I did a clean install of OS X 10.10 on my home laptop a week ago. I tried to launch PyCharm 4.0.4 on it today. It im­me­di­ate­ly failed. Every time.

When I looked in the System Console, I saw:

1/25/15 7:46:00.557 PM pycharm[1160]: No matching VM found.
1/25/15 7:46:00.711 PM com.apple.xpc.launchd[1]: (com.jetbrains.pycharm.58252[1160]) Service exited with abnormal code: 1

The JetBrains website wasn't very helpful when I looked there. In time, I found a Stack­Over­flow answer that put me on the right track (and reminded me that I had previously solved this problem about a year ago, at work). PyCharm and some of the other JetBrains IDEs require JDK 1.6, as …continue.

I've spent some time this evening profiling a Python ap­pli­ca­tion on Windows, trying to find out why it was so much slower than on Mac or Linux. The ap­pli­ca­tion is an in-house build tool which reads a number of config files, then writes some output files.

Using the Run­SnakeRun Python profile viewer on Windows, two things im­me­di­ate­ly leapt out at me: we were running os.stat a lot and file.close was really expensive.

A quick test convinced me that we were stat-ing the same files over and over. It was a com­bi­na­tion of explicit checks and implicit code, like os.walk calling os.path.isdir. I wrote a little cache that memoizes the results, which brought …continue.

In the last few weeks, I've switched over to Git for most of my version-control needs, at home and at work, after putting it on the long finger for months.

We continue to use Subversion at work, but I've recently followed Pavel and Eric's lead in using git-svn. I work locally on my own private branches and git svn dcommit and git svn rebase oc­ca­sion­al­ly. I'm primarily on Windows at work, but I have a Linux box and a Mac Mini too, while at home, I have a MacBook, a Linux netbook, and a Vista desktop. I'm using msysGit, oc­ca­sion­al­ly sup­ple­ment­ed by Tor­toise­Git and QGit. Pavel's on a Mac …continue.

I've been running the 64-bit version of Windows 7 RC since June. It's been quite painless on the whole.

One wrinkle that I ran into was with some batchfiles which launch ap­pli­ca­tions in %Pro­gram­Files% (normally C:\Program Files). Due to the magic WOW64 redirector, 32-bit ap­pli­ca­tions are actually installed into %Pro­gram­Files(x86)%—normally C:\Program Files (x86)—instead of %Pro­gram­Files%. This is trans­par­ent to the 32-bit ap­pli­ca­tions, which think they're running in %Pro­gram­Files% (C:\Program Files).

However, the cmd.exe shell is 64-bit (unless you make a special effort to run the 32-bit cmd.exe in SysWOW64), so batchfiles see the 64-bit %Pro­gram­Files% which contains 64-bit ap­pli­ca­tions.

Hence, a batchfile that launches an installed 32-bit ap­pli­ca­tion on Win64 must use %Pro­gram­Files(x86)%, not %Pro­gram­Files%.

It sounds …continue.

When using Lightroom before, I was never able to figure out how to move photos from one folder to another. You'd think that you could just click on a photo and drag it. I just spent twenty minutes figuring out what I've been doing wrong. After you've selected multiple photos, click on the photo thumbnail and not the sur­round­ing gray frame, and then you can drag the photos to the target folder.

I had become accustomed to clicking on the frames to multi-select photos, so naturally I assumed that was also how you dragged a set of photos. But clicking on a frame of a selected photo merely deselects …continue.

I mentioned three weeks ago that I had just repaved my work dev box and installed the 64-bit version of the Windows 7 RC. Nine or ten years after I first ported parts of IIS to Win64, I am finally running my main desktop on 64-bit Windows. With one exception, it's been painless. Programs have just worked, devices have just worked. There are relatively few native x64 ap­pli­ca­tions, but for the most part it doesn't matter. The cases where it does matter—e.g., shell extensions such as Tor­tois­eSVN—are available as 64-bit binaries.

I briefly flirted with using the 64-bit build of Python, but realized that I would have to recompile several eggs as …continue.

Python has long had a string in­ter­po­la­tion operator, %.

Python 2.6 and 3.0 introduced a new, richer set of string formatting operations. See PEP 3101 for the rationale.

One trick that I liked with the old way of formatting was to put the locals() dictionary or self.__dict__ on the right-hand side

>>> def stuff(a, b):
...  c = a+b; d = a-b
...  return "%(a)s, %(b)s, %(c)s, %(d)s" % locals()
...
>>> stuff(3, 17)
'3, 17, 20, -14'

It took me a few minutes to figure out how to do the equivalent with string.format: use the ** syntax to unpack the dict into kwargs.

>>> class Person(object):
...  def __init__(self, name, age):
... 

About three weeks ago, I answered a question on Stack­Over­flow about generating the most readable color of text on a colored background.

I suggested flipping the top bit of each component, (r ^ 0x80, g ^ 0x80, b ^ 0x80). This has the same effect as adding 128 if the component is less than 128, and sub­tract­ing 128 otherwise.

Another way to think about it is to imagine the 256x256x256 color cube. Inside that cube, erect another cube half as wide. One corner is at your original color and the diagonally opposite corner is the one computed above.

The questioner liked my answer the best, but I decided to experiment further. I wrote …continue.

The Cozi Tech Blog needed some love, so I wrote a post on augmenting Python's strftime.

On a Stack­Over­flow question about favorite Vim plugins, I learned about Ack, a re­place­ment for grep that's smarter about searching source trees.

Ack is written in Perl. The built-in :vimgrep is rather slow. It seems to have some Vim-specific overhead, such as creating swap files and executing BufRead autocmds. Ack is noticeably faster, though somewhat slower than GNU grep.

Which would you rather type to search a tree, ignoring the .svn and .git subtrees?

$ ack -i -l foobar
$ grep --exclude='*.svn*' --exclude='*.git*' -i -l -r foobar .

The ack takes 6 seconds to search 4500 files, while the grep completes in 2. This does not count the time that I spent trying …continue.