[squeak-dev] Source file index encoding rant

David F davidf at gmx.us
Sat Dec 12 16:10:21 UTC 2009


On Dec 12, 2009, at 6:43 AM, Levente Uzonyi wrote:

> 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.

+1

Also it would be very nice to move from carriage returns to line feeds  
to delimit lines in these files.  That way, when unix commands like  
grep happen to stumble over .changes, it doesn't output the entire  
file.  And, better yet, it would enable the use of standard unix  
commands on those files.

Also, I believe there is a bug where Squeak can't recover if it loses  
its filehandle to the changes file (e.g. if you are running Squeak off  
of a network-mapped drive and you temporarily loses that connection).

David




More information about the Squeak-dev mailing list