Smalltalk › Squeak › Squeak - Dev

Installing metacello within a 'Smalltalk run:[]' fails

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 9 messages Options
timrowledge
Reply | Threaded
Open this post in threaded view
♦
♦
|

Installing metacello within a 'Smalltalk run:[]' fails

timrowledge
Running
Installer ensureRecentMetacello
works. (in a 5.3-19435 image)

Wrapping it in
Smalltalk run:[Installer ensureRecentMetacello ]
crashes. Specifically in MetacelloScriptEngine>>#lookupProjectSpecFor: we find that 'registration' is nil on the last line.

Seems a bit odd; possibly sometihng to do with the assorted exception handling in the SmalltalkImage>run: code?

I'm trying to make a simplecommandline  filein that will load a bunch'o'stuff, something that has been doable before, so this is a bit puzzling.

{a bit later}
Hmm, moving the Installer ensureRecentMetacello  outside the run: block lets it install but later use of metacello within the run: block to load Seaside fails because MetacelloIgnorePackageLoaded signal: pkg doesn't return a boolean. So, yeah, probably sometihng to do with the run: handling of exceptions.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many tnuctip does it take to change a lightbulb?”
"Depends what you want them to change it into."




Levente Uzonyi
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Installing metacello within a 'Smalltalk run:[]' fails

Levente Uzonyi
On Wed, 15 Jul 2020, tim Rowledge wrote:

> Running
> Installer ensureRecentMetacello
> works. (in a 5.3-19435 image)
>
> Wrapping it in
> Smalltalk run:[Installer ensureRecentMetacello ]
> crashes. Specifically in MetacelloScriptEngine>>#lookupProjectSpecFor: we find that 'registration' is nil on the last line.
>
> Seems a bit odd; possibly sometihng to do with the assorted exception handling in the SmalltalkImage>run: code?

I think the cause of the problem is that SmalltalkImage >> #run:
catches all Notifications, logs them, and finally #resumes them.
But many Notifications override #defaultAction, and the return value of
that method will be the value the Notification normally returns with when
not handled.
#resume does not send #defaultAction (it sends #defaultResumeValue,
which is rarely used).

IMO the code should not #resume the Notifications just #pass them, so that
they can return with whatever they want (or be handled by an outer
handler).


Levente

>
> I'm trying to make a simplecommandline  filein that will load a bunch'o'stuff, something that has been doable before, so this is a bit puzzling.
>
> {a bit later}
> Hmm, moving the Installer ensureRecentMetacello  outside the run: block lets it install but later use of metacello within the run: block to load Seaside fails because MetacelloIgnorePackageLoaded signal: pkg doesn't return a boolean. So, yeah, probably sometihng to do with the run: handling of exceptions.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> "How many tnuctip does it take to change a lightbulb?”
> "Depends what you want them to change it into."
timrowledge
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Installing metacello within a 'Smalltalk run:[]' fails

timrowledge


> On 2020-07-15, at 7:09 PM, Levente Uzonyi <[hidden email]> wrote:
>
> On Wed, 15 Jul 2020, tim Rowledge wrote:
>
>> Running Installer ensureRecentMetacello works. (in a 5.3-19435 image)
>>
>> Wrapping it in Smalltalk run:[Installer ensureRecentMetacello ]
>> crashes. Specifically in MetacelloScriptEngine>>#lookupProjectSpecFor: we find that 'registration' is nil on the last line.
>> Seems a bit odd; possibly sometihng to do with the assorted exception handling in the SmalltalkImage>run: code?
>
> I think the cause of the problem is that SmalltalkImage >> #run: catches all Notifications, logs them, and finally #resumes them.
> But many Notifications override #defaultAction, and the return value of that method will be the value the Notification normally returns with when not handled.
> #resume does not send #defaultAction (it sends #defaultResumeValue, which is rarely used).

Sounds pretty likely to me. It's another of those 'fun' cases where one tries to handle errors that you don't necessarily know how to handle. Almost always a problem. I think I have a sigline about that mistake.


>
> IMO the code should not #resume the Notifications just #pass them, so that they can return with whatever they want (or be handled by an outer handler).

Except that surely the problem then becomes that the default action of many Notification type exceptions is to do some UI thing, and the entire point of the run: stuff is to avoid that so it can be a commandline no-UI activity. ;-)

Is it a case of a different type of exception being the right way of doing it within the metacello load code?  I see several Metacello exception classes under Notification, mostly with #defaultAction returning a boolean. Don't see any current exception class that really covers the 'give me a default boolean answer' case.

Exception handling is *such* fun!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Ne auderis delere orbem rigidum meum! = Don't you dare erase my hard disk!



Levente Uzonyi
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Installing metacello within a 'Smalltalk run:[]' fails

Levente Uzonyi
On Wed, 15 Jul 2020, tim Rowledge wrote:

>
>
>> On 2020-07-15, at 7:09 PM, Levente Uzonyi <[hidden email]> wrote:
>>
>> On Wed, 15 Jul 2020, tim Rowledge wrote:
>>
>>> Running Installer ensureRecentMetacello works. (in a 5.3-19435 image)
>>>
>>> Wrapping it in Smalltalk run:[Installer ensureRecentMetacello ]
>>> crashes. Specifically in MetacelloScriptEngine>>#lookupProjectSpecFor: we find that 'registration' is nil on the last line.
>>> Seems a bit odd; possibly sometihng to do with the assorted exception handling in the SmalltalkImage>run: code?
>>
>> I think the cause of the problem is that SmalltalkImage >> #run: catches all Notifications, logs them, and finally #resumes them.
>> But many Notifications override #defaultAction, and the return value of that method will be the value the Notification normally returns with when not handled.
>> #resume does not send #defaultAction (it sends #defaultResumeValue, which is rarely used).
>
> Sounds pretty likely to me. It's another of those 'fun' cases where one tries to handle errors that you don't necessarily know how to handle. Almost always a problem. I think I have a sigline about that mistake.
>
>
>>
>> IMO the code should not #resume the Notifications just #pass them, so that they can return with whatever they want (or be handled by an outer handler).
>
> Except that surely the problem then becomes that the default action of many Notification type exceptions is to do some UI thing, and the entire point of the run: stuff is to avoid that so it can be a commandline no-UI activity. ;-)

AFAIK that is why DummyUIManager exists. It lets you provide answers to
these questions (via Notifications :)) or go with a default value if
possible.


Levente

>
> Is it a case of a different type of exception being the right way of doing it within the metacello load code?  I see several Metacello exception classes under Notification, mostly with #defaultAction returning a boolean. Don't see any current exception class that really covers the 'give me a default boolean answer' case.
>
> Exception handling is *such* fun!
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Ne auderis delere orbem rigidum meum! = Don't you dare erase my hard disk!

Chris Muller-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Installing metacello within a 'Smalltalk run:[]' fails

Chris Muller-3
Hi Tim and Levente,

IMO, the shortcoming is in the class library not strictly and clearly defining a Notification as an output, while providing a separate, resumable Request, for input.  Because of that, over time, clients (mis)used Notification as a way to dynamically request input, with inconsistent use of #defaultAction to either resume with a defaultValue, or pop up a UI that simply returns a value (without resuming).

This has basically rendered any and all handling of Notification impossible to be correct for all cases.  It has no way to tell them apart, which is the responsibility of the signalers, not the handler.  So Notification essentially became a catch-all common-superclass "categorizer"...  and a very bad one, at that.

As long as Notification>>#defaultAction remains 

    ^nil 

instead of 

      self resume

then Smalltalk>>#run: must handle Notification, otherwise, what Tim said would happen with headless apps, will happen.

Tim, I'm sure you've figured that those Metacello exceptions can be handled within your run: block.  Something like:

Smalltalk run:
     [ ...
     [ ensureMetacello ] on: MetacelloNotification do: [ : noti | noti defaultAction ].
     ... ]

I agree, you shouldn't have to, it'd be so much nicer if they'd inherited from something besides Notification...

 - Chris


On Thu, Jul 16, 2020 at 7:50 AM Levente Uzonyi <[hidden email]> wrote:

>
> On Wed, 15 Jul 2020, tim Rowledge wrote:
>
> >
> >
> >> On 2020-07-15, at 7:09 PM, Levente Uzonyi <[hidden email]> wrote:
> >>
> >> On Wed, 15 Jul 2020, tim Rowledge wrote:
> >>
> >>> Running Installer ensureRecentMetacello works. (in a 5.3-19435 image)
> >>>
> >>> Wrapping it in Smalltalk run:[Installer ensureRecentMetacello ]
> >>> crashes. Specifically in MetacelloScriptEngine>>#lookupProjectSpecFor: we find that 'registration' is nil on the last line.
> >>> Seems a bit odd; possibly sometihng to do with the assorted exception handling in the SmalltalkImage>run: code?
> >>
> >> I think the cause of the problem is that SmalltalkImage >> #run: catches all Notifications, logs them, and finally #resumes them.
> >> But many Notifications override #defaultAction, and the return value of that method will be the value the Notification normally returns with when not handled.
> >> #resume does not send #defaultAction (it sends #defaultResumeValue, which is rarely used).
> >
> > Sounds pretty likely to me. It's another of those 'fun' cases where one tries to handle errors that you don't necessarily know how to handle. Almost always a problem. I think I have a sigline about that mistake.
> >
> >
> >>
> >> IMO the code should not #resume the Notifications just #pass them, so that they can return with whatever they want (or be handled by an outer handler).
> >
> > Except that surely the problem then becomes that the default action of many Notification type exceptions is to do some UI thing, and the entire point of the run: stuff is to avoid that so it can be a commandline no-UI activity. ;-)
>
> AFAIK that is why DummyUIManager exists. It lets you provide answers to
> these questions (via Notifications :)) or go with a default value if
> possible.
>
>
> Levente
>
> >
> > Is it a case of a different type of exception being the right way of doing it within the metacello load code?  I see several Metacello exception classes under Notification, mostly with #defaultAction returning a boolean. Don't see any current exception class that really covers the 'give me a default boolean answer' case.
> >
> > Exception handling is *such* fun!
> >
> > tim
> > --
> > tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> > Useful Latin Phrases:- Ne auderis delere orbem rigidum meum! = Don't you dare erase my hard disk!
>
timrowledge
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Installing metacello within a 'Smalltalk run:[]' fails

timrowledge


> On 2020-07-17, at 7:41 PM, Chris Muller <[hidden email]> wrote:
>
> IMO, the shortcoming is in the class library not strictly and clearly defining a Notification as an output, while providing a separate, resumable Request, for input.  

Yup. Pain, annoyance and time wasted. Sigh.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SEXI: Sign EXtend Integer



Jakob Reschke
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Installing metacello within a 'Smalltalk run:[]' fails

Jakob Reschke
In reply to this post by Chris Muller-3
Chris Muller <[hidden email]> schrieb am Sa., 18. Juli 2020, 04:42:

As long as Notification>>#defaultAction remains 

    ^nil 

instead of 

      self resume

then Smalltalk>>#run: must handle Notification, otherwise, what Tim said would happen with headless apps, will happen.

resume must not be called from defaultAction according to the ANSI standard. Squeak may differ, but having this in the class library would set a bad example for applications that implement their own notifications. Notifications resume by default anyway if not curtailed. The return value of defaultAction will be the resume value. So maybe it should read ^ self defaultResumeValue, or the latter selector should not exist in the library  classes.
Chris Muller-3
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Installing metacello within a 'Smalltalk run:[]' fails

Chris Muller-3
Wow, I actually had to look that up, because I found it incredible, but, lo and behold, there it is, under 5.5.4.5 Message: resume.  Does anyone know why ANSI considers it erroneous?

> Notifications resume by default anyway if not curtailed.

A signaled Notification which is never curtailed is nothing, negative even.  Their value is derived by being handled.  But, if you try to handle a Notification, you're basically forced to resume it if you want to retain the nature as if you didn't handle it.  By not guarantee'ing resumption, ANSI forces handlers and signalers to coordinate when they should be decoupled.

> The return value of defaultAction will be the resume value. So maybe it should read ^ self defaultResumeValue, or the latter selector should not exist in the library  classes.

Squeak has a couple of places that've been sending #resume from defaultAction since their inception.  My inclination would be to understand what we want to get out of Notification before making any changes.

For me, a Notification is informational output from a program that should always resume afterward and, therefore, whose defaultAction should be to resume: self defaultResumeValue.  Request should be its own major sub branch of Notification for input.

 - Chris


On Sat, Jul 18, 2020 at 7:10 AM Jakob Reschke <[hidden email]> wrote:
Chris Muller <[hidden email]> schrieb am Sa., 18. Juli 2020, 04:42:

As long as Notification>>#defaultAction remains 

    ^nil 

instead of 

      self resume

then Smalltalk>>#run: must handle Notification, otherwise, what Tim said would happen with headless apps, will happen.

resume must not be called from defaultAction according to the ANSI standard. Squeak may differ, but having this in the class library would set a bad example for applications that implement their own notifications. Notifications resume by default anyway if not curtailed. The return value of defaultAction will be the resume value. So maybe it should read ^ self defaultResumeValue, or the latter selector should not exist in the library  classes.
marcel.taeumel
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Installing metacello within a 'Smalltalk run:[]' fails

marcel.taeumel
Hi all!

Here are related discussions:


Best,
Marcel

Am 19.07.2020 00:31:25 schrieb Chris Muller <[hidden email]>:

Wow, I actually had to look that up, because I found it incredible, but, lo and behold, there it is, under 5.5.4.5 Message: resume.  Does anyone know why ANSI considers it erroneous?

> Notifications resume by default anyway if not curtailed.

A signaled Notification which is never curtailed is nothing, negative even.  Their value is derived by being handled.  But, if you try to handle a Notification, you're basically forced to resume it if you want to retain the nature as if you didn't handle it.  By not guarantee'ing resumption, ANSI forces handlers and signalers to coordinate when they should be decoupled.

> The return value of defaultAction will be the resume value. So maybe it should read ^ self defaultResumeValue, or the latter selector should not exist in the library  classes.

Squeak has a couple of places that've been sending #resume from defaultAction since their inception.  My inclination would be to understand what we want to get out of Notification before making any changes.

For me, a Notification is informational output from a program that should always resume afterward and, therefore, whose defaultAction should be to resume: self defaultResumeValue.  Request should be its own major sub branch of Notification for input.

 - Chris


On Sat, Jul 18, 2020 at 7:10 AM Jakob Reschke <[hidden email]> wrote:
Chris Muller <[hidden email]> schrieb am Sa., 18. Juli 2020, 04:42:

As long as Notification>>#defaultAction remains 

    ^nil 

instead of 

      self resume

then Smalltalk>>#run: must handle Notification, otherwise, what Tim said would happen with headless apps, will happen.

resume must not be called from defaultAction according to the ANSI standard. Squeak may differ, but having this in the class library would set a bad example for applications that implement their own notifications. Notifications resume by default anyway if not curtailed. The return value of defaultAction will be the resume value. So maybe it should read ^ self defaultResumeValue, or the latter selector should not exist in the library  classes.
Free forum by Nabble Edit this page