From: Robert Lipe <robertlipe@us...> - 2007-01-18 06:00:40
[ redirected to -code after finding in obscure mailbox ]
> Here's a CVS patch that integrates support for the Alan Map 500
> handheld GPS (identical to Holux GM101). Both waypoint+route files
> (.wpr) and tracklog files (.trl) can be read and written. Support is
> currently limitted to OS Alan/Holux OS Versions 2.x. That is current,
> 3.x is still beta.
Thanx for the contribution. This is pretty much a poster child for a
contribution. Complete code that's not a pain in relying on vendor
extensions undefined behaviour , doc, test cases, and so on. It's hard
to be too critical of anything that drops in this easily, so thanx for
Part of me cringes at yet another reimplementation of the endianness
handlers as we have plenty of those already and have spent much effort
this year trying to reduce those, not add to them. The architecture geek
in me appreciates paying attention to details like PDP endianness (and,
yes, as a UNIX dude of 20-ish years, I DO know what that is all about)
but the pragmatic part of me just doesn't care any more. It didn't
bother me enough to rip it out, though. I think the code could really be
simplified (and shrunk) by using replacing byte_order...trl_swap with
code in the various functions that handled this. For example, I see
you're already using the gbfread family of functions. If, instead of
doing a 'gbfread' on the structures, you'd do a gbfgetint16 (or 8 or 32
or dbl or whatever) on the members one by one, you wouldn't have to do
the swapping manually later.
I made some trivial edits to play nicer with our memory management code
and checked it in as it passes both leaktest and vtesto. This happens
this easily almost never from a first time contributor. :-)
If you can "punch up" the doc, that would be great, but I certainly
can't say we don't have existing formats with less doc.
Please do sit in on the list for a while to help catch issues on CPU
architectures and compilers and such that I didn't exercise on initial
> The Alan community at http://www.alan-germany.com/forum would love to have
> support in gpsbabel.
My German is non-existent but we have one very experienced Babelhead,
Olaf Klein, that speaks it fluently in case we don't can't make each
other understand something. Mind you, your English appears more coherent
than what I see from some native speakers, so I'm not seeing that as a
problem; it's just offering that we have experienced ears.
Thanks for your comments and fixes. It's nice to receive positive
feedback from a pro! That made my day.
I share your point about reusing code. However, the alan module brings
its own endianess functions because it's heavily copied from the
current release of map500conv. (Which had the same bugs, so thanks for
fixing!) Slurping in all data at once and fixing endianess later has
the advantage that we can use the same approach when reading/writing
from/to the device directly. It seems to be more reliable to
upload/download data in chunks rather than item by item. My idea was
that direct device access could be integrated into gpsbabel sometime later.
So I chose not to use the existing functions.
I'll see what I can do about alan.xml.
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail