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
