On Sun, Feb 28, 1999 at 09:01:46PM -0500, Bob Arning wrote:
> On Sun, 28 Feb 1999 22:52:04 +0100 "Reinier van Loon" <R.L.J.M.W.van.Loon at inter.nl.net> wrote: 
> >could it be that the changes file is constrained to 16M?
> 
> It is. We had a discussion some time ago about options for
> increasing it (there were a couple of bits that could be used to
> increase the limit), but I think no resolution was reached. The
> trick, for now, is to compress your change file before it gets that
> big (unless, of course, you have 18M of unique changes).

Since today seems to be Squeak-list catchup day, I may as well throw
in my CDN$0.03:

Howzabout we[1]:

	  1) Implement an abstract class MethodSource whose
             subinstances implement methods #sourceString, which gets
             the source from wherever it's stored, be it file, CVS
             repository, web site, ROM, etc and #setSource: which
	     stores it at said location.
           
	  2) Modify CompiledMethod to keep method source in an
             ordinary ST instance variable (i.e. reference).  (IIRC,
             this doesn't change the size of the object since it
             already uses 32 bits to store the index.)

	  3) Modify CompiledMethod's source-fetching code to check the
             method source object and if it's an integer, get it from
             the usual files in the usual way.  If it's a
             MethodSource subinstance, send it #sourceString.


Advantages:

	-Minimal image size increase as long as your changes file <16M
         in size.

	-That 16M limit goes away, 'cause the indices automagically
         become LargeIntegers.

	-Folks who want to do wierd stuff (e.g. web-based source
         repositories) can do so by subclassing MethodSource.

Disadvantages:

	-Somebody has to do the work.


This looks to me to be the Right Thing.


				 --Chris

[1] By "we", I mean "not me".  :-)