- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About the sprint saturday 12

by Tudor Girba

Gary, are you around? Cheers, Doru On 8 Mar 2011, at 11:33, Gary Chambers wrote: > No, for the Bern sprint. > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, March 07, 2011 8:11 PM > Subject: Re: [Pharo-project] About the sprint saturday 12 > > > you mean for the 12? > > > Stef > On Mar 7, 2011, at 5:40 PM, Gary Chambers wrote: > >> As indicated, due to lack of response prior to event I scheduled other activities, unfortunately... >> >> Regards, Gary >> >> ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, March 07, 2011 4:26 PM >> Subject: Re: [Pharo-project] About the sprint saturday 12 >> >> >> did you try screen sharing? >> >> On Mar 7, 2011, at 5:25 PM, Gary Chambers wrote: >> >>> Indeed, I'll be on email/IRC#pharo or whatever else is needed then. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Monday, March 07, 2011 4:05 PM >>> Subject: Re: [Pharo-project] About the sprint saturday 12 >>> >>> >>> Good. >>> I would like to merge all the polymorph overrides :). >>> With alain we are building a roadmap to move the UI. >>> >>> Stef >>> >>> >>>> As before I 'can' be available on IRC if interested... >>>> Book now, as with the Bern sprint I had no reply... >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>> Sent: Monday, March 07, 2011 3:09 PM >>>> Subject: Re: [Pharo-project] About the sprint saturday 12 >>>> >>>> >>>> 9 in the morning until 17h >>>> INRIA is 15 min by tram from the station direct connection. >>>> >>>> Stef >>>> >>>> On Mar 7, 2011, at 3:15 PM, Francois Stephany wrote: >>>> >>>>> Hi, >>>>> >>>>> At what time do you start/finish ? Is it far from Lille train station ? >>>>> >>>>> Cheers, >>>>> Francois >>>>> >>>>> On 03/03/11 17:30, StÃ©phane Ducasse wrote: >>>>>> Hi guys and participants of the school, >>>>>> >>>>>> we proposed to organize a spring saturday 12 so that you can get involved and get the feel >>>>>> of a fun coding party. Now we need to know if you plan to participate so that we >>>>>> can reserve a room and prepare something for lunch. >>>>>> >>>>>> So could you reply to this email so that we know what we should prepare. >>>>>> >>>>>> Stef >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

March 12, 2011

Re: [Pharo-project] Issue 3714 in pharo: ChangeSet removeSelector does not dirty packages

by pharo＠googlecode.com

Updates: Summary: ChangeSet removeSelector does not dirty packages Comment #2 on issue 3714 by stephane...(a)gmail.com: ChangeSet removeSelector does not dirty packages http://code.google.com/p/pharo/issues/detail?id=3714 (No comment was entered for this change.)

March 12, 2011

Re: [Pharo-project] Issue 3795 in pharo: MC repository

by pharo＠googlecode.com

Comment #1 on issue 3795 by stephane...(a)gmail.com: MC repository http://code.google.com/p/pharo/issues/detail?id=3795 No idea where the code is: not found in squeak trunk or inbox.

March 12, 2011

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

by StÃ©phane Ducasse

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

[Pharo-project] [update 1.3] #13079

by StÃ©phane Ducasse

13079 ----- - Issue 3600: Enhancement : Refactorings and tests on Balloon-Collections. Thanks HJO :) and Henrik Johanssen. Stef

March 12, 2011

[Pharo-project] Pharo 1.2 builds green :)

by Esteban Lorenzano

Hi, ...well, they are blue, not green, but I can't get used to it :) So... is time to release it, finally? btw, before release it, can't we change default RealEstateAgent usedStrategy to #straggerFor:initialExtent:world:, so windows get a "normal" size? Current one is too small in my screen :( Cheers, Esteban

March 12, 2011

Re: [Pharo-project] Issue 3793 in pharo: MorphTreeMorph >> #addSelectedNodeItem:

by pharo＠googlecode.com

Updates: Status: Accepted Comment #2 on issue 3793 by stephane...(a)gmail.com: MorphTreeMorph >> #addSelectedNodeItem: http://code.google.com/p/pharo/issues/detail?id=3793 (No comment was entered for this change.)

March 12, 2011

Re: [Pharo-project] Issue 3803 in pharo: Create an issue tracker for Cog VM development

by pharo＠googlecode.com

Comment #13 on issue 3803 by stephane...(a)gmail.com: Create an issue tracker for Cog VM development http://code.google.com/p/pharo/issues/detail?id=3803 Remember that this is eliot that asked doru to set up this bugtracker for Cog!!!

March 12, 2011

Re: [Pharo-project] Issue 3600 in pharo: Enhancement : Refactorings and tests on Balloon-Collections.

by pharo＠googlecode.com

Updates: Status: Closed Labels: Milestone-1.3 Comment #2 on issue 3600 by stephane...(a)gmail.com: Enhancement : Refactorings and tests on Balloon-Collections. http://code.google.com/p/pharo/issues/detail?id=3600 in 13079

March 12, 2011

Re: [Pharo-project] Issue 3732 in pharo: default omni browser size bigger

by pharo＠googlecode.com

Updates: Status: Closed Comment #5 on issue 3732 by stephane...(a)gmail.com: default omni browser size bigger http://code.google.com/p/pharo/issues/detail?id=3732 (No comment was entered for this change.)

March 12, 2011