DSP Robotics Support

Now (with version 0.7)it really starts to fit my needs. I tested it with several tx16wx programs and it works great. I will test it in my dayly workflow some time until I send a "release" version

hmmm would it be possible, to create a ruby.rb file from within flowstone, to start with 'normal' ruby, so that this rubyscript would convert from utf16 to utf8? You only would have to install ruby and that's it...

Hi mccy,
Wow, that's some amazing progress - I only took a couple of days away from the forum, and you already have most of your core functions working!

mccy wrote:hmmm would it be possible, to create a ruby.rb file from within flowstone, to start with 'normal' ruby, so that this rubyscript would convert from utf16 to utf8? You only would have to install ruby and that's it...

You would need a decent code editor so that you could adapt the code a little to work outside FS, but yes, this is actually quite simple. I've been doing it a little myself, because I really like the instant feedback you get when editing code inside FS - so I use FS sometimes to prototype code for making stand-alone Rubies. So, if you are happy with a "batch file" rather than complete GUI, you should easily be able to adapt what you have to be a stand-alone Ruby program. It's when you come to build a user-interface that plain Ruby becomes much more difficult, and FS then comes into its own.
And it won't cost you a penny - just download the Ruby Windows installer - and for an editor, you could use SCite or Notepad++, both of which are free and understand Ruby syntax straight out of the box. Since Ruby files are just text, there's no problem cutting and pasting code between the FS editor and standard .rb files.
In fact, I work with Notepad++ open most of the time - it can be very handy to copy the code over into an external editor where you have features like search and replace, multiple views of the same code, or even just to have a bigger window to view the code in - and then back into FS for 'interactive' editing of the details.

Now, that I see how nice gui editing in FS could get with additional parameters, maybe a real editor etc, I'd like to stay in FS although 'porting' to ruby alone would be a nice thing for batch editing.

What I'd like to do is fire up just a ruby converter from FS. Like "Start convert.rb; change filename, pick up new filename in FS" and going on in FS - but all under the FS GUI... Would that be possible, to 'activate' an external ruby file from FS created GUI? It would not have to control any parameter. Renaming would be an automated process in the rb file, while FS program knowing what will happen: converter picking up "abcde.txprog" in a dir specified in FS, spitting out a file like "abcdeX.txprog", FS doing the rest of the work as allready done.

Can you read this file (Thex.txprog) and see a whole text?
I tried it on 3 computers - it doesn't work for me. Support told me that the file is O.K. & sent a screenshot of proof & a fsm project to open & test.

I checked out the TX file using NotePad++, and it is definitely a properly encoded UTF-16LE file.
The problem is that the encoding tag in the 'open' method is not doing anything. I've never seen that construction before, and I don't see it in the API docs, so maybe it is something from an older version of Ruby. You can type anything you like after the 'rb' and Ruby doesn't even notice.
Putting "f.external_encoding" after the 'open' shows that the file is still being read as if it is an 8-bit ASCII file.

However, in the absence of the proper encoder, I think you definitely have the right idea - read the data in binary form, and do your own conversion. Here's something that is maybe one step closer - reading the data as 16bit integers, and then converting those to characters as if they were 8 bit (at the moment non-ASCII characters are converted to underscores just to highlight them)

This might even be enough to recover everything you need. I rigged up a little routine to count the number of non-ASCII character codes in the whole file (i.e. binary > 255), and there was only one - the first character in the file (possibly just a header giving the file-size/encoding or some other metadata).
So I would guess that as long as none of the filenames include 'international' characters, this may be a perfectly practical workaround.

Great!!! Thanks!!!!! This works! It is now so supereasy to convert complex multiprograms from tx16wx! Yeah!

http://www.derknott.de/tx2SFZ08.zip

This is the actual version.

That's translating beautifully - and the GUI looks to be coming on nicely too.

And thankyou for giving me a kick in the direction of doing a '16bit->8bit translation - it's lead me to find a few things that may well be useful for my own adventures into file parsing.

And I found out a little more about those first two bytes - apparently, they are the file's Byte-Order_Mark (BOM) which can be used to distinguish the correct decoding for UTF files. There's loads about it in this document. The BOM stuff is a fair way down the document, with a table showing what values to look for - and it looks like there's a whole lot of other useful stuff in there too.