On Fri, Jan 07, 2022 at 10:29:26AM -0800, Eliot Miranda wrote:
> 
> If the source file model supported something like
> substituteReadOnlySourceFilesDuring: and
> substituteWritableSourceFilesDuring:, the former being used in the
> debugger, the latter when writing to the changes and sources files, then
> we wouldn't need CurrentReadOnlySourceFiles at all.  The whole design is
> backwards.  There is *no need* to create a new source file for every read;
> that's insane.  There is only a need to avoid the debugger tripping over
> itself.  There have never been any thread-safety guarantees with the
> sources file and the UI ensures that compilation and browsing are
> essentially single-threaded.  I wish we would engineer this properly and
> not keep using the ugly CurrentReadOnlySourceFiles hack.  [and no criticism
> is implied of you Levente; the thing works ok-ish, but things could be so
> much better]
> 

Does the above approach of implementing substituteReadOnlySourceFilesDuring:
and substituteWritableSourceFilesDuring: assume that the debugger is
running in a single UI process (i.e. Morphic)? Or this this something
that would work from any process, and is expected to be called only
occasionally from some debugger process that needs access to sources
and changes without disturbing the process being manipulated by the
debugger?

I am asking because "the UI ensures that compilation and browsing are
essentially single-threaded" is true only for Squeak Morphic, which
is arguably a bit of a hack in its own right.

I do not know if I am understanding this correctly, but my sense is that
substituteReadOnlySourceFilesDuring: and substituteWritableSourceFilesDuring:
could be trivially implemented on top of Levente's intended design
of a CurrentReadOnlySourceFiles associated with process local variables.
So maybe you are both right?

Dave