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

Re: [Pharo-dev] Slot definition API?

by Torsten Bergmann

Hi, I'm not too deep in the CDSlotNode and related - but I wonder why we need the specific #=> selector and slotName => Definition mapping form in the definition at all. What are the benefits of the additional "=>" style ? To me it looks not very natural to write: #id => InstanceVariable. or other specific forms. The custom subclasses of class "Slot" are already inheriting the "name" iVar for the slotName. So using the additional slotName in the definition is - disrupting the slot name from other arguments - redundant if the slot creation should have the name as well Why not use just the plain slot object by creating it directly with a class message? We can just use custom class side instantiation methods for the slots including the name like #named: #named:type: #named:type:default: ... or other. I mean #=> dispatches to #named: on the slot anyway. If we define the class / slot objects like this: Object subclass: #MyTask slots: { BOInstanceVariableSlot named: #'id'. #anotherIVar. BOTypedSlot named: #'description' type: String. BOAttributeSlot named: #'isDone' type: Boolean default: true. BOAttributeSlot named: #'created' type: Date default: [ Date today ] } classVariables: { } package: 'CustomSlots-Definitions-Examples' is more natural than the => forms where the name is just disrupted from the other arguments. The attached file out from a Pharo 8 example demonstrates this. Just file it in and have a look at class MyTask or inspect "MyTask new created" or "MyTask new created: 2" to see that the implemented simple slot typing and defaults are working. Then look at the definition of #MyTask class, which looks like written above. It could be made even more readable using Object subclass: #MyTaskEvenEasier slots: { BOAttributeSlot named: #'id'. BOAttributeSlot named: #'anotherIVar'. BOAttributeSlot named: #'description' type: String. BOAttributeSlot named: #'isDone' type: Boolean default: true. BOAttributeSlot named: #'created' type: Date default: [ Date today ] } classVariables: { } package: 'CustomSlots-Definitions-Examples' only. The benefits without the => indirection are: - a simple, compact and easy readable class definition even when slots are used - slot definitions are regular messages to the slot class - simply evaluate or inspect the full slot class side message - we keep the possibility to mix slots with other instance variables (here #anotherIVar in the example by using the symbol) - we keep the possibility to evaluate the full slots definition and check the array of their definition - we unify the definition with the "MyClass slots" message - as both are just return the array of slot objects - we do not rely on an additional specific definition API one has to remember So where is the real value in the often used additional indirection of the => message in slot definitions? Thanks T.

Sept. 8, 2019

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

by Tudor Girba

> On Sep 8, 2019, at 6:31 PM, ducasse <stepharo(a)netcourrier.com> wrote: > > > >> On 8 Sep 2019, at 05:26, Christopher Fuhrman <christopher.fuhrman(a)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 :) This is funny, indeed :) Doru >> 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> 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 <tesonep(a)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 >> 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> 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> 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> 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 >> > >> "Every thing has its own flow." >> > >> >> > >>> On 28 Aug 2019, at 16:20, ducasse <stepharo(a)netcourrier.com> wrote: >> > >>> >> > >>> tx doru >> > >>> >> > >>> Stef >> > >>> >> > >>>> On 28 Aug 2019, at 16:01, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> > >>>> >> > >>>> Hi >> > >>>> >> > >>>> I opened an issue: 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> 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> 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-… >> > >>>>>> >> > >>>>>> 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> 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> 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 >> > >>>>>>> >> > >>>>>>> cheers -ben >> > >>>>>> >> > >>>>> >> > >>>>> -- >> > >>>>> feenk.com >> > >>>>> >> > >>>>> "Not knowing how to do something is not an argument for how it cannot be done." >> > >>>>> >> > >>>> >> > >>>> -- >> > >>>> feenk.com >> > >>>> >> > >>>> âLive like you mean it." >> > >>>> >> > >>>> >> > >>> >> > >>> >> > >>> >> > >> >> > > >> > > >> > > >> > >> > >> >> >> -- >> Pablo Tesone. >> tesonep(a)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 >> +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 >> +1 514 396 8638 >> L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec > -- feenk.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

Sept. 8, 2019

[Pharo 8.0] Build #712: 4497-humanReadablePrintString

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

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

Sept. 8, 2019

[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