10:30 a.m.
Hello:
I receive the error message in the attached picture whenever I try to estimate a SVAR in
some sessions files where I have already estimated an saved a SVAR model. Do you know
why?
11:43 a.m.
Am 16.02.2018 um 16:30 schrieb Olivo Victor:
Hello:
I receive the error message in the attached picture whenever I try to
estimate a SVAR in some sessions files where I have already estimated
an saved a SVAR model. Do you know why?
Hi Olivo, I have a suspicion, but not (yet) an idea on how to work
around that. Could you tell us more precisely what you are doing when
you estimate and save a SVAR model? Do you use the SVAR addon (if you
know what that means)? How do you save the model to the session? Could
you perhaps even send the session file (if it's not too large for the
list, I think 200KB is the limit)?
thanks,
sven
5:16 p.m.
On Fri, 16 Feb 2018, Olivo Victor wrote:
Hello:
I receive the error message in the attached picture whenever I try
to estimate a SVAR in some sessions files where I have already
estimated an saved a SVAR model. Do you know why?
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.
Then if you reopen the session and do "include SVAR.gfn" gretl
reckons you're trying to overwrite the functions already in memory
(restored from the session file) with some alien versions, and
doesn't like that.
I think this should probably be considered a bug, and we'll think
about how best to fix it, but as a workaround, you could try _not_
doing "include SVAR.gfn" after reopening the session file, since the
SVAR functions should in fact be present already.
Allin Cottrell
10:20 a.m.
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?
cheers,
sven
2:49 p.m.
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
3:57 p.m.
On Sat, 17 Feb 2018, Allin Cottrell wrote:
> 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.
I guess that we might make a distinction here between regular packages
and addons. A function from an addon should always be available (bar
version changes, of course), whereas a function from a package is only
avalable if the user installed that package on the machine that he/she is
using to open the session file. Not sure if this is relevant, though.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
5:01 p.m.
What if saving session dialogue would have
an option "whether to run include relevant_packages.gfn
on the next gretl session?
Oleh
17 лютого 2018, 22:58:37, від "Riccardo (Jack) Lucchetti"
<r.lucchetti(a)univpm.it>:
On Sat, 17 Feb 2018, Allin Cottrell wrote:
> 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.
I guess that we might make a distinction here between regular packages
and addons. A function from an addon should always be available (bar
version changes, of course), whereas a function from a package is only
avalable if the user installed that package on the machine that he/she is
using to open the session file. Not sure if this is relevant, though.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
7:26 a.m.
Am 17.02.2018 um 20:49 schrieb Allin Cottrell:
On Sat, 17 Feb 2018, Sven Schreiber wrote:
> 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.
> 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.
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.
Hm, I see.
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.
Right. That sounded very complicated, but maybe it's not, given that in
functions.xml (inside the session file) the functions already appear in
context with their owning packages.
I'm wondering about different package versions, though. Say I have an
old session file with embedded package foo.gfn version 0.1. In the
meantime the package is at version 2.5. If I load the session and then
do 'include foo.gfn', what is supposed to happen? Always load the latest
available package version and replace the older function versions? (In
memory I mean, not in the session file.) That would mean to tell users
not to do 'include' if they want to rely on the function versions
embedded in the session file.
Or a switch could be added to 'include' that clarifies this. Like
--keep-old or something.
cheers,
sven
2419
days inactive
2421
days old
7 comments
5 participants
participants (5)
-
Allin Cottrell -
oleg_komashko＠ukr.net -
Olivo Victor -
Riccardo (Jack) Lucchetti -
Sven Schreiber