Re: [Development] Please update the maintainer table at http://wiki.qt.io/index.php?title=Maintainers
On Mar 2, 2015 7:10 PM, Thiago Macieira thiago.macie...@intel.com wrote: BTW, any chance of getting mod_rewrite so the index.php?title= part gets hidden? I did ask Tero the exact same question: Yes, it is planned, but getting the contents across is the priority at this time. Best Regards, Tobias ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please update the maintainer table at http://wiki.qt.io/index.php?title=Maintainers
Since you both asked nicely, I did it this morning. The full style links still work, for those who use them. Tero From: development-bounces+tero.kojo=theqtcompany@qt-project.org [mailto:development-bounces+tero.kojo=theqtcompany@qt-project.org] On Behalf Of Tobias Hunger Sent: 3. maaliskuuta 2015 10:47 To: Thiago Macieira Cc: development@qt-project.org Subject: Re: [Development] Please update the maintainer table at http://wiki.qt.io/index.php?title=Maintainers On Mar 2, 2015 7:10 PM, Thiago Macieira thiago.macie...@intel.commailto:thiago.macie...@intel.com wrote: BTW, any chance of getting mod_rewrite so the index.php?title= part gets hidden? I did ask Tero the exact same question: Yes, it is planned, but getting the contents across is the priority at this time. Best Regards, Tobias ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 for Examples
On Tuesday 03 March 2015 10:17:45 Koehne Kai wrote: Make it unconditional and let people disable with -nomake tests or -no- compile-examples if they have older compilers. Yeah well, I think the above check contains(QT_CONFIG, c++11) won't hurt. I'd just do it globally in configure though (so that examples aren't automatically build for older compilers), instead of black/whitelisting single examples... I really meant leaving it unconditionally. People with old compilers will face compiler errors and they'll have to add one of the two options to get rid of them. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problem loading plugins with gcc 4.9.2
On Tuesday 03 March 2015 13:55:29 Sergio Martins wrote: Hi, So that you don't waste time pulling your hair out: plugin loading is broken with gcc 4.9.2 There's some clash between global static QFactoryLoader instances. Reproduced on Archlinux (and on Fedora by jpnurmi). Please explain the problem. The one issue I had was QJsonObject failing to sort the keys properly, which resulted in a binary JSON output that was malformed (the format requires the keys to be sorted because they are scanned by binary search). I could not reliably reproduce this in a testcase, so it went unreported. I should also point out that it happened only with GCC 5. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 for Examples
On Tuesday 03 March 2015 12:57:55 Matthew Woehlke wrote: On 2015-03-03 05:17, Koehne Kai wrote: What's missing from the list IMO is using QObject::connect with PointerToMemberFunction instead of SIGNAL(), SLOT(). I thought that was just new in Qt5, and that it does *not* require C++11. The documentation seems to imply so, anyway: The number of arguments in the signal or slot are limited to 6 if the compiler does not support C++11 variadic templates. The syntax is possible in C++98, but the greatest improvement of the syntax is the ability to connect to lambdas. There's also the problem you mentioned of the limit of parameters. I would rather people not have to remember how many they can use, so we should restrict this to C++11. ...which brings up another potentially missing item; variadic templates. Not sure if any examples would benefit from those or not... Unlikely, we don't create new template classes in our examples. There are also very few classes in the Qt sources that would benefit from it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 for Examples
On 2015-03-03 05:17, Koehne Kai wrote: What's missing from the list IMO is using QObject::connect with PointerToMemberFunction instead of SIGNAL(), SLOT(). I thought that was just new in Qt5, and that it does *not* require C++11. The documentation seems to imply so, anyway: The number of arguments in the signal or slot are limited to 6 if the compiler does not support C++11 variadic templates. ...which brings up another potentially missing item; variadic templates. Not sure if any examples would benefit from those or not... -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCore missing check for memory allocation
On Mon, Mar 02, 2015 at 10:11:33AM -0800, Thiago Macieira wrote: On Monday 02 March 2015 11:21:10 Oswald Buddenhagen wrote: I am actively against it while it's a huge burden on us for little perceived benefit. You have to convince me of the benefit against the cost. i still don't see that huge burden. i see introducing a few (inline) functions in two alternative #ifdef branches, and a global search replace operation. You need to replace all the new too for this to be effective. this aims at the reliably failing builds without exception support, so the non-throwing new's return value would have to be checked to complement the malloc wrapper. while this would be reasonably simple (just replace new with qNew or something like that), it would be a) kinda ugly and b) would expand to lots of code. the other case is a build with exceptions where new throws as normal and qMalloc (used from c++ code) throws as well. malloc calls from c code would obviously need to handle and propagate malloc failures up to a point where we can see them and throw, which isn't much effort for our own code. however, there is a serious problem: stack unwinding resulting from an exception being thrown (even if it just aborts in the end because nobody catches it) requires all objects on the stack to keep their internal state consistent enough so that invoked d'tors won't crash - even when a c'tor throws before initialization finishes. this is clearly at least partially the exception safety which we have deemed out of scope so far because of an unreasonable cost/benefit ratio. i presume we're not going to change our opinion on that point. regarding 3rd party libraries: some would need to be excluded from the support entirely (because they are uncooperative), while others may need fixes inside or around the libs. generally, whether they return null or throw (while being exception-safe) doesn't matter, as the mechanisms can be translated into each other. i don't think the effort for that would be prohibitive if we had a serious interest in it, but it certainly wouldn't come for free. so to summarize ... color me convinced. replacing malloc it is. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 for Examples
On Tuesday 03 March 2015 16:15:59 Matthew Woehlke wrote:
Unlikely, we don't create new template classes in our examples. There are
also very few classes in the Qt sources that would benefit from it.
I can think of a few that *might*... QString::arg,
I have a replacement for QString::arg (called QStringArgBuilder) that I've
been keeping for now a year and a half. It's a near drop-in replacement with a
big advantage that it makes proper use of rvalue-qualified members and allows
arg() to modify in-place, but it has two big drawbacks:
1) like QStringBuilder, it returns an object that isn't exactly QString,
which means it introduces a slight source incompatibility. See
https://codereview.qt-project.org/107694
2) completion in Qt Creator doesn't work anymore for the first arg() call
because of the variadic template perfect forward to QStringArgBuilder.
QMetaObject::invokeMethod... anything that takes a pseudo-variadic list
(there are a few places), maybe. (Although I can imagine that the
internals may not in all cases be conducive to being rewritten as true
variadics.)
Right, like QDBusAbstractInterface and QDBusPendingReply. But that's 3 classes
out of 1200+. I mentioned that there are very few :-)
And on a different note... what about initializer lists? I literally
just today was writing:
QProcess process;
process.start(cmd, {arg, arg, QString::number(value) ...});
Why wouldn't that already work?
I'm not going to start a war on omission of class types (although I do
find it can be quite convenient, especially for things where the type is
obvious, e.g. lots of places that take a QRect, QPoint, QSize, etc.),
but I could see making use of the ability to pass vectors in-place via
initializer.
Those don't need initialiser lists. The uniform initialisation syntax would
simply call the appropriate constructor.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problem loading plugins with gcc 4.9.2
On Tuesday, March 03, 2015 11:45:49 Thiago Macieira wrote: On Tuesday 03 March 2015 13:55:29 Sergio Martins wrote: Hi, So that you don't waste time pulling your hair out: plugin loading is broken with gcc 4.9.2 There's some clash between global static QFactoryLoader instances. Reproduced on Archlinux (and on Fedora by jpnurmi). Please explain the problem. The problem is that: (gdb) bt #0 (anonymous namespace)::Q_QGS_loader::innerFunction () at accessible/qaccessible.cpp:462 #1 0x76ff2250 in QGlobalStaticQFactoryLoader, (anonymous namespace)::Q_QGS_loader::innerFunction(), (anonymous namespace)::Q_QGS_loader::guard::operator()() (this=0x775d54f0 _ZL6loader) at ../../include/QtCore/../../src/corelib/global/qglobalstatic.h:129 #2 0x770020ab in QPlatformIntegrationFactory::create (platform=..., paramList=..., argc=@0x7fffdd1c: 1, argv=0x7fffde28, platformPluginPath=...) at kernel/qplatformintegrationfactory.cpp:73 #3 0x7700db47 in init_platform (pluginArgument=..., platformPluginPath=..., platformThemeName=..., argc=@0x7fffdd1c: 1, argv=0x7fffde28) at kernel/qguiapplication.cpp:1010 #4 0x7700ed7a in QGuiApplicationPrivate::createPlatformIntegration (this=0x601a80) at kernel/qguiapplication.cpp:1165 In frame #2, we do loader(), which should create an instance of the /platforms QFactoryLoader, but instead, it calls innerFunction() of a global static of another translation unit (QFactoryLoader of /accessible plugins). A simple fix is to use loader instead of loader() Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problem loading plugins with gcc 4.9.2
On Tue, Mar 3, 2015 at 2:55 PM, Sergio Martins sergio.mart...@kdab.com wrote: Hi, So that you don't waste time pulling your hair out: plugin loading is broken with gcc 4.9.2 There's some clash between global static QFactoryLoader instances. Reproduced on Archlinux (and on Fedora by jpnurmi). I also hit this bug on ArchLinux. I solved it by downgrading from: 4.9.2-3 to 4.9.2-2 on these packages: lib32-gcc-libs gcc-libs gcc. Hope this helps, Aleix ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] foo and the qnetworkdiskcache failure
Short story: I think the current CI failure in 5.5 is fixed by https://codereview.qt-project.org/107701 Long story: tst_qnetworkdiskcache has been trying to fetch pages from www.foo.com, which is a real domain. It's possible that that the infrastructure for this domain changed recently, causing timeouts for us. In the future, please be very careful about domain names, IP addresses, and port numbers in unit tests. If you're reviewing code from others, please try to validate the assumption with an eye towards the future. Things you should avoid: - hardcoded host names that we can't control Example: some unit tests tried to connect to foo port 80, which was fine in Trolltech but promptly started failing once we ran tests in the Nokia network. Similarly to www.foo.com now Solution: use invalid.test.qt-project.org or localhost with a bad port number if you'll try to connect; example.com is fine if your code will never connect - hardcoded IP addresses Example: When APNIC tried to delegate the 1.1.1.0/24 network to a real customer, they discovered a huge amount of traffic due to people using 1.1.1.1 as a test address. For that reason, the 1.1.1.0/24 and 1.2.3.0/24 networks are blackholes (bogon) Solution: Use the IP addresses reserved by RFC 1166/5737, like 192.0.2.1 - hardcoded port numbers (including default numbers) Example: One of our tests tried to bind to port 1234, assuming it would never be in use. Of course, there was a situation in which it was in use. Most likely, it's a previous run of the test that failed to exit properly, so the port was still lingering open by the OS. Solution: If you're going to open a socket, always use port number 0, which will ask the OS assign an unused port to you (use QTcpServer::serverPort() or QUdpSocket::localPort() to get it). If you're going to connect and expect it to fail, choose a very low port number, like 4, which is unassigned. - connecting to outside the test network Example: Trying to connect to qt-project.org and check the result of those pages. Not only can the content change unpredictably, corporate firewalls may block the access. Solution: Either use a mini HTTP server bound to localhost or use the network test server. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 for Examples
On 2015-03-03 16:49, Thiago Macieira wrote:
On Tuesday 03 March 2015 16:15:59 Matthew Woehlke wrote:
And on a different note... what about initializer lists? I literally
just today was writing:
QProcess process;
process.start(cmd, {arg, arg, QString::number(value) ...});
Why wouldn't that already work?
It *does* work. I *love* it :-D. But it requires at least partial C++11
support, does it not? My point was, I didn't see initializer lists on
the list of features to potentially use in examples.
I'm not going to start a war on omission of class types (although I do
find it can be quite convenient, especially for things where the type is
obvious, e.g. lots of places that take a QRect, QPoint, QSize, etc.),
but I could see making use of the ability to pass vectors in-place via
initializer.
Those don't need initialiser lists. The uniform initialisation syntax would
simply call the appropriate constructor.
Yes, different features. Sorry for muddying things :-). (Although I
personally am a fan of uniform initialization, I'm not arguing for its
use in examples... for one, I'm pretty sure it would further restrict
compiler support. If nothing else, there's a GCC bug as late as 4.8 at
least that references can't be {} initialized.)
--
Matthew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problem loading plugins with gcc 4.9.2
On Tuesday 03 March 2015 22:14:55 Sergio Martins wrote: In frame #2, we do loader(), which should create an instance of the /platforms QFactoryLoader, but instead, it calls innerFunction() of a global static of another translation unit (QFactoryLoader of /accessible plugins). A simple fix is to use loader instead of loader() Definitely GCC or linker bug. As you can see in your backtrace, all of this is in an anonymous namespace, so qplatformintegrationfactory.cpp cannot affect qaccessible.cpp. Since we're seeing both operator() and the innerFunction frames, I assume you compiled in debug mode. Correct? Anyway, I have GCC 4.9.2, Binutils 2.25.0 (using gold) and I cannot reproduce in either debug, regular release or LTO release modes. I have 8 different global statics called loader in QtGui: $ nm -C libQt5Gui.so.5 | grep ::Q_QGS_loader::guard\$ 006a5750 b (anonymous namespace)::Q_QGS_loader::guard 006a59c0 b (anonymous namespace)::Q_QGS_loader::guard 006a5a20 b (anonymous namespace)::Q_QGS_loader::guard 006a5ac0 b (anonymous namespace)::Q_QGS_loader::guard 006a5b40 b (anonymous namespace)::Q_QGS_loader::guard 006a61b0 b (anonymous namespace)::Q_QGS_loader::guard 006a6200 b (anonymous namespace)::Q_QGS_loader::guard 006a6374 b (anonymous namespace)::Q_QGS_loader::guard (The mangled name for all of those is the same: _ZN12_GLOBAL__N_112Q_QGS_loader5guardE) Which matches the source code: $ git --no-pager grep Q_GLOBAL_STATIC.*\\bloader accessible/qaccessible.cpp:Q_GLOBAL_STATIC_WITH_ARGS(QFactoryLoader, loader, image/qicon.cpp:Q_GLOBAL_STATIC_WITH_ARGS(QFactoryLoader, loader, image/qimagereader.cpp:Q_GLOBAL_STATIC_WITH_ARGS(QFactoryLoader, loader, image/qimagewriter.cpp:Q_GLOBAL_STATIC_WITH_ARGS(QFactoryLoader, loader, kernel/qgenericpluginfactory.cpp:Q_GLOBAL_STATIC_WITH_ARGS(QFactoryLoader, loader, kernel/qplatforminputcontextfactory.cpp:Q_GLOBAL_STATIC_WITH_ARGS(QFactoryLoader, loader, kernel/qplatformintegrationfactory.cpp:Q_GLOBAL_STATIC_WITH_ARGS(QFactoryLoader, loader, kernel/qplatformthemefactory.cpp:Q_GLOBAL_STATIC_WITH_ARGS(QFactoryLoader, loader, -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 for Examples
On Tuesday 03 March 2015 17:38:47 Matthew Woehlke wrote:
On 2015-03-03 16:49, Thiago Macieira wrote:
On Tuesday 03 March 2015 16:15:59 Matthew Woehlke wrote:
And on a different note... what about initializer lists? I literally
just today was writing:
QProcess process;
process.start(cmd, {arg, arg, QString::number(value) ...});
Why wouldn't that already work?
It *does* work. I *love* it :-D. But it requires at least partial C++11
support, does it not? My point was, I didn't see initializer lists on
the list of features to potentially use in examples.
Indeed it does. But you're right, we couldn't use initializer_list according
to the proposal I made, since initializer_list is broken in Visual Studio up
until 2013 SP 2.
qcompilerdetection.h:
// implemented, but nested initialization fails (eg tst_qvector):
http://connect.microsoft.com/VisualStudio/feedback/details/800364/initializer-list-calls-object-destructor-twice
// #define Q_COMPILER_INITIALIZER_LISTS
The other problem with initialiser lists is std::initializer_list: even though
this header is technically part of the compiler core language, it's supplied
as part of libstdc++, so it's missing on QNX 6.5 and on OS X if you don't use
libc++.
I'm not going to start a war on omission of class types (although I do
find it can be quite convenient, especially for things where the type is
obvious, e.g. lots of places that take a QRect, QPoint, QSize, etc.),
but I could see making use of the ability to pass vectors in-place via
initializer.
Those don't need initialiser lists. The uniform initialisation syntax
would
simply call the appropriate constructor.
Yes, different features. Sorry for muddying things :-). (Although I
personally am a fan of uniform initialization, I'm not arguing for its
use in examples... for one, I'm pretty sure it would further restrict
compiler support. If nothing else, there's a GCC bug as late as 4.8 at
least that references can't be {} initialized.)
Unfortunately, uniform initialisation is one of the three features not yet
working with even VS 2015. qcompilerdetection.h:
// Partial support, insufficient for Qt
//# define Q_COMPILER_CONSTEXPR
// Uniform initialization is not working yet -- build errors with QUuid
//# define Q_COMPILER_UNIFORM_INIT
The third one is attributes.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 for Examples
On Tuesday 03 March 2015 10:38:22 Thiago Macieira wrote: Yeah well, I think the above check contains(QT_CONFIG, c++11) won't hurt. I'd just do it globally in configure though (so that examples aren't automatically build for older compilers), instead of black/whitelisting single examples... I really meant leaving it unconditionally. People with old compilers will face compiler errors and they'll have to add one of the two options to get rid of them. If you want to write a config.test to check if the compiler has enough support, I recommend taking code from tests/auto/other/compiler, maybe even share. That way, if we find later that the check is insufficient, we should update the unit test too. Clang 3.6 results: Totals: 63 passed, 0 failed, 1 skipped, 0 blacklisted (the skip was runtimeArrays, which was removed from C++14) GCC 4.9 skips cxx14_constexpr, cxx14_aggregate_nsdmi, cxx14_variable_templates. ICC 15 skips all the C++14 stuff GCC 5 is running into a compilation error with variable templates. I'll need to investigate sometime before we add GCC 5 to the CI. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problem loading plugins with gcc 4.9.2
On Wednesday 04 March 2015 02:40:55 Aleix Pol wrote: On Tue, Mar 3, 2015 at 2:55 PM, Sergio Martins sergio.mart...@kdab.com wrote: Hi, So that you don't waste time pulling your hair out: plugin loading is broken with gcc 4.9.2 There's some clash between global static QFactoryLoader instances. Reproduced on Archlinux (and on Fedora by jpnurmi). I also hit this bug on ArchLinux. I solved it by downgrading from: 4.9.2-3 to 4.9.2-2 on these packages: lib32-gcc-libs gcc-libs gcc. Someone who can reproduce the bug, please file it with GCC. The test case seems quite simple (two .cpp files with two Q_GLOBAL_STATIC with the same name). Just remember to expand the Q_GLOBAL_STATIC macro before submitting. if that doesn't work, you'll need to reduce the testcase. Again, it should be quite evident which two .cpp files need to be reduced. In case the problem isn't triggered by just those two .cpp files, you can use the attached script, which I used to test an LTO issue with QtGui and GCC 5. The file listing should be up-to-date for Qt 5.4. Before you run it, you'll need to update the main linker command-line and the error detection logic. I suggest that you run the linker normally, just ensuring it ran successfully, then use nm to get the anonymous namespace symbols. If the count is wrong (not 8), then mark as error. You'll probably need to remove the --no-undefined option to allow the linker to succeed without the full list of files. Once you have the minimum set of sources that triggers the error, reduce the .cpp to the minimum. Then reduce the compiler and linker flags. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center test.pl Description: Perl program ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Problem loading plugins with gcc 4.9.2
Hi, So that you don't waste time pulling your hair out: plugin loading is broken with gcc 4.9.2 There's some clash between global static QFactoryLoader instances. Reproduced on Archlinux (and on Fedora by jpnurmi). Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problem loading plugins with gcc 4.9.2
And Ubuntu, i've had this issue for a long time and i thought i was the only one and thus only renamed all the loaders in the .cpp files and went on with it :D On Tue, Mar 3, 2015 at 2:55 PM, Sergio Martins sergio.mart...@kdab.com wrote: Hi, So that you don't waste time pulling your hair out: plugin loading is broken with gcc 4.9.2 There's some clash between global static QFactoryLoader instances. Reproduced on Archlinux (and on Fedora by jpnurmi). Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 for Examples
Make it unconditional and let people disable with -nomake tests or -no-compile-examples if they have older compilers. Why not make different example categories? One category, which has the same policies as Qt itself, i.e. it compiles with all the compilers Qt supports. Additionally a category, which uses all new stuff C++11 stuff. And perhaps an experimental cat, which is insane and requires C++2x --- ok, slight exaggeration. Then the cats could be disabled with -no-compile-examples, -no-compile-examples-modern, -no-compile-examples-insane. I was in several projects where I have been told: Don't use this feature, don't use that feature. Sometimes the reasons where understandable, sometimes I had the feeling the reason was the project manager was stuck in 98 and did not understand anything beyond that. Now it is not Qt's task to teach modern C++, but if examples using those new features help/convince other people to migrate, it also helps Qt. Guido ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Update and resubmit on reverted submission
On 2 mars 2015, at 04:24, Thiago Macieira thiago.macie...@intel.com wrote: On Monday 02 March 2015 00:31:08 Samuel Gaist wrote: Hi, I've had a submission merged but then reverted because of an unforeseen bug. I've updated the code, added a new test and wanted to push it again to keep the history and discussion going. Logically it failed since it's closed. Following qtqa's documentation, it seems that I have no choice but to make a new submission thus losing the discussion, am I right ? Correct. You need to submit a new one, with a new change-id. Ok, good, thanks for the confirmation Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 for Examples
On 3 Mar 2015, at 11:30, Guido Seifert warg...@gmx.de wrote: Make it unconditional and let people disable with -nomake tests or -no-compile-examples if they have older compilers. Why not make different example categories? One category, which has the same policies as Qt itself, i.e. it compiles with all the compilers Qt supports. Additionally a category, which uses all new stuff C++11 stuff. And perhaps an experimental cat, which is insane and requires C++2x --- ok, slight exaggeration. Schrödinger’s cat? Then the cats could be disabled with -no-compile-examples, -no-compile-examples-modern, -no-compile-examples-insane. Creator has those “tags” on the examples page (so that you can e.g. find all the examples that show off certain platforms, or that use QtQuick), so the easiest would be to tag whichever examples we get around to updating to use some c++11 features. I was in several projects where I have been told: Don't use this feature, don't use that feature. Sometimes the reasons where understandable, sometimes I had the feeling the reason was the project manager was stuck in 98 and did not understand anything beyond that. Now it is not Qt's task to teach modern C++, but if examples using those new features help/convince other people to migrate, it also helps Qt. and the ones who are “stuck” will use it as as an excuse not to use Qt, if none of the examples work on their compilers, or they just have mental blocks to understanding them. So we should probably start small. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 for Examples
-Original Message- From: development-bounces+kai.koehne=theqtcompany.com@qt- [...] 2.) Coding convention for C++11 constructs and set of permitted features: https://wiki.qt.io/index.php?title=Coding_Conventions#Conventions_for_ C.2B.2 B11_usage I didn't know this existed. That's a nice summary and a good start. I guess we'll expand it as necessary. What's missing from the list IMO is using QObject::connect with PointerToMemberFunction instead of SIGNAL(), SLOT(). I'd say we should think of raising the bar a little. How about making the examples require GCC 4.7 and VS 2012? Those are 4-year-old compilers by the time Qt 5.6 is released. Completely agree. contains(QT_CONFIG, c++11) is a very coarse qmake check for a given set of C++11 features it is unlikely to be useful to serve as enabler for converted examples. Workarounds might be to not compile examples on unsupported platforms in the CI anymore or we define a new qmake flag that precisely covers the required set of C++ features. The latter would certainly be more user friendly. Comments, suggestions and desires? Make it unconditional and let people disable with -nomake tests or -no- compile-examples if they have older compilers. Yeah well, I think the above check contains(QT_CONFIG, c++11) won't hurt. I'd just do it globally in configure though (so that examples aren't automatically build for older compilers), instead of black/whitelisting single examples... I'd also propose dropping the VS 2010 packages for either 5.5 or 5.6 and replace them with VS 2015. +1. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
