remembering variables

> Date: Mon, 02 Jun 2008 19:34:36 -0700
> From: Randal L. Schwartz <[hidden email]>
> To: peter h meadows <[hidden email]>
> Cc: [hidden email]
> Subject: Re: [Newbies] remembering variables
>
>>>>>> "peter" == peter h meadows <[hidden email]> writes:
>
> peter> Is there a way to make squeak remember what variables have been set to
> peter> in the past? So as I'm browsing the source it will tell me which type
> peter> of object a variable contained last time that bit of code was running?
>
> Nope, but you can either record the type (maybe write something to Transcript)
> or capture it in the debugger.
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
>

>
> peter> Hummm. How much work would it be to add this ability to the browser? And
> peter> roughly how would I go about it? Thanks.
>
> Because it's not part of a normal development process with smalltalk?
>
> I don't *care* what types things are, as long as they don't throw
> a "does not understand" error when I call various methods with them.
>
> What do you think you'll be doing with the knowledge of "the most recent class
> a variable has been assigned"?  How will you use it in your development?
>

>>>>>> "peter" == peter h meadows <[hidden email]> writes:
>
> peter> Oh. I'm still very new to smalltalk. It seemed like it would help me to
> peter> understand what's going on. I wanted it to remember everything. E.g if
> peter> the thing is an array it will tell me what has been stored in it. Also,
> peter> wouldn't it help with code completion? If it knows what type of object
> peter> it was in the past it can guess which messages I want to send to
> peter> it. That would be useful.
>
> But the problem is that a given type in the past is not any indication of
> a type in the future.
>
> You're not "thinking smalltalk" yet.  Stop worrying about types. :)
>
> Oh, and they aren't types.  They're instances of classes.
>
> If you want to see what's going on, learn to single step in the debugger.
> It's quite informative.
>

> Any ideas? thx.
>
>
>
>>>>>>> "peter" == peter h meadows <[hidden email]> writes:
>>
>> peter> Oh. I'm still very new to smalltalk. It seemed like it would  
>> help me to
>> peter> understand what's going on. I wanted it to remember everything.  
>> E.g if
>> peter> the thing is an array it will tell me what has been stored in  
>> it. Also,
>> peter> wouldn't it help with code completion? If it knows what type of  
>> object
>> peter> it was in the past it can guess which messages I want to send to
>> peter> it. That would be useful.
>>
>> But the problem is that a given type in the past is not any indication  
>> of
>> a type in the future.
>>
>> You're not "thinking smalltalk" yet.  Stop worrying about types. :)
>>
>> Oh, and they aren't types.  They're instances of classes.
>>
>> If you want to see what's going on, learn to single step in the  
>> debugger.
>> It's quite informative.
>>

> Hello Klaus,
>
>
> KDW> Yes, MessageTally does that for you: a tree of message sends. From the Spy
> KDW> results, you can select a class and browse it for more details, or a
> KDW> method and browse its senders or implementors for more details.
>
> interesting idea to use it this way! But MessageTally IMHO only shows
> what it finds on the stack when it peeks. So it can miss some methods
> running seldom and quick.
>
> So you can do MessageTally>>tallySends: [your tallied block] which
> uses the simulator (sloow!!) but gets you everything.
>
> And to be real useful with long class names and deeply nested sends
> one might have to patch some of the class side methods of MessageTally
> in the defaults category.
>
> After looking I see it has become better with 3.9 so the latter
> applies only for 3.8 and older.
>

> Herbert König a écrit :
>> Hello Klaus,
>>
>>
>> KDW> Yes, MessageTally does that for you: a tree of message sends. From the
>> Spy
>> KDW> results, you can select a class and browse it for more details, or a
>> KDW> method and browse its senders or implementors for more details.
>>
>> interesting idea to use it this way! But MessageTally IMHO only shows
>> what it finds on the stack when it peeks. So it can miss some methods
>> running seldom and quick.
>>
>> So you can do MessageTally>>tallySends: [your tallied block] which
>> uses the simulator (sloow!!) but gets you everything.
>>
>> And to be real useful with long class names and deeply nested sends
>> one might have to patch some of the class side methods of MessageTally
>> in the defaults category.
>>
>> After looking I see it has become better with 3.9 so the latter
>> applies only for 3.8 and older.
>>
>
>
> Another possibility well beyond beginners list is the opposite, when you
> want to trace senders call stack rather than sent call tree.
>
> The idea is like putting a halt in a method and debugging, but instead
> of putting a halt, you raise (signal) a Notification in the method(s)
> you want to trace, and instead of a debugger at each send occurence, you
> open a MessageTally for tracing the call stacks of the overall sends.
>
> Create a subclass of Notification for that purpose, say
> YourNotification, and put the sentence:
> YourNotification signal.
> in every method or block you want to trace.
> You can of course raise YourNotification conditionally like say:
> yourConditionsAreFulfilled ifTrue: [YourNotification signal].
>
> Then trap and tally YourNotification with this little code snippet
> (As demonstrated at http://bugs.squeak.org/view.php?id=6755 I used it
> with EndOfStream):
>
>
>
> "INITIALIZE THE TALLY (that is hackish)"
> tally := MessageTally new.
> tally spyEvery: 100 on: ['em ezilaitini ot si siht' reverse].
> tally class: World class method: World class>>#doOneCycle.
>
> "ARM A TIMER TO END THE TALLY"
> tallyEnd := false.
> [(Delay forSeconds: 300) wait. tallyEnd := true] fork.
>
> "EMULATE REGULAR SQUEAK USER ACTIVITY LOOP"
> [[World doOneCycle. Processor yield. tallyEnd] whileFalse]
> "TALLY THE CALL STACK AT EACH SENT OF YOUR METHODS"
>          on: YourNotification
>          do: [:exc | tally tally: exc signalerContext by: 1.
>              exc resume].
>
> "OPEN A WINDOW WITH TALLY CALL STACK RESULTS"
> (StringHolder new contents:
>          (String streamContents: [:s | tally report: s]))
>      openLabel: 'YourNotification Spy Results'.
> tally close.
>
>
>
> You put the code snippet in a workspace and execute it (DoIt).
> Thanks to [World doOneCycle] emulation this enables you to run any
> activity you like during the 300 seconds duration including interactive
> and graphical activity but also running some SUnit tests cases if you
> want to.
>
> Thanks to YourNotification Exception handling, the tally will catch each
> and every send to the method(s) of interest (where you raised
> YourNotification), rather than randomly analyze callStack every few
> milliseconds.
>
> Some core or UI activity are really impossible to debug with a halt and
> step by step processing in debugger, in which case this hack is usefull.
> (like tracing a Font or a Morphic bug / see
> http://bugs.squeak.org/view.php?id=1035 or
> http://bugs.squeak.org/view.php?id=2084 for example).
>
> Of course, you do not catch each and every possible send of the
> method(s), but only actual send you triggered by your selected activity.
> It's complementary to browsing activity when polymorphism makes it
> complex to track...
>
> You can change the 300 seconds timer at will, or end the tally manually
> by executing tallyEnd := true with a doIt in the same workspace rather
> than forking a timer...
>
> If you omit the final tally close, you can also cumulate tallies by
> rearming the timer and tally block (simply doIt!).
>
> Though i tried to be didactic, I know this hack might be just too much
> for this list, but isn't it amazingly clear and powerful what you can do
> with Smalltalk in a few lines?
> Just invent your own variations...
>
> Nicolas