10:26 p.m.
Now that Chris is back from holiday, I'll mention this: I've
merged his function debugger code.
It's very nice. If you want to debug your user-defined function
foo, you construct a script that calls it (well, this is one way
of doing it). Within that script you say
debug foo
Then you run the script using gretlcli. [Comment on the GUI
appears below.]
The "debug" command should come after foo is defined but before
it's called. Then when a call to foo is reached, you get an
interactive prompt at which you can:
- type "n" or "next" to execute the next gretl command in foo
- type another gretl command (most likely a "print" to see
what's happening with some variable)
- type "c" or "continue" to allow foo to continue unimpeded
It would be nice to enable this behaviour within the GUI console
but that's not trivial. The code in gui2/console.c would have to
be re-written quite substantially to allow it to work. I've made
one false start on this myself (since erased from CVS) and I need
to think about it more carefully before trying again.
Allin.
3:34 p.m.
Allin Cottrell wrote:
Now that Chris is back from holiday, I'll mention this: I've
merged his function debugger code.
That's nice! Thank you for the cleanup!
It would be nice to enable this behaviour within the GUI console
but that's not trivial. The code in gui2/console.c would have to
be re-written quite substantially to allow it to work. I've made
one false start on this myself (since erased from CVS) and I need
to think about it more carefully before trying again.
I think for basic debugging the implementation within gretlcli is
sufficient. The problem with supporting debugging in the gui client is
the callback function to read user commands. I had two ideas about this,
which would put this problem into a wider context:
1. We could add a new function to enable scripts to interact with the
user. A new function, let's say readinput, could read input from the
console. This way the user could alter the execution flow while the
script is running. If we had this facility in place we could use it for
the debugger, too.
2. Perhaps debugging via a console prompt is not sufficient for
gretl_gui users. Perhaps we could open a second instance of the gretl
main window when a function is debugged. Within this window one could
see all series, matrices, etc defined in this function. This way users
would debug function using the same guithey use for normal operations.
Just my thoughts on this. I hope to write some sample code for this in
the next weeks.
Christoph
8:41 p.m.
On Mon, 20 Jul 2009, chris wrote:
Allin Cottrell wrote:
> Now that Chris is back from holiday, I'll mention this: I've
> merged his function debugger code.
>
That's nice! Thank you for the cleanup!
> It would be nice to enable this behaviour within the GUI console
> but that's not trivial. The code in gui2/console.c would have to
> be re-written quite substantially to allow it to work. I've made
> one false start on this myself (since erased from CVS) and I need
> to think about it more carefully before trying again.
>
I think for basic debugging the implementation within gretlcli is
sufficient. The problem with supporting debugging in the gui client is
the callback function to read user commands. I had two ideas about this,
which would put this problem into a wider context:
1. We could add a new function to enable scripts to interact with the
user. A new function, let's say readinput, could read input from the
console. This way the user could alter the execution flow while the
script is running. If we had this facility in place we could use it for
the debugger, too.
2. Perhaps debugging via a console prompt is not sufficient for
gretl_gui users. Perhaps we could open a second instance of the gretl
main window when a function is debugged. Within this window one could
see all series, matrices, etc defined in this function. This way users
would debug function using the same guithey use for normal operations.
These ideas sound good. I now have a basic version of debugging
in the gui console in a semi-usable state; it needs some fixes but
the proof of concept is there. I needed a second debugging
callback function to flush output in the GUI case.
Allin.
5392
days inactive
5394
days old
2 comments
2 participants
participants (2)
-
Allin Cottrell -
chris