Day 0 – Preparing for the Coast to Coast walk



Preparations

The Coast to Coast walk across England is one of the most popular long distance treks in the country. Popularized by the famous walker and author Alfred Wainright in his 1973 book of the same title, the route crosses the beautiful countryside of northern England. Starting at St. Bees on the Irish Sea, it covers some 200 miles, crossing the Lake District, the Yorkshire Dales and the Yorkshire Moors to end at Robin’s Bay by the North Sea.

Several members of our local hiking club had done the Coast to Coast walk as part of a guided tour in previous years and recommended it highly. Their reports piqued our interest. It was Chris who finally committed to doing the trip in early 2011 as a self-guided trek. Three of friends from the UK wanted to do the trip too. When he asked if Bob, Sassan and I were interested in joining, we naturally said yes!

The first major challenge was to settle on an itinerary. Chris had a good guidebook and after some consultation we elected to split the trip up into 14 stages. This meant that each leg of the trip was between 9 and 20 miles. Based on everyone’s availability, we scheduled the journey for the last two weeks of June. This also corresponded with the guidebook indicated was the best time for walking, weather-wise. Plane tickets and transportation to and from the starting point also took time to arrange. In retrospect we would have done better booking in March rather than in early May (plane ticket prices increased substantially in the interim).

Michelle booked accommodations in February for the UK-based contingent. Since each leg of the journey was between small towns or villages, we had a choice of (in order of price) B&Bs, youth hostels, bunkhouses (exactly what they sounded like) and camping. Owing to the famously wet weather, we ruled out camping except as a last resort. I didn’t book accommodations for Bob, Sassan and myself until the beginning of May, so we didn’t have as many choices as M, but between B&Bs, hostels and bunkhouses, I found a spot for every night, and all but two nights in the same town as the rest of the group. Prices varied, but the usual price for a double-occupancy room in a B&B was around £60 (including breakfast).

The other important bit of logistics was arranging luggage transport. There were several services for taking luggage from one stopping point to the next, allowing you to only carry a light daypack throughout the trek. You provide them your itinerary, and they take care of the rest. We used the Coast-to-Coast Packhorse, and the service proved invaluable. No, it wasn’t cheap, but being able to have several extra sets of dry (and clean) clothes handy throughout the trip was more than worth the cost. The only catch was that we had to make sure that our luggage was packed and ready for pickup by 9AM each morning.

The luggage transport made packing quite a bit easier. Aside from good waterproof clothing and good boots, we didn’t really end up needing any special gear for the walk. I did forget my gaiters, which proved an unfortunate oversight, though I managed to get a second-hand pair in Keld. We met with more than our share of rainy weather though, which made the raincoat, rain pants, and thick boots quite essential.

I largely overlooked the issue of maps, which didn’t matter too much as Chris and Mark had things well covered. Still, if I were to do the trip again, I would probably bite the bullet and purchase the set of eight 1:25000 Ordinance Survey maps covering the route. The OS Strip maps that I bought were sufficient, but didn’t provide much context beyond the route, and weren’t nearly as detailed. Because the Coast to Coast route is largely unmarked, it is also essential to have a good guidebook. Chris had two of which Martin Wainwright’s ‘The Coast to Coast Walk’ was the more complete. A GPS, while not essential, is certainly handy. What with the unpredictable weather particularly in the rugged Lakes District, it isn’t hard to get lost.

Lightroom oddity

Lightroom CPU usageAdobe Lightroom is pretty much the de-facto standard for DAM (digital asset management) and bulk editing among professional and serious amateur digital photographers. As a heavy user since the beta of version 1 in mid-2006 (we are currently at version 3.4), I can appreciate why that is. Lightroom offers a reasonably intuitive well-designed interface for editing and organizing large numbers of images. It has a number of minor flaws, but it compares favorably to pretty much every competing software package I’ve tried.

That said, from an architecture point of view, it seems that Lightroom could stand some improvement. My basic complaint is that the software is sluggish. Not tear-your-hair out slow mind you, but lethargic enough to be annoying. And this is when dealing with 12MP RAW image files, on a machine that has 4 2.8GHZ cores and 6GB RAM. That is to say image sizes aren’t that large, and the hardware is pretty current.

Continue reading

Leaker: a simple C leak detection example

Following up on my previous post, I’ve posted right below an actual working example of a simple C leak detector. It pretty much follows the outline given in that post. There is a global table to keep track of allocations and deallocations. Anything left in the table at the end of the program is known to have been leaked. By recording filenames and line numbers as well as memory addresses, the table makes it possible to know exactly where leaked allocations were made.

Leaker code. ~180 lines of ANSI C.

Continue reading

Olympux XZ-1 – A Serious Compact Camera?

Olympus XZ-1

I’ve been looking, on and off for a serious compact digital camera for quite some time. It’s not that I’m unhappy with my DSLR, but I have developed a certain lack of enthusiasm for carrying it everywhere. The DSLR is large, heavy and obtrusive. People notice me carrying it. I notice me carrying it. For quality, it can’t be beat, but for activities where photography is the primary goal, it often seems like overkill.

My search began in earnest after a couple of trips last summer where I was forced to put the camera away in the pack to keep it from interfering with climbing. While this helped with climbing, it also meant that I missed photographing a number of interesting moments.

Continue reading

Disk I/O in C – avoid fgetc/fputc

Most programs don’t do that much disk I/O. But for those that do, the disk I/O is often the bottleneck. I discovered this firsthand working on my Huffman tree encoding program. On small data files, it doesn’t matter much how you read or write your data, but when the filesizes get into hundreds of megabytes, implementation makes a big difference.

The 3 basic C functions for reading (and writing) unformatted text files are fgetc/fputc, fgets/fputs, and fread/fwrite. fgetc reads in one character at a time, fgets one line at a time and fread some number of ‘records’ at a time. As a record is just a sequence of bytes of a defined length, what fread really let you do is read in data in chunks whose size are recordsize * number of records. The respective put/write functions do the reverse.

Continue reading

Detecting Memory Leaks in C

Memory leaks are a common occurrence in C programs, particularly for novice programmers.  Because memory allocation and deallocation is left to the programmers, it’s not difficult to lose track of what was allocated where, and forget to deallocate it once it is no longer in use.  The is particularly true for more complex data structures which may have dynamically allocated blocks of memory that reference other dynamically allocated blocks of memory.

There are a fair number of tools to deal with this, like valgrind.  Still, building a simple detector is a relatively straightforward exercise, and can often reveal interesting things.

Continue reading

Installing Android x86 in a virtual machine

Ever wanted to play around with Android, without actually buying an Android phone? Thanks to the Android x86 project you can. While Google only officially supports the ARM platform, a group of volunteers has ported it to x86. What’s more, it runs more or less seamlessly inside a virtual machine, so there’s no danger of accidentally messing up your main system.

The process is pretty straightforward.

android.jpg

Continue reading

Programmer vs. Computer Time

I’ve always been predominantly a C programmer, mainly simply from habit. However, recent projects using Perl have me thinking about the tradeoffs involved. The big issue seems to be time – both at the programmer’s end and at the computer’s.

C compared to languages like Java or Perl generally offers greater flexibility and performance. On the flip side, it makes programming tasks more complex and debugging more difficult. C requires more time from the programmer, in order to minimize time spent running on the computer. Higher-level languages on the other hand, require less from the programmer, at the expense of longer run-time.

Continue reading

C – not a good starting language

In most computer science programs, the first course in the sequence is a basic programming course. Usually, this course introduces the standard concepts, along with one of the more common programming language. And at least from what I’ve seen, that language is usually C.

From what I’ve seen in the classes I’ve taken, and particularly from what I’ve seen tutoring at the college this quarter, this is a mistake. Don’t get me wrong, C is a great programming language. I learned on it. I like it. I use it regularly. But as a first programming language for beginning students it leaves a lot to be desired.

Continue reading

Finding Memory Errors in C

Memory errors are among the nastier programming mistake one can make when using C. Unlike syntax errors, the compiler doesn’t flag them for you. Unlike basic logic errors, you won’t necessarily see the problem in the output. The result – silent data corruption – usually manifests itself differently under different systems and compilers which makes it especially obnoxious to deal with.

Fortunately, there are a couple of good tools for debugging memory errors. My favorite is valgrind, a memory debugger modeled after Rational’s purify (the commercial standard) that runs on Linux and now (experimentally) on MacOS X.

Continue reading