> And none of them is closed via "save and quit"?<br>
<br>
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<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font><br>
<br>
On 2022-02-25T11:27:06+01:00, marcel.taeumel@hpi.de wrote:<br>
<br>
> >  I have 233 .image files [...]<br>
> <br>
> And none of them is closed via "save and quit"?  Yeah, I think I will add a preference about this thing.<br>
> <br>
> Best,<br>
> Marcel<br>
> Am 24.02.2022 23:23:59 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:<br>
> Hi Marcel,<br>
> <br>
> just two notes from my side, but no clear opinion here. :-)<br>
> <br>
> > I assume that the user can spare those extra megs on disk while working.<br>
> <br>
> 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. :-)<br>
> <br>
> > Which server images save on a regular basis? :-D<br>
> <br>
> 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. :-)<br>
> <br>
> Best,<br>
> Christoph<br>
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel<br>
> Gesendet: Mittwoch, 16. Februar 2022 17:26:38<br>
> An: squeak-dev<br>
> Betreff: Re: [squeak-dev] The Trunk: Graphics-mt.482.mcz<br>
>  <br>
> Hi Tim --<br>
> <br>
> > The problem here is image file bloating<br>
> <br>
> 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.<br>
> <br>
> >  It should start ok but might be a problem for server cases where startup time is important?<br>
> <br>
> 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...<br>
> <br>
> Best,<br>
> Marcel<br>
> Am 14.02.2022 18:29:21 schrieb tim Rowledge <tim at rowledge.org>:<br>
> <br>
> <br>
> > On 2022-02-14, at 8:43 AM, Marcel Taeumel wrote:<br>
> ><br>
> > Hi all --<br>
> ><br>
> > 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.<br>
> <br>
> 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<br>
> <br>
> 100mb<br>
> 112mb<br>
> 121mb<br>
> (quit) 101mb<br>
> <br>
> .. which maybe wouldn't bother anyone, maybe would annoy some?<br>
> <br>
> 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?<br>
> <br>
> High-tech-insane solution - use DTL's spawn-an-image and have that image do the hibernate & save! Couldn't possibly go wrong...<br>
> <br>
> <br>
> tim<br>
> --<br>
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim<br>
> Strange OpCodes: CM: Circulate Memory<br>
> <br>
> <br>
> <br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220225/8f1c353f/attachment.html><br>
> <br>