October 2017 - Pharo-users - lists.pharo.org

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

SystemVersion cleanup (or the return of the explicit build number) in latest Pharo 7

by Torsten Bergmann

Hi, as you all know Pharo 7 is built using sources from github and a new bootstrap process. The first Pharo 7 images [1] unfortunately were hard to distinguish - the initial problem was described in [2] Guille tried to address this by adding a build number again [3] but unfortunately he mixed it into the existing suffix of the class SystemVersion. There was also some other trouble afterwards: - the highestUpdate was still not set by the bootstrap process, which made some code unloadable (like Artefact who's config is checking if it is above a certain update number) - with Guilles fix the build number had to be parsed from the suffix string - one was still not able to distinguish 32/64 bit images - the SystemVersion class and the according tests were still ugly So I reviewed all this more deeply and cleaned SystemVersion as well as the tests while trying to stay as compatible as possible. Thanks a lot to Pavel and Esteban who helped me sorting things out, especially in git and the bootstrap process. How does it look now ==================== 1. Our system type is still called "Pharo" ;) SystemVersion current type -> 'Pharo' 2. we still continue with major and minor versioning (leaving out patch versions), so currently work is done for Pharo 7.0 SystemVersion current major -> 7 SystemVersion current minor -> 0 SystemVersion current majorMinorVersion -> 'Pharo7.0' 3. the identification string now has a "+" sign inside to separate the build meta informations following the given rule 10 from http://semver.org So the full image version now looks like this: SystemVersion current imageVersionString -> 'Pharo-7.0+alpha.build.168.sha.30fc9bbe79922877706ecd842f8aef6822cdcdd9 (32 Bit)' 4. the suffix is currently "alpha" and may be changed depending on release status SystemVersion current suffix -> 'alpha' 5. the build number is stored as an explicit ivar in SystemVersion now SystemVersion current build -> 168 Note that the build number is explicitly set during the bootstrap process from the outside and increased over time with each new build. It represents the CI build number of #development branch now, see [4] on CI server 6. the github SHA commit hash is accessible too: SystemVersion current commitHash -> '30fc9bbe79922877706ecd842f8aef6822cdcdd9' which corresponds in this case to the last commit in #development branch https://github.com/pharo-project/pharo/commit/30fc9bbe79922877706ecd842f8ae… 7. the version includes now also the 32/64 bit distinction: Pharo-7.0+alpha.build.168.sha.30fc9bbe79922877706ecd842f8aef6822cdcdd9 (32 Bit) or Pharo-7.0+alpha.build.168.sha.30fc9bbe79922877706ecd842f8aef6822cdcdd9 (64 Bit) Additionally ============ - the version is displayed in SystemReporter and the AboutBox (Screenshot attached), please use this to identify the image easily - the #highestUpdate is calculated dynamically with code in the image (but it is there only for compatibility reasons). SystemVersion current highestUpdate -> "70168" We might easily catch the 999 build mark now and then run into 71000 which might still be Pharo 7.0 instead of 7.1. (which means first two digits of update number will then NOT correspond to major/minor version anymore). So better avoid #highestUpdate as a meaningful number for loading code or other. - also note if you contribute with an own PR (in your own fork on github) the build number is the build number of you PR specific CI build. Once your PR is reviewed and merged it is the regular Pharo image build number again. - you can reuse SystemVersion for you own apps built on top of Pharo: "MyKillerApp-1.0+beta (64 Bit)" can be easily created with: (SystemVersion major: 1 minor: 0 suffix: 'beta') type: 'MyKillerApp'; yourself - if you report a bug on bugs.pharo.org it would be good to note down the full version of the image you used as found in the About box. This allows to better reproduce wrong behavior that only happens in a specific image Thanks T. [1] http://files.pharo.org/image/70/ [2] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2017-August/1309… [3] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2017-August/1310… [4] https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 5, 2017

Re: [Pharo-users] Brea wiki software

by H. Hirzel

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