[Pharo-dev] Debugger recursion

jan.struz public+pharo at struz.cz
Fri Aug 30 11:12:20 EDT 2013


one more endless loop, on Pharo3 & Pharo2, evaluate this code:

BreakpointManager installInClass: FileSystem selector: #stringFromPath:.
'C:\' asFileReference fullName.

no debugger, cannot interrupt, freezed image(especially 2.0)
this one is going to end in bugtracker, I think... :)



Mariano Martinez Peck wrote
> On Wed, Aug 28, 2013 at 11:18 AM, jan.struz <

> public+pharo@

> > wrote:
> 
>> Hi all,
>> I have a solution for the recursion in Pharo 2.0. (For those subclassing
>> ProtoObject, of course :-) )
>> If the subclass of ProtoObject implements #class, then the Debugger is
>> happy
>> (will open a debugger).
>> #class is the first message sent by Debugger, to continue with full
>> debugger
>> & deeper inspecting the instance, one have to implement the rest -
>> #isMemberOf: #isKindOf: #inspectorClass #printStringLimitedTo:
>> #longPrintOn:limitedTo:indent: #defaultLabelForInspector
>> #longPrintStringLimitedTo: (minimal set)
>> All of these messages pops up in debugger as MNU, and I am able to debug
>> it.
>> (I hope this will be useful for someone...)
>>
>> In the latest Pharo 3.0 (30351), implementing the first message (here it
>> is
>> #printStringLimitedTo:) is not enough, I have to implement another
>> methods
>> (ex. #inspector) and in addition #basicSize and #-> (in short, all of
>> them,
>> needed by debugger).
>> Without that, I am not able to debug it. The good thing in Pharo3 is,
>> that
>> the image is responding, and I can see what is happening in
>> ProcessBrowser
>> and so, without interrupting.
>>
>> Mariano, the Ghost proxies are really great, only I think the logging
>> should
>> be optional and turned off by default. So it could be referenced by
>> another
>> project and ready to use.
>>
> 
> Indeed. I thought it was disabled by default.
> 
> 
>> It's interesting to see the (no)difference between the debuggingMessages
>> in
>> Ghost, and these needed for ProtoObject subclass... :-)
>>
>>
> It seems you were not the first fighting with that :)
> Maybe it's time to document all this by having integrated in the image a
> DebuggeableProtoObject? Subclass of ProtoObject and implementing the
> needed
> methods?
> Those that could be implemented, can be implemented and those that would
> depend on the usage, could be implemented as "self
> subclassResponsability".
> But what is important is that such a class will document the needed
> methods
> in order to proper debug/inspect subclasses of ProtoObject.

I like the idea, but it doesn't depend on me...


> Cheers,
> 
> 
> 
>> Igor, you are right, the possibility to break something is not a bug,
>> indeed
>> :-) I know.
>>
>>
>>
>>
>> -----
>> Save The World!
>> --
>> View this message in context:
>> http://forum.world.st/Debugger-recursion-tp4704703p4705487.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>>
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com





-----
Save The World!
--
View this message in context: http://forum.world.st/Debugger-recursion-tp4704703p4705815.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.




More information about the Pharo-dev mailing list