[squeak-dev] The Inbox: DTL-internal-sources-dtl.4.mcz

Marcel Taeumel marcel.taeumel at hpi.de
Mon Jan 24 09:26:57 UTC 2022


...or maybe disabling the preference MUST always write out that .source file and complain if there is already such a file. Otherwise you cannot guarantee that you have some .source that match your .image? Hmm...

Best,
Marcel
Am 24.01.2022 09:42:44 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi Dave --

I just tested dtl.9 and it almost works on Windows:

- In CompressedSources class >> #initializeSource:, you forgot a #closeSourceFiles before that #openSourceFiles
- In CompressedSources class >> #initializeSource:, you should support a "nil" argument so that all pragma preferences can be reset; in this case a "nil" argument should just leave the current preference value as is
- If you disable that preference, it should write the source to the file system again if it cannot find a file already.

Yet, I like it that you do not delete the .source file after you enabled that preference bc. more than one .image might already on that file.

Other than that, it seems to be ready for Trunk.

Best,
Marcel
Am 24.01.2022 02:23:00 schrieb David T. Lewis <lewis at mail.msen.com>:
I moved DTL-internal-sources-dtl.4 to the treated inbox, and
replaced it with DTL-internal-sources-dtl.9 in the inbox.

After loading DTL-internal-sources-dtl.9 you can now use preference
"Cache sources file" in preference category "Files" to control
whether or not the sources file needs to be loaded from the file
system.

After cleaning up my initial hacks and writing some unit tests,
I am pleasantly surprised to find that Dan Ingall's CompressedSourceStream
(written some 20 years ago and largely overlooked since then) is
fully functional for writing as well as reading, and with a couple
of minor overrides it works equally well streaming over a FileStream
on disk or a simple ReadWriteStream on a ByteArray.

Dave


On Fri, Jan 21, 2022 at 05:28:48PM -0500, David T. Lewis wrote:
> Hi Chris,
>
> On Thu, Jan 20, 2022 at 09:43:12PM -0600, Chris Muller wrote:
> > Neat idea. It should allow a slight reduction in complexity of
> > deployment (one less file), while dodging that turn-off and deterrent
> > for new users when they encounter the "missing sources" warning
> > message.
> >
>
> Thanks for looking at it :-)
>
> > I didn't look at the implementation, just the API, and would like to
> > ask your thoughts about synchronicity with the .sources file. Does
> > the cached object know which .sources file (version) it is?
>
> The cached object is nothing more than a read only copy of the
> sources that does not require loading from disk. It is the simplest
> possible hack that does not require actually hitting the file system
> to read the sources.
>
> The real sources file still needs to exist, if only for initializing
> the in-image copy of it. But we don't need to read that file each
> and every time we open the image.
>
>
> > In case
> > the .sources files is updated from the version the cached object is
> > created from, and the user selects #clearCachedSources, what would
> > happen? Some way for the user to "update" their cached sources.
> >
>
> clearCachedSources just clears a class variable so that you go
> back to the normal behavior of loading source from the file system.
>
>
> > I guess it should be fine since the .sources file is 100% static. As
> > long as the .sources file is the same as the cached object, the system
> > can be toggled back even after a lot of work. It's the .changes file
> > that is continually updated, and this doesn't concern that file,
> > right?
>
> This is just for the sources file, not the changes file. It is a
> minimal hack that supports the case of reading sources. I do not
> expect it to work for a writeable stream such as the changes file.
> And to be honest I would not want to implement that unless we
> first had a reliable way to restore non-compressed sources from
> a compressed sources stream (as far as I know that does not exist,
> although I did not really look).
>
> >
> > In any case, this is an improvement I hope we can squeeze into the
> > next release. Thanks for doing it!
> >
>
> Thanks for you kind words, but I think we should discuss it after
> the next release. The last thing I want to do right now is make
> Marcel's release manager chores more complicated :-)
>
> Meanwhile I'll be running it my own images just to make sure
> that nothing horrible happens.
>
> Dave
>
>

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


More information about the Squeak-dev mailing list