StudentProjects

Revision as of 21:27, 15 Apr 2006
Miguel (Talk | contribs)
Ground Rules
← Go to previous diff		 Revision as of 21:30, 15 Apr 2006
Miguel (Talk | contribs)
ASP.NET
Go to next diff →
Line 222: Line 222:
The designer should be hosted in Gtk# (yes, it sounds strange), but its needed to host inside MonoDevelop. The designer should be hosted in Gtk# (yes, it sounds strange), but its needed to host inside MonoDevelop.
 +
 += GTK# Work =
 +
 +== DataBinding ==
 +
 +Complexity: medium
 +
 +Importance: high
 +
 +Modify Gtk# to provide databinding (as defined in the ".NET parlance") to allow Data to be automatically bound to forms and controls.
 +
 +== Ribbons Widget ==
 +
 +Complexity: medium
 +
 +Importance: cool factor foundation
 +
 +Implement a Gtk# widget that brings the Office-like ribbons to Gtk#. Focus is on managed widgets, not in C-based widgets.
 +
 +It should implement:
 +* Top level selectors
 +* Ribbons per each level
 +* Pop-down widgets with default actions
 +
 +Plus a sample application showing its use.
 +
= ASP.NET = = ASP.NET =

Revision as of 21:30, 15 Apr 2006

Summer of Code.

Please check this page for updates on fine-tuning some of the proposals and requirements as questions come in.

This page is maintained by Miguel (miguel@novell.com) please contact him to list new projects or if you have questions about a project. Notice that to apply for the Summer of Code, you should go through the standard Google process.

For Mono-related ideas not listed here or proposals, email Miguel. Notice that they must be related to Mono: either a component of Mono itself, a third-party add-on that others might use, a port of a Windows application to run on Mono or a killer application built with Mono.

Ground Rules

Language: code must be written in the same language as the host of the project: GCC extensions for example will be written in C. Mono VM extensions in C. Tools extensions in C#. APIs in C# and so on.

Licensing: All of the code submitted must be contributed under the terms of the MIT X11 license.

Acceptance criteria: the results must be mainteinable 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.

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 email why you should be considered to implement a particular project. From the hundreds of requests that we got last year, we discared in the first few hours 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.

Explain to us why you are a good candidate, also explain which projects interest you (in case that there is more than one) and why.

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.

Last year we had great results, and we want to improve upon those results.

If your idea is not listed here, and you think its a great idea that should apply to Mono or is related to Mono, please feel free to email miguel@novell.com and we will add the idea here, and we will consider your application.

Compiler Related Projects

GCC CIL Backend

Priority: high Difficulty: medium-high

During the last summer, some progress was achieved in creating a CIL backend for GCC. A backedn that would allow all of the GCC languages to target the Mono CIL intermediate language. But Jey, the developer behind this effort, broke his wrist before the project was completed.

We would like someone to retake this project.

His existing code lives here (http://forge.novell.com/modules/xfmod/project/?gcc-cil) and he kept a blog here (http://gcc-cil.blogspot.com/)

Objectives

The new version of GCC has a new internal representation called "GENERIC" (which is later transformed into "GIMPLE") which is suitable as a representation that we can use to generate ECMA CIL byte codes.

The task would be to write a backend to GCC4 that generates CIL byte codes.

This project should compile C initially, but should allow for external methods to be invoked through P/Invoke and structure passing and returning must be implemented.

Another component is that some mechanism for passing enough information to the backend must be arranged, this is so that we can emit proper CIL metadata for methods.

Some documentation can be found in gcc/doc (tree.defs has some explanations) and some older documentation is available here as well (http://gcc.gnu.org/ml/gcc/2002-08/msg01397.html)

Acceptance criteria: a non-trivial C application compiled to CIL should be demostrated to run on top of the Mono VM. For example, GNU tar, Midnight Commander, vi or anything moderately interesting (hello world does not count)

Managed C++ extensions to GCC

Difficulty: Medium-Hard

This project should extend the semantics of G++ to support the managed extensions as described on the ECMA standard.

Since the extensions are quite big, and it is not possible to do the whole thing during the summer, a submission should scope what things will be implemented. The compiler does not have to generate the code, but it must dump a description of the managed information it gather.

The specification is available here:

ECMA C++ (http://www.plumhall.com/ecma/)

For this project to be fully usable, it probably needs to integrate with the GCC-CIL.

PHP.NET

Priority: medium-high Difficulty: medium-high

Last summer we got most of a PHP.NET compiler for Mono, developed by Raphael Romeikat, the code is available here (http://php4mono.sourceforge.net/).

The work was partitioned in three stages; The first two stages have been completed, and we would like to complete the third stage to have a full PHP.NET Compiler.

Acceptance criteria: run a few major PHP applications without modifications (to be decided which applications).

Comega

Priority: low

An implementation of the main features of Comega (http://research.microsoft.com/Comega/) the new research language from Microsoft.

There are two subprojects:

  • Data type extension mechanisms.
  • Control flow extensions.

Both are independent projects.

Acceptance criteria: run the samples from here (http://research.microsoft.com/Comega/doc/comega_samples.htm).

Documentation Tools

Mono Documentation Engine

There are a number of tasks that must be completed here:

  • Add support for generics documentation to Monodoc, update the necessary tools in our documentation toolchain to cope with this (monodocer, updater)
  • Import updated ECMA generic docs into existing documentation.
  • Flag 2.x APIs as being only available in 2.x (modify the tools to cope with this).
  • Should add support to download updated documentation from the web.

Web-based Wiki editing of documentation

The documentation today can be Wiki-edited if we have a local tool, but we would like to bring this to the web as well. Most of the pieces are in place, but the flow is not implemented.

Acceptance criteria:

  • Should allow multiple-users to see the changes.
  • Should only allow the changes to be visible to the user that made the changes until the changes are approved for public consumption.
  • Should allow documentation to be updated on the server

CIL-based tools

Linker Tool for CIL

The idea is to create a "linker" for assemblies in Mono. The goal is to only ship the minimal possible set of functions that a set of programs might require to run as opposed to the full libraries.

This is convenient in many cases:

  • Embedded systems could continue to work, but not resort to hacks to fit Mono down==
  • It could be used to generate libraries for multiple profiles from the same binary: ECMA profile, 1.0 profile, 1.1 profile, 1.1 service pack profile, etc.
  • Applications that embed Mono could reduce the download size by shipping only the bits that they require.

Given a set of libraries and a root set which can be a program, a library or a list of classes and methods, the program would use the CECIL or PERWAPI APIs to read the root set and perform a Mark and Sweep like process and extract everything that is marked into a new binary.

The Mark and Sweep needs to be very inclusive and should be possible to augment it with flags or extra work to do, so the behavior of the program can be customized.

API problem finder

Using Cecil to inspect binaries: public APIs should adhere whenever possible to the coding guidelines for .NET components as well as CLS compliance.

Windows developers have a similar tool called FxCop.

Today we have Gendarme, but it only contains a handful of rules, we would like to bring to Gendarme more rules to assist developers developing software catch errors ahead of time

Replacing CIL with native code.

Complexity: hard Priority: low

Background: Mono contains a code generator that can be used for Just-in-Time compilation at runtime or code can be compiled Ahead-of-Time to produce native code in advance.

JIT compilation is the most common mode of use, but for some systems that do not have much memory or which want to improve startup its best if the memory consumption can be kept down by pre-compiling the code.

The problem today with the later case is that we ship two binaries:

  • Original file which contains metadata and bytecodes.
  • Generated native code.

But the bytecodes are no longer required and they only bloat the distribution.

The goal is to modify Mono's runtime and compialtion so that the bytecodes can be safely removed from a program and a single image is shipped containing: metadata + native code.

Bug Finder

Using Cecil to inspect the bytecode in an program or library: a tool that reconstructs the semantic trees, and catches common patterns of code that lead to bugs in the code, examples include: recursive property invocations, double-lock problem, calling an event without using a local variable (thread-safety issue)

There is a Java tool that does something similar for Java.

Resources:

Acceptance criteria:

  • Software must be maintainable, so after you leave we can take maintainership of it (if you choose to orphan the project).
  • Dataflow analysis should be implemented (this is the hard one).
  • Double-check locking detection.
  • Null pointer dereference
  • Simple checks for recursive invocations (particularly in properties: int X { get { return X; } })

Windows.Forms

Windows Forms 2.0 controls

Mono today has focused on Windows.Forms as shipped in .NET as version 1.x, but various new controls are available, there are some trivial controls and various larger controls.

There are numerous controls that are new, and we would love some external input in implementing them.

Acceptance criteria: if you pick simple trivial controls, we would expect you to implement a handful, and provide unit test cases as well as polished controls (not quick-and-dirty controls).

If you pick a larger, more complex control we would relax the acceptance criteria.

Some implementation details:

WebControl: should integrate Gecko and expose it as a Windows.Forms control.

Accessibility Support for Windows.Forms

Use the Gnome Atk Framework to add support accessibility support for Windows.Forms (the Accessibility namespace).

This is important not only for accessibility purposes, but to be able to create automated regression test suites using the Linux Desktop Testing Project (http://www.gnomebangalore.org/ldtp)

Windows.Forms Designer

We would like to have a GUI designer for Windows.Forms controls, and an implementation of the APIs required to host the designer on an application. The project is to implement the designer hosting facility

This should be written using Windows.Forms in C#.

Some people have pointed out the SharpDevelop GUI designer. This GUI designer is merely a wrapper around a native library provided with Visualstudio. You might want to implement that API, so that the code from SharpDevelop could be used "out of the box" (notice that running SharpDevelop on Mono today is not possible, so you will have to cut and paste code to try your designer out).

Some background can be found here: Hosting Windows Forms Designers (http://www.divil.co.uk/net/articles/designers/hosting.asp)

The designer should be hosted in Gtk# (yes, it sounds strange), but its needed to host inside MonoDevelop.

GTK# Work

DataBinding

Complexity: medium

Importance: high

Modify Gtk# to provide databinding (as defined in the ".NET parlance") to allow Data to be automatically bound to forms and controls.

Ribbons Widget

Complexity: medium

Importance: cool factor foundation

Implement a Gtk# widget that brings the Office-like ribbons to Gtk#. Focus is on managed widgets, not in C-based widgets.

It should implement:

  • Top level selectors
  • Ribbons per each level
  • Pop-down widgets with default actions

Plus a sample application showing its use.


ASP.NET

Web Services Enhancements

Importance: medium

Complexity: high

We're not developing WSE anymore but it contains a lot of important web services standards. Implementing even a subset of WSE1 or WSE2 (i.e. the specs that still exists) would be beneficial to a lot of people (including the Windows users who will be left support-less after WSE3 and forced to upgrade to Indigo).

See the page on WSE for details.

MonoDevelop

The following projects are extensions to Mono's IDE: MonoDevelop (http://www.monodevelop.com). MonoDevelop features a plugin architecture (http://www.monodevelop.com/Developers) which is fairly well documented. The plugin architecture will simplify the development of extensions for it.

Many things can be done by porting code from SharpDevelop 2.0 into MonoDevelop and replacing piece-by-piece the existing code.

Although we list *some* features here, there is a rather extensive list of tasks that we would like to get done, please see the list:

  • here (http://www.monodevelop.com/TODO)


Source Code Control Integration

Add support for MonoDevelop to support source code control.

At this point we would like to see support for Subversion as there are libraries available in C# to access the Subversion repositories.

Mono Debugger Integration

Importance: Medium

Complexity: Medium

We would like to integrate the Mono Debugger (this should be an optional dependency, as the debugger is still not API stable) into MonoDevelop to enable developers to debug from within the IDE.

ASP.NET Editor Integration

Complexity: medium

Importance: high

Last summer Michael Hutchinson and Blagovest Dachev created a GUI editor for ASP.NET pages. We would like to see a MonoDevelop Add-in that would allow developers to maintain web sites with it.

The add-in can take inspiration from both WebMatrix and the new VS.NET 2005 development style for applications. It should also ideally launch XSP on demand to test drive the pages.

C# 2.0 support

Complexity: high:

Importance: high

Add support for C# 2.0 language constructs to MonoDevelop (generics, anonymous methods, partial classes, iterators) so that the parser can cope with them and support intellisense with it.

In addition this effort should allow for applications to be built with gmcs in addition to mcs.

Porting New Components from SharpDevelop 2.0

Complexity: medium:

Importance: high

Interlock with other delopers: high

SharpDevelop 2.0 has many new features that are not present in MonoDevelop, we would like to backport those to MonoDevelop (maybe even the editor and new completion engines).

Others

There are many other items listed on the MonoDevelop [1] (http://www.monodevelop.com/TODO), make sure you read it.