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

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

by Benjamin

You must be kidding right :) Since you arrived, I told you at least once per week "we should sit together and see the monkey" ;) Ben On Jun 17, 2012, at 11:42 AM, Esteban Lorenzano wrote: > 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] start thinking on summer release of Pharo 1.4

by Ben Coman

Esteban Lorenzano wrote: > 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) > Well I was very happy to hear your proposal. You are in the drivers seat so I'll live with whatever outcome - but just a bit more counter-point... Sometimes boring makes the world go round. If you release an emergency fix to '1.4 Alexandria' - what do you call it? Are you going to be tagging in the Issue Tracker the fixes included with maintenance release - what would you use? Looking further into how Ubuntu handle this [1] (since they are most obvious using funky release naming.) Turns out their official release actually remains numeric point-form, but because they include the month of release in the minor point-number they need the codename "during development". Perhaps including the numeric month somewhat addresses your concern of expectations of continuing minor revisions. However since there has been no codename and the release month is unknown to me, I have been thinking about the maintenance release as 1.4.1. I'd be very happy to have a codename to refer to this up until release (and probably for some time afterwards) - but I'd still really like a point form backing, to refer to in a few years time. [1] https://wiki.ubuntu.com/DevelopmentCodeNames cheers -ben > 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] PackageOrganizer packages vs. categories

by Marcus Denker

On Jun 17, 2012, at 4:05 PM, Sean P. DeNigris wrote: > > EstebanLM wrote >> >> Marcus proposal is good: map RPackage with MCPackage, tag the >> subcategories (RPackage allow adding attributes). >> > I'm not sure I completely understand... So MCPackages will become RPackages, Yes. > and subcategories will become RPackages tagged to indicate they belong to a > parent package? > No. the *classes* will be tagged with the sub-category. There will only be one RPackage. Marcus -- Marcus Denker -- http://marcusdenker.de

June 17, 2012

Re: [Pharo-project] PackageOrganizer packages vs. categories

by Sean P. DeNigris

EstebanLM wrote > > Marcus proposal is good: map RPackage with MCPackage, tag the > subcategories (RPackage allow adding attributes). > I'm not sure I completely understand... So MCPackages will become RPackages, and subcategories will become RPackages tagged to indicate they belong to a parent package? EstebanLM wrote > > with time packages will adapt > Adapt how? -- View this message in context: http://forum.world.st/PackageOrganizer-packages-vs-categories-tp4635069p463… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 17, 2012

[Pharo-project] [Bootstrap][GSOC] Update on the bootstrap

by Guillermo Polito

Finally I'm making the progress public *officially* :P I've written some posts in my blog about the bootstrap progress: http://playingwithobjects.wordpress.com/2012/06/08/the-bootstrap-chronicles… http://playingwithobjects.wordpress.com/2012/06/11/the-bootstrap-chronicles… http://playingwithobjects.wordpress.com/2012/06/17/the-bootstrap-chronicles… The last post is probably the most interesting one, telling how you can try the code *(at your own risk)*. If you do not like reading long posts, here is a summary: - code is available to bootstrap a pharo image. - the bootstrap takes a sample on the current running pharo image. It does not start from source code yet. - the bootstrapped image doe some nice reporting like space tally and a list of broken references and not initialized stuff. This list is a point to start improving the pharo core packaging, to make the core not dependent on external packages. - the size of the bootstrapped image fluctuates between 1.1 and 2 megabytes depending on the initialization and sample you take to bootstrap. This is a point to attack using the spacetally and some other reports probably. You can also see a jenkins job at Ecole des Mines where that report is printed as a Junit report. As long as that list has items to fix, the job will remain yellow :). http://car.mines-douai.fr/ci/job/Seed%20Broken%20References%20Report/ http://car.mines-douai.fr/ci/job/Seed%20Broken%20References%20Report/lastCo… My next steps are making the bootstrap start from a source code specification and work a bit on modularization. Enjoy, Guille

June 17, 2012

Re: [Pharo-project] #anyChanges still needed?

by Mariano Martinez Peck

On Sat, Jun 16, 2012 at 11:53 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > My 2cts is for some event (and I think *modified is part of them), you got > the event twice: before and after. > So basically, one of the two events is wrong. > > Mariano, you should try to put an halt, and see :) > I did, but it gets call only once per modification. > > Ben > > > On Jun 16, 2012, at 10:26 PM, Guillermo Polito wrote: > > Yeah, but logging superfluous changes does not really make a change, does > it? > > On Sat, Jun 16, 2012 at 10:04 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> may be because the source changes was listening to the event. >> And the log file needed to log any thing like doits and other. >> >> On Jun 16, 2012, at 9:14 PM, Mariano Martinez Peck wrote: >> >> > Hi guys. ChangeSet does at some point: >> > >> > anEvent itemKind = SystemChangeNotifier classKind ifTrue: [ >> > ... >> > anEvent isModified >> > ifTrue: [anEvent anyChanges ifTrue: [self >> changeClass: anEvent item from: anEvent oldItem]]. >> > anEven >> > >> > >> > >> > So...I don't understand the #anyChanges. We received an event saying >> that a class was modified, but it may not have any changes? if true, why >> was the event sent? >> > Ok...let's say that there could be several reasons that a class was >> modified but only some of them make sense to change set. I can imagine >> people wanted to avoid writing stuff to .changes that didn't actullay >> represente a change? >> > >> > If this is the case, then #anyChanges looks like a bad name for me. >> > >> > Now, do we still need this mesage? can there be ClassModified events >> without changes? >> > thanks >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> >> >> > > -- Mariano http://marianopeck.wordpress.com

June 17, 2012

[Pharo-project] Help review ! Re: [Pharo-bugtracker] Issue 6077 in pharo: Let DataStream only for Monticello Part2

by Mariano Martinez Peck

Hi guys. I touched a couple of packages so it will get obsolete soon if we don't integrate it. Anywone to review? On Sun, Jun 17, 2012 at 3:36 PM, <pharo(a)googlecode.com> wrote: > Updates: > Status: FixReviewNeeded > > Comment #1 on issue 6077 by marianopeck: Let DataStream only for > Monticello Part2 > http://code.google.com/p/**pharo/issues/detail?id=6077<http://code.google.com/p/pharo/issues/detail?id=6077> > > So slice in inbox. > IMPORTANT: after integrating, you have to evaluate: > > ScriptLoader new deletePackage: 'System-Object Storage' > > > > ______________________________**_________________ > Pharo-bugtracker mailing list > Pharo-bugtracker(a)lists.gforge.**inria.fr<Pharo-bugtracker(a)lists.gforge.inria.fr> > http://lists.gforge.inria.fr/**cgi-bin/mailman/listinfo/**pharo-bugtracker<http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker> > -- Mariano http://marianopeck.wordpress.com

June 17, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,mac - Build # 129 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 17, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,linux - Build # 129 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 17, 2012

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

by Sean P. DeNigris

philippeback wrote > > OB if we want traction with embarking new people into Pharo. > ... That makes sense. The only downside is that we will train people on one browser and almost immediately switch to a new one. I remember questions about how to "get the browser from PBE" (it was O2 I think). Although, I guess this is a good tradeoff vs. exposing newbies to a bleeding edge tool under heavy development. Also, about that release date... Sean -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp46345… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 17, 2012