hmm.  So, I was going back to find an old version of CrLfFileStream before
MutliByteFileStream - that was a long time ago.  While looking, though, I
found where at least the writing seems to have stopped doing the conversion:

Name: Multilingual-ul.146
Author: ul
Time: 17 May 2011, 5:31:08.561 pm
UUID: 8c0359ba-6c47-a946-9707-cc7c37dc8d44
Ancestors: Multilingual-ul.145

MultiByteFileStream changes:
- assume that wantsLineEndConversion is properly initialized
- removed the line end conversion code from #nextPut:

Levente, do you happen to remember why you made
MultiByteFileStream>>nextPut: not do the line end conversion code 3 years
ago?

(And apparently I've been annoyed about this for 3 years - but not enough
to actually ask until now - bad me)

-cbc


On Wed, Aug 13, 2014 at 3:30 PM, Chris Cunningham <cunningham.cb at gmail.com>
wrote:

> Good.  In that case I'll try to be a little more formal in the work, and
> share it, too.
> Can't promise it will be fast, though - off hours only.
>
> -cbc
>
>
> On Wed, Aug 13, 2014 at 2:02 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>>
>>
>>
>> On Wed, Aug 13, 2014 at 1:57 PM, Chris Cunningham <
>> cunningham.cb at gmail.com> wrote:
>>
>>> Hi.
>>>
>>> so, for a while now, I've been annoyed that the newer Squeak's didn't
>>> really handle Windows nicely - at least, not writing to files to handle
>>> outside of Squeak.  Today I finally dug into the code to find out why.
>>>
>>> Many moons ago, MultiByteFileStream was created as the replacement fo
>>> rCrLfFileStream, and most references to CrLfFileStream went away.  Which is
>>> even commented in the code(!), as:
>>> It also combined the good old CrLfFileStream.  CrLfFileStream class>>new
>>> now returns an instance of MultiByteFileStream.
>>>
>>> However, the conversion wasn't complete.  In particular:
>>> FileDirectory>>newFileNamed: (and related things) just get a new
>>> MutliByteFileStream, which doesn't activate any of the CrLf lineEnding
>>> magic - it assume there is no line ending conversions wanted at all.
>>> In fact, no way to use MutliBytFileStream (except as CrLfFileStream new,
>>> from that obsoleted class) really use it (exceptions being FileList and
>>> BDFFontReader).  This is annoying on a system that doesn't use cr as the
>>> default line endings (are there any left?).
>>>
>>> Further, if you do set it up to detect line endings, as far as I can
>>> tell, it never actually does any conversions!
>>>
>>> Would anyone mind if I finished putting the CrLfFileStream functionality
>>> into MultiByteFileStream?  and if I did it, would anyone else use it?
>>>
>>
>> I would be pleased!  I can't promise to use it, but I /want/ to produce a
>> build server for WIndows that includes producing VM source, building it,
>> etc, and as part of that I would test that sources can be produced
>> *without* CR-LF, but with plain LF line-endings.
>>
>> --
>> best,
>> Eliot
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140813/8ad31d23/attachment.htm