August 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Having green builds

by Guillermo Polito

And for the lazy ones, here is the link to the build (that can be also accessed from the PR) https://ci.inria.fr/pharo-ci-jenkins2/job/test%20multibranch%20pipeline/job… On Sun, Aug 6, 2017 at 11:00 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi all, > > As you all know, we are now building from github. Integrations are made > through pull requests. And pull requests are validated using jenkins (that > is back again, Yay!). > > In this scenario, pull requests validations in github differentiate only > between three states: Pased (green) and not passed (red). This of course > conflicts with the three-state jobs of jenkins. By default jenkins > transforms failing tests (yellow) to a red state. This means that we lose > the extra information provided by the intermediate state. > > Now, because of this, in order to really differentiate good builds from > bad builds, we need to have green builds :). Always. > > Yesterday we worked with Pablo on that and now we have a PR that fixes all > tests and is green :) > > https://github.com/pharo-project/pharo/pull/184 > > You can follow up all the things we did in the issue also: > > https://pharo.fogbugz.com/f/cases/20288/Fix-failing-tests-in-pharo-70 > > As a summary, we could fix most tests by just touching some code here and > there. Some of them were portability issues, some other encoding in the > build slaves and so on. The only one we could not fix was a problem cause > by a side effect of QualityAssistant-Tests, so we skipped it. Those two > tests should be rewritten to not have side effects on other tests (In this > case, Epicea). > > Enjoy, > Guille and Pablo > > -- > > > > 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> > -- 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

Aug. 6, 2017

Re: [Pharo-dev] About cr and lf

by Guillermo Polito

On Sun, Aug 6, 2017 at 10:54 AM, Stephane Ducasse <stepharo.self(a)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(a)stfx.eu> > wrote: > > > >> On 6 Aug 2017, at 08:59, Guillermo Polito <guillermopolito(a)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(a)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(a)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(a)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(a)gmail.com> wrote: > >> > >>>> > >> > >>>> > >> > >>>>> On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet(a)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(a)gmail.com <tesonep(a)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(a)gmail.com> > wrote: > >> > >>>>> > >> > >>>>>> On 4 Aug 2017, at 14:06, Stephane Ducasse < > stepharo.self(a)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(a)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

Aug. 6, 2017

Having green builds

by Guillermo Polito

Hi all, As you all know, we are now building from github. Integrations are made through pull requests. And pull requests are validated using jenkins (that is back again, Yay!). In this scenario, pull requests validations in github differentiate only between three states: Pased (green) and not passed (red). This of course conflicts with the three-state jobs of jenkins. By default jenkins transforms failing tests (yellow) to a red state. This means that we lose the extra information provided by the intermediate state. Now, because of this, in order to really differentiate good builds from bad builds, we need to have green builds :). Always. Yesterday we worked with Pablo on that and now we have a PR that fixes all tests and is green :) https://github.com/pharo-project/pharo/pull/184 You can follow up all the things we did in the issue also: https://pharo.fogbugz.com/f/cases/20288/Fix-failing-tests-in-pharo-70 As a summary, we could fix most tests by just touching some code here and there. Some of them were portability issues, some other encoding in the build slaves and so on. The only one we could not fix was a problem cause by a side effect of QualityAssistant-Tests, so we skipped it. Those two tests should be rewritten to not have side effects on other tests (In this case, Epicea). Enjoy, Guille and Pablo -- 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

Aug. 6, 2017

Re: [Pharo-dev] About cr and lf

by Stephane Ducasse

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(a)stfx.eu> wrote: > >> On 6 Aug 2017, at 08:59, Guillermo Polito <guillermopolito(a)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(a)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(a)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(a)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(a)gmail.com> wrote: >> > >>>> >> > >>>> >> > >>>>> On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet(a)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(a)gmail.com <tesonep(a)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(a)gmail.com> wrote: >> > >>>>> >> > >>>>>> On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self(a)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(a)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 > >

Aug. 6, 2017

Re: [Pharo-dev] About cr and lf

by Sven Van Caekenberghe

> On 6 Aug 2017, at 08:59, Guillermo Polito <guillermopolito(a)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(a)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(a)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(a)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(a)gmail.com> wrote: > > >>>> > > >>>> > > >>>>> On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet(a)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(a)gmail.com <tesonep(a)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(a)gmail.com> wrote: > > >>>>> > > >>>>>> On 4 Aug 2017, at 14:06, Stephane Ducasse <stepharo.self(a)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(a)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

Aug. 6, 2017

Re: [Pharo-dev] PharoLauncher - uninformative Pharo7 template names

by Guillermo Polito

About tagging... It looks super ackward to me to tag EVERY commit with "build information". Building does not mean releasing... I prefer the other way around: we tag builds with commit information. Like that we know how to reproduce the build. I'm ok with tagging build artifacts by explicitly saying "this is BUILD #X", which is ~= from "this is RELEASE #X". Moreover, before we needed to store ALL versions of the image because that was the way we versionned the system. Now, every commit in the #development branch should be buildable (delta some bugs of course ;)). This means that we can rebuild all images by just iterating the git history and building from scratch. No need to store all images. On Sun, Aug 6, 2017 at 9:40 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > I made a PR > > https://github.com/pharo-project/pharo/pull/185 > > this PR adds a script that will rename built archives accordingly. I > propose the following file names for the zip: > > Pharo${IMAGE_KIND}-7.0.0-arch.32bit.sha.${HASH}.build.${BUILD_NUMBER}.zip > > Where: > > IMAGE_KIND is the built product (core image, image with monticello, image > with metacello, full image...) > HASH is the commit hash > BUILD_NUMBER is the build number set by jenkins, or "nobuildnumber" if not > available > > > Moreover, this only makes part of a "prepare for upload" script and not > the main build process. That is because of simplicity right now. However, > if we put the build number by default in the main archives, there may be > several drawbacks: > > - PR's builds will have build numbers conflicting with the main builds > (which may be confusing) > - when building locally, we do not necessarily have a build number > available so it does not make much sense > > Once the PR is accepted/integrated, we should change the build process to > use this script. > > Guille > > > On Sun, Aug 6, 2017 at 9:05 AM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi, I created an issue: >> >> https://pharo.fogbugz.com/f/cases/20290/Add-build-number-to- >> uploaded-files >> >> I propose to keep both the sha and add the build number. Also, to follow >> semantic version conventions, we should use $- instead of $/. Something >> like: >> >> {Major}.{Minor}.{Patch}-sha.{sha}.build.{buildnumber} >> >> What do you think? I'll propose a pull request in some minutes. >> >> On Sat, Aug 5, 2017 at 6:17 PM, Stephane Ducasse <stepharo.self(a)gmail.com >> > wrote: >> >>> Hi torsten >>> >>> Yes it sounds good to have MAJOR.MINOR.PATCH/BUILDNUMBER scheme >>> >>> On Fri, Aug 4, 2017 at 9:22 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>> > Hi Ben, >>> > >>> > reason is that for Pharo 7 currently an sha git hash is used in the >>> file >>> > name >>> > instead of a (more clear) build number. >>> > >>> > See http://files.pharo.org/image/70/ >>> > >>> > This problem (which has more side effects on different sides, not only >>> the >>> > Launcher now) was discussed >>> > already yesterday on Discord #iceberg channel with Esteban and Pavel. >>> > >>> > The current sha based image file name scheme is not only confusing but >>> has >>> > some downsides. >>> > One can not easily remember the SHA or see which image is the latest, >>> or >>> > sort from recent >>> > images to older in a folder. >>> > >>> > If I understood correctly the reason to (initially) choose sha's in the >>> > image name has something >>> > to do with Travis and a discussion between Pavel, Esteban and Guille. >>> > >>> > I would vote for using Build numbers again. >>> > >>> > We would have several BENEFITS when keeping/returning to build numbers >>> for >>> > Pharo 7: >>> > - we do not change image file names, about box behavior, ... >>> compared to >>> > previous Pharo version < 7 >>> > (as we used image build number already in the past) >>> > - we tag each release as before and see it in Git (we can easily >>> reproduce) >>> > - the build number easily tells you which image is more recent (as >>> before) >>> > - we can easily sort when we have several images in a directory >>> > - a build number is more readable and recognizable by a human >>> (compared to >>> > the shas) >>> > - Pharo is not an "aliens" compared to the rest of the software world >>> as >>> > often software >>> > follows a MAJOR.MINOR.PATCH/BUILDNUMBER scheme (see semver.org) >>> > - we do not change the order in Launcher (higher numbers at the top to >>> > download more recent) >>> > >>> > According to the discussion with Esteban and Pavel it is technically >>> > possible to have build numbers again - >>> > it means to tag each commit again with a build number (we already did >>> this >>> > for Pharo 6, >>> > see https://github.com/pharo-project/pharo/releases) >>> > >>> > The outcome from yesterday was that Pavel will discuss again with >>> Guile on >>> > that topic. It would be good if others >>> > could comment on that topic too. Maybe we can return to the known build >>> > number scheme >>> > or (if there are problems with that) at least know the arguments why >>> we need >>> > to be exotic/different on >>> > this corner in the future. >>> > >>> > Thanks >>> > T. >>> > >>> > Gesendet: Donnerstag, 03. August 2017 um 15:41 Uhr >>> > Von: "Ben Coman" <btc(a)openinworld.com> >>> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> > Betreff: [Pharo-dev] PharoLauncher - uninformative Pharo7 template >>> names >>> > >>> > Attached is what I see for Pharo 7 images in PharoLauncher. >>> > I presume the top one is the latest, but Its a bit hard to tell :P >>> > Anyone else seeing this? >>> > >>> > Loading ConfigurationOfPharoLauncher-ChristopheDemarey.53 (latest) >>> > and doing "ConfigurationOfPharoLauncher loadDevelopment" >>> > which loads PharoLauncher-Core-ChristopheDemarey.116 (latest) >>> > >>> > This is with Pharo builds 60486 and 60510, and same VM for both... >>> > Win32 built on May 31 2017 03:09:04 GMT Compiler: 5.4.0 VMMaker >>> > versionString VM: 201705310241 >>> > CoInterpreter VMMaker.oscog-eem.2231 uuid: >>> > de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017 >>> > >>> > (but btw, does that look strange? The 60510 image was lauched from the >>> > original 60486-PharoLauncher which said it was downloading the >>> matching VM, >>> > so I kind of expect each image to have a different VM ?? ) >>> > >>> > cheers -ben >>> >>> >> >> >> -- >> >> >> >> 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> >> > > > > -- > > > > 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> > -- 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

Aug. 6, 2017

Re: [Pharo-dev] PharoLauncher - uninformative Pharo7 template names

by Guillermo Polito

I made a PR https://github.com/pharo-project/pharo/pull/185 this PR adds a script that will rename built archives accordingly. I propose the following file names for the zip: Pharo${IMAGE_KIND}-7.0.0-arch.32bit.sha.${HASH}.build.${BUILD_NUMBER}.zip Where: IMAGE_KIND is the built product (core image, image with monticello, image with metacello, full image...) HASH is the commit hash BUILD_NUMBER is the build number set by jenkins, or "nobuildnumber" if not available Moreover, this only makes part of a "prepare for upload" script and not the main build process. That is because of simplicity right now. However, if we put the build number by default in the main archives, there may be several drawbacks: - PR's builds will have build numbers conflicting with the main builds (which may be confusing) - when building locally, we do not necessarily have a build number available so it does not make much sense Once the PR is accepted/integrated, we should change the build process to use this script. Guille On Sun, Aug 6, 2017 at 9:05 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi, I created an issue: > > https://pharo.fogbugz.com/f/cases/20290/Add-build-number-to-uploaded-files > > I propose to keep both the sha and add the build number. Also, to follow > semantic version conventions, we should use $- instead of $/. Something > like: > > {Major}.{Minor}.{Patch}-sha.{sha}.build.{buildnumber} > > What do you think? I'll propose a pull request in some minutes. > > On Sat, Aug 5, 2017 at 6:17 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> Hi torsten >> >> Yes it sounds good to have MAJOR.MINOR.PATCH/BUILDNUMBER scheme >> >> On Fri, Aug 4, 2017 at 9:22 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >> > Hi Ben, >> > >> > reason is that for Pharo 7 currently an sha git hash is used in the file >> > name >> > instead of a (more clear) build number. >> > >> > See http://files.pharo.org/image/70/ >> > >> > This problem (which has more side effects on different sides, not only >> the >> > Launcher now) was discussed >> > already yesterday on Discord #iceberg channel with Esteban and Pavel. >> > >> > The current sha based image file name scheme is not only confusing but >> has >> > some downsides. >> > One can not easily remember the SHA or see which image is the latest, or >> > sort from recent >> > images to older in a folder. >> > >> > If I understood correctly the reason to (initially) choose sha's in the >> > image name has something >> > to do with Travis and a discussion between Pavel, Esteban and Guille. >> > >> > I would vote for using Build numbers again. >> > >> > We would have several BENEFITS when keeping/returning to build numbers >> for >> > Pharo 7: >> > - we do not change image file names, about box behavior, ... compared >> to >> > previous Pharo version < 7 >> > (as we used image build number already in the past) >> > - we tag each release as before and see it in Git (we can easily >> reproduce) >> > - the build number easily tells you which image is more recent (as >> before) >> > - we can easily sort when we have several images in a directory >> > - a build number is more readable and recognizable by a human >> (compared to >> > the shas) >> > - Pharo is not an "aliens" compared to the rest of the software world >> as >> > often software >> > follows a MAJOR.MINOR.PATCH/BUILDNUMBER scheme (see semver.org) >> > - we do not change the order in Launcher (higher numbers at the top to >> > download more recent) >> > >> > According to the discussion with Esteban and Pavel it is technically >> > possible to have build numbers again - >> > it means to tag each commit again with a build number (we already did >> this >> > for Pharo 6, >> > see https://github.com/pharo-project/pharo/releases) >> > >> > The outcome from yesterday was that Pavel will discuss again with Guile >> on >> > that topic. It would be good if others >> > could comment on that topic too. Maybe we can return to the known build >> > number scheme >> > or (if there are problems with that) at least know the arguments why we >> need >> > to be exotic/different on >> > this corner in the future. >> > >> > Thanks >> > T. >> > >> > Gesendet: Donnerstag, 03. August 2017 um 15:41 Uhr >> > Von: "Ben Coman" <btc(a)openinworld.com> >> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> > Betreff: [Pharo-dev] PharoLauncher - uninformative Pharo7 template names >> > >> > Attached is what I see for Pharo 7 images in PharoLauncher. >> > I presume the top one is the latest, but Its a bit hard to tell :P >> > Anyone else seeing this? >> > >> > Loading ConfigurationOfPharoLauncher-ChristopheDemarey.53 (latest) >> > and doing "ConfigurationOfPharoLauncher loadDevelopment" >> > which loads PharoLauncher-Core-ChristopheDemarey.116 (latest) >> > >> > This is with Pharo builds 60486 and 60510, and same VM for both... >> > Win32 built on May 31 2017 03:09:04 GMT Compiler: 5.4.0 VMMaker >> > versionString VM: 201705310241 >> > CoInterpreter VMMaker.oscog-eem.2231 uuid: >> > de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017 >> > >> > (but btw, does that look strange? The 60510 image was lauched from the >> > original 60486-PharoLauncher which said it was downloading the matching >> VM, >> > so I kind of expect each image to have a different VM ?? ) >> > >> > cheers -ben >> >> > > > -- > > > > 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> > -- 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

Aug. 6, 2017

Re: [Pharo-dev] PharoLauncher - uninformative Pharo7 template names

by Guillermo Polito

Hi, I created an issue: https://pharo.fogbugz.com/f/cases/20290/Add-build-number-to-uploaded-files I propose to keep both the sha and add the build number. Also, to follow semantic version conventions, we should use $- instead of $/. Something like: {Major}.{Minor}.{Patch}-sha.{sha}.build.{buildnumber} What do you think? I'll propose a pull request in some minutes. On Sat, Aug 5, 2017 at 6:17 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi torsten > > Yes it sounds good to have MAJOR.MINOR.PATCH/BUILDNUMBER scheme > > On Fri, Aug 4, 2017 at 9:22 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Ben, > > > > reason is that for Pharo 7 currently an sha git hash is used in the file > > name > > instead of a (more clear) build number. > > > > See http://files.pharo.org/image/70/ > > > > This problem (which has more side effects on different sides, not only > the > > Launcher now) was discussed > > already yesterday on Discord #iceberg channel with Esteban and Pavel. > > > > The current sha based image file name scheme is not only confusing but > has > > some downsides. > > One can not easily remember the SHA or see which image is the latest, or > > sort from recent > > images to older in a folder. > > > > If I understood correctly the reason to (initially) choose sha's in the > > image name has something > > to do with Travis and a discussion between Pavel, Esteban and Guille. > > > > I would vote for using Build numbers again. > > > > We would have several BENEFITS when keeping/returning to build numbers > for > > Pharo 7: > > - we do not change image file names, about box behavior, ... compared > to > > previous Pharo version < 7 > > (as we used image build number already in the past) > > - we tag each release as before and see it in Git (we can easily > reproduce) > > - the build number easily tells you which image is more recent (as > before) > > - we can easily sort when we have several images in a directory > > - a build number is more readable and recognizable by a human (compared > to > > the shas) > > - Pharo is not an "aliens" compared to the rest of the software world as > > often software > > follows a MAJOR.MINOR.PATCH/BUILDNUMBER scheme (see semver.org) > > - we do not change the order in Launcher (higher numbers at the top to > > download more recent) > > > > According to the discussion with Esteban and Pavel it is technically > > possible to have build numbers again - > > it means to tag each commit again with a build number (we already did > this > > for Pharo 6, > > see https://github.com/pharo-project/pharo/releases) > > > > The outcome from yesterday was that Pavel will discuss again with Guile > on > > that topic. It would be good if others > > could comment on that topic too. Maybe we can return to the known build > > number scheme > > or (if there are problems with that) at least know the arguments why we > need > > to be exotic/different on > > this corner in the future. > > > > Thanks > > T. > > > > Gesendet: Donnerstag, 03. August 2017 um 15:41 Uhr > > Von: "Ben Coman" <btc(a)openinworld.com> > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > Betreff: [Pharo-dev] PharoLauncher - uninformative Pharo7 template names > > > > Attached is what I see for Pharo 7 images in PharoLauncher. > > I presume the top one is the latest, but Its a bit hard to tell :P > > Anyone else seeing this? > > > > Loading ConfigurationOfPharoLauncher-ChristopheDemarey.53 (latest) > > and doing "ConfigurationOfPharoLauncher loadDevelopment" > > which loads PharoLauncher-Core-ChristopheDemarey.116 (latest) > > > > This is with Pharo builds 60486 and 60510, and same VM for both... > > Win32 built on May 31 2017 03:09:04 GMT Compiler: 5.4.0 VMMaker > > versionString VM: 201705310241 > > CoInterpreter VMMaker.oscog-eem.2231 uuid: > > de62947a-7f40-4977-a232-e06a3a80c939 May 31 2017 > > > > (but btw, does that look strange? The 60510 image was lauched from the > > original 60486-PharoLauncher which said it was downloading the matching > VM, > > so I kind of expect each image to have a different VM ?? ) > > > > cheers -ben > > -- 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

Aug. 6, 2017

Re: [Pharo-dev] About cr and lf

by Guillermo Polito

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(a)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(a)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(a)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(a)gmail.com> > wrote: > > >>>> > > >>>> > > >>>>> On 4 Aug 2017, at 15:41, Damien Pollet <damien.pollet(a)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(a)gmail.com <tesonep(a)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(a)gmail.com> > wrote: > > >>>>> > > >>>>>> On 4 Aug 2017, at 14:06, Stephane Ducasse < > stepharo.self(a)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(a)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

Aug. 6, 2017

Re: [Pharo-dev] Spec menu extensibility (epicea)

by Peter Uhnak

Hi Stef, I faced similar issue and then I've found out that PragmaMenuBuilder is compatible with Spec. Something like... builder := PragmaMenuBuilder pragmaKeyword: 'myPragma' model: self. menu := MenuModel new. menu fromSpec: builder menuSpec. Peter On Sat, Aug 05, 2017 at 06:26:45PM +0200, Stephane Ducasse wrote: > Hi guys > > I would like to know if there is a pattern to build extensible menu in Spec. > For example, I extending Epicea to support pillar fileout so that I > can turn a coding section into a pillar steps of action. > > I wanted to extend the epicea browser to get my menu in: > But the code is like that: > > EPLogBrowserModel >> addMenuItemsForSelectedItemsIn: aMenu > > aMenu addGroup: [ :aGroup | > self menuActionsForSelectedItems do: [ :oldStyleMenuItemArray | > aGroup addItem: [ :anItem | > anItem > name: oldStyleMenuItemArray first; > description: oldStyleMenuItemArray third; > icon: (self iconNamed: oldStyleMenuItemArray fourth); > action: [ self perform: oldStyleMenuItemArray second ] ] ] ]. > > aMenu addGroup: [ :aGroup | > aGroup addItem: [ :anItem | > anItem > name: 'Filters'; > icon: (self iconNamed: #smallFindIcon); > subMenu: self filtersSubMenu ] ]. > > aMenu addGroup: [ :aGroup | > aGroup addItem: [ :anItem | > anItem > name: 'File Out'; > description: 'Write selected entries to an Ombu file'; > icon: (self iconNamed: #smallSaveAsIcon); > action: [ self fileOutSelection ] ] ]. > > > EPLogBrowserModel >> menuMorphForSelectedItems > > | aMenu | > aMenu := MenuModel new. > showEntryItemMenu ifTrue: [ self > addMenuItemsForSelectedItemsIn: aMenu ]. > ^ aMenu buildWithSpecAsPopup > > > So I would like to improve Epicea but I face the problem of the limits > of Spec (presumably). > I'm thinking to add a <specMenu: 10> pragma to handle this case. > Any thought. > > Stef >

Aug. 5, 2017