February 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] PhD proposal: Software re-modularization

by Marcus Denker

(I am reposting this with updated links) The RMoD team at INRIA Lille / France is offering a PhD position. "Software re-modularization". Applications must be submitted online, the deadline is *Mai 4*. More information and online application: http://bit.ly/ajc1N8 More on doing a PhD at INRIA: http://www.inria.fr/travailler/opportunites/doc.en.html ====================================================================== Software re-modularization ========================== Position type: PhD Student Functional area: Lille (Villeneuve d'Asq) Project: RMOD Environnement ============= For organizations, each software system represents a significant investment in time, resources, and knowledge. It is fundamental to keep these systems effective to protect this investment. On the other side, constant evolution of the systems produces an âarchitectural driftâ where the initial architecture no longer fits the necessities of the new requirements. To fight this trend, one must re-architecture the system, which could sometimes be compared to re-engineer a hand made canoe to a full cruise ship while at sea. Research already made good progress, proposing tools that detect the necessity of architecture re-engineering and point at the most urgent needs. These tools work by analyzing class dependencies (e.g., when a class makes a call to a method in another class) and relying on the high cohesion/low coupling principle: A good architecture should ensure that packages have high cohesion (lots of dependencies between their classes) and low coupling with other (few dependencies between classes in one package and classes outside the package). But re-modularization is still a difficult task, for example a lot of solutions may be possible in any specific case, not one with clear advantages over the others. The next research step is therefore to propose tools helping software engineers to actually perform and assess these modularizations. Several paths will be explored, independently or jointly: - Exploration of the space of all possible re-modularization solutions. Visual tools and/or tools based on metrics could help software engineers foresee and understand the costs and consequences of several different re-modularization options so as to help them choose the best one. - Define a quality model to assess different re-modularisations. There is a need to compare multiple solutions of remodularisation actions. - Identification of a catalog of high-level re-modularization operations. Just like modern IDE offer high-level refactoring operations (rename an attribute, move a method), one could identify what high-level operations (for example, cut cycle) would be necessary and sufficient to perform most re-modularization. - Combining these two approaches, one can even imagine a tool that would explore alone the possible options and choose the best(s) one(s) according to some pre-establish quality model. This would somehow be similar to a program that plays chess and explore the space of possible play to choose the most promising one toward a win. Missions ======== The goals of the project are multiple and could be explored independently: - exploring existing high level re-factoring operations; - perform re-modularization so as to identify possibly recurrent high-level operations; - implementing tools to apply these high-level re-modularization operations; - definition of metrics and tools to visualize concurrently different possible re-modularization solutions; - definition of quality and cost models for re-modularization; exploring heuristic to choose the best re-modularization operations to apply in specific cases. CompÃ©tences et Profil ===================== - object-oriented programming with knowledge of Smalltalk - experience in software maintenance and re-factoring - english - good communication Informations complÃ©mentaires ============================ Chercheur(s) Ã contacter pour plus dâinformation/advisors : StÃ©phane Ducasse: stephane.ducasse(a)inria.fr Nicolas Anquetil: nicolas.anquetil(a)inria.fr References =========== [1] S. Ducasse, D. Pollet, M. Suen, H. Abdeen, I. Alloui, âPackage Surface Blueprints: Visually Supporting the Understanding of Package Relationshipsâ, IEEE International Conference on Software Maintenance, 2007. ICSM 2007, IEEE Comp. Soc. Press, pp. 94-103 [2] S. Ducasse, D. Pollet, âSoftware Architecture Reconstruction: a Process-Oriented Taxonomyâ, IEEE Transactions on Software Engineering, IEEE Comp. Soc. Press, 35(4), pp. 573-591, 2009 [3] O. Seng, M. Bauer, M. Biehl, G. Pache, âSearch-based Improvement of Subsystem Decompositionsâ, Proceedings of the 2005 conference on Genetic and evolutionary computation, ACM, pp. 1045 - 1051, 2005 [4] O. Seng, J. Stammel, D. Burkhart, âSearch-Based Determination of Refactorings for Improving the Class Structure of Object-Oriented Systemsâ, Proceedings of the 8th annual conference on Genetic and evolutionary computation, ACM, pp. 1909 â 1916, 2006. [5] J.B. Tran, M.W. Godfrey, E.H.S. Lee, R.C. Holt, âArchitectural Repair of Open Source Softwareâ, 8th International Workshop on Program Comprehension (IWPC'00), IEEE Comp. Soc. Press, p. 48, 2000 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 28, 2010

[Pharo-project] Postdoc position: Reflection

by Marcus Denker

(I am reposting this with updated links) The RMoD team at INRIA Lille / France is offering a postdoc position: "Reflection and Scoping in Dynamic Languages". Applications must be submitted online, the deadline is *March 14th*. More information and online application: http://bit.ly/9GYHAx More on Postocs at INRIA: http://www.inria.fr/travailler/opportunites/postdoc/postdoc.en.html Reflection and Scoping in Dynamic Languages =========================================== Position type: Post-doctoral Fellow Functional area: Lille (Villeneuve d'Asq) Project: RMOD ====================================================================== Environnement ============= To support the creation and evolution of complex systems, language need support for reflection and context. A reflective system contains a model of itself for enabling runtime change. Context provides a way to model and react to the context the system is embedded in. Reflection is an established research theme and has seen a lot of work over the last decades. Contextual languages, in contrast are a relatively new direction of research. It has recently gotten popular, with a number of dedicated workshops and a lot of active work going on at the moment. As a new research topic, it poses many open questions. Even fundamental questions, for example, how to model context, are discussed. Missions ======== The following points should be explored: - Study existing models of context. - Model composition of contexts and context reuse. - Explore and Model context propagation - Propose a new, general model of context to support further research on context in reflective systems. The model will be implemented in a dynamic, object-oriented language. - Evaluate contexts as a first class language feature. - Extend the model to provide enhanced reflection on context CompÃ©tences et Profil ===================== Reflective programming - Smalltalk / C - English Informations complÃ©mentaires ============================= Chercheur(s) Ã contacter pour plus dâinformation/advisors : StÃ©phane Ducasse : stephane.ducasse(a)inria.fr Marcus Denker : marcus.denker(a)inria.fr Bibliographical References: ============================ [1] Pascal Costanza and Robert Hirschfeld. Reflective layer activation in ContextL. In SAC â07: Proceedings of the 2007 ACM Symposium on Applied Computing, pages 1280â1285, New York, NY, USA, 2007. ACM Press. [2] Marcus Denker, Mathieu Suen, and StÃ©phane Ducasse. The meta in meta-object architectures. In Proceedings of TOOLS EUROPE 2008, volume 11 of LNBIP, pages 218â237, 2008. [3] Eric Tanter. Contextual values. In Proceedings of the 4th ACM Dynamic Languages Symposium (DLS 2008), Paphos, Cyprus, jul 2008. ACM Press. [4] Eric Tanter. Expressive scoping of dynamically-deployed aspects. In Proceedings of the 7th ACM International Conference on Aspect-Oriented Software Development (AOSD 2008), pages 168â179, Brussels, Belgium, April 2008. ACM Press. [5] Eric Tanter, Kris Gybels, Marcus Denker, and Alexandre Bergel. Context-aware aspects. In Proceedings of the 5th International Symposium on Software Composition (SC 2006), volume 4089 of LNCS, pages 227â242, Vienna, Austria, March 2006. [6] Robert Hirschfeld, Pascal Costanza, and Oscar Nierstrasz. Context-oriented programming. Journal of Object Technology, 7(3), March 2008. [7] Martin von LÃ¶wis, Marcus Denker, and Oscar Nierstrasz. Context-oriented programming: Beyond layers. In Proceedings of the 2007 International Conference on Dynamic Languages (ICDL 2007), pages 143â156. ACM Digital Library, 2007. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 28, 2010

[Pharo-project] Postdoc position: Trait-based Language

by Marcus Denker

(I am reposting this with updated links) The RMoD team at INRIA Lille / France is offering a postdoc position: "Designing a pure trait-based language". Applications must be submitted online, the deadline is *March 14th*. More information and online application: http://bit.ly/cGkzn9 More on Postocs at INRIA: http://www.inria.fr/travailler/opportunites/postdoc/postdoc.en.html ====================================================================== Designing a pure trait-based language ===================================== Position type: Post-doctoral Fellow Functional area: Lille (Villeneuve d'Asq) Project: RMOD Environnement ============= Recently, traits have been proposed as a single inheritance backward compatible solution in which the composing entity has the control over the trait composition. Traits are fine-grained units used to compose classes, while avoiding many problems of inheritance and mixin-based approaches. To evaluate the expressiveness of traits, some hierarchies were refactored, showing code reuse. However, such large refactorings, while valuable, may not be facing all the problems, since the hierarchies were previously expressed within single inheritance and following certain patterns. In addition traits have always been considered in addition to class inheritance but not as the main composition and reuse mechanism. Missions ======= We are in the process of designing a pure traits based language. We want to evaluate the impact of having only traits as building blocks and removing inheritance from an object-oriented language. We expect the candidate to take part of the design of a pure traits-based programming language, to perform analysis on large pieces of software for remodularisation purposes and redesign a library. We expect the candidate to implement the core of a pure trait-based language and some representative examples. CompÃ©tences et Profil ==================== - have good skills in interpretation of object-oriented programming languages (classbased, prototypes, mixins...) - have an expertise in object-oriented programming languages outside Java, C++ and C# - be fluent in English Informations complÃ©mentaires ============================= Chercheur(s) Ã contacter pour plus dâinformation/advisors : StÃ©phane Ducasse : stephane.ducasse(a)inria.fr Marcus Denker : marcus.denker(a)inria.fr Bibliographical References: =========================== [1] Alexandre Bergel, StÃ©phane Ducasse, Oscar Nierstrasz and Roel Wuyts, Stateful Traits and their Formalization, Journal of Computer Languages, Systems and Structures, 2008. [2] Damien Cassou, StÃ©phane Ducasse and Roel Wuyts, Redesigning with Traits: the Nile Stream trait-based Library, International Conference on Dynamic Languages 2007, 2007, pp. 50-79. [3] StÃ©phane Ducasse, Oscar Nierstrasz, Nathanael Schaerli, Roel Wuyts and Andrew Black, Traits: A Mechanism for fine-grained Reuse, ACM Transactions on Programming Languages and Systems (TOPLAS), vol. 28, no. 2, March 2006, pp. 331-388. [5] Nathanael Schaerli, StÃ©phane Ducasse, Oscar Nierstrasz and Andrew Black, Traits: Composable Units of Behavior, Proceedings of European Conference on Object-Oriented Programming (ECOOP'03), LNCS, vol. 2743, Springer Verlag, July 2003, pp. 248-274. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 28, 2010

Re: [Pharo-project] Introducing Myself / FFI comments

by Igor Stasenko

On 28 February 2010 07:54, Andreas Raab <andreas.raab(a)gmx.de> wrote: > Folks - > > > Back to lurking for now, wait.. i'd really like to have eventually <apicall: 'Win32HBrush CreateSolidBrush (ulong)' module: 'gdi32.dll'> instead of: <apicall: Win32HBrush 'CreateSolidBrush' (ulong) module: 'gdi32.dll'> so, pragma syntax will be consistent. Yes, backwards compatibility hurts. Yes everything has its costs, but.. do you willing to reopen this topic again (after 4 years passed) towards making FFI pragmas pluggable into parser/compiler? By pluggable i mean that by loading next-gen FFI package, there will be no need to patch/add not a single method in parser/compiler. I think its quite easy to write some code which helps with transition automation. I imagine a following process: - write a new FFI-Legacy package, which supports transition to new format then user: - loads this package, before loading any code which using FFI - load any code which using FFI , during which it should be automatically converted to new pragma format(s) - save converted code - user now free to unload FFI-Legacy and use new pragma syntax. > Â - Andreas > > > _______________________________________________ > 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.

Feb. 28, 2010

[Pharo-project] Introducing Myself / FFI comments

by Andreas Raab

Folks - After long hesitation I've decided to subscribe to the Pharo list. I'm doing this mostly to put perspective on some issues that have come up here and where I feel I have a unique perspective on them. If you haven't guessed, I've been called many unfriendly names here, most recently "the FFI maintainer". Let's start there with putting some perspective on the issues. Fortunately, all of this discussion has been archived so we don't need to play "he said, she said" but I can just point you to the messages themselves. Lukas claims: "In fact we had that in Squeak 3.9 and early Pharo versions. I even wrote code that adapted this mechanism for FFI, but the FFI maintainer insisted on sticking with his compiler hacks." What Lukas *isn't* mentioning is that his proposal would have rendered all FFI code ever written nonfunctional and non-loadable. Practically speaking, it would have simplified two methods with fifty lines of code at the expense of making six years of work of many people unusable: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/106992.h… http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107037.h… http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107039.h… http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107204.h… Then of course, Stef threw in his usual good-natured self and changed what had been a relatively issue-focused discussion into an old-fashioned personal assault: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107124.h… http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107134.h… Despite that I proposed what I felt might be a workable alternative, which got shot down by Lukas in an instant: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107136.h… http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107144.h… A third proposal was made, that I agreed with as will, Lukas ignored the proposal completely: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107313.h… http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107338.h… At the end of the discussion, Lukas still hadn't responded to various compromises that I had offered to discuss with him: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107309.h… http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107337.h… I've certainly had points in the past where some people here have every right to be mad at me and where I've made gross mistakes. But this wasn't one of those times. I've been fairly patient, took the discussion into whichever direction Lukas wanted, made alternative proposals, agreed with third party proposals, didn't even raise to the rhetoric bait that was thrown at me multiple times. The *one* tradeoff I wasn't willing to make for the sake of my users was to break their code; was to make their code non-loadable for absolutely no benefit for these users. Cleaning up two methods and fifty lines of code isn't worth breaking six years of work from lots of people. It wasn't then, it isn't today. And when Stef says "Some people may now understand why we finally decided to do Pharo." then you should probably wonder what that means in the context of this discussion. Finding solutions that benefit *all* parties involved isn't one of his primary strengths in my experience. Back to lurking for now, - Andreas

Feb. 28, 2010

Re: [Pharo-project] Streams. Status and where to go?

by Igor Stasenko

Hi, i'm also did some hacking. I uploaded XTream-Wrappers-sig.1 into SqS/XTream. There is a basic XtreamWrapper class, which should work transparently for any stream (hopefully ;). Next, in subclass i created converter. Sure thing i could also add a buffered wrapper, but maybe later :) Here some benchmarks. The file i used to test is utf-8 russian doc text - in attachment.. | str | str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. { [ str reset. (XtreamUTF8Converter on: str readXtream) upToEnd ] bench. [ str reset. (UTF8Decoder new source: str readXtream) upToEnd ] bench. } #('21.71314741035857 per second.' '14.0371688414393 per second.') #('22.16896345116836 per second.' '14.5186953062848 per second.') Next, buffered | str | str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. { [ str reset. (XtreamUTF8Converter on: str readXtream buffered) upToEnd ] bench. [ str reset. (UTF8Decoder new source: str readXtream buffered) upToEnd ] bench. } #('58.52976428286057 per second.' '25.44225800039754 per second.') #('58.90575079872205 per second.' '25.87064676616916 per second.') I'm also tried double-buffering, but neither my class nor yours currently works with it: | str | str := (StandardFileStream readOnlyFileNamed: 'unitext.txt') readXtream. { [ str reset. (XtreamUTF8Converter on: str readXtream buffered) buffered upToEnd ] bench. [ str reset. (UTF8Decoder new source: str readXtream buffered) buffered upToEnd ] bench. } Please , take a look. There are some quirks which not because i cleaned up decoding/encoding code. See XtreamWrapper>>upToEnd implementation. -- Best regards, Igor Stasenko AKA sig.

Feb. 28, 2010

Re: [Pharo-project] SqueakSave on Pharo

by Yanni Chiu

laurent laffont wrote: > On Fri, Feb 19, 2010 at 9:24 PM, Yanni Chiu > > > > Can you put it on squeaksource ? > > I'll clean up the package I have, and then ping the author for how > contributions are to be handled (before forking it on squeaksource). > BTW, the HPI repository is now back online. Okay, it's at: http://www.squeaksource.com/SqueakSave SqSave-tkow.127.mcz - This version was created from the HPI version by unzip'ing the .mcz, fixing the issues that prevented it from loading into Pharo, by editing the source.st file, then re-zip'ing into a .mcz package. SqSave-YanniChiu.135.mcz - This version was developed for my needs at the time, then clean up somewhat for public release. Using the native postgres driver (and probably dbx one too), the following 3 tests are still failing: >>> SqsCTISearchQueryTest.testQueryBlob >>> SqsCTISearchQueryTest.testReferenceToSubclassElementWithinCollection >>> SqsSTISearchQueryTest.testQueryBlob Some class category names were changed, and some example code left out. The original .127.mcz should be loadable, so you can see what was changed. The repository is set for global read/write. -- Yanni

Feb. 28, 2010

Re: [Pharo-project] Scamper revival

by Schwab,Wilhelm K

I'm in favor of options like this, but remain convinced that the more layers that appear between the ultimate end user software and the hardware, the worse performance will be. A while back I was taking the "Seaside is *not* all we need for a GUI" side of a debate and described my cash cow as "an etch-a-sketch with a type A personality" - got a good laugh when I ran across that a couple of years later. Picture users frantically banging on a tablet, selecting, poking and scribbling. Pardon my lack of vision, but there is no way in hell that HTML+CSS+JavaScript is going to keep up with it. I also have my doubts about our current vms in that respect, though Windows and its bloat would be out of the picture. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eagle Offshore Sent: Saturday, February 27, 2010 5:48 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Scamper revival Quick thought: WebKit plugin with Javascript language binding. http://webkit.org/projects/javascript/index.html Consider the kind of system you could build with html 5 rendered UI. Interesting project: http://phonegap.com Sadly, I have zero time to work on things outside of paying work these days. On Feb 27, 2010, at 7:33 AM, GermÃ¡n Arduino wrote: > I agree with these comments (don't know if the way to go is Polymorph being that I don't know it deeper) but as I also think that Magritte is a BIG help to write almost any sort of applications. > > I we could have a better (more productive) way of write desktop UIs then we can take over the win-linux.mac market :) I would try myself with my PasswordsPro application (currently in Dolphin). It would be nice to me port PasswordsPro to Pharo and sell it as a real desktop app (native in any operating system) and reuse the same model to have it on web also. > > Having a only one model, with UI in desktop and web will be really awesome, even when a lot of people may claim that is possible today, I'm not really convinced with complex applications. > > Cheers. > _______________________________________________ > 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

Feb. 28, 2010

Re: [Pharo-project] Simple (but effective) Optimization of PackageOrganizer

by Alexandre Bergel

Fortunately yes. I am currently on the seaside, these has been some tsunami alert, but I haven't more than a very strong tide. Wondering how I will find my flat in Santiago. Thanks for asking, Alexandre On 27 Feb 2010, at 08:17, Serge Stinckwich wrote: > I see that a big earthquake hit Chile : > http://www.alertnet.org/thenews/newsdesk/LDE61Q02O.htm > I hope everything is ok with you. > > On Fri, Feb 26, 2010 at 6:58 PM, Alexandre Bergel > <alexandre(a)bergel.eu> wrote: >> issue #2085 >> >> Replace the method PackageOrganizer>>packageOfClass: aClass ifNone: >> errorBlock by >> -=-=-=-=-= >> packageOfClass: aClass ifNone: errorBlock >> | classCategory | >> classCategory := aClass category. >> packages at: classCategory ifPresent: [:v | ^ v]. >> >> (classCategory includes: $-) >> ifTrue: [ packages at: (classCategory copyUpTo: $-) >> ifPresent: [:v | >> ^ v] ]. >> >> ^ self packages detect: [:ea | ea includesClass: aClass] >> ifNone: >> errorBlock >> -=-=-=-=-= >> >> Before this enhancement: >> [100 timesRepeat: [Object package]] timeToRun >> => 141 >> >> After the fix: >> => 2 >> >> Easy thing to do. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 >> > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://doesnotunderstand.org/ > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 28, 2010

Re: [Pharo-project] Scamper revival

by Eagle Offshore

Quick thought: WebKit plugin with Javascript language binding. http://webkit.org/projects/javascript/index.html Consider the kind of system you could build with html 5 rendered UI. Interesting project: http://phonegap.com Sadly, I have zero time to work on things outside of paying work these days. On Feb 27, 2010, at 7:33 AM, GermÃ¡n Arduino wrote: > I agree with these comments (don't know if the way to go is Polymorph being that I don't know it deeper) but as I also think that Magritte is a BIG help to write almost any sort of applications. > > I we could have a better (more productive) way of write desktop UIs then we can take over the win-linux.mac market :) I would try myself with my PasswordsPro application (currently in Dolphin). It would be nice to me port PasswordsPro to Pharo and sell it as a real desktop app (native in any operating system) and reuse the same model to have it on web also. > > Having a only one model, with UI in desktop and web will be really awesome, even when a lot of people may claim that is possible today, I'm not really convinced with complex applications. > > Cheers. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010