geek + red sox + cooking = peter ryan

I recently upgraded my TortoiseSVN installation to 1.5 and as a consequence needed to upgrade my Visual SVN install for visual studio to 1.5.1. I received an unexpected error when upgrading Visual SVN - it claimed it needed the Visual SVN 1.3.2 (currently installed) msi to install 1.5.1. This felt really lame and as I had no local copy was also obnoxious).

Visual SVN does not provide easy links to old versions of VisualSVN but they do provide access. Based on the download link for Visual SVN 1.5.1 I inferred the 1.3.2 link:

http://www.visualsvn.com/files/VisualSVN-1.5.1.msi

http://www.visualsvn.com/files/VisualSVN-1.3.2.msi

Also it looks like when I installed Visual SVN I did so directly from a firefox download I must have done twice as the installer claimed it was looking for VisualSVN-1.3.2[1].msi. When I passed it the downloaded file it claimed it was not the correct one so I renamed Visual-SVN-1.3.2[1].msi and the error went away.

There is a lot of strangeness with Visual SVN / Tortoise SVN. Another time when I upgraded to Tortoise SVN I had to shutdown Visual Studio, Outlook, and Firefox.

The VisualSVN Setup also spends a lot fo time “Updating Visual Studio settings” but as far as I can observe from the task manager does absolutely nothing but wait.

That along with the TortoiseSVN forced reboot makes the entire upgrade process for Tortoise/VisualSVN really obnoxious.

A few weeks ago I was making a sandwich lunch and instead of your typical chips side decided to make a quick pasta primavera. Lately I’ve been chopping veggies for snacks so I had plenty of vegetables handy. My sister Kristen got wind of it and requested it for our 3rd of July party. Primavera can be as complicated or as easy as you wish. Mine is easy and has an emphasis on quick as well.

Ingredients

• Two to Three Carrots
• Head of Broccoli
• Half bag of frozen peas
• Half pint of grape tomatoes
• 8oz Farfalle
• Olive oil and Extra Virgin Olive Oil
• Salt and Pepper

Preparation

The bulk of the work is chopping.

• Dice the carrots.
• Cut off the florets from the broccoli head into bite size pieces. I discarded the stalks.
• Halve the grape tomatoes

Steam the broccoli and peas. We will be sautéing them later so its not necessary to cook them completely. I probably steamed them for 3-4 minutes each.

Salt and boil water in a pot sufficient for cooking the pasta. Cook according to the package directions.

While the water is boiling heat a saucepan to medium heat and add a couple tablespoons of olive oil or vegetable oil over medium heat. When the oil has heated add the carrots and lightly sauté for a minute or two. Next add the tomatoes (raw) and the partially cooked broccoli and peas. Toss lightly and let the vegetables sauté cook for about 5 minutes. Adjust the heat as necessary - you do not want the vegetables to burn and you should hear a light sizzle with the oil in the pan. Also during the adding of the vegetables season with salt and pepper as desired.

When the vegetables have cooked lower the heat to low until the pasta is ready. Hopefully the two will occur at the same time. Drain the pasta.

Combine the pasta and the vegetable saute with alternate scoops from your colander and saute pan into the pasta pot. Stir the pot after each scoop and add extra virgin olive oil and seasonings with every other scoop to taste. When all the ingredients have been combined lightly toss and let sit in the pot for a few minutes. This will let the primavera cool and also allow proper coating of the oil and seasoning with the pasta and vegetables.

Serve immediately warm or wait and serve chilled as an alternative to a heavy mayo pasta salad.

The above should serve 2-4 as a side. The ingredients would easily scale up and proportions of vegetables to pasta (and indeed adding any other veggies like zucchini, mushrooms, etc) would be easy and great depending on what you feel like.

I have had this recipe immediately and later and preferred it fresh so if you can serve it as closely as possible to when it is cooked!

I just spent at least 10 minutes trying to determine the exit code for a command just executed from the command prompt. This seems like an overly simple thing to do but one that is not very well documented. The answer is to use the errorlevel environment variable.

runMyCommand.exe


After completion…

echo %errorlevel%


displays the actual code returned by the process.

Interesting doing a SET does not display this environment variable.

Lately I have been working on implementing an acceptance testing stack using the following:

• PyFit
• FitNesse
• IronPython

I wasn’t the first person to try PyFit on IronPython and based on this suggestion we have switched from vanilla Iron Python to the Iron Python Community Edition for its almost out of the box compatibility with PyFit.

Anyway I ran into the following ERROR when using PyFit with Iron Python. Preparing a test runner as so:


Environment
IRONPYTHONPATH=c:\tools\pyfit\fit


import sys
import fepy
fepy.install_option('ast')
from fitnesse.FitServerImplementation import TestRunner

Causes the FitServerImplementation not to be found:


FitNesse cannot be started...
Port 80 is already in use.
Use the -p command line argument to use a different port.
Traceback (most recent call last):
File test_runner.py, line 4, in Initialize
File , line 0, in __import__##4
ImportError: No module named FitServerImplementation

This is unexpected because I am not trying to launch FitNesse and PyFit is on the IRONPYTHONPATH. What I discovered was that instead of using the IRONPYTHONPATH which essentially appends PyFit inserting PyFit at the beginning results in a correct PyFit resolution.


IRONPYTHONPATH= #No PyFit Reference


import sys
import fepy

fepy.install_option('ast')
fitpath = "PathTo/PyFIT/fit"
sys.path.insert(0, fitpath)

from fitnesse.FitServerImplementation import TestRunner

Now the TestRunner (or whatever PyFit class be it a fixture, runner, etc) is found. I am not sure why this is the case (my ignorance of python / iron python doesn’t hep) and would appreciate any insights.

In Ubuntu I accidentally tried connecting to a wireless network. After that every time go near it now the Gnome network manager would connect to it. There is no handy way that the manager lists of “allowed” networks can be managed. After some digging I found the solution - removing a directory that made it “preferred” and restarting networking. After that the manager no longer did an auto connect.

cd .gconf/system/networking/wireless/networks/
ls
rm -rf <essid>


I was reading John Hume’s to_proc blog entry. Much like he said I hadn’t seen the extension and immediately liked it’s readability.

On my ubuntu machine I use scripts to dial into verizon evdo. Lately I haven’t been connecting as reliably as I had been and I was spending a lot of time dialing, looking at the system log.

Interested in trying out the extension and also more interested in setting up an autodialer I started working on an intelligent verizon pppd script. It’s not done yet (I’ll post more when it is fully flushed) but I did use the to_proc.

def call_evdo
  IO.popen("pppd call 1xevdo")
  sleep 10
end

10.times &:call_evdo

I like the readability thanks to the to_proc extension. Right now I am working on monitoring /var/system/log for the IP address / error and redialing / binding the default gateway. I’ll keep this blog updated with progress and eventually an autodialer script.

I recently pulled about 6 months of photos from my camera. To my aghast I realized that I had mistakenly set the clock a year early so all of the photos had the correct date on them except for the year which was 2006 instead of 2007. This was really annoying in Picasa which uses the date of the photo in the exif header to order photo albums.

In order to fix this I need to update the EXIF file for each JPEG. What I really needed was a date shift since most of the dates I was using were fine. I did some digging around and found ExifTool by Phil Harvey that will let me modify an EXIF file, in particular ExifTool will perform a date shift on a group of photos - probably for morons like me who can’t properly set their camera date or accidentally check in a hard coded test URL.

ANYWAY I had quite a few photos to process and some of the photos (first half of 2007) that were correct. So I wrote a script that did the following:

1) Check the EXIF create_date for 2006.
2) If 2006 shift the date forward one year
3) confirm and delete the backup “original”

Here is the subsequent ruby script. It isn’t very pretty as this was a one off operation.

shift_year_forward_to_2007_if_2006.rb

#!/usr/bin/env ruby
require 'date'

def create_year(photo)
  command = "exiftool -CreateDate #{photo}"
  read_process = IO.popen(command)
  output = read_process.readline
  read_process.close
  Date.parse(output.split[3].gsub!(":","-")).year
end

photos = Dir[File.join('**/*')].select do |path| path.upcase.include?("JPG") end
photos.each do |photo|
    if create_year(photo).eql?(2006)
      puts "Attempting to Shift #{photo}..."
      modify_process = IO.popen("exiftool \"-AllDates+=1:0:0 0\" #{photo}")
      modify_process.close
      File.delete("#{photo}_original")
      if create_year(photo).eql?(2007)
        puts "Verified!"
      else
        puts "Error on #{photo}"
      end
    else
      puts "Ignoring #{photo}"
    end
  end

After a few weeks of trying Compiz Fusion on my Kubuntu Gutsy laptop I have returned to using the standard KWin window manager. My reasons for this were:

• Buggy decorators. After running for a short period of time with compiz the windows decorators (maximum, minimize, close, resize, etc) stopped appearing.
• Tray icons not loading correctly. When I booted my laptop and immediately logged in a few of the system tray icons (PowerManager for one) would not load in the tray but instead be running on the top left of the screen. Restoring to kwin would cause this issue to go away.
• Occasionally on login the keyboard would not be functional. This was resolvable by logging out with the mouse and logging back in.

Overall I liked the effects but couldn’t handle the issues and not being a kde developer didn’t feel like sifting through bug reports and trying to tinker with the window manager. I setup my compiz fusion configuration according to the help.ubuntu.com’s instructions.

Today I was experimenting with Advanced Desktop Effects for Kubuntu Gutsy. I set them up easily enough. I first removed everything I had installed before (legacy beryl) and reinstalled CompizFusion according to the ubuntu help documentation.

Everything installed fine but I ran into a troubling issue. I was looking at the list of activated plugins and trying to get a handle on everything (including what the super key is…I still have no idea but I’ll figure it out soon enough) and after playing with the “Move window plugin” which was tied to ALT-F7 I said “that is cool but I’ll never use it…I’ll just drag the window around with my mouse” and disabled it.

Anyway that behavior was opposite of what I was expecting. The compiz desktop effect was also the base move window action so disabling it made it impossible to move any windows at all. I re-enabled it and moving windows (with the mouse) once again worked as expected.

I suspect that other effect “plugins” behave similarly so when playing with desktop effects be careful what you disable! IMHO a window manager’s core functionality includes things like “move window” “resize window” and treating them like plugins as opposed to core elements is an extreme that could lead an unaware user down a road that disables features that one might view as critical. That said there are things like “Application Switcher”, “Ring Switcher”, and “Shift Swticher” all of which are different ways to switch between windows. So I guess one could deliver an alternate “Move Window plugin.”

At some point after I completed my Feisty to Gutsy upgrade I discovered that whenever I ran a perl module (whether it was when I was reinstalling vmware or running aptitude) I received the following warning:


perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory


I ran across the following ubuntu forum thread and executed the following two commands to clean up the broken locale:


sudo locale-gen
sudo dpkg-reconfigure locales


That resolved the issue and the perl warnings disappeared when I ran aptitude again as a smoke test. I am not sure what could have caused this corruption as the thread is dated. The issue might not be gutsy upgrade related but it is likely the culprit as I have done little on my machine in terms of config changes beyond it.