that means that breakpoint should trigger only once and then immediately place a recursion guard, so next time it enters the breakpoint, it checks against recursion and passing by.
On 30 August 2013 17:42, Marcus Denker <[email protected]> wrote: > > On Aug 30, 2013, at 5:13 PM, jan.struz <[email protected]> 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. > > > > -- Best regards, Igor Stasenko.
