May 2014 - Pharo-dev - lists.pharo.org

we should add Pharo30 inbox

by stepharo

Hi we should add Pharo 30 inbox because many changes for 40 have been published there. Stef

May 29, 2014

Re: [Pharo-dev] Solaris VM ?

by Nicolas Cellier

Great. This shall typically be posted on vm-dev. 2014-05-29 2:52 GMT+02:00 aglynn42 <aglynn42(a)gmail.com>: > <quote author="Andreas Wacknitz"> This pdf has a lot of info on porting > linux code to solaris 11. > http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCkQFjA… Hi > Jannik, PharoVM is based on Cog. My old VMâs were traditional SqueakVMâs. I > am not aware of precompiled Solaris VMâs based on Cog or PharoVM, so you > have to build them by yourself. This should be possible; you only need some > supporting libraries (e.g. GMP (earlier named GNUmp) and MPFR)) and > probably CMake. When I did compile it for myself I used Solaris 10 (both, > x86 and SPARC). Which variant do your customers have? Nowadays there are > Solaris 10, Solaris 11, and a bunch of OpenSolaris derivates. There are > some differences in the tool chains and libraries (versions). If you are > not familiar with Solaris or UNIX you should be aware that UNIX in Squeakâs > view is (most probably only) Linux. And this is problematic because you > will most probably find some areas where there are differences between a > ârealâ UNIX (like Solaris) and Linux. Good luck, Andreas > ------------------------------ > View this message in context: Re: Solaris VM ?<http://forum.world.st/Solaris-VM-tp4725204p4760786.html> > Sent from the Pharo Smalltalk Developers mailing list archive<http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html>at Nabble.com. >

May 29, 2014

Re: [Pharo-dev] is ClassOrganization>>#categories right?

by Nicolas Cellier

2014-05-29 0:43 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > I would be for: > > - deprecate #categories > - add #protocols but not answering a string. Answer the protocol objects. > > after all, the whole purpose of this is to reify the protocol concept. > > and of course, Nicolas is rightâ¦ protocols *should not* answer > allProtocolâ¦ or any other virtual protocol. I agree that answering in > #categories is an error tooâ¦ if we are going to change it, letâs not carry > the original mistake. > > Esteban > > +1, that sounds better, then #protocols is not just another rename but a value change. In that case, first revert #categories (remove --all--), - #categories -> #categoriesAndPseudoCategories - #realCategories -> #categories backport to Pharo 3.1, deprecate it in 4.0 (grace period for package maintenance...) One can allways arrange to add #categories later in a compatibility layer. Nicolas > > On 28 May 2014, at 18:16, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > > 2014-05-28 22:49 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> >> On 26/5/14 23:07, GOUBIER Thierry wrote: >> >>> In my own code, I allways use ClassOrganization>>#realCategories to >>> avoid getting the --all-- category. I consider the --all-- category to be a >>> GUI artifact, not a class organization concept. >>> >>> I'd prefer a #protocols (without the --all-- category, of course :)) so >>> ok for deprecating #categories. >>> >> >> +1 :) >> >>> >>> Thierry >>> ________________________________________ >>> De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de >>> Esteban Lorenzano [estebanlm(a)gmail.com] >>> EnvoyÃ© : lundi 26 mai 2014 21:20 >>> Ã : Pharo Development List >>> Objet : [Pharo-dev] is ClassOrganization>>#categories right? >>> >>> Hi, >>> >>> I wonder is current implementation of that method is good: right now, it >>> answers all categories, including virtual ones (âallâ). >>> A lot of things are made in that assumption, but I wonder if is not >>> better to answer just real categories and to create a new method called >>> #allCategories to answer the reals and the virtuals. >>> >>> Also, I wonder if wouldnât be better to just deprecate #categories and >>> use the correct abstraction: #protocols. >>> >>> any opinions? >>> >>> Esteban >>> >>> >>> >> >> > -1 > The sole purpose of categories is to provide backward compatibility > support, or am I mistaken? > > If it's for backward compatibility, why the hell rename it? > We have #categories -> #realCategories (to avoid bogus --all-- inclusion) > and now -> #protocols > That's way too much erraticity. > If the purpose is driving buts people caring of package management and > cross dialect compatibility, then +1, it's a successfull path ;) > I know, I know, Pharo values clean API - protocols ;) - more than > compatibility, but cleaning a message dedicated to compatibility somehow > sounds too much. > > If you opt for protocols, at least, please remove --all-- > > >

May 29, 2014

Re: [Pharo-dev] Solaris VM ?

by aglynn42

This pdf has a lot of info on porting linux code to solaris 11.http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCkQ… Jannik,PharoVM is based on Cog. My old VMâs were traditional SqueakVMâs.I am not aware of precompiled Solaris VMâs based on Cog or PharoVM,so you have to build them by yourself. This should be possible; you only needsome supporting libraries (e.g. GMP (earlier named GNUmp) and MPFR)) and probably CMake.When I did compile it for myself I used Solaris 10 (both, x86 and SPARC). Which variant do yourcustomers have? Nowadays there are Solaris 10, Solaris 11, and a bunch of OpenSolaris derivates.There are some differences in the tool chains and libraries (versions).If you are not familiar with Solaris or UNIX you should be aware that UNIX in Squeakâs viewis (most probably only) Linux. And this is problematic because you will most probably find someareas where there are differences between a ârealâ UNIX (like Solaris) and Linux.Good luck,Andreas -- View this message in context: http://forum.world.st/Solaris-VM-tp4725204p4760786.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 29, 2014

Re: [Pharo-dev] Request write access to Pharo40Inbox

by Sean P. DeNigris

what are the dependency mczs? On May 28, 2014, at 4:40 PM, Attila Magyar [via Smalltalk] <ml-node+s1294792n4760766h34(a)n4.nabble.com> wrote: > What other details would you like to know? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Request-write-access-to-Pharo40Inbox-tp4760747p476078… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 28, 2014

Re: [Pharo-dev] Dark Theme in Pharo 4

by Esteban Lorenzano

wellâ¦ we have to decide that (is trivial to implement, but it was not working like that until now, soâ¦ maybe we need to rethink it :) ) Esteban On 28 May 2014, at 19:59, kilon alios <kilon.alios(a)gmail.com> wrote: > Ah ok . But why ? I assumed that a theme would take care of these things. Especially the color of the font. > > Î£ÏÎ¹Ï 29 ÎÎ±Ï 2014 1:54 Ï.Î¼., Î¿ ÏÏÎ®ÏÏÎ·Ï "Esteban Lorenzano" <estebanlm(a)gmail.com> ÎÎ³ÏÎ±ÏÎµ: > wellâ¦ I just tried with #installFullTheme and it works fine. > you are probably trying to do it trough settings browserâ¦ there, you need to chose the background, the completion background and the colorisation by yourself. > > Esteban > > On 28 May 2014, at 19:36, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > using #installFullTheme? > > thatâs super weirdâ¦ after all, Pharo4 is almost Pharo3 now, and I just merged inâ¦ > > > > Esteban > > > > On 28 May 2014, at 19:01, kilon alios <kilon.alios(a)gmail.com> wrote: > > > >> I don't know if you are aware of this, even though dark theme is integrated in Pharo 4 I see several problems that I dont have with my Pharo 3 install of Dark theme. > >> > >> 1) Pharo background appears still white > >> > >> 2) Code completion has also white background > >> > >> 3) fonts appear black in workspace and inside methods code. > >> > >> > >> Most likely you are aware of this and I realise that Pharo 4 just started but I decided to report just in case. > >> > >> Just for the record Rubric workspace also has issues with Dark Theme. > > > >

May 28, 2014

Re: [Pharo-dev] Dark Theme in Pharo 4

by kilon alios

Ah ok . But why ? I assumed that a theme would take care of these things. Especially the color of the font. Î£ÏÎ¹Ï 29 ÎÎ±Ï 2014 1:54 Ï.Î¼., Î¿ ÏÏÎ®ÏÏÎ·Ï "Esteban Lorenzano" < estebanlm(a)gmail.com> ÎÎ³ÏÎ±ÏÎµ: > wellâ¦ I just tried with #installFullTheme and it works fine. > you are probably trying to do it trough settings browserâ¦ there, you need > to chose the background, the completion background and the colorisation by > yourself. > > Esteban > > On 28 May 2014, at 19:36, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > using #installFullTheme? > > thatâs super weirdâ¦ after all, Pharo4 is almost Pharo3 now, and I just > merged inâ¦ > > > > Esteban > > > > On 28 May 2014, at 19:01, kilon alios <kilon.alios(a)gmail.com> wrote: > > > >> I don't know if you are aware of this, even though dark theme is > integrated in Pharo 4 I see several problems that I dont have with my Pharo > 3 install of Dark theme. > >> > >> 1) Pharo background appears still white > >> > >> 2) Code completion has also white background > >> > >> 3) fonts appear black in workspace and inside methods code. > >> > >> > >> Most likely you are aware of this and I realise that Pharo 4 just > started but I decided to report just in case. > >> > >> Just for the record Rubric workspace also has issues with Dark Theme. > > > > >

May 28, 2014

Re: [Pharo-dev] Dark Theme in Pharo 4

by kilon alios

No I am using system settings to choose the theme as suggested in Pharo news. I am on macos and got my image from https://ci.inria.fr/pharo/job/Pharo-4.0-Update-Step-4-Publish/. Maybe wrong image ? Î£ÏÎ¹Ï 29 ÎÎ±Ï 2014 1:37 Ï.Î¼., Î¿ ÏÏÎ®ÏÏÎ·Ï "Esteban Lorenzano" < estebanlm(a)gmail.com> ÎÎ³ÏÎ±ÏÎµ: > using #installFullTheme? > thatâs super weirdâ¦ after all, Pharo4 is almost Pharo3 now, and I just > merged inâ¦ > > Esteban > > On 28 May 2014, at 19:01, kilon alios <kilon.alios(a)gmail.com> wrote: > > > I don't know if you are aware of this, even though dark theme is > integrated in Pharo 4 I see several problems that I dont have with my Pharo > 3 install of Dark theme. > > > > 1) Pharo background appears still white > > > > 2) Code completion has also white background > > > > 3) fonts appear black in workspace and inside methods code. > > > > > > Most likely you are aware of this and I realise that Pharo 4 just > started but I decided to report just in case. > > > > Just for the record Rubric workspace also has issues with Dark Theme. > > >

May 28, 2014

Re: [Pharo-dev] Dark Theme in Pharo 4

by Esteban Lorenzano

wellâ¦ I just tried with #installFullTheme and it works fine. you are probably trying to do it trough settings browserâ¦ there, you need to chose the background, the completion background and the colorisation by yourself. Esteban On 28 May 2014, at 19:36, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > using #installFullTheme? > thatâs super weirdâ¦ after all, Pharo4 is almost Pharo3 now, and I just merged inâ¦ > > Esteban > > On 28 May 2014, at 19:01, kilon alios <kilon.alios(a)gmail.com> wrote: > >> I don't know if you are aware of this, even though dark theme is integrated in Pharo 4 I see several problems that I dont have with my Pharo 3 install of Dark theme. >> >> 1) Pharo background appears still white >> >> 2) Code completion has also white background >> >> 3) fonts appear black in workspace and inside methods code. >> >> >> Most likely you are aware of this and I realise that Pharo 4 just started but I decided to report just in case. >> >> Just for the record Rubric workspace also has issues with Dark Theme. >

May 28, 2014

Re: [Pharo-dev] is ClassOrganization>>#categories right?

by Esteban Lorenzano

I would be for: - deprecate #categories - add #protocols but not answering a string. Answer the protocol objects. after all, the whole purpose of this is to reify the protocol concept. and of course, Nicolas is rightâ¦ protocols *should not* answer allProtocolâ¦ or any other virtual protocol. I agree that answering in #categories is an error tooâ¦ if we are going to change it, letâs not carry the original mistake. Esteban On 28 May 2014, at 18:16, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 2014-05-28 22:49 GMT+02:00 stepharo <stepharo(a)free.fr>: > > On 26/5/14 23:07, GOUBIER Thierry wrote: > In my own code, I allways use ClassOrganization>>#realCategories to avoid getting the --all-- category. I consider the --all-- category to be a GUI artifact, not a class organization concept. > > I'd prefer a #protocols (without the --all-- category, of course :)) so ok for deprecating #categories. > > +1 :) > > Thierry > ________________________________________ > De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Esteban Lorenzano [estebanlm(a)gmail.com] > EnvoyÃ© : lundi 26 mai 2014 21:20 > Ã : Pharo Development List > Objet : [Pharo-dev] is ClassOrganization>>#categories right? > > Hi, > > I wonder is current implementation of that method is good: right now, it answers all categories, including virtual ones (âallâ). > A lot of things are made in that assumption, but I wonder if is not better to answer just real categories and to create a new method called #allCategories to answer the reals and the virtuals. > > Also, I wonder if wouldnât be better to just deprecate #categories and use the correct abstraction: #protocols. > > any opinions? > > Esteban > > > > > > -1 > The sole purpose of categories is to provide backward compatibility support, or am I mistaken? > > If it's for backward compatibility, why the hell rename it? > We have #categories -> #realCategories (to avoid bogus --all-- inclusion) and now -> #protocols > That's way too much erraticity. > If the purpose is driving buts people caring of package management and cross dialect compatibility, then +1, it's a successfull path ;) > I know, I know, Pharo values clean API - protocols ;) - more than compatibility, but cleaning a message dedicated to compatibility somehow sounds too much. > > If you opt for protocols, at least, please remove --all--

May 28, 2014