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 |
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
Carpe Squeak!
|
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
|
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
Carpe Squeak!
|
Free forum by Nabble | Edit this page |