On Tue, Jan 18, 2022 at 1:24 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> 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.
>

+1

>
> 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.
>

+1

>
> 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% :-)
>

14% ;-)

In addition I like the ability to deploy without source by simply deploying
the image file, leaving the changes and sources behind, or providing a zero
length changes file.

> So:
> +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
>

ASs a post-script I like what we did in VisualWorks for parcels.  We
changes the format of a file pointer so that it could include an arbitrary
file index and offset, so one could encode index 27, offset 1000000, etc.
Then when a parcel was loaded its source file was added to the source files
array, an extensible OrderedCollection of files, and the methods in that
parcel had their source pointers swizzled to index the relevant source
file.  Hence loading packages didn't pollute the changes file. I'm not
suggesting we go this route for Saueak but if we did I would preserve
Squeak's version support and save to a new package all previous versions of
methods.  Again, because the source is external there's no space overhead
in the image for supporting conveniently browsable versions.  And with both
binary loading and compilation the swizzling of source pointers can be done
as each compiled method is being instantiated; it does not imply a second
pass over the loaded methods to adjust their pointers.


> Best,
> Marcel
>
> 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.
>
> Dave
>
>
> 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 ===============
> > >
> >
>
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220118/f75e8d23/attachment.html>