10:09 a.m.
Hi,
could it be (Apr 11th snapshot) that gretl isn't always
re-reading/re-loading functions from included scripts that have been edited?
I got a (correct) error message about 'N' being undefined, then I
inserted a definition for N (in the external function/script), but I
still get the same error message. I made sure to set my working
directory to the one where these scripts all live.
BTW, I also noticed that in this case gretl didn't spit out the nested
hierarchy of functions called before getting to the error, as it usually
(sometimes?) does.
thanks,
sven
10:16 a.m.
On Fri, 14 Apr 2017, Sven Schreiber wrote:
Hi,
could it be (Apr 11th snapshot) that gretl isn't always re-reading/re-loading
functions from included scripts that have been edited?
I got a (correct) error message about 'N' being undefined, then I inserted a
definition for N (in the external function/script), but I still get the same
error message. I made sure to set my working directory to the one where these
scripts all live.
BTW, I also noticed that in this case gretl didn't spit out the nested
hierarchy of functions called before getting to the error, as it usually
(sometimes?) does.
Not reloading the file is unlikely.
I think it's more plausible that you have two copies of the same file in
different locations. Commands like "open", "include" etc follow some
heuristic rules in order to pick the directory you most likely mean, and
it could well be that the file you're including is not the one you've
edited.
If my guess is correct, specifying the full path of your file should solve
the problem.
-------------------------------------------------------
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
-------------------------------------------------------
10:56 a.m.
Am 14.04.2017 um 12:16 schrieb Riccardo (Jack) Lucchetti:
I think it's more plausible that you have two copies of the same
file in
different locations. Commands like "open", "include" etc follow some
heuristic rules in order to pick the directory you most likely mean, and
it could well be that the file you're including is not the one you've
edited.
If my guess is correct, specifying the full path of your file should
solve the problem
The thing is, when I restart gretl then it works. If I was really
picking the wrong file, then this mistake should stay the same across
restarts, no?
This isn't happening all the time (in fact most of the time it's OK), so
it's very hard to give a minimal or reproducible example. I thought the
fact that gretl isn't reporting the function call chain there might
helpt to find the problem.
thanks,
sven
6:23 p.m.
On Fri, 14 Apr 2017, Sven Schreiber wrote:
Am 14.04.2017 um 12:16 schrieb Riccardo (Jack) Lucchetti:
> I think it's more plausible that you have two copies of the same file in
> different locations. Commands like "open", "include" etc follow
some
> heuristic rules in order to pick the directory you most likely mean, and it
> could well be that the file you're including is not the one you've edited.
>
> If my guess is correct, specifying the full path of your file should solve
> the problem
The thing is, when I restart gretl then it works. If I was really picking the
wrong file, then this mistake should stay the same across restarts, no?
This isn't happening all the time (in fact most of the time it's OK), so it's
very hard to give a minimal or reproducible example. I thought the fact that
gretl isn't reporting the function call chain there might helpt to find the
problem.
I can't think of any recent changes that might affect this behavior.
However, here's a possibly semi-relevant point: when "include" is
used in a script with a gfn argument (only), gretl checks to see if
the function package in question is already loaded, and if so the
package file is not re-read. I've just added a --force option for
"include" which will force re-reading from file regardless.
(Note that if you're working on a package in the GUI, then when you
save your changes this forces an update of the package in memory; in
that context the precise behaviour of "include" doesn't matter.)
Allin
3:12 p.m.
Am 14.04.2017 um 20:23 schrieb Allin Cottrell:
However, here's a possibly semi-relevant point: when
"include" is used
in a script with a gfn argument (only), gretl checks to see if the
function package in question is already loaded, and if so the package
file is not re-read. I've just added a --force option for "include"
which will force re-reading from file regardless.
Just a feedback that this new --force option is very useful when
testing/debugging packages!
thanks,
sven
4:07 p.m.
Am 18.04.2017 um 17:12 schrieb Sven Schreiber:
Am 14.04.2017 um 20:23 schrieb Allin Cottrell:
> However, here's a possibly semi-relevant point: when "include" is used
> in a script with a gfn argument (only), gretl checks to see if the
> function package in question is already loaded, and if so the package
> file is not re-read. I've just added a --force option for "include"
> which will force re-reading from file regardless.
Just a feedback that this new --force option is very useful when
testing/debugging packages!
And I just had an example where I replaced the old version of a function
package with a new one (unzipped zip into gfn et al.). By looking
directly into the gfn with a text editor I made sure it was the new
version (had changes).
And then in the GUI (with 2017a on Windows) I chose in the
function-package list window the corresponding directory (via the folder
button), which showed me the package. Then right-clicking and opening
the info script I got the old (outdated) content.
So I think gretl is not --force-reloading the package file when I
manually select a package location; perhaps it should.
thanks,
sven
4:27 p.m.
On Fri, 14 Apr 2017, Sven Schreiber wrote:
Hi,
could it be (Apr 11th snapshot) that gretl isn't always re-reading/re-loading
functions from included scripts that have been edited?
I got a (correct) error message about 'N' being undefined, then I inserted a
definition for N (in the external function/script), but I still get the same
error message. I made sure to set my working directory to the one where these
scripts all live.
BTW, I also noticed that in this case gretl didn't spit out the nested
hierarchy of functions called before getting to the error, as it usually
(sometimes?) does.
Sven, is the file in question plain .inp, or .gfn? And is the
command you're using "include" or "run"? And am I right in
assuming
you're using the GUI program?
Thanks,
Allin
11:14 a.m.
Am 14.04.2017 um 18:27 schrieb Allin Cottrell:
On Fri, 14 Apr 2017, Sven Schreiber wrote:
> could it be (Apr 11th snapshot) that gretl isn't always
> re-reading/re-loading functions from included scripts that have been
> edited?
> BTW, I also noticed that in this case gretl didn't spit out
the nested
> hierarchy of functions called before getting to the error, as it
> usually (sometimes?) does.
Sven, is the file in question plain .inp, or .gfn? And is the command
you're using "include" or "run"? And am I right in assuming
you're using
the GUI program?
It's .inp (I already realized at another occasion that an edited gfn
isn't re-read in the same session, but I thought that was understandable
--not a bug-- and didn't report it). The command is include, and this is
running from the script editor window, yes (not gretlcli).
thanks,
sven
2:07 p.m.
On Sat, 15 Apr 2017, Sven Schreiber wrote:
Am 14.04.2017 um 18:27 schrieb Allin Cottrell:
> On Fri, 14 Apr 2017, Sven Schreiber wrote:
>> could it be (Apr 11th snapshot) that gretl isn't always
>> re-reading/re-loading functions from included scripts that have been
>> edited?
>> BTW, I also noticed that in this case gretl didn't spit out the nested
>> hierarchy of functions called before getting to the error, as it usually
>> (sometimes?) does.
>
> Sven, is the file in question plain .inp, or .gfn? And is the command
> you're using "include" or "run"? And am I right in assuming
you're using
> the GUI program?
It's .inp (I already realized at another occasion that an edited gfn isn't
re-read in the same session, but I thought that was understandable --not a
bug-- and didn't report it). The command is include, and this is running from
the script editor window, yes (not gretlcli).
Thanks, Sven. I ran an experiment on this as follows:
Open two .inp files in the script editor: one that defines a
function and another that includes the first and calls the
function. Put a deliberate error in the function, run the caller:
error. Fix the error in the function script and save it. Run the
caller: no error. Reinstate the error and save, run caller: error.
And so on for a few iterations. So all OK.
However... when I first tried this I thought I had replicated the
problem you describe: kept on getting the "the error" even after
correcting and saving the function script! Then I realized that
there was an error in the caller that happened to "mimic" the
deliberate one in the function script, in that the undefined symbol
had the same name in each case. I wonder if that is what's happening
in your case. That would explain the absence of any call-stack
information in the error message.
Allin
5:29 p.m.
Am 15.04.2017 um 16:07 schrieb Allin Cottrell:
However... when I first tried this I thought I had replicated the
problem you describe: kept on getting the "the error" even after
correcting and saving the function script! Then I realized that there
was an error in the caller that happened to "mimic" the deliberate one
in the function script, in that the undefined symbol had the same name
in each case. I wonder if that is what's happening in your case. That
would explain the absence of any call-stack information in the error
message.
That would explain it, but again: why would it then have worked without
changing anything after a gretl restart?
The whole thing is no big deal. But would you confirm that in theory
gretl reads in file.inp every time that "include file.inp" is found? Or
is there some case like with gfn files where this isn't done (on purpose)?
thanks,
sven
5:52 p.m.
On Sat, 15 Apr 2017, Sven Schreiber wrote:
Am 15.04.2017 um 16:07 schrieb Allin Cottrell:
>
> However... when I first tried this I thought I had replicated the problem
> you describe: kept on getting the "the error" even after correcting and
> saving the function script! Then I realized that there was an error in the
> caller that happened to "mimic" the deliberate one in the function script,
> in that the undefined symbol had the same name in each case. I wonder if
> that is what's happening in your case. That would explain the absence of
> any call-stack information in the error message.
That would explain it, but again: why would it then have worked without
changing anything after a gretl restart?
Sorry, don't know.
The whole thing is no big deal. But would you confirm that in theory
gretl
reads in file.inp every time that "include file.inp" is found? Or is there
some case like with gfn files where this isn't done (on purpose)?
The former: file.inp should always be read in when it's the argument
to "include" or "run", and it's a bug if that ever doesn't
happen.
Allin
9:24 p.m.
On Sat, 15 Apr 2017, Allin Cottrell wrote:
Open two .inp files in the script editor: one that defines a
function and another that includes the first and calls the
function. Put a deliberate error in the function, run the caller:
error. Fix the error in the function script and save it. Run the
caller: no error. Reinstate the error and save, run caller: error.
And so on for a few iterations. So all OK.
However... when I first tried this I thought I had replicated the
problem you describe: kept on getting the "the error" even after
correcting and saving the function script! Then I realized that
there was an error in the caller that happened to "mimic" the
deliberate one in the function script, in that the undefined
symbol had the same name in each case.
P.S. keep in mind "set debug 2" if you want to see explicitly what's
going on with levels of function execution.
<sample-output>
? include functest.inp
/home/allin/gretl-git/build/cli/functest.inp
? set debug 2
? scalar z = 5
Generated scalar z = 5
? eval foo(z)
*** executing function foo
? # N = 7
? return x*N
*** exiting function foo, returning to main
The symbol 'N' is undefined
*** error in function foo, line 2
x*N
</sample-output>
Allin
2827
days inactive
2838
days old
11 comments
3 participants
participants (3)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber