- Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #711: 4521-Adding-some-comments-to-compiler-methods

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

There is a new Pharo build available! The status of the build #711 was: FAILURE. The Pull Request #4522 was integrated: "4521-Adding-some-comments-to-compiler-methods" Pull request url: https://github.com/pharo-project/pharo/pull/4522 Issue Url: https://github.com/pharo-project/pharo/issues/4521 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 8, 2019

Re: [Pharo-dev] Slot definition API?

by ducasse

> On 8 Sep 2019, at 18:30, ducasse <stepharo(a)netcourrier.com> wrote: > > Iâm thinking that I should subclass RBMessageNode to have RBSlotInitializationNode So now Iâm creating RBSlotInitializationNode as a subclass of the superclass of MessageNode because it felt too much as a bad subclassing practice. > > Ideally I have the impression that it would be nice to have RBNoReceiverMessageNode as a subclass or RBMessageNode. > This way we could also simplify the logic of cascade :) - but this is another story. > > Stef >

Sept. 8, 2019

Re: [Pharo-dev] possible Windows Update "1903" Iceberg problem

by ducasse

> On 8 Sep 2019, at 05:26, Christopher Fuhrman <christopher.fuhrman(a)etsmtl.ca <mailto:christopher.fuhrman@etsmtl.ca>> wrote: > > I can also confirm that Iceberg via SSH was crashing on my Windows 1903 update, the funny thing is that we could not install 1903 on our PCs because Inria did not validate 1903 as a valid update :) > and putting those DLLs in Documents\Pharo\vms\80-x64 allows Iceberg to work without a VM crash. > > I did not test on 70-x64. > > Good work! > > On Thu, 5 Sep 2019 at 10:02, Christopher Fuhrman <christopher.fuhrman(a)etsmtl.ca <mailto:christopher.fuhrman@etsmtl.ca>> wrote: > This sounds great, Pablo. > > Just to clarify on how to test, if I'm using Pharo Launcher, do I just replace the .dll files from your .zip in C:\Users\{me}\Documents\Pharo\vms\80-x64 (and/or \70-x64)? > > On Thu, 5 Sep 2019 at 09:34, tesonep(a)gmail.com <mailto:tesonep@gmail.com> <tesonep(a)gmail.com <mailto:tesonep@gmail.com>> wrote: > Hi all, > with Guille we have been working in this issue since Monday, it > was a complicated issue to solve as we require to compile and test > different versions of the libgit2 library and its dependencies > (openssl and libssh2). > We have a workaround for using ssh in windows. > We have produced a new set of libraries with the correct versions. > These libraries are available in > https://drive.google.com/open?id=1fwAVyrEEXkGOAuyAh1wASRRSv3SjZ3R1 <https://drive.google.com/open?id=1fwAVyrEEXkGOAuyAh1wASRRSv3SjZ3R1> > The idea is to start testing them while we are working on a new > release of the VM. > > Cheers, > Pablo > > On Wed, Sep 4, 2019 at 10:05 AM Guillermo Polito > <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > > > > Hi all, > > > > Sorry for not communicating better :). > > We know this is an important issue and we did move it to top priority even prior to this email ;). > > Doru, to answer you, what people can do for the moment is to test what we are going to propose in a couple of hours in your windows machines. > > With Pablo we have tested in several Windows 10 machines pre- and post- update 1903. Still we would like people testing on their setups and other windows versions > > > > We have been working the last couple of days debugging openssh and libgit, and building a version with a more up-to-date version of openssh. > > We will come back later this morning / early afternoon with > > - a new vm setup using up to date versions of openssh > > - a description of workarounds for those tied to old versions of the VM > > So people can test. > > > > Cheers, > > Guille and Pablo > > > > > El 4 sept 2019, a las 8:38, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> escribiÃ³: > > > > > > I saw everybody super busy and I imagine that they will reply soon. > > > Iâm travelling to give Pharo lectures. > > > > > >> On 3 Sep 2019, at 19:23, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: > > >> > > >> Hi, > > >> > > >> Is there a way to speed the work on this one? > > >> > > >> At this moment, people cannot load any code in Pharo on Windows 10. > > >> > > >> Cheers, > > >> Doru > > >> > > >> -- > > >> www.feenk.com <http://www.feenk.com/> > > >> "Every thing has its own flow." > > >> > > >>> On 28 Aug 2019, at 16:20, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: > > >>> > > >>> tx doru > > >>> > > >>> Stef > > >>> > > >>>> On 28 Aug 2019, at 16:01, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: > > >>>> > > >>>> Hi > > >>>> > > >>>> I opened an issue: https://github.com/pharo-project/pharo/issues/4437 <https://github.com/pharo-project/pharo/issues/4437> > > >>>> > > >>>> I believe this should be treated as critical given that we cannot load code in Pharo 7 (or 8) which makes it almost useless for users. > > >>>> > > >>>> Cheers, > > >>>> Doru > > >>>> > > >>>> > > >>>>> On Aug 27, 2019, at 10:54 AM, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> We just encountered this on two different machines. We got this after the update to Windows 1903. For us itâs a critical issue at this point. What can we do to help with this? > > >>>>> > > >>>>> Cheers, > > >>>>> Doru > > >>>>> > > >>>>> > > >>>>> > > >>>>>> On Aug 17, 2019, at 12:50 PM, Ben Coman <btc(a)openInWorld.com <mailto:btc@openInWorld.com>> wrote: > > >>>>>> > > >>>>>> hi Stef, > > >>>>>> I feel you missed my point. Probably I wasn't clear this has already been tested with latest Pharo 8 launched by PharoLauncher. > > >>>>>> The problem occurs with Pharo 7.0.3(64 bit) and with Pharo8.0-SNAPSHOT-build.635(64 bit) > > >>>>>> after Microsoft Windows Update 1903... > > >>>>>> https://www.computerworld.com/article/3409621/microsoft-starts-windows-10s-… <https://www.computerworld.com/article/3409621/microsoft-starts-windows-10s-…> > > >>>>>> > > >>>>>> If indeed 1903 is the cause, with this update now being *forced* down on people, this will potentially soon impact more and more Windows users. > > >>>>>> But my guess that 1903 is the culprit needs to be confirmed. > > >>>>>> So I am requesting someone with access to multiple Windows machines directly compare a 1903 machine with a pre-1903 machine. > > >>>>>> > > >>>>>> cheers -ben > > >>>>>> > > >>>>>> On Sat, 17 Aug 2019 at 12:58, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: > > >>>>>> Hi ben > > >>>>>> > > >>>>>> in the pharo launcher if you click on P8.0 (development version) you get access to all the builds. > > >>>>>> > > >>>>>> Stef > > >>>>>> > > >>>>>>> On 16 Aug 2019, at 16:02, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > > >>>>>>> > > >>>>>>> IThis morning the May 2019 Windows Update "1903" forced itself onto my computer and now 64-bits Pharo seems to have a problem with git_remote_fetch() FFI callout. I no longer have a non-1903 machine to directly compare behaviour before "1903". Can someone familiar with this area with both "pre-1903" and "1903" machines triage whether "1903" is indeed the cause? > > >>>>>>> > > >>>>>>> A few other recent reports are noted here... > > >>>>>>> https://github.com/pharo-project/pharo/issues/3418 <https://github.com/pharo-project/pharo/issues/3418> > > >>>>>>> > > >>>>>>> cheers -ben > > >>>>>> > > >>>>> > > >>>>> -- > > >>>>> feenk.com <http://feenk.com/> > > >>>>> > > >>>>> "Not knowing how to do something is not an argument for how it cannot be done." > > >>>>> > > >>>> > > >>>> -- > > >>>> feenk.com <http://feenk.com/> > > >>>> > > >>>> âLive like you mean it." > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >> > > > > > > > > > > > > > > > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com> > > > > -- > Christopher Fuhrman, P.Eng., PhD > Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'information > ÃTS (Ãcole de technologie supÃ©rieure) > > http://profs.etsmtl.ca/cfuhrman <http://profs.etsmtl.ca/cfuhrman> > +1 514 396 8638 > L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec > > > -- > Christopher Fuhrman, P.Eng., PhD > Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'information > ÃTS (Ãcole de technologie supÃ©rieure) > > http://profs.etsmtl.ca/cfuhrman <http://profs.etsmtl.ca/cfuhrman> > +1 514 396 8638 > L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec

Sept. 8, 2019

Re: [Pharo-dev] Slot definition API?

by ducasse

Iâm thinking that I should subclass RBMessageNode to have RBSlotInitializationNode Ideally I have the impression that it would be nice to have RBNoReceiverMessageNode as a subclass or RBMessageNode. This way we could also simplify the logic of cascade :) - but this is another story. Stef

Sept. 8, 2019

Re: [Pharo-dev] Slot definition API?

by ducasse

>> >> Right now I return a symbol instead of the class but I could return a class. >> Now I would like to avoid to blindly think that we have a single namespace. >> So returning a class implies to be sure that the definition is parsed in the same environment >> than the class it refers and to me this is a constraint I do not like. >> So I will return a symbol. >> Let me know what you think. > > maybe #slotClassName instead of #slotClass? Yes I will rename typeName > Iâm not against the symbol... > >> >>> slotDefinition(1) initializationMessage >>> >>> 'default: 5â >>> or better >>> >>> Node(default: 5) if it exist >> >> Now I do not know what to do: because I can create a message with an empty receiver. >> Because > > Two simple solutions that come to my mind > 1) âinstVar3â generates a CDSlotNode with a default #slotClassName = #InstanceVariableSlot (I like this solution the less because it hardcodes in the parser knowledge about the runtime) Yes I did this. > 2) we have two different nodes (becase they have different syntax) CDSlotNode and CDDefaultSlotNode and DefaultSlotNode does not have a class name and should be visited differently. Yes. I was wondering what would be initializationMessage part of a normal slot. And may be having these two can solve the problem. I do not like to put a nil or #() in the initializeMessage (and I was thinking that I would need a NullMessage but this is not nice. So Iâm thinking that having two different nodes may be good now I do not know what to do for the initializeMessage (if it would be an action I would do nothing) > >>> >>> S.

Sept. 8, 2019

Re: [Pharo-dev] Slot definition API?

by Guillermo Polito

> El 8 sept 2019, a las 17:59, ducasse <stepharo(a)netcourrier.com> escribiÃ³: > > > >> On 8 Sep 2019, at 09:17, ducasse <stepharo(a)netcourrier.com> wrote: >> >> Hi >> >> Iâm fixing the class definition parser and I have a question. >> >> Iâm stabilizing the API of CDSlotNode >> >> >> 1 âfirst' => LazyClassVariable default: 5. >> 2 âsecond' => InstanceVariableSlot. >> 3 âinstVar3â >> >> Here is a proposal >> >> slotdefinition(3) name ? variable name >> >>> âinstVar3' >> >> slotDefinition(2) slotClass? >> >>> InstanceVariableSlot > > Right now I return a symbol instead of the class but I could return a class. > Now I would like to avoid to blindly think that we have a single namespace. > So returning a class implies to be sure that the definition is parsed in the same environment > than the class it refers and to me this is a constraint I do not like. > So I will return a symbol. > Let me know what you think. maybe #slotClassName instead of #slotClass? Iâm not against the symbol... > >> slotDefinition(1) initializationMessage >> >>> 'default: 5â >> or better >> >>> Node(default: 5) if it exist > > Now I do not know what to do: because I can create a message with an empty receiver. > Because Two simple solutions that come to my mind 1) âinstVar3â generates a CDSlotNode with a default #slotClassName = #InstanceVariableSlot (I like this solution the less because it hardcodes in the parser knowledge about the runtime) 2) we have two different nodes (becase they have different syntax) CDSlotNode and CDDefaultSlotNode and DefaultSlotNode does not have a class name and should be visited differently. >> >> S.

Sept. 8, 2019

Re: [Pharo-dev] Slot definition API?

by ducasse

> On 8 Sep 2019, at 09:17, ducasse <stepharo(a)netcourrier.com> wrote: > > Hi > > Iâm fixing the class definition parser and I have a question. > > Iâm stabilizing the API of CDSlotNode > > > 1 âfirst' => LazyClassVariable default: 5. > 2 âsecond' => InstanceVariableSlot. > 3 âinstVar3â > > Here is a proposal > > slotdefinition(3) name ? variable name > >>> âinstVar3' > > slotDefinition(2) slotClass? > >>> InstanceVariableSlot Right now I return a symbol instead of the class but I could return a class. Now I would like to avoid to blindly think that we have a single namespace. So returning a class implies to be sure that the definition is parsed in the same environment than the class it refers and to me this is a constraint I do not like. So I will return a symbol. Let me know what you think. > slotDefinition(1) initializationMessage > >>> 'default: 5â > or better > >>> Node(default: 5) if it exist Now I do not know what to do: because I can create a message with an empty receiver. Because > > S. > > >

Sept. 8, 2019

Re: [Pharo-dev] Slot definition API?

by Guillermo Polito

> El 8 sept 2019, a las 17:55, ducasse <stepharo(a)netcourrier.com> escribiÃ³: > > > >> On 8 Sep 2019, at 10:15, tesonep(a)gmail.com <mailto:tesonep@gmail.com> wrote: >> >> Hi, I really like the idea of returning a node object for the initialization. >> From seeing the class definition, I think we should assume that: >> >> - the receiver of the slot instantiation message is a Slot. >> - the parameters to the slot instatiation message are literals or literal-only expressions. >> >> Do you think that these assumptions / constraints are cool / enough? > > I had the same :) > Now I wondered if allowing a block would make sense. If you need behaviour specific for your domain, you can always create a subclass of slot and redefine read: and write:, ++ you donât need a block :D ++ it makes it super explicit youâre doing some magic > But it automatically raises the evaluation environment so I would prefer not. > >> Cheers. >> >> On Sun, 8 Sep 2019, 09:41 ducasse, <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: >> Hi >> >> Iâm fixing the class definition parser and I have a question. >> >> Iâm stabilizing the API of CDSlotNode >> >> >> 1 âfirst' => LazyClassVariable default: 5. >> 2 âsecond' => InstanceVariableSlot. >> 3 âinstVar3â >> >> Here is a proposal >> >> slotdefinition(3) name ? variable name >> >>> âinstVar3' >> >> slotDefinition(2) slotClass? >> >>> InstanceVariableSlot >> >> slotDefinition(1) initializationMessage >> >>> 'default: 5â >> or better >> >>> Node(default: 5) if it exist >> >> S. >> >> >> >

Sept. 8, 2019

Re: [Pharo-dev] Slot definition API?

by ducasse

> On 8 Sep 2019, at 10:15, tesonep(a)gmail.com wrote: > > Hi, I really like the idea of returning a node object for the initialization. > From seeing the class definition, I think we should assume that: > > - the receiver of the slot instantiation message is a Slot. > - the parameters to the slot instatiation message are literals or literal-only expressions. > > Do you think that these assumptions / constraints are cool / enough? I had the same :) Now I wondered if allowing a block would make sense. But it automatically raises the evaluation environment so I would prefer not. > Cheers. > > On Sun, 8 Sep 2019, 09:41 ducasse, <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: > Hi > > Iâm fixing the class definition parser and I have a question. > > Iâm stabilizing the API of CDSlotNode > > > 1 âfirst' => LazyClassVariable default: 5. > 2 âsecond' => InstanceVariableSlot. > 3 âinstVar3â > > Here is a proposal > > slotdefinition(3) name ? variable name > >>> âinstVar3' > > slotDefinition(2) slotClass? > >>> InstanceVariableSlot > > slotDefinition(1) initializationMessage > >>> 'default: 5â > or better > >>> Node(default: 5) if it exist > > S. > > >

Sept. 8, 2019

Re: [Pharo-dev] Step by step contribute

by ducasse

> On 8 Sep 2019, at 14:22, Hilaire <hilaire(a)drgeo.eu> wrote: > > hum, with some sort of luck I got it working as it should and in the > process understood a bit the workflow. the workflow is your fork pharo then iceberg will clone you also commit to your working copy when you are in trouble select repair the items are sorted in order of use probability you commit commit commit to your working copy then push to your fork then PR from your fork to pharo remote > In the tutorial, a few words explaining it could be useful to git > newbies as me. > > Hilaire > > Le 08/09/2019 Ã 14:12, Hilaire a Ã©crit : >> What should I do now? > > -- > Dr. Geo > http://drgeo.eu > > >

Sept. 8, 2019