how can I disable input/output saving in Ruby?

[KG_is_back]

Simple, yet important question. I'm using ruby connections to pass data that can be "marshal dumped", namely an Anonymous module (object of Module class) buried deep in the data. I can't avoid having that anonymous module there, so only option is to disable marshalling of inputs/outputs when schematic saves.

Is that possible? Perhaps a feature to be added?

[tulamide]

Simple, yet important question. I'm using ruby connections to pass data that can be "marshal dumped", namely an Anonymous module (object of Module class) buried deep in the data. I can't avoid having that anonymous module there, so only option is to disable marshalling of inputs/outputs when schematic saves.

Is that possible? Perhaps a feature to be added?

Any anonymous module could as well be a static one. As such you wouldn't need to pass anything else but a pointer (or access it directly. Wouldn't that be much easier than trying to disable some Flowstone functionality? If not, it would need to be done by DSPr, I'm afraid.

[KG_is_back]

I have fixed the issue by assigning the module to a constant. What that does, _dump only dumps the constant's name and it's value (the module itself) is referenced by that constant once it's evaluated.

I have found another example, when I really don't know how to fix the issue - Hash with a default proc (a code block, that is run, when you request non-existing key) can't be dumped either. I really don't wish to stop using them just because of this issue, because they are often super-helpful (note: hash with default proc is fundamentally different than hash with default value).

Code: Select all

#if you run this code and save the schematic, you'll get an error
x=Hash.new{|key,hash| hash[key]=nil}
output x


For example DSPR could add a method, that would disable/enable saveState method from saving I/O. Or it might enable/disable a "rescue" statement in saveState method, which would return "0" (dumped nil) or dumped []. I tried to put the rescue statement in it myself,but the saveState method we define in ruby component manually is either different from the one that saves I/O (although, by the TypeError it shares the same name), or the "save inputs and outputs" part is added later after code in Ruby component is evaluated. Either way, I was unable to make it respond to a "rescue". Not even redefining the saveState method work:

Code: Select all

class RubyEdit

alias_method :setSaveState,:saveState #save old method as alias

def saveState(*a) #new saveState method definition
   begin
   setSaveState(*a) #call old version
   rescue #if error occured, return default value
      Marshal.dump([])
   end
end

#saveState method now should return Marshal.dump([]) if any error occurs


[tulamide]

For example DSPR could add a method, that would disable/enable saveState method from saving I/O. Or it might enable/disable a "rescue" statement in saveState method, which would return "0" (dumped nil) or dumped []. I tried to put the rescue statement in it myself,but the saveState method we define in ruby component manually is either different from the one that saves I/O (although, by the TypeError it shares the same name), or the "save inputs and outputs" part is added later after code in Ruby component is evaluated. Either way, I was unable to make it respond to a "rescue".

That's what I said. A change would need to be done by DSPr, if it gets too deep into Flowstone.

Code: Select all

#if you run this code and save the schematic, you'll get an error
x=Hash.new{|key,hash| hash[key]=nil}
output x


Ok, now this is strange. I checked your example and had no issue. Try the schematic I attached to see if it causes trouble for you. (v3.0.6)

[KG_is_back]

Ok, now this is strange. I checked your example and had no issue. Try the schematic I attached to see if it causes trouble for you. (v3.0.6)

The error is reported when you save the schematic (crtl+s) and then click back to the flowstone working place - not immediately when you save. (v3.0.8.1)

That's what I said. A change would need to be done by DSPr, if it gets too deep into Flowstone.

I've already submitted the issue to DSPR.

[tulamide]

The error is reported when you save the schematic (crtl+s) and then click back to the flowstone working place - not immediately when you save. (v3.0.8.1)

Confirmed with v3.0.6

Also, it is not a Flowstone issue. I read a bit about Marshal:
"Some objects cannot be dumped: if the objects to be dumped include bindings, procedure or method objects, instances of class IO, or singleton objects, a TypeError will be raised."

In conclusion it would indeed be neccessary to either catch those TypeErrors or have an "exclude from dumping"-option. Took me a while to see the whole problem. Now that I understand it, I hope DSPr will have a solution for it soon.

[KG_is_back]

In conclusion it would indeed be neccessary to either catch those TypeErrors or have an "exclude from dumping"-option. Took me a while to see the whole problem. Now that I understand it, I hope DSPr will have a solution for it soon.

Exclude from dumping without notifying the user is a bad idea.
Suppose you create a GraphicsPath, store it in module input and expect it to be there when schematic reloads (vs. re-initializing it in "init" method on startup, which is the working and correct way). You have a bug that is very hard to trace and comprehend and "BUG - GraphicPath does not persist in inputs"-type of topic will follow soon.

Being able to manually switch of persistence on modules is far more reliable. It even may have other applications, like decreasing loading times in case when output contains a big array, which is reinitialized by afterload trigger anyway (in which case saving and loading it with its previous values is pointless).

[tulamide]

Exclude from dumping without notifying the user is a bad idea.

I haven't said so.

...have an "exclude from dumping"-option...

An option is something that you, the user, control. That was my thought. An active decision, like "switching off" on purpose because of, for example, one of the things you mentioned