March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3685 in pharo: #createUserSubclass:instVarNames:categoryName: no longer accepts an inst var array

by pharo＠googlecode.com

Updates: Labels: Milestone-1.3 Comment #3 on issue 3685 by marianopeck: #createUserSubclass:instVarNames:categoryName: no longer accepts an inst var array http://code.google.com/p/pharo/issues/detail?id=3685 (No comment was entered for this change.)

March 12, 2011

[Pharo-project] Issue 3814 in pharo: Weak announcements refinement

by pharo＠googlecode.com

Status: Accepted Owner: siguc...(a)gmail.com New issue 3814 by siguc...(a)gmail.com: Weak announcements refinement http://code.google.com/p/pharo/issues/detail?id=3814 So... here it is! Before applying, load the Announcements-Core-LukasRenggli.12 Announcements-Tests-Core-LukasRenggli.4 from PharoTaskForces and then apply changeset from 3811 Attachments: Announcements-phase1.1.cs 7.6 KB Announcements-phase2.3.cs 22.4 KB

March 12, 2011

[Pharo-project] About Pharo sprint

by Igor Stasenko

It is easy to tell, when it happens.. because my inbox is flooded with tons of messages :) And that's great :) -- Best regards, Igor Stasenko AKA sig.

March 12, 2011

Re: [Pharo-project] Issue 3811 in pharo: Extending MessageSend protocol with cull: and value: protocol

by pharo＠googlecode.com

Issue 3811: Extending MessageSend protocol with cull: and value: protocol http://code.google.com/p/pharo/issues/detail?id=3811 This issue is now blocking issue 3814. See http://code.google.com/p/pharo/issues/detail?id=3814 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

March 12, 2011

Re: [Pharo-project] Fwd: [squeak-dev] sustainable Monticello

by Chris Muller

I have not yet copied all of the packages. Please give me a few more days.. On Sat, Mar 12, 2011 at 4:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Where can I find the code of your changes? > I looked in the squeak trunk but this is not clear to me. > I look in the squeak inbox and again I could not find it. > > Stef > > >> Thanks, I'm glad Pharo will adopt too, since having common MC API's >> between Squeak and Pharo will make life easier. >> >> I only posted the latest versions, there there are 8 or 10 interim >> ancestor versions which I will copy to trunk in a few days. >> >> - Chris >> >> On Wed, Mar 9, 2011 at 2:55 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> thanks >>> >>> If somebody want to get the code and prepare it for pharo this will help. >>> >>> Stef >>> >>> >>> >>> On Mar 8, 2011, at 10:38 PM, Janko MivÅ¡ek wrote: >>> >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: [squeak-dev] sustainable Monticello >>>> Date: Tue, 8 Mar 2011 15:33:19 -0600 >>>> From: Chris Muller <asqueaker(a)gmail.com> >>>> Reply-To: ma.chris.m(a)gmail.com, The general-purpose Squeak developers >>>> list Â <squeak-dev(a)lists.squeakfoundation.org> >>>> To: squeak dev <squeak-dev(a)lists.squeakfoundation.org> >>>> >>>> This will probably be a long post, but I would like to tell you about >>>> the Monticello upgrades I'm about to move to the trunk. >>>> >>>> Monticello has several repository types: >>>> >>>> Â Â Â Â Â Â Â MCRepository #('creationTemplate' 'storeDiffs') >>>> Â Â Â Â Â Â Â Â Â Â Â MCDictionaryRepository #('description' 'dict') >>>> Â Â Â Â Â Â Â Â Â Â Â MCFileBasedRepository #('cache' 'allFileNames') >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â MCDirectoryRepository #('directory') >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â MCCacheRepository >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â #('packageCaches' 'seenFiles') >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â MCSubDirectoryRepository #() >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â MCFtpRepository #('host' 'directory' >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 'user' 'password' 'connection') >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â MCHttpRepository #('location' 'user' >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 'password' 'readerCache') >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â MCSMCacheRepository #('smCache') >>>> Â Â Â Â Â Â Â Â Â Â Â MCGOODSRepository #('hostname' 'port' >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â 'connection') >>>> Â Â Â Â Â Â Â Â Â Â Â MCWriteOnlyRepository #() >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â MCSMReleaseRepository #('packageName' >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 'user' 'password') >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â MCSmtpRepository #('email') >>>> >>>> but MCFileBasedRepository is the one that has been given all of the >>>> focus, the other repository types have been ignored over the years. >>>> MCHttpRepository is the one that interfaces with SqueakSource, and >>>> MCDirectoryRepository are pretty much the only types being used. >>>> >>>> I know this because external users of MCRepository API, like the >>>> Repository-browser tools and MC-Configurations and Installer; these >>>> are all using API's that are specific to MCFileBasedRepository - not >>>> generally understood by the other repository-types or the abstract API >>>> in MCRepository. >>>> >>>> This is worthy of concern because of the access-limitations of a >>>> MCFileBasedRepository. Â Unlike a MCGOODSRepository, for example, a >>>> file-system-based repository cannot efficiently meet the demands of >>>> being a MCRepository without, at some points, needing to enumerating >>>> ALL version names (files) in its file-system location. >>>> >>>> As the number of versions in a repository reaches 1-million and >>>> beyond, performance will grind to a halt due to the number of files >>>> that must be constantly downloaded into RAM (another area of >>>> unscalability and unsustainability related to FileBased Repository's). >>>> A purging of old versions could be done, but a philosophy of >>>> Monticello, from the outset, has been that repository's are intended >>>> to contain "all" of version history. >>>> >>>> I have therefore reworked the MCRepository API's and external tools to >>>> talk using only an API that is understood by any repository that >>>> implements the methods identified as #subclassResponsibility in >>>> MCRepository. Â This minimally-required API is now: >>>> >>>> Â #allPackageNames - answer a list of package names in this repository. >>>> Â #basicStoreVersion: - add a Version to this repository. >>>> Â #includesVersionNamed: - does a version with this name exist in this >>>> repository? >>>> Â #versionNamed: - answer the first Version object with the given name. >>>> Â #versionNamesForPackageNamed: - answer the version names for the >>>> given package name. >>>> Â #versionWithInfo:ifAbsent: - answer the Version object with the >>>> given unique VersionInfo >>>> >>>> In deference to the limitations of FileBasedRepository's, we only ask >>>> for the _names_ of things rather than the whole object, because the >>>> names are all that is needed to satisfy tool requirements, except in >>>> cases where we need a single Version object (like loading). Â FileBased >>>> cannot access the Version objects quickly, just the (file)names (incl. >>>> author & version-number). >>>> >>>> During the process of this refactoring, I was able to signficantly >>>> improve the coherence of the code. Â It was really, really bad in some >>>> areas. >>>> >>>> I've also verified the viability of this API by updating >>>> MCMagmaRepository, and demonstrating using Magma as a >>>> totally-sustainable and scalable MC repository. Â Employing a >>>> Magma-based Repository also affords some additional benefits, which I >>>> will describe in a separate follow-up mail. >>>> >>>> I think SqueakSource will eventually have to change to something more >>>> scalable. Â At least now we have have a viable alternative, and with >>>> much cleaner MC code in the process. >>>> >>>> Please load my latest versions of Monticello, >>>> MonticelloConfigurations, Installer and Tests from the Inbox and let >>>> me know if you experience any issues. Â You should not see any >>>> difference in day-to-day operations. >>>> >>>> - Chris >>>> >>>> >>>> >>> >>> >>> > >

March 12, 2011

Re: [Pharo-project] Last pending things for Pharo 1.2

by Noury Bouraqadi

7) unload SimpleMorphic (see my previous mail) On 12 mars 2011, at 20:19, Mariano Martinez Peck wrote: > So....here is the list of things I guess are pending: > > 1) "Release" all configurations included in Pharo (this is, ConfigurationOfPharo and all it dependencies). I mean, we should NOT use or depend on #development versions. > 2) Update the one click image to use latest cog images and "pharo prepared vms". There are some issues regarding this... > 3) Write down all the things/summary done in Pharo 1.2 > 5) Update SystemVersion current -->> Pharo1.2rc2 of 27 January 2011 update 12340 > 6) Condense sources? condense changes? #cleanUpForRelease > > Cheers > > Mariano Noury Bouraqadi http://car.mines-douai.fr/noury -- -6th National Conference on âControl Architecture of Robotsâ 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France

March 12, 2011

Re: [Pharo-project] can we add #cleanUpForRelease to hudson?

by Noury Bouraqadi

We discussed today that on release we should remove SimpleMorphic when releasing. The idea is that SimpleMorphic is in the image in order to try to get some benefit from the money spent by ESUG. The result wasn't what ESUG first wanted, but this is another story. So, the idea is to try to extract some useful parts from SimpleMorphic and inject them in the image. We don't want SimpleMorphic by itself. So, we remove it from the image when releasing. But, when developing we want to have it into the image. To sum up: -We unload SimpleMorphic when releasing version n -We load it back into the image of version n+1 alpha. Noury On 12 mars 2011, at 20:34, Mariano Martinez Peck wrote: > grrr forget this thread....it is already being done by DEVImageCreator...I don't know why I didn't see the sender...sorry for the noise > > mariano > > On Sat, Mar 12, 2011 at 8:30 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > or...we can add it to ImageForDevelopers...indeed it was there at the beginning, but then we remove it from there becase it took ages. Now, and even with cog, it is fast..so... > > I am all ears.. > > mariano > > > On Sat, Mar 12, 2011 at 8:10 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Marcus, can we add a "ScriptLoader new cleanUpForRelease" at the end of the Pharo.st that is used to build the PharoDev 1.2? > > Thanks > > mariano > > Noury Bouraqadi http://car.mines-douai.fr/noury -- -6th National Conference on âControl Architecture of Robotsâ 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France

March 12, 2011

Re: [Pharo-project] Pharo mailing list weekly summary #5

by Francois Stephany

Sure, I'll add the date range next week ;) Of course, some threads span on 2 or 3 periods. On 12/03/11 19:49, Noury Bouraqadi wrote: > I'd rather prefer the actual date such as: 7-13 march 2011 > > Thanx FranÃ§ois any way. > On 12 mars 2011, at 18:14, Geert Claes wrote: > >> Hi Francois, Excellent job again. Just one suggestion, can we use the actual >> week number e.g. Pharo summary week 10, 2011? >> >> -- >> View this message in context: http://forum.world.st/Pharo-mailing-list-weekly-summary-5-tp3350331p3350535… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 12, 2011

Re: [Pharo-project] Do you want to add the background picture to the image like we did with Pharo 1.1 ?

by Noury Bouraqadi

+1. I suggest to change the background for every new version. Also put the version number next the logo. On 12 mars 2011, at 20:16, Mariano Martinez Peck wrote: > If I could decide, I would vote for it :) I like it. > > If you agree, then it is very easy to add to hudson, just modify (marcus?) the Pharo.st used to build the images to do something like this: World backgroundImage: (ImageReadWriter formFromFileNamed: 'pharoBackground.png') layout: #scaled. > > I attach here the picture used. > > Cheers > > Mariano > <pharoBackground.png> Noury Bouraqadi http://car.mines-douai.fr/noury -- -6th National Conference on âControl Architecture of Robotsâ 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France

March 12, 2011

Re: [Pharo-project] The current status of OSProcess

by David T. Lewis

On Sat, Mar 12, 2011 at 11:34:11AM -0800, nullPointer wrote: > Please, I need know the actual status of OSProcess; what I can wit it and > cannot: > > -Works in main platforms? Mac, Windows Linux? works of same way on all > places? OSProcess works on unix platforms, including Mac and Linux. Windows support is incomplete. > -I could execute external executable files? > -I could execute commandline tools? Yes. You should also load CommandShell in addition to OSProcess. > -Which will be the next steps of development? Well I probably should get Windows support working one of these days ;) > -OsProcess will be integrated in Core? No, OSProcess and CommandShell are external packages. > -Exists some place with deep doc? See class CommandShell, method category "documentation" on the class side, as well as class and method comments throughout. Many classes provide examples, and the unit tests may be helpful for understanding usage. Additional information is at: http://wiki.squeak.org/squeak/708 http://wiki.squeak.org/squeak/1914 http://wiki.squeak.org/squeak/2153 http://wiki.squeak.org/squeak/6023 Dave

March 12, 2011