- Pharo-users - lists.pharo.org

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by horrido

I've incorporated some of the suggestions. Thanks. Here's a very lively discussion at Hacker News: https://news.ycombinator.com/item?id=15399442 The article has sparked a raging debate. Hacker News readers seem to really like the article, as it has garnered 150 points, /more than any other article that I've ever posted!/ (Even my original TechBeacon article <https://techbeacon.com/how-learning-smalltalk-can-make-you-better-developer> -- which launched my campaign! -- only got 115 points.) You should all participate in the discussion and help to dispel the many misconceptions people have about Pharo/Smalltalk. I find a great deal of ignorance out there, and *only you folks* can address it properly. Thanks. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2017

Re: [Pharo-users] Equals and HashCode Builder

by Stephane Ducasse

Here is what I extracted from older emails >From David Allouche in Pharo-dev to see if The ==hash== method is used in Pharo to separate objects in bucket-based data structures. !! Property It must have one required property which is required data integrity: !!!! A. Objects that are equal according to ==\=== must have equal hashes. It should have two desirable properties that are required to support the algorithmic assumptions of bucket-based data structures: !!!! B. Objects that are not equal should have different hashes. Ideally, the probability of hash collision should by 1/N where N is the size of hash value space. !!!! C. The hash values should spread as much as possible over their value space. For example: ProtoObject>>#identityHash. How these two desirable properties can be implemented depends on the actual distribution of the values used to compute the hash. An object can safely use XOR hashing if its instance variables are all different objects that already provide a hash method with these two properties. @@todo check following sentence because the use of singleton is obscure For example, an object whose behaviour is defined by several of singleton delegates of different classes that do not override Object>>#hash. But if the instance variables are not guaranteed to have those properties, it is necessary to more thoroughly "mix the bits". For example the method ==hash== of ==SequenceableCollection== illustrates this point. [[[ SequenceableCollection >> hash | hash | hash := self species hash. 1 to: self size do: [:i | hash := (hash + (self at: i) hash) hashMultiply]. ^ hash ]]] The mixing of the bits is done by the combination of addition and ==hashMultiply==. The value of ==species hash== does not need to be processed by ==hashMultiply==, because it is probably computed by the method =identityHash== of ==ProtoObject==, and that already provides property C. !!! When we should not use XOR ==LayoutFrame== is a particularly good example of a data structure that should not use XOR hashing. Its instance variables provide none of the required properties: - ==SmallInteger>>hash== is just ==^self==. - In addition, common ==LayoutFrame== instances tend to use pairs of identical values in their instance variables. Like ==0@0 corner: 1@1==, or ==Margin fromNumber: 10==. A good hash function for LayoutFrame needs to: - Get hashes for each instance variable that provides properties A and B. - Combine them in a way that is order-sensitive (to maintain property B) and that does some extra mixing (to provide property C). Now, we can assume that common values for the instance variables will be instances of ==SmallInteger==, ==Float==, or ==Fraction==. You can see in ==Fraction>>hash==, that a comment mentions the assumption that the fraction is already reduced, that is what makes it acceptable to use bitXor. The hash of ==SmallInteger== does provide properties A and B, but not property C. The hash of ==Float== is harder to understand, but tests show that it provides distinct values for 0.5, 0.25 and 0.125. So it hopefully provides B for the range of values of interest to ==LayoutFrame==. Another class that has similar hashing constraints to ==LayoutFrame== is ==Point==. Its ==hash== method is: [[[ Point >> hash "Hash is reimplemented because = is implemented." ^(x hash hashMultiply + y hash) hashMultiply ]]] It does not include species in the computation, which is less than ideal because it favours collisions with objects of different species that have a similar content and a the same hash algorithm. Finally, it is probably not necessary or useful to use the accessors to get to the instance variables. So a good implementation for LayoutFrame is [[[ LayoutFrame >> hash | hash | hash := self species hash hash := (hash + leftFraction hash) hashMultiply hash := (hash + leftOffset hash) hashMultiply hash := (hash + topFraction hash) hashMultiply hash := (hash + topOffset hash) hashMultiply hash := (hash + rightFraction hash) hashMultiply hash := (hash + rightOffset hash) hashMultiply hash := (hash + bottomFraction hash) hashMultiply hash := (hash + bottomOffset hash) hashMultiply ^ hash ]]] On Fri, Oct 6, 2017 at 9:59 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Noury also proposed a trait to avoid to systematically have to implement hash. > Vitor why don't you take it as a small project to propose a solution for Pharo. > > On Thu, Oct 5, 2017 at 6:34 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: >> Yes, canEqual implementation also make #= be commutative. >> >> On Tue, Oct 3, 2017 at 11:11 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >>> >>> >>> 2017-10-02 17:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>> >>>> >>>> 2017-10-02 17:13 GMT+02:00 Vitor Medina Cruz <vitormcruz(a)gmail.com>: >>>>> >>>>> I am sorry, not species, but #isKindOf istead of #= to compare classes. >>>> >>>> >>>> It is bad idea. #= should be transitive. >>> >>> >>> Oh, I used wrong word, shame on me :). I tried to say commutative. >>> >>>> >>>> How you will generate it with isKindOf: logic? You need to know common >>>> parent. >>>> >>>> Also I not remember cases where I was needed two instances of different >>>> classes to be equal. >>>> And I can imaging the problems which it will lead to. >>>> >>>>> >>>>> >>>>> On Mon, Oct 2, 2017 at 11:57 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> 2017-10-02 16:37 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>>>> >>>>>>> >>>>>>> Two questions/comments about the generated code: >>>>>>> 1. #= >>>>>>> ... >>>>>>> self class = anObject class "should compare #species instead?" >>>>>>> ifFalse: [ ^ false ]. >>>>>>> ... >>>>>>> Typically, I've seen #species instead of #class in the guard >>>>>>> statement. >>>>>>> Should we change it to that? >>>>>> >>>>>> >>>>>> I doubt that it is important for domain classes. Because I never saw >>>>>> the user of #species which is not a kind of Collection. And for collections >>>>>> this refactoring is not valid anyway. >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2. #hash >>>>>>> ^ var1 hash bitXor: (var2 hash bitXor: var3 hash) >>>>>>> Is this implementation always safe? It's what I usually hand roll >>>>>>> based on >>>>>>> what I've seen, but Andres Valloud wrote a whole (large) book on >>>>>>> hashing, so >>>>>>> I've always wondered if I was missing somethingâ¦ >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- >>>>>>> Cheers, >>>>>>> Sean >>>>>>> -- >>>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>>> >>>>>> >>>>> >>>> >>> >>

Oct. 6, 2017

Re: [Pharo-users] Equals and HashCode Builder

by Stephane Ducasse

Noury also proposed a trait to avoid to systematically have to implement hash. Vitor why don't you take it as a small project to propose a solution for Pharo. On Thu, Oct 5, 2017 at 6:34 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Yes, canEqual implementation also make #= be commutative. > > On Tue, Oct 3, 2017 at 11:11 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: >> >> >> 2017-10-02 17:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>> >>> 2017-10-02 17:13 GMT+02:00 Vitor Medina Cruz <vitormcruz(a)gmail.com>: >>>> >>>> I am sorry, not species, but #isKindOf istead of #= to compare classes. >>> >>> >>> It is bad idea. #= should be transitive. >> >> >> Oh, I used wrong word, shame on me :). I tried to say commutative. >> >>> >>> How you will generate it with isKindOf: logic? You need to know common >>> parent. >>> >>> Also I not remember cases where I was needed two instances of different >>> classes to be equal. >>> And I can imaging the problems which it will lead to. >>> >>>> >>>> >>>> On Mon, Oct 2, 2017 at 11:57 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >>>> wrote: >>>>> >>>>> >>>>> 2017-10-02 16:37 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>>>> >>>>>> >>>>>> Two questions/comments about the generated code: >>>>>> 1. #= >>>>>> ... >>>>>> self class = anObject class "should compare #species instead?" >>>>>> ifFalse: [ ^ false ]. >>>>>> ... >>>>>> Typically, I've seen #species instead of #class in the guard >>>>>> statement. >>>>>> Should we change it to that? >>>>> >>>>> >>>>> I doubt that it is important for domain classes. Because I never saw >>>>> the user of #species which is not a kind of Collection. And for collections >>>>> this refactoring is not valid anyway. >>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2. #hash >>>>>> ^ var1 hash bitXor: (var2 hash bitXor: var3 hash) >>>>>> Is this implementation always safe? It's what I usually hand roll >>>>>> based on >>>>>> what I've seen, but Andres Valloud wrote a whole (large) book on >>>>>> hashing, so >>>>>> I've always wondered if I was missing somethingâ¦ >>>>>> >>>>>> >>>>>> >>>>>> ----- >>>>>> Cheers, >>>>>> Sean >>>>>> -- >>>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>> >>>>> >>>> >>> >> >

Oct. 6, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Stephane Ducasse

Thanks I think that this is really nice. Thanks for your time. On Fri, Oct 6, 2017 at 2:42 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Cool! Waiting for the updated version with this mailing list feedback on it. > > Cheers, > > Offray > > > On 05/10/17 19:35, horrido wrote: >> Yes, the "updated" angle was the crucial tactic. Thanks. >> >> I just wanted to inform you that in just 48 hours since publication, this >> article has gathered over 11,000 views! This is a new record for me. Fastest >> rising. >> >> I am astounded by the number; I really didn't expect it. It's a very, very >> nice way to end my campaign on a high note. Hopefully, Pharo (and Smalltalk) >> will become more popular. >> >> Cheers. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> > >

Oct. 6, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Offray Vladimir Luna CÃ¡rdenas

Cool! Waiting for the updated version with this mailing list feedback on it. Cheers, Offray On 05/10/17 19:35, horrido wrote: > Yes, the "updated" angle was the crucial tactic. Thanks. > > I just wanted to inform you that in just 48 hours since publication, this > article has gathered over 11,000 views! This is a new record for me. Fastest > rising. > > I am astounded by the number; I really didn't expect it. It's a very, very > nice way to end my campaign on a high note. Hopefully, Pharo (and Smalltalk) > will become more popular. > > Cheers. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 6, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by horrido

Yes, the "updated" angle was the crucial tactic. Thanks. I just wanted to inform you that in just 48 hours since publication, this article has gathered over 11,000 views! This is a new record for me. Fastest rising. I am astounded by the number; I really didn't expect it. It's a very, very nice way to end my campaign on a high note. Hopefully, Pharo (and Smalltalk) will become more popular. Cheers. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 6, 2017

Re: [Pharo-users] Deploying on Linux with LibC version < 2.15

by Cyril Ferlicot D.

Le 05/10/2017 Ã 16:29, Holger Freyther a Ã©critÂ : > I don't have a RHEL subscription but I assumed they are similar but > OBS even produces RHEL packages: > > https://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/… > > > Not sure. Even the RHEL documentation mentions --add-repo exists. I assume > you can download the .repo[1] file and put it in the right directory? > > I tested on a CentOS 6.9 and it worked fine. I'll see next week if it works fine on RHEL. Thank you. > holger > > > > > [1] > RHEL6: > https://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/… > > CentOS6: > https://download.opensuse.org/repositories/devel:/languages:/pharo:/stable/… > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Oct. 5, 2017

Re: [Pharo-users] Deploying on Linux with LibC version < 2.15

by phil＠highoctane.be

Any developer can get a free RHEL license and a dev account for accessing docs and what not. This includes CVE fixes etc. CentOS is close but not always the same. e.g. no security fixes are included vs RHEL when updating (even if the flag is accepted). I am going next week to the RedHat forum in Breda. I would like to find how to get Pharo available on RHEL out of the box. Phil On Thu, Oct 5, 2017 at 4:29 PM, Holger Freyther <holger(a)freyther.de> wrote: > > > On 5. Oct 2017, at 22:22, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> > wrote: > > > > > > > Your instructions describes the steps for CentOS 6.x. Are they the > > exact same steps for RHEL6? > > I don't have a RHEL subscription but I assumed they are similar but > OBS even produces RHEL packages: > > https://download.opensuse.org/repositories/devel:/languages: > /pharo:/stable/RHEL_6/ > > > > > Also, I am trying this on a CentOS 6.0 virtual machine and I get this > error : > > > > [centoslive@livecd test]$ yum-config-manager --add-repo > > http://download.opensuse.org/repositories/devel:/languages: > /pharo:/latest/CentOS_6/devel:languages:pharo:latest.repo > > Loaded plugins: fastestmirror, refresh-packagekit > > Usage: "yum-config-manager [options] [section] > > > > Command line error: no such option: --add-repo > > [centoslive@livecd test]$ > > > > > > Is there something else to install before? > > Not sure. Even the RHEL documentation mentions --add-repo exists. I assume > you can download the .repo[1] file and put it in the right directory? > > > holger > > > > > [1] > RHEL6: > https://download.opensuse.org/repositories/devel:/languages: > /pharo:/stable/RHEL_6/devel:languages:pharo:stable.repo > > CentOS6: > https://download.opensuse.org/repositories/devel:/languages: > /pharo:/stable/CentOS_6/devel:languages:pharo:stable.repo > >

Oct. 5, 2017

Re: [Pharo-users] Equals and HashCode Builder

by Vitor Medina Cruz

Yes, canEqual implementation also make #= be commutative. On Tue, Oct 3, 2017 at 11:11 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-10-02 17:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> 2017-10-02 17:13 GMT+02:00 Vitor Medina Cruz <vitormcruz(a)gmail.com>: >> >>> I am sorry, not species, but #isKindOf istead of #= to compare classes. >>> >> >> It is bad idea. #= should be transitive. >> > > Oh, I used wrong word, shame on me :). I tried to say commutative. > > >> How you will generate it with isKindOf: logic? You need to know common >> parent. >> >> Also I not remember cases where I was needed two instances of different >> classes to be equal. >> And I can imaging the problems which it will lead to. >> >> >>> >>> On Mon, Oct 2, 2017 at 11:57 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> >>>> >>>> 2017-10-02 16:37 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: >>>> >>>>> >>>>> Two questions/comments about the generated code: >>>>> 1. #= >>>>> ... >>>>> self class = anObject class "should compare #species instead?" >>>>> ifFalse: [ ^ false ]. >>>>> ... >>>>> Typically, I've seen #species instead of #class in the guard statement. >>>>> Should we change it to that? >>>>> >>>> >>>> I doubt that it is important for domain classes. Because I never saw >>>> the user of #species which is not a kind of Collection. And for collections >>>> this refactoring is not valid anyway. >>>> >>>> >>>>> >>>>> >>>>> 2. #hash >>>>> ^ var1 hash bitXor: (var2 hash bitXor: var3 hash) >>>>> Is this implementation always safe? It's what I usually hand roll >>>>> based on >>>>> what I've seen, but Andres Valloud wrote a whole (large) book on >>>>> hashing, so >>>>> I've always wondered if I was missing somethingâ¦ >>>>> >>>>> >>>>> >>>>> ----- >>>>> Cheers, >>>>> Sean >>>>> -- >>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>> >>>>> >>>> >>> >> >

Oct. 5, 2017

Re: [Pharo-users] Brea wiki software

by Offray Vladimir Luna CÃ¡rdenas

Hannes, Happy to help, at least with some ideas. Brea is still an early prototype, but suit my needs without the burden of all the extra stuff Seaside includes, for simple cases as mine, but if glad to know that it works for your use case. Cheers, Offray On 05/10/17 10:49, H. Hirzel wrote: > Hello Offray > > Thank you for making the Brea wiki code available. I have read it and > got some ideas out of it. > > My conclusion was that I do not have the capacity at the moment to > continue working on it. > > So I went for Seaside though the library is large. It has a simple > wiki as well. And with Pier are more elaborate version. > > Seaside is well documented. > > Regards > Hannes > > On 9/6/17, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >> Hi, >> >> >> On 06/09/17 02:12, H. Hirzel wrote: >>> So at the moment I am fine to get it up and running using a FossilRepo. >>> Later on I will work on replacing it with a JSON data store. >> Please let me know if you need any permissions into the repository to >> make JSON data store available in Brea. >> >>> On 9/6/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>>> I understand that it makes a lot of sense to reuse the functions >>>> implemented in the FossilRepo. >>>> >>>> Installation of the Fossil version control system seems to be very >>>> simple, just put a single executable file into the pharo folder for >>>> example >>>> >>>> https://fossil-scm.org/index.html/doc/trunk/www/index.wiki >> Yes. Fossil is simpler and self-contained. A lot of friendly and >> powerful user experience without importing the external complexities of >> other developer cultures, like the popular systems (*coff... Git). I use >> the one provided by my package manager, but we have installed Fossil and >> started to use in our workshops and is a lot easier to start being >> productive without the almost always gratuitous extra complexities, >> specially for non tekies. Fossil gives me and easy distributed wiki out >> of the box. >> >>>> On 9/6/17, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >>>>> What I wanted to write is that the class FossilRepo is not included. >>>>> >>>>> And that the setup of the Teapot server should not be hidden in lazy >>>>> initialisation method but made explicit with some methods in a method >>>>> category called 'setup' or 'configuration'. >> Please update your ConfigurationOfBrea, which fixes this two issues. >> >>>>>> On 9/6/17, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> >>>>>> wrote: >>>>>>> Hi, Hannes, >>>>>>> >>>>>>> Sorry it took so long. >>>>>> No problem. It was actually less than 14 days which is not long ..... >>>>>> >>>>>> :-) >> Despite of being just one week after I told you I would look at the >> issue, because the first one I have not access to my computer, is kind >> of a lot considering the good support times in this community (with rare >> exceptions, like when I feedback GT Tools and get no response :-/). >> >> Cheers, >> >> Offray >> >

Oct. 5, 2017