[squeak-dev] Why not just get rid of the sources file entirely (was: The Inbox: System-dtl.1277.mcz)

Marcel Taeumel marcel.taeumel at hpi.de
Tue Jan 18 09:24:12 UTC 2022

Hi Dave --

> why don't we just get rid of the file entirely?

Because it is a good design exercise. There will always be some external content to be managed. Strings can bloat the an .image file quite fast. Try managing your e-mails for example. Currently, you are better off keeping that database nearby but outside the image. We still have to solve some GC challenges in the OSVM to conveniently support multi-gig image files.

If you would want to integrate the .sources file into the .image, then -- for the moment -- just keep a copy around the .image file. I, too, see not too much value in trying to manage re-use of such files outside the .image. But I do see value in having and keeping a design that allows us to maintain such contents outside the image.

If the image is 50 MB in size, then a compressed sources file with about 7 MB is a lot. It's not "only" but "a lot". Almost 10% :-)

+1 for NOT putting too much effort in re-using/sharing external contents such as .source file between .images
-1 for integrating the .source file into the .image file

Am 17.01.2022 19:17:41 schrieb David T. Lewis <lewis at mail.msen.com>:
Rather that putting a lot of effort into figuring out how to package
the sources file and how to locate sources files in various places
for various different operating systems, why don't we just get rid
of the file entirely?

Traditionally the sources file is delivered as a disk file separate
from the images file. That is good if you are dealing with small images
and VMs with limited address space, but nowadays our 64-bit release
image is over 50MB in size, and typical working images get much larger
than that. Meanwhile, a compressed sources file is only(!) 6.7MB on disk.

So rather than use files, just keep the sources in the image. It would
work like this:

- Load the compressed sources file into an object, hold it in a class var
- If the in-image sources exist, use them, otherwise use file based sources
- Allow the in-image sources to be cleared so that small images or images
transmitted over the network do not need to carry the sources along
- Existing disk-based sources lookup would work as before

I actually have this working now, and I am not seeing any problems when
using the in-image sources. The sources file never needs to be reopened
or located from the file system.

The attached png shows an explorer on the sources file array in my
image after changing over to the in-image compressed sources. The raw
compressed data is highlighted in the explorer.

If this sounds worthwhile, I'll clean it up a bit and post a change set
or inbox submission.


On Mon, Jan 17, 2022 at 12:56:01PM +0100, Marcel Taeumel wrote:
> Hi Dave --
> +1
> Did you double-check whether it is safe to remove that interface on FileDirectory class???
> Best,
> Marcel
> Am 02.01.2022 09:42:09 schrieb David T. Lewis :
> See discussion at:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-January/218008.html
> Dave
> On Sat, Jan 01, 2022 at 08:47:18PM +0000, commits at source.squeak.org wrote:
> > A new version of System was added to project The Inbox:
> > http://source.squeak.org/inbox/System-dtl.1277.mcz
> >
> > ==================== Summary ====================
> >
> > Name: System-dtl.1277
> > Author: dtl
> > Time: 1 January 2022, 2:57:48.389886 pm
> > UUID: 4d975f20-d62d-4b7e-8abb-bc511d976834
> > Ancestors: System-mt.1276
> >
> > Look for the sources file in well-known locations on some platforms. For Unix, if not found in the usual locations then look in /usr/share/squeak and /usr/local/share/squeak. Hooks for other platforms may be added to SmalltalkImage>>sourcesFilePaths.
> >
> > Refactor to reduce duplication of logic in locateSourcesEntry and openSources:forImage: and to ensure that the full set of file paths is searched for stc compressed sources files prior to searching for regular sources files.
> >
> > =============== Diff against System-mt.1276 ===============
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220118/bac190dd/attachment.html>

More information about the Squeak-dev mailing list