Re: QT 5.13 on Windows/MXE
FYI, Latest version of QT 5.13.1 looks to resolve the problem... It looks like there were quite a few changes to QStringListModel in QT5.13 , which I guess introduced some bugs that have been fixed. This is available in mxe @ revision 180304a (it looks like ther have already been some commits since downloaded last night! Note it still doesn't build with the debug-release flag. Paul On Tue, Sep 3, 2019 at 8:15 AM Paul Buxton wrote: > Thanks guys,I will poke around in it some more. Good to know that 5.13 is > not the problem in itself. > > I will see if there is anything helpful in the event log as well. > > I have debugging information for the subusrface app working fine, it is > MXE+QT which is difficult to get anything useful out of, and the build time > discourages experimentation with build flags :-) > I was curious to know if other people had the same issue, as knowing any > commonalities/differences can help locating an issue. > > Paul > > > > On Tue, Sep 3, 2019 at 4:44 AM Thiago Macieira > wrote: > >> On Monday, 2 September 2019 02:23:09 PDT Paul Buxton wrote: >> > I think it might be because we are trying to access the selected product >> > before it has been populated, but my Qt-fu is not strong enough to be >> > certain yet, and the latest MXE doesn't support building >> Debug-and-Release >> > for the QT libraries so it isn't clear exactly where the exception is >> being >> > generated. >> >> You shouldn't need a debug-and-release build to debug. You can do it the >> Unix >> way and build an unsuffixed library with debug symbols and without >> optimisation. >> >> -- >> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >>Software Architect - Intel System Software Products >> >> >> >> ___ >> 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: Unnecessary detail in dive plan
Unchecking "Display transitions in deco" shows 21m gate too. Il giorno ven 6 set 2019 alle ore 23:29 Rick Walsh ha scritto: > Hi Tormento, > > I suggest unchecking the 'display transitions in deco' option. It will > then only show the actual stops. > > Rick > > P.S. yes I'm still around > > On Fri, 6 Sep. 2019, 19:21 tormento, wrote: > >> I have started to use EAN50 to cut deco and I am planning some diving. >> >> In available gas I put bot twin bottle air and the EAN50 bottle. >> >> Let's do, as example, 32 minutes @ 37 meters. GF 45/95. >> >> Even if I check "Only switch at required stops", the dive plan details >> show me the 21m (MOD of EAN50) gate obviously with the ascend time only, as >> no deco is planned at that depth. >> >> depth duration runtime gas >> ➘ 37m 2min 2min air >> ➙ 37m 30min 32min >> *➚ 21m 2min 34min * >> ➚ 15m 1min 34min >> - 15m 1min 35min EAN50 >> ➚ 12m 0min 35min >> - 12m 2min 37min >> ➚ 9m 0min 37min >> - 9m 3min 40min >> ➚ 6m 0min 40min >> - 6m 15min 55min >> ➚ 0m 1min 56min >> >> It would be nice that no more info than necessary would be shown or >> calculated. >> >> Can you please fix that when ""Only switch at required stops" is set? >> ___ >> 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
4.9.3 preparations
This took a lot longer than expected. What else is new. I think we finally have the Qt 5.9 issue resolved (THANK YOU Berthold) and a couple of crashes one could produce in the same area of code even with the latest Qt. We also have a Qt 5.12 based AppImage - and that one REALLY needs testing. I am just about to head to Portugal - and there are some small issues with creating releases remotely because of the slightly esoteric setup I now use for the website. I'll give it a try :-) What I'd really ask everyone to do is - look at the translations - try the binaries - let me know I'd hate to have to immediately go into "oh, we need ANOTHER release" mode after this one. Linus, is there anything in libdivecomputer we should pull? Assuming I can get things to work from Portugal, I'd like to get 4.9.3 tagged on Monday and released on Tuesday. Please don't wait with testing the builds until after I have tagged the release :-/ /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
On Sat, Sep 7, 2019 at 8:34 AM Dirk Hohndel wrote: > > Linus, is there anything in libdivecomputer we should pull? I just checked Jef's branch, and merged it. It has a Mares BLE packet caching fix that *might* explain that the Mares BLUELINK Pro apparently doesn't work any more. Since I don't have a dive computer to test with, I can't really say. But that fix looks obvious and harmless even if it doesn't end up making any difference. It also merges up my i200C changes (but that doesn't change anything in our tree, just history) and improves support for the Ratio iDive dive computers' pressure transmitters. I've done the merge, I'm doing a test build, and I'll make a pull request. However, I can't test either the Mares nor the iDive changes, so it's a slight judgement call. The Mares changes I can't imagine breaking anything. The iDive changes _look_ good too, but do some odd things (send a pressure of 0 for "pressure lost", which shouldn't affect us because I think we'll just ignore it, but..) So I think merging it is good, but the iDive thing is a _slight_ risk. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
On Sat, Sep 7, 2019 at 9:54 AM Linus Torvalds wrote: > > I've done the merge, I'm doing a test build, and I'll make a pull > request. Travis is happy, things look ok. For reference, this is the diffstat of the updates from Jef: src/divesystem_idive_parser.c | 131 +++--- src/mares_iconhd.c| 2 + 2 files changed, 95 insertions(+), 38 deletions(-) so the risk is literally to just from that iDive parsing (the Mares changes really can't break anything, particularly as Fabio reported (again) that it apparently used to work in 4.8.3 but doesn't work in 4.9.2. Now, there are other changes that Jef did to the Mares code, but the BLE-specific change I see is his changes to do the BLE packet cache, so it really looks like that might be it. So I'd suggest just merging it. The possible breakage is very limited, and it does look like it might fix things. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
Il sab 7 set 2019, 18:54 Linus Torvalds ha scritto: > On Sat, Sep 7, 2019 at 8:34 AM Dirk Hohndel wrote: > > > > Linus, is there anything in libdivecomputer we should pull? > > I just checked Jef's branch, and merged it. It has a Mares BLE packet > caching fix that *might* explain that the Mares BLUELINK Pro > apparently doesn't work any more. > Since I don't have a dive computer to test with, I can't really say. > But that fix looks obvious and harmless even if it doesn't end up > making any difference. Hi, If you have a Android version with new Beta version of libdivelog, I can test it on my Mares Smart DC. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
On Sat, Sep 7, 2019 at 12:21 PM Fabio Capriati wrote: > > If you have a Android version with new Beta version of libdivelog, I can > test it on my Mares Smart DC. Hmm. Travis successfully built the Android version at https://travis-ci.org/Subsurface-divelog/subsurface/jobs/582100407 but I don't actually know where the binaries end up and if we can download them. I think Dirk is on a flight to Lisbon right now, so I decided to just merge that libdivecomputer update into subsurface. I think that in turn should make it should up eventually as https://github.com/Subsurface-divelog/subsurface/releases/download/continuous/subsurface-mobile-build-arm-debug.apk but those aren't signed, so they are a pain. I dunno. I guess we'll need to wait for Dirk anyway. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.9.3 preparations
On 7/09/19 20:16, Linus Torvalds wrote: Now, there are other changes that Jef did to the Mares code, but the BLE-specific change I see is his changes to do the BLE packet cache, so it really looks like that might be it. I doubt that change will fix Fabio's problem. That patch is needed to discard a corrupt packet. It won't help if there is no response or an empty packet. Jef ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
