diff options
Diffstat (limited to 'web/mono-todo')
| -rw-r--r-- | web/mono-todo | 266 |
1 files changed, 0 insertions, 266 deletions
diff --git a/web/mono-todo b/web/mono-todo deleted file mode 100644 index c57c430c9b2..00000000000 --- a/web/mono-todo +++ /dev/null @@ -1,266 +0,0 @@ -* 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. - - * <b>AOT compiler</b>: optimizing the compiler output and the AOT loader, - better support for multiple application domains. - - * <b>VM runtime</b>: optimizing the runtime data structures, experimenting with - different garbage collectors, integration with different component models. - - * <b>Class library</b>: many opportunities in the implementation of regular - expressions, Xml related technologies (XPath, XLST, etc). - - * <b>Compilers</b>: writing compilers, interpreters and runtimes for langauges - so that they run on the CLR (using Reflection.Emit support, for example). - </ul> - -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>System assembly (mcs/class/System/) - <td>Implement the IL-based regular expression engine. Instead of - intepreting the regular expression pattern, a method is created at runtime using - Reflection.Emit. This makes for faster pattern matching because there is no - intepreter overhead and the matching code is jitted to fast native code. - Bonus points if the compiled regular expression is compatible with the ones generated - by the MS runtime. - <td>Medium-hard (thesis subject) - <td>2-4 months - <td><a href="http://bugzilla.ximian.com/show_bug.cgi?id=52605">52605</a> - </tr> - - <tr> - <td>JIT (mono/mini/) - <td>Implement common subexpression elimination. - Global and local common subexpression elimination needs to be implemented - to achieve better performance. The local case is easier and may take just one month. - It should be implemented in the context of the SSA framework (mini/ssa.c). - <td>Hard (thesis subject) - <td>2-4 months - <td>not assigned - </tr> - - <tr> - <td>JIT (mono/mini/) - <td>Optimize AOT compiler output. - Currently the code generated by the AOT compiler may be significantly slower than - jitted code. This is mostly because the AOT code supports multiple application domains - and some values that are constant at JIT-time are not constant at AOT-time. It may be - needed to write a simple dynamic linker and/or binary object writer. Bonus poinst if - it supports ELF, PE/COFF and mach-O binary formats. A possible idea for improvements - is also the use of appdomain ID-indexed tables to get at the appdomain specific data. - <td>Medium-hard (thesis subject) - <td>3-6 months - <td>not assigned - </tr> - - <tr> - <td>JIT (mono/mini/) - <td>Port the JIT to additional architectures. - 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 - </tr> - - <tr> - <td>Runtime and JIT (mono/metadata and mono/mini/) - <td>Add support for COM and/or XPCOM and/or ORBit. - We need a way to seamlessy use existing component technologies inside the mono runtime. - The COM support needs to match the MS runtime behaviour and is targeted at windows systems. - XPCOM and ORBit support are important on Unix platforms. Bonus points for developing - the runtime support so that different component systems can be used at the same time. - <td>Medium-hard (thesis subject) - <td>3-4 months for each - <td>not assigned - </tr> - - <tr> - <td>Runtime and JIT (mono/metadata and mono/mini/) - <td>Implement support for Code Access Security. - Support needs to be added to the JIT and the runtime to ensure - code that executes privileged operations is permitted to do so. - The task includes loading the security information from metadata, - collecting evidence, inserting calls to the permission objects, - stack walking to collect security info. - <td>Medium-hard (thesis subject) - <td>4-5 months - <td><a href="http://bugzilla.ximian.com/show_bug.cgi?id=52606">52606</a> - </tr> - - <tr> - <td>Runtime and JIT (mono/metadata and mono/mini/) - <td>Implement support for a generational GC. - We're currently using a conservative non-moving GC. - Support for a generational and moving GC requires changes to the JIT - (to record locations in frames as well as registers that may contain - pointers to GC-allocated memory) and to the runtime code (when - objects are manipulated directly we should make sure they are pinned - and reachable by the GC also in the C unmanaged code). Code from an existing - precise GC such as the ORP one could be reused or a new GC may be developed - (increasing the estimated development time). - <td>Hard (thesis subject) - <td>6-8 months - <td>not assigned - </tr> - - <tr> - <td>Compilers for dynamic languages - <td>Write a IL compiler and runtime support for dynamic languages like - Python, Perl, Ruby, PHP. - <td>Medium-hard (thesis subject) - <td>6-12 months - <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> - |