Hi Tim,

Instead of looking to change the world to deploy what
you have sofar why not put the code on mantis and let
others see and comment on it.

A change of this magnitude is worth testing with other
peoples eyes (and hands and keyboards) before
committing to. I'm sure both I and Mr Witzel will show
interest and there may be others.  

-------- a slight change of focus
---------------------

More thought on the future of sources:


As you know from my previous posts I am dedicated to
seeing Squeak Soucres unleashed.

I've thought about downloading a CD sized source or
changes file and remembered my old experiences with
large files. (The conclusion: it is always better to
divide and conquor than to put all your eggs into
large baskets.)

I want to see the extention go in the direction of
multilevel version sources with the final level being
a small "growth tip" changes file. The upper levels
would each have a source of its own. To keep any one
file from getting too large each source level may
consist of several files

so you would have version 3 sources.  version 3.1
sources (or version 3.1-1 and version 3.1-2 source
files where 3.1-2 is the second part continuation of
3.1-1) and a version 3.1.1 changes file which would be
the "growth tip."

By making sources multipart no one file would have to
grow above a reasonable size.  There might even be
good reason to make that size ~32M to allow some
possible backward compatability.

The "growth tip" scheme aids distribution.  Once you
have the upper level sources distributed once you need
not do it again. All that needs to be distributed is
the image file and the "growth tip" changes file. The
changes file will almost always be quite small.  I can
imaging people blessing you for that.




Yours in service, -- Jerome Peace


>compiled method source pointer cleanup
>tim Rowledge tim at rowledge.org 
>Thu Oct 19 05:35:05 UTC 2006 wrote:
>
>I have some code that adds the source reference to
the method  
>properties. Seems to work ok, which is good so far as
it goes.
>
>Problem now is that I'm out of spare braincells on
the next stage.  
>I'm reasonably sure I could work it out eventually
but I have a bunch  
>of actual work to do so I'm asking for help.
>
>The current source position/file encoding is a little
convoluted -  
>see StandardSourceFileArray>
sourcePointerFromFileIndex: index  
>andPosition: position - in such a way as to make it a
bit tricky to  
>extend the position range. Now we *could* keep using
the same  
>encoding for larger position ranges but it seems a
bit silly to  
>complicate life. I'd like to use something much more
extensible  
>(remember, the source reference is no longer encoded
into a fixed  
>number of bytes at the end of a compiledmethod) like
>(sourcefileindex-1) + (position bitShift: 2)
>which would happily keep working into large integers.
I think we can  
>feel sure that large integer will allow pointing into
any conceivable  
>file size?
>
>What we need is a chunk of code that will
>do the equivalent of #condenseSources whilst moving
from the old to  
>the new encoding
>install the replacement code to use the new encoding
without breaking  
>during the installation
>cleanup
>
>I suppose the good news about losing the old sources
as part of 3.9  
>is that there is no need to try to make the transfer
also follow the  
>method history chains. That should simplify things a
bit. Obviously I  
>can supply the changesets for the method changes to
the brave volunteer.
>
>There is also a boatload of code needing attacking to
clear out usage  
>of the trailer bytes, explicit assumptions about use
of files and the  
>indices etc but that can come later.
>
>So, who's feeling brave and adventurous?
>
>tim
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com