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

[Pharo 8.0] Build #1085: Hiding the methods from TraitedClass in Calypso.

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

There is a new Pharo build available! The status of the build #1085 was: SUCCESS. The Pull Request #5386 was integrated: "Hiding the methods from TraitedClass in Calypso." Pull request url: https://github.com/pharo-project/pharo/pull/5386 Issue Url: https://github.com/pharo-project/pharo/issues/hiding Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2019

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

by Nicolas Anquetil

actually the problem arose from some old code that I tried to load and failed to. So I guess at some point in the past (pharo4 or prior) it was working : --- PPExpressParserTests>>testReal3 self parse: '-1.1333e3333' rule: #literal. self assert: (result value = -1.1333e3333). self assert: (PPSmalltalkParser parseExpression: '- 1.1333e3333') = result rbNode --- nicolas On Fri, 2019-12-20 at 10:21 +0100, Sven Van Caekenberghe wrote: > Yes, the difference is not good. > > Indeed, > > Float fmax. "1.7976931348623157e308" > > The reason > > Number readFrom: '7.5e333'. > > gives infinity is actual not because of the reading, but because of > > 75e332 asFloat. > > Which is probably correct. > > The failure of > > Number readFrom: '7.5e3333'. > > is because of NumberParser>>#readExponent > > However, the test at the end is probably wrong. > > Float emax > > is a binary number, not a decimal one, IIUC. > > Nicolas (nice) ? > > > On 19 Dec 2019, at 19:28, tbrunz <wild.ideas(a)gmail.com> wrote: > > > > 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 > > > > -- Nicolas Anquetil RMod team -- Inria Lille

Dec. 20, 2019

[Pharo 8.0] Build #1084: rollback-bad-comment-when-copying-class

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

There is a new Pharo build available! The status of the build #1084 was: FAILURE. The Pull Request #5390 was integrated: "rollback-bad-comment-when-copying-class" Pull request url: https://github.com/pharo-project/pharo/pull/5390 Issue Url: https://github.com/pharo-project/pharo/issues/rollback Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2019

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

by Sven Van Caekenberghe

Yes, the difference is not good. Indeed, Float fmax. "1.7976931348623157e308" The reason Number readFrom: '7.5e333'. gives infinity is actual not because of the reading, but because of 75e332 asFloat. Which is probably correct. The failure of Number readFrom: '7.5e3333'. is because of NumberParser>>#readExponent However, the test at the end is probably wrong. Float emax is a binary number, not a decimal one, IIUC. Nicolas (nice) ? > On 19 Dec 2019, at 19:28, tbrunz <wild.ideas(a)gmail.com> wrote: > > 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. 20, 2019

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

by Denis Kudriashov

ÑÑ, 19 Ð´ÐµÐº. 2019 Ð³. Ð² 21:43, Denis Kudriashov <dionisiydk(a)gmail.com>: > I checked Squeak. All my examples work consistently there: UnhandledError > handler is always triggered. > Even more: signalling new error from the handler block passes it from the > original signallerContext: > > [ >> >> [ 1/0 ] on: MyTestError do: [ :e | self halt ] >> >> ] on: ZeroDivide do: [ :z | MyTestError signal ] >> >> > This code halts in Squeak. > Squeak has special "activeHandle" logic in #handleSignal: code: Context>>handleSignal: exception "Sent to handler (on:do:) contexts only. If my exception class (first arg) handles exception and the handler is active then execute my handle block (second arg), otherwise forward this message to the next handler context. If none left, execute exception's defaultAction (see nil>>handleSignal:)." | handlerActive val | "If the context has been returned from the handlerActive temp var may not be accessible." handlerActive := stackp >= 3 and: [(self tempAt: 3) == true]. (((self tempAt: 1) handles: exception) and: [handlerActive]) ifFalse: [^self nextHandlerContext handleSignal: exception]. exception privHandlerContext: self contextTag. self tempAt: 3 put: false. "disable self while executing handle block" val := [(self tempAt: 2) cull: exception] ensure: [self tempAt: 3 put: true]. self return: val "return from self if not otherwise directed in handle block" This flag is used by VM primitive to lookup next handler. We should just copy this code into Pharo with corresponding tests

Dec. 19, 2019

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

by Denis Kudriashov

I checked Squeak. All my examples work consistently there: UnhandledError handler is always triggered. Even more: signalling new error from the handler block passes it from the original signallerContext: [ > > [ 1/0 ] on: MyTestError do: [ :e | self halt ] > > ] on: ZeroDivide do: [ :z | MyTestError signal ] > > This code halts in Squeak.

Dec. 19, 2019

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

by Alistair Grant

Hi Denis, Thanks very much for the clarification in your previous email (which I haven't quoted here), I did indeed misunderstand the point you were making. On Thu, 19 Dec 2019 at 19:40, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 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. Confirmed. > 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 I thought I'd take a look at VisualWorks (8.3) to see what it does: it has the same behaviour as with your fix above. This opens some other interesting possibilities. Changing some names and reinterpreting your original example: [ result := [ MyResumableError signal ] on: UnhandledError do: [ :e | self doUltimateFallback ] ] on: MyResumableError do: [ :e | e resume: 42 ]. The MyResumableError handler may be way down the call stack. While the code is more than a little contrived, it does demonstrate the possibility of allowing callers to handle exceptions, but then have a fallback if everything else fails. Great detective work! Thanks, Alistair

Dec. 19, 2019

Re: [Pharo-dev] Why UnhandledError is not the only way to open debugger?

by Steven Costiou

Le 2019-12-19 19:54, Denis Kudriashov a Ã©crit : > Or in other words why Halt and Warning open debugger directly instead of using UnhandledError signalling? > > In Squeak it's all going though UnhandledError. Hi Denis, Thomas Dupriez made a nice documentation from existing materials about how exceptions are handled: -https://raw.githubusercontent.com/pharo-open-documentation/pharo-wiki/master/General/Exceptions_Image_WhatHappensWhenAnExceptionIsSignalled.png - https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/… I am also interested in deeply understanding these mechanics because I have strange behavior with the new spec debugger when it comes to stepping over code that produces an exception and how to "catch it" to display useful information in the gui. I am going into vacations tomorrow with no or few internet, so I will only follow from far away but not participate until january. Steven.

Dec. 19, 2019

Why UnhandledError is not the only way to open debugger?

by Denis Kudriashov

Or in other words why Halt and Warning open debugger directly instead of using UnhandledError signalling? In Squeak it's all going though UnhandledError.

Dec. 19, 2019

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

by Denis Kudriashov

I will collect here other issues if I will find them. Looking in Context methods which I mentioned here I found that debugger is broken for stepping through warnings. And it means that debugging deprecated methods can hang debugger. I will create another thread on this issue because it has more questions on current exceptions design. ÑÑ, 19 Ð´ÐµÐº. 2019 Ð³. Ð² 18:39, Denis Kudriashov <dionisiydk(a)gmail.com>: > 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