Mono Woes

And finally we get to what is wrong with Mono. Aside from the tool-chain and various other issues, I found several problems with the framework itself.

First, and probably the most annoying thing is that when one of my apps crashes and the stack trace is printed, the mono framework seems to go AWOL. Running the application again produces nothing. It just immediately returns to the prompt with no error or any suggestion as to why. After waiting for appoximately two minutes Mono will start to work again. This is a major impediment to the edit/compile/debug cycle and happens consistently.

Another major issue is the Console.Readline() only intermittently echos the character you typed back to the screen. You never know if you have typed what you think you typed. Did the character not appear because you did not hit the key hard enough or because it did not get echoed back?

Finally, I also found that long running programs regularly exit without any errors. Just run a simple GUI app from the console and return a few hours later. The app will be closed and there will be nothing on stdout to suggest why.

Poor development tools are something that I can work around, but a frame*work* that does not work is something I cannot tolerate.

Aliases in Screen

What a headache!
GNU Screen on Cygwin was not getting my aliases. Searching all over the internet yields that screen runs ~/.bashrc since it is not a “login shell”. This was not happening. Everybody says to add shell -$SHELL to run an interactive shell and that will source your ~/.bash_profile which will usually source ~/.bashrc (as is my case). Now this works, but it does not explain why my ~/.bashrc is not running without shell -$SHELL. What does the documentation say?

shell command
Set the command to be used to create a new shell. This overrides the value of the environment variable $SHELL.

So what is my $SHELL variable set to?

$ echo $SHELL
/bin/bash

But if I run /bin/bash and run alias, all my aliases are there. Clearly screen is not doing what it says. So is that it? The documentation is just plain wrong? When I add shell $SHELL (notice the absence of the ‘-‘) my aliases do show up. But if shell _command_ “overrides the value of the environment variable $SHELL” wouldn’t shell $SHELL do nothing? Yet it does. It fixes my problem. Screen runs ~/.bashrc where it otherwise does not.
In summary:

• with nothing in ~/.screenrc: neither ~/.bashrc nor ~/.bash_profile run
• shell $SHELL: only ~/.bashrc is run (non-login shell)
• shell -$SHELL: ~/.bash_profile is run, which typically also sources ~/.bashrc (login shell)
• the GNU screen documentation is wrong. Or at least, unclear.

Qyoto

And on with the saga…
Finally, I started to work with Qyoto (.NET Qt Bindings). The packages on Ubuntu did not work and I had to hack for a long time to even get something to build. I was pretty happy when I did, but my excitement was short lived. Again I could not generate Boo code and had to settle for C#. This time it was a little worse though. See, to use Qyoto you have to edit the UI in QtDesigner, save your file, run uics to generate the C# code, then go back to MonoDevelop and reload the file. Build and run and hope the debugger attaches and hope the app does not suddenly exit. Rinse and repeat…
Qt is much nicer than GTK, but it has the same problem that it does not integrate with the .Net data structures. Again, no databinding with UI controls, etc… With all the problems with MonoDevelop, Mono, the and the UI I finally gave up.

Mono and GTK#

So, Mono…
So the next problems I encountered were the interface problems. WinForms on Linux is ugly and the DataGrid doesn’t work. So I ported my app to GTK#. Cringe. GTK is ugly both in its visual display and its programmatic interface. I simply used it because there was a visual designer in MonoDevelop. However, that choice forced me to have a mix of C# and Boo since the designer does not generate Boo code.
Unfortunately, GTK# is a bastardization that mocks the clean design of the .NET Framework. It is neither object-oriented nor does it integrate with the natural data structures. Want to bind a DataSet to a UI control? Then use Windows and forget about GTK#.

MonoDevelop

So Mono…
Several years ago I ported a Boo WinForms .NET application to Linux using Mono. I started using MonoDevelop 1.0. What an ordeal the whole thing turned out to be. Porting was easy. There was very little that didn’t work in Mono. But it all went downhill from there.
First MonoDevelop was buggy and hard to use. There was no integrated debugger. Secondly, it used a proprietary project format so I had to maintain separate files for Linux and Windows. Eventually they ported MonoDevelop to Windows, but didn’t port the Boo Addin so I still had to maintain two sets of project files. They integrated the debugger but broke the Boo Addin on Linux (had to submit my own patch and use a locally compiled copy for a while). Then the code completion stopped working. Some of the time the debugger just does not attach and about half of the time my app would compile, run and then mysteriously close with no error.
Finally I did a dist-upgrade on Ubuntu and got the new MonoDevelop 2.6. I was sure hoping that some of my problems would be solved. Ha! That’s where I hit the end of the road. The new version came with no Boo Addin. I could no longer compile my project from the IDE. I looked in the Addin repository, but there is nothing there. They must have changed the Addin interface from 2.4 and apparently none of the Addins got ported.
Wait… I did not even talk about Mono! Maybe next post…

New Programming Language

I am looking for a new (or old) general purpose programming language. I would like the language to have a good GUI library, work well for web development, have a good IDE (particularly a GUI designer), (and one more thing…).
I have been a C# developer for 10 years and it satisfies my first three requirements. I have also been programming in Boo for almost six years. With Sharpdevelop it too satisfies my first three.
So, what’s the problem? Linux. I mainly use Linux now and I would like something that works well on Linux, but also Windows as I often need my tools on both platforms.
“What about Mono?” you ask. That gets its own post…