Great day today

I know a movie star
I’ve got her plastered to my wall.
Just like we’re dear old friends
Like she already knows me.
She’s as perfect as she seems,
Lifts me right out the mezzanine.
I finally fell in love,
I’d been waiting forever.

   -- Guster

I'm an Uncle!

My little sister had her baby boy (Alexander) last night.

Implement Interface

MonoDevelop Refactory work update:

This past week, after getting Renaming working for method parameters, I added context menu items that could implement a target interface's properties, methods, and events implicitly or explicitly auto-magically for the programmer.

You can see screenshots of these menus in an older post of mine, Refactory Operations

Godspeed, Robert Love

Today was Robert Love's last day at Novell, Inc.

Take care, Mr. Architect! Hopefully we'll continue to run into each other from time to time.

MonoDevelop Refactoring

Have you ever wanted to rename a variable in a source file and have all of the references to that variable be renamed as well? I'm sure you have. If you are a typical Linux developer, the only option you've ever had available to you would be to perform a Search & Replace action in your editor (bound to Alt-% in my Emacs editor).

...But this solution is hardly perfect. Search & Replace might match substrings you wouldn't want to replace, so you'd have to examine each substring match manually to accept the change, but this is prone to mistakes. Using a regex Search & Replace might help minimize mistakes in that you might be able to eliminate substring matches that were part of other identifiers, but you'd still have to manually examine each change if you re-used variable names in different scopes or different functions/methods within the same file.

...Which brings us to the next problem: editors historically used by programmers on Linux have never offered to update source files that depend on the current buffer, so programmers would have to manually update the other source files as well.

Welcome... to the Future.

This past week I've been working on a feature allowing MonoDevelop users to rename local variables, classes, interfaces, class members, methods, events, properties, etc and have all the appropriate code in the entire project auto-magically updated, no matter where you invoke the rename action (whether it be in the base class, inner class, some other section of code that uses the class, etc).

Just another example of Mono bringing improvements to Linux developers everywhere.

Beware: Suicidal Cars

Need I say more?

Childhood Memories

Today, Miguel asked me to take a look at fixing some of the System.Console 2.0 bugs. I managed to fix some of the ReadKey() and ReadLine() bugs, although the Backspace bug illustrated in Iron Python is still out there (it appears that the cursor X,Y position is not correctly kept track of in Mono).

Earlier today, when Miguel was explaining to me what sorts of problems existed in System.Console, one of the things he was hoping I could take a look at (although there was no bug # that I know of?) was optimizing Console.Write[Line]().

I didn't actually have time to look at that until tonight when I was sitting at my home computer waiting for my dinner to finish cooking. The solution was fairly simple (for those interested in seeing the patch, check out revision 75806).

An important part of optimizing a section of code is to compare actual running times of the old code vs the new code (and, obviously, to check that the results are correct), so I wrote a simple program that could be measured for performance improvements:

using System;

public class Program {
    static void Main () {
        Console.ForegroundColor = ConsoleColor.Cyan;
        string abc = new String ('a', 100000);
        Console.WriteLine (abc);
    }
}

Using the system `time' command, I got the following times:

pre optimization:

real 0m13.177s
user 0m0.308s
sys 0m0.232s

post optimization:

real 0m0.238s
user 0m0.124s
sys 0m0.004s

Wowzers!

Anyways, the reason the title of this blog is "Childhood Memories" is because after running this test program, I couldn't help but remember my first assembler program for the 6502 that I wrote back when I was 8 years old - it was a program which filled the screen with the character 'A' (which I then compared to a program written in BASIC that did the same thing). The difference in speed here was about the same as it was back then, too, funnily enough :)

Update: This morning I woke up realizing that I had a bug in my optimization patch last night, but I had a fix that lost no performance and then later today (in part thanks to Alan's prompting me to re-evaluate my need for a temporary buffer, which truly became unnecessary after my fix this morning) was able to optimize it even further (and eliminated the need for a temporary buffer) by blitting chunks of the input buffer between special escape sequences at a time (we have to handle certain escape sequences specially as they can relocate the cursor).

Oh, and the Iron Python bug is now solved... it was actually arguably a bug in Iron Python in that it goes behind Mono's back when writing to stdout so it was impossible for us to keep track of the cursor position. They do, however, use Console.In.ReadLine() (would be better if they simply used Console.ReadLine() but I digress), and so what I did was make ReadLine() query the terminal for the cursor position (rather than rely on our own state).