- Pharo-dev - lists.pharo.org

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

[Pharo 8.0] Build #725: 4561-Ring-definitions-with-slots-use-category

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

There is a new Pharo build available! The status of the build #725 was: FAILURE. The Pull Request #4562 was integrated: "4561-Ring-definitions-with-slots-use-category" Pull request url: https://github.com/pharo-project/pharo/pull/4562 Issue Url: https://github.com/pharo-project/pharo/issues/4561 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 11, 2019

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

by Martin Dias

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

Re: [Pharo-dev] Zero Conf for Windows 10

by vincent.blondeau＠polytech-lille.net

Yes It works thanks! But, it is still not an optimal solution because you need to install git bash and in windows bash scripts you have to mix with git bash commands. Thanks, Vincent From: Pharo-dev On Behalf Of Christopher Fuhrman Sent: Wednesday, 11 September 2019 13:31 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] Zero Conf for Windows 10 Did you try it in git bash (after installing git on Windows)? Git bash has a lot of support (I think I used zeroconf that way before moving to WSL), although it is not as much as cygwin. On Wed, Sep 11, 2019, 05:53 <vincent.blondeau(a)polytech-lille.net <mailto:vincent.blondeau@polytech-lille.net> > wrote: Hi all, I wanted to try to get a Pharo image (the headless one to try the new gtk binding) through the Pharo Zero conf on a Windows 10 machine. So, I ran in the Powershell and the cmd: curl https://get.pharo.org/64/vmHeadlessLatest80 | bash But bash is not recognized under windows, so you end by looking into the http://files.pharo.org and look tediously for the vm or the image you are looking for. I was wondering if there are some projects aiming to use the windows cmd or powershell for zeroconf. Otherwise, what will be the cost to do it? (Of course, I could install Cygwin or MinCw (with some additional packages like unzip which is not in the default configuration), but the goal here is to have it on the shelf). Thanks, Vincent

Sept. 11, 2019