Shallow Thoughts : : Oct

Comparing sunset times with PyEphem

We were marveling at how early it's getting dark now -- seems like a big difference even compared to a few weeks ago. Things change fast this time of year.

Since we're bouncing back and forth a lot between southern and northern California, Dave wondered how Los Angeles days differed from San Jose days. Of course, San Jose being nearly 4 degrees farther north, it should have shorter days -- but by the weirdness of orbital mechanics that doesn't necessarily mean that the sun sets earlier in San Jose. His gut feel was that LA was actually getting an earlier sunset.

"I can calculate that," I said, and fired up a Python interpreter to check with PyEphem. Since PyEphem doesn't know San Jose (hmph! San Jose is bigger than San Francisco) I used San Francisco.

Since PyEphem's Observer class only has next_rising() and next_setting(), I had to set a start date of midnight so I could subtract the two dates properly to get the length of the day.

>>> sun = ephem.Sun()
>>> la = ephem.city('Los Angeles')
>>> sf = ephem.city('San Francisco')
>>> 
>>> mid = ephem.Date('2012/10/31 8:00')
>>> 
>>> la.next_rising(sun, start=mid)
2012/10/31 14:11:57
>>> la.next_setting(sun, start=mid)
2012/11/1 01:00:45
>>> la.next_setting(sun, start=mid) - la.next_rising(sun, start=mid)
0.45055988136300584
>>> 
>>> sf.next_rising(sun, start=mid)
2012/10/31 14:34:19
>>> sf.next_setting(sun, start=mid)
2012/11/1 01:11:44
>>> sf.next_setting(sun, start=mid) - sf.next_rising(sun, start=mid)
0.4426457611261867

So Dave's intuition was right: northern California really does have a later sunset than southern California at this time of year, even though the total day length is shorter -- the difference in sunrise time makes up for the later sunset.

How much shorter?

>>> (la.next_setting(sun, start=mid) - la.next_rising(sun, start=mid)) - (sf.next_setting(sun, start=mid) - sf.next_rising(sun, start=mid))
0.007914120236819144
>>> ((la.next_setting(sun, start=mid) - la.next_rising(sun, start=mid)) - (sf.next_setting(sun, start=mid) - sf.next_rising(sun, start=mid))) * 24
0.18993888568365946
>>> ((la.next_setting(sun, start=mid) - la.next_rising(sun, start=mid)) - (sf.next_setting(sun, start=mid) - sf.next_rising(sun, start=mid))) * 24 * 60
11.396333141019568

And we have our answer -- there's about 11 minutes difference in day length between SF and LA.

Asynchronous sound playing in Python

A little while back I wrote about my Python xchat script to play sound alerts.

But one thing that's been annoying me about it -- it was a problem with the old perl alert script too -- is the repeated sounds. If lots of twitter updates come in on the Bitlbee channel, or if someone pastes numerous lines into a channel, I hear POPPOPPOPPOPPOPPOP or repetitions of whatever the alert sound is for that type of message. It's annoying to me, but even more so to anyone else in the same room.

It would be so much nicer if I could have it play just one repetition of any given alert, even if there are eight lines all coming in at the same time. So I decided to write a Python class to handle that.

My existing code used subprocesses to call the basic ALSA sound player, /usr/bin/aplay -q. Initially I used
if not os.fork() : os.execl(APLAY, APLAY, "-q", alertfile)
but I later switched to the cleaner
subprocess.call([APLAY, '-q', alertfile])
But of course, it would be better to do it all from Python without requiring an external process like aplay. So I looked into that first.

Sadly, it turns out Python audio support is a mess. The built-in libraries are fairly limited in functionality and formats, and the external libraries that handle sound are mostly unmaintained, unless you want to pull in a larger library like pygame. After a little web searching I decided that maybe an aplay subprocess wasn't so bad after all.

Okay, so how should I handle the subprocesses? I decided the best way was to keep track of what sound was currently playing. If another alert fires for the same sound while that sound is already playing, just ignore it. If an alert comes in for a different sound, then wait() for the current sound to finish, then start the new sound.

That's all quite easy with Python's subprocess module. subprocess.Popen() returns a Popen object that tracks a process ID and can check whether that process has finished or not. If self.curpath is the path to the sound currently playing and self.current is the Popen object for whatever aplay process is currently running, then:

    if self.current :
        if self.current.poll() == None :
            # Current process hasn't finished yet. Is this the same sound?
            if path == self.curpath :
                # A repeat of the currently playing sound.
                # Don't play it more than once.
                return
            else :
                # Trying to play a different sound.
                # Wait on the current sound then play the new one.
                self.wait()

    self.curpath = path
    self.current = subprocess.Popen([ "/usr/bin/aplay", '-q', path ] )

Finally, it's a good idea when exiting the program to check whether any aplay process is running, and wait() for it. Otherwise, you might end up with a zombie aplay process.

    def __del__(self) :
        self.wait()

I don't know if xchat actually closes down Python objects gracefully, so I don't know whether the __del__ destructor will actually be called. But at least I tried. It's possible that a context manager might be more reliable.

The full scripts are on github at pyplay.py for the basic SoundPlayer class, and chatsounds.py for the xchat script that includes SoundPlayer.

Patricia Peck, Requiescat in pace

I haven't been able to write much lately. I have a good excuse. I was helping my mom through the last stages of lung cancer. She died early Tuesday morning, October 9, 2012.

She was in hospice at home for the last six weeks, and Dave and I moved in to take care of her and try to make her last days more comfortable.

Hospice takes care of the drugs and medical equipment, so pain wasn't a problem (at least up until the end). But they aren't big on explaining anything, so figuring it all out was quite a learning experience for us.

I may write about that some day, but it's too hard now. It's not just losing a family member; it's who she was. Someone, I forget who, said once that I "won the mom lottery." It's true -- I couldn't have asked for a better mother. In school everybody wanted to trade moms with me. (I said no thanks.)

And some day I may write about all the things that were so great about her, and how much I appreciated her. But I'm not ready for that yet. I'm just glad I had the chance to tell her in person while she was still here. Some people don't get that chance. If there's someone in your life you really appreciate, tell them now. Just in case you don't get a chance later.

Anyway, Dave and I are back at home, trying to recover some sort of normalcy after more than a month of being full-time caregivers. I'll probably get back to posting tech tips and silly humor items soon. But for now:

Rest in peace, Mom. You were loved and appreciated, and I wish I could have had a lot longer with you.

A great team name: the Edison Chargers

I just love Edison elementary school's team name.

Fireballs -- an easier variant on the paper brick

I wrote, some time ago, about making burnable paper bricks as an alternative to shredding sensitive paper material that also helps keep you warm in winter.

We recently got pulled in to help with disposing of quite a large cache of sensitive paper, and have discovered a much faster method than the "let sit and stir occasionally" technique.

The trick is to use hot water, ideally with a little soap added. Hot soapy water breaks down the paper quite quickly; the soap helps it break down, and may also help the paper stick together better as it dries.

Stir the mess around a bit, and in as little as a few hours you can fish up handfuls of paper goosh them into nice compact tennis balls. (Though if you can let it sit overnight, so much the better.)

Try to squeeze out as much water as you can, and keep the balls reasonably small, so they'll dry quickly. Ours have been ranging from tennis ball sized to softball sized.

Then put the fireballs out in the sun to dry. We have them on a tarp in the backyard. If anyone visits, tell them it's an art project.

They feel fairly dry on the outside after a day or two, but of course the insides are still wet -- I'd let them sit for at least several weeks before throwing them into the fireplace. Don't want to smoke up the house! Fortunately, with temperatures in the nineties, I don't think we'll be needing the fireplace terribly soon.

Do check first whether your bucket's in reasonable shape. The first bucket we tried turned out to be brittle, and the bottom exploded a bit after putting the paper in. Oops! Brittle Bottom Syndrome seems to be a common fate of buckets that sit out in the backyard for too long.

But at least this photo shows the state of the paper after a short time sitting in the soapy water. I don't think anybody's going to be reading names or credit card numbers off any of these documents, whether or not they're gooshed into a ball.

We're accumulating so many fireballs that I'm hoping to try burning a pyramid of them some time this winter.