do not read the code using emacs or vi.
Use the tools in squeak, sources and changes are internal format of  
squeak saving code.

Stef

On 8 mai 07, at 08:34, subbukk wrote:

> On Tuesday 08 May 2007 12:41 am, Bert Freudenberg wrote:
>> On May 7, 2007, at 14:47 , subbukk wrote:
>>> SqueakV39.sources contains the following sequence as seen in a
>>> hexeditor for
>>> DateAndTime commentStamp:
>>> I have zero duration\r\n\r\n\r\n
>>> When I browse this class and inspect the Text object in the
>>> annotation pane,
>>> the same sequence shows up in its string variable. Since
>>> annotations are read
>>> in as line-oriented text from files
>>
>> They are not. The sources and changes file is *not* a text file even
>> though it might look like one to the uninitiated. It's a database of
>> data chunks and the image actually stores byte offsets into this
>> file. When you move the file to a different platform you *must not*
>> change the line ending convention.
> By text, I only meant portions of chunk and not the whole file.  
> This is the
> reason I used a hexeditor for the whole file. But it is good that  
> you pointed
> out the special nature of these files.
>
>>> , the CRLFs should have been replaced with
>>> CRs. Of course, we could take a stance that the sources files is
>>> corrupt
>>> since it uses mixed line endings, but then what about text read in
>>> from a
>>> changes file or from a filein that came thru email?
>>
>> We might be more tolerant when filing in, this is true. But this
>> should be an explicit action because there actually are file-ins that
>> contain binary data which we do *no* want to mess with.
> Yes, I understand this. But there are contexts where we know the  
> byteArray to
> be a text sequence.
>
>>> SqueakV3.sources contains the sequence:
>>> editStartPage\r\n\t
>>> But the Text object in the codepane shows the sequence:
>>> editStartPage\r\t
>> ..
>> 	(Scamper>>#editStartPage) getSourceFromFile asString asByteArray
>> 		"a ByteArray(101 100 105 116 83 116 97 114 116 80 97 103 101 13
>> 9 ...)"
>>
>> which is the source code as retrieved by the browser, note there only
>> is a 13 (CR) no LF (10).
> I stand corrected. I poked directly into the Sources file and  
> forgot to check
> the changes file, so this is a wrong example. There are other  
> examples 3.8
> image like:
> (String>>#asDateAndTime) getSourceFromFile asString asByteArray a  
> ByteArray(97
> 115 68 97 116 101 65 110 100 84 105 109 101 13 10 13 10 9 34 67 ...
> where the CRLF line ending pops up.
>
> I am curious about how these CRLFs got into the chunks in the first  
> place? I
> dont know Squeak well enough to track this down quickly, so when I  
> saw the
> artifacts, I seized this opportunity to dig into internals.
>
> Bret, thank you very much for explaining your reasoning in detail  
> and in
> Squeak code. It helps me learn internals faster.
>
> Regards .. Subbu
>
>