A complete batch of divelog and dive data takes about 20% of the available
space (depending on how long those dives are). This is a hack and I can
see this potentially going wrong, but the alternative is to be even more
conservative and that has its own set of problems as it causes us to need
more "unplug, wait, plug in again and restart" cycles.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This looks like a fairly big change but it mostly just moves a block of
code inside an earlier loop and adjust a few variables around it.
The completely broken and insane Uemis download protocol distributes data
across different "databases" on the dive computer. The "divelogs" are
downloaded in batches of 10 (most of the time), and with this change every
time one of those batches is downloaded we straight away get the matching
"dive" entries.
Hopefully this will avoid having the download abort (for lack of space)
before all components are loaded.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This caused us to not read the auxiliary information for up to the last
ten dives that were downloaded from the SDA.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user hits retry from within the download dialog, the dive list
might still be empty but we still have to look for the best point to
restart.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we run out of space in the Uemis filesystem we return an error. The
user could reasonably unplug the SDA, insert it again and then retry to
continue the download (that's what we tell them to do). In that case we
need to make sure we start at the correct dive otherwise the same dives
keep getting downloaded over and over again.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A complete batch of divelog and dive data takes about 20% of the available
space (depending on how long those dives are). This is a hack and I can
see this potentially going wrong, but the alternative is to be even more
conservative and that has its own set of problems as it causes us to need
more "unplug, wait, plug in again and restart" cycles.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This looks like a fairly big change but it mostly just moves a block of
code inside an earlier loop and adjust a few variables around it.
The completely broken and insane Uemis download protocol distributes data
across different "databases" on the dive computer. The "divelogs" are
downloaded in batches of 10 (most of the time), and with this change every
time one of those batches is downloaded we straight away get the matching
"dive" entries.
Hopefully this will avoid having the download abort (for lack of space)
before all components are loaded.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This caused us to not read the auxiliary information for up to the last
ten dives that were downloaded from the SDA.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user hits retry from within the download dialog, the dive list
might still be empty but we still have to look for the best point to
restart.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we run out of space in the Uemis filesystem we return an error. The
user could reasonably unplug the SDA, insert it again and then retry to
continue the download (that's what we tell them to do). In that case we
need to make sure we start at the correct dive otherwise the same dives
keep getting downloaded over and over again.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A well intentioned attempt in commit ff860b3c04 ("uemis-downloader -
resource leaks") to fix resource leaks actually introduced a bug.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We pass a different table to libdivecomputer (and the uemis code) and have
that table filled. And then we simply copy the dives from that table into
the real dive_table when the user accepts the download.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now that we pass in the full device_data_t information, we can look at
the "create_private_dive" flag and decide just how to record newly
downloaded dives properly.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Not only does it make it look more like the libdivecomputer downloaders,
but the uemis downloader needs it in order to support all the flags we
have. Notably "download into private trip".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we can easily decode the start time of the dive that is currently being
parsed (i.e., if the information doesn't happen to straddle a block
boundary) then show that in the dialog's progress bar.
Make the explanatory text before it shorter so there's enough space.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
[Dirk Hohndel: this overlapped with my commit 09e7c61fee ("Consistently
use for_each_dive (and use it correctly)") so I took the
pieces that I had missed]
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A bit longer, but we had a function named get_dive_by_diveid
and another one named getDiveByDiveid that did completely
different things, it was too easy to hit the wrong one..
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we first get an invalid dive info and then, once we decremented the
offset, get a valid one but for the wrong dive and then try to calculate
the correct offset, we need to keep the existing offset in mind.
What a horrid design. Thanks, UEMIS.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
After receiving another report of the Uemis downloader failing I tried to
make it more robust when unexpected things happen. The data structures
returned by the SDA are rather convoluted and not all relationships are
fully understood.
This makes sure we don't try to parse invalid dive entries, we only read
dive entries if we actually got new divelog entries, we only read dive
sites if at least one was referenced and we use a much more patient (and
hopefully, much more robust) algorithm to figure out which dive entry
corresponds to the new divelog entries.
What a pain.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In most cases the existing code might have done the right thing, but some
of the hard to reproduce errors might actually stem from the fact that we
have intermittend fs errors. Maybe this addresses things?
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
tissue_tolerance wasn't used after it was assigned.
type was overwritten after it was assigned.
serial was overwritten after the last /= 100.
event is assigned in the for loop.
clear isn't used after the assignment
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I know everyone will hate it.
Go ahead. Complain. Call me names.
At least now things are consistent and reproducible.
If you want changes, have your complaint come with a patch to
scripts/whitespace.pl so that we can automate it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
rint() is "round to nearest integer", and does a better job than +0.5
(followed by the implicit truncation inherent in integer casting). We
already used 'rint()' for values that could be negative (where +0.5 is
actively wrong), let's just make it consistent.
Of course, as is usual for the messy C math functions, it depends on the
current rounding mode. But the default round-to-nearest is what we want
and use, and the functions that explicitly always round to nearest
aren't standard enough to worry about.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Earlier we converted the C++ code to using true/false, and this converts
the C code to using the same style.
We already depended on stdbool.h in subsurfacestartup.[ch], and we build
with -std=gnu99 so nobody could build subsurface without a c99 compiler.
[Dirk Hohndel: small change suggested by Thiago Macieira: don't include
stdbool.h for C++]
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a separate patch because it required more changes
and branches due to how opendir() works on win32
with the separate struct type _WDIR and the according _w...
methods for it.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Adds use of everything from the new wrappers(), but the
opendir() one.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
next_segment():
The iterator limit check (i < size - 1) should precede
the indexing (buf[i]).
Reported by the program cppcheck.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This can happen if the Uemis is not correctly connected, but the user
still has the path set (as default DC most likely) and tries to start a
download.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This may seem like a really odd change - but with this change the Qt tools
can correctly parse the C files (and qt-gui.cpp) and get the context for
the translatable strings right.
It's not super-pretty (I'll admit that _("string literal") is much easier
on the eye than translate("gettextFromC", "string literal") ) but I think
this will be the price of success.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- remove the build flags and libraries from the Makefile / Configure.mk
- remove the glib types (gboolean, gchar, gint64, gint)
- comment out / hack around gettext
- replace the glib file helper functions
- replace g_ascii_strtod
- replace g_build_filename
- use environment variables instead of g_get_home_dir() & g_get_user_name()
- comment out GPS string parsing (uses glib utf8 macros)
This needs massive cleanup, but it's a snapshot of what I have right now, in
case people want to look at it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Commit 48ba01b807 ("Enable downloads from the UEMIS Zurich")
mistakenly switched the meaning of the "force_download" argument when it
moved from "struct argument_block" to being a direct argument.
This fixes it right back.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
