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

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

by Torsten Bergmann

After some testing on two machines with "1903" Win update and loading of different projects with 64bit images I can also confirm that it is working without any visible side effect. As several windows users confirmed I guess it can be used in offical VM bundle, launcher, etc. now. Super cool + Big thanks! Bye T.

Sept. 9, 2019

Re: [Pharo-dev] Slot definition API?

by ducasse

> Anyhow - we can only experiment when https://github.com/MarcusDenker/SlotComposition moves on and > becomes part of the imageâ¦ No if we decide that composed traits should be defined prior to class definition. Marcus will have all the freedom to work on slot composition without breaking the tools. And we can have a simple synatx for slots and use it. Stef

Sept. 9, 2019

Re: [Pharo-dev] Slot definition API?

by ducasse

I would really like a solution that does not change the syntax. Why we cannot have a slot defined before the class use. Like I defined my LazySlot class and after in the class definition I just write LazySlot named: âsomeIVarâ Like that the syntax stays under control. I do not really get why the composition should be done in the class definition. We can have composedSlots at the level of slots without having to define them within the class definition. I think that composing a slot property should be more exceptional than the normal business. So why can we have a library of slots that use composition without having it mixed inside the class definition. Could we keep things simple? >> 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. > > Yes - would like to see them in as quickly as possible - but I fear they need more work from your side which > is time and prio related as always. > > ComposedSlots can make things easier and allow to better control the different variations. > > Compositions will change how things can be composed together. But for the definition I guess we still > have to decide for either > - either for the "=>" approach > - the plain objects approach > > > For compositions the => syntax would allow to just write the class name if there are no parameters for the slot: > > { âsomeIVar' => InstanceVariableSlot + LazySlot } > > > But using the "just objects" approach one could would make it look like: > > { (InstanceVariableSlot named: 'someIVar') + LazySlot new } > > When "+" is implemented also on instance side for composing one could even have: > > { (InstanceVariableSlot named: 'someIVar') + LazySlot } > > or { LazySlot + (InstanceVariableSlot named: 'someIVar') } > to stay symmetric. > > It would also allow for: > > { ComposableSlot for: 'someIVar' using: LazySlot } "assuming that an InstanceVariableSlot is always in > > or > > { ComposableSlot for: 'someIVar' with: LazySlot new } "if one uses an existing slot instance" > > Anyhow - we can only experiment when https://github.com/MarcusDenker/SlotComposition moves on and > becomes part of the image... > > Bye > T. > > > >

Sept. 9, 2019

Re: [Pharo-dev] Slot definition API?

by Torsten Bergmann

> 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. Yes - would like to see them in as quickly as possible - but I fear they need more work from your side which is time and prio related as always. ComposedSlots can make things easier and allow to better control the different variations. Compositions will change how things can be composed together. But for the definition I guess we still have to decide for either - either for the "=>" approach - the plain objects approach For compositions the => syntax would allow to just write the class name if there are no parameters for the slot: { âsomeIVar' => InstanceVariableSlot + LazySlot } But using the "just objects" approach one could would make it look like: { (InstanceVariableSlot named: 'someIVar') + LazySlot new } When "+" is implemented also on instance side for composing one could even have: { (InstanceVariableSlot named: 'someIVar') + LazySlot } or { LazySlot + (InstanceVariableSlot named: 'someIVar') } to stay symmetric. It would also allow for: { ComposableSlot for: 'someIVar' using: LazySlot } "assuming that an InstanceVariableSlot is always in or { ComposableSlot for: 'someIVar' with: LazySlot new } "if one uses an existing slot instance" Anyhow - we can only experiment when https://github.com/MarcusDenker/SlotComposition moves on and becomes part of the image... Bye T.

Sept. 9, 2019

[Pharo 8.0] Build #716: Fonts-should-not-depend-on-deprecated-file-streams

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

There is a new Pharo build available! The status of the build #716 was: SUCCESS. The Pull Request #4343 was integrated: "Fonts-should-not-depend-on-deprecated-file-streams" Pull request url: https://github.com/pharo-project/pharo/pull/4343 Issue Url: https://github.com/pharo-project/pharo/issues/Fonts 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

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. > 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

[Pharo 8.0] Build #715: SlotDefTests

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

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

Sept. 9, 2019

[Pharo 8.0] Build #714: 4480-Fix-Typos-in-BooleanSlot-class-comment

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

There is a new Pharo build available! The status of the build #714 was: FAILURE. The Pull Request #4526 was integrated: "4480-Fix-Typos-in-BooleanSlot-class-comment" Pull request url: https://github.com/pharo-project/pharo/pull/4526 Issue Url: https://github.com/pharo-project/pharo/issues/4480 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 9, 2019

[Pharo 8.0] Build #713: 4524-Typo-wantsInitalization---wantsInitialization

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

There is a new Pharo build available! The status of the build #713 was: SUCCESS. The Pull Request #4525 was integrated: "4524-Typo-wantsInitalization---wantsInitialization" Pull request url: https://github.com/pharo-project/pharo/pull/4525 Issue Url: https://github.com/pharo-project/pharo/issues/4524 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 ducasse

Good question. I will let marcus answer. Iâm just the guy that makes sure that the AST behind class definition is working. I prefer your solution because it is easier since I do not have to make AST transformation :). S. > On 8 Sep 2019, at 23:48, Torsten Bergmann <astares(a)gmx.de> wrote: > > 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. > <CustomSlots-Definitions.st>

Sept. 9, 2019