There’s a new autoconf out, autoconf-2.63. It continues autoconf’s fine tradition of having the suckiest release schedule and quality of the GNU toolkit. You would think that they would increment the major number whenever they release a non-backwards compatible release, but they don’t for shear perversity. I guess 2.63 just rolls off the tongue, and I can’t blame them. The ridiculousness of having to test for different versions of your platform configuration tool boggles me. I’m at a loss for words at how much the autoconf maintainers have failed their core mission.
I’m not even going to go into their choice of m4 as the file format. That probably made sense at the time. But that the thing is implemented in sh is just stupid.
Really, what the autoconf maintainers should do is what the make maintainers never had the guts to do. Realize that their software is making the world a worse place, pick a worthy successor, and never update their project again. In my perfect world, autoconf is allowed to commit hari-kari. Meanwhile, automake is lined up against a wall and shot at dawn.
From the documentation for GetProcessInformation()
You need to specify values for the processInfoLength, processName, and processAppSpec fields of the process information structure. Specify the length of the process information structure in the processInfoLength field. If you do not want information returned in the processName and processAppSpec fields, specify NULL for these fields. Otherwise, allocate at least 32 bytes of storage for the string pointed to by the processName field and, in the processAppSpec field, specify a pointer to an FSSpec structure.
Rollover Carbon, rock on OOP.
I found this today and it’s too useful to not link to.
- A bundle for editing zsh scripts
- A terminal command for going to the directory the front textmate document resides in
They finally fixed threading. You heard it here first.
No important software for the Mac depends on Java.
I think he meant “I don’t have any important software that depends on Java”. There. Fixed that for you.
What I like about the most about his subsequent backpedaling is that it avoids the original issue people were complaining about.
- Gruber says Java isn’t supported in the new MacOS X 10.5 and no one cares except Java developers.
- People who do care write him and complain.
- Instead of saying, “oh, hey, some people clearly have different computing needs than me,” Gruber gives them a condescending lecture on prioritizing development issues, which wasn’t the point at all and as if developers don’t already know about needing to delay low priority tasks.
Somewhere in there he also found the time to talk about a new feature to AppleScript, a language that no one cares about, except AppleScript developers.
PS. I’m not a Java developer. I don’t even care for Java.
Taskpaper has a nice idea, using a plaintext microformat to store TODO lists. Seems unfortunate that it’s getting so much press a week before Leopard comes out with the same feature with presumably the same implementation.
I’ve long thought that TODO lists were overdue for an IMAP style, access this anywhere from any client, protocol. Nice to see Apple implementing it and it looks like they’re skipping the design-a-new-protocol phase and just using IMAP for the TODO list.
Next up, a standard way of syncing read RSS feeds? I’d like that very much, kthxbye.
I came across an interesting post about SmallTalk’s Seaside versus Ruby’s Rails.
The meat is in the comments which are very polite and informative. I’ve only played with Squeak once back in college so I didn’t really grasp the whole editing-live-objects-which-don’t-live-in-files thing.
It sounds pretty neat and pretty powerful.