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

[Pharo 8.0] Build #562: Fix recently-introduced portability problems
by ci-pharo-ci-jenkins2＠inria.fr July 25, 2019

July 25, 2019

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

1 0

[Pharo 7.0] Build #166: BackPort Pharo7: Moved becomeForward from Object to ProtoObject where it belongs
by ci-pharo-ci-jenkins2＠inria.fr July 24, 2019

July 24, 2019

There is a new Pharo build available! The status of the build #166 was: FAILURE. The Pull Request #4084 was integrated: "BackPort Pharo7: Moved becomeForward from Object to ProtoObject where it belongs" Pull request url: https://github.com/pharo-project/pharo/pull/4084 Issue Url: https://pharo.fogbugz.com/f/cases/Pharo7.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Menu missing translation rule
by Cyril Ferlicot July 24, 2019

July 24, 2019

Hi, I usually get really annoyed by the "Menu missing translation" rule because it has a huge false positive rate. I am the only one get many false positives? Does it make sense to keep this rule? What do you think? If all menus should be translated, maybe it's the menu itself that should send #translate to the argument. -- Cyril Ferlicot https://ferlicot.fr

2 1

[Pharo 8.0] Build #561: move setModel: out of completionAround:keyStroke:
by ci-pharo-ci-jenkins2＠inria.fr July 24, 2019

July 24, 2019

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

1 0

[Pharo 8.0] Build #560: Fix typo : annoucement => announcement
by ci-pharo-ci-jenkins2＠inria.fr July 24, 2019

July 24, 2019

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

1 0

[Pharo 8.0] Build #559: Add tests for LargePositiveInteger&LargeNegativeInteger from last version of Squeak
by ci-pharo-ci-jenkins2＠inria.fr July 24, 2019

July 24, 2019

There is a new Pharo build available! The status of the build #559 was: SUCCESS. The Pull Request #4081 was integrated: "Add tests for LargePositiveInteger&LargeNegativeInteger from last version of Squeak" Pull request url: https://github.com/pharo-project/pharo/pull/4081 Issue Url: https://github.com/pharo-project/pharo/issues/clean Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #558: 2341-memory-leak-through-NECController-uniqueInstance
by ci-pharo-ci-jenkins2＠inria.fr July 24, 2019

July 24, 2019

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

1 0

[Pharo 8.0] Build #557: Deprecate-PluggableTextMorph-and-subclasses
by ci-pharo-ci-jenkins2＠inria.fr July 24, 2019

July 24, 2019

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

1 0

P8 + aTalent - aKind
by Norbert Hartl July 24, 2019

July 24, 2019

Iâm playing again with Talents and I want that in Pharo8 to appear so it can mature. I want to discuss a few things Iâm not clear about in order to help steering the talents in the right direction. I think Talents do not properly separate concerns. If you add a talent to an object each object gets its own anonymous class with its own method dictionary. To me this is two things at the same time. One use case I want is âruntime traitsâ. It means that you can add a trait at runtime to an object which acquires the functionality. But all objects of the same class + talent should share the same anonymous subclass. This would be possible in a performant way if I only want behavioral flexibility. It is just one more class per use case. A second step is âobject-centric behaviourâ which finally privatizes the method dictionary to one object making object-centric logging/debugging/â¦ possible. This is somewhat expensive but for object centric logging/debugging/â¦ there will be only a small amount of objects being extended. With Traits and now with Talents we need to rethink parts of the reflection API. We have #isKindOf: and #includesBehavior: which are not properly aligned at the moment [1] and for talents it gets even wrong. I think we need a definition what is a kind. What it means to include a behavior I find more straight forward. I used a few test classes Object subclass: #ContainsNoTrait instanceVariableNames: '' classVariableNames: '' package: 'Talents-Testâ Object subclass: #ContainsOneTrait uses: Doable instanceVariableNames: '' classVariableNames: '' package: 'Talents-Testâ Object subclass: #ContainsTwoTraits uses: Doable + Doable2 instanceVariableNames: '' classVariableNames: '' package: 'Talents-Testâ Trait named: #Doable uses: {} slots: { #status } package: 'Talents-Testâ Trait named: #Doable2 uses: {} slots: { #status2 } package: 'Talents-Testâ Code is attached. When I create instances of each noTrait := ContainsNoTrait new. oneTrait := ContainsOneTrait new. twoTraits := ContainsTwoTraits new. oneTalent := ContainsNoTrait new addTalent: Doable; yourself. twoTalents := ContainsNoTrait new addTalent: Doable + Doable2; yourself . and create a table of each behavior I get which doesnât look quite right. My opinion is that all of the #includesBehavior: calls should return true. Iâm not so sure about the #isKindOf: If we continue on that road the single class inheritance wonât be central to all of the code but a special quality. One of the composed elements can be a class with a superclass hierarchy. I donât know if there is a rationale that #includesBehavior: and #isKindOf: refer to that the same thing or not. It would be good to take the opportunity to make this a concept which gives back some symmetry again. Norbert [1] https://github.com/pharo-project/pharo/issues/3958 <https://github.com/pharo-project/pharo/issues/3958>

5 5

[Pharo 8.0] Build #556: Moved becomeForward from Object to ProtoObject where it belongs
by ci-pharo-ci-jenkins2＠inria.fr July 24, 2019

July 24, 2019

There is a new Pharo build available! The status of the build #556 was: SUCCESS. The Pull Request #4078 was integrated: "Moved becomeForward from Object to ProtoObject where it belongs" Pull request url: https://github.com/pharo-project/pharo/pull/4078 Issue Url: https://github.com/pharo-project/pharo/issues/4077 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0