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