Valentine1 a great example of customer service

About seven years ago after getting yet another speeding ticket, I sat across the table from my attorney at breakfast meeting one morning. I was inquiring to see if he knew anyone in a remote part of the country that could assist me with my legal traffic woes. It was in that moment he said, "you want my advice? get a Valentine1!"

So I did.

Granted, it was expensive compared to the other brands out there. It’s selling points were pretty clear. Well designed, detects pretty much anything they can throw at you, and was fairly invisible to the K40 radar detector detectors.

After some seven plus years, covering hundreds of thousands of miles on the road– The Valentine1 has been flawless.

…until last week, it suddenly started to see ghosts.. signals from everywhere around ever turn. Immediately, I checked for support on the website, which led me to believe I did in fact have a problem. I called the customer support line who reiterated what the website confirmed. Something was amiss.

Some $12 later, I had shipped the unit back to Ohio for repair. Feeling separated from a trusted part of the family. I waited for word…

…a week went by and FedEx arrived.. returned my Valentine1 returned to perfect function. Despite being loved for many years… and well used… the repairs were made at no cost and return shipping paid.

I must say that, I was fully prepared to pay the $45 diagnostic fee and reasonable repair charges, and had all been hopeless I would have found a way to buy a new one. But instead, Valentine1 exceeding all my expectations did the right thing to maintain their position in the marketplace as the high quality radar detector.

Thank you Valentine1 not only for an exceptional product but also for providing exceptional customer service!

How to fix mach-o, but wrong architecture on OSX Snow Leopard for Ruby Gems Bundle Files

Ran into the annoying mach-o problem for compiled rubygem extensions on a few gems (mainly RedCloth and CSVScan). First pass at Google rendered a few people who had experienced similar problems but no real solutions. Finally broke down and figured out how to fix it.

First, what is the problem; in the land of OSX you have many architectures this includes the old PowerPC world, 32-bit (i386), and 64-bit (x86_64). In the old world everything was always 32-bit and nobody was the wiser, but with Snow Leopard the world changed and suddenly you could run things in 64-bit. So here’s the rub, 64-bit and 32-bit dont play nicely together. They are consider different architectures and even as Apple has done a great job to provide 32-bit emulation when you have a 64-bit app that tries to access a 32-bit library or vs versa things stop working.

The fix is pretty simple, figure out what architecture your primary application is, then re-compile the library to comply. This error pops up usually as a “mach-o, but wrong architecture” error. And this is true across all languages but in this case I will explain how I fixed my rubygems that had incompatible bundle files.

Step 1: Identify which architecture you need. This goes both ways, if you have a 32-bit app with a 64-bit library you need a 32-bit library to run. If you have a 64-bit app with a 32-bit library you need a 64-bit library. Easiest way is to use the “file” command. If you dont mind larger executables you can compile all architectures in, but this wastes space. Below see a few examples.

prompt$ file /usr/local/bin/ruby
/usr/local/bin/ruby: Mach-O executable i386


$ file /bin/ls
/bin/ls: Mach-O universal binary with 2 architectures
/bin/ls (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/ls (for architecture i386): Mach-O executable i386

In the case of RedCloth, removed the 64-bit bundle;
$ sudo /bin/rm /usr/local/lib/ruby/site_ruby/1.8/i686-darwin9.5.0/redcloth_scan.bundle

$ cd /usr/local/lib/ruby/gems/1.8/gems/RedCloth-4.2.2/ext/redcloth_scan/

Now you can edit your Makefile to include the ‘-arch i386’ or ‘-arch x86_64’, once again you can add one or both. For some reason most of the gem builds scripts don’t account for what version of ruby you run and default to 64-bit which is where the problem originates.

Edit your CFLAGS and ldflags or archflag and just add ‘-arch i386’ or ‘-arch x86_64’ to the lines. Run a make clean; make … then go back to the root of your gem and run the ruby setup.rb install. Make sure you dont re-run config as this will overwrite your Makefile changes. This will install your new bundle and you should be ready to go.