Smalltalk › Squeak › Squeak - Dev

a few small quit issues I want to note

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

22 messages Options

Eliot Miranda-2

a few small quit issues I want to note

Hi All,

there are a handful of issues on quitting, especially quitting without saving, that bother me. I'm not suggesting we fix these right away but I do want to put them on the list to be fixed. Fast system startup and exit are important, especially in a scripting context.

The first is that I *hate* the QUIT/NO SAVE notice being written to the changes file. This seems entirely unnecessary. Why if one enters the image, doesn't do anything and then quits, must the changes file be written to? This causes minor pain when one has an image/changes under git and one has to revert the changes occasionally (but not the image).

Another issue is that we waste time shutting down the SoundPlugin via primSoundStop in stopPlayerProcess, whether the SOundPlugin is loaded or not. So what happens is that the Vm loads the SoundPlugin just to turn it off. A waste of effort. We could check whether the plugin has been loaded first.

Similarly, Symbol class>>shutDown: anf Form class>>shutDown: do unnecessary processing if the system is just exiting, and not snapshotting and then exiting.

_,,,^..^,,,_

best, Eliot

timrowledge

Re: a few small quit issues I want to note

I kind of agree here.

If nothing has been written to the changelog, then quit/nosave ought not be added - nothing has happened, it doesn't need recording.

For the sound plugin pointless-shutdown it is at least not causing an error should the plugin fail to load, so that's one small blessing. Maybe in SoundPlayer class>>#stopPlayerProcess we should simply do nothing if the PlayerProcess is nil? I think that would work ok with SoundPlayer class>>#playLoop.

> On 2020-09-11, at 10:27 AM, Eliot Miranda <[hidden email]> wrote:
>
> Hi All,
>
> there are a handful of issues on quitting, especially quitting without saving, that bother me. I'm not suggesting we fix these right away but I do want to put them on the list to be fixed. Fast system startup and exit are important, especially in a scripting context.
>
> The first is that I *hate* the QUIT/NO SAVE notice being written to the changes file. This seems entirely unnecessary. Why if one enters the image, doesn't do anything and then quits, must the changes file be written to? This causes minor pain when one has an image/changes under git and one has to revert the changes occasionally (but not the image).
>
> Another issue is that we waste time shutting down the SoundPlugin via primSoundStop in stopPlayerProcess, whether the SOundPlugin is loaded or not. So what happens is that the Vm loads the SoundPlugin just to turn it off. A waste of effort. We could check whether the plugin has been loaded first.
>
> Similarly, Symbol class>>shutDown: anf Form class>>shutDown: do unnecessary processing if the system is just exiting, and not snapshotting and then exiting.
> _,,,^..^,,,_
> best, Eliot
>

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: PDH: Page to Disk for the Hell of it

David T. Lewis

Re: a few small quit issues I want to note

+1 from me too.

Although I would also note that "Smalltalk quitPrimitive" does the job
very effectively, at least on Unix systems. File handles are closed
automatically, and I have never noticed any problems. I'm not sure if
it is safe on Windows though.

Dave

On Fri, Sep 11, 2020 at 01:00:55PM -0700, tim Rowledge wrote:

> I kind of agree here.
>
> If nothing has been written to the changelog, then quit/nosave ought not be added - nothing has happened, it doesn't need recording.
>
> For the sound plugin pointless-shutdown it is at least not causing an error should the plugin fail to load, so that's one small blessing. Maybe in SoundPlayer class>>#stopPlayerProcess we should simply do nothing if the PlayerProcess is nil? I think that would work ok with SoundPlayer class>>#playLoop.
>
> > On 2020-09-11, at 10:27 AM, Eliot Miranda <[hidden email]> wrote:
> >
> > Hi All,
> >
> > there are a handful of issues on quitting, especially quitting without saving, that bother me. I'm not suggesting we fix these right away but I do want to put them on the list to be fixed. Fast system startup and exit are important, especially in a scripting context.
> >
> > The first is that I *hate* the QUIT/NO SAVE notice being written to the changes file. This seems entirely unnecessary. Why if one enters the image, doesn't do anything and then quits, must the changes file be written to? This causes minor pain when one has an image/changes under git and one has to revert the changes occasionally (but not the image).
> >
> > Another issue is that we waste time shutting down the SoundPlugin via primSoundStop in stopPlayerProcess, whether the SOundPlugin is loaded or not. So what happens is that the Vm loads the SoundPlugin just to turn it off. A waste of effort. We could check whether the plugin has been loaded first.
> >
> > Similarly, Symbol class>>shutDown: anf Form class>>shutDown: do unnecessary processing if the system is just exiting, and not snapshotting and then exiting.
> > _,,,^..^,,,_
> > best, Eliot
> >
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: PDH: Page to Disk for the Hell of it
>
>
>

Chris Muller-3

Re: a few small quit issues I want to note

In reply to this post by Eliot Miranda-2

Hi Eliot, may I recommend the "flat-line your image" hot key? It's
really useful for that and other use cases like debugging shutdown
code, or when Morphic gets slammed with events due to a bug that
disrupts the UI. It calls Smalltalk quitPrimitive, so skips all
shutdown processing and logging. It's one of the global command keys,
Cmd+Shift+_.

Another tip to avoid git fake dirty .changes file is, upon launching
the image, immediately Save as... a "_test" image that'll be excluded
from your repository.

With those two easily-accessible paths to a non-logging exit for the
user, I hope we won't rush into changing the logging of
exit-without-save. That's a pretty legacy feature that I do use
occasionally to help me keep track of which images I'm looking at,
without wanting to change their .image file timestamp.

That SoundPlugin one does sound like one to optimize, but for the
Form, I think you want that processing because it's about what bits
you want to record in the image file, regardless whether continuing
the session.

- Chris

On Fri, Sep 11, 2020 at 12:27 PM Eliot Miranda <[hidden email]> wrote:

>
> Hi All,
>
> there are a handful of issues on quitting, especially quitting without saving, that bother me. I'm not suggesting we fix these right away but I do want to put them on the list to be fixed. Fast system startup and exit are important, especially in a scripting context.
>
> The first is that I *hate* the QUIT/NO SAVE notice being written to the changes file. This seems entirely unnecessary. Why if one enters the image, doesn't do anything and then quits, must the changes file be written to? This causes minor pain when one has an image/changes under git and one has to revert the changes occasionally (but not the image).
>
> Another issue is that we waste time shutting down the SoundPlugin via primSoundStop in stopPlayerProcess, whether the SOundPlugin is loaded or not. So what happens is that the Vm loads the SoundPlugin just to turn it off. A waste of effort. We could check whether the plugin has been loaded first.
>
> Similarly, Symbol class>>shutDown: anf Form class>>shutDown: do unnecessary processing if the system is just exiting, and not snapshotting and then exiting.
> _,,,^..^,,,_
> best, Eliot
>

Eliot Miranda-2

Re: a few small quit issues I want to note

On Fri, Sep 11, 2020 at 5:19 PM Chris Muller <[hidden email]> wrote:

Hi Eliot, may I recommend the "flat-line your image" hot key? It's
really useful for that and other use cases like debugging shutdown
code, or when Morphic gets slammed with events due to a bug that
disrupts the UI. It calls Smalltalk quitPrimitive, so skips all
shutdown processing and logging. It's one of the global command keys,
Cmd+Shift+_.

Thanks. However quitting via quitPrimitive is a bad idea. Soon enough we will have a system with ephemerons around files and could expect file vuffers etc to be flushed before exit. So we will want to run pending finalization actions, etc. exiting via the quit primitive without running these activities could well break some applications.

Another tip to avoid git fake dirty .changes file is, upon launching
the image, immediately Save as... a "_test" image that'll be excluded
from your repository.

Not the use case I'm thinking of.

With those two easily-accessible paths to a non-logging exit for the
user, I hope we won't rush into changing the logging of
exit-without-save. That's a pretty legacy feature that I do use
occasionally to help me keep track of which images I'm looking at,
without wanting to change their .image file timestamp.

OK, I abandon the idea. Forget I said anything.

That SoundPlugin one does sound like one to optimize, but for the
Form, I think you want that processing because it's about what bits
you want to record in the image file, regardless whether continuing
the session.

No, the Form thing is compressing forms so they take less space in the image file. A complete waste of time if one is merely quitting.

- Chris

On Fri, Sep 11, 2020 at 12:27 PM Eliot Miranda <[hidden email]> wrote:
>
> Hi All,
>
> there are a handful of issues on quitting, especially quitting without saving, that bother me. I'm not suggesting we fix these right away but I do want to put them on the list to be fixed. Fast system startup and exit are important, especially in a scripting context.
>
> The first is that I *hate* the QUIT/NO SAVE notice being written to the changes file. This seems entirely unnecessary. Why if one enters the image, doesn't do anything and then quits, must the changes file be written to? This causes minor pain when one has an image/changes under git and one has to revert the changes occasionally (but not the image).
>
> Another issue is that we waste time shutting down the SoundPlugin via primSoundStop in stopPlayerProcess, whether the SOundPlugin is loaded or not. So what happens is that the Vm loads the SoundPlugin just to turn it off. A waste of effort. We could check whether the plugin has been loaded first.
>
> Similarly, Symbol class>>shutDown: anf Form class>>shutDown: do unnecessary processing if the system is just exiting, and not snapshotting and then exiting.
> _,,,^..^,,,_
> best, Eliot
>

_,,,^..^,,,_

best, Eliot

Christoph Thiede

Re: a few small quit issues I want to note

Hi,

which entries in the changes file are we talking about in detail?

Allow me to describe one certain use case of the changes file I frequently apply to one of my images: I have a FreshTrunk.image file that I only utilize in order to reproduce bugs or similar stuff but never save changes made to it. However, sometimes I make some experiments in it, i. e. compile a few methods, and at some time I also need to revert these changes later. Because I never overwrite the image file itself, the first entry in the "browse far as back as ..." dialog already lies several months in past. In this particular situation, it is really helpful for me to filter-type '...' into the changes browser, select the latest item, and press Enter to quickly jump to the latest changes made but not saved to the image.

It would be great if this option would not be lost.

Apart from that, accelerating image startup + shutdown sounds reasonable of course!

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Samstag, 12. September 2020 03:02:15
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] a few small quit issues I want to note

On Fri, Sep 11, 2020 at 5:19 PM Chris Muller <[hidden email]> wrote:

Hi Eliot, may I recommend the "flat-line your image" hot key? It's
really useful for that and other use cases like debugging shutdown
code, or when Morphic gets slammed with events due to a bug that
disrupts the UI. It calls Smalltalk quitPrimitive, so skips all
shutdown processing and logging. It's one of the global command keys,
Cmd+Shift+_.

Another tip to avoid git fake dirty .changes file is, upon launching
the image, immediately Save as... a "_test" image that'll be excluded
from your repository.

Not the use case I'm thinking of.

With those two easily-accessible paths to a non-logging exit for the
user, I hope we won't rush into changing the logging of
exit-without-save. That's a pretty legacy feature that I do use
occasionally to help me keep track of which images I'm looking at,
without wanting to change their .image file timestamp.

OK, I abandon the idea. Forget I said anything.

That SoundPlugin one does sound like one to optimize, but for the
Form, I think you want that processing because it's about what bits
you want to record in the image file, regardless whether continuing
the session.

No, the Form thing is compressing forms so they take less space in the image file. A complete waste of time if one is merely quitting.

- Chris

On Fri, Sep 11, 2020 at 12:27 PM Eliot Miranda <[hidden email]> wrote:
>
> Hi All,
>
> there are a handful of issues on quitting, especially quitting without saving, that bother me. I'm not suggesting we fix these right away but I do want to put them on the list to be fixed. Fast system startup and exit are important, especially in a scripting context.
>
> The first is that I *hate* the QUIT/NO SAVE notice being written to the changes file. This seems entirely unnecessary. Why if one enters the image, doesn't do anything and then quits, must the changes file be written to? This causes minor pain when one has an image/changes under git and one has to revert the changes occasionally (but not the image).
>
> Another issue is that we waste time shutting down the SoundPlugin via primSoundStop in stopPlayerProcess, whether the SOundPlugin is loaded or not. So what happens is that the Vm loads the SoundPlugin just to turn it off. A waste of effort. We could check whether the plugin has been loaded first.
>
> Similarly, Symbol class>>shutDown: anf Form class>>shutDown: do unnecessary processing if the system is just exiting, and not snapshotting and then exiting.
> _,,,^..^,,,_
> best, Eliot
>

_,,,^..^,,,_

best, Eliot

Carpe Squeak!

Eliot Miranda-2

Re: a few small quit issues I want to note

Hi Christoph,

On Sep 12, 2020, at 5:05 AM, Thiede, Christoph <[hidden email]> wrote:

Hi,

which entries in the changes file are we talking about in detail?

Allow me to describe one certain use case of the changes file I frequently apply to one of my images: I have a FreshTrunk.image file that I only utilize in order to reproduce bugs or similar stuff but never save changes made to it. However, sometimes I make some experiments in it, i. e. compile a few methods, and at some time I also need to revert these changes later. Because I never overwrite the image file itself, the first entry in the "browse far as back as ..." dialog already lies several months in past. In this particular situation, it is really helpful for me to filter-type '...' into the changes browser, select the latest item, and press Enter to quickly jump to the latest changes made but not saved to the image.

That makes sense. So we do want the QUIT/NO SAVE indication written to the changes file if anything is written to the changes file because we know that when doing crash recovery we want to ignore everything before QUIT/NO SAVE. So, Chris Muller’s objections aside, I would argue that if the changes file is undisturbed (nothing written to it in the current session) when the system is about to quit without saving, it should do so without writing the QUIT/NO SAVE stamp.

Chris, does this work for you or do you still see benefit in the QUIT/NO SAVE stamp when nothing has been logged? Why?

It would be great if this option would not be lost.

I’m most interested in not disturbing the changes file unnecessarily for the REPL image used in vm development and in the packaged app I’m working on (Terf), in our git repository.

With the REPL image if it starts up and evaluates an expression of two (which are not logged) and then quits nothing has changed but the QUIT/NO SAVE has been written, and now my reproducible image/changes pair is no longer in exactly the same state; the changes file has grown.

If I run the app image, launch the app, quit the app and then quit the image nothing has changed except that the QUIT/NO SAVE stamp has been written to the changes. And gif tells me I have a modified file. But I have modified nothing.

So Chris, can you live with having the system not write the QUIT/NO SAVE stamp if the changes file is the same size it was at startup?

Apart from that, accelerating image startup + shutdown sounds reasonable of course!

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Samstag, 12. September 2020 03:02:15
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] a few small quit issues I want to note

On Fri, Sep 11, 2020 at 5:19 PM Chris Muller <[hidden email]> wrote:

Hi Eliot, may I recommend the "flat-line your image" hot key? It's
really useful for that and other use cases like debugging shutdown
code, or when Morphic gets slammed with events due to a bug that
disrupts the UI. It calls Smalltalk quitPrimitive, so skips all
shutdown processing and logging. It's one of the global command keys,
Cmd+Shift+_.

Thanks. However quitting via quitPrimitive is a bad idea. Soon enough we will have a system with ephemerons around files and could expect file vuffers etc to be flushed before exit. So we will want to run pending finalization actions, etc. exiting via the quit primitive without running these activities could well break some applications.

Another tip to avoid git fake dirty .changes file is, upon launching
the image, immediately Save as... a "_test" image that'll be excluded
from your repository.

Not the use case I'm thinking of.

With those two easily-accessible paths to a non-logging exit for the
user, I hope we won't rush into changing the logging of
exit-without-save. That's a pretty legacy feature that I do use
occasionally to help me keep track of which images I'm looking at,
without wanting to change their .image file timestamp.

OK, I abandon the idea. Forget I said anything.

That SoundPlugin one does sound like one to optimize, but for the
Form, I think you want that processing because it's about what bits
you want to record in the image file, regardless whether continuing
the session.

No, the Form thing is compressing forms so they take less space in the image file. A complete waste of time if one is merely quitting.

- Chris

On Fri, Sep 11, 2020 at 12:27 PM Eliot Miranda <[hidden email]> wrote:
>
> Hi All,
>
> there are a handful of issues on quitting, especially quitting without saving, that bother me. I'm not suggesting we fix these right away but I do want to put them on the list to be fixed. Fast system startup and exit are important, especially in a scripting context.
>
> The first is that I *hate* the QUIT/NO SAVE notice being written to the changes file. This seems entirely unnecessary. Why if one enters the image, doesn't do anything and then quits, must the changes file be written to? This causes minor pain when one has an image/changes under git and one has to revert the changes occasionally (but not the image).
>
> Another issue is that we waste time shutting down the SoundPlugin via primSoundStop in stopPlayerProcess, whether the SOundPlugin is loaded or not. So what happens is that the Vm loads the SoundPlugin just to turn it off. A waste of effort. We could check whether the plugin has been loaded first.
>
> Similarly, Symbol class>>shutDown: anf Form class>>shutDown: do unnecessary processing if the system is just exiting, and not snapshotting and then exiting.
> _,,,^..^,,,_
> best, Eliot
>

--

_,,,^..^,,,_

best, Eliot

Christoph Thiede

Re: a few small quit issues I want to note

Hi Eliot,

I think I see your point, but I'm not sure whether we really want to restrict the logging features of Squeak by defining an edge case like this. Without being aware of all the background, one could wonder "why quit 1 has been logged but quit 2 has not been" until you discover that you did not compile any code during the second session. However, that's just a loose thought trying to keep the complexity in the image as low as possible.

As an alternative, couldn't you disable the whole changes file in your REPL process via a script, or maybe even via a VM parameter? Another option would be making the changes file read-only if you do not need to manipulate it anyway. Squeak displays a warning in this situation, but you can still do everything that does not involve compiling afaik.

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Samstag, 12. September 2020 16:31:27
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] a few small quit issues I want to note

Hi Christoph,

On Sep 12, 2020, at 5:05 AM, Thiede, Christoph <[hidden email]> wrote:

Hi,

which entries in the changes file are we talking about in detail?

Allow me to describe one certain use case of the changes file I frequently apply to one of my images: I have a FreshTrunk.image file that I only utilize in order to reproduce bugs or similar stuff but never save changes made to it. However, sometimes I make some experiments in it, i. e. compile a few methods, and at some time I also need to revert these changes later. Because I never overwrite the image file itself, the first entry in the "browse far as back as ..." dialog already lies several months in past. In this particular situation, it is really helpful for me to filter-type '...' into the changes browser, select the latest item, and press Enter to quickly jump to the latest changes made but not saved to the image.

Chris, does this work for you or do you still see benefit in the QUIT/NO SAVE stamp when nothing has been logged? Why?

It would be great if this option would not be lost.

I’m most interested in not disturbing the changes file unnecessarily for the REPL image used in vm development and in the packaged app I’m working on (Terf), in our git repository.

So Chris, can you live with having the system not write the QUIT/NO SAVE stamp if the changes file is the same size it was at startup?

Apart from that, accelerating image startup + shutdown sounds reasonable of course!

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Samstag, 12. September 2020 03:02:15
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] a few small quit issues I want to note

On Fri, Sep 11, 2020 at 5:19 PM Chris Muller <[hidden email]> wrote:

Hi Eliot, may I recommend the "flat-line your image" hot key? It's
really useful for that and other use cases like debugging shutdown
code, or when Morphic gets slammed with events due to a bug that
disrupts the UI. It calls Smalltalk quitPrimitive, so skips all
shutdown processing and logging. It's one of the global command keys,
Cmd+Shift+_.

Thanks. However quitting via quitPrimitive is a bad idea. Soon enough we will have a system with ephemerons around files and could expect file vuffers etc to be flushed before exit. So we will want to run pending finalization actions, etc. exiting via the quit primitive without running these activities could well break some applications.

Another tip to avoid git fake dirty .changes file is, upon launching
the image, immediately Save as... a "_test" image that'll be excluded
from your repository.

Not the use case I'm thinking of.

With those two easily-accessible paths to a non-logging exit for the
user, I hope we won't rush into changing the logging of
exit-without-save. That's a pretty legacy feature that I do use
occasionally to help me keep track of which images I'm looking at,
without wanting to change their .image file timestamp.

OK, I abandon the idea. Forget I said anything.

That SoundPlugin one does sound like one to optimize, but for the
Form, I think you want that processing because it's about what bits
you want to record in the image file, regardless whether continuing
the session.

No, the Form thing is compressing forms so they take less space in the image file. A complete waste of time if one is merely quitting.

- Chris

On Fri, Sep 11, 2020 at 12:27 PM Eliot Miranda <[hidden email]> wrote:
>
> Hi All,
>
> there are a handful of issues on quitting, especially quitting without saving, that bother me. I'm not suggesting we fix these right away but I do want to put them on the list to be fixed. Fast system startup and exit are important, especially in a scripting context.
>
> The first is that I *hate* the QUIT/NO SAVE notice being written to the changes file. This seems entirely unnecessary. Why if one enters the image, doesn't do anything and then quits, must the changes file be written to? This causes minor pain when one has an image/changes under git and one has to revert the changes occasionally (but not the image).
>
> Another issue is that we waste time shutting down the SoundPlugin via primSoundStop in stopPlayerProcess, whether the SOundPlugin is loaded or not. So what happens is that the Vm loads the SoundPlugin just to turn it off. A waste of effort. We could check whether the plugin has been loaded first.
>
> Similarly, Symbol class>>shutDown: anf Form class>>shutDown: do unnecessary processing if the system is just exiting, and not snapshotting and then exiting.
> _,,,^..^,,,_
> best, Eliot
>

--

_,,,^..^,,,_

best, Eliot

Carpe Squeak!

Tobias Pape

Re: a few small quit issues I want to note

In reply to this post by Eliot Miranda-2

> On 12.09.2020, at 16:31, Eliot Miranda <[hidden email]> wrote:
>
> With the REPL image if it starts up and evaluates an expression of two (which are not logged) and then quits nothing has changed but the QUIT/NO SAVE has been written, and now my reproducible image/changes pair is no longer in exactly the same state; the changes file has grown.
>

In that particular case, wouldn't it suffice to just make the Changes file read-only?

Best regards
-Tobias

David T. Lewis

Re: a few small quit issues I want to note

On Sat, Sep 12, 2020 at 06:57:03PM +0200, Tobias Pape wrote:
>
> > On 12.09.2020, at 16:31, Eliot Miranda <[hidden email]> wrote:
> >
> > With the REPL image if it starts up and evaluates an expression of two (which are not logged) and then quits nothing has changed but the QUIT/NO SAVE has been written, and now my reproducible image/changes pair is no longer in exactly the same state; the changes file has grown.
> >
>
> In that particular case, wouldn't it suffice to just make the Changes file read-only?
>

Just exit with Smalltalk quitPrimitive. It's perfectly safe on unix.

Dave

Eliot Miranda-2

Re: a few small quit issues I want to note

In reply to this post by Tobias Pape

Hi Tobias,

On Sat, Sep 12, 2020 at 9:56 AM Tobias Pape <[hidden email]> wrote:

> On 12.09.2020, at 16:31, Eliot Miranda <[hidden email]> wrote:
>
> With the REPL image if it starts up and evaluates an expression of two (which are not logged) and then quits nothing has changed but the QUIT/NO SAVE has been written, and now my reproducible image/changes pair is no longer in exactly the same state; the changes file has grown.
>

In that particular case, wouldn't it suffice to just make the Changes file read-only?

No. Sometimes one wants to file-in code into the REPL.

Best regards
-Tobias

_,,,^..^,,,_

best, Eliot

Eliot Miranda-2

Re: a few small quit issues I want to note

In reply to this post by David T. Lewis

On Sat, Sep 12, 2020 at 10:43 AM David T. Lewis <[hidden email]> wrote:

On Sat, Sep 12, 2020 at 06:57:03PM +0200, Tobias Pape wrote:
>
> > On 12.09.2020, at 16:31, Eliot Miranda <[hidden email]> wrote:
> >
> > With the REPL image if it starts up and evaluates an expression of two (which are not logged) and then quits nothing has changed but the QUIT/NO SAVE has been written, and now my reproducible image/changes pair is no longer in exactly the same state; the changes file has grown.
> >
>
> In that particular case, wouldn't it suffice to just make the Changes file read-only?
>

Just exit with Smalltalk quitPrimitive. It's perfectly safe on unix.

That's hardly the point. The REPL should work on any platform with a command line, Windows included. And e.g. LibTerm.app even gives me a command line on my iPhone ;-)

And it *won't* safe in a system a little more advanced than we have now where ephemerons are used for output streams and we want them to be automatically flushed on exit.

It is possible to get this right.

Dave

_,,,^..^,,,_

best, Eliot

David T. Lewis

Re: a few small quit issues I want to note

On Sat, Sep 12, 2020 at 12:22:23PM -0700, Eliot Miranda wrote:

> On Sat, Sep 12, 2020 at 10:43 AM David T. Lewis <[hidden email]> wrote:
>
> > On Sat, Sep 12, 2020 at 06:57:03PM +0200, Tobias Pape wrote:
> > >
> > > > On 12.09.2020, at 16:31, Eliot Miranda <[hidden email]>
> > wrote:
> > > >
> > > > With the REPL image if it starts up and evaluates an expression of two
> > (which are not logged) and then quits nothing has changed but the QUIT/NO
> > SAVE has been written, and now my reproducible image/changes pair is no
> > longer in exactly the same state; the changes file has grown.
> > > >
> > >
> > > In that particular case, wouldn't it suffice to just make the Changes
> > file read-only?
> > >
> >
> > Just exit with Smalltalk quitPrimitive. It's perfectly safe on unix.
> >
>
> That's hardly the point. The REPL should work on any platform with a
> command line, Windows included. And e.g. LibTerm.app even gives me a
> command line on my iPhone ;-)
> And it *won't* safe in a system a little more advanced than we have now
> where ephemerons are used for output streams and we want them to be
> automatically flushed on exit.
>
>
> It is possible to get this right.

No disagreement on any of that :-)

Dave

>
> Dave
> >
>
>
> --
> _,,,^..^,,,_
> best, Eliot

>

Chris Muller-3

Re: a few small quit issues I want to note

In reply to this post by Eliot Miranda-2

Hi Eliot,

>> Hi Eliot, may I recommend the "flat-line your image" hot key? It's
>> really useful for that and other use cases like debugging shutdown
>> code, or when Morphic gets slammed with events due to a bug that
>> disrupts the UI. It calls Smalltalk quitPrimitive, so skips all
>> shutdown processing and logging. It's one of the global command keys,
>> Cmd+Shift+_.
>
> Thanks. However quitting via quitPrimitive is a bad idea. Soon enough we will have a system with ephemerons around files and could expect file vuffers etc to be flushed before exit. So we will want to run pending finalization actions, etc. exiting via the quit primitive without running these activities could well break some applications.

It's a bad idea as normal course, yes, but a godsend when all you want
to do is stop the process immediately before system memory fills up
(e.g., in a stack-recursion bug scenario).

#quitPrimitive has also been used for Magma's db-recovery test case
since forever. It was the easiest way to simulate the reality that
processes can and do get killed at inopportune times, and allowed me
to place it at exactly the worst place possible for Magma (e.g., write
of a commit, but prior to flush). It may not run pending
finalizations, but I do believe I observed #quitPrimitive properly
closing open file handles (or, maybe the VM?).

The point is, #quitPrimitive does have a couple of use cases,
including even with its dangerous aspects.

>> With those two easily-accessible paths to a non-logging exit for the
>> user, I hope we won't rush into changing the logging of
>> exit-without-save. That's a pretty legacy feature that I do use
>> occasionally to help me keep track of which images I'm looking at,
>> without wanting to change their .image file timestamp.
>
> OK, I abandon the idea. Forget I said anything.

Your call. There's a lot of ground between not rushing and full
abandonment. I simply wanted a moment to be able to think about it.
Not logging when there is no change sounds reasonable at first blush,
but there are also Squeak systems that run a fixed image that don't
save on exit -- it may be useful for operators of those systems to be
able to know when there were interactions with the system, regardless
whether development causing .changes changes was done or not.

>> That SoundPlugin one does sound like one to optimize, but for the
>> Form, I think you want that processing because it's about what bits
>> you want to record in the image file, regardless whether continuing
>> the session.
>
> No, the Form thing is compressing forms so they take less space in the image file. A complete waste of time if one is merely quitting.

Yes, you're right. I was thinking about save+exit vs. save+continue,
but you're referring to quit+no save.

- Chris

timrowledge

Re: a few small quit issues I want to note

Ah, I was wondering what purpose you had in mind...

> On 2020-09-12, at 1:08 PM, Chris Muller <[hidden email]> wrote:
>
> Not logging when there is no change sounds reasonable at first blush,
> but there are also Squeak systems that run a fixed image that don't
> save on exit -- it may be useful for operators of those systems to be
> able to know when there were interactions with the system, regardless
> whether development causing .changes changes was done or not.

Since an image set up that way is already going to be fairly heavily configured, would it not be likely that there is some added logging (I have been using the Squeaksource Toothpick package for a while now with considerable success) that would be a better target? Indeed a simple extension to the ToothPick stuff could add some of the logging to the changes file if wanted, offering the best of both worlds.

One could even consider making such a system part of the image so that changes logging is simply a particular case, and allowing even that to be logged in some way other than simply writing to a local file. It might make for an interesting option for a cluster of image to write to a single logging target, for example. You could process that info and reply to alert a developer that someone else has recently touched the same code; or use ReallyCoolAI(™) to analyse it and suggest improvements - always a popular option :-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Ignorant, and proud of it.

K K Subbu

Re: a few small quit issues I want to note

In reply to this post by Eliot Miranda-2

On 12/09/20 8:01 pm, Eliot Miranda wrote:
>
> That makes sense. So we do want the QUIT/NO SAVE indication written to
> the changes file if anything is written to the changes file because we
> know that when doing crash recovery we want to ignore everything
> before QUIT/NO SAVE. So, Chris Muller’s objections aside, I would argue
> that if the changes file is undisturbed (nothing written to it in the
> current session) when the system is about to quit without saving, it
> should do so without writing the QUIT/NO SAVE stamp.

What if a START log is lazily written just before the first write to the
change log?

If no changes are made then the changes file remains untouched. The
first write to the change log is prefixed with a START log entry. A
QUIT/NO SAVE entry is not needed or may be added if and only if a START
log was written.

Regards .. Subbu

Squeak - Dev mailing list

Re: a few small quit issues I want to note

In reply to this post by Eliot Miranda-2

Where can I download this REPL image?

I cannot find it on files.squeak.org

thx in advance.

---- On Sat, 12 Sep 2020 15:19:37 -0400 Eliot Miranda <[hidden email]> wrote ----

Hi Tobias,

On Sat, Sep 12, 2020 at 9:56 AM Tobias Pape <[hidden email]> wrote:

> On 12.09.2020, at 16:31, Eliot Miranda <[hidden email]> wrote:
>
> With the REPL image if it starts up and evaluates an expression of two (which are not logged) and then quits nothing has changed but the QUIT/NO SAVE has been written, and now my reproducible image/changes pair is no longer in exactly the same state; the changes file has grown.
>

In that particular case, wouldn't it suffice to just make the Changes file read-only?

No. Sometimes one wants to file-in code into the REPL.

Best regards
-Tobias

_,,,^..^,,,_
best, Eliot

Eliot Miranda-2

Re: a few small quit issues I want to note

On Sep 13, 2020, at 4:47 AM, gettimothy via Squeak-dev <[hidden email]> wrote:

Where can I download this REPL image?

I cannot find it on files.squeak.org

It gets built by a script in the image directory of the OpenSmalltalk-vm repository. Clone, cd to the image directory and run buildsqueaktrunkreader64.sh or some such

thx in advance.

---- On Sat, 12 Sep 2020 15:19:37 -0400 Eliot Miranda <[hidden email]> wrote ----

Hi Tobias,

On Sat, Sep 12, 2020 at 9:56 AM Tobias Pape <[hidden email]> wrote:

> On 12.09.2020, at 16:31, Eliot Miranda <[hidden email]> wrote:
>
> With the REPL image if it starts up and evaluates an expression of two (which are not logged) and then quits nothing has changed but the QUIT/NO SAVE has been written, and now my reproducible image/changes pair is no longer in exactly the same state; the changes file has grown.
>

In that particular case, wouldn't it suffice to just make the Changes file read-only?

No. Sometimes one wants to file-in code into the REPL.

Best regards
-Tobias

_,,,^..^,,,_
best, Eliot

Eliot Miranda-2

Re: a few small quit issues I want to note

In reply to this post by K K Subbu

Hi Subbu,

> On Sep 13, 2020, at 4:27 AM, K K Subbu <[hidden email]> wrote:
>
> On 12/09/20 8:01 pm, Eliot Miranda wrote:
>> That makes sense. So we do want the QUIT/NO SAVE indication written to the changes file if anything is written to the changes file because we know that when doing crash recovery we want to ignore everything before QUIT/NO SAVE. So, Chris Muller’s objections aside, I would argue that if the changes file is undisturbed (nothing written to it in the current session) when the system is about to quit without saving, it should do so without writing the QUIT/NO SAVE stamp.
>
> What if a START log is lazily written just before the first write to the change log?
>
> If no changes are made then the changes file remains untouched. The first write to the change log is prefixed with a START log entry. A QUIT/NO SAVE entry is not needed or may be added if and only if a START log was written.

Good idea. That would work.

>
> Regards .. Subbu
>

Christoph Thiede

Re: a few small quit issues I want to note

Hi Subbu,

> What if a START log is lazily written just before the first write to the change log?

> If no changes are made then the changes file remains untouched. The first write to the change log is prefixed with a START log entry. A QUIT/NO SAVE entry is not needed or may be added if and only if a START log was written.

-1. :-) I think Chris found exactly the right words about an important drawback of such behavior:

> Not logging when there is no change sounds reasonable at first blush, but there are also Squeak systems that run a fixed image that don't save on exit -- it may be useful for operators of those systems to be able to know when there were interactions with the system, regardless whether development causing .changes changes was done or not.

IMO this sounds like something that you should be able to control via a special VM flag:

./squeak my.image --quite-changes-logging # Does not write startup/shutdown messages to the changes file

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Sonntag, 13. September 2020 18:25:10
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] a few small quit issues I want to note

Carpe Squeak!