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? Stef
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
But the question is: what does cr do? - Does it write a platform independent newLine? - Or does it write a (platform dependent) cr ascii character? http://www.theasciicode.com.ar/ascii-control-characters/carriage-return-asci... On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany <jan.vrany@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
-- 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
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. Stef On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany <jan.vrany@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
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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
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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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
I agree with Pablo, #cr and #lf should not be clever and just be names for the carriage return and linefeed characters/codepoints. 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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <mailto:tesonep@gmail.com> <tesonep@gmail.com <mailto:tesonep@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" <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@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.vrany@fit.cvut.cz <mailto:jan.vrany@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 <http://people.untyped.org/damien.pollet>
+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 <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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."
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 <tudor@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 <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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."
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
+1 I prefer #nl to #newLine, but admit that it is a subjective preference and that descriptive names are generally better. Cheers, Alistair
On 4 Aug 2017, at 23:48, Tudor Girba <tudor@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 <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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
On 5 Aug 2017, at 11:06, Alistair Grant <akgrant0710@gmail.com> wrote:
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
+1
I prefer #nl to #newLine, but admit that it is a subjective preference and that descriptive names are generally better.
heh, me too⦠but is a bit cryptic.
Cheers, Alistair
On 4 Aug 2017, at 23:48, Tudor Girba <tudor@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 <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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
On Sat, Aug 05, 2017 at 11:09:51AM +0200, Esteban Lorenzano wrote:
On 5 Aug 2017, at 11:06, Alistair Grant <akgrant0710@gmail.com> wrote:
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
+1
I prefer #nl to #newLine, but admit that it is a subjective preference and that descriptive names are generally better.
heh, me too... but is a bit cryptic.
#nl "Insert the platform dependent end of line character. For people that haven't got used to terminal communications rising above 9600baud" ^self newLine :-)
On 5 Aug 2017, at 11:14, Alistair Grant <akgrant0710@gmail.com> wrote:
On Sat, Aug 05, 2017 at 11:09:51AM +0200, Esteban Lorenzano wrote:
On 5 Aug 2017, at 11:06, Alistair Grant <akgrant0710@gmail.com> wrote:
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
+1
I prefer #nl to #newLine, but admit that it is a subjective preference and that descriptive names are generally better.
heh, me too... but is a bit cryptic.
#nl "Insert the platform dependent end of line character. For people that haven't got used to terminal communications rising above 9600baud"
^self newLine
+1
:-)
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. 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*) 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). 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 <tudor@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 <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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."
On 5 Aug 2017, at 11:17, Peter Uhnak <i.uhnak@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 <tudor@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 <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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."
Hi Esteban, On Sat, Aug 05, 2017 at 11:30:58AM +0200, Esteban Lorenzano wrote:
On 5 Aug 2017, at 11:17, Peter Uhnak <i.uhnak@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.)
I think Peter raises a good point about how strings with embedded line endings are written out. We do need to ensure that this case is handled sensibly in the new scheme. (Maybe the proposed scheme already handles this correctly, I don't know, but it should be an explicit test). Cheers, Alistair
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
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.uhnak@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 <tudor@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 <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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."
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. Guille On Sun, Aug 6, 2017 at 12:01 AM, Peter Uhnak <i.uhnak@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.uhnak@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 <tudor@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 <estebanlm@gmail.com>
wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse < stepharo.self@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.vrany@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* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
On 6 Aug 2017, at 08:59, Guillermo Polito <guillermopolito@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.uhnak@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.uhnak@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 <tudor@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 <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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
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 <sven@stfx.eu> wrote:
On 6 Aug 2017, at 08:59, Guillermo Polito <guillermopolito@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.uhnak@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.uhnak@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 <tudor@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 <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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
On Sun, Aug 6, 2017 at 10:54 AM, Stephane Ducasse <stepharo.self@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 <sven@stfx.eu> wrote:
On 6 Aug 2017, at 08:59, Guillermo Polito <guillermopolito@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.uhnak@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.uhnak@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 <tudor@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 <
estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse < stepharo.self@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.vrany@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
Hi Guille I agree with you :). Stef On Sun, Aug 6, 2017 at 11:05 AM, Guillermo Polito <guillermopolito@gmail.com
wrote:
On Sun, Aug 6, 2017 at 10:54 AM, Stephane Ducasse <stepharo.self@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 <sven@stfx.eu> wrote:
On 6 Aug 2017, at 08:59, Guillermo Polito <guillermopolito@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.uhnak@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.uhnak@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 <tudor@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 <
estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <
damien.pollet@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, tesonep@gmail.com < tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse < stepharo.self@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.vrany@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>
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" 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) 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 <sven@stfx.eu> wrote:
On 6 Aug 2017, at 08:59, Guillermo Polito <guillermopolito@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.uhnak@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.uhnak@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 <tudor@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 <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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
On Sun, Aug 6, 2017 at 11:47 AM, Thierry Goubier <thierry.goubier@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 <sven@stfx.eu> wrote:
On 6 Aug 2017, at 08:59, Guillermo Polito <guillermopolito@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.uhnak@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.uhnak@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 <tudor@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 <estebanlm@gmail.com>
wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <
stepharo.self@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.vrany@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
Hi, that's why one of the proposals was to configure the stream to either use always specific line endings stream beForWindows. stream newLine. "outputs CRLF irrespective of where the image is currently running" and stream beForCurrentPlatform. stream newLine. "returns whatever it is currently running on" Peter On Sun, Aug 06, 2017 at 11:47:26AM +0200, Thierry Goubier 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"
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)
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 <sven@stfx.eu> wrote:
On 6 Aug 2017, at 08:59, Guillermo Polito <guillermopolito@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.uhnak@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.uhnak@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 <tudor@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 <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet@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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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
On 06/08/17 15:25, Peter Uhnak wrote:
Hi,
that's why one of the proposals was to configure the stream to either use always specific line endings
stream beForWindows. stream newLine. "outputs CRLF irrespective of where the image is currently running"
and
stream beForCurrentPlatform. stream newLine. "returns whatever it is currently running on"
Hmm. I'm pretty sure it should not be a stream responsibility. What about the encoder? Stephan
On Fri, Aug 04, 2017 at 03:41:05PM +0200, Damien Pollet wrote:
Stream >> newLineForWindows "convenience for the most common platforms Stream >> newLineForUnix Stream >> newLineForHistoricReasons
Practically speaking this looks insanely wordy. In 102% (est.) you want to use the same consistent newline and not thinking about for which platform you are writing every time you want to write a new line. I think that most WriteStream miss what MultiByteFileStream has -- lineEndConvention. fileStream lineEndConvention: #lf. fileStream cr. "<- this will be autoconverted to #lf" Also I would like to see a situation where you actually _want_ to use different line endings at the same time, so converting lf/cr to the global one shouldn't break things. So maybe instead of stating what kind of line ending you want to write, you would specify them for the whole stream
Stream >> newLineForWindows "convenience for the most common platforms Stream >> newLineForUnix Stream >> newLineForHistoricReasons
Stream>>beForCurrentPlatform (would be the default maybe?) Stream>>beForWindows "crlf" Stream>>beForUnix "lf" Stream>>beAnnoyingOutsideOfPharo "cr" Peter
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, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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
On 4 August 2017 at 18:52, Peter Uhnak <i.uhnak@gmail.com> wrote:
On Fri, Aug 04, 2017 at 03:41:05PM +0200, Damien Pollet wrote:
Stream >> newLineForWindows "convenience for the most common platforms Stream >> newLineForUnix Stream >> newLineForHistoricReasons
Practically speaking this looks insanely wordy. In 102% (est.) you want to use the same consistent newline and not thinking about for which platform you are writing every time you want to write a new line.
Hmm, granted :)
I think that most WriteStream miss what MultiByteFileStream has -- lineEndConvention.
fileStream lineEndConvention: #lf.
Agreed.
fileStream cr. "<- this will be autoconverted to #lf"
No⦠please don't abuse a low-level explicit selector to mean something context-dependent. Also I would like to see a situation where you actually _want_ to use
different line endings at the same time, so converting lf/cr to the global one shouldn't break things.
But it's uglyâ¦
So maybe instead of stating what kind of line ending you want to write, you would specify them for the whole stream
Stream >> newLineForWindows "convenience for the most common platforms Stream >> newLineForUnix Stream >> newLineForHistoricReasons
Stream>>beForCurrentPlatform (would be the default maybe?)
Stream>>beForWindows "crlf" Stream>>beForUnix "lf" Stream>>beAnnoyingOutsideOfPharo "cr"
Yes, I actually prefer that to my own proposition, just don't make #cr and #lf contextually put something else than their name implies. #newline (or #nl if you prefer it concise) should be the contextual message -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On Friday 04 August 2017 07:11 PM, Damien Pollet wrote:
Stream >> newLineFor: platform self nextPutAll: platform lineEnding
EOL encoding is a property of a text file and not a platform. While files created on a certain proprietary platforms ;-) may use an encoding that does not make it a platform property. Pharo should be liberal in accepting and preserving differently encoded files. E.g. Text editor vim has a setting (fileformats) for eol encoding to view or edit files with cr or crlf EOL encoding. If this is not set, vim falls back to nl. I agree that existing messages like cr or nl should not be changed. Instead new methods (*eol) could be added to text files for decoding (read side) and encoding (write side). This should be liberal in accepting cr, nl, crnl decodes while reading a text file. While writing a new stream, eol should follow this order: 1. if file eol property is set (cr/nl/crnl) it should use it 2. else fallback to check platform eol property. 3. Else, use cr (for backward compatibility with old files) E.g. (aStream atEOL) ifFalse: [ c := aStream next ] aStream nextPutAll: 'hello world' ; writeEOL record := aStream readLine. "strip eol" aStream nextPutLine: 'hello world' This is not going to be an easy change but it would make new code cleaner. Regards .. Subbu
So one step at a time: - #cr and #lf just put this character in the stream. - #newLine put the underlying OS line ending. ( and sorry for the nostalgic but nl sucks and to me this is netherlands and not newline :). 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 On Sat, Aug 5, 2017 at 4:08 PM, K K Subbu <kksubbu.ml@gmail.com> wrote:
On Friday 04 August 2017 07:11 PM, Damien Pollet wrote:
Stream >> newLineFor: platform self nextPutAll: platform lineEnding
EOL encoding is a property of a text file and not a platform. While files created on a certain proprietary platforms ;-) may use an encoding that does not make it a platform property. Pharo should be liberal in accepting and preserving differently encoded files. E.g. Text editor vim has a setting (fileformats) for eol encoding to view or edit files with cr or crlf EOL encoding. If this is not set, vim falls back to nl.
I agree that existing messages like cr or nl should not be changed. Instead new methods (*eol) could be added to text files for decoding (read side) and encoding (write side). This should be liberal in accepting cr, nl, crnl decodes while reading a text file. While writing a new stream, eol should follow this order: 1. if file eol property is set (cr/nl/crnl) it should use it 2. else fallback to check platform eol property. 3. Else, use cr (for backward compatibility with old files) E.g.
(aStream atEOL) ifFalse: [ c := aStream next ] aStream nextPutAll: 'hello world' ; writeEOL record := aStream readLine. "strip eol" aStream nextPutLine: 'hello world'
This is not going to be an easy change but it would make new code cleaner.
Regards .. Subbu
On Sat, Aug 5, 2017 at 6:14 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
So one step at a time:
- #cr and #lf just put this character in the stream. - #newLine put the underlying OS line ending. ( and sorry for the nostalgic but nl sucks and to me this is netherlands and not newline :).
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
I like that. For the internal usage of Pharo I would not use cr since it is used by nobody in current systems. But that's just my opinion :) -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
:) Me too. Stef On Sat, Aug 5, 2017 at 6:32 PM, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
On Sat, Aug 5, 2017 at 6:14 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
So one step at a time:
- #cr and #lf just put this character in the stream. - #newLine put the underlying OS line ending. ( and sorry for the nostalgic but nl sucks and to me this is netherlands and not newline :).
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
I like that.
For the internal usage of Pharo I would not use cr since it is used by nobody in current systems. But that's just my opinion :)
-- Cyril Ferlicot https://ferlicot.fr
http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
Hi Stef, On 5 August 2017 at 18:14, Stephane Ducasse <stepharo.self@gmail.com> wrote:
So one step at a time:
- #cr and #lf just put this character in the stream. - #newLine put the underlying OS line ending. ( and sorry for the nostalgic but nl sucks and to me this is netherlands and not newline :).
Beyond the nostalgic and humorous, there is actually a justification for the shorter #nl. Adding a new line is a common operation, and more compact code is more readable. So I find: stream << 'Line 1 goes here'; nl; << 'Line 2 goes here'; nl. better than: stream nextPutAll: 'Line 1 goes here'; newLine; nextPutAll: 'Line 2 goes here'; newLine. Although this is still subjective. Cheers, Alistair
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
On Sat, Aug 5, 2017 at 4:08 PM, K K Subbu <kksubbu.ml@gmail.com> wrote:
On Friday 04 August 2017 07:11 PM, Damien Pollet wrote:
Stream >> newLineFor: platform self nextPutAll: platform lineEnding
EOL encoding is a property of a text file and not a platform. While files created on a certain proprietary platforms ;-) may use an encoding that does not make it a platform property. Pharo should be liberal in accepting and preserving differently encoded files. E.g. Text editor vim has a setting (fileformats) for eol encoding to view or edit files with cr or crlf EOL encoding. If this is not set, vim falls back to nl.
I agree that existing messages like cr or nl should not be changed. Instead new methods (*eol) could be added to text files for decoding (read side) and encoding (write side). This should be liberal in accepting cr, nl, crnl decodes while reading a text file. While writing a new stream, eol should follow this order: 1. if file eol property is set (cr/nl/crnl) it should use it 2. else fallback to check platform eol property. 3. Else, use cr (for backward compatibility with old files) E.g.
(aStream atEOL) ifFalse: [ c := aStream next ] aStream nextPutAll: 'hello world' ; writeEOL record := aStream readLine. "strip eol" aStream nextPutLine: 'hello world'
This is not going to be an easy change but it would make new code cleaner.
Regards .. Subbu
Hi all, First, we should not confuse "writing into a stream" with "writing into a text file". Not all streams are to write into a text file. This means that we cannot pretend that the basic stream implementation should always do a conversion. I think that should belong to a text writer, also managing the text encoding (utf-8 and so on). So far we have a Character writer stream that wraps a binary stream and manages encoding (see ZnCharacterWriteStream). I wrote for backwards compatibility a ZnCrPortableWriteStream (that is in pharo repo so far because but should be pushed back to Zinc's repo, hi Sven :) ) that manages crlf automatic conversion also. Moreover, for people that want "detection of line separators in a file" such as it is done in text editors, I believe we need a higher level abstraction. We need also to detect encoding and keep living during the life of the file. However, we don't have such abstraction. Guille On Sat, Aug 5, 2017 at 8:03 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Stef,
On 5 August 2017 at 18:14, Stephane Ducasse <stepharo.self@gmail.com> wrote:
So one step at a time:
- #cr and #lf just put this character in the stream. - #newLine put the underlying OS line ending. ( and sorry for the nostalgic but nl sucks and to me this is netherlands and not newline :).
Beyond the nostalgic and humorous, there is actually a justification for the shorter #nl.
Adding a new line is a common operation, and more compact code is more readable. So I find:
stream << 'Line 1 goes here'; nl; << 'Line 2 goes here'; nl.
better than:
stream nextPutAll: 'Line 1 goes here'; newLine; nextPutAll: 'Line 2 goes here'; newLine.
Although this is still subjective.
Cheers, Alistair
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
On Sat, Aug 5, 2017 at 4:08 PM, K K Subbu <kksubbu.ml@gmail.com> wrote:
On Friday 04 August 2017 07:11 PM, Damien Pollet wrote:
Stream >> newLineFor: platform self nextPutAll: platform lineEnding
EOL encoding is a property of a text file and not a platform. While files created on a certain proprietary platforms ;-) may use an encoding that does not make it a platform property. Pharo should be liberal in accepting and preserving differently encoded files. E.g. Text editor vim has a setting (fileformats) for eol encoding to view or edit files with cr or crlf EOL encoding. If this is not set, vim falls back to nl.
I agree that existing messages like cr or nl should not be changed. Instead new methods (*eol) could be added to text files for decoding (read side) and encoding (write side). This should be liberal in accepting cr, nl, crnl decodes while reading a text file. While writing a new stream, eol should follow this order: 1. if file eol property is set (cr/nl/crnl) it should use it 2. else fallback to check platform eol property. 3. Else, use cr (for backward compatibility with old files) E.g.
(aStream atEOL) ifFalse: [ c := aStream next ] aStream nextPutAll: 'hello world' ; writeEOL record := aStream readLine. "strip eol" aStream nextPutLine: 'hello world'
This is not going to be an easy change but it would make new code cleaner.
Regards .. Subbu
-- 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
Yes :) On Fri, Aug 4, 2017 at 2:25 PM, tesonep@gmail.com <tesonep@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" <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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
or eol On Fri, Aug 4, 2017 at 9:19 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self@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.vrany@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
-- Javier Pimás Ciudad de Buenos Aires
+1 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Aug 4, 2017, at 8:19 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
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
On Fri, 2017-08-04 at 14:06 +0200, Stephane Ducasse 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.
Yes, that's exactly what I meant. cr self newLine Jan
Stef
On Fri, Aug 4, 2017 at 12:50 PM, Jan Vrany <jan.vrany@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
I vote for: #cr and #lf just put this character in the stream. #newLine put the underlying OS line ending. This is consisten also with String>>expandMacrosWithArguments: <r> -> cr <l> -> lf <n> -> OSPlatform current lineEnding On Fri, Aug 4, 2017 at 7:03 AM, Stephane Ducasse <stepharo.self@gmail.com> 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?
Stef
participants (17)
-
Alexandre Bergel -
Alistair Grant -
Cyril Ferlicot -
Damien Pollet -
Esteban Lorenzano -
Gabriel Cotelli -
Guillermo Polito -
Jan Vrany -
Javier Pimás -
K K Subbu -
Peter Uhnak -
Stephan Eggermont -
Stephane Ducasse -
Sven Van Caekenberghe -
tesonep＠gmail.com -
Thierry Goubier -
Tudor Girba