Smalltalk Block defined in a Workspace for debugging
I was reading Blaine's ruminations about Blocks
and Objects and how Ruby and Smalltalk manage those two worlds really well, and
was reminded of an old debugging trick/hack I've done before in VisualAge
Smalltalk with Blocks. So here it
is.
The VisualAge Smalltalk debugger allows for interesting snippets of code to be executed as part of the breakpoint definition. For example, instead of putting in true or false as the contents of the breakpoint definition you could put little pieces of code that look like this:
self size > 12
and the debugger will stop when the size of the object is greater than 12. Another simple example is
self inspect. false
Here it becomes more obvious that a Block is being evaluated by the debugger. The code self inspect. will open up an Inspector on the object you are curious about and the false statement tells the debugger not to stop.
All simple stuff that everybody has seen before. But here's a fun one. Open up some Workspace and put in code that looks like this:
Smalltalk at: #Dummy put: [:val |
val inspect.
Transcript show: val size printString; cr.
... other stuff ...
].
Leave your Workspace window open and evaluate it. The global Dummy contains the block of code from the Workspace, not unlike a method on a Class. In the debugger breakpoint definition do this:
Dummy value: self. false
When the debugger encounters the breakpoint it sends the object over to your Block in your Workspace and you can do things with it.
I found this technique handy when I wanted to explore things without stopping because of a web service request or some socket response.
It's a simple trick and quite fun to play around with. Just set it up and starting writing diagnostics in the Workspace.
Oh yea, be a good Image citizen and clean up after yourself. I recommend you toss your Block out when you are done.
Dummy := nil.
The VisualAge Smalltalk debugger allows for interesting snippets of code to be executed as part of the breakpoint definition. For example, instead of putting in true or false as the contents of the breakpoint definition you could put little pieces of code that look like this:
self size > 12
and the debugger will stop when the size of the object is greater than 12. Another simple example is
self inspect. false
Here it becomes more obvious that a Block is being evaluated by the debugger. The code self inspect. will open up an Inspector on the object you are curious about and the false statement tells the debugger not to stop.
All simple stuff that everybody has seen before. But here's a fun one. Open up some Workspace and put in code that looks like this:
Smalltalk at: #Dummy put: [:val |
val inspect.
Transcript show: val size printString; cr.
... other stuff ...
].
Leave your Workspace window open and evaluate it. The global Dummy contains the block of code from the Workspace, not unlike a method on a Class. In the debugger breakpoint definition do this:
Dummy value: self. false
When the debugger encounters the breakpoint it sends the object over to your Block in your Workspace and you can do things with it.
I found this technique handy when I wanted to explore things without stopping because of a web service request or some socket response.
It's a simple trick and quite fun to play around with. Just set it up and starting writing diagnostics in the Workspace.
Oh yea, be a good Image citizen and clean up after yourself. I recommend you toss your Block out when you are done.
Dummy := nil.
Posted: Wednesday - November 29, 2006 at 07:46 PM |
Quick Links
Statistics
Total entries in this blog:
Total entries in this category:
Published On: Jan 19, 2008 09:36 PM
Total entries in this category:
Published On: Jan 19, 2008 09:36 PM