On Tue, Jan 18, 2022 at 5:05 PM tim Rowledge <tim at rowledge.org> wrote:

> I remember this idea when Dave Leibs & I were messing around with early
> VW packages stuff a *very* long time go. The downside that has bitten me is
> that you get screwed when you move an image; not so much on the same
> machine so long as the paths are fully qualified but if you copy to a
> different machine... blech. You're actually worse off then because there is
> no guarantee the new target machine has anything like the same directory
> layout.
>

We solved this by introducing environment variables into source paths.  So
everything is relative to some root location and/or the current directory.

>
> I'd prefer to see source strings directly attached to each method, with
> changes backed up to the changes log or something akin to Chris' revision
> history server, with an easy way to drop those source strings for any
> deployment use. Given that a working image will grow to over 100Mb very
> quickly if you install anything like Seaside, RB, Postgres, SIXX and so on
> - an extra 10Mb for the sources to be local is nothing.
>

I disagree. It's all bloat and overhead. The fact that source files have
persisted for sop long has two count for something.  In any case the Pharo
cabal have discarded the sources file.  Let's see how they fare before
potentially making a serious mistake.

>
> > On 2022-01-18, at 4:44 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > On Tue, Jan 18, 2022 at 12:26:03PM -0800, Eliot Miranda wrote:
> >>
> >> ASs a post-script I like what we did in VisualWorks for parcels.  We
> >> changes the format of a file pointer so that it could include an
> arbitrary
> >> file index and offset, so one could encode index 27, offset 1000000,
> etc.
> >> Then when a parcel was loaded its source file was added to the source
> files
> >> array, an extensible OrderedCollection of files, and the methods in that
> >> parcel had their source pointers swizzled to index the relevant source
> >> file.  Hence loading packages didn't pollute the changes file. I'm not
> >> suggesting we go this route for Saueak but if we did I would preserve
> >> Squeak's version support and save to a new package all previous
> versions of
> >> methods.  Again, because the source is external there's no space
> overhead
> >> in the image for supporting conveniently browsable versions.  And with
> both
> >> binary loading and compilation the swizzling of source pointers can be
> done
> >> as each compiled method is being instantiated; it does not imply a
> second
> >> pass over the loaded methods to adjust their pointers.
> >>
> >
> > I like this idea. There's no particular need for SourcesFiles to be of
> size two.
> >
> > Dave
> >
> >
> >
>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Klingon Code Warrior:- 5) "Specs are for the weak and timid!"
>
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220118/6bff59e8/attachment.html>