<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi Levente,<div><br></div><div>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</div><div><br></div><div>I do like the point of the extensibility through a class variable though...</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 29.10.2019 16:20:33 schrieb Levente Uzonyi <leves@caesar.elte.hu>:</p><div style="font-family:Arial,Helvetica,sans-serif">On Tue, 29 Oct 2019, Marcel Taeumel wrote:
<br>
<br>> Hi Christoph.
<br>> > However, currently, a #deprecated call in a drawing method makes the image unusable ...
<br>>
<br>> 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
<br>> mentioned for #displayWorldSafely.
<br>>
<br>> Since the exception mechanism can be used to implement dynamic scope (see CurrentReadOnlySourceFiles), we should never catch Exception in general to install such handlers.
<br>>
<br>> Warning might be a nice addition to #displayWorldSafely.
<br>>
<br>> [Error] bench '219,000,000 per second. 4.57 nanoseconds per run.'
<br>> [Error, Halt] bench '11,900,000 per second. 84.4 nanoseconds per run.'
<br>> [Error, Halt, Warning] bench '9,910,000 per second. 101 nanoseconds per run.'
<br>
<br>#bench is not suitable to measure things that are fairly quick, because []
<br>bench doesn't give 0 ns. It's not too far off, but definitely not
<br>accurate, especially if you compare ratios.
<br>
<br>#bench doesn't measure the effects of allocation/gc well. The last two
<br>code puts pressure on the garbage collector.
<br>
<br>>
<br>> 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.
<br>
<br>Not all machines (physical and virtual) running Squeak are as fast as
<br>yours. What's 100ns on your machine, may take up to 3 magnitudes longer
<br>on others. In that case, you only have 16 666 microseconds to render, and
<br>you spend 100 microseconds on something that could be almost 0.
<br>
<br>If there were a class variable holding the exception set, it could be
<br>reused with no additional cost. It would also let users to add their own
<br>exceptions to the set without modifying Trunk code.
<br>
<br>Levente
<br>
<br>>
<br>> Best,
<br>> Marcel
<br>>
<br>> Am 25.10.2019 20:46:52 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>:
<br>>
<br>> I see, but isn't it just their existence what we want to test for to prevent from loads of Debuggers appearing?
<br>>
<br>> Or should we go the other way around and signal a "DebuggerRaisedNotification" each time before opening a debugger?
<br>>
<br>>
<br>> However, currently, a #deprecated call in a drawing method makes the image unusable ...
<br>>
<br>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
<br>> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
<br>> Gesendet: Mittwoch, 23. Oktober 2019 15:48:15
<br>> An: John Pfersich via Squeak-dev
<br>> Betreff: Re: [squeak-dev] The Trunk: System-mt.1093.mcz
<br>> > Why isn't it sufficient to test for UnhandledError instead? Otherwise, we would also need to test for Warning etc. ...
<br>> UnhandledError and UnhandledWarning are (private) implementation details of Squeak's exception handling mechanism. They should never be exposed to (or used by) applications/frameworks.
<br>>
<br>> Best,
<br>> Marcel
<br>>
<br>> Am 22.10.2019 18:50:59 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>:
<br>>
<br>> Why isn't it sufficient to test for UnhandledError instead? Otherwise, we would also need to test for Warning etc. ...
<br>>
<br>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
<br>> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
<br>> Gesendet: Dienstag, 15. Oktober 2019 13:18:26
<br>> An: gettimothy via Squeak-dev
<br>> Betreff: Re: [squeak-dev] The Trunk: System-mt.1093.mcz
<br>> Yeah, I wonder whether we should expand "Error" to "Error, Halt"?
<br>> Best,
<br>> Marcel
<br>>
<br>> Am 15.10.2019 12:45:42 schrieb Balázs Kósi <rebmekop@gmail.com>:
<br>>
<br>> Hi Hannes!
<br>>
<br>> This morning I've just run into this exact same situation: putting a halt into a method, called by a morph's #drawOn:
<br>> makes the image unusable.
<br>>
<br>> The problem stems from WorldState >> displayWorldSafely: being safe only for Errors and not for other kind of
<br>> Exceptions, and Halt being only an Exception not an Error.
<br>>
<br>> For a quick fix add Halt to the handled exceptions in #displayWorldSafely:
<br>> [aWorld displayWorld. finished := true] on: Error, Halt do: [:ex |
<br>> Balázs
<br>>
<br>>
<br>><br></rebmekop@gmail.com></squeak-dev-bounces@lists.squeakfoundation.org></christoph.thiede@student.hpi.uni-potsdam.de></squeak-dev-bounces@lists.squeakfoundation.org></christoph.thiede@student.hpi.uni-potsdam.de></div></blockquote>
</div></body>