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

Re: [Pharo-dev] Step by step contribute

by ducasse

> On 9 Sep 2019, at 18:39, Hilaire <hilaire(a)drgeo.eu> wrote: > > > Le 08/09/2019 Ã 14:29, ducasse a Ã©crit : >>> On 8 Sep 2019, at 14:22, Hilaire <hilaire(a)drgeo.eu <mailto:hilaire@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 > > Where? When you do repair. > My scenario is now: I want to resync my P8 installation with its remote > state, so I can work on some fixes. How to? When you "repair" your image, your repo is resync automatically. New commits from Pharo are pulled and when you push you push such changes too. I asked the same and in fact I never resync my fork explicitely since months. > >> >> 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 >>> >>> >>> >> >> > -- > Dr. Geo > http://drgeo.eu <http://drgeo.eu/>

Sept. 9, 2019

Re: [Pharo-dev] Slot definition API?

by ducasse

I would prefer that we discuss also because we need to have a design that suits us. I do not think Pharo will benefit to have a complex class definition. Stef > On 9 Sep 2019, at 17:20, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 9 Sep 2019, at 17:00, ducasse <stepharo(a)netcourrier.com> wrote: >> >> Marcus to me the point is that we should not rush this kind of things. >> What we should think is >> - freeze a syntax - I like the idea of guille to make sure that we cannot have any message in the slot >> - take the time to discuss the design, do code review, make sure that we have tests >> - to me a programmer should not compose slot property in the class definition. >> > > > I will finish it and then we can discuss. > > Marcus

Sept. 9, 2019

Re: [Pharo-dev] Step by step contribute

by Hilaire

Le 08/09/2019 Ã 14:29, ducasse a Ã©critÂ : >> 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 Where? My scenario is now: I want to resync my P8 installation with its remote state, so I can work on some fixes. How to? > > 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 >> >> >> > > -- Dr. Geo http://drgeo.eu

Sept. 9, 2019

Re: [Pharo-dev] Slot definition API?

by Marcus Denker

> On 9 Sep 2019, at 17:00, ducasse <stepharo(a)netcourrier.com> wrote: > > Marcus to me the point is that we should not rush this kind of things. > What we should think is > - freeze a syntax - I like the idea of guille to make sure that we cannot have any message in the slot > - take the time to discuss the design, do code review, make sure that we have tests > - to me a programmer should not compose slot property in the class definition. > I will finish it and then we can discuss. Marcus

Sept. 9, 2019

Re: [Pharo-dev] Slot definition API?

by ducasse

Marcus to me the point is that we should not rush this kind of things. What we should think is - freeze a syntax - I like the idea of guille to make sure that we cannot have any message in the slot - take the time to discuss the design, do code review, make sure that we have tests - to me a programmer should not compose slot property in the class definition. Stef > On 9 Sep 2019, at 16:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 9 Sep 2019, at 16:03, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> >> >>> El 9 sept 2019, a las 9:57, Marcus Denker <marcus.denker(a)inria.fr> escribiÃ³: >>> >>> I will have a look, but I feel that we should first get the Composed Slots into the image >>> as they will change everything again. >> >> Marcus, how much time could it take you to have a mature version we can test and try? >> I'd avoid moving research experiments into the image before they have some maturityâ¦ >> > I am trying to block time to finish it till next weekâ¦ > > > Marcus > >

Sept. 9, 2019

[Pharo 8.0] Build #718: 4535-Is-there-a-reason-new-completion-does-not-use-RBProgramNodeVisitor

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

There is a new Pharo build available! The status of the build #718 was: SUCCESS. The Pull Request #4536 was integrated: "4535-Is-there-a-reason-new-completion-does-not-use-RBProgramNodeVisitor" Pull request url: https://github.com/pharo-project/pharo/pull/4536 Issue Url: https://github.com/pharo-project/pharo/issues/4535 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 9, 2019

Re: [Pharo-dev] Slot definition API?

by Marcus Denker

> On 9 Sep 2019, at 16:03, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > >> El 9 sept 2019, a las 9:57, Marcus Denker <marcus.denker(a)inria.fr> escribiÃ³: >> >> I will have a look, but I feel that we should first get the Composed Slots into the image >> as they will change everything again. > > Marcus, how much time could it take you to have a mature version we can test and try? > I'd avoid moving research experiments into the image before they have some maturityâ¦ > I am trying to block time to finish it till next weekâ¦ Marcus

Sept. 9, 2019

Re: [Pharo-dev] Slot definition API?

by Guillermo Polito

> El 9 sept 2019, a las 9:57, Marcus Denker <marcus.denker(a)inria.fr> escribiÃ³: > > I will have a look, but I feel that we should first get the Composed Slots into the image > as they will change everything again. Marcus, how much time could it take you to have a mature version we can test and try? I'd avoid moving research experiments into the image before they have some maturity... > > >> 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 >> >> slotDefinition(1) initializationMessage >> >>> 'default: 5â >> or better >> >>> Node(default: 5) if it exist >> >> S. >> >> >> > >

Sept. 9, 2019

Re: [Pharo-dev] Slot definition API?

by Guillermo Polito

ThÂ¡Â¡ > El 8 sept 2019, a las 23:48, Torsten Bergmann <astares(a)gmx.de> escribiÃ³: > > 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 To me there is a drawback on this: even though being a message send is actually more flexible, arbitrary messages can be hard to cope with by tools. For example, if we want to validate if a slot definition is valid before loading it (e.g., if its class exists), we need to identify the slot kind/class from that message send. The same happens with the slot name. If someone defines a slot as MySlot new name: #asd. or MySlot withName: #asd. tools will just be much harder to implement Although this can be helped by strong name conventions (i.e., always a slot definition is a message send, always the receiver is a class, always the first keyword is #named: ?, all args are literal). ^^ > > So where is the real value in the often used additional indirection of the => message in slot definitions? > > Thanks > T. > <CustomSlots-Definitions.st>

Sept. 9, 2019

[Pharo 8.0] Build #717: 4530-Auto-completion-fail-on-thisContext

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

There is a new Pharo build available! The status of the build #717 was: SUCCESS. The Pull Request #4531 was integrated: "4530-Auto-completion-fail-on-thisContext" Pull request url: https://github.com/pharo-project/pharo/pull/4531 Issue Url: https://github.com/pharo-project/pharo/issues/4530 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 9, 2019