I’ll leave it open for archeological purposes, and because some posts seem to be actually useful for some people:

• Scientific Python for all: Matlab vs. SAGE and Python, The Enthought Python Distribution now with Basemap (which has superseded SAGE in my personal use for a long time now), Shapely
• Schizophrenia in Bibliography: Papers + Word 2008 = Bibliography heaven, Word 2008 = bibliography mess, Bibdesk (right now I’m waiting for Papers2 to allow cite-in-Pages like EndNote X4).
• Coding fonts: Coda Sans, Inconsolata
• My fruitless search about the perfect information manager: too much of a good thing, one information manager to rule them all, EagleFiler, the epilogue (these days I’m just trying to keep a clean folder hierarchy)
• A few bug descriptions: X Error of failed request, NVChannel FIFO, Quicklook and UTF-8
• A few science blurbs in french, which are totally out-of-date now but are still funny (to me): A story about NOx, About global warming, About global dimming, About Michael Crichton, About intelligent design

Take care.

dock preferences screenshot

Another thing I haven’t seen (yet) mentioned anywhere… In the last snow leopard build (10a394), the new “dock+expose” feature is enabled, and a new related option has appeared in the Dock preferences (see screenshot above). The checkbox label translates to “Minimize windows in the application icon”.

When you check this option, minimized windows don’t squeeze in the right side of the dock anymore; instead, they go “hide” behind the application icon. You actually don’t see the minimized windows anymore.

So how do you get to them do you ask? Well, if you have hidden ALL the opened windows for a specific application, just clicking on the app dock icon will un-minimize the last minimized window. If you already have at least one window opened for the application, this won’t work. Instead, you’ll have to use expose!

Expose with minimized windows

See, when the option above is activated, and you have minimized windows, Expose now divides the screen in two, with opened windows in the main top area, and minimized windows in a new bottom row. Pretty neat.

I haven’t yet found a way to minimized/unminimize windows directly from within expose (i.e. move windows between the top and bottom areas), which I could imagine would be useful. One weird thing though: if you hide an application, its minimized windows still show up in expose, the others don’t.

In Snow Leopard, french locale, the “Movies” folder will be called Vidéos. Finally. At least that’s what it’s called in the 10a380 build, and I seriously hope it’s gonna stay this way from now on.

For non-french speakers, you should know that since forever (at least since 10.3) the Movies folder in the french locale was called “Séquences”. While technically correct, nobody uses this word to describe video files. Videos is much much better. This is one of the small details that always bothered me in the OS, and it’s finally gonna be fixed. Yay.

During the past two weeks or so, the iMac began behaving strangely. The problems were mostly with the graphics, but after a while the system would slow down to a crawl and a reboot was needed. The problem manifested itself through the appearance of visual artefacts: mostly bits and pieces of the interface trailing behind actual windows or menus, but also horizontal lines in Safari or the Finder, or in the worst case entire parts of windows obscured by colored blocks. Once, I exited Firefox but its window stayed on-screen like nothing happened – I had to “erase” the window myself by using a Finder window as some kind of screen wiper. The easiest way to trigger this bug seemed to repeatedly open and close stacks in the Dock: sometimes the stack would appear only half-opened. Dock icons would also become corrupted after a while.

At first, I feared some kind of hardware failure, but I soon found out that after a reboot all these problems disappeared. Everything was working fine and dandy again, no video glitches. I thought it might come from overheating: nope, the temperature was below 50°C all this time, and problems sometimes occurred just as the computer was coming out of sleep (“waking up”, I guess).

A trip to the console enlightened me: the system.log for previous days was filled to the brim with entries more or less like

kernel[0]: NVChannel(GL): Graphics channel exception! status = 0xffff

kernel[0]: NVChannel(GL): Graphics channel timeout!

kernel[0]: NVChannel(GL): Graphics channel exception! status = 0xffff info32 = 0×3 = Fifo: Unknown Method Error

… and so on. I googled the problem, and eventually ended up on this seemingly neverending thread on the Apple Forums. In it, people alternatively blame Leopard 10.5.1, World of Warcraft, the Leopard Graphics Update, Aperture, Google Earth, any software that tries to use OpenGL, etc. I tried panning and zooming like crazy in Google Earth for a while, but no problem whatsoever — this was not it. But it led me in the good direction: video-intensive applications.

What video-intensive application do I use on a regular basis? I don’t play games, I run iPhoto once in a while… but every other day I end up watching a movie using Plex (not too hard to guess if you read the title of this post). So I kept Console opened in the background, launched Plex in windowed mode, opened a movie… and behold! Tons of graphics channel exceptions! Ha-ha!

Needless to say, I trashed Plex and its LaunchAgent right away. I’m pretty sure the issue only arised because I had tinkered with an option I shouldn’t have on my particular hardware; Plex is otherwise a pretty nice piece of software. The weird part is that I replaced Plex with XBMC (which is basically the same thing but less Mac-focused), and there was no Graphics channel exception to be seen. After switching to the MediaStream skin, it was as if nothing had ever happened. Without the graphical problems.

Maybe next time, I’ll write something more interesting, like how the Sarkozy government is slowly dismantling the research structures around here with the help of the AERES, creating inequalities between teaching positions to increase competition and handing  the control of universities to the private sector, all imposed from above, without concertation with the people who do the actual work, by a minister with strong ties to big corporations. Maybe.

Another nice unpublicized thing in this release, that is only mentioned in the release notes, is the addition of basemap (a nice mapping toolbox for matplotlib), which provides plotting functions I use a lot.

With previous EPD releases I always had to reinstall or upgrade one package or another, but now everything I need to work is there out-of-the-box, in the latest version for important packages. It’s a pretty impressive accomplishment, given how difficult it was to get a coherent “Scientific Python” stack as early as a year ago. The future is looking good for Python as a scientific toolbox.

Maybe even better: the slides are up too.

EPD is smaller than SAGE in size and also includes tons of good science stuff. There’s some overlap between the two distributions (for instance, both include the NumPy/SciPy/Matplotlib triad as well as IPython), but EPD is more geared towards observation data analysis and visualization. For instance, EPD includes netcdf and HDF5 libraries, VTK, WxPython, PyTables, PIL and lots of other stuff. And since it comes from Enthought, it also includes the whole Enthought Tools Suite, which are components aimed at making the development of standalone scientific applications easier (for an introduction to ETS see this nifty tutorial by Gael Varoquaux). The Enthought people also seem to my often-misinformed eye more directly involved into NumPy et al.

I’m not necessarily saying this distribution is better than SAGE’s, but if you don’t feel the need for some of SAGE’s extras (e.g. the Mathematica-like notebook approach, or the tons of symbolic math packages and libraries), you might want to take a look at EPD. The installation is painless and everything works as advertised (at least on Mac OS X).

TM’s on left, QL on the right. Unix deities seemed to confirm that TM was not to blame:

$ file test.txt 
test.txt: UTF-8 Unicode text
$ cat test.txt
é ç ë

On the other hand, opening test.txt with TextEdit gave the same result as QuickLook — messed up characters. If I fixed the characters in TextEdit and saved, the display of this particular file was always correct from then on (even if I modified it with TM afterwards). Weird.

Apart from a grand total of one (1) related and unanswered thread at Apple Discussions, a Google search for “Quicklook utf8″ or “Quicklook unicode” turned out nothing – so at first it seemed like there were only two people on the entire planet affected by this bug (well, three). By being a little more creative with my keywords, however, this post by Nico Weber on a vi-related thread turned up:

Indeed, if you check the two files with `ls -l`, you’ll see that the
file written by TextEdit has an “@” (that means it has an extended
attribute). Now, if you do `ls -l@` or `xattr -l filename`, you’ll see
that the TextEdit file has the com.apple.TextEncoding attribute set:

Macintosh-2:b nico$ xattr -l texteditfile.txt
com.apple.TextEncoding: UTF-8;134217984

The file written by MacVim does not have this attribute. If you add it
(`xattr -w com.apple.TextEncoding ‘UTF-8;134217984′ macvimfile.txt`),
the file shows up correctly in Quicklook (and in TextEdit too; it
didn’t do that before)

Applying the `xattr` command on test.txt did the trick: non-ASCII UTF-8 characters now show up fine in QL.

So what gives? It seems pretty harsh to me to demand extended attributes just to have the encoding right, especially when all 3-rd party programs are handling the matter perfectly fine without them, thank you very much. I don’t feel like applying xattr on all my text files either. I also don’t understand why the issue is not more widespread, i.e. why nobody talks about it. I feel like maybe this bug only appears with a specific combination of tools and locales? Should TextMate set the relevant attributes? I’m puzzled.