[squeak-dev] The better debugger support by extending an Object
protocol
Chris Muller
asqueaker at gmail.com
Mon Sep 7 23:45:56 UTC 2009
Magma is deliberate about printing proxy's:
MagmaMutatingProxy>>printOn: aStream
MagmaPreferences debugProxies
ifTrue:
[ super printOn: aStream.
aStream
maPrint: $( ;
maPrint: oid ;
maPrint: '/' ;
maPrint: session id ;
maPrint: ')' ]
ifFalse: [ self mutant printOn: aStream ]
Making a new Proxy class can be tricky to debug, here are some tips I
used in getting Magma's proxy's going. If you don't want a proxy to
materialize:
- use the inspector, not the explorer
- if a particular proxy does not have a convenient type-checking
test, you may print #class safely without materializing.
- It's really easy to forget about robust printing methods, so when
I had to debug proxy's I would generally avoid clicking state
variables in the debugger variable lists, instead, send messages by
typing only message-selectors I knew were available in the proxy class
and "print it".
I have actually been concerned about squirrelly debugging even for
regular, non-proxy objects. It seems if you have too complex an
expression; perhaps an exception handler wrapped in an ensure: within
a critical: block, etc. that sometimes debugging "Through" those
blocks results in a crashed debugger process. I can't remember the
exact message at the moment, but it can be frustrating.
I don't know that I've had the need or courage to step the debugger
through a Proxy's #become:. Thankfully, once the proxy limitations
are known, they are relatively easy to avoid.
For example, when calling a primitive it is easy to include a #yourself:
self perform: aSelectorProxied yourself with: #foo
It's a chink the "transparency", thankfully the impact is negligible.
I agree, use of == is generally bad form in applications, definitely
not worth the very minor performance nick of the extra send to
Object>>#=.
Cheers,
Chris
On Mon, Sep 7, 2009 at 12:29 PM, Igor Stasenko<siguctua at gmail.com> wrote:
> 2009/9/7 Bert Freudenberg <bert at freudenbergs.de>:
>>
>> On 07.09.2009, at 18:40, Randal L. Schwartz wrote:
>>
>>>>>>>> "Igor" == Igor Stasenko <siguctua at gmail.com> writes:
>>>
>>> Igor> Here is the default implementation of
>>>
>>> Object> debugPrintOn: aStream
>>> Igor> ^ self printOn: aStream
>>>
>>> I like it, but I don't like the name. It conjurs up the idea of debugging
>>> the #printOn: method itself.
>>>
>>> maybe #printForDebuggerOn: ?
>>
>>
>> It matches the other methods like #longPrintOn: though.
>>
>> Also that would imply only the debugger invokes it, when it's clearly
>> appropriate for any purpose.
>>
>> However, apart from this bike shedding ;) do others think it's a good idea
>> in general? IMHO #printOn: is primarily used for debugging anyway so I
>> wouldn't really expect a separate debug print method to be needed. Debugging
>> transparent proxies isn't for the faint-of-heart anyway, so these developers
>> can adapt their tools and proxies I would guess. OTOH there is precedence in
>> e.g. #asExplorerString, which exists solely to get rid of the quotes
>> enclosing strings for aesthetic reasons ...
>>
>
> I agree with you Bert, that we should consider if its really necessary.
> While #printOn: is used by most code for debugging, some of the code
> using it to serialize object to textual stream, so the #printOn: usage
> is much more generic than just debugging.
>
> As for debugging the transparent proxies - yes you can make own
> tools.. but this means reimplementing/hacking
> other tools , like debugger, inspector and so on, which will probably
> end up with similar solution to what i proposing.
>
> For example, there was a point of discrepancy with debugging the code
> which uses Magma.
> The magma forwarding proxy reifying the object once the first real
> message is sent to it.
> And the problem with such a proxy, that you can't use them in certain
> situations, like:
>
> self perform: aSelectorProxied with: #foo
>
> because #perform doesn't sends the messages to aSelectorProxied and
> primitive fails. But then, when you entering the debugger and trying
> to figure out why its not working - a proxy becomes a real object when
> it printed out.. and so you can't debug the error using debugger.
> Which leaves you to wonder, why code works in debugger, but not
> working at run time :)
>
>>
>> - Bert -
>>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
More information about the Squeak-dev
mailing list
|