-<h2>Mono hacking TODO list</h2>
-
-From time to time people that want to contribute to Mono ask on the mailing list
-what they can help with. The generic answer is always:<br>
-<ul>
- <li>Write documentation.
- <li>Write regression tests.
- <li>Complete the implementations of the class libraries.
- <li>Help fix the bugs filed in our bugzilla database.
-</ul>
-
-The proposed tasks are very important for the Mono project and are suitable for people
-that can dedicate even just an hour per week to contribute.
-But some people may need something more
-focused to work on, such as students that want to do a thesis
-on their contribution to Mono. For such people (and also for professors who want
-ideas for thesis regarding JIT or VM technologies), here is a list of tasks that
-need attention.<p>
-The estimated time to complete any of the tasks is between 1 week to several months
-to accomodate for different hacking possibilities.<br>
-
-Note on the time estimates: they are very rough estimates, a smart and dedicated hacker
-can complete the tasks in half of the minimum time, a part-time hacker that also has a
-social life can take more than double the max time, but there's nothing to worry as long as
-progress is being done:-).<p>
-If some people (or group of people) want to take on a task, they should write to
-the mono-devel mailing list and in the relative bugzilla bug report. Discussions
-about how to implement a feature or additional information on the task should be mailed to
-the list or in the bugzilla report as well so that people can keep informed on the
-progress or have the information needed to start contributing.<p>
-
-Mono is an excellent platform for research on JITs, virtual machines and specifically
-the CLR because it provides an advanced free software implementation that can be used as
-a basis for more optimizations, new approaches to problems and new features.<p>
-There are different areas of interest where high-level contributions can be made:
-<ul>
- <li><b>JIT compiler</b>: tasks can be: adding more optimizations, reducing
+* Mono hacking TODO list
+
+ From time to time people that want to contribute to Mono ask
+ on the mailing list what they can help with. The generic
+ answer is always:
+ <ul>
+ <li> Write documentation.
+ <li> Write regression tests.
+ <li> Complete the implementations of the class libraries.
+ <li> Help fix the bugs filed in our bugzilla database.
+ </ul>
+
+ The proposed tasks are very important for the Mono project and
+ are suitable for people that can dedicate even just an hour
+ per week to contribute. But some people may need something
+ more focused to work on, such as students that want to do a
+ thesis on their contribution to Mono. For such people (and
+ also for professors who want ideas for thesis regarding JIT or
+ VM technologies), here is a list of tasks that need attention.
+
+ The estimated time to complete any of the tasks is between 1
+ week to several months to accomodate for different hacking
+ possibilities.
+
+ Note on the time estimates: they are very rough estimates, a
+ smart and dedicated hacker can complete the tasks in half of
+ the minimum time, a part-time hacker that also has a social
+ life can take more than double the max time, but there's
+ nothing to worry as long as progress is being done.
+
+ If some people (or group of people) want to take on a task,
+ they should write to the mono-devel mailing list and in the
+ relative bugzilla bug report. Discussions about how to
+ implement a feature or additional information on the task
+ should be mailed to the list or in the bugzilla report as well
+ so that people can keep informed on the progress or have the
+ information needed to start contributing.
+
+ Mono is an excellent platform for research on JITs, virtual
+ machines and specifically the CLR because it provides an
+ advanced free software implementation that can be used as a
+ basis for more optimizations, new approaches to problems and
+ new features.
+
+ There are different areas of interest where high-level
+ contributions can be made:
+
+ <ul>
+ * <b>JIT compiler</b>: tasks can be: adding more optimizations, reducing
compile time, porting to different architectures.
- <li><b>AOT compiler</b>: optimizing the compiler output and the AOT loader,
+
+ * <b>AOT compiler</b>: optimizing the compiler output and the AOT loader,
better support for multiple application domains.
- <li><b>VM runtime</b>: optimizing the runtime data structures, experimenting with
+
+ * <b>VM runtime</b>: optimizing the runtime data structures, experimenting with
different garbage collectors, integration with different component models.
- <li><b>Class library</b>: many opportunities in the implementation of regular
+
+ * <b>Class library</b>: many opportunities in the implementation of regular
expressions, Xml related technologies (XPath, XLST, etc).
- <li><b>Compilers</b>: writing compilers, interpreters and runtimes for langauges
+
+ * <b>Compilers</b>: writing compilers, interpreters and runtimes for langauges
so that they run on the CLR (using Reflection.Emit support, for example).
-</ul>
+ </ul>
-Happy hacking!<p>
+Happy hacking!
<table border=1 cellspacing="0" cellpadding="0">
<tr>
<th>Area<th>Description<th>Difficulty<th>Time estimate<th>Bugzilla ID
</tr>
- <tr>
- <td>Runtime (mono/metadata)
- <td>Optimize method vtable. Currently all the methods in a class
- are added to the method vtable, including static and non-virtual methods.
- This makes vtables bigger and the instructions to access them are longer,
- increasing also code size. Some code in metadata/icall.c and maybe also some
- remoting code may depend on the current layout: such code should be fixed as well.
- <td>Medium
- <td>1-2 weeks
- <td>not assigned
- </tr>
-
<tr>
<td>System assembly (mcs/class/System/)
<td>Implement the IL-based regular expression engine. Instead of
by the MS runtime.
<td>Medium-hard (thesis subject)
<td>2-4 months
- <td>not assigned
+ <td><a href="http://bugzilla.ximian.com/show_bug.cgi?id=52605">52605</a>
</tr>
<tr>
<td>not assigned
</tr>
- <tr>
- <td>JIT (mono/mini/)
- <td>Implement generics support.
- We need to add support for the additional instructions and change existing ones to
- support the generics requirements.
- <td>Medium-hard
- <td>2-3 months
- <td>not assigned
- </tr>
-
<tr>
<td>JIT (mono/mini/)
<td>Port the JIT to additional architectures.
- Currently ports are in the works for ppc, arm, sparc, s390. None of the ports
- are as feature-complete as the x86 one, yet, so help is needed in getting them
- up to speed. Ports to more architectures are welcome as well.
+ Currently ports exist for x86, ppc, sparc and s390.
+
+ Ports to more architectures are welcome as well.
<td>Medium-hard
<td>3-6 months per arch
<td>not assigned
stack walking to collect security info.
<td>Medium-hard (thesis subject)
<td>4-5 months
- <td>not assigned
+ <td><a href="http://bugzilla.ximian.com/show_bug.cgi?id=52606">52606</a>
</tr>
<tr>
<td>not assigned
</tr>
+ <tr>
+ <td>Linker tool.
+
+ <td>Write a tool that given a list of methods and
+ classes extracts them from an existing assembly and
+ produces a new assembly with these classes and any
+ dependencies they might have.
+
+ <br>The idea is to have a way of creating custom
+ libraries that can either be embedded with Mono's
+ bundle setup or to create smaller editions of the
+ libraries for embedded systems.
+
+ <td>Medium
+ <td>4-6 months
+ <td>
+ </tr>
+
+ <tr>
+ <td>Tools
+ <td>Write an implementation of the MSBuild compilation tool available in .NET 1.2
+ <td>Medium
+ <td>4-6 months
+ <td>not assigned
+ </tr>
+ <tr>
+ <td>Build tools.
+ <td>Currently it is easy for people doing daily
+ updates from CVS to break their installation. Design a mechanism by
+ which Mono never fails to compile.
+ <td>Easy
+ <td>1-2 weeks
+ <td>not assigned
+ </tr>
+ <tr>
+ <td>Documentation.
+ <td>Editorial review of the Monkeyguide: The monkeyguide is known to contain outdated
+ statements, it needs to be reviewed and it needs an
+ editor to take control over it. Some simple tasks
+ include flattening out the Monkeyguide, since it is
+ too nested today.
+ <td>Easy
+ <td>Ongoing work.
+ <td>not assigned
+ </tr>
+ <tr>
+ <td>Documentation
+ <td>GNOME.NET Chapter should probably be separated
+ from the Monkeyguide. This is probably the most
+ complete chapter, but it is burried in various nested
+ levels of stuff, and because of this, it is not being
+ updated. Write a chapter on custom control
+ authoring and common patterns of app development.
+ <td>Easy
+ <td>Ongoing work.
+ <td>not assigned
+ </tr>
+ <tr>
+ <td>Documentation Tools
+ <td>The Monodoc collaborative service needs a better
+ administration tool than it has today; Someone needs
+ to redo the UI and streamline its process.
+ <td>Easy
+ <td>2-3 months.
+ <td>not assigned
+ </tr>
+ <tr>
+ <td>Comment Service API
+ <td>Design a full system for comments and ratings so
+ people can annotate the documentation in Monodoc.
+ <td>Easy
+ <td>2-3 months.
+ <td>not assigned
+ </tr>
+ <tr>
+ <td>System.Data updates
+ <td>.NET 1.2 will introduce many new updates to the
+ System.Data namespace: MARS and ObjectSpaces are the
+ big ones.
+ <td>Medium
+ <td>6-9 months.
+ <td>Work with the mono-devel-list to keep track of things.
+ </tr>
+ <tr>
+ <td>System.XML updates
+
+ <td>.NET 2.0 will introduce many new updates to the
+ System.Xml namespace: XQuery and new XPathDocument are
+ the big changes.
+
+ <td>Medium
+ <td>6-9 months.
+ <td>Work with the mono-devel-list to keep track of things.
+ </tr>
</table>
projects / mono.git / blobdiff