I didn’t realise Emacs has an elisp repl

When it comes to Emacs, I am an amateur at best, but part of the fun is that I keep discovering new useful functionality. Thanks to a post over at Mastering Emacs, I’m now aware of ielm, which came in very handy when I was trying to build an elisp function that would automatically pull all the packages I regularly use via ELPA if they weren’t installed already.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon

Running Emacs from a Windows Explorer context menu

It’s one of those days, thanks to a hard disk going south I ended up having to rebuild the system drive on one of my machines. After putting the important software back on there – “Outlook and Emacs”, as one of my colleagues calls it – I had to reapply some of the usual tweaks that make a generic developer workstation my developer workstation.

One of the changes I wanted to make was to have an “Edit in Emacs” type context menu in Windows Explorer. The only reason I was keeping another editor around was because it’s a feature I use regularly but hadn’t got around to setting up for Emacs.

StackOverflow to the rescue, as usual. I used the registry script provided in the first answer and tweaked it slightly. In contrast to a lot of people, I don’t keep Emacs running all the time but only when I’m editing something. For that reason like my Emacs setups to either start a new instance if there is no Emacs running or use an existing instance as a server if there happens to be one running.

With my little tweaks to start an instance of Emacs even if there is no Emacs server running, this is what the updated registry script looks like:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\*\shell]
[HKEY_CLASSES_ROOT\*\shell\openwemacs]
@="&Edit with Emacs"
[HKEY_CLASSES_ROOT\*\shell\openwemacs\command]
@="C:\\Tools\\emacs\\bin\\emacsclientw.exe -a C:\\Tools\\emacs\\bin\\runemacs.exe -n \"%1\""
[HKEY_CLASSES_ROOT\Directory\shell\openwemacs]
@="Edit &with Emacs"
[HKEY_CLASSES_ROOT\Directory\shell\openwemacs\command]
@="C:\\Tools\\emacs\\bin\\emacsclientw.exe -a C:\\Tools\\emacs\\bin\\runemacs.exe -n \"%1\""

There’s another neat little tweak in there, too – the directory “C:\tools\emacs is actually a symbolic link to the current installed version of Emacs on this machine so whenever I update my version of Emacs, I don’t have to redo other scripts and settings that try to use the current version of Emacs.

This might be an old hat to most Unixheads, but it’s slightly unusual on Windows so I figured I’ll mention that it’s possible to do something like this on Windows also.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon

Improving the performance of Git for Windows

Admittedly I’m  not the biggest fan of git – I prefer Mercurial – but we’re using it at work and it does a good job as a DVCS. However, we’re mostly a Windows shop and the out of the box performance of Git for Windows is anything but stellar. That’s not too much bother with most of our repos but we have a couple of fairly big ones and clone performance with those matters.

I finally got fed up with the performance after noticing that cloning the same large repo from the same Linux server to a FreeBSD box was over an order of magnitude faster and decided to start digging around for a solution.

The clone performance left a lot to be desired using either PuTTY or the bundled OpenSSH as the SSH client. I finally settled on using OpenSSH as I find it easier to deal with multiple keys. Well, it might just be easier if you’re a Unixhead.

Anyway, my search led me to this discussion, which implies that the problem lies with the version of OpenSSH and OpenSSL that comes prepackaged with Git for Windows. The version is rather out of date. Now, I had come across this discussion before and as a result attempt to build my own SSH binary that included the high performance ssh patches, but even after I got those to build using cygwin, I never managed to actually get it to work with Git for Windows. Turns out I was missing a crucial detail. It looks like the Git for Windows binaries ignore the PATH variable when they look for their OpenSSH binaries and just look in their local directory. After re-reading the above discussion, it turned out that the easiest way to get Git for Windows to recognise the new ssh binaries is to simply overwrite the ones that are bundled with the Git for Windows installer.

*** Bad hack alert ***

The simple recipe to improve the Git performance on Windows when using a git+ssh server is thus:

  • Install Git for Windows and configure it to use OpenSSH
  • Install the latest MinGW system. You only need the base system and their OpenSSH binaries. The OpenSSH and OpenSSL binaries that come with this installation are much newer than the ones you get with the Git for Windows installer.
  • Copy the new SSH binaries into your git installation directory. You will need to have local administrator rights for this as the binaries reside under Program Files (or “Program Files (x86)” if you’re on a 64 bit OS). The binaries you need to copy are msys-crypto-1.0.0.dll, msys-ssl-1.0.0.dll, ssh-add.exe, ssh-agent.exe, ssh-keygen.exe, ssh-keyscan.exe and ssh.exe

After the above modifications, the clone performance on my Windows machine went from 1.5MB/s – 2.5MB/s to 10MB/s-28MB/s depending on which part of the repo it was processing. That’s obviously a major speedup but another nice side effect is that this change will result in noticeable performance improvements for pretty much all operations that involve a remote git repo. They all feel much snappier.

 

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon

Make GNU Emacs play nicely with a German keyboard layout on Mac OS X

I used to use Carbon Emacs on OS X for quite a while, but with the release of Emacs 24 I switched to the stock GNU Emacs distribution. While GNU Emacs works fine on OS X, once you throw a German keyboard layout in the mix it doesn’t work so well as OS X uses Option + Number keys for a variety of characters needed for programming like [] and {}. As GNU Emacs uses Option as Meta out of the box that doesn’t work overly well, especially if you do a lot of programming in the C family of languages.

I finally got fed up with this restriction as it seriously affected my enjoyment of cranking out code under OS X. A bit of duckduckgo’ing gave me the necessary settings to use Command as Meta and pass Option through to the underlying OS. From my slightly hazy memory, this was the default layout for Carbon Emacs.

Here’s the code that will switch the keys around:

(setq mac-command-modifier 'meta
      mac-option-modifier 'none
      default-input-method "MacOSX")

Yes, there is also the whole argument about the unsuitability of using a German keyboard layout for programming. A lot of German programmers I know switched to UK or US layout keyboards to make programming easier.

I can drive one of those keyboards if need be but I’m both a touch typist and I rely on Kinesis Advantage keyboards for my day-to-day work thanks to an injury I got from a less than ergonomic desk quite a few years back. And while this old dog is generally happy to learn a new trick or three, I draw the line at switching keyboard layouts when there are other options available.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon

C++ memory management – why does my object still hang around after its destructor was called?

I recently came across a discussion on LinkedIn where someone had run into memory related undefined behaviour, which prompted me to write this post as it’s a common, subtle and often not very well understood bug that’s easily introduced into C++ code.

Before we start, please keep in mind that what we’re talking about here is undefined behaviour in any standardized version of C++. You’re not guaranteed to see this behaviour in your particular environment and pretty much anything might happen, including your cat hitting the power button on your computer.

The behaviour I am describing in this blog post is fairly common though – especially on Windows – and it’s one of the harder problems to debug, especially if you haven’t encountered it before or it’s been so long you can’t remember it (lucky you).

Let’s assume you have the following code:

class notMuch
{
public:
  notMuch(char const* str)
  {
    strncpy(m_str, str, 315);
  }
  char* getStr()
  {
    return &m_str[0];
  }
private:
  char m_str[315];
};
void oops()
{
  notMuch* nm = new notMuch("Oops");
  delete nm;
  std::string hmmm(nm->getStr());
}

Obviously this is a contrived example and decidedly bad code on multiple levels, but I constructed it like this to make a point.

Now assume that you are debugging the above code because you are trying to track down some odd memory behaviour. For some reason, everything is working fine when you run the code under the debugger, even though there is clearly something wrong in this code and you’d expect it to fail in a pretty spectacular fashion. Only that it doesn’t. You run the code and everything seems to be working, even though the code is clearly accessing an invalid object.

In order to understand what is happening here, we need to delve a bit deeper into C++ memory handling.

In desktop and server OSs, the call to operator new will be handled by your runtime library’s memory manager. The memory manager will attempt to locate a suitably sized chunk of memory and return it to operator new, which then makes use of this memory. In case of a low memory condition, the runtime’s memory manager will request additional memory from the operating system, but as OS calls tend to be a fairly expensive operations compared to checking an internal list, the runtime tries to minimize these calls and keep the requested memory around even if it’s not in use. When the object’s destructor is called, it takes care of its business – not much in this case as the object only contains an array of PODs, so the destructor is essentially a no-op – and then uses operator delete to “free” the memory.

Notice the quotation marks around “free”? That’s because in most cases, freeing the memory results in an entry in a list or bit field being updated. In the interest of performance, the memory isn’t being touched otherwise and now patiently waits to be reused, but the data in the chunk of memory remains unaltered until the memory chunk is being reused. The pointer to the object nm is still pointing to the (now freed) memory location. It’s invalid, but neither the runtime nor the user can determine that by simply looking at the pointer itself.

Unfortunately this means you now have an invalid pointer that’s pointing to an unusable object somewhere in the weeds that you shouldn’t be able to dereference. The trouble is that in a lot of implementations, you are still able to dereference the pointer and make use of the underlying object as if it hadn’t been deleted. In the example above, this works the majority of the time. If we don’t assume a multithreaded environment, there is no way the memory containing the invalid object will be touched, so it’s safe to access and the user ends up seeing the correct data.

So it’s bad, but not really, right?

No so fast.

Let’s now assume that before our call to getStr(), we insert another function call that triggers a memory allocation. Depending on the size of the requested chunk of memory and the current availability of other chunks of memory, the memory manager will occasionally reuse the memory that was previously occupied by nm. Not all the time, but occasionally. And as already mentioned, “nm” is indistinguishable from a valid pointer. All of a sudden, the attempt to create the string “hmmm” results in the string containing garbage or the program crashing, but the behaviour cannot be reproduced consistently and the crashes seem to depend on the phase of the moon.

The big question is, what can we do about this problem?

First, using RAII is a much better idea than raw pointer slinging. The above example contains a good reason why – if nm had been handled in an RAII fashion by using a std::shared_ptr or simply allocating the object on the stack the string hmmm would be constructed when nm was still in scope and a valid object.

Second, a lot of developers advocate nullptr’ing nm after the delete, at least in debug mode. That’s a valid approach and it will allow you to see the problem in the debugger, but it relies on the weakest link – the one located between the chair and the keyboard – to apply this pattern consistently. In any reasonably sized code base one can pretty much expect that someone will forget to apply the pattern in a critical piece of code, with predictable late night debugging sessions being the result.

Third, the use of a good memory debugger like Valgrind or Rational Purify will catch this issue and a whole raft of other, similar issues like double deletes, buffer overruns, memory leaks etc. If you’re writing production C++ code and you care about the quality of your work, you need to one of these tools.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon

I seem to be getting addicted to icicle-mode

Not that I’m doing much with it yet other than the more minibuffer completion, but I really notice when icicles is not installed or inactive, so I’ve ended up adding it to every Emacs installation I use. ELPA is coming in really handy as it’s a matter of just installing icicles via one of its repos rather than having to install it manually. I’m really going off manual installs of complex Emacs packages these days after doing it for so long.

One thing I really appreciate about icicles is that it subtly extends Emacs in such a way that you don’t notice its presence, but even after a couple of days I very much notice its absence. Of course its presence in the menus is much more obvious and pronounced, but I rarely use Emacs menus, preferring to drive it via the keyboard shortcuts. I’ll be experimenting with icicles a bit more because this mode has all the makings of a must have mode, at least for my setup.

And of course it’s another distraction from learning eshell. Oh well.

Anyway, check out icicles if you haven’t done so already.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon

How to turn off the shouty menus in Visual Studio, 2013 edition

Visual Studio 2013, much like its predecessor Visual Studio 2012, also “features” the SHOUTY uppercase menus. As in Visual Studio 2012, these can be turned off using a registry setting.

tl;dr – run this command in PowerShell:


Set-ItemProperty -Path HKCU:\Software\Microsoft\VisualStudio\12.0\General -Name SuppressUppercaseConversion -Type DWord -Value 1

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon

Getting emacs’ ansi-term to play nicely with FreeBSD

I was playing with the various shell options – sorry, trying to learn eshell – this evening. While playing with eshell I learned about the second, fully fledged terminal emulator ansi-term.

Most of my machines here run FreeBSD, as does the machine that hosts this blog. FreeBSD’s terminal emulators don’t recognise eterm-color as a valid terminal type, plus FreeBSD uses termcap and not terminfo, so the supplied terminfo file was of limited use.

As usual, stackoverflow came to the rescue with this answer. After adding the termcap entry and rebuilding termcap.db, ansi-term is now recognized as a full featured terminal emulator, running inside emacs. So now I can do this:

Screen Shot 2014-01-07 at 10.09.17 PMThat’s midnight commander running on one of my FreeBSD servers, inside GNU Emacs on my Mac. Job done.

And yes, ESC-0 is passed through correctly so I can actually exit mc.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon

Ergodox keyboard built and reviewed by Phil Hagelberg

Phil Hagelberg published an interesting blog post about the Ergodox keyboard. I’m a self-confessed input hardware nerd and have been a Kinesis Ergo/Advantage user for over a dozen years now. I love those keyboards – otherwise I wouldn’t keep buying them – but Phil makes a very good point that they’re bulky, not something you quickly throw into a bag and take with you for a hacking session at the local coffee shop. It’s good to see alternatives out there, especially as there seems to be less of a focus on ergonomic input devices recently.

Will I try to build an Ergodox? Probably not right now. My muscle memory is pretty tied to the Kinesis keyboards but if I find myself traveling more, I’d definitely look into one.

If you are a professional programmer you owe it to yourself, your continuing career and health to check out higher quality keyboards. Unfortunately over the last decade or so there has been a race to the bottom when it comes to keyboard quality. Most users don’t notice the difference and those who would most likely would probably have a good keyboard hidden away or were willing to buy one. Join them.

Yes, I’m a keyboard snob, but then again I had the good fortune to start programming professionally when these were the gold standard. You owe it to yourself to be a keyboard snob, too.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon

Accessing the recovery image on a Dell Inspiron 530 when you can’t boot into the recovery partition

My hardware “scrap pile” contained a Dell Inspiron 530 – not the most glamorous of machines and rather out of date and old, too, but it works and it runs a few pieces of software that I don’t want to reboot my Mac for regularly. Problem was, I had to rebuild it because it had multiple OSs installed and none of them worked. Note to self – don’t mix 32 and 64 bit Windows on the same partition and expect it to work flawlessly.

I did still had the recovery partition, but it wasn’t accessible from the boot menu any more. Normally you’re supposed to use the advanced boot menu to access it. I couldn’t figure out how to boot into it. There is a Windows folder on the partition, but no obvious boot loader. I also didn’t want to pay Dell for a set of recovery disks, mainly because those would have cost more than the machine is worth to me.

Poking around the recovery partition showed a Windows image file that looked it contained the factory OS setting – its name, “Factory.wim” kinda gave that away – and the necessary imaging tool from Microsoft, called imageex.exe.

All I needed was a way to actually run them from an OS that wasn’t blocking the main disk, so I grabbed one of my Windows 7 disks, booted into installation repair mode and fired up a command prompt.

After I made sure that I was playing with the correct partition, I formatted the main Windows partition and then used imageex to apply Factory.wim to the newly cleansed partition. This restored the machine to factory settings even though I hadn’t been able to boot into the recovery partition to use the “official” factory reset.

Oh, and if the above sounds like gibberish to you, I would recommend that you don’t blindly follow these vague instructions unless you want to make sure you’re losing all the data on the machine.

As a bonus task, you also get to uninstall all the crapware loaded on the machine. Fortunately it looks like everything can be uninstalled from the control panel. While you’re installing and uninstalling, make sure you update the various wonderful pieces of software that come with the machine as they’ll be seriously outdated.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon