An INRIA Equipe Associee between RMOD and PLEIAD, a continuation of the PLOMO Equipe Associee named after cerro El Plomo, the highest peak (5424 meters) that is visible from Santiago. Foto by by Thiago "James".
Performing effective software development and maintenance are best achieved with effective tool support. Provided by a variety of tools, each one presenting a specific kind of information supporting the task at hand. The goal of the first PLOMO was to develop new meta tools to improve and bring synergy in the existing infrastructure of Pharo (for software development) and the Moose software analysis platform (for maintenance). With Plomo2, we want to build on top of this work and invent a new generation tools to navigate and profile programs.
The hypotheses that Plomo2 will seek to verify are:
The overall objectives of Plomo2 are:
All the efforts will be performed on Pharo and Moose, two platforms heavily used by the RMoD and Pleiad teams.
For both for program profiling and programmer activity recording, we need a way to deeply hook into the system. We plan for this to improve the reflective infrastructure of Pharo.
During the previous period we worked on OPAL, a new compiler toolchain for Pharo. In essence the work on the compiler framework does not move forward the state of the art in compiler technology. However it has already been proven to be a crucial building block. It provided the fundamentals for many research experiments and new features for Pharo. For example, Pleiad and RMoD collaborated on a novel type system for Pharo that was realized using the new compiler infrastructure. Other examples are the many new features of Pharo 3 that use parts of the new compiler chain, like AST-based navigation in the editor or breakpoints.
The Opal flexible compiler infrastructure will allow us to build a new generation of reflective infrastructure. Such infrastructure is keys to support tools (profilers) and new language design (AOP, proxies, isolation). We are now in a position to perform a new iteration on the reflective layer and metaobject protocol for Pharo. In 2005 we started to develop new reflective foundations and we learned a lot (partial reflection, metalevel recursion handling, object-centric on the fly propagation, proxies, isolation). We are now in a situation to step back and redesign the reflective layer based on all the cases we identified and developed.
The results of this work package will be used and thus validated by WP3. In addition, we plan to realize the next generation of the AOP framework Phantom using the reflection framework. This especially makes sure that the framework is general and not just limited for the use in tools.
Plomo made a lot of progress by realizing the Roassal visualisation framework. We plan to enhance the infrastructure to visually render software-related data. We will investigate two complementary directions:
The goal of the third work package is to build on top of both WP1 and WP2: Combining dynamic information with visualization to improve the development environment.
This work package will therefore validate both WP1 and WP2. We will validate the ideas developed as part of WP3 by carrying out an empirical evaluation.
Progress on a new iteration on the reflective layer and metaobject protocol for Pharo: We have implemented the Slots Mechanism in Pharo, which resulted in a first-class reification of instance variables and their accessing through assignment and reading. This allows us to hook into reading and writing of instance variables and perform meta-level operations on them, e.g., adding breakpoints to the reading of a specific instance var, or a transparent notification mechanism for when a specific instance variable is written. The latter can be used, e.g., in WP3 to dynamically update a visualization of the object that contains the instance variable whenever the variable changes. Reflective operations in the form of meta-links can be added to any expression tree. All variables can now be annotated with meta data. Reflectivity has been improved to allow Meta- Links to be put on First Class Variables. All work has been integrated in Pharo5 development and is used already by other projects of RMOD and a research project of the University of Lugano/Switzerland. The stay of Marcus Denker in Chile in November 2015 had the goal to make the new reflective infrastructure to be reliable enough for other PLOMO sub projects to use (namely LRP and Profilers). A breakpoint system based on Metalinks has been added to Pharo5 and is being improved for the release of Pharo6. The object layout functionality of Pharo allowed us to work on supporting C-Types. The Opal Compiler was extended with primitive types and to emit new low-level bytecode instructions. Combined, this allows performance for use-cases like 2D and 3D frameworks to be speed up by 50-400% [13].
Two complementaries axes were investigated. Roassal 2D is a visualization engine to render data. Roassal 2D is employed to visualize any arbitrary set of data, including software-related data [5, 9] (e.g., source code, module dependencies), numerical set of numbers [6] (e.g., metric values). Roassal 2D has been improved from the interaction and scalability point of view. Roassal 2D is regularly used to visualize software systems large of thousands of classes. The second axis is the visualization in 3D. For that purpose, we have improved the FFI support of Pharo to use external libraries. With that, we created binding to SDL2 which allowed to move the window management code from the Virtual Machine to Pharo (OSWindow). The 2D infrastructure work (OSWindow) has been taken up by another Project (Inria in collaboration with Thales). It has been extended with multi-touch support and a gesture engine. Besides pre-defined low level gestures (e.g., pinch or multi-finger swipe), the engine is extensible with user-defined gestures. The Woden 3D graphics engine is a first demo that uses this foundation to bring the ideas of Roassal to 3D. The new next generation graphics frameworks like Metal and Vulcan where the driving force to revisit Woden. The new framework Woden 2 uses the lowcode subsystem (see WP1) for a new generation, high perfomance 3D framework for Pharo. This will be the foundation of Roassal3D soon. Woden has already seen use outside of the PLOMO project, for example it is used for experiments with virtual reality at a large french multi-national company.
Live Robot Programming (LRP) [10] as a case for the first two points of WP3: Visualization to navigate and browse source code, Visualizing dynamic information to navigate source code. Firstly, in LRP the (Domain-Specific) source code is shown in a (Domain-Specific) visualization made in Roassal2 and Spec. Clicking on the entities in the visual representation causes a navigation action in the source code of the program. Secondly, in the LRP visualization the dynamic information of the state of variables in scope is shown, as well as which piece of the code is currently running, and this is partially enabled by Slots. The visit of Marcus Denker to Chile in spring 2015 helped to make serious progress on the base implementation infrastructure: The LRP prototype now is based in the First Class Variables (Slots and Globals) that are available in Pharo. We worked on refining the user interface framework Spec [4,16], together with its integra- tion with the visualization of dynamic information using Roassal as well as the GT Inspector framework for the analysis of live objects. The goal is to allow a developer to build his own custom user interface for the visualization of dynamic information, easily combining classical UI widgets with more advanced visualizations (provided by Roassal and/or the powerful object inspection and modification abilities of the GT Inspector). One example of a specific UI built this way is the work of Fabry and Sinclair [14] allowing the analysis of the dynamic evolution of simulated object trajectories in different physics engines e.g., the Siconos engine by INRIA Bipop. This work on Spec is enhanced by the writing of extensive documentation on the frame- work, which was shown to be necessary for developers to effectively be able to construct such user interface
Close proximity among the researchers also allowed work outside of the work packages to be started. One example is a preliminary effort in speeding up collections handling [12], another the work on identifying classes in legacy JavaScript code [15].
Santiago To Lille:
Lille to Santiago: