Re: Several float to int potential rounding errors/inconsistencies

[Lubomir I. Ivanov]

On 11 March 2017 at 07:21, Jérémie Guichard  wrote:
> Hey guys,
>
> I've added the flag conditionally as discussed in previous mail, and updated
> the pull request.

i've tested the changes locally on Windows and it builds fine.
llrint() is also available.

4.9.0 seems to be the version they've added "float-conversation", so
this is correct:

+ if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS "4.9.0")
+ set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wfloat-conversion")
+ endif()

of course, there is no need of lrint() in a lot of locations and
rint() can be used instead, like here:

- sample->depth.mm = depth * FEET * 1000;
+ sample->depth.mm = lrint(depth * FEET * 1000);

"mm" is of type int.

here, t1 is of type int as well:
+ int t1 = lrint(max_d / slope);

but that's not a big issue as long as numbers are not truncated for
64bit builds.
our main Windows build is 32bit, so this is pretty much in effect:
sizeof(long) == sizeof(int).

i haven't tested if the changes break functionality in some way, hopefully not.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [Subsurface-divelog/subsurface] [Idea] Rock bottom/Minimum gas calculation (#188)

[Stefan Fuchs]

Hi All,

Am 06.03.2017 um 06:41 schrieb Dirk Hohndel:
>>
>> How is this progressing? Since I have started to pull new features
>> maybe this should get merged as well?
>> Or is it still too early for that?
>>
>>
>
Status update:
Implementation and review: Code unchanged since a few days. No known
issues. Review once done by Robert.
Testing: By me and Rick - thanks!
Documentation: Docu created, please review! I also changed some planner
screen shots but even not all (not the pSCR and CCR ones). Willem, it
would be really great if you could update them later.
Automated tests: Not yet but I promise to do this later :-)

Pull request submitted.

One important hint: Can happen that there will be a conflict with an
still open pull request from Robert. Dirk, if you can't merge it after
merging Roberts changes, please tell me! I will then rebase it again and
take care about the conflicts.


Best regards
Stefan

-- 

Stefan Fuchs
E-Mail: sfu...@gmx.de 

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Several float to int potential rounding errors/inconsistencies

[Dirk Hohndel]

On Sat, Mar 11, 2017 at 03:41:53PM +0200, Lubomir I. Ivanov wrote:
> On 11 March 2017 at 07:21, Jérémie Guichard  wrote:
> > Hey guys,
> >
> > I've added the flag conditionally as discussed in previous mail, and updated
> > the pull request.
> 
> i've tested the changes locally on Windows and it builds fine.
> llrint() is also available.
> 
> 4.9.0 seems to be the version they've added "float-conversation", so
> this is correct:
> 
> + if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS "4.9.0")
> + set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wfloat-conversion")
> + endif()
> 
> of course, there is no need of lrint() in a lot of locations and
> rint() can be used instead, like here:
> 
> - sample->depth.mm = depth * FEET * 1000;
> + sample->depth.mm = lrint(depth * FEET * 1000);

I find changes like this not only unnecessary but also potentially
confusing.

> here, t1 is of type int as well:
> + int t1 = lrint(max_d / slope);

> but that's not a big issue as long as numbers are not truncated for
> 64bit builds.
> our main Windows build is 32bit, so this is pretty much in effect:
> sizeof(long) == sizeof(int).

I keep wondering at which point it would make sense to switch to 64bit
builds for Windows as well. Our stats still show a small but fairly stable
share of 32bit systems running Subsurface. But then again, we also have a
few people on 4.5 running Windows XP :-)

> i haven't tested if the changes break functionality in some way, hopefully 
> not.

If we had better tests, we could use those to test that nothing breaks...

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [Subsurface-divelog/subsurface] [Idea] Rock bottom/Minimum gas calculation (#188)

[Stefan Fuchs]

Hi Dirk,


Am 11.03.2017 um 14:47 schrieb Stefan Fuchs:
>
> Pull request submitted.
>
> One important hint: Can happen that there will be a conflict with an
> still open pull request from Robert. Dirk, if you can't merge it after
> merging Roberts changes, please tell me! I will then rebase it again
> and take care about the conflicts. 
I saw that you were able to merge everything but as expected the build
fails now. I have to change a few things to depth_t because Robert
changed variables to depth_t at the same moment. I can do this in a few
hours. It shouldn't be a big deal. Sorry for the inconvenience.

Best regards
Stefan

-- 

Stefan Fuchs
E-Mail: sfu...@gmx.de 

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Several float to int potential rounding errors/inconsistencies

[Linus Torvalds]

On Sat, Mar 11, 2017 at 5:41 AM, Lubomir I. Ivanov  wrote:
>
> of course, there is no need of lrint() in a lot of locations and
> rint() can be used instead, like here:
>
> - sample->depth.mm = depth * FEET * 1000;
> + sample->depth.mm = lrint(depth * FEET * 1000);
>
> "mm" is of type int.

No.

It's an understandable confusion: thinking that rint() returns 'int'
and lrint() returns 'long'. But no, that's not how it works.

'rint()' returns a double that has been rounded to an integer. Note
the difference between: "integer" and "int". The end result not only
isn't an 'int', it might not even fit in an int. In fact, it might not
fit in a long.

So 'rint()' does work, but it results in the float-conversion warnings
because of the implicit conversion from 'double' to 'int' in the final
assignment.

So 'lrint()' is the right thing to do, because FEET is 0.3048, so
'depth * FEET * 1000' is a floating point value, and it does actually
want rounding in theory.

Then the long->int conversion might drop bits, but we don't care.

Not that anybody really cares about the nearest mm when doing feet
conversion, but still...

> here, t1 is of type int as well:
> + int t1 = lrint(max_d / slope);

Again, same issue. "rint()" doesn't return an "int". So "lrint()" is
actually better.

   Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [Subsurface-divelog/subsurface] [Idea] Rock bottom/Minimum gas calculation (#188)

[Dirk Hohndel]

> On Mar 11, 2017, at 8:30 AM, Stefan Fuchs  wrote:
> 
> Hi Dirk,
> 
> 
> Am 11.03.2017 um 14:47 schrieb Stefan Fuchs:
>> 
>> Pull request submitted.
>> 
>> One important hint: Can happen that there will be a conflict with an still 
>> open pull request from Robert. Dirk, if you can't merge it after merging 
>> Roberts changes, please tell me! I will then rebase it again and take care 
>> about the conflicts.
> I saw that you were able to merge everything but as expected the build fails 
> now. I have to change a few things to depth_t because Robert changed 
> variables to depth_t at the same moment. I can do this in a few hours. It 
> shouldn't be a big deal. Sorry for the inconvenience.

I have this fixed and will push it soon.

/D___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Several float to int potential rounding errors/inconsistencies

[Lubomir I. Ivanov]

On 11 March 2017 at 18:32, Linus Torvalds  wrote:
> On Sat, Mar 11, 2017 at 5:41 AM, Lubomir I. Ivanov  
> wrote:
>>
>> of course, there is no need of lrint() in a lot of locations and
>> rint() can be used instead, like here:
>>
>> - sample->depth.mm = depth * FEET * 1000;
>> + sample->depth.mm = lrint(depth * FEET * 1000);
>>
>> "mm" is of type int.
>
> No.
>
> It's an understandable confusion: thinking that rint() returns 'int'
> and lrint() returns 'long'. But no, that's not how it works.
>
> 'rint()' returns a double that has been rounded to an integer. Note
> the difference between: "integer" and "int". The end result not only
> isn't an 'int', it might not even fit in an int. In fact, it might not
> fit in a long.
>
> So 'rint()' does work, but it results in the float-conversion warnings
> because of the implicit conversion from 'double' to 'int' in the final
> assignment.

ah, yeah,

so rint() returns a double and lrint() returns a long.
makes sense for the stdlib folks, i guess:
http://en.cppreference.com/w/c/numeric/math/rint

so with lrint() we avoid the float -> integer cast.

but in the case of:
int mm = lrint(some_float);

if one enables -Wconversation on a 64bit toolchain, where sizeof(long) == 8:
warning: conversion to ‘int’ from ‘long int’ may alter its value [-Wconversion]

which is essentially truncation, but probably doesn't matter in our
case as it's unlikely some of those properties will receive values
larger than (2^31) - 1...
for instance, 2.147483E+6 meters is *very* deep.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Several float to int potential rounding errors/inconsistencies

[Lubomir I. Ivanov]

On 11 March 2017 at 17:24, Dirk Hohndel  wrote:
> On Sat, Mar 11, 2017 at 03:41:53PM +0200, Lubomir I. Ivanov wrote:
>> On 11 March 2017 at 07:21, Jérémie Guichard  wrote:
>> > Hey guys,
>> >
>> > I've added the flag conditionally as discussed in previous mail, and 
>> > updated
>> > the pull request.
>>
>> i've tested the changes locally on Windows and it builds fine.
>> llrint() is also available.
>>
>> 4.9.0 seems to be the version they've added "float-conversation", so
>> this is correct:
>>
>> + if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS "4.9.0")
>> + set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wfloat-conversion")
>> + endif()
>>
>> of course, there is no need of lrint() in a lot of locations and
>> rint() can be used instead, like here:
>>
>> - sample->depth.mm = depth * FEET * 1000;
>> + sample->depth.mm = lrint(depth * FEET * 1000);
>
> I find changes like this not only unnecessary but also potentially
> confusing.
>
>> here, t1 is of type int as well:
>> + int t1 = lrint(max_d / slope);
>
>> but that's not a big issue as long as numbers are not truncated for
>> 64bit builds.
>> our main Windows build is 32bit, so this is pretty much in effect:
>> sizeof(long) == sizeof(int).
>
> I keep wondering at which point it would make sense to switch to 64bit
> builds for Windows as well. Our stats still show a small but fairly stable
> share of 32bit systems running Subsurface. But then again, we also have a
> few people on 4.5 running Windows XP :-)

i think they've released WinXP 64bit at some point

probably best to stay with the 32bit as the main one for now.
at least, that's the standard practice with other Win32 software - if
you provide one build use 32bit, but you can also provide a 64bit
build next to it.

the 64bit build for 64bit OSes might increase performance a little and
can support more than 4GB of RAM.
but other than that there are no noticeable benefits.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 1/4] Only enable -Wmissing-field-initializers for Clang

[Lubomir I. Ivanov]

From: "Lubomir I. Ivanov" 

The following pragma is Clang specific:

It produces a warning:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]

Only enable it for Clang by checking the __clang__ macro.

Signed-off-by: Lubomir I. Ivanov 
---
 core/cochran.c | 2 ++
 core/datatrak.c| 2 ++
 core/equipment.c   | 2 ++
 core/git-access.c  | 2 ++
 core/libdivecomputer.c | 2 ++
 core/load-git.c| 2 ++
 core/membuffer.c   | 2 ++
 core/parse-xml.c   | 2 ++
 core/save-git.c| 2 ++
 core/save-html.c   | 2 ++
 core/save-xml.c| 2 ++
 core/worldmap-save.c   | 2 ++
 12 files changed, 24 insertions(+)

diff --git a/core/cochran.c b/core/cochran.c
index c31e78f..430c3b4 100644
--- a/core/cochran.c
+++ b/core/cochran.c
@@ -1,5 +1,7 @@
+#ifdef __clang__
 // Clang has a bug on zero-initialization of C structs.
 #pragma clang diagnostic ignored "-Wmissing-field-initializers"
+#endif
 
 #include 
 #include 
diff --git a/core/datatrak.c b/core/datatrak.c
index 6c9b007..272aa34 100644
--- a/core/datatrak.c
+++ b/core/datatrak.c
@@ -1,5 +1,7 @@
+#ifdef __clang__
 // Clang has a bug on zero-initialization of C structs.
 #pragma clang diagnostic ignored "-Wmissing-field-initializers"
+#endif
 
 #include 
 #include 
diff --git a/core/equipment.c b/core/equipment.c
index 0d4ab55..19b50ab 100644
--- a/core/equipment.c
+++ b/core/equipment.c
@@ -1,5 +1,7 @@
+#ifdef __clang__
 // Clang has a bug on zero-initialization of C structs.
 #pragma clang diagnostic ignored "-Wmissing-field-initializers"
+#endif
 
 /* equipment.c */
 #include 
diff --git a/core/git-access.c b/core/git-access.c
index b95606d..ac4ac80 100644
--- a/core/git-access.c
+++ b/core/git-access.c
@@ -1,5 +1,7 @@
+#ifdef __clang__
 // Clang has a bug on zero-initialization of C structs.
 #pragma clang diagnostic ignored "-Wmissing-field-initializers"
+#endif
 
 #include 
 #include 
diff --git a/core/libdivecomputer.c b/core/libdivecomputer.c
index 8ffb49d..f8f9823 100644
--- a/core/libdivecomputer.c
+++ b/core/libdivecomputer.c
@@ -1,5 +1,7 @@
+#ifdef __clang__
 // Clang has a bug on zero-initialization of C structs.
 #pragma clang diagnostic ignored "-Wmissing-field-initializers"
+#endif
 
 #include 
 #include 
diff --git a/core/load-git.c b/core/load-git.c
index 03e7f86..fdac2ef 100644
--- a/core/load-git.c
+++ b/core/load-git.c
@@ -1,5 +1,7 @@
+#ifdef __clang__
 // Clang has a bug on zero-initialization of C structs.
 #pragma clang diagnostic ignored "-Wmissing-field-initializers"
+#endif
 
 #include 
 #include 
diff --git a/core/membuffer.c b/core/membuffer.c
index 053edb8..e35f160 100644
--- a/core/membuffer.c
+++ b/core/membuffer.c
@@ -1,5 +1,7 @@
+#ifdef __clang__
 // Clang has a bug on zero-initialization of C structs.
 #pragma clang diagnostic ignored "-Wmissing-field-initializers"
+#endif
 
 #include 
 #include 
diff --git a/core/parse-xml.c b/core/parse-xml.c
index 38cd25f..2f5be06 100644
--- a/core/parse-xml.c
+++ b/core/parse-xml.c
@@ -1,5 +1,7 @@
+#ifdef __clang__
 // Clang has a bug on zero-initialization of C structs.
 #pragma clang diagnostic ignored "-Wmissing-field-initializers"
+#endif
 
 #include 
 #include 
diff --git a/core/save-git.c b/core/save-git.c
index d0ae790..cfcd362 100644
--- a/core/save-git.c
+++ b/core/save-git.c
@@ -1,5 +1,7 @@
+#ifdef __clang__
 // Clang has a bug on zero-initialization of C structs.
 #pragma clang diagnostic ignored "-Wmissing-field-initializers"
+#endif
 
 #include 
 #include 
diff --git a/core/save-html.c b/core/save-html.c
index 0b2d8e7..2824625 100644
--- a/core/save-html.c
+++ b/core/save-html.c
@@ -1,5 +1,7 @@
+#ifdef __clang__
 // Clang has a bug on zero-initialization of C structs.
 #pragma clang diagnostic ignored "-Wmissing-field-initializers"
+#endif
 
 #include "save-html.h"
 #include "qthelperfromc.h"
diff --git a/core/save-xml.c b/core/save-xml.c
index c9b6a5b..b6a0e4b 100644
--- a/core/save-xml.c
+++ b/core/save-xml.c
@@ -1,5 +1,7 @@
+#ifdef __clang__
 // Clang has a bug on zero-initialization of C structs.
 #pragma clang diagnostic ignored "-Wmissing-field-initializers"
+#endif
 
 #include 
 #include 
diff --git a/core/worldmap-save.c b/core/worldmap-save.c
index e7e8bcc..8ad6535 100644
--- a/core/worldmap-save.c
+++ b/core/worldmap-save.c
@@ -1,5 +1,7 @@
+#ifdef __clang__
 // Clang has a bug on zero-initialization of C structs.
 #pragma clang diagnostic ignored "-Wmissing-field-initializers"
+#endif
 
 #include 
 #include 
-- 
1.7.11.msysgit.0

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 2/4] templateedit.ui: give the layout for "Border width" unique name

[Lubomir I. Ivanov]

From: "Lubomir I. Ivanov" 

Warning introduced in e8c918622fb:
desktop-widgets\templateedit.ui: Warning: The name 'horizontal
Layout_3' (QHBoxLayout) is already in use, defaulting to 'horizontalLayout_31'.

Signed-off-by: Lubomir I. Ivanov 
---
 desktop-widgets/templateedit.ui | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/desktop-widgets/templateedit.ui b/desktop-widgets/templateedit.ui
index 616d135..bfb60d4 100644
--- a/desktop-widgets/templateedit.ui
+++ b/desktop-widgets/templateedit.ui
@@ -220,7 +220,7 @@
 


-
+
  
   

-- 
1.7.11.msysgit.0

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 4/4] qtserialbluetooth.cpp: mark qt_serial_get_transmitted() as unused

[Lubomir I. Ivanov]

From: "Lubomir I. Ivanov" 

The function is unused, to silence the warning add the "unused"
GCC attribute to the function declaration.

Signed-off-by: Lubomir I. Ivanov 
---
 core/qtserialbluetooth.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/core/qtserialbluetooth.cpp b/core/qtserialbluetooth.cpp
index 1b227cf..20e32f5 100644
--- a/core/qtserialbluetooth.cpp
+++ b/core/qtserialbluetooth.cpp
@@ -346,6 +346,9 @@ static dc_status_t qt_serial_get_received(void **userdata, 
size_t *available)
return DC_STATUS_SUCCESS;
 }
 
+/* UNUSED! */
+static int qt_serial_get_transmitted(qt_serial_t *device) __attribute__ 
((unused));
+
 static int qt_serial_get_transmitted(qt_serial_t *device)
 {
 #if defined(Q_OS_WIN)
-- 
1.7.11.msysgit.0

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[PATCH 3/4] planner.c: fix a couple of float -> int cast warnings

[Lubomir I. Ivanov]

From: "Lubomir I. Ivanov" 

Use lrint() to fix both:

1)
core\planner.c:902:23: warning: conversion to 'int' from 'doub
le' may alter its value [-Wfloat-conversion]

2)
core\planner.c:907:21: warning: conversion to 'int32_t' from '
double' may alter its value [-Wfloat-conversion]

Signed-off-by: Lubomir I. Ivanov 
---
 core/planner.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/core/planner.c b/core/planner.c
index eb73527..90fe629 100644
--- a/core/planner.c
+++ b/core/planner.c
@@ -899,13 +899,13 @@ static void add_plan_to_notes(struct diveplan *diveplan, 
struct dive *dive, bool
&& dive->dc.divemode == OC && 
decoMode() != RECREATIONAL) {
/* Calculate minimum gas volume. */
volume_t mingasv;
-   mingasv.mliter = 
prefs.problemsolvingtime * prefs.bottomsac * prefs.sacfactor / 100.0
+   mingasv.mliter = 
lrint(prefs.problemsolvingtime * prefs.bottomsac * prefs.sacfactor / 100.0
* 
depth_to_bar(lastbottomdp->depth.mm, dive)
-   + cyl->deco_gas_used.mliter * 
prefs.sacfactor / 100.0;
+   + cyl->deco_gas_used.mliter * 
prefs.sacfactor / 100.0);
/* Calculate minimum gas pressure for 
cyclinder. */
pressure_t mingasp;
-   mingasp.mbar = 
isothermal_pressure(&cyl->gasmix, 1.0,
-   mingasv.mliter, 
cyl->type.size.mliter) * 1000;
+   mingasp.mbar = 
lrint(isothermal_pressure(&cyl->gasmix, 1.0,
+   mingasv.mliter, 
cyl->type.size.mliter) * 1000);
/* Translate all results into correct 
units */
mingas_volume = 
get_volume_units(mingasv.mliter, NULL, &unit);
mingas_pressure = 
get_pressure_units(mingasp.mbar, &pressure_unit);
-- 
1.7.11.msysgit.0

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

direct import form dive computer

[Alessandro Volpi]

Dear Jef,

I have downloaded the full memory content of my Galileo Trimix computer.

The resulting files can be found in my Dropbox folder, subdirectory
galileo_trimix_import :

 https://www.dropbox.com/sh/dsg43qcbo013i1k/AAC_vCS3cZeZar5i3HngCNq3a?dl=0

I have also tried to do the same with my SmartTec computer.

For my dives I usually wear both computers, so that their contents should
be the same.

Unfortunately I was not able to download any file from the SmartTec.

The subsurface error message is "Could not connect to the SmartTec
computer" or something similar.

The SmartTec computer hardware is working perfectly. I have downloaded 112
dives form its memory relying on SmartTrak; the program was executed on a
virtual Windows XP system on the same computer used for downloading the
Galileo Trimix files.

I guess that some bug in the IR interface causes the failure of the data
download  from the SmartTec.

It is worth while to mention that the IR interface is a package not being
maintained for many years.

The interface works with Ubuntu Trusty, at least with the Galileo Sol
device.

It DOES NOT WORK AT ALL with newer systems, such as Ubuntu xenial and
Fedora 24.

I would like to try once again, if you or someone else in the mailing list
can give me some suggestions about connecting the SmartTec with the linux
IR interface.

Best regards.

Alessandro
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Android App

[Dirk Hohndel]

I would like to update the app. It would be nice if a few people could try the 
new Subsurface-mobile that's available in the beta test channel... Just as a 
check to make sure I didn't break anything obvious

Thanks

/D

⁣--
>From my phone​___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Android App

[Willem Ferguson]

>From phone. Where does one find the beta test channel? Kind regards, willem

On 12 Mar 2017 04:32, "Dirk Hohndel"  wrote:

I would like to update the app. It would be nice if a few people could try
the new Subsurface-mobile that's available in the beta test channel... Just
as a check to make sure I didn't break anything obvious

Thanks

/D

-- 
>From my phone

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Android App

[Miika Turkia]

I believe it is this one from another thread 3 hours ago:

https://play.google.com/apps/testing/org.subsurfacedivelog.mobile

miika

On Sun, Mar 12, 2017 at 7:28 AM, Willem Ferguson
 wrote:
> From phone. Where does one find the beta test channel? Kind regards, willem
>
> On 12 Mar 2017 04:32, "Dirk Hohndel"  wrote:
>
> I would like to update the app. It would be nice if a few people could try
> the new Subsurface-mobile that's available in the beta test channel... Just
> as a check to make sure I didn't break anything obvious
>
> Thanks
>
> /D
>
> --
> From my phone
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: direct import form dive computer

[Willem Ferguson]

On 12/03/2017 00:41, Alessandro Volpi wrote:

Dear Jef,


It is worth while to mention that the IR interface is a package not 
being maintained for many years.


The interface works with Ubuntu Trusty, at least with the Galileo Sol 
device.


It DOES NOT WORK AT ALL with newer systems, such as Ubuntu xenial and 
Fedora 24.


I would like to try once again, if you or someone else in the mailing 
list can give me some suggestions about connecting the SmartTec with 
the linux IR interface.


Best regards.

Alessandro


Alessandro,

I have been using the IrDA interface for several years now over several 
versions of Ubuntu (including Xenial), downloading from a Galileo Luna 
and Sol.


What procedure do you follow to install the IrDA driver?

What commands are required to activate IrDA on your machine?

Kind regards,
willem

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Android App

[Anton Lundin]

On 11 March, 2017 - Dirk Hohndel wrote:

> I would like to update the app. It would be nice if a few people could try 
> the new Subsurface-mobile that's available in the beta test channel... Just 
> as a check to make sure I didn't break anything obvious
> 

LGTM


//Anton


-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Android App

[Jérémie Guichard]

Made a fast walk through, did not find anything significant...

2017-03-12 14:19 GMT+07:00 Anton Lundin :

> On 11 March, 2017 - Dirk Hohndel wrote:
>
> > I would like to update the app. It would be nice if a few people could
> try the new Subsurface-mobile that's available in the beta test channel...
> Just as a check to make sure I didn't break anything obvious
> >
>
> LGTM
>
>
> //Anton
>
>
> --
> Anton Lundin+46702-161604
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface