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.
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! -- 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.
why do you inherit from protoObject? Stef On Aug 23, 2013, at 12:34 PM, jan.struz <public+pharo@struz.cz> 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 Stéphane Ducasse wrote
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.
On Aug 23, 2013, at 7:13 PM, jan.struz <public+pharo@struz.cz> 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.
Stéphane Ducasse wrote
On Aug 23, 2013, at 7:13 PM, jan.struz <
public+pharo@
> 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
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! -- View this message in context: http://forum.world.st/Debugger-recursion-tp4704703p4704864.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hello, Are you on Pharo 2 or 3 ? In Pharo 2, debugging or inspecting with ProtoObject subclasses resulted in infinite loops or image crashes. I tried to have a look with the new debugger and inspectors in Pharo 3 but there is still some work to do. 2013/8/24 jan.struz <public+pharo@struz.cz>
Stéphane Ducasse wrote
On Aug 23, 2013, at 7:13 PM, jan.struz <
public+pharo@
> 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
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! -- View this message in context: http://forum.world.st/Debugger-recursion-tp4704703p4704864.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I'm on Pharo 2, exactly this case - infinite loops or image crashes, I will try it in Pharo 3, and see the difference. Clément Bera-4 wrote
Hello,
Are you on Pharo 2 or 3 ?
In Pharo 2, debugging or inspecting with ProtoObject subclasses resulted in infinite loops or image crashes. I tried to have a look with the new debugger and inspectors in Pharo 3 but there is still some work to do.
2013/8/24 jan.struz <
public+pharo@
>
Stéphane Ducasse wrote
On Aug 23, 2013, at 7:13 PM, jan.struz <
public+pharo@
> 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
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! -- View this message in context: http://forum.world.st/Debugger-recursion-tp4704703p4704864.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-tp4704703p4705301.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 24 August 2013 14:18, jan.struz <public+pharo@struz.cz> wrote: > Stéphane Ducasse wrote > > On Aug 23, 2013, at 7:13 PM, jan.struz < > > > public+pharo@ > > > > 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 > > 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.. > > 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 > > > > > > ----- > Save The World! > -- > View this message in context: > http://forum.world.st/Debugger-recursion-tp4704703p4704864.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- 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 <siguctua@gmail.com> wrote: > > > > On 24 August 2013 14:18, jan.struz <public+pharo@struz.cz> wrote: > >> Stéphane Ducasse wrote >> > On Aug 23, 2013, at 7:13 PM, jan.struz < >> >> > public+pharo@ >> >> > > 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 >> >> 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.. >> >> 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 >> >> >> >> >> >> ----- >> Save The World! >> -- >> View this message in context: >> http://forum.world.st/Debugger-recursion-tp4704703p4704864.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > > > -- > Best regards, > Igor Stasenko. > -- 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! -- 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.
On Wed, Aug 28, 2013 at 11:18 AM, jan.struz <public+pharo@struz.cz> 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. 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
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.
On Aug 30, 2013, at 5:13 PM, jan.struz <public+pharo@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.
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 <marcus.denker@inria.fr> wrote:
On Aug 30, 2013, at 5:13 PM, jan.struz <public+pharo@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.
-- Best regards, Igor Stasenko.
added issue 11517: https://pharo.fogbugz.com/f/cases/11517/Installed-Breakpoint-can-cause-recur... Igor Stasenko wrote
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 <
marcus.denker@
> wrote:
On Aug 30, 2013, at 5:13 PM, jan.struz <
public+pharo@
> 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.
----- Save The World! -- View this message in context: http://forum.world.st/Debugger-recursion-tp4704703p4705841.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (6)
-
Clément Bera -
Igor Stasenko -
jan.struz -
Marcus Denker -
Mariano Martinez Peck -
Stéphane Ducasse