[squeak-dev] The Trunk: Graphics-mt.482.mcz

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Fri Feb 25 15:08:32 UTC 2022


> And none of them is closed via "save and quit"?

I do save-and-quit and also save-and-no-quit. So if I understand the issue correctly, the wasted space problem will only occur when you save-and-no-quit and then kill the VM? Well, this happens not so frequently ... I guess that 1 of 3 images on my disk were saved by this way because Windows crashes every 1 or 2 weeks. :D

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2022-02-25T11:27:06+01:00, marcel.taeumel at hpi.de wrote:

> >  I have 233 .image files [...]
> 
> And none of them is closed via "save and quit"?  Yeah, I think I will add a preference about this thing.
> 
> Best,
> Marcel
> Am 24.02.2022 23:23:59 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
> Hi Marcel,
> 
> just two notes from my side, but no clear opinion here. :-)
> 
> > I assume that the user can spare those extra megs on disk while working.
> 
> On my main machine, I have 233 .image files with 28 GB in total. So maybe "those extra megs" could indeed be relevant ... But I did not do a rough calculation. :-)
> 
> > Which server images save on a regular basis? :-D
> 
> The image for https://t.me/SqueakSmalltalkBot [https://t.me/SqueakSmalltalkBot] does, once in ten minutes. Will this increase the wear and tear of my raspi's SD card? :-) To be honest, I would prefer it if "Smalltalk snapshot: ... andQuit: ..." would support the server use case out-of-the-box, too, without extra scripting. But if we are only talking about a few kilobytes here, I don't mind. :-)
> 
> Best,
> Christoph
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
> Gesendet: Mittwoch, 16. Februar 2022 17:26:38
> An: squeak-dev
> Betreff: Re: [squeak-dev] The Trunk: Graphics-mt.482.mcz
>  
> Hi Tim --
> 
> > The problem here is image file bloating
> 
> I know. Is this a problem? I assume that the user can spare those extra megs on disk while working. Yet, it is annoying to get a stuttering system after snapshotting, which might even encourage people to not save that often.
> 
> >  It should start ok but might be a problem for server cases where startup time is important?
> 
> Which server images save on a regular basis? :-D You can always call "Form shutdown: true" and "TTCFont shutdown: true" in your server scripts directly before snapshotting ... I assume that servers have such scripts anyway and those two extra lines wouldn't hurt...
> 
> Best,
> Marcel
> Am 14.02.2022 18:29:21 schrieb tim Rowledge <tim at rowledge.org>:
> 
> 
> > On 2022-02-14, at 8:43 AM, Marcel Taeumel wrote:
> >
> > Hi all --
> >
> > Please report whether I am overlooking something here... It was kind of annoying that my entire TrueType cache was gone after just saving the image and keep on working.
> 
> The problem here is image file bloating; the hibernation is intended to save (quite a bit of) space in the image file. If we only hibernate when save&quitting then we will see patterns in the snapshot file size like
> 
> 100mb
> 112mb
> 121mb
> (quit) 101mb
> 
> .. which maybe wouldn't bother anyone, maybe would annoy some?
> 
> Also, a few save-no-quits followed by a damn-I-broke-it-quit-no-save would lave the large file as the one you have to start up. It should start ok but might be a problem for server cases where startup time is important?
> 
> High-tech-insane solution - use DTL's spawn-an-image and have that image do the hibernate & save! Couldn't possibly go wrong...
> 
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: CM: Circulate Memory
> 
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220225/8f1c353f/attachment.html>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220225/d6274b2a/attachment.html>


More information about the Squeak-dev mailing list