Opened 15 years ago

Closed 13 years ago

Last modified 11 years ago

#548 closed enhancement (fixed)

Turtle Art:: read and write to text file

Reported by: tonyforster Owned by: walter
Priority: Normal Milestone:
Component: Turtleart Version: Unspecified
Severity: Unspecified Keywords:
Cc: rgs Distribution/OS: Unspecified
Bug Status: Assigned

Description

Suggest adding blocks for file open, read record and write record.

Attachments (1)

TurtleArt-104.xo (996.4 KB) - added by walter 13 years ago.
if json decoding fails, try processing clipboard data as a list

Download all attachments as: .zip

Change History (22)

comment:1 Changed 15 years ago by tonyforster

  • Bug Status changed from Unconfimed to Assigned

comment:2 Changed 15 years ago by erikos

  • Milestone changed from Unspecified by Release Team to 0.86

Moving to 0.86 as it is an enhancement.

comment:3 Changed 15 years ago by walter

Do we need to add this feature given that the user-definable block can be used for file IO?

comment:4 Changed 15 years ago by tonyforster

I am inclined to say this is a desirable feature even though users can implement in python. Ultimately it depends on how simple it is to use and what the resulting learning curve is for users.

comment:5 Changed 15 years ago by walter

  • Milestone changed from 0.86 to 0.88

comment:6 Changed 15 years ago by rgs

  • Cc rgs added

I can take a shot at this. I would need a better definition of the use cases, desired operations and semantics .. You would write one line at a time to a file? You would only be reading one line at a time?

A sample use case would clear some of my doubts.

comment:7 Changed 15 years ago by walter

Given an external data source, it would be useful to be able to read data stored in the Journal. Saving data to the Journal is less obvious to me, but I can imagine kids wanting to compute some result from the data they read and then save it out.

A simple CSV scheme would probably be easiest. A couple of new blocks on the Extras panel?

comment:8 Changed 15 years ago by tonyforster

A sample use case:
Was thinking mainly of sensor input and being able to read/write one line at a time in CSV format, eg
24/8/09, 10:06AM, 32.5mV

another use case, read in a *.txt helpfile, one line at a time till EOF

Other use cases demoed:
http://rupert.id.au/schoolgamemaker/samples3/
smartbug: CSV one line at a time suitable spreadsheet import
http://rupert.id.au/schoolgamemaker/morethan.htm
database: one line at a time each record is a string
firstname
lastname

A simple CSV scheme would probably be easiest. A couple of new blocks on the Extras panel? YES

comment:9 Changed 14 years ago by walter

  • Milestone changed from 0.88 to 0.90

Just didn't get around to this one for 0.88. Will make it a priority for 0.90.

comment:10 Changed 13 years ago by tonyforster

I am reconsidering this, some challenges are better left open.
http://wiki.sugarlabs.org/go/Activities/TurtleArt/Using_Turtle_Art_Sensors#Importing_Logged_Data_into_other_Activities
shows how to export csv data to the clipboard with the Python Block

comment:11 Changed 13 years ago by tonyforster

comment:12 Changed 13 years ago by walter

I've added sample code to tamyblock for copy and paste to/from the clipboard and save/load to/from the Journal. (I still need to add support for file IO in non-Sugar environments.)

Questions:

(1) Should all these samples be crammed into one by python file or would it make sense to make a collection of small files, e.g., copy.py, paste.py, etc.

(2) I am on the fence about making these predefined blocks as they seem so useful.

(3) I will have to make sure that non-JSON-encoded data is readable, e.g., data saved from Measure.

(4) Should I strip the [] off the JSON data when pasting, saving?

(5) Should I enable each Python block to load its own code? In which case, there is a UI question: each time I click, should I prompt to reload the block? Or should I somehow load the block through the toolbar? The how to associate which block with the loader? Last one touched?

comment:13 Changed 13 years ago by tonyforster

1) A collection of small files does make sense. Like the TA samples, in the file system not the journal? Then load python block would need to handle both the journal and file system? As editing is now done in pippy, the workflow to edit one of the examples is complex. Interacts with other issues like (5)and in TA editing.

2) I am on the fence too. Depends on whether the student who is advanced enough to want to save data is going to benefit from a python challenge. My primary use case is logged data but theres no telling how it might be used, eg pasting an infinite series into a write doc.

4) If python code, leave it as a challenge? If a new block, delete [].

5) Every time a block is clicked, reload? Remove from toolbar?

comment:14 Changed 13 years ago by walter

Here is my current plan:

(1) Use the toolbar button to access sample python code stored in the file system (similar to the sample turtle art code). This will have the side effect of letting me remove journal spam. The result of selecting a sample file will be a new block added to the project that is loaded with that code.

(2) Dragging a sample from the palette will result in a block that is not loaded. Clicking on that block will open the journal chooser to select python code to load.

Question: how do we move sample code into the journal so that it can be modified in Pippy? Perhaps copy it to the journal when it is loaded?

Note: by opening the chooser every time a block is clicked means that the only way these blocks can be executed is by attaching them to a stack.

Comments?

comment:15 Changed 13 years ago by walter

  1. Samples are now in separate small files in the pysamples subdirectory
  2. You load samples from the toolbar and the sample code is copied to the journal
  3. Clicking on a block will open the chooser to load python code from the journal
  4. Python code is loaded on a per-block basis
  5. No error message is shown if the code is not loaded (not sure this is the best behavior)
  6. Python code can be edited in either Pippy or the plain text editor, Edit.
  7. Currently, the code loaded into a block is not saved between sessions. I am not sure of the best way to do this. If I save the code directly in the block, then it represents a serious security risk when projects are shared. Maybe I will save the object ids of the associated python files and thus require that the python file be explicitly shared and loaded (and hopefully examined) before it is executed?

comment:16 Changed 13 years ago by walter

Re #7 I added loading from the Journal. Still need to add support for non-Sugar TA.

comment:17 Changed 13 years ago by walter

Added support for reloading Python code in non-Sugar contexts.

Still to do: sort out JSON and non-JSON encoding situations.

Changed 13 years ago by walter

if json decoding fails, try processing clipboard data as a list

comment:18 Changed 13 years ago by walter

I've addressed the issue of reading in non-JSON-encoded data with the latest patch (http://git.sugarlabs.org/turtleart/mainline/commit/20e252c1e3db408ebb005a705dcf41d70c758c5e). But I think I will write JSON-encoded data. Ready to close the ticket?

comment:19 Changed 13 years ago by tonyforster

Thanks
Will try V104 when I get time
OK to close ticket.

comment:20 Changed 13 years ago by walter

  • Resolution set to fixed
  • Status changed from new to closed

We've resolved this by using example code in the Python block.

comment:21 Changed 11 years ago by dnarvaez

  • Milestone 0.90 deleted

Milestone 0.90 deleted

Note: See TracTickets for help on using tickets.