Journal for 2008

I'm very excited to see that Ananth, the author of the Brahma LINQ-to-GPU provider, now has it running on Mono using OpenGL.

If anyone's not heard of GPGPU, it's the technique of taking a graphic processor unit and using it to run general-purpose computation. Discrete GPUs are incredibly powerful, so if code is ported effectively, it sees a massive speedup. However, the graphics-centric APIs and ridiculously parallelised architecture make this non-trivial. This is where Brahma comes in. It takes your C# 3 LINQ expression trees and automagically runs them on your GPU.

I can't wait to see it running on Linux!

I've recently added simple vi modes emulation to MonoDevelop. It's been a relatively quick and easy hack, though I'm pretty sure I'm now running a deficit of free time. I'm not actually a vi user, but I've been hearing from several of our users that they miss vi navigation and commands. While most editors (for example emacs) can be simulated to some extend through a keybinding theme, it's impossible to replicate even the simplest behaviours of vi this way.

After seeing ViEmu, a successful vi emulation addin for Visual Studio, I realised that a vi mode in MonoDevelop would probably see a lot of use, and, as a challenge, decided to bootstrap it. I'm hoping that real vi/vim users will contribute tweaks and patches to bring it closer to a faithful vi experience.

Some of you might be wondering why I started from scratch, since over a year ago, Ankit embedded vim in MonoDevelop. There are several reasons why I don't think this is the best approach. Embedding vim means you have perfect vim support, but you have to manually integrate all of the MonoDevelop features one by one. Integrating code completion is only the first step. Consider integrating language item tooltips, refactoring/navigation commands, error underlining, code folding, language item combos, semantic highlighting, text templates draggable from the toolbox, debugger breakpoint and stepping markers, debugger value inspection tooltips. Even when you finish this, you have to deal with potential future features like per-project editor settings, contexual multi-field templates, and who knows what else. People using vim integration would always be second-class MonoDevelop users.

I don't want to bring MonoDevelop features to vim, I want to bring vi/vim features to MonoDevelop.

Spelunking deep into Mono.TextEditor code, I implemented vi modes and commands at the very core of the text editor. The action-based architecture made this pretty easy to do at the core, though I'm running into a few problems at the higher levels of MonoDevelop, particularly the C# smart indenter, which relies on hooking <Enter> keystrokes. Fortunately it's still very usable.

The code is in MD SVN, and can be enabled through a checkbox in the Preferences -> Text Editor -> Behaviour panel. Features implemented so far are:

Motions

h j k l w b % 0 ^ _ $ G { }

Delete commands

d d{motion} dd D x X

Change commands

c c{motion} cc C r R

Insert commands

a A i I o O

Ex commands

 :q :w :qw :q! :{linenumber}

In addition, keyboard directional keys act where appropriate, normal MonoDevelop keyboard shortcuts remain functional, and visual mode is implemented but so far can only be used with normal MonoDevelop keyboard shortcuts.

I have a pretty good idea of what I'd like to see and how I'd like to see them implemented, in particular with regard to refactoring so that macros and repeat commands can be implemented. This will not be easy, but there are many other low-hanging fruit: B W e E ( ) word and sentence navigation, simple search/replace, repeated motions (e.g. d10w), cut/copy/paste. I'd also like to add some ex commands for IDE features, e.g. build project, jump to definition, rename variable, go to base class, implement interface. These are pretty easy too, though naming the commands will take some thought. It might be worth borrowing some ideas from jVi/NetBeans.

Unfortunately I'm not likely to have any time to spend on vi modes in the near future, but I welcome contributions, and will be glad to provide guidance to anyone who'd like to contribute.

I'm very pleased that Visual Web Developer Express 2008 has now gained Web Application project support in Service Pack 1. This means that MonoDevelop users will be able to share ASP.NET projects with VWD developers.

For those of you who haven't heard the story behind this, Web Application projects are support for developing your ASP.NET site as a project. Although VS.NET and VS.NET 2003 did this, it was removed in VS 2005 in favour of "Web Sites", which consider a web site to be a directory. As I'm sure you can guess, the latter system is convenient for editing websites in-place — and they even had FTP support for this purpose — but in my opinion it's a poor system for well-structured development. Clearly other people thought so, because Web Applications were added back to Visual Studio 2005 as an optional addon, and included in VS 2008. Finally in VS2008 SP1, it's reached the free version. The reason for this is quite simple; it's a necessity for proper ASP.NET MVC development.

At the moment, MD trunk does a passable job of opening projects from VWD 2008 SP1, but building and deployment isn't so great, because when I originally implemented these, I had to work around some of the limitations in MD's build and deployment system. These workarounds aren't quite compatible with the MSBuild projects from VS. I'm currently trying to make this seamless by tweaking our MSBuild loader to more closely match the MSBuild build targets and file copy semantics, making the MD deployment system slightly more generic, and implementing the build and deployment targets "correctly" for ASP.NET projects.

Support for importing Web Sites may come later, but for now, it's good to see that we can now interoperate with Microsoft's free ASP.NET development tool.

MonoDevelop has a code navigation history. When you switch views, or jump around between definitions, it logs the history, and you can browse back and forth like a web browser. However, it has some major issues -- the history it generates is unintuitive and erratic. It seems like it should be a really useful feature, but in practice is frustrating to use, so I recently decided to give it an overhaul.

Unfortunately, navigation isn't an easy thing to get right in an IDE. It's easy to log too many points. For example, if navigation points are logged every time the user switches between all their open document tabs looking for something, it gets very cluttered.

The most important thing is how it fits into the users' code navigation, so I decided to blog in order to get some feedback on my current thoughts.

In my opinion the following actions should not trigger logging of navigation points:

• Switching through files by control-tabbing or clicking on the tabs.
• Jumping using the search pad or the error pad
• Navigation between items using the document outline or the class browser
• Moving the cursor around with the keys and/or mouse (but this should alter/update the existing nav point)

Whereas the following points should be logged:

• The destination of a "Go to definition" command
• The point that's left behind when executing a "Go to definition" command, if it's not too close to the current point
• A jump to an event handler from a designer
• Locations in which text is edited, though these points should be carefully pruned so that there are no more than one or two per file

In summary, only direct interaction with the document -- and in particular, large jumps -- should be logged.

How will this fit into your coding flow?