Mono 1.1.16 is now released. The inlining optimization is now turned on as well as a number of other small optimizations that enhance inlining and the results are excellent and ASP.NET/Windows.Forms have seen a big step forward.
Mono 1.1.16 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
It’s good to hear non-MS .net implementation progress, mono seems to be the leader (versus dotgnu) at the moment. I was amazed that I could really compile and run console-based VB programs on Macs – but the window system seems to be tangled up at the moment. I’ve seen lots of screenshots, but my system loses it’s mind (as do I) when I try.
I’ve been trying for almost three months (not continuously, mind you) to get monodevelop to install on 10.4. Fink is all sorts of confused and X11 aparently isn’t X11-enough. I didn’t even know Apple used their own X-window server – until I tried to install monodevelop. If anyone else has gotten this to compile and run: PLEASE let me know how..
.. and their website has sadly not helped. There is an article on doing this – but I need something step-by-step, the page is a wiki entry and seems to be more of ‘requirements’ not ‘installation procedures’.
http://www.monodevelop.org/Running_On_OSX
…but that’s monodevelop – the article’s about mono.
mono makes me happy.
still seems odd to me that mono works better on windows than on linux. kinda defeats the point of having a non-visualstudio .net system.
has anyone done fedora 5 rpm’s yet? even the novellforge repo is incomplete (monodevelop won’t install).
nice to see that its as up-to-date as vs2005 as far as ironpython goes.
replying to myself, but i’ve just installed monodevelop using the following .repo
[mono-latest]
name=Mono for fedora-5-i386 (latest)
baseurl=http://go-mono.com/download-latest/fedora-5-i386/
enabled=1
gpgcheck=0
windows.forms now works!
There’s an extra package under review.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178904
And the source RPM:
http://fedorared.org/~john/review/monodevelop-0.11-10.src.rpm
Just issue rpmbuild -bb mono*.src.rpm and it should build just fine. (If not, post a message in the link above)
If all goes well, FC5 packages should be just around the corner.
Cheers,
Lost and alone
Pain has become constant
Every day becomes more difficult
Every breath more strained
Struggling to move on
Yet every road I take dead ends
Down on my hands and knees I pray for and end
Yet which end do I desire
Just stop this struggle
End the torture of my heart
Let me mourn or celebrate
Then let me move on
They dangle my children in front of me
I reach out my arms
Stumbling forward to reach them
A starving donkey chasing the carrot
Does the donkey know it can not reach it?
No matter how hard it works
No matter how fast it goes
The carrot is always just out of reach
Yet it moves on praying to eat that carrot
Staving and weakening – the dangling carrot it’s only hope
Stumbling and falling – it picks itself up again
Struggling on forever – until it falls and never stands again
Mono is the donkey chasing the .net carot wich Microsoft *holds*
What is the Mono logo meant to represent? I looked in the project faq, but couldn´t find any clue.
If it is supposed to be a monkey, it must be a species unfamiliar to me.
it’s a monkey in profile
I guess it’s from old Ximian days, nothing to do with .NET probably 😉
I’ve heard that it’s not just a monkey’s profile – but a shadow-hand-puppet of a monkey’s profile…
…this may not actually be true – my friend is something of an idiot.
“Monkey see, monkey do.”
– I believe this is the theme that went along with the icon.
Mono = monkey in spanish:
http://builder.com.com/5100-6373-1044968.html
I’m a big fan of the concept of “embrace and extend/refine”. This, in practice, accelerates human development, because 1) people don’t continually re-invent the wheel, and 2) people can “stand on the shoulders of giants” and add their own ideas to a solid base.
I’ve always looked at Microsoft’s .Net as “embrace and extend/refine” of Java. I also look at Mono as “embrace and extend/refine” of .Net. Then I look at Java 5 as an “embrace and extend/refine” of .Net/Mono.
In the case of .Net (and C# in particular), MS took a lot of the great ideas in Java and refined them and extended them. I find the C# syntax to be a bit cleaner than Java. Also, the runtime and JIT seem to be a bit less heavy. And they added annotations and generics, as well as “unsafe” code. And Windows.Forms are essentially .Net wrappers around Win32/MFC.
In the case of Mono, they embraced and extended .Net by making it cross platform, and adding GTK# support, and (in my experience) made it even more efficient.
And, alas, it all goes full circle. Java has embraced and extended some of the concepts of of .Net/Mono, most notably annotations, generics, and SWT (which wraps around Win32, Apple Aqua, and GTK).
And all that said, I’m finding I’m liking Mono more and more. MonoDevelop has evolved into a damn fine IDE, and C# is a really nice language to work with, and Basic support is good, as is Java and Python and Boo, and finally there are really good apps that use Mono/GTK# (Muine, Blam, F-Spot, Tomboy, Beagle, SkyNet).
…why do people use Java? .NET? Mono?
At first, I really liked the idea of managed code and well structured/easy to extend libraries. Swing, SWT, Windows Forms, GTK#, I tried em all.
But god, it comes at a price which is way too expensive!
About 10 years ago, I remember making programs that ran quite fast on 486/early pentium processors. That was in the Windows 95 days. I also remember using programs that ran quite fast (complete office suites, html editors, media players, games, etc). All these programs had decent GUIs that were sometimes even richer than those we find in today’s programs.
Today, we have very powerful machines with alot of RAM. Today’s hardware perform much better than before. Huge difference I must say. But on the software side, well functionality-wise, I don’t see much improvements. However, programs are most of the time way slower than programs from 10 years ago. It’s nonsense.
People say “managed code is much more secure”, “developement is much faster”, “reuse, reuse, reuse!”, etc. But it really doesn’t matter for the end user. The people who use my software don’t care much about that. They just want things to work and to be quite fast.
In 2002/2003, I rewrote an aging MFC program using .NET/WinForms (I got caught in the .NET buzz). I failed to convince people to use the new version. Processing was slower than before, the GUI was sometimes unresponsitive, etc. I stepped back and decided to wait before making another step.
I finally realized that people were right. How? Just by using something like Visual Studio 2005. It’s scary.
Thus said, while I understand all the advantages of managed code, proper design patterns, etc, it’s just theorical. At the end, it doesnt matter much. What matters is the whole user experience. Sometimes it takes 3-4months to write a program that will be used intensively for 10 years. This is what you should consider.
Managed code can be as fast or faster than unmanaged code depending on the scenario, though there are some costs associated with the additional benefits it offers, usually in initialization and overhead. There are ways to mitigate these costs, and they usually even out for non-trivial applications.
Concerning UI responsiveness, did your application perform all of its work on the UI thread? If so, the UI will block as long as some other operation is being performed, resulting in an unresponsive UI. This is true for managed and unmanaged apps. Potentially long-running processes should be executed on a seperate thread. .NET 2.0 provides a BackgroundWorker object to make this easier. There are also application blocks provided by MS Patterns and Practices for previous versions of .NET. You can also implement this behavior manually.
Also, security can be a hassle sometimes, and the users will claim to not care, but they will care when they are actually affected.
Thus said, while I understand all the advantages of managed code, proper design patterns, etc, it’s just theorical. At the end, it doesnt matter much. What matters is the whole user experience.
Agree. The convenience for the programmer must always come second to the experience for the user.
Edited 2006-07-09 12:06
I couldn’t agree with you more.
What matters is the end user experience, not the convenience of garbage collection, or increased developer productivity, or “pure OOP” design, or whatever.
It seems that for corporate or internal apps, Java and .Net are kings. In this environment, users have to use what they’re told to, whether they think the interface is slow and clunky or not. And the productivity gains received when using a garbage collected, managed language is a big win, and there is no loss in usage. For corporate, internal apps, the audience is captive.
But in commercial software, especially shrink wrapped software, C and C++ are kings, by a long margin. The same holds true for a lot of open source software. In this arena, the audience is not captive, and will not tolerate slow, clunky, memory hogging, sometimes alien looking applications. Here, the increased performance and less memory usage of the end product make it worthwhile, and indeed necessary, to sacrifice the programmer convenience and increased productivity of applications built on managed code.
And, even though I was singing the praises of Mono (and Java and .Net) in my previous post, that was from my developer perspective. Those are nice tools to work with.
However, as just a pure end user, I always, I mean always prefer an application that has been compiled to native machine code (C/C++), that is, when I’m aware of what the app was written in. In every case, a C/C++ app always out performs, and delivers a better overall user experience, and uses way less memory, then an equivelent Java/.Net app. There are no exceptions, not in my experience.
Edited 2006-07-07 19:44
However, as just a pure end user, I always, I mean always prefer an application that has been compiled to native machine code (C/C++), that is, when I’m aware of what the app was written in.
All .NET code is compiled to native machine code before execution. For max compatibility, compilation happens either at install or runtime (defaut). You can also pre-compile seperate binaries for each platform like in C/C++ by using NGen or similar tools.