On Sun, Aug 6, 2017 at 11:47 AM, Thierry Goubier <thierry.goub...@gmail.com>
wrote:

> Hi Stef, all,
>
> I'd like to point out that, during the life of an image (prepared on
> windows, then used on Linux, then on Mac), the meaning of a new line
> changes -> should then all 'newLines' done on streams while on windows be
> changed when the image restart on Linux?
>
> My take would be:
>
> - Set a convention internal to Pharo (#cr is then fine for me)
> - provide an easy and simple "convert to current os convention"
>

But the problem is that convention clashes with another convention: cr is
an ascii character and is not portable. So either we have a confusing API
(is this cr going to write a cr or a platform independent newline sequence
of characters?) or we have a clear one with a new message that does the
magic.

We can then also provide some magic that transforms cr's into newlines
automatically. But I want to decouple "weird magic for backwards
compatibility" from "the nice and clean library below" :).


>
> I'd suspect, Stef, that your #newLine will end up being a mess for
> multi-platform apps (and force multi-platform apps to add code to determine
> on which platform a stream was written to to be able to reconvert it back)
>

But that is the case with the current implementation. We only want to make
it explicit. Right now:
 - MultiByteFileStream & friends guess the line ending convention in the
platform (I'd not guarantee that this works ok all the time)
 - when you write a cr, iff you're writing to a file, it will transform it
to the line ending that corresponds

The only thing is that this implementation
 - is complex
 - is implicit (maybe you wanted to really write a cr and you end up
writing an lf?)

But otherwise it shares the weaknesses you're pointing out. We are only
saying that:
 - we should split the cr conversion into a decorator object to have a
cleaner API
 - we should make it explicit and thus less confusing using a message
#newline instead of a #cr that is magically converted


>
> Regards,
>
> Thierry
>
>
>
> Le 06/08/2017 à 10:54, Stephane Ducasse a écrit :
>
>> Agreed :)
>>
>> But so far what do we do?
>>
>>
>> - #cr and #lf just put this character in the stream.
>> - #newLine put the underlying OS line ending.
>>
>> Then we should revisit all the cr inside the system and use newline.
>> Then we should think about the internal usage of cr by default in
>> Pharo (We should change it).
>>
>> Does it make sense?
>> Stef
>>
>> Stef
>>
>> On Sun, Aug 6, 2017 at 10:36 AM, Sven Van Caekenberghe <s...@stfx.eu>
>> wrote:
>>
>>>
>>> On 6 Aug 2017, at 08:59, Guillermo Polito <guillermopol...@gmail.com>
>>>> wrote:
>>>>
>>>> Can somebody propose an implementation besides on top of this
>>>> discussion? I propose such an implementation should take the form of a
>>>> stream decorator instead of changing the base implementation.
>>>>
>>>
>>> YES, a decorator !
>>>
>>> We want simpler streams, not the old complex ones. Less API, less
>>> functionality.
>>>
>>> Guille
>>>>
>>>> On Sun, Aug 6, 2017 at 12:01 AM, Peter Uhnak <i.uh...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> just to (hopefully) clarify my intention, maybe pseudocode would
>>>> describe my thoughts better.
>>>>
>>>> Stream>>beForWindows
>>>>          "Use consistenly Windows line endings (CRLF) in the stream"
>>>>          self convertLineEndings: true
>>>>          lineEnding := String crlf
>>>>
>>>> Stream>>convertLineEndings: aBoolean
>>>>          "automatically convert line endings to the predefined one"
>>>>          convertLineEndings := aBoolean
>>>>
>>>> Stream>>nl
>>>>          self nextPutAll: lineEnding
>>>>
>>>> Stream>>cr
>>>>          convertLineEndings ifTrue: [
>>>>                  self deprected: 'Using #cr/#lf for generic newlines is
>>>> deprected, use #nl instead".
>>>>                  self nl.
>>>>          ] ifFalse: [
>>>>                  self nextPutAll: String cr.
>>>>          ]
>>>>
>>>>
>>>> So when "convertLineEndings = true", then using anything else than #nl
>>>> would warn the user that they should use #nl instead (as they explicitly
>>>> requested to have the line endings consistend).
>>>>
>>>> And when "convertLineEndings = false", it would behave pretty much the
>>>> same way as now, #cr would write #cr, etc.
>>>>
>>>>
>>>> With such approach imho
>>>>
>>>> * output of existing code wouldn't be broken
>>>> * when switching to new scheme (#nl) the programmer would be warned
>>>> where the missed a change
>>>> * it will be easier to keep the newlines consistent
>>>>
>>>> Peter
>>>>
>>>> On Sat, Aug 05, 2017 at 11:30:58AM +0200, Esteban Lorenzano wrote:
>>>>
>>>>>
>>>>> On 5 Aug 2017, at 11:17, Peter Uhnak <i.uh...@gmail.com> wrote:
>>>>>>
>>>>>> I think there is a consensus we need to keep #cr and #lf as intended
>>>>>>>
>>>>>>
>>>>>> Is there?
>>>>>>
>>>>>> My argument was that there's no (obvious) reason to combine different
>>>>>> line endings in the same document. Therefore if you were to use #cr, #lf,
>>>>>> #crlf, you would actually mean that you just want to enter newline.
>>>>>>
>>>>>
>>>>> no, sometimes you want to enforce a specific line ending. You will not
>>>>> mix, but you will not use the one from platform. Also, sometimes you
>>>>> actually can use #cr and #lf different as their immediate, common use 
>>>>> (I’ve
>>>>> seen some weird exporting formats).
>>>>>
>>>>>
>>>>>> Similar problem arises when you would write a multiline string:
>>>>>>
>>>>>> stream nextPutAll: 'first line with enter
>>>>>> second line'.
>>>>>>
>>>>>> Stored in method this will most likely contain Pharo's internal
>>>>>> representation (#cr), even though you just want a new line, and not
>>>>>> specifically #cr. (I've lost count how many times tests on CI failed
>>>>>> because of this.)
>>>>>>
>>>>>> Considering the above, my opinion is:
>>>>>>
>>>>>> 1) by default #cr, #lf, #crLf, #nl (#newLine) will write whatever is
>>>>>> globally configured for the stream (#beFor*)
>>>>>>
>>>>>
>>>>> No, I strongly disagree.
>>>>> #cr and #lf are ascii characters and should not be redefined.
>>>>>
>>>>> 2) if one wanted to combine different line endings in the same stream,
>>>>>> there should be an option to disable autoconversion.
>>>>>> (Stream>>noNewLineAutoconversion)
>>>>>>
>>>>>> If (1) is much more common than (2), then imho autoconversion should
>>>>>> cause no issues.
>>>>>> If (1) is NOT that much more common than (2), then autoconversion
>>>>>> wouldn't be beneficial.
>>>>>>
>>>>>> Autoconversion could also make transition easier because existing
>>>>>> code will suddenly work as intended here without breaking anything
>>>>>> (hopefully).
>>>>>>
>>>>>
>>>>> Sorry, I do not see what this approach solves than the other one does
>>>>> not (and as I see, this one is a lot more complicated and prone to
>>>>> confusion).
>>>>>
>>>>> cheers,
>>>>> Esteban
>>>>>
>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>> On Sat, Aug 05, 2017 at 10:49:02AM +0200, Esteban Lorenzano wrote:
>>>>>>
>>>>>>> I think there is a consensus we need to keep #cr and #lf as
>>>>>>> intended, yet to add some kind of #newLine (which btw is different to 
>>>>>>> EOL
>>>>>>> :P) vocabulary, isn’t?
>>>>>>>
>>>>>>> In this, I favour Peter approach for define line ending convention
>>>>>>> (the way #newLine will work)… and of course by default it should use the
>>>>>>> one from the current platform.
>>>>>>>
>>>>>>> anything agains this approach?
>>>>>>>
>>>>>>> Esteban
>>>>>>>
>>>>>>>
>>>>>>> On 4 Aug 2017, at 23:48, Tudor Girba <tu...@tudorgirba.com> wrote:
>>>>>>>>
>>>>>>>> +1.
>>>>>>>>
>>>>>>>> We need a basic representation of those characters. Logical ones
>>>>>>>> should be derived from the simple ones.
>>>>>>>>
>>>>>>>> Doru
>>>>>>>>
>>>>>>>>
>>>>>>>> On Aug 4, 2017, at 3:44 PM, Esteban Lorenzano <esteba...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4 Aug 2017, at 15:41, Damien Pollet <damien.pol...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I agree with Pablo, #cr and #lf should not be clever and just be
>>>>>>>>>> names for the carriage return and linefeed characters/codepoints.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Making #newLine's behavior dependent on the current platform
>>>>>>>>>> disturbs me, though. I'd rather have:
>>>>>>>>>>
>>>>>>>>>> Stream >> newLineFor: platform
>>>>>>>>>>    self nextPutAll: platform lineEnding
>>>>>>>>>>
>>>>>>>>>> Stream >> newLineForCurrentPlatform
>>>>>>>>>>    self newLineFor: OSPlatform current
>>>>>>>>>>
>>>>>>>>>> Stream >> newLineForWindows "convenience for the most common
>>>>>>>>>> platforms
>>>>>>>>>> Stream >> newLineForUnix
>>>>>>>>>> Stream >> newLineForHistoricReasons
>>>>>>>>>>
>>>>>>>>>> Stream >> newLine
>>>>>>>>>>    "delegates to one of the above, I'd argue for unix for
>>>>>>>>>> convenience, but windows is the technically correct combination of 
>>>>>>>>>> cr + lf,
>>>>>>>>>> and cr only is the historic one"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 4 August 2017 at 14:25, teso...@gmail.com <teso...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> To me it is clear that cr and lf should be in streams. But they
>>>>>>>>>> should put the 'cr' or 'lf' character only. And of course the 
>>>>>>>>>> platform
>>>>>>>>>> independent newline should be also.
>>>>>>>>>>
>>>>>>>>>> The first (cr, lf) should be used by the code wanting to have
>>>>>>>>>> absolute control of what is in the stream. The later (newline) when 
>>>>>>>>>> you
>>>>>>>>>> just want a new line.
>>>>>>>>>>
>>>>>>>>>> The two have completely different behaviour, ones are really low
>>>>>>>>>> level, the other is higher level.
>>>>>>>>>>
>>>>>>>>>> On 4 Aug 2017 14:20, "Esteban Lorenzano" <esteba...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 4 Aug 2017, at 14:06, Stephane Ducasse <
>>>>>>>>>>> stepharo.s...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Well. This is not implemented like that in Pharo.
>>>>>>>>>>>
>>>>>>>>>>> cr is bad because it does not mean that it is independent of the
>>>>>>>>>>> platform.
>>>>>>>>>>> So cr can be redefined as newLine and keep but not used inside
>>>>>>>>>>> the system.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> sometimes you actually want to write a cr (or a lf). So it needs
>>>>>>>>>> to remain in the system, of course.
>>>>>>>>>> now, including #newLine can be cool (most of the times you want
>>>>>>>>>> the “platform compatible” new line). Also I would consider including 
>>>>>>>>>> #nl,
>>>>>>>>>> abbreviated… just for convenience :P
>>>>>>>>>>
>>>>>>>>>> Esteban
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Stef
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany <
>>>>>>>>>>> jan.vr...@fit.cvut.cz> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Fri, 2017-08-04 at 12:03 +0200, Stephane Ducasse wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi guys
>>>>>>>>>>>>>
>>>>>>>>>>>>> While writing pillar code, I ended up using "stream cr" and it
>>>>>>>>>>>>> worries
>>>>>>>>>>>>> me to still expand usage
>>>>>>>>>>>>> of a pattern I would like to remove.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Let us imagine that we would like to prepare the migration
>>>>>>>>>>>>> from cr.
>>>>>>>>>>>>> I was thinking that we could replace cr invocation by newLine
>>>>>>>>>>>>> so that
>>>>>>>>>>>>> after newLine
>>>>>>>>>>>>> could be redefined as
>>>>>>>>>>>>>
>>>>>>>>>>>>> Stream >> newLine
>>>>>>>>>>>>>      self nextPutAll: OSPlatform current lineEnding
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> what do you think about this approach?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Why not? But please keep #cr.
>>>>>>>>>>>>
>>>>>>>>>>>> Section 5.9.4.1 of ANSI reads:
>>>>>>>>>>>>
>>>>>>>>>>>> Message: cr
>>>>>>>>>>>>
>>>>>>>>>>>> Synopsis
>>>>>>>>>>>> Writes an end-of-line sequence to the receiver.
>>>>>>>>>>>>
>>>>>>>>>>>> Definition: <puttableStream>
>>>>>>>>>>>> A sequence of character objects that constitute the
>>>>>>>>>>>> implementation-
>>>>>>>>>>>> defined end-of-line sequence is added to the receiver in the
>>>>>>>>>>>> same
>>>>>>>>>>>> manner as if the message  #nextPutAll: was sent to the receiver
>>>>>>>>>>>> with
>>>>>>>>>>>> an argument string whose elements are the sequence of
>>>>>>>>>>>> characters.
>>>>>>>>>>>>
>>>>>>>>>>>> Return Value
>>>>>>>>>>>> UNSPECIFIED
>>>>>>>>>>>> Errors
>>>>>>>>>>>> It is erroneous if any element of the end-of-line sequence is an
>>>>>>>>>>>> object that does not conform to the receiver's sequence value
>>>>>>>>>>>> type .
>>>>>>>>>>>>
>>>>>>>>>>>> my 2c,
>>>>>>>>>>>>
>>>>>>>>>>>> Jan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Stef
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Damien Pollet
>>>>>>>>>> type less, do more [ | ] http://people.untyped.org/damien.pollet
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> www.tudorgirba.com
>>>>>>>> www.feenk.com
>>>>>>>>
>>>>>>>> "Presenting is storytelling."
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Guille Polito
>>>>
>>>> Research Engineer
>>>> French National Center for Scientific Research - http://www.cnrs.fr
>>>>
>>>>
>>>> Web: http://guillep.github.io
>>>> Phone: +33 06 52 70 66 13
>>>>
>>>
>>>
>>>
>>
>>
>
>


-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*
<http://www.cnrs.fr>



*Web:* *http://guillep.github.io* <http://guillep.github.io>

*Phone: *+33 06 52 70 66 13

Reply via email to