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

Re: [Pharo-dev] ESUG 2019 - Call for presentations

by askoh

Are ESUG 2019 and IWST 2019 two difference conferences running in parallel? Are they independent of each other? Thanks, Aik-Siong Koh -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

May 14, 2019

Re: [Pharo-dev] Some more effort to make Slang and VMMaker work on Pharo [for review]

by ducasse

This is super nice and this was a couple of days well invested. I thought that it would be a lot more challenging so you prove it by doing it fast and this is super cool. In addition this is excellent that you added tests while doing it. I really want to have a tutorial on extending the VM with Pharo. Stef > Hi all, > > Just to keep everyone informed, last week Iâve spent a couple of days making slang work on Pharo again, based on the initial effort of Eliot. > The summary of what I did is: > > - we can generate, compile and run a stack vm > - we can generate, compile and run a cog vm > > - for this, Iâve done a couple of patches to VMMaker > - the ones specific to Pharo has been pushed > - the ones that touch cross dialect code are still in review (I think) > > To do this work > > - I had to review the AST-to-AST transformation, checking the output, comparing it to what squeak does and so on... > - Iâve written several unit tests to ensure that future migrations are easier to do > - Iâve introduced several compatibility classes/methods related to PackageInfo, Time and so onâ¦ > > Cheers, > Guille > >> Inicio del mensaje reenviado: >> >> De: Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> >> Asunto: Re: [Vm-dev] Some more effort to make Slang and VMMaker work on Pharo [for review] >> Fecha: 9 de mayo de 2019, 17:48:03 CEST >> Para: Open Smalltalk Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org <mailto:vm-dev@lists.squeakfoundation.org>> >> >> I've decided for the moment to put the tests in the PharoCompatibility package, since they are too close of Pharo's AST. >> I've tried to make them work in squeak but I've found too many incompatibilities in the AST and some in the collections that would make the tests too verbose to make them reusable... >> Maybe we can do an iteration afterwards. >> >> Cheers, >> Guille >> >> On Thu, May 9, 2019 at 5:21 PM Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> Hi all, >> >> On Wed, May 8, 2019 at 2:17 AM David T. Lewis <lewis(a)mail.msen.com <mailto:lewis@mail.msen.com>> wrote: >> >> >> On Tue, May 07, 2019 at 03:36:32PM -0700, Eliot Miranda wrote: >> >> > In VMMaker.oscog-GAP.2533 I would prefer to see printString instead of >> > asString. asString is a horrible hack. printString says what we mean. >> >> Sure. I've submitted another version to the inbox: >> >> Name: VMMaker.oscog-GAP.2534 >> Author: GAP >> Time: 9 May 2019, 5:12:22.055089 pm >> UUID: cd6aae16-6f20-4ddb-9328-64b19b413cb1 >> Ancestors: VMMaker.oscog-eem.2532 >> >> Convert numeric constants to strings for concatenation using #printString. >> Required for Pharo compatibility, where the arguments of concatenation are not automatically coerced to strings. >> >> > ==== Patch 1 ==== >> > > Name: VMMaker.oscog-GAP.2533 >> > > Author: GAP >> > > Time: 7 May 2019, 10:57:16.034354 am >> > > UUID: 3209319f-60f3-4586-8d03-cfac3c9fddee >> > > Ancestors: VMMaker.oscog-eem.2532 >> > > >> > > Convert numeric constants to strings for concatenation. >> > > Required for Pharo compatibility, where the arguments of concatenation are >> > > not automatically coerced to strings. >> > > >> > >> > I trust you on these. I'm not really in a position to test this out right >> > now. I suggest you push the VMMakerCompatibilityForPharo6 packages to >> > VMMaker as soon as you'd like. You can write VMMaker right? >> > >> >> +1 >> >> Guille, if you want commit access to the repo, you can make an account >> on source.squeak.org <http://source.squeak.org/> and I'll add you the the VMMaker project. Or if >> it's easier, just say which packages you are ready to move and either >> I or Eliot (or any of the others with commit access) will move it to >> VMMaker for you. >> >> I note that VMMaker.oscog-GAP.2533 package is part of the main >> VMMaker.oscog package. If you need to have that tested on Squeak I >> can probably do that for you within the next couple of days if no >> one else gets to it first. >> >> Well, the change I did in that package was fairly small, and I'm using squeak to generate also some parts of the VM to compare to what I generate from Pharo. >> So, I'd say I've tried it myself already. >> >> For the Pharo specific package, I've already uploaded it to the VMMaker repository. >> I had already rights to do it :). >> >> Name: VMMakerCompatibilityForPharo6-GuillermoPolito.11 >> Author: GuillermoPolito >> Time: 9 May 2019, 5:15:50.00473 pm >> UUID: e1a685a9-d744-0d00-b3c1-ad600f1a7e9a >> Ancestors: VMMakerCompatibilityForPharo6-GuillermoPolito.10 >> >> With these changes I can already compile and run Cog and almost all tests pass :) >> >> <image.png> >> >> I have also a couple dozen tests about AST translation and C generation, mainly about those parts that are covered differently between Pharo's and Squeak's ASTs. >> Would you like that I push them inside the VMMaker package or make a separate package? >> >> Thanks! >> Guille >> >> >> -- >> >> 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 >

May 14, 2019

Re: [Pharo-dev] Some more effort to make Slang and VMMaker work on Pharo [for review]

by Ben Coman

This is really great, thx Guille. I'd love to use Pharo environment when I play with the VM and look forward to trying it. Is it feasible to add VMMaker to the Catalog and make it a one click install? Thanks also Elliot for the initial work. cheers -ben On Tue, 14 May 2019 at 23:05, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Ah yes, and Iâve done this so far on Pharo6.1, platform where Eliot was > working on initially. > I donât think there is much to do to move it to Pharo7, but still Iâve not > explored it. > > El 14 may 2019, a las 16:29, Guillermo Polito <guillermopolito(a)gmail.com> > escribiÃ³: > > Hi all, > > Just to keep everyone informed, last week Iâve spent a couple of days > making slang work on Pharo again, based on the initial effort of Eliot. > The summary of what I did is: > > - we can generate, compile and run a stack vm > - we can generate, compile and run a cog vm > > - for this, Iâve done a couple of patches to VMMaker > - the ones specific to Pharo has been pushed > - the ones that touch cross dialect code are still in review (I think) > > To do this work > > - I had to review the AST-to-AST transformation, checking the output, > comparing it to what squeak does and so on... > - Iâve written several unit tests to ensure that future migrations are > easier to do > - Iâve introduced several compatibility classes/methods related to > PackageInfo, Time and so onâ¦ > > Cheers, > Guille > > Inicio del mensaje reenviado: > > *De: *Guillermo Polito <guillermopolito(a)gmail.com> > *Asunto: **Re: [Vm-dev] Some more effort to make Slang and VMMaker work > on Pharo [for review]* > *Fecha: *9 de mayo de 2019, 17:48:03 CEST > *Para: *Open Smalltalk Virtual Machine Development Discussion < > vm-dev(a)lists.squeakfoundation.org> > > I've decided for the moment to put the tests in the PharoCompatibility > package, since they are too close of Pharo's AST. > I've tried to make them work in squeak but I've found too many > incompatibilities in the AST and some in the collections that would make > the tests too verbose to make them reusable... > Maybe we can do an iteration afterwards. > > Cheers, > Guille > > On Thu, May 9, 2019 at 5:21 PM Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> Hi all, >> >> On Wed, May 8, 2019 at 2:17 AM David T. Lewis <lewis(a)mail.msen.com> >> wrote: >> >>> >>> >>> On Tue, May 07, 2019 at 03:36:32PM -0700, Eliot Miranda wrote: >>> >>> > In VMMaker.oscog-GAP.2533 I would prefer to see printString instead of >>> > asString. asString is a horrible hack. printString says what we mean. >>> >> >> Sure. I've submitted another version to the inbox: >> >> Name: VMMaker.oscog-GAP.2534 >> Author: GAP >> Time: 9 May 2019, 5:12:22.055089 pm >> UUID: cd6aae16-6f20-4ddb-9328-64b19b413cb1 >> Ancestors: VMMaker.oscog-eem.2532 >> >> Convert numeric constants to strings for concatenation using #printString. >> Required for Pharo compatibility, where the arguments of concatenation >> are not automatically coerced to strings. >> >> >>> > ==== Patch 1 ==== >>> > > Name: VMMaker.oscog-GAP.2533 >>> > > Author: GAP >>> > > Time: 7 May 2019, 10:57:16.034354 am >>> > > UUID: 3209319f-60f3-4586-8d03-cfac3c9fddee >>> > > Ancestors: VMMaker.oscog-eem.2532 >>> > > >>> > > Convert numeric constants to strings for concatenation. >>> > > Required for Pharo compatibility, where the arguments of >>> concatenation are >>> > > not automatically coerced to strings. >>> > > >>> > >>> > I trust you on these. I'm not really in a position to test this out >>> right >>> > now. I suggest you push the VMMakerCompatibilityForPharo6 packages to >>> > VMMaker as soon as you'd like. You can write VMMaker right? >>> > >>> >>> +1 >>> >>> Guille, if you want commit access to the repo, you can make an account >>> on source.squeak.org and I'll add you the the VMMaker project. Or if >>> it's easier, just say which packages you are ready to move and either >>> I or Eliot (or any of the others with commit access) will move it to >>> VMMaker for you. >>> >>> I note that VMMaker.oscog-GAP.2533 package is part of the main >>> VMMaker.oscog package. If you need to have that tested on Squeak I >>> can probably do that for you within the next couple of days if no >>> one else gets to it first. >>> >> >> Well, the change I did in that package was fairly small, and I'm using >> squeak to generate also some parts of the VM to compare to what I generate >> from Pharo. >> So, I'd say I've tried it myself already. >> >> For the Pharo specific package, I've already uploaded it to the VMMaker >> repository. >> I had already rights to do it :). >> >> Name: VMMakerCompatibilityForPharo6-GuillermoPolito.11 >> Author: GuillermoPolito >> Time: 9 May 2019, 5:15:50.00473 pm >> UUID: e1a685a9-d744-0d00-b3c1-ad600f1a7e9a >> Ancestors: VMMakerCompatibilityForPharo6-GuillermoPolito.10 >> >> With these changes I can already compile and run Cog and almost all tests >> pass :) >> >> <image.png> >> >> I have also a couple dozen tests about AST translation and C generation, >> mainly about those parts that are covered differently between Pharo's and >> Squeak's ASTs. >> Would you like that I push them inside the VMMaker package or make a >> separate package? >> >> Thanks! >> Guille >> > > > -- > > 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 > > > >

May 14, 2019

Re: [Pharo-dev] Some more effort to make Slang and VMMaker work on Pharo [for review]

by Guillermo Polito

Ah yes, and Iâve done this so far on Pharo6.1, platform where Eliot was working on initially. I donât think there is much to do to move it to Pharo7, but still Iâve not explored it. > El 14 may 2019, a las 16:29, Guillermo Polito <guillermopolito(a)gmail.com> escribiÃ³: > > Hi all, > > Just to keep everyone informed, last week Iâve spent a couple of days making slang work on Pharo again, based on the initial effort of Eliot. > The summary of what I did is: > > - we can generate, compile and run a stack vm > - we can generate, compile and run a cog vm > > - for this, Iâve done a couple of patches to VMMaker > - the ones specific to Pharo has been pushed > - the ones that touch cross dialect code are still in review (I think) > > To do this work > > - I had to review the AST-to-AST transformation, checking the output, comparing it to what squeak does and so on... > - Iâve written several unit tests to ensure that future migrations are easier to do > - Iâve introduced several compatibility classes/methods related to PackageInfo, Time and so onâ¦ > > Cheers, > Guille > >> Inicio del mensaje reenviado: >> >> De: Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> >> Asunto: Re: [Vm-dev] Some more effort to make Slang and VMMaker work on Pharo [for review] >> Fecha: 9 de mayo de 2019, 17:48:03 CEST >> Para: Open Smalltalk Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org <mailto:vm-dev@lists.squeakfoundation.org>> >> >> I've decided for the moment to put the tests in the PharoCompatibility package, since they are too close of Pharo's AST. >> I've tried to make them work in squeak but I've found too many incompatibilities in the AST and some in the collections that would make the tests too verbose to make them reusable... >> Maybe we can do an iteration afterwards. >> >> Cheers, >> Guille >> >> On Thu, May 9, 2019 at 5:21 PM Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> Hi all, >> >> On Wed, May 8, 2019 at 2:17 AM David T. Lewis <lewis(a)mail.msen.com <mailto:lewis@mail.msen.com>> wrote: >> >> >> On Tue, May 07, 2019 at 03:36:32PM -0700, Eliot Miranda wrote: >> >> > In VMMaker.oscog-GAP.2533 I would prefer to see printString instead of >> > asString. asString is a horrible hack. printString says what we mean. >> >> Sure. I've submitted another version to the inbox: >> >> Name: VMMaker.oscog-GAP.2534 >> Author: GAP >> Time: 9 May 2019, 5:12:22.055089 pm >> UUID: cd6aae16-6f20-4ddb-9328-64b19b413cb1 >> Ancestors: VMMaker.oscog-eem.2532 >> >> Convert numeric constants to strings for concatenation using #printString. >> Required for Pharo compatibility, where the arguments of concatenation are not automatically coerced to strings. >> >> > ==== Patch 1 ==== >> > > Name: VMMaker.oscog-GAP.2533 >> > > Author: GAP >> > > Time: 7 May 2019, 10:57:16.034354 am >> > > UUID: 3209319f-60f3-4586-8d03-cfac3c9fddee >> > > Ancestors: VMMaker.oscog-eem.2532 >> > > >> > > Convert numeric constants to strings for concatenation. >> > > Required for Pharo compatibility, where the arguments of concatenation are >> > > not automatically coerced to strings. >> > > >> > >> > I trust you on these. I'm not really in a position to test this out right >> > now. I suggest you push the VMMakerCompatibilityForPharo6 packages to >> > VMMaker as soon as you'd like. You can write VMMaker right? >> > >> >> +1 >> >> Guille, if you want commit access to the repo, you can make an account >> on source.squeak.org <http://source.squeak.org/> and I'll add you the the VMMaker project. Or if >> it's easier, just say which packages you are ready to move and either >> I or Eliot (or any of the others with commit access) will move it to >> VMMaker for you. >> >> I note that VMMaker.oscog-GAP.2533 package is part of the main >> VMMaker.oscog package. If you need to have that tested on Squeak I >> can probably do that for you within the next couple of days if no >> one else gets to it first. >> >> Well, the change I did in that package was fairly small, and I'm using squeak to generate also some parts of the VM to compare to what I generate from Pharo. >> So, I'd say I've tried it myself already. >> >> For the Pharo specific package, I've already uploaded it to the VMMaker repository. >> I had already rights to do it :). >> >> Name: VMMakerCompatibilityForPharo6-GuillermoPolito.11 >> Author: GuillermoPolito >> Time: 9 May 2019, 5:15:50.00473 pm >> UUID: e1a685a9-d744-0d00-b3c1-ad600f1a7e9a >> Ancestors: VMMakerCompatibilityForPharo6-GuillermoPolito.10 >> >> With these changes I can already compile and run Cog and almost all tests pass :) >> >> <image.png> >> >> I have also a couple dozen tests about AST translation and C generation, mainly about those parts that are covered differently between Pharo's and Squeak's ASTs. >> Would you like that I push them inside the VMMaker package or make a separate package? >> >> Thanks! >> Guille >> >> >> -- >> >> 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 >

May 14, 2019

Re: [Pharo-dev] Some more effort to make Slang and VMMaker work on Pharo [for review]

by Nicolas Cellier

Thanks Guile, This is super important to ease contributions from Pharo teams. Le mar. 14 mai 2019 Ã 16:30, Guillermo Polito <guillermopolito(a)gmail.com> a Ã©crit : > Hi all, > > Just to keep everyone informed, last week Iâve spent a couple of days > making slang work on Pharo again, based on the initial effort of Eliot. > The summary of what I did is: > > - we can generate, compile and run a stack vm > - we can generate, compile and run a cog vm > > - for this, Iâve done a couple of patches to VMMaker > - the ones specific to Pharo has been pushed > - the ones that touch cross dialect code are still in review (I think) > > To do this work > > - I had to review the AST-to-AST transformation, checking the output, > comparing it to what squeak does and so on... > - Iâve written several unit tests to ensure that future migrations are > easier to do > - Iâve introduced several compatibility classes/methods related to > PackageInfo, Time and so onâ¦ > > Cheers, > Guille > > Inicio del mensaje reenviado: > > *De: *Guillermo Polito <guillermopolito(a)gmail.com> > *Asunto: **Re: [Vm-dev] Some more effort to make Slang and VMMaker work > on Pharo [for review]* > *Fecha: *9 de mayo de 2019, 17:48:03 CEST > *Para: *Open Smalltalk Virtual Machine Development Discussion < > vm-dev(a)lists.squeakfoundation.org> > > I've decided for the moment to put the tests in the PharoCompatibility > package, since they are too close of Pharo's AST. > I've tried to make them work in squeak but I've found too many > incompatibilities in the AST and some in the collections that would make > the tests too verbose to make them reusable... > Maybe we can do an iteration afterwards. > > Cheers, > Guille > > On Thu, May 9, 2019 at 5:21 PM Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> Hi all, >> >> On Wed, May 8, 2019 at 2:17 AM David T. Lewis <lewis(a)mail.msen.com> >> wrote: >> >>> >>> >>> On Tue, May 07, 2019 at 03:36:32PM -0700, Eliot Miranda wrote: >>> >>> > In VMMaker.oscog-GAP.2533 I would prefer to see printString instead of >>> > asString. asString is a horrible hack. printString says what we mean. >>> >> >> Sure. I've submitted another version to the inbox: >> >> Name: VMMaker.oscog-GAP.2534 >> Author: GAP >> Time: 9 May 2019, 5:12:22.055089 pm >> UUID: cd6aae16-6f20-4ddb-9328-64b19b413cb1 >> Ancestors: VMMaker.oscog-eem.2532 >> >> Convert numeric constants to strings for concatenation using #printString. >> Required for Pharo compatibility, where the arguments of concatenation >> are not automatically coerced to strings. >> >> >>> > ==== Patch 1 ==== >>> > > Name: VMMaker.oscog-GAP.2533 >>> > > Author: GAP >>> > > Time: 7 May 2019, 10:57:16.034354 am >>> > > UUID: 3209319f-60f3-4586-8d03-cfac3c9fddee >>> > > Ancestors: VMMaker.oscog-eem.2532 >>> > > >>> > > Convert numeric constants to strings for concatenation. >>> > > Required for Pharo compatibility, where the arguments of >>> concatenation are >>> > > not automatically coerced to strings. >>> > > >>> > >>> > I trust you on these. I'm not really in a position to test this out >>> right >>> > now. I suggest you push the VMMakerCompatibilityForPharo6 packages to >>> > VMMaker as soon as you'd like. You can write VMMaker right? >>> > >>> >>> +1 >>> >>> Guille, if you want commit access to the repo, you can make an account >>> on source.squeak.org and I'll add you the the VMMaker project. Or if >>> it's easier, just say which packages you are ready to move and either >>> I or Eliot (or any of the others with commit access) will move it to >>> VMMaker for you. >>> >>> I note that VMMaker.oscog-GAP.2533 package is part of the main >>> VMMaker.oscog package. If you need to have that tested on Squeak I >>> can probably do that for you within the next couple of days if no >>> one else gets to it first. >>> >> >> Well, the change I did in that package was fairly small, and I'm using >> squeak to generate also some parts of the VM to compare to what I generate >> from Pharo. >> So, I'd say I've tried it myself already. >> >> For the Pharo specific package, I've already uploaded it to the VMMaker >> repository. >> I had already rights to do it :). >> >> Name: VMMakerCompatibilityForPharo6-GuillermoPolito.11 >> Author: GuillermoPolito >> Time: 9 May 2019, 5:15:50.00473 pm >> UUID: e1a685a9-d744-0d00-b3c1-ad600f1a7e9a >> Ancestors: VMMakerCompatibilityForPharo6-GuillermoPolito.10 >> >> With these changes I can already compile and run Cog and almost all tests >> pass :) >> >> [image: image.png] >> >> I have also a couple dozen tests about AST translation and C generation, >> mainly about those parts that are covered differently between Pharo's and >> Squeak's ASTs. >> Would you like that I push them inside the VMMaker package or make a >> separate package? >> >> Thanks! >> Guille >> > > > -- > > 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 > > >

May 14, 2019

Some more effort to make Slang and VMMaker work on Pharo [for review]

by Guillermo Polito

Hi all, Just to keep everyone informed, last week Iâve spent a couple of days making slang work on Pharo again, based on the initial effort of Eliot. The summary of what I did is: - we can generate, compile and run a stack vm - we can generate, compile and run a cog vm - for this, Iâve done a couple of patches to VMMaker - the ones specific to Pharo has been pushed - the ones that touch cross dialect code are still in review (I think) To do this work - I had to review the AST-to-AST transformation, checking the output, comparing it to what squeak does and so on... - Iâve written several unit tests to ensure that future migrations are easier to do - Iâve introduced several compatibility classes/methods related to PackageInfo, Time and so onâ¦ Cheers, Guille > Inicio del mensaje reenviado: > > De: Guillermo Polito <guillermopolito(a)gmail.com> > Asunto: Re: [Vm-dev] Some more effort to make Slang and VMMaker work on Pharo [for review] > Fecha: 9 de mayo de 2019, 17:48:03 CEST > Para: Open Smalltalk Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > > I've decided for the moment to put the tests in the PharoCompatibility package, since they are too close of Pharo's AST. > I've tried to make them work in squeak but I've found too many incompatibilities in the AST and some in the collections that would make the tests too verbose to make them reusable... > Maybe we can do an iteration afterwards. > > Cheers, > Guille > > On Thu, May 9, 2019 at 5:21 PM Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > Hi all, > > On Wed, May 8, 2019 at 2:17 AM David T. Lewis <lewis(a)mail.msen.com <mailto:lewis@mail.msen.com>> wrote: > > > On Tue, May 07, 2019 at 03:36:32PM -0700, Eliot Miranda wrote: > > > In VMMaker.oscog-GAP.2533 I would prefer to see printString instead of > > asString. asString is a horrible hack. printString says what we mean. > > Sure. I've submitted another version to the inbox: > > Name: VMMaker.oscog-GAP.2534 > Author: GAP > Time: 9 May 2019, 5:12:22.055089 pm > UUID: cd6aae16-6f20-4ddb-9328-64b19b413cb1 > Ancestors: VMMaker.oscog-eem.2532 > > Convert numeric constants to strings for concatenation using #printString. > Required for Pharo compatibility, where the arguments of concatenation are not automatically coerced to strings. > > > ==== Patch 1 ==== > > > Name: VMMaker.oscog-GAP.2533 > > > Author: GAP > > > Time: 7 May 2019, 10:57:16.034354 am > > > UUID: 3209319f-60f3-4586-8d03-cfac3c9fddee > > > Ancestors: VMMaker.oscog-eem.2532 > > > > > > Convert numeric constants to strings for concatenation. > > > Required for Pharo compatibility, where the arguments of concatenation are > > > not automatically coerced to strings. > > > > > > > I trust you on these. I'm not really in a position to test this out right > > now. I suggest you push the VMMakerCompatibilityForPharo6 packages to > > VMMaker as soon as you'd like. You can write VMMaker right? > > > > +1 > > Guille, if you want commit access to the repo, you can make an account > on source.squeak.org <http://source.squeak.org/> and I'll add you the the VMMaker project. Or if > it's easier, just say which packages you are ready to move and either > I or Eliot (or any of the others with commit access) will move it to > VMMaker for you. > > I note that VMMaker.oscog-GAP.2533 package is part of the main > VMMaker.oscog package. If you need to have that tested on Squeak I > can probably do that for you within the next couple of days if no > one else gets to it first. > > Well, the change I did in that package was fairly small, and I'm using squeak to generate also some parts of the VM to compare to what I generate from Pharo. > So, I'd say I've tried it myself already. > > For the Pharo specific package, I've already uploaded it to the VMMaker repository. > I had already rights to do it :). > > Name: VMMakerCompatibilityForPharo6-GuillermoPolito.11 > Author: GuillermoPolito > Time: 9 May 2019, 5:15:50.00473 pm > UUID: e1a685a9-d744-0d00-b3c1-ad600f1a7e9a > Ancestors: VMMakerCompatibilityForPharo6-GuillermoPolito.10 > > With these changes I can already compile and run Cog and almost all tests pass :) > > > > I have also a couple dozen tests about AST translation and C generation, mainly about those parts that are covered differently between Pharo's and Squeak's ASTs. > Would you like that I push them inside the VMMaker package or make a separate package? > > Thanks! > Guille > > > -- > > 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

May 14, 2019

Re: [Pharo-dev] Metacello/Iceberg detached head of cascade loaded requirements

by Ben Coman

On Tue, 14 May 2019 at 18:02, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi Ben, > > Iâll complement a bit Gabrielâs answer. See inline > > El 11 may 2019, a las 10:39, Ben Coman <btc(a)openinworld.com> escribiÃ³: > > I have a query about "Detached HEAD" status after a Metacello/Iceberg > cascade load of required packages. Starting with the general questions... > Is that a common status for this scenario? > > > Yes. > > A git repository can be mainly in two states (Iâm not being really > accurate here, just simplifying the explanation). > - youâre working on a branch, and thus commit, merge and other operations > will affect the current branch > - youâre working on a commit, outside of a branch. In this case some > operations do not work, others will work but with different semantics. The > thing that is clear is that operations do not affect any branch. > > To understand it a bit better: there is a git variable called HEAD which > points to the current commitish we are working on. > A git repository is said to be in `Detached HEAD` when HEAD does point to > a commitish other than a branch. > > To put in in bare command-line git, in general youâll see that HEAD points > to a branch, mostly when we clone a fresh repository, or when we `checkout` > a branch: > > ``` > $ git checkout myBranch > ``` > > However, when checking out a tag or a commit, HEAD points respectively to > the commit referenced by the tag (recursivelyâ¦) or to the checked out > commit. > > ``` > $ git checkout tagV1.0 > > or > > $ git checkout abcd123 > ``` > > This happens in your scenario because the project youâre loading has some > dependency that has a version corresponding to a tag. > Detached HEAD does not mean your repository is broken, it means that to > work properly you need to check out a branch. > > > Now, letâs imagine we decide to do a tool that automatically leaves you in > the âcorrect branchâ to avoid Detached HEAD state, the reality is that it > is no straight forward. > > Case 1) Take the simple case where the tagged commit is referenced > directly by two branches. > There is no good automatic way to decide which branch is the good one > without knowing the intentions of the user, or the conventions of the > projectâ¦ > Even creating an automatic branch may not be what the user wanted... > > Case 2) Still simple but even more complicated: the two branches have > diverged from the tagged commit. > The tagged commit is in the history of both branches, and there is no good > automatic way to determine which branch is the good. > They are actually both equally good. > And even more dangerous, if we silently checkout one of the branches, we > may be checking out a version that does not work! > > How to leave the status looking good as "Up to dateâ? > > > Well, usually you have nothing to do. First thing to understand is that in > git there is not such thing as "Up to dateâ. > The best you can do is to say that > > [a branch] is up to date [with respect to a remote repository] > > Which means that a particular branch has everything from that specific > remote repository. > But > * maybe there is another repository that has more commits (typical case > of forks in github for example) > * while there could be in your repository a branch that is up to date, > other branches may not. > > Now, I understand that you want to âupdate your projectâ to the latest > version. > Looking at the graph in Case 2 above, what you need to do is to checkout > the correct branch. > The selection of the correct branch would depend on the decisions of the > developer, or the conventions of the community. > Right now we have no such conventions, and even if we had them, we should > give some alternative for those who donât want to strictly follow them. > > > > Here is a case example... > To avoid the a Filetree repo "filename too long" error on Windows, > I pre-cloned the repo to specify s shorter path name... > Repositories > Add > Clone from github.com > Owner: dionisiydk > Project name: Mocketry > Local directory: C:\Temp\Mocketry > Protocol: SSH > > Then in Playground evaluated... > Metacello new > baseline: 'Mocketry'; > repository: 'github://dionisiydk/Mocketry'; > load > > This cascade loaded Ghost and StateSpecs repos leaving them > with a status of "Detached HEAD". > What does this mean? > And how to have these load cleanly so they are left "Up to dateâ ? > > > Hope I answered those questions :). > If not, keep asking! > > Cheers, > Guille > got it. Thx Guille. I knew what Detached head was but not its behavior in relation to checking out tags. I found more info... https://stackoverflow.com/questions/5582208/checking-out-git-tag-leads-to-d… https://git-scm.com/book/en/v2/Git-Basics-Tagging Now I agree we don't want the system to be trying to decide which branch1 or branch2 to select, but what would be nice is when a tag v0.2 was checked out, a new branch "Branched-from-v0.2" was created for that commit. This could have two benefits: 1. It requires extra experience to know what "Detached HEAD" means. Now this is more Git issue rather Iceberg, but it "feels" like an error (and is the sort of thing to make French royalty nervous). A quick google skim indicates that you can lose commits with a Detached HEAD - by changing to another branch. Maybe Iceberg could have some guards against that, but I still carry that sense of foreboding looking at it. So avoiding a detached state is nicer 2. The Repository list would record which versions of packages were chain loaded by Metacello. cheers -ben

May 14, 2019

[Pharo 8.0] Build #271: 2272-Spec-Model-classes-still-contains-extensions

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

There is a new Pharo build available! The status of the build #271 was: SUCCESS. The Pull Request #3346 was integrated: "2272-Spec-Model-classes-still-contains-extensions" Pull request url: https://github.com/pharo-project/pharo/pull/3346 Issue Url: https://github.com/pharo-project/pharo/issues/2272 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 14, 2019

Re: [Pharo-dev] Metacello/Iceberg detached head of cascade loaded requirements

by Guillermo Polito

Hi Ben, Iâll complement a bit Gabrielâs answer. See inline > El 11 may 2019, a las 10:39, Ben Coman <btc(a)openinworld.com> escribiÃ³: > > I have a query about "Detached HEAD" status after a Metacello/Iceberg > cascade load of required packages. Starting with the general questions... > Is that a common status for this scenario? Yes. A git repository can be mainly in two states (Iâm not being really accurate here, just simplifying the explanation). - youâre working on a branch, and thus commit, merge and other operations will affect the current branch - youâre working on a commit, outside of a branch. In this case some operations do not work, others will work but with different semantics. The thing that is clear is that operations do not affect any branch. To understand it a bit better: there is a git variable called HEAD which points to the current commitish we are working on. A git repository is said to be in `Detached HEAD` when HEAD does point to a commitish other than a branch. To put in in bare command-line git, in general youâll see that HEAD points to a branch, mostly when we clone a fresh repository, or when we `checkout` a branch: ``` $ git checkout myBranch ``` However, when checking out a tag or a commit, HEAD points respectively to the commit referenced by the tag (recursivelyâ¦) or to the checked out commit. ``` $ git checkout tagV1.0 or $ git checkout abcd123 ``` This happens in your scenario because the project youâre loading has some dependency that has a version corresponding to a tag. Detached HEAD does not mean your repository is broken, it means that to work properly you need to check out a branch. Now, letâs imagine we decide to do a tool that automatically leaves you in the âcorrect branchâ to avoid Detached HEAD state, the reality is that it is no straight forward. Case 1) Take the simple case where the tagged commit is referenced directly by two branches. There is no good automatic way to decide which branch is the good one without knowing the intentions of the user, or the conventions of the projectâ¦ Even creating an automatic branch may not be what the user wanted... Case 2) Still simple but even more complicated: the two branches have diverged from the tagged commit. The tagged commit is in the history of both branches, and there is no good automatic way to determine which branch is the good. They are actually both equally good. And even more dangerous, if we silently checkout one of the branches, we may be checking out a version that does not work! > How to leave the status looking good as "Up to dateâ? Well, usually you have nothing to do. First thing to understand is that in git there is not such thing as "Up to dateâ. The best you can do is to say that [a branch] is up to date [with respect to a remote repository] Which means that a particular branch has everything from that specific remote repository. But * maybe there is another repository that has more commits (typical case of forks in github for example) * while there could be in your repository a branch that is up to date, other branches may not. Now, I understand that you want to âupdate your projectâ to the latest version. Looking at the graph in Case 2 above, what you need to do is to checkout the correct branch. The selection of the correct branch would depend on the decisions of the developer, or the conventions of the community. Right now we have no such conventions, and even if we had them, we should give some alternative for those who donât want to strictly follow them. > > Here is a case example... > To avoid the a Filetree repo "filename too long" error on Windows, > I pre-cloned the repo to specify s shorter path name... > Repositories > Add > Clone from github.com > Owner: dionisiydk > Project name: Mocketry > Local directory: C:\Temp\Mocketry > Protocol: SSH > > Then in Playground evaluated... > Metacello new > baseline: 'Mocketry'; > repository: 'github://dionisiydk/Mocketry'; > load > > This cascade loaded Ghost and StateSpecs repos leaving them > with a status of "Detached HEAD". > What does this mean? > And how to have these load cleanly so they are left "Up to dateâ ? Hope I answered those questions :). If not, keep asking! Cheers, Guille

May 14, 2019

Need help to help newbies on discord mooc channel

by ducasse

May 13, 2019