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

[Pharo 8.0] Build #543: RubSmalltalkEditor #keystroke Simplify more

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

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

July 23, 2019

[Pharo 8.0] Build #542: 4045-RBSequenceNode-stop-does-not-take-temp-definitions-into-account

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

There is a new Pharo build available! The status of the build #542 was: SUCCESS. The Pull Request #4049 was integrated: "4045-RBSequenceNode-stop-does-not-take-temp-definitions-into-account" Pull request url: https://github.com/pharo-project/pharo/pull/4049 Issue Url: https://github.com/pharo-project/pharo/issues/4045 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 23, 2019

Re: [Pharo-dev] P8 + aTalent - aKind

by Norbert Hartl

Just if you wonder where this #includesTalent: method is. You can get it from here https://github.com/noha/pharo-talents/tree/api-enhancements <https://github.com/noha/pharo-talents/tree/api-enhancements> Norbert > Am 23.07.2019 um 11:24 schrieb Norbert Hartl <norbert(a)hartl.name>: > > 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 > > > <Bildschirmfoto 2019-07-23 um 11.10.54.png> > > 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> > > <Talents-Test.st> > <playground.st>

July 23, 2019

P8 + aTalent - aKind

by Norbert Hartl

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>

July 23, 2019

Re: [Pharo-dev] Testing "Weekly Digest" for GitHub

by Marcus Denker

> On 17 Jul 2019, at 07:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > This seems to have been caused by a faulty config (I really hate YAMLâ¦). > > I changed it *and* put the day to be saturday, as they seem to have run into rate limiting > for the API on Sundays in the past. > > So hopefully this will work saturday again. > I finally remove the config file and deinstalled/reinstalled the bot. https://github.com/pharo-project/pharo/issues/4024 "Last week, 64 pull requests were merged.â Marcus

July 23, 2019

[Pharo 8.0] Build #541: Categorize FFITestUnion

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

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

July 22, 2019

[Pharo 8.0] Build #540: Cleanups MemoryHandle class

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

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

July 22, 2019

[Pharo 8.0] Build #539: addingSortingPluginToCodeCompletion

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

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

July 22, 2019

[Pharo 8.0] Build #538: 4029-CodeCompletion-bug-fix-for-visitBlockNode

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

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

July 22, 2019

Re: [Pharo-dev] [Blog Post] PoC Alpine Linux Minimal Stateless Pharo

by Mariano Martinez Peck

On Sat, Jul 20, 2019 at 9:05 PM Pierce Ng <pierce(a)samadhiweb.com> wrote: > On Sat, Jul 20, 2019 at 10:58:36AM -0300, Mariano Martinez Peck wrote: > > This is very interesting. I have been playing with docker too [1] [2] [3] > > and indeed I also tried to make it work with alpine [4]. But it was > > Hi Mariano, > > Fun stuff! > Yes, I think it was very fun but useful at the same time :) > > > Anyway, I will be curious to know your progress. Would cog VM work > > correctly with musl instead of glibc? > > That's what I'll find out. :-) I built the Cog VM from source on Alpine. > As written in my post said Cog VM successfully runs a minimal Pharo > image doing FFI and Fuel. > > I'll be testing it with the regular image running some kind of webapp. > > That sounds cool. Please keep us posted on your progress. Even if a "development" image cannot run on Alpine (because of whatever external lib), having a reduced/runtime/minima/production/whatever that would, is a great achievement. If I were you, I would also try to run the whole Pharo Test Suite on top of that minimal image (the test suite for that image, obviously). That may give you a better idea than just testing by using a webapp. Best, -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: www.linkedin.com/in/mariano-martinez-peck <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> Blog: https://marianopeck.wordpress.com/

July 21, 2019