- Pharo-dev - lists.pharo.org

[Pharo-project] Postdoctoral position on language design

by StÃ©phane Ducasse

The INRIA RMoD Team led by S. Ducasse has an open position on traits. http://rmod.lille.inria.fr/ http://stephane.ducasse.free.fr/ End of the campaign : May 4, 2009 Beginning of the positions: from September to December 2009 CONTEXT INRIA, the national institute for research in computer science and control, is dedicated to fundamental and applied research in information and communication science and technology (ICST). The Institute has a workforce of 3,700, 2,900 of whom are scientists from INRIA and its partner organizations. INRIA has an annual budget of 162 million euros, 20% of which comes from its own research contracts and development products. INRIA develops many partnerships with industry and fosters technology transfer and company foundations in the field of ICST - some eighty companies have been funded. Startups are financed in particular by INRIA Transfert, a subsidiary of INRIA that supports four startup funds. The international collaborations are based on an incentive strategy of welcoming and recruiting foreign students as well as developing strong exchanges between research scientists. Priority is given to geographic zones with strong growth: Europe, Asia and North America while maintaining reasonable cooperation with South America, Africa and Middle-East. from http://www.inria.fr/lille/scientific-research/research-teams/RMOD_page : The goal of RMoD is to support remodularization of object-oriented applications. This objective is tackled from two complementary perspectives: reengineering and modularity constructs for programming languages. In the reengineering perspective we will propose new analyses to understand and restructure existing large applications (specialized package metrics, adapted visualizations, layer identifications). In the modularity construct context we will work on a pure trait-based language and new modular abstractions. We will also propose the definition of dedicated secure language constructs based on a modular and layered kernel as one direct application of modularization. These programming language constructs will be experimented on Pharo, a platform for dynamic web development. Pharo will be used as a testbed for a pure-traits language, which will be used to assess the impact of modular classes in terms of reuse orthogonally to inheritance. SCIENTIFIC CONTEXT 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 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. Goals 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 piece 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. Expected Skills -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 Bilbiographical 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, Stphane 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. 4 Luigi Liquori and Arnaud Spiwack, FeatherTrait: A Modest Extension of Featherweight Java, ACM Transactions on Programming Languages and Systems (TOPLAS), 2007, To appear. 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. APPLICATION REQUIREMENTS Applicant should have held a doctorate or Ph.D. for less than one year or you are about to obtain one and you would like to carry out a fulfilling research activity in the field of ICST (information and communication science and technology) or in a related field. POSITION SALARY 2,357.30 EUR gross per month (Social security already payed) SOCIAL SECURITY BENEFITS - Entitled to unemployment benefit at the end of the contract; - Affiliated to the French social security system. HOW TO APPLY Thank you for applying directly on the institute's website, by following this link: = http://www.inria.fr/travailler/opportunites/postdoc/postdoc.en.html

Feb. 20, 2009

Re: [Pharo-project] Question about Universes

by Keith Hodges

StÃ©phane Ducasse wrote: > But we do not want hacks. :) and hidden dependencies. > Frankly I do not understand why this is not possible to use a method > (since a method is a script with a name). > Because methods have to compile, or they are not accepted. In bob's case these are scripts that will run in a different image, so do not necessarily compile in Bob's image. In mantis's case these are the bug reports downloaded for searching and reference purposes. I dont regard this as a hack since Smalltalk is designed to have this flexibility of supporting differnnt languages, and syntaxes. If you dont like it then why not remove #compilerClass altogether. If you call this a hack then what is WAFileDirectory? You would think that using methods to store data in the image has never been done before. Keith

Feb. 20, 2009

Re: [Pharo-project] Question about Universes

by StÃ©phane Ducasse

But we do not want hacks. :) and hidden dependencies. Frankly I do not understand why this is not possible to use a method (since a method is a script with a name). >>> >> > Well I never liked it, when I used it last I only had a 700Mhz machine > to work on, it was slow, buggy, menu items I used frequently were > missing. In short it was impossible to actually use. But it is working since years now. I never understood why some Squeakers did not the value of it. For Pharo I would like to have deeper integration of RB engine. Stef

Feb. 20, 2009

Re: [Pharo-project] Question about Universes

by Keith Hodges

Lukas Renggli wrote: >> It doesn't depend upon that compiler hack. That hack provides the >> ability to put textual data in as an appendix to a method. It is an >> entirely independent facility that could be perhaps better included as a >> trait for those that want it. >> > > The version I found in the latest Pharo-Dev images has the compiler > hack loaded and depends on it (or the package definitions). > The package definitions do not depend on it, it allows the compiler to ignore code after 6 quote marks. myMethod ^ self """""" Some text here as documentation. Bob will also use this facility, because it provides a place to put scripts verbatim without having to escape quotes. Again you dont have to use it. >> I don't think it is fair to use code critics as an argument. >> > > You can't deny that references to variables and classes that do not > exist in the system are not a serious bug. > Yes I can, because plainly it hasnt effected use for while. If the tests run then its not a serious bug. These sot of artifacts are unwanted side effects in a rapidly evolving code base, they are not a big deal in the grand scheme of things. >> To me it >> appears that you have developed all of these tools for your own use. >> > > Code Critics is part of the refactoring browser by Don Roberts and John Brant. > > The refactoring browser is one of the most amazing pieces of Smalltalk > code I have ever seen. I am maintaining the code-base in Pharo (and > Well I never liked it, when I used it last I only had a 700Mhz machine to work on, it was slow, buggy, menu items I used frequently were missing. In short it was impossible to actually use. > previously in Squeak), because it makes me much more productive in my > daily work. Code critics provides a huge set of high quality tests for > free that can quickly point out flaws in code. It is not always > correct, but it is usually very good to find the problematic parts of > a system ok Keith

Feb. 20, 2009

Re: [Pharo-project] Question about Universes

by Keith Hodges

Ramon Leon wrote: > > I don't think it is fair to use code critics as an argument. > > I think it's perfectly fair, be it code critic or lint, if it finds > bad code then it finds bad code. It's not like you don't know about > code critics and Lint is already in Squeak, No it is not. I have seen one passing comment about something called SwaLint, on the mailing list that is about all. > so it's your choice if you choose not to avail yourself of tools that > point out badly written code. He writes about the tools he's working > on at his blog http://www.lukas-renggli.ch/blog which is easily > subscribed to. Thanks, I didnt know > There's no reason anyone can say they're unaware of what he's doing > unless they're choosing to be unaware. Well clearly that is not true. Keith

Feb. 20, 2009

Re: [Pharo-project] Question about Universes

by Lukas Renggli

> It doesn't depend upon that compiler hack. That hack provides the > ability to put textual data in as an appendix to a method. It is an > entirely independent facility that could be perhaps better included as a > trait for those that want it. The version I found in the latest Pharo-Dev images has the compiler hack loaded and depends on it (or the package definitions). > I don't think it is fair to use code critics as an argument. You can't deny that references to variables and classes that do not exist in the system are not a serious bug. > To me it > appears that you have developed all of these tools for your own use. Code Critics is part of the refactoring browser by Don Roberts and John Brant. The refactoring browser is one of the most amazing pieces of Smalltalk code I have ever seen. I am maintaining the code-base in Pharo (and previously in Squeak), because it makes me much more productive in my daily work. Code critics provides a huge set of high quality tests for free that can quickly point out flaws in code. It is not always correct, but it is usually very good to find the problematic parts of a system. >> not implemented anywhere. Of course there is not a single test. > What are you talking about: Sake-Tests. I am sorry. I was not aware of that package. I should have checked online. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 19, 2009

[Pharo-project] Fwd: [Seaside] Re: VNC Problem on Gentoo

by StÃ©phane Ducasse

> > > > would be nice to have that fied inheadless mode. > > > Begin forwarded message: > >> From: Andreas Raab <andreas.raab(a)gmx.de> >> Date: February 19, 2009 5:15:40 PM CEST >> To: Seaside - general discussion >> <seaside(a)lists.squeakfoundation.org>, cdshaffer(a)acm.org >> Subject: [Seaside] Re: VNC Problem on Gentoo >> Reply-To: Seaside - general discussion <seaside(a)lists.squeakfoundation.org >> > >> >> C. David Shaffer wrote: >>> Yes, copy through VNC kills the squeak VM (not just the VNC >>> session). This has been the case for as long as I can >>> remember...just never had >>> the time to try to correct it. >> >> The problem is that when you run headless the clipboard primitives >> die. The easiest way to fix this is to just comment out the >> primitive 141 in both primitiveClipboardText/primitiveClipboardText: >> >> Cheers, >> - Andreas >> _______________________________________________ >> seaside mailing list >> seaside(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> > > > >

Feb. 19, 2009

Re: [Pharo-project] Question about Universes

by StÃ©phane Ducasse

Hi keith I will let lukas answers your questions. And I like this discussion because at the end we should all get a better understanding. I like the idea of an integration build server we all need that. Lukas can from time to time build too complex software :) (I know he will smile) but he showed with Seaside that he has a sense of code responsibility. So continue to discuss not argue :) Stef On Feb 19, 2009, at 6:11 PM, Keith Hodges wrote: > Lukas Renggli wrote: >>> You are wrong about Sake I think. >>> >> >> I know Sake. I've written a generator for builder.seaside.st. The >> result (or a modified version of it) is included with the Sake >> distribution as Seaside29Builder. >> >> >>> Sake can declare a universe of >>> known-to-work-together packages. Just take a class, declare the sake >>> tasks you know work together in the image you target and things will >>> be as in universe. >>> >> >> Sure, you can use Sake to build something very similar to a Universe. >> However tasks are not declarative, but instead use a script to >> perform >> some actions. In most cases they call Installer to find and load an >> appropriate version (what is already scary in itself). >> > Why? > > They are "mostly" declarative, following feedback from Andreas. If > the > default script is used it simply analyses the url data given, which is > the case for 99% of packages. >> I understand that Package Universe is too restrictive for some cases, >> however I wouldn't dare to replace it with Sake. Sake depends on a >> stack of hacks, it even uses its own compiler to allow uppercase >> method names. > No it doesnt. > > It doesn't depend upon that compiler hack. That hack provides the > ability to put textual data in as an appendix to a method. It is an > entirely independent facility that could be perhaps better included > as a > trait for those that want it. > > I use it when I want to use methods to be a mini database, in the > Mantis > package, and for Bob to be able to manages build scripts in the image > without having to enclose in quotes and escape quotes. >> In the small codebase Code Critics finds 14 serious bugs >> like non existing inst-variable references and message sents that are >> > I don't think it is fair to use code critics as an argument. To me it > appears that you have developed all of these tools for your own use. I > have never even seen you announce their existence to squeak-dev. > Where > is the documentation? >> not implemented anywhere. Of course there is not a single test. > What are you talking about: Sake-Tests. >> The >> way Sake calculates dependencies is totally strange, I am not sure if >> it is even correct. >> > Again, what do you mean? There are two algorithms in use. The first is > lifted directly from rake. The second is stolen directly from > universes. > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 19, 2009

Re: [Pharo-project] Question about Universes

by StÃ©phane Ducasse

> It doesn't depend upon that compiler hack. That hack provides the > ability to put textual data in as an appendix to a method. It is an > entirely independent facility that could be perhaps better included > as a > trait for those that want it. I do not get that? I use it when I want to use methods to be a mini database, in the Mantis > > package, and for Bob to be able to manages build scripts in the image > without having to enclose in quotes and escape quotes. > >> In the small codebase Code Critics finds 14 serious bugs >> like non existing inst-variable references and message sents that are >> > I don't think it is fair to use code critics as an argument. To me it > appears that you have developed all of these tools for your own use. I > have never even seen you announce their existence to squeak-dev. > Where > is the documentation? >> not implemented anywhere. Of course there is not a single test. > What are you talking about: Sake-Tests. >> The >> way Sake calculates dependencies is totally strange, I am not sure if >> it is even correct. >> > Again, what do you mean? There are two algorithms in use. The first is > lifted directly from rake. The second is stolen directly from > universes. > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 19, 2009

Re: [Pharo-project] Question about Universes

by StÃ©phane Ducasse

and the spelling rules is definitively colo :) On Feb 19, 2009, at 8:22 PM, Ramon Leon wrote: > > I don't think it is fair to use code critics as an argument. > > I think it's perfectly fair, be it code critic or lint, if it finds > bad code then it finds bad code. It's not like you don't know about > code critics and Lint is already in Squeak, so it's your choice if > you choose not to avail yourself of tools that point out badly > written code. He writes about the tools he's working on at his blog http://www.lukas-renggli.ch/blog > which is easily subscribed to. There's no reason anyone can say > they're unaware of what he's doing unless they're choosing to be > unaware. > > Ramon Leon > http://onsmalltalk.com > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 19, 2009