Monthly Archives: September 2012
After the weekend’s high of singing Mahler, it was down to Earth with a bump today, as I found myself doing battle with the Macbook and Apple’s UK operations.
It started when it didn’t start, so to speak. That is to say, the laptop screen remained resolutely blank, no matter what I did. In other matters the machine seemed OK: turning it off and then powering up gave the characteristic startup sound and the disc spun into motion, but nothing on the screen.
Shining a bike light on it close up revealed the faint apple logo, indicating that it is in fact the backlight that failed (dammit, why can’t I get a laptop with e-ink screen?) And given that for a few days I’ve had intermittent issues with it going blank when adjusting the screen angle, it seems likely to be a connection that’s at fault.
In a desktop context I would of course expect to identify and fix or replace the faulty component fairly easily. In a laptop, my reaction is to take it to the professionals and hope they can do something within the bounds of my bank balance. So I googled for Apple UK store. That got me their online store, but no hint of a store locator! I know there’s a store in Exeter, but even typing “Exeter” into Apple UK’s search box drew a blank.
Come on Apple. What’s the use of physical shops if you won’t tell us how to find or contact them?
Phoning Apple UK’s number from the site got me eventually to a human. He started by insisting on my serial number, then told me in accusatory terms that the computer belonged to someone completely different. A nasty moment was resolved when it turned out he’d misheard a single “B” as “D”, and Apple’s database does indeed list me as owner of my macbook. But isn’t it alarming that valid serial numbers should differ only by something so easily confusable? If the other machine had been reported lost/stolen, they could’ve been accusing me of theft!
Having got through that, the man was friendly and helpful enough, but couldn’t answer my question: whether it would be worth my while to take it to an apple store. I mean, if they can fix it for £50 then great – well worth the time and trouble of taking it in. But if they charge £50 to tell me they can’t do anything – or that they would charge a further £500 – I should be well p***ed off. Of course he wasn’t going to diagnose it on the phone, but I’d hoped he’d at least have a feel for whether this class of problem could usually be fixed or whether I was wasting my time.
He did give me a phone number for a Plymouth store called Stormfront, which is my nearest Apple dealer. Phoning that number got altogether more bizarre. Their menu tells me to select one of just two options, but after selecting either option, nothing happens. Until, after about a minute, a tone indicates the call has died. Googling the Plymouth store found a second ‘phone number, but that got me exactly the same thing. Seems the Plymouth store isn’t contactable: so much for their technology! I’ve emailed them, but no great expectation of that going anywhere more productive than the ‘phone.
Should I just try and fix it myself? If it’s anything like a loose connection, I’m in contention for the world’s worst person with a soldering iron. Unfortunately I don’t know how much I’ve got to lose (or rather, to gain compared to writing it off by taking it to someone competent). Bah, Humbug.
The next concert I’m singing in is Mahler’s 8th symphony – the Symphony of a Thousand. It’s Sunday Week (September 16th) at 5pm, in the Great Hall of Exeter University.
For obvious logistical reasons, this symphony isn’t often performed, so when the chance came my way I grabbed it! The group and the venue are new to me, being a bit too far away to travel for a regular evening out. Rehearsals have been a series of weekend workshops, of which this weekend will be the last before that of the concert. I’ve enjoyed it so far, and I confidently expect to enjoy the final weekend and concert. For readers in or not too far from Exeter, it should be well worth coming to see, too!
Some people engage in Holy Wars over what source control system to use. For my part I really can’t get too worked up over a choice of tools, but I am concerned about another question. What files do you keep in a source control repository?
I’d like to say source files. Program source files, inputs for your choice of build system, legal stuff like licenses and acknowledgements, matters of record, documentation. The key point is, files that are rightfully under the direct control of project members. Not files that are generated by software, or managed by third-parties.
In practice, this principle is all-too-often lost. One example is Apache HTTPD, whose source repos contain extensive HTML documentation that is not written by developers but generated from XML source. There’s a clue in the headers of each of these files:
<!-- XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX This file is generated from xml source: DO NOT EDIT XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -->
So these files are not source, and should really be generated in the build (or made a configuration option) rather than kept under source control. But apart from raising the overhead of using the repos, they’re harmless.
I’ve recently come upon an altogether more problematic case. It manifested itself after I’d installed all the prerequisites for a configure to succeed, but found my build fell down in compiling something. Scrolling up through reams of error messages, I find at the top:
#error This file was generated by a newer version of protoc which is #error incompatible with your Protocol Buffer headers. Please update #error your headers.
OK, that’s simple enough: the version of google protobuf I installed with aptitude is too old. Go to google and download the latest (cursing google for failing to sign it). And hack protobuf.m4 to detect this error from configure rather than fall over in the build.
But hang on! It’s not as simple as that. This isn’t the usual dependency on a minimum version: it’s a requirement for an exact version of protobuf. If I install a version that’s too new I get another error:
#error This file was generated by an older version of protoc which is #error incompatible with your Protocol Buffer headers. Please #error regenerate this file with a newer version of protoc.
Altogether more problematic. Nightmare if I have more than one app each requiring different protobuf versions. And this is a library I’m building: it could be linked with somesuch. Ouch!
The clue is at the top of the file that generates the errors:
// Generated by the protocol buffer compiler. DO NOT EDIT! // source: [filename].proto
This C++ is not source, it’s an intermediate file generated by protoc, which is part of the protobuf package. Its source is the .proto file, which is also there in the repo but not used for the build. It follows that hacking protobuf.m4 to test the version was the wrong solution: instead the build should be updated to generate the intermediate files from the .proto source.