It turns out that by default, on Leopard, Python 2.5 looks at ~/Library/Python/2.5/site-packages for Python modules. The problem is that nothing installs there by default. However, distutils (and setuptools) will read settings from ~/.pydistutils.cfg allowing you to configure some default settings for the install and easy_install commands. After a little bit of work, here’s the final result:
[easy_install]
# set the default location to install packages
install_dir = $HOME/Library/Python/2.5/site-packages
[install]
install-base=$HOME
install-purelib=$HOME/Library/Python/2.5/site-packages
install-platlib=$HOME/Library/Python/2.5/site-packages
install-scripts=$HOME/bin
install-data=$HOME/Library/Python/2.5/share
install-headers=$HOME/Library/Python/2.5/Headers
Now I can worry less about what’s going to happen with my Python modules the next time I upgrade.
I had a misbehaving application (I believed it was connecting to the wrong port based on a preference setting), so I figured I’d give dtrace a try and see if I could capture the connect() system call. After a fair amount of tweaking, I was finally able to capture what I was looking for. Here’s the script:
#pragma D option quiet
typedef uint32_t in_addr_t;
typedef uint8_t sa_family_t;
typedef uint16_t in_port_t;
struct in_addr {
in_addr_t s_addr;
};
struct sockaddr_in {
uint8_t sin_len;
sa_family_t sin_family;
in_port_t sin_port;
struct in_addr sin_addr;
char sin_zero[8];
};
dtrace:::BEGIN
{
/* print header */
printf(”%5s %5s %-12s %4s %5s %s\n”,
”UID”, ”PID”, ”CMD”, ”TYPE”, ”PORT”, ”IP_SOURCE”);
}
syscall::connect:entry
/arg1/
{
sa = (struct sockaddr_in *) copyin(
arg1, sizeof(struct sockaddr_in));
printf(”%5d %5d %-12s %4s %5d %d.%d.%d.%d\n”,
uid, pid, execname, ”tcp”,
((sa->sin_port >> 8) | (sa->sin_port << 8)) & 0xFFFF,
sa->sin_addr.s_addr & 0xFF,
(sa->sin_addr.s_addr >> 8) & 0xFF,
(sa->sin_addr.s_addr >> 16) & 0xFF,
sa->sin_addr.s_addr >> 24);
}
And here’s sample output from loading the Slashdot page in Safari:
:: sudo dtrace -C -s snoop-connections.d
UID PID CMD TYPE PORT IP_SOURCE
501 83317 Safari tcp 80 66.35.250.150
501 83317 Safari tcp 80 66.35.250.150
501 83317 Safari tcp 80 66.35.250.55
501 83317 Safari tcp 80 66.35.250.55
501 83317 Safari tcp 80 66.35.250.55
Nice to see that Mac OS X shipped with Python 2.5. I need to figure out how to migrate a number of my Python modules to the mainline tree though. I should really just install them into a different tree. :-)
The only weird thing I’ve seen so far is that Terminal had some bogus key bindings set up. I don’t know why they chose to use page-up and page-down as a way to scroll the buffer… I guess they figured no one uses tools like Vim. :-) I use Vim constantly, so I changed the bindings to be more like the Linux defaults. I’m not particularly fond of all the translucency… it’s neat eye candy but stands in the way of productivity.
Other than that, things have gone smoothly. I’m definitely eager to try some of the dtrace tools out. I really wish I had a similar solution for Windows and Linux though.
I’ve had zero success in trying to recover from 10.4.10’s brokeness. I’m know going to have to attempt an “Archive and Install” to get 10.4.8 on the system, and then update back to 10.4.9. I thought I left the days of PC stupidity behind. Grrr.
In a few words, don’t do it. Many things are now broken on my nice Mac Pro box. USB Flash drive doesn’t work. VMware Fusion is broken (yes, I even tried updating to the 4.1 beta, which doesn’t seem to install correctly). SoftRaid is giving me a warning about needing 10.4.8 or better. It’s not pretty. I was up until midnight last night trying to resolve some of these issues with no luck. How disappointing.
One nifty feature on most modern macs is that you can disable processors on the fly. Up front, that doesn’t sound like much of a benefit, but in reality it is. As a developer, I can examine the compute time using different processor configurations, and see how well the software scales.
One problem that I ran into is determining the number of available processors. From sysctl’s man page, it shows an entry for ‘hw.ncpu’. However, that’s the number of processors installed on the machine, not the number of active processors. ’sysctl -a’ turned up the setting I was looking for: ‘hw.availcpu’. Actually, there was another one called ‘hw.activecpu’ that seemed to operate in the same way–it changed when hw.availcpu changed. However sys/sysctl.h recommended using hw.availcpu as the mechanism to determine the number of threads to create for SMP aware applications.
So, for those of you developing SMP aware apps on the Mac, hw.availcpu is the value you need to use.
Apparently something changed on a recent update. I had a script that used to the following:
hdid -nomount ram://size
newfs_hfs -v “Volume Name” /dev/rdiskX
hdiutil mount /dev/diskX
That doesn’t work any more. It appears that now there is a partition map expected to be on the volume, if you want ‘hdiutil mount /dev/diskX’ to work. You can, alternatively, use ‘mount’ to mount the device. However, if you want to use ‘hdiutil mount’, you can partition the ram disk by doing the following:
disktool partitionDisk diskX 1 HFS+ “Volume Name” <size_in_mb>M
I wish they wouldn’t change behaviors like this so willy-nilly.