Update gitignore for the name-change of the executable
It's not called 'parse' any more. And I think I should rename 'divelog'
too to something more unique. Right now the working name for the
project is 'diveclog' (kind of like 'jdivelog') , but I'm not convinced
that the "C implementation" part is really important enough to make a
point of long-term.
"subsurface"? I don't know. Maybe I should follow the "name all
projects after myself" mantra. "divenut"?
Oops. I forgot to 'fclose()' the file after saving the xml
It never actually triggered anything for me, but any buffered data might
be lost, especially if you force-exit the application after saving a
dive log.
This probably explains a corrupted (truncated) dive file report from
Nathan Samson.
Add 'Quit' menu item, and fix invisible "File" on gtk2
I didn't even notice that the "File" part of the file menu no longer
showed up, since the keyboard accelerator for ^S worked fine.. But
apparently there's no default label associated with GTK_STOCK_FILE in
gtk2, so the "File" text went away with the conversion to GtkUIManager
in commit 4d62478e14fe ("Use the newer GtkUIManager for menu creation.")
The addition of a Quit menu entry with the associated keyboard
accelerator also makes ^Q "just work".
Of course, if we actually tracked dirty state etc, we could perhaps ask
the user whether they wanted to save or something. But I'm not exactly
famous for my GUI chops, so ..
If given multiple dives at the same time, just de-dup the dives. This
happens when you've dumped the whole dive-computer several times, and
some dives show up in multiple dumps.
When de-duping, try to avoid dropping data. So if one dive has notes
attached to it, and the other one does not, pick the notes from the dive
that does have them. Obvious stuff like that.
The sample merge is also written so that it should be possible to merge
two dives. Which we don't actually do yet.
It looks like the "units.pressure" setting is only about the units that
things are *shown* in on the wrist computer: the units in the file are
always in bar (or rather, centi-bar).
Which is definitely the right thing to do, and means that we shouldn't
care about parsing the units setting. It's purely about how something
is shown, not about parsing.
That's probably true of the other units too, but let's see when I have
more data to go on.
Use 'units' value instead of guessing based on integer/FP
We still end up guessing based on magnitude of the value, though: it
might be 'bar' or 'mbar', we end up picking one or the other based on
just how big the value is.
I should make it look at any possible explicit units too, since at least
with good xml, they exist. Of course, the only good xml I've seen so
far is the one we generate ourselves ;)
Hack up some very rudimentary support for the Uemis xml format
I think I'll need to re-organize the handling of per-format code, but
for now we just mix it all up.
The uemis conversion is also questionable even for just the small parts
I do. Does it really do "centiPSI"? That sounds crazy. I'm waiting for
Dirk to send me some actual human-readable output from the dives, right
now some of it is just rough guesses.
I think it should be legal xml, but whatever. libxml2 is very unhappy,
and complains when loading - even if I escape them. So let's just
replace the low escape characters with '?'.
The only thing to ever care was my test-case, I suspect.
Use the "empty element" form for samples that don't have any events
associated with them (and none do, right now). This avoids that
annoying "</sample>" crud.
And output the units in the output helpers, so that you can't forget
them even if you try.
When we see a number like 23.145, we'd better always also see a unit.
It's just good practice. So add 'min' to duration (and use only two
digits for number of seconds), and 'm' to depth.
And write the date in international standard format.
Teach the date parser to also parse the international standard date format
The standard way to write a date is yyyy-mm-dd, which is unambiguous and
sorts correctly.
We parsed that right in the 'datetime' case, but not in the normal date
case. And we do want to use that in our output format, exactly because
it's standard.
And also parse 'duration' for the dive duration. It's what we use when
saving, it just so happened that we ended up not parsing it right, but
then picking it up from the samples instead.
Be more careful with FP conversions, and with the Kelvin<->C offset.
And make sure to use the same names when saving as when parsing.
Now when we save a set of dives, then re-load them, and save again, the
second save image is identical to the first one.
Of course, we don't actually save everything we load, so we still do
lose information when we load and then save the result. But at least we
now don't lose the information that we *do* save.
This just generates another xml file. Don't get me wrong: I still don't
like xml, but this way we can save in the same format we load things
from. Except the save-format is a *lot* cleaner than the abortion that
is Suunto or libdivecomputer xml.
Don't bother with some crazy xml library crap for saving. Just do it!
The only thing you can do with that thing is screw things up (like
libdivecomputer did). There's no value in tracking the "filler" gas,
since you can always just calculate it from the gases that actually
matter.
So just track Oxygen and Helium - and make sure they have sane values.
Did I just say "In comparison, the libdivecomputer output is nice and
sane"?
It turns out that libdivecomputer has been doing some drugs too when it
comes to gas mixes. Like showing O2 percentages as 255.0% and N2
percentages as -155.0%.
Clearly libdivecomputer uses a 'unsigned char' for oxygen percentage,
and makes "-1" be "undefined". And then it prints that non-existing mix
out, and in the process does MATH on the damn thing ("100-O2") to
"calculate" the nitrogen percentage.
Christ.
Just make the parser silently ignore the craziness, because printing out
"Strange percentage reading -155.0" a few hundred times just doesn't
make anything any better.
The suunto xml is just completely crazy. What's the helium percentage
companion to "o2pct"? Would it be "hepct"? No. It's "hepct_0".
Ok, so they didn't number the first o2pct, which could be seen as sane:
that's the only mix value that should always exist. And they clearly
started their indexing with 0. So with multiple mixes, you'd then
expect "o2pct_1" and "hepct_1", right?
Wrong! Because XML people are crazy, the second O2 mix percentage is
obviously "o2pct_2". So the O2 percentages are one-based, with an
implicit one. But the He percentages are zero-based with an explicit
zero. So the second mix is "o2pct_2" and "hepct_1".
I'd like to ask what drugs Suunto people are on, but hey, it's a Finnish
company. No need to ask. Vodka explains everything. LOTS AND LOTS OF
VODKA.
In comparison, the libdivecomputer output is nice and sane, and uses a
'gasmix' node. Of course, now we have so many different XML nesting
nodes to check that I just made it an array of different noces. That
also allows me to mark the suunto case, so that we only do the "check
for crazy alcoholic xml entries" when it's a suunto file.
The "type of file" thing is probably a good idea for deciding on default
units too. Some day.
I'll start doing some kind of "save unparsed things as extended items"
thing, and the ignore rules were just there to get rid of some of the
noise from early parsing.
This requires us to change the way we match things up, because now we
can have things like
dives.dive.sample.event.time
and
dives.dive.sample.time
and they are different things (that "sample.event.time" is a 'time'
property of the 'event').
Now, this is always going to be ambiguous, since our linearized name of
the xml doesn't really care whether it's a xml node "child" or a
"property", but quite frankly, I don't care. XML just isn't worth the pain.
In fact, maybe this ambiguity can end up being a good thing. We will
parse these two different lines of XML the same way:
This tweaks:
- packing to be what you'd kind of expect
- makes the "summary info" always visible
- the "extended info" is now on a notebook page of its own
- dive profile the first notebook page, since the summary
information is visible regardless.
which all just seems a lot more logical.
Linus Torvalds [Wed, 31 Aug 2011 23:33:20 +0000 (16:33 -0700)]
Start cleaning up dive accessors
I'm going to add a menu to import (and eventually export) dives, and so
we'd like to be able to start out with no dives at all. Right now we
croak if that happens - it's not like the code has been written with
actual end users in mind.
So start cleaning things up. First make the 'current_dive' macro work
right even for invalid dives.
Linus Torvalds [Wed, 31 Aug 2011 23:10:11 +0000 (16:10 -0700)]
Use a 'notebook' for Info vs Profile
I dunno. This seems a better interface at least if we get more info for
the dive, but I suspect I'll want to the add basic info to the profile
page too.
This makes the 'table' approach to layout be kind of pointless again,
and the table has become a fancy vbox. Maybe I'll put the core info
back, and use the notebook 'Info' page for extended information.
I should just bite the bullet and start saving the dive data, and adding
editing functions for adding information. But instead I'm playing
around with random gtk widgets.
Linus Torvalds [Wed, 31 Aug 2011 22:35:28 +0000 (15:35 -0700)]
Add some more dive info - and actually update it
It's still the ugliest application ever, but now it at least gives you
some basic dive info.
I'd love to add a way to edit the dives to add new data (name, buddies,
location etc), but that would also require the ability to save the end
result. Maybe some day.
Linus Torvalds [Wed, 31 Aug 2011 21:35:31 +0000 (14:35 -0700)]
dive profile plot: use saner minimum limits
The time minimum was in seconds, not minutes, and we really do want to
show at least to 90ft to make shallow dives look shallow rather than
scaled to some full depth.
Linus Torvalds [Wed, 31 Aug 2011 19:09:19 +0000 (12:09 -0700)]
Add fake 'info' frame contents
It should have depth, time, place etc information, but right now it only
has a fake depth that doesn't even get updated. Just to show the idea
of the table usage.
Linus Torvalds [Wed, 31 Aug 2011 18:07:31 +0000 (11:07 -0700)]
Teach the thing to actually track the currently selected dive
.. and repaint the profile when the selection changes.
Now, if it just wasn't so ugly, it might even be useful. Except it
obviously needs to also show all the other dive information. And allow
the user to fill in details. And save the end results.
Linus Torvalds [Wed, 31 Aug 2011 15:47:13 +0000 (08:47 -0700)]
Draw some kind of profile for the (first) dive
This is all kinds of broken: it doesn't actually follow the selected
dive, and the profile isn't scaled properly etc. But it shows something
new, and not just text.
Linus Torvalds [Wed, 31 Aug 2011 03:56:01 +0000 (20:56 -0700)]
Show the dives as a gtk list/tree widget
Ok, so I'm not very good at this. I'll need to enclose the dang thing
in a scrollable window, and then make that scrollable thing just part of
the whole window.
But hey, it's pixels on the screen. Pixels that show the names of the
dives we've parsed. At least as many as will fit on screen at one time ;)
Linus Torvalds [Tue, 30 Aug 2011 23:59:03 +0000 (16:59 -0700)]
Add 'datetime' parsing for libdivecomputer xml files
I think this gets me dates on all my dives. So now I could start
sorting them and removing duplicates.
But before I try to remove dups, I guess I should compare the
libdivecomputer ones against the suunto ones. Because I bet they have
various "interesting" issues like using Bar vs Atm etc.
Linus Torvalds [Tue, 30 Aug 2011 21:36:34 +0000 (14:36 -0700)]
Fix stupid mis-initialization of current sample
.. nice compiler warning hidden by the crazy gcc pointer sign warnings
that nobody wants to see (yes, we really do want to do 'strlen()' even
on unsigned strings, don't complain, crazy bitch compiler).
So this also makes our CFLAGS set -Wno-pointer-sign.
Linus Torvalds [Tue, 30 Aug 2011 00:51:54 +0000 (17:51 -0700)]
Turn the XML into something almost parseable.
Of course, now the problem is that the different XML files have
different node names, but at least we've turned it into a half-way sane
format, and have a nice callback place per value.
Soon we could use that to actually fill in useful information.
Linus Torvalds [Sun, 28 Aug 2011 23:18:53 +0000 (16:18 -0700)]
Start archiving the stupid XML files
(and add a reminder of how they came to be)
Gaah. XML is *stupid*. It's not easy to parse for humans or for
computers, and some of these XML files are just disgusting. But maybe
they can be turned into something usable with libxml.