Debugger recursion

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugger recursion

jan.struz
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!
Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

Stéphane Ducasse
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.
>


Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

jan.struz
the code:

ProtoObject subclass: #A
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: '_Test'.

A>>doesNotUnderstand: aMessage
        self halt.
        ^ nil

A new kiss.
Save The World!
Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

Stéphane Ducasse
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.
>


Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

jan.struz
Proxy implementation

Stéphane Ducasse wrote
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.
>
Save The World!
Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

Stéphane Ducasse

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 &lt;
>
>> public+pharo@
>
>> &gt; 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.
>


Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

jan.struz
Stéphane Ducasse wrote
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
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!
Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

Clément Béra
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 <[hidden email]>
Stéphane Ducasse wrote
> On Aug 23, 2013, at 7:13 PM, jan.struz &lt;

> public+pharo@

> &gt; 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.


Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

jan.struz
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 <[hidden email]>

> 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!
Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

Igor Stasenko
In reply to this post by jan.struz



On 24 August 2013 14:18, jan.struz <[hidden email]> wrote:
Stéphane Ducasse wrote
> On Aug 23, 2013, at 7:13 PM, jan.struz &lt;

> public+pharo@

> &gt; 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.
Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

Mariano Martinez Peck
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:



On 24 August 2013 14:18, jan.struz <[hidden email]> wrote:
Stéphane Ducasse wrote
> On Aug 23, 2013, at 7:13 PM, jan.struz &lt;

> public+pharo@

> &gt; 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
Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

jan.struz
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!
Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

Mariano Martinez Peck



On Wed, Aug 28, 2013 at 11:18 AM, jan.struz <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

jan.struz
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 <[hidden email]> 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!
Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

Marcus Denker-4

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 &lt;
>
>> public+pharo@
>
>> &gt; 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
Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

Igor Stasenko
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:

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 &lt;
>
>> public+pharo@
>
>> &gt; 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.
Reply | Threaded
Open this post in threaded view
|

Re: Debugger recursion

jan.struz
added issue 11517:

https://pharo.fogbugz.com/f/cases/11517/Installed-Breakpoint-can-cause-recursion

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 <[hidden email]> wrote:

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


--
Best regards,
Igor Stasenko.
Save The World!