> On 2 Jun 2019, at 21:24, Guillermo Polito <[email protected]> wrote:
>
>
>
>> El 2 jun 2019, a las 20:45, ducasse <[email protected]> escribió:
>>
>> Sven
>>
>> why not having this as extension.
>
> I’d even propose to have it by default: a FileReference writeStream can
> return a ZnNewLineWriterStream wrapping the corresponding stream.
> By default it can be configured with the system’s default line ending
> convention (least surprise?).
> And then users can change it accordingly…
>
> Now I ask also myself what we could do when reading line endings from a file.
> I’m 98.761% convinced that in the image we should have a single line ending
> convention for strings, and that we should convert internal strings to the
> external representation of convenience explicitly.
> In this direction we could make that default read streams in FileSystem to
> automatically transform external line endings into internal line endings.
Maybe, maybe.
It would still create the assumption that the standard stream has lots of
functionality that you can automatically count on. Then it feels that we are
back to where we started.
The goal was to simplify, with simple, compose-able functionality.
I know that the implementation would still be more or less modular, but many
layers also carry a performance price.
I feel like I am fighting a losing battle trying to simplify and clean up the
stream API.
The fact that we cannot use Traits is another problem, because inheritance does
not cut it. See the old NILE project.
>> Stef
>>
>>
>>> On 2 Jun 2019, at 13:52, Alistair Grant <[email protected]> wrote:
>>>
>>> Hi Ben,
>>>
>>> On Fri, 31 May 2019 at 07:08, Ben Coman <[email protected]> wrote:
>>>>
>>>>
>>>> I'm on Windows wanting to write a text file with LF endings.
>>>> The code developed on Linux is thus...
>>>> (destinationDirectory / 'README.md') ensureCreateFile
>>>> writeStreamDo: [ :stream | stream nextPutAll: class comment ]
>>>
>>> I've come across this so many times that I always add a couple of
>>> methods to my image:
>>>
>>> ZnEncodedStream>>asNewLineStream
>>> "Answer the receiver wrapped with a ZnNewLineWriterStream"
>>> ^ZnNewLineWriterStream on: self! !
>>>
>>>
>>> ZnNewLineWriterStream>>asNewLineStream
>>> "Answer the receiver wrapped with a ZnNewLineWriterStream"
>>> ^self! !
>>>
>>>
>>> You could then modify the example above to be:
>>>
>>> stream asNewLineStream forLf nextPutAll: class comment
>>>
>>> Cheers,
>>> Alistair
>>>
>>>
>>>
>>>> and I am stuck with CR line endings.
>>>> The specific symptom is that it screws `git diff`
>>>> Here is a simple experiment...
>>>> testfile := 'README.md' asFileReference.
>>>> testfile ensureCreateFile writeStreamDo: [ :stream |
>>>> stream nextPutAll: 'aa
>>>> bb' ].
>>>> testfile binaryReadStream contents at: 3 "==> Character cr "
>>>>
>>>> I think its safe to assume on Linux that will result in "==> Character lf
>>>> "
>>>> but can someone please confirm?
>>>>
>>>> So my issue is that I've got
>>>> #ensureCreateFile - returns a FileReference
>>>> and
>>>> :stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream
>>>> wrapping BinaryFileStream.
>>>>
>>>> and neither seem to have an easily accessible defaultLineEnding setting.
>>>> Indeed, line endings are not a property of FileReference
>>>> and Binary & Characters have nothing to do with line endings,
>>>> and questionable if Buffering is related.
>>>>
>>>> Its more a property of a File, but IIUC that is being deprecated (??)
>>>>
>>>> MultiByteFileStream has #lineEndConvention:
>>>> but IIUC that also is being deprecated.
>>>>
>>>> So what is the proper way to force default line endings?
>>>>
>>>>
>>>> ------
>>>> Now while composing this email I discovered String>>withUnixLineEndings.
>>>> So I have a solution...
>>>> testfile := 'README.md' asFileReference.
>>>> testfile ensureCreateFile writeStreamDo: [ :stream |
>>>> stream nextPutAll: 'aa
>>>> bb' withUnixLineEndings ].
>>>> (testfile binaryReadStream contents at: 3) asCharacter "==> Character
>>>> lf "
>>>>
>>>> but that seems to imply that on Windows...
>>>> 'aa
>>>> bb' at: 3 "==> Character cr "
>>>>
>>>> and on Linux (someone please confirm)...
>>>> 'aa
>>>> bb' at: 3 "==> Character lf "
>>>>
>>>> and that is *very* curious. Strange that I never noticed it before and
>>>> obviously that hasn't hurt me,
>>>> but considering the Principal Of Least Surprise it leaves me feeling
>>>> somewhat violated :)
>>>
>>
>>
>>
>
>
