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