Re: qtserialbluetooth.cpp:80:1: sorry, unimplemented: non-trivial designated initializers not supported

2018-04-22 Thread Dirk Hohndel

> On Apr 22, 2018, at 6:39 PM, Rick Walsh  wrote:
> 
> You are building against the wrong version of libdivecomputer.
> 
> git submodule update
> 
> then rebuild in libdivecomputer/build and install into your local install-root
> 
> Thanks, that fixed it.  I was under the mistaken impression that because I 
> ran scripts/build.sh that I wouldn't have to update any dependencies by hand.

We should fix build.sh so that it notices if the libdivecomputer SHA has 
changed and rebuilds it.

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


Re: qtserialbluetooth.cpp:80:1: sorry, unimplemented: non-trivial designated initializers not supported

2018-04-22 Thread Rick Walsh
On 23 April 2018 at 11:32, Dirk Hohndel  wrote:

>
> > On Apr 22, 2018, at 6:19 PM, Rick Walsh  wrote:
> >
> > Hi,
> >
> > Attempting to build the current master (50b8044d5 Updated doc. for
> handling of libdc) on Fedora 27 I get the error:
> >
> > [ 53%] Building CXX object core/CMakeFiles/subsurface_
> corelib.dir/qtserialbluetooth.cpp.o
> > /home/rick/src/subsurface/core/qtserialbluetooth.cpp:80:1: sorry,
> unimplemented: non-trivial designated initializers not supported
> >  };
> >  ^
> >
> > I am building with qt 5.9.4-1 from the Fedora updates repo.
> >
>
>
> You are building against the wrong version of libdivecomputer.
>
> git submodule update
>
> then rebuild in libdivecomputer/build and install into your local
> install-root
>
> Thanks, that fixed it.  I was under the mistaken impression that because I
ran scripts/build.sh that I wouldn't have to update any dependencies by
hand.

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


Re: qtserialbluetooth.cpp:80:1: sorry, unimplemented: non-trivial designated initializers not supported

2018-04-22 Thread Dirk Hohndel

> On Apr 22, 2018, at 6:19 PM, Rick Walsh  wrote:
> 
> Hi,
> 
> Attempting to build the current master (50b8044d5 Updated doc. for handling 
> of libdc) on Fedora 27 I get the error:
> 
> [ 53%] Building CXX object 
> core/CMakeFiles/subsurface_corelib.dir/qtserialbluetooth.cpp.o
> /home/rick/src/subsurface/core/qtserialbluetooth.cpp:80:1: sorry, 
> unimplemented: non-trivial designated initializers not supported
>  };
>  ^
> 
> I am building with qt 5.9.4-1 from the Fedora updates repo.
> 


You are building against the wrong version of libdivecomputer.

git submodule update

then rebuild in libdivecomputer/build and install into your local install-root

/D

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


qtserialbluetooth.cpp:80:1: sorry, unimplemented: non-trivial designated initializers not supported

2018-04-22 Thread Rick Walsh
Hi,

Attempting to build the current master (50b8044d5 Updated doc. for handling
of libdc) on Fedora 27 I get the error:

[ 53%] Building CXX object
core/CMakeFiles/subsurface_corelib.dir/qtserialbluetooth.cpp.o
/home/rick/src/subsurface/core/qtserialbluetooth.cpp:80:1: sorry,
unimplemented: non-trivial designated initializers not supported
 };
 ^

I am building with qt 5.9.4-1 from the Fedora updates repo.

Cheers,

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


Re: Any brave dive computer download testers out there?

2018-04-22 Thread Rick Walsh
On 19 April 2018 at 07:01, Dirk Hohndel  wrote:

>
> We now have binaries for Windows, Mac, and Linux (AppImage only) available
> in order for people to test this.
>
> https://github.com/Subsurface-divelog/subsurface/releases/ta
> g/continuous-NG
>
> I'm a bit late to the party, but I've tested the continuous-NG AppImage
(on Fedora 27) and Android (Galaxy S7) builds.

Linux with Shearwater Petrel 2.
Cannot pair in BLE (nothing new here) or Auto modes.  The "Cannot connect
due to pending active LE connections" error message might be interesting,
but I don't know why it occurs.
Can pair in Classic BT mode, but download of dives fails in new logbook
(cannot use my real log since it already contains my last dives).

[rick@localhost Downloads]$ ./Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
-v
Subsurface v4.7.8-73-ga12ea13d51f5,
built with libdivecomputer v0.7.0-devel-Subsurface-NG (
b5f53eeb1f5fac951d694c5173470f99d005bf45)
built with Qt Version 5.9.3, runtime from Qt Version 5.9.3
built with libgit2 0.26.0
"validateGL(): created OpenGLContext."
"validateGL(): obtained QOpenGLFunctions."
"validateGL(): detected OpenGL version 3.0."
can't find Qt localization for locale "en-AU" searching in
"/tmp/.mount_SubsurA3AowW/usr/translations"
can't find Subsurface localization for locale "en-AU"
Plugins Directory:  QDir( "/tmp/.mount_SubsurA3AowW/usr/bin" , nameFilters
= { "*" },  QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters(
Dirs|Files|Drives|AllEntries ) )
...
Missing CAP_NET_ADMIN permission. Cannot determine whether a found address
is of random or public type.
Failed to create pairing "org.bluez.Error.InProgress"
Failed to create pairing "org.freedesktop.DBus.Error.NoReply"
Failed to create pairing "org.bluez.Error.InProgress"
Failed to create pairing "org.bluez.Error.InProgress"
Failed to create pairing "org.freedesktop.DBus.Error.NoReply"
Starting download from  BT
Starting the thread 0
Enabling GATT request timeout behavior 2
qt_ble_open( 00:13:43:0E:6B:D0 )
Creating default GAP/GATT services
Cannot connect due to pending active LE connections
HCI event triggered, type: f
RemoteDeviceManager job queue status: true
RemoteDeviceManager finished attempting to close external connections
addresstypeToUse: "Random"
No settings found for peer device.
HCI event triggered, type: 5
HCI event triggered, type: e
HCI event triggered, type: e
HCI event triggered, type: e
HCI event triggered, type: e
timeout while trying to connect to the controller  00:13:43:0E:6B:D0
The connection on RFCOMM channel number 1 took more than expected. Wait
another 15 seconds.
void QBluetoothSocketPrivate::_q_readNotify() 19 error: -1 "Resource
temporarily unavailable"
Failed to connect to device  00:13:43:0E:6B:D0 . Device state
QBluetoothSocket::UnconnectedState . Error:  QBluetoothSocket::
UnknownSocketError
[17.322698] ERROR: No such file or directory (2) [in
../../src/serial_posix.c:295 (dc_serial_open)]
Finishing the thread Unable to open %s %s (%s) dives downloaded 0
Set the current dive site: 0

Linux with Hollis DG03 (via USB/serial cable).
Download works for 6 dives, then produces a ringbuffer error.  Probably
nothing to do with the current changes.  I previously (last year?) had a
similar error, that Jef fixed in libdivecomputer, but it's here again.  I
rarely download dives from this dive computer (it's a backup that I
sometimes take in the water), so it doesn't get much testing anymore.

^TStarting download from  /dev/ttyUSB0
Starting the thread 0
INFO: dc_device_open error value of 0
[0.351396] ERROR: Invalid ringbuffer pointer detected (0x00fea0 0x001190).
[in ../../src/oceanic_common.c:363 (oceanic_common_device_profile)]
[10.953339] ERROR: Invalid ringbuffer pointer detected (0x00fea0 0x001190).
[in ../../src/oceanic_common.c:441 (oceanic_common_device_profile)]
Finishing the thread Dive data import error dives downloaded 6


Android with Petrel 2
Download failed.  extract from subsurface.log is below.

"23.711: DCDownloadThread started for Petrel 2 on LE:00:13:43:0E:6B:D0"
Starting download from  BT
Starting the thread 0
Creating Android Central/Client support for BTLE
qt_ble_open( 00:13:43:0E:6B:D0 )
"LocalDeviceBroadcastReceiver::onReceive() - event:
android.bluetooth.device.action.ACL_CONNECTED"
Connection updated: error: QLowEnergyController::Error(NoError) oldState:
QLowEnergyController::ControllerState(ConnectingState) newState:
QLowEnergyController::ControllerState(ConnectedState)
connected to the controller for device 00:13:43:0E:6B:D0
  .. discovering services
Service discovery initiated
Found service "{1800--1000-8000-00805f9b34fb}"
 .. ignoring standard service
Found service "{180a--1000-8000-00805f9b34fb}"
 .. ignoring standard service
Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
 .. created service object QLowEnergyService(0xc92907b0)
Discovery of "{fe25c237-0ece-443c-b0aa-e02033e7029d}" started
 .. done discovering services
 .. discovering details

Re: Any brave dive computer download testers out there?

2018-04-22 Thread Linus Torvalds
On Sun, Apr 22, 2018 at 1:19 PM, Dirk Hohndel  wrote:
>
> Yeah, it's ugly, but it should make a huge difference in BLE download speed
> if I understand correctly what's going on.

The whole thing is basically completely mis-designed and retarded. On
most dive computers it actually is *worse* than what we do right now.

It also depends on actually remembering the fingerprint, and giving it
back to the right device. Which is hard to begin with, since you don't
get the proper serial number from libdivecomputer, so it's not even
easy to know which fingerprint to use.

So now you have to remember garbage that is irrelevant in 99% of all
cases, that is ugly random data that could be any size, and that you
have to then also match up with the right dive computer based on other
garbage data that isn't even reliable.

Really?

I really don't want to touch it with a ten-foot pole.

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


Re: Any brave dive computer download testers out there?

2018-04-22 Thread Dirk Hohndel

> On Apr 22, 2018, at 1:09 PM, Linus Torvalds  
> wrote:
> 
> 
> 
> On Sun, Apr 22, 2018, 12:42 Dirk Hohndel  > wrote:
> 
> I know we initially didn't use the fingerprint (5 or so years ago) because 
> back then something was broken with it.
> Linus, is there still a design reason why we can't use it?
> 
> It still has the exact same problem it always had: it's random binary data 
> that we'd have to encode some way. 
> 
> In practice, I suspect it's always just a number, but the interface is nasty.
> 
> It would be much better as a string. Of course. Now it can be anything, so 
> even if it's a string we'd have to encode it somehow.
> 
> And for most dive computers it's pure garbage, and it's impossible to tell 
> which dive computer it actually matters for. So you have to encode this 
> garbage whether it's useful or not.

You make it sound so wonderful... libdivecomputer returns a char * and a size 
to us - which is different for different dive computers. Lovely.
So all we can do is store the size and base64 encode the binary data that we 
get.

Yeah, it's ugly, but it should make a huge difference in BLE download speed if 
I understand correctly what's going on.

/D

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


Re: Any brave dive computer download testers out there?

2018-04-22 Thread Linus Torvalds
On Sun, Apr 22, 2018, 12:42 Dirk Hohndel  wrote:

>
> I know we initially didn't use the fingerprint (5 or so years ago) because
> back then something was broken with it.
> Linus, is there still a design reason why we can't use it?


It still has the exact same problem it always had: it's random binary data
that we'd have to encode some way.

In practice, I suspect it's always just a number, but the interface is
nasty.

It would be much better as a string. Of course. Now it can be anything, so
even if it's a string we'd have to encode it somehow.

And for most dive computers it's pure garbage, and it's impossible to tell
which dive computer it actually matters for. So you have to encode this
garbage whether it's useful or not.

Linus

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


Re: Any brave dive computer download testers out there?

2018-04-22 Thread Jef Driesen

On 22-04-18 18:37, Linus Torvalds wrote:

On Sun, Apr 22, 2018 at 3:52 AM, Jérémie Guichard  wrote:


I just tried Scubapro G2 over bluetooth on Android build and it did not
work, but I must say this was already the case on Android for the normal
release.


Hmm. I just tried my G2 over USB, and that worked fine.

But bluetooth connects and starts downloading the data fine, but then
it doesn't import:

 Dive data import error dives downloaded 0

but I did get one "Failed to receive the packet" error. The BLE packet
handling is a _lot_ less reliable than serial is.

Hmm. I tried again, and it worked and downloaded all 78 dives on my G2.

So the bluetooth case works (at least on Linux desktop), it's just:

  (a) really really damn slow, and you can't interrupt it in the middle
because it doesn't download one dive at a time

  (b) fragile and does bad things if you get any BLE errors.

and that makes it less than wonderful (to the point of maybe being useless).

Jef, even when I already have all dives, the G2 download will
apparently just download the whole memory dump and then parse later.
That _really_ doesn't work very well. Is there no way to download one
dive at a time?


No, the protocol doesn't support that. But it does support downloading only the 
new dives. Unfortunately, the only way to take advantage of that is by means of 
the libdivecomputer fingerprint feature.


This is actually one of those cases where trying to implement the download only 
new dives feature entirely on the application side (without using the 
fingerprint feature) will always be inefficient. That's because the protocol 
works a bit different here. Unlike most other dive computers, it's the dive 
computer that does the work. You need to send a timestamp (of the most recent 
previously download dive) to the dive computer, and then the dive computer will 
only send back the newer dives.


The result is that if you don't use the fingerprint feature, then you will 
always request ALL dives And once you have all dives, you can ignore the ones 
you already had. But at that point you have already downloaded them all.


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


Re: Any brave dive computer download testers out there?

2018-04-22 Thread Linus Torvalds
On Sun, Apr 22, 2018 at 3:52 AM, Jérémie Guichard  wrote:
>
> I just tried Scubapro G2 over bluetooth on Android build and it did not
> work, but I must say this was already the case on Android for the normal
> release.

Hmm. I just tried my G2 over USB, and that worked fine.

But bluetooth connects and starts downloading the data fine, but then
it doesn't import:

Dive data import error dives downloaded 0

but I did get one "Failed to receive the packet" error. The BLE packet
handling is a _lot_ less reliable than serial is.

Hmm. I tried again, and it worked and downloaded all 78 dives on my G2.

So the bluetooth case works (at least on Linux desktop), it's just:

 (a) really really damn slow, and you can't interrupt it in the middle
because it doesn't download one dive at a time

 (b) fragile and does bad things if you get any BLE errors.

and that makes it less than wonderful (to the point of maybe being useless).

Jef, even when I already have all dives, the G2 download will
apparently just download the whole memory dump and then parse later.
That _really_ doesn't work very well. Is there no way to download one
dive at a time?

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


Re: Many issues.

2018-04-22 Thread jani


> On 22 Apr 2018, at 16:50, Willem Ferguson  
> wrote:
> 
> On 22/04/2018 11:28, j...@apache.org wrote:
>> Hi
>> 
>> Sorry for adding a bunch of issues, but I have been testing while compiling, 
>> and found a number of issues (at least on the Mac version). Once I get 
>> settled in, I have the intention of solving some of the issues. It is 
>> interesting, some things that does not work on my Mac, works on iOS and visa 
>> versa, so I have found myself having subsurface open on my iPad and my Mac.
>> 
>> Having played quite a bit with the 4.7.8 version, I see features lacking (at 
>> least for how I would like to use the software), but before adding a feature 
>> request, I would like to hear the opinion of others.
>> 
>> We have “Country” and “Location”, but not a possibility to remember the 
>> club. I frequently dive in the same location with 3 different clubs/shops 
>> and I would like to be able to see the differences e.g. in quality. It is of 
>> course to violate “Dive master” to e.g. “iSub/Antonio”, but would it not be 
>> nice to have this info as a separate field ?
>> 
>> The dive list is a wonderful thing, but it would be nice to have all fields 
>> selectable (e.g. Dive master is not in the select list) and have 
>> sub-groupings. E.g. I sort by “Dive Master”, should group when there is a 
>> break and add a short summary line. That would enable us to look at how 
>> different Dive masters perform ?
>> 
>> And yes I know how this works, “If you have itch, scratch it”, but I wanted 
>> to hear opinions first.
>> 
>> rgds
>> Jan I
> The filter tool is incredibly useful. One can filter your favourite 
> divemaster by selecting the right name in the persons list in the filter. On 
> the other hand, the tags are also very useful. Create a tag for your dive 
> club and you could filter all the dives for that dive club from the dive 
> list. Not quite as sophisticated as having all the info in the dive list, but 
> a superb tool to select specific dives from the dive list. For my needs this 
> is quite adequate.
> Kind regards,
> willem

Thanks for telling me about the filter tool, it is really powerful and it 
really does what I wanted.

In other words, forget about me idea to enhance the dive list, it is already 
enhanced !

rgds
Jan I.
> 
> 
> -- 
> This message and attachments are subject to a disclaimer.
> 
> Please refer to 
> http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
>  for
> full details.

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


Re: Any brave dive computer download testers out there?

2018-04-22 Thread Dirk Hohndel

> On Apr 22, 2018, at 6:17 AM, Jef Driesen  wrote:
> 
> It looks like some data got transferred succesfully. But then the logging 
> stops. Can you send the libdivecomputer logfile? That should give some more 
> info. (I'm not sure whether android app supports saving libdc log.)

It does, it's in the settings. And subsurface.log and libdivecomputer.log will 
be in the root of your storage device.
The latest beta builds actually show a few more interactions with the DC than 
earlier versions did.

/D

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


Re: Many issues.

2018-04-22 Thread Dirk Hohndel

> On Apr 22, 2018, at 2:28 AM, j...@apache.org wrote:
> 
> Sorry for adding a bunch of issues, but I have been testing while compiling, 
> and found a number of issues (at least on the Mac version).

Don't apologize for filing bugs. That's how we find out that apparently you 
cannot enter manual dives with durations between 50-59 minutes. Who knew...
As you've seen, on some things the difference between an "issue" and "works as 
designed" may be in the eye of the beholder :-)

> Once I get settled in, I have the intention of solving some of the issues. It 
> is interesting, some things that does not work on my Mac, works on iOS and 
> visa versa, so I have found myself having subsurface open on my iPad and my 
> Mac.

There is a lot of shared code in the backend (and that should behave reasonably 
consistently), but the UI is mostly different and I am unsurprised that there 
are differences. Some of those might be intentional, the majority is likely 
simply a bug or an oversight.

> Having played quite a bit with the 4.7.8 version, I see features lacking (at 
> least for how I would like to use the software), but before adding a feature 
> request, I would like to hear the opinion of others.
> 
> We have “Country” and “Location”, but not a possibility to remember the club. 
> I frequently dive in the same location with 3 different clubs/shops and I 
> would like to be able to see the differences e.g. in quality. It is of course 
> to violate “Dive master” to e.g. “iSub/Antonio”, but would it not be nice to 
> have this info as a separate field ?

Dive locations are a major problem, because so many people have so many 
completely different ideas what they want to store there. Some people would 
love a nine level taxonomy starting with the galaxy, down to the name of the 
dive club and boat. Others want to just put a name there. And any combination 
in between. Our solution is half baked, and only so on Subsurface, all these 
data aren't accessible on mobile. If you click on the little globe to the right 
of the Location entry on the desktop, it will allow you to Enter the Name, 
Country, Description, etc. And you have that Notes field that allows you to go 
completely crazy. That's where you could add the shop.

> The dive list is a wonderful thing, but it would be nice to have all fields 
> selectable (e.g. Dive master is not in the select list) and have 
> sub-groupings. E.g. I sort by “Dive Master”, should group when there is a 
> break and add a short summary line. That would enable us to look at how 
> different Dive masters perform ?

I'll admit that you are the first user that ever asked for the name of the dive 
master in the dive list. That shows again how individual people have very 
different expectation from a dive log. I cannot imagine why I would want to 
sort my dives by dive master... but that's what's fun about humans - they all 
have different interests and ideas. I'm not opposed to adding this column (I 
guess the next person will add for the Buddies column as well). I'm not sure 
how that grouping would work, but I look forward to seeing the code. Given the 
widget set that we use, there are potentially some limitations there.

> And yes I know how this works, “If you have itch, scratch it”, but I wanted 
> to hear opinions first.

You'll see that there are a few of us who tend to be happy to share their 
opinions :-)

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


Re: Any brave dive computer download testers out there?

2018-04-22 Thread Jef Driesen
It looks like some data got transferred succesfully. But then the logging 
stops. Can you send the libdivecomputer logfile? That should give some more 
info. (I'm not sure whether android app supports saving libdc log.)

Jef

On April 22, 2018 12:52:48 PM GMT+02:00, "Jérémie Guichard" 
 wrote:
>Hi guys,
>
>I just tried Scubapro G2 over bluetooth on Android build and it did not
>work, but I must say this was already the case on Android for the
>normal
>release.
>This use case was working few month ago but cannot remember the version
>it
>was.
>
>I'm not sure it actually helps but I attached the log file.
>
>Jeremie
>
>
>
>2018-04-20 23:10 GMT+07:00 Murillo Bernardes :
>
>> Successfully downloaded dives on a Mac from:
>> - Oceanic OCi over USB
>> - Perdix AI over BLE
>>
>> Murillo Bernardes
>>
>> On Fri, Apr 20, 2018 at 1:05 PM, Jérémie Guichard
>
>> wrote:
>>
>>> Hey guys,
>>>
>>> Just tried this build on Windows 10: https://github.com/Subsurf
>>> ace-divelog/subsurface/releases/download/continuous-NG/
>>> subsurface-4.7.8-73-ga12ea13d51f5.exe
>>>
>>> With Scubapro G2 and Suunto Zoop over USB. Seems to work like a
>charm.
>>>
>>> Jeremie
>>>
>>> 2018-04-20 9:56 GMT+07:00 Matt Thompson :
>>>


 On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel 
>wrote:

>
> We now have binaries for Windows, Mac, and Linux (AppImage only)
> available in order for people to test this.
>
> https://github.com/Subsurface-divelog/subsurface/releases/ta
> g/continuous-NG
>
>
> I tested all three of my computers on Windows 10, macOS 10.13.4,
>and
 Fedora 27.

 My Aqualung i750TC worked correctly on all three platforms using
>the USB
 cable.

 My Atomic Cobalt2 worked on Windows and macOS but failed on Linux. 
>I
 think the failure on Linux is a configuration issue on my part but
>for
 completeness I get the following in the console:
 ERROR: Failed to open the usb device. [in
>../../src/atomics_cobalt.c:117
 (atomics_cobalt_device_open)]
 INFO: dc_deveice_open error value of -6
 I get that error on both
>Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
 and Subsurface-4.7.8-x86_64.AppImage.

 My Suunto D4i failed on all three platforms.  It gave various
>errors on
 the platforms:
 Windows 10:
  the red banner at the bottom of the main window with the message
 "Unsupported operation"

 Fedora: A message box  with the message "Unable to open
>/dev/ttyUSB0"
 and a message on the console "ERROR: Failed to receive the answer.
>[in
 ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]

 macOS: A message box with the message "Error downloading dive data"



 ___
 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
>>
>>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Any brave dive computer download testers out there?

2018-04-22 Thread Jérémie Guichard
Hi guys,

I just tried Scubapro G2 over bluetooth on Android build and it did not
work, but I must say this was already the case on Android for the normal
release.
This use case was working few month ago but cannot remember the version it
was.

I'm not sure it actually helps but I attached the log file.

Jeremie



2018-04-20 23:10 GMT+07:00 Murillo Bernardes :

> Successfully downloaded dives on a Mac from:
> - Oceanic OCi over USB
> - Perdix AI over BLE
>
> Murillo Bernardes
>
> On Fri, Apr 20, 2018 at 1:05 PM, Jérémie Guichard 
> wrote:
>
>> Hey guys,
>>
>> Just tried this build on Windows 10: https://github.com/Subsurf
>> ace-divelog/subsurface/releases/download/continuous-NG/
>> subsurface-4.7.8-73-ga12ea13d51f5.exe
>>
>> With Scubapro G2 and Suunto Zoop over USB. Seems to work like a charm.
>>
>> Jeremie
>>
>> 2018-04-20 9:56 GMT+07:00 Matt Thompson :
>>
>>>
>>>
>>> On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel  wrote:
>>>

 We now have binaries for Windows, Mac, and Linux (AppImage only)
 available in order for people to test this.

 https://github.com/Subsurface-divelog/subsurface/releases/ta
 g/continuous-NG


 I tested all three of my computers on Windows 10, macOS 10.13.4, and
>>> Fedora 27.
>>>
>>> My Aqualung i750TC worked correctly on all three platforms using the USB
>>> cable.
>>>
>>> My Atomic Cobalt2 worked on Windows and macOS but failed on Linux.  I
>>> think the failure on Linux is a configuration issue on my part but for
>>> completeness I get the following in the console:
>>> ERROR: Failed to open the usb device. [in ../../src/atomics_cobalt.c:117
>>> (atomics_cobalt_device_open)]
>>> INFO: dc_deveice_open error value of -6
>>> I get that error on both Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
>>> and Subsurface-4.7.8-x86_64.AppImage.
>>>
>>> My Suunto D4i failed on all three platforms.  It gave various errors on
>>> the platforms:
>>> Windows 10:
>>>  the red banner at the bottom of the main window with the message
>>> "Unsupported operation"
>>>
>>> Fedora: A message box  with the message "Unable to open /dev/ttyUSB0"
>>> and a message on the console "ERROR: Failed to receive the answer. [in
>>> ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]
>>>
>>> macOS: A message box with the message "Error downloading dive data"
>>>
>>>
>>>
>>> ___
>>> 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
>
>


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