On Sat, 17 Feb 2018, Sven Schreiber wrote:
Am 16.02.2018 um 23:16 schrieb Allin Cottrell:
> Here's what I think is happening: when gretl saves your session, it saves
> all the functions that were active at the time, including any functions
> supplied by SVAR, in a sort of "pseudo-package" named functions.xml.
> I think this should probably be considered a bug, and we'll think about how
> best to fix it,
I'd actually go so far as to say that saving the functions to a session file
in the first place is already a mistake. In 2012 you (Allin) said on this
list: "Mixing the use of session files with scripting is not
something we'd want to encourage."
It has been explained (to me and others) that the session concept is a GUI
thing. I don't see why contributed functions need to be saved in there. I
would just end this practice, and the problem of this thread would not
appear. Or what am I missing?
Well, maybe you're right, but here's the sort of thing you may be
missing. Suppose I save an SVAR result "as an icon" then save my
session. I (or perhaps someone else) later opens the saved session
file, and double-clicks on the icon. This should result in a call to
the SVAR bundle-printer function. (And the same goes for contributed
packages, not just addons.) Will the function be available? We don't
really know, unless we bundle the relevant functions into the
session file.
True, the session file is inherently a GUI thing, but ideally it
should be a snapshot of the state of gretl at the time of saving, so
you could open the file later and pick up where you left off -- or,
in principle, send the file to someone else, who could reconstitute
your gretl state without having to load any other files.
One thing is clear: _if_ we're going to save loaded functions in the
session file, we have to mark the ones that belong to specific
packages as owned by those packages so we don't get false-positive
conflicts.
Allin