[squeak-dev] The Trunk: Tools-eem.1104.mcz

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Fri Jan 14 15:58:27 UTC 2022


Hi Marcel,

if we started catching errors in every programmable hook of the system, it would not be the same Squeak any longer. :-) There are too many of these hooks (which is good) and I claim that most Squeak users are used to stumbling upon an unexpected debugger occassionaly fixing, reporting, and/or working around it immediately.

Yes, we have similar mechanisms for #drawOn:, #doLayoutIn:, and maybe soon in #handleEvent: as well, but these are crucial to keep the system minimally intact when an error occurs (that is, avoid infinite chains of debuggers). However, this reason does *not* apply to menus which are not part of the "minimal feature set" required for fixing a simple bug in the system.

Wrapping errors into other, not significantly different exceptions/warnings also slightly appears as an anti-pattern to me ("don't handle an exception you cannot actually handle"), but I guess this could be a trade-off for now. :-) My question is, how could the user re-enable the broken menu builders conveniently to see the debugger again? What would be the equivalent of "resume after draw error" (which already lacks an ideal discoverability IMO), does the user need to go into the preferences or evaluate a one-liner for this? :(

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2022-01-14T16:20:46+01:00, marcel.taeumel at hpi.de wrote:

> Hi Christoph --
> 
> > This is an anti-pattern in my opinion and should be revised.
> > Can we please remove that #ifError: from Model>>#buildMenu:withBuilders:shifted: again? :-)
> 
> Not every user is a developer. Having menus that do not throw errors is a good thing. Hmm... a specialized Warning about the broken menu seems nice =)
> 
> > Or maybe a separate "release mode" preference.
> 
> Seriously ... we do need to talk about "modes" at some point ... Stop it. xD
> 
> Best,
> Marcel
> Am 14.01.2022 16:16:54 schrieb christoph.thiede at student.hpi.uni-potsdam.de <christoph.thiede at student.hpi.uni-potsdam.de>:
> Hi Marcel,
> 
> thank you for the clarification (and thank you Eliot for fixing this bug)!
> 
> So the menu building mechanism is actually ignoring errors from single menu builders? This is an anti-pattern in my opinion and should be revised. Silently and unconditionally dropping errors instead of reporting them to the user/developer (and writing them to the Transcript does *not* count as reporting IMHO because I only open the Transcript when I *expect* to see particular messages in it) looks like a bad practice to me that makes debugging and testing (both manually and automated) unnecessarily hard and non-interactive. It's not the Smalltalk way of facilitating short feedback cycles and direct manipulation. If an error occurs, I want to know about it and fix it immediately (which usually only takes a few seconds or minutes). If you really see some situations where fixing the error is so expensive (I would be curious to hear them), I would prefer talking about an opt-in mechanism similar to Warning class >> #suppressed:. Or maybe a separate "release mode" preference. But please let's keep our primary focus in the main image on developers that are curious to notice and report/resolve every bug. :-)
> 
> Can we please remove that #ifError: from Model>>#buildMenu:withBuilders:shifted: again? :-)
> 
> Best,
> Christoph
> 
> ---
> Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]
> 
> On 2022-01-14T10:08:23+01:00, marcel.taeumel at hpi.de wrote:
> 
> > Hi Christoph --
> >
> > You are showing the "more..." menu. The initial menu is truncated because of that bug in #isBreakOnEntry.
> >
> >
> >
> > After Eliot's patch, it looks as expected:
> >
> >
> >
> > Best,
> > Marcel
> > Am 13.01.2022 19:26:32 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
> > I have a message trace here with no message selected, but the menu can be opened anyway without an error:
> >
> >
> >  
> >
> >
> > Under which circumstances did this error occur? :-)
> >
> > Best,
> > Christoph
> > Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von commits at source.squeak.org <commits at source.squeak.org>
> > Gesendet: Donnerstag, 13. Januar 2022 19:21:13
> > An: squeak-dev at lists.squeakfoundation.org; packages at lists.squeakfoundation.org
> > Betreff: [squeak-dev] The Trunk: Tools-eem.1104.mcz
> >  
> > Eliot Miranda uploaded a new version of Tools to project The Trunk:
> > http://source.squeak.org/trunk/Tools-eem.1104.mcz [http://source.squeak.org/trunk/Tools-eem.1104.mcz]
> >
> > ==================== Summary ====================
> >
> > Name: Tools-eem.1104
> > Author: eem
> > Time: 13 January 2022, 10:21:10.513361 am
> > UUID: 1d051d8d-473d-43ee-9628-d33992a5849f
> > Ancestors: Tools-mt.1103
> >
> > Fix MNU in menu building for MessageTrace with no method selected
> >
> > =============== Diff against Tools-mt.1103 ===============
> >
> > Item was changed:
> >   ----- Method: CodeHolder>>isBreakOnEntry (in category 'breakpoints') -----
> >   isBreakOnEntry
> >  
> > +        ^self selectedClassOrMetaClass
> > +                ifNil: [false]
> > +                ifNotNil:
> > +                        [:class|
> > +                         (class
> > +                                        compiledMethodAt: self selectedMessageName
> > +                                        ifAbsent: nil)
> > +                                ifNil: [false]
> > +                                ifNotNil: [:method| method hasBreakpoint]]!
> > -        | selectedMethod |
> > -        selectedMethod := self selectedClassOrMetaClass
> > -                compiledMethodAt: self selectedMessageName
> > -                ifAbsent: [^ false].
> > -        ^ selectedMethod hasBreakpoint!
> >
> >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220114/a8d504cb/attachment-0001.html>
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: image.png
> > Type: image/png
> > Size: 22635 bytes
> > Desc: not available
> > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220114/a8d504cb/attachment-0005.png>
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: pastedImage.png
> > Type: image/png
> > Size: 4074 bytes
> > Desc: not available
> > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220114/a8d504cb/attachment-0006.png>
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: pastedImage.png
> > Type: image/png
> > Size: 18275 bytes
> > Desc: not available
> > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220114/a8d504cb/attachment-0007.png>
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: pastedImage.png
> > Type: image/png
> > Size: 15326 bytes
> > Desc: not available
> > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220114/a8d504cb/attachment-0008.png>
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: image.png
> > Type: image/png
> > Size: 78379 bytes
> > Desc: not available
> > URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220114/a8d504cb/attachment-0009.png>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220114/eb5bed70/attachment.html>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220114/7f246fd5/attachment-0001.html>


More information about the Squeak-dev mailing list