This adds a couple of helper functions to manage dive trips
("add_dive_to_trip()" and "remove_dive_from_trip()") and makes those
functions do the trip statistics maintenance (trip beginning times,
number of dives, etc).
This was needed because the dive merge cases for multiple dive
computers showed some rather nasty special cases: especially if the
new dive information has been loaded into an XML file with trips
auto-generated, merging several of these kinds of xml files with
multiple dives in several overlapping trips would completely confuse
our previous code.
In particular, auto-generated trips that had the exact same date as
previous trips (because they were generated from the same dive
computer) really confused the code that used the trip timestamp to
manage the trips.
Adding the helper functions allows us to get the general case right
without having to have each piece of code that handles trip
information having to bother about all the odd rules. It will
eventually also allow us to make the dive trip data structures more
logical: right now the dive trip list is largely designed around the
odd gtk model handling, rather than some more higher-level conceptual
relationship with the actual dives.
But for now, this keeps all the data structures unchanged, and just
modifies them using the new helper functions.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The default filename handling is broken in two different ways:
(a) if we start subsurface with a non-existing file, we warn about
the inability to read that file, and then we exit without setting the
default filename.
This is broken because it means that if the user (perhaps by mistake,
by pressing ^S) now saves the file, he will overwrite the default
filename, even though that was *not* the file we read, and *not* the
file that subsurface was started with.
So just set the default filename even for a failed file open.
The exact same logic is true of a failed parse of an XML file that we
successfully opened. We do *not* want to leave the old default
filename in place just because the XML parsing failed, and possibly
then overwriting some file that was never involved with that failure
in the first place. So just get rid of all the logic to push the
filename saving into the XML parsing layer, it has zero relevance at
that point.
(b) if we do replace the default filename with a NULL file, we need
to set that even if we cannot do a strdup() on the NULL.
This fixes both errors.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Turns out we had a data field for visibility as a length unit - but never
used it. I can never guess how much visibility we actually had on a dive -
but I think most everyone can assign a rating between abysmal (zero stars,
"I couldn't read my dive computer even right in front of my mask" - trust
me, I had some of those dives) to amazing ("five stars, I could see farther
than I though possible" - and I had one or two of those, too). So I
changed this to an integer and am re-using the star infrastructure we have
for the overall dive rating.
When displaying this I was dismayed that we are running out of space in
the "Dive Notes" notbook. So I moved this to the "Dive Info" notebook.
This is not consistent and not logical. I think we need to revisit the
notebooks and think about what we want to display where.
While adding the infrastructure to manually enter the visibility I went
ahead and added the ability to manually enter the air temperature as well
(that was one of the things missing in the previous commit).
Fixes#7
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds a few fields that we parse, but more importantly it also tries
to dynamically decide if the sample temperatures and pressures are in
imperial or metric units.
Dirk suspects that DivingLog generally always does everything in metric,
and the reason why he has crazy sample data in imperial units (both for
pressure and temperature) may be due to a bug in the early Uemis
importer for DivingLog.
Which would actually make a lot more sense than DivingLog really being
so insane on purpose.
Anyway, Dirk's brother Jurgen seems to have everything in metric units,
which would be much saner. Maybe we should throw away the support for
insane DivingLog files entirely, since it is possible that the only use
ever of the possible source of that bug was Dirk's use of the Uemis
importer.
But for now, we end up just guessing. Current guesses:
- water temperature is below 32 dgC, so 32+ degrees is in Fahrenheit.
- tank pressures are below 400 bar, so higher values than that must be
psi.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is just the first step - convert the string literals, try to catch
all the places where this isn't possible and the program needs to convert
string constants at runtime (those are the N_ macros).
Add a very rough first German localization so I can at least test what I
have done. Seriously, I have never used a localized OS, so I am certain
that I have many of the 'standard' translations wrong. Someone please take
over :-)
Major issues with this:
- right now it hardcodes the search path for the message catalog to be
./locale - that's of course bogus, but it works well while doing initial
testing. Once the tooling support is there we just should use the OS
default.
- even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets
can't seem to agree) I went with UTF-8 as that is what Gtk appears to
want to use internally. ISO-8859-15 encoded .mo files create funny
looking artefacts instead of Umlaute.
- no support at all in the Makefile - I was hoping someone with more
experience in how to best set this up would contribute a good set of
Makefile rules - likely this will help fix the first issue in that it
will also install the .mo file(s) in the correct place(s)
For now simply run
msgfmt -c -o subsurface.mo deutsch.po
to create the subsurface.mo file and then move it to
./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo
If you make changes to the sources and need to add new strings to be
translated, this is what seems to work (again, should be tooled through
the Makefile):
xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c
msgmerge -s -U po/deutsch.po subsurface-new.pot
If you do this PLEASE do one commit that just has the new msgid as
changes in line numbers create a TON of diff-noise. Do changes to
translations in a SEPARATE commit.
- no testing at all on Windows or Mac
It builds on Windows :-)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Only files that are opened should be considered r/w. Files that are
imported should be treated as if they were r/o.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This patch makes the trips nest, and it also fixes the fact that you never
saved the trip notes (you could edit it, but saving would throw it away).
I did *not* change the indentation of the dives, so the trip stuff shows
up the the beginning of the line, at the same level as the <dive> and
<dives> thing. I think it's fairly readable xml, though, and we haven't
really had proper "indentation shows nesting" anyway, since the top-level
"<dives>" thing also didn't indent stuff inside of it.
Anyway, the way I wrote it, it still parses your old "INTRIP" stuff etc,
so as far as I know, it should happily read the old-style XML too. At
least it seemed to work with your xml file that already had the old-style
one (I haven't committed my divetrips, exactly because I didn't like the
new format).
It always saves in the new style, though.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Merge the dive trip rewrite by Dirk Hohndel.
This just merges the dive trip changes with the timestamp handling
changes. There were multiple small data conflicts, along with some
newly added 'time_t' cases in the dive trip handling that needed to be
converted to 'timestamp_t' along the way.
* 'divetrip-rewrite' of git://github.com/torvalds/subsurface:
Convert FIND_TRIP into function
Partial rewrite of the dive trip code
Check if trip is NULL before calling DIVE_TRIP
This introduces a new data structure for dive trips - reuseing the struct
dive just got way too messy.
The dive_trip_t datastructure now allows the code to remember if the trip
was auto generated or if its time stamp changed when dives where added to
the trip during auto generation.
The algorithm also distinguishes between dives that were intentionally
added to a trip (either in an XML file or by adding them to trip in the
UI) and dives that were added to trips via autogen. Saving dives that were
added to trips via autogen makes that assignment "intentional".
With this partial rewrite several of the oddities of the old code should
be resolved - especially turning autogen on and off again should get the
divelist back to the previous stage.
Also, when dives are merged during file open or import we now try to pick
the correct tripflag (instead of just ignoring the tripflag completely and
resetting it to TF_NONE by mistake).
Finally, the dive trip debugging code got more verbose and is trying
harder to detect issues at the earliest time possible.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes the time type unambiguous, and we can use G_TYPE_INT64 for it
in the divelist too.
It also implements a portable (and thread-safe) "utc_mkdate()" function
that acts kind of like gmtime_r(), but using the 64-bit timestamp_t. It
matches our original "utc_mktime()".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Previously we could end up with a bogus dive with all zero data in it.
Adding dives/test24.xml to be able to test that we handle this case
correctly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Previously we always picked the last file that was openend as the file
name to save to. That seems counterintuitive when importing files or when
opening multiple files. Especially if Subsurface was executed without a
file on the command line and we are using the default file.
Now we only remember a file name if it was the first one to ever be
openend or if it was used in save-as.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Pull trip manipulation branch from Dirk Hohndel:
"I have added yet more of the requested features.
I am not aware of any outstanding bugs or crashes (except for the Gtk
problem that causes the import to crash for some people on Ubuntu and
MacOS - but as I mentioned earlier, that bug has been around as long
as the import file selector box)."
* 'trip3' of git://git.hohndel.org/subsurface:
Avoid duplicate dive_trip entries
More trip manipulations: remove selected dives from trip
Add ability to merge trip with trip below
Use the infrastructure for moving dives in more places
Correct the trip related test dives
Fix crash when removing the first dive of a trip
Correctly initialize the toggle state of the autogroup menu entry
Fix copy_tree_node to no longer overwrite dive duration
Add autogen menu command
Fix a crash when changing sort column
Use truth values with gboolean
Allow modification and edits of trips
Clean up macros and auxiliary functions
Store time_t as long value
When inserting a trip into the dive_trip_list we already check for
duplicate trips, but we still kept the additional dive_trip around.
With this change we instead replace it with the existing one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
GTK messes up the standard C library locales by default (instead of just
taking locale information into account internally). Which breaks
'strtod()' and 'printf()' etc. Since they screwed that up, they then
added helper functions for undoing that braindamage. Use it.
I'd like to blame the GTK people, but the standard C libary people bear
*some* responsibility for this. One of the reasons why people do not
use "setlocale()" in many normal programs is exactly because it messes
up core libc functionality - with number conversion being the main
thing.
Doing things like converting numbers in a locale-specific manner is
something people do want to do, but not *always*. So the C library
locale code should always had defaulted to C locale, with some *extra*
marker (like a printf/scanf modifier) to say "print/scan in the current
locale".
Because many things absoilutely need to be non-localized. You don't
want your internal file format to magically change just because you want
to show things to the user in France, for example.
Reported-by: Ivan Habunek <ivan.habunek@gmail.com>
Root-caused-by: Jef Driesen <jefdriesen@telenet.be>
Cc: Dirk Hohndel <dirk@hohndel.org>
Cc: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In preparation for the next stage of the trips handling this commit makes
the macros used to access trips (and some frequently used variables for
the tree and list models) more consistent.
This also changes the way we display un-grouped dives in the dive list,
i.e. dives that are not part of a dive trip. Their dive number is now
printed bold.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Merge the initial 'track trips explicitly' code from Dirk Hohndel.
Fix up trivial conflicts in save-xml.c due to the new 'is_attribute'
flag.
* 'trips' of git://git.hohndel.org/subsurface:
Fix an issue with trips that have dives from multiple input files
Some simple test dives for the trips code
First cut of explicit trip tracking
The existing code didn't handle the case of different trips for the same
date coming from different sources. It also got confused if the first dive
processed (which is, chronologically, the last dive) happened to be a
"NOTRIP" dive.
This commit adds a bit of debugging infrastructure for the trip handling,
too.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This code establishes the explicit trip data structures and loads and
saves them in the XML data. No attempts are made to edit / modify the
trips, yet.
Loading XML files without trip data creates the trips based on timing as
before. Saving out the same, unmodified data will create 'trip' entries in
the XML file with a 'number' that reflects the number of dives in that
trip. The trip tag also stores the beginning time of the first dive in the
trip and the location of the trip (which we display in the summary entries
in the UI).
The logic allows for dives that aren't part of a dive trip. All other
dives simply belong to the "previous" dive trip - i.e. the dive trip with
the latest start time that is earlier or equal to the start time of this
dive.
This logic significantly simplifies the tracking of trips compared to
other approaches that I have tried.
The automatic grouping into trips now is an option that defaults to off
(as it makes changes to the XML file - and people who don't want this
feature shouldn't have trips added to their XML files that they then need
to manually remove).
For now you have to select this option, then exit the program and start it
again. Still to do is to trigger the trip generation at run time.
We also need a way to mark dives as not part of trips and to allow options
to combine trips, split trips, edit trip location data, etc.
The code has only had some limited testing when opening multiple files.
The code is known to fail if a location name contains unquoted special
characters like an "'".
This commit also fixes a visual inconsistency in the preferences dialog
where the font selector button didn't have a frame around it that told you
what this option was about.
Inspired-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The previous commit was a patch from Lubomir, which also had some
whitespace fixes (to go with some new whitespace bugs to replace them)
in it.
I removed the whitespace changes from that patch (don't mix whitespace
fixes with other fixes, unless they are on the same lines!) but decided
to look for other whitespace issues, and this is the result.
I left the non-C files alone, some of the spec and script files also
have whitespace at the end of lines etc.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
For simplicity and shortness, throughout subsurface exposure protection is
simply referred to as "suit".
Add the fields to the data structures, add the column to the dive_list
and the preferences dialog (once again with it being turned invisible by
default). Support loading and saving of the suit information.
Display the suit information in the Dive Info pane (this may be a bit
controversial as people could argue this should be in the Equipment pane)
and allow editing of the suit info, with our usual support for completion
and drop down lists to pick from.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
David McNett sent me some example Cochran CAN file data, along with his
UDDF exports of same. I still have absolutely no idea how to decode the
CAN files (although the subsurface decrypting code seems to correctly
decrypt the data, and I see binary patters rather than just noise), but
at least I can make sure we parse the UDDF portion better.
See also
https://github.com/nugget/cochran2uddf
for David's tool to convert the Cochran CSV exports into UDDF.
Data-source: David McNett <nugget@macnugget.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's very annoying to have to do "make install" to test a new xslt file,
just because the default xslt path has the standard install path as the
first entry.
At the same time, we do want to default to just using the standard
install location first.
So to allow both testing, and having a nice sane default, just add
support for a SUBSURFACE_XSLT_PATH environment variable that overrides
the default one if it exists.
So then you can just do
SUBSURFACE_XSLT_PATH=xslt ./subsurface
to run subsurface from inside the git tree itself, using the current
files in the git xslt subdirectory.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
... 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>
