- Pharo-dev - lists.pharo.org

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

by Adrian Lienhard

On Dec 30, 2009, at 09:53 , StÃ©phane Ducasse wrote: > Adrian > > What I would like to understand > - what part of the require algorithm could we unload? Everything can be unloaded. > because I imagine that the requirement analysis is > for the self sends deep up the hierarchy that may invoke an > explicit requirement > deep down the composition and this is not related > to the simple self explicitRequirement. I would be good to do a > pass because it would > clarify the code. I could give a try but I would prefer you to do > it and also we should not > rush this is not because squeak is getting frantic that we should - > I said that mainly for me. ;) Yes, I can take a look. But as you say, not right now ;) > - what is the impact from the tool perspective to have trait > subclass of class description > I imagine that you get less bug due to Trait dnu superclass and > friend. I'd also like to look closer into NanoTraits. But so far I failed to get a trunk image with it. I downloaded Squeak3.11-8472-alpha.image from the ftp server and did an update to 8660 but I still get the outdated traits implementation of Squeak. Inheriting from ClassDescription you need less code but you inherit too much so I wonder how you deal with the inherited behavior that does not make sense for traits. > I do not care about the install method I imagine that it is long and > you can throw it away. Me neither. This was a joke ;) Adrian > Now let us be smarter than some people think we are :) > What can we learn from nanotrait: > - is the composition more robust (I think that andreas change a bit > the operator) > - is the code simpler? > for example > push traitComposition into TraitOrganizer so that we don't need to > duplicate it in three places (Class, Metaclass, TraitDescription). > of course using trait you do not duplicate > - we have the opportunity to compare and weight pro and cons. > We could even write a workshop paper on it for fun (ok not that > fun :)). > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 30, 2009

[Pharo-project] Pharo-beginner mailing list ?

by StÃ©phane Ducasse

Hi all I remember that the squeak-beginner mailing-list (our ideas) was a huge success since it enabled people to ask questions and have less mails. So a question to you: do you think that it would be good to have a pharo-beginner mailing list? Stef

Dec. 30, 2009

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

by StÃ©phane Ducasse

> Unloading is a BIG problem, because of package overrides. I tried it a > little for Loader and became very frustrated, the whole system become > unstable in most of the unload cases (just the easiest ones are passing > without problem). May be with atomic loading and unloading. It would be easier > I think this functionality just can be achieved with package managers > like DeltaStreams or (maybe) MC2... I don't know if Stef work on > packages will be useful too. I do not think so for now I just want to replace packageInfo. And since I have no time to work on it it is not making progress :( > But until something like that cames to > Pharo, I would vote "no" to project unload (If my vote counts on > something, of course ;) ). For now if we can systematically load well I would be really happy

Dec. 30, 2009

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

by StÃ©phane Ducasse

On Dec 30, 2009, at 10:44 AM, Igor Stasenko wrote: > ----------- > Reposting from squeak-dev (about nanotraits): > > ClassDescription , Metaclass ivars: > traitComposition localSelectors > has no uses. > > Andreas using a TraitMethodProperties to hold a reference to original > method, and then to trait. So, its easy to tell whether method is > local or not, by asking it, without need of keeping a separate state. > I find such approach less error prone, since method is the unit of > manipulation for traits and asking it directly, where it came, seems > more straightforward. > It is, however incurs a little overhead: any method which comes from > trait should keep additional state in > MethodProperties (in fact , a subclass of it), while normally, most of > methods don't need to have it. > And sure thing, copying method over multiple method > dicts, does not require you to care about keeping something else in > sync (except categorizer, maybe). I have to digest that paragraph (a bit difficult). > Stephane, > i appreciate your way of doing things. Really, if something is 'not > invented here' , its a signal to learn from it, how you could improve > things, > but not a signal to start bashing each other over and over again. Thanks. I really believe what I wrote :) No marketing in it. I always want to learn from alternate design. I think that in general there is a chance people need another view to things to understand the world. > For professionals, at first place should be the code, the idea and > quality of implementation, but not where it came from. ;) >> Now let us be smarter than some people think we are :) >> What can we learn from nanotrait: >> - is the composition more robust (I think that andreas change a bit the operator) >> - is the code simpler? >> for example >> push traitComposition into TraitOrganizer so that we don't need to >> duplicate it in three places (Class, Metaclass, TraitDescription). >> of course using trait you do not duplicate >> - we have the opportunity to compare and weight pro and cons. >> We could even write a workshop paper on it for fun (ok not that fun :)). >> Stef >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 30, 2009

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

by Esteban Lorenzano

Unloading is a BIG problem, because of package overrides. I tried it a little for Loader and became very frustrated, the whole system become unstable in most of the unload cases (just the easiest ones are passing without problem). I think this functionality just can be achieved with package managers like DeltaStreams or (maybe) MC2... I don't know if Stef work on packages will be useful too. But until something like that cames to Pharo, I would vote "no" to project unload (If my vote counts on something, of course ;) ). Cheers, Esteban On 2009-12-29 20:02:48 -0300, Dale Henrichs <dale.henrichs(a)gemstone.com> said: > 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. 30, 2009

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

by Igor Stasenko

----------- Reposting from squeak-dev (about nanotraits): ClassDescription , Metaclass ivars: traitComposition localSelectors has no uses. Andreas using a TraitMethodProperties to hold a reference to original method, and then to trait. So, its easy to tell whether method is local or not, by asking it, without need of keeping a separate state. I find such approach less error prone, since method is the unit of manipulation for traits and asking it directly, where it came, seems more straightforward. It is, however incurs a little overhead: any method which comes from trait should keep additional state in MethodProperties (in fact , a subclass of it), while normally, most of methods don't need to have it. And sure thing, copying method over multiple method dicts, does not require you to care about keeping something else in sync (except categorizer, maybe). ---------- Stephane, i appreciate your way of doing things. Really, if something is 'not invented here' , its a signal to learn from it, how you could improve things, but not a signal to start bashing each other over and over again. For professionals, at first place should be the code, the idea and quality of implementation, but not where it came from. 2009/12/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Adrian > > What I would like to understand > Â Â Â Â - what part of the require algorithm could we unload? > Â Â Â Â because I imagine that the requirement analysis is > Â Â Â Â for the self sends deep up the hierarchy that may invoke an explicit requirement > Â Â Â Â deep down the composition and this is not related > Â Â Â Â to the simple self explicitRequirement. I would be good to do a pass because it would > Â Â Â Â clarify the code. I could give a try but I would prefer you to do it and also we should not > Â Â Â Â rush this is not because squeak is getting frantic that we should - I said that mainly for me. ;) > > Â Â Â Â - what is the impact from the tool perspective to have trait subclass of class description > Â Â Â Â I imagine that you get less bug due to Trait dnu superclass and friend. > > I do not care about the install method I imagine that it is long and you can throw it away. > > Now let us be smarter than some people think we are :) > What can we learn from nanotrait: > Â Â Â Â - is the composition more robust (I think that andreas change a bit the operator) > Â Â Â Â - is the code simpler? > Â Â Â Â Â Â Â Â for example > Â Â Â Â Â Â Â Â Â Â Â Â push traitComposition into TraitOrganizer so that we don't need to > Â Â Â Â Â Â Â Â Â Â Â Â duplicate it in three places (Class, Metaclass, TraitDescription). > Â Â Â Â Â Â Â Â Â Â Â Â of course using trait you do not duplicate > Â Â Â Â - we have the opportunity to compare and weight pro and cons. > Â Â Â Â We could even write a workshop paper on it for fun (ok not that fun :)). > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Dec. 30, 2009

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

by StÃ©phane Ducasse

Adrian What I would like to understand - what part of the require algorithm could we unload? because I imagine that the requirement analysis is for the self sends deep up the hierarchy that may invoke an explicit requirement deep down the composition and this is not related to the simple self explicitRequirement. I would be good to do a pass because it would clarify the code. I could give a try but I would prefer you to do it and also we should not rush this is not because squeak is getting frantic that we should - I said that mainly for me. ;) - what is the impact from the tool perspective to have trait subclass of class description I imagine that you get less bug due to Trait dnu superclass and friend. I do not care about the install method I imagine that it is long and you can throw it away. Now let us be smarter than some people think we are :) What can we learn from nanotrait: - is the composition more robust (I think that andreas change a bit the operator) - is the code simpler? for example push traitComposition into TraitOrganizer so that we don't need to duplicate it in three places (Class, Metaclass, TraitDescription). of course using trait you do not duplicate - we have the opportunity to compare and weight pro and cons. We could even write a workshop paper on it for fun (ok not that fun :)). Stef

Dec. 30, 2009

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

by StÃ©phane Ducasse

> > >> - The requires algorithm is not directly related to Traits (as I >> pointed out in a recent mail) > > That's cool, but why is it there? I can reply to you on that one :) Some historical background first. Nathanael (who was hesitating to go to work with andreas - since andreas was really interested to have traits to build user interface for kids - I remember them drawing picture on the board of nathanael and marcus office) implemented a Browser that showed instantaneously where you would need to provide a method because of a trait composition. This was difficult because of the quality of Squeak library (containing a lot of self send to method not existing in Object), the bad state of the browser and because the system is dynamic (you can add a method anytime anywhere). This is explained in depth in his PhD. Nathanael was wise and declined the offer to go to google. I'm sure that he does not feel insulted by certain statement because a lot of languages would like to have traits or introduce them instead of bashing them: Scala, Perl, Fortress... we even got a guy of MS that asked us to apply to get a grant to port trait to C# (boring with types). Nathanael did a first implementation of traits that was driven by tape to fix a lot of places which were suboptimal. Then Adrian reimplemented the core as part of his master thesis. The idea was that Squeak deserved a good trait implementation if we wanted to get a chance to build on them. The state of the Squeak browser was getting in our way (no tree widgets at that time still not today). OB was not an alternative - no tree widgets. So adrian did not get the time and will to fix the Squeak UI lib and build a browser. Now this is just fun to see how some people have the tendency to insult others because I think that adrian is - a really smart guy (got several awards for his work) - talented (run his own company since years in parallel to do research) I mean a real company that is not sponsored but live with the money it collects. Then practically during the last two years, we clean a ***lot*** of problem. Now squeak is starting to clean. Mainly also because nicolas is pushing a lot of fixes from pharo to squeak. And we go at our little speed but we go steadily and we will continue. I imagine that this gives an historical view to the question and I thanks you because we will probably clean it. Stef

Dec. 30, 2009

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

by Levente Uzonyi

On Wed, 30 Dec 2009, Adrian Lienhard wrote: > 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 first line in the table is "nonsense" or just gives a brief overview. > - 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. Well, it's abandoned. > - 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) Correct me if I'm wrong, but PackageInfo >> #methods returns only local selectors, so this is not true. > - The requires algorithm is not directly related to Traits (as I > pointed out in a recent mail) That's cool, but why is it there? > 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 > [...] > Picking one long method is easy. Let's see raw numbers: NanoTraits in Squeak Trunk (update 8660) Package Classes Methods Loc Loc/Method Traits-Composition 5 64 221 3.45 Traits-Kernel 22 91 394 4.33 Traits-Kernel-Traits 17 0 0 - Kernel-Classes 10 589 4754 8.07 Total 54 744 5369 7.22 Traits in Pharo 1.1 (update 11120) Package Classes Methods Loc Loc/Method Traits-Composition 7 122 615 5.04 Traits-Kernel 11 343 1988 5.8 Traits-Kernel-Traits 6 214 1360 6.36 Kernel-Classes 10 460 3931 8.55 Total 34 1139 7894 6.93 According to these numbers, Pharo's traits implementation has less classes, more methods, more code and longer methods (average). (Code to generate the data: String streamContents: [ :stream | #('Traits-Composition' 'Traits-Kernel' 'Traits-Kernel-Traits' 'Kernel-Classes' ) do: [ :packageName | | package methods linesOfCode | package := PackageInfo named: packageName. methods := package methods. linesOfCode := methods detectSum: [ :each | each compiledMethod linesOfCode ]. stream nextPutAll: ( '<1S><T><2P><T><3P><T><4P><T><5P><N>' expandMacrosWithArguments: { packageName. package classes size. methods size. linesOfCode. methods ifEmpty: [ '-' ] ifNotEmpty: [ linesOfCode / methods size roundTo: 0.01 ] }) ] ]) Levente > Not that it bothers me... Andreas is free to do what he likes in his > Squeak ;) > > Cheers, > Adrian > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 30, 2009

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

by Dale Henrichs

I've been able to address the problems with Metacello and pharo1.0-10502-rc1dev09.12.2. Version 1.0-beta.18 (just released see: http://groups.google.com/group/metacello/msg/a12918b4bd11c0ef for the announcement) has been tested with both: - pharo1.0-10493-rc1dev09.11.2 - pharo1.0-10502-rc1dev09.12.2 the class-side #ensureMetacello methods for configurations also need to be updated to work with pharo1.0-10502-rc1dev09.12.2. See: http://code.google.com/p/metacello/wiki/EnsureMetacello for a suggested implementation. I plan to update the #ensureMetacello methods for the configurations in MetacelloRepository tonight. Dale ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | The latest Gofer API is not backward compatible with the earlier | versions of the Gofer API. This means that I need to have different | versions of Metacello to use with the different versions of Gofer. | Unfortunately, I can't use Gofer to detect which version of Gofer is | loaded because of the API changes. So I will have to write more code | than I'd like to detect which version of Gofer is pre-installed. The | API changes also impact the bootstrapping code. | | Solving these problems are a larger project than I can undertake on a | Sunday and I _am_ on vacation the coming week as well. | | So until further notice, if you want to use Metacello 1.0-beta.17 (or | earlier) in Pharo you will have to manually ensure Gofer-lr.83 (or | earlier) is loaded into your image before attempting to load any | Metacello configurations. I'm not sure that you use Gofer to load an | earlier version of itself (I'll be finding out in the next few | days)... | | Metacello 1.0-beta.18 works with Gofer-lr.107 (in pharo 1.0-10502). If | you want to use Metacello 1.0-beta.18 (currently in development, so | it's subject to change). You will have to manually bootstrap Metacello | by executing: | | Gofer new | gemsource: 'metacello'; | package: 'ConfigurationOfMetacello'; | load. | (Smalltalk at: #ConfigurationOfMetacello) perform: | #ensureMetacello18. | ((Smalltalk at: #ConfigurationOfMetacello) project version: | '1.0-beta.18') load: 'ALL'. | | before loading your configuration. | | I won't release 1.0-beta.18 until I've resolved the bootstrapping | problem. I'm pretty sure that there is a technical solution, but it | will take several days for me to get it implemented. | | Dale | | ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | | | Version 1.0-beta.18 (development) should have fixes for the latest | | Gofer. 1.0-beta.18 is currently in #development so it is | automatically | | loaded. When I get the chance to test the Metacello fixes with | 10502, | | I'll #release 1.0-beta.18 (and will be automatically loaded). | | | | Dale | | ----- "Alexandre Bergel" <alexandre(a)bergel.eu> 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 | | | | _______________________________________________ | | Pharo-project mailing list | | Pharo-project(a)lists.gforge.inria.fr | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 30, 2009