Left early.
Got a new codebase from JD, which I've uploaded to the beta version of the site, and to which I had to make two changes myself, one that he'd forgotten and sent me by email, and one which results from my meeting with JS-R the other day. The new version allows selection of tract ranges, but it fails to upload the additional Philadelphia data which is required for the beta site; I'm currently corresponding with JD about what might be causing this.
Rewrote a stack of the db connectivity code using pure mysql functions in PHP, and lo, the whole thing works fine. This pretty much proves to my satisfaction there's a weird bug in MDB2, so we'll avoid it like the plague in future.
I now have <select> elements auto-populating themselves, and I'm beginning the rewrite of the code for adding, editing and deleting new items. Meanwhile, I've taken some of the sample data and uploaded it into mySQL through phpMyAdmin. In the process, I encountered a limitation we need to get around: max_allowed_packet is set at the default 1MB, which won't allow uploads of image files that we need to store in BLOB fields, so Greg is going to get that value changed to 15MB.
Martin and I took a look at using dd to "ghost" a partition on a Mac. On Radish, we ran the command:
dd bs=5120 if=/dev/rdisk1s3 of=/Volumes/Storage/testing/radish.img
The command ran successfully, and 20 minutes later we had a 20GB image. When I tried to mount it, however, it turned in to a 0kb file. Oops! Not sure why; I probably screwed something up.
Next we tried a simpler command:
dd if=/dev/rdisk1s3 | gzip -c5 > /Volumes/Storage/testing/radish.gz
The syntax is pretty simple. "if" is the input, in this case the 3rd partition on disk 1. "| gzip -c5 > " sends the input to the gzip command, using a modest compression level and then writes it, using ">", to "of", which is the output file.
The point here is to try to create a simple, automatable system for building *nix-based machines (like in a lab). Our hope is that we can create a master machine, run a "dd" like command to create an image of the OS partition, rsync it to a server and then rsync it back to lab machines for rebuild. rsync is our weapon of choice because it does its thing by only replacing the bits in a file that have changed. Ostensibly, this means that we can make a simple change to the master machine, re-image it using "dd", rsync it to the server (which will only replace the pertinent bits) and then have lab machines rsync against the updated image (again, only changing the important bits) and then run "dd" again to build the local machine.
Applications are invited for two 2 ½ year fixed term positions with the Digital Humanities Observatory (DHO), a national digital humanities centre located in Dublin, Ireland.
The second HASTAC/MacArthur Digital Media and Learning Competition is now open. The focus is participatory learning.
Awards will be made in two categories:
1. Innovation in Participatory Learning Awards to support large-scale digital learning projects
Applications from Canada are now being accepted in the "Innovations in Participatory Learning" category as part of a pilot international program.*
2. Young Innovator Awards targeted at 18-25 year olds $5,000-$30,000
Full information at: http://www.dmlcompetition.net/
*Participatory learning is **defined broadly: using new digital media for sharing ideas or planning, designing, implementing, or just discussing ideas and goals together. *
* (You can find out about last year's winners at http://hub.dmlcompetition.net/
Spent all day writing a debug engine into the RomanLaw project in order to figure out what was causing some very odd behaviour, in which queries worked on one table but failed on another identical table. There are three options:
- PEAR's MDB2 library is broken. There are some indications of previous bugs in this area, and the documentation for MDB2 is poor. We can only test this by rewriting the whole site to use DB, or pure mysql functions. This is probably what I'll have to do tomorrow.
- mySQL is flaky on the dev server. Some odd behaviour when we tried to drop tables suggested this might be the case, but we have dropped and rebuilt the entire database several times.
- There's a mismatch between our PHP version and our mySQL version (in other words, PHP is expecting a more recent mySQL, or doesn't work well with precisely the version we have). This is less likely (although it is the case on Mustard).
I'm going with option 1 tomorrow; Greg is looking into the mySQL logs to see if there's any sign of 2 or 3.