From jani.heikkinen at qt.io Fri Dec 1 09:02:54 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 1 Dec 2017 08:02:54 +0000 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: <15831512067729@web14o.yandex.ru> References: <3717608.CIl6TGCH48@tjmaciei-mobl1> <15831512067729@web14o.yandex.ru> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+jani.heikkinen=qt.io at qt- > project.org] On Behalf Of Konstantin Tokarev > Sent: torstai 30. marraskuuta 2017 20.49 > To: Thiago Macieira ; development at qt- > project.org > Subject: Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux > distribution > > > > 30.11.2017, 20:47, "Thiago Macieira" : > > See https://bugreports.qt.io/browse/QTBUG-64820 and > > http://lists.qt-project.org/pipermail/interest/2017-November/028766.ht > > ml > > > > The Qt 5.9.3 binaries were compiled by GCC 6, which is too new for the > > latest Ubuntu LTS (16.04). I urgently recommend: > > > >  1) find some older distro (possibly Ubuntu 16.04 LTS) to compile the > > 5.10 and further 5.9 binaries with. We will start using devtoolset-4 again, but in RHEL 7.4. It is easiest and safest change now & should be doable within 5.10.0 schedule. Work is already ongoing. > > > >  2) recompile the 5.9.3 binaries and post them. No changes to the > > source code, just rebuild. I understand that but still I think we shouldn't do this. Qt 5.9.4 is coming on January and I hope we can wait to fix this there. We are that hurry atm and even this is quite simple task it still takes quite much effort from us. One basic idea with this new release model is just this; if we found some regression it will be fixed quite soon with next patch release. So that's why I hope we can just add this in Qt 5.9.3 known issue & fix this in Qt 5.9.4 instead. br, Jani > > It seems that when RHEL was updated from 7.2 to 7.4 [1], devtoolset-6 was > installed instead of devtoolset-4 [2]. As we use artifacts from RHEL7 > configuration as official binaries, they started to require GCC 6 > > [1] https://codereview.qt-project.org/#/c/204675/38 > > [2] One of patches integrated before that provisioning change: > > https://testresults.qt.io/coin/api/results/qt/qtbase/1e813c55a1e3d07549cfe2d > d6fe3a927c3677c19/LinuxRHEL_7_2x86_64LinuxRHEL_7_2x86_64GCCqtci- > linux-RHEL-7.2-x86_64- > e1aea8Release_NoUseGoldLinker/2a48a3b7dcb9652b1532a3ad14de7580b5b9b > 1ee/build_1508179165/log.txt.gz > > > > > -- > > 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 From ville.voutilainen at gmail.com Fri Dec 1 10:08:05 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Fri, 1 Dec 2017 11:08:05 +0200 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: References: <3717608.CIl6TGCH48@tjmaciei-mobl1> <15831512067729@web14o.yandex.ru> Message-ID: On 1 December 2017 at 10:02, Jani Heikkinen wrote: >> > 2) recompile the 5.9.3 binaries and post them. No changes to the >> > source code, just rebuild. > > I understand that but still I think we shouldn't do this. Qt 5.9.4 is coming on January and I hope we can wait to fix this there. We are that hurry atm and even this is quite simple task it still takes quite much effort from us. One basic idea with this new release model is just this; if we found some regression it will be fixed quite soon with next patch release. So that's why I hope we can just add this in Qt 5.9.3 known issue & fix this in Qt 5.9.4 instead. OK by me, but let's please also strive to add an RTA test that shows this sort of problems, should they occur in the future. From marc.mutz at kdab.com Fri Dec 1 10:31:18 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 01 Dec 2017 10:31:18 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <2205331.XELMSDqlt1@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <8356435.nI9tCjiaGg@tjmaciei-mobl1> <2205331.XELMSDqlt1@tjmaciei-mobl1> Message-ID: <7d190cdc83c8cbe05c8f2d88be5e28a3@kdab.com> On 2017-11-30 22:13, Thiago Macieira wrote: > On Thursday, 30 November 2017 12:08:45 PST Marc Mutz wrote: >> Don't go off on a tangent here. I used concepts syntax to keep the >> example simple. I can post with std::enable_if, if you prefer :) > > Fair enough, I had not considered that. > >> Anyway, the point is the asymmetry of member functions. >> u"Hello".compare(string) does not compile in C++ (it does in Java), so >> everyone that wants to write a template like the op== above will have >> to >> re-invent qCompareStrings(). The Qt API rules stipulate that the >> common >> use case should be made simple (we do, we have member functions >> whereever we can add them), but make the rest possible. And that's >> where >> qCompareStrings() come in. It makes the remaining 5% (random number) >> possible. > > Why does anyone besides us need to write the op== like above? We have > access > to QtPrivate::qCompareStrings, so we can write the comparisons to our > string > objects. > > Once those operator<=> are there, what benefit is there in having the > API > public and documented? The spaceship operator solves the problem for qCompareStrings(). One could say we already have all relational operators for all combinations of string-like objects to solve it for the user _now_, but qCompareStrings(), like operator<=>() return the full information, while relational operators only return a subset. You know that, I know. I'm just mentioning it for completeness sake. And we have more than qCompareStrings(). How does operator<=> help with qFindString()/qIndexOf() (which is still missing)? Answer: it doesn't. There's no infix notation for find-in-string. And there probably never will be (fancy proposing operator=~, anyone?). [...] >> We all think we're smarter than the committee, yes. Maybe we are, but >> swarm intelligence suggests otherwise. > > To be clear: there's nothing wrong with adding constexpr where we can. > Constexpr string literals make a lot of sense. > > The flaw is in doing that in detriment to performance at runtime. EVERY > SINGLE > strlen function is SIMD-optimised, sometimes even multiple versions. > There's > even a dedicated instruction added to SSE4.2 to do that, plus the > original > 8086 way (rep scasb) which was slow for a long time and now is fast > again. > > I don't have the benchmarks to prove it, but my gut feeling is that the > SIMD > code becomes worth it very quickly (despite the call overhead), > sometime > between 8 and 16 characters in the string. > > https://godbolt.org/g/gBMykD Ah, but you said that the flaw was in the _standard_. But what you show are sub-optimal compiler implementations. There's nothing in the standard that prevents a compiler to implement char_traits::length() as a compiler intrinsic that can have different backends for constexpr and runtime evaluation. So, would the following be acceptable: 1. QSV uses char_traits::length() to calculate the length (that was my initial implementation, but it's constexpr only starting with C++17). Then QSV(Char*) is only constexpr in C++17. I can live with that. 2. You/Intel work on the compiler vendors to get char_traits::length() implemented as an intrinsic, with SIMD at runtime and compiler magic at compile-time? Then we fix the problem where it should be fixed, and just piggy-back on the more general solution. And it's easy to sell to QSV users why that ctor is not constexpr until C++17 (and we don't even need any #ifdefery in the implementation). What do you think? Thanks, Marc That is, unless compiler vendors haven't yet done this already. From evilruff at gmail.com Fri Dec 1 10:53:06 2017 From: evilruff at gmail.com (Yuri Alexandrov) Date: Fri, 1 Dec 2017 09:53:06 +0000 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: References: <3717608.CIl6TGCH48@tjmaciei-mobl1> <15831512067729@web14o.yandex.ru> , Message-ID: Am I right then thinking that only way to make 5.9.3 works on RH6 is to rebuild from sources as online installer is not working there due to glibc issues? Sent from Mail for Windows 10 ________________________________ From: Development on behalf of Ville Voutilainen Sent: Friday, December 1, 2017 12:08:05 PM To: Jani Heikkinen Cc: Thiago Macieira; development at qt-project.org Subject: Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution On 1 December 2017 at 10:02, Jani Heikkinen wrote: >> > 2) recompile the 5.9.3 binaries and post them. No changes to the >> > source code, just rebuild. > > I understand that but still I think we shouldn't do this. Qt 5.9.4 is coming on January and I hope we can wait to fix this there. We are that hurry atm and even this is quite simple task it still takes quite much effort from us. One basic idea with this new release model is just this; if we found some regression it will be fixed quite soon with next patch release. So that's why I hope we can just add this in Qt 5.9.3 known issue & fix this in Qt 5.9.4 instead. OK by me, but let's please also strive to add an RTA test that shows this sort of problems, should they occur in the future. _______________________________________________ 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 annulen at yandex.ru Fri Dec 1 11:01:19 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 01 Dec 2017 13:01:19 +0300 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: References: <3717608.CIl6TGCH48@tjmaciei-mobl1> <15831512067729@web14o.yandex.ru> , Message-ID: <150471512122479@web12o.yandex.ru> 01.12.2017, 12:54, "Yuri Alexandrov" : > Am I right then thinking that only way to make 5.9.3 works on RH6 is to rebuild from sources as online installer is not working there due to glibc issues? Same should be true for all previous releases starting from 5.8.0, as all binaries since then are built on RHEL7 and therefore require glibc 2.14 > > Sent from Mail for Windows 10 > > ---------------------------------------- > From: Development on behalf of Ville Voutilainen > Sent: Friday, December 1, 2017 12:08:05 PM > To: Jani Heikkinen > Cc: Thiago Macieira; development at qt-project.org > Subject: Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution > > On 1 December 2017 at 10:02, Jani Heikkinen wrote: >>> >  2) recompile the 5.9.3 binaries and post them. No changes to the >>> > source code, just rebuild. >> >> I understand that but still I think we shouldn't do this. Qt 5.9.4 is coming on January and I hope we can wait to fix this there. We are that hurry atm and even this is quite simple task it still takes quite much effort from us. One basic idea with this new release model is just this; if we found some regression it will be fixed quite soon with next patch release. So that's why I hope we can just add this in Qt 5.9.3 known issue & fix this in Qt 5.9.4 instead. > > OK by me, but let's please also strive to add an RTA test that shows > this sort of problems, should they occur in the future. > _______________________________________________ > 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 evilruff at gmail.com Fri Dec 1 11:08:44 2017 From: evilruff at gmail.com (Yuri Alexandrov) Date: Fri, 1 Dec 2017 10:08:44 +0000 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: <150471512122479@web12o.yandex.ru> References: <3717608.CIl6TGCH48@tjmaciei-mobl1> <15831512067729@web14o.yandex.ru> , , <150471512122479@web12o.yandex.ru> Message-ID: Ok.. as we just moved from 5.7 to 5.9.3 =) so, nice surprise. Sent from Mail for Windows 10 ________________________________ From: Konstantin Tokarev Sent: Friday, December 1, 2017 1:01:19 PM To: Yuri Alexandrov; development at qt-project.org Subject: Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution 01.12.2017, 12:54, "Yuri Alexandrov" : > Am I right then thinking that only way to make 5.9.3 works on RH6 is to rebuild from sources as online installer is not working there due to glibc issues? Same should be true for all previous releases starting from 5.8.0, as all binaries since then are built on RHEL7 and therefore require glibc 2.14 > > Sent from Mail for Windows 10 > > ---------------------------------------- > From: Development on behalf of Ville Voutilainen > Sent: Friday, December 1, 2017 12:08:05 PM > To: Jani Heikkinen > Cc: Thiago Macieira; development at qt-project.org > Subject: Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution > > On 1 December 2017 at 10:02, Jani Heikkinen wrote: >>> > 2) recompile the 5.9.3 binaries and post them. No changes to the >>> > source code, just rebuild. >> >> I understand that but still I think we shouldn't do this. Qt 5.9.4 is coming on January and I hope we can wait to fix this there. We are that hurry atm and even this is quite simple task it still takes quite much effort from us. One basic idea with this new release model is just this; if we found some regression it will be fixed quite soon with next patch release. So that's why I hope we can just add this in Qt 5.9.3 known issue & fix this in Qt 5.9.4 instead. > > OK by me, but let's please also strive to add an RTA test that shows > this sort of problems, should they occur in the future. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From evilruff at gmail.com Fri Dec 1 11:10:00 2017 From: evilruff at gmail.com (Yuri Alexandrov) Date: Fri, 1 Dec 2017 10:10:00 +0000 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: <150471512122479@web12o.yandex.ru> References: <3717608.CIl6TGCH48@tjmaciei-mobl1> <15831512067729@web14o.yandex.ru> , , <150471512122479@web12o.yandex.ru> Message-ID: Ok.. as we just moved from 5.7 to 5.9.3 =) so, nice surprise. Sent from Mail for Windows 10 ________________________________ From: Konstantin Tokarev Sent: Friday, December 1, 2017 1:01:19 PM To: Yuri Alexandrov; development at qt-project.org Subject: Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution 01.12.2017, 12:54, "Yuri Alexandrov" : > Am I right then thinking that only way to make 5.9.3 works on RH6 is to rebuild from sources as online installer is not working there due to glibc issues? Same should be true for all previous releases starting from 5.8.0, as all binaries since then are built on RHEL7 and therefore require glibc 2.14 > > Sent from Mail for Windows 10 > > ---------------------------------------- > From: Development on behalf of Ville Voutilainen > Sent: Friday, December 1, 2017 12:08:05 PM > To: Jani Heikkinen > Cc: Thiago Macieira; development at qt-project.org > Subject: Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution > > On 1 December 2017 at 10:02, Jani Heikkinen wrote: >>> > 2) recompile the 5.9.3 binaries and post them. No changes to the >>> > source code, just rebuild. >> >> I understand that but still I think we shouldn't do this. Qt 5.9.4 is coming on January and I hope we can wait to fix this there. We are that hurry atm and even this is quite simple task it still takes quite much effort from us. One basic idea with this new release model is just this; if we found some regression it will be fixed quite soon with next patch release. So that's why I hope we can just add this in Qt 5.9.3 known issue & fix this in Qt 5.9.4 instead. > > OK by me, but let's please also strive to add an RTA test that shows > this sort of problems, should they occur in the future. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar.roth at gmx.de Fri Dec 1 11:18:43 2017 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Fri, 1 Dec 2017 11:18:43 +0100 Subject: [Development] Qt 5.10.0 RC out In-Reply-To: References: Message-ID: The wiki now says: Release Candidate 2 Week 48 /2017 1.12.2017 Release Candidate 2 4.12.2017    Why two dates for rc2? Regards, Gunnar Roth _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development] From evilruff at gmail.com Fri Dec 1 11:12:47 2017 From: evilruff at gmail.com (Yuri Alexandrov) Date: Fri, 1 Dec 2017 10:12:47 +0000 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: References: <3717608.CIl6TGCH48@tjmaciei-mobl1> <15831512067729@web14o.yandex.ru> , Message-ID: > I understand that but still I think we shouldn't do this. Qt 5.9.4 is coming on January and I hope we can wait to fix this there. We are that hurry atm > and even this is quite simple task it still takes quite much effort from us. One basic idea with this new release model is just this; if we found some > regression it will be fixed quite soon with next patch release. So that's why I hope we can just add this in Qt 5.9.3 known issue & fix this in Qt 5.9.4 > instead. To be honest I have mixed feelings about that, from one point of view I understand that rebuilding now and updating installers is something which takes time and resources, but from another point of view think about commercial customers (like myself) which have expectations and plans and now I have to spend own time and resources to fix something which is a deployment bug actually, as I have to support in a system I deliver RH6 and Ubuntu 16. I am not really to blame, just to say that its not really only about release model, but about people who are using it and in certain way pay the bill. Regards, Yuri -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Fri Dec 1 11:42:03 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 1 Dec 2017 10:42:03 +0000 Subject: [Development] Fw: Qt 5.10 RC2 is out In-Reply-To: References: Message-ID: Hi all, Qt 5.10 RC2 is released today. Delta to RC1 as an attachment. Unfortunately there is still at least two issues in RC2 which must be fixed before final Qt 5.10.0 release: QTBUG-64868 & QTBUG-64820. Luckily we have fixes for both available & we are planning to get RC3 out on Monday. And if it will be finally ok for the release we will release Qt 5.10.0 on Thursday as planned. Instructions how to get the release are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. br, Jani -------------- next part -------------- A non-text attachment was scrubbed... Name: qt5.10-rc1-delta-rc2-commits Type: application/octet-stream Size: 1357 bytes Desc: qt5.10-rc1-delta-rc2-commits URL: From marc.mutz at kdab.com Fri Dec 1 15:21:38 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 01 Dec 2017 15:21:38 +0100 Subject: [Development] New BiC gotcha: adding noexcept Message-ID: <48f689b5e4bef513e5f96d41682262b7@kdab.com> Hi, I just realised: Since C++17, noexcept is part of the mangled name. That means that adding noexcept to an exported function is BiC now! Please be aware of this when reviewing patches. Since non-template inline members of exported classes are exported, too, in MSVC Debug builds, the same is true for them: You can no longer add noexcept to inline functions of exported classes (yet another reason to avoid exporting non-polymorphic classes wholesale; individually export single functions instead). Do we need a new macro (Q_DECL_CPP17_COMPATIBLE_NOTHROW?) that expands to nothing on MSVC Debug builds? Or should we simply dodge the issue and declare debug builds of Qt not subject to BC on MSVC? Thanks, Marc From marc.mutz at kdab.com Fri Dec 1 15:41:18 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 01 Dec 2017 15:41:18 +0100 Subject: [Development] New BiC gotcha: adding noexcept In-Reply-To: <48f689b5e4bef513e5f96d41682262b7@kdab.com> References: <48f689b5e4bef513e5f96d41682262b7@kdab.com> Message-ID: On 2017-12-01 15:21, Marc Mutz wrote: > Hi, > > I just realised: Since C++17, noexcept is part of the mangled name. > That means that adding noexcept to an exported function is BiC now! This is not correct, after all. The name mangling of functions does not change, since you can't overload on noexcept(true)/noexcept(false). It's the name of function pointer _types_ that change. That's not to say that there are no BiC issues lurking there (or, more probable, more SiC issues than what was fixed so far), but the above was false alarm. Pfew. Thanks, Marc From aapo.keskimolo at qt.io Fri Dec 1 19:07:54 2017 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Fri, 1 Dec 2017 18:07:54 +0000 Subject: [Development] Coin Network Problems Message-ID: Lately, many users of CI have been suffering from build and test agents failing because of timeouts. As one of the causes, we have found out that there are unused network interfaces that are not removed when opennebula daemon disposed the VMs. As a result, this will cause MAC address conflicts because those addresses are quickly reassigned to new vms which then leads to failures with launching the agent. As a work-around, I have implemented a cronjob that will automatically remove these unused interfaces which will solve this problem for the time being. The actual root cause with the permanent solution is still being investigated. Kind regards/Ystävällisin terveisin, Aapo Keskimölö -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Dec 1 19:26:28 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 1 Dec 2017 10:26:28 -0800 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <7d190cdc83c8cbe05c8f2d88be5e28a3@kdab.com> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <2205331.XELMSDqlt1@tjmaciei-mobl1> <7d190cdc83c8cbe05c8f2d88be5e28a3@kdab.com> Message-ID: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> On Friday, 1 December 2017 01:31:18 PST Marc Mutz wrote: > > Once those operator<=> are there, what benefit is there in having the > > API > > public and documented? > > The spaceship operator solves the problem for qCompareStrings(). One > could say we already have all relational operators for all combinations > of string-like objects to solve it for the user _now_, but > qCompareStrings(), like operator<=>() return the full information, while > relational operators only return a subset. You know that, I know. I'm > just mentioning it for completeness sake. Ok, so your case is when you have two string-like objects and you want to get the ordering result. Since we don't yet have the spaceship operator, you have to call the compare() function. But you can't do that in clean, generic code because you don't know if the first argument is an actual QString or QStringView, or if it's just a char16_t literal. Is that it? Why can't they write QStringView(s1).compare(s2) ? > And we have more than qCompareStrings(). How does operator<=> help with > qFindString()/qIndexOf() (which is still missing)? Answer: it doesn't. > There's no infix notation for find-in-string. And there probably never > will be (fancy proposing operator=~, anyone?). In both cases, explain why we need to provide that. Why can't they write QStringView(s1).indexOf(s2) ? > Ah, but you said that the flaw was in the _standard_. But what you show > are sub-optimal compiler implementations. There's nothing in the > standard that prevents a compiler to implement char_traits::length() as > a compiler intrinsic that can have different backends for constexpr and > runtime evaluation. The flaw is in the standard because it does not allow me to implement an optimised version using whichever tools I want to. > So, would the following be acceptable: > > 1. QSV uses char_traits::length() to calculate the length > (that was my initial implementation, but it's constexpr only starting > with C++17). Then QSV(Char*) is only constexpr in C++17. I can live with > that. No, because... > 2. You/Intel work on the compiler vendors to get > char_traits::length() implemented as an intrinsic, with SIMD > at runtime and compiler magic at compile-time? We should do that anyway, but depending on it means we'll have performance in 2021 or later (just look at how we have to build Linux binaries with GCC 4.8). The flaw exists today. My choice for fixing it is to sacrifice the part we don't really need: the constexprness. > Then we fix the problem where it should be fixed, and just piggy-back on > the more general solution. And it's easy to sell to QSV users why that > ctor is not constexpr until C++17 (and we don't even need any #ifdefery > in the implementation). > > What do you think? We should fix the standard and we should help fix the implementations. But I'm not accepting a performance drawback for 3 or more years until then. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Dec 1 19:28:37 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 1 Dec 2017 10:28:37 -0800 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: References: <3717608.CIl6TGCH48@tjmaciei-mobl1> <15831512067729@web14o.yandex.ru> Message-ID: <2460019.aNOcNdcHOr@tjmaciei-mobl1> On Friday, 1 December 2017 00:02:54 PST Jani Heikkinen wrote: > I understand that but still I think we shouldn't do this. Qt 5.9.4 is coming > on January and I hope we can wait to fix this there. I don't think we can wait. This is not a regresion that will be fixed. This is almost a P0 for our users, since they cannot use Qt 5.9.3 as built. It's not really P0 because they can rebuild from sources. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Dec 1 19:29:00 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 1 Dec 2017 10:29:00 -0800 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: References: <3717608.CIl6TGCH48@tjmaciei-mobl1> Message-ID: <1629590.KCxkuJzVlK@tjmaciei-mobl1> On Friday, 1 December 2017 01:53:06 PST Yuri Alexandrov wrote: > Am I right then thinking that only way to make 5.9.3 works on RH6 is to > rebuild from sources as online installer is not working there due to glibc > issues? RHEL 6 is too old, even despite this issue. You need to build from sources in very old distros. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Dec 1 19:31:50 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 1 Dec 2017 10:31:50 -0800 Subject: [Development] New BiC gotcha: adding noexcept In-Reply-To: References: <48f689b5e4bef513e5f96d41682262b7@kdab.com> Message-ID: <3270823.M5CYhcppvg@tjmaciei-mobl1> On Friday, 1 December 2017 06:41:18 PST Marc Mutz wrote: > On 2017-12-01 15:21, Marc Mutz wrote: > > Hi, > > > > I just realised: Since C++17, noexcept is part of the mangled name. > > That means that adding noexcept to an exported function is BiC now! > > This is not correct, after all. The name mangling of functions does not > change, since you can't overload on noexcept(true)/noexcept(false). It's > the name of function pointer _types_ that change. That's not to say that > there are no BiC issues lurking there (or, more probable, more SiC > issues than what was fixed so far), but the above was false alarm. Pfew. Right, you almost gave me a heart-attack! The new mangling only shows up where __cpp_noexcept_function_type takes effect, which is on function pointers. So anything that takes a noexcept function pointer (including template parameters) can have different mangling. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From enmarantispam at gmail.com Fri Dec 1 19:32:05 2017 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Fri, 1 Dec 2017 21:32:05 +0300 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: References: <3717608.CIl6TGCH48@tjmaciei-mobl1> Message-ID: You will not be able to use compiled qt installer on centos 6 anyway. It's our standard installation OS and we just compile Qt from source because glibc is incompatible On Thu, Nov 30, 2017 at 9:48 PM, probono wrote: > On Thu, Nov 30, 2017 at 7:29 PM, Ville Voutilainen > wrote: > > On 30 November 2017 at 19:47, Thiago Macieira > wrote: > >> See https://bugreports.qt.io/browse/QTBUG-64820 and > >> http://lists.qt-project.org/pipermail/interest/2017- > November/028766.html > >> > >> The Qt 5.9.3 binaries were compiled by GCC 6, which is too new for the > latest > >> Ubuntu LTS (16.04). > > Yes. Please _at least_ support the oldest still-supported LTS version, > which is 14.04 at this time. CentOS 6 users might also still exist. > Thanks! > _______________________________________________ > 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 jeanmichael.celerier at gmail.com Fri Dec 1 19:59:48 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Fri, 1 Dec 2017 19:59:48 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <2205331.XELMSDqlt1@tjmaciei-mobl1> <7d190cdc83c8cbe05c8f2d88be5e28a3@kdab.com> <2591442.fx7fcFLXIJ@tjmaciei-mobl1> Message-ID: > (just look at how we have to build Linux binaries with GCC 4.8). Isn't it possible to use a newer GCC but to tell it to use GCC 4.8's ABI ? eg to target GCC 4.8, by using -fabi-version=2 -D_GLIBCXX_USE_CXX11_ABI=0 Best, ------- Jean-Michaël Celerier http://www.jcelerier.name On Fri, Dec 1, 2017 at 7:26 PM, Thiago Macieira wrote: > On Friday, 1 December 2017 01:31:18 PST Marc Mutz wrote: > > > Once those operator<=> are there, what benefit is there in having the > > > API > > > public and documented? > > > > The spaceship operator solves the problem for qCompareStrings(). One > > could say we already have all relational operators for all combinations > > of string-like objects to solve it for the user _now_, but > > qCompareStrings(), like operator<=>() return the full information, while > > relational operators only return a subset. You know that, I know. I'm > > just mentioning it for completeness sake. > > Ok, so your case is when you have two string-like objects and you want to > get > the ordering result. Since we don't yet have the spaceship operator, you > have > to call the compare() function. But you can't do that in clean, generic > code > because you don't know if the first argument is an actual QString or > QStringView, or if it's just a char16_t literal. > > Is that it? > > Why can't they write > > QStringView(s1).compare(s2) ? > > > And we have more than qCompareStrings(). How does operator<=> help with > > qFindString()/qIndexOf() (which is still missing)? Answer: it doesn't. > > There's no infix notation for find-in-string. And there probably never > > will be (fancy proposing operator=~, anyone?). > > In both cases, explain why we need to provide that. Why can't they write > > QStringView(s1).indexOf(s2) ? > > > Ah, but you said that the flaw was in the _standard_. But what you show > > are sub-optimal compiler implementations. There's nothing in the > > standard that prevents a compiler to implement char_traits::length() as > > a compiler intrinsic that can have different backends for constexpr and > > runtime evaluation. > > The flaw is in the standard because it does not allow me to implement an > optimised version using whichever tools I want to. > > > So, would the following be acceptable: > > > > 1. QSV uses char_traits::length() to calculate the length > > (that was my initial implementation, but it's constexpr only starting > > with C++17). Then QSV(Char*) is only constexpr in C++17. I can live with > > that. > > No, because... > > > 2. You/Intel work on the compiler vendors to get > > char_traits::length() implemented as an intrinsic, with SIMD > > at runtime and compiler magic at compile-time? > > We should do that anyway, but depending on it means we'll have performance > in > 2021 or later (just look at how we have to build Linux binaries with GCC > 4.8). > > The flaw exists today. My choice for fixing it is to sacrifice the part we > don't really need: the constexprness. > > > Then we fix the problem where it should be fixed, and just piggy-back on > > the more general solution. And it's easy to sell to QSV users why that > > ctor is not constexpr until C++17 (and we don't even need any #ifdefery > > in the implementation). > > > > What do you think? > > We should fix the standard and we should help fix the implementations. But > I'm > not accepting a performance drawback for 3 or more years until then. > > -- > 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 evilruff at gmail.com Fri Dec 1 20:53:30 2017 From: evilruff at gmail.com (Yuri Alexandrov) Date: Fri, 1 Dec 2017 19:53:30 +0000 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: <2460019.aNOcNdcHOr@tjmaciei-mobl1> References: <3717608.CIl6TGCH48@tjmaciei-mobl1> <15831512067729@web14o.yandex.ru> , <2460019.aNOcNdcHOr@tjmaciei-mobl1> Message-ID: Is there any plans for an out-of-schedule update about this (if plan exists at all =), as I have to deliver something end of next week, so if it’s not going to happen next week I have to start making steps to rebuild things myself. Regards, Yuri From: Thiago Macieira Sent: Friday, December 1, 2017 9:28 PM To: development at qt-project.org Subject: Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution On Friday, 1 December 2017 00:02:54 PST Jani Heikkinen wrote: > I understand that but still I think we shouldn't do this. Qt 5.9.4 is coming > on January and I hope we can wait to fix this there. I don't think we can wait. This is not a regresion that will be fixed. This is almost a P0 for our users, since they cannot use Qt 5.9.3 as built. It's not really P0 because they can rebuild from sources. -- 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 marc.mutz at kdab.com Fri Dec 1 20:57:33 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 01 Dec 2017 20:57:33 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <2205331.XELMSDqlt1@tjmaciei-mobl1> <7d190cdc83c8cbe05c8f2d88be5e28a3@kdab.com> <2591442.fx7fcFLXIJ@tjmaciei-mobl1> Message-ID: <47e0db35cf04ca1ea86471dfb4fd7470@kdab.com> On 2017-12-01 19:26, Thiago Macieira wrote: > On Friday, 1 December 2017 01:31:18 PST Marc Mutz wrote: >> > Once those operator<=> are there, what benefit is there in having the >> > API >> > public and documented? >> >> The spaceship operator solves the problem for qCompareStrings(). One >> could say we already have all relational operators for all >> combinations >> of string-like objects to solve it for the user _now_, but >> qCompareStrings(), like operator<=>() return the full information, >> while >> relational operators only return a subset. You know that, I know. I'm >> just mentioning it for completeness sake. > > Ok, so your case is when you have two string-like objects and you want > to get > the ordering result. Since we don't yet have the spaceship operator, > you have > to call the compare() function. But you can't do that in clean, generic > code > because you don't know if the first argument is an actual QString or > QStringView, or if it's just a char16_t literal. > > Is that it? > > Why can't they write > > QStringView(s1).compare(s2) ? I think you owe me a bit more thought on an answer to a mail of mine that that :P A quick look at the qCompareString() overload set will answer this question (hint: the lhs is not always QStringView). >> Ah, but you said that the flaw was in the _standard_. But what you >> show >> are sub-optimal compiler implementations. There's nothing in the >> standard that prevents a compiler to implement char_traits::length() >> as >> a compiler intrinsic that can have different backends for constexpr >> and >> runtime evaluation. > > The flaw is in the standard because it does not allow me to implement > an > optimised version using whichever tools I want to. The standard is not obliged to publicly give you all the plumbing to re-implement the standard library. The lack of plumbing is _sometimes_ a flaw in the standard, yes (std::invoke), but not always. You are supposed to use the standard library functionality, not re-implement it. In this case, the interface is char_traits::length, it exists on all supported platforms and does what we'd like it to do, incl., from C++17 on, constexpr. >> So, would the following be acceptable: >> >> 1. QSV uses char_traits::length() to calculate the length >> (that was my initial implementation, but it's constexpr only starting >> with C++17). Then QSV(Char*) is only constexpr in C++17. I can live >> with >> that. > > No, because... > >> 2. You/Intel work on the compiler vendors to get >> char_traits::length() implemented as an intrinsic, with SIMD >> at runtime and compiler magic at compile-time? > > We should do that anyway, but depending on it means we'll have > performance in > 2021 or later (just look at how we have to build Linux binaries with > GCC 4.8). Since char_traits::length would be called from inline code in QSV, its performance does not depend on how Qt was compiled, but on what the user's compiler is capable of. Also, presumably, the compiler was already optimizing char_traits::length() back when it wasn't constexpr (in C++11+14) and now has to implement something to not regress on runtime performance while still meeting constexpr restrictions. If it doesn't, then it's not our problem. It's SEP. And that is good. Pick your battles. > The flaw exists today. My choice for fixing it is to sacrifice the part > we > don't really need: the constexprness. Fixing it in Qt is limiting both Qt and the standard library. Don't do that. The same is true, btw, of QMutex. Qt takes pride in how QMutex is faster than std::mutex. I think it's a shame. It shows that you didn't go the next step and get std::mutex fixed. Having QMutex not use std::mutex means that tsan doesn't work correctly, for one. Here, too, the "easy" local "fix" is to the detriment of both the standard library (slower-than-necessary mutex operations) and Qt (failure to work with tsan). This habit of cocooning might have worked out ok when Qt was years ahead of the C++ standard library. But since those times in the 2000s, C++ has overtaken Qt in all aspects the committee decided to take on. Qt will have to adapt to this new reality or degrade to insignificance. Ride the wave or drown. As I said elsewhere: innovate, don't replicate. See the bigger picture here: Where are the patches that integrate Qt's event system and signal/slots mechanism with Coroutines, to name just one? Instead you celebrate the perceived failures of the standard and Qt's ability to "fix" them by writing a SIMD strlen or take the null state of a Qt value class to optimize QOptional size. This pattern repeats and repeats. V8 fork, anyone? When will Qt _finally_ learn? :) I said in my talks about QStringView that it's existential for Qt to get off its own container classes. I shall in the future extend that statement to anything that overlaps with std. I explicitly do not exclude QString here, even though it's exempt for the time being. But people _do_ talk about a std::text_view, and it _will_ support utf8 strings and that, in combination, _will_ degrade QString to insignificance. When Coroutines and ASIO land in C++, C++ will magically gain a cross-platform event loop. And more likely than not, you will have to integrate with it using Coroutines, futures and other awaitables, not the classic way of QAbstractEventDispatcher. It does not take a leap of imagination to assume that Coroutines TS will spark a ton of reactive GUI libraries for C++, incl. cross-platform ones. Qt needs to be prepared for that day. And the only way to prepare is to start working on innovative stuff and work with its various upstreams more, incl. the standard committee, and innovate. Stop. Fixing. Stuff. Locally. Get. Involved. Don't. Kodak. Qt. >> Then we fix the problem where it should be fixed, and just piggy-back >> on >> the more general solution. And it's easy to sell to QSV users why that >> ctor is not constexpr until C++17 (and we don't even need any >> #ifdefery >> in the implementation). >> >> What do you think? > > We should fix the standard and we should help fix the implementations. > But I'm > not accepting a performance drawback for 3 or more years until then. Pick your battles. I offered a compromise. I think it's a good one. And I think you're seriously overestimating the effect of your change. Not because it doesn't give a large performance boost, when exercised (I'm sure it does), but simply due to the fact that that code will be exercised very rarely. And, when actually exercised, the smaller i-cache footprint of "my" function might just beat "your" high-performance function in wall-clock time. Yes, in a library, every missed optimisation is some user's performance bottleneck. But we have an easy solution for that: people should be able to find in the ctor's documentation the recommendation to use qustrlen() manually. Thanks, Marc From thiago.macieira at intel.com Fri Dec 1 21:35:34 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 1 Dec 2017 12:35:34 -0800 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <2591442.fx7fcFLXIJ@tjmaciei-mobl1> Message-ID: <2022492.eaBp0N9IHS@tjmaciei-mobl1> On Friday, 1 December 2017 10:59:48 PST Jean-Michaël Celerier wrote: > > (just look at how we have to build Linux binaries with GCC 4.8). > > Isn't it possible to use a newer GCC but to tell it to use GCC 4.8's ABI ? > eg to target GCC 4.8, by using -fabi-version=2 -D_GLIBCXX_USE_CXX11_ABI=0 Don't tempt fate. In theory, it's possible to use GCC 6 against an old set of libstdc++ headers. I don't know if the GCC devs officially support this (Ville, can you chime in?). I wouldn't try. Just use an older GCC. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Dec 1 21:54:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 1 Dec 2017 12:54:01 -0800 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <47e0db35cf04ca1ea86471dfb4fd7470@kdab.com> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <47e0db35cf04ca1ea86471dfb4fd7470@kdab.com> Message-ID: <13655885.mOggW4fEAN@tjmaciei-mobl1> On Friday, 1 December 2017 11:57:33 PST Marc Mutz wrote: > > Why can't they write > > > > QStringView(s1).compare(s2) ? > > I think you owe me a bit more thought on an answer to a mail of mine > that that :P > A quick look at the qCompareString() overload set will answer this > question (hint: the lhs is not always QStringView). I understand it isn't. But can't QStringView be constructed from any StringLike? What overhead do you get with the solution above that you wouldn't by calling qCompareString directly? > > The flaw is in the standard because it does not allow me to implement > > an > > optimised version using whichever tools I want to. > > The standard is not obliged to publicly give you all the plumbing to > re-implement the standard library. Most of it, it has to. The standard library is written in C++. The only exceptions should be chapter 21 "Language support library". > The lack of plumbing is _sometimes_ a > flaw in the standard, yes (std::invoke), but not always. You are > supposed to use the standard library functionality, not re-implement it. > In this case, the interface is char_traits::length, it exists on all > supported platforms and does what we'd like it to do, incl., from C++17 > on, constexpr. Except that it's not efficient. In fact, it *used* to be efficient in libc++ for char (strlen) and wchar_t (wcslen), but ceased to be because of the C++17 requirement for constexpr. I'm not accepting a performance regression. > >> 2. You/Intel work on the compiler vendors to get > >> char_traits::length() implemented as an intrinsic, with SIMD > >> at runtime and compiler magic at compile-time? > > > > We should do that anyway, but depending on it means we'll have > > performance in > > 2021 or later (just look at how we have to build Linux binaries with > > GCC 4.8). > > Since char_traits::length would be called from inline code in QSV, its > performance does not depend on how Qt was compiled, but on what the > user's compiler is capable of. Also, presumably, the compiler was > already optimizing char_traits::length() back when it wasn't constexpr > (in C++11+14) and now has to implement something to not regress on > runtime performance while still meeting constexpr restrictions. If it > doesn't, then it's not our problem. It's SEP. And that is good. Pick > your battles. I have picked my battles. As I said above, it used to be efficient in libc++ (using wcslen) then was made not to be so. See libcxx commit 291741 "Implement P0426: Constexpr for std::char_traits". Fortunately, I now see the LLVM developers applied the same hacky solution for libc++ that GCC devs did for libstdc++ to get performance back again. Also note in both cases this applies only to char and wchar_t. char16_t is not fixed. > > The flaw exists today. My choice for fixing it is to sacrifice the part > > we > > don't really need: the constexprness. > > Fixing it in Qt is limiting both Qt and the standard library. Don't do > that. I wouldn't mind co-authoring a paper about this. But we cannot wait for C++20 for it to be accepted for performance to pick back up. > > The same is true, btw, of QMutex. Qt takes pride in how QMutex is faster > than std::mutex. I think it's a shame. It shows that you didn't go the > next step and get std::mutex fixed. Having QMutex not use std::mutex > means that tsan doesn't work correctly, for one. Here, too, the "easy" > local "fix" is to the detriment of both the standard library > (slower-than-necessary mutex operations) and Qt (failure to work with > tsan). There's nothing wrong with std::mutex's definition. It can be made as efficient as QMutex, more than what QMutex is today and closer to what I have made it for Qt 6. It's just QoI: the libc++ and libstdc++ implementation operate on top of a pthread_mutex_t. If they ditch that, like we did, they can get the performance. It's an ABI-breaking change, though, because of std::mutex::native_handle_type. > This habit of cocooning might have worked out ok when Qt was years ahead > of the C++ standard library. But since those times in the 2000s, C++ has > overtaken Qt in all aspects the committee decided to take on. Qt will > have to adapt to this new reality or degrade to insignificance. Ride the > wave or drown. The corollary of what you're saying is that we need to continue innovating. That's what I believe I'm doing. And, again, where I think the committee got it wrong, I will NOT follow suit. Ditto for implementations, see QRandomGenerator. > As I said elsewhere: innovate, don't replicate. See the bigger picture > here: Where are the patches that integrate Qt's event system and > signal/slots mechanism with Coroutines, to name just one? Instead you > celebrate the perceived failures of the standard and Qt's ability to > "fix" them by writing a SIMD strlen or take the null state of a Qt value > class to optimize QOptional size. > > This pattern repeats and repeats. V8 fork, anyone? When will Qt > _finally_ learn? :) I said in my talks about QStringView that it's > existential for Qt to get off its own container classes. I shall in the > future extend that statement to anything that overlaps with std. You and I disagree. > I explicitly do not exclude QString here, even though it's exempt for > the time being. But people _do_ talk about a std::text_view, and it > _will_ support utf8 strings and that, in combination, _will_ degrade > QString to insignificance. > > When Coroutines and ASIO land in C++, C++ will magically gain a > cross-platform event loop. And more likely than not, you will have to > integrate with it using Coroutines, futures and other awaitables, not > the classic way of QAbstractEventDispatcher. It does not take a leap of > imagination to assume that Coroutines TS will spark a ton of reactive > GUI libraries for C++, incl. cross-platform ones. Qt needs to be > prepared for that day. And the only way to prepare is to start working > on innovative stuff and work with its various upstreams more, incl. the > standard committee, and innovate. Stop. Fixing. Stuff. Locally. Get. > Involved. Don't. Kodak. Qt. > -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Dec 1 21:53:39 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 01 Dec 2017 21:53:39 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <47e0db35cf04ca1ea86471dfb4fd7470@kdab.com> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <2205331.XELMSDqlt1@tjmaciei-mobl1> <7d190cdc83c8cbe05c8f2d88be5e28a3@kdab.com> <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <47e0db35cf04ca1ea86471dfb4fd7470@kdab.com> Message-ID: <21320de941293bad1695c4523bde4a03@kdab.com> On 2017-12-01 20:57, Marc Mutz wrote: > V8 fork, anyone? Or was it V4? ETOOMANYJSENGINES From ville.voutilainen at gmail.com Fri Dec 1 22:37:05 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Fri, 1 Dec 2017 23:37:05 +0200 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <2022492.eaBp0N9IHS@tjmaciei-mobl1> References: <2662207.B6jXvkEcQG@tjmaciei-mobl1> <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <2022492.eaBp0N9IHS@tjmaciei-mobl1> Message-ID: On 1 December 2017 at 22:35, Thiago Macieira wrote: > In theory, it's possible to use GCC 6 against an old set of libstdc++ headers. > > I don't know if the GCC devs officially support this (Ville, can you chime > in?). There's no attempt by GCC maintainers to make a newer compiler work with the older libstdc++ versions. They probably work, considering that the old library probably doesn't use any intrinsics and such the newer compiler doesn't have (modulo things that have been removed for one reason or another), but bug reports for such combinations are likely going to be outright rejected as invalid. For example, if there's some code in an old libstdc++ that the newer compiler doesn't accept, there's going to be exactly zero effort to fix that. From philwave at gmail.com Fri Dec 1 23:12:05 2017 From: philwave at gmail.com (Philippe) Date: Fri, 01 Dec 2017 23:12:05 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <47e0db35cf04ca1ea86471dfb4fd7470@kdab.com> References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <47e0db35cf04ca1ea86471dfb4fd7470@kdab.com> Message-ID: <20171201231204.5809.6F0322A@gmail.com> >>it's existential for Qt to get off its own container classes. >>I shall in the future extend that statement to anything that overlaps >>with std. Two points to keep in mind: 1) the std implementation varies with compiler vendors, each one with a different set of bugs, unit tests and sometimes performance. While with Qt, the implementation is more uniform. This to say, I feel more secure using Qt implementations for an application that runs on multiple platforms. And cross-platform is the core business of Qt... 2) a majority of Qt users are not C++ wizards, and ease of use / intuitive api, is of primary importance... std does not always shine here. Philippe On Fri, 01 Dec 2017 20:57:33 +0100 Marc Mutz wrote: > On 2017-12-01 19:26, Thiago Macieira wrote: > > On Friday, 1 December 2017 01:31:18 PST Marc Mutz wrote: > >> > Once those operator<=> are there, what benefit is there in having the > >> > API > >> > public and documented? > >> > >> The spaceship operator solves the problem for qCompareStrings(). One > >> could say we already have all relational operators for all > >> combinations > >> of string-like objects to solve it for the user _now_, but > >> qCompareStrings(), like operator<=>() return the full information, > >> while > >> relational operators only return a subset. You know that, I know. I'm > >> just mentioning it for completeness sake. > > > > Ok, so your case is when you have two string-like objects and you want > > to get > > the ordering result. Since we don't yet have the spaceship operator, > > you have > > to call the compare() function. But you can't do that in clean, generic > > code > > because you don't know if the first argument is an actual QString or > > QStringView, or if it's just a char16_t literal. > > > > Is that it? > > > > Why can't they write > > > > QStringView(s1).compare(s2) ? > > I think you owe me a bit more thought on an answer to a mail of mine that that :P > A quick look at the qCompareString() overload set will answer this question (hint: the lhs is not always QStringView). > > >> Ah, but you said that the flaw was in the _standard_. But what you > >> show > >> are sub-optimal compiler implementations. There's nothing in the > >> standard that prevents a compiler to implement char_traits::length() > >> as > >> a compiler intrinsic that can have different backends for constexpr > >> and > >> runtime evaluation. > > > > The flaw is in the standard because it does not allow me to implement > > an > > optimised version using whichever tools I want to. > > The standard is not obliged to publicly give you all the plumbing to re-implement the standard library. The lack of plumbing is _sometimes_ a flaw in the standard, yes (std::invoke), but not always. You are supposed to use the standard library functionality, not re-implement it. In this case, the interface is char_traits::length, it exists on all supported platforms and does what we'd like it to do, incl., from C++17 on, constexpr. > > >> So, would the following be acceptable: > >> > >> 1. QSV uses char_traits::length() to calculate the length > >> (that was my initial implementation, but it's constexpr only starting > >> with C++17). Then QSV(Char*) is only constexpr in C++17. I can live > >> with > >> that. > > > > No, because... > > > >> 2. You/Intel work on the compiler vendors to get > >> char_traits::length() implemented as an intrinsic, with SIMD > >> at runtime and compiler magic at compile-time? > > > > We should do that anyway, but depending on it means we'll have > > performance in > > 2021 or later (just look at how we have to build Linux binaries with > > GCC 4.8). > > Since char_traits::length would be called from inline code in QSV, its performance does not depend on how Qt was compiled, but on what the user's compiler is capable of. Also, presumably, the compiler was already optimizing char_traits::length() back when it wasn't constexpr (in C++11+14) and now has to implement something to not regress on runtime performance while still meeting constexpr restrictions. If it doesn't, then it's not our problem. It's SEP. And that is good. Pick your battles. > > > The flaw exists today. My choice for fixing it is to sacrifice the part > > we > > don't really need: the constexprness. > > Fixing it in Qt is limiting both Qt and the standard library. Don't do that. > > > The same is true, btw, of QMutex. Qt takes pride in how QMutex is faster than std::mutex. I think it's a shame. It shows that you didn't go the next step and get std::mutex fixed. Having QMutex not use std::mutex means that tsan doesn't work correctly, for one. Here, too, the "easy" local "fix" is to the detriment of both the standard library (slower-than-necessary mutex operations) and Qt (failure to work with tsan). > > This habit of cocooning might have worked out ok when Qt was years ahead of the C++ standard library. But since those times in the 2000s, C++ has overtaken Qt in all aspects the committee decided to take on. Qt will have to adapt to this new reality or degrade to insignificance. Ride the wave or drown. > > As I said elsewhere: innovate, don't replicate. See the bigger picture here: Where are the patches that integrate Qt's event system and signal/slots mechanism with Coroutines, to name just one? Instead you celebrate the perceived failures of the standard and Qt's ability to "fix" them by writing a SIMD strlen or take the null state of a Qt value class to optimize QOptional size. > > This pattern repeats and repeats. V8 fork, anyone? When will Qt _finally_ learn? :) I said in my talks about QStringView that it's existential for Qt to get off its own container classes. I shall in the future extend that statement to anything that overlaps with std. > > I explicitly do not exclude QString here, even though it's exempt for the time being. But people _do_ talk about a std::text_view, and it _will_ support utf8 strings and that, in combination, _will_ degrade QString to insignificance. > > When Coroutines and ASIO land in C++, C++ will magically gain a cross-platform event loop. And more likely than not, you will have to integrate with it using Coroutines, futures and other awaitables, not the classic way of QAbstractEventDispatcher. It does not take a leap of imagination to assume that Coroutines TS will spark a ton of reactive GUI libraries for C++, incl. cross-platform ones. Qt needs to be prepared for that day. And the only way to prepare is to start working on innovative stuff and work with its various upstreams more, incl. the standard committee, and innovate. Stop. Fixing. Stuff. Locally. Get. Involved. Don't. Kodak. Qt. > > > >> Then we fix the problem where it should be fixed, and just piggy-back > >> on > >> the more general solution. And it's easy to sell to QSV users why that > >> ctor is not constexpr until C++17 (and we don't even need any > >> #ifdefery > >> in the implementation). > >> > >> What do you think? > > > > We should fix the standard and we should help fix the implementations. > > But I'm > > not accepting a performance drawback for 3 or more years until then. > > Pick your battles. I offered a compromise. I think it's a good one. And I think you're seriously overestimating the effect of your change. Not because it doesn't give a large performance boost, when exercised (I'm sure it does), but simply due to the fact that that code will be exercised very rarely. And, when actually exercised, the smaller i-cache footprint of "my" function might just beat "your" high-performance function in wall-clock time. Yes, in a library, every missed optimisation is some user's performance bottleneck. But we have an easy solution for that: people should be able to find in the ctor's documentation the recommendation to use qustrlen() manually. > > Thanks, > Marc > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Fri Dec 1 23:59:31 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 02 Dec 2017 01:59:31 +0300 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: References: <3717608.CIl6TGCH48@tjmaciei-mobl1> <15831512067729@web14o.yandex.ru> , <2460019.aNOcNdcHOr@tjmaciei-mobl1> Message-ID: <1050251512169171@web60g.yandex.ru> > Is there any plans for an out-of-schedule update about this (if plan exists at all =), as I have to deliver something end of next week, so if it’s not going to happen next week I have to start making steps to rebuild things myself. Even if 5.9.3 is be rebuilt and new binaries are published in time, it still won't work on RHEL 6, so I guess you have no choice. > > Regards, > > Yuri > > From: Thiago Macieira > > Sent: Friday, December 1, 2017 9:28 PM > > To: development at qt-project.org > > Subject: Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution > > On Friday, 1 December 2017 00:02:54 PST Jani Heikkinen wrote: > >> I understand that but still I think we shouldn't do this. Qt 5.9.4 is coming > >> on January and I hope we can wait to fix this there. > > I don't think we can wait. > > This is not a regresion that will be fixed. This is almost a P0 for our users, > > since they cannot use Qt 5.9.3 as built. > > It's not really P0 because they can rebuild from sources. > > -- > > 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 Sat Dec 2 17:48:19 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 02 Dec 2017 17:48:19 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <20171201231204.5809.6F0322A@gmail.com> References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <47e0db35cf04ca1ea86471dfb4fd7470@kdab.com> <20171201231204.5809.6F0322A@gmail.com> Message-ID: <7becacf58efb363ffa6c200e37e930a8@kdab.com> On 2017-12-01 23:12, Philippe wrote: >>> it's existential for Qt to get off its own container classes. >>> I shall in the future extend that statement to anything that overlaps >>> with std. > > Two points to keep in mind: > > 1) the std implementation varies with compiler vendors, each one with a > different set of bugs, unit tests and sometimes performance. While with > Qt, the implementation is more uniform. This to say, I feel more secure > using Qt implementations for an application that runs on multiple > platforms. And cross-platform is the core business of Qt... You make it sound as if std implementations are much more buggy than Qt's. I don't even know how to respond. I'm sure STL, Marshal Clow, Howard Hinnant, and all the others std library implementers will be pleased with your analysis. Have you tried using QVector with a type that has no default constructor? Using that nice API forces users to supply an unnatural operation on their types (if they control the types in the first place). As I said multiple times before: my arguments would be pretty weak if Qt's implementation quality matched or exceeded the quality of the corresponding feature in the standard library (and that's why we have QStringView, incomplete as it still is, because of QString), but except for QString, and QFuture, which, however, lacks the QPromise counterpart, I don't see any other cases. > 2) a majority of Qt users are not C++ wizards, and ease of use / > intuitive api, is of primary importance... std does not always shine > here. If that analyis were true, you'd need to explain why it is, then, that the Qt containers now have more or less the same API as std ones, when in Qt 1 they were very different. And why I keep needing to fight off QOptional. These are ideas that do not come from Qt. They come from C++/Boost. Qt is "stealing" them, wrapping them up in a camelCase interface, omitting the hard parts of the implementation, adding some optimisation for Qt types, and then stand here as Thiago does and say that the Qt type needs to stay because of that optimisation. Even new-style Qt 5 signal/slot connections were available in this form in Boost since at least 1.32, ie. something like 2004. In Qt 3 times, people would have protected loudly over the need to write ugly code like &QLineEdit::returnPressed instead of SIGNAL(returnPressed()), but lo and behold, there's been no public outcry. Qt silently adopted the interface that was inspired by it's own invention, but had since succeeded in keeping up with the rest of the world (Boost.Signals). That's a _good_ change. It helps people integrate their code with Qt. because integrate they must. Where I come from, we see customer's code "out there", and they almost never use Qt in isolation. They have to interface with some 2rd-party library which, naturally, does _not_ use Qt types, but std ones, and developers on those projects need to interact with both. They also surprisingly often know about and use Boost. Not only do they need to learn two different APIs (append() vs. push_back()), they also face the impedance mismatch between Qt and every other C++ library on the planet. Developers just can't cocoon inside the Qt world. They need to interact with the real world, and Qt actively prevents that with its copies of upstream APIs all over the place, and it's antiquated (read: pre-C++11) programming model. Two things have happened since 2010: C++ is progressing fast again, as a language, and, more importantly, the _tooling_ situation has dramatically improved. In a world where your static analysis tools actively warn you about common Qt idioms (mutexes, but also naked new all over the place, in violation of CoreGuidelines), Qt's insistence on providing it's own copies of std functionality force users to choose between Qt-ish APIs or static analysis coverage. A developer that chooses a nicer API if there's another cross-platform alternative which is functionally at least on par, but better integrated with his tools (IDE, compiler, clang-tidy, ...) should have a long meeting with his manager. But Qt is just maintaining it's own NIH/our-APIs-are-superior stance. As evidenced by this thread. But it's users will move on. Personally, I'm doing more Modern C++ trainings than Qt trainings these days. That has to do with me not knowing QML much, but _also_ with a surge of interest in C++. And, c'mon, std::optional's API is just not going to be topped by QOptional. What should they do? snake_case vs. camelCase? That's what we need to invest several man-days of development work in, to rename the functions and stick a Q in front of the class name? Thanks, Marc From ville.voutilainen at gmail.com Sat Dec 2 18:54:44 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sat, 2 Dec 2017 19:54:44 +0200 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <7becacf58efb363ffa6c200e37e930a8@kdab.com> References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <47e0db35cf04ca1ea86471dfb4fd7470@kdab.com> <20171201231204.5809.6F0322A@gmail.com> <7becacf58efb363ffa6c200e37e930a8@kdab.com> Message-ID: On 2 December 2017 at 18:48, Marc Mutz wrote: > If that analyis were true, you'd need to explain why it is, then, that the > Qt containers now have more or less the same API as std ones, when in Qt 1 > they were very different. And why I keep needing to fight off QOptional. .. > And, c'mon, std::optional's API is just not going to be topped by QOptional. > What should they do? snake_case vs. camelCase? That's what we need to invest > several man-days of development work in, to rename the functions and stick a > Q in front of the class name? There's one thing that a QOptional could do that std::optional can't: be available for all Qt users in a time span of a couple of months. From boud at valdyas.org Sat Dec 2 19:11:23 2017 From: boud at valdyas.org (Boudewijn Rempt) Date: Sat, 2 Dec 2017 19:11:23 +0100 (CET) Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <47e0db35cf04ca1ea86471dfb4fd7470@kdab.com> <20171201231204.5809.6F0322A@gmail.com> <7becacf58efb363ffa6c200e37e930a8@kdab.com> Message-ID: On Sat, 2 Dec 2017, Ville Voutilainen wrote: > On 2 December 2017 at 18:48, Marc Mutz wrote: > > If that analyis were true, you'd need to explain why it is, then, that the > > Qt containers now have more or less the same API as std ones, when in Qt 1 > > they were very different. And why I keep needing to fight off QOptional. > .. > > And, c'mon, std::optional's API is just not going to be topped by QOptional. > > What should they do? snake_case vs. camelCase? That's what we need to invest > > several man-days of development work in, to rename the functions and stick a > > Q in front of the class name? > > > There's one thing that a QOptional could do that std::optional can't: > be available for all Qt users > in a time span of a couple of months. And another thing: be properly documented in a way that people who are not CS phd's can understand. std completely and utterly fails in that. Parts of Qt's docs are bad enough, but there's nothing in cppreference.com that would pass muster for my gsoc students. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org From philwave at gmail.com Sat Dec 2 22:42:12 2017 From: philwave at gmail.com (Philippe) Date: Sat, 02 Dec 2017 22:42:12 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <7becacf58efb363ffa6c200e37e930a8@kdab.com> References: <20171201231204.5809.6F0322A@gmail.com> <7becacf58efb363ffa6c200e37e930a8@kdab.com> Message-ID: <20171202224211.6A1C.6F0322A@gmail.com> >>And, c'mon, std::optional's API is just not going to be topped by QOptional. I don't know the QOptional plans (or no-plan), but as today, on the Mac, the latest XCode 9.1 still does not provide std::optional. With Qt, at least, when something is available, it is available in all platforms, and Qt users can count on that. >>Where I come from, we see customer's code "out there", and they almost never use Qt in isolation. >> They have to interface with some 2rd-party library which, naturally, does _not_ use Qt types, but std ones, >> and developers on those projects need to interact with both. >> They also surprisingly often know about and use Boost. >> Not only do they need to learn two different APIs (append() vs. push_back()), >> they also face the impedance mismatch between Qt and every other C++ library on the planet. I also see that, except that boost dependency is often rejected. But I also hear praises about Qt documentation and ease of learning. I like your expression "impedance mismatch", but don't see this as a problem in practise. I mean, when a std:: container needs to be used for an interface with another library, then let's use is. No big deal. Philippe On Sat, 02 Dec 2017 17:48:19 +0100 Marc Mutz wrote: > On 2017-12-01 23:12, Philippe wrote: > >>> it's existential for Qt to get off its own container classes. > >>> I shall in the future extend that statement to anything that overlaps > >>> with std. > > > > Two points to keep in mind: > > > > 1) the std implementation varies with compiler vendors, each one with a > > different set of bugs, unit tests and sometimes performance. While with > > Qt, the implementation is more uniform. This to say, I feel more secure > > using Qt implementations for an application that runs on multiple > > platforms. And cross-platform is the core business of Qt... > > You make it sound as if std implementations are much more buggy than Qt's. I don't even know how to respond. I'm sure STL, Marshal Clow, Howard Hinnant, and all the others std library implementers will be pleased with your analysis. > > Have you tried using QVector with a type that has no default constructor? Using that nice API forces users to supply an unnatural operation on their types (if they control the types in the first place). > > As I said multiple times before: my arguments would be pretty weak if Qt's implementation quality matched or exceeded the quality of the corresponding feature in the standard library (and that's why we have QStringView, incomplete as it still is, because of QString), but except for QString, and QFuture, which, however, lacks the QPromise counterpart, I don't see any other cases. > > > 2) a majority of Qt users are not C++ wizards, and ease of use / > > intuitive api, is of primary importance... std does not always shine > > here. > > If that analyis were true, you'd need to explain why it is, then, that the Qt containers now have more or less the same API as std ones, when in Qt 1 they were very different. And why I keep needing to fight off QOptional. These are ideas that do not come from Qt. They come from C++/Boost. Qt is "stealing" them, wrapping them up in a camelCase interface, omitting the hard parts of the implementation, adding some optimisation for Qt types, and then stand here as Thiago does and say that the Qt type needs to stay because of that optimisation. Even new-style Qt 5 signal/slot connections were available in this form in Boost since at least 1.32, ie. something like 2004. In Qt 3 times, people would have protected loudly over the need to write ugly code like &QLineEdit::returnPressed instead of SIGNAL(returnPressed()), but lo and behold, there's been no public outcry. Qt silently adopted the interface that was inspired by it's own invention, but had since succeeded in keeping up with the rest of the world (Boost.Signals). That's a _good_ change. It helps people integrate their code with Qt. because integrate they must. > > Where I come from, we see customer's code "out there", and they almost never use Qt in isolation. They have to interface with some 2rd-party library which, naturally, does _not_ use Qt types, but std ones, and developers on those projects need to interact with both. They also surprisingly often know about and use Boost. Not only do they need to learn two different APIs (append() vs. push_back()), they also face the impedance mismatch between Qt and every other C++ library on the planet. > > Developers just can't cocoon inside the Qt world. They need to interact with the real world, and Qt actively prevents that with its copies of upstream APIs all over the place, and it's antiquated (read: pre-C++11) programming model. > > Two things have happened since 2010: C++ is progressing fast again, as a language, and, more importantly, the _tooling_ situation has dramatically improved. In a world where your static analysis tools actively warn you about common Qt idioms (mutexes, but also naked new all over the place, in violation of CoreGuidelines), Qt's insistence on providing it's own copies of std functionality force users to choose between Qt-ish APIs or static analysis coverage. A developer that chooses a nicer API if there's another cross-platform alternative which is functionally at least on par, but better integrated with his tools (IDE, compiler, clang-tidy, ...) should have a long meeting with his manager. > > But Qt is just maintaining it's own NIH/our-APIs-are-superior stance. As evidenced by this thread. But it's users will move on. Personally, I'm doing more Modern C++ trainings than Qt trainings these days. That has to do with me not knowing QML much, but _also_ with a surge of interest in C++. > > And, c'mon, std::optional's API is just not going to be topped by QOptional. What should they do? snake_case vs. camelCase? That's what we need to invest several man-days of development work in, to rename the functions and stick a Q in front of the class name? > > Thanks, > Marc From philwave at gmail.com Sun Dec 3 07:25:32 2017 From: philwave at gmail.com (Philippe) Date: Sun, 03 Dec 2017 07:25:32 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <7becacf58efb363ffa6c200e37e930a8@kdab.com> References: <20171201231204.5809.6F0322A@gmail.com> <7becacf58efb363ffa6c200e37e930a8@kdab.com> Message-ID: <20171203072530.D9DB.6F0322A@gmail.com> On Sat, 02 Dec 2017 17:48:19 +0100 Marc Mutz wrote: > > 1) the std implementation varies with compiler vendors, each one with a > > different set of bugs, unit tests and sometimes performance. While with > > Qt, the implementation is more uniform. This to say, I feel more secure > > using Qt implementations for an application that runs on multiple > > platforms. And cross-platform is the core business of Qt... > > You make it sound as if std implementations are much more buggy than Qt's. I don't even know how to respond. I'm sure STL, Marshal Clow, Howard Hinnant, and all the others std library implementers will be pleased with your analysis. This is not what I said. I want to say that all libraries have bugs, without telling that Qt is better or worse. But for a cross-platform developer, it is better to deal with one implementation than many. When a bug only happens on one platform, and you ship a cross-platform application, this it not cool! Philippe From marc.mutz at kdab.com Sun Dec 3 12:42:59 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 03 Dec 2017 12:42:59 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <47e0db35cf04ca1ea86471dfb4fd7470@kdab.com> <20171201231204.5809.6F0322A@gmail.com> <7becacf58efb363ffa6c200e37e930a8@kdab.com> Message-ID: On 2017-12-02 18:54, Ville Voutilainen wrote: > On 2 December 2017 at 18:48, Marc Mutz wrote: >> If that analyis were true, you'd need to explain why it is, then, that >> the >> Qt containers now have more or less the same API as std ones, when in >> Qt 1 >> they were very different. And why I keep needing to fight off >> QOptional. > .. >> And, c'mon, std::optional's API is just not going to be topped by >> QOptional. >> What should they do? snake_case vs. camelCase? That's what we need to >> invest >> several man-days of development work in, to rename the functions and >> stick a >> Q in front of the class name? > > > There's one thing that a QOptional could do that std::optional can't: > be available for all Qt users > in a time span of a couple of months. And I'm not against it. I, personally, did that for qAsConst/std::as_const. And we had qtypetraits.h, too. But if we copy std functionality, it must be and stay 100% behaviour-compatible with the corresponding std type. As a consequence, it was trivial to move away from qtypetraits.h, and it will be trivial to move from qAsConst to std::as_const. The problem comes in when you add functionality to the Qt copy that is not in the std equivalent. As such, I'm asking, like for bug-fixes, to merge the feature upstream first, then implement it in Qt when it becomes apparent that upstream will adopt the change. And as with qtypetraits.h, we should _copy_ a 3rd-party component instead of implementing it ourselves. Another excellent example of correctly working with upstream is QRegularExpression. The author first added UTF-16 support to libpcre, and _then_ added QRegularExpression on top, instead of, like it was done for QRegExp, implement the automaton himself. The QRegularExpression API is also closer to std::regex than QRegExp. The latter, despite originating in Qt, does not really have a more convenient API than std::regex. But if a QOptional is added with a nullable-Qt-types optimisation already built-in, or QStringView(Char*) is missing constexpr when std::string_view(char*) does not, then this is a functional fork that I consider unacceptable. So, to summarize my position: 1. It's ok for Qt to add copies of std functionality. It may even have a Qt-ish API (QClass::camelCase()). 2. But it must never, ever, add functionality that the std equivalent does not have. 3. Unless Qt is leap-frogging in front of the std with this (like Unicode support in QString), functionally. Performance does not count, as that should be fixed upstream. 4. Even so, Qt-as-a-project should actively participate in upstreams (incl., but not limited to, the C++ standard) to get added functionality upstreamed. An example of (4) would be for TQC to participate in the text_view discussion. Another is Olivier's co-operation with Herb and Andrew on exploring porting Qt's metaobject system to C++ metaclasses. Thanks, Marc From alex at vikingsoftware.com Sun Dec 3 17:41:07 2017 From: alex at vikingsoftware.com (Alejandro Exojo) Date: Sun, 03 Dec 2017 17:41:07 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> Message-ID: <9723848.19L0TIIrY5@walt> On Saturday 02 December 2017 19:11:23 Boudewijn Rempt wrote: > > > And, c'mon, std::optional's API is just not going to be topped by > > > QOptional. What should they do? snake_case vs. camelCase? That's what > > > we need to invest several man-days of development work in, to rename > > > the functions and stick a Q in front of the class name? > > > > There's one thing that a QOptional could do that std::optional can't: > > be available for all Qt users > > in a time span of a couple of months. True. And that, in my very humble opinion, highlights a common problem that people face in projects in all languages: wanting to use a standard functionality that is not yet available in the platforms that you have to support. Many other languages are able to "polyfill"/shim not-yet-standardized classes or functions (even members) in a clean way, by adding a 3rd party library and done. I would be fine having the same developer experience in C++ even if I had to change name spaces and includes, but doesn't seem usual practice in C++. > And another thing: be properly documented in a way that people who > are not CS phd's can understand. std completely and utterly fails > in that. Parts of Qt's docs are bad enough, but there's nothing in > cppreference.com that would pass muster for my gsoc students. I wholeheartedly agree. I understand the argument of the lambda in find_if in a somewhat intuitive way, but the explanations that one finds there about it are hugely discouraging to me (full of standardese), even if it's been some years using C++. It's not rare to see pages documenting a class or function, that, instead of giving examples of its usage, show instead three possible implementations. When you are trying to understand how it's used, or why it's useful. :-( And a 3rd point, that not necessarily applies to QOptional if everything is templated and inline, but I think still the main blocker for using more standard API is the lack of ABI stability. Yes, that's misfeature for some, but it's the current rule, so ignoring it is not helping the conversation, IMHO. -- Viking Software, Qt and C++ developers for hire http://www.vikingsoftware.com From jeanmichael.celerier at gmail.com Sun Dec 3 20:02:19 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Sun, 3 Dec 2017 20:02:19 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <9723848.19L0TIIrY5@walt> References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <9723848.19L0TIIrY5@walt> Message-ID: > . I would be fine having the same developer experience in C++ even if I had to change name spaces and includes, but doesn't seem usual practice in C++. uh... ? I have been polyfilling optional, string_view, any, and variant for almost three years with boost, or std/experimental/. The API is 99% compatible to what's in std. ------- Jean-Michaël Celerier http://www.jcelerier.name On Sun, Dec 3, 2017 at 5:41 PM, Alejandro Exojo via Development < development at qt-project.org> wrote: > On Saturday 02 December 2017 19:11:23 Boudewijn Rempt wrote: > > > > And, c'mon, std::optional's API is just not going to be topped by > > > > QOptional. What should they do? snake_case vs. camelCase? That's what > > > > we need to invest several man-days of development work in, to rename > > > > the functions and stick a Q in front of the class name? > > > > > > There's one thing that a QOptional could do that std::optional can't: > > > be available for all Qt users > > > in a time span of a couple of months. > > True. And that, in my very humble opinion, highlights a common problem that > people face in projects in all languages: wanting to use a standard > functionality that is not yet available in the platforms that you have to > support. Many other languages are able to "polyfill"/shim > not-yet-standardized > classes or functions (even members) in a clean way, by adding a 3rd party > library and done. I would be fine having the same developer experience in > C++ > even if I had to change name spaces and includes, but doesn't seem usual > practice in C++. > > > And another thing: be properly documented in a way that people who > > are not CS phd's can understand. std completely and utterly fails > > in that. Parts of Qt's docs are bad enough, but there's nothing in > > cppreference.com that would pass muster for my gsoc students. > > I wholeheartedly agree. I understand the argument of the lambda in find_if > in a > somewhat intuitive way, but the explanations that one finds there about it > are > hugely discouraging to me (full of standardese), even if it's been some > years > using C++. It's not rare to see pages documenting a class or function, > that, > instead of giving examples of its usage, show instead three possible > implementations. When you are trying to understand how it's used, or why > it's > useful. :-( > > And a 3rd point, that not necessarily applies to QOptional if everything is > templated and inline, but I think still the main blocker for using more > standard API is the lack of ABI stability. Yes, that's misfeature for some, > but it's the current rule, so ignoring it is not helping the conversation, > IMHO. > > -- > Viking Software, Qt and C++ developers for hire > http://www.vikingsoftware.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: From annulen at yandex.ru Sun Dec 3 20:17:57 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 03 Dec 2017 22:17:57 +0300 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <9723848.19L0TIIrY5@walt> Message-ID: <809551512328677@web40o.yandex.ru> >> . I would be fine having the same developer experience in C++ > > even if I had to change name spaces and includes, but doesn't seem usual > > practice in C++. > > uh... ? I have been polyfilling optional, string_view, any, and variant for almost three years with boost, or std/experimental/. The API is 99% compatible to what's in std. FWIW, WebKit project is also doing this for years (by importing experimental implementations into the source tree) > > ------- > Jean-Michaël Celerierhttp://www.jcelerier.name > > On Sun, Dec 3, 2017 at 5:41 PM, Alejandro Exojo via Development wrote: > >> On Saturday 02 December 2017 19:11:23 Boudewijn Rempt wrote: >> >>> > > And, c'mon, std::optional's API is just not going to be topped by >> >>> > > QOptional. What should they do? snake_case vs. camelCase? That's what >> >>> > > we need to invest several man-days of development work in, to rename >> >>> > > the functions and stick a Q in front of the class name? >> >>> > >> >>> > There's one thing that a QOptional could do that std::optional can't: >> >>> > be available for all Qt users >> >>> > in a time span of a couple of months. >> >> True. And that, in my very humble opinion, highlights a common problem that >> >> people face in projects in all languages: wanting to use a standard >> >> functionality that is not yet available in the platforms that you have to >> >> support. Many other languages are able to "polyfill"/shim not-yet-standardized >> >> classes or functions (even members) in a clean way, by adding a 3rd party >> >> library and done. I would be fine having the same developer experience in C++ >> >> even if I had to change name spaces and includes, but doesn't seem usual >> >> practice in C++. >> >>> And another thing: be properly documented in a way that people who >> >>> are not CS phd's can understand. std completely and utterly fails >> >>> in that. Parts of Qt's docs are bad enough, but there's nothing in >> >>> cppreference.com that would pass muster for my gsoc students. >> >> I wholeheartedly agree. I understand the argument of the lambda in find_if in a >> >> somewhat intuitive way, but the explanations that one finds there about it are >> >> hugely discouraging to me (full of standardese), even if it's been some years >> >> using C++. It's not rare to see pages documenting a class or function, that, >> >> instead of giving examples of its usage, show instead three possible >> >> implementations. When you are trying to understand how it's used, or why it's >> >> useful. :-( >> >> And a 3rd point, that not necessarily applies to QOptional if everything is >> >> templated and inline, but I think still the main blocker for using more >> >> standard API is the lack of ABI stability. Yes, that's misfeature for some, >> >> but it's the current rule, so ignoring it is not helping the conversation, >> >> IMHO. >> >> -- >> >> Viking Software, Qt and C++ developers for hire >> >> http://www.vikingsoftware.com >> >> _______________________________________________ >> >> Development mailing list >> >> Development at qt-project.org >> >> http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From kde at carewolf.com Sun Dec 3 22:57:53 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sun, 03 Dec 2017 22:57:53 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <7becacf58efb363ffa6c200e37e930a8@kdab.com> References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <20171201231204.5809.6F0322A@gmail.com> <7becacf58efb363ffa6c200e37e930a8@kdab.com> Message-ID: <1723420.SamiMsTZo9@twilight> On Samstag, 2. Dezember 2017 17:48:19 CET Marc Mutz wrote: > If that analyis were true, you'd need to explain why it is, then, that > the Qt containers now have more or less the same API as std ones, when > in Qt 1 they were very different. And why I keep needing to fight off > QOptional. These are ideas that do not come from Qt. They come from > C++/Boost. What are you smoking? These come from ML/Haskell who have had types like that for decades. 'Allan From kde at carewolf.com Sat Dec 2 09:25:27 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sat, 02 Dec 2017 09:25:27 +0100 Subject: [Development] New BiC gotcha: adding noexcept In-Reply-To: References: <48f689b5e4bef513e5f96d41682262b7@kdab.com> Message-ID: <4452510.zeGjS27lAV@twilight> On Freitag, 1. Dezember 2017 15:41:18 CET Marc Mutz wrote: > On 2017-12-01 15:21, Marc Mutz wrote: > > Hi, > > > > I just realised: Since C++17, noexcept is part of the mangled name. > > That means that adding noexcept to an exported function is BiC now! > > This is not correct, after all. The name mangling of functions does not > change, since you can't overload on noexcept(true)/noexcept(false). It's > the name of function pointer _types_ that change. That's not to say that > there are no BiC issues lurking there (or, more probable, more SiC > issues than what was fixed so far), but the above was false alarm. Pfew. > I had the same panic twice already. I even wrote a test to demonstate the issue, which then failed to do so ;) C++17 did cause several source incompatibilities though. Both for this issue and removal of explicit throw declarations (the latter fortunately not used by Qt). 'Allan From eskil.abrahamsen-blomfeldt at qt.io Mon Dec 4 10:14:04 2017 From: eskil.abrahamsen-blomfeldt at qt.io (Eskil Abrahamsen Blomfeldt) Date: Mon, 4 Dec 2017 10:14:04 +0100 Subject: [Development] Branch request: wip/webassembly in Qt Declarative Message-ID: <564726d3-2ee5-27e0-f800-95d26ed59394@qt.io> Hi, We currently have a WIP branch in Qt Base for the WebAssembly work, but it turns out that we will also need changes in Qt Declarative that significant enough that it would be good to keep them in a WIP branch until we merge the feature back. No CI needed. -- Eskil Abrahamsen Blomfeldt Senior Manager, R&D The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfeldt at qt.io http://qt.io The Future is Written with Qt www.qtworldsummit.com From jani.heikkinen at qt.io Mon Dec 4 11:31:24 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 4 Dec 2017 10:31:24 +0000 Subject: [Development] Qt 5.10.0 RC3 out In-Reply-To: References: Message-ID: Hi, We have released Qt 5.10.0 RC3 today. Delta to RC2 as an attachment. With my current knowledge this should be now final Qt 5.10.0 content which we are planning to release this Thursday (if all still ok according to tests). Instructions how to get the release are here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer. br, Jani -------------- next part -------------- A non-text attachment was scrubbed... Name: qt5.10-rc2-delta-rc3-commits Type: application/octet-stream Size: 784 bytes Desc: qt5.10-rc2-delta-rc3-commits URL: From marc.mutz at kdab.com Mon Dec 4 15:00:53 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 04 Dec 2017 15:00:53 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <1723420.SamiMsTZo9@twilight> References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <20171201231204.5809.6F0322A@gmail.com> <7becacf58efb363ffa6c200e37e930a8@kdab.com> <1723420.SamiMsTZo9@twilight> Message-ID: On 2017-12-03 22:57, Allan Sandfeld Jensen wrote: > On Samstag, 2. Dezember 2017 17:48:19 CET Marc Mutz wrote: >> If that analyis were true, you'd need to explain why it is, then, that >> the Qt containers now have more or less the same API as std ones, when >> in Qt 1 they were very different. And why I keep needing to fight off >> QOptional. These are ideas that do not come from Qt. They come from >> C++/Boost. > > What are you smoking? Nothing, atm. I did a cigarette once, though, after some scotch. Didn't end all that well... > These come from ML/Haskell who have had types like that > for decades. Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the Haskell name is maybe. So why is it QOptional and not QMaybe? Because the C++ interface is used as the basis, not something from Haskell. Alex Stepanov also agrees that vector may not have been his wisest naming choice for a dynamic array container, but it's still QVector, and not QArray, after all (IIRC, it actually _was_ QGArray in Qt 1). So, seems Qt's using C++ as a reference. As it should (whenever Java was used, things went bad: QList, QListIterator, ...). For better or worse, Qt is a C++ framework, so it's important to not try to invent new names for all things C++. Thanks, Marc From albert.astals.cid at kdab.com Mon Dec 4 15:16:16 2017 From: albert.astals.cid at kdab.com (Albert Astals Cid) Date: Mon, 04 Dec 2017 15:16:16 +0100 Subject: [Development] QT printing via CUPS (advanced printing dalog box missing) In-Reply-To: <2061336.GRC7mtx1fp@tjmaciei-mobl1> References: <2061336.GRC7mtx1fp@tjmaciei-mobl1> Message-ID: <8594205.i7L8JcGNRz@yoga> El dilluns, 20 de novembre de 2017, a les 23:45:18 CET, Thiago Macieira va escriure: > On segunda-feira, 20 de novembro de 2017 14:01:25 PST GMAIL wrote: > > This bug has been reported on QT ( see > > https://bugreports.qt.io/browse/QTBUG-54464) on *June 2016*. Almost a > > year and half now, the bug status is still *reported* and the resolution > > *unknown*. > > > > I am sorry to post this information here, but we are many users affected > > by this bug and we are desperate because we don't have any feed back > > from QT. Is there anybody working on it ? > > No, there is not. > > The module is currently orphan, with no maintainer. Reviews more than welcome https://codereview.qt-project.org/#/c/213391/ https://codereview.qt-project.org/#/c/213390/ https://codereview.qt-project.org/#/c/213389/ https://codereview.qt-project.org/#/c/213388/ https://codereview.qt-project.org/#/c/213387/ https://codereview.qt-project.org/#/c/213386/ https://codereview.qt-project.org/#/c/213385/ https://codereview.qt-project.org/#/c/213384/ https://codereview.qt-project.org/#/c/213383/ Cheers, Albert -- Albert Astals Cid | albert.astals.cid at 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 - The Qt, C++ and OpenGL Experts From kde at carewolf.com Mon Dec 4 15:20:02 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 04 Dec 2017 15:20:02 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <1723420.SamiMsTZo9@twilight> Message-ID: <2842372.rB7z5efWQ8@twilight> On Montag, 4. Dezember 2017 15:00:53 CET Marc Mutz wrote: > > Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the > Haskell name is maybe. So why is it QOptional and not QMaybe? Because > the C++ interface is used as the basis, not something from Haskell. > I believe the name "optional" comes from Haskell and Java where it appeared first. The standard library only imports things that are already industry standard, and once there were several implementations of optional out there, they started to pull one in. They just didn't manage to write it without using C++17'isms. The other name that sometimes gets used instead of Optional is Nullable (from SQL and C#), but that is a little different. I don't think "maybe" ever gets used much for this kind of type. Anyway. I do believe we should try to be compatible with std. I just don't see the point in throwing our hands in the air and refusing to improve our base classes while waiting for something we might be able to use 9 years from now. Btw. One of the issues with std::expected and std::outcome is that many are pushing for them to become C++ versions of Haskell monads, which complicates things. Best regard 'Allan From ville.voutilainen at gmail.com Mon Dec 4 15:30:49 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Mon, 4 Dec 2017 16:30:49 +0200 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <2842372.rB7z5efWQ8@twilight> References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <1723420.SamiMsTZo9@twilight> <2842372.rB7z5efWQ8@twilight> Message-ID: On 4 December 2017 at 16:20, Allan Sandfeld Jensen wrote: > On Montag, 4. Dezember 2017 15:00:53 CET Marc Mutz wrote: >> >> Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the >> Haskell name is maybe. So why is it QOptional and not QMaybe? Because >> the C++ interface is used as the basis, not something from Haskell. >> > > I believe the name "optional" comes from Haskell and Java where it appeared > first. The standard library only imports things that are already industry > standard, and once there were several implementations of optional out there, > they started to pull one in. They just didn't manage to write it without using > C++17'isms. std::optional has no fundamental c++17isms in it, and can be written without any problem in C++11 code. I maintain optional in libstdc++, in case you wonder on what basis I'm making that statement. The standard library imports a whole host of things that aren't always industry standards, but it imports things only when there's a proposal to import something. From annulen at yandex.ru Mon Dec 4 15:35:13 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 04 Dec 2017 17:35:13 +0300 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <1723420.SamiMsTZo9@twilight> <2842372.rB7z5efWQ8@twilight> Message-ID: <553571512398113@web23o.yandex.ru> 04.12.2017, 17:31, "Ville Voutilainen" : > On 4 December 2017 at 16:20, Allan Sandfeld Jensen wrote: >>  On Montag, 4. Dezember 2017 15:00:53 CET Marc Mutz wrote: >>>  Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the >>>  Haskell name is maybe. So why is it QOptional and not QMaybe? Because >>>  the C++ interface is used as the basis, not something from Haskell. >> >>  I believe the name "optional" comes from Haskell and Java where it appeared >>  first. The standard library only imports things that are already industry >>  standard, and once there were several implementations of optional out there, >>  they started to pull one in. They just didn't manage to write it without using >>  C++17'isms. > > std::optional has no fundamental c++17isms in it, and can be written > without any problem in C++11 code. > I maintain optional in libstdc++, in case you wonder on what basis I'm > making that statement. > The standard library imports a whole host of things that aren't always > industry standards, but > it imports things only when there's a proposal to import something. See also https://github.com/akrzemi1/Optional/blob/master/optional.hpp > _______________________________________________ > 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 Dec 4 16:52:37 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 4 Dec 2017 07:52:37 -0800 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <1723420.SamiMsTZo9@twilight> Message-ID: <1787335.7dukgjqukQ@tjmaciei-mobl1> On Monday, 4 December 2017 06:00:53 PST Marc Mutz wrote: > Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the > Haskell name is maybe. So why is it QOptional and not QMaybe? Because > the C++ interface is used as the basis, not something from Haskell. FYI, I wrote QMaybe some 9 to 10 years ago, when D-Bus was discussing having maybe types. https://dbus.freedesktop.org/doc/dbus-specification.html#idm423, see "Reserved for a 'maybe' type compatible with the one in GVariant, and must not appear in signatures used on D-Bus until specified here" Since it didn't happen there, it didn't happen for us either. > Alex Stepanov also agrees that vector may not have been his wisest > naming choice for a dynamic array container, but it's still QVector, and > not QArray, after all And QList is not a linked list. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Mon Dec 4 19:49:44 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 4 Dec 2017 18:49:44 +0000 Subject: [Development] QT printing via CUPS (advanced printing dalog box missing) In-Reply-To: <8594205.i7L8JcGNRz@yoga> References: <2061336.GRC7mtx1fp@tjmaciei-mobl1> <8594205.i7L8JcGNRz@yoga> Message-ID: On 4 Dec 2017, at 15:16, Albert Astals Cid > wrote: El dilluns, 20 de novembre de 2017, a les 23:45:18 CET, Thiago Macieira va escriure: On segunda-feira, 20 de novembro de 2017 14:01:25 PST GMAIL wrote: This bug has been reported on QT ( see https://bugreports.qt.io/browse/QTBUG-54464) on *June 2016*. Almost a year and half now, the bug status is still *reported* and the resolution *unknown*. I am sorry to post this information here, but we are many users affected by this bug and we are desperate because we don't have any feed back from QT. Is there anybody working on it ? No, there is not. The module is currently orphan, with no maintainer. Reviews more than welcome https://codereview.qt-project.org/#/c/213391/ https://codereview.qt-project.org/#/c/213390/ https://codereview.qt-project.org/#/c/213389/ https://codereview.qt-project.org/#/c/213388/ https://codereview.qt-project.org/#/c/213387/ https://codereview.qt-project.org/#/c/213386/ https://codereview.qt-project.org/#/c/213385/ https://codereview.qt-project.org/#/c/213384/ https://codereview.qt-project.org/#/c/213383/ Thanks a lot, Albert. I'll try to have a look in the next couple of days (or find someone else to do so ;-) Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at carewolf.com Mon Dec 4 20:29:25 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 04 Dec 2017 20:29:25 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <2842372.rB7z5efWQ8@twilight> Message-ID: <1608759.ubQtABiqkD@twilight> On Montag, 4. Dezember 2017 15:30:49 CET Ville Voutilainen wrote: > On 4 December 2017 at 16:20, Allan Sandfeld Jensen wrote: > > On Montag, 4. Dezember 2017 15:00:53 CET Marc Mutz wrote: > >> Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the > >> Haskell name is maybe. So why is it QOptional and not QMaybe? Because > >> the C++ interface is used as the basis, not something from Haskell. > > > > I believe the name "optional" comes from Haskell and Java where it > > appeared > > first. The standard library only imports things that are already industry > > standard, and once there were several implementations of optional out > > there, they started to pull one in. They just didn't manage to write it > > without using C++17'isms. > > std::optional has no fundamental c++17isms in it, and can be written > without any problem in C++11 code. > I maintain optional in libstdc++, in case you wonder on what basis I'm > making that statement. I know it can be written with C++11. I have both seen it, and done it myself. I was just noting the C++17 version takes advantage of C++17 (which makes sense). I did not mean to imply you couldn't or hadn't. I am sorry if I formulated that wrongly. > The standard library imports a whole host of things that aren't always > industry standards. but it imports things only when there's a proposal > to import something. For this part I was refering call for proposals http://cplusplus.github.io/ LWG/call-for-library-proposals.html which says it strongly prefers things based on existing practice. Anyway. I was just taking offense at Marc's claims that Qt was "stealing from C++" by adopting similar compatible ideas as the standard library, but made available for our supported platforms in our time frame. It made little sense to me, as you might as well argue Qt is stealing from Windows and Mac, by making a cross-platform toolkit implementing their established practices. Best regards 'Allan From ville.voutilainen at gmail.com Mon Dec 4 21:05:30 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Mon, 4 Dec 2017 22:05:30 +0200 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: <1608759.ubQtABiqkD@twilight> References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <2842372.rB7z5efWQ8@twilight> <1608759.ubQtABiqkD@twilight> Message-ID: On 4 December 2017 at 21:29, Allan Sandfeld Jensen wrote: >> > I believe the name "optional" comes from Haskell and Java where it >> > appeared >> > first. The standard library only imports things that are already industry >> > standard, and once there were several implementations of optional out >> > there, they started to pull one in. They just didn't manage to write it >> > without using C++17'isms. >> >> std::optional has no fundamental c++17isms in it, and can be written >> without any problem in C++11 code. >> I maintain optional in libstdc++, in case you wonder on what basis I'm >> making that statement. > I know it can be written with C++11. I have both seen it, and done it myself. > I was just noting the C++17 version takes advantage of C++17 (which makes > sense). I did not mean to imply you couldn't or hadn't. I am sorry if I > formulated that wrongly. Right; stylistically, the C++17 specification uses C++17 facilities when convenient - that has nothing to do with what the committee "manages" to do or not. For optional, it uses, for example, the _v trait-value variable templates, which are C++17, but are perfectly possible to express with the longer-hand form with ::value. Beyond those, optional doesn't do anything C++17-specific (and was in fact implemented *and specified* in terms of C++14 when it was experimental::optional, and even there, the only C++14 facility it used was relaxed constexpr, but again, those things can be written with C++11 constexpr). Under the general as-if rule, implementations can and do implement optional with equivalent facilities that were there since well before C++17. >> The standard library imports a whole host of things that aren't always >> industry standards. but it imports things only when there's a proposal >> to import something. > > For this part I was refering call for proposals http://cplusplus.github.io/ > LWG/call-for-library-proposals.html which says it strongly prefers things > based on existing practice. Yes, *prefers*, but doesn't *require*. Even the ISO guideline of standardizing existing practice is a recommendation, not a hard requirement. > Anyway. I was just taking offense at Marc's claims that Qt was "stealing from > C++" by adopting similar compatible ideas as the standard library, but made > available for our supported platforms in our time frame. It made little sense > to me, as you might as well argue Qt is stealing from Windows and Mac, by > making a cross-platform toolkit implementing their established practices. I think Marc's concern is adopting e.g. an optional-like type and giving it a *completely* different interface because we prefer camelNames to std_like_names, which is migration-wise, generic-programming-wise and interoperability-wise a complete dead end. This leads to a discussion we need to have at some point, which is that if we write a Qt facility that's expected (no expected-related puns intended) to have an equivalent facility in the standard, we should give such facilities a standard-like interface with standard-like naming, instead of following our usual naming conventions. Same goes for semantics. Which brings us back to the discussion on constexpr on QStringView - it hurts migration and interoperability if string_view has constexpr operations that are not constexpr on QStringView. Having said that, there are nuances there, like *how much* it hurts and what kind of migration/interoperability. General design principles can have engineering exceptions, when the rationale for such is sufficient. From marc.mutz at kdab.com Tue Dec 5 10:22:11 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 05 Dec 2017 10:22:11 +0100 Subject: [Development] QtCS 2017 QtCore sessions In-Reply-To: References: <2591442.fx7fcFLXIJ@tjmaciei-mobl1> <2842372.rB7z5efWQ8@twilight> <1608759.ubQtABiqkD@twilight> Message-ID: <6dac4939e4ed0de646bef6373def8c0a@kdab.com> On 2017-12-04 21:05, Ville Voutilainen wrote: > Same goes for semantics. In fact, I'm _mainly_ concerned with semantics. Different method naming is trivially fixed by tooling these days, as long as the semantics are the same. As a trivial example: qAsConst, like std::as_const, has the rvalue overload `= delete`d. For Qt containers, and most STL ones, too, with the notable exceptions of QVLA and std::array, it would make sense to allow the rvalue overload, but return a new object moved from the original. Then lifetime extension would kick in and for (auto &e : qAsConst(funReturningQVector())) would be safe, albeit less efficient as the alternative. But getting rid of qAsConst would then be much harder, since std::as_const does not have an overload for rvalues, so the above code would need to be transformed into const auto uniq = funReturningQVector(); for (auto &e : uniq) which is what you're forced to write today already, thanks to the lack of the rvalue overload. As an aside: it also makes the API easier to abuse (by allowing std::array and QVLA rvalues). So, IMNSHO, it's better to not add the rvalue overload to qAsConst, but keep it `= delete`d, thereby maintaining semantic one-to-one-ness with std::as_const, in turn making tools to perform the rewrite trivial (in this case, as easy as `s/qAsConst/std::as_const/g`). Thanks, Marc From rjvbertin at gmail.com Tue Dec 5 15:34:26 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 05 Dec 2017 15:34:26 +0100 Subject: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection Message-ID: <12927695.V9egX3tFKD@bola> Hi, Is the crash below another (new?) variant of the on-exit QDBus crashes for which a few fixes were pushed a couple months ago, a new bug I should report, or is this the result of a bug in the dependent code? rekonq built on Linux from the frameworks git head, Qt 5.8 (with the QDBus patches backported), KF5 frameworks @Konstatin Tokarev : this is with QtWebKit 5.212 Alpha2 - not that I think it's related. #6 0x0000000001832c40 in ?? () #7 0x00007f5c2985efd1 in QObject::disconnect (sender=0x907590, signal=signal at entry=0x0, receiver=receiver at entry=0x7f5c040030f0, method=method at entry=0x0) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/kernel/qobject.cpp:2956 #8 0x00007f5c2bbea770 in disconnect (member=0x0, receiver=0x7f5c040030f0, this=) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/include/QtCore/../../src/corelib/kernel/qobject.h:339 #9 QDBusConnectionPrivate::closeConnection (this=this at entry=0x7f5c040030f0) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusintegrator.cpp:1147 #10 0x00007f5c2bbea994 in QDBusConnectionPrivate::~QDBusConnectionPrivate (this=0x7f5c040030f0, __in_chrg=) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusintegrator.cpp:1071 #11 0x00007f5c2bbeaca9 in QDBusConnectionPrivate::~QDBusConnectionPrivate (this=0x7f5c040030f0, __in_chrg=) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusintegrator.cpp:1091 #12 0x00007f5c2bbde0fe in QDBusConnectionManager::run (this=0x7f5c2be4e460 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusconnection.cpp:178 #13 0x00007f5c29664cf9 in QThreadPrivate::start (arg=0x7f5c2be4e460 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:368 #14 0x00007f5c2878f184 in start_thread (arg=0x7f5c0a6d6700) at pthread_create.c:312 #15 0x00007f5c28aa2ffd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7f5c32ad68c0 (LWP 18256)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f5c29665aeb in wait (time=18446744073709551615, this=0x90aba0) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:143 #2 QWaitCondition::wait (this=this at entry=0x90bee0, mutex=mutex at entry=0x90bec0, time=time at entry=18446744073709551615) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:215 #3 0x00007f5c296648ee in QThread::wait (this=this at entry=0x7f5c2be4e460 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>, time=time at entry=18446744073709551615) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/corelib/thread/qthread_unix.cpp:698 #4 0x00007f5c2bbdba96 in QDBusConnectionManager::~QDBusConnectionManager (this=0x7f5c2be4e460 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>, __in_chrg=) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusconnection.cpp:149 #5 0x00007f5c2bbdbb59 in (anonymous namespace)::Q_QGS__q_manager::Holder::~Holder (this=, __in_chrg=) at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusconnection.cpp:72 #6 0x00007f5c2bbdbb59 in operator() (this=) from /opt/local/libexec/qt5/lib/libQt5DBus.so.5 #7 QDBusConnection::systemBus () at /opt/local/var/lnxports/build/_opt_local_site-ports_aqua_qt5-kde-devel/qt5-kde-devel/work/qt-everywhere-opensource-src-5.8.0/qtbase/src/dbus/qdbusconnection.cpp:1186 #8 0x00007f5c289e11a9 in __run_exit_handlers (status=0, listp=0x7f5c28d676c8 <__exit_funcs>, run_list_atexit=run_list_atexit at entry=true) at exit.c:82 #9 0x00007f5c289e11f5 in __GI_exit (status=) at exit.c:104 #10 0x00007f5c289c6f4c in __libc_start_main (main=0x400b00 , argc=1, argv=0x7ffed8743628, init=, fini=, rtld_fini=, stack_end=0x7ffed8743618) at libc-start.c:321 #11 0x0000000000400a39 in _start () From thiago.macieira at intel.com Tue Dec 5 16:06:42 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 5 Dec 2017 07:06:42 -0800 Subject: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection In-Reply-To: <12927695.V9egX3tFKD@bola> References: <12927695.V9egX3tFKD@bola> Message-ID: <7269585.4TUITD9s5q@tjmaciei-mobl1> On Tuesday, 5 December 2017 06:34:26 PST René J.V. Bertin wrote: > Is the crash below another (new?) variant of the on-exit QDBus crashes for > which a few fixes were pushed a couple months ago, a new bug I should > report, or is this the result of a bug in the dependent code? The fixes were reverted. So if you stopped using them, you brought them back. Keep applying the patch on top of the official release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Tue Dec 5 17:23:05 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Tue, 05 Dec 2017 17:23:05 +0100 Subject: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection References: <12927695.V9egX3tFKD@bola> <7269585.4TUITD9s5q@tjmaciei-mobl1> Message-ID: <2245654.mslAfbqpQs@portia.local> Thiago Macieira wrote: > Keep applying the patch on top of the official release. Wasn't that clear? I'm still running 5.8 *with* the fixes. This does look like a related-but-different issue though, trying to disconnect a valid receiver from a sender instance which has apparently already been deleted. It appears to be an issue caused by (with?) the QtCurve widget style, though. FWIW, this is what I get for the receiver object: (lldb) p ((QObject*)receiver)->dumpObjectInfo() OBJECT QDBusConnectionPrivate::unnamed SIGNALS OUT signal: destroyed(QObject*) signal: destroyed() signal: objectNameChanged(QString) signal: dispatchStatusChanged() signal: spyHooksFinished(QDBusMessage) signal: messageNeedsSending(QDBusPendingCallPrivate*,void*,int) signal: messageNeedsSending(QDBusPendingCallPrivate*,void*) signal: signalNeedsConnecting(QString,QDBusConnectionPrivate::SignalHook) signal: signalNeedsDisconnecting(QString,QDBusConnectionPrivate::SignalHook) signal: serviceOwnerChanged(QString,QString,QString) signal: callWithCallbackFailed(QDBusError,QDBusMessage) SIGNALS IN <-- QDBusAdaptorConnector::unnamed relaySignal(QObject*,const QMetaObject*,int,QVariantList) <-- KHintsSettingsMac::unnamed <-- QDBusConnectionPrivate::unnamed <-- QDBusConnectionPrivate::unnamed <-- QDBusConnectionPrivate::unnamed <-- QDBusConnectionPrivate::unnamed <-- QDBusConnectionPrivate::unnamed From rjvbertin at gmail.com Tue Dec 5 17:40:34 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Tue, 05 Dec 2017 17:40:34 +0100 Subject: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection References: <12927695.V9egX3tFKD@bola> <7269585.4TUITD9s5q@tjmaciei-mobl1> <2245654.mslAfbqpQs@portia.local> Message-ID: <5712031.urRGpvaa6c@portia.local> René J. V. Bertin wrote: > It appears to be an issue caused by (with?) the QtCurve widget style, though. One that goes away when I add an output tracer just before exiting from the style's dtor ... =/ R From thiago.macieira at intel.com Tue Dec 5 18:20:37 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 5 Dec 2017 09:20:37 -0800 Subject: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection In-Reply-To: <2245654.mslAfbqpQs@portia.local> References: <12927695.V9egX3tFKD@bola> <7269585.4TUITD9s5q@tjmaciei-mobl1> <2245654.mslAfbqpQs@portia.local> Message-ID: <2356148.kp5p9pSJ6S@tjmaciei-mobl1> On Tuesday, 5 December 2017 08:23:05 PST René J. V. Bertin wrote: > Thiago Macieira wrote: > > Keep applying the patch on top of the official release. > > Wasn't that clear? I'm still running 5.8 *with* the fixes. No, it wasn't. Please upgrade to 5.10 and apply the fixes again. But other than that, there are no known issues because there aren't many changes either. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Tue Dec 5 19:42:54 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Tue, 05 Dec 2017 19:42:54 +0100 Subject: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection References: <12927695.V9egX3tFKD@bola> <7269585.4TUITD9s5q@tjmaciei-mobl1> <2245654.mslAfbqpQs@portia.local> <2356148.kp5p9pSJ6S@tjmaciei-mobl1> Message-ID: <11372651.D2HtT1Slfs@patux.local> Thiago Macieira wrote: > Please upgrade to 5.10 and apply the fixes again. But other than that, there > are no known issues because there aren't many changes either. I don't think I'll be trying 5.10 any time soon, 5.9 is the newest version I hope I'll be able to run across all my systems. R. From thiago.macieira at intel.com Tue Dec 5 20:11:12 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 5 Dec 2017 11:11:12 -0800 Subject: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection In-Reply-To: <11372651.D2HtT1Slfs@patux.local> References: <12927695.V9egX3tFKD@bola> <2356148.kp5p9pSJ6S@tjmaciei-mobl1> <11372651.D2HtT1Slfs@patux.local> Message-ID: <16630721.4oyXMhZYR2@tjmaciei-mobl1> On Tuesday, 5 December 2017 10:42:54 PST René J. V. Bertin wrote: > Thiago Macieira wrote: > > Please upgrade to 5.10 and apply the fixes again. But other than that, > > there are no known issues because there aren't many changes either. > > I don't think I'll be trying 5.10 any time soon, 5.9 is the newest version I > hope I'll be able to run across all my systems. Ok, the only differences between 5.9 and 5.10 are replacing 0 with nullptr and removing one no-op. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Tue Dec 5 22:36:09 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 05 Dec 2017 22:36:09 +0100 Subject: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection In-Reply-To: <16630721.4oyXMhZYR2@tjmaciei-mobl1> References: <12927695.V9egX3tFKD@bola> <11372651.D2HtT1Slfs@patux.local> <16630721.4oyXMhZYR2@tjmaciei-mobl1> Message-ID: <40925910.TKmZCM9L2U@portia.local> On Tuesday December 05 2017 11:11:12 Thiago Macieira wrote: > Ok, the only differences between 5.9 and 5.10 are replacing 0 with nullptr and > removing one no-op. Has anything changed in the handling of style plugins between 5.8 and 5.9? A few more lines of output later I now know that the stale sender object corresponds to the style instance which is delete'd (much) earlier than the call to QDbusConnectionPrivate::closeConnection() in the global destruction. Yet we call `disconnect()` in the style dtor. I'm a bit at a loss understanding why this would bite us only in very select applications. The only sensible explanation I see is that the app in question here (rekonq) hasn't been maintained for a few years and may never have been ported correctly to Qt5. R. From thiago.macieira at intel.com Tue Dec 5 23:11:09 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 5 Dec 2017 14:11:09 -0800 Subject: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection In-Reply-To: <40925910.TKmZCM9L2U@portia.local> References: <12927695.V9egX3tFKD@bola> <16630721.4oyXMhZYR2@tjmaciei-mobl1> <40925910.TKmZCM9L2U@portia.local> Message-ID: <5119668.NjsbHCEbu4@tjmaciei-mobl1> On Tuesday, 5 December 2017 13:36:09 PST René J.V. Bertin wrote: > On Tuesday December 05 2017 11:11:12 Thiago Macieira wrote: > > Ok, the only differences between 5.9 and 5.10 are replacing 0 with nullptr > > and removing one no-op. > > Has anything changed in the handling of style plugins between 5.8 and 5.9? > > A few more lines of output later I now know that the stale sender object > corresponds to the style instance which is delete'd (much) earlier than the > call to QDbusConnectionPrivate::closeConnection() in the global > destruction. > > Yet we call `disconnect()` in the style dtor. > > I'm a bit at a loss understanding why this would bite us only in very select > applications. The only sensible explanation I see is that the app in > question here (rekonq) hasn't been maintained for a few years and may never > have been ported correctly to Qt5. disconnect() what? QDBusConnection has held locks on each registered object since Qt 4.3. The dying object cannot complete destruction until QDBusConnection has had a chance to operate. So no pointer to a QObject can become invalid before QDBusConnection disconnects the private. The specific code you're talking about did receive a patch for the exact cause you're talking about in commit ad66dbe305cff72443f4d3484191872d56e6dfbb, but that's 5.7.0. The issue was that some QObjects could be registered more than once with QDBusConnection, but QObject::disconnect() does not take a refcount, it disconnected all connections. At that point, the object was free to be deleted. The alternative I can think of is that object wasn't destroyed, but the library where the destructor code resides has been unloaded. That could explain the ?? and weird pointer address at the top of the stack. Can you see if this is the case? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Wed Dec 6 12:57:06 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 06 Dec 2017 12:57:06 +0100 Subject: [Development] systematic crash-on-exit in QDBusConnectionPrivate::closeConnection In-Reply-To: <16630721.4oyXMhZYR2@tjmaciei-mobl1> References: <12927695.V9egX3tFKD@bola> <11372651.D2HtT1Slfs@patux.local> <16630721.4oyXMhZYR2@tjmaciei-mobl1> Message-ID: <3005231.66FWtThkZ6@bola> I've decided to file this as a bug at least for future reference: https://bugreports.qt.io/browse/QTBUG-64996 I tried my luck with valgrind but apparently that modifies the runtime environment sufficiently to avoid the crash. If there was a useful hint in the valgrind output it got lost in tons of supposed errors esp. in libcrypto (probably uninitialised variable false alarms). R. From albert.astals.cid at kdab.com Wed Dec 6 15:35:44 2017 From: albert.astals.cid at kdab.com (Albert Astals Cid) Date: Wed, 06 Dec 2017 15:35:44 +0100 Subject: [Development] QT printing via CUPS (advanced printing dalog box missing) In-Reply-To: <8594205.i7L8JcGNRz@yoga> References: <2061336.GRC7mtx1fp@tjmaciei-mobl1> <8594205.i7L8JcGNRz@yoga> Message-ID: <3424390.zSYkCEMYeJ@yoga> El dilluns, 4 de desembre de 2017, a les 15:16:16 CET, Albert Astals Cid va escriure: > El dilluns, 20 de novembre de 2017, a les 23:45:18 CET, Thiago Macieira va > > escriure: > > On segunda-feira, 20 de novembro de 2017 14:01:25 PST GMAIL wrote: > > > This bug has been reported on QT ( see > > > https://bugreports.qt.io/browse/QTBUG-54464) on *June 2016*. Almost a > > > year and half now, the bug status is still *reported* and the resolution > > > *unknown*. > > > > > > I am sorry to post this information here, but we are many users affected > > > by this bug and we are desperate because we don't have any feed back > > > from QT. Is there anybody working on it ? > > > > No, there is not. > > > > The module is currently orphan, with no maintainer. > > Reviews more than welcome > > https://codereview.qt-project.org/#/c/213391/ > https://codereview.qt-project.org/#/c/213390/ > https://codereview.qt-project.org/#/c/213389/ > https://codereview.qt-project.org/#/c/213388/ > https://codereview.qt-project.org/#/c/213387/ > https://codereview.qt-project.org/#/c/213386/ > https://codereview.qt-project.org/#/c/213385/ > https://codereview.qt-project.org/#/c/213384/ > https://codereview.qt-project.org/#/c/213383/ and some more (more regarding to default values than to the advanced tabs itself) https://codereview.qt-project.org/#/c/213483/ https://codereview.qt-project.org/#/c/213575/ https://codereview.qt-project.org/#/c/213580/ https://codereview.qt-project.org/#/c/213589/ https://codereview.qt-project.org/#/c/213598/ https://codereview.qt-project.org/#/c/213661/ https://codereview.qt-project.org/#/c/213677/ Cheers, Albert > > Cheers, > Albert -- Albert Astals Cid | albert.astals.cid at 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 - The Qt, C++ and OpenGL Experts From Ch.Ehrlicher at gmx.de Thu Dec 7 09:19:14 2017 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Thu, 7 Dec 2017 09:19:14 +0100 Subject: [Development] QTimer::setInterval() and Message-ID: An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Thu Dec 7 10:37:48 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 7 Dec 2017 10:37:48 +0100 Subject: [Development] QTimer::setInterval() and In-Reply-To: References: Message-ID: <7f70adab-665e-a35d-fe94-bbc5714a7e94@kdab.com> Il 07/12/2017 09:19, Christian Ehrlicher ha scritto: > From my pov is a c++11 feature and since Qt5.9 needs c++11 the > include gueard is superfluous. But I don't know if there is a supported > platform which is still supported and chrono is not available... > If the include guard is superflouos, I can create a patch. > btw: the same goeas for qmutex.h and qobject.h Although in general Qt > 5.6 requires C++11, we don't require _complete C++11 support_ from the compiler, in order to support as many platforms as possible. We don't (and cannot) use certain language features; some language feature needs protection via #ifdefs and other macros; and we unconditionally require minimal support from the Standard Library (as of now, I think, only containers, , ). Support for from the Standard Library is one of the things that Qt includes conditionally. I'm not sure which platform we want to support doesn't have it yet (QNX? maybe osX?), and since we don't want to drop that platform, we protect the inclusion. Yes, this also means you need to upgrade your compiler to support the has_include mechanism. (Or, patch your local version of Qt...) Hope this helps, -- 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 Ch.Ehrlicher at gmx.de Thu Dec 7 10:55:18 2017 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Thu, 7 Dec 2017 10:55:18 +0100 Subject: [Development] QTimer::setInterval() and In-Reply-To: <7f70adab-665e-a35d-fe94-bbc5714a7e94@kdab.com> References: <7f70adab-665e-a35d-fe94-bbc5714a7e94@kdab.com> Message-ID: An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Thu Dec 7 10:59:21 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 7 Dec 2017 10:59:21 +0100 Subject: [Development] QTimer::setInterval() and In-Reply-To: References: <7f70adab-665e-a35d-fe94-bbc5714a7e94@kdab.com> Message-ID: Il 07/12/2017 10:55, Christian Ehrlicher ha scritto: > And shouldn't the documentation state that some functions are not > available, even the used compiler supports it, just because the check is > using some other feature which prevents the usage... Yes, it should. Please file a bug report. 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 jani.heikkinen at qt.io Thu Dec 7 12:29:39 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 7 Dec 2017 11:29:39 +0000 Subject: [Development] Qt 5.10.0 and Qt Creator 4.5.0 released Message-ID: Hi everyone! I am happy to announce that Qt 5.10.0 and Qt Creator 4.5.0 are released today. More information about releases can be found from blog posts: Qt 5.10.0: http://blog.qt.io/blog/2017/12/07/qt-5-10-released/ Qt Creator 4.5.0: http://blog.qt.io/blog/2017/12/07/qt-creator-4-5-0-released/ Big thanks to everyone involved! br, Jani Heikkinen Release Manager The Qt Company From evilruff at gmail.com Thu Dec 7 12:53:46 2017 From: evilruff at gmail.com (Yuri Alexandrov) Date: Thu, 7 Dec 2017 11:53:46 +0000 Subject: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution In-Reply-To: <1050251512169171@web60g.yandex.ru> References: <3717608.CIl6TGCH48@tjmaciei-mobl1> <15831512067729@web14o.yandex.ru> , <2460019.aNOcNdcHOr@tjmaciei-mobl1> , <1050251512169171@web60g.yandex.ru> Message-ID: Hmm.. but what to do with QtQuickCompiler then? Which sources are not available… Yuri Sent from Mail for Windows 10 ________________________________ From: Konstantin Tokarev Sent: Saturday, December 2, 2017 1:59:31 AM To: Yuri Alexandrov Cc: development at qt-project.org Subject: Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution > Is there any plans for an out-of-schedule update about this (if plan exists at all =), as I have to deliver something end of next week, so if it’s not going to happen next week I have to start making steps to rebuild things myself. Even if 5.9.3 is be rebuilt and new binaries are published in time, it still won't work on RHEL 6, so I guess you have no choice. > > Regards, > > Yuri > > From: Thiago Macieira > > Sent: Friday, December 1, 2017 9:28 PM > > To: development at qt-project.org > > Subject: Re: [Development] Urgent: Qt 5.9.3 binaries built with too NEW Linux distribution > > On Friday, 1 December 2017 00:02:54 PST Jani Heikkinen wrote: > >> I understand that but still I think we shouldn't do this. Qt 5.9.4 is coming > >> on January and I hope we can wait to fix this there. > > I don't think we can wait. > > This is not a regresion that will be fixed. This is almost a P0 for our users, > > since they cannot use Qt 5.9.3 as built. > > It's not really P0 because they can rebuild from sources. > > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederik.gladhorn at qt.io Thu Dec 7 14:53:06 2017 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 07 Dec 2017 14:53:06 +0100 Subject: [Development] QML and Qt Quick versioning of our modules Message-ID: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> Hi all, I've lately been discussing with a few people in The Qt Company about our versioning. Historically it was a good idea to not couple Qt Quick too tightly to general Qt releases. There were quite some constraints and added flexibility was nice. Qt Quick has matured a lot though, so I think it's time to consider making everyone's lives easier by cleaning up our version chaos. See also J-P's previous mail here: http://lists.qt-project.org/pipermail/ development/2015-September/023200.html Examples are the version section in here: https://doc.qt.io/qt-5/qtquickcontrols2-index.html And a general confusion around which version does what. Since we so far don't keep copies of old functions around (as far as I'm aware at least), I don't think there's a huge value in the versioning system in the first place. It only gives one important guarantee: if you added a property/type/name and import a defined version, you don't suddenly get conflicts because we introduced the same name. Some modules started to copy the Qt version, e.g. Multimedia, that's pretty easy to remember and a good start in my opinion. I have several ideas and I'm unsure how hard they would be to implement, so I'll list things from easy to hard. 1) sync minor versions to Qt release version: For Qt 5.11, we would provide QtQuick.Controls 2.11 This way, the challenge for the user is only to find out if it's version 1, 2 or 5. 2) Make the minor version import optional and we pick the lastest. This should be optional to prevent the name clashes described above and shifts the risk to the user. In practice I'd expect this to be pretty safe. import QtQuick.Controls 2 would then give the latest version available. 3) Make even the major version optional and we'd pick up the latest version. import QtQuick.Controls would give version 2.11 with Qt 5.11. I don't see us releasing most of the QML/Qt Quick modules independent of the rest of Qt any time soon, so I hope this will make things easier for everyone. I'm sure there are even better ideas out there, this is just my version and current thinking, I hope for constructive suggestions :) In the end I want this to be easier for Qt users and also to lessen our maintenance burden and the need to look up versions, explain the scheme and reduce the confusion. Luckily we now have qmlRegisterModule(QT_VERSION_MAJOR, QT_VERSION_MINOR) to help registering the current versions already. Cheers, Frederik From kari.oikarinen at qt.io Thu Dec 7 14:58:19 2017 From: kari.oikarinen at qt.io (Kari Oikarinen) Date: Thu, 7 Dec 2017 15:58:19 +0200 Subject: [Development] QML and Qt Quick versioning of our modules In-Reply-To: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> References: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> Message-ID: On 07.12.2017 15:53, Frederik Gladhorn wrote: > 1) sync minor versions to Qt release version: > For Qt 5.11, we would provide QtQuick.Controls 2.11 > This way, the challenge for the user is only to find out if it's version 1, 2 > or 5. > This sounds troublesome if Qt 6.0 comes when Qt Quick Controls would still like to stay in the same major version. 2.0? > 2) Make the minor version import optional and we pick the lastest. This should > be optional to prevent the name clashes described above and shifts the risk to > the user. > In practice I'd expect this to be pretty safe. > import QtQuick.Controls 2 would then give the latest version available. > > 3) Make even the major version optional and we'd pick up the latest version. > import QtQuick.Controls would give version 2.11 with Qt 5.11. Optional versions in the import statement sound good to me. -- Kari From frederik.gladhorn at qt.io Thu Dec 7 15:26:36 2017 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 07 Dec 2017 15:26:36 +0100 Subject: [Development] QT printing via CUPS (advanced printing dalog box missing) In-Reply-To: <3424390.zSYkCEMYeJ@yoga> References: <8594205.i7L8JcGNRz@yoga> <3424390.zSYkCEMYeJ@yoga> Message-ID: <1757203.TYEngqTViH@frederik-thinkcentre-m93p> Thanks for picking this up and working on it :) Frederik On onsdag 6. desember 2017 15.35.44 CET Albert Astals Cid wrote: > El dilluns, 4 de desembre de 2017, a les 15:16:16 CET, Albert Astals Cid va > > escriure: > > El dilluns, 20 de novembre de 2017, a les 23:45:18 CET, Thiago Macieira va > > > > escriure: > > > On segunda-feira, 20 de novembro de 2017 14:01:25 PST GMAIL wrote: > > > > This bug has been reported on QT ( see > > > > https://bugreports.qt.io/browse/QTBUG-54464) on *June 2016*. Almost a > > > > year and half now, the bug status is still *reported* and the > > > > resolution > > > > *unknown*. > > > > > > > > I am sorry to post this information here, but we are many users > > > > affected > > > > by this bug and we are desperate because we don't have any feed back > > > > from QT. Is there anybody working on it ? > > > > > > No, there is not. > > > > > > The module is currently orphan, with no maintainer. > > > > Reviews more than welcome > > > > https://codereview.qt-project.org/#/c/213391/ > > https://codereview.qt-project.org/#/c/213390/ > > https://codereview.qt-project.org/#/c/213389/ > > https://codereview.qt-project.org/#/c/213388/ > > https://codereview.qt-project.org/#/c/213387/ > > https://codereview.qt-project.org/#/c/213386/ > > https://codereview.qt-project.org/#/c/213385/ > > https://codereview.qt-project.org/#/c/213384/ > > https://codereview.qt-project.org/#/c/213383/ > > and some more (more regarding to default values than to the advanced tabs > itself) > > https://codereview.qt-project.org/#/c/213483/ > https://codereview.qt-project.org/#/c/213575/ > https://codereview.qt-project.org/#/c/213580/ > https://codereview.qt-project.org/#/c/213589/ > https://codereview.qt-project.org/#/c/213598/ > https://codereview.qt-project.org/#/c/213661/ > https://codereview.qt-project.org/#/c/213677/ > > Cheers, > Albert > > > Cheers, > > > > Albert From jhihn at gmx.com Thu Dec 7 15:39:03 2017 From: jhihn at gmx.com (Jason H) Date: Thu, 7 Dec 2017 15:39:03 +0100 Subject: [Development] QML and Qt Quick versioning of our modules In-Reply-To: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> References: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> Message-ID: > I've lately been discussing with a few people in The Qt Company about our > versioning. > Historically it was a good idea to not couple Qt Quick too tightly to general > Qt releases. There were quite some constraints and added flexibility was nice. > Qt Quick has matured a lot though, so I think it's time to consider making > everyone's lives easier by cleaning up our version chaos. > See also J-P's previous mail here: http://lists.qt-project.org/pipermail/ > development/2015-September/023200.html As a user I've been very confused about what this (stated versions) is and why I need it. If I could draw some parallels with node, they have a package.json file which specifies versions for modules with a decorator to identify valid versions. ( https://docs.npmjs.com/misc/semver ) Meanwhile the source files just spend characters importing the module. I originally thought that specified version was specifying the minimum version, however this is not true in practice. Many times the version is just specified as the current. And what happens with a project that specifies multiple versions in multiple import statements? In the vein of "if you say something that isn't right, it's wrong" the version numbers are nothing but wasted characters full of wrong information. So they should be eliminated. If versions are to be specified, they should: 0. Indicate the minimum version required, or acceptable versions, by the spec. 1. Be implicitly determined by the API in use, and not the responsibility of the developer 2. Be maintained in _one_ place Therefore, it seems appropriate to adopt the package.json for QML. And maybe it's already a thing with qpm? ( https://www.qpm.io/ ) From alexander.blasche at qt.io Thu Dec 7 16:14:13 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Thu, 7 Dec 2017 15:14:13 +0000 Subject: [Development] QML and Qt Quick versioning of our modules In-Reply-To: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> References: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> Message-ID: >1) sync minor versions to Qt release version: >For Qt 5.11, we would provide QtQuick.Controls 2.11 >This way, the challenge for the user is only to find out if it's version 1, 2 >or 5. The "match the Qt version" pattern is used by QtPositioning, QtLocation, Sensors, QtBluetooth and QtNfc too. It gets my support. Coincidentally I forgot to bump all versions for Qt 5.10 :(. Well, my first fixes for 5.10.1 -- Alex From robin.burchell at crimson.no Thu Dec 7 16:42:26 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Thu, 07 Dec 2017 16:42:26 +0100 Subject: [Development] QML and Qt Quick versioning of our modules In-Reply-To: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> References: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> Message-ID: <1512661346.1077295.1197371848.181F891C@webmail.messagingengine.com> On Thu, Dec 7, 2017, at 02:53 PM, Frederik Gladhorn wrote: > I've lately been discussing with a few people in The Qt Company about our > versioning. Thanks for taking the initiative Frederik! > And a general confusion around which version does what. > Since we so far don't keep copies of old functions around (as far as I'm > aware at least), I don't think there's a huge value in the versioning system in > the first place. > It only gives one important guarantee: if you added a property/type/name > and > import a defined version, you don't suddenly get conflicts because we > introduced > the same name. There is an additional added benefit: if you are targetting a system other than the one you are developing on now, you can set your import version appropriately, and you won't be able to use any properties/etc that were added later on than your target system. This is pretty good for working on a "product" while not messing around with your system-installed Qt, though I'll admit it's probably not a massive one. I have wanted to be able to somehow get information about what version was imported in the past, but it's not straightforward to see how to accomplish that. It would then be useful for introducing changes in behaviour that can then be explicitly opted into, though, without needing to necessarily wait for a major version. > Some modules started to copy the Qt version, e.g. Multimedia, that's > pretty easy to remember and a good start in my opinion. Agreed. The only caveat here is that it would prevent a repeat of QtQuickControls 1->2: if you copy the major version from Qt, you can't replace the whole implementation without giving it a new import, or waiting for a new Qt release. I see this as a benefit in some ways: I've heard of a lot of people who were (or are) confused by this, as the two do offer some functionality that differs. > 1) sync minor versions to Qt release version: > For Qt 5.11, we would provide QtQuick.Controls 2.11 > This way, the challenge for the user is only to find out if it's version > 1, 2 > or 5. Seems like a good idea. > 2) Make the minor version import optional and we pick the lastest. This > should > be optional to prevent the name clashes described above and shifts the > risk to > the user. > In practice I'd expect this to be pretty safe. > import QtQuick.Controls 2 would then give the latest version available. I'm inclined to prefer we don't do this, but I don't feel too strongly about it, either - at least not as long as revisioning is as weak as it is. > 3) Make even the major version optional and we'd pick up the latest > version. > import QtQuick.Controls would give version 2.11 with Qt 5.11. As well as preventing a QtQuickControls 1 -> QtQuickControls 2 transition again, this would also impact a hypothetical Qt 5 -> Qt 6 transition: QtQuick 6 (let's say) may well have behaviour changes in some form over QtQuick 2. If we don't require versioning at all, then suddenly, code that may not be able to work with that will be forced to use it. Making the minor version optional doesn't seem to have many caveats, but the major version is a bit more limiting and scary, given we don't have a linker to help ensure we're using the right dependencies... > Luckily we now have qmlRegisterModule(QT_VERSION_MAJOR, QT_VERSION_MINOR) > to help registering the current versions already. Yep, this is good :) Another potentially interesting idea that came to me while thinking about this just now: what about implicit imports (versioned), added in the qmldir file? Such that an: "import QtQuick 2.10" in the qmldir applied to everything in an import that don't specify an implicit version themselves. That would reduce clutter for anything which actually has a qmldir (which tend to be most larger more complex things), maybe that's good enough? Then, an application template could use that out of the box, too. I don't know offhand how hard this would be, but I don't think it would be too difficult. -- Robin Burchell robin at crimson.no From thiago.macieira at intel.com Thu Dec 7 17:01:17 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 7 Dec 2017 08:01:17 -0800 Subject: [Development] QTimer::setInterval() and In-Reply-To: References: Message-ID: <32309772.oxsCli5R8g@tjmaciei-mobl1> On Thursday, 7 December 2017 00:19:14 PST Christian Ehrlicher wrote: > Hi, > > According to QTimer documentation, > QTimer::setInterval(std::chrono::milliseconds) is available unconditionally > in Qt 5.9. But in qtimer.h the std::chrono - functions are guarded with > QT_HAS_INCLUDE(chrono) which expands to __has_include(chrono) or 0. The > problem is that gcc 4.8 doesn't know anything about this preprocessor > construct So you upgrade your compiler. See also how no version of Visual Studio has __has_include, so the functionality is disabled with Microsoft's compiler until they implement the macro. This is a conscious decision. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhihn at gmx.com Thu Dec 7 17:06:01 2017 From: jhihn at gmx.com (Jason H) Date: Thu, 7 Dec 2017 17:06:01 +0100 Subject: [Development] QML and Qt Quick versioning of our modules In-Reply-To: References: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> Message-ID: > >1) sync minor versions to Qt release version: > >For Qt 5.11, we would provide QtQuick.Controls 2.11 > >This way, the challenge for the user is only to find out if it's version 1, 2 > >or 5. > > The "match the Qt version" pattern is used by QtPositioning, QtLocation, Sensors, QtBluetooth and QtNfc too. It gets my support. > > Coincidentally I forgot to bump all versions for Qt 5.10 :(. Well, my first fixes for 5.10.1 I rather dislike this, unless the 5.10 version are different. This makes it seem like the code you are using _requires_ that version of module, and that module is different from it's predecessor. When reading documentation and examples, having a realistic version number is important. Is the demo code workable on my version of Qt? Are you unnecessarily bumping versions? If my Qt is out of date, and I'm trying to use more modern API then it should tell me. But if you're writing code that will work on any version back to Qt 5.8, then that should be the version specified. How do we know 5.8 is the version? Well try it, or have a tool to scan the code and tell you. Let me ask this, are the versions maintained separately from Qt? If they are, then they should bump, but if they aren't you're just wasting effort. It may be that modules can be maintained separately, but how often is that done? It seems like even Qt 3D is maintained as a proper Qt module, tied to Qt releases. If they want to have inter-release bumps 5.10.x would seem to be the way to go? From Liang.Qi at qt.io Thu Dec 7 17:22:08 2017 From: Liang.Qi at qt.io (Liang Qi) Date: Thu, 7 Dec 2017 16:22:08 +0000 Subject: [Development] Suggestion to add labels when changing API Message-ID: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> Since http://lists.qt-project.org/pipermail/development/2016-October/027542.html , Coin tests all changes against Qt5 instead of the latest version of all modules. The situation is sth like, some new APIs were added to qtbase in 5.10, and other modules were adapted. But around beta or sometime(before release), some refactoring work happened on those APIs. We adjusted them in qtbase, and other modules. We have several steps to make sure those thing to be approved in CI/COIN. But the order of things gets lost easily when merging the changes up, for example to the dev branch. Here are some suggestions to make those steps more clearer to the people who maintain merge and integration. The changes that are important to be merged up before other changes should have a special tag, such as API_CHANGE in the commit message. Then the script used to do the merges could stop and/or warn about commits with this tag in the message, which would make the merge easier. We can also apply this check into the submodule update script. The situation is also valid for some private API changes(which were used cross qt submodules). About which labels are better to be used for this purpose, please give your suggestion and votes. Thanks. Best Regards, Liang From giuseppe.dangelo at kdab.com Thu Dec 7 17:26:57 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 7 Dec 2017 16:26:57 +0000 Subject: [Development] QML and Qt Quick versioning of our modules In-Reply-To: References: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> Message-ID: <40b81af8-5f8b-b5bc-7318-85d492b81a59@kdab.com> On 07/12/17 16:06, Jason H wrote: > Let me ask this, are the versions maintained separately from Qt? If they are, then they should bump, but if they aren't you're just wasting effort. It may be that modules can be maintained separately, but how often is that done? It seems like even Qt 3D is maintained as a proper Qt module, tied to Qt releases. If they want to have inter-release bumps 5.10.x would seem to be the way to go? I would oppose this idea. There is supposed to be backward and forward compatibility in a patch release. Bumping the imports in a patch release breaks this (you can have code using Qt 5.10.1, importing Qt Quick 5.10, and which doesn't work with Qt 5.10.0). My 2 cents, -- 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, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From adam.treat at qt.io Thu Dec 7 18:17:16 2017 From: adam.treat at qt.io (Adam Treat) Date: Thu, 7 Dec 2017 12:17:16 -0500 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> Message-ID: <0ccbf0d6-6c09-c288-8305-2258d98f0cf4@qt.io> Hi, I think it is high time that we fix the underlying problem: supporting atomic commits across submodules. Once this is done we should revert our CI to test changes against latest version of all modules. As for how this could be done: * Adopt something like Google's repo tool: https://code.google.com/archive/p/git-repo/ * Stop using submodules and use a monolithic repo * Git subtree * Implement atomic commit across submodules not in Git, but in the gerrit/COIN layer so that COIN effectively locks integrations until commits that span submodules are finished * Something else? Cheers, Adam On 12/07/2017 11:22 AM, Liang Qi wrote: > Since http://lists.qt-project.org/pipermail/development/2016-October/027542.html , Coin tests all changes against Qt5 instead of the latest version of all modules. > > The situation is sth like, some new APIs were added to qtbase in 5.10, and other modules were adapted. But around beta or sometime(before release), some refactoring work happened on those APIs. We adjusted them in qtbase, and other modules. We have several steps to make sure those thing to be approved in CI/COIN. But the order of things gets lost easily when merging the changes up, for example to the dev branch. > > Here are some suggestions to make those steps more clearer to the people who maintain merge and integration. > > The changes that are important to be merged up before other changes should have a special tag, such as API_CHANGE in the commit message. Then the script used to do the merges could stop and/or warn about commits with this tag in the message, which would make the merge easier. We can also apply this check into the submodule update script. > > The situation is also valid for some private API changes(which were used cross qt submodules). > > About which labels are better to be used for this purpose, please give your suggestion and votes. Thanks. > > Best Regards, > Liang > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Ch.Ehrlicher at gmx.de Thu Dec 7 18:22:12 2017 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Thu, 7 Dec 2017 18:22:12 +0100 Subject: [Development] QTimer::setInterval() and In-Reply-To: <32309772.oxsCli5R8g@tjmaciei-mobl1> References: <32309772.oxsCli5R8g@tjmaciei-mobl1> Message-ID: <0c670e17-9a73-8e90-2313-6687633aff3d@gmx.de> Am 07.12.2017 um 17:01 schrieb Thiago Macieira: > So you upgrade your compiler. No problem from my side :) > > See also how no version of Visual Studio has __has_include, so the > functionality is disabled with Microsoft's compiler until they implement the > macro. > > This is a conscious decision. Then it's even more important to document that those functions are not available for compilers which do not support __has_include. Really hoped this was just a leftover from pre c++11 times :) Will fill a documentation bug report this evening. Christian From giuseppe.dangelo at kdab.com Thu Dec 7 19:18:56 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 7 Dec 2017 19:18:56 +0100 Subject: [Development] QTimer::setInterval() and In-Reply-To: <32309772.oxsCli5R8g@tjmaciei-mobl1> References: <32309772.oxsCli5R8g@tjmaciei-mobl1> Message-ID: <44ca3d25-0784-0b1b-3202-c967094ab69d@kdab.com> Il 07/12/2017 17:01, Thiago Macieira ha scritto: > See also how no version of Visual Studio has __has_include, so the > functionality is disabled with Microsoft's compiler until they implement the > macro. Actually VS 2017 should have __has_include: https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance -- 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 thiago.macieira at intel.com Thu Dec 7 19:31:54 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 7 Dec 2017 10:31:54 -0800 Subject: [Development] QTimer::setInterval() and In-Reply-To: <0c670e17-9a73-8e90-2313-6687633aff3d@gmx.de> References: <32309772.oxsCli5R8g@tjmaciei-mobl1> <0c670e17-9a73-8e90-2313-6687633aff3d@gmx.de> Message-ID: <1727870.LbqTgnDRBx@tjmaciei-mobl1> On Thursday, 7 December 2017 09:22:12 PST Christian Ehrlicher wrote: > Am 07.12.2017 um 17:01 schrieb Thiago Macieira: > > So you upgrade your compiler. > > No problem from my side :) > > > See also how no version of Visual Studio has __has_include, so the > > functionality is disabled with Microsoft's compiler until they implement > > the macro. > > > > This is a conscious decision. > > Then it's even more important to document that those functions are not > available for compilers which do not support __has_include. > Really hoped this was just a leftover from pre c++11 times :) This is specifically a C++11 solution. The standing document that explains how to detect if the implementation has the feature says we should use __has_include. So we do. See also QTBUG-62107. PS: looks like VS 15.3 has __has_include. I haven't confirmed that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Liang.Qi at qt.io Thu Dec 7 23:28:36 2017 From: Liang.Qi at qt.io (Liang Qi) Date: Thu, 7 Dec 2017 22:28:36 +0000 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: <0ccbf0d6-6c09-c288-8305-2258d98f0cf4@qt.io> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <0ccbf0d6-6c09-c288-8305-2258d98f0cf4@qt.io> Message-ID: I really don’t think switch back to a monolithic repo is a good idea… But if I understand atomic commits across submodules as successful integrations in qt5, I think it has some meaning to me. Here are a few tasks which I think perhaps related with this topic. https://bugreports.qt.io/browse/QTBUG-19580 https://bugreports.qt.io/browse/QTQAINFRA-824 — Liang > On 7 Dec 2017, at 18:17, Adam Treat wrote: > > Hi, > > I think it is high time that we fix the underlying problem: supporting atomic commits across submodules. > > Once this is done we should revert our CI to test changes against latest version of all modules. As for how this could be done: > > * Adopt something like Google's repo tool: https://code.google.com/archive/p/git-repo/ > * Stop using submodules and use a monolithic repo > * Git subtree > * Implement atomic commit across submodules not in Git, but in the gerrit/COIN layer so that COIN effectively locks integrations until commits that span submodules are finished > * Something else? > > Cheers, > Adam > > On 12/07/2017 11:22 AM, Liang Qi wrote: >> Since http://lists.qt-project.org/pipermail/development/2016-October/027542.html , Coin tests all changes against Qt5 instead of the latest version of all modules. >> >> The situation is sth like, some new APIs were added to qtbase in 5.10, and other modules were adapted. But around beta or sometime(before release), some refactoring work happened on those APIs. We adjusted them in qtbase, and other modules. We have several steps to make sure those thing to be approved in CI/COIN. But the order of things gets lost easily when merging the changes up, for example to the dev branch. >> >> Here are some suggestions to make those steps more clearer to the people who maintain merge and integration. >> >> The changes that are important to be merged up before other changes should have a special tag, such as API_CHANGE in the commit message. Then the script used to do the merges could stop and/or warn about commits with this tag in the message, which would make the merge easier. We can also apply this check into the submodule update script. >> >> The situation is also valid for some private API changes(which were used cross qt submodules). >> >> About which labels are better to be used for this purpose, please give your suggestion and votes. Thanks. >> >> Best Regards, >> Liang >> >> _______________________________________________ >> 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 tony.sarajarvi at qt.io Fri Dec 8 09:24:15 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Fri, 8 Dec 2017 08:24:15 +0000 Subject: [Development] Provisioning problems with macOS currently Message-ID: Hi You might have noticed provisionings failing with "" messages etc. Further investigations will show you that command line tools are needed in macOS. We have a script for that, but we've had problems getting it in. That's our P0 currently. Until we get https://codereview.qt-project.org/#/c/212787/ in, and that merged (probably with a cherry-pick to make it faster) into 5.10 and dev, you can expect to see the same message over and over again. So hitting restage in the CI won't help the situation. On a second topic. The maintenance break you might have witnessed yesterday was us doing some infra changes. It was a controlled shutdown where we moved servers to other hardware to get more bandwidth to the CI in certain parts. Sorry about this, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Fri Dec 8 09:53:49 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 8 Dec 2017 08:53:49 +0000 Subject: [Development] QML and Qt Quick versioning of our modules In-Reply-To: <1512661346.1077295.1197371848.181F891C@webmail.messagingengine.com> References: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> <1512661346.1077295.1197371848.181F891C@webmail.messagingengine.com> Message-ID: > On 7 Dec 2017, at 16:42, Robin Burchell wrote: > > On Thu, Dec 7, 2017, at 02:53 PM, Frederik Gladhorn wrote: > >> 2) Make the minor version import optional and we pick the lastest. This >> should >> be optional to prevent the name clashes described above and shifts the >> risk to >> the user. >> In practice I'd expect this to be pretty safe. >> import QtQuick.Controls 2 would then give the latest version available. > > I'm inclined to prefer we don't do this, but I don't feel too strongly > about it, either - at least not as long as revisioning is as weak as it > is. Well I suppose making it optional is one thing, but encouraging users to omit the minor version routinely is something else. Not sure we can guarantee that nothing ever breaks if they do that. >> 3) Make even the major version optional and we'd pick up the latest >> version. >> import QtQuick.Controls would give version 2.11 with Qt 5.11. > > As well as preventing a QtQuickControls 1 -> QtQuickControls 2 > transition again, this would also impact a hypothetical Qt 5 -> Qt 6 > transition: QtQuick 6 (let's say) may well have behaviour changes in > some form over QtQuick 2. If we don't require versioning at all, then > suddenly, code that may not be able to work with that will be forced to > use it. Making the minor version optional doesn't seem to have many > caveats, but the major version is a bit more limiting and scary, given > we don't have a linker to help ensure we're using the right > dependencies… Yeah, we should maybe reserve the right to release Qt Quick 3 some time before Qt 6, just in case Qt 6 takes way too long. Although, with the new config system, beginning to work on Qt Quick 6 (if we call it that) ought to already be possible… you’d just need to opt-in at configure time to try it out. Changing behavior based on import version ought to be possible, but the uri as given to a plugin’s registerTypes(const char *uri) and initializeEngine(QQmlEngine *engine, const char *uri) functions do not include the version number, so I guess we’ll have to change it. (e.g. registerTypesV2(const char *uri, int majorVersion, int minorVersion)) But we always have objections about bincompat when changing or adding virtual functions to public APIs. >> Luckily we now have qmlRegisterModule(QT_VERSION_MAJOR, QT_VERSION_MINOR) >> to help registering the current versions already. > > Yep, this is good :) > > Another potentially interesting idea that came to me while thinking > about this just now: what about implicit imports (versioned), added in > the qmldir file? Such that an: "import QtQuick 2.10" in the qmldir > applied to everything in an import that don't specify an implicit > version themselves. That would reduce clutter for anything which > actually has a qmldir (which tend to be most larger more complex > things), maybe that's good enough? Then, an application template could > use that out of the box, too. I don't know offhand how hard this would > be, but I don't think it would be too difficult. I don’t like the qmldir files much. It seems to me that most of the information in them should be discoverable, but maybe it’s just saving a little time not to need to discover everything. And the files on a web server are not as discoverable, if you are using QML that way. I think that all libraries (not just ours) should be better at providing metadata about themselves. (e.g. dll files on Windows have metadata like version number, author, copyright etc... you can see it on the Properties dialog if you right-click a dll. But Linux shared objects don’t. Why have Linux people let this situation continue for so many years?) We could at least have some standard functions which can be called to retrieve information from any QML-compatible plugin. So if you can find the plugin, you can call one or more of those to get the kinds of data that you would’ve gotten from the qmldir file. (What exactly they return, or whether it should be one function instead of several, is just a detail that needs figuring out.) Then if you import foo 2.1 the engine could expect libfoo.so.2 to exist in the appropriate directory, and look for that right away instead of looking for qmldir first. If we still care about matching the minor version, the metadata function(s) can tell us whether the version is 2.0 or 2.1 or higher. Important metadata like that should be encoded in the _file_, or in resources, not in the _file name_. I’m not that fond of the idea of replacing qmldir with JSON: yes it’s standard, and tree-structured, but it’s only slightly better than XML. It still requires too much punctuation for my taste, making it harder to write than a qmldir file, without some rule-enforcing editor. Eventually the world may get around to taking the next step: a file format that is optimized for machine reading, given that you generally need a specialized editor and/or viewer to work with XML or JSON anyway. Something where an int is an int, word-aligned so you can mmap it and trivially read it, but which stores general tree-structured key-value data like JSON does. (I wrote something like this years ago, but wasn’t worried about mmap and word-alignment at that time.) Lately there are a lot of such formats to choose from for wire protocols, but not so many that are word-aligned I suppose? But returning machine-readable metadata from a library function, or reading it from a resource block inside the library without having to call a function, is even better, IMO. A step beyond that would be to say that an importable plugin should always be a single library file, not a whole directory full of stuff. QML can be embedded as resources inside. The benefit is that installation is easier, and the plugin would be portable between systems that have the same architecture. The downside is that embedded QML is harder to access… but I think we could write a resource editor tool which allows modifying QML inside a library. It would be necessary to satisfy the open-source license requirements if the QML is to be always embedded. Proprietary vendors would want to encrypt or obfuscate any embedded resources then, but I guess some of them probably already do that. From oswald.buddenhagen at qt.io Fri Dec 8 11:44:14 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 8 Dec 2017 11:44:14 +0100 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <0ccbf0d6-6c09-c288-8305-2258d98f0cf4@qt.io> Message-ID: <20171208104414.GD6561@troll08> On Thu, Dec 07, 2017 at 10:28:36PM +0000, Liang Qi wrote: > I really don’t think switch back to a monolithic repo is a good idea… > > But if I understand atomic commits across submodules as successful integrations in qt5, I think it has some meaning to me. Here are a few tasks which I think perhaps related with this topic. > > https://bugreports.qt.io/browse/QTBUG-19580 > https://bugreports.qt.io/browse/QTQAINFRA-824 > https://bugreports.qt.io/browse/QTQAINFRA-868 is much more pertinent. > — Liang > > > On 7 Dec 2017, at 18:17, Adam Treat wrote: > > > > Hi, > > > > I think it is high time that we fix the underlying problem: supporting atomic commits across submodules. > > > > Once this is done we should revert our CI to test changes against latest version of all modules. As for how this could be done: > > > > * Adopt something like Google's repo tool: https://code.google.com/archive/p/git-repo/ > > * Stop using submodules and use a monolithic repo > > * Git subtree > > * Implement atomic commit across submodules not in Git, but in the gerrit/COIN layer so that COIN effectively locks integrations until commits that span submodules are finished > > * Something else? > > > > Cheers, > > Adam > > > > On 12/07/2017 11:22 AM, Liang Qi wrote: > >> Since http://lists.qt-project.org/pipermail/development/2016-October/027542.html , Coin tests all changes against Qt5 instead of the latest version of all modules. > >> > >> The situation is sth like, some new APIs were added to qtbase in 5.10, and other modules were adapted. But around beta or sometime(before release), some refactoring work happened on those APIs. We adjusted them in qtbase, and other modules. We have several steps to make sure those thing to be approved in CI/COIN. But the order of things gets lost easily when merging the changes up, for example to the dev branch. > >> > >> Here are some suggestions to make those steps more clearer to the people who maintain merge and integration. > >> > >> The changes that are important to be merged up before other changes should have a special tag, such as API_CHANGE in the commit message. Then the script used to do the merges could stop and/or warn about commits with this tag in the message, which would make the merge easier. We can also apply this check into the submodule update script. > >> > >> The situation is also valid for some private API changes(which were used cross qt submodules). > >> > >> About which labels are better to be used for this purpose, please give your suggestion and votes. Thanks. > >> > >> Best Regards, > >> Liang > >> > >> _______________________________________________ > >> 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 tor.arne.vestbo at qt.io Fri Dec 8 13:41:25 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Fri, 8 Dec 2017 13:41:25 +0100 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> Message-ID: On 07/12/2017 17:22, Liang Qi wrote: > The changes that are important to be merged up before other changes should have a special tag, such as API_CHANGE in the commit message. Then the script used to do the merges could stop and/or warn about commits with this tag in the message, which would make the merge easier. We can also apply this check into the submodule update script. Can't the script detect this by looking for changes to public headers? I also agree with Adam, this should be solved by proper dependency management _in_module_. We already have that through sync.profile pinning, why are we not using that? tor arne From edward.welbourne at qt.io Fri Dec 8 14:23:32 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 8 Dec 2017 13:23:32 +0000 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io>, Message-ID: On 07/12/2017 17:22, Liang Qi wrote: >> The changes that are important to be merged up before other changes >> should have a special tag, such as API_CHANGE in the commit >> message. Then the script used to do the merges could stop and/or warn >> about commits with this tag in the message, which would make the >> merge easier. We can also apply this check into the submodule update >> script. Tor Arne Vestbø (8 December 2017 13:41) > Can't the script detect this by looking for changes to public headers? That's possible (albeit possibly trickier than you think), but not all changes to public headers present a problem that this needs to attend to. Our API reviews do require actual reviewers, after all. Eddy, who has no idea what sync.profile pinning is. From sahumada at texla.cl Fri Dec 8 14:54:00 2017 From: sahumada at texla.cl (Sergio Ahumada) Date: Fri, 8 Dec 2017 14:54:00 +0100 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> Message-ID: On 08.12.2017 14:23, Edward Welbourne wrote: > On 07/12/2017 17:22, Liang Qi wrote: >>> The changes that are important to be merged up before other changes >>> should have a special tag, such as API_CHANGE in the commit >>> message. Then the script used to do the merges could stop and/or warn >>> about commits with this tag in the message, which would make the >>> merge easier. We can also apply this check into the submodule update >>> script. > > Tor Arne Vestbø (8 December 2017 13:41) >> Can't the script detect this by looking for changes to public headers? > > That's possible (albeit possibly trickier than you think), but not all > changes to public headers present a problem that this needs to attend > to. Our API reviews do require actual reviewers, after all. > > Eddy, who has no idea what sync.profile pinning is. an old concept that used to pin the sha1 of repo/module's dependency, eg http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=ab6b6b7c7ab544d347d59b7eefad403837d94012 that was replaced in, eg, http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=9bfe3324f7fa94e1f272c35bcb943daa2669edba for http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules -- Sergio Ahumada sahumada at texla.cl From tor.arne.vestbo at qt.io Fri Dec 8 15:14:19 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Fri, 8 Dec 2017 15:14:19 +0100 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> Message-ID: On 08/12/2017 14:54, Sergio Ahumada wrote: > an old concept that used to pin the sha1 of repo/module's dependency, eg > > http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=ab6b6b7c7ab544d347d59b7eefad403837d94012 > > > that was replaced in, eg, > http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=9bfe3324f7fa94e1f272c35bcb943daa2669edba > > > for > > http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules Ouch, what was the rationale for making this change? tor arne From tor.arne.vestbo at qt.io Fri Dec 8 15:14:19 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Fri, 8 Dec 2017 15:14:19 +0100 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> Message-ID: On 08/12/2017 14:54, Sergio Ahumada wrote: > an old concept that used to pin the sha1 of repo/module's dependency, eg > > http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=ab6b6b7c7ab544d347d59b7eefad403837d94012 > > > that was replaced in, eg, > http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=9bfe3324f7fa94e1f272c35bcb943daa2669edba > > > for > > http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules Ouch, what was the rationale for making this change? tor arne From annulen at yandex.ru Fri Dec 8 15:20:55 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 08 Dec 2017 17:20:55 +0300 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> Message-ID: <4152131512742855@web21o.yandex.ru> 08.12.2017, 17:14, "Tor Arne Vestbø" : > On 08/12/2017 14:54, Sergio Ahumada wrote: >>  an old concept that used to pin the sha1 of repo/module's dependency, eg >> >>  http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=ab6b6b7c7ab544d347d59b7eefad403837d94012 >> >>  that was replaced in, eg, >>  http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=9bfe3324f7fa94e1f272c35bcb943daa2669edba >> >>  for >> >>  http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules > > Ouch, what was the rationale for making this change? IIRC, it was done to have all things in one place. Integration is strongly affected by used qt5 commit, which determines provisioning configuration and platform configs, so it's logical to use its submodule references as well. > > tor arne > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From adam.treat at qt.io Fri Dec 8 15:42:54 2017 From: adam.treat at qt.io (Adam Treat) Date: Fri, 8 Dec 2017 09:42:54 -0500 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: <4152131512742855@web21o.yandex.ru> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <4152131512742855@web21o.yandex.ru> Message-ID: <796cccf5-be3e-cabf-69d3-3316ae28e197@qt.io> Relying upon qt5 submodule pins is the problem. The underlying issue is atomicity of commits. Oswald is right. We need to have a way to provide atomic commits across modules at least the CI should see these as atomic and integrate accordingly. On 12/08/2017 09:20 AM, Konstantin Tokarev wrote: > > 08.12.2017, 17:14, "Tor Arne Vestbø" : >> On 08/12/2017 14:54, Sergio Ahumada wrote: >>>  an old concept that used to pin the sha1 of repo/module's dependency, eg >>> >>>  http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=ab6b6b7c7ab544d347d59b7eefad403837d94012 >>> >>>  that was replaced in, eg, >>>  http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=9bfe3324f7fa94e1f272c35bcb943daa2669edba >>> >>>  for >>> >>>  http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules >> Ouch, what was the rationale for making this change? > IIRC, it was done to have all things in one place. Integration is strongly affected by used qt5 commit, which determines provisioning configuration and platform configs, so it's logical to use its submodule references as well. > >> tor arne >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development From sahumada at texla.cl Fri Dec 8 16:15:10 2017 From: sahumada at texla.cl (Sergio Ahumada) Date: Fri, 8 Dec 2017 16:15:10 +0100 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: <796cccf5-be3e-cabf-69d3-3316ae28e197@qt.io> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <4152131512742855@web21o.yandex.ru> <796cccf5-be3e-cabf-69d3-3316ae28e197@qt.io> Message-ID: <2d184f32-84cf-e55b-d201-082ccd8c3834@texla.cl> On 08.12.2017 15:42, Adam Treat wrote: > Relying upon qt5 submodule pins is the problem. The underlying issue is > atomicity of commits. Oswald is right. > > We need to have a way to provide atomic commits across modules at least > the CI should see these as atomic and integrate accordingly. > what about trying to enable gerrit topic's feature again for cross-repo changes? -- Sergio Ahumada sahumada at texla.cl From oswald.buddenhagen at qt.io Fri Dec 8 16:50:18 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 8 Dec 2017 16:50:18 +0100 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: <2d184f32-84cf-e55b-d201-082ccd8c3834@texla.cl> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <4152131512742855@web21o.yandex.ru> <796cccf5-be3e-cabf-69d3-3316ae28e197@qt.io> <2d184f32-84cf-e55b-d201-082ccd8c3834@texla.cl> Message-ID: <20171208155018.GE6561@troll08> On Fri, Dec 08, 2017 at 04:15:10PM +0100, Sergio Ahumada wrote: > On 08.12.2017 15:42, Adam Treat wrote: > > Relying upon qt5 submodule pins is the problem. The underlying issue is > > atomicity of commits. Oswald is right. > > > > We need to have a way to provide atomic commits across modules at least > > the CI should see these as atomic and integrate accordingly. > > > > what about trying to enable gerrit topic's feature again for cross-repo > changes? > from the ci perspective, that's both pointless (because the grouping can be achieved temporally by just staging the changes at the same time) and insufficient (because the system currently just won't do atomic integrations). if you want to use the topic name as the label that has been originally proposed, regardless of the CI system, then there is nothing to fix: the ability to set the topic has been available forever (it just does not have any magic effect on integration). the problem with such "soft-labeling" is of course that it's laborious and terribly easy to mess up. fwiw, openstack's zuul recognizes explicit dependency markers in commit message footers, which is kind of a middle ground (it's formalized, so it can be checked). i'm not a particular fan of their gerrit<=>ci integration approach to start with, though. From annulen at yandex.ru Fri Dec 8 17:10:41 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 08 Dec 2017 19:10:41 +0300 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: <20171208155018.GE6561@troll08> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <4152131512742855@web21o.yandex.ru> <796cccf5-be3e-cabf-69d3-3316ae28e197@qt.io> <2d184f32-84cf-e55b-d201-082ccd8c3834@texla.cl> <20171208155018.GE6561@troll08> Message-ID: <835351512749441@web4j.yandex.ru> 08.12.2017, 18:50, "Oswald Buddenhagen" : > On Fri, Dec 08, 2017 at 04:15:10PM +0100, Sergio Ahumada wrote: >>  On 08.12.2017 15:42, Adam Treat wrote: >>  > Relying upon qt5 submodule pins is the problem. The underlying issue is >>  > atomicity of commits. Oswald is right. >>  > >>  > We need to have a way to provide atomic commits across modules at least >>  > the CI should see these as atomic and integrate accordingly. >>  > >> >>  what about trying to enable gerrit topic's feature again for cross-repo >>  changes? > > from the ci perspective, that's both pointless (because the grouping can > be achieved temporally by just staging the changes at the same time) and > insufficient (because the system currently just won't do atomic > integrations). > > if you want to use the topic name as the label that has been originally > proposed, regardless of the CI system, then there is nothing to fix: > the ability to set the topic has been available forever (it just does > not have any magic effect on integration). > the problem with such "soft-labeling" is of course that it's laborious > and terribly easy to mess up. > > fwiw, openstack's zuul recognizes explicit dependency markers in commit > message footers, which is kind of a middle ground (it's formalized, so > it can be checked). If git hashes were used instead of Change-Id's, it would be useful to store this information in git commits (in case of future need for bisecting) i'm not a particular fan of their gerrit<=>ci > integration approach to start with, though. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From Jake.Petroules at qt.io Fri Dec 8 18:29:29 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 8 Dec 2017 17:29:29 +0000 Subject: [Development] Qbs 1.10 released In-Reply-To: References: Message-ID: <853DB3C0-E7E0-4B9C-9883-D173E1D521F3@qt.io> Hi everyone! Following our successful Qt, Qt Creator, and Qt 3D Studio releases yesterday, we have released qbs 1.10 today. Find all the relevant information in the blog post at http://blog.qt.io/blog/2017/12/07/qbs-1-10-released/ > On Dec 7, 2017, at 3:29 AM, Jani Heikkinen wrote: > > Hi everyone! > > I am happy to announce that Qt 5.10.0 and Qt Creator 4.5.0 are released today. > > More information about releases can be found from blog posts: > Qt 5.10.0: http://blog.qt.io/blog/2017/12/07/qt-5-10-released/ > Qt Creator 4.5.0: http://blog.qt.io/blog/2017/12/07/qt-creator-4-5-0-released/ > > Big thanks to everyone involved! > > br, > Jani Heikkinen > Release Manager > The Qt Company > > > > > _______________________________________________ > 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 enmarantispam at gmail.com Fri Dec 8 18:32:23 2017 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Fri, 8 Dec 2017 20:32:23 +0300 Subject: [Development] Qbs 1.10 released In-Reply-To: <853DB3C0-E7E0-4B9C-9883-D173E1D521F3@qt.io> References: <853DB3C0-E7E0-4B9C-9883-D173E1D521F3@qt.io> Message-ID: can you please clarify this passage with a link to an example? > It is now possible to add file tags to generated artifacts by setting the new fileTags property in a group that has a fileTagsFilter. This allows you to “append” to the list of file tags assigned to artifacts created by a rule that is defined in a module which is outside your control. On Fri, Dec 8, 2017 at 8:29 PM, Jake Petroules wrote: > Hi everyone! > > Following our successful Qt, Qt Creator, and Qt 3D Studio releases > yesterday, we have released qbs 1.10 today. Find all the relevant > information in the blog post at http://blog.qt.io/blog/2017/ > 12/07/qbs-1-10-released/ > > > On Dec 7, 2017, at 3:29 AM, Jani Heikkinen wrote: > > > > Hi everyone! > > > > I am happy to announce that Qt 5.10.0 and Qt Creator 4.5.0 are released > today. > > > > More information about releases can be found from blog posts: > > Qt 5.10.0: http://blog.qt.io/blog/2017/12/07/qt-5-10-released/ > > Qt Creator 4.5.0: http://blog.qt.io/blog/2017/12/07/qt-creator-4-5-0- > released/ > > > > Big thanks to everyone involved! > > > > br, > > Jani Heikkinen > > Release Manager > > The Qt Company > > > > > > > > > > _______________________________________________ > > 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 sahumada at texla.cl Fri Dec 8 18:47:09 2017 From: sahumada at texla.cl (Sergio Ahumada) Date: Fri, 8 Dec 2017 18:47:09 +0100 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: <20171208155018.GE6561@troll08> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <4152131512742855@web21o.yandex.ru> <796cccf5-be3e-cabf-69d3-3316ae28e197@qt.io> <2d184f32-84cf-e55b-d201-082ccd8c3834@texla.cl> <20171208155018.GE6561@troll08> Message-ID: <55a7ea5a-ccc6-7cae-6fe8-11a0f9e16970@texla.cl> On 08.12.2017 16:50, Oswald Buddenhagen wrote: > On Fri, Dec 08, 2017 at 04:15:10PM +0100, Sergio Ahumada wrote: >> On 08.12.2017 15:42, Adam Treat wrote: >>> Relying upon qt5 submodule pins is the problem. The underlying issue is >>> atomicity of commits. Oswald is right. >>> >>> We need to have a way to provide atomic commits across modules at least >>> the CI should see these as atomic and integrate accordingly. >>> >> >> what about trying to enable gerrit topic's feature again for cross-repo >> changes? >> > from the ci perspective, that's both pointless (because the grouping can > be achieved temporally by just staging the changes at the same time) and > insufficient (because the system currently just won't do atomic > integrations). I meant provided the system is able to do atomic integrations, as Adam suggested. But that would probably require quite a lot of more computer power. actually, Adam's initial proposal sounds quite good to me > * Adopt something like Google's repo tool: https://code.google.com/archive/p/git-repo/ > * Stop using submodules and use a monolithic repo for both these proposals see https://bugreports.qt.io/browse/QTBUG-19580 > * Implement atomic commit across submodules not in Git, but in the gerrit/COIN layer so that COIN effectively locks integrations until commits that span submodules are finished Use the topic feature to merge changes across repos once they are all passed their CIs. Merge normal changes as usual after their CIs are passed. Move the old dependencies from sync.profile+http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules to the demo-default.xml file proposed in QTBUG-19580 .. get the list of repos to be cloned (or already built tgz) + needed sha1 to git-reset and then git-cherry-pick the changes under test on top .. does that make any sense? -- Sergio Ahumada sahumada at texla.cl From adam.treat at qt.io Fri Dec 8 20:46:28 2017 From: adam.treat at qt.io (Adam Treat) Date: Fri, 8 Dec 2017 14:46:28 -0500 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: <4152131512742855@web21o.yandex.ru> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <4152131512742855@web21o.yandex.ru> Message-ID: On 12/08/2017 09:20 AM, Konstantin Tokarev wrote: > > 08.12.2017, 17:14, "Tor Arne Vestbø" : >> On 08/12/2017 14:54, Sergio Ahumada wrote: >>>  an old concept that used to pin the sha1 of repo/module's dependency, eg >>> >>>  http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=ab6b6b7c7ab544d347d59b7eefad403837d94012 >>> >>>  that was replaced in, eg, >>>  http://code.qt.io/cgit/qt/qtdeclarative.git/commit/sync.profile?id=9bfe3324f7fa94e1f272c35bcb943daa2669edba >>> >>>  for >>> >>>  http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules >> Ouch, what was the rationale for making this change? > IIRC, it was done to have all things in one place. Integration is strongly affected by used qt5 commit, which determines provisioning configuration and platform configs, so it's logical to use its submodule references as well. Again, this all boils down to the commits across submodules are not atomic. The very least that needs to be done is to make it atomic from the CI perspective if not atomic to all those doing git fetch and rebuild. From adam.treat at qt.io Fri Dec 8 20:52:53 2017 From: adam.treat at qt.io (Adam Treat) Date: Fri, 8 Dec 2017 14:52:53 -0500 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: <55a7ea5a-ccc6-7cae-6fe8-11a0f9e16970@texla.cl> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <4152131512742855@web21o.yandex.ru> <796cccf5-be3e-cabf-69d3-3316ae28e197@qt.io> <2d184f32-84cf-e55b-d201-082ccd8c3834@texla.cl> <20171208155018.GE6561@troll08> <55a7ea5a-ccc6-7cae-6fe8-11a0f9e16970@texla.cl> Message-ID: <92a0a4f8-bc9a-4a22-152e-f81ca5fe5862@qt.io> On 12/08/2017 12:47 PM, Sergio Ahumada wrote: > On 08.12.2017 16:50, Oswald Buddenhagen wrote: >> On Fri, Dec 08, 2017 at 04:15:10PM +0100, Sergio Ahumada wrote: >>> On 08.12.2017 15:42, Adam Treat wrote: >>>> Relying upon qt5 submodule pins is the problem. The underlying >>>> issue is >>>> atomicity of commits. Oswald is right. >>>> >>>> We need to have a way to provide atomic commits across modules at >>>> least >>>> the CI should see these as atomic and integrate accordingly. >>>> >>> >>> what about trying to enable gerrit topic's feature again for cross-repo >>> changes? >>> >> from the ci perspective, that's both pointless (because the grouping can >> be achieved temporally by just staging the changes at the same time) and >> insufficient (because the system currently just won't do atomic >> integrations). > > I meant provided the system is able to do atomic integrations, as Adam > suggested. But that would probably require quite a lot of more > computer power. Why? > actually, Adam's initial proposal sounds quite good to me > > > * Adopt something like Google's repo tool: > https://code.google.com/archive/p/git-repo/ > > * Stop using submodules and use a monolithic repo > > for both these proposals see https://bugreports.qt.io/browse/QTBUG-19580 > > > * Implement atomic commit across submodules not in Git, but in the > gerrit/COIN layer so that COIN effectively locks integrations until > commits that span submodules are finished > > Use the topic feature to merge changes across repos once they are all > passed their CIs. Merge normal changes as usual after their CIs are > passed. > > Move the old dependencies from > sync.profile+http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules to the > demo-default.xml file proposed in QTBUG-19580 .. get the list of repos > to be cloned (or already built tgz) + needed sha1 to git-reset and > then git-cherry-pick the changes under test on top .. > > does that make any sense? As another alternative I'm trying to figure out if Gitlab's CI system has a way to deal with this: https://forum.gitlab.com/t/trigger-ci-build-if-any-dependent-git-repo-is-updated/9725 They do have ways to kick off integration jobs based on git triggers and/or other logic: https://docs.gitlab.com/ee/ci/yaml/#jobs I think we could design atomic integrations across submodules with something like that. In general, has anyone looked into Gitlab's CI system and compared/contrasted with COIN? From annulen at yandex.ru Fri Dec 8 20:57:30 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 08 Dec 2017 22:57:30 +0300 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: <92a0a4f8-bc9a-4a22-152e-f81ca5fe5862@qt.io> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <4152131512742855@web21o.yandex.ru> <796cccf5-be3e-cabf-69d3-3316ae28e197@qt.io> <2d184f32-84cf-e55b-d201-082ccd8c3834@texla.cl> <20171208155018.GE6561@troll08> <55a7ea5a-ccc6-7cae-6fe8-11a0f9e16970@texla.cl> <92a0a4f8-bc9a-4a22-152e-f81ca5fe5862@qt.io> Message-ID: <1692971512763050@web57o.yandex.ru> 08.12.2017, 22:53, "Adam Treat" : > On 12/08/2017 12:47 PM, Sergio Ahumada wrote: >>  On 08.12.2017 16:50, Oswald Buddenhagen wrote: >>>  On Fri, Dec 08, 2017 at 04:15:10PM +0100, Sergio Ahumada wrote: >>>>  On 08.12.2017 15:42, Adam Treat wrote: >>>>>  Relying upon qt5 submodule pins is the problem. The underlying >>>>>  issue is >>>>>  atomicity of commits. Oswald is right. >>>>> >>>>>  We need to have a way to provide atomic commits across modules at >>>>>  least >>>>>  the CI should see these as atomic and integrate accordingly. >>>> >>>>  what about trying to enable gerrit topic's feature again for cross-repo >>>>  changes? >>>  from the ci perspective, that's both pointless (because the grouping can >>>  be achieved temporally by just staging the changes at the same time) and >>>  insufficient (because the system currently just won't do atomic >>>  integrations). >> >>  I meant provided the system is able to do atomic integrations, as Adam >>  suggested. But that would probably require quite a lot of more >>  computer power. > > Why? Because if you rebuild all modules when integrating each commit to qtbase, it will require much more CPU (and wall clock) time than now. Note that qtbase probably has higher commit rate than some "peripheral" modules. > >>  actually, Adam's initial proposal sounds quite good to me >> >>  > * Adopt something like Google's repo tool: >>  https://code.google.com/archive/p/git-repo/ >>  > * Stop using submodules and use a monolithic repo >> >>  for both these proposals see https://bugreports.qt.io/browse/QTBUG-19580 >> >>  > * Implement atomic commit across submodules not in Git, but in the >>  gerrit/COIN layer so that COIN effectively locks integrations until >>  commits that span submodules are finished >> >>  Use the topic feature to merge changes across repos once they are all >>  passed their CIs. Merge normal changes as usual after their CIs are >>  passed. >> >>  Move the old dependencies from >>  sync.profile+http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules to the >>  demo-default.xml file proposed in QTBUG-19580 .. get the list of repos >>  to be cloned (or already built tgz) + needed sha1 to git-reset and >>  then git-cherry-pick the changes under test on top .. >> >>  does that make any sense? > > As another alternative I'm trying to figure out if Gitlab's CI system > has a way to deal with this: > > https://forum.gitlab.com/t/trigger-ci-build-if-any-dependent-git-repo-is-updated/9725 > > They do have ways to kick off integration jobs based on git triggers > and/or other logic: https://docs.gitlab.com/ee/ci/yaml/#jobs > > I think we could design atomic integrations across submodules with > something like that. > > In general, has anyone looked into Gitlab's CI system and > compared/contrasted with COIN? > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From sahumada at texla.cl Fri Dec 8 21:07:04 2017 From: sahumada at texla.cl (Sergio Ahumada) Date: Fri, 8 Dec 2017 21:07:04 +0100 Subject: [Development] Suggestion to add labels when changing API In-Reply-To: <92a0a4f8-bc9a-4a22-152e-f81ca5fe5862@qt.io> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <4152131512742855@web21o.yandex.ru> <796cccf5-be3e-cabf-69d3-3316ae28e197@qt.io> <2d184f32-84cf-e55b-d201-082ccd8c3834@texla.cl> <20171208155018.GE6561@troll08> <55a7ea5a-ccc6-7cae-6fe8-11a0f9e16970@texla.cl> <92a0a4f8-bc9a-4a22-152e-f81ca5fe5862@qt.io> Message-ID: On 08.12.2017 20:52, Adam Treat wrote: > > As another alternative I'm trying to figure out if Gitlab's CI system > has a way to deal with this: > > https://forum.gitlab.com/t/trigger-ci-build-if-any-dependent-git-repo-is-updated/9725 > > > They do have ways to kick off integration jobs based on git triggers > and/or other logic: https://docs.gitlab.com/ee/ci/yaml/#jobs > > I think we could design atomic integrations across submodules with > something like that. > > In general, has anyone looked into Gitlab's CI system and > compared/contrasted with COIN? > I have no idea how they do it .. but you could listen to gerrit stream-events parse project/branch (and even files/paths to implement https://bugreports.qt.io/browse/QTQAINFRA-869) and match that against a yaml configuration file (or the same default-demo.xml from QTBUG-19580) and trigger the Jenkins jobs accordingly -- Sergio Ahumada sahumada at texla.cl From devguy.ca at gmail.com Sun Dec 10 14:23:54 2017 From: devguy.ca at gmail.com (Dev Guy) Date: Sun, 10 Dec 2017 08:23:54 -0500 Subject: [Development] [Announce] Qt 5.10.0 and Qt Creator 4.5.0 released In-Reply-To: References: Message-ID: Hello you need to fix your unsubscribe, I keep getting emails for various Qt mailing lists no matter how many time I've unsubscribed! Please remove me from all Qt list, thank you. On Thu, Dec 7, 2017 at 6:29 AM, List for announcements regarding Qt releases and development wrote: > Hi everyone! > > I am happy to announce that Qt 5.10.0 and Qt Creator 4.5.0 are released today. > > More information about releases can be found from blog posts: > Qt 5.10.0: http://blog.qt.io/blog/2017/12/07/qt-5-10-released/ > Qt Creator 4.5.0: http://blog.qt.io/blog/2017/12/07/qt-creator-4-5-0-released/ > > Big thanks to everyone involved! > > br, > Jani Heikkinen > Release Manager > The Qt Company > > > > > _______________________________________________ > Announce mailing list > Announce at qt-project.org > http://lists.qt-project.org/mailman/listinfo/announce -- Kind Regards, TH From tony.sarajarvi at qt.io Mon Dec 11 11:03:45 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Mon, 11 Dec 2017 10:03:45 +0000 Subject: [Development] QtBase broken in 5.9 and 5.10. Fix is already inbound. Message-ID: Hi QtBase in 5.9 and 5.10 are broken currently. We found the bug, and it was sadly approved by yours sincerely :/ Fix is inbound: https://codereview.qt-project.org/#/c/214032/ -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From Liang.Qi at qt.io Mon Dec 11 12:22:30 2017 From: Liang.Qi at qt.io (Liang Qi) Date: Mon, 11 Dec 2017 11:22:30 +0000 Subject: [Development] QtBase broken in 5.9 and 5.10. Fix is already inbound. In-Reply-To: References: Message-ID: <96CBA118-F04E-4FF3-AB37-283B6304F371@qt.io> 5.9 was fixed. The merge to 5.10 is on the way. https://codereview.qt-project.org/#/c/214051/ dev is blocked by "Module "" () Failed to provision template 'qtci-osx-10.11-x86_64-3-9946c2’:” issue, should be fixed by following change: https://codereview.qt-project.org/#/c/214045/ — Liang > On 11 Dec 2017, at 11:03, Tony Sarajärvi wrote: > > Hi > > QtBase in 5.9 and 5.10 are broken currently. We found the bug, and it was sadly approved by yours sincerely :/ > Fix is inbound: https://codereview.qt-project.org/#/c/214032/ > > -Tony From Liang.Qi at qt.io Mon Dec 11 17:02:17 2017 From: Liang.Qi at qt.io (Liang Qi) Date: Mon, 11 Dec 2017 16:02:17 +0000 Subject: [Development] QtBase broken in 5.9 and 5.10. Fix is already inbound. In-Reply-To: <96CBA118-F04E-4FF3-AB37-283B6304F371@qt.io> References: <96CBA118-F04E-4FF3-AB37-283B6304F371@qt.io> Message-ID: <8CBC6AAF-46FB-4543-87D7-7EEC7AFE5335@qt.io> 5.10 was fixed. — Liang > On 11 Dec 2017, at 12:22, Liang Qi wrote: > > 5.9 was fixed. The merge to 5.10 is on the way. > https://codereview.qt-project.org/#/c/214051/ > > dev is blocked by "Module "" () Failed to provision template 'qtci-osx-10.11-x86_64-3-9946c2’:” issue, should be fixed by following change: > https://codereview.qt-project.org/#/c/214045/ > > — Liang > >> On 11 Dec 2017, at 11:03, Tony Sarajärvi wrote: >> >> Hi >> >> QtBase in 5.9 and 5.10 are broken currently. We found the bug, and it was sadly approved by yours sincerely :/ >> Fix is inbound: https://codereview.qt-project.org/#/c/214032/ >> >> -Tony > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From adam.treat at qt.io Mon Dec 11 17:24:16 2017 From: adam.treat at qt.io (Adam Treat) Date: Mon, 11 Dec 2017 11:24:16 -0500 Subject: [Development] COIN failures on dev Message-ID: Hi, For the past few business days we've all witnessed failures on dev branch like this: https://codereview.qt-project.org/#/c/213309/ Seems that something broke with provisioning on macOS or something. I see this https://codereview.qt-project.org/#/c/214045/ attempt to fix, but that is also failing to integrate due to seemingly unrelated reasons. I'm disturbed that I haven't seen any widely shared communication about this, how it broke, what is being done to fix, or what can be done to stop it in the future. Things seem really broken with our CI system in general. I wonder that this isn't the normalization of deviance. Has the project just given up and regards this as standard operating procedure? - Adam From adam.treat at qt.io Mon Dec 11 17:47:41 2017 From: adam.treat at qt.io (Adam Treat) Date: Mon, 11 Dec 2017 11:47:41 -0500 Subject: [Development] COIN failures on dev In-Reply-To: References: Message-ID: Whenever I discover something seemingly broken in an area of code I'm unfamiliar with I first suspect I don't understand something... Right now I'm looking for the last successful dev branch integration on qt5 supermodule and I can not find it. I've gone back to before Thanksgiving. Can this possibly be correct?? Where is the dashboard showing the last successful integration for a given branch? On 12/11/2017 11:24 AM, Adam Treat wrote: > Hi, > > For the past few business days we've all witnessed failures on dev > branch like this: https://codereview.qt-project.org/#/c/213309/ > > Seems that something broke with provisioning on macOS or something. I > see this https://codereview.qt-project.org/#/c/214045/ attempt to fix, > but that is also failing to integrate due to seemingly unrelated reasons. > > I'm disturbed that I haven't seen any widely shared communication > about this, how it broke, what is being done to fix, or what can be > done to stop it in the future. > > Things seem really broken with our CI system in general. I wonder that > this isn't the normalization of deviance. Has the project just given > up and regards this as standard operating procedure? > > - Adam > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Mon Dec 11 19:05:13 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 11 Dec 2017 10:05:13 -0800 Subject: [Development] COIN failures on dev In-Reply-To: References: Message-ID: <5672234.5JyxA9uukX@tjmaciei-mobl1> On Monday, 11 December 2017 08:47:41 PST Adam Treat wrote: > Whenever I discover something seemingly broken in an area of code I'm > unfamiliar with I first suspect I don't understand something... > > Right now I'm looking for the last successful dev branch integration on > qt5 supermodule and I can not find it. I've gone back to before > Thanksgiving. > > Can this possibly be correct?? The last qt5/dev integration is over a month old, from what I was told last week. > Where is the dashboard showing the last successful integration for a > given branch? https://testresults.qt.io/coin/?project=qt%2Fqt5 But it looks like the last success is so old it fell off the list. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Tue Dec 12 09:09:03 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 12 Dec 2017 08:09:03 +0000 Subject: [Development] COIN failures on dev In-Reply-To: References: , Message-ID: Hi, I find the easiest way to find the last successful integration for example for qt5.git dev is this: (1) Go to http://code.qt.io/cgit/qt/qt5.git/ and pick the dev branch (2) Click on the last commit in the branch (3) Click on the "Change-Id" link or paste the commit sha1 into the Gerrit search field (4) At the bottom of the change in Gerrit you can find a link to https://testresults.qt.io/ with more details about the actual integration and what other changes it was tested together with (https://testresults.qt.io/coin/integration/qt/qt5/tasks/1510549095 in this case). The git repo is our source of truth, and from there it's easy to get back to gerrit and then the CI. All of the above steps can also be done entirely in a CLI way by using Gerrit's ssh query interface. Simon ________________________________ From: Development on behalf of Adam Treat Sent: Monday, December 11, 2017 5:47:41 PM To: development at qt-project.org Subject: Re: [Development] COIN failures on dev Whenever I discover something seemingly broken in an area of code I'm unfamiliar with I first suspect I don't understand something... Right now I'm looking for the last successful dev branch integration on qt5 supermodule and I can not find it. I've gone back to before Thanksgiving. Can this possibly be correct?? Where is the dashboard showing the last successful integration for a given branch? On 12/11/2017 11:24 AM, Adam Treat wrote: > Hi, > > For the past few business days we've all witnessed failures on dev > branch like this: https://codereview.qt-project.org/#/c/213309/ > > Seems that something broke with provisioning on macOS or something. I > see this https://codereview.qt-project.org/#/c/214045/ attempt to fix, > but that is also failing to integrate due to seemingly unrelated reasons. > > I'm disturbed that I haven't seen any widely shared communication > about this, how it broke, what is being done to fix, or what can be > done to stop it in the future. > > Things seem really broken with our CI system in general. I wonder that > this isn't the normalization of deviance. Has the project just given > up and regards this as standard operating procedure? > > - Adam > > _______________________________________________ > 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 adam.treat at qt.io Tue Dec 12 13:09:47 2017 From: adam.treat at qt.io (Adam Treat) Date: Tue, 12 Dec 2017 12:09:47 +0000 Subject: [Development] COIN failures on dev In-Reply-To: References: , , Message-ID: Ah, so last successful integration on qt5 super module was nearly a month ago?? 11/172017 Now, what I was really after was last generally unsuccessful integration to see how all the brokenness went through. I guess the git repo is not the source of truth for that. The integrations yesterday were failing seemingly unrelated to the patch. Folks seemed generally unsurprised this was happening and attributed it to flakiness that is generally known and that force pushes are the way to deal with that. Is this customary? Force pushing because the CI results are too flaky to be trusted? ________________________________ From: Simon Hausmann Sent: Tuesday, December 12, 2017 3:09:03 AM To: Adam Treat; development at qt-project.org Subject: Re: [Development] COIN failures on dev Hi, I find the easiest way to find the last successful integration for example for qt5.git dev is this: (1) Go to http://code.qt.io/cgit/qt/qt5.git/ and pick the dev branch (2) Click on the last commit in the branch (3) Click on the "Change-Id" link or paste the commit sha1 into the Gerrit search field (4) At the bottom of the change in Gerrit you can find a link to https://testresults.qt.io/ with more details about the actual integration and what other changes it was tested together with (https://testresults.qt.io/coin/integration/qt/qt5/tasks/1510549095 in this case). The git repo is our source of truth, and from there it's easy to get back to gerrit and then the CI. All of the above steps can also be done entirely in a CLI way by using Gerrit's ssh query interface. Simon ________________________________ From: Development on behalf of Adam Treat Sent: Monday, December 11, 2017 5:47:41 PM To: development at qt-project.org Subject: Re: [Development] COIN failures on dev Whenever I discover something seemingly broken in an area of code I'm unfamiliar with I first suspect I don't understand something... Right now I'm looking for the last successful dev branch integration on qt5 supermodule and I can not find it. I've gone back to before Thanksgiving. Can this possibly be correct?? Where is the dashboard showing the last successful integration for a given branch? On 12/11/2017 11:24 AM, Adam Treat wrote: > Hi, > > For the past few business days we've all witnessed failures on dev > branch like this: https://codereview.qt-project.org/#/c/213309/ > > Seems that something broke with provisioning on macOS or something. I > see this https://codereview.qt-project.org/#/c/214045/ attempt to fix, > but that is also failing to integrate due to seemingly unrelated reasons. > > I'm disturbed that I haven't seen any widely shared communication > about this, how it broke, what is being done to fix, or what can be > done to stop it in the future. > > Things seem really broken with our CI system in general. I wonder that > this isn't the normalization of deviance. Has the project just given > up and regards this as standard operating procedure? > > - Adam > > _______________________________________________ > 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 denis.shienkov at gmail.com Tue Dec 12 14:13:15 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Tue, 12 Dec 2017 16:13:15 +0300 Subject: [Development] How fast grab a QML item's content to image when it updates? Message-ID: <75a7c659-fb74-19b6-abbe-657114d0f46f@gmail.com> Hi all... Is it possible to grab a QQuickItem content (e.g. with all sub-items) when an item changes? E.g. with widgets I use the following code: bool MyWidget::event(QEvent *event) {     if (event->type() == QEvent::UpdateRequest)         myGrab();     return QWidget::event(event); } void MyWidget::myGrab() {     ...     QBackingStore *store = backingStore();     Q_ASSERT(store);     QPaintDevice *pdev = store->paintDevice();     const auto image = dynamic_cast(pdev);     ... } it is very fast (as I know)... But with the QML I got a troubles: I can 'grab' the sourceItem, using the FBO and private functions, but the fbo::toImage() is too slow (~24 msecs), and I don't know how to intercept the signal when a watched item updates: Grabber::Grabber(QQuickItem *parent)     : QQuickItem(parent) {     setFlag(QQuickItem::ItemHasContents); } // Where sourceItem - is a watched item. void Grabber::setSourceItem(QQuickItem *sourceItem) {     if (sourceItem == m_sourceItem)         return;     m_sourceItem = sourceItem;     emit sourceItemChanged(m_sourceItem);     update(); } QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,                                   UpdatePaintNodeData *updatePaintNodeData) {     Q_UNUSED(updatePaintNodeData);     if (!m_sourceItem)         return oldNode;     QSGRootNode root; root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());     const QScopedPointer renderer(                 QQuickItemPrivate::get(this)->                 sceneGraphRenderContext()->createRenderer());     renderer->setRootNode(&root);     const QSize size(m_sourceItem->width(), m_sourceItem->height());     renderer->setDeviceRect(size);     renderer->setViewportRect(size);     renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));     renderer->setClearColor(Qt::transparent);     QOpenGLFramebufferObject fbo(size);     renderer->renderScene(BindableFbo(&fbo));     fbo.release();     QElapsedTimer et;     et.start();     const QImage image = fbo.toImage(); // TOO LONG ~24 msec!     qDebug() << "Elapsed:" << et.elapsed();     return oldNode; } it is very fast (as I know). But with the QML I got a troubles: I can 'grub' an item, using the FBO, but the toImage() method is too slow (~24 msecs), and I don't know how to intercept a signal when the watched item updates: Grabber::Grabber(QQuickItem *parent)     : QQuickItem(parent) {     setFlag(QQuickItem::ItemHasContents); } QSGNode *Grabber::updatePaintNode(QSGNode *oldNode,                                   UpdatePaintNodeData *updatePaintNodeData) {     Q_UNUSED(updatePaintNodeData);     if (!m_sourceItem)         return oldNode;     QSGRootNode root; root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode());     const QScopedPointer renderer(                 QQuickItemPrivate::get(this)->                 sceneGraphRenderContext()->createRenderer());     renderer->setRootNode(&root);     const QSize size(m_sourceItem->width(), m_sourceItem->height());     renderer->setDeviceRect(size);     renderer->setViewportRect(size);     renderer->setProjectionMatrixToRect(QRectF(QPointF(), size));     renderer->setClearColor(Qt::transparent);     QOpenGLFramebufferObject fbo(size);     renderer->renderScene(BindableFbo(&fbo));     fbo.release();     QElapsedTimer et;     et.start();     const QImage image = fbo.toImage(); // TOO LONG!     qDebug() << "Elapsed:" << et.elapsed();     return oldNode; } From denis.shienkov at gmail.com Tue Dec 12 14:17:05 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Tue, 12 Dec 2017 16:17:05 +0300 Subject: [Development] How fast grab a QML item's content to image when it updates? In-Reply-To: <75a7c659-fb74-19b6-abbe-657114d0f46f@gmail.com> References: <75a7c659-fb74-19b6-abbe-657114d0f46f@gmail.com> Message-ID: <1ea0d65c-139b-0774-abd7-a91d70b6a1fa@gmail.com> 12.12.2017 16:13, Denis Shienkov пишет: > Hi all... > > Is it possible to grab a QQuickItem content (e.g. with all sub-items) > when an item changes? > > E.g. with widgets I use the following code: > > bool MyWidget::event(QEvent *event) > { >     if (event->type() == QEvent::UpdateRequest) >         myGrab(); >     return QWidget::event(event); > } > > void MyWidget::myGrab() > { >     ... >     QBackingStore *store = backingStore(); >     Q_ASSERT(store); > >     QPaintDevice *pdev = store->paintDevice(); >     const auto image = dynamic_cast(pdev); >     ... > } > > it is very fast (as I know)... > > But with the QML I got a troubles: I can 'grab' the sourceItem, using > the FBO and private functions, but the fbo::toImage() is too slow (~24 > msecs), > and I don't know how to intercept the signal when a watched item updates: > > Grabber::Grabber(QQuickItem *parent) >     : QQuickItem(parent) > { >     setFlag(QQuickItem::ItemHasContents); > } > > // Where sourceItem - is a watched item. > void Grabber::setSourceItem(QQuickItem *sourceItem) > { >     if (sourceItem == m_sourceItem) >         return; >     m_sourceItem = sourceItem; >     emit sourceItemChanged(m_sourceItem); >     update(); > } > > QSGNode *Grabber::updatePaintNode(QSGNode *oldNode, >                                   UpdatePaintNodeData > *updatePaintNodeData) > { >     Q_UNUSED(updatePaintNodeData); > >     if (!m_sourceItem) >         return oldNode; > >     QSGRootNode root; > root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode()); > >     const QScopedPointer renderer( >                 QQuickItemPrivate::get(this)-> >                 sceneGraphRenderContext()->createRenderer()); > >     renderer->setRootNode(&root); > >     const QSize size(m_sourceItem->width(), m_sourceItem->height()); >     renderer->setDeviceRect(size); >     renderer->setViewportRect(size); >     renderer->setProjectionMatrixToRect(QRectF(QPointF(), size)); >     renderer->setClearColor(Qt::transparent); > >     QOpenGLFramebufferObject fbo(size); >     renderer->renderScene(BindableFbo(&fbo)); >     fbo.release(); > >     QElapsedTimer et; >     et.start(); >     const QImage image = fbo.toImage(); // TOO LONG ~24 msec! >     qDebug() << "Elapsed:" << et.elapsed(); > >     return oldNode; > } > From annulen at yandex.ru Tue Dec 12 14:40:50 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 12 Dec 2017 16:40:50 +0300 Subject: [Development] How fast grab a QML item's content to image when it updates? In-Reply-To: <75a7c659-fb74-19b6-abbe-657114d0f46f@gmail.com> References: <75a7c659-fb74-19b6-abbe-657114d0f46f@gmail.com> Message-ID: <323051513086050@web51g.yandex.ru> 12.12.2017, 16:13, "Denis Shienkov" : > Hi all... > > Is it possible to grab a QQuickItem content (e.g. with all sub-items) > when an item changes? Did you try QQuickItem::grabToImage? > > E.g. with widgets I use the following code: > > bool MyWidget::event(QEvent *event) > { >      if (event->type() == QEvent::UpdateRequest) >          myGrab(); >      return QWidget::event(event); > } > > void MyWidget::myGrab() > { >      ... >      QBackingStore *store = backingStore(); >      Q_ASSERT(store); > >      QPaintDevice *pdev = store->paintDevice(); >      const auto image = dynamic_cast(pdev); >      ... > } > > it is very fast (as I know)... > > But with the QML I got a troubles: I can 'grab' the sourceItem, using > the FBO and private functions, but the fbo::toImage() is too slow (~24 > msecs), > and I don't know how to intercept the signal when a watched item updates: > > Grabber::Grabber(QQuickItem *parent) >      : QQuickItem(parent) > { >      setFlag(QQuickItem::ItemHasContents); > } > > // Where sourceItem - is a watched item. > void Grabber::setSourceItem(QQuickItem *sourceItem) > { >      if (sourceItem == m_sourceItem) >          return; >      m_sourceItem = sourceItem; >      emit sourceItemChanged(m_sourceItem); >      update(); > } > > QSGNode *Grabber::updatePaintNode(QSGNode *oldNode, >                                    UpdatePaintNodeData *updatePaintNodeData) > { >      Q_UNUSED(updatePaintNodeData); > >      if (!m_sourceItem) >          return oldNode; > >      QSGRootNode root; > root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode()); > >      const QScopedPointer renderer( >                  QQuickItemPrivate::get(this)-> >                  sceneGraphRenderContext()->createRenderer()); > >      renderer->setRootNode(&root); > >      const QSize size(m_sourceItem->width(), m_sourceItem->height()); >      renderer->setDeviceRect(size); >      renderer->setViewportRect(size); >      renderer->setProjectionMatrixToRect(QRectF(QPointF(), size)); >      renderer->setClearColor(Qt::transparent); > >      QOpenGLFramebufferObject fbo(size); >      renderer->renderScene(BindableFbo(&fbo)); >      fbo.release(); > >      QElapsedTimer et; >      et.start(); >      const QImage image = fbo.toImage(); // TOO LONG ~24 msec! >      qDebug() << "Elapsed:" << et.elapsed(); > >      return oldNode; > } > > it is very fast (as I know). > > But with the QML I got a troubles: I can 'grub' an item, using the FBO, > > but the toImage() method is too slow (~24 msecs), and I don't know how > > to intercept a signal when the watched item updates: > > Grabber::Grabber(QQuickItem *parent) >      : QQuickItem(parent) > { >      setFlag(QQuickItem::ItemHasContents); > } > > QSGNode *Grabber::updatePaintNode(QSGNode *oldNode, >                                    UpdatePaintNodeData *updatePaintNodeData) > { >      Q_UNUSED(updatePaintNodeData); > >      if (!m_sourceItem) >          return oldNode; > >      QSGRootNode root; > root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode()); > >      const QScopedPointer renderer( >                  QQuickItemPrivate::get(this)-> >                  sceneGraphRenderContext()->createRenderer()); > >      renderer->setRootNode(&root); > >      const QSize size(m_sourceItem->width(), m_sourceItem->height()); >      renderer->setDeviceRect(size); >      renderer->setViewportRect(size); >      renderer->setProjectionMatrixToRect(QRectF(QPointF(), size)); >      renderer->setClearColor(Qt::transparent); > >      QOpenGLFramebufferObject fbo(size); >      renderer->renderScene(BindableFbo(&fbo)); >      fbo.release(); > >      QElapsedTimer et; >      et.start(); >      const QImage image = fbo.toImage(); // TOO LONG! >      qDebug() << "Elapsed:" << et.elapsed(); > >      return oldNode; > } > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From denis.shienkov at gmail.com Tue Dec 12 14:53:09 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Tue, 12 Dec 2017 16:53:09 +0300 Subject: [Development] How fast grab a QML item's content to image when it updates? In-Reply-To: <323051513086050@web51g.yandex.ru> References: <75a7c659-fb74-19b6-abbe-657114d0f46f@gmail.com> <323051513086050@web51g.yandex.ru> Message-ID: <81783351-ebcf-7e17-ff34-eaea3a164b85@gmail.com> > Did you try QQuickItem::grabToImage? Of course, it is veeery slowly. 12.12.2017 16:40, Konstantin Tokarev пишет: > > 12.12.2017, 16:13, "Denis Shienkov" : >> Hi all... >> >> Is it possible to grab a QQuickItem content (e.g. with all sub-items) >> when an item changes? > Did you try QQuickItem::grabToImage? > >> E.g. with widgets I use the following code: >> >> bool MyWidget::event(QEvent *event) >> { >>      if (event->type() == QEvent::UpdateRequest) >>          myGrab(); >>      return QWidget::event(event); >> } >> >> void MyWidget::myGrab() >> { >>      ... >>      QBackingStore *store = backingStore(); >>      Q_ASSERT(store); >> >>      QPaintDevice *pdev = store->paintDevice(); >>      const auto image = dynamic_cast(pdev); >>      ... >> } >> >> it is very fast (as I know)... >> >> But with the QML I got a troubles: I can 'grab' the sourceItem, using >> the FBO and private functions, but the fbo::toImage() is too slow (~24 >> msecs), >> and I don't know how to intercept the signal when a watched item updates: >> >> Grabber::Grabber(QQuickItem *parent) >>      : QQuickItem(parent) >> { >>      setFlag(QQuickItem::ItemHasContents); >> } >> >> // Where sourceItem - is a watched item. >> void Grabber::setSourceItem(QQuickItem *sourceItem) >> { >>      if (sourceItem == m_sourceItem) >>          return; >>      m_sourceItem = sourceItem; >>      emit sourceItemChanged(m_sourceItem); >>      update(); >> } >> >> QSGNode *Grabber::updatePaintNode(QSGNode *oldNode, >>                                    UpdatePaintNodeData *updatePaintNodeData) >> { >>      Q_UNUSED(updatePaintNodeData); >> >>      if (!m_sourceItem) >>          return oldNode; >> >>      QSGRootNode root; >> root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode()); >> >>      const QScopedPointer renderer( >>                  QQuickItemPrivate::get(this)-> >>                  sceneGraphRenderContext()->createRenderer()); >> >>      renderer->setRootNode(&root); >> >>      const QSize size(m_sourceItem->width(), m_sourceItem->height()); >>      renderer->setDeviceRect(size); >>      renderer->setViewportRect(size); >>      renderer->setProjectionMatrixToRect(QRectF(QPointF(), size)); >>      renderer->setClearColor(Qt::transparent); >> >>      QOpenGLFramebufferObject fbo(size); >>      renderer->renderScene(BindableFbo(&fbo)); >>      fbo.release(); >> >>      QElapsedTimer et; >>      et.start(); >>      const QImage image = fbo.toImage(); // TOO LONG ~24 msec! >>      qDebug() << "Elapsed:" << et.elapsed(); >> >>      return oldNode; >> } >> >> it is very fast (as I know). >> >> But with the QML I got a troubles: I can 'grub' an item, using the FBO, >> >> but the toImage() method is too slow (~24 msecs), and I don't know how >> >> to intercept a signal when the watched item updates: >> >> Grabber::Grabber(QQuickItem *parent) >>      : QQuickItem(parent) >> { >>      setFlag(QQuickItem::ItemHasContents); >> } >> >> QSGNode *Grabber::updatePaintNode(QSGNode *oldNode, >>                                    UpdatePaintNodeData *updatePaintNodeData) >> { >>      Q_UNUSED(updatePaintNodeData); >> >>      if (!m_sourceItem) >>          return oldNode; >> >>      QSGRootNode root; >> root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode()); >> >>      const QScopedPointer renderer( >>                  QQuickItemPrivate::get(this)-> >>                  sceneGraphRenderContext()->createRenderer()); >> >>      renderer->setRootNode(&root); >> >>      const QSize size(m_sourceItem->width(), m_sourceItem->height()); >>      renderer->setDeviceRect(size); >>      renderer->setViewportRect(size); >>      renderer->setProjectionMatrixToRect(QRectF(QPointF(), size)); >>      renderer->setClearColor(Qt::transparent); >> >>      QOpenGLFramebufferObject fbo(size); >>      renderer->renderScene(BindableFbo(&fbo)); >>      fbo.release(); >> >>      QElapsedTimer et; >>      et.start(); >>      const QImage image = fbo.toImage(); // TOO LONG! >>      qDebug() << "Elapsed:" << et.elapsed(); >> >>      return oldNode; >> } >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development From Shawn.Rutledge at qt.io Tue Dec 12 16:20:00 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 12 Dec 2017 15:20:00 +0000 Subject: [Development] How fast grab a QML item's content to image when it updates? In-Reply-To: <81783351-ebcf-7e17-ff34-eaea3a164b85@gmail.com> References: <75a7c659-fb74-19b6-abbe-657114d0f46f@gmail.com> <323051513086050@web51g.yandex.ru> <81783351-ebcf-7e17-ff34-eaea3a164b85@gmail.com> Message-ID: <3901824D-4A8B-4F03-BCBA-321929AE83D4@qt.io> > On 12 Dec 2017, at 14:53, Denis Shienkov wrote: > > > Did you try QQuickItem::grabToImage? > > Of course, it is veeery slowly. If the frame was rendered on the GPU, you have to download it from there, and that is slower than if you had rendered into CPU memory, as widgets do by default. Thus the note in the docs: Note: This function will render the item to an offscreen surface and copy that surface from the GPU's memory into the CPU's memory, which can be quite costly. For "live" preview, use layers or ShaderEffectSource. So, maybe try to get the GPU to do whatever comes next after you think you need to grab the frame? grabToImage is more for archival, not for real-time effects (although I did use it recently to record an animated GIF; I could only get 30FPS despite using a fairly powerful GPU, but that was good enough). From denis.shienkov at gmail.com Tue Dec 12 16:43:23 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Tue, 12 Dec 2017 18:43:23 +0300 Subject: [Development] How fast grab a QML item's content to image when it updates? In-Reply-To: <3901824D-4A8B-4F03-BCBA-321929AE83D4@qt.io> References: <75a7c659-fb74-19b6-abbe-657114d0f46f@gmail.com> <323051513086050@web51g.yandex.ru> <81783351-ebcf-7e17-ff34-eaea3a164b85@gmail.com> <3901824D-4A8B-4F03-BCBA-321929AE83D4@qt.io> Message-ID: Now I tried to use the following code: classBindableFbofinal:publicQSGBindable { public: explicitBindableFbo(QOpenGLFramebufferObject*fbo) :m_fbo(fbo) {} voidbind()constfinal{m_fbo->bind();} private: QOpenGLFramebufferObject*m_fbo=nullptr; }; Grabber::Grabber(QQuickItem*parent) :QQuickItem(parent) { setFlag(QQuickItem::ItemHasContents); connect(this,&Grabber::windowChanged, this,&Grabber::scheduleWindowChange); } voidGrabber::setSourceItem(QQuickItem*sourceItem) { if(sourceItem==m_sourceItem) return; m_sourceItem=sourceItem; emitsourceItemChanged(m_sourceItem); update(); } QQuickItem*Grabber::sourceItem()const { returnm_sourceItem; } QSGNode*Grabber::updatePaintNode(QSGNode*oldNode, UpdatePaintNodeData*updatePaintNodeData) { Q_UNUSED(updatePaintNodeData); if(!m_sourceItem) returnoldNode; m_running=true; constautoitemNode=QQuickItemPrivate::get(m_sourceItem)->itemNode(); constautoparentNode=itemNode->parent(); constautosiblingNode=itemNode->previousSibling(); if(parentNode) parentNode->removeChildNode(itemNode); constQScopedPointerrenderer( QQuickItemPrivate::get(this)-> sceneGraphRenderContext()->createRenderer()); QSGRootNoderootNode; rootNode.appendChildNode(itemNode); renderer->setRootNode(&rootNode); constQSizesize(m_sourceItem->width(),m_sourceItem->height()); renderer->setDeviceRect(size); renderer->setViewportRect(size); renderer->setProjectionMatrixToRect(QRectF(QPointF(),size)); renderer->setClearColor(Qt::transparent); QOpenGLFramebufferObjectfbo(size); renderer->renderScene(BindableFbo(&fbo)); fbo.release(); rootNode.removeChildNode(itemNode); if(parentNode){ if(siblingNode){ parentNode->insertChildNodeAfter(itemNode,siblingNode); }else{ parentNode->prependChildNode(itemNode); } } QElapsedTimeret; et.start(); constQImageimage=fbo.toImage();//TOOLONG! staticintcount=0; qDebug()<<"Elapsed:"<> On 12 Dec 2017, at 14:53, Denis Shienkov wrote: >> >>> Did you try QQuickItem::grabToImage? >> Of course, it is veeery slowly. > If the frame was rendered on the GPU, you have to download it from there, and that is slower than if you had rendered into CPU memory, as widgets do by default. Thus the note in the docs: > > Note: This function will render the item to an offscreen surface and copy > that surface from the GPU's memory into the CPU's memory, which can be > quite costly. For "live" preview, use layers or ShaderEffectSource. > > So, maybe try to get the GPU to do whatever comes next after you think you need to grab the frame? grabToImage is more for archival, not for real-time effects (although I did use it recently to record an animated GIF; I could only get 30FPS despite using a fairly powerful GPU, but that was good enough). > > _______________________________________________ > 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 annulen at yandex.ru Tue Dec 12 16:52:46 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 12 Dec 2017 18:52:46 +0300 Subject: [Development] How fast grab a QML item's content to image when it updates? References: <75a7c659-fb74-19b6-abbe-657114d0f46f@gmail.com> <323051513086050@web51g.yandex.ru> <81783351-ebcf-7e17-ff34-eaea3a164b85@gmail.com> Message-ID: <652881513093966@web29o.yandex.ru> 12.12.2017, 16:53, "Denis Shienkov" : >  > Did you try QQuickItem::grabToImage? > > Of course, it is veeery slowly. I guess your best bet then is hardware grabbing video output > > 12.12.2017 16:40, Konstantin Tokarev пишет: >>  12.12.2017, 16:13, "Denis Shienkov" : >>>  Hi all... >>> >>>  Is it possible to grab a QQuickItem content (e.g. with all sub-items) >>>  when an item changes? >>  Did you try QQuickItem::grabToImage? >> >>>  E.g. with widgets I use the following code: >>> >>>  bool MyWidget::event(QEvent *event) >>>  { >>>        if (event->type() == QEvent::UpdateRequest) >>>            myGrab(); >>>        return QWidget::event(event); >>>  } >>> >>>  void MyWidget::myGrab() >>>  { >>>        ... >>>        QBackingStore *store = backingStore(); >>>        Q_ASSERT(store); >>> >>>        QPaintDevice *pdev = store->paintDevice(); >>>        const auto image = dynamic_cast(pdev); >>>        ... >>>  } >>> >>>  it is very fast (as I know)... >>> >>>  But with the QML I got a troubles: I can 'grab' the sourceItem, using >>>  the FBO and private functions, but the fbo::toImage() is too slow (~24 >>>  msecs), >>>  and I don't know how to intercept the signal when a watched item updates: >>> >>>  Grabber::Grabber(QQuickItem *parent) >>>        : QQuickItem(parent) >>>  { >>>        setFlag(QQuickItem::ItemHasContents); >>>  } >>> >>>  // Where sourceItem - is a watched item. >>>  void Grabber::setSourceItem(QQuickItem *sourceItem) >>>  { >>>        if (sourceItem == m_sourceItem) >>>            return; >>>        m_sourceItem = sourceItem; >>>        emit sourceItemChanged(m_sourceItem); >>>        update(); >>>  } >>> >>>  QSGNode *Grabber::updatePaintNode(QSGNode *oldNode, >>>                                      UpdatePaintNodeData *updatePaintNodeData) >>>  { >>>        Q_UNUSED(updatePaintNodeData); >>> >>>        if (!m_sourceItem) >>>            return oldNode; >>> >>>        QSGRootNode root; >>>  root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode()); >>> >>>        const QScopedPointer renderer( >>>                    QQuickItemPrivate::get(this)-> >>>                    sceneGraphRenderContext()->createRenderer()); >>> >>>        renderer->setRootNode(&root); >>> >>>        const QSize size(m_sourceItem->width(), m_sourceItem->height()); >>>        renderer->setDeviceRect(size); >>>        renderer->setViewportRect(size); >>>        renderer->setProjectionMatrixToRect(QRectF(QPointF(), size)); >>>        renderer->setClearColor(Qt::transparent); >>> >>>        QOpenGLFramebufferObject fbo(size); >>>        renderer->renderScene(BindableFbo(&fbo)); >>>        fbo.release(); >>> >>>        QElapsedTimer et; >>>        et.start(); >>>        const QImage image = fbo.toImage(); // TOO LONG ~24 msec! >>>        qDebug() << "Elapsed:" << et.elapsed(); >>> >>>        return oldNode; >>>  } >>> >>>  it is very fast (as I know). >>> >>>  But with the QML I got a troubles: I can 'grub' an item, using the FBO, >>> >>>  but the toImage() method is too slow (~24 msecs), and I don't know how >>> >>>  to intercept a signal when the watched item updates: >>> >>>  Grabber::Grabber(QQuickItem *parent) >>>        : QQuickItem(parent) >>>  { >>>        setFlag(QQuickItem::ItemHasContents); >>>  } >>> >>>  QSGNode *Grabber::updatePaintNode(QSGNode *oldNode, >>>                                      UpdatePaintNodeData *updatePaintNodeData) >>>  { >>>        Q_UNUSED(updatePaintNodeData); >>> >>>        if (!m_sourceItem) >>>            return oldNode; >>> >>>        QSGRootNode root; >>>  root.appendChildNode(QQuickItemPrivate::get(m_sourceItem)->itemNode()); >>> >>>        const QScopedPointer renderer( >>>                    QQuickItemPrivate::get(this)-> >>>                    sceneGraphRenderContext()->createRenderer()); >>> >>>        renderer->setRootNode(&root); >>> >>>        const QSize size(m_sourceItem->width(), m_sourceItem->height()); >>>        renderer->setDeviceRect(size); >>>        renderer->setViewportRect(size); >>>        renderer->setProjectionMatrixToRect(QRectF(QPointF(), size)); >>>        renderer->setClearColor(Qt::transparent); >>> >>>        QOpenGLFramebufferObject fbo(size); >>>        renderer->renderScene(BindableFbo(&fbo)); >>>        fbo.release(); >>> >>>        QElapsedTimer et; >>>        et.start(); >>>        const QImage image = fbo.toImage(); // TOO LONG! >>>        qDebug() << "Elapsed:" << et.elapsed(); >>> >>>        return oldNode; >>>  } >>> >>>  _______________________________________________ >>>  Development mailing list >>>  Development at qt-project.org >>>  http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From tuukka.turunen at qt.io Tue Dec 12 19:24:23 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 12 Dec 2017 18:24:23 +0000 Subject: [Development] COIN failures on dev In-Reply-To: References: Message-ID: Hi, Force pushing of what? Of course in a situation where nothing else is possible, we need to have a way to unblock CI by forced push. But we are not pushing other than really mandatory fixes in bypassing the CI. It is very unfortunate that dev has been broken for a while, but work is ongoing to unblock it. Yours, Tuukka From: Development on behalf of Adam Treat Date: Tuesday, 12 December 2017 at 13.10 To: Simon Hausmann , "development at qt-project.org" Subject: Re: [Development] COIN failures on dev Ah, so last successful integration on qt5 super module was nearly a month ago?? 11/172017 Now, what I was really after was last generally unsuccessful integration to see how all the brokenness went through. I guess the git repo is not the source of truth for that. The integrations yesterday were failing seemingly unrelated to the patch. Folks seemed generally unsurprised this was happening and attributed it to flakiness that is generally known and that force pushes are the way to deal with that. Is this customary? Force pushing because the CI results are too flaky to be trusted? ________________________________ From: Simon Hausmann Sent: Tuesday, December 12, 2017 3:09:03 AM To: Adam Treat; development at qt-project.org Subject: Re: [Development] COIN failures on dev Hi, I find the easiest way to find the last successful integration for example for qt5.git dev is this: (1) Go to http://code.qt.io/cgit/qt/qt5.git/ and pick the dev branch (2) Click on the last commit in the branch (3) Click on the "Change-Id" link or paste the commit sha1 into the Gerrit search field (4) At the bottom of the change in Gerrit you can find a link to https://testresults.qt.io/ with more details about the actual integration and what other changes it was tested together with (https://testresults.qt.io/coin/integration/qt/qt5/tasks/1510549095 in this case). The git repo is our source of truth, and from there it's easy to get back to gerrit and then the CI. All of the above steps can also be done entirely in a CLI way by using Gerrit's ssh query interface. Simon ________________________________ From: Development on behalf of Adam Treat Sent: Monday, December 11, 2017 5:47:41 PM To: development at qt-project.org Subject: Re: [Development] COIN failures on dev Whenever I discover something seemingly broken in an area of code I'm unfamiliar with I first suspect I don't understand something... Right now I'm looking for the last successful dev branch integration on qt5 supermodule and I can not find it. I've gone back to before Thanksgiving. Can this possibly be correct?? Where is the dashboard showing the last successful integration for a given branch? On 12/11/2017 11:24 AM, Adam Treat wrote: > Hi, > > For the past few business days we've all witnessed failures on dev > branch like this: https://codereview.qt-project.org/#/c/213309/ > > Seems that something broke with provisioning on macOS or something. I > see this https://codereview.qt-project.org/#/c/214045/ attempt to fix, > but that is also failing to integrate due to seemingly unrelated reasons. > > I'm disturbed that I haven't seen any widely shared communication > about this, how it broke, what is being done to fix, or what can be > done to stop it in the future. > > Things seem really broken with our CI system in general. I wonder that > this isn't the normalization of deviance. Has the project just given > up and regards this as standard operating procedure? > > - Adam > > _______________________________________________ > 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 adam.treat at qt.io Tue Dec 12 19:28:45 2017 From: adam.treat at qt.io (Adam Treat) Date: Tue, 12 Dec 2017 13:28:45 -0500 Subject: [Development] COIN failures on dev In-Reply-To: References: Message-ID: <18d7b8e8-796c-74fb-99c5-307e125d21b8@qt.io> This was apparently the result of a miscommunication and no force pushing is contemplated. On 12/12/2017 01:24 PM, Tuukka Turunen wrote: > > Hi, > > Force pushing of what? Of course in a situation where nothing else is > possible, we need to have a way to unblock CI by forced push. But we > are not pushing other than really mandatory fixes in bypassing the CI. > > It is very unfortunate that dev has been broken for a while, but work > is ongoing to unblock it. > > Yours, > >                                 Tuukka > > *From: *Development > on behalf of > Adam Treat > *Date: *Tuesday, 12 December 2017 at 13.10 > *To: *Simon Hausmann , > "development at qt-project.org" > *Subject: *Re: [Development] COIN failures on dev > > Ah, so last successful integration on qt5 super module was nearly a > month ago?? 11/172017 > > Now, what I was really after was last generally unsuccessful > integration to see how all the brokenness went through.  I guess the > git repo is not the source of truth for that. The integrations > yesterday were failing seemingly unrelated to the patch. Folks seemed > generally unsurprised this was happening and attributed it to > flakiness that is generally known and that force pushes are the way to > deal with that. > > Is this customary? Force pushing because the CI results are too flaky > to be trusted? > > ------------------------------------------------------------------------ > > *From:*Simon Hausmann > *Sent:* Tuesday, December 12, 2017 3:09:03 AM > *To:* Adam Treat; development at qt-project.org > *Subject:* Re: [Development] COIN failures on dev > > Hi, > > I find the easiest way to find the last successful integration for > example for qt5.git dev is this: > >     (1) Go to http://code.qt.io/cgit/qt/qt5.git/ and pick the dev branch > >     (2) Click on the last commit in the branch > >     (3) Click on the "Change-Id" link or paste the commit sha1 into > the Gerrit search field > >     (4) At the bottom of the change in Gerrit you can find a link to > https://testresults.qt.io/ with more details about the actual > integration and what other changes it was tested together with > (https://testresults.qt.io/coin/integration/qt/qt5/tasks/1510549095 in > this case). > > The git repo is our source of truth, and from there it's easy to get > back to gerrit and then the CI. All of the above steps can also be > done entirely in a CLI way by using Gerrit's ssh query interface. > > Simon > > ------------------------------------------------------------------------ > > *From:*Development > on behalf of > Adam Treat > *Sent:* Monday, December 11, 2017 5:47:41 PM > *To:* development at qt-project.org > *Subject:* Re: [Development] COIN failures on dev > > Whenever I discover something seemingly broken in an area of code I'm > unfamiliar with I first suspect I don't understand something... > > Right now I'm looking for the last successful dev branch integration on > qt5 supermodule and I can not find it. I've gone back to before > Thanksgiving. > > Can this possibly be correct?? > > Where is the dashboard showing the last successful integration for a > given branch? > > On 12/11/2017 11:24 AM, Adam Treat wrote: > > Hi, > > > > For the past few business days we've all witnessed failures on dev > > branch like this: https://codereview.qt-project.org/#/c/213309/ > > > > Seems that something broke with provisioning on macOS or something. I > > see this https://codereview.qt-project.org/#/c/214045/ attempt to fix, > > but that is also failing to integrate due to seemingly unrelated > reasons. > > > > I'm disturbed that I haven't seen any widely shared communication > > about this, how it broke, what is being done to fix, or what can be > > done to stop it in the future. > > > > Things seem really broken with our CI system in general. I wonder that > > this isn't the normalization of deviance. Has the project just given > > up and regards this as standard operating procedure? > > > > - Adam > > > > _______________________________________________ > > 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 bstottle at ford.com Tue Dec 12 19:38:34 2017 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Tue, 12 Dec 2017 18:38:34 +0000 Subject: [Development] Module "" () : on QtRemoteObjects Message-ID: Hi list, I saw some traffic on QtBase showing the above error staging from Gerrit (which I thought was fixed). I'm seeing the same thing on the Qt Remote Objects module. Is this expected? Is there anything trick other than retry? The specific change is https://codereview.qt-project.org/#/c/213340/ Thanks, Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandru.croitor at qt.io Tue Dec 12 19:41:57 2017 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Tue, 12 Dec 2017 18:41:57 +0000 Subject: [Development] Module "" () : on QtRemoteObjects In-Reply-To: References: Message-ID: <4E9A073A-6785-4068-9862-8F0391EB33E3@qt.io> Hi, Afaik the fix was applied to 5.9 and 5.10 branches, whereas your change targets dev. Restaging will not help at the moment. On Dec 12, 2017, at 19:38, Stottlemyer, Brett (B.S.) > wrote: Hi list, I saw some traffic on QtBase showing the above error staging from Gerrit (which I thought was fixed). I’m seeing the same thing on the Qt Remote Objects module. Is this expected? Is there anything trick other than retry? The specific change is https://codereview.qt-project.org/#/c/213340/ Thanks, Brett _______________________________________________ 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 Liang.Qi at qt.io Wed Dec 13 07:31:14 2017 From: Liang.Qi at qt.io (Liang Qi) Date: Wed, 13 Dec 2017 06:31:14 +0000 Subject: [Development] QtBase broken in 5.9 and 5.10. Fix is already inbound. In-Reply-To: <96CBA118-F04E-4FF3-AB37-283B6304F371@qt.io> References: <96CBA118-F04E-4FF3-AB37-283B6304F371@qt.io> Message-ID: https://codereview.qt-project.org/#/c/214045/ was merged. dev is fixed now. — Liang > On 11 Dec 2017, at 12:22, Liang Qi wrote: > > dev is blocked by "Module "" () Failed to provision template 'qtci-osx-10.11-x86_64-3-9946c2’:” issue, should be fixed by following change: > https://codereview.qt-project.org/#/c/214045/ From tony.sarajarvi at qt.io Wed Dec 13 10:25:46 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Wed, 13 Dec 2017 09:25:46 +0000 Subject: [Development] Builds missing qmake? Message-ID: Hi If you stumble upon a problem in your build where the error message says that it can't find qmake, contact us maintaining the CI immediately. It's not a random failure in such that it goes away by restaging a few times. It means that for some reason (still unclear) we have a pointer indicating where the binaries should be, but they aren't. So they are never even uncompressed. But we can't really fail the build on missing artifacts, since we have no way of knowing if those binaries are optional or not. The error above clearly says that qtbase binaries are now uncompressed, hence the missing qmake, but we don't want to hard code all the really dependent packages for every module. Instead, we're trying to figure out why those binaries are missing in the first place. So, qmake missing error -> contact us. We are needed to fix it currently. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Wed Dec 13 20:39:23 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Wed, 13 Dec 2017 19:39:23 +0000 Subject: [Development] Builds missing qmake? In-Reply-To: References: Message-ID: Hi again. Should have told you this as well. When you see this error message coming from the CI: "Could not access requested repository (: RAN: /usr/bin/git --git-dir=/home/vmbuilder/ci-working-dir/git-repos/qt-project/qt/qtwebview --no-pager fetch --tags origin +refs/builds/qtci/5.9/1513182815:refs/builds/qtci/5.9/1513182815 STDOUT: packet_write_wait: Connection to 54.229.21.112 port 29418: Broken pipe fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. STDERR:" It means that Coin is unable to retrieve needed sources from codereview. Again, as of now we don't know the root cause for this. We can produce this even outside Coin, so it's a problem outside our CI. We are investigating where and why the connections are lost. When this happens you don't have to contact us however. Just restage your commit and the next time around the sources might be retrieved. I apologize for the inconvenience -Tony From: Tony Sarajärvi Sent: keskiviikko 13. joulukuuta 2017 11.26 To: 'development at qt-project.org' Subject: Builds missing qmake? Hi If you stumble upon a problem in your build where the error message says that it can't find qmake, contact us maintaining the CI immediately. It's not a random failure in such that it goes away by restaging a few times. It means that for some reason (still unclear) we have a pointer indicating where the binaries should be, but they aren't. So they are never even uncompressed. But we can't really fail the build on missing artifacts, since we have no way of knowing if those binaries are optional or not. The error above clearly says that qtbase binaries are now uncompressed, hence the missing qmake, but we don't want to hard code all the really dependent packages for every module. Instead, we're trying to figure out why those binaries are missing in the first place. So, qmake missing error -> contact us. We are needed to fix it currently. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Thu Dec 14 05:53:48 2017 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Thu, 14 Dec 2017 04:53:48 +0000 Subject: [Development] Module "" () : on QtRemoteObjects In-Reply-To: <4E9A073A-6785-4068-9862-8F0391EB33E3@qt.io> References: <4E9A073A-6785-4068-9862-8F0391EB33E3@qt.io> Message-ID: Hi, Dev has been fixes as well now: https://testresults.qt.io/coin/integration/qt/qt5/tasks/1513105251 -T From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Alexandru Croitor Sent: tiistai 12. joulukuuta 2017 20.42 To: Stottlemyer, Brett (B.S.) Cc: development at qt-project.org Subject: Re: [Development] Module "" () : on QtRemoteObjects Hi, Afaik the fix was applied to 5.9 and 5.10 branches, whereas your change targets dev. Restaging will not help at the moment. On Dec 12, 2017, at 19:38, Stottlemyer, Brett (B.S.) > wrote: Hi list, I saw some traffic on QtBase showing the above error staging from Gerrit (which I thought was fixed). I’m seeing the same thing on the Qt Remote Objects module. Is this expected? Is there anything trick other than retry? The specific change is https://codereview.qt-project.org/#/c/213340/ Thanks, Brett _______________________________________________ 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 alexander.blasche at qt.io Thu Dec 14 08:46:17 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Thu, 14 Dec 2017 07:46:17 +0000 Subject: [Development] Nominating Ivan Donchevskii for approver In-Reply-To: References: Message-ID: Approver rights have been granted to Ivan. Congratulations. -- Alex ________________________________________ From: Development on behalf of Marco Bubke Sent: Thursday, 23 November 2017 12:52:42 PM To: development at qt-project.org Subject: [Development] Nominating Ivan Donchevskii for approver I'd like to nominate Ivan Donchevskii for Approver. He is working since spring at the C++ support of Qt Creator. Since then his changes made a strong impact to the C++ support. He worked on the Clang integration for Qt Creator, Clang itself, improved the static analyses, polished the Windows experience of the C++ support and integrated Clazy and Clang Tidy. These are his contributions: https://codereview.qt-project.org/#/q/owner:%22Ivan+Donchevskii%22,n,z From tor.arne.vestbo at qt.io Thu Dec 14 12:56:31 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Thu, 14 Dec 2017 12:56:31 +0100 Subject: [Development] Builds missing qmake? In-Reply-To: References: Message-ID: On 13/12/2017 20:39, Tony Sarajärvi wrote: > When this happens you don’t have to contact us however. Just restage > your commit and the next time around the sources might be retrieved. Could the integration both have a list of known CI issues and automatically restage in these cases? tor arne From tor.arne.vestbo at qt.io Thu Dec 14 12:56:31 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Thu, 14 Dec 2017 12:56:31 +0100 Subject: [Development] Builds missing qmake? In-Reply-To: References: Message-ID: On 13/12/2017 20:39, Tony Sarajärvi wrote: > When this happens you don’t have to contact us however. Just restage > your commit and the next time around the sources might be retrieved. Could the integration both have a list of known CI issues and automatically restage in these cases? tor arne From olivier at woboq.com Thu Dec 14 18:47:26 2017 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 14 Dec 2017 18:47:26 +0100 Subject: [Development] QML and Qt Quick versioning of our modules In-Reply-To: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> References: <3407164.bdQOt9hGqW@frederik-thinkcentre-m93p> Message-ID: <2121228.kd5BHI94Ke@maurice> Am Donnerstag, 7. Dezember 2017, 14:53:06 CET schrieb Frederik Gladhorn: > Hi all, > > I've lately been discussing with a few people in The Qt Company about our > versioning. > Historically it was a good idea to not couple Qt Quick too tightly to > general Qt releases. There were quite some constraints and added > flexibility was nice. Qt Quick has matured a lot though, so I think it's > time to consider making everyone's lives easier by cleaning up our version > chaos. > See also J-P's previous mail here: http://lists.qt-project.org/pipermail/ > development/2015-September/023200.html > > Examples are the version section in here: > https://doc.qt.io/qt-5/qtquickcontrols2-index.html > And a general confusion around which version does what. > Since we so far don't keep copies of old functions around (as far as I'm > aware at least), I don't think there's a huge value in the versioning > system in the first place. > It only gives one important guarantee: if you added a property/type/name and > import a defined version, you don't suddenly get conflicts because we > introduced the same name. > > Some modules started to copy the Qt version, e.g. Multimedia, that's pretty > easy to remember and a good start in my opinion. > > I have several ideas and I'm unsure how hard they would be to implement, so > I'll list things from easy to hard. > > 1) sync minor versions to Qt release version: > For Qt 5.11, we would provide QtQuick.Controls 2.11 > This way, the challenge for the user is only to find out if it's version 1, > 2 or 5. > > 2) Make the minor version import optional and we pick the lastest. This > should be optional to prevent the name clashes described above and shifts > the risk to the user. > In practice I'd expect this to be pretty safe. > import QtQuick.Controls 2 would then give the latest version available. > > 3) Make even the major version optional and we'd pick up the latest version. > import QtQuick.Controls would give version 2.11 with Qt 5.11. > > I don't see us releasing most of the QML/Qt Quick modules independent of the > rest of Qt any time soon, so I hope this will make things easier for > everyone. I'm sure there are even better ideas out there, this is just my > version and current thinking, I hope for constructive suggestions :) > > In the end I want this to be easier for Qt users and also to lessen our > maintenance burden and the need to look up versions, explain the scheme and > reduce the confusion. > > Luckily we now have qmlRegisterModule(QT_VERSION_MAJOR, QT_VERSION_MINOR) to > help registering the current versions already. Thanks for bringing the discussion up. In my opinion, this import is not so useful and I would vote for making it optional I also think that Q_REVISION is defective by design and we should not try t support this. I know that it is supposed to make sure that new property/function names don't clash with application name. But do we have any data that this indeed was usefull? Is there any project that upgraded Qt and had his qml still working because there would be a conflict. The QML engine should throw a warning when this happen (that the lookup would be different with a newer version), and we could see in the real world if this happen. -- Olivier From tuukka.turunen at qt.io Fri Dec 15 20:04:33 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 15 Dec 2017 19:04:33 +0000 Subject: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards Message-ID: Hi, I propose to remove support for QNX 6.6 from Qt 5.11 onwards. Since Qt 5.9.0 we have supported both QNX 6.6 and 7.0, but going forward we would support only QNX 7.0 with new Qt versions. QNX 6.6 continues to be supported with Qt 5.9 LTS and Qt 5.10. Based on my experience QNX 7.0 is a better choice for new projects than QNX 6.6. It has, for example, better C++11 support, 64 bit support and improved graphics support. I have discussed the topic with James McDonnell (QNX platform maintainer) as well as QNX product management and they agree that it is better to focus into improving QNX 7.0 support with upcoming Qt releases rather that splitting the effort between QNX 6.6 and 7.0. Yours, Tuukka -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Fri Dec 15 20:20:43 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 15 Dec 2017 22:20:43 +0300 Subject: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards In-Reply-To: References: Message-ID: <1905221513365643@web56g.yandex.ru> 15.12.2017, 22:04, "Tuukka Turunen" : > Hi, > > I propose to remove support for QNX 6.6 from Qt 5.11 onwards. > > Since Qt 5.9.0 we have supported both QNX 6.6 and 7.0, but going forward we would support only QNX 7.0 with new Qt versions. QNX 6.6 continues to be supported with Qt 5.9 LTS and Qt 5.10. > > Based on my experience QNX 7.0 is a better choice for new projects than QNX 6.6. It has, for example, better C++11 support, 64 bit support and improved graphics support. > > I have discussed the topic with James McDonnell (QNX platform maintainer) as well as QNX product management and they agree that it is better to focus into improving QNX 7.0 support with upcoming Qt releases rather that splitting the effort between QNX 6.6 and 7.0. If we also remove MSVC 2013, only compilers with complete C++11 support on both core language and library side will remain in CI. > > Yours, > >                   Tuukka > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From tuukka.turunen at qt.io Fri Dec 15 21:06:37 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 15 Dec 2017 20:06:37 +0000 Subject: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards In-Reply-To: <1905221513365643@web56g.yandex.ru> References: , <1905221513365643@web56g.yandex.ru> Message-ID: True. But let's discuss separately QNX 6.6 and MSVC 2013. My proposal was about QNX 6.6 specifically. Let's make sure that gets discussed even though MSVC 2013 might be a mere interesting topic for many :) We have discussed about MSVC 2013 earlier and then some more time was desired before deciding. Perhaps enough time has passed now to open the discussion again. I do agree that complete C++11 support in all compilers is a tempting idea. Yours, Tuukka ________________________________ Lähettäjä: Konstantin Tokarev Lähetetty: 15. joulukuuta 2017 21:20 Vastaanottaja: Tuukka Turunen; development at qt-project.org; James McDonnell Aihe: Re: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards 15.12.2017, 22:04, "Tuukka Turunen" : > Hi, > > I propose to remove support for QNX 6.6 from Qt 5.11 onwards. > > Since Qt 5.9.0 we have supported both QNX 6.6 and 7.0, but going forward we would support only QNX 7.0 with new Qt versions. QNX 6.6 continues to be supported with Qt 5.9 LTS and Qt 5.10. > > Based on my experience QNX 7.0 is a better choice for new projects than QNX 6.6. It has, for example, better C++11 support, 64 bit support and improved graphics support. > > I have discussed the topic with James McDonnell (QNX platform maintainer) as well as QNX product management and they agree that it is better to focus into improving QNX 7.0 support with upcoming Qt releases rather that splitting the effort between QNX 6.6 and 7.0. If we also remove MSVC 2013, only compilers with complete C++11 support on both core language and library side will remain in CI. > > Yours, > > Tuukka > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmcdonnell at blackberry.com Fri Dec 15 21:17:04 2017 From: jmcdonnell at blackberry.com (James McDonnell) Date: Fri, 15 Dec 2017 20:17:04 +0000 Subject: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards In-Reply-To: References: , <1905221513365643@web56g.yandex.ru>, Message-ID: +2 to removing support for QNX 6.6.0 Sent from my BlackBerry - the most secure mobile device - via the Rogers Network From: tuukka.turunen at qt.io Sent: December 15, 2017 3:06 PM To: annulen at yandex.ru; development at qt-project.org; jmcdonnell at blackberry.com Subject: VS: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards True. But let's discuss separately QNX 6.6 and MSVC 2013. My proposal was about QNX 6.6 specifically. Let's make sure that gets discussed even though MSVC 2013 might be a mere interesting topic for many :) We have discussed about MSVC 2013 earlier and then some more time was desired before deciding. Perhaps enough time has passed now to open the discussion again. I do agree that complete C++11 support in all compilers is a tempting idea. Yours, Tuukka ________________________________ Lähettäjä: Konstantin Tokarev Lähetetty: 15. joulukuuta 2017 21:20 Vastaanottaja: Tuukka Turunen; development at qt-project.org; James McDonnell Aihe: Re: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards 15.12.2017, 22:04, "Tuukka Turunen" : > Hi, > > I propose to remove support for QNX 6.6 from Qt 5.11 onwards. > > Since Qt 5.9.0 we have supported both QNX 6.6 and 7.0, but going forward we would support only QNX 7.0 with new Qt versions. QNX 6.6 continues to be supported with Qt 5.9 LTS and Qt 5.10. > > Based on my experience QNX 7.0 is a better choice for new projects than QNX 6.6. It has, for example, better C++11 support, 64 bit support and improved graphics support. > > I have discussed the topic with James McDonnell (QNX platform maintainer) as well as QNX product management and they agree that it is better to focus into improving QNX 7.0 support with upcoming Qt releases rather that splitting the effort between QNX 6.6 and 7.0. If we also remove MSVC 2013, only compilers with complete C++11 support on both core language and library side will remain in CI. > > Yours, > > Tuukka > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Sat Dec 16 10:26:39 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Sat, 16 Dec 2017 09:26:39 +0000 Subject: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards In-Reply-To: References: <1905221513365643@web56g.yandex.ru> Message-ID: <7DAE1773-1628-49C3-A96A-F4406FC06350@qt.io> +1 from my side as well. Cheers, Lars On 15 Dec 2017, at 21:17, James McDonnell > wrote: +2 to removing support for QNX 6.6.0 Sent from my BlackBerry - the most secure mobile device - via the Rogers Network From: tuukka.turunen at qt.io Sent: December 15, 2017 3:06 PM To: annulen at yandex.ru; development at qt-project.org; jmcdonnell at blackberry.com Subject: VS: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards True. But let's discuss separately QNX 6.6 and MSVC 2013. My proposal was about QNX 6.6 specifically. Let's make sure that gets discussed even though MSVC 2013 might be a mere interesting topic for many :) We have discussed about MSVC 2013 earlier and then some more time was desired before deciding. Perhaps enough time has passed now to open the discussion again. I do agree that complete C++11 support in all compilers is a tempting idea. Yours, Tuukka ________________________________ Lähettäjä: Konstantin Tokarev > Lähetetty: 15. joulukuuta 2017 21:20 Vastaanottaja: Tuukka Turunen; development at qt-project.org; James McDonnell Aihe: Re: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards 15.12.2017, 22:04, "Tuukka Turunen" >: > Hi, > > I propose to remove support for QNX 6.6 from Qt 5.11 onwards. > > Since Qt 5.9.0 we have supported both QNX 6.6 and 7.0, but going forward we would support only QNX 7.0 with new Qt versions. QNX 6.6 continues to be supported with Qt 5.9 LTS and Qt 5.10. > > Based on my experience QNX 7.0 is a better choice for new projects than QNX 6.6. It has, for example, better C++11 support, 64 bit support and improved graphics support. > > I have discussed the topic with James McDonnell (QNX platform maintainer) as well as QNX product management and they agree that it is better to focus into improving QNX 7.0 support with upcoming Qt releases rather that splitting the effort between QNX 6.6 and 7.0. If we also remove MSVC 2013, only compilers with complete C++11 support on both core language and library side will remain in CI. > > Yours, > > Tuukka > , > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Sat Dec 16 10:30:01 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Sat, 16 Dec 2017 09:30:01 +0000 Subject: [Development] MSVC 2013 (was: Proposal to remove QNX 6.6 support from Qt 5.11 onwards) In-Reply-To: References: <1905221513365643@web56g.yandex.ru> Message-ID: <6BDD2840-76DB-4767-8A2A-57AC8087CA09@qt.io> With regards to MSVC 2013. The previous conclusion was to have a look at the download/usage data from Qt 5.10 and then evaluate/decide. Tuukka, do we have some data now, that we can use as a basis for that decision? Thanks, Lars On 15 Dec 2017, at 21:06, Tuukka Turunen > wrote: True. But let's discuss separately QNX 6.6 and MSVC 2013. My proposal was about QNX 6.6 specifically. Let's make sure that gets discussed even though MSVC 2013 might be a mere interesting topic for many :) We have discussed about MSVC 2013 earlier and then some more time was desired before deciding. Perhaps enough time has passed now to open the discussion again. I do agree that complete C++11 support in all compilers is a tempting idea. Yours, Tuukka ________________________________ Lähettäjä: Konstantin Tokarev > Lähetetty: 15. joulukuuta 2017 21:20 Vastaanottaja: Tuukka Turunen; development at qt-project.org; James McDonnell Aihe: Re: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards 15.12.2017, 22:04, "Tuukka Turunen" >: > Hi, > > I propose to remove support for QNX 6.6 from Qt 5.11 onwards. > > Since Qt 5.9.0 we have supported both QNX 6.6 and 7.0, but going forward we would support only QNX 7.0 with new Qt versions. QNX 6.6 continues to be supported with Qt 5.9 LTS and Qt 5.10. > > Based on my experience QNX 7.0 is a better choice for new projects than QNX 6.6. It has, for example, better C++11 support, 64 bit support and improved graphics support. > > I have discussed the topic with James McDonnell (QNX platform maintainer) as well as QNX product management and they agree that it is better to focus into improving QNX 7.0 support with upcoming Qt releases rather that splitting the effort between QNX 6.6 and 7.0. If we also remove MSVC 2013, only compilers with complete C++11 support on both core language and library side will remain in CI. > > Yours, > > Tuukka > , > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sat Dec 16 04:10:05 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 15 Dec 2017 19:10:05 -0800 Subject: [Development] Dropping of MSVC 2013 In-Reply-To: References: <2827905.1UXfmysL1p@tjmaciei-mobl1> <0903A9A1-04B8-4D24-93A8-907FC548526B@qt.io> Message-ID: <5315663.VmxJgI0e72@tjmaciei-mobl1> On Wednesday, 8 November 2017 10:57:32 PST Alex Blasche wrote: > Sorry, no. As mentioned during the contributor summit, this decision is > tabled until we have the 5.10 download figures. Any numbers now? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jedrzej.nowacki at qt.io Mon Dec 18 11:24:18 2017 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 18 Dec 2017 11:24:18 +0100 Subject: [Development] atomic commits across submodules (was: Suggestion to add labels when changing API) In-Reply-To: <0ccbf0d6-6c09-c288-8305-2258d98f0cf4@qt.io> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <0ccbf0d6-6c09-c288-8305-2258d98f0cf4@qt.io> Message-ID: <1520388.uf7oSa6Aqz@snoll> On czwartek, 7 grudnia 2017 12:17:16 CET Adam Treat wrote: > Hi, > > I think it is high time that we fix the underlying problem: supporting > atomic commits across submodules. As I'm not against the idea, I'm not really fan of it either. The problem with atomic commits across submodules is that they encourage API breakages. Without supporting both code paths even for a little while, one is not aware of the pain that our users needs to go through every time we break API. Even private API modifications have side effects. If you are working in qtbase then it is easy, but otherwise you are forced to recompile quite often or risk debugging subtle binary incompatibilities. It is not as crazy as during qt5.0 but still happens. In addition we were thinking about splitting submodules even more. Reduce amount of private API usage or even make them use only public API (quite nice but a controversial dream, please do not start discussion about that now :-) ). Make them more independent libraries, which would have many positive aspects. If you keep all these in mind, cross sumodule modifications are not encouraged and our process was never optimized for the case. Just to be very clear if you want to simplify changing many submodules at once, then you would get my full support, but keep in mind that it should not be disruptive nor for other Qt developers nor for Qt users. > Once this is done we should revert our CI to test changes against latest > version of all modules. No. First, how these two are connected, that is a big jump to a solution, without providing reasoning. I know that you didn't know about the fact that we pin submodules in qt5 and you got burned by this. That __is__ an argument, but an alternative solution would be a better documentation or UI. Second, the most important, that doesn't scale. By compiling against latest Qt5 we reduced CI load by ~80%. > * Adopt something like Google's repo tool: > https://code.google.com/archive/p/git-repo/ > * Stop using submodules and use a monolithic repo > * Git subtree > * Implement atomic commit across submodules not in Git, but in the > gerrit/COIN layer so that COIN effectively locks integrations until > commits that span submodules are finished > * Something else? I think there is nothing in our infrastructure that would block us from implementing atomic cross submodules commits. It is matter of Coin calling few more functions. Cheers, Jędrek From tuukka.turunen at qt.io Mon Dec 18 12:09:33 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Mon, 18 Dec 2017 11:09:33 +0000 Subject: [Development] Dropping of MSVC 2013 In-Reply-To: <5315663.VmxJgI0e72@tjmaciei-mobl1> References: <2827905.1UXfmysL1p@tjmaciei-mobl1> <0903A9A1-04B8-4D24-93A8-907FC548526B@qt.io> <5315663.VmxJgI0e72@tjmaciei-mobl1> Message-ID: Hi, Akseli will check the percentages from Qt 5.10 online installer later this week. Yours, Tuukka On 16/12/2017, 18.25, "Development on behalf of Thiago Macieira" wrote: On Wednesday, 8 November 2017 10:57:32 PST Alex Blasche wrote: > Sorry, no. As mentioned during the contributor summit, this decision is > tabled until we have the 5.10 download figures. Any numbers now? -- 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 adam.treat at qt.io Mon Dec 18 15:22:31 2017 From: adam.treat at qt.io (Adam Treat) Date: Mon, 18 Dec 2017 09:22:31 -0500 Subject: [Development] atomic commits across submodules In-Reply-To: <1520388.uf7oSa6Aqz@snoll> References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <0ccbf0d6-6c09-c288-8305-2258d98f0cf4@qt.io> <1520388.uf7oSa6Aqz@snoll> Message-ID: On 12/18/2017 05:24 AM, Jędrzej Nowacki wrote: > On czwartek, 7 grudnia 2017 12:17:16 CET Adam Treat wrote: >> Hi, >> >> I think it is high time that we fix the underlying problem: supporting >> atomic commits across submodules. > As I'm not against the idea, I'm not really fan of it either. The problem with > atomic commits across submodules is that they encourage API breakages. Without > supporting both code paths even for a little while, one is not aware of the > pain that our users needs to go through every time we break API. So your position is we shouldn't need atomic commits across submodules because the changes that are leading to breakage are themselves the problem. Let's examine types of changes: 1) Build system changes that require cross-module modifications 2) New public API in base module where dependent module takes advantage of it 3) Private API being changed out from under 4) Merges of the above 3 types from release branches to dev Of these, only #2 should be solvable without atomic commits. In that case, we can introduce API first and when it is integrated, only then update dependent modules. This is still a problem for #4 though, but more about that later. For the other types, atomic commits are at least sometimes going to be required. Right now, we are experiencing breakage. And it *is* painful. But I have not seen a postmortem of said breakages that shows the current processes are up to preventing such breakage. Maybe the answer is to move away from private API and a build system that does not need to be bootstrapped from Qt... Now, back to #4, I do know that those responsible for merging from release branches into dev face a mind field of cross-module modifications. Consider #2 again and say such a change across modules has made it into release branches. It is my understanding that it is *just such a set of changes* that led to Liang Qi's request to add labels to API changes because the ordering info gets lost.  Merges from release to dev are going to be problematic until we have some way of ensuring cross-module dependencies are handled. Which is why I propose that we stop merging from release to dev and require all changes to hit dev first. But, more on that in another email thread later. Maybe after the holidays ;) >> Once this is done we should revert our CI to test changes against latest >> version of all modules. > No. First, how these two are connected, that is a big jump to a solution, > without providing reasoning. I know that you didn't know about the fact that > we pin submodules in qt5 and you got burned by this. That __is__ an argument, > but an alternative solution would be a better documentation or UI. Second, > the most important, that doesn't scale. By compiling against latest Qt5 we > reduced CI load by ~80%. Fair enough, let's table this. I have more to say about this, but it really is related to my suggestion above. Again, more about that later. From tpham3783 at gmail.com Mon Dec 18 16:46:24 2017 From: tpham3783 at gmail.com (Toan Pham) Date: Mon, 18 Dec 2017 10:46:24 -0500 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine Message-ID: Hi, I am having multiple problems w/ building qt5.10 w/ webengine support for linux 32bit. Before I proceed further down that road, I would like to know if there's a pre-built version of qt5.10.0 w/ webengine for linux 32bit somewhere? thank you and have a good day, TP -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Dec 18 17:39:39 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 18 Dec 2017 08:39:39 -0800 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: Message-ID: <1624810.gLDOA3jiHc@tjmaciei-mobl1> On Monday, 18 December 2017 07:46:24 PST Toan Pham wrote: > Hi, > > I am having multiple problems w/ building qt5.10 w/ webengine support for > linux 32bit. Before I proceed further down that road, I would like to know > if there's a pre-built version of qt5.10.0 w/ webengine for linux 32bit > somewhere? There isn't. Linux 32-bit is uncommon enough these days that it's not worth spending CPU time building for it. Please report your build issues. I did check a few days ago that qtwebengine does not explicitly block 32-bit builds, so it should have worked. Please make sure you have a 64-bit linker. Also make sure you have gold available, it's possible that the regular BFD blows up due to memory use. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tpham3783 at gmail.com Mon Dec 18 18:53:55 2017 From: tpham3783 at gmail.com (Toan Pham) Date: Mon, 18 Dec 2017 12:53:55 -0500 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: <1624810.gLDOA3jiHc@tjmaciei-mobl1> References: <1624810.gLDOA3jiHc@tjmaciei-mobl1> Message-ID: Thiago, I am running two parallel builds at the moment, and they are: 1. 32 bit LXC container (ubuntu 16.04 32bit) The build is still compiling chronium web-engine for the last an hr and a half. So far, I haven't had much problem w/ this one except that I had to comment out a few lines in qtwebengine/qtwebengine.pro to get the build started. 2. 32bit inside T2SDE sandbox (ref. http://t2sde.org) This build stopped here: make[4]: Entering directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools' make[4]: Nothing to be done for `first'. make[4]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools' ( test -e Makefile.configure_target || /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/bin/qmake -o Makefile.configure_target /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools/ configure_target.pro ) && make -f Makefile.configure_target make[4]: Entering directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools' make[4]: Nothing to be done for `first'. make[4]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools' ( test -e Makefile.gn || /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/bin/qmake -o Makefile.gn /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools/ gn.pro ) && make -f Makefile.gn Building gn manually in a temporary directory for bootstrapping... Traceback (most recent call last): File "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 855, in sys.exit(main(sys.argv[1:])) File "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 127, in main return run_build(build_dir, options) File "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 74, in run_build build_gn_with_ninja_manually(tempdir, options) File "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 220, in build_gn_with_ninja_manually check_call(cmd) File "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 45, in check_call subprocess.check_call(cmd, cwd=GN_ROOT, **kwargs) File "/usr/lib/python2.7/subprocess.py", line 535, in check_call retcode = call(*popenargs, **kwargs) File "/usr/lib/python2.7/subprocess.py", line 522, in call return Popen(*popenargs, **kwargs).wait() File "/usr/lib/python2.7/subprocess.py", line 709, in __init__ errread, errwrite) File "/usr/lib/python2.7/subprocess.py", line 1326, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory Project ERROR: GN build error! make[3]: *** [sub-gn-pro-make_first] Error 3 make[3]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools' make[2]: *** [sub-buildtools-make_first] Error 2 make[2]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src' make[1]: *** [sub-src-make_first] Error 2 make[1]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine' Please let me know if you know what went wrong w/ the second build. thanks, TP On Mon, Dec 18, 2017 at 11:39 AM, Thiago Macieira wrote: > On Monday, 18 December 2017 07:46:24 PST Toan Pham wrote: > > Hi, > > > > I am having multiple problems w/ building qt5.10 w/ webengine support for > > linux 32bit. Before I proceed further down that road, I would like to > know > > if there's a pre-built version of qt5.10.0 w/ webengine for linux 32bit > > somewhere? > > There isn't. Linux 32-bit is uncommon enough these days that it's not worth > spending CPU time building for it. > > Please report your build issues. I did check a few days ago that > qtwebengine > does not explicitly block 32-bit builds, so it should have worked. > > Please make sure you have a 64-bit linker. Also make sure you have gold > available, it's possible that the regular BFD blows up due to memory use. > > -- > 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 Mon Dec 18 19:08:28 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 18 Dec 2017 10:08:28 -0800 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <1624810.gLDOA3jiHc@tjmaciei-mobl1> Message-ID: <1762287.o5G8KsK4rf@tjmaciei-mobl1> On Monday, 18 December 2017 09:53:55 PST Toan Pham wrote: > 1. 32 bit LXC container (ubuntu 16.04 32bit) > The build is still compiling chronium web-engine for the last an hr > and a half. So far, I haven't had much problem w/ this one except that I > had to comment out a few lines in qtwebengine/qtwebengine.pro to get the > build started. Can you share what those were? > 2. 32bit inside T2SDE sandbox (ref. http://t2sde.org) > > This build stopped here: > > "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine > /src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 220, in > build_gn_with_ninja_manually > check_call(cmd) > File > "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine > /src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 45, in > check_call > subprocess.check_call(cmd, cwd=GN_ROOT, **kwargs) > File "/usr/lib/python2.7/subprocess.py", line 535, in check_call > retcode = call(*popenargs, **kwargs) > File "/usr/lib/python2.7/subprocess.py", line 522, in call > return Popen(*popenargs, **kwargs).wait() > File "/usr/lib/python2.7/subprocess.py", line 709, in __init__ > errread, errwrite) > File "/usr/lib/python2.7/subprocess.py", line 1326, in _execute_child > raise child_exception > OSError: [Errno 2] No such file or directory > Project ERROR: GN build error! > Please let me know if you know what went wrong w/ the second build. Some file is missing or failed to be build. Sorry, I don't have the chromium sources in my checkout so I can't tell what it's looking for. Given that you have one build working and one not, it's very likely this sandbox is missing some required tool. Look into that bootstrap.py file to find out what it tried to run. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From michal.klocek at qt.io Mon Dec 18 21:01:56 2017 From: michal.klocek at qt.io (Michal Klocek) Date: Mon, 18 Dec 2017 21:01:56 +0100 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <1624810.gLDOA3jiHc@tjmaciei-mobl1> Message-ID: Hi It looks like the build can not proceed because of lack of working ninja. Qt configure detects system ninja, and in case it does not work builds internal one. In case for some reason this failed you can still force the build to use internal ninja with configure option: -no-feature-webengine-system-ninja Br Michal On 12/18/2017 06:53 PM, Toan Pham wrote: > Thiago, > > > I am running two parallel builds at the moment, and they are: > > > 1. 32 bit LXC container (ubuntu 16.04 32bit) > The build is still compiling chronium web-engine for the last an hr > and a half. So far, I haven't had much problem w/ this one except that > I had to comment out a few lines in qtwebengine/qtwebengine.pro > to get the build started. > > > > 2. 32bit inside T2SDE sandbox (ref. http://t2sde.org) > > This build stopped here: > > make[4]: Entering directory > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools' > make[4]: Nothing to be done for `first'. > make[4]: Leaving directory > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools' > ( test -e Makefile.configure_target || > /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/bin/qmake > -o Makefile.configure_target > /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools/configure_target.pro > ) && make -f Makefile.configure_target > make[4]: Entering directory > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools' > make[4]: Nothing to be done for `first'. > make[4]: Leaving directory > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools' > ( test -e Makefile.gn || > /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtbase/bin/qmake > -o Makefile.gn > /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools/gn.pro > ) && make -f Makefile.gn > Building gn manually in a temporary directory for bootstrapping... > Traceback (most recent call last): > File > "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", > line 855, in > sys.exit(main(sys.argv[1:])) > File > "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", > line 127, in main > return run_build(build_dir, options) > File > "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", > line 74, in run_build > build_gn_with_ninja_manually(tempdir, options) > File > "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", > line 220, in build_gn_with_ninja_manually > check_call(cmd) > File > "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", > line 45, in check_call > subprocess.check_call(cmd, cwd=GN_ROOT, **kwargs) > File "/usr/lib/python2.7/subprocess.py", line 535, in check_call > retcode = call(*popenargs, **kwargs) > File "/usr/lib/python2.7/subprocess.py", line 522, in call > return Popen(*popenargs, **kwargs).wait() > File "/usr/lib/python2.7/subprocess.py", line 709, in __init__ > errread, errwrite) > File "/usr/lib/python2.7/subprocess.py", line 1326, in _execute_child > raise child_exception > OSError: [Errno 2] No such file or directory > Project ERROR: GN build error! > make[3]: *** [sub-gn-pro-make_first] Error 3 > make[3]: Leaving directory > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/buildtools' > make[2]: *** [sub-buildtools-make_first] Error 2 > make[2]: Leaving directory > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src' > make[1]: *** [sub-src-make_first] Error 2 > make[1]: Leaving directory > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine' > > > > Please let me know if you know what went wrong w/ the second build. > > > thanks, > > TP > > > On Mon, Dec 18, 2017 at 11:39 AM, Thiago Macieira > > wrote: > > On Monday, 18 December 2017 07:46:24 PST Toan Pham wrote: > > Hi, > > > > I am having multiple problems w/ building qt5.10 w/ webengine support for > > linux 32bit. Before I proceed further down that road, I would like to know > > if there's a pre-built version of qt5.10.0 w/ webengine for linux 32bit > > somewhere? > > There isn't. Linux 32-bit is uncommon enough these days that it's > not worth > spending CPU time building for it. > > Please report your build issues. I did check a few days ago that > qtwebengine > does not explicitly block 32-bit builds, so it should have worked. > > Please make sure you have a 64-bit linker. Also make sure you have gold > available, it's possible that the regular BFD blows up due to memory > use. > > -- > 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 oswald.buddenhagen at qt.io Mon Dec 18 22:25:46 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 18 Dec 2017 22:25:46 +0100 Subject: [Development] atomic commits across submodules In-Reply-To: References: <924372A7-862D-478B-9B26-BC2DE7047B9C@qt.io> <0ccbf0d6-6c09-c288-8305-2258d98f0cf4@qt.io> <1520388.uf7oSa6Aqz@snoll> Message-ID: <20171218212546.GC14693@troll08> On Mon, Dec 18, 2017 at 09:22:31AM -0500, Adam Treat wrote: > 3) Private API being changed out from under > 3a) yet unreleased public api being revised. there is just no reasonable way to claim that the pain inflicted by the 5-stage workaround is a good thing. it's a barely acceptable thing given the constraint of atomic commits being unrealistic for the time being. From kde at carewolf.com Mon Dec 18 20:14:58 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 18 Dec 2017 20:14:58 +0100 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <1624810.gLDOA3jiHc@tjmaciei-mobl1> Message-ID: <3308126.piR9Nt2yrh@twilight> On Montag, 18. Dezember 2017 18:53:55 CET Toan Pham wrote: > "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine > /src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 45, in > check_call > subprocess.check_call(cmd, cwd=GN_ROOT, **kwargs) > File "/usr/lib/python2.7/subprocess.py", line 535, in check_call > retcode = call(*popenargs, **kwargs) > File "/usr/lib/python2.7/subprocess.py", line 522, in call > return Popen(*popenargs, **kwargs).wait() > File "/usr/lib/python2.7/subprocess.py", line 709, in __init__ > errread, errwrite) > File "/usr/lib/python2.7/subprocess.py", line 1326, in _execute_child > raise child_exception > OSError: [Errno 2] No such file or directory > Project ERROR: GN build error! > make[3]: *** [sub-gn-pro-make_first] Error 3 > make[3]: Leaving directory > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine > /src/buildtools' make[2]: *** [sub-buildtools-make_first] Error 2 > make[2]: Leaving directory > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine > /src' make[1]: *** [sub-src-make_first] Error 2 > make[1]: Leaving directory > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine > ' > > > > Please let me know if you know what went wrong w/ the second build. > > Looks like it expects ninja to be installed, but cant launch it. Check your configure output and see if it detected system ninja and you have ninja installed. 'Allan From sergio.martins at kdab.com Tue Dec 19 12:25:17 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Tue, 19 Dec 2017 11:25:17 +0000 Subject: [Development] Time to switch to android-clang Message-ID: <14d4cb98ca86e58afc68d6c8d3d8939b@kdab.com> Hi all, We need to start offering pre-built android binaries built with android-clang and bump our minimum supported NDK version. gcc on android is pretty much dead since 2016: "GCC is no longer supported. It will be removed in NDK r18. libc++ is now the default STL for CMake and standalone toolchains. If you manually selected a different STL, we strongly encourage you to move to libc++ gnustl and stlport are deprecated and will be removed in NDK r18. [1] " And the latest shipped gcc (4.9.2) is crashy [2], forcing gcc users to stay on ndk r10. The problem of clang generating bigger binaries was much improved with -Oz, now size increase is only 10%. Many users are already switching to android-clang due to the shipped gnu libstdc++ having incomplete C++11 and then complaining the pre-built binaries not being able to compile for clang+libc++. Furthermore, supporting both android and android-clang is a maintenance burden: the mkspecs are often broken, either because of a new Qt version or because of a new NDK version. Then you have to test not only gcc and clang, but also test builds with the older NDKs. So we should also bump the NDK. [1] - https://developer.android.com/ndk/downloads/revision_history.html [2] - http://lists.qt-project.org/pipermail/development/2015-March/020632.html 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, C++ and OpenGL Experts From thiago.macieira at intel.com Tue Dec 19 17:18:46 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Dec 2017 08:18:46 -0800 Subject: [Development] Time to switch to android-clang In-Reply-To: <14d4cb98ca86e58afc68d6c8d3d8939b@kdab.com> References: <14d4cb98ca86e58afc68d6c8d3d8939b@kdab.com> Message-ID: <2970546.jHGumfAVZe@tjmaciei-mobl1> On terça-feira, 19 de dezembro de 2017 03:25:17 PST Sergio Martins wrote: > Furthermore, supporting both android and android-clang is a maintenance > burden: the mkspecs are often broken, either because of a new Qt version > or because of a new NDK version. Then you have to test not only gcc and > clang, but also test builds with the older NDKs. > So we should also bump the NDK. I'm not familiar with Android development and the difficulty in maintaining android-clang. But seeing as we're already doing that anyway, it should be less work to change to Clang. I'm all for upgraing compilers, so a +0.5 for me. However, please answer this: what kind of compatibility do we need and for how long do we need to provide it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tpham3783 at gmail.com Tue Dec 19 18:16:47 2017 From: tpham3783 at gmail.com (Toan Pham) Date: Tue, 19 Dec 2017 12:16:47 -0500 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: <3308126.piR9Nt2yrh@twilight> References: <1624810.gLDOA3jiHc@tjmaciei-mobl1> <3308126.piR9Nt2yrh@twilight> Message-ID: Here is brief update on my 32bit build: 1. 32bit build inside lxc container - code built successfully, qtwebengine worked perfectly. The only problem w/ this one is that it does not use compatible glibc library as my target board. 2. 32bit build inside t2 sandbox - I got the builder to use internal ninja tool. However, I now faced w/ the error below: BTW, t2 sandbox is a chroot build environment for building native and also cross root filesystem. One major advantage of using it because it completely isolates my development machine from the build environment after the initial toolchain stage. I am just wondering if that was the reason why ninja failed, as seen in the getcwd error! /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/ninja/ninja -C /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release QtWebEngineCore ninja: Entering directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release' [1/21229] STAMP obj/third_party/webrtc/modules/audio_coding/isac_fix_common.stamp shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device [2/21229] STAMP obj/device/sensors/public/interfaces/interfaces__type_mappings.inputdeps.stamp shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device [3/21229] STAMP obj/media/midi/mojo_blink__type_mappings.inputdeps.stamp shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device [4/21229] ACTION //extensions/features:features(/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/toolchain:target) shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device [5/21229] STAMP obj/extensions/features/features.stamp shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device [6/21229] COPY ../../3rdparty/chromium/third_party/WebKit/Source/devtools/front_end/Images/accelerometer-bottom.png resources/inspector/Images/accelerometer-bottom.png FAILED: resources/inspector/Images/accelerometer-bottom.png ln -f ../../3rdparty/chromium/third_party/WebKit/Source/devtools/front_end/Images/accelerometer-bottom.png resources/inspector/Images/accelerometer-bottom.png 2>/dev/null || (rm -rf resources/inspector/Images/accelerometer-bottom.png && cp -af ../../3rdparty/chromium/third_party/WebKit/Source/devtools/front_end/Images/accelerometer-bottom.png resources/inspector/Images/accelerometer-bottom.png) shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device cp: cannot create regular file `/TOOLCHAIN/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/resources/inspector/Images/accelerometer-bottom.png': No such file or directory [7/21229] COPY ../../3rdparty/chromium/third_party/WebKit/Source/devtools/front_end/emulated_devices/goog...5x-vertical-keyboard-1x.png resources/inspector/emulated_devices/google-nexus-5x-vertical-keyboard-1x.pn FAILED: resources/inspector/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png ln -f ../../3rdparty/chromium/third_party/WebKit/Source/devtools/front_end/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png resources/inspector/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png 2>/dev/null || (rm -rf resources/inspector/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png && cp -af ../../3rdparty/chromium/third_party/WebKit/Source/devtools/front_end/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png resources/inspector/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png) shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device cp: cannot create regular file `/TOOLCHAIN/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/resources/inspector/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png': No such file or directory [8/21229] ACTION //media/midi:mojo_blink__type_mappings(/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/toolchain:target) shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device [9/21229] CXX obj/mojo/public/c/system/system/thunks.o shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device [10/21229] CXX obj/crypto/crypto/random.o shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device [11/21229] CXX obj/crypto/crypto/p224.o shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device [12/21229] CXX obj/crypto/crypto/p224_spake.o shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device [13/21229] CXX obj/media/shared_memory_support/audio_point.o shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device [14/21229] CXX obj/crypto/crypto/symmetric_key.o shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device [15/21229] CXX obj/crypto/crypto/sha2.o shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device shell-init: error retrieving current directory: getcwd: cannot access parent directories: Inappropriate ioctl for device ninja: build stopped: subcommand failed. make[4]: *** [run_ninja] Error 1 make[4]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core' make[3]: *** [sub-gn_run-pro-make_first] Error 2 make[3]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core' make[2]: *** [sub-core-make_first] Error 2 make[2]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src' make[1]: *** [sub-src-make_first] Error 2 make[1]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine' On Mon, Dec 18, 2017 at 2:14 PM, Allan Sandfeld Jensen wrote: > On Montag, 18. Dezember 2017 18:53:55 CET Toan Pham wrote: > > "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere- > src-5.10.0/qtwebengine > > /src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 45, in > > check_call > > subprocess.check_call(cmd, cwd=GN_ROOT, **kwargs) > > File "/usr/lib/python2.7/subprocess.py", line 535, in check_call > > retcode = call(*popenargs, **kwargs) > > File "/usr/lib/python2.7/subprocess.py", line 522, in call > > return Popen(*popenargs, **kwargs).wait() > > File "/usr/lib/python2.7/subprocess.py", line 709, in __init__ > > errread, errwrite) > > File "/usr/lib/python2.7/subprocess.py", line 1326, in _execute_child > > raise child_exception > > OSError: [Errno 2] No such file or directory > > Project ERROR: GN build error! > > make[3]: *** [sub-gn-pro-make_first] Error 3 > > make[3]: Leaving directory > > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere- > src-5.10.0/qtwebengine > > /src/buildtools' make[2]: *** [sub-buildtools-make_first] Error 2 > > make[2]: Leaving directory > > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere- > src-5.10.0/qtwebengine > > /src' make[1]: *** [sub-src-make_first] Error 2 > > make[1]: Leaving directory > > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere- > src-5.10.0/qtwebengine > > ' > > > > > > > > Please let me know if you know what went wrong w/ the second build. > > > > > Looks like it expects ninja to be installed, but cant launch it. Check your > configure output and see if it detected system ninja and you have ninja > installed. > > 'Allan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.yadrov at qt.io Tue Dec 19 21:44:36 2017 From: oleg.yadrov at qt.io (Oleg Yadrov) Date: Tue, 19 Dec 2017 20:44:36 +0000 Subject: [Development] Cross-compile Qt 4.8.x for QNX 6.5.0 Message-ID: Hi, I'm having issues while trying to build Qt 4.8.7 for QNX 6.5.0 (vanilla QNX 6.5.0 without SP1 and libscreen patches installed). Seems like nobody tested if Qt 4.8.5 (I've tried both 4.8.7 and 4.8.5 and observed exactly the same errors) builds for QNX 6.5.0 before release, because it simply does not compile. I have QNX SDP 6.5.0 installed to /opt/qnx650, so before configure Qt I set QNX_HOST=/opt/qnx650/host/linux/x86 QNX_TARGET=opt/qnx650/target/qnx6 I'm using the following line to configure Qt: /home/user/qtforqnx/src/configure -xplatform qnx-x86-qcc -embedded i386 -no-gfx-linuxfb -no-mouse-linuxtp -no-kbd-tty -no-qt3support -qt-gfx-qnx -qt-mouse-qnx -qt-kbd-qnx -exceptions -nomake webkit -opengl es1 -v -prefix /home/user/qtforqnx/install Then, during configuration, I get a message that OpenGL ES 1.x auto-detection test failed due to undefined reference to "gf_surface_create" and "gf_surface_free". I found a way to fix it: I need to add "LIBS += -lgf" to qtsrc/src/mkspecs/qnx-x86-qcc/qmake.conf. Then I get a similar message about EGL. I add "-lEGL" to the same "LIBS" statement. Configuration finishes successfully, I run make a get a message "qlocale_unix.cpp:36: error: '_CS_LOCALE' was not declared in this scope. I go to qlocale_unix.cpp and add "#include ". Next time make stops on qfilesystemiterator_unix.cpp. I do more changes in qfilesystemiterator_unix.cpp. Later on make stops due to multiple errors in QWSServer. I don't think I'm supposed to do all these changes. Am I doing something wrong, or is it really so that nobody tested if Qt >= 4.8.5 builds for QNX 6.5 before me? Thanks, Oleg Yadrov - oleg.yadrov at qt.io PS: I'm not sure what "-embedded i386" parameter is needed for, but if I don't specify it, make fails due to something related to X11 header files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpham3783 at gmail.com Tue Dec 19 22:15:14 2017 From: tpham3783 at gmail.com (Toan Pham) Date: Tue, 19 Dec 2017 16:15:14 -0500 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <1624810.gLDOA3jiHc@tjmaciei-mobl1> <3308126.piR9Nt2yrh@twilight> Message-ID: Hi all, I just found out that the build failed while running this command in qtwebengine/src/core: /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/3rdparty/ninja/ninja -C /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release QtWebEngineCore I was able to resolve by changing to the release folder (see above) and then ran the same command, then webengine started to compile. Obviously, something was wrong w/ the t2 sandbox because ninja could not run getdir() or chdir(). This may be a t2 build, so i will report it to their mailing list. thank you for all your support. TP On Tue, Dec 19, 2017 at 12:16 PM, Toan Pham wrote: > > > Here is brief update on my 32bit build: > > > 1. 32bit build inside lxc container - code built successfully, > qtwebengine worked perfectly. The only problem w/ this one is that it does > not use compatible glibc library as my target board. > > 2. 32bit build inside t2 sandbox - I got the builder to use internal > ninja tool. However, I now faced w/ the error below: > BTW, t2 sandbox is a chroot build environment for building native and > also cross root filesystem. One major advantage of using it because it > completely isolates my development machine from the build environment after > the initial toolchain stage. I am just wondering if that was the reason > why ninja failed, as seen in the getcwd error! > > > /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere- > src-5.10.0/qtwebengine/src/3rdparty/ninja/ninja -C > /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere- > src-5.10.0/qtwebengine/src/core/release QtWebEngineCore > ninja: Entering directory `/TOOLCHAIN/loop/target/ > nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release' > [1/21229] STAMP obj/third_party/webrtc/modules/audio_coding/isac_fix_ > common.stamp > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > [2/21229] STAMP obj/device/sensors/public/interfaces/interfaces__type_ > mappings.inputdeps.stamp > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > [3/21229] STAMP obj/media/midi/mojo_blink__type_mappings.inputdeps.stamp > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > [4/21229] ACTION //extensions/features:features(/TOOLCHAIN/loop/ > target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/toolchain: > target) > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > [5/21229] STAMP obj/extensions/features/features.stamp > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > [6/21229] COPY ../../3rdparty/chromium/third_party/WebKit/Source/devtools/ > front_end/Images/accelerometer-bottom.png resources/inspector/Images/ > accelerometer-bottom.png > FAILED: resources/inspector/Images/accelerometer-bottom.png > ln -f ../../3rdparty/chromium/third_party/WebKit/Source/devtools/ > front_end/Images/accelerometer-bottom.png resources/inspector/Images/accelerometer-bottom.png > 2>/dev/null || (rm -rf resources/inspector/Images/accelerometer-bottom.png > && cp -af ../../3rdparty/chromium/third_party/WebKit/Source/devtools/ > front_end/Images/accelerometer-bottom.png resources/inspector/Images/ > accelerometer-bottom.png) > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > cp: cannot create regular file `/TOOLCHAIN/target/nicebox/ > sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/ > resources/inspector/Images/accelerometer-bottom.png': No such file or > directory > [7/21229] COPY ../../3rdparty/chromium/third_party/WebKit/Source/devtools/ > front_end/emulated_devices/goog...5x-vertical-keyboard-1x.png > resources/inspector/emulated_devices/google-nexus-5x- > vertical-keyboard-1x.pn > FAILED: resources/inspector/emulated_devices/google-nexus-5x- > vertical-keyboard-1x.png > ln -f ../../3rdparty/chromium/third_party/WebKit/Source/devtools/ > front_end/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png > resources/inspector/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png > 2>/dev/null || (rm -rf resources/inspector/emulated_ > devices/google-nexus-5x-vertical-keyboard-1x.png && cp -af > ../../3rdparty/chromium/third_party/WebKit/Source/devtools/ > front_end/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png > resources/inspector/emulated_devices/google-nexus-5x- > vertical-keyboard-1x.png) > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > cp: cannot create regular file `/TOOLCHAIN/target/nicebox/ > sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/ > resources/inspector/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png': > No such file or directory > [8/21229] ACTION //media/midi:mojo_blink__type_mappings(/TOOLCHAIN/loop/ > target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/toolchain: > target) > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > [9/21229] CXX obj/mojo/public/c/system/system/thunks.o > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > [10/21229] CXX obj/crypto/crypto/random.o > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > [11/21229] CXX obj/crypto/crypto/p224.o > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > [12/21229] CXX obj/crypto/crypto/p224_spake.o > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > [13/21229] CXX obj/media/shared_memory_support/audio_point.o > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > [14/21229] CXX obj/crypto/crypto/symmetric_key.o > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > [15/21229] CXX obj/crypto/crypto/sha2.o > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > shell-init: error retrieving current directory: getcwd: cannot access > parent directories: Inappropriate ioctl for device > ninja: build stopped: subcommand failed. > make[4]: *** [run_ninja] Error 1 > make[4]: Leaving directory `/TOOLCHAIN/loop/target/ > nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core' > make[3]: *** [sub-gn_run-pro-make_first] Error 2 > make[3]: Leaving directory `/TOOLCHAIN/loop/target/ > nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core' > make[2]: *** [sub-core-make_first] Error 2 > make[2]: Leaving directory `/TOOLCHAIN/loop/target/ > nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src' > make[1]: *** [sub-src-make_first] Error 2 > make[1]: Leaving directory `/TOOLCHAIN/loop/target/ > nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine' > > > > > > On Mon, Dec 18, 2017 at 2:14 PM, Allan Sandfeld Jensen > wrote: > >> On Montag, 18. Dezember 2017 18:53:55 CET Toan Pham wrote: >> > "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >> 10.0/qtwebengine >> > /src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 45, in >> > check_call >> > subprocess.check_call(cmd, cwd=GN_ROOT, **kwargs) >> > File "/usr/lib/python2.7/subprocess.py", line 535, in check_call >> > retcode = call(*popenargs, **kwargs) >> > File "/usr/lib/python2.7/subprocess.py", line 522, in call >> > return Popen(*popenargs, **kwargs).wait() >> > File "/usr/lib/python2.7/subprocess.py", line 709, in __init__ >> > errread, errwrite) >> > File "/usr/lib/python2.7/subprocess.py", line 1326, in _execute_child >> > raise child_exception >> > OSError: [Errno 2] No such file or directory >> > Project ERROR: GN build error! >> > make[3]: *** [sub-gn-pro-make_first] Error 3 >> > make[3]: Leaving directory >> > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >> 10.0/qtwebengine >> > /src/buildtools' make[2]: *** [sub-buildtools-make_first] Error 2 >> > make[2]: Leaving directory >> > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >> 10.0/qtwebengine >> > /src' make[1]: *** [sub-src-make_first] Error 2 >> > make[1]: Leaving directory >> > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >> 10.0/qtwebengine >> > ' >> > >> > >> > >> > Please let me know if you know what went wrong w/ the second build. >> > >> > >> Looks like it expects ninja to be installed, but cant launch it. Check >> your >> configure output and see if it detected system ninja and you have ninja >> installed. >> >> 'Allan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Dec 19 23:28:17 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Dec 2017 14:28:17 -0800 Subject: [Development] Cross-compile Qt 4.8.x for QNX 6.5.0 In-Reply-To: References: Message-ID: <378433131.JqasAdWn5H@tjmaciei-mobl1> On terça-feira, 19 de dezembro de 2017 12:44:36 PST Oleg Yadrov wrote: > Configuration finishes successfully, I run make a get a message > "qlocale_unix.cpp:36: error: '_CS_LOCALE' was not declared in this scope. qlocale_unix.cpp line 36 in Qt 4.8 is a comment: http://code.qt.io/cgit/qt/qt.git/tree/src/corelib/tools/qlocale_unix.cpp#n36 Did you mean line 58? http://code.qt.io/cgit/qt/qt.git/tree/src/corelib/tools/qlocale_unix.cpp#n58 If this is just an #include issue, try compiling with precompiled headers (pass -pch to configure). > Later on make stops due to multiple errors in QWSServer. QWS was *only* designed for Linux. Do not try to run it on any other platform. You should use X11 on QNX instead. The early QPA might work, but we really can't recommend it until Qt 5. > Am I doing something wrong, or is it really so that nobody tested if Qt >= > 4.8.5 builds for QNX 6.5 before me? You are doing something wrong: trying Qt 4.8 for any new project in almost-2018. Please upgrade. > PS: I'm not sure what "-embedded i386" parameter is needed for, but if I > don't specify it, make fails due to something related to X11 header files. Don't pass options you don't understand. That option is the one that turned the Linux-only QWS subsystem on. Remove it and make sure your buildsystem has X11 headers. Or upgrade to Qt 5. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Tue Dec 19 23:39:24 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 19 Dec 2017 22:39:24 +0000 Subject: [Development] Cross-compile Qt 4.8.x for QNX 6.5.0 In-Reply-To: <378433131.JqasAdWn5H@tjmaciei-mobl1> References: <378433131.JqasAdWn5H@tjmaciei-mobl1> Message-ID: > On Dec 19, 2017, at 2:28 PM, Thiago Macieira wrote: > > On terça-feira, 19 de dezembro de 2017 12:44:36 PST Oleg Yadrov wrote: >> Configuration finishes successfully, I run make a get a message >> "qlocale_unix.cpp:36: error: '_CS_LOCALE' was not declared in this scope. > > qlocale_unix.cpp line 36 in Qt 4.8 is a comment: > > http://code.qt.io/cgit/qt/qt.git/tree/src/corelib/tools/qlocale_unix.cpp#n36 > > Did you mean line 58? > http://code.qt.io/cgit/qt/qt.git/tree/src/corelib/tools/qlocale_unix.cpp#n58 > > If this is just an #include issue, try compiling with precompiled headers > (pass -pch to configure). > >> Later on make stops due to multiple errors in QWSServer. > > QWS was *only* designed for Linux. Do not try to run it on any other platform. > You should use X11 on QNX instead. The early QPA might work, but we really > can't recommend it until Qt 5. > >> Am I doing something wrong, or is it really so that nobody tested if Qt >= >> 4.8.5 builds for QNX 6.5 before me? > > You are doing something wrong: trying Qt 4.8 for any new project in > almost-2018. Please upgrade. Consulting services... > >> PS: I'm not sure what "-embedded i386" parameter is needed for, but if I >> don't specify it, make fails due to something related to X11 header files. > > Don't pass options you don't understand. That option is the one that turned > the Linux-only QWS subsystem on. Remove it and make sure your buildsystem has > X11 headers. > > Or upgrade to Qt 5. > > -- > 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 Wed Dec 20 00:13:14 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Dec 2017 15:13:14 -0800 Subject: [Development] Cross-compile Qt 4.8.x for QNX 6.5.0 In-Reply-To: References: <378433131.JqasAdWn5H@tjmaciei-mobl1> Message-ID: <4732898.4eJenUWvgB@tjmaciei-mobl1> On terça-feira, 19 de dezembro de 2017 14:39:24 PST Jake Petroules wrote: > >> Am I doing something wrong, or is it really so that nobody tested if Qt > >> >= > >> 4.8.5 builds for QNX 6.5 before me? > > > > You are doing something wrong: trying Qt 4.8 for any new project in > > almost-2018. Please upgrade. > > Consulting services... Who are not infallible. I still call a mistake to use Qt 4.8 for ANY new project in 2018. Whether KDAB or ICS or TQtC actually makes money off other people's mistakes is totally orthogonal. Just don't be jack^*&*es and do advise your customers to PLEASE pretty please with a cherry on top consider upgrading to software that is still receiving security fixes. Note this is different from supporting an existing project that happens to still be using Qt 4.8, but the fact that Oleg is wondering if he's the first to try the combination indicates this is indeed a new project. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bogdan at kdab.com Wed Dec 20 09:17:17 2017 From: bogdan at kdab.com (BogDan Vatra) Date: Wed, 20 Dec 2017 10:17:17 +0200 Subject: [Development] Time to switch to android-clang In-Reply-To: <14d4cb98ca86e58afc68d6c8d3d8939b@kdab.com> References: <14d4cb98ca86e58afc68d6c8d3d8939b@kdab.com> Message-ID: <2058457.Pft3JfikTP@debian> On marți, 19 decembrie 2017 11:25:17 EET Sergio Martins wrote: [...] > > The problem of clang generating bigger binaries was much improved with > -Oz, now size increase is only 10%. > Which, on ARM, usually means the bins are slower ;-) [...] Anyway, a +0.5 also from my side. Cheers, BogDan. From denis.shienkov at gmail.com Wed Dec 20 09:39:20 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 20 Dec 2017 11:39:20 +0300 Subject: [Development] [Android] Use pkg-config to link with external libraries in qmake project Message-ID: <5075bfac-6c3a-6897-b57e-17cacfcd549e@gmail.com> Hi all, is it possible to use the pkg-config to build the Android's applications? e.g. I want to use the GStreamer for the Android application, using the pkg-config. I already have installed & configured the the Android Kit, have downloaded the Gstreamer SDK for ARMv7 platform. I use the Windows host, so, I have downloaded the pkg-config 'lite' binary for windows and have added the following env build variables into QtC: 1. PKG_CONFIG_PATH = c:\Android\gstreamer\armv7\lib\pkgconfig\  - a path to my Android's GStreamer pkg-configurations installed. 2. PATH = c:\pkgconfig\bin;  - a path to downloaded pkg-config executable. When I try to open my qmake-based project, e.g. with following content: ... CONFIG += link_pkgconfig PKGCONFIG += \     gstreamer-1.0 \     gstreamer-base-1.0 \     gstreamer-video-1.0 \     gstreamer-app-1.0 ... and to run the qmake, then I got the following errors: " Project WARNING: Cross compiling without sysroot. Disabling pkg-config. Project WARNING: Cross compiling without sysroot. Disabling pkg-config. Project ERROR: gstreamer-1.0 development package not found " This says about the 'sysroot', but, I have no any sysroot for Android kit, besides the QtC 'sysroot' Kit's field is empty and not editable (it is read-only). So, my question is: how to use pkg-config && qmake && Android? PS: I have use similar cinfiguration to build an applications on Windows host (with pkg-config), and all be fines... BR, Denis From oswald.buddenhagen at qt.io Wed Dec 20 10:04:11 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 20 Dec 2017 10:04:11 +0100 Subject: [Development] [Android] Use pkg-config to link with external libraries in qmake project In-Reply-To: <5075bfac-6c3a-6897-b57e-17cacfcd549e@gmail.com> References: <5075bfac-6c3a-6897-b57e-17cacfcd549e@gmail.com> Message-ID: <20171220090411.GB18697@troll08> On Wed, Dec 20, 2017 at 11:39:20AM +0300, Denis Shienkov wrote: > This says about the 'sysroot', but, I have no any sysroot for Android kit, > that's just implausible. you must have something that resembles a sysroot, even if it's not declared as such. if you don't find anything else, just use the directory that contains the lib and include directories. the code is in qt_functions.prf:pkgConfigExecutable(). here you see that you will need to set %PKG_CONFIG_LIBDIR% and %PKG_CONFIG_SYSROOT_DIR% if you qt build is not configured for pkg-config use to start with. From denis.shienkov at gmail.com Wed Dec 20 10:35:19 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 20 Dec 2017 12:35:19 +0300 Subject: [Development] [Android] Use pkg-config to link with external libraries in qmake project In-Reply-To: <20171220090411.GB18697@troll08> References: <5075bfac-6c3a-6897-b57e-17cacfcd549e@gmail.com> <20171220090411.GB18697@troll08> Message-ID: Hi Oswald, Hmm.. many thanks for your hint, I have modified the pkg-conf env variables to: 1. PKG_CONFIG_LIBDIR = c:\Android\gstreamer\armv7\lib\pkgconfig  - a path to all *.pc files. 2. PKG_CONFIG_SYSROOT_DIR = c:\Android\gstreamer\armv7  - a path to a 'fake' sysroot, which contains an 'include',    'lib', 'etc' and other directories. Now, the qmake eats it without warnings... But, now, it does not detect the gst's include files, like: #include though they are present in: c:\Android\gstreamer\armv7\include\gstreamer-1.0\gst\ :( 20.12.2017 12:04, Oswald Buddenhagen пишет: > On Wed, Dec 20, 2017 at 11:39:20AM +0300, Denis Shienkov wrote: >> This says about the 'sysroot', but, I have no any sysroot for Android kit, >> > that's just implausible. you must have something that resembles a > sysroot, even if it's not declared as such. if you don't find anything > else, just use the directory that contains the lib and include > directories. > > the code is in qt_functions.prf:pkgConfigExecutable(). here you see that > you will need to set %PKG_CONFIG_LIBDIR% and %PKG_CONFIG_SYSROOT_DIR% if > you qt build is not configured for pkg-config use to start with. > _______________________________________________ > 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 denis.shienkov at gmail.com Wed Dec 20 10:55:54 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 20 Dec 2017 12:55:54 +0300 Subject: [Development] [Android] Use pkg-config to link with external libraries in qmake project In-Reply-To: References: <5075bfac-6c3a-6897-b57e-17cacfcd549e@gmail.com> <20171220090411.GB18697@troll08> Message-ID: I even have tried following from the Windows cmd durectly: set PATH=c:\pkgconfig\bin;%PATH% set PKG_CONFIG_LIBDIR=c:/Android/gstreamer/armv7/lib/pkgconfig set PKG_CONFIG_SYSROOT_DIR=c:/Android/gstreamer/armv7 pkg-config.exe --cflags gstreamer-1.0 Output is: -pthread -Ic:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/gstreamer-1.0 -Ic:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/glib-2.0 -Ic:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/lib/glib-2.0/include So, all include dirs are found, but the qmake's link_pkgconfig.prf skiped this.. :( 20.12.2017 12:35, Denis Shienkov пишет: > > Hi Oswald, > > Hmm.. many thanks for your hint, I have modified the > pkg-conf env variables to: > > 1. PKG_CONFIG_LIBDIR = c:\Android\gstreamer\armv7\lib\pkgconfig >  - a path to all *.pc files. > > 2. PKG_CONFIG_SYSROOT_DIR = c:\Android\gstreamer\armv7 >  - a path to a 'fake' sysroot, which contains an 'include', >    'lib', 'etc' and other directories. > > Now, the qmake eats it without warnings... > But, now, it does not detect the gst's include files, > like: > > #include > > though they are present in: > > c:\Android\gstreamer\armv7\include\gstreamer-1.0\gst\ > > :( > > > 20.12.2017 12:04, Oswald Buddenhagen пишет: >> On Wed, Dec 20, 2017 at 11:39:20AM +0300, Denis Shienkov wrote: >>> This says about the 'sysroot', but, I have no any sysroot for Android kit, >>> >> that's just implausible. you must have something that resembles a >> sysroot, even if it's not declared as such. if you don't find anything >> else, just use the directory that contains the lib and include >> directories. >> >> the code is in qt_functions.prf:pkgConfigExecutable(). here you see that >> you will need to set %PKG_CONFIG_LIBDIR% and %PKG_CONFIG_SYSROOT_DIR% if >> you qt build is not configured for pkg-config use to start with. >> _______________________________________________ >> 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 denis.shienkov at gmail.com Wed Dec 20 11:03:30 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 20 Dec 2017 13:03:30 +0300 Subject: [Development] [Android] Use pkg-config to link with external libraries in qmake project In-Reply-To: References: <5075bfac-6c3a-6897-b57e-17cacfcd549e@gmail.com> <20171220090411.GB18697@troll08> Message-ID: <2fd67484-defe-ff97-e983-280f6246077c@gmail.com> Next, I have modified the link_pkgconfig.prf to add there a message output like: ... INCLUDEPATH *= $$PKGCONFIG_INCLUDEPATH DEFINES *= $$PKGCONFIG_DEFINES message("blaaaaaaaaaaaaa $$INCLUDEPATH") ... and I see required output: Project MESSAGE: blaaaaaaaaaaaaa c:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/gstreamer-1.0 c:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/glib-2.0 c:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/lib/glib-2.0/include all fine... But, if I try to output message from my *.pro file: message("blaaaaaaaaaaaaa $$INCLUDEPATH") then I see an empty content of INCLUDEPATH... What happens? 20.12.2017 12:55, Denis Shienkov пишет: > > I even have tried following from the Windows cmd durectly: > > set PATH=c:\pkgconfig\bin;%PATH% > set PKG_CONFIG_LIBDIR=c:/Android/gstreamer/armv7/lib/pkgconfig > set PKG_CONFIG_SYSROOT_DIR=c:/Android/gstreamer/armv7 > > pkg-config.exe --cflags gstreamer-1.0 > > Output is: > > -pthread > -Ic:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/gstreamer-1.0 > -Ic:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/glib-2.0 > -Ic:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/lib/glib-2.0/include > > So, all include dirs are found, but the qmake's link_pkgconfig.prf > skiped this.. :( > > > 20.12.2017 12:35, Denis Shienkov пишет: >> >> Hi Oswald, >> >> Hmm.. many thanks for your hint, I have modified the >> pkg-conf env variables to: >> >> 1. PKG_CONFIG_LIBDIR = c:\Android\gstreamer\armv7\lib\pkgconfig >>  - a path to all *.pc files. >> >> 2. PKG_CONFIG_SYSROOT_DIR = c:\Android\gstreamer\armv7 >>  - a path to a 'fake' sysroot, which contains an 'include', >>    'lib', 'etc' and other directories. >> >> Now, the qmake eats it without warnings... >> But, now, it does not detect the gst's include files, >> like: >> >> #include >> >> though they are present in: >> >> c:\Android\gstreamer\armv7\include\gstreamer-1.0\gst\ >> >> :( >> >> >> 20.12.2017 12:04, Oswald Buddenhagen пишет: >>> On Wed, Dec 20, 2017 at 11:39:20AM +0300, Denis Shienkov wrote: >>>> This says about the 'sysroot', but, I have no any sysroot for Android kit, >>>> >>> that's just implausible. you must have something that resembles a >>> sysroot, even if it's not declared as such. if you don't find anything >>> else, just use the directory that contains the lib and include >>> directories. >>> >>> the code is in qt_functions.prf:pkgConfigExecutable(). here you see that >>> you will need to set %PKG_CONFIG_LIBDIR% and %PKG_CONFIG_SYSROOT_DIR% if >>> you qt build is not configured for pkg-config use to start with. >>> _______________________________________________ >>> 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 Wed Dec 20 11:53:07 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 20 Dec 2017 11:53:07 +0100 Subject: [Development] [Android] Use pkg-config to link with external libraries in qmake project In-Reply-To: <2fd67484-defe-ff97-e983-280f6246077c@gmail.com> References: <5075bfac-6c3a-6897-b57e-17cacfcd549e@gmail.com> <20171220090411.GB18697@troll08> <2fd67484-defe-ff97-e983-280f6246077c@gmail.com> Message-ID: <20171220105307.GC18697@troll08> On Wed, Dec 20, 2017 at 01:03:30PM +0300, Denis Shienkov wrote: > c:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/gstreamer-1.0 > i really wouldn't expect this to work. ;) the problems seems to be that pkg-config outputs the paths in a format that cannot be possibly understood by the compiler. that's a bug in the .pc files or pkg-config itself, i'd guess. > But, if I try to output message from my *.pro file: > > message("blaaaaaaaaaaaaa $$INCLUDEPATH") > > then I see an empty content of INCLUDEPATH... > > What happens? > execution order happens. ;) From denis.shienkov at gmail.com Wed Dec 20 12:18:12 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 20 Dec 2017 14:18:12 +0300 Subject: [Development] [Android] Use pkg-config to link with external libraries in qmake project In-Reply-To: <20171220105307.GC18697@troll08> References: <5075bfac-6c3a-6897-b57e-17cacfcd549e@gmail.com> <20171220090411.GB18697@troll08> <2fd67484-defe-ff97-e983-280f6246077c@gmail.com> <20171220105307.GC18697@troll08> Message-ID: <1787e50a-bba3-a8c8-8871-d2d7eb0198cb@gmail.com> Ohhh.. exactly, many thanks... :) 20.12.2017 13:53, Oswald Buddenhagen пишет: > On Wed, Dec 20, 2017 at 01:03:30PM +0300, Denis Shienkov wrote: >> c:/Android/gstreamer/armv7c:/Android/gstreamer/armv7/include/gstreamer-1.0 >> > i really wouldn't expect this to work. ;) > > the problems seems to be that pkg-config outputs the paths in a format > that cannot be possibly understood by the compiler. that's a bug in the > .pc files or pkg-config itself, i'd guess. > >> But, if I try to output message from my *.pro file: >> >> message("blaaaaaaaaaaaaa $$INCLUDEPATH") >> >> then I see an empty content of INCLUDEPATH... >> >> What happens? >> > execution order happens. ;) > > _______________________________________________ > 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 lars.knoll at qt.io Wed Dec 20 15:17:43 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 20 Dec 2017 14:17:43 +0000 Subject: [Development] Dropping of MSVC 2013 In-Reply-To: References: <2827905.1UXfmysL1p@tjmaciei-mobl1> <0903A9A1-04B8-4D24-93A8-907FC548526B@qt.io> <5315663.VmxJgI0e72@tjmaciei-mobl1> Message-ID: Hi all, here are the promised numbers: Version Compiler Commercial Version Compiler Opensource 5.10.0 MinGW530 22 % 5.10.0 MinGW530 25 % 5.10.0 MSVC2013_64 14 % 5.10.0 MSVC2013_64 15 % 5.10.0 MSVC2015 20 % 5.10.0 MSVC2015 18 % 5.10.0 MSVC2015_64 20 % 5.10.0 MSVC2015_64 18 % 5.10.0 MSVC2017_64 24 % 5.10.0 MSVC2017_64 24 % So MSVC 2013 is now the least used compiler by both our customers and the community, and seems to be dropping fast. Given that 5.11 is still some months out, download percentages for this compiler would probably be in the single digit range by then. So my proposal is to drop MSVC 2013 support from 5.11 and onwards. Cheers, Lars On 18 Dec 2017, at 12:09, Tuukka Turunen > wrote: Hi, Akseli will check the percentages from Qt 5.10 online installer later this week. Yours, Tuukka On 16/12/2017, 18.25, "Development on behalf of Thiago Macieira" on behalf of thiago.macieira at intel.com> wrote: On Wednesday, 8 November 2017 10:57:32 PST Alex Blasche wrote: Sorry, no. As mentioned during the contributor summit, this decision is tabled until we have the 5.10 download figures. Any numbers now? -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ville.voutilainen at gmail.com Wed Dec 20 15:49:40 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 20 Dec 2017 16:49:40 +0200 Subject: [Development] Dropping of MSVC 2013 In-Reply-To: References: <2827905.1UXfmysL1p@tjmaciei-mobl1> <0903A9A1-04B8-4D24-93A8-907FC548526B@qt.io> <5315663.VmxJgI0e72@tjmaciei-mobl1> Message-ID: On 20 December 2017 at 16:17, Lars Knoll wrote: > Hi all, > > here are the promised numbers: > *Version* > *Compiler* > *Commercial* > > *Version* > *Compiler* > *Opensource* > 5.10.0 > MinGW530 > 22 % > > 5.10.0 > MinGW530 > 25 % > 5.10.0 > MSVC2013_64 > 14 % > > 5.10.0 > MSVC2013_64 > 15 % > 5.10.0 > MSVC2015 > 20 % > > 5.10.0 > MSVC2015 > 18 % > 5.10.0 > MSVC2015_64 > 20 % > > 5.10.0 > MSVC2015_64 > 18 % > 5.10.0 > MSVC2017_64 > 24 % > > 5.10.0 > MSVC2017_64 > 24 % > > > So MSVC 2013 is now the least used compiler by both our customers and the > community, and seems to be dropping fast. Given that 5.11 is still some > months out, download percentages for this compiler would probably be in the > single digit range by then. > > So my proposal is to drop MSVC 2013 support from 5.11 and onwards. > > Sounds good, +1, good riddance. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederik.gladhorn at qt.io Wed Dec 20 16:25:10 2017 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 20 Dec 2017 16:25:10 +0100 Subject: [Development] Proposal to remove QNX 6.6 support from Qt 5.11 onwards In-Reply-To: References: Message-ID: <3834436.AtMNtSuJRY@frederik-thinkcentre-m93p> On fredag 15. desember 2017 20.04.33 CET Tuukka Turunen wrote: > Hi, > > > I propose to remove support for QNX 6.6 from Qt 5.11 onwards. Yes please, it has been a bit of a trouble maker every once in a while :) For example not needing to patch a header file on the platform is a good thing. Cheers, Frederik > > > Since Qt 5.9.0 we have supported both QNX 6.6 and 7.0, but going forward we > would support only QNX 7.0 with new Qt versions. QNX 6.6 continues to be > supported with Qt 5.9 LTS and Qt 5.10. > > > Based on my experience QNX 7.0 is a better choice for new projects than QNX > 6.6. It has, for example, better C++11 support, 64 bit support and improved > graphics support. > > > I have discussed the topic with James McDonnell (QNX platform maintainer) as > well as QNX product management and they agree that it is better to focus > into improving QNX 7.0 support with upcoming Qt releases rather that > splitting the effort between QNX 6.6 and 7.0. > > > Yours, > > > Tuukka From annulen at yandex.ru Wed Dec 20 17:00:18 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 20 Dec 2017 19:00:18 +0300 Subject: [Development] Weird issue in CI Message-ID: <266961513785618@web6o.yandex.ru> I'm repeatedly getting this error: Failed to provision template 'qtci-linux-Ubuntu-16.04-x86_64-1-b46ac1': Failed repeatedly to launch build/test agent Details: https://testresults.qt.io/coin/integration/qt/qtwebkit/tasks/1513784851 No log exist. -- Regards, Konstantin From thiago.macieira at intel.com Wed Dec 20 17:26:14 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Dec 2017 08:26:14 -0800 Subject: [Development] Dropping of MSVC 2013 In-Reply-To: References: <2827905.1UXfmysL1p@tjmaciei-mobl1> Message-ID: <2059439.AcAk3oIIbm@tjmaciei-mobl1> On quarta-feira, 20 de dezembro de 2017 06:49:40 PST Ville Voutilainen wrote: > Sounds good, +1, good riddance. +1 With the drop of QNX 6.6, we'll finally be C++11 core language feature- complete, only ~7 years after it came out. Fortunately, those numbers seem to be coming down. We should be able to require C++14 within the next two years. We officially required C++98 with Qt 5.0 (15 years after it came out), but effectively we had been requiring that for some time, at least since we dropped faulty, old compilers. (We dropped aCC 3 with PA-RISC sometime around 2008; HP aCC 6 was much better, but I don't remember if it supported template friends; I don't know when the Solaris compiler became "good", but I do remember building WebKit with it in the Summer of 2009; the drop of IRIX CC was before PA-RISC's, like the MSVC 6.0 drop alongside non-Unicode Windows). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Wed Dec 20 18:42:39 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 20 Dec 2017 17:42:39 +0000 Subject: [Development] Cross-compile Qt 4.8.x for QNX 6.5.0 In-Reply-To: <4732898.4eJenUWvgB@tjmaciei-mobl1> References: <378433131.JqasAdWn5H@tjmaciei-mobl1> <4732898.4eJenUWvgB@tjmaciei-mobl1> Message-ID: > On 20 Dec 2017, at 00:13, Thiago Macieira wrote: > > On terça-feira, 19 de dezembro de 2017 14:39:24 PST Jake Petroules wrote: >>>> Am I doing something wrong, or is it really so that nobody tested if Qt >>>>> = >>>> 4.8.5 builds for QNX 6.5 before me? No, at least not a QNX without any service patches etc installed. But neither QNX 6.5 nor Qt 4.8 is supported here anymore, so don't expect any help here. >>> >>> You are doing something wrong: trying Qt 4.8 for any new project in >>> almost-2018. Please upgrade. As Thiago said. I'd try to upgrade to QNX 6.6 and Qt 5.9. >> >> Consulting services... > > Who are not infallible. > > I still call a mistake to use Qt 4.8 for ANY new project in 2018. Whether KDAB > or ICS or TQtC actually makes money off other people's mistakes is totally > orthogonal. Just don't be jack^*&*es and do advise your customers to PLEASE > pretty please with a cherry on top consider upgrading to software that is > still receiving security fixes. Thiago, that's what we're always doing. Nobody I know of advises customers to use old and unsupported versions of Qt. But those companies you mention do try to help customers find a solution to their problem. The (highly) preferred option is of course to get the customer upgraded to something that's officially supported. Cheers, Lars > > Note this is different from supporting an existing project that happens to > still be using Qt 4.8, but the fact that Oleg is wondering if he's the first > to try the combination indicates this is indeed a new project. > > -- > 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 Dec 20 19:28:48 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Dec 2017 10:28:48 -0800 Subject: [Development] Cross-compile Qt 4.8.x for QNX 6.5.0 In-Reply-To: References: <4732898.4eJenUWvgB@tjmaciei-mobl1> Message-ID: <3996843.bxybJzyPen@tjmaciei-mobl1> On quarta-feira, 20 de dezembro de 2017 09:42:39 PST Lars Knoll wrote: > > I still call a mistake to use Qt 4.8 for ANY new project in 2018. Whether > > KDAB or ICS or TQtC actually makes money off other people's mistakes is > > totally orthogonal. Just don't be jack^*&*es and do advise your customers > > to PLEASE pretty please with a cherry on top consider upgrading to > > software that is still receiving security fixes. > > > Thiago, that's what we're always doing. Nobody I know of advises customers > to use old and unsupported versions of Qt. I know you do. I just had to write that because it sounded extremely callous when I wrote "it's ok for you to make money off other people's mistakes". I know that it's not the immediate consequence. You do advise them, but if they insist (for good reason or ill), then I expect you to be suitably compensated for the work. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Wed Dec 20 22:47:36 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 20 Dec 2017 21:47:36 +0000 Subject: [Development] Cross-compile Qt 4.8.x for QNX 6.5.0 In-Reply-To: <3996843.bxybJzyPen@tjmaciei-mobl1> References: <4732898.4eJenUWvgB@tjmaciei-mobl1> <3996843.bxybJzyPen@tjmaciei-mobl1> Message-ID: <82934DC1-EDDA-4183-8A0C-247941C8BD7D@qt.io> > On 20 Dec 2017, at 19:28, Thiago Macieira wrote: > > On quarta-feira, 20 de dezembro de 2017 09:42:39 PST Lars Knoll wrote: >>> I still call a mistake to use Qt 4.8 for ANY new project in 2018. Whether >>> KDAB or ICS or TQtC actually makes money off other people's mistakes is >>> totally orthogonal. Just don't be jack^*&*es and do advise your customers >>> to PLEASE pretty please with a cherry on top consider upgrading to >>> software that is still receiving security fixes. >> >> >> Thiago, that's what we're always doing. Nobody I know of advises customers >> to use old and unsupported versions of Qt. > > I know you do. I just had to write that because it sounded extremely callous > when I wrote "it's ok for you to make money off other people's mistakes". I > know that it's not the immediate consequence. You do advise them, but if they > insist (for good reason or ill), then I expect you to be suitably compensated > for the work. Absolutely. If people really need the old version there's ways to get help, but support for those always comes at a premium. Cheers, Lars From frederik.gladhorn at qt.io Thu Dec 21 10:08:15 2017 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 21 Dec 2017 10:08:15 +0100 Subject: [Development] Weird issue in CI In-Reply-To: <266961513785618@web6o.yandex.ru> References: <266961513785618@web6o.yandex.ru> Message-ID: <21044012.QVaT3I9ram@frederik-thinkcentre-m93p> On onsdag 20. desember 2017 17.00.18 CET Konstantin Tokarev wrote: > I'm repeatedly getting this error: > > Failed to provision template 'qtci-linux-Ubuntu-16.04-x86_64-1-b46ac1': > Failed repeatedly to launch build/test agent This means it never actually did any work because it either didn't get a VM or when acquiring one, it didn't manage to communicate with it (we launch a program on the VMs = the "agent", which calls home once the machine is up and running). I'll improve the error message at least. > Details: > https://testresults.qt.io/coin/integration/qt/qtwebkit/tasks/1513784851 > > No log exist. We only show logs when anything happens on a VM (=agent). Since it never got that far there is no log, we only have our general logs for all of Coin to look at. This points to a bug in Coin or the infrastructure below it. Someone who has access needs to investigate. Cheers, Frederik From rithvikp98 at gmail.com Thu Dec 21 10:14:14 2017 From: rithvikp98 at gmail.com (Rithvik Patibandla) Date: Thu, 21 Dec 2017 14:44:14 +0530 Subject: [Development] Integrating Common Print Dialog project into Qt Message-ID: <65A10371-06B6-4437-9EE8-2CD4590A533E@gmail.com> Hi This summer, OpenPrinting [1] has created a Common Print Dialog project via the Google Summer of Code (2017) program to improve the experience of printing in Linux systems with a modern UI and backend APIs that will be maintained by the OpenPrinting org (the idea can be found here [2]). I am one of the students who worked on this project. For the UI, we decided to build one using Qt 5. Although, the dialog started as an application to ship with individual distributions, we changed course and instead built a print dialog API which can be used by application developers to include the dialog in their applications. We wish to integrate this dialog API into Qt so that any application built using Qt can use this dialog to include support for printing. The code for the dialog can be found here [3]. We request the Qt developers to review the code and help us in integrating the dialog into Qt. The build instructions are given in the README file and screenshots of the dialog will be uploaded very soon. Thanks, Rithvik [1] https://wiki.linuxfoundation.org/openprinting/start [2] https://wiki.linuxfoundation.org/gsoc/google-summer-code-2017-openprinting-projects [3] https://github.com/rithvikp1998/common-print-dialog -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert.astals.cid at kdab.com Thu Dec 21 10:22:47 2017 From: albert.astals.cid at kdab.com (Albert Astals Cid) Date: Thu, 21 Dec 2017 10:22:47 +0100 Subject: [Development] Integrating Common Print Dialog project into Qt In-Reply-To: <65A10371-06B6-4437-9EE8-2CD4590A533E@gmail.com> References: <65A10371-06B6-4437-9EE8-2CD4590A533E@gmail.com> Message-ID: <2773388.sx4n8UKjcV@yoga> El dijous, 21 de desembre de 2017, a les 10:14:14 CET, Rithvik Patibandla va escriure: > Hi Hi > This summer, OpenPrinting [1] has created a Common Print Dialog project via > the Google Summer of Code (2017) program to improve the experience of > printing in Linux systems with a modern UI and backend APIs that will be > maintained by the OpenPrinting org (the idea can be found here [2]). I am > one of the students who worked on this project. For the UI, we decided to > build one using Qt 5. Although, the dialog started as an application to > ship with individual distributions, we changed course and instead built a > print dialog API which can be used by application developers to include the > dialog in their applications. We wish to integrate this dialog API into Qt > so that any application built using Qt can use this dialog to include > support for printing. The code for the dialog can be found here [3]. We > request the Qt developers to review the code and help us in integrating the > dialog into Qt. The build instructions are given in the README file and > screenshots of the dialog will be uploaded very soon. I see a big-ish problem that is that it uses QtQuick so it can't really go into qtbase where the current printing dialog lives, so if this was to be accepted the printing module would need to split off from qtbase (no idea if that is planned or not). Looking at the code Advanced.qml seems to be collection of items that really don't do anything at all? Cheers, Albert > > Thanks, > Rithvik > > [1] https://wiki.linuxfoundation.org/openprinting/start > [2] > https://wiki.linuxfoundation.org/gsoc/google-summer-code-2017-openprinting-> projects > -projects> [3] https://github.com/rithvikp1998/common-print-dialog > -- Albert Astals Cid | albert.astals.cid at 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 - The Qt, C++ and OpenGL Experts From rithvikp98 at gmail.com Thu Dec 21 10:33:53 2017 From: rithvikp98 at gmail.com (Rithvik Patibandla) Date: Thu, 21 Dec 2017 15:03:53 +0530 Subject: [Development] Integrating Common Print Dialog project into Qt In-Reply-To: <2773388.sx4n8UKjcV@yoga> References: <65A10371-06B6-4437-9EE8-2CD4590A533E@gmail.com> <2773388.sx4n8UKjcV@yoga> Message-ID: > On 21-Dec-2017, at 2:52 PM, Albert Astals Cid wrote: > > I see a big-ish problem that is that it uses QtQuick so it can't really go > into qtbase where the current printing dialog lives, so if this was to be > accepted the printing module would need to split off from qtbase (no idea if > that is planned or not). > This has been one of our main concerns too. At the time of project planning, we were thinking more about QML support because of the missing printing support within QML. However, if it is not possible to split the dialog off qtbase, we could probably redo the QML part and write the UI using QWidget instead but that would be our last option. > Looking at the code Advanced.qml seems to be collection of items that really > don't do anything at all? The CUPS backend API doesn’t support all of these options yet. So we just put up dummy dropdown and we’ll add backend functions to them as soon as the API supports it. Thanks, Rithvik -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Thu Dec 21 10:46:20 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 21 Dec 2017 12:46:20 +0300 Subject: [Development] Weird issue in CI In-Reply-To: <21044012.QVaT3I9ram@frederik-thinkcentre-m93p> References: <266961513785618@web6o.yandex.ru> <21044012.QVaT3I9ram@frederik-thinkcentre-m93p> Message-ID: <682481513849580@web50o.yandex.ru> > On onsdag 20. desember 2017 17.00.18 CET Konstantin Tokarev wrote: > >> I'm repeatedly getting this error: >> >> Failed to provision template 'qtci-linux-Ubuntu-16.04-x86_64-1-b46ac1': >> Failed repeatedly to launch build/test agent > > This means it never actually did any work because it either didn't get a VM or > when acquiring one, it didn't manage to communicate with it (we launch a > program on the VMs = the "agent", which calls home once the machine is up and > running). I'll improve the error message at least. Main problem is not error text, but fact that on I restage I get the same error again and again (for same or different VM image) > >> Details: >> https://testresults.qt.io/coin/integration/qt/qtwebkit/tasks/1513784851 >> >> No log exist. > > We only show logs when anything happens on a VM (=agent). Since it never got > that far there is no log, we only have our general logs for all of Coin to > look at. > > This points to a bug in Coin or the infrastructure below it. Someone who has > access needs to investigate. > > Cheers, > Frederik -- Regards, Konstantin From rjvbertin at gmail.com Thu Dec 21 11:35:48 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 21 Dec 2017 11:35:48 +0100 Subject: [Development] About the presence of /System/Library/Frameworks/Carbon.framework Message-ID: <1939068.kntlJOzske@bola> Hi, Here's a silly one: configuring Qt for building on my Linux rig I was told that I needed Xcode, and how to get it. :) Long story short, it turns out that the configure script determines whether it's building on Mac by checking if the Carbon framework exists in the designated location. And it turns out that I copied over the entire header dir. structure under /System/Library/Frameworks onto said Linux rig because I use it for cross-platform development. Apart from the fact that it should probably check for a framework with a more certain future, isn't there a less "rootsy" way of determining whether the script is running on Mac? R. From jani.heikkinen at qt.io Thu Dec 21 11:37:47 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 21 Dec 2017 10:37:47 +0000 Subject: [Development] Stop delivering 32 bit MinGW binaries from 5.12 -> In-Reply-To: References: , , Message-ID: Hi all, There is open suggestion (https://bugreports.qt.io/browse/QTBUG-35288) to start delivering MinGW 64 bit pre-built binaries. This has been requested several times in mails, blog comments etc. We have discussed this earlier, last time with Qt 5.10 where I proposed that we could replace 32 bit MinGW with 64 bit one. But at that time we weren't ready for that. And it seems 32 bit MinGW package is still quite widely used, see http://lists.qt-project.org/pipermail/development/2017-December/031674.html . With Qt 5.11 it seems we can finally drop MSVC2013 so we could "temporarily" add MinGW 64 bit pre-build binaries in our packages in addition to 32 bit ones and remove 32 bit MinGW pre-built binaries from 5.12 onwards. Making this decision now would complete this discussion finally and still give users time to move from 32 bit to 64 bit ones... br, Jani From lars.knoll at qt.io Thu Dec 21 11:45:00 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 21 Dec 2017 10:45:00 +0000 Subject: [Development] Stop delivering 32 bit MinGW binaries from 5.12 -> In-Reply-To: References: Message-ID: <95162EDF-978D-45E6-8BDB-F15F70162164@qt.io> Hi Jani, +1 from my side for doing the move to 64bit MinGW in two steps. Cheers, Lars > On 21 Dec 2017, at 11:37, Jani Heikkinen wrote: > > Hi all, > > There is open suggestion (https://bugreports.qt.io/browse/QTBUG-35288) to start delivering MinGW 64 bit pre-built binaries. This has been requested several times in mails, blog comments etc. We have discussed this earlier, last time with Qt 5.10 where I proposed that we could replace 32 bit MinGW with 64 bit one. But at that time we weren't ready for that. And it seems 32 bit MinGW package is still quite widely used, see http://lists.qt-project.org/pipermail/development/2017-December/031674.html . > > With Qt 5.11 it seems we can finally drop MSVC2013 so we could "temporarily" add MinGW 64 bit pre-build binaries in our packages in addition to 32 bit ones and remove 32 bit MinGW pre-built binaries from 5.12 onwards. Making this decision now would complete this discussion finally and still give users time to move from 32 bit to 64 bit ones... > > br, > Jani > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Thu Dec 21 11:47:34 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 21 Dec 2017 13:47:34 +0300 Subject: [Development] About the presence of /System/Library/Frameworks/Carbon.framework In-Reply-To: <1939068.kntlJOzske@bola> References: <1939068.kntlJOzske@bola> Message-ID: <479391513853254@web5j.yandex.ru> > Hi, > > Here's a silly one: configuring Qt for building on my Linux rig I was told that I needed Xcode, and how to get it. :) > > Long story short, it turns out that the configure script determines whether it's building on Mac by checking if the Carbon framework exists in the designated location. And it turns out that I copied over the entire header dir. structure under /System/Library/Frameworks onto said Linux rig because I use it for cross-platform development. > > Apart from the fact that it should probably check for a framework with a more certain future, isn't there a less "rootsy" way of determining whether the script is running on Mac? Check uname maybe? > > R. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From roland.m.winklmeier at gmail.com Thu Dec 21 11:59:32 2017 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Thu, 21 Dec 2017 11:59:32 +0100 Subject: [Development] Stop delivering 32 bit MinGW binaries from 5.12 -> In-Reply-To: References: Message-ID: 2017-12-21 11:37 GMT+01:00 Jani Heikkinen : > With Qt 5.11 it seems we can finally drop MSVC2013 so we could > "temporarily" add MinGW 64 bit pre-build binaries in our packages in > addition to 32 bit ones and remove 32 bit MinGW pre-built binaries from > 5.12 onwards. Making this decision now would complete this discussion > finally and still give users time to move from 32 bit to 64 bit ones... > Hi Jani, adding MinGW 64 bit sounds great. I would prefer to keep the MinGW 32 bit ones too, because there are several projects which are plugins to host applications in 32 bit. So sometimes its not in the scope of the developer to change his project to 64 bit. Please keep that in mind. I personally use MSVC2017 together with MSVC2015 32 bit binaries for the published product. But I regularly use MinGW for daily development. Other people might prefer MinGW over MSVC for published products though. So 32 bit software projects are still very common on Windows platforms. Cheers R. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Thu Dec 21 12:57:51 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 21 Dec 2017 12:57:51 +0100 Subject: [Development] About the presence of /System/Library/Frameworks/Carbon.framework In-Reply-To: <479391513853254@web5j.yandex.ru> References: <1939068.kntlJOzske@bola> <479391513853254@web5j.yandex.ru> Message-ID: <2244428.fJXqf0c1a4@portia.local> On Thursday December 21 2017 13:47:34 Konstantin Tokarev wrote: > Check uname maybe? Possibly: just `uname` returns Darwin. That should certainly work for the desktop OS, but I have no way of checking what it returns on other Apple OSes (and if the Carbon.framework exists there). R. From thiago.macieira at intel.com Thu Dec 21 12:54:31 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 21 Dec 2017 05:54:31 -0600 Subject: [Development] About the presence of /System/Library/Frameworks/Carbon.framework In-Reply-To: <479391513853254@web5j.yandex.ru> References: <1939068.kntlJOzske@bola> <479391513853254@web5j.yandex.ru> Message-ID: <3300826.BcPtKKvnmx@tjmaciei-mobl1> On quinta-feira, 21 de dezembro de 2017 04:47:34 CST Konstantin Tokarev wrote: > > Hi, > > > > Here's a silly one: configuring Qt for building on my Linux rig I was told > > that I needed Xcode, and how to get it. :) > > > > Long story short, it turns out that the configure script determines > > whether it's building on Mac by checking if the Carbon framework exists > > in the designated location. And it turns out that I copied over the > > entire header dir. structure under /System/Library/Frameworks onto said > > Linux rig because I use it for cross-platform development. > > > > Apart from the fact that it should probably check for a framework with a > > more certain future, isn't there a less "rootsy" way of determining > > whether the script is running on Mac? > Check uname maybe? That would tell you the host you're running on, not the target you're compiling to. If your sysroot contains Apple files, it's reasonable to conclude it's an Apple system. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tony.sarajarvi at qt.io Thu Dec 21 13:19:24 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Thu, 21 Dec 2017 12:19:24 +0000 Subject: [Development] CI is suffering from problems Message-ID: Hi You have probably already noticed this, but here's an email notifying you that we're on it. Our OpenNebula isn't able to clone any new virtual machines, complaining that the disk is full even though it isn't. As said...we continue investigating. Regards, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.hermann at qt.io Thu Dec 21 14:17:29 2017 From: ulf.hermann at qt.io (Ulf Hermann) Date: Thu, 21 Dec 2017 14:17:29 +0100 Subject: [Development] CI is suffering from problems In-Reply-To: References: Message-ID: > You have probably already noticed this, but here’s an email notifying > you that we’re on it. Our OpenNebula isn’t able to clone any new virtual > machines, complaining that the disk is full even though it isn’t. As > said…we continue investigating. In addition to that we suddenly get failures when compiling QtCore and QtNetwork, even if nothing has changed there: > Module "qt/qtbase" (9ec8da01004481027df83361b998b24c63ab5a6d) The make execution failed. The CI rejected the staged commits due to the beforementioned reason. Possible reason could be flakiness in the system, but could also be a bug in one of the commits.: > /home/qt/work/qt/qtbase/src/corelib/global/qfloat16_f16c.c:61: undefined reference to `_mm256_cvtps_ph' > /home/qt/work/qt/qtbase/src/corelib/global/qfloat16_f16c.c:76: undefined reference to `_mm256_cvtph_ps' > Makefile:1152: recipe for target '../../lib/libQt5Core.so.5.11.0' failed > make[2]: *** [../../lib/libQt5Core.so.5.11.0] Error 1 > make[1]: *** [sub-corelib-make_first] Error 2 > make: *** [sub-src-make_first] Error 2 and > Module "qt/qtbase" (99b12531013516c060eed60157f8b0be5eafa1e5) The make execution failed. The CI rejected the staged commits due to the beforementioned reason. Possible reason could be flakiness in the system, but could also be a bug in one of the commits.: > /opt/yocto-armv7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -c -include .pch/Qt5Network -pipe -march=armv7-a -mfpu=neon -DLINUX=1 -mfloat-abi=hard --sysroot=/opt/yocto-armv7/sysroots/armv7ahf-neon-poky-linux-gnueabi -g -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Werror -Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow -D_REENTRANT -fPIC -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DQT_USE_SYSTEM_PROXIES -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_NETWORK_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB -I. -Ikernel -I../../include -I../../include/QtNetwork -I../../include/QtNetwork/5.11.0 -I../../include/QtNetw > ork/5.11.0/QtNetwork -I../../include/QtCore/5.11.0 -I../../include/QtCore/5.11.0/QtCore -I../../include/QtCore -I.moc -I../../mkspecs/devices/linux-imx7-g++ -o .obj/qnetworkinterface_linux.o kernel/qnetworkinterface_linux.cpp > kernel/qnetworkinterface_linux.cpp: In instantiation of ‘void {anonymous}::ProcessNetlinkRequest::operator()(int, nlmsghdr*, char*, size_t, Lambda&&) [with Lambda = getInterfaces(int, char*)::; size_t = unsigned int]’: > kernel/qnetworkinterface_linux.cpp:216:36: required from ‘void {anonymous}::processNetlinkRequest(int, nlmsghdr*, char*, size_t, Lambda&&) [with Lambda = getInterfaces(int, char*)::; size_t = unsigned int]’ > kernel/qnetworkinterface_linux.cpp:319:6: required from here > kernel/qnetworkinterface_linux.cpp:161:48: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] > kernel/qnetworkinterface_linux.cpp: In instantiation of ‘void {anonymous}::ProcessNetlinkRequest::operator()(int, nlmsghdr*, char*, size_t, Lambda&&) [with Lambda = getAddresses(int, char*, QList&)::; size_t = unsigned int]’: > kernel/qnetworkinterface_linux.cpp:216:36: required from ‘void {anonymous}::processNetlinkRequest(int, nlmsghdr*, char*, size_t, Lambda&&) [with Lambda = getAddresses(int, char*, QList&)::; size_t = unsigned int]’ > kernel/qnetworkinterface_linux.cpp:423:6: required from here > kernel/qnetworkinterface_linux.cpp:161:48: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] > Makefile:26401: recipe for target '.obj/qnetworkinterface_linux.o' failed > make[2]: *** [.obj/qnetworkinterface_linux.o] Error 1 > make[1]: *** [sub-network-make_first] Error 2 > make: *** [sub-src-make_first] Error 2 I guess in the first case the system headers changed and in the second case the compiler changed. Do you actually test machine configuration changes against the current state of Qt before you switch them live? I think that should be done and any fixes to Qt for the new configuration should be applied before the configuration goes live. br, Ulf From Liang.Qi at qt.io Thu Dec 21 16:52:17 2017 From: Liang.Qi at qt.io (Liang Qi) Date: Thu, 21 Dec 2017 15:52:17 +0000 Subject: [Development] CI is suffering from problems In-Reply-To: References: Message-ID: <04770DAF-555C-4129-9045-8444F731475A@qt.io> both are known and fixes are available. https://codereview.qt-project.org/#/c/215113/ https://codereview.qt-project.org/#/c/215046/ — Liang > On 21 Dec 2017, at 14:17, Ulf Hermann wrote: > >> You have probably already noticed this, but here’s an email notifying >> you that we’re on it. Our OpenNebula isn’t able to clone any new virtual >> machines, complaining that the disk is full even though it isn’t. As >> said…we continue investigating. > > In addition to that we suddenly get failures when compiling QtCore and QtNetwork, even if nothing has changed there: > >> Module "qt/qtbase" (9ec8da01004481027df83361b998b24c63ab5a6d) The make execution failed. The CI rejected the staged commits due to the beforementioned reason. Possible reason could be flakiness in the system, but could also be a bug in one of the commits.: >> /home/qt/work/qt/qtbase/src/corelib/global/qfloat16_f16c.c:61: undefined reference to `_mm256_cvtps_ph' >> /home/qt/work/qt/qtbase/src/corelib/global/qfloat16_f16c.c:76: undefined reference to `_mm256_cvtph_ps' >> Makefile:1152: recipe for target '../../lib/libQt5Core.so.5.11.0' failed >> make[2]: *** [../../lib/libQt5Core.so.5.11.0] Error 1 >> make[1]: *** [sub-corelib-make_first] Error 2 >> make: *** [sub-src-make_first] Error 2 > > and > >> Module "qt/qtbase" (99b12531013516c060eed60157f8b0be5eafa1e5) The make execution failed. The CI rejected the staged commits due to the beforementioned reason. Possible reason could be flakiness in the system, but could also be a bug in one of the commits.: >> /opt/yocto-armv7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -c -include .pch/Qt5Network -pipe -march=armv7-a -mfpu=neon -DLINUX=1 -mfloat-abi=hard --sysroot=/opt/yocto-armv7/sysroots/armv7ahf-neon-poky-linux-gnueabi -g -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Werror -Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow -D_REENTRANT -fPIC -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DQT_USE_SYSTEM_PROXIES -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_NETWORK_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB -I. -Ikernel -I../../include -I../../include/QtNetwork -I../../include/QtNetwork/5.11.0 -I../../include/QtNetw >> ork/5.11.0/QtNetwork -I../../include/QtCore/5.11.0 -I../../include/QtCore/5.11.0/QtCore -I../../include/QtCore -I.moc -I../../mkspecs/devices/linux-imx7-g++ -o .obj/qnetworkinterface_linux.o kernel/qnetworkinterface_linux.cpp >> kernel/qnetworkinterface_linux.cpp: In instantiation of ‘void {anonymous}::ProcessNetlinkRequest::operator()(int, nlmsghdr*, char*, size_t, Lambda&&) [with Lambda = getInterfaces(int, char*)::; size_t = unsigned int]’: >> kernel/qnetworkinterface_linux.cpp:216:36: required from ‘void {anonymous}::processNetlinkRequest(int, nlmsghdr*, char*, size_t, Lambda&&) [with Lambda = getInterfaces(int, char*)::; size_t = unsigned int]’ >> kernel/qnetworkinterface_linux.cpp:319:6: required from here >> kernel/qnetworkinterface_linux.cpp:161:48: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] >> kernel/qnetworkinterface_linux.cpp: In instantiation of ‘void {anonymous}::ProcessNetlinkRequest::operator()(int, nlmsghdr*, char*, size_t, Lambda&&) [with Lambda = getAddresses(int, char*, QList&)::; size_t = unsigned int]’: >> kernel/qnetworkinterface_linux.cpp:216:36: required from ‘void {anonymous}::processNetlinkRequest(int, nlmsghdr*, char*, size_t, Lambda&&) [with Lambda = getAddresses(int, char*, QList&)::; size_t = unsigned int]’ >> kernel/qnetworkinterface_linux.cpp:423:6: required from here >> kernel/qnetworkinterface_linux.cpp:161:48: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] >> Makefile:26401: recipe for target '.obj/qnetworkinterface_linux.o' failed >> make[2]: *** [.obj/qnetworkinterface_linux.o] Error 1 >> make[1]: *** [sub-network-make_first] Error 2 >> make: *** [sub-src-make_first] Error 2 > > I guess in the first case the system headers changed and in the second case the compiler changed. Do you actually test machine configuration changes against the current state of Qt before you switch them live? I think that should be done and any fixes to Qt for the new configuration should be applied before the configuration goes live. > > br, > Ulf > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Jake.Petroules at qt.io Thu Dec 21 17:25:02 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 21 Dec 2017 16:25:02 +0000 Subject: [Development] About the presence of /System/Library/Frameworks/Carbon.framework In-Reply-To: <2244428.fJXqf0c1a4@portia.local> References: <1939068.kntlJOzske@bola> <479391513853254@web5j.yandex.ru> <2244428.fJXqf0c1a4@portia.local> Message-ID: <69AD1806-F623-4CDF-8DF3-F0ECB3865CC3@qt.io> > On Dec 21, 2017, at 3:57 AM, René J.V. Bertin wrote: > > On Thursday December 21 2017 13:47:34 Konstantin Tokarev wrote: > >> Check uname maybe? > > Possibly: just `uname` returns Darwin. That should certainly work for the desktop OS, but I have no way of checking what it returns on other Apple OSes they all return "Darwin" > (and if the Carbon.framework exists there). it does not :) > > R. > _______________________________________________ > 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 rjvbertin at gmail.com Thu Dec 21 17:53:35 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 21 Dec 2017 17:53:35 +0100 Subject: [Development] About the presence of /System/Library/Frameworks/Carbon.framework In-Reply-To: <69AD1806-F623-4CDF-8DF3-F0ECB3865CC3@qt.io> References: <1939068.kntlJOzske@bola> <2244428.fJXqf0c1a4@portia.local> <69AD1806-F623-4CDF-8DF3-F0ECB3865CC3@qt.io> Message-ID: <1928301.43UsiJyT0k@portia.local> On Thursday December 21 2017 16:25:02 Jake Petroules wrote: > > Possibly: just `uname` returns Darwin. That should certainly work for the desktop OS, but I have no way of checking what it returns on other Apple OSes > > they all return "Darwin" Figures... > > (and if the Carbon.framework exists there). > > it does not :) I'm pretty sure `sysctl hw.model` doesn't return anything that starts with Mac when you're not on a Mac though? R From annulen at yandex.ru Thu Dec 21 18:19:03 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 21 Dec 2017 20:19:03 +0300 Subject: [Development] About the presence of /System/Library/Frameworks/Carbon.framework In-Reply-To: <1928301.43UsiJyT0k@portia.local> References: <1939068.kntlJOzske@bola> <2244428.fJXqf0c1a4@portia.local> <69AD1806-F623-4CDF-8DF3-F0ECB3865CC3@qt.io> <1928301.43UsiJyT0k@portia.local> Message-ID: <219831513876743@web27g.yandex.ru> 21.12.2017, 19:53, "René J.V. Bertin" : > On Thursday December 21 2017 16:25:02 Jake Petroules wrote: > >>  > Possibly: just `uname` returns Darwin. That should certainly work for the desktop OS, but I have no way of checking what it returns on other Apple OSes >> >>  they all return "Darwin" > > Figures... > >>  > (and if the Carbon.framework exists there). >> >>  it does not :) > > I'm pretty sure `sysctl hw.model` doesn't return anything that starts with Mac when you're not on a Mac though? Are you trying to distinguish it from PureDarwin? > > R -- Regards, Konstantin From rjvbertin at gmail.com Thu Dec 21 19:12:20 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 21 Dec 2017 19:12:20 +0100 Subject: [Development] About the presence of /System/Library/Frameworks/Carbon.framework In-Reply-To: <219831513876743@web27g.yandex.ru> References: <1939068.kntlJOzske@bola> <1928301.43UsiJyT0k@portia.local> <219831513876743@web27g.yandex.ru> Message-ID: <5490740.Q8hNgKOgoa@bola> On Thursday December 21 2017 20:19:03 Konstantin Tokarev wrote: >> I'm pretty sure `sysctl hw.model` doesn't return anything that starts with Mac when you're not on a Mac though? > >Are you trying to distinguish it from PureDarwin? No, in theory that command should always return the identification of the actual hardware it's running on. (I thought that project was dead, apparently not, cool, but will Qt support it?). R. From annulen at yandex.ru Thu Dec 21 19:37:05 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 21 Dec 2017 21:37:05 +0300 Subject: [Development] Reporting errors for powershell scripts executed by Coin Message-ID: <296601513881425@web10o.yandex.ru> Hi all, AFAIU, some time ago Coin considered ps1 script to be failed its exit code was non-null (e.g, Exit(1) certainly aborted further provisioning process). Now I see that Exit(1) is ignored (see [1]). What is the correct way now, throw exception? [1] https://testresults.qt.io/coin/api/results/provisioning/qtci-windows-10-x86_64-10-f8e8db/provision_1513869138/log.txt.gz Words "conan exited with code 1" are printed before script does Exit(1) -- Regards, Konstantin From thiago.macieira at intel.com Thu Dec 21 20:58:50 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 21 Dec 2017 17:58:50 -0200 Subject: [Development] About the presence of /System/Library/Frameworks/Carbon.framework In-Reply-To: <1928301.43UsiJyT0k@portia.local> References: <1939068.kntlJOzske@bola> <69AD1806-F623-4CDF-8DF3-F0ECB3865CC3@qt.io> <1928301.43UsiJyT0k@portia.local> Message-ID: <5032185.41uXECoAhE@tjmaciei-mobl1> On quinta-feira, 21 de dezembro de 2017 14:53:35 -02 René J.V. Bertin wrote: > I'm pretty sure `sysctl hw.model` doesn't return anything that starts with > Mac when you're not on a Mac though? Entirely irrelevant, since it would tell you what you're running on, not what you're compiling for. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tpham3783 at gmail.com Thu Dec 21 21:30:49 2017 From: tpham3783 at gmail.com (Toan Pham) Date: Thu, 21 Dec 2017 15:30:49 -0500 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <1624810.gLDOA3jiHc@tjmaciei-mobl1> <3308126.piR9Nt2yrh@twilight> Message-ID: Hi all, How do I add an include path (/usr/X11/include) to chromium build. Not sure why qtwebengine did not detect include path /usr/X11/include before starting the build. thanks [1878/11462] CXX obj/skia/skia/SkFontConfigInterface_direct.o FAILED: obj/skia/skia/SkFontConfigInterface_direct.o /TOOLCHAIN/build/nicebox-9.0-trunk-nicebox-x86-pentium4-linux/TOOLCHAIN/tools.chroot/wrapper/g++ -MMD -MF obj/skia/skia/SkFontConfigInterface_direct.o.d -DV8_DEPRECATION_WARNINGS -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC -DDISABLE_NACL -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS -DSK_HAS_PNG_LIBRARY -DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY -DSK_SUPPORT_GPU=1 -DSK_GAMMA_EXPONENT=1.2 -DSK_GAMMA_CONTRAST=0.2 -DSK_DEFAULT_FONT_CACHE_LIMIT=20971520 -DUSE_LIBJPEG_TURBO=1 -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -Igen -I../../3rdparty/chromium -I../../3rdparty/chromium/skia/config -I../../3rdparty/chromium/skia/ext -I../../3rdparty/chromium/third_party/skia/include/c -I../../3rdparty/chromium/third_party/skia/include/config -I../../3rdparty/chromium/third_party/skia/include/core -I../../3rdparty/chromium/third_party/skia/include/effects -I../../3rdparty/chromium/third_party/skia/include/encode -I../../3rdparty/chromium/third_party/skia/include/images -I../../3rdparty/chromium/third_party/skia/include/lazy -I../../3rdparty/chromium/third_party/skia/include/pathops -I../../3rdparty/chromium/third_party/skia/include/pdf -I../../3rdparty/chromium/third_party/skia/include/pipe -I../../3rdparty/chromium/third_party/skia/include/ports -I../../3rdparty/chromium/third_party/skia/include/utils -I../../3rdparty/chromium/third_party/skia/third_party/vulkan -I../../3rdparty/chromium/third_party/skia/include/gpu -I../../3rdparty/chromium/third_party/skia/src/gpu -I../../3rdparty/chromium/third_party/skia/src/sksl -I../../3rdparty/chromium/third_party/skia/include/private -I../../3rdparty/chromium/third_party/skia/include/client/android -I../../3rdparty/chromium/third_party/skia/src/codec -I../../3rdparty/chromium/third_party/skia/src/core -I../../3rdparty/chromium/third_party/skia/src/image -I../../3rdparty/chromium/third_party/skia/src/images -I../../3rdparty/chromium/third_party/skia/src/opts -I../../3rdparty/chromium/third_party/skia/src/pdf -I../../3rdparty/chromium/third_party/skia/src/ports -I../../3rdparty/chromium/third_party/skia/src/shaders -I../../3rdparty/chromium/third_party/skia/src/shaders/gradients -I../../3rdparty/chromium/third_party/skia/src/sfnt -I../../3rdparty/chromium/third_party/skia/src/utils -I../../3rdparty/chromium/third_party/skia/src/lazy -I../../3rdparty/chromium/third_party/skia/src/effects/gradients -I../../3rdparty/chromium/third_party/libwebp/src -I/usr/include/freetype2 -I../../3rdparty/chromium/third_party/libjpeg_turbo -I../../3rdparty/chromium/third_party/libpng -I../../3rdparty/chromium/third_party/zlib -I../../3rdparty/chromium/third_party/icu/source/common -I../../3rdparty/chromium/third_party/icu/source/i18n -I../../3rdparty/chromium/third_party/sfntly/src/cpp/src -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -funwind-tables -fPIC -pipe -pthread -m32 -msse2 -mfpmath=sse -mmmx -fomit-frame-pointer -g0 -fvisibility=hidden -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections -std=gnu++11 -fno-rtti -fno-exceptions -fvisibility-inlines-hidden -Wno-narrowing -c ../../3rdparty/chromium/third_party/skia/src/ports/SkFontConfigInterface_direct.cpp -o obj/skia/skia/SkFontConfigInterface_direct.o In file included from ../../3rdparty/chromium/third_party/skia/src/ports/SkFontConfigInterface_direct.cpp:13:0: ../../3rdparty/chromium/third_party/skia/src/ports/SkFontConfigInterface_direct.h:12:35: fatal error: fontconfig/fontconfig.h: No such file or directory #include ^ compilation terminated. [1887/11462] CXX obj/skia/skia/SkSLSPIRVCodeGenerator.o ninja: build stopped: subcommand failed. make[3]: *** [run_ninja] Error 1 make[3]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core' make[2]: *** [sub-gn_run-pro-make_first] Error 2 make[2]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core' make[1]: *** [sub-core-make_first] Error 2 make[1]: Leaving directory `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src' On Tue, Dec 19, 2017 at 4:15 PM, Toan Pham wrote: > Hi all, > > I just found out that the build failed while running this command in > qtwebengine/src/core: > > /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere- > src-5.10.0/qtwebengine/src/3rdparty/ninja/ninja -C > /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere- > src-5.10.0/qtwebengine/src/core/release QtWebEngineCore > > > I was able to resolve by changing to the release folder (see above) and > then ran the same command, then webengine started to compile. Obviously, > something was wrong w/ the t2 sandbox because ninja could not run getdir() > or chdir(). This may be a t2 build, so i will report it to their mailing > list. thank you for all your support. > > > TP > > > On Tue, Dec 19, 2017 at 12:16 PM, Toan Pham wrote: > >> >> >> Here is brief update on my 32bit build: >> >> >> 1. 32bit build inside lxc container - code built successfully, >> qtwebengine worked perfectly. The only problem w/ this one is that it does >> not use compatible glibc library as my target board. >> >> 2. 32bit build inside t2 sandbox - I got the builder to use internal >> ninja tool. However, I now faced w/ the error below: >> BTW, t2 sandbox is a chroot build environment for building native >> and also cross root filesystem. One major advantage of using it because it >> completely isolates my development machine from the build environment after >> the initial toolchain stage. I am just wondering if that was the reason >> why ninja failed, as seen in the getcwd error! >> >> >> /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >> 10.0/qtwebengine/src/3rdparty/ninja/ninja -C >> /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >> 10.0/qtwebengine/src/core/release QtWebEngineCore >> ninja: Entering directory `/TOOLCHAIN/loop/target/nicebo >> x/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release' >> [1/21229] STAMP obj/third_party/webrtc/modules >> /audio_coding/isac_fix_common.stamp >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> [2/21229] STAMP obj/device/sensors/public/inte >> rfaces/interfaces__type_mappings.inputdeps.stamp >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> [3/21229] STAMP obj/media/midi/mojo_blink__type_mappings.inputdeps.stamp >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> [4/21229] ACTION //extensions/features:features(/TOOLCHAIN/loop/target/ >> nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/ >> toolchain:target) >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> [5/21229] STAMP obj/extensions/features/features.stamp >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> [6/21229] COPY ../../3rdparty/chromium/third_ >> party/WebKit/Source/devtools/front_end/Images/accelerometer-bottom.png >> resources/inspector/Images/accelerometer-bottom.png >> FAILED: resources/inspector/Images/accelerometer-bottom.png >> ln -f ../../3rdparty/chromium/third_party/WebKit/Source/devtools/f >> ront_end/Images/accelerometer-bottom.png resources/inspector/Images/accelerometer-bottom.png >> 2>/dev/null || (rm -rf resources/inspector/Images/accelerometer-bottom.png >> && cp -af ../../3rdparty/chromium/third_party/WebKit/Source/devtools/f >> ront_end/Images/accelerometer-bottom.png resources/inspector/Images/acc >> elerometer-bottom.png) >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> cp: cannot create regular file `/TOOLCHAIN/target/nicebox/san >> dbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/resources >> /inspector/Images/accelerometer-bottom.png': No such file or directory >> [7/21229] COPY ../../3rdparty/chromium/third_ >> party/WebKit/Source/devtools/front_end/emulated_devices/goog...5x-vertical-keyboard-1x.png >> resources/inspector/emulated_devices/google-nexus-5x-vertica >> l-keyboard-1x.pn >> FAILED: resources/inspector/emulated_devices/google-nexus-5x-vertica >> l-keyboard-1x.png >> ln -f ../../3rdparty/chromium/third_party/WebKit/Source/devtools/f >> ront_end/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png >> resources/inspector/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png >> 2>/dev/null || (rm -rf resources/inspector/emulated_d >> evices/google-nexus-5x-vertical-keyboard-1x.png && cp -af >> ../../3rdparty/chromium/third_party/WebKit/Source/devtools/f >> ront_end/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png >> resources/inspector/emulated_devices/google-nexus-5x-vertica >> l-keyboard-1x.png) >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> cp: cannot create regular file `/TOOLCHAIN/target/nicebox/san >> dbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/resources >> /inspector/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png': >> No such file or directory >> [8/21229] ACTION //media/midi:mojo_blink__type_ >> mappings(/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywher >> e-src-5.10.0/qtwebengine/src/toolchain:target) >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> [9/21229] CXX obj/mojo/public/c/system/system/thunks.o >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> [10/21229] CXX obj/crypto/crypto/random.o >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> [11/21229] CXX obj/crypto/crypto/p224.o >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> [12/21229] CXX obj/crypto/crypto/p224_spake.o >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> [13/21229] CXX obj/media/shared_memory_support/audio_point.o >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> [14/21229] CXX obj/crypto/crypto/symmetric_key.o >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> [15/21229] CXX obj/crypto/crypto/sha2.o >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> shell-init: error retrieving current directory: getcwd: cannot access >> parent directories: Inappropriate ioctl for device >> ninja: build stopped: subcommand failed. >> make[4]: *** [run_ninja] Error 1 >> make[4]: Leaving directory `/TOOLCHAIN/loop/target/nicebo >> x/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core' >> make[3]: *** [sub-gn_run-pro-make_first] Error 2 >> make[3]: Leaving directory `/TOOLCHAIN/loop/target/nicebo >> x/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core' >> make[2]: *** [sub-core-make_first] Error 2 >> make[2]: Leaving directory `/TOOLCHAIN/loop/target/nicebo >> x/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src' >> make[1]: *** [sub-src-make_first] Error 2 >> make[1]: Leaving directory `/TOOLCHAIN/loop/target/nicebo >> x/sandbox/qt-everywhere-src-5.10.0/qtwebengine' >> >> >> >> >> >> On Mon, Dec 18, 2017 at 2:14 PM, Allan Sandfeld Jensen >> wrote: >> >>> On Montag, 18. Dezember 2017 18:53:55 CET Toan Pham wrote: >>> > "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >>> 10.0/qtwebengine >>> > /src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 45, in >>> > check_call >>> > subprocess.check_call(cmd, cwd=GN_ROOT, **kwargs) >>> > File "/usr/lib/python2.7/subprocess.py", line 535, in check_call >>> > retcode = call(*popenargs, **kwargs) >>> > File "/usr/lib/python2.7/subprocess.py", line 522, in call >>> > return Popen(*popenargs, **kwargs).wait() >>> > File "/usr/lib/python2.7/subprocess.py", line 709, in __init__ >>> > errread, errwrite) >>> > File "/usr/lib/python2.7/subprocess.py", line 1326, in >>> _execute_child >>> > raise child_exception >>> > OSError: [Errno 2] No such file or directory >>> > Project ERROR: GN build error! >>> > make[3]: *** [sub-gn-pro-make_first] Error 3 >>> > make[3]: Leaving directory >>> > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >>> 10.0/qtwebengine >>> > /src/buildtools' make[2]: *** [sub-buildtools-make_first] Error 2 >>> > make[2]: Leaving directory >>> > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >>> 10.0/qtwebengine >>> > /src' make[1]: *** [sub-src-make_first] Error 2 >>> > make[1]: Leaving directory >>> > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >>> 10.0/qtwebengine >>> > ' >>> > >>> > >>> > >>> > Please let me know if you know what went wrong w/ the second build. >>> > >>> > >>> Looks like it expects ninja to be installed, but cant launch it. Check >>> your >>> configure output and see if it detected system ninja and you have ninja >>> installed. >>> >>> 'Allan >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpham3783 at gmail.com Thu Dec 21 21:57:15 2017 From: tpham3783 at gmail.com (Toan Pham) Date: Thu, 21 Dec 2017 15:57:15 -0500 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <1624810.gLDOA3jiHc@tjmaciei-mobl1> <3308126.piR9Nt2yrh@twilight> Message-ID: Sorry for so much email noise, On my t2 sandbox environment, It only has 3G of RAM and that webengine build stopped because it ran out of memory. Does anyone know the minimal memory requirement to build qt w/ webengine. thanks, [10013] 0 10013 1785 102 1 0 0 sshd [10015] 0 10015 965 74 7 0 0 bash [10019] 0 10019 1785 93 2 0 0 sshd [10023] 0 10023 965 75 7 0 0 bash [29587] 0 29587 923 36 0 0 0 debug.sh [29593] 0 29593 935 245 1 0 0 bash [24417] 0 24417 923 34 0 0 0 debug.sh [24418] 0 24418 935 242 1 0 0 bash [32263] 0 32263 2441 1961 2 0 0 make [32265] 0 32265 663 60 3 0 0 sh [32267] 0 32267 2428 1971 4 0 0 make [32285] 0 32285 663 59 5 0 0 sh [32287] 0 32287 2355 1889 6 0 0 make [32294] 0 32294 663 60 7 0 0 sh [32296] 0 32296 2408 1952 0 0 0 make [32297] 0 32297 663 60 1 0 0 sh [32298] 0 32298 16109 15287 2 0 0 ninja [ 2599] 0 2599 635 39 3 0 0 g++ [ 2601] 0 2601 104441 97898 1 0 0 cc1plus [ 2602] 0 2602 1337 638 7 0 0 as [ 2607] 0 2607 635 38 3 0 0 g++ [ 2609] 0 2609 110143 103510 1 0 0 cc1plus [ 2610] 0 2610 1337 638 5 0 0 as [ 2611] 0 2611 635 38 4 0 0 g++ [ 2613] 0 2613 106617 100108 1 0 0 cc1plus [ 2614] 0 2614 1337 638 7 0 0 as [ 2615] 0 2615 635 39 4 0 0 g++ [ 2617] 0 2617 106756 100048 1 0 0 cc1plus [ 2618] 0 2618 1337 637 5 0 0 as [ 2623] 0 2623 635 39 3 0 0 g++ [ 2625] 0 2625 96877 90704 1 0 0 cc1plus [ 2626] 0 2626 1337 638 5 0 0 as Out of memory: Kill process 2609 (cc1plus) score 84 or sacrifice child Killed process 2609 (cc1plus) total-vm:440572kB, anon-rss:413632kB, file-rss:408kB On Thu, Dec 21, 2017 at 3:30 PM, Toan Pham wrote: > > Hi all, > > > How do I add an include path (/usr/X11/include) to chromium build. > > Not sure why qtwebengine did not detect include path /usr/X11/include > before starting the build. thanks > > > > > [1878/11462] CXX obj/skia/skia/SkFontConfigInterface_direct.o > FAILED: obj/skia/skia/SkFontConfigInterface_direct.o > /TOOLCHAIN/build/nicebox-9.0-trunk-nicebox-x86-pentium4- > linux/TOOLCHAIN/tools.chroot/wrapper/g++ -MMD -MF obj/skia/skia/ > SkFontConfigInterface_direct.o.d -DV8_DEPRECATION_WARNINGS -DUSE_UDEV > -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC -DDISABLE_NACL > -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL > -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED -DTOOLKIT_QT > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNDEBUG > -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DSK_IGNORE_LINEONLY_AA_CONVEX_PATH_OPTS > -DSK_HAS_PNG_LIBRARY -DSK_HAS_WEBP_LIBRARY -DSK_HAS_JPEG_LIBRARY > -DSK_SUPPORT_GPU=1 -DSK_GAMMA_EXPONENT=1.2 -DSK_GAMMA_CONTRAST=0.2 > -DSK_DEFAULT_FONT_CACHE_LIMIT=20971520 -DUSE_LIBJPEG_TURBO=1 > -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DU_STATIC_IMPLEMENTATION > -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -Igen > -I../../3rdparty/chromium -I../../3rdparty/chromium/skia/config > -I../../3rdparty/chromium/skia/ext -I../../3rdparty/chromium/third_party/skia/include/c > -I../../3rdparty/chromium/third_party/skia/include/config > -I../../3rdparty/chromium/third_party/skia/include/core > -I../../3rdparty/chromium/third_party/skia/include/effects > -I../../3rdparty/chromium/third_party/skia/include/encode > -I../../3rdparty/chromium/third_party/skia/include/images > -I../../3rdparty/chromium/third_party/skia/include/lazy > -I../../3rdparty/chromium/third_party/skia/include/pathops > -I../../3rdparty/chromium/third_party/skia/include/pdf > -I../../3rdparty/chromium/third_party/skia/include/pipe > -I../../3rdparty/chromium/third_party/skia/include/ports > -I../../3rdparty/chromium/third_party/skia/include/utils > -I../../3rdparty/chromium/third_party/skia/third_party/vulkan > -I../../3rdparty/chromium/third_party/skia/include/gpu > -I../../3rdparty/chromium/third_party/skia/src/gpu > -I../../3rdparty/chromium/third_party/skia/src/sksl > -I../../3rdparty/chromium/third_party/skia/include/private > -I../../3rdparty/chromium/third_party/skia/include/client/android > -I../../3rdparty/chromium/third_party/skia/src/codec > -I../../3rdparty/chromium/third_party/skia/src/core > -I../../3rdparty/chromium/third_party/skia/src/image > -I../../3rdparty/chromium/third_party/skia/src/images > -I../../3rdparty/chromium/third_party/skia/src/opts > -I../../3rdparty/chromium/third_party/skia/src/pdf > -I../../3rdparty/chromium/third_party/skia/src/ports > -I../../3rdparty/chromium/third_party/skia/src/shaders > -I../../3rdparty/chromium/third_party/skia/src/shaders/gradients > -I../../3rdparty/chromium/third_party/skia/src/sfnt > -I../../3rdparty/chromium/third_party/skia/src/utils > -I../../3rdparty/chromium/third_party/skia/src/lazy > -I../../3rdparty/chromium/third_party/skia/src/effects/gradients > -I../../3rdparty/chromium/third_party/libwebp/src > -I/usr/include/freetype2 -I../../3rdparty/chromium/third_party/libjpeg_turbo > -I../../3rdparty/chromium/third_party/libpng -I../../3rdparty/chromium/third_party/zlib > -I../../3rdparty/chromium/third_party/icu/source/common > -I../../3rdparty/chromium/third_party/icu/source/i18n > -I../../3rdparty/chromium/third_party/sfntly/src/cpp/src > -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector > -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= > -funwind-tables -fPIC -pipe -pthread -m32 -msse2 -mfpmath=sse -mmmx > -fomit-frame-pointer -g0 -fvisibility=hidden -Wno-unused-local-typedefs > -Wno-maybe-uninitialized -Wno-missing-field-initializers > -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections > -std=gnu++11 -fno-rtti -fno-exceptions -fvisibility-inlines-hidden > -Wno-narrowing -c ../../3rdparty/chromium/third_party/skia/src/ports/ > SkFontConfigInterface_direct.cpp -o obj/skia/skia/ > SkFontConfigInterface_direct.o > In file included from ../../3rdparty/chromium/third_party/skia/src/ports/ > SkFontConfigInterface_direct.cpp:13:0: > ../../3rdparty/chromium/third_party/skia/src/ports/ > SkFontConfigInterface_direct.h:12:35: fatal error: > fontconfig/fontconfig.h: No such file or directory > #include > ^ > compilation terminated. > [1887/11462] CXX obj/skia/skia/SkSLSPIRVCodeGenerator.o > ninja: build stopped: subcommand failed. > make[3]: *** [run_ninja] Error 1 > make[3]: Leaving directory `/TOOLCHAIN/loop/target/ > nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core' > make[2]: *** [sub-gn_run-pro-make_first] Error 2 > make[2]: Leaving directory `/TOOLCHAIN/loop/target/ > nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core' > make[1]: *** [sub-core-make_first] Error 2 > make[1]: Leaving directory `/TOOLCHAIN/loop/target/ > nicebox/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src' > > > On Tue, Dec 19, 2017 at 4:15 PM, Toan Pham wrote: > >> Hi all, >> >> I just found out that the build failed while running this command in >> qtwebengine/src/core: >> >> /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >> 10.0/qtwebengine/src/3rdparty/ninja/ninja -C >> /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >> 10.0/qtwebengine/src/core/release QtWebEngineCore >> >> >> I was able to resolve by changing to the release folder (see above) and >> then ran the same command, then webengine started to compile. Obviously, >> something was wrong w/ the t2 sandbox because ninja could not run getdir() >> or chdir(). This may be a t2 build, so i will report it to their mailing >> list. thank you for all your support. >> >> >> TP >> >> >> On Tue, Dec 19, 2017 at 12:16 PM, Toan Pham wrote: >> >>> >>> >>> Here is brief update on my 32bit build: >>> >>> >>> 1. 32bit build inside lxc container - code built successfully, >>> qtwebengine worked perfectly. The only problem w/ this one is that it does >>> not use compatible glibc library as my target board. >>> >>> 2. 32bit build inside t2 sandbox - I got the builder to use internal >>> ninja tool. However, I now faced w/ the error below: >>> BTW, t2 sandbox is a chroot build environment for building native >>> and also cross root filesystem. One major advantage of using it because it >>> completely isolates my development machine from the build environment after >>> the initial toolchain stage. I am just wondering if that was the reason >>> why ninja failed, as seen in the getcwd error! >>> >>> >>> /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.1 >>> 0.0/qtwebengine/src/3rdparty/ninja/ninja -C >>> /TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5.1 >>> 0.0/qtwebengine/src/core/release QtWebEngineCore >>> ninja: Entering directory `/TOOLCHAIN/loop/target/nicebo >>> x/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/release' >>> [1/21229] STAMP obj/third_party/webrtc/modules >>> /audio_coding/isac_fix_common.stamp >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> [2/21229] STAMP obj/device/sensors/public/inte >>> rfaces/interfaces__type_mappings.inputdeps.stamp >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> [3/21229] STAMP obj/media/midi/mojo_blink__type_mappings.inputdeps.stamp >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> [4/21229] ACTION //extensions/features:features >>> (/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >>> 10.0/qtwebengine/src/toolchain:target) >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> [5/21229] STAMP obj/extensions/features/features.stamp >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> [6/21229] COPY ../../3rdparty/chromium/third_ >>> party/WebKit/Source/devtools/front_end/Images/accelerometer-bottom.png >>> resources/inspector/Images/accelerometer-bottom.png >>> FAILED: resources/inspector/Images/accelerometer-bottom.png >>> ln -f ../../3rdparty/chromium/third_party/WebKit/Source/devtools/f >>> ront_end/Images/accelerometer-bottom.png resources/inspector/Images/accelerometer-bottom.png >>> 2>/dev/null || (rm -rf resources/inspector/Images/accelerometer-bottom.png >>> && cp -af ../../3rdparty/chromium/third_party/WebKit/Source/devtools/f >>> ront_end/Images/accelerometer-bottom.png resources/inspector/Images/acc >>> elerometer-bottom.png) >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> cp: cannot create regular file `/TOOLCHAIN/target/nicebox/san >>> dbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/resources >>> /inspector/Images/accelerometer-bottom.png': No such file or directory >>> [7/21229] COPY ../../3rdparty/chromium/third_ >>> party/WebKit/Source/devtools/front_end/emulated_devices/goog...5x-vertical-keyboard-1x.png >>> resources/inspector/emulated_devices/google-nexus-5x-vertica >>> l-keyboard-1x.pn >>> FAILED: resources/inspector/emulated_devices/google-nexus-5x-vertica >>> l-keyboard-1x.png >>> ln -f ../../3rdparty/chromium/third_party/WebKit/Source/devtools/f >>> ront_end/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png >>> resources/inspector/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png >>> 2>/dev/null || (rm -rf resources/inspector/emulated_d >>> evices/google-nexus-5x-vertical-keyboard-1x.png && cp -af >>> ../../3rdparty/chromium/third_party/WebKit/Source/devtools/f >>> ront_end/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png >>> resources/inspector/emulated_devices/google-nexus-5x-vertica >>> l-keyboard-1x.png) >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> cp: cannot create regular file `/TOOLCHAIN/target/nicebox/san >>> dbox/qt-everywhere-src-5.10.0/qtwebengine/src/core/resources >>> /inspector/emulated_devices/google-nexus-5x-vertical-keyboard-1x.png': >>> No such file or directory >>> [8/21229] ACTION //media/midi:mojo_blink__type_ >>> mappings(/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywher >>> e-src-5.10.0/qtwebengine/src/toolchain:target) >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> [9/21229] CXX obj/mojo/public/c/system/system/thunks.o >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> [10/21229] CXX obj/crypto/crypto/random.o >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> [11/21229] CXX obj/crypto/crypto/p224.o >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> [12/21229] CXX obj/crypto/crypto/p224_spake.o >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> [13/21229] CXX obj/media/shared_memory_support/audio_point.o >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> [14/21229] CXX obj/crypto/crypto/symmetric_key.o >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> [15/21229] CXX obj/crypto/crypto/sha2.o >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> shell-init: error retrieving current directory: getcwd: cannot access >>> parent directories: Inappropriate ioctl for device >>> ninja: build stopped: subcommand failed. >>> make[4]: *** [run_ninja] Error 1 >>> make[4]: Leaving directory `/TOOLCHAIN/loop/target/nicebo >>> x/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core' >>> make[3]: *** [sub-gn_run-pro-make_first] Error 2 >>> make[3]: Leaving directory `/TOOLCHAIN/loop/target/nicebo >>> x/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src/core' >>> make[2]: *** [sub-core-make_first] Error 2 >>> make[2]: Leaving directory `/TOOLCHAIN/loop/target/nicebo >>> x/sandbox/qt-everywhere-src-5.10.0/qtwebengine/src' >>> make[1]: *** [sub-src-make_first] Error 2 >>> make[1]: Leaving directory `/TOOLCHAIN/loop/target/nicebo >>> x/sandbox/qt-everywhere-src-5.10.0/qtwebengine' >>> >>> >>> >>> >>> >>> On Mon, Dec 18, 2017 at 2:14 PM, Allan Sandfeld Jensen >> > wrote: >>> >>>> On Montag, 18. Dezember 2017 18:53:55 CET Toan Pham wrote: >>>> > "/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >>>> 10.0/qtwebengine >>>> > /src/3rdparty/chromium/tools/gn/bootstrap/bootstrap.py", line 45, in >>>> > check_call >>>> > subprocess.check_call(cmd, cwd=GN_ROOT, **kwargs) >>>> > File "/usr/lib/python2.7/subprocess.py", line 535, in check_call >>>> > retcode = call(*popenargs, **kwargs) >>>> > File "/usr/lib/python2.7/subprocess.py", line 522, in call >>>> > return Popen(*popenargs, **kwargs).wait() >>>> > File "/usr/lib/python2.7/subprocess.py", line 709, in __init__ >>>> > errread, errwrite) >>>> > File "/usr/lib/python2.7/subprocess.py", line 1326, in >>>> _execute_child >>>> > raise child_exception >>>> > OSError: [Errno 2] No such file or directory >>>> > Project ERROR: GN build error! >>>> > make[3]: *** [sub-gn-pro-make_first] Error 3 >>>> > make[3]: Leaving directory >>>> > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >>>> 10.0/qtwebengine >>>> > /src/buildtools' make[2]: *** [sub-buildtools-make_first] Error 2 >>>> > make[2]: Leaving directory >>>> > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >>>> 10.0/qtwebengine >>>> > /src' make[1]: *** [sub-src-make_first] Error 2 >>>> > make[1]: Leaving directory >>>> > `/TOOLCHAIN/loop/target/nicebox/sandbox/qt-everywhere-src-5. >>>> 10.0/qtwebengine >>>> > ' >>>> > >>>> > >>>> > >>>> > Please let me know if you know what went wrong w/ the second build. >>>> > >>>> > >>>> Looks like it expects ninja to be installed, but cant launch it. Check >>>> your >>>> configure output and see if it detected system ninja and you have ninja >>>> installed. >>>> >>>> 'Allan >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Dec 22 00:39:57 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 21 Dec 2017 21:39:57 -0200 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: Message-ID: <3740686.9mK7ZYsy0s@tjmaciei-mobl1> On quinta-feira, 21 de dezembro de 2017 18:57:15 -02 Toan Pham wrote: > On my t2 sandbox environment, It only has 3G of RAM and that webengine > build stopped because it ran out of memory. > > Does anyone know the minimal memory requirement to build qt w/ webengine. To build? At least 8 GB of RAM and please use a 64-bit toolchain. You may compile for 32-bit, but you need to use a 64-bit linker executable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Fri Dec 22 01:00:26 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 Dec 2017 01:00:26 +0100 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine References: <3740686.9mK7ZYsy0s@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > To build? At least 8 GB of RAM and please use a 64-bit toolchain. You may > compile for 32-bit, but you need to use a 64-bit linker executable. I haven't tried 5.10.0 yet, but 5.9.3 built fine with the 32-bit toolchains we have in our Fedora 32-bit buildroots (i686 and armv7hl). All packages in Fedora are natively built, not cross-built, which means that 32-bit binaries will necessarily be built with a 32-bit linker. If this stops/stopped working, we will no longer be able to ship QtWebEngine on 32-bit architectures in Fedora. Kevin Kofler From jani.heikkinen at qt.io Fri Dec 22 06:35:10 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 22 Dec 2017 05:35:10 +0000 Subject: [Development] Qt 5.11 feature freeze is getting closer: New submodules in Qt 5.11? Message-ID: Hi all, There is only a bit more than a month to Qt 5.11 feature freeze, see https://wiki.qt.io/Qt_5.11_Release . So at this point we should already know if there will be some new submodule modules in Qt 5.11. We are doing packaging confs etc for 5.11 now so please inform me immediately if there will be some new in. And of course get the new submodule in qt5 as soon as possible; those really needs to be in before we start soft branching! br, Jani From tony.sarajarvi at qt.io Fri Dec 22 08:35:14 2017 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Fri, 22 Dec 2017 07:35:14 +0000 Subject: [Development] CI is suffering from problems In-Reply-To: References: Message-ID: Hi This problem was fixed for now. We have the CI running again since yesterday afternoon. The system needed a cold boot of the server to update all disk related info after our cleanup. Free space etc were reported incorrectly before that. To avoid this, we should never ever let the disk get 100% full, and we have to be more careful with that. Monitoring didn’t help here as we ignored the warnings we received ☹ -T From: Tony Sarajärvi Sent: torstai 21. joulukuuta 2017 14.19 To: development at qt-project.org Subject: CI is suffering from problems Hi You have probably already noticed this, but here’s an email notifying you that we’re on it. Our OpenNebula isn’t able to clone any new virtual machines, complaining that the disk is full even though it isn’t. As said…we continue investigating. Regards, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Fri Dec 22 08:39:46 2017 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Fri, 22 Dec 2017 07:39:46 +0000 Subject: [Development] Gerrit problems fixed (?) Message-ID: Hi again! The gerrit problems we've seen (example below (pardon for top posting with Outlook)) are potentially fixed. The problem was found to be in the AWS VM. Following actions were made to remedy the situation: * Port range increased to allow more connections * Mount options adjusted optimizing file access * I/O scheduler is now 'noop' With these changes the symptoms are for now gone. If they start appearing again, just hit reply to this thread and let's see if we can reproduce and fix it. Thank you, -Tony From: Tony Sarajärvi Sent: keskiviikko 13. joulukuuta 2017 21.39 To: 'development at qt-project.org' Subject: RE: Builds missing qmake? Hi again. Should have told you this as well. When you see this error message coming from the CI: "Could not access requested repository (: RAN: /usr/bin/git --git-dir=/home/vmbuilder/ci-working-dir/git-repos/qt-project/qt/qtwebview --no-pager fetch --tags origin +refs/builds/qtci/5.9/1513182815:refs/builds/qtci/5.9/1513182815 STDOUT: packet_write_wait: Connection to 54.229.21.112 port 29418: Broken pipe fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. STDERR:" It means that Coin is unable to retrieve needed sources from codereview. Again, as of now we don't know the root cause for this. We can produce this even outside Coin, so it's a problem outside our CI. We are investigating where and why the connections are lost. When this happens you don't have to contact us however. Just restage your commit and the next time around the sources might be retrieved. I apologize for the inconvenience -Tony From: Tony Sarajärvi Sent: keskiviikko 13. joulukuuta 2017 11.26 To: 'development at qt-project.org' > Subject: Builds missing qmake? Hi If you stumble upon a problem in your build where the error message says that it can't find qmake, contact us maintaining the CI immediately. It's not a random failure in such that it goes away by restaging a few times. It means that for some reason (still unclear) we have a pointer indicating where the binaries should be, but they aren't. So they are never even uncompressed. But we can't really fail the build on missing artifacts, since we have no way of knowing if those binaries are optional or not. The error above clearly says that qtbase binaries are now uncompressed, hence the missing qmake, but we don't want to hard code all the really dependent packages for every module. Instead, we're trying to figure out why those binaries are missing in the first place. So, qmake missing error -> contact us. We are needed to fix it currently. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Fri Dec 22 09:17:47 2017 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Fri, 22 Dec 2017 08:17:47 +0000 Subject: [Development] Reporting errors for powershell scripts executed by Coin In-Reply-To: <296601513881425@web10o.yandex.ru> References: <296601513881425@web10o.yandex.ru> Message-ID: Hi We ignore the results of PS1 scripts because A) We have bad scripts that try to remove folders that don't exists anymore (should be cleaned) and B) as your example said, if we enabled enforcing of them now, things would break apart (fix needed as well 😝) -T -----Original Message----- From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Konstantin Tokarev Sent: torstai 21. joulukuuta 2017 20.37 To: development at qt-project.org Subject: [Development] Reporting errors for powershell scripts executed by Coin Hi all, AFAIU, some time ago Coin considered ps1 script to be failed its exit code was non-null (e.g, Exit(1) certainly aborted further provisioning process). Now I see that Exit(1) is ignored (see [1]). What is the correct way now, throw exception? [1] https://testresults.qt.io/coin/api/results/provisioning/qtci-windows-10-x86_64-10-f8e8db/provision_1513869138/log.txt.gz Words "conan exited with code 1" are printed before script does Exit(1) -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Fri Dec 22 09:23:22 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 22 Dec 2017 11:23:22 +0300 Subject: [Development] Reporting errors for powershell scripts executed by Coin In-Reply-To: References: <296601513881425@web10o.yandex.ru> Message-ID: <580381513931002@web55o.yandex.ru> > Hi > > We ignore the results of PS1 scripts because A) We have bad scripts that try to remove folders that don't exists anymore (should be cleaned) and B) as your example said, if we enabled enforcing of them now, things would break apart (fix needed as well 😝) B is fixed already, however one VM snapshot had to be manually removed for re-provisioning > > -T > > -----Original Message----- > From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Konstantin Tokarev > Sent: torstai 21. joulukuuta 2017 20.37 > To: development at qt-project.org > Subject: [Development] Reporting errors for powershell scripts executed by Coin > > Hi all, > > AFAIU, some time ago Coin considered ps1 script to be failed its exit code was non-null (e.g, Exit(1) certainly aborted further provisioning process). > > Now I see that Exit(1) is ignored (see [1]). What is the correct way now, throw exception? > > [1] https://testresults.qt.io/coin/api/results/provisioning/qtci-windows-10-x86_64-10-f8e8db/provision_1513869138/log.txt.gz > > Words "conan exited with code 1" are printed before script does Exit(1) > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From tuukka.turunen at qt.io Fri Dec 22 13:22:39 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 22 Dec 2017 12:22:39 +0000 Subject: [Development] Gerrit problems fixed (?) In-Reply-To: References: Message-ID: Excellent, thanks! -- Tuukka From: Tony Sarajärvi Date: Friday, 22 December 2017 at 9.40 To: "development at qt-project.org" Subject: Gerrit problems fixed (?) Hi again! The gerrit problems we’ve seen (example below (pardon for top posting with Outlook)) are potentially fixed. The problem was found to be in the AWS VM. Following actions were made to remedy the situation: - Port range increased to allow more connections - Mount options adjusted optimizing file access - I/O scheduler is now ‘noop’ With these changes the symptoms are for now gone. If they start appearing again, just hit reply to this thread and let’s see if we can reproduce and fix it. Thank you, -Tony From: Tony Sarajärvi Sent: keskiviikko 13. joulukuuta 2017 21.39 To: 'development at qt-project.org' Subject: RE: Builds missing qmake? Hi again. Should have told you this as well. When you see this error message coming from the CI: “Could not access requested repository (: RAN: /usr/bin/git --git-dir=/home/vmbuilder/ci-working-dir/git-repos/qt-project/qt/qtwebview --no-pager fetch --tags origin +refs/builds/qtci/5.9/1513182815:refs/builds/qtci/5.9/1513182815 STDOUT: packet_write_wait: Connection to 54.229.21.112 port 29418: Broken pipe fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. STDERR:” It means that Coin is unable to retrieve needed sources from codereview. Again, as of now we don’t know the root cause for this. We can produce this even outside Coin, so it’s a problem outside our CI. We are investigating where and why the connections are lost. When this happens you don’t have to contact us however. Just restage your commit and the next time around the sources might be retrieved. I apologize for the inconvenience -Tony From: Tony Sarajärvi Sent: keskiviikko 13. joulukuuta 2017 11.26 To: 'development at qt-project.org' > Subject: Builds missing qmake? Hi If you stumble upon a problem in your build where the error message says that it can’t find qmake, contact us maintaining the CI immediately. It’s not a random failure in such that it goes away by restaging a few times. It means that for some reason (still unclear) we have a pointer indicating where the binaries should be, but they aren’t. So they are never even uncompressed. But we can’t really fail the build on missing artifacts, since we have no way of knowing if those binaries are optional or not. The error above clearly says that qtbase binaries are now uncompressed, hence the missing qmake, but we don’t want to hard code all the really dependent packages for every module. Instead, we’re trying to figure out why those binaries are missing in the first place. So, qmake missing error -> contact us. We are needed to fix it currently. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Dec 22 13:25:45 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Dec 2017 10:25:45 -0200 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: References: <3740686.9mK7ZYsy0s@tjmaciei-mobl1> Message-ID: <1579689.60vB0ZmokD@tjmaciei-mobl1> On quinta-feira, 21 de dezembro de 2017 22:00:26 -02 Kevin Kofler wrote: > Thiago Macieira wrote: > > To build? At least 8 GB of RAM and please use a 64-bit toolchain. You may > > compile for 32-bit, but you need to use a 64-bit linker executable. > > I haven't tried 5.10.0 yet, but 5.9.3 built fine with the 32-bit toolchains > we have in our Fedora 32-bit buildroots (i686 and armv7hl). All packages in > Fedora are natively built, not cross-built, which means that 32-bit binaries > will necessarily be built with a 32-bit linker. If this stops/stopped > working, we will no longer be able to ship QtWebEngine on 32-bit > architectures in Fedora. A 32-bit executable is limited to 4 GB of RAM on a 64-bit kernel. If you're running a 32-bit kernel, then the limit drops to 3 GB. At the very least, make sure you're using gold, not ld.bfd. But my recommendation stands, especially for developers. I'm also not asking for a cross-compilation. I'm asking for a native linker that is a 64-bit executable that your 64-bit CPU and 64-bit kernel can execute natively anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Fri Dec 22 13:30:12 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 22 Dec 2017 15:30:12 +0300 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: <1579689.60vB0ZmokD@tjmaciei-mobl1> References: <3740686.9mK7ZYsy0s@tjmaciei-mobl1> <1579689.60vB0ZmokD@tjmaciei-mobl1> Message-ID: <2707441513945812@web4g.yandex.ru> 22.12.2017, 15:26, "Thiago Macieira" : > On quinta-feira, 21 de dezembro de 2017 22:00:26 -02 Kevin Kofler wrote: >>  Thiago Macieira wrote: >>  > To build? At least 8 GB of RAM and please use a 64-bit toolchain. You may >>  > compile for 32-bit, but you need to use a 64-bit linker executable. >> >>  I haven't tried 5.10.0 yet, but 5.9.3 built fine with the 32-bit toolchains >>  we have in our Fedora 32-bit buildroots (i686 and armv7hl). All packages in >>  Fedora are natively built, not cross-built, which means that 32-bit binaries >>  will necessarily be built with a 32-bit linker. If this stops/stopped >>  working, we will no longer be able to ship QtWebEngine on 32-bit >>  architectures in Fedora. > > A 32-bit executable is limited to 4 GB of RAM on a 64-bit kernel. If you're > running a 32-bit kernel, then the limit drops to 3 GB. > > At the very least, make sure you're using gold, not ld.bfd. But my > recommendation stands, especially for developers. > > I'm also not asking for a cross-compilation. I'm asking for a native linker > that is a 64-bit executable that your 64-bit CPU and 64-bit kernel can execute > natively anyway. Well, -m32 is also a kind of cross-compilation. It requires completely different set of dependency packages to be preinstalled. > > -- > 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 albert.astals.cid at kdab.com Fri Dec 22 14:50:01 2017 From: albert.astals.cid at kdab.com (Albert Astals Cid) Date: Fri, 22 Dec 2017 14:50:01 +0100 Subject: [Development] Integrating Common Print Dialog project into Qt In-Reply-To: References: <65A10371-06B6-4437-9EE8-2CD4590A533E@gmail.com> <2773388.sx4n8UKjcV@yoga> Message-ID: <1750756.75W2DSFkXD@yoga> El dijous, 21 de desembre de 2017, a les 10:33:53 CET, Rithvik Patibandla va escriure: > > On 21-Dec-2017, at 2:52 PM, Albert Astals Cid > > wrote: > > > > I see a big-ish problem that is that it uses QtQuick so it can't really go > > into qtbase where the current printing dialog lives, so if this was to be > > accepted the printing module would need to split off from qtbase (no idea > > if that is planned or not). > > This has been one of our main concerns too. At the time of project planning, > we were thinking more about QML support because of the missing printing > support within QML. However, if it is not possible to split the dialog off > qtbase, we could probably redo the QML part and write the UI using QWidget > instead but that would be our last option. > > Looking at the code Advanced.qml seems to be collection of items that > > really don't do anything at all? > > The CUPS backend API doesn’t support all of these options yet. So we just > put up dummy dropdown and we’ll add backend functions to them as soon as > the API supports it. In my opinion showing the user something that does nothing is bad usability and the way to make everyone very unhappy. Best Regards, Albert > > Thanks, > Rithvik -- Albert Astals Cid | albert.astals.cid at 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 - The Qt, C++ and OpenGL Experts From jani.heikkinen at qt.io Fri Dec 22 15:26:40 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 22 Dec 2017 14:26:40 +0000 Subject: [Development] Branching '5.9.4' from '5.9' started Message-ID: Hi all, We have now soft branched '5.9.4' from '5.9' so please start using '5.9.4' for new changes targeting Qt 5.9.4 release. Target is to do final downmerge from '5.9' -> '5.9.4' and finalize branching at the beginning of January 2018 so there should be enough time to finalize ongoing ones in '5.9'. Target is to release Qt 5.9.4 ~ mid January. br, Jani Heikkinen Release Manager From thiago.macieira at intel.com Fri Dec 22 17:34:17 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Dec 2017 14:34:17 -0200 Subject: [Development] 32bit linux build of qt5.10.0 w/ webengine In-Reply-To: <2707441513945812@web4g.yandex.ru> References: <1579689.60vB0ZmokD@tjmaciei-mobl1> <2707441513945812@web4g.yandex.ru> Message-ID: <2126029.WM82Itbiqh@tjmaciei-mobl1> On sexta-feira, 22 de dezembro de 2017 10:30:12 -02 Konstantin Tokarev wrote: > Well, -m32 is also a kind of cross-compilation. It requires completely > different set of dependency packages to be preinstalled. Not exactly. Yes, it requires a different set of packages to be installed, but they're natively installed and can be run on the CPU, without emulation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bartoszpajewski at gmail.com Mon Dec 25 17:00:42 2017 From: bartoszpajewski at gmail.com (Bartosz Pajewski) Date: Mon, 25 Dec 2017 17:00:42 +0100 Subject: [Development] Fwd: [Libraries] Qts libraries recognized as Trojan In-Reply-To: References: Message-ID: Hi, in this week I scanned my PC preventively. My Antivirus recognized Qts libraries as Trojans. I'm enclosing log file for more information. -- Regards Bartosz Pajewski www.bartoit.pl -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20171223105445.log Type: application/octet-stream Size: 7828 bytes Desc: not available URL: From thiago.macieira at intel.com Mon Dec 25 19:33:19 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 25 Dec 2017 16:33:19 -0200 Subject: [Development] Fwd: [Libraries] Qts libraries recognized as Trojan In-Reply-To: References: Message-ID: <9069889.RClNDbLz58@tjmaciei-mobl1> On segunda-feira, 25 de dezembro de 2017 14:00:42 -02 Bartosz Pajewski wrote: > Hi, > in this week I scanned my PC preventively. My Antivirus recognized Qts > libraries as Trojans. > I'm enclosing log file for more information. Try to install again and see if they still produce the same warning. If they do, install on a system known to be clean from infection and compare the checksums for the files your AV reports as problematic. If the problem persists, contact your AV vendor with information about false positives. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Thu Dec 28 19:32:46 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 28 Dec 2017 19:32:46 +0100 Subject: [Development] about the Cocoa/Freetype fontengine Message-ID: <4742033.fg7tE2YJlQ@portia.local> Hi, Are there any plans to evolve the FreeType support on Mac any further, possibly adding FontConfig support so fonts can really be rendered in identical fashion on at least the major Unix platforms? If so, would you consider making it easier to select the FreeType engine? I've been experimenting with this in my customised version of the 5.9 Cocoa QPA: - I've added an env. variable to activate the FreeType engine - I've added a QPlatformNativeInterface::NativeResourceForIntegrationFunction hook that allows toggling between the two engines. For now I've only tested that hook from a platform theme plugin forked from KDE's plasma integration plugin (github.com/RJVB/osx-integration) which applies a set of user settings. The fontengine can be set to FreeType and back to CoreText again without a glitch as long as it hasn't yet been used (IOW, QCocoaIntegration::fontDatabase() hasn't been called yet). It's probably not a good idea to try to change it later on. R. From iamsergio at gmail.com Thu Dec 28 20:46:28 2017 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Thu, 28 Dec 2017 19:46:28 +0000 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: <4742033.fg7tE2YJlQ@portia.local> References: <4742033.fg7tE2YJlQ@portia.local> Message-ID: On Thu, Dec 28, 2017 at 6:32 PM, René J. V. Bertin wrote: > Hi, > > Are there any plans to evolve the FreeType support on Mac any further, possibly > adding FontConfig support so fonts can really be rendered in identical fashion > on at least the major Unix platforms? Hi René, Check the last two comments of https://bugreports.qt.io/browse/QTBUG-42839, there are no plans. I also wouldn't call it "evolving FreeType", as FreeType is independent from the font database. But adding fontconfig support should be quite trivial and wouldn't touch FT code. Regards, Sérgio M. From rjvbertin at gmail.com Thu Dec 28 20:53:51 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 28 Dec 2017 20:53:51 +0100 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: References: <4742033.fg7tE2YJlQ@portia.local> Message-ID: <2125429.zmWqp9U4cN@portia.local> On Thursday December 28 2017 19:46:28 Sérgio Martins wrote: > Check the last two comments of > https://bugreports.qt.io/browse/QTBUG-42839, there are no plans. Oops, sorry, I forgot about that. > I also wouldn't call it "evolving FreeType", as FreeType is > independent from the font database. But that's not what I called it, I called it "evolving support" ;) And I really meant that: making it easier to select FreeType rendering as a system-wide or application-specific default. > But adding fontconfig support should be quite trivial and wouldn't > touch FT code. It used to be trivial to build Qt on Mac with fontconfig enabled (but not actually used anywhere). That's no longer the case in 5.9 so I'm guessing it might be a bit less trivial than you think. FontConfig allows font-specific rendering tweaks, how can it do that without touching FT code in some place or other? R. From iamsergio at gmail.com Thu Dec 28 21:08:38 2017 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Thu, 28 Dec 2017 20:08:38 +0000 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: <2125429.zmWqp9U4cN@portia.local> References: <4742033.fg7tE2YJlQ@portia.local> <2125429.zmWqp9U4cN@portia.local> Message-ID: On Thu, Dec 28, 2017 at 7:53 PM, René J.V. Bertin wrote: > On Thursday December 28 2017 19:46:28 Sérgio Martins wrote: >> But adding fontconfig support should be quite trivial and wouldn't >> touch FT code. > > It used to be trivial to build Qt on Mac with fontconfig enabled (but not actually used anywhere). That's no longer the case in 5.9 so I'm guessing it might be a bit less trivial than you think. > > FontConfig allows font-specific rendering tweaks, how can it do that without touching FT code in some place or other? What I meant is that you don't need to touch FT code when adding fontconfig support to macOS. The code already exists and is cross-platform (even worked on QNX). It's just that it's not being used by cocoa QPA. Regards, Sergio M. From rjvbertin at gmail.com Fri Dec 29 10:07:26 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 29 Dec 2017 10:07:26 +0100 Subject: [Development] about the Cocoa/Freetype fontengine References: <4742033.fg7tE2YJlQ@portia.local> <2125429.zmWqp9U4cN@portia.local> Message-ID: <7850948.X9B33WSh9e@patux.local> Sérgio Martins wrote: > What I meant is that you don't need to touch FT code when adding > fontconfig support to macOS. The code already exists and is > cross-platform (even worked on QNX). It's just that it's not being > used by cocoa QPA. Hmmm, I guess I'll need to have another look then. It had indeed been my hope that this would just be a question of adding a few calls into existing code (after making sure it's included in the build). Now I'll only need to figure out what calls and where to make them. Cheers, René From jeanmichael.celerier at gmail.com Fri Dec 29 10:38:04 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Fri, 29 Dec 2017 10:38:04 +0100 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: <7850948.X9B33WSh9e@patux.local> References: <4742033.fg7tE2YJlQ@portia.local> <2125429.zmWqp9U4cN@portia.local> <7850948.X9B33WSh9e@patux.local> Message-ID: :+1: for being able to use fontconfig everywhere. It's painful to have to make pixel adjustments on each platform because they don't render fonts exactly the same everywhere. Besides, fontconfig with infinality patches honestly gives a beautiful rendering, crispier and yet fuller than everything you can see on othe OSes in my taste. Best, Jean-Michaël On Fri, Dec 29, 2017 at 10:07 AM, René J. V. Bertin wrote: > Sérgio Martins wrote: > > > What I meant is that you don't need to touch FT code when adding > > fontconfig support to macOS. The code already exists and is > > cross-platform (even worked on QNX). It's just that it's not being > > used by cocoa QPA. > > Hmmm, I guess I'll need to have another look then. It had indeed been my > hope > that this would just be a question of adding a few calls into existing code > (after making sure it's included in the build). Now I'll only need to > figure out > what calls and where to make them. > > Cheers, > René > > _______________________________________________ > 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 rjvbertin at gmail.com Fri Dec 29 11:10:17 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 29 Dec 2017 11:10:17 +0100 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> Message-ID: <5740503.SiWtZChDqH@bola> On Friday December 29 2017 10:38:04 Jean-Michaël Celerier wrote: > Besides, fontconfig with infinality patches >honestly gives a beautiful rendering, crispier and yet fuller than >everything you can see on othe OSes in my taste. I agree completely, except - I'm not (yet) convinced that the Infinality patches to FreeType are of any effect on Mac. Fonts rendered with FreeType look fuzzier than with CoreText, which in turn looks fuzzier than fonts rendered with that same FreeType library under X11 (XQuartz). - The stem-darkening change in Qt 5.9 does trigger side-effects with certain fonts when using the FontConfig Ultimate patches and/or config files. For now I've only found this to be the case for the Novarese font (all versions I have of it). Sadly I happen to like that font a lot, including for use in UI elements. Cheers, R. From madigens at gmail.com Fri Dec 29 12:06:58 2017 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Fri, 29 Dec 2017 12:06:58 +0100 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: <5740503.SiWtZChDqH@bola> References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> Message-ID: <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> >> Besides, fontconfig with infinality patches honestly gives a >> beautiful rendering, crispier and yet fuller than everything you >> can see on othe OSes in my taste. > > I agree completely, except - I'm not (yet) convinced that the > Infinality patches to FreeType are of any effect on Mac. Fonts > rendered with FreeType look fuzzier than with CoreText, which in turn > looks fuzzier than fonts rendered with that same FreeType library > under X11 (XQuartz). - The stem-darkening change in Qt 5.9 does > trigger side-effects with certain fonts when using the FontConfig > Ultimate patches and/or config files. For now I've only found this to > be the case for the Novarese font (all versions I have of it). Sadly > I happen to like that font a lot, including for use in UI elements. I don't get it. How will this improve the look of Qt-Mac applications? Apps using CoreText will look different than Qt apps linking to a patched FreeType and FontConfig. It is unlikely that these patches will ship in official builds (they're not mainlined for a reason), so it would only be your custom compiled applications. The difference would be jarring. Aside: The Infinality patches make fonts look good only under very specific circumstances and inevitably lead to jarring differences when some font next to the "good" ones doesn't fit the specifics. I wasted a lot of time on that patch set when I was young. The entire patch is tailored to a platform that never rendered fonts correctly. Qt 5.9 iirc made a start with linear alpha blending and gamma correction for CFF fonts and compensating the contrast loss with stem darkening. The fuzziness FT > CoreText > FT X11 is because on X11, some form of hinting is usually turned on and there is no linear alpha blending plus gamma correction, leading to harsher rendering that only appears less fuzzy. CoreText ignores hints but darkens stems (overly so by default) to counter the effects of gamma correction, FT will only do that when told so. You probably shouldn't enable stem darkening when using the Infinality set or turn off hacks for CFF fonts until there are no more issues. From rjvbertin at gmail.com Fri Dec 29 21:44:27 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 29 Dec 2017 21:44:27 +0100 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: References: <4742033.fg7tE2YJlQ@portia.local> <2125429.zmWqp9U4cN@portia.local> Message-ID: <1789138.BZuGLZt3Wq@portia.local> On Thursday December 28 2017 20:08:38 Sérgio Martins wrote: Hi, > What I meant is that you don't need to touch FT code when adding > fontconfig support to macOS. The code already exists and is > cross-platform (even worked on QNX). It's just that it's not being > used by cocoa QPA. So... Currently, FreeType support under Cocoa is some kind of hybrid where the standard QCoreTextFontDatabase uses the FreeType font engine (only) for rendering fonts. The existing fontconfig support seems to take the form of a different FontDataBase which has a comparable relationship with QFontEngineFT. It might be trivial to replace QCoreTextFontDatabase with QFontconfigDatabase in QCocoaIntegration but that would be a build-time choice. R. From rjvbertin at gmail.com Fri Dec 29 23:40:52 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 29 Dec 2017 23:40:52 +0100 Subject: [Development] about the Cocoa/Freetype fontengine and FontConfig In-Reply-To: <1789138.BZuGLZt3Wq@portia.local> References: <4742033.fg7tE2YJlQ@portia.local> <1789138.BZuGLZt3Wq@portia.local> Message-ID: <2959715.VeSD12AOex@portia.local> On Friday December 29 2017 21:44:27 René J.V. Bertin wrote: > It might be trivial to replace QCoreTextFontDatabase with QFontconfigDatabase in QCocoaIntegration but that would be a build-time choice. In fact it is ... and with a bit of static_cast'ing one can probably make it a runtime (startup) choice too. Some comparisons on the suggestion ticket I created: https://bugreports.qt.io/browse/QTBUG-65510 Cheers, René From rjvbertin at gmail.com Sat Dec 30 10:57:10 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 30 Dec 2017 10:57:10 +0100 Subject: [Development] about the Cocoa/Freetype fontengine References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> Message-ID: <3041559.U3iHeigPsF@patux.local> Nikolaus Waxweiler wrote: > I don't get it. How will this improve the look of Qt-Mac applications? This is in the eye of the beholder, to some extent. Ideally you will hardly notice a difference as a casual user. > Apps using CoreText will look different than Qt apps linking to a > patched FreeType and FontConfig. It is unlikely that these patches will > ship in official builds (they're not mainlined for a reason), so it > would only be your custom compiled applications. The difference would be > jarring. Well, that's up to the application developer to decide, no? Qt evolves in a universe where it's considered normal to ship copies of the required libraries with(in) each and every application. That includes the FreeType library if that font engine is to be supported, and the FontConfig library could be included just as easily. With or without patches. The Infinality patches aren't mainlined (what's left of them) for 2 reasons that I'm aware of. The FT developers are overly cautious about possible licensing issues and claim there are performance implications. I can only comment from personal experience and expertise on the latter: humbug. > Aside: The Infinality patches make fonts look good only under very > specific circumstances and inevitably lead to jarring differences when > some font next to the "good" ones doesn't fit the specifics. I wasted a > lot of time on that patch set when I was young. Is that longer than about 6 years ago? I've been using the patch set for that long, with the accompanying FC and Cairo patches of course, and the only specific circumstance where I had jagged (pun intended) fonts was when an application shipped its own FreeType (wine!) or I tried a new distro. Plus possibly a very rare occasion where the patch maintainer slipped up. OTOH I get frequent requests to upgrade my Trusty PPA with the patched FT, FC and Cairo libraries, and if you look at the number of forks around and the activity around the various packaging implementation you'll realise that there are a lot of people who care and consider the gain in quality is significant enough to mess around with system libraries. That's certainly not for nothing. > The entire patch is > tailored to a platform that never rendered fonts correctly. Shall we say optimally and make it dependent on point size? > The fuzziness FT > CoreText > FT X11 is because on X11, some form of > hinting is usually turned on and there is no linear alpha blending plus > gamma correction, leading to harsher rendering that only appears less > fuzzy. That's the whole trick, isn't it? Exploiting specifics of human vision so things look sharp while in reality they aren't and even if they were we wouldn't perceive them as such (read up on how fresco painters from the Renaissance worked around that, for fun :)) > CoreText ignores hints but darkens stems (overly so by default) > to counter the effects of gamma correction, FT will only do that when > told so. Which only means that both platforms have there own suboptimal way of doing things. Font developers provide hinting for a reason and spend inordinate amounts of time getting it right. Ignoring it is just stupid, at least on devices with traditional and affordable display densities. > You probably shouldn't enable stem darkening when using the Infinality > set or turn off hacks for CFF fonts until there are no more issues. I probably would if I knew how. In practice I've only come across a single font family where the difference is notable and the font gamma value has an effect. That parameter is apparently ignored for all other fonts so the easy solution for me is to tune that value and be done with it. R From szehowe.koh at gmail.com Sat Dec 30 11:50:12 2017 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Sat, 30 Dec 2017 18:50:12 +0800 Subject: [Development] [Interest] Contributing to Qt In-Reply-To: <63c9a981-3862-0e29-6224-fca21fcf4d47@gmail.com> References: <63c9a981-3862-0e29-6224-fca21fcf4d47@gmail.com> Message-ID: On 30 Dec. 2017 16:12, "Igor Mironchik" wrote: Hello, I want to contribute a little to Qt. I cloned qtbase from git://code.qt.io/qt/qtbase.git Created branch with git branch test git checkout test made changes git commit -a Great but now I have a question: how should I correctly push my changes? Provide a working example please. Thank you. Hi Igor, The short version is: You need to set up your Gerrit account, add Git hooks, and and configure your local repository to use the Gerrit remote repository. Push your commits to the remote repository. The exact details are a bit long. To get started, read through https://wiki.qt.io/Qt_Contribution_Guidelines and https://wiki.qt.io/Setting_up_Gerrit Note: If you use the "init-repository" Perl script from qt5.git, it will automatically set up the Git hooks and the remote repo for all Qt 5 repos (not just qtbase.git). If you don't use this script, you will need to manually configure every repo. Finally, since this thread is about contributing to Qt, let's continue this discussion at development at qt-project.org (remove interest at qt-project.org when you reply) Regards, Sze-Howe -------------- next part -------------- An HTML attachment was scrubbed... URL: From madigens at gmail.com Sat Dec 30 12:21:51 2017 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Sat, 30 Dec 2017 12:21:51 +0100 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: <3041559.U3iHeigPsF@patux.local> References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> Message-ID: > This is in the eye of the beholder, to some extent. Ideally you will > hardly notice a difference as a casual user. > [...] > Well, that's up to the application developer to decide, no? Qt > evolves in a universe where it's considered normal to ship copies of > the required libraries with(in) each and every application. That > includes the FreeType library if that font engine is to be > supported, and the FontConfig library could be included just as > easily. With or without patches. I think you have to carefully match the rendering of CoreText (and its' darkening algorithm) for users not to notice. At that point, you might as well use CoreText, unless you have something very specific in mind. People notice different font rendering. Just recall the fuzz over browsers switching to DirectWrite for text rendering. > The Infinality patches aren't mainlined (what's left of them) for 2 > reasons that I'm aware of. The FT developers are overly cautious > about possible licensing issues and claim there are performance > implications. I can only comment from personal experience and > expertise on the latter: humbug. The performance hit is measurable in the rendering benchmark tool, not sure how much it carries over when you use caches, but it's still iffy. Rendering glyphs multiple times for subpixel positioning might make that even worse. Can't remember something being about licenses. The part of the left-over patchset I sifted through contained post-processing hacks that in their form were not acceptable for mainlining. > Is that longer than about 6 years ago? I've been using the patch set > for that long, with the accompanying FC and Cairo patches of course, > and the only specific circumstance where I had jagged (pun intended) > fonts was when an application shipped its own FreeType (wine!) or I > tried a new distro. Plus possibly a very rare occasion where the > patch maintainer slipped up. Can't remember, but followed the patchset for at least as long as Infinality was active. It's not about being jagged, it's rendering consistency. Sit a Core Web font next to some random Google Font font on the internet and they'll look jarringly different, like each used a different rendering framework. The same happens on Windows, by the way. > OTOH I get frequent requests to upgrade my Trusty PPA with the > patched FT, FC and Cairo libraries, and if you look at the number of > forks around and the activity around the various packaging > implementation you'll realise that there are a lot of people who > care and consider the gain in quality is significant enough to mess > around with system libraries. That's certainly not for nothing. Understandable, because the starting point is crappy. >> The entire patch is tailored to a platform that never rendered >> fonts correctly. > > Shall we say optimally and make it dependent on point size? No, incorrectly hits the mark. As soon as your rendered glyph image contains shades of gray, you MUST use linear alpha blending and gamma correction. Everything else is incorrect. The Windows and Mac platform have been doing that for decades, X11 libs never did to my knowledge. Or, Qt4 or 5 once did and was immediately called back by users complaining about thinner looking text. That is why you need some form of darkening on top, at least on LoDPI screens. >> The fuzziness FT > CoreText > FT X11 is because on X11, some form >> of hinting is usually turned on and there is no linear alpha >> blending plus gamma correction, leading to harsher rendering that >> only appears less fuzzy. > > That's the whole trick, isn't it? Exploiting specifics of human > vision so things look sharp while in reality they aren't and even if > they were we wouldn't perceive them as such (read up on how fresco > painters from the Renaissance worked around that, for fun :)) The "sharpness" is bought with overall harsh- and blotchyness and weaker rendering of lighter text on darker backgrounds. It's a bad trade and makes people flock to band-aid solutions like the Infinality patchset :) >> CoreText ignores hints but darkens stems (overly so by default) to >> counter the effects of gamma correction, FT will only do that when >> told so. > > Which only means that both platforms have there own suboptimal way > of doing things. Font developers provide hinting for a reason and > spend inordinate amounts of time getting it right. Ignoring it is > just stupid, at least on devices with traditional and affordable > display densities. Apple could do with a lighter darkening algorithm, yes, but it's okay, I usually turn it down one notch. The CFF darkener delivers the best looking results so far, as it only counters the thinning such that the font looks as meaty as before gamma correction. There is not always a good reason behind a certain hinting decision (just look at all the fixing Infinality has to do; hinting can be a very seat-of-the-pants business) and it is perfectly acceptable to ignore it all and do something else (autohinter) or nothing at all (CoreText). Remember that it's the design of a font, not the hinting that is canonical. One of my pet peeves with TrueType hinting is that the designer decides the final look, which can clash with the decision of the designer of the font right next to it. Compare the hinted look of Source Sans Pro, Ubuntu or https://acumin.typekit.com/ to what's on Google Fonts which its' many ttfautohint'ed fonts. Or compare it to CFF fonts. Background: (hintslight) autohinter and CFF engine only snap horizontal stems to pixel boundaries but do not change their width. TrueType fonts like those mentioned snap the entire width to pixels and may change vertical stems and bearings. Sounds like a small difference, can make a font look very different however. >> You probably shouldn't enable stem darkening when using the >> Infinality set or turn off hacks for CFF fonts until there are no >> more issues. > > I probably would if I knew how. export FREETYPE_PROPERTIES=cff:no-stem-darkening=1 From rjvbertin at gmail.com Sat Dec 30 13:45:52 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 30 Dec 2017 13:45:52 +0100 Subject: [Development] about the Cocoa/Freetype fontengine References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> Message-ID: <3066007.nQJ9BTZ2LE@patux.local> Nikolaus Waxweiler wrote: > I think you have to carefully match the rendering of CoreText (and its' > darkening algorithm) for users not to notice. At that point, you might > as well use CoreText, unless you have something very specific in mind. Remember that there's also the issue of getting the exact same font metrics which is important for certain users. > People notice different font rendering. Yes - but they're not likely to complain if the different look also looks better. And even then ... how many users complained about window titles looking blurry when KWin started using QtQuick for rendering titlebars? > The performance hit is measurable in the rendering benchmark tool Measurable in a benchmark tool doesn't mean there are performance issues. I've been using Infinality on a very slow system, without any ill effects. > consistency. Sit a Core Web font next to some random Google Font font on > the internet and they'll look jarringly different, like each used a If you mean fonts rendered by FreeType with and without Infinality looks jarringly different, then yes, that can be the case at regular point sizes on regular density displays. Which is the whole point: with the result looks jarringly better. > No, incorrectly hits the mark. As soon as your rendered glyph image > contains shades of gray, you MUST use linear alpha blending and gamma > correction. Everything else is incorrect. > The Windows and Mac platform > have been doing that for decades, X11 libs never did to my knowledge. Erm, I'm talking about KDE desktops using Qt4 or better, which have the option to activate sub-pixel rendering and hinting (which will be on by default IIRC). Basic X11 font rendering doesn't, indeed. Instead it relied on pre-rendered bitmap fonts like for a high-resolution matrix printer. And curiously those fonts could be displayed 100% correct - with moiré effects and blurring between the display phosphor and our retina taking care of making the letters look smooth enough to be pleasant. I still use some fonts like that (Monaco in particular) in my xterms, that I've been preserving from my PhD days on a Mac IIx running A/UX 2.0 . Either way, a long as we're talking about vector fonts rendered on a raster display the term correct has a very relative meaning. > The CFF darkener delivers the best > looking results so far, as it only counters the thinning such that the > font looks as meaty as before gamma correction. Again, that's in the eye of the beholder, but I still find that the results look better with than without the Infinality patch set. The only regression (due to your CFF darkener or to the FT+FC patches) is in a single font family so far, which looks washed out with the default gamma correction. That's actually due to something in the FontConfig "Ultimate" patch or tweaked config files. I have no idea if those are CFF fonts and can't find a reference to the family in the .conf files either. > (just look at all the fixing Infinality has to do; hinting can be a very > seat-of-the-pants business) It is, inevitably. It's aimed at fooling human perception and as such cannot be an exact science (unless you're a biologist or "assimilated" neuroscientist :)). Anyway, whether or not "we" use Infinality is not Qt's business. Or rather, it's not up to Qt to tell us what we should consider to look better and then take steps to make it impossible to use that patch set. The issue at hand here is whether or not Qt should/could allow users to use font rendering based on FreeType+FontConfig across the main platforms, with as the main argument the fact that this will allow (near) perfect cross-platform homogeneity in text rendering. The default should evidently be to use the platform native font engine (but it'd be nice if there were at least an env. variable for users to select their preferred engine and/or a way to do so via e.g. a platform theme plugin like the plasma-integration plugin or my github:RJVB/osx-integration.git). I've posted a few side-by-side comparisons: https://bugreports.qt.io/browse/QTBUG-65510 >> I probably would if I knew how. > > export FREETYPE_PROPERTIES=cff:no-stem-darkening=1 I see absolutely no difference between the two. Maybe simply because I'm not using any CFF fonts. R. From jeanmichael.celerier at gmail.com Sat Dec 30 14:01:33 2017 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Sat, 30 Dec 2017 14:01:33 +0100 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: <3066007.nQJ9BTZ2LE@patux.local> References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> <3066007.nQJ9BTZ2LE@patux.local> Message-ID: > And even then ... how many users complained about window titles looking blurry when KWin started using QtQuick for rendering titlebars? isn't this a common complaint actually : https://www.google.com/search?q=qt+quick+blurry+text ? But I think that the overall problem is that there are two categories of software built with Qt : * apps that integrates with their user's desktop * apps that look the same everywhere. In my case I am for instance sometimes developing small UI software with some buttons, list, etc... and in this case I want the app to integrate nicely and blend in whatever the OS and the color scheme of the user of the software. But the main app I work on is a music software for artists ; these generally have a *very strong* visual identity. We use our own CSS with fusion style everywhere with custom fonts, pixmaps, etc etc... and the software *has* to look the same (as in, pixel-perfect) on every platform (given same DPI of course). I honestly don't care much about the software integrating with the host environment; just take a look at famous software in this category: * Max/MSP: https://docs.cycling74.com/max7/vignettes/images/project-edit.png * Ableton Live: https://img.audiofanzine.com/images/u/product/normal/ableton-live-9-suite-163826.jpg * TouchDesigner: http://farm9.staticflickr.com/8531/8680998191_df78973538_b.jpg * Sonar: https://medias.audiofanzine.com/images/normal/710664.jpg * AudioMulch: https://static.kvraudio.com/i/b/audiomulch2-2.jpg etc... in this case it's a good thing to pop out from other software on your desktop (for very practical reasons, too: when you're on stage performing a show you don't want to spend time finding where is the window you have to click on, they all have to appear very distinct if you have multiple software running) Best, ------- Jean-Michaël Celerier http://www.jcelerier.name On Sat, Dec 30, 2017 at 1:45 PM, René J. V. Bertin wrote: > Nikolaus Waxweiler wrote: > > > I think you have to carefully match the rendering of CoreText (and its' > > darkening algorithm) for users not to notice. At that point, you might > > as well use CoreText, unless you have something very specific in mind. > > Remember that there's also the issue of getting the exact same font metrics > which is important for certain users. > > > People notice different font rendering. > > Yes - but they're not likely to complain if the different look also looks > better. And even then ... how many users complained about window titles > looking > blurry when KWin started using QtQuick for rendering titlebars? > > > The performance hit is measurable in the rendering benchmark tool > > Measurable in a benchmark tool doesn't mean there are performance issues. > I've > been using Infinality on a very slow system, without any ill effects. > > > consistency. Sit a Core Web font next to some random Google Font font on > > the internet and they'll look jarringly different, like each used a > > If you mean fonts rendered by FreeType with and without Infinality looks > jarringly different, then yes, that can be the case at regular point sizes > on > regular density displays. Which is the whole point: with the result looks > jarringly better. > > > No, incorrectly hits the mark. As soon as your rendered glyph image > > contains shades of gray, you MUST use linear alpha blending and gamma > > correction. Everything else is incorrect. > > The Windows and Mac platform > > have been doing that for decades, X11 libs never did to my knowledge. > > Erm, I'm talking about KDE desktops using Qt4 or better, which have the > option > to activate sub-pixel rendering and hinting (which will be on by default > IIRC). > Basic X11 font rendering doesn't, indeed. Instead it relied on pre-rendered > bitmap fonts like for a high-resolution matrix printer. And curiously those > fonts could be displayed 100% correct - with moiré effects and blurring > between > the display phosphor and our retina taking care of making the letters look > smooth enough to be pleasant. I still use some fonts like that (Monaco in > particular) in my xterms, that I've been preserving from my PhD days on a > Mac > IIx running A/UX 2.0 . > > Either way, a long as we're talking about vector fonts rendered on a raster > display the term correct has a very relative meaning. > > > The CFF darkener delivers the best > > looking results so far, as it only counters the thinning such that the > > font looks as meaty as before gamma correction. > > Again, that's in the eye of the beholder, but I still find that the > results look > better with than without the Infinality patch set. The only regression > (due to > your CFF darkener or to the FT+FC patches) is in a single font family so > far, > which looks washed out with the default gamma correction. That's actually > due to > something in the FontConfig "Ultimate" patch or tweaked config files. > I have no idea if those are CFF fonts and can't find a reference to the > family in > the .conf files either. > > > (just look at all the fixing Infinality has to do; hinting can be a very > > seat-of-the-pants business) > > It is, inevitably. It's aimed at fooling human perception and as such > cannot be > an exact science (unless you're a biologist or "assimilated" > neuroscientist :)). > > Anyway, whether or not "we" use Infinality is not Qt's business. Or > rather, it's > not up to Qt to tell us what we should consider to look better and then > take > steps to make it impossible to use that patch set. > > The issue at hand here is whether or not Qt should/could allow users to > use font > rendering based on FreeType+FontConfig across the main platforms, with as > the > main argument the fact that this will allow (near) perfect cross-platform > homogeneity in text rendering. The default should evidently be to use the > platform native font engine (but it'd be nice if there were at least an > env. > variable for users to select their preferred engine and/or a way to do so > via > e.g. a platform theme plugin like the plasma-integration plugin or my > github:RJVB/osx-integration.git). > > I've posted a few side-by-side comparisons: > https://bugreports.qt.io/browse/QTBUG-65510 > > >> I probably would if I knew how. > > > > export FREETYPE_PROPERTIES=cff:no-stem-darkening=1 > > I see absolutely no difference between the two. Maybe simply because I'm > not > using any CFF fonts. > > R. > > > _______________________________________________ > 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 rjvbertin at gmail.com Sat Dec 30 16:27:03 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sat, 30 Dec 2017 16:27:03 +0100 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: References: <4742033.fg7tE2YJlQ@portia.local> <3066007.nQJ9BTZ2LE@patux.local> Message-ID: <2776022.QqUqlGae0t@portia.local> On Saturday December 30 2017 14:01:33 Jean-Michaël Celerier wrote: > isn't this a common complaint actually : > https://www.google.com/search?q=qt+quick+blurry+text ? Let's put it this way: not common enough for neither the Qt nor the KWin developers to heed? ;) > In my case I am for instance sometimes developing small UI software with > some buttons, list, etc... and in this case I want the app to integrate > nicely and blend in whatever the OS and the color scheme of the user of the > software. Of course. But you wouldn't mind if they actually look better, would you? (Not that that's usually the case with "vanilla" cross-platform Qt software running on Mac; it tends to look as if designed for the visual and/or motor impaired). A few more screenshots: > But the main app I work on is a music software for artists ; these > generally have a *very strong* visual identity. We use our own CSS with > fusion style everywhere with custom fonts, pixmaps, etc etc... and the > software *has* to look the same (as in, pixel-perfect) on every platform > (given same DPI of course). I honestly don't care much about the software > integrating with the host environment; just take a look at famous software > in this category: > > * Max/MSP: https://docs.cycling74.com/max7/vignettes/images/project-edit.png > * Ableton Live: > https://img.audiofanzine.com/images/u/product/normal/ableton-live-9-suite-163826.jpg > * TouchDesigner: > http://farm9.staticflickr.com/8531/8680998191_df78973538_b.jpg > * Sonar: https://medias.audiofanzine.com/images/normal/710664.jpg > * AudioMulch: https://static.kvraudio.com/i/b/audiomulch2-2.jpg > > etc... in this case it's a good thing to pop out from other software on > your desktop (for very practical reasons, too: when you're on stage > performing a show you don't want to spend time finding where is the window > you have to click on, they all have to appear very distinct if you have > multiple software running) > > > Best, > ------- > Jean-Michaël Celerier > http://www.jcelerier.name > > On Sat, Dec 30, 2017 at 1:45 PM, René J. V. Bertin > wrote: > > > Nikolaus Waxweiler wrote: > > > > > I think you have to carefully match the rendering of CoreText (and its' > > > darkening algorithm) for users not to notice. At that point, you might > > > as well use CoreText, unless you have something very specific in mind. > > > > Remember that there's also the issue of getting the exact same font metrics > > which is important for certain users. > > > > > People notice different font rendering. > > > > Yes - but they're not likely to complain if the different look also looks > > better. And even then ... how many users complained about window titles > > looking > > blurry when KWin started using QtQuick for rendering titlebars? > > > > > The performance hit is measurable in the rendering benchmark tool > > > > Measurable in a benchmark tool doesn't mean there are performance issues. > > I've > > been using Infinality on a very slow system, without any ill effects. > > > > > consistency. Sit a Core Web font next to some random Google Font font on > > > the internet and they'll look jarringly different, like each used a > > > > If you mean fonts rendered by FreeType with and without Infinality looks > > jarringly different, then yes, that can be the case at regular point sizes > > on > > regular density displays. Which is the whole point: with the result looks > > jarringly better. > > > > > No, incorrectly hits the mark. As soon as your rendered glyph image > > > contains shades of gray, you MUST use linear alpha blending and gamma > > > correction. Everything else is incorrect. > > > The Windows and Mac platform > > > have been doing that for decades, X11 libs never did to my knowledge. > > > > Erm, I'm talking about KDE desktops using Qt4 or better, which have the > > option > > to activate sub-pixel rendering and hinting (which will be on by default > > IIRC). > > Basic X11 font rendering doesn't, indeed. Instead it relied on pre-rendered > > bitmap fonts like for a high-resolution matrix printer. And curiously those > > fonts could be displayed 100% correct - with moiré effects and blurring > > between > > the display phosphor and our retina taking care of making the letters look > > smooth enough to be pleasant. I still use some fonts like that (Monaco in > > particular) in my xterms, that I've been preserving from my PhD days on a > > Mac > > IIx running A/UX 2.0 . > > > > Either way, a long as we're talking about vector fonts rendered on a raster > > display the term correct has a very relative meaning. > > > > > The CFF darkener delivers the best > > > looking results so far, as it only counters the thinning such that the > > > font looks as meaty as before gamma correction. > > > > Again, that's in the eye of the beholder, but I still find that the > > results look > > better with than without the Infinality patch set. The only regression > > (due to > > your CFF darkener or to the FT+FC patches) is in a single font family so > > far, > > which looks washed out with the default gamma correction. That's actually > > due to > > something in the FontConfig "Ultimate" patch or tweaked config files. > > I have no idea if those are CFF fonts and can't find a reference to the > > family in > > the .conf files either. > > > > > (just look at all the fixing Infinality has to do; hinting can be a very > > > seat-of-the-pants business) > > > > It is, inevitably. It's aimed at fooling human perception and as such > > cannot be > > an exact science (unless you're a biologist or "assimilated" > > neuroscientist :)). > > > > Anyway, whether or not "we" use Infinality is not Qt's business. Or > > rather, it's > > not up to Qt to tell us what we should consider to look better and then > > take > > steps to make it impossible to use that patch set. > > > > The issue at hand here is whether or not Qt should/could allow users to > > use font > > rendering based on FreeType+FontConfig across the main platforms, with as > > the > > main argument the fact that this will allow (near) perfect cross-platform > > homogeneity in text rendering. The default should evidently be to use the > > platform native font engine (but it'd be nice if there were at least an > > env. > > variable for users to select their preferred engine and/or a way to do so > > via > > e.g. a platform theme plugin like the plasma-integration plugin or my > > github:RJVB/osx-integration.git). > > > > I've posted a few side-by-side comparisons: > > https://bugreports.qt.io/browse/QTBUG-65510 > > > > >> I probably would if I knew how. > > > > > > export FREETYPE_PROPERTIES=cff:no-stem-darkening=1 > > > > I see absolutely no difference between the two. Maybe simply because I'm > > not > > using any CFF fonts. > > > > R. > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > From rjvbertin at gmail.com Sat Dec 30 16:40:11 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sat, 30 Dec 2017 16:40:11 +0100 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: References: <4742033.fg7tE2YJlQ@portia.local> <3066007.nQJ9BTZ2LE@patux.local> Message-ID: <22613706.qQzmassh59@portia.local> On Saturday December 30 2017 14:01:33 Jean-Michaël Celerier wrote: [apologies, hit the wrong key] > isn't this a common complaint actually : > https://www.google.com/search?q=qt+quick+blurry+text ? Let's put it this way: not common enough for neither the Qt nor the KWin developers to heed? ;) > In my case I am for instance sometimes developing small UI software with > some buttons, list, etc... and in this case I want the app to integrate > nicely and blend in whatever the OS and the color scheme of the user of the > software. Of course. But you wouldn't mind if they actually look better, would you? (Not that that's usually the case with "vanilla" cross-platform Qt software running on Mac; it tends to look as if designed for the visual and/or motor impaired). A few more screenshots: https://bugreports.qt.io/browse/QTBUG-65510?focusedCommentId=385106&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-385106 One could probably say that the FT+FC rendering shown in those images is not correct for certain glyphs. It's actually more correct than without the Infinality/Ultimate patches to FontConfig (with stock FC the result has a bit of a crushed, too flat look). The main goal for these patches probably lies more in obtaining a pleasant and highly legible quality rather than the most correct glyph shape. > But the main app I work on is a music software for artists ; these > generally have a *very strong* visual identity. We use our own CSS with ... > etc... in this case it's a good thing to pop out from other software on If you want I can share the fontconfig enabler patches for Mac with you, for experimentation (or even bundling). R. From madigens at gmail.com Sat Dec 30 18:03:31 2017 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Sat, 30 Dec 2017 18:03:31 +0100 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: <3066007.nQJ9BTZ2LE@patux.local> References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> <3066007.nQJ9BTZ2LE@patux.local> Message-ID: >> People notice different font rendering. > > Yes - but they're not likely to complain if the different look also > looks better. DirectWrite rendering looks better than GDI rendering (in the sense that it is truer to the designed outlines and the spacing with fewer compromises for black and white glyphs), yet so many people complained about blurry fonts that Microsoft lowered the gamma correction in IE to make the fonts look blacker. >> The performance hit is measurable in the rendering benchmark tool > > Measurable in a benchmark tool doesn't mean there are performance > issues. I've been using Infinality on a very slow system, without > any ill effects. They still exist and would better not be there. Actually, since the core Infinality patch set is mainlined, they already are part of the code base... >> consistency. Sit a Core Web font next to some random Google Font >> font on the internet and they'll look jarringly different, like >> each used a > > If you mean fonts rendered by FreeType with and without Infinality > looks jarringly different, then yes, that can be the case at regular > point sizes on regular density displays. Which is the whole point: > with the result looks jarringly better. I mean fonts rendered through Infinality that match the specifics required for good looks and others that don't. That is the core problem. And then you have fonts next to each other where one was originally hinted for Win95-style bitmap display (e.g. Arial) and the other is trying to take advantage of ClearType. Looks jarring in a bad way even on Windows. > Erm, I'm talking about KDE desktops using Qt4 or better, which have > the option to activate sub-pixel rendering and hinting (which will > be on by default IIRC). Basic X11 font rendering doesn't, indeed. I'm talking about linear alpha blending and gamma correction. Qt4 and 5 (and Skia) are capable of it, it's just disabled by default (except for 5.9 with CFF fonts iirc). That is the problem. Subpixel rendering and positioning are icing on the cake. > Instead it relied on pre-rendered bitmap fonts like for a > high-resolution matrix printer. And curiously those fonts could be > displayed 100% correct - with moiré effects and blurring between the > display phosphor and our retina taking care of making the letters > look smooth enough to be pleasant. Black and white fonts need no linear alpha blending and gamma correction because they contain no grays, so the X11 way of rendering is indeed correct ;) And I'm well aware of the smoothing effect of analog displays. Background: FreeType's renderings of glyphs are coverage maps in linear space (50% coverage of a pixel by an outline == pixel gray level of 128 in 8 bit). All our displays have a non-linear gamma curve though. 0% coverage == white and 100% coverage == black are the same in linear and sRGB gamma space, just everything in between isn't, which means you have to convert the values before you put them on arbitrary surfaces for display on a sRGB screen -> linear alpha blending and gamma correction. That is why I'm talking about correctness with such certainty :) We want to get to "Gamma 1.8, darkenend": https://www.freetype.org/image/BlendingExamples.png > Either way, a long as we're talking about vector fonts rendered on a > raster display the term correct has a very relative meaning. As long as you convert vectors (any vectors, really) to bitmaps and put them on arbitrary surfaces, you have to do linear alpha blending and gamma correction to comply with baseline rendering correctness. Only afterwards can you be relative in your meaning. > I have no idea if those are CFF fonts and can't find a reference to > the family in the .conf files either. Should be easy to find out. Filename ends with ".otf", you're most likely looking at a CFF font (see e.g. Cantarell). Cubic beziers inside the font are a dead giveaway. > It is, inevitably. It's aimed at fooling human perception and as > such cannot be an exact science (unless you're a biologist or > "assimilated" neuroscientist :)). Wait, what I was trying to say is that just because someone instructed some glyph in some way, doesn't mean it's been instructed well. > The issue at hand here is whether or not Qt should/could allow users > to use font rendering based on FreeType+FontConfig across the main > platforms, with as the main argument the fact that this will allow > (near) perfect cross-platform homogeneity in text rendering. And I think it is asking for users to complain about different looking fonts on their platform. It's annoying enough that all major toolkits on X11 interpret fontconfig in slightly different ways when messing with hinting etc. >> export FREETYPE_PROPERTIES=cff:no-stem-darkening=1 > > I see absolutely no difference between the two. Maybe simply because > I'm not using any CFF fonts. Err. Does 0 make a difference? If not, you're probably not looking at a CFF font or something else is going on. CFF darkening is noticeable. > One could probably say that the FT+FC rendering shown in those > images is not correct for certain glyphs. If linear alpha blending and gamma correction are involved, they are correctly rendered in the technical sense. --- > But the main app I work on is a music software for artists ; these > generally have a *very strong* visual identity. > in this case it's a good thing to pop out from other software on your > desktop From the screenshots, the apps appear to use a native font renderer. Nothing wrong with a strong identity, but please user-test font renderer changes before you unleash them on your users... From rjvbertin at gmail.com Sat Dec 30 22:18:57 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 30 Dec 2017 22:18:57 +0100 Subject: [Development] about the Cocoa/Freetype fontengine References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> <3066007.nQJ9BTZ2LE@patux.local> Message-ID: <2101501.14ONTCRir5@patux.local> Nikolaus Waxweiler wrote: > > DirectWrite rendering looks better than GDI rendering (in the sense that > it is truer to the designed outlines and the spacing with fewer That's not what I call looking better, but more veridical. The two can overlap but just as (actually, more) often they don't. > compromises for black and white glyphs), yet so many people complained > about blurry fonts that Microsoft lowered the gamma correction in IE to > make the fonts look blacker. Which confirms my claim that most users will give higher priority to on-screen legibility than to design veracity. Very understandably so. IIRC Microsoft played into that themselves when they promoted Times New Roman to the de-facto standard variable-width font. Looks very different at usual screen point sizes than it does in print. Rendering it veridically (like CoreText apparently does) makes it very uncomfortable to read. > I mean fonts rendered through Infinality that match the specifics > required for good looks and others that don't. That is the core problem. I'm guessing you can find almost any number of combinations of fonts that bite when displayed next to each other. Not a fair argument. I'm also pretty certain that people like "Bohomil" who spend/t hours tweaking fontconfig files do so in part to reduce such differences. I know only of FontConfig that allows to do this kind of font-specific tuning. > Should be easy to find out. Filename ends with ".otf", you're most > likely looking at a CFF font (see e.g. Cantarell). I have lots of OpenType fonts that probably just contain TrueType inside. > Cubic beziers inside > the font are a dead giveaway. And those are *so* easy to spot... > Wait, what I was trying to say is that just because someone instructed > some glyph in some way, doesn't mean it's been instructed well. Oh. I missed that or you didn't succeed in that intention. I've doodled in font design myself and learned quite quickly it's much easier to mess up rendering than it is to improve things. > And I think it is asking for users to complain about different looking > fonts on their platform. Seriously? Anyone complaining about something they asked for is begging not to be taken seriously. Qt already has the possibility to switch to using FreeType, on MS Windows and since a few releases also on Mac. How many people complain about that? How many people complained about fonts looking differently after having set up a GIGO font substitution table under Qt4? > Err. Does 0 make a difference? No. > If not, you're probably not looking at a > CFF font or something else is going on. Probably some combination of both. Some day I should try to figure out what, maybe it's just that this font family gets lumped into a FontConfig category where it really shouldn't be. The fact may be telling that this also appears to be the only font family where the font smoothing gamma value has a significant effect. > From the screenshots, the apps appear to use a native font renderer. I hesitated annotating my own last 2 screenshots, just to see if you'd ask or tell which was which... I've been running the same applications on the same monitor using the XCB and Cocoa QPAs side by side for a bit over a year now, without very strong opinions over which was better on the eyes. I can now get (almost) exactly the same rendering in both modes by selecting the FontConfig path in the Cocoa QPA. I'm curious to see if I'll develop a preference. R. From madigens at gmail.com Sat Dec 30 22:59:34 2017 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Sat, 30 Dec 2017 22:59:34 +0100 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: <2101501.14ONTCRir5@patux.local> References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> <3066007.nQJ9BTZ2LE@patux.local> <2101501.14ONTCRir5@patux.local> Message-ID: <50fa943c-5817-e56d-aa8a-b6bf92be0da4@gmail.com> >> compromises for black and white glyphs), yet so many people >> complained about blurry fonts that Microsoft lowered the gamma >> correction in IE to make the fonts look blacker. > > Which confirms my claim that most users will give higher priority to > on-screen legibility than to design veracity. Very understandably > so. Alternative explanation: people complain when something they know changes. Nobody could stand to use Macs if bitmap fonts were the pinnacle of on-screen legibility. > IIRC Microsoft played into that themselves when they promoted Times > New Roman to the de-facto standard variable-width font. Yep :) > I'm guessing you can find almost any number of combinations of fonts > that bite when displayed next to each other. True if you use bytecode hinting. Now use hintslight/the autohinter for everything. Suddenly everything harmonizes much better because the same hinting strategy is applied consistently to everything. This is the reason I pushed for hintslight as the default in GNOME and FontConfig after Ubuntu used it for years. > I'm also pretty certain that people like "Bohomil" who spend/t hours > tweaking fontconfig files do so in part to reduce such differences. You can't fix fonts having different hinting strategies, unless you rewrite the hinting. >> Should be easy to find out. Filename ends with ".otf", you're most >> likely looking at a CFF font (see e.g. Cantarell). > > I have lots of OpenType fonts that probably just contain TrueType > inside. Find out in FontForge, or if you have fonttools installed, look for "CFF" in `ttx -l font.otf`. >> And I think it is asking for users to complain about different >> looking fonts on their platform. > > Seriously? Anyone complaining about something they asked for is > begging not to be taken seriously. Lemme reword that: users of apps whose developers switched font engines. > I'm curious to see if I'll develop a preference. Maybe you find that you prefer what you're used to :) From rjvbertin at gmail.com Sat Dec 30 23:52:02 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 30 Dec 2017 23:52:02 +0100 Subject: [Development] about the Cocoa/Freetype fontengine References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> <3066007.nQJ9BTZ2LE@patux.local> Message-ID: <4501587.HH3h8i9JZz@portia.local> Nikolaus Waxweiler wrote: > We want to get to "Gamma 1.8, darkenend": > https://www.freetype.org/image/BlendingExamples.png On Mac (FT and/or FT+FC *without* Infinality+Ultimate patches) I find 1.5 comes closer to the native CoreText font colour. 1.8 is too thin. And for giggles, which one looks better and which more correct in this screenshot (of 2 Konsole windows under X11)? R -------------- next part -------------- A non-text attachment was scrubbed... Name: FC-Inf-noInf.png Type: image/png Size: 86400 bytes Desc: not available URL: From rjvbertin at gmail.com Sun Dec 31 00:04:27 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 31 Dec 2017 00:04:27 +0100 Subject: [Development] about the Cocoa/Freetype fontengine References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> <3066007.nQJ9BTZ2LE@patux.local> <2101501.14ONTCRir5@patux.local> <50fa943c-5817-e56d-aa8a-b6bf92be0da4@gmail.com> Message-ID: <22614094.nR1biZr0It@portia.local> Nikolaus Waxweiler wrote: > changes. Nobody could stand to use Macs if bitmap fonts were the > pinnacle of on-screen legibility. ? Where does that come from and what does it even mean? >> tweaking fontconfig files do so in part to reduce such differences. > > You can't fix fonts having different hinting strategies, unless you Please re-read and ponder the difference between fixing something and "tweaking to reduce it". > Lemme reword that: users of apps whose developers switched font engines. Right, and where did *that* come from in discussion that's about font engine choice by the user? >> I'm curious to see if I'll develop a preference. > > Maybe you find that you prefer what you're used to :) That'd mean both... From madigens at gmail.com Sun Dec 31 01:10:56 2017 From: madigens at gmail.com (Nikolaus Waxweiler) Date: Sun, 31 Dec 2017 01:10:56 +0100 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: <4501587.HH3h8i9JZz@portia.local> References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> <3066007.nQJ9BTZ2LE@patux.local> <4501587.HH3h8i9JZz@portia.local> Message-ID: >> We want to get to "Gamma 1.8, darkenend": >> https://www.freetype.org/image/BlendingExamples.png > > On Mac (FT and/or FT+FC *without* Infinality+Ultimate patches) I > find 1.5 comes closer to the native CoreText font colour. 1.8 is too > thin. Fair enough, depends on your screen and how much you darken. Ideally, you match the sRGB gamma curve of roughly 2.2 that in an ideal world, your screen matches, too. Ha! > And for giggles, which one looks better and which more correct in > this screenshot (of 2 Konsole windows under X11)? Both look off (right: hinting, left: autohinting), specifically the gamma correction. Looks more like a gamma of 1.0 plus maybe some thickening/smearing via the LCD filter. Is gamma correction enabled in your Qt build? No strong hinting preference here, still prefer left for the slightly cleaner look should you wonder. The ftview program from the freetype2-demos package will render stuff in the technical correct way I'm going on about with a default gamma of 1.8. Use the FREETYPE_PROPERTIES env thing to toggle darkening for CFF fonts. All of that is courtesy of Adobe. >> Which confirms my claim that most users will give higher priority >> to on-screen legibility than to design veracity. Very >> understandably so. > > Alternative explanation: people complain when something they know > changes. Nobody could stand to use Macs if bitmap fonts were the > pinnacle of on-screen legibility. Reworded: if most users have higher priority on on-screen legibility in the strongly hinted sense, nobody would have used Macs before Retina screens. Text on pre-Retina Macs is however quite readable if you get used to the look. > Please re-read and ponder the difference between fixing something and > "tweaking to reduce it". Reworded: you can't reduce the difference between different hinting strategies without rewriting the hinting. See the attached screenshot. Left is hinting, right is autohinting, both use the v40 hinting engine that discards changes to vertical stems. The designers chose to clamp horizontal stems to full pixels (the usual strategy in Win95 times), note the thickness jump between 18 and 19 and 30 and 31 pt. The autohinter instead pulls horizontal stems to the pixel boundary without changing the stem thickness/width, a different design/clarity trade-off. This is a fundamental difference you can't paper over. You can see this even on Windows when you look at Arial and some ttfautohinted font in a text waterfall. Well, okay, you could theoretically start to supersample on the y-axis and apply some black magic, but then you might as well use autohinting. > Right, and where did *that* come from in discussion that's about font > engine choice by the user? We are talking about giving devs the ability to ship Qt apps with switched font engines, no? > That'd mean both... Yes :) -------------- next part -------------- A non-text attachment was scrubbed... Name: Bildschirmfoto vom 2017-12-31 00-57-38.png Type: image/png Size: 131964 bytes Desc: not available URL: From rjvbertin at gmail.com Sun Dec 31 11:11:04 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2E__V=2E?= Bertin) Date: Sun, 31 Dec 2017 11:11:04 +0100 Subject: [Development] about the Cocoa/Freetype fontengine References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> <3066007.nQJ9BTZ2LE@patux.local> <4501587.HH3h8i9JZz@portia.local> Message-ID: <1842890.OjgxPJRaY0@patux.local> Nikolaus Waxweiler wrote: > Fair enough, depends on your screen and how much you darken. Ideally, > you match the sRGB gamma curve of roughly 2.2 that in an ideal world, > your screen matches, too. Ha! I recall a difference in opinion between Apple and the rest of the world about what the correct gamma should be. To me 2.2 always looked too bleak. I calibrate my Mac screens btw, not using hardware but with the SuperCal utility. > Both look off (right: hinting, left: autohinting), specifically the > gamma correction. Looks more like a gamma of 1.0 plus maybe some Nope, 1.5 . > thickening/smearing via the LCD filter. Is gamma correction enabled in > your Qt build? All I can say is that I didn't turn it off and that the font smoothing gamma value matters. > No strong hinting preference here, still prefer left for > the slightly cleaner look should you wonder. Hah. Both are Konsole under X11 with Novarese BQ Medium for menus and Ubuntu Mono for the terminal font. Left is with Infinality+Ultimate (preset #3), right is stock FT+FC. Those are the point sizes and colours I work with; needless to say left is much easier on the eyes in the long run. Seeing them side-by-side I do think it could be a tad darker though. > Reworded: if most users have higher priority on on-screen legibility in > the strongly hinted sense, nobody would have used Macs before Retina > screens. You forget there are other reasons, and I didn't claim that legibility had to include hinting (most users won't care what tech is used, evidently). You can get very readable text with bitmapped fonts if they're well done - remember my earlier remarks about Monaco. In fact I realised that my Terminal.app is still set not to anti-alias text because it simply looks sharper. Because it is (but then hinting and smoothing are not necessarily coupled, are they.) Looks something like the attached screenshot (of the old X11 pre-rasterised version). I've spent countless hours coding in vi with exactly that font; that only changed after I installed a KDE4 desktop and discovered the Infinality patches. Still, that same font looked a bit better with the more modern tech in OS X (provided it was black on white, granted). Not that I had much choice outside of Terminal.app ... > Text on pre-Retina Macs is however quite readable if you get > used to the look. Then there's that: going back to such a Mac might be hard if you've never gotten used to them, but once they were the reference (and I have never cared to shell out the extra cash for one). > Reworded: you can't reduce the difference between different hinting > strategies without rewriting the hinting And what if you can switch the autohinter on or off per font (or per glyph if FontConfig allows that kind of control)? I see it's a FreeType property so technically this should be possible. > We are talking about giving devs the ability to ship Qt apps with > switched font engines, no? A priori in a way that can be overridden as far as I'm concerned because handled via existing mechanisms (env. variables, command line options, qt.conf settings). I did write a PoC implementation to switch via a platform theme plugin, based on what's in a settings file so yeah, that approach could make it possible to force a font engine. There's no law against given devs noose-making API, is there? ;) BTW, is there a technical reason to expect one cannot change a fontengine/fontdatabase anymore after the first fonts have been rendered? R. -------------- next part -------------- A non-text attachment was scrubbed... Name: monaco-bitmapped.png Type: image/png Size: 5973 bytes Desc: not available URL: From annulen at yandex.ru Sun Dec 31 12:25:04 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 31 Dec 2017 14:25:04 +0300 Subject: [Development] about the Cocoa/Freetype fontengine In-Reply-To: References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> <3066007.nQJ9BTZ2LE@patux.local> <4501587.HH3h8i9JZz@portia.local> Message-ID: <1250131514719504@web43o.yandex.ru> 31.12.2017, 03:11, "Nikolaus Waxweiler" : >>>  We want to get to "Gamma 1.8, darkenend": >>>  https://www.freetype.org/image/BlendingExamples.png >> >>  On Mac (FT and/or FT+FC *without* Infinality+Ultimate patches) I >>  find 1.5 comes closer to the native CoreText font colour. 1.8 is too >>  thin. > > Fair enough, depends on your screen and how much you darken. Ideally, > you match the sRGB gamma curve of roughly 2.2 that in an ideal world, > your screen matches, too. Ha! > >>  And for giggles, which one looks better and which more correct in >>  this screenshot (of 2 Konsole windows under X11)? > > Both look off (right: hinting, left: autohinting), specifically the > gamma correction. Looks more like a gamma of 1.0 plus maybe some > thickening/smearing via the LCD filter. Is gamma correction enabled in > your Qt build? No strong hinting preference here, still prefer left for > the slightly cleaner look should you wonder. > > The ftview program from the freetype2-demos package will render stuff in > the technical correct way I'm going on about with a default gamma of > 1.8. Use the FREETYPE_PROPERTIES env thing to toggle darkening for CFF > fonts. All of that is courtesy of Adobe. > >>>  Which confirms my claim that most users will give higher priority >>>  to on-screen legibility than to design veracity. Very >>>  understandably so. >> >>  Alternative explanation: people complain when something they know >>  changes. Nobody could stand to use Macs if bitmap fonts were the >>  pinnacle of on-screen legibility. > > Reworded: if most users have higher priority on on-screen legibility in > the strongly hinted sense, nobody would have used Macs before Retina > screens. Text on pre-Retina Macs is however quite readable if you get > used to the look. Note that Mac OS X at least up to 10.5 allowed setting strong hinting in the system settings > >>  Please re-read and ponder the difference between fixing something and >>  "tweaking to reduce it". > > Reworded: you can't reduce the difference between different hinting > strategies without rewriting the hinting. See the attached screenshot. > Left is hinting, right is autohinting, both use the v40 hinting engine > that discards changes to vertical stems. The designers chose to clamp > horizontal stems to full pixels (the usual strategy in Win95 times), > note the thickness jump between 18 and 19 and 30 and 31 pt. The > autohinter instead pulls horizontal stems to the pixel boundary without > changing the stem thickness/width, a different design/clarity trade-off. > This is a fundamental difference you can't paper over. You can see this > even on Windows when you look at Arial and some ttfautohinted font in a > text waterfall. > > Well, okay, you could theoretically start to supersample on the y-axis > and apply some black magic, but then you might as well use autohinting. > >>  Right, and where did *that* come from in discussion that's about font >>  engine choice by the user? > > We are talking about giving devs the ability to ship Qt apps with > switched font engines, no? > >>  That'd mean both... > > Yes :) > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From rjvbertin at gmail.com Sun Dec 31 14:37:48 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 31 Dec 2017 14:37:48 +0100 Subject: [Development] about the Cocoa/Freetype fontengine References: <4742033.fg7tE2YJlQ@portia.local> <7850948.X9B33WSh9e@patux.local> <5740503.SiWtZChDqH@bola> <1f30fa23-311c-e35f-6e60-ee4a3f410169@gmail.com> <3041559.U3iHeigPsF@patux.local> <3066007.nQJ9BTZ2LE@patux.local> <4501587.HH3h8i9JZz@portia.local> <1250131514719504@web43o.yandex.ru> Message-ID: <17622198.3FtAFHqXq5@patux.local> Konstantin Tokarev wrote: > Note that Mac OS X at least up to 10.5 allowed setting strong hinting in the > system settings It indeed used to have a combobox with different levels of font smoothing. That went the way of the dodo together with CRTs; nowadays all that's left is "Use LCD font smoothing when available". If other settings remain they're not even exposed via TinkerTool (the only utility I know that allows customising the desktop fonts on Mac). R.