The python-daemon library has a nice implementation of pidfiles, much better than the standard lib lockfile. i.e.
import lockfile.pidlockfile as pidlock
lf = pidlock.PIDLockFile("/tmp/mqtask.pid")
# module methods
pidlock.read_pid_from_pidfile
pidlock.remove_existing_pidfile
pidlock.write_pid_to_pidfile
Monday, March 14, 2011
Monday, June 21, 2010
Airbnb sounds cool, but I really want Walk-in-closet-to-go
I don't like packing.
When I look around my house, I see the progress I've made towards living a less-stuff lifestyle, such as advocated by Paul Graham, among many others, (see Stuff.) Still, I don't think I'll reach the point where I can comfortably live out of a suitcase or a backpack without significantly reducing the quality of my life.
So what about a service more like AirBnB + PODS + A Closet organizer something like this + Robotic movers similar to these = Easy, comfortable, continuous travel.
Just playing with numbers on the back of an envelope, I think this would be both possible and cheap, in the near future.
Hmmmm....
When I look around my house, I see the progress I've made towards living a less-stuff lifestyle, such as advocated by Paul Graham, among many others, (see Stuff.) Still, I don't think I'll reach the point where I can comfortably live out of a suitcase or a backpack without significantly reducing the quality of my life.
So what about a service more like AirBnB + PODS + A Closet organizer something like this + Robotic movers similar to these = Easy, comfortable, continuous travel.
Just playing with numbers on the back of an envelope, I think this would be both possible and cheap, in the near future.
Hmmmm....
Monday, June 7, 2010
Using Apache Camel from Clojure
I've been looking at Apache Camel for a project at work, and had a bit of trouble getting it working from Clojure, so I wrote this up in case anyone has the same issues.
The first example in Camel in Action watches a directory for new files, and copies them to an output directory. Here are the steps to get that running in Clojure, using leiningen.
Part of what screwed me up was the fact that you need to include spring in the project in order to get camel to work properly.
You can also use a macro to make the code even cleaner, like this:
Which I think compares nicely to the original Java:
I'm sure there are more improvements possible, but this got me started.
The first example in Camel in Action watches a directory for new files, and copies them to an output directory. Here are the steps to get that running in Clojure, using leiningen.
- Create your input and output directories
- Create a new leiningen project
- Add the following to the project.clj
- run lein deps
- Add the following to your src/org/whitlark/fc.clj (or whatever your last name is ;-)
Part of what screwed me up was the fact that you need to include spring in the project in order to get camel to work properly.
You can also use a macro to make the code even cleaner, like this:
Which I think compares nicely to the original Java:
I'm sure there are more improvements possible, but this got me started.
Friday, April 23, 2010
Extending the range of a PS3 controller.
Just plug a short usb cable (I use 12"), and leave the other end unplugged. The cable seems to act like an antenna, giving you a better connection. I've not done any tests to see exactly how much you can get, but I get at least another 10'.
I'm thinking about opening up the controller and soldering an antenna to the usb enclosure. If I do that, I'll post instructions/video.
I'm thinking about opening up the controller and soldering an antenna to the usb enclosure. If I do that, I'll post instructions/video.
Monday, June 22, 2009
Quick post on working with large changes across your codebase
Stuff I wrote up for work. Ignore the p4 part, assuming you use a real version control system, *cough* git.
Strategies for making changes that affect a large number of files
emacs:
- recursive editing (C-r, C-M-c)
- find-grep-dired
- ibuffer (Used to save large number of buffers at once)
- dired-do-query-replace-regexp (find-replace across marked files in dired buffer)
shell:
- grep -rIl 'pattern' * > files_to_op_on (that's a capital i and a lowercase L)
- grep option -r: recurse
- grep option -I: (capital i) exclude binary files
- grep option -l: (lowercase L) Show only filenames with matching content, no other output.
- grep option -h: don't include filename in the match line.
- cat files_to_op_on | xargs sed -i backup_extension 's/old/new/g' #Note that bsd sed required a backup extension with the -i argument.
- cat files_to_op_on | xargs p4 edit
Watch out for symlinks! If you get them in your changelist, p4 won't accept submit, in which case you'll need to delete them via p4 change.
p4 submit > /dev/nullworks well to just get the errors.
The general pattern of:
grep -rI 'something' * | sort -ucan show you the variations you'll need to fix. If you want to get rid of leading whitespace in your results, try piping through:
sed -E -e 's/^[[:space:]]+//'
Saturday, March 7, 2009
Clojure, Frozen Bubble, and how I learned to start worrying about my math education
So, I've been playing around with Clojure, reading the rough cut of Programming Clojure, (good book, so far), and was looking for a project to sink my teeth into in order to really get a feel for the language. Frozen Bubble, aka Bust A Move, has long been a favorite game of my wife, and while I tend to lose to my coworkers, should be interesting to implement.
Using a sample implementation of snake from the book as a template, I start hacking on the code, striping out all the snakey stuff, and just getting a minimal program that just displays a window. So, Frozen Bubble has only two real game objects: your target pointer, which ranges from -90 to +90 degrees, (a little less actually, no sense firing horizontally), and bubbles, which are in one of three states: not moving while in the initial position at the center of the bottom of the screen, stuck to the top of the game area (directly or via a chain of bubbles), and moving from the bottom of the screen to the top.
Well, the first state is easy, the third state is probably the same, but the second state has some unexpected complexity. First I think I'll give the bubble a location and direction, and handle the speed via the game tics. Seems reasonable, right? Then I run smack into something that makes me wish I had paid more attention in math class. The bubble has a direction, expressed in degrees, which I need to use to manipulate the location, which is expressed as [x,y].
Being a proper little reductionist, and stubborn enough to try to figure it out for myself instead of spending five minutes with google, I decide to think about the second simplest case, a 2x2 grid of pixels. (The simplest would be a single pixel, and I don't see how that would help at all. Perhaps I'm just not being clever enough, though.)
Anyway, this setup gives us the following:
Starting point: [0,0], 0 degrees (straight up or North) -> [0,1], 90 degrees (right or East) -> [1,0], and 45 degrees (NE) -> [1,1]
This says to me that if I want to work in single pixels, I have to do it in 45 degree increments. Not satisfactory. I can approximate closer and closer angles by using a larger grid, (why do I feel like this leads to calculus?) But that means that I'm not working with single pixels anymore.
I went and read some things at Better Explained, which while fascinating in their own right, (I love that site), didn't seem to help matters. I think the gap is that the actual position in real space would be floating point (well, kinda), but the game space in measured in integers (pixels).
Grabbing my trusty graph paper, I start diagramming. A 3x3 grid only buys me two new angles: 22.5 and 67.5. 4x4 gives me 0, 15, 30, 45, 60, 75, & 90.
I now have:
2x2 = 4 squares = 3 angles
3x3 = 9 squares = 5 angles
4x4 = 16 squares = 7 angles
5x5 = 25 squares = 9 angles, etc.
which generalizes to: AxA = A**2 squares, and 2A-1 angles
So to represent all 90 degrees, (which is actually kind of arbitrary anyway), I solve for 90 = 2A-1 = 45.5 squares to a side. My screen resolution on my laptop is 1024/768, so using the height as a guide, if I want to update to bubble position by individual degrees, I can only do it ~16 times from the bottom to the top of the screen. Clearly less than ideal, some sort of approximation is called for.
There are two ways that I can think of to do this off the top of my head for a 2x2 grid update: splitting the difference evenly, (i.e. a 20 degree angle will be bumped up to 45, or it can be rounded to the closer number, in this case 0. The rounding case seems more rational.) Obviously I want to stagger the updates to get the closes approximation to the actual angle I can, but a constraint I'm operating under is to have no other state saved between updates than location and direction. Ummmm.....
The only option I can see is to manipulate the direction each time so that after ~45 pixels, it arrives in the correct place. However, my laptop battery is about to die, and it's late, so I think I'll sleep on it and continue this later.
Using a sample implementation of snake from the book as a template, I start hacking on the code, striping out all the snakey stuff, and just getting a minimal program that just displays a window. So, Frozen Bubble has only two real game objects: your target pointer, which ranges from -90 to +90 degrees, (a little less actually, no sense firing horizontally), and bubbles, which are in one of three states: not moving while in the initial position at the center of the bottom of the screen, stuck to the top of the game area (directly or via a chain of bubbles), and moving from the bottom of the screen to the top.
Well, the first state is easy, the third state is probably the same, but the second state has some unexpected complexity. First I think I'll give the bubble a location and direction, and handle the speed via the game tics. Seems reasonable, right? Then I run smack into something that makes me wish I had paid more attention in math class. The bubble has a direction, expressed in degrees, which I need to use to manipulate the location, which is expressed as [x,y].
Being a proper little reductionist, and stubborn enough to try to figure it out for myself instead of spending five minutes with google, I decide to think about the second simplest case, a 2x2 grid of pixels. (The simplest would be a single pixel, and I don't see how that would help at all. Perhaps I'm just not being clever enough, though.)
Anyway, this setup gives us the following:
Starting point: [0,0], 0 degrees (straight up or North) -> [0,1], 90 degrees (right or East) -> [1,0], and 45 degrees (NE) -> [1,1]
This says to me that if I want to work in single pixels, I have to do it in 45 degree increments. Not satisfactory. I can approximate closer and closer angles by using a larger grid, (why do I feel like this leads to calculus?) But that means that I'm not working with single pixels anymore.
I went and read some things at Better Explained, which while fascinating in their own right, (I love that site), didn't seem to help matters. I think the gap is that the actual position in real space would be floating point (well, kinda), but the game space in measured in integers (pixels).
Grabbing my trusty graph paper, I start diagramming. A 3x3 grid only buys me two new angles: 22.5 and 67.5. 4x4 gives me 0, 15, 30, 45, 60, 75, & 90.
I now have:
2x2 = 4 squares = 3 angles
3x3 = 9 squares = 5 angles
4x4 = 16 squares = 7 angles
5x5 = 25 squares = 9 angles, etc.
which generalizes to: AxA = A**2 squares, and 2A-1 angles
So to represent all 90 degrees, (which is actually kind of arbitrary anyway), I solve for 90 = 2A-1 = 45.5 squares to a side. My screen resolution on my laptop is 1024/768, so using the height as a guide, if I want to update to bubble position by individual degrees, I can only do it ~16 times from the bottom to the top of the screen. Clearly less than ideal, some sort of approximation is called for.
There are two ways that I can think of to do this off the top of my head for a 2x2 grid update: splitting the difference evenly, (i.e. a 20 degree angle will be bumped up to 45, or it can be rounded to the closer number, in this case 0. The rounding case seems more rational.) Obviously I want to stagger the updates to get the closes approximation to the actual angle I can, but a constraint I'm operating under is to have no other state saved between updates than location and direction. Ummmm.....
The only option I can see is to manipulate the direction each time so that after ~45 pixels, it arrives in the correct place. However, my laptop battery is about to die, and it's late, so I think I'll sleep on it and continue this later.
Wednesday, November 19, 2008
Nice trick with functools and os.path.join
Sometimes os.path.join('something', 'something_else', 'more' ... ) gets old. With functools.partial, you can preload os.path.join to clean up your code. For example:
import functools
my_path_plus = functools.partial( os.path.join, 'a', 'b', 'c')
m = my_path_plus('x', 'y', 'z')
# m is 'a/b/c/x/y/z'
n = my_path_plus()
# n is 'a/b/c', for when you don't want to add anything.
import functools
my_path_plus = functools.partial( os.path.join, 'a', 'b', 'c')
m = my_path_plus('x', 'y', 'z')
# m is 'a/b/c/x/y/z'
n = my_path_plus()
# n is 'a/b/c', for when you don't want to add anything.
Subscribe to:
Posts (Atom)