As my next step in learning Squeak, I thought I would try to enhance the EToy Outliner widget. However, as soon as I started to do this I realised that I didn't really know how to 'grok' the code. So, when the experts in this list, are faced with a new application, how do you go about understanding it? Do you draw out object diagrams, open lots of source browsers, or do other clever things?
The reason I am asking is that, at the moment, I find that I am jumping around the system browser looking up all sorts of objects/methods etc., in what feels like a very disorganised way, trying to piece together what actually happens. I am sure there must be a better way to tackle this.
Also, I don't really understand how to trace a Squeak application. I imagine I could put lots of 'Transcript show:'s into the code, but again, I feel there must be a better way. Is it possible to run the code in debug mode?
Thanks for any advice you guys can offer
Cheers AB
Hi Andy,
One useful trick is to put a "self halt." somewhere in the code you want to analyze. Then when you run the code the debugger will stop at that point, and you can start stepping through the code. Of course the debugger provides access to real objects, so you can inspect anything, evaluate expressions within the debugger, and modify code on the fly.
Hope that helps.
Oscar
On Feb 8, 2008, at 13:32, Andy Burnett wrote:
Also, I don't really understand how to trace a Squeak application. I imagine I could put lots of 'Transcript show:'s into the code, but again, I feel there must be a better way. Is it possible to run the code in debug mode?
Andy,
(What is Etoy Outliner?)
As Oscar wrote, examining the "live" application is the best way. Insert a breakpoints by putting "self halt." into an event handler/callback method of an application and, say, press the button that invokes it. You can step through it while looking at the actual values of the application. And put some expression there and do "debug it"; if you do it carefully, you can effectively try the "what-if" cases quickly.
Also, you can just inspect it. Alt-click on the widget to get "halo". Near top-right there is a gray "handle" for bringing up the debug menu for it. Let's say you choose "explore morph" and see how objects are connected each other.
Of course, the static information is important. The menu item "class refs (N)" in the context menu for the lass pane of browser is handy when you would like to know the relationship of classes.
-- Yoshiki
At Fri, 8 Feb 2008 12:32:07 +0000, Andy Burnett wrote:
[1 <multipart/alternative (7bit)>] [1.1 <text/plain; ISO-8859-1 (7bit)>]
[1.2 <text/html; ISO-8859-1 (7bit)>] As my next step in learning Squeak, I thought I would try to enhance the EToy Outliner widget. However, as soon as I started to do this I realised that I didn't really know how to 'grok' the code. So, when the experts in this list, are faced with a new application, how do you go about understanding it? Do you draw out object diagrams, open lots of source browsers, or do other clever things?
The reason I am asking is that, at the moment, I find that I am jumping around the system browser looking up all sorts of objects/methods etc., in what feels like a very disorganised way, trying to piece together what actually happens. I am sure there must be a better way to tackle this.
Also, I don't really understand how to trace a Squeak application. I imagine I could put lots of 'Transcript show:'s into the code, but again, I feel there must be a better way. Is it possible to run the code in debug mode?
Thanks for any advice you guys can offer
Cheers AB
[2 <text/plain; us-ascii (7bit)>] _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
beginners@lists.squeakfoundation.org
-
Andy Burnett -
Oscar Nierstrasz -
Yoshiki Ohshima