Hi Guille

I agree with you :).

Stef

On Sun, Aug 6, 2017 at 11:05 AM, Guillermo Polito <guillermopol...@gmail.com
> wrote:

>
>
> On Sun, Aug 6, 2017 at 10:54 AM, Stephane Ducasse <stepharo.s...@gmail.com
> > wrote:
>
>> Agreed :)
>>
>> But so far what do we do?
>>
>>
>> - #cr and #lf just put this character in the stream.
>>
> yes. I would even be a bit more agressive. Streams work on any collection,
> not only on strings (that's why I think this is buggy!). We should move cr
> and lf to the character write streams. People that want to write characters
> should use a character write stream not a general purpose stream (on e.g.,
> a Set).
>
>
>> - #newLine put the underlying OS line ending.
>>
>
> this could just exist in a decorator, used in "text writing streams". This
> implies files, transcript, stdio. But not sockets, collections
>
>>
>> Then we should revisit all the cr inside the system and use newline.
>>
> yes
>
>
>> Then we should think about the internal usage of cr by default in
>> Pharo (We should change it).
>>
>
> Yes, and we should teach people (this means documenting :P) the correct
> usage of streams :).
>
>
>> 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/dami
>> en.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 <+33%206%2052%2070%2066%2013>
>

Reply via email to