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

[Pharo-project] [update 1.3] #13081

by StÃ©phane Ducasse

13081 ----- - Issue 3283: Symbol dependent on Scanner. part 1 and 2. - Removed UIThemePro. - Issue 3299: [Kernel Dependencies] Object Extension.

March 12, 2011

Re: [Pharo-project] Issue 3299 in pharo: [Kernel Dependencies] Object Extension

by pharo＠googlecode.com

Updates: Status: Closed Comment #4 on issue 3299 by stephane...(a)gmail.com: [Kernel Dependencies] Object Extension http://code.google.com/p/pharo/issues/detail?id=3299 In fact we did :)

March 12, 2011

Re: [Pharo-project] Issue 3299 in pharo: [Kernel Dependencies] Object Extension

by pharo＠googlecode.com

Comment #3 on issue 3299 by stephane...(a)gmail.com: [Kernel Dependencies] Object Extension http://code.google.com/p/pharo/issues/detail?id=3299 we will not include primitiveError: since we need it.

March 12, 2011

Re: [Pharo-project] Issue 3298 in pharo: [Kernel Dependencies] Object >> #cannotReturn

by pharo＠googlecode.com

Updates: Status: Closed Labels: Unresolvable Comment #4 on issue 3298 by stephane...(a)gmail.com: [Kernel Dependencies] Object >> #cannotReturn http://code.google.com/p/pharo/issues/detail?id=3298 The solution is probably in the kernel to have cannotReturn: result closureOrNil notNil ifTrue: [^self cannotReturn: result to: self home sender]. then when toolset is loaded to have cannotReturn: result closureOrNil notNil ifTrue: [^self cannotReturn: result to: self home sender]. ToolSet debugContext: thisContext label: 'computation has been terminated' contents: nil

March 12, 2011

[Pharo-project] Issue 3807 in pharo: FileIn from FileContentsBrowser is broken when in presence of reorganize

by pharo＠googlecode.com

Status: Closed Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3807 by stephane...(a)gmail.com: FileIn from FileContentsBrowser is broken when in presence of reorganize http://code.google.com/p/pharo/issues/detail?id=3807 We spent some time with Benjamin and probably the problem is that a ChangeRecord is not tagged as a reorganize. Now the code is so bad and circumvoluted that we decided to remove the possibility to file in code from the FileContentsBrowser and that the user performs a new drag and drop and select file in (which works). We do that because like that we make sure that the integrators do not get confused with different options and one breaking on reorganize in presence of class extension and MC recategorization.

March 12, 2011

Re: [Pharo-project] Issue 1836 in pharo: Adding dedicated accessors for VM parameters

by pharo＠googlecode.com

Updates: Status: Started Labels: Milestone-1.2 Comment #9 on issue 1836 by jbaptist...(a)gmail.com: Adding dedicated accessors for VM parameters http://code.google.com/p/pharo/issues/detail?id=1836 (No comment was entered for this change.)

March 12, 2011

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