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