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

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

by Damien Pollet

I understand what slots are, but haven't heard of frames in this contextâ¦ can you elaborate ? On Wed, 18 Jul 2018 at 13:44, Reg Krock via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > The Slot class implementation is fundamentally sound but the larger > constructs surrounding Frames and Slots still requires extensive thought. > > I suspect that you will find that many more changes will be discovered as > work is done with it. > > Slots provide the capacity to implement most of AOP concepts in a simple > manner. It also results in a Frame model. > > I also would suggest careful examination of when to use composition versus > traits with slots. > > Regards > > Reg Krock > > > > On 17 Jul2018, at 1:44 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > > > 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 > > > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

July 18, 2018

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

by Reg Krock

The Slot class implementation is fundamentally sound but the larger constructs surrounding Frames and Slots still requires extensive thought. I suspect that you will find that many more changes will be discovered as work is done with it. Slots provide the capacity to implement most of AOP concepts in a simple manner. It also results in a Frame model. I also would suggest careful examination of when to use composition versus traits with slots. Regards Reg Krock > On 17 Jul2018, at 1:44 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > 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 18, 2018

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

by Denis Kudriashov

Hi 2018-07-17 9:55 GMT+01:00 tesonep(a)gmail.com <tesonep(a)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. > Would be nice to have it consistent with #methods and #localMethods. I would prefer explicit names like definedSlots, owningSlots (if needed). And same for methods. > 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

Re: [Pharo-dev] [ANN] Pharo Git Thermite Release

by Alexandre Bergel

It would be fantastic that people try it out. It is easy to use, and is really a big improvement over the tool set we use. And getting feedback is important. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jul 17, 2018, at 11:08 AM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > 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 <https://github.com/ronsaldo/pharo-git-thermite> > > Short video examples: > - Monticello Visualization; https://youtu.be/02CUHBmm-K8 <https://youtu.be/02CUHBmm-K8> > - GitHub pull request: https://youtu.be/f196btLfYxM <https://youtu.be/f196btLfYxM> > - Local git commit: https://youtu.be/LCHTiJ4nx3g <https://youtu.be/LCHTiJ4nx3g> > > Feedback form: https://docs.google.com/forms/d/e/1FAIpQLSeir6VlE3bR78oRsNAp9eHLkUn2Q016wEl… <https://docs.google.com/forms/d/e/1FAIpQLSeir6VlE3bR78oRsNAp9eHLkUn2Q016wEl…> > > Best regards, > Ronie > > <thermite-visualization.png> >

July 17, 2018

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