[Pharo-dev] Debugger recursion
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 <
> > 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
>> (will open a debugger).
>> #class is the first message sent by Debugger, to continue with full
>> & 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
>> (I hope this will be useful for someone...)
>> In the latest Pharo 3.0 (30351), implementing the first message (here it
>> #printStringLimitedTo:) is not enough, I have to implement another
>> (ex. #inspector) and in addition #basicSize and #-> (in short, all of
>> needed by debugger).
>> Without that, I am not able to debug it. The good thing in Pharo3 is,
>> the image is responding, and I can see what is happening in
>> and so, without interrupting.
>> Mariano, the Ghost proxies are really great, only I think the logging
>> be optional and turned off by default. So it could be referenced by
>> project and ready to use.
> Indeed. I thought it was disabled by default.
>> It's interesting to see the (no)difference between the debuggingMessages
>> 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
> Those that could be implemented, can be implemented and those that would
> depend on the usage, could be implemented as "self
> But what is important is that such a class will document the needed
> in order to proper debug/inspect subclasses of ProtoObject.
I like the idea, but it doesn't depend on me...
>> Igor, you are right, the possibility to break something is not a bug,
>> :-) I know.
>> Save The World!
>> View this message in context:
>> Sent from the Pharo Smalltalk Developers mailing list archive at
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