bug in a ToolBuilder, Squeak5.3rc2

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

bug in a ToolBuilder, Squeak5.3rc2

vaidasd
Hello,
It seems there is a bug in the Morphic ToolBuilder lists, sorry if this is not right place reporting it. Say, we have:
listSpec := builder pluggableListSpec new.
listSpec
      model: self;
      list: #fields;
       ...
      dropAccept: #acceptThis:;
      dropItem: #dropOn:at: .
Image stalls if I put #halt in #acceptThis

regards,
Vaidotas


Reply | Threaded
Open this post in threaded view
|

Re: bug in a ToolBuilder, Squeak5.3rc2

Christoph Thiede
Hi Vaidotas,

thanks for the report, you're right here! :-) IMHO, this not a real bug, though clearly a behavior that could be improved. The reason is that every single mouse move your image receives while dragging something will trigger your list morph to check whether it can accept the dragged morph, so it will call #dropAccept: and open a debugger. This will happen again for every single of all the many MouseMoveEvents. You might want to use #haltOnce to spawn one debugger only.

However, for the feature after 5.3, I would be happy to make the debugger even more robust against this kind of debugger chains (which are not related to a known issue with process-faithful debugging). For example, we could simply count the number of debuggers that were opened in the last few seconds and show a prompt (#request:) if a certain threshold has been reached before opening further debuggers thereafter. This is just a vague idea and may need further discussion ...

Best,
Christoph



Von: Squeak-dev <[hidden email]> im Auftrag von Vaidotas Didžbalis <[hidden email]>
Gesendet: Donnerstag, 27. Februar 2020, 21:04
An: Squeak-Dev
Betreff: [squeak-dev] bug in a ToolBuilder, Squeak5.3rc2

Hello,
It seems there is a bug in the Morphic ToolBuilder lists, sorry if this is not right place reporting it. Say, we have:
listSpec := builder pluggableListSpec new.
listSpec
      model: self;
      list: #fields;
       ...
      dropAccept: #acceptThis:;
      dropItem: #dropOn:at: .
Image stalls if I put #halt in #acceptThis

regards,
Vaidotas



Reply | Threaded
Open this post in threaded view
|

Re: bug in a ToolBuilder, Squeak5.3rc2

marcel.taeumel
Hi, there.

 For example, we could simply count the number of debuggers that were opened in the last few seconds and show a prompt (#request:) if a certain threshold 

Counting and timing dependent watchdogs are quite error prone and not user friendly. A more robust solution could address the particular control flow and not attach some outside process that monitors variables from time to time.

Now that we invoke morph halos through event filters, we should implement #errorOnDraw for events, too. Then we could skip event processing for a buggy morph and avoid those endless debuggers. Like we already do for drawing errors. We just have to double-check the performance because there is not much time left to play with during event processing.

Best,
Marcel

Am 27.02.2020 21:50:17 schrieb Christoph Thiede <[hidden email]>:

Hi Vaidotas,

thanks for the report, you're right here! :-) IMHO, this not a real bug, though clearly a behavior that could be improved. The reason is that every single mouse move your image receives while dragging something will trigger your list morph to check whether it can accept the dragged morph, so it will call #dropAccept: and open a debugger. This will happen again for every single of all the many MouseMoveEvents. You might want to use #haltOnce to spawn one debugger only.

However, for the feature after 5.3, I would be happy to make the debugger even more robust against this kind of debugger chains (which are not related to a known issue with process-faithful debugging). For example, we could simply count the number of debuggers that were opened in the last few seconds and show a prompt (#request:) if a certain threshold has been reached before opening further debuggers thereafter. This is just a vague idea and may need further discussion ...

Best,
Christoph



Von: Squeak-dev <[hidden email]> im Auftrag von Vaidotas Didžbalis <[hidden email]>
Gesendet: Donnerstag, 27. Februar 2020, 21:04
An: Squeak-Dev
Betreff: [squeak-dev] bug in a ToolBuilder, Squeak5.3rc2

Hello,
It seems there is a bug in the Morphic ToolBuilder lists, sorry if this is not right place reporting it. Say, we have:
listSpec := builder pluggableListSpec new.
listSpec
      model: self;
      list: #fields;
       ...
      dropAccept: #acceptThis:;
      dropItem: #dropOn:at: .
Image stalls if I put #halt in #acceptThis

regards,
Vaidotas



Reply | Threaded
Open this post in threaded view
|

Re: bug in a ToolBuilder, Squeak5.3rc2

Christoph Thiede

Hi Marcel,


Counting and timing dependent watchdogs are quite error prone and not user friendly. A more robust solution could address the particular control flow and not attach some outside process that monitors variables from time to time.


Well, that's right. Please see Morphic-ct.1636 for a proposed implementation of #errorOnEvent. And thank you for suggesting such interesting feature requests! :D


Best,

Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Freitag, 28. Februar 2020 10:03:19
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] bug in a ToolBuilder, Squeak5.3rc2
 
Hi, there.

 For example, we could simply count the number of debuggers that were opened in the last few seconds and show a prompt (#request:) if a certain threshold 

Counting and timing dependent watchdogs are quite error prone and not user friendly. A more robust solution could address the particular control flow and not attach some outside process that monitors variables from time to time.

Now that we invoke morph halos through event filters, we should implement #errorOnDraw for events, too. Then we could skip event processing for a buggy morph and avoid those endless debuggers. Like we already do for drawing errors. We just have to double-check the performance because there is not much time left to play with during event processing.

Best,
Marcel

Am 27.02.2020 21:50:17 schrieb Christoph Thiede <[hidden email]>:

Hi Vaidotas,

thanks for the report, you're right here! :-) IMHO, this not a real bug, though clearly a behavior that could be improved. The reason is that every single mouse move your image receives while dragging something will trigger your list morph to check whether it can accept the dragged morph, so it will call #dropAccept: and open a debugger. This will happen again for every single of all the many MouseMoveEvents. You might want to use #haltOnce to spawn one debugger only.

However, for the feature after 5.3, I would be happy to make the debugger even more robust against this kind of debugger chains (which are not related to a known issue with process-faithful debugging). For example, we could simply count the number of debuggers that were opened in the last few seconds and show a prompt (#request:) if a certain threshold has been reached before opening further debuggers thereafter. This is just a vague idea and may need further discussion ...

Best,
Christoph



Von: Squeak-dev <[hidden email]> im Auftrag von Vaidotas Didžbalis <[hidden email]>
Gesendet: Donnerstag, 27. Februar 2020, 21:04
An: Squeak-Dev
Betreff: [squeak-dev] bug in a ToolBuilder, Squeak5.3rc2

Hello,
It seems there is a bug in the Morphic ToolBuilder lists, sorry if this is not right place reporting it. Say, we have:
listSpec := builder pluggableListSpec new.
listSpec
      model: self;
      list: #fields;
       ...
      dropAccept: #acceptThis:;
      dropItem: #dropOn:at: .
Image stalls if I put #halt in #acceptThis

regards,
Vaidotas