iCal Getting Slow When Showing a Different Day

So I've got a Macintosh Mini (mid-2010)—believe it or not, that's the official name—running "Snow Leopard" OSX 10.6.8. I synchronized a lot of data on that with a Galaxy Player 4.0 "YP-G1" (which I refer to as a "Palm Pilot" since it's shorter than saying "technically it's an MP3 player and not a smart phone", and since it replaced my Palm Vx which was in service for about 10 years.) I got frustrated with MissingSync for Android when it started flaking out and not connecting to the Palm Pilot anymore. I switched to SyncMate which I was very excited about (since, unlike MissingSync, it let me synchronize while charging.)

I started noticing that iCal was running slowly. Whenever I changed to a different day it would take around 4 seconds or so. I searched around and found iCal Dupe Deleter. It exports a backup for you in iCal then looks for duplicates and deletes them. Upon completion, you restore the fixed backup into iCal—a process which I assume replaces all your iCal data with the archive contents. I had 3 or 4 duplicates, but now iCal is (while not snappy) reasonably quick in switching between days. I only wonder if I simply created an archive in iCal with File > Export... > iCal Archive... then immediately restore it with File > Import... > Import... and picking the file I just created.

Loading


Trouble with OsmAnd's "Smart" Merge of Favorites.gpx

Years ago I was quite excited by an application for my Samsung Galaxy Player Android called OsmAnd. It is a free application (although you can buy a non-free version to support the project) that allows you to download OpenStreetMap data and use it like a GPS. It supports routing and talking directions like a commercial GPS, but, given its OpenStreetMap roots, if you find an error, you can edit it yourself and within days the changes will percolate to everyone's device.

One of the things I grew fond of was to directly edit the favorites.gpx file which contained all your "Favorite" places (now called "My Places" as of version 1.8). I could find a location in, say, Google Maps, then take the latitude and longitude and create an entry in favorites.gpx. The same time I upgraded to version 1.8, I stumbled upon a file with some old locations I had saved on my (now dead) Garmin GPS. I did some text manipulations and dropped them into the favorites.gpx file, but they wouldn't import.

I played around with it for a while, and found that OsmAnd could open GPX files, with which it would try to import the entries. When I did that with favorites.gpx, it would read the file and ignore my new entries, replacing favorites.gpx with a version that did not contain any of the new entries. I didn't notice at the time, but it popped up a cryptic error message that thankfully led me to the problem:

Error reading GPX data Error parsing document. (position: line -1, column -1) caused by org.apache.harmony.xml.ExpatParser$ParseException: At line 4, column 16: not well-formed (invalid token)

The error reads "Error reading GPX data Error parsing document. (position: line -1, column -1) caused by org.apache.harmony.xml.ExpatParser$ParseException: At line 4, column 16: not well-formed (invalid token)". Examining that line in the favorites.gpx, I had attempted to include an ampersand (&) in one of the entries (the first one, as it turned out). Rather than coding it as the SGML entity (&) I simply included it in the text which the parser (validly) didn't like. Unfortunately OsmAnd didn't handle the error very gracefully.

While I appreciate the new "smart merge" feature, I debate the use of the word "smart" in the way my poorly-formed gpx file was handled!

Loading