Subscribe: To Infinity and Beyond
http://rolfkvinge.blogspot.com/feeds/posts/default
Added By: Feedage Forager Feedage Grade B rated
Language: English
Tags:
app  case  cecil  code  compiler  crash report  crash  file  monodevelop  monotouch dialog  monotouch  system  vbnc  write 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: To Infinity and Beyond

To Infinity and Beyond





Updated: 2014-10-07T03:22:27.285+01:00

 



A common SQLite pitfall

2013-07-18T17:47:48.793+01:00

This is something I've seen happen to several of our customers, and it can be quite difficult to track down if you don't know how.

Make sure you dispose commands before closing their connections!

The code I've seen typically goes like this:

protected void ExecuteNonQuery (string cmd)
{
    using (var c = connection.CreateCommand ()) {
        c.CommandText = cmd;
        connection.Open ();
        c.ExecuteNonQuery ();
        connection.Close ();
    }
}


This is broken. Here the connection is closed before the command is disposed. Unfortunately SQLite doesn't tell you anything when this happens, but it will leak file handles (the connection will in fact not be closed), eventually leading to random errors somewhere else when you run out of file handles.

Random errors are of course not fun, but fortunately this is very easy to debug if you just know how: in Xamarin Studio open the Run->Exceptions menu and add SqliteExceptions to the list of exceptions to break on:

(image)

Now run your app. You'll break here if your code is broken:

(image)

and now it's just a matter of walking up the call stack until you find out where the SQLiteConnection.Close is called:

(image)

And you should be able to spot the bug and fix it easily:

protected void ExecuteNonQuery (string cmd)
{
    using (var c = connection.CreateCommand ()) {
        c.CommandText = cmd;
        connection.Open ();
        c.ExecuteNonQuery ();
    }
    connection.Close ();
}


As a final note I'd like to mention that breaking on all exceptions (configure Xamarin Studio to break on System.Exception) can be a valuable debugging tool when weird things are happening - when I first ran into this issue I spent several frustrating hours trying to track it down without success. Out of a hunch I decided to break on all exceptions, and then it took me only a couple of minutes to understand what was going on and fix the code.



Valgrind

2012-09-21T10:47:22.915+01:00

Starting with MonoTouch 5.4 it is possible to use Valgrind on a MonoTouch project. In some cases Valgrind is invaluable in finding strange crashes, in particular when freed memory is accessed.

This is what you need to do:

Download latest Valgrind (3.7.0 as of this writing). Extract somewhere, and compile:

./configure --enable-only32bit --prefix=/usr/local
make
sudo make install

Now open the project you want to valgrind, and set the VALGRIND environment variable to the command to execute to use valgrind:


Run (not debug) your project. You will see this in the Application Output:


In particular read the second line, you need to do exactly as it says: use gdb to attach to the app and then detach again. Once you've done this the app should start up (slowly, Valgrind makes your app a lot slower). Quite much output is printed to the Application Output, most of it is just noise though.

The messages you should be looking for (if you're trying to figure out why your app is crashing), are:

  • Invalid read of size X
  • Invalid write of size X

You can try to track down the reason for the following messages if you're just trying to find out why the app behaves strangely. Just have in mind that most of these messages are harmless, it can be due to "smart" optimizations in the code or by the compiler which valgrind doesn't understand.

  • Conditional jump or move depends on uninitialised value(s)
  • Use of uninitialised value of size X

For a thorough explanation of all these messages from Valgrind you should read their documentation.



I can't debug on device!

2012-08-02T22:10:44.156+01:00

My app won't connect to MonoDevelop when debugging on device, what do I do?Here are a few tips to track down this particular failure: Switch between USB and WiFi mode. Just go to MonoDevelop's Preferences and toggle this check box: Enable diagnostic output when the app tries to connect to MonoDevelop. This is done by adding "-v -v -v" to the additional mtouch arguments in your project's options:Now rebuild your app, and you should get more information on what's happening in the iOS Device Log:MonoTouch: Added IP to look for MonoDevelop: 123.123.123.123MonoTouch: MonoDevelop Port: 10000 Transport: USBMonoTouch: Successfully received USB connection from MonoDevelop on port 10000, fd: 5MonoTouch: Processing: 'connect output'MonoTouch: Successfully received USB connection from MonoDevelop on port 10000, fd: 6MonoTouch: Processing: 'start debugger: sdb'MonoTouch: Debugger loaded with custom transport (fd: 6)MonoTouch: Successfully received USB connection from MonoDevelop on port 10000, fd: 7MonoTouch: Processing: 'start profiler: no'Some of this information should also (but probably won't since that's the problem you're trying to solve in the first place) show up in MonoDevelop's Application Output pad (everything after the 'connect output' line, since that's when the app's standard output is redirected to MonoDevelop):Please ensure your device is connected...Connected to: Rolf Bjarne Kvinge’s iPadKilled the process 'instruments' with pid 1287.Launching /private/var/mobile/Applications/06007ED7-84C1-4D67-A893-7C04CE477F15/instruments.app -debugtrack -monodevelop-port 10000 -connection-mode usbMonoTouch: Successfully received USB connection from MonoDevelop on port 10000, fd: 6MonoTouch: Processing: 'start debugger: sdb'MonoTouch: Debugger loaded with custom transport (fd: 6)MonoTouch: Successfully received USB connection from MonoDevelop on port 10000, fd: 7MonoTouch: Processing: 'start profiler: no'Loaded assembly: /private/var/mobile/Applications/06007ED7-84C1-4D67-A893-7C04CE477F15/instruments.app/Mono.Security.dllLoaded assembly: /private/var/mobile/Applications/06007ED7-84C1-4D67-A893-7C04CE477F15/instruments.app/System.dllLoaded assembly: /private/var/mobile/Applications/06007ED7-84C1-4D67-A893-7C04CE477F15/instruments.app/System.Core.dllLoaded assembly: /private/var/mobile/Applications/06007ED7-84C1-4D67-A893-7C04CE477F15/instruments.app/monotouch.dllLoaded assembly: /private/var/mobile/Applications/06007ED7-84C1-4D67-A893-7C04CE477F15/instruments.app/MonoTouch.Dialog-1.dllLoaded assembly: /private/var/mobile/Applications/06007ED7-84C1-4D67-A893-7C04CE477F15/instruments.app/instruments.exeThread started: FinalizerThis time everything connected fine, but if error messages may be printed to the iOS Device Log if anything goes wrong. Restart your device and machine. Last solution: file a bug or ask on the MonoTouch mailing list. Please remember to include the information you got from the previous steps, that's the first thing anybody will ask you anyway.[...]



MonoTouch debugging tips

2012-08-03T14:39:55.138+01:00

This is mostly for myself so these ideas aren't lost in bugzilla comments or GMail's bottomless mail pit.

How to create a crash report when the app is hung


Update

There is a much easier way to do this. All iOS versions and devices include a way to force quit an application:


  • Hold down the On/Off button until "slide to power off" appears.
  • Release the On/Off button.
  • Hold down the Home button.
  • After a few seconds the app will be terminated, and a crash report will be generated (the app's exception code will be 0xdeadfa11).


This snippet will cause the app to generate a crash report after 30 seconds (feel free to modify the timeout to ensure it only crashes after you've managed to hang the app).


Once the app has crashed, you should get a crash report in Xcode, hopefully with stack traces giving some clues as to what the app was trying to do when it hung. If you can't make heads and tails of the crash report, you should file a bug (remember to attach the crash report!).


Just replace the Application class in Main.cs with this (if you've made modifications to the Main.cs file yourself, you'll have to modify this code accordingly).


public class Application {
    [System.Runtime.InteropServices.DllImport ("libc")]
    static extern int strlen (IntPtr zero);
    static unsafe void Tick ()
    {
        int zero = 0;
        int* z = &zero;
        // This is so that strlen is initialized
        // (so no/fewer locks are required later)
        strlen ((IntPtr) z);
        // The sleep interval can be modified to sleep
        // until you're sure the app has hung.
        System.Threading.Thread.Sleep (30000);
        // Create a crash report
        strlen (IntPtr.Zero);
    }

    static void Main (string[] args)
    {
        new System.Threading.Thread (Tick).Start ();
        UIApplication.Main (args, null, "AppDelegate");
    }
}



Next tip will go here next time I remember something I don't want to forget again




Native crashes in MonoTouch

2012-04-14T01:11:45.964+01:00

If you use MonoTouch a bit, you will once in a while run into native crashes. In a perfect world you'd never see such a horrible thing, but unfortunately the world isn't perfect, and in real life there are several ways you can end up crashing your app. Usual debugging techniques with MonoDevelop will not work, but with some ingenuity you can figure out what's going on. And you will catch a glimpse of how the world is for those poor guys who can't develop in C#!Now, how do you find out what happened? You need as much information as possible, and information related to a native crash is twofold: Crash report.Console output.Where you can find each differs depends on whether you're running in the iOS simulator or on an iOS device.You're running in the iOS simulator.In this case, the console is the system console on your Mac. You can find the Console application in Applications -> Utilities -> Console. This is how it looks like:Now let's see what happens if you crash in the simulator. You will get this dialog:and if you click the Report button, you'll see the crash report:The same crash report is also available in the Console, in case you dismissed the dialog:You're running on an iOS device.In this case, you want Xcode's Organizer. Open Xcode, and go to the Window -> Organizer menu entry.Here you will find crash reports under the Device Logs node, and the obviously the console output will be under the Console node.Now what?Some times the information you found tells you exactly what happened.This is the case for an unhandled exception, in which case you'll see something like this in the console:13/04/12 4:28:54.101 PM CrashReporting: Unhandled Exception: System.Exception: Unhandled I am!  at CrashReporting.AppDelegate.UnhandledException () [0x00000] in /Users/rolf/Projects/CrashReporting/AppDelegate.cs:27   at MonoTouch.Dialog.StringElement.Selected (MonoTouch.Dialog.DialogViewController dvc, MonoTouch.UIKit.UITableView tableView, MonoTouch.Foundation.NSIndexPath indexPath) [0x0000b] in /mono/ios/MonoTouch.Dialog/MonoTouch.Dialog/Elements.cs:691   at MonoTouch.Dialog.DialogViewController.Selected (MonoTouch.Foundation.NSIndexPath indexPath) [0x00029] in /mono/ios/MonoTouch.Dialog/MonoTouch.Dialog/DialogViewController.cs:518   at MonoTouch.Dialog.DialogViewController+Source.RowSelected (MonoTouch.UIKit.UITableView tableView, MonoTouch.Foundation.NSIndexPath indexPath) [0x00019] in /mono/ios/MonoTouch.Dialog/MonoTouch.Dialog/DialogViewController.cs:364   at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr)  at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x0004c] in /mono/ios/monotouch/src/UIKit/UIApplication.cs:38   at CrashReporting.Application.Main (System.String[] args) [0x00000] in /Users/rolf/Projects/CrashReporting/Main.cs:17 in this case it's pretty obvious what happened. But this isn't often the case, usually the information is at best unfamiliar unless you already have experience debugging native crashes (and in some cases the crash happens way after the underlying cause, and any relevant information is long lost. When this happens you'll have to resort to more creative debugging techniques).I will write more blog posts describing some of the most common reasons for native crashes later, but in the mean time you have a few options to get help:The monotouch mailing list. There is also a forum interface to the mailing lists.File a bug.Contact Xamarin support.In all cases be sure to include all information you're able to gather, have in mind that even though the console output and crash reports may be greek to you, it may provide valuable information to somebody else.[...]



Hackweeek

2010-06-22T23:36:34.834+01:00

A couple of weeks ago we had another hackweek at Novell, and I continued working on getting vbnc to use cecil, as I did last time. With a big difference: I finished.

Yep, vbnc now uses Cecil to emit assemblies, the System.Reflection.Emit API is not used anymore. This makes it possible to fix a few long standing bugs, but most importantly (to me at least, the bugs are quite corner-case), a lot of unnecessary code has been deleted (~10k fewer lines of code in the compiler).

Another advantage is that it's now trivial to add support for compiling to different runtime versions - vbnc won't ever suffer from multiple personalities like the mono's C# compiler does: mcs/gmcs/smcs/dmcs...

Performance is still somewhat lower (bootstrapping the compiler itself is ~20% slower), but I haven't even looked at why (almost 3 years of working on a branch with fairly big changes has probably introduced some non-optimal code), so this is likely to change. Speed is also helped by using the new cecil/light which jbevain released recently.

And since I was done a day early and wanted to have a break from what I've been doing for the last 3 years with vbnc, I implemented the first VB 9 feature: ternary ifs!



ASX playlists

2009-10-15T13:59:35.179+01:00

If you tried watching Nasa TV in my last post with Silverlight, you'd find that it wouldn't work. And once again the problem is with the ASX file - to be more specific, the exact same problem I had to find a quick fix for last week for Moonlight.

The ASX file I linked to links to another ASX file. This second ASX file has a copyright symbol in it (©), and it stores it in the CP1252 code page (i.e. the binary value 0xA9 - this is an illegal value in utf8). Now it seems like Silverlight expects the file to be in utf8 [1], and it errors out if it isn't [2].

Unfortunately I can't link to the real mms link, Yahoo seems to uses some sort of authentication ensuring that you got the link from the ASX playlist.

I notified Yahoo using their contact form about this, asking them to fix their ASX output, now let's see what happens...

[1] When there are no byte-order markers at least
[2] Windows Media Player plays the ASX file just fine.



Nasa TV

2009-10-09T12:06:45.857+01:00

Interested by the NASA's crash landing on the moon, I wanted to watch the event live on my Linux machine. NASA has a few live TV channels, but none seemed to work on Linux. Until I discovered that they use ASX files to view the channels in Windows Media Player - turns out Silverlight (and by consequence Moonlight) also support ASX files. It was just a matter of creating a simple silverlight application referencing the ASX links. And that's what I did!

The bad thing is that our ASX support was a bit broken [1], and I had to fix it. This means that the currently released beta is not able to view the streams, you need to download brand new xpis from here: x86 / x64 (fair warning: these xpis are not tested at all, download at your own risk). Download, restart firefox and you should be able to watch the event live here.




(embed)



(video is scaled 200%, quality is kinda bad, but that's how it's transmitted from NASA)

[1] IMHO ASX files are broken by themselves - they look like xml files but aren't (they don't escape special characters that xml files have to), and they're encoded in the current encoding of the machine generating the ASX file, and in order to correctly parse the file you have to know which encoding that is (the file itself doesn't know).



Git & make

2009-06-10T10:05:33.324+01:00

One of the most annoying issues with git (which is actually a side-product of the fact that it's very easy to create/administer branches), is that switching branches will cause a lot of recompiles.

ccache helps some, but the real life-saver here is a script which doesn't come bundled with your installed git, but which you'll have to download the source code to get: git-new-workdir. It clones your repository to a different directory, with some symlink magic so that everything is shared except the index. It's the git equivalent a checkout of a svn repository to different directories, except that anything you do in any of the directories is available in all directories.



Git & Whitespace

2009-06-02T11:36:31.939+01:00

Recently I've been slowly transitioning from svn to git, though one of the mildly annoying differences is that git likes to colorize trailing whitespace in diffs with a very distracting color:

(image)

First try at fixing it: a tiny script to fix the file before committing.

Oops, that introduced a huge number of changes and would mess up history quite a bit, not the way to go.

So I added this to my ~/.gitconfig:


[core]
whitespace = -trailing-space


and now I can see the important changes in the diffs again.



Cecil Reloaded

2008-08-29T19:06:04.891+01:00

For our hack week here at Novell I continued hacking on making vbnc work with Cecil, and yesterday I reached the point where vbnc is able to compile itself using only Cecil (in my previous post I also said vbnc was able to bootstrap, but back then vbnc was still using SRE to do all the hard work, and Cecil just to write the final assembly to disk).

The initial performance problems are mostly gone, it's still not quite as fast as before, but there are also quite a few low-hanging fruit yet in that area. The first successful bootstrap yesterday took 40 seconds (compared to 12 seconds for the normal vbnc), and after a few optimizations I'm now down at 24 seconds. Almost all of that time was gained by allocating less strings, the first non-optimized version allocated ~1.4 GB of strings, and it's now down to 119 MB.

I'm also using a delay-loading mechanism to load data from referenced assemblies on-demand, this is not that visible when you compile a lot of code in one go, but it sure make a difference when compiling thousands of 15-20 line tests one by one.

I'm pretty confident I can get compilation time down to the 12 seconds I had before, especially given that Cecil hasn't been much optimized [1] (not actually used by compilers) before, while Mono's SRE implementation is known to be quite fast.

As a sidenote the actual amount of code in the compiler has decreased, from ~75k lines with the normal vbnc to ~68k for the cecil version.

[1] Sébastien Pouliot corrected me, cecil is used by some know compilers, and probably some unknown too. Some parts of Cecil has also been optimized already.



Cecil

2008-01-07T10:12:42.725+01:00

When I started writing vbnc, there weren't many options when it came to deciding which library to use to write the assemblies, only System.Reflection.Emit (SRE) was a real option.

SRE is very powerful, but unfortunately it has a few known and unknown limitations, mostly because it was never designed to be used by a full-fledged compiler.

Since I heard about Cecil, I've wanted to switch, and for the last months I've slowly added support for emitting assemblies with Cecil. Yesterday I reached a very important milestone: vbnc is able to bootstrap itself when using Cecil!

And I have to say that Cecil is A LOT easier to use than SRE, especially with generics.

There are still some problems for switching right away to only using Cecil, one of the biggest being that it's quite slow if you have many referenced assemblies (since Cecil loads everything from an assembly when loading it), though there is work in progress here.

Hopefully these issues will be solved shortly, and I can finally remove everything SRE-related, which has caused me quite a few head-aches!



VB 10

2007-10-07T16:47:17.497+01:00

Paul Vick asks what people want for VB 10.Here's my list:1) Inline and multiline comments (why not just copy C's /* */?)2) Option Overflow On/Off3) Option Warning 30XXX On/Off/Error3) The ability to apply Options to methods and/or blocks of code. Something like this maybe:Block Option Strict Off, Option Overflow On    'Some code hereEnd BlockI don't particularily like this syntax though, it's somewhat verbose.Another idea might be to add it to the attribute syntax:



Killer feature

2007-08-25T17:06:47.156+01:00

I see the light at the end of the tunnel.

Finally, the one single thing that has been annoying me for a loooong time with Opera, is about to be fixed

I just hope it's really, really killed now.



Oh Captain My Forms

2011-09-21T08:10:12.294+01:00

Today I finally committed support for one of the last remaining features in vbnc: the My namespace.It was easier than expected, hadn't it been for one little problem I had with a little close friend of mine: Reflection.Emit. I stumbled upon the single worst issue I had during last year's SoC, an issue it took me four days to work around. Note: work around, not fix.At that time I was able to work around it, since it was happening with the compiler, now this wasn't an option anymore, since it was the generated My code that was causing this.The problem is quite simple: anytime you have a generic type parameter on a method with a constraint, some other generic type parameter (on a completely unrelated type, not method) might fail emission (with a nice TypeLoadException, claiming that the constraint isn't met).The workaround I used last year is quite simple: remove all constraints, but as mentioned, that isn't an option anymore, so I started investigating. Unfortunately I lost the test case I cooked up last year, but it didn't take me long to recreate one this time. (Last year I had to start with the entire compiler and comment it out piece by piece...)Namespace OhCaptainIMixedUpTheTypeParameters    Class C1(Of Y)    End Class    Class C2(Of Z)        Inherits C1(Of Z)    End Class    Class C3        Sub M1(Of A As New)()        End Sub        Sub M2(Of B)()        End Sub    End ClassEnd NamespaceLooks quite innocuous, doesn't it?On MS this fails with: TypeLoadException: GenericArguments[0], 'B', on 'TypeParameter1.C1`1[A]' violates the constraint of type parameter 'A'.Now read the exception again and try to relate the A and B to the Z and Y.Of things you can try to make this compile includes changing the order (for example make C3 the first class in the file), or moving the methods to either C1 or C2.With this test case in hand I was quite certain it was a bug in Reflection.Emit, but I wasn't entirely sure either. So I added code to vbnc that dumps out how it emits everything in VB code, and got a nice 90-line source file that when compiled and run nicely reproduces the problem.The conclusion is that it's not a bug in vbnc, which is quite bad (I can't fix it). So everybody that wants to compile any VB code with generic type method parameters, be warned: if the compiler quits with a weird TypeLoadException, you know who to blame.The best part is that it Mono does not suffer from this bug, so if you want your project to compile no matter what, you'll have to use Mono :)PD: Already filed a bug with MS (link), and they seem to have confirmed it's a bug in Reflection.Emit.Update 01/07/2007: Fixed bug-link.Update 21/09/2011: Fixed html for VB code.[...]



Ain't Numeric

2007-04-16T18:22:54.995+01:00

Today I learned something: don't trust a compiler. I repeat: don't ever trust a compiler. It might be doing some magic behind your back.

A while ago I was assigned a bug, at first it looked really easy, but no matter what I tried I couldn't reproduce it, and I was positive the reporter was experiencing the problem. So I just left the bug standing there, and of course, eventually it hit me.

Quiz: If you compile the following source code, what will the IL look like?

Class AintNumeric
    Shared Sub Main
        Console.WriteLine(Microsoft.VisualBasic.Information.IsNumeric("0"))
    End Sub
End Class

The problem was that this printed "False" on Mono and "True" on MS. I compiled the code with vbnc, ran the code on Mono and it printed "True". I ran it on MS and it printed "True". I disassembled the program to see if the compiler was doing something wrong, and it wasn't. I put Console.WriteLines in MS.VB.Information.IsNumeric and they all confirmed that the function was working like it should. Just to check I compiled the program with vbc, ran it on MS and it printed "True".

You might have seen what I missed, but I'll tell you anyway: I didn't run the MS compiled program on Mono. My bad, the reported of the bug explicitly wrote that he did it, but I honestly didn't think it would change anything. vbnc was compiling everything correctly, wasn't it? 

Well no, and now here is the answer to the quiz:

.method public static void Main() cil managed {
    .entrypoint
    .maxstack 8
    L_0000: ldstr "0"
    L_0005: call bool     [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.Versioned::IsNumeric(object)
    L_000a: call void [mscorlib]System.Console::WriteLine(bool)
    L_000f: ret
}


The Microsoft VB8 compiler changes every method call to Microsoft.VisualBasic.Information.IsNumeric to Microsoft.VisualBasic.CompilerServices.Versioned.IsNumeric. And of course, that function was buggy in Mono...

Now you may think about it and find this is some really bad behaviour, but it's all because of backwards compatibility. When VB 8 came out they added support for unsigned types, which is the reason behind this: The old version of IsNumeric returns false for unsigned numeric types... and since that couldn't change it because it would break backwards compatibility, and they didn't want to add another function handling the new data types (and telling everybody they had to use the new funcion), they created some compiler magic.

And yes, the bug is fixed and vbnc does the same magic now.



How?

2007-03-27T11:37:33.883+01:00

A few people have been asking me how to learn how to write compilers.

After all, when I studied they didn't require me to write a compiler, but they didn't teach much about how to write them either, so how did I do it?

I went to the university library and got the Dragon Book(image) . But I didn't have time to read it before I had to return it, so I can't say I've actually read it though. Since I was still interested in writing a compiler when I had to return the book I figured I had to get some documentation that could stay with me (and at the time I didn't have the money to buy any book) so I yahooed a bit and found some resources about recursive descent compilers and printed it out (the original site I used was of course not wikipedia, but it doesn't seem to be available anymore, at least I can't find it - it was some university course in a South African university if I remember correctly).

So, armed with some a little bit of knowledge and much patience I started writing, and here I am today, with a compiler that's actually working on such weird architectures as ppc or s390x. 

It sounds easy and for me it wasn't really that hard (the head-aches I got a few times were usually because of the buggy and lacking Reflection.Emit from MS - this could probably have been avoided had Jb Evain written Cecil a few years earlier).

However I certainly didn't think I would get this far when I started!



Why?

2007-02-22T16:40:10.462+01:00

Why did I write a compiler?When I was studying computer programming at Universidad de Belgrano, one of my fellow students mentioned that "at least they don't require us to write a compiler anymore", making reference to earlier years when the students seemingly were required to write compilers in order to finish their degree.This obviously made me want to write a compiler, not to finish my degree, but to only satisfy my geeky desire to do something nobody else wanted to do.Why did I write a compiler for Visual Basic.Net?Visual Basic was the first computer language I learnt (way back at high school in '98 I got my hands on VB4, later on it was upgraded to VB5 and then VB6), and I did actually like it (no comments on this one please :) .Later on I started learning C++ (but I didn't like it since the relation between "tangible results"/"amount of code written" is way lower than for VB - in other words it took me far longer to do the same thing in C++ than in VB), and Delphi (which after about half an hour of trying things out the compiler started throwing internal errors at me, so I figured Delphi wasn't the language for me either).This happened about the same time as the first beta of VS2002 came out (VB7/VB.Net), I had ordered a copy so I was trying it out and learning about the new VB.Net language, and I liked it way better than the previous editions of VB, so the choice wasn't really that hard. Besides, I couldn't find any other VB compiler (non-MS and compatible with MS' version of VB) out there, so it always feels good to create something new :)The original intention was to write a compiler that compiled VB.Net into native code (I did actually get it produce a HelloWorld.exe, it was however mostly hardcoded into the compiler), but when I got to learn more about the managed world I realized that the intelligent thing to do would be to create a compiler that compiled IL to native code and therefore targeting several languages in one hit. The amount of document-reading required to do this (I would have to learn IL, assembler, the PE file format...), made it completely uninteresting, so I rescoped my project into creating a compiler to compile VB.Net into IL, just as vbc.exe does it.Why did I write the compiler in Visual Basic.Net?It didn't start out like that, I first tried C++ (yes, even though I didn't like it, but I thought it was a great change to learn it better and maybe make the mentioned result/work relation better). You can actually still see this in the code (check out the comments at the end of this file). The effort didn't last much though, after a couple of days of debugging memory leaks and seeing weird compiler messages all the time I got bored and figured I'd have to change the source language if I was ever going to finish anything at all.Next try was VB6. I'd read everywhere that no sane person would write a compiler in VB6, so I decided to kill that myth. After a couple of hours the myth had survived. The lack of inheritance in VB6 made me crazy, I saw myself either copy-paste huge amounts of code, or write it all in functions, with no OOP whatsoever, neither very pleasant alternatives. Especially now that I was learning the new Visual Basic.Net language. Once again, the choice wasn't really that hard.[...]



My Name

2007-02-20T21:15:28.361+01:00

Hi there!

I'm the guy behind the new vb compiler for Mono and my name is Rolf Bjarne Kvinge.  Yeah, that's right, you're probably not going to be able to pronounce it unless you know some scandinavian language (not even my wife can). And for the record: I have one first name (Rolf), one middle name (Bjarne) and one last name (Kvinge). Especially people from the Spanish-speaking world think I have one first name and two last names (it probably comes from the fact that in Spain everyone gets two last names, one from the father and one from the mother, and if you have only one, it's sort of like you don't know who is your father...).

You have no idea how many ways I've seen my name spelled and pronounced (and even though I really think my first name is really easy to spell), though Raulf Jarve is one of the better ones (you'd think journalists would spend more time on checking these kind of things, but this one obviously didn't - if google returns 2 (two) results for it something should tell you there's something wrong).

When I was living in Brazil they pronounced my name something like "Houlfi", in Argentina/Spain it's like "RRRRRRolf", in English it's with the English "R", it's only the French that is able to pronounce my first name more or less the way I do in Norwegian... and here in Spain I normally have to spell even my first name for them to be able to pronounce it (normally it will be either turn out Raul, Ralph, Rodolfo or Rudolf otherwise), but then they normally get it right.

Regarding my middle name and my last name I've learnt that it's completely useless to try to teach anyone how to pronounce them, so just call me Rolf, ok?