Working with C# is very nice, I’ve testes some applications with SharpDevelope and its very nice, now, Im trying to make the move to GTK# with mono, dows anyone know if the GTK# bindings are the same or almost the same as Windows.Forms?
I think it’s kind of a shame that the DotGNU project and Mono aren’t working together. They both have similar goals.
In most circumstances I’d say competition is great. But in this case, I don’t see the need for it and may just slow down the eventual final product. What would benefit everyone is if they just worked together toward a unified goal.
The mono core is based on the ECMA CLI specification (submitted by Microsoft) which already has support for generics, Mono did not “add” this to the compiler…it’s already there.
What are you blind? No one said Mono “added” it. He said it’s impressive that the compiler supports it already.
“At this point our generics compiler (gmcs) and runtime seem to be feature complete, Martin has been working steadily on the compiler front, and some bits of the Generic class libraries.
Our next tasks are to review the specification and make sure we flag every possible error as well as continuing the implementation of our generic class library.
Although Generics are available now as the gmcs compiler, they will not be part of the 1.0 release, the generic compiler is only present for those working on the post Mono 1.0 components.”
I did not say Mono “added” generics to the compiler, I said the compiler now completely supports generics. I know Mono follows the ECMA CLI specifications.
It’s no secret that there’s animosity among some members of the two projects. Also, Dotgnu’s compiler is written in c and the runtime uses some hybrid jit/intrepretation mechanism. Dotgnu’s compiler can also compile c code to IL. Mono’s compiler is written in c# and the runtime is JIT. Right now, Dotgnu is more portable than Mono and Mono is more feature complete. That said, it would be nice if there was a little bit more collaboration on the class libraries. IIRC, there has been in the past, but I don’t know much is done now.
Unfortunately, since Sun decided not to change the runtime its version of generics is just syntactical sugar and not real generics. Everything will still be objects in the data structures and the compiler will just do the boxing and unboxing for you. So, you won’t get the peformance enhancements with true generics because you’ll still have boxing and unboxing and also won’t be to use any kind of reflection to rebuild types on the fly. At least they got variable length arguments(a proper printf with it) and a foreach construct.
i think right now dotgnu’s CLR is interpretive only (mono is JIT on x86 and SPARC, also PPC, i think). but i find it impressive that they’ve got more comprehensive Windows Forms support, compared to the “requires WINE” approach of mono
Does this release work on FreeBSD? The last time i looked for the port of Mono it was broken. I develop on Windows, but i would like to test if my programs also work on Mono.
Contrary to what some people say, i believe that Miguel and company made a good decision to create Mono. Mono doesn’t have to follow Microsoft with everything, but the base .NET framework is very good. I don’t think there are a lot of developers who disagree with that. There is nothing wrong with taking the good parts and trying to expand it into something that is even better than what Microsoft offers.
“Does anybody know how mature is the Database handling with mono?”
Its pretty much the same as in .net itself. I recently set up mono to work with mysql and it was very very easy. I downloaded the mysql c# library intalled it and added the code. That was it.
Wow so they did do the xwindows to c# binding thing. Hmmmm. Interesting. I have alot of respect for the mono project but I dont run gnome with my distro and so I havent been able to play around with c# windowing which has bummed me out. I looked at the qt# project and thats dead. But I started thinking how is it that open office and mozilla work under both enviromments and why cant someone make a bridge to that.
If you compare Mono to DotGNU, Mono have the most advantages, I think.
But there is one big disadvantage of Mono: The dependences.
If you want to install DotGNU (in binary or in sourcecode) you don’t need additional libraries.
But if you want to install Mono (And I mean only the mono-runtime with C#-compiler and basical libraries. No Gtk#, no Winforms, etc), you need glib. And glib needs some other libraries, which must been installed.
And all the libraries blow up Mono. And then there existing KDE-people, who don’t want install glib. And all other non-GTK+ people (that are all of the other platforms like MacOS X, BeOS, Syllable, etc) don’t want too much additional libraries, too.
I know, that it is for Miguel and the other one, easier to write something with GObjects. But I think, that it would be better, if the fundamental core of Mono is only written in ANSI C with assembler extensions and other extensions, which are really needed. No additional libraries or so.
Additionally, building DotGNU from source on either windows or linux is trivial. Just cvs checkout treecc, pnet, pnetlib and then ./configure, make install them. With mono you have to bootstrap your way into a full setup from source and the way things are supposed to get built tends to change around quite a bit. Mono has ties to Gnome so its no surprise that they leverage Gnome libraries. Building mono from scratch on a mostly KDE system is going to be a task and a half because of the dependencies explosion, but there are rpms and debs out there for those that don’t want the fuss.
DotGNU’s Windows Forms is interesting, but I just hope there is going to be a way to get it themable at some point.
I thought glib is a very stand alone library. It might need X, but then, that is the target of the development on *nix anyway. Other than than, glib is not huge, is very convenient, and there is no reason to reinvent the wheel if glib does the job. It also helps the quality of the dependencies because now we have a large company (Novell) that is interested in keeping them modern and well developed.
People who do not want to install glib because it was developed by people affiliated with GNOME and because it was developed in C are not to be listened to anyway. I do not see what the problem is. glib is only 2.5 MB in source form, so size consideration are not realy at issue. If you are going to pass up a very good technology like mono because of zealotry about KDE/GNOME or C/C++, then you will get left in the past and no one will miss you.
“Building mono from scratch on a mostly KDE system is going to be a task and a half because of the dependencies explosion, but there are rpms and debs out there for those that don’t want the fuss”
But it is a big thing, as a general rule Mac owners are not build from source types, do will not have glib, pkg-config, etc on their Macs so this will have to be packaged for them. As for no dependencies on X, does winelib have a Carbon port, or are you not counting SWF.
Is GTK# preferred, oh that out then until there’s a native port of GTK, which well looks unlikely considering the lack of interest in the GTK-Aqua and GTK-OSX projects. GTK of course would throw in another stack of dependencies (pango et al).
It seems that they switched from the boehm conservative garbage collector to the intel ORP garbage collector. I never heard of this one, but it seems that it is a precise generational garbage collector.
There are very little dependencies today for MacOS and as its users do not want to deal with any such dependencies, Mono will sport a nice MacOS X installer soon which will take care of that. On Linux there are already RPM for most distros as well as a Red Carpet channel. On Windows, the project has had installers for a while too.
On all platforms Mono is now becoming much more user friendly and not just to developers contributing to Mono but to developers wanting to develop applications on Linux Desktops as well as cross platform applications. It’s also exciting to see MonoDevelop making such great progress with source level debugging and documentation browsing.
I noticed that the 0.30 release of Mono on Windows also had a download of Gtk# available, while the 0.31 section doesn’t. Is Gtk# integrated into the 0.31 installer, or will the prior version work with 0.31, or is there a new Gtk# download pending or what? Perhaps the previous version’s Windows.Forms were based on Gtk#, hence the libs, but the new version’s changes make Gtk# unnecessary on Windows?
While I’m at it, does Gtk# on Windows hook into the native controls and theming engine of Windows XP and such?
And then there existing KDE-people, who don’t want install glib.
Most of linux applications are use GTK and glib. Without this you can’t use many linux applications, like gimp, bluefish, evolution,etc. And IMHO in long term KDE and Qt will disappear, because of Qt license.
There are alternatives to every GNOME/GTK program out there (well, except the Gimp, but there’s GTK-QT). I’m no KDE fan but I know many that can live happily without using any GTK application. That said, I believe that GTK applications are usually of a better quality but that’s probably just me…
Working with C# is very nice, I’ve testes some applications with SharpDevelope and its very nice, now, Im trying to make the move to GTK# with mono, dows anyone know if the GTK# bindings are the same or almost the same as Windows.Forms?
No, they are not the same. Gtk# is based on Gtk+, but you shouldn’t have a problem picking up Gtk#. Hopefully, the documentation has improved.
No.. this is 0.31 just like it says on the go-mono.com website…..
Nice to see this sane alternative to XML Schema get support
My God, this project is on steriods. Impressive to see the compiler supports generics already.
I think it’s kind of a shame that the DotGNU project and Mono aren’t working together. They both have similar goals.
In most circumstances I’d say competition is great. But in this case, I don’t see the need for it and may just slow down the eventual final product. What would benefit everyone is if they just worked together toward a unified goal.
They have to work like crazy. They’re roadmap states that their 1.0 will be released in Q2 of 2004.
“My God, this project is on steriods. Impressive to see the compiler supports generics already.”
The mono core is based on the ECMA CLI specification (submitted by Microsoft) which already has support for generics, Mono did not “add” this to the compiler…it’s already there. http://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q….
Isn’t there some sort of story behind this?
Nice. I love the “Mono Exclusive” labels, it adds a nice marketing touch to it.
I think they do share a lot of code – just not the base stuff. one is written in c and the other in c#
The mono core is based on the ECMA CLI specification (submitted by Microsoft) which already has support for generics, Mono did not “add” this to the compiler…it’s already there.
What are you blind? No one said Mono “added” it. He said it’s impressive that the compiler supports it already.
From the changelog:
“At this point our generics compiler (gmcs) and runtime seem to be feature complete, Martin has been working steadily on the compiler front, and some bits of the Generic class libraries.
Our next tasks are to review the specification and make sure we flag every possible error as well as continuing the implementation of our generic class library.
Although Generics are available now as the gmcs compiler, they will not be part of the 1.0 release, the generic compiler is only present for those working on the post Mono 1.0 components.”
I did not say Mono “added” generics to the compiler, I said the compiler now completely supports generics. I know Mono follows the ECMA CLI specifications.
It’s no secret that there’s animosity among some members of the two projects. Also, Dotgnu’s compiler is written in c and the runtime uses some hybrid jit/intrepretation mechanism. Dotgnu’s compiler can also compile c code to IL. Mono’s compiler is written in c# and the runtime is JIT. Right now, Dotgnu is more portable than Mono and Mono is more feature complete. That said, it would be nice if there was a little bit more collaboration on the class libraries. IIRC, there has been in the past, but I don’t know much is done now.
Unfortunately, since Sun decided not to change the runtime its version of generics is just syntactical sugar and not real generics. Everything will still be objects in the data structures and the compiler will just do the boxing and unboxing for you. So, you won’t get the peformance enhancements with true generics because you’ll still have boxing and unboxing and also won’t be to use any kind of reflection to rebuild types on the fly. At least they got variable length arguments(a proper printf with it) and a foreach construct.
i think right now dotgnu’s CLR is interpretive only (mono is JIT on x86 and SPARC, also PPC, i think). but i find it impressive that they’ve got more comprehensive Windows Forms support, compared to the “requires WINE” approach of mono
Remamber at http://www.osnews.com/story.php?news_id=6379 , where Havoc thinks about “Java, Mono, or C++?”. Now lupus have (by Mono) have answerd at http://www.advogato.org/person/lupus/diary.html?start=10
An other intereisting article is this one by Miguel:
http://primates.ximian.com/~miguel//texts/gtkjava.html
He writes, how to write with Mono and IKVM Java-programs, which use .net-code.
Does this release work on FreeBSD? The last time i looked for the port of Mono it was broken. I develop on Windows, but i would like to test if my programs also work on Mono.
Contrary to what some people say, i believe that Miguel and company made a good decision to create Mono. Mono doesn’t have to follow Microsoft with everything, but the base .NET framework is very good. I don’t think there are a lot of developers who disagree with that. There is nothing wrong with taking the good parts and trying to expand it into something that is even better than what Microsoft offers.
Just curious how does dotgnu implement windowing?
I know Mono does it through either gtk# or wine.
But does dotgnu do it differently?
> Just curious how does dotgnu implement windowing?
What I have heard is, that they have written a X-binding, called X#.
(In this case X# isn’t the MS XML language, its the X-binding)http://savannah.gnu.org/cgi-bin/viewcvs/dotgnu-pnet/pnetlib/Xsharp/
And then they have written in C# Widgets for X, which look like the MS ones.
Oh, and here are some samples, if you want to write some apps in XSharp:
http://savannah.gnu.org/cgi-bin/viewcvs/dotgnu-pnet/pnetlib/samples…
Does anybody know how mature is the Database handling with mono?
“Does anybody know how mature is the Database handling with mono?”
Its pretty much the same as in .net itself. I recently set up mono to work with mysql and it was very very easy. I downloaded the mysql c# library intalled it and added the code. That was it.
Wow so they did do the xwindows to c# binding thing. Hmmmm. Interesting. I have alot of respect for the mono project but I dont run gnome with my distro and so I havent been able to play around with c# windowing which has bummed me out. I looked at the qt# project and thats dead. But I started thinking how is it that open office and mozilla work under both enviromments and why cant someone make a bridge to that.
Thanks for the link.
The Mono C# compiler who is written in C# is also more
mature and feature complete, in the words of Marcus:
“The DotGNU C# compiler implements something which looks like
C# but is not C#”. They lack definite assignment support
and in general are lagging a lot in terms of polish and
code correctness.
Their feature used to be speed, but with 0.31, the mono
C# compiler is faster for large programs than cscc.
If you compare Mono to DotGNU, Mono have the most advantages, I think.
But there is one big disadvantage of Mono: The dependences.
If you want to install DotGNU (in binary or in sourcecode) you don’t need additional libraries.
But if you want to install Mono (And I mean only the mono-runtime with C#-compiler and basical libraries. No Gtk#, no Winforms, etc), you need glib. And glib needs some other libraries, which must been installed.
And all the libraries blow up Mono. And then there existing KDE-people, who don’t want install glib. And all other non-GTK+ people (that are all of the other platforms like MacOS X, BeOS, Syllable, etc) don’t want too much additional libraries, too.
I know, that it is for Miguel and the other one, easier to write something with GObjects. But I think, that it would be better, if the fundamental core of Mono is only written in ANSI C with assembler extensions and other extensions, which are really needed. No additional libraries or so.
Rulf
Additionally, building DotGNU from source on either windows or linux is trivial. Just cvs checkout treecc, pnet, pnetlib and then ./configure, make install them. With mono you have to bootstrap your way into a full setup from source and the way things are supposed to get built tends to change around quite a bit. Mono has ties to Gnome so its no surprise that they leverage Gnome libraries. Building mono from scratch on a mostly KDE system is going to be a task and a half because of the dependencies explosion, but there are rpms and debs out there for those that don’t want the fuss.
DotGNU’s Windows Forms is interesting, but I just hope there is going to be a way to get it themable at some point.
I thought glib is a very stand alone library. It might need X, but then, that is the target of the development on *nix anyway. Other than than, glib is not huge, is very convenient, and there is no reason to reinvent the wheel if glib does the job. It also helps the quality of the dependencies because now we have a large company (Novell) that is interested in keeping them modern and well developed.
People who do not want to install glib because it was developed by people affiliated with GNOME and because it was developed in C are not to be listened to anyway. I do not see what the problem is. glib is only 2.5 MB in source form, so size consideration are not realy at issue. If you are going to pass up a very good technology like mono because of zealotry about KDE/GNOME or C/C++, then you will get left in the past and no one will miss you.
How many members are on each project? I believe there are 5 or so on mono. How many on dotgnu?
“Building mono from scratch on a mostly KDE system is going to be a task and a half because of the dependencies explosion, but there are rpms and debs out there for those that don’t want the fuss”
Can you post some links? Thanks.
Installing on MacOS, which should not be any harder
than anything else requires:
* pkg-config
* glib
* icu (optional)
* gc (latest beta, this is a MacOS ismm)
* mono
Not really a very large number of dependencies, on Linux
the situation is even simpler.
There is no X dependency of any kind.
5 developers on Mono? It’s more like 60!
But it is a big thing, as a general rule Mac owners are not build from source types, do will not have glib, pkg-config, etc on their Macs so this will have to be packaged for them. As for no dependencies on X, does winelib have a Carbon port, or are you not counting SWF.
Is GTK# preferred, oh that out then until there’s a native port of GTK, which well looks unlikely considering the lack of interest in the GTK-Aqua and GTK-OSX projects. GTK of course would throw in another stack of dependencies (pango et al).
Sorry for the rantiness.
Dave
It seems that they switched from the boehm conservative garbage collector to the intel ORP garbage collector. I never heard of this one, but it seems that it is a precise generational garbage collector.
This is really good news.
Well, SWF can not any production application today, so
am not even counting it.
When its ready, we will port Wine to MacOS, it was done
a few months ago, we need to revisit the patch.
There are very little dependencies today for MacOS and as its users do not want to deal with any such dependencies, Mono will sport a nice MacOS X installer soon which will take care of that. On Linux there are already RPM for most distros as well as a Red Carpet channel. On Windows, the project has had installers for a while too.
On all platforms Mono is now becoming much more user friendly and not just to developers contributing to Mono but to developers wanting to develop applications on Linux Desktops as well as cross platform applications. It’s also exciting to see MonoDevelop making such great progress with source level debugging and documentation browsing.
My two centimes.
I noticed that the 0.30 release of Mono on Windows also had a download of Gtk# available, while the 0.31 section doesn’t. Is Gtk# integrated into the 0.31 installer, or will the prior version work with 0.31, or is there a new Gtk# download pending or what? Perhaps the previous version’s Windows.Forms were based on Gtk#, hence the libs, but the new version’s changes make Gtk# unnecessary on Windows?
While I’m at it, does Gtk# on Windows hook into the native controls and theming engine of Windows XP and such?
Answering some of my own questions, after embarassingly simple web search
Gtk# for Windows 0.17 is available for download from the Gtk# SourceForge project site: http://sourceforge.net/project/showfiles.php?group_id=40240
It appears to require a seperate install of GTK+ for Windows, available from another SourceForge site: http://sourceforge.net/project/showfiles.php?group_id=71914
I still don’t know yet whether GTK+ on Windows uses the Windows theming (or even fakes it). Time to download, install and determine that next.
And then there existing KDE-people, who don’t want install glib.
Most of linux applications are use GTK and glib. Without this you can’t use many linux applications, like gimp, bluefish, evolution,etc. And IMHO in long term KDE and Qt will disappear, because of Qt license.
There are alternatives to every GNOME/GTK program out there (well, except the Gimp, but there’s GTK-QT). I’m no KDE fan but I know many that can live happily without using any GTK application. That said, I believe that GTK applications are usually of a better quality but that’s probably just me…
I still don’t know yet whether GTK+ on Windows uses the Windows theming (or even fakes it). Time to download, install and determine that next.
http://gtk-wimp.sourceforge.net/
It would be very nice to have Python in Mono.
Are there any plans for this?
Does anyone know if MonoDevelop works under windows?