Monday
May112009

Setting up a Subversion (SVN) server on Bluehost

Subversion is my choice for version control and document repository.  I use it for code, proposals (funding, observing, etc.), papers, etc..

Some quick advantages are:

  • Easy syncing between machines.  (This is little less relevant on a day-to-day basis now that I use my laptop as my primary computer, rather than switching back and forth, but it still useful for distributing code among number crunching computers and keeping everyone up-to-date.)
  • Automatic off-site backups (because I keep the repository on a Bluehost account).

A few disadvantages are:

  • Does not play well with Apple's iWork file formats (which are actually directories with files that can appear/disappear somewhat randomly).  (BUT, note that as of 2009-05-10 I read that the latest iWork applications now save files in a format that effectively zips that directory into a single file and therefore should play nicely with svn in the future.)
  • Keeps 'fresh' copy of all files in a hidden directory within your working directory.  This is how subversion can quickly tell what you've edited.  The implication of this is do not put a directory into svn that has a lot of large files that will not be changing, e.g. the directory where you keep the library of all the PDF's of published papers you've read and need to go back to.  Such a folder will be twice it's 'normal' size.

Setting up a Subversion server on Bluehost is reasonably easy, though not as easy as it could be.  (Most software is so incredibly simple to set up on Bluehost through their web tools, but subversion is currently included in their list of supported packages.)  A debt to Joe Maller for showing how to do this on his blog, with some additional help from this thread.

  1. Log in to your Bluehost server with ssh
  2. mkdir src   (if you have not already)
  3. cd src
  4. wget http://subversion.tigris.org/downloads/subversion-1.5.6.tar.gz     (or the current version number; I originally did try 1.6.2 but ran into problems)
  5. wget http://subversion.tigris.org/downloads/subversion-deps-1.5.6.tar.gz     (or the current version number)
  6. tar -xzvf subversion-1.6.2.tar.gz
  7. tar -xzvf subversion-deps-1.6.2.tar.gz
  8. cd subversion-1.5.6
  9. arch     (and confirm that is a 64 bit system)
  10. cd apr
  11. ./configure –enable-shared –prefix=$HOME
  12. make & make install
  13. cd ../apr-util
  14. ./configure –enable-shared –prefix=$HOME –with-expat=builtin –with-apr=$HOME –without-berkeley-db LDFLAGS=”-L/lib64″
  15. make & make install
  16. cd ../neon
  17. EXTRA_CFLAGS=”-L/usr/lib64 -fPIC”
  18. CFLAGS=”-L/usr/lib64 -fPIC”
  19. ./configure –enable-shared –prefix=$HOME –with-libs=$HOME –with-ssl
  20. make & make install
  21. cd ../
  22. ./configure –prefix=$HOME –without-berkeley-db –with-editor=/usr/bin/vim –with-apr=$HOME –with-apr-util=$HOME –with-neon=$HOME –without-apxs –without-apache LDFLAGS=”-L/lib64″
  23. make & make install
  24. svn –version  (to confirm everything is working)
Monday
May112009

Bluehost

A few years ago I decided I needed a hosting service for blogs, web pages, distributing files to colleagues, wikis, and a subversion server and for safety reasons wanted this to be offsite.  (My office used to be in a high earthquake zone, now it's in a high forest fire danger zone, so offsite is the only reasonable thing to do.)  I turned to Bluehost for this and have generally been happy with the service they provide.  There are a few things that have taken a little more effort to figure out than they probably should, and I've read some worrying reports online about accounts being closed without warning for violations (or perceived violations) of the ToS.  Their claim these days is "unlimited" bandwidth/storage/cpu/etc., but obviously at some point you exceed their internal limits and they cut you off.  I guess I'd prefer well-documented fixed limits and having to stay within them, rather than the uncertainty.  But, overall I've been happy.  I run a number of domains from this service (including this blog.).

Saturday
Apr112009

Reset the display & evil vertical dark striping on MacBook Pro

Discovered a useful new key combo:

ctrl-shift ejectButton

This resets the display.  Should be useful for those times when something isn't quite working.

This also got rid of the vertical striping problem that appeared on my MBP today.

Friday
Feb132009

Saving space: deleting old iPhone update packages

I just saw this nice tip about saving some disk space (1.2 gigs in my case today) by deleting older software updates for an iPhone (or an iPod).

Basically, delete everything in:

~/Library/iTunes/iPhone Software Updates
~/Library/iTunes/iPod Software Updates 

See more details at:

http://www.macosxhints.com/article.php?story=20090210105622812

Friday
Feb062009

Detecting the transit of an extrasolar planet (CoRoT-Exo-1b)

Extrasolar planets are all the rage these days, with decent reason. There's a lot of neat science to be done with them. CoRot-Exo-1b is a roughly Jupiter-mass planet orbiting a star that was discovered by the French-led COROT mission.

I was doing some engineering work with a new InGaAs infrared camera earlier this week on Lowell Observatory's 31" telescope and decided to see if we could detect the transit. The star is pretty faint for an infrared camera on a not very large telescope and the transit was only about 2%. Definitely a tricky observation that I wasn't sure would work out. (Some day I need to write a post about this camera and the projects we're planning to do with it.)

But, here's the cool thing: It did. With about 1500 images taken over 6+ hours we were able to detect the transit. (See below.)

There's no question this isn't the prettiest light curve ever and there's nothing this light curve can tell us about the host star or planet that we don't already know. So, there's no real new science here, but it's a pretty cool engineering demo of what this new camera can do. These results are just a quick-and-dirty reduction of the data. With a little more careful processing the curve would probably look some better.

exo1

To explain the various parts of the above figure:


  • Each individual open point represents the measurement from one 10 second exposure.

  • The red diamonds with vertical error bars are a binning of the individual measurements

  • The blue horizontal line is the mean of those points during those times when the planet was not transiting.

  • The magenta vertical lines indicate the start and end times of the planet transit.

  • Based on the much higher quality visible light observations of others, the deepest part of the transit should be about 2%, which is where the horizontal magenta line is. Note that the transit shouldn't be a binary "wink-off"/"wink-on" but should be a more gradual curve, but our data really aren't good enough to distinguish that level of detail.


Yes, there are a couple of binned data points between 2 and 3 UT that don't match all that well, but these data are noisy and it's not at all surprising that a few data points are off.  As I mentioned above, I did a really quick-and-dirty job here, so a little more effort might clean up this part of the light curve.

(Side note: These are 1-sigma error bars, so about one third of the points should be at least one error bar away from their expected value. I could work through some statistical arguments on this, but if about 1/3 of the points weren't off their expected values by one sigma or more you could pretty much assume either: 1. I don't understand my errors, or 2. I'm doing something wrong. By my count something like 8 or 9 of the points are off their 'expected' values by more than one sigma. There are 26 points, so that works out that about 1/3 the points are off, as one would expect. So, no clues there that there's anything drastically wrong with this analysis.)