December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )

by Adrian Lienhard

On Dec 28, 2009, at 12:39 , Igor Stasenko wrote: > 2009/12/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>>> >>>> Package Classes Methods >>>> Traits 59 873 >>>> Traits-Kernel 22 343 >>>> Traits-Kernel-Traits 17 215 >>>> Traits-Composition 7 127 >>>> NanoTraits-Kernel 9 190 >>>> NanoTraits-Tests 9 122 Haha. This table is nonsense: - The package "Traits" includes "Traits-Kernel", "Traits-Composition" etc. so it is counting the same classes and methods twice - The numbers are from an older implementation of Traits. In Pharo there is a refactored version with less traits that is easier to understand. Squeak has an old version. - Methods defined in the traits ("Traits-Kernel-Traits") are also used by Behavior, ClassDescription, etc. hence making these classes smaller in turn (but the table does not show this fact) - The requires algorithm is not directly related to Traits (as I pointed out in a recent mail) In a Pharo 1.0 image I get Package Classes Methods Traits-Kernel 11 343 Traits-Kernel-Traits 6 215 Traits-Composition 7 122 [...] >> Igor please rephrase your thoughts! :) >> amount of complexity !!! >> not amount of code!!! >> Come on number of classes is not a decent measure in >> presence of late binding! >> > > hehe.. i hope that Andreas writing short methods, not a fat ones which > trying to do everything at once :) Not sure about this. I browsed through the NanoTraits code for 2 minutes, and one thing that puzzled me was this method: !ClassDescription methodsFor: '*NanoTraits-Extensions' stamp: 'ar 12/20/2009 13:38'! installTraitsFrom: aTraitComposition "Install the traits from the given composition" | allTraits methods oldMethod removals oldCategories | (aTraitComposition isKindOf: NanoTraitComposition) ifFalse:[self error: 'Invalid composition']. (self traitComposition isEmpty and: [aTraitComposition isEmpty]) ifTrue: [^self]. "Check for cycles" allTraits := aTraitComposition gather: [:t | t allTraits copyWith: t]. (allTraits includes: self) ifTrue:[^self error: 'Cyclic trait definition detected']. "XXXX: addUser/removeUser should be part of setter, but subclass override prevents it until we've got rid of Traits mess." self traitComposition removeTraitUser: self. self traitComposition: aTraitComposition. aTraitComposition addTraitUser: self. "Assemble the methods in a new dictionary first. Uses a Dictionary instead of a MethodDictionary for speed (MDs grow by #become:)" methods := Dictionary new. "Stick in the local methods first, since this avoids generating conflict methods unnecessarily" self selectorsAndMethodsDo:[:sel :newMethod| (self isLocalMethod: newMethod) ifTrue:[methods at: sel put:newMethod]]. "Now assemble the traits methods" aTraitComposition do:[:trait| trait selectorsAndMethodsDo:[:sel :newMethod| oldMethod := methods at: sel ifAbsentPut:[newMethod]. newMethod == oldMethod ifFalse:["a conflict" (self isLocalMethod: oldMethod) ifFalse:[ methods at: sel put: (self resolveTraitsConflict: sel from: oldMethod to: newMethod). ]. ]. ]. ]. "Apply the changes. We first add the new or changed methods." oldCategories := Set new. methods keysAndValuesDo:[:sel :newMethod| oldMethod := self compiledMethodAt: sel ifAbsent:[nil]. oldMethod == newMethod ifFalse:[ self traitAddSelector: sel withMethod: newMethod. (self organization categoryOfElement: sel) ifNotNil:[:cat| oldCategories add: cat]. self organization classify: sel under: (newMethod methodHome organization categoryOfElement: newMethod selector). ]]. "Now remove the old or obsoleted ones" removals := OrderedCollection new. self selectorsDo:[:sel| (methods includesKey: sel) ifFalse:[removals add: sel]]. removals do:[:sel| self traitRemoveSelector: sel]. "Clean out empty categories" oldCategories do:[:cat| (self organization isEmptyCategoryNamed: cat) ifTrue:[self organization removeCategory: cat]]. self isMeta ifFalse:[self class updateTraitsFrom: aTraitComposition].! ! Not that it bothers me... Andreas is free to do what he likes in his Squeak ;) Cheers, Adrian

Dec. 29, 2009

Re: [Pharo-project] My idea of Metacello configurations for Pharo

by Dale Henrichs

Unloading isn't supported in Metacello, yet. At various points in time in the past I have had unloading working in Metacello, from the perspective of using the dependency information to determine what packages should be unloaded and what order to unload things. But, I thought it was important to get all of the loading logic complete before attempting to deal with unloading issues. I expect that I will be using Gofer to do the actual unloading (as it is used for the loading), so it isn't the intent of Metacello to handle overrides any better or worse than Gofer/MC does:) Dale ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | Looks good! | You haven't mentioned unloading. This is an important topic in my | opinion. | | Alexandre | | On 29 Dec 2009, at 15:11, Mariano Martinez Peck wrote: | | > Hi folks. I just wanted to write down my ideas of the Metacello | > configurations for our Pharo Images. The idea is to use Metacello to | | > manage the dependencies and version of the packages, have a history | | > of the releases and be more modular. You will be able to take a core | | > image and easily load what you want. We will have a | > ConfigurationOfPharo and that's what you will probably use. However, | | > this conf depends and delegates to another configurations (the conf | | > of each package). So, the first step is to make each little conf to | | > work, and then, we focus in the pharo one. | > | > So....lists of points: | > | > 1) I have been writing several configurations so far. One | > configuration per external project that is loaded in Pharo Dev | > images. Examples: Shout, OCompletion, RefactoringBrowser, | > OmniBroswer, O2, etc.. | > The idea is to implement and be sure each of this conf is working | > before doing the ConfigurationOfPharo. | > | > 2) All configurations will be published here: | http://www.squeaksource.com/MetacelloRepository | > This repository is like the ibiblio for maven, or the Universe for | | > the apt-get, or similar. In a near future we will have tools that | > work with this (Esteban Lorenzano is working in Loader for | example). | > | > 3) Each configuration must be PERFECTLY loaded in a Pharo Core image | | > without doing or installing nothing. To do this, I have to declare | | > properly the dependencies. | > This mean, that you will be able to take a core image load the | > ConfigurationOfShout for exameple, or OCompletion and you will be | > able to load it. Metacello will take care of all the dependencies. | > You will also be able to install part of the project and not all | > (for example, only core or core + tests, or whatever). | > | > 4) I started with the Dev packages. We will do this test first to | > see if Metacello really help us in our project. If this goes well, | | > then, in a second step, we will take care about the Web images. | > | > 5) I started with the 1.0 Dev packages. 1.1 is unestable and several | | > external packages even don't load in it. So, will do 1.1 in a second | | > step. | > | > 6) As there were no versions of Metacello in all the external | > projects, I started with 1.0 in ALL. Shout 1.0, OCompletion 1.0, RB | | > 1.0, etc. This has nothing to do with Pharo 1.0. They are just the | | > version number. And after this is released, we really need PLEASE, | | > that the maintainers of those packages also creates the following | > versions for them. | > | > 7) I took as a base, the versions of the 10496 image. I have been | > using this image since in was release, 12 hours a day, and seems to | | > be very stable to me. I mean, the version 1.0 of | > ConfigurationOfPharo will be like the 10496 image. When everything | | > is done and working, create a new image will be very easy. | > | > 8) We need some features from Metacello which are in the todo list. | | > So, we will have to wait a bit for them. | > | > OK, that's all. What do you think? | > | > Soon I will send an email for the configurations of all projects and | | > will ask for help and feedback from their developers. | > | > Cheers, | > | > Mariano | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project(a)lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | | | | | | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 29, 2009

Re: [Pharo-project] Pharo-project Digest, Vol 20, Issue 285

by Mariano Martinez Peck

On Tue, Dec 29, 2009 at 4:41 PM, Colin Putney <cputney(a)wiresong.ca> wrote: > > On 2009-12-28, at 7:10 PM, pharo-project-request(a)lists.gforge.inria.frwrote: > > >>> > >>> Right now, in our Pharo images we are loading the following packages > from > >>> http://source.wiresong.ca/ob > >> > >> AFAIK, the updated code from > >> http://source.lukas-renggli.ch/omnibrowser hasn't been merged into the > >> repository of Colin yet. I assume that will happen sometime soon. > >> > >> > > > > Colin: Right now we are building our official Pharo images using > > http://source.wiresong.ca/ob repository, not > > http://source.lukas-renggli.ch/omnibrowser > > > > Do you think that this can be merged ? > > Yes. I definitely want to have a new release that includes all of Lukas' > latest work, pulled from the wiresong repository. I'm just a bit bogged down > in Real Life at the moment. :-) > > Ok perfect. Take it easy :) Just let us know when this happens. Thank you very much, Mariano > Colin > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 29, 2009

Re: [Pharo-project] Issue with gofer/metacello

by Alexandre Bergel

I haven't found a better way to load Mondrian in the last Pharo than this incantation: -=-=-=-=-=-=-=-=-=-=-=-= [Gofer new renggli: 'gofer'; version: 'Gofer-lr.86'; load] on: Error do: []. Gofer new squeaksource: 'Mondrian'; addPackage: 'ConfigurationOfMondrian'; load. (Smalltalk at: #ConfigurationOfMondrian) perform: #loadDefault. -=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre On 27 Dec 2009, at 18:35, Tudor Girba wrote: > Hi, > > The problem is that Metacello is not quite working with the latest > Gofer. > > Cheers, > Doru > > > On 27 Dec 2009, at 17:39, Alexandre Bergel wrote: > >> Hi Lukas, >> >> In a fresh 10502 I evaluated: >> -=-=-=-=-=-=-=-=-= >> [ Gofer gofer load ] >> on: Error >> do: [ :err | err retry ]. >> Gofer gofer recompile. >> Gofer new >> squeaksource: 'Mondrian'; >> addPackage: 'ConfigurationOfMondrian'; >> load. >> (Smalltalk at: #ConfigurationOfMondrian) perform: #loadLastStable. >> -=-=-=-=-=-=-=-=-= >> >> I have the same error. >> The error comes from: >> >> -=-=-=-=-=-=-=-=-= >> MetacelloMCProject>>updateProject >> "load the latest version of the configuration package" >> >> | mcLoader | >> (mcLoader := self loader) == nil >> ifTrue: [ mcLoader := self project loaderClass on: nil ]. >> mcLoader doingLoads: [ >> | gofer | >> gofer := Gofer new. >> MCWorkingCopy >> managersForClass: self configuration class >> do: [:mgr | >> gofer add: (GoferPackageReference name: mgr packageName >> repository: mgr repositoryGroup) versionReference. >> Transcript cr; show: 'Loading -> ', mgr packageName, ' <-' ]. >> gofer load ]. >> ^true >> -=-=-=-=-=-=-=-=-= >> >> Cheers, >> Alexandre >> >> On 27 Dec 2009, at 17:27, Lukas Renggli wrote: >> >>>> After proceeding these warnings, I have a rollback: MNU >>>> GoferPackageReference class>>name:repository: >>> >>> Can you evaluate >>> >>> [ Gofer gofer load ] >>> on: Error >>> do: [ :err | err retry ]. >>> Gofer gofer recompile. >>> >>> ? I don't have any senders of #name:repository: to >>> GoferPackageReference. >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "From an abstract enough point of view, any two things are similar." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 29, 2009

[Pharo-project] Fwd: [update 1.1] #11120

by StÃ©phane Ducasse

> 11120 > ----- > > - Cleaning some tests. > #testSort, #testRestoreDefaultFonts > - Issue 1691: Adding some tests for formalParameterAt: from nicolas > - Moved FixedIdentitySet to Collections-Unordered > - Better comments. > - Better shuffledBy: > - Issue 1713: Clean Duplication in widthOfString:from:to: > > >

Dec. 29, 2009

Re: [Pharo-project] My idea of Metacello configurations for Pharo

by StÃ©phane Ducasse

On Dec 29, 2009, at 9:40 PM, Alexandre Bergel wrote: > override is probably a problem for unloading. Maybe Stef's > substitution of PackageInfo will help. I do not think so since this is not my goal. I do not want to replace MC just packageInfo. > But already having a solution for unloading a configuration that does > not override will be great. > > Alexandre > > On 29 Dec 2009, at 21:33, Mariano Martinez Peck wrote: > >> >> >> On Tue, Dec 29, 2009 at 9:27 PM, Alexandre Bergel >> <alexandre(a)bergel.eu> wrote: >> Looks good! >> You haven't mentioned unloading. This is an important topic in my >> opinion. >> >> >> Yes, that's true. I am 100% agree. However, these were my little >> next steps for the Metacello configurations for Pharo. >> Regarding the unload, I really don't know who should provide that, >> Metacello ? Monticello ? Pharo it self? >> Does someone know about this? The main problem are the overrides >> because you should go back to anothe version, and I don't know if >> you have it or you loose it. >> >> Thanks >> >> Mariano >> >> Alexandre >> >> On 29 Dec 2009, at 15:11, Mariano Martinez Peck wrote: >> >>> Hi folks. I just wanted to write down my ideas of the Metacello >>> configurations for our Pharo Images. The idea is to use Metacello to >>> manage the dependencies and version of the packages, have a history >>> of the releases and be more modular. You will be able to take a core >>> image and easily load what you want. We will have a >>> ConfigurationOfPharo and that's what you will probably use. However, >>> this conf depends and delegates to another configurations (the conf >>> of each package). So, the first step is to make each little conf to >>> work, and then, we focus in the pharo one. >>> >>> So....lists of points: >>> >>> 1) I have been writing several configurations so far. One >>> configuration per external project that is loaded in Pharo Dev >>> images. Examples: Shout, OCompletion, RefactoringBrowser, >>> OmniBroswer, O2, etc.. >>> The idea is to implement and be sure each of this conf is working >>> before doing the ConfigurationOfPharo. >>> >>> 2) All configurations will be published here: http://www.squeaksource.com/MetacelloRepository >>> This repository is like the ibiblio for maven, or the Universe for >>> the apt-get, or similar. In a near future we will have tools that >>> work with this (Esteban Lorenzano is working in Loader for example). >>> >>> 3) Each configuration must be PERFECTLY loaded in a Pharo Core image >>> without doing or installing nothing. To do this, I have to declare >>> properly the dependencies. >>> This mean, that you will be able to take a core image load the >>> ConfigurationOfShout for exameple, or OCompletion and you will be >>> able to load it. Metacello will take care of all the dependencies. >>> You will also be able to install part of the project and not all >>> (for example, only core or core + tests, or whatever). >>> >>> 4) I started with the Dev packages. We will do this test first to >>> see if Metacello really help us in our project. If this goes well, >>> then, in a second step, we will take care about the Web images. >>> >>> 5) I started with the 1.0 Dev packages. 1.1 is unestable and several >>> external packages even don't load in it. So, will do 1.1 in a second >>> step. >>> >>> 6) As there were no versions of Metacello in all the external >>> projects, I started with 1.0 in ALL. Shout 1.0, OCompletion 1.0, RB >>> 1.0, etc. This has nothing to do with Pharo 1.0. They are just the >>> version number. And after this is released, we really need PLEASE, >>> that the maintainers of those packages also creates the following >>> versions for them. >>> >>> 7) I took as a base, the versions of the 10496 image. I have been >>> using this image since in was release, 12 hours a day, and seems to >>> be very stable to me. I mean, the version 1.0 of >>> ConfigurationOfPharo will be like the 10496 image. When everything >>> is done and working, create a new image will be very easy. >>> >>> 8) We need some features from Metacello which are in the todo list. >>> So, we will have to wait a bit for them. >>> >>> OK, that's all. What do you think? >>> >>> Soon I will send an email for the configurations of all projects and >>> will ask for help and feedback from their developers. >>> >>> Cheers, >>> >>> Mariano >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 29, 2009

Re: [Pharo-project] ImageSegment fixes in Inbox

by StÃ©phane Ducasse

> Sheridan is in holidays. As I will start with the cleaning and refactor soon I wanted to commit a version that at least fixes the current problems. I imagine. > However, I wouldn't commit them in 1.0, just 1.1. Yes 1.0 should only accept a fix for the double past problem. > But.....I have been testing this in 1.0. The problem is that in 1.1 ImageSegment doesn't work anymore because of the Issue 1075: Clean officialClass and isSystemDefined > Search senders for isSystemDefined and you will see several. I don't know how to fix them :( indeed we should not have senders of them in the image if we removed the behavior. > I should check that. Please > > It would be cool if Adrian could also give some feedback, but I think he is in Holidays too. I cc him just in case. > > I have written 20 unit tests also that I can commit if you want. Only one is yellow in 1.0. cool. It would be probably good too. Stef > > Cheers > > Mariano > > On Dec 29, 2009, at 9:19 PM, Mariano Martinez Peck wrote: > > > Hi! After several days of surfing the beatiful ImageSegment code, I fixed several issues. I commit to Inbox the SLICE-FixesToImageSegment. > > > > > > This are the changes in my commit: > > > > - Removed Beeper beepPrimitive from ImageSegment >> install > > - Fix to writeToFile. See issue 1204 > > http://code.google.com/p/pharo/issues/detail?id=1204 > > - Now ImageSegment >> discoverActiveClasses answer the number of them > > - New method ImageSegment >> unActiveClasses > > - Fix to ImageSegment >> swapOutInactiveClasses. I have to hold the allSymbols and to > > exclude the Multilingual and Kernel package from the swap. This should fix issues > > 1203 and 1204. > > - The errors for wrong states now print the current state and also the expected one. > > - Fix issue 207. > > > > > > Take a clean image and evaluate: > > > > Smalltalk at: #MDFaultDict put: Dictionary new. > > > > Then > > > > | count | > > count := ImageSegment discoverActiveClasses. > > Transcript show: 'Classes forced: ', count asString. > > > > Do something > > > > And finally evaluate > > > > | count | > > count := ImageSegment activeClasses size. > > Transcript show: 'Classes active ', count asString. > > > > or > > > > | count | > > count := ImageSegment unActiveClasses size. > > Transcript show: 'Classes active ', count asString. > > > > Whit this, there is no trace. Even if puting the dictionary. > > A simple hack to see this is to change activeClasses to use > > recoverFromMDFaultWithTrace instead of recoverFromMDFault > > If you do that, you will be able to inspect Smalltalk at: #MDFaultDict > > > > > > I also fixed the swapOutInactiveClasses. The image have several emergency windows before this. > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 29, 2009

Re: [Pharo-project] My idea of Metacello configurations for Pharo

by Mariano Martinez Peck

On Tue, Dec 29, 2009 at 9:40 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > override is probably a problem for unloading. Maybe Stef's > substitution of PackageInfo will help. > But already having a solution for unloading a configuration that does > not override will be great. > We don't have this already ? I thought we had that :( > > Alexandre > > On 29 Dec 2009, at 21:33, Mariano Martinez Peck wrote: > > > > > > > On Tue, Dec 29, 2009 at 9:27 PM, Alexandre Bergel > > <alexandre(a)bergel.eu> wrote: > > Looks good! > > You haven't mentioned unloading. This is an important topic in my > > opinion. > > > > > > Yes, that's true. I am 100% agree. However, these were my little > > next steps for the Metacello configurations for Pharo. > > Regarding the unload, I really don't know who should provide that, > > Metacello ? Monticello ? Pharo it self? > > Does someone know about this? The main problem are the overrides > > because you should go back to anothe version, and I don't know if > > you have it or you loose it. > > > > Thanks > > > > Mariano > > > > Alexandre > > > > On 29 Dec 2009, at 15:11, Mariano Martinez Peck wrote: > > > > > Hi folks. I just wanted to write down my ideas of the Metacello > > > configurations for our Pharo Images. The idea is to use Metacello to > > > manage the dependencies and version of the packages, have a history > > > of the releases and be more modular. You will be able to take a core > > > image and easily load what you want. We will have a > > > ConfigurationOfPharo and that's what you will probably use. However, > > > this conf depends and delegates to another configurations (the conf > > > of each package). So, the first step is to make each little conf to > > > work, and then, we focus in the pharo one. > > > > > > So....lists of points: > > > > > > 1) I have been writing several configurations so far. One > > > configuration per external project that is loaded in Pharo Dev > > > images. Examples: Shout, OCompletion, RefactoringBrowser, > > > OmniBroswer, O2, etc.. > > > The idea is to implement and be sure each of this conf is working > > > before doing the ConfigurationOfPharo. > > > > > > 2) All configurations will be published here: > http://www.squeaksource.com/MetacelloRepository > > > This repository is like the ibiblio for maven, or the Universe for > > > the apt-get, or similar. In a near future we will have tools that > > > work with this (Esteban Lorenzano is working in Loader for example). > > > > > > 3) Each configuration must be PERFECTLY loaded in a Pharo Core image > > > without doing or installing nothing. To do this, I have to declare > > > properly the dependencies. > > > This mean, that you will be able to take a core image load the > > > ConfigurationOfShout for exameple, or OCompletion and you will be > > > able to load it. Metacello will take care of all the dependencies. > > > You will also be able to install part of the project and not all > > > (for example, only core or core + tests, or whatever). > > > > > > 4) I started with the Dev packages. We will do this test first to > > > see if Metacello really help us in our project. If this goes well, > > > then, in a second step, we will take care about the Web images. > > > > > > 5) I started with the 1.0 Dev packages. 1.1 is unestable and several > > > external packages even don't load in it. So, will do 1.1 in a second > > > step. > > > > > > 6) As there were no versions of Metacello in all the external > > > projects, I started with 1.0 in ALL. Shout 1.0, OCompletion 1.0, RB > > > 1.0, etc. This has nothing to do with Pharo 1.0. They are just the > > > version number. And after this is released, we really need PLEASE, > > > that the maintainers of those packages also creates the following > > > versions for them. > > > > > > 7) I took as a base, the versions of the 10496 image. I have been > > > using this image since in was release, 12 hours a day, and seems to > > > be very stable to me. I mean, the version 1.0 of > > > ConfigurationOfPharo will be like the 10496 image. When everything > > > is done and working, create a new image will be very easy. > > > > > > 8) We need some features from Metacello which are in the todo list. > > > So, we will have to wait a bit for them. > > > > > > OK, that's all. What do you think? > > > > > > Soon I will send an email for the configurations of all projects and > > > will ask for help and feedback from their developers. > > > > > > Cheers, > > > > > > Mariano > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 29, 2009

Re: [Pharo-project] ImageSegment fixes in Inbox

by Mariano Martinez Peck

On Tue, Dec 29, 2009 at 9:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > cool mariano > Since this code is complex did you ask sheridan to have a look? > > Sheridan is in holidays. As I will start with the cleaning and refactor soon I wanted to commit a version that at least fixes the current problems. However, I wouldn't commit them in 1.0, just 1.1. But.....I have been testing this in 1.0. The problem is that in 1.1 ImageSegment doesn't work anymore because of the Issue 1075: Clean officialClass and isSystemDefined Search senders for isSystemDefined and you will see several. I don't know how to fix them :( I should check that. It would be cool if Adrian could also give some feedback, but I think he is in Holidays too. I cc him just in case. I have written 20 unit tests also that I can commit if you want. Only one is yellow in 1.0. Cheers Mariano > On Dec 29, 2009, at 9:19 PM, Mariano Martinez Peck wrote: > > > Hi! After several days of surfing the beatiful ImageSegment code, I fixed > several issues. I commit to Inbox the SLICE-FixesToImageSegment. > > > > > > This are the changes in my commit: > > > > - Removed Beeper beepPrimitive from ImageSegment >> install > > - Fix to writeToFile. See issue 1204 > > http://code.google.com/p/pharo/issues/detail?id=1204 > > - Now ImageSegment >> discoverActiveClasses answer the number of them > > - New method ImageSegment >> unActiveClasses > > - Fix to ImageSegment >> swapOutInactiveClasses. I have to hold the > allSymbols and to > > exclude the Multilingual and Kernel package from the swap. This should > fix issues > > 1203 and 1204. > > - The errors for wrong states now print the current state and also the > expected one. > > - Fix issue 207. > > > > > > Take a clean image and evaluate: > > > > Smalltalk at: #MDFaultDict put: Dictionary new. > > > > Then > > > > | count | > > count := ImageSegment discoverActiveClasses. > > Transcript show: 'Classes forced: ', count asString. > > > > Do something > > > > And finally evaluate > > > > | count | > > count := ImageSegment activeClasses size. > > Transcript show: 'Classes active ', count asString. > > > > or > > > > | count | > > count := ImageSegment unActiveClasses size. > > Transcript show: 'Classes active ', count asString. > > > > Whit this, there is no trace. Even if puting the dictionary. > > A simple hack to see this is to change activeClasses to use > > recoverFromMDFaultWithTrace instead of recoverFromMDFault > > If you do that, you will be able to inspect Smalltalk at: #MDFaultDict > > > > > > I also fixed the swapOutInactiveClasses. The image have several emergency > windows before this. > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 29, 2009

Re: [Pharo-project] My idea of Metacello configurations for Pharo

by Alexandre Bergel

override is probably a problem for unloading. Maybe Stef's substitution of PackageInfo will help. But already having a solution for unloading a configuration that does not override will be great. Alexandre On 29 Dec 2009, at 21:33, Mariano Martinez Peck wrote: > > > On Tue, Dec 29, 2009 at 9:27 PM, Alexandre Bergel > <alexandre(a)bergel.eu> wrote: > Looks good! > You haven't mentioned unloading. This is an important topic in my > opinion. > > > Yes, that's true. I am 100% agree. However, these were my little > next steps for the Metacello configurations for Pharo. > Regarding the unload, I really don't know who should provide that, > Metacello ? Monticello ? Pharo it self? > Does someone know about this? The main problem are the overrides > because you should go back to anothe version, and I don't know if > you have it or you loose it. > > Thanks > > Mariano > > Alexandre > > On 29 Dec 2009, at 15:11, Mariano Martinez Peck wrote: > > > Hi folks. I just wanted to write down my ideas of the Metacello > > configurations for our Pharo Images. The idea is to use Metacello to > > manage the dependencies and version of the packages, have a history > > of the releases and be more modular. You will be able to take a core > > image and easily load what you want. We will have a > > ConfigurationOfPharo and that's what you will probably use. However, > > this conf depends and delegates to another configurations (the conf > > of each package). So, the first step is to make each little conf to > > work, and then, we focus in the pharo one. > > > > So....lists of points: > > > > 1) I have been writing several configurations so far. One > > configuration per external project that is loaded in Pharo Dev > > images. Examples: Shout, OCompletion, RefactoringBrowser, > > OmniBroswer, O2, etc.. > > The idea is to implement and be sure each of this conf is working > > before doing the ConfigurationOfPharo. > > > > 2) All configurations will be published here: http://www.squeaksource.com/MetacelloRepository > > This repository is like the ibiblio for maven, or the Universe for > > the apt-get, or similar. In a near future we will have tools that > > work with this (Esteban Lorenzano is working in Loader for example). > > > > 3) Each configuration must be PERFECTLY loaded in a Pharo Core image > > without doing or installing nothing. To do this, I have to declare > > properly the dependencies. > > This mean, that you will be able to take a core image load the > > ConfigurationOfShout for exameple, or OCompletion and you will be > > able to load it. Metacello will take care of all the dependencies. > > You will also be able to install part of the project and not all > > (for example, only core or core + tests, or whatever). > > > > 4) I started with the Dev packages. We will do this test first to > > see if Metacello really help us in our project. If this goes well, > > then, in a second step, we will take care about the Web images. > > > > 5) I started with the 1.0 Dev packages. 1.1 is unestable and several > > external packages even don't load in it. So, will do 1.1 in a second > > step. > > > > 6) As there were no versions of Metacello in all the external > > projects, I started with 1.0 in ALL. Shout 1.0, OCompletion 1.0, RB > > 1.0, etc. This has nothing to do with Pharo 1.0. They are just the > > version number. And after this is released, we really need PLEASE, > > that the maintainers of those packages also creates the following > > versions for them. > > > > 7) I took as a base, the versions of the 10496 image. I have been > > using this image since in was release, 12 hours a day, and seems to > > be very stable to me. I mean, the version 1.0 of > > ConfigurationOfPharo will be like the 10496 image. When everything > > is done and working, create a new image will be very easy. > > > > 8) We need some features from Metacello which are in the todo list. > > So, we will have to wait a bit for them. > > > > OK, that's all. What do you think? > > > > Soon I will send an email for the configurations of all projects and > > will ask for help and feedback from their developers. > > > > Cheers, > > > > Mariano > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 29, 2009