On Sat, 12 Dec 2009, Igor Stasenko wrote:

> Hello,
>
> encoding a file index in the highest bits of source pointer preventing
> from having source file index > 32M :(
>
> I mean, if we would encode pointer as:
>
> (filePosition << 1) + (fileIndex -1) "file index 1 or 2 "
> then there is no limit in .changes and .source files sizes, because
> then its easy to represent such value as a byte array,
> and it will mean only longer trailer bytes in compiled method, if
> source file index above 32M.
>
> But the way, how its encoded currently:
>
> index * 16r1000000 + position
>
> means that we're unable to have file position more than 32M :(
>
> See implementation of #sourcePointerFromFileIndex:andPosition:
>
> This should be fixed!
>

+1

Also source file handling needs cleanup. I don't know anything about the 
original design of the source file handling (and the decisions behind it), 
but the current implementation has a few unused capabilities (more than 2 
source files, multiple source file array implementation) and rarely used 
features (in-memory source streams). Removing (some of) these could 
simplify the implementation. Also it's a bit cryptic to use
SourcesFiles at: 2 instead of SourceFiles changesFile.


Levente

> -- 
> Best regards,
> Igor Stasenko AKA sig.
>
>