Re: Very timid beginning framework for BLE communication

[Dirk Hohndel]

It used to work, but when I tried last week I couldn't get it to work on Mac...

⁣--
>From my phone​


 Original Message 
From: Linus Torvalds 
Sent: Wed Apr 19 15:45:09 PDT 2017
To: Dirk Hohndel , Anton Lundin , 
Subsurface Mailing List 
Subject: Re: Very timid beginning framework for BLE communication

On Wed, Apr 19, 2017 at 12:17 PM, Linus Torvalds
 wrote:
> Dirk, Anton, (and possibly others who currently use RFCOMM),

Side note: does the bluetooth code actually work on MacOS at all?

Because as part of reading the Qt Bluetooth docs (I'm resigned to
having to look at this myself), I noticed that the docs clearly say
that the "QBluetoothDeviceInfo::address()" data is invalid on MacOS
and iOS, and that you should use deviceUuid() instead.

I have a patch that tries to abstract the address use (attached), but
maybe the docs are just wrong. I have neither a mac nor a rfcomm dive
computer to test with.

So this patch may be pure garbage. Throwing it out here for comments
just in case.

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

Re: Very timid beginning framework for BLE communication

[Linus Torvalds]

On Wed, Apr 19, 2017 at 3:45 PM, Linus Torvalds
 wrote:
>
> Because as part of reading the Qt Bluetooth docs (I'm resigned to
> having to look at this myself), I noticed that the docs clearly say
> that the "QBluetoothDeviceInfo::address()" data is invalid on MacOS
> and iOS, and that you should use deviceUuid() instead.

Side note: this may or may not be limited to just the BLE side, so
it's possible that the current code works fine with traditional
bluetooth and RFCOMM. The docs aren't obvious.

So even if the current state of Qt bluetooth works fine on MacOS, it
would be good to hear if it still works with the patch, or whether
this is something that needs to be made conditional on the whole
low-energy thing.

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

Re: Very timid beginning framework for BLE communication

[Linus Torvalds]

On Wed, Apr 19, 2017 at 12:17 PM, Linus Torvalds
 wrote:
> Dirk, Anton, (and possibly others who currently use RFCOMM),

Side note: does the bluetooth code actually work on MacOS at all?

Because as part of reading the Qt Bluetooth docs (I'm resigned to
having to look at this myself), I noticed that the docs clearly say
that the "QBluetoothDeviceInfo::address()" data is invalid on MacOS
and iOS, and that you should use deviceUuid() instead.

I have a patch that tries to abstract the address use (attached), but
maybe the docs are just wrong. I have neither a mac nor a rfcomm dive
computer to test with.

So this patch may be pure garbage. Throwing it out here for comments
just in case.

  Linus
From 94f99d0479ad883462a933640c8b7cbe8ca65534 Mon Sep 17 00:00:00 2001
From: Linus Torvalds 
Date: Wed, 19 Apr 2017 15:37:44 -0700
Subject: [PATCH] QtBluetooth: Use deviceUuid() instead of address() on Macs

I don't have any hardware, but the Qt docs say that QBluetoothDeviceInfo
"address()" is garbage on MacOS and iOS:

 "Note: On iOS and macOS this address is invalid. Instead deviceUuid()
  should be used. Those two platforms do not expose Bluetooth addresses
  for found Bluetooth devices and utilize unique device identifiers"

so I wonder how that code worked.

Signed-off-by: Linus Torvalds 
---
 desktop-widgets/btdeviceselectiondialog.cpp | 27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/desktop-widgets/btdeviceselectiondialog.cpp b/desktop-widgets/btdeviceselectiondialog.cpp
index fcc086bf..e1c80c62 100644
--- a/desktop-widgets/btdeviceselectiondialog.cpp
+++ b/desktop-widgets/btdeviceselectiondialog.cpp
@@ -213,12 +213,25 @@ void BtDeviceSelectionDialog::hostModeStateChanged(QBluetoothLocalDevice::HostMo
 #endif
 }
 
+//
+// The Qt BT docs say that on MacOS and iOS you have to use deviceUuid,
+// not address. Don't ask me why.
+//
+static QString get_device_string(const QBluetoothDeviceInfo &device)
+{
+#ifdef Q_OS_MAC
+	return device.deviceUuid().toString();
+#else
+	return device.address().toString();
+#endif
+}
+
 void BtDeviceSelectionDialog::addRemoteDevice(const QBluetoothDeviceInfo &remoteDeviceInfo)
 {
 #if defined(Q_OS_WIN)
 	// On Windows we cannot obtain the pairing status so we set only the name and the address of the device
 	QString deviceLabel = QString("%1 (%2)").arg(remoteDeviceInfo.name(),
-		 remoteDeviceInfo.address().toString());
+		 get_device_string(remoteDeviceInfo));
 	QColor pairingColor = QColor(Qt::white);
 #else
 	// By default we use the status label and the color for the UNPAIRED state
@@ -235,7 +248,7 @@ void BtDeviceSelectionDialog::addRemoteDevice(const QBluetoothDeviceInfo &remote
 	}
 
 	QString deviceLabel = tr("%1 (%2)   [State: %3]").arg(remoteDeviceInfo.name(),
-			  remoteDeviceInfo.address().toString(),
+			  get_device_string(remoteDeviceInfo),
 			  pairingStatusLabel);
 #endif
 	// Create the new item, set its information and add it to the list
@@ -252,7 +265,7 @@ void BtDeviceSelectionDialog::itemClicked(QListWidgetItem *item)
 	// By default we assume that the devices are paired
 	QBluetoothDeviceInfo remoteDeviceInfo = item->data(Qt::UserRole).value();
 	QString statusMessage = tr("The device %1 can be used for connection. You can press the Save button.")
-  .arg(remoteDeviceInfo.address().toString());
+  .arg(get_device_string(remoteDeviceInfo));
 	bool enableSaveButton = true;
 
 #if !defined(Q_OS_WIN)
@@ -261,7 +274,7 @@ void BtDeviceSelectionDialog::itemClicked(QListWidgetItem *item)
 
 	if (pairingStatus == QBluetoothLocalDevice::Unpaired) {
 		statusMessage = tr("The device %1 must be paired in order to be used. Please use the context menu for pairing options.")
-  .arg(remoteDeviceInfo.address().toString());
+  .arg(get_device_string(remoteDeviceInfo));
 		enableSaveButton = false;
 	}
 #endif
@@ -322,11 +335,11 @@ void BtDeviceSelectionDialog::displayPairingMenu(const QPoint &pos)
 
 	if (chosenAction == pairAction) {
 		ui->dialogStatus->setText(tr("Trying to pair device %1")
-	.arg(currentRemoteDeviceInfo.address().toString()));
+	.arg(get_device_string(currentRemoteDeviceInfo)));
 		localDevice->requestPairing(currentRemoteDeviceInfo.address(), QBluetoothLocalDevice::Paired);
 	} else if (chosenAction == removePairAction) {
 		ui->dialogStatus->setText(tr("Trying to unpair device %1")
-	.arg(currentRemoteDeviceInfo.address().toString()));
+	.arg(get_device_string(currentRemoteDeviceInfo)));
 		localDevice->requestPairing(currentRemoteDeviceInfo.address(), QBluetoothLocalDevice::Unpaired);
 	}
 #endif
@@ -420,7 +433,7 @@ void BtDeviceSelectionDialog::deviceDiscoveryError(QBluetoothDeviceDiscoveryAgen
 QString BtDeviceSelectionDialog::getSelectedDeviceAddress()
 {
 	if (selectedRemoteDeviceInfo) {
-		return selectedRemoteDeviceInfo.data()->address().toString();
+		return get_device_string(*selectedRemoteDevi

Re: Crash on Windows when importing dives via USB from OSTC2

[Stefan Fuchs]

Hello Lobomir, hello Anton,


Am 19.04.2017 um 15:35 schrieb Lubomir I. Ivanov:
> On 19 April 2017 at 09:48, Stefan Fuchs  wrote:
>> Hi All,
>>
>> unfortunately I see a new crash when importing via USB from my OSTC2. This
>> happens under Windows 10 with current master and was not there about 2 weeks
>> ago. It happens every time at the end of data transfer from the dive
>> computer.
>>
> Stefan, can you reproduce the same issue with the official Subsurface
> Windows binaries - not the ones you've built?
>
> in your stack trace, i again see hints of concurrency problems which
> may be caused by mingw.
>
With Dirks latest daily build which is
subsurface-4.6.3-260-gcb15a37ee5d5.exe I don't have the crash.

@Dirk: Is this daily based on latest libdc and marble as on Github?

Dirks MXE build is based on Qt 5.7.1.

Maybe it's really Qt or mingw. But unfortunately I used to have also
problems with newer MXE snapshots. This is why I once decided to use the
"release" 2016-10-12 of MXE which includes Qt 5.7.
Maybe it's possible to cherry pick the commit which brings MXE to Qt 5.7.1?!

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: Very timid beginning framework for BLE communication

[Rick Walsh]

On 20 Apr. 2017 5:49 am, "Linus Torvalds" 
wrote:

On Wed, Apr 19, 2017 at 12:33 PM, Dirk Hohndel  wrote:
>
>> It's really just three commits:
>>
>>   custom serial: pass device_data_t to bluetooth operation function
>>   Expand 'bluetooth_mode' from a boolean to an emun
>>   Prepare to split the custom serial operations up by RFCOMM-vs-BLE
>>
>> and each of them actually tries to be a total no-op at this time. But
>> the intent is to make it possible for core/qtserialbluetooth.cpp to
>> simply have a different set of operations for BLE devices where RFCOMM
>> doesn't work.
>
> I looked at the code and it makes sense to me. I assume the debug fprintf
> in the last one is there intentionally... :-)

Well, you picked up on the *one* change that is actually supposed to
do something.

Yeah, it's "intentional" in the sense that without that line, I
couldn't see if my code actually did anything or not.

It's obviously not meant to be real in the end. Once we have code that
actually handles the BLE case, that printf no longer makes sense at
all. Right now it's there to show that "yes, we actually noticed that
the device was a BLE device" .

>> In particular, somebody should probably test that it still works with
>> the RFCOMM model. I'm particularly worried about devices that can do
>> *both* traditional bluetooth *and* BLE. Because right now it just says
>> that if the device can do BLE, we'll pick the BLE model. Of course,
>> right now that BLE model ends up falling back to the same old RFCOMM
>> code (which would fail on a BLE-only device), so it should still work
>> with a "RFCOMM *and* BLE" device, but whatever..
>>
>> Comments?
>
> I need to check back with Shearwater - I think they have some devices that
> do both, rfcomm and BTLE

Yeah, so that's definitely the most interesting case.


The Petral 2 does both, and I think the "original" Perdix too. I might have
a chance to test with my Petral 2 this weekend but not before.


I suspect BLE is generally the "preferred" model (newer, lower power),
but obviously only when we have a working BLE downloader. Which was
why I did that "assume BLE if it's supported".

If there is somebody who has a RFCOMM mode, _and_ supports BLE, and
then the BLE protocol is something entirely different, we'd really
need the low-level libdivecomputer code to explicitly pick one over
the other.

It might be something as hacky as the libdivecomputer code doing

/* We don't handle BLE yet, force RFCOMM fallback */
if (device->bluetooth_mode == BT_LE) device->bluetooth_mode = BT_RFCOMM;

before doing the dc_serial_open() call.

But hopefully we'd never need anything like that, just because any
dive computer that supports both would use the same protocol and we'd
just prefer BLE.

 Linus
___
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: Very timid beginning framework for BLE communication

[Linus Torvalds]

On Wed, Apr 19, 2017 at 12:33 PM, Dirk Hohndel  wrote:
>
>> It's really just three commits:
>>
>>   custom serial: pass device_data_t to bluetooth operation function
>>   Expand 'bluetooth_mode' from a boolean to an emun
>>   Prepare to split the custom serial operations up by RFCOMM-vs-BLE
>>
>> and each of them actually tries to be a total no-op at this time. But
>> the intent is to make it possible for core/qtserialbluetooth.cpp to
>> simply have a different set of operations for BLE devices where RFCOMM
>> doesn't work.
>
> I looked at the code and it makes sense to me. I assume the debug fprintf
> in the last one is there intentionally... :-)

Well, you picked up on the *one* change that is actually supposed to
do something.

Yeah, it's "intentional" in the sense that without that line, I
couldn't see if my code actually did anything or not.

It's obviously not meant to be real in the end. Once we have code that
actually handles the BLE case, that printf no longer makes sense at
all. Right now it's there to show that "yes, we actually noticed that
the device was a BLE device" .

>> In particular, somebody should probably test that it still works with
>> the RFCOMM model. I'm particularly worried about devices that can do
>> *both* traditional bluetooth *and* BLE. Because right now it just says
>> that if the device can do BLE, we'll pick the BLE model. Of course,
>> right now that BLE model ends up falling back to the same old RFCOMM
>> code (which would fail on a BLE-only device), so it should still work
>> with a "RFCOMM *and* BLE" device, but whatever..
>>
>> Comments?
>
> I need to check back with Shearwater - I think they have some devices that
> do both, rfcomm and BTLE

Yeah, so that's definitely the most interesting case.

I suspect BLE is generally the "preferred" model (newer, lower power),
but obviously only when we have a working BLE downloader. Which was
why I did that "assume BLE if it's supported".

If there is somebody who has a RFCOMM mode, _and_ supports BLE, and
then the BLE protocol is something entirely different, we'd really
need the low-level libdivecomputer code to explicitly pick one over
the other.

It might be something as hacky as the libdivecomputer code doing

/* We don't handle BLE yet, force RFCOMM fallback */
if (device->bluetooth_mode == BT_LE) device->bluetooth_mode = BT_RFCOMM;

before doing the dc_serial_open() call.

But hopefully we'd never need anything like that, just because any
dive computer that supports both would use the same protocol and we'd
just prefer BLE.

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

Re: Very timid beginning framework for BLE communication

[Dirk Hohndel]

On Wed, Apr 19, 2017 at 12:17:41PM -0700, Linus Torvalds wrote:
> Dirk, Anton, (and possibly others who currently use RFCOMM),
> 
> would you mind taking a look at my "ble-prep" branch in
> 
>   https://github.com/torvalds/subsurface-for-dirk.git ble-prep
> 
> that I have *not* made into a pull request yet, because I don't
> actually have anything to test with.

I'll get you two devices tomorrow, one that does BTLE (Perdix AI) and one
that does rfcomm (Petrel).

> It's really just three commits:
> 
>   custom serial: pass device_data_t to bluetooth operation function
>   Expand 'bluetooth_mode' from a boolean to an emun
>   Prepare to split the custom serial operations up by RFCOMM-vs-BLE
> 
> and each of them actually tries to be a total no-op at this time. But
> the intent is to make it possible for core/qtserialbluetooth.cpp to
> simply have a different set of operations for BLE devices where RFCOMM
> doesn't work.

I looked at the code and it makes sense to me. I assume the debug fprintf
in the last one is there intentionally... :-)

> My plan (which may or may not work) would actually be to turn the
> Suunto EON Steel into a user of the serial emulation code too, for the
> BLE case there - even though the native model for the EON Steel isn't
> really "serial" at all, but a packet format with command/reply on top
> of USB HID (and now on top of BLE GATT with the new firmware). But I
> think it should probably be possible to use the same serial
> abstraction to then write the BLE packets instead.

At least with the Perdix AI that should in theory be all that it takes.

> But that series of three commits doesn't do any of that. It just tries
> to do no-op prep on code that I don't actually know at all, which is
> why I'd like somebody else to take a look at it.
> 
> In particular, somebody should probably test that it still works with
> the RFCOMM model. I'm particularly worried about devices that can do
> *both* traditional bluetooth *and* BLE. Because right now it just says
> that if the device can do BLE, we'll pick the BLE model. Of course,
> right now that BLE model ends up falling back to the same old RFCOMM
> code (which would fail on a BLE-only device), so it should still work
> with a "RFCOMM *and* BLE" device, but whatever..
> 
> Comments?

I need to check back with Shearwater - I think they have some devices that
do both, rfcomm and BTLE

> And yes, if somebody who actually knows that code (I'm looking at you,
> Anton) actually knows the Qt bluetooth interfaces and would fill in
> the open/close/read/write cases for the GLE GATT case, that would be
> great. Because right now I have a device that can do BLE, but going
> from "USB HID" to "BLE GATT" is a fairly big step. For example, it's a
> packetized protocol, and the packet size has changed.
> 
> In contrast, somebody who has a Perdix and already knows it, may have
> a much simpler time with the protocol that is already just a serial
> stream and isn't really packetized (and the BLE GATT thing is just a
> transport for that).

See above. I'll get you the hardware tomorrow (I'll fly home tonight).
But that shouldn't stop Anton from commenting / working on the code :-)

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

Very timid beginning framework for BLE communication

[Linus Torvalds]

Dirk, Anton, (and possibly others who currently use RFCOMM),

would you mind taking a look at my "ble-prep" branch in

  https://github.com/torvalds/subsurface-for-dirk.git ble-prep

that I have *not* made into a pull request yet, because I don't
actually have anything to test with.

It's really just three commits:

  custom serial: pass device_data_t to bluetooth operation function
  Expand 'bluetooth_mode' from a boolean to an emun
  Prepare to split the custom serial operations up by RFCOMM-vs-BLE

and each of them actually tries to be a total no-op at this time. But
the intent is to make it possible for core/qtserialbluetooth.cpp to
simply have a different set of operations for BLE devices where RFCOMM
doesn't work.

My plan (which may or may not work) would actually be to turn the
Suunto EON Steel into a user of the serial emulation code too, for the
BLE case there - even though the native model for the EON Steel isn't
really "serial" at all, but a packet format with command/reply on top
of USB HID (and now on top of BLE GATT with the new firmware). But I
think it should probably be possible to use the same serial
abstraction to then write the BLE packets instead.

But that series of three commits doesn't do any of that. It just tries
to do no-op prep on code that I don't actually know at all, which is
why I'd like somebody else to take a look at it.

In particular, somebody should probably test that it still works with
the RFCOMM model. I'm particularly worried about devices that can do
*both* traditional bluetooth *and* BLE. Because right now it just says
that if the device can do BLE, we'll pick the BLE model. Of course,
right now that BLE model ends up falling back to the same old RFCOMM
code (which would fail on a BLE-only device), so it should still work
with a "RFCOMM *and* BLE" device, but whatever..

Comments?

And yes, if somebody who actually knows that code (I'm looking at you,
Anton) actually knows the Qt bluetooth interfaces and would fill in
the open/close/read/write cases for the GLE GATT case, that would be
great. Because right now I have a device that can do BLE, but going
from "USB HID" to "BLE GATT" is a fairly big step. For example, it's a
packetized protocol, and the packet size has changed.

In contrast, somebody who has a Perdix and already knows it, may have
a much simpler time with the protocol that is already just a serial
stream and isn't really packetized (and the BLE GATT thing is just a
transport for that).

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

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

[Thiago Macieira]

On quarta-feira, 19 de abril de 2017 03:45:46 PDT Lubomir I. Ivanov wrote:
> void MarbleDebug::setEnabled(bool enabled)
> {
> QLoggingCategory::setFilterRules(QString("marble.debug=%1").arg(enabled
> ? "true", "false"));
> }
> 
> and likely remove isEnabled() as it's not needed?

Sounds good, but do we need this setEnabled() in the first place? Is it used 
anywhere?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

Re: preparing for a 4.6.4

[Dirk Hohndel]

On Wed, Apr 19, 2017 at 03:08:42PM +0200, Anton Lundin wrote:
> On 18 April, 2017 - Dirk Hohndel wrote:
> 
> > I know, we've spent all this time on Subsurface-mobile and the bugs there
> > still aren't fully understood (let alone fixed). But I can't forget about
> > our main app again - and we really need to get an update out to our users
> > with the fixed libdivecomputer.
> > 
> > I have two options. I can do a quick new build that uses the new
> > libdivecomputer and the Subsurface that we used for 4.6.3. Or I can use
> > the current master and stabilize this.
> > 
> > The advantage of the first option is that we had really really complete
> > translations for that. The advantage of the second option is that we'd get
> > the other new things out to our users, including all the fixes to the
> > planner, the manual entry of depth and duration, etc.
> > 
> > I'm kinda leaning towards the second option but that means we need to
> > spend a week or two, focused on testing the latest master and finishing
> > the translations, again. If people have strong feelings one way or
> > another, please speak up.
> > 
> > I'll do new "daily" builds next and also make sure that all the source
> > strings are pushed to Transifex, just in case.
> > 
> 
> Why not do both?
> 
> Roll a 4.6.3.1 (or something) Now, with just libdivecomputer patches,
> and when we got something stable, roll a 4.6.4?

That would be a 4.6.4 and 4.6.5 (because... reasons - actually, because we
use the fourth digit for the number of commits since a release).

The reason I don't just "do a release" is that while this may be invisible
to most of you, there is actually a good bit of work involved for me to
make a release. And so I was trying to see if the translators would be up
to doing a 4.6.4 or if there were other considerations to take into
account. "why don't you just do all that work twice, Dirk" wasn't really
part of my plan...

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

Re: Crash on Windows when importing dives via USB from OSTC2

[Lubomir I. Ivanov]

On 19 April 2017 at 09:48, Stefan Fuchs  wrote:
> Hi All,
>
> unfortunately I see a new crash when importing via USB from my OSTC2. This
> happens under Windows 10 with current master and was not there about 2 weeks
> ago. It happens every time at the end of data transfer from the dive
> computer.
>

Stefan, can you reproduce the same issue with the official Subsurface
Windows binaries - not the ones you've built?

in your stack trace, i again see hints of concurrency problems which
may be caused by mingw.

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

Re: Crash on Windows when importing dives via USB from OSTC2

[Anton Lundin]

On 19 April, 2017 - Stefan Fuchs wrote:

> Hi All,
> 
> unfortunately I see a new crash when importing via USB from my OSTC2.
> This happens under Windows 10 with current master and was not there
> about 2 weeks ago. It happens every time at the end of data transfer
> from the dive computer.
> 
> Stack trace attached. I already started to think about one of the latest
> commits being the root cause but from the stack trace I can't see a
> direct link to one of the changes I'm aware off.
> 



> 
> LEAK: 77 RenderObject
> LEAK: 1 Page
> LEAK: 1 Frame
> LEAK: 21 CachedResource
> LEAK: 169 WebCoreNode
> QWaitCondition: Destroyed while threads are still waiting
> Registers:
> eax= ebx=77a2f9a0 ecx=0004 edx= esi=0003 edi=
> eip=7798e89c esp=03c78d44 ebp=03c78e1c iopl=0 nv up ei pl nz na po nc
> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b efl=0206
> 
> AddrPC   Params
> 7798E89C  0003 0004  ntdll.dll!_NtTerminateProcess@8
> 7794A41E 0003 77E8F3B0   ntdll.dll!RtlExitUserProcess
> 7447ADC2 0003 03C78E84 76D66CD7  KERNEL32.DLL!_ExitProcessImplementation@4
> 76D66738 0003 8BF28E59 0004  msvcrt.dll!___crtExitProcess
> 76D66CD6 0003 0001   msvcrt.dll!doexit
> 76D666B1 0003 00010001   msvcrt.dll!__exit
> 76D5BCC9 03C79560 0004 03C79258  msvcrt.dll!_abort
> 03FF3AE2 0003 03C7928C 03C79248  Qt5Cored.dll!qt_message_fatal  
> [/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/global/qlogging.cpp
>  @ 1680]
> 03FF09B1 03C7928C 04330284 043E8E47  Qt5Cored.dll!fatal  
> [/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/global/qlogging.cpp
>  @ 793]
> 03FEC8FA 043E8E47 043E8B60 0A87  Qt5Cored.dll!qt_assert  
> [/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/global/qglobal.cpp
>  @ 3063]
> 041434C1 03C79330    Qt5Cored.dll!beginRemoveRows  
> [/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/itemmodels/qabstractitemmodel.cpp
>  @ 2695]

> 004A215F  001F   subsurface.exe!setImportedDivesIndexes  
> [/home/stefan/Entwicklung/Subsurface/subsurface/desktop-widgets/downloadfromdivecomputer.cpp
>  @ 736]

This looks to be curlprint.

> 004A06F5 03C7C164 03C794EC 03C79408  subsurface.exe!onDownloadThreadFinished  
> [/home/stefan/Entwicklung/Subsurface/subsurface/desktop-widgets/downloadfromdivecomputer.cpp
>  @ 456]
> 00481A63 03C7C164  0006  subsurface.exe!qt_static_metacall  
> [/home/stefan/Entwicklung/Subsurface/win32/subsurface/desktop-widgets/moc_downloadfromdivecomputer.cpp
>  @ 298]
> 041A0F26 03C7C164 5E0508E0 0004  Qt5Cored.dll!placeMetaCall  
> [/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/kernel/qobject.cpp
>  @ 502]

Because we're in onDownloadThreadFinished, I'd guess its not
libdivecomputers fault. Maybe libdivecomputer generates some data which
we can't handle, but thats another thing.


There's also both a patch release and a major release of qt after qt 5.7.0.

Might be worth trying to to one of those.


//Anton


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

Re: preparing for a 4.6.4

[Anton Lundin]

On 18 April, 2017 - Dirk Hohndel wrote:

> I know, we've spent all this time on Subsurface-mobile and the bugs there
> still aren't fully understood (let alone fixed). But I can't forget about
> our main app again - and we really need to get an update out to our users
> with the fixed libdivecomputer.
> 
> I have two options. I can do a quick new build that uses the new
> libdivecomputer and the Subsurface that we used for 4.6.3. Or I can use
> the current master and stabilize this.
> 
> The advantage of the first option is that we had really really complete
> translations for that. The advantage of the second option is that we'd get
> the other new things out to our users, including all the fixes to the
> planner, the manual entry of depth and duration, etc.
> 
> I'm kinda leaning towards the second option but that means we need to
> spend a week or two, focused on testing the latest master and finishing
> the translations, again. If people have strong feelings one way or
> another, please speak up.
> 
> I'll do new "daily" builds next and also make sure that all the source
> strings are pushed to Transifex, just in case.
> 

Why not do both?

Roll a 4.6.3.1 (or something) Now, with just libdivecomputer patches,
and when we got something stable, roll a 4.6.4?


//Anton


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

RE: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

[Kai Koehne]

> -Original Message-
> From: Thiago Macieira [mailto:thi...@kde.org]
> Sent: Tuesday, April 18, 2017 6:36 PM
> To: Stefan Fuchs 
> Cc: Lubomir I. Ivanov ; Subsurface Mailing List
> ; Kai Koehne 
> Subject: Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as
> a null device
> 
> Em terça-feira, 18 de abril de 2017, às 09:23:12 PDT, Stefan Fuchs escreveu:
> > /home/stefan/Entwicklung/Subsurface/marble-
> source/src/lib/marble/Marbl
> > eDebug
> > .cpp:27:53: error: passing 'const QLoggingCategory' as 'this' argument
> > of 'void QLoggingCategory::setEnabled(QtMsgType, bool)' discards
> > qualifiers [-fpermissive] loggingCategory().setEnabled(QtDebugMsg,
> > enabled);
> 
> Hold on. This one is weird, because how can you call that non-const method
> if everything is const?
> 
> Kai, how is one supposed to call QLoggingCategory::setEnabled()? Or are we
> not supposed to?
>
> Or should we skip the Q_LOGGING_CATEGORY macro and deploy our own
> code?

The general idea is that the logging category objects represent a view on the 
general logging configuration, and shouldn't be manipulated directly. That is, 
if you call setEnabled() on one object it will be only changing the exact 
object, and not another object that might represent the same category. Also, a 
change in the logging configuration might overwrite your local change at any 
time.

To avoid this, I suggest to change the logging rules either through custom 
logging rules (QLoggingCategory::setFilterRules(), QT_LOGGING_RULES, 
QT_LOGGING_CONF), or by installing a custom logging filter 
(QLoggingCategory::installFilter()). If you 'just' want to set a default 
logging level (so that e.g. QtDebugMsg messages are not printed for your 
categories) you can also set a level in your Q_LOGGING_CATEGORY macro call.

This is also all documented in 
http://doc.qt.io/qt-5/qloggingcategory.html#details . Please raise it if you 
feel that anything is unclear/missing there.

Regards

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

Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

[Lubomir I. Ivanov]

On 19 April 2017 at 11:40, Kai Koehne  wrote:
>
>
>> -Original Message-
>> From: Thiago Macieira [mailto:thi...@kde.org]
>> Sent: Tuesday, April 18, 2017 6:36 PM
>> To: Stefan Fuchs 
>> Cc: Lubomir I. Ivanov ; Subsurface Mailing List
>> ; Kai Koehne 
>> Subject: Re: [PATCH] MarbleDebug: don't use a class extending QIODevice as
>> a null device
>>
>> Em terça-feira, 18 de abril de 2017, às 09:23:12 PDT, Stefan Fuchs escreveu:
>> > /home/stefan/Entwicklung/Subsurface/marble-
>> source/src/lib/marble/Marbl
>> > eDebug
>> > .cpp:27:53: error: passing 'const QLoggingCategory' as 'this' argument
>> > of 'void QLoggingCategory::setEnabled(QtMsgType, bool)' discards
>> > qualifiers [-fpermissive] loggingCategory().setEnabled(QtDebugMsg,
>> > enabled);
>>
>> Hold on. This one is weird, because how can you call that non-const method
>> if everything is const?
>>
>> Kai, how is one supposed to call QLoggingCategory::setEnabled()? Or are we
>> not supposed to?
>>
>> Or should we skip the Q_LOGGING_CATEGORY macro and deploy our own
>> code?
>
> The general idea is that the logging category objects represent a view on the 
> general logging configuration, and shouldn't be manipulated directly. That 
> is, if you call setEnabled() on one object it will be only changing the exact 
> object, and not another object that might represent the same category. Also, 
> a change in the logging configuration might overwrite your local change at 
> any time.
>
> To avoid this, I suggest to change the logging rules either through custom 
> logging rules (QLoggingCategory::setFilterRules(), QT_LOGGING_RULES, 
> QT_LOGGING_CONF), or by installing a custom logging filter 
> (QLoggingCategory::installFilter()). If you 'just' want to set a default 
> logging level (so that e.g. QtDebugMsg messages are not printed for your 
> categories) you can also set a level in your Q_LOGGING_CATEGORY macro call.
>
> This is also all documented in 
> http://doc.qt.io/qt-5/qloggingcategory.html#details . Please raise it if you 
> feel that anything is unclear/missing there.
>

hi Thiago,

following Kai's explanation can we use something in these lines:

void MarbleDebug::setEnabled(bool enabled)
{
QLoggingCategory::setFilterRules(QString("marble.debug=%1").arg(enabled
? "true", "false"));
}

and likely remove isEnabled() as it's not needed?

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

Re: preparing for a 4.6.4

[Davide DB]

Italian translation ready (just in case)

-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: preparing for a 4.6.4

[Davide DB]

As usual :)

../smtk-import/smartrak.c:254

"Sank time"

What does it mean?
Is it "time to reach the bottom" for a diver or is it something wreck
related? You'll never know with Smartrak.

On 19 April 2017 at 06:15, Dirk Hohndel  wrote:
> I know, we've spent all this time on Subsurface-mobile and the bugs there
> still aren't fully understood (let alone fixed). But I can't forget about
> our main app again - and we really need to get an update out to our users
> with the fixed libdivecomputer.
>
> I have two options. I can do a quick new build that uses the new
> libdivecomputer and the Subsurface that we used for 4.6.3. Or I can use
> the current master and stabilize this.
>
> The advantage of the first option is that we had really really complete
> translations for that. The advantage of the second option is that we'd get
> the other new things out to our users, including all the fixes to the
> planner, the manual entry of depth and duration, etc.
>
> I'm kinda leaning towards the second option but that means we need to
> spend a week or two, focused on testing the latest master and finishing
> the translations, again. If people have strong feelings one way or
> another, please speak up.
>
> I'll do new "daily" builds next and also make sure that all the source
> strings are pushed to Transifex, just in case.
>
> Thanks
>
> /D
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface



-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Crash on Windows when importing dives via USB from OSTC2

[Jan Mulder]

On 19-04-17 09:24, Stefan Fuchs wrote:

Am 19.04.2017 um 09:09 schrieb Miika Turkia:

git bisect is your friend

miika

On 19 Apr 2017, at 9.48, Stefan Fuchs > wrote:


unfortunately I see a new crash when importing via USB from my 
OSTC2. This happens under Windows 10 with current master and was not 
there about 2 weeks ago. It happens every time at the end of data 
transfer from the dive computer.


Stack trace attached. I already started to think about one of the 
latest commits being the root cause but from the stack trace I can't 
see a direct link to one of the changes I'm aware off.





Yes, can try but not before the weekend. Maybe someone has a quick guess.
Shall we start looking at libdivecomputer or Subsurface?


Well, my first question would be: does it also crash on Linux? For me, 
that would simplify tracking down the issue. Then, remember the recent 
changes in the build stuff. From my commit fd40a29ec858a onwards we are 
pulling a newer libdc. The old location was not not updated since some 
time. This meaning that the change in libdc is relatively big. libdc or 
not can easily be tested. Pull libdc from the old location, and 
recompile. Notice that the official 4.6.3 on Windows does not contain a 
fix from Anton in libdc (6fccf5923f31) from beginning of 2017, due to 
build scripting issues (see 
https://github.com/Subsurface-divelog/subsurface/issues/301), so be very 
careful when bisecting something in the libdc area.


Further, interfacing on Linux with my OSTC3 (ok, over BT) works just 
fine 


best,

--jan

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

Re: Crash on Windows when importing dives via USB from OSTC2

[Stefan Fuchs]

Am 19.04.2017 um 09:09 schrieb Miika Turkia:
> git bisect is your friend
>
> miika
>
> On 19 Apr 2017, at 9.48, Stefan Fuchs  > wrote:
>
>> unfortunately I see a new crash when importing via USB from my OSTC2.
>> This happens under Windows 10 with current master and was not there
>> about 2 weeks ago. It happens every time at the end of data transfer
>> from the dive computer.
>>
>> Stack trace attached. I already started to think about one of the
>> latest commits being the root cause but from the stack trace I can't
>> see a direct link to one of the changes I'm aware off.
>>
>
Yes, can try but not before the weekend. Maybe someone has a quick guess.
Shall we start looking at libdivecomputer or Subsurface?

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: Crash on Windows when importing dives via USB from OSTC2

[Miika Turkia]

git bisect is your friend

miika

> On 19 Apr 2017, at 9.48, Stefan Fuchs  wrote:
> 
> Hi All,
> 
> unfortunately I see a new crash when importing via USB from my OSTC2. This 
> happens under Windows 10 with current master and was not there about 2 weeks 
> ago. It happens every time at the end of data transfer from the dive computer.
> 
> Stack trace attached. I already started to think about one of the latest 
> commits being the root cause but from the stack trace I can't see a direct 
> link to one of the changes I'm aware off.
> 
> 
> 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
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface