<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Dave --<div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">why don't we just get rid</span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"> of the file entirely?</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">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.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">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.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">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% :-)</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">So:</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">+1 for NOT putting too much effort in re-using/sharing external contents such as .source file between .images</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">-1 for integrating the .source file into the .image file</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 17.01.2022 19:17:41 schrieb David T. Lewis <lewis@mail.msen.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Rather that putting a lot of effort into figuring out how to package
<br>the sources file and how to locate sources files in various places
<br>for various different operating systems, why don't we just get rid
<br>of the file entirely?
<br>
<br>Traditionally the sources file is delivered as a disk file separate
<br>from the images file. That is good if you are dealing with small images
<br>and VMs with limited address space, but nowadays our 64-bit release
<br>image is over 50MB in size, and typical working images get much larger
<br>than that. Meanwhile, a compressed sources file is only(!) 6.7MB on disk.
<br>
<br>So rather than use files, just keep the sources in the image. It would
<br>work like this:
<br>
<br>- Load the compressed sources file into an object, hold it in a class var
<br>- If the in-image sources exist, use them, otherwise use file based sources
<br>- Allow the in-image sources to be cleared so that small images or images
<br>  transmitted over the network do not need to carry the sources along
<br>- Existing disk-based sources lookup would work as before
<br>
<br>I actually have this working now, and I am not seeing any problems when
<br>using the in-image sources. The sources file never needs to be reopened
<br>or located from the file system.
<br>
<br>The attached png shows an explorer on the sources file array in my
<br>image after changing over to the in-image compressed sources. The raw
<br>compressed data is highlighted in the explorer.
<br>
<br>If this sounds worthwhile, I'll clean it up a bit and post a change set
<br>or inbox submission.
<br>
<br>Dave
<br>
<br>
<br>On Mon, Jan 17, 2022 at 12:56:01PM +0100, Marcel Taeumel wrote:
<br>> Hi Dave --
<br>> 
<br>> +1
<br>> 
<br>> Did you double-check whether it is safe to remove that interface on FileDirectory class???
<br>> 
<br>> Best,
<br>> Marcel
<br>> Am 02.01.2022 09:42:09 schrieb David T. Lewis <lewis@mail.msen.com>:
<br>> See discussion at:
<br>> 
<br>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-January/218008.html
<br>> 
<br>> Dave
<br>> 
<br>> On Sat, Jan 01, 2022 at 08:47:18PM +0000, commits@source.squeak.org wrote:
<br>> > A new version of System was added to project The Inbox:
<br>> > http://source.squeak.org/inbox/System-dtl.1277.mcz
<br>> >
<br>> > ==================== Summary ====================
<br>> >
<br>> > Name: System-dtl.1277
<br>> > Author: dtl
<br>> > Time: 1 January 2022, 2:57:48.389886 pm
<br>> > UUID: 4d975f20-d62d-4b7e-8abb-bc511d976834
<br>> > Ancestors: System-mt.1276
<br>> >
<br>> > 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.
<br>> >
<br>> > 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.
<br>> >
<br>> > =============== Diff against System-mt.1276 ===============
<br>> >
<br>> 
<br>
<br><br></lewis@mail.msen.com></div></blockquote></div>