Variables Data in Profile save file located and read after Lua code that may use them is compiled

[Stephen Lyons]

The <VariablePackage>...</VariablePackage> element of the XML file data used to store the profile data between session is located and thus parsed AFTER the other members which contain Lua script elements that may require the variables that are contained within (the ones in a session that the user has marked as to be "Saved" between sessions). This effect may be (erroneously) masked by code that checks for and initialises such variables if it is *executed* before the real variable is read from the file, but perhaps NOT if it is just *compiled* {by which I mean the compilation system examines the code to deduce what data storage is required} in that case the absence of the required variable will just trigger a Lua syntax error about using a non-existent (nil) global variable - which would show up as a bug initially but disappear after the real variable is read.

However in simple experimenting which attempted to save and thus load the variables BEFORE the other elements of a Mudlet profile - which will be the method to correct this - I encountered an odd error which I could not determine the cause of. In that situation, installed packages would fail to show up in the Editor. The package manager confirmed the presence of the packages but they never seemed to be loaded from the save file, even though a manual inspection showed them present in the file. Note that this refers to packages, in both a single/group of one type of aliases and scripts and presumably (but not checked) buttons/menu/items, keys, timers or triggers, NOT modules.

Although the presentation is very like https://bugs.launchpad.net/mudlet/+bug/1668177 {"Default packages are no longer installed on new profiles (temporary post-iota only)"} that was caused by single line of code in an `else` branch that had been placed in the wrong `if` of a nested 'if' - which does not seem to be the case here - though the mechanism that is invoked could be the same. It is almost as some sub-system has been correctly set up in the case with the variables being loaded last but which has not been initialised before they are. This suggests some part of the variable store which interacts with the Lua subsystem but I have not been able to pin down the cause.

Note that after a profile has been loaded once, variables and compiled functions persist in the Lua system I think; so if a profile is reloaded there is likely to be wanted variables/functions still/already in the system and thus the odd effects and problems are only likely to show up during session start-up.

[Stephen Lyons (slysven)]

There is a related issue, "Scripts" ought to be read/parsed BEFORE other elements that might refer to them, e.g. Aliases/Actions/Keys/Triggers and Timers can all use functions/variables defined in a script so scripts should be loaded AFTER Variables but before these others...

For example the built-in Alias "delete old profiles" makes use of the "deleteOldProfiles(keepdays_arg, delete_maps)" defined in the Script "deleteOldProfiles script" it may be that for *compilation* the parser does not go looking for Lua elements that look like functions that are not "built-in" {I am not a Lua Wizard!} but if it does than I'd expect issues if a "forward reference" to a function that has not yet been defined - OTOH I may have got completely the wrong idea about this...

[Vadim Peretokin (vperetokin)]

Compilation does not resolve run-time functions. For example, take a Lua
script, run it through luac, and it'll run fine. Compilation just helps us
detect syntax errors in scripts.

As far as I know, we don't have any order loading issues in 2.1 and nor in
3.0 except _maybe_ for the variables stuff, which not a lot of people have
made use of yet, and even less would have ticked variables to be saved and
referred to those variables at script startup.

On Wed, Mar 15, 2017 at 5:56 AM Stephen Lyons <email address hidden>
wrote:

> There is a related issue, "Scripts" ought to be read/parsed BEFORE other
> elements that might refer to them, e.g. Aliases/Actions/Keys/Triggers
> and Timers can all use functions/variables defined in a script so
> scripts should be loaded AFTER Variables but before these others...
>
> For example the built-in Alias "delete old profiles" makes use of the
> "deleteOldProfiles(keepdays_arg, delete_maps)" defined in the Script
> "deleteOldProfiles script" it may be that for *compilation* the parser
> does not go looking for Lua elements that look like functions that are
> not "built-in" {I am not a Lua Wizard!} but if it does than I'd expect
> issues if a "forward reference" to a function that has not yet been
> defined - OTOH I may have got completely the wrong idea about this...
>
> --
> You received this bug notification because you are a member of Mudlet
> Makers, which is subscribed to Mudlet.
> https://bugs.launchpad.net/bugs/1671978
>
> Title:
> Variables Data in Profile save file located and read after Lua code
> that may use them is compiled
>
> Status in Mudlet:
> New
>
> Bug description:
> The <VariablePackage>...</VariablePackage> element of the XML file
> data used to store the profile data between session is located and
> thus parsed AFTER the other members which contain Lua script elements
> that may require the variables that are contained within (the ones in
> a session that the user has marked as to be "Saved" between sessions).
> This effect may be (erroneously) masked by code that checks for and
> initialises such variables if it is *executed* before the real
> variable is read from the file, but perhaps NOT if it is just
> *compiled* {by which I mean the compilation system examines the code
> to deduce what data storage is required} in that case the absence of
> the required variable will just trigger a Lua syntax error about using
> a non-existent (nil) global variable - which would show up as a bug
> initially but disappear after the real variable is read.
>
> However in simple experimenting which attempted to save and thus load
> the variables BEFORE the other elements of a Mudlet profile - which
> will be the method to correct this - I encountered an odd error which
> I could not determine the cause of. In that situation, installed
> packages would fail to show up in the Editor. The package manager
> confirmed the presence of the packages but they never seemed to be
> loaded from the save file, even though a manual inspection showed them
> present in the file. Note that this refers to packages, in both a
> single/group of one type of aliases ...

[Vadim Peretokin (vperetokin)]

Migrating issues to Github, please follow the new discussion here: https://github.com/Mudlet/Mudlet/issues/807

This issue needs to be closed and there is no appropriate status, so will set it to "Opinion" just for migration purposes.