- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

by Sean P. DeNigris

tesonep(a)gmail.com wrote > the one that is disturbing, it is kept for > compatibility with the old behavior Are there enough users to justify backward compatibility if it costs a nice API? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

July 17, 2018

[ANN] Pharo Git Thermite Release

by Ronie Salgado

Hello, I am finally releasing an initial public version of Pharo Git Thermite, a tool that I am developing as part of my master thesis for visualizing Monticello and Git commits, for Pharo and Python: GitHub Page with sources/documentation/issue tracker: https://github.com/ronsaldo/pharo-git-thermite Short video examples: - Monticello Visualization; https://youtu.be/02CUHBmm-K8 - GitHub pull request: https://youtu.be/f196btLfYxM - Local git commit: https://youtu.be/LCHTiJ4nx3g Feedback form: https://docs.google.com/forms/d/e/1FAIpQLSeir6VlE3bR78oRsNAp9eHLkUn2Q016wEl… Best regards, Ronie

July 17, 2018

[Pharo 7.0-dev] Build #1127: 22067-Duplicated-packages-in-Pharo-baselines-SUnit-and-BasicTools

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

There is a new Pharo build available! The status of the build #1127 was: FAILURE. The Pull Request #1487 was integrated: "22067-Duplicated-packages-in-Pharo-baselines-SUnit-and-BasicTools" Pull request url: https://github.com/pharo-project/pharo/pull/1487 Issue Url: https://pharo.fogbugz.com/f/cases/22067 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 17, 2018

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

by Torsten Bergmann

July 17, 2018

Re: [Pharo-dev] ZnUnicodeComposingReadStream?

by Max Leske

On 16 Jul 2018, at 19:46, Alistair Grant wrote: > Hi Sven & Max, > > > On Fri, Jul 13, 2018 at 07:59:32PM +0200, Sven Van Caekenberghe wrote: >> Alistair, are you aware of the following (article/codebase) ? >> >> https://medium.com/concerning-pharo/an-implementation-of-unicode-normalizat… >> >> Due to the size of the full DB it is doubtful it would become a >> standard part of Pharo though. >> >> Sven > > > Thanks again for the link, it has helped my (still limited) > understanding of Unicode. > > The reason I started looking in to this was that my file attribute > modification tests failed on Mac OS. The problem is that Mac OS > requires file names to be decomposed UTF8, and my plugin wasn't doing > the conversion. > > Following the general principle of trying to keep the VM minimal and > do > as much as possible in the image, I had hoped I could do the UTF8 > (de)composition in the image. > > But it turns out that Mac OS doesn't follow the standard rules, so > programs really need to use the native file name encoding routines on > Mac OS. > > So that's the path I'll be following in this instance. I still really > appreciate the link, and will be exploring the Unicode package more. > > > > On Fri, Jul 13, 2018 at 10:50:36PM +0200, Max Leske wrote: >> Hi Alistair, >> >> *nix systems usually come with the iconv[1] command line program that >> implements the normalization and denormalization algorithms, or Uconv >> 2, a >> library that does the same thing. These algorithms include a lot of >> black magic >> and I recommend to not make your hands dirty with them. With the FFI >> interface >> Pharo has today it shouldn't be too hard to call out to Uconv >> (although I'm not >> saying it's trivial; I've written a VM plugin that we use a work to >> interface >> with Uconv and you do have to know how encodings and iconv work) or >> execute >> iconv directly. >> >> I can send you a copy of the plugin code if you want, actually, I may >> put it on >> github if there's interest. >> >> Cheers, >> Max >> >> [1] https://linux.die.net/man/1/iconv >> [2] https://en.wikipedia.org/wiki/Uconv >> [3] http://site.icu-project.org/ >> >> > > On Sat, Jul 14, 2018 at 08:20:23AM +0200, Max Leske wrote: >> I realize I got things mixed up a bit: Uconv is a program akin to >> Iconv. What >> we interface with is libicu. >> >> Max > > The VM already uses libiconv for the encoding translation on linux. > As > far as I know, the routines haven't been exposed directly to the image > (although I haven't looked carefully). > > I'd be interested in looking at your plugin - I'm still working > through > the current FilePlugin behaviour, but I think it would be useful to > have > these routines available directly from the image for debugging, etc. > > Thanks again, > Alistair I've put the plugin source on Github: https://github.com/Netstyle/Squeak-VM-Unicode-operations-plugin. I hope you'll find it useful. Note that the code was written for version 4.0.3-2202 of the Squeak VM and that you'd most likely have to make a couple of modifications to get it running in the OpenSmalltalk VM's. Cheers, Max

July 17, 2018

Re: [Pharo-dev] IndexedSlots in combination with StatefulTraits

by tesonep＠gmail.com

Hi Torsten, the problem is defining the behavior expected from the set of messages: Today we have 3 (yes 3.... awful) they are to keep compatibility with the tools, we have to continue improving them. - allSlots: returns all the slots defined in the hierarchy, in the same class and in all the traits used in the hierarchy. - localSlots: returns the slots that are defined in the own class without the ones in the traits. - slots: returns the slots that are defined in the class and not in the superclasses. The last message is the one that is disturbing, it is kept for compatibility with the old behavior. In my opinion, localSlots should be removed, and slots behave like localSlots. It requires to change the tools. If we need to know where the slots are defined we can ask the slots, the slots know which is the class using the slot and where it is defined. So, I will like to improve in any way. About the implementation I like the one in #localSlots. But it requires some work or letting the stuff broken until we fix them. Cheers, Pablo On Tue, Jul 17, 2018 at 10:19 AM Torsten Bergmann <astares(a)gmx.de> wrote: > I guess I found a bug in accessing Slots using #slots in combination with > IndexedSlots and traits. > To reproduce use latest Pharo 7 (Build 1126) > > First create a class with a slot, note that the slot needs to be : > > Object subclass: #ClassA > slots: { IndexedSlot named: #upper } > classVariables: { } > package: 'Slot-Bugs' > > As it is the first slot it internally receives an index 1 as you can check > with "ClassA slots first". > > Now define a stateful trait with another indexed slot: > > Trait named: #StatefulTrait > uses: {} > slots: { IndexedSlot named: #slotFromTrait } > category: 'Slot-Bugs' > > And create a new subclass using the new Trait > > ClassA subclass: #ClassB > uses: StatefulTrait > instanceVariableNames: '' > classVariableNames: '' > package: 'Slot-Bugs' > > > 1. when you evaluate "ClassA slots" it returns {#FirstSlot => Slot} which > is correct > 2. when you evaluate "StatefulTrait slots" it returns {#slotFromTrait => > Slot} which is correct > 3. when you evaluate "ClassB allSlots" returns "an > OrderedCollection(#upper => InstanceVariableSlot #slotFromTrait => > InstanceVariableSlot)" which is OK > > but > > 4. when you evaluate "ClassB slots" it returns {#slotFromTrait => > InstanceVariableSlot} which is NOT correct as class B does not define the > slot, it is defined in the trait > > > So I think 4. is wrong and reasons is the implementation of #slot: > > slots > "I remove the slots comming from a traitComposition" > ^ super slots reject:[ :e | self traitComposition slots > includes:e ] > > If you debug you will notice that > > super slots returns our #slotFromTrait with an index > of 2 while > self traitComposition slots returns our #slotFromTrait with an index > of 1 while > > which is the same #slotFromTrait but a different index - therefore it does > not get removed. > > > Dont know what is the best way to fix this without any side effects. > Commenst and help appreciated. > > Thanks > T. > > -- Pablo Tesone. tesonep(a)gmail.com

July 17, 2018

IndexedSlots in combination with StatefulTraits

by Torsten Bergmann

I guess I found a bug in accessing Slots using #slots in combination with IndexedSlots and traits. To reproduce use latest Pharo 7 (Build 1126) First create a class with a slot, note that the slot needs to be : Object subclass: #ClassA slots: { IndexedSlot named: #upper } classVariables: { } package: 'Slot-Bugs' As it is the first slot it internally receives an index 1 as you can check with "ClassA slots first". Now define a stateful trait with another indexed slot: Trait named: #StatefulTrait uses: {} slots: { IndexedSlot named: #slotFromTrait } category: 'Slot-Bugs' And create a new subclass using the new Trait ClassA subclass: #ClassB uses: StatefulTrait instanceVariableNames: '' classVariableNames: '' package: 'Slot-Bugs' 1. when you evaluate "ClassA slots" it returns {#FirstSlot => Slot} which is correct 2. when you evaluate "StatefulTrait slots" it returns {#slotFromTrait => Slot} which is correct 3. when you evaluate "ClassB allSlots" returns "an OrderedCollection(#upper => InstanceVariableSlot #slotFromTrait => InstanceVariableSlot)" which is OK but 4. when you evaluate "ClassB slots" it returns {#slotFromTrait => InstanceVariableSlot} which is NOT correct as class B does not define the slot, it is defined in the trait So I think 4. is wrong and reasons is the implementation of #slot: slots "I remove the slots comming from a traitComposition" ^ super slots reject:[ :e | self traitComposition slots includes:e ] If you debug you will notice that super slots returns our #slotFromTrait with an index of 2 while self traitComposition slots returns our #slotFromTrait with an index of 1 while which is the same #slotFromTrait but a different index - therefore it does not get removed. Dont know what is the best way to fix this without any side effects. Commenst and help appreciated. Thanks T.

July 17, 2018

Re: [Pharo-dev] ZnUnicodeComposingReadStream?

by Alistair Grant

Hi Sven & Max, On Fri, Jul 13, 2018 at 07:59:32PM +0200, Sven Van Caekenberghe wrote: > Alistair, are you aware of the following (article/codebase) ? > > https://medium.com/concerning-pharo/an-implementation-of-unicode-normalizat… > > Due to the size of the full DB it is doubtful it would become a standard part of Pharo though. > > Sven Thanks again for the link, it has helped my (still limited) understanding of Unicode. The reason I started looking in to this was that my file attribute modification tests failed on Mac OS. The problem is that Mac OS requires file names to be decomposed UTF8, and my plugin wasn't doing the conversion. Following the general principle of trying to keep the VM minimal and do as much as possible in the image, I had hoped I could do the UTF8 (de)composition in the image. But it turns out that Mac OS doesn't follow the standard rules, so programs really need to use the native file name encoding routines on Mac OS. So that's the path I'll be following in this instance. I still really appreciate the link, and will be exploring the Unicode package more. On Fri, Jul 13, 2018 at 10:50:36PM +0200, Max Leske wrote: > Hi Alistair, > > *nix systems usually come with the iconv[1] command line program that > implements the normalization and denormalization algorithms, or Uconv 2, a > library that does the same thing. These algorithms include a lot of black magic > and I recommend to not make your hands dirty with them. With the FFI interface > Pharo has today it shouldn't be too hard to call out to Uconv (although I'm not > saying it's trivial; I've written a VM plugin that we use a work to interface > with Uconv and you do have to know how encodings and iconv work) or execute > iconv directly. > > I can send you a copy of the plugin code if you want, actually, I may put it on > github if there's interest. > > Cheers, > Max > > [1] https://linux.die.net/man/1/iconv > [2] https://en.wikipedia.org/wiki/Uconv > [3] http://site.icu-project.org/ > > On Sat, Jul 14, 2018 at 08:20:23AM +0200, Max Leske wrote: > I realize I got things mixed up a bit: Uconv is a program akin to Iconv. What > we interface with is libicu. > > Max The VM already uses libiconv for the encoding translation on linux. As far as I know, the routines haven't been exposed directly to the image (although I haven't looked carefully). I'd be interested in looking at your plugin - I'm still working through the current FilePlugin behaviour, but I think it would be useful to have these routines available directly from the image for debugging, etc. Thanks again, Alistair

July 16, 2018

Off-topic: The Value Shift in Commons-based Peer Production

by Eliot Miranda

The Value Shift in Commons-based Peer Production, or how open source communities can fairly create and share wealth while protecting themselves from extractive exploitation https://www.boell.de/sites/default/files/value_in_the_commons_economy.pdf _,,,^..^,,,_ (phone)

July 15, 2018

[Pharo 7.0-dev] Build #1126: 22261-Improving-method-comments-and-adding-examples

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

There is a new Pharo build available! The status of the build #1126 was: SUCCESS. The Pull Request #1636 was integrated: "22261-Improving-method-comments-and-adding-examples" Pull request url: https://github.com/pharo-project/pharo/pull/1636 Issue Url: https://pharo.fogbugz.com/f/cases/22261 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 15, 2018