Re: crash in QMLManager destructor

[Thiago Macieira via subsurface]

On Monday, 8 January 2024 18:35:56 -03 Berthold Stoeger wrote:
> > Thiago, is that something that makes sense to you?
> > 
> > 
> > 
> > here's the disassembled code and yes, it does call terminate...
> 
> Does it? At least not directly as far as I can see. I reckon this is the
> exception handler?

Quite right, there's no branch instruction arriving there. So it could only be 
reached via stack unwinding due to an exception being thrown.

I don't know Objective C or C++ at all so I can't tell for sure why dealloc 
would fail. The most likely condition is that the object has become corrupt, 
probably due to a buffer overflow somewhere or it's a double-free. The object 
itself appears to be a single 64-bit word in size (probably a pointer). 
Searching for "objective c dealloc exception" has as first result "don't use 
dealloc; use release"[1].

I also don't know why Clang inserted that __clang_call_terminate( here. The 
stack unwinding mechanism should have done that, not the IosShare destructor. 
In that case, the runtime usually prints the name of the exception that was 
thrown.

Maybe building in ASan mode and running will provide some clue.

[1] 
https://stackoverflow.com/questions/559295/difference-between-release-and-dealloc-in-objective-c

> > 0070 :
> >   70: a9be4ff4  stp x20, x19, [sp, #-32]!
> >   74: a9017bfd  stp x29, x30, [sp, #16]
> >   78: 910043fd  add x29, sp, #16
> >   7c: aa0003f3  mov x19, x0
> >   80: f940  ldr x0, [x0]
> >   84: 9400  bl  0x84 
> > 0084:  ARM64_RELOC_BRANCH26
> > _objc_msgSend$dealloc
> >   88: aa1303e0  mov x0, x19
> >   8c: a9417bfd  ldp x29, x30, [sp, #16]
> >   90: a8c24ff4  ldp x20, x19, [sp], #32
> >   94: d65f03c0  ret
> >   98: 9400  bl  0x98 
> > 0098:  ARM64_RELOC_BRANCH26
> > ___clang_call_terminate


-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering



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

Re: crash in QMLManager destructor

[Thiago Macieira via subsurface]

On Monday, 8 January 2024 14:10:45 -03 Dirk Hohndel via subsurface wrote:
> 7   libc++abi.dylib 0x0001f7aa99c8 std::terminate()
> + 56 (cxa_handlers.cpp:88) 8   Subsurface-mobile  
> 0x00010027589c QMLManager::~QMLManager() + 68 (qmlmanager.cpp:608)

The fact that it's spelt "QML" in all caps in the class name led me to find 
this file in Subsurface's sources. Line 608 is the closing bracket of the 
destructor, which definitely raises a WTF question: why is it calling 
std::terminate()?

Since there's nothing in the source code for that to call it directly, that 
implies it's debugging or hardening code inserted by the compiler itself. As 
it's happening on the closing brace, it's probably QMLManager trying to 
destroy one of its member variables.

The one thing that comes to mind is an exception. Throwing in destructors is 
really frowned upon (you can't fail to clean up) and by default all 
destructors are noexcept, so trying to throw from them causes an immediate 
std::terminate(). If this is the case, then the question is: what is throwing?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering



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

Re: Mac OS crash report

[Thiago Macieira via subsurface]

On Monday, 21 August 2023 17:52:36 PDT MAX ERENBERG via subsurface wrote:
> VM Region Info: 0x58 is not in any region.  Bytes before following region:
> 140737487097768

> 0   QtCore 0x10b61bdaa
> QCoreApplication::notifyInternal2(QObject*, QEvent*) + 138 
> 1   QtCore0x10b7a7a01 QTimerInfoList::activateTimers() + 961

This is a null-pointer dereference activating a timer. The crash is 0x58 past 
the null pointer. Comparing to my local build and assuming the structures in 
question haven't  changed sizes between those two versions, offset 0x58 shows 
up here:

QObjectPrivate *d = receiver->d_func();
QThreadData *threadData = d->threadData.loadAcquire();

d->threadData is 0x58 bytes into the QObjectPrivate object, which indicates 
that d is the null variable.

This is of course not supposed to happen: this receiver object must be a 
dangling pointer. The problem is that the receiver is coming from 
QTimerInfoList, so it's not the application's fault. Unless it deleted the 
object from another thread, but I don't see any of the threads as being the 
likely culprit and if this happened, there should be a warning.

I have a vague memory of a bug report like this, but I can't recall the 
details. Searching for QTimerInfoList::activateTimers() doesn't find anything 
meaningful. What I do remember is that this function has some convoluted code 
to deal with reentrancy in the same thread, which turned up in a recent 
refactoring but has unfortunately has gone nowhere. I'm not convinced the 
current code works.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering



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

Re: Does BLE scanning / downloading work on Mac OS X 13 for anyone else? (It doesn't for me unless I use the QT6 build)

[Thiago Macieira via subsurface]

On Tuesday, 7 March 2023 11:09:32 PST Ryan Gardner via subsurface wrote:
> Interestingly, an older QT6 experimental build *does* show all the many BLE
> devices scattered around my house (including the dive computer I'm scanning
> for) A QT5 build from the same day as the QT6 test build does not work.

There are 55 fixes to the QtBluetooth Darwin backend since 5.15. I see a few 
"Pick-to: 5.15" to indicate the fix should be picked to the 5.15 branch, but I 
don't see those commits in the 5.15 at all. Looks like there's a major 
refactoring that happened early in 6.x time so those cherry-picks failed and 
were abandoned.

That major refactoring is probably the reason why it's working now on Qt 6.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering



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

Re: testprofile on i686

[Thiago Macieira via subsurface]

On Wednesday, 1 December 2021 14:21:28 PST Linus Torvalds via subsurface 
wrote:
> I'm not seeing what's going on, but it smells like some instability in
> the calculations rather than some extra non-ieee precision of the
> i387.

An easy way to verify if it is the 387 extra precision is to remove it: add 
-msse2 -mfpmath=sse to your C/C++ build flags throughout Subsurface and unit 
test builds and see of the problem disappears.

BTW, Qt by default builds itself with those two flags on i386. Since no one 
has complained that Subsurface doesn't run on their 20+-year-old computer, we 
could turn it on for Subsurface too.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



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

Re: testprofile on i686

[Thiago Macieira via subsurface]

On Sunday, 28 November 2021 08:50:04 PST Linus Torvalds via subsurface wrote:
> > I am trying to package version 5.0.5 for void linux. The build seems to
> > pass all of the tests for x86_64, aarch64, armv7l, armv6l but fails on
> > i686 on the testprofile. Does anyone know why this might be happening
> > specifically for this architecture?
> 
> At a guess, it's some floating point rounding issue or similar, and a
> failure of the test itself rather than the binary.

That would explain why it fails on i686 but nowhere else: x87 floating point, 
which keeps extra precision between operations that the other ones don't.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



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

Re: WebKit -> WebEngine

[Thiago Macieira via subsurface]

On Sunday, 31 October 2021 10:23:05 PDT Lubomir I. Ivanov via subsurface 
wrote:
> >> Visual Studio 2017 version 15.8 or later, or clang-cl version 8 or later
> 
> they seem to support clang now as well.

Please note that clang-cl is not clang. It's the clang front end that is 
compatible with the MSVC cl syntax and produces MSVC-compatible binaries.

I really don't understand what is required to get either clang or GCC to build 
Chromium. It's not supported because Google doesn't support it, but they are 
moving towards Clang more and more, so there's a good chance it might "just 
work" some day, or at least with some effort. After all, the other platforms 
build with Clang, so it can't be more than some Windows-specific files.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



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

Re: Assistance cross-building Windows target

[Thiago Macieira via subsurface]

On Friday, 29 October 2021 03:58:03 PDT Steven Morlock via subsurface wrote:
> Howdy,
>   I have been trying to unsuccessfully follow guidance on how to cross-build
> the Windows client.  I am running on a OSBoxes.org Ubuntu 21.04 virtual
> machine.  I have followed as best I could the instructions in
> 'subsurface/INSTALL' and
> 'subsurface/packaging/windows/mxe-based-build.sh'.  Could someone please
> review the enclosed 'winbuild.log' and suggest where I may have gone wrong.
> Thanks,Steve

Hello Steve

statsview.h:187:21: error: missing template arguments before '(' token
  return ChartItemPtr(new T(*this, std::forward(args)...));

"missing template arguments" indicates the code is using template parameter 
deduction, which is a C++17 feature. 

statscolors.h:8:46: error: 'backgroundColor' declared as an 'inline' variable
 inline const QColor backgroundColor(Qt::white);

inline variables are a C++17 feature too.

barseries.cpp:93:14: error: expected unqualified-id before '[' token
   for (auto &[dives, label]: item.items) {
  ^

And this is the syntax for structured bindings, another C++17 feature.

Looks like your issue is that Subsurface is not being compiled as C++17. That 
means your compiler is old. Whether adding the "-std=c++17" / "-std=gnu++17" 
option would help you or not, I don't know. Recommendation: upgrade your 
MinGW's GCC.

PS: looks like Subsurface is using more C++17 features than my own code!
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



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

Re: Subsurface on Apple Silicone

[Thiago Macieira via subsurface]

On Sunday, 24 October 2021 18:35:14 PDT Thiago Macieira via subsurface wrote:
> > Any pointers, Thiago?
> 
> There was some discussion about only QtPositioning being available... not
> sure. I didn't pay attention. I did a quick check to see if the qtlocation
> repository was tagged with 6.2 but didn't check *what* it installs. I don't
> keep a full build of Qt in my laptop, that's what workstations wit lots of
> cores are for :)
> 
> Can you try QT += positioning to see if that helps and replacing the
> #includes?

Yep, the module is only QtPositioning:

$ ls -ld include/Qt{Positioning,Location}
ls: cannot access 'include/QtLocation': No such file or directory
drwxr-xr-x 3 tjmaciei tjmaciei 4096 Sep 30 00:50 include/QtPositioning
$ ls mkspecs/modules/qt_lib_{positioning,location}.pri
ls: cannot access 'mkspecs/modules/qt_lib_location.pri': No such file or 
directory
mkspecs/modules/qt_lib_positioning.pri

Here are the classes it contains:
$ ls -1 include/QtPositioning
6.3.0
QGeoAddress
qgeoaddress.h
QGeoAreaMonitorInfo
qgeoareamonitorinfo.h
QGeoAreaMonitorSource
qgeoareamonitorsource.h
QGeoCircle
qgeocircle.h
QGeoCoordinate
qgeocoordinate.h
QGeoLocation
qgeolocation.h
QGeoPath
qgeopath.h
QGeoPolygon
qgeopolygon.h
QGeoPositionInfo
qgeopositioninfo.h
QGeoPositionInfoSource
QGeoPositionInfoSourceFactory
qgeopositioninfosourcefactory.h
qgeopositioninfosource.h
QGeoRectangle
qgeorectangle.h
QGeoSatelliteInfo
qgeosatelliteinfo.h
QGeoSatelliteInfoSource
qgeosatelliteinfosource.h
QGeoShape
qgeoshape.h
QNmeaPositionInfoSource
qnmeapositioninfosource.h
QNmeaSatelliteInfoSource
qnmeasatelliteinfosource.h
qpositioningglobal.h
QtPositioning
qtpositioning-config.h
QtPositioningDepends
QtPositioningVersion
qtpositioningversion.h

Is this enough for Subsurface needs?
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



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

Re: Subsurface on Apple Silicone

[Thiago Macieira via subsurface]

On Sunday, 24 October 2021 17:12:04 PDT Dirk Hohndel wrote:
> [hohndel@fedora build]$ qmake6 ../googlemaps.pro
> Project ERROR: Unknown module(s) in QT: location
> 
> So at least qmake6 doesn't appear to know how to build against Qt Location.

Hmm... the "qt_lib_location.pri" file must be missing. I'll take a look 
tomorrow.

> Interestingly, when I go to https://doc.qt.io/qt-6/qtmodules.html
> <https://doc.qt.io/qt-6/qtmodules.html> - it doesn't list Qt Location... So
> maybe it's only "sort of" there? Or maybe I'm supposed to use it
> differently?


> Oh, and then using
>   dnf repoquery -l qt6-qtlocation-devel
> shows that this package does, indeed, only contain QtPositioning, but not
> QtLocation
> 
> Trying to find anything on this topic via Google has been not very
> successful.
> 
> Any pointers, Thiago?

There was some discussion about only QtPositioning being available... not 
sure. I didn't pay attention. I did a quick check to see if the qtlocation 
repository was tagged with 6.2 but didn't check *what* it installs. I don't 
keep a full build of Qt in my laptop, that's what workstations wit lots of 
cores are for :)

Can you try QT += positioning to see if that helps and replacing the 
#includes?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



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

Re: Subsurface on Apple Silicone

[Thiago Macieira via subsurface]

On Friday, 22 October 2021 16:52:06 PDT Dirk Hohndel via subsurface wrote:
> Some more messing around with Qt 6... we're not only losing QtWebKit -
> there's also no Qt Location and no Qt Positioning. Which means no map
> module that we can use.

Those were missing in 6.0 and 6.1, but qtlocation is back in 6.2.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



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

Re: Subsurface on Apple Silicone

[Thiago Macieira via subsurface]

On Friday, 22 October 2021 10:34:08 PDT Dirk Hohndel via subsurface wrote:
> I haven't followed this closely enough to see if the Linux distros are
> including these patches in their versions, though.

They are, at least the ones that follow KDE somewhat closely.

https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/sources
https://build.opensuse.org/package/show/openSUSE:Factory/libqt5-qtbase
https://github.com/archlinux/svntogit-packages/blob/packages/qt5-base/trunk/
PKGBUILD#L31-L33
etc.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



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

Re: Windows crash

[Thiago Macieira via subsurface]

On Tuesday, 30 March 2021 08:30:31 PDT Dirk Hohndel via subsurface wrote:
> I wonder why I didn't find this with Valgrind. Given that my professional
> software developer career started writing a memory debugger 27 years ago...
> I find Valgrind frustratingly inconsistent to use.
> 
> /D

Try ASan (-fsanitize=address). Compiling only the executable and not the 
libraries (especially Qt) with ASan works most of the time, but if you need 
more info you may need to enable that for Qt too.

I find that Valgrind and ASan are complementary and find things the other 
don't. Valgrind is especially useful when you don't want to recompile.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



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

Re: libqtgeoservices_googlemaps.so: undefined symbol: _ZN7QGeoMap25fitViewportToGeoRectangleERK13QGeoRectangle

[Thiago Macieira via subsurface]

On Thursday, 1 October 2020 01:05:10 PDT Cristian Ionescu-Idbohrn via 
subsurface wrote:
> libqtgeoservices_googlemaps.so: undefined symbol:
> _ZN7QGeoMap25fitViewportToGeoRectangleERK13QGeoRectangle)"

This is a private symbol in QtLocation that changed between 5.12 and 5.13.0. 
See https://github.com/qt/qtlocation/commit/
56e07f78579196fc33580ca5f20073a156b0e2dd

The symbol your plugin is looking up is the old one. That means you compiled 
the plugin against an old Qt (probably accidentally).

Recommendation: remove the development packages of Qt that were installed 
system-wide.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



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

Re: Windows && sqlite?

[Thiago Macieira via subsurface]

On Tuesday, 22 September 2020 11:58:04 PDT Dirk Hohndel via subsurface wrote:
> > I suspect that parsing the samples fails, and that sql query might be
> > something that the version of libsqlite on windows cannot handle...
> We use libsqlite 3.32.2 on Windows.
> I always wonder if this is a line end issue or something else where the
> different character set conversions bite us...?

The sqlite file format should be the same. It's binary, so line endings 
shouldn't be an issue. Only if the lines with CRLF are loaded into the 
database itself...

You can copy the file onto a Linux and use /usr/bin/sqlite to see if it can 
read.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering



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

Re: Qt version on OpenSuse

[Thiago Macieira via subsurface]

On Monday, 20 July 2020 05:55:12 PDT Robert Helling via subsurface wrote:
> Hi,
> 
> got a question from a user: He is on OpenSuse Tumbleweed which apparently
> comes with Qt 5.15 while the Subsurface package apparently (I didn’t check
> any of this) requires 5.13. Is there anything I can tell him besides using
> the AppImage?

There shouldn't be a problem. Is he experiencing a problem?

-- 
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

Re: renaming the default branch to 'main'

[Thiago Macieira via subsurface]

On Monday, 15 June 2020 13:01:04 PDT Dirk Hohndel via subsurface wrote:
> I am at this point working through the steps it will take to rename our
> default branch to be 'main

Just don't call it MAIN. That's too CVS-y.

-- 
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

Re: Build issues

[Thiago Macieira]

On Saturday, 4 January 2020 12:31:53 -03 Robert.Helling wrote:
> find Subsurface-mobile.app/ |grep dylib$|xargs -n1 otool -L
> 
> here: https://neu.atdotde.de/~robert/ot.out
> 
> Maybe you can spot something odd.

Ok, that will catch plugins (as they are .dylib), but not the libraries 
themselves. Those have a plain, undecorated name like "QtCore".

> + '[' '' = 1 ']'
> + (( i++  ))
> + (( i < 1  ))
> 
> [BTW: What is this?]

That's sh -x output, which is showing things after expansion.

-- 
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

Re: Build issues

[Thiago Macieira]

On Friday, 3 January 2020 21:33:09 -03 Robert Helling wrote:
> > objc[85638]: Class
> > QT_ROOT_LEVEL_POOL__THESE_OBJECTS_WILL_BE_RELEASED_WHEN_QAPP_GOES_OUT_OF_
> > SCOPE is implemented in both
> > /Users/Helling/Qt/5.12.0/clang_64/lib/QtCore.framework/Versions/5/QtCore
> > (0x1025390e0) and
> > /Users/Helling/mobile/subsurface/build-mobile/Subsurface-mobile.app/Conte
> > nts/Frameworks/QtCore.framework/Versions/5/QtCore (0x1078750e0). One of
> > the two will be used. Which one is undefined.

This looks like an incomplete deployment: some binary resources inside the 
bundle still point to the original files from the Qt SDK, not the bundled copy 
of the Qt frameworks. If you use otool -L on each of the binaries inside, can 
you find out which one still points to that "clang_64" build?

-- 
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

Re: QT 5.13 on Windows/MXE

[Thiago Macieira]

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

Re: Large negative pressures

[Thiago Macieira]

On Wednesday, 7 August 2019 10:19:01 PDT Linus Torvalds wrote:
> Again, truncation of long to int isn't undefined behavior or overflow.
> It's just a value truncation.

Strictly speaking, it's defined only if the result fits. Otherwise, the C 
standard says it's implementation defined what happens.

On all modern machines, it just truncates, no warning.

-- 
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

Re: Large negative pressures

[Thiago Macieira]

On Wednesday, 7 August 2019 09:31:35 PDT Linus Torvalds wrote:
> > 2) Make pressure_t (and related variable) int64_t,
> 
> Absolutely not. See above. That would be entirely crazy.

Unless you want to use Subsurface to calculate a dive into the core of the Sun 
(pressure there is estimated at around 250 gigabars). That would overflow the 
puny int32_t.

-- 
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

Re: .dev domain

[Thiago Macieira]

On Thursday, 28 February 2019 18:31:36 PST Dirk Hohndel wrote:
> Eventually (when I find the time), I think I'll migrate this mailing list to
> be "de...@subsurface.dev <mailto:de...@subsurface.dev>" ...

d...@subsurface.dev?
subsurface@subsurface.dev?

-- 
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

Re: Qt 5.12 and Android arm64 build

[Thiago Macieira]

On Wednesday, 14 November 2018 14:03:54 PST Dirk Hohndel wrote:
> Will there be an Android Qt 5.12 built with clang?

I don't know if it will be pre-built as such, but Clang support is now present 
in 5.12.

-- 
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: Qt 5.12 and Android arm64 build

[Thiago Macieira]

On Wednesday, 14 November 2018 13:28:04 PST Jan Mulder wrote:
> With Qt 5.12 coming soon (end this month), I gave the beta #4 a try
> today. My focus was on the cross build of Subsurface-mobile for Android.
> Obviously, I ran in some problems, but nothing that seems mayor. One
> weird thing I could not solve up to now is an undefined reference from
> the linker (QtAndroid::runOnAndroidThread); a construct to set the color
> of the header and footer to our liking.

That sounds like a mix of two Qt versions, since runOnAndroidThread is defined 
in qjnihelpers.cpp, inside QtCore, without any #if. That is, you're compiling 
against 5.12, but linking (or running) against 5.11. Check your environment.

> With Qt 5.12 also a build for arm64 architecture becomes feasible. And I
> succeeded in a running arm64 app on my device. Also here, relatively
> straightforward (in hindsight). This requires a newer API that the
> currently used 16. I used API 21 (corresponding to Android 5.0).

Note that this will make use of Clang to build, instead of GCC of the older 
SDKs. Clang produces much larger binaries, even at extreme size optimisation 
(-Oz).

> So, my question for Dirk: interested in set of patches for all this?
> Obviously, no hurry here, as 5.12 is still beta. I between I might take
> a look into clang instead of gcc for the mobile app, as Android had
> moved away from gcc, and support will end someday.

The first -rc is expected next week and these days it means any RC could be 
the final release one week later, if nothing major is found. If you have 
issues, please report them so we decide whether the RC is good or not.

-- 
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: erreur d'importation

[Thiago Macieira]

On Friday, 12 October 2018 02:56:26 PDT jean-yves coppin wrote:
> bonjour,
> 
> 
> je rencontre ce problème sur mon Galileo Sol full de chez UWATEC depuis le
> changement de version 4.8.3.

Inline translation:

I am facing this problem on my Galileo Sol Full from UWATEC after the change 
of version (upgraded, I guess)  4.8.3

> j'ai mème essayé de revenir sur l'ancienne version rien a faire

I have even tried to go back to the old version -- nothing happened.

> subsurface ne veut plus m’importer mais plongée

Subsurface does not want to import my dives any more.

> il n'y a pas eu enregistrement de fichier subsurface.bin

There haven't been any modifications to the file subsurface.bin.

> j’espère que vous trouverez le problème

I hope you'll find this problem.

-- 
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: libdc, libzip, Mac and Android updates

[Thiago Macieira]

On Sunday, 5 August 2018 16:01:52 PDT Dirk Hohndel wrote:
> b) this brings me to the second thing I figured out: building a working APK
> against Qt 5.11.1. You may remember that I had problems with
> androiddeployqt not managing to package our APK because a dependency for
> one of the Qt plugins was unmet. After lots of googling I pieced together
> enough information to realize that the problem is in qt-android-cmake. I
> sent a PR to that project and in the meantime switched Subsurface to use my
> fork of this that actually tells androiddeployqt to scan the QML modules as
> well for dependencies. Thiago, I thought you might be interested in that
> part.

Do you have a link?

-- 
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

[Thiago Macieira]

On Friday, 13 July 2018 21:32:10 PDT Lubomir I. Ivanov wrote:
> > rm -rf qmake
> > cmd \ /c config.status
> > 
> > If you're in a regular DOS prompt, probably
> > 
> > rd /s /q qmake
> > config.status

BTW those config.status.bat are just:

configure -redo

Usually, on Windows you want to run configure.bat, but if you've been using 
the sh script and it works for you, you can do that too.

-- 
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

[Thiago Macieira]

On Friday, 13 July 2018 21:21:32 PDT Lubomir I. Ivanov wrote:
> building qt on windows with mingw (can't look at the version number right
> now).
> 
> i was getting a compiler error somewhere in the qmake source
> (something about a duplicate "escape path" method), when building the
> 5.11 branch of qtbase.
> cleaning object code didn't help. to solve this, i removed the qtbase
> submodule completely, initialized it again but this time built the
> 5.10 branch.

qmake is special because it's not built with qmake (circular dependency). So 
its Makefile is much simpler and is not as complete.

When I have such an issue, I do:
 rm -rf qmake
 cmd \ /c config.status

If you're in a regular DOS prompt, probably

 rd /s /q qmake
 config.status

-- 
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: MXE with Qt5.11.1 and missing map

[Thiago Macieira]

On Tuesday, 10 July 2018 18:08:08 PDT Thiago Macieira wrote:
> I haven't looked at he macdeployqt tool in a few years, but it shouldn't be
> too difficult to fix it. Assuming the other two have copy/pasted code, the
> fix should be ported easily too.

Quick inspection of the source code shows that it *meant* to deploy the 
plugins' dependencies. I'm going to try and create a simple testcase to see 
what happens.

-- 
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: MXE with Qt5.11.1 and missing map

[Thiago Macieira]

On Tuesday, 10 July 2018 15:28:43 PDT Dirk Hohndel wrote:
> > But they don't recheck after #3 if any plugins require libraries the
> > application doesn't link to. This could be worked around by explicitly
> > linking to the new library -- except that library has no public symbols
> > to require, so many linkers will just drop it as unnecessary.
> 
> So the problem becomes... how do we work around that. Just force the library
> to be part of the package... is that the way to go? It's what I did for
> macOS and I think I know how to do that win Windows (but haven't tried,
> yet). With Android I still haven't figured out how to do that... 

That sounds like a decent workaround, until the deploy tools get fixed.

I haven't looked at he macdeployqt tool in a few years, but it shouldn't be 
too difficult to fix it. Assuming the other two have copy/pasted code, the fix 
should be ported easily too.

-- 
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: MXE with Qt5.11.1 and missing map

[Thiago Macieira]

On Monday, 9 July 2018 23:31:22 PDT Dirk Hohndel wrote:
> And the same thing is preventing the Qt 5.11 based Android app from working.
> There is some other component or library that we need to select in cmake -
> but I can't figure out what the right keyword might be. On Android it's lib
> declarative_positioning.so that isn't packaged and that one isn't packaged
> because its dependency libQt5PositioningQuick.so is missing.
> 
> That sound awfully familiar, doesn't it?

Yeah.

My guess is that the deploy applications actually all share the same history 
and have the same bug. They work like this (my theory):
 1) check which libraries the application links to
 2) adds regular (non-QML) plugins associated with that library
 3) check what QML imports (including plugins) are needed

But they don't recheck after #3 if any plugins require libraries the 
application doesn't link to. This could be worked around by explicitly linking 
to the new library -- except that library has no public symbols to require, so 
many linkers will just drop it as unnecessary.

-- 
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: QMetaObject::invokeMethod

[Thiago Macieira]

On Saturday, 7 July 2018 08:37:40 PDT Robert Helling wrote:
> Hi,
> 
> I am trying to understand some code that contains invocations of
> 
> QMetaObject::invokeMethod
> 
> I admit I not a C++ person in any sense so could somebody please explain why
> one would use such a thing? Berthold, I guess you introduced these. In
> particular since the Qt documentation says about QMetaObject

Usually, that function is used with Qt::QueuedConnection, which instead of 
calling the method indicated right now, it posts an event to the event queue 
with the arguments you supply. When the event loop gets to that event, the 
method you listed gets finally called.

Another way of doing the same is by using QTimer::singleShot() with a lambda 
that carries your parameters. But this wasn't available before Qt 5.4, so 
there's a lot of code (and muscle memory) using invokeMethod().

-- 
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

[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

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

[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

[Thiago Macieira]

On Sunday, 10 June 2018 01:59:37 CEST Linus Torvalds wrote:
> Your debug log doesn't actually have the IO that is done. That seems
> to be a Qt issue. We ask for debug output, and some versions of Qt
> will give that:
> 
> QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth*
> = true"));
> 
> and others will apparently just ignore it.

Ubuntu installs a global file that overrides. It's up to the user to configure 
what output they want to see, not the application.

The above line needs to be set by the user in the QT_LOGGING_RULES environment 
variable.

-- 
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: 32-bit Qt

[Thiago Macieira]

On Thursday, 7 June 2018 03:12:10 PDT Willem Ferguson wrote:
> My travel computer is a small laptop with an Atom CPU, running 32-bit
> Ubuntu. It looks like Qt5.5. is the last 32-bit version available, since
> I cannot find a Qt5.10 32-bit version. Is this correct?

Qt 5.10 continues to support 32-bit. You just won't find a binary for download 
from qt.io for it. You'll have to compile from source, or use the one from 
your Linux distribution. If you choose the latter, you'll need to make sure it 
can install the necessary private headers.

-- 
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: Segfault with Qt-5.11.0

[Thiago Macieira]

On Wednesday, 23 May 2018 05:08:58 -03 Gaetan Bisson wrote:
> Any ideas how to debug this?

Can you valgrind? Without debug symbols in Qt it may be a little difficult to 
make sense of what we're seeing, but it might help.

-- 
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

Qt 5.11 released -- QSettings can't save on Android

[Thiago Macieira]

You may want to wait for 5.11.1 or apply the fix[1].

The reason is we're using O_TMPFILE for temporary files now, but the solution 
to materialise the file suggested in the man page[2]

  char path[PATH_MAX];
  fd = open("/path/to/dir", O_TMPFILE | O_RDWR,
  S_IRUSR | S_IWUSR);

  /* File I/O on 'fd'... */

  snprintf(path, PATH_MAX,  "/proc/self/fd/%d", fd);
  linkat(AT_FDCWD, path, AT_FDCWD, "/path/for/file",
  AT_SYMLINK_FOLLOW);

fails because Android security permissions block the link(2) and linkat(2) 
system calls. Since you can't have nice things on Android, I've disabled the 
O_TMPFILE support as well as the rename-overwrite-race-prevention one 
(renameat(2) system call also blocked and can't use link(2)).

statx(2) is also blocked, so you can't get file birth times either.

[1] http://code.qt.io/cgit/qt/qtbase.git/commit/?
id=f86fbc45667528ac9a496d1476bd139f26b3b5bc
[2] http://man7.org/linux/man-pages/man2/open.2.html
-- 
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: Ubuntu bionic appears to have removed the QtLocation private headers

[Thiago Macieira]

On Monday, 30 April 2018 08:49:19 PDT Lubomir I. Ivanov wrote:
> > What was the package with the Qt private headers? I could just add that
> > for
> > 18.04 in our Launchpad repo... Should do the trick.
> 
> AFAIK one of the problems was that there are simply no packages for
> some of the Qt private headers in Ubuntu (intentionally).
> this is why we added this solution to pull private headers:
> https://github.com/Subsurface-divelog/subsurface/blob/master/scripts/build.s
> h#L148

Right. I also asked on Debian and the answer was that they don't provide 
private headers unless they are actually required by something else that they 
also build (like other Qt modules).

-- 
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: Formatting Dive tags string

[Thiago Macieira]

On Thursday, 5 April 2018 10:32:37 PDT Berthold Stoeger wrote:
> Hi,
> 
> On Donnerstag, 5. April 2018 19:28:28 CEST Thiago Macieira wrote:
> > On Thursday, 5 April 2018 10:25:37 PDT Berthold Stoeger wrote:
> > > It's fine as it is, since all C-strings are supposed to be UTF-8
> > > encoded.
> > > The only use I see for fromLatin1() et al. would be importing data from
> > > an
> > > external source that is not UTF-8.
> > 
> > If it's US-ASCII, it is valid UTF-8, but QString::fromLatin1 is slightly
> > faster.
> 
> I don't understand your point. Do you suggest limiting dive-tags to
> US-ASCII?

I'm stuck on "tag". To me that indicates an identifier, like a Git tag. But 
that's apparently not what you're using it for.

-- 
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: Formatting Dive tags string

[Thiago Macieira]

On Thursday, 5 April 2018 10:25:37 PDT Berthold Stoeger wrote:
> It's fine as it is, since all C-strings are supposed to be UTF-8 encoded.
> The only use I see for fromLatin1() et al. would be importing data from an
> external source that is not UTF-8.

If it's US-ASCII, it is valid UTF-8, but QString::fromLatin1 is slightly 
faster.

-- 
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: Cloud server

[Thiago Macieira]

On Sunday, 1 April 2018 11:55:34 PDT Dirk Hohndel wrote:
> I know added another 30GB of storage, hopefully that will last for a while 

"30 GB will be enough for everyone" ?

-- 
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: Formatting Dive tags string

[Thiago Macieira]

On Wednesday, 4 April 2018 02:55:22 PDT Berthold Stoeger wrote:
>   char *s = taglist_get_tagstring(...);
>   QString tags(s);
>   free(s);

One minor note: this decodes the string as UTF-8. If your string is Latin1 or 
plain US-ASCII, you should use QString::fromLatin1 or QLatin1String (same 
thing in this context).

-- 
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: Trouble in Qt-land

[Thiago Macieira]

On Sunday, 25 March 2018 22:26:39 CST Willem Ferguson wrote:
> Pointing to a problem somewhere deep in Qt-land. I think the first
> obvious question is why is Qt 5.10.1 not used, but Qt 5.5.1?

Probably a matter of setting LD_LIBRARY_PATH to point to the 5.10.1. This 
should have been dealt with by CMake by creating the necessary RPATH in the 
Subsurface executable, though...

-- 
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: Roll our own qUtf8Printable()?

[Thiago Macieira]

On domingo, 25 de fevereiro de 2018 17:13:11 PST Thiago Macieira wrote:
> But there's another option, which is to avoid a copy of the QString if the
> input is already a QString. Let me try a few variations of possible
> solutions and compile Qt to see what happens.
> 
> I'll BRB.

Change to Qt: https://codereview.qt-project.org/221331

Here's the implementation details: https://godbolt.org/g/voLGhQ

As you can see from the assembly output, it does not create a copy anymore, 
but does work for any and all types convertible to QString (including QString 
itself).

-- 
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: Roll our own qUtf8Printable()?

[Thiago Macieira]

On domingo, 25 de fevereiro de 2018 14:34:28 PST Berthold Stoeger wrote:
> I think the compiler can't optimize the copy away, because QString doesn't
> copy the string, but does reference counting. I'm not sure if it is allowed
> to throw away the side effects of the ref()/deref() calls? This does some
> atomic stuff, so is obviously a bit hairy.

I'm not sure it can. Because the variable is an atomic, the compiler may 
conclude it cannot remove a pair of operations that reverse each other, 
because another thread may find the modified value in-between. That's true 
even for relaxed memory access, which ref counts are not.

> [Sidenote: There's a reason the C++-standard disallows reference counting
> for its string class.]

There is, but this isn't it. The concern is the unexpected memory allocation 
when calling a non-const function. The standard banned reference counting by 
requiring a few of those functions to have constant time (O(1)) operation, 
which can't be implemented if you need to allocate memory and memcpy.

-- 
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: Roll our own qUtf8Printable()?

[Thiago Macieira]

On domingo, 25 de fevereiro de 2018 15:00:38 PST Lubomir I. Ivanov wrote:
> <bstoe...@mail.tuwien.ac.at> wrote:
> > Dear all,
> > 
> > In many places, QStrings are converted to C-style strings with an
> > expression of the kind
> > 
> >  s.toUf8().data()
> > 
> > I have a patch replacing all of them with
> > 
> >  qUtf8Printable(s)
> > 
> > The idea is that - according to the documentation - this is equivalent to
> > 
> >  s.toUtf8().constData()
> > 
> > The latter should produce less machine code, because it doesn't have to
> > check whether the data of the temporary QByteArray is shared. Owing to
> > the many indirections in Qt's code, the compiler is not smart enough to
> > understand that in this case data() = constData().

It couldn't and shouldn't. toUtf8() returns a non-const QByteArray, so .data() 
calls the non-const version which will in turn try to detach. However, the 
data isn't shared, which means this is just a useless branch-and-compare. The 
performance impact should be negligible, except in tight loops, and most 
definitely dwarfed by the memory allocation that involved creating that UTF-8 
string in the first place.

I've got some code that will try to gift the memory from the QString to the 
QByteArray, but it can't be done in Qt 5 without breaking binary 
compatibility.

> > Much to my surprise, qUtf8Printable() produced larger code. The reason is
> > that it is defined as a macro in :
> > 
> > #ifndef qUtf8Printable
> > #  define qUtf8Printable(string) QString(string).toUtf8().constData()
> > #endif
> > 
> > It generates a temporary copy of the string! This looks like a defect to
> > me.

Not really, but we may be able to improve it.

It's done that way because you want this to work:

qUtf8Printable(someString + ":" + otherString)

When the fast operator+ is active, the expression in the parentheses isn't a 
QString, but a QStringBuilder<QStringBuilder<QString, char[2]>, QString>, 
which does a single memory allocation with no temporaries, instead of the 
expected two allocations. So we need to get it to convert to QString first 
before we can call .toUtf8() on it.

This also works if the macro parameter is anything else that can be implicitly 
converted to QString, like QLatin1String. So if you wrote:

qUtf8Printable(QLatin1String("\xe9"))

You'd get the expected "\xc3\xa9" output.

But, like I said, there may be a way to improve that. It's not what you 
suggested here:

> > So what do you think about rolling our own helper function:
> > 
> > inline const char *qstring2c(const QString )
> > {
> > 
> > return s.toUtf8().constData();
> > 
> > }

The above is just wrong. The pointer that is returned is dangling, because the 
above code actually does:

QByteArray temp1 = s.toUtf8();
const char *temp2 = temp1.constData();
temp1.~QByteArray();
return temp2;

Since the temporary QByteArray owns the pointer, it will free the pointer 
before the function returns. Any and all use of that pointer is strictly UB.

That's also why both qPrintable and qUtf8Printable are macros, instead of 
inline functions. Many a novice contributor to Qt has made such a proposal to 
convert macros to inline functions and stumbled upon this mistake, myself 
included (though over 10 years ago).

> hi, Thiago.
> 
> if you have a moment, what do you think about the size differences
> between qUtf8Printable() and the proposed home brew qstring2c()
> replacement.
> Berhold is saying that qUtf8Printable() always creates a copy of the
> string, does that seem right?

No, it doesn't.

But there's another option, which is to avoid a copy of the QString if the 
input is already a QString. Let me try a few variations of possible solutions 
and compile Qt to see what happens.

I'll BRB.

-- 
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: Compiling Subsurface against Qt in debug/developer mode

[Thiago Macieira]

On terça-feira, 26 de dezembro de 2017 08:15:06 -02 Jan Mulder wrote:
> Currently, I'm (test) compiling Subsurface against the relatively new Qt
> 5.10, which I compiled myself in developer mode. As the Qt source
> contains numerous asserts that are only active in developer mode, I
> (obviously) trip some of them while using our Subsurface (see for
> example, PR #977).
> 
> So, my question is now: what to do with this knowledge? When there is an
> obvious fix (like in 977), there seems no reason not to fix this in
> Subsurface. But now, I am stuck on a very deep down assert triggered by
> the new filter code. This code seems to work just fine in production
> code, and a fix on our side seems not straightforward. It might even be
> a bogus assert in Qt, or a bug in Qt.
> 
> So, another question: what do the Qt specialists here think of the
> "quality of the asserts in Qt source?". Are they of any use to non-Qt
> developers? Obviously, our main objective here is to improve Subsurface
> and not trying to debug Qt. That said, we might improve out code by
> assuming the Qt asserts are valid and correct, and improve our code not
> to trip those.

Assertions inside Qt code, like all warnings printed by Qt, are meant to 
indicate errors in the application's usage of the Qt API. So please 
investigate whether we have a mistake in Subsurface.

If you find out that it's a valid condition but the assertion or warning was 
incorrectly printed, file a bug report with an explanation of how you reached 
it.

-- 
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 as a Snap?

[Thiago Macieira]

On quinta-feira, 21 de dezembro de 2017 13:15:53 -02 Dirk Hohndel wrote:
> Snap is a Canonical effort and as such is receiving at best "lip-service"
> level support from the other distros. FlatPak was very much developed by
> Red Hat as a response to Snap and as a direct competitor. As a result
> (isn't it lovely), neither of them has good support on the other one's
> platform. Even though both of course claim that they do.

Red Hat is contributing new features to Qt in order to support FlatPak, like 
supporting the FlatPak D-Bus portal service to show file dialogs and allow 
selecting of files outside of the sandbox. I have not seen any patch for 
Canonical for Snap.

For that matter, neither for AppImage.

-- 
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: Switching to Qt 5.10

[Thiago Macieira]

On sexta-feira, 8 de dezembro de 2017 05:49:34 PST Dirk Hohndel wrote:
> > On Dec 8, 2017, at 7:46 AM, Thiago Macieira <thi...@macieira.org> wrote:
> > 
> > On Friday, 8 December 2017 03:21:04 PST Dirk Hohndel wrote:
> >> Actually, I just wanted to switch to Qt 5.10 and start testing with that.
> > 
> > Please note that 5.10.0 has problems renaming files on Android, due to an
> > unexpected SELinux rule. I advise to wait for 5.10.1.
> 
> Thank you for that warning!
> 
> I started looking at 5.10.0 for iOS, haven't even looked at Android, yet.
> I will hold off. Is there an ETA for 5.10.1 (since that's a pretty
> catastrophic bug)?

I don't know if Subsurface uses Qt for renaming files. It doesn't affect 
QTemporaryFile, QSaveFile and QSettings, though.

5.10.1 should be out just after new years.

-- 
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: Switching to Qt 5.10

[Thiago Macieira]

On Friday, 8 December 2017 03:21:04 PST Dirk Hohndel wrote:
> Actually, I just wanted to switch to Qt 5.10 and start testing with that.

Please note that 5.10.0 has problems renaming files on Android, due to an 
unexpected SELinux rule. I advise to wait for 5.10.1.

-- 
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: ReleaseNotes.txt and merge conflicts

[Thiago Macieira]

On Monday, 27 November 2017 15:18:19 PST Lubomir I. Ivanov wrote:
> > Isn’t this what we are looking for:
> > 
> > http://krlmlr.github.io/using-gitattributes-to-avoid-merge-conflicts/
> 
> i think, yes. that's exactly what we are looking for.
> i wonder if it would work with the current ReleaseNotes.txt layout
> where lines are inserted at the bottom of a new release and on top of
> old ones. i guess i can test it.

Since we're using GitHub itself to do the merges, can you confirm that it does 
respect this .gitattributes attribute?

-- 
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: ReleaseNotes.txt and merge conflicts

[Thiago Macieira]

On Monday, 27 November 2017 14:19:50 PST Lubomir I. Ivanov wrote:
> maybe we can think of a mechanic to avoid the release note conflicts,
> as these are more common now that everyone edits the file next to a
> pull request.

The way we do in Qt is to add it to the commit message. Later, in the release 
process, we run a script that collects all entries and produces the file.

If we want to use the Qt script, the format is:

[ChangeLog][Area1][Area2] Text text.

The Area2 is optional. Each entry is a separate Git commit message paragraph, 
so it can be wrapped around multiple lines and needs to be separated from 
other text (including other entries) by a blank line. See as an example:

http://code.qt.io/cgit/qt/qtbase.git/commit/?
id=92ca09147fc239762927595165f71a0d1ecff98f

-- 
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: bool different in C and C++?

[Thiago Macieira]

On sábado, 18 de novembro de 2017 08:19:41 PST Berthold Stoeger wrote:
> in core/pref.h we find the comment
> /* can't use 'bool' for the boolean values - different size in C and C++ */

The comment is wrong. It's been wrong for 18 years, since C99 introduced 
stdbool.h.

-- 
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: no luck with Qt 5.9.2

[Thiago Macieira]

On Tuesday, 24 October 2017 10:32:10 PDT Jan Mulder wrote:
> > I can help poke people, though. Can you report the current findings so
> > I'll
> > poke people?
> 
> created QTBUG-64017

Thanks Jan

Let's see what the maintainers say.

Did I mention I find the disk cache a hacky feature?

-- 
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: no luck with Qt 5.9.2

[Thiago Macieira]

On Tuesday, 24 October 2017 08:30:14 PDT Tomaz Canabrava wrote:
> > I found one commit that is in Qt 5.9.2 (and not in 5.9.1) called "Fix qml
> > cache invalidation when changing dependent C++ registered QML singletons"
> > (commit 98358715930739ca8de172d88c5ce6941c275ff3 in qtdeclarative).
> > Related
> > to QTBUG-62243.
> > 
> > The rationale of that commit is fully sane to me, but ... I reverted this
> > one, and my problem of unable to start Subsurface-mobile build with 5.9.2
> > (on desktop, for now) due to a silent failure of engine.load("main.qml")
> > is
> > gone, and the mobile-on-desktop app runs correctly as before.
> > 
> > So, now the big question is ... how to proceed? I still cannot rule out
> > that
> > the whole issue is a result of some (still unknown) bug in Subsurface
> > itself, or Kirigami or ... But, building a tiny bug demonstrator for Qt
> > might be over my skill set :-)
> > 
> > For anyone that might wonder how I found this suspicious commit ... I
> > found
> > earlier that the Kirigami file Units.qml was involved, and that is a
> > singleton type object. That made me search for singleton related code
> > changes in Qt.
> 
> This is something that we can poke thiago, and thiago can poke more people.
> And it's a serious issue as this can break a lot of usecases of qt.

And he did.

The first thing we should do is file a bug with the findings so far and the 
symptoms, even if we can't provide a reduced testcase.

Further from that, I can't directly help, since I have no idea about the QML 
internals. I do know that the QML caching feature is something I have problems 
with, but that's usually because I build from sources and not from releases. 
Intermediary builds can leave corrupt caches.

I can help poke people, though. Can you report the current findings so I'll 
poke people?

-- 
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: removing Marble traces from the Subsurface tree

[Thiago Macieira]

On Friday, 25 August 2017 12:50:01 PDT Lubomir I. Ivanov wrote:
> do you happen to have qtlocation5-private-dev in the package manager?

I asked the packagers.

They said they don't want to create the -private-dev packages if they can 
avoid it, since it is too tempting for other packagers to use them. Since Qt 
does not offer API/ABI stability in the private headers, anything that depends 
on -private-dev must be rebuilt whenever Qt changes anything.

They're too few people to keep track of this and it takes too much resource 
(one week to rebuild everything -- remember that Debian supports some 
platforms for which there's no fast hardware).

But he did confirm that they do not patch them, so they should match the tag 
from the Qt repositories.

-- 
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: removing Marble traces from the Subsurface tree

[Thiago Macieira]

On Friday, 25 August 2017 12:43:28 PDT Lubomir I. Ivanov wrote:
> about the private headers not being available - i just read in a
> github project that some distros simply do not include them, so one
> has to download the offline Linux installer of Qt from here -
> https://www.qt.io/download-open-source/#section-2.

Most distros do include them. Fedora has them in the regular package:

https://koji.fedoraproject.org/koji/rpminfo?rpmID=10536754

OpenSUSE has in separate "private-headers-devel" packages:

https://build.opensuse.org/package/binaries/openSUSE:Leap:42.3/libqt5-qtbase?
repository=standard

-- 
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: Qt 5.9 openssl problems on F26

[Thiago Macieira]

On Sunday, 6 August 2017 00:07:30 PDT Dirk Hohndel wrote:
> While I don't even pretend to be a security expert, this is a topic that I
> have quite some familiarity with. Yes, right now OpenSSL 1.0.2 (latest) is
> still considered "as secure" as 1.1.0 latest. I can understand the Qt team
> delaying this migration for 5.10 as it is quite painful.

There's also a licensing component here. One cannot distribute GPLv2-only 
software linking to OpenSSL 1.1.

Subsurface is GPLv2-only, isn't it?

-- 
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: Qt 5.9 openssl problems on F26

[Thiago Macieira]

On Sunday, 6 August 2017 18:42:24 PDT Linus Torvalds wrote:
> On Sat, Aug 5, 2017 at 9:16 PM, Thiago Macieira <thi...@macieira.org> wrote:
> > Patch and diff links in
> > http://code.qt.io/cgit/qt/qtbase.git/commit/?
> > id=cfbe03a6e035ab3cce5f04962cddd06bd414dcea
> 
> It doesn't really apply cleanly, but it's fixable, so I have 5.9 on F26
> working.

dbb2374d20959472ca379a38c37774518eef5bfe,  
dc8bfab82eb051a516a4138e50f2d8de5095319e and 
f78a189da5d9e13a96a52b9d17cdc80df06ed8c8 also touch those same files and they 
appear between current 5.9 branch tip and the OpenSSL 1.1 commit above.

-- 
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: Qt 5.9 openssl problems on F26

[Thiago Macieira]

On Saturday, 5 August 2017 17:07:50 PDT Linus Torvalds wrote:
> You don't use old versions of security software. It's that easy. Not done,
> not acceptable, not a solution.

To be clear: OpenSSL 1.0.2l was released on the very same day as 1.1.0f. Both 
branches are currently maintained.

-- 
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: Qt 5.9 openssl problems on F26

[Thiago Macieira]

On Saturday, 5 August 2017 20:54:59 PDT Linus Torvalds wrote:
> On Aug 5, 2017 20:48, "Thiago Macieira" <thi...@macieira.org> wrote:
> 
> From the Qt Project's point of view, it's a new feature, so it was added to
> the devleopment branch. But it seems the patch is clean enough to be
> backported if a Linux distribution wants it for its purposes.
> 
> Christ, you people have some odd ideas about "new features". Like that
> while "it compiles" thing. Small new feature, that.

I agree on the "it compiles", but those at fault are the OpenSSL developers 
for suddenly breaking source compatibility with no grace period.  See 
https://www.mail-archive.com/tech@openbsd.org/msg36437.html for someone else 
complaining about the same issue (no, not Theo).

From Qt's point of view, it's a large refactoring of a central piece of 
technology. We couldn't add it to the stable release without further testing. 
Timing also didn't help: Qt 5.9 had already been feature frozen for almost two 
months when the patch was first uploaded (no idea when the author first began 
working on it).

> Can you point me to the actual patch that is clean enough to backport?

Lubomir sent the link, which includes all 63 iterations of the patch:
https://codereview.qt-project.org/189399

Patch and diff links in
http://code.qt.io/cgit/qt/qtbase.git/commit/?
id=cfbe03a6e035ab3cce5f04962cddd06bd414dcea

-- 
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: Qt 5.9 openssl problems on F26

[Thiago Macieira]

On Saturday, 5 August 2017 17:07:50 PDT Linus Torvalds wrote:
> I did see some patches, and another big report that was allegedly closed
> because of those patches, but they don't actually seem to be merged
> although the bug report said they were upstream. I suspect that there is
> some branch that worked at some point.

They are, but in Qt 5.10. You're building 5.9.1.

From the Qt Project's point of view, it's a new feature, so it was added to 
the devleopment branch. But it seems the patch is clean enough to be 
backported if a Linux distribution wants it for its purposes.

-- 
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: Qt 5.9 openssl problems on F26

[Thiago Macieira]

On Saturday, 5 August 2017 15:40:01 PDT Linus Torvalds wrote:
> Ok, I've worked around this by just using my old build, but it means
> that ssl doesn't work, which in turn means that I can't actually do
> the cloud access etc on my F26 desktop.
> 
> So I'm tried of my old broken At-5.9 build, and would like to know how
> to make a proper build against openssl-1.1.0, which is what F26 has.

OpenSSL 1.1 is work in progress for Qt. You have to use 1.0.

OpenSSL developers decided to break source compatibility and we haven't had 
time to adapt.

-- 
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: latest Windows binary crashes

[Thiago Macieira]

On segunda-feira, 3 de julho de 2017 14:32:35 PDT Dirk Hohndel wrote:
> Grumble.
> 
> I was told on the Qt list that there is a MUCH newer branch that I should
> try - they have updated to a current WebKit. The thing that's odd... between
> 5.7.1 (which the Windows binaries used to be based on) and 5.9 there
> shouldn't really have been any WebKit changes... so why does it crash now.

There are a number of minor changes submitted to the 5.8 and 5.9 branches by 
people like Konstantin, Allan and me. Mine were mostly just to make it, but 
looking at the diff there appear to be a couple of backports from upstream.

> > i mean i can possibly find the offending line of code, but i won't
> > really have a good fix for it. after seeing that unpredictable Marble
> > multi-threading crash on Windows, i think we are entering the
> > territory of big, complicated but unmaintained libraries that simply
> > may not run with the latest Qt version. Qt 6.0 is coming too...
> 
> I think they are working on 5.10 ...

Qt 6.0 will be discussed at the Contributor Summit this year in Berlin. The 
current idea is that 5.12 will be LTS and then 6.0. That would put 6.0 about 
two years away from now.

> > so we need to:
> > 1) move away from these unmaintained libraries
> > WebKit - currently we are stuck with WebKit on Windows
> > Grantlee - we are stuck with Grantlee due to the template syntax which
> > the users are already using
> > Marble - we probably should start using a 2D map of sorts
> 
> WebKit - I think we are stuck with that for a while
> Marble - Tomaz has this working with the latest, maintained Marble
> Grantee - I have this working on Mac

What happened to the idea of using QtLocation for maps?

> > BTW you can try building this QtWebKit port as it's actively updated:
> > https://github.com/annulen/webkit/releases
> 
> Yes, and that appears to be in the 5.212 branch of Qt that I need to
> find the time to investigate...

5.212 builds with CMake, not qmake anymore. My recommendation is that you 
build it after all the rest of Qt.

-- 
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: Dive download crash - Qt model issues

[Thiago Macieira]

On sábado, 24 de junho de 2017 11:05:25 PDT you wrote:
> The solution to that problem is "--developer-build".  That actually
> does exactly the right thing from a "build one single app against the
> special Qt tree that has a couple of experimental patches"
> perspective.

You can just do -prefix $PWD/qtbase if you're building from the top-level 
qt5.git.

You can also build only qtconnectivity on top of your existing libs and not 
install it. With LD_LIBRARY_PATH and QT_PLUGIN_PATH environment variables set, 
you should be able to run without installing too.

> Honestly, I'd probably prefer a non-debug developer mode, but the
> extra debug printouts it also seems to cause were actually super
> helpful for getting BLE going.

That should not have affected the debugging output... It seems to be a Fedora 
patch:
https://src.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qtlogging.ini

You can override it by setting QT_LOGGING_RULES=*.debug=true

-- 
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: Dive download crash - Qt model issues

[Thiago Macieira]

On sábado, 24 de junho de 2017 10:16:06 PDT Linus Torvalds wrote:
> Now, it may be that (once more) this is because I run my self-compiled
> Qt, and apparently it ends up adding more sanity checks and asserts
> when built in developer mode.

Going off on a tangent here, but...

Qt has release mode, debug mode and the "-developer-mode" switch. Be careful 
not to confuse the latter two: developer mode is debug mode but enables a few 
extra things so Qt's own unit tests can run, like exporting some functions so 
they can be called from the tests. Another consequence is that it compiles 
with -Werror and compiles each header individually, so the build time 
increases and you're more likely to get build failures.

Unless you're developing Qt itself like me, you don't want that option. Debug 
mode is fine for debugging into Qt itself and enables Q_ASSERT.

-- 
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: QtWebEngine and Mingw

[Thiago Macieira]

On sábado, 24 de junho de 2017 08:40:49 PDT Lubomir I. Ivanov wrote:
> to summarize:
> this leaves in a bit of a stalemate and unless Thiago has some sort of
> an idea,

Sorry, I don't have an idea.

> we should just stick with WebKit for as long as possible, or
> until:
> 1) clang WebEngine binaries can be used from mingw binaries

I don't think they can. The one being discussed here is the target "x86_64-
windows" which is compatible with MSVC (a.k.a clang-cl), not "x86_64-mingw" 
which is compatible with MinGW.

> 2) if we can build the whole Subsurface project using clang for
> Windows and WebEngine is also built using clang

Which is the same as switching to MSVC and build on Windows. My experience 
with clang-cl isn't very good, but at least you an mix it with MSVC and use 
2015 or 2017 where Clang-cl is still lacking.

-- 
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: MacBook Pro El Cap vers 10.11.6 (15G1510) Subsurface ver Subsurface v4.6.4

[Thiago Macieira]

On Thursday, 15 June 2017 16:42:43 PDT Lubomir I. Ivanov wrote:
> On 16 June 2017 at 00:38, Dirk Hohndel <d...@hohndel.org> wrote:
> > On Thu, Jun 15, 2017 at 03:07:43PM +, Tomaz Canabrava wrote:
> >> We really need to update marble on subsurface, I'll try to do that.
> > 
> > The problem is that we have quite a few significant changes in our branch
> > that remove features and fix issues we ran into. And keeping up with
> > upstream was a major pain. I thought we talked about using the Qt map
> > thingy instead of Marble - I'd much prefer that than spending more time on
> > Marble.
> 
> why not try to use the google maps API directly inside a html page in
> a Qt web-engine, with a no-restrictions google maps API key.
> (i suggested similar before we started using marble)

Please note that deploying a web engine is not permitted on iOS. So you need 
both a solution using qtwebengine (for desktops) and qtwebview (for mobile 
phones). I'd investigate qtlocation first, just to see if it solves the 
problem.

-- 
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: MacBook Pro El Cap vers 10.11.6 (15G1510) Subsurface ver Subsurface v4.6.4

[Thiago Macieira]

On Thursday, 15 June 2017 14:38:23 PDT Dirk Hohndel wrote:
> The problem is that we have quite a few significant changes in our branch
> that remove features and fix issues we ran into. And keeping up with
> upstream was a major pain. I thought we talked about using the Qt map
> thingy instead of Marble - I'd much prefer that than spending more time on
> Marble.

Qt Location?

The newer versions have nice support by MapBox, maintained in upstream by 
MapBox people.

But it's a map, not a globe.

-- 
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: Segfault when trying to edit cylinder information

[Thiago Macieira]

On terça-feira, 13 de junho de 2017 13:16:21 PDT Lubomir I. Ivanov wrote:
> i cannot reproduce the problem, but also the above should not happen
> as we allocate the cylinder "type" (tank_info_t->name) on the heap and
> it's address cannot be so low (0x1770).

It comes from:

struct tank_info_t *info = _info[index.row()];

which is a global variable in core/equipment.c:

struct tank_info_t tank_info[100] = {
...
};

and has been so since 2013. I don't see how
 a) tank_info could be wrong (unless it's a major compilation problem)
 and
 b) how index.row() could have been so exactly wrong to produce a pointer in 
the second memory page (it's too much of a coincidence)

Not to mention that index was created by QComboBox, as a result of resize 
operation, so even if there's another QModelIndex in the stack, it shouldn't 
have had an effect -- not to mention that those were also generated by Qt.

-- 
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: ASSERT: "bytes <= bufferSize" in file tools/qringbuffer.cpp, line 74

[Thiago Macieira]

On terça-feira, 13 de junho de 2017 03:09:51 PDT Linus Torvalds wrote:
> I seem to be the only one getting this, and I don't get it reliably
> either. It seems to be timing-related somehow, because it never
> happens under gdb, but I *can* catch it with a core-dump and then get
> gdb to show me where it is. Backtrace appended in case it makes
> anybody go "yeah".
> 
> This may be because I'm doing something wrong when I had to build my
> own Qt-5.9 (for doing BT). It seems to be some interaction with
> Marble.

The reason you may be getting this and no one else is that you did build your 
Qt so it's got assertions enabled. For everyone else, with them disabled, the 
code is just faulty but silent.

>   (gdb) p bytes
>   $1 = 115
>   (gdb) p bufferSize
>   $2 = 0

Any other threads running at this time? This smells like a race condition and 
caused by the Marble's "don't print debug" debugging functionality.

-- 
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: Initial crash in MacOS Sierra

[Thiago Macieira]

On sexta-feira, 26 de maio de 2017 12:53:54 PDT Thiago Macieira wrote:
> On segunda-feira, 15 de maio de 2017 01:55:33 PDT Robert Helling wrote:
> > Thiago,
> > 
> > could you please have a look at this:
> > https://github.com/Subsurface-divelog/subsurface/issues/398#issuecomment-3
> > 0
> > 1407498
> > 
> > User reports Subsurface crashing on start up and it seems it is in the
> > intial network operation where it determines if it is the latest version.
> > Somehow it seems Qt-networking is calling into CoreFoundations with an
> > illegal nil argument.
> > 
> > Needless to say, I cannot reproduce this problem here.
> 
> Hi Robert
> 
> I haven't yet got Subsurface to build on my Mac, so I couldn't debug yet.
> I'm trying to fight CMake so that it will find OpenSSL properly: my Mac is
> a little unusual in that I didn't install the Xcode Command Line tools, but
> instead I added
> 
>   /Applications/Xcode.app/Contents/Developer/Toolchains/
> XcodeDefault.xctoolchain/usr/bin
> 
> to $PATH instead. So I keep getting now:
> 
>  ld: library not found for -lssl
> 
> The older SDKs (for macOS 10.8 through 10.10) had libssl.dylib, but the
> newest Xcode only carries the 10.12 SDK and that doesn't have libssl.dylib.

That was easy to fix: just drop -lssl -lcrypto from the command-line. Then it 
links without errors.

-- 
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: Initial crash in MacOS Sierra

[Thiago Macieira]

On segunda-feira, 15 de maio de 2017 01:55:33 PDT Robert Helling wrote:
> Thiago,
> 
> could you please have a look at this:
> https://github.com/Subsurface-divelog/subsurface/issues/398#issuecomment-30
> 1407498
> 
> User reports Subsurface crashing on start up and it seems it is in the
> intial network operation where it determines if it is the latest version.
> Somehow it seems Qt-networking is calling into CoreFoundations with an
> illegal nil argument.
> 
> Needless to say, I cannot reproduce this problem here.

Hi Robert

I haven't yet got Subsurface to build on my Mac, so I couldn't debug yet. I'm 
trying to fight CMake so that it will find OpenSSL properly: my Mac is a little 
unusual in that I didn't install the Xcode Command Line tools, but instead I 
added 

  /Applications/Xcode.app/Contents/Developer/Toolchains/
XcodeDefault.xctoolchain/usr/bin

to $PATH instead. So I keep getting now:

 ld: library not found for -lssl

The older SDKs (for macOS 10.8 through 10.10) had libssl.dylib, but the newest 
Xcode only carries the 10.12 SDK and that doesn't have libssl.dylib.

-- 
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

[PATCH 1/1] Don't use the deprecated CMake variable

[Thiago Macieira]

The *_VERSION_STRING variable has been deprecated in Qt since 5.1.0. Use
the non-deprecated variable instead (which is not a string).

Qt 5.9.0 has a bug in the deprecated variable. Since it's deprecated,
it's probably not going to be fixed until 5.9.1. See
 https://bugreports.qt.io/browse/QTBUG-60936

Signed-off-by: Thiago Macieira <thi...@macieira.org>
---
 CMakeLists.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index cca2c0a3..bcdf6cd5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -218,9 +218,9 @@ set(QT_LIBRARIES Qt5::Core Qt5::Concurrent Qt5::Widgets 
Qt5::Network Qt5::Svg  Q
 set(QT_TEST_LIBRARIES ${QT_LIBRARIES} Qt5::Test)
 
 #disable bluetooth if Qt version is ancient.
-if (BTSUPPORT AND "${Qt5Core_VERSION_STRING}" STRLESS "5.4.0")
+if (BTSUPPORT AND "${Qt5Core_VERSION}" VERSION_LESS 5.4.0)
set(BTSUPPORT OFF)
-   message(STATUS "Turning off Bluetooth support as Qt version 
${Qt5Core_VERSION_STRING} is insufficient for that")
+   message(STATUS "Turning off Bluetooth support as Qt version 
${Qt5Core_VERSION} is insufficient for that")
list(REMOVE_ITEM QT_LIBRARIES Qt5::Bluetooth)
 endif()
 
-- 
2.12.2

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

[PATCH 1/1] Adapt build.sh if qmake is already in PATH on a Mac

[Thiago Macieira]

Some people (like me) have Qt elsewhere. So long as qmake is in PATH,
we should be able to support it.

Signed-off-by: Thiago Macieira <thi...@macieira.org>
---
 scripts/build.sh | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/build.sh b/scripts/build.sh
index 1e64b515..88437c76 100755
--- a/scripts/build.sh
+++ b/scripts/build.sh
@@ -174,7 +174,11 @@ if [ $BUILDMARBLE = 1 ]; then
mkdir -p build
cd build
if [ $PLATFORM = Darwin ] ; then
-   if [ -d "$HOME/Qt/5.8" ] ; then
+   # qmake in PATH?
+   libdir=`qmake -query QT_INSTALL_LIBS`
+   if [ $? -eq 0 ]; then
+   export CMAKE_PREFIX_PATH=$libdir/cmake
+   elif [ -d "$HOME/Qt/5.8" ] ; then
export CMAKE_PREFIX_PATH=~/Qt/5.8/clang_64/lib/cmake
elif [ -d "$HOME/Qt/5.7" ] ; then
export CMAKE_PREFIX_PATH=~/Qt/5.7/clang_64/lib/cmake
-- 
2.12.2

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

Re: Initial crash in MacOS Sierra

[Thiago Macieira]

On segunda-feira, 15 de maio de 2017 01:55:33 PDT Robert Helling wrote:
> Thiago,
> 
> could you please have a look at this:
> https://github.com/Subsurface-divelog/subsurface/issues/398#issuecomment-30
> 1407498
> <https://github.com/Subsurface-divelog/subsurface/issues/398#issuecomment-3
> 01407498>
> 
> User reports Subsurface crashing on start up and it seems it is in the
> intial network operation where it determines if it is the latest version.
> Somehow it seems Qt-networking is calling into CoreFoundations with an
> illegal nil argument.
> 
> Needless to say, I cannot reproduce this problem here.

Story of our lives :-)

I'll take a look later this week.

-- 
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: sudo 4.6.4 Aborted

[Thiago Macieira]

On segunda-feira, 15 de maio de 2017 08:40:38 PDT Dirk Hohndel wrote:
> > On May 15, 2017, at 8:32 AM, Thiago Macieira <thi...@macieira.org> wrote:
> > 
> > On segunda-feira, 15 de maio de 2017 06:38:51 PDT Dirk Hohndel wrote:
> >> I understand that. For us as a user of the library, though, having the
> >> app
> >> crash on something as trivial as not being able to connect to the
> >> display,
> >> that does seem a bit crude.
> > 
> > I know. It's a side-effect of not using exceptions: we have no way of
> > reporting that the connection failed, aside from aborting the application.
> > 
> > Would a change to _exit help?
> 
> The app reporting an error and calling _exit() (which means no "crash"
> message to the user) would be preferable in my view.

I think I can justify that change.

-- 
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: sudo 4.6.4 Aborted

[Thiago Macieira]

On segunda-feira, 15 de maio de 2017 06:38:51 PDT Dirk Hohndel wrote:
> I understand that. For us as a user of the library, though, having the app
> crash on something as trivial as not being able to connect to the display,
> that does seem a bit crude.

I know. It's a side-effect of not using exceptions: we have no way of 
reporting that the connection failed, aside from aborting the application.

Would a change to _exit help?

-- 
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: sudo 4.6.4 Aborted

[Thiago Macieira]

On domingo, 14 de maio de 2017 23:22:55 PDT Martin Měřinský wrote:
> > we should fix the reason you run as root in the first place.
> > 
> > > Because importing dives from DC doesn't work for me as a user. So
> > > for
> > > the short moment I run Subsurface as a root.
> > > 
> > > I tried, what manual says, but it didn't work.
> > > 
> > > sudo usermod -a -G dialout mermar
> > > sudo usermod -a -G uucp mermar
> > > 
> > > subsurface divelog.2017-04-10.xml
> > > Insufficient privileges to open the device /dev/ttyUSB0 Suunto
> > > (HelO2)
> > 
> > Can you send us the output of
> > 
> > ls -l /dev/ttyUSB0
> 
> crw-rw 1 root dialout 188, 0 kvě 15 08:21 /dev/ttyUSB0

And did you log out and then back in after running the usermod command? Check 
that the "id" command shows dialout.

-- 
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: sudo 4.6.4 Aborted

[Thiago Macieira]

On domingo, 14 de maio de 2017 21:52:56 PDT Dirk Hohndel wrote:
> Ah, apparently this is a Qt bug that was declared not a bug at some point
> (you can find quite a few threads about this), and the way to work around
> it is to implement your own Logger class and exit() instead of abort()
> when you get a "Could not connect to display error".
> 
> Not one of the more useful aspects of Qt, I'd like to add...

Unfortunately, exit() is often harmful in C++ programs, since the global & 
atexit destructors are run, but the stack hasn't been unwound so objects in 
the main() function continue to exist. This breaks a number of assumptions 
about the order in which things are destroyed (namely, that it is the opposite 
in which they were constructed).

Using _exit() might help, but it may bring its own set of problems. At least 
it's closer to the qFatal call that is there now.

-- 
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: sudo 4.6.4 Aborted

[Thiago Macieira]

On domingo, 14 de maio de 2017 21:20:01 PDT Martin Měřinský wrote:
> sudo subsurface divelog.xml
> [sudo] password for mermar:
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-
> root'
> No protocol specified
> QXcbConnection: Could not connect to display :0
> Aborted (core dumped)

Your X server refused the connection.

Best solution: don't use sudo. In fact, don't run Subsurface as root.

Why were you trying this?

-- 
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: [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: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

[Thiago Macieira]

Em terça-feira, 18 de abril de 2017 00:08:57 PDT você escreveu:
> I will try it this morning.
> Two remaining questions:
> - What is the default state now if we don't set it explicitly? Enabled true
> or false? 

Depends on the argument passed in the macro. With QtDebugMsg, it defaults to 
enabled; with QtWarningMsg, it defaults to disabled.

> - Where would be the right place in Subsurface code to put the
> MarbleDebug::setEnabled(false) ?

If we want it disabled by default, just change the macro.

-- 
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: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

[Thiago Macieira]

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/MarbleDebug
> .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?

-- 
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: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

[Thiago Macieira]

On segunda-feira, 17 de abril de 2017 14:53:12 PDT Lubomir I. Ivanov wrote:
> Stefan, could you please try building and running the attached patch?
> you can toggle the debugging with MarbleDebug::setEnabled(true/false)
> e.g. from the Subsurface source code.

Or by setting in your environment:

QT_LOGGING_RULES=marble.debug=true

-- 
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: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

[Thiago Macieira]

On segunda-feira, 17 de abril de 2017 14:41:13 PDT Lubomir I. Ivanov wrote:
> On 18 April 2017 at 00:18, Thiago Macieira <thi...@macieira.org> wrote:
> > On segunda-feira, 17 de abril de 2017 14:10:28 PDT Lubomir I. Ivanov 
wrote:
> >> i guess we could just do a:
> >> void MarbleDebug::setEnabled(bool enabled)
> >> {
> >> 
> >> Marble::loggingCategory.setEnabled(enabled);
> >> MarbleDebug::m_enabled = enabled;
> >> 
> >> }
> > 
> > I'd go a little further and drop the m_enabled variable completely. You
> > don't need it, let the bit in the QLoggingCategory variable keep the
> > state.
> > 
> > You'd have:
> > 
> > namespace MarbleDebug {
> > Q_LOGGING_CATEGORY(category, "marble", QtWarningMsg)
> > 
> > void setEnabled(bool enabled)
> > {
> > 
> > category.setEnabled(QtDebugMsg, enabled);
> > 
> > }
> > 
> > bool isEnabled()// do you even need this function?
> > {
> > 
> > return category.isDebugEnabled();
> > 
> > }
> > } //namespace MarbleDebug
> > 
> > This changes to the MarbleDebug namespace too.
> 
> thanks, i think i understand.
> 
> here are the updated Marble files and a patch diff for review.
> i can't build Marble to test these changes ATM though.

Looks good, so long as "Marble::category" isn't too generic a name.

-- 
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: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

[Thiago Macieira]

On segunda-feira, 17 de abril de 2017 14:10:28 PDT Lubomir I. Ivanov wrote:
> i guess we could just do a:
> void MarbleDebug::setEnabled(bool enabled)
> {
> Marble::loggingCategory.setEnabled(enabled);
> MarbleDebug::m_enabled = enabled;
> }

I'd go a little further and drop the m_enabled variable completely. You don't 
need it, let the bit in the QLoggingCategory variable keep the state.

You'd have:

namespace MarbleDebug {
Q_LOGGING_CATEGORY(category, "marble", QtWarningMsg)

void setEnabled(bool enabled)
{
category.setEnabled(QtDebugMsg, enabled);
}

bool isEnabled()// do you even need this function?
{
return category.isDebugEnabled();
}
} //namespace MarbleDebug

This changes to the MarbleDebug namespace too.

-- 
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: [PATCH] MarbleDebug: don't use a class extending QIODevice as a null device

[Thiago Macieira]

On segunda-feira, 17 de abril de 2017 13:24:26 PDT Lubomir I. Ivanov wrote:
> On 17 April 2017 at 22:29, Thiago Macieira <thi...@macieira.org> wrote:
> > On segunda-feira, 17 de abril de 2017 12:01:48 PDT Lubomir I. Ivanov 
wrote:
> >> QDebug mDebug()
> >> 
> >>  {
> >>  
> >> return QDebug( QtDebugMsg ); // or "return qDebug();"
> >> 
> >> }
> >> 
> >> which will essentially enable debug output for everything in Marble,
> >> until we write a dummy Class with an overloaded << operator to void
> >> all the incoming debug calls.
> > 
> > It would be better to use a category and then simply turn the category
> > off. It can be enabled manually by users with QT_LOGGING_RULES
> > environment variable.
> > 
> > See http://doc.qt.io/qt-5/qloggingcategory.html.
> 
> thanks, for the suggestion, Thiago.
> 
> Stefan, could you please test the attached patch and if it works,
> submit it to Github for approval.

This disables the debug output for the default category, that is, every user 
of qDebug().

I was suggesting turning mDebug() into qCDebug(...).

// in a header
namespace Marble {
Q_DECLARE_LOGGING_CATEGORY(loggingCategory)
}
#define mDebug  qCDebug(Marble::loggingCategory)

// in one source file
namespace Marble {
Q_LOGGING_CATEGORY(loggingCategory, "marble", QtWarningMsg)
}

-- 
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: Haunting a Windows "Subsurface not start but becoming zombie" bug

[Thiago Macieira]

Em domingo, 9 de abril de 2017, às 16:47:25 PDT, Lubomir I. Ivanov escreveu:
> g++ test.cpp -Wall -std=c++11 -O1 -S -o test-meyer.S
> 
> so, it's guarded with ___cxa_guard_acquire() and it appears that the
> c++11 flag doesn't matter much.

That's because GCC has used thread-safe initialisation of function statics for 
a long time. I know it was specified in the IA-64 C++ ABI, dating from 1999, 
but it's possible GCC supported it for longer (3.3 or earlier).

But it wasn't part of the C++ language specification. It only said that "if the 
initialisation is reentered, behaviour is undefined". So other compilers did 
not need to implement it.

C++11 did add a requirement that such initialisation must not deadlock. This 
is known to trip several implementations. Apple operating systems are known to 
fail that second bit too.

-- 
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: [PATCH] Detect location of `ldconfig' before use

[Thiago Macieira]

On domingo, 5 de fevereiro de 2017 12:53:38 PST Cristian Ionescu-Idbohrn 
wrote:
> +   _ldconfig=$(PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH command -v
> ldconfig) || { +   echo "can't find ldconfig" >&2
> +   exit 1
> +   }
> +   LIBGIT=$($_ldconfig -p | grep libgit2\\.so\\. | awk -F. '{ print $NF
> }')

Instead of trying to find it, I'd just do:

    ldconfig 2>/dev/null || true

-- 
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: Qt and subsurface for Android

[Thiago Macieira]

On segunda-feira, 9 de janeiro de 2017 21:59:40 PST Anton Lundin wrote:
> > I'm having this same problem. I thought it was my version of cmake, and
> > ended up updating my dist from wily to xenial (LTS) and then yakkety.
> > Still
> > no luck. I may try the above hack later... but is that the correct fix?
> 
> https://bugreports.qt.io/browse/QTBUG-54666
> 
> Sounds like cmake 3.7(!) might be the "fix".
> 
> 
> I currently just cmake || true so bash don't aborts on the return code,
> and it builds just fine.

See also the discussion in https://bugreports.qt.io/browse/QTBUG-57886. This 
is a CMake bug in that it fails to recognise the Clang for Android being a 
useful compiler. The bug report has a workaround, something about setting 
CMP0025.

I have no idea what that means or how to do it. Someone who understands CMake 
should read the bug report and apply the fix.

-- 
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: since we are testing things on Mac...

[Thiago Macieira]

On domingo, 1 de janeiro de 2017 18:33:02 BRST Dirk Hohndel wrote:
> For kicks and giggles I dug out an almost ten year old Mac running 10.6.
> That one will happen. Qt is limited to 5.3 on that for example. And we
> don't have a C++11 compiler...

That's ok, Qt 5.3 didn't require it (Qt 5.6 doesn't either).

The problem is the compiler itself, though. Apple's GCC 4.2 was stuck in time 
for a long time, with known miscompilation bugs. If you can get Clang to work, 
it would be the best result.

-- 
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: anyone with a Mac running 10.7 or 10.8?

[Thiago Macieira]

Em domingo, 1 de janeiro de 2017, às 09:48:01 BRST, Dirk Hohndel escreveu:
> > On Jan 1, 2017, at 6:58 AM, Thiago Macieira <thi...@macieira.org> wrote:
> > 
> > It is the old AVX bug. VXORPS is an AVX instruction (that V is the tell)
> 
> And this library comes from OpenSSL which we get from HomeBrew. I can
> already see that I will hate where all this will take me, but I appreciate
> that thanks to Robert's access (if somewhat limited) to such an old machine
> we got reminded of the issue...
> 
> Doing some more research, it seems that not a lot of Macs should fall into
> the narrow overlap of "able to run 10.7 and don't have AVX". But I'll see
> what I can do.

I think HomeBrew by default builds targetting the local machine (-
march=native), which makes the binaries unsuitable for distribution. There's a 
switch somewhere to make it build generic binaries.

-- 
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: anyone with a Mac running 10.7 or 10.8?

[Thiago Macieira]

  It is the old AVX bug. VXORPS is an AVX instruction (that V is the tell)Sent from my BlackBerry — the most secure mobile deviceFrom: hell...@atdotde.deSent: 1 January 2017 12:54 p.m.To: thi...@macieira.orgCc: subsurface@subsurface-divelog.orgSubject: Re: anyone with a Mac running 10.7 or 10.8?  On 01 Jan 2017, at 14:07, Robert Helling  wrote:that was quick: Xcode requires at least 10.11.5 … luckily, knowing the URL one can download old developer disks. So, here we go:* thread #1: tid = 0x1f03, 0x0001043eb574 libcrypto.1.0.0.dylib`ENGINE_pkey_asn1_find_str + 12, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)    frame #0: 0x0001043eb574 libcrypto.1.0.0.dylib`ENGINE_pkey_asn1_find_str + 12libcrypto.1.0.0.dylib`ENGINE_pkey_asn1_find_str + 12:-> 0x1043eb574:  vxorps %xmm0, %xmm0, %xmm0   0x1043eb578:  vmovaps%xmm0, -48(%rbp)   0x1043eb57d:  movq   %rsi, -32(%rbp)   0x1043eb581:  movl   %edx, -24(%rbp)As I don’t speak i386 assembly, I have no idea what that means.BestRobert___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: anyone with a Mac running 10.7 or 10.8?

[Thiago Macieira]

 Apologies about top-postingDoesn't OSX generate a crash report? It should be possible to debug on your regular Mac. If not, we can probably guess what instruction it was: do you know what processor this old mini of your has? Sent from my BlackBerry — the most secure mobile deviceFrom: hell...@atdotde.deSent: 1 January 2017 11:14 a.m.To: thi...@macieira.orgCc: subsurface@subsurface-divelog.orgSubject: Re: anyone with a Mac running 10.7 or 10.8?  On 01 Jan 2017, at 14:07, Robert Helling  wrote:that was quick: Xcode requires at least 10.11.5 … and home-brew also requires Xcode command line tools…Any idea how I could install a debugger?BestRobert___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: anyone with a Mac running 10.7 or 10.8?

[Thiago Macieira]

Em domingo, 1 de janeiro de 2017, às 12:52:50 BRST, Robert Helling escreveu:
> From the command line it's the same, it crashes with "Illegal instruction:4"

Any chance you can get the backtrace or disassembly of the crashing 
instruction? This rings a bell of a problem we had way in the past when some 
code had AVX instructions, which would cause it to run on hardware pre-2011.

-- 
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: anyone with a Mac running 10.7 or 10.8?

[Thiago Macieira]

Em sábado, 31 de dezembro de 2016, às 20:29:10 BRST, Dirk Hohndel escreveu:
> From looking through the Subsurface cloud server logs I can see that we
> still have a fair number of users on MacOS 10.7 and 10.8. I went through
> the effort to create a DMG that should run even on 10.7. I'd love it if
> someone could verify that this actually works.
> 
> http://subsurface-divelog.org/downloads/daily/Subsurface-4.5.96-36-ge94d4966
> 8ef9-10.7.dmg
> 
> The regular DMG should run on 10.9 and newer (it would also be useful to
> verify that this does, indeed, run on 10.9 and doesn't run on 10.7 or
> 10.8).

I have a 10.9 VM in the office, so I can test it in a week's time.

Unfortunately, it didn't occur to me to create VMs from the recovery images 
until after I had upgraded from 10.8 to 10.9, so I can't test 10.8.

-- 
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