FS Ruby user state management

For general discussion related FlowStone
Post Reply
tulamide
Posts: 2714
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

FS Ruby user state management

Post by tulamide »

Another one of those guess-what-really-happened-errors. I post it here because it refers to a method that doesn't exist throughout the whole schematic. The error message appeared with a freshly started FS (and of course disappeared after having clicked into the instance once, to make it even harder to find a meaning in such error messages). :lol:

My guess: As I used my acm (which in turn uses the schematic to save colors via user state management) in an earlier version, then removed and replaced it and finally saved the new sturctured schematic, I'm afraid FS does not clear the schematic from older user states. If so, I call it a huge bug!

loadstatewtf.png
loadstatewtf.png (19.93 KiB) Viewed 9826 times
"There lies the dog buried" (German saying translated literally)
KG_is_back
Posts: 1196
Joined: Tue Oct 22, 2013 5:43 pm
Location: Slovakia

Re: FS Ruby user state management

Post by KG_is_back »

I've got similar bugs all all-round Flowstone. saveState and loadState methods save/load the variables via Marshal rutine. If a class does not have "_dump" and "_load" methods it cannot be saved/loaded. Also remember, that @ins and @outs are saved and loaded by the loadState/saveState methods too.
tulamide
Posts: 2714
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: FS Ruby user state management

Post by tulamide »

Thanks for the help, KG.

KG_is_back wrote:saveState and loadState methods save/load the variables via Marshal rutine. If a class does not have "_dump" and "_load" methods it cannot be saved/loaded.
Yes, I am aware of that. As I said, there is no saveState or loadState throughout the schematic, so this is not an issue.

KG_is_back wrote:Also remember, that @ins and @outs are saved and loaded by the loadState/saveState methods too.
I'm not sure what you mean. If using marshalling to keep the state of the inputs and outputs was meant, then I'm aware of that too.

The cause of this error message had nothing to with marshalling. It was an incorrect order of RubyEdit-initializations. FS is overly sensitive in that matter. I described that I removed a module from the schematic, replacing it by another one. The removed one was the first added to the schematic, removing it changed the order. I knew about this and normally take care of the right order, but in this case I didn't see the need as it was the first one, but not the one with the class definition). However, after cut'n'paste everything but the new module, it works fine now.
"There lies the dog buried" (German saying translated literally)
KG_is_back
Posts: 1196
Joined: Tue Oct 22, 2013 5:43 pm
Location: Slovakia

Re: FS Ruby user state management

Post by KG_is_back »

Oh, now I get it... it seems the Class isn't initialized when loadState is called, right?
tulamide
Posts: 2714
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: FS Ruby user state management

Post by tulamide »

KG_is_back wrote:Oh, now I get it... it seems the Class isn't initialized when loadState is called, right?

Yes, I have an input where a class is expected (the fourth one in the image), but the class was initialized after the request :)
"There lies the dog buried" (German saying translated literally)
Post Reply