December 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Interesting bug or feature in exception processing logic

by Denis Kudriashov

The solution to problem is to resignal UnhandledError instead of simple signalling. Resignal uses original signalContext as a starting point for handlers lookup: UnhandledError>>signalForException: anError ^anError resignalAs: (self new exception: anError; yourself) I played with some of debugger issues and this code really fixes them. For example try debug following script in playground: [ self methodWithError ] on: Error do: [ :e | e logCr. e pass ] With error method: Object>>methodWithError 1/0 Step into #methodWithError and then stepThrough "1/0". In current image it will hands for a while and then it will open another debugger with single error item. The current debugger process will be broken. Now try to apply proposed change for UnhandledError>>signalForException: and repeat experiment. StepThrough "1/0" will move debugger to ZeroDivide signal showing correct stack. Notice that debugging separate "self methodWithError" without outer handler works correctly in both cases. But you should be in clean stack without hidden outer handlers. And in Playground or when you use debugIt it is clean. But you can try in "bad" environment. Execute in browser editor "self halt. self methodWithError". And in debugger just Step Through #methodWithError. It will hangs. Proposed change fixes that. I will prepare PR with tests. But it would be nice to find other broken places which will be fixed ÑÑ, 19 Ð´ÐµÐº. 2019 Ð³. Ð² 00:42, Denis Kudriashov <dionisiydk(a)gmail.com>: > I think this problem could lead to debugger issues with stepOver and > stepThrough. For example: > > Context>>#stepToHome: > ... > context := aContext insertSender: (Context > contextOn: UnhandledError do: [:ex | ... ]) > > It is a method which is used for stepThrough. If current method has outer > handler for Error then the UnhandledError logic will be ignored. > > Step over is based on following method: > > Context>>runUntilErrorOrReturnFrom: aSender > ... > > context := aSender insertSender: (Context > > contextOn: Error do: [:ex | > > error ifNil: [ > > "this is ugly but it fixes the side-effects of not sending an Unhandled > error on Halt" > > error := (ex isKindOf: UnhandledError) ifTrue: [ ex exception ] > ifFalse: [ ex ]. > ... > > I think UnhandledError branch will never be true: > > [ 1/0 ] on: Error do: [:e | e logCr. e3 pass ] > > Handler here is executed only once with ZeroDivide error. > Previous version was based on UnhandledError handler: > > > context := aSender insertSender: (Context > contextOn: UnhandledError, Halt do: [:ex | ...] > > > which had the same issue when there is an outer error handler. > And we have such general error handler (probably introduced in Pharo 6): > > WorldMorph>>becomeActiveDuring: aBlock > > ... > > aBlock > > on: Error > > do: [ :ex | ... ex pass ] > > > Any UI event is processed under this method. > > ÑÑ, 18 Ð´ÐµÐº. 2019 Ð³. Ð² 22:31, Denis Kudriashov <dionisiydk(a)gmail.com>: > >> Users of UnhandledError definitely shows that it is a critical bug. >> >> For example we rely on UnhandledError in Announcer to ensure that all >> subscriptions will be processed independently on errors signalled by any of >> them: >> >> ann := Announcer new. >> ann when: ValueChanged do: [:ann | 1 logCr. 1/0 ]. >> ann when: ValueChanged do: [:ann | 2 logCr. 2/0 ]. >> ann when: ValueChanged do: [:ann | 3 logCr. 3/0 ]. >> >> >> ann announce: ValueChanged new >> >> >> It will show 1, 2, 3 in transcript and open 3 debuggers. Each error is >> deferred to the background process allowing the delivery to continue: >> >> AnnouncementSubscription>>deliver: anAnnouncement >> >> " deliver an announcement to receiver. In case of failure, it will be >> handled in separate process" >> >> >> ^ (self handlesAnnouncement: anAnnouncement ) ifTrue: [ >> >> [action cull: anAnnouncement cull: announcer] >> >> on: UnhandledError fork: [:ex | ex pass ]] >> >> >> Now if you will try to wrap #announce: into handler block the deliver >> will be interrupted by first error: >> >> [ann announce: ValueChanged new] on: ZeroDivide do: [ :err | err logCr. >> err pass ]. >> >> >> It will open single debugger at first handler error. >> >> ÑÑ, 18 Ð´ÐµÐº. 2019 Ð³. Ð² 20:44, Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> Hi. >>> >>> I played a bit with exceptions trying to detect that given block will >>> open the debugger. My idea was to simply catch UnhandledError which >>> normally means that no outer code handles given error and therefore >>> debugger is appeared. >>> For my surprise the following example works from playground but not from >>> the browser editor: >>> >>> >>> [MyTestError signal ] on: UnhandledError do: [ :e | self halt ] >>> >>> >>> In playground you will see the halt. But from the browser the debugger >>> will show MyTestError. >>> >>> After breaking my head I found that there is a difference how >>> scripts are executed in those tools. In Playground it is a deferred action. >>> But in the browser it is evaluated as a deep event processing code (keymap >>> processing) and there is an outer error handler (on: Error do: ) which does >>> some work and passes the exception further (err pass). >>> Following script demonstrates the difference in the error processing >>> logic when there is an outer handler: >>> >>> >>> [ >>> >>> [MyTestError signal ] on: UnhandledError do: [ :e | self halt ] >>> >>> ] on: MyTestError do: [ :z | z pass] >>> >>> >>> Try it from playground. Second line separately will show the halt while >>> all together it will stop at MyTestError signal. >>> >>> Debugging shows that when the outer handler is processed it sets the >>> handler context into the exception and it skips the existing handler for >>> UnhandledError. >>> >>> The question: is it a feature or a bug? >>> Think also how following code should work (unrelated to UnhandledError >>> logic): >>> >>> [ >>> >>> [ 1/0 ] on: MyTestError do: [ :e | self halt ] >>> >>> ] on: ZeroDivide do: [ :z | MyTestError signal ] >>> >>> >>> Currently it will show MyTestError signal. >>> >>> Best regards, >>> Denis >>> >>

Dec. 19, 2019

Re: [Pharo-dev] pharo compiler on scientific notation

by tbrunz

I would expect that both would result in +Inf. A IEEE-754 'double' overflows around 2e308. Surely both cases should behave the same way..?? -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 19, 2019

Re: [Pharo-dev] Interesting bug or feature in exception processing logic

by Denis Kudriashov

Hi Alistair ÑÑ, 19 Ð´ÐµÐº. 2019 Ð³. Ð² 07:19, Alistair Grant <akgrant0710(a)gmail.com>: > On Wed, 18 Dec 2019 at 21:45, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > Following script demonstrates the difference in the error processing > logic when there is an outer handler: > > > > [ > > > > [MyTestError signal ] on: UnhandledError do: [ :e | self halt ] > > > > ] on: MyTestError do: [ :z | z pass] > > > > > > Try it from playground. Second line separately will show the halt while > all together it will stop at MyTestError signal. > > > > Debugging shows that when the outer handler is processed it sets the > handler context into the exception and it skips the existing handler for > UnhandledError. > > It isn't skipping the UnhandledError handler. MyTestError isn't a > subclass of UnhandledError, it's a subclass of Error, so we expect the > first exception handler that is triggered in the code above to be the > MyTestError handler. > Hm. It forces me to think that I did not explain the problem. If your sentence is correct then the following code would not halt: [[MyTestError signal ] on: UnhandledError do: [ :e | self halt ]] fork Notice that I use fork to avoid any "garbage" of outer handlers from the doIt processing machinery. With the handler we #pass the caught error (on: MyTestError do: [ :z | z pass]) which should be equivalent to "not caught scenario" (it should be to my view) but it doesn't (there will be MyTestError instead of halt). > > > > The question: is it a feature or a bug? > > Setting aside whether it is a feature or a bug, it is clearly the > defined behaviour. > Do you still think it is clear semantics? > > > > Think also how following code should work (unrelated to UnhandledError > logic): > > > > [ > > > > [ 1/0 ] on: MyTestError do: [ :e | self halt ] > > > > ] on: ZeroDivide do: [ :z | MyTestError signal ] > > In this case the behaviour should be the same for both the browser and > the playground: the 0 divide exception handler catches 1/0 and signals > MyTestError, which doesn't have a handler, and a debugger is opened. > > Cheers, > Alistair > >

Dec. 19, 2019

[Pharo 8.0] Build #1083: Enhance monticello snapshot class lookup

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1083 was: SUCCESS. The Pull Request #5395 was integrated: "Enhance monticello snapshot class lookup" Pull request url: https://github.com/pharo-project/pharo/pull/5395 Issue Url: https://github.com/pharo-project/pharo/issues/enhancement/mc Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 19, 2019

Re: [Pharo-dev] pharo compiler on scientific notation

by Sven Van Caekenberghe

Because your exponent is not between: Float emin and: Float emax ? In other words it is too large and not representable in a https://en.wikipedia.org/wiki/IEEE_754 double. > On 19 Dec 2019, at 16:02, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > > > In pharo 7, inspecting: 1.0e3333 > > gives: "Reading a number failed -> " > > it works for: 1.0e333 (only three "3") > > is that the expected behaviour ? > > nicolas > > > -- > Nicolas Anquetil > RMod team -- Inria Lille > >

Dec. 19, 2019

pharo compiler on scientific notation

by Nicolas Anquetil

In pharo 7, inspecting: 1.0e3333 gives: "Reading a number failed -> " it works for: 1.0e333 (only three "3") is that the expected behaviour ? nicolas -- Nicolas Anquetil RMod team -- Inria Lille

Dec. 19, 2019

[ANN] TechTalk TODAY âWorking with Spec2 and GTK" BUT TIME CHANGE TO 16h France

by Esteban Lorenzano

Hi, I will give a techtalk today around the work with Spec2 and GTK. But because of personal reasons, I cannot give the talk 17-18h EU, instead, it will be one our earlier. So, this is the appointment: Pharo TechTalk 19 Dec 2019 4:00 PM - 5:00 PM (UTC+01:00) A regular chat about Pharo. Happens on Discord. The Tech talks are open to both members and non-members! Topic: âWorking with Spec2 and GTKâ Here is the event link: https://association.pharo.org/event-3419547 And here is the place where the transmission will be made: https://www.youtube.com/c/EstebanLorenzano/live Iâm sorry for the mess but fatherhood has this issues ;) See you there! Esteban

Dec. 19, 2019

Re: [Pharo-dev] Interesting bug or feature in exception processing logic

by Denis Kudriashov

ÑÑ, 19 Ð´ÐµÐº. 2019 Ð³. Ð² 00:42, Denis Kudriashov <dionisiydk(a)gmail.com>: > I think this problem could lead to debugger issues with stepOver and > stepThrough. For example: > > Context>>#stepToHome: > ... > context := aContext insertSender: (Context > contextOn: UnhandledError do: [:ex | ... ]) > > It is a method which is used for stepThrough. If current method has outer > handler for Error then the UnhandledError logic will be ignored. > > Step over is based on following method: > > Context>>runUntilErrorOrReturnFrom: aSender > ... > > context := aSender insertSender: (Context > > contextOn: Error do: [:ex | > > error ifNil: [ > > "this is ugly but it fixes the side-effects of not sending an Unhandled > error on Halt" > > error := (ex isKindOf: UnhandledError) ifTrue: [ ex exception ] > ifFalse: [ ex ]. > ... > > I think UnhandledError branch will never be true: > > [ 1/0 ] on: Error do: [:e | e logCr. e3 pass ] > > Handler here is executed only once with ZeroDivide error. > Sorry, the mistake is here. It's better to copy scripts to the mail. It should be with Exception. But the result is same - single message in transcript: [ 1/0 ] on: Exception do: [:e | e logCr. e pass ] >

Dec. 19, 2019

Re: [Pharo-dev] Interesting bug or feature in exception processing logic

by Denis Kudriashov

Hi Alistair. ÑÑ, 19 Ð´ÐµÐº. 2019 Ð³. Ð² 07:10, Alistair Grant <akgrant0710(a)gmail.com>: > I think the difference here is that in the playground 'self' is nil, > while in the browser 'self' is the class being inspected. > UndefinedObject>>handleSignal: tells the exception to execute its > #defaultAction, which is to signal the UnhandledError, and thus it > evaluates the block. > #handleSignal: is sent to contexts chain in the stack during error processing which ends up at top context and its nil sender. It is not related to the receiver of messages on the stack. > > One other thing to keep in mind, UnhandledError is a subclass of > Exception. That's correct. But it does not matter for my findings. > It will only catch signals of itself, unlike Error or > Exception, which will catch all their subclasses. So 'MyTestError > signal' can only be caught if something catches it and then signals > UnhandledError. In this case it is the #defaultAction. > Yes, and here is the trick. When error resignals UnhandledError from the defaultAction it is caught by UnhandledError handler but only if there was no outer handler which already processed original error > HTH, > Alistair > >

Dec. 19, 2019

[Pharo 8.0] Build #1082: CleanupASTCache

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1082 was: SUCCESS. The Pull Request #5393 was integrated: "CleanupASTCache" Pull request url: https://github.com/pharo-project/pharo/pull/5393 Issue Url: https://github.com/pharo-project/pharo/issues/CleanupASTCache Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 19, 2019