March 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #708: 21629-Fix-inspect-MetaLink

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

There is a new Pharo build available! The status of the build #708 was: SUCCESS. The Pull Request #1139 was integrated: "21629-Fix-inspect-MetaLink" Pull request url: https://github.com/pharo-project/pharo/pull/1139 Issue Url: https://pharo.fogbugz.com/f/cases/21629 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 20, 2018

[Pharo 7.0-dev] Build #707: 21626-remove-localClassMethod-pragma-unused

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

There is a new Pharo build available! The status of the build #707 was: SUCCESS. The Pull Request #1136 was integrated: "21626-remove-localClassMethod-pragma-unused" Pull request url: https://github.com/pharo-project/pharo/pull/1136 Issue Url: https://pharo.fogbugz.com/f/cases/21626 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 20, 2018

[Pharo 7.0-dev] Build #706: 21617-Better-implementation-of-package-comments

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

There is a new Pharo build available! The status of the build #706 was: SUCCESS. The Pull Request #1131 was integrated: "21617-Better-implementation-of-package-comments" Pull request url: https://github.com/pharo-project/pharo/pull/1131 Issue Url: https://pharo.fogbugz.com/f/cases/21617 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 20, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #705: 21618-Saving-code-as-file-tree-is-broken

by Marcus Denker

The build was hanging since 14 hours on windowsâ¦ I killed it. Lets see if the next one works better > On 20 Mar 2018, at 10:41, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #705 was: FAILURE. > > The Pull Request #1132 was integrated: "21618-Saving-code-as-file-tree-is-broken" > Pull request url: https://github.com/pharo-project/pharo/pull/1132 > > Issue Url: https://pharo.fogbugz.com/f/cases/21618 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 20, 2018

[Pharo 7.0-dev] Build #705: 21618-Saving-code-as-file-tree-is-broken

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

There is a new Pharo build available! The status of the build #705 was: FAILURE. The Pull Request #1132 was integrated: "21618-Saving-code-as-file-tree-is-broken" Pull request url: https://github.com/pharo-project/pharo/pull/1132 Issue Url: https://pharo.fogbugz.com/f/cases/21618 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 20, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by CÃ©drick BÃ©ler

> > > >> On 16 Mar 2018, at 16:41, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> but thing is: default download should be the launcher. >> because this is the ânewbie-friendlyâ approach. >> >> All the rest can be in under a link (or a subtitle, doesnât matters). > > It think that even that is a mistake: To give ânewbiesâ a different download > than the âpeople that know better" is *wrong*. > > Marcus What about having normal/advance mode to shore more or less images ? Official bistro + documentation/book images ? Then the whole stuff. Cheers, CÃ©drick

March 20, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by CÃ©drick BÃ©ler

CLI is cool too but it quickly becomes a mess for me ^^ Just loving the launcher on the Macâ¦ +100 for me to push it. Still, the CLI should be available and probably the better way to launch one specific image. My 2 cents, CÃ©drick

March 20, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Guillermo Polito

If the launcher had a command line interface, I'd use it all the time :) On Tue, Mar 20, 2018 at 10:15 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > > I'm really glad PharoLauncher has been promoted to the download page, > but it seems some people want to push PharoLauncher to *be* Pharo. > To me this seems a poor strategy. > > The README file in the PharoLauncher zip downloads says... > "Pharo 1.1-2018.01.16 This distribution was built January 16, 2018." > > This seems strange to me and highly likely to confuse newcomers. > Pharo 1.1 more than a few years old. How can something built in 2018 be > named "Pharo 1.1" ? > > And if PharoLauncher is instead published as Pharo 7, then it seems > strange to use it to run Pharo 5 images and later Pharo 8 images. > Why not have the Downloads page just say "The recommended way to manage > Pharo downloads is with PharoLauncher" > and allow PharoLauncher to exist as a separate entity. This would be > similar similar to those applications where you download > an initial 500kB installer, which then grabs the other 100MB from the net > to complete the install. > > Also, when maybe one day we can use Pharo as a command line shell, how > will that relate to PharoLauncher being presented "as" Pharo. > > > > What is clear is that people use many images anyway. And the more machines > get bigger, this will happen even more. > > So any download can only be âthe VM + a Template imageâ. > => when you just start âPharoâ it starts the template (read only) > => drag an image (or double click) -> opens that image. > > To make that work for real we would need to have one release per version > (Pharo6, Pharo7, Pharo8) that you installâ¦ > > The launcher is a similar scheme that I think could be even better, it > adds: > > - easy find images online > - manage your images (you do not need to use it, you can just use the UI > of your OS instead, too). > - manage VMs in addition. > - which means that it is just one download that people need to install to > be able to run all old images, too. > > So I think if can be quite niceâ¦ it needs some iterations > > - simplify the UI so people know what todo when they see it the first time > - make sure it works everywhere > - Sign it so installation is easier > - We need something that the images that end up on disk do not have the > bit set that make drag-n-drop fail. > - integrate command line: There should be a menu to write scripts to > /usr/local/bin to run pharo images easily > - Longterm: we need 1-file imagesâ¦ a container that has the image itself + > auxiliary stuff on âdiskâ but that is one file. > > So for me this is a bit like docker: to use docker, you install docker on > the mac. There is one way, it works. > > Marcus > > > > > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 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

March 20, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Marcus Denker

Hi, > > I'm really glad PharoLauncher has been promoted to the download page, > but it seems some people want to push PharoLauncher to *be* Pharo. > To me this seems a poor strategy. > > The README file in the PharoLauncher zip downloads says... > "Pharo 1.1-2018.01.16 This distribution was built January 16, 2018." > > This seems strange to me and highly likely to confuse newcomers. > Pharo 1.1 more than a few years old. How can something built in 2018 be named "Pharo 1.1" ? > > And if PharoLauncher is instead published as Pharo 7, then it seems strange to use it to run Pharo 5 images and later Pharo 8 images. > Why not have the Downloads page just say "The recommended way to manage Pharo downloads is with PharoLauncher" > and allow PharoLauncher to exist as a separate entity. This would be similar similar to those applications where you download > an initial 500kB installer, which then grabs the other 100MB from the net to complete the install. > > Also, when maybe one day we can use Pharo as a command line shell, how will that relate to PharoLauncher being presented "as" Pharo. > > What is clear is that people use many images anyway. And the more machines get bigger, this will happen even more. So any download can only be âthe VM + a Template imageâ. => when you just start âPharoâ it starts the template (read only) => drag an image (or double click) -> opens that image. To make that work for real we would need to have one release per version (Pharo6, Pharo7, Pharo8) that you installâ¦ The launcher is a similar scheme that I think could be even better, it adds: - easy find images online - manage your images (you do not need to use it, you can just use the UI of your OS instead, too). - manage VMs in addition. - which means that it is just one download that people need to install to be able to run all old images, too. So I think if can be quite niceâ¦ it needs some iterations - simplify the UI so people know what todo when they see it the first time - make sure it works everywhere - Sign it so installation is easier - We need something that the images that end up on disk do not have the bit set that make drag-n-drop fail. - integrate command line: There should be a menu to write scripts to /usr/local/bin to run pharo images easily - Longterm: we need 1-file imagesâ¦ a container that has the image itself + auxiliary stuff on âdiskâ but that is one file. So for me this is a bit like docker: to use docker, you install docker on the mac. There is one way, it works. Marcus

March 20, 2018

Re: [Pharo-dev] New Files in Pharo - Migration Guide, How To's and examples

by Guillermo Polito

Yes, it would be good to have those kind of methods. But there are some other constraints to have into account :) - introducing these without introducing duplications is right now complicated because streams do not share a hierarchy - having a common hierarchy is maybe complicated: ZnStreams should for the moment be backwards compatible with Pharo>4? - using traits to avoid duplications would be good, but for now traits are forbidden from kernel packages (otherwise we need to add traits in the kernel, + trait support in the class builder, runtime,... and the image will grow MBs and the build time will grow too) About the naming, I'm for - #buffered / #bufferedWithBufferSize: size - #encoded / #utf8Encoded / #encodedAs: encoding - #usingCr / #usingLf / #usingCrLf / #usingPlatformLineEndingConvention / #usingLineConvention: aConvention On Mon, Mar 19, 2018 at 9:53 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2018-03-19 17:42 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > > 2018-03-19 21:21 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> > >> 2018-03-19 20:39 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > >>> > >>> 2018-03-19 16:32 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > >>> > aStream buffered. > >>> I'd only change this one, to #beBuffered. > > >> But #be sounds like it modifies receiver. > >> But idea is same as #reversed or #sorted for collections. > > -1 for beBuffered, it's not about adding states to the stream. > > As Denis said, it's a transform producing a new stream. > > > I didn't understand it was returning a transformed instance, I > actually thought it was the opposite, so if that is the case then > Denis' suggested selectors are fine. > > Thanks for the clarification. > > Esteban A. Maringolo > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 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

March 20, 2018