[squeak-dev] a few small quit issues I want to note

Eliot Miranda eliot.miranda at gmail.com
Sat Sep 12 14:31:27 UTC 2020


Hi Christoph,

> On Sep 12, 2020, at 5:05 AM, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> 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 <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
> 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 <asqueaker at gmail.com> 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 <eliot.miranda at gmail.com> 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200912/6a4db937/attachment.html>


More information about the Squeak-dev mailing list