StudentProjects
From Mono
Google Summer of Code (GSoC) (http://code.google.com/soc/2008/) is a program that offers student developers stipends to write code for various open source projects. Google will be working with several open source, free software, and technology-related groups to identify and fund several projects over a three month period.
The following is a list of Mono project ideas that students can apply for. Additionally, we encourage students to submit their own interesting Mono-related project proposals. In 2007, roughly 20% of the accepted proposals were original ideas from students instead of from our suggestions. You can submit more than one proposal, so you can submit your own ideas as well as apply for one from this list. (Only one can be chosen of course!)
Please note that to apply for GSoC, you will need to go through the standard Google application process. You do not apply directly to the Mono Project. Any questions or comments about this page can be sent to Miguel (miguel@novell.com).
For inspiration, here are the projects from previous years:
- 2005 Projects (follow-up review (http://tirania.org/blog/archive/2006/Apr-13.html))
- 2006 Projects
- 2007 Projects
Important: Projects
If a project is not listed here, but you think you got yourself a great idea, feel free to contact our mentors, Miguel or to suggest your own project.
Over the past three years we have picked projects that were not listed here because they were great ideas, and we had students that were passionate about those projects. In the end, most of these projects were a success.
Do not be afraid to pick up a project that would be interesting and also help the Mono-universe.
Ground Rules
Language: Code must be written in the same language as the host of the project:
- GCC extensions in C
- Mono VM extensions in C
- Tools extensions in C#
- APIs in C#
- etc.
Licensing: All of the code submitted must be contributed under the terms of the MIT X11 license.
Acceptance criteria: The results must be maintainable and clean. If the code works as advertised but its a quick hack or something we would have to rewrite from scratch, we would not accept the project as completed.
We would rather have a maintainable, clean and incomplete piece of code that we could extend than a complete but unmaintainable piece of code.
Applying, suggestions
Remember that many people will apply to work on the Summer of Code and we cannot accept them all.
Keep in mind that those of us evaluating your application do not know you, we do not know what kind of experience you have, we do not know what you have done in the past, and we have to pick the best people suited for a particular task.
Hence, it is very important that you tell us in your application why you should be considered to implement a particular project. From the hundreds of requests that we got last year, in the first few hours we discarded all of the one-line requests that read something like:
I would like to work on project XYZ
Do not cut-and-paste the text from this page in your application. We know full well what the text here is. Instead explain to us your take on the problem "I could implement this using this and that", "I would need to research these areas", "I might need help sorting this out", etc.
We especially want to see:
- A concrete list of goals/deliverables for the time period.
- A rough estimate of the steps it will take to complete your project.
- A timeline showing how long you believe each step will take.
- Multiple people may apply for the same project, tell us why you are the best candidate.
During the summer of code, we will invest significant resources from existing team members to guide you, answer your questions, and help you architect the software in a way that is acceptable to Mono and that has a high chance of having an impact on the larger community of Mono users.
Contacting the Mono Team
If you have questions or suggestions that you want to make in real-time and talk to a member of the team, please join us on IRC on the server irc.gnome.org in channel #monosoc or the #mono channel. Various mentors and students from past years are usually there and can answer some quick questions about the program and about Mono.
Applications
We are looking for improvements to the existing Gnome/Mono applications like F-Spot, Banshee, Gnome-Do, Tasque, Tomboy and others.
Mentors: please add new ideas and applications.
Students: feel free to suggest ideas and projects for the summer from those alternative web sites.
Moonlight/Silverlight related projects
Many of these projects are intended to help us create software that we can use to test drive our implementation, find problems with Moonlight, our SDK and the development process.
The software will live on its own, but expect to find challenges with our implementation.
Silverlight GUI Designer
Last summer Alan McGovern (of MonoTorrent fame) worked on LunarEclipse, an GUI editor for Siverlight XAML files. This editor was being built as Moonlight was being developed, so it was a great test for Moonlight and exposed many bugs and limitations on it.
This year, Moonlight is more mature and we would like to have this GUI designer completed, first in standalone mode.
Deliverables:
- Complete the editing features available for figures.
- Complete the recording and animation framework.
- Add support for loading and saving files.
A Powerpoint (PPTX) to XAML converter
Complexity: Medium
Create a tool that enable users to compile existing Powerpoint presentations, in PPTX format, into Silverlight applications. The resulting applications could then be viewed on the web using either Moonlight or Silverlight.
- a (useful) subset of PPTX may be enough (i.e. not all effects are important as long as all the content is available);
- the results needs to be tested under both Moonlight/Silverlight;
- file bugs in Moonlight when it differs from Silverlight
Deliverable: A tool that takes a PPTX and creates a Moonlight based presentation.
An OOXML Word (docx) to XAML converter
Complexity: Medium
Create a tool that can convert .docx files into Silverlight applications/documents. This would not be an editor, but just a viewer that would be easy to embed in a page.
The resulting applications could then be viewed on the web using either Moonlight or Silverlight.
- a (useful) subset of DOCX may be enough (i.e. not all effects are important as long as all the content is available);
- the results needs to be tested under both Moonlight/Silverlight;
- file bugs in Moonlight when it differs from Silverlight
Deliverable: A tool that takes a DOCX and creates a Moonlight based presentation.
Silverlight/Web-based "Garage-Band"-like application
Using Silverlight 2.0 build the UI for a Garage-Band like application (sequencing of instruments, showing audio, beats, select ranges, cut and paste) that would be fully implemented with Silverlight and Moonlight.
Important: Do not worry about actual music output for this project, we are only interested in the UI. The actual media hookup would take place later (and would likely require server-side provided on-demand audio generation).
Silverlight/Web-based video editing sofwtare
Using Silverlight 2.0 build the UI for video editing software (import clips, select regions, cut regions, combine regions, mix regions, do transitions, effects).
Deliverables:, assuming that all audio and video sources are available on the server (ie, do not worry about the actual storage and web presence, that will be sorted out independently):
- Preview area for the video
- Timeline editor
- Cut, paste, slice, transitions.
- List of resources
- Show a timeline for the various clips
Moonlight Desktop editor for PureData
Complexity: Medium
Create managed bindings for PD patches and a Moonlight based editor for PureData content.
The editor should read PD files and use bindings to native patches, this have the advantage of leveraging all community developed patches. The interface could follow something similar to OSX Quartz Composer.
Deliverables: Managed bindings to PD libraries and patches and a Moonlight based editor for PD files.
Moonlight/Desktop Edition: F-Spot light-room
Implement a work-flow for F-Spot that allows browsing multiple related pictures, offer a light-room area using Moonlight as the rendering surface.
Silverlight/Moonlight Web-based: Suggest Your Own
Remember that all the Silverlight apps can be ran locally on the Linux desktop: what would be a great application that we could run unmodified on the web and on the client?
Graphical scripting tool
Develop a simple (highly limited scope) graphical flow-based scripting tool that uses a Moonlight-based canvas GUI. Mono objects could be exposed to the script environment by tagging methods (inputs) and events (outputs) with attributes. Users can then drop objects on the canvas and link outputs (events) to inputs (methods), with some kind of simple automatic typecasting where possible. These "programs" could easily be compiled to assemblies using SRE or CodeDOM and executed. Should also contain one assembly of useful objects for scripting simple file manipulations.
MonoDevelop
MonoDevelop (http://monodevelop.com) is Mono's integrated development environment, and aims to provide all of the RAD features that users expect in a modern IDE. Its architecture is highly flexible, so new features can easily be implemented in an "add-in". Students would be expected to write a new add-in or complete an existing, unmaintained addin.
Language Bindings
Language binding extensions integrate support for programming languages: compilation, code completion, etc. We are primarily interested in bindings for languages with an open-source implementation that can target Mono, but the architecture of MonoDevelop does not preclude other languages.
Implement a new Language Binding
Implement a language binding for a language currently unsupported by MonoDevelop. It should include complete code parsing and simple code completion, and possibly refactoring operations.
Possible languages include IronPython, IronRuby and LuaCLR.
DLR Console
Implement a DLR console that can host any of the DLR languages and provide an immediate window in which to type commands, both to run native applications as well as extending MonoDevelop.
Improve C/C++ Binding
Implement a mini parser and local type resolver in order to provide code completion for instance members and contextual code completion. Make the code completion more "eager". Refactor out the ctags layer so that it can be used to provide basic completion for other ctags-supported languages. Add features to facilitate managed bindings, such as DllImport completion and SWIG integration. Consider implementing some refactoring tools.
Improve VB.NET Binding
Finish the VB.NET bindings for MonoDevelop. Improve the code completion "eagerness". Implement the basic refactoring operations so that it can be used with Stetic and the ASP.NET codebehind. Implement automatic code insertion (insert 'End If' after 'If', etc).
Improve Boo Binding
The Boo (http://boo.codehaus.org) Binding is in a similar state to the VB.NET binding, so similar tasks would apply.
Java/IKVM Binding
Implement a complete parser for the IKVM Java binding to provide code completion. Further work is possible, as for VB.NET binding.
Class Designer Addin
Provide a class designer canvas based on Moonlight that allows users to visualise their class hierarchy via MD's built in code DOM, and stub out new code automagically. Should allow performing operations already made possible by MD's refactory tools such as adding and renaming members. Bonus points if it can load class designer files from VS2005+. N.B. #develop has some related code already.
Database Addin
Database Designer
Implement a database designer canvas using Moonlight that can be used to visualise and modify the table structures and relationships in a database. This could share code with the class designer.
Database integration
Integrate the database addin with other parts of MonoDevelop. This could possibly include the GTK# data widgets in Stetic, the databound controls in ASP.NET, or persistence layers such as DBLinq and NHibernate.
Moonlight/Silverlight Project Support
Complete the Moonlight project support in MonoDevelop, updating it to support the 2.0 CodeBehind and xap compilation.
It should also include a range of templates, solid XAML code completion, and an embedded Moonlight widget to show a live preview of the XAML.
Maybe also "widget tree" view of XAML, and use of property grid to edit XAML controls in the text editor, though here there may be overlap with the XML addin and ASP.NET addin.
Translation Resources Editor
An editor for Translation resources, particularly useful for ASP.NET where there is no (easy) Gettext availability. Could extend or share code with the Gettext addin.
Webkit-based HTML editor
An HTML editor based on GTK WebKit. The key feature of this editor should be to synchronise edited changes to and from the text editor in real time, allowing a designer/code split view. It should also include support for "regions" of uneditable code that can be rendered and updated by the ASP.NET addin. The will require close mentoring by mhutch to make sure it can be used to replace Composer for the ASP.NET editor.
Documentation Addin
Integrate the MonoDoc documentation system into MonoDevelop to make it easy to generate and update documentation for a project. The main feature would be a contextual pad that allows editing MonoDoc documentation. It should use the MonoDevelop parser services to determine the current position in the editor, and show the documentation for that class/method/property etc. Possible extensions to this addin would include displaying the documentation inline in the text editor, allowing "refactoring" of documentation from XML comments into the MonoDoc system, and autocompletion of references within the documentation editor.
Improve Code analysis and metrics addins
Integrate the Gendarme and Smokey addins and improve their usabiliy and feature set. The code metrics addin could also be improved, adding more complex metrics such as documention coverage, tests coverage, classes per file, methods per class, LOC per method etc.
Version control addins
The version control integration in MonoDevelop can be extended to support new version control systems via providers. Since the only completed provider is the Subversion provider, it is unknown whether the provider extension point is flexible enough to support all other version control systems; some patches to the core version control addin may be required.
Implement a new Version Control Provider
Fully implement a version control provider for any popular open-source VCS, such as Mercurial, GIT, or SVK.
Visualisation tools
In order to fully support distributed development, MonoDevelop needs tools to perform visual merging of changes (ideally three-way merge) and visualising branch and file history. Although most useful with distributed VCS, these will be useful with Subversion too.
Debugger addin
Get the Debugger addin in sync with the debugger interface so that inline debugging is supported inside monodevelop, with the ability to manage breakpoints, watchlists, tooltip variable inspection, callstacks and muktithread support.
Compilers
VB.Net 9
The current VB.Net compiler, vbnc, fully implements VB.Net 8. We would like to extend it to implement VB.Net 9. This may be too much for one summer, so your application should list which parts you plan on implementing.
Deliverable: Code and tests for vbnc which implement the proposed VB 9 features.
Class Libraries and Bindings
GIT# implementation
Importance: High
A fully managed implementation of the GIT framework, this would be a class library that would implement the GIT file format and operations in C#, including its test suite.
It should be possible to implement command-line equivalents to the GIT command line tools on Unix using the library.
There are various benefits in this project:
- It would allow tools like MonoDevelop to integrate GIT support natively.
- Bring GIT support to Windows easily
- Allow for the creation of new tools that use GIT storage as their backend.
Deliverable: A managed library that implements GIT functionality with unit tests.
Mono.Media API
The Mono.Media API would be a low-level implementation of a Media API for applications, we can draw inspiration and design from the Java Sound API (http://java.sun.com/products/java-media/sound/) and should provide support for audio operations such as audio playback and capture (recording), mixing, MIDI sequencing, and MIDI synthesis.
This is not a general purpose audio frameowkr like GStreamer, this would be significantly limited to the above list.
System.Data.SqlServerCe Implementation
An implementation of the System.Data.SqlServerCE API that is actually bound to Sqlite on Unix systems.
Deliverable: Code and unit tests for the SqlServerCE API implementation.
Windows.Forms Theming
Although our Windows.Forms (Winforms) implementation was designed with some rudimentary theming support, we currently only support one theme, based off the Windows Classic look. We would like to have themes that natively integrate with GTK, OSX, and WinXP+. This will most likely involve some refactoring of Winforms controls to separate drawing code into a drawing class.
This task would be to complete any necessary refactoring to create one theme (GTK, OSX, or WinXP+).
Deliverable: Code for refactoring and one native theme that runs our control test formstest (http://anonsvn.mono-project.com/viewcvs/trunk/winforms/formstest/).
Linq to SQL for open source databases
Linq to SQL has some layers. System.Data.Linq assembly contains a set of core Linq to SQL functionality and a set of interfaces to database providers.
Since it could be a big task, we could limit the scope of the project to only some parts of this feature.
There is an existing implementation called DBLinq that provides LINQ support for various open source databases; It would be useful to work with the DBLinq team to bring this library to work on Mono and Unix.
Deliverable: A Linq binding and unit tests to an open source database.
GTK#
GTK# Applications
We are extremely proud to have some exciting and innovative Mono/GTK# based applications, like F-Spot (http://f-spot.org/Main_Page), Tomboy (http://www.gnome.org/projects/tomboy/), and Banshee (http://banshee-project.org/Main_Page). We are interested in expanding this to include the next generation of Gnome apps. If you have an idea for a new, innovative application, please feel free to write a proposal for it. Note we are not interested in "I would like to rewrite application XYZ in Mono". We want fresh, new applications that provide value to the Linux desktop.
Deliverable: A GTK# application that contains the features specified in the proposal.
GTK# Custom Controls
One of the nice things about developing with Winforms is there is a vast ecosystem of third party controls you can drop into your application. It would be nice for us to "prime the pump" by creating some controls for GTK#.
Common Winforms controls to consider are things like: Charting, Graphing, Mapping, Reporting, GUI.
Some are available from Medsphere here (http://www.medsphere.org/projects/widgets).
Compatibility with the Stetic GTK# designer in MonoDevelop should be a priority.
Your proposal should include what type of control you would like to do, as well as what features it would have. For example, if you would like to make a charting control, you should list the types of charts you intend to support.
Deliverable: A GTK# control containing the features specified in the proposal, documentation for the control's API, and a sample application that demonstrates the control.
Summer of Profiling
The new 2.0 profile support in Mono is larger than 1.0 and also includes many new code paths that might affect regular applications running by using more memory that they should.
Since performance of managed applications is deeply tied to memory allocation, reducing memory allocation in Mono applications will lead to performance increase.
The Summer of Profiling would be a project to identify, tune, patch and improve the memory usage of Mono applications in every aspect: ASP.NET, web services, XML handling, core libraries, Gtk#.
Deliverable: Patches to reduce Mono's memory usage.
Tools
Gendarme related projects
Mono has a tool, Gendarme to inspect .NET software to detect potential problems within them. It is similar, in goal, to the FxCop tool available to Windows developers.
Gendarme is composed of a runner (a command-line tool) that execute a set of rules over binary assemblies. The rules are written in C#, or possibly any .NET language, by using Cecil, a managed API to manipulate an assembly IL and metadata.
Questions ? See us on IRC, #gendarme channel on GIMPNet, or drop us a mail on our Google Group (http://groups.google.com/group/gendarme).
Here are some potential projects related to Gendarme. We expect you to develop them further in your proposals.
Apply Gendarme to Mono
This project goal is to enhance Gendarme to be even more useful to Mono itself.
This project includes:
- Creating, or tweaking existing, rule sets (profiles) for
- stable assemblies, where API cannot be changed
- unstable assemblies, where the API can be changed
- non-core assemblies, those the Mono project doesn't directly support
- tools, all managed tools provided with mono
- Create a special runner to ease the execution and reporting over Mono different profiles.
- NET_1_1, NET_2_0, Silverlight ... assemblies and tools
- Wrap some rules for Mono usage.
- E.g. a lot of Gendarme's rules cannot be used because they would turn out valid issues that cannot be solved and retain compatibility with MS .NET framework (e.g. naming rules). However some rules would still be useful for private and internal classes/methods.
- Analyze Gendarme results to find:
- False positives. Create new unit tests for them and either fix the rules or fill bugs for them.
- Bugs on class libraries (and tools). File bugs for real problems (which can include patches) or add ignore entries for unsolvable issues (e.g. compatibility)
- Propose changes (framework and/or rules) to Gendarme to make it more useful to Mono
Apply Gendarme to FOSS projects
This project's goal is similar to the previous one but with a different target(s). Here the idea is to enhance Gendarme by helping other FOSS projects that run on top of Mono, e.g. MonoDevelop (http://www.monodevelop.org/), Tomboy (http://www.gnome.org/projects/tomboy/), Banshee (http://www.banshee-project.org), F-Spot (http://f-spot.org/Main_Page), Gnome-DO (http://do.davebsd.com/), NUnit (http://www.nunit.org/) ... The number of FOSS projects to be analyzed depend on their size and support. Since the latter may vary during the project (e.g. vacations) it could be possible to add more project(s) during the summer.
This project includes:
- Contacting the project maintainers to see
- their interest (and free time) in fixing the reported issues. Ideally this should be done before sending us the proposal!
- if binary compatibility is an issue, since this will influence the number of rules that can be used
- For each project you must
- Create scripts that contain:
- the set of rules used on the projects (actually it should be all of them - minus some specific ones)
- the list of assemblies to be evaluated
- File (or fix) bugs for
- Gendarme, e.g. in case of false positives
- the selected FOSS projects
- Produce a small report (in the form of a special blog entry) with statistics
- size of the project
- how many problems were found (e.g. per category, per rule)
- how many problems were false-positives
- how many problems could be / could not be fixed
- ...
- Create scripts that contain:
- Propose changes (framework and/or rules) to Gendarme to make it more useful to FOSS projects
Statistics & Performance Analysis
As Gendarme gains more rules performance will become an important concern. Gendarme's default rule set must be kept fast enough so that using it regularly, or as part of the build process, doesn't become an issue.
Part I: Statistics
This includes enhancements to the Gendarme.Framework to, optionally, keep statistics like:
- the number of times a rule was used, not applicable, successful, failed
- the required time for each case
The results should be added, on demand, to the default console runner to help developers see the impact of their changes.
Part II: Performance Profiling
This includes using the profilers available with Mono to find where we spend our time (and memory) while executing Gendarme (and potentially Mono.Cecil too). This should enable to create/refine the developer FAQ by documenting good practice for rules development.
Part III: Optimization
This last part includes changes (proposals and, if accepted, some implementation) to Gendarme (runners, framework and/or rules) to optimize the current time/memory requirements. It's also possible to propose (or write) some rules to check rules :)
Write some cool rules
For this project your proposal must include a list of a few, moderately complex(*), rules for Gendarme. Writing rules is a great way to learn C#, IL and the metadata internals by using the Cecil managed library.
To be considered complete each rule must:
- include its source code;
- include unit tests to ensure the rules works correctly, i.e. to confirm both positive and negative findings;
- include documentation for the wiki, e.g. [Gendarme.Rules.Design];
- be reviewed (to ensure it's been tested against the Mono class library and doesn't return too many false positives);
(*) there are a lot of small and simple rules still missing from Gendarme (requiring less than 5 days of work). However they are not candidates for GSoC projects since they offer a great introduction to new contributors, a way to relax (and try new stuff) for existing contributors (when short on time) and are very popular for GHOP tasks.
Additional sources of information:
- Existing rules (http://www.mono-project.com/Gendarme#Rules)
- The FindBugs (http://findbugs.sourceforge.net/bugDescriptions.html) software for Java
- .NET Framework Guidelines (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconNETFrameworkDesignGuidelines.asp)
Visual Studio Integration
Provide better support for Mono in Visual Studio.
- Most important features:
- Test in Mono on Windows
- Test in Mono on Linux (using either a VM or a linux box)
- Scan with MoMA
- Could integrate output with Visual Studio's error list
- An important note about Test in Mono is that we really need to build with [g]mcs so that we have debug symbols for stack traces.
- Some other possible features:
- Support debugging of the mono runtime in VS.
- Take over VS like grasshopper does so that pressing F5 (build) automagically uses mono instead of .net.
Deliverable: A Visual Studio add-in that implements at least the first three features listed above, as well as any server/daemon code that needs to run on Linux to implement Test in Mono on Linux.
ILASM
Convert the ILASM backend to to use Cecil (http://www.mono-project.com/Cecil) as its backend instead of PEAPI (this is only a backend change, not a rewrite of ILASM).
Deliverable: A version of ILASM that uses Cecil.
Monodoc
- Convert monodocer to use Cecil (http://www.mono-project.com/Cecil) instead of System.Reflection.
- Write PDF export support for documentation.
- C# 3.0 support in monodocer and monodoc (e.g. show extension methods)
Hosting Mono
The Mono runtime could be hosted into several open-source applications (e.g. extensibility, scriptability). Each one would be a different challenge with varying complexity levels. Got other hosting ideas/projects ? Let us know!
Inkscape
Create bindings to Inkscape so that Mono can be used to script Inkscape with any of the .NET provided programming languages.
Deliverables: Bindings that expose the Inkscape API to C# code as well as code to host the Mono runtime inside Inkscape.
Database Server
Develop a database server plugin to execute C# (or any .NET language) stored procedures. Mono can either be hosted inside the database engine or out-of-process.
Notes
- An open-source database server would be more useful than a proprietary one ;-)
- Like hosting Mono inside FireFox the security implications of managed storedproc limits the usefulness of this tool until our security manager is completed. However it is still useful for fully trusted code and will provide an excellent test environment for a secure Mono runtime.
Deliverable: A plugin that can execute basic C# statements as a stored procedure with examples.
ClickOnce
A ClickOnce (http://msdn.microsoft.com/msdnmag/issues/04/05/ClickOnce/) implementation could be done using either a managed or unmanaged host (e.g. Firefox). Besides a host this would require adding the missing pieces in the Mono class library (e.g. manifest support).
Since CAS is not supported in Mono its usefulness would be somewhat limited. However a basic use case, from an enterprise point of view, is to distribute/update applications on an intranet. In this case having only NoTrust (no execution) and FullTrust (execution) is a valid and interesting scenario.
Ideally the NoTrust/FullTrust decision would be based on host security policies (e.g. strongnames, url, ...) or by custom host logic.
Deliverable: A host environment and necessary Mono pieces to enable clicking on a link in a browser which will download, install, and run Mono applications.
Runtime
Mono Runtime Ports
Port the Mono JIT engine to any of the following CPUs:
- PA-RISC
- PowerPC 64 bit port (we have a 32 bit port).
- MIPS 64 bit port
Each port can be implemented in two to three months.
Deliverable: A port that passes all of the tests in mono/tests, as well as mono/runtime and be able to bootstrap itself.
Add COM support for other COM runtimes
Complexity: Medium. Priority: Medium.
Currently Mono has support for Mainsoft's COM and Mozilla XPCOM, we would like to add support for OpenOffice's UNO to bridge their APIs using the native COM support in Mono.
See Three Com Interop Updates (http://jonathanchambers.blogspot.com/2007/02/three-com-interop-updates.html), COM Interop in SVN (http://jonathanchambers.blogspot.com/2006/07/com-interop-in-svn.html), COM Interop in Mono Progress (http://jonathanchambers.blogspot.com/2005/11/com-interop-in-mono-progress.html) and COM Interop in Mono (http://jonathanchambers.blogspot.com/2005/11/com-interop-in-mono-part-1.html) blog posts for more details.
Deliverable: Code that enables support for OpenOffice's UNO with an example program that connects to OO and performs some small task.
LLVM Back-End
Complexity: Hard.
Investigate using LLVM (http://llvm.cs.uiuc.edu/) as an optional back-end optimizer for the Mono JIT, useful in Ahead-Of-Time compilation or server environments, where the quality of generated code is more important than compilation time. Some of the integration issues are discussed here (http://lambda-the-ultimate.org/node/141).
Rewrite Remoting to use DynamicMethod
Complexity: Medium-Hard.
The current implementation of Remoting use System.Reflection.Emit to generate classes do optimize some remoting tasks. However the types are not GC'able due to the nature of how TypeBuilder and friends work. The idea is to re-implement this part of the code to use DynamicMethod, which would result in less memory utilization and allow for GC'able data.
Deliverable: Patches re-implementing the related parts of Remoting.
Optimize AOT Relocations
Complexity: Medium. Priority: Medium.
The current AOT compiler generates a large amount of indirection in the AOT generated code as compared to what comes from the JIT. This hurts the runtime performance when AOT is used. We need to reduce the number of relocations to make AOT more beneficial.
Some ideas are available Optimizing AOT page
Deliverable: Patches to reduce indirection / increase performance of Mono's AOT.
Axiom Engine
The Axiom 3D Engine (http://axiomengine.sourceforge.net) is an open-source, cross-platform 3D graphics rendering engine for .NET and Mono. The engine is a high-performance C# port of the powerful OGRE engine.
Some ideas can be found on the Axiom wiki (http://axiomengine.sourceforge.net/wiki/index.php/HelpRequested). We're interested in things that will make it easier to write cross-platform games and 3D applications using Mono.
F-Spot
f-spot (http://f-spot.org) is an open-source photo-management application for the GNOME desktop built on top of Mono. A few ideas can be found here [1] (http://f-spot.org/Soc2008) but your own are welcome too. The following item is the most mono oriented of the set:
Extend daap-sharp to d[amp]ap-sharp, integrate it with f-spot for photo sharing
Complexity: Medium Priority: Medium
DPAP is the protocol used by iPhoto for sharing images, similar to DAAP for sharing audio between iTunes and other music app (banshee, rhythmbox, ...). Right now banshee consume the daap-sharp bindings, and this bindings should be extended to support dpap too (both daap and dpap are based on dmap). F-Spot should use this new library to 1)browse remote dpap shares from the --view mode and 2)expose it's collection via dpap.
Deliverables: a working managed dpap library and a set of patches to showcase it's usage in f-spot (exposing f-spot db, browsing shared items)
Powered by MediaWiki