Hi Eliot --

> Why are we still unable to do something constructive here?

My guess would be mostly due to the fact that is seems to work most of the time. Even on Windows. Yet, I was also surprised to find out that we close and re-open those files any time we have written into them.

Best,
Marcel
Am 20.01.2022 20:44:11 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
Hi All,

On Jan 19, 2022, at 12:38 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:



Hi Dave --

> [...] which point the sources file no longer lives on rotating media

Quick comment on this one. :-) Many computers use SSD/Flash storage these days and I am pretty sure that modern operating systems have their tricks with caching bigger files even further without the application ever noticing. However, considering external file scanners scanning for viruses, yes, it can be beneficial to avoid an extra use of some OS file API.


Again our performance issues accessing sources on windows are much more likely to be rooted in the absurdity of opening a file for every file access, using the ugly CurrentReadOnlySources nonsense to compensate.  If we were to maintain the in-image source files correctly our performance would improve markedly.

The issue with source files is fundamentally to do with providing a way for the debugger to access source through different files while debugging source file access.  A substituteSourceFilesDuring: aBlock protocol would work, be infinitely preferable than cacheDuring:.  Why are we still unable to do something constructive here?

Eliot

_,,,^..^,,,_ (phone)

Best,
Marcel
Am 19.01.2022 04:21:20 schrieb David T. Lewis <lewis at mail.msen.com>:
On Mon, Jan 17, 2022 at 01:17:31PM -0500, David T. Lewis wrote:
> 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.
>

As promised. Try loading DTL-internal-sources-dtl.4 from the inbox.

The postscript will create a compressed .stc if you do not already
have one in your image directory, then load the raw bytes into a
holder object in the image. It then reopens the sources files, at
which point the sources file no longer lives on rotating media.

Evaluate "CompressedSources clearCachedSources" to go back to the
old-school approach of rooting around through various directories
to find a traditional .sources or .stc file. Don't worry, this still
works just as well as it ever did.

Save your image first ... just sayin'

Dave



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