[squeak-dev] MutliByteFileStream and CrLfFileStream (and windows)
cunningham.cb at gmail.com
Thu Aug 14 05:52:33 UTC 2014
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:
Time: 17 May 2011, 5:31:08.561 pm
- 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
(And apparently I've been annoyed about this for 3 years - but not enough
to actually ask until now - bad me)
On Wed, Aug 13, 2014 at 3:30 PM, Chris Cunningham <cunningham.cb at gmail.com>
> 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.
> On Wed, Aug 13, 2014 at 2:02 PM, Eliot Miranda <eliot.miranda at gmail.com>
>> On Wed, Aug 13, 2014 at 1:57 PM, Chris Cunningham <
>> cunningham.cb at gmail.com> wrote:
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev