DSP Robotics Support

RJHollins wrote:any improvements writing and de-bugging RUBY would be most welcomed

Totally agree.
Even before we had Ruby, I thought that de-bugging is the weakest area of the SM/FS interface, and a few simple tools could make life a lot easier.
For example, a 'green breakpoint' primitive that pauses the trigger system to allow values to be inspected before another trigger comes along and changes them all; or a floating window to show the values at chosen links without having to navigate all over the schematic to see them.

Another problem, that I still bug Malc about from time to time, is the difficulty of using custom Classes and Modules in Ruby. Even if it were only for ones we make ourselves, it could make Ruby much less daunting to get started with.

Maybe only a few of us have mastered Ruby enough to create such things, but if they were easy to embed into a schematic, they could be used to build 'code libraries' that simplify complex tasks for everyone. For example, to make a 3D vector knob, just drag in a module from the toolbox that defines an SVG file parser, and transformations for rotation etc. - voila! Vector knobs become as easy to make as bitmap ones.

It is not impossible to use custom Classes, but the current ways require a lot of care to avoid the quirks of FS - otherwise they can very easily introduce bugs that a less experienced user might find difficult to de-bug.
In principle, all that is needed is a RubyEdit primitive that is guaranteed to be parsed before all others, or one that will embed the Ruby code for 'required' source code files - much less demanding than, say, the DLL embedding that was recently added.

I feel that we really miss out on a lot of the power of object-oriented programming because of this, and folks are often spending a lot of time "re-inventing the wheel" to write low-level routines that we could have 'standardised' by now.