From diegoiast at gmail.com Thu Sep 1 09:34:10 2016 From: diegoiast at gmail.com (Diego Iastrubni) Date: Thu, 1 Sep 2016 10:34:10 +0300 Subject: [Development] On deprecated APIs In-Reply-To: <858e42dd-21d6-9c70-139d-5f4eabe565f0@qt.io> References: <201608310938.22262.marc.mutz@kdab.com> <20160831105040.7A5B.6F0322A@gmail.com> <858e42dd-21d6-9c70-139d-5f4eabe565f0@qt.io> Message-ID: Maybe the wording is wrong... how about "not recommended" instead of "deprecated"? I would also like to have an option to be able to compile a "qforeach" block without the compiler spitting at me (/me takes off the java developer hat). On Wed, Aug 31, 2016 at 12:27 PM, Ulf Hermann wrote: > > This is a debate convenience vs performance; >> >> * Q_FOREACH will never detach, hence it is convenient. >> * A for-loop can be (a very little more) optimized, as long as you work >> on const containers or use qAsCont (and many will forget about that... >> which >> is *not* convenient) >> > > ... especially as there is no qAsConst() for containers returned from > functions. Those have to be saved in a local variable first, which makes > the code not only less convenient but also uglier. > > I understand that we should teach people to avoid premature pessimzation, > but at some point the pessimization might not actually be premature > anymore. Q_FOREACH always makes a copy. This means you cannot mess up the > logic if you change the code to modify the container in the loop body. You > might actively decide to take a small performance hit for the convenience > of not having to take care of this every time you change a loop body. > > The rules on when a Q_FOREACH detaches an implicitly shared container are > also comparably simple. If you take a non-const reference as "iterator", > then it detaches. If the reference is const or if you iterate by value, it > won't detach. The rules in the "ranged for" case are more complicated and > the user might actively trade a small performance hit for the ability to > see the detaching behavior on first glance. > > Those are valid tradeoffs to be considered by the users and we should not > impose either solution on them. So, I think there is still a place for > Q_FOREACH in user code and we should not deprecate it in the first place. I > agree that it's a good idea not to use it in Qt code. > > regards, > Ulf > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janne.anttila at qt.io Thu Sep 1 11:51:07 2016 From: janne.anttila at qt.io (Janne Anttila) Date: Thu, 1 Sep 2016 09:51:07 +0000 Subject: [Development] Test email - please ignore Message-ID: -- Janne -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Sep 1 15:00:11 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 01 Sep 2016 15:00:11 +0200 Subject: [Development] Overly large Gerrit fetch in QtBase...?! In-Reply-To: <201608311541.18674.marc.mutz@kdab.com> References: <201608311541.18674.marc.mutz@kdab.com> Message-ID: <6088139.jnUjhJZTqo@tjmaciei-mobl1> Em quarta-feira, 31 de agosto de 2016, às 15:41:18 CEST, Marc Mutz escreveu: > Receiving objects: 100% (41981/41981), 70.13 MiB | 362 KiB/s, done. > Resolving deltas: 100% (21723/21723), completed with 754 local objects. > From codereview.qt-project.org:qt/qtbase > e52fcb7..531a2b1 5.6 -> gerrit/5.6 > 47aad8f..8d8c7b3 5.6.2 -> gerrit/5.6.2 > 6cbd982..fa2aef5 5.7 -> gerrit/5.7 > 829c59a..84830fc 5.8 -> gerrit/5.8 > b012f55..f510a51 dev -> gerrit/dev > > that's extreme, compared to the size of the .git, here from a repo copy I > didn't fetch, yet: Git diff --stat on those ranges doesn't show anything big. The largest change is a 3000-line update to src/3rdparty/pcre/pcre_jit_compile.c. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Sep 1 15:22:29 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 1 Sep 2016 15:22:29 +0200 Subject: [Development] CI/5.6: "Failed 7 times to aqcuire the hardware" (was: Fwd: Change in qt/qtbase[5.6]: qstrncpy: don't call strncpy_s with invalid parameters) Message-ID: <201609011522.31152.marc.mutz@kdab.com> Hi, Twice in succession. Any idea what's happening? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- An embedded message was scrubbed... From: "Qt CI Bot (Code Review)" Subject: Change in qt/qtbase[5.6]: qstrncpy: don't call strncpy_s with invalid parameters Date: Thu, 1 Sep 2016 12:25:42 +0000 Size: 4985 URL: From antti.kokko at qt.io Thu Sep 1 16:22:14 2016 From: antti.kokko at qt.io (Antti Kokko) Date: Thu, 1 Sep 2016 14:22:14 +0000 Subject: [Development] Qt 5.8 alpha packages available Message-ID: Hi all, We have Qt 5.8 alpha src packages available here: http://download.qt.io/snapshots/qt/5.8/5.8.0-alpha/latest_src/ Please note that the files were just copied, it might take couple of hours for the mirror sync to complete. Please check the packages to see if those are OK for alpha purposes (compilation seems to work, all needed modules etc are in the packages). We will release these packages as Qt 5.8 Alpha most probably tomorrow if no alpha blockers found. So please inform all alpha blockers immediately to releasing at qt-project.org (please remember to fill proper bug report as well) . BR, Antti Antti Kokko Release Engineer The Qt Company Elektroniikkatie 13 90590, Oulu, Finland antti.kokko at qt.io +358 40 8275912 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoenitz at t-online.de Thu Sep 1 20:48:57 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 1 Sep 2016 20:48:57 +0200 Subject: [Development] On deprecated APIs In-Reply-To: <201608312138.04076.marc.mutz@kdab.com> References: <201608310938.22262.marc.mutz@kdab.com> <20160831190427.GA5342@klara.mpi.htwm.de> <201608312138.04076.marc.mutz@kdab.com> Message-ID: <20160901184857.GA1734@klara.mpi.htwm.de> On Wed, Aug 31, 2016 at 09:38:03PM +0200, Marc Mutz wrote: > Hi André, > > On Wednesday 31 August 2016 21:04:27 André Pönitz wrote: > > They are not completely independent, but a 'Q_FOREACH' ban in Qt > > proper does not have to imply its removal for users. If it is > > not useful in your view, you can mention it in the docs. Breaking > > formerly compilable code for no good reason is not a good base > > for a 'contract'. > > All the text in my email (which you cut away) is about how _not_ to break > formerly compilable code, for *any* reason. That's a bit of a stretch, as some users *do* want builds with full warnings and -Werror or similar atrocities, but with the 'In return, the Qt users: stop insisting on -Wdeprecated-clean builds without' it'd be part of the price they pay for the deal. > What I actually don't understand is why people are so keen on enabling - > Wdeprecated and at the same time don't want to move a finger about it. Because they can. Not that I think that this is a god idea, but some people do excruciating things just because they are possible. > Why enable it if it just annoys you? Why not just *not enable* the warning? > The fear, I guessed, is that if you don't enable it, you will get caught with > your pants down when your start compiling against Qt 6. > > So this proposal is for a way to lift that fear, so people who don't want to > don't feel that they need to enable -Wdeprecated, turning it into its former > meaning: API we have deprecated, not removed. > > So, do you have any opinion on the actual proposal? I do. Re-inserting the cut text: > > > I'd therefore like to propose a new contract with our users: > > > > > > The Qt Project: > > > - continues to deprecate API it wants gone I'd like to see this weakened a bit, maybe by adding something like 'if a reasonable replacements has been shipped in the previous $K minor releases'. K == 2 would feel good to me. > > > - maintains deprecated Qt N.x API until Qt (N+1).0. That's generous. I'd be even ok with something harsher, like 'maintains deprecated Qt N.Y API until Qt (N+1).0 _or_ Qt N.(Y+5), whatever happens earlier'. > > > - does *not* remove deprecated N.x API anymore come (N+1).0 Same here. > > > - does also *not* maintain deprecated N.x API after the initial (N+1).0.0 > > > release > > > * (ie. N+1).y CI runs with API deprecated in N.x (or earlier) disabled > > > * also means Qt does the work of making sure deprecated API is turned > > > all-inline before a .0.0 release to maintain BC. Something that I believe is valuable is to provide an upgrade path from N.y to (N+1).0 that's as source compatible as possible. We had Qt Creator compilable on Qt 4 and Qt 5 for quite a while, and this was a real boon to catch Qt 4 -> Qt 5 regressions. This can be phased out after (N+1).2 or so, and it's not really in contrast to what you are suggesting here. > > > In return, the Qt users: > > > - stop insisting on -Wdeprecated-clean builds without investing time of their > > > own into updating their sources > > > - provide patches to maintain deprecated APIs we no longer maintain > > > > > > In return, the Qt Project: > > > - pledges to take those patches in without hackling about "but it's > > > deprecated..." Ok. Andre' From giuseppe.dangelo at kdab.com Fri Sep 2 12:32:48 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Fri, 2 Sep 2016 12:32:48 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads Message-ID: Howdy, I'm trying to introduce a change [1] which will make QThread invoke std::terminate in case an exception is thrown from the new thread (including, but not limited to: user's reimplementation of QThread::run; slots listening to the QThread::started / finished signals; custom event dispatchers). The idea is to align ourselves to what std::thread does. There's a small catch, however: user code might be using platform-native APIs such as pthread_exit(3) in order to make a QThread quit. On some implementations (notably: glibc), pthread_exit is implemented by throwing an exception, because it needs to run the pushed cleanup handlers. The net result is that, with my change applied, pthread_exit won't make the thread exit but crash the application instead (!). The question for the ML is: is this a scenario Qt has ever officially supported, and a scenario that we should support in the future? (QThread documentation does not talk about how QThread itself is implemented, so actually relying on the that it has pthread semantics is already a slight API abuse by the users). [1] https://codereview.qt-project.org/#/c/167240/ Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From marc.mutz at kdab.com Fri Sep 2 13:35:12 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 2 Sep 2016 13:35:12 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: References: Message-ID: <201609021335.13281.marc.mutz@kdab.com> On Friday 02 September 2016 12:32:48 Giuseppe D'Angelo wrote: > On some implementations (notably: glibc), pthread_exit is implemented by > throwing an exception, because it needs to run the pushed cleanup > handlers. The net result is that, with my change applied, pthread_exit > won't make the thread exit but crash the application instead (!). I thought you can catch that particular exception type, and ignore it (= rethrow). It's something with cxa and abi, but I can't find it anymore. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Fri Sep 2 17:01:05 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 02 Sep 2016 17:01:05 +0200 Subject: [Development] Notes on QtCore session @ QCS2016 Message-ID: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> https://wiki.qt.io/QtCS2016_QtCore * Deprecation of APIs * qrand/qsrand -> replacement is Standard Library or your own * FIPS compliance * QCryptographicHash, random generator * requires external (optional) implementation, provided by OpenSSL * loading of OpenSSL libcrypto: either via QtNetwork or by compile-time switch (-openssl-linked) * Later: Use the SHA1 & SHA256 instructions * QStringView & QByteArrayView * Deprecate QStringRef * Not QArrayView: discuss later * allocator for QObject * custom operator new() * might conflict with combined moc space savings * which conflicts with includemoc for Clang warnings * Metaobject improvements for QML * make separate session * Animation framework, item models & statemachine * Move out of QtCore in Qt 6 * MIME type too? * C++11 Standard Library compatibility list * no volunteers yet * C++ ABI * libstdc++ still breaking compatibility in std::function * not now, revisit in a year or two * C++17 filesystem * go for it, inline only, QT_HAS_INCLUDE() * C++11 API style compatibility (empty vs isEmpty) * no update -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Sep 2 17:21:44 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 02 Sep 2016 17:21:44 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: <201609021335.13281.marc.mutz@kdab.com> References: <201609021335.13281.marc.mutz@kdab.com> Message-ID: <1915208.UW1dPaaHRG@tjmaciei-mobl1> Em sexta-feira, 2 de setembro de 2016, às 13:35:12 CEST, Marc Mutz escreveu: > On Friday 02 September 2016 12:32:48 Giuseppe D'Angelo wrote: > > On some implementations (notably: glibc), pthread_exit is implemented by > > throwing an exception, because it needs to run the pushed cleanup > > handlers. The net result is that, with my change applied, pthread_exit > > won't make the thread exit but crash the application instead (!). > > I thought you can catch that particular exception type, and ignore it (= > rethrow). It's something with cxa and abi, but I can't find it anymore. I've found the libstdc++ code for std::thread. It does this: __try { __t->_M_run(); } __catch(const __cxxabiv1::__forced_unwind&) { __throw_exception_again; } __catch(...) { std::terminate(); } Our question is: do we want to rely on abi::__forced_unwind? It's declared if we include the public header , but it's not documented in the ABI spec: https://mentorembedded.github.io/cxx-abi/abi-eh.html Should we ask the ABI people? Or are we ok with what Peppe proposed: if you pthread_exit() a QThread, the whole application exits. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From giuseppe.dangelo at kdab.com Fri Sep 2 18:06:27 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Fri, 2 Sep 2016 18:06:27 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: <1915208.UW1dPaaHRG@tjmaciei-mobl1> References: <201609021335.13281.marc.mutz@kdab.com> <1915208.UW1dPaaHRG@tjmaciei-mobl1> Message-ID: Il 02/09/2016 17:21, Thiago Macieira ha scritto: > Our question is: do we want to rely on abi::__forced_unwind? It's declared if > we include the public header , but it's not documented in the ABI > spec: https://mentorembedded.github.io/cxx-abi/abi-eh.html This one in particular is also documented/mentioned in libstdc++'s manual: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html Wonder if it's a good idea to rely on this, though (what about libc++ or other STD implementations?) Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Fri Sep 2 22:35:59 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 02 Sep 2016 22:35:59 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: References: <1915208.UW1dPaaHRG@tjmaciei-mobl1> Message-ID: <4296462.nTlXLaONEc@tjmaciei-mobl1> Em sexta-feira, 2 de setembro de 2016, às 18:06:27 CEST, Giuseppe D'Angelo escreveu: > Il 02/09/2016 17:21, Thiago Macieira ha scritto: > > Our question is: do we want to rely on abi::__forced_unwind? It's declared > > if we include the public header , but it's not documented in > > the ABI spec: https://mentorembedded.github.io/cxx-abi/abi-eh.html > > This one in particular is also documented/mentioned in libstdc++'s manual: > > https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html > > Wonder if it's a good idea to rely on this, though (what about libc++ or > other STD implementations?) There's no "__forced_unwind" in either LLVM libc++ (libcxx.git), libc++abi (libcxxabi) or libunwind. libstdc++ (libsupc++) has it in __gxx_personality_v0, which libc++abi also provides, but doesn't reference that class. That means users of std::thread (from either libc++ or libstdc++) when using libc++abi will not catch the exception at all and the application will just crash/quit when a cancellation happens with glibc pthread. I'd say that's a defect in libc++ and in libc++abi caused by the way glibc does pthread cancellation. However, the documentation from the ABI says that forced unwinds cannot be stopped, so you can't swallow the exception even if you wanted to. Are you sure that the application crashes when you pthread_exit() when QThreadPrivate::start() is noexcept? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Sep 2 23:45:26 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 2 Sep 2016 23:45:26 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: <4296462.nTlXLaONEc@tjmaciei-mobl1> References: <4296462.nTlXLaONEc@tjmaciei-mobl1> Message-ID: <201609022345.27053.marc.mutz@kdab.com> On Friday 02 September 2016 22:35:59 Thiago Macieira wrote: > However, the documentation from the ABI says that forced unwinds cannot be > stopped, so you can't swallow the exception even if you wanted to. Are you > sure that the application crashes when you pthread_exit() when > QThreadPrivate::start() is noexcept? Can't swallow doesn't mean can't catch. You can catch it, but you can't not rethrow. But if you call std::terminate(), the rethrow will never be reached. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From kevin.kofler at chello.at Sat Sep 3 04:30:33 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 03 Sep 2016 04:30:33 +0200 Subject: [Development] On deprecated APIs References: <201608310938.22262.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > My porting guide for Q_FOREACH -> C++11 ranged for has created the > expected outcry from users. Well, at least I object to deprecating Q_FOREACH to begin with, even if you don't remove it. It's just the safer (no risk of accidental detaches, as long as you use Qt containers) and more convenient API. Kevin Kofler From thiago.macieira at intel.com Sat Sep 3 09:03:21 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 03 Sep 2016 09:03:21 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: <201609022345.27053.marc.mutz@kdab.com> References: <4296462.nTlXLaONEc@tjmaciei-mobl1> <201609022345.27053.marc.mutz@kdab.com> Message-ID: <8615812.gtAI1A4odG@tjmaciei-mobl1> Em sexta-feira, 2 de setembro de 2016, às 23:45:26 CEST, Marc Mutz escreveu: > On Friday 02 September 2016 22:35:59 Thiago Macieira wrote: > > However, the documentation from the ABI says that forced unwinds cannot be > > stopped, so you can't swallow the exception even if you wanted to. Are you > > sure that the application crashes when you pthread_exit() when > > QThreadPrivate::start() is noexcept? > > Can't swallow doesn't mean can't catch. You can catch it, but you can't not > rethrow. But if you call std::terminate(), the rethrow will never be > reached. But that doesn't do what we want. We want to rethrow the __forced_unwind exception so that it terminates the thread, but not the entire application. But anyway, what I asked didn't work. Test app: #include void do_exit() noexcept { pthread_exit(nullptr); } int dummy; void *thread_function(void *) { do_exit(); return &dummy; } int main() { pthread_t thr; void *retval; pthread_create(&thr, nullptr, thread_function, nullptr); pthread_join(thr, &retval); return retval == nullptr ? 0 : 1; } Crash backtrace: #0 0x00007ffff6fa9975 in raise () from /lib64/libc.so.6 #1 0x00007ffff6faad8a in abort () from /lib64/libc.so.6 #2 0x00007ffff78ca6bd in __gnu_cxx::__verbose_terminate_handler() () from / usr/lib64/libstdc++.so.6 #3 0x00007ffff78c8696 in ?? () from /usr/lib64/libstdc++.so.6 #4 0x00007ffff78c86e1 in std::terminate() () from /usr/lib64/libstdc++.so.6 #5 0x00007ffff78c8314 in __gxx_personality_v0 () from /usr/lib64/libstdc+ +.so.6 #6 0x00007ffff73275a9 in ?? () from /lib64/libgcc_s.so.1 #7 0x00007ffff7327904 in _Unwind_ForcedUnwind () from /lib64/libgcc_s.so.1 #8 0x00007ffff7bcacb0 in __pthread_unwind () from /lib64/libpthread.so.0 #9 0x00007ffff7bc3595 in pthread_exit () from /lib64/libpthread.so.0 #10 0x0000000000400794 in do_exit() () #11 0x00000000004007a5 in thread_function(void*) () #12 0x00007ffff7bc2474 in start_thread () from /lib64/libpthread.so.0 #13 0x00007ffff705d3ed in clone () from /lib64/libc.so.6 I'll post to cxxabi and ask that __forced_unwind be made public API. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Sep 3 15:03:05 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 03 Sep 2016 15:03:05 +0200 Subject: [Development] Notes on Metaobject & QML discussion @ QCS2016 Message-ID: <2146413.zHDDdYtmZl@tjmaciei-mobl1> https://wiki.qt.io/QtCS2016_MetaObject * qMetaType() == qMetaType() ** Because QMetaObject::normalizedType("const T") == "T" ** Fix it * Q_NAMESPACE ** Keep it in 5.8 ** look into having it with multiple .h ** Q_ENUM_NS(OtherNamespace::Enum) or using Enum = OtherNamespace::Enum; is a good idea * Direct property access via the qt_static_metacall ** qdbusxml2cpp ** Add property & setProperty to QDBusAbstractInterfaceBase * Generated hash table ** properties, methods, enums ** hashing table needs to encode the type (Q_SIGNAL_CODE) ** perfect hashing doesn't help ** check if we can encode the hashing of the entire hierarchy ** "prelink" the class to its parent, recursively, but check at runtime * For Qt6: ** metatype vs C++ RTTI ** qMetaType() == &typeid(T) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From massimocallegari at yahoo.it Sun Sep 4 10:55:31 2016 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Sun, 4 Sep 2016 08:55:31 +0000 (UTC) Subject: [Development] qtbase 5.8.0 -O3 flag causes an internal compiler error on Ubuntu 16.04 References: <1533721499.109706.1472979331541.ref@mail.yahoo.com> Message-ID: <1533721499.109706.1472979331541@mail.yahoo.com> Hi, I am building Qt 5.8.0 alpha on Kubuntu 16.04 and the file qtbase/src/gui/painting/qdrawhelper.cpp causes a segmentation fault in GCC 5.4.0. In particular, it happens at line 4977: static void blend_transformed_argb(int count, const QSpan *spans, void *userData) After a few minutes, I found out that the -O3 flag in CXXFLAGS is causing this. Manually changing it to -O2 only for that file let the build proceed. Now, I know this most likely seems to be a GCC issue, but 16.04 is a LTS distro and the vanilla GCC is 5.4.0 (details below), so I just wanted to report this. Should I fire a Jira ticket or is this not pertinent ? Regards, Massimo Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --ena ble-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/us r/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-de bug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugi n --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre -- enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arc h-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-a bi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-li nux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2) From thiago.macieira at intel.com Sun Sep 4 11:20:53 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 04 Sep 2016 11:20:53 +0200 Subject: [Development] qtbase 5.8.0 -O3 flag causes an internal compiler error on Ubuntu 16.04 In-Reply-To: <1533721499.109706.1472979331541@mail.yahoo.com> References: <1533721499.109706.1472979331541.ref@mail.yahoo.com> <1533721499.109706.1472979331541@mail.yahoo.com> Message-ID: <6607738.sAYjsc6qgT@tjmaciei-mobl1> Em domingo, 4 de setembro de 2016, às 08:55:31 CEST, Massimo Callegari via Development escreveu: > Now, I know this most likely seems to be a GCC issue, but 16.04 is a LTS > distro and the vanilla GCC is 5.4.0 (details below), so I just wanted to > report this. Since it's an LTS distro, won't they update the compiler every now and then? Please note that the -O3 has been there since Qt 5.3. It's the code that changed and caused the ICE. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Sep 4 11:18:32 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 04 Sep 2016 11:18:32 +0200 Subject: [Development] Notes on "Contributing to Qt" session @ QCS 2016 Message-ID: <20748650.MOshRO9nvX@tjmaciei-mobl1> https://wiki.qt.io/QtCS2016_Contributions * Entry point: how do people find out how to contribute? ** We can more easily indicate to people how to contact developers ** Web Freenode * Making it easy to contribute, less intimidating ** Instructions too complex! ** Clean up the entry guidelines * Bug reports ** Bug triaging guidelines / hints / BKMs * Documentation fixes ** Can we make it easier? There's no need to build, only to run qdoc * Forums * "Junior jobs" ** Mark certain JIRA entries with the label ** Examples *** TBD: Examples repo *** Skeleton/template directory *** Modernise codebase (C++11, new styles not from Qt 2 days) ** Documentation * How to deal with patches that go unnoticed / unreviewed ** Get someone to review, ''anyone'' ** Add people who have worked in that file and other similar ones ** If a week goes by, add Maintainer and write "ping" * Mentoring programs ** GSoC via KDE * Rewards ** Recognising biggest new contributor in the last year to QCS ** Example: 10th commit gets you a coffee mug -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Sun Sep 4 11:27:19 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 4 Sep 2016 11:27:19 +0200 Subject: [Development] qtbase 5.8.0 -O3 flag causes an internal compiler error on Ubuntu 16.04 In-Reply-To: <1533721499.109706.1472979331541@mail.yahoo.com> References: <1533721499.109706.1472979331541.ref@mail.yahoo.com> <1533721499.109706.1472979331541@mail.yahoo.com> Message-ID: <201609041127.19698.marc.mutz@kdab.com> Hi Massimo, On Sunday 04 September 2016 10:55:31 Massimo Callegari via Development wrote: [...] > Now, I know this most likely seems to be a GCC issue, but 16.04 is a LTS > distro and the vanilla GCC is 5.4.0 (details below), so I just wanted to > report this. > > > Should I fire a Jira ticket or is this not pertinent ? [...] If the compiler crashes, you should file a report with the compiler (GCC), or Ubuntu. Or run memcheck86. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Sun Sep 4 14:05:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 04 Sep 2016 14:05:16 +0200 Subject: [Development] Notes on "Deprecating APIs & Modules" session @ QCS 2016 Message-ID: <1577834.cohHsAVWCp@tjmaciei-mobl1> https://wiki.qt.io/QtCS2016_Deprecating_APIs_and_Modules * Deprecating API ** Configuring them out ** Use QT_DEPRECATED_X to include a short description (if possible) *** Serious deprecations (any use is a flaw) should use Q_DECL_DEPRECATED_X ** Advertise the feature ** Should we increase the QT_DEPRECATED_SINCE value? *** Creator's project wizard should include QT_DEPRECATED_SINCE to current version *** qmake -project ** Change Qt Creator to increase QT_DEPRECATED_SINCE * Deprecating modules ** Policy: will not remove the module before 6.0 if we can; if we have to, it will be a soft-removal ** qmake should warn ** Security policy: most likely not get fixes ** How long must we support them? (non-removed) *** We fix security issues, P0 and P1 * Removing modules ** Soft-removal: not shipped, but still guaranteed to compile until 6.0 ** We fix only P0 issues ** No longer commercially supported ** Doesn't stop the release, but fix comes soon after *** fix should be in the works for the release to happen ** qt5.git should not build them; build should happen on top of qt5.git *** We should produce weekend updates that verify that they still compile (post to dev) *** For modules that run unit tests when staging patches, unit tests too == Separate discussion on qttools during cross-compilation == * host tools should be compiled outside of qt5.git * no need for wide compiler support * needs to be had separately -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Mon Sep 5 11:47:45 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 5 Sep 2016 09:47:45 +0000 Subject: [Development] Qt 5.8.0 Alpha released In-Reply-To: References: Message-ID: Hi, We have released Qt 5.8.0 Alpha, see http://blog.qt.io/blog/2016/09/05/qt-5-8-alpha-released/ At this time we managed to release it almost as planned, big thanks everyone involved! Br, Jani --- Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland Jani.heikkinen at qt.io +358 50 4873735 http://qt.io --- From andrew.knight at intopalo.com Mon Sep 5 11:49:03 2016 From: andrew.knight at intopalo.com (Andrew Knight) Date: Mon, 5 Sep 2016 12:49:03 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 Message-ID: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> We had a vibrant discussion on Qt Build Systems, hosted by Kai. tl;dr: Lots of discussion on the merits of which build system (CMake, Qbs) should replace qmake in building Qt; lots of supporters of CMake but no volunteers to do the work, many reasons to use Qbs as well. Some related discussions about how this impacts Qt Creator and the Qt offering in general. * Updates from various departments ** qmake - "Still undead" - qmake parses c++ now (dependency scanner) - configure system rewrite drove some qmake changes -- The changes are "not much" ~1500 lines of code to parse and use formal configuration -- These changes do not imply a commitment to qmake as Qt's permanent build system; the real work is done in configure.json and similar JSON files and can be ported to another build system - (Kai) "The message we want to send is: qmake will be deprecated, but supported for a long time" ** Qbs - Continues to be developed, mostly small incremental changes/releases - Has been used to build Creator for a long time (alongside qmake). Support for building Creator with qmake might eventually be dropped. - A WIP branch in qtbase (wip/qbs) demonstrates that Qbs can build Qt ** CMake - (Tobias) Cmake is the "worst" system in Qt Creator because CMake doesn't give enough feedback to the IDE. We need first-class support for CMake in Qt Creator, though, so that is irrelevant to the discussion of which system we use to build Qt. If we build Qt with Qbs, we have to also have support in Creator. In other words, the more build systems we support, the more work Creator folks have to do to maintain it. * Quick survey: which build system do you use (raise of hands by ~40 people) - CMake ~70% - qmake ~20% - Qbs ~10% * What should we use to build Qt in the future (qmake, Qbs, CMake)? ** Pro Qbs: - (Kai) "We can do better than CMake" - (Kai) "having our own build system is also about making a more "out of the box" experience for our users. Qt is more than a C++ library; we need to ship a good-quality build tool" - (Rich/Stephen) Qbs might be better at doing host tools and cross-compiled builds than CMake - Qbs doesn't have an intermediate step (i.e. makefile generation). Makefile generation has disadvantages for incremental builds and dependency tracking -- (Ossi) "acompletely accurate build dependency tracking system with a meta build system is very expensive" ** Pro CMake: - Much larger user base than Qbs, leading to possibly more contributions -- (Stephen) Most people (in this room) use CMake. - Qt is not in the business of creating a build tool - Qbs is still not finished - CMake is mature and widely used by Qt developers - Using an external tool tends to benefit both projects better: the CMake community benefits from Qt's fixes to CMake, while Qt benefits from the CMake community's improvements to CMake. - (Milian) CMakeis used by e.g. clang and it works for them - CMake comes with support for hundreds of modules; Qbs only supports Qt and pkg-config currently. ** General comments: - Do we really need to care what "outsiders" think of what we use in Qt? -- Yes, because it is a statement about what tool is good for Qt development. --- (Someone) "If Qbs is not used by Qt, why should I use it for my project? If Qt switches to Qbs, I will switch to it from CMake. With CMake, we don't have this problem: a lot of people are using it and it is evolving" -- Yes, because it is a statement about what tool is supported by Qt, and we don't want that tool to go away. --- (Eddy) "CMake will be there even if we lose interest. By using it in Qt, we shift the burden to someone else. If qmake's future is uncertain, it will make users uncomfortable --- (David) "Either something changes, or it dies" -- No, because Qt should support all major build systems anyway - Does Qbs support dependency tracking like CMake does -- Answer: Yes - (Stephen) "In reality, rewriting Qt's build system in CMake will actually be a PITA, and will require changes to CMake to make everything better" - (Rich) "Isn't the time better spent improving CMake than build a new build system?" - There is work to do to make Qt generate better CMake files - (Andreas) "I love that Qbs is declarative. I really love how Qbs can bind dependencies and rules on how I generate artifacts" - (Someone)"The beauty of Qbs is that it is accessible and it is clear how the separation between the declarative stops and the imperative begins." - (Someone) "Qbs doesn't seem very active, and Qt doesn't use it. This scares us. CMake is the best tool we have right now, but it isn't perfect." - (Eddy) Why are we using this ancient tool? (Referring to make) - (Andreas) "Every big project ends up building their own system. Qbs is a possibility to create a new build system. If it stays in the Qt Project, less people will use it." ** General sentiment: - As long as Qbs looks like a part of Qt, it is perceived as a Qt product, and is less attractive to external users. - Yet, there remains a conflict: "if Qt doesn't use it, I don't want to use it" vs. "if it's not outside of Qt, I don't want to use it" ** Summary: -- We are thinking about switching build systems. We don't know what to do yet, but we can't decide it here. ** Further notes on the switch: - Bootstrapping Qbs is required before we can really move forward. -- Solving this problem isn't rocket science (Ossi), it's just not a priority. -- Linux distro maintainers might be more compelled to put a static-built Qbs in their bootstrap if Qbs is seen as a core tool - (Stephen) "Go ahead and build a better build system, but make sure users can still use CMake" - (Jake) "Sometimes you have to do something different" From Wolfgang.Baron at gmx.net Mon Sep 5 12:15:25 2016 From: Wolfgang.Baron at gmx.net (Wolfgang Baron) Date: Mon, 5 Sep 2016 12:15:25 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: Message-ID: I really want to move to QBS, because of its advantages (speed, good dependency tracking, nice syntax, fexibility). However, as long as Qt-Creator keeps generating new projects using qmake templates, I am not so confident in the future of QBS. Also, if QBS is not used for all own projects, my confidence shrinks even further. I had a hard time getting around QBS's edges and I do not like to transform each new project from qmake to QBS and maybe away from QBS again it it does not stick. So if the Qt-project wants to have QBS, it's either all in or all out. For me as a developer, I am most interested in a clear decision, so that I know which build system to use in the future. Please make this decision a top priority and clearly communicate the result. Thanks! From nospam at vuorela.dk Mon Sep 5 12:27:37 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Mon, 5 Sep 2016 10:27:37 +0000 (UTC) Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: On 2016-09-05, Andrew Knight wrote: > tl;dr: Lots of discussion on the merits of which build system (CMake, > Qbs) should replace qmake in building Qt; lots of supporters of CMake > but no volunteers to do the work, many reasons to use Qbs as well. Some I do think that there is volunteers to get Qt building with cmake if there is a likly chance of getting it accepted. I think I also commmunicated that at the session. /Sune From enmarantispam at gmail.com Mon Sep 5 13:08:44 2016 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Mon, 5 Sep 2016 14:08:44 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: Been using QBS for the last 6 months, transformed all projects to it(from qmake). Never looked back. It just clicks for me. Most everything seems logical (if poorly explained) when you understand how to do it. One thing QBS needs is better documentation, because a lot of things that are "obvious" to Christian Kandeler and Jake Petroules (sorry if misspeled) are not ever mentioned in the docs or are in obscure places. Using QBS effectively is literally impossible without knowledge of freenode:#qt-qbs On Mon, Sep 5, 2016 at 1:27 PM, Sune Vuorela wrote: > On 2016-09-05, Andrew Knight wrote: > > tl;dr: Lots of discussion on the merits of which build system (CMake, > > Qbs) should replace qmake in building Qt; lots of supporters of CMake > > but no volunteers to do the work, many reasons to use Qbs as well. Some > > I do think that there is volunteers to get Qt building with cmake if > there is a likly chance of getting it accepted. I think I also > commmunicated that at the session. > > /Sune > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristian.adam at gmail.com Mon Sep 5 13:09:25 2016 From: cristian.adam at gmail.com (Cristian Adam) Date: Mon, 5 Sep 2016 13:09:25 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: On Mon, Sep 5, 2016 at 12:27 PM, Sune Vuorela wrote: > On 2016-09-05, Andrew Knight wrote: > > tl;dr: Lots of discussion on the merits of which build system (CMake, > > Qbs) should replace qmake in building Qt; lots of supporters of CMake > > but no volunteers to do the work, many reasons to use Qbs as well. Some > > I do think that there is volunteers to get Qt building with cmake if > there is a likly chance of getting it accepted. I think I also > commmunicated that at the session. > > There were volunteers to add CMake support to CopperSpice , the moc-less C++11 Qt fork. I don't see why there won't be any volunteers to add support for Qt. Unless it's not welcomed. That would be the Boost story all over again, where at some point Kitware volunteered to add manpower to the conversion, but boost people didn't want it. Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tero.kojo at qt.io Mon Sep 5 13:19:26 2016 From: tero.kojo at qt.io (Tero Kojo) Date: Mon, 5 Sep 2016 11:19:26 +0000 Subject: [Development] QtCon session notes Message-ID: Thank you to everyone who was at QtCon during the past weekend! I had a really good time, and from discussions there, others did as well. The session videos (for the sessions that had cameras) are coming online soon, right after we get the titles correct. While I see a good number of session notes here, please make sure that you send the notes here for everyone to see. Also put the notes to the Wiki https://wiki.qt.io/Qt_contributors_summit_2016 And the last thing, like the speaker email mentioned, you can upload your slides (if you had any) to the registration system where they will be attaached to the schedule for later viewing. And again thank you for a great event! Tero -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Mon Sep 5 14:13:03 2016 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 05 Sep 2016 14:13:03 +0200 Subject: [Development] Notes on Metaobject & QML discussion @ QCS2016 In-Reply-To: <2146413.zHDDdYtmZl@tjmaciei-mobl1> References: <2146413.zHDDdYtmZl@tjmaciei-mobl1> Message-ID: <1894649.E8huUCfaTA@maurice> On Samstag, 3. September 2016 15:03:05 CEST Thiago Macieira wrote: > https://wiki.qt.io/QtCS2016_MetaObject > > * qMetaType() == qMetaType() > ** Because QMetaObject::normalizedType("const T") == "T" > ** Fix it QMetaObject::normalizedType("const T") -> "T" //OK QMetaObject::normalizedType("T const") -> "T" //OK QMetaObject::normalizedType("const T*") -> "const T*" //OK QMetaObject::normalizedType("T const *") -> "const T*" //OK QMetaObject::normalizedType("T* const") -> "T*const" // Wrong (const not removed) QMetaObject::normalizedType("const T* const") "T*const" // VERY WRONG! QMetaObject::normalizedType("T const * const") -> "T*const" // VERY WRONG! So QMetaTypeId2 can be adapted fixed so that qMetaType() == qMetaType(). That should be a compatible change because normally const type could not be register anyway. QMetaObject::normalizedType should be ideally fixed as well. However this might be a compatibility problem as their name might be encoded by moc. Last time we change the normalization, we had to make sure to still understand function from the old moc object. See commit b881d8fb99972f1bd04ab4c84843cc8d43ddbeed (in Qt 4) (Similar bug fix) > * Q_NAMESPACE > ** Keep it in 5.8 > ** look into having it with multiple .h > ** Q_ENUM_NS(OtherNamespace::Enum) or using Enum = OtherNamespace::Enum; is > a good idea > * Direct property access via the qt_static_metacall Since Qt 5.5, the code that write the property is in qt_static_metacall rather than in the virtual qt_metacall. QML could optimize by calling directly the qt_static_metacall. However QML can't do it unconditionally otherwise it will break with old objects, it needs to check the PropertyAccessInStaticMetaCall flag. 4e9fc0129d6b4326c2159e4fafa42a3df9d35e0a in qtdeclarative need to be fixed. But moc does not set this flag by default because of the hack in qdbusxml2cpp. > ** qdbusxml2cpp > ** Add property & setProperty to QDBusAbstractInterfaceBase Thiago, are you taking care of that? > * Generated hash table The goal is to be able to simplify or get rid of the current Qml's Property hash table. > ** properties, methods, enums > ** hashing table needs to encode the type (Q_SIGNAL_CODE) Not Q_SIGNAL_CODE, we would need a flag for what it is (method, property, enum, ...) and maybe it's going to be a multi-hash. > ** perfect hashing doesn't help The way I see it, we increase the metaobject revision number, and we add int hashTableSize, hashTableOffest in QMetaObjectPrivate. We then generate a hash table. This could be an open addressing hash table (The moc can be smart and order the entries properly to reduce the clustering. Or use the "robin hood" scheme) > ** check if we can encode the hashing of the entire hierarchy > ** "prelink" the class to its parent, recursively, but check at runtime If we encode the entire hierarchy, the hash become invalid if the base class are upgraded because of a library upgrade that adds or reorder property. (even if the common case is that there is no change) One way to check for change would be to store in the QMetaObject's data a QCryptoGraphicHash (to avoid collision) of all the properties, methods, ... And also the one of the base class. So they can be compared at runtime. We could also have a pointer from the QMetaObject to be a pointer to a read- write location. It would point to something like: struct QMetaObjectExtraData { QAtomicInt initialized; // Set to 1 once we have done the runtime check int *hashTable; // a pointer to the hash table. the one pre-generated, // or another one on the heap if that was not valid. int extraArray[]; // can contain the cache of the type ids }; This actually does not need to be part of the QMetaObject itself, but can be in a QHash > * For Qt6: > ** metatype vs C++ RTTI > ** qMetaType() == &typeid(T) -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From stephen.kelly at ableton.com Mon Sep 5 14:40:54 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Mon, 5 Sep 2016 12:40:54 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: <98F2D36D-A065-4427-82C8-311E529F54E2@ableton.com> Thanks Andrew for these notes! You did really well to capture the key points from a complex and meandering discussion. >- (Stephen) "In reality, rewriting Qt's build system in CMake will >actually be a PITA, and will require changes to CMake to make everything >better" I think something was lost in transit on this point. I don’t think it would be a PITA to write a CMake buildsystem for Qt. I recall the above point was in reference to ‘compiling host tools and using them in the build while cross compiling’. The way CMake makes that possible currently(!) is implemented separately to the core of CMake with the ExternalProject module. It can be implemented better in the core of CMake if someone wants to do so and that would be better, but it’s not very urgent and no one has volunteered to do it. Even if CMake did better in that scenario though, that’s not the reason Qt is not going to use CMake, so it doesn’t matter anyway. Thanks, Steve. From andrew.knight at intopalo.com Mon Sep 5 14:49:03 2016 From: andrew.knight at intopalo.com (Andrew Knight) Date: Mon, 5 Sep 2016 15:49:03 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <98F2D36D-A065-4427-82C8-311E529F54E2@ableton.com> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <98F2D36D-A065-4427-82C8-311E529F54E2@ableton.com> Message-ID: Hi Steve, On 09/05/16 15:40, Stephen Kelly wrote: >> - (Stephen) "In reality, rewriting Qt's build system in CMake will >> actually be a PITA, and will require changes to CMake to make everything >> better" > > I think something was lost in transit on this point. I don’t think it would be a PITA to write a CMake buildsystem for Qt. I recall the above point was in reference to ‘compiling host tools and using them in the build while cross compiling’. The way CMake makes that possible currently(!) is implemented separately to the core of CMake with the ExternalProject module. > > You're right; I remember now that this was referring what you describe above, not the porting work in general. I actually found another quote from you in my notes saying "I'm not sure CMake would require a lot of effort for either CMake or Qt itself". Clearly, I need to work on my stenography... Thanks for the clarification! -- Andrew From kevin.kofler at chello.at Mon Sep 5 15:38:09 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 05 Sep 2016 15:38:09 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: Andrew Knight wrote: > - (Tobias) Cmake is the "worst" system in Qt Creator because CMake > doesn't give enough feedback to the IDE. We need first-class support for > CMake in Qt Creator, though, so that is irrelevant to the discussion of > which system we use to build Qt. Anything you can get into CMake to improve IDE support will also help KDevelop, and vice-versa. KDevelop dropped their own CMake parser in KDevelop 5 and now relies on the information CMake gives (using a dedicated query mode that was added mainly for KDevelop), they know about things missing there and want them added to CMake. > * Quick survey: which build system do you use (raise of hands by ~40 > people) > - CMake ~70% > - qmake ~20% > - Qbs ~10% That basically says it all. :-) > - (Milian) CMakeis used by e.g. clang and it works for them … and the whole stack of software from the KDE project, and other large projects. > - (Eddy) Why are we using this ancient tool? (Referring to make) You don't have to use make with CMake, CMake has other generator backends, e.g., a Ninja generator. And the really nice thing is, the developer of the application or library (Qt in this case) normally does not have to do anything to support them, it should just work (and make will still just work, too, for those who prefer using make). > - (Andreas) "Every big project ends up building their own system. Qbs is > a possibility to create a new build system. If it stays in the Qt > Project, less people will use it." The fact that many big projects (thankfully not all of them) reinvent their own square wheel is a bad thing, not something worth copying. This is a major annoyance when packaging. That said, what I have also seen in some projects is strange wrapper layers above CMake, with things like: * custom Find* files that work differently from the standard ones, * custom macros that do everything instead of standard commands, * undocumented hacked-on support for bundled libraries (with custom macros and custom Find* files) that makes it hard to unbundle them, * lack of support for important standard CMake variables, e.g., some broken CMakeLists setups use neither LIB_INSTALL_DIR nor LIB_SUFFIX. So using CMake is not always enough to avoid being a pain to package. But an entirely custom build system is always the worst. I don't see why one would need to do different just for the sake of doing different, it just makes us packagers' jobs harder (see e.g. Chromium's gyp and/or gn). Kevin Kofler From annulen at yandex.ru Mon Sep 5 15:52:09 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 05 Sep 2016 16:52:09 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: <229681473083529@web27g.yandex.ru> 05.09.2016, 16:38, "Kevin Kofler" : > Andrew Knight wrote: >>  - (Tobias) Cmake is the "worst" system in Qt Creator because CMake >>  doesn't give enough feedback to the IDE. We need first-class support for >>  CMake in Qt Creator, though, so that is irrelevant to the discussion of >>  which system we use to build Qt. > > Anything you can get into CMake to improve IDE support will also help > KDevelop, and vice-versa. KDevelop dropped their own CMake parser in > KDevelop 5 and now relies on the information CMake gives (using a dedicated > query mode that was added mainly for KDevelop), they know about things > missing there and want them added to CMake. > >>  * Quick survey: which build system do you use (raise of hands by ~40 >>  people) >>  - CMake ~70% >>  - qmake ~20% >>  - Qbs ~10% > > That basically says it all. :-) > >>  - (Milian) CMakeis used by e.g. clang and it works for them > > … and the whole stack of software from the KDE project, and other large > projects. > >>  - (Eddy) Why are we using this ancient tool? (Referring to make) > > You don't have to use make with CMake, CMake has other generator backends, > e.g., a Ninja generator. And the really nice thing is, the developer of the > application or library (Qt in this case) normally does not have to do > anything to support them, it should just work (and make will still just > work, too, for those who prefer using make). > >>  - (Andreas) "Every big project ends up building their own system. Qbs is >>  a possibility to create a new build system. If it stays in the Qt >>  Project, less people will use it." > > The fact that many big projects (thankfully not all of them) reinvent their > own square wheel is a bad thing, not something worth copying. This is a > major annoyance when packaging. Problem is that square wheel here is CMake. IMNSHO, it doesn't do _anything_ better than competition and it's only workable because of lots and lots of man-hours of pain and suffering, invested in its extension modules. > > That said, what I have also seen in some projects is strange wrapper layers > above CMake, with things like: > * custom Find* files that work differently from the standard ones, > * custom macros that do everything instead of standard commands, > * undocumented hacked-on support for bundled libraries (with custom macros >   and custom Find* files) that makes it hard to unbundle them, > * lack of support for important standard CMake variables, e.g., some broken >   CMakeLists setups use neither LIB_INSTALL_DIR nor LIB_SUFFIX. > So using CMake is not always enough to avoid being a pain to package. > > But an entirely custom build system is always the worst. I don't see why one > would need to do different just for the sake of doing different, it just > makes us packagers' jobs harder (see e.g. Chromium's gyp and/or gn). > >         Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From viktor.engelmann at qt.io Mon Sep 5 16:08:41 2016 From: viktor.engelmann at qt.io (Viktor Engelmann) Date: Mon, 5 Sep 2016 16:08:41 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: <8615812.gtAI1A4odG@tjmaciei-mobl1> References: <4296462.nTlXLaONEc@tjmaciei-mobl1> <201609022345.27053.marc.mutz@kdab.com> <8615812.gtAI1A4odG@tjmaciei-mobl1> Message-ID: <1660564d-62f2-c8e4-cc21-e488b7a36edf@qt.io> So what if the user adds an asm statement that changes a register and doesn't declare that register to be changed? That would also cause his "Qt" application to misbehave... or what if he links the object files to a custom loader that doesn't call the constructors for global objects? We can lock away OUR guns so the user can't shoot himself in the foot with them, but if he goes out and buys his own gun, there is nothing we can (or should) do about it. Just my 2 cents. Viktor Am 03.09.2016 um 09:03 schrieb Thiago Macieira: > Em sexta-feira, 2 de setembro de 2016, às 23:45:26 CEST, Marc Mutz escreveu: >> On Friday 02 September 2016 22:35:59 Thiago Macieira wrote: >>> However, the documentation from the ABI says that forced unwinds cannot be >>> stopped, so you can't swallow the exception even if you wanted to. Are you >>> sure that the application crashes when you pthread_exit() when >>> QThreadPrivate::start() is noexcept? >> Can't swallow doesn't mean can't catch. You can catch it, but you can't not >> rethrow. But if you call std::terminate(), the rethrow will never be >> reached. > But that doesn't do what we want. We want to rethrow the __forced_unwind > exception so that it terminates the thread, but not the entire application. > > But anyway, what I asked didn't work. Test app: > > #include > > void do_exit() noexcept > { > pthread_exit(nullptr); > } > > int dummy; > void *thread_function(void *) > { > do_exit(); > return &dummy; > } > > int main() > { > pthread_t thr; > void *retval; > pthread_create(&thr, nullptr, thread_function, nullptr); > pthread_join(thr, &retval); > return retval == nullptr ? 0 : 1; > } > > Crash backtrace: > #0 0x00007ffff6fa9975 in raise () from /lib64/libc.so.6 > #1 0x00007ffff6faad8a in abort () from /lib64/libc.so.6 > #2 0x00007ffff78ca6bd in __gnu_cxx::__verbose_terminate_handler() () from / > usr/lib64/libstdc++.so.6 > #3 0x00007ffff78c8696 in ?? () from /usr/lib64/libstdc++.so.6 > #4 0x00007ffff78c86e1 in std::terminate() () from /usr/lib64/libstdc++.so.6 > #5 0x00007ffff78c8314 in __gxx_personality_v0 () from /usr/lib64/libstdc+ > +.so.6 > #6 0x00007ffff73275a9 in ?? () from /lib64/libgcc_s.so.1 > #7 0x00007ffff7327904 in _Unwind_ForcedUnwind () from /lib64/libgcc_s.so.1 > #8 0x00007ffff7bcacb0 in __pthread_unwind () from /lib64/libpthread.so.0 > #9 0x00007ffff7bc3595 in pthread_exit () from /lib64/libpthread.so.0 > #10 0x0000000000400794 in do_exit() () > #11 0x00000000004007a5 in thread_function(void*) () > #12 0x00007ffff7bc2474 in start_thread () from /lib64/libpthread.so.0 > #13 0x00007ffff705d3ed in clone () from /lib64/libc.so.6 > > I'll post to cxxabi and ask that __forced_unwind be made public API. -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin Viktor.Engelmann at qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Qt World Summit 2016 Qt World Summit 2016 | Pier 27, San Francisco, CA Experience Exponential Potential on October 18-20 www.qtworldsummit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_logo_with_text_green_rgb_400x141.png Type: image/png Size: 16849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_facebook.png Type: image/png Size: 1407 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_twitter.png Type: image/png Size: 1778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_linkedin.png Type: image/png Size: 1532 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_googleplus.png Type: image/png Size: 1957 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_youtube.png Type: image/png Size: 1610 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qtworldsummit2016_banner.jpg Type: image/jpeg Size: 35183 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: viktor_engelmann.vcf Type: text/x-vcard Size: 271 bytes Desc: not available URL: From Jake.Petroules at qt.io Mon Sep 5 16:12:23 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 5 Sep 2016 14:12:23 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: On Sep 5, 2016, at 3:38 PM, Kevin Kofler > wrote: - (Milian) CMakeis used by e.g. clang and it works for them … and the whole stack of software from the KDE project, and other large projects. Keep in mind that "large projects use X, therefore X is great" is a poor argument, because large does not necessarily mean complex. Any build tool is good at handling a large project (including autotools), but few are good at handling complex ones. Moreover, because Y uses X and it works for Y, does not mean X works for Z. As an incredibly simple example, make is inherently limited in that it cannot even represent a rule with multiple outputs (there are some workarounds, but they are hacky and rather limited in how they can be applied). And ninja is no magic bullet here either, because that still represents a static build graph, whereas the content of Qbs' build graph can actually change during the execution of the build. Many of you seem to not understand how complex build tools can get and just how simple Qbs can make problems that are incredibly challenging in other systems. Perhaps you should actually try Qbs before complaining about it. Or perhaps we simply need more/better examples to show the community the difference between the Rolls-Royce Trent 900 jet engine that is CMake, and the wet firecrackers that are CMake and qmake. Perhaps both. :) No one WANTS to use CMake. They use it because they HAVE to, because it's the only thing that exists. Feel free to long for the "good old days" of the stone age, when food was scarce, disease was rampant, and life was short, but we will move forward towards a better future. -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Mon Sep 5 16:13:04 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 5 Sep 2016 14:13:04 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: <7661D5D7-9AFD-4274-BA82-17D932DFD72E@qt.io> On Sep 5, 2016, at 4:12 PM, Jake Petroules > wrote: On Sep 5, 2016, at 3:38 PM, Kevin Kofler > wrote: - (Milian) CMakeis used by e.g. clang and it works for them … and the whole stack of software from the KDE project, and other large projects. Keep in mind that "large projects use X, therefore X is great" is a poor argument, because large does not necessarily mean complex. Any build tool is good at handling a large project (including autotools), but few are good at handling complex ones. Moreover, because Y uses X and it works for Y, does not mean X works for Z. As an incredibly simple example, make is inherently limited in that it cannot even represent a rule with multiple outputs (there are some workarounds, but they are hacky and rather limited in how they can be applied). And ninja is no magic bullet here either, because that still represents a static build graph, whereas the content of Qbs' build graph can actually change during the execution of the build. Many of you seem to not understand how complex build tools can get and just how simple Qbs can make problems that are incredibly challenging in other systems. Perhaps you should actually try Qbs before complaining about it. Or perhaps we simply need more/better examples to show the community the difference between the Rolls-Royce Trent 900 jet engine that is Qbs, and the wet firecrackers that are CMake and qmake. Perhaps both. :) No one WANTS to use CMake. They use it because they HAVE to, because it's the only thing that exists. Feel free to long for the "good old days" of the stone age, when food was scarce, disease was rampant, and life was short, but we will move forward towards a better future. -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io s/CMake/Qbs/ Fail. -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From nassian at bitshift-dynamics.de Mon Sep 5 17:04:29 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Mon, 5 Sep 2016 17:04:29 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: References: Message-ID: Hi, Is, or should, that even be supported? I’m just wondering because when I’m using Qt to create a thread, I also use Qt to quit it. Why should anybody use a „foreign“ API? Beste Grüße / Best regards, Alexander Nassian > Am 02.09.2016 um 12:32 schrieb Giuseppe D'Angelo : > > Howdy, > > I'm trying to introduce a change [1] which will make QThread invoke > std::terminate in case an exception is thrown from the new thread > (including, but not limited to: user's reimplementation of QThread::run; > slots listening to the QThread::started / finished signals; custom event > dispatchers). > > The idea is to align ourselves to what std::thread does. > > There's a small catch, however: user code might be using platform-native > APIs such as pthread_exit(3) in order to make a QThread quit. > > On some implementations (notably: glibc), pthread_exit is implemented by > throwing an exception, because it needs to run the pushed cleanup > handlers. The net result is that, with my change applied, pthread_exit > won't make the thread exit but crash the application instead (!). > > The question for the ML is: is this a scenario Qt has ever officially > supported, and a scenario that we should support in the future? > > (QThread documentation does not talk about how QThread itself is > implemented, so actually relying on the that it has pthread semantics is > already a slight API abuse by the users). > > [1] https://codereview.qt-project.org/#/c/167240/ > > Cheers, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 > KDAB - The Qt Experts > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Mon Sep 5 18:38:11 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 5 Sep 2016 18:38:11 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: <1660564d-62f2-c8e4-cc21-e488b7a36edf@qt.io> References: <4296462.nTlXLaONEc@tjmaciei-mobl1> <201609022345.27053.marc.mutz@kdab.com> <8615812.gtAI1A4odG@tjmaciei-mobl1> <1660564d-62f2-c8e4-cc21-e488b7a36edf@qt.io> Message-ID: <32e9c903-f370-ba4c-386a-ce91788edf5c@kdab.com> Il 05/09/2016 16:08, Viktor Engelmann ha scritto: > We can lock away OUR guns so the user can't shoot himself in the foot > with them, but if he goes out and buys his own gun, there is nothing we > can (or should) do about it. That's not the point. The point is that every time we do an apparently innocuous change (maybe thinking "surely we never promised POSIX semantics for our threads!") it turns out that instead there are people out there that are relying on this behaviour (for whatever reason). We might have find a couple of workarounds [1][2] for this particular issue, so in the end the semantics for users are not going to change, but if the workarounds are not good enough and could not get accepted then user code is going to break, and that's why I was wondering 1) if we ever promised something about this issue, and 2) if there's any user publicly using the feature (I was planning to send an email to interest@ to run a poll about this). [1] Catch __cxxabiv1::__forced_unwind, as documented here: > https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html which is what libstdc++'s std::thread also does: > https://code.woboq.org/gcc/libstdc++-v3/src/c++11/thread.cc.html#execute_native_thread_routine (but not libc++, wonder why). [2] Rely on std::current_exception() to return a null std::exception_ptr in a catch(...) block (!), to represent the fact that there's no exception but it's a forced stack unwind. Cf. the thread at: > http://sourcerytools.com/pipermail/cxx-abi-dev/2016-September/002956.html -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From nassian at bitshift-dynamics.de Mon Sep 5 18:46:04 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Mon, 5 Sep 2016 18:46:04 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: <32e9c903-f370-ba4c-386a-ce91788edf5c@kdab.com> References: <4296462.nTlXLaONEc@tjmaciei-mobl1> <201609022345.27053.marc.mutz@kdab.com> <8615812.gtAI1A4odG@tjmaciei-mobl1> <1660564d-62f2-c8e4-cc21-e488b7a36edf@qt.io> <32e9c903-f370-ba4c-386a-ce91788edf5c@kdab.com> Message-ID: <8994DAE1-1005-4857-AD78-E180404BD362@bitshift-dynamics.de> > Am 05.09.2016 um 18:38 schrieb Giuseppe D'Angelo : > > Il 05/09/2016 16:08, Viktor Engelmann ha scritto: >> We can lock away OUR guns so the user can't shoot himself in the foot >> with them, but if he goes out and buys his own gun, there is nothing we >> can (or should) do about it. > > That's not the point. The point is that every time we do an apparently > innocuous change (maybe thinking "surely we never promised POSIX > semantics for our threads!") it turns out that instead there are people > out there that are relying on this behaviour (for whatever reason). Please don’t get me wrong, but that would imply that if enough people (for whatever reason) expect eg. QSettings to be compatible with WinAPI calls that should be changed. If I’m not wrong QThread doesn’t event expose the native handle in a reliable way, so why should Qt support API abuse by the user? Beste Grüße / Best regards, Alexander Nassian From giuseppe.dangelo at kdab.com Mon Sep 5 18:46:41 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 5 Sep 2016 18:46:41 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: References: Message-ID: <6655bd4e-2e64-eeef-e594-1ee2f1bb0bfa@kdab.com> Il 05/09/2016 17:04, Alexander Nassian ha scritto: > Is, or should, that even be supported? I’m just wondering because when > I’m using Qt to create a thread, I also use Qt to quit it. Why should > anybody use a „foreign“ API? Maybe one is just using a 3rd party library that assumes pthreads, not Qt. Again, this is not the point, the point is that this used to work (users relying on undocumented behaviour) and I was about to break that behaviour. I wanted consensus before proceeding. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From marc.mutz at kdab.com Mon Sep 5 18:54:25 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 5 Sep 2016 18:54:25 +0200 Subject: [Development] [FYI] on gerrit change retargeting requests In-Reply-To: <20160831141255.GG2429@troll08> References: <20160831141255.GG2429@troll08> Message-ID: <201609051854.25469.marc.mutz@kdab.com> On Wednesday 31 August 2016 16:12:55 Oswald Buddenhagen wrote: > with the upcoming qtcon and my subsequent vacation, my availability will > be rather sporadic, so consider this: > - i'm not going to do reviews on a regular basis, so it's unwise to just > add me to them and expect a reaction. send me a direct mail. > - this recommendation actually applies irrespective of current plans - > sometimes i actually want to get some work done instead of just doing > reviews. ;) > - you can also ask frederik gladhorn (fregl) > > generally speaking, send a complete list of change urls, as we can just > paste that into the script which performs the operation. that's also the > reason why a single mail (or irc messsage) instead of adding us to n > reviews is always preferred. please don't give verbal descriptions of > ranges - somebody has to do the click and paste orgy anyway, and that > should be you. ;) And please, pretty please, don't _abandon_ changes and resubmit them to a different branch. _Do_ ask Ossi or Frederik to re-target on the server, _esp_ if you've already run into half a dozen revisions. Submitting a new change without the ability to use inter-change diffs is just rude towards the reviewers. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From giuseppe.dangelo at kdab.com Mon Sep 5 19:00:40 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 5 Sep 2016 19:00:40 +0200 Subject: [Development] Notes on QtCore session @ QCS2016 In-Reply-To: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> Message-ID: Random comments: Il 02/09/2016 17:01, Thiago Macieira ha scritto: > https://wiki.qt.io/QtCS2016_QtCore > > * Deprecation of APIs > * qrand/qsrand -> replacement is Standard Library or your own Unfortunately there's no replacement for a thread safe, easy to use, deterministic, low quality random number generator. std::rand is not thread safe and the whole random API is not exactly user friendly... > * QStringView & QByteArrayView > * Deprecate QStringRef > * Not QArrayView: discuss later IOW: the views will have the full blown QByteArray/QString API on them? > * allocator for QObject > * custom operator new() > * might conflict with combined moc space savings > * which conflicts with includemoc for Clang warnings It would be interesting to know how all the problems with custom operator new()s have been solved by this approach (for instance, how does this handle objects created in one shared object and destroyed in another?) > * Metaobject improvements for QML > * make separate session > * Animation framework, item models & statemachine > * Move out of QtCore in Qt 6 > * MIME type too? > * C++11 Standard Library compatibility list > * no volunteers yet Is this a matter of converting this documented into qdoc? https://codereview.qt-project.org/#/c/142782/ > * C++ ABI > * libstdc++ still breaking compatibility in std::function > * not now, revisit in a year or two There hasn't been time to discuss this at QtCon, but I'd say we should not spend another year before revisiting this at the next QtCS: do we really care about C++ ABI compatibility? What other C++ libraries are doing this? Do users really expect to swap out standard library implementations without the need of recompiling libraries and applications that use them? Or is it an artificial problem we're imposing on ourselves? Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From jpnurmi at qt.io Mon Sep 5 19:20:29 2016 From: jpnurmi at qt.io (J-P Nurmi) Date: Mon, 5 Sep 2016 17:20:29 +0000 Subject: [Development] [FYI] on gerrit change retargeting requests In-Reply-To: <201609051854.25469.marc.mutz@kdab.com> References: <20160831141255.GG2429@troll08>, <201609051854.25469.marc.mutz@kdab.com> Message-ID: > On 05 Sep 2016, at 18:53, Marc Mutz wrote: > >> On Wednesday 31 August 2016 16:12:55 Oswald Buddenhagen wrote: >> with the upcoming qtcon and my subsequent vacation, my availability will >> be rather sporadic, so consider this: >> - i'm not going to do reviews on a regular basis, so it's unwise to just >> add me to them and expect a reaction. send me a direct mail. >> - this recommendation actually applies irrespective of current plans - >> sometimes i actually want to get some work done instead of just doing >> reviews. ;) >> - you can also ask frederik gladhorn (fregl) >> >> generally speaking, send a complete list of change urls, as we can just >> paste that into the script which performs the operation. that's also the >> reason why a single mail (or irc messsage) instead of adding us to n >> reviews is always preferred. please don't give verbal descriptions of >> ranges - somebody has to do the click and paste orgy anyway, and that >> should be you. ;) > > And please, pretty please, don't _abandon_ changes and resubmit them to a > different branch. _Do_ ask Ossi or Frederik to re-target on the server, _esp_ > if you've already run into half a dozen revisions. Submitting a new change > without the ability to use inter-change diffs is just rude towards the > reviewers. Let us move our own changes. If you're worried about abuse, downgrade any +2 to +1 on branch change. Problem solved. -- J-P Nurmi From marc.mutz at kdab.com Mon Sep 5 19:29:30 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 5 Sep 2016 19:29:30 +0200 Subject: [Development] [FYI] on gerrit change retargeting requests In-Reply-To: References: <20160831141255.GG2429@troll08> <201609051854.25469.marc.mutz@kdab.com> Message-ID: <201609051929.30738.marc.mutz@kdab.com> On Monday 05 September 2016 19:20:29 J-P Nurmi wrote: > > On 05 Sep 2016, at 18:53, Marc Mutz wrote: > >> On Wednesday 31 August 2016 16:12:55 Oswald Buddenhagen wrote: > >> with the upcoming qtcon and my subsequent vacation, my availability will > >> be rather sporadic, so consider this: > >> - i'm not going to do reviews on a regular basis, so it's unwise to just > >> > >> add me to them and expect a reaction. send me a direct mail. > >> - this recommendation actually applies irrespective of current plans - > >> > >> sometimes i actually want to get some work done instead of just doing > >> reviews. ;) > >> > >> - you can also ask frederik gladhorn (fregl) > >> > >> generally speaking, send a complete list of change urls, as we can just > >> paste that into the script which performs the operation. that's also the > >> reason why a single mail (or irc messsage) instead of adding us to n > >> reviews is always preferred. please don't give verbal descriptions of > >> ranges - somebody has to do the click and paste orgy anyway, and that > >> should be you. ;) > > > > And please, pretty please, don't _abandon_ changes and resubmit them to a > > different branch. _Do_ ask Ossi or Frederik to re-target on the server, > > _esp_ if you've already run into half a dozen revisions. Submitting a > > new change without the ability to use inter-change diffs is just rude > > towards the reviewers. > > Let us move our own changes. If you're worried about abuse, downgrade any > +2 to +1 on branch change. Problem solved. It's not about restricting what a user can do. It's simply missing implementation, and I believe that if it were easy to implement, Ossi would have done it long ago instead of playing retarget-monkey for the rest of us :) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Mon Sep 5 19:35:28 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 5 Sep 2016 19:35:28 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: <8615812.gtAI1A4odG@tjmaciei-mobl1> References: <201609022345.27053.marc.mutz@kdab.com> <8615812.gtAI1A4odG@tjmaciei-mobl1> Message-ID: <201609051935.28397.marc.mutz@kdab.com> On Saturday 03 September 2016 09:03:21 Thiago Macieira wrote: > > Can't swallow doesn't mean can't catch. You can catch it, but you can't > > not rethrow. But if you call std::terminate(), the rethrow will never be > > reached. > > But that doesn't do what we want. We want to rethrow the __forced_unwind > exception so that it terminates the thread, but not the entire application. I was referring to the original implementation which did catch (...) { std::reminate(); // forced rethrow of a __forced_unwind is never reached } making an explicit catch block for __forced_unwind necessary to avoid the call to std::terminate(). HTCTU, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From sahumada at texla.cl Mon Sep 5 19:34:57 2016 From: sahumada at texla.cl (Sergio Ahumada) Date: Mon, 5 Sep 2016 19:34:57 +0200 Subject: [Development] [FYI] on gerrit change retargeting requests In-Reply-To: <201609051929.30738.marc.mutz@kdab.com> References: <20160831141255.GG2429@troll08> <201609051854.25469.marc.mutz@kdab.com> <201609051929.30738.marc.mutz@kdab.com> Message-ID: <6b1a38c0-fcbe-b1d5-ad72-d2326d4d6fa3@texla.cl> On 05.09.2016 19:29, Marc Mutz wrote: > On Monday 05 September 2016 19:20:29 J-P Nurmi wrote: >>> On 05 Sep 2016, at 18:53, Marc Mutz wrote: >>>> On Wednesday 31 August 2016 16:12:55 Oswald Buddenhagen wrote: >>>> with the upcoming qtcon and my subsequent vacation, my availability will >>>> be rather sporadic, so consider this: >>>> - i'm not going to do reviews on a regular basis, so it's unwise to just >>>> >>>> add me to them and expect a reaction. send me a direct mail. >>>> - this recommendation actually applies irrespective of current plans - >>>> >>>> sometimes i actually want to get some work done instead of just doing >>>> reviews. ;) >>>> >>>> - you can also ask frederik gladhorn (fregl) >>>> >>>> generally speaking, send a complete list of change urls, as we can just >>>> paste that into the script which performs the operation. that's also the >>>> reason why a single mail (or irc messsage) instead of adding us to n >>>> reviews is always preferred. please don't give verbal descriptions of >>>> ranges - somebody has to do the click and paste orgy anyway, and that >>>> should be you. ;) >>> >>> And please, pretty please, don't _abandon_ changes and resubmit them to a >>> different branch. _Do_ ask Ossi or Frederik to re-target on the server, >>> _esp_ if you've already run into half a dozen revisions. Submitting a >>> new change without the ability to use inter-change diffs is just rude >>> towards the reviewers. >> >> Let us move our own changes. If you're worried about abuse, downgrade any >> +2 to +1 on branch change. Problem solved. > > It's not about restricting what a user can do. It's simply missing > implementation, and I believe that if it were easy to implement, Ossi would > have done it long ago instead of playing retarget-monkey for the rest of us :) > > Thanks, > Marc > https://bugreports.qt.io/browse/QTQAINFRA-268 https://bugs.chromium.org/p/gerrit/issues/detail?id=117 -- Sergio Ahumada sahumada at texla.cl From marc.mutz at kdab.com Mon Sep 5 19:41:28 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 5 Sep 2016 19:41:28 +0200 Subject: [Development] Notes on QtCore session @ QCS2016 In-Reply-To: References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> Message-ID: <201609051941.29079.marc.mutz@kdab.com> On Monday 05 September 2016 19:00:40 Giuseppe D'Angelo wrote: > > * QStringView & QByteArrayView > > > > * Deprecate QStringRef > > * Not QArrayView: discuss later > > IOW: the views will have the full blown QByteArray/QString API on them? The const subset, yes, minus deprecated API, if any. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From milian.wolff at kdab.com Mon Sep 5 20:49:13 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Mon, 05 Sep 2016 20:49:13 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: <1611603.8B8jhCL7eK@agathebauer> On Montag, 5. September 2016 14:12:23 CEST Jake Petroules wrote: > On Sep 5, 2016, at 3:38 PM, Kevin Kofler > > wrote: > - (Milian) CMakeis used by e.g. clang and it works for them > > … and the whole stack of software from the KDE project, and other large > projects. > > Keep in mind that "large projects use X, therefore X is great" is a poor > argument, because large does not necessarily mean complex. Any build tool > is good at handling a large project (including autotools), but few are good > at handling complex ones. Moreover, because Y uses X and it works for Y, > does not mean X works for Z. Currently we only know that QBS can be used for Creator, which is, quite frankly, far from the complexity of LLVM, all of the KDE stuff, as well as WebKit and the tons of other big projects that use CMake... > As an incredibly simple example, make is inherently limited in that it > cannot even represent a rule with multiple outputs (there are some > workarounds, but they are hacky and rather limited in how they can be > applied). And ninja is no magic bullet here either, because that still > represents a static build graph, whereas the content of Qbs' build graph > can actually change during the execution of the build. Can you give an example for why we should care? This may sound flame-baity, but I'm really truly interested. I simply don't care about my build system, as long as it gets the job done without too much hassle (and yes, that is the case for me personally with cmake), and fast, too (which is the case with ninja). See also below. > Many of you seem to not understand how complex build tools can get and just > how simple Qbs can make problems that are incredibly challenging in other > systems. Perhaps you should actually try Qbs before complaining about it. > Or perhaps we simply need more/better examples to show the community the > difference between the Rolls-Royce Trent 900 jet engine that is CMake, and > the wet firecrackers that are CMake and qmake. Perhaps both. :) Sure, that can be the case. But do you really think that everyone will rewrite their working CMake buildsystem in QBS just for the sake of it? What advantages does it have that would make such an effort worth it? Also, do note that many people outside the Qt company simply don't get why such an effort is put into reinventing a build system, when we are in short supply of developers in other areas, which are arguably more important to keep Qt relevant. Kai mentioned competing against other languages, I wonder why one needs to compete against them. If Qt had proper language bindings, it would be used far more often... > No one WANTS to use CMake. They use it because they HAVE to, because it's > the only thing that exists.. I agree. But with the many years I've worked with CMake, I don't get it either why so many people become so passionate at hating it. Thanks to the new features in CMake 3 most notably, it's pretty easy to use. > Feel free to long for the "good old days" of > the stone age, when food was scarce, disease was rampant, and life was > short, but we will move forward towards a better future That is completely besides the point. Bye -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From milian.wolff at kdab.com Mon Sep 5 21:20:12 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Mon, 05 Sep 2016 21:20:12 +0200 Subject: [Development] A faster qUtf8Printable for static trace points? Message-ID: <1757662.KxShe8fSTD@agathebauer> Hey Thiago, others. I plan to work on adding static trace points to Qt in the next months, i.e. find an abstraction that works with DTrace/SystemTap UDST/xperf as well as custom trace point APIs that are sometimes used in the automotive sector e.g. One thing that I noticed already is that often the existing consumers for trace files expect UTF8 string parameters for tracepoints. Now in Qt we usually deal with stuff like: bool QLibraryPrivate::load() { ... TraceScope<...> ts(qUtf8Printable(fileName)) ... } Trace points have nearly zero runtime overhead when not used [1]. But the above has a super high cost due to calling QString::toUtf8, which constructs a temporary QByteArray and thus incurs a temporary runtime allocation. An alternative would be to use qUtf16Printable, which would be fast, but I fear it makes interoperability with existing trace point consumers hard. Can someone with experience on trace points confirm this assertion? If that is untrue, simply using qUtf16Printable above would make everything work, and be fast. One way to handle the above case would be only doing the qUtf8Printable call when the trace point is enabled, but afaik that checking also is not done for free, and also makes the consumer code harder to write. I thought, what about improving qUtf8Printable instead. I.e. something along the lines of: https://github.com/milianw/bench_qt/blob/master/bench_qstring/ bench_qstring.cpp#L118 Would something like this be acceptable for upstream? E.g. change qUtf8Printable to not allocate memory for up to PATH_MAX chars or similar, and otherwise fallback to the slow QByteArray (or simply truncate, which would be an option for trace points actually). From my POV, the way qPrintable & friends are used right now, the above would be "safe". And it's much faster: RESULT : BenchQString::benchQUtf8Printable(): 0.00014 msecs per iteration (total: 74, iterations: 524288) RESULT : BenchQString::benchQFastUtf8Printable_QUtf8Functions(): 0.000049 msecs per iteration (total: 52, iterations: 1048576) RESULT : BenchQString::benchQUtf8Printable(): 450.764625 CPU cycles per iteration (total: 450,764,625, iterations: 1000000) RESULT : BenchQString::benchQFastUtf8Printable_QUtf8Functions(): 161.244798 CPU cycles per iteration (total: 161,244,798, iterations: 1000000) RESULT : BenchQString::benchQUtf8Printable(): 1,023.400176 instructions per iteration (total: 1,023,400,177, iterations: 1000000) RESULT : BenchQString::benchQFastUtf8Printable_QUtf8Functions(): 432.060962 instructions per iteration (total: 432,060,962, iterations: 1000000) Thanks, any input welcome. [1]: one nop - see http://tromey.com/blog/?p=687 -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From frank.meerkoetter at basyskom.com Mon Sep 5 22:14:40 2016 From: frank.meerkoetter at basyskom.com (Frank =?ISO-8859-1?Q?Meerk=F6tter?=) Date: Mon, 05 Sep 2016 22:14:40 +0200 Subject: [Development] Qt 5.8.0 Alpha released In-Reply-To: References: Message-ID: <14901251.JuPyhLmGyB@naos> On Monday 05 September 2016 09:47:45 Jani Heikkinen wrote: Hi Jani, > We have released Qt 5.8.0 Alpha, see http://blog.qt.io/blog/2016/09/05/qt-5-8-alpha-released/ > > At this time we managed to release it almost as planned, big thanks everyone involved! It would be great if alpha/beta releases would also be available through the meta-boot2qt layer. It would allow to gather (more) early feedback from users of embedded linux platforms. Regards, Frank -- Frank Meerkötter Development Lead basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel : +49 6151 870 589 161 | Fax: +49 6151 - 870 589 162 frank.meerkoetter at basyskom.com | www.basyskom.com Handelsregister: Darmstadt HRB 9352 Geschäftsführung: Eva Brucherseifer, Heike Ziegler From jpnurmi at qt.io Mon Sep 5 23:17:59 2016 From: jpnurmi at qt.io (J-P Nurmi) Date: Mon, 5 Sep 2016 21:17:59 +0000 Subject: [Development] [FYI] on gerrit change retargeting requests In-Reply-To: <201609051929.30738.marc.mutz@kdab.com> References: <20160831141255.GG2429@troll08> <201609051854.25469.marc.mutz@kdab.com> , <201609051929.30738.marc.mutz@kdab.com> Message-ID: <04C718D5-89D8-496E-AA6A-6118CC41839B@qt.io> > On 05 Sep 2016, at 19:27, Marc Mutz wrote: > > On Monday 05 September 2016 19:20:29 J-P Nurmi wrote: >>>> On 05 Sep 2016, at 18:53, Marc Mutz wrote: >>>> On Wednesday 31 August 2016 16:12:55 Oswald Buddenhagen wrote: >>>> with the upcoming qtcon and my subsequent vacation, my availability will >>>> be rather sporadic, so consider this: >>>> - i'm not going to do reviews on a regular basis, so it's unwise to just >>>> >>>> add me to them and expect a reaction. send me a direct mail. >>>> - this recommendation actually applies irrespective of current plans - >>>> >>>> sometimes i actually want to get some work done instead of just doing >>>> reviews. ;) >>>> >>>> - you can also ask frederik gladhorn (fregl) >>>> >>>> generally speaking, send a complete list of change urls, as we can just >>>> paste that into the script which performs the operation. that's also the >>>> reason why a single mail (or irc messsage) instead of adding us to n >>>> reviews is always preferred. please don't give verbal descriptions of >>>> ranges - somebody has to do the click and paste orgy anyway, and that >>>> should be you. ;) >>> >>> And please, pretty please, don't _abandon_ changes and resubmit them to a >>> different branch. _Do_ ask Ossi or Frederik to re-target on the server, >>> _esp_ if you've already run into half a dozen revisions. Submitting a >>> new change without the ability to use inter-change diffs is just rude >>> towards the reviewers. >> >> Let us move our own changes. If you're worried about abuse, downgrade any >> +2 to +1 on branch change. Problem solved. > > It's not about restricting what a user can do. It's simply missing > implementation, and I believe that if it were easy to implement, Ossi would > have done it long ago instead of playing retarget-monkey for the rest of us :) Doing it through the web UI would be a nice bonus, but having access to the same script that is already used by the admins would be good enough for starters. -- J-P Nurmi From nospam at vuorela.dk Mon Sep 5 23:33:02 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Mon, 5 Sep 2016 21:33:02 +0000 (UTC) Subject: [Development] Notes on QtCore session @ QCS2016 References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> Message-ID: On 2016-09-05, Giuseppe D'Angelo wrote: >> * C++ ABI >> * libstdc++ still breaking compatibility in std::function >> * not now, revisit in a year or two > > There hasn't been time to discuss this at QtCon, but I'd say we should > not spend another year before revisiting this at the next QtCS: do we > really care about C++ ABI compatibility? What other C++ libraries are > doing this? Do users really expect to swap out standard library one of the problems is that libstdc++ broke the abi between 4.9 and 5.0 for std::function without any compatibility things like for the other ones, because c++11 was only "experimental" until then. And I think that std::function is maybe the primary candidate for a thing we want to use. /Sune From thiago.macieira at intel.com Tue Sep 6 01:44:32 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 05 Sep 2016 16:44:32 -0700 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: <1660564d-62f2-c8e4-cc21-e488b7a36edf@qt.io> References: <8615812.gtAI1A4odG@tjmaciei-mobl1> <1660564d-62f2-c8e4-cc21-e488b7a36edf@qt.io> Message-ID: <2633012.tF69sBFDdv@tjmaciei-mobl1> Em segunda-feira, 5 de setembro de 2016, às 16:08:41 PDT, Viktor Engelmann escreveu: > So what if the user adds an asm statement that changes a register and > doesn't declare that register to be changed? That would also cause his > "Qt" application to misbehave... or what if he links the object files to > a custom loader that doesn't call the constructors for global objects? If you insert an asm statement that changes a register and you don't inform GCC that you changed it, then your application is buggy and it deserves to crash. In fact, you should HOPE it crashes cleanly, before it corrupts any user data. Still, what does that have to do with the problem at hand? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 6 01:53:44 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 05 Sep 2016 16:53:44 -0700 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: <6655bd4e-2e64-eeef-e594-1ee2f1bb0bfa@kdab.com> References: <6655bd4e-2e64-eeef-e594-1ee2f1bb0bfa@kdab.com> Message-ID: <1646549.IAZmiGRs2o@tjmaciei-mobl1> Em segunda-feira, 5 de setembro de 2016, às 18:46:41 PDT, Giuseppe D'Angelo escreveu: > Il 05/09/2016 17:04, Alexander Nassian ha scritto: > > Is, or should, that even be supported? I’m just wondering because when > > I’m using Qt to create a thread, I also use Qt to quit it. Why should > > anybody use a „foreign“ API? > > Maybe one is just using a 3rd party library that assumes pthreads, not Qt. > > Again, this is not the point, the point is that this used to work (users > relying on undocumented behaviour) and I was about to break that > behaviour. I wanted consensus before proceeding. Note one more wrinkle in this: we never promised that pthread_exit(), in specific, would work. However, the fact that QThreadPrivate::finish is run by way of a cleanup function is indicative that someone in the past tried and QThread was changed to support cancellation. It's more likely that it was inserted so that QThread::terminate would emit the termination signals. Which in turn brings about *another* wrinkle: if we don't add the workaround, thr->terminate() will terminate the entire application. That's not acceptable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 6 01:48:05 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 05 Sep 2016 16:48:05 -0700 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: <8994DAE1-1005-4857-AD78-E180404BD362@bitshift-dynamics.de> References: <32e9c903-f370-ba4c-386a-ce91788edf5c@kdab.com> <8994DAE1-1005-4857-AD78-E180404BD362@bitshift-dynamics.de> Message-ID: <5013052.5OLHtnUZOH@tjmaciei-mobl1> Em segunda-feira, 5 de setembro de 2016, às 18:46:04 PDT, Alexander Nassian escreveu: > Please don’t get me wrong, but that would imply that if enough people (for > whatever reason) expect eg. QSettings to be compatible with WinAPI calls > that should be changed. If I’m not wrong QThread doesn’t event expose the > native handle in a reliable way, so why should Qt support API abuse by the > user? That's exactly our position: we've never promised it and, unlike std::thread, we do not expose the native handle. And yet the native handle is trivially easy to get from inside the thread (call pthread_self()) and pthread_exit() doesn't even require the handle. So it's entirely within the realm of possibility that people expect POSIX semantics to apply. We're wondering how much we have to strive to keep that compatibility we had never promised. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 6 02:02:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 05 Sep 2016 17:02:50 -0700 Subject: [Development] Notes on QtCore session @ QCS2016 In-Reply-To: References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> Message-ID: <245522471.MNfLxLEXRv@tjmaciei-mobl1> Em segunda-feira, 5 de setembro de 2016, às 19:00:40 PDT, Giuseppe D'Angelo escreveu: > Random comments: > > Il 02/09/2016 17:01, Thiago Macieira ha scritto: > > https://wiki.qt.io/QtCS2016_QtCore > > > > * Deprecation of APIs > > > > * qrand/qsrand -> replacement is Standard Library or your own > > Unfortunately there's no replacement for a thread safe, easy to use, > deterministic, low quality random number generator. std::rand is not > thread safe and the whole random API is not exactly user friendly... I don't think we care enough about providing a low-quality generator. The discussion we had was about high-quality ones, possibly FIPS certified. You're right the std:: API is not user-friendly. In fact, it's plainly user- hostile, requiring multiple template arguments, creating objects that should only be used with auto, and has a major problem with properly seeding the entropy in certain scenarios. Still, the conclusion of the discussion is that we don't to write a wrapper API. We should get the high-quality generator and that should suffice for everyone. > > * QStringView & QByteArrayView > > > > * Deprecate QStringRef > > * Not QArrayView: discuss later > > IOW: the views will have the full blown QByteArray/QString API on them? Like Marc said. > > * allocator for QObject > > > > * custom operator new() > > * might conflict with combined moc space savings > > > > * which conflicts with includemoc for Clang warnings > > It would be interesting to know how all the problems with custom > operator new()s have been solved by this approach (for instance, how > does this handle objects created in one shared object and destroyed in > another?) No such problem exists in the first place. It can only happen if you're mixing MSVC runtimes, which is not supported. > > * C++11 Standard Library compatibility list > > > > * no volunteers yet > > Is this a matter of converting this documented into qdoc? > > https://codereview.qt-project.org/#/c/142782/ We decided to make a QUIP out of this, in a later session. Stay tuned. > > * C++ ABI > > > > * libstdc++ still breaking compatibility in std::function > > * not now, revisit in a year or two > > There hasn't been time to discuss this at QtCon, but I'd say we should > not spend another year before revisiting this at the next QtCS: do we > really care about C++ ABI compatibility? What other C++ libraries are > doing this? Do users really expect to swap out standard library > implementations without the need of recompiling libraries and > applications that use them? Or is it an artificial problem we're > imposing on ourselves? I think there was enough time to discuss it, we did discuss it, and we concluded that it's still important enough that we don't want to depend on the ABI right now. In fact, given that libstdc++ is breaking ABI across its own versions, it's not even a problem of libstdc++ vc libc++ compatibility (which is also still broken in all Linux distros I've seen).. The "a year or two" revisit is to check how relevant the breakages that we are currently aware of are, at that time. If they are safely in the past and don't affect much, and if GCC folks have stopped playing with the voltage in the power switches, we can reconsider. PS: QCS discussions are proposals. They become decisions once the ML agrees on it. PPS: those decisions will be documented as QUIPs. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 6 02:08:52 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 05 Sep 2016 17:08:52 -0700 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: <1971855.9lgUZeMv02@tjmaciei-mobl1> Em segunda-feira, 5 de setembro de 2016, às 12:49:03 PDT, Andrew Knight escreveu: > ** General sentiment: > - As long as Qbs looks like a part of Qt, it is perceived as a Qt > product, and is less attractive to external users. > - Yet, there remains a conflict: "if Qt doesn't use it, I don't want to > use it" vs. "if it's not outside of Qt, I don't want to use it" Sounds like the way to go for qbs is to decouple it, make it a separate project, one that doesn't release in lockstep with Qt. That puts an extra burden in Qbs development: it has to be ahead of Qt's own development by at least two releases. Building a library should not require a change in the buildsystem tool: the tool should already support it by the time we get to that problem. That's unlike qmake, for which we make changes as we need them in Qt. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 6 02:21:21 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 05 Sep 2016 17:21:21 -0700 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: <5418330.Fkj3B2dbl8@tjmaciei-mobl1> Em segunda-feira, 5 de setembro de 2016, às 14:12:23 PDT, Jake Petroules escreveu: > Many of you seem to not understand how complex build tools can get and just > how simple Qbs can make problems that are incredibly challenging in other > systems. Perhaps you should actually try Qbs before complaining about it. > Or perhaps we simply need more/better examples to show the community the > difference between the Rolls-Royce Trent 900 jet engine that is CMake, and > the wet firecrackers that are CMake and qmake. Perhaps both. :) I'm interested in seeing that. Please port one of the complex KF5 libraries to qbs. One that has dozens of configuration decisions and dependencies, both mandatory and optional, few of which can be detected with pkg-config. Then we can compare a real-world case of CMake vs qbs. Qt Creator is not a good example, because it has exactly one external dependency (the LLVM libs) and it barely tries to detect it. You have to inform the build with qmake that LLVM is available. Botan is included as a bundled 3rdparty, instead of being detected, etc. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 6 02:13:18 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 05 Sep 2016 17:13:18 -0700 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <98F2D36D-A065-4427-82C8-311E529F54E2@ableton.com> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <98F2D36D-A065-4427-82C8-311E529F54E2@ableton.com> Message-ID: <12176995.VH8TqLCkKB@tjmaciei-mobl1> Em segunda-feira, 5 de setembro de 2016, às 12:40:54 PDT, Stephen Kelly via Development escreveu: > I think something was lost in transit on this point. I don’t think it would > be a PITA to write a CMake buildsystem for Qt. I recall the above point was > in reference to ‘compiling host tools and using them in the build while > cross compiling’. The way CMake makes that possible currently(!) is > implemented separately to the core of CMake with the ExternalProject > module. That's how it should be. Every single project out there, except for Qt and possibly GCC itself, builds for one single target. Building something for one architecture so that it can be run to build another is ungainly and unexpected. Whenever you cross-compile Qt, you end up with tools that can only be run on the host. So Qt's cross-compilation mechanism can't be used to build tools that can be run on the target platform. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chgans at gna.org Tue Sep 6 03:36:26 2016 From: chgans at gna.org (Ch'Gans) Date: Tue, 6 Sep 2016 13:36:26 +1200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: On 5 September 2016 at 23:08, NIkolai Marchenko wrote: > Been using QBS for the last 6 months, transformed all projects to it(from > qmake). Never looked back. > It just clicks for me. Most everything seems logical (if poorly explained) > when you understand how to do it. I have switched quite a few projects from qmake to Qbs, and me too I never looked back! QtCreator has decent support for Qbs (could be improved tho, qmake support could be improved too and same goes with CMake) I never wanted to use CMake b/c for me it look like a gross hack (Reminds me of GNU M4). Qbs has been designed from the ground up to tackle build management, and it does it very well in a very elegant and efficient way. Qbs is a radical change compared to the usual Makefile-generator approach. Qbs relies on Qt, Qt declarative and Qt JS, which brings a work horse CMake cannot even dream of. I would compare CMake and Qbs, the same way Linus Torvald compares SVN and Git: SVN claims to be CVS but better => Epic fail, Git has been designed to address devs need using a new and efficient approach. I've recently contributed to Qbs (with great help from Jake and Christian), and I've been amazed how easy, simple and straight-forward the job was. We're talking 500 lines of raw source code (inc blanks, comments, autotests, qbs&qmake files, ...) to add a Clang Database generator to Qbs! This was that easy because of Qbs architecture but Qt did help a lot too, generating a JSON Db with Qt was a piece of cake. I know that lot of project use CMake, but as someone noted, projects use CMake because they have to, not because they want too. What are the other cross-platform choices? Autotools, hand-crafted Makefiles, Scons, Maven, ... Quite some years ago I was a happy GNU autotools user. Yes I was happy with it! Why? b/c I didn't have choice back at that time. Now, each time I have to hack an autotools-based project, I want to wash my hands 200 times in a raw, yuck! > One thing QBS needs is better documentation, because a lot of things that > are "obvious" to Christian Kandeler and Jake Petroules (sorry if misspeled) > are not ever mentioned in the docs or are in obscure places. > Using QBS effectively is literally impossible without knowledge of > freenode:#qt-qbs Yeah, sort of true. I've learned Qbs by looking at Qbs's own qbs files and QtCreator's ones too. And of course the documentation, which is "just" good enough to get started. It didn't take long to get my projects ported. I now have a easy-to-read, easy-to-understand, easy-to-extend cross-platform build, test and packaging (inc. installer) system. Bye bye qmake! Makefiles are out-dated (no punt intended) and so is CMake and any other Makefile-based tools. Makefiles are dead! CMake is ill! (Friendly, easy and provocative argument) Long live Qbs! My 2 cents, Chris > > On Mon, Sep 5, 2016 at 1:27 PM, Sune Vuorela wrote: >> >> On 2016-09-05, Andrew Knight wrote: >> > tl;dr: Lots of discussion on the merits of which build system (CMake, >> > Qbs) should replace qmake in building Qt; lots of supporters of CMake >> > but no volunteers to do the work, many reasons to use Qbs as well. Some >> >> I do think that there is volunteers to get Qt building with cmake if >> there is a likly chance of getting it accepted. I think I also >> commmunicated that at the session. >> >> /Sune >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From chgans at gna.org Tue Sep 6 03:40:40 2016 From: chgans at gna.org (Ch'Gans) Date: Tue, 6 Sep 2016 13:40:40 +1200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <229681473083529@web27g.yandex.ru> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <229681473083529@web27g.yandex.ru> Message-ID: On 6 September 2016 at 01:52, Konstantin Tokarev wrote: > 05.09.2016, 16:38, "Kevin Kofler" : >> Andrew Knight wrote: >>> * Quick survey: which build system do you use (raise of hands by ~40 >>> people) >>> - CMake ~70% >>> - qmake ~20% >>> - Qbs ~10% >> >> That basically says it all. :-) Yes, that basically says it all: 90% of people were certainly unaware or unfamiliar with Qbs! ;) Krys From thiago.macieira at intel.com Tue Sep 6 06:20:06 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 05 Sep 2016 21:20:06 -0700 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <229681473083529@web27g.yandex.ru> Message-ID: <2172009.Q5xAuZtDf9@tjmaciei-mobl1> Em terça-feira, 6 de setembro de 2016, às 13:40:40 PDT, Ch'Gans escreveu: > On 6 September 2016 at 01:52, Konstantin Tokarev wrote: > > 05.09.2016, 16:38, "Kevin Kofler" : > >> Andrew Knight wrote: > >>> * Quick survey: which build system do you use (raise of hands by ~40 > >>> people) > >>> - CMake ~70% > >>> - qmake ~20% > >>> - Qbs ~10% > >> > >> That basically says it all. :-) > > Yes, that basically says it all: 90% of people were certainly unaware > or unfamiliar with Qbs! ;) Which is, in itself, an argument: why learn yet another buildsystem? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chgans at gna.org Tue Sep 6 06:52:47 2016 From: chgans at gna.org (Ch'Gans) Date: Tue, 6 Sep 2016 16:52:47 +1200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <2172009.Q5xAuZtDf9@tjmaciei-mobl1> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <229681473083529@web27g.yandex.ru> <2172009.Q5xAuZtDf9@tjmaciei-mobl1> Message-ID: On 6 September 2016 at 16:20, Thiago Macieira wrote: > Em terça-feira, 6 de setembro de 2016, às 13:40:40 PDT, Ch'Gans escreveu: >> On 6 September 2016 at 01:52, Konstantin Tokarev wrote: >> > 05.09.2016, 16:38, "Kevin Kofler" : >> >> Andrew Knight wrote: >> >>> * Quick survey: which build system do you use (raise of hands by ~40 >> >>> people) >> >>> - CMake ~70% >> >>> - qmake ~20% >> >>> - Qbs ~10% >> >> >> >> That basically says it all. :-) >> >> Yes, that basically says it all: 90% of people were certainly unaware >> or unfamiliar with Qbs! ;) > > Which is, in itself, an argument: why learn yet another buildsystem? Good question, maybe because it's more powerful, it fits better your needs, it is more fun, it uses new concepts, ... Or just out of curiosity! Why learn yet another programming language? If I followed this reasoning, I would still be writing my programs in Motorola assembler... Luckily, I've learned other languages like C, C++, Python, Lua, JS, Qml, etc, ... An average software developer knows about, says 10 to 20 programming languages, maybe even more depending on the definition of "language". Why should he/she knows just one build system? Chris > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From andrew.knight at intopalo.com Tue Sep 6 07:07:25 2016 From: andrew.knight at intopalo.com (Andrew Knight) Date: Tue, 6 Sep 2016 08:07:25 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <1971855.9lgUZeMv02@tjmaciei-mobl1> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1971855.9lgUZeMv02@tjmaciei-mobl1> Message-ID: <87e11a39-bdc7-e721-8dc3-3a91bd7dbab9@intopalo.com> On 09/06/16 03:08, Thiago Macieira wrote: > Em segunda-feira, 5 de setembro de 2016, às 12:49:03 PDT, Andrew Knight > escreveu: >> ** General sentiment: >> - As long as Qbs looks like a part of Qt, it is perceived as a Qt >> product, and is less attractive to external users. >> - Yet, there remains a conflict: "if Qt doesn't use it, I don't want to >> use it" vs. "if it's not outside of Qt, I don't want to use it" > Sounds like the way to go for qbs is to decouple it, make it a separate > project, one that doesn't release in lockstep with Qt. That's already the case. Apart from having a Qt dependency, and being somewhat influenced by Qt Creator development, it does not release in lockstep with either. > > That puts an extra burden in Qbs development: it has to be ahead of Qt's own > development by at least two releases. Building a library should not require a > change in the buildsystem tool: the tool should already support it by the time > we get to that problem. That's unlike qmake, for which we make changes as we > need them in Qt. > That might become a burden if Qbs development starts using new Qt features, but that hasn't really been an issue so far. AFAIK Qbs still builds against Qt 5.2. Over the weekend we had a number of discussions about bootstrapping Qbs (or even removing the Qt dependency altogether). So, I think this requirement is already used in practice and hasn't greatly burdened the project. The Qbs developers are interested in it being small, fast, and portable more than relying on any recent innovations in Qt. -- Andrew From marc.mutz at kdab.com Tue Sep 6 07:24:19 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 6 Sep 2016 07:24:19 +0200 Subject: [Development] Notes on QtCore session @ QCS2016 In-Reply-To: <245522471.MNfLxLEXRv@tjmaciei-mobl1> References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> <245522471.MNfLxLEXRv@tjmaciei-mobl1> Message-ID: <201609060724.20034.marc.mutz@kdab.com> On Tuesday 06 September 2016 02:02:50 Thiago Macieira wrote: > > > * C++11 Standard Library compatibility list > > > > > > > > > * no volunteers yet > > > > > > > > Is this a matter of converting this documented into qdoc? > > > > > > > > https://codereview.qt-project.org/#/c/142782/ > > We decided to make a QUIP out of this, in a later session. Stay tuned. ENOABBREV > > > * C++ ABI > > > > > > > > > * libstdc++ still breaking compatibility in std::function > > > * not now, revisit in a year or two > > > > > > > > There hasn't been time to discuss this at QtCon, but I'd say we should > > not spend another year before revisiting this at the next QtCS: do we > > really care about C++ ABI compatibility? What other C++ libraries are > > doing this? Do users really expect to swap out standard library > > implementations without the need of recompiling libraries and > > applications that use them? Or is it an artificial problem we're > > imposing on ourselves? > > I think there was enough time to discuss it, we did discuss it, and we > concluded that it's still important enough that we don't want to depend on > the ABI right now. In fact, given that libstdc++ is breaking ABI across > its own versions, it's not even a problem of libstdc++ vc libc++ > compatibility (which is also still broken in all Linux distros I've > seen).. The issue I see here is that the Qt BC rules are leaking. They no longer apply to separate Qt versions compiled with the same compiler and options (incl. that of which std implementation to compile against), which is how we understood the BC guarantee. Instead, since some indeterminable (to me) time in the not too distant past, an entirely *arbitrary* selection of options is now _included_ in the BC guarantee, incl. the one of std library implementation, but most notably *not* release/debug on Windows, even though that would be just as possible, and more desireable (there are no two std impls for MSVC). It is being argued that this is a compatibility that was provided by Qt versions before, but that's a smoke screen: a) If you never used the types in the API, it's trivial to make that particular guarantee and b) it falls apart as soon as a user is using Qt API (which exists!) that uses std types, making it all just theoretical. IMO it plain *isn't* Qt jobs to provide the user with that compatibility. That's the job of the *compiler vendors*. It feels like the BC leak is allowed to leak just enough to use the std implementation incompatibilities as an excuse to keep std types out of the Qt ABI when equally desireable compiler options, foremost debug/release, are not included in the guarantee. That's an arbitrary distinction and Qt should stop trying to provide more compatibility than the compiler vendors themselves are willing to give. Thanks, Marc > The "a year or two" revisit is to check how relevant the breakages that we > are currently aware of are, at that time. If they are safely in the past > and don't affect much, and if GCC folks have stopped playing with the > voltage in the power switches, we can reconsider. > > PS: QCS discussions are proposals. They become decisions once the ML agrees > on it. > > PPS: those decisions will be documented as QUIPs. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From jedrzej.nowacki at qt.io Tue Sep 6 09:33:34 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Tue, 6 Sep 2016 09:33:34 +0200 Subject: [Development] CI/5.6: "Failed 7 times to aqcuire the hardware" (was: Fwd: Change in qt/qtbase[5.6]: qstrncpy: don't call strncpy_s with invalid parameters) In-Reply-To: <201609011522.31152.marc.mutz@kdab.com> References: <201609011522.31152.marc.mutz@kdab.com> Message-ID: <2284270.8HehTm6Xjx@42> On torsdag 1. september 2016 15.22.29 CEST Marc Mutz wrote: > Hi, > > Twice in succession. > > Any idea what's happening? > > Thanks, > Marc Yes, more or less. vSphere is overloaded and it shows that it doesn't like it... Anyway write a bug report for it. Especially if you see it again. As for know I have seen it 2 times in last 5-6 months, so I hope it is minor. Cheers, Jędrek From oswald.buddenhagen at qt.io Tue Sep 6 11:43:34 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 6 Sep 2016 11:43:34 +0200 Subject: [Development] [FYI] on gerrit change retargeting requests In-Reply-To: <04C718D5-89D8-496E-AA6A-6118CC41839B@qt.io> References: <20160831141255.GG2429@troll08> <201609051854.25469.marc.mutz@kdab.com> <201609051929.30738.marc.mutz@kdab.com> <04C718D5-89D8-496E-AA6A-6118CC41839B@qt.io> Message-ID: <20160906094334.GB7954@nubble> On Mon, Sep 05, 2016 at 09:17:59PM +0000, J-P Nurmi wrote: > On 05 Sep 2016, at 19:27, Marc Mutz wrote: > > It's not about restricting what a user can do. It's simply missing > > implementation, and I believe that if it were easy to implement, > > Ossi would have done it long ago instead of playing retarget-monkey > > for the rest of us :) > > Doing it through the web UI would be a nice bonus, but having access > to the same script that is already used by the admins would be good > enough for starters. > yep - because i'm totally going to give everyone full write access to the database. ;) if you make a secure web frontend that authenticates against qt account and verifies change ownership using the gerrit ssh interface, i'm totally willing to deploy that. ;) From stephen.kelly at ableton.com Tue Sep 6 11:46:12 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Tue, 6 Sep 2016 11:46:12 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <12176995.VH8TqLCkKB@tjmaciei-mobl1> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <98F2D36D-A065-4427-82C8-311E529F54E2@ableton.com> <12176995.VH8TqLCkKB@tjmaciei-mobl1> Message-ID: On 06/09/16 02:13, Thiago Macieira wrote: > Em segunda-feira, 5 de setembro de 2016, às 12:40:54 PDT, Stephen Kelly via > Development escreveu: >> I think something was lost in transit on this point. I don’t think it would >> be a PITA to write a CMake buildsystem for Qt. I recall the above point was >> in reference to ‘compiling host tools and using them in the build while >> cross compiling’. The way CMake makes that possible currently(!) is >> implemented separately to the core of CMake with the ExternalProject >> module. > That's how it should be. Every single project out there, except for Qt and > possibly GCC itself, builds for one single target. Building something for one > architecture so that it can be run to build another is ungainly and > unexpected. > > Whenever you cross-compile Qt, you end up with tools that can only be run on > the host. So Qt's cross-compilation mechanism can't be used to build tools > that can be run on the target platform. > Yes, I have had problems with that in the past too. However, there's nothing preventing building the tools for both the host and the target. I think that would be cleaner (This is independent of buildsystem tool - I would also be happy if the current qmake build did this). Thanks, -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 From annulen at yandex.ru Tue Sep 6 11:46:24 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 06 Sep 2016 12:46:24 +0300 Subject: [Development] [FYI] on gerrit change retargeting requests In-Reply-To: <20160906094334.GB7954@nubble> References: <20160831141255.GG2429@troll08> <201609051854.25469.marc.mutz@kdab.com> <201609051929.30738.marc.mutz@kdab.com> <04C718D5-89D8-496E-AA6A-6118CC41839B@qt.io> <20160906094334.GB7954@nubble> Message-ID: <123431473155184@web6h.yandex.ru> 06.09.2016, 12:44, "Oswald Buddenhagen" : > On Mon, Sep 05, 2016 at 09:17:59PM +0000, J-P Nurmi wrote: >>  On 05 Sep 2016, at 19:27, Marc Mutz wrote: >>  > It's not about restricting what a user can do. It's simply missing >>  > implementation, and I believe that if it were easy to implement, >>  > Ossi would have done it long ago instead of playing retarget-monkey >>  > for the rest of us :) >> >>  Doing it through the web UI would be a nice bonus, but having access >>  to the same script that is already used by the admins would be good >>  enough for starters. > > yep - because i'm totally going to give everyone full write access to > the database. ;) > > if you make a secure web frontend that authenticates against qt account > and verifies change ownership using the gerrit ssh interface, i'm > totally willing to deploy that. ;) Idea: IRC bot accepting retarget requests, with rate limit e.g. one request per minute. Bot runs on host with db access and can do only this one thing. -- Regards, Konstantin From jpnurmi at qt.io Tue Sep 6 11:56:44 2016 From: jpnurmi at qt.io (J-P Nurmi) Date: Tue, 6 Sep 2016 09:56:44 +0000 Subject: [Development] [FYI] on gerrit change retargeting requests In-Reply-To: <123431473155184@web6h.yandex.ru> References: <20160831141255.GG2429@troll08> <201609051854.25469.marc.mutz@kdab.com> <201609051929.30738.marc.mutz@kdab.com> <04C718D5-89D8-496E-AA6A-6118CC41839B@qt.io> <20160906094334.GB7954@nubble>,<123431473155184@web6h.yandex.ru> Message-ID: On 06 Sep 2016, at 11:46, Konstantin Tokarev wrote: > > > > 06.09.2016, 12:44, "Oswald Buddenhagen" : >>> On Mon, Sep 05, 2016 at 09:17:59PM +0000, J-P Nurmi wrote: >>> On 05 Sep 2016, at 19:27, Marc Mutz wrote: >>> > It's not about restricting what a user can do. It's simply missing >>> > implementation, and I believe that if it were easy to implement, >>> > Ossi would have done it long ago instead of playing retarget-monkey >>> > for the rest of us :) >>> >>> Doing it through the web UI would be a nice bonus, but having access >>> to the same script that is already used by the admins would be good >>> enough for starters. >> >> yep - because i'm totally going to give everyone full write access to >> the database. ;) >> >> if you make a secure web frontend that authenticates against qt account >> and verifies change ownership using the gerrit ssh interface, i'm >> totally willing to deploy that. ;) > > Idea: IRC bot accepting retarget requests, with rate limit e.g. one request per minute. Bot runs on host with db access and can do only this one thing. Another idea: patch Gerrit to change the target branch (and create a new patchset version to reset scores) when pushing to a different branch. -- J-P Nurmi From marc.mutz at kdab.com Tue Sep 6 14:56:31 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 6 Sep 2016 14:56:31 +0200 Subject: [Development] [FYI] on gerrit change retargeting requests In-Reply-To: <20160906094334.GB7954@nubble> References: <20160831141255.GG2429@troll08> <04C718D5-89D8-496E-AA6A-6118CC41839B@qt.io> <20160906094334.GB7954@nubble> Message-ID: <201609061456.31779.marc.mutz@kdab.com> On Tuesday 06 September 2016 11:43:34 Oswald Buddenhagen wrote: > On Mon, Sep 05, 2016 at 09:17:59PM +0000, J-P Nurmi wrote: > > On 05 Sep 2016, at 19:27, Marc Mutz wrote: > > > It's not about restricting what a user can do. It's simply missing > > > implementation, and I believe that if it were easy to implement, > > > Ossi would have done it long ago instead of playing retarget-monkey > > > for the rest of us :) > > > > Doing it through the web UI would be a nice bonus, but having access > > to the same script that is already used by the admins would be good > > enough for starters. > > yep - because i'm totally going to give everyone full write access to > the database. ;) > > if you make a secure web frontend that authenticates against qt account > and verifies change ownership using the gerrit ssh interface, i'm > totally willing to deploy that. ;) Maybe just add a combobox "Request Move to Other Branch" that just emails you and Frederik? As it is now, not even all @qt.io people know how to do this/that it's possible... Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Tue Sep 6 15:20:34 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Sep 2016 06:20:34 -0700 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <12176995.VH8TqLCkKB@tjmaciei-mobl1> Message-ID: <6668361.qDuafcBIYy@tjmaciei-mobl1> Em terça-feira, 6 de setembro de 2016, às 11:46:12 PDT, Stephen Kelly via Development escreveu: > > Whenever you cross-compile Qt, you end up with tools that can only be run > > on the host. So Qt's cross-compilation mechanism can't be used to build > > tools that can be run on the target platform. > > Yes, I have had problems with that in the past too. However, there's > nothing preventing building the tools for both the host and the target. > I think that would be cleaner (This is independent of buildsystem tool - > I would also be happy if the current qmake build did this). The biggest offender of this is qmake itself. So if we move away from qmake to something else, I'd expect that one could just use any host pre-built set of tools (moc, uic, rcc, etc.) to build your target Qt. Any mismatch of qobjectsdefs.h and moc is already an #error. Building the host tools while cross-compiling is a convenience and I think we can keep it, but I don't think we should simply have different "bin" dirs. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 6 15:26:30 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Sep 2016 06:26:30 -0700 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <2172009.Q5xAuZtDf9@tjmaciei-mobl1> Message-ID: <3046179.x0av3CoztB@tjmaciei-mobl1> Em terça-feira, 6 de setembro de 2016, às 16:52:47 PDT, Ch'Gans escreveu: > > Which is, in itself, an argument: why learn yet another buildsystem? > > Good question, maybe because it's more powerful, it fits better your > needs, it is more fun, it uses new concepts, ... > Or just out of curiosity! > > Why learn yet another programming language? I haven't learnt any new programming languages since PHP in the late 90s. That specifically excludes major languages like Python, C# and even QML itself. I have yet to write a single QML file (disclaimer: my last GUI application was qdbusviewer, in 2006, and it was also my first). I think I'm not doing that bad... > If I followed this reasoning, I would still be writing my programs in > Motorola assembler... > Luckily, I've learned other languages like C, C++, Python, Lua, JS, > Qml, etc, ... > > An average software developer knows about, says 10 to 20 programming > languages, maybe even more depending on the definition of "language". > Why should he/she knows just one build system? There's a difference between "I could read that thing if I needed to" and "I can write very good code in this language". I can read Python, C# and QML, Go, Lua, Tcl, LISP, Rust, maybe even Haskell; but I have no interest in becoming an expert in any of those. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 6 15:46:37 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Sep 2016 06:46:37 -0700 Subject: [Development] Notes on QtCore session @ QCS2016 In-Reply-To: <201609060724.20034.marc.mutz@kdab.com> References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> <245522471.MNfLxLEXRv@tjmaciei-mobl1> <201609060724.20034.marc.mutz@kdab.com> Message-ID: <1990526.ruIhrjze9J@tjmaciei-mobl1> Em terça-feira, 6 de setembro de 2016, às 07:24:19 PDT, Marc Mutz escreveu: > On Tuesday 06 September 2016 02:02:50 Thiago Macieira wrote: > > > https://codereview.qt-project.org/#/c/142782/ > > > > We decided to make a QUIP out of this, in a later session. Stay tuned. > > ENOABBREV It's a backronym, so expanding doesn't help. You need to read Louai's full post, when he posts it. > Instead, since some indeterminable (to me) time in the not too distant past, > an entirely *arbitrary* selection of options is now _included_ in the BC > guarantee, incl. the one of std library implementation, but most notably > *not* release/debug on Windows, even though that would be just as possible, > and more desireable (there are no two std impls for MSVC). It is being > argued that this is a compatibility that was provided by Qt versions > before, but that's a smoke screen: a) If you never used the types in the > API, it's trivial to make that particular guarantee and b) it falls apart > as soon as a user is using Qt API (which exists!) that uses std types, > making it all just theoretical. I agree with you that we shouldn't need to specify our binary compatibility in terms of other libraries. Like you said, we don't do it for the MSVC runtime, like we don't for libpng (12 or 16?) , libjpeg (8, 62 or turbo?), libmysqlclient or libudev. It was a *choice* not to depend on the C++ Standard Library ABI for features outside of the language support. The choice was made during Qt 5.0 development, in response to the -no-stl option being removed. It was originally done so that applications and libraries on Apple platforms could choose to use libstdc++ or libc++: it was common back in 2012 that applications would need to link to proprietary libraries that used libstdc++ and could not easily be recompiled. That choice extended to GCC 4.9 & 5.0 that broke compatibility, and it turned out to be a bonus for us because Qt-only applications did not need to be recompiled. > IMO it plain *isn't* Qt jobs to provide the user with that compatibility. > That's the job of the *compiler vendors*. Agreed. But it's a nice bonus. > It feels like the BC leak is allowed to leak just enough to use the std > implementation incompatibilities as an excuse to keep std types out of the > Qt ABI when equally desireable compiler options, foremost debug/release, > are not included in the guarantee. > > That's an arbitrary distinction and Qt should stop trying to provide more > compatibility than the compiler vendors themselves are willing to give. We could choose that route too. The QCS recommendation is that we revisit this, again, next year. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From viktor.engelmann at qt.io Tue Sep 6 15:47:15 2016 From: viktor.engelmann at qt.io (Viktor Engelmann) Date: Tue, 6 Sep 2016 15:47:15 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <229681473083529@web27g.yandex.ru> <2172009.Q5xAuZtDf9@tjmaciei-mobl1> Message-ID: Am 06.09.2016 um 06:52 schrieb Ch'Gans: > On 6 September 2016 at 16:20, Thiago Macieira wrote: >> Which is, in itself, an argument: why learn yet another buildsystem? > ... > > Why learn yet another programming language? > > ... > > An average software developer knows about, says 10 to 20 programming > languages, maybe even more depending on the definition of "language". > Why should he/she knows just one build system? > > Chris My 2 cents: I want to spend my time on programming = being productive - Not waste my time fighting against an incredibly stupid build system... In my opinion, build systems in general haven't matured the way compilers have. Using classes and polymorphism, you can easily explain arbitrarily complex situations to compilers. I have yet to see a build system that understands more complex situations than "FILE1 IS OLDER THAN FILE2". They don't even have the slightest understanding of the commands they execute - they just slap some raw strings together (which YOU have to provide) and pass them to a shell. Oh, these raw strings were for a different OS? Or even just a different version of the same compiler on the same OS? well too bad... It kind of reminds me of this joke: http://www.ebaumsworld.com/jokes/blond-hole-diggers/80432143/ Viktor -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin Viktor.Engelmann at qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Qt World Summit 2016 Qt World Summit 2016 | Pier 27, San Francisco, CA Experience Exponential Potential on October 18-20 www.qtworldsummit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_logo_with_text_green_rgb_400x141.png Type: image/png Size: 16849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_facebook.png Type: image/png Size: 1407 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_twitter.png Type: image/png Size: 1778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_linkedin.png Type: image/png Size: 1532 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_googleplus.png Type: image/png Size: 1957 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_youtube.png Type: image/png Size: 1610 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qtworldsummit2016_banner.jpg Type: image/jpeg Size: 35183 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: viktor_engelmann.vcf Type: text/x-vcard Size: 271 bytes Desc: not available URL: From thiago.macieira at intel.com Tue Sep 6 15:49:45 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Sep 2016 06:49:45 -0700 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <6668361.qDuafcBIYy@tjmaciei-mobl1> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <6668361.qDuafcBIYy@tjmaciei-mobl1> Message-ID: <8719423.nmRhLTuoEX@tjmaciei-mobl1> Em terça-feira, 6 de setembro de 2016, às 06:20:34 PDT, Thiago Macieira escreveu: > Building the host tools while cross-compiling is a convenience and I think > we can keep it, but I don't think we should simply have different "bin" > dirs. Fail in sentence rewrite. I wanted to write "don't think we should mix" and then rewrote to "think we should simply have different 'bin' dirs" -- except I forgot to remove the "don't". I don't have a cross-compiled build of Qt handy, but I think we put both host and target builds in the same "bin" dir during the build. It should be easy to split and then always build target tools too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 6 15:59:40 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Sep 2016 06:59:40 -0700 Subject: [Development] A faster qUtf8Printable for static trace points? In-Reply-To: <1757662.KxShe8fSTD@agathebauer> References: <1757662.KxShe8fSTD@agathebauer> Message-ID: <2378524.1HAKQvlkHk@tjmaciei-mobl1> Em segunda-feira, 5 de setembro de 2016, às 21:20:12 PDT, Milian Wolff escreveu: > Hey Thiago, others. Hey Milian Is this what you were looking for me for on Sunday afternoon? > bool QLibraryPrivate::load() > { > ... > TraceScope<...> ts(qUtf8Printable(fileName)) > ... > } Hmm... I only agreed to something that has no runtime impact when not in use. I thought the traces were totally out-of-line (recorded in a separate section). Annotating variables sounds like a good idea, but annotating the result of function calls... not so much. > Trace points have nearly zero runtime overhead when not used [1]. But the > above has a super high cost due to calling QString::toUtf8, which constructs > a temporary QByteArray and thus incurs a temporary runtime allocation. An > alternative would be to use qUtf16Printable, which would be fast, but I > fear it makes interoperability with existing trace point consumers hard. > > Can someone with experience on trace points confirm this assertion? If that > is untrue, simply using qUtf16Printable above would make everything work, > and be fast. qUtf16Printable may reallocate if the QString in question was created with fromRawData. But that's not a very common use-case. As for existing trace point consumers, sorry, you're the expert. I have no clue if there are any that dump UTF-16, but I wouldn't be surprised if there weren't. How hard would it be to add them? Remeber that C++11 has char16_t. > One way to handle the above case would be only doing the qUtf8Printable call > when the trace point is enabled, but afaik that checking also is not done > for free, and also makes the consumer code harder to write. Right. Don't annotate with function calls. Annotate variables only. You can mostly do this by adding an unreachable rvalue-ref overload, like qAsConst. > https://github.com/milianw/bench_qt/blob/master/bench_qstring/ > bench_qstring.cpp#L118 > > Would something like this be acceptable for upstream? E.g. change > qUtf8Printable to not allocate memory for up to PATH_MAX chars or similar, > and otherwise fallback to the slow QByteArray (or simply truncate, which > would be an option for trace points actually). That change is interesting and we could accept it, but I still wouldn't want it used in tracepoints. You avoid the allocation, but you're still converting to UTF-8. Your benchmark doesn't show it because your strings are probably very short and our UTF-8 algorithm is very optimised. It is dwarfed by the memory allocation. No, instead the policy should be that we annotate only direct variables or values that can be computed easily from the variable itself (like constData()). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From laszlo.agocs at qt.io Tue Sep 6 16:00:55 2016 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Tue, 6 Sep 2016 14:00:55 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <8719423.nmRhLTuoEX@tjmaciei-mobl1> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <6668361.qDuafcBIYy@tjmaciei-mobl1>, <8719423.nmRhLTuoEX@tjmaciei-mobl1> Message-ID: Using one "bin" is the default behavior, yes, but one can pass -hostprefix to separate them upon install. http://doc-snapshots.qt.io/qt5-5.8/embedded-linux.html#configuring-a-specific-device Cheers, Laszlo ________________________________ From: Development on behalf of Thiago Macieira Sent: Tuesday, September 6, 2016 3:49 PM To: development at qt-project.org Subject: Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016 Em terça-feira, 6 de setembro de 2016, às 06:20:34 PDT, Thiago Macieira escreveu: > Building the host tools while cross-compiling is a convenience and I think > we can keep it, but I don't think we should simply have different "bin" > dirs. Fail in sentence rewrite. I wanted to write "don't think we should mix" and then rewrote to "think we should simply have different 'bin' dirs" -- except I forgot to remove the "don't". I don't have a cross-compiled build of Qt handy, but I think we put both host and target builds in the same "bin" dir during the build. It should be easy to split and then always build target tools too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From viktor.engelmann at qt.io Tue Sep 6 16:08:59 2016 From: viktor.engelmann at qt.io (Viktor Engelmann) Date: Tue, 6 Sep 2016 16:08:59 +0200 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: <2633012.tF69sBFDdv@tjmaciei-mobl1> References: <8615812.gtAI1A4odG@tjmaciei-mobl1> <1660564d-62f2-c8e4-cc21-e488b7a36edf@qt.io> <2633012.tF69sBFDdv@tjmaciei-mobl1> Message-ID: It is just a (more extreme) example of my point: If the user bypasses our security measures and shoots himself in the foot - why should we take any responsibility for that? Am 06.09.2016 um 01:44 schrieb Thiago Macieira: > Em segunda-feira, 5 de setembro de 2016, às 16:08:41 PDT, Viktor Engelmann > escreveu: >> So what if the user adds an asm statement that changes a register and >> doesn't declare that register to be changed? That would also cause his >> "Qt" application to misbehave... or what if he links the object files to >> a custom loader that doesn't call the constructors for global objects? > If you insert an asm statement that changes a register and you don't inform > GCC that you changed it, then your application is buggy and it deserves to > crash. In fact, you should HOPE it crashes cleanly, before it corrupts any > user data. > > Still, what does that have to do with the problem at hand? > -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin Viktor.Engelmann at qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Qt World Summit 2016 Qt World Summit 2016 | Pier 27, San Francisco, CA Experience Exponential Potential on October 18-20 www.qtworldsummit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_logo_with_text_green_rgb_400x141.png Type: image/png Size: 16849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_facebook.png Type: image/png Size: 1407 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_twitter.png Type: image/png Size: 1778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_linkedin.png Type: image/png Size: 1532 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_googleplus.png Type: image/png Size: 1957 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_youtube.png Type: image/png Size: 1610 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qtworldsummit2016_banner.jpg Type: image/jpeg Size: 35183 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: viktor_engelmann.vcf Type: text/x-vcard Size: 271 bytes Desc: not available URL: From ulf.hermann at qt.io Tue Sep 6 16:29:38 2016 From: ulf.hermann at qt.io (Ulf Hermann) Date: Tue, 6 Sep 2016 16:29:38 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <229681473083529@web27g.yandex.ru> <2172009.Q5xAuZtDf9@tjmaciei-mobl1> Message-ID: <773d1eb5-4d07-e114-4e64-c53b69ced1c7@qt.io> > It kind of reminds me of this joke: > http://www.ebaumsworld.com/jokes/blond-hole-diggers/80432143/ Do we have a policy about inappropriate content posted to mailing lists and similar communication channels? If not, I think we should agree on banning at least some basic things like racism or sexism. We should be inclusive after all, and not scare off any potential contributors. regards, Ulf From thiago.macieira at intel.com Tue Sep 6 16:31:43 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Sep 2016 07:31:43 -0700 Subject: [Development] Using platform-native APIs for terminating QThreads In-Reply-To: References: <2633012.tF69sBFDdv@tjmaciei-mobl1> Message-ID: <13155767.dgTvvToNAT@tjmaciei-mobl1> Em terça-feira, 6 de setembro de 2016, às 16:08:59 PDT, Viktor Engelmann escreveu: > It is just a (more extreme) example of my point: > > If the user bypasses our security measures and shoots himself in the > foot - why should we take any responsibility for that? The problem here is that you went extreme. Extremes are clear because they're far from the dividing line. The question we have is what side of the line are we on for pthread_exit? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 6 16:33:11 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Sep 2016 07:33:11 -0700 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <8719423.nmRhLTuoEX@tjmaciei-mobl1> Message-ID: <2661598.xb9uy4BhbP@tjmaciei-mobl1> Em terça-feira, 6 de setembro de 2016, às 14:00:55 PDT, Laszlo Agocs escreveu: > Using one "bin" is the default behavior, yes, but one can pass -hostprefix > to separate them upon install. > > > http://doc-snapshots.qt.io/qt5-5.8/embedded-linux.html#configuring-a-specifi > c-device That's for installation. I was thinking during the build too, so that moc is built twice when the "convenience host tools" are built. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 6 16:34:41 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Sep 2016 07:34:41 -0700 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <773d1eb5-4d07-e114-4e64-c53b69ced1c7@qt.io> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <773d1eb5-4d07-e114-4e64-c53b69ced1c7@qt.io> Message-ID: <2676077.QH9I58bjHI@tjmaciei-mobl1> Em terça-feira, 6 de setembro de 2016, às 16:29:38 PDT, Ulf Hermann escreveu: > Do we have a policy about inappropriate content posted to mailing lists and > similar communication channels? No, but there was a side-discussion at QCS that we should write and adopt a Code of Conduct. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Tue Sep 6 16:37:16 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 6 Sep 2016 14:37:16 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <2676077.QH9I58bjHI@tjmaciei-mobl1> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <773d1eb5-4d07-e114-4e64-c53b69ced1c7@qt.io> <2676077.QH9I58bjHI@tjmaciei-mobl1> Message-ID: <2B9740BC-D74C-46E1-82FD-F78C3FA60FBD@qt.io> On Sep 6, 2016, at 4:34 PM, Thiago Macieira > wrote: Em terça-feira, 6 de setembro de 2016, às 16:29:38 PDT, Ulf Hermann escreveu: Do we have a policy about inappropriate content posted to mailing lists and similar communication channels? No, but there was a side-discussion at QCS that we should write and adopt a Code of Conduct. Let's start a new thread for that, then, if someone is interested (keep this one on topic of build systems). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Tue Sep 6 17:10:19 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 06 Sep 2016 17:10:19 +0200 Subject: [Development] Notes on QtCore session @ QCS2016 References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> <245522471.MNfLxLEXRv@tjmaciei-mobl1> <201609060724.20034.marc.mutz@kdab.com> <1990526.ruIhrjze9J@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > It was a *choice* not to depend on the C++ Standard Library ABI for > features outside of the language support. The choice was made during Qt > 5.0 development, in response to the -no-stl option being removed. It was > originally done so that applications and libraries on Apple platforms > could choose to use libstdc++ or libc++: it was common back in 2012 that > applications would need to link to proprietary libraries that used > libstdc++ and could not easily be recompiled. That choice extended to GCC > 4.9 & 5.0 that broke compatibility, and it turned out to be a bonus for us > because Qt-only applications did not need to be recompiled. I think it was a mistake to remove -no-stl to begin with, and that Qt API should not be littered with ugly std:: APIs, not just for ABI reasons, but also for API (consistency) reasons. Why can't Qt continue to offer better Q* equivalents as it has always done? What benefit does it bring to users to deprecate nice APIs for less nice ones just because the latter are part of the compiler? Kevin Kofler From kevin.kofler at chello.at Tue Sep 6 17:19:06 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 06 Sep 2016 17:19:06 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <229681473083529@web27g.yandex.ru> <2172009.Q5xAuZtDf9@tjmaciei-mobl1> Message-ID: Ch'Gans wrote: > If I followed this reasoning, I would still be writing my programs in > Motorola assembler... pea msg(%pc) jbsr puts addq.l #4,%a7 rts msg: .asciz "And this would be wrong, why? ;-)" or if you prefer the more traditional syntax: pea msg(PC) jsr puts addq.l #4,a7 rts msg: dc.b "And this would be wrong, why? ;-)", 0 :-) Kevin Kofler From kevin.kofler at chello.at Tue Sep 6 17:14:58 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 06 Sep 2016 17:14:58 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: Ch'Gans wrote: > I never wanted to use CMake b/c for me it look like a gross hack > (Reminds me of GNU M4). The CMake language is much easier to use than m4, and also there is just one layer rather than having autoconf on top of m4, with shell script snippets mixed in. There is a reason CMake is being proposed for Qt and autotools is not. > Makefiles are out-dated (no punt intended) and so is CMake and any > other Makefile-based tools. > Makefiles are dead! CMake is ill! (Friendly, easy and provocative > argument) CMake can generate other build files than makefiles (e.g., the Ninja generator is basically a drop-in replacement). I guess somebody could even get CMake to write Qbs files, it would just be one more generator. :-) Kevin Kofler From Jake.Petroules at qt.io Tue Sep 6 17:24:33 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 6 Sep 2016 15:24:33 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: <19E17854-6D3B-432D-BE1D-0374B77ED65E@qt.io> On Sep 6, 2016, at 5:14 PM, Kevin Kofler > wrote: Ch'Gans wrote: I never wanted to use CMake b/c for me it look like a gross hack (Reminds me of GNU M4). The CMake language is much easier to use than m4, and also there is just one layer rather than having autoconf on top of m4, with shell script snippets mixed in. There is a reason CMake is being proposed for Qt and autotools is not. Makefiles are out-dated (no punt intended) and so is CMake and any other Makefile-based tools. Makefiles are dead! CMake is ill! (Friendly, easy and provocative argument) CMake can generate other build files than makefiles (e.g., the Ninja generator is basically a drop-in replacement). Again, Ninja has its architectural limitations as well, so this would not be useful. The problem isn't (just) Makefiles, it's the fact that we don't have a build tool that is fundamentally better and more powerful than anything we've ever had before, and we CAN have this. It's like C++ vs Motorola 68k assembler. I guess somebody could even get CMake to write Qbs files, it would just be one more generator. :-) Again, useless, because Qbs is more powerful and at a much higher level of abstraction, so a generator would only be useful in the reverse direction. It's like trying to make a compiler to transform Motorola 68k assembler to C++. Only the reverse transformation of that can done in a useful manner. Kevin Kofler _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Tue Sep 6 17:34:15 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 06 Sep 2016 18:34:15 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <19E17854-6D3B-432D-BE1D-0374B77ED65E@qt.io> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <19E17854-6D3B-432D-BE1D-0374B77ED65E@qt.io> Message-ID: <59711473176055@web30m.yandex.ru> 06.09.2016, 18:24, "Jake Petroules" : >> On Sep 6, 2016, at 5:14 PM, Kevin Kofler wrote: >> >> Ch'Gans wrote: >>> I never wanted to use CMake b/c for me it look like a gross hack >>> (Reminds me of GNU M4). >> >> The CMake language is much easier to use than m4, and also there is just one >> layer rather than having autoconf on top of m4, with shell script snippets >> mixed in. >> >> There is a reason CMake is being proposed for Qt and autotools is not. >> >>> Makefiles are out-dated (no punt intended) and so is CMake and any >>> other Makefile-based tools. >>> Makefiles are dead! CMake is ill! (Friendly, easy and provocative >>> argument) >> >> CMake can generate other build files than makefiles (e.g., the Ninja >> generator is basically a drop-in replacement). > > Again, Ninja has its architectural limitations as well, so this would not be useful. The problem isn't (just) Makefiles, it's the fact that we don't have a build tool that is fundamentally better and more powerful than anything we've ever had before, and we CAN have this. It's like C++ vs Motorola 68k assembler. Architecture of ninja is not the biggest problem here - I'd rather argue that if your build graph is unknown ahead of time your build process is flawed. Problem is that CMake often makes it hard to do things which can be easily expressed in terms of make or ninja, e.g. it does not have a concept of build rule (instead you have for write foreach cycles), or such trivial thing as building PCH for gcc turns into the page of ugly cmake code [1] [1] https://gist.github.com/larsch/573926 > >> I guess somebody could even get CMake to write Qbs files, it would just be >> one more generator. :-) > > Again, useless, because Qbs is more powerful and at a much higher level of abstraction, so a generator would only be useful in the reverse direction. It's like trying to make a compiler to transform Motorola 68k assembler to C++. Only the reverse transformation of that can done in a useful manner. > >>        Kevin Kofler >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Jake Petroules - jake.petroules at qt.io > Consulting Services Engineer - The Qt Company > Qbs build tool evangelist - qbs.io > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From cristian.adam at gmail.com Tue Sep 6 17:35:03 2016 From: cristian.adam at gmail.com (Cristian Adam) Date: Tue, 6 Sep 2016 17:35:03 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: On Tue, Sep 6, 2016 at 5:14 PM, Kevin Kofler wrote: > > I guess somebody could even get CMake to write Qbs files, it would just be > one more generator. :-) > > This was done already , but it was removed from CMake due to bad feedback from Qt Creator people. Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Tue Sep 6 17:35:45 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 6 Sep 2016 17:35:45 +0200 Subject: [Development] Notes on QtCore session @ QCS2016 In-Reply-To: References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> <245522471.MNfLxLEXRv@tjmaciei-mobl1> <201609060724.20034.marc.mutz@kdab.com> <1990526.ruIhrjze9J@tjmaciei-mobl1> Message-ID: <6464027d-a8b2-605f-5c61-d6ba215f8de0@kdab.com> Il 06/09/2016 17:10, Kevin Kofler ha scritto: > I think it was a mistake to remove -no-stl to begin with, and that Qt API > should not be littered with ugly std:: APIs, not just for ABI reasons, but > also for API (consistency) reasons. Having APIs which follows the naming in the Standard Library has nothing to do with the discussion at hand. It's also proven that: 1) they allow C++ developers to see Qt as a less foreign land 2) they allow Qt classes to be used with other APIs (say, run algorithms written for the STL over them) 3) they don't pose any extra maintenance burden (as they would just forward the call to the Qt-ish API) So please do not derail this sub-topic. The subject at hand here is using Standard Library datatypes in our public API. > Why can't Qt continue to offer better Q* equivalents as it has always done? 1) BECAUSE. THEY. ARE. NOT. BETTER. In so many cases they're actually far worse (hi, algorithms!). Can we please stop having this discussion over and over again? 2) Because there are countless things for which you can't escape from using the Standard Library: how can you possibly implement things like std::is_enum? How can you handle initializer lists? (And yes: we need all of that). 3) Because nobody wants to spend time to properly reimplement non-trivial things like std::function, when we have a fully working std::function we could just use. And we need std::function in many places in our public API. Rinse and repeat for the other cases. And before you think of "let's make a simplified std::function, which will be 'simpler' for the user to use, and 'simpler' for us to implement", please read https://www.kdab.com/goodbye-q_foreach/#comment-158485 > What benefit does it bring to users to deprecate nice APIs for less nice > ones just because the latter are part of the compiler? Nobody is talking about this -- on the contrary, we even considered offering convenience classes. Say, a std::vector subclass which adds append() and isEmpty(). -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From marc.mutz at kdab.com Tue Sep 6 18:01:18 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 6 Sep 2016 18:01:18 +0200 Subject: [Development] Notes on QtCore session @ QCS2016 In-Reply-To: <6464027d-a8b2-605f-5c61-d6ba215f8de0@kdab.com> References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> <6464027d-a8b2-605f-5c61-d6ba215f8de0@kdab.com> Message-ID: <201609061801.18916.marc.mutz@kdab.com> Noo.... don't feed the Troll...! :) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Tue Sep 6 19:08:23 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 6 Sep 2016 19:08:23 +0200 Subject: [Development] Notes on QtCore session @ QCS2016 In-Reply-To: <201609061801.18916.marc.mutz@kdab.com> References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> <6464027d-a8b2-605f-5c61-d6ba215f8de0@kdab.com> <201609061801.18916.marc.mutz@kdab.com> Message-ID: <201609061908.24095.marc.mutz@kdab.com> On Tuesday 06 September 2016 18:01:18 Marc Mutz wrote: > Noo.... don't feed the Troll...! :) (with apologies to the original Trolltech people!) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From andre at familiesomers.nl Tue Sep 6 19:27:44 2016 From: andre at familiesomers.nl (=?utf-8?Q?Andr=C3=A9_Somers?=) Date: Tue, 6 Sep 2016 19:27:44 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: Sent from my iPhone > On 06 Sep 2016, at 17:35, Cristian Adam wrote: > >> On Tue, Sep 6, 2016 at 5:14 PM, Kevin Kofler wrote: >> >> I guess somebody could even get CMake to write Qbs files, it would just be >> one more generator. :-) > > This was done already, but it was removed from CMake due to bad feedback from > Qt Creator people. Pitty. That might have made a useful porting tool. André > > Cheers, > Cristian. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoenitz at t-online.de Tue Sep 6 19:59:08 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Tue, 6 Sep 2016 19:59:08 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: <20160906175908.GA3278@klara.mpi.htwm.de> On Tue, Sep 06, 2016 at 05:35:03PM +0200, Cristian Adam wrote: > On Tue, Sep 6, 2016 at 5:14 PM, Kevin Kofler wrote: > > > > > I guess somebody could even get CMake to write Qbs files, it would just be > > one more generator. :-) > > > > > This was done already > , > but it was removed from CMake due to bad feedback from > Qt Creator people. Is this feedback recorded somewhere? Andre' From kevin.kofler at chello.at Tue Sep 6 19:52:01 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 06 Sep 2016 19:52:01 +0200 Subject: [Development] Notes on QtCore session @ QCS2016 References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> <245522471.MNfLxLEXRv@tjmaciei-mobl1> <201609060724.20034.marc.mutz@kdab.com> <1990526.ruIhrjze9J@tjmaciei-mobl1> <6464027d-a8b2-605f-5c61-d6ba215f8de0@kdab.com> Message-ID: Giuseppe D'Angelo wrote: > So please do not derail this sub-topic. The subject at hand here is > using Standard Library datatypes in our public API. And I was just pointing out that doing so also waters the API consistency, in addition to the ABI issues. > 1) BECAUSE. THEY. ARE. NOT. BETTER. In so many cases they're actually > far worse (hi, algorithms!). Can we please stop having this discussion > over and over again? QtAlgorithms was more convenient to use than the STL algorithms. In particular, it had convenience overloads operating on the whole container, which is by far the most common use case, whereas the STL algorithms require you to copy&paste begin() and end() boilerplate. Both the Qt and the STL implementations of things have their advantages, but as an API user, I find the Qt ones much more compelling than the STL ones. One important property is that the Qt ones are usually a lot harder to misuse in a way that will make them very inefficient (e.g., O(n) by-value assignment of std::vector vs. O(1) by-value assignment of QVector or QList, O(mn) insertion into std::vector vs. O(n) insertion into QList, etc.) or even crashy (e.g., accidentally modifying a container within a range-for on it vs. safe Q_FOREACH). The STL ones may be marginally faster when used perfectly, but it is hard to get everything right (and requires ugly write- only hacks such as move and swap), and even the slightest mistake will more than kill the performance advantage. The Qt containers are what makes C++/Qt competitive with other languages in term of convenience. In fact, in terms of convenience, I'd easily rank Qt > Java > STL. Forcing people to use the STL will just make them prefer languages with a less arcane standard library. > 2) Because there are countless things for which you can't escape from > using the Standard Library: how can you possibly implement things like > std::is_enum? How can you handle initializer lists? (And yes: we need > all of that). In the public API, non-optionally? > 3) Because nobody wants to spend time to properly reimplement > non-trivial things like std::function, when we have a fully working > std::function we could just use. And we need std::function in many > places in our public API. Rinse and repeat for the other cases. > > And before you think of "let's make a simplified std::function, which > will be 'simpler' for the user to use, and 'simpler' for us to > implement", please read > > https://www.kdab.com/goodbye-q_foreach/#comment-158485 And that is exactly one of the comments I disagree with. (In fact, I had posted a reply to that blog comment, but it was censored by the blog owner.) The premise there is that we want to eventually deprecate things like qAsConst, and so we have to artificially cripple them to allow doing that in the future? But why can we not just accept to keep a better version forever? So the entire premise is wrong. As for the issue of avoiding copying non-implicitly-shared rvalues: Would this work? #define qAsConst(x) static_cast((x)) As far as I know, rvalues can (still) be safely cast to const T &. >> What benefit does it bring to users to deprecate nice APIs for less nice >> ones just because the latter are part of the compiler? > > Nobody is talking about this -- on the contrary, we even considered > offering convenience classes. Say, a std::vector subclass which adds > append() and isEmpty(). That doesn't solve the inherent lack of COW. It is possible to wrap COW around STL containers (e.g., I've done so for std::priority_queue in a project of mine), but that adds an extra indirection compared to QVector, so it is a performance loss. Kevin Kofler From kevin.kofler at chello.at Tue Sep 6 20:04:02 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 06 Sep 2016 20:04:02 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <19E17854-6D3B-432D-BE1D-0374B77ED65E@qt.io> Message-ID: Jake Petroules wrote: > Again, useless, because Qbs is more powerful and at a much higher level of > abstraction, so a generator would only be useful in the reverse direction. Of course, the generator would not use all the features of Qbs, just the minimum subset that is needed to do the work. > It's like trying to make a compiler to transform Motorola 68k assembler to > C++. Only the reverse transformation of that can done in a useful manner. That is not a reasonable comparison. Assembly code is not designed to be compiled to anything other than the corresponding machine code. Code can be self-modifying, there are hardware-dependent I/O ports, etc. The CMake language is designed exactly to perform configuration and then output build files for all sorts of build systems: make, Ninja, various IDEs, etc. But of course, all the configury would be done at CMake time and Qbs would just be tasked to do the actual build, as a make replacement. Will somebody be interested enough in implementing that? Probably not. But if make is really the issue, it could be done. Kevin Kofler From kevin.kofler at chello.at Tue Sep 6 20:10:18 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 06 Sep 2016 20:10:18 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: Cristian Adam wrote: > This was done already > , > but it was removed from CMake due to bad feedback from > Qt Creator people. Interesting, but why was that done on top of existing makefile generators? I'd expect the Qbs generator to be a new toplevel generator instead. Kevin Kofler From cristian.adam at gmail.com Tue Sep 6 20:30:19 2016 From: cristian.adam at gmail.com (Cristian Adam) Date: Tue, 6 Sep 2016 20:30:19 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <20160906175908.GA3278@klara.mpi.htwm.de> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <20160906175908.GA3278@klara.mpi.htwm.de> Message-ID: <3e351a3d-ed09-8bba-3496-b232814dde01@gmail.com> On 06-Sep-16 19:59, André Pönitz wrote: > On Tue, Sep 06, 2016 at 05:35:03PM +0200, Cristian Adam wrote: >> On Tue, Sep 6, 2016 at 5:14 PM, Kevin Kofler wrote: >> >>> I guess somebody could even get CMake to write Qbs files, it would just be >>> one more generator. :-) >>> >>> >> This was done already >> , >> but it was removed from CMake due to bad feedback from >> Qt Creator people. > Is this feedback recorded somewhere? > > Andre' https://git.backbone.ws/cmake/cmake/commit/deec97d8eca4db67be09031757fd11f66c1a037b Revert "Qbs: Add new 'extra' generator for qbs project files" This reverts commit f85db2f32358e6de921aba7d1cb8ecb81da934c0. Discussion by the QtCreator community at https://bugreports.qt.io/browse/QTCREATORBUG-13695 raises concerns about this particular approach to working with CMake projects using QtCreator. Also, the functionality and design of the QBS extra generator was never discussed on the CMake mailing list or with QtCreator developers. There may be better ways to make the two tools work together. In order to avoid committing to long-term support of this generator prior to such discussion taking place, revert it from CMake for now. We may restore this or use an alternative design based on results of such discussion. Maybe "bad feedback" is strong, but it was non constructive and lead to the removal of the Qbs generator. Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From milian.wolff at kdab.com Tue Sep 6 20:48:39 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Tue, 06 Sep 2016 20:48:39 +0200 Subject: [Development] A faster qUtf8Printable for static trace points? In-Reply-To: <2378524.1HAKQvlkHk@tjmaciei-mobl1> References: <1757662.KxShe8fSTD@agathebauer> <2378524.1HAKQvlkHk@tjmaciei-mobl1> Message-ID: <3169544.9zaPPYYkHl@agathebauer> On Dienstag, 6. September 2016 06:59:40 CEST Thiago Macieira wrote: > Em segunda-feira, 5 de setembro de 2016, às 21:20:12 PDT, Milian Wolff > > escreveu: > > Hey Thiago, others. > > Hey Milian > > Is this what you were looking for me for on Sunday afternoon? Yes :) > > bool QLibraryPrivate::load() > > { > > > > ... > > TraceScope<...> ts(qUtf8Printable(fileName)) > > ... > > > > } > > Hmm... I only agreed to something that has no runtime impact when not in > use. I thought the traces were totally out-of-line (recorded in a separate > section). Annotating variables sounds like a good idea, but annotating the > result of function calls... not so much. True, I think this was not clear and shows the value of starting this discussion early. > > Trace points have nearly zero runtime overhead when not used [1]. But the > > above has a super high cost due to calling QString::toUtf8, which > > constructs a temporary QByteArray and thus incurs a temporary runtime > > allocation. An alternative would be to use qUtf16Printable, which would > > be fast, but I fear it makes interoperability with existing trace point > > consumers hard. > > > > Can someone with experience on trace points confirm this assertion? If > > that > > is untrue, simply using qUtf16Printable above would make everything work, > > and be fast. > > qUtf16Printable may reallocate if the QString in question was created with > fromRawData. But that's not a very common use-case. As for existing trace > point consumers, sorry, you're the expert. I wouldn't call myself an expert on that yet - I have used it, and have written custom analysation tools for LTTNG. But this does not necessarily mean I know all the ways in which this can be used :] > I have no clue if there are any > that dump UTF-16, but I wouldn't be surprised if there weren't. How hard > would it be to add them? Remeber that C++11 has char16_t. I will bring this question to the LTTNG/perf mailing lists and ask for guidance there. I imagine that xperf would support UTF16, considering that the Windows API uses it (right?). I will try to get input from an expert on that platform. > > One way to handle the above case would be only doing the qUtf8Printable > > call when the trace point is enabled, but afaik that checking also is not > > done for free, and also makes the consumer code harder to write. > > Right. Don't annotate with function calls. Annotate variables only. You can > mostly do this by adding an unreachable rvalue-ref overload, like qAsConst. > > > https://github.com/milianw/bench_qt/blob/master/bench_qstring/ > > bench_qstring.cpp#L118 > > > > Would something like this be acceptable for upstream? E.g. change > > qUtf8Printable to not allocate memory for up to PATH_MAX chars or similar, > > and otherwise fallback to the slow QByteArray (or simply truncate, which > > would be an option for trace points actually). > > That change is interesting and we could accept it, but I still wouldn't want > it used in tracepoints. You avoid the allocation, but you're still > converting to UTF-8. Your benchmark doesn't show it because your strings > are probably very short and our UTF-8 algorithm is very optimised. It is > dwarfed by the memory allocation. OK, I will upstream this change independently of whether it will be used for trace points or not then. > No, instead the policy should be that we annotate only direct variables or > values that can be computed easily from the variable itself (like > constData()). I think this will severely limit the value of the trace points - even if we can find a way to print UTF-16 "cheaply" and thus can handle QString. I will try and see if there is maybe a way to opt out of calling the potentially costly functions in a nice to use API with minimal/no overhead and report my findings back to this list then. I have something like the category-based logging in mind ATM, where (afaik?) we short-circuit constructs like qCDebug(foo) << bar() << asdf(); when the category is not enabled One example where "only" QString is not enough: the various cases where we operate with QUrl (such as QNetworkManager, or stuff in Qt Declarative)... In the customer project of ours, I wrote a wrapper around my "fast" UTF-8 conversion and then use a static buffer with snprintf, such that you can use it with: TraceScope<...> ts("url: " QURL_TRACE_FORMAT, qUrlTraceFormat(myQUrl)); Ugly, but faster than constructing a QString for the QUrl first. CTF (the common trace format) also seems to support structs, so we could do better there, i.e. get a cheap wrapper around the direct data getters of QUrl (protocol, host, port, user, path, query, fragment,....). But I'd have to check up what xperf has for that, and how to use it with sdt.h... So, overly long email - sorry for that. tl;dr; I will do more evaluation of the underlying trace point APIs to figure out how we can do this without cost Bye, and thanks for the valuable input already -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From thiago.macieira at intel.com Tue Sep 6 20:52:15 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Sep 2016 11:52:15 -0700 Subject: [Development] A faster qUtf8Printable for static trace points? In-Reply-To: <3169544.9zaPPYYkHl@agathebauer> References: <1757662.KxShe8fSTD@agathebauer> <2378524.1HAKQvlkHk@tjmaciei-mobl1> <3169544.9zaPPYYkHl@agathebauer> Message-ID: <1501108.8AaKfgirB0@tjmaciei-mobl1> Em terça-feira, 6 de setembro de 2016, às 20:48:39 PDT, Milian Wolff escreveu: > > That change is interesting and we could accept it, but I still wouldn't > > want it used in tracepoints. You avoid the allocation, but you're still > > converting to UTF-8. Your benchmark doesn't show it because your strings > > are probably very short and our UTF-8 algorithm is very optimised. It is > > dwarfed by the memory allocation. > > OK, I will upstream this change independently of whether it will be used > for trace points or not then. I said it could be, but I frankly don't like it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rich at kde.org Tue Sep 6 21:05:26 2016 From: rich at kde.org (Richard Moore) Date: Tue, 6 Sep 2016 20:05:26 +0100 Subject: [Development] Qt Network Maintainership Changes Message-ID: Hi All, As some of you may know, I'm planning to step down as maintainer of Qt Network. This is because now that the Qt company has people in a position to work on the network stack full time I think it makes much more sense for them to be the maintainer - it doesn't mean I'll be moving away from working on Qt (in fact I hope it will mean I'll have more time to actually get things done as a result). I'd like to nominate Timur as my replacement - he's already spent an inordinate amount of time fixing bugs, to say nothing of adding support for HTTP/2 so I'm sure things are in good hands. https://codereview.qt-project.org/#/q/owner:%22Timur+Pocheptsov%22,n,z On a similar note, I'd like to nominate Jesús Fernández as the maintainer of the QtNetworkAuth module - he wrote it after all! https://codereview.qt-project.org/#/q/owner:%22Jesus+Fernandez%22,n,z I plan to continue working on the network code myself too, this is more an administrative change than anything else. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From milian.wolff at kdab.com Tue Sep 6 21:09:47 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Tue, 06 Sep 2016 21:09:47 +0200 Subject: [Development] A faster qUtf8Printable for static trace points? In-Reply-To: <1501108.8AaKfgirB0@tjmaciei-mobl1> References: <1757662.KxShe8fSTD@agathebauer> <3169544.9zaPPYYkHl@agathebauer> <1501108.8AaKfgirB0@tjmaciei-mobl1> Message-ID: <3486609.VavCJCRQ7o@agathebauer> On Dienstag, 6. September 2016 11:52:15 CEST Thiago Macieira wrote: > Em terça-feira, 6 de setembro de 2016, às 20:48:39 PDT, Milian Wolff escreveu: > > > That change is interesting and we could accept it, but I still wouldn't > > > want it used in tracepoints. You avoid the allocation, but you're still > > > converting to UTF-8. Your benchmark doesn't show it because your strings > > > are probably very short and our UTF-8 algorithm is very optimised. It is > > > dwarfed by the memory allocation. > > > > OK, I will upstream this change independently of whether it will be used > > for trace points or not then. > > I said it could be, but I frankly don't like it. Hehe ok :) I'll see if I find the time to put it up for review anyways so it's documented at least and won't be lost. Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From thiago.macieira at intel.com Tue Sep 6 21:51:30 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Sep 2016 12:51:30 -0700 Subject: [Development] Notes on QtCore session @ QCS2016 In-Reply-To: References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> <1990526.ruIhrjze9J@tjmaciei-mobl1> Message-ID: <3493418.kLUO9Az9UQ@tjmaciei-mobl1> Em terça-feira, 6 de setembro de 2016, às 17:10:19 PDT, Kevin Kofler escreveu: > Thiago Macieira wrote: > > It was a *choice* not to depend on the C++ Standard Library ABI for > > features outside of the language support. The choice was made during Qt > > 5.0 development, in response to the -no-stl option being removed. It was > > originally done so that applications and libraries on Apple platforms > > could choose to use libstdc++ or libc++: it was common back in 2012 that > > applications would need to link to proprietary libraries that used > > libstdc++ and could not easily be recompiled. That choice extended to GCC > > 4.9 & 5.0 that broke compatibility, and it turned out to be a bonus for us > > because Qt-only applications did not need to be recompiled. > > I think it was a mistake to remove -no-stl to begin with, and that Qt API > should not be littered with ugly std:: APIs, not just for ABI reasons, but > also for API (consistency) reasons. I disagree, even though the build times have significantly increased. > Why can't Qt continue to offer better Q* equivalents as it has always done? > What benefit does it bring to users to deprecate nice APIs for less nice > ones just because the latter are part of the compiler? Marc will have more reasons, but I'll just give you one: iterators. Why should we not have the iterator tags? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 6 21:59:12 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Sep 2016 12:59:12 -0700 Subject: [Development] Qt Network Maintainership Changes In-Reply-To: References: Message-ID: <2162548.prP01YVRb8@tjmaciei-mobl1> Em terça-feira, 6 de setembro de 2016, às 20:05:26 PDT, Richard Moore escreveu: > As some of you may know, I'm planning to step down as maintainer of Qt > Network. This is because now that the Qt company has people in a position > to work on the network stack full time I think it makes much more sense for > them to be the maintainer - it doesn't mean I'll be moving away from > working on Qt (in fact I hope it will mean I'll have more time to actually > get things done as a result). I'd like to nominate Timur as my replacement > - he's already spent an inordinate amount of time fixing bugs, to say > nothing of adding support for HTTP/2 so I'm sure things are in good hands. > > https://codereview.qt-project.org/#/q/owner:%22Timur+Pocheptsov%22,n,z +1 for Timur. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Morten.Sorvig at qt.io Wed Sep 7 11:45:10 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Wed, 7 Sep 2016 09:45:10 +0000 Subject: [Development] Qt Network Maintainership Changes In-Reply-To: References: Message-ID: > On 6 Sep 2016, at 21:05, Richard Moore wrote: > > Hi All, > > As some of you may know, I'm planning to step down as maintainer of Qt Network. This is because now that the Qt company has people in a position to work on the network stack full time I think it makes much more sense for them to be the maintainer - it doesn't mean I'll be moving away from working on Qt (in fact I hope it will mean I'll have more time to actually get things done as a result). I'd like to nominate Timur as my replacement - he's already spent an inordinate amount of time fixing bugs, to say nothing of adding support for HTTP/2 so I'm sure things are in good hands. > > https://codereview.qt-project.org/#/q/owner:%22Timur+Pocheptsov%22,n,z > > On a similar note, I'd like to nominate Jesús Fernández as the maintainer of the QtNetworkAuth module - he wrote it after all! > > https://codereview.qt-project.org/#/q/owner:%22Jesus+Fernandez%22,n,z +1 to both Timur and Jesús from me. Morten From stephen.kelly at ableton.com Wed Sep 7 11:35:01 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Wed, 7 Sep 2016 11:35:01 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <3e351a3d-ed09-8bba-3496-b232814dde01@gmail.com> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <20160906175908.GA3278@klara.mpi.htwm.de> <3e351a3d-ed09-8bba-3496-b232814dde01@gmail.com> Message-ID: <228ec0c3-4609-9346-3a84-7e466e5e3b03@ableton.com> On 06/09/16 20:30, Cristian Adam wrote: > > Maybe "bad feedback" is strong, but it was non constructive and lead > to the removal of the Qbs generator. > To clarify even further: the contribution was wip, the contributor was surprised at it being merged, and happy with it being reverted: https://github.com/Kitware/CMake/pull/145#issuecomment-104292606 Thanks, -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.kelly at ableton.com Wed Sep 7 12:16:08 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Wed, 7 Sep 2016 12:16:08 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <3e351a3d-ed09-8bba-3496-b232814dde01@gmail.com> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <20160906175908.GA3278@klara.mpi.htwm.de> <3e351a3d-ed09-8bba-3496-b232814dde01@gmail.com> Message-ID: <7d837a0b-657e-b546-e13a-77e3d2982175@ableton.com> On 06/09/16 20:30, Cristian Adam wrote: > > Maybe "bad feedback" is strong, but it was non constructive and lead > to the removal of the Qbs generator. > To clarify even further: the contribution was wip, the contributor was surprised at it being merged, and happy with it being reverted: https://github.com/Kitware/CMake/pull/145#issuecomment-104292606 Thanks, -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Wed Sep 7 13:06:23 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 7 Sep 2016 11:06:23 +0000 Subject: [Development] Qt Network Maintainership Changes In-Reply-To: References: Message-ID: On Sep 7, 2016, at 11:45 AM, Morten Sorvig > wrote: On 6 Sep 2016, at 21:05, Richard Moore > wrote: Hi All, As some of you may know, I'm planning to step down as maintainer of Qt Network. This is because now that the Qt company has people in a position to work on the network stack full time I think it makes much more sense for them to be the maintainer - it doesn't mean I'll be moving away from working on Qt (in fact I hope it will mean I'll have more time to actually get things done as a result). I'd like to nominate Timur as my replacement - he's already spent an inordinate amount of time fixing bugs, to say nothing of adding support for HTTP/2 so I'm sure things are in good hands. https://codereview.qt-project.org/#/q/owner:%22Timur+Pocheptsov%22,n,z On a similar note, I'd like to nominate Jesús Fernández as the maintainer of the QtNetworkAuth module - he wrote it after all! https://codereview.qt-project.org/#/q/owner:%22Jesus+Fernandez%22,n,z +1 to both Timur and Jesús from me. Also what Morten said. Morten _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Wed Sep 7 10:26:44 2016 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 07 Sep 2016 10:26:44 +0200 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <201608161048.27861.marc.mutz@kdab.com> References: <201608121052.52787.marc.mutz@kdab.com> <1626069.GIB9faJcai@maurice> <201608161048.27861.marc.mutz@kdab.com> Message-ID: <1755764.blp8L9eGak@maurice> On Dienstag, 16. August 2016 10:48:27 CEST Marc Mutz wrote: > On Tuesday 16 August 2016 10:06:09 Olivier Goffart wrote: > > On Freitag, 12. August 2016 09:02:08 CEST Thiago Macieira wrote: > [...] > > > > I agree with Marc, we should allow fixing bugs besides those that are > > > critical or regressions. Even the regression category will change: once > > > 5.6 is a year old, we'll start making judgement calls that we "had > > > better leave it this way". > > > > > > I would prefer we do fix bugs that we can, so long as we can reasonably > > > say that they are reasonably safe of causing further issues. At least > > > for the next six months. > > > > > > We should probably become progressively stricter as the branch becomes > > > older. > > > > Any rationale for this way? > > I disagree that we should fix non-critical bugs or regression. > > > > If the bug has been there for several years already and the user could > > live > > with it, they can continue to work it around unti they upgrade to the > > newer > > Qt. It can be seen as a feature. > > > > Our product is the latest version of Qt. LTS means previous versions stay > > supported, not actively developped. > > The rationale IMHO is a direct consequence of the target audience of an LTS. > What's the purpose of an LTS? Why do we jump through hoops to mainain an > outdated codebase for three year? The purpose of the LTS is too keep that version working. The reason we should limit the changes to critical change is so than "jumping through hoops" gets easier. Every patch we put there instead of in a upper branch makes more work of merging, handling regressions causing by this patch, having to work with an outdated code base. (In fact, I think maybe we should stop merging 5.6. Backporting (chery-pick) proven patches might be more effective.) > Because the LTS is for users who _cannot_ update to newer Qts (for whatever > reason, dropped platforms just being one of them). Pointing them to a newer > Qt where their bug is fixed is not going to help them one bit. You could say the same about any new feature. An user requesting a feature might still be on LTS and pointing them at the feature in a newer version might not be helpfull. But in the end, we want our users to upgrade. So they can reconsider the reason they cannot upgrade while weighing the new features/ bugfixes in the equation. The question also is what is a bug fix? The change in question is this one: https://codereview.qt-project.org/167238 The bug was already existing in Qt 4.x since the feature was introduced. People have been able to wait so many years, they can continue waiting. In fact, this "bugfix" is a "feature". The change looks harmless, but maybe this suddenly cause augly flickering in some cases and we don't know. I've seen enough trivial patches making feature unusable. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From alexander.blasche at qt.io Wed Sep 7 07:55:27 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Wed, 7 Sep 2016 05:55:27 +0000 Subject: [Development] Qt Network Maintainership Changes In-Reply-To: References: Message-ID: >From: Development on behalf of Richard Moore >I'd like to nominate Timur as my replacement - he's already spent an inordinate amount of time fixing bugs, >to say nothing of adding support for HTTP/2 so I'm sure things are in good hands. +1 -- Alex From viktor.engelmann at qt.io Wed Sep 7 09:56:52 2016 From: viktor.engelmann at qt.io (Viktor Engelmann) Date: Wed, 7 Sep 2016 09:56:52 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <773d1eb5-4d07-e114-4e64-c53b69ced1c7@qt.io> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <229681473083529@web27g.yandex.ru> <2172009.Q5xAuZtDf9@tjmaciei-mobl1> <773d1eb5-4d07-e114-4e64-c53b69ced1c7@qt.io> Message-ID: <4a68ec99-b15e-2e3e-efb3-9dfb6043b0ca@qt.io> I don't think the joke is racist or sexist. The protagonists happen to be female, but the gender has nothing to do with the punchline (at least I don't think so). I have read the same joke with blond men and with clerks. You could take anyone - and that is what makes the joke in-offensive for anyone (IMO). I find it more excluding and off-putting to be called racist/sexist /*publicly*/ for posting such a harmless joke. If you have any problem, you could come and talk to me personally first, before pointing fingers. Am 06.09.2016 um 16:29 schrieb Ulf Hermann: >> It kind of reminds me of this joke: >> http://www.ebaumsworld.com/jokes/blond-hole-diggers/80432143/ > > Do we have a policy about inappropriate content posted to mailing > lists and similar communication channels? If not, I think we should > agree on banning at least some basic things like racism or sexism. We > should be inclusive after all, and not scare off any potential > contributors. > > regards, > Ulf -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin Viktor.Engelmann at qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Qt World Summit 2016 Qt World Summit 2016 | Pier 27, San Francisco, CA Experience Exponential Potential on October 18-20 www.qtworldsummit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_logo_with_text_green_rgb_400x141.png Type: image/png Size: 16849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_facebook.png Type: image/png Size: 1407 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_twitter.png Type: image/png Size: 1778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_linkedin.png Type: image/png Size: 1532 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_googleplus.png Type: image/png Size: 1957 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_youtube.png Type: image/png Size: 1610 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qtworldsummit2016_banner.jpg Type: image/jpeg Size: 35183 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: viktor_engelmann.vcf Type: text/x-vcard Size: 271 bytes Desc: not available URL: From Friedemann.Kleint at qt.io Wed Sep 7 08:37:01 2016 From: Friedemann.Kleint at qt.io (Friedemann Kleint) Date: Wed, 7 Sep 2016 08:37:01 +0200 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 Message-ID: <57CFB58D.2060200@qt.io> Hi, the notes are at: https://wiki.qt.io/QtCS2016_Managing_Qt_Branches * Number of existing branches (5.6LTS, 5.7.,5.8 dev) causes a number of problems ** Strain on COIN which also has release branches ** Merging becomes increasingly difficult ** Hard to manage for individual developers * Branches ** Close 5.7 after 5.7.1. We then have LTS, stable, dev. ** After 5.7 is closed and sanity bot is upgraded (to handle cherry-picking), go into cherrypicking mode for 5.6. Developer is responsible for doing the cherrypicking ** Cherry-picking technicalities need to be figured out: Let sanity bot verify source ("cherrypicked from") the SHA1 ** In the future, exact time for closing stable branches will be discussed for each one individually * Submit Policy ** Target which branch? ** Long Term Support (5.6) Branch *** Initially equal to stable, increasingly strict over time: Fix only severe issues, avoid regressions. *** Bugs: For example, P2 for the first year, P1 for year 2, rest Security. Try to further objectify that: Jedrzei + Friedemann *** Tests: Fix/stabilize tests itself, add tests *** No performance improvements unless really significant (relevant/reduces O(n)) *** Upgrading 3rd party (including WebEngine) *** Support new OS versions unless introducing new platforms, no rewrite of QPA *** No cleanups, positively: -> dev *** To aid customers with issues, patches for issues in LTS to be locally applied can be provided, but the fixes will be pushed to higher versions of Qt. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH From bogdan at kdab.com Wed Sep 7 09:19:29 2016 From: bogdan at kdab.com (BogDan Vatra) Date: Wed, 07 Sep 2016 10:19:29 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> Message-ID: <2696303.4YcVdbDnqi@debian> On marți, 6 septembrie 2016 17:35:03 EEST Cristian Adam wrote: > On Tue, Sep 6, 2016 at 5:14 PM, Kevin Kofler wrote: > > I guess somebody could even get CMake to write Qbs files, it would just be > > one more generator. :-) > > This was done already > cb81da934c0>, but it was removed from CMake due to bad feedback from > Qt Creator people. > Ha ha ha! The guy who implemented this didn't know that QBS is not better than cmake when it comes to give proper information to IDE which is so needed to have proper syntax highlighting and code completion. For those who don't know yet, QBS *DOESN'T* provide the necessary info to the IDE: - no compiler preprocessor defines: https://bugreports.qt.io/browse/QBS-903 even is hallucinating this bug was closed as invalid :) there is a pending patch https://codereview.qt-project.org/#/c/122000/ which might fix it but we'll soon celebrate its 2nd anniversary in gerrit :) - no system includes paths: https://bugreports.qt.io/browse/QBS-904 - no c/cpp flags: https://bugreports.qt.io/browse/QBS-905 Having said that, why on earth to create such a generator when QBS support in QtCreator is the same (or even worst) than cmake's one? DISCLAIMER: I was one of the biggest fans of this project, I had so much hopes for it, but when you have high hopes you'll also have high disappoints :) . I'll try to summarize my thought on QBS: - it still has HUGE potential, it has a great easy to use & learn syntax -it has great features that you can't find in other build systems (e.g. it can build multiple ABIs/platforms at once). - personally I don't mind that it depends on Qt, what I do mind is that it depends on dead Qt modules (e.g. QtScript, it has it's own (outdated?) QML parser fork). Other cool build systems (e.g. gradle) download half of the internet before they start, so, a build system that depends on a library like Qt is not that bad. As I said it has huge potential and in the future Qt will help to implement cool features like: automatically download/clone/checkout 3rd partly libs, etc. - QBS was introduced to us as a build system designed with tooling in mind, sadly that crucial aspect was forgotten (the above bugs prove what I'm saying). - QBS developers don't use it in large projects with lots of dependencies, with situations when you need to build & run tools to generate code, when you need to build and/or run tools to check dependencies, when you need to test compiler flags, etc. (apart from QtCreator which has just a few dependencies). You might think that they started to use QBS to compile Qt to test all these things, well, think again, that work was started by a brave contributor (Andrew Knight) who is not a QBS developer! After the work was started, QBS developers jumped in. - is QBS finished and ready to replace cmake/qmake/gradle/etc.? IMHO no! There are not too many remaining features to implement, but if the development continues at current speed I'm afraid we'll see people walking on Mars before we'll see QBS finished... I hope that trying to build Qt with QBS will motivate QBS developers to implement these features faster. Cheers, BogDan. From peter-qt at hartmann.tk Wed Sep 7 10:18:10 2016 From: peter-qt at hartmann.tk (Peter Hartmann) Date: Wed, 7 Sep 2016 10:18:10 +0200 Subject: [Development] Qt Network Maintainership Changes In-Reply-To: References: Message-ID: <61077804-0ce6-a183-3bd4-bd8ad4d58af6@hartmann.tk> +1 for Timur I am hereby officially stepping down as co-maintainer as well; I was in fact not working any more on QtNetwork for quite some time already, because my day job does not really allow for it... Feel free to ping me on IRC or add me to a code review and I might get back to you though. Peter On 06.09.2016 21:05, Richard Moore wrote: > Hi All, > > As some of you may know, I'm planning to step down as maintainer of Qt > Network. This is because now that the Qt company has people in a > position to work on the network stack full time I think it makes much > more sense for them to be the maintainer - it doesn't mean I'll be > moving away from working on Qt (in fact I hope it will mean I'll have > more time to actually get things done as a result). I'd like to > nominate Timur as my replacement - he's already spent an inordinate > amount of time fixing bugs, to say nothing of adding support for > HTTP/2 so I'm sure things are in good hands. > > https://codereview.qt-project.org/#/q/owner:%22Timur+Pocheptsov%22,n,z > > On a similar note, I'd like to nominate Jesús Fernández as the > maintainer of the QtNetworkAuth module - he wrote it after all! > > https://codereview.qt-project.org/#/q/owner:%22Jesus+Fernandez%22,n,z > > I plan to continue working on the network code myself too, this is > more an administrative change than anything else. > > Cheers > > Rich. > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Tue Sep 6 23:13:30 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 6 Sep 2016 23:13:30 +0200 Subject: [Development] Qt Network Maintainership Changes In-Reply-To: <2162548.prP01YVRb8@tjmaciei-mobl1> References: <2162548.prP01YVRb8@tjmaciei-mobl1> Message-ID: <201609062313.30744.marc.mutz@kdab.com> On Tuesday 06 September 2016 21:59:12 Thiago Macieira wrote: > Em terça-feira, 6 de setembro de 2016, às 20:05:26 PDT, Richard Moore > > escreveu: > > As some of you may know, I'm planning to step down as maintainer of Qt > > Network. This is because now that the Qt company has people in a position > > to work on the network stack full time I think it makes much more sense > > for them to be the maintainer - it doesn't mean I'll be moving away from > > working on Qt (in fact I hope it will mean I'll have more time to > > actually get things done as a result). I'd like to nominate Timur as my > > replacement - he's already spent an inordinate amount of time fixing > > bugs, to say nothing of adding support for HTTP/2 so I'm sure things are > > in good hands. > > > > https://codereview.qt-project.org/#/q/owner:%22Timur+Pocheptsov%22,n,z > > +1 for Timur. +1 here, too -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From annulen at yandex.ru Wed Sep 7 13:27:33 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 07 Sep 2016 14:27:33 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <2696303.4YcVdbDnqi@debian> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <2696303.4YcVdbDnqi@debian> Message-ID: <311981473247653@web29g.yandex.ru> 07.09.2016, 14:17, "BogDan Vatra" : > On marți, 6 septembrie 2016 17:35:03 EEST Cristian Adam wrote: >>  On Tue, Sep 6, 2016 at 5:14 PM, Kevin Kofler wrote: >>  > I guess somebody could even get CMake to write Qbs files, it would just be >>  > one more generator. :-) >> >>  This was done already >>  >  cb81da934c0>, but it was removed from CMake due to bad feedback from >>  Qt Creator people. > > Ha ha ha! > The guy who implemented this didn't know that QBS is not better than cmake > when it comes to give proper information to IDE which is so needed to have > proper syntax highlighting and code completion. For those who don't know yet, > QBS *DOESN'T* provide the necessary info to the IDE: > - no compiler preprocessor defines: https://bugreports.qt.io/browse/QBS-903 > even is hallucinating this bug was closed as invalid :) there is a pending > patch https://codereview.qt-project.org/#/c/122000/ which might fix it but > we'll soon celebrate its 2nd anniversary in gerrit :) > - no system includes paths: https://bugreports.qt.io/browse/QBS-904 > - no c/cpp flags: https://bugreports.qt.io/browse/QBS-905 > > Having said that, why on earth to create such a generator when QBS support in > QtCreator is the same (or even worst) than cmake's one? > > DISCLAIMER: I was one of the biggest fans of this project, I had so much hopes > for it, but when you have high hopes you'll also have high disappoints :) . > I'll try to summarize my thought on QBS: > - it still has HUGE potential, it has a great easy to use & learn syntax > > -it has great features that you can't find in other build systems (e.g. it can > build multiple ABIs/platforms at once). For the record, premake can do it as well. > > - personally I don't mind that it depends on Qt, what I do mind is that it > depends on dead Qt modules (e.g. QtScript, it has it's own (outdated?) QML > parser fork). Other cool build systems (e.g. gradle) download half of the > internet before they start, so, a build system that depends on a library like > Qt is not that bad. As I said it has huge potential and in the future Qt will > help to implement cool features like: automatically download/clone/checkout > 3rd partly libs, etc. > > - QBS was introduced to us as a build system designed with tooling in mind, > sadly that crucial aspect was forgotten (the above bugs prove what I'm > saying). > > - QBS developers don't use it in large projects with lots of dependencies, > with situations when you need to build & run tools to generate code, when you > need to build and/or run tools to check dependencies, when you need to test > compiler flags, etc. (apart from QtCreator which has just a few dependencies). > You might think that they started to use QBS to compile Qt to test all these > things, well, think again, that work was started by a brave contributor > (Andrew Knight) who is not a QBS developer! After the work was started, QBS > developers jumped in. > > - is QBS finished and ready to replace cmake/qmake/gradle/etc.? IMHO no! There > are not too many remaining features to implement, but if the development > continues at current speed I'm afraid we'll see people walking on Mars before > we'll see QBS finished... I hope that trying to build Qt with QBS will motivate > QBS developers to implement these features faster. > > Cheers, > BogDan. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From chgans at gna.org Wed Sep 7 11:50:06 2016 From: chgans at gna.org (Ch'Gans) Date: Wed, 7 Sep 2016 21:50:06 +1200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <8d39752d-9f26-1077-86fa-a0a10177fbf7@qt.io> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <229681473083529@web27g.yandex.ru> <2172009.Q5xAuZtDf9@tjmaciei-mobl1> <8d39752d-9f26-1077-86fa-a0a10177fbf7@qt.io> Message-ID: [Keeping discussion posted on ML] On 7 September 2016 at 20:08, Viktor Engelmann wrote: > Really? I haven't checked out Qbs yet, but that sounds like the build > system I was looking for. > > So maybe I don't have to write my own build tool after all :-D > Give it a try, but beware: Qbs is addictive. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Sep 7 11:01:32 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 7 Sep 2016 11:01:32 +0200 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <1755764.blp8L9eGak@maurice> References: <201608121052.52787.marc.mutz@kdab.com> <201608161048.27861.marc.mutz@kdab.com> <1755764.blp8L9eGak@maurice> Message-ID: <201609071101.32455.marc.mutz@kdab.com> On Wednesday 07 September 2016 10:26:44 Olivier Goffart wrote: > On Dienstag, 16. August 2016 10:48:27 CEST Marc Mutz wrote: > > On Tuesday 16 August 2016 10:06:09 Olivier Goffart wrote: > > > On Freitag, 12. August 2016 09:02:08 CEST Thiago Macieira wrote: > > [...] > > > > > > I agree with Marc, we should allow fixing bugs besides those that are > > > > critical or regressions. Even the regression category will change: > > > > once 5.6 is a year old, we'll start making judgement calls that we > > > > "had better leave it this way". > > > > > > > > I would prefer we do fix bugs that we can, so long as we can > > > > reasonably say that they are reasonably safe of causing further > > > > issues. At least for the next six months. > > > > > > > > We should probably become progressively stricter as the branch > > > > becomes older. > > > > > > Any rationale for this way? > > > I disagree that we should fix non-critical bugs or regression. > > > > > > If the bug has been there for several years already and the user could > > > live > > > with it, they can continue to work it around unti they upgrade to the > > > newer > > > Qt. It can be seen as a feature. > > > > > > Our product is the latest version of Qt. LTS means previous versions > > > stay supported, not actively developped. > > > > The rationale IMHO is a direct consequence of the target audience of an > > LTS. What's the purpose of an LTS? Why do we jump through hoops to > > mainain an outdated codebase for three year? > > The purpose of the LTS is too keep that version working. You're evading with a null argument: Keep it working _for_ _whom_? > The reason we should limit the changes to critical change is so than > "jumping through hoops" gets easier. Every patch we put there instead of > in a upper branch makes more work of merging, handling regressions causing > by this patch, having to work with an outdated code base. > > (In fact, I think maybe we should stop merging 5.6. Backporting > (chery-pick) proven patches might be more effective.) IMO, that's nonsense. I still remember this from 4.8. No thanks. Why work against the (very good!) revision control system? Anyway, seeing as neither you nor me are doing merges, I guess we should let that particular topic in peace for Liang and Eddy to comment on, if they so wish. > > Because the LTS is for users who _cannot_ update to newer Qts (for > > whatever reason, dropped platforms just being one of them). Pointing > > them to a newer Qt where their bug is fixed is not going to help them > > one bit. > > You could say the same about any new feature. Of course not. A user needs to write code to use a new feature. A bugfix affects existing code. > An user requesting a feature > might still be on LTS and pointing them at the feature in a newer version > might not be helpfull. But in the end, we want our users to upgrade. So > they can reconsider the reason they cannot upgrade while weighing the new > features/ bugfixes in the equation. > > > The question also is what is a bug fix? You seem to want to imply that bug fixes are just some form of feature. If you do, then I disagree. A bug fix is a mismatch between documented[1] and actual behaviour. The fix _either_ fixes the docs _or_ the code, but not both. Features don't have this property: You change the docs _and_ the code. So that particular line is easy to draw, even though, of course, there's, as always, a grey area. [1] Documented as in qdoc, or implied by reasonable expectation, e.g. "works like in a native application", "does not invoke UB". > The change in question is this one: > https://codereview.qt-project.org/167238 > The bug was already existing in Qt 4.x since the feature was introduced. > People have been able to wait so many years, they can continue waiting. > In fact, this "bugfix" is a "feature". No. It does not change both docs and code, only code, and makes Qt behave as a native application (try it in IE/Edge, e.g.). > The change looks harmless, but maybe this suddenly cause augly flickering > in some cases and we don't know. I've seen enough trivial patches making > feature unusable. If that should be the case, we will add another patch. We don't release 5.6 immediately after each commit, so there's some time in which regressions can be discovered. In general, it makes no sense to not fix bugs because you might introduce bugs. Even if you add one bug per two bugs fixed, you end up with less bugs at the end. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From chgans at gna.org Wed Sep 7 00:16:51 2016 From: chgans at gna.org (Ch'Gans) Date: Wed, 7 Sep 2016 10:16:51 +1200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <229681473083529@web27g.yandex.ru> <2172009.Q5xAuZtDf9@tjmaciei-mobl1> Message-ID: On 7 September 2016 at 01:47, Viktor Engelmann wrote: > > Am 06.09.2016 um 06:52 schrieb Ch'Gans: > > On 6 September 2016 at 16:20, Thiago Macieira wrote: > > Which is, in itself, an argument: why learn yet another buildsystem? > > ... > > Why learn yet another programming language? > > ... > > An average software developer knows about, says 10 to 20 programming > languages, maybe even more depending on the definition of "language". > Why should he/she knows just one build system? > > Chris > > > My 2 cents: I want to spend my time on programming = being productive - > Not waste my time fighting against an incredibly stupid build system... > > In my opinion, build systems in general haven't matured the way compilers > have. Using classes and polymorphism, you can easily explain arbitrarily > complex situations to compilers. I have yet to see a build system that > understands more complex situations than "FILE1 IS OLDER THAN FILE2". > This is the Makefile approach, the whole Makefile thing is based on "FILE1 IS OLDER THAN FILE2" (and so is CMake). I think that Qbs is way more than this. Maybe have a quick look at the documentation to realise how the approach is completely different. Qbs understand the concept of classes and polymorphism. In my projects, I define a "base class" (a Product in Qbs terminology), and I can derive this product into more specific product, of course derived products inherit from their base behaviours and properties, and of course i can overwrite properties (inc, full overwrite, append, prepend, transform, ...). Qbs is really different. See eg. http://doc.qt.io/qbs/language-introduction.html They don't even have the slightest understanding of the commands they > execute - they just slap some raw strings together (which YOU have to > provide) and pass them to a shell. Oh, these raw strings were for a > different OS? Or even just a different version of the same compiler on the > same OS? well too bad... > > It kind of reminds me of this joke: > http://www.ebaumsworld.com/jokes/blond-hole-diggers/80432143/ > Will have to check this one at home, corporate "firewall" tells me: "404: Access denied - Adult detected" ... Chris > > > Viktor > > -- > > > Viktor Engelmann > Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > Viktor.Engelmann at qt.io > +49 151 26784521 > http://qt.io > > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B > > > > > > [image: Qt World Summit 2016] > Qt World Summit 2016 | Pier 27, San Francisco, CA > Experience Exponential Potential on October 18-20 > www.qtworldsummit.com > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_linkedin.png Type: image/png Size: 1532 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_logo_with_text_green_rgb_400x141.png Type: image/png Size: 16849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_googleplus.png Type: image/png Size: 1957 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_facebook.png Type: image/png Size: 1407 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_twitter.png Type: image/png Size: 1778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_youtube.png Type: image/png Size: 1610 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qtworldsummit2016_banner.jpg Type: image/jpeg Size: 35183 bytes Desc: not available URL: From bstottle at ford.com Wed Sep 7 13:55:32 2016 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Wed, 7 Sep 2016 11:55:32 +0000 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <1755764.blp8L9eGak@maurice> References: <201608121052.52787.marc.mutz@kdab.com> <1626069.GIB9faJcai@maurice> <201608161048.27861.marc.mutz@kdab.com> <1755764.blp8L9eGak@maurice> Message-ID: <8B18366A-2188-4F1B-BFC9-F1C7425D7192@ford.com> On 9/7/16, 4:26 AM, "Development on behalf of Olivier Goffart" wrote: >But in the end, we want our users to upgrade. So they >can reconsider the reason they cannot upgrade while weighing the new features/ >bugfixes in the equation. Maybe I’m being overly sensitive. Having worked in aerospace and automotive, I actually find the above comments offensive... >The question also is what is a bug fix? >The change in question is this one: >https://codereview.qt-project.org/167238 >The bug was already existing in Qt 4.x since the feature was introduced. >People have been able to wait so many years, they can continue waiting. >In fact, this "bugfix" is a "feature". >The change looks harmless, but maybe this suddenly cause augly flickering in >some cases and we don't know. I've seen enough trivial patches making feature >unusable. ... and completely at odds with these comments. I’m not sure how you can cite the risk associated with even small changes and at the same time suggest the solution is moving to the current version of Qt which has significantly more changes? I do understand where you are coming from - there are limited resources and supporting multiple versions means some of those resources aren’t available for other work. At the same time, providing an LTS version was a commitment made by Qt. Yet it is looking more like a nuisance to be given as little attention as possible. I’d caution this isn’t the way to appeal to the audiences that care about long term stability. Regards, Brett From markus at woboq.com Wed Sep 7 14:21:41 2016 From: markus at woboq.com (Markus Goetz) Date: Wed, 7 Sep 2016 14:21:41 +0200 Subject: [Development] Qt Network Maintainership Changes In-Reply-To: References: Message-ID: On 06/09/16 21:05, Richard Moore wrote: > I'd like to nominate Timur as my replacement +1 > > On a similar note, I'd like to nominate Jesús Fernández as the > maintainer of the QtNetworkAuth module > +1 -- Woboq GmbH | https://woboq.com/ Geschäftsführer: Markus Goetz, Olivier Goffart Hermannstr. 134, 12051 Berlin, Germany Handelsregister: Amtsgericht Berlin (Charlottenburg) HRB 137795 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Wed Sep 7 14:27:03 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 7 Sep 2016 12:27:03 +0000 Subject: [Development] Maintainers: your action needed Message-ID: Hi all (maintainers), We in the release team did initial versions of change files for Qt 5.6.2 release (to those modules where it was missing). Please take those over & finalize those as soon as possible; We are planning to release Qt 5.6.2 already during next week. Changes are pushed to gerrit as WIP so please just add/modify content, get the change approved & we will then stage those in. br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Wed Sep 7 15:08:29 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Wed, 7 Sep 2016 13:08:29 +0000 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <8B18366A-2188-4F1B-BFC9-F1C7425D7192@ford.com> References: <201608121052.52787.marc.mutz@kdab.com> <1626069.GIB9faJcai@maurice> <201608161048.27861.marc.mutz@kdab.com> <1755764.blp8L9eGak@maurice> <8B18366A-2188-4F1B-BFC9-F1C7425D7192@ford.com> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Stottlemyer, > Brett (B.S.) > Sent: keskiviikkona 7. syyskuuta 2016 14.56 > To: development at qt-project.org > Subject: Re: [Development] Which changes are suitable for 5.6? > > I do understand where you are coming from - there are limited resources > and supporting multiple versions means some of those resources aren’t > available for other work. At the same time, providing an LTS version was a > commitment made by Qt. Yet it is looking more like a nuisance to be given as > little attention as possible. I’d caution this isn’t the way to appeal to the > audiences that care about long term stability. > Hi, By simply looking into the amount of changes we have already included to Qt 5.6.1 and what is coming in Qt 5.6.2 you can easily see that it has received a lot of attention. LTS is about stability. Every change is possible to cause also harm to someone. It is not good to put risk item such as behavior changes or minor bug fixes into the LTS version, as there are prone to break things. There is no absolute right or wrong, so it is very beneficial to discuss these matter in the mailing list. There were also discussions related to this at QtCon. Yours, Tuukka From cavendish.qi at gmail.com Thu Sep 8 07:37:28 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Thu, 8 Sep 2016 07:37:28 +0200 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: <57CFB58D.2060200@qt.io> References: <57CFB58D.2060200@qt.io> Message-ID: On 7 September 2016 at 08:37, Friedemann Kleint wrote: > Hi, > > the notes are at: https://wiki.qt.io/QtCS2016_Managing_Qt_Branches > > * Number of existing branches (5.6LTS, 5.7.,5.8 dev) causes a number of > problems > > ** Strain on COIN which also has release branches > ** Merging becomes increasingly difficult > ** Hard to manage for individual developers > > * Branches > > ** Close 5.7 after 5.7.1. We then have LTS, stable, dev. > Is it better to have 5.7.2 around 5.8.0 final release and close 5.7 after that? 5.7.1 is very soon in a few weeks. There will be a few months gap between 5.7.1 and 5.8.0/5.8.1. The first release of new branch, like 5.8.0, sometimes it's not tested enough in user(or application developers) side, so some regressions or a bit critical issues will be found between 5.8.0 and 5.8.1. It's good for users to have a more stable release of 5.7.2. If we stick to do release like this kind of order, 5.6.2->5.7.1->5.8.0 Beta, it's not very difficult to have a 5.6.3->5.7.2->5.8.0 or similar. And I would like to see it becomes a convention for future releases. Best Regards, Liang > ** After 5.7 is closed and sanity bot is upgraded (to handle > cherry-picking), go into cherrypicking mode for 5.6. Developer is > responsible for doing the cherrypicking > ** Cherry-picking technicalities need to be figured out: Let sanity bot > verify source ("cherrypicked from") the SHA1 > ** In the future, exact time for closing stable branches will be discussed > for each one individually > > * Submit Policy > > ** Target which branch? > > ** Long Term Support (5.6) Branch > *** Initially equal to stable, increasingly strict over time: Fix only > severe issues, avoid regressions. > > *** Bugs: For example, P2 for the first year, P1 for year 2, rest > Security. Try to further objectify that: Jedrzei + Friedemann > *** Tests: Fix/stabilize tests itself, add tests > *** No performance improvements unless really significant > (relevant/reduces O(n)) > *** Upgrading 3rd party (including WebEngine) > *** Support new OS versions unless introducing new platforms, no rewrite > of QPA > *** No cleanups, positively: -> dev > *** To aid customers with issues, patches for issues in LTS to be locally > applied can be provided, but the fixes will be pushed to higher versions of > Qt. > > > Regards, > Friedemann > > -- > Friedemann Kleint > The Qt Company GmbH > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Thu Sep 8 09:12:32 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 8 Sep 2016 09:12:32 +0200 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: <57CFB58D.2060200@qt.io> References: <57CFB58D.2060200@qt.io> Message-ID: <201609080912.32155.marc.mutz@kdab.com> On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote: > ** After 5.7 is closed and sanity bot is upgraded (to handle > cherry-picking), go into cherrypicking mode for 5.6. Developer is > responsible for doing the cherrypicking > ** Cherry-picking technicalities need to be figured out: Let sanity bot > verify source ("cherrypicked from") the SHA1 I'm sorry, but this is nonsense. The source control system works by committing on the older branches and merging up. Cherry-picking from younger branches works against the source control system. We put up with cherry-picking for 4.8, because there we dealt with separate repositories, but that doesn't make is a good model. There's another aspect to this: I develop part of my patches on gt5.git/5.6 and the rest on qtbase.git/dev. I guess for most people with non-unlimited processing power it will be similar. For sure this is the only way if your development focus is on qtbase (and you can't just submit your changes to COIN manually). If I submit from the qt5.git/5.6 built, the changes have gone through testing in the stable branch. If I submit from there to younger branches, test coverage is not as good, but the point is that the stable branch receives the changes tested locally in-situ. If I change this to qt5.git/5.8 and cherry- pick changes back to 5.6, all local testing will have been done in-situ for 5.8, and when submitting to 5.6, no in-situ testing has happened locally. IOW: cherry-picking causes *more* risk to the stable branch than submitting there and merging up. I am not convinced that the perceived security of having a patch integrated into a younger branch and then submitting it to the older branch outweights the loss of test coverage. If the merging strain is too much, only merge 5.6 up once a fortnight/month. Currently, it feels like there's 5.6 -> 5.7 5.7 -> 5.8 5.8 -> dev 5.6 -> 5.7 with maximum speed. That's nice for developers who are splitting changes into a bugfix part for 5.6 and a feature part for 5.8/dev, but it hasn't been like that in the past and we survived, too. And the git history looked cleaner, too :) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From alexander.blasche at qt.io Thu Sep 8 09:36:21 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Thu, 8 Sep 2016 07:36:21 +0000 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: <201609080912.32155.marc.mutz@kdab.com> References: <57CFB58D.2060200@qt.io>,<201609080912.32155.marc.mutz@kdab.com> Message-ID: ________________________________________ From: Marc Mutz >On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote: >> ** After 5.7 is closed and sanity bot is upgraded (to handle >> cherry-picking), go into cherrypicking mode for 5.6. Developer is >> responsible for doing the cherrypicking >> ** Cherry-picking technicalities need to be figured out: Let sanity bot >> verify source ("cherrypicked from") the SHA1 >I'm sorry, but this is nonsense. I agree with Marc. Why cant we do 5.6->5.8 merges once the 5.7 branch is closed? Since the 5.6 branch will get fewer and fewer patches as the strictness of its commits increases I see no reason why 5.6->5.8 could pose a problem. Maybe you sb can elaborate why we have to go to cherry-picking? The notes don't say and I wasn't in this QtCon meeting. -- Alex From cavendish.qi at gmail.com Thu Sep 8 12:25:02 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Thu, 8 Sep 2016 12:25:02 +0200 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: References: <57CFB58D.2060200@qt.io> <201609080912.32155.marc.mutz@kdab.com> Message-ID: On 8 September 2016 at 09:36, Alexander Blasche wrote: > ________________________________________ > From: Marc Mutz > > >On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote: > >> ** After 5.7 is closed and sanity bot is upgraded (to handle > >> cherry-picking), go into cherrypicking mode for 5.6. Developer is > >> responsible for doing the cherrypicking > >> ** Cherry-picking technicalities need to be figured out: Let sanity bot > >> verify source ("cherrypicked from") the SHA1 > > >I'm sorry, but this is nonsense. > > I agree with Marc. Why cant we do 5.6->5.8 merges once the 5.7 branch is > closed? Since the 5.6 branch will get fewer and fewer patches as the > strictness of its commits increases I see no reason why 5.6->5.8 could pose > a problem. > > Maybe you sb can elaborate why we have to go to cherry-picking? The notes > don't say and I wasn't in this QtCon meeting. > This is mainly because we did heavy refactoring in upstream branches, for example, rewriting configure system, then any small fix in 5.6 will trigger a huge conflicts. https://codereview.qt-project.org/#/c/163938/ Other cases are sth like directories reorganization, class renaming and etc, it's very annoying when developers have changes in similar places in 5.6 and upper branches. Best Regards, Liang > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.terrier at gmail.com Thu Sep 8 11:35:22 2016 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Thu, 8 Sep 2016 11:35:22 +0200 Subject: [Development] QUuid documentation Message-ID: Hi, As of Qt 5.7, QUuid::createUuid() documentation is: > On any platform other than Windows, this function returns a new UUID with variant QUuid::DCE and version QUuid::Random. If the /dev/urandom device exists, then the numbers used to construct the UUID will be of cryptographic quality, which will make the UUID unique. Otherwise, the numbers of the UUID will be obtained from the local pseudo-random number generator (qrand(), which is seeded by qsrand()) which is usually not of cryptograhic quality, which means that the UUID can't be guaranteed to be unique. > > On a Windows platform, a GUID is generated, which almost certainly will be unique, on this or any other system, networked or not. So according to this there are 3 kinds of UUID: - Generated by /dev/urandom - Generated by qrand() - Generated on Windows OS The documentation states explicitly that the first type is unique and that the 2 last types are not unique. However, my knowledge is that whatever the method one use to generate your UUID, one can never guarantee its uniqueness. Meaning that the Qt documentation is falsely guarantying unique UUID and therefore should be changed. If anyone can confirm, I'll create a bug report. BR, Benjamin Terrier From jani.heikkinen at qt.io Thu Sep 8 12:32:58 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 8 Sep 2016 10:32:58 +0000 Subject: [Development] Qt 5.6.2 Snapshot for testing In-Reply-To: References: Message-ID: Hi all, We have Qt 5.6.2 snapshot for testing Win: http://download.qt.io/snapshots/qt/5.6/5.6.2/553/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.2/489/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.2/418/ src: http://download.qt.io/snapshots/qt/5.6/5.6.2/latest_src/ Packages are based on https://codereview.qt-project.org/#/c/169746/ Unfortunately these aren't yet final Qt 5.6.2 packages because most of change files are still missing [☹] But Qt 5.6.2 blocker list is empty (see https://bugreports.qt.io/issues/?filter=17829 ) so if nothing really serious found during testing we will just update missing change files in the packages & release Qt 5.6.2 during next week so please make sure all blockers are visible in the blocker list immediately after noticed! And please make sure change files are in as soon as possible (hoping already during this week). br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OutlookEmoji-☹.png Type: image/png Size: 506 bytes Desc: OutlookEmoji-☹.png URL: From oswald.buddenhagen at qt.io Thu Sep 8 12:58:48 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 8 Sep 2016 12:58:48 +0200 Subject: [Development] [Qt-creator] [FYI] on gerrit change retargeting requests In-Reply-To: <201609061456.31779.marc.mutz@kdab.com> References: <20160831141255.GG2429@troll08> <04C718D5-89D8-496E-AA6A-6118CC41839B@qt.io> <20160906094334.GB7954@nubble> <201609061456.31779.marc.mutz@kdab.com> Message-ID: <20160908105848.GD14568@nubble> On Tue, Sep 06, 2016 at 02:56:31PM +0200, Marc Mutz wrote: > As it is now, not even all @qt.io people know how to do this/that it's > possible... > of course. why would anyone read the branch creation mails in which we point out the possibility every single time ... it's not like they have subjects which look important or something. From oswald.buddenhagen at qt.io Thu Sep 8 13:26:12 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 8 Sep 2016 13:26:12 +0200 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: References: <57CFB58D.2060200@qt.io> <201609080912.32155.marc.mutz@kdab.com> Message-ID: <20160908112612.GE14568@nubble> On Thu, Sep 08, 2016 at 12:25:02PM +0200, Liang Qi wrote: > This is mainly because we did heavy refactoring in upstream branches, > "upstream" makes no sense whatsoever. merge-wise, it's exactly the wrong way around. "younger" as used elsewhere in this thread is better. > for example, rewriting configure system, then any small fix in 5.6 > will trigger a huge conflicts. > yes, it's annoying for the one(s) doing the work, but the fact that it *has* to be done ensures that it *gets* done. doing cherry-picking is a virtual guarantee that the LTS becomes a scam. you should also see things in perspective: how many files merge without you even noticing it, because the merges are clean? > Other cases are sth like directories reorganization, class renaming > and etc, it's very annoying when developers have changes in similar > places in 5.6 and upper branches. > which is why i'm actually in favor of doing low-risk cleanups and refactorings on stable branches, or at least shortly before branching off. > Best Regards, > Liang > > > > > -- > > Alex > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From bo at vikingsoft.eu Thu Sep 8 13:41:21 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Thu, 8 Sep 2016 13:41:21 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <1611603.8B8jhCL7eK@agathebauer> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> Message-ID: <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> Den 05-09-2016 kl. 20:49 skrev Milian Wolff: >> As an incredibly simple example, make is inherently limited in that it >> > cannot even represent a rule with multiple outputs (there are some >> > workarounds, but they are hacky and rather limited in how they can be >> > applied). And ninja is no magic bullet here either, because that still >> > represents a static build graph, whereas the content of Qbs' build graph >> > can actually change during the execution of the build. > Can you give an example for why we should care? This may sound flame-baity, > but I'm really truly interested. I simply don't care about my build system, as > long as it gets the job done without too much hassle (and yes, that is the > case for me personally with cmake), and fast, too (which is the case with > ninja). See also below. I can answer that because I asked for this feature all the way back at QtCS in Bilbao. The context I was talking about was code generators. At the time I had built a code generator that created both the Qt and the PHP side of a client-server system. It had a single JSON file that described a server with the available remote methods on it. The output from the C++ code generator was a .h and .cpp file per method and a single .h and .cpp that described the server. So on qmake run time you can't know how many output files you have unless you force the user to run qmake every time you modify the JSON description. And to make the problem worse, the customer wanted each of the classes describing a remote call to be qobjects with a Q_OBJECT so a moc run is required. AFAIK this is impossible to do with both qmake and cmake. Not just hard, actually impossible. And the reason is that you can't know until build time what files you have to run moc on. (Now as a mental exersize, imagine having multiple server descriptions in a single json file...) It's possible to do in pure make by calling the code generator and creating a sub make file and then calling make on that. But you can't do that in any way that supports hitting the build button once in QtCreator. I finally solved this by convincing the customer it was sufficient to have a qobject base class for the remote calls and live without the meta object descriptions on those. And yes, this is a very specific case. But it's an example of something that neither cmake nor qmake can do because they have a makefile generating step. Maybe this seems more important to me than others because I'm a huge fan of custom built code generators for stuff like database connections and client-server communications. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From milian.wolff at kdab.com Thu Sep 8 13:47:05 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Thu, 08 Sep 2016 13:47:05 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> Message-ID: <2391268.OHDipyMWUV@agathebauer> On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote: > Den 05-09-2016 kl. 20:49 skrev Milian Wolff: > >> As an incredibly simple example, make is inherently limited in that it > >> > >> > cannot even represent a rule with multiple outputs (there are some > >> > workarounds, but they are hacky and rather limited in how they can be > >> > applied). And ninja is no magic bullet here either, because that still > >> > represents a static build graph, whereas the content of Qbs' build > >> > graph > >> > can actually change during the execution of the build. > > > > Can you give an example for why we should care? This may sound > > flame-baity, > > but I'm really truly interested. I simply don't care about my build > > system, as long as it gets the job done without too much hassle (and yes, > > that is the case for me personally with cmake), and fast, too (which is > > the case with ninja). See also below. > > I can answer that because I asked for this feature all the way back at > QtCS in Bilbao. > > The context I was talking about was code generators. At the time I had > built a code generator that created both the Qt and the PHP side of a > client-server system. It had a single JSON file that described a server > with the available remote methods on it. The output from the C++ code > generator was a .h and .cpp file per method and a single .h and .cpp > that described the server. So on qmake run time you can't know how many > output files you have unless you force the user to run qmake every time > you modify the JSON description. > > And to make the problem worse, the customer wanted each of the classes > describing a remote call to be qobjects with a Q_OBJECT so a moc run is > required. > > AFAIK this is impossible to do with both qmake and cmake. Not just hard, > actually impossible. At least for CMake, I don't think so - if I'm not misunderstanding the problem. You add a target that depends on your .json file, and then whenever that is changed you generate headers. Then you add a dependent target which runs moc. And then you let your actual target depend on that one? > And the reason is that you can't know until build > time what files you have to run moc on. (Now as a mental exersize, > imagine having multiple server descriptions in a single json file...) That is not an issue, no? You have one file that you need your targets depend on - the JSON file. If that one changes, the dependent targets must be rebuild. > It's possible to do in pure make by calling the code generator and > creating a sub make file and then calling make on that. But you can't do > that in any way that supports hitting the build button once in QtCreator. > > I finally solved this by convincing the customer it was sufficient to > have a qobject base class for the remote calls and live without the meta > object descriptions on those. And yes, this is a very specific case. But > it's an example of something that neither cmake nor qmake can do because > they have a makefile generating step. > > Maybe this seems more important to me than others because I'm a huge fan > of custom built code generators for stuff like database connections and > client-server communications. I'm not yet convinced. Bye -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5901 bytes Desc: not available URL: From bo at vikingsoft.eu Thu Sep 8 14:03:05 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Thu, 8 Sep 2016 14:03:05 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <2391268.OHDipyMWUV@agathebauer> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> Message-ID: <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> Den 08-09-2016 kl. 13:47 skrev Milian Wolff: > On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote: >> Den 05-09-2016 kl. 20:49 skrev Milian Wolff: >>>> As an incredibly simple example, make is inherently limited in that it >>>> >>>>> cannot even represent a rule with multiple outputs (there are some >>>>> workarounds, but they are hacky and rather limited in how they can be >>>>> applied). And ninja is no magic bullet here either, because that still >>>>> represents a static build graph, whereas the content of Qbs' build >>>>> graph >>>>> can actually change during the execution of the build. >>> >>> Can you give an example for why we should care? This may sound >>> flame-baity, >>> but I'm really truly interested. I simply don't care about my build >>> system, as long as it gets the job done without too much hassle (and yes, >>> that is the case for me personally with cmake), and fast, too (which is >>> the case with ninja). See also below. >> >> I can answer that because I asked for this feature all the way back at >> QtCS in Bilbao. >> >> The context I was talking about was code generators. At the time I had >> built a code generator that created both the Qt and the PHP side of a >> client-server system. It had a single JSON file that described a server >> with the available remote methods on it. The output from the C++ code >> generator was a .h and .cpp file per method and a single .h and .cpp >> that described the server. So on qmake run time you can't know how many >> output files you have unless you force the user to run qmake every time >> you modify the JSON description. >> >> And to make the problem worse, the customer wanted each of the classes >> describing a remote call to be qobjects with a Q_OBJECT so a moc run is >> required. >> >> AFAIK this is impossible to do with both qmake and cmake. Not just hard, >> actually impossible. > > At least for CMake, I don't think so - if I'm not misunderstanding the > problem. You add a target that depends on your .json file, and then whenever > that is changed you generate headers. Then you add a dependent target which > runs moc. And then you let your actual target depend on that one? > >> And the reason is that you can't know until build >> time what files you have to run moc on. (Now as a mental exersize, >> imagine having multiple server descriptions in a single json file...) > > That is not an issue, no? You have one file that you need your targets depend > on - the JSON file. If that one changes, the dependent targets must be > rebuild. > >> It's possible to do in pure make by calling the code generator and >> creating a sub make file and then calling make on that. But you can't do >> that in any way that supports hitting the build button once in QtCreator. >> >> I finally solved this by convincing the customer it was sufficient to >> have a qobject base class for the remote calls and live without the meta >> object descriptions on those. And yes, this is a very specific case. But >> it's an example of something that neither cmake nor qmake can do because >> they have a makefile generating step. >> >> Maybe this seems more important to me than others because I'm a huge fan >> of custom built code generators for stuff like database connections and >> client-server communications. > > I'm not yet convinced. Ok, go try it. Create a simple python or perl script that reads a file. The file just has a single number N inside it. And based on N the script outputs those files: server.h method1.h method2.h ... methodN.h Inside method1.h you write this: #include class Method1 : public QObject { Q_OBJECT }; server.h has this: #include "method1.h" ... #include "methodN.h" class Server { public: Method1* call1() { return new Method1; } ... MethodN* callN() { return new MethodN; } }; In main.cpp you instantiate Server. The only problem is that you have to run moc on each of the .h files. Solution to the problem is only accepted if you can press build one single time inside both Visual Studio and Qt Creator and it builds this even when you modify the input file and the main.cpp. I'm sure there are ways you can make the build call cmake or force a build to fail and rebuild, and that's what you can currently do. And those all feels annoying when you work on the project. You asked why modifying the tree at build time could be necessary. This is one of the (probably very few) examples of it. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From annulen at yandex.ru Thu Sep 8 14:19:08 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 08 Sep 2016 15:19:08 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> Message-ID: <130321473337148@web23h.yandex.ru> 08.09.2016, 15:03, "Bo Thorsen" : > Den 08-09-2016 kl. 13:47 skrev Milian Wolff: >>  On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote: >>>  Den 05-09-2016 kl. 20:49 skrev Milian Wolff: >>>>>  As an incredibly simple example, make is inherently limited in that it >>>>> >>>>>>  cannot even represent a rule with multiple outputs (there are some >>>>>>  workarounds, but they are hacky and rather limited in how they can be >>>>>>  applied). And ninja is no magic bullet here either, because that still >>>>>>  represents a static build graph, whereas the content of Qbs' build >>>>>>  graph >>>>>>  can actually change during the execution of the build. >>>> >>>>  Can you give an example for why we should care? This may sound >>>>  flame-baity, >>>>  but I'm really truly interested. I simply don't care about my build >>>>  system, as long as it gets the job done without too much hassle (and yes, >>>>  that is the case for me personally with cmake), and fast, too (which is >>>>  the case with ninja). See also below. >>> >>>  I can answer that because I asked for this feature all the way back at >>>  QtCS in Bilbao. >>> >>>  The context I was talking about was code generators. At the time I had >>>  built a code generator that created both the Qt and the PHP side of a >>>  client-server system. It had a single JSON file that described a server >>>  with the available remote methods on it. The output from the C++ code >>>  generator was a .h and .cpp file per method and a single .h and .cpp >>>  that described the server. So on qmake run time you can't know how many >>>  output files you have unless you force the user to run qmake every time >>>  you modify the JSON description. >>> >>>  And to make the problem worse, the customer wanted each of the classes >>>  describing a remote call to be qobjects with a Q_OBJECT so a moc run is >>>  required. >>> >>>  AFAIK this is impossible to do with both qmake and cmake. Not just hard, >>>  actually impossible. >> >>  At least for CMake, I don't think so - if I'm not misunderstanding the >>  problem. You add a target that depends on your .json file, and then whenever >>  that is changed you generate headers. Then you add a dependent target which >>  runs moc. And then you let your actual target depend on that one? >> >>>  And the reason is that you can't know until build >>>  time what files you have to run moc on. (Now as a mental exersize, >>>  imagine having multiple server descriptions in a single json file...) >> >>  That is not an issue, no? You have one file that you need your targets depend >>  on - the JSON file. If that one changes, the dependent targets must be >>  rebuild. >> >>>  It's possible to do in pure make by calling the code generator and >>>  creating a sub make file and then calling make on that. But you can't do >>>  that in any way that supports hitting the build button once in QtCreator. >>> >>>  I finally solved this by convincing the customer it was sufficient to >>>  have a qobject base class for the remote calls and live without the meta >>>  object descriptions on those. And yes, this is a very specific case. But >>>  it's an example of something that neither cmake nor qmake can do because >>>  they have a makefile generating step. >>> >>>  Maybe this seems more important to me than others because I'm a huge fan >>>  of custom built code generators for stuff like database connections and >>>  client-server communications. >> >>  I'm not yet convinced. > > Ok, go try it. Create a simple python or perl script that reads a file. > The file just has a single number N inside it. And based on N the script > outputs those files: > > server.h > method1.h > method2.h > ... > methodN.h > > Inside method1.h you write this: > > #include > > class Method1 : public QObject { >    Q_OBJECT > }; > > server.h has this: > > #include "method1.h" > ... > #include "methodN.h" > > class Server { > public: >    Method1* call1() { return new Method1; } >    ... >    MethodN* callN() { return new MethodN; } > }; > > In main.cpp you instantiate Server. > > The only problem is that you have to run moc on each of the .h files. Run moc from inside script when you generate header. > > Solution to the problem is only accepted if you can press build one > single time inside both Visual Studio and Qt Creator and it builds this > even when you modify the input file and the main.cpp. > > I'm sure there are ways you can make the build call cmake or force a > build to fail and rebuild, and that's what you can currently do. And > those all feels annoying when you work on the project. > > You asked why modifying the tree at build time could be necessary. This > is one of the (probably very few) examples of it. > > Bo Thorsen, > Director, Viking Software. > > -- > Viking Software > Qt and C++ developers for hire > http://www.vikingsoft.eu > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From christian.kandeler at qt.io Thu Sep 8 14:34:03 2016 From: christian.kandeler at qt.io (Christian Kandeler) Date: Thu, 8 Sep 2016 14:34:03 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> Message-ID: On 09/08/2016 02:03 PM, Bo Thorsen wrote: > Ok, go try it. Create a simple python or perl script that reads a file. > The file just has a single number N inside it. And based on N the script > outputs those files: > > server.h > method1.h > method2.h > ... > methodN.h > > Inside method1.h you write this: > > #include > > class Method1 : public QObject { > Q_OBJECT > }; > > server.h has this: > > #include "method1.h" > ... > #include "methodN.h" > > class Server { > public: > Method1* call1() { return new Method1; } > ... > MethodN* callN() { return new MethodN; } > }; > > In main.cpp you instantiate Server. > > The only problem is that you have to run moc on each of the .h files. > > Solution to the problem is only accepted if you can press build one > single time inside both Visual Studio and Qt Creator and it builds this > even when you modify the input file and the main.cpp. In qbs: Rule { inputs: ["metadata"] fileTags: ["hpp"] outputArtifacts: { var p = new Process(); try { p.exec("path_to_script", ["--list", input.filePath]); var files = p.readStdout.split("\n"); var artifacts = []; for (var i in files) artifacts.push({ filePath: files[i], fileTags: ["hpp"]}); return artifacts: } finally { p.close(); } prepare: { var cmd = new Command("path_to_script", ["--generate", input.filePath]); cmd.description = "creating headers"; return [cmd]; } } (This is a somewhat more advanced example in that it is not assumed that we have a priori knowledge about how the content of the input file relates to the outputs.) FYI, Christian From milian.wolff at kdab.com Thu Sep 8 14:48:23 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Thu, 08 Sep 2016 14:48:23 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> Message-ID: <26806728.XxpNaikK00@agathebauer> On Donnerstag, 8. September 2016 14:03:05 CEST Bo Thorsen wrote: > Den 08-09-2016 kl. 13:47 skrev Milian Wolff: > > On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote: > >> Den 05-09-2016 kl. 20:49 skrev Milian Wolff: > >>>> As an incredibly simple example, make is inherently limited in that it > >>>> > >>>>> cannot even represent a rule with multiple outputs (there are some > >>>>> workarounds, but they are hacky and rather limited in how they can be > >>>>> applied). And ninja is no magic bullet here either, because that still > >>>>> represents a static build graph, whereas the content of Qbs' build > >>>>> graph > >>>>> can actually change during the execution of the build. > >>> > >>> Can you give an example for why we should care? This may sound > >>> flame-baity, > >>> but I'm really truly interested. I simply don't care about my build > >>> system, as long as it gets the job done without too much hassle (and > >>> yes, > >>> that is the case for me personally with cmake), and fast, too (which is > >>> the case with ninja). See also below. > >> > >> I can answer that because I asked for this feature all the way back at > >> QtCS in Bilbao. > >> > >> The context I was talking about was code generators. At the time I had > >> built a code generator that created both the Qt and the PHP side of a > >> client-server system. It had a single JSON file that described a server > >> with the available remote methods on it. The output from the C++ code > >> generator was a .h and .cpp file per method and a single .h and .cpp > >> that described the server. So on qmake run time you can't know how many > >> output files you have unless you force the user to run qmake every time > >> you modify the JSON description. > >> > >> And to make the problem worse, the customer wanted each of the classes > >> describing a remote call to be qobjects with a Q_OBJECT so a moc run is > >> required. > >> > >> AFAIK this is impossible to do with both qmake and cmake. Not just hard, > >> actually impossible. > > > > At least for CMake, I don't think so - if I'm not misunderstanding the > > problem. You add a target that depends on your .json file, and then > > whenever that is changed you generate headers. Then you add a dependent > > target which runs moc. And then you let your actual target depend on that > > one? > > > >> And the reason is that you can't know until build > >> time what files you have to run moc on. (Now as a mental exersize, > >> imagine having multiple server descriptions in a single json file...) > > > > That is not an issue, no? You have one file that you need your targets > > depend on - the JSON file. If that one changes, the dependent targets > > must be rebuild. > > > >> It's possible to do in pure make by calling the code generator and > >> creating a sub make file and then calling make on that. But you can't do > >> that in any way that supports hitting the build button once in QtCreator. > >> > >> I finally solved this by convincing the customer it was sufficient to > >> have a qobject base class for the remote calls and live without the meta > >> object descriptions on those. And yes, this is a very specific case. But > >> it's an example of something that neither cmake nor qmake can do because > >> they have a makefile generating step. > >> > >> Maybe this seems more important to me than others because I'm a huge fan > >> of custom built code generators for stuff like database connections and > >> client-server communications. > > > > I'm not yet convinced. > > Ok, go try it. Create a simple python or perl script that reads a file. > The file just has a single number N inside it. And based on N the script > outputs those files: > > server.h > method1.h > method2.h > ... > methodN.h > > Inside method1.h you write this: > > #include > > class Method1 : public QObject { > Q_OBJECT > }; > > server.h has this: > > #include "method1.h" > ... > #include "methodN.h" > > class Server { > public: > Method1* call1() { return new Method1; } > ... > MethodN* callN() { return new MethodN; } > }; > > In main.cpp you instantiate Server. > > The only problem is that you have to run moc on each of the .h files. > > Solution to the problem is only accepted if you can press build one > single time inside both Visual Studio and Qt Creator and it builds this > even when you modify the input file and the main.cpp. > > I'm sure there are ways you can make the build call cmake or force a > build to fail and rebuild, and that's what you can currently do. And > those all feels annoying when you work on the project. > > You asked why modifying the tree at build time could be necessary. This > is one of the (probably very few) examples of it. Someone else also told me that this is apparently harder then I thought it is with CMake, when the name of the output files of a code generator is not known. It is possible, but far from easy esp. when you don't have control over the generator script (though one can always use a wrapper). I see now that having support for this in QBS can be advantageous for the cases where one has such cases. Thankfully, I never ran into this so far, ever. Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From edward.welbourne at qt.io Thu Sep 8 15:49:19 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 8 Sep 2016 13:49:19 +0000 Subject: [Development] Qt Network Maintainership Changes In-Reply-To: References: , Message-ID: On 6 Sep 2016, at 21:05, Richard Moore wrote: >> [...] I'd like to nominate Timur as my replacement - he's already >> spent an inordinate amount of time fixing bugs, to say nothing of >> adding support for HTTP/2 so I'm sure things are in good hands. >> >> https://codereview.qt-project.org/#/q/owner:%22Timur+Pocheptsov%22,n,z >> >> On a similar note, I'd like to nominate Jesús Fernández as the >> maintainer of the QtNetworkAuth module - he wrote it after all! >> >> https://codereview.qt-project.org/#/q/owner:%22Jesus+Fernandez%22,n,z Morten Sorvig replied: > +1 to both Timur and Jesús from me. +1 for both here (disclaimer: I'm in the same team at TQtC), Eddy. From bo at vikingsoft.eu Thu Sep 8 15:52:48 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Thu, 8 Sep 2016 15:52:48 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <130321473337148@web23h.yandex.ru> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> <130321473337148@web23h.yandex.ru> Message-ID: Den 08-09-2016 kl. 14:19 skrev Konstantin Tokarev: >> > The only problem is that you have to run moc on each of the .h files. > Run moc from inside script when you generate header. Yes, I thought about that at the time as well. While simple enpough, there are some complications. You would have to run moc exactly like if it was done by the qmake built makefiles, with exactly the same environment and arguments. Not impossible, but it does sound brittle. For example different qmake versions might do things differently. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From edward.welbourne at qt.io Thu Sep 8 17:06:24 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 8 Sep 2016 15:06:24 +0000 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <201609071101.32455.marc.mutz@kdab.com> References: <201608121052.52787.marc.mutz@kdab.com> <201608161048.27861.marc.mutz@kdab.com> <1755764.blp8L9eGak@maurice>,<201609071101.32455.marc.mutz@kdab.com> Message-ID: On Wednesday 07 September 2016 10:26:44 Olivier Goffart wrote: >> The reason we should limit the changes to critical change is so than >> "jumping through hoops" gets easier. Every patch we put there instead >> of in a upper branch makes more work of merging, handling regressions >> causing by this patch, having to work with an outdated code base. >> >> (In fact, I think maybe we should stop merging 5.6. Backporting >> (chery-pick) proven patches might be more effective.) Marc Mutz replied: > IMO, that's nonsense. I still remember this from 4.8. No thanks. I can't remember 4.8 - I wasn't here that long ago. Please share * what was the process ? * why was it painful ? (... as your phrasing indicates it was) > Why work against the (very good!) revision control system? One of the nice things about git is that it supports many work-flows. Using its support for cherry-picking does not "work against" it; indeed, it's what we primarily do in Gerrit (and rebasing is just mass-produced cherry-picking). It also supports merging wonderfully well, of course. So the real question is: what work-flow works best for us ? > Anyway, seeing as neither you nor me are doing merges, I guess we > should let that particular topic in peace for Liang and Eddy to > comment on, if they so wish. The branch-management discussion at QtCon decided in fact to go with a switch to cherry-picking back to LTS once 5.7 closes. Until then, we'll be merging 5.6 -> 5.7 -> 5.8 -> dev, which is a painfully long chain, but we endure it. Once 5.7 drops out of the chain and 5.9 sneaks in, however, we'll be merging stable -> release -> dev and cherry-picking backwards from stable (initially 5.8) to LTS (5.6). One of the contributory factors to that choice is just the length of the present merge chain (which slows propagation of changes); another is the expectation that conflicts shall become more common when passing over the dead 5.7 branch (and, eventually, more). I was part of that discussion and I am satisfied that this is a sensible way to move forward - provided I can work out how to hack into sanity-bot the necessary checks that cherry-picks reference the right sha1s. If I read the past accurately, it was Marc who had supplied: >>> Because the LTS is for users who _cannot_ update to newer Qts (for >>> whatever reason, dropped platforms just being one of them). Pointing >>> them to a newer Qt where their bug is fixed is not going to help them >>> one bit. On the other hand, pointing them to the fix in a newer Qt does, at least in some cases, offer them the option of patching the version of Qt they use. It isn't adequate for all, but it is significantly easier for them to cherry-pick one (typically self-contained, single-commit) bug-fix rather than a whole new feature (typically split across several commits, that may - thanks to the vagaries of Gerrit - have been split up across a broad span of the git history). Olivier replied: >> You could say the same about any new feature. and Marc followed up with: > Of course not. A user needs to write code to use a new feature. A bugfix > affects existing code. That's actually an interesting way to draw the distinction. Elsewhere I see a doc vs code (only one changes in a bug-fix, both in a feature) way to draw it; this gives a different classification. There is a general problem that - in between the changes that are clearly new features and those that are clearly bug-fixes - there is a broad grey area where it doesn't really help much to argue about whether the change is a feature or a fix; it's a change, to be assessed as itself. Whether it belongs in a particular branch should be about its suitability for the releases intended off that branch. Sometimes we change default behaviour of a system; the client code doesn't change, but its behaviour does; both the code and the doc change, so the doc vs code classifier calls this a feature, while the new code classifier says its a bug-fix. This is indeed quite apt: some such changes fix an inappropriate default behaviour, others enable new ways of using the system. Whether they're bugs or features isn't really the important question: whether such a change should go into LTS depends on whether LTS use-cases are likely to be broken by the change and whether LTS use-cases are likely to be saved from grief by them. If we update the list of cipher-suites used by default in SSL (quite likely we shall), I don't really care whether you call it a bug-fix or a feature; I'm fairly sure I'll want it to go into LTS because it'll make client code work better with the evolving set of ciphers in use by the servers it'll be talking to. So let's not get hung up on classifying things as bugs or features; let's ask what changes should go into LTS. Changes that are unequivocally new features shouldn't; changes which unequivocally fix important bugs that are likely to impact many LTS users should. The mess in between does somewhat align with the fuzzy distinction between bug and feature; but we shouldn't get hung up on that distinction when deciding the real question: does this change belong in LTS ? So a third reason why cherry-picking back to 5.6 makes sense is that each such change does need to be studied for "does it belong in LTS"; this may at times be contentious, which shall slow down review of those changes. If we stuck with merging all the way, that would delay those changes getting into more recent branches where there is less to argue about. Once you've got your fix into stable (and it's begun its merge journey up the chain towards dev) you can start arguing about whether it belongs in LTS, in a separate review for the cherry-pick. The reason we should limit the changes in LTS to critical change is that all change incurs risk and the point of LTS is to assure stability. For a critical change, the benefit (fixing a critical problem) more surely out-weighs the (unquantifiable until too late) harm implicit in the risk associated with change. LTS users are - ipso facto - more conservative, more risk-averse, so better served by a more stable (i.e. less changing) product. Eddy. From thiago.macieira at intel.com Thu Sep 8 17:13:11 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 08 Sep 2016 08:13:11 -0700 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: References: <57CFB58D.2060200@qt.io> Message-ID: <2532835.dUoVZLnayI@tjmaciei-mobl1> On quinta-feira, 8 de setembro de 2016 07:37:28 PDT Liang Qi wrote: > Is it better to have 5.7.2 around 5.8.0 final release and close 5.7 after > that? 5.7.1 is very soon in a few weeks. There will be a few months gap > between 5.7.1 and 5.8.0/5.8.1. The first release of new branch, like 5.8.0, > sometimes it's not tested enough in user(or application developers) side, > so some regressions or a bit critical issues will be found between 5.8.0 > and 5.8.1. It's good for users to have a more stable release of 5.7.2. > > If we stick to do release like this kind of order, 5.6.2->5.7.1->5.8.0 > Beta, it's not very difficult to have a 5.6.3->5.7.2->5.8.0 or similar. > > And I would like to see it becomes a convention for future releases. It wouldn't be bad, if the release team and merging team can make it work. Our concern was that you and Eddy are spending far too much time on doing merges. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Sep 8 17:16:27 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 08 Sep 2016 08:16:27 -0700 Subject: [Development] QUuid documentation In-Reply-To: References: Message-ID: <1975369.J7for5LNFY@tjmaciei-mobl1> On quinta-feira, 8 de setembro de 2016 11:35:22 PDT Benjamin TERRIER wrote: > Hi, > > As of Qt 5.7, QUuid::createUuid() documentation is: > > On any platform other than Windows, this function returns a new UUID with > > variant QUuid::DCE and version QUuid::Random. If the /dev/urandom device > > exists, then the numbers used to construct the UUID will be of > > cryptographic quality, which will make the UUID unique. Otherwise, the > > numbers of the UUID will be obtained from the local pseudo-random number > > generator (qrand(), which is seeded by qsrand()) which is usually not of > > cryptograhic quality, which means that the UUID can't be guaranteed to be > > unique. > > > > On a Windows platform, a GUID is generated, which almost certainly will be > > unique, on this or any other system, networked or not. > So according to this there are 3 kinds of UUID: > - Generated by /dev/urandom > - Generated by qrand() > - Generated on Windows OS > > The documentation states explicitly that the first type is unique and > that the 2 last types are not unique. It says that the first and the last are unique, the middle one isn't. > However, my knowledge is that whatever the method one use to generate > your UUID, one can never guarantee its uniqueness. Meaning that the Qt > documentation is falsely guarantying unique UUID and therefore should > be changed. > > If anyone can confirm, I'll create a bug report. Right, it's not guaranteed. It's just that the chance of collision is virtually zero. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From stephen.kelly at ableton.com Thu Sep 8 18:13:31 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Thu, 8 Sep 2016 18:13:31 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <26806728.XxpNaikK00@agathebauer> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> <26806728.XxpNaikK00@agathebauer> Message-ID: <3b6d6261-1f6a-5ea6-a8ee-1191d1c0cee8@ableton.com> On 08/09/16 14:48, Milian Wolff wrote: > Someone else also told me that this is apparently harder then I thought it is > with CMake, when the name of the output files of a code generator is not > known. It is possible, but far from easy esp. when you don't have control over > the generator script (though one can always use a wrapper). I see now that > having support for this in QBS can be advantageous for the cases where one has > such cases. Thankfully, I never ran into this so far, ever. > All the talk about a 'dynamic build graph' of QBS was about satisfying this kind of case in a nice way. That's what makes it interesting to me - is that what will make QBS successful? Thanks, -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 From Jake.Petroules at qt.io Thu Sep 8 18:16:21 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 8 Sep 2016 16:16:21 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> <130321473337148@web23h.yandex.ru> Message-ID: <29DA5903-9D03-4507-9134-723A78B13F08@qt.io> Another thing that's very hard to do in other build systems is building Java code. The class files emitted by a Java compiler actually vary depending on the contents of the Java files themselves. Imagine you've built a JAR file, and then you add a new anonymous inner class within one of your Java source files. The command line invocation to build the JAR file needs to be updated to contain the new class file that will result. Impossible with qmake/CMake/Makefiles/etc. Whereas Qbs has sophisticated support exactly for this case: https://github.com/qt-labs/qbs/tree/master/share/qbs/modules/java, made possible by its dynamic build graph. On Sep 8, 2016, at 6:52 AM, Bo Thorsen > wrote: Den 08-09-2016 kl. 14:19 skrev Konstantin Tokarev: > The only problem is that you have to run moc on each of the .h files. Run moc from inside script when you generate header. Yes, I thought about that at the time as well. While simple enpough, there are some complications. You would have to run moc exactly like if it was done by the qmake built makefiles, with exactly the same environment and arguments. Not impossible, but it does sound brittle. For example different qmake versions might do things differently. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernst.maurer at gmail.com Fri Sep 9 17:08:07 2016 From: ernst.maurer at gmail.com (Ernst Maurer) Date: Fri, 09 Sep 2016 15:08:07 +0000 Subject: [Development] QBS module git cloning In-Reply-To: References: Message-ID: Each time, when I'm trying to clone qt creator I'm getting the error related with QBS (I'm not an active developer, and I do this probably monthly) Do I something wrong? because it happens always when I'm trying to get creator from git *Submodule 'qbs' (http://code.qt.io/cgit/qt-labs/qbs.git ) registered for path 'src/shared/qbs'* *Cloning into 'src/shared/qbs'...* *error: Failed connect to code.qt.io:80 ; No error (curl_result = 7, http_code = 0, sha1 = e1d5dc0b836dc6f709b2deeff2d0051d03b2c135)* *error: Unable to find f073f4556ca26a0df1e8df1d8684c61d76394c53 under http://code.qt.io/cgit/qt-labs/qbs.git * *Cannot obtain needed blob f073f4556ca26a0df1e8df1d8684c61d76394c53* *while processing commit 9bbbf55ea6d1e80871ab810eebaeaf377bc0aad0.* *error: Fetch failed.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Fri Sep 9 14:38:59 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 9 Sep 2016 12:38:59 +0000 Subject: [Development] QtCon session notes In-Reply-To: References: Message-ID: > Also put the notes to the Wiki https://wiki.qt.io/Qt_contributors_summit_2016 Suggestion: let's use the features of the tool to do the work. Add [[Category:QtCS2016]] to any pages related to this, and we can just turn the page above into the category over-view page (with a redirect, naturally). That way, you just have to set the category on your page, you don't have to also edit the page that needs to link to it. Use the strengths of the tool to our advantage ... Eddy. From edward.welbourne at qt.io Fri Sep 9 13:56:26 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 9 Sep 2016 11:56:26 +0000 Subject: [Development] Qt 5.8 API review (vs 5.7.0) In-Reply-To: References: , , Message-ID: Hi all, It's that time in the release cycle again - API review time. If you can catch a moment when Gerrit isn't hiding, please take a look at any modules you care for: https://codereview.qt-project.org/170634 -- qtbase https://codereview.qt-project.org/170635 -- qtdeclarative https://codereview.qt-project.org/170636 -- qtactiveqt https://codereview.qt-project.org/170637 -- qtmultimedia https://codereview.qt-project.org/170638 -- qttools https://codereview.qt-project.org/170639 -- qtlocation https://codereview.qt-project.org/170640 -- qtconnectivity https://codereview.qt-project.org/170641 -- qtwayland https://codereview.qt-project.org/170642 -- qt3d https://codereview.qt-project.org/170643 -- qtserialbus https://codereview.qt-project.org/170644 -- qtserialport https://codereview.qt-project.org/170645 -- qtandroidextras https://codereview.qt-project.org/170646 -- qtwebsockets https://codereview.qt-project.org/170647 -- qtwebengine https://codereview.qt-project.org/170648 -- qtcanvas3d https://codereview.qt-project.org/170649 -- qtcharts https://codereview.qt-project.org/170650 -- qtdatavis3d https://codereview.qt-project.org/170651 -- qtvirtualkeyboard https://codereview.qt-project.org/170652 -- qtscxml Eddy. From frederik.gladhorn at qt.io Fri Sep 9 16:17:14 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Fri, 9 Sep 2016 16:17:14 +0200 Subject: [Development] Gerrit down Message-ID: <1827050.pGryCThjEX@frederik-thinkcentre-m93p> Hi all, gerrit (codereview.qt-project.org) is going to be down over the weekend, unless we find out what is currently causing trouble in it. Currently it seems to stop working every few hours and the root cause is unclear. Sorry for the disturbance :( Cheers, Frederik From edward.welbourne at qt.io Fri Sep 9 11:26:36 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 9 Sep 2016 09:26:36 +0000 Subject: [Development] QUuid documentation In-Reply-To: <1975369.J7for5LNFY@tjmaciei-mobl1> References: , <1975369.J7for5LNFY@tjmaciei-mobl1> Message-ID: Benjamin Terrier: >> However, my knowledge is that whatever the method one use to generate >> your UUID, one can never guarantee its uniqueness. Meaning that the >> Qt documentation is falsely guarantying unique UUID and therefore >> should be changed. >> >> If anyone can confirm, I'll create a bug report. Thiago Macieira > Right, it's not guaranteed. It's just that the chance of collision is > virtually zero. ... and for sufficiently small values of "virtually zero", that's as close a guarantee as you'll get to anything, because no matter how well you think you can guarantee things, cosmic rays still sporadically flip bits in your memory. I read a most illuminating paper a few years back that looked at the reliability of tests of prime-ness for large numbers. There's a widely used approach that's cheap and theoretically not guaranteed but easy to apply to enough test-cases to reduce the likelihood of error to ignorably low. This was compared to the best known "provably correct" algorithm for determining primeness - which is significantly more computationally expensive. Due to the (ridiculously rare) flipping of bits by cosmic rays hitting the processor and memory, the latter was in fact *less* reliable than the former, because the former ran faster so incurred a smaller chance of errors due to stray rays. I don't think we should worry about documenting how not-quite-perfect our guarantee of UID uniqueness is in a case where - realistically - the difference from perfection is ignorable. Eddy. From frederik.gladhorn at qt.io Fri Sep 9 17:48:00 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Fri, 9 Sep 2016 17:48:00 +0200 Subject: [Development] Gerrit down In-Reply-To: <1827050.pGryCThjEX@frederik-thinkcentre-m93p> References: <1827050.pGryCThjEX@frederik-thinkcentre-m93p> Message-ID: <4728839.HbjHzZdLtd@frederik-thinkcentre-m93p> Since the problem is very likely something with the mail setup being broken, we'll disable gerrit mails - so expect not to see any emails from gerrit until this is fixed. Occasional mail might still make it, we'll try giving mails a short timeout before dropping them. The other choice to completely not have gerrit running seems even worse. Have a good weekend! Frederik On fredag 9. september 2016 16.17.14 CEST you wrote: > Hi all, > > gerrit (codereview.qt-project.org) is going to be down over the weekend, > unless we find out what is currently causing trouble in it. Currently it > seems to stop working every few hours and the root cause is unclear. > > Sorry for the disturbance :( > > Cheers, > Frederik From kevin.kofler at chello.at Fri Sep 9 13:39:31 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 09 Sep 2016 13:39:31 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> <130321473337148@web23h.yandex.ru> <29DA5903-9D03-4507-9134-723A78B13F08@qt.io> Message-ID: Jake Petroules wrote: > Another thing that's very hard to do in other build systems is building > Java code. The class files emitted by a Java compiler actually vary > depending on the contents of the Java files themselves. > > Imagine you've built a JAR file, and then you add a new anonymous inner > class within one of your Java source files. The command line invocation to > build the JAR file needs to be updated to contain the new class file that > will result. Impossible with qmake/CMake/Makefiles/etc. Well, what you can do if you have a lot of Java stuff to build is to just shell out to Ant. That's how Qt Jambi does it, for example. Use the right tool for the job. CMake has some support for building Java, but indeed, it does not automatically figure out the outputs of each .java file for you. Dedicated Java build systems are much better at that. Kevin Kofler From kevin.kofler at chello.at Fri Sep 9 13:42:27 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 09 Sep 2016 13:42:27 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> Message-ID: Bo Thorsen wrote: > I'm sure there are ways you can make the build call cmake or force a > build to fail and rebuild, and that's what you can currently do. And > those all feels annoying when you work on the project. Well, that's what CMake does by itself whenever it sees that it's needed (or at least thinks it is), e.g., if you upgraded some dependency. E.g., I've seen the CMake-produced makefiles auto-rerun CMake on my projects after upgrading Qt. Thankfully, CMake is so fast (due to being native C++ code) that it is barely noticeable. Kevin Kofler From Jake.Petroules at qt.io Thu Sep 8 22:22:25 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 8 Sep 2016 20:22:25 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <29DA5903-9D03-4507-9134-723A78B13F08@qt.io> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> <130321473337148@web23h.yandex.ru> <29DA5903-9D03-4507-9134-723A78B13F08@qt.io> Message-ID: I just found a perfect example of how hard building a JAR file is in qmake for example, compared to qbs: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qbs-javac-scan.pro Type: application/octet-stream Size: 2297 bytes Desc: qbs-javac-scan.pro URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qbs-javac-scan.qbs Type: application/octet-stream Size: 359 bytes Desc: qbs-javac-scan.qbs URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kimmo.Ollila at qt.io Fri Sep 9 14:04:57 2016 From: Kimmo.Ollila at qt.io (Kimmo Ollila) Date: Fri, 9 Sep 2016 12:04:57 +0000 Subject: [Development] Boot2Qt Device Utilities module repo Message-ID: Hi All, We are planning to open new Boot2Qt Device Utilities module repository. Qt Device Utilities module allows user manipulate easily various embedded device settings via simple QML APIs. More information can be found at the end of the blog post below: https://blog.qt.io/blog/2016/06/16/qt-5-7-for-device-creation/ I also want to propose Teemu Holappa to be the maintainer of Boot2Qt Device Utilities since he is the one who implemented the module. Br, Kimmo Ollila The Qt Company Email: Kimmo.Ollila at qt.io Mobile: + 358 50 590 9774 http://qt.io ------------------------------------------------------------------ PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. ----------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Fri Sep 9 15:21:04 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 9 Sep 2016 13:21:04 +0000 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: <2532835.dUoVZLnayI@tjmaciei-mobl1> References: <57CFB58D.2060200@qt.io> <2532835.dUoVZLnayI@tjmaciei-mobl1> Message-ID: On 08/09/16 17:13, "Development on behalf of Thiago Macieira" wrote: >On quinta-feira, 8 de setembro de 2016 07:37:28 PDT Liang Qi wrote: >> Is it better to have 5.7.2 around 5.8.0 final release and close 5.7 after >> that? 5.7.1 is very soon in a few weeks. There will be a few months gap >> between 5.7.1 and 5.8.0/5.8.1. The first release of new branch, like 5.8.0, >> sometimes it's not tested enough in user(or application developers) side, >> so some regressions or a bit critical issues will be found between 5.8.0 >> and 5.8.1. It's good for users to have a more stable release of 5.7.2. >> >> If we stick to do release like this kind of order, 5.6.2->5.7.1->5.8.0 >> Beta, it's not very difficult to have a 5.6.3->5.7.2->5.8.0 or similar. >> >> And I would like to see it becomes a convention for future releases. > >It wouldn't be bad, if the release team and merging team can make it work. Our >concern was that you and Eddy are spending far too much time on doing merges. It’s basically a question about how we can deal most efficiently with the branches we have. And both merging and cherry-picking are valid ways to work with those branches. If the branches are closely related, merging is obviously the better choice, as conflicts will be rare. But once branches start diverging more, merging will at some point start to create more overhead (and risk) than cherry-picking back into the older branch. There are several reasons, why I think we at some point should stop merging from 5.6 to newer branches. We are doing significant changes all through our code base currently. C++11 and configuration system related changes are just one example. This will lead to more and more merge conflicts as time goes by. I’ve already reviewed a few merges where it took significant effort to verify that the merge was correct. Merges are done by one person, and that person often doesn’t know all the details of what the patch causing a conflict is trying to achieve. This actually increases our risk of introducing regressions into our newer branches. Having a lot of branches also increases the complexity for all of us into figuring out where a change should go. In many cases it also does significantly increase turn-around time if a patch is needed in a newer branch. Having a long merge patch from 5.6 to dev can cause delays for all of us. If those delays get too long, this is costly for all of us and will slow us down when developing new features. A cherry-picking approach for the LTS branch can make sense, as it distributes the burden of bringing the bug fix to both the stable and LTS branch over all developers and doesn’t put it on the one person having to do the merges. It will also help limiting changes in the LTS branch to the things that should really go there. Cheers, Lars From Jake.Petroules at qt.io Sat Sep 10 00:44:34 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 9 Sep 2016 22:44:34 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> <130321473337148@web23h.yandex.ru> <29DA5903-9D03-4507-9134-723A78B13F08@qt.io> Message-ID: On Sep 9, 2016, at 4:39 AM, Kevin Kofler > wrote: Jake Petroules wrote: Another thing that's very hard to do in other build systems is building Java code. The class files emitted by a Java compiler actually vary depending on the contents of the Java files themselves. Imagine you've built a JAR file, and then you add a new anonymous inner class within one of your Java source files. The command line invocation to build the JAR file needs to be updated to contain the new class file that will result. Impossible with qmake/CMake/Makefiles/etc. Well, what you can do if you have a lot of Java stuff to build is to just shell out to Ant. That's how Qt Jambi does it, for example. Use the right tool for the job. CMake has some support for building Java, but indeed, it does not automatically figure out the outputs of each .java file for you. Dedicated Java build systems are much better at that. Last I checked, "dedicated" Java build systems (like Ant) don't even handle that case. Maybe I'm wrong but as far as I'm aware, the Java support in Qbs with regard to dependency tracking is superior to anything else out there except perhaps Buck. And no one would call that a "dedicated Java build system". Kevin Kofler _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Fri Sep 9 08:39:42 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 9 Sep 2016 08:39:42 +0200 Subject: [Development] No Gerrit notification email? Message-ID: <201609090839.42429.marc.mutz@kdab.com> Hi, I don't get notification emails from Gerrit anymore, and since the big downtime of Gerrit and dev ML two(?) days ago only sporadically. Anyone else seeing this? Or is it KDAB's mail server problem? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From bogdan at kdab.com Sat Sep 10 08:36:00 2016 From: bogdan at kdab.com (BogDan Vatra) Date: Sat, 10 Sep 2016 09:36:00 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <29DA5903-9D03-4507-9134-723A78B13F08@qt.io> Message-ID: <10680355.LQo73ebkB6@debian> On joi, 8 septembrie 2016 20:22:25 EEST Jake Petroules wrote: > I just found a perfect example of how hard building a JAR file is in qmake > for example, compared to qbs: IMHO will be even easier if instead: qbs-javac-scan.qbs: [...] files: [ "io/qt/qbs/**/*.java" ] [...] You'll write: [...] dirs: [ "io/qt/qbs/" ] [...] As any java developer is used to write in any java build system ;-) Cheers, BogDan. From marc.mutz at kdab.com Sat Sep 10 09:01:16 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 10 Sep 2016 09:01:16 +0200 Subject: [Development] Qt 5.8 API review (vs 5.7.0) In-Reply-To: References: Message-ID: <201609100901.16932.marc.mutz@kdab.com> On Friday 09 September 2016 13:56:26 Edward Welbourne wrote: > https://codereview.qt-project.org/170641 -- qtwayland > https://codereview.qt-project.org/170643 -- qtserialbus > https://codereview.qt-project.org/170652 -- qtscxml These three are exiting TP state on 5.8, so the whole API needs to be reviewed, not just changes to 5.7. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From giuseppe.dangelo at kdab.com Sat Sep 10 01:36:40 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sat, 10 Sep 2016 01:36:40 +0200 Subject: [Development] Gerrit down In-Reply-To: <4728839.HbjHzZdLtd@frederik-thinkcentre-m93p> References: <1827050.pGryCThjEX@frederik-thinkcentre-m93p> <4728839.HbjHzZdLtd@frederik-thinkcentre-m93p> Message-ID: Il 09/09/2016 17:48, Frederik Gladhorn ha scritto: > Since the problem is very likely something with the mail setup being broken, > we'll disable gerrit mails - so expect not to see any emails from gerrit until > this is fixed. Occasional mail might still make it, we'll try giving mails a > short timeout before dropping them. By the way, this very mailing list seems to suffer from something, I've just received a bunch of messages sent today which were stuck somewhere, notice the gigantic gap in time: [snip] > Received: from mx.qt-project.org (mx.qt-project.org [193.209.87.4]) > (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) > (No client certificate requested) > by mail.kdab.com (Postfix) with ESMTPS id 26B8B28070C > for ; Sat, 10 Sep 2016 00:18:07 +0200 (CEST) > X-Original-To: development at qt-project.org > Delivered-To: development at qt-project.org > Received: by mx.qt-project.org (Postfix, from userid 1233) > id 7A7A550264; Sat, 10 Sep 2016 00:18:24 +0200 (CEST) > Received: from EUR01-VE1-obe.outbound.protection.outlook.com > (mail-ve1eur01on0100.outbound.protection.outlook.com [104.47.1.100]) > by mx.qt-project.org (Postfix) with ESMTP id AA75D50262 > for ; Sat, 10 Sep 2016 00:18:23 +0200 (CEST) > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=qtcompany.onmicrosoft.com; s=selector1-qt-io; > h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; > bh=mN6vAFQ72mV+/H1wStOxJTboKGXq95PRWd5/52UDCzA=; > b=SfGAI+ERzPwuKluQOanFfg8rqTcgBrRu5aFLxhRg9ThTegmFmjXLeSOYdQAuRzh02TWyaH4y8HMcYqKuS/9vjsW9vUA4UMJWC9fap2j6YJYFlvOiQWVst++hKk3GZSrnLXvbW7pJj60K8ok+CYBQc+ptL2DwfF4N5NOYouWR+t8= > Authentication-Results: spf=none (sender IP is ) > smtp.mailfrom=Frederik.Gladhorn at qt.io; > Received: from frederik-thinkcentre-m93p.localnet (185.55.107.82) by > AM5PR0201MB2404.eurprd02.prod.outlook.com (10.169.243.142) with > Microsoft SMTP Server (version=TLS1_0, > cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) > id 15.1.609.9; Fri, 9 Sep 2016 15:48:04 +0000 > From: Frederik Gladhorn > To: > Date: Fri, 9 Sep 2016 17:48:00 +0200 Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From marc.mutz at kdab.com Sat Sep 10 09:21:58 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 10 Sep 2016 09:21:58 +0200 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: References: <57CFB58D.2060200@qt.io> <2532835.dUoVZLnayI@tjmaciei-mobl1> Message-ID: <201609100921.58625.marc.mutz@kdab.com> Hi Lars, On Friday 09 September 2016 15:21:04 Lars Knoll wrote: > A cherry-picking approach for the LTS branch can make sense, as it > distributes the burden of bringing the bug fix to both the stable and LTS > branch over all developers and doesn’t put it on the one person having to > do the merges. The obvious question is, then, why is only "the one person" doing merges? Allow more people to upload merges, and you will get the spreading you desire. (and the less obvious one: why are changes to the config system done in 5.8, and not LTS? They don't touch code, after all). > It will also help limiting changes in the LTS branch to the > things that should really go there. Which is in itself a controversial topic (see other thread). To stay on-topic: I don't see how cherry-picking would help here, as both cherry-picks and original commits to LTS will be reviewed, possibly by the same people. In fact, one could also be led to think that the perceived security of "it has passed CI in dev, so it's safe for LTS" will cause more and less appropriate commits to be backported to LTS. Or are you going to impose release branch rules (restricted staging) on 5.6, eventually? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From annulen at yandex.ru Sat Sep 10 14:37:40 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 10 Sep 2016 15:37:40 +0300 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: <201609100921.58625.marc.mutz@kdab.com> References: <57CFB58D.2060200@qt.io> <2532835.dUoVZLnayI@tjmaciei-mobl1> <201609100921.58625.marc.mutz@kdab.com> Message-ID: <130321473511060@web23o.yandex.ru> 10.09.2016, 15:32, "Marc Mutz" : > Hi Lars, > > On Friday 09 September 2016 15:21:04 Lars Knoll wrote: >>  A cherry-picking approach for the LTS branch can make sense, as it >>  distributes the burden of bringing the bug fix to both the stable and LTS >>  branch over all developers and doesn’t put it on the one person having to >>  do the merges. > > The obvious question is, then, why is only "the one person" doing merges? > Allow more people to upload merges, and you will get the spreading you desire. > > (and the less obvious one: why are changes to the config system done in 5.8, > and not LTS? They don't touch code, after all). > >>  It will also help limiting changes in the LTS branch to the >>  things that should really go there. > > Which is in itself a controversial topic (see other thread). To stay on-topic: > I don't see how cherry-picking would help here, as both cherry-picks and > original commits to LTS will be reviewed, possibly by the same people. Resolution of merge conflicts also requires review, and, in addition, may lack necessary context in place. > > In fact, one could also be led to think that the perceived security of "it has > passed CI in dev, so it's safe for LTS" will cause more and less appropriate > commits to be backported to LTS. > > Or are you going to impose release branch rules (restricted staging) on 5.6, > eventually? > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From ernst.maurer at gmail.com Fri Sep 9 17:35:36 2016 From: ernst.maurer at gmail.com (Ernst Maurer) Date: Fri, 09 Sep 2016 15:35:36 +0000 Subject: [Development] which part of the editor's shared files is a Kate from Message-ID: In my qtc-based projects, there is a lot of doxygen. Qtc contains a highlighter for doxygen-style comments, but no highlighter for doxyfile, I've wrote this (a little bit smarter than simple INI format) and using this for some time. I'd like to share , probably this can be helpful for someone else. does qtc store own copy of the highlighters? or check this out from kate editor repository ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cavendish.qi at gmail.com Sat Sep 10 17:27:48 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Sat, 10 Sep 2016 17:27:48 +0200 Subject: [Development] No Gerrit notification email? In-Reply-To: <201609090839.42429.marc.mutz@kdab.com> References: <201609090839.42429.marc.mutz@kdab.com> Message-ID: http://lists.qt-project.org/pipermail/development/2016-September/027083.html On 9 September 2016 at 08:39, Marc Mutz wrote: > Hi, > > I don't get notification emails from Gerrit anymore, and since the big > downtime of Gerrit and dev ML two(?) days ago only sporadically. > > Anyone else seeing this? Or is it KDAB's mail server problem? > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.martins at kdab.com Sat Sep 10 17:29:15 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Sat, 10 Sep 2016 16:29:15 +0100 Subject: [Development] Qt API review with clazy Message-ID: <2084014.ngmSSEkCbQ@desktop> Hi, I've been developing a Qt oriented clang compiler plugin called clazy [1]. It has about 50 custom checks/warnings for common Qt and C++ mistakes. I would like to propose clazy to be used to sanitize API of new Qt modules. Of course, only a few of the 50 checks are relevant to API, so I will only talk about those. ** Checks that can find bugs ** * clazy-copyable-polymorphic polymorphic copyable classes are usually vulnerable to slicing [2] The cases I found were either real bugs or easily fixable by adding Q_DISABLE_COPY. * clazy-rule-of-two-soft Finds when you're calling the compiler generated copy-ctor of a class that has a user-defined assign operator (and vice-versa). You'll want to write both, or none. I've found many bugs where one of them was missing (where the copy-ctor didn't have the same behavior as the assign- operator). In most cases you can simply remove the user defined methods and let the compiler generate them. * clazy-rule-of-three Either implement all 3 dtor, copy-ctor and assign-op or none of them. This is my favorite as it finds many bugs which are easy to fix. It's very common to have a class that is holding a resource and frees it in the DTOR, but if that class gets copied then two DTORs might run, freeing the resource twice, which might crash or misbehave the app. See for example https://codereview.qt-project.org/#/c/151488/ , QBasicTimer is copyable, but when a copy is destroyed it stops both timers. Also common is copying a class that has a d-pointer and getting a crash when both DTORs are run because you forgot the copy-ctor and assign-op. So either implement the copy-ctor and assign-op too, or use Q_DISABLE_COPY, or in the majority of cases, just remove your DTOR if it doesn't do any work. * mutable-container-key QMap or QHash having a key that can be modified by external factors (like QPointer) ** Nice to haves (don't find real bugs but are related to performance) ** * clazy-function-args-by-ref Pass big or non-trivial types (so copy-ctor and dtor don't get called) by const-ref * clazy-missing-typeinfo Types used in containers but missing a Q_DECLARE_TYPEINFO * clazy-qenums: Use Q_ENUM instead of Q_ENUMS * clazy-missing-qobject-macro missing a Q_OBJECT macro ** Debatable ** * clazy-function-args-by-value Pass small and trivial types by value Thanks for reading. [1] https://github.com/KDE/clazy [2] https://en.wikipedia.org/wiki/Object_slicing Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From stephen.kelly at ableton.com Fri Sep 9 12:58:36 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Fri, 9 Sep 2016 12:58:36 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> Message-ID: On 08/09/16 14:34, Christian Kandeler wrote: > On 09/08/2016 02:03 PM, Bo Thorsen wrote: >> Ok, go try it. Create a simple python or perl script that reads a file. >> The file just has a single number N inside it. And based on N the script >> outputs those files: Here's the CMake version: cmake_minimum_required(VERSION 3.5.0) project(cmaketest) find_package(Qt5Core REQUIRED) execute_process( COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5 OUTPUT_VARIABLE fileList ) string(REPLACE "\n" ";" fileList ${fileList}) add_custom_command(OUTPUT ${fileList} COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/generator.py ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5 ) qt5_wrap_cpp(moc_files ${fileList}) add_executable(servertest servertest.cpp ${fileList} ${moc_files}) target_link_libraries(servertest Qt5::Core) target_include_directories(servertest PRIVATE ${CMAKE_CURRENT_BINARY_DIR}/genoutput) However, it is cheating in the same way that the QBS version from Christian is cheating - it assumes '--list' exists: > In qbs: > > outputArtifacts: { > var p = new Process(); > try { > p.exec("path_to_script", ["--list", input.filePath]); > var files = p.readStdout.split("\n"); > Christian, can you create a version which does not require --list? As far as I understand, that is the point of the QBS dynamic build graph. I would like to make sure my understanding is correct. You can find my code at https://github.com/ske-ableton/generated-build-inputs if that helps. Thanks, -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.kelly at ableton.com Fri Sep 9 12:30:16 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Fri, 9 Sep 2016 12:30:16 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> Message-ID: On 08/09/16 14:34, Christian Kandeler wrote: > On 09/08/2016 02:03 PM, Bo Thorsen wrote: >> Ok, go try it. Create a simple python or perl script that reads a file. >> The file just has a single number N inside it. And based on N the script >> outputs those files: Here's the CMake version: cmake_minimum_required(VERSION 3.5.0) project(cmaketest) find_package(Qt5Core REQUIRED) execute_process( COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5 OUTPUT_VARIABLE fileList ) string(REPLACE "\n" ";" fileList ${fileList}) add_custom_command(OUTPUT ${fileList} COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/generator.py ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5 ) qt5_wrap_cpp(moc_files ${fileList}) add_executable(servertest servertest.cpp ${fileList} ${moc_files}) target_link_libraries(servertest Qt5::Core) target_include_directories(servertest PRIVATE ${CMAKE_CURRENT_BINARY_DIR}/genoutput) However, it is cheating in the same way that the QBS version from Christian is cheating - it assumes '--list' exists: > In qbs: > > outputArtifacts: { > var p = new Process(); > try { > p.exec("path_to_script", ["--list", input.filePath]); > var files = p.readStdout.split("\n"); > Christian, can you create a version which does not require --list? As far as I understand, that is the point of the QBS dynamic build graph. I would like to make sure my understanding is correct. I've attached the generator and servertest.cpp if that helps. Thanks, -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 -------------- next part -------------- A non-text attachment was scrubbed... Name: generator.py Type: text/x-python-script Size: 1125 bytes Desc: not available URL: -------------- next part -------------- #include "server.h" #include #include int main(int argc, char** argv) { Server server; auto m2 = server.call2(); if (m2->metaObject()->className() == QStringLiteral("Method2")) { qDebug() << "PASS"; return 0; } qDebug() << "FAIL"; return 1; } From thiago.macieira at intel.com Sat Sep 10 20:32:35 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 10 Sep 2016 11:32:35 -0700 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: <201609100921.58625.marc.mutz@kdab.com> References: <57CFB58D.2060200@qt.io> <201609100921.58625.marc.mutz@kdab.com> Message-ID: <4672110.EFd5XccrRb@tjmaciei-mobl1> On sábado, 10 de setembro de 2016 09:21:58 PDT Marc Mutz wrote: > (and the less obvious one: why are changes to the config system done in 5.8, > and not LTS? They don't touch code, after all). You mean the complete rewrite of configure and configure.exe, with a huge chunk of new qmake code that was started several months after the v5.6.0 release? The one we're still finding issues with? The one that can potentially disable a lot of previously-supported build configurations because we didn't know people used that? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jeremie.delaitre at gmail.com Sun Sep 11 23:43:46 2016 From: jeremie.delaitre at gmail.com (=?UTF-8?B?SsOpcsOpbWllIERlbGFpdHJl?=) Date: Sun, 11 Sep 2016 21:43:46 +0000 Subject: [Development] Qt API review with clazy In-Reply-To: <2084014.ngmSSEkCbQ@desktop> References: <2084014.ngmSSEkCbQ@desktop> Message-ID: Can the same checks be implemented in clang-tidy instead of having yet another tool? clang-tidy now has boost specific checks so maybe they would also accept a Qt specific module in there. On Sun, 11 Sep 2016 at 03:29 Sergio Martins wrote: > Hi, > > > I've been developing a Qt oriented clang compiler plugin called clazy [1]. > > It has about 50 custom checks/warnings for common Qt and C++ mistakes. > I would like to propose clazy to be used to sanitize API of new Qt > modules. Of > course, only a few of the 50 checks are relevant to API, so I will only > talk > about those. > > > ** Checks that can find bugs ** > > > * clazy-copyable-polymorphic > > polymorphic copyable classes are usually vulnerable to slicing [2] > The cases I found were either real bugs or easily fixable by adding > Q_DISABLE_COPY. > > > > * clazy-rule-of-two-soft > > Finds when you're calling the compiler generated copy-ctor of a class that > has > a user-defined assign operator (and vice-versa). > You'll want to write both, or none. I've found many bugs where one of them > was > missing (where the copy-ctor didn't have the same behavior as the assign- > operator). > > In most cases you can simply remove the user defined methods and let the > compiler generate them. > > > > > * clazy-rule-of-three > > Either implement all 3 dtor, copy-ctor and assign-op or none of them. > > This is my favorite as it finds many bugs which are easy to fix. > > It's very common to have a class that is holding a resource and frees it in > the DTOR, but if that class gets copied then two DTORs might run, freeing > the > resource twice, which might crash or misbehave the app. > > See for example https://codereview.qt-project.org/#/c/151488/ , > QBasicTimer is > copyable, but when a copy is destroyed it stops both timers. > > Also common is copying a class that has a d-pointer and getting a crash > when > both DTORs are run because you forgot the copy-ctor and assign-op. > > So either implement the copy-ctor and assign-op too, or use > Q_DISABLE_COPY, or > in the majority of cases, just remove your DTOR if it doesn't do any work. > > > > * mutable-container-key > > QMap or QHash having a key that can be modified by external factors (like > QPointer) > > > > > > ** Nice to haves (don't find real bugs but are related to performance) ** > > > * clazy-function-args-by-ref > > Pass big or non-trivial types (so copy-ctor and dtor don't get called) by > const-ref > > > > * clazy-missing-typeinfo > > Types used in containers but missing a Q_DECLARE_TYPEINFO > > > > * clazy-qenums: > > Use Q_ENUM instead of Q_ENUMS > > > * clazy-missing-qobject-macro > > missing a Q_OBJECT macro > > > > ** Debatable ** > > * clazy-function-args-by-value > Pass small and trivial types by value > > > Thanks for reading. > > > [1] https://github.com/KDE/clazy > [2] https://en.wikipedia.org/wiki/Object_slicing > > > > Regards, > -- > Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.martins at kdab.com Mon Sep 12 00:34:53 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Sun, 11 Sep 2016 23:34:53 +0100 Subject: [Development] Qt API review with clazy In-Reply-To: References: <2084014.ngmSSEkCbQ@desktop> Message-ID: <6355450.rNcvjOcTTX@serj-laptop> On Sunday, 11 September 2016 21:43:46 WEST Jérémie Delaitre wrote: > Can the same checks be implemented in clang-tidy instead of having yet > another tool? clang-tidy now has boost specific checks so maybe they would > also accept a Qt specific module in there. I haven't been able to use clang-tidy on big qmake projects such as Qt, it either crashes or stops with "include not found" errors. It also requires an intermediate step, where you generate a "compiler command database" file with yet another tool [1] clazy, otoh, is a compiler plugin, it integrates with your normal compilation run, you don't have to run any more tools after doing "make" as you usually do. Enabling clazy is just a matter of modifying your CXX flags, which you can easily do with qmake or mkspec. Or ENABLE_CLAZY in CMake if you're building KDE. [1] https://github.com/rizsotto/Bear Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From jani.heikkinen at qt.io Mon Sep 12 06:45:30 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 12 Sep 2016 04:45:30 +0000 Subject: [Development] Maintainers: your action needed: Qt 5.6.2 change files mostly missing! In-Reply-To: References: Message-ID: Hi all, It seems most of change files for Qt 5.6.2 is still missing from packages :( Here are the links for open changes: qt3d:https://codereview.qt-project.org/#/c/170367/ qtandroidextras: https://codereview.qt-project.org/#/c/170387/3 qtbase: https://codereview.qt-project.org/#/c/170370/ qtcanvas3d: https://codereview.qt-project.org/#/c/170369/ qtconnectivity: https://codereview.qt-project.org/#/c/170389/ qtlocation: https://codereview.qt-project.org/#/c/170413/ qtmultimedia: https://codereview.qt-project.org/#/c/170406/ qtsensors: https://codereview.qt-project.org/#/c/170379/ qtserialport:https://codereview.qt-project.org/#/c/170373/ qtwayland: https://codereview.qt-project.org/#/c/170414/ qtwebengine: https://codereview.qt-project.org/#/c/170310/ qtwebview: https://codereview.qt-project.org/#/c/170378/ Maintainers, please make sure you finalize these & get it approved today (or comment if one isn't needed in 5.6.2). These are now delaying our Qt 5.6.2 release! It seems mandatory fixes are in, we just need to get these change files in and final packages created. Then we should be ready for the release... br, Jani ________________________________ From: Jani Heikkinen Sent: Wednesday, September 7, 2016 3:27 PM To: development at qt-project.org Subject: Maintainers: your action needed Hi all (maintainers), We in the release team did initial versions of change files for Qt 5.6.2 release (to those modules where it was missing). Please take those over & finalize those as soon as possible; We are planning to release Qt 5.6.2 already during next week. Changes are pushed to gerrit as WIP so please just add/modify content, get the change approved & we will then stage those in. br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Smith at qt.io Mon Sep 12 08:30:18 2016 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 12 Sep 2016 06:30:18 +0000 Subject: [Development] Qt API review with clazy In-Reply-To: <6355450.rNcvjOcTTX@serj-laptop> References: <2084014.ngmSSEkCbQ@desktop> , <6355450.rNcvjOcTTX@serj-laptop> Message-ID: There is a flag that tells clang to keep going when it can't find something or encounters too many errors, but it is in clang 3.9. martin ________________________________ From: Development on behalf of Sergio Martins Sent: Monday, September 12, 2016 12:34:53 AM To: development at qt-project.org Subject: Re: [Development] Qt API review with clazy On Sunday, 11 September 2016 21:43:46 WEST Jérémie Delaitre wrote: > Can the same checks be implemented in clang-tidy instead of having yet > another tool? clang-tidy now has boost specific checks so maybe they would > also accept a Qt specific module in there. I haven't been able to use clang-tidy on big qmake projects such as Qt, it either crashes or stops with "include not found" errors. It also requires an intermediate step, where you generate a "compiler command database" file with yet another tool [1] clazy, otoh, is a compiler plugin, it integrates with your normal compilation run, you don't have to run any more tools after doing "make" as you usually do. Enabling clazy is just a matter of modifying your CXX flags, which you can easily do with qmake or mkspec. Or ENABLE_CLAZY in CMake if you're building KDE. [1] https://github.com/rizsotto/Bear Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gna.org Mon Sep 12 08:38:31 2016 From: chgans at gna.org (Ch'Gans) Date: Mon, 12 Sep 2016 18:38:31 +1200 Subject: [Development] Qt API review with clazy In-Reply-To: <6355450.rNcvjOcTTX@serj-laptop> References: <2084014.ngmSSEkCbQ@desktop> <6355450.rNcvjOcTTX@serj-laptop> Message-ID: On 12 September 2016 at 10:34, Sergio Martins wrote: > On Sunday, 11 September 2016 21:43:46 WEST Jérémie Delaitre wrote: >> Can the same checks be implemented in clang-tidy instead of having yet >> another tool? clang-tidy now has boost specific checks so maybe they would >> also accept a Qt specific module in there. > > I haven't been able to use clang-tidy on big qmake projects such as Qt, it > either crashes or stops with "include not found" errors. It also requires an > intermediate step, where you generate a "compiler command database" file with > yet another tool [1] Both CMake (since 2.8.5, see [1]) and Qbs (master branch) can generate this "compiler command database". Maybe your tool could be made to work with this DB (via clang-tidy) and as a clang plugin. The DB approach has the added advantage that it doesn't require modifying CXX flags, which can be a problem on projects that have "buggy" build files. Having your checks run by clang-tidy would also definitely widen your user base. clang-tidy have specific rules for LLVM, boost, google, ... Would be nice to add Qt. Chris [1] http://clang.llvm.org/docs/JSONCompilationDatabase.html#supported-systems > clazy, otoh, is a compiler plugin, it integrates with your normal compilation > run, you don't have to run any more tools after doing "make" as you usually > do. > > Enabling clazy is just a matter of modifying your CXX flags, which you can > easily do with qmake or mkspec. Or ENABLE_CLAZY in CMake if you're building > KDE. > > > [1] https://github.com/rizsotto/Bear > > Regards, > -- > Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From mathias at taschenorakel.de Mon Sep 12 09:06:40 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Mon, 12 Sep 2016 09:06:40 +0200 Subject: [Development] Qt API review with clazy In-Reply-To: References: <2084014.ngmSSEkCbQ@desktop> <6355450.rNcvjOcTTX@serj-laptop> Message-ID: <3a63ccd7-d84b-a61a-06ba-8545b3dc1c3f@taschenorakel.de> Just that the approach of clang-tidy is fundamentally wrong: You simply don't do static checks as a after thought, at random times when sun, mars and moon are in proper constellation. Why? Because when running this checks occasionally too much cruft will have accumulated that it is worth and reasonable to fix those issues: Too big chunk of boring and still expensive work. Too big risk to introduce regressions. You really want to make this checks part of your daily development experience, you want the compiler to tell you about your mistakes as soon as you compile that code for the first time. It's much easier to fix your mistakes if you just wrote them. It's much safer to fix them before even doing the first tests. Well, and you'll learn much earlier about possible anti-patterns, so you'll write less of such code. I hear you saying "but you could add clang-tidy" to your build scripts, but that's not a valid argument adding the following flags is considered too much effort already: -Xclang -load -Xclang ClangLazy.so -Xclang -add-plugin -Xclang clang-lazy Thanks, Mathias Disclaimer: I am working with Sergio and using his awesome plugin since its very first days. Am 12.09.2016 um 08:38 schrieb Ch'Gans: > On 12 September 2016 at 10:34, Sergio Martins wrote: >> On Sunday, 11 September 2016 21:43:46 WEST Jérémie Delaitre wrote: >>> Can the same checks be implemented in clang-tidy instead of having yet >>> another tool? clang-tidy now has boost specific checks so maybe they would >>> also accept a Qt specific module in there. >> >> I haven't been able to use clang-tidy on big qmake projects such as Qt, it >> either crashes or stops with "include not found" errors. It also requires an >> intermediate step, where you generate a "compiler command database" file with >> yet another tool [1] > > Both CMake (since 2.8.5, see [1]) and Qbs (master branch) can generate > this "compiler command database". > Maybe your tool could be made to work with this DB (via clang-tidy) > and as a clang plugin. > The DB approach has the added advantage that it doesn't require > modifying CXX flags, which can be a problem on projects that have > "buggy" build files. > Having your checks run by clang-tidy would also definitely widen your user base. > clang-tidy have specific rules for LLVM, boost, google, ... Would be > nice to add Qt. > > Chris > > [1] http://clang.llvm.org/docs/JSONCompilationDatabase.html#supported-systems > >> clazy, otoh, is a compiler plugin, it integrates with your normal compilation >> run, you don't have to run any more tools after doing "make" as you usually >> do. >> >> Enabling clazy is just a matter of modifying your CXX flags, which you can >> easily do with qmake or mkspec. Or ENABLE_CLAZY in CMake if you're building >> KDE. >> >> >> [1] https://github.com/rizsotto/Bear >> >> Regards, >> -- >> Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer >> Klarälvdalens Datakonsult AB, a KDAB Group company >> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >> KDAB - The Qt Experts >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From tuukka.turunen at qt.io Mon Sep 12 09:09:10 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Mon, 12 Sep 2016 07:09:10 +0000 Subject: [Development] No Gerrit notification email? In-Reply-To: <201609090839.42429.marc.mutz@kdab.com> References: <201609090839.42429.marc.mutz@kdab.com> Message-ID: Hi, There have been issues with Gerrit mail server integration, so the notifications were disabled during the weekend. We'll see if these can soon be re-enabled - but first we need to get the Gerrit / CI properly working again. Yours, Tuukka > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Marc Mutz > Sent: perjantaina 9. syyskuuta 2016 9.40 > To: development at qt-project.org > Subject: [Development] No Gerrit notification email? > > Hi, > > I don't get notification emails from Gerrit anymore, and since the big > downtime of Gerrit and dev ML two(?) days ago only sporadically. > > Anyone else seeing this? Or is it KDAB's mail server problem? > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer KDAB > (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From chgans at gna.org Mon Sep 12 09:26:54 2016 From: chgans at gna.org (Ch'Gans) Date: Mon, 12 Sep 2016 19:26:54 +1200 Subject: [Development] Qt API review with clazy In-Reply-To: <3a63ccd7-d84b-a61a-06ba-8545b3dc1c3f@taschenorakel.de> References: <2084014.ngmSSEkCbQ@desktop> <6355450.rNcvjOcTTX@serj-laptop> <3a63ccd7-d84b-a61a-06ba-8545b3dc1c3f@taschenorakel.de> Message-ID: On 12 September 2016 at 19:06, Mathias Hasselmann wrote: > Just that the approach of clang-tidy is fundamentally wrong: Hi Mathias, No offense, but you arguments are fundamentally wrong too. Your workflow is not everyone's workflow! > > You simply don't do static checks as a after thought, at random times when > sun, mars and moon are in proper constellation. I don't see the problem, people are free to choose if, when and which checks they fancy run. > Why? Because when running this checks occasionally too much cruft will have > accumulated that it is worth and reasonable to fix those issues: Too big > chunk of boring and still expensive work. Too big risk to introduce > regressions. Running clang-tidy is way slower than compiling code, a nightly check might be enough (or not, again this is a personal choice), or you could decide to run the checks systematically on pull requests because you don't trust the authors (for whatever reason, inc the usual "oops, forgot to do that", human do errors). > You really want to make this checks part of your daily development > experience, you want the compiler to tell you about your mistakes as soon as > you compile that code for the first time. It's much easier to fix your > mistakes if you just wrote them. It's much safer to fix them before even > doing the first tests. Well, and you'll learn much earlier about possible > anti-patterns, so you'll write less of such code. Maybe, but again, this is a personal choice based on personal usage of the said tool. > I hear you saying "but you could add clang-tidy" to your build scripts, but > that's not a valid argument adding the following flags is considered too > much effort already: > > -Xclang -load -Xclang ClangLazy.so -Xclang -add-plugin -Xclang clang-lazy This has nothing to do with clang-tidy, this is how you would use Sergio's *clang plugin*. Clang tidy is a separate tool that you can run externally once you have extracted the compilation database from your project. clang-tidy doesn't compile anything, it just run sanity checks, period. Sanity checks ran by clang-tidy can be of arbitrary complexity, and as such can take really long time. You might not want to be slow down by this while you're actively developing. If you go this way, then why don't you always run your applications in profiling mode to make sure you don't introduce bottle-necks or memory leaks "as-you-go"? Well we all know the answer: Because it is way too slow. Chris. > Thanks, > Mathias > > Disclaimer: I am working with Sergio and using his awesome plugin since its > very first days. > > > Am 12.09.2016 um 08:38 schrieb Ch'Gans: >> >> On 12 September 2016 at 10:34, Sergio Martins >> wrote: >>> >>> On Sunday, 11 September 2016 21:43:46 WEST Jérémie Delaitre wrote: >>>> >>>> Can the same checks be implemented in clang-tidy instead of having yet >>>> another tool? clang-tidy now has boost specific checks so maybe they >>>> would >>>> also accept a Qt specific module in there. >>> >>> >>> I haven't been able to use clang-tidy on big qmake projects such as Qt, >>> it >>> either crashes or stops with "include not found" errors. It also requires >>> an >>> intermediate step, where you generate a "compiler command database" file >>> with >>> yet another tool [1] >> >> >> Both CMake (since 2.8.5, see [1]) and Qbs (master branch) can generate >> this "compiler command database". >> Maybe your tool could be made to work with this DB (via clang-tidy) >> and as a clang plugin. >> The DB approach has the added advantage that it doesn't require >> modifying CXX flags, which can be a problem on projects that have >> "buggy" build files. >> Having your checks run by clang-tidy would also definitely widen your user >> base. >> clang-tidy have specific rules for LLVM, boost, google, ... Would be >> nice to add Qt. >> >> Chris >> >> [1] >> http://clang.llvm.org/docs/JSONCompilationDatabase.html#supported-systems >> >>> clazy, otoh, is a compiler plugin, it integrates with your normal >>> compilation >>> run, you don't have to run any more tools after doing "make" as you >>> usually >>> do. >>> >>> Enabling clazy is just a matter of modifying your CXX flags, which you >>> can >>> easily do with qmake or mkspec. Or ENABLE_CLAZY in CMake if you're >>> building >>> KDE. >>> >>> >>> [1] https://github.com/rizsotto/Bear >>> >>> Regards, >>> -- >>> Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer >>> Klarälvdalens Datakonsult AB, a KDAB Group company >>> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) >>> KDAB - The Qt Experts >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Mon Sep 12 09:33:04 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 12 Sep 2016 10:33:04 +0300 Subject: [Development] Qt API review with clazy In-Reply-To: <2084014.ngmSSEkCbQ@desktop> References: <2084014.ngmSSEkCbQ@desktop> Message-ID: <354681473665584@web30g.yandex.ru> 10.09.2016, 18:29, "Sergio Martins" : > Hi, > > I've been developing a Qt oriented clang compiler plugin called clazy [1]. > > It has about 50 custom checks/warnings for common Qt and C++ mistakes. > I would like to propose clazy to be used to sanitize API of new Qt modules. Of > course, only a few of the 50 checks are relevant to API, so I will only talk > about those. > > ** Checks that can find bugs ** > > * clazy-copyable-polymorphic > > polymorphic copyable classes are usually vulnerable to slicing [2] > The cases I found were either real bugs or easily fixable by adding > Q_DISABLE_COPY. > > * clazy-rule-of-two-soft > > Finds when you're calling the compiler generated copy-ctor of a class that has > a user-defined assign operator (and vice-versa). > You'll want to write both, or none. I've found many bugs where one of them was > missing (where the copy-ctor didn't have the same behavior as the assign- > operator). > > In most cases you can simply remove the user defined methods and let the > compiler generate them. > > * clazy-rule-of-three > > Either implement all 3 dtor, copy-ctor and assign-op or none of them. > > This is my favorite as it finds many bugs which are easy to fix. > > It's very common to have a class that is holding a resource and frees it in > the DTOR, but if that class gets copied then two DTORs might run, freeing the > resource twice, which might crash or misbehave the app. > > See for example https://codereview.qt-project.org/#/c/151488/ , QBasicTimer is > copyable, but when a copy is destroyed it stops both timers. > > Also common is copying a class that has a d-pointer and getting a crash when > both DTORs are run because you forgot the copy-ctor and assign-op. > > So either implement the copy-ctor and assign-op too, or use Q_DISABLE_COPY, or > in the majority of cases, just remove your DTOR if it doesn't do any work. > > * mutable-container-key > > QMap or QHash having a key that can be modified by external factors (like > QPointer) > > ** Nice to haves (don't find real bugs but are related to performance) ** > > * clazy-function-args-by-ref > > Pass big or non-trivial types (so copy-ctor and dtor don't get called) by > const-ref > > * clazy-missing-typeinfo > > Types used in containers but missing a Q_DECLARE_TYPEINFO > > * clazy-qenums: > > Use Q_ENUM instead of Q_ENUMS Q_ENUM increases amount of metacode generated for enum. Is it really a good idea to replace Q_ENUMS everywhere? > > * clazy-missing-qobject-macro > > missing a Q_OBJECT macro > > ** Debatable ** > > * clazy-function-args-by-value > Pass small and trivial types by value > > Thanks for reading. > > [1] https://github.com/KDE/clazy > [2] https://en.wikipedia.org/wiki/Object_slicing > > Regards, > -- > Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From Eike.Ziller at qt.io Mon Sep 12 09:46:09 2016 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 12 Sep 2016 07:46:09 +0000 Subject: [Development] which part of the editor's shared files is a Kate from In-Reply-To: References: Message-ID: <2D448FC1-6AFB-415A-94EE-F37C8CED8760@qt.io> > On Sep 9, 2016, at 5:35 PM, Ernst Maurer wrote: > > In my qtc-based projects, there is a lot of doxygen. > Qtc contains a highlighter for doxygen-style comments, > but no highlighter for doxyfile, > I've wrote this (a little bit smarter than simple INI format) > and using this for some time. I'd like to share , probably this can be helpful for someone else. > > does qtc store own copy of the highlighters? or check this out from kate editor repository ? We ship a few ourselves (http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/share/3rdparty/generic-highlighter) and since there already is the one for .dox/.doxygen, I’d say one for doxyfile would be ok to have there too. They are mostly copies from the original Kate files though, so it would be good to have the doxyfile one in Kate too. (You can also get the other Kate highlighting files by downloading them in the options > Text Editor > Generic Highlighter.) Br, Eike -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From ernst.maurer at gmail.com Mon Sep 12 09:52:28 2016 From: ernst.maurer at gmail.com (Ernst Maurer) Date: Mon, 12 Sep 2016 07:52:28 +0000 Subject: [Development] which part of the editor's shared files is a Kate from In-Reply-To: <2D448FC1-6AFB-415A-94EE-F37C8CED8760@qt.io> References: <2D448FC1-6AFB-415A-94EE-F37C8CED8760@qt.io> Message-ID: This is doxygen comments for, but I was talking about doxygen configuring files. But anyway, ok, i got пн, 12 сен 2016 г., 10:46 Eike Ziller : > > > On Sep 9, 2016, at 5:35 PM, Ernst Maurer wrote: > > > > In my qtc-based projects, there is a lot of doxygen. > > Qtc contains a highlighter for doxygen-style comments, > > but no highlighter for doxyfile, > > I've wrote this (a little bit smarter than simple INI format) > > and using this for some time. I'd like to share , probably this can be > helpful for someone else. > > > > does qtc store own copy of the highlighters? or check this out from kate > editor repository ? > > We ship a few ourselves ( > http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/share/3rdparty/generic-highlighter > ) > and since there already is the one for .dox/.doxygen, I’d say one for > doxyfile would be ok to have there too. > They are mostly copies from the original Kate files though, so it would be > good to have the doxyfile one in Kate too. > (You can also get the other Kate highlighting files by downloading them in > the options > Text Editor > Generic Highlighter.) > > Br, Eike > > -- > Eike Ziller > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > eike.ziller at qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh at theharmers.co.uk Mon Sep 12 09:59:03 2016 From: sh at theharmers.co.uk (Sean Harmer) Date: Mon, 12 Sep 2016 09:59:03 +0200 Subject: [Development] Maintainers: your action needed: Qt 5.6.2 change files mostly missing! In-Reply-To: References: Message-ID: Hi, Qt 3D doesn’t need one for 5.6.2. Cheers, Sean > On 12 Sep 2016, at 06:45, Jani Heikkinen wrote: > > Hi all, > > It seems most of change files for Qt 5.6.2 is still missing from packages :( Here are the links for open changes: > > qt3d:https://codereview.qt-project.org/#/c/170367/ > qtandroidextras: https://codereview.qt-project.org/#/c/170387/3 > qtbase: https://codereview.qt-project.org/#/c/170370/ qtcanvas3d: https://codereview.qt-project.org/#/c/170369/ > qtconnectivity: https://codereview.qt-project.org/#/c/170389/ > qtlocation: https://codereview.qt-project.org/#/c/170413/ qtmultimedia: https://codereview.qt-project.org/#/c/170406/ > qtsensors: https://codereview.qt-project.org/#/c/170379/ qtserialport:https://codereview.qt-project.org/#/c/170373/ > qtwayland: https://codereview.qt-project.org/#/c/170414/ qtwebengine: https://codereview.qt-project.org/#/c/170310/ > qtwebview: https://codereview.qt-project.org/#/c/170378/ > > > Maintainers, please make sure you finalize these & get it approved today (or comment if one isn't needed in 5.6.2). These are now delaying our Qt 5.6.2 release! It seems mandatory fixes are in, we just need to get these change files in and final packages created. Then we should be ready for the release... > > br, > Jani > > > > From: Jani Heikkinen > Sent: Wednesday, September 7, 2016 3:27 PM > To: development at qt-project.org > Subject: Maintainers: your action needed > > Hi all (maintainers), > > We in the release team did initial versions of change files for Qt 5.6.2 release (to those modules where it was missing). Please take those over & finalize those as soon as possible; We are planning to release Qt 5.6.2 already during next week. Changes are pushed to gerrit as WIP so please just add/modify content, get the change approved & we will then stage those in. > > br, > Jani > > Jani Heikkinen > Release Manager > > The Qt Company > Elektroniikkatie 13 > 90590 Oulu Finland > jani.heikkinen at qt.io > +358 50 4873735 > http://qt.io > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathias at taschenorakel.de Mon Sep 12 10:25:53 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Mon, 12 Sep 2016 10:25:53 +0200 Subject: [Development] Qt API review with clazy In-Reply-To: <354681473665584@web30g.yandex.ru> References: <2084014.ngmSSEkCbQ@desktop> <354681473665584@web30g.yandex.ru> Message-ID: <66da1f29-589e-8db4-feae-76dd1df0eaeb@taschenorakel.de> Am 12.09.2016 um 09:33 schrieb Konstantin Tokarev: >> Use Q_ENUM instead of Q_ENUMS > > Q_ENUM increases amount of metacode generated for enum. Is it really a good idea to replace Q_ENUMS everywhere? One thing that makes Qt easy to use is consistency. Once you know enough of its classes using most other class is trivial as you know what to expect, what to look for. So if ease of use and therefore consistency is a goal of Qt I am happily paying that price. Anywhere: Where would you draw the line for Q_ENUM vs. Q_ENUMS enums? Any rule about this would be arbitrary and therefore hard to remember, hard to get consistent. I am a big fan of Q_ENUMS, the benefits it adds for QML and the benefits it adds for debugging, the benefits it adds for reliable data serialization. Ciao, Mathias From mitch.curtis at qt.io Mon Sep 12 10:30:28 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Mon, 12 Sep 2016 08:30:28 +0000 Subject: [Development] Qt 5.8 API review (vs 5.7.0) In-Reply-To: References: , , Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- > project.org] On Behalf Of Edward Welbourne > Sent: Friday, 9 September 2016 1:56 PM > To: development at qt-project.org > Subject: [Development] Qt 5.8 API review (vs 5.7.0) > > Hi all, > > It's that time in the release cycle again - API review time. > If you can catch a moment when Gerrit isn't hiding, please take a look at > any modules you care for: > > https://codereview.qt-project.org/170634 -- qtbase > https://codereview.qt-project.org/170635 -- qtdeclarative > https://codereview.qt-project.org/170636 -- qtactiveqt > https://codereview.qt-project.org/170637 -- qtmultimedia > https://codereview.qt-project.org/170638 -- qttools > https://codereview.qt-project.org/170639 -- qtlocation > https://codereview.qt-project.org/170640 -- qtconnectivity > https://codereview.qt-project.org/170641 -- qtwayland > https://codereview.qt-project.org/170642 -- qt3d > https://codereview.qt-project.org/170643 -- qtserialbus > https://codereview.qt-project.org/170644 -- qtserialport > https://codereview.qt-project.org/170645 -- qtandroidextras > https://codereview.qt-project.org/170646 -- qtwebsockets > https://codereview.qt-project.org/170647 -- qtwebengine > https://codereview.qt-project.org/170648 -- qtcanvas3d > https://codereview.qt-project.org/170649 -- qtcharts > https://codereview.qt-project.org/170650 -- qtdatavis3d > https://codereview.qt-project.org/170651 -- qtvirtualkeyboard qtvirtualkeyboard looks OK. > https://codereview.qt-project.org/170652 -- qtscxml > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From ulf.hermann at qt.io Mon Sep 12 10:41:43 2016 From: ulf.hermann at qt.io (Ulf Hermann) Date: Mon, 12 Sep 2016 10:41:43 +0200 Subject: [Development] Qt API review with clazy In-Reply-To: <66da1f29-589e-8db4-feae-76dd1df0eaeb@taschenorakel.de> References: <2084014.ngmSSEkCbQ@desktop> <354681473665584@web30g.yandex.ru> <66da1f29-589e-8db4-feae-76dd1df0eaeb@taschenorakel.de> Message-ID: <0dfa259a-81ce-e7ec-6cfc-bd55da1a9a75@qt.io> On 09/12/2016 10:25 AM, Mathias Hasselmann wrote: > Am 12.09.2016 um 09:33 schrieb Konstantin Tokarev: >>> Use Q_ENUM instead of Q_ENUMS >> >> Q_ENUM increases amount of metacode generated for enum. Is it really a good idea to replace Q_ENUMS everywhere? > > One thing that makes Qt easy to use is consistency. Once you know enough of its classes using most other class is trivial as you know what to expect, what to look for. > > So if ease of use and therefore consistency is a goal of Qt > I am happily paying that price. > > Anywhere: Where would you draw the line for Q_ENUM vs. Q_ENUMS enums? Any rule about this would be arbitrary and therefore hard to remember, hard to get consistent. Following this argument you'll have to draw the line at public Qt headers vs other other Qt code. The user will see the nice consistency and we can still save some metacode where we don't need the benefits of Q_ENUM. I haven't checked how much space it actually saves, though. regards, Ulf From edward.welbourne at qt.io Mon Sep 12 10:59:20 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 12 Sep 2016 08:59:20 +0000 Subject: [Development] QBS module git cloning In-Reply-To: References: , Message-ID: Ernst Maurer said: > Each time, when I'm trying to clone qt creator I'm getting the error related with QBS I'm able to clone this repo without problems, both bare and with work-tree. The cloned repos appear entirely sane. > Submodule 'qbs' (http://code.qt.io/cgit/qt-labs/qbs.git) registered for path 'src/shared/qbs' It's conceivable the git submodule infrastructure is what's causing the problem. I just cloned qbs directly, rather than via cloning of creator. My commands were git clone --bare http://code.qt.io/cgit/qt-labs/qbs.git and the same without --bare (run on Debian/testing GNU/Linux). What source are you cloning creator from ? What's the actual clone command you run ? What sort of system are you running this from ? > error: Failed connect to code.qt.io:80; No error (curl_result = 7, http_code = 0, sha1 = e1d5dc0b836dc6f709b2deeff2d0051d03b2c135) The curl man-page decodes curl_result = 7 as: 7 Failed to connect to host. You clearly connected repeatedly to the host to fetch other blobs, failing just this once. I'd guess flaky network (or flaky server), but you say this recurs. Does it always fail with the same sha1s or do they vary ? > error: Unable to find f073f4556ca26a0df1e8df1d8684c61d76394c53 under http://code.qt.io/cgit/qt-labs/qbs.git > Cannot obtain needed blob f073f4556ca26a0df1e8df1d8684c61d76394c53 My clone contains this blob: it is a version of file tests/auto/api/tst_api.cpp > while processing commit 9bbbf55ea6d1e80871ab810eebaeaf377bc0aad0. > error: Fetch failed. This commit is a few steps short of branch 1.4. I am able to access it without problems in my clones. However, if you failed to fetch one of its blobs, it would indeed be broken. Eddy. From mathias at taschenorakel.de Mon Sep 12 11:13:27 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Mon, 12 Sep 2016 11:13:27 +0200 Subject: [Development] Qt API review with clazy In-Reply-To: References: <2084014.ngmSSEkCbQ@desktop> <6355450.rNcvjOcTTX@serj-laptop> <3a63ccd7-d84b-a61a-06ba-8545b3dc1c3f@taschenorakel.de> Message-ID: Hello Chris, > On 12 September 2016 at 19:06, Mathias Hasselmann > wrote: >> Just that the approach of clang-tidy is fundamentally wrong: > > Hi Mathias, > > No offense, but you arguments are fundamentally wrong too. Your > workflow is not everyone's workflow! > >> >> You simply don't do static checks as a after thought, at random times when >> sun, mars and moon are in proper constellation. > > I don't see the problem, people are free to choose if, when and which > checks they fancy run. > >> Why? Because when running this checks occasionally too much cruft will have >> accumulated that it is worth and reasonable to fix those issues: Too big >> chunk of boring and still expensive work. Too big risk to introduce >> regressions. > > Running clang-tidy is way slower than compiling code, a nightly check > might be enough (or not, again this is a personal choice), or you > could decide to run the checks systematically on pull requests because > you don't trust the authors (for whatever reason, inc the usual "oops, > forgot to do that", human do errors). > Sanity checks ran by clang-tidy can be of arbitrary complexity, and as > such can take really long time. You might not want to be slow down by > this while you're actively developing. Well, with clang-tidy being slow you just gave another reason to have a compiler plugin for this quick, very obvious tests. In my experience clazy has no measurable impact to compile time. > If you go this way, then why don't you always run your applications in > profiling mode to make sure you don't introduce bottle-necks or memory > leaks "as-you-go"? Well we all know the answer: Because it is way too > slow. Besides clazy being blasting fast you are comparing apples with oranges. The issues clazy blames are plain Qt usage bugs. Just the same kind of issues the compiler reports for regular C++ already. Ideally the compilers would checks those issues out of the box already. Obviously they can't because Qt layers stuff on top of C++. Ciao, Mathias From edward.welbourne at qt.io Mon Sep 12 11:20:41 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 12 Sep 2016 09:20:41 +0000 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: <201609100921.58625.marc.mutz@kdab.com> References: <57CFB58D.2060200@qt.io> <2532835.dUoVZLnayI@tjmaciei-mobl1> , <201609100921.58625.marc.mutz@kdab.com> Message-ID: Marc Mutz said: > The obvious question is, then, why is only "the one person" doing merges? > Allow more people to upload merges, and you will get the spreading you desire. Several people can upload merges. One person looks after integration in qt5 and all its sub-modules. We can spread the load (indeed, I carried it for a few weeks while Liang was on holiday), and I believe module owners can do their own merges (which saves the integration team work), but the integration team takes responsibility for ensuring merges are happening. So it ends up being that Liang, as integrator, does most merges. > In fact, one could also be led to think that the perceived security of "it has > passed CI in dev, so it's safe for LTS" will cause more and less appropriate > commits to be backported to LTS. I shall amend sanity-bot to object to cherry-picks to LTS unless they come from gerrit/stable. So "it has passed CI in dev" won't get it into LTS. It has to have passed review and CI in stable to be a candidate for cherry-picking to LTS. Then the second review can haggle about whether it belongs in LTS. That can take a long time without delaying the change's merge-journey up to dev. Eddy. From annulen at yandex.ru Mon Sep 12 11:34:29 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 12 Sep 2016 12:34:29 +0300 Subject: [Development] QBS module git cloning In-Reply-To: References: Message-ID: <1145071473672869@web26o.yandex.ru> 10.09.2016, 01:10, "Ernst Maurer" : > Each time, when I'm trying to clone qt creator I'm getting the error related with QBS >  (I'm not an active developer, and I do this probably monthly) > Do I something wrong? because it happens always when I'm trying to get creator from git > > Submodule 'qbs' (http://code.qt.io/cgit/qt-labs/qbs.git) registered for path 'src/shared/qbs' > > Cloning into 'src/shared/qbs'... > > error: Failed connect to code.qt.io:80; No error (curl_result = 7, http_code = 0, sha1 = e1d5dc0b836dc6f709b2deeff2d0051d03b2c135) > > error: Unable to find f073f4556ca26a0df1e8df1d8684c61d76394c53 under http://code.qt.io/cgit/qt-labs/qbs.git > Cannot obtain needed blob f073f4556ca26a0df1e8df1d8684c61d76394c53 > while processing commit 9bbbf55ea6d1e80871ab810eebaeaf377bc0aad0. > error: Fetch failed. That's probably unrelated to you issue, but I'd recommended you to use git protocol instead of http -- Regards, Konstantin From Morten.Sorvig at qt.io Mon Sep 12 11:37:58 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Mon, 12 Sep 2016 09:37:58 +0000 Subject: [Development] QtCon 2016 session notes: Qt for macOS Message-ID: Session held friday september 2nd. Around 15 persons in attendance, with a good mix of full-time Qt developers, Qt contributors, and Qt application developers. 1) We briefly went through the work on QTBUG-49827 (Qt on macOS Graphics/integration update): Development of native autotests and manual tests. Layer-backed QWindows. Color space support. Improving support for embedding QWindow in native view hierarchies. This was mostly information sharing. Some questions were asked (and answered): Q: Should layer mode be enabled by default, like on UIKit? A: Maybe. Let’s make it work first. Q: Will this require changes to application code? A: The goal is no changes to application code. Some changes to non-platform plugin code may be wanted, for example all QWindow users should drive animations using QWindow::requestUpdate(). 2) We discussed dropping 32-bit support, which will enable us to (easily) use automated reference counting (ARC) internally. As of today Qt does not support any 32-bit mac hardware, the only reason for keeping 32-bit going is to support applications with 32-bit components (non 64-bit clean source code or 32-bit only binaries). Other Apple platforms are 64-bit only. In favor of keeping 32-bit support is the normal “Qt runs everywhere” argument, and not having macOS be the only (desktop) port without 32-bit support. Recommendation: We deprecate/obsolete 32-bit builds and phase in ARC usage in all apple-platform code. 3) Notifications: There are patches for improving native notification support. https://codereview.qt-project.org/#/c/166456/ (and one more) Do we want a new module? Cross-platform support via plugins. Can the deprecate existing QSystrayIcon/platform plugin support Some API revising needed. Do we want a signal-slot API to support user interaction with the notification. 4) Optional private API usage. We may be able to improve e.g. the Mac style (see below) by using private API. Apparently there are instances of private API usage on the App store, also from “big name” applications. Recommendation: Okay as long as applications have to opt-in to taking the risk (the default Qt build is app-store compliant) 5) Styling: The mac style can be improved, with some/much effort. At the same time it does not help us in the native “feel”. Improvement: use new (10.7) alignment rectangle API. Improvement: perhaps also by using the CoreUI private framework directly. If exact native behavior is needed: use native components, for example NSToolBar directly, or wrapped via QMacToolBar. Meta-point: how do we (Qt) deal with continuing platform divergence? We ran out of time and may have missed some topics and/or input - following up on this email is possible. Morten From ernst.maurer at gmail.com Mon Sep 12 11:45:43 2016 From: ernst.maurer at gmail.com (Ernst Maurer) Date: Mon, 12 Sep 2016 09:45:43 +0000 Subject: [Development] QBS module git cloning In-Reply-To: <1145071473672869@web26o.yandex.ru> References: <1145071473672869@web26o.yandex.ru> Message-ID: Thank you, I'll try. Seems it doesn't work from time to time, Yesterday, I could do this, with no issues пн, 12 сен 2016 г., 12:34 Konstantin Tokarev : > > > 10.09.2016, 01:10, "Ernst Maurer" : > > Each time, when I'm trying to clone qt creator I'm getting the error > related with QBS > > (I'm not an active developer, and I do this probably monthly) > > Do I something wrong? because it happens always when I'm trying to get > creator from git > > > > Submodule 'qbs' (http://code.qt.io/cgit/qt-labs/qbs.git) registered for > path 'src/shared/qbs' > > > > Cloning into 'src/shared/qbs'... > > > > error: Failed connect to code.qt.io:80; No error (curl_result = 7, > http_code = 0, sha1 = e1d5dc0b836dc6f709b2deeff2d0051d03b2c135) > > > > error: Unable to find f073f4556ca26a0df1e8df1d8684c61d76394c53 under > http://code.qt.io/cgit/qt-labs/qbs.git > > Cannot obtain needed blob f073f4556ca26a0df1e8df1d8684c61d76394c53 > > while processing commit 9bbbf55ea6d1e80871ab810eebaeaf377bc0aad0. > > error: Fetch failed. > > That's probably unrelated to you issue, but I'd recommended you to use git > protocol instead of http > > > -- > Regards, > Konstantin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Mon Sep 12 11:46:31 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Mon, 12 Sep 2016 09:46:31 +0000 Subject: [Development] Maintainers: your action needed: Qt 5.6.2 change files mostly missing! In-Reply-To: References: Message-ID: Hi Sean, > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Sean Harmer > Sent: Monday, 12 September 2016 9:59 > Qt 3D doesn’t need one for 5.6.2. If that's the case then please add a statement to the change log telling the reader that there were no noteworthy changes. To the Qt user there is no way to distinguish a missing change log due to no changes from a missing change log because we didn't write it (despite having potentially a lot). In my opinion there are noteworthy changes in Qt3D. There are 2 bugs fixed and hover event related changes... Don't you think this is relevant? -- Alex From edward.welbourne at qt.io Mon Sep 12 11:47:26 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 12 Sep 2016 09:47:26 +0000 Subject: [Development] Qt 5.8 API review (vs 5.7.0) In-Reply-To: References: , , , Message-ID: I mentioned: >> https://codereview.qt-project.org/170651 -- qtvirtualkeyboard Mitch Curtis replied: > qtvirtualkeyboard looks OK. Please give review responses on the reviews themselves (if you can catch Gerrit up for long enough to do so). Eddy. From chgans at gna.org Mon Sep 12 11:56:50 2016 From: chgans at gna.org (Ch'Gans) Date: Mon, 12 Sep 2016 21:56:50 +1200 Subject: [Development] Qt API review with clazy In-Reply-To: References: <2084014.ngmSSEkCbQ@desktop> <6355450.rNcvjOcTTX@serj-laptop> <3a63ccd7-d84b-a61a-06ba-8545b3dc1c3f@taschenorakel.de> Message-ID: On 12 September 2016 at 21:13, Mathias Hasselmann wrote: > Hello Chris, > >> On 12 September 2016 at 19:06, Mathias Hasselmann >> wrote: >>> >>> Just that the approach of clang-tidy is fundamentally wrong: >> >> >> Hi Mathias, >> >> No offense, but you arguments are fundamentally wrong too. Your >> workflow is not everyone's workflow! >> >>> >>> You simply don't do static checks as a after thought, at random times >>> when >>> sun, mars and moon are in proper constellation. >> >> >> I don't see the problem, people are free to choose if, when and which >> checks they fancy run. >> >>> Why? Because when running this checks occasionally too much cruft will >>> have >>> accumulated that it is worth and reasonable to fix those issues: Too big >>> chunk of boring and still expensive work. Too big risk to introduce >>> regressions. >> >> >> Running clang-tidy is way slower than compiling code, a nightly check >> might be enough (or not, again this is a personal choice), or you >> could decide to run the checks systematically on pull requests because >> you don't trust the authors (for whatever reason, inc the usual "oops, >> forgot to do that", human do errors). > >> Sanity checks ran by clang-tidy can be of arbitrary complexity, and as >> such can take really long time. You might not want to be slow down by >> this while you're actively developing. > > Well, with clang-tidy being slow you just gave another reason to have a > compiler plugin for this quick, very obvious tests. In my experience clazy > has no measurable impact to compile time. I never said that clazy was not useful, I was just saying that you should use the right tool for the right job. Both tools are complimentary, people have different use-cases. > >> If you go this way, then why don't you always run your applications in >> profiling mode to make sure you don't introduce bottle-necks or memory >> leaks "as-you-go"? Well we all know the answer: Because it is way too >> slow. > > > Besides clazy being blasting fast you are comparing apples with oranges. The > issues clazy blames are plain Qt usage bugs. Just the same kind of issues > the compiler reports for regular C++ already. Ideally the compilers would > checks those issues out of the box already. Obviously they can't because Qt > layers stuff on top of C++. Effectively, I'm not sure we're talking about the same things here. Maybe clazy plugin could be even use by Qtc clang code model if it's that fast (I really like the "compile errors/warnings" as you type, altho not perfect). I was talking about "deeper" checks, like the ones listed in the "group of checks" table as per http://clang.llvm.org/extra/clang-tidy/index.html#using-clang-tidy They are really more than what clazy proposes (for now). And you definitely don't want them to be run each time you build your app. So, all in all, it looks to me that the clazy plugin is the way to go for fast checks, and clang-tidy for the more thoughtfully ones. Hence my message about being able to use these new checks both form the compiler command and from an external tool such as clang-tidy. Deeper, time-consuming, Qt-specific checks would be welcome as a new clang-tidy check group. The checks clang-tidy propose are not limited to "potential bugs", it does cover as well coding guideline and styles and AFAIR Qt use custom perl scripts for style and basic errors checking (might have changed since last time i checked). Cherry on the cake, with clang-tidy (actually a llvm feature used by clang-tidy) is that it can generates the fixes as well, and even apply them in one go. A feature which I believe is used by QtC to propose you the "hot fix" accessible with Alt-Return (On Linux). "clang-tidy -checks=* -list-checks" here gives me a list of 184 checks (LLVM v3.8.0). Not all are useful and some of them are not always applicable or sometimes give false positive, but it should give you a fair idea of what does already exists in there. Chris > > Ciao, > Mathias From chgans at gna.org Mon Sep 12 12:04:47 2016 From: chgans at gna.org (Ch'Gans) Date: Mon, 12 Sep 2016 22:04:47 +1200 Subject: [Development] Qt API review with clazy In-Reply-To: References: <2084014.ngmSSEkCbQ@desktop> <6355450.rNcvjOcTTX@serj-laptop> <3a63ccd7-d84b-a61a-06ba-8545b3dc1c3f@taschenorakel.de> Message-ID: On 12 September 2016 at 21:13, Mathias Hasselmann wrote: > Hello Chris, [...] > Besides clazy being blasting fast you are comparing apples with oranges. The > issues clazy blames are plain Qt usage bugs. Just the same kind of issues > the compiler reports for regular C++ already. Ideally the compilers would > checks those issues out of the box already. Obviously they can't because Qt > layers stuff on top of C++. BTW, have you tried to use clazy by adding the flags in QtC C++ clang model? (tools->options->C++->code model) I have no clue if it is even doable, i'm just asking. Chris > > Ciao, > Mathias From milian.wolff at kdab.com Mon Sep 12 12:55:49 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Mon, 12 Sep 2016 12:55:49 +0200 Subject: [Development] Qt API review with clazy In-Reply-To: References: <2084014.ngmSSEkCbQ@desktop> Message-ID: <3214013.CFY5PYbUSz@agathebauer> On Montag, 12. September 2016 22:04:47 CEST Ch'Gans wrote: > On 12 September 2016 at 21:13, Mathias Hasselmann > > wrote: > > Hello Chris, > > [...] > > > Besides clazy being blasting fast you are comparing apples with oranges. > > The issues clazy blames are plain Qt usage bugs. Just the same kind of > > issues the compiler reports for regular C++ already. Ideally the > > compilers would checks those issues out of the box already. Obviously > > they can't because Qt layers stuff on top of C++. > > BTW, have you tried to use clazy by adding the flags in QtC C++ clang > model? (tools->options->C++->code model) > I have no clue if it is even doable, i'm just asking. It's possible. We did that in KDevelop. But it depends on a libclang patch that was not yet accepted upstream: https://reviews.llvm.org/D15729 Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From Simon.Hausmann at qt.io Mon Sep 12 13:25:16 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 12 Sep 2016 11:25:16 +0000 Subject: [Development] Maintainers: your action needed: Qt 5.6.2 change files mostly missing! In-Reply-To: References: , Message-ID: Hi, It should be noted that Qt3D has "preview" status in the Qt 5.6 branch. So I don't think anybody should rely on the content of qt3d in the 5.6 branch and consequently look for a changelog :) Simon ________________________________ From: Development on behalf of Alexander Blasche Sent: Monday, September 12, 2016 11:46:31 AM To: Sean Harmer; Jani Heikkinen Cc: development at qt-project.org Subject: Re: [Development] Maintainers: your action needed: Qt 5.6.2 change files mostly missing! Hi Sean, > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Sean Harmer > Sent: Monday, 12 September 2016 9:59 > Qt 3D doesn’t need one for 5.6.2. If that's the case then please add a statement to the change log telling the reader that there were no noteworthy changes. To the Qt user there is no way to distinguish a missing change log due to no changes from a missing change log because we didn't write it (despite having potentially a lot). In my opinion there are noteworthy changes in Qt3D. There are 2 bugs fixed and hover event related changes... Don't you think this is relevant? -- Alex _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From orgads at gmail.com Mon Sep 12 13:39:57 2016 From: orgads at gmail.com (Orgad Shaneh) Date: Mon, 12 Sep 2016 14:39:57 +0300 Subject: [Development] [Qt-creator] [FYI] on gerrit change retargeting requests In-Reply-To: References: <20160831141255.GG2429@troll08> <201609051854.25469.marc.mutz@kdab.com> <201609051929.30738.marc.mutz@kdab.com> <04C718D5-89D8-496E-AA6A-6118CC41839B@qt.io> <20160906094334.GB7954@nubble> <123431473155184@web6h.yandex.ru> Message-ID: On Tue, Sep 6, 2016 at 12:56 PM, J-P Nurmi wrote: > On 06 Sep 2016, at 11:46, Konstantin Tokarev wrote: > > > > > > > > 06.09.2016, 12:44, "Oswald Buddenhagen" : > >>> On Mon, Sep 05, 2016 at 09:17:59PM +0000, J-P Nurmi wrote: > >>> On 05 Sep 2016, at 19:27, Marc Mutz wrote: > >>> > It's not about restricting what a user can do. It's simply missing > >>> > implementation, and I believe that if it were easy to implement, > >>> > Ossi would have done it long ago instead of playing retarget-monkey > >>> > for the rest of us :) > >>> > >>> Doing it through the web UI would be a nice bonus, but having access > >>> to the same script that is already used by the admins would be good > >>> enough for starters. > >> > >> yep - because i'm totally going to give everyone full write access to > >> the database. ;) > >> > >> if you make a secure web frontend that authenticates against qt account > >> and verifies change ownership using the gerrit ssh interface, i'm > >> totally willing to deploy that. ;) > > > > Idea: IRC bot accepting retarget requests, with rate limit e.g. one > request per minute. Bot runs on host with db access and can do only this > one thing. > > Another idea: patch Gerrit to change the target branch (and create a new > patchset version to reset scores) when pushing to a different branch. > I have another suggestion, which should be quite easy to implement. Either extend the sanity bot, or create a new bot, which listens on gerrit's event stream. If *the change's owner* (or an approver?) posts a comment reading "Please retarget ", run your script on the server side. You need some sanity test that ensures this branch exists etc... What do you say? - Orgad -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Mon Sep 12 14:01:31 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Mon, 12 Sep 2016 12:01:31 +0000 Subject: [Development] Maintainers: your action needed: Qt 5.6.2 change files mostly missing! In-Reply-To: References: , , Message-ID: Ok, I was not aware of TP status. In this case I stand corrected. -- Alex ________________________________________ From: Simon Hausmann Sent: Monday, 12 September 2016 1:25:16 PM To: Alexander Blasche; Sean Harmer; Jani Heikkinen Cc: development at qt-project.org Subject: Re: [Development] Maintainers: your action needed: Qt 5.6.2 change files mostly missing! Hi, It should be noted that Qt3D has "preview" status in the Qt 5.6 branch. So I don't think anybody should rely on the content of qt3d in the 5.6 branch and consequently look for a changelog :) Simon ________________________________ From: Development on behalf of Alexander Blasche Sent: Monday, September 12, 2016 11:46:31 AM To: Sean Harmer; Jani Heikkinen Cc: development at qt-project.org Subject: Re: [Development] Maintainers: your action needed: Qt 5.6.2 change files mostly missing! Hi Sean, > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Sean Harmer > Sent: Monday, 12 September 2016 9:59 > Qt 3D doesn’t need one for 5.6.2. If that's the case then please add a statement to the change log telling the reader that there were no noteworthy changes. To the Qt user there is no way to distinguish a missing change log due to no changes from a missing change log because we didn't write it (despite having potentially a lot). In my opinion there are noteworthy changes in Qt3D. There are 2 bugs fixed and hover event related changes... Don't you think this is relevant? -- Alex _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From frederik.gladhorn at qt.io Mon Sep 12 14:03:36 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Mon, 12 Sep 2016 14:03:36 +0200 Subject: [Development] Gerrit down In-Reply-To: References: <1827050.pGryCThjEX@frederik-thinkcentre-m93p> <4728839.HbjHzZdLtd@frederik-thinkcentre-m93p> Message-ID: <40950885.xNqieUmXmH@frederik-thinkcentre-m93p> Both gerrit and mailing lists should be running again. It seems like there was a problem with DNS on the machine that runs the mail server and mailman. I don't know the exact details, but the machine has been fixed and also the backups have been tuned, so mails and gerrit should be rolling again. There are still seven changes in a weird state, I'll clean these up now, but I don't want to risk creating a bigger mess, so it'll take a bit of time to fully understand which state they are in. Gerrit shows them in integrating state and the CI thinks they're done. Happy hacking! Frederik On lørdag 10. september 2016 01.36.40 CEST Giuseppe D'Angelo wrote: > Il 09/09/2016 17:48, Frederik Gladhorn ha scritto: > > Since the problem is very likely something with the mail setup being > > broken, we'll disable gerrit mails - so expect not to see any emails from > > gerrit until this is fixed. Occasional mail might still make it, we'll > > try giving mails a short timeout before dropping them. > > By the way, this very mailing list seems to suffer from something, I've > just received a bunch of messages sent today which were stuck somewhere, > notice the gigantic gap in time: > > [snip] > > > Received: from mx.qt-project.org (mx.qt-project.org [193.209.87.4]) > > > > (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) > > (No client certificate requested) > > by mail.kdab.com (Postfix) with ESMTPS id 26B8B28070C > > for ; Sat, 10 Sep 2016 00:18:07 +0200 (CEST) > > > > X-Original-To: development at qt-project.org > > Delivered-To: development at qt-project.org > > Received: by mx.qt-project.org (Postfix, from userid 1233) > > > > id 7A7A550264; Sat, 10 Sep 2016 00:18:24 +0200 (CEST) > > > > Received: from EUR01-VE1-obe.outbound.protection.outlook.com > > > > (mail-ve1eur01on0100.outbound.protection.outlook.com [104.47.1.100]) > > by mx.qt-project.org (Postfix) with ESMTP id AA75D50262 > > for ; Sat, 10 Sep 2016 00:18:23 +0200 (CEST) > > > > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > > > > d=qtcompany.onmicrosoft.com; s=selector1-qt-io; > > h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; > > bh=mN6vAFQ72mV+/H1wStOxJTboKGXq95PRWd5/52UDCzA=; > > b=SfGAI+ERzPwuKluQOanFfg8rqTcgBrRu5aFLxhRg9ThTegmFmjXLeSOYdQAuRzh02TWyaH4 > > y8HMcYqKuS/9vjsW9vUA4UMJWC9fap2j6YJYFlvOiQWVst++hKk3GZSrnLXvbW7pJj60K8ok+ > > CYBQc+ptL2DwfF4N5NOYouWR+t8=> > > Authentication-Results: spf=none (sender IP is ) > > > > smtp.mailfrom=Frederik.Gladhorn at qt.io; > > > > Received: from frederik-thinkcentre-m93p.localnet (185.55.107.82) by > > > > AM5PR0201MB2404.eurprd02.prod.outlook.com (10.169.243.142) with > > Microsoft SMTP Server (version=TLS1_0, > > cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) > > id 15.1.609.9; Fri, 9 Sep 2016 15:48:04 +0000 > > > > From: Frederik Gladhorn > > To: > > Date: Fri, 9 Sep 2016 17:48:00 +0200 > > Cheers, From edward.welbourne at qt.io Mon Sep 12 14:07:31 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 12 Sep 2016 12:07:31 +0000 Subject: [Development] QtCon 2016 session notes: Qt for macOS In-Reply-To: References: Message-ID: Morten Sorvig > Session held friday september 2nd. Notes transformed into a Wiki page: https://wiki.qt.io/Qt_for_macOS_at_QtCon_2016 > We ran out of time and may have missed some topics and/or input - following up on > this email is possible. Additions to the wiki page might be another way to approach some types of follow-up. Eddy. From edward.welbourne at qt.io Mon Sep 12 16:08:16 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 12 Sep 2016 14:08:16 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> , Message-ID: For reference, I've turned Andrew's notes (see ur-ancestor post of this thread) into: https://wiki.qt.io/Qt_build_systems_at_QtCon_2016 Eddy. From frederik.gladhorn at qt.io Mon Sep 12 16:26:49 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Mon, 12 Sep 2016 16:26:49 +0200 Subject: [Development] Gerrit down In-Reply-To: <40950885.xNqieUmXmH@frederik-thinkcentre-m93p> References: <1827050.pGryCThjEX@frederik-thinkcentre-m93p> <40950885.xNqieUmXmH@frederik-thinkcentre-m93p> Message-ID: <2600700.SaNMxL9eXl@frederik-thinkcentre-m93p> On mandag 12. september 2016 14.03.36 CEST Frederik Gladhorn wrote: > Both gerrit and mailing lists should be running again. > > It seems like there was a problem with DNS on the machine that runs the mail > server and mailman. I don't know the exact details, but the machine has > been fixed and also the backups have been tuned, so mails and gerrit should > be rolling again. > There are still seven changes in a weird state, I'll clean these up now, but > I don't want to risk creating a bigger mess, so it'll take a bit of time to > fully understand which state they are in. Gerrit shows them in integrating > state and the CI thinks they're done. The offending changes have been "failed" now and should be ready to be restaged. Please let me know if you see anything still hanging for a day or longer. Cheers, Frederik > > Happy hacking! > Frederik > > On lørdag 10. september 2016 01.36.40 CEST Giuseppe D'Angelo wrote: > > Il 09/09/2016 17:48, Frederik Gladhorn ha scritto: > > > Since the problem is very likely something with the mail setup being > > > broken, we'll disable gerrit mails - so expect not to see any emails > > > from > > > gerrit until this is fixed. Occasional mail might still make it, we'll > > > try giving mails a short timeout before dropping them. > > > > By the way, this very mailing list seems to suffer from something, I've > > just received a bunch of messages sent today which were stuck somewhere, > > notice the gigantic gap in time: > > > > [snip] > > > > > Received: from mx.qt-project.org (mx.qt-project.org [193.209.87.4]) > > > > > > (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) > > > (No client certificate requested) > > > by mail.kdab.com (Postfix) with ESMTPS id 26B8B28070C > > > for ; Sat, 10 Sep 2016 00:18:07 +0200 (CEST) > > > > > > X-Original-To: development at qt-project.org > > > Delivered-To: development at qt-project.org > > > Received: by mx.qt-project.org (Postfix, from userid 1233) > > > > > > id 7A7A550264; Sat, 10 Sep 2016 00:18:24 +0200 (CEST) > > > > > > Received: from EUR01-VE1-obe.outbound.protection.outlook.com > > > > > > (mail-ve1eur01on0100.outbound.protection.outlook.com [104.47.1.100]) > > > by mx.qt-project.org (Postfix) with ESMTP id AA75D50262 > > > for ; Sat, 10 Sep 2016 00:18:23 +0200 > > > (CEST) > > > > > > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > > > > > > d=qtcompany.onmicrosoft.com; s=selector1-qt-io; > > > h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; > > > bh=mN6vAFQ72mV+/H1wStOxJTboKGXq95PRWd5/52UDCzA=; > > > b=SfGAI +ERzPwuKluQOanFfg8rqTcgBrRu5aFLxhRg9ThTegmFmjXLeSOYdQAuRzh02TWya > > > H4 > > > y8HMcYqKuS/9vjsW9vUA4UMJWC9fap2j6YJYFlvOiQWVst+ +hKk3GZSrnLXvbW7pJj60K8o > > > k+ > > > CYBQc+ptL2DwfF4N5NOYouWR+t8=> > > > > > > Authentication-Results: spf=none (sender IP is ) > > > > > > smtp.mailfrom=Frederik.Gladhorn at qt.io; > > > > > > Received: from frederik-thinkcentre-m93p.localnet (185.55.107.82) by > > > > > > AM5PR0201MB2404.eurprd02.prod.outlook.com (10.169.243.142) with > > > Microsoft SMTP Server (version=TLS1_0, > > > cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) > > > id 15.1.609.9; Fri, 9 Sep 2016 15:48:04 +0000 > > > > > > From: Frederik Gladhorn > > > To: > > > Date: Fri, 9 Sep 2016 17:48:00 +0200 > > > > Cheers, > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From stephen.kelly at ableton.com Mon Sep 12 17:12:09 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Mon, 12 Sep 2016 17:12:09 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> Message-ID: Hi Edward, You copied the line: (Stephen) "In reality, rewriting Qt's build system in CMake will actually be a PITA, and will require changes to CMake to make everything better" That was a stenography error. Can you remove it? Thanks, On 12/09/16 16:08, Edward Welbourne wrote: > For reference, I've turned Andrew's notes (see ur-ancestor post of this thread) into: > https://wiki.qt.io/Qt_build_systems_at_QtCon_2016 > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 From nospam at vuorela.dk Mon Sep 12 23:15:31 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Mon, 12 Sep 2016 21:15:31 +0000 (UTC) Subject: [Development] Qt 5.8 API review (vs 5.7.0) References: Message-ID: On 2016-09-09, Edward Welbourne wrote: > https://codereview.qt-project.org/170634 -- qtbase Added some comments. Though didn't detailed read all template magic. One enum have reordered some members. This is likely an issue. > https://codereview.qt-project.org/170635 -- qtdeclarative Kind of looks ok to me from a BC standpoint. > https://codereview.qt-project.org/170637 -- qtmultimedia OK. Single added enum and single added function. > https://codereview.qt-project.org/170638 -- qttools How much of this is actually changes in installed headers, and how much is just internal stuff ? > https://codereview.qt-project.org/170647 -- qtwebengine How much of this is external api, and how much is internal ? Comment on one set of the api provided. /Sune From newellm at blur.com Mon Sep 12 23:40:19 2016 From: newellm at blur.com (Matt Newell) Date: Mon, 12 Sep 2016 14:40:19 -0700 Subject: [Development] Proposal: JSON single value documents Message-ID: <15043335.9dMgDhLTUe@obsidian> I would like to propose an addition to the QtJson api to allow single value json documents (SVJ for brevity). There have been various discussions regarding whether or not a SVJ is a valid json document, with more recent rfc's saying yes. Here is one discussion which also has links to others: http://stackoverflow.com/questions/18419428/what-is-the-minimum-valid-json Regardless of whether a SJV is a valid document, the fact remains that to be fully interoperable with many other existing projects Qt should support them. My initial motivation is full support for the json/jsonb column type in Postgresql. My proposed change would add the following methods to QJsonDocument: bool isValue() const; QJsonValue value() const; void setValue(const QJsonValue &value); The only backwards compatibility issue that i can think of would be that fromVariant and fromJson will now return valid values documents. For that reason it may be needed to provide new fromVariant and fromJson overloads. I have figured out an elegant way to handle SVJ's without changing qt's binary format. Because the binary format in it's current form can only hold a top- level object or array, and because any old code will not be able to load a binary document containing a single value, a version bump is required. My idea is to have a SVJ stored as a single element json array containing the value, but have the version set to 2. This results in no actual changes to the binary format at all. Any non-SVJ document continues to use version 1 retaining full backwards compatibility for any document that was valid previously. Attached is a preliminary patch that compiles, passes the existing tests in tests/auto/corelib/json, and adds a few new tests to exercise the new functionality. If it's determined that this is a reasonable approach I will work on extending the tests and updating the documentation. Thanks, Matt Newell -------------- next part -------------- A non-text attachment was scrubbed... Name: json_svj.diff Type: text/x-patch Size: 11868 bytes Desc: not available URL: From thiago.macieira at intel.com Tue Sep 13 03:31:40 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 12 Sep 2016 18:31:40 -0700 Subject: [Development] Proposal: JSON single value documents In-Reply-To: <15043335.9dMgDhLTUe@obsidian> References: <15043335.9dMgDhLTUe@obsidian> Message-ID: <5995470.zFD2mElIGQ@tjmaciei-mobl1> On segunda-feira, 12 de setembro de 2016 14:40:19 PDT Matt Newell wrote: > My proposed change would add the following methods to QJsonDocument: > bool isValue() const; I'm not sure it. Arrays and objects are JSON values, so this function would return a constant true, for all values, except when isEmpty() is true. Maybe we want isValid() instead. These are ok: > QJsonValue value() const; > void setValue(const QJsonValue &value); That would also mean the object()/setObject() and array()/setArray() pairs become convenience functions around value().to{Array,Object}() and setValue() with type constraining. > The only backwards compatibility issue that i can think of would be that > fromVariant and fromJson will now return valid values documents. For that > reason it may be needed to provide new fromVariant and fromJson overloads. Indeed. > I have figured out an elegant way to handle SVJ's without changing qt's > binary format. Because the binary format in it's current form can only > hold a top- level object or array, and because any old code will not be > able to load a binary document containing a single value, a version bump is > required. My idea is to have a SVJ stored as a single element json array > containing the value, but have the version set to 2. This results in no > actual changes to the binary format at all. Any non-SVJ document continues > to use version 1 retaining full backwards compatibility for any document > that was valid previously. Lars to comment. > Attached is a preliminary patch that compiles, passes the existing tests in > tests/auto/corelib/json, and adds a few new tests to exercise the new > functionality. And way too big (> 10 lines), so no one interested in this feature should open your patch and read it: it could become a problem if someone were to later implement it. Instead, please upload it to Gerrit so we can get your patch with the Contribution Licence Agreement. > If it's determined that this is a reasonable approach I will work on > extending the tests and updating the documentation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jedrzej.nowacki at qt.io Tue Sep 13 08:25:10 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Tue, 13 Sep 2016 08:25:10 +0200 Subject: [Development] Module maintainers: action required (Coin slowly migrates from sync.profile to .gitmodules) In-Reply-To: <16176940.ZuU55maq73@42> References: <2756158.WOgs6TtE6b@42> <16176940.ZuU55maq73@42> Message-ID: <1812257.QvtQHO20lV@42> On fredag 19. august 2016 08.52.59 CEST Jędrzej Nowacki wrote: > On torsdag 18. august 2016 17.46.41 CEST Dominik Holland wrote: > > How are the dependencies managed for projects/modules which are not part > > of the qt5.git but are part of coin ? > > > > Dominik > > That is the reason of migrating "slowly". We need to define/find a product > repository for them. Such super repository would define testing platforms, > configurations and dependencies configurations. For experimental modules and > in general, playground I would propose to create "qt-labs" product. > Cheers, > Jędrek Hi, In addition to what I said before "product less" modules, which we should not have, by default will depend on all Qt5 modules, so we can test them anyway. Cheers, Jędrek From jedrzej.nowacki at qt.io Tue Sep 13 08:45:53 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Tue, 13 Sep 2016 08:45:53 +0200 Subject: [Development] [Qt-creator] [FYI] on gerrit change retargeting requests In-Reply-To: References: <20160831141255.GG2429@troll08> Message-ID: <1995849.MOA7rzCDns@42> On mandag 12. september 2016 14.39.57 CEST Orgad Shaneh wrote: > On Tue, Sep 6, 2016 at 12:56 PM, J-P Nurmi wrote: > > On 06 Sep 2016, at 11:46, Konstantin Tokarev wrote: > > > 06.09.2016, 12:44, "Oswald Buddenhagen" : > > >>> On Mon, Sep 05, 2016 at 09:17:59PM +0000, J-P Nurmi wrote: > > >>> On 05 Sep 2016, at 19:27, Marc Mutz wrote: > > >>> > It's not about restricting what a user can do. It's simply missing > > >>> > implementation, and I believe that if it were easy to implement, > > >>> > Ossi would have done it long ago instead of playing retarget-monkey > > >>> > for the rest of us :) > > >>> > > >>> Doing it through the web UI would be a nice bonus, but having access > > >>> to the same script that is already used by the admins would be good > > >>> enough for starters. > > >> > > >> yep - because i'm totally going to give everyone full write access to > > >> the database. ;) > > >> > > >> if you make a secure web frontend that authenticates against qt account > > >> and verifies change ownership using the gerrit ssh interface, i'm > > >> totally willing to deploy that. ;) > > > > > > Idea: IRC bot accepting retarget requests, with rate limit e.g. one > > > > request per minute. Bot runs on host with db access and can do only this > > one thing. > > > > Another idea: patch Gerrit to change the target branch (and create a new > > patchset version to reset scores) when pushing to a different branch. > > I have another suggestion, which should be quite easy to implement. > > Either extend the sanity bot, or create a new bot, which listens on > gerrit's event stream. > > If *the change's owner* (or an approver?) posts a comment reading "Please > retarget ", run your script on the server side. You need some > sanity test that ensures this branch exists etc... > > What do you say? > > - Orgad Actually that work is ongoing :-) I just need get a proper account in the right db. Cheers, Jędrek From b.terrier at gmail.com Tue Sep 13 12:42:15 2016 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Tue, 13 Sep 2016 12:42:15 +0200 Subject: [Development] QUuid documentation In-Reply-To: References: <1975369.J7for5LNFY@tjmaciei-mobl1> Message-ID: Le 10 sept. 2016 12:18 AM, "Edward Welbourne" a écrit : > > Benjamin Terrier: > >> However, my knowledge is that whatever the method one use to generate > >> your UUID, one can never guarantee its uniqueness. Meaning that the > >> Qt documentation is falsely guarantying unique UUID and therefore > >> should be changed. > >> > >> If anyone can confirm, I'll create a bug report. > > Thiago Macieira > > Right, it's not guaranteed. It's just that the chance of collision is > > virtually zero. > > ... and for sufficiently small values of "virtually zero", that's as > close a guarantee as you'll get to anything, because no matter how well > you think you can guarantee things, cosmic rays still sporadically flip > bits in your memory. > > I read a most illuminating paper a few years back that looked at the > reliability of tests of prime-ness for large numbers. There's a widely > used approach that's cheap and theoretically not guaranteed but easy to > apply to enough test-cases to reduce the likelihood of error to > ignorably low. This was compared to the best known "provably correct" > algorithm for determining primeness - which is significantly more > computationally expensive. Due to the (ridiculously rare) flipping of > bits by cosmic rays hitting the processor and memory, the latter was in > fact *less* reliable than the former, because the former ran faster so > incurred a smaller chance of errors due to stray rays. > > I don't think we should worry about documenting how not-quite-perfect > our guarantee of UID uniqueness is in a case where - realistically - > the difference from perfection is ignorable. > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development I agree with both of you. Still I'd like the documentation to be changed, mainly for 2 reasons. 1. For the sake of correctness. The sentence "the UUID will be of cryptographic quality, which will make the UUID unique" is false on a logical/mathematical/algorithmical point of view. And here the documentation is about what the code does, what the implemented algorithm provides, and it does not provide a 100% guaranteed unique UUID. Starting to justify that the UUID should be documented as guaranteed unique in this part of the documentation is out of scope because you make assumptions on where and how the code will be executed. It would be way better to tell that cryptographic quality UUID are as unique as any UUID can be and that in most use cases its uniqueness can be safely implied (because hardware is less reliable, etc.). 2. For the sake of educating people When reading "the UUID will be of cryptographic quality, which will make the UUID unique", people who do not have advance knowledge on UUID and such could come to think that there is a way to guarantee UUID uniqueness. And I'm pretty sure you could end up with quotes of Qt documentation to back up the claim that "UUID can be unique if the RNG is of cryptographic quality". BR, Benjamin From thiago.macieira at intel.com Tue Sep 13 20:25:00 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 13 Sep 2016 11:25:00 -0700 Subject: [Development] NSURLConnection backend in 5.6.2 Message-ID: <4361638.GZGoXNq634@tjmaciei-mobl1> The changelog contains this entry: - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has been removed, since SecureTransport is the default SSL backend on iOS and is enabled by default. This means that building with -no-openssl -no-securetransport will no longer provide SSL capabilities on iOS. WTH? Why are we removing options in a patch release? What happened? Is the backend so severely broken that it needed to be removed? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Tue Sep 13 20:33:20 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 13 Sep 2016 18:33:20 +0000 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: <4361638.GZGoXNq634@tjmaciei-mobl1> References: <4361638.GZGoXNq634@tjmaciei-mobl1> Message-ID: <9DAA4321-4C3F-4195-BCA9-BCA44D30C71F@qt.io> Because the APIs are deprecated by Apple so they would have had to be removed/changed soon anyways, especially when an alternative (which is the default now) is already available. Also it caused build failure on tvOS/watchOS. On Sep 13, 2016, at 11:25 AM, Thiago Macieira > wrote: The changelog contains this entry: - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has been removed, since SecureTransport is the default SSL backend on iOS and is enabled by default. This means that building with -no-openssl -no-securetransport will no longer provide SSL capabilities on iOS. WTH? Why are we removing options in a patch release? What happened? Is the backend so severely broken that it needed to be removed? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Tue Sep 13 20:40:29 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 13 Sep 2016 21:40:29 +0300 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: <9DAA4321-4C3F-4195-BCA9-BCA44D30C71F@qt.io> References: <4361638.GZGoXNq634@tjmaciei-mobl1> <9DAA4321-4C3F-4195-BCA9-BCA44D30C71F@qt.io> Message-ID: <1004011473792029@web1g.yandex.ru> 13.09.2016, 21:33, "Jake Petroules" : >  Because the APIs are deprecated by Apple so they would have had to be removed/changed soon anyways, especially when an alternative (which is the default now) is already available. AFAIK they cannot remove API from released SDK, and users may choose to use it even if it's not latest and greatest anymore. > Also it caused build failure on tvOS/watchOS. > >>  On Sep 13, 2016, at 11:25 AM, Thiago Macieira wrote: >> >>  The changelog contains this entry: >> >>  - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has >>    been removed, since SecureTransport is the default SSL backend on iOS >>    and is enabled by default. This means that building with -no-openssl >>    -no-securetransport will no longer provide SSL capabilities on iOS. >> >>  WTH? Why are we removing options in a patch release? What happened? >> >>  Is the backend so severely broken that it needed to be removed? >>  -- >>  Thiago Macieira - thiago.macieira (AT) intel.com >>   Software Architect - Intel Open Source Technology Center >> >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > >  -- >  Jake Petroules - jake.petroules at qt.io >  Consulting Services Engineer - The Qt Company >  Qbs build tool evangelist - qbs.io >  , > >  _______________________________________________ >  Development mailing list >  Development at qt-project.org >  http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From Jake.Petroules at qt.io Tue Sep 13 20:41:50 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 13 Sep 2016 18:41:50 +0000 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: <1004011473792029@web1g.yandex.ru> References: <4361638.GZGoXNq634@tjmaciei-mobl1> <9DAA4321-4C3F-4195-BCA9-BCA44D30C71F@qt.io> <1004011473792029@web1g.yandex.ru> Message-ID: On Sep 13, 2016, at 11:40 AM, Konstantin Tokarev > wrote: 13.09.2016, 21:33, "Jake Petroules" >: Because the APIs are deprecated by Apple so they would have had to be removed/changed soon anyways, especially when an alternative (which is the default now) is already available. AFAIK they cannot remove API from released SDK, and users may choose to use it even if it's not latest and greatest anymore. They can and have before. Anyways, it doesn't matter. The code was unused, untested, and was in the way of other things, so its removal is inconsequential. Also it caused build failure on tvOS/watchOS. On Sep 13, 2016, at 11:25 AM, Thiago Macieira > wrote: The changelog contains this entry: - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has been removed, since SecureTransport is the default SSL backend on iOS and is enabled by default. This means that building with -no-openssl -no-securetransport will no longer provide SSL capabilities on iOS. WTH? Why are we removing options in a patch release? What happened? Is the backend so severely broken that it needed to be removed? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io , _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Kandeler at qt.io Tue Sep 13 21:10:10 2016 From: Christian.Kandeler at qt.io (Christian Kandeler) Date: Tue, 13 Sep 2016 19:10:10 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> , Message-ID: [Sorry about the formatting, using outlook] Stephen Kelly wrote: > Here's the CMake version: [ ... ] > execute_process( > COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list > ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5 > OUTPUT_VARIABLE fileList > ) How do you know where the input file is located? > However, it is cheating in the same way that the QBS version from > Christian is cheating - it assumes '--list' exists: Yes, I was assuming a cooperating tool. > Christian, can you create a version which does not require --list? There are two possibilities: a) The inner workings of the tool are known and "simple enough". That's the case in Bo's example, so there we could just open the input file and derive the output artifacts from the number we find there. b) Otherwise, our outputArtifacts script has to run the tool in "real mode" (using the "--generate" option). The actual command would be a no-op then. This is icky, both conceptually and for practical reasons, because commands of non-competing rules are run in parallel, whereas the outputArtifacts scripts are not. I think so far we only use this approach for the infamous qdoc tool. Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Sep 13 21:32:35 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 13 Sep 2016 12:32:35 -0700 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: References: <4361638.GZGoXNq634@tjmaciei-mobl1> <1004011473792029@web1g.yandex.ru> Message-ID: <2858899.frQFlEcn0S@tjmaciei-mobl1> On terça-feira, 13 de setembro de 2016 18:41:50 PDT Jake Petroules wrote: > They can and have before. Anyways, it doesn't matter. The code was unused, > untested, and was in the way of other things, so its removal is > inconsequential. > > Also it caused build failure on tvOS/watchOS. Are we sure none of our users depended on it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Tue Sep 13 21:39:41 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 13 Sep 2016 19:39:41 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> Message-ID: On Sep 13, 2016, at 12:10 PM, Christian Kandeler > wrote: [Sorry about the formatting, using outlook] Stephen Kelly wrote: > Here's the CMake version: [ ... ] > execute_process( > COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list > ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5 > OUTPUT_VARIABLE fileList > ) How do you know where the input file is located? > However, it is cheating in the same way that the QBS version from > Christian is cheating - it assumes '--list' exists: Yes, I was assuming a cooperating tool. > Christian, can you create a version which does not require --list? There are two possibilities: a) The inner workings of the tool are known and "simple enough". That's the case in Bo's example, so there we could just open the input file and derive the output artifacts from the number we find there. b) Otherwise, our outputArtifacts script has to run the tool in "real mode" (using the "--generate" option). The actual command would be a no-op then. This is icky, both conceptually and for practical reasons, because commands of non-competing rules are run in parallel, whereas the outputArtifacts scripts are not. I think so far we only use this approach for the infamous qdoc tool. And asset catalogs, XIBs/NIBs/storyboards, Java sources, and TypeScript sources. Christian _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Tue Sep 13 21:44:35 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 13 Sep 2016 19:44:35 +0000 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: <2858899.frQFlEcn0S@tjmaciei-mobl1> References: <4361638.GZGoXNq634@tjmaciei-mobl1> <1004011473792029@web1g.yandex.ru> <2858899.frQFlEcn0S@tjmaciei-mobl1> Message-ID: <5B44DFA8-4241-4E82-8B68-1397957F887A@qt.io> On Sep 13, 2016, at 12:32 PM, Thiago Macieira > wrote: On terça-feira, 13 de setembro de 2016 18:41:50 PDT Jake Petroules wrote: They can and have before. Anyways, it doesn't matter. The code was unused, untested, and was in the way of other things, so its removal is inconsequential. Also it caused build failure on tvOS/watchOS. Are we sure none of our users depended on it? I'd be blown away if they did and I can't see how there would be a dependency. Also using deprecated APIs is a bad idea for app store compliance. I believe there have been rejections for that in the past. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Tue Sep 13 21:51:28 2016 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 13 Sep 2016 21:51:28 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> Message-ID: Christian Kandeler wrote: > [Sorry about the formatting, using outlook] > > Stephen Kelly wrote: >> Here's the CMake version: > > [ ... ] > >> execute_process( >> COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list >> ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5 >> OUTPUT_VARIABLE fileList >> ) > > How do you know where the input file is located? There is no input file. There is only an input number. The task is from Bo, who gave it as a simplified example. >> However, it is cheating in the same way that the QBS version from >> Christian is cheating - it assumes '--list' exists: > > Yes, I was assuming a cooperating tool. In his real-world example, Bo said that there was a tool which generated output files, but the output files are not a-priori known: https://www.mail-archive.com/development at qt-project.org/msg25970.html Of course, if you have a 'cooperating tool' you can do anything with CMake too. My understanding is that because Qbs has a dynamic build graph, it can do things that CMake can't do. I'm looking for a good example of that so that I can understand. It is the gap that Qbs is to fill. Jake mentioned examples to show the difference between the Rolls-Royce Trent 900 jet engine that is Qbs, and the wet firecrackers that are CMake and qmake. I thought this would be a good one, but it turns out that in this case, Qbs and CMake have the same requirement of the tool. >> Christian, can you create a version which does not require --list? > > There are two possibilities: > a) The inner workings of the tool are known and "simple enough". That's > the case in Bo's example, so there we could just open the input file and > derive the output artifacts from the number we find there. Yes, if we can find out "now" what the tool will generate "later", then everything is easy. If we require that of the tool, then we can have a static build graph, so I don't see how the dynamic build graph is an advantage in that case. In the case Bo mentioned, he built the tool, so he can ensure it is cooperative. It seems his mistake and the source of his problem was to use qmake for the job instead of CMake or Qbs :). > b) Otherwise, > our outputArtifacts script has to run the tool in "real mode" (using the > "--generate" option). And how do you know what the outputArtifacts are? Do you require the tool to tell you what files it generated during this step? (ie, again be cooperative) > The actual command would be a no-op then. This is > icky, both conceptually and for practical reasons, because commands of > non-competing rules are run in parallel, whereas the outputArtifacts > scripts are not. Right, assuming the tool is still 'cooperative' and tells you what files it generated, you would end up with the same thing with a CMake build - you would generate the files at CMake time, and then ninja would build them in parallel. Again, that's no conceptual advantage of the dynamic build graph over the static one in the case of a somewhat cooperative tool. That's probably why Milian never saw a need for such a thing :). So, I'm still trying to find out when the dynamic build graph is actually an advantage. I have an idea in mind, but it gets quite niche and still has some assumptions. Maybe you can tell me if I am right: 1) You have an 'uncooperative' tool which can not tell you what it will generate, and which does not output a list of what it generated. However, it accepts a command line argument specifying where it should generate its files. 2) So, you set it up to generate the files in some directory. You assume that the directory is empty before the tool is run, and you use the equivalent of running the 'ls' command to determine what the files are. Rules to run moc and to run the compiler are then added to your dynamic build graph, which then proceeds and eventually gets around to executing those rules. If that is something Qbs is designed to do, then can you post a Qbs file which does it? You can use the generator.py I posted before. The script already accepts a directory to generate the files into - just pretend --list doesn't exist. Thanks, Steve. From thiago.macieira at intel.com Tue Sep 13 21:55:37 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 13 Sep 2016 12:55:37 -0700 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: <5B44DFA8-4241-4E82-8B68-1397957F887A@qt.io> References: <4361638.GZGoXNq634@tjmaciei-mobl1> <2858899.frQFlEcn0S@tjmaciei-mobl1> <5B44DFA8-4241-4E82-8B68-1397957F887A@qt.io> Message-ID: <5426827.HsXNLkgysD@tjmaciei-mobl1> On terça-feira, 13 de setembro de 2016 19:44:35 PDT Jake Petroules wrote: > I'd be blown away if they did and I can't see how there would be a > dependency. Also using deprecated APIs is a bad idea for app store > compliance. I believe there have been rejections for that in the past. But did it work on macOS too? Or was it exclusively for the Apple embedded platforms? PS: can you configure your mail client to quote text properly in the plain-text format? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From steveire at gmail.com Tue Sep 13 21:59:58 2016 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 13 Sep 2016 21:59:58 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <2696303.4YcVdbDnqi@debian> <311981473247653@web29g.yandex.ru> Message-ID: Konstantin Tokarev wrote: >> -Qbs has great features that you can't find in other build systems (e.g. >> it can build multiple ABIs/platforms at once). > > For the record, premake can do it as well. Can you show me the syntax for this with premake (and with Qbs)? I assume you're talking about building a tool on the host, then using it to generate sources, then cross compiling those sources, and having all of that in one build. My internet searches do not reveal anything about premakes ability here. Thanks, Steve. From Jake.Petroules at qt.io Tue Sep 13 22:01:10 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 13 Sep 2016 20:01:10 +0000 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: <5426827.HsXNLkgysD@tjmaciei-mobl1> References: <4361638.GZGoXNq634@tjmaciei-mobl1> <2858899.frQFlEcn0S@tjmaciei-mobl1> <5B44DFA8-4241-4E82-8B68-1397957F887A@qt.io> <5426827.HsXNLkgysD@tjmaciei-mobl1> Message-ID: On Sep 13, 2016, at 12:55 PM, Thiago Macieira > wrote: On terça-feira, 13 de setembro de 2016 19:44:35 PDT Jake Petroules wrote: I'd be blown away if they did and I can't see how there would be a dependency. Also using deprecated APIs is a bad idea for app store compliance. I believe there have been rejections for that in the past. But did it work on macOS too? Or was it exclusively for the Apple embedded platforms? NSURLConnection was only ever used on iOS, not any of the other platforms. PS: can you configure your mail client to quote text properly in the plain-text format? Tell me how to do that in Apple Mail and I'm happy to. I think I heard a couple complaints after upgrading to Apple Mail 10 (Sierra). There's a checkbox under responding, "Use the same message format as the original message", maybe that will help. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Tue Sep 13 22:01:21 2016 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 13 Sep 2016 22:01:21 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> Message-ID: Stephen Kelly wrote: > Christian Kandeler wrote: > >> [Sorry about the formatting, using outlook] >> >> Stephen Kelly wrote: >>> Here's the CMake version: >> >> [ ... ] >> >>> execute_process( >>> COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list >>> ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5 >>> OUTPUT_VARIABLE fileList >>> ) >> >> How do you know where the input file is located? > > There is no input file. There is only an input number. The task is from > Bo, who gave it as a simplified example. Oops, I'm wrong here. Bo said to read the number from a file. I don't think that changes anything though regarding dynamic build graph being an advantage. Thanks, Steve. From thiago.macieira at intel.com Tue Sep 13 22:15:58 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 13 Sep 2016 13:15:58 -0700 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: References: <4361638.GZGoXNq634@tjmaciei-mobl1> <5426827.HsXNLkgysD@tjmaciei-mobl1> Message-ID: <1554958.c1PdTgAlyg@tjmaciei-mobl1> On terça-feira, 13 de setembro de 2016 20:01:10 PDT Jake Petroules wrote: > On Sep 13, 2016, at 12:55 PM, Thiago Macieira > > wrote: > On terça-feira, 13 de setembro de 2016 19:44:35 PDT Jake Petroules wrote: > I'd be blown away if they did and I can't see how there would be a > dependency. Also using deprecated APIs is a bad idea for app store > compliance. I believe there have been rejections for that in the past. > > But did it work on macOS too? Or was it exclusively for the Apple embedded > platforms? > > NSURLConnection was only ever used on iOS, not any of the other platforms. Ok, then that's less of a problem. If it could only be used on a platform where no one will ever want to use it again, we can reasonably conclude no one will be using it. > PS: can you configure your mail client to quote text properly in the > plain-text format? > > Tell me how to do that in Apple Mail and I'm happy to. I think I heard a > couple complaints after upgrading to Apple Mail 10 (Sierra). There's a > checkbox under responding, "Use the same message format as the original > message", maybe that will help. I don't know how. Check with other Mac users. This is not a new thing, you've been doing it for months or more. If you can't configure your MUA to quote properly for a mailing list, don't use it for mailing lists. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Christian.Kandeler at qt.io Tue Sep 13 22:29:54 2016 From: Christian.Kandeler at qt.io (Christian Kandeler) Date: Tue, 13 Sep 2016 20:29:54 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> , Message-ID: Stephen Kelly wrote: >> There is no input file. There is only an input number. The task is from >> Bo, who gave it as a simplified example. > Oops, I'm wrong here. Bo said to read the number from a file. > I don't think that changes anything though regarding dynamic build graph > being an advantage. Sure? What about the (lack of) need for two rules to agree in advance about the location of a generated file? Also, there could be several layers of indirection, with the second set of generated files also containing meta data etc. Christian From Jake.Petroules at qt.io Tue Sep 13 22:58:35 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 13 Sep 2016 20:58:35 +0000 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: <1554958.c1PdTgAlyg@tjmaciei-mobl1> References: <4361638.GZGoXNq634@tjmaciei-mobl1> <5426827.HsXNLkgysD@tjmaciei-mobl1> <1554958.c1PdTgAlyg@tjmaciei-mobl1> Message-ID: On Sep 13, 2016, at 1:15 PM, Thiago Macieira > wrote: On terça-feira, 13 de setembro de 2016 20:01:10 PDT Jake Petroules wrote: On Sep 13, 2016, at 12:55 PM, Thiago Macieira > wrote: On terça-feira, 13 de setembro de 2016 19:44:35 PDT Jake Petroules wrote: I'd be blown away if they did and I can't see how there would be a dependency. Also using deprecated APIs is a bad idea for app store compliance. I believe there have been rejections for that in the past. But did it work on macOS too? Or was it exclusively for the Apple embedded platforms? NSURLConnection was only ever used on iOS, not any of the other platforms. Ok, then that's less of a problem. If it could only be used on a platform where no one will ever want to use it again, we can reasonably conclude no one will be using it. PS: can you configure your mail client to quote text properly in the plain-text format? Tell me how to do that in Apple Mail and I'm happy to. I think I heard a couple complaints after upgrading to Apple Mail 10 (Sierra). There's a checkbox under responding, "Use the same message format as the original message", maybe that will help. I don't know how. Check with other Mac users. This is not a new thing, you've been doing it for months or more. Testing that quoting hopefully works properly. If you can't configure your MUA to quote properly for a mailing list, don't use it for mailing lists. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Tue Sep 13 23:06:37 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 13 Sep 2016 21:06:37 +0000 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: <1554958.c1PdTgAlyg@tjmaciei-mobl1> References: <4361638.GZGoXNq634@tjmaciei-mobl1> <5426827.HsXNLkgysD@tjmaciei-mobl1> <1554958.c1PdTgAlyg@tjmaciei-mobl1> Message-ID: <8722EA09-167D-457C-B1EB-BDF8A4CFC2EA@qt.io> > On Sep 13, 2016, at 1:15 PM, Thiago Macieira wrote: > > On terça-feira, 13 de setembro de 2016 20:01:10 PDT Jake Petroules wrote: >> On Sep 13, 2016, at 12:55 PM, Thiago Macieira >> > wrote: > >> On terça-feira, 13 de setembro de 2016 19:44:35 PDT Jake Petroules wrote: >> I'd be blown away if they did and I can't see how there would be a >> dependency. Also using deprecated APIs is a bad idea for app store >> compliance. I believe there have been rejections for that in the past. >> >> But did it work on macOS too? Or was it exclusively for the Apple embedded >> platforms? >> >> NSURLConnection was only ever used on iOS, not any of the other platforms. > > Ok, then that's less of a problem. If it could only be used on a platform > where no one will ever want to use it again, we can reasonably conclude no one > will be using it. Testing again that quoting is fixed? > >> PS: can you configure your mail client to quote text properly in the >> plain-text format? >> >> Tell me how to do that in Apple Mail and I'm happy to. I think I heard a >> couple complaints after upgrading to Apple Mail 10 (Sierra). There's a >> checkbox under responding, "Use the same message format as the original >> message", maybe that will help. > > I don't know how. Check with other Mac users. This is not a new thing, you've > been doing it for months or more. > > If you can't configure your MUA to quote properly for a mailing list, don't use > it for mailing lists. > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From Morten.Sorvig at qt.io Wed Sep 14 09:36:03 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Wed, 14 Sep 2016 07:36:03 +0000 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: <9DAA4321-4C3F-4195-BCA9-BCA44D30C71F@qt.io> References: <4361638.GZGoXNq634@tjmaciei-mobl1> <9DAA4321-4C3F-4195-BCA9-BCA44D30C71F@qt.io> Message-ID: <231CDAA2-1E20-43CE-9EFB-7E436AE71B54@qt.io> Should we have a “no feature removal for cleanup reasons in patch releases” policy? That’s easy to understand for everyone and we don’t have to make the "is it obscure enough” judgement. (The build failure could have been easily fixed so I don’t see it as a relevant reason.) Morten > On 13 Sep 2016, at 20:33, Jake Petroules wrote: > > Because the APIs are deprecated by Apple so they would have had to be removed/changed soon anyways, especially when an alternative (which is the default now) is already available. Also it caused build failure on tvOS/watchOS. > >> On Sep 13, 2016, at 11:25 AM, Thiago Macieira wrote: >> >> The changelog contains this entry: >> >> - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has >> been removed, since SecureTransport is the default SSL backend on iOS >> and is enabled by default. This means that building with -no-openssl >> -no-securetransport will no longer provide SSL capabilities on iOS. >> >> WTH? Why are we removing options in a patch release? What happened? >> >> Is the backend so severely broken that it needed to be removed? >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Jake Petroules - jake.petroules at qt.io > Consulting Services Engineer - The Qt Company > Qbs build tool evangelist - qbs.io > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Wed Sep 14 09:46:03 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 14 Sep 2016 07:46:03 +0000 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: <231CDAA2-1E20-43CE-9EFB-7E436AE71B54@qt.io> References: <4361638.GZGoXNq634@tjmaciei-mobl1> <9DAA4321-4C3F-4195-BCA9-BCA44D30C71F@qt.io> <231CDAA2-1E20-43CE-9EFB-7E436AE71B54@qt.io> Message-ID: That’s the policy we have had all the time. No feature removal or additions, no API changes in patch level releases. If a feature is really unused, or causes larger issues one can of course discuss exceptions, but it should be a conscious decision involving the relevant maintainers. Cheers, Lars On 14/09/16 09:36, "Development on behalf of Morten Sorvig" wrote: >Should we have a “no feature removal for cleanup reasons in patch >releases” policy? That’s easy to understand for everyone and we >don’t have to make the "is it obscure enough” judgement. > >(The build failure could have been easily fixed so I don’t see >it as a relevant reason.) > >Morten > > > >> On 13 Sep 2016, at 20:33, Jake Petroules wrote: >> >> Because the APIs are deprecated by Apple so they would have had to be removed/changed soon anyways, especially when an alternative (which is the default now) is already available. Also it caused build failure on tvOS/watchOS. >> >>> On Sep 13, 2016, at 11:25 AM, Thiago Macieira wrote: >>> >>> The changelog contains this entry: >>> >>> - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has >>> been removed, since SecureTransport is the default SSL backend on iOS >>> and is enabled by default. This means that building with -no-openssl >>> -no-securetransport will no longer provide SSL capabilities on iOS. >>> >>> WTH? Why are we removing options in a patch release? What happened? >>> >>> Is the backend so severely broken that it needed to be removed? >>> -- >>> Thiago Macieira - thiago.macieira (AT) intel.com >>> Software Architect - Intel Open Source Technology Center >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> -- >> Jake Petroules - jake.petroules at qt.io >> Consulting Services Engineer - The Qt Company >> Qbs build tool evangelist - qbs.io >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From Morten.Sorvig at qt.io Wed Sep 14 10:02:16 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Wed, 14 Sep 2016 08:02:16 +0000 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: References: <4361638.GZGoXNq634@tjmaciei-mobl1> <9DAA4321-4C3F-4195-BCA9-BCA44D30C71F@qt.io> <1004011473792029@web1g.yandex.ru> Message-ID: <3A67A8C5-3E62-40BB-874C-3B74B5A95978@qt.io> > On 13 Sep 2016, at 20:41, Jake Petroules wrote: > > >> On Sep 13, 2016, at 11:40 AM, Konstantin Tokarev wrote: >> >> >> >> 13.09.2016, 21:33, "Jake Petroules" : >>> Because the APIs are deprecated by Apple so they would have had to be removed/changed soon anyways, especially when an alternative (which is the default now) is already available. >> >> AFAIK they cannot remove API from released SDK, and users may choose to use it even if it's not latest and greatest anymore. > > They can and have before. I don’t think I’ve seen this happen, unless you were referring to the 32->64bit transition. If you grep for NS_DEPRECATED in the headers there are plenty of references to API that has been deprecated for a long time. What are the counter-examples? Morten From stephen.kelly at ableton.com Wed Sep 14 12:05:15 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Wed, 14 Sep 2016 12:05:15 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> Message-ID: On 13/09/16 22:29, Christian Kandeler wrote: > Stephen Kelly wrote: > >>> There is no input file. There is only an input number. The task is from >>> Bo, who gave it as a simplified example. >> Oops, I'm wrong here. Bo said to read the number from a file. >> I don't think that changes anything though regarding dynamic build graph >> being an advantage. > Sure? It is trivial: https://github.com/ske-ableton/generated-build-inputs/commit/d4ef3c48 Clearly there is some kind of misunderstanding happening here. In particular, when I said 'advantage' above, it means 'Qbs can do this thing, but CMake can not'. > What about the (lack of) need for two rules to agree in advance about the location of a generated file? I don't know what you are talking about. I don't know what rules have to 'agree'. > Also, there could be several layers of indirection, with the second set of generated files also containing meta data etc. Please post example code for that. Feel free to start by forking my repo. You quoted and challenged just one small part of my email. Can you answer the rest of it? I want to understand Qbs and what it can do with a dynamic build graph which CMake can't do. I made a guess in my email in the hope that you would confirm that my assumption is correct, or would correct my assumption to fill my understanding. Thanks, -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 From annulen at yandex.ru Wed Sep 14 12:09:18 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 14 Sep 2016 13:09:18 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <2696303.4YcVdbDnqi@debian> <311981473247653@web29g.yandex.ru> Message-ID: <1246371473847758@web28h.yandex.ru> 13.09.2016, 23:00, "Stephen Kelly" : > Konstantin Tokarev wrote: > >>>  -Qbs has great features that you can't find in other build systems (e.g. >>>  it can build multiple ABIs/platforms at once). >> >>  For the record, premake can do it as well. > > Can you show me the syntax for this with premake (and with Qbs)? I assume > you're talking about building a tool on the host, then using it to generate > sources, then cross compiling those sources, and having all of that in one > build. No, I meant building different subprojects for different platforms. As premake generates makefile (or project files) for all configurations at once you can run them sequentially, but there was no direct support for described use case when I looked into it last time > My internet searches do not reveal anything about premakes ability > here. > > Thanks, > > Steve. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From frederik.gladhorn at qt.io Wed Sep 14 15:45:33 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 14 Sep 2016 15:45:33 +0200 Subject: [Development] Boot2Qt Device Utilities module repo In-Reply-To: References: Message-ID: <6798099.rJcdhlQ7CE@frederik-thinkcentre-m93p> On fredag 9. september 2016 12.04.57 CEST Kimmo Ollila wrote: > Hi All, > > We are planning to open new Boot2Qt Device Utilities module repository. > Qt Device Utilities module allows user manipulate easily various embedded > device settings via simple QML APIs. > > More information can be found at the end of the blog post below: > https://blog.qt.io/blog/2016/06/16/qt-5-7-for-device-creation/ > > I also want to propose Teemu Holappa to be the maintainer of Boot2Qt Device > Utilities since he is the one who implemented the module. There was no opposition to this mail, so I'll create qt/qtdeviceutilities in gerrit. Cheers, Frederik > > Br, > Kimmo Ollila > > The Qt Company > Email: Kimmo.Ollila at qt.io > Mobile: + 358 50 590 9774 > http://qt.io > ------------------------------------------------------------------ > PRIVACY AND CONFIDENTIALITY NOTICE > This message and any attachments are intended only for use by the named > addressee and may contain privileged and/or confidential information. If > you are not the named addressee you should not disseminate, copy or take > any action in reliance on it. If you have received this message in error, > please contact the sender immediately and delete the message and any > attachments accompanying it. Digia Plc does not accept liability for any > corruption, interception, amendment, tampering or viruses occurring to this > message. ----------------------------------------------------------------- From Shawn.Rutledge at qt.io Wed Sep 14 16:01:23 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Wed, 14 Sep 2016 14:01:23 +0000 Subject: [Development] Boot2Qt Device Utilities module repo In-Reply-To: <6798099.rJcdhlQ7CE@frederik-thinkcentre-m93p> References: <6798099.rJcdhlQ7CE@frederik-thinkcentre-m93p> Message-ID: <4E7AECD2-3E78-4F88-8958-769BB9F270D0@qt.io> > On 14 Sep 2016, at 15:45, Frederik Gladhorn wrote: > > On fredag 9. september 2016 12.04.57 CEST Kimmo Ollila wrote: >> Hi All, >> >> We are planning to open new Boot2Qt Device Utilities module repository. >> Qt Device Utilities module allows user manipulate easily various embedded >> device settings via simple QML APIs. >> >> More information can be found at the end of the blog post below: >> https://blog.qt.io/blog/2016/06/16/qt-5-7-for-device-creation/ >> >> I also want to propose Teemu Holappa to be the maintainer of Boot2Qt Device >> Utilities since he is the one who implemented the module. > > There was no opposition to this mail, so I'll create qt/qtdeviceutilities in > gerrit. Sorry I didn’t notice your post the first time, and also hadn’t gotten around to reading the blog post until now. But it looks like there is some overlap with the qtsystems module. Maybe it would be a good time to combine efforts and try to get that module up to snuff instead of starting over? It’s not the first connman Qt binding either, although that’s not in qtsystems so far. I’ve been using this https://git.merproject.org/mer-core/libconnman-qt on one personal project. From Jake.Petroules at qt.io Wed Sep 14 16:10:40 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 14 Sep 2016 14:10:40 +0000 Subject: [Development] NSURLConnection backend in 5.6.2 In-Reply-To: References: <4361638.GZGoXNq634@tjmaciei-mobl1> <9DAA4321-4C3F-4195-BCA9-BCA44D30C71F@qt.io> <231CDAA2-1E20-43CE-9EFB-7E436AE71B54@qt.io> Message-ID: > On Sep 14, 2016, at 12:46 AM, Lars Knoll wrote: > > That’s the policy we have had all the time. No feature removal or additions, no API changes in patch level releases. > > If a feature is really unused, or causes larger issues one can of course discuss exceptions, but it should be a conscious decision involving the relevant maintainers. But we didn't remove a "feature", only a particular implementation detail of an existing feature, which should have no practical effect. I don't think that a rare combination of configure options now resulting in different behavior should really count as a feature change. The feature itself is "SSL support", which is unchanged. Otherwise, any change to implementation details to fix bugs could theoretically be considered a feature removal or addition... > > Cheers, > Lars > > > > > On 14/09/16 09:36, "Development on behalf of Morten Sorvig" wrote: > >> Should we have a “no feature removal for cleanup reasons in patch >> releases” policy? That’s easy to understand for everyone and we >> don’t have to make the "is it obscure enough” judgement. >> >> (The build failure could have been easily fixed so I don’t see >> it as a relevant reason.) >> >> Morten >> >> >> >>> On 13 Sep 2016, at 20:33, Jake Petroules wrote: >>> >>> Because the APIs are deprecated by Apple so they would have had to be removed/changed soon anyways, especially when an alternative (which is the default now) is already available. Also it caused build failure on tvOS/watchOS. >>> >>>> On Sep 13, 2016, at 11:25 AM, Thiago Macieira wrote: >>>> >>>> The changelog contains this entry: >>>> >>>> - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has >>>> been removed, since SecureTransport is the default SSL backend on iOS >>>> and is enabled by default. This means that building with -no-openssl >>>> -no-securetransport will no longer provide SSL capabilities on iOS. >>>> >>>> WTH? Why are we removing options in a patch release? What happened? >>>> >>>> Is the backend so severely broken that it needed to be removed? >>>> -- >>>> Thiago Macieira - thiago.macieira (AT) intel.com >>>> Software Architect - Intel Open Source Technology Center >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> -- >>> Jake Petroules - jake.petroules at qt.io >>> Consulting Services Engineer - The Qt Company >>> Qbs build tool evangelist - qbs.io >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From oswald.buddenhagen at qt.io Thu Sep 15 08:57:14 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 15 Sep 2016 08:57:14 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> Message-ID: <20160915065714.GA17144@nubble> On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development wrote: > I want to understand Qbs and what it can do with a dynamic build graph > which CMake can't do. > there is no such thing, as after full expansion the graph has to be static by definition (the output artifacts are expected to be deterministic, after all). the difference is in when you determine the final graph. as cmake is a meta build tool, it artificially creates two phases. as it creates inputs for static build tools, it has to execute all the dynamic parts itself, which makes the "preparation" phase actually a partial "execution" phase, and thus slower than it is supposed to be. having said that, qbs also has a "meta" mode, to make ide project generation possible. also, as shown in the bootstrapping discussion, we'll probably need a simple makefile generator as well. and as christian already pointed out, in qbs there is also the fundamental split between preparation and execution phases, only that they could be scheduled much better for individual artifacts (but as also pointed out, this isn't taken advantage of yet). so what it all comes down to is that qbs is, as in pretty much every other regard, simply more elegant than cmake, not a magic solution for problems yet to be found. From stephen.kelly at ableton.com Thu Sep 15 14:39:54 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Thu, 15 Sep 2016 14:39:54 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <20160915065714.GA17144@nubble> References: <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> <20160915065714.GA17144@nubble> Message-ID: On 15/09/16 08:57, Oswald Buddenhagen wrote: > On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development wrote: >> I want to understand Qbs and what it can do with a dynamic build graph >> which CMake can't do. >> > there is no such thing Oh, I'm very surprised by that. That also means I don't understand the great advantage of Qbs, just when I thought I was starting to understand it. My previous guess about Qbs being able to generate unknown files in a particular location and then determine them by an 'ls' equivalent, moc them and compile everything is not something Qbs would be able to do. > so what it all comes down to is that qbs is, as in pretty much every > other regard, simply more elegant than cmake Ok, thanks for clarifying! I'm still interested in a Qbs solution to the code/repo I posted before. A full and preferably working Qbs solution, instead of a snippet, would be good for comparison. Thanks, -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 From giuseppe.dangelo at kdab.com Thu Sep 15 14:51:26 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 15 Sep 2016 14:51:26 +0200 Subject: [Development] Missing Qt modules from Coverity Scan Message-ID: Howdy, while playing around with Coverity Scan with a few colleagues of mine we noticed that only qtbase is getting uploaded and therefore checked (instead of the complete qt5.git). I'm fairly sure that this has changed recently, as there are bugs in there against other modules which were automatically marked as "fixed" by Coverity (because the corresponding code is now gone). May I ask the Good Samaritan who is regularly uploading builds of Qt to Coverity to double check the configuration? Thanks, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From frank.meerkoetter at basyskom.com Thu Sep 15 21:02:40 2016 From: frank.meerkoetter at basyskom.com (Frank =?ISO-8859-1?Q?Meerk=F6tter?=) Date: Thu, 15 Sep 2016 21:02:40 +0200 Subject: [Development] Missing Qt modules from Coverity Scan In-Reply-To: References: Message-ID: <4232719.pAbfbWQiz3@naos> On Thursday 15 September 2016 14:51:26 Giuseppe D'Angelo wrote: [...] > while playing around with Coverity Scan with a few colleagues of mine we > noticed that only qtbase is getting uploaded and therefore checked > (instead of the complete qt5.git). > > I'm fairly sure that this has changed recently, as there are bugs in > there against other modules which were automatically marked as "fixed" > by Coverity (because the corresponding code is now gone). I played with the coverity scans end of 2015 or so. It was definitively not only qtbase. Still I had the impression that certain modules were missing (either that or they are free from errors/warnings). > May I ask the Good Samaritan who is regularly uploading builds of Qt to > Coverity to double check the configuration? That would be cool. How does the upload work? qt5.git + sub modules? Hand picked list? Regards, Frank -- Frank Meerkötter Development Lead basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel : +49 6151 870 589 161 | Fax: +49 6151 - 870 589 162 frank.meerkoetter at basyskom.com | www.basyskom.com Handelsregister: Darmstadt HRB 9352 Geschäftsführung: Eva Brucherseifer, Heike Ziegler From Christian.Kandeler at qt.io Fri Sep 16 03:07:56 2016 From: Christian.Kandeler at qt.io (Christian Kandeler) Date: Fri, 16 Sep 2016 01:07:56 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> <20160915065714.GA17144@nubble>, Message-ID: Stephen Kelly wrote: > My previous guess about Qbs being able to generate unknown files in a > particular location and then determine them by an 'ls' equivalent, moc > them and compile everything is not something Qbs would be able to do. I'm having trouble parsing this, but if you mean that your previous guess was wrong, then I can tell you it was not; that's exactly what we do for "blackbox tools". > I'm still interested in a Qbs solution to the code/repo I posted before. > A full and preferably working Qbs solution, instead of a snippet, would > be good for comparison. That's more than I'm willing to invest during my vacation, but I might come back to you later there. Christian From thiago.macieira at intel.com Fri Sep 16 03:16:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 15 Sep 2016 18:16:08 -0700 Subject: [Development] Help! configure won't configure on Windows Message-ID: <3515742.nSWKF3TO2I@tjmaciei-mobl1> $ ls configure.cache $ cat configure.cache -opensource -developer-build -nomake tests -nomake examples -confirm-license -I c:/OpenSSL-Win32/include/ -L c:/OpenSSL-Win32/lib -I c:/qt/3rdparty/icu/include/ -L c:/Qt/3rdparty/icu/lib64 -openssl -icu -opengl desktop -make-tool jom Then I configure: $ cmd \ /c /c/Qt/qt5/qtbase/configure.bat -redo Please wait while bootstrapping configure ... = C:/Qt/qt5/qtbase = C:/Qt/qt5-msvc2015-x64/qtbase [syncqt runs] jom 1.1.0 - empower your cores [configure.exe compiles] mt.exe -nologo -manifest "configure.intermediate.manifest" - outputresource:..\..\configure.exe;1 This is the Qt for Windows Open Source Edition. You have already accepted the terms of the license. Running syncqt... = C:/Qt/qt5/qtbase = C:/Qt/qt5-msvc2015-x64/qtbase Creating qmake... jom 1.1.0 - empower your cores [qmake.exe compiles] copy qmake.exe ..\bin\qmake.exe 1 file(s) copied. Info: creating cache file C:\Qt\qt5-msvc2015-x64\qtbase\.qmake.cache $ Then I'm back at the prompt. There was no configuration. There is no mkspecs/ qconfig.pri and no mkspecs/qmodule.pri. Trying to compile produces error. I can't figure out *what* should be running the configure tests, where they are called from, much less why nothing is happening. $ jom jom 1.1.0 - empower your cores cd src\ && ( if not exist Makefile C:\Qt\qt5-msvc2015-x64\qtbase\bin \qmake -o Makefile C:\Qt\qt5\qtbase\src\src.pro -- -opensource -developer-build -nomake tests -nomake examples -confirm-license -I c:/OpenSSL-Win32/include/ -L c:/OpenSSL-Win32/lib -I c:/qt/3rdparty/icu/include/ -L c:/Qt/3rdparty/icu/ lib64 -openssl -icu -opengl desktop -make-tool jom ) && C:\Qt\jom\bin\jom.exe -f Makefile Project ERROR: Could not find feature system-zlib. jom: C:\Qt\qt5-msvc2015-x64\qtbase\Makefile [sub-src-make_first] Error 3 cd qmake\ && ( if not exist Makefile.qmake-aux C:\Qt\qt5-msvc2015- x64\qtbase\bin\qmake -o Makefile.qmake-aux C:\Qt\qt5\qtbase\qmake\qmake-aux.pro -- -opensource -developer-build -nomake tests -nomake examples -confirm-license -I c:/OpenSSL-Win32/include/ -L c:/OpenSSL-Win32/lib -I c:/qt/3rdparty/icu/ include/ -L c:/Qt/3rdparty/icu/lib64 -openssl -icu -opengl desktop -make-tool jom ) && C:\Qt\jom\bin\jom.exe -f Makefile.qmake-aux C:\Qt\jom\bin\jom.exe -f Makefile.qmake-aux.Release -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Sep 16 03:22:14 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 15 Sep 2016 18:22:14 -0700 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <3515742.nSWKF3TO2I@tjmaciei-mobl1> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> Message-ID: <1898348.4dIOKGYEx5@tjmaciei-mobl1> On quinta-feira, 15 de setembro de 2016 18:16:08 PDT Thiago Macieira wrote: > Then I'm back at the prompt. There was no configuration. There is no > mkspecs/ qconfig.pri and no mkspecs/qmodule.pri. Trying to compile produces > error. I can't figure out *what* should be running the configure tests, > where they are called from, much less why nothing is happening. Now this is happening on Linux too: $ ls bin config.status examples lib plugins src config.cache config.summary imports Makefile qmake tests config.opt config.tests include mkspecs qml translations $ ./config.status -recheck-all -v This is the Qt Open Source Edition. You are licensed to use this software under the terms of the GNU Lesser General Public License (LGPL) versions 3. You are also licensed to use this software under the terms of the GNU General Public License (GPL) versions 2. You have already accepted the terms of the Open Source license. Preparing build tree... = /home/tjmaciei/src/qt/qt5/qtbase = /home/tjmaciei/obj/qt/qt5/qtbase Creating qmake... gmake: Nothing to be done for 'first'. Qt is now configured for building. Just run 'gmake'. Once everything is built, Qt is installed. You should not run 'gmake install'. Prior to reconfiguration, make sure you remove any leftovers from the previous build. $ If I run with sh -x, I see this: + /home/tjmaciei/obj/qt/qt5/qtbase/bin/qmake -qtconf /home/tjmaciei/obj/qt/ qt5/qtbase/bin/qt.conf /home/tjmaciei/src/qt/qt5/qtbase -- -prefix /home/ tjmaciei/obj/qt/qt5/qtbase -opensource -confirm-license -developer-build - system-libjpeg -system-libpng -reduce-relocations -xcb -pch -platform linux-g+ +-optimised -system-sqlite -journald -qt-xkbcommon-x11 -dbus-runtime - qtlibinfix .t -nomake tests -nomake examples -sctp -recheck-all I've run that command manually and it exits with status 0. I've attached the -d -d output if anyone can help me figure out why it won't configure. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: qmake.trace.xz Type: application/x-xz Size: 181464 bytes Desc: not available URL: From thiago.macieira at intel.com Fri Sep 16 03:33:24 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 15 Sep 2016 18:33:24 -0700 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <1898348.4dIOKGYEx5@tjmaciei-mobl1> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <1898348.4dIOKGYEx5@tjmaciei-mobl1> Message-ID: <33571607.8kfsMgBhvr@tjmaciei-mobl1> On quinta-feira, 15 de setembro de 2016 18:22:14 PDT Thiago Macieira wrote: > On quinta-feira, 15 de setembro de 2016 18:16:08 PDT Thiago Macieira wrote: > > Then I'm back at the prompt. There was no configuration. There is no > > mkspecs/ qconfig.pri and no mkspecs/qmodule.pri. Trying to compile > > produces > > error. I can't figure out *what* should be running the configure tests, > > where they are called from, much less why nothing is happening. > > Now this is happening on Linux too: Ok, just to be sure, I've nuked EVERYTHING from another build and it also happens: $ ls -a . .. config.opt $ $srcdir/configure -redo This is the Qt Open Source Edition. You are licensed to use this software under the terms of the GNU Lesser General Public License (LGPL) versions 3. You are also licensed to use this software under the terms of the GNU General Public License (GPL) versions 2. You have already accepted the terms of the Open Source license. Preparing build tree... = /home/tjmaciei/src/qt/qt5/qtbase = /home/tjmaciei/obj/qt/qt5-clang/qtbase [syncqt runs] Creating qmake... .........................................................................................Done. Info: creating cache file /home/tjmaciei/obj/qt/qt5-clang/qtbase/.qmake.cache Qt is now configured for building. Just run 'gmake'. Once everything is built, Qt is installed. You should not run 'gmake install'. Prior to reconfiguration, make sure you remove any leftovers from the previous build. $ gmake cd src/ && ( test -e Makefile || /home/tjmaciei/obj/qt/qt5-clang/qtbase/bin/ qmake -o Makefile /home/tjmaciei/src/qt/qt5/qtbase/src/src.pro -qtconf /home/ tjmaciei/obj/qt/qt5-clang/qtbase/bin/qt.conf -- -prefix /home/tjmaciei/obj/qt/ qt5-clang/qtbase -opensource -confirm-license -developer-build -dbus -system- libjpeg -system-libpng -system-sqlite -reduce-relocations -xcb -pch -platform linux-clang-optimised -journald -dbus-runtime -qtlibinfix .t -nomake tests - nomake examples -release -recheck ) && gmake -f Makefile cd qmake/ && ( test -e Makefile.qmake-aux || /home/tjmaciei/obj/qt/qt5-clang/ qtbase/bin/qmake -o Makefile.qmake-aux /home/tjmaciei/src/qt/qt5/qtbase/qmake/ qmake-aux.pro -qtconf /home/tjmaciei/obj/qt/qt5-clang/qtbase/bin/qt.conf -- - prefix /home/tjmaciei/obj/qt/qt5-clang/qtbase -opensource -confirm-license - developer-build -dbus -system-libjpeg -system-libpng -system-sqlite -reduce- relocations -xcb -pch -platform linux-clang-optimised -journald -dbus-runtime -qtlibinfix .t -nomake tests -nomake examples -release -recheck ) && gmake -f Makefile.qmake-aux Project ERROR: Could not find feature system-zlib. gmake: *** [Makefile:46: sub-src-make_first] Error 3 gmake: ** Waiting for unfinished jobs.... gmake[1]: Entering directory '/home/tjmaciei/obj/qt/qt5-clang/qtbase/qmake' gmake[1]: Nothing to be done for 'first'. gmake[1]: Leaving directory '/home/tjmaciei/obj/qt/qt5-clang/qtbase/qmake' $ ls -aF . mkspecs .: ./ bin/ config.tests/ Makefile qmake/ src/ ../ config.opt include/ mkspecs/ .qmake.cache mkspecs: ./ ../ modules/ qdevice.pri qfeatures.pri qhost.pri $ cat config.opt -prefix /home/tjmaciei/obj/qt/qt5-clang/qtbase -opensource -confirm-license -developer-build -dbus -system-libjpeg -system-libpng -system-sqlite -reduce-relocations -xcb -pch -platform linux-clang-optimised -journald -dbus-runtime -qtlibinfix .t -nomake tests -nomake examples -release -recheck -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Sep 16 04:51:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 15 Sep 2016 19:51:16 -0700 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <33571607.8kfsMgBhvr@tjmaciei-mobl1> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <1898348.4dIOKGYEx5@tjmaciei-mobl1> <33571607.8kfsMgBhvr@tjmaciei-mobl1> Message-ID: <1628332.mg4ymtIhEC@tjmaciei-mobl1> On quinta-feira, 15 de setembro de 2016 18:33:24 PDT Thiago Macieira wrote: > On quinta-feira, 15 de setembro de 2016 18:22:14 PDT Thiago Macieira wrote: > > On quinta-feira, 15 de setembro de 2016 18:16:08 PDT Thiago Macieira wrote: > > > Then I'm back at the prompt. There was no configuration. There is no > > > mkspecs/ qconfig.pri and no mkspecs/qmodule.pri. Trying to compile > > > produces > > > error. I can't figure out *what* should be running the configure tests, > > > where they are called from, much less why nothing is happening. > > > > Now this is happening on Linux too: > Ok, just to be sure, I've nuked EVERYTHING from another build and it also > happens: I've reduce this to this commit: commit 60e5a1c8effd4099f7b1414107b5cbb67c266210 Author: Lars Knoll Date: Thu Aug 25 15:45:44 2016 +0200 Commit: Lars Knoll CommitDate: Sat Sep 10 14:04:01 2016 +0000 Modularize the new configure system (infrastructure part) [...] Configure is now automatically invoked when building the a project tree's "root" project; this works with both modular and top-level builds of Qt (the latter with an according change in the super repo). As an immediate consequence, the -skip option moves to the super repo with a different implementation, as configuration is now done after the repo list is determined. The option belongs there anyway. That other paragraph clued me in: I haven't updated qt5.git in a while. So I did and I tried to run qmake there: $ qmake $srcdir Running configuration tests... Checking for pkg-config... yes Checking for gold linker... yes [... cut ...] Build options: Mode ................................... release; optimized tools [...] Build parts ............................ libs examples tools Why is it running qtbase's configure in qt5.git? If that's to be expected, why is it not obeying the options I passed in configure? I passed -developer-build, which triggers a debug build. The above is release. I also passed -nomake examples, so why are examples listed? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Maurice.Kalinowski at qt.io Fri Sep 16 06:37:49 2016 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Fri, 16 Sep 2016 04:37:49 +0000 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <1628332.mg4ymtIhEC@tjmaciei-mobl1> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <1898348.4dIOKGYEx5@tjmaciei-mobl1> <33571607.8kfsMgBhvr@tjmaciei-mobl1> <1628332.mg4ymtIhEC@tjmaciei-mobl1> Message-ID: Quoting from another mail (haven't verified myself but rather reverted the patch Thiago mentioned locally): "Change https://codereview.qt-project.org/#/c/168922/ is required. Unfortunately it's not yet in, apparently partly due to the gerrit troubles." Maurice > -----Original Message----- > From: Development [mailto:development- > bounces+maurice.kalinowski=qt.io at qt-project.org] On Behalf Of Thiago > Macieira > Sent: Friday, September 16, 2016 4:51 AM > To: development at qt-project.org > Subject: Re: [Development] Help! configure won't configure on Windows > > On quinta-feira, 15 de setembro de 2016 18:33:24 PDT Thiago Macieira wrote: > > On quinta-feira, 15 de setembro de 2016 18:22:14 PDT Thiago Macieira > wrote: > > > On quinta-feira, 15 de setembro de 2016 18:16:08 PDT Thiago Macieira > wrote: > > > > Then I'm back at the prompt. There was no configuration. There is > > > > no mkspecs/ qconfig.pri and no mkspecs/qmodule.pri. Trying to > > > > compile produces error. I can't figure out *what* should be > > > > running the configure tests, where they are called from, much less > > > > why nothing is happening. > > > > > > Now this is happening on Linux too: > > Ok, just to be sure, I've nuked EVERYTHING from another build and it > > also > > happens: > > I've reduce this to this commit: > > commit 60e5a1c8effd4099f7b1414107b5cbb67c266210 > Author: Lars Knoll > Date: Thu Aug 25 15:45:44 2016 +0200 > Commit: Lars Knoll > CommitDate: Sat Sep 10 14:04:01 2016 +0000 > > Modularize the new configure system (infrastructure part) [...] > Configure is now automatically invoked when building the a project > tree's "root" project; this works with both modular and top-level builds > of Qt (the latter with an according change in the super repo). As an > immediate consequence, the -skip option moves to the super repo with a > different implementation, as configuration is now done after the repo > list is determined. The option belongs there anyway. > > That other paragraph clued me in: I haven't updated qt5.git in a while. So I did > and I tried to run qmake there: > > $ qmake $srcdir > > Running configuration tests... > Checking for pkg-config... yes > Checking for gold linker... yes > [... cut ...] > Build options: > Mode ................................... release; optimized tools [...] > Build parts ............................ libs examples tools > > > Why is it running qtbase's configure in qt5.git? If that's to be expected, why is > it not obeying the options I passed in configure? I passed -developer-build, > which triggers a debug build. The above is release. I also passed -nomake > examples, so why are examples listed? > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Fri Sep 16 08:34:48 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 15 Sep 2016 23:34:48 -0700 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <1628332.mg4ymtIhEC@tjmaciei-mobl1> Message-ID: <3558021.vPlrBhDpGL@tjmaciei-mobl1> On sexta-feira, 16 de setembro de 2016 04:37:49 PDT Maurice Kalinowski wrote: > Quoting from another mail (haven't verified myself but rather reverted the > patch Thiago mentioned locally): > > "Change https://codereview.qt-project.org/#/c/168922/ is required. > Unfortunately it's not yet in, apparently partly due to the gerrit > troubles." Looks like it landed now. The change says: Patch Set 1 Patch Set 2 Patch Set 537 :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alexander.blasche at qt.io Fri Sep 16 09:43:16 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Fri, 16 Sep 2016 07:43:16 +0000 Subject: [Development] Nominating Paolo Angelelli for Approver status In-Reply-To: References: Message-ID: Congratulations to Paolo. The permissions have been adjusted. -- Alex ________________________________________ From: Development on behalf of Alexander Blasche Sent: Friday, 26 August 2016 10:17:12 AM To: development at qt-project.org Subject: [Development] Nominating Paolo Angelelli for Approver status Hi, I'd like to nominate Paolo Angelelli for Approver status. He joined The Qt Company at the end of 2015, and has been working full time on Qt since. Paolo has been actively involved fixing and improving QtPositioning and QtLocation. -- Alex _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From stephen.kelly at ableton.com Fri Sep 16 11:49:58 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Fri, 16 Sep 2016 11:49:58 +0200 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> <20160915065714.GA17144@nubble> Message-ID: On 16/09/16 03:07, Christian Kandeler wrote: > Stephen Kelly wrote: > >> My previous guess about Qbs being able to generate unknown files in a >> particular location and then determine them by an 'ls' equivalent, moc >> them and compile everything is not something Qbs would be able to do. > I'm having trouble parsing this, but if you mean that your previous guess was wrong, then I can tell you it was not; that's exactly what we do for "blackbox tools". It is probably less confusing for you in the context of the previous email I wrote (you didn't respond to that one - I started with "There is no input file. There is only an input number."). Feel free to go back to read that one and hopefully respond to it. >> I'm still interested in a Qbs solution to the code/repo I posted before. >> A full and preferably working Qbs solution, instead of a snippet, would >> be good for comparison. > That's more than I'm willing to invest during my vacation, but I might come back to you later there. Great, thanks! -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 From probono at puredarwin.org Fri Sep 16 15:31:30 2016 From: probono at puredarwin.org (probono) Date: Fri, 16 Sep 2016 15:31:30 +0200 Subject: [Development] linuxdeployqt Message-ID: Hi all, I have been working on a deployment tool for Linux, linuxdeployqt, which I eventually would like to see merged into qttools.git. linuxdeployqt takes an application and makes it self-contained by copying in the Qt libraries and plugins that the application uses into a bundle. While based on macdeployqt it uses an equivalent logic but other tools. https://github.com/probonopd/linuxdeployqt/ Known issues: See GitHub Issues. Use with care, run with maximum verbosity. Watch out for FIXMEs in the code. This is stil very young, but I'd appreciate your testing, comments, and (ideally) code review. Regards, Simon From thiago.macieira at intel.com Fri Sep 16 08:40:34 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 15 Sep 2016 23:40:34 -0700 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <3558021.vPlrBhDpGL@tjmaciei-mobl1> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <3558021.vPlrBhDpGL@tjmaciei-mobl1> Message-ID: <2633070.6PfaamIOeg@tjmaciei-mobl1> On quinta-feira, 15 de setembro de 2016 23:34:48 PDT Thiago Macieira wrote: > On sexta-feira, 16 de setembro de 2016 04:37:49 PDT Maurice Kalinowski wrote: > > Quoting from another mail (haven't verified myself but rather reverted the > > patch Thiago mentioned locally): > > > > "Change https://codereview.qt-project.org/#/c/168922/ is required. > > Unfortunately it's not yet in, apparently partly due to the gerrit > > troubles." > > Looks like it landed now. > > The change says: > Patch Set 1 > Patch Set 2 > Patch Set 537 Ah, I see what you mean by Gerrit troubles. The change is marked as merged 22 hours ago, but it isn't in the 5.8 branch. If you update today, you'll need to revert three commits, not just one: a668c6a Convert the old feature system b754b28 rename description => label in configure.json 2d3c73f Modularize configure.json/.pri -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Fri Sep 16 22:43:39 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 16 Sep 2016 16:43:39 -0400 Subject: [Development] Notes on QtCore session @ QCS2016 In-Reply-To: <245522471.MNfLxLEXRv@tjmaciei-mobl1> References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> <245522471.MNfLxLEXRv@tjmaciei-mobl1> Message-ID: On 2016-09-05 20:02, Thiago Macieira wrote: > Em segunda-feira, 5 de setembro de 2016, às 19:00:40 PDT, Giuseppe D'Angelo > escreveu: >> Il 02/09/2016 17:01, Thiago Macieira ha scritto: >>> https://wiki.qt.io/QtCS2016_QtCore >>> >>> * Deprecation of APIs >>> >>> * qrand/qsrand -> replacement is Standard Library or your own >> >> Unfortunately there's no replacement for a thread safe, easy to use, >> deterministic, low quality random number generator. std::rand is not >> thread safe and the whole random API is not exactly user friendly... class RandomSource { ... double operator()() { m_seed = ((19073486328125 * m_seed) + 1) & 0x7fffffffffffffff; return ldexp(static_cast(m_seed), -63); } } auto r = RandomSource{}; // or construct with a known initial seed auto first_random_value = r(); auto next_random_value = r(); Class boilerplate omitted. A thread-local instance of this would give you thread safety, or depending on how you need to use it, you can just instantiate your own instance. Producing a "good" initial seed is more complicated, but for determinism obviously you will supply a known initial seed. FTR, I wrote this *after* C++11 came out. It's faster¹ than C++11 , has "pretty good" randomness characteristics, and is much, much easier to use. Having this or similar in Qt (with a suitable means of initial seeding) could indeed be still useful. (¹ IIRC... at least compared to the libstdc++ implementation at the time, although it's hard to imagine how it could possibly be *slower* given how trivial the code is.) > You're right the std:: API is not user-friendly. In fact, it's plainly user- > hostile, requiring multiple template arguments, creating objects that should > only be used with auto, and has a major problem with properly seeding the > entropy in certain scenarios. Still, the conclusion of the discussion is that > we don't to write a wrapper API. We should get the high-quality generator and > that should suffice for everyone. I will never, *ever* replace the PRNG shown with a high quality generator. The use case for which I wrote this - computer VFX, basically (think 'video games') - specifically needs a LOT of random numbers. Speed is critical, and the algorithm shown is essentially the fastest possible algorithm short of a LUT. A high quality (read: slow) algorithm would be completely unacceptable for my use case (though possibly useful for initial seeding). I'm not sure I'd use a high quality (slow) generator even for something like game AI. Using it for procedural content generation is out of the question. -- Matthew From holger at freyther.de Sat Sep 17 09:51:02 2016 From: holger at freyther.de (Holger Freyther) Date: Sat, 17 Sep 2016 09:51:02 +0200 Subject: [Development] Missing Qt modules from Coverity Scan In-Reply-To: References: Message-ID: <3086DA2C-553C-4122-85F2-5F281FDFCA47@freyther.de> > On 15 Sep 2016, at 14:51, Giuseppe D'Angelo wrote: > > Howdy, Hi! > > while playing around with Coverity Scan with a few colleagues of mine we > noticed that only qtbase is getting uploaded and therefore checked > (instead of the complete qt5.git). > > I'm fairly sure that this has changed recently, as there are bugs in > there against other modules which were automatically marked as "fixed" > by Coverity (because the corresponding code is now gone). > > May I ask the Good Samaritan who is regularly uploading builds of Qt to > Coverity to double check the configuration? thanks for pointing it out. It seems that qt5.git/configure in the dev branch is broken (or has changed behavior). The configure script in all its beauty is: ./configure -prefix /home/qt-project/install -debug -opensource -confirm-license -no-pch make -j 4 qt-project at Qt-Coverity:~/coverity/qt5$ make cd qtbase/ && ( test -e Makefile || /home/qt-project/coverity/qt5/qtbase/bin/qmake -o Makefile /home/qt-project/coverity/qt5/qtbase/qtbase.pro -qtconf /home/qt-project/coverity/qt5/qtbase/bin/qt.conf -- -prefix /home/qt-project/coverity/qt5/qtbase -opensource ) && make -f Makefile make[1]: Entering directory `/home/qt-project/coverity/qt5/qtbase' cd src/ && ( test -e Makefile || /home/qt-project/coverity/qt5/qtbase/bin/qmake -o Makefile /home/qt-project/coverity/qt5/qtbase/src/src.pro -qtconf /home/qt-project/coverity/qt5/qtbase/bin/qt.conf -- -prefix /home/qt-project/coverity/qt5/qtbase -opensource ) && make -f Makefile Cannot read /home/qt-project/coverity/qt5/qtbase/src/corelib/qtcore-config.pri: No such file or directory Cannot read /home/qt-project/coverity/qt5/qtbase/src/gui/qtgui-config.pri: No such file or directory Project ERROR: Could not find feature system-zlib. qt5.git is at 2fb27862aa760d88790b23e0eab3cd3be5341054 Is this a known problem? How should the configure be changed? holger From oswald.buddenhagen at qt.io Sat Sep 17 11:23:12 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Sat, 17 Sep 2016 11:23:12 +0200 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <1628332.mg4ymtIhEC@tjmaciei-mobl1> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <1898348.4dIOKGYEx5@tjmaciei-mobl1> <33571607.8kfsMgBhvr@tjmaciei-mobl1> <1628332.mg4ymtIhEC@tjmaciei-mobl1> Message-ID: <20160917092312.GC2164@nubble> On Thu, Sep 15, 2016 at 07:51:16PM -0700, Thiago Macieira wrote: > On quinta-feira, 15 de setembro de 2016 18:33:24 PDT Thiago Macieira wrote: > > Ok, just to be sure, I've nuked EVERYTHING from another build and it also > > happens: > > I've reduce this to this commit: > after this commit, qtbase is still _supposed_ to configure stand-alone, provided there are *no* build artifacts from qt5.git (look for hidden files). admittedly, i never tested this configuration, but i thought CI does (it builds every module separately, supposedly without a top-level tree). From thiago.macieira at intel.com Sat Sep 17 20:31:57 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 17 Sep 2016 11:31:57 -0700 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <2633070.6PfaamIOeg@tjmaciei-mobl1> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <3558021.vPlrBhDpGL@tjmaciei-mobl1> <2633070.6PfaamIOeg@tjmaciei-mobl1> Message-ID: <2428026.xiFBJFPTnc@tjmaciei-mobl1> Em quinta-feira, 15 de setembro de 2016, às 23:40:34 PDT, Thiago Macieira > Ah, I see what you mean by Gerrit troubles. The change is marked as merged > 22 hours ago, but it isn't in the 5.8 branch. > > If you update today, you'll need to revert three commits, not just one: > > a668c6a Convert the old feature system > b754b28 rename description => label in configure.json > 2d3c73f Modularize configure.json/.pri I'm upgrading this to a P0, since I can't figure out what to revert anymore. https://bugreports.qt.io/browse/QTBUG-56049 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Sep 17 21:49:36 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 17 Sep 2016 12:49:36 -0700 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <20160917092312.GC2164@nubble> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <1628332.mg4ymtIhEC@tjmaciei-mobl1> <20160917092312.GC2164@nubble> Message-ID: <1654789.27MmTHl0xo@tjmaciei-mobl1> On sábado, 17 de setembro de 2016 11:23:12 PDT Oswald Buddenhagen wrote: > On Thu, Sep 15, 2016 at 07:51:16PM -0700, Thiago Macieira wrote: > > On quinta-feira, 15 de setembro de 2016 18:33:24 PDT Thiago Macieira wrote: > > > Ok, just to be sure, I've nuked EVERYTHING from another build and it > > > also > > > > > happens: > > I've reduce this to this commit: > after this commit, qtbase is still _supposed_ to configure stand-alone, > provided there are *no* build artifacts from qt5.git (look for hidden > files). > admittedly, i never tested this configuration, but i thought CI does (it > builds every module separately, supposedly without a top-level tree). So how am I going to reconfigure qtbase once I've built the rest of qt5? My workflow is: cd qtbase configure make repeat for a month cd .. # to qt5.git qmake && make -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Sep 17 21:52:15 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 17 Sep 2016 12:52:15 -0700 Subject: [Development] Missing Qt modules from Coverity Scan In-Reply-To: <3086DA2C-553C-4122-85F2-5F281FDFCA47@freyther.de> References: <3086DA2C-553C-4122-85F2-5F281FDFCA47@freyther.de> Message-ID: <6487887.bg7TC8q1nz@tjmaciei-mobl1> On sábado, 17 de setembro de 2016 09:51:02 PDT Holger Freyther wrote: > Is this a known problem? How should the configure be changed? Same problem as I'm having (see the "Help!" thread and QTBUG-56049). Workaround: only build qtbase and do not build qt5.git. If you have built qt5.git in the past, make sure you've removed all artifacts. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Sun Sep 18 17:12:58 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 18 Sep 2016 17:12:58 +0200 Subject: [Development] Missing Qt modules from Coverity Scan In-Reply-To: <3086DA2C-553C-4122-85F2-5F281FDFCA47@freyther.de> References: <3086DA2C-553C-4122-85F2-5F281FDFCA47@freyther.de> Message-ID: <201609181712.59026.marc.mutz@kdab.com> On Saturday 17 September 2016 09:51:02 Holger Freyther wrote: > > On 15 Sep 2016, at 14:51, Giuseppe D'Angelo > > wrote: > > > > Howdy, > > Hi! > > > while playing around with Coverity Scan with a few colleagues of mine we > > noticed that only qtbase is getting uploaded and therefore checked > > (instead of the complete qt5.git). > > > > I'm fairly sure that this has changed recently, as there are bugs in > > there against other modules which were automatically marked as "fixed" > > by Coverity (because the corresponding code is now gone). > > > > May I ask the Good Samaritan who is regularly uploading builds of Qt to > > Coverity to double check the configuration? > > thanks for pointing it out. It seems that qt5.git/configure in the dev > branch is broken (or has changed behavior). This is another issue. This week's report only contains issues in code built by qmake, probably caused by the configure problem you mention. Last week's report, to which Peppe referred, however, contained all of qtbase, but none of the other modules. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From holger at freyther.de Sun Sep 18 19:59:24 2016 From: holger at freyther.de (Holger Freyther) Date: Sun, 18 Sep 2016 19:59:24 +0200 Subject: [Development] Missing Qt modules from Coverity Scan In-Reply-To: <201609181712.59026.marc.mutz@kdab.com> References: <3086DA2C-553C-4122-85F2-5F281FDFCA47@freyther.de> <201609181712.59026.marc.mutz@kdab.com> Message-ID: <96CF722A-616F-4FDB-836F-B854492BC8D0@freyther.de> > On 18 Sep 2016, at 17:12, Marc Mutz wrote: > > > This is another issue. This week's report only contains issues in code built > by qmake, probably caused by the configure problem you mention. > > Last week's report, to which Peppe referred, however, contained all of qtbase, > but none of the other modules. The build script driving the build didn't do set -e so I think it just errored out on qtbase compilation and uploaded a partial result. The system is a Ubuntu 14.04.03 and it seems Qt requires a newer system: /home/qt-project/coverity/qt5/qtbase/src/plugins/platforms/xcb/qxcbconnection.h:689:20: error: 'TabletData' is not a member of 'QXcbConnection' Q_DECLARE_TYPEINFO(QXcbConnection::TabletData::ValuatorClassInfo, Q_PRIMITIVE_TYPE); ^ From thiago.macieira at intel.com Sun Sep 18 20:40:04 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 18 Sep 2016 11:40:04 -0700 Subject: [Development] Missing Qt modules from Coverity Scan In-Reply-To: <96CF722A-616F-4FDB-836F-B854492BC8D0@freyther.de> References: <201609181712.59026.marc.mutz@kdab.com> <96CF722A-616F-4FDB-836F-B854492BC8D0@freyther.de> Message-ID: <5531894.8A3B5ofcB1@tjmaciei-mobl1> On domingo, 18 de setembro de 2016 19:59:24 PDT Holger Freyther wrote: > > On 18 Sep 2016, at 17:12, Marc Mutz wrote: > > > > > > This is another issue. This week's report only contains issues in code > > built by qmake, probably caused by the configure problem you mention. > > > > Last week's report, to which Peppe referred, however, contained all of > > qtbase, but none of the other modules. > > The build script driving the build didn't do set -e so I think it just > errored out on qtbase compilation and uploaded a partial result. The system > is a Ubuntu 14.04.03 and it seems Qt requires a newer system: > > /home/qt-project/coverity/qt5/qtbase/src/plugins/platforms/xcb/qxcbconnectio > n.h:689:20: error: 'TabletData' is not a member of 'QXcbConnection' > Q_DECLARE_TYPEINFO(QXcbConnection::TabletData::ValuatorClassInfo, > Q_PRIMITIVE_TYPE); ^ Maybe fixed by commit 8cedf59a6815bf6457879822c0429f4becf85567 Author: Allan Sandfeld Jensen , Tue Sep 6 12:30:33 2016 +0200 (12 days ago) Fix Linux build without XINPUT2 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at qt.io Sun Sep 18 22:22:57 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Sun, 18 Sep 2016 22:22:57 +0200 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <1654789.27MmTHl0xo@tjmaciei-mobl1> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <1628332.mg4ymtIhEC@tjmaciei-mobl1> <20160917092312.GC2164@nubble> <1654789.27MmTHl0xo@tjmaciei-mobl1> Message-ID: <20160918202257.GA31013@nubble> On Sat, Sep 17, 2016 at 12:49:36PM -0700, Thiago Macieira wrote: > So how am I going to reconfigure qtbase once I've built the rest of qt5? > you don't. you keep configuring qt5, or you clean out the non-qtbase artifacts first. > My workflow is: > you should consider yourself lucky that this ever worked. > cd qtbase > configure > make > repeat for a month > cd .. # to qt5.git > qmake && make From thiago.macieira at intel.com Mon Sep 19 01:44:43 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 18 Sep 2016 16:44:43 -0700 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <20160918202257.GA31013@nubble> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <1654789.27MmTHl0xo@tjmaciei-mobl1> <20160918202257.GA31013@nubble> Message-ID: <2098802.YqDBTfd0Qi@tjmaciei-mobl1> On domingo, 18 de setembro de 2016 22:22:57 PDT Oswald Buddenhagen wrote: > On Sat, Sep 17, 2016 at 12:49:36PM -0700, Thiago Macieira wrote: > > So how am I going to reconfigure qtbase once I've built the rest of qt5? > > you don't. you keep configuring qt5, or you clean out the non-qtbase > artifacts first. > > > My workflow is: > you should consider yourself lucky that this ever worked. It's worked for over 4 years. I may not be the only one doing this. Please fix it. > > > cd qtbase > > configure > > make > > repeat for a month > > cd .. # to qt5.git > > qmake && make > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Mon Sep 19 02:22:42 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 19 Sep 2016 00:22:42 +0000 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <2098802.YqDBTfd0Qi@tjmaciei-mobl1> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <1654789.27MmTHl0xo@tjmaciei-mobl1> <20160918202257.GA31013@nubble> <2098802.YqDBTfd0Qi@tjmaciei-mobl1> Message-ID: <7AD67F49-B2EF-4322-A780-E3E44E414E8B@qt.io> > On Sep 18, 2016, at 4:44 PM, Thiago Macieira wrote: > > On domingo, 18 de setembro de 2016 22:22:57 PDT Oswald Buddenhagen wrote: >> On Sat, Sep 17, 2016 at 12:49:36PM -0700, Thiago Macieira wrote: >>> So how am I going to reconfigure qtbase once I've built the rest of qt5? >> >> you don't. you keep configuring qt5, or you clean out the non-qtbase >> artifacts first. >> >>> My workflow is: >> you should consider yourself lucky that this ever worked. > > It's worked for over 4 years. I may not be the only one doing this. > > Please fix it. I don't see why we should, it seems an illogical workflow to configure qt5 and then expect to be able to configure from qtbase... > >> >>> cd qtbase >>> configure >>> make >>> repeat for a month >>> cd .. # to qt5.git >>> qmake && make >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From thiago.macieira at intel.com Mon Sep 19 03:12:17 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 18 Sep 2016 18:12:17 -0700 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <7AD67F49-B2EF-4322-A780-E3E44E414E8B@qt.io> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <2098802.YqDBTfd0Qi@tjmaciei-mobl1> <7AD67F49-B2EF-4322-A780-E3E44E414E8B@qt.io> Message-ID: <2528752.RSBiDnx0df@tjmaciei-mobl1> On segunda-feira, 19 de setembro de 2016 00:22:42 PDT Jake Petroules wrote: > > It's worked for over 4 years. I may not be the only one doing this. > > > > Please fix it. > > I don't see why we should, it seems an illogical workflow to configure qt5 > and then expect to be able to configure from qtbase... I don't configure qt5. I have never, ever run configure from there. I configure qtbase and run qmake in the other modules. There's a .pro file in qt5.git and it was useful to use it to generate a Makefile to build the other modules. And, like I said, others may have done the same. See the discussion on the Coverity issue. Please fix. > >>> cd qtbase > >>> configure > >>> make > >>> repeat for a month > >>> cd .. # to qt5.git > >>> qmake && make > >> > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chris.adams at qinetic.com.au Mon Sep 19 03:14:51 2016 From: chris.adams at qinetic.com.au (Chris Adams) Date: Mon, 19 Sep 2016 11:14:51 +1000 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null Message-ID: Hi, Recently, a few unit test failures[1] in the (unreleased) QtPIM module showed that the recent change[2] which changes the semantics of null assignment (from JS) to a QVariant Q_PROPERTY can affect existing client code. Certainly, the cases which are affected are most likely edge-cases (that is, specifically testing the type or value of the QVariant within C++ code to detect "null" assignment), however it is probably worth raising for discussion. Why was the change made? The commit message tells us what was changed, but not the reasoning behind the change. The unit tests were changed, so the behaviour change was clearly intentional (and the old behaviour considered problematic), and I assume that there must be very good reasons to make such a change, but it wasn't discussed on the mailing list, so I don't know what those reasons are. Best regards, Chris. [1] https://codereview.qt-project.org/#/c/170491/ [2] https://codereview.qt-project.org/#/c/167062/ www.qinetic.com.au - Qt And QML User Experience Specialists -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Mon Sep 19 08:00:58 2016 From: holger at freyther.de (Holger Freyther) Date: Mon, 19 Sep 2016 08:00:58 +0200 Subject: [Development] Missing Qt modules from Coverity Scan In-Reply-To: <5531894.8A3B5ofcB1@tjmaciei-mobl1> References: <201609181712.59026.marc.mutz@kdab.com> <96CF722A-616F-4FDB-836F-B854492BC8D0@freyther.de> <5531894.8A3B5ofcB1@tjmaciei-mobl1> Message-ID: <3F12D836-6EF1-40B1-BCFB-7B244FFECEE5@freyther.de> > On 18 Sep 2016, at 20:40, Thiago Macieira wrote: Hi! >> /home/qt-project/coverity/qt5/qtbase/src/plugins/platforms/xcb/qxcbconnectio >> n.h:689:20: error: 'TabletData' is not a member of 'QXcbConnection' >> Q_DECLARE_TYPEINFO(QXcbConnection::TabletData::ValuatorClassInfo, >> Q_PRIMITIVE_TYPE); ^ > > Maybe fixed by > > commit 8cedf59a6815bf6457879822c0429f4becf85567 > Author: Allan Sandfeld Jensen , Tue Sep 6 > 12:30:33 2016 +0200 (12 days ago) > > Fix Linux build without XINPUT2 > thank you! I have done a Ubuntu 14.04->16.04 upgrade on the build machine and installed more devel packages (xinput2, gles, udev, ssl, etc.). I use a a hack Simon had indicated in QTBUG-56049 and remove the .qmake.* files after ./configure has ran and on first make it starts to configure and build. Only downside is that it looks like -prefix is being ignored and everything ends up in module/lib/*.so.5.9.0 and then qtscxml can't find qml-private. have a nice week holger From holger at freyther.de Mon Sep 19 08:06:48 2016 From: holger at freyther.de (Holger Freyther) Date: Mon, 19 Sep 2016 08:06:48 +0200 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <2528752.RSBiDnx0df@tjmaciei-mobl1> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <2098802.YqDBTfd0Qi@tjmaciei-mobl1> <7AD67F49-B2EF-4322-A780-E3E44E414E8B@qt.io> <2528752.RSBiDnx0df@tjmaciei-mobl1> Message-ID: <5EED5566-21F8-4B5E-AEBC-6016D20A3BF8@freyther.de> > On 19 Sep 2016, at 03:12, Thiago Macieira wrote: > > Good Morning, > And, like I said, others may have done the same. See the discussion on the > Coverity issue. > > Please fix. as Thiago has indicated the following is broken on at least my Ubuntu system: cd qt5 .. clean + rebase + update all to dev ./configure -prefix ... make -j X the nice thing about this as build script for doing the coverity builds is that new modules will be built automatically and that I don't need to maintain dependencies between modules myself. so please fix it as this drives the coverity build. thank you holger From lars.knoll at qt.io Mon Sep 19 12:06:25 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 19 Sep 2016 10:06:25 +0000 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <5EED5566-21F8-4B5E-AEBC-6016D20A3BF8@freyther.de> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <2098802.YqDBTfd0Qi@tjmaciei-mobl1> <7AD67F49-B2EF-4322-A780-E3E44E414E8B@qt.io> <2528752.RSBiDnx0df@tjmaciei-mobl1> <5EED5566-21F8-4B5E-AEBC-6016D20A3BF8@freyther.de> Message-ID: On 19/09/16 08:06, "Development on behalf of Holger Freyther" wrote: > >> On 19 Sep 2016, at 03:12, Thiago Macieira wrote: >> >> > >Good Morning, > > >> And, like I said, others may have done the same. See the discussion on the >> Coverity issue. >> >> Please fix. > >as Thiago has indicated the following is broken on at least my Ubuntu system: > >cd qt5 >.. clean + rebase + update all to dev >./configure -prefix ... >make -j X That work flow (ie. Calling configure in qt5/) is supported. It was broken for a few days last week, but should work right now if you have qt5.git updated to the latest 5.8. Cheers, Lars > >the nice thing about this as build script for doing the coverity builds is >that new modules will be built automatically and that I don't need to maintain >dependencies between modules myself. > >so please fix it as this drives the coverity build. > >thank you > holger >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Mon Sep 19 13:03:10 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 19 Sep 2016 13:03:10 +0200 Subject: [Development] Notes on QtCore session @ QCS2016 In-Reply-To: References: <2275326.0xyQ0TLF9q@tjmaciei-mobl1> <245522471.MNfLxLEXRv@tjmaciei-mobl1> Message-ID: <201609191303.11160.marc.mutz@kdab.com> Can you please move this OT discussion to SG-14 (https://groups.google.com/a/isocpp.org/forum/#!forum/sg14), where it belongs? Thanks, Marc On Friday 16 September 2016 22:43:39 Matthew Woehlke wrote: > I will never, *ever* replace the PRNG shown with a high quality > generator. The use case for which I wrote this - computer VFX, basically > (think 'video games') - specifically needs a LOT of random numbers. > Speed is critical, and the algorithm shown is essentially the fastest > possible algorithm short of a LUT. A high quality (read: slow) algorithm > would be completely unacceptable for my use case (though possibly useful > for initial seeding). > > I'm not sure I'd use a high quality (slow) generator even for something > like game AI. Using it for procedural content generation is out of the > question. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From louai.al-khanji at qt.io Mon Sep 19 16:45:14 2016 From: louai.al-khanji at qt.io (Louai Al-Khanji) Date: Mon, 19 Sep 2016 14:45:14 +0000 Subject: [Development] linuxdeployqt In-Reply-To: References: Message-ID: <68AE4335-1F84-44B7-9BC5-4A5AFCF5A322@qt.io> Hi Simon, Nice! Looks like a good start. It’s something that’s definitely missing at the moment. You would likely get more people looking at it if you moved it over to Qt Code Review. Looking at the license headers, it looks like it is your intent that this could become part of Qt, and for that to happen it must before long go through code review anyway. From a quick look it seems to be mostly well written. I do wonder whether it might be better to use a tool other than ldd to find the library dependencies. objdump -p provides the same information, and also works for cross-compiles. Cheers, Louai PS: Apologies for the top post. On 9/16/16, 6:31 AM, "Development on behalf of probono" wrote: Hi all, I have been working on a deployment tool for Linux, linuxdeployqt, which I eventually would like to see merged into qttools.git. linuxdeployqt takes an application and makes it self-contained by copying in the Qt libraries and plugins that the application uses into a bundle. While based on macdeployqt it uses an equivalent logic but other tools. https://github.com/probonopd/linuxdeployqt/ Known issues: See GitHub Issues. Use with care, run with maximum verbosity. Watch out for FIXMEs in the code. This is stil very young, but I'd appreciate your testing, comments, and (ideally) code review. Regards, Simon _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at qt.io Mon Sep 19 17:03:04 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 19 Sep 2016 17:03:04 +0200 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <2528752.RSBiDnx0df@tjmaciei-mobl1> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <2098802.YqDBTfd0Qi@tjmaciei-mobl1> <7AD67F49-B2EF-4322-A780-E3E44E414E8B@qt.io> <2528752.RSBiDnx0df@tjmaciei-mobl1> Message-ID: <20160919150304.GA18649@nubble> On Sun, Sep 18, 2016 at 06:12:17PM -0700, Thiago Macieira wrote: > On segunda-feira, 19 de setembro de 2016 00:22:42 PDT Jake Petroules wrote: > > > It's worked for over 4 years. I may not be the only one doing this. > > > > > > Please fix it. > > > > I don't see why we should, it seems an illogical workflow to configure qt5 > > and then expect to be able to configure from qtbase... > > I don't configure qt5. I have never, ever run configure from there. > running qmake now *is* configure, and it's going to stay this way. > I configure qtbase and run qmake in the other modules. There's a .pro file in > qt5.git and it was useful to use it to generate a Makefile to build the other > modules. > still, this workflow relied on a bug: the possibility to make the build tree internally inconsistent. you can hack the project file to not create a super cache and not do the configuration step. this may actually work for non-prefix builds. otherwise, you need to build and install each module individually, which requires a different makefile altogether. > And, like I said, others may have done the same. > they'll get the same response. all roughly two of them. > See the discussion on the Coverity issue. > unrelated, as pointed out by others. > Please fix. > nope From VARD.ANTINYAN at cse.gu.se Mon Sep 19 17:13:43 2016 From: VARD.ANTINYAN at cse.gu.se (Vard Antinyan) Date: Mon, 19 Sep 2016 15:13:43 +0000 Subject: [Development] Code complexity survey Message-ID: <062c3c1c10fe404e92f38db2fe298035@cse.gu.se> Dear QT developers, We have undertaken a task to assess code complexity triggers and generate recommendations for developing simple and understandable code. Our intension is to share the results with you, developers, so everyone can learn the triggers behind complex software. We need your help for rigorous results. My request to you is - if you get 5-10 min. time, would you please consider to answer the questions of this survey on code complexity? https://goo.gl/forms/h9WXZ8VSEw7BUyHg1 You are welcome to learn preliminary results through this link: https://www.facebook.com/SoftwareCodeQuality/photos/?tab=album&album_id=1639816749664288 The results will be shared in a public webpage and everyone possible will be invited to learn and discuss them. Your knowledge and experience is vital for achieving substantial and generalizable results, and your effort is much appreciated! Sincerely Vard Antinyan PhD candidate in University of Gothenburg, Sweden Tel: 0046317725707 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Sep 19 17:42:58 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 19 Sep 2016 08:42:58 -0700 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <20160919150304.GA18649@nubble> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <2528752.RSBiDnx0df@tjmaciei-mobl1> <20160919150304.GA18649@nubble> Message-ID: <1746431.xOIkEhrxUt@tjmaciei-mobl1> On segunda-feira, 19 de setembro de 2016 17:03:04 PDT Oswald Buddenhagen wrote: > you can hack the project file to not create a super cache and not do the > configuration step. this may actually work for non-prefix builds. Will do. Do not expect any buildsystem contribution from me from this point forward. Or in any other modules besides qtbase. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Sep 19 17:44:56 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 19 Sep 2016 08:44:56 -0700 Subject: [Development] linuxdeployqt In-Reply-To: <68AE4335-1F84-44B7-9BC5-4A5AFCF5A322@qt.io> References: <68AE4335-1F84-44B7-9BC5-4A5AFCF5A322@qt.io> Message-ID: <2221108.u6lPYkWnes@tjmaciei-mobl1> On segunda-feira, 19 de setembro de 2016 14:45:14 PDT Louai Al-Khanji wrote: > From a quick look it seems to be mostly well written. I do wonder whether it > might be better to use a tool other than ldd to find the library > dependencies. objdump -p provides the same information, and also works for > cross-compiles. I'd parse the output of eu-readelf instead. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Mon Sep 19 17:58:22 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 19 Sep 2016 17:58:22 +0200 Subject: [Development] linuxdeployqt References: <68AE4335-1F84-44B7-9BC5-4A5AFCF5A322@qt.io> Message-ID: Louai Al-Khanji wrote: > From a quick look it seems to be mostly well written. I do wonder whether > it might be better to use a tool other than ldd to find the library > dependencies. objdump -p provides the same information, and also works for > cross-compiles. It's not the same thing, ldd is transitive, objdump is not. Kevin Kofler From thiago.macieira at intel.com Mon Sep 19 18:05:31 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 19 Sep 2016 09:05:31 -0700 Subject: [Development] Help! configure won't configure on Windows In-Reply-To: <1746431.xOIkEhrxUt@tjmaciei-mobl1> References: <3515742.nSWKF3TO2I@tjmaciei-mobl1> <20160919150304.GA18649@nubble> <1746431.xOIkEhrxUt@tjmaciei-mobl1> Message-ID: <1707516.QqDzqSzn1M@tjmaciei-mobl1> On segunda-feira, 19 de setembro de 2016 08:42:58 PDT Thiago Macieira wrote: > On segunda-feira, 19 de setembro de 2016 17:03:04 PDT Oswald Buddenhagen > > wrote: > > you can hack the project file to not create a super cache and not do the > > configuration step. this may actually work for non-prefix builds. > > Will do. > > Do not expect any buildsystem contribution from me from this point forward. > > Or in any other modules besides qtbase. diff --git i/qt.pro w/qt.pro index 1915fc2..87db477 100644 --- i/qt.pro +++ w/qt.pro @@ -1,5 +1,5 @@ # Create the super cache so modules will add themselves to it. -cache(, super) + TEMPLATE = subdirs @@ -94,4 +94,4 @@ for (mod, modules) { SUBDIRS += $$mod } -load(qt_configure) + -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Sep 19 18:06:30 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 19 Sep 2016 09:06:30 -0700 Subject: [Development] linuxdeployqt In-Reply-To: References: <68AE4335-1F84-44B7-9BC5-4A5AFCF5A322@qt.io> Message-ID: <2602326.e317Do8o5q@tjmaciei-mobl1> On segunda-feira, 19 de setembro de 2016 17:58:22 PDT Kevin Kofler wrote: > Louai Al-Khanji wrote: > > From a quick look it seems to be mostly well written. I do wonder whether > > it might be better to use a tool other than ldd to find the library > > dependencies. objdump -p provides the same information, and also works for > > cross-compiles. > > It's not the same thing, ldd is transitive, objdump is not. True, so you implement the transitiveness by running it on each library. The cross-platformness is more important, though: ldd can't be run on non-native binaries. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Mon Sep 19 18:09:58 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 19 Sep 2016 19:09:58 +0300 Subject: [Development] linuxdeployqt In-Reply-To: <2602326.e317Do8o5q@tjmaciei-mobl1> References: <68AE4335-1F84-44B7-9BC5-4A5AFCF5A322@qt.io> <2602326.e317Do8o5q@tjmaciei-mobl1> Message-ID: <84731474301398@web5o.yandex.ru> 19.09.2016, 19:06, "Thiago Macieira" : > On segunda-feira, 19 de setembro de 2016 17:58:22 PDT Kevin Kofler wrote: >>  Louai Al-Khanji wrote: >>  > From a quick look it seems to be mostly well written. I do wonder whether >>  > it might be better to use a tool other than ldd to find the library >>  > dependencies. objdump -p provides the same information, and also works for >>  > cross-compiles. >> >>  It's not the same thing, ldd is transitive, objdump is not. > > True, so you implement the transitiveness by running it on each library. The > cross-platformness is more important, though: ldd can't be run on non-native > binaries. ldd script itself may also be missing, and its implementation depends on glibc-specific variables which are not necessary supported when using other libc implementation. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Mon Sep 19 18:20:48 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 19 Sep 2016 09:20:48 -0700 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? Message-ID: <2037719.HAYudMlsJZ@tjmaciei-mobl1> This code was there in Qt 5.0, so I kept it when I refactored the numeric comparisons. Now, dealing with QTBUG-56073, I'm wondering if it should be there in the first place. Should we do fuzzy comparisns in QVariant? Note that the fuzzy comparisons are always performed in qreal precision (whichever that may be), regardless of whether the original number is float, double or an integer. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Mon Sep 19 18:48:10 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 19 Sep 2016 18:48:10 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <2037719.HAYudMlsJZ@tjmaciei-mobl1> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> Message-ID: <201609191848.11370.marc.mutz@kdab.com> On Monday 19 September 2016 18:20:48 Thiago Macieira wrote: > Should we do fuzzy comparisns in QVariant? If you talk about op==, then using fuzzy compare is a definite no-no, because it makes it impossible to define a hash function. Fuzzy comparision should be performed with a named function, qFuzzyCompare, and _only_ with that function. We need to fix other classes for Qt 6, too (e.g. Q(Size|Point|Line)F. That said, a qFuzzyCompare(QVariant, QVariant) would probably be useful, but requires extensive extra work, like hashing a QVariant, too. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From apoenitz at t-online.de Mon Sep 19 19:47:12 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 19 Sep 2016 19:47:12 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <2037719.HAYudMlsJZ@tjmaciei-mobl1> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> Message-ID: <20160919174712.GB3417@klara.mpi.htwm.de> On Mon, Sep 19, 2016 at 09:20:48AM -0700, Thiago Macieira wrote: > This code was there in Qt 5.0, so I kept it when I refactored the numeric > comparisons. Now, dealing with QTBUG-56073, I'm wondering if it should be > there in the first place. > > Should we do fuzzy comparisns in QVariant? No. QVariant should not expose any numeric or conversion functionality and *only* be used to store and retrieve data. Comparison/Ordering should only be used and only be available to the degree needed to fullfil basic container requirements. Everything else has bitten in the past, and will necessarily continue to do so, and adding more conceptually *wrong* features only digs deeper holes. Andre' From apoenitz at t-online.de Mon Sep 19 19:50:22 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 19 Sep 2016 19:50:22 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <201609191848.11370.marc.mutz@kdab.com> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <201609191848.11370.marc.mutz@kdab.com> Message-ID: <20160919175022.GC3417@klara.mpi.htwm.de> On Mon, Sep 19, 2016 at 06:48:10PM +0200, Marc Mutz wrote: > Fuzzy comparision should be performed with a named function, qFuzzyCompare, > and _only_ with that function. +1. > We need to fix other classes for Qt 6, too (e.g. Q(Size|Point|Line)F. +1. > That said, a qFuzzyCompare(QVariant, QVariant) would probably be useful, but > requires extensive extra work, like hashing a QVariant, too. +/-0. I'd personally prefer to request people to be explicit about what they think they will get. Andre' From thiago.macieira at intel.com Mon Sep 19 20:10:51 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 19 Sep 2016 11:10:51 -0700 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <20160919174712.GB3417@klara.mpi.htwm.de> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <20160919174712.GB3417@klara.mpi.htwm.de> Message-ID: <20222401.bEjRGi9JRg@tjmaciei-mobl1> On segunda-feira, 19 de setembro de 2016 19:47:12 PDT André Pönitz wrote: > On Mon, Sep 19, 2016 at 09:20:48AM -0700, Thiago Macieira wrote: > > This code was there in Qt 5.0, so I kept it when I refactored the numeric > > comparisons. Now, dealing with QTBUG-56073, I'm wondering if it should be > > there in the first place. > > > > Should we do fuzzy comparisns in QVariant? > > No. Ok, thanks for your and Marc's opinion. I agree with you. Since this is a P3 and 5.8 hasn't been released, I will push the behaviour change to 5.8 and drop the fuzzy comparison. > QVariant should not expose any numeric or conversion functionality and > *only* be used to store and retrieve data. Comparison/Ordering should > only be used and only be available to the degree needed to fullfil basic > container requirements. Everything else has bitten in the past, and > will necessarily continue to do so, and adding more conceptually *wrong* > features only digs deeper holes. That I can't do. The following will still compare equally: QVariant(1) == QVariant(1.) And the following will sort: QVariant::fromValue(0.5f) < QVariant(1) < QVariant(1.5) < QVariant(2ULL) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Mon Sep 19 21:21:01 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 19 Sep 2016 21:21:01 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <20222401.bEjRGi9JRg@tjmaciei-mobl1> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <20160919174712.GB3417@klara.mpi.htwm.de> <20222401.bEjRGi9JRg@tjmaciei-mobl1> Message-ID: <20160919192101.GA3852@klara.mpi.htwm.de> On Mon, Sep 19, 2016 at 11:10:51AM -0700, Thiago Macieira wrote: > On segunda-feira, 19 de setembro de 2016 19:47:12 PDT André Pönitz wrote: > > On Mon, Sep 19, 2016 at 09:20:48AM -0700, Thiago Macieira wrote: > > > This code was there in Qt 5.0, so I kept it when I refactored the numeric > > > comparisons. Now, dealing with QTBUG-56073, I'm wondering if it should be > > > there in the first place. > > > > > > Should we do fuzzy comparisns in QVariant? > > > > No. > > Ok, thanks for your and Marc's opinion. I agree with you. > > Since this is a P3 and 5.8 hasn't been released, I will push the behaviour > change to 5.8 and drop the fuzzy comparison. > > > QVariant should not expose any numeric or conversion functionality and > > *only* be used to store and retrieve data. Comparison/Ordering should > > only be used and only be available to the degree needed to fullfil basic > > container requirements. Everything else has bitten in the past, and > > will necessarily continue to do so, and adding more conceptually *wrong* > > features only digs deeper holes. > > That I can't do. That is understood. I am not asking to remove existing functionality, just to not to add "convenience" like QVariant v1 = char('a'); QVariant v2 = QChar('a'); QVariant v3 = QString("a"); assert(v1 == v2 && v2 == v3 && v1 != v3); Andre' From thiago.macieira at intel.com Mon Sep 19 22:18:56 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 19 Sep 2016 13:18:56 -0700 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <20160919192101.GA3852@klara.mpi.htwm.de> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <20222401.bEjRGi9JRg@tjmaciei-mobl1> <20160919192101.GA3852@klara.mpi.htwm.de> Message-ID: <1682928.R1N8Z7W7b7@tjmaciei-mobl1> On segunda-feira, 19 de setembro de 2016 21:21:01 PDT André Pönitz wrote: > On Mon, Sep 19, 2016 at 11:10:51AM -0700, Thiago Macieira wrote: > > Since this is a P3 and 5.8 hasn't been released, I will push the behaviour > > change to 5.8 and drop the fuzzy comparison. https://codereview.qt-project.org/171452 > > > QVariant should not expose any numeric or conversion functionality and > > > *only* be used to store and retrieve data. Comparison/Ordering should > > > only be used and only be available to the degree needed to fullfil basic > > > container requirements. Everything else has bitten in the past, and > > > will necessarily continue to do so, and adding more conceptually *wrong* > > > features only digs deeper holes. > > > > That I can't do. > > That is understood. > > I am not asking to remove existing functionality, just to not to add > "convenience" like > > QVariant v1 = char('a'); > QVariant v2 = QChar('a'); > QVariant v3 = QString("a"); > assert(v1 == v2 && v2 == v3 && v1 != v3); It may already be too late. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From olivier at woboq.com Mon Sep 19 23:27:52 2016 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 19 Sep 2016 23:27:52 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <201609191848.11370.marc.mutz@kdab.com> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <201609191848.11370.marc.mutz@kdab.com> Message-ID: <2023960.ebE3zJ8313@maurice> On Montag, 19. September 2016 18:48:10 CEST Marc Mutz wrote: > On Monday 19 September 2016 18:20:48 Thiago Macieira wrote: > > Should we do fuzzy comparisns in QVariant? > > If you talk about op==, then using fuzzy compare is a definite no-no, > because it makes it impossible to define a hash function. We really cannot have a qHash for QVariant anyway, because that would imply that ALL QVariant can be hashed, and compared. Which is not the case. Most custom types don't even register comparator function. So I don't think that's an argument. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From kde at carewolf.com Tue Sep 20 00:08:08 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Tue, 20 Sep 2016 00:08:08 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <1682928.R1N8Z7W7b7@tjmaciei-mobl1> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <20160919192101.GA3852@klara.mpi.htwm.de> <1682928.R1N8Z7W7b7@tjmaciei-mobl1> Message-ID: <201609200008.08923.kde@carewolf.com> On Monday 19 September 2016, Thiago Macieira wrote: > On segunda-feira, 19 de setembro de 2016 21:21:01 PDT André Pönitz wrote: > > On Mon, Sep 19, 2016 at 11:10:51AM -0700, Thiago Macieira wrote: > > > Since this is a P3 and 5.8 hasn't been released, I will push the > > > behaviour change to 5.8 and drop the fuzzy comparison. > > https://codereview.qt-project.org/171452 > > > > > QVariant should not expose any numeric or conversion functionality > > > > and *only* be used to store and retrieve data. Comparison/Ordering > > > > should only be used and only be available to the degree needed to > > > > fullfil basic container requirements. Everything else has bitten in > > > > the past, and will necessarily continue to do so, and adding more > > > > conceptually *wrong* features only digs deeper holes. > > > > > > That I can't do. > > > > That is understood. > > > > I am not asking to remove existing functionality, just to not to add > > "convenience" like > > > > QVariant v1 = char('a'); > > QVariant v2 = QChar('a'); > > QVariant v3 = QString("a"); > > assert(v1 == v2 && v2 == v3 && v1 != v3); > > It may already be too late. It is, I am pretty sure we can't fix associativity, but another example is that qvariant equality is not even commutative right now, in the example above v2 == v3, but v3 != v2 I had this patch for it two years ago: https://codereview.qt-project.org/#/c/92850 `Allan From louai.al-khanji at qt.io Tue Sep 20 00:45:01 2016 From: louai.al-khanji at qt.io (Louai Al-Khanji) Date: Mon, 19 Sep 2016 22:45:01 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt Message-ID: Hi all, Here are my notes from the QUIPs session. Thank you for your patience. :-) QUIPs are a proposed design process for Qt, modeled after Python’s PEPs. QUIP 1 introduces the general concept: http://quips-qt-io.herokuapp.com/quip-0001.html QUIP 2 details the Qt governance model, it’s simply the current wiki page converted into a QUIP: http://quips-qt-io.herokuapp.com/quip-0002.html QUIP 3 is an informational QUIP containing the session notes, which are repeated below: http://quips-qt-io.herokuapp.com/quip-0003.html The heroku domain is obviously a placeholder. I have also attached the source files for proposed QUIPs 1, 2, and 3 to this e-mail. One item left open was licensing of the QUIPs themselves. For these I propose Creative Commons CC0. Any and all feedback welcome. Cheers, Louai ---------------- BEGIN NOTES ---------------- At the Qt Contributors' Summit 2016 in Berlin a session was held to discuss the idea of introducing QUIPs as a new process for Qt governance. The general idea was introduced by looking at QUIPs 1 and 2, and by looking at some Python PEPs. The general feedback was positive. An attempt was made to identify the minimum set of work required to bootstrap QUIP, which was the main theme of the session. The overall discussion is summarized below, in roughly chronological order. - Discussed background of QUIP, the process and the documents. Referred to Python and looked at QUIP 1 and QUIP 2 which had been prepared prior to the session. - The idea is to have a new git repository with the QUIP text files - Managed through Qt's normal work flow, currently gerrit code review - The maintainer of the quips repository takes on required editorial duties - Agreed that the text documents should be limited to 80 character lines. - Agreed that care must be taken to ensure that QUIPs are written in "proper" English so as to be clear, understandable and concise. - Talked about how a new QUIP is introduced. The most important thing is to reserve a number, which is the identifier of any one QUIP. The title can change, and is expected to do so from time to time. - New QUIP documents will go through a review process like any other patch to Qt. The author of the QUIP is responsible for logging this discussion in the evolving QUIP itself. - The important thing is to bootstrap the process. Once it is bootstrapped, it is possible to fine-tune the QUIP process through QUIPs. It is expected that this will happen. - The question of what goes into a QUIP was discussed. QUIP 1 gives a rough overview of the different kinds of possible QUIPs. It is expected that the content be further specified in revisions of QUIP 1 or in follow-up QUIPs. - Like any other part of Qt, QUIPs are living documents. They can be updated, amended or entirely superseded by later ones. - QUIP licensing was discussed. Python's PEPs are required to be either placed in the public domain or licensed under the Open Publication License. The former is not possible in all jurisdictions and the latter has apparently been superseded by the Creative Commons licenses the CC0 license was suggested. - The minimum QUIP boostrapping process was discussed: 1. Post QUIP 1 to qt-development mailing list for discussion. 2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io has since been made available) 3. Create new git repository to hold QUIPs - The initial QUIP process was discussed: 1. Author of QUIP reserves new number in QUIP 0 (the index QUIP) through gerrit 2. The author gives notice of new QUIP by sending it to qt-development, either inline or as a text attachment (things like this can be refined later through QUIPs) 3. Concurrently the author pushes the draft to gerrit where further discussion can take place. This discussion must be described in the QUIP. 4. Decisions are achieved through the same lazy consensus mechanism that is in place today. In that respect nothing changes. 5. A final +2 from the QUIP maintainer(s) is required. This differs slightly from other parts of Qt as only the maintainer(s) can +2 changes to this repository. - Louai naively volunteered to convert existing material on the wiki into a series of QUIPs. - There was a question whether community guidelines could be described in a QUIP. The answer is a resounding yes. - The QUIP lifecycle was discussed. The following two items were explored: 1. Superseding QUIPs. These are QUIPs that both change some mechanism described in an earlier QUIP and change the content of that QUIP substantially. For small changes existing QUIPs can be updated. 2. Retroactive QUIPs are possible. That is to say, QUIPs can be written to describe a change that occured in the past. For instance, an Implementation Track QUIP can be written after something has been added. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: quip-0001.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: quip-0002.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: quip-0003.txt URL: From kevin.kofler at chello.at Tue Sep 20 03:08:42 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 20 Sep 2016 03:08:42 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <20160919174712.GB3417@klara.mpi.htwm.de> <20222401.bEjRGi9JRg@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > Since this is a P3 and 5.8 hasn't been released, I will push the behaviour > change to 5.8 and drop the fuzzy comparison. Is such a behavior change really acceptable for 5.8? I think it can break applications that were relying on the current behavior in pretty bad, hard to debug ways (random bugs based on rounding errors). Kevin Kofler From marc.mutz at kdab.com Tue Sep 20 08:57:17 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 20 Sep 2016 08:57:17 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <2023960.ebE3zJ8313@maurice> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <201609191848.11370.marc.mutz@kdab.com> <2023960.ebE3zJ8313@maurice> Message-ID: <201609200857.17800.marc.mutz@kdab.com> On Monday 19 September 2016 23:27:52 Olivier Goffart wrote: > On Montag, 19. September 2016 18:48:10 CEST Marc Mutz wrote: > > On Monday 19 September 2016 18:20:48 Thiago Macieira wrote: > > > Should we do fuzzy comparisns in QVariant? > > > > If you talk about op==, then using fuzzy compare is a definite no-no, > > because it makes it impossible to define a hash function. > > We really cannot have a qHash for QVariant anyway, because that would imply > that ALL QVariant can be hashed, and compared. Which is not the case. Most > custom types don't even register comparator function. > So I don't think that's an argument. We have a op== on QVariant, thus we must be able to have a qHash, but indeed, as I said, this is an extensive amount of work, as if introducing comparator functions from scratch. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From andre at familiesomers.nl Tue Sep 20 09:02:11 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Tue, 20 Sep 2016 09:02:11 +0200 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: Message-ID: <5a2ab55b-80c2-c606-83c1-335e7c7e1d49@familiesomers.nl> Hi, Thanks for posting this, it finally cleared up a few postings by Thiago from just after the event. I wrestled my way through this whole thing, trying to get through the self-referential nature of all the acronyms. Somewhere in the middle I finally found what a QUIP is supposed to be. However, nowhere did I find an explanation of what problem it is supposed to solve, why it solves it, or how it integrates with the current work flow. So far, it seems to me like a solution from some management sphere without a problem to solve. So, could you please explain, preferably without relying on all the acronyms, what problems this bureaucratization effort is trying to resolve, and how it fits the rest of our work flow (like making feature requests in Jira)? Thanks, André Op 20/09/2016 om 00:45 schreef Louai Al-Khanji: > Hi all, > > Here are my notes from the QUIPs session. Thank you for your patience. :-) > > QUIPs are a proposed design process for Qt, modeled after Python’s PEPs. > > QUIP 1 introduces the general concept: > > http://quips-qt-io.herokuapp.com/quip-0001.html > > QUIP 2 details the Qt governance model, it’s simply the current wiki page > converted into a QUIP: > > http://quips-qt-io.herokuapp.com/quip-0002.html > > QUIP 3 is an informational QUIP containing the session notes, which are > repeated below: > > http://quips-qt-io.herokuapp.com/quip-0003.html > > The heroku domain is obviously a placeholder. > > I have also attached the source files for proposed QUIPs 1, 2, and 3 to this e-mail. > > One item left open was licensing of the QUIPs themselves. For these I propose > Creative Commons CC0. > > Any and all feedback welcome. > > Cheers, > Louai > > ---------------- BEGIN NOTES ---------------- > > At the Qt Contributors' Summit 2016 in Berlin a session was held to discuss the > idea of introducing QUIPs as a new process for Qt governance. > > The general idea was introduced by looking at QUIPs 1 and 2, and by looking at > some Python PEPs. The general feedback was positive. An attempt was made to > identify the minimum set of work required to bootstrap QUIP, which was the main > theme of the session. > > The overall discussion is summarized below, in roughly chronological order. > > - Discussed background of QUIP, the process and the documents. Referred to > Python and looked at QUIP 1 and QUIP 2 which had been prepared prior to the > session. > > - The idea is to have a new git repository with the QUIP text files > > - Managed through Qt's normal work flow, currently gerrit code review > > - The maintainer of the quips repository takes on required editorial duties > - Agreed that the text documents should be limited to 80 character lines. > > - Agreed that care must be taken to ensure that QUIPs are written in "proper" > English so as to be clear, understandable and concise. > > - Talked about how a new QUIP is introduced. The most important thing is to > reserve a number, which is the identifier of any one QUIP. The title can > change, and is expected to do so from time to time. > > - New QUIP documents will go through a review process like any other patch to > Qt. The author of the QUIP is responsible for logging this discussion in the > evolving QUIP itself. > > - The important thing is to bootstrap the process. Once it is bootstrapped, it > is possible to fine-tune the QUIP process through QUIPs. It is expected that > this will happen. > > - The question of what goes into a QUIP was discussed. QUIP 1 gives a rough > overview of the different kinds of possible QUIPs. It is expected that the > content be further specified in revisions of QUIP 1 or in follow-up QUIPs. > > - Like any other part of Qt, QUIPs are living documents. They can be updated, > amended or entirely superseded by later ones. > > - QUIP licensing was discussed. Python's PEPs are required to be either placed > in the public domain or licensed under the Open Publication License. The > former is not possible in all jurisdictions and the latter has apparently > been superseded by the Creative Commons licenses the CC0 license was > suggested. > > - The minimum QUIP boostrapping process was discussed: > > 1. Post QUIP 1 to qt-development mailing list for discussion. > > 2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io > has since been made available) > > 3. Create new git repository to hold QUIPs > > - The initial QUIP process was discussed: > > 1. Author of QUIP reserves new number in QUIP 0 (the index QUIP) through > gerrit > > 2. The author gives notice of new QUIP by sending it to qt-development, > either inline or as a text attachment (things like this can be refined > later through QUIPs) > > 3. Concurrently the author pushes the draft to gerrit where further > discussion can take place. This discussion must be described in the QUIP. > > 4. Decisions are achieved through the same lazy consensus mechanism that > is in place today. In that respect nothing changes. > > 5. A final +2 from the QUIP maintainer(s) is required. This differs slightly > from other parts of Qt as only the maintainer(s) can +2 changes to this > repository. > > - Louai naively volunteered to convert existing material on the wiki into a > series of QUIPs. > > - There was a question whether community guidelines could be described in a > QUIP. The answer is a resounding yes. > > - The QUIP lifecycle was discussed. The following two items were explored: > > 1. Superseding QUIPs. These are QUIPs that both change some mechanism > described in an earlier QUIP and change the content of that QUIP > substantially. For small changes existing QUIPs can be updated. > > 2. Retroactive QUIPs are possible. That is to say, QUIPs can be written > to describe a change that occured in the past. For instance, an > Implementation Track QUIP can be written after something has been added. > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Sep 20 09:27:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 20 Sep 2016 00:27:50 -0700 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <5a2ab55b-80c2-c606-83c1-335e7c7e1d49@familiesomers.nl> References: <5a2ab55b-80c2-c606-83c1-335e7c7e1d49@familiesomers.nl> Message-ID: <3672068.6VsPie5nrh@tjmaciei-mobl1> On terça-feira, 20 de setembro de 2016 09:02:11 PDT André Somers wrote: > So, could you please explain, preferably without relying on all the > acronyms, what problems this bureaucratization effort is trying to > resolve, and how it fits the rest of our work flow (like making feature > requests in Jira)? Basically, QUIP extends the governance by formalising decisions. The governance says decisions are made by consensus and meritocracy on the mailing list. But once the discussion ends, how do we know what we agreed upon? And two years later, how do we find out what we had decided? Can you remember the list of C++11 features we're allowed to use? We had a discussion on the mailing list. Do you remember why we decided not to have the Standard Library in our ABI? That discussion happened in 2012. The mailing list archives are searchable, but that doesn't mean it's easy to find what you're looking for. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Tue Sep 20 10:54:05 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 20 Sep 2016 08:54:05 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <3672068.6VsPie5nrh@tjmaciei-mobl1> References: <5a2ab55b-80c2-c606-83c1-335e7c7e1d49@familiesomers.nl> <3672068.6VsPie5nrh@tjmaciei-mobl1> Message-ID: <2CB1DE71-DE05-4975-8D96-E62516B13ED5@qt.io> On 20/09/16 09:27, "Development on behalf of Thiago Macieira" wrote: On terça-feira, 20 de setembro de 2016 09:02:11 PDT André Somers wrote: > So, could you please explain, preferably without relying on all the > acronyms, what problems this bureaucratization effort is trying to > resolve, and how it fits the rest of our work flow (like making feature > requests in Jira)? Basically, QUIP extends the governance by formalising decisions. The governance says decisions are made by consensus and meritocracy on the mailing list. But once the discussion ends, how do we know what we agreed upon? And two years later, how do we find out what we had decided? Can you remember the list of C++11 features we're allowed to use? We had a discussion on the mailing list. Do you remember why we decided not to have the Standard Library in our ABI? That discussion happened in 2012. The mailing list archives are searchable, but that doesn't mean it's easy to find what you're looking for. And it formalizes the way we can discuss and comment on things, as QUIPs would be reviewed in codereview, then approved there. I believe it’ll lead to a better workflow and better decision making in the project than discussions on the mailing list that often end somewhat inconclusive. Cheers, Lars From edward.welbourne at qt.io Tue Sep 20 11:18:00 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 20 Sep 2016 09:18:00 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: Message-ID: Louai Al-Khanji wrote: > QUIPs are a proposed design process for Qt, modeled after Python’s PEPs. > > QUIP 1 introduces the general concept: > > http://quips-qt-io.herokuapp.com/quip-0001.html > > QUIP 2 details the Qt governance model, it’s simply the current wiki page > converted into a QUIP: > > http://quips-qt-io.herokuapp.com/quip-0002.html > > QUIP 3 is an informational QUIP containing the session notes, which are > repeated below: > > http://quips-qt-io.herokuapp.com/quip-0003.html > > The heroku domain is obviously a placeholder. In the interests of stability and to complete the Wiki's coverage of QtCon, I've turned the write-up at the end of your mail into: https://wiki.qt.io/QUIPs_for_Qt_at_QtCon_2016 I have concocted a crude Template:QUIP for use on the Wiki [*] and used it in this write-up. Thus there need only be one place on the Wiki that needs to change when the QUIPs find their new home. Just write {{QUIP|N}} to link to QUIP N. [*] https://wiki.qt.io/Template:QUIP If someone with more Wiki-template-foo could please review this, I'm sure it can be improved; in particular, it uses 000{{{1}}} where clearly some analogue of formatting {{{1}}} with %03d would be more apt. Eddy. From edward.welbourne at qt.io Tue Sep 20 11:23:23 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 20 Sep 2016 09:23:23 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: , Message-ID: > [*] https://wiki.qt.io/Template:QUIP > If someone with more Wiki-template-foo could please review this, I'm > sure it can be improved; in particular, it uses 000{{{1}}} where clearly > some analogue of formatting {{{1}}} with %03d would be more apt. Sorry, obviously I meant %04d ... Eddy. From olivier at woboq.com Tue Sep 20 11:29:32 2016 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 20 Sep 2016 11:29:32 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <20222401.bEjRGi9JRg@tjmaciei-mobl1> Message-ID: <1970306.GPDMVAqAdm@maurice> On Dienstag, 20. September 2016 03:08:42 CEST Kevin Kofler wrote: > Thiago Macieira wrote: > > Since this is a P3 and 5.8 hasn't been released, I will push the behaviour > > change to 5.8 and drop the fuzzy comparison. > > Is such a behavior change really acceptable for 5.8? I think it can break > applications that were relying on the current behavior in pretty bad, hard > to debug ways (random bugs based on rounding errors). I tend to agree with that. This is a behavior change, and i see no reason to do it. Comparing double for equality with operator== is a bad idea. I know QVariant::operator== has problems, but i don't think this is something that should be changed. (Correct me if i'm wrong, but this might actually have quite some bad performance impact on QML where lot of bindings are done on a real value and they are compared for equality before emiting the changed signal. (or does QML takes the value out of qvariant before comparing?)) On the other hand, the fact that qFuzzyCompare(inf, -inf) returns true looks like a bug within qFuzzyCompare. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From mathias at taschenorakel.de Tue Sep 20 12:21:11 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Tue, 20 Sep 2016 12:21:11 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <2023960.ebE3zJ8313@maurice> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <201609191848.11370.marc.mutz@kdab.com> <2023960.ebE3zJ8313@maurice> Message-ID: Am 19.09.2016 um 23:27 schrieb Olivier Goffart: > We really cannot have a qHash for QVariant anyway, because that would imply > that ALL QVariant can be hashed, and compared. Which is not the case. Most > custom types don't even register comparator function. Which actually is quite a serious issue, as we do a simply memcmp() on such custom types, which simply won't work if your custom data structure contains uninitialized memory from alignment padding. It is easy to forget registering comparator functions and currently Qt doesn't help in debugging such issues. So I wonder if QVariant should forbid comparison of custom types without having a comparator function registered. Ciao, Mathias From olivier at woboq.com Tue Sep 20 12:44:04 2016 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 20 Sep 2016 12:44:04 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <2023960.ebE3zJ8313@maurice> Message-ID: <1572252.L1a78adV0X@maurice> On Dienstag, 20. September 2016 12:21:11 CEST Mathias Hasselmann wrote: > Am 19.09.2016 um 23:27 schrieb Olivier Goffart: > > We really cannot have a qHash for QVariant anyway, because that would > > imply > > that ALL QVariant can be hashed, and compared. Which is not the case. Most > > custom types don't even register comparator function. > > Which actually is quite a serious issue, as we do a simply memcmp() on > such custom types, which simply won't work if your custom data structure > contains uninitialized memory from alignment padding. We don't do that. We just return false in that case. > It is easy to forget registering comparator functions and currently Qt > doesn't help in debugging such issues. So I wonder if QVariant should > forbid comparison of custom types without having a comparator function > registered. That's a source incompatible change. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From marc.mutz at kdab.com Tue Sep 20 12:57:49 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 20 Sep 2016 12:57:49 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <1572252.L1a78adV0X@maurice> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <1572252.L1a78adV0X@maurice> Message-ID: <201609201257.50145.marc.mutz@kdab.com> On Tuesday 20 September 2016 12:44:04 Olivier Goffart wrote: > > It is easy to forget registering comparator functions and currently Qt > > doesn't help in debugging such issues. So I wonder if QVariant should > > forbid comparison of custom types without having a comparator function > > registered. > > That's a source incompatible change. But one of the type we allow (fixes still compile and work with older Qt), in line with adding `explicit` to ctors that miss it. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Tue Sep 20 18:46:45 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 20 Sep 2016 09:46:45 -0700 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <2CB1DE71-DE05-4975-8D96-E62516B13ED5@qt.io> References: <3672068.6VsPie5nrh@tjmaciei-mobl1> <2CB1DE71-DE05-4975-8D96-E62516B13ED5@qt.io> Message-ID: <184398978.2tWNJuWaxk@tjmaciei-mobl1> On terça-feira, 20 de setembro de 2016 08:54:05 PDT Lars Knoll wrote: > And it formalizes the way we can discuss and comment on things, as QUIPs > would be reviewed in codereview, then approved there. I believe it’ll lead > to a better workflow and better decision making in the project than > discussions on the mailing list that often end somewhat inconclusive. Discussions on content still happen on the mailing list for maximum reachability. The discussion on codereview is just the editorial workflow. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 20 18:51:31 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 20 Sep 2016 09:51:31 -0700 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <1970306.GPDMVAqAdm@maurice> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <1970306.GPDMVAqAdm@maurice> Message-ID: <10062324.xAOng0RbG1@tjmaciei-mobl1> On terça-feira, 20 de setembro de 2016 11:29:32 PDT Olivier Goffart wrote: > > Is such a behavior change really acceptable for 5.8? I think it can break > > applications that were relying on the current behavior in pretty bad, hard > > to debug ways (random bugs based on rounding errors). > > I tend to agree with that. > This is a behavior change, and i see no reason to do it. Comparing double > for equality with operator== is a bad idea. > I know QVariant::operator== has problems, but i don't think this is > something that should be changed. I did add a changelog for important behaviour change and I do think it should be changed. Fuzzy comparisons only operate on certain values. We know there's a problem with them when both numbers are close to zero: for example, fuzzy comparing 1.2e-12 to 0 is false, comparing it to -1.2e-12 is false, even though they could be the result from the same operation. I also think that if you want a fuzzy comparison in variants, you should call qFuzzyCompare(QVariant, QVariant) (which doesn't exist, I can add it). > (Correct me if i'm wrong, but this might actually have quite some bad > performance impact on QML where lot of bindings are done on a real value and > they are compared for equality before emiting the changed signal. (or does > QML takes the value out of qvariant before comparing?)) Question for Simon. > On the other hand, the fact that qFuzzyCompare(inf, -inf) returns true looks > like a bug within qFuzzyCompare. And I will reject any patch that adds more complexity in qFuzzyCompare for a 0.01% corner-case. Instead, we should document that it only works for finite numbers far enough away from zero. If your number can be infinite or NaN or zero, you have to find something else. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From filippocucchetto at gmail.com Tue Sep 20 19:04:07 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Tue, 20 Sep 2016 19:04:07 +0200 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <184398978.2tWNJuWaxk@tjmaciei-mobl1> References: <3672068.6VsPie5nrh@tjmaciei-mobl1> <2CB1DE71-DE05-4975-8D96-E62516B13ED5@qt.io> <184398978.2tWNJuWaxk@tjmaciei-mobl1> Message-ID: Really? Shouldn't be better to just announce a proposal on the mailing list and then shift the discussion and feedbacks on the codereview? 2016-09-20 18:46 GMT+02:00 Thiago Macieira : > On terça-feira, 20 de setembro de 2016 08:54:05 PDT Lars Knoll wrote: >> And it formalizes the way we can discuss and comment on things, as QUIPs >> would be reviewed in codereview, then approved there. I believe it’ll lead >> to a better workflow and better decision making in the project than >> discussions on the mailing list that often end somewhat inconclusive. > > Discussions on content still happen on the mailing list for maximum > reachability. The discussion on codereview is just the editorial workflow. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Filippo Cucchetto From lars.knoll at qt.io Tue Sep 20 19:53:36 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 20 Sep 2016 17:53:36 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <3672068.6VsPie5nrh@tjmaciei-mobl1> <2CB1DE71-DE05-4975-8D96-E62516B13ED5@qt.io> <184398978.2tWNJuWaxk@tjmaciei-mobl1> Message-ID: My thinking. I’m fine to have initial discussions on the mailing list, but agreeing on and nailing down details will be a lot easier to do on codereview. Lars On 20/09/16 19:04, "Development on behalf of Filippo Cucchetto" wrote: Really? Shouldn't be better to just announce a proposal on the mailing list and then shift the discussion and feedbacks on the codereview? 2016-09-20 18:46 GMT+02:00 Thiago Macieira : > On terça-feira, 20 de setembro de 2016 08:54:05 PDT Lars Knoll wrote: >> And it formalizes the way we can discuss and comment on things, as QUIPs >> would be reviewed in codereview, then approved there. I believe it’ll lead >> to a better workflow and better decision making in the project than >> discussions on the mailing list that often end somewhat inconclusive. > > Discussions on content still happen on the mailing list for maximum > reachability. The discussion on codereview is just the editorial workflow. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Filippo Cucchetto _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From mwoehlke.floss at gmail.com Tue Sep 20 21:10:42 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 20 Sep 2016 15:10:42 -0400 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> Message-ID: On 2016-09-08 07:41, Bo Thorsen wrote: > Den 05-09-2016 kl. 20:49 skrev Milian Wolff: >>> As an incredibly simple example, make is inherently limited in that it >>> cannot even represent a rule with multiple outputs (there are some >>> workarounds, but they are hacky and rather limited in how they can be >>> applied). And ninja is no magic bullet here either, because that still >>> represents a static build graph, whereas the content of Qbs' build >>> graph can actually change during the execution of the build. >> >> Can you give an example for why we should care? This may sound >> flame-baity, but I'm really truly interested. I simply don't care >> about my build system, as long as it gets the job done without too >> much hassle (and yes, that is the case for me personally with >> cmake), and fast, too (which is the case with ninja). > > I can answer that because I asked for this feature all the way back at > QtCS in Bilbao. > > The context I was talking about was code generators. At the time I had > built a code generator that created both the Qt and the PHP side of a > client-server system. It had a single JSON file that described a server > with the available remote methods on it. The output from the C++ code > generator was a .h and .cpp file per method and a single .h and .cpp > that described the server. So on qmake run time you can't know how many > output files you have unless you force the user to run qmake every time > you modify the JSON description. > > And to make the problem worse, the customer wanted each of the classes > describing a remote call to be qobjects with a Q_OBJECT so a moc run is > required. > > AFAIK this is impossible to do with both qmake and cmake. Not just hard, > actually impossible. It's not *impossible*... it "just" requires that you be able to determine the outputs at configure time, e.g. by having the tool run in a mode that does nothing but report what files will be produced. Granted, this is arduous, and especially terrible if the complexity of determining the output files is on the order of producing them in the first place, but saying it's "actually impossible" is a bit of an exaggeration. (This can't exactly work with VS because the *way* it works is to force CMake to re-run when the file(s) that determine the output files change. That works with e.g. make/ninja, but not so well with VS, but that's a VS failing that I don't see how Qbs could overcome, given that VS *is* the build tool and doesn't AFAIK support dynamic build graphs. Blaming CMake for VS's shortcomings isn't really fair.) The project I'm working on currently uses LCM, which has this problem (we also use CMake, and have a CMake script that parses the input files in order to determine the names of the output files). So does PySide / Shiboken, and I'm sure there are other examples out there. -- Matthew From annulen at yandex.ru Tue Sep 20 21:18:42 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 20 Sep 2016 22:18:42 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> Message-ID: <3839841474399122@web3j.yandex.ru> 20.09.2016, 22:11, "Matthew Woehlke" : > That works with e.g. make/ninja, but not so well with VS, but that's a > VS failing that I don't see how Qbs could overcome, given that VS *is* > the build tool and doesn't AFAIK support dynamic build graphs. QBS does not use VS as a build tool, it is not a project generator -- Regards, Konstantin From mwoehlke.floss at gmail.com Tue Sep 20 21:20:49 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 20 Sep 2016 15:20:49 -0400 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <20160915065714.GA17144@nubble> References: <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> <20160915065714.GA17144@nubble> Message-ID: On 2016-09-15 02:57, Oswald Buddenhagen wrote: > On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development wrote: >> I want to understand Qbs and what it can do with a dynamic build graph >> which CMake can't do. > > there is no such thing, as after full expansion the graph has to be > static by definition (the output artifacts are expected to be > deterministic, after all). I don't think that's actually true; it just has to *halt*. That is, you can execute as many steps as you like that generate new build edges, as long as *at some point* you end up with a static graph. CMake necessarily imposes that you can run exactly one iteration, but I'm not aware of any theoretical reason you couldn't have an entire chain of targets each of which don't know their outputs (which are the inputs of the next in the chain) until you go to actually build them. For that matter, you can do that sort of thing with make, by having each target depend on the previous one, and generate a new Makefile that is used to build the next one. -- Matthew From Jake.Petroules at qt.io Tue Sep 20 21:21:51 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 20 Sep 2016 19:21:51 +0000 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <3839841474399122@web3j.yandex.ru> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <3839841474399122@web3j.yandex.ru> Message-ID: <4ADB8177-B2BE-45A3-AD8F-510D95649380@qt.io> > On Sep 20, 2016, at 12:18 PM, Konstantin Tokarev wrote: > > > > 20.09.2016, 22:11, "Matthew Woehlke" : >> That works with e.g. make/ninja, but not so well with VS, but that's a >> VS failing that I don't see how Qbs could overcome, given that VS *is* >> the build tool and doesn't AFAIK support dynamic build graphs. > > QBS does not use VS as a build tool, it is not a project generator Although it can act as one; I recently added support for generating VS projects: https://codereview.qt-project.org/#/c/91353/ Qbs still performs the build entirely on its own though, the VS output is no more than a file listing. > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From annulen at yandex.ru Tue Sep 20 21:24:23 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 20 Sep 2016 22:24:23 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <2391268.OHDipyMWUV@agathebauer> <8e7638e5-4dc4-14a3-d4f6-5698728689d7@vikingsoft.eu> <20160915065714.GA17144@nubble> Message-ID: <3847291474399463@web3j.yandex.ru> 20.09.2016, 22:21, "Matthew Woehlke" : > On 2016-09-15 02:57, Oswald Buddenhagen wrote: >>  On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development wrote: >>>  I want to understand Qbs and what it can do with a dynamic build graph >>>  which CMake can't do. >> >>  there is no such thing, as after full expansion the graph has to be >>  static by definition (the output artifacts are expected to be >>  deterministic, after all). > > I don't think that's actually true; it just has to *halt*. That is, you > can execute as many steps as you like that generate new build edges, as > long as *at some point* you end up with a static graph. > > CMake necessarily imposes that you can run exactly one iteration, but > I'm not aware of any theoretical reason you couldn't have an entire > chain of targets each of which don't know their outputs (which are the > inputs of the next in the chain) until you go to actually build them. > > For that matter, you can do that sort of thing with make, by having each > target depend on the previous one, and generate a new Makefile that is > used to build the next one. More popular pattern: include generated makefile (e.g., depfile produced by GCC) into "master" makefile -- Regards, Konstantin From thiago.macieira at intel.com Tue Sep 20 21:26:19 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 20 Sep 2016 12:26:19 -0700 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: <184398978.2tWNJuWaxk@tjmaciei-mobl1> Message-ID: <4467854.jDW3d3qIxX@tjmaciei-mobl1> On terça-feira, 20 de setembro de 2016 19:04:07 PDT Filippo Cucchetto wrote: > Really? > Shouldn't be better to just announce a proposal on the mailing list > and then shift the discussion and feedbacks > on the codereview? It may come as a shock to you, but the Gerrit user interface is horrible. Reviewing discussions after they're done is very difficult, since there's no way to dump inline comments with the 5-year-old interface we're using (the one Gerrit added some time 3 or 4 years ago can do it). Joining a discussion in progress is very difficult. Email is much easier. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Tue Sep 20 21:25:31 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 20 Sep 2016 15:25:31 -0400 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: <3839841474399122@web3j.yandex.ru> References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <3839841474399122@web3j.yandex.ru> Message-ID: On 2016-09-20 15:18, Konstantin Tokarev wrote: > 20.09.2016, 22:11, "Matthew Woehlke" : >> That works with e.g. make/ninja, but not so well with VS, but that's a >> VS failing that I don't see how Qbs could overcome, given that VS *is* >> the build tool and doesn't AFAIK support dynamic build graphs. > > QBS does not use VS as a build tool, it is not a project generator ...but that's sort of my point; calling CMake deficient because it can't do something that Qbs can't do either is disingenuous. Saying "oh, but Qbs just tells VS to invoke Qbs" isn't really better; there is no reason (besides "no one has implemented it") why CMake couldn't do the same thing with e.g. ninja as the build driver. (And either case assumes you don't include the generated files in the VS project, or both will still have VS complaining about reloading the project...) -- Matthew From asmirnov at ilbers.de Tue Sep 20 21:48:42 2016 From: asmirnov at ilbers.de (Alexander Smirnov) Date: Tue, 20 Sep 2016 22:48:42 +0300 Subject: [Development] Qt5 Bearer: broken PPP support Message-ID: <57E1929A.2050900@ilbers.de> Dear all, I've faced with the following problem. I use the Linux-based board, in which I start PPP daemon to have GPRS networking. After upgrading from Qt5.4 to Qt5.6 my ppp0 interface is always in QNetworkConfiguration::Defined state, so it's unusable. After debugging I figured out, that the problem is in commit: 043f5d3eb52587831f643bc52c95079c36d984c7 This commit allows to add to list: QList interfaces; interfaces with no address field (ifa_addr == NULL). Then, I've checked the output from 'getifaddrs()' syscall on my board, and it returns 2! instances of ppp0: - one with AF_INET family - one with ifa_addr == NULL So, with the commit mentioned above, there are 2 ppp0 interfaces now in the list, one - correct, second - incorrect. Due to this mix, eventually in QGenericEngine::doRequestUpdate() ppp0 is always set to QNetworkConfiguration::Defined, because: interface.addressEntries().isEmpty() Reverting the patch helps to get ppp0 in QNetworkConfiguration::Active state. So, is it a bug? :-) -- With best regards, Alexander Smirnov ilbers GmbH Baierbrunner Str. 28c D-81379 München +49 (89) 122 67 24-0 http://ilbers.de/ Commercial register Munich, HRB 214197 General manager: Baurzhan Ismagulov From filippocucchetto at gmail.com Tue Sep 20 22:12:22 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Tue, 20 Sep 2016 22:12:22 +0200 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <4467854.jDW3d3qIxX@tjmaciei-mobl1> References: <184398978.2tWNJuWaxk@tjmaciei-mobl1> <4467854.jDW3d3qIxX@tjmaciei-mobl1> Message-ID: I could agree, but basically you're saying that the problem is the tool and not the idea to discuss the details on the codereview. At the end a proposal is for sure a document (thus a sort of source file) and so gerrit would help matching the discussion with the actual version of the document (imho this could be harder by email). Given that i'm ok in both codereview or email...maybe i'm too biased by github :) 2016-09-20 21:26 GMT+02:00 Thiago Macieira : > On terça-feira, 20 de setembro de 2016 19:04:07 PDT Filippo Cucchetto wrote: >> Really? >> Shouldn't be better to just announce a proposal on the mailing list >> and then shift the discussion and feedbacks >> on the codereview? > > It may come as a shock to you, but the Gerrit user interface is horrible. > Reviewing discussions after they're done is very difficult, since there's no way > to dump inline comments with the 5-year-old interface we're using (the one > Gerrit added some time 3 or 4 years ago can do it). Joining a discussion in > progress is very difficult. > > Email is much easier. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Filippo Cucchetto From sahumada at texla.cl Tue Sep 20 22:30:56 2016 From: sahumada at texla.cl (Sergio Ahumada) Date: Tue, 20 Sep 2016 22:30:56 +0200 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <4467854.jDW3d3qIxX@tjmaciei-mobl1> References: <184398978.2tWNJuWaxk@tjmaciei-mobl1> <4467854.jDW3d3qIxX@tjmaciei-mobl1> Message-ID: <0900a02f-3743-4ff3-e267-e7777f150df1@texla.cl> On 20.09.2016 21:26, Thiago Macieira wrote: > On terça-feira, 20 de setembro de 2016 19:04:07 PDT Filippo Cucchetto wrote: >> Really? >> Shouldn't be better to just announce a proposal on the mailing list >> and then shift the discussion and feedbacks >> on the codereview? > > It may come as a shock to you, but the Gerrit user interface is horrible. > Reviewing discussions after they're done is very difficult, since there's no way > to dump inline comments with the 5-year-old interface we're using (the one > Gerrit added some time 3 or 4 years ago can do it). Joining a discussion in > progress is very difficult. > > Email is much easier. > which 5-year-old feature are we missing? --comments? $ ssh codereview.qt-project.org gerrit query 171459 --patch-sets --comments --format JSON | python -c $'import json, sys; l=sys.stdin.readline();j=json.loads(l)\nfor i in j["patchSets"]:\n\tif "comments" in i: print i["comments"]' this shows both inline comments in https://codereview.qt-project.org/#/c/171459/1/src/plugins/platforms/vnc/qvnc.cpp -- Sergio Ahumada sahumada at texla.cl From thiago.macieira at intel.com Tue Sep 20 23:17:58 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 20 Sep 2016 14:17:58 -0700 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <0900a02f-3743-4ff3-e267-e7777f150df1@texla.cl> References: <4467854.jDW3d3qIxX@tjmaciei-mobl1> <0900a02f-3743-4ff3-e267-e7777f150df1@texla.cl> Message-ID: <2303052.RKrebIo0th@tjmaciei-mobl1> On terça-feira, 20 de setembro de 2016 22:30:56 PDT Sergio Ahumada wrote: > which 5-year-old feature are we missing? The new UI. I want to see all comment, in all files, from all reviews, along with the review message, in one page. The new UI also has the ability to comment on multiple lines or sections of a line. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Sep 20 23:20:41 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 20 Sep 2016 14:20:41 -0700 Subject: [Development] Qt5 Bearer: broken PPP support In-Reply-To: <57E1929A.2050900@ilbers.de> References: <57E1929A.2050900@ilbers.de> Message-ID: <2626078.nGM65MBnMW@tjmaciei-mobl1> On terça-feira, 20 de setembro de 2016 22:48:42 PDT Alexander Smirnov wrote: > After debugging I figured out, that the problem is in commit: > > 043f5d3eb52587831f643bc52c95079c36d984c7 > > This commit allows to add to list: > > QList interfaces; > > interfaces with no address field (ifa_addr == NULL). > > Then, I've checked the output from 'getifaddrs()' syscall on my board, > and it returns 2! instances of ppp0: > > - one with AF_INET family > - one with ifa_addr == NULL [cut] > So, is it a bug? :-) Probably. Can you give me a full dump of what getifaddrs gave you along with ip -d link show dev ppp0 ip -d addr show dev ppp0 I'll fix it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Wed Sep 21 03:56:31 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 21 Sep 2016 03:56:31 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <1970306.GPDMVAqAdm@maurice> <10062324.xAOng0RbG1@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > And I will reject any patch that adds more complexity in qFuzzyCompare for > a 0.01% corner-case. Instead, we should document that it only works for > finite numbers far enough away from zero. If your number can be infinite > or NaN or zero, you have to find something else. This is just ridiculous, the code would be fixing a clear bug, and avoid having to very dangerously change the behavior of QVariant. Kevin Kofler From thiago.macieira at intel.com Wed Sep 21 06:15:09 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 20 Sep 2016 21:15:09 -0700 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <10062324.xAOng0RbG1@tjmaciei-mobl1> Message-ID: <4935523.60M5YKmvQ3@tjmaciei-mobl1> On quarta-feira, 21 de setembro de 2016 03:56:31 PDT Kevin Kofler wrote: > Thiago Macieira wrote: > > And I will reject any patch that adds more complexity in qFuzzyCompare for > > a 0.01% corner-case. Instead, we should document that it only works for > > finite numbers far enough away from zero. If your number can be infinite > > or NaN or zero, you have to find something else. > > This is just ridiculous, the code would be fixing a clear bug, and avoid > having to very dangerously change the behavior of QVariant. The clear bug is in QVariant and my original patch fixed qvariant.cpp numericCompare function. It's ok to call fpclassify() there, since QVariant comparison is not expected to be really fast. Besides, it's out-of-line code. However, I will oppose adding fpclassify() or isinf() to qFuzzyCompare. That function has existed for 10 years (or more) and this is this is the first we ever discuss it having a problem. The bug report isn't even about qFuzzyCompare, so as far as I know, no user has ever complained about it not working for infinities. I do remember a discussion some 8 or 9 years ago about using qFuzzyCompare to compare to zero. That's why qFuzzyIsNull exists. Which also means that QVariant comparisons to exact-zero or when the numbers are close to zero aren't fuzzy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mathias at taschenorakel.de Wed Sep 21 08:01:22 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Wed, 21 Sep 2016 08:01:22 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <1572252.L1a78adV0X@maurice> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <2023960.ebE3zJ8313@maurice> <1572252.L1a78adV0X@maurice> Message-ID: Am 20.09.2016 um 12:44 schrieb Olivier Goffart: > On Dienstag, 20. September 2016 12:21:11 CEST Mathias Hasselmann wrote: >> Am 19.09.2016 um 23:27 schrieb Olivier Goffart: >>> We really cannot have a qHash for QVariant anyway, because that would >>> imply >>> that ALL QVariant can be hashed, and compared. Which is not the case. Most >>> custom types don't even register comparator function. >> >> Which actually is quite a serious issue, as we do a simply memcmp() on >> such custom types, which simply won't work if your custom data structure >> contains uninitialized memory from alignment padding. > > We don't do that. We just return false in that case. Valgrind is telling a different story. It blames uninitialized memory access via memcpy() when comparing custom types without registered compare operator. Those types are gadgets, maybe that's making the difference. As much as I'd like to debug this code now to prove me right, I sadly have deadlines to meet this week. So I have to behave myself to not dig up the code right now. Maybe later. Or someone else. >> It is easy to forget registering comparator functions and currently Qt >> doesn't help in debugging such issues. So I wonder if QVariant should >> forbid comparison of custom types without having a comparator function >> registered. > > That's a source incompatible change. No, it's not. It's changing undefined behavior into defined behavior. Ciao, Mathias From olivier at woboq.com Wed Sep 21 08:57:01 2016 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 21 Sep 2016 08:57:01 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <1572252.L1a78adV0X@maurice> Message-ID: <2089649.Ciur4RRXTq@maurice> On Mittwoch, 21. September 2016 08:01:22 CEST Mathias Hasselmann wrote: > Am 20.09.2016 um 12:44 schrieb Olivier Goffart: > > On Dienstag, 20. September 2016 12:21:11 CEST Mathias Hasselmann wrote: > >> Am 19.09.2016 um 23:27 schrieb Olivier Goffart: > >>> We really cannot have a qHash for QVariant anyway, because that would > >>> imply > >>> that ALL QVariant can be hashed, and compared. Which is not the case. > >>> Most > >>> custom types don't even register comparator function. > >> > >> Which actually is quite a serious issue, as we do a simply memcmp() on > >> such custom types, which simply won't work if your custom data structure > >> contains uninitialized memory from alignment padding. > > > > We don't do that. We just return false in that case. > > Valgrind is telling a different story. It blames uninitialized memory > access via memcpy() when comparing custom types without registered > compare operator. Those types are gadgets, maybe that's making the > difference. > > As much as I'd like to debug this code now to prove me right, I sadly > have deadlines to meet this week. So I have to behave myself to not dig > up the code right now. Maybe later. Or someone else. Turns out you are right. If there is no registered comparison function, we do a memcmp in 'customCompare' in qvariant.cpp: https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qvariant.cpp.html#1079 That is indeed an undefined behavior! > > >> It is easy to forget registering comparator functions and currently Qt > >> doesn't help in debugging such issues. So I wonder if QVariant should > >> forbid comparison of custom types without having a comparator function > >> registered. > > > > That's a source incompatible change. > > No, it's not. It's changing undefined behavior into defined behavior. But in many case, we want to put something in a QVariant, and we never compare this variant. Forbidding types that do not have an operator== to be in a QVariant might be to strict. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From asmirnov at ilbers.de Wed Sep 21 09:11:00 2016 From: asmirnov at ilbers.de (Alexander Smirnov) Date: Wed, 21 Sep 2016 10:11:00 +0300 Subject: [Development] Qt5 Bearer: broken PPP support In-Reply-To: <2626078.nGM65MBnMW@tjmaciei-mobl1> References: <57E1929A.2050900@ilbers.de> <2626078.nGM65MBnMW@tjmaciei-mobl1> Message-ID: <57E23284.404@ilbers.de> Hi Thiago, > On terça-feira, 20 de setembro de 2016 22:48:42 PDT Alexander Smirnov wrote: >> After debugging I figured out, that the problem is in commit: >> >> 043f5d3eb52587831f643bc52c95079c36d984c7 >> >> This commit allows to add to list: >> >> QList interfaces; >> >> interfaces with no address field (ifa_addr == NULL). >> >> Then, I've checked the output from 'getifaddrs()' syscall on my board, >> and it returns 2! instances of ppp0: >> >> - one with AF_INET family >> - one with ifa_addr == NULL > [cut] >> So, is it a bug? :-) > > Probably. Can you give me a full dump of what getifaddrs gave you along with > > ip -d link show dev ppp0 > ip -d addr show dev ppp0 > So, I've attached the following: [ifconfig.log] - output from 'ifconfig -a' [getifaddrs.c] - test app to show getifaddrs() output, derived from man page, but fixed to not to skip null addresses [getifaddrs.log] - output from test app [ip.log] - output from ip command as you requested NOTE: I've also observed the same behavior for tun devices. ppp0 interface is created by typical Linux pppd daemon. tun2 interface is created by openvpn. > I'll fix it. > Please let me know, if you need additional information. -- With best regards, Alexander Smirnov ilbers GmbH Baierbrunner Str. 28c D-81379 München +49 (89) 122 67 24-0 http://ilbers.de/ Commercial register Munich, HRB 214197 General manager: Baurzhan Ismagulov -------------- next part -------------- #include #include #include #include #include #include #include int main(int argc, char** argv) { struct ifaddrs *ifaddr, *ifa; int family, s; char host[NI_MAXHOST]; if (getifaddrs(&ifaddr) == -1) { perror("getifaddrs"); exit(EXIT_FAILURE); } /* Walk through linked list, maintaining head pointer so we * can free list later */ for (ifa = ifaddr; ifa != NULL; ifa = ifa->ifa_next) { if (ifa->ifa_addr == NULL) { printf("%s \taddress: NULL\n", ifa->ifa_name); continue; } family = ifa->ifa_addr->sa_family; /* Display interface name and family (including symbolic * form of the latter for the common families) */ printf("%s \tfamily: %d%s\n", ifa->ifa_name, family, (family == AF_PACKET) ? " (AF_PACKET)" : (family == AF_INET) ? " (AF_INET)" : (family == AF_INET6) ? " (AF_INET6)" : ""); /* For an AF_INET* interface address, display the address */ if (family == AF_INET || family == AF_INET6) { s = getnameinfo(ifa->ifa_addr, (family == AF_INET) ? sizeof(struct sockaddr_in) : sizeof(struct sockaddr_in6), host, NI_MAXHOST, NULL, 0, NI_NUMERICHOST); if (s != 0) { printf("getnameinfo() failed: %s\n", gai_strerror(s)); exit(EXIT_FAILURE); } printf("\taddress: <%s>\n", host); } } freeifaddrs(ifaddr); exit(EXIT_SUCCESS); } -------------- next part -------------- # getifaddrs lo family: 17 (AF_PACKET) can0 address: NULL eth0 family: 17 (AF_PACKET) wlan0 family: 17 (AF_PACKET) sit0 family: 17 (AF_PACKET) ppp0 address: NULL tun2 address: NULL lo family: 2 (AF_INET) address: <127.0.0.1> eth0 family: 2 (AF_INET) address: <192.168.178.110> ppp0 family: 2 (AF_INET) address: <10.142.173.66> tun2 family: 2 (AF_INET) address: <10.0.0.1> lo family: 10 (AF_INET6) address: <::1> eth0 family: 10 (AF_INET6) address: -------------- next part -------------- # ifconfig -a can0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 NOARP MTU:16 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:30 eth0 Link encap:Ethernet HWaddr 00:01:C0:19:6C:24 inet addr:192.168.178.110 Bcast:192.168.178.255 Mask:255.255.255.0 inet6 addr: fe80::201:c0ff:fe19:6c24%1996412624/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:361871 errors:9529 dropped:60 overruns:9529 frame:9529 TX packets:169960 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:511238273 (487.5 MiB) TX bytes:11817634 (11.2 MiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1%1996412624/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:512 (512.0 B) TX bytes:512 (512.0 B) ppp0 Link encap:Point-to-Point Protocol inet addr:10.142.173.66 P-t-P:10.142.173.66 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:58 (58.0 B) TX bytes:98 (98.0 B) sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) tun2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) wlan0 Link encap:Ethernet HWaddr 04:F0:21:13:FD:7C BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:15 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:2489 (2.4 KiB) -------------- next part -------------- ************ *** ppp0 *** ************ # ip -d link show dev ppp0 10: ppp0: mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 3 link/ppp promiscuity 0 addrgenmode eui64 # ip -d addr show dev ppp0 10: ppp0: mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 3 link/ppp promiscuity 0 inet 10.142.173.66/32 scope global ppp0 valid_lft forever preferred_lft forever ************ *** tun2 *** ************ # ip -d link show dev tun2 11: tun2: mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 100 link/none promiscuity 0 tun addrgenmode eui64 # ip -d addr show dev tun2 11: tun2: mtu 1500 qdisc noqueue state DOWN group default qlen 100 link/none promiscuity 0 tun inet 10.0.0.1/24 scope global tun2 valid_lft forever preferred_lft forever From mathias at taschenorakel.de Wed Sep 21 09:23:35 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Wed, 21 Sep 2016 09:23:35 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <2089649.Ciur4RRXTq@maurice> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <1572252.L1a78adV0X@maurice> <2089649.Ciur4RRXTq@maurice> Message-ID: <3c6d6ee4-3f58-d63c-9228-d3d5c76b89b4@taschenorakel.de> Am 21.09.2016 um 08:57 schrieb Olivier Goffart: > On Mittwoch, 21. September 2016 08:01:22 CEST Mathias Hasselmann wrote: >> As much as I'd like to debug this code now to prove me right, I sadly >> have deadlines to meet this week. So I have to behave myself to not dig >> up the code right now. Maybe later. Or someone else. > > Turns out you are right. If there is no registered comparison function, we do > a memcmp in 'customCompare' in qvariant.cpp: > https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qvariant.cpp.html#1079 > > That is indeed an undefined behavior! Cool. Or rather not. Anyway: Thank you for looking this up! >>>> It is easy to forget registering comparator functions and currently Qt >>>> doesn't help in debugging such issues. So I wonder if QVariant should >>>> forbid comparison of custom types without having a comparator function >>>> registered. >>> >>> That's a source incompatible change. >> >> No, it's not. It's changing undefined behavior into defined behavior. > > But in many case, we want to put something in a QVariant, and we never compare > this variant. > Forbidding types that do not have an operator== to be in a QVariant might be > to strict. I fear balance has changed dramatically since we switched from 32 bit to 64 bit. In the old 32 bit days our structs tended to be densely packed with our enums and ints. Many structs were well defined as they contained no padding wholes. Memcmp was working. World was good. These days with compilers often defaulting to sizeof(int) == 4 while using a memory alignment of 8 we usually end up with horrible inefficient, very sparse structs where often half of the bytes are undefined. Actually the compiler gurus' decision to use stay with 32 bits for ints feels slightly stupid now that I think about it: No improvement in memory efficiency, but lots of undefined behavior. Maybe some clever use of type traits can tell us if your structs contain alignment wholes? Ciao, Mathias From marc.mutz at kdab.com Wed Sep 21 09:52:44 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 21 Sep 2016 09:52:44 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <3c6d6ee4-3f58-d63c-9228-d3d5c76b89b4@taschenorakel.de> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <2089649.Ciur4RRXTq@maurice> <3c6d6ee4-3f58-d63c-9228-d3d5c76b89b4@taschenorakel.de> Message-ID: <201609210952.44783.marc.mutz@kdab.com> On Wednesday 21 September 2016 09:23:35 Mathias Hasselmann wrote: > Maybe some clever use of type traits can tell us if your structs contain > alignment wholes? -Werror=padded :) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From probono at puredarwin.org Wed Sep 21 10:11:01 2016 From: probono at puredarwin.org (probono) Date: Wed, 21 Sep 2016 10:11:01 +0200 Subject: [Development] linuxdeployqt In-Reply-To: <68AE4335-1F84-44B7-9BC5-4A5AFCF5A322@qt.io> References: <68AE4335-1F84-44B7-9BC5-4A5AFCF5A322@qt.io> Message-ID: 2016-09-19 16:45 GMT+02:00 Louai Al-Khanji : > From a quick look it seems to be mostly well written. I do wonder whether it might be better to use a tool other than ldd to find the library dependencies. objdump -p provides the same information, and also works for cross-compiles. ldd not only provides the name of the libraries to be loaded, but also the paths to the locations where they are loaded from. How would I get this information without using ldd? From jani.heikkinen at qt.io Wed Sep 21 11:04:25 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 21 Sep 2016 09:04:25 +0000 Subject: [Development] Qt 5.6.2 packages for testing Message-ID: Hi all, We have final Qt 5.6.2 packages for your testing available: Windows:http://download.qt.io/snapshots/qt/5.6/5.6.2/569/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.2/503/ Mac:http://download.qt.io/snapshots/qt/5.6/5.6.2/436/ src: http://download.qt.io/snapshots/qt/5.6/5.6.2/latest_src/ Please check the packages to be sure those are still Ok. We are planning to release these packages as Qt 5.6.2 at the beginning of next week so please inform me immediately if there is something badly broken. Packages are based on https://codereview.qt-project.org/#/c/170236/ Please update Qt 5.6.2 known issues page as well: https://wiki.qt.io/Qt_5.6.2_Known_Issues br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From konrad at silmor.de Wed Sep 21 11:06:59 2016 From: konrad at silmor.de (Konrad Rosenbaum) Date: Wed, 21 Sep 2016 11:06:59 +0200 Subject: [Development] linuxdeployqt In-Reply-To: References: <68AE4335-1F84-44B7-9BC5-4A5AFCF5A322@qt.io> Message-ID: Hi, On Wed, September 21, 2016 10:11, probono wrote: > 2016-09-19 16:45 GMT+02:00 Louai Al-Khanji : >> From a quick look it seems to be mostly well written. I do wonder >> whether it might be better to use a tool other than ldd to find the >> library dependencies. objdump -p provides the same information, and also >> works for cross-compiles. > > ldd not only provides the name of the libraries to be loaded, but also > the paths to the locations where they are loaded from. How would I get > this information without using ldd? By implementing the same algorithm? It's pretty simple actually: * go through $LD_LIBRARY_PATH * go through RPath * go through /etc/ld.so.config (I think there are 1 or 2 more, look it up, it's documented) RPath may be a bit tricky: normally Qt compiles it's lib path into RPath, but with a deploy script you do not want that RPath anymore, instead you'd want to change it to $ORIGIN (literally, not the value of a variable). So you may have to check the location of linuxdeployqt and derive the original lib path from there. For each path that is being checked: find a file that matches the name, check that it has the correct ELF platform (x86, amd64, x32, arm, etc.) - if it matches, take it and add its dependencies to the list. Ldd has several downsides: * it may not be available on some platforms (e.g. some embedded devices) * its output format may change without warning * it cannot check programs for platforms that do not run on your host (anything that is cross-compiled, or if the binary loader is missing or broken) * it is unsafe (although we'll assume that you will not compile and deploy a program that sabotages your own System) Konrad From Friedemann.Kleint at qt.io Wed Sep 21 11:34:02 2016 From: Friedemann.Kleint at qt.io (Friedemann Kleint) Date: Wed, 21 Sep 2016 11:34:02 +0200 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: Message-ID: <57E2540A.2040608@qt.io> Hi, technically speaking: is using the .rst format set in stone? I find this difficult to handle; one needs a local web server to view it AFAIK. .md comes to mind as alternative? Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH From mathias at taschenorakel.de Wed Sep 21 11:42:41 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Wed, 21 Sep 2016 11:42:41 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <201609210952.44783.marc.mutz@kdab.com> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <2089649.Ciur4RRXTq@maurice> <3c6d6ee4-3f58-d63c-9228-d3d5c76b89b4@taschenorakel.de> <201609210952.44783.marc.mutz@kdab.com> Message-ID: Am 21.09.2016 um 09:52 schrieb Marc Mutz: > On Wednesday 21 September 2016 09:23:35 Mathias Hasselmann wrote: >> Maybe some clever use of type traits can tell us if your structs contain >> alignment wholes? > > -Werror=padded :) > Yes, but how is it supposed to help? Let me show a real world example: struct Sensor { enum Config { NotInitialized, PullUp, PullDown, Analog }; Config config; QVariant value; //[1] } No matter what order I use for config and value, the compiler will pad and -Wpadded will complain. How am I supposed to fix this? This solutions that come to my mind all are ugly, but most likely I am just stupid. [1] Yes, the use of QVariant in this case is questionable, but that's not the point. Ciao, Mathias From edward.welbourne at qt.io Wed Sep 21 11:53:48 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 21 Sep 2016 09:53:48 +0000 Subject: [Development] Qt 5.8 API review (vs 5.7.0) In-Reply-To: References: , , , Message-ID: On 2016 September 9 I announced: > It's that time in the release cycle again - API review time. > If you can catch a moment when Gerrit isn't hiding, please > take a look at any modules you care for: > https://codereview.qt-project.org/170634 -- qtbase > https://codereview.qt-project.org/170635 -- qtdeclarative > https://codereview.qt-project.org/170636 -- qtactiveqt > https://codereview.qt-project.org/170637 -- qtmultimedia > https://codereview.qt-project.org/170638 -- qttools > https://codereview.qt-project.org/170639 -- qtlocation > https://codereview.qt-project.org/170640 -- qtconnectivity > https://codereview.qt-project.org/170641 -- qtwayland > https://codereview.qt-project.org/170642 -- qt3d > https://codereview.qt-project.org/170643 -- qtserialbus > https://codereview.qt-project.org/170644 -- qtserialport > https://codereview.qt-project.org/170645 -- qtandroidextras > https://codereview.qt-project.org/170646 -- qtwebsockets > https://codereview.qt-project.org/170647 -- qtwebengine > https://codereview.qt-project.org/170648 -- qtcanvas3d > https://codereview.qt-project.org/170649 -- qtcharts > https://codereview.qt-project.org/170650 -- qtdatavis3d > https://codereview.qt-project.org/170651 -- qtvirtualkeyboard > https://codereview.qt-project.org/170652 -- qtscxml I've today done an update to pick up fixes to issues found there, plus on-going changes to 5.8; and the review scripts are a bit smarter now, so have refined some details. In particular, they now find (possibly recent) changes also in: https://codereview.qt-project.org/171662 -- qtquickcontrols2 ... and I seem to need to kick a few where the update landed in a new review; somehow I failed at amending :-( In any case, if you grumbled about one of these reviews, you should have mail about its update (if it got one - or you'll get one shortly when I fix the failed amends). Eddy. From marc.mutz at kdab.com Wed Sep 21 12:00:15 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 21 Sep 2016 12:00:15 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <201609210952.44783.marc.mutz@kdab.com> Message-ID: <201609211200.16107.marc.mutz@kdab.com> On Wednesday 21 September 2016 11:42:41 Mathias Hasselmann wrote: > Am 21.09.2016 um 09:52 schrieb Marc Mutz: > > On Wednesday 21 September 2016 09:23:35 Mathias Hasselmann wrote: > >> Maybe some clever use of type traits can tell us if your structs contain > >> alignment wholes? > > > > -Werror=padded :) > > Yes, but how is it supposed to help? Let me show a real world example: > > struct Sensor > { > enum Config { NotInitialized, PullUp, PullDown, Analog }; > > Config config; > QVariant value; //[1] > } > > No matter what order I use for config and value, the compiler will pad > and -Wpadded will complain. How am I supposed to fix this? This > solutions that come to my mind all are ugly, but most likely I am just > stupid. Tabs? Seriously? :) struct Sensor { enum Config { NotInitialized, PullUp, PullDown, Analog }; Config config; char padding[alignof(QVariant) - sizeof(Config)]; QVariant value; //[1] } and pray for alignof(QVariant) - sizeof(Config) != 0. I wasn't serious about -Wpadded, but incidentally, my example shows that type traits also won't help. We have a handful of classes in Qt which have a 'reserved' field that doesn't get initialized (so it better should be named 'unusable'). A type trait cannot tell if a field called 'padding', 'reserved', 'unused' or 'unusable' is meant to be part of equality or not. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From andrew.knight at intopalo.com Wed Sep 21 12:04:34 2016 From: andrew.knight at intopalo.com (Andrew Knight) Date: Wed, 21 Sep 2016 13:04:34 +0300 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <57E2540A.2040608@qt.io> References: <57E2540A.2040608@qt.io> Message-ID: <946cd0f5-8ff8-c319-4e6a-aaf42522a9cc@intopalo.com> Hi, On 09/21/16 12:34, Friedemann Kleint wrote: > Hi, > > technically speaking: is using the .rst format set in stone? I find > this difficult to handle; one needs a local web server to view it > AFAIK. .md comes to mind as alternative? > We discussed this at QtCon and settled on ReStructured Text because it results in a cleaner plaintext document (i.e. more document-like, less markup-like) than markdown. It's also the format PIP uses, but note that it doesn't necessarily matter: each QUIP can declare its MIME type in the header. Anyway, I don't think you need a web server to view the formatted RST result. Docutils has examples on how to convert to HTML using Python: http://docutils.sourceforge.net/docs/user/tools.html#rst2html-py -- Andrew From abbapoh at gmail.com Wed Sep 21 16:39:22 2016 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Wed, 21 Sep 2016 17:39:22 +0300 Subject: [Development] Notes on "Qt Build Systems" @ QtCon 2016 In-Reply-To: References: <8c7fbbe6-045a-777c-b26b-b4c9bd1e65cd@intopalo.com> <1611603.8B8jhCL7eK@agathebauer> <769af97b-3ea0-5ae2-8b30-44f5dda5dd65@vikingsoft.eu> <3839841474399122@web3j.yandex.ru> Message-ID: I was using CMake for several years (and still forced to use it now), however i moved all my projects to QBS for one reason - CMake is too complex. It has great documentation, but it can't be used without it; on the contrary, qbs is very intuitive. I don't have to remember tons of variables like CMAKE_CURRENT_SOURCE_DIR, CMAKE_SOURCE_DIR (there is also PROJECT_SOURCE_DIR!) with qbs, property names are simple. Every complex task lead to tons of code with CMake, it's hard to maintain those scripts. I don't want to do that complex job maintaining buildsystem, i want to write code. Yes, if a project will use both CMake and QBS build systems, all the variables and logic will be almost the same; however qbs is much clearer and easier. I tried to create a simple project with typical usecases - libraries, tests, app bundles that uses both CMake and QBS, but i didn't have time to finish the cmake part https://github.com/ABBAPOH/qbsfish (not sure if it even works). For now, cmake scripts looks much easier, but adding new features is rather painful - i have to use the docs all the time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Sep 21 16:51:26 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 21 Sep 2016 07:51:26 -0700 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <57E2540A.2040608@qt.io> References: <57E2540A.2040608@qt.io> Message-ID: <5236806.ZcnjVzEqRX@tjmaciei-mobl1> On quarta-feira, 21 de setembro de 2016 11:34:02 PDT Friedemann Kleint wrote: > Hi, > > technically speaking: is using the .rst format set in stone? I find this > difficult to handle; one needs a local web server to view it AFAIK. .md > comes to mind as alternative? How is that different from .md? Don't you need a tool that converts it from the source format to HTML? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed Sep 21 16:54:49 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 21 Sep 2016 17:54:49 +0300 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: <57E2540A.2040608@qt.io> References: <57E2540A.2040608@qt.io> Message-ID: <847381474469689@web37m.yandex.ru> 21.09.2016, 12:34, "Friedemann Kleint" : > Hi, > > technically speaking: is using the .rst format set in stone? I find this > difficult to handle; one needs a local web server to view it AFAIK. .md > comes to mind as alternative? Are you implying that you need local web server to view HTML? :) > > Regards, > Friedemann > > -- > Friedemann Kleint > The Qt Company GmbH > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Wed Sep 21 16:57:42 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 21 Sep 2016 07:57:42 -0700 Subject: [Development] Qt5 Bearer: broken PPP support In-Reply-To: <57E23284.404@ilbers.de> References: <57E1929A.2050900@ilbers.de> <2626078.nGM65MBnMW@tjmaciei-mobl1> <57E23284.404@ilbers.de> Message-ID: <1594545.PD8B3MDiQv@tjmaciei-mobl1> On quarta-feira, 21 de setembro de 2016 10:11:00 PDT Alexander Smirnov wrote: > ppp0 interface is created by typical Linux pppd daemon. > tun2 interface is created by openvpn. > > > I'll fix it. > > Please let me know, if you need additional information. I thought I'd fixed the tun case, as I do have an openvpn VPN... Anyway, that means it's that much easier for me to reproduce and fix. I've got this with tst_qnetworkinterface dump, for an openconnect VPN: Interface: "vpn0" index: 15 flags: Up,Running,PointToPoint,Multicast type: QNetworkInterface::InterfaceType(Virtual) hw address: 00:00:00:00:00:00 address 0: 10.255.92.115/19 (255.255.224.0) broadcast 10.255.95.255 Interface: "vpn0" index: 15 flags: Up,Running,PointToPoint,Multicast type: QNetworkInterface::InterfaceType(Virtual) hw address: 00:00:00:00:00:00 I'll fix it when I'm back home tonight. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Sep 21 17:00:25 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 21 Sep 2016 08:00:25 -0700 Subject: [Development] linuxdeployqt In-Reply-To: References: <68AE4335-1F84-44B7-9BC5-4A5AFCF5A322@qt.io> Message-ID: <10500712.kXK9ADZF4M@tjmaciei-mobl1> On quarta-feira, 21 de setembro de 2016 10:11:01 PDT probono wrote: > ldd not only provides the name of the libraries to be loaded, but also > the paths to the locations where they are loaded from. How would I get > this information without using ldd? Manually. First, use the environment variable $LD_LIBRARY_PATH. The default search path is known to qmake (variable QMAKE_DEFAULT_LIBDIRS) and you can then search the paths from /etc/ld.so.conf & /etc/ld.so.conf.d/*. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Sep 21 17:02:32 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 21 Sep 2016 08:02:32 -0700 Subject: [Development] linuxdeployqt In-Reply-To: References: Message-ID: <1684039.doeB23Vrcg@tjmaciei-mobl1> On quarta-feira, 21 de setembro de 2016 11:06:59 PDT Konrad Rosenbaum wrote: > RPath may be a bit tricky: normally Qt compiles it's lib path into RPath, > but with a deploy script you do not want that RPath anymore, instead you'd > want to change it to $ORIGIN (literally, not the value of a variable). Don't change. If you want $ORIGIN, you tell the linker you want it. Also, RPATH is tricky, but for another reason: - If DT_RUNPATH is present, check $LD_LIBRARY_PATH first and ignore DT_RPATH - if only DT_RPATH is present, check it before $LD_LIBRARY_PATH -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From fromqt at tungware.se Wed Sep 21 17:49:39 2016 From: fromqt at tungware.se (Henry Skoglund) Date: Wed, 21 Sep 2016 17:49:39 +0200 Subject: [Development] linuxdeployqt In-Reply-To: <1684039.doeB23Vrcg@tjmaciei-mobl1> References: <1684039.doeB23Vrcg@tjmaciei-mobl1> Message-ID: <57162a7a-e53b-a207-18a6-4b4f3a4aa9d9@tungware.se> On 2016-09-21 17:02, Thiago Macieira wrote: > On quarta-feira, 21 de setembro de 2016 11:06:59 PDT Konrad Rosenbaum wrote: >> RPath may be a bit tricky: normally Qt compiles it's lib path into RPath, >> but with a deploy script you do not want that RPath anymore, instead you'd >> want to change it to $ORIGIN (literally, not the value of a variable). > > Don't change. If you want $ORIGIN, you tell the linker you want it. > > Also, RPATH is tricky, but for another reason: > > - If DT_RUNPATH is present, check $LD_LIBRARY_PATH first and ignore DT_RPATH > - if only DT_RPATH is present, check it before $LD_LIBRARY_PATH > About paths, if we want linuxdeployqt to harmonize with windeployqt's behavior: since last year windeployqt unpatches (i.e. neuters) Qt's installation path in Qt5Core.dll, so that for example my Qt5Core.dll is patched from "qt_prfxpath=C:\Qt\5.7\msvc2013\" to "qt_prfxpath=.". This severes any pathological connections my app would have with my Qt installation (and shuts a small but possible backdoor). (And, when I copy my app to a vanilla PC, I can either place the platforms subdirectory next to my .exe file, or I want to get fancy, copy the whole plugins tree and place it next my .exe file. Either works fine for loading qwindows.dll.) So perhaps linuxdeployt could do the same, i.e. neuter the path to my Qt installation (e.g. change "prfxpath=/home/henry/Qt/5.7/gcc_64" to "prfxpath=." in libQt5Core.so.5.7.0? In theory you could apply the same reasoning to RPATH, why let Qt's installation path remain artifacted in the .elf file? Perhaps $ORIGIN is a nicer default. (windeployqt does not do this step, as on Windows $ORIGIN is the "standard" anyway). Rgrds Henry From oswald.buddenhagen at qt.io Wed Sep 21 19:24:34 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 21 Sep 2016 19:24:34 +0200 Subject: [Development] linuxdeployqt In-Reply-To: <10500712.kXK9ADZF4M@tjmaciei-mobl1> References: <68AE4335-1F84-44B7-9BC5-4A5AFCF5A322@qt.io> <10500712.kXK9ADZF4M@tjmaciei-mobl1> Message-ID: <20160921172434.GD10434@nubble> On Wed, Sep 21, 2016 at 08:00:25AM -0700, Thiago Macieira wrote: > On quarta-feira, 21 de setembro de 2016 10:11:01 PDT probono wrote: > > ldd not only provides the name of the libraries to be loaded, but also > > the paths to the locations where they are loaded from. How would I get > > this information without using ldd? > > Manually. > > First, use the environment variable $LD_LIBRARY_PATH. > The default search path is known to qmake (variable > QMAKE_DEFAULT_LIBDIRS) > that's the static search path, i.e. just $LIBRARY_PATH. and it's actually what you want. > and you can then search the > paths from /etc/ld.so.conf & /etc/ld.so.conf.d/*. > that will suffer from x-build issues again. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed Sep 21 19:40:45 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 21 Sep 2016 10:40:45 -0700 Subject: [Development] linuxdeployqt In-Reply-To: <20160921172434.GD10434@nubble> References: <10500712.kXK9ADZF4M@tjmaciei-mobl1> <20160921172434.GD10434@nubble> Message-ID: <8995682.I8JhEBzP8r@tjmaciei-mobl1> On quarta-feira, 21 de setembro de 2016 19:24:34 PDT Oswald Buddenhagen wrote: > > and you can then search the > > paths from /etc/ld.so.conf & /etc/ld.so.conf.d/*. > > that will suffer from x-build issues again. Hmm... if we're cross-compiling, we should have access to the path to the sysroot, so we can find ld.so.conf there. $ ls /opt/poky/sysroots/*/etc/ld.so.conf /opt/poky/sysroots/aarch64-poky-linux/etc/ld.so.conf /opt/poky/sysroots/armv7a-neon-poky-linux-gnueabi/etc/ld.so.conf /opt/poky/sysroots/mips32r2-poky-linux/etc/ld.so.conf /opt/poky/sysroots/mips64-poky-linux/etc/ld.so.conf /opt/poky/sysroots/ppc7400-poky-linux/etc/ld.so.conf /opt/poky/sysroots/ppce500v2-poky-linux-gnuspe/etc/ld.so.conf /opt/poky/sysroots/x86_64-pokysdk-linux/etc/ld.so.conf -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed Sep 21 21:09:05 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 21 Sep 2016 22:09:05 +0300 Subject: [Development] linuxdeployqt In-Reply-To: <8995682.I8JhEBzP8r@tjmaciei-mobl1> References: <10500712.kXK9ADZF4M@tjmaciei-mobl1> <20160921172434.GD10434@nubble> <8995682.I8JhEBzP8r@tjmaciei-mobl1> Message-ID: <1191801474484945@web30j.yandex.ru> 21.09.2016, 20:41, "Thiago Macieira" : > On quarta-feira, 21 de setembro de 2016 19:24:34 PDT Oswald Buddenhagen wrote: >>  > and you can then search the >>  > paths from /etc/ld.so.conf & /etc/ld.so.conf.d/*. >> >>  that will suffer from x-build issues again. > > Hmm... if we're cross-compiling, we should have access to the path to the > sysroot, so we can find ld.so.conf there. > > $ ls /opt/poky/sysroots/*/etc/ld.so.conf > /opt/poky/sysroots/aarch64-poky-linux/etc/ld.so.conf > /opt/poky/sysroots/armv7a-neon-poky-linux-gnueabi/etc/ld.so.conf > /opt/poky/sysroots/mips32r2-poky-linux/etc/ld.so.conf > /opt/poky/sysroots/mips64-poky-linux/etc/ld.so.conf > /opt/poky/sysroots/ppc7400-poky-linux/etc/ld.so.conf > /opt/poky/sysroots/ppce500v2-poky-linux-gnuspe/etc/ld.so.conf > /opt/poky/sysroots/x86_64-pokysdk-linux/etc/ld.so.conf Do these file have any content? I have a few fully working toolchains from 2 vendors at my hands, one has empty ld.so.conf, others don't have any > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From apoenitz at t-online.de Thu Sep 22 00:58:08 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 22 Sep 2016 00:58:08 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <2089649.Ciur4RRXTq@maurice> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <1572252.L1a78adV0X@maurice> <2089649.Ciur4RRXTq@maurice> Message-ID: <20160921225808.GC3442@klara.mpi.htwm.de> On Wed, Sep 21, 2016 at 08:57:01AM +0200, Olivier Goffart wrote: > > No, it's not. It's changing undefined behavior into defined > > behavior. > > But in many case, we want to put something in a QVariant, and we > never compare this variant. Forbidding types that do not have an > operator== to be in a QVariant might be to strict. Forbidding types without operator== in QVariants is not needed, not even if one wanted to use associative container with QVariants as keys. [Pseudocode] bool operator(QVariant(Foo) a, QVariant(Bar) b) { if Foo != Bar: return false if Foo has no operator==(): return true return (Foo)a == (Foo)b } establishes an equivalance relation by lumping all "uncomparable" objects into a single equivalency class. One might argue that considering all instances of classes without operator== as equal makes associative containers of them not exactly useful, but it is at least formally correct, defined behaviour and can be easily turned into correct, defined and useful behaviour by the user himself by providing some operator== for his types. This is certainly better than the current behaviour that is not exactly useful[1], formally incorrect, undefined and unfixable from the user side. Andre' [1] "Not exactly useful" e.g. as in "funny effects like the number of elements in an associative container depending on the insertion order": int main() { QVariant v1('a'), v2(QChar('a')), v3(QString("a")); QMap maps[] = { { {v1,1}, {v2,1}, {v3,1} }, { {v1,1}, {v3,1}, {v2,1} }, { {v2,1}, {v1,1}, {v3,1} }, { {v2,1}, {v3,1}, {v1,1} }, { {v3,1}, {v1,1}, {v2,1} }, { {v3,1}, {v2,1}, {v1,1} } }; for (auto h : maps) qDebug() << h.size(); } -> 2 2 1 1 2 2 From thiago.macieira at intel.com Thu Sep 22 03:16:53 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 21 Sep 2016 18:16:53 -0700 Subject: [Development] linuxdeployqt In-Reply-To: <1191801474484945@web30j.yandex.ru> References: <8995682.I8JhEBzP8r@tjmaciei-mobl1> <1191801474484945@web30j.yandex.ru> Message-ID: <5003281.iXuyFSScgY@tjmaciei-mobl1> On quarta-feira, 21 de setembro de 2016 22:09:05 PDT Konstantin Tokarev wrote: > > $ ls /opt/poky/sysroots/*/etc/ld.so.conf > > /opt/poky/sysroots/aarch64-poky-linux/etc/ld.so.conf > > /opt/poky/sysroots/armv7a-neon-poky-linux-gnueabi/etc/ld.so.conf > > /opt/poky/sysroots/mips32r2-poky-linux/etc/ld.so.conf > > /opt/poky/sysroots/mips64-poky-linux/etc/ld.so.conf > > /opt/poky/sysroots/ppc7400-poky-linux/etc/ld.so.conf > > /opt/poky/sysroots/ppce500v2-poky-linux-gnuspe/etc/ld.so.conf > > /opt/poky/sysroots/x86_64-pokysdk-linux/etc/ld.so.conf > > Do these file have any content? > > I have a few fully working toolchains from 2 vendors at my hands, one has > empty ld.so.conf, others don't have any And that's fine. Those files in my Poky sysroots are empty too. It just means that there are no additional directories to search, besides those reported by the compiler, which in turn were already detected by qmake & configure. Unfortunately, I don't have a cross-compilation built in my current laptop to prove it (it's only 5 months old). Unless we broke it with the new configure system. The commit by Ossi that fixed it is getting reverted in 5.8. See variable QMAKE_DEFAULT_LIBDIRS. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Sep 22 03:35:47 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 21 Sep 2016 18:35:47 -0700 Subject: [Development] linuxdeployqt In-Reply-To: <5003281.iXuyFSScgY@tjmaciei-mobl1> References: <1191801474484945@web30j.yandex.ru> <5003281.iXuyFSScgY@tjmaciei-mobl1> Message-ID: <19930738.pIa80xFUPY@tjmaciei-mobl1> On quarta-feira, 21 de setembro de 2016 18:16:53 PDT Thiago Macieira wrote: > Unless we broke it with the new configure system. The commit by Ossi that > fixed it is getting reverted in 5.8. Sorry, reverted in dev. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Sep 22 04:07:51 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 21 Sep 2016 19:07:51 -0700 Subject: [Development] Qt5 Bearer: broken PPP support In-Reply-To: <1594545.PD8B3MDiQv@tjmaciei-mobl1> References: <57E1929A.2050900@ilbers.de> <57E23284.404@ilbers.de> <1594545.PD8B3MDiQv@tjmaciei-mobl1> Message-ID: <2273430.0GNTtKXFGz@tjmaciei-mobl1> On quarta-feira, 21 de setembro de 2016 07:57:42 PDT Thiago Macieira wrote: > I'll fix it when I'm back home tonight. https://codereview.qt-project.org/171756 It was quite simple. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mathias at taschenorakel.de Thu Sep 22 06:02:43 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Thu, 22 Sep 2016 06:02:43 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <201609211200.16107.marc.mutz@kdab.com> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <201609210952.44783.marc.mutz@kdab.com> <201609211200.16107.marc.mutz@kdab.com> Message-ID: <3bd89003-694b-852b-5a1f-b150b8aa5232@taschenorakel.de> Am 21.09.2016 um 12:00 schrieb Marc Mutz: > On Wednesday 21 September 2016 11:42:41 Mathias Hasselmann wrote: >> No matter what order I use for config and value, the compiler will pad >> and -Wpadded will complain. How am I supposed to fix this? This >> solutions that come to my mind all are ugly, but most likely I am just >> stupid. > > Tabs? Seriously? :) E-mail clients and their horrible text editors. > > struct Sensor > { > enum Config { NotInitialized, PullUp, PullDown, Analog }; > > Config config; > char padding[alignof(QVariant) - sizeof(Config)]; > QVariant value; //[1] > } > > and pray for alignof(QVariant) - sizeof(Config) != 0. Yup, one of solutions I had in mind and rejected for expected that prayer remaining unheard while juggling with 32 and 64 bit code. > I wasn't serious about -Wpadded, but incidentally, my example shows that type > traits also won't help. We have a handful of classes in Qt which have a > 'reserved' field that doesn't get initialized (so it better should be named > 'unusable'). A type trait cannot tell if a field called 'padding', 'reserved', > 'unused' or 'unusable' is meant to be part of equality or not. Q_DECLARE_TYPEINFO(QBar, Q_PADDED_TYPE) // :D Ciao, Mathias From mathias at taschenorakel.de Thu Sep 22 06:04:58 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Thu, 22 Sep 2016 06:04:58 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <20160921225808.GC3442@klara.mpi.htwm.de> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <1572252.L1a78adV0X@maurice> <2089649.Ciur4RRXTq@maurice> <20160921225808.GC3442@klara.mpi.htwm.de> Message-ID: <25f020ab-90db-7b57-4e90-d3fe9e4bddd1@taschenorakel.de> Am 22.09.2016 um 00:58 schrieb André Pönitz: > On Wed, Sep 21, 2016 at 08:57:01AM +0200, Olivier Goffart wrote: >>> No, it's not. It's changing undefined behavior into defined >>> behavior. >> >> But in many case, we want to put something in a QVariant, and we >> never compare this variant. Forbidding types that do not have an >> operator== to be in a QVariant might be to strict. > > Forbidding types without operator== in QVariants is not needed, > not even if one wanted to use associative container with > QVariants as keys. > > [Pseudocode] > > bool operator(QVariant(Foo) a, QVariant(Bar) b) > { > if Foo != Bar: > return false > if Foo has no operator==(): > return true > return (Foo)a == (Foo)b > } > > establishes an equivalance relation by lumping all "uncomparable" > objects into a single equivalency class. I rather was considering to return false. But indeed. Forcing all that types into a single equivalency class feels that unnatural, that users should notice that issue much quicker, than if we'd return false. Would that be sufficient to warn Qt users, or would we also have to print a warning? Ciao, Mathias From thiago.macieira at intel.com Thu Sep 22 06:29:21 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 21 Sep 2016 21:29:21 -0700 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <201609211200.16107.marc.mutz@kdab.com> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <201609211200.16107.marc.mutz@kdab.com> Message-ID: <1492862.QZQhHDTdkh@tjmaciei-mobl1> On quarta-feira, 21 de setembro de 2016 12:00:15 PDT Marc Mutz wrote: > We have a handful of classes in Qt which have a > 'reserved' field that doesn't get initialized (so it better should be named > 'unusable') That depends on whether the copy constructors and destructor are inline or not. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From cavendish.qi at gmail.com Thu Sep 22 08:55:13 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Thu, 22 Sep 2016 08:55:13 +0200 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: References: <57CFB58D.2060200@qt.io> <2532835.dUoVZLnayI@tjmaciei-mobl1> <201609100921.58625.marc.mutz@kdab.com> Message-ID: On 12 September 2016 at 11:20, Edward Welbourne wrote: > Marc Mutz said: > > The obvious question is, then, why is only "the one person" doing merges? > > Allow more people to upload merges, and you will get the spreading you > desire. > > Several people can upload merges. > One person looks after integration in qt5 and all its sub-modules. > We can spread the load (indeed, I carried it for a few weeks while > Liang was on holiday), and I believe module owners can do their own > merges (which saves the integration team work), but the integration team > takes responsibility for ensuring merges are happening. > So it ends up being that Liang, as integrator, does most merges. > We have some/many modules are in not active mode, so the merges for them are normally based on the release schedules. That's one of the reason to have a merger. A heavy load for mergers and integrators is that the new CI, COIN, doesn't have reverse dependency check like old CI. Then if sth changed in qtbase or qtdeclarative, the merge and integration will trigger the issue. Then very often it's a bit difficult for us to analysis the root cause and find right persons to fix it. Perhaps we should set up a rule for deprecated sth, for example, 1. notify merger/integrator/others, or just add them into a list in a wiki/web page 2. the dev of the deprecated change should do a "git grep" in all qt project, and at least provide a fix for one of them, better to do all For merges, the maintainers of modules should take care. At least, qtquickcontrols2/qtwebengine are very well, it's also because developers there are working on different features in different branches, they care the merge themselves. For some other modules, like qt3d/qtmultimedia/qtwayland, the help from the maintainers and developers are also very good. But for qtbase, it's a totally different story, too many areas, so normally we(or I) can't say there is an active maintainer for the whole of qtbase. A regular merge for qtbase is needed, for example, weekly. And if we can't get response from devs very soon, who can help? Give the merge permission to everyone is obiviously not a solution. But it will help a lot if we have an active merger/integrator group, at least for review. Regards, Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Thu Sep 22 09:41:29 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 22 Sep 2016 09:41:29 +0200 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: References: <57CFB58D.2060200@qt.io> Message-ID: <201609220941.30522.marc.mutz@kdab.com> On Thursday 22 September 2016 08:55:13 Liang Qi wrote: > Give the merge permission to everyone is obiviously not a solution. Not everyone, but approvers, maybe? Merges need to be reviewed like any other commit, so why are they special, anyway? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From vladstelmahovsky at gmail.com Thu Sep 22 13:17:26 2016 From: vladstelmahovsky at gmail.com (Vlad Stelmahovsky) Date: Thu, 22 Sep 2016 13:17:26 +0200 Subject: [Development] dev doesnt builds Message-ID: Hi trying build dev branch and got this error all the time: Cannot read .....qt5/qtbase/src/corelib/qtcore-config.pri: No such file or directory Cannot read .....qt5/qtbase/src/gui/qtgui-config.pri: No such file or directory Project ERROR: Could not find feature system-zlib. Makefile:45: recipe for target 'sub-src-make_first' failed make[1]: *** [sub-src-make_first] Error 3 make[1]: Leaving directory '....../qt5/qtbase' Makefile:78: recipe for target 'module-qtbase-make_first' failed make: *** [module-qtbase-make_first] Error 2 is there a workaround for this? -- Best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From cavendish.qi at gmail.com Thu Sep 22 13:21:18 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Thu, 22 Sep 2016 13:21:18 +0200 Subject: [Development] dev doesnt builds In-Reply-To: References: Message-ID: On 22 September 2016 at 13:17, Vlad Stelmahovsky wrote: > Hi > > trying build dev branch and got this error all the time: > > > Cannot read .....qt5/qtbase/src/corelib/qtcore-config.pri: No such file > or directory > Cannot read .....qt5/qtbase/src/gui/qtgui-config.pri: No such file or > directory > Project ERROR: Could not find feature system-zlib. > Makefile:45: recipe for target 'sub-src-make_first' failed > make[1]: *** [sub-src-make_first] Error 3 > make[1]: Leaving directory '....../qt5/qtbase' > Makefile:78: recipe for target 'module-qtbase-make_first' failed > make: *** [module-qtbase-make_first] Error 2 > > > is there a workaround for this? > Perhaps missing a qt5 5.8->dev merge to include https://github.com/qt/qt5/commit/64cc947ded9999527197168f5d16f25a15638e58 . Anyway, the dev branch for all modules except qtbase are blocked by https://bugreports.qt.io/browse/QTBUG-56122 . Regards, Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Thu Sep 22 14:39:02 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 22 Sep 2016 12:39:02 +0000 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: <201609220941.30522.marc.mutz@kdab.com> References: <57CFB58D.2060200@qt.io> , <201609220941.30522.marc.mutz@kdab.com> Message-ID: On Thursday 22 September 2016 08:55:13 Liang Qi wrote: >> Give the merge permission to everyone is obiviously not a solution. Marc Mutz replied: > Not everyone, but approvers, maybe? Merges need to be reviewed like > any other commit, so why are they special, anyway? Do we at least give all maintainers merge powers in their modules ? Eddy. From alexander.blasche at qt.io Thu Sep 22 16:37:10 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Thu, 22 Sep 2016 14:37:10 +0000 Subject: [Development] dev doesnt builds In-Reply-To: References: Message-ID: Hi >Cannot read .....qt5/qtbase/src/corelib/qtcore-config.pri: No such file or directory >Cannot read .....qt5/qtbase/src/gui/qtgui-config.pri: No such file or directory >Project ERROR: Could not find feature system-zlib. >Makefile:45: recipe for target 'sub-src-make_first' failed >make[1]: *** [sub-src-make_first] Error 3 >make[1]: Leaving directory '....../qt5/qtbase' >Makefile:78: recipe for target 'module-qtbase-make_first' failed >make: *** [module-qtbase-make_first] Error 2 >is there a workaround for this? I had the same problem. Make sure that you have an up-to-date qt5.git checkout for dev as well. In combination with git clean the problem solved itself for me. -- Alex From asmirnov at ilbers.de Thu Sep 22 20:21:17 2016 From: asmirnov at ilbers.de (Alexander Smirnov) Date: Thu, 22 Sep 2016 21:21:17 +0300 Subject: [Development] Qt5 Bearer: broken PPP support In-Reply-To: <2273430.0GNTtKXFGz@tjmaciei-mobl1> References: <57E1929A.2050900@ilbers.de> <57E23284.404@ilbers.de> <1594545.PD8B3MDiQv@tjmaciei-mobl1> <2273430.0GNTtKXFGz@tjmaciei-mobl1> Message-ID: <57E4211D.2020208@ilbers.de> On 09/22/2016 05:07 AM, Thiago Macieira wrote: > On quarta-feira, 21 de setembro de 2016 07:57:42 PDT Thiago Macieira wrote: >> I'll fix it when I'm back home tonight. > > https://codereview.qt-project.org/171756 This works for me! > > It was quite simple. > -- With best regards, Alexander Smirnov ilbers GmbH Baierbrunner Str. 28c D-81379 München +49 (89) 122 67 24-0 http://ilbers.de/ Commercial register Munich, HRB 214197 General manager: Baurzhan Ismagulov From apoenitz at t-online.de Thu Sep 22 22:58:09 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 22 Sep 2016 22:58:09 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <25f020ab-90db-7b57-4e90-d3fe9e4bddd1@taschenorakel.de> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <1572252.L1a78adV0X@maurice> <2089649.Ciur4RRXTq@maurice> <20160921225808.GC3442@klara.mpi.htwm.de> <25f020ab-90db-7b57-4e90-d3fe9e4bddd1@taschenorakel.de> Message-ID: <20160922205809.GA3451@klara.mpi.htwm.de> On Thu, Sep 22, 2016 at 06:04:58AM +0200, Mathias Hasselmann wrote: > Am 22.09.2016 um 00:58 schrieb André Pönitz: > >On Wed, Sep 21, 2016 at 08:57:01AM +0200, Olivier Goffart wrote: > >>>No, it's not. It's changing undefined behavior into defined > >>>behavior. > >> > >>But in many case, we want to put something in a QVariant, and we > >>never compare this variant. Forbidding types that do not have an > >>operator== to be in a QVariant might be to strict. > > > >Forbidding types without operator== in QVariants is not needed, > >not even if one wanted to use associative container with > >QVariants as keys. > > > >[Pseudocode] > > > >bool operator(QVariant(Foo) a, QVariant(Bar) b) > >{ > > if Foo != Bar: > > return false > > if Foo has no operator==(): > > return true > > return (Foo)a == (Foo)b > >} > > > >establishes an equivalance relation by lumping all "uncomparable" > >objects into a single equivalency class. > > I rather was considering to return false. There is not much of a choice. An equivalence relation is reflexive, i.e. at least Foo(a) == Foo(a) must be true. Lacking the ability to compare Foos, treating them all equal at least doesn't break the relation. > But indeed. Forcing all that types into a single equivalency class feels > that unnatural, that users should notice that issue much quicker, than if > we'd return false. > > Would that be sufficient to warn Qt users, or would we also have to print > a warning? I don't have an opinion on that. Andre' From mwoehlke.floss at gmail.com Thu Sep 22 23:15:36 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 22 Sep 2016 17:15:36 -0400 Subject: [Development] QUuid documentation In-Reply-To: References: Message-ID: On 2016-09-08 05:35, Benjamin TERRIER wrote: > As of Qt 5.7, QUuid::createUuid() documentation is: > >> On any platform other than Windows, this function returns a new UUID with variant QUuid::DCE and version QUuid::Random. If the /dev/urandom device exists, then the numbers used to construct the UUID will be of cryptographic quality, which will make the UUID unique. Otherwise, the numbers of the UUID will be obtained from the local pseudo-random number generator (qrand(), which is seeded by qsrand()) which is usually not of cryptograhic quality, which means that the UUID can't be guaranteed to be unique. >> >> On a Windows platform, a GUID is generated, which almost certainly will be unique, on this or any other system, networked or not. > > So according to this there are 3 kinds of UUID: > - Generated by /dev/urandom > - Generated by qrand() > - Generated on Windows OS > > The documentation states explicitly that the first type is unique and > that the 2 last types are not unique. There are three types. The first is "unique" (unqualified). The second "can't be guaranteed to be unique" (and while not stated explicitly, "probably won't be under particular, easily obtained circumstances" is implied). The third "almost certainly will be unique". You are lumping the second and third into "not unique", which is a little strange given the difference in degree of "probably unique" that applies, which I think is throwing people off. However, I take your point that probably the first should have the same "almost certainly" qualification as the third, vs. the apparently unqualified "will be" assertion it has presently. FWIW, that seems to me like a reasonable change to request. (If nothing else, the first and third are AFAIK equally likely to either be or not be unique, so phrasing them similarly makes sense.) -- Matthew From vladstelmahovsky at gmail.com Fri Sep 23 07:00:42 2016 From: vladstelmahovsky at gmail.com (Vlad Stelmahovsky) Date: Fri, 23 Sep 2016 07:00:42 +0200 Subject: [Development] dev doesnt builds In-Reply-To: References: Message-ID: In my desperate attempt to build it I even re-clone whole qt5 repo from scratch. still doesnt works On Thu, Sep 22, 2016 at 4:37 PM, Alexander Blasche wrote: > Hi > > >Cannot read .....qt5/qtbase/src/corelib/qtcore-config.pri: No such file > or directory > >Cannot read .....qt5/qtbase/src/gui/qtgui-config.pri: No such file or > directory > >Project ERROR: Could not find feature system-zlib. > >Makefile:45: recipe for target 'sub-src-make_first' failed > >make[1]: *** [sub-src-make_first] Error 3 > >make[1]: Leaving directory '....../qt5/qtbase' > >Makefile:78: recipe for target 'module-qtbase-make_first' failed > >make: *** [module-qtbase-make_first] Error 2 > > >is there a workaround for this? > > > I had the same problem. Make sure that you have an up-to-date qt5.git > checkout for dev as well. In combination with git clean the problem solved > itself for me. > > -- > Alex > -- Best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Smith at qt.io Fri Sep 23 09:50:12 2016 From: Martin.Smith at qt.io (Martin Smith) Date: Fri, 23 Sep 2016 07:50:12 +0000 Subject: [Development] dev doesnt builds In-Reply-To: References: , Message-ID: I did git checkout 5.8 at the qt5 level but kept my qtbase module on dev branch. That seems to work. martin ________________________________ From: Development on behalf of Vlad Stelmahovsky Sent: Friday, September 23, 2016 7:00:42 AM To: Alexander Blasche Cc: development at qt-project.org Subject: Re: [Development] dev doesnt builds In my desperate attempt to build it I even re-clone whole qt5 repo from scratch. still doesnt works On Thu, Sep 22, 2016 at 4:37 PM, Alexander Blasche > wrote: Hi >Cannot read .....qt5/qtbase/src/corelib/qtcore-config.pri: No such file or directory >Cannot read .....qt5/qtbase/src/gui/qtgui-config.pri: No such file or directory >Project ERROR: Could not find feature system-zlib. >Makefile:45: recipe for target 'sub-src-make_first' failed >make[1]: *** [sub-src-make_first] Error 3 >make[1]: Leaving directory '....../qt5/qtbase' >Makefile:78: recipe for target 'module-qtbase-make_first' failed >make: *** [module-qtbase-make_first] Error 2 >is there a workaround for this? I had the same problem. Make sure that you have an up-to-date qt5.git checkout for dev as well. In combination with git clean the problem solved itself for me. -- Alex -- Best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Fri Sep 23 11:07:13 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 23 Sep 2016 09:07:13 +0000 Subject: [Development] First Qt 5.8.0 Beta snapshot available Message-ID: Hi, We have finally first Qt 5.8.0 beta snapshot available Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/570/ Mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/439/ src: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/ Linux ones are there as well but those don't work yet :( iOS installer is also missing but coming as well as MSVC2015 32 bit. Please take a tour to see how close to beta we are. Please make sure all beta blockers are visible in https://bugreports.qt.io/issues/?filter=17924 br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Fri Sep 23 11:22:08 2016 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 23 Sep 2016 11:22:08 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <20160922205809.GA3451@klara.mpi.htwm.de> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <25f020ab-90db-7b57-4e90-d3fe9e4bddd1@taschenorakel.de> <20160922205809.GA3451@klara.mpi.htwm.de> Message-ID: <3657161.2RyX6fn9fR@maurice> On Donnerstag, 22. September 2016 22:58:09 CEST André Pönitz wrote: > On Thu, Sep 22, 2016 at 06:04:58AM +0200, Mathias Hasselmann wrote: > > Am 22.09.2016 um 00:58 schrieb André Pönitz: > > >On Wed, Sep 21, 2016 at 08:57:01AM +0200, Olivier Goffart wrote: > > >>>No, it's not. It's changing undefined behavior into defined > > >>>behavior. > > >> > > >>But in many case, we want to put something in a QVariant, and we > > >>never compare this variant. Forbidding types that do not have an > > >>operator== to be in a QVariant might be to strict. > > > > > >Forbidding types without operator== in QVariants is not needed, > > >not even if one wanted to use associative container with > > >QVariants as keys. > > > > > >[Pseudocode] > > > > > >bool operator(QVariant(Foo) a, QVariant(Bar) b) > > >{ > > > > > > if Foo != Bar: > > > return false > > > > > > if Foo has no operator==(): > > > return true > > > > > > return (Foo)a == (Foo)b > > > > > >} > > > > > >establishes an equivalance relation by lumping all "uncomparable" > > >objects into a single equivalency class. > > > > I rather was considering to return false. > > There is not much of a choice. An equivalence relation is reflexive, > i.e. at least Foo(a) == Foo(a) must be true. Lacking the ability > to compare Foos, treating them all equal at least doesn't break the > relation. Why do we want that kind of mathematical purity? This ensure we have the most useless operator==. Most of the code use it for stuff like that: void setFoo(const QVariant &foo) { if (foo != m_foo) { m_foo = foo; emit fooChanged(); } } And suddenly returning always true if the variant has the same type will break this code. And i think will break most use case for QVariant::operator== What use case did you have in mind where a reflexive relation is any usefull? There is the case of the key of a QHash or in a QSet, but even then i'm not sure it is wise that all QVariant of the same type map to the "same" value. So let's be pragmatic here and do something usefull rather than something methematicaly correct, but useless and that break lot of code. > > > But indeed. Forcing all that types into a single equivalency class feels > > that unnatural, that users should notice that issue much quicker, than if > > we'd return false. > > > > Would that be sufficient to warn Qt users, or would we also have to print > > a warning? > > I don't have an opinion on that. > Now that we have C++11 and we can use some expression SFINAE, we can do something like: template auto registerEqualityOperator() -> decltype(std::declval() == std::declval()) Called from qRegisterMetaType, which automatically register the operator== if it exists. The QVariant::operator== could return false if none was registered. And possibly print a qWarning: "Attempting to compare two QVariant containing type 'Foo' which has no equality operation registered". -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From oswald.buddenhagen at qt.io Fri Sep 23 11:50:11 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 23 Sep 2016 11:50:11 +0200 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: <201609220941.30522.marc.mutz@kdab.com> References: <57CFB58D.2060200@qt.io> <201609220941.30522.marc.mutz@kdab.com> Message-ID: <20160923095011.GD6077@troll08> On Thu, Sep 22, 2016 at 09:41:29AM +0200, Marc Mutz wrote: > On Thursday 22 September 2016 08:55:13 Liang Qi wrote: > > Give the merge permission to everyone is obiviously not a solution. > > Not everyone, but approvers, maybe? Merges need to be reviewed like any other > commit, so why are they special, anyway? > because a botched merge push may result in hundreds of bogus reviews (when somebody does pull --rebase before pushing the merge; no, that's not a hypothetical situation). not having the right to push merges trains the users to not even attempt it. another reason is that some people tend to over-merge, needlessly cluttering the history. having to ask another person (who will hopefully critically examine the request) is a natural check for this. From edward.welbourne at qt.io Fri Sep 23 11:56:30 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 23 Sep 2016 09:56:30 +0000 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <3657161.2RyX6fn9fR@maurice> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <25f020ab-90db-7b57-4e90-d3fe9e4bddd1@taschenorakel.de> <20160922205809.GA3451@klara.mpi.htwm.de>, <3657161.2RyX6fn9fR@maurice> Message-ID: Olivier Goffart > What use case did you have in mind where a reflexive relation is any usefull? Well, having x == x for all x is generally considered a useful property of equality. That's all "reflexive" is saying. > There is the case of the key of a QHash or in a QSet, but even then i'm not > sure it is wise that all QVariant of the same type map to the "same" value. Indeed; having all values of some type equivalent is worse (for the "has my value changed" test you illustrate, at least) than having a value not equal to itself (which triggers a "changed" event for a non-change). In fact one can have one's mathematical purity by attacking the "for all x" part of the above instead of the "x == x" part. Although it's usual to talk about "a relation is reflexive on S if, for all s in S, it relates s to s" one can equally define reflexive by "whenever the relation relates any x to y, it also relates x to x and y to y". (This is the more natural formulation in a mathematics based on relations [*] rather than sets.) [*] http://www.chaos.org.uk/~eddy/maths/found/relate.xhtml#Types With that formulation (which doesn't tie the relation to a set that it's "on"), returning false for the types that don't support equality comparison works; we won't consider any value of such a type equal to *anything*, so our relation isn't required to relate them to themselves. We are then left with QVariant::operator== being a relation formally on only those QVariants that support comparison, not on all QVariants (although it tolerates being asked about the values it doesn't relate to anything; it just says no about them). It's not ideal (and the justification is heterodox) but false is a valid answer for the incomparable values, Eddy. From thiago.macieira at intel.com Fri Sep 23 16:50:27 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 23 Sep 2016 07:50:27 -0700 Subject: [Development] First Qt 5.8.0 Beta snapshot available In-Reply-To: References: Message-ID: <9287709.tjZBdVE0Nn@tjmaciei-mobl1> On sexta-feira, 23 de setembro de 2016 09:07:13 PDT Jani Heikkinen wrote: > Hi, > > > We have finally first Qt 5.8.0 beta snapshot available > > Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/570/ > > Mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/439/ > > src: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/ > > > Linux ones are there as well but those don't work yet :( iOS installer is > also missing but coming as well as MSVC2015 32 bit. Source is not available yet. This dir is empty: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/submodules/ -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Fri Sep 23 19:11:43 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 23 Sep 2016 13:11:43 -0400 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <20160922205809.GA3451@klara.mpi.htwm.de> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <1572252.L1a78adV0X@maurice> <2089649.Ciur4RRXTq@maurice> <20160921225808.GC3442@klara.mpi.htwm.de> <25f020ab-90db-7b57-4e90-d3fe9e4bddd1@taschenorakel.de> <20160922205809.GA3451@klara.mpi.htwm.de> Message-ID: On 2016-09-22 16:58, André Pönitz wrote: > There is not much of a choice. An equivalence relation is reflexive, > i.e. at least Foo(a) == Foo(a) must be true. JFTR... auto nan = qNaN(); assert(nan != nan); // okay assert(!(nan == nan)); // okay -- Matthew From apoenitz at t-online.de Fri Sep 23 19:45:18 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 23 Sep 2016 19:45:18 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <3657161.2RyX6fn9fR@maurice> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <25f020ab-90db-7b57-4e90-d3fe9e4bddd1@taschenorakel.de> <20160922205809.GA3451@klara.mpi.htwm.de> <3657161.2RyX6fn9fR@maurice> Message-ID: <20160923174518.GB3571@klara.mpi.htwm.de> On Fri, Sep 23, 2016 at 11:22:08AM +0200, Olivier Goffart wrote: > > There is not much of a choice. An equivalence relation is reflexive, > > i.e. at least Foo(a) == Foo(a) must be true. Lacking the ability > > to compare Foos, treating them all equal at least doesn't break the > > relation. > > Why do we want that kind of mathematical purity? Because that's the only sane way to avoid ugly surprises. > This ensure we have the most useless operator==. > Most of the code use it for stuff like that: > > void setFoo(const QVariant &foo) { > if (foo != m_foo) { > m_foo = foo; > emit fooChanged(); > } > } That gives already "surprising" behaviour if fed with QChar('a') and QString("a") in a row. And it is "surprising" to a degree that I'd call it buggy. > And suddenly returning always true if the variant has the same type will break > this code. And i think will break most use case for QVariant::operator== Most of the uses of QVariant::operator==() ARE ALREADY BROKEN, and will not be fixable if people refuse to accept basic requirements. > What use case did you have in mind where a reflexive relation is any usefull? > There is the case of the key of a QHash or in a QSet, but even then i'm not > sure it is wise that all QVariant of the same type map to the "same" value. The discussion started with making QVariant ready for use in hashs. > So let's be pragmatic here and do something usefull rather than something > methematicaly correct, but useless and that break lot of code. This "pragmatism" has already led to the current situation where the number of items in a QMap with QVariant keys depend on the order of insertion and other crap. > Now that we have C++11 and we can use some expression SFINAE, we can do > something like: > > > template > auto registerEqualityOperator() > -> decltype(std::declval() == std::declval()) > > Called from qRegisterMetaType, which automatically register the operator== if > it exists. > > > The QVariant::operator== could return false if none was registered. And > possibly print a qWarning: "Attempting to compare two QVariant containing type > 'Foo' which has no equality operation registered". That would be ok to, but does not invalidate my point. Andre' From apoenitz at t-online.de Fri Sep 23 20:17:47 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 23 Sep 2016 20:17:47 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <25f020ab-90db-7b57-4e90-d3fe9e4bddd1@taschenorakel.de> <20160922205809.GA3451@klara.mpi.htwm.de> <3657161.2RyX6fn9fR@maurice> Message-ID: <20160923181747.GC3571@klara.mpi.htwm.de> On Fri, Sep 23, 2016 at 09:56:30AM +0000, Edward Welbourne wrote: > Indeed; having all values of some type equivalent is worse (for the "has > my value changed" test you illustrate, at least) than having a value not > equal to itself (which triggers a "changed" event for a non-change). In > fact one can have one's mathematical purity by attacking the "for all x" > part of the above instead of the "x == x" part. Although it's usual to > talk about "a relation is reflexive on S if, for all s in S, it relates > s to s" Right. That's pretty much the definition the known universe uses: https://en.wikipedia.org/wiki/Reflexive_relation (and no, *I* didn't put it there) > one can equally define reflexive by "whenever the relation > relates any x to y, it also relates x to x and y to y". > (This is the > more natural formulation in a mathematics based on relations [*] rather > than sets.) > > [*] http://www.chaos.org.uk/~eddy/maths/found/relate.xhtml#Types > > With that formulation (which doesn't tie the relation to a set that it's > "on"), returning false for the types that don't support equality > comparison works; we won't consider any value of such a type equal to > *anything*, so our relation isn't required to relate them to themselves. > We are then left with QVariant::operator== being a relation formally on > only those QVariants that support comparison, not on all QVariants > (although it tolerates being asked about the values it doesn't relate to > anything; it just says no about them). How does that help with QHash which needs comparsion of the keys? > It's not ideal (and the justification is heterodox) but false is a valid > answer for the incomparable values, This is a nonsensical line of argument long as you try to use it to counter "unexpected" results. With your "uncomparable things compare false" approach QHash<>::contains() will never return true for uncomparable QVariants, i.e. code like void doSomethingOnlyOncePerValue(QVariant v) { static QHash seen; if (seen.contains(v)) return; seen.insert(v, 0); doSomething(v); } will be quite surprising, too. Andre' From nospam at vuorela.dk Fri Sep 23 21:10:40 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Fri, 23 Sep 2016 19:10:40 +0000 (UTC) Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <25f020ab-90db-7b57-4e90-d3fe9e4bddd1@taschenorakel.de> <20160922205809.GA3451@klara.mpi.htwm.de> <3657161.2RyX6fn9fR@maurice> <20160923174518.GB3571@klara.mpi.htwm.de> Message-ID: On 2016-09-23, André Pönitz wrote: > That gives already "surprising" behaviour if fed with QChar('a') and > QString("a") in a row. > > And it is "surprising" to a degree that I'd call it buggy. Then try feeding it boolean's and strings. QQmlPropertyMap map; map.insert(QLatin1String("key1"),true); map.insert(QLatin1String("key1"),QLatin1String("p")); QCOMPARE(map.value(QLatin1String("key1")).toString(),QLatin1String("p")); QCOMPARE((int)map.value(QLatin1String("key1")).type(),(int)QMetaType::QString); map.insert(QLatin1String("key1"),false); map.insert(QLatin1String("key1"),QLatin1String("")); QCOMPARE((int)map.value(QLatin1String("key1")).type(),(int)QMetaType::QString); (Taken from https://codereview.qt-project.org/#/c/121715/1//ALL when I was trying to fix things but ... kind of moved on) /Sune From tim at klingt.org Sat Sep 24 11:04:47 2016 From: tim at klingt.org (Tim Blechmann) Date: Sat, 24 Sep 2016 17:04:47 +0800 Subject: [Development] [5.7.1] release schedule? Message-ID: hi all, the 5.7.1 release was scheduled for sept/oct ... october is almost over, so i wonder what's the state of it? thanks a lot, tim From aha_1980 at gmx.de Sat Sep 24 11:37:31 2016 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Sat, 24 Sep 2016 11:37:31 +0200 Subject: [Development] [5.7.1] release schedule? In-Reply-To: References: Message-ID: Am 24.09.2016 um 11:04 schrieb Tim Blechmann: > hi all, > > the 5.7.1 release was scheduled for sept/oct ... october is almost over, > so i wonder what's the state of it? > > thanks a lot, > tim Hi Tim, I don't know the exact release plan either, but I guess they want to get 5.6.2 released first. The branch 5.7.1 already exists, so this will be the next step... > october is almost over, No, there are still five weeks left to release 5.7.1 in october :) André From massimocallegari at yahoo.it Sat Sep 24 12:01:36 2016 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Sat, 24 Sep 2016 10:01:36 +0000 (UTC) Subject: [Development] First Qt 5.8.0 Beta snapshot available In-Reply-To: References: Message-ID: <257493884.7506779.1474711296445@mail.yahoo.com> Hi, I am trying to build my application on the 5.8.0 441 snapshot for MacOS/iOS to check QTBUG-51131, but I believe something has changed in how pkg-config is handled by clang+qmake. The way: macx:QT_CONFIG -= no-pkg-config CONFIG += link_pkgconfig PKGCONFIG += sndfile Has been working on every 5.x release, but not on 5.8.0. The error I've got is: Project WARNING: pkg-config disabled, can't check package existence Project ERROR: sndfile development package not found Doing just PKGCONFIG += sndfile seems to go a bit further but then the sndfile headers cannot be found at build time. Please help ? Massimo ________________________________ Da: Jani Heikkinen A: "development at qt-project.org" Inviato: Venerdì 23 Settembre 2016 11:07 Oggetto: [Development] First Qt 5.8.0 Beta snapshot available Hi, We have finally first Qt 5.8.0 beta snapshot available Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/570/ Mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/439/ src: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/ Linux ones are there as well but those don't work yet :( iOS installer is also missing but coming as well as MSVC2015 32 bit. Please take a tour to see how close to beta we are. Please make sure all beta blockers are visible in https://bugreports.qt.io/issues/?filter=17924 From tim at klingt.org Sat Sep 24 16:33:21 2016 From: tim at klingt.org (Tim Blechmann) Date: Sat, 24 Sep 2016 22:33:21 +0800 Subject: [Development] [5.7.1] release schedule? In-Reply-To: References: Message-ID: >> the 5.7.1 release was scheduled for sept/oct ... october is almost over, >> so i wonder what's the state of it? >> >> thanks a lot, >> tim > > Hi Tim, > > I don't know the exact release plan either, but I guess they want to get > 5.6.2 released first. The branch 5.7.1 already exists, so this will be > the next step... ah ja, that makes sense ... >> october is almost over, > > No, there are still five weeks left to release 5.7.1 in october :) off-by-one-error 8) From thiago.macieira at intel.com Sun Sep 25 05:58:38 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 24 Sep 2016 20:58:38 -0700 Subject: [Development] QDataStream: blackbox or document all versions? Message-ID: <4148392.zjhzp35ijF@tjmaciei-mobl1> A thread[1] on the interest mailing list started when someone asked for the docs for the current format of the QDataStream wire protocol, to which I replied that it doesn't exist as we don't maintain such docs. Long story short, we have two options: Option 1: claim QDataStream is a blackbox and tell people that the only thing that can read QDataStream is QDataStream. That means removing the documentation file src/corelib/doc/src/datastreamformat.qdoc, as we don't want people getting any ideas that they could write their own decoders or encoders. Option 2: the opposite, saying that reading QDataStream's output is fine from non-Qt code and it's fine to write data that QDataStream should read. This means extending the documentation to cover ALL 17 wire formats (including bugs) and keeping it up to date whenever someone modifies the format. I am in favour of Option 1 because I really don't think QDataStream is a good format for exchanging data with non-Qt code. It's designed first and foremost for Qt's own internal data formats (sometimes even depending on internal details), the marshalling of certain types in certain versions is buggy and lossy. Instead, people should find a better transport format for their data, of which we already have in Qt: XML JSON D-Bus QSettings (to an extent) And I can add CBOR support if we want to. [1] http://lists.qt-project.org/pipermail/interest/2016-September/024387.html -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From eric.lemanissier at gmail.com Sun Sep 25 16:24:29 2016 From: eric.lemanissier at gmail.com (Eric Lemanisser) Date: Sun, 25 Sep 2016 14:24:29 +0000 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <4148392.zjhzp35ijF@tjmaciei-mobl1> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: You could choose to turn QDataStream into a black-box, but I think there should be a white-box alternative which has to be 1/ as efficient : binary format 2/ as easy to use : QDataStream is able to serialize any type with the help of qRegisterMetaTypeStreamOperators 3/ as generic : it should be able to use any QIODevice for transport/storage 1/ discards XML and JSON, and 3/ discards QSettings and D-Bus. I don't know CBOR, but it seems an interesting alternative. Eric Lemanissier Le dim. 25 sept. 2016 à 05:59, Thiago Macieira a écrit : > A thread[1] on the interest mailing list started when someone asked for the > docs for the current format of the QDataStream wire protocol, to which I > replied that it doesn't exist as we don't maintain such docs. > > Long story short, we have two options: > > that can read QDataStream is QDataStream. That means removing the > Option 1: claim QDataStream is a blackbox and tell people that the only > thing > that can read QDataStream is QDataStream. That means removing the > documentation file src/corelib/doc/src/datastreamformat.qdoc, as we don't > want > people getting any ideas that they could write their own decoders or > encoders. > > Option 2: the opposite, saying that reading QDataStream's output is fine > from > non-Qt code and it's fine to write data that QDataStream should read. This > means extending the documentation to cover ALL 17 wire formats (including > bugs) and keeping it up to date whenever someone modifies the format. > > > I am in favour of Option 1 because I really don't think QDataStream is a > good > format for exchanging data with non-Qt code. It's designed first and > foremost > for Qt's own internal data formats (sometimes even depending on internal > details), the marshalling of certain types in certain versions is buggy and > lossy. Instead, people should find a better transport format for their > data, of > which we already have in Qt: > > XML > JSON > D-Bus > QSettings (to an extent) > > And I can add CBOR support if we want to. > > [1] > http://lists.qt-project.org/pipermail/interest/2016-September/024387.html > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun Sep 25 19:40:06 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 25 Sep 2016 10:40:06 -0700 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: <1919698.jHcBiWdA7Q@tjmaciei-mobl1> On domingo, 25 de setembro de 2016 14:24:29 PDT Eric Lemanisser wrote: > 2/ as easy to use : QDataStream is able to serialize any type with the help > of qRegisterMetaTypeStreamOperators You only need that if you use QVariant. Regular QDataStream with non-type- erased types doesn't require that call. But that brings us to QDataStream's biggest advantage: the wealth of available operator<<. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Sun Sep 25 23:12:13 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 26 Sep 2016 00:12:13 +0300 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <4148392.zjhzp35ijF@tjmaciei-mobl1> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: <1957571474837933@web16j.yandex.ru> 25.09.2016, 06:58, "Thiago Macieira" : > A thread[1] on the interest mailing list started when someone asked for the > docs for the current format of the QDataStream wire protocol, to which I > replied that it doesn't exist as we don't maintain such docs. > > Long story short, we have two options: > > Option 1: claim QDataStream is a blackbox and tell people that the only thing > that can read QDataStream is QDataStream. That means removing the > documentation file src/corelib/doc/src/datastreamformat.qdoc, as we don't want > people getting any ideas that they could write their own decoders or encoders. > > Option 2: the opposite, saying that reading QDataStream's output is fine from > non-Qt code and it's fine to write data that QDataStream should read. This > means extending the documentation to cover ALL 17 wire formats (including > bugs) and keeping it up to date whenever someone modifies the format. > > I am in favour of Option 1 because I really don't think QDataStream is a good > format for exchanging data with non-Qt code. It's designed first and foremost > for Qt's own internal data formats (sometimes even depending on internal > details), the marshalling of certain types in certain versions is buggy and > lossy. Instead, people should find a better transport format for their data, of > which we already have in Qt: > >         XML >         JSON >         D-Bus >         QSettings (to an extent) > > And I can add CBOR support if we want to. In case you are going to implement CBOR from scratch, please support string reference extension [1] which is needed to encode repeating strings (most importantly, data keys) efficiently. [1] http://cbor.schmorp.de/stringref > > [1] http://lists.qt-project.org/pipermail/interest/2016-September/024387.html > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From annulen at yandex.ru Sun Sep 25 23:37:25 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 26 Sep 2016 00:37:25 +0300 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <1957571474837933@web16j.yandex.ru> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <1957571474837933@web16j.yandex.ru> Message-ID: <2268541474839445@web33m.yandex.ru> 26.09.2016, 00:12, "Konstantin Tokarev" : > 25.09.2016, 06:58, "Thiago Macieira" : >>  A thread[1] on the interest mailing list started when someone asked for the >>  docs for the current format of the QDataStream wire protocol, to which I >>  replied that it doesn't exist as we don't maintain such docs. >> >>  Long story short, we have two options: >> >>  Option 1: claim QDataStream is a blackbox and tell people that the only thing >>  that can read QDataStream is QDataStream. That means removing the >>  documentation file src/corelib/doc/src/datastreamformat.qdoc, as we don't want >>  people getting any ideas that they could write their own decoders or encoders. >> >>  Option 2: the opposite, saying that reading QDataStream's output is fine from >>  non-Qt code and it's fine to write data that QDataStream should read. This >>  means extending the documentation to cover ALL 17 wire formats (including >>  bugs) and keeping it up to date whenever someone modifies the format. >> >>  I am in favour of Option 1 because I really don't think QDataStream is a good >>  format for exchanging data with non-Qt code. It's designed first and foremost >>  for Qt's own internal data formats (sometimes even depending on internal >>  details), the marshalling of certain types in certain versions is buggy and >>  lossy. Instead, people should find a better transport format for their data, of >>  which we already have in Qt: >> >>          XML >>          JSON >>          D-Bus >>          QSettings (to an extent) >> >>  And I can add CBOR support if we want to. > > In case you are going to implement CBOR from scratch, please support string > reference extension [1] which is needed to encode repeating strings (most > importantly, data keys) efficiently. > > [1] http://cbor.schmorp.de/stringref BTW, newly emerged SuperPack format goes further and introduces repeated keyset optimization https://github.com/shapesecurity/superpack-spec https://www.infoq.com/news/2016/08/superpack > >>  [1] http://lists.qt-project.org/pipermail/interest/2016-September/024387.html >>  -- >>  Thiago Macieira - thiago.macieira (AT) intel.com >>    Software Architect - Intel Open Source Technology Center >> >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From annulen at yandex.ru Sun Sep 25 23:42:12 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 26 Sep 2016 00:42:12 +0300 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <4148392.zjhzp35ijF@tjmaciei-mobl1> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: <2865301474839732@web7g.yandex.ru> 25.09.2016, 06:58, "Thiago Macieira" : > A thread[1] on the interest mailing list started when someone asked for the > docs for the current format of the QDataStream wire protocol, to which I > replied that it doesn't exist as we don't maintain such docs. > > Long story short, we have two options: > > Option 1: claim QDataStream is a blackbox and tell people that the only thing > that can read QDataStream is QDataStream. That means removing the > documentation file src/corelib/doc/src/datastreamformat.qdoc, as we don't want > people getting any ideas that they could write their own decoders or encoders. > > Option 2: the opposite, saying that reading QDataStream's output is fine from > non-Qt code and it's fine to write data that QDataStream should read. This > means extending the documentation to cover ALL 17 wire formats (including > bugs) and keeping it up to date whenever someone modifies the format. I think there is also Option 3: restore documentation of version 12 and declare that it's the only format version that is meant for use with 3rd party encoders and decoders. > > I am in favour of Option 1 because I really don't think QDataStream is a good > format for exchanging data with non-Qt code. It's designed first and foremost > for Qt's own internal data formats (sometimes even depending on internal > details), the marshalling of certain types in certain versions is buggy and > lossy. Instead, people should find a better transport format for their data, of > which we already have in Qt: > >         XML >         JSON >         D-Bus >         QSettings (to an extent) > > And I can add CBOR support if we want to. > > [1] http://lists.qt-project.org/pipermail/interest/2016-September/024387.html > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From giuseppe.dangelo at kdab.com Mon Sep 26 00:16:28 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 26 Sep 2016 00:16:28 +0200 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <2865301474839732@web7g.yandex.ru> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <2865301474839732@web7g.yandex.ru> Message-ID: Il 25/09/2016 23:42, Konstantin Tokarev ha scritto: > I think there is also > > Option 3: restore documentation of version 12 and declare that it's the only > format version that is meant for use with 3rd party encoders and decoders. > What is the rationale be for this? Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From jedrzej.nowacki at qt.io Mon Sep 26 08:52:24 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 26 Sep 2016 08:52:24 +0200 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <4148392.zjhzp35ijF@tjmaciei-mobl1> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: <1537060.VJ0A0TlAzE@42> On lørdag 24. september 2016 20.58.38 CEST Thiago Macieira wrote: > A thread[1] on the interest mailing list started when someone asked for the > docs for the current format of the QDataStream wire protocol, to which I > replied that it doesn't exist as we don't maintain such docs. > > Long story short, we have two options: > > Option 1: claim QDataStream is a blackbox and tell people that the only > thing that can read QDataStream is QDataStream. That means removing the > documentation file src/corelib/doc/src/datastreamformat.qdoc, as we don't > want people getting any ideas that they could write their own decoders or > encoders. > > Option 2: the opposite, saying that reading QDataStream's output is fine > from non-Qt code and it's fine to write data that QDataStream should read. > This means extending the documentation to cover ALL 17 wire formats > (including bugs) and keeping it up to date whenever someone modifies the > format. > > > I am in favour of Option 1 because I really don't think QDataStream is a > good format for exchanging data with non-Qt code. It's designed first and > foremost for Qt's own internal data formats (sometimes even depending on > internal details), the marshalling of certain types in certain versions is > buggy and lossy. Instead, people should find a better transport format for > their data, of which we already have in Qt: > > XML > JSON > D-Bus > QSettings (to an extent) > > And I can add CBOR support if we want to. > > [1] > http://lists.qt-project.org/pipermail/interest/2016-September/024387.html Hi, Option 4: Document only basic types, like char, int, maybe QByteArray and QString, QVector. Everything above is tight to Qt implementation and therefore is super hard to use from 3rd party perspective as it is changing often. But I agree with you QDataStream is not a good format for exchanging data with non-Qt code so option 1 is Ok too. Cheers, Jędrek From Martin.Smith at qt.io Mon Sep 26 08:59:01 2016 From: Martin.Smith at qt.io (Martin Smith) Date: Mon, 26 Sep 2016 06:59:01 +0000 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <4148392.zjhzp35ijF@tjmaciei-mobl1> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: Do we need a way to tie A specific qdoc comment to the result of a specific autotest? martin ________________________________ From: Development on behalf of Thiago Macieira Sent: Sunday, September 25, 2016 5:58:38 AM To: development at qt-project.org Subject: [Development] QDataStream: blackbox or document all versions? A thread[1] on the interest mailing list started when someone asked for the docs for the current format of the QDataStream wire protocol, to which I replied that it doesn't exist as we don't maintain such docs. Long story short, we have two options: Option 1: claim QDataStream is a blackbox and tell people that the only thing that can read QDataStream is QDataStream. That means removing the documentation file src/corelib/doc/src/datastreamformat.qdoc, as we don't want people getting any ideas that they could write their own decoders or encoders. Option 2: the opposite, saying that reading QDataStream's output is fine from non-Qt code and it's fine to write data that QDataStream should read. This means extending the documentation to cover ALL 17 wire formats (including bugs) and keeping it up to date whenever someone modifies the format. I am in favour of Option 1 because I really don't think QDataStream is a good format for exchanging data with non-Qt code. It's designed first and foremost for Qt's own internal data formats (sometimes even depending on internal details), the marshalling of certain types in certain versions is buggy and lossy. Instead, people should find a better transport format for their data, of which we already have in Qt: XML JSON D-Bus QSettings (to an extent) And I can add CBOR support if we want to. [1] http://lists.qt-project.org/pipermail/interest/2016-September/024387.html -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From tero.kojo at qt.io Mon Sep 26 09:00:59 2016 From: tero.kojo at qt.io (Tero Kojo) Date: Mon, 26 Sep 2016 07:00:59 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: Message-ID: Hi, This initiative is much appreciated, thank you Louai! Having been in the session at QtCon, I don't have any problems with the proposed format and process as outlined in the initial QUIPS. I'd like to request two QUIP numbers "Qt Community Code of Conduct", and another one for "Code of Conduct for Qt Events". I guess the repo isn't there yet, do we wait on the lazy agreement process until it is created? Tero > -----Original Message----- > From: Development [mailto:development-bounces+tero.kojo=qt.io at qt- > project.org] On Behalf Of Louai Al-Khanji > Sent: tiistai 20. syyskuuta 2016 1.45 > To: development at qt-project.org > Subject: [Development] QCS2016 Session Notes - QUIPs for Qt > > Hi all, > > Here are my notes from the QUIPs session. Thank you for your patience. :-) > > QUIPs are a proposed design process for Qt, modeled after Python’s PEPs. > > QUIP 1 introduces the general concept: > > http://quips-qt-io.herokuapp.com/quip-0001.html > > QUIP 2 details the Qt governance model, it’s simply the current wiki page > converted into a QUIP: > > http://quips-qt-io.herokuapp.com/quip-0002.html > > QUIP 3 is an informational QUIP containing the session notes, which are > repeated below: > > http://quips-qt-io.herokuapp.com/quip-0003.html > > The heroku domain is obviously a placeholder. > > I have also attached the source files for proposed QUIPs 1, 2, and 3 to this e- > mail. > > One item left open was licensing of the QUIPs themselves. For these I > propose Creative Commons CC0. > > Any and all feedback welcome. > > Cheers, > Louai > > ---------------- BEGIN NOTES ---------------- > > At the Qt Contributors' Summit 2016 in Berlin a session was held to discuss > the idea of introducing QUIPs as a new process for Qt governance. > > The general idea was introduced by looking at QUIPs 1 and 2, and by looking > at some Python PEPs. The general feedback was positive. An attempt was > made to identify the minimum set of work required to bootstrap QUIP, > which was the main theme of the session. > > The overall discussion is summarized below, in roughly chronological order. > > - Discussed background of QUIP, the process and the documents. Referred > to > Python and looked at QUIP 1 and QUIP 2 which had been prepared prior to > the > session. > > - The idea is to have a new git repository with the QUIP text files > > - Managed through Qt's normal work flow, currently gerrit code review > > - The maintainer of the quips repository takes on required editorial duties > - Agreed that the text documents should be limited to 80 character lines. > > - Agreed that care must be taken to ensure that QUIPs are written in > "proper" > English so as to be clear, understandable and concise. > > - Talked about how a new QUIP is introduced. The most important thing is to > reserve a number, which is the identifier of any one QUIP. The title can > change, and is expected to do so from time to time. > > - New QUIP documents will go through a review process like any other patch > to > Qt. The author of the QUIP is responsible for logging this discussion in the > evolving QUIP itself. > > - The important thing is to bootstrap the process. Once it is bootstrapped, it > is possible to fine-tune the QUIP process through QUIPs. It is expected that > this will happen. > > - The question of what goes into a QUIP was discussed. QUIP 1 gives a rough > overview of the different kinds of possible QUIPs. It is expected that the > content be further specified in revisions of QUIP 1 or in follow-up QUIPs. > > - Like any other part of Qt, QUIPs are living documents. They can be updated, > amended or entirely superseded by later ones. > > - QUIP licensing was discussed. Python's PEPs are required to be either > placed > in the public domain or licensed under the Open Publication License. The > former is not possible in all jurisdictions and the latter has apparently > been superseded by the Creative Commons licenses the CC0 license was > suggested. > > - The minimum QUIP boostrapping process was discussed: > > 1. Post QUIP 1 to qt-development mailing list for discussion. > > 2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io > has since been made available) > > 3. Create new git repository to hold QUIPs > > - The initial QUIP process was discussed: > > 1. Author of QUIP reserves new number in QUIP 0 (the index QUIP) through > gerrit > > 2. The author gives notice of new QUIP by sending it to qt-development, > either inline or as a text attachment (things like this can be refined > later through QUIPs) > > 3. Concurrently the author pushes the draft to gerrit where further > discussion can take place. This discussion must be described in the QUIP. > > 4. Decisions are achieved through the same lazy consensus mechanism that > is in place today. In that respect nothing changes. > > 5. A final +2 from the QUIP maintainer(s) is required. This differs slightly > from other parts of Qt as only the maintainer(s) can +2 changes to this > repository. > > - Louai naively volunteered to convert existing material on the wiki into a > series of QUIPs. > > - There was a question whether community guidelines could be described in > a > QUIP. The answer is a resounding yes. > > - The QUIP lifecycle was discussed. The following two items were explored: > > 1. Superseding QUIPs. These are QUIPs that both change some mechanism > described in an earlier QUIP and change the content of that QUIP > substantially. For small changes existing QUIPs can be updated. > > 2. Retroactive QUIPs are possible. That is to say, QUIPs can be written > to describe a change that occured in the past. For instance, an > Implementation Track QUIP can be written after something has been > added. > From jedrzej.nowacki at qt.io Mon Sep 26 09:02:58 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 26 Sep 2016 09:02:58 +0200 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: References: Message-ID: <4898690.X1uOUlSLlE@42> On mandag 19. september 2016 11.14.51 CEST Chris Adams wrote: > Hi, > > Recently, a few unit test failures[1] in the (unreleased) QtPIM module > showed that the recent change[2] which changes the semantics of null > assignment (from JS) to a QVariant Q_PROPERTY can affect existing client > code. > > Certainly, the cases which are affected are most likely edge-cases (that > is, specifically testing the type or value of the QVariant within C++ code > to detect "null" assignment), however it is probably worth raising for > discussion. > > Why was the change made? The commit message tells us what was changed, but > not the reasoning behind the change. The unit tests were changed, so the > behaviour change was clearly intentional (and the old behaviour considered > problematic), and I assume that there must be very good reasons to make > such a change, but it wasn't discussed on the mailing list, so I don't know > what those reasons are. > > Best regards, > Chris. > > [1] https://codereview.qt-project.org/#/c/170491/ > [2] https://codereview.qt-project.org/#/c/167062/ > > > www.qinetic.com.au - Qt And QML User Experience Specialists Hi, There are many reasons, mostly related to C++11 (in more or less chronological order): - 5.8 depends on C++11 that has null defined sensibly so we want to use it to mark null values. - std::nullptr_t became registered type which is meant to be use for null values - QJson support got better null handling (the feature was waiting for std::nullptr_t in metatype) - using (void*)0 for null in QVariant was suboptimal as it could not detect invalid states like for example (void*)1 I guess there are more from QML perspective. Cheers, Jędrek From thiago.macieira at intel.com Mon Sep 26 09:14:03 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Sep 2016 00:14:03 -0700 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <1957571474837933@web16j.yandex.ru> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <1957571474837933@web16j.yandex.ru> Message-ID: <2163064.9JTvVVdSh5@tjmaciei-mobl1> On segunda-feira, 26 de setembro de 2016 00:12:13 PDT Konstantin Tokarev wrote: > In case you are going to implement CBOR from scratch, please support string > reference extension [1] which is needed to encode repeating strings (most > importantly, data keys) efficiently. Please create a feature suggestion for me at https://github.com/01org/tinycbor/ I'll implement it once it becomes an RFC (not before). This looks like a nice suggestion, but requires the decoder to support it and may not be supported by all. TinyCBOR is meant to work on very constrained systems and keeping track of what an atom/quark is supposed to be could be expensive if all the decoder does is do a stream decoding and operate as it reads. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Sep 26 09:15:04 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Sep 2016 00:15:04 -0700 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <2865301474839732@web7g.yandex.ru> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <2865301474839732@web7g.yandex.ru> Message-ID: <6631959.9ikJTaXOS7@tjmaciei-mobl1> On segunda-feira, 26 de setembro de 2016 00:42:12 PDT Konstantin Tokarev wrote: > Option 3: restore documentation of version 12 and declare that it's the only > format version that is meant for use with 3rd party encoders and decoders. Why 12? It can't transmit QDateTime timezones. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Sep 26 09:35:10 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Sep 2016 00:35:10 -0700 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: <77701979.PvNnZphieT@tjmaciei-mobl1> On segunda-feira, 26 de setembro de 2016 06:59:01 PDT Martin Smith wrote: > Do we need a way to tie A specific qdoc comment to the result of a specific > autotest? I don't think we need to go that far. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Sep 26 09:37:07 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Sep 2016 00:37:07 -0700 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <4898690.X1uOUlSLlE@42> References: <4898690.X1uOUlSLlE@42> Message-ID: <2924212.X3JXzurJvh@tjmaciei-mobl1> On segunda-feira, 26 de setembro de 2016 09:02:58 PDT Jędrzej Nowacki wrote: > On mandag 19. september 2016 11.14.51 CEST Chris Adams wrote: > > Hi, > > > > Recently, a few unit test failures[1] in the (unreleased) QtPIM module > > showed that the recent change[2] which changes the semantics of null > > assignment (from JS) to a QVariant Q_PROPERTY can affect existing client > > code. > > > > Certainly, the cases which are affected are most likely edge-cases (that > > is, specifically testing the type or value of the QVariant within C++ code > > to detect "null" assignment), however it is probably worth raising for > > discussion. > > > > Why was the change made? The commit message tells us what was changed, > > but > > not the reasoning behind the change. The unit tests were changed, so the > > behaviour change was clearly intentional (and the old behaviour considered > > problematic), and I assume that there must be very good reasons to make > > such a change, but it wasn't discussed on the mailing list, so I don't > > know > > what those reasons are. > > > > Best regards, > > Chris. > > > > [1] https://codereview.qt-project.org/#/c/170491/ > > [2] https://codereview.qt-project.org/#/c/167062/ > > > > > > www.qinetic.com.au - Qt And QML User Experience Specialists > > Hi, > > There are many reasons, mostly related to C++11 (in more or less > chronological order): > - 5.8 depends on C++11 that has null defined sensibly so we want to use it > to mark null values. > - std::nullptr_t became registered type which is meant to be use for null > values > - QJson support got better null handling (the feature was waiting for > std::nullptr_t in metatype) > - using (void*)0 for null in QVariant was suboptimal as it could not detect > invalid states like for example (void*)1 Those are the reasons that enabled the change, not a justification for why it is better (except the last one, which I don't agree; you can always check the value). Repeating Chris's question: is it worth the breakage on the user code? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Mon Sep 26 09:39:51 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 26 Sep 2016 10:39:51 +0300 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <6631959.9ikJTaXOS7@tjmaciei-mobl1> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <2865301474839732@web7g.yandex.ru> <6631959.9ikJTaXOS7@tjmaciei-mobl1> Message-ID: <532131474875591@web15o.yandex.ru> 26.09.2016, 10:15, "Thiago Macieira" : > On segunda-feira, 26 de setembro de 2016 00:42:12 PDT Konstantin Tokarev > wrote: >>  Option 3: restore documentation of version 12 and declare that it's the only >>  format version that is meant for use with 3rd party encoders and decoders. > > Why 12? It can't transmit QDateTime timezones. Just because it is already documented, so no extra work is needed. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From marc.mutz at kdab.com Mon Sep 26 09:48:17 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 26 Sep 2016 09:48:17 +0200 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <1919698.jHcBiWdA7Q@tjmaciei-mobl1> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <1919698.jHcBiWdA7Q@tjmaciei-mobl1> Message-ID: <201609260948.17717.marc.mutz@kdab.com> On Sunday 25 September 2016 19:40:06 Thiago Macieira wrote: > But that brings us to QDataStream's biggest advantage: the wealth of > available operator<<. Which is also one of its major drawbacks: Streaming out may invoke any implicit conversions, and while the worst of these are probably caught be the streaming-in code, which disables most implicit conversion by way of taking an lvalue reference, the derived-to-base class conversion is still performed, with bad potential side effects for both Qt and the user (cf. the recent QDBusArgument::op<<(QList) issue[1]). Thanks, Marc [1] QtBase commits d55f2b1fb9c910bc118f75967a0e6273f8aa98d1 and 5f542f3cca13f2da58b82aee2efbaffefeee00a7 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From jani.heikkinen at qt.io Mon Sep 26 09:54:23 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 26 Sep 2016 07:54:23 +0000 Subject: [Development] HEADS-UP: Branching from '5.7' to '5.7.1' started Message-ID: Hi all, We have now created '5.7.1' branch for Qt 5.7.1 release. Please start using it for changes targeted to Qt 5.7.1 release. And as usual there is time to finalize ongoing ones in '5.7' branch; final downmerge from '5.7' to '5.7.1' will be done after a week. br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jedrzej.nowacki at qt.io Mon Sep 26 09:55:13 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 26 Sep 2016 09:55:13 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <3657161.2RyX6fn9fR@maurice> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <20160922205809.GA3451@klara.mpi.htwm.de> <3657161.2RyX6fn9fR@maurice> Message-ID: <2440787.qSYOX0Yjf8@42> On fredag 23. september 2016 11.22.08 CEST Olivier Goffart wrote: > template > auto registerEqualityOperator() > -> decltype(std::declval() == std::declval()) I have tried it already. Sadly it breaks terribly in case of private/protected operators. It doesn't solve the problem, because types may got converted just to satisfy operator== type requirements. In addition it causes small perf problems. So QVariant::operator== is broken and it is not fixable without _major_ breakages. Cheers, Jędrek From jedrzej.nowacki at qt.io Mon Sep 26 09:57:27 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 26 Sep 2016 09:57:27 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <2037719.HAYudMlsJZ@tjmaciei-mobl1> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> Message-ID: <1519980.lLWlKfCS63@42> On mandag 19. september 2016 09.20.48 CEST Thiago Macieira wrote: > This code was there in Qt 5.0, so I kept it when I refactored the numeric > comparisons. Now, dealing with QTBUG-56073, I'm wondering if it should be > there in the first place. > > Should we do fuzzy comparisns in QVariant? > > Note that the fuzzy comparisons are always performed in qreal precision > (whichever that may be), regardless of whether the original number is float, > double or an integer. No. I think we should avoid it, there are to many side effects of such behavior change. Cheers, Jędrek From ulf.hermann at qt.io Mon Sep 26 10:11:09 2016 From: ulf.hermann at qt.io (Ulf Hermann) Date: Mon, 26 Sep 2016 10:11:09 +0200 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <4148392.zjhzp35ijF@tjmaciei-mobl1> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: <329cc5fd-4ce8-3bad-2f45-53ea80bbbc87@qt.io> On 09/25/2016 05:58 AM, Thiago Macieira wrote: > A thread[1] on the interest mailing list started when someone asked for the > docs for the current format of the QDataStream wire protocol, to which I > replied that it doesn't exist as we don't maintain such docs. > > Long story short, we have two options: [...] I see another option: Make QDataStream a good interchange format. From your reply on the interest mailing list: > I also don't think the QDataStream binary format is particularly good for non- > Qt purposes. It passes internals that are really about how Qt works, not meant > for interchange of information. For example, QDate passes the Julian Day in > 64-bit format -- who in the world exchanges data like that? One would expect > the serialisation format of a date and time to be something like milliseconds > since 1970, milliseconds since 1601 or a string format, like ISO 3337. It > passes strings as UTF-16 encoded instead of encoding with UTF-8, which would > in turn allow interchanging QString and QByteArray serialisation formats. > > It's also by default quite inefficient since it marshalls everything as big- > endian, while most CPUs are little-endian. It has no support for indexing or > random-access seeking. It can't be used as a DOM storage, like QJsonDocument > can. All of that, except for the default endianness, could be fixed on a per operator base. Changing the default endianness can also be done with minimal effort and would only require incrementing the data stream version. Considering this, QDataStream may at the moment not be very efficient, but it does have some potential. We could probably even change all the operators to read and write CBOR, and that would also only require a version change. The versioning allows us to adapt the wire format to whatever is needed now or in the future. I don't know any other data interchange format which can do this. This doesn't change the implicit conversion problem that Marc mentioned, but at the moment I don't quite see a way to fix it without removing a lot of convenience for the user (that is, have the user specify the exact intended type for each serialization operation). regards, Ulf From marc.mutz at kdab.com Mon Sep 26 10:13:02 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 26 Sep 2016 10:13:02 +0200 Subject: [Development] HEADS-UP: Branching from '5.7' to '5.7.1' started In-Reply-To: References: Message-ID: <201609261013.02506.marc.mutz@kdab.com> Hi, On Monday 26 September 2016 09:54:23 Jani Heikkinen wrote: > And as usual there is time to > finalize ongoing ones in '5.7' branch; final downmerge from '5.7' to > '5.7.1' will be done after a week. I'd like to confess that I have no idea what that usual one-week hiatus of the 5.X branch is supposed to achieve. Apart from forming a funny Git ancestry tree, all it does is shut down 5.X for commits that for whatever reason should not be in 5.X.Y. We have a way to re- target change requests between branches, why not use it? I.e: - take CI on 5.X down (disable submit button) - wait for all integrations on 5.X to end (successfully or not) - then branch 5.X.Y. off the result - re-enable CI on 5.X - possibly automatically[1] retarget to 5.X.Y any 5.X change that had an attempted integration run before to 5.X.Y. - deal with retarget requests of the rest as usual What am I missing? Thanks, Marc [1] automatic here means to have script generate a list of URLs or IDs of such requests and have that list mailed to Ossi. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From olivier at woboq.com Mon Sep 26 10:17:45 2016 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 26 Sep 2016 10:17:45 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <2440787.qSYOX0Yjf8@42> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <3657161.2RyX6fn9fR@maurice> <2440787.qSYOX0Yjf8@42> Message-ID: <1574457.747gTH3e7U@maurice> On Montag, 26. September 2016 09:55:13 CEST Jędrzej Nowacki wrote: > On fredag 23. september 2016 11.22.08 CEST Olivier Goffart wrote: > > template > > auto registerEqualityOperator() > > > > -> decltype(std::declval() == std::declval()) > > I have tried it already. Sadly it breaks terribly in case of > private/protected operators. It does not break. It will simply not be registered if it's private. (It is a C++11 expression SFINAE in a decltype, not a &T::operator== substitution) > It doesn't solve the problem, because types > may got converted just to satisfy operator== type requirements. That is indeed more of a problem. I think we can live with that. > In addition it causes small perf problems. Are you talking about the registration cost? If we register all at the same time, I'd say that's negligible. > So QVariant::operator== is broken and it is not fixable without _major_ > breakages. Yes that's true. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From marc.mutz at kdab.com Mon Sep 26 10:24:21 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 26 Sep 2016 10:24:21 +0200 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <329cc5fd-4ce8-3bad-2f45-53ea80bbbc87@qt.io> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <329cc5fd-4ce8-3bad-2f45-53ea80bbbc87@qt.io> Message-ID: <201609261024.21446.marc.mutz@kdab.com> On Monday 26 September 2016 10:11:09 Ulf Hermann wrote: > This doesn't change the implicit conversion problem that Marc mentioned, > but at the moment I don't quite see a way to fix it without removing a lot > of convenience for the user (that is, have the user specify the exact > intended type for each serialization operation). The solution is to have just one (templated) op<> and (partially) specialise a struct that contains a static function (or a function call operator). This is how std::hash works (except it lacks the convenience function so you have to be explicit about the type), and why it's not susceptible to problems such a qHash(badly-designed smart-pointer) invoking qHash(bool) (if we had qHash(bool), which we don't have, for precisely that reason). Another solution is to write every op<> as a constrained template, but that is decidedly not user-friendly (where user here is the user that extends op<> to her own types). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From michael.winkelmann at qt.io Mon Sep 26 10:40:02 2016 From: michael.winkelmann at qt.io (Michael Winkelmann) Date: Mon, 26 Sep 2016 10:40:02 +0200 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <329cc5fd-4ce8-3bad-2f45-53ea80bbbc87@qt.io> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <329cc5fd-4ce8-3bad-2f45-53ea80bbbc87@qt.io> Message-ID: I think what Qt is lacking is a good serialization module like cereal or boost serialization. With this pattern, QDataStream would be just another archive format, like JSON or XML. Cereal has portable and unportable binary for endianness. The developer should be able specify how the data is serialized and select an arbitrary archive type that takes streams operators as default serialization method. PS: For wire protocols, I would also consider Protobuf as an option. On 26.09.2016 10:11, Ulf Hermann wrote: > On 09/25/2016 05:58 AM, Thiago Macieira wrote: >> A thread[1] on the interest mailing list started when someone asked >> for the >> docs for the current format of the QDataStream wire protocol, to which I >> replied that it doesn't exist as we don't maintain such docs. >> >> Long story short, we have two options: [...] > > I see another option: Make QDataStream a good interchange format. > From your reply on the interest mailing list: > >> I also don't think the QDataStream binary format is particularly good >> for non- >> Qt purposes. It passes internals that are really about how Qt works, >> not meant >> for interchange of information. For example, QDate passes the Julian >> Day in >> 64-bit format -- who in the world exchanges data like that? One would >> expect >> the serialisation format of a date and time to be something like >> milliseconds >> since 1970, milliseconds since 1601 or a string format, like ISO >> 3337. It >> passes strings as UTF-16 encoded instead of encoding with UTF-8, >> which would >> in turn allow interchanging QString and QByteArray serialisation >> formats. >> >> It's also by default quite inefficient since it marshalls everything >> as big- >> endian, while most CPUs are little-endian. It has no support for >> indexing or >> random-access seeking. It can't be used as a DOM storage, like >> QJsonDocument >> can. > > All of that, except for the default endianness, could be fixed on a > per operator base. Changing the default endianness can also be done > with minimal effort and would only require incrementing the data > stream version. Considering this, QDataStream may at the moment not be > very efficient, but it does have some potential. We could probably > even change all the operators to read and write CBOR, and that would > also only require a version change. The versioning allows us to adapt > the wire format to whatever is needed now or in the future. I don't > know any other data interchange format which can do this. > > This doesn't change the implicit conversion problem that Marc > mentioned, but at the moment I don't quite see a way to fix it without > removing a lot of convenience for the user (that is, have the user > specify the exact intended type for each serialization operation). > > regards, > Ulf > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From ulf.hermann at qt.io Mon Sep 26 10:54:30 2016 From: ulf.hermann at qt.io (Ulf Hermann) Date: Mon, 26 Sep 2016 10:54:30 +0200 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <329cc5fd-4ce8-3bad-2f45-53ea80bbbc87@qt.io> Message-ID: <1f174963-e1ef-cd7f-b839-1527eb8d773c@qt.io> On 09/26/2016 10:40 AM, Michael Winkelmann wrote: > I think what Qt is lacking is a good serialization module like cereal or > boost serialization. > With this pattern, QDataStream would be just another archive format, > like JSON or XML. > Cereal has portable and unportable binary for endianness. Btw, QDataStream has a method setByteOrder(). Big endian is just the default. regards, Ulf From jani.heikkinen at qt.io Mon Sep 26 11:03:12 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 26 Sep 2016 09:03:12 +0000 Subject: [Development] First Qt 5.8.0 Beta snapshot available In-Reply-To: <9287709.tjZBdVE0Nn@tjmaciei-mobl1> References: , <9287709.tjZBdVE0Nn@tjmaciei-mobl1> Message-ID: Arg, some error when copying submodule src packages. New try ongoing, should be there later today br, Jani ________________________________ From: Development on behalf of Thiago Macieira Sent: Friday, September 23, 2016 5:50 PM To: development at qt-project.org Subject: Re: [Development] First Qt 5.8.0 Beta snapshot available On sexta-feira, 23 de setembro de 2016 09:07:13 PDT Jani Heikkinen wrote: > Hi, > > > We have finally first Qt 5.8.0 beta snapshot available > > Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/570/ > > Mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/439/ > > src: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/ > > > Linux ones are there as well but those don't work yet :( iOS installer is > also missing but coming as well as MSVC2015 32 bit. Source is not available yet. This dir is empty: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/submodules/ -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Mon Sep 26 11:28:12 2016 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 26 Sep 2016 11:28:12 +0200 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <20160923174518.GB3571@klara.mpi.htwm.de> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <3657161.2RyX6fn9fR@maurice> <20160923174518.GB3571@klara.mpi.htwm.de> Message-ID: <20780093.v9zTqhYQ6I@maurice> On Freitag, 23. September 2016 19:45:18 CEST André Pönitz wrote: > On Fri, Sep 23, 2016 at 11:22:08AM +0200, Olivier Goffart wrote: > > > There is not much of a choice. An equivalence relation is reflexive, > > > i.e. at least Foo(a) == Foo(a) must be true. Lacking the ability > > > to compare Foos, treating them all equal at least doesn't break the > > > relation. > > > > Why do we want that kind of mathematical purity? > > Because that's the only sane way to avoid ugly surprises. An operator== returning true for two different object is a surprise to me. In that respect I believe returning false is what will lead to less surprise. > > This ensure we have the most useless operator==. > > > > Most of the code use it for stuff like that: > > void setFoo(const QVariant &foo) { > > > > if (foo != m_foo) { > > > > m_foo = foo; > > emit fooChanged(); > > > > } > > > > } > > That gives already "surprising" behaviour if fed with QChar('a') and > QString("a") in a row. > > And it is "surprising" to a degree that I'd call it buggy. That's another problem. And yes, I agree that this looks buggy. On the other hand, we also have have the same "42" == 42 in javascript, so it has some logic. > > And suddenly returning always true if the variant has the same type will > > break this code. And i think will break most use case for > > QVariant::operator== > Most of the uses of QVariant::operator==() ARE ALREADY BROKEN, and will > not be fixable if people refuse to accept basic requirements. What do you mean by broken? Do you mean the application misbehave. Or might misbehave? Because I would think currently most usage of QVariant produce an application that behave properly. (Even if admitively they may rely on the undefined behavior for memcmp) And if you change to always return true, these application will misbehave. Note: you can see all use of QVariant::operator== in Qt: https://code.woboq.org/data/symbol.html?root=../qt5/&ref=_ZNK8QVarianteqERKS_ [...] > > So let's be pragmatic here and do something usefull rather than something > > methematicaly correct, but useless and that break lot of code. > > This "pragmatism" has already led to the current situation where > the number of items in a QMap with QVariant keys depend on the > order of insertion and other crap. That's just a bug in the implementation. Of course Sune is right there. But that's again not the problem at hand. > > Now that we have C++11 and we can use some expression SFINAE, we can do > > > > something like: > > template > > auto registerEqualityOperator() > > > > -> decltype(std::declval() == std::declval()) > > > > Called from qRegisterMetaType, which automatically register the operator== > > if it exists. > > > > > > The QVariant::operator== could return false if none was registered. And > > possibly print a qWarning: "Attempting to compare two QVariant containing > > type 'Foo' which has no equality operation registered". > > That would be ok to, but does not invalidate my point. I said "return false", when you said we should return true. From Simon.Hausmann at qt.io Mon Sep 26 11:31:34 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 26 Sep 2016 09:31:34 +0000 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <2924212.X3JXzurJvh@tjmaciei-mobl1> References: <4898690.X1uOUlSLlE@42>,<2924212.X3JXzurJvh@tjmaciei-mobl1> Message-ID: Hi, I'm somewhat torn about the behavioral change. One the one hand it's the "correct" thing to do, on the other hand it does have the potential of breaking existing code. That said, this is not quite the same as changing the return type of a typed C++ function. QVariant is designed to hold any type and if you receive a QVariant it has always been a little dangerous to rely on specific conversion behavior (throughout Qt). Simon ________________________________ From: Development on behalf of Thiago Macieira Sent: Monday, September 26, 2016 9:37:07 AM To: development at qt-project.org Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null On segunda-feira, 26 de setembro de 2016 09:02:58 PDT Jędrzej Nowacki wrote: > On mandag 19. september 2016 11.14.51 CEST Chris Adams wrote: > > Hi, > > > > Recently, a few unit test failures[1] in the (unreleased) QtPIM module > > showed that the recent change[2] which changes the semantics of null > > assignment (from JS) to a QVariant Q_PROPERTY can affect existing client > > code. > > > > Certainly, the cases which are affected are most likely edge-cases (that > > is, specifically testing the type or value of the QVariant within C++ code > > to detect "null" assignment), however it is probably worth raising for > > discussion. > > > > Why was the change made? The commit message tells us what was changed, > > but > > not the reasoning behind the change. The unit tests were changed, so the > > behaviour change was clearly intentional (and the old behaviour considered > > problematic), and I assume that there must be very good reasons to make > > such a change, but it wasn't discussed on the mailing list, so I don't > > know > > what those reasons are. > > > > Best regards, > > Chris. > > > > [1] https://codereview.qt-project.org/#/c/170491/ > > [2] https://codereview.qt-project.org/#/c/167062/ > > > > > > www.qinetic.com.au - Qt And QML User Experience Specialists > > Hi, > > There are many reasons, mostly related to C++11 (in more or less > chronological order): > - 5.8 depends on C++11 that has null defined sensibly so we want to use it > to mark null values. > - std::nullptr_t became registered type which is meant to be use for null > values > - QJson support got better null handling (the feature was waiting for > std::nullptr_t in metatype) > - using (void*)0 for null in QVariant was suboptimal as it could not detect > invalid states like for example (void*)1 Those are the reasons that enabled the change, not a justification for why it is better (except the last one, which I don't agree; you can always check the value). Repeating Chris's question: is it worth the breakage on the user code? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Mon Sep 26 11:34:59 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 26 Sep 2016 09:34:59 +0000 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <329cc5fd-4ce8-3bad-2f45-53ea80bbbc87@qt.io>, Message-ID: Hi, I'm very much in favor of using a proper schema based system such as protocol buffers if we decide to remove the black box from serialization. They don't appear to be connected, but the moment you need to deal with changes in the format, the protobuf approach wins IMO. The other advantage is interoperability with the world outside of Qt. But this isn't so much a question of what to do, I I think it's more of a question of man power. Until then I'm in favor of QDataStream remaining a black box. Simon ________________________________ From: Development on behalf of Michael Winkelmann Sent: Monday, September 26, 2016 10:40:02 AM To: development at qt-project.org Subject: Re: [Development] QDataStream: blackbox or document all versions? I think what Qt is lacking is a good serialization module like cereal or boost serialization. With this pattern, QDataStream would be just another archive format, like JSON or XML. Cereal has portable and unportable binary for endianness. The developer should be able specify how the data is serialized and select an arbitrary archive type that takes streams operators as default serialization method. PS: For wire protocols, I would also consider Protobuf as an option. On 26.09.2016 10:11, Ulf Hermann wrote: > On 09/25/2016 05:58 AM, Thiago Macieira wrote: >> A thread[1] on the interest mailing list started when someone asked >> for the >> docs for the current format of the QDataStream wire protocol, to which I >> replied that it doesn't exist as we don't maintain such docs. >> >> Long story short, we have two options: [...] > > I see another option: Make QDataStream a good interchange format. > From your reply on the interest mailing list: > >> I also don't think the QDataStream binary format is particularly good >> for non- >> Qt purposes. It passes internals that are really about how Qt works, >> not meant >> for interchange of information. For example, QDate passes the Julian >> Day in >> 64-bit format -- who in the world exchanges data like that? One would >> expect >> the serialisation format of a date and time to be something like >> milliseconds >> since 1970, milliseconds since 1601 or a string format, like ISO >> 3337. It >> passes strings as UTF-16 encoded instead of encoding with UTF-8, >> which would >> in turn allow interchanging QString and QByteArray serialisation >> formats. >> >> It's also by default quite inefficient since it marshalls everything >> as big- >> endian, while most CPUs are little-endian. It has no support for >> indexing or >> random-access seeking. It can't be used as a DOM storage, like >> QJsonDocument >> can. > > All of that, except for the default endianness, could be fixed on a > per operator base. Changing the default endianness can also be done > with minimal effort and would only require incrementing the data > stream version. Considering this, QDataStream may at the moment not be > very efficient, but it does have some potential. We could probably > even change all the operators to read and write CBOR, and that would > also only require a version change. The versioning allows us to adapt > the wire format to whatever is needed now or in the future. I don't > know any other data interchange format which can do this. > > This doesn't change the implicit conversion problem that Marc > mentioned, but at the moment I don't quite see a way to fix it without > removing a lot of convenience for the user (that is, have the user > specify the exact intended type for each serialization operation). > > regards, > Ulf > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Mon Sep 26 11:38:22 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 26 Sep 2016 11:38:22 +0200 Subject: [Development] First Qt 5.8.0 Beta snapshot available In-Reply-To: <257493884.7506779.1474711296445@mail.yahoo.com> References: <257493884.7506779.1474711296445@mail.yahoo.com> Message-ID: <20160926093822.GD16265@troll08> On Sat, Sep 24, 2016 at 10:01:36AM +0000, Massimo Callegari via Development wrote: > macx:QT_CONFIG -= no-pkg-config > CONFIG += link_pkgconfig > PKGCONFIG += sndfile > > Has been working on every 5.x release, but not on 5.8.0. > yes, the mechanism has changed. QT_CONFIG was never a user-writable variable, so you can't really complain. why didn't you just make the CONFIG addition conditional? From giuseppe.dangelo at kdab.com Mon Sep 26 11:38:42 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 26 Sep 2016 11:38:42 +0200 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <4148392.zjhzp35ijF@tjmaciei-mobl1> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: Il 25/09/2016 05:58, Thiago Macieira ha scritto: > > Option 2: the opposite, saying that reading QDataStream's output is fine from > non-Qt code and it's fine to write data that QDataStream should read. This > means extending the documentation to cover ALL 17 wire formats (including > bugs) and keeping it up to date whenever someone modifies the format. > > > I am in favour of Option 1 because I really don't think QDataStream is a good > format for exchanging data with non-Qt code. It's designed first and foremost > for Qt's own internal data formats (sometimes even depending on internal > details), the marshalling of certain types in certain versions is buggy and > lossy. Instead, people should find a better transport format for their data, of > which we already have in Qt: For the record, I'm for option 2, as I don't think it poses a huge burden (apart from an initial task to add older protocol versions to it, then it's just a matter of maintaining documentation, and we must do it anyhow). Plus, the mere existence of that page means that someone is relying on the binary format. That having being said, I agree that QDataStream hasn't got the best wire format or the best implementation, but this is totally orthogonal to the matter at hand. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From annulen at yandex.ru Mon Sep 26 11:48:18 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 26 Sep 2016 12:48:18 +0300 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <329cc5fd-4ce8-3bad-2f45-53ea80bbbc87@qt.io>, Message-ID: <1336651474883298@web8m.yandex.ru> 26.09.2016, 12:35, "Simon Hausmann" : > Hi, > > I'm very much in favor of using a proper schema based system such as protocol buffers if we decide > > to remove the black box from serialization. They don't appear to be connected, but the moment you > > need to deal with changes in the format, the protobuf approach wins IMO. The other advantage is interoperability > > with the world outside of Qt. Protobuf itself is kinda outdated format, there are a lot of newer alternatives which incur much lower overhead. But it certainly has advantage of wider interoperability. > > But this isn't so much a question of what to do, I I think it's more of a question of man power. Until then I'm in favor > > of QDataStream remaining a black box. > > Simon > ---------------------------------------- > From: Development on behalf of Michael Winkelmann > Sent: Monday, September 26, 2016 10:40:02 AM > To: development at qt-project.org > Subject: Re: [Development] QDataStream: blackbox or document all versions? > > I think what Qt is lacking is a good serialization module like cereal or > boost serialization. > With this pattern, QDataStream would be just another archive format, > like JSON or XML. > Cereal has portable and unportable binary for endianness. > > The developer should be able specify how the data is serialized and > select an arbitrary archive type that takes streams operators as default > serialization method. > > PS: For wire protocols, I would also consider Protobuf as an option. > > On 26.09.2016 10:11, Ulf Hermann wrote: >> On 09/25/2016 05:58 AM, Thiago Macieira wrote: >>> A thread[1] on the interest mailing list started when someone asked >>> for the >>> docs for the current format of the QDataStream wire protocol, to which I >>> replied that it doesn't exist as we don't maintain such docs. >>> >>> Long story short, we have two options: [...] >> >> I see another option: Make QDataStream a good interchange format. >> From your reply on the interest mailing list: >> >>> I also don't think the QDataStream binary format is particularly good >>> for non- >>> Qt purposes. It passes internals that are really about how Qt works, >>> not meant >>> for interchange of information. For example, QDate passes the Julian >>> Day in >>> 64-bit format -- who in the world exchanges data like that? One would >>> expect >>> the serialisation format of a date and time to be something like >>> milliseconds >>> since 1970, milliseconds since 1601 or a string format, like ISO >>> 3337. It >>> passes strings as UTF-16 encoded instead of encoding with UTF-8, >>> which would >>> in turn allow interchanging QString and QByteArray serialisation >>> formats. >>> >>> It's also by default quite inefficient since it marshalls everything >>> as big- >>> endian, while most CPUs are little-endian. It has no support for >>> indexing or >>> random-access seeking. It can't be used as a DOM storage, like >>> QJsonDocument >>> can. >> >> All of that, except for the default endianness, could be fixed on a >> per operator base. Changing the default endianness can also be done >> with minimal effort and would only require incrementing the data >> stream version. Considering this, QDataStream may at the moment not be >> very efficient, but it does have some potential. We could probably >> even change all the operators to read and write CBOR, and that would >> also only require a version change. The versioning allows us to adapt >> the wire format to whatever is needed now or in the future. I don't >> know any other data interchange format which can do this. >> >> This doesn't change the implicit conversion problem that Marc >> mentioned, but at the moment I don't quite see a way to fix it without >> removing a lot of convenience for the user (that is, have the user >> specify the exact intended type for each serialization operation). >> >> regards, >> Ulf >> >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From oswald.buddenhagen at qt.io Mon Sep 26 11:51:01 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 26 Sep 2016 11:51:01 +0200 Subject: [Development] HEADS-UP: Branching from '5.7' to '5.7.1' started In-Reply-To: <201609261013.02506.marc.mutz@kdab.com> References: <201609261013.02506.marc.mutz@kdab.com> Message-ID: <20160926095101.GE16265@troll08> On Mon, Sep 26, 2016 at 10:13:02AM +0200, Marc Mutz wrote: > What am I missing? > the preceding discussions on these lists. From rich at kde.org Mon Sep 26 11:53:51 2016 From: rich at kde.org (Richard Moore) Date: Mon, 26 Sep 2016 10:53:51 +0100 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: On 26 September 2016 at 10:38, Giuseppe D'Angelo wrote: > Il 25/09/2016 05:58, Thiago Macieira ha scritto: > anyhow). Plus, the mere existence of that page means that someone is > relying on the binary format. > ​IIRC it was added to allow DCOP to be used in non-Qt contexts. Rich.​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Mon Sep 26 12:29:07 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 26 Sep 2016 10:29:07 +0000 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <329cc5fd-4ce8-3bad-2f45-53ea80bbbc87@qt.io>, Message-ID: On Sep 26, 2016, at 11:34, Simon Hausmann > wrote: Hi, I'm very much in favor of using a proper schema based system such as protocol buffers if we decide to remove the black box from serialization. They don't appear to be connected, but the moment you need to deal with changes in the format, the protobuf approach wins IMO. The other advantage is interoperability with the world outside of Qt. There are many alternatives to protocol buffers, some of them faster and/or more compressed. https://capnproto.org/ claims to be a really good one, for example. It has an MIT license. Zero-copy is a nice feature to have. After what I read, I’d probably never choose to use protocol buffers if it can be avoided. You have to use the code generator, and it’s not efficient. But I never tried, either. Being able to mmap the file and immediately treat it as the data structure that you really wanted is a nice feature to have; that kind of implementation is not necessarily the same thing as a serialization protocol, although the ideal serialization protocol could be designed so that you can deal with it either way. Doesn’t fit the QDataStream API, anyway. Wikipedia has a comparison: https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats There are even several that claim to be both binary and human-readable. i always thought that a binary format which doesn’t require a schema, uses tags like XML, but can represent the common data types natively (various types of numbers, bools, enums, opaque byte arrays, and strings) and for which a tool is available to format it to be human-readable ought to be better than things like XML and JSON. An early example is wbxml: WAP Binary XML (but it doesn’t have any representation for floating-point numbers AFAICT). I also wrote one which uses a string table for the tags, and binary representation for the tree structure and the data. But then I realized maybe I should have designed it for mmapping rather than only for bytewise streaming. But doing alignment wastes some space. If you like schemas or IDL, there’s the DDS serialization protocol. We’ve already tossed around the idea of having a Qt DDS wrapper because it would be useful in certain known industries. But it requires more structure and discipline compared to tag-based formats. It resembles CORBA because it comes from OMG. Like CORBA, it’s not worth the effort for rapid prototyping, only for larger-scale projects where the need for robustness outweighs the need to have a short development effort. QDataStream is just a sequence - you have to know what to expect when you are deserializing, rather than checking tag names or using a schema. Unless you just have a convention that the stream will consist of alternating tags and values. Is it actually that useful? Maybe we should deprecate it and come up with something better? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan.vatra at kdab.com Mon Sep 26 13:22:25 2016 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Mon, 26 Sep 2016 14:22:25 +0300 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <4148392.zjhzp35ijF@tjmaciei-mobl1> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: <4339499.BZrjm6p0JF@zmeu> Hi, What about Option 3 :) ? Use another binary format for serialization: flatbuffers [1] which is super fast, has a stable binary format and can be used by lots of other languages [2]. Cheers, BogDan. P.S. On my personal fork [3] I even added Qt support, and it can be used from QML as well ;-) [1] http://google.github.io/flatbuffers/ [2] http://google.github.io/flatbuffers/flatbuffers_support.html [3] https://github.com/bog-dan-ro/flatbuffers On sâmbătă, 24 septembrie 2016 20:58:38 EEST Thiago Macieira wrote: > A thread[1] on the interest mailing list started when someone asked for the > docs for the current format of the QDataStream wire protocol, to which I > replied that it doesn't exist as we don't maintain such docs. > > Long story short, we have two options: > > Option 1: claim QDataStream is a blackbox and tell people that the only > thing that can read QDataStream is QDataStream. That means removing the > documentation file src/corelib/doc/src/datastreamformat.qdoc, as we don't > want people getting any ideas that they could write their own decoders or > encoders. > > Option 2: the opposite, saying that reading QDataStream's output is fine > from non-Qt code and it's fine to write data that QDataStream should read. > This means extending the documentation to cover ALL 17 wire formats > (including bugs) and keeping it up to date whenever someone modifies the > format. > > > I am in favour of Option 1 because I really don't think QDataStream is a > good format for exchanging data with non-Qt code. It's designed first and > foremost for Qt's own internal data formats (sometimes even depending on > internal details), the marshalling of certain types in certain versions is > buggy and lossy. Instead, people should find a better transport format for > their data, of which we already have in Qt: > > XML > JSON > D-Bus > QSettings (to an extent) > > And I can add CBOR support if we want to. > > [1] > http://lists.qt-project.org/pipermail/interest/2016-September/024387.html From annulen at yandex.ru Mon Sep 26 13:47:17 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 26 Sep 2016 14:47:17 +0300 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <329cc5fd-4ce8-3bad-2f45-53ea80bbbc87@qt.io>, Message-ID: <22401474890437@web15o.yandex.ru> 26.09.2016, 13:29, "Shawn Rutledge" : > On Sep 26, 2016, at 11:34, Simon Hausmann wrote: > >> Hi, >> >> I'm very much in favor of using a proper schema based system such as protocol buffers if we decide >> to remove the black box from serialization. They don't appear to be connected, but the moment you >> need to deal with changes in the format, the protobuf approach wins IMO. The other advantage is interoperability >> with the world outside of Qt. > > There are many alternatives to protocol buffers, some of them faster and/or more compressed.  https://capnproto.org/ claims to be a really good one, for example.  It has an MIT license.  Zero-copy is a nice feature to have.  After what I read, I’d probably never choose to use protocol buffers if it can be avoided.  You have to use the code generator, and it’s not efficient.  But I never tried, either. Note that you probably won't probably be able to get zero-copy for Qt types, as canonical use of Cap'n'Proto assumes that you use Cap'n'Proto data types for encoded data. Though it still should be more efficient that protobuf as it doesn't require you to convert data to std containers and then back, and you'll probably be able to take more shortcuts when constructing Qt types from "zero-copy" Cap'n'Proto types. > > Being able to mmap the file and immediately treat it as the data structure that you really wanted is a nice feature to have; that kind of implementation is not necessarily the same thing as a serialization protocol, although the ideal serialization protocol could be designed so that you can deal with it either way.  Doesn’t fit the QDataStream API, anyway. > > Wikipedia has a comparison:  https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats > > There are even several that claim to be both binary and human-readable.  i always thought that a binary format which doesn’t require a schema, uses tags like XML, but can represent the common data types natively (various types of numbers, bools, enums, opaque byte arrays, and strings) and for which a tool is available to format it to be human-readable ought to be better than things like XML and JSON.  An early example is wbxml: WAP Binary XML (but it doesn’t have any representation for floating-point numbers AFAICT).  I also wrote one which uses a string table for the tags, and binary representation for the tree structure and the data.  But then I realized maybe I should have designed it for mmapping rather than only for bytewise streaming.  But doing alignment wastes some space. > > If you like schemas or IDL, there’s the DDS serialization protocol.  We’ve already tossed around the idea of having a Qt DDS wrapper because it would be useful in certain known industries.  But it requires more structure and discipline compared to tag-based formats.  It resembles CORBA because it comes from OMG.  Like CORBA, it’s not worth the effort for rapid prototyping, only for larger-scale projects where the need for robustness outweighs the need to have a short development effort. > > QDataStream is just a sequence - you have to know what to expect when you are deserializing, rather than checking tag names or using a schema.  Unless you just have a convention that the stream will consist of alternating tags and values. > > Is it actually that useful?  Maybe we should deprecate it and come up with something better? > > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From bstottle at ford.com Mon Sep 26 14:00:46 2016 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Mon, 26 Sep 2016 12:00:46 +0000 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <4148392.zjhzp35ijF@tjmaciei-mobl1> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: <72C432BA-A0EA-476A-B878-F0C74618AEA6@ford.com> On 9/24/16, 11:58 PM, "Development on behalf of Thiago Macieira" wrote: >A thread[1] on the interest mailing list started when someone asked for the >docs for the current format of the QDataStream wire protocol, to which I >replied that it doesn't exist as we don't maintain such docs. Not really sure which reply to respond to with my thoughts, so I’m going back to the beginning. When you talk about documenting QDataStream, you are talking about using it with IPC, either to other processes on the same machine or different devices. What you care about depends very much on what you are trying to do, which brings up the question of what should Qt support. Questions off the top of my head: Which types are supported? What errors are checked/caught? Are they concerned with speed? Speed on which platform? Or are they concerned with packet size? Which languages are supported? Which types? I’m going to assume that when Thiago talks about documenting QDataStream, he is talking about the operators in qtbase only? That is, all of the custom QDataStream operators in other modules, whether they get an internal index or not? Or is it every internal type, not matter which module? I guess I should ask, rather than assume. As I understand it, Qt stores an internal list of known types, each with an index. When data is written, the index is written first, then the element itself, in whatever format. Custom types won’t have an index by default, so if you pass one of those, QDataStream sends the name as well, and I’d assume, a size. Even if the type has the data stream operator in both processes (or on both devices), it likely won’t be the same index, thus the name provides the way to look up the index. I think we should assume that people will want to pass custom types, which means there needs to be a documented way to describe them. You know people will want to pass Q_ENUM values, right? Hopefully the question of custom types is valid, even if my attempted description of the internals is faulty. For all of the other questions. Different answers would likely favor different protocols. There simply isn’t one best answer. If we selected a specific use-case, there may be a best answer for that, but is that the best solution for Qt? For my part, I’m very interested in this discussion. Thiago’s point that JSON/DBus/etc provide alternatives to QDataStream is correct, but isn’t great for my use case. As a user (and developer of) Qt Remote Objects[1], communication is between Qt and Qt, so it uses QDataStream. To be able to also support interaction with non-Qt processes would great, but only if it can re-use the QDataStream. I’m just not interested in the overhead (work and processing) of other formats when the focus is Qt. My ideal option (specific to the use-case I care most about) would be a documented QDataStream format that supported one-time passing of custom type information (rather than passing each instance of a type), with minimal overhead on embedded targets and enough information to ignore unknown types. [1] https://codereview.qt-project.org/p/playground/qtremoteobjects.git From massimocallegari at yahoo.it Mon Sep 26 14:18:49 2016 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Mon, 26 Sep 2016 12:18:49 +0000 (UTC) Subject: [Development] First Qt 5.8.0 Beta snapshot available In-Reply-To: <20160926093822.GD16265@troll08> References: <257493884.7506779.1474711296445@mail.yahoo.com> <20160926093822.GD16265@troll08> Message-ID: <1840073921.9165061.1474892329695@mail.yahoo.com> Da: Oswald Buddenhagen A: development at qt-project.org Inviato: Lunedì 26 Settembre 2016 11:38 Oggetto: Re: [Development] First Qt 5.8.0 Beta snapshot available >> On Sat, Sep 24, 2016 at 10:01:36AM +0000, Massimo Callegari via Development wrote: >> macx:QT_CONFIG -= no-pkg-config >> CONFIG += link_pkgconfig >> PKGCONFIG += sndfile >> > Has been working on every 5.x release, but not on 5.8.0. >> > yes, the mechanism has changed. QT_CONFIG was never a user-writable > variable, so you can't really complain. Sorry if I gave you the impression of being complaining, but I'm not. I only reported an issue that I experienced and I am looking for a solution to it. After all, isn't it what alphas and betas are for ? By the way I changed QT_CONFIG because of this: http://stackoverflow.com/questions/16972066/using-pkg-config-with-qt-creator-qmake-on-mac-osx > why didn't you just make the CONFIG addition conditional? Because it doesn't hurt the other 4 platforms I'm building on and by the way even if I did, it doesn't solve the pkg-config problem of 5.8.0 on MacOS. Anyway I created QTBUG-56164 so let's please discuss there in case From jedrzej.nowacki at qt.io Mon Sep 26 15:40:20 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 26 Sep 2016 15:40:20 +0200 Subject: [Development] Module maintainers: action required (Coin migrates from sync.profile to .gitmodules on 28.09.2016) In-Reply-To: <1812257.QvtQHO20lV@42> References: <2756158.WOgs6TtE6b@42> <16176940.ZuU55maq73@42> <1812257.QvtQHO20lV@42> Message-ID: <18001555.Lp55u9ybnk@42> On tirsdag 13. september 2016 08.25.10 CEST Jędrzej Nowacki wrote: > On fredag 19. august 2016 08.52.59 CEST Jędrzej Nowacki wrote: > > On torsdag 18. august 2016 17.46.41 CEST Dominik Holland wrote: > > > How are the dependencies managed for projects/modules which are not part > > > of the qt5.git but are part of coin ? > > > > > > Dominik > > > > That is the reason of migrating "slowly". We need to define/find a product > > repository for them. Such super repository would define testing platforms, > > configurations and dependencies configurations. For experimental modules > > and in general, playground I would propose to create "qt-labs" product. > > Cheers, > > > > Jędrek > > Hi, > > In addition to what I said before "product less" modules, which we should > not have, by default will depend on all Qt5 modules, so we can test them > anyway. > > Cheers, > Jędrek > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Hi, Friendly reminder about dropping support for sync.profile in favor of .gitmodules. The new code will be deployed on on Wednesday (28.09.2016) unless I will find some major breakages to that point. Cheers, Jędrek From edward.welbourne at qt.io Mon Sep 26 17:47:42 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 26 Sep 2016 15:47:42 +0000 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <20160923181747.GC3571@klara.mpi.htwm.de> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <25f020ab-90db-7b57-4e90-d3fe9e4bddd1@taschenorakel.de> <20160922205809.GA3451@klara.mpi.htwm.de> <3657161.2RyX6fn9fR@maurice> , <20160923181747.GC3571@klara.mpi.htwm.de> Message-ID: On Fri, Sep 23, 2016 at 09:56:30AM +0000, Edward Welbourne wrote: >> Indeed; having all values of some type equivalent is worse (for the "has >> my value changed" test you illustrate, at least) than having a value not >> equal to itself (which triggers a "changed" event for a non-change). In >> fact one can have one's mathematical purity by attacking the "for all x" >> part of the above instead of the "x == x" part. Although it's usual to >> talk about "a relation is reflexive on S if, for all s in S, it relates >> s to s" André Pönitz replied: > Right. That's pretty much the definition the known universe uses: > https://en.wikipedia.org/wiki/Reflexive_relation > (and no, *I* didn't put it there) Like I say, that's the usual definition. The interesting thing that tends to get lost as a result is that the only part it actually adds to the definition of an equivalence is the "for all s in S" part since, when a symmetric transitive relation relates x to y it also relates (by symmetry) y to x and thus (by transitivity) x via y to x and y via x to y. So a symmetric transitive relation is already reflexive *on its set of values* - and the usual definition of equivalence only *needs* the usual definition of reflexive as a way to say *and every member of S is a value of the relation*; the "relates each to self" part is already taken care of. Hence my attack on the "for all x" side. >> one can equally define reflexive by "whenever the relation >> relates any x to y, it also relates x to x and y to y". >> (This is the >> more natural formulation in a mathematics based on relations [*] rather >> than sets.) >> >> [*] http://www.chaos.org.uk/~eddy/maths/found/relate.xhtml#Types >> >> With that formulation (which doesn't tie the relation to a set that it's >> "on"), returning false for the types that don't support equality >> comparison works; we won't consider any value of such a type equal to >> *anything*, so our relation isn't required to relate them to themselves. >> We are then left with QVariant::operator== being a relation formally on >> only those QVariants that support comparison, not on all QVariants >> (although it tolerates being asked about the values it doesn't relate to >> anything; it just says no about them). > How does that help with QHash which needs comparsion of the > keys? It makes clear what the problem is - you can't sensibly use a value as a key in a hash if it doesn't compare equal to itself. Your problem isn't that you need x == x, it's that you need it for all QVariants and it isn't a sensible thing to ask for among all QVariants, because some of them don't know *how to ask whether* x == x. You can't sensibly do comparison on the values of types for which no operator== is registered, so you can't sensibly make a hash that has them as keys. So if you want QHash you have to either live with the same kind of brokenness that several contributors to this discussion (from both camps) have described for equality or you have to live with your hash refusing to tolerate keys of types (within QVariant) that don't support equality comparison. After all, when you come to look up an entry in your hash, you do need to do a comparison (once you've found the right hash bucket to look in), to check you haven't just got a hash collision - right ? So if you can't do comparisons sensibly with values of some type (that you've wrapped in QVariant), then you can't sensibly use those values as keys in a hash. >> It's not ideal (and the justification is heterodox) but false is a valid >> answer for the incomparable values, > This is a nonsensical line of argument long as you try to use it to counter > "unexpected" results. I'm not trying to use it to counter unexpected results. I'm trying to tell you that you should expect perverse results and not implement APIs whose sanity depends on sensible behaviour from a "solution" to an ill-posed problem. > With your "uncomparable things compare false" approach QHash<>::contains() > will never return true for uncomparable QVariants, i.e. code like > > void doSomethingOnlyOncePerValue(QVariant v) > { > static QHash seen; > if (seen.contains(v)) > return; > seen.insert(v, 0); For reference, I think QHash::insert(K key, ...) should start by checking key == key; if that fails, refuse to insert. > doSomething(v); > } > > will be quite surprising, too. *Any* resolution of the problem will present surprises, if we allow QHash to use keys for which we don't know how to do comparison. If QHash has no way to reject such keys, then supporting QVariant as a key type is *inescapably* problematic. A hash needs a comparison relation that it can use on its keys that is an equivalence and for which each value offered as a key is equal to itself; so either you need your QHash to actually have a key-type that's a proper sub-type of QVariant ("return false;", excluding sub-types for which we have no registered operator==) or you have to treat all values of each incomparable sub-type as if they were equal ("return true;"). Either shall have its defects and produce perverse behaviour. When you are faced with evidence the hole you're digging is just going to engulf you, it tends to be a smart move to stop and ask why you're still digging the hole and whether there's something better you could be doing instead. Eddy. From thiago.macieira at intel.com Mon Sep 26 19:57:30 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Sep 2016 10:57:30 -0700 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <329cc5fd-4ce8-3bad-2f45-53ea80bbbc87@qt.io> Message-ID: <2875658.Btt7qjvCm4@tjmaciei-mobl1> On segunda-feira, 26 de setembro de 2016 10:40:02 PDT Michael Winkelmann wrote: > I think what Qt is lacking is a good serialization module like cereal or > boost serialization. > With this pattern, QDataStream would be just another archive format, > like JSON or XML. > Cereal has portable and unportable binary for endianness. Having worked with Cereal on another project, I don't think that's a good approach. Serialising to different protocols and formats is not something that can be properly abstracted. Not if you want to produce a schema that the other side expects. If you're going to serialise something that only you will read, then QDataStream is already sufficient. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Sep 26 20:03:53 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Sep 2016 11:03:53 -0700 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: <2177978.gzZXisrr4i@tjmaciei-mobl1> On segunda-feira, 26 de setembro de 2016 10:29:07 PDT Shawn Rutledge wrote: > On Sep 26, 2016, at 11:34, Simon Hausmann > > wrote: > > Hi, > > I'm very much in favor of using a proper schema based system such as > protocol buffers if we decide to remove the black box from serialization. > They don't appear to be connected, but the moment you need to deal with > changes in the format, the protobuf approach wins IMO. The other advantage > is interoperability with the world outside of Qt. Interoperability would be a plus, indeed. But if you want Protobuf, why not use Protobuf? Why do you need QDataStream to do it? > There are many alternatives to protocol buffers, some of them faster and/or > more compressed. https://capnproto.org/ claims to be a really good one, > for example. It has an MIT license. Zero-copy is a nice feature to have. > After what I read, I’d probably never choose to use protocol buffers if it > can be avoided. You have to use the code generator, and it’s not > efficient. But I never tried, either. Zero-copy is useless for Qt due to the way our strings are stored in memory anyway (UTF-16 host-endian) and due to our implicit sharing. If I were to choose and implement this, I'd choose CBOR for these reasons: * I personally already know the format * I maintain a library to encode and decode it (whose unit tests are written with QtTest) * it's in an RFC (7049), which none other besides JSON is * it's got its own MIME type (application/cbor) and CoAP content-format (60) > Being able to mmap the file and immediately treat it as the data structure > that you really wanted is a nice feature to have; that kind of > implementation is not necessarily the same thing as a serialization > protocol, although the ideal serialization protocol could be designed so > that you can deal with it either way. Doesn’t fit the QDataStream API, > anyway. Again, not so useful to us. If we need that, we already have one: the QJsonDocument binary format. If we need another, I'd recommend the dconf format, which is the same as the D-Bus wire format plus indexing, is already very much in use in Linux and has a Qt implementation already written. And as you said, mmap() ability is usually at odds with streaming. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Sep 26 20:07:28 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Sep 2016 11:07:28 -0700 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: <2134024.xtiSlN0hij@tjmaciei-mobl1> On segunda-feira, 26 de setembro de 2016 10:53:51 PDT Richard Moore wrote: > On 26 September 2016 at 10:38, Giuseppe D'Angelo > wrote: > > Il 25/09/2016 05:58, Thiago Macieira ha scritto: > > anyhow). Plus, the mere existence of that page means that someone is > > relying on the binary format. > > ​IIRC it was added to allow DCOP to be used in non-Qt contexts. Makes sense, but then it should have stayed the Qt 3.3 documentation (or 3.0?) and not updated. DCOP had a fixed QDataStream version number. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Sep 26 20:13:21 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Sep 2016 11:13:21 -0700 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <72C432BA-A0EA-476A-B878-F0C74618AEA6@ford.com> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <72C432BA-A0EA-476A-B878-F0C74618AEA6@ford.com> Message-ID: <4291001.8xfk0VHShv@tjmaciei-mobl1> On segunda-feira, 26 de setembro de 2016 12:00:46 PDT Stottlemyer, Brett (B.S.) wrote: > Not really sure which reply to respond to with my thoughts, so I’m going > back to the beginning. > When you talk about documenting QDataStream, you are talking about using it > with IPC, either to other processes on the same machine or different > devices. What you care about depends very much on what you are trying to > do, which brings up the question of what should Qt support. Questions off > the top of my head: Which types are supported? What errors are > checked/caught? Are they concerned with speed? Speed on which platform? > Or are they concerned with packet size? Which languages are supported? Good questions all of them. Right now, QDataStream does not catch errors, is not very speedy (big endian by default), is more concerned for easy marshalling and demarshalling of Qt types rather than compatibility or packet size. > Which types? > I’m going to assume that when Thiago talks about documenting QDataStream, he > is talking about the operators in qtbase only? That is, all of the custom > QDataStream operators in other modules, whether they get an internal index > or not? Or is it every internal type, not matter which module? I guess I > should ask, rather than assume. As I understand it, Qt stores an internal > list of known types, each with an index. When data is written, the index > is written first, then the element itself, in whatever format. Custom > types won’t have an index by default, so if you pass one of those, > QDataStream sends the name as well, and I’d assume, a size. Even if the > type has the data stream operator in both processes (or on both devices), > it likely won’t be the same index, thus the name provides the way to look > up the index. You're describing how QVariant's operator<< works. Outside of QVariant, there's no type index: the data is written as-is, no prefix, no header. You can write one quint32 and read two quint16. You can even write one QString and read a quint32 (then throw away the data). > I think we should assume that people will want to pass custom types, which > means there needs to be a documented way to describe them. You know people > will want to pass Q_ENUM values, right? They write their operator<< and operator>>. That's all. > For my part, I’m very interested in this discussion. Thiago’s point that > JSON/DBus/etc provide alternatives to QDataStream is correct, but isn’t > great for my use case. As a user (and developer of) Qt Remote Objects[1], > communication is between Qt and Qt, so it uses QDataStream. To be able to > also support interaction with non-Qt processes would great, but only if it > can re-use the QDataStream. I’m just not interested in the overhead (work > and processing) of other formats when the focus is Qt. Ok, this is a good point. Just like Rich mentioned for DCOP, we'd need to document at least one QDataStream version for Qt Remote Objects to be usable with non-Qt implementations. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Sep 26 20:14:58 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Sep 2016 11:14:58 -0700 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: References: <2924212.X3JXzurJvh@tjmaciei-mobl1> Message-ID: <2072786.6ck3geAJBJ@tjmaciei-mobl1> On segunda-feira, 26 de setembro de 2016 09:31:34 PDT Simon Hausmann wrote: > That said, this is not quite the same as changing the return type of a typed > C++ function. QVariant is designed > to hold any type and if you receive a QVariant it has always been a little > dangerous to rely on specific conversion > behavior (throughout Qt). Only if you didn't make the type part of your API, which is what QML had done. See the failures: https://codereview.qt-project.org/170491 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Sep 26 20:29:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Sep 2016 11:29:01 -0700 Subject: [Development] Should QVariant be doing fuzzy comparisons on doubles? In-Reply-To: <1519980.lLWlKfCS63@42> References: <2037719.HAYudMlsJZ@tjmaciei-mobl1> <1519980.lLWlKfCS63@42> Message-ID: <6353195.IqjP0PGHxR@tjmaciei-mobl1> On segunda-feira, 26 de setembro de 2016 09:57:27 PDT Jędrzej Nowacki wrote: > No. I think we should avoid it, there are to many side effects of such > behavior change. Ok, I will restore the original patch that keeps the fuzzy comparison, just skips it for NaN and infinite. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Sep 26 20:32:47 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Sep 2016 11:32:47 -0700 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: <532131474875591@web15o.yandex.ru> References: <4148392.zjhzp35ijF@tjmaciei-mobl1> <6631959.9ikJTaXOS7@tjmaciei-mobl1> <532131474875591@web15o.yandex.ru> Message-ID: <4149456.pOvhFZOqo7@tjmaciei-mobl1> On segunda-feira, 26 de setembro de 2016 10:39:51 PDT Konstantin Tokarev wrote: > 26.09.2016, 10:15, "Thiago Macieira" : > > On segunda-feira, 26 de setembro de 2016 00:42:12 PDT Konstantin Tokarev > > > > wrote: > >> Option 3: restore documentation of version 12 and declare that it's the > >> only format version that is meant for use with 3rd party encoders and > >> decoders.> > > Why 12? It can't transmit QDateTime timezones. > > Just because it is already documented, so no extra work is needed. Version 13 is documented: http://doc.qt.io/qt-5/datastreamformat.html -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Sep 26 21:51:36 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Sep 2016 12:51:36 -0700 Subject: [Development] First Qt 5.8.0 Beta snapshot available In-Reply-To: References: <9287709.tjZBdVE0Nn@tjmaciei-mobl1> Message-ID: <2577748.vFgvtHVBi3@tjmaciei-mobl1> On segunda-feira, 26 de setembro de 2016 09:03:12 PDT Jani Heikkinen wrote: > Arg, some error when copying submodule src packages. New try ongoing, should > be there later today Thanks. I've now attempted a build on my Mac to check if the issue I've been having was related to my sources or not. It's not. 5.8 beta has a Failure To Build From Sources. Reported as https://bugreports.qt.io/browse/QTBUG-56193 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From edward.welbourne at qt.io Tue Sep 27 10:20:09 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 27 Sep 2016 08:20:09 +0000 Subject: [Development] Module maintainers: action required (Coin migrates from sync.profile to .gitmodules on 28.09.2016) In-Reply-To: <18001555.Lp55u9ybnk@42> References: <2756158.WOgs6TtE6b@42> <16176940.ZuU55maq73@42> <1812257.QvtQHO20lV@42>,<18001555.Lp55u9ybnk@42> Message-ID: Jędrek said: > Friendly reminder about dropping support for sync.profile in favor of > .gitmodules. The new code will be deployed on on Wednesday (28.09.2016) unless > I will find some major breakages to that point. ... and, just to avoid any confusion, that's only the dependencies between modules used by COIN that'll stop looking at sync.profile; header generation by syncqt.pl continues to use sync.profile as ever ... Eddy. From Simon.Hausmann at qt.io Tue Sep 27 13:25:49 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 27 Sep 2016 11:25:49 +0000 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <2072786.6ck3geAJBJ@tjmaciei-mobl1> References: <2924212.X3JXzurJvh@tjmaciei-mobl1> , <2072786.6ck3geAJBJ@tjmaciei-mobl1> Message-ID: Hi, That is exactly the part I'm referring to. Receiving a QVariant from the QML engine and relying on it to contain a specific type. Simon ________________________________ From: Thiago Macieira Sent: Monday, September 26, 2016 8:14:58 PM To: development at qt-project.org Cc: Simon Hausmann Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null On segunda-feira, 26 de setembro de 2016 09:31:34 PDT Simon Hausmann wrote: > That said, this is not quite the same as changing the return type of a typed > C++ function. QVariant is designed > to hold any type and if you receive a QVariant it has always been a little > dangerous to rely on specific conversion > behavior (throughout Qt). Only if you didn't make the type part of your API, which is what QML had done. See the failures: https://codereview.qt-project.org/170491 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Sep 27 17:04:56 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 27 Sep 2016 08:04:56 -0700 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: References: <2072786.6ck3geAJBJ@tjmaciei-mobl1> Message-ID: <3740848.Dqj7CzAFDH@tjmaciei-mobl1> On terça-feira, 27 de setembro de 2016 11:25:49 PDT Simon Hausmann wrote: > That is exactly the part I'm referring to. Receiving a QVariant from the QML > engine and relying on it to contain a specific type. Well, I would say it's acceptable that the QVariant contain different numeric types as the engine changes. Maybe you originally only had double and now you have double and int. That would be an acceptable behaviour change. Changing from void* to nullptr is unexpected, but it does fall into the same bucket. The problem is that you can't write code to adapt to it without #ifdef, so there's no way to write forward compatibility. Can we compromise and you delay this change for one release? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Tue Sep 27 17:29:16 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 27 Sep 2016 15:29:16 +0000 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <3740848.Dqj7CzAFDH@tjmaciei-mobl1> References: <2072786.6ck3geAJBJ@tjmaciei-mobl1> , <3740848.Dqj7CzAFDH@tjmaciei-mobl1> Message-ID: Hi, I'm personally fine with delaying this by one release. What do others think? That said, I think it can be written without #ifdef perhaps by using QVariant::isNull() ? (QVariant(nullptr) maps to isNull() as well, right? ;-) Simon ________________________________ From: Development on behalf of Thiago Macieira Sent: Tuesday, September 27, 2016 5:04:56 PM To: development at qt-project.org Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null On terça-feira, 27 de setembro de 2016 11:25:49 PDT Simon Hausmann wrote: > That is exactly the part I'm referring to. Receiving a QVariant from the QML > engine and relying on it to contain a specific type. Well, I would say it's acceptable that the QVariant contain different numeric types as the engine changes. Maybe you originally only had double and now you have double and int. That would be an acceptable behaviour change. Changing from void* to nullptr is unexpected, but it does fall into the same bucket. The problem is that you can't write code to adapt to it without #ifdef, so there's no way to write forward compatibility. Can we compromise and you delay this change for one release? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Sep 27 18:31:14 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 27 Sep 2016 09:31:14 -0700 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: References: <3740848.Dqj7CzAFDH@tjmaciei-mobl1> Message-ID: <23538281.SpfXcHiqNk@tjmaciei-mobl1> On terça-feira, 27 de setembro de 2016 15:29:16 PDT Simon Hausmann wrote: > That said, I think it can be written without #ifdef perhaps by using > QVariant::isNull() ? > > > (QVariant(nullptr) maps to isNull() as well, right? ;-) It should. But QVariant(QString()) [after you bypass C++'s most vexing parse] also has isNull() == true. Does the QML engine ever generate those? Note that user code might. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From 83.manish at gmail.com Tue Sep 27 19:23:12 2016 From: 83.manish at gmail.com (manish sharma) Date: Tue, 27 Sep 2016 17:23:12 +0000 Subject: [Development] COIN Message-ID: Hi, I am working on a project which consists of around 20 git submodules and we use jenkins as our CI. I was searching for an alternative to manage builds and I came across COIN scripts which qt uses to run its CI. And it perfectly suits our requirement especially dependency resolver and storage. http://testresults.qt.io/coin/doc/overview.html I search over google and checked code.qt.io/cgit/ but could not find COIN scripts. Is it public domain? Let me know if someone knows the repo link. Thanks, Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Sep 27 19:26:09 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 27 Sep 2016 10:26:09 -0700 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <23538281.SpfXcHiqNk@tjmaciei-mobl1> References: <23538281.SpfXcHiqNk@tjmaciei-mobl1> Message-ID: <4541839.luIDPdY38A@tjmaciei-mobl1> On terça-feira, 27 de setembro de 2016 09:31:14 PDT Thiago Macieira wrote: > On terça-feira, 27 de setembro de 2016 15:29:16 PDT Simon Hausmann wrote: > > That said, I think it can be written without #ifdef perhaps by using > > QVariant::isNull() ? > > > > > > (QVariant(nullptr) maps to isNull() as well, right? ;-) > > It should. Actually, I'm not sure it should. QVariant's only pointer constructor is the one for const char*, which will be null if the pointer is null too. That would support the proposition that QVariant(nullptr).isNull() because QVariant((const char*)nullptr).isNull(). However, to create a VoidStar, you need to write: QVariant::fromValue(nullptr); which does return QVariant(qMetaTypeId(), &t, QTypeInfo::isPointer); That constructor always sets d.is_null = false. So the QVariant is not null, as it contains a valid VoidStar value. It just happens that the VoidStar itself is null. In other words, QVariant behaves like a non-null void** pointing to a null void*. What's more, it's very likely that your QML-created VoidStar also would report isNull() == false, so you can't write that for current code either to detect a null JSON value. Unless you created it with: QVariant(QMetaType::VoidStar); is that the case? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From cavendish.qi at gmail.com Tue Sep 27 19:27:07 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Tue, 27 Sep 2016 19:27:07 +0200 Subject: [Development] COIN In-Reply-To: References: Message-ID: On 27 September 2016 at 19:23, manish sharma <83.manish at gmail.com> wrote: > Hi, > > I am working on a project which consists of around 20 git submodules and > we use jenkins as our CI. I was searching for an alternative to manage > builds and I came across COIN scripts which qt uses to run its CI. And it > perfectly suits our requirement especially dependency resolver and storage. > > http://testresults.qt.io/coin/doc/overview.html > > I search over google and checked code.qt.io/cgit/ but could not find COIN > scripts. Is it public domain? Let me know if someone knows the repo link. > https://blog.qt.io/blog/2016/08/08/coin-continuous-integration-for-qt/ It's not in public domain yet. Regards, Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From 83.manish at gmail.com Tue Sep 27 19:51:09 2016 From: 83.manish at gmail.com (manish sharma) Date: Tue, 27 Sep 2016 17:51:09 +0000 Subject: [Development] COIN In-Reply-To: References: Message-ID: Thanks Liang, Regards, Manish On Tue, Sep 27, 2016 at 10:57 PM Liang Qi wrote: > On 27 September 2016 at 19:23, manish sharma <83.manish at gmail.com> wrote: > >> Hi, >> >> I am working on a project which consists of around 20 git submodules and >> we use jenkins as our CI. I was searching for an alternative to manage >> builds and I came across COIN scripts which qt uses to run its CI. And it >> perfectly suits our requirement especially dependency resolver and storage. >> >> http://testresults.qt.io/coin/doc/overview.html >> >> I search over google and checked code.qt.io/cgit/ but could not find >> COIN scripts. Is it public domain? Let me know if someone knows the repo >> link. >> > > https://blog.qt.io/blog/2016/08/08/coin-continuous-integration-for-qt/ > > It's not in public domain yet. > > Regards, > Liang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Tue Sep 27 20:22:34 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 27 Sep 2016 18:22:34 +0000 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <4541839.luIDPdY38A@tjmaciei-mobl1> References: <23538281.SpfXcHiqNk@tjmaciei-mobl1>, <4541839.luIDPdY38A@tjmaciei-mobl1> Message-ID: I'm fairly sure we used QVariant(QMetaType::VoidStar); Simon From: thiago.macieira at intel.com Sent: September 27, 2016 19:26 To: development at qt-project.org Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null On terça-feira, 27 de setembro de 2016 09:31:14 PDT Thiago Macieira wrote: > On terça-feira, 27 de setembro de 2016 15:29:16 PDT Simon Hausmann wrote: > > That said, I think it can be written without #ifdef perhaps by using > > QVariant::isNull() ? > > > > > > (QVariant(nullptr) maps to isNull() as well, right? ;-) > > It should. Actually, I'm not sure it should. QVariant's only pointer constructor is the one for const char*, which will be null if the pointer is null too. That would support the proposition that QVariant(nullptr).isNull() because QVariant((const char*)nullptr).isNull(). However, to create a VoidStar, you need to write: QVariant::fromValue(nullptr); which does return QVariant(qMetaTypeId(), &t, QTypeInfo::isPointer); That constructor always sets d.is_null = false. So the QVariant is not null, as it contains a valid VoidStar value. It just happens that the VoidStar itself is null. In other words, QVariant behaves like a non-null void** pointing to a null void*. What's more, it's very likely that your QML-created VoidStar also would report isNull() == false, so you can't write that for current code either to detect a null JSON value. Unless you created it with: QVariant(QMetaType::VoidStar); is that the case? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Sep 27 23:59:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 27 Sep 2016 14:59:50 -0700 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: References: <4541839.luIDPdY38A@tjmaciei-mobl1> Message-ID: <3154455.zo9t9GIjz4@tjmaciei-mobl1> On terça-feira, 27 de setembro de 2016 18:22:34 PDT Simon Hausmann wrote: > I'm fairly sure we used QVariant(QMetaType::VoidStar); Can you guarantee that the only time the QML engine generates null QVariants is for null JS Values? That is, no null QStrings, null QVariantLists, null QVariantMaps/Hahes, null doubles, etc.? If that's the case, I'd recommend a doc update and unit tests. Chris can fix his code for isNull(). Note: QVariant::fromValue(nullptr).isNull() == false QVariant(QMetaType::Nullptr).isNull() == true -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Sep 28 00:00:38 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 27 Sep 2016 15:00:38 -0700 Subject: [Development] COIN In-Reply-To: References: Message-ID: <3410788.syB8fVIkBF@tjmaciei-mobl1> On terça-feira, 27 de setembro de 2016 19:27:07 PDT Liang Qi wrote: > > I search over google and checked code.qt.io/cgit/ but could not find COIN > > scripts. Is it public domain? Let me know if someone knows the repo link. > > https://blog.qt.io/blog/2016/08/08/coin-continuous-integration-for-qt/ > > It's not in public domain yet. Note that public domain is not the same thing as open source. I would advise the COIN team against releasing it as public domain. Choose a suitable, open source licence for it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kde at carewolf.com Wed Sep 28 01:22:33 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Wed, 28 Sep 2016 01:22:33 +0200 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <3154455.zo9t9GIjz4@tjmaciei-mobl1> References: <3154455.zo9t9GIjz4@tjmaciei-mobl1> Message-ID: <201609280122.33505.kde@carewolf.com> On Tuesday 27 September 2016, Thiago Macieira wrote: > On terça-feira, 27 de setembro de 2016 18:22:34 PDT Simon Hausmann wrote: > > I'm fairly sure we used QVariant(QMetaType::VoidStar); > > Can you guarantee that the only time the QML engine generates null > QVariants is for null JS Values? That is, no null QStrings, null > QVariantLists, null QVariantMaps/Hahes, null doubles, etc.? > > If that's the case, I'd recommend a doc update and unit tests. Chris can > fix his code for isNull(). > > Note: > QVariant::fromValue(nullptr).isNull() == false > QVariant(QMetaType::Nullptr).isNull() == true And QVariant(nullptr) doesn't compile. We should probably fix the fromValue constructor. `Allan From Jake.Petroules at qt.io Wed Sep 28 02:22:14 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 28 Sep 2016 00:22:14 +0000 Subject: [Development] COIN In-Reply-To: <3410788.syB8fVIkBF@tjmaciei-mobl1> References: <3410788.syB8fVIkBF@tjmaciei-mobl1> Message-ID: <3EBA0DF0-909C-4309-A8DE-AE70279BA875@qt.io> > On Sep 27, 2016, at 3:00 PM, Thiago Macieira wrote: > > On terça-feira, 27 de setembro de 2016 19:27:07 PDT Liang Qi wrote: >>> I search over google and checked code.qt.io/cgit/ but could not find COIN >>> scripts. Is it public domain? Let me know if someone knows the repo link. >> >> https://blog.qt.io/blog/2016/08/08/coin-continuous-integration-for-qt/ >> >> It's not in public domain yet. > > Note that public domain is not the same thing as open source. I would advise > the COIN team against releasing it as public domain. Choose a suitable, open > source licence for it. "public domain" is different from "Public Domain"; I think all parties involved understood what was meant. Obviously we wouldn't be so uninformed as to release a project as Public Domain in lieu of a proper Open Source license. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From 83.manish at gmail.com Wed Sep 28 04:16:47 2016 From: 83.manish at gmail.com (manish sharma) Date: Wed, 28 Sep 2016 02:16:47 +0000 Subject: [Development] COIN In-Reply-To: <3EBA0DF0-909C-4309-A8DE-AE70279BA875@qt.io> References: <3410788.syB8fVIkBF@tjmaciei-mobl1> <3EBA0DF0-909C-4309-A8DE-AE70279BA875@qt.io> Message-ID: Thanks Thiago and Jake, When Coin is expected to be released? I was thinking if it is very close then we can continue using our current infrastructure, otherwise we will implement something similar to Coin. I found information about Coin on qt blog and testresults overview page very helpful. It gave me good understanding of the infrastructure. Thanks, Manish On Wed, Sep 28, 2016 at 5:52 AM Jake Petroules wrote: > > > On Sep 27, 2016, at 3:00 PM, Thiago Macieira > wrote: > > > > On terça-feira, 27 de setembro de 2016 19:27:07 PDT Liang Qi wrote: > >>> I search over google and checked code.qt.io/cgit/ but could not find > COIN > >>> scripts. Is it public domain? Let me know if someone knows the repo > link. > >> > >> https://blog.qt.io/blog/2016/08/08/coin-continuous-integration-for-qt/ > >> > >> It's not in public domain yet. > > > > Note that public domain is not the same thing as open source. I would > advise > > the COIN team against releasing it as public domain. Choose a suitable, > open > > source licence for it. > > "public domain" is different from "Public Domain"; I think all parties > involved understood what was meant. Obviously we wouldn't be so uninformed > as to release a project as Public Domain in lieu of a proper Open Source > license. > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Sep 28 07:29:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 27 Sep 2016 22:29:08 -0700 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <201609280122.33505.kde@carewolf.com> References: <3154455.zo9t9GIjz4@tjmaciei-mobl1> <201609280122.33505.kde@carewolf.com> Message-ID: <2690967.77ZNDzu0qx@tjmaciei-mobl1> On quarta-feira, 28 de setembro de 2016 01:22:33 PDT Allan Sandfeld Jensen wrote: > > QVariant::fromValue(nullptr).isNull() == false > > QVariant(QMetaType::Nullptr).isNull() == true > > And QVariant(nullptr) doesn't compile. > > We should probably fix the fromValue constructor. I don't think so. This is also false: QVariant::fromValue(nullptr).isNull() -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kde at carewolf.com Wed Sep 28 10:39:42 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Wed, 28 Sep 2016 10:39:42 +0200 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <2690967.77ZNDzu0qx@tjmaciei-mobl1> References: <201609280122.33505.kde@carewolf.com> <2690967.77ZNDzu0qx@tjmaciei-mobl1> Message-ID: <201609281039.42819.kde@carewolf.com> On Wednesday 28 September 2016, Thiago Macieira wrote: > On quarta-feira, 28 de setembro de 2016 01:22:33 PDT Allan Sandfeld Jensen > > wrote: > > > QVariant::fromValue(nullptr).isNull() == false > > > QVariant(QMetaType::Nullptr).isNull() == true > > > > And QVariant(nullptr) doesn't compile. > > > > We should probably fix the fromValue constructor. > > I don't think so. This is also false: > > QVariant::fromValue(nullptr).isNull() Is QVariant(QMetaType::VoidStar).isNull() true? Since nullptr is new, I would prefer if we could avoid having it too quirky to begin with. `allan From Simon.Hausmann at qt.io Wed Sep 28 10:54:10 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 28 Sep 2016 08:54:10 +0000 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <3154455.zo9t9GIjz4@tjmaciei-mobl1> References: <4541839.luIDPdY38A@tjmaciei-mobl1> , <3154455.zo9t9GIjz4@tjmaciei-mobl1> Message-ID: Hi, Ok, let me clarify: When the JavaScript engine wants to map a JS null value to a QVariant, it used to use QVariant(QMetaType::VoidStar, (void *)0); and now uses QVariant::fromValue(nullptr); If a string is to be converted to a QVariant, it will naturally use QVariant(thatString). I think if that string happens to be a null QString, then QVariant isNull() will return true, right? If that is unsufficient for the pim code here (or generally any other code), then my recommendation would be to change the signature to take a QJSValue instead of a QVariant. The engine supports that transparently and the QJSValue API allows distinguishing between a JavaScript null and a string, etc. So that is another option. Simon ________________________________ From: Development on behalf of Thiago Macieira Sent: Tuesday, September 27, 2016 11:59:50 PM To: development at qt-project.org Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null On terça-feira, 27 de setembro de 2016 18:22:34 PDT Simon Hausmann wrote: > I'm fairly sure we used QVariant(QMetaType::VoidStar); Can you guarantee that the only time the QML engine generates null QVariants is for null JS Values? That is, no null QStrings, null QVariantLists, null QVariantMaps/Hahes, null doubles, etc.? If that's the case, I'd recommend a doc update and unit tests. Chris can fix his code for isNull(). Note: QVariant::fromValue(nullptr).isNull() == false QVariant(QMetaType::Nullptr).isNull() == true -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development Development Info Page - Qt lists.qt-project.org To see the collection of prior postings to the list, visit the Development Archives. Using Development: To post a message to all the list members ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Wed Sep 28 12:41:16 2016 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 28 Sep 2016 12:41:16 +0200 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <201609281039.42819.kde@carewolf.com> References: <2690967.77ZNDzu0qx@tjmaciei-mobl1> <201609281039.42819.kde@carewolf.com> Message-ID: <2027735.Ulnuf5J9Fb@maurice> On Mittwoch, 28. September 2016 10:39:42 CEST Allan Sandfeld Jensen wrote: > On Wednesday 28 September 2016, Thiago Macieira wrote: > > On quarta-feira, 28 de setembro de 2016 01:22:33 PDT Allan Sandfeld Jensen > > > > wrote: > > > > QVariant::fromValue(nullptr).isNull() == false > > > > QVariant(QMetaType::Nullptr).isNull() == true > > > > > > And QVariant(nullptr) doesn't compile. > > > > > > We should probably fix the fromValue constructor. > > > > I don't think so. This is also false: > > QVariant::fromValue(nullptr).isNull() > > Is QVariant(QMetaType::VoidStar).isNull() true? > > Since nullptr is new, I would prefer if we could avoid having it too quirky > to begin with. > > `allan int main() { QVariant v1 = QVariant::fromValue(nullptr); QVariant v2 = QVariant::fromValue(nullptr); qDebug() << v1.isNull() << v2.isNull() << (v1 == v2) << (v2 == v1); qDebug() << v2.canConvert() << v2.canConvert(); } // output: // "false false false false" // "false false" IMHO this is wrong! First of all, I'm not even convinced it makes sens to have std::nullptr_t as a builtin type. I think any pointer type with nullptr in it should be isNull() All we need a specialisation of QVariantIsNull::CallFilteredIsNull for T* and for std::nullptr_t. That would be a change of behaviour for T* tough. But not for nullptr_t since it's new. Also I think nullptr_t should be convertible to any pointer type. (nullptr_t is converting top any pointer type in the c++ world) And that should solve the equality problem. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From Jedrzej.Nowacki at qt.io Wed Sep 28 13:34:54 2016 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Wed, 28 Sep 2016 11:34:54 +0000 Subject: [Development] Module maintainers: action required (Coin migrates from sync.profile to .gitmodules on 28.09.2016) In-Reply-To: References: <2756158.WOgs6TtE6b@42> <16176940.ZuU55maq73@42> <1812257.QvtQHO20lV@42>, <18001555.Lp55u9ybnk@42>, Message-ID: Good news everyone! The deployment was success and we can wait for fireworks. I'm sure there will be some. So if something doesn't compile now, because of an invalid dependency look to .gitmodules in the right qt5 branch and fix it. Integrations may fail also because of invalid intermodule dependencies, we compile every module against modules from the latest successful qt5 integration of the same branch, which means that we use combination of sha1 that up to now was not really tested, so fix it. It should be a temporary problem. QtBase is not affected, by the change. At this point I would like to remind everyone importance of Qt5 submodule updates. Breakages there are P0 for the project even in dev branch! They affect not only packages and release but now also our day to day development process. Cheers, Jędrek From kde at carewolf.com Wed Sep 28 14:53:01 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Wed, 28 Sep 2016 14:53:01 +0200 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <2027735.Ulnuf5J9Fb@maurice> References: <201609281039.42819.kde@carewolf.com> <2027735.Ulnuf5J9Fb@maurice> Message-ID: <201609281453.02088.kde@carewolf.com> On Wednesday 28 September 2016, Olivier Goffart wrote: > > int main() { > QVariant v1 = QVariant::fromValue(nullptr); > QVariant v2 = QVariant::fromValue(nullptr); > qDebug() << v1.isNull() << v2.isNull() << (v1 == v2) << (v2 == v1); > qDebug() << v2.canConvert() << v2.canConvert(); > } > // output: > // "false false false false" > // "false false" > > IMHO this is wrong! > > First of all, I'm not even convinced it makes sens to have std::nullptr_t > as a builtin type. > > I think any pointer type with nullptr in it should be isNull() > All we need a specialisation of QVariantIsNull::CallFilteredIsNull for T* > and for std::nullptr_t. > That would be a change of behaviour for T* tough. But not for nullptr_t > since it's new. > > Also I think nullptr_t should be convertible to any pointer type. > (nullptr_t is converting top any pointer type in the c++ world) > And that should solve the equality problem. I would agree, but after looking into the code, I think we have a major problem. QVariant::isNull is used for two things, one it maps to isNull on any complex classes, but during conversion anything null can't be converted and null afterwards indicate a failed conversion. Convert should probably be using QVariant::Invalid, but it currently doesn't. In general we have not separated invalid and null well in the past, and trying to fix that will cause issues. `Allan From thiago.macieira at intel.com Wed Sep 28 17:37:34 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 28 Sep 2016 08:37:34 -0700 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: References: <3154455.zo9t9GIjz4@tjmaciei-mobl1> Message-ID: <1632398.mZCWtCm1NG@tjmaciei-mobl1> On quarta-feira, 28 de setembro de 2016 08:54:10 PDT Simon Hausmann wrote: > Hi, > > Ok, let me clarify: When the JavaScript engine wants to map a JS null value > to a QVariant, it used to use > > QVariant(QMetaType::VoidStar, (void *)0); > > and now uses > > QVariant::fromValue(nullptr); Neither is isNull() == true. > If a string is to be converted to a QVariant, it will naturally use > QVariant(thatString). I think if that > string happens to be a null QString, then QVariant isNull() will return > true, right? Right. he question was whether QML strings were guaranteed to be non-null. If you can't guarantee that, then we can't rely on QVariant::isNull(). > If that is unsufficient for the pim code here (or generally any other code), > then my recommendation > would be to change the signature to take a QJSValue instead of a QVariant. > The engine supports that > transparently and the QJSValue API allows distinguishing between a > JavaScript null and a string, etc. Are we deprecating the QVariant interface? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Wed Sep 28 17:42:06 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 28 Sep 2016 15:42:06 +0000 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <1632398.mZCWtCm1NG@tjmaciei-mobl1> References: <3154455.zo9t9GIjz4@tjmaciei-mobl1> , <1632398.mZCWtCm1NG@tjmaciei-mobl1> Message-ID: Hi, I don't think the QVariant interface is deprecated, but it just inherently unsuitable for JavaScript specific things such as distinguishing undefined from null or storing function closures. That is why the engine supports both, for different purposes. Simon From: thiago.macieira at intel.com Sent: September 28, 2016 17:37 To: development at qt-project.org Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null On quarta-feira, 28 de setembro de 2016 08:54:10 PDT Simon Hausmann wrote: > Hi, > > Ok, let me clarify: When the JavaScript engine wants to map a JS null value > to a QVariant, it used to use > > QVariant(QMetaType::VoidStar, (void *)0); > > and now uses > > QVariant::fromValue(nullptr); Neither is isNull() == true. > If a string is to be converted to a QVariant, it will naturally use > QVariant(thatString). I think if that > string happens to be a null QString, then QVariant isNull() will return > true, right? Right. he question was whether QML strings were guaranteed to be non-null. If you can't guarantee that, then we can't rely on QVariant::isNull(). > If that is unsufficient for the pim code here (or generally any other code), > then my recommendation > would be to change the signature to take a QJSValue instead of a QVariant. > The engine supports that > transparently and the QJSValue API allows distinguishing between a > JavaScript null and a string, etc. Are we deprecating the QVariant interface? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Sep 28 17:50:00 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 28 Sep 2016 08:50:00 -0700 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: References: <1632398.mZCWtCm1NG@tjmaciei-mobl1> Message-ID: <70367480.XkEpTXphLn@tjmaciei-mobl1> On quarta-feira, 28 de setembro de 2016 15:42:06 PDT Simon Hausmann wrote: > I don't think the QVariant interface is deprecated, but it just inherently > unsuitable for JavaScript specific things such as distinguishing undefined > from null or storing function closures. That is why the engine supports > both, for different purposes. Chris, is it possible to use the QJSValue interface instead? Why did the code use QVariant? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chris.adams at qinetic.com.au Thu Sep 29 03:13:29 2016 From: chris.adams at qinetic.com.au (Chris Adams) Date: Thu, 29 Sep 2016 11:13:29 +1000 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: <70367480.XkEpTXphLn@tjmaciei-mobl1> References: <1632398.mZCWtCm1NG@tjmaciei-mobl1> <70367480.XkEpTXphLn@tjmaciei-mobl1> Message-ID: I'm certain that it's possible. I suspect the reason why the code used QVariant is that when it was originally written (in Qt 4.7 days, IIRC), QJSValue didn't exist, and it simply hasn't been ported to newer interfaces since then. Without knowing too much about the QML bindings in QtPIM, I am going to assume that there is at least some effort required to port all of the usages and update all of the unit tests. On Thu, Sep 29, 2016 at 1:50 AM, Thiago Macieira wrote: > On quarta-feira, 28 de setembro de 2016 15:42:06 PDT Simon Hausmann wrote: > > I don't think the QVariant interface is deprecated, but it just > inherently > > unsuitable for JavaScript specific things such as distinguishing > undefined > > from null or storing function closures. That is why the engine supports > > both, for different purposes. > > Chris, is it possible to use the QJSValue interface instead? Why did the > code > use QVariant? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jturcotte at woboq.com Thu Sep 29 10:29:52 2016 From: jturcotte at woboq.com (Jocelyn Turcotte) Date: Thu, 29 Sep 2016 10:29:52 +0200 Subject: [Development] Behaviour change in QML in Qt 5.8 regarding null In-Reply-To: References: <1632398.mZCWtCm1NG@tjmaciei-mobl1> <70367480.XkEpTXphLn@tjmaciei-mobl1> Message-ID: <39E46F59-4871-4349-B395-3FB8B1FFF7EF@woboq.com> One of the reasons to use QVariant is that it's usually what is needed to connect a C++ signal to a QML function or to use invokeMethod, I could only ever get this to work by passing all arguments as QVariants. See for example: http://doc.qt.io/qt-5/qtqml-cppintegration-interactqmlfromcpp.html#invoking-qml-methods Connecting QML signal to a C++ slot also recommends (requires?) using a QVariant for arguments: http://doc.qt.io/qt-5/qtqml-cppintegration-interactqmlfromcpp.html#connecting-to-qml-signals Would there be a way that I'm not aware to use QJSValue in those situations too? Sure it's the other way around, but for the sake of consistency I don't like to use QVariant for QML input functions while using QJSValue for arguments of output functions. Jocelyn > On 29 Sep 2016, at 03:13, Chris Adams wrote: > > I'm certain that it's possible. I suspect the reason why the code used QVariant is that when it was originally written (in Qt 4.7 days, IIRC), QJSValue didn't exist, and it simply hasn't been ported to newer interfaces since then. Without knowing too much about the QML bindings in QtPIM, I am going to assume that there is at least some effort required to port all of the usages and update all of the unit tests. > > On Thu, Sep 29, 2016 at 1:50 AM, Thiago Macieira wrote: > On quarta-feira, 28 de setembro de 2016 15:42:06 PDT Simon Hausmann wrote: > > I don't think the QVariant interface is deprecated, but it just inherently > > unsuitable for JavaScript specific things such as distinguishing undefined > > from null or storing function closures. That is why the engine supports > > both, for different purposes. > > Chris, is it possible to use the QJSValue interface instead? Why did the code > use QVariant? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jan.kotanski at desy.de Thu Sep 29 22:08:05 2016 From: jan.kotanski at desy.de (Kotanski, Jan) Date: Thu, 29 Sep 2016 22:08:05 +0200 (CEST) Subject: [Development] Too long text in qlabel crashes my gdm Message-ID: <1556475550.12223241.1475179685855.JavaMail.zimbra@desy.de> Hi, I've noticed that too long test in qlabel e.g. void retranslateUi(QDialog *Dialog) { Dialog->setWindowTitle(QApplication::translate("Dialog", "Dialog", 0, QApplication::UnicodeUTF8)); char str[2000]; for(int i=0; i<1999;i++) str[i] = 'a'; str[1999]='\0'; label->setText(QApplication::translate("Dialog", str, 0, QApplication::UnicodeUTF8)); } // retranslateUi crashed my gdm (for gnome 3). Is it a known problem? How to fix it? More info on: https://www.riverbankcomputing.com/pipermail/pyqt/2016-September/038145.html Bests, Jan From nassian at bitshift-dynamics.de Thu Sep 29 22:12:14 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Thu, 29 Sep 2016 22:12:14 +0200 Subject: [Development] Too long text in qlabel crashes my gdm In-Reply-To: <1556475550.12223241.1475179685855.JavaMail.zimbra@desy.de> References: <1556475550.12223241.1475179685855.JavaMail.zimbra@desy.de> Message-ID: <4D08B50D-AAF8-4F19-8EE4-05B18B03334B@bitshift-dynamics.de> Hi, Does this also happen if you use QString instead of char[]? Beste Grüße / Best regards, Alexander Nassian, bitshift dynamics GmbH > Am 29.09.2016 um 22:08 schrieb Kotanski, Jan : > > Hi, > > I've noticed that too long test in qlabel e.g. > > void retranslateUi(QDialog *Dialog) > { > Dialog->setWindowTitle(QApplication::translate("Dialog", "Dialog", 0, QApplication::UnicodeUTF8)); > char str[2000]; > for(int i=0; i<1999;i++) > str[i] = 'a'; > str[1999]='\0'; > label->setText(QApplication::translate("Dialog", str, 0, QApplication::UnicodeUTF8)); > } // retranslateUi > > crashed my gdm (for gnome 3). > > Is it a known problem? How to fix it? > > More info on: > > https://www.riverbankcomputing.com/pipermail/pyqt/2016-September/038145.html > > Bests, > Jan > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From nassian at bitshift-dynamics.de Thu Sep 29 22:17:01 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Thu, 29 Sep 2016 22:17:01 +0200 Subject: [Development] Too long text in qlabel crashes my gdm In-Reply-To: <1556475550.12223241.1475179685855.JavaMail.zimbra@desy.de> References: <1556475550.12223241.1475179685855.JavaMail.zimbra@desy.de> Message-ID: <47D1F547-86FD-4683-9FCD-D437C1F18E8D@bitshift-dynamics.de> FTR on my macOS machine with Qt 5.7.0 it doesn’t crash. What Qt version do you use? QApplication::UnicodeUTF8 is unknown as well as the translate() overload that your code uses. Beste Grüße / Best regards, Alexander Nassian, bitshift dynamics GmbH > Am 29.09.2016 um 22:08 schrieb Kotanski, Jan : > > Hi, > > I've noticed that too long test in qlabel e.g. > > void retranslateUi(QDialog *Dialog) > { > Dialog->setWindowTitle(QApplication::translate("Dialog", "Dialog", 0, QApplication::UnicodeUTF8)); > char str[2000]; > for(int i=0; i<1999;i++) > str[i] = 'a'; > str[1999]='\0'; > label->setText(QApplication::translate("Dialog", str, 0, QApplication::UnicodeUTF8)); > } // retranslateUi > > crashed my gdm (for gnome 3). > > Is it a known problem? How to fix it? > > More info on: > > https://www.riverbankcomputing.com/pipermail/pyqt/2016-September/038145.html > > Bests, > Jan > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Sep 29 22:43:28 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 29 Sep 2016 13:43:28 -0700 Subject: [Development] Too long text in qlabel crashes my gdm In-Reply-To: <1556475550.12223241.1475179685855.JavaMail.zimbra@desy.de> References: <1556475550.12223241.1475179685855.JavaMail.zimbra@desy.de> Message-ID: <2360363.l5o5iyvq1T@tjmaciei-mobl1> On quinta-feira, 29 de setembro de 2016 22:08:05 PDT Kotanski, Jan wrote: > crashed my gdm (for gnome 3). > > Is it a known problem? How to fix it? if gdm crashes, it's a gdm bug. Please talk to GNOME people for the fix. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jan.kotanski at desy.de Thu Sep 29 22:48:10 2016 From: jan.kotanski at desy.de (Kotanski, Jan) Date: Thu, 29 Sep 2016 22:48:10 +0200 (CEST) Subject: [Development] Too long text in qlabel crashes my gdm In-Reply-To: <47D1F547-86FD-4683-9FCD-D437C1F18E8D@bitshift-dynamics.de> References: <1556475550.12223241.1475179685855.JavaMail.zimbra@desy.de> <47D1F547-86FD-4683-9FCD-D437C1F18E8D@bitshift-dynamics.de> Message-ID: <1973757598.12227036.1475182090725.JavaMail.zimbra@desy.de> Replacing into QString it crashes as well, i.e. #ifndef UI_DIALOG_H #define UI_DIALOG_H #include #include #include #include #include #include #include #include #include QT_BEGIN_NAMESPACE class Ui_Dialog { public: QFormLayout *formLayout; QVBoxLayout *verticalLayout; QLabel *label; void setupUi(QDialog *Dialog) { if (Dialog->objectName().isEmpty()) Dialog->setObjectName(QString::fromUtf8("Dialog")); Dialog->resize(355, 37); formLayout = new QFormLayout(Dialog); formLayout->setSpacing(6); formLayout->setContentsMargins(11, 11, 11, 11); formLayout->setObjectName(QString::fromUtf8("formLayout")); verticalLayout = new QVBoxLayout(); verticalLayout->setSpacing(6); verticalLayout->setObjectName(QString::fromUtf8("verticalLayout")); label = new QLabel(Dialog); label->setObjectName(QString::fromUtf8("label")); verticalLayout->addWidget(label); formLayout->setLayout(0, QFormLayout::LabelRole, verticalLayout); retranslateUi(Dialog); QMetaObject::connectSlotsByName(Dialog); } // setupUi void retranslateUi(QDialog *Dialog) { Dialog->setWindowTitle(QString("Dialog")); char str[2000]; for(int i=0; i<1999;i++) str[i] = 'a'; str[1999]='\0'; label->setText(QString(str)); } // retranslateUi }; namespace Ui { class Dialog: public Ui_Dialog {}; } // namespace Ui QT_END_NAMESPACE #endif // UI_DIALOG_H From: "Alexander Nassian" To: "Kotanski, Jan" Cc: "development" Sent: Thursday, 29 September, 2016 22:17:01 Subject: Re: [Development] Too long text in qlabel crashes my gdm FTR on my macOS machine with Qt 5.7.0 it doesn’t crash. What Qt version do you use? QApplication::UnicodeUTF8 is unknown as well as the translate() overload that your code uses. Beste Grüße / Best regards, Alexander Nassian, bitshift dynamics GmbH Am 29.09.2016 um 22:08 schrieb Kotanski, Jan < jan.kotanski at desy.de >: Hi, I've noticed that too long test in qlabel e.g. void retranslateUi(QDialog *Dialog) { Dialog->setWindowTitle(QApplication::translate("Dialog", "Dialog", 0, QApplication::UnicodeUTF8)); char str[2000]; for(int i=0; i<1999;i++) str[i] = 'a'; str[1999]='\0'; label->setText(QApplication::translate("Dialog", str, 0, QApplication::UnicodeUTF8)); } // retranslateUi crashed my gdm (for gnome 3). Is it a known problem? How to fix it? More info on: https://www.riverbankcomputing.com/pipermail/pyqt/2016-September/038145.html Bests, Jan _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoenitz at t-online.de Thu Sep 29 23:15:18 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 29 Sep 2016 23:15:18 +0200 Subject: [Development] Too long text in qlabel crashes my gdm In-Reply-To: <1556475550.12223241.1475179685855.JavaMail.zimbra@desy.de> References: <1556475550.12223241.1475179685855.JavaMail.zimbra@desy.de> Message-ID: <20160929211517.GA5911@klara.mpi.htwm.de> On Thu, Sep 29, 2016 at 10:08:05PM +0200, Kotanski, Jan wrote: > Hi, > > I've noticed that too long test in qlabel e.g. > > void retranslateUi(QDialog *Dialog) > { > Dialog->setWindowTitle(QApplication::translate("Dialog", "Dialog", 0, QApplication::UnicodeUTF8)); > char str[2000]; > for(int i=0; i<1999;i++) > str[i] = 'a'; > str[1999]='\0'; > label->setText(QApplication::translate("Dialog", str, 0, QApplication::UnicodeUTF8)); > } // retranslateUi > > crashed my gdm (for gnome 3). > > Is it a known problem? How to fix it? That's something to ask the gdm folks. 2000 bytes in a QLabel might be unusual, but no reason to crash. Here (fvwm 2.6.5 on Ubuntu 16.04) it displays fine. Andre' From thiago.macieira at intel.com Fri Sep 30 00:00:30 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 29 Sep 2016 15:00:30 -0700 Subject: [Development] Too long text in qlabel crashes my gdm In-Reply-To: <20160929211517.GA5911@klara.mpi.htwm.de> References: <1556475550.12223241.1475179685855.JavaMail.zimbra@desy.de> <20160929211517.GA5911@klara.mpi.htwm.de> Message-ID: <3127657.tRKBmdai0v@tjmaciei-mobl1> On quinta-feira, 29 de setembro de 2016 23:15:18 PDT André Pönitz wrote: > That's something to ask the gdm folks. 2000 bytes in a QLabel might be > unusual, but no reason to crash. Here (fvwm 2.6.5 on Ubuntu 16.04) it > displays fine. From the conversation in the linked thread, it looks like Qt tried to create a dialog that is too wide, so COGL failed to create the OpenGL texture. Then it crashed. Workaround: limit the width of your dialog. Fix: get the window manager to stop crashing. It can force Qt to accept a smaller size. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jan.kotanski at desy.de Fri Sep 30 08:32:34 2016 From: jan.kotanski at desy.de (Jan Kotanski) Date: Fri, 30 Sep 2016 08:32:34 +0200 Subject: [Development] Too long text in qlabel crashes my gdm In-Reply-To: <3127657.tRKBmdai0v@tjmaciei-mobl1> References: <1556475550.12223241.1475179685855.JavaMail.zimbra@desy.de> <20160929211517.GA5911@klara.mpi.htwm.de> <3127657.tRKBmdai0v@tjmaciei-mobl1> Message-ID: Thanks. > From the conversation in the linked thread, it looks like Qt tried to create a > dialog that is too wide, so COGL failed to create the OpenGL texture. Then it > crashed. That's my suspicious. > > Workaround: limit the width of your dialog. Yes. I did it before my posts in the origin project. :) > > Fix: get the window manager to stop crashing. It can force Qt to accept a > smaller size. > I've reported to the GNOME mailing list https://mail.gnome.org/archives/gnome-devel-list/2016-September/msg00001.html Since I'm not the expert I didn't know if it is the qt job (check if it can create the window) or the gnome job (force Qt to accept a smaller size). Bests, Jan From jani.heikkinen at qt.io Fri Sep 30 11:16:07 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 30 Sep 2016 09:16:07 +0000 Subject: [Development] Qt 5.8.0 beta snapshot for testing Message-ID: Hi all, Please test qt 5.8.0 beta snapshot Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/579/ Mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/446/ Src: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/ Unfortunately we don't have working binary installers for Linux yet so you need to compile qt 5.8.0 beta from sources for Linux. But please do it; it is really important to find all beta blockers from there as well. We will be late from original beta schedule (target was 4th October) but let's try to minimize the delay so please make sure all beta blockers are visible in beta blocker list immediately. And please fix the issues in the list immediately. Beta blocker list here: https://bugreports.qt.io/issues/?filter=17924 RTA smoke is run for the packages & you can find known issues from here:https://bugreports.qt.io/issues/?filter=17948 br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.harmer at kdab.com Fri Sep 30 12:39:20 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 30 Sep 2016 11:39:20 +0100 Subject: [Development] Managing branches of Qt's git modules Message-ID: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> Hi, just a query as to how people do bulk checkouts of different branches when working with the Qt git modules. It would be nice to be able to use git submodule foreach ... but this is a problem because not all modules use the same branching scheme. So, what do people do to checkout all interesting modules to 5.7, 5.8, dev etc on Unix like systems and on Windows? On *nix systems I've been getting away with a simple bash for loop. But on windows I find this painful but maybe that's just my unfamiliarity with windows batch scripts. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From sean.harmer at kdab.com Fri Sep 30 12:46:39 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 30 Sep 2016 11:46:39 +0100 Subject: [Development] Qt 3D WIP branches Message-ID: Hi, Without knowing the internals of COIN, is it a problem for CI load if we request some WIP branches for upcoming major Qt 3D features? The branches we would like are for features that will take many commits to mature and involve many people so local branches are not enough and we don't know if they will mature in time for 5.9 so dev is not ideal either as then we may have to strip a ton of stuff out. The branches we would like created are: * wip-animation - for key frame animation support * wip-quickintegration - for providing support to render and interact with Qt Quick 2 elements in a 3D scene * wip-particles - for a new particle system in Qt 3D There will be others needed later but these are the pressing ones. if this is OK, then is this email sufficient to get it rolling or do I need to file a JIRA too? Thanks in advance, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From marc.mutz at kdab.com Fri Sep 30 12:57:43 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 30 Sep 2016 12:57:43 +0200 Subject: [Development] Managing branches of Qt's git modules In-Reply-To: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> References: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> Message-ID: <201609301257.43726.marc.mutz@kdab.com> On Friday 30 September 2016 12:39:20 Sean Harmer wrote: > Hi, > > just a query as to how people do bulk checkouts of different branches > when working with the Qt git modules. It would be nice to be able to use > git submodule foreach ... but this is a problem because not all modules > use the same branching scheme. > > So, what do people do to checkout all interesting modules to 5.7, 5.8, > dev etc on Unix like systems and on Windows? > > On *nix systems I've been getting away with a simple bash for loop. But > on windows I find this painful but maybe that's just my unfamiliarity > with windows batch scripts. to speed up fetching: git submdule foreach "git fetch --all &" for everything else there's the repo tool, though I have not gotten around to checking it out, since most of my work is in qtbase. git checkout git submodule update --rebase doesn't do what you want? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From sergio.martins at kdab.com Fri Sep 30 12:55:36 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Fri, 30 Sep 2016 11:55:36 +0100 Subject: [Development] Managing branches of Qt's git modules In-Reply-To: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> References: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> Message-ID: <10a276bdac2d43bb50fc1805f3152397@kdab.com> On 2016-09-30 11:39, Sean Harmer wrote: > Hi, > > just a query as to how people do bulk checkouts of different branches > when working with the Qt git modules. It would be nice to be able to > use git submodule foreach ... but this is a problem because not all > modules use the same branching scheme. > > So, what do people do to checkout all interesting modules to 5.7, 5.8, > dev etc on Unix like systems and on Windows? I have my own set of scripts which automate that and abstracts the underlying platform. $ build_stuff.py x86_64 qtbase,qtdeclarative,gammaray 5.6 --clean --pull So I can build for mac, linux, windows, android, QNX without having to remember specifics. > On *nix systems I've been getting away with a simple bash for loop. > But on windows I find this painful but maybe that's just my > unfamiliarity with windows batch scripts. That's because Windows is painful. Invest some time tweaking it until you can have the same workflows as you have on linux. You'll be happier. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From sean.harmer at kdab.com Fri Sep 30 13:05:22 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 30 Sep 2016 12:05:22 +0100 Subject: [Development] Managing branches of Qt's git modules In-Reply-To: <201609301257.43726.marc.mutz@kdab.com> References: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> <201609301257.43726.marc.mutz@kdab.com> Message-ID: <84c30574-9a04-965a-d585-843e40b28864@kdab.com> On 30/09/2016 11:57, Marc Mutz wrote: > On Friday 30 September 2016 12:39:20 Sean Harmer wrote: >> Hi, >> >> just a query as to how people do bulk checkouts of different branches >> when working with the Qt git modules. It would be nice to be able to use >> git submodule foreach ... but this is a problem because not all modules >> use the same branching scheme. >> >> So, what do people do to checkout all interesting modules to 5.7, 5.8, >> dev etc on Unix like systems and on Windows? >> >> On *nix systems I've been getting away with a simple bash for loop. But >> on windows I find this painful but maybe that's just my unfamiliarity >> with windows batch scripts. > > to speed up fetching: > > git submdule foreach "git fetch --all &" > > for everything else there's the repo tool, though I have not gotten around > to checking it out, since most of my work is in qtbase. > > git checkout > git submodule update --rebase Thanks! Somehow I'd missed knowing about the --rebase option. > doesn't do what you want? Looks like it should. Thanks, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From Kai.Koehne at qt.io Fri Sep 30 14:19:09 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 30 Sep 2016 12:19:09 +0000 Subject: [Development] Using semicolons in JS (QML) Message-ID: Hi, It’s Friday, so time for some bikeshedding ;) As you might know, the semicolon as a statement separator in JavaScript is optional. That is, most of the time you can just separate commands by newlines. There are a few pathological cases [1] though where a semicolon is needed. It seems the JavaScript world is divided on the topic whether to use semicolons by default though. Now I do not care that much about JavaScript as a language, but I do care about consistency in the Qt documentation and examples. Unfortunately we didn’t seem to have made a call so far what to prefer. Even our minimal “QML coding conventions” at http://doc.qt.io/qt-5/qml-codingconventions.html feature a semicolon in places, and in others no semicolon. To make a proposal: Let’s use semicolons in imperative JS parts of QML in our examples and documentation. Apart from being on the safe side regarding some pathological cases, it also makes the difference between declarative QML bindings and imperative JS code more explicit. Now I do realize that the right side of QML bindings is actually JavaScript. But no, I do not want to propose that now every binding ends with a ‘;’. A good rule of thumb might be that semicolons should be used inside either function X() {} or OnSignalHandler: {} blocks, or in .js files. Thoughts? Kai [1]: See e.g. http://benalman.com/news/2013/01/advice-javascript-semicolon-haters/ -- Kai Köhne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Qt World Summit 2016 | Pier 27, San Francisco, CA Experience Exponential Potential on October 18-20 www.qtworldsummit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Fri Sep 30 14:22:23 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 30 Sep 2016 15:22:23 +0300 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: References: Message-ID: <3676011475238143@web27h.yandex.ru> 30.09.2016, 15:19, "Kai Koehne" : > Hi, > > It’s Friday, so time for some bikeshedding ;) > > As you might know, the semicolon as a statement separator in JavaScript is optional. That is, most of the time you can just separate commands > > by newlines. There are a few pathological cases [1] though where a semicolon is needed. It seems the JavaScript world is divided on the topic > > whether to use semicolons by default though. > > Now I do not care that much about JavaScript as a language, but I do care about consistency in the Qt documentation and examples. Unfortunately > > we didn’t seem to have made a call so far what to prefer. Even our minimal “QML coding conventions” at http://doc.qt.io/qt-5/qml-codingconventions.html > > feature a semicolon in places, and in others no semicolon. > > To make a proposal: Let’s use semicolons in imperative JS parts of QML in our examples and documentation. > > Apart from being on the safe side regarding some pathological cases, it also makes the difference between declarative QML bindings  and > > imperative JS code more explicit. > > Now I do realize that the right side of QML bindings is actually JavaScript. But no, I do not want to propose that now every binding ends with a ‘;’. > > A good rule of thumb might be that semicolons should be used inside either function X() {} or OnSignalHandler: {} blocks, or in .js files. > > Thoughts? > > Kai > > [1]: See e.g. http://benalman.com/news/2013/01/advice-javascript-semicolon-haters/ I think that would be fine to require semicolons everywhere except last statement (and if there is single statement in the binding, no semi-colons are needed at all) > > -- > > Kai Köhne, Senior Manager R&D | The Qt Company > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > > Qt World Summit 2016 | Pier 27, San Francisco, CA > > Experience Exponential Potential on October 18-20 > > www.qtworldsummit.com > > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From ulf.hermann at qt.io Fri Sep 30 14:34:54 2016 From: ulf.hermann at qt.io (Ulf Hermann) Date: Fri, 30 Sep 2016 14:34:54 +0200 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: <3676011475238143@web27h.yandex.ru> References: <3676011475238143@web27h.yandex.ru> Message-ID: <4ef52338-104d-3e3e-c3e7-305a7dace54a@qt.io> > I think that would be fine to require semicolons everywhere except last statement (and if there is single statement in the binding, no semi-colons are needed at all) I'm fine with having no semicolon on single statement bindings or signal handlers that also don't require a pair of curly braces. For everything else and our own sanity, please let's use semicolons. Having functions with semicolons on all but the last statement is just going to be a pain when someone adds another line at the bottom and forgets to add a semicolon on the previous line. When adding the second statement to a binding you're less likely to forget it because you also have to add the braces. regards, Ulf From andreas at hanssen.name Fri Sep 30 14:41:25 2016 From: andreas at hanssen.name (Andreas Aardal Hanssen) Date: Fri, 30 Sep 2016 14:41:25 +0200 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: References: Message-ID: 2016-09-30 14:19 GMT+02:00 Kai Koehne : > To make a proposal: Let’s use semicolons in imperative JS parts of QML in > our examples and documentation. > > Apart from being on the safe side regarding some pathological cases, it > also makes the difference between declarative QML bindings and > > imperative JS code more explicit. > I propose to have semicolons based on the following rules: 1. Every second line of js outside of any scope should end with a semicolon. 2. Semicolon for multiline statements inside an if. 3. If whitespace isn't clear enough, add one semicolon to make the code more readable. 4. If the semicolon makes you feel angry, feel free to arbitrarily add (or remove) semicolons to make you feel better. For example: a = b // ok a = c; // ok, since it's every second line a = d; // WRONG drop the semicolon, be consistent for goodness sake ; // good, add a semicolon to emphasize the whitespace ;;; // now you're just being ridiculous if (a === b) { a = b; a = c; // very good! } Andreas :-) just trying to help -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.hermann at qt.io Fri Sep 30 14:51:36 2016 From: ulf.hermann at qt.io (Ulf Hermann) Date: Fri, 30 Sep 2016 14:51:36 +0200 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: References: Message-ID: <9724ac4a-c302-fa42-fbfe-23ea38668180@qt.io> > 4. If the semicolon makes you feel angry, feel free to arbitrarily add (or remove) semicolons to make you feel better. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; From nassian at bitshift-dynamics.de Fri Sep 30 15:19:47 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Fri, 30 Sep 2016 15:19:47 +0200 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: References: Message-ID: <80AEAEB0-6EAC-4E2A-8636-588FF5188B48@bitshift-dynamics.de> I personally use semicolons always when {} is incorporated. And {} I'm using when its more than a single statement. Beste Grüße / Best regards, Alexander Nassian, bitshift dynamics GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.zanetti at canonical.com Fri Sep 30 15:25:34 2016 From: michael.zanetti at canonical.com (Michael Zanetti) Date: Fri, 30 Sep 2016 15:25:34 +0200 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: References: Message-ID: <33d33ba8-b080-0dab-29ae-3da286359c0f@canonical.com> FWIW, in unity8 (reasonably big QML application) we agreed to not use semicolons for declarative code unless you really want to write some things into a single line and need them, but always use semicolons for imperative code. This has served us very well over the past years, seems consistent and everyone in the team agrees this makes sense. Of course, your opinion may differ but I thought I'd share nevertheless... example: Button { anchors { left: parent.left; right: parent.right } height: 100 text: "foobar" onClicked: { doSomething(); soSomeMoreStuff(); } onReleased: doSomethingElse(); } Br, Michael On 30.09.2016 14:19, Kai Koehne wrote: > Hi, > > > > It’s Friday, so time for some bikeshedding ;) > > > > > > As you might know, the semicolon as a statement separator in JavaScript > is optional. That is, most of the time you can just separate commands > > by newlines. There are a few pathological cases [1] though where a > semicolon is needed. It seems the JavaScript world is divided on the topic > > whether to use semicolons by default though. > > > > Now I do not care that much about JavaScript as a language, but I do > care about consistency in the Qt documentation and examples. Unfortunately > > we didn’t seem to have made a call so far what to prefer. Even our > minimal “QML coding conventions” at > http://doc.qt.io/qt-5/qml-codingconventions.html > > feature a semicolon in places, and in others no semicolon. > > > > To make a proposal: Let’s use semicolons in imperative JS parts of QML > in our examples and documentation. > > Apart from being on the safe side regarding some pathological cases, it > also makes the difference between declarative QML bindings and > > imperative JS code more explicit. > > > > Now I do realize that the right side of QML bindings is actually > JavaScript. But no, I do not want to propose that now every binding ends > with a ‘;’. > > A good rule of thumb might be that semicolons should be used inside > either function X() {} or OnSignalHandler: {} blocks, or in .js files. > > > > Thoughts? > > > > Kai > > > > [1]: See e.g. > http://benalman.com/news/2013/01/advice-javascript-semicolon-haters/ > > > > > > > > -- > > > > Kai Köhne, Senior Manager R&D | The Qt Company > > > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB > 144331 B > > > > Qt World Summit 2016 | Pier 27, San Francisco, CA > > Experience Exponential Potential on October 18-20 > > www.qtworldsummit.com > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 246 bytes Desc: OpenPGP digital signature URL: From marco.a.piccolino at gmail.com Fri Sep 30 16:45:46 2016 From: marco.a.piccolino at gmail.com (Marco Piccolino) Date: Fri, 30 Sep 2016 16:45:46 +0200 Subject: [Development] Using semicolons in JS (QML) Message-ID: I am also already abiding to the practice of using semicolons between curly braces and no semicolons for simple bindings. Marco Piccolino -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Fri Sep 30 16:48:20 2016 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 30 Sep 2016 16:48:20 +0200 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: References: Message-ID: <10697300.r8QWyNEJNn@maurice> On Freitag, 30. September 2016 12:19:09 CEST Kai Koehne wrote: > Hi, > > It’s Friday, so time for some bikeshedding ;) > > > As you might know, the semicolon as a statement separator in JavaScript is > optional. Technicly, that's more complicated than that. The semicolons are mandatory. But in case of parse error, the parser should try to recover by inserting them using complex rules. Quoting the ECMAScript spec: http://www.ecma-international.org/ecma-262/5.1/#sec-7.9 | Certain ECMAScript statements [...] must be terminated with semicolons. Such | semicolons may always appear explicitly in the source text. For convenience, | however, such semicolons may be omitted from the source text in certain | situations. These situations are described by saying that semicolons are | automatically inserted into the source code token stream in those | situations. | When, as the program is parsed from left to right, a token (called the | offending token) is encountered that is not allowed by any production of the | grammar, then a semicolon is automatically inserted before the offending | token if one or more of the following conditions is true: | - The offending token is separated from the previous token by at least one | LineTerminator. | - The offending token is }. | [...] > [...] > To make a proposal: Let’s use semicolons in imperative JS parts of QML in > our examples and documentation. Apart from being on the safe side > regarding some pathological cases, it also makes the difference between > declarative QML bindings and imperative JS code more explicit. > > Now I do realize that the right side of QML bindings is actually JavaScript. > But no, I do not want to propose that now every binding ends with a ‘;’. A > good rule of thumb might be that semicolons should be used inside either > function X() {} or OnSignalHandler: {} blocks, or in .js files. > Thoughts? Personally, I like to use semicolon everywhere when I write QML; including at the end of the bindings. I'm used to semi colon from writing C++ anyway. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Fri Sep 30 17:26:13 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 30 Sep 2016 08:26:13 -0700 Subject: [Development] Managing branches of Qt's git modules In-Reply-To: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> References: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> Message-ID: <1578260.bplyHkjVXR@tjmaciei-mobl1> On sexta-feira, 30 de setembro de 2016 11:39:20 PDT Sean Harmer wrote: > So, what do people do to checkout all interesting modules to 5.7, 5.8, > dev etc on Unix like systems and on Windows? > > On *nix systems I've been getting away with a simple bash for loop. But > on windows I find this painful but maybe that's just my unfamiliarity > with windows batch scripts. You can use git submodule foreach in both cases: since git-submodule is, itself, a shell script, it will be able to run the same things in all OSes. For example, to switch to dev, I might do: git submodule foreach "git rev-parse origin/dev && \ git rebase --onto origin/dev origin/5.8 || true" Then check which ones may have failed to rebase. I only keep commits in qtbase and qtdeclarative, so it's easy to spot which ones failed. PS: I only use one branch in each repository and it's called "master", and I only work with one Qt upstream branch at a time for about 6 months. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Kai.Koehne at qt.io Fri Sep 30 17:34:44 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 30 Sep 2016 15:34:44 +0000 Subject: [Development] Managing branches of Qt's git modules In-Reply-To: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> References: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Sean Harmer > Sent: Friday, September 30, 2016 12:39 PM > To: development at qt-project.org > Subject: [Development] Managing branches of Qt's git modules > > Hi, > > just a query as to how people do bulk checkouts of different branches when > working with the Qt git modules. It would be nice to be able to use git > submodule foreach ... but this is a problem because not all modules use the > same branching scheme. > > So, what do people do to checkout all interesting modules to 5.7, 5.8, dev etc > on Unix like systems and on Windows? git submodule foreach "git fetch && (git checkout 5.8 || git checkout master) " et voila :) Feel free to append a && git reset --hard @{u} && git clean -fxd if you want a clean slate. This works also on Windows. Kai From Shawn.Rutledge at qt.io Fri Sep 30 17:43:57 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 30 Sep 2016 15:43:57 +0000 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: References: Message-ID: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> On 30 Sep 2016, at 14:19, Kai Koehne wrote: > To make a proposal: Let’s use semicolons in imperative JS parts of QML in our examples and documentation Back in Nokia times it was said that we shouldn't use semicolons, because it would speed up the parsing and reduce the size of resources slightly. (Maybe you think performance isn’t impacted by small things like that, but we are at the same time investing effort into other “optimizations” for which I suspect the runtime performance impact may end up being similarly small.) So I’ve been following the no-semicolons convention ever since, except occasionally when C++ habits get the better of me. If you think it’s important, then write a reformatter tool and figure out how to use it as a git hook. We are wasting time bikeshedding about coding style (do you really have nothing better to do? all bugs in Qt are fixed?), and IMO the same argument applies in any kind of code: if there’s no tool to do the reformatting, maybe it’s not so important. It’s just subjective and political, and not the kind of argument I’d ever want to start, personally. From thiago.macieira at intel.com Fri Sep 30 21:57:58 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 30 Sep 2016 12:57:58 -0700 Subject: [Development] Managing branches of Qt's git modules In-Reply-To: <1578260.bplyHkjVXR@tjmaciei-mobl1> References: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> <1578260.bplyHkjVXR@tjmaciei-mobl1> Message-ID: <2123339.hyBUu2KzgZ@tjmaciei-mobl1> On sexta-feira, 30 de setembro de 2016 08:26:13 PDT Thiago Macieira wrote: > For example, to switch to dev, I might do: > > git submodule foreach "git rev-parse origin/dev && \ > git rebase --onto origin/dev origin/5.8 || true" By the way, on my Windows and Mac machines, since they fetch from my Linux one, it's all much simpler once the above is done: git fetch --recurse-submodules=yes git rebase git submodule foreach "git reset --hard @{u}" -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Kai.Koehne at qt.io Fri Sep 30 23:00:24 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 30 Sep 2016 21:00:24 +0000 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> References: , <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> Message-ID: >> To make a proposal: Let’s use semicolons in imperative JS parts of QML in our examples and documentation > > Back in Nokia times it was said that we shouldn't use semicolons, because it would speed up the parsing and reduce the size of resources slightly. (Maybe you think performance isn’t impacted by small > things like that, but we are at the same time investing effort into other “optimizations” for which I suspect the runtime performance impact may end up being similarly small.) So I’ve been following the > no-semicolons convention ever since, except occasionally when C++ habits get the better of me. Interesting. Indeed, I wouldn't have thought it makes any measurable difference. IIRC we had a qml mimizer once, I guess this is still around? > If you think it’s important, then write a reformatter tool and figure out how to use it as a git hook. We are wasting time bikeshedding about coding style (do you really have nothing better to do? > all bugs in Qt are fixed?), and IMO the same argument applies in any kind of code: if there’s no tool to do the reformatting, maybe it’s not so important. It's certainly not that important to me that I will spend a day on writing a git hook that then nobody will use ;) But a lot of programmers (including me) tend to care about code style consistency. So I was making a suggestion that costs us nothing, but leads to a sllightly more consistent documentation and examples in then end. In the same way as I couldn't care less whether to use tabs or spaces, or what the right indentation level is, as long as we stick to one. (And yeah, I also enjoy bikeshedding sometimes, be it at the coffee machine or on a mailing list, even if not 'all Qt in bugs are fixed". And honestly speaking I do not see an issue with this.) > It’s just subjective and political, and not the kind of argument I’d ever want to start, personally. Well, it's an entirely voluntary discussion ;) Kai ________________________________ From: Development on behalf of Shawn Rutledge Sent: Friday, September 30, 2016 5:43:57 PM To: development at qt-project.org Subject: Re: [Development] Using semicolons in JS (QML) On 30 Sep 2016, at 14:19, Kai Koehne wrote: > To make a proposal: Let’s use semicolons in imperative JS parts of QML in our examples and documentation Back in Nokia times it was said that we shouldn't use semicolons, because it would speed up the parsing and reduce the size of resources slightly. (Maybe you think performance isn’t impacted by small things like that, but we are at the same time investing effort into other “optimizations” for which I suspect the runtime performance impact may end up being similarly small.) So I’ve been following the no-semicolons convention ever since, except occasionally when C++ habits get the better of me. If you think it’s important, then write a reformatter tool and figure out how to use it as a git hook. We are wasting time bikeshedding about coding style (do you really have nothing better to do? all bugs in Qt are fixed?), and IMO the same argument applies in any kind of code: if there’s no tool to do the reformatting, maybe it’s not so important. It’s just subjective and political, and not the kind of argument I’d ever want to start, personally. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoenitz at t-online.de Fri Sep 30 23:20:06 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 30 Sep 2016 23:20:06 +0200 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> References: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> Message-ID: <20160930202846.GA3723@klara.mpi.htwm.de> On Fri, Sep 30, 2016 at 03:43:57PM +0000, Shawn Rutledge wrote: > On 30 Sep 2016, at 14:19, Kai Koehne wrote: > > To make a proposal: Let’s use semicolons in imperative JS parts of QML in > > our examples and documentation > > Back in Nokia times it was said that we shouldn't use semicolons, because it > would speed up the parsing and reduce the size of resources slightly. Hear, hear! The world of JavaScript *IS* full of miracles! It is FANTASTIC to know that letting the parser run into an error situation, to back up, to insert an artificial semicolon, and to retry to parse would be SO much faster than reading and interpreting a semicolon directly. You know -- ok, sorry, I have to admit it, I was almost thinking that one could - erm, do -- kind of silly things like create a benchmark, and perhaps even -- *SHUDDER* -- just a little? -- *run* it? But now, of course, I see, this would be really ridiculous. Silly me. And this resource reduction! I mean, we are not talking peanuts here, like World Peace or such, right - but bits, *REAL* bits, and not -- really! -- not just ONE, not TWO, but SEVERAL of them, in a row! This is so incredible! I really, really cannot imagine how dull the world must have been before the magic Ten Days. Oh man. I just notice I am talking crap. It's of course not *REAL* for bits in JavaScript, but *DOUBLES*! Stupid C++ would have used integers for such important things. I mean, that's not paying the right amount of deference, ok? Why should one let an integer operation pass a CPU in, like, one or two cycles, or possibly even less than one, if one really could spend a multiple of that on floating points? Or even require extra hardware? That's not taking machines seriously, is it? > (Maybe you think performance isn’t impacted by small things like that, but we > are at the same time investing effort into other “optimizations” for which I > suspect the runtime performance impact may end up being similarly small.) Even more miracles! What a wonderful world! Ahead-of time compiled C++ code can not only be vastly improved by replacing it with run-time interpreted code - note the word "RUN!" -- that's already making very clear that this *must* be fast, doesn't it! -- people in the know may even take that further and strip away those pesky semicolons from the sources to gain even more performance! That's absolutely great - or, dare I say? -- AWESOME! Andre' PS: On the less serious side: > If you think it’s important, then write a reformatter tool and figure out how > to use it as a git hook. We are wasting time bikeshedding about coding style > (do you really have nothing better to do? There would be that 'consistent documentation' thing that was mentioned in the initial mail. I think this is a valid reason. From robin+qt at viroteck.net Fri Sep 30 23:57:02 2016 From: robin+qt at viroteck.net (Robin Burchell) Date: Fri, 30 Sep 2016 23:57:02 +0200 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: References: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> Message-ID: <1475272622.4135955.742357129.25BF2F40@webmail.messagingengine.com> On Fri, Sep 30, 2016, at 11:00 PM, Kai Koehne wrote: > Interesting. Indeed, I wouldn't have thought it makes any measurable > difference. IIRC we had a qml mimizer once, I guess this is still around? tools/qmlmin in qtdeclarative > It's certainly not that important to me that I will spend a day on > writing a git hook that then nobody will use ;) But a lot of programmers > (including me) tend to care about code style consistency. So I was making > a suggestion that costs us nothing, but leads to a sllightly more > consistent documentation and examples in then end. In the same way as I > couldn't care less whether to use tabs or spaces, or what the right > indentation level is, as long as we stick to one. > > (And yeah, I also enjoy bikeshedding sometimes, be it at the coffee > machine or on a mailing list, even if not 'all Qt in bugs are fixed". And > honestly speaking I do not see an issue with this.) The problem is that these kinds of discussions do actually have a cost. They take time and energy to read and digest, and time to reply to (yes, it's voluntary, but occasionally something useful comes out of it, although usually not in any way related to the original topic - I'd count the above mention of qmlmin in this category for instance). The whole principle of bikeshedding as I'd understand it is that it's easy (and subjectively - somewhat fun) to do, but on the other hand doesn't really get all that much useful accomplished. And it may not be toxic every once in a while, but when you do it often enough, the noise starts to drown out the signal, and you can end up killing off a medium for any sort of reasonable conversations. It's a fine line to walk. As an idea of cost: aside from reading this thread, I spent something like 20 minutes mulling over this topic (and reading around on the internet for resources and opinions) while writing this reply for instance, time that I didn't even really realise I had spent until I was about to click "send" on this mail. Multiply that by every participant, and by every "low signal" thread, and you end up with potentially gargantuan amounts of time being spent on more or less irrelevant details, even if it is fun to do. ... To the topic at hand, I personally tend to omit semicolons unless they are clearly needed either to reduce ambiguity or for reasons of e.g. multiple statements on a single line (already something I prefer to outright avoid, however). I choose this for aesthetics, much like the "omit braces on single line if" rule (which is also, coincidentally, somewhat controversial and ignored from time to time) In the wider community (both QML and JS in general), this isn't a unified topic I'd say. You can find numerous advice going both ways, and I think it's fairly safe to say that there will always be dissenting voices everywhere, no matter what you choose. So for yourself, my advice would be: pick one that you like and stick with it. For Qt, while I would like to see one or the other picked and followed for consistency's sake, I'm not sure it would be a useful investment of your time to try to enforce a particular semicolon-style without tooling enforcement, as it seems like yet another Sisyphean task that will - at best - burn a lot of your time and energy and end up back in exactly the same situation, all for an effort which in practice has little real-world gain. I think that is why Shawn replied the way he did.