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

Re: [Pharo-dev] Do we kill the catalog?

by Stephane Ducasse

> > That's why I try to do with PI https://github.com/hernanmd/pi > > It's 100% command-line, which I know smalltalkers don't love. do not draw conclusions like that. > However after working with Python, R, Perl, etc. I saw the world > expects a pretty standard package installation pattern. > I feel (outsider) people really don't care if there is a Catalog, > StHub, PepeHub. This is not for the others this is for US. And We plan to have a command line interface for the launcher and also for pakbot. > > Please everyone feel free to fork and add/fix anything you need from PI. > > Hernan > >> @Peter no cargo is not dead now christophe cannot fix all the time the >> PharoLauncher and make progress >> on Cargo -> Pakbot >> And yes I really want to have something that we can use soon. >> >> - Needed immediate actions: >> -- support baselineOf >> -- how could we make sure that we can publish in multiple repo? (After >> this is just a copy so I click on the package >> and say copy to). >> >> What else. >> @thierry the story I do not use the catalog because the icons are not >> understandable is not really good to me. >> >> >> Stef >> >> >> On Thu, Apr 19, 2018 at 8:46 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> why to kill it? >>> right now we do not have a replacement. >>> >>> Esteban >>> >>>> On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> >>>> Hi guys >>>> >>>> What do we do with it? >>>> What alternatives? >>>> >>>> Stef >>>> >>> >>> >> >

April 20, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Esteban A. Maringolo

On 20/04/2018 14:42, HernÃ¡n Morales Durand wrote: > Hi Stef, >> Do you think that editing STON is easier than a class? I think that we >> should have a button. >> Look people do not care about posting their project into the repo. >> May be we need a crawler? > That's why I try to do with PI https://github.com/hernanmd/pi > > It's 100% command-line, which I know smalltalkers don't love. > > However after working with Python, R, Perl, etc. I saw the world > expects a pretty standard package installation pattern. +1 > I feel (outsider) people really don't care if there is a Catalog, > StHub, PepeHub. We have the right (and probably the reasons) to do things "our way", but it shouldn't surprise us if outsiders and newcomers reject that way because it feels weird, even if is better than what they're used to. Regards, -- Esteban A. Maringolo

April 20, 2018

Re: [Pharo-dev] Do we kill the catalog?

by HernÃ¡n Morales Durand

Hi Stef, 2018-04-20 7:09 GMT+00:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > The underlying questions (sorry for people that need subtitles) are: > > - how do we have a central place to declare projects > - right now in Smalltalkhub/list is a nice way to find projects > with the move to github > we should get a central place > > Christophe has been working on project repository and we should check > what he has. > @Christophe? > > - how do we make sure that we can validated (I can load this version > of XMLParser in that version of Pharo) > -- in this version of Pharo what is the latest working version of this package > > - if people do not maintain/add "configuration" into the catalog what > is the point? > -- How can we ease the participation to the catalog? Esteban I do not > care about the format. > Do you think that editing STON is easier than a class? I think that we > should have a button. > Look people do not care about posting their project into the repo. > May be we need a crawler? > > That's why I try to do with PI https://github.com/hernanmd/pi It's 100% command-line, which I know smalltalkers don't love. However after working with Python, R, Perl, etc. I saw the world expects a pretty standard package installation pattern. I feel (outsider) people really don't care if there is a Catalog, StHub, PepeHub. Please everyone feel free to fork and add/fix anything you need from PI. Hernan > @Peter no cargo is not dead now christophe cannot fix all the time the > PharoLauncher and make progress > on Cargo -> Pakbot > And yes I really want to have something that we can use soon. > > - Needed immediate actions: > -- support baselineOf > -- how could we make sure that we can publish in multiple repo? (After > this is just a copy so I click on the package > and say copy to). > > What else. > @thierry the story I do not use the catalog because the icons are not > understandable is not really good to me. > > > Stef > > > On Thu, Apr 19, 2018 at 8:46 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> why to kill it? >> right now we do not have a replacement. >> >> Esteban >> >>> On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> Hi guys >>> >>> What do we do with it? >>> What alternatives? >>> >>> Stef >>> >> >> >

April 20, 2018

Re: [Pharo-dev] File/Stream changes: one Integer decoder/encoder to rule them all

by Stephane Ducasse

I should that I love twice the title of your email. - yes if we can have one good instead of multiple not so good. This is wonderful. Now I'm not expert in that and brain dead after car, flight, rer, metro, train to get back home On Fri, Apr 20, 2018 at 5:24 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > After the File and Stream changes in Pharo 7, a binary read, resp. write stream from/to a file is actually a ZnBuffered(Read|Write)Stream on a BinaryFileStream. You access these using #binary(Read|Write)Stream[Do:] sent to a FileReference. > > As minimal streams the API of ZnBuffered(Read|Write)Stream was different from what existed before. > > Specifically, a number of Integer decoding/encoding methods were missing. It is probably best to add those (an alternative would be a subclass). > > When I looked at what was available, I thought I could improve upon the current situation. In fact, I think all existing ones can be written in terms of just one key method, one for reading and one for writing. The existing methods than become simple aliases, all while offering more functionality. > > (Incidentally this would be an ideal use of a Trait, can we use them again/still ?) > > The key method is #nextIntegerOfSize: numberOfBytes signed: signed bigEndian: bigEndian [put: value] and can be found in the latest version of Zinc-CharacterEncoding-Core with a comprehensive set of unit tests. > > For example, > > int32 > ^ self nextIntegerOfSize: 4 signed: true bigEndian: true > > nextWord > ^ self nextIntegerOfSize: 2 signed: false bigEndian: true > > or non-aliases ones like > > binaryStream nextIntegerOfSize: 3 signed: true bigEndian: false > > I think I nailed it, but I would love a second pair of eyes to check what I did. > > The same functionality could be added to ByteArray in a slight variation (with offsets), where similar integer encoding/decoding methods exist. > > Sven

April 20, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Stephane Ducasse

On Fri, Apr 20, 2018 at 7:28 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> Cargo is orthogonal to the need of a centralised repository. >> >> Yes, its idea is to provide oneâ¦ but we will need a central repo, always. > > > Yes, but it already has STON manfiests to define the projects > (project-metadata.ston). So why not use/extend the same file. +1 > > Peter > > > On Fri, Apr 20, 2018 at 7:23 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Thierry >> >> May be you are nervous these days. But try to relax and get a positive >> mindset. >> This is not perfect but it is there. You know that we are all full and >> even more. >> So just criticizing is not productive. >> >> >> > One of the issues I have with the Catalog is that it made a mess of the >> > various MetaRrepo for Pharo... Showing in the end that the single place >> > one >> > should put a ConfigurationOf for Pharo is the squeak meta repo. >> >> If you find that funny it is not. >> The point of having multiple repo was to make sure that contrary to >> the old squeak experience >> projects would load. >> >> >> > That in addition the Catalog doesn't even use the best package >> > management we >> > have at a given point is just salt rubbed in the wound. >> >> >> I do not get what you mean but do not reply. >> I do not think that it will be interested. You are in a ranting mode >> and it deos not help. >> >> >> >> > >> > As you wish. I know it belongs to one of these GUIs where I have to >> > spend 10 >> > minutes to try to remember what the icons mean. But that's just me. >> >> Come on. There are fly by help >> >> > The key point to me is that the Catalog should reduce the friction it >> > creates, not that the Catalog has to be a perfect solution. >> > >> > For example, do user-stories on it: how do one publish and updates a >> > project >> > on the Catalog? What has one to do in CI to ensure a project is >> > validated >> > ... Can the catalog just takes care of that part, if the project has a >> > correct setup (project has tests visible in the configurationOf, catalog >> > does the CI stuff of testing it upon each new release of Pharo, even >> > stable >> > because Iceberg breaks stuff when updated in Pharo 6.1, for example). >> > Tags >> > for Pharo versions are only granted if project has been tested on CI by >> > the >> > Catalog for the current version image you're in, for example. >> >> I have a long todo list too. We just did not get the resources for it. >> Let us face it. >> >> >> > We know how to explore and manipulate project specs already; look into >> > the >> > GT tools for the code, and I also use a variant in my AltBrowser when I >> > sort >> > all packages under the configuration or baseline they are specified in. >> > >> > In short, make it so that the Catalog is low friction and bring value to >> > both project maintainers and users. >> > >> > Thierry >> > >> > >> >> >> >> Stef >> >> >> >> >> >> On Thu, Apr 19, 2018 at 8:46 AM, Esteban Lorenzano >> >> <estebanlm(a)gmail.com> >> >> wrote: >> >>> >> >>> why to kill it? >> >>> right now we do not have a replacement. >> >>> >> >>> Esteban >> >>> >> >>>> On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self(a)gmail.com> >> >>>> wrote: >> >>>> >> >>>> Hi guys >> >>>> >> >>>> What do we do with it? >> >>>> What alternatives? >> >>>> >> >>>> Stef >> >>>> >> >>> >> >>> >> >> >> >> >> > >> > >> >

April 20, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Stephane Ducasse

So what are the key "immediate" action to improve the situation - Support for Baseline (no idea what it means) - Use Metacello API. Metacello new repository: 'zzz' configurationOf: 'XXX' loadVersion: #'YYY' - What else? Stef On Fri, Apr 20, 2018 at 7:27 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi guille > > should we open an issue and update the catalog? > > Stef > > On Fri, Apr 20, 2018 at 3:53 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi all, >> >> IMHO, the problem is not metacello or gofer but the fact that the catalog >> uses the old Metacello API: i.e., >> >> Gofer new >> repository: 'zzz'; >> configurationOf: 'XXX'; >> load. >> (ConfigurationOfXXX project version: #YYY) load >> >> instead of the *new* Metacello API >> >> Metacello new >> repository: 'zzz' >> configurationOf: 'XXX' >> loadVersion: #'YYY' >> >> >> >> On Fri, Apr 20, 2018 at 3:34 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >>> >>> >>> > On 20 Apr 2018, at 12:42, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> >>> wrote: >>> > >>> > Le 20/04/2018 Ã 11:44, Esteban Lorenzano a Ã©crit : >>> >> >>> >> >>> >>> On 20 Apr 2018, at 11:01, Thierry Goubier <thierry.goubier(a)gmail.com >>> >>> <mailto:thierry.goubier@gmail.com>> wrote: >>> >>> >>> >>> Le 20/04/2018 Ã 09:09, Stephane Ducasse a Ã©crit : >>> >>>> The underlying questions (sorry for people that need subtitles) are: >>> >>>> - how do we have a central place to declare projects >>> >>>> - right now in Smalltalkhub/list is a nice way to find projects >>> >>>> with the move to github >>> >>>> we should get a central place >>> >>> >>> >>> One of the issues I have with the Catalog is that it made a mess of >>> >>> the various MetaRrepo for Pharo... Showing in the end that the single >>> >>> place one should put a ConfigurationOf for Pharo is the squeak meta >>> repo. >>> >> >>> >> not really. >>> >> if you put your project in the squeak meta repo it will not even be >>> >> listed (is old stuff and we are not listing those). >>> >> >>> >> the idea was to add a project in its corresponding development repo. >>> But >>> >> is an uncomfortable way, yes (and it was a patch, not meant to last) >>> >> >>> >>> That in addition the Catalog doesn't even use the best package >>> >>> management we have at a given point is just salt rubbed in the wound. >>> >> >>> >> thatâs a one method change. Instead: >>> >> >>> >> loadConfiguration >>> >> Gofer it >>> >> url: self repositoryUrl; >>> >> configurationOf: self name; >>> >> load >>> >> >>> >> loadConfiguration >>> >> Metacello new >>> >> repository: self repositoryUrl; >>> >> configuration: self name; >>> >> load. >>> >> >>> >> when I made catalog, Metacello usage was not so expanded. >>> >> Yetâ¦ gofer will use metacello to load so, yes, it will use the best >>> >> package management we have at the moment. >>> >> >>> > >>> > Hi, >>> > >>> > Except if it changed recently, Gofer does not use Metacello behind. >>> > >>> > At Synectique when I tried to clean all our configurations because it >>> > was really hard to update them, I found some problems in the >>> > configurations but the projects were loading. The reasons was that we >>> > used Gofer and the bugs of gofer compensated the problems in the >>> > configurations. After switching to Metacello the projects did not load >>> > anymore and I needed to fix the configurations to make them clean. >>> > >>> > So, if it worked with Gofer but not Metacello, I doubt Gofer use >>> Metacello. >>> >>> there is no way of loading a configuration/baseline without metacello. >>> >>> Esteban >>> >>> > >>> >> >>> >> very unlikely. >>> >> a spec made in STON you just have to modify it each time you do a >>> >> release (which is exactly what you have to do now with >>> configurations). >>> >> >>> >> A crawler will not handle the need to publish a released version. >>> >> >>> >> one STON file as I imagine would be something like: >>> >> >>> >> project { >>> >> ânameâ : "blah", >>> >> âurlâ : "http://github.com/someone/blah", >>> >> âlastVersionâ : âv1.0.0", >>> >> âdescriptionâ : âSome project description" >>> >> } >>> >> >>> >> and maybe a couple more. Howâs that cryptic? >>> >> maybe you are confusing things? >>> >> >>> >> >>> > >>> > >>> > -- >>> > Cyril Ferlicot >>> > https://ferlicot.fr >>> > >>> >>> >>> >> >> >> -- >> >> >> >> 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 >> > >

April 20, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Peter UhnÃ¡k

> > Cargo is orthogonal to the need of a centralised repository. Yes, its idea is to provide oneâ¦ but we will need a central repo, always. Yes, but it already has STON manfiests to define the projects (project-metadata.ston). So why not use/extend the same file. Peter On Fri, Apr 20, 2018 at 7:23 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Thierry > > May be you are nervous these days. But try to relax and get a positive > mindset. > This is not perfect but it is there. You know that we are all full and > even more. > So just criticizing is not productive. > > > > One of the issues I have with the Catalog is that it made a mess of the > > various MetaRrepo for Pharo... Showing in the end that the single place > one > > should put a ConfigurationOf for Pharo is the squeak meta repo. > > If you find that funny it is not. > The point of having multiple repo was to make sure that contrary to > the old squeak experience > projects would load. > > > > That in addition the Catalog doesn't even use the best package > management we > > have at a given point is just salt rubbed in the wound. > > > I do not get what you mean but do not reply. > I do not think that it will be interested. You are in a ranting mode > and it deos not help. > > > > > > > As you wish. I know it belongs to one of these GUIs where I have to > spend 10 > > minutes to try to remember what the icons mean. But that's just me. > > Come on. There are fly by help > > > The key point to me is that the Catalog should reduce the friction it > > creates, not that the Catalog has to be a perfect solution. > > > > For example, do user-stories on it: how do one publish and updates a > project > > on the Catalog? What has one to do in CI to ensure a project is validated > > ... Can the catalog just takes care of that part, if the project has a > > correct setup (project has tests visible in the configurationOf, catalog > > does the CI stuff of testing it upon each new release of Pharo, even > stable > > because Iceberg breaks stuff when updated in Pharo 6.1, for example). > Tags > > for Pharo versions are only granted if project has been tested on CI by > the > > Catalog for the current version image you're in, for example. > > I have a long todo list too. We just did not get the resources for it. > Let us face it. > > > > We know how to explore and manipulate project specs already; look into > the > > GT tools for the code, and I also use a variant in my AltBrowser when I > sort > > all packages under the configuration or baseline they are specified in. > > > > In short, make it so that the Catalog is low friction and bring value to > > both project maintainers and users. > > > > Thierry > > > > > >> > >> Stef > >> > >> > >> On Thu, Apr 19, 2018 at 8:46 AM, Esteban Lorenzano <estebanlm(a)gmail.com > > > >> wrote: > >>> > >>> why to kill it? > >>> right now we do not have a replacement. > >>> > >>> Esteban > >>> > >>>> On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self(a)gmail.com> > >>>> wrote: > >>>> > >>>> Hi guys > >>>> > >>>> What do we do with it? > >>>> What alternatives? > >>>> > >>>> Stef > >>>> > >>> > >>> > >> > >> > > > > > >

April 20, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Stephane Ducasse

Hi guille should we open an issue and update the catalog? Stef On Fri, Apr 20, 2018 at 3:53 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi all, > > IMHO, the problem is not metacello or gofer but the fact that the catalog > uses the old Metacello API: i.e., > > Gofer new > repository: 'zzz'; > configurationOf: 'XXX'; > load. > (ConfigurationOfXXX project version: #YYY) load > > instead of the *new* Metacello API > > Metacello new > repository: 'zzz' > configurationOf: 'XXX' > loadVersion: #'YYY' > > > > On Fri, Apr 20, 2018 at 3:34 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> >> > On 20 Apr 2018, at 12:42, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> >> wrote: >> > >> > Le 20/04/2018 Ã 11:44, Esteban Lorenzano a Ã©crit : >> >> >> >> >> >>> On 20 Apr 2018, at 11:01, Thierry Goubier <thierry.goubier(a)gmail.com >> >>> <mailto:thierry.goubier@gmail.com>> wrote: >> >>> >> >>> Le 20/04/2018 Ã 09:09, Stephane Ducasse a Ã©crit : >> >>>> The underlying questions (sorry for people that need subtitles) are: >> >>>> - how do we have a central place to declare projects >> >>>> - right now in Smalltalkhub/list is a nice way to find projects >> >>>> with the move to github >> >>>> we should get a central place >> >>> >> >>> One of the issues I have with the Catalog is that it made a mess of >> >>> the various MetaRrepo for Pharo... Showing in the end that the single >> >>> place one should put a ConfigurationOf for Pharo is the squeak meta >> repo. >> >> >> >> not really. >> >> if you put your project in the squeak meta repo it will not even be >> >> listed (is old stuff and we are not listing those). >> >> >> >> the idea was to add a project in its corresponding development repo. >> But >> >> is an uncomfortable way, yes (and it was a patch, not meant to last) >> >> >> >>> That in addition the Catalog doesn't even use the best package >> >>> management we have at a given point is just salt rubbed in the wound. >> >> >> >> thatâs a one method change. Instead: >> >> >> >> loadConfiguration >> >> Gofer it >> >> url: self repositoryUrl; >> >> configurationOf: self name; >> >> load >> >> >> >> loadConfiguration >> >> Metacello new >> >> repository: self repositoryUrl; >> >> configuration: self name; >> >> load. >> >> >> >> when I made catalog, Metacello usage was not so expanded. >> >> Yetâ¦ gofer will use metacello to load so, yes, it will use the best >> >> package management we have at the moment. >> >> >> > >> > Hi, >> > >> > Except if it changed recently, Gofer does not use Metacello behind. >> > >> > At Synectique when I tried to clean all our configurations because it >> > was really hard to update them, I found some problems in the >> > configurations but the projects were loading. The reasons was that we >> > used Gofer and the bugs of gofer compensated the problems in the >> > configurations. After switching to Metacello the projects did not load >> > anymore and I needed to fix the configurations to make them clean. >> > >> > So, if it worked with Gofer but not Metacello, I doubt Gofer use >> Metacello. >> >> there is no way of loading a configuration/baseline without metacello. >> >> Esteban >> >> > >> >> >> >> very unlikely. >> >> a spec made in STON you just have to modify it each time you do a >> >> release (which is exactly what you have to do now with configurations). >> >> >> >> A crawler will not handle the need to publish a released version. >> >> >> >> one STON file as I imagine would be something like: >> >> >> >> project { >> >> ânameâ : "blah", >> >> âurlâ : "http://github.com/someone/blah", >> >> âlastVersionâ : âv1.0.0", >> >> âdescriptionâ : âSome project description" >> >> } >> >> >> >> and maybe a couple more. Howâs that cryptic? >> >> maybe you are confusing things? >> >> >> >> >> > >> > >> > -- >> > Cyril Ferlicot >> > https://ferlicot.fr >> > >> >> >> > > > -- > > > > 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 >

April 20, 2018

Re: [Pharo-dev] Do we kill the catalog?

by Stephane Ducasse

Thierry May be you are nervous these days. But try to relax and get a positive mindset. This is not perfect but it is there. You know that we are all full and even more. So just criticizing is not productive. > One of the issues I have with the Catalog is that it made a mess of the > various MetaRrepo for Pharo... Showing in the end that the single place one > should put a ConfigurationOf for Pharo is the squeak meta repo. If you find that funny it is not. The point of having multiple repo was to make sure that contrary to the old squeak experience projects would load. > That in addition the Catalog doesn't even use the best package management we > have at a given point is just salt rubbed in the wound. I do not get what you mean but do not reply. I do not think that it will be interested. You are in a ranting mode and it deos not help. > > As you wish. I know it belongs to one of these GUIs where I have to spend 10 > minutes to try to remember what the icons mean. But that's just me. Come on. There are fly by help > The key point to me is that the Catalog should reduce the friction it > creates, not that the Catalog has to be a perfect solution. > > For example, do user-stories on it: how do one publish and updates a project > on the Catalog? What has one to do in CI to ensure a project is validated > ... Can the catalog just takes care of that part, if the project has a > correct setup (project has tests visible in the configurationOf, catalog > does the CI stuff of testing it upon each new release of Pharo, even stable > because Iceberg breaks stuff when updated in Pharo 6.1, for example). Tags > for Pharo versions are only granted if project has been tested on CI by the > Catalog for the current version image you're in, for example. I have a long todo list too. We just did not get the resources for it. Let us face it. > We know how to explore and manipulate project specs already; look into the > GT tools for the code, and I also use a variant in my AltBrowser when I sort > all packages under the configuration or baseline they are specified in. > > In short, make it so that the Catalog is low friction and bring value to > both project maintainers and users. > > Thierry > > >> >> Stef >> >> >> On Thu, Apr 19, 2018 at 8:46 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >>> >>> why to kill it? >>> right now we do not have a replacement. >>> >>> Esteban >>> >>>> On 19 Apr 2018, at 08:42, Stephane Ducasse <stepharo.self(a)gmail.com> >>>> wrote: >>>> >>>> Hi guys >>>> >>>> What do we do with it? >>>> What alternatives? >>>> >>>> Stef >>>> >>> >>> >> >> > >

April 20, 2018

[Pharo 7.0-dev] Build #790: 21749-Removing-Override-support-from-RPackage

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

There is a new Pharo build available! The status of the build #790 was: SUCCESS. The Pull Request #1236 was integrated: "21749-Removing-Override-support-from-RPackage" Pull request url: https://github.com/pharo-project/pharo/pull/1236 Issue Url: https://pharo.fogbugz.com/f/cases/21749 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 20, 2018