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