Hi,
try this: ProtoObject subclass: #A instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: '_Test'. A>>doesNotUnderstand: aMessage self halt. ^ nil A new kiss. This will start opening infinite number of debuggers, because of A>>doesNotUnderstand: #halt. Ok, so, if I replace self halt with Halt signal, it will do the same, but now because of A>>doesNotUnderstand: #inspector. But in both cases, after successfully (before stack is full) interrupting the recursion with Alt+., only the Process Browser is full of "Morphic UI process:MorphicUIManager>>openDebuggerOn:context:label:contents:fullView:" no real debugger is visible... My question: How to debug code inside DNU method? Bug? Feature? I know, the full stack issue can be solved by a watchdog, is it planned? And it was discussed before here on mailinglist, but with different code examples. Or one can limit the total count of opened...
Save The World!
|
HI jan
we cannot see your code Ideally we would like to have a better handling of deep recursion but we are focusing on more important issues. Stef > Hi, > try this: > > > > This will start opening infinite number of debuggers, because of > A>>doesNotUnderstand: #halt. > Ok, so, if I replace /self halt/ with /Halt signal/, it will do the same, > but now because of A>>doesNotUnderstand: #inspector. > But in both cases, after successfully (before stack is full) interrupting > the recursion with Alt+., only the Process Browser is full of > "Morphic UI > process:MorphicUIManager>>openDebuggerOn:context:label:contents:fullView:" > no real debugger is visible... > > My question: How to debug code inside DNU method? Bug? Feature? > I know, the full stack issue can be solved by a watchdog, is it planned? And > it was discussed before here on mailinglist, but with different code > examples. > Or one can limit the total count of opened... > > > > ----- > Save The World! > -- > View this message in context: http://forum.world.st/Debugger-recursion-tp4704703.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
the code:
ProtoObject subclass: #A instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: '_Test'. A>>doesNotUnderstand: aMessage self halt. ^ nil A new kiss.
Save The World!
|
why do you inherit from protoObject?
Stef On Aug 23, 2013, at 12:34 PM, jan.struz <[hidden email]> wrote: > the code: > > ProtoObject subclass: #A > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: '_Test'. > > A>>doesNotUnderstand: aMessage > self halt. > ^ nil > > A new kiss. > > > > ----- > Save The World! > -- > View this message in context: http://forum.world.st/Debugger-recursion-tp4704703p4704751.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
Proxy implementation
Save The World!
|
On Aug 23, 2013, at 7:13 PM, jan.struz <[hidden email]> wrote: > Proxy implementation did you have a look at Ghost because mariano spent nearly a year on it. I do not really know what are the messages supposed to be supported by ProtoObject to be debugged May be it is not in the contract of ProtoObject and as such it produces normally an infinite loop. Stef >> why do you inherit from protoObject? >> >> Stef >> >> On Aug 23, 2013, at 12:34 PM, jan.struz < > >> public+pharo@ > >> > wrote: >> >>> the code: >>> >>> ProtoObject subclass: #A >>> instanceVariableNames: '' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: '_Test'. >>> >>> A>>doesNotUnderstand: aMessage >>> self halt. >>> ^ nil >>> >>> A new kiss. >>> >>> >>> >>> ----- >>> Save The World! >>> -- >>> View this message in context: >>> http://forum.world.st/Debugger-recursion-tp4704703p4704751.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> > > > > > > ----- > Save The World! > -- > View this message in context: http://forum.world.st/Debugger-recursion-tp4704703p4704791.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > |
ok, so the rule is: never subclass ProtoObject to make Debugger crazy.. I will definitely look at Ghost, it has already been on my todo list.. thanks
Save The World!
|
Hello, Are you on Pharo 2 or 3 ? 2013/8/24 jan.struz <[hidden email]> Stéphane Ducasse wrote |
I'm on Pharo 2, exactly this case - infinite loops or image crashes, I will try it in Pharo 3, and see the difference.
Save The World!
|
In reply to this post by jan.struz
On 24 August 2013 14:18, jan.struz <[hidden email]> wrote: Stéphane Ducasse wrote i would say: - if you subclass from ProtoObject then you are on your own.. don't expect any standard tools to work anymore (including debugger, of course). And no, there is no 'fix' for that.. except from merging ProtoObject with Object, which kills the purpose of having ProtoObject class. thanks -- Best regards, Igor Stasenko. |
If you take a look to Ghost proxies, in the proxy handler I have a dictionary in which users can define exceptions. That means, that the proxy handler will do something different than the expected action (like forwarding the message to another object). By default, I added some helper methods that add some of these exceptions. One of these, where a list of method to proper debug/inspect proxies. And the nice thing of being a dictionary is that you can enable/disable them even on the fly. Cheers, On Tue, Aug 27, 2013 at 5:09 PM, Igor Stasenko <[hidden email]> wrote:
Mariano http://marianopeck.wordpress.com |
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. It's interesting to see the (no)difference between the debuggingMessages in Ghost, and these needed for ProtoObject subclass... :-) Igor, you are right, the possibility to break something is not a bug, indeed :-) I know.
Save The World!
|
On Wed, Aug 28, 2013 at 11:18 AM, jan.struz <[hidden email]> wrote: Hi all, Indeed. I thought it was disabled by default. It's interesting to see the (no)difference between the debuggingMessages in 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.
Cheers, Igor, you are right, the possibility to break something is not a bug, indeed Mariano http://marianopeck.wordpress.com |
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... :) I like the idea, but it doesn't depend on me...
Save The World!
|
On Aug 30, 2013, at 5:13 PM, jan.struz <[hidden email]> 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. > signature.asc (210 bytes) Download Attachment |
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 <[hidden email]> wrote:
-- Best regards, Igor Stasenko. |
added issue 11517:
https://pharo.fogbugz.com/f/cases/11517/Installed-Breakpoint-can-cause-recursion
Save The World!
|
Free forum by Nabble | Edit this page |