ALL RubyEdit components turned off at once!

[Spogg]

I just had a Ruby nightmare!

I got a Ruby error due to excess processing detected. But when I went up to the top level of the schematic, every damned component using Ruby (and there are a lot) had turned off.
I saved the schematic because I had just made some good changes, but when I re-opened it all the RubyEdit components were still turned off.
I had to go through every damned one and turn them all back on, one at a time.
This is before I could try to find what had caused the excess processing.

Is it normal for this error for every RubyEdit box to turn off at once? Is there a way to turn them all on at once?

Cheers

Spogg

[tulamide]

Yes it is normal, especially if they are chained together (similar to the propagating trigger issues), but also on not connected RubyEdits doing completely different jobs, when the kernel is affected.

This safety measure makes sense, since you don't want to crash due to Ruby. And yes, you can only turn them back on one by one, and that also makes sense, because you should first search for the programming error or else they will just shut down again.

It is annoying (I had it many times), but you can prevent a lot of it if you do the following:
1) Save right before starting new code.
2) Disable the RubyEdit in which you write code before you do so.
3) Save a copy of the changed schematic.
4) Only then turn on the RubyEdit you turned off manually.

Similar proceedings if you don't know anything about Ruby, but are about to connect something to a RubyEdit (note: includes modules that have a RubyEdit inside).

[Spogg]

Than you good sir!

You gave me good advice about handling changes to a RubyEdit.

However, my big “turn-off” was when I was messing with View switching which included a RubyEdit connected to it. I didn’t touch the RubyEdit itself! Honestly!

Since posting, I haven’t been able to reproduce the problem (in a copied schematic of course). I also remembered that I had some Ruby code which didn’t relate to Viewing (monostable and an array sorter I made) so I expected to see them turned off as well, but they were still on. So, while it seemed at first that ALL were affected, it’s the case that only the View ones (like in all my selectors, switches, labels etc) were turned off.

It seems there may be something rather “unforgiving” in the View processing aspect of Ruby.

Many thanks again.

Spogg

[trogluddite]

It seems there may be something rather “unforgiving” in the View processing aspect of Ruby.

It's to do with which RubyEdits happen to receive an event to process while the faulty RubyEdit is hogging the Ruby interpreter. No other RubyEdit can process anything while the interpreter is stalled, so any which have work to do while the timer is running down can also time out. RubyEdits which don't happen to have anything to process during that time don't get affected - at least not immediately (caveats in the next paragraph!)

However, since we quite often have something to redraw following a value change, and drawing a View has to draw all of its nested "sub-Views", RubyEdits with a GUI to draw are very easily caught in the crossfire. So, as you say, they are rather less "forgiving" than others. Also, it often spreads further when loading or saving a schematic, because there's usually a flurry of triggers and Ruby events at those times (RubyEdits with loadState or saveState methods will have them called, for example).

One other tip. When a RubyEdit is shut-down, its input/output/saveState data won't get stored when you save the schematic - so when you turn things back on again, you might see a lot of Ruby error messages because of RubyEdit inputs having 'nil' as a value instead of a String/Integer/Float/etc. like they should have ( the error message will usually mention 'nil' or 'NilClass'). If you see this, try refreshing all of the RubyEdit's inputs, either by triggering values to be sent to them, or by clicking the RubyEdit's input connectors - it's very easy to mistake this for broken code!

This is the thing that v3.0.8 was supposed to fix by making the RubyEdit timeout per-instance - which it does, but at the expense of its other issues. It is incredibly annoying, and I wish I could turn it off for RubyEdits which I know full well are working properly. It's also part of the reason why I usually edit Ruby in an external editor (Notepad++) and then paste it in - otherwise, I know for sure that my sub-conscious CTRL-S reflex will save the schematic at just the wrong moment!

[RJHollins]

One other tip. When a RubyEdit is shut-down, its input/output/saveState data won't get stored when you save the schematic - so when you turn things back on again, you might see a lot of Ruby error messages because of RubyEdit inputs having 'nil' as a value instead of a String/Integer/Float/etc. like they should have ( the error message will usually mention 'nil' or 'NilClass'). If you see this, try refreshing all of the RubyEdit's inputs, either by triggering values to be sent to them, or by clicking the RubyEdit's input connectors - it's very easy to mistake this for broken code!

ooooooo ... Thanks for this Tip TROG !

[tulamide]

Another thing to keep in mind is that unlike schematics, Ruby is not removed by closing a schematic. It still runs in the background with whatever state it is in. The only way to get Ruby to start fresh from the start is to close Flowstone and start it again. This isn't always needed, of course, it depends on the issue you're facing.

[trogluddite]

However, my big “turn-off” was when I was messing with View switching which included a RubyEdit connected to it

I've managed to reproduce this a couple of times here now, but it's a very intermittent problem that I can't quite pin down - each time I've managed to break it, I try the same thing again and it works OK! However, certain combinations of linking up a selector to a RubyEdit View connector do indeed blow the Ruby 'fuse' (FS 3.0.6).

My guess is that for some reason, the RubyEdit gets passed an invalid View to draw onto, or maybe just nothing at all. There's something about whether it's the RubyEdit's first time having to draw anything, and whether the selector is fresh from the toolbox, that seem to make it more likely, and it only seems to happen after new links have been freshly connected - but that's as close to nailing it down as I've been able to get. Thankfully, it seems at least to be a "just edited the schematic" problem rather than a "during run-time" problem!

Suffice to say, I think it's unlikely that you were doing anything wrong, and just got very unlucky - but we should probably add to tulamide's list of tips something like...

5) Don't connect to a RubyEdit View connector (or keep the RubyEdit turned off) until all of your View wiring is in place and showing the proper (V) icons (but even that might not guarantee it!)

[Spogg]

Guys, thanks for all this background.

I’m glad Trog was able to see it sometimes. This kind of behaviour suggest to me that it’s some sort of timing issue, so it’ll be a bit like throwing dice in effect; get the timing “wrong” and you die.

I’ve done lots of view switching connections before with Ruby running and it’s never happened, hence my shock and horror.
I do think it’s a good idea to turn off a RubyEdit when editing View control, especially when a schematic is getting huge.
A little step like that can save many tears later.

Cheers

Spogg