No idea why this now shows up as an error in the iOS build.
We need to refer to the typedef, not the underlying struct.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I hate changing the IO interfaces this often, but when I converted the
custom serial interface to the more generic custom IO interface, I
intentionally left the legacy serial operations alone, because I didn't
want to change something I didn't care about.
But it turns out that leaving them with the old calling convention
caused extra problems when converting the bluetooth serial code to have
the BLE GATT packet fall-back, which requires mixing two kinds of
operations.
Also, the packet_open() routine was passed a copy of the 'dc_context_t',
which makes it possible to update the 'dc_custom_io_t' field on the fly
at open time. That makes a lot of chaining operations much simpler,
since now you can chain the 'custom_io_t' at open time and then
libdivecomputer will automatically call the new routines instead of the
old ones.
That dc_context_t availability gets rid of all the
if (device && device->ops)
return device->ops->serial_xyz(..);
hackery inside the rfcomm routines - now we can just at open time do a simple
dc_context_set_custom_io(context, &ble_serial_ops);
to switch things over to the BLE version of the serial code instead.
Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer
argument to the custom_io descriptor, which gets filled in as the
custom_io is registered with the download context. Note that unlike
most opaque pointers, this one is opaque to *libdivecomputer*, and the
type is supposed to be supplied by the user.
We define the "dc_user_device_t" as our old "struct device_data_t",
making it "struct user_device_t" instead. That means that the IO
routines now get passed the device info showing what device they are
supposed to download for.
That, in turn, means that now our BLE GATT open code can take the device
type it opens for into account if it wants to. And it will want to,
since the rules for Shearwater are different from the rules for Suunto,
for example.
NOTE! Because of the interface change with libdivecomputer, this will
need a flag-day again where libdivecomputer and subsurface are updated
together. It may not be the last time, either.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is important to not duplicate code for the Qml
view. Now the DownloadFromDiveComputer widget is mostly
free from important code (that has been upgraded to the
core folder), and I can start coding the QML interface.
There are still a few functions on the desktop widget
that will die so I can call them via the QML code later.
I also touched the location of a few globals (please, let's
stop using those) - because it was declared on the
desktop code and being used in the core.
Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Not using lrint(f) when converting double/float to int
creates rounding errors.
This error was detected by TestParse::testParseDM4 failure
on Windows. It was creating rounding inconsistencies
on Linux too, see change in TestDiveDM4.xml.
Enable -Wfloat-conversion for gcc version greater than 4.9.0
Signed-off-by: Jeremie Guichard <djebrest@gmail.com>
Using gcc option "-Wfloat-conversion" is useful to catch
potential conversion errors (where lrint should be used).
rint returns double and still raises the same warning,
this is why this change updates all rint calls to lrint.
In few places, where input type is a float, corresponding
lrinf is used.
Signed-off-by: Jeremie Guichard <djebrest@gmail.com>
It turns out that we are starting to have users that have logs that go
back that far. It won't be common, but let's get it right anyway.
NOTE! With us now supporting dates earlier in 1900, this also makes
"utc_mktime()" always add the "1900" to the year field. That way we
avoid ever using the fairly ambiguous two-digit shorthand.
It didn't use to be all that ambiguous when we knew that any two-digit
number less than 70 had to be 2000+. Now that we support going back to
earlier in the last centiry, that certainty is eroding.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Having subsurface-core as a directory name really messes with
autocomplete and is obviously redundant. Simmilarly, qt-mobile caused an
autocomplete conflict and also was inconsistent with the desktop-widget
name for the directory containing the "other" UI.
And while cleaning up the resulting change in the path name for include
files, I decided to clean up those even more to make them consistent
overall.
This could have been handled in more commits, but since this requires a
make clean before the build, it seemed more sensible to do it all in one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2016-04-04 22:33:58 -07:00
Renamed from subsurface-core/uemis-downloader.c (Browse further)
