- Pharo-dev - lists.pharo.org

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

by Alistair Grant

Hi Denis, This is a really interesting discussion, and I haven't wrapped my head around it properly yet, but one initial observation: On Wed, 18 Dec 2019 at 21:45, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 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). 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. One other thing to keep in mind, UnhandledError is a subclass of Exception. 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. HTH, Alistair

Dec. 19, 2019

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

by Denis Kudriashov

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] Interesting bug or feature in exception processing logic

by Denis Kudriashov

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. 18, 2019

Interesting bug or feature in exception processing logic

by Denis Kudriashov

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. 18, 2019

Re: [Pharo-dev] [Pharo-users] TaskIt

by Ben Coman

On Mon, 16 Dec 2019 at 18:41, Santiago Bragagnolo < santiagobragagnolo(a)gmail.com> wrote: > Hi everybody! > We are starting to discuss with norbert about letting taskit to leave > my incubator (my github account to go elsewhere). I have being thinking > about it since long time, since i would like it to allow taskit to evolve > into more than just my needs and wishes. > > The sidequestion i am bringing today it may seem (or even be) almost > scholastic at this point, but i think it should have some space. > The question is if to move it to pharo-contributions, or if to create a > new pharo-processing. > I know a bit of what TaskIt is, but not what "processing" is in-general. Can you clue me in? cheers -ben

Dec. 17, 2019

Re: [Pharo-dev] [Mm10s] 2019-12-16

by Esteban Lorenzano

> On 17 Dec 2019, at 23:15, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Tue, 17 Dec 2019 at 16:22, tesonep(a)gmail.com <mailto:tesonep@gmail.com> <tesonep(a)gmail.com <mailto:tesonep@gmail.com>> wrote: > My report, some are the same than Esteban, as we work a lot together :D > > ### Last week: > > - (Pair Programming with Esteban) Modifying the TFFI callbacks to > include information about the Smalltalk block in the plugin data > structure. This improves the debugging experience and the detection of > errors when a Callback in the image side is garbage collected. > > - (Pair Programming with Esteban) Compiling the Queue based > ThreaddedFFI plugin to use the latest libffi version. This is required > to build in Catalina. > > - (Pair Programming with Esteban) Adding synchronization code to > correctly interrupt the AIO waiting idle loop. This is still work in > progress as we have to test more scenarios. This modification allows > us to extend enormously the idle time of the relinquish processor > primitive without losing events nor delays. > > This is super cool. I'm interested in seeing what the changes were. Are there a few commits/PRs you could point to? We are preparing the PR to headless :P https://github.com/tesonep/opensmalltalk-vm/tree/merge-headless-worker-thre… <https://github.com/tesonep/opensmalltalk-vm/tree/merge-headless-worker-thre…> Esteban > > cheers -ben

Dec. 17, 2019

Re: [Pharo-dev] [Mm10s] 2019-12-16

by Ben Coman

On Tue, 17 Dec 2019 at 16:22, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > My report, some are the same than Esteban, as we work a lot together :D > > ### Last week: > > - (Pair Programming with Esteban) Modifying the TFFI callbacks to > include information about the Smalltalk block in the plugin data > structure. This improves the debugging experience and the detection of > errors when a Callback in the image side is garbage collected. > > - (Pair Programming with Esteban) Compiling the Queue based > ThreaddedFFI plugin to use the latest libffi version. This is required > to build in Catalina. > > - (Pair Programming with Esteban) Adding synchronization code to > correctly interrupt the AIO waiting idle loop. This is still work in > progress as we have to test more scenarios. This modification allows > us to extend enormously the idle time of the relinquish processor > primitive without losing events nor delays. > This is super cool. I'm interested in seeing what the changes were. Are there a few commits/PRs you could point to? cheers -ben

Dec. 17, 2019

Re: [Pharo-dev] [Pharo-users] TaskIt

by Esteban Lorenzano

> On 17 Dec 2019, at 15:38, Torsten Bergmann <astares(a)gmx.de> wrote: > > Santiago wrote: >> What if we have links to all the groups in Pharo-project (pharo-misc, >> pharo-processing, pharo-robotics, pharo-web) ? I can do the firsts steps if >> we agree in here. > > Hi Santiago, > > yes - we should link the groups from the main "pharo-project" so they are easier to find. Here are the ones I know: > > 1. https://github.com/pharo-project > 2. https://github.com/pharo-contributions (general community managed contributions) > 3. https://github.com/pharo-rdbms (relational database support) > 4. https://github.com/pharo-nosql (NoSQL database support) > 5. https://github.com/pharo-sql (points to https://github.com/pharo-rdbms) > 6. https://github.com/pharo-robotics (Robotics related) > 7. https://github.com/pharo-brand (Brand Assets to do some marketing) > > > 8. https://github.com/pharo-db (looks like offical DB stuff, but created by Todd Blanchard to assemble some database projects) > > > Not existing (yet), dont know why you need/mentioned them > > https://github.com/pharo-misc > https://github.com/pharo-processing > https://github.com/pharo-we > > For TaskIt maybe you start in "pharo-contributions" and if Pharo has more projects in similar directions an own separate group > could be created. +1 > > I'm not sure if an own mailinglist other than "Pharo-users" makes sense but https://lists.pharo.org now also meanwhile got > an additional "Pharo-iot" and "Workflow-engine" mailinglist. > > Thanks > T. >

Dec. 17, 2019

Re: [Pharo-dev] [Pharo-users] TaskIt

by Torsten Bergmann

Santiago wrote: >What if we have links to all the groups in Pharo-project (pharo-misc, >pharo-processing, pharo-robotics, pharo-web) ? I can do the firsts steps if >we agree in here. Hi Santiago, yes - we should link the groups from the main "pharo-project" so they are easier to find. Here are the ones I know: 1. https://github.com/pharo-project 2. https://github.com/pharo-contributions (general community managed contributions) 3. https://github.com/pharo-rdbms (relational database support) 4. https://github.com/pharo-nosql (NoSQL database support) 5. https://github.com/pharo-sql (points to https://github.com/pharo-rdbms) Â 6. https://github.com/pharo-robotics (Robotics related) 7. https://github.com/pharo-brand (Brand Assets to do some marketing) 8. https://github.com/pharo-db (looks like offical DB stuff, but created by Todd Blanchard to assemble some database projects) Not existing (yet), dont know why you need/mentioned them https://github.com/pharo-misc Â https://github.com/pharo-processingÂ https://github.com/pharo-we For TaskIt maybe you start in "pharo-contributions" and if Pharo has more projects in similar directions an own separate group could be created. I'm not sure if an own mailinglist other than "Pharo-users" makes sense but https://lists.pharo.org now also meanwhile got an additional "Pharo-iot" and "Workflow-engine" mailinglist. Thanks T.Â

Dec. 17, 2019

[Pharo 8.0] Build #1081: 5343-Inconsistency-in-the-rules-relating-to-checking-the-code-of-methods

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

There is a new Pharo build available! The status of the build #1081 was: SUCCESS. The Pull Request #5358 was integrated: "5343-Inconsistency-in-the-rules-relating-to-checking-the-code-of-methods" Pull request url: https://github.com/pharo-project/pharo/pull/5358 Issue Url: https://github.com/pharo-project/pharo/issues/5343 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 17, 2019