Last month I posted about backing up metadata for your Flickr photos using a simple little Python script. That script gives you an XML file for each photo with all that photo's metadata stored inside it for ready access. If you're a recent switcher to OSX, you might want to take advantage of that data to get your photos from Flickr into iPhoto.

Once you have iPhoto and Flick in sync, you can import new photos from your camera into iPhoto and then export to iPhoto using FlickrExport and they will stay in sync. Of course you may have no interest in getting your photos from Flickr to iPhoto, in which case feel free to stop reading. In my case, while I had the photos around, they were in multiple folders on my hard drive and didn't have any tags associated with them. On Flickr I had them tagged, dates corrected, and so on. Rather than recreate that process I decided it would be easiest to take what I'd done in Flickr and push it to iPhoto.

The linked AppleScripts below were mostly what I used to accomplish this process, again in conjunction with the XML files from the script mentioned in Backing up your Flickr photo info. Now some caveats: I had never used AppleScript before when I wrote these, and my copy of AppleScript: The Definitive Guide was still in the mail. If you know AppleScript you will be aware of how quite unlike most other scripting languages it is. The scripts below are undoubtedly not in best AppleScript style, and I didn't spend any time modularizing them, so you'll see common functions in each for XML parsing and so forth.

So with that said, take them for what they are and do with them what you please. Hopefully between them they'll give you enough to make a start on whatever iPhoto library-munging project you've decided to take on.

• Copy photo "date taken" information from Flickr to iPhoto
• Copy photo metadata from Flickr to iPhoto (title, comment, keywords)
• Download photos from Flickr and import them into iPhoto
• Change YYMMDD_N titles to YYMMDD_0N in iPhoto

flickr applescript iPhoto iLife

In Windows CE 5 and earlier, each process is limited to 32MB of virtual address space. That 32MB has to hold your executable, your DLLs, everyone else's DLLs, your heap, and some other stuff. If you're on a plain Windows CE device the so-called 'DLL crunch' isn't always too bad, since the OEM only has to include what they want or need to include in the platform image. However, on a Windows Mobile device, the OEM has to include everything required to get LTK verification: Pocket Word, and all that fun stuff. That means a bunch of extra DLLs that eat into the available space in your process' slot.

In Windows CE 6, the limit was raised to 2GB, so you have much more breathing room (you are limited to 512MB of physical RAM, but still, what luxury).

So, what do you do if you're developing for pre-6 Windows CE and you run out of heap space for your application? Well, you can play some tricks with DLL load ordering, but that only gets you so far. One neat trick I rely on is what I like to call the 'LMA incantation'. It goes like this:
If you ask for at least 2MB, and you ask for it in a particular way, then CE will allocate that memory for you from the Large Memory Area. This is the area of memory above where the individual 32MB slots exist for normal processes. It's normally used for memory-mapped files (which is another way you can make use of the LMA if you need to).

Here's the incantation:

DWORD size = 2*1024*1024; // (or more)

void *p = VirtualAlloc(0, size, MEM_RESERVE, PAGE_NOACCESS);
p = VirtualAlloc(p, size, MEM_COMMIT, PAGE_READWRITE);

// optional:
#define LMA_START_ADDRESS (0x42000000)
assert(ptr > LMA_START_ADDRESS)

Now if you do this in one line rather than two, that is do the commit without the reserve, then you will get memory from your process' 32MB slot rather than the LMA, and the assert will of course fail.

This one has saved my behind on more than one project. Enjoy!

Notes:

• From the MSDN description of VirtualAlloc:
  

  In Windows CE 5.01 and earlier versions, if you call VirtualAlloc with dwSize >= 2 MB, flAllocationType set to MEM_RESERVE, and flProtect set to PAGE_NOACCESS, it automatically reserves memory at the shared memory region. This preserves per-process virtual memory.... Since CE 6.0, irrespective of the value of dwSize, kernel will always try to allocate VM in user process space. Also, user applications cannot call VirtualAlloc with shared heap address range (0x70000000 - 0x7fffffff) since this is read only for user applications and read/write for kernel mode threads.

• A recent article from CE whiz Doug Boling on CE memory architecture.

windows ce

I'm honoured to have been chosen in the first wave of beta testers to get access to the BugLabs beta. I read about BugLabs in an Engadget blog post and it sounded intriguing: "An open source, web-enabled, modular software + hardware platform."

We're not under a formal NDA or anything, but we've been asked not to disclose URLs for the various components of the beta program, and so on, which is fair enough:

By the way, please keep these links to yourself, they should all be considered confidential to the beta program. You are welcome to blog about, chat about, Twitter about, text about, email about, or send smoke signals about the beta program, but please don't share the links or SDK.

They have bug tracking, forums and a WiKi already up and running, and they made an SDK available. The SDK includes VirtualBug: an emulator for the hardware, since hardware isn't available at this stage.



They built their SDK on top of Eclipse and I have to say it's pretty slick for things being so early. The instructions to get everything up and running are also unusually polished for a beta program.

There are a few sample applications that do real things, like post pictures to Flickr with geo-tagging. Some things are still necessarily in the mock-up stage until the hardware is ready, like the camera module (which pulls pictures from file rather than an actual camera) and the motion sensor (which 'detects' motion by you typing the word 'motion' into the Eclipse console).

Still, I'm very impressed at how it looks at this point. The few questions I've had have been replied to promptly in the forums and the folks at BugLabs all seem very helpful.

I'm still getting my feet wet in the SDKs, but I'll post updates as I make progress.

buglabs

Gruber posted a link to Stephen Fry's new blog. Now I'm a big fan of Stephen Fry, and he's a good writer, but lo and behold he also happens to be a gadget freak and a Mac user to boot. I had no idea. He even had a Psion 3, one of my favourite PDA predecessors, and something I still keep around to play with now and again.

His first post is all about smart phones. Let's hope he keeps it going. I for one am already subscribed to his feed.;

So a while back, I signed up for the VMware Fusion beta. Shortly thereafter I started getting a ton of all the usual delightful varietes of spam through the address I have them. Now I use sneakemail, so the email address I gave them was actually a sneakemail alias that I set up specifically and solely for that purpose. Now that their mailing list has made it to the spammers, I can simply go into my sneakemail control panel and send that alias to the bitbucket. If you haven't come across sneakemail before, I highly recommend that you take a look. They have a free offering, but the real power is in the autoaddressing keys that you get with the paid account, which is only $2/month.

I'm surprised, and a little disappointed, that a company of VMware's stature would let their mailing lists get abused like this though.

For more C++0x fun, check out Herb Sutter's trip report for the July 2007 ISO C++ Standard meeting.

c++ programming

OnSoftware is putting out some pretty neat video podcasts right now. As a (predominately) C++ guy, I found the ones with Bjarne Stroustrup, Herb Sutter and Scott Meyers to be particularly interesting.

They're making me eager for C++0x to get here! I realize it's going to be a while though: to my knowledge, Microsoft still haven't said when Visual C++ will have TR1 support, never mind C++0x. I can live with getting my shared_ptr fix from the the Boost libraries for now, but having shared pointers fully and officially in the language, along with things like lambda functions, will certainly make life easier.

Note that you can get TR1 now from Dinkumware, and they'll likely be first to put out proper C++0x support once it's ratified (fingers crossed for 2009). P.J. Plauger and Pete Becker are very nice to deal. Indeed, we used Dinkumware on Windows CE 4.2 so that we could make use of streams. Unfortunately for our application, it's tough to justify the overhead of an alternate library, and we had problems on other people's devices that exported C++ APIs in their SDKs (they would export a function that returned a Microsoft std::wstring for example, which isn't binary compatible with a Dinkumware std::wstring so we'd end up wrapping their SDK in C: very ugly).

software programming c++

Fun little project for after the kids went to bed tonight: we picked up an old Western Electric Model 500 rotary telephone from boldoldphones.com via eBay. We chose the cheaper one, so we had to clean it. That was no big deal, and it was fun unscrewing the handset couplings like spies used to do in the old movies ;-)

I researched our exchange and found at Telephone World that it used to be called CYpress-5, so I printed up a little label using the 1942 report font, since it seemed fitting (well the 500 was introduced in 1949, and the coiled cable version is newer, but let's not split hairs).

Then, I'm ashamed to say, I had to find instructions on getting the finger wheel off to replace the label. Luckily, I found just what I was looking for at porticus.org.

The phone looks great, and it sounds fantastic: the bell could wake the dead, and really brings me back to the beige British Telecom equivalent we had when I was growing up. Best of all was my daughter's reaction to it, and walking her through the use of the rotary dial.

fun