- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ann] moldable brick editor - alpha

by Alexandre Bergel

This is gorgeous! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Aug 4, 2017, at 6:19 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We are very happy to announce the alpha version of a moldable editor built in Brick (https://github.com/pharo-graphics/Brick) which is based on Bloc (https://github.com/pharo-graphics/Bloc) This is primarily the work of Alex Syrel. The project was initially financially sponsored by ESUG and it is currently supported by feenk. And of course, the project is based on the tremendous work that went into Bloc and Brick by all contributors. > > Take a look at this 2 min video: > https://www.youtube.com/watch?v=2vy6VMJM9W4&feature=youtu.be > > The basic editor works and it is both flexible and scalable. For example, the last example shown in the video is an editor opened on 1M characters, which is reasonably large, and as can be seen see one can interact with it as smoothly as with the one screen text. It actually works just as fine with 100M characters. > > The functionality of the editor includes: rendering, line wrapping, keypress and shortcut handling, navigation, selection and text styling. Currently, the editor is 1260 lines of code including method and class comments. This is not large for a text editor and this is possible because most of the work is done by generic concepts that already exist in Bloc such as layouts and text measurements. Beside the small maintenance cost, the benefit is that we have the option to build all sorts of variations with little effort. That is why we call this a moldable text editor. > > Another benefit of using elements and layouts is that we can also embed other kinds of non-text elements with little effort (such as pictures), and obtain a rich and live text editor. We already have basic examples for this behavior, and we will focus more in the next period on this area. > > The next immediate step is to add syntax highlighting. Beside the text attributes problem, this issue will also exercise the thread-safety the implementation is. The underlying structure (https://en.wikipedia.org/wiki/Rope_(data_structure)) is theoretically thread-safe, but it still needs to be proven in practice. > > We think this is a significant step because the editor was the main piece missing in Brick and it will finally allow us to build value that can be directly perceived by regular users on top of Brick and this, in turn, will generate more traction. Please also note that because now Bloc is directly embeddable in Morphic it means that we can actually start using it right away. For example, the picture below shows the text element being shown through a live preview in the GTInspector. > > <AC36A55F-405C-6147-9E0F-BA1F6F1008BA.png> > > This is another puzzle piece towards the final goal of engineering the future of the Pharo user interface. There is still a long way to go to reach that goal, but considering the work that is behind us, that goal that looked so illusive when Alain and Stef initiated the Bloc project is now palpable. > > We will continue the work on this over the next period and we expect to announce new developments soon. > > If you want to play with it, you can load the code like this (works in both Pharo 6 and 7): > Iceberg enableMetacelloIntegration: true. > Metacello new > baseline: 'Brick'; > repository: 'github://pharo-graphics/Brick/src'; > load: #development > > Please let us know what you think. > > Cheers, > Alex and Doru > > > > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" >

Aug. 5, 2017

Re: [Pharo-dev] About cr and lf

by Alistair Grant

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(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.) 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

Aug. 5, 2017

Re: [Pharo-dev] About cr and lf

by Esteban Lorenzano

> 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." >>> >>> >> >> >

Aug. 5, 2017

Re: [Pharo-dev] About cr and lf

by Peter Uhnak

> 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(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." > > > > > >

Aug. 5, 2017

Re: [Pharo-dev] About cr and lf

by Esteban Lorenzano

> On 5 Aug 2017, at 11:14, Alistair Grant <akgrant0710(a)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(a)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 > > > > :-)

Aug. 5, 2017

Re: [Pharo-dev] About cr and lf

by Alistair Grant

On Sat, Aug 05, 2017 at 11:09:51AM +0200, Esteban Lorenzano wrote: > > > On 5 Aug 2017, at 11:06, Alistair Grant <akgrant0710(a)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 :-)

Aug. 5, 2017

Re: [Pharo-dev] About cr and lf

by Esteban Lorenzano

> On 5 Aug 2017, at 11:06, Alistair Grant <akgrant0710(a)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(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 >

Aug. 5, 2017

Re: [Pharo-dev] About cr and lf

by Alistair Grant

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(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

Aug. 5, 2017

Re: [Pharo-dev] About cr and lf

by Esteban Lorenzano

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." > >

Aug. 5, 2017

ZnEasy question

by milton mamani

Hi to all I want to use the next instruction in my code response := ZnEasy get: 'https://archive.softwareheritage.org/api/1/ origin/git/url/https://github.com/hylang/hy'. response. The previous code works from command line or in a webbrowser, but I does not work with ZnEasy Because it takes the previous link as: a ZnRequest(GET /api/1/origin/git/url/https:/github.com/hylang/hy) Could you please tell me what can I do for this situation? Cheers, Milton

Aug. 5, 2017