Dotgnu Coding Competition 132
Honestly writes "Apparently DotGNU seems to be offering more than the 'warm fuzzy feeling' to its contributors. Somebody has funded about $4500 worth of prizes for code contributions. The developers have confirmed that the $$$ is in FSF Hands (good hands, I suppose). Here is the split up of prizes. It's almost strange to earn money writing open source. Especially when you're not even
employed by dotgnu. Anyway all I can say is ,I like it. It's ideal for a grad student with lots of free time. But hardly anyone seems to have seen
the Newsforge posts (except maybe me)."
Re:fp (Score:3, Informative)
Re:What about Mono (Score:5, Informative)
Re:System.Windows.Forms (Score:2, Informative)
Re:Not so strange. (Score:2, Informative)
He's getting paid to write the kernel, paid by OSDL, more info here. [osdl.org]
PNET vs Mono (Score:4, Informative)
DotGNU in the past has tried to cooperate and initiated talks in sharing resources, but this didn't go well with Mono.
The true difference between Portable.NET and Mono is Portable.NET has chosen different technical decisions.
#1: The compiler is written in C/C++ not C# itself, so it doesn't have the chicken or the egg problem. Mono's CVS is very difficult to get a handle of because of this. PNET's compiler is about 3x as fast as Mono's.
#2: The topic at hand, winforms.. PNET's winforms only dependancy is X, which means their winforms work on handhelds, osx, etc. Very portable. Mono's requires Wine, not very portable to say the least.
Thats a rough quick sum.
Re:Only for the incrowd? (Score:1, Informative)
If you are hacking on System.Windows.Forms at least one of your code contributions needs to get accepted into the official pnetlib so that you are considered as a participant.
The contest - of course - isn't restricted to people who already contributed something.
Re:What about Mono (Score:2, Informative)
An advanced native-code compilation engine: Both just-in-time compilation (JIT) and pre-compilation of CIL bytecodes into native code are supported.
Portable.net uses an advanced unrolling interpreter which gives it up to 60% the speed of a real JIT and makes it much easier to port than the mono JIT. It only took a week to port the unroller to arm processors.
In the future Portable
A foundation for code optimization: The new code generator in Mono builds on the experience of our first JIT engine, and enables us to implement various advanced compiler optimization tricks. With an SSA-framework, plenty of new optimizations are possible.
The current list of optimizations are: Peephole postpass, Branch optimizations, Inline method calls, Constant folding, Constant propagation, Copy propagation, Dead code elimination, Linear scan global reg allocation, Conditional moves, Emit per-domain code, Instruction scheduling, Intrinsic method implementations, Tail recursion and tail calls, Loop related optimizations, Fast x86 FP compares, Leaf procedures optimizations
That's only unique cause Mono currently has a JIT. It's not unique to the Mono project.
A self-hosting C# compiler written in C#, which is clean, easy to maintain.
Focus on the
And the API that is the most poorly designed (when compared to OO libraries like Java).
A multi-platform runtime engine: both a JIT engine and an interpreter exist. The JIT engine runs currently on x86 systems, while the interpreter works on SPARC, StrongARM, s390 and PowerPC systems.
Our new compilation engine is being ported to the PowerPC.
Now the wording of this paragraph is designed to decieve. The first part talks about a multi-platform runtime engine which is infact not unique to mono. In reality, portable.net runs on far more platforms than mono. The second part just goes on to talk about how the new compilation is going to be ported to PowerPC.
Supports Linux, BSD, Windows and Solaris at this point.
Portable.Net supports Linux, BSD, Windows, OSX, and more. In fact, all you need is a C compiler -- you can even compile portable.net with Visual C++ (try doing that with mono).
The JIT engine is written using a portable instruction selector which not only generates good code but is also the foundation to re-target the JIT engine to other systems.
More about the JIT. All of this "amazing" stuff is pretty standard for a JITs.
Full support for remoting in the runtime.
I'll give them that.
The C# compiler, the JIT engine and the class libraries are mature enough that the whole system has been self-hosting since April 2002. This means that we develop Mono completely with itself at this point.
By forcing ourselves to use our own code to develop our tools, we bug fix problems rapidly, and the system is overall more robust and tested than if we did not.
That's not unique to mono either.
We have a great community of developers, without which Mono would not be possible.
In general, Mono is more mature and complete since it has been used to develop itself, which is a
And so does portable.net. Too many mono developers are newbie or ex VB programmers which makes *a lot* of the code in mono extremely ugly hacks.
I beg to differ (Score:4, Informative)
I was involved in that argument. If I recall correctly, it was a Rhys Weatherly and some others demanding that the Mono be placed under the DotGNU steering committee and that everybody work on their project instead. Of course, at the time it was quite obvious that DotGNU was mostly ideologues who were obsessed with 'defeating Microsoft' through some embrace and extend tactics, whereas most of the Mono hackers were fairly pragmatic about the whole issue: 'This is pretty cool! I'd love to see an implementation of this in Linux!'. Most of the people who weren't turned off by the downright abrasiveness of Rhys were turned off by the zealous ideology.
As for bad-mouthing, the only thing the Mono FAQ says about Portable.NET as opposed to Mono is that it the runtime (and compiler) are much less tested. Ximian claims that by developing the compiler and most of the rest of Mono in C#, the whole toolchain has been given a much more rigourous workout than Portable.NET.
In fact, I'd say the badmouthing has been much more in the other direction: there used to be a page around on the DotGNU website (not sure if it's still there) badmouthing Mono. None of the claims had any substance. For example, it claimed that Mono was on shaky legal grounds with regards to hidden Microsoft patents, which may perhaps be true. However, Portable.NET/DotGNU isn't safe from those legal threats either. Further, while Mono was developed from the ECMA (and now ISO) specifications, Portable.NET was initially developed by reverse engineering Microsoft's .NET implementation (without any clean-room engineering), putting it at risk of copyright infringement claims as well as patent claims. This was also part of the reason why there was little interest from Mono in merging the class libraries.
I suspect things are probably more civil these days. Cooler heads usually prevail in the end.
As for your other claims....
#1: The compiler is written in C/C++ not C# itself, so it doesn't have the chicken or the egg problem. Mono's CVS is very difficult to get a handle of because of this. PNET's compiler is about 3x as fast as Mono's.
Mono's CVS is easy to handle. It is distributed with a partial prebuilt toolchain, that is then used to build the entire toolchain. It's all MSIL, so there are no platform portability issues. It is also standard practice to write a compiler in its own language.
#2: The topic at hand, winforms.. PNET's winforms only dependancy is X, which means their winforms work on handhelds, osx, etc. Very portable. Mono's requires Wine, not very portable to say the least.
WinForms contains a number of window-isms, which the Wine project have already implemented. Reimplementing winelib seems silly and a waste of energy. I can't imagine it'd be appreciably harder to port Mono's WinForms implementation across platforms had it been written from scratch than it would be to port winelib itself. And if winelib gets ported, people other than Mono users and developers can benefit from that work.
Anyway, just my $0.02.
Re:System.Windows.Forms (Score:3, Informative)
Re:Wine? (Score:2, Informative)
Re:No, you weren't involved (Score:3, Informative)
Phase 1: DotGNU and Mono announced on the same day by the FSF. Mono to work on the framework, DotGNU to do the more undefined parts of
At this point cooperation was not possible, because it turned out the DotGNU team wanted to invent a new virtual machine that supported Java and
Then we were asked something like `you will work with us better than with proprietary companies'. This is ridiculous in that you cant make this kind of promises. Specially with a team of people (the DotGnu) who had no track record of writing anything of large scale. So to us, a relatively experienced team of developers, being told this by a team of self-appointed "core team" of unexperienced people was a non-starter.
Phase 2: Portable.NET bends over and accepts every wacky idea of DotGNUers. The idea here is that Portable.NET had to please the desires of the dotgnu kids, so a promise to support JVM binaries at the same time and generating code for both was made. They got this working to some extent, but again, its slow, untested, and very broken.
Phase 3: the code donation. Mono received under the terms of the MIT X11 license, a copy of the I18N code. A pretty small chunk of code, and lots of data files that come from the IBM ICU library (about 4k lines of code, plus 46k of data files).
This was the beginning of cooperation.
The cooperation did not last long, because even when we submitted fixes to them, and pointed them to new codecs, they decided to change the license of their code to GNU GPL, because they felt cooperation with us was useless.
Licensing:
We use the more liberal MIT X11 code, which they have liberally integrated into their code base, but since we are commited to eliminate any potential licensing problem that a proprietary software developer might have with Mono, we will not use the GNU GPL or GNU LGPL in our libraries.
We could not use PNet's code for two reasons: we just plain dont like the coding style (coming from the Linux/Gnome coding conventions), and second the reverse engineering that was done in Australia (what Norbert claims is ok) would put anyone distributing the software in the US under a potentially interesting legal situation.
It is our responsability to the contributors of Mono who have devoted tons of hours to it, and to the users to make sure that there is not the slightest potential legal problem with the code that would make their contribution useless. We dont want anyone FUDing in the future like its being done with SCO. So we had to have more strict legal procedures.
For instance, we recommended people not to look at Rotor source code until we had the equivalent Rotor functionality implemented. Pnet follows a different approach: read Rotor, and do a new implementation of it. Might be better for interop, but I sleep better at night
Miguel.