[Pharo-dev] Debugger recursion

Marcus Denker marcus.denker at inria.fr
Fri Aug 30 11:42:17 EDT 2013


On Aug 30, 2013, at 5:13 PM, jan.struz <public+pharo at struz.cz> wrote:

> 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... :)
> 
> 
Yes, opening the debugger opens a file. So the breakpoint calls the method
again…

Oh, Meta-recursion :-)

	http://scg.unibe.ch/archive/papers/Denk08bMetaContextLNBIP.pdf

	Marcus


> 
> 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.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20130830/824c8595/attachment.asc>


More information about the Pharo-dev mailing list