I've just spent an hour working through the tutorials for
It's a free 3D modeling tool. Pretty slick and easy to use.
I worked on 3D graphics and user interaction when I was a Master's student
at Brown in the early 90s. What we had then wasn't bad,
but the SketchUp UI is easier to use and more functional,
and it runs on a regular PC instead of a high-end Unix workstation.
I can see myself using SketchUp to model woodworking projects.
I'm writing some C++ code at the moment, after months of C#.
I'm trying to be very Test First,
writing Red tests, then making them turn Green.
I'm also using CppUnit
for the first time. It's not as easy as
NUnit. You can't just declare
your test method with an attribute, you have to declare the test method
in a header file, place it inside a macro, and then have the test
implementation in a .cpp file. And there's no nunit-gui.
I'm using a post-build step to run the tests, which makes it
fairly pain free.
There was one internal method that I didn't have an explicit test for,
although I had tests for methods that called it. The main obstacle
was that I didn't have a simple way to check the result, as the method
returned a vector of objects. I didn't want to have to construct
another vector of expected results.
Then it came to me: I could wrap the vector in a class and write a
ToString() method for it (as well as a
ToString() for the
contained objects), and compare that to a string constant:
RateList result = creative.GetRates();
CPPUNIT_ASSERT(result.ToString() == "100_4x3:100_16x9|200_16x9|400_4x3:400_16x9");
In retrospect, it should have been obvious. I already have
methods for many of my other objects, and I'm using
CPPUNIT_ASSERT(actual.ToString() == expected) in many of my unit tests.
The extra step of writing
ToString() for the collection blocked my
I've ported Vim to Win64. Native binaries for AMD64 can be found on my
In the end, it wasn't all that hard. Last weekend, I fixed approximately
400 warnings that were thrown up by the x86_amd64 cross compiler.
Most of them were due to the widening of
size_t (especially the value
ptrdiff_t to 64 bits.
Several years ago, I went through a similar exercise in fixing these
warnings for Vim6, but I never finished the port.
This week, I scrounged access to an AMD64 box at work. Today, I turned on
the /Wp64 flag,
which found several new, subtler problems, where pointers where being
__int32s or conversely
__int32s were being widened to
pointers. Judicious introduction of (the equivalent of)
fixed most of those.
At that point, I tried running the binary. It refused to start!
After a few detours, I had WinDbg
installed, and ran gvim under WinDbg. That showed that the error was 14001
(ERROR_SXS_CANT_GEN_ACTCTX, "The application has failed to start because its
side-by-side configuration is incorrect. Please see the application event
log for more detail.") The event log showed nothing.
After more investigation, I found a WinSxS manifest for the Windows Common
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<description>Vi Improved - A Text Editor</description>
Once the two instances of
processorArchitecture="X86" were set to
processorArchitecture="AMD64", Vim started working without a hitch.
Despite my naïve expectations, none of the other fields in the comctl32
assembly needed to be changed.
Vim vs. Visual Studio
I've been an obsessive vi user
for more than 20 years. Vi keystrokes are indelibly burned into my
When I have to use Notepad or Word or Visual Studio, I feel crippled.
I have to work harder to do simple things; I have to type too many chords
with Alt and Ctrl; I have to take my hands off the home keys to use the
cursor keys and the mouse.
In the mid-90s, I adopted Vim (Vi IMproved)
to the point where I became a significant contributor, writing a big chunk of the
While I was at Microsoft, I hardly ever used Visual Studio.
I edited my C/C++ code with Vim,
I compiled and linked it with the
NT Build Environment
and I debugged it with
I was hardly alone in this. In the Windows division, your code has to
build with the NT build environment, and the Windows debuggers are much
better supported than the Visual Studio debugger for developing the OS.
Now that I'm programming in C#, using the Visual Studio IDE makes a lot
more sense. VS's IntelliSense for C# is much richer than
Vim7's Omni completion,
especially when coupled with ReSharper,
and VS is the debugger of choice for managed code.
I've been spending a fair amount of time in the VS IDE, especially when
pair programming, but I've also been switching back to Vim a lot.
When I'm struggling with unfamiliar code, VS's IntelliSense is a great comfort;
when I'm moving a lot of text around, Vim suits me far better.
Earlier this week, by way of its graphical Vim cheat sheet,
I found an interesting compromise.
ViEmu is a vi/Vim emulator for VS 2003 and
ViEmu implements most of the vi keystrokes and many of the Vim extended
keystrokes, right inside the Visual Studio IDE.
It uses the native VS IntelliSense in place of Vim's completion
functions. ViEmu even implements some of the more common Ex command line,
including most of the
:%s regular expression substitutions.
The author, who seems to be known only as JNG, is responsive.
Within 24 hours of my reporting some missing keystrokes, he had
implemented them in a new minor release.
It does not, however, support VimL, the Vim extension language,
so if you have an extensive suite of Vim plugins, as I do, they're not
going to work in ViEmu.
All in all, I'm favorably impressed with ViEmu.
It provides much of the muscle memory experience of Vim
inside of Visual Studio. Technically, it can't have been easy to
impose such a radically different input model on VS or
to emulate Vim and Ex fairly faithfully.
Vim has always been free (actually charityware),
but JNG charges for ViEmu.
Right now, I'm in the 30-day trial period, but I fully expect
that I'll pay for a license before the trial is up.
Vim comes with a Visual Studio add-in called VisVim, which is based on
another add-in called VisEmacs. It allows VS5 and VS6 to use Vim
as the default editor, albeit externally to the IDE: Vim continues to run
in its own window.
A few weeks ago, Bram asked me if I could get VisVim to compile with
VS 2003. I tried, but I was unable. Necessary headers are no longer
included with VS 2003 or VS 2005. No doubt this is because the Add-In
architecture changed radically with the introduction of Visual
Work is underway, albeit very slowly, to create
At some point, it may be worth creating a merger of VisVim and
viWord allows you to use vi
keybindings in Microsoft Word. It's not nearly as full featured as ViEmu
and I found that I didn't like it enough to keep it around.
This post was, of course, composed in Vim. I wrote it in lightly marked-up
plain text and converted it to HTML with VST,
Vim reStructured Text.
Blogging with VST will be the topic of a future post.
To fully take advantage of Vim7's Omni completion, you need a
patched version of Exuberant Ctags.
I've made a Win32 binary available.