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

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

by Esteban Lorenzano

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

June 17, 2012

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

by phil＠highoctane.be

As a tribute to south america, why not pick up places, people, or events? There is for sure a wealth of names and a rich history. Would be great as lots of growth expected in that area of the world! http://en.wikipedia.org/wiki/History_of_Argentina http://en.wikipedia.org/wiki/History_of_Chile Pharo Patagonia anyone? Phil 2012/6/17 Esteban Lorenzano <estebanlm(a)gmail.com>: > I prefer codenames and not number because numbering is boring. Just that. 1.4.1 is a stupid number that makes people believe that there will be a 1.4.2, etc... (because our mind is designed that way, inevitably). And if I want to realease an emergency fix, as this version is 1.4.1 next version will be 1.4.1.1 etc. > So, no, I prefer codenames over numbering. Also, I'm from southamerica, I know perfectly well than summer here is winter there. I also know something more: nobody cares there :) but if there are complains, I'm willing to change the code name for... I dunno, places where there are Faros. > > 1.4 Alexandria > 1.4 FinistÃ¨re > 1.4 Usuhaia :) > > as I said... I just don't care which code name, but I don't want numbers. > > (btw... I'm kinda happy that this is the biggest divergence in my proposal :P) > > On Jun 17, 2012, at 5:10 AM, Ben Coman wrote: > >> Sean P. DeNigris wrote: >>> EstebanLM wrote >>> >>>> I started thinking on next release of Pharo 1.4 (which will be code named >>>> "summer", not an ugly number). >>>> >>>> Re browsers... I would definitely include either OB or Nautilus. The default >>>> is just too limiting. Nautilus does seem to be in a pretty usable state now, >>>> and it'd be helpful for new users not to have to learn two browsers in two >>>> releases... >>>> >>>> >>>> >> -1 on code name "summer" since it is winter here in Australia. Â Also, were you considering the full name being: >> a) only "Summer" >> b) "Pharo Summer" >> c) "Pharo 1.4 Summer" >> >> For (a) and (b) - what happens next summer for a maintenance release of 2.0 ? Â Another code name could work. >> For (c), since an ugly number '1.4' is already included, I'd just stay with that as '1.4.1' > (c) was my idea, but if place-codenames are taken, we can use a different names each times. > >> >> Also for consideration with using a code name rather than a version number, the two I know off... >> Ubuntu - increments each release with a letter of the alphabet, so it is still easy to see the progression. >> Eclipse - used the code name for the simultaneous release of multiple projects all having separate version numbers. Â The underlying platform still uses point numbers. >> >> >> Esteban, >> >> 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. > > no, because you can load Nautilus on top of OB, but not the opposite. > >> >> cheers -ben >> >> >> > > -- 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 Esteban Lorenzano

I prefer codenames and not number because numbering is boring. Just that. 1.4.1 is a stupid number that makes people believe that there will be a 1.4.2, etc... (because our mind is designed that way, inevitably). And if I want to realease an emergency fix, as this version is 1.4.1 next version will be 1.4.1.1 etc. So, no, I prefer codenames over numbering. Also, I'm from southamerica, I know perfectly well than summer here is winter there. I also know something more: nobody cares there :) but if there are complains, I'm willing to change the code name for... I dunno, places where there are Faros. 1.4 Alexandria 1.4 FinistÃ¨re 1.4 Usuhaia :) as I said... I just don't care which code name, but I don't want numbers. (btw... I'm kinda happy that this is the biggest divergence in my proposal :P) On Jun 17, 2012, at 5:10 AM, Ben Coman wrote: > Sean P. DeNigris wrote: >> EstebanLM wrote >> >>> I started thinking on next release of Pharo 1.4 (which will be code named >>> "summer", not an ugly number). >>> >>> Re browsers... I would definitely include either OB or Nautilus. The default >>> is just too limiting. Nautilus does seem to be in a pretty usable state now, >>> and it'd be helpful for new users not to have to learn two browsers in two >>> releases... >>> >>> >>> > -1 on code name "summer" since it is winter here in Australia. Also, were you considering the full name being: > a) only "Summer" > b) "Pharo Summer" > c) "Pharo 1.4 Summer" > > For (a) and (b) - what happens next summer for a maintenance release of 2.0 ? Another code name could work. > For (c), since an ugly number '1.4' is already included, I'd just stay with that as '1.4.1' (c) was my idea, but if place-codenames are taken, we can use a different names each times. > > Also for consideration with using a code name rather than a version number, the two I know off... > Ubuntu - increments each release with a letter of the alphabet, so it is still easy to see the progression. > Eclipse - used the code name for the simultaneous release of multiple projects all having separate version numbers. The underlying platform still uses point numbers. > > > Esteban, > > 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. no, because you can load Nautilus on top of OB, but not the opposite. > > cheers -ben > > >

June 17, 2012

Re: [Pharo-project] what is the status of the monkey?

by Esteban Lorenzano

is locked in Benjamin's drawer, but with Camillo we are planning to free him this week :) On Jun 16, 2012, at 11:57 PM, Mariano Martinez Peck wrote: > ulyses. Where is it? why is it not working? how can I make the monkey pick a particular issue? > > thanks > > -- > Mariano > http://marianopeck.wordpress.com >

June 17, 2012

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

by Igor Stasenko

On 17 June 2012 09:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor > > could you tell us what we should do with the issues on handle (feedback of lukas) > > http://code.google.com/p/pharo/issues/detail?id=5145 > > Stef oh, i thought this was already integrated. i think we shall integrate it, and then we will see. the main change is allow object-based announcements, as long an object understands #handlesAnnouncement: message. > > On Jun 16, 2012, at 11:09 PM, Igor Stasenko wrote: > >> On 16 June 2012 22:51, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> Hi, with the help of Guille I noticed that normal instances usually register >>> weakly: >>> >>> TestRunner >> initialize >>> ..... >>> SystemAnnouncer current >>> Â Â Â Â weak >>> Â Â Â Â on: ClassAdded, CategoryAdded, ClassRemoved, CategoryRemoved, >>> ClassRenamed, CategoryRenamed, ClassRecategorized send: #update to: self. >>> ..... >>> >>> and classes don't: >>> >>> TestCase class >> registerForNotifications >>> Â Â ... >>> Â Â SystemAnnouncer current on: MethodAdded, MethodModified, MethodRemoved >>> send: #methodChanged: to: self. >>> >>> so..Guille told me this is because usually the cycle-life of instances is >>> short in comparisson with classes. But classes can be removed as well. What >>> happen then? the announcer will hold always a reference to an obsolete >>> class? >>> my question is, should we always use weakly? if not, why ? >>> >> >> Yes, i think most of subscriptions should be weak, because it is kind >> of implied by loose-coupling. >> And classes is not an exception - because then you don't need to >> explicitly unsubscribe, >> and don't have to worry that it kept in memory just because you forgot to do it. >> >>> thanks for the explanation, >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

June 17, 2012

Re: [Pharo-project] senders search symbols, class references shouldn't do it as well?

by Marcus Denker

On Jun 16, 2012, at 11:42 PM, Mariano Martinez Peck wrote: > If I search senders of 'foo' I do get those method that has #foo inside. However, if I search class references to Bar, it doesn't found methods that have something like Smalltalk at: #Bar. > shouldn't it also find this? > This is not really possible. "senders of" is actually "has this symbol in the literal array". the class references, it searches for class bindings in the literal array. both are *very* simplistic. The system is not searching for "message sends" or "class references" at all. What you want would mean far more analysis, with real semantical knowledge that is not available on that level. Marcus -- Marcus Denker -- http://marcusdenker.de

June 17, 2012

[Pharo-project] Pharo Magritte

by StÃ©phane Ducasse

Begin forwarded message: > From: William Cook <wcook(a)cs.utexas.edu> > Subject: Re: Pharo > Date: June 17, 2012 5:30:29 AM GMT+02:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Reply-To: wcook(a)cs.utexas.edu > > Hi again, > > By the way, I have noticed that there are lots of similarities between the Magritte project and the Enso project that I'm working on with Tijs van der Storm. One big difference is that we avoid embedded DSLs, but many of the high-level goals seem similar. Are you still working on it? > > Here are two papers that we have produced recently: > Object Grammars: Compositional & Bidirectional Mapping Between Text and Graphs (EnsÅ Papers 2 of 6) > Tijs van der Storm, William R. Cook, Alex Loh > (submitted for publication) > > Managed Data: Modular Strategies for Data Abstraction (EnsÅ Papers 1 of 6) > Alex Loh, Tijs van der Storm, and William R. Cook > To appear, Onward! 2012 . > > > William

June 17, 2012

[Pharo-project] Fwd: [Pharo-bugtracker] Issue 6075 in pharo: PrimitiveFailed: primitive #primClose: in MultiByteFileStream failed

by StÃ©phane Ducasse

Begin forwarded message: > From: pharo(a)googlecode.com > Subject: [Pharo-bugtracker] Issue 6075 in pharo: PrimitiveFailed: primitive #primClose: in MultiByteFileStream failed > Date: June 17, 2012 7:38:03 AM GMT+02:00 > To: pharo-bugtracker(a)lists.gforge.inria.fr > Reply-To: codesite-noreply(a)google.com > > Status: Accepted > Owner: ---- > Labels: Milestone-2.0 Type-Bug > > New issue 6075 by vonbecm...(a)gmail.com: PrimitiveFailed: primitive #primClose: in MultiByteFileStream failed > http://code.google.com/p/pharo/issues/detail?id=6075 > > Image > ----- > /home/vonbecmann/pharo-projects/trunk/target/Pharo-2.0.image > Pharo2.0a > Latest update: #20132 > Unnamed > > Virtual Machine > --------------- > /home/vonbecmann/bin/pharo-cog-vm/CogVM > CoInterpreter VMMaker-oscog-EstebanLorenzano.160 uuid: bec8cdf0-4e06-4975-8c02-e882fadf4df3 Jun 1 2012, StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.160 uuid: bec8cdf0-4e06-4975-8c02-e882fadf4df3 Jun 1 2012, https://git.gitorious.org/cogvm/blessed.git Commit: 744bfe905c78a1a5d408680a8780367ea77e0549 Date: Fri Jun 1 15:17:41 2012 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> > Unix built on Jun 1 2012 15:35:26 Compiler: 4.1.2 20080704 (Red Hat 4.1.2-48) > CoInterpreter VMMaker-oscog-EstebanLorenzano.160 uuid: bec8cdf0-4e06-4975-8c02-e882fadf4df3 Jun 1 2012 > StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.160 uuid: bec8cdf0-4e06-4975-8c02-e882fadf4df3 Jun 1 2012 > > Steps to reproduce: > - download latest pharo-2.0 image from hudson > - open that image > > > Attachments: > output.log 1.2 KB > PharoDebug.log 40.6 KB > > > _______________________________________________ > Pharo-bugtracker mailing list > Pharo-bugtracker(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

June 17, 2012

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

by StÃ©phane Ducasse

Igor could you tell us what we should do with the issues on handle (feedback of lukas) http://code.google.com/p/pharo/issues/detail?id=5145 Stef On Jun 16, 2012, at 11:09 PM, Igor Stasenko wrote: > On 16 June 2012 22:51, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> Hi, with the help of Guille I noticed that normal instances usually register >> weakly: >> >> TestRunner >> initialize >> ..... >> SystemAnnouncer current >> weak >> on: ClassAdded, CategoryAdded, ClassRemoved, CategoryRemoved, >> ClassRenamed, CategoryRenamed, ClassRecategorized send: #update to: self. >> ..... >> >> and classes don't: >> >> TestCase class >> registerForNotifications >> ... >> SystemAnnouncer current on: MethodAdded, MethodModified, MethodRemoved >> send: #methodChanged: to: self. >> >> so..Guille told me this is because usually the cycle-life of instances is >> short in comparisson with classes. But classes can be removed as well. What >> happen then? the announcer will hold always a reference to an obsolete >> class? >> my question is, should we always use weakly? if not, why ? >> > > Yes, i think most of subscriptions should be weak, because it is kind > of implied by loose-coupling. > And classes is not an exception - because then you don't need to > explicitly unsubscribe, > and don't have to worry that it kept in memory just because you forgot to do it. > >> thanks for the explanation, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Best regards, > Igor Stasenko. >

June 17, 2012

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

by Ben Coman

Sean P. DeNigris wrote: > EstebanLM wrote > >> I started thinking on next release of Pharo 1.4 (which will be code named >> "summer", not an ugly number). >> >> >> Re browsers... I would definitely include either OB or Nautilus. The default >> is just too limiting. Nautilus does seem to be in a pretty usable state now, >> and it'd be helpful for new users not to have to learn two browsers in two >> releases... >> >> >> -1 on code name "summer" since it is winter here in Australia. Also, were you considering the full name being: a) only "Summer" b) "Pharo Summer" c) "Pharo 1.4 Summer" For (a) and (b) - what happens next summer for a maintenance release of 2.0 ? Another code name could work. For (c), since an ugly number '1.4' is already included, I'd just stay with that as '1.4.1' Also for consideration with using a code name rather than a version number, the two I know off... Ubuntu - increments each release with a letter of the alphabet, so it is still easy to see the progression. Eclipse - used the code name for the simultaneous release of multiple projects all having separate version numbers. The underlying platform still uses point numbers. Esteban, 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. cheers -ben

June 17, 2012