> Why isn't it sufficient to test for UnhandledError instead? Otherwise, we would also need to test for Warning etc. ... UnhandledError and UnhandledWarning are (private) implementation details of Squeak's exception handling mechanism. They should never be exposed to (or used by) applications/frameworks. Best, Marcel
|
I see, but isn't it just their existence what we want to test for to prevent from loads of Debuggers appearing? Or should we go the other way around and signal a "DebuggerRaisedNotification" each time before opening a debugger?
However, currently, a #deprecated call in a drawing method makes the image unusable ... Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 23. Oktober 2019 15:48:15 An: John Pfersich via Squeak-dev Betreff: Re: [squeak-dev] The Trunk: System-mt.1093.mcz
> Why isn't it sufficient to test for UnhandledError instead? Otherwise, we would also need to test for Warning etc. ...
UnhandledError and UnhandledWarning are (private) implementation details of Squeak's exception handling mechanism. They should never be exposed to (or used by) applications/frameworks.
Best,
Marcel
Carpe Squeak!
|
Hi Christoph. > However, currently, a #deprecated call in a drawing method makes the image unusable ... Yes, there is a lot of room for improvement in Squeak's strategy to keep the image alive and in a recoverable state. Annoying things include errors in event handlers (such as #mouseOver:) and the thing about Warnings you mentioned for #displayWorldSafely. Since the exception mechanism can be used to implement dynamic scope (see CurrentReadOnlySourceFiles), we should never catch Exception in general to install such handlers. Warning might be a nice addition to #displayWorldSafely. [Error] bench '219,000,000 per second. 4.57 nanoseconds per run.' [Error, Halt] bench '11,900,000 per second. 84.4 nanoseconds per run.' [Error, Halt, Warning] bench '9,910,000 per second. 101 nanoseconds per run.' Since this is called only once to fourteen times per frame (see DamageRecorder) -- but usually only once -- we are good with 100 nanoseconds, given that 60 frames-per-second translate to 16 666 667 nanoseconds per frame. Best, Marcel
|
> Since this is called only once to fourteen times per frame (see DamageRecorder) ... Sorry for that slip. The role of DamageRecorder comes into play only *after* the error handler. So this is only called once per frame. Best, Marcel
|
In reply to this post by marcel.taeumel
On Tue, 29 Oct 2019, Marcel Taeumel wrote:
> Hi Christoph. > > However, currently, a #deprecated call in a drawing method makes the image unusable ... > > Yes, there is a lot of room for improvement in Squeak's strategy to keep the image alive and in a recoverable state. Annoying things include errors in event handlers (such as #mouseOver:) and the thing about Warnings you > mentioned for #displayWorldSafely. > > Since the exception mechanism can be used to implement dynamic scope (see CurrentReadOnlySourceFiles), we should never catch Exception in general to install such handlers. > > Warning might be a nice addition to #displayWorldSafely. > > [Error] bench '219,000,000 per second. 4.57 nanoseconds per run.' > [Error, Halt] bench '11,900,000 per second. 84.4 nanoseconds per run.' > [Error, Halt, Warning] bench '9,910,000 per second. 101 nanoseconds per run.' bench doesn't give 0 ns. It's not too far off, but definitely not accurate, especially if you compare ratios. #bench doesn't measure the effects of allocation/gc well. The last two code puts pressure on the garbage collector. > > Since this is called only once to fourteen times per frame (see DamageRecorder) -- but usually only once -- we are good with 100 nanoseconds, given that 60 frames-per-second translate to 16 666 667 nanoseconds per frame. Not all machines (physical and virtual) running Squeak are as fast as yours. What's 100ns on your machine, may take up to 3 magnitudes longer on others. In that case, you only have 16 666 microseconds to render, and you spend 100 microseconds on something that could be almost 0. If there were a class variable holding the exception set, it could be reused with no additional cost. It would also let users to add their own exceptions to the set without modifying Trunk code. Levente > > Best, > Marcel > > Am 25.10.2019 20:46:52 schrieb Thiede, Christoph <[hidden email]>: > > I see, but isn't it just their existence what we want to test for to prevent from loads of Debuggers appearing? > > Or should we go the other way around and signal a "DebuggerRaisedNotification" each time before opening a debugger? > > > However, currently, a #deprecated call in a drawing method makes the image unusable ... > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel > Gesendet: Mittwoch, 23. Oktober 2019 15:48:15 > An: John Pfersich via Squeak-dev > Betreff: Re: [squeak-dev] The Trunk: System-mt.1093.mcz > > Why isn't it sufficient to test for UnhandledError instead? Otherwise, we would also need to test for Warning etc. ... > UnhandledError and UnhandledWarning are (private) implementation details of Squeak's exception handling mechanism. They should never be exposed to (or used by) applications/frameworks. > > Best, > Marcel > > Am 22.10.2019 18:50:59 schrieb Thiede, Christoph <[hidden email]>: > > Why isn't it sufficient to test for UnhandledError instead? Otherwise, we would also need to test for Warning etc. ... > > _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel > Gesendet: Dienstag, 15. Oktober 2019 13:18:26 > An: gettimothy via Squeak-dev > Betreff: Re: [squeak-dev] The Trunk: System-mt.1093.mcz > Yeah, I wonder whether we should expand "Error" to "Error, Halt"? > Best, > Marcel > > Am 15.10.2019 12:45:42 schrieb Balázs Kósi <[hidden email]>: > > Hi Hannes! > > This morning I've just run into this exact same situation: putting a halt into a method, called by a morph's #drawOn: > makes the image unusable. > > The problem stems from WorldState >> displayWorldSafely: being safe only for Errors and not for other kind of > Exceptions, and Halt being only an Exception not an Error. > > For a quick fix add Halt to the handled exceptions in #displayWorldSafely: > [aWorld displayWorld. finished := true] on: Error, Halt do: [:ex | > Balázs > > > |
Hi Levente, that's correct. Thanks that reminder. So we need a benchmark on a slower machine to justify that class variable. Until then, your speculation is as good as my fast machine. :-D I do like the point of the extensibility through a class variable though... Best, Marcel
|
Raspberry Pi 3 Model B+ (2017) 62 nanoseconds 1.11 microseconds 1.37 microseconds SqueakJS (Squeak 5.0) on my machine 2 microseconds 24 microseconds 28 microseconds ** What are better ways to benchmark "Error, Halt, Warning" than via #bench? Best, Marcel
|
Free forum by Nabble | Edit this page |