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.
