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.

** Bug watch added: github.com/Mudlet/Mudlet/issues #807
   https://github.com/Mudlet/Mudlet/issues/807

** Changed in: mudlet
       Status: New => Opinion

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

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

_______________________________________________
Mailing list: https://launchpad.net/~mudlet-makers
Post to     : mudlet-makers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mudlet-makers
More help   : https://help.launchpad.net/ListHelp

Reply via email to