2006-10-20: Coding Style
A compiler is a thing that takes some input, processes it in some way, and drops out some output. It normally also outputs information to the terminal for the developer. It’s not that difficult to understand and there are hundreds of compilers out there that work this way. Well known, mainly in relation to programming and compiling is Emacs, a kind of meta operating system which can be used to, among other things, edit files.
Now the developers of Mono have decided to make the Mono compiler (g)mcs “Emacs Aware” (M. d. Icaza). This means that the compiler adapts its textual output to the environment it is running in; better: it adapts solely to Emacs by suppressing information. IMHO this is bad style. It is the editor’s, console’s, whatever’s responsibility to correctly display the output of programs executed by and in it. By adapting the programs’ behavior instead of letting the displaying process handle output rendering, things will get even worse.
Finally saying “is not a bug, it’s a feature” (M. d. Icaza) really makes me believe that the Mono framework will never improve. It might thus keep its indeterministic and somewhat unreliable behavior.
November 10th, 2006 at 14:52
> … really makes me believe that the Mono framework will never improve.
What the heck do you want to say with that weird sentence?
Miguel clearly explained why the hack is part of mcs.
Just unset the EMACS env var in the makefile or build script
and you’ll receive a great improvement.
November 10th, 2006 at 20:53
Well, let’s cool down a bit. I don’t think this sentence is too weird, it expresses my opinion. If you do not agree, it’s ok for me.
Nevertheless, from my point of view this is bad style (yes, I’m talking about the Mono thing) and I’m not the only one who thinks so. My last bug report is another example of bad style. Parsing a user-provided string the wrong way is the most obvious vulnerability in almost every program. Mono is a really cool piece of software, they (Miguel et. al.) did a good job but it is, in my opinion, rather pre-beta software. There are and were so many missing things, buggy programs, or unfinished implementations.
Even if it is open source (and I know, *nobody* is allowd to criticize open source software), I take the liberty of having my own opinion. It’s not my problem if you feel attacked by me or my statement.
A compiler is a compiler. It is responsible for translating things into other things, maybe with some non-linear transformations in-between. If some editor or whatever is not capable of parsing the output a compiler produces, than take some script, wrap it around the compiler, and let it transform the output. That’s far less weird.
So long, I’m hungry now.
November 10th, 2006 at 22:14
I’m accidentally the reviewer of your bug report ;-)
I’m not against criticisms. I’m against nitpicking and pointless blogging.
If you’ve found so many bugs, where are your bug reports? Why
don’t you make them public where they belong to: in Mono’s Bugzilla.
Of course there are many classes not implemented: The whole
2.0 profile has missing pieces. WinForms 1.1 has just been finished and
it has for sure some issues. So *parts* of Mono are really pre-beta,
but this isn’t true for mcs, the runtime and the 1.1 profile.
November 10th, 2006 at 22:45
I agree, mcs and gmcs (well, ok, only gmcs as of 1.1.18) are really usable. We are using Mono for a quite large project, so I really know that it is usable for most appliances.
I’ve filed some bug reports in the last year (79696, 77747 for Mono, then one or two for gtk-sharp). But hey, I’ve a job and do not have the time to constantly doing such costly things. I actually can’t always dig for the sources of an error. Maybe you’ve the time to care about all that, I don’t.
Finally, these bug reports are in the public. They’ve been filed to bugzilla — by other users.
Again: I like Mono, really. But I don’t think it’s stable. That’s all. That’s no bad thing. If you do think it is, it’s ok. I’ll continue using it and write hooks around things that do not work as expected.
November 11th, 2006 at 18:17
The example about parsing user input is a valid one, but it happens in an explicitly unsupported feature of Mono, from the manual page:
MONO_PATH
Provides a search path to the runtime where to look for library files. This is a tool convenient for debugging applications, but should not be used by deployed applications as it breaks the assembly loader in subtle ways.
So you were using an unsupported feature, a debugging tool, and furthermore, the documentation explicitly states that it should have a list of directories. An empty directory is not a list of directories.
Miguel.
November 11th, 2006 at 18:27
That’s correct and I was not aware of this fact, I must admit. The reason why I was irritated about the (for me) unexpected behavior is: it is perfect for development if you don’t want to copy files around or want to separate libraries and binaries.
Well, and since our software will never reach some stable release state, there will probably never be a fixed directory structure.
So it’s great that it is fixed now.