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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |