... but only do it if the numbering of subsequent dives was consecutive
to begin with.
Note that we do accept unnumbered dives (and will stop the sequence
check if we find one), but in order to renumber dives on delete, we
require that starting with the dive we delete, the subsequent numbered
dives have to be a nice incrementing series. If that is the case, then
we fix up that numbering as we delete the dive.
Put another way: if the dive numbering was an incrementing sequence
before the delete, then it will be a sane incrementing sequence after it
too. But if you had missing dives before the delete, we will turn the
delete into just another missing dive.
The basic rule is that we never renumber any dives unless that
renumbering is "obviously correct". It's better to leave old numbers
as-is (and expect that the user is going to do an explicit re-numbering
operation) than it is to change dive numbers in a sequence that we don't
understand.
I do suspect that we should possibly check the dive number "backwards"
too, but this doesn't do that.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This interface works the same way the "edit dive" menu item does: it's a
text entry meny item on the dive text entries (ie buddy/divemaster/notes
sections). Except you pick the "Delete" entry rather than the "Edit"
entry.
It kind of works, but it really is a pretty horrible interface. I'll
need to add a top-level dive menu entry for just deleting all selected
dives instead. And it would be good to be able to get a drop-down menu
from the divelist instead of having to do it from the dive text entries,
which is just insane.
But that requires gtk work. I'm not quite ready to get back into that.
Thus the "exact same insane interface as the explicit 'Edit' mode".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull weight management from Dirk Hohndel:
"This is the fifth or sixth version of this code, I'm begining to lose
track. I still struggle with the balance between code duplication and
unnecessary indirectness and complexity. Maybe I'm just not finding
the right level of abstraction. Maybe I'm just trying too hard.
The code here is reasonably well tested. Works for me :-)
It can import DivingLog xml files with weight systems and correctly
parses those. It obviously can read and write weight systems in its
own file format. It adds a KG/lbs unit default (and correctly stores
that).
The thing I still worry about is the code in equipment.c. You'll see
that I tried to abstract things in a way that weight systems and
cylinders share quite a bit of code - but there's more very similar
code that isn't shared as my attempts to do so turned into ugly and
hard to read code. It always felt like trying to write C++ in C..."
* 'weight' of git://subsurface.hohndel.org/subsurface:
Add weight system tracking
Fix up some trivial conflicts due to various renaming of globals and
simplification in function interfaces.
- supports multiple weight systems per dive
- supports multiple weight system types
- supports import of weight as tracked by DivingLog
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We're going to eventually import non-xml files too, so let's begin
splitting the logic up.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We have local variables or function arguments with the same names as
function static variables (or in one case, function arguments).
While all the current code was correct, it could potentially cause
confusion when chasing bugs or reviewing patches. This should make things
clearer.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Right now we do certain cylinder info operations only when importing
from an XML file, which is wrong. In particular, we do the "is the
gasmix air" or "what is the standard cylinder name" only at XML read
time, which means that if you import a dive directly from the dive
computer, it won't have the air sanitization or the proper default
cylinder names.
Of course, most dive computers don't actually save enough cylinder
information for us to do the cylinder name lookup anyway, but some do.
And all Nitrox-capable dive computers do have that O2 percentage that
needs cleanup too.
Reported-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Using xmlParseFile() was simple, but I'm planning on extending the file
parsing past just XML, since we want to be able to import other formats
too. And quite frankly, that means that we'll want to read the file
into memory to look at it before we start parsing it.
We could decide do it by file extensions too, and I'll look at that
approach as well, but regardless of how we do things it's almost
certainly a good idea to do the file access in one place. The XML
parsing might as well happen from a memory buffer instead anyway.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This works ok-ish, but doesn't allow us to click on the stars and edit
them in the divelist, which a user might expect to be able to do - in
most "star rating UIs" you simply click on the n-th star to set that
rating. Here you need to edit the dive and pick the rating from a drop
down menu.
Minor oddity: you can actually (if you force it) write anything you want
into the star rating. But anything that isn't one of the predefined
strings simply results in a zero star rating.
Overall the UI feels a bit... forced. But I think this is quite useful
anyway.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is tested with Linus' sample data, all basic functionality seems to
be working properly. Gas changes are implemented but not tested as there
was no samples of those. Multiple cylinders are missing because there
was no samples available.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Have information of multiple XSLT files on an array for importing
"alien" formatted XML dive log files. Adding support for new XSLT
requires updating the array and adding the XSLT file (provided the
format can be identified by root element of the XML).
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This allows us to install the xslt files in multiple places. Right now
the path defaults to the subsurface xslt install directory, the relative
directory "xslt" and the current working directory.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Open JDiveLog files by translating them to subsurface format using XSLT.
These files are identified by the name of the first element (JDiveLog)
and transform is applied to only these.
The XSLT feature is compiled in only if libxslt is installed. The
transformation files are installed globally in Linux under
/usr/share/subsurface/xslt. Windows and OSX still need appropriate Makefile
changes and testing.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's less portable (missing on Windows, for example) and it's kind of
overkill here - the same is easily done with a sscanf.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We would save it in the xml file, but then not actually read it back
properly. Oops. Not that we actually have any multi-tank dives yet, so
it doesn't matter. Yet.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There are a few interesting issues with this:
- this requires a change to the SDA file format; thankfully I control that
format, too (the default files are not valid XML files)
- once again, the fact that adding samples can change the dive pointer
messes with me - I decided to change the interface of ALL of the
XXX_dive_match functions to take a struct dive**
I know this is not ideal as all the other functions don't need that -
but I would have hated the inconsistency
- there is the issue that we now overload two _different_ uemis formats in
the same function - that's certainly a potential point of confusion
- a minor detail is the problem that the SDA format is kinda odd to parse
and that we trigger on the duration field by it being the only float.
Yeah, that's not ideal - but again, I control the format, so I _know_
this is true.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Just missed that one entirely in the xml parser for some reason.
Probably because the fields don't have much semantic meaning, so I
didn't even realize that I had missed one of the random integer values
in an event.
On my suunto, the 'value' field seems to contain things like the new
Oxygen percentage of a gas change event etc.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'otu-tracking-v2' of git://github.com/dirkhh/subsurface:
Make OTU column invisible by default
Add OTU to divelist
Calculate OTUs for every dive
Fix up trivial conflicts in dive.h (due to dive event handling also
adding a field to the dive structure)
Remember those useless surface events that we ignore when we import a
dive from a dive computer? Yeah, they exist in the libdivelog xml files
too. So ignore them when we see them there too.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Parse them, save them, take them from libdivecomputer.
This doesn't merge them or show them in the profile yet, though.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The calculation assumes that the cylinderindex in each sample tells us
which PO2 the dive was breathing at that time. This needs to be verified
with dives where there is an actual gas switch.
No idea where to display them, yet. Far fewer people will care about this
than care about SAC - does this still rate a spot in the dive_list?
I guess I could make it part of the dive_info - but it's not editable.
It doesn't seem to fit with the equipment page (even though this is the
one editable field that is related - nitrox %)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Sadly, no way to show them yet. But it would be nice to let people
enter them (and it would be doubly nice to have a dive computer that
does it at the surface), and then perhaps just do the "point browser at
google maps" thing.
Saving/parsing tested by hand-feeding the location of Enenui (Molokini
Crater) from google maps by hand into my divelog.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I never really liked 'diveclog' as a name - it's not like the C part is
all that important. And while I could try to just make up another slang
word for despicable person (in the tradition of naming all my projects
after myself), I just can't see it.
So let's just call it "subsurface".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I have it in some of my notes, and Dirk seems to fill that in too, so
let's just show it, save it, and allow editing of it..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
So this actually reports the dive data that libdivecomputer generates.
It doesn't import special events etc, but neither do we for the xml
importer.
It is also slow as heck, since it doesn't try to do the "hey, I already
have this dive" logic and always imports everything, but the basics are
definitely there.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We're going to start to want to allocate dives and samples for the
libdivecomputer import too, so let's clean things up a bit for that.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
libdivecomputer already uses 'gasmix_t' for its own gasmix thing. I
don't like th eway we step on each others name spaces, but hey, might as
well just use 'struct gasmix' and avoid the typedef.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Diving Log temperature reading is in Fahrenheit for the samples (for
the per-dive water/air temperature it's in Celsius). But it seems to
have a bug where a lack of a sample has been turned into 32 Fahrenheit
(which is 0 celsius). This is despite the dive itself having a water
temperature of 8 degF.
Just throw away those bogus freezing temperatures. Sure, they can
happen, and ice divers are crazy - but in this case I know it's just an
error in the log, and it looks very much like a Diving Log bug.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The LP85+ name is not something we'd normally want to recognize. The LP
cylinder names all tend to be by the "+" pressure anyway, and that's
what we do in the equipment handling naming.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When we change units, we need to flush any currently active dive
information in the old units, and then carefully reload it in the new
units.
Otherwise crazy stuff happens - like having current cylinder working
pressure values that are in PSI because that *used* to be the output
unit, but then interpreting those values as BAR, because we changed the
units.
Also, since we now properly import working pressure from Diving Log,
stop importing the (useless) cylinder description. The Diving Log
cylinder descriptions are things like "Alu" or "Steel". We're better
off just making up our own.
Finally, since Diving Log has cylinder size in metric, make sure that we
do the "match standard cylinder sizes" *after* we've done all the
cylinder size conversions to proper units.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Oh Gods. Why are all other scuba programs so f*&% messed up?
The Diving Log cylinder working pressure is in bar - which is all good.
But their pressure *samples* are in PSI. Why the h*ll do people mix up
units in the same damn file like that? I despair at the pure
incompetence sometimes.
I suspect the pressure samples aren't "really" in PSI: they are probably
in some user-specified units.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some people want to know how many dives they have under their belt, so
let's save and restore the dive number if it exists.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
That just screws up the good xml files that have everything in
well-defined units and chose the sane metric units.
So do the cuft -> liter conversion only if the input units are
explicitly CUFT, or known ambiguous input (SUUNTO).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This doesn't actually *do* anything yet, but it introduces the notion of
output units, and allows you to pick metric or imperial.
Of course, since the output doesn't currently care, the units you pick
are irrelevant. But just wait..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There are several sample UDDF files around on the net, so we might as
well start importing some of it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Looks like Linus misinterpreted the first UEMIS xml files I sent him.
The date_time appears to be in local time - so the time zone info can be
ignored (that seems strange, but it worked for the dives I tested it
with)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'open-files' of git://github.com/nathansamson/diveclog:
Report errors when opening files
Make it possible to load multiple files at once.
Open File works. I refactored the code and introduced a new type. I never used it as a pointer (their was no real reason), but I'm not really satisfied.
This is just a very rough draft. It imports all the main stuff I
noticed, but I'm sure it drops a ton of other stuff.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Instead of having each import source recognition routine set a separate
flag for that import source, just enumerate them and set them in one
variable.
I'm adding yet another xml importer - divinglog.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There's a big comment there now about what is going on. It took me a
while to understand how the crazy seven-tank uemis dive computer
information actually works.
So the Uemis computer has 4 different "tank profiles":
- single tank air (0)
- single tank nitrox (1)
- two-tank nitrox (2)
- three-tank nitrox (3)
and the computer always lists all seven tank cases (because that's how
you fill them in).
Depending on the "gas.template" you are supposed to then *use* just one
particular profile. Why the computer doesn't just give you the tanks
for that one profile, who knows? It seems to be more of the same "Uemis
dive data isn't so much about the dive, it's about dive computer state"
mentality.
So we first get the profile information, and then based on that we need
to pick the right tanks from the set of seven that we're presented with.
All clear?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This makes the xml save-file look way nicer: it's both smaller and
better organized. Using individual xml nodes for random small details
is silly.
The duration even parses exactly the same, because it still ends up
being '.depth.duration' (now it's the 'duration' attribute of the dive
node, it used to be the 'duration' child node of the dive node).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Doing per-dive cylinder start/end pressures is insane, when we can have
up to eight cylinders. The cylinder start/end pressure cannot be per
dive, it needs to be per cylinder.
This makes the save format cleaner too, we have all the cylinder data in
just one place.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is some seriously crazy stuff. Instead of making sense as a
divelog, the uemis xml makes more sense as a "dive computer settings
dump".
And I guess I can see why they'd do that. But it makes parsing it just
incredibly annoying. The thing is more of a "these are the
configurations I support as a dive computer thing" than a "this was the
tank you were diving with".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I'll want to also add a way to override/set the cylinder type: both
manually by just setting a size in liters, and by picking from some list
of standard cylinder sizes.
For example, it looks like most of my dives are marked as having
12-liter cylinders. That is probably some default from Suunto Dive
Manager, or from whatever Dirk did. It's almost certainly not right for
any of them: as far as I know, the standard cylinders for Lahaina Divers
(which is likely most of the warm water dives) are AL72's for air, and
AL80's for Nitrox.
That would be a 10L and a 11.1L tank respectively, afaik. I don't know
what a 12-liter tank would be or where that size comes from.
Anyway, the LP85+ tank designation for some of the dives looks more
likely: that's one of the common sizes I've used for local dives. So
the size of that thing is much more probably correct.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. and sort based on the 'time_t' value itself.
This allows us to use a more compact date format that doesn't need to
sort alphabetically, because sorting by date is always based on the date
value. So we can use just a two-digit year, and skip the seconds, to
keep the column narrow, while still sorting correctly.
Also, "Depth" is a nice header string, but it is wider than the column
itself, which makes the whole column wider than necessary. So put the
units in the header instead of in the string, keeping things narrow.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Instead of just tracking gasmix, track the size and workng pressure of
the cylinder too.
And use "cylinder" instead of "tank" throughout.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Now the dive profile plot *really* needs some units. The pressure is
just a random line otherwise.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Also, parse water temperatures and tank pressure.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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 ;)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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:
<dive><sample><time>50</time><depth>10.8</depth></sample></dive>
<dive><sample time="50" depth="10.8"></sample></dive>
and the attribute approach seems to be the nicer one. Maybe I'll use
that for the output format.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The executable is now called 'divelog'. If this gets useful enough to
actually *use*, I guess I'll have to come up with a real name some day.
Add a silly README, rename 'parse' to 'parse-xml'.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
