I switched to digital cable recently, which means that there is now an external cable box for tuning. That means the analog tuner on my mythbox must be set to channel 3 to receive the input from the cable box. Unfortunately, ivtv-tune has a quirk that made it difficult to get the PVR-250 tuned to channel 3. The problem is that ivtv-tune needs the HOME environment variable to be set, and it needs there to be a ~/.ivtv-tune file there. Finally I got it working with this upstart script:
# Ensures the PVR 250 card is set to channel 3 so that the cable box works.
description "Ensures the PVR 250 card is set to channel 3"
author "Matt Hughes "
start on mounted
stop on starting shutdown
task
console output
script
echo "Changing tuner to channel 3..."
export HOME=/tmp
echo "device /dev/video0" > /tmp/.ivtv-tune
echo "freqtable us-cable" >> /tmp/.ivtv-tune
exec /usr/bin/ivtv-tune -c 3 -d /dev/video0
end script
Now the ir-blaster can do it's thing and everything works. As a side note, if your remove control stops working, you should replace the batteries be for messing with the LIRC configuration, even if you just updated your kernel. !$!@#$@# Linux.
I recently became interested in Clojure, a (mostly) functional lisp
that runs on the JVM. While reading the documentation and watching
the screencasts, I wanted to start trying out some of the stuff I was
seeing. I use Emacs
for code, on Windows, Linux, and Mac OS, and it is particularly
nice for dynamic languages that provide a REPL.
Here's the super easy way to get started with Clojure on Emacs.
Install a recent version of Emacs, 22 or 23, if you haven't
already got one. I use Carbon Emacs
on OS X.
Run Clojure in SLIME:M-x slime. You should be asked if
you want to download and install Clojure. Say yes, and let it do it's
thing, and you will eventually see a buffer that looks like this:
Today I've posted Phred, the 3d FDTD program I wrote for my M.A.Sc,
to Google code. In some ways it is very simple: it only supports
uniform grading for instance. The way the updates are handled is not
very flexible. The testing is pretty primitive. Other things about
it are still really cool: it runs on a variety on super-computers, or
at least it did five years ago. It uses Python as a scripting
language for problem set-up. It implements the Drude model for
modelling some kinds of metal. It's a good example of my skills as
they were five years ago. Despite cringing at some of this code, I'm
still pretty proud of it.
Drude model for simulating dispersive materials such as gold and silver.
Uses a hybrid MPI/OpenMP model for parallel computation. I found
that MPI by itself generally gave better performance, even on SMP
machines.
I ran the majority of my large simulations on Nexus and Glacier,
and smaller simulations on Debian Linux, so those are the best
tested. However, things have come along way in five years, and I'm
not sure if everything would still compile given various software
updates than may have been rolled out.
There are a lot of rough edges and unfinished things in the code.
I was experimenting with template meta-programming for the updates,
for instance. Template meta-programming is interesting, but because
it's a side-effect of a language feature designed for something else
it is hard to use. The error messages are particularly
unhelpful.
My goal in releasing this is mostly just to preserve it for my own
reference, to ensure that it is not lost when the hard drive it was on
is disposed of or dies. Open source is more than just the code. It
takes a lot of work to build up a community, get people interested,
accept patches, and so on. I don't have time to give this project
that kind of love. Perhaps someone else will be interested in picking
it up and taking it over, but that seems unlikely. There are already
many other actively maintained open source FDTD packages out there.
I'm using Cygwin and X11 on Windows 7, and I'm
pretty happy with it so far. The newest version of Cygwin integrates
nicely, and 7 seems pretty polished and much nicer overall than XP (I
never really used Vista).
The one problem I've been having is related to the meta key in
XTerm. I'm a heavy user of the Emacs movement keys, so M-b, M-f, M-a
and friends see heavy use. However, in the default configuration, I
get garbage and strange behaviour.
I finally found the fix in an old
blog post from 2005. To summarize, the fix is to ctrl-left click
and make sure that "meta sends escape" is selected. This can be made
permanent by adding this to your .Xresources file:
XTerm*metaSendsEscape: true
To load that change without restarting X, run xrdb -override
.Xresources.
Now to figure out what is wrong with X11 on Snow Leopard!
UPDATE: If adding the above your your .Xresources file does not work, try adding it to .Xdefaults instead. Alternatively, add xrdb -merge ~/.Xresources to your .xinitrc file.
I was trying to set up netatalk to serve files off my linux box to my macs, but Leopard was giving a cryptic error message whenever I tried to connect to the server. Turns out the that the default netatalk package that comes with Ubuntu doesn't have SSL support enabled, which Leopard requires. I finally found a blog entry that shows how to build an SSL enabled netatalk package. Works like a charm now!
AFP replaces SSHFS and Macfuse for me, as I couldn't get the volumes to mount read/write after upgrading to Leopard. AFP is really more suitable anyway.
I wrote a program to completely remove the FAT partition table
entry from the GPT, which meant learning about CRC-32 and messing up
with the dd command, which was... fun. All this effort didn't pan out however.
Ultimately, I ended up installing Leopard to an external drive,
migrating my backup into the new install, then formatting my internal
drive before using SuperDuper! to copy the new Leopard install to the
internal drive. After I had been running Leopard off of the external
drive for a while, a box popped up that told me that my internal drive
was now available for use in a limited capacity. Turns out Leopard
had been silently running fsck_hfs on the file system, and that it
turned up errors in the drive. That's probably the reason I couldn't
get the Leopard installer to recognize the drive. I just wasn't
patient enough. If I had waited for the installer to finish the fsck,
it probably would have shown up.
The error fsck_hfs found was "Incorrect number of thread records
found." Apparently this is not something that can be fixed in HFS+
file systems. Or at least, the built in tools can't fix it.
I've been trying to upgrade my MacBook Pro to Leopard for the last few
days. The trouble is, the installer refuses to detect any of the
partitions on my hard drive. It doesn't even show the drive with a
exclamation mark and tell me I need to repartition, which seems to be
fairly common. The Disk Utility and command line tools in the
installer don't see the partitions either, so it seems to a problem at
a more fundamental (kernel?) level. Tiger works fine, as does the
installer for Tiger. From searching the inter-tubes, it appears that
the problem is related to my bootcamp partition. The Leopard
installed seems to require a specific partition layout in order for it
to detect the partitions, which seems massively stupid. Especially
when bootcamp installations are probably fairly common on Tiger
machines.
I tried a couple of things already, such are resetting the protective
MBR to contain only the EFI protection partition, but that had no
effect. Since I have rEFIt installed, I wasn't
worried about trashing the MBR, since rEFIt can recreate it from the
GPT.
A guy on this thread about the Leopard
Installer disk detection problems suggests that the installer
requires the GPT itself to be set up in exactly the right way. It
requires either a single HFS+ partition of any size, or a single HFS+
partition followed by a "basic data" partition, as long as the sum of
the two partition sizes is exactly the size of the disk. My disk
appears to fit the second case... Except it doesn't, because
there is a gap between the HFS+ and FAT32 partitions, which can be seen
with the gpt tool:
thunderstorm:~ mch$ sudo gpt -r -v -v show /dev/disk0
gpt show: /dev/disk0: mediasize=80026361856; sectorsize=512; blocks=156301488
gpt show: /dev/disk0: PMBR at sector 0
gpt show: /dev/disk0: Pri GPT at sector 1
gpt show: /dev/disk0: Sec GPT at sector 156301487
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 102760448 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
103170088 262144
103432232 52869216 3 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
156301448 7
156301455 32 Sec GPT table
156301487 1 Sec GPT header
So, there is a 6 sector gap between the table and the HFS+
partition, and a 262144 sector gap between the HFS+ partition and the
FAT32 partition. That second gap is probably what is messing up the
Leopard installer.
Here's what diskutil has to say about the disk:
thunderstorm:~ mch$ sudo diskutil list disk0
/dev/disk0
#: type name size identifier
0: GUID_partition_scheme *74.5 GB disk0
1: EFI 200.0 MB disk0s1
2: Apple_HFS Thunderstorm 49.0 GB disk0s2
3: Microsoft Basic Data HELL 25.2 GB disk0s3
Yes, my Windows partition is named HELL. Here is my MBR, after I
trashed it so that it only contains the protective GPT partition:
The next step is to back up my boot camp partition before taking
the FAT32 partition out of the GPT... I'm hoping that that will let
me install Leopard, after which I can attempt to restore the GPT
entry for the FAT32, and hopefully everything will work.
The "My account" page on the Calgary Public Library site uses your library card number and a pin number to authenticate you. However, both form fields are of type "password", which means that Firefox won't save the username / password information. Since the site seems to randomly log you out, it becomes a pain in the ass to get out the library card over and over again to type it in by hand.
This Greasemonkey script simply changes the library card barcode number field from a password type to a text type, which allows Firefox to remember the contents. Unfortunately, when Firefox fills the form, it places the "password" (your pin) in the first password field it finds... since the autofill happens before the Greasemonkey script runs. The barcode isn't autofilled anywhere, so it is necessary to embed it in the script itself. Or you can type the first number in the barcode field and it will autofill it then.
NOTE: after using the CPL website a while, I noticed that the original version of this script was filling in random form fields. It needed to be modified to look for some unique characteristic of the sign in page. Since the CPL website uses a single JSP and GET URL parameters to navigate all the pages, one can't use the greasemonkey include/exclude URL thing.
// ==UserScript==
// @name Calgary Public Library Login fixer
// @namespace http://spacemonkeys.ca/greasemonkey
// @description Changes the password box to a text box so
// that firefox can remember the form fields.
// @include https://catalogue.calgarypubliclibrary.com/ipac20/*
// ==/UserScript==
var inputFields = document.getElementsByTagName('input');
var barcode = inputFields[9];
var barcodeLabel = barcode.parentNode.parentNode.childNodes[0].childNodes[0];
var pin = inputFields[10];
var pinLabel = pin.parentNode.parentNode.childNodes[0].childNodes[0];
var mycardNumber = "xxxxxxxxxxxxxx";
// Firefox autofills the pin into the barcode field, probably because
// that is the first password field it sees. The barcode itself is lost.
if (pin.name == "sec2"
&& barcode.name == "sec1"
&& barcodeLabel.data.search("Library Card Number:") != -1
&& pinLabel.data.search("Last 4 numbers") != -1)
{
var temp = barcode.value;
barcode.value = mycardNumber;
pin.value = temp;
// Make the barcode number a text field, so that Firefox will be able
// to remember the barcode/pin combo.
barcode.type = 'text';
}
It looks like the CPL is in the middle of overhauling their site, so maybe the need for this script will go away.
If anyone can tell me how to get Firefox to redo the autofill after changing the barcode field to text, that would be great!
I'm often asked how many lines of code there are in some project I'm working on. I think it's the least useful metric of any codebase, but people always seem interested in knowing. I'm not sure if they are more impressed by a small number or a large number...
Since it comes up, here's a one liner to count the number of lines of code.
It is sometimes necessary, even in this day and age, to use DOS or
some other simple operating system to directly access hardware to
perform tasks such as BIOS upgrades. Floppies, the traditional boot
media for quick and dirty tasks such as this, are almost extinct. CD's
are cumbersome to use and change. It is therefore handy to use
some other portable external bootable media for jobs such as
this. Enter the bootable USB key.
FreeDOS is a handy open source alternative to
MS-DOS, but it only comes as a CD image that must be burned to a CD
and then installed to a hard drive in order to be usable. This makes
it a bit cumbersome to install on a USB key.
I took a somewhat circuitous route to arrive at these
instructions, which included installing FreeDOS in a VMware Fusion
virtual machine, copying that virtual disk to a flat image file,
moving that image file into a Ubuntu virtual machine, byzantine
manipulations of a USB flash drive with dd, and learning more
about FAT and MBR than I ever wanted to know. Hopefully the distilled
instructions below are a little easier.
I assume that you have a Linux capable of running QEMU (there is a version of QEMU for OS X). You don't need
to use QEMU... but it makes it easier to try different things are
repeat the process while still doing other things, since you don't
have to reboot all the time.
Download the FreeDOS installer ISO from FreeDOS.org.
Partition your USB flash drive as you please. You should have at
least one FAT32 primary partition on which you will install
FreeDOS.
Run qemu-launcher. Set it to boot from CD-ROM, and set the CD-ROM
path to point to the FreeDOS ISO you just downloaded. Set hard disk
path to point at the raw flash device (something like /dev/sdb... find
out from dmesg).
Launch qemu. It should boot the FreeDOS installer. Install FreeDOS
on the "hard drive". I recommend installing just the base set of
packages, unless you want to experiment with networking, etc in FreeDOS.
If you don't need multiboot, you are done.
Close QEMU, unplug the flash drive, and try to test it on a real system. If you have trouble, like it says that no OS is found, it may be necessary to run QEMU again in the same way as before, except instead of using the installer, use the live CD and run fdisk /mbr and sys c: to make sure the drive is fully bootable.
If you want to use multiple OS's on the flash drive, then you can
install grub and set it up to boot each one. But that's for a later
post...
but is thinking that one of the drivers you are cheering for just died entertainment?
Urgh. Yay safety innovation. Concussion and a sore (broken?) ankle. Wow.
Crashes are entertaining when you don't know who is involved, but it's pretty dramatic when it happens to someone you are cheering for. Which is part of watching sports I guess... experiencing the lows is just as much a part of it as the highs. Of course you alway want more points and less crashes in that case.
Montreal was perhaps the most entertaining race of the season, and that's because a lot of unexpected stuff happened, not because anyone drove particularity well.
I often tried to use bash's for loops to do line by line processing, but it's alway been a pain in the ass. An example. I have a list of files in a text file, and I want to copy each file to some other location. The naïve method:
for F in `cat names.txt`; do cp $F /new/path; done
Unfortunately, names.txt looks like this:
This filename has spaces 1.txt
This filename has spaces 2.txt
...
This filename has spaces N.txt
Bash breaks each line on the space, so the for loop doesn't copy each complete filename. If there are no spaces or tabs in the filenames, then the for loop works ok. The right solution is to use the read command and a while loop:
cat names.txt | while read FILENAME; do cp "$FILENAME" /new/path; done
Update per comment below: added quotes around $FILENAME.
