Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

2018-06-20 Thread Dirk Hohndel 
Hi Davide,

We just merged the patches from Anton, a new test build should show up in
https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous 

soon.
This link always gets you the latest test installer - and sometimes it may be
missing because it's just being built (or because there was an error in the
build). If that's the case (a) wait 10 minutes and (b) if it's still missing, 
send
an email to the list so we know to kick it :-)

> On Jun 18, 2018, at 9:15 PM, Davide DB  wrote:
> 
> I'm sure that this problem will solved.

The frustrating part is that it took so long. And that is definitely my fault
because as I said, I didn't pay enough attention to the issue.

> As you see my report is dated back on december 2017. I cannot blame
> nobody except my self for being lenient checking my profiles after
> discovering that bug. On the other side I know well how open-source
> projects works. People write code or generally help (like me) for what
> is important for themselves and not so quickly for other things that
> are not so important for themselves. No one gets paid for the work, so
> one cannot force anybody.

So true

> Hence this bug was thought provoking for me. I've been always a
> minority but with a divecan shearwater controller I thought I was
> mainstream but I was wrong. This bug hit me hard. I have over 60 ccr
> maniacally logged dives with completely wrong or missing pO2 samples.

I am reasonably certain that we can rectify this.

Please make a copy of your dive data (simply export them to an XML
file), open that XML file, and then re-download from the Shearwater.
In the Download dialog check the two boxes (sorry, English text, I'm
sure you can figure out the Italian version):
"Force download of all dives"
"Always prefer downloaded dives"

With these options checked it should keep all of your other data like
notes, buddies, etc, but replace the downloaded data with the new
version which we assume will be corrected with the fix in place.

So this should be reasonably easy to recover from.

> A CCR dive without pO2 samples is like a cake with no sugar. If I
> still have them on my Petrel (I never investigated how many profiles
> it stores) I should import everything from scratch into Subsurface and
> compile everything again. Not a nice perspective for the future. Right
> now I'm diving two/three times per week so the count will increase
> rapidly. I've tons of notes, wrecks positions, all dives have GPS
> locations...

See above - you should be able to do this without having to manually
re-edit all of this work!

> I think I will use Shearwater desktop for the time being
> and leave old dives in Subsurface. When a complete solution will be
> found I will evaluate how much effort is needed to realign everything
> because I do not see a real solution coming soon.

This is where my ignorance shows. I thought Anton's fix solves the problem
for you. Can you explain in non-CCR diver terms what is still missing?

> Anton (and now Aaron) patches are blessed workarounds but  don't solve
> the inner problem:  for some mysterious reason, on some devices we
> cannot use/decode Shearwater data.

If someone can extract this as one or two sample dives that show the
problem and add words that make enough sense to me, I'll reach out
to Shearwater again to see if they have suggestions. I know I sent them
one of the earliest exchanges on this topic but neither they nor I really
understood the problem and it got dropped

> Moreover other questions remained unanswered; In one year my unique
> Petrel was identified as 3 different devices with random number of
> sensors. My logbook is a mess and nobody knows the reason.

Also something I can ask about if you give me more information.

> Frankly speaking I think nobody with a shearwater petrel ccr
> controller knowing in advance this bug  would use Subsurface as their
> logbook. My profiles shows 2,1 bar of pO2 at 80 meters. Nothing you
> would show to anybody.

That would be, err, unsafe. Even I know that.

> Months ago, given your good relationship with Shearwater, I warmly
> recommended to contact them privately asking info on this nasty
> behaviour of some devices.

I will look again if there are more emails that I've missed.

Again, all I can do is apologize. You've done so much for Subsurface
and we have not taken good care of you. I hope you'll consider the
option I outlined above.

All the best

/D

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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

2018-06-20 Thread Linus Torvalds 
On Thu, Jun 21, 2018 at 4:20 AM Dirk Hohndel  wrote:
>
> Thanks, Anton. This looks reasonable. Assuming Linus sees no issue we can add 
> this today and if Davide is still interested he can test the new binaries.

I've taken them.

I pulled Jef's fix for the Uwatec Aladin Tec too.

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

Re: Product / vendor on mobile download

2018-06-20 Thread Linus Torvalds 
On Thu, Jun 21, 2018 at 6:52 AM Linus Torvalds
 wrote:
>
> On Thu, Jun 21, 2018 at 4:16 AM Dirk Hohndel  wrote:
> >
> > Linus, could that be the actual culprit?
>
> Very possibly.

Oh, I should have read the whole thread. Apparently the real cause has
been found, and was not the libdivecomputer custom IO changes.

Never mind. That should teach me.

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

Re: Product / vendor on mobile download

2018-06-20 Thread Linus Torvalds 
On Thu, Jun 21, 2018 at 4:16 AM Dirk Hohndel  wrote:
>
> This sounds like the ftdi code isn't triggered. Maybe that's what is actually 
> broken - when we did the NG merge of libdivecomputer...
>
> Linus, could that be the actual culprit?

Very possibly.

I verified the build (on desktop, but with libftdi enabled), but not
that anything _worked_.

But I didn't bring my ftdi computer (HelO2 should still work) with me,
so I still can't test.

I'll at least try to eyeball it.

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

Re: Product / vendor on mobile download

2018-06-20 Thread Dirk Hohndel 

> On Jun 21, 2018, at 5:36 AM, Anton Lundin  wrote:
> 
> Now the selection dialogs works, and I've found what broke all libusb
> based communication and sent a PR.
> 
> https://github.com/Subsurface-divelog/subsurface/pull/1416 
> 

Merged, I'll make a new Android beta in a few moments.

> Now I have working ftdi and libusb based downloads for both my OSTC3 and
> Suunto Eon Steel.

Excellent. Eon Steel over USB?

> Spoiler. For 6-7 dives on the Eon Steel its about a bazillion times
> faster.

Eon Steel over BLE is hard to stomach for just downloading a day's worth
of diving. Yes, USB is about a bazillion times faster there.

Awesome

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

Re: Product / vendor on mobile download

2018-06-20 Thread Dirk Hohndel 

> On Jun 21, 2018, at 5:40 AM, Anton Lundin  wrote:
> 
> On 20 June, 2018 - Dirk Hohndel wrote:
> 
>> Hi Anton,
>> 
>>> I was also trying to test the usb code for the suunto eon steel, but the
>>> whole went sideways and as far as I've read the code there's no way to
>>> enable the libdivecomputer logging. Even when I changed all the saveLog
>>> / data.libdc_log to a hard coded true I didn't get any logs.
>> 
>> Are you still talking about Android? That should always turn on the
>> libdivecomputer log.
>> But again, I've never been able to test any of this - I've enabled it, but no
>> one ever gave feedback on it, which made me think that no one actually
>> cared (given that the EON Core/Steel work with BLE)
> 
> Still no libdivecomputer log anywhere to be found.
> 
> I think we should always enable it, and plumb it up into qDebug() so it
> all ends up in the same log buffer.

It is always enabled. I'm confused :-)

When you click on the button in the About page, you get both the 
subsurface.log and the libdivecomputer.log -- you saw that in the
email that Thomas sent, for example

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

Re: Subsurface on Opensuse Tumbleweed

2018-06-20 Thread Thiago Macieira 
On Wednesday, 20 June 2018 13:53:03 PDT Dietrich Meyer wrote:
> Here is another backtrace, running subsurface 4.7.8-372 on Tumbleweed, not
> sure if this can give any more clues...

Sorry, it's exactly the same:

> #9  0x7fd01de07127 in QPainter::begin(QPaintDevice*) () at /usr/lib64/
> libQt5Gui.so.5
> #10 0x7fd01ec586ce in  () at /usr/lib64/libQt5Widgets.so.5
> #11 0x7fd01ec58b4c in QHeaderView::mousePressEvent(QMouseEvent*) () at /
> usr/lib64/libQt5Widgets.so.5

-- 
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: Subsurface on Opensuse Tumbleweed

2018-06-20 Thread Dietrich Meyer 
Hi,

> On Wednesday, 20 June 2018 12:35:45 PDT Martin Gysel wrote:
> > I get the following backtrace:
> > 
> > QPainter::begin: Paint device returned engine == 0, type: 2
> 


Here is another backtrace, running subsurface 4.7.8-372 on Tumbleweed, not 
sure if this can give any more clues...
-
Application: subsurface (subsurface), signal: Aborted
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fd024f0ce80 (LWP 5979))]

Thread 8 (Thread 0x7fcfda5d5700 (LWP 5992)):
#0  0x7fd01b8e3179 in poll () at /lib64/libc.so.6
#1  0x7fd016620429 in  () at /usr/lib64/libglib-2.0.so.0
#2  0x7fd01662053c in g_main_context_iteration () at /usr/lib64/
libglib-2.0.so.0
#3  0x7fd01c9c988b in 
QEventDispatcherGlib::processEvents(QFlags) () 
at /usr/lib64/libQt5Core.so.5
#4  0x7fd01c97114a in 
QEventLoop::exec(QFlags) () at /usr/lib64/
libQt5Core.so.5
#5  0x7fd01c7ac36a in QThread::exec() () at /usr/lib64/libQt5Core.so.5
#6  0x7fd01c7b6b58 in  () at /usr/lib64/libQt5Core.so.5
#7  0x7fd02407459b in start_thread () at /lib64/libpthread.so.0
#8  0x7fd01b8eda1f in clone () at /lib64/libc.so.6

Thread 7 (Thread 0x7fcfd9dd4700 (LWP 5990)):
#0  0x7fd02407a899 in pthread_cond_timedwait@@GLIBC_2.3.2 () at /lib64/
libpthread.so.0
#1  0x7fd01c7b7820 in QWaitCondition::wait(QMutex*, unsigned long) () at /
usr/lib64/libQt5Core.so.5
#2  0x7fd01c7ae81e in  () at /usr/lib64/libQt5Core.so.5
#3  0x7fd01c7b6b58 in  () at /usr/lib64/libQt5Core.so.5
#4  0x7fd02407459b in start_thread () at /lib64/libpthread.so.0
#5  0x7fd01b8eda1f in clone () at /lib64/libc.so.6

Thread 6 (Thread 0x7fcfe0fc6700 (LWP 5986)):
#0  0x7fd02407db34 in read () at /lib64/libpthread.so.0
#1  0x7fd016664ab0 in  () at /usr/lib64/libglib-2.0.so.0
#2  0x7fd01661ff17 in g_main_context_check () at /usr/lib64/
libglib-2.0.so.0
#3  0x7fd0166203d0 in  () at /usr/lib64/libglib-2.0.so.0
#4  0x7fd01662053c in g_main_context_iteration () at /usr/lib64/
libglib-2.0.so.0
#5  0x7fd01c9c988b in 
QEventDispatcherGlib::processEvents(QFlags) () 
at /usr/lib64/libQt5Core.so.5
#6  0x7fd01c97114a in 
QEventLoop::exec(QFlags) () at /usr/lib64/
libQt5Core.so.5
#7  0x7fd01c7ac36a in QThread::exec() () at /usr/lib64/libQt5Core.so.5
#8  0x7fd01d725f85 in  () at /usr/lib64/libQt5Qml.so.5
#9  0x7fd01c7b6b58 in  () at /usr/lib64/libQt5Core.so.5
#10 0x7fd02407459b in start_thread () at /lib64/libpthread.so.0
#11 0x7fd01b8eda1f in clone () at /lib64/libc.so.6

Thread 5 (Thread 0x7fcff29ba700 (LWP 5985)):
#0  0x7fd02407a56c in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/
libpthread.so.0
#1  0x7fcff35068db in  () at /usr/lib64/dri/i965_dri.so
#2  0x7fcff3506607 in  () at /usr/lib64/dri/i965_dri.so
#3  0x7fd02407459b in start_thread () at /lib64/libpthread.so.0
#4  0x7fd01b8eda1f in clone () at /lib64/libc.so.6

Thread 4 (Thread 0x7fd00dfbe700 (LWP 5982)):
#0  0x7fd016665e29 in g_mutex_lock () at /usr/lib64/libglib-2.0.so.0
#1  0x7fd01661fe4c in g_main_context_check () at /usr/lib64/
libglib-2.0.so.0
#2  0x7fd0166203d0 in  () at /usr/lib64/libglib-2.0.so.0
#3  0x7fd01662053c in g_main_context_iteration () at /usr/lib64/
libglib-2.0.so.0
#4  0x7fd01c9c988b in 
QEventDispatcherGlib::processEvents(QFlags) () 
at /usr/lib64/libQt5Core.so.5
#5  0x7fd01c97114a in 
QEventLoop::exec(QFlags) () at /usr/lib64/
libQt5Core.so.5
#6  0x7fd01c7ac36a in QThread::exec() () at /usr/lib64/libQt5Core.so.5
#7  0x7fd0159f2a85 in  () at /usr/lib64/libQt5DBus.so.5
#8  0x7fd01c7b6b58 in  () at /usr/lib64/libQt5Core.so.5
#9  0x7fd02407459b in start_thread () at /lib64/libpthread.so.0
#10 0x7fd01b8eda1f in clone () at /lib64/libc.so.6

Thread 3 (Thread 0x7fd00e9ff700 (LWP 5981)):
#0  0x7fd01b8e3179 in poll () at /lib64/libc.so.6
#1  0x7fd016620429 in  () at /usr/lib64/libglib-2.0.so.0
#2  0x7fd01662053c in g_main_context_iteration () at /usr/lib64/
libglib-2.0.so.0
#3  0x7fd01c9c988b in 
QEventDispatcherGlib::processEvents(QFlags) () 
at /usr/lib64/libQt5Core.so.5
#4  0x7fd01c97114a in 
QEventLoop::exec(QFlags) () at /usr/lib64/
libQt5Core.so.5
#5  0x7fd01c7ac36a in QThread::exec() () at /usr/lib64/libQt5Core.so.5
#6  0x7fd01c7b6b58 in  () at /usr/lib64/libQt5Core.so.5
#7  0x7fd02407459b in start_thread () at /lib64/libpthread.so.0
#8  0x7fd01b8eda1f in clone () at /lib64/libc.so.6

Thread 2 (Thread 0x7fd00f49d700 (LWP 5980)):
#0  0x7fd02407a56c in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/
libpthread.so.0
#1  0x7fd01be87b3c in 
std::condition_variable::wait(std::unique_lock&) () at /usr/lib64/
libstdc++.so.6
#2  0x7fd021a71f17 in  () at /usr/lib64/libQt5WebKit.so.5
#3  0x7fd021a72059 in  () at /usr/lib64/libQt5WebKit.so.5
#4  0x7fd01be8d35f in  () at /usr/lib64/libstdc++.so.6
#5

Re: Product / vendor on mobile download

2018-06-20 Thread Thomas Fänge 
Sorry for this, I sent the video directly to Dirk, since it was too large
for the forum mailserver...

Best regards,
Thomas

Den ons 20 juni 2018 21:53Thomas Fänge  skrev:

>
> Hi Dirk!
>
> No problem, happy to help out!
>
> I include a video - easier to explain. When BT is on, I can only see
> Mac-addresses in the drop-down box, and when I turn BT off, I can only see
> FTDI.  Previously both Mac-addresses and FTDI was available even when BT
> was on.
>
> I guessed previously that dc_serial_open failed, since Libdivecomputer.log
> says:
>
> Subsurface: v4.7.8-213-g6a91611e90cc, built with libdivecomputer
>
> v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
> INFO: Open: name=ftdi
> ERROR: No such file or directory (2) [in
> /data/android/subsurface/libdivecomputer/src/serial_posix.c:295
> (dc_serial_open)]
>
> This I think resulted in the "Unsupported operation" error message.
>
> Best regards,
> Thomas
>
> Den ons 20 juni 2018 21:16Dirk Hohndel  skrev:
>
>> Hi Thomas,
>>
>> Thanks for testing. I wasn't all that optimistic, but based on Anton's
>> post it seemed possible that it was as simple as this.
>>
>> > On Jun 20, 2018, at 11:07 PM, Thomas Fänge 
>> wrote:
>> >
>> > No success, it just behaves as before, same log as before, but the
>> reference to "localBtDevice isn't valid or not connect" I don't recognize
>> from before. I still think that the log at 27.556:"Unsupported operation"
>> should tell us something.
>> >
>> > "27.553: DCDownloadThread started for Mares Puck Pro on FTDI"
>> > Starting download from ftdi
>> > Starting the thread 0
>> > Finishing the thread Unable to open %s %s (%s) dives downloaded 0
>>
>> I need to fix that debug message. Grmbl.
>> So we still fail to open the FTDI device - but at least we are trying to
>> open the right thing.
>>
>> > "27.556: Unsupported operation"
>> > no new dives downloaded
>> > "27.557: DCDownloadThread finished"
>> > localBtDevice isn't valid or not connecta
>> >
>> > Same on all devices I tested on.
>> >
>> > I also noticed that I had to disable Bluetooth for FTDI to appear as a
>> valid option for connection.
>>
>> That's strange, can you say more? I see FTDI here on my devices with BT
>> enabled.
>>
>> > Nor can I test with version 4.7.4.280 that other claims should work,
>> since Mares DC is not enabled in that version. 
>>
>> Worst case I can go back and hack that, I guess...
>>
>> > And yes, I have new dives on the DC... 
>>
>> The error "unable to open" made it clear that this is not just a "no new
>> dives" issue, but thanks for explicitly stating that.
>>
>> > -- libdivecomputer.log --
>> > Subsurface: v4.7.8-287-g76f61468e690, built with libdivecomputer
>> v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
>> > INFO: Open: name=ftdi
>> > ERROR: No such file or directory (2) [in
>> /data/android/subsurface/libdivecomputer/src/serial_posix.c:295
>> (dc_serial_open)]
>>
>> This sounds like the ftdi code isn't triggered. Maybe that's what is
>> actually broken - when we did the NG merge of libdivecomputer...
>>
>> Linus, could that be the actual culprit?
>>
>> /D
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Product / vendor on mobile download

2018-06-20 Thread Anton Lundin 
On 20 June, 2018 - Dirk Hohndel wrote:

> Hi Anton,
> 
> > I was also trying to test the usb code for the suunto eon steel, but the
> > whole went sideways and as far as I've read the code there's no way to
> > enable the libdivecomputer logging. Even when I changed all the saveLog
> > / data.libdc_log to a hard coded true I didn't get any logs.
> 
> Are you still talking about Android? That should always turn on the
> libdivecomputer log.
> But again, I've never been able to test any of this - I've enabled it, but no
> one ever gave feedback on it, which made me think that no one actually
> cared (given that the EON Core/Steel work with BLE)

Still no libdivecomputer log anywhere to be found.

I think we should always enable it, and plumb it up into qDebug() so it
all ends up in the same log buffer.


//Anton


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

Re: Product / vendor on mobile download

2018-06-20 Thread Anton Lundin 
On 20 June, 2018 - Dirk Hohndel wrote:

> 
> > On Jun 20, 2018, at 4:30 AM, Thomas Fänge  wrote:
> > 
> > Hi,
> > 
> > What several people have mentioned and tested, is that version 4.7.4.280 in 
> > the Android app seems to work with USB OTG, but any version after that 
> > fails. I'm running Oreo 8.0, and I have other apps that work with my DC 
> > using OTG, so Oreo and the HW supports it.
> 
> Could you try the latest Android beta. I'm not able to test it, but there's a 
> chance that I un-broke what got broken since 4.7.4.280.
> I'd love to hear feedback good or bad. Preferably with log files (you can now 
> get those by clicking on the button in the About screen which copies all the 
> logs to the clipboard for easy pasting into email)
> 

Now the selection dialogs works, and I've found what broke all libusb
based communication and sent a PR.

https://github.com/Subsurface-divelog/subsurface/pull/1416


Now I have working ftdi and libusb based downloads for both my OSTC3 and
Suunto Eon Steel.


Spoiler. For 6-7 dives on the Eon Steel its about a bazillion times
faster.


//Anton


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

Re: Subsurface on Opensuse Tumbleweed

2018-06-20 Thread Thiago Macieira 
On Wednesday, 20 June 2018 12:35:45 PDT Martin Gysel wrote:
> I get the following backtrace:
> 
> QPainter::begin: Paint device returned engine == 0, type: 2

Thanks Martin.

I don't see anything in the backtrace belonging to Subsurface, so this appears 
to be a regular Qt regression. Turns out there were a lot of changes to 
QHeaderView earlier this year, so one of the must be at fault. I can't spot 
which one just by looking though.

To help constrain the search, do you know if this warning was printed with 
Qt 5.10 too?

> #3  0x72724f74 in QPainter::begin(QPaintDevice*) () from
> /usr/lib64/libQt5Gui.so.5
> #4  0x73551777 in  () from /usr/lib64/libQt5Widgets.so.5
> #5  0x73551c0c in QHeaderView::mousePressEvent(QMouseEvent*) ()
> from /usr/lib64/libQt5Widgets.so.5

I'm trying to guess which frame is that ??, but it's not clear what it is. My 
first guess was QHeaderViewPrivate::setupSectionIndicator, which does have a 
QPainter, but that function is painting on a QPixmap and that wouldn't have 
printed the warning. But that leaves me out of options.

Can you install the debug symbols for the library?

zypper in libQt5Gui5-debuginfo

That should resolve the ?? to something useful, and possibly also give us line 
numbers.

PS: I'm experimenting with an optimised build of Qt5 that you can find at 
https://build.opensuse.org/package/show/
home:thiagomacieira:branches:openSUSE:Factory/libqt5-qtbase

-- 
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: Product / vendor on mobile download

2018-06-20 Thread Matt Thompson 
>
> > -- libdivecomputer.log --
> > Subsurface: v4.7.8-287-g76f61468e690, built with libdivecomputer
> v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
> > INFO: Open: name=ftdi
> > ERROR: No such file or directory (2) [in /data/android/subsurface/
> libdivecomputer/src/serial_posix.c:295 (dc_serial_open)]
>
> This sounds like the ftdi code isn't triggered. Maybe that's what is
> actually broken - when we did the NG merge of libdivecomputer...
>
> Linus, could that be the actual culprit?
>
>
I think there is something there.  When the NG work was happening I
reported that I was unable to download dives from my Suunto D4i on any the
desktop platforms (macOS, Linux, Windows 10) using the NG version but had
no problems with the released versions at the time.  Sorry I didn't have
time to continue testing and I just assumed this had been resolved.  I'll
grab the latest nightly tonight and test again.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface on Opensuse Tumbleweed

2018-06-20 Thread Martin Gysel 
Am 20.06.2018 um 19:46 schrieb Thiago Macieira:
> On Wednesday, 20 June 2018 07:23:27 PDT guillaume.gar...@free.fr wrote:
>> If I click the dive number it is fine. Otherwise, I get a blank area with
>> the following messages in console: QPainter::begin: Paint device returned
>> engine == 0, type: 2
>>   QPainter::setFont: Painter not active
>>   QPainter::setOpacity: Painter not active
>>   QPainter::end: Painter not active, aborted
> Can you run with QT_FATAL_WARNINGS=1 and once Subsurface aborts, get the 
> backtrace from these warnings?
>
> If these are not the first warnings printed by Subsurface, increase the 
> number 
> 1 to be the number of warnings until that "QPainter::begin".
>
I get the following backtrace:

QPainter::begin: Paint device returned engine == 0, type: 2

Thread 1 "subsurface" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht
gefunden.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x701c1ec1 in __GI_abort () at abort.c:79
#2  0x7118ffb0 in QMessageLogger::warning(char const*, ...)
const () from /usr/lib64/libQt5Core.so.5
#3  0x72724f74 in QPainter::begin(QPaintDevice*) () from
/usr/lib64/libQt5Gui.so.5
#4  0x73551777 in ?? () from /usr/lib64/libQt5Widgets.so.5
#5  0x73551c0c in QHeaderView::mousePressEvent(QMouseEvent*) ()
from /usr/lib64/libQt5Widgets.so.5
#6  0x7332823f in QWidget::event(QEvent*) () from
/usr/lib64/libQt5Widgets.so.5
#7  0x733c9a5e in QFrame::event(QEvent*) () from
/usr/lib64/libQt5Widgets.so.5
#8  0x73540cbb in QAbstractItemView::viewportEvent(QEvent*) ()
from /usr/lib64/libQt5Widgets.so.5
#9  0x7355075c in QHeaderView::viewportEvent(QEvent*) () from
/usr/lib64/libQt5Widgets.so.5
#10 0x7134b85a in
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*,
QEvent*) () from /usr/lib64/libQt5Core.so.5
#11 0x732e8d55 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#12 0x732f084f in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib64/libQt5Widgets.so.5
#13 0x7134ba97 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) () from /usr/lib64/libQt5Core.so.5
#14 0x732ef822 in QApplicationPrivate::sendMouseEvent(QWidget*,
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool)
() from /usr/lib64/libQt5Widgets.so.5
#15 0x733428e3 in ?? () from /usr/lib64/libQt5Widgets.so.5
#16 0x73344ea9 in ?? () from /usr/lib64/libQt5Widgets.so.5
#17 0x732e8d7c in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#18 0x732f02f4 in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib64/libQt5Widgets.so.5
#19 0x7134ba97 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) () from /usr/lib64/libQt5Core.so.5
#20 0x725320a3 in
QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*)
() from /usr/lib64/libQt5Gui.so.5
#21 0x72533d25 in
QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*)
() from /usr/lib64/libQt5Gui.so.5
#22 0x7250cc7b in
QWindowSystemInterface::sendWindowSystemEvents(QFlags)
() from /usr/lib64/libQt5Gui.so.5
#23 0x7fffe370a9eb in ?? () from /usr/lib64/libQt5XcbQpa.so.5
#24 0x7134a88a in
QEventLoop::exec(QFlags) () from
/usr/lib64/libQt5Core.so.5
#25 0x71353270 in QCoreApplication::exec() () from
/usr/lib64/libQt5Core.so.5
#26 0x5566b527 in main ()

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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

2018-06-20 Thread Martin Long 
I'll test them either way once a binary is available. This problem has
affected me too.

On Wed, 20 Jun 2018, 20:20 Dirk Hohndel,  wrote:

> Thanks, Anton. This looks reasonable. Assuming Linus sees no issue we can
> add this today and if Davide is still interested he can test the new
> binaries.
>
> /D
>
> > On Jun 21, 2018, at 4:06 AM, Anton Lundin  wrote:
> >
> > Of course I forgot to even compile it, so here's a updated 0002 patch
> > which actually compiles.
> >
> >
> > //Anton
> >
> >
> > On 20 June, 2018 - Anton Lundin wrote:
> >
> >> Here's the patches.
> >>
> >> I splitted them into two, so Jef can cherry-pick the first one, and a
> >> second one which adds a strings that says the source of the PPO2 values.
> >>
> >>
> >> //Anton
> >>
> >>
> >> On 18 June, 2018 - Dirk Hohndel wrote:
> >>
> >>> As I said before, I can't seem to find that patch. No idea why. If
> someone sends it to me I'll be happy to add it. I said that before as well.
> >>> If hate to see Davide abandon Subsurface over this...
> >>>
> >>> /D
> >>>
> >>> On June 18, 2018 5:39:43 AM GMT+09:00, "Long, Martin" <
> mar...@longhome.co.uk> wrote:
>  Dirk,
> 
>  I would say that Anton's patch would do it as an interim solution. Jef
>  isn't keen, as he has a better solution, but doesn't have the time to
>  work
>  on it yet. However, it does remove the regression, and prevent further
>  loss
>  of data in imports, until the *ideal* solution can be added. Data is
>  still
>  being lost, which is frustrating - I can't seem my actual ppO2 from
>  dives I
>  did yesterday, and now I never will, for those dives.
> 
>  Rather take an imperfect patch, which works now, than leave it broken
>  waiting for the perfect one (and no idea of how long it will take).
> 
>  On 17 June 2018 at 12:02, Dirk Hohndel  wrote:
> 
> >
> > On Jun 17, 2018, at 6:52 PM, Davide DB  wrote:
> >
> > On Thu, Jun 14, 2018, 15:34 Long, Martin 
>  wrote:
> >
> >> I'm in agreement with Davide that any interim solution we can get
>  running
> >> is better than the way it is working now. It's a regression, and tbh
>  if
> >> there isn't an interim solution then it ought to be reverted to the
>  old
> >> behaviour. At the moment I'm having to use Shearwater desktop for
>  reviewing
> >> all my logs.
> >>
> >
> > I had to stop using Subsurface for the time being. First time in so
>  many
> > years.
> >
> > If the bug will be solved I would have to transfer and compile from
> > scratch more than 60 dives (until now). I don't know if I will have
>  the
> > time or will to do all this work and frankly speaking I'm tired to be
> > always a minority.
> >
> > Farewell my friends. It has been a nice journey. Thank you all for
>  the
> > amazing work.
> >
> >>
> > Sorry to see you leave and thank you for all the great contributions.
> > Subsurface-mobile wouldn't be anywhere near where it is today if it
>  wasn't
> > for you.
> >
> > I'll admit that I completely tune out rebreather discussions - I
>  assume
> > that those who care about rebreathers will figure things out and will
>  send
> > me pull requests.
> >
> > Since I'd hate to see you go, is there actually something that we can
>  do
> > to fix this? Or are we (as in so many small odd corner cases) at a
>  point
> > where we just don't have the right person to work on something (like
>  the
> > FTDI download on Android)?
> >
> > /D
> >
> >
> >>>
> >>> --
> >>> from my phone.
> >>
> >>> ___
> >>> subsurface mailing list
> >>> subsurface@subsurface-divelog.org
> >>>
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> >>
> >>
> >> --
> >> Anton Lundin +46702-161604
> >
> >>> From c60d498661bac58e4182dfaab8d7e3e27b968b5b Mon Sep 17 00:00:00 2001
> >> From: Anton Lundin 
> >> Date: Wed, 20 Jun 2018 20:04:55 +0200
> >> Subject: [PATCH 1/2] shearwater: Fallback to average/voted ppo2
> >>
> >> If we can't find any calibration values for the individual sensors,
> >> fallback to emitting the average/voted ppo2 instead, so users always get
> >> a ppo2 value.
> >>
> >> Signed-off-by: Anton Lundin 
> >> ---
> >> src/shearwater_predator_parser.c | 26 +-
> >> 1 file changed, 13 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/src/shearwater_predator_parser.c
> b/src/shearwater_predator_parser.c
> >> index dda042c..6b1ae43 100644
> >> --- a/src/shearwater_predator_parser.c
> >> +++ b/src/shearwater_predator_parser.c
> >> @@ -669,19 +669,19 @@ shearwater_predator_parser_samples_foreach
> (dc_parser_t *abstract, dc_sample_cal
> >>  if ((status & OC) == 0) {
> >>  // PPO2
> >>  if ((status & PPO2_EXTERNAL) == 0) {
>

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

2018-06-20 Thread Dirk Hohndel 
Thanks, Anton. This looks reasonable. Assuming Linus sees no issue we can add 
this today and if Davide is still interested he can test the new binaries.

/D

> On Jun 21, 2018, at 4:06 AM, Anton Lundin  wrote:
> 
> Of course I forgot to even compile it, so here's a updated 0002 patch
> which actually compiles.
> 
> 
> //Anton
> 
> 
> On 20 June, 2018 - Anton Lundin wrote:
> 
>> Here's the patches.
>> 
>> I splitted them into two, so Jef can cherry-pick the first one, and a
>> second one which adds a strings that says the source of the PPO2 values.
>> 
>> 
>> //Anton
>> 
>> 
>> On 18 June, 2018 - Dirk Hohndel wrote:
>> 
>>> As I said before, I can't seem to find that patch. No idea why. If someone 
>>> sends it to me I'll be happy to add it. I said that before as well.
>>> If hate to see Davide abandon Subsurface over this...
>>> 
>>> /D
>>> 
>>> On June 18, 2018 5:39:43 AM GMT+09:00, "Long, Martin" 
>>>  wrote:
 Dirk,
 
 I would say that Anton's patch would do it as an interim solution. Jef
 isn't keen, as he has a better solution, but doesn't have the time to
 work
 on it yet. However, it does remove the regression, and prevent further
 loss
 of data in imports, until the *ideal* solution can be added. Data is
 still
 being lost, which is frustrating - I can't seem my actual ppO2 from
 dives I
 did yesterday, and now I never will, for those dives.
 
 Rather take an imperfect patch, which works now, than leave it broken
 waiting for the perfect one (and no idea of how long it will take).
 
 On 17 June 2018 at 12:02, Dirk Hohndel  wrote:
 
> 
> On Jun 17, 2018, at 6:52 PM, Davide DB  wrote:
> 
> On Thu, Jun 14, 2018, 15:34 Long, Martin 
 wrote:
> 
>> I'm in agreement with Davide that any interim solution we can get
 running
>> is better than the way it is working now. It's a regression, and tbh
 if
>> there isn't an interim solution then it ought to be reverted to the
 old
>> behaviour. At the moment I'm having to use Shearwater desktop for
 reviewing
>> all my logs.
>> 
> 
> I had to stop using Subsurface for the time being. First time in so
 many
> years.
> 
> If the bug will be solved I would have to transfer and compile from
> scratch more than 60 dives (until now). I don't know if I will have
 the
> time or will to do all this work and frankly speaking I'm tired to be
> always a minority.
> 
> Farewell my friends. It has been a nice journey. Thank you all for
 the
> amazing work.
> 
>> 
> Sorry to see you leave and thank you for all the great contributions.
> Subsurface-mobile wouldn't be anywhere near where it is today if it
 wasn't
> for you.
> 
> I'll admit that I completely tune out rebreather discussions - I
 assume
> that those who care about rebreathers will figure things out and will
 send
> me pull requests.
> 
> Since I'd hate to see you go, is there actually something that we can
 do
> to fix this? Or are we (as in so many small odd corner cases) at a
 point
> where we just don't have the right person to work on something (like
 the
> FTDI download on Android)?
> 
> /D
> 
> 
>>> 
>>> -- 
>>> from my phone.
>> 
>>> ___
>>> subsurface mailing list
>>> subsurface@subsurface-divelog.org
>>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>> 
>> 
>> -- 
>> Anton Lundin +46702-161604
> 
>>> From c60d498661bac58e4182dfaab8d7e3e27b968b5b Mon Sep 17 00:00:00 2001
>> From: Anton Lundin 
>> Date: Wed, 20 Jun 2018 20:04:55 +0200
>> Subject: [PATCH 1/2] shearwater: Fallback to average/voted ppo2
>> 
>> If we can't find any calibration values for the individual sensors,
>> fallback to emitting the average/voted ppo2 instead, so users always get
>> a ppo2 value.
>> 
>> Signed-off-by: Anton Lundin 
>> ---
>> src/shearwater_predator_parser.c | 26 +-
>> 1 file changed, 13 insertions(+), 13 deletions(-)
>> 
>> diff --git a/src/shearwater_predator_parser.c 
>> b/src/shearwater_predator_parser.c
>> index dda042c..6b1ae43 100644
>> --- a/src/shearwater_predator_parser.c
>> +++ b/src/shearwater_predator_parser.c
>> @@ -669,19 +669,19 @@ shearwater_predator_parser_samples_foreach 
>> (dc_parser_t *abstract, dc_sample_cal
>>  if ((status & OC) == 0) {
>>  // PPO2
>>  if ((status & PPO2_EXTERNAL) == 0) {
>> -#ifdef SENSOR_AVERAGE
>> -sample.ppo2 = data[offset + 6] / 100.0;
>> -if (callback) callback (DC_SAMPLE_PPO2, sample, 
>> userdata);
>> -#else
>> -sample.ppo2 = data[offset + 12] * 
>> parser->calibration[0];
>> -if (callback && (parser->calibrated & 0x01)) 
>> callback

Re: Product / vendor on mobile download

2018-06-20 Thread Dirk Hohndel 
Hi Thomas,

Thanks for testing. I wasn't all that optimistic, but based on Anton's post it 
seemed possible that it was as simple as this.

> On Jun 20, 2018, at 11:07 PM, Thomas Fänge  wrote:
> 
> No success, it just behaves as before, same log as before, but the reference 
> to "localBtDevice isn't valid or not connect" I don't recognize from before. 
> I still think that the log at 27.556:"Unsupported operation" should tell us 
> something. 
> 
> "27.553: DCDownloadThread started for Mares Puck Pro on FTDI"
> Starting download from ftdi
> Starting the thread 0
> Finishing the thread Unable to open %s %s (%s) dives downloaded 0

I need to fix that debug message. Grmbl.
So we still fail to open the FTDI device - but at least we are trying to open 
the right thing.

> "27.556: Unsupported operation"
> no new dives downloaded
> "27.557: DCDownloadThread finished"
> localBtDevice isn't valid or not connecta
> 
> Same on all devices I tested on.
> 
> I also noticed that I had to disable Bluetooth for FTDI to appear as a valid 
> option for connection. 

That's strange, can you say more? I see FTDI here on my devices with BT enabled.

> Nor can I test with version 4.7.4.280 that other claims should work, since 
> Mares DC is not enabled in that version.  

Worst case I can go back and hack that, I guess...

> And yes, I have new dives on the DC... 

The error "unable to open" made it clear that this is not just a "no new dives" 
issue, but thanks for explicitly stating that.

> -- libdivecomputer.log --
> Subsurface: v4.7.8-287-g76f61468e690, built with libdivecomputer 
> v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
> INFO: Open: name=ftdi
> ERROR: No such file or directory (2) [in 
> /data/android/subsurface/libdivecomputer/src/serial_posix.c:295 
> (dc_serial_open)]

This sounds like the ftdi code isn't triggered. Maybe that's what is actually 
broken - when we did the NG merge of libdivecomputer...

Linus, could that be the actual culprit?

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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

2018-06-20 Thread Anton Lundin 
Of course I forgot to even compile it, so here's a updated 0002 patch
which actually compiles.


//Anton


On 20 June, 2018 - Anton Lundin wrote:

> Here's the patches.
> 
> I splitted them into two, so Jef can cherry-pick the first one, and a
> second one which adds a strings that says the source of the PPO2 values.
> 
> 
> //Anton
> 
> 
> On 18 June, 2018 - Dirk Hohndel wrote:
> 
> > As I said before, I can't seem to find that patch. No idea why. If someone 
> > sends it to me I'll be happy to add it. I said that before as well.
> > If hate to see Davide abandon Subsurface over this...
> > 
> > /D
> > 
> > On June 18, 2018 5:39:43 AM GMT+09:00, "Long, Martin" 
> >  wrote:
> > >Dirk,
> > >
> > >I would say that Anton's patch would do it as an interim solution. Jef
> > >isn't keen, as he has a better solution, but doesn't have the time to
> > >work
> > >on it yet. However, it does remove the regression, and prevent further
> > >loss
> > >of data in imports, until the *ideal* solution can be added. Data is
> > >still
> > >being lost, which is frustrating - I can't seem my actual ppO2 from
> > >dives I
> > >did yesterday, and now I never will, for those dives.
> > >
> > >Rather take an imperfect patch, which works now, than leave it broken
> > >waiting for the perfect one (and no idea of how long it will take).
> > >
> > >On 17 June 2018 at 12:02, Dirk Hohndel  wrote:
> > >
> > >>
> > >> On Jun 17, 2018, at 6:52 PM, Davide DB  wrote:
> > >>
> > >> On Thu, Jun 14, 2018, 15:34 Long, Martin 
> > >wrote:
> > >>
> > >>> I'm in agreement with Davide that any interim solution we can get
> > >running
> > >>> is better than the way it is working now. It's a regression, and tbh
> > >if
> > >>> there isn't an interim solution then it ought to be reverted to the
> > >old
> > >>> behaviour. At the moment I'm having to use Shearwater desktop for
> > >reviewing
> > >>> all my logs.
> > >>>
> > >>
> > >> I had to stop using Subsurface for the time being. First time in so
> > >many
> > >> years.
> > >>
> > >> If the bug will be solved I would have to transfer and compile from
> > >> scratch more than 60 dives (until now). I don't know if I will have
> > >the
> > >> time or will to do all this work and frankly speaking I'm tired to be
> > >> always a minority.
> > >>
> > >> Farewell my friends. It has been a nice journey. Thank you all for
> > >the
> > >> amazing work.
> > >>
> > >>>
> > >> Sorry to see you leave and thank you for all the great contributions.
> > >> Subsurface-mobile wouldn't be anywhere near where it is today if it
> > >wasn't
> > >> for you.
> > >>
> > >> I'll admit that I completely tune out rebreather discussions - I
> > >assume
> > >> that those who care about rebreathers will figure things out and will
> > >send
> > >> me pull requests.
> > >>
> > >> Since I'd hate to see you go, is there actually something that we can
> > >do
> > >> to fix this? Or are we (as in so many small odd corner cases) at a
> > >point
> > >> where we just don't have the right person to work on something (like
> > >the
> > >> FTDI download on Android)?
> > >>
> > >> /D
> > >>
> > >>
> > 
> > -- 
> > from my phone.
> 
> > ___
> > subsurface mailing list
> > subsurface@subsurface-divelog.org
> > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> 
> 
> -- 
> Anton Lundin  +46702-161604

> >From c60d498661bac58e4182dfaab8d7e3e27b968b5b Mon Sep 17 00:00:00 2001
> From: Anton Lundin 
> Date: Wed, 20 Jun 2018 20:04:55 +0200
> Subject: [PATCH 1/2] shearwater: Fallback to average/voted ppo2
> 
> If we can't find any calibration values for the individual sensors,
> fallback to emitting the average/voted ppo2 instead, so users always get
> a ppo2 value.
> 
> Signed-off-by: Anton Lundin 
> ---
>  src/shearwater_predator_parser.c | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/src/shearwater_predator_parser.c 
> b/src/shearwater_predator_parser.c
> index dda042c..6b1ae43 100644
> --- a/src/shearwater_predator_parser.c
> +++ b/src/shearwater_predator_parser.c
> @@ -669,19 +669,19 @@ shearwater_predator_parser_samples_foreach (dc_parser_t 
> *abstract, dc_sample_cal
>   if ((status & OC) == 0) {
>   // PPO2
>   if ((status & PPO2_EXTERNAL) == 0) {
> -#ifdef SENSOR_AVERAGE
> - sample.ppo2 = data[offset + 6] / 100.0;
> - if (callback) callback (DC_SAMPLE_PPO2, sample, 
> userdata);
> -#else
> - sample.ppo2 = data[offset + 12] * 
> parser->calibration[0];
> - if (callback && (parser->calibrated & 0x01)) 
> callback (DC_SAMPLE_PPO2, sample, userdata);
> -
> - sample.ppo2 = data[offset + 14] * 
> parser->calibration[1];
> - if (callback && (parser->calibrated & 0x02)) 
> callback (DC_SAMPLE_PPO2, sample,

TestFlight beta feedback for Subsurface-mobile.

2018-06-20 Thread Enno Ackermann 
Hi Subsurface Team,

I typed in my email incorrectly twice, and by doing so found that I was not 
able to press the change button to correct it. The only way I could get rid of 
the faulty data was to delete the app, and reinstall it.

App Information:
App Name: Subsurface-mobile
App Version: 2.1.0 (4.7.8.372)
Installed App Version: 2.1.0 (4.7.8.372)

Device Information:
Device: iPhone8,4
iOS Version: 11.2.6
Language: en-AT (English (Austria))
Carrier: NOVA
Timezone: GMT
Architecture: N/A
Connection Status: Cellular data
Paired Apple Watch: N/A

Sent from my iPhone___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

2018-06-20 Thread Anton Lundin 
Here's the patches.

I splitted them into two, so Jef can cherry-pick the first one, and a
second one which adds a strings that says the source of the PPO2 values.


//Anton


On 18 June, 2018 - Dirk Hohndel wrote:

> As I said before, I can't seem to find that patch. No idea why. If someone 
> sends it to me I'll be happy to add it. I said that before as well.
> If hate to see Davide abandon Subsurface over this...
> 
> /D
> 
> On June 18, 2018 5:39:43 AM GMT+09:00, "Long, Martin"  
> wrote:
> >Dirk,
> >
> >I would say that Anton's patch would do it as an interim solution. Jef
> >isn't keen, as he has a better solution, but doesn't have the time to
> >work
> >on it yet. However, it does remove the regression, and prevent further
> >loss
> >of data in imports, until the *ideal* solution can be added. Data is
> >still
> >being lost, which is frustrating - I can't seem my actual ppO2 from
> >dives I
> >did yesterday, and now I never will, for those dives.
> >
> >Rather take an imperfect patch, which works now, than leave it broken
> >waiting for the perfect one (and no idea of how long it will take).
> >
> >On 17 June 2018 at 12:02, Dirk Hohndel  wrote:
> >
> >>
> >> On Jun 17, 2018, at 6:52 PM, Davide DB  wrote:
> >>
> >> On Thu, Jun 14, 2018, 15:34 Long, Martin 
> >wrote:
> >>
> >>> I'm in agreement with Davide that any interim solution we can get
> >running
> >>> is better than the way it is working now. It's a regression, and tbh
> >if
> >>> there isn't an interim solution then it ought to be reverted to the
> >old
> >>> behaviour. At the moment I'm having to use Shearwater desktop for
> >reviewing
> >>> all my logs.
> >>>
> >>
> >> I had to stop using Subsurface for the time being. First time in so
> >many
> >> years.
> >>
> >> If the bug will be solved I would have to transfer and compile from
> >> scratch more than 60 dives (until now). I don't know if I will have
> >the
> >> time or will to do all this work and frankly speaking I'm tired to be
> >> always a minority.
> >>
> >> Farewell my friends. It has been a nice journey. Thank you all for
> >the
> >> amazing work.
> >>
> >>>
> >> Sorry to see you leave and thank you for all the great contributions.
> >> Subsurface-mobile wouldn't be anywhere near where it is today if it
> >wasn't
> >> for you.
> >>
> >> I'll admit that I completely tune out rebreather discussions - I
> >assume
> >> that those who care about rebreathers will figure things out and will
> >send
> >> me pull requests.
> >>
> >> Since I'd hate to see you go, is there actually something that we can
> >do
> >> to fix this? Or are we (as in so many small odd corner cases) at a
> >point
> >> where we just don't have the right person to work on something (like
> >the
> >> FTDI download on Android)?
> >>
> >> /D
> >>
> >>
> 
> -- 
> from my phone.

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


-- 
Anton Lundin+46702-161604
>From c60d498661bac58e4182dfaab8d7e3e27b968b5b Mon Sep 17 00:00:00 2001
From: Anton Lundin 
Date: Wed, 20 Jun 2018 20:04:55 +0200
Subject: [PATCH 1/2] shearwater: Fallback to average/voted ppo2

If we can't find any calibration values for the individual sensors,
fallback to emitting the average/voted ppo2 instead, so users always get
a ppo2 value.

Signed-off-by: Anton Lundin 
---
 src/shearwater_predator_parser.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/src/shearwater_predator_parser.c b/src/shearwater_predator_parser.c
index dda042c..6b1ae43 100644
--- a/src/shearwater_predator_parser.c
+++ b/src/shearwater_predator_parser.c
@@ -669,19 +669,19 @@ shearwater_predator_parser_samples_foreach (dc_parser_t *abstract, dc_sample_cal
 		if ((status & OC) == 0) {
 			// PPO2
 			if ((status & PPO2_EXTERNAL) == 0) {
-#ifdef SENSOR_AVERAGE
-sample.ppo2 = data[offset + 6] / 100.0;
-if (callback) callback (DC_SAMPLE_PPO2, sample, userdata);
-#else
-sample.ppo2 = data[offset + 12] * parser->calibration[0];
-if (callback && (parser->calibrated & 0x01)) callback (DC_SAMPLE_PPO2, sample, userdata);
-
-sample.ppo2 = data[offset + 14] * parser->calibration[1];
-if (callback && (parser->calibrated & 0x02)) callback (DC_SAMPLE_PPO2, sample, userdata);
-
-sample.ppo2 = data[offset + 15] * parser->calibration[2];
-if (callback && (parser->calibrated & 0x04)) callback (DC_SAMPLE_PPO2, sample, userdata);
-#endif
+if (!parser->calibrated) {
+	sample.ppo2 = data[offset + 6] / 100.0;
+	if (callback) callback (DC_SAMPLE_PPO2, sample, userdata);
+} else {
+	sample.ppo2 = data[offset + 12] * parser->calibration[0];
+	if (callback && (parser->calibrated & 0x01)) callback (DC_SAMPLE_PPO2, sample, userdata);
+
+	sample.ppo2 = data[offset + 14] * parser->calibration[1];
+	if (callback && (parser->calibrated & 0x02)) callback (DC_SAMPLE_PPO2,

Re: Subsurface on Opensuse Tumbleweed

2018-06-20 Thread Thiago Macieira 
On Wednesday, 20 June 2018 07:23:27 PDT guillaume.gar...@free.fr wrote:
> If I click the dive number it is fine. Otherwise, I get a blank area with
> the following messages in console: QPainter::begin: Paint device returned
> engine == 0, type: 2
>   QPainter::setFont: Painter not active
>   QPainter::setOpacity: Painter not active
>   QPainter::end: Painter not active, aborted

Can you run with QT_FATAL_WARNINGS=1 and once Subsurface aborts, get the 
backtrace from these warnings?

If these are not the first warnings printed by Subsurface, increase the number 
1 to be the number of warnings until that "QPainter::begin".

-- 
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: [TEST REQUEST] Windows Bluetooth LE build

2018-06-20 Thread Lubomir I. Ivanov 
On 20 June 2018 at 18:50, Lubomir I. Ivanov  wrote:
> update:
>
> i wrote a couple of minimal apps that for the GATT service of interest
> in the OSTC+, write data to the first characteristic and wait for a
> notification from the second characteristic.
> - BLE WINAPI native C.
> - BLE WINAPI via Qt.
>
> the first app works and is able to catch the 0x4D response from the DC.
> there seems to be a bug in Qt notification code.
> too bad that the author of the code:
> - doesn't speak good english.
> - usually is busy and doesn't respond to email.
> but still i'm going to ask if notifications have been tested at all.
>
> my goal right not is to investigate the bug in Qt and try to fix it.
>

*right now

my English is great too.

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

Re: [TEST REQUEST] Windows Bluetooth LE build

2018-06-20 Thread Lubomir I. Ivanov 
On 11 June 2018 at 21:56, Lubomir I. Ivanov  wrote:
> On 11 June 2018 at 21:50, Linus Torvalds  
> wrote:
>> On Mon, Jun 11, 2018 at 11:31 AM Lubomir I. Ivanov  
>> wrote:
>>>
>>> the Qt BLE Windows stack on the other hand detects it as "Write
>>> without response".
>>> this has to be investigated - possible bug.
>>
>> That's how you enable notifications - you write a 16-bit value to the
>> notification thing that has the notification bit enabled (and you
>> don't ask for responses).
>>
>> BLE is kind of odd. We also do things kind of oddly, because the way
>> we generate that 16-bit value is with
>>
>> QByteArray::fromHex("0100")
>>
>> which is just another way to say "two bytes: 0x01 and 0x00", which is
>> just the little-endian layout of 0x0001.
>>
>> So it's that
>>
>> qDebug() << "now writing \"0x0100\" to the descriptor" <<
>> d.uuid().toString();
>> ble->preferredService()->writeDescriptor(d, QByteArray::fromHex("0100"));
>>
>> that should enable notifications on the notification characteristic.
>>
>
> thanks, i will check if it succeeds with this stack.
>

update:

i wrote a couple of minimal apps that for the GATT service of interest
in the OSTC+, write data to the first characteristic and wait for a
notification from the second characteristic.
- BLE WINAPI native C.
- BLE WINAPI via Qt.

the first app works and is able to catch the 0x4D response from the DC.
there seems to be a bug in Qt notification code.
too bad that the author of the code:
- doesn't speak good english.
- usually is busy and doesn't respond to email.
but still i'm going to ask if notifications have been tested at all.

my goal right not is to investigate the bug in Qt and try to fix it.

side observation:
in the case of the OSTC+ there is no need to write the 0100 to the
second char's descriptor to make it notifiable as it already is.
i haven't looked at what 0200 does yet.

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

Re: Re : Re: Subsurface on Opensuse Tumbleweed

2018-06-20 Thread Dietrich Meyer 
Hi all,

> It builds. What happens if you resort the dive list based on a different
> column?

dive list disappears, following output in console:
--
QPainter::begin: Paint device returned engine == 0, type: 2
QPainter::setFont: Painter not active
QPainter::setOpacity: Painter not active
QPainter::end: Painter not active, aborted
--
but I guess you already knew this... 

running on up-to-date Opensuse Tumbleweed.
Starting subsurface with "subsurface -vvv" doesn't give any more information 
when re-sorting the divelist.

I am not a C++ nor QT programmer, so unable to really help except for testing.

Dietrich



> > 
> On June 20, 2018 5:40:33 PM GMT+09:00, guillaume.gar...@free.fr wrote:
> >Hi,
> >
> >- Dirk Hohndel  a écrit :
> >> > On Jun 18, 2018, at 5:27 PM, Robert Helling  wrote:
> >> > 
> >> > Hi,
> >> > 
> >> > I was informed that Opensuse upgrading to gcc8 and plasma 5.11 in
> >
> >Tumbleweed broke the subsurface package. I don’t know who takes care of
> >that. Just to let you know.
> >
> >> I just kicked off new builds of current master.
> >> But given that Qt 5.11 is known to cause errors for Subsurface, we
> >
> >need to fix those before the next release, anyway.
> >
> >The good news is that current daily (4.7.8.372) does build fine for
> >Tumbleweed! \o/
> >
> >Guillaume
> >
> >> /D
> >> ___
> >> 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 : Re: Re : Re: Subsurface on Opensuse Tumbleweed

2018-06-20 Thread guillaume . gardet 

- Dirk Hohndel  a écrit :
> It builds. What happens if you resort the dive list based on a different 
> column?

If I click the dive number it is fine. Otherwise, I get a blank area with the 
following messages in console:
  QPainter::begin: Paint device returned engine == 0, type: 2
  QPainter::setFont: Painter not active
  QPainter::setOpacity: Painter not active
  QPainter::end: Painter not active, aborted


Guillaume


> 
> On June 20, 2018 5:40:33 PM GMT+09:00, guillaume.gar...@free.fr wrote:
> >
> >Hi,
> >
> >- Dirk Hohndel  a écrit :
> >> 
> >> > On Jun 18, 2018, at 5:27 PM, Robert Helling  wrote:
> >> > 
> >> > Hi,
> >> > 
> >> > I was informed that Opensuse upgrading to gcc8 and plasma 5.11 in
> >Tumbleweed broke the subsurface package. I don’t know who takes care of
> >that. Just to let you know.
> >> 
> >> I just kicked off new builds of current master.
> >> But given that Qt 5.11 is known to cause errors for Subsurface, we
> >need to fix those before the next release, anyway.
> >
> >The good news is that current daily (4.7.8.372) does build fine for
> >Tumbleweed! \o/
> >
> >Guillaume
> >
> >> 
> >> /D
> >> ___
> >> subsurface mailing list
> >> subsurface@subsurface-divelog.org
> >>
> >http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> 
> -- 
> from my phone.

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

Re: Product / vendor on mobile download

2018-06-20 Thread Thomas Fänge 
Hi Dirk,

No success, it just behaves as before, same log as before, but the
reference to "localBtDevice isn't valid or not connect" I don't recognize
from before. I still think that the log at 27.556:"Unsupported operation"
should tell us something.

"27.553: DCDownloadThread started for Mares Puck Pro on FTDI"
Starting download from ftdi
Starting the thread 0
Finishing the thread Unable to open %s %s (%s) dives downloaded 0
"27.556: Unsupported operation"
no new dives downloaded
"27.557: DCDownloadThread finished"
localBtDevice isn't valid or not connecta

Same on all devices I tested on.

I also noticed that I had to disable Bluetooth for FTDI to appear as a
valid option for connection.

Nor can I test with version 4.7.4.280 that other claims should work, since
Mares DC is not enabled in that version. 

And yes, I have new dives on the DC... 

Best regards,
Thomas


-- subsurface.log --
Empty filename passed to function
"0.005: Successfully opened logfile /storage/emulated/0/subsurface.log at
Wed Jun 20 15:46:54 2018"
"0.005: Starting Subsurface-mobile:2.1.0(4.7.8.387):Android Oreo
(8.0):arm:en-US"
"0.006: built with libdivecomputer v0.7.0-devel-Subsurface-NG
(e97a47cca55973199715df0f818b4955e60d3a31)"
"0.006: built with Qt Version 5.10.1, runtime from Qt Version 5.10.1"
"0.006: built with libgit2 0.26.0"
localBtDevice isn't valid or not connectable
"Created position source android"
"0.013: Created position source android"
"Set GPS service update interval to 300 s"
"0.013: Set GPS service update interval to 300 s"
"0.013: location service is available"
"0.466: Synchronising data file"
"0.481: Load dives from local cache"
"0.535: Successfully opened dive data"
"0.557: AppState changed to active with save ongoing and no unsaved changes"
"0.559: 109 dives loaded from cache"
"0.560: have cloud credentials, but user asked not to connect to network"
"Set GPS service update interval to 300 s"
"0.561: Set GPS service update interval to 300 s"
Using the following font: Roboto
qqwindow devicePixelRatio 3 3
Supported dive computers:
"Aeris: 500 AI (SERIAL), A300 (SERIAL), A300 AI (SERIAL), A300CS (SERIAL),
Atmos 2 (SERIAL), Atmos AI (SERIAL), Atmos AI 2 (SERIAL), Compumask
(SERIAL), Elite (SERIAL), Elite T3 (SERIAL), Epic (SERIAL), F10 (SERIAL),
F11 (SERIAL), Manta (SERIAL), XR-1 NX (SERIAL), XR-2 (SERIAL)"
"Aqualung: i200 (SERIAL), i300 (SERIAL), i450T (SERIAL), i550 (SERIAL),
i750TC (SERIAL)"
"Atomic Aquatics: Cobalt (USB), Cobalt 2 (USB)"
"Beuchat: Mundial 2 (SERIAL), Mundial 3 (SERIAL), Voyager 2G (SERIAL)"
"Cochran: Commander I (SERIAL), Commander II (SERIAL), Commander TM
(SERIAL), EMC-14 (SERIAL), EMC-16 (SERIAL), EMC-20H (SERIAL)"
"Genesis: React Pro (SERIAL), React Pro White (SERIAL)"
"Heinrichs Weikamp: Frog (SERIAL, BT), OSTC (SERIAL), OSTC 2 (SERIAL, BT,
BLE), OSTC 2 TR (SERIAL, BT, BLE), OSTC 2C (SERIAL), OSTC 2N (SERIAL), OSTC
3 (SERIAL), OSTC 4 (SERIAL, BT, BLE), OSTC Mk2 (SERIAL), OSTC Plus (SERIAL,
BT, BLE), OSTC Sport (SERIAL, BT, BLE), OSTC cR (SERIAL)"
"Hollis: DG02 (SERIAL), DG03 (SERIAL), TX1 (SERIAL)"
"Mares: Puck Pro (SERIAL), Quad (SERIAL), Smart (SERIAL)"
"Oceanic: Atom 1.0 (SERIAL), Atom 2.0 (SERIAL), Atom 3.0 (SERIAL), Atom 3.1
(SERIAL), Datamask (SERIAL), F10 (SERIAL), F11 (SERIAL), Geo (SERIAL), Geo
2.0 (SERIAL), OC1 (SERIAL), OCS (SERIAL), OCi (SERIAL), Pro Plus 2
(SERIAL), Pro Plus 2.1 (SERIAL), Pro Plus 3 (SERIAL), VT 4.1 (SERIAL), VT
Pro (SERIAL), VT3 (SERIAL), VT4 (SERIAL), VTX (SERIAL), Veo 1.0 (SERIAL),
Veo 180 (SERIAL), Veo 2.0 (SERIAL), Veo 200 (SERIAL), Veo 250 (SERIAL), Veo
3.0 (SERIAL), Versa Pro (SERIAL)"
"Scubapro: Aladin Sport Matrix (BLE), Aladin Square (USBHID), G2 (USBHID,
BLE), G2 Console (USBHID, BLE)"
"Seemann: XP5 (SERIAL)"
"Shearwater: Nerd (SERIAL, BT), Nerd 2 (BLE), Perdix (SERIAL, BT, BLE),
Perdix AI (BLE), Petrel (SERIAL, BT), Petrel 2 (SERIAL, BT, BLE), Predator
(SERIAL, BT)"
"Sherwood: Amphos (SERIAL), Amphos Air (SERIAL), Insight (SERIAL), Insight
2 (SERIAL), Vision (SERIAL), Wisdom (SERIAL), Wisdom 2 (SERIAL), Wisdom 3
(SERIAL)"
"Subgear: XP-Air (SERIAL)"
"Suunto: Cobra (SERIAL), Cobra 2 (SERIAL), Cobra 3 (SERIAL), D3 (SERIAL),
D4 (SERIAL), D4f (SERIAL), D4i (SERIAL), D6 (SERIAL), D6i (SERIAL), D9
(SERIAL), D9tx (SERIAL), DX (SERIAL), EON Core (USBHID, BLE), EON Steel
(USBHID, BLE), Eon (SERIAL), Gekko (SERIAL), HelO2 (SERIAL), Mosquito
(SERIAL), Solution (SERIAL), Solution Alpha (SERIAL), Solution Nitrox
(SERIAL), Spyder (SERIAL), Stinger (SERIAL), Vyper (SERIAL), Vyper 2
(SERIAL), Vyper Air (SERIAL), Vyper Novo (SERIAL), Vytec (SERIAL), Zoop
(SERIAL), Zoop Novo (SERIAL)"
"Tusa: Element II (IQ-750) (SERIAL), Zen (IQ-900) (SERIAL), Zen Air
(IQ-950) (SERIAL)"
"Uwatec: Aladin Air Twin (SERIAL), Aladin Air Z (SERIAL), Aladin Air Z
Nitrox (SERIAL), Aladin Air Z O2 (SERIAL), Aladin Pro (SERIAL), Aladin Pro
Ultra (SERIAL), Aladin Sport Plus (SERIAL), Memomouse (SERIAL)"
qqwindow screen has ldpi/pdpi 72 162.923
"27.553: DCDownloadThread

Re: Product / vendor on mobile download

2018-06-20 Thread Dirk Hohndel 

> On Jun 20, 2018, at 4:30 AM, Thomas Fänge  wrote:
> 
> Hi,
> 
> What several people have mentioned and tested, is that version 4.7.4.280 in 
> the Android app seems to work with USB OTG, but any version after that fails. 
> I'm running Oreo 8.0, and I have other apps that work with my DC using OTG, 
> so Oreo and the HW supports it.

Could you try the latest Android beta. I'm not able to test it, but there's a 
chance that I un-broke what got broken since 4.7.4.280.
I'd love to hear feedback good or bad. Preferably with log files (you can now 
get those by clicking on the button in the About screen which copies all the 
logs to the clipboard for easy pasting into email)

Thanks

/D

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

latest updates

2018-06-20 Thread Dirk Hohndel 

Thanks to the "off-gassing" day we got a few things addressed:

- the banner image in the Subsurface-mobile global drawer should work fairly 
consistently now
- when switching from no-cloud to cloud on Subsurface-mobile, we keep the dive 
data around
- no more crashes when editing manually added dives on Subsurface-mobile (but 
the profile doesn't update - I've been chasing this one for several hours... we 
still are not handling the "here, let's render this profile and show the 
pixmap" thing correctly. Even if I force an update, it isn't shown.
- based on Anton's suggestion I implemented an attempt to bring back FTDI 
download on Android to the state it used to be in
- Linus reimplemented the wait / timeout logic of the BLE code and that seems 
to have significantly improved download stability and success likelihood for at 
least the EON Core/Steel and the Perdix AI.

A new Android app is in the beta channel, the iOS app has just been submitted 
and should show up fairly soon.

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

Re: Re : Re: Subsurface on Opensuse Tumbleweed

2018-06-20 Thread Dirk Hohndel 
It builds. What happens if you resort the dive list based on a different column?

On June 20, 2018 5:40:33 PM GMT+09:00, guillaume.gar...@free.fr wrote:
>
>Hi,
>
>- Dirk Hohndel  a écrit :
>> 
>> > On Jun 18, 2018, at 5:27 PM, Robert Helling  wrote:
>> > 
>> > Hi,
>> > 
>> > I was informed that Opensuse upgrading to gcc8 and plasma 5.11 in
>Tumbleweed broke the subsurface package. I don’t know who takes care of
>that. Just to let you know.
>> 
>> I just kicked off new builds of current master.
>> But given that Qt 5.11 is known to cause errors for Subsurface, we
>need to fix those before the next release, anyway.
>
>The good news is that current daily (4.7.8.372) does build fine for
>Tumbleweed! \o/
>
>Guillaume
>
>> 
>> /D
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>>
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

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

Re : Re: Subsurface on Opensuse Tumbleweed

2018-06-20 Thread guillaume . gardet 

Hi,

- Dirk Hohndel  a écrit :
> 
> > On Jun 18, 2018, at 5:27 PM, Robert Helling  wrote:
> > 
> > Hi,
> > 
> > I was informed that Opensuse upgrading to gcc8 and plasma 5.11 in 
> > Tumbleweed broke the subsurface package. I don’t know who takes care of 
> > that. Just to let you know.
> 
> I just kicked off new builds of current master.
> But given that Qt 5.11 is known to cause errors for Subsurface, we need to 
> fix those before the next release, anyway.

The good news is that current daily (4.7.8.372) does build fine for Tumbleweed! 
\o/

Guillaume

> 
> /D
> ___
> 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: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

2018-06-20 Thread Long, Martin 
I can't seem to get my Android build environment working at the moment. If
anyone is able to give me an apk with these patches, I'll happily test
them.

Thanks

 Martin

On 17 June 2018 at 23:05, Aaron Scheiner  wrote:

> In the attached screenshot the green line is the voted PO2 from the DC (I
> changed the colours because... messing around. They're not colour blindness
> friendly). On my JJ the reported PO2 from the dive computer (Petrel 2) is
> slightly lower than the uncalibrated sensor values.
>
> I've tested saving/loading from XML and saving/loading from git, which
> work.
>
> In a nutshell I've added an additional field in both libdivecomputer and
> Subsurface. If the additional field is populated, Subsurface will use that
> instead of trying to average/calculate the PO2.
>
> I still need to test what it does on Android. I still need to clean up
> stuff. There's probably a better way of implementing this functionality.
>
> Aaron
>
> On Sun, Jun 17, 2018 at 5:18 PM, Aaron Scheiner 
> wrote:
>
>> I'm in the same boat and last week I started working on adding an
>> additional field to both subsurface and libdivecomputer (I called it voted
>> PO2). I managed to get the import and display of it working before I got
>> interrupted by other stuff. It has subsequently occurred to me that this
>> may not be the best approach.
>>
>> I'll have a look at it again and try and come up with a better way.
>>
>> Aaron
>>
>> On Sun, Jun 17, 2018, 11:53 Davide DB  wrote:
>>
>>> On Thu, Jun 14, 2018, 15:34 Long, Martin  wrote:
>>>
 I'm in agreement with Davide that any interim solution we can get
 running is better than the way it is working now. It's a regression, and
 tbh if there isn't an interim solution then it ought to be reverted to the
 old behaviour. At the moment I'm having to use Shearwater desktop for
 reviewing all my logs.

>>>
>>> I had to stop using Subsurface for the time being. First time in so many
>>> years.
>>>
>>> If the bug will be solved I would have to transfer and compile from
>>> scratch more than 60 dives (until now). I don't know if I will have the
>>> time or will to do all this work and frankly speaking I'm tired to be
>>> always a minority.
>>>
>>> Farewell my friends. It has been a nice journey. Thank you all for the
>>> amazing work.
>>>

>>>
>>> davide@mobile
>>>
>>>
>>>
 ___
>>> 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