Jb in a nutshell

Today, I had an amazing experience.

Today, I’ve patched our implementation of System.Object::ToString (). Do you realize that every time you’ll use ToString in Mono you’ll be executing a line I actually wrote? That’s simply amazing. I felt like I was literally modifying the blueprints of the known universe.

Sadly, you’ll most probably never notice it.

That’s life for ya`.

Lately, I’ve found myself using monoport more and more as a convenient pastebin like tool. Working on the build of Mono, I was mainly sending patches, logs or errors for instance.

Today I ended up writing a small script, that I tend to find quite useful, to post to monoport from stdin.

You want to send a patch? Easy:

svn diff | monoport

In return, the script will print the link to the post to stdout.

A little editing by hand will let you change the default values for the name, the life time of the post, and the language it is written in. In any case, you can specify them like this:

cat foo.patch | monoport -n:jbevain -e:f -l:diff

Convenient. I’m pretty sure you can find jillions* of such scripts on the net, still, this one is mine.

Download from here: monoport script. And as you can see, it can even monoport itself. Amazing.

*: sir, it’s not a number!

Congratulations John for releasing a first pre-alpha of IronRuby, and for the way you’re driving this.

On a side note, if you want to try it on Mono, use it with a console whose background is not white, or you’ll end up wondering what the hell is going on. IronRuby simply likes to write in white.

Eight days ago, I’ve blogged about an issue involving Cecil and ildasm. And the last security update to the .net framework.

After a few hours of investigation, I’ve managed to be able to reproduce the ildasm crash. It turns out that the security update is actually not involved in the issue. It’s just that I stumbled upon right after the security update, and that I had not experienced it before.

So, the ildasm crash happened when I was disassembling an assembly that I had just round-tripped. The issue is that in the same folder as the new assembly, there was the pdb file that was going along the assembly. So when Cecil re-writes the assembly, the methods identifiers are re-generated, and the pdb which keep track of them, becomes out of sync. ildasm uses the pdb file to read the variable names, and other infos. So when it tries to read them from the pdb, which doesn’t match the assembly, it may crash.

You can read the bug reported at Microsoft. It’s somewhat a corner case, so it’s not really critical. But if ever you face the same symptoms while disassembling an assembly generated by Cecil, you can try to delete the pdb.