June 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #310: 3410-[Trait] Impossible to use from a classTrait a method that is also defined in a subclass of Behavior even when following the doc

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #310 was: FAILURE. The Pull Request #3426 was integrated: "3410-[Trait] Impossible to use from a classTrait a method that is also defined in a subclass of Behavior even when following the doc" Pull request url: https://github.com/pharo-project/pharo/pull/3426 Issue Url: https://github.com/pharo-project/pharo/issues/3410 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 4, 2019

[Pharo 8.0] Build #309: Adding the execution of the benchmark job.

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #309 was: SUCCESS. The Pull Request #3423 was integrated: "Adding the execution of the benchmark job." Pull request url: https://github.com/pharo-project/pharo/pull/3423 Issue Url: https://github.com/pharo-project/pharo/issues/automating Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 4, 2019

Zinc-FileSystem-SvenVanCaekenberghe.20.mcz Empty .st

by lpaniceres

I'm experiencing a problem with tha package Zinc-FileSystem-SvenVanCaekenberghe, MOnticello downloas the file Zinc-FileSystem-SvenVanCaekenberghe.20.mcz with an empty source.st. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 4, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by Dale Henrichs

Haha, I agree! Dale On 6/3/19 11:06 AM, ducasse wrote: > We will make it :) > > Stef > >> This is our goal as well... >> >> Dale >> >> On 6/1/19 6:37 AM, ducasse wrote: >>> My goal is to have the best environment possible and Iâm working to make it. >>> My goal is not to have a smalltalk system compatible with the rest of the universe. >>> Now since people deploy on Gemstone we will pay attention to them and ideally I would love to have the ressources to make Pharo fully execute >>> with compiler and other on top of GS VM. > >

June 3, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by ducasse

We will make it :) Stef > This is our goal as well... > > Dale > > On 6/1/19 6:37 AM, ducasse wrote: >> My goal is to have the best environment possible and Iâm working to make it. >> My goal is not to have a smalltalk system compatible with the rest of the universe. >> Now since people deploy on Gemstone we will pay attention to them and ideally I would love to have the ressources to make Pharo fully execute >> with compiler and other on top of GS VM. >

June 3, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by Dale Henrichs

This is our goal as well... Dale On 6/1/19 6:37 AM, ducasse wrote: > My goal is to have the best environment possible and Iâm working to > make it. > My goal is not to have a smalltalk system compatible with the rest of > the universe. > Now since people deploy on Gemstone we will pay attention to them and > ideally I would love to have the ressources to make Pharo fully execute > with compiler and other on top of GS VM.

June 3, 2019

Re: [Pharo-dev] Default line endings while writing to a file stream

by ducasse

I understand your point now this is about letting the guy specifying the line ending and this is really frequent. >> Iâd even propose to have it by default: a FileReference writeStream can return a ZnNewLineWriterStream wrapping the corresponding stream. >> By default it can be configured with the systemâs default line ending convention (least surprise?). >> And then users can change it accordinglyâ¦ >> >> Now I ask also myself what we could do when reading line endings from a file. >> Iâm 98.761% convinced that in the image we should have a single line ending convention for strings, and that we should convert internal strings to the external representation of convenience explicitly. >> In this direction we could make that default read streams in FileSystem to automatically transform external line endings into internal line endings. > > Maybe, maybe. > > It would still create the assumption that the standard stream has lots of functionality that you can automatically count on. Then it feels that we are back to where we started. > > The goal was to simplify, with simple, compose-able functionality. > > I know that the implementation would still be more or less modular, but many layers also carry a performance price. > > I feel like I am fighting a losing battle trying to simplify and clean up the stream API. > > The fact that we cannot use Traits is another problem, because inheritance does not cut it. See the old NILE project.

June 3, 2019

Re: [Pharo-dev] Default line endings while writing to a file stream

by Sven Van Caekenberghe

> On 2 Jun 2019, at 21:24, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > >> El 2 jun 2019, a las 20:45, ducasse <stepharo(a)netcourrier.com> escribiÃ³: >> >> Sven >> >> why not having this as extension. > > Iâd even propose to have it by default: a FileReference writeStream can return a ZnNewLineWriterStream wrapping the corresponding stream. > By default it can be configured with the systemâs default line ending convention (least surprise?). > And then users can change it accordinglyâ¦ > > Now I ask also myself what we could do when reading line endings from a file. > Iâm 98.761% convinced that in the image we should have a single line ending convention for strings, and that we should convert internal strings to the external representation of convenience explicitly. > In this direction we could make that default read streams in FileSystem to automatically transform external line endings into internal line endings. Maybe, maybe. It would still create the assumption that the standard stream has lots of functionality that you can automatically count on. Then it feels that we are back to where we started. The goal was to simplify, with simple, compose-able functionality. I know that the implementation would still be more or less modular, but many layers also carry a performance price. I feel like I am fighting a losing battle trying to simplify and clean up the stream API. The fact that we cannot use Traits is another problem, because inheritance does not cut it. See the old NILE project. >> Stef >> >> >>> On 2 Jun 2019, at 13:52, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> Hi Ben, >>> >>> On Fri, 31 May 2019 at 07:08, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> >>>> I'm on Windows wanting to write a text file with LF endings. >>>> The code developed on Linux is thus... >>>> (destinationDirectory / 'README.md') ensureCreateFile >>>> writeStreamDo: [ :stream | stream nextPutAll: class comment ] >>> >>> I've come across this so many times that I always add a couple of >>> methods to my image: >>> >>> ZnEncodedStream>>asNewLineStream >>> "Answer the receiver wrapped with a ZnNewLineWriterStream" >>> ^ZnNewLineWriterStream on: self! ! >>> >>> >>> ZnNewLineWriterStream>>asNewLineStream >>> "Answer the receiver wrapped with a ZnNewLineWriterStream" >>> ^self! ! >>> >>> >>> You could then modify the example above to be: >>> >>> stream asNewLineStream forLf nextPutAll: class comment >>> >>> Cheers, >>> Alistair >>> >>> >>> >>>> and I am stuck with CR line endings. >>>> The specific symptom is that it screws `git diff` >>>> Here is a simple experiment... >>>> testfile := 'README.md' asFileReference. >>>> testfile ensureCreateFile writeStreamDo: [ :stream | >>>> stream nextPutAll: 'aa >>>> bb' ]. >>>> testfile binaryReadStream contents at: 3 "==> Character cr " >>>> >>>> I think its safe to assume on Linux that will result in "==> Character lf " >>>> but can someone please confirm? >>>> >>>> So my issue is that I've got >>>> #ensureCreateFile - returns a FileReference >>>> and >>>> :stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream wrapping BinaryFileStream. >>>> >>>> and neither seem to have an easily accessible defaultLineEnding setting. >>>> Indeed, line endings are not a property of FileReference >>>> and Binary & Characters have nothing to do with line endings, >>>> and questionable if Buffering is related. >>>> >>>> Its more a property of a File, but IIUC that is being deprecated (??) >>>> >>>> MultiByteFileStream has #lineEndConvention: >>>> but IIUC that also is being deprecated. >>>> >>>> So what is the proper way to force default line endings? >>>> >>>> >>>> ------ >>>> Now while composing this email I discovered String>>withUnixLineEndings. >>>> So I have a solution... >>>> testfile := 'README.md' asFileReference. >>>> testfile ensureCreateFile writeStreamDo: [ :stream | >>>> stream nextPutAll: 'aa >>>> bb' withUnixLineEndings ]. >>>> (testfile binaryReadStream contents at: 3) asCharacter "==> Character lf " >>>> >>>> but that seems to imply that on Windows... >>>> 'aa >>>> bb' at: 3 "==> Character cr " >>>> >>>> and on Linux (someone please confirm)... >>>> 'aa >>>> bb' at: 3 "==> Character lf " >>>> >>>> and that is *very* curious. Strange that I never noticed it before and obviously that hasn't hurt me, >>>> but considering the Principal Of Least Surprise it leaves me feeling somewhat violated :) >>> >> >> >> > >

June 3, 2019

Re: [Pharo-dev] Default line endings while writing to a file stream

by Sven Van Caekenberghe

Yes, maybe. These kind of convenience messages are cool, but it feels that many would be needed, and together they will form a heavy protocol by themselves, making it harder to implement a new stream from scratch. > On 2 Jun 2019, at 20:45, ducasse <stepharo(a)netcourrier.com> wrote: > > Sven > > why not having this as extension. > > Stef > > >> On 2 Jun 2019, at 13:52, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Ben, >> >> On Fri, 31 May 2019 at 07:08, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> >>> I'm on Windows wanting to write a text file with LF endings. >>> The code developed on Linux is thus... >>> (destinationDirectory / 'README.md') ensureCreateFile >>> writeStreamDo: [ :stream | stream nextPutAll: class comment ] >> >> I've come across this so many times that I always add a couple of >> methods to my image: >> >> ZnEncodedStream>>asNewLineStream >> "Answer the receiver wrapped with a ZnNewLineWriterStream" >> ^ZnNewLineWriterStream on: self! ! >> >> >> ZnNewLineWriterStream>>asNewLineStream >> "Answer the receiver wrapped with a ZnNewLineWriterStream" >> ^self! ! >> >> >> You could then modify the example above to be: >> >> stream asNewLineStream forLf nextPutAll: class comment >> >> Cheers, >> Alistair >> >> >> >>> and I am stuck with CR line endings. >>> The specific symptom is that it screws `git diff` >>> Here is a simple experiment... >>> testfile := 'README.md' asFileReference. >>> testfile ensureCreateFile writeStreamDo: [ :stream | >>> stream nextPutAll: 'aa >>> bb' ]. >>> testfile binaryReadStream contents at: 3 "==> Character cr " >>> >>> I think its safe to assume on Linux that will result in "==> Character lf " >>> but can someone please confirm? >>> >>> So my issue is that I've got >>> #ensureCreateFile - returns a FileReference >>> and >>> :stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream wrapping BinaryFileStream. >>> >>> and neither seem to have an easily accessible defaultLineEnding setting. >>> Indeed, line endings are not a property of FileReference >>> and Binary & Characters have nothing to do with line endings, >>> and questionable if Buffering is related. >>> >>> Its more a property of a File, but IIUC that is being deprecated (??) >>> >>> MultiByteFileStream has #lineEndConvention: >>> but IIUC that also is being deprecated. >>> >>> So what is the proper way to force default line endings? >>> >>> >>> ------ >>> Now while composing this email I discovered String>>withUnixLineEndings. >>> So I have a solution... >>> testfile := 'README.md' asFileReference. >>> testfile ensureCreateFile writeStreamDo: [ :stream | >>> stream nextPutAll: 'aa >>> bb' withUnixLineEndings ]. >>> (testfile binaryReadStream contents at: 3) asCharacter "==> Character lf " >>> >>> but that seems to imply that on Windows... >>> 'aa >>> bb' at: 3 "==> Character cr " >>> >>> and on Linux (someone please confirm)... >>> 'aa >>> bb' at: 3 "==> Character lf " >>> >>> and that is *very* curious. Strange that I never noticed it before and obviously that hasn't hurt me, >>> but considering the Principal Of Least Surprise it leaves me feeling somewhat violated :) >> > > >

June 3, 2019

OSProcess and CommandShell available on GitHub for Pharo users

by David T. Lewis

Alistair Grant and I, with the support of Feenk, have made GitHub repositories for OSProcess and CommandShell at: https://github.com/dtlewis290/OSProcess-Tonel https://github.com/dtlewis290/CommandShell-Tonel Alistair did the conversions using Peter Uhn??k's migration tool, and I set up the repositories so that they can now be loading in Pharo as follows: Metacello new repository: 'github://dtlewis290/OSProcess-Tonel/src'; baseline: 'OSProcess'; load. Metacello new repository: 'github://dtlewis290/CommandShell-Tonel/src'; baseline: 'CommandShell'; load. Note, the two respositories are named *-Tonel because I also maintain a GitHub repository for OSProcess on Cuis, and will probably do repositories in Squot format in the future. @Thierry Goubier - If you have an account on GitHub I will add you as a collaborator (but my own development work remains on squeaksource so I prefer contributions there anyway). Enjoy, Dave and Alistair

June 3, 2019