Project ideas for GSoC 2010

This page is now depreciated, please look at Projects instead!

Core

Supporting the Coral a scripting syntax for smalltalk

Mentor: Luc Fabresse

Second mentor: Stéphane Ducasse

Level: 

Coral is a scripting syntax for Smalltalk. Now it lacks some support to make it easier to
script (file manipulation, ....).  The idea is to help using the FileSystem framework to build a better file manipulation and scripting library for coral. Improving OSProcess and other libraries to be able to launch process on Windows, linux.... would be good too.

Cross-Platform Namespaces

Mentor: James Foster

Second mentor: John O'Keefe

Level:

Produce the design of a cross-platform namespace with a reference implementation for Pharo/Squeak.
This will involve:

• Identify existing namespace approaches in other Smalltalk dialects (GemStone, VisualWorks, GNU Smalltalk, VA Smalltalk, etc.)
• Identify existing namespace proposals for Pharo/Squeak
• Design cross-platform namespace and implement for Pharo/Squeak
• Add tool support for selected implementation

Technical Details

Traditionally, all globals in Smalltalk are visible to all code in the image. While this works fine on a small scale, it becomes a problem when code originates from many different individuals or teams (which is particularly common in an open source community such as Squeak or Pharo). Each module that is developed will naturally have class names that reflect the domain being modeled. In any large system there is likely to be overlap among the names chosen (e.g., Person, User, Preferences, Server, Client, etc.). The typical approach is to preface class names with an abbreviation of the module name. While this works, it is cumbersome and tends to make names either cryptic or cumbersome. What is needed is a system in which internal class names (and other "globals") are visible only to the internals of a module that defines them. Each module should be able to reference its own names without exposing other modules to anything more than a public API.

An additional challenge is that multiple modules might add the same method to base classes–sometimes with conflicting implementations. This again presents a challenge to coordination among various contributors to a large system (particularly with an open source system where the contributors are not under some central direction). What is needed is an approach in which two or more modules can define the same methods, yet be protected from overlap.

Benefits to the Student

Exposure to compiler and tool building.

Benefits to the Community

A much richer environment that allows more sharing of code without the risk of overlap.

Improving the Compiler Frameworks

Mentor: Marcus Denker

Second mentor: Jorge Ressia

Level:

Technical Details

Squeak's compiler framework is hard to understand and not easy to extend. Over the last years, a number of projects used the compiler framework from Anthony Hanan's Closure Compiler (the NewCompiler) for research experiments.

Over the years, the compiler has seen some work (e.g. The compiler backend has been extended to support old-style non-closure code and extended to support FFI and 3.9 pragmas. In addition, work is nearly finished to generate code for new Eliot Closures).

Nevertheless, some more work is needed until the NewCompiler can replace the old squeak compiler. The goal of this project is to improve the compiler with regard to the code generation for new closures, improve performance and improve the compiler framework. One possible project to focus on could be to build an easy to understand decompiler.

Benefits to the Student

The student would learn about compilers, decompilers and in general the implementation of Programming Languages. The student would get insight into the inner workings of a dynamic language (ie. bytecode and implementation details). In addition, as the newcompiler was used for some research projects in the past, the student would learn about extending and in general using a compiler to modify and extend a smalltalk system.

Benefits to the Community

The current compiler is hard to understand and difficult to modify. In the past, many experiments (for example Reflectivity, Bytesurgeon, Helvetia, ObjectFlow, Changeboxes and Babel) used the newcompiler framework instead.
Having an easy to modify compiler as the main compiler replacing the current AST and Compiler would be of some benefit for the community: experiments get simpler and the adoption of some of the new technologies based on the newcompiler would be easier to use in real world projects.

OpenCL support for Kedama

Mentor: Josh Gargus

Second mentor: Yoshiki Ohshima

Level: Moderate to Difficult

Packaging Squeak as a DLL

Mentor: Eliot Miranda

Second mentor: Aik-Siong Koh

Level: Difficult

A conventional approach to making libraries written in a particular language available to other languages is to package a library as a dynamic load library or shared object (dll from here on in).  Adapting that approach to Squeak would both allow use of Smalltalk code by a wider audience and enable alternative deployment approaches for Squeak applications, easing the creation of Squeak plug-ins for systems like Apache, web browsers and so on.  There are broadly two different approaches one can take, which one could call passive or active.  In the passive architecture, the Squeak dll is inactive until called from another language, and runs only until a result is answered to the caller.  In the active architecture the act of loading the dll causes Squeak to start up on its own thread and accept incoming calls from other threads in a form of rendezvous.  The passive approach is easier to build but less useful; one does not have the full range of Squeak facilities such as light-weight processes, delays etc.

Technical Details

The objective of the project would be to implement either the passive or the active approach, depending on the student's interest and ability.  The goal is to make Squeak more broadly useful to users and application deployers alike.  There are many technical challenges to be met that will involve both Smalltalk and C coding and the use of the Smalltalk-C hybrid language Slang in which the Squeak VM is written.

Benefits to the Student

The benefits to the student include gaining an in-depth understanding of dlls, interfacing to dynamic languages, foreign function interfaces and of the Squeak VM.  The student will also be gaining an understanding of architectural issues by considering the many trade-offs between the passive and active approaches.

Benefits to the Community

The benefits to the Squeak community will be in being able to package and deploy Squeak applications much more broadly than before.

Progress Towards a Cross-Dialect Smalltalk FFI

Mentor: Eliot Miranda

Second mentor: John McIntosh

Level: Difficult

There is no one common foreign function interface amongst the various Smalltalk dialects and descendants.  There is a wide range of basic functionality, some systems providing only call-outs with limited or no callback facilities, some systems providing non-blocking call-outs that can run on separate threads, and accept call-backs from arbitrary threads.  At this lower level the absence of multi-threaded and callback facilities cause grave problems for interfacing SMalltalk to other languages.  At a higher level there is no up-to-date cross-dialect header parser written in Smalltalk which can be used to analyse external apis and auto-generate FFI bindings to those apis.  As the various C parsers have languished so auto-generating bindings to foreign languages has got ever more tedious and tricky.  But there has been significant innovation in Smalltalk VM architectures that allow simple and efficient multi-threaded FFIs, and a cross-platform C parser should have much broader support and hence be better maintained and functional.

Technical Details

The goals of this project would be, one, to build a reference implementation of a multi-threaded FFI, in either Squeak or Gnu Smalltalk, two, to build above that a cross-dialect set of facilities for defining C types, call-outs and call-backs, and three, to upgrade and port Gnu Smalltalk's CObject C parser, with the aim of providing a powerful multi-threaded cross-platform FFI for Smalltalk.  The actual work undertaken is open ended.  One can attack these problems at a high or low level and progress from there.

Benefits to the Student

The student(s) will gain an understanding of the full stack of a dynamic language FFI, including cutting-edge FFI architecture for dynamic language VMs, and the issues of deconstructing C header files from which Smalltalk interfaces there-to can be auto-generated.

Benefits to the Community

The Smalltalk community will gain important steps towards a modern cross-Smalltalk-dialect threaded FFI that makes it easy to interface Smalltalk with other languages and systems.

Refactored Hashed Collection Library

Mentor: Andrés Valloud

Level: Intermediate

Technical Details

Currently, most Smalltalk implementations provide a rich hashed collection hierarchy including Sets and Dictionaries of various kinds.
Unfortunately, historical constraints crystallized the class hierarchies into inflexible shapes.  For example, in VisualWorks, all hashed collections inherit from Set, even though Dictionaries are not
Sets.  Moreover, concepts such as hash vs. identityHash, equality vs. identity checking, weakness, ephemeronness, and storage strategy are not best served by subclassing. Consequently, one can observe reversals in such properties while diving through a hierarchy branch. The current class libraries are so pervasively used that modifying them in place would be quite disruptive to existing applications. Consequently, rather than refactoring the class library in place, it would be better to provide a loadable library that offers better hashed collections on demand without conflicting with the existing hashed collections.

Broadly speaking, hashed collections can be divided into Sets and Dictionaries.  Their properties (using hash or identityHash values, comparing objects via equality or identity, several types of weakness, their storage strategies) should be configurable in place. Subclassing should be used when the behavior of the hashed collection changes.  Therefore, the properties of hashed collections should be implemented in terms of composition and delegation of policy or other
collaborator objects.

The minimum goal for this project is to implement the equivalent of today's Set, IdentitySet, WeakSet, Dictionary, IdentityDictionary, WeakKeyDictionary, WeakValueDictionary, WeakIdentityKeyDictionary, WeakIdentityValueDictionary, some ephemeron based dictionaries, and at least two storage strategies: open addressing with linear probing, and hash buckets.

Benefits to the Student

The student will be exposed to a fascinating area of research rich in results and potential for often dramatic real life application performance improvements.  This knowledge will increase the student's ability to meaningfully contribute to software projects.

Benefits to the Community

Quite frequently, the community ends up implementing a one-off hashed collection that depends on a deficient class hierarchy.  This dependency only compounds the maintenance issues for the current hierarchy.  Having a loadable library with more sensible hashed collections would prevent the need to repeatedly implement hashed collections that occur often in practice (e.g.: a hash bucketed Set), as well as preventing a proliferation of redundant hashed collection classes of similar structure and functionality.  Moreover, the potential for hashed collection class unification offers the possibility to improve the performance of applications that depend on less than optimal hashed collections.

Tools

Web application to create custom Smalltalk images and Virtual Machines

Mentor: Dale Henrichs

Level:

Create something like http://builder.seaside.st/ but for building your own Smalltalk images, using Metacello and Loader. This should work at least for the Smalltalk dialects that supports Metacello and Monticello. In that website you should be able to search projects (Metacello configurations), add/remove them from your list, select a particular version, look the project description, authors, releases, etc. Once you have finished selecting all you want, you can download a script to run in your image or the server can even create the image for you and give you a link to just download the image.

In a further step (probably even optional and a bonus), it would be nice to create and compile your own VM using VMMaker. This would be like a web version of VMMakerTool, where you can select which plugins to compile and if you want them internal or external. Then, the server should be able to automatically generate the C code and build the VM for you. The main problem is how to build the VM for different OS when the server is running in only one in particular. Another problem would be that the VM code has some strange dependencies that should be fixed.

Finally, this bonus is important to spread the "build your own vm". This would help people to know how to create their own VMs, have less fear about it and not depend on VM gurus.

Fast binary format for objects and packages

Mentor: Stéphane Ducasse

Second mentor: Hilaire Fernandes

Level:

Monticello is widely recognized as a scalable and robust versioning and packaging system. However, a crucial feature is still missing. Source code is still the primary support to save and load applications. The idea of this project is to take the existing binary support, enhance it and incorporate it into Monticello.

This require the development of a package format to be able to load fast code without recompiling source code and supporting atomic loading of code as in professional Smalltalk environments.

Technical Details

VW parcel have a nice format that is optimized to load objects (any object graph) really fast. It would be good to understand the main idea.

Benefits to the Student

Great potential to have a huge impact in terms of users and feedback.
The student will learn a crucial part of smalltalk and will be able to gather precious knowledge about Monticello.

Benefits to the Community

Ideally, every user of Monticello (more than 1900 are listed on www.squeaksource.com) will find a benefit in this project.

Extensible but fast code and text editor

Mentor:

Level: Difficult

Smalltalk lacks an extensible editor component, that can not only be used to program in Smalltalk but also be extended to facilitate domain specific languages (DSLs). The goal of this project is to implement the model and view of a powerful editor component that is highly configurable and customizable. Possible features include, but are not limited to: configurable keyboard bindings, unlimited undo/redo, copy and past with multiple clipboards, multiple editing areas, bookmarks in text, folding of text, multiple selections, rectangular selections, syntax highlighting, completion mechanism, template mechanism, collaborative editing, etc.
This project may continue the work done in Safara.

Application package system for Pharo/Squeak

Mentor: Hilaire Fernandes

Level:

Technical Details

Develop an application package system to allow the distribution of Pharo/Squeak application in a package form.
The package could be an archive containing:

• source code of the application
• compiled byte code of the application
• resources files necessary to the application (translation, graphics, sound,...)

The application package will be installable at run time in a preinstalled Pharo/Squeak environment. The byte code will be used to allow a fast installation of the application code in the preinstalled Pharo/Squeak environment.
Additional mechanism will be provided to parse argument to the installed application. Non limited example:
pharo --load-application path-to/drgeo.app --arg "--load euclide.xml"

Benefits to the Student

• Exposure to virtual machine and byte code generation and manipulation (load/save in/from external file).
• Design and study of an application packaging system.

Benefits to the Community

Ease the distribution of Smalltalk applications, those making Pharo/Squeak suited to the development of third party applications without the need to distribute a whole Smalltalk environment.
Then the benefit is to make Pharo/Squeak a more appealing open source environment for the development of extremely portable applications.

Smalltalk-to-Javascript IDE

Mentor: Panu Logic

Level: Advanced

Smalltalk has a superior IDE for object-oriented, class-based programming. The fact that you can
easily see your classes and their relationships in the ST browser is what makes you "Think in OO
without trying".

There are many ways to do OO in Javascript, the dominant language of the web. The problem is
there is no good object-oriented IDEs for doing that, that would automatically ensure your
javascript is automatically class-based OO.

Because Smalltalk IDE can be programmed in Smalltalk, it should be easy to modify it and its compiler so that instead of just compiling Smalltalk classes into the Smalltalk VM, we would also be producing an equivalent, executable JavaScript program as a side-effect.

In the end you will have:

1. A superior IDE for OO-based javascript programming which would make all of your javascript "naturally" object-oriented (without having to think about it). The IDE would allow you to browse callers, implementors, subclasses etc.
2. A way to program Javascript in Smalltalk, and have your (Smalltalk!) program run on all web-browsers or server-based javascript environments.
   
3. In the case it proves too difficult to translate Smalltalk to Javascript (as described above), the IDE could still serve as a browsing tool (senders, implementors etc.) for javascript created in it, then stored into external files, which can then be run and debugged in a web-browser.
   Just the fact that the ST IDE would take care of creating the OO-framework around the individual javascript methods you assign in the ST IDE to classes and subclasses would  be a great productivity aid for any Javascript programmer .

Generate UML diagrams from Smalltalk code for Pharo

Mentor: Stéphane Ducasse

Level:

Key Features:

• Provide a simple interface to build Class Diagrams and Sequence Diagrams and export them as images.
• Right click on a package and generate it’s class diagram
• Right click on a class and generate it’s inheritance tree class diagram
• Generate sequence diagrams by executing a block -(i.e.:  [anObject doSomeMagic] drawSequenceDiagram)
• Generate class diagrams of the involved classes in the execution of a block.-(i.e.:  [anObject doSomeMagic] drawClassDiagram)
• Generate the Smalltalk code that would reproduce an auto-generated diagram, in order to have the possibility to adapt those diagrams with richer information that illustrates a specific scenario (i.e.: add/remove messages from a sequence diagram or methods from a class diagram, add or remove relations from a class diagram, etc). 
  
• Build a simple website where people can write code that generates an UML diagram and get the result images.
  

The idea would focus on static Class and Sequence diagrams, although in the future other features could be added, such as drawing an Object Diagram illustrating the relations of an object on a specific moment, adding comments or code into the diagrams, different strategies to generate diagrams (instead of just static graphics, maybe some interactive graphics or HTML), etc.

Technical Details

The student will have to integrate the functionality achieved by the framework with the coding tools already used on Pharo such as Class Browsers / Package Browsers for better usability. It would be useful to have specific tools for the project (i.e.: a window with two panes, one to preview the diagram and one for writing the code that generates it).
There are no restrictions about what technology has to be used to draw the diagrams. Part of the project consists in evaluating the different alternatives on that, and making a good choice. The generated diagrams will have to be exported as PNG / JPEG images or any format that can be easily shared and viewed.

The Smalltalk code generated with the diagrams could be useful to share diagrams “yet to be drawn” via Monticello or other forms of code sharing.

The website should be a very simple Seaside app. If the protocol to build a diagram is simple, the code that people would write in the website in order to describe the UML diagram and generate it, that code could just be Smalltalk without the need of a particular UML describing new language. Despite of this, designing a UML describing language to be used on the website can still be an option.

Benefits to the Student

• Get involved with some “inside aspects” of the Pharo environment
• Learn how to add features to the coding tools already working on Pharo
• Learn how to create graphics dynamically.

Benefits to the Community

• Have a comfortable and easy tool that helps communicating the object oriented design of a project by big or very specific parts of it.
• Get to share diagrams as code and not just images, that way they can be easily updated and manteined if any refactor or new requirements affect them, or it could even be useful to sketch possible changes in the code.
• Earn some popularity through the UML generation website, which could use as an introduction to Smalltalk to people who doesn't know about the language yet.

GLORP & Magritte integration/refactoring

Mentor: Yuriy Mironenko

Second mentor: Diógenes Moreira

Level: Intermediate

Glorp and Magritte both map between model-layer objects and other domains; in Glorp's case, the relational database, in Magritte's case, the web. The truth is that Magritte is a meta-description framework for all kind of descriptions. However, it is mostly used for web applications.

There are many similarities in how each framework manage model-layer class - accessing model's fields, mapping those fields to it's representation, caching/commiting/rollbacking, condition checking/validation and so on. Lot of business applications are RDS-based, CRUD-like systems, with GUI structure close to model structure, and model structure close to database structure. So, developers sometimes feel they are repeating themselves when they code first the Glorp descriptors and then the Magritte descriptors, or vice versa.

The goals of this project are:

•  Detect common aspects of both frameworks
• Compare implementation of those common aspects in both frameworks, and choose/compile "best" one
• Detect any limitations of one framework revealed by comparison with the other
• Refactor the stuff, splitting it to three groups: "common metamodeling", "Generic ORM" and "GLORP-related"
• Cleanup GLORP from "common metamodeling" and "Generic ORM" stuff.

The output is both a refactored codeset with three level of abstractness, and an analysis of why functionality was splitted in this exactly way.

Technical Details

Glorp and Magritte have good test suites. XP development to ensure existing facilities remain functional will protect the student from breaking some facilities as they experiment with refactorings. Maintaining, where possible, deprecated methods that call new API in terms of old API may be appropriate in the project, and may also assist introduction of the results to the community.

There are at least two projects to observe, one is for magritte-based SQL mapping without GLORP, another one - generator of simple GLORP mappings with Magritte descriptors.

Maybe it will be necessary to make some tools for describing domain-specific Magritte things. For example, something like "with this domain-specific descriptor you should use this domain-specific memento for caching".

Benefits to the Student

Glorp and Magritte are two meta-modelling/mapping frameworks with impressive capabilities solving real problems: the student who does this project will acquire significant practical knowledge of this kind of meta-modelling. Glorp and Magritte are also important parts of one way of writing web applications: the student who does this project will have skills that can be turned to practical account in web development.

Benefits to the Community

Decreasing complexity and entry level for projects with both Magritte and GLORP inside (a lot of enduser applications really).
Increasing quality of both Magritte and GLORP. Decreasing complexity of GLORP, which is very complex now becouse of all the stuff for meta-describing inside.
And avoiding double-efforts in future, so when  we'll upgrade Magritte, we'll upgrade GLORP simultaneously.

Build a Pango based Text Editor

Mentor: Travis Griggs

Level: Intermediate

Pango is at the top of the open source text/font stack. It's becoming the defacto on Linux/X11 and gaining traction elsewhere. It uses native engines (CoreFont on OSX and Uniscribe on Windows) where applicable. It has the ability to do multi-lingual matching and rendering, complex character shaping, and BIDI, amongst other things.

Benefits to the Student

Learn (at a high level at least), the ins and outs of modern font/text composition (one of the most taken-for-granted "arts" to computer programming currently). Gain experience in bridging between Smalltalk reifications of external libraries.

Benefits to the Community

If done right, since it does all of the rendering, a text editing ability that is beyond what any of the Smalltalks have, keeps them competitive with other offerings, and should be relatively applicable between different Smalltalk flavors.

Visualization of profiling information in Pharo and Squeak

Mentor: Alexandre Bergel

Level: Moderate to Difficult

Even though computing resources are abundant, execution optimization through
code pro-ling remains an important software development activity. A CPU time
pro-ler is a crucial tool to identify bottlenecks - program elements that take a
large part of the execution time. Today, it is inconceivable to ship a programming
environment without a code pro-ler included or provided by a third party.

Unfortunately, Smalltalk environments did not receive deserved attention on code profiling tools, and especially in Pharo and Squeak. MessageTally is currently the only profiling tool on these platforms. Whereas quite useful, profiling information would greatly benefit from a graphical (instead of textual) rendering. Inspiring example could be found on http://www.bootchart.org/images/bootchart.png

Technical details

The visualization part is offered by Mondrian. Technical challenges will be in getting the dynamic information and determining relevant and defining compelling visualizations. A first step was already done using the Spy framework.

Benefits to the Students

The student will have the potential to make a great impact on the Smalltalk community. Depending on the student taste, the project goal may range from getting expressive visualizations and getting an efficient implementation (e.g., with little runtime overhead). This project is also suitable for research activities. The current state of the art in this field is rather poor.

Benefits to the Community

MessageTally hasn't significantly evolved over the last years. This cannot last forever :-)

User Interface

Cairo support based on ROME

Mentor: Stéphane Ducasse

Second mentor: Alain Plantec 

Level:

Rome is a canvas drawing framework that has been developed for the Sophie project. It allows one to use the same interface to draw on multiple surfaces such as bitblt, cairo or svg. Cairo (http://cairographics.org/) is a 2D graphic library that is widely used in the free software community (Firefox uses it to render everything from UI to website content).

Native windows for Squeak and Pharo

Mentor:

Level:

Provide a multiple window support for Pharo, Squeak and all their forks. Something like Areithfa Ffenestri (http://wiki.squeak.org/squeak/3862)

FreeCAD/Cobalt: 3D CAD with Motion Simulation

Mentor: Aik-Siong Koh

Second mentor: Khai Fong Phua

Level:

To complete a CAD or Modeling tool inside Cobalt for the creation and simulation of objects in virtual worlds.

Technical Details

FreeCAD/Cobalt aims to be a native CAD or Modeling tool to create physical objects inside Cobalt virtual worlds. It was started in GsoC 2008 with good progress made.
http://www.youtube.com/user/kayef8#g/u
http://www.opencobalt.org
Simple shapes can be made and assembled into machines for simulation inside Cobalt.

The thing lacking now is the ability to create complex shapes with holes, extrusions and organic surfaces. This requires the ability to perform Boolean operations and manipulation of NURBS. The project will create the GUI to extrude and cut. Then it will also compute the resulting shapes after the operations. Upon completion, the project will make freeCAD/Cobalt a full fledged CAD system inside Cobalt written in its native language Smalltalk.

Benefits to the Student

The student will learn how to build a CAD system inside a virtual reality environment and use the power of Smalltalk.

Benefits to the Community

FreeCAD/Cobalt can be the default authoring tool used by all users of Cobalt for the creation of virtual worlds and its contents.

Squeakland education project

Mentor: Randy Caton

Second mentor: Markus Gälli

Level: Intermediate

Technical Details

Develop a set of tools in the Etoys/Squeak environment to implement the following:

• Graphing of Data: Tiles for creating vertical and horizontal grid lines, major and minor tick marks, labels for axes, and a label for the graph  would be created to allow students to graph data they acquire in science and mathematics projects.
• Input/Output of Data From/To Files: Tiles would be created to allow data from the Etoys environment to be output to a file and for information from an external file to be imported into the Etoys environment.
• Learner and Teacher Feedback: Tiles would be created to allow feedback to be provided to learners and teachers as a student progresses through a project.

Benefits to the Student

Exposure to Smalltalk programming and the problem solving involved in implementing the above tools in the Etoys environment would be valuable to the student's education. The description above is meant to be an outline, but the project would be somewhat open-ended so the students could use their problem solving skills to modify, improve and enhance the ideas for the tool set as they progress.

Benefits to the Community

Learners and Teachers would benefit from more tools in Etoys to enhance their learning.

• Graphing of Data: When learners are doing Etoys projects that involve acquiring data - either real or virtual - it would be valuable from an educational standpoint if they could stay within the same environment to plot the results of their investigation to better visualize their data. This would fit well with the visual aspect of Etoys.

• Input/Output of Data From/To Files: This would allow learners to import data for visualization in the Etoys environment. Etoys is richer than most learning environments used in education and very creative things could be done in Etoys to visualize and use external data from a file. Learners and Teachers would also benefit from getting formative feedback on how the learner is progressing. Etoys is a rich environment of objects and data regarding the learners manipulation of these objects would be sent to an external file for educators to analyze at a later date. The feedback would be more sophisticated and useful than a simple list of keystrokes or monitoring of eye movements. Further, data could be retrieved from these files to present to the learner or teacher as formative feedback on the learner's progress.
• Student and Teacher Feedback: Learners and Teachers would benefit from getting immediate, formative, embedded feedback. Teachers often have 20-30 students in their classroom and they don't have time to give each student very much individual attention. If teachers have immediate feedback on the screen regarding the progress of the student would help them decide which students need the most help. With feedback tools, educational developers who weren't Smalltalk programmers, would be able to create lessons with valuable feedback for learners and teachers.

Interoperability

Porting Monticello to Smalltalk/X

Mentor: Jan Vrany

Second mentor: Claus Gittinger

Level: Medium

Over the years, lot of nice stuff has been developed for Squeak/Pharo. All the code is maintained using Monticello, a source code management tool written for Squeak and Smalltalk. Porting the code to other dialects lacking monticello (such as Smalltalk/X) support is difficult and error-prone. Updating already ported code to a new version or merging changes back to the mainline is even worse.

Monticello port will ease porting of other successful projects. AidaWeb, Seaside, SqueakDBX, Glamour, Mondrian or DeltaStreams are just few of them. GemStone pioneered this approach and
its success show us that this is a reasonable way to go.

The goal of this project is to port and integrate Monticello to
the Smalltalk/X environment so the programmer will be able to
load a code from a monticello repository and commit it back right
from the Smalltalk/X IDE.

Technical Details

Porting Monticello to Smalltalk/X consist of three parts: (i) porting a Monticello's base classes, (ii) creating usable user interface integrated to existing Smalltalk/X tools and (iii) define a mapping scheme to map Smalltalk/X package names to Monticello ones and back. Port of base classes should be pretty straightforward - Monticello code-base is already covered by an extensive set of tests. The user interface part of monticello may reuse a code already written for libsvn (a SubVersion integration).

Benefits to the Student

Student will explore smalltalk language in depth. Working on source code management tool requires good knowledge of every aspect of given programming language. Smalltalk
is dynamic reflective language and Smalltalk source code management tools are usually good examples of usage of reflective features. Moreover, the student will become a part of big community, which is always a good experience.

Benefits to the Community

Due to historical reasons there are many Smalltalk dialects. Although they are all similar in spirit they differs in many details like an API, language features, user interface toolkits. Since there is a lot of high-quality code already stored in Monticello,, its support in Smalltalk/X will ease
further porting of other libraries and tools. Consequently this will enlarge particular tool sub-community. Moreover any back-contributions will further improve the tool or library,
making it even better and more usable. Monticello may serve as an integration platform ant thus,
having a Monticello ported is the first necessary step.

Newspeak/Smalltalk Import/Export Tool

Mentor: Gilad Brancha

Level:

Create tooling in the Newspeak IDE that facilitates conversion of code from Smalltalk to Newspeak (import) and from Newspeak to Smalltalk (export).

Technical Details

The tool will extend and integrate existing components in Newspeak, such as the Newspeak to Strongtalk compiler that essentially does source-to-source conversion to Smalltalk and spits out file out format for Strongtalk. It is easily adapted to other dialects. One can file in Squeak into the the system, and have tools that semi-automatically migrate  it in stages to Newspeak. These tools need to be made more robust, more sophisticated and better integrated. Adaptations to a number of different Smalltalk dialects beyond Squeak are desirable. Integration of tools such as Grease, Sport or Slime is a possibility.

Benefits to the Student

Students will gain experience with technologies such as parser combinators, advanced module systems, mirror based reflection and GUI programming in the context of a IDE as well as exposure to a variety of Smalltalk dialects and to Newspeak and its modularity structures.

Benefits to the Community

Increased sharing of software. Newspeak gains from the vast amount of available software in the Smalltalk community, and Smalltalk gains from some of the advances made in Newspeak.

Pharo/Squeak integration with git/mercurial

Mentor: George Herolyants

Level: Intermediate

Source code management is highly important aspect of every software project. Currently in Squeak/Pharo world developer has very limited choice of such tools. The only available full-featured SCM tool is Monticello. Other alternatives such as changesets lack in some areas.
Monticello in its own turn has some disadvantages: it can only handle Smalltalk code while typical software project has many other artefacts (represented primarily as files) such as documentation, scripts, diagrams and so on, which would be nice to have in the same repository. This project aims to get round this and some other disadvantages by creating a possibility for developers to use modern distributed source code management tools, which are popular outside of the Smalltalk community. The most recognized are git and mercurial.

There is already SqueakSVN project but it aims to SVN integration. SVN is classic client-server SCM. But nowadays this kind of SCM's become less popular, while popularity of distributed SCM's (such as git/mercurial) is still growing. It is also crucial for open source projects like Pharo/Squeak to have distributed SCM to ease development process. Monticello is highly distributed and the new SCM must be distributed as well to successfully compete with Monticello. So git/mercurial fits this goal very well.

Technical Details

This project may go different ways towards it's goal, depending on decisions being made during it.

Initial steps will be:

• Examining git/mercurial and choose one of them considering simplicity of API and it's ease of use, supported operating systems on and other important factors. There's also pure Smalltalk implementation of Git storage format on SqueakSource, so this step will require examining it as well.
• Defining and implementing a file mapping format for the Smalltalk code structure (classes, methods and so on), in order to support versioning at the level of separate methods (there is already one defined by SqueakSVN project so this step may require examining it). Or examining the ability to avoid such a mapping and store code directly without needing a working copy on disk.
• Studying how Squeak/Pharo handles system changes (changes or classes, methods). Then implement handlers for such changes to translate them to working copy using the mapping or through SCM API.
• (optional but desirable) Implementing Smalltalk interface to the chosen SCM. It can be based on the SCM's command line interface or on it's API. These will require using OSProcess or FFI (or writing a plugin) respectively.

Additional steps may include:

• Implementing import/export tool for Monticello repositories.
• Implementing simple user interface for the chosen SCM so that programmer can work with it from within the Smalltalk environment.
• Integration with widely used OmniBrowser would be even better.

In addition to this a local git/mercurial repository can be used instead of sources/changes files. This will require:

• Exploring the current mechanism used in Pharo/Squeak to maintain method version history.
• Replacing it with the developed system which will write changes to the local git/mercurial repository.

Benefits to the Student

The student will:

• learn about modern source code management systems;
• study their interfaces, both command line and API;
• study Pharo/Squeak internal mechanisms related to handling of classes and methods changes and storing of method versions.
• get experience in usage of FFI or writing plugins for Smalltalk VM;
• get experience with making GUI in Pharo/Squeak;
• enjoy writing programs in Smalltalk :)

Benefits to the Community

Developers will be able to choose SCM system grounding this choice on their own preferences. The community will gain access to some famous source code hosting services such as GitHub or Bitbucket. Among other benefits it will increase visibility of the community and the Smalltalk language in whole. It also will lower the entry barriers to newcomers and as a consequence will help community grow.

Getting rid of sources/changes files offers potentially unlimited method version history and avoids so called "condensing changes". And using local git/mercurial repository for this purpose will make managing changes more natural and uniform in small (every method accepting) and in large (changes at the project level).

Web

OpenSSL Smalltalk wrapper

Mentor:

Level:

It would be cool to wrap the OpenSSL library from Smalltalk

Google APIs Smalltalk wrapper

Mentor: Francois Stephany

Level: Beginner

Nowadays, more and more applications rely on external web services to provide functionalities that would be hard to implement from scratch. A major actor in this area is Google.

Many companies can benefit from those services: they bring a lot of value for a low cost.

Google provides many services that can be manipulated from any programming language (http://code.google.com/intl/en/more/). The main goal of this project is to bring them into the Smalltalk world.

The student will also study other web services providers (e.g., Bing for maps). The public smalltalk API should be (within a certain extent) provider agnostic: it should be possible to integrate different backends for a given functionality.

Benefits to the Student

• Good project to learn Smalltalk
• Discover the google web APIs
• Learn to shape a consistent API using Smalltalk idioms.

Benefits to the Community

• Easy Integration of google web services in smalltalk applications.
• Help companies that use Smalltalk for their product to compete with other company using different technologies on this facet of software development.

Brainstorming portal for better community decision process

Mentor: Janko Mivšek

Level: Intermediate

Create a web portal for brainstorming sessions/meetings to get ideas and answers to important questions in Smalltalk community. Portal should allow on-line to:

1. brainstorm the ideas
2. vote to get-out the best ideas
3. seek consensus
4. analyze - report

On-line session/meeting should look like a Skype session together with a brainstorming portal, from collecting ideas to a final decision proposal. Example of such session can be a Squeak Oversight Board meeting or planning session for a new Smalltalk project. Or some broader session in the community, like on a question how to organize better.

Some important concepts:

• anonymity of idea proposers
• associations: proposers see the ideas of anonymous others to facilitate an association for proposing an even better idea
• seeking consensus to avoid 51/49% decisions but to come closer to 100% agreement on important ideas.

Technical details

• a web application for gathering brainstormed ideas in real-time (using Ajax and Comet technology).
• voting system with appropriate algorithms
• analytics with on-line graphs and reports on paper/PDF
• installation on a publicly available hosting server
  

Benefits to the Student

• getting insight into group dynamics of Smalltalk community and in general
• gaining knowledge of modern web technologies in Smalltalk and in general
  

Benefits to the Community

Better community decision process by getting the best ideas from the members while on the other side avoiding stalemates so frequent in Smalltalk community those days

Tutorial application for Suixo

Mentor: Arthur van Schijndel

Second mentor: Diego Lont, Stephan Eggermont

Level: easy to difficult

Produce several tutorial applications for Suixo. These applications should demonstrate:

• How to start using the framework in your application.
• What benefits the framework will bring (see technical details)
• When to use a domain model driven user interface (i.e. naked objects) and when to use a workflow driven user interface
• How to apply domain driven design
• The advantage of using Smalltalk Seaside as development environment for enterprise applications

Technical details

Context

Suixo is an open source Smalltalk Seaside application framework used to build a.o. a vertical market solution for healthcare. The healthcare solution is currently used daily by about 80 users. Suixo is an application level framework that currently features:

• Workflow engine
• Generic reusable business model
  • Party model (company / person)
  • Time tracking
• Role based access control
• Content management system

Used technology
Suixo integrates the following technologies into an application level framework:

• Pharo (virtual machine)
• Seaside (web framework)
• Glorp (ORM)
• Postgres (persistence)
• Scriptaculous ui (Ajax componenten)
• ShoreComponents (widgets)
• Mold (meta model)
• Graphviz (workflow visualisation)
• Flotr (graphics)
• Soap (webservices)

Goal
Currently the framework has a steep learning curve, because it uses many technologies of the Smalltalk Seaside enviroment. The tutorial applications should make the framework more accessible.

Benefits to the Student

• Exposure to high level frameworks
• Designing large and complex applications
• Working in an agile environment

Benefits to the Community

• Make Pharo/Seaside a more appealing open source environment for the development of enterprise applications:
• Demonstrates Smalltalk Seaside viability for large and complex applications
• Better accessability of application level reusable functionality

Add functionality to Suixo

Mentor: Stephan Eggermont

Second mentor: Diego Lont, Arthur van Schijndel

Level: easy to difficult

Improve the Suixo full stack Seaside framework. Features should be usable as independent components as well as in the framework. Examples of features are:

• Adding an OODB based persistence layer
• Building a PDF rendering canvas for Seaside, using css for layout (larger scope)
• Building a reading / writing library for one of several document formats (i.e. Excel, ODF)
• Building a domain specific language for (object) reporting
• Adding persistence infrastructure for a document management system (distributed storage) (i.e. CloudDB, MongoDB)
• Implementing a Naked Objects style UI

Technical details

Context
Suixo is an open source Smalltalk Seaside application framework used to build a.o. a vertical market solution for healthcare. The healthcare solution is currently used daily by about 80 users. Suixo is an application level framework and currently features:

• Workflow engine
• Generic party model (company / person)
• Role based access control
• Time tracking
• Content management system

Used technology

• Pharo (virtual machine)
• Seaside (web framework)
• Glorp (ORM)
• Postgres (persistence)
• Scriptaculous ui (Ajax componenten)
• ShoreComponents (widgets)
• Mold (meta model)
• Graphviz (workflow visualisation)
• Flotr (graphics)
• Soap (webservices)

Goal
To increase the applicability of the Smalltalk stack.

Benefits to the Student

• Experience in extending existing frameworks
• Exposure to high level frameworks
• Designing large and complex applications
• Working in an agile environment

Benefits to the Community

Make Pharo/Seaside a more appealing open source environment for the development of enterprise applications:

• Better accessability of application level reusable functionality
• Richer Seaside environment

HTTP messaging library

Mentor: Janko Mivšek

Second mentor: Julian Fitzell

Level: Intermediate

Take the best parts of HTTP protocol classes from web servers, frameworks and clients, and create an HTTP package using Grease and Sport portability libarires.

Idea is to make an independent HTTP messaging library to be used for both web servers and clients, and also for internal use in web frameworks like Seaside, Aida and Iliad, to avoid unnecessary converting as it happens now.

Technical details

• review current HTTP messaging libraries in Swazoo, Commanche, Seaside, Iliad and in several HTTP clients,
• take the best from all of current implementations,
• reference implementation in Swazoo,
• cooperate with all interested communities (Swazoo, Aida, Iliad, Seaside and others).

Benefits to the Student

• gaining in-depth knowledge of the HTTP protocol,
• mastering the networking code in Smalltalk,
• giving valuable contribution to the community.

Benefits to the Community

• All Smalltalk web frameworks and libraries will get a common HTTP messaging library to avoid duplication of efforts.

Extensible parsing and persistency for Pier

Mentor: Tudor Girba

Second mentor: Lukas Renggli

Level: Intermediate

Pier is an open-source content management system that aims at allowing users to manage their content from the browser. It is based on a highly object-oriented model dealing with multiple issues: multiple types of structures that are meta-described, security management, user management, or persistency. The preferred way to define content is through an wiki-like syntax. Using this syntax, the user can specify multiple types of links, can choose to embed entire structures, and it can even access external services (like YouTube).

This project will tackle two important problems related to extending Pier:

1. While the Pier model is extensible the parser of the Pier syntax is not easily extensible. The first job will be to rewrite the Pier parser to offer hooks for syntax extensions. A possible path towards this implementation is the use of the PetitParser framework.
2. The main persistency mechanism in Pier is image-based. While the Pier model is meta-described for most parts, there are still parts that are accessed directly without the use of meta-descriptions. This poses a problem for a generic persistency mechanism. The second part of the project will focus on providing a mechanism for allowing each structure to specify a persistency strategy.

Benefits to the Student

• learn about meta-modeling and parsing.
• learn Seaside and work on a platform that has a wide acceptance already.

Benefits to the Community

• a better content management system
  

Swazoo web server/Grease improvements

Mentor:  Paolo Bonzini

Level:

The development of Swazoo, a web server written in Smalltalk, has been relatively slow recently.  This project proposes a series of tasks to improve Swazoo's position in the panorama of portable Smalltalk projects, and a series of infrastructure improvements that could be enabled by changes to Swazoo.

Some such task are refactorings of Swazoo with the following goals:

• improving the set of abstractions that Swazoo uses and provides; for example, GNU Smalltalk include a few changes to Swazoo that add support for SCGI and make it also faster in general.
• Swazoo is currently using a cross-dialect portability layer known as Sport.  Most of it could be replaced by Seaside's Grease layer, whose development was initially started and is now coordinated by Julian Fitzell.  Grease allows the user to write code more naturally than with Sport, by defining a series of extensions to the ANSI/Smalltalk-80 standard classes that are tested by Grease's test suite.
• the only part of Sport that is not included in Grease is support for sockets.  There are two approaches to solving this.  One is to add a small per-dialect layer to Swazoo, basically by inlining Sport's classes into Swazoo.  The second is to add socket support to Grease. The student could evaluate the relative advantages of these approaches and implement the one that is deemed better.
• regarding the latter possibility, Paolo Bonzini agreed to relicense GNU Smalltalk's Socket and File implementation under a different license for use within Grease or within other dialects.  This implementation is relatively large and it could be used as part of Grease.

To sum up, the goals of this project are:

• Incorporate the changes and speedups that went into the version of Swazoo distributed with GNU Smalltalk
• Incorporate and refactor Nicolas Petton's implementation of SCGI for Swazoo
• Replace the Sport dependency with Grease as much as possible
• Augment Grease with new functionality

Additional goals could include development of a common HTTP request framework to be used by Swazoo, Seaside, AidaWeb, Iliad and so on.

Technical Details

Swazoo and Grease have good test suites.  Test-driven development will ensure that existing facilities remain functional.  In addition, stand-alone benchmark programs such as the Apache benchmark (ab) will be used.

Benefits to the Student

Better understanding of the commonalities and differences between different Smalltalk dialects.  Learning the performance impact of using different abstractions provided by the Smalltalk virtual
machines, and the  necessary trade-offs to be employed by a high-performance component such as a web server.

Benefits to the Community

Modernizing the Swazoo portability infrastructure to match more closely other cross-platform projects that the Smalltalk community has developed.  Improving performance and functionality of the Swazoo web server.

Smalltalk application demo

Mentor:  Stan Shepherd

Level:  Intermediate

Smalltalk is enjoying a resurgence in its development, with a great deal of development going into building out its abilities to underpin a web framework.
Auctomatic was a recent startup built in Smalltalk, that received seed funding from Y-Combinator and was acquired by Live Current Media. People who build in Smalltalk know that it lends itself to fast development, and that web aplications can be upgraded on the fly, without the need to take down the server.

Technical Details

The goal of this project is to spread the use of Smalltalk to a wider audience. The scope is to produce a reference implementation of a Smalltalk stack, in the form of a working e-commerce site. The participants will select and integrate the preferred technologies, and build on existing
demonstration systems. The result will make it much easier for potential new Smalltalkers to evaluate the technology, by seeing a fully working example, and then to get started on their own application by downloading that same example as a working template.

Benefits to the Student

The student participant will gain experience of implementation of a real world Smalltalk project, and of the practicalities of e-commerce development. The student would be well positioned to participate in a startup using the technology stack.

Benefits to the Community

The Smalltalk community, and in particular the open source Smalltalk community, will benefit as follows: improved quality and documentation of the technology stack at its interfaces Availability of a one stop solution as the basis for new projects better ability to attract new participants and projects to Smalltalk.

Seaside tools

Mentor:  Julian Fitzell

Level: Intermediate

Develop a set of tools to support the development and/or deployment of Seaside applications. A number of focuses are possible here, including:

• Improving the configuration/administration interface distributed with Seaside to make it easier to use by new developers and system administrators. This might include developing a task-oriented interface and providing more contextual information to guide the user towards appropriate actions. A "welcome dashboard" for new Seaside installations could provide documentation, examples, and next steps to guide new users through their first encounter with the framework.
• Developing tools for system administrators to facilitate the management and deployment of Seaside/Smalltalk images, including monitoring the state and configuration of images, adding and removing instances, upgrade and rollback, etc. These tools should be implemented so they are portable between Smalltalk platforms (but the expectation is that only one platform would be implemented during this project).
• Experimenting with web-based tools to allow "wolfpack programming" where many developers work simultaneously on the same codebase in the same image. The environment should encourage collaboration through various techniques and investigate issues like: what division of roles is appropriate within the pack? what is the impact on code versioning? how closely in the codebase can developers effectively work? what is the impact on other agile techniques?

Benefits to the Student

The student will develop skills in analyzing a problem space, defining tool requirements, and implementing a solution. They will gain experience developing user interfaces and implementing applications using the Seaside web framework.

Benefits to the Community

The community will benefit from a richer development/deployment environment for Seaside and Smalltalk applications.

Operating System and hardware

PharoNOS

Mentor: Gerardo Richarte

Level:

''Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one.'' – Dan Ingalls, said that on 1981. That is the aim of SqueakNOS. The aim of the project is to make a Pharo image that is bootable without having a base Operating System as a backend, as we've done with Squeak. Once this stage get's completed, we plan to model a simple persistence scheme so we can save changes within running image, to work around this temporary shortcoming that actual SqueakNOS has. Then we could load the sources which isn't possible right now because of the lack of disk support. To summarize, to carry out all the things needed to have a PharoNOS that has all Pharo functionallity.

Technical Details

• Actually there is an SqueakNos image with some different shortcomings. The idea is to study the virtual machine (the interpreter) and get the knowledge needed to compile it with all its necessary configurations, (primitives, modules, etc) so that different images from different dialects could be loaded without an operating system supporting it.
• Adapt a Pharo Image so that it can run with the new compiled VM and without an operating system supporting it. This implies to make compatible all interruption mechanism.
• Implement a persistent scheme, probably only write and read from blocks of disc, or some FAT type filesystem. This would help to have persistence work, the changes to the image would be save on disk and also the .sources would be readable.
• Make Virtual appliances for the most known virtual players so it would be easy for everyone to use it.

Benefits to the Student

• Study persistent schemes having in mind the factibility of the environment.
• Model low-level stuff concepts on a dynamic and pure object environment.
• Study compilation of complex virtual machines.

Benefits to the Community

• The aim of the project is to have an operating system written almost purely in Smalltalk. That implies lot of things for the community. It would be easier to learn concepts, lo implement new concepts and to try them.
• The image would be an open source tool for everyone where they can interact with hardware from a dynamic and high level language.
• Smalltalk is a unique language in that it allows programmers to focus in actual problems without having to care on the way they communicate with the computer. This project can be of a lot of help in education and research environments, allowing to easily explore, try and test different hardware communication models with a myriad of different devices.

Memory Manager for SqueakNOS

Mentor: Hernán Wilkinson

Level:

The idea es to think about memory management schemes that fit into de SqueakNOS platform, idea and philosophy. Once studied the different ideas, the objective is to implement one. This would make for people from different areas to be able to understand, change, and adjust the memory management. The objective is to implement more than one, and a simple framework for benchmarking.

Technical Details

• Implement a memory manager from and for SqueakNOS.
• Study memory manager concepts and some implementations.
• Benchmarking for choosing the best for each situation.

Benefits to the Student

• Study memory manager concepts. 
• Model low-level stuff concepts on a dynamic and pure object environment.
• Compare different algorithms simple and export interesting data about them.

Benefits to the Community

• The aim of the project is to have an operating system written almost purely in Smalltalk. That implies lot of things for the community. It would be easier to learn concepts, lo implement new concepts and to try them.
• The image would be an open source tool for everyone where they can interact with the memory manager in a very simple way. Perhaps the algorith could be changed dinamically.
• The framework for banhmarking make it very simple for anyone who would want to improve the memory manager.

Concurrency Architectures in Smalltalk

Mentor: Andreas Tönne

Second mentor: TBD

Level: Medium to Advanced

Technical Details

Modern hardware architectures provide parallel computing power from the low end segment with multi-CPU boards and multi-core CPUs up to massively parallel systems, clusters and grids with thousands of processors. Traditional software development has been based mainly on assumptions of non-concurrent processing. The theoretical basics of parallel processing are researched and well understood since the 1960-ies. Theory and practice show there is no silver bullet, no solution that fits all circumstances.
 
On the other hand today’s software architectures such as Web Applications and Service Oriented Architectures as well as ever growing demands to the solutions of complex domain problems require software systems to leverage the power that is provided by the hardware. Software developers have to learn how to use the potential of parallel processing. System developers have to provide the necessary support by frameworks and tools. For quick adoption such frameworks and tools should not be grass-root new but be implemented in technologies already in use. A good part of software systems in production written in Smalltalk fall into the categories mentioned and would benefit from being able to resort to standard architectures, frameworks and tools.
 
This project shall examine the various approaches to concurrent processing and their implications on the applications in terms of performance, scalability, robustness and security. The solutions shall be based on multiple virtual machines and images communicating among each others. The Actor model and Data Centric Computing are examples of the architectures to be considered. The students will develop Smalltalk reference models on the basis of the assumption that the virtual machines are a given and not changeable. An important part of the project is to provide tools to examine and further develop the frameworks. From the point of view of the application developer the frameworks need to be intuitively to use and leave the application code easy to maintain. Any frameworks and tools developed shall be implemented under the Smalltalk principles of Simplicity, Power, Genericity and Ease of Use.

Benefits to the Student

The students will learn about the aspects of parallel computing which is vital for all future software architectures. They will learn how to implement reference models and frameworks for everyday use by application developers. Last but not least they will learn about the importance of tooling around any such basic technology to ensure reaching the goals.

Benefits to the Community

The whole Smalltalk community - the academic users, the open source community, the vendors and the commercial and non-commercial users - will benefit from being able to resort to standard architectures, frameworks and tools as a basis for their specific needs. Not only existing projects will be able to enhance their systems in operation but also new ideas will be more easily realized by being able to start from well examined sound ground.