Since earlier have we had support for our own calculated TTS. This adds
support for holding TTS values reported by a dive computer.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds the loading of picture data from git repositories too.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
1) All the variables in the sample structures are strongly typed
2) Two additional types were declared in units.h:
o2pressure_t
bearing_t
3) The following variables were added:
diluentpressure
o2setpoint
o2sensor[3]
4) Changes to a number of files were made to chanf
sample->po2 to sample->po2.mbar
bearing to bearring.degrees
Signed-off-by: Willem Ferguson <willemferguson@zoology.up.ac.za>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We don't save the dive computer timestamp and duration if they match the
dive timestamp and duration. But that means that on loading, we need to
default the dive computer time/duration to the dive one. If they
differ, the loading of the divecomputer file will then override the
default timestamp/duration.
This mainly matters if a later dive merge then changes the timestamp of
the dive: the dive computer timestamp needs to have been set correctly
and not change.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This should make git loading be able to load git saves with arbitrary
weekday names. Even strange German ones.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The userid of Subsurface Webservice can be included in locally saved xml
files and git repository.
For xml files, it is stored in userid tag. For git repo, it is stored
in 00-Subsurface file present in the repo.
Preference dialog and webservice dialog modified to include option
for saving userid locally.
In case of difference in default userid and userid in local file,
some semantics are followed. These can be referred to here:
http://lists.hohndel.org/pipermail/subsurface/2014-April/011422.htmlFixes#473
Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes "is_git_repository()" return non-NULL for all file names that
match the git name pattern, even if we don't find an actual git
repository there. That way, we won't fall back to writing out an XML
file with an odd filename.
If there is no actual git repository, we return a special invalid dummy
pointer, and then the git reading and writing routines will catch it and
return the appropriate error.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Commit 13e2210d75 ("Allow remote branch names when reading a git
object tree") made it possible to read (but not write) remote branches,
which is very convenient when you just want to look at somebody elses
dives in a shared repository.
However, it was really quite stupidly done - both overly complicated,
and overly restrictive.
It's much better and simpler to just allow general git revision
specifications, which includes branches (both remote and local) as a
simple case, but also allows general git revision expressions. So you
can tag things, and use a tag-name instead. Or you can say that you
want to look at the previous save, by using the "branchname^" syntax.
Or, you can use the git reflog, and do things like
subsurface ~/scuba/[linus@{two.days.ago}]
to see the dives that your repository contained two days ago.
Obviously, you will not be able to save to this kind of ref-spec (and I
really will have to make error handling work better), but for browsing
state it's quite useful.
And in git terms, this is actually simpler than the "lets try to first
see if we have a local branch of that name, and then if we have a remote
one", as shown by the fact that this removes more lines than it adds.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes subsurface remember the git source commit of the dive data.
If you save to an existing branch, subsurface will now complain and
refuse to save if you try to save if the existing branch is not related
to the original source. That would destroy the history of the dive
data, which in turn would make it impossible to do sane merging of the
data.
If you save to a new branch, it will see if the previous parent commit
is known in the repository you are saving to, and will save parenthood
information if so. Otherwise it will save it as a new parentless commit
("root commit" in git parlance).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is the quick hack to read from a remote branch, which allows you to
look at other peoples branches when sharing a git tree.
Note that the "remote" part of "remote branch" is the _git_ meaning of a
remote branch: it is the local cached copy from a remote. This does not
imply any kind of network traffic - but if you have done a "git fetch"
to get branches from some other source, you can now use the remote
branch-name to see them in subsurface.
Also notice that you should *NOT* save the end result. It will "work",
but it won't do what you think it does. Saving does not update the
remote branch, it would create a new *local* branch with that same
branch-name, and since it's a new branch, it would do so with no
parenthood information. So you'll be very very confused.
I think I'll add code to remember the parent when loading from a git
repository, and then use that remembered information when saving. So
then you could create a real local branch with real history. But that's
an independent issue from this loading case.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead, just encode the git repository information in the filename.
We want to make it much harder to make it match a real filename, but to
still allow easy browsing with the file manager interface. So the git
repository "filename" format is the path to the git repository
directory, with the branch name encoded as "[branch]" at the end rather
than the "path:branch" format that we used in the descriptor file.
[ For example, on Windows, a filename like "c:\my.xml" could be
interpreted as the branchame "\my.xml" in the repository in the
directory "c" ]
In particular, with this model, no filename that ends with ".xml" could
possibly ever be considered a git repository name, since the last
character of a git pathname is always ']'.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We don't actually much use the trip list any more, and it's possible we
should simply get rid of it. I hadn't added the trips to the trip list
when loading them, and everything worked fine.
Well, *almost* everything worked fine.
There is one use of the list of trips, and that's the "clear the trip
index for each trip before saving them". That literally seems to be the
only non-debug use of this list, but when we didn't add the trips to the
list, the trip index never got cleared before saving trips.
And even that is unnoticeable for the *first* save event, because the
trip index will have been clear before that.
But on the *second* save event, if the trip index doesn't get cleared
before saving, the saving code will look at the index, say "Hey, I
already saved this" and skip the trip.
So if you loaded the trips from a git repository, and then saved things,
everything worked fine. But it you saved things a *second* time,
nothing would get saved at all, because all the trips were marked as
saved already.
Anyway, I think the real solution is to get rid of the pointless trip
list, and just use "for_each_dive()" to find all the trips, since that
list clearly is just more pain than gain. But in the meantime, this
makes the git loading add the trips properly to the list.
Signed-off-by: Linus "oops" Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So this is totally unrelated to the git repository format, except for
the fact that I noticed it while writing the git saving code.
The subsurface divetag list handling is being stupid, and has a
initial dummy entry at the head of the list for no good reason.
I say "no good reason", because there *is* a reason for it: it allows
code to avoid the special case of empty list and adding entries to
before the first entry etc etc. But that reason is a really *bad*
reason, because it's valid only because people don't understand basic
list manipulation and pointers to pointers.
So get rid of the dummy element, and do things right instead - by
passing a *pointer* to the list, instead of the list. And then when
traversing the list and looking for a place to insert things, don't go
to the next entry - just update the "pointer to pointer" to point to
the address of the next entry. Each entry in a C linked list is no
different than the list itself, so you can use the pointer to the
pointer to the next entry as a pointer to the list.
This is a pet peeve of mine. The real beauty of pointers can never be
understood unless you understand the indirection they allow. People
who grew up with Pascal and were corrupted by that mindset are
mentally stunted. Niklaus Wirth has a lot to answer for!
But never fear. You too can overcome that mental limitation, it just
needs some brain exercise. Reading this patch may help. In particular,
contemplate the new "taglist_add_divetag()".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
s could be used without being set.
Also convert the file to utf-8 - for some reason it was created as
iso8859.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While 100 was almost certainly long enough for all the non-string data
that we'd find on a single line, it was a little too close for comfort.
So let's go total overkill and not worry about it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This was the final piece we didn't read. I can now read my XML file,
write it to a git repository, read it back, and write it to a new XML
file, and the final XML file is bit-for-bit identical with the original
one.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes us parse everything we save, and I can load my XML file, save
it as a git file, load that git file, save it as a new XML file, and the
end result is identical.
Well... *ALMOST* identical. We currently don't save the dive computer
nickname and serial/firmware information in the git repository, so that
does get lost in translation. But all the actual dive data is there.
NOTE! I have currently only worked with my own dive files. They are
reasonably complex and complete, and do have a lot of the interesting
cases covered (like multiple dive computers etc), but there's no CCR
information, and all the dives are in trips, so this does need more
testing. It's at the very least very close.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes the sample parsing helper function for key-value pair parsing
more generic, and uses it for parsing cylinders and weightsystems too.
Events still to go, and then we have the "setting" section (for dive
computer nicknames and firmware information) that we don't actually save
yet in the git format.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This gets us the stopdepth, cns, bearing etc information. We're getting
really close to parsing everything, but are still missing event parsing,
and cylinder/weight data.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This doesn't yet parse the (less common) "key=value" type sample data,
so it's not complete, but the framework for that is in place too.
With this, we now parse all the basics, and the most noticeable missing
part is the cylinder and weigthsystem data. Lack of cylinder data in
particular means that SAC-rates etc don't get calculated, but other than
that it looks almost complete - you don't miss the missing event and
sample details unless you look for them.
I'll get the missing pieces done too, but this basic sample parsing was
visually a big step.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Some things are still missing: samples and events, and cylinder and
weightsystem information. But most of the basics are there (although
the lack of sample data makes a big visual impact)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This implements the simple line parser (including the multiline strings
with escape characters). What a difference a good file format makes:
this is nothing like the pain that is XML.
That said, it only does the line/string parsing right now, it doesn't
actually then look at what the lines say. So no human-noticeable
improvements in the actual data shown by subsurface.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we want to scale to thousands of dives, we'll eventually want to read
the dive computer files lazily when actually needed, but for now we do
everything synchronously. Even if that may actually be slower than
parsing one big XML file.
The git object store is pretty efficient, but especially with some
history, the compression and delta application will certainly not be
free.
This does all the git object unpacking, but none of the actual data
parsing yet. But as part of looking up the file objects, we do get the
dive number (which is in the name of the dive file).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The biggest part of this commit is the comment about the woeful state of
the "git_tree_walk()" interface - the interface is not really very good
for seeing any recursive state, since it just walks the tree pretty much
linearly.
But the only real recursive state we care about is the trip, and in all
normal situations the "trip this dive is in" is the same thing as "what
was the last trip directory we traversed", so a linear walk works fine.
The one exception is if a dive isn't in a trip at all, in which case
"last trip directory" obviously isn't what we want.
But rather than do our own tree walking by hand (and just passing the
trip information in the natural recursive manner when traversing the
tree), we hack around it by just looking at the path to the dive.
That one-liner trivial hack has now generated about 20 lines of
explanation of it.
ANYWAY. With this, we parse the dive and trip hierarchy properly, and
instead of just printing out the data, we might as well insert the dives
and trips into the subsurface data structures.
Note: the only data we have about the dive and trip right now is what is
visible in the directory structure, since we don't look at the actual
dive file at all (not even the name of it, which contains the dive
number). So the end result will be just a sea of empty dives and the
trips they are contained in. The dives have a date and time, and the
trip has a date, though.
So this is *not* useful for actually saving and loading data, but the
data we do load is easily visualized inside subsurface, so as I'm
starting to add real dive data parsing code, it will all be much more
visually satisfying.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It doesn't actually parse the files themselves, but it does walk the
object tree and print out the dives and trips it finds.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
