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

[Pharo 8.0] Build #729: 4554-tagsForAllMethods-not-in-Ring

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

There is a new Pharo build available! The status of the build #729 was: FAILURE. The Pull Request #4555 was integrated: "4554-tagsForAllMethods-not-in-Ring" Pull request url: https://github.com/pharo-project/pharo/pull/4555 Issue Url: https://github.com/pharo-project/pharo/issues/4554 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 12, 2019

[Pharo 8.0] Build #728: 4552-propagateTransformation-should-not-be-subclassResponsibility

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

There is a new Pharo build available! The status of the build #728 was: FAILURE. The Pull Request #4556 was integrated: "4552-propagateTransformation-should-not-be-subclassResponsibility" Pull request url: https://github.com/pharo-project/pharo/pull/4556 Issue Url: https://github.com/pharo-project/pharo/issues/4552 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 12, 2019

[Pharo 8.0] Build #727: 2165-GrowlMorphdefaultBorderColor-is-not-take-into-account

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

There is a new Pharo build available! The status of the build #727 was: FAILURE. The Pull Request #4566 was integrated: "2165-GrowlMorphdefaultBorderColor-is-not-take-into-account" Pull request url: https://github.com/pharo-project/pharo/pull/4566 Issue Url: https://github.com/pharo-project/pharo/issues/2165 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 12, 2019

Iceberg Error in Pharo 7

by Sean P. DeNigris

When trying to convert Soup to Tonel, I got: UndefinedObject(Object)>>doesNotUnderstand: #methodClass RGMethodDefinition>>asMCMethodDefinitionFromActiveDefinition RGMethodDefinition>>basicAsMCMethodDefinition RGMethodDefinition>>asMCMethodDefinition [ :ea | definitions add: ea asMCMethodDefinition ] in MCPackage>>basicSnapshot in Block: [ :ea | definitions add: ea asMCMethodDefinition ]...etc... Array(SequenceableCollection)>>do: MCPackage>>basicSnapshot IceWorkingCopy>>snapshotForPackage: IceMCPackageImporter>>snapshot Ideas? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 11, 2019

Re: [Pharo-dev] I have a dream... or why I think that compatibility is an illusion and bring us to the past

by Nicolas Cellier

It was just an answer to: > Do not tell me that there is a value in these selectors? I used the same argument for huge?:or!:???and: But I don't think it's a valid argument: it's making induction starting with a restricted set of examples... I also tried to answer to why and when a binary selector would be a "good" selector (elected for core libraries). (since you gave a list of selectors which were OK) I said that I don't really need ? nor ! in binary selectors, but neither do I in unary/keyword selectors (though I also thought using ? for boolean answer, I don't think it's really useful) Le mer. 11 sept. 2019 Ã 20:10, ducasse <stepharo(a)netcourrier.com> a Ã©crit : > Wait I do not understand what you are saying :) > I never said that I want to forbid anything. I just say that I would like > that ? is not consider as a part of a binary selector. > Amâi clearer? > > Stef > > > On 11 Sep 2019, at 19:48, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Ah, and I forgot about your argumentation Stef: > > you cannot forbid binary selectors altogether because some are ugly > @@*+!!! (I think I read this one in Asterix le gaulois) > for the same reasons that > youCanNOtfOrBIDunaYSElectORSWIthletTersBECauSESoMeaREUgly > > Le mer. 11 sept. 2019 Ã 19:44, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > >> >> >> Le mer. 11 sept. 2019 Ã 10:40, Serge Stinckwich < >> serge.stinckwich(a)gmail.com> a Ã©crit : >> >>> >>> >>> On Wed, Sep 11, 2019 at 2:14 AM Gabriel Cotelli <g.cotelli(a)gmail.com> >>> wrote: >>> >>>> Looks like Christmas season opened early this year :) >>>> >>>> Jokes aside, I'm in favor of changing some of the characters we use for >>>> binary selectors to allow it to be used in keyword/unary messages. >>>> >>>> I'll include % in that list. For me its more useful as a way to create >>>> percentages ( 5 % ) than to be used as a binary message for keeping an ugly >>>> name from C-like languages. >>>> >>>> - Â· is middle dot and it's used in some math operations AFAIR >>>> - Ã is used in math also (it's used as the multiplication sign for >>>> scalars, cross product for vectors and cartesian product for sets) >>>> >>>> One thing that would be really cool is that we can use the full power >>>> of Unicode in methods/class names. Projects like polymath and DSLs can >>>> clearly take advantage of that. Some examples I've just invented, but can >>>> be supported: >>>> >>>> >>>> - â from: 1 to: 5 do: [:i | i + i squared ] >>>> - 1 â¥ 3 >>>> - â anyIn: #( 1 2 4) such: [:x | x isPrime ] >>>> - â includes: 1 >>>> >>>> >>>> >>> Yes I would like to have something like that for PolyMath :-) >>> Is it possible to use Unicode characters for identifiers already ? >>> >>> I working on the port of : https://github.com/len/Domains >>> to Pharo. The author modify the Cuis parser, so he can do things like >>> that : >>> >>> "â is used for direct sums, â for tensor products, Ã for cartesian >>> product, direct product of groups, ring products, and in general for >>> categorical products." >>> >> >> Of course we want to be able to use those selectors: â â etc... >> Not using those selectors in core image is one thing, forbiding their >> usage for every package is another thing >> >> Concerning the selectors with more than 2 characters, there are two >> examples in use in Squeak >> ==> logical implication (I use it a lot when writing tests cases) >> <=> space ship operator >> /// has been used in the past (but is rather deprecated) >> >> What is questionable is cultural acceptance of universal meaning of a >> Symbol >> <=> could have meant logical equivalence, but it would be pointless, >> because = (and == thanks to singleton) are already equivalence. >> It has been expunged from Pharo to my regrets, because it is >> - beautifully self defined as < = > >> - culturally legitimate >> - the art of original author (Travis Griggs) >> There is no sacred cow, but respect of author has a value for me. >> >> It's sure that every binary selector might be questionable, at least in >> core image. >> For application, you never know (think DSL) we can create a lot of not >> completely inaesthetic ASCII styles >> <|> >< <+> <-> /+/ |*| >> For example +/- could be used for interval arithmetic (if we don't want >> to pay the burden of typing unicode, which ain't easy) >> /\ \/ intersection and union >> |\| the Nicolas operator - I didn't fin a usage for it yet ;) >> etc... >> So why would one want to forbid them? >> >> For ? and ! I do not foresee elegant usage as binary, but would not miss >> them as regular letters eithers. >> It means accepting huge??? - understand isReallyHuge :) >> huge?:or!:???and: which are not less questionable. >> >> Ideally, it should be really easy to define one's own syntax in any class >> (already possible with own compiler/parser/scanner/whatever), or maybe any >> method >> I find that it's somehow more complex with the well engineered new >> Compiler than it was with the very hackish legacy one, but that's a detail. >> >> >>> and also define ^ as a binary method: >>> >>> "The ^ (hat) operator is used for exponentiation as well as conjugation >>> by group elements, and for creating free modules of tuples and matrices." >>> >>> I'm not sure this is a good idea, because ^ is used also to return >>> values. >>> >> >> There is no ambiguity for ^ and i have proposed that in Squeak years ago, >> it's a very simple change (here for legacy Compiler) >> http://source.squeak.org/inbox/Compiler-nice.280.diff >> >> The only argument against it is that omitting the point ending last but >> one sentence would not be detected as invalid syntax >> >> self doThis. >> ^self doThat >> >> versus >> >> self doThis >> ^self doThat >> >> To address this concern, we could have rules concerning the formatting: >> normally we would write >> >> self doThis ^ self doThat >> >> or eventually if on several lines, we would generally indent >> >> self doThis >> ^ self doThat >> >> An unusual formatting is a code smell IMO >> And in fact, this is not much different from un-detecting when we send a >> message #self when forgetting the point >> >> self doThis >> self doThat >> >> self doThis self doThat. >> >> >>> A+ >>> -- >>> Serge Stinckwic >>> h >>> >>> Int. Research Unit >>> on Modelling/Simulation of Complex Systems (UMMISCO) >>> Sorbonne University >>> (SU) >>> French National Research Institute for Sustainable Development (IRD) >>> U >>> niversity of YaoundÃ© I, Cameroon >>> "Programs must be written for people to read, and only incidentally for >>> machines to execute." >>> https://twitter.com/SergeStinckwich >>> >> >

Sept. 11, 2019

Re: [Pharo-dev] I have a dream... or why I think that compatibility is an illusion and bring us to the past

by ducasse

Wait I do not understand what you are saying :) I never said that I want to forbid anything. I just say that I would like that ? is not consider as a part of a binary selector. Amâi clearer? Stef > On 11 Sep 2019, at 19:48, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Ah, and I forgot about your argumentation Stef: > > you cannot forbid binary selectors altogether because some are ugly @@*+!!! (I think I read this one in Asterix le gaulois) > for the same reasons that youCanNOtfOrBIDunaYSElectORSWIthletTersBECauSESoMeaREUgly > > Le mer. 11 sept. 2019 Ã 19:44, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> a Ã©crit : > > > Le mer. 11 sept. 2019 Ã 10:40, Serge Stinckwich <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@gmail.com>> a Ã©crit : > > > On Wed, Sep 11, 2019 at 2:14 AM Gabriel Cotelli <g.cotelli(a)gmail.com <mailto:g.cotelli@gmail.com>> wrote: > Looks like Christmas season opened early this year :) > > Jokes aside, I'm in favor of changing some of the characters we use for binary selectors to allow it to be used in keyword/unary messages. > > I'll include % in that list. For me its more useful as a way to create percentages ( 5 % ) than to be used as a binary message for keeping an ugly name from C-like languages. > Â· is middle dot and it's used in some math operations AFAIR > Ã is used in math also (it's used as the multiplication sign for scalars, cross product for vectors and cartesian product for sets) > One thing that would be really cool is that we can use the full power of Unicode in methods/class names. Projects like polymath and DSLs can clearly take advantage of that. Some examples I've just invented, but can be supported: > > â from: 1 to: 5 do: [:i | i + i squared ] > 1 â¥ 3 > â anyIn: #( 1 2 4) such: [:x | x isPrime ] > â includes: 1 > > > Yes I would like to have something like that for PolyMath :-) > Is it possible to use Unicode characters for identifiers already ? > > I working on the port of : https://github.com/len/Domains <https://github.com/len/Domains> > to Pharo. The author modify the Cuis parser, so he can do things like that : > > "â is used for direct sums, â for tensor products, Ã for cartesian product, direct product of groups, ring products, and in general for categorical products." > > Of course we want to be able to use those selectors: â â etc... > Not using those selectors in core image is one thing, forbiding their usage for every package is another thing > > Concerning the selectors with more than 2 characters, there are two examples in use in Squeak > ==> logical implication (I use it a lot when writing tests cases) > <=> space ship operator > /// has been used in the past (but is rather deprecated) > > What is questionable is cultural acceptance of universal meaning of a Symbol > <=> could have meant logical equivalence, but it would be pointless, because = (and == thanks to singleton) are already equivalence. > It has been expunged from Pharo to my regrets, because it is > - beautifully self defined as < = > > - culturally legitimate > - the art of original author (Travis Griggs) > There is no sacred cow, but respect of author has a value for me. > > It's sure that every binary selector might be questionable, at least in core image. > For application, you never know (think DSL) we can create a lot of not completely inaesthetic ASCII styles > <|> >< <+> <-> /+/ |*| > For example +/- could be used for interval arithmetic (if we don't want to pay the burden of typing unicode, which ain't easy) > /\ \/ intersection and union > |\| the Nicolas operator - I didn't fin a usage for it yet ;) > etc... > So why would one want to forbid them? > > For ? and ! I do not foresee elegant usage as binary, but would not miss them as regular letters eithers. > It means accepting huge??? - understand isReallyHuge :) > huge?:or!:???and: which are not less questionable. > > Ideally, it should be really easy to define one's own syntax in any class (already possible with own compiler/parser/scanner/whatever), or maybe any method > I find that it's somehow more complex with the well engineered new Compiler than it was with the very hackish legacy one, but that's a detail. > > > and also define ^ as a binary method: > > "The ^ (hat) operator is used for exponentiation as well as conjugation by group elements, and for creating free modules of tuples and matrices." > > I'm not sure this is a good idea, because ^ is used also to return values. > > There is no ambiguity for ^ and i have proposed that in Squeak years ago, it's a very simple change (here for legacy Compiler) > http://source.squeak.org/inbox/Compiler-nice.280.diff <http://source.squeak.org/inbox/Compiler-nice.280.diff> > > The only argument against it is that omitting the point ending last but one sentence would not be detected as invalid syntax > > self doThis. > ^self doThat > > versus > > self doThis > ^self doThat > > To address this concern, we could have rules concerning the formatting: > normally we would write > > self doThis ^ self doThat > > or eventually if on several lines, we would generally indent > > self doThis > ^ self doThat > > An unusual formatting is a code smell IMO > And in fact, this is not much different from un-detecting when we send a message #self when forgetting the point > > self doThis > self doThat > > self doThis self doThat. > > > A+ > -- > Serge Stinckwich > Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) > Sorbonne University (SU) > French National Research Institute for Sustainable Development (IRD) > University of YaoundÃ© I, Cameroon > "Programs must be written for people to read, and only incidentally for machines to execute." > https://twitter.com/SergeStinckwich <https://twitter.com/SergeStinckwich>

Sept. 11, 2019

Re: [Pharo-dev] I have a dream... or why I think that compatibility is an illusion and bring us to the past

by Nicolas Cellier

Ah, and I forgot about your argumentation Stef: you cannot forbid binary selectors altogether because some are ugly @@*+!!! (I think I read this one in Asterix le gaulois) for the same reasons that youCanNOtfOrBIDunaYSElectORSWIthletTersBECauSESoMeaREUgly Le mer. 11 sept. 2019 Ã 19:44, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > > > Le mer. 11 sept. 2019 Ã 10:40, Serge Stinckwich < > serge.stinckwich(a)gmail.com> a Ã©crit : > >> >> >> On Wed, Sep 11, 2019 at 2:14 AM Gabriel Cotelli <g.cotelli(a)gmail.com> >> wrote: >> >>> Looks like Christmas season opened early this year :) >>> >>> Jokes aside, I'm in favor of changing some of the characters we use for >>> binary selectors to allow it to be used in keyword/unary messages. >>> >>> I'll include % in that list. For me its more useful as a way to create >>> percentages ( 5 % ) than to be used as a binary message for keeping an ugly >>> name from C-like languages. >>> >>> - Â· is middle dot and it's used in some math operations AFAIR >>> - Ã is used in math also (it's used as the multiplication sign for >>> scalars, cross product for vectors and cartesian product for sets) >>> >>> One thing that would be really cool is that we can use the full power of >>> Unicode in methods/class names. Projects like polymath and DSLs can clearly >>> take advantage of that. Some examples I've just invented, but can be >>> supported: >>> >>> >>> - >>> >>> â from: 1 to: 5 do: [:i | i + i squared ] >>> - >>> >>> 1 â¥ 3 >>> - >>> >>> â anyIn: #( 1 2 4) such: [:x | x isPrime ] >>> - >>> >>> â includes: 1 >>> >>> >>> >> Yes I would like to have something like that for PolyMath :-) >> Is it possible to use Unicode characters for identifiers already ? >> >> I working on the port of : https://github.com/len/Domains >> to Pharo. The author modify the Cuis parser, so he can do things like >> that : >> >> "â is used for direct sums, â for tensor products, Ã for cartesian >> product, direct product of groups, ring products, and in general for >> categorical products." >> > > Of course we want to be able to use those selectors: â â etc... > Not using those selectors in core image is one thing, forbiding their > usage for every package is another thing > > Concerning the selectors with more than 2 characters, there are two > examples in use in Squeak > ==> logical implication (I use it a lot when writing tests cases) > <=> space ship operator > /// has been used in the past (but is rather deprecated) > > What is questionable is cultural acceptance of universal meaning of a > Symbol > <=> could have meant logical equivalence, but it would be pointless, > because = (and == thanks to singleton) are already equivalence. > It has been expunged from Pharo to my regrets, because it is > - beautifully self defined as < = > > - culturally legitimate > - the art of original author (Travis Griggs) > There is no sacred cow, but respect of author has a value for me. > > It's sure that every binary selector might be questionable, at least in > core image. > For application, you never know (think DSL) we can create a lot of not > completely inaesthetic ASCII styles > <|> >< <+> <-> /+/ |*| > For example +/- could be used for interval arithmetic (if we don't want to > pay the burden of typing unicode, which ain't easy) > /\ \/ intersection and union > |\| the Nicolas operator - I didn't fin a usage for it yet ;) > etc... > So why would one want to forbid them? > > For ? and ! I do not foresee elegant usage as binary, but would not miss > them as regular letters eithers. > It means accepting huge??? - understand isReallyHuge :) > huge?:or!:???and: which are not less questionable. > > Ideally, it should be really easy to define one's own syntax in any class > (already possible with own compiler/parser/scanner/whatever), or maybe any > method > I find that it's somehow more complex with the well engineered new > Compiler than it was with the very hackish legacy one, but that's a detail. > > >> and also define ^ as a binary method: >> >> "The ^ (hat) operator is used for exponentiation as well as conjugation >> by group elements, and for creating free modules of tuples and matrices." >> >> I'm not sure this is a good idea, because ^ is used also to return values. >> > > There is no ambiguity for ^ and i have proposed that in Squeak years ago, > it's a very simple change (here for legacy Compiler) > http://source.squeak.org/inbox/Compiler-nice.280.diff > > The only argument against it is that omitting the point ending last but > one sentence would not be detected as invalid syntax > > self doThis. > ^self doThat > > versus > > self doThis > ^self doThat > > To address this concern, we could have rules concerning the formatting: > normally we would write > > self doThis ^ self doThat > > or eventually if on several lines, we would generally indent > > self doThis > ^ self doThat > > An unusual formatting is a code smell IMO > And in fact, this is not much different from un-detecting when we send a > message #self when forgetting the point > > self doThis > self doThat > > self doThis self doThat. > > >> A+ >> -- >> Serge Stinckwic >> h >> >> Int. Research Unit >> on Modelling/Simulation of Complex Systems (UMMISCO) >> Sorbonne University >> (SU) >> French National Research Institute for Sustainable Development (IRD) >> U >> niversity of YaoundÃ© I, Cameroon >> "Programs must be written for people to read, and only incidentally for >> machines to execute." >> https://twitter.com/SergeStinckwich >> >

Sept. 11, 2019

Re: [Pharo-dev] I have a dream... or why I think that compatibility is an illusion and bring us to the past

by Nicolas Cellier

Le mer. 11 sept. 2019 Ã 10:40, Serge Stinckwich <serge.stinckwich(a)gmail.com> a Ã©crit : > > > On Wed, Sep 11, 2019 at 2:14 AM Gabriel Cotelli <g.cotelli(a)gmail.com> > wrote: > >> Looks like Christmas season opened early this year :) >> >> Jokes aside, I'm in favor of changing some of the characters we use for >> binary selectors to allow it to be used in keyword/unary messages. >> >> I'll include % in that list. For me its more useful as a way to create >> percentages ( 5 % ) than to be used as a binary message for keeping an ugly >> name from C-like languages. >> >> - Â· is middle dot and it's used in some math operations AFAIR >> - Ã is used in math also (it's used as the multiplication sign for >> scalars, cross product for vectors and cartesian product for sets) >> >> One thing that would be really cool is that we can use the full power of >> Unicode in methods/class names. Projects like polymath and DSLs can clearly >> take advantage of that. Some examples I've just invented, but can be >> supported: >> >> >> - >> >> â from: 1 to: 5 do: [:i | i + i squared ] >> - >> >> 1 â¥ 3 >> - >> >> â anyIn: #( 1 2 4) such: [:x | x isPrime ] >> - >> >> â includes: 1 >> >> >> > Yes I would like to have something like that for PolyMath :-) > Is it possible to use Unicode characters for identifiers already ? > > I working on the port of : https://github.com/len/Domains > to Pharo. The author modify the Cuis parser, so he can do things like that > : > > "â is used for direct sums, â for tensor products, Ã for cartesian > product, direct product of groups, ring products, and in general for > categorical products." > Of course we want to be able to use those selectors: â â etc... Not using those selectors in core image is one thing, forbiding their usage for every package is another thing Concerning the selectors with more than 2 characters, there are two examples in use in Squeak ==> logical implication (I use it a lot when writing tests cases) <=> space ship operator /// has been used in the past (but is rather deprecated) What is questionable is cultural acceptance of universal meaning of a Symbol <=> could have meant logical equivalence, but it would be pointless, because = (and == thanks to singleton) are already equivalence. It has been expunged from Pharo to my regrets, because it is - beautifully self defined as < = > - culturally legitimate - the art of original author (Travis Griggs) There is no sacred cow, but respect of author has a value for me. It's sure that every binary selector might be questionable, at least in core image. For application, you never know (think DSL) we can create a lot of not completely inaesthetic ASCII styles <|> >< <+> <-> /+/ |*| For example +/- could be used for interval arithmetic (if we don't want to pay the burden of typing unicode, which ain't easy) /\ \/ intersection and union |\| the Nicolas operator - I didn't fin a usage for it yet ;) etc... So why would one want to forbid them? For ? and ! I do not foresee elegant usage as binary, but would not miss them as regular letters eithers. It means accepting huge??? - understand isReallyHuge :) huge?:or!:???and: which are not less questionable. Ideally, it should be really easy to define one's own syntax in any class (already possible with own compiler/parser/scanner/whatever), or maybe any method I find that it's somehow more complex with the well engineered new Compiler than it was with the very hackish legacy one, but that's a detail. > and also define ^ as a binary method: > > "The ^ (hat) operator is used for exponentiation as well as conjugation by > group elements, and for creating free modules of tuples and matrices." > > I'm not sure this is a good idea, because ^ is used also to return values. > There is no ambiguity for ^ and i have proposed that in Squeak years ago, it's a very simple change (here for legacy Compiler) http://source.squeak.org/inbox/Compiler-nice.280.diff The only argument against it is that omitting the point ending last but one sentence would not be detected as invalid syntax self doThis. ^self doThat versus self doThis ^self doThat To address this concern, we could have rules concerning the formatting: normally we would write self doThis ^ self doThat or eventually if on several lines, we would generally indent self doThis ^ self doThat An unusual formatting is a code smell IMO And in fact, this is not much different from un-detecting when we send a message #self when forgetting the point self doThis self doThat self doThis self doThat. > A+ > -- > Serge Stinckwic > h > > Int. Research Unit > on Modelling/Simulation of Complex Systems (UMMISCO) > Sorbonne University > (SU) > French National Research Institute for Sustainable Development (IRD) > U > niversity of YaoundÃ© I, Cameroon > "Programs must be written for people to read, and only incidentally for > machines to execute." > https://twitter.com/SergeStinckwich >

Sept. 11, 2019

Re: [Pharo-dev] [Pharo 8.0] Build #724: 4287-Integrate-Ring2

by Pavel Krivanek

No, directly to Pharo (unless it is for older versions), I will add information to the original repository. -- Pavel st 11. 9. 2019 v 16:26 odesÃlatel Martin Dias <tinchodias(a)gmail.com> napsal: > Nice. Is it decided where should issues and PRs be reported? pharo or > original ring2 repo? > > On Wed, Sep 11, 2019 at 8:38 AM <ci-pharo-ci-jenkins2(a)inria.fr> wrote: > > > > There is a new Pharo build available! > > > > The status of the build #724 was: SUCCESS. > > > > The Pull Request #4290 was integrated: "4287-Integrate-Ring2" > > Pull request url: https://github.com/pharo-project/pharo/pull/4290 > > > > Issue Url: https://github.com/pharo-project/pharo/issues/4287 > > Build Url: > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > >

Sept. 11, 2019

[Pharo 8.0] Build #726: 4563-reflectivity-update-rfValue

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

There is a new Pharo build available! The status of the build #726 was: FAILURE. The Pull Request #4564 was integrated: "4563-reflectivity-update-rfValue" Pull request url: https://github.com/pharo-project/pharo/pull/4564 Issue Url: https://github.com/pharo-project/pharo/issues/4563 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 11, 2019