Smalltalk › Pharo › Pharo Smalltalk Developers

Debugging with Toggle breakpoint

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

S Krish

Debugging with Toggle breakpoint

Will come up with a cs for the issues in Morphic widgets shortly after I test them more thoroughly..

I am kind of convinced that putting a breakpoint in a method with "Toggle Breakpoint" and then stepping through the morphic code base is causing the UI instability of rendering glitches and other concomittant issues. It does not occur, if we do normal "debugIt" and then step through, so it should not be much to do with Morphic stepping thru logic of events et all.. but something intrinsic to how the breakpoint affects Morphic / UI rendering of Pharo.

I have done fair amount of work spread across several days with the same image earlier, days prior to "breakpoint" capabilities on Pharo 1.1, but now I barely have the image last the day, goes sluggish and with these UI blemishes may be unrelated but I suspect a correlation:

( Pharo is Lot better though than Linux blemises with Compbiz where you loose all window bars, decorations.. once a while..!)

On Pharo 1.3 stable mostly/ Also Pharo 1.4 latest :

* The thumbnail image of taskbar windows will remain painted, behind the top window, on the World.. ( thankfully..) but at times on front occluding the top window .

* Windows/ Menus will come up partially occluded and running the mouse over exposes it fully..

* Mouse inputs become sluggish...

* Transcript opened in these situations sometimes has a funny effect of only the textMorph of transcript partially overlapping the top Window

* From a newbie perspective, need to keep a list of methods break point cannot be put in, which are polling code..

Will need to get more precise and come back on them with fixes as possible. I will revert to the older breakpointing of using self halt inserted at top/ line I need with the "Toggle breakpoint" and check also..

Will dig in deeper and come back.

Stéphane Ducasse

Re: Debugging with Toggle breakpoint

On Feb 13, 2012, at 3:49 AM, S Krish wrote:

> Will come up with a cs for the issues in Morphic widgets shortly after I test them more thoroughly..
>
> I am kind of convinced that putting a breakpoint in a method with "Toggle Breakpoint" and then stepping through the morphic code base is causing the UI instability of rendering glitches and other concomittant issues. It does not occur, if we do normal "debugIt" and then step through, so it should not be much to do with Morphic stepping thru logic of events et all.. but something intrinsic to how the breakpoint affects Morphic / UI rendering of Pharo.

I never use such functionality so I cannot comment.

>
> I have done fair amount of work spread across several days with the same image earlier, days prior to "breakpoint" capabilities on Pharo 1.1, but now I barely have the image last the day, goes sluggish and with these UI blemishes may be unrelated but I suspect a correlation:
>
> ( Pharo is Lot better though than Linux blemises with Compbiz where you loose all window bars, decorations.. once a while..!)
>
> On Pharo 1.3 stable mostly/ Also Pharo 1.4 latest :
>
> * The thumbnail image of taskbar windows will remain painted, behind the top window, on the World.. ( thankfully..) but at times on front occluding the top window .
> * Windows/ Menus will come up partially occluded and running the mouse over exposes it fully..
> * Mouse inputs become sluggish...
> * Transcript opened in these situations sometimes has a funny effect of only the textMorph of transcript partially overlapping the top Window
>
> * From a newbie perspective, need to keep a list of methods break point cannot be put in, which are polling code..
>
> Will need to get more precise and come back on them with fixes as possible. I will revert to the older breakpointing of using self halt inserted at top/ line I need with the "Toggle breakpoint" and check also..
>
> Will dig in deeper and come back.
>

Igor Stasenko

Re: Debugging with Toggle breakpoint

On 13 February 2012 16:58, Stéphane Ducasse <[hidden email]> wrote:
>
> On Feb 13, 2012, at 3:49 AM, S Krish wrote:
>
>> Will come up with a cs for the issues in Morphic widgets shortly after I test them more thoroughly..
>>
>> I am kind of convinced that putting a breakpoint in a method with "Toggle Breakpoint" and then stepping through the morphic code base is causing the UI instability of rendering glitches and other concomittant issues. It does not occur, if we do normal "debugIt" and then step through, so it should not be much to do with Morphic stepping thru logic of events et all.. but something intrinsic to how the breakpoint affects Morphic / UI rendering of Pharo.
>
> I never use such functionality so I cannot comment.
>
I can only say, that if you put a breakpoint at wrong place somewhere
in morphic code, you may endup with broken system,
when rendering/event handling code always goes to that method and
always halts there, causing restarting UI process on every system
event.

Debugging UI while UI is running is not an easy task. Mostly done
manually with tricks like haltOnce: or invoking doits which lead to
parts of code under question.

So, it would be good to know first, where exactly you put breakpoints.

>>
>> I have done fair amount of work spread across several days with the same image earlier, days prior to "breakpoint" capabilities on Pharo 1.1, but now I barely have the image last the day, goes sluggish and with these UI blemishes may be unrelated but I suspect a correlation:
>>
>> ( Pharo is Lot better though than Linux blemises with Compbiz where you loose all window bars, decorations.. once a while..!)
>>
>> On Pharo 1.3 stable mostly/ Also Pharo 1.4 latest :
>>
>> * The thumbnail image of taskbar windows will remain painted, behind the top window, on the World.. ( thankfully..) but at times on front occluding the top window .
>> * Windows/ Menus will come up partially occluded and running the mouse over exposes it fully..
>> * Mouse inputs become sluggish...
>> * Transcript opened in these situations sometimes has a funny effect of only the textMorph of transcript partially overlapping the top Window
>>
>> * From a newbie perspective, need to keep a list of methods break point cannot be put in, which are polling code..
>>
>> Will need to get more precise and come back on them with fixes as possible. I will revert to the older breakpointing of using self halt inserted at top/ line I need with the "Toggle breakpoint" and check also..
>>
>> Will dig in deeper and come back.
>>
>
>

--
Best regards,
Igor Stasenko.

S Krish

Re: Debugging with Toggle breakpoint

Sure, I hope my understanding of the system, polling events is good enough to avoid basic pitfalls..

But this is debug breakpoint of custom classes for Morphic View.. simple morphic compositions.. not in the Pharo framework code..

But as you said let me get this cleanly replicable this weekend and give a heads up.. else its like finding a needle in a haystack..

On Mon, Feb 13, 2012 at 10:36 PM, Igor Stasenko <[hidden email]> wrote:

On 13 February 2012 16:58, Stéphane Ducasse <[hidden email]> wrote:
>
> On Feb 13, 2012, at 3:49 AM, S Krish wrote:
>
>> Will come up with a cs for the issues in Morphic widgets shortly after I test them more thoroughly..
>>
>> I am kind of convinced that putting a breakpoint in a method with "Toggle Breakpoint" and then stepping through the morphic code base is causing the UI instability of rendering glitches and other concomittant issues. It does not occur, if we do normal "debugIt" and then step through, so it should not be much to do with Morphic stepping thru logic of events et all.. but something intrinsic to how the breakpoint affects Morphic / UI rendering of Pharo.
>
> I never use such functionality so I cannot comment.
>

I can only say, that if you put a breakpoint at wrong place somewhere
in morphic code, you may endup with broken system,
when rendering/event handling code always goes to that method and
always halts there, causing restarting UI process on every system
event.

Debugging UI while UI is running is not an easy task. Mostly done
manually with tricks like haltOnce: or invoking doits which lead to
parts of code under question.

So, it would be good to know first, where exactly you put breakpoints.

>>
>> I have done fair amount of work spread across several days with the same image earlier, days prior to "breakpoint" capabilities on Pharo 1.1, but now I barely have the image last the day, goes sluggish and with these UI blemishes may be unrelated but I suspect a correlation:
>>
>> ( Pharo is Lot better though than Linux blemises with Compbiz where you loose all window bars, decorations.. once a while..!)
>>
>> On Pharo 1.3 stable mostly/ Also Pharo 1.4 latest :
>>
>> * The thumbnail image of taskbar windows will remain painted, behind the top window, on the World.. ( thankfully..) but at times on front occluding the top window .
>> * Windows/ Menus will come up partially occluded and running the mouse over exposes it fully..
>> * Mouse inputs become sluggish...
>> * Transcript opened in these situations sometimes has a funny effect of only the textMorph of transcript partially overlapping the top Window
>>
>> * From a newbie perspective, need to keep a list of methods break point cannot be put in, which are polling code..
>>
>> Will need to get more precise and come back on them with fixes as possible. I will revert to the older breakpointing of using self halt inserted at top/ line I need with the "Toggle breakpoint" and check also..
>>
>> Will dig in deeper and come back.
>>
>
>

--
Best regards,
Igor Stasenko.