I’ve done some more work on the Aperture Importer (background here), and the latest is attached below. It now does some reformatting of keywords that get split (e.g., “San” and “Diego” can be merged to “San Diego” as a keyword.) It’s hacky and ugly. You’ll have to set up your own keywords for this kind of merge.

I’ve found a couple of apparent Aperture bugs.

If I tell Aperture to import an empty directory from Applescript, it’ll stall and lock up Aperture.

Worse, I find that if I do a large import (more than, say, 5,000 images), Aperture grabs a bunch of memory that never gets released. Well, Aperture itself doesn’t grab the memory, but it causes the kernel_task “process” to allocate a big pile of real memory, which it seems to hold on to until reboot.

It’s a cumulative thing: if I import 5,000 images, the memory gets grabbed. Then, if I do another 5,000 image import, the memory usage doubles. Thinking it would be handled by swapping, I didn’t worry, and continued. This was a bad idea. Aperture locked up, but so did the whole OS. The last thing I could see from top was that 100% of my real memory was allocated, that less than 256M of swap was in use. I had at least 50GB of disk free, so that wasn’t the problem.

Anyway, for safety, if you use this import script, I recommend rebooting between import sessions. Yeah, it’s voodoo, but it’s guaranteed to work.

Aperture Importer Update

So I’ve been building a new security camera system. The last time I did this, I bought a Dell dual-core box, and spent about a week installing Debian, and building and rebuilding the kernel to support the dual cores, to support the BT878 video capture chipset, compile and configure motion, etc. It took a week of evenings and a weekend or two, because the Dell hardware wasn’t automatically supported, and it required special boot-time parameters to recognize the SATA controller, for example.

So I’m building a new system on a Dell Vostro 400. Right off the bat, I ran into problems with installing the Debian net-install. I was booting off a CD, but the installer couldn’t find an ATA/IDE controller for which it had a driver. Weird. This article showed me the solution to that — set the Dell controller’s SATA mode to “RAID.”

But then I hit a wall with the Intel Gigabit network controller. I couldn’t find any workarounds for it, but, after extensive Googling, found that some of the Ubuntu people may have a patch. The posting was six months old.

So screw it, thought I, and downloaded a shiny new ISO of Ubuntu 7.10 Server Edition to see whether it would work.

Damn, am I impressed! Not only did it recognize the ATA/IDE controller and the network controller, it happily recognized the BT878-based card and loaded the kernel modules. It even has motion installed as a package for easy installation. I was able to copy over all my support scripts and motion configuration files, and was up an running in less than two hours (and that includes setting up the web server, motd, special sshd tweaks, and all)!

Now, all I have to do is deal with my crisis of faith. Do I leave the Church of Debian for the radical new Ubuntuist movement?

So, in the process of organizing photographs, I wanted to examine my deeply-nested hierarchy to figure out how it’s possible I have 30,000 images (Aperture only wants me to have 10,000 in a project, so I need to re-organize the hierarchy even before I import).

So, I figured it’d be easy to use find to list all my directories, and how many images they contain. It turns out that (at least for me) it’s not.

My best stab so far is to use find and a loop, which gives me almost what I want (it not only includes the count of images in the each directory, but subdirectories as well). It fails if there are too many directories. It’s good enough. But it’s not elegant.

So CLI Deities — how would you make this pretty?

find . -type d | while read dir; do echo `ls -1 "$dir" | wc -l` $dir; done

Potential type-face issue disambiguation: after the ls, that first argument is a one, not an ell, although I suppose an ell would work too. The wc option is an ell.

As I described back in this article, I was getting segfault errors from eAccelerator.

I’m experiencing it on another, similarly-equipped GoDaddy VPS server. Same software versions, even, for Apache, PHP, eAccelerator, and OS, although this is not a old CMS Made Simple install.

Still, no good solutions out there, as far as I can google.

Here’s the clues I have found:

• The syntax function fun_name ($arg = array (blah)) is fatal.
• The order in which PHP extensions are loaded might matter.
• There are issues with files that get included or required multiple times via different paths.
• Software versions are just Too Old.

This is teh suckage.

Next thing I’ll try, when I have the time, is to upgrade the VPS to Fedora Core 6, and see if pushing those version numbers up a bit helps.

So, I’m working on an old RoR application, and was having a hard time getting it to work on my newer development machine.

The error dump was not at all clear:

C:\project\foo_bar_baz_quux>rake migrate --trace
(in C:/project/foo_bar_baz_quux)
** Invoke migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute migrate
rake aborted!
wrong number of arguments (1 for 0)
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:551:in `initialize'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:551:in `new'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:551:in `scramble41'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/vendor/mysq
l.rb:141:in `real_connect'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:316:in `connect'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:87:in `initialize'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:37:in `new'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/mysql_adapter.rb:37:in `mysql_connection'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:145:in `send'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:145:in `connection_without_query_c
ache='
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/query_cache
.rb:54:in `connection='
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:106:in `retrieve_connection'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_
adapters/abstract/connection_specification.rb:20:in `connection'
c:/ruby/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/migration.r
b:178:in `migrate'
c:/ruby/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/tasks/databases.rake:3
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `call'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `each'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:399:in `execute'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:369:in `invoke'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `synchronize'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:362:in `invoke'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `each'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake.rb:1935:in `run'
c:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/bin/rake:7
c:/ruby/bin/rake.bat:20:in `load'
c:/ruby/bin/rake.bat:20


I went through a lot of work to use older versions of Rails, etc, but none of it worked. I didn’t find much out
there that helped, either, until I finally happened across this page.

Turns out it’s one of those pernicious password / old style password hash issues with MySQL. Simplest solution for now: use no database password on the dev box.