<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Dave --<div><br></div><div>I just tested dtl.9 and it almost works on Windows:</div><div><br></div><div>- In CompressedSources class >> #initializeSource:, you forgot a #closeSourceFiles before that #openSourceFiles</div><div><div>- 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</div></div><div>- If you disable that preference, it should write the source to the file system again if it cannot find a file already.</div><div><br></div><div>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.</div><div><br></div><div>Other than that, it seems to be ready for Trunk.</div><div><br></div><div>Best,</div><div>Marcel</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;'>
                        <p style='color: #AAAAAA; margin-top: 10px;'>Am 24.01.2022 02:23:00 schrieb David T. Lewis <lewis@mail.msen.com>:</p><div style='font-family:Arial,Helvetica,sans-serif'>I moved DTL-internal-sources-dtl.4 to the treated inbox, and<br>replaced it with DTL-internal-sources-dtl.9 in the inbox.<br><br>After loading DTL-internal-sources-dtl.9 you can now use preference<br>"Cache sources file" in preference category "Files" to control<br>whether or not the sources file needs to be loaded from the file<br>system.<br><br>After cleaning up my initial hacks and writing some unit tests,<br>I am pleasantly surprised to find that Dan Ingall's CompressedSourceStream<br>(written some 20 years ago and largely overlooked since then) is<br>fully functional for writing as well as reading, and with a couple<br>of minor overrides it works equally well streaming over a FileStream<br>on disk or a simple ReadWriteStream on a ByteArray.<br><br>Dave<br><br><br>On Fri, Jan 21, 2022 at 05:28:48PM -0500, David T. Lewis wrote:<br>> Hi Chris,<br>> <br>> On Thu, Jan 20, 2022 at 09:43:12PM -0600, Chris Muller wrote:<br>> > Neat idea.  It should allow a slight reduction in complexity of<br>> > deployment (one less file), while dodging that turn-off and deterrent<br>> > for new users when they encounter the "missing sources" warning<br>> > message.<br>> ><br>> <br>> Thanks for looking at it :-)<br>>  <br>> > I didn't look at the implementation, just the API, and would like to<br>> > ask your thoughts about synchronicity with the .sources file.  Does<br>> > the cached object know which .sources file (version) it is?<br>> <br>> The cached object is nothing more than a read only copy of the<br>> sources that does not require loading from disk. It is the simplest<br>> possible hack that does not require actually hitting the file system<br>> to read the sources.<br>> <br>> The real sources file still needs to exist, if only for initializing<br>> the in-image copy of it. But we don't need to read that file each<br>> and every time we open the image.<br>> <br>> <br>> > In case<br>> > the .sources files is updated from the version the cached object is<br>> > created from, and the user selects #clearCachedSources, what would<br>> > happen?  Some way for the user to "update" their cached sources.<br>> > <br>> <br>> clearCachedSources just clears a class variable so that you go<br>> back to the normal behavior of loading source from the file system.<br>> <br>> <br>> > I guess it should be fine since the .sources file is 100% static.  As<br>> > long as the .sources file is the same as the cached object, the system<br>> > can be toggled back even after a lot of work.  It's the .changes file<br>> > that is continually updated, and this doesn't concern that file,<br>> > right?<br>> <br>> This is just for the sources file, not the changes file. It is a<br>> minimal hack that supports the case of reading sources. I do not<br>> expect it to work for a writeable stream such as the changes file.<br>> And to be honest I would not want to implement that unless we<br>> first had a reliable way to restore non-compressed sources from<br>> a compressed sources stream (as far as I know that does not exist,<br>> although I did not really look).<br>> <br>> > <br>> > In any case, this is an improvement I hope we can squeeze into the<br>> > next release.  Thanks for doing it!<br>> > <br>> <br>> Thanks for you kind words, but I think we should discuss it after<br>> the next release. The last thing I want to do right now is make<br>> Marcel's release manager chores more complicated :-)<br>> <br>> Meanwhile I'll be running it my own images just to make sure<br>> that nothing horrible happens.<br>> <br>> Dave<br>> <br>> <br><br></div></blockquote>
                                        </div></body>