[squeak-dev] MutliByteFileStream and CrLfFileStream (and windows)
Levente Uzonyi
leves at elte.hu
Thu Aug 14 15:30:40 UTC 2014
On Wed, 13 Aug 2014, Chris Cunningham wrote:
> 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?
Because line end conversion is also done by the TextConverter (see
#installLineEndConventionInConverter), so it created double line endings
(cr -> crlf -> crlflf) in some cases, and it was unnecessary anyway.
I just checked if it works, and it does on linux:
| filename result |
filename := UUID new asString36, '.txt'.
FileStream newFileNamed: filename do: [ :file |
file
lineEndConvention: #crlf;
nextPut: Character cr;
nextPutAll: String cr;
lineEndConvention: #lf;
nextPut: Character cr;
nextPutAll: String cr;
lineEndConvention: #cr;
nextPut: Character cr;
nextPutAll: String cr;
lineEndConvention: nil;
nextPut: Character cr;
nextPutAll: String cr ].
result := FileStream readOnlyFileNamed: filename do: [ :file | file binary upToEnd ].
FileDirectory default deleteFileNamed: filename.
self assert: result = #[13 10 13 10 10 10 13 13 13 13]
Does it work on your machine?
Levente
>
> (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
>
>
>
>
>
>
>
More information about the Squeak-dev
mailing list
|