PHP segfaults. Unfortunately it’s quite hard to reproduce artificially; we don’t see the segfault until way after the reference was taken (presumably after the GC has done its rounds). It’s 100% reproducible in our program, but I’m still working on a minimal test case.
I’ve merged the current CVS HEAD (sub-minor version 0821 apparently) of iTerm with my +blur branch. You can download the new binary.
In doing so, I found that there’s a new maintainer, James Bunton, responsible for most of the changes. He’s got a mercurial tree, but it’s not up to date with sourceforge CVS. Welcome to distributed VC hell, where CVS is being used as a central repository between patchset-based DVCs. There are some importers, but if the canonical repository is CVS, importing from the mercurial tree is strictly more work (since I’d still need to import the CVS updates, and merge again).
cvsps and git-cvsimport do a good job of making working with cvs repositories from git reasonably painless. But I had some issues.
Perhaps it was just me failing, but I couldn’t coax git-cvsimport to import into my remotes (yes, using -r). Also it would be nice if git pull could figure out a remote was CVS and run git-cvsimport for me, using cached parameters. As it is, I have one repository for running git-cvsimport, and my working repository that pulls from that.
Git seems remarkably unhelpful when it comes time to do manual merging. An “ours”-type strategy for hunks consisting of just CVS $Id$ keywords would be nice. Why isn’t there a simple comand to run a 3-way merge with an arbitrary merge(1)-compatible invocation? I discovered smartmerge too late, but surely manual merges are common enough that getting 3 temporary files together could be done in one base command?
There’s a persistent feeling when using git that I’m doing it wrong, or at least there’s an easier way if only I could remember the command. I ran git status |grep unmerged because I couldn’t remember that I wanted git ls-files -u. I have to re-read git-rebase’s documentation every time I use it.
I’ve been a fan of terminal transparency since there have been terminal-emulators that supported it (although in the old days, it was just showing the X11 root window with some tinting). I’m not alone, and similar terminal-emulator users have been ahead of their time with respect to the transparency-fetish that is now popular.
Back on Windows 2k and xp there were various hacks that could turn a window transparent (I used one that came with my nVidia drivers). They weren’t perfect, as the transparency included the window borders and chrome, but they granted real transparency: where the background is a composition of alpha-blended windows. This added a little bit of depth to the desktop, rather than just having pretty terminal backgrounds.
When I moved to OS X, iTerm did it properly (i.e. without making the UI parts transparent). However, at the end of a long night hacking, with several accumulated editor and terminal windows full of text merged on top of each other, there is a serious readability problem with low opacities.
I use transparency because:
It’s easier on the eyes than high-contrast text-on-black.
It’s multiplexing content from multiple windows without consuming screen resolution. This is a fidelity trade-off: as the visibility of lower layers of text increases, the accuity of the frontmost (focused) layer decreases.
It impresses others.
When I saw Vista’s glass effect, the first thing I thought was “finally the answer to stacking translucent terminals!”. Combining blurring with transparency preserves the accuity of the focused window while transmitting enough information to be useful. So you won’t be able to transcribe text from below, but you can see if there’s, say, a burst of activity in IRC.
I suspect Microsoft got some IP rights on it, because Leopard has the most subtle application of transparency+blurring ever (in sheets and the menu bar), compared to Aero’s egregious UI-glassing. However, the imporant thing is that the new Core Image filters can be applied to windows, with a compositing mode that is perfect for terminals (and text editors for that matter).
One stumbling block is that the API to apply window filters is undocumented. Fortunately, thanks to the CGSInternal headers some of this API has been exposed.
It’s already been exploited for Apple’s Terminal.app, but that requires Input Manager patching hacks. I gave reasons why I prefer iTerm in my last post, but here’s another one: it’s open source and so I can add blurring in myself.