compiled method source pointer cleanup

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
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: LCD: Launch Cartridge Disk

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