[squeak-dev] Regression | Cannot interrupt "[ [] repeat ] fork" anymore

Jaromir Matas mail at jaromir.net
Thu Dec 16 22:27:47 UTC 2021


Hi,
Haha, nice warmup exercise…
This is also equivalent 😊
                ^ ([self vmParameterAt: parameterIndex]
                                on: Error
                                do: [defaultValueOrBlock value]) ifNil: [defaultValueOrBlock value]
Yours removes the unpleasant duplication but as a reader I’d be happy for a comment why do nothing – which is not really “do nothing” but “return nil”.

However, Dave’s the author after all so whatever his preference is 😊

Thanks!
Jaromir

From: Thiede, Christoph<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>
Sent: Thursday, December 16, 2021 23:03
To: mail at jaromir.net<mailto:mail at jaromir.net>; squeak-dev at lists.squeakfoundation.org<mailto:squeak-dev at lists.squeakfoundation.org>
Subject: AW: Regression | Cannot interrupt "[ [] repeat ] fork" anymore

Or even shorter, at a price of being hypothetically a few byte steps more expensive:

vmParameterAt: parameterIndex ifAbsent: defaultValueOrBlock
"Answer a VM parameter or defaultValueOrBlock value if out of range
or if the VM does not provide a value for this parameter. A VM parameter
is typically numeric or boolean, and if not implemented will be nil."
^ ([self vmParameterAt: parameterIndex]
on: Error do: [])
ifNil: [defaultValueOrBlock value]


Best,

Christoph

Von: Thiede, Christoph
Gesendet: Donnerstag, 16. Dezember 2021 22:58:34
An: mail at jaromir.net; squeak-dev at lists.squeakfoundation.org
Betreff: AW: Regression | Cannot interrupt "[ [] repeat ] fork" anymore


Hi Jaromir,



oops, you are totally right, sorry, thank you! Hmm ... I still do not like evaluating the defaultValueOrBlock inside the exception handler.



Would you agree with this version? :-)


vmParameterAt: parameterIndex ifAbsent: defaultValueOrBlock
"Answer a VM parameter or defaultValueOrBlock value if out of range
or if the VM does not provide a value for this parameter. A VM parameter
is typically numeric or boolean, and if not implemented will be nil."
| result |
[result := self vmParameterAt: parameterIndex]
on: Error
do: [^ defaultValueOrBlock value].
^ result ifNil: [defaultValueOrBlock value]


Best,

Christoph

Von: mail at jaromir.net <mail at jaromir.net>
Gesendet: Donnerstag, 16. Dezember 2021 22:16:28
An: squeak-dev at lists.squeakfoundation.org; Thiede, Christoph
Betreff: Re: Regression | Cannot interrupt "[ [] repeat ] fork" anymore

Hi Christoph,

> > I just wanted to suggest
> >                 ^ [(self vmParameterAt: parameterIndex)
> >                                                 ifNil: [defaultValueOrBlock value]]
> >                                 on: Error
> >                                 do: [defaultValueOrBlock value]
>  >
> > i.e. without the return inside ifNil block…
>
> The only effective difference would be that if defaultValueOrBlock is a block and raises an error, it would be evaluated a second time.
>
I still don't quite understand: if defaultValueOrBlock is a block and raises an error inside the ifNil block then the error would get handled by the above handler regardless whether there's a return inside the ifNil block or not - or not? :) The return should only evaluate after the exception resumes, I think. So actually it seems to me now the return should never get evaluated if defaultValueOrBlock raised an error (unless the error was resumable and resumed).  Or maybe I'm confused :) I'd like to be sure though I know how the evaluation goes in such cases, thanks!

> I cannot make sense of this behavior, can you? :-) Apart from that, the non-local return is a bit slower, I know, but IMHO this should only become an argument if there is no visible change in behavior.
>

Thanks for discussing this.

Best,


~~~
^[^    Jaromir

Sent from Squeak Inbox Talk

On 2021-12-16T20:02:34+00:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:

> Hi Jaromir,
>
>
> > I just wanted to suggest
> >                 ^ [(self vmParameterAt: parameterIndex)
> >                                                 ifNil: [defaultValueOrBlock value]]
> >                                 on: Error
> >                                 do: [defaultValueOrBlock value]
>  >
> > i.e. without the return inside ifNil block…
>
>
> The only effective difference would be that if defaultValueOrBlock is a block and raises an error, it would be evaluated a second time. I cannot make sense of this behavior, can you? :-) Apart from that, the non-local return is a bit slower, I know, but IMHO this should only become an argument if there is no visible change in behavior.
>
>
> > So the default processPreemptionYields value remains false, right?
>
> Apparently - without having studied the details of how preemption works in Squeak. :-)
>
> Best,
> Christoph
>
> ________________________________
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jaromir Matas <mail at jaromir.net>
> Gesendet: Donnerstag, 16. Dezember 2021 20:47:27
> An: The general-purpose Squeak developers list
> Betreff: Re: [squeak-dev] Regression | Cannot interrupt "[ [] repeat ] fork" anymore
>
> Hi Christoph,
> Yes, a good one 😊 I just wanted to suggest
>                 ^ [(self vmParameterAt: parameterIndex)
>                                                 ifNil: [defaultValueOrBlock value]]
>                                 on: Error
>                                 do: [defaultValueOrBlock value]
>
> i.e. without the return inside ifNil block…
>
> I noticed recently the image stopped responding to
> Smalltalk processPreemptionYields: false
>
> So the default processPreemptionYields value remains false, right?
> Best,
> Jaromir
>
> From: Thiede, Christoph<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>
> Sent: Thursday, December 16, 2021 20:29
> To: squeak-dev<mailto:squeak-dev at lists.squeakfoundation.org>
> Subject: Re: [squeak-dev] Regression | Cannot interrupt "[ [] repeat ] fork" anymore
>
>
> Ha, got it! This was a small regression in SmalltalkImage >> #processPreemptionYields from dtl 1/5/2021 19:29 (System-dtl.1261). Fixed in System-ct.1268. :-)
>
>
>
> Best,
>
> Christoph
>
> Von: Thiede, Christoph
> Gesendet: Donnerstag, 16. Dezember 2021 19:29:30
> An: squeak-dev
> Betreff: AW: [squeak-dev] Regression | Cannot interrupt "[ [] repeat ] fork" anymore
>
>
> Hi Dave, hi Marcel,
>
>
>
> one "recent" change I noticed is that one to SmalltalkImage>>#processPreemptionYields by Dave in May, which answered false before but answers true since then. But this is just an observation, I do not know whether this change was justified by a change on the VM side.
>
>
>
> > even if CMD+Dot interrupts the "[ [] repeat ] fork" from the interrupt watcher
>
>
>
> How did you achieve to do this? The interrupt doesn't work for me in this situation.
>
>
>
> Best,
>
> Christoph
>
>
>
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
> Gesendet: Donnerstag, 16. Dezember 2021 15:53:37
> An: squeak-dev
> Betreff: Re: [squeak-dev] Regression | Cannot interrupt "[ [] repeat ] fork" anymore
>
> Hi Christoph, hi Dave, hi all --
>
> "Processor preemptedProcess" does not behave as it used to be. It now answers the current ui process even if CMD+Dot interrupts the "[ [] repeat ] fork" from the interrupt watcher.
>
> Maybe you can spot the issue right away?
>
> ProcessorScheduler >> preemptedProcess
> "Return the process that the currently active process just preempted."
> self activeProcess priority to: 1 by: -1 do: [:priority |
> (quiescentProcessLists at: priority) ifNotEmpty: [:list |
> ^ Smalltalk processPreemptionYields
> ifTrue: [list last]
> ifFalse: [list first]]].
> ^ nil
>
> Best,
> Marcel
>
> Am 16.12.2021 14:33:51 schrieb David T. Lewis <lewis at mail.msen.com>:
> On Thu, Dec 16, 2021 at 11:27:09AM +0100, Marcel Taeumel wrote:
> > Hi all --
> >
> > I am investigating a?? regression revealed via DebuggerTests >> test01UserInterrupt. One cannot interrupt "[ [] repeat ] fork" from a do-it anymore. :-(
> >
> > VM: 202112022203 (32-bit, Windows 10)
> >
> > Update: #20872
> >
> > Since the forked process should run at priority 40 and the "user interrupt watcher" watches at priority 60, this must work. Did we loose a process scheduling point in "[] repeat"? It's still implemented as "[self value. true] whileTrue".
> >
>
> Confirming on Linux and also on an interpreter VM with trunk level V3 image,
> so the issue is in the image, not the VM.
>
> Dave
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211216/4cd96722/attachment.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0CB9301048554EEBA662C4875E74FF8A.png
> Type: image/png
> Size: 141 bytes
> Desc: 0CB9301048554EEBA662C4875E74FF8A.png
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211216/4cd96722/attachment.png>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211216/8b8df5e1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 96268D73652E4CACBFEE647E1586A4B1.png
Type: image/png
Size: 143 bytes
Desc: 96268D73652E4CACBFEE647E1586A4B1.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211216/8b8df5e1/attachment.png>


More information about the Squeak-dev mailing list