mudlet-makers team mailing list archive

[Stephen Lyons <slysven@xxxxxxxxxxxxxxx>]

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 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mudlet/+bug/1671978/+subscriptions