- Pharo-dev - lists.pharo.org

[Pharo-project] Postdoc position: Reflection
by Marcus Denker Feb. 28, 2010

Feb. 28, 2010

(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.

1 0

[Pharo-project] Postdoc position: Trait-based Language
by Marcus Denker Feb. 28, 2010

Feb. 28, 2010

(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.

1 0

[Pharo-project] [update 1.1] #11237
by StÃ©phane Ducasse Feb. 27, 2010

Feb. 27, 2010

11237 ----- - Issue 2093: SUnitSpeedUp testSelectors - Issue 2092: Register file after setting name (from CUIS) and a couple of other little tweaks from squeak Stef

1 0

[Pharo-project] polymorph theme with new color for text
by Hilaire Fernandes Feb. 27, 2010

Feb. 27, 2010

Hello, In a custom Polymorph theme I want to use another color them for the menu font, button font,... Really I don't see from where it is themable. Any ideas? Hilaire

2 1

[Pharo-project] Quasi-stateful traits?
by Stan Shepherd Feb. 27, 2010

Feb. 27, 2010

To test out the possibilities of using traits for refactoring, I had a go at rationalising OmniBrowser/OmniBrowser2. This showed up that it appears to be possible to use the current traits implementation in a 'quasi-stateful' manner. that is, you can directly address the variables of a trait's 'hosting' class. This is rather contrary to my previous understanding of stateless traits. Is this normal behaviour? I've written up the details here. http://neat-sheet.com/development-blog.html/ ...Stan -- View this message in context: http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571120.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 15

[Pharo-project] [ANN] Printed version of "Dynamic Web Development with Seaside"
by Lukas Renggli Feb. 27, 2010

Feb. 27, 2010

A print-on-demand, softcover copy of the book "Dynamic Web Development with Seaside" is available from Lulu. The printed book is identical with the online and the PDF version of the book. http://book.seaside.st/book/introduction/print-book We wish to thank the European Smalltalk User Group (ESUG), inceptive.be, Cincom Smalltalk, GemStone Smalltalk and Instantiations for generously sponsoring this book. Please distribute this message widely. Cheers, Stef & Lukas

1 0

[Pharo-project] Issue 329: strange behaviour when Proceeding or Stepping in a newly opened Debugger
by StÃ©phane Ducasse Feb. 27, 2010

Feb. 27, 2010

http://code.google.com/p/pharo/issues/detail?id=329 what is the status? Can we make progress on this point? Stef Reported by jfitzell, Nov 11, 2008 Summary ~~~~~~~ When you Proceed in a Debugger, it assumes the interruptedProcess is sitting at the right context and so merely resumes the process. This assumption is valid once you have hit Restart or recompiled a method but not (currently) when the Debugger is first opened. When the Debugger first opens, the interruptedProcess is sitting in Process>>suspend and that is within the contexts of all the UnhandledError handling code, the code to open the debugger, etc. So if you hit Proceed right after opening the Debugger, the behaviour is different (see below). Current Behaviour ~~~~~~~~~~~~~~~~~ If you evaluate "Error signal" and then immediately Proceed, the behaviour is as follows: + Debugger class>>openOn:context:label:contents:fullView: is resumed and runs to completion, falling off the end + UnhandledError>>defaultAction eventually returns (and returns a Process because of the weird implementation of StandardToolSet>>debugError:) + The (non-resumable) UnhandledError is resumed with that value (a Process) + This causes the signal of UnhandledError in Error>>defaultAction to return the Process + Error>>defaultAction now returns but it ignores the Process that was returned by the UnhandledError and just returns self + The (possibly non-resumable) original error is now resumed with the value of #defaultAction (self) Expected Behaviour ~~~~~~~~~~~~~~~~~~ While the above basically works, the return value (the Error) is pretty sub-optimal and it is logically a bit confusing because the Debugger is supposed to be debugging the context where the error was signaled, not the code path that led to opening the Debugger. When you press Step, you expect it to make one step withing the current context, not to unwind a whole bunch of error handling code first. I expect step to simply make a step in the signaling context and I expect Proceed to carry on running in the signaling context. Since we are dealing with an Error that did not have a default value (since #defaultValue resulted in opening a Debugger), it seems reasonable to return nil as the result of the signal. Reproducing the Problem ~~~~~~~~~~~~~~~~~~~~~~~ This is of course hard to trace. You can verify the return value by simply inspecting "Error signal" and then hitting Proceed in the Debugger that pops up. You will see the result is an Error, not nil as I would expect. (For comparison, VW produces nil in this case, though you have to "Debug" and then "Run" because it won't let you Proceed a non-resumable error). To confirm the execution path, I ended up adding Transcript messages in UndefinedObject>>handleSignal: like this: handleSignal: exception value := exception defaultAction. Transcript show: exception name; show: ' -- defaultAction returned value: '; show: value printString; cr. ^ exception resumeUnchecked: value Suggested Fix ~~~~~~~~~~~~~ As far as I can tell, the best/easiest fix is to have the Debugger set the process into the debugged context on startup. I did this by making the attached change to Debugger>>process:controller:context:isolationHead:. It just adds a call of #popTo:value: on the process. (the debugger doesn't seem to be in a Monticello package?) This exception stuff gets complicated though, so discussion may be warranted if anybody else has a better suggestion. ***As an aside, I think the return values in UnhandledError>>defaultAction and StandardToolSet>>debugError: should be fixed to be more meaningful (or self). Returning a Process as the result of either message is silly. Debugger-processcontrollercontextisolationHead.st 704 bytes Download Delete commentComment 1 by jfitzell, Nov 11, 2008 Sorry... don't know why I couldn't see the Tools package. I found it and saved a version into Pharo-Inbox: Name: Tools-jf.90 Author: jf Time: 11 November 2008, 2:52:23 pm UUID: 5b6889f2-9071-314b-9c30-e6d83e014049 Ancestors: Tools-stephane.ducasse.89 Possible fix for issue 329: http://code.google.com/p/pharo/issues/detail?id=329 When opening a Debugger, pop the interruptedProcess back to the context that signaled the original Error. Delete commentComment 2 by jfitzell, Nov 11, 2008 Gah! Just discovered my fix seems to break things when a Warning is triggered... I need to look into it further. Delete commentComment 3 by jfitzell, Nov 11, 2008 Ok, the error I was getting was "the active process cannot pop contexts". The problem seems to be fixed by implementing ToolSet>>debugContext:label:contents: as follows: debugContext: aContext label: aString contents: contents ^ self debug: Processor activeProcess context: aContext label: aString contents: contents fullView: false This also has the side-benefit that "[Warning signal: 'foo'] fork" will now work (you get a white screen of death without that change). Anybody know why the Debugger class-side methods #openOn:context:label:contents:fullView: and #openContext:label:contents: are implemented differently to begin with? The method names don't suggest that their behaviour should be different. I feel like I've pulled on a thread that maybe I shouldn't have pulled on... :) Delete commentComment 4 by jfitzell, Nov 11, 2008 And I notice DebuggerUnwindBug>>testUnwindDebuggerWithStep is failing, but it seems to fail even with my changes reverted so I think that's not a problem here. Delete commentComment 5 by marcus.denker, Feb 18, 2009 As the change seems to be not stable yet, I have attached the mcz to the bug-report (this way we can clean the inbox) Tools-jf.90.mcz 384 KB Download

1 0

[Pharo-project] self halt
by Hilaire Fernandes Feb. 27, 2010

Feb. 27, 2010

On a updated pharo 1.1 image, a "self halt" block the image. The debugger is raised but the UI is frozen.

2 2

[Pharo-project] [update 1.1] #11235
by Marcus Denker Feb. 27, 2010

Feb. 27, 2010

11235 -------- - Issue 2057: Clean Codeloader more... - Issue 2029: Undeclared Variables - Issue 1922: use #forceNewFileNamed:do: pattern -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 1

[Pharo-project] [update 1.1] #11235
by Marcus Denker Feb. 27, 2010

Feb. 27, 2010

11235 --------- - Issue 1628: Error: There is no free space in this set!. - Enh Diff tool -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0