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