Reading/Writing Text Files

[frangonve]

Hello, I think an useful addition to waterbear would be the ability to read/write local text files:

A block to open a dialog to read a file returning the path selected by the user. A block to open a dialog to write a file returning the path selected by the user. A block to read a line of file into a string A block to write a line of file from a string

Additionally: A block to read a file into an array (a line into each element of the array) A block to write a file from an array (a line from each element of the array)

What do you think?

Sorry for my bad english

Cheers

Francisco

[dethe]

I think this is a great idea. This is a relatively small addition, is it something you would feel comfortable implementing? I'd be happy to guide and/or help, and we could even factor out some of the code from the IDE that deals with files to re-use.

Your English seems fine to me, you are communicating the idea and I understand you. Don't worry, I will ask for clarification if there is anything I don't understand. I hope you will too.

[frangonve]

Well, I can't promise anything as I barely code in javascript, I don't know the Waterbear/github environment and I'll need lots of help. But I'll look around...

[dethe]

Sounds good. Look at how the blocks in languages/javascript/controls.json are implemented and then at scripts/file.js. The code in file.js isn't perfect, we'd need to clean it up a bit first to be more re-usable, but it has examples for opening a file and for saving a file that are quite different than most of what you'll find in JavaScript code or online examples.

The usual way to open a file is with the HTML <input type="file"> element, which cannot be styled effectively with CSS. So instead of having that in the HTML, we create it dynamically when it is needed and called click() on it to open a file dialog. Then we use the new-ish file APIs to actually read in the file (the <input type="file"> was designed for uploading a file to a server, but we want to process everything in the client).

For saving a file, we do a similar trick. The <a> element has a new (but supported in recent Firefox and Chrome) attribute "download" that lets us set a file type and content to download. Since we don't know the content until the user downloads something, we create the <a> dynamically and populate the download attribute before calling click() on the generated element.

Hopefully, that explanation will help you to understand what the code is doing, but feel free to ask questions!

And if you do feel it is beyond you, let me know. This would be a good first bug for a student.

Also, I'm curious how you found Waterbear and what you are using it for?

[frangonve]

I'll start by the end: "I'm curious how you found Waterbear and what you are using it for?"

I'm interested in visual programming, and so I found Waterbear. Really I'm not using it but I find it attractive. Now I'm using another visual programming tool: "Limnor Studio" and a textual programming language of APL heritage: "J".

Last thing I've coded was a small tool in J language to transform some old format flat text files to a new standard called SEPA (Single Euro Payments Area)...

Yes, I´ll look the code you mention... to see if I can be of any help...

Cheers

[CelticMinstrel]

What about a control block to read a file line by line and do something with each line? And what if you want to read less than a full line from a file or write out just part of a line? Also, users might want to read and write numerical data rather than textual data; I'm not sure if Waterbear has blocks to convert between the two, though.

[frangonve]

Hello Dethe,

After reading your code and thinking a bit, I see that I can't realistically help you to implement, being beyond my ability.

Cheers

[frangonve]

Hello CelticMinstrel,

Perhaps additional blocks could be designed/implemented to allow the behaviour you describe. To convert text to numeric perhaps blocks implementing functions like parseFloat/parseInt could be added to math

Cheers

[dethe]

@frangonve Fair enough, thanks for the thoughtful issue, we'll find someone to take it on.

[nosman]

It occurred to me this morning that we could have an eval block that would work very well with the reading/writing text files block. This could import the text file and use javascript's eval to actually run the code. This might give users more flexibility and control over how they want to create code.

[dethe]

@CelticMinstrel There are a lot of blocks we could add for better string processing. For instance:

• underscore-string
• Parser tools like PEG or OMeta
• Or, if we want to get radical, things like SNOBOL pattern matching components, which were added to Python with a nice writeup

[dethe]

@nosman How would we prevent that from becoming a giant security hole for cross-site scripting, though?