Ruby Execution Order Experiment

[trogluddite]

While working on some biggish Rubies, I've been scratching my head trying to prevent "no method for nil class" errors at startup. There are quite a few things that have to happen when a Ruby starts - loadState, fetching the stored input/output variables, the 'init' method etc.
So I devised a little test to see if I could work out once and for all what order these things happen...

Execution Order.fsm

(425 Bytes) Downloaded 1054 times

Each section declares a variable, and also watches the values of all the other variables to work out which ones it is able to see - they'll return 'nil' if not declared yet. The results I get seem to indicate that the order is...

1) - Parse the code to make all the method definitions. Code not wrapped in a method will also get executed.
2) - The 'init' method will run if there is one
3) - loadState retrieves any variables stored at the last schematic save.
4) - The input and output variable arrays are read
5) - The bare code is parsed again! (Note how it seems to see all of the other variables - yet all of the other stages can see the "bare" variable. Two passes of the parser is the only reason I can think of for this)
6) - The rest of the schematic goes 'live', and events at the inputs start arriving.

Hopefully this knowledge will prevent so many load time errors due to undeclared variables being used too soon - e,g, don't refer to an input variable within the 'init' routine etc.
I'd be glad to hear from anyone who can spot any errors in my reasoning, though, as I'm still not 100% that I'm reading the results quite right!

PS) I'd also be glad of any explanation why I called the input variable 'doodad' instead of just plain old 'input'!!

[unkargherth]

Are you concious of what this means?

Yeah, well, Deeper knowledge, less bugs, etc, etc....

The only important thing is :

"Attention Citizen Trogluddite: By your actions, knowledge,expertise, generosity and easy paced way of sharing your knowledge, you, personally, without any doubt, declared yourself ( and worst, everybody agrees) as THE Ruby Component Resident Guru - from now RCRG - , receiving all the prestige and influence related to the position and assuming, knowing it or not, all the responsability this position implies, including , but not limited too:

.- Being requested for help
.- Being cited as the ultimate source of all wisdom
.- Becoming Master, Teacher and inspiration for the rest of us
.- Becoming the author of the next "Ruby for Flowstone for dummies"
.- Becoming the author of the next "Ruby for Flowstone: The Reference "
.- Becoming the author of the next "Ruby for Flowstone: The Hidden Chapters"
.- Becoming the author of the next "Ruby for Flowstone: What you always wanted to know and Never asked"
.- Becoming the author of the next "Ruby for Flowstone: What they don't want you to know"
.- Beign forced to write tons of free ( a free Beer) mistake-less, bug-free, eco-green, feature-full, resource-low, near Goodlike code, and
.- Accept our Thanks as one-and only payment for all of it

Thanks Citizen Trogluddite. Good work. Continue that way"

[trogluddite]

ROFL
I shall get my crayons out and make myself a special badge!

[trogluddite]

Been pondering this issue more since doing my experiments - and it has occurred to me that IF I have read the system right, it is a little flawed. (if I got it wrong, then my apologies for time wasting!!)
'init' seems to be executed before either the saved 'loadState' or input arrays have been read, so this means that the 'init' routine does not have access to any of those variable values.
This means that 'constants' cannot be derived from any of those values - for example, you might want to calculate a value or fill an array using an equation that requires the routine to know several 'property' values that the user sets up as 'user preferences' from the properties panel.

So this leaves us with three options for calculating 'derived' constants...
1) Waste CPU calculating them repeatedly whenever they are needed within the events section.
2) Have a special events routine triggered by a separate input and an 'After Load' primitive - which seems an unnecessary complication (though required for certain memory hungry data anyway e.g. bitmaps)
3) Just use bare code, not wrapped in a method, as this will get processed by the 'second pass' of the parser. Which kind of defeats the object of having an 'init' routine at all. This method has proved to be the most reliable for me in a couple of Rubies that I have written.

Here's a little example to show what I mean...

error no_error.fsm

(336 Bytes) Downloaded 1055 times

When you load it, notice how the one with the 'init' routine gets the length of the string wrong - it seems to know that the input is of the String class (so no Type error), but the value read is wrong because @input hasn't been read yet. But the version that is just bare code gets it right.

This seems odd - loading stored 'loadState' and input values is not going to need access to variables initialised in the 'init' routine, whereas 'init' having access to stored variables seems like it could be rather useful.

You might say - "well if that is the case, just don't use 'init' then!". Quite so - but there might be times where having 'init' is useful - there may be other circumstances where it would be useful to call it, for example; apart from which, it does make the code more readable, and could be handy when searching the code in an external editor.

This might seem a moot point when you can use 'saveState', 'loadState' and the input arrays to hang onto whatever values you need - but there are quite a few object classes that cannot be stored this way. To be able to do this, the class must have the correct methods defined for the Marshal module.. Not all of them have this, and user defined classes certainly will not unless the user builds them. There are also some data types are inherently not save-able (e.g anything that refers directly to an object's ID code, such as Proc objects).

This is of course quite 'power user' stuff, likely to be of concern to only a small minority - but if the example of SM is anything to go by, FlowStone will end up getting used in ways that DSPr never dreamed of (I hope so!). So it seems odd to process things in this order when there is no apparent disadvantage to doing it the other way around.

[MyCo]

the "Init" method is the FS equivalent of the class constructor (I think it is even called directly from there). And knowing nothing about inputs sounds OK for a constructor.

But I would also wish there would be a more clever way in which the inputs get initialized.

Right now I don't work with Ruby. I reported several things to Malc, and he confirmed that he'll change that in the next update. So the Ruby behaviour will be a little bit different in the future. And for me it doesn't make sense to build workarounds for things that get fixed soon.

[Tronic]

several things? they might know?

[unkargherth]

Right now I don't work with Ruby. I reported several things to Malc, and he confirmed that he'll change that in the next update. So the Ruby behaviour will be a little bit different in the future. And for me it doesn't make sense to build workarounds for things that get fixed soon.

What you mean soon? Isn't the update policy once a year?

[trogluddite]

And knowing nothing about inputs sounds OK for a constructor.

Hmm, yes. I can see where you're coming from - but I think that putting Ruby inside the context of FS changes things a bit. The trouble is that some input values are dynamic (calls of a RubyEdit method, if you like), but others, like 'properties' settings are static, and I'd see those almost as arguments of the constructor, e.g....
RubyEdit.new (property1,property2..) (metaphorically speaking).
But of course, the FS input values don't make that distinction between dynamic and static values. So it seems to me that the stored input array should default to being available to the constructor - dynamic values are free to update the startup values any time they like, so I can't see what harm it would do, even though it is not strictly the 'Ruby ethos'.

More importantly, every effort needs to be made to make Ruby work inside FS without confusing people - and the current execution order makes it all too easy to generate errors due to undeclared variables. "This is the routine that only runs once at the start" is a lot easier for people to understand than the concept of a class constructor, especially as we never explicitly construct instances by calling "RubyEdit.new" ourselves.

Thanks for your comments BTW. I posted rather than hassling Malc again straight away precisely because I wanted a second opinion - especially from folks that understand Ruby a bit better than I do!

Anyhow - enough ranting for one day! I've exchanged e-mails with Malc a few times myself, and he has been very receptive regarding the niggles and suggestions that I've put forward - so the signs are good that our feedback will lead to some very useful changes for the first update.

[trogluddite]

What you mean soon? Isn't the update policy once a year?

No,no. There are two different licences.
The cheaper one just buys you the software as it is - with that one you get no upgrades unless you decide to pay for them later.
But if you upgraded from SM, or paid the extra for the 'annual upgrade' thingy, you get incremental upgrades throughout the year whenever there's anything new from the dev's. And at the end of the year, you don't pay for another full licence, you just 'top up' your upgrade policy.