Older blog entries for etrepum (starting at number 25)

hub: Although the Mach-O binary format does use "hardcoded" dylib paths (they are more like hints, though), the paths can be relative to an executable (as in an application bundle). This is how you are supposed to distribute applications. You can rewrite the load command paths post-link with install_name_tool(1), or influence the search path for dylibs at runtime with the dyld(1) environment variables (though I consider this a hack to be used only at development time).

The way dyld works is different (than dlls on win32 or "shared libraries" on Linux/BSD/etc.), but it most certainly not broken. It's just as flexible as anything else (actually more so, in many respects), you just need to RTFM.

osullivj: Although using generators to do asynchronous I/O might seem like a cute deisgn idiom, it's really just a silly hack to get around a fundamental flaw of the Python VM. There is a fix for this, called Stackless Python. The only tradeoff is that your code is no longer useful with a stock Python interpreter, but in many cases you control enough of the environment to where that isn't a big deal, beacuse you can just package up Stackless Python with your application. It's even binary compatible (bytecode and extensions) with regular Python.

elanthis, xf: Yes, if you order a *just announced* Mac, it will take a while to get. It's common knowledge, they will let you know approximately when it will ship. It's basically a preorder.

I don't know what there is to complain about. Apple has great customer service. If you want a computer that day, then go to the store and buy one... or call them up and ask "if I order this today, when will I get it?". They aren't going to lie to you.

URLs are Universal Resource Locators. Needlessly using query strings that break when you send a URL to a person on another computer (or another web browser on the same computer) is probably not a good idea if you're doing web development.

So just stop doing it, ok? It sucks for the users, especially if your script totally busts apart at the seams when the non-universal URL is visited by another browser.

lindsey: "C# doesn't force you to... This seems bad." No, it's not bad. Programming languages should do what you want, not vice versa.

MisterP: The UNIX version of PrBooM is based on SDL. Port that to Panther, don't bother with Carbon. It is relatively easy, the biggest problems you will have are linker differences and learning how to build app bundles and such. A port such as this (SDL based software that's already cross-platform) should take someone experienced a few hours at best, a weekend at worst. BTW, SDL's Quartz output for OS X is on top of Cocoa, not Carbon. You can use this to your advantage to make a nice set of menus and such (since Cocoa is infinitely easier than Carbon) for your port once you have it working.

kalle:

I'm well aware of the fact that the slice creates a new list. Either example is going to create a whole lot of useless temporary lists. Granted, the slice version creates almost twice as many, but both are horribly wasteful. I wrote it that way because reverse is in-place and the range syntax is ugly.

Archit: I assume you meant this:

k = [1, 2, 3, 4, 5, 6, 7, 8, 9]; k = [e for e in k if e < 2]

Because your syntax wasn't correct. Also, Python list comprehensions can nest, try this:

k = [(i, j) for i in range(10) for j in range(10)[::-1]]

nymia: OS X comes with Developer Tools on the fourth CD (called Xcode now), but IIRC they are not pre-installed when you buy the computer. If they were installed, you'd see them in /Developer on the boot volume.

mwh: OS X configuration files are a subset of XML called a Property List (plist). These are XMLified NeXT property lists, which were much cleaner looking and still easy to parse. In any case, there's not a whole lot you can do in a plist (DTD), so that's why Apple can write a tool like defaults(1) that is able to reliably manipulate arbitrary keys in an arbitrary plist file. It is also how they can offer simple APIs (i.e. NSDefaults) that basically just serialize/deserialize objects from the programming language you're using directly to these plist files, either by coercing to/from one of the simple types, or just encoding as base64. Strangely enough, I've even seen Apple use plists inside of plists disguised with base64.