Hello, Here are my proposals,
================================================== Title: Slots, batteries included Context: Pharo has recently introduced a model for first-class class layouts and instance variables (slots). This model will permit to customize the memory layout of instances of a class and the read/write logic of instance variables. However, the current compiler doesn't take the custom read/write logic into account and the implementation need some love. Goal: The student will first have to understand the model of layout and slots (http://rmod.lille.inria.fr/archives/papers/Verw11a-OOSPLA11-FlexibleObjectLayouts.pdf). The next step is to modify the compiler (Opal) so that it take slots into account. Then, the student will improve the current implementation: - Expand the API: Each class should responds to #slots #ownSlots, each object to #slotNamed:set:, #slotNamed:, etc... - Fix the class installer to use the new instance migration model instead of the old one. - Study whether scopes can be removed from the core model or not. - Better definition of the interactions/responsibilities of the class builder and the class installer and fix the problem of modification of anonymous classes. Then the student can provides several examples of custom slots and identify potential clients of these new facilities. Dialect: Pharo Skill level: intermediate Mentors: Camille Teruel / Martin Dias ================================================== Title: Baobab Context: Pharo sources are currently stored in a separated file (.sources). We plan to remove that file and instead store all sources in the image in AST form. But keeping all the ASTs of the system methods would cost too much memory. Bonsai, is one possible solution for saving memory: it is just a flyweight pattern for ASTs. Additionally, we want to annotate the nodes of the ASTs various informations (bindings, additional comments, discussions, false positive critics, debugging code, typing information for various pluggable type systems, statistics like code coverage, etc...). All these annotations would also take too much space in the image. Moreover, not all of them are needed by all developers. Some must be kept in the image, others not. Goal: The goal of Baobab is to offer a flexible AST annotation and serialization system. An annotation should be able to define if it's transient (kept in the image but not serialized with the AST), local (kept in the image and serialized with the AST) or remote (stored on remote repositories so that teams of developers can share and edit them). Dialect: Pharo Skill level: easy/intermediate Mentor: Camille Teruel =================================================== Title: Generic rewriting engine Context: Rewriting is an useful technique that has a lot of applications in many functional programming language. A rewriting engine that can rewrite arbitrary graph of objects would have a lot of useful applications like code refactoring and migration of instances in an alive program. Goal: The goal of this proposal is to implement a rewriting engine for arbitrary tree/graph of object. A rewriting rule must be able to define: - Patterns to match a part of the graph possibly including metavariables (variables that match subparts of the matched part) - Transformation of the matched part using the metavariables The engine is parametrized with a set of rules an a traversal of the graph (look at http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects for ideas). Inspirations can be found in the pattern-matching library of Newspeak: (http://www.hpi.uni-potsdam.de/hirschfeld/publications/media/GellerHirschfeldBracha_2010_PatternMatchingForAnObjectOrientedAndDynamicallyTypedProgrammingLanguage_HPI36.pdf). Skill level: intermediate Dialect: Free Mentor: Camille Teruel =================================================== Title: Object based IDE Context: An object oriented program is based on objects that send messages to other objects. However, source code and IDE shows only classes and methods. There is a huge gap between the source code that the IDEs show and the runtime entities of a program: object and messages. This gap make program comprehension difficult because it is up to the programmer to fill this gap in is head. That is certainly the reason why many Smalltalk programmers like to program in the debugger: they deal with an actual instance of their program. Goal: The goal of this proposal is to set up the first bricks toward a graphical IDE centered around objects that are alive during a program execution. The first step is to provide a view to easily navigate through a graph of objects. Then objects should be able to customize their view and several default views for common classes must be provided: Array, Dictionary, Set, etc... The final step is to be able to run a program step by step as in a debugger and display the messages sent between objects using Granovetter diagrams. Dialect: any Skill level: intermediate Mentor: Camille Teruel
