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

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

by Aliaksei Syrel

Hi Denis, Thanks a lot for looking into it :) See my answers for every point below: 1) Loading in Pharo 7 signal dependency error: That is true, but I can not do anything about it now :( OSWindow-SDL depends on Athens (while it should not). In Bloc we don't use / need Athens but because of OSWindow's dependency Athens tries to update itself. Additionally the classes you mentioned were removed from the system, while Athens adds extension methods to them => error during installation. In Pharo 6 there is no error, though. 2) Text cursor up/down is not working correctly when text is wrapped. Indeed, up/down movement is a bit tricky :) But its implementation is in fact very interesting. Take a look at this video: â Bloc-FocusNavigationLong.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTVEFlemwzeTNibEk/view?usp=drive…> â Bloc has support of element-independent *visual* focus navigation. In the editor we reuse it for the cursor (one cursor for a moment but we target to support multiple). However, because of text's special nature it is not super smooth but will be improved :) 3) I look a bit at text commands (TextEditorCommand) and found that current > KeyMapping package ($a asShortcut) is not used. Instead there is new > hierarchy of BlKeyCombination. It is a special bloc feature that requires its own announcement. As a teaser I can say that we rely on *Key* and not on *Character + modifiers* while defining shortcuts. It allows us to build any *key* combinations possible. For example we distinguish left and right shift, left and right meta, etc. Shortcuts can consist only of one Key or be just only right shift :) It is super flexible but we will come to it later ;) P.S. arrows are also treated at shortcuts and not as keystroke: meaning that there is no need to do this: [image: Inline images 1] 4) I thing we should try to use Commander for new UI widgets. For example > It is very naturally applied to TextEditorCommand hierarchy. And it will > automatically remove hardcoded shortcuts defined in method > BrTextEditor>>onAttached: Commander didn't yet made it into release :) Just as prove of concept I hardcoded shortcuts in onAttached: tin order to show that *they all* are in one single place. There is no other place where we check if any modifier keys pressed! It is beautiful and will allow us to ship editor with fully customisable shortcuts (nothing should stop us from having vim bindings). Cheers, Alex On 6 August 2017 at 19:17, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Good job guys. > > Here is my feedback: > > 1) Loading in Pharo 7 signal dependency error: > > This package depends on the following classes: > NewList > NewListRenderer > TabActionButton > Tab > TabBar > > Then I proceed and it was loaded fine. And editor works like in demo. > > 2) Text cursor up/down is not working correctly when text is wrapped. > > - it jumps between real text line instead of visual wrapped lines. > > - it skips empty lines > > - sometimes it is just not moved (not found concrete case) > > > 3) I look a bit at text commands (TextEditorCommand) and found that > current KeyMapping package ($a asShortcut) is not used. Instead there is > new hierarchy of BlKeyCombination. > What the reason for this? > > 4) I thing we should try to use Commander for new UI widgets. For example > It is very naturally applied to TextEditorCommand hierarchy. And it will > automatically remove hardcoded shortcuts defined in method > BrTextEditor>>onAttached: > > > > > 2017-08-05 0:19 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> 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. >> >> [image: Playground @ â¢ a8rEditorE1ement x Page â BrRopedText string: >> Emphasizing everything text : nothing' text attributes: { >> BrFontSizeAttribute size: 66 } . text attributes: { BrTextForegroundAttri >> bute paint: ( BILinearGradientPaint new stops: 9 â> Color red . start: end: >> from: 1 to: 11; Color blue} ; attributes: { BrFontWeightAttribute bold } >> from: 12 attributes: { BrFontEmphasisAttribute italic from: emphasi zi ng >> to: 17; 18 to: 22; Raw Preview Live User data Metrics Meta Em hasizing ever >> thin is emphasizing nothing attributes: { BrTextBackgroundAttribute paint: >> Color yellow from: 27 to: 37; attributes: { BrFontWeightAttribute thin. >> BrTextForegroundAttribute paint: Color gray. BrFontSizeAttribute size: 40 >> from: 39 to: 45. element : BrEditorElement new size: 400 @ 600; edi tor: >> (BrTextEdi tor new text: text) .] >> >> 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. 6, 2017

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

by Denis Kudriashov

Good job guys. Here is my feedback: 1) Loading in Pharo 7 signal dependency error: This package depends on the following classes: NewList NewListRenderer TabActionButton Tab TabBar Then I proceed and it was loaded fine. And editor works like in demo. 2) Text cursor up/down is not working correctly when text is wrapped. - it jumps between real text line instead of visual wrapped lines. - it skips empty lines - sometimes it is just not moved (not found concrete case) 3) I look a bit at text commands (TextEditorCommand) and found that current KeyMapping package ($a asShortcut) is not used. Instead there is new hierarchy of BlKeyCombination. What the reason for this? 4) I thing we should try to use Commander for new UI widgets. For example It is very naturally applied to TextEditorCommand hierarchy. And it will automatically remove hardcoded shortcuts defined in method BrTextEditor>>onAttached: 2017-08-05 0:19 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > 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. > > [image: Playground @ â¢ a8rEditorE1ement x Page â BrRopedText string: > Emphasizing everything text : nothing' text attributes: { > BrFontSizeAttribute size: 66 } . text attributes: { BrTextForegroundAttri > bute paint: ( BILinearGradientPaint new stops: 9 â> Color red . start: end: > from: 1 to: 11; Color blue} ; attributes: { BrFontWeightAttribute bold } > from: 12 attributes: { BrFontEmphasisAttribute italic from: emphasi zi ng > to: 17; 18 to: 22; Raw Preview Live User data Metrics Meta Em hasizing ever > thin is emphasizing nothing attributes: { BrTextBackgroundAttribute paint: > Color yellow from: 27 to: 37; attributes: { BrFontWeightAttribute thin. > BrTextForegroundAttribute paint: Color gray. BrFontSizeAttribute size: 40 > from: 39 to: 45. element : BrEditorElement new size: 400 @ 600; edi tor: > (BrTextEdi tor new text: text) .] > > 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. 6, 2017

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

by Guillermo Polito

On Sun, Aug 6, 2017 at 5:46 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> About tagging... It looks super ackward to me to tag EVERY commit with >> "build information". >> > > I'm not sure which comment your responding to, > yours :P. Yes, too early, I did not want to properly quote... > and not sure what you mean by "build information", > In this particular case I mean build number. but obviously someone may do several commits before doing a pull request, > as they work through developing and testing a fix for an Issue. Its only > the successful builds that are uploaded to files.pharo.org that are > important to tag. > But then, why not just going through the files in files.pharo.org and get the corresponding hash from there (since they have the hash they correspond to)? I do not see the practical usecase. It's just redundance, no? > 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". >> > > I'd imagine that tagging a commit as BUILD#X would be done as part of the > CI immediately before the upload to files.pharo.org. > That's what I wanto to avoid. Why is that required? The generated file already has a pointer to the git commit it was generated from. Why do we need the backpointer from git to the build? > > >> 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. >> > > I don't understand why you'd need to iterate git history. > Shouldn't you be able to rebuild an image from a single git commit? > Yes you are. I meant in here that "if you want to rebuild all images from files.pharo.org" you can walk all commits. > > >> No need to store all images. >> > > Do you mean on files.pharo.com? > That might be a good later goal, but for now these resultant images are > useful to work with PharoLauncher without expending effort on redeveloping > that to also rebuild images on the fly. > > Yeah, I did not mean that we have to change it. But we have to keep in mind that before files.pharo.org was used for versioning purposes but in a process where we are bootstrapping from sources, the intermediate generated images are build artifacts and are just a "cache". I know the launcher depends on it right now, but does it make sense that it provides access to every alpha image > Pharo${IMAGE_KIND}-7.0.0-arch.32bit.sha.${HASH}.build.${BUILD_NUMBER}.zip >>> >> > +1 to Torsten's suggestion to put the BUILD_NUMBER first, since it is more > sortable than HASH. > Ok, that's easily doable :) https://github.com/pharo-project/pharo/pull/185/files#diff-bf8112f4242808a7… > By "arch", do you mean Win/Linux/Mac? Or were labelling the bit-ness field? > bitness. Images are portable between operating systems but not between 32&64 bit vms. > Also, is it important to prepend these with the numbers with "build." and > "sha." fieldname strings? This bulks out the name increases the chance some > interface needs to mangle the name to fit into a thin column. > I like that they make the metadata more explicit. Otherwise we will start having strange scripts that have magic numbers here and there. At least like this we can read the file name and identify what is each field. I prefer to pay some extra bytes in filenames... About column names in UIs.... That's a UI problem. I'd not design the filename of our build artifacts because of a UI... > > > While we are discussion version naming (and I ask this from a position of > ignorance) > could you discuss with your team, without insider knowledge, how do we > distinguish between the released 7.0.0 and all the 7.0.0 development builds > heading towards that release? > Can we add something to distinguish the development phase > i.e. alpha/beta/rc/release (which coincidentally sort well with build > numbers.) > > Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-alpha.${BUILD_NUMBER}.${HASH}.zip > Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-beta.${BUILD_NUMBER}.${HASH}.zip > Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-rc.${BUILD_NUMBER}.${HASH}.zip > Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-release.${BUILD_NUMBER}.${HASH}.zip > > beta might be the defined point to ask applications to test-port to the > new version, this perhaps being the optimum point to get fixes into the the > next release. > > or if you don't want to be that sophisticated, maybe just phases dev/rel > I like that. The only thing is that right now what is "alpha" version is managed in the file server as "latest". That will otherwise break zeroconf scripts that depend on that. I'd say every build in development is alpha so far. At some point we will move to beta. Releases and release candidates should be managed explicitly (like there is someone that will decide "this is a release and I'll tag it explicitly like it"). > > or for a more continuous release process, maybe '#' for the patch number... > Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-${BUILD_NUMBER}.${HASH}.zip > (since '#' sorts before '0') > I did not get this one. Guille

Aug. 6, 2017

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

by Ben Coman

On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > About tagging... It looks super ackward to me to tag EVERY commit with > "build information". > I'm not sure which comment your responding to, and not sure what you mean by "build information", but obviously someone may do several commits before doing a pull request, as they work through developing and testing a fix for an Issue. Its only the successful builds that are uploaded to files.pharo.org that are important to tag. > 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". > I'd imagine that tagging a commit as BUILD#X would be done as part of the CI immediately before the upload to files.pharo.org. > 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. > I don't understand why you'd need to iterate git history. Shouldn't you be able to rebuild an image from a single git commit? > No need to store all images. > Do you mean on files.pharo.com? That might be a good later goal, but for now these resultant images are useful to work with PharoLauncher without expending effort on redeveloping that to also rebuild images on the fly. cheers -ben > 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 >> > +1 to Torsten's suggestion to put the BUILD_NUMBER first, since it is more sortable than HASH. By "arch", do you mean Win/Linux/Mac? Or were labelling the bit-ness field? Also, is it important to prepend these with the numbers with "build." and "sha." fieldname strings? This bulks out the name increases the chance some interface needs to mangle the name to fit into a thin column. While we are discussion version naming (and I ask this from a position of ignorance) could you discuss with your team, without insider knowledge, how do we distinguish between the released 7.0.0 and all the 7.0.0 development builds heading towards that release? Can we add something to distinguish the development phase i.e. alpha/beta/rc/release (which coincidentally sort well with build numbers.) Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-alpha.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-beta.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-rc.${BUILD_NUMBER}.${HASH}.zip Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-release.${BUILD_NUMBER}.${HASH}.zip beta might be the defined point to ask applications to test-port to the new version, this perhaps being the optimum point to get fixes into the the next release. or if you don't want to be that sophisticated, maybe just phases dev/rel or for a more continuous release process, maybe '#' for the patch number... Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-${BUILD_NUMBER}.${HASH}.zip (since '#' sorts before '0') cheers -ben > >> 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. >>>> >>>

Aug. 6, 2017

Re: [Pharo-dev] About cr and lf

by Peter Uhnak

Hi, that's why one of the proposals was to configure the stream to either use always specific line endings stream beForWindows. stream newLine. "outputs CRLF irrespective of where the image is currently running" and stream beForCurrentPlatform. stream newLine. "returns whatever it is currently running on" Peter On Sun, Aug 06, 2017 at 11:47:26AM +0200, Thierry Goubier wrote: > Hi Stef, all, > > I'd like to point out that, during the life of an image (prepared on > windows, then used on Linux, then on Mac), the meaning of a new line changes > -> should then all 'newLines' done on streams while on windows be changed > when the image restart on Linux? > > My take would be: > > - Set a convention internal to Pharo (#cr is then fine for me) > - provide an easy and simple "convert to current os convention" > > I'd suspect, Stef, that your #newLine will end up being a mess for > multi-platform apps (and force multi-platform apps to add code to determine > on which platform a stream was written to to be able to reconvert it back) > > Regards, > > Thierry > > > Le 06/08/2017 Ã 10:54, Stephane Ducasse a Ã©crit : > >Agreed :) > > > >But so far what do we do? > > > > > >- #cr and #lf just put this character in the stream. > >- #newLine put the underlying OS line ending. > > > >Then we should revisit all the cr inside the system and use newline. > >Then we should think about the internal usage of cr by default in > >Pharo (We should change it). > > > >Does it make sense? > >Stef > > > >Stef > > > >On Sun, Aug 6, 2017 at 10:36 AM, Sven Van Caekenberghe <sven(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] Having green builds

by Gabriel Cotelli

Great guys, this is the way to go. On Sun, Aug 6, 2017 at 6: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 >

Aug. 6, 2017

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

by Torsten Bergmann

Aug. 6, 2017

Re: [Pharo-dev] About cr and lf

by Guillermo Polito

On Sun, Aug 6, 2017 at 11:47 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Stef, all, > > I'd like to point out that, during the life of an image (prepared on > windows, then used on Linux, then on Mac), the meaning of a new line > changes -> should then all 'newLines' done on streams while on windows be > changed when the image restart on Linux? > > My take would be: > > - Set a convention internal to Pharo (#cr is then fine for me) > - provide an easy and simple "convert to current os convention" > But the problem is that convention clashes with another convention: cr is an ascii character and is not portable. So either we have a confusing API (is this cr going to write a cr or a platform independent newline sequence of characters?) or we have a clear one with a new message that does the magic. We can then also provide some magic that transforms cr's into newlines automatically. But I want to decouple "weird magic for backwards compatibility" from "the nice and clean library below" :). > > I'd suspect, Stef, that your #newLine will end up being a mess for > multi-platform apps (and force multi-platform apps to add code to determine > on which platform a stream was written to to be able to reconvert it back) > But that is the case with the current implementation. We only want to make it explicit. Right now: - MultiByteFileStream & friends guess the line ending convention in the platform (I'd not guarantee that this works ok all the time) - when you write a cr, iff you're writing to a file, it will transform it to the line ending that corresponds The only thing is that this implementation - is complex - is implicit (maybe you wanted to really write a cr and you end up writing an lf?) But otherwise it shares the weaknesses you're pointing out. We are only saying that: - we should split the cr conversion into a decorator object to have a cleaner API - we should make it explicit and thus less confusing using a message #newline instead of a #cr that is magically converted > > Regards, > > Thierry > > > > Le 06/08/2017 Ã 10:54, Stephane Ducasse a Ã©crit : > >> Agreed :) >> >> But so far what do we do? >> >> >> - #cr and #lf just put this character in the stream. >> - #newLine put the underlying OS line ending. >> >> Then we should revisit all the cr inside the system and use newline. >> Then we should think about the internal usage of cr by default in >> Pharo (We should change it). >> >> Does it make sense? >> Stef >> >> Stef >> >> On Sun, Aug 6, 2017 at 10:36 AM, Sven Van Caekenberghe <sven(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

Re: [Pharo-dev] About cr and lf

by Thierry Goubier

Hi Stef, all, I'd like to point out that, during the life of an image (prepared on windows, then used on Linux, then on Mac), the meaning of a new line changes -> should then all 'newLines' done on streams while on windows be changed when the image restart on Linux? My take would be: - Set a convention internal to Pharo (#cr is then fine for me) - provide an easy and simple "convert to current os convention" I'd suspect, Stef, that your #newLine will end up being a mess for multi-platform apps (and force multi-platform apps to add code to determine on which platform a stream was written to to be able to reconvert it back) Regards, Thierry Le 06/08/2017 Ã 10:54, Stephane Ducasse a Ã©crit : > Agreed :) > > But so far what do we do? > > > - #cr and #lf just put this character in the stream. > - #newLine put the underlying OS line ending. > > Then we should revisit all the cr inside the system and use newline. > Then we should think about the internal usage of cr by default in > Pharo (We should change it). > > Does it make sense? > Stef > > Stef > > On Sun, Aug 6, 2017 at 10:36 AM, Sven Van Caekenberghe <sven(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] Having green builds

by Pavel Krivanek

Great job! Thank you very much. -- Pavel 2017-08-06 11:00 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > 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> >

Aug. 6, 2017