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>
