4:08 p.m.
Hi,
I just had to debug a script which failed with a generic "data error".
Gretl correctly indicated the failing line "k++", but it took me a while
to find out that k was undefined at that point. If the error message had
been "unknown object 'k'", it would have been much easier.
thanks
sven
4:08 a.m.
On Tue, 5 Oct 2021, Sven Schreiber wrote:
Hi,
I just had to debug a script which failed with a generic "data error".
Gretl correctly indicated the failing line "k++", but it took me a while
to find out that k was undefined at that point. If the error message had
been "unknown object 'k'", it would have been much easier.
Uhm. We do catch that special case: it's the "else" branch in
undefined_symbol_error() from lib/src/genlex.c, where we store the
appropriate message string into the parser struct. The trouble is, it
doesn't get printed, for some reason.
-------------------------------------------------------
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:14 a.m.
Am 06.10.2021 um 10:08 schrieb Riccardo (Jack) Lucchetti:
On Tue, 5 Oct 2021, Sven Schreiber wrote:
> Hi,
> I just had to debug a script which failed with a generic "data error".
> Gretl correctly indicated the failing line "k++", but it took me a while
> to find out that k was undefined at that point. If the error message had
> been "unknown object 'k'", it would have been much easier.
Uhm. We do catch that special case: it's the "else" branch in
undefined_symbol_error() from lib/src/genlex.c, where we store the
appropriate message string into the parser struct. The trouble is, it
doesn't get printed, for some reason.
Hm, my guess would rather be that undefined_symbol_error() isn't reached
in this post-incrementation case?
The only evidence I have, though, is that in other cases I get the
message "symbol foo is undefined" alright.
thanks
sven
5:54 a.m.
Am 06.10.2021 um 11:14 schrieb Sven Schreiber:
Am 06.10.2021 um 10:08 schrieb Riccardo (Jack) Lucchetti:
>
> Uhm. We do catch that special case: it's the "else" branch in
> undefined_symbol_error() from lib/src/genlex.c, where we store the
> appropriate message string into the parser struct. The trouble is, it
> doesn't get printed, for some reason.
Hm, my guess would rather be that undefined_symbol_error() isn't reached
in this post-incrementation case?
The only evidence I have, though, is that in other cases I get the
message "symbol foo is undefined" alright.
BTW, the informative error message is also there when doing "eval b++"
or "print b++".
-s
6:26 a.m.
Am 06.10.2021 um 10:08 schrieb Riccardo (Jack) Lucchetti:
On Tue, 5 Oct 2021, Sven Schreiber wrote:
> Hi,
> I just had to debug a script which failed with a generic "data error".
> Gretl correctly indicated the failing line "k++", but it took me a while
> to find out that k was undefined at that point. If the error message had
> been "unknown object 'k'", it would have been much easier.
Uhm. We do catch that special case: it's the "else" branch in
undefined_symbol_error() from lib/src/genlex.c, where we store the
appropriate message string into the parser struct. The trouble is, it
doesn't get printed, for some reason.
Thanks, I see that the right error message appears now.
-sven
1135
days inactive
1139
days old
4 comments
2 participants
participants (2)
-
Riccardo (Jack) Lucchetti -
Sven Schreiber