Slashdot Mirror
Mono Beta 2 Released
A little birdy writes "Less than a month after Beta 1 was released,
Mono Beta 2 has been released. See the Release Notes, or go directly to the download page. It includes a C# compiler, an implementation of the Common Language Infrastructure and two stacks of APIs: a Unix, Linux, GNOME, Mono stack for APIs that takes the most advantage of your Unix server and desktop and a set of APIs compatible with the Microsoft .NET Framework 1.1 that provides support for ASP.NET (web services and web forms), ADO.NET and many other components." And in a related story: darthcamaro writes "The drive to develop a FOSS implementation of Microsoft's .NET framework by DotGNU and Novell's Mono project is being painted as a contest between the Free and Open Source communities in an article on internetnews.com. The article details the running argument between DotGNU's Norbert Bollow and Mono's Miguel de Icaza on the issues of commercial involvement, software patents and all the 'religious' stuff that the Free software community holds against the open source community."
The mono C# compiler is a work of engineering genius.
It uses a program called TreeCC which goes beyond the Lex+Yacc model and provides an aspect-oriented tree programming model. This makes it very easy to write visitor patterns on your tree, and you can do syntax and semantic analysis with ease.
The resulting source code for a full working C# compiler is minute. TreeCC expands it into the real code.
Check it out!
It will be interesting to see what the performance comparisons of MSNET/MonoNET and MonoNet/LinJava. I would also like to see the CLI for Java project gain steam to take over some MS mkt share on the Winserver side (and allow seamless upgrades to Lin/Unix for those). Since C-pound is much like a C++/Java mutant it is not hard to transfer to the language.
I'm quite interested in seeing the first tools to take advantage of System.DirectoryServices, as this should enable us to manage a windows Active Directory natively from Linux.
I agree with Bollow's reasoning and reality, but I fear that his sentiments may fall far short of his dream. He'll have to cope with
With that said, I think it's a very good idea to try to slowly nudge Microsoft developers over to other platforms, particularly if we come out with more advanced and/or convenient features than Microsoft's own standards. Nevertheless, time will tell whether this project pans out or not.
I was under impression that mono has switched to a modern generational garbage collector, the Intel ORP GC. But the current beta uses the conservative boehm garbage collector.
A conservative GC is nice for a quick hack, but it really does not cut it for a modern VM.
So which one will it use in mono 1.0? Boehm or ORP? And if it is the boehm collector, what plans are there to switch to a modern GC?
By the way: the conservative garbage collector is the only real technical flaw of mono. Other than that it is quite a modern VM. Quite amazing for this short development time...
--
Private property is the central institution of a free society (David Friedman)
Ive seen MonoDevelop and SharpDevelop and am not impressed with either. The day Novell is able to churn out an IDE like VS.NET for MONO is when Mono will be really able to make waves.
Read this
Yes, we are not able to fully support the
Windows.Forms API on the 1.0 timeframe (you can
get the previews, but they are not ready to ship).
Windows.Forms has a number of problems for
open source software anyways: for instance, it
does not do constraing-based layout, so for
every language that you want to support, you must
relayout your dialog boxes manually (or if you
have a larger font size).
By using Gtk# you take advantage of the Linux-specific
APIs and Linux-specific features (you can use
Gtk# on Windows, Linux and MacOS).
On the other hand, there is a community of
MacOS developers working on bindings to Cocoa
bindings to give them the same flexibility and
OS integration on the Mac.
Windows.Forms would give you a Windows-solution
everywhere.
We are going to support it for the sake of helping
Windows developers move to Unix, but it is not
a particularly great toolkit.
miguel.
I agree that building on top of Wine is far from
ideal, but it has some benefits. For instance
we are able to support applications that want
to embed IE, or use Direct3D.
Miguel.
Additionally, Gnome GUI programming is much different, and SUPERIOUR to the Windows.Forms layout. Windows.Forms reflects that exactly, Windows. Absolutly positioned buttons, and loosely wrapped COM controls. GTK layout is vastly different, using theming engines, multilingual input methods, and automated layout and positioning. Additionally the font support in the Gnome stack can select glyphs from multiple fonts.
Windows.Forms is built for Windows... and thusly, running it under Wine is a perfect compromise.
Hello,
Part of the problem is that the Windows.Forms API
exposes an entry point to hook up to the win32
programming model the `WndProc' method override
on Control.
This is used to allow the developer to catch events
and process events that Windows.Forms might not
support directly with the managed API.
Also, since the Windows.Forms and Drawing APIs
are not comprehensive, developers of third-party
controls often depend on calling into Win32
calls (with P/Invokes). These are used for
special effects or more complicated behavior than
is available through the managed APIs.
For instance, a common scenario is embedding
the IE control and hook up to its DOM (see the
cute Reflector from Lutz Roeder).
Suboptimal, I know.
Although the official reason that GnomeBasic was dropped was because of "stagnation", the real reason that it died was because Mono was supposed to take it's place.
If that happened, I've seen no evidence of it.
While you can write Mono code in Java, PHP, Logo, Oberon, Pascal, Forth and Lisp, VB is still unavailable.
It's a pity such a popular language appears to be entirely ignored.
You said that if you don't use GTK# your app will run on Windows. This is wrong. GTK# apps can work on Windows, or MacOS X just fine.
Understand this: the portability of an application is not defined by the type of machine (virtual or not) it's running on, it is by and large defined by the portability of the compilers and frameworks/libraries it relies upon.
GTK+ is a portable widget toolkit, it works pretty well on Windows and MacOS. The Win32 widget toolkit is not very portable, mostly because the only open source implementation is the Wine implementation and Wine by policy only concentrates on application compatibility, not on having nice pretty widgets.
So, if you are writing a .NET application you are best advised to use GTK# - this is true even if you are writing a program meant for Windows as in future if you wish to port things to another platform it will be a lot easier. There are a few other things to consider as well, such as the nicer API GTK has.
As to the DotGNU approach vs the Mono approach, basically I think you'd have to be insane to want to reimplement what Wine has done. Nobody is going to use System.Windows.Forms on Linux because it blows goats, everybody will use GTK# or (maybe when it is mature) Qt# - therefore a SWF implementation is useful only for application compatibility.
As to mapping S.W.F to Gnome/GTK, forget it. Back in the day (waaaaay back) Wine attempted to map the Win32 widget toolkit to Tk which was one of the better toolkits available back then. Didn't work. Widget toolkits differ too much to succesfully map between, and in particular the differential between a modern toolkit like GTK+ and Win32 is enormous - why do you think Microsoft are so keen to scrap it and start over with Avalon?