mudlet-makers team mailing list archive

[Stephen Lyons <slysven@xxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: mudlet
     Importance: Undecided
         Status: New

** Description changed:

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

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