Overflow bug

[alexalthauser]

I've been following the RubyMonk tutorial, and I typed this into the Ruby console.

loop do
"this line will get executed infinitely"
end

The console gave an error message, and then it switched to Off. I deleted the code, and then tried to switch the component back on, but to no avail. I deleted the component and replaced it with a new one. The new component still showed the error message, and I was still unable to switch it back to on. I restarted Flowstone, and everything works well again. The process is repeatable. It's not a large bug, but I thought I'd mention it. Although, it could possibly just be due to a memory problem, on my end.

[trogluddite]

This is partly a consequence of there being only one Ruby interpreter running, I think.

The Ruby blocks aren't really independent, they're just containers for code that all gets run by the same interpreter - so if you lock Ruby into an infinite loop anywhere it will lock up the entire Ruby system.
Because of that, and because the interpreter is always running in the background, removing the Ruby blocks won't have any effect on the already running loop. Either the stack will eventually overflow because the loop body is creating too many new objects, or the connection between Ruby and FS will time out, disabling the Ruby blocks.
In that situation, only stopping the interpreter completely (i.e. shutting down FS) will break the loop.

I doubt that much could be done about this, as the overflow error is inherent in the Ruby interpreter - in fact it could be taken as a good sign that FS takes Ruby going down so gracefully - you were even able to carry on editing. It's easy to take FS's stability for granted - but considering some of the stuff we throw at (my code typo's!), and that it is always 'live' during edits, it is quite an achievement to make it so robust.

And infinite loops are begging for trouble - when you say "forever" to a computer, you'd better be sure you really mean it!

[VPDannyMan]

Hmm...
I never thought about that Trog..

[trogluddite]

I never thought about that Trog.

Ruby certainly gives us plenty more to think about!
A very accessible language that's relatively easy for beginners to get to grips with - but with enough low-level access to the system for the unwary (or mischevous) to seriously mess up a PC.
It has some parallels with delving into the assembly module, where there are not the safeguards that DSP code has - but buggy assembly generally just crashes, whereas buggy Ruby, especially file system stuff, could have undesirable consequences much worse than simply cursing and then restarting your app'.
The infinite loop example, while harmless in itself, is a good demonstration of how the new capabilities we now have with Ruby also bring with them consequences and responsibilities.
I wouldn't want the forum to turn into a 'police state' or for us all to be obsessively critical of each other's work - but I think that we should be vigilant for uploaded code that has the potential to be harmful, and politely point out to the poster how to improve their code. In extrene cases, maybe even suggesting to the dev's or moderators that certain downloads be removed.
The forum I visit for Sketchup Ruby plugins has a 'quarantine' area set aside for this purpose. Generally the download iremains available, but in a discrete area with appropriate warnings to users - this allows the opportunity for other users to fix genuinely useful downloads that just need a bug or two ironing out.
On the whole, users who have made a genuine mistake, or who are still learning all the best practices take this is good spirits and are glad of what they learn from the experience. The few who take it badly are generally the kind of folks that no-ones going to miss anyway, or who later get banned for other mischief.

[infuzion]

The Ruby blocks aren't really independent, they're just containers for code that all gets run by the same interpreter - so if you lock Ruby into an infinite loop anywhere it will lock up the entire Ruby system.
Because of that, and because the interpreter is always running in the background, removing the Ruby blocks won't have any effect on the already running loop. Either the stack will eventually overflow because the loop body is creating too many new objects, or the connection between Ruby and FS will time out, disabling the Ruby blocks.
In that situation, only stopping the interpreter completely (i.e. shutting down FS) will break the loop.

Does not sound good for depending FS for anything system critical, like VSTs or running a robotics factory.

So if one Ruby module is a bit slow, then that locks up the entire schematic? Perhaps we should not depend on Ruby so much, esp when FS does not seem to have internal tools to profile the scripts (opposed to web-based Ruby, since that does have many tools to trouble-shoot Ruby issues).

Does green have issues like this?

[trogluddite]

Does green have issues like this?

Can green handle multi-dimensional, mixed data-type arrays?
If so, how much work would it take to make this functional and robust?
And how fast would it run?

So if one Ruby module is a bit slow, then that locks up the entire schematic?

Sure, Ruby has some limitations, just as SM always has - and they each have their own advantages too. But this particularly seems a strange point to criticise - of course green has issues like that; trigger a ReDraw loop too fast and you'll max out a core in no time - or program a single DSP module badly and listen to the whole thing crackle. Or one could do a spectacularly bad job of writing a C function and have the same result when using the VST SDK.
SM and FS are there to make a difficult job more easy, but they are not a license for lack of diligence and bad programming.
With VSTs, I would be inclined to agree with you more - each exe runs its own Ruby interpreter so far as I can tell - but VSTs do share a common interpreter, which can lead them to interact in the current implementation.
But even then, if another FS plugin were to start interfering with mine, I would be more inclined to say that the other programmer is inexperienced or a a bit of a cowboy, and not use their plugins until they learn to make them well, rather than blame FS per se.

But that's just my amateur's take on things - I point out the things I discover about FS/Ruby so that we can all know and debate the nature of the beast, and can make informed choices . For me, they are parameters to work within, but not deal breakers - for a more commercially oriented programmer, I can see why they might be.