Smalltalk › Squeak › Squeak VM

Progress changes break VMMaker

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Eliot Miranda-2

Progress changes break VMMaker

Hi All, Hi Chris,

something in the changes to ProcessInitiationException done in ToolBuilder-Kernel-cmm.48/49/52 breaks the VMMaker. i.e. the following prints nil 5 times to the Transcript instead of printing #caught 5 times.

['Progressing' displayProgressFrom: 1 to: 5 during:

[:bar|

1 to: 5 do:

[:i|

Transcript cr; print: (Notification new tag: #getVMMaker; signal); flush.

bar value: i]]]

on: Notification

do:[:ex|

ex tag == #getVMMaker

ifTrue: [ex resume: #caught]

ifFalse: [ex pass]]

Any help in fixing this appreciated!

Interestingly in the following count is 1

| count |

count := 0.

['Progressing' displayProgressFrom: 1 to: 5 during:

[:bar|

1 to: 5 do:

[:i|

Transcript cr; print: (Notification new tag: #getVMMaker; signal); flush.

bar value: i]]]

on: Notification

do:[:ex|

count := count + 1.

ex tag == #getVMMaker

ifTrue: [ex resume: #caught]

ifFalse: [ex pass]].

count 1

--
best,

Eliot

Balázs Kósi-2

Re: Progress changes break VMMaker

Hi,

Executing your example, these things happen:

- String >> displayProgressFrom:to:during: throws a
ProgressInitiationException, which is a Notification
- Your handler block passes that notification
- It executes its defaultAction, which includes executing the during block

So the problem is that execution of the during block happens outside
your Notification handling.

Btw the comment of ToolBuilder-Kernel-cmm.52 says:
"Fix ability to safely catch Notification so that, if
#displayProgressAt:from:to:during: is sent, will actually execute the
during block."

It would be help to see, what situation was fixed by this change. It's
still not entirely safe to catch Notifications around display
progress calls. E.g. if you send #resume: to the Notifications you
catch, the during block won't run.

A quick fix, at least for the example, is to move the Notification
handling inside the during block.
Another is to change the superclass of ProgressInitiationException
from Notification to Exception.

Cheers, Balázs

Balázs Kósi-2

Re: Progress changes break VMMaker

> Another is to change the superclass of ProgressInitiationException
> from Notification to Exception.
Actually I don't understand why exactly this works. It could be something like
that you can't activate an exception handling block more than once, and now
we activating it only once, but in the original setting it was activated by the
ProgressInitiationException, and it won't trigger for the subsequently
signalled Notifications?

Balázs

Balázs Kósi-2

Re: Progress changes break VMMaker

I poked around a bit more, and found a method to handle these kind of
situations: #rearmHandlerDuring:
You could rewrite the exception handling block to something like this:

[ :ex |
ex tag == #getVMMaker
ifTrue: [ ex resume: #caught ]
ifFalse: [ ex rearmHandlerDuring: [ ex pass ] ] ]

and get five #cought on the Transcript

Eliot Miranda-2

Re: Progress changes break VMMaker

On Sat, Jun 23, 2012 at 10:13 AM, Balázs Kósi <[hidden email]> wrote:

I poked around a bit more, and found a method to handle these kind of
situations: #rearmHandlerDuring:
You could rewrite the exception handling block to something like this:

[ :ex |

ex tag == #getVMMaker
ifTrue: [ ex resume: #caught ]

ifFalse: [ ex rearmHandlerDuring: [ ex pass ] ] ]

and get five #cought on the Transcript

Thanks, Balázs!!

--
best,

Eliot

Eliot Miranda-2

Re: Progress changes break VMMaker

In reply to this post by Balázs Kósi-2

On Sat, Jun 23, 2012 at 10:13 AM, Balázs Kósi <[hidden email]> wrote:

I poked around a bit more, and found a method to handle these kind of
situations: #rearmHandlerDuring:
You could rewrite the exception handling block to something like this:

[ :ex |

ex tag == #getVMMaker
ifTrue: [ ex resume: #caught ]

ifFalse: [ ex rearmHandlerDuring: [ ex pass ] ] ]

and get five #cought on the Transcript

So is this a hack that points to a bug in the exception handling system or what? I don't have time to think about this carefully right now, but it looks like this is covering up a serious bug in the exception system. Thoughts?

--
best,

Eliot