June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by btc＠openInWorld.com

June 17, 2012

Re: [Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Sean P. DeNigris

Igor Stasenko wrote > > I bet if you do that, some people will be alienated/antagonized by > this change Yes, but 2.0 is changing *alot*, so this is a good time to sneak this in :) Like pulling off a BandAid... the best thing to do is pull fast and get it over with. Igor Stasenko wrote > > As a compromise i would suggest to force people to explicitly tell > their intent That would be an improvement... Also, what's the status of this limitation (http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082565.html) : when:do: anActionBlock subscription does > not work weakly, you are constrained to when:send:to IIUC it was waiting on ephemerons (http://forum.world.st/Working-with-weak-announcements-td3305802.html) -- View this message in context: http://forum.world.st/Why-don-t-we-always-register-weakly-in-SystemAnnounce… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 17, 2012

Re: [Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Guillermo Polito

On Sun, Jun 17, 2012 at 2:42 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 17 June 2012 01:30, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > Igor Stasenko wrote > >> > >> because 'announcer weak subscribe: ' is explicit > >> > > > > Either way, something is implicit. Why not make the common case implicit > and > > the uncommon one slightly more verbose? "Make common things easy, rare > > things possible" > > > I bet if you do that, some people will be alienated/antagonized by > this change (oh... its really hard > to make everyone happy). > > As a compromise i would suggest to force people to explicitly tell > their intent.. i.e. > if they want to subscribe strongly, then they should say: > > announcer strong on:.. > > and weakly, is > > announcer weak on:.. > > but if they do: > > announcer on: > > they shall get a DNU/error. > He, I like that! > > -- > Best regards, > Igor Stasenko. > >

June 17, 2012

Re: [Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Igor Stasenko

On 17 June 2012 01:30, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Igor Stasenko wrote >> >> because 'announcer weak subscribe: ' is explicit >> > > Either way, something is implicit. Why not make the common case implicit and > the uncommon one slightly more verbose? "Make common things easy, rare > things possible" > I bet if you do that, some people will be alienated/antagonized by this change (oh... its really hard to make everyone happy). As a compromise i would suggest to force people to explicitly tell their intent.. i.e. if they want to subscribe strongly, then they should say: announcer strong on:.. and weakly, is announcer weak on:.. but if they do: announcer on: they shall get a DNU/error. -- Best regards, Igor Stasenko.

June 17, 2012

[Pharo-project] [update 2.0] #20134

by StÃ©phane Ducasse

20134 ----- - Issue 5750: RPackage should rename extension methods in pckage renames. Thanks Mariano Martinez-Peck and Guillermo Polito. http://code.google.com/p/pharo/issues/detail?id=5750 - Issue 6073: Make PragmaCollector rely on SystemAnnouncer instead of SystemChangeNotifier. Thanks Mariano Martinez-Peck and Guillermo Polito. http://code.google.com/p/pharo/issues/detail?id=6073

June 17, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by Esteban Lorenzano

yes, Configurations Browser needs a little love too :P On Jun 17, 2012, at 12:44 PM, phil(a)highoctane.be wrote: > Who is his/her right mind would be able to make sense of this without > a lot of preexposure? And who the hell are those people? > > And figuring out they need to right click, followed by a load > configuration *and* stable version? Followed by a loooong wait. And if > there is no internet, well, it would freeze for a significant while. > > That's the feedback I get from people I try to get into the flow. Lots > of blank stares... along the lines of "What the heck are you doing?" > > Phil > > > 2012/6/17 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> On Jun 17, 2012, at 5:10 AM, Ben Coman wrote: >> >>> Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? >>> I need to know this to continue updating Pharo By Example for 1.4. >> >> this is an interesting and important issue (much more than codenames, he). >> I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it): >> >> Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. >> Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. >> To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly). >> >> So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. >> Frankly, I don't know what to do now :) >> >> Esteban > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium > <PharoScreenshot.1.png>

June 17, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by phil＠highoctane.be

The girl was attractive and that's why I talked to her. Light was faster than sound in her case, so I left. But, I wouldn't have spoken to her in the first place should she have been an ugly betty. That's just the way things go and why marketing focuses so much on packaging, even if it is an ugly mess inside (Microwave food anyone?) 2012/6/17 Igor Stasenko <siguctua(a)gmail.com>: > i for Pharo 1.4.1 > no messy naming please. > > Let's care more about what we put under the hood, than on glossy cover. > > -- > Best regards, > Igor Stasenko. > -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 17, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by Igor Stasenko

i for Pharo 1.4.1 no messy naming please. Let's care more about what we put under the hood, than on glossy cover. -- Best regards, Igor Stasenko.

June 17, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by phil＠highoctane.be

Who is his/her right mind would be able to make sense of this without a lot of preexposure? And who the hell are those people? And figuring out they need to right click, followed by a load configuration *and* stable version? Followed by a loooong wait. And if there is no internet, well, it would freeze for a significant while. That's the feedback I get from people I try to get into the flow. Lots of blank stares... along the lines of "What the heck are you doing?" Phil 2012/6/17 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On Jun 17, 2012, at 5:10 AM, Ben Coman wrote: > >> Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? >> I need to know this to continue updating Pharo By Example for 1.4. > > this is an interesting and important issue (much more than codenames, he). > I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it): > > Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. > Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. > To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly). > > So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. > Frankly, Â I don't know what to do now :) > > Esteban -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 17, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by phil＠highoctane.be

OB if we want traction with embarking new people into Pharo. Think about the feeling it would give when faced with incomplete/unstable in such a thing as the Browser for a new comer or someone who wants to convince "the powers" that Pharo is an interesting avenue to invest into. Nautilus is the shiny new thing. But OB has all the important things working and the refactorings do kind of work well. And what's wrong with OB after all? There are docs on how to leverage the thing to do our own extensions, which is good. (Glamour still too far fetched at my level). But OB is okay after going through the docs. Know what? At a minimum, it should be clear that one can load OB from the Configurations with just a DoIt from the initial workspace. The way it is now is too complicated to find out. Same thing with ProfStef, FFI etc And a warning telling about how long it would take and so on may be a great thing (Getting OB from the 1.4 metarepo is just taking a long while... and no one wanting to try things out in an overbusy schedule would be able to spend that time. Another point crossing my mind is that if you try this out during a commute in a train or place, you are stuck without network connection. A primed package-cache would be beneficial for that, at the expense of the release size). Spotlight would also benefit from an explanation (like hit Shift-Enter to invoke. In the beginning I was opening that in World and then had a look at the code to find out about the binding...) Know what, we may want to have a YouTube video going with the release and showing how to do that stuff and what to expect. I am volunteering to do it if you are interested. Phil 2012/6/17 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On Jun 17, 2012, at 5:10 AM, Ben Coman wrote: > >> Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? >> I need to know this to continue updating Pharo By Example for 1.4. > > this is an interesting and important issue (much more than codenames, he). > I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it): > > Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. > Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. > To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly). > > So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. > Frankly, Â I don't know what to do now :) > > Esteban -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 17, 2012