How does one use the debugger?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

How does one use the debugger?

Stephen-71
Hi All,

Could someone give me a hint on how to use the debugger please.

I tried this to see what would happen..
| db a b |
a := b := 1.
db := Debugger on:
   [a := 5.
   b := 6.] newProcess.
a displayNl.
db step.
a displayNl.

However no change to a.

In any case, the code above isn't interactive.

Also found MiniDebugger which has menu options with exactly the
functions I want, and is interactive. Is this working (the code has old
formatting) and if so, how does one use it?

Thanks
Stephen

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: How does one use the debugger?

Paolo Bonzini-2
On 10/23/2010 12:37 PM, Stephen wrote:
> Hi All,
>
> Could someone give me a hint on how to use the debugger please.
>
> I tried this to see what would happen..
| db a b |
a := b := 1.
db := Debugger on:
[a := 5.
b := 6.] newProcess.
a displayNl.
db step.
a displayNl.
>
> However no change to a.

You are not waiting enough. :)

First of all, there is some book-keeping to do before starting the process,
so it will take 3 step invocations just to reach your block.  After that,
remember that variables in the REPL are actually globals so they have to go
through the hashed collection machinery.  Better to use "next".  For example:

db := Debugger on: ([ 'now do next' basicPrint.
a := 5.
b := 6 ] newProcess).
db step
db step
db step          "prints Object: 'now do next'"
db next
a                "prints 5"
b                "prints nil"
db step
db process suspendedContext "prints DeferredVariableBinding>>value:"
b                "prints nil"
db finish
b                "prints 6"

> In any case, the code above isn't interactive.

Yes, the Debugger class implements the tools to step through a controlled process, and to attach to a running process.

> Also found MiniDebugger which has menu options with exactly the
> functions I want, and is interactive. Is this working (the code has old
> formatting) and if so, how does one use it?

Just load it in the image with "gst -Kexamples/MiniDebugger.st -S".

$ gst -Kexamples/MiniDebugger.st -S
"Global garbage collection... done"
Loading package DebugTools
"Global garbage collection... done"
$ gst
st> self halt
Eval [ self halt. 100 factorial ]
'nil error: halt encountered'
Halt(Exception)>>signal (ExcHandling.st:254)
Halt(Exception)>>signal: (ExcHandling.st:264)
UndefinedObject(Object)>>halt: (SysExcept.st:1423)
UndefinedObject(Object)>>halt (Object.st:1325)
UndefinedObject>>executeStatements (a String:1)
      6         ^self activateHandler: (onDoBlock isNil and: [ self isResumable ])
(debug) f 4
UndefinedObject>>executeStatements (a String:1)
      1 self halt. 100 factorial
(debug) s
SmallInteger(Integer)>>factorial (Integer.st:246)
      1 factorial [
(debug) c
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000


Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: How does one use the debugger?

Stephen-71

Thanks Paolo

I ran through the examples as per your post and got the same results.
Good examples.

So now I have a question about workflow when debugging.

I normally call GST with a list of files at the command line, and
sprinkle in displayNl output as required. So to try out debugging, I
first tried adding MiniDebugger.st to the file list, and put a "self
halt" into my test framework, then stepped as per your post. This didn't
work for me; as when it halted none of my code was visible. See output
below.

OK, so it seems one should run the debugger interactively from gst just
as you have done in both your examples. So then I did the following:-
$ gst -i -S -I ./gst.im -Kexamples/MiniDebugger.st  ./BER.st ./Core.st
./Exceptions.st ./Filters.st ./Tests.st
$ gst -I ./gst.im

It works, but every time I need to change the breakpoint or alter code,
I have to go out of the interactive gst, generate a new image, and then
run interactive gst again. Its still useful having the ability to step,
but just checking that there isn't a simpler way.

Thanks for the examples
Stephen

------------------------------
Test to see if I can run gst from the command line and have it stop at a
'self halt' and allow me to debug...

$] cat ./Tests2.st
   tester := LDAPTest new.
   self halt.
   'debug now' displayNl.
   tester testBind.
------

I ran the line below and got the following output
$ gst -i -S -I ./gst.im -Kexamples/MiniDebugger.st  ./BER.st ./Core.st
./Exceptions.st ./Filters.st ./Tests2.st
"Global garbage collection... done"
Loading package DebugTools
Loading package Sockets
Loading package SUnit
'nil error: halt encountered'
Halt(Exception)>>signal (ExcHandling.st:254)
Halt(Exception)>>signal: (ExcHandling.st:264)
UndefinedObject(Object)>>halt: (SysExcept.st:1423)
UndefinedObject(Object)>>halt (Object.st:1325)
UndefinedObject>>executeStatements (Tests2.st:602)
       6         ^self activateHandler: (onDoBlock isNil and: [ self
isResumable ])
(debug) f 4
UndefinedObject>>executeStatements (Tests2.st:602)
       1 self halt.
(debug) s
UndefinedObject>>__terminate (source not available:0)
(debug) x

Didn't work. Looks like one has to put the classes required in an image,
and then run up gst interactively as described above..


On 24/10/10 12:54 AM, Paolo Bonzini wrote:

> On 10/23/2010 12:37 PM, Stephen wrote:
>> Hi All,
>>
>> Could someone give me a hint on how to use the debugger please.
>>
>> I tried this to see what would happen..
> | db a b |
> a := b := 1.
> db := Debugger on:
> [a := 5.
> b := 6.] newProcess.
> a displayNl.
> db step.
> a displayNl.
>>
>> However no change to a.
>
> You are not waiting enough. :)
>
> First of all, there is some book-keeping to do before starting the process,
> so it will take 3 step invocations just to reach your block.  After that,
> remember that variables in the REPL are actually globals so they have to go
> through the hashed collection machinery.  Better to use "next".  For example:
>
> db := Debugger on: ([ 'now do next' basicPrint.
> a := 5.
> b := 6 ] newProcess).
> db step
> db step
> db step          "prints Object: 'now do next'"
> db next
> a                "prints 5"
> b                "prints nil"
> db step
> db process suspendedContext "prints DeferredVariableBinding>>value:"
> b                "prints nil"
> db finish
> b                "prints 6"
>
>> In any case, the code above isn't interactive.
>
> Yes, the Debugger class implements the tools to step through a controlled process, and to attach to a running process.
>
>> Also found MiniDebugger which has menu options with exactly the
>> functions I want, and is interactive. Is this working (the code has old
>> formatting) and if so, how does one use it?
>
> Just load it in the image with "gst -Kexamples/MiniDebugger.st -S".
>
> $ gst -Kexamples/MiniDebugger.st -S
> "Global garbage collection... done"
> Loading package DebugTools
> "Global garbage collection... done"
> $ gst
> st>  self halt
> Eval [ self halt. 100 factorial ]
> 'nil error: halt encountered'
> Halt(Exception)>>signal (ExcHandling.st:254)
> Halt(Exception)>>signal: (ExcHandling.st:264)
> UndefinedObject(Object)>>halt: (SysExcept.st:1423)
> UndefinedObject(Object)>>halt (Object.st:1325)
> UndefinedObject>>executeStatements (a String:1)
>        6         ^self activateHandler: (onDoBlock isNil and: [ self isResumable ])
> (debug) f 4
> UndefinedObject>>executeStatements (a String:1)
>        1 self halt. 100 factorial
> (debug) s
> SmallInteger(Integer)>>factorial (Integer.st:246)
>        1 factorial [
> (debug) c
> 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
>
>
> Paolo
>


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: How does one use the debugger?

Paolo Bonzini-2
On 10/26/2010 10:22 AM, Stephen Woolerton wrote:
> It works, but every time I need to change the breakpoint or alter code,
> I have to go out of the interactive gst, generate a new image, and then
> run interactive gst again. Its still useful having the ability to step,
> but just checking that there isn't a simpler way.

Yes, there is no "edit method" in the MiniDebugger.  It's mostly useful
to step and inspect objects when you get an exceptions.  I rarely use
"self halt" even with the browser anyway. :)

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: How does one use the debugger?

Paolo Bonzini-2
In reply to this post by Stephen-71
On 10/26/2010 10:22 AM, Stephen Woolerton wrote:

>
> ------------------------------
> Test to see if I can run gst from the command line and have it stop at a
> 'self halt' and allow me to debug...
>
> $] cat ./Tests2.st
>    tester := LDAPTest new.
>    self halt.
>    'debug now' displayNl.
>    tester testBind.
> ------


Ah, missed this.

All statements in doits are ran independently by default.  You need to
wrap it with

Eval [
     tester := LDAPTest new.
     self halt.
     'debug now' displayNl.
     tester testBind.
]

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk