Linked by Eugenia Loli on Fri 7th Jul 2006 03:15 UTC
Mono Project 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.
Order by: Score:
monodevelop on OS X
by JacobMunoz on Fri 7th Jul 2006 04:42 UTC
JacobMunoz
Member since:
2006-03-17

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.

Reply Score: 2

linux support
by simo on Fri 7th Jul 2006 07:27 UTC
simo
Member since:
2006-01-09

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.

Reply Score: 2

RE: linux support
by simo on Fri 7th Jul 2006 08:19 UTC in reply to "linux support"
simo Member since:
2006-01-09

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!

Reply Score: 3

RE: linux support
by gilboa on Sun 9th Jul 2006 09:16 UTC in reply to "linux support"
gilboa Member since:
2005-07-06

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,

Reply Score: 1

v A donkey chasing the carot
by agnus on Fri 7th Jul 2006 08:10 UTC
Offtopic, but...
by wowtip on Fri 7th Jul 2006 11:40 UTC
wowtip
Member since:
2005-07-14

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. ;)

Reply Score: 1

RE: Offtopic, but...
by Matzon on Fri 7th Jul 2006 12:34 UTC in reply to "Offtopic, but..."
Matzon Member since:
2005-07-06

it's a monkey in profile

Reply Score: 1

RE: Offtopic, but...
by Brmbolec on Fri 7th Jul 2006 12:36 UTC in reply to "Offtopic, but..."
Brmbolec Member since:
2005-07-23

I guess it's from old Ximian days, nothing to do with .NET probably ;-)

Reply Score: 1

RE: Offtopic, but...
by JacobMunoz on Fri 7th Jul 2006 14:59 UTC in reply to "Offtopic, but..."
JacobMunoz Member since:
2006-03-17

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.

Reply Score: 1

RE: Offtopic, but...
by hustomte on Fri 7th Jul 2006 12:49 UTC
hustomte
Member since:
2006-01-07
Embrace and extend, refine
by JeffS on Fri 7th Jul 2006 17:45 UTC
JeffS
Member since:
2005-07-12

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).

Reply Score: 1

One thing I don't understand
by rx182 on Fri 7th Jul 2006 19:00 UTC
rx182
Member since:
2005-07-08

...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.

Reply Score: 5

RE: One thing I don't understand
by n4cer on Fri 7th Jul 2006 20:10 UTC in reply to "One thing I don't understand"
n4cer Member since:
2005-07-06

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.

Reply Score: 1

RE: One thing I don't understand
by segedunum on Sun 9th Jul 2006 12:06 UTC in reply to "One thing I don't understand"
segedunum Member since:
2005-07-06

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

Reply Score: 1

RE: One thing I don't understand
by JeffS on Fri 7th Jul 2006 19:38 UTC
JeffS
Member since:
2005-07-12

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

Reply Score: 2

n4cer Member since:
2005-07-06

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.

Reply Score: 1