Re: [Development] The CI is down atm

[Jędrzej Nowacki]

Oh, thanks for sharing it. For the first time we have something that really 
points to fscache, or at least has it in the logs. I suggest to replace NFS + 
fscache, with a distributed files system with _good_ local caching (could be 
cephfs?). The current setup requires only that used part of images is cached 
locally  and that all images are permanently stored in one location. As a 
bonus we would migrate from a stat setup to a mesh, that would be good 
too.That can not be hard to achieve ;-)

Cheers,  
 Jędrek


Dnia sobota, 17 marca 2018 07:42:30 CET Tony Sarajärvi pisze:
> Ok I brought it up again. Hosts seem to be dying left and right. The current
> MAAS provided Ubuntu 16.04 LTS seem to have at least 3 different symptoms
> of how it crashes. 
> kernel BUG at /build/linux-Fk60NP/linux-4.10.0/include/linux/swapops.h:129!
> kernel BUG at /build/linux-Fk60NP/linux-4.10.0/fs/fscache/operation.c:494!
> or
> kernel BUG at /build/linux-Fk60NP/linux-4.10.0/fs/fscache/operation.c:68!
>  
> + possible memory corruptions on multiple host causing crashes. These are
> being checked by memtest, but it hasn’t found anything wrong. 
> So, coin is building again, but more crashes are due. I should swap to 17.04
> or 17.10 even though they have their own share of problems. They _might_
> have gotten fixed during this period when we went back to 16.04. And as
> 16.04 went from bad to worse recently, the 17.xx are surely more stable
> right now. 
> Fingers crossed!
>  
> -Tony
>  
> Oh, and capacity is heavily reduced before the crashed servers are deployed
> back. And a long queue is in already naturally. ☹ 
> We aren’t monitoring 24/7, so please inform at qt...@qt.io  if you suspect
> the CI has crashed. Thank you! 
> From:  Tony Sarajärvi
> Sent:  lauantai 17. maaliskuuta 2018 8.03
> To:  development@qt-project.org
> Subject:  The CI is down atm
>  
> Hi
>  
> The CI is down atm and I can’t even log in to the server right now. I’m
> trying to fix this somehow right away. 
> -Tony


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] atomic commits across submodules (was: Suggestion to add labels when changing API)

[Jędrzej Nowacki]

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding Qt CoAP

[Jędrzej Nowacki]

On piątek, 1 września 2017 08:38:19 CEST Thiago Macieira wrote:
> I'm also wondering if we shouldn't have a bigger repo for IoT-related
> things,  instead of creating a small one for each thing.

Currently, from CI and releasing perspective heaving dozen of small repos is 
easier and faster. All these modules are quite distinct, so joining them would 
not give any adventage to our users nor us apart of a good feeling of grouping 
things together.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] CI has infra problems

[Jędrzej Nowacki]

On tirsdag 1. august 2017 15.11.38 CEST Thiago Macieira wrote:
> No, another problem has now appeared:
> 
>  Module "qt/qtbase" (34adca0607ff9231b4c79949353827c1c8319c52) Failed
> repeatedly to launch build/test agent:
>  Failed 7 times to acquire the hardware
>  buildKey: qt/qtbase/eab0f32365c02540893fd3d1d75c2af2b4e6f6e8/
> LinuxUbuntu_16_04x86_64LinuxUbuntu_16_04x86_64GCCqtci-linux-Ubuntu-16.04-
> x86_64-1-bd2be3TestOnly_LicenseCheck/7ca30f915833d953146007e71743147e3e71950
> 0/ Test
>  agentLaunchRequest: AgentLaunchRequest(machineType=0,
> testConfiguration=TestConfiguration(testHack=None, features=[8, 7],
> vmTemplate='qtci-linux-Ubuntu-16.04-x86_64-1-bd2be3', configureArgs=None,
> toolsets=[Toolset(targetSourceDirectory='qt/qtqa-latest', branch='master',
> excludeSubModules=None,
> repositoryState=RepositoryState(sha1='f2fea571b9e17dc31eff349f6b744603c670dc
> d6', project='qt/qtqa',
> contentSha1='2e26fde8a7db0bb8e81edb44509ea8a64d257e1a', dependencies=[],
> gerritInstance='qt-project'), sourceOnly=True)],
> target=Machine(os=1, arch='x86_64', os_version=304, compiler=0),
> host=Machine(os=1, arch='x86_64', os_version=304, compiler=0), type=0),
> productVersion='5.9', buildKey='qt/qtbase/
> eab0f32365c02540893fd3d1d75c2af2b4e6f6e8/
> LinuxUbuntu_16_04x86_64LinuxUbuntu_16_04x86_64GCCqtci-linux-Ubuntu-16.04-
> x86_64-1-bd2be3TestOnly_LicenseCheck/7ca30f915833d953146007e71743147e3e71950
> 0/ Test', vmTemplate='qtci-linux-Ubuntu-16.04-x86_64-1-bd2be3', type=1)
> reasons:

Hi,

  So this kind of things should be fixed now.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdoc for C++ and QML

[Jędrzej Nowacki]

On mandag 24. april 2017 14.05.17 CEST Sean Harmer wrote:
> Hi,
> 
> are there any plans to reduce/remove the redundancy when writing
> documentation for both C++ and QML? Seems a waste of time to have to
> copy/paste or update the docs twice for both languages when really the
> only things differing are the "Q" prefix on the class names in C++.
> (...)

You can create shared blocks of docs in a separate qdocinc file and use them 
with " \include file.qdocinc" command. It is not perfect, as you would not see 
the full docs in the source code, but it generates the right thing.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] State of dev branch in CI

[Jędrzej Nowacki]

On tirsdag 10. januar 2017 11.37.56 CET Simon Hausmann wrote:
> (2) I really wish the placement of the configuration files for the
> platforms being moved to qt5.git had a high priority, because it prevents
> situations like these where the R organization, the project, contributors
> and partners in the ecosystem are blocked from work for several days. As
> such a configuration change went into the CI last Thursday and the problem
> was noticed last Thursday, the change _remained_ in there until now we have
> confirmation that it is going to get reverted. If this had been part of
> qt5.git the change would not go live until all the issues are fixed, while
> nobody else is blocked in their work.

For sake of bureaucracy this is tracked here: https://bugreports.qt.io/browse/
QTQAINFRA-1074 and it is almost solved.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Jędrzej Nowacki]

On torsdag 10. november 2016 12.29.12 CET Oswald Buddenhagen wrote:
> the easiest would be going with the normal approval rights, but limit
> the submit button to a "QUIP owners" group which would consist of lars
> (and possibly a _few_ deputies).

Considering expected traffic there it could be only Lars :-)

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] cdn.qt.digia.com SSL certificate has expired

[Jędrzej Nowacki]

On torsdag 10. november 2016 11.39.14 CET Arnaud Vrac wrote:
> Hi,
> 
> I'm trying to run MaintenanceTool on my Qt commercial install and it fails,
> apparently because the SSL certificate to cdn.qt.digia.com has expired.
> This also prevents using the online installer.
> 
> Can this please be fixed ?
> 
> Thanks,
> 
> -Arnaud

I have forwarded this email to our IT. Should be fixed soon.

Thanks,
   Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Removal of some of the blacklisted (non-working) autotests?

[Jędrzej Nowacki]

On torsdag 3. november 2016 09.17.57 CET Milla Pohjanheimo wrote:
> I would like to challenge you a bit about removal of (some of) the
> blacklisted autotests. 
> (...)

Hi,
 
In your email you wrote that blacklisted is just a burden for CI. In 
general it is true, but mark that currently they are compiling and they are 
_not_ crashing. So they do contribute to the quality of Qt. On the other hand 
they artificially increase test coverage level hiding untested code paths and 
they may affect other tests.

Partial conclusion: delete them, but watch code coverage and add new ones 
where needed.

Eddy mentioned that tests are documenting certain Qt usages. There are two 
aspects of it. In many cases, we do not know what author of a test wanted to 
test, sometimes it was a use case, sometimes it was just an internal code path 
in the implementation. On the other hand, we know that the code is not working 
in a reliable way, therefore in reality it is a misleading documentation. 
Moreover developers tends to do copy coding and coping a blacklisted 
test is just plain wrong, while being very difficult to catch in code review.

Partial conclusion: delete them, but add a policy that every test should 
contain a short comment what is the purpose of the test.

Some tests are blacklisted only on certain platforms. Depending on the reason 
why the test is not working on a specific platform, we need to handle them 
differently. In general it is ok to assume that Qt as well as Qt bugs are 
cross platform. So a test failing only on one of them is failing because of a 
platform specific code (we do not have so much of it) or it is wrongly 
blacklisted or it hits a bug in a platform itself.

Partial conclusion: the test delivers an interesting information. It is worth 
to spend a bit of time and check what is going on. A tool that do a stress 
test of a test would be a really good addition, as it would simplify 
debugging.

Conclusion: I believe we should delete them, but be smart about that. Don't 
just go and remove all of them, but first build infrastructure / process that 
allows us to not decrease the test coverage. Even more, we need something that 
would not allow flaky, badly written test to be merged to Qt in the first 
place, 
otherwise we would have that discussion again in next 12 months.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Coin news

[Jędrzej Nowacki]

On onsdag 26. oktober 2016 11.28.28 CEST Oswald Buddenhagen wrote:
> that's indeed better in the optimal case:
> 1. prepare downstream module and update upstream module
> 2. have them integrated into qt5. make sure that the upstream update
>does not go in before the downstream adjustment (you can generally
>assume an atomic integration).
> 3. clean up both modules
> 4. have them integrated into qt5. make sure the upstream cleanup does
>not go in before the downstream cleanup.
The only problem is that you have to be sure to prepare downstream module 
right, because only one code path will be tested, but it is still ok. Btw. 
earlier by referring to a two steps process I meant that you need to 

> another good thing about this variant is that you can atomically fix
> issues introduced due to signal/slot overloading, which you'd otherwise
> have to do separately in advance, introducing yet another two-stage
> integration.
Yes.

> a downside is that the history is messier, because there are inherently
> at least two commits in every downstream module. and it may get even
> more messy if you notice later in the process that you need to adjust
> the downstreams further before the qt5 integration succeeds. that's
> because the downstream integrations are basically dummies and you don't
> notice that something went wrong until the qt5 integration which pulls
> in the upstream change.
I would not be worried about history too much, it just reflects the reality. I 
had idea to mitigate the late discovery problem by adding a 2nd job to CI that 
would do a fast qt5  incremental build check just on Linux. With proper setup 
(unionfs like partitions) and reduced load (that we've achieved) we could 
potentially run it for every patch set. 

Cheers,
  Jędrek

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Module maintainers: action required (Coin migrates from sync.profile to .gitmodules on 28.09.2016)

[Jędrzej Nowacki]

On tirsdag 13. september 2016 08.25.10 CEST Jędrzej Nowacki wrote:
> On fredag 19. august 2016 08.52.59 CEST Jędrzej Nowacki wrote:
> > On torsdag 18. august 2016 17.46.41 CEST Dominik Holland wrote:
> > > How are the dependencies managed for projects/modules which are not part
> > > of the qt5.git but are part of coin ?
> > > 
> > > Dominik
> > 
> > That is the reason of migrating "slowly". We need to define/find a product
> > repository for them. Such super repository would define testing platforms,
> > configurations and dependencies configurations. For experimental modules
> > and in general, playground I would propose to create "qt-labs" product.
> > Cheers,
> > 
> >   Jędrek
> 
> Hi,
> 
>   In addition to what I said before "product less" modules, which we should
> not have, by default will depend on all Qt5 modules, so we can test them
> anyway.
> 
> Cheers,
>   Jędrek
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Hi,

  Friendly reminder about dropping support for sync.profile in favor of 
.gitmodules. The new code will be deployed on on Wednesday (28.09.2016) unless 
I will find some major breakages to that point. 

Cheers, 
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Jędrzej Nowacki]

On mandag 19. september 2016 09.20.48 CEST Thiago Macieira wrote:
> This code was there in Qt 5.0, so I kept it when I refactored the numeric
> comparisons. Now, dealing with QTBUG-56073, I'm wondering if it should be
> there in the first place.
> 
> Should we do fuzzy comparisns in QVariant?
> 
> Note that the fuzzy comparisons are always performed in qreal precision
> (whichever that may be), regardless of whether the original number is float,
> double or an integer.

No. I think we should avoid it, there are to many side effects of such 
behavior change.

Cheers,
  Jędrek

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Jędrzej Nowacki]

On fredag 23. september 2016 11.22.08 CEST Olivier Goffart wrote:
>   template
>   auto registerEqualityOperator() 
> -> decltype(std::declval() == std::declval()) 

I have tried it already. Sadly it breaks terribly in case of private/protected 
operators. It doesn't solve the problem, because types may got converted just 
to satisfy operator== type requirements. In addition it causes small perf 
problems.

So QVariant::operator== is broken and it is not fixable without _major_ 
breakages.   

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Behaviour change in QML in Qt 5.8 regarding null

[Jędrzej Nowacki]

On mandag 19. september 2016 11.14.51 CEST Chris Adams wrote:
> Hi,
> 
> Recently, a few unit test failures[1] in the (unreleased) QtPIM module
> showed that the recent change[2] which changes the semantics of null
> assignment (from JS) to a QVariant Q_PROPERTY can affect existing client
> code.
> 
> Certainly, the cases which are affected are most likely edge-cases (that
> is, specifically testing the type or value of the QVariant within C++ code
> to detect "null" assignment), however it is probably worth raising for
> discussion.
> 
> Why was the change made?  The commit message tells us what was changed, but
> not the reasoning behind the change.  The unit tests were changed, so the
> behaviour change was clearly intentional (and the old behaviour considered
> problematic), and I assume that there must be very good reasons to make
> such a change, but it wasn't discussed on the mailing list, so I don't know
> what those reasons are.
> 
> Best regards,
> Chris.
> 
> [1] https://codereview.qt-project.org/#/c/170491/
> [2] https://codereview.qt-project.org/#/c/167062/
> 
> 
> www.qinetic.com.au - Qt And QML User Experience Specialists

Hi,

There are many reasons, mostly related to C++11 (in more or less chronological 
order):
 - 5.8 depends on C++11 that has null defined sensibly so we want to use it to 
mark null values.
 - std::nullptr_t became registered type which is meant to be use for null 
values
 - QJson support got better null handling (the feature was waiting for 
std::nullptr_t in metatype)
 - using (void*)0 for null in QVariant was suboptimal as it could not detect 
invalid states like for example (void*)1

I guess there are more from QML perspective.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QDataStream: blackbox or document all versions?

[Jędrzej Nowacki]

On lørdag 24. september 2016 20.58.38 CEST Thiago Macieira wrote:
> A thread[1] on the interest mailing list started when someone asked for the
> docs for the current format of the QDataStream wire protocol, to which I
> replied that it doesn't exist as we don't maintain such docs.
> 
> Long story short, we have two options:
> 
> Option 1: claim QDataStream is a blackbox and tell people that the only
> thing that can read QDataStream is QDataStream. That means removing the
> documentation file src/corelib/doc/src/datastreamformat.qdoc, as we don't
> want people getting any ideas that they could write their own decoders or
> encoders.
> 
> Option 2: the opposite, saying that reading QDataStream's output is fine
> from non-Qt code and it's fine to write data that QDataStream should read.
> This means extending the documentation to cover ALL 17 wire formats
> (including bugs) and keeping it up to date whenever someone modifies the
> format.
> 
> 
> I am in favour of Option 1 because I really don't think QDataStream is a
> good format for exchanging data with non-Qt code. It's designed first and
> foremost for Qt's own internal data formats (sometimes even depending on
> internal details), the marshalling of certain types in certain versions is
> buggy and lossy. Instead, people should find a better transport format for
> their data, of which we already have in Qt:
> 
>   XML
>   JSON
>   D-Bus
>   QSettings (to an extent)
> 
> And I can add CBOR support if we want to.
> 
> [1]
> http://lists.qt-project.org/pipermail/interest/2016-September/024387.html

Hi,

 Option 4: Document only basic types, like char, int, maybe QByteArray and 
QString, QVector. Everything above is tight to Qt implementation and therefore 
is super hard to use from 3rd party perspective as it is changing often.

  But I agree with you QDataStream is not a good format for exchanging data 
with non-Qt code so option 1 is Ok too.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] [FYI] on gerrit change retargeting requests

[Jędrzej Nowacki]

On mandag 12. september 2016 14.39.57 CEST Orgad Shaneh wrote:
> On Tue, Sep 6, 2016 at 12:56 PM, J-P Nurmi  wrote:
> > On 06 Sep 2016, at 11:46, Konstantin Tokarev  wrote:
> > > 06.09.2016, 12:44, "Oswald Buddenhagen" :
> > >>> On Mon, Sep 05, 2016 at 09:17:59PM +, J-P Nurmi wrote:
> > >>>  On 05 Sep 2016, at 19:27, Marc Mutz  wrote:
> > >>>  > It's not about restricting what a user can do. It's simply missing
> > >>>  > implementation, and I believe that if it were easy to implement,
> > >>>  > Ossi would have done it long ago instead of playing retarget-monkey
> > >>>  > for the rest of us :)
> > >>>  
> > >>>  Doing it through the web UI would be a nice bonus, but having access
> > >>>  to the same script that is already used by the admins would be good
> > >>>  enough for starters.
> > >> 
> > >> yep - because i'm totally going to give everyone full write access to
> > >> the database. ;)
> > >> 
> > >> if you make a secure web frontend that authenticates against qt account
> > >> and verifies change ownership using the gerrit ssh interface, i'm
> > >> totally willing to deploy that. ;)
> > > 
> > > Idea: IRC bot accepting retarget requests, with rate limit e.g. one
> > 
> > request per minute. Bot runs on host with db access and can do only this
> > one thing.
> > 
> > Another idea: patch Gerrit to change the target branch (and create a new
> > patchset version to reset scores) when pushing to a different branch.
> 
> I have another suggestion, which should be quite easy to implement.
> 
> Either extend the sanity bot, or create a new bot, which listens on
> gerrit's event stream.
> 
> If *the change's owner* (or an approver?) posts a comment reading "Please
> retarget ", run your script on the server side. You need some
> sanity test that ensures this branch exists etc...
> 
> What do you say?
> 
> - Orgad

Actually that work is ongoing :-) I just need get a proper account in the 
right db.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Module maintainers: action required (Coin slowly migrates from sync.profile to .gitmodules)

[Jędrzej Nowacki]

On fredag 19. august 2016 08.52.59 CEST Jędrzej Nowacki wrote:
> On torsdag 18. august 2016 17.46.41 CEST Dominik Holland wrote:
> > How are the dependencies managed for projects/modules which are not part
> > of the qt5.git but are part of coin ?
> > 
> > Dominik
> 
> That is the reason of migrating "slowly". We need to define/find a product
> repository for them. Such super repository would define testing platforms,
> configurations and dependencies configurations. For experimental modules and
> in general, playground I would propose to create "qt-labs" product.
> Cheers,
>   Jędrek
 
Hi,

  In addition to what I said before "product less" modules, which we should 
not have, by default will depend on all Qt5 modules, so we can test them 
anyway.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] CI/5.6: "Failed 7 times to aqcuire the hardware" (was: Fwd: Change in qt/qtbase[5.6]: qstrncpy: don't call strncpy_s with invalid parameters)

[Jędrzej Nowacki]

On torsdag 1. september 2016 15.22.29 CEST Marc Mutz wrote:
> Hi,
> 
> Twice in succession.
> 
> Any idea what's happening?
> 
> Thanks,
> Marc

Yes, more or less. vSphere is overloaded and it shows that it doesn't like 
it... Anyway write a bug report for it. Especially if you see it again. As for 
know I have seen it 2 times in last 5-6 months, so I hope it is minor.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Module maintainers: action required (Coin slowly migrates from sync.profile to .gitmodules)

[Jędrzej Nowacki]

On torsdag 18. august 2016 17.46.41 CEST Dominik Holland wrote:
> How are the dependencies managed for projects/modules which are not part
> of the qt5.git but are part of coin ?
> 
> Dominik
That is the reason of migrating "slowly". We need to define/find a product 
repository for them. Such super repository would define testing platforms, 
configurations and dependencies configurations. For experimental modules and in 
general, playground I would propose to create "qt-labs" product.
Cheers,
  Jędrek

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Module maintainers: action required (Coin slowly migrates from sync.profile to .gitmodules)

[Jędrzej Nowacki]

Hi,

Short version:
  We plan to migrate from using sync.profile to qt5/.gitmodules in Coin, so 
please make sure that the files are in sync and that they contain sensible 
informations in every actively maintained branch.

Long version:
  Currently, for every integration Coin is reading module dependency from 
sync.profile which is stored in the root directory of every module. The file 
contains section that looks more or less like that:
  %dependencies = (
  "qtbase" => "",
  "qtxmlpatterns" => "",
  );
Which means that the module depends on qtbase and qtxmlpatterns. Now this 
approach happened to be not flexible enough, as it doesn't allow  to easily 
define an alternative dependency chain without changing content of the module 
or forcing rebuild of depending modules. We want to migrate to qt5/.gitmodules 
that looks like that:
  [submodule "qtdeclarative"]
  depends = qtbase
  recommends = qtsvg qtxmlpatterns
  path = qtdeclarative
  url = ../qtdeclarative.git
  branch = dev
  status = essential
As it leave outside of the module we can easily use a shadow definition that 
overwrites certain aspects of it. As a bonus changing .gitmodules would 
trigger partial qt5 check, verifying if all leaf modules are intact.
For integrations Coin will use union of "depends" and "recommends" fields.

Thank you!
  Jędrek

ps. I heard rumors that Oswald want deprecate sync.profile too :-)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Which changes are suitable for 5.6?

[Jędrzej Nowacki]

On fredag 12. august 2016 10.52.52 CEST Marc Mutz wrote:
> Hi,
> 
> I'd like to know what the rules are supposed to for submitting to 5.6 (LTS).
> 
> Should we enforce the strict rules of other minor releases (only regressions
> and P2+)?
I strongly believe that autotests improvements should go to LTS, flaky and 
broken tests affect all branches.
 
Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Programs crashing left and right in the CI

[Jędrzej Nowacki]

On Tuesday 02 of August 2016 17:17:59 Thiago Macieira wrote:
> On quarta-feira, 3 de agosto de 2016 01:05:00 PDT Giuseppe D'Angelo wrote:
> > On Thu, Jul 28, 2016 at 10:06 AM, Michal Klocek  
wrote:
> > > It seems to happen in different modules (here qttools and qtlocation)
> > > and in different branches (here dev and 5.6), but on mac/clang and
> > > during
> > > moc compilation.
> > 
> > Now I've got an ICE:
> > 
> > http://testresults.qt.io/logs/qt/qtbase/920ef98db1070f97042845877e2fe61caa
> > 27
> > e241/OSXOSX_10_10x86_64IOSIOS_ANYmultiClangqtci-osx-10.10-x86_64DebugAndR
> > ele
> > ase_DisableTests_Static/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog
> > .tx t.gz
> 
> Ok, this is the first time that the compiler itself has crashed. Can you
> retry the integration with the exact same commits in the same order? If it
> crashes again compiling .obj/debug-iphoneos/qjsonparser.o, it's a compiler
> bug. If it passes, then we can't exclude compiler bug, but it's more likely
> to be a HW fault.
> 
> Were there any changes to any files that could be used as source to
> qjsonparser.cpp (qmake, mkspec or other QtCore changes)?

I asked to check the node.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New Coin feature: automatic provisioning

[Jędrzej Nowacki]

On Wednesday 27 of July 2016 13:58:44 Dominik Holland wrote:
> Hi,
> 
> Am 07/27/2016 um 01:47 PM schrieb Jędrzej Nowacki:
> > Hi,
> > 
> >   Good news everyone! Last month we managed to deploy a new automatic
> > 
> > provisioning system to Coin. What does it mean to you? Now you can modify
> > existing VM templates used by Coin. Installing additional packages should
> > be trivial and more or less safe from now.
> > 
> >   I. The goal:
> >   - Coin should use VMs with vanilla OS installations (aka base template)
> >   - Anything that needs to be installed in addition should be documented,
> > 
> > reproducible in an automatic way (create a provisioned template)
> > 
> >   - templates may be only modified in such way that the _whole_ Qt still
> >   works> 
> > on a VM create from it
> > 
> >   - It should not be required to log in to a VM to modify it
> >   
> >   II. So how it works now:
> >   Qt5 is our product repository. The product repository contains directory
> > 
> > called "coin/provisioning", which contains provisioning scripts used
> > against base templates to produce provisioned templates. When an
> > integration starts on a certain platform, it checks for the directory. If
> > base platform template name matches one of the subdirectories then all
> > scripts in the subdirectory are used to provision the new template. Of
> > course the result is cached and re- used for all integrations that needs
> > it.
> > 
> >   III. Qt Developer oriented example:
> >   We need to install FooBar on Ubuntu 14.04
> >   
> >   1. Prepare bash script that installs it:
> >  #!/bin/env bash
> >  # Package FooBar is need to ... and can be safely removed if ...
> >  apt install FooBar
> >   
> >   2. Place it in the product repository (Qt5) in
> >   coin/provisioning/qtci-linux-> 
> > Ubuntu-14.04-x86_64/ under foobar.sh name.
> > 
> >   3. Commit it to the right branch (5.6..dev) depending where the package
> >   is
> > 
> > needed
> > 
> >   4. Get through the review, by default we do __not__ want any additional
> > 
> > software on VMs, so you need to have a good reason to install something
> > 
> >   5. Stage the change together with a recent submodule update
> >   6. If it pass then you can enjoy FooBar in your code
> >   7. Follow-up on Qt5 merges, to ensure that FooBar is installed in right
> > 
> > branches and only in them
> > 
> >   Be aware that provisioning scripts are tested against Qt5 state while
> >   newly
> > 
> > provisioned templates are used for all integrations. So technically it is
> > possible to break stuff if Qt5 is old or if a breakage was integrated
> > during Qt5 testing. In reality I do not think it would affect anyone, but
> > that is why in point 5 I recommend to staging together with a recent
> > submodule update.> 
> >   Currently only bash and powershell are supported.
> >   
> >   If you want to share a script between different platforms (for example
> > 
> > Ubuntu 14.04, and Ubuntu 16.04) you place it in
> > "coin/provisioning/common".
> > Then you can call it from any other "coin/provisioning" subdirectory.
> > 
> >   The current naming convention for base templates is suboptimal and it
> >   will
> > 
> > be changed in a reasonable future, but you should not worry about that,
> > the
> > process will be transparent (TM).
> > 
> > Cheers,
> > 
> >   Jędrek
> > 
> > ps. The feature consists of a few dozen patches and the probability says
> > that there is at least one bug, so keep your eyes open.
> 
> great news !
> 
> Does the provisioning only work for the qt5 repository or does it also
> work for each of the modules ?
> 
> E.g. Could there be a provisioning script in qtmultimedia, installing
> some of the dependencies e.g. gstreamer1.0-dev ?
> 
> Dominik
> 

Qt5 repository contains definition for all modules. All modules shares the same 
set of machines(*). There is no direct way to install something just for one 
module. Technically you could install something to a custom place and export a 
environment variable, which would be used only by one module. I advice against 
that. 

The feature is useful for installing software that is already shipped by a 
distribution but just not installed by default. Regarding gstreamer1.0, the 
problem is that in RHEL 6 it doesn't exist at all therefore it would need to 
be compiled from sources and then we would need to ship gstreamer binaries... 
So, no the feature do not solve qstreamer case :(

Cheers,
 Jędrek

*there are tricks to opt-out and opt-in, they but should be avoided
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] New Coin feature: automatic provisioning

[Jędrzej Nowacki]

Hi,

  Good news everyone! Last month we managed to deploy a new automatic 
provisioning system to Coin. What does it mean to you? Now you can modify 
existing VM templates used by Coin. Installing additional packages should be 
trivial and more or less safe from now.

  I. The goal:
  - Coin should use VMs with vanilla OS installations (aka base template)
  - Anything that needs to be installed in addition should be documented, 
reproducible in an automatic way (create a provisioned template)
  - templates may be only modified in such way that the _whole_ Qt still works 
on a VM create from it
  - It should not be required to log in to a VM to modify it

  II. So how it works now:
  Qt5 is our product repository. The product repository contains directory 
called "coin/provisioning", which contains provisioning scripts used against 
base templates to produce provisioned templates. When an integration starts on 
a certain platform, it checks for the directory. If base platform template 
name matches one of the subdirectories then all scripts in the subdirectory 
are used to provision the new template. Of course the result is cached and re-
used for all integrations that needs it.

  III. Qt Developer oriented example:
  We need to install FooBar on Ubuntu 14.04
  1. Prepare bash script that installs it:
 #!/bin/env bash
 # Package FooBar is need to ... and can be safely removed if ...
 apt install FooBar
  2. Place it in the product repository (Qt5) in coin/provisioning/qtci-linux-
Ubuntu-14.04-x86_64/ under foobar.sh name. 
  3. Commit it to the right branch (5.6..dev) depending where the package is 
needed
  4. Get through the review, by default we do __not__ want any additional 
software on VMs, so you need to have a good reason to install something
  5. Stage the change together with a recent submodule update
  6. If it pass then you can enjoy FooBar in your code
  7. Follow-up on Qt5 merges, to ensure that FooBar is installed in right 
branches and only in them

  Be aware that provisioning scripts are tested against Qt5 state while newly 
provisioned templates are used for all integrations. So technically it is 
possible to break stuff if Qt5 is old or if a breakage was integrated during 
Qt5 testing. In reality I do not think it would affect anyone, but that is why 
in point 5 I recommend to staging together with a recent submodule update.

  Currently only bash and powershell are supported.

  If you want to share a script between different platforms (for example 
Ubuntu 14.04, and Ubuntu 16.04) you place it in "coin/provisioning/common". 
Then you can call it from any other "coin/provisioning" subdirectory.

  The current naming convention for base templates is suboptimal and it will 
be changed in a reasonable future, but you should not worry about that, the 
process will be transparent (TM).

Cheers,
  Jędrek

ps. The feature consists of a few dozen patches and the probability says that 
there is at least one bug, so keep your eyes open.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Programs crashing left and right in the CI

[Jędrzej Nowacki]

On Wednesday 27 of July 2016 08:28:08 Friedemann Kleint wrote:
> Hi,
> 
> to summarize for Windows:
> 
> - Crashes have been observed over time in various tests, mostly in
> QtCore (QDir,QFile, QProcess see fex
> https://bugreports.qt.io/browse/QTBUG-47370
> 
> - It only affects 64bit (!) (correct me if you have observed otherwise)
> 
> - It never has been observed for MinGW (most likely since we don't have
> 64bit MinGW builds?)
> 

Nice list, it matches my observations too. 

Just note that up to now significant % of problems could be reproduced with 
valgrind + taskset + execution in a loop. Of course not in case of Windows 
specific code...

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Programs crashing left and right in the CI

[Jędrzej Nowacki]

On Tuesday 26 of July 2016 15:30:48 Thiago Macieira wrote:
> Em terça-feira, 26 de julho de 2016, às 23:24:21 PDT, Giuseppe D'Angelo
> 
> escreveu:
> > On Mon, Jul 25, 2016 at 5:51 PM, Thiago Macieira
> > 
> >  wrote:
> > > Let's pay attention of what crashes and where. But we'll need to
> > > reproduce
> > > this in order to debug it.
> > 
> > It just happened again:
> > 
> > http://testresults.qt.io/logs/qt/qtbase/ddfe2ba984be5d652fe500f6695040959d
> > b9
> > 8fa4/OSXOSX_10_11x86_64OSXOSX_10_11x86_64Clangqtci-osx-10.11-x86_64DebugA
> > ndR
> > elease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz
> This is a crash on Linux, with "core dumped", albeit in a unit test, not
> moc:
> 
> http://testresults.qt.io/logs/qt/qtbase/
> 47fa5811ef59b06d8d512b565db856c5c3bc5478/
> LinuxUbuntu_14_04x86_64LinuxUbuntu_14_04x86_64GCCqtci-linux-Ubuntu-14.04-
> x86_64-be23deNoWidgets_ForceDebugInfo/
> 85d6b000f945a84bc84a4f01f53ac65bc05cbe86/testrun_1469528656/testlog.txt.gz
> 
> Any chance we can get the backtrace of that crash?

No, the machine gets destroyed after test failure. Normally gdb session is 
attached to crashing process, that was not the case for some odd reason. Can 
it be that QTestLib is crashing too?

There is feature request to upload core dumps 
(https://bugreports.qt.io/browse/QTQAINFRA-990) .

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Programs crashing left and right in the CI

[Jędrzej Nowacki]

On Monday 25 of July 2016 10:27:30 Thiago Macieira wrote:
> On segunda-feira, 25 de julho de 2016 08:51:36 PDT Thiago Macieira wrote:
> > On segunda-feira, 25 de julho de 2016 14:07:04 PDT Jędrzej Nowacki wrote:
> > > Ugh I haven't seen link.exe crashing, but in case of moc I have
> > > impression
> > > that it is a software problem. I remember that first time I have seen it
> > > I
> > > was  quite surprised, but now it is quite common and it happens mostly
> > > (only) on OSX (Clang miss-compilation?). If it would be memory then I
> > > would
> > > expect to see compiler crashing more often and I have experienced it
> > > maybe
> > > once...
> > > 
> > > Any other idea what can go wrong or what can be checked?
> > 
> > The fact that it is consitently crashing on moc indicates the problem is
> > actually moc or the compiler. You're also right that most of the crashes
> > are on macOS. I can't remember if I've seen it on other OSes. This
> > link.exe crash is a one-off and I haven't seen others.
> > 
> > Let's pay attention of what crashes and where. But we'll need to reproduce
> > this in order to debug it.
> 
> tst_qdir.exe crashed on Windows, on Qt 5.6:
> 
> A crash occurred in C:\Users\qt\work\qt\qtbase\tests\auto\corelib\io\qdir
> \release\tst_qdir.exe.
>  Function time: 2728ms Total time: 2731ms
> 
>  Exception address: 0x7FF8DB7367B4
>  Exception code   : 0xc005
>  PASS   : tst_QDir::entryList(Sorting QDir::Type | QDir::DirsFirst)
>  PASS   : tst_QDir::entryList(Sorting QDir::Size)
>  PASS   : tst_QDir::entryList(Sorting QDir::Size | QDir::Reversed)
>  SKIP   : tst_QDir::entryListTimedSort() /bin/touch not found
>  tst_qdir.cpp(869) : failure location
>  PASS   : tst_QDir::entryListSimple(data2)
>  PASS   : tst_QDir::entryListSimple(simple dir)
>  PASS   : tst_QDir::entryListSimple(simple dir with slash)
>  Nearby symbol: DllUnregisterServer
> 
>  Stack:
>  #  1: QTest::toString() - 0x7FF8DEC08CD0
>  #  2: UnhandledExceptionFilter() - 0x7FF8E4001AD0
>  #  3: TpDbgDumpHeapUsage() - 0x7FF8E6D01BE0
>  #  4: TpDbgDumpHeapUsage() - 0x7FF8E6D01BE0
>  #  5: memset() - 0x7FF8E6C95140
>  #  6: _C_specific_handler() - 0x7FF8E6C82800
>  #  7: wcstok_s() - 0x7FF8E6C8D8C0
>  #  8: _chkstk() - 0x7FF8E6C93E70
>  #  9: RtlRaiseException() - 0x7FF8E6C53920
>  # 10: KiUserExceptionDispatcher() - 0x7FF8E6C93060
>  # 11: DllUnregisterServer() - 0x7FF8DB7097B0
>  # 12: DllUnregisterServer() - 0x7FF8DB7097B0
>  # 13: DllUnregisterServer() - 0x7FF8DB7097B0
>  # 14: DllGetActivationFactory() - 0x7FF8DC9D1860
>  # 15: DllGetActivationFactory() - 0x7FF8DC9D1860
>  # 16: DllGetActivationFactory() - 0x7FF8DC9D1860
>  # 17: DllGetActivationFactory() - 0x7FF8DC9D1860
>  # 18: DllGetActivationFactory() - 0x7FF8DC9D1860
>  # 19: SwMemFree() - 0x7FF8E3E29770
>  # 20: SwMemFree() - 0x7FF8E3E29770
>  # 21: QueryProtectedPolicy() - 0x7FF8E3F45C80
>  # 22: RtlGetActiveActivationContext() - 0x7FF8E6C1C6B0
>  # 23: RtlFreeUnicodeString() - 0x7FF8E6C37100
>  # 24: BaseThreadInitThunk() - 0x7FF8E44B13B0
>  # 25: RtlUserThreadStart() - 0x7FF8E6C15410
> 
> http://testresults.qt.io/coin/integration/qt/qtbase/tasks/
> 1469463068.thrift_bin

tst_qdir is known to be "ugly" it was backlisted for months and probably re-
added https://bugreports.qt.io/browse/QTBUG-50835 recently. The bug mentioned 
CI load, we see increased failure rate when the machinery is over a bigger 
load (~140 vms), but there are always more or less the same tests failing. So 
my interpretation is that tests/qt has a race condition that is exposed if IO 
gets slower. CPU and RAM are reserved separately without overallocation for 
every machine, so they do not overlap too much*.

So let's concentrate on code / apps that should be rock solid which are 
compilers, linkers and such.

Cheers,
 Jędrek

*CPU reservation is done in Mhz instead of cores, which may cause problems we 
try different tricks to enforce CPU affinity, but they are just "hints" to the 
VSphere scheduler.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Programs crashing left and right in the CI

[Jędrzej Nowacki]

On Friday 22 of July 2016 13:25:19 Thiago Macieira wrote:
> For the past month or so, I've noted an increase in the number of crashes in
> applications that shouldn't be otherwise crashing. I first saw it with moc
> (Segmentation fault) and I thought my change was at fault. But it's been
> happening with other changes, even before my changes went in.
> 
> Now I ran into a link.exe internal error:
> 
> LINK : fatal error LNK1000: Internal error during LIB::Search
> 
>   Version 14.00.23918.0
> 
>   ExceptionCode= C005
>   ExceptionFlags   = 
>   ExceptionAddress = 7FF64939415B (7FF64937) "C:\Program
> Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\link.exe"
>   NumberParameters = 0002
>   ExceptionInformation[ 0] = 
>   ExceptionInformation[ 1] = 00020226BDF8
> 
> Can someone check whether there are memory problems in some of the CI
> machines?

As far I know it is actually happening, some machines have been already 
checked. Every thing was fine :( We blacklisted some blades that were suspected 
to be broken, but as far I know there is no prove. 

Ugh I haven't seen link.exe crashing, but in case of moc I have impression 
that it is a software problem. I remember that first time I have seen it I was 
quite surprised, but now it is quite common and it happens mostly (only) on 
OSX (Clang miss-compilation?). If it would be memory then I would expect to 
see compiler crashing more often and I have experienced it maybe once...

Any other idea what can go wrong or what can be checked?

Cheers,
 Jędrek

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Why is QVariant::data() \internal?

[Jędrzej Nowacki]

On Wednesday 20 of July 2016 13:50:49 Olivier Goffart wrote:
> On Montag, 18. Juli 2016 23:15:22 CEST Konrad Rosenbaum wrote:
> > Hi,
> > 
> > On Monday 18 July 2016 07:59:21 Jędrzej Nowacki wrote:
> > > On Saturday 16 of July 2016 13:56:00 Konrad Rosenbaum wrote:
> > > > I am currently interfacing two libraries that only have QVariant in
> > > > common, most of the (value) types getting exchanged are either Qt
> > > > containers or Q_GADGETs.
> > > > 
> > > > I was relatively quick to realize that I needed the QMetaType and
> > > > QMetaObject of these objects, but it took me pretty long to find out
> > > > that I can use QVariant::data() to get at the void* that I need to
> > > > access properties and Q_INVOKABLEs.
> > > > 
> > > > Is there a particular reason that QVariant::data() is classified as
> > > > \internal or would a documentation patch be accepted?
> > > 
> > > Mostly because it should not be needed.
> > 
> > I can see why it should not be needed in 95% of situations. But there is
> > this tiny little fraction of cases in which QVariant is the only
> > commonality between interfaces. Esp. if those interfaces are supposed to
> > be generic, non-related and exchangeable.
> > 
> > I'd argue it is needed often enough to merit some documentation with a big
> > fat warning for the other 95% of cases.
> > 
> > > Why can't you use https://doc.qt.io/qt-5/qvariant.html#value or
> > > https://doc.qt.io/qt-5/qvariant.html#qvariant_cast ?
> > 
> > The library that is looking into the QVariant is a generic
> > calculation/templating engine that uses QVariant to exchange data with
> > whatever outside caller is using its services.
> > 
> > It does not know what kind of data types the calling code uses - all it
> > can
> > assume is that it gets property names to find the values it is really
> > looking for. It does not even know why it is being used.
> > 
> > The data source may be the calling code or it may be a completely
> > unrelated
> > library.
> > 
> > Example:
> > Lets assume the engine is configured to work on strings and it gets the
> > formula {'I am ' + my1.name} and "my1" is configured to be a pointer to a
> > QObject-derived class or a Q_GADGET. The formula itself will usually come
> > from some kind of configuration (otherwise: what's the point!). What the
> > library code does is parse the formula, delve into the QObject or gadget
> > behind "my1" and retrieve the property "name".
> > 
> > For some use cases demanding that structured types are QObject is simply
> > not feasible since the remainder of the use case may demand value logic
> > (in my current specific case it represents data exchanged over the
> > network).
> > 
> > Writing a formula parser is complex enough for me to definitely not
> > wanting
> > to tie it to one specific application - hence I do not want it to know the
> > specific structured types - I want it to explore those types through some
> > kind of reflection - turns out QMetaType/QMetaObject is a wonderful way of
> > doing this.
> 
> I think indeed, with the recent Q_GADGET change, there is indeed a reason to
> document QVariant::data/constData or QMetaType::IsGadget

Just small remainder why it was not public from the beginning.
auto v1 QVariant::fromValue(gadget);
auto v2 = v1;
At that point you do not know if v1 and v2 keeps the same gadget instance or 
just a copy of it. It may not be a problem if you call just a "getName() 
const" function because it is likely to return the same (unless "this" pointer 
is part of the name :P), but not pure method and especially something that  
alters mutable members would effect in code impossible to reason about.

I hope that would be a safer option from API perspective, Anyway I can not 
think about any alternative and it is super safe to say that QVariant::data() 
method will stay forever. 

Cheers,
 Jędrek


 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Why is QVariant::data() \internal?

[Jędrzej Nowacki]

On Saturday 16 of July 2016 13:56:00 Konrad Rosenbaum wrote:
> Hi,
> 
> I am currently interfacing two libraries that only have QVariant in common,
> most of the (value) types getting exchanged are either Qt containers or
> Q_GADGETs.
> 
> I was relatively quick to realize that I needed the QMetaType and
> QMetaObject of these objects, but it took me pretty long to find out that I
> can use QVariant::data() to get at the void* that I need to access
> properties and Q_INVOKABLEs.
> 
> Is there a particular reason that QVariant::data() is classified as
> \internal or would a documentation patch be accepted?
> 
> 
> 
>   Konrad

Mostly because it should not be needed.

Why can't you use https://doc.qt.io/qt-5/qvariant.html#value or 
https://doc.qt.io/qt-5/qvariant.html#qvariant_cast ?

Cheers,
 Jędrek?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Source break policy for function overloads

[Jędrzej Nowacki]

On Wednesday 13 of July 2016 10:44:13 Alexander Blasche wrote:
> Hi,
> 
> Yesterday, I stumbled over a break in QtSerialBus due to the addition of new
> QTimer::setInterval(..) overloads in qtbase/dev. This was introduced by
> 
> https://codereview.qt-project.org/#/c/160889/
> 
> Unfortunately this has the undesirable side effect that lines like:
> 
> q->connect(q, ::timeoutChanged, element.timer.data(),
> ::setInterval);
> 
> do not compile anymore. The function pointer to setInterval() becomes
> ambiguous. While the fix (https://codereview.qt-project.org/#/c/165034/)
> was not difficult once you know what is happening this can hit every
> customer and basically reduces the source compatibility promise into
> absurdity.
> 
> While talking to several devs in the office I could not find a congruent
> opinion on this issue. Do we or even can we care? Do we have a policy?
> 
> --
> Alex
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Hi,

 We do not have SC promise only BC. We tend to not break SC without reason, 
for example we avoid juggling with header files just to "cleanup" stuff, but 
definitely we reserve right to add overloads and new functions.  That is the 
current state, whatever it make sense or not is a different discussion. 

Cheers,
 Jędrek

 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Coin will be down on Tuesday 21st of June (6am-8am UTC+3)

[Jędrzej Nowacki]

On Tuesday 21 of June 2016 10:47:29 Jędrzej Nowacki wrote:
> On Thursday 16 of June 2016 16:22:15 Jędrzej Nowacki wrote:
> > There is datacenter hardware maintenance break on Tuesday 21st of June
> > (6am-8am UTC+3), Coin will be shutdown a bit earlier and hopefully restart
> > after.
> > Cheers,
> > 
> >  Jędrek
> 
> Seems that something got completely broken, Coin is down. Sorry.
> 
> Cheers,
>  Jędrek

Seems to work Ok for last 50 min :-)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Coin will be down on Tuesday 21st of June (6am-8am UTC+3)

[Jędrzej Nowacki]

On Thursday 16 of June 2016 16:22:15 Jędrzej Nowacki wrote:
> There is datacenter hardware maintenance break on Tuesday 21st of June
> (6am-8am UTC+3), Coin will be shutdown a bit earlier and hopefully restart
> after.
> Cheers,
>  Jędrek

Seems that something got completely broken, Coin is down. Sorry.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Coin will be down on Tuesday 21st of June (6am-8am UTC+3)

[Jędrzej Nowacki]

There is datacenter hardware maintenance break on Tuesday 21st of June 
(6am-8am UTC+3), Coin will be shutdown a bit earlier and hopefully restart 
after.
Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.8 branching & Feature Freeze

[Jędrzej Nowacki]

On Thursday 16 of June 2016 06:57:50 Tony Sarajärvi wrote:
> Hi,
> 
> Our aim was to get new platforms in immediately after the previous platforms
> branched away from dev branch. Meaning, when 5.7 branch was created and it
> branched away from dev branch, all new platforms aiming for 5.8 should have
> been put into dev branch. However, in practice it didn't quite go as
> expected. Not to blame anyone, but all focus was to get 5.6.x and 5.7.x
> out. Meaning, dev branch was left broken for several months. The individual
> submodules did pass in the CI, but the last time Qt5 has passed is 4 months
> ago.
> 
> To tackle this we agreed that we can start inserting new platforms submodule
> by submodule, but right after that we froze Coin setup so that we don't
> break 5.7.x by accident. And by having several branches, with alphas,
> betas, release candidates and releases themselves we have a lot of these
> freezes, which means that the time window, where we can put in any new
> platform, is very short. And if the submodule in dev don't happen to have
> everything merged from earlier branches and finally work, an insertion
> won't happen.
> 
> This is why we've not been successful in bringing openSUSE 42.1, Ubuntu
> 16.04, RHEL 7.2, OS X 10.11 in into dev branch albeit trying to do that for
> months.
> 
> So back to this day. Currently we can't put anything new in, since Coin
> setup is frozen. We have holidays coming up and we have a skeleton crew
> working the entire summer. Right as we get back to work, we have 5.8 branch
> coming up and feature freeze right after that. When did you expect us to
> push in these new platforms? According to process, we shouldn't put them
> into 5.8 after FF. If we bend this rule (as we usually do), we might get
> them in there as people focus on fixing issues there, or the same thing
> happens as happened with 5.7: the new platforms simply never passed
> autotests so that they could be brought in (we actually did try to get them
> into 5.7 early on, but not lately due to release being too close).
> 
> Ok...perhaps I should propose something. Let's postpone branching 5.8. As
> much as I like the motto of Blizzard Entertainment "done when it's done" ,
> I've found that people like time schedules as well. Alas, I have to suggest
> that we postpone it as much as possible. I think that we can fix the things
> we want to fix in 5.8 in dev branch as well. When we get a more mature dev
> branch that actually works, we can generate the alpha package for 5.8 much
> faster after the branch, as 5.8 already worked right of the bat (because
> dev worked). Also, we'll get a working dev branch as well simultaneously.
> 
> Also, we've noticed that often when people fix problems found in autotests,
> being it a bug in the autotest itself or as it actually more often is, a
> problem in Qt sources themselves, people push the fix to the most mature
> branch available. In this case, when we report that we can't get openSUSE
> 42.1 in, because this and that fails, the fix is pushed into 5.6 as it
> already appears there but haven't been found or studied before. Then we
> have to sit down and in worst case wait for a 5.6.1 -> 5.6 -> 5.7 -> dev
> merge. With all the general flakiness in the system, that usually takes a
> fortnight at least.
> 
> So by fixing dev, we can skip doing merges from 5.8 -> dev when we
> eventually find the problems for these new platforms.
> 
> With regards,
> -Tony
> 
> PS: The list with new platforms actually increases yet with OS X...ehm macOS
> Sierra (10.12) beta coming up, tvOS etc...

Hi,
Ok, the process here is suboptimal, let' me extract certain aspects 
that 
can be handled separately.

Qt5 dev is in disastrous state, nobody managed to pass CI from 
February. 
Having  Qt5 working is crucial because otherwise, how can we distinguish 
between regressions in a new platform and just standard regressions. As you 
wrote Qt5 dev was not prioritized, because of two concurrent releases. That 
has to change, because state of Qt5 dev directly affects a next release. We 
have to accept the fact that we are doing 3-4 releases in parallel: LTS, 
current (potentially could be two of them) and next. Down-prioritizing one is 
just moving problems in time, which doesn't work with time based releases.

We were not updating Coin in any way for last 2 weeks. That is an 
exceptional situation. I strongly believe that in future it will not be 
requested and we will limit such freeze just to test configurations not the 
whole system. 

New platforms are features, they affect releases in exactly the same 
way as 
code. So feature freeze should apply to them too and it is great that it was 
enforced. Now, porting to new platform also should be done as a feature 
development. No need to wait for branching.

Technically waiting for merges is not necessary. Coin is able to test 
arbitrary refs from gerrit, I encourage you to not wait for the system, but 

Re: [Development] commas in ctor-init-lists

[Jędrzej Nowacki]

On Wednesday 01 of June 2016 15:44:22 Marc Mutz wrote:
> > Subjective reasons against trailling commas:
> > - It's ugly
> 
> I beg your pardon? Trailing commas are ugly? So where's the text editor
> that  folds prose text to have commas on the next line?
Aesthetics are subjective by definition, you could argue that leading commas 
are creating optically aligned result, highlighting indentation of the 
initialization list :D

> > Objective reasons in favor of leading commas:
> > - You get 1 line diffs
> 
> You get the same when you insert fields in the middle. Only at the end
> there's  a difference.
You can not always pick where you insert new field, it may cause warnings and 
bugs cause by wrong initialization order.

> > - You can comment it out by commenting only 1 line
> > - Code generators / tooling only have to touch 1 line to add or remove
> 
> All these are also valid for enums and function argument lists, but I see
> no- one doing similar things for enums and functions.
> 
> If those reasons were strong enough to do away with 100s of years of 
> typesetting history, why don't we use it for functions, too:
> 
>func(
>  loongarg1
>, lnerarg2
>, looongestarg3
> );
> 
> Hmm, sweet...
Good idea we should all that everywhere :-)

> > Weren't these reasons even a motivation for C++11 to support "trailling
> > enum comma" ?
> 
> Yes, and we should wait for / propose that they do the same change for ctor-
> init-list, too. Not apply some horrible work-around.
We have long tradition of doing stuff before C++ standard. We can not just 
drop it :P

Enough trolling :-)

Cheers 
 , Jędrek

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] commas in ctor-init-lists

[Jędrzej Nowacki]

On Wednesday 01 of June 2016 15:16:01 Andreas Aardal Hanssen wrote:
> > Den 1. jun. 2016 kl. 15.06 skrev Mark Gaiser :
> > ...
> > Funny in the coding style you mention. For operators: "An operator at the
> > end of the line is easy to miss if the editor is too narrow." The exact
> > same could be said for commas at the end of the line.
> Silly point, it's pretty much a given that there is a comma there, it's
> insignificant. But the precise operator makes all the difference.
> 
> +1 Marc, who cares if the diff is shorter or easier to read if the _code_ is
> hard to read. And butt-ugly code is hard to read. Code is easiest to read
> if it resembles English , and commas at the beginning of a line just
> doesn't.
> 
> Andreas
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Yey for coding style fights! 

I care about easy to read diffs and not every butt  is ugly :-) These days I'm 
probably reading more code then English literature (which is definitely visible 
in my mails and commit messages...) and argument about how similar code is to 
natural language is a bit odd to me, I'm not aware of any successful 
programing language that simulates natural grammar :-) . Btw. How often do you 
_read_ commas? My brain automatically skips them... In the end it simply 
doesn't matter much.

Cheers,
 Jędrek


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Announcing moc_combine

[Jędrzej Nowacki]

On Monday 30 of May 2016 10:19:38 Marc Mutz wrote:
> On Sunday 29 May 2016 18:05:07 Thiago Macieira wrote:
> > I've just pushed a feature[1] to moc that makes it process multiple
> > headers
> > at  the same time, producing only one output file
> 
> Separate compilation is not how I would recommend to use moc-generated
> files. I'd recommend to always include the moc file in the corresponding
> cpp file. That gives the compiler the whole picture and enables better
> optimisation[1] and error checking[2,3].

If moc has full picture it also can apply some nice optimizations, like for 
example here https://codereview.qt-project.org/#/c/75151/.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] dev CI integration stuck for 3½ days

[Jędrzej Nowacki]

Yes and I fixed them all on Friday with a "catch all" command. I have no clue 
how just one integration could stay locked.

Cheers,
 Jędrek

On Tuesday 17 of May 2016 12:49:17 Oswald Buddenhagen wrote:
> On Tue, May 17, 2016 at 06:08:50AM +, Simon Hausmann wrote:
> > I just looked into it and it looks like an inconsistency in the gerrit
> > database. The latest builds branch points to a set of changes that are in
> > staged state, while the change that is in integrating change is not in
> > that branch. I've found the build branch that had the integrating change
> > and rejected the change (and staged it again).
> yes, fregl (or nierob?) diagnosed that there was a network outage during
> the time the CI was supposed to report the result to gerrit, and the
> system apparently has no queue/retry mechanism for this. so it's out of
> sync now.
> Somebody (TM) needs to (re-)execute the relevant commands by hand ...
> 
> > It appears that the change was staged Friday morning and nobody noticed it
> > during Friday. Then came a long weekend, with Monday off and Tuesday also
> > off in Norway.
> > 
> > Simon
> > 
> > From: Development
> >  on behalf of
> > Thiago Macieira  Sent: Monday, May 16, 2016
> > 10:42:32 PM
> > To: development@qt-project.org
> > Subject: [Development] dev CI integration stuck for 3½ days
> > 
> > Will someone PLEASE look into the qtbase/dev integration?
> > 
> > https://codereview.qt-project.org/156523 has been integrating for (at the
> > time of writing this email) 84 and a half hours -- 3.5 days -- and that's
> > including two full working days in Finland, one in Germany and Norway as
> > today is is a bank holiday in those countries. I believe we'll break the
> > record by the time someone gets around to fixing this, if we haven't yet.
> > 
> > Let's not hope we have to wait until after tomorrow's holiday in Norway
> > for it to get back to working.
> > 
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> > 
> >   Software Architect - Intel Open Source Technology Center
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt CI reliability

[Jędrzej Nowacki]

> Determining architecture... ()
> make: Warning: File `../../../qt/qtbase/config.tests/arch/arch.pro' has
> modification time 1.3e+03 s in the future
> /home/qt/work/build/bin/qmake -qtconf /home/qt/work/build/bin/qt.conf
> -nocache -spec /home/qt/work/qt/qtbase/mkspecs/linux-g++ LIBS+=
> QMAKE_CXXFLAGS+= INCLUDEPATH+= CONFIG-=app_bundle -o Makefile
> ../../../qt/qtbase/config.tests/arch/arch.pro
> ...
> 
> agent:2016/05/05 13:07:20 build.go:221: Killed process after timeout (total
> time)
> agent:2016/05/05 13:07:20 agent.go:170: Build failed
> agent:2016/05/05 13:07:20 agent.go:127: ERROR building: Timeout after 5m0s:
> Maximum duration reached
> agent:2016/05/05 13:07:20 build.go:158: Error reading from stdout/err:
> Timeout after 5m0s: Maximum duration reached
> 
> Sean

Date and time on nodes was out of sync. Now they are still out of sync but it 
should not affect the build anymore, while unziping source code we change 
ctime and atime 30 years to the past. The "fix" is deployed, if you see the 
problem again ping me.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt CI reliability

[Jędrzej Nowacki]

On Tuesday 03 of May 2016 14:54:50 Sean Harmer wrote:
> On Monday 02 May 2016 11:14:24 Jędrzej Nowacki wrote:
> > On Saturday 30 of April 2016 20:26:20 Sean Harmer wrote:
> (...)
> What would be a *very* useful feature would be if we can trigger a test
> build of a change on a particular configuration for such cases where we
> don't have ready access to a configuration locally.
We have this feature, but it is not exposed. Qt account integration is missing 
as well as some kind of limitation to protect CI resources. If you have a 
really urgent thing to test ping me on IRC. I can run a test run for you.

> > I will ask IT about network, it seems that network interface was
> > re-configured during CI run and DHCP assigned a different IP. It should
> > not
> > happen (TM)
> 
> Yes that sort of thing should be done in a specified window out of hours
> after disabling the CI master to be able to disseminate jobs to the nodes.
Well it was not about maintenance. A node tried to re-new it's IP lease and it 
got a new IP instead of an old one. It may be some kind of DHCP miss-
configuration or operating system failed to ask in time to re-new the IP lease. 
I do not know, how on earth this could happen. I need to access logs.

> > Rule of thumb is: if logs show broken compilation it means: real problem,
> > don't blame CI. There are three main reasons, that I'm aware of, that can
> > cause the problem (sorted according to the probability):
> > 1. One of changes being integrated broke the compilation
> 
> Fine and expected and, with timely failures, not an issue.
> 
> > 2. One of module dependencies broke source compatibility
> 
> This is very rarely an issue, at least for Qt 3D.
> 
> > 3. There was a untested template update (this reason will almost disappear
> > soon)
> 
> Do you mean VM template? If so then yes that's again something that should
> ideally be verified before deployment.
Eh, wrong phrasing. Templates are tested. The problem is that the current 
process is a bit racy. Updating template is a work that require time, 
especially for testing and deployment. Regressions may appear during that time 
window. Anyway the process is about to be changed soon. 

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt CI reliability

[Jędrzej Nowacki]

On Saturday 30 of April 2016 20:26:20 Sean Harmer wrote:
> Hi,
Hi,

> after yet another 5 hour wait just to be greeted with yet another random
> failure with no build logs I'm getting really tired of the poor reliability
> of the Qt CI system.
I'm sorry about that.
 
> https://codereview.qt-project.org/#/c/157590/
> 
> has been greeted with genuine failures, failures in qtdeclarative,
> qtxmlpatterns, multiple random failures in qt3d despite being a simple
> change which I suspect are due to issues on one or more CI nodes.

I scanned through the failures and it seems that you had a very bad luck. I 
know CI should not be about luck and therefore I'm really sorry about that. 

You tried to stage the change 7 times
1. Failed to compile qt3d (broken change 
https://codereview.qt-project.org/#/c/157593/)
2. Looks like a network connectivity failure, logs were not flushed as they 
should, so you can blame CI
3. Blame CI, we failed to acquire a free machine for 5h, I will look at that 
later
4. Failed to compile qt3d (broken change 
https://codereview.qt-project.org/#/c/157590/)
5. Failed to compile qt3d (broken change 
https://codereview.qt-project.org/#/c/157590/), same as 4
6. Looks like a network connectivity failure, logs were not flushed as they 
should, so you can blame CI, same as 2
7. Passed

I will ask IT about network, it seems that network interface was re-configured 
during CI run and DHCP assigned a different IP. It should not happen (TM)

Rule of thumb is: if logs show broken compilation it means: real problem, 
don't blame CI. There are three main reasons, that I'm aware of, that can 
cause the problem (sorted according to the probability):
1. One of changes being integrated broke the compilation
2. One of module dependencies broke source compatibility
3. There was a untested template update (this reason will almost disappear 
soon)
*. There was huge radiation in Finland, but that you would know from the news 
;-)

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Coding Guidelines

[Jędrzej Nowacki]

On Thursday 17 of March 2016 12:29:46 André Somers wrote:
> Op 17/03/2016 om 11:24 schreef Mathias Hasselmann:
> > Am 17.03.2016 um 10:01 schrieb Sorvig Morten:
> >> How about treating the coding guidelines as \internal documentation?
> >> We could then at some point build and publish it together with the
> >> rest of the \internal's. (suitably separated from the public user
> >> documentation)
> > 
> > Actually having the Qt code style as public document proved to be
> > extremely useful in the past to quickly shutdown this inevitable and
> > highly annoying bike shed discussion about code style that happens at
> > the start of every other project. Also in the future I'd like to say:
> > 
> > "We do a Qt based project and for consistency I propose to follow the
> > Qt code style: It's a good and proven style guide. Just read it
> > http://wiki.qt.io/Coding_Conventions and then focus on real problems."
> 
> I actually prefer to just delegate the actual formatting style to clang
> format now and apply that automagically. Perhaps it is not perfect in
> everyones eyes, but it is better that having differences all over the
> place or wasting time on discussing tabs, spaces or the location of * or
> &. But that's layout mostly, and there is a lot more to say than that
> (naming conventions, patterns to use or avoid, etc.) You still have to
> decide on what format to use, but the default is fine by me. So in any
> style guide, I'd probably not waste any more time on the formatting
> aspects any more, and just refer to something like "we use clang format
> with the LLVM style" or something like that.
> 
> 
> André
> 

+1 

Every time someone discuss coding style issues my blood boils. I understand 
that it is important to have consistent coding style, but discussing where to 
put braces or spaces is just waste of developing time.

I'm totally for an automated solution. I would even say that every rule 
formatting related which is not expressed in some tooling aware code should 
disappear. In addition, I really do not like that sanity bot is complaining 
about typos after I pushed patches to gerrit and even worse it is commenting 
on my code instead of proposing a fix. 

As you said coding convention are a bit bigger topic, but it also should be 
automated. Seriously, rules about where to place Q_DECLARE_METATYPE or a check 
if an include is missing are quite easy to express.

So I think, that we should not discuss what is better qdoc or md. The real 
discussion is about tooling, what is the best tool to sanitize Qt code. We 
need something that:
1. Can work as a sanity bot
2. Can re-format the code by applying changes (git hook?)
3. Rules are easy to express and they can be exported (qdoc, html, fooBar)
4. Works on diff level (so it doesn't complain about the whole world being 
broken)

Bonus:
5. C++, js, qml awareness

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Coding Guidelines

[Jędrzej Nowacki]

On Friday 18 of March 2016 09:13:13 Knoll Lars wrote:
> I’m all for an automated solution for code formatting, so we can remove
> discussions/comments about wrongly placed braces or spaces from code review
> and can rather focus more on the content. But there will be still a need
> for some coding guidelines in other places (like auto usage, foreach and
> many other things).

That was my point. It starts to be really arbitrary. If we can not express a 
rule in an algorithmic way then it is not a rule it is just a hint, which 
should not end up as a -1 in code review. Auto usage is exactly one of these 
cases, some people thinks it is fine to use it almost everywhere some thinks it 
is better to avoid it. I really want to have an algorithm, I don't want to 
have slightly different coding style depending on the reviewer. Same with 
foreach, it seems that we prefer range loops now, therefore foreach should not 
be used which is easy to express as an algorithm ;-)

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ci timeouts

[Jędrzej Nowacki]

Hi,

> Just fast update on the issue. I thought that this is fixed:
> http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1456811813.thrift_
> bin Thanks for pointing it out. Time handling in virtualiazed environment is
> not reliable, and sometimes source packages are created in future... Anyway
> I know how to workaround it a fix is coming hopefully soon.
Fix is working in the production. If you ever see it again then ping me.

> Another timeout was caused because of a temporary
> network failure (https://bugreports.qt.io/browse/QTQAINFRA-969).
Workaround for the issue is already done and it will be deployed during the 
next week, we will see if it helps

Cheers,
 Jędrek

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] codereview.qt-project.org certificate has expired

[Jędrzej Nowacki]

On Sunday 06 of March 2016 09:16:13 Sean Harmer wrote:
> As per the subject. Can the sysadmins please install a new certificate
> please?
> 
> Sean
> --
> Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - Qt Experts - Platform-independent software solutions
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

I've already informed our IT support about the issue.

Thanks,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Jędrzej Nowacki]

On Monday 29 of February 2016 08:38:30 Thiago Macieira wrote:
> On segunda-feira, 29 de fevereiro de 2016 10:09:51 PST Jędrzej Nowacki 
wrote:
> > On Friday 26 of February 2016 15:56:08 Thiago Macieira wrote:
> > > > I.e. what problems would we get from having to install the
> > > > moc files?
> > > 
> > > Lots.
> > 
> > And probably all go away if instead of installing anything we use
> > QMetaObjectBuilder (assuming it's api stabilization). Yes it would have
> > performance impact, but only on the templated version and only during
> > initialization, qml is paying that price constantly without bigger
> > complains. It would not require any build system changes. The only
> > limitation I can think of right now is that in QObject, Foo needs to
> > be know to QMetaType system, which is not a big deal.
> 
> What source data do you propose for QMOB?

So for QObject moc should generate something like that:
{
QMetaObjectBuilder builder; // Side note: add overloads that takes type 
id
builder.addProperty("property", "int")
builder.addMethod("void Invokable(int)"); 
builder.setClassName("QObject<" + 
QMetaType::typeName(qMetaTypeId()) 
+ ">")
return builder.toMetaObject();
}

Yes, it is super inefficient, but in the same time I think it is quite safe to 
support. 

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] debug symbols for official Qt releases

[Jędrzej Nowacki]

On Friday 04 of March 2016 13:22:05 Ulf Hermann wrote:
> > The option is being evaluated. The main problem is that it seems that the
> > installer size grows 2x with force-debug-info enabled, we need to confirm
> > that it is not the case.
> 
> You can add the debug symbols as optional separate packages. People who need
> them can install them then, and we don't need to push larger installers to
> anyone else. In fact, the current release packages could be even smaller if
> we strip out the rudimentary debug symbols they currently contain.
> 
> regards,
> Ulf

Yes, of course we can, but it requires more work to do, so it is better to 
evaluate the size first  :-) 

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] debug symbols for official Qt releases

[Jędrzej Nowacki]

On Wednesday 02 of March 2016 09:00:35 Gunnar Roth wrote:
> >On 2016-03-01, Milian Wolff  wrote:
> >> b) Apparently there are never any debug symbols shipped for the release
> >> build fo Qt. Having debug symbols even for a release build is crucial
> >> for a good profiling experience. Could we maybe get release builds in
> >> the future with - force-debug-info to improve this situation? I'm aware
> >> that one can get some sense out of a profiler when only the end-level
> >> application is build in that way, but one can often get much more
> >> insight when the stack below (or even in- between for the eventloop and
> >> signal/slot magic) also gets annotated stack frames. Right now, I have
> >> to suggest people to build Qt themselves for the sole purpose of
> >> profiling... A pity!
> >
> >This would be amazing. Also for getting better backtraces from crashes
> >at users systems.
> 
> I normally use release build always even for debugging. It were also nice if
> Qt would set the enhanced pdb option to get better release debugging
> experience, /d2Zi+ option for vs2012 and /Zo for Vs2013 upd3 and VS2015.
> 
> As i have other reasons to always build Qt myself and maintain patches
> others than these, i have no real problem with the current state, but would
> still be glad if pdb for release are build and delivered with the enhanced
> pdb option.
> 
> Regards,
> Gunnar Roth
> 

This is related:
https://bugreports.qt.io/browse/QTBUG-29668

The option is being evaluated. The main problem is that it seems that the 
installer size grows 2x with force-debug-info enabled, we need to confirm that 
it is not the case.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] ci timeouts

[Jędrzej Nowacki]

On Tuesday 01 of March 2016 14:15:30 Tim Blechmann wrote:
> hi all,
> 
> it seems that i cannot integrate changes into 5.6 anymore:
> > http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1456811813.thrif
> > t_bin
> seems that i'm always hitting a timeout somewhere ... is this a known
> issue? i was hoping that the following changes could make it into 5.6:
> https://codereview.qt-project.org/#/c/149223/
> https://codereview.qt-project.org/#/c/150084/
> https://codereview.qt-project.org/#/c/150645/
> 
> all of them are bug fixes ...
> 
> thnx,
> tim

Hi,

Just fast update on the issue. I thought that this is fixed:
http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1456811813.thrift_bin
Thanks for pointing it out. Time handling in virtualiazed environment is not 
reliable, and sometimes source packages are created in future... Anyway I know 
how to workaround it a fix is coming hopefully soon.

On the other hand this one
https://codereview.qt-project.org/#/c/150084/
Was caused by a source incompatible change in qtbase. In such cases re-staging 
is just a waste of resources. 

This one 
https://codereview.qt-project.org/#/c/150645/
is most interesting. It contains a failure because make install in iOS build 
took more then 20 min(?). Another timeout was caused because of a temporary 
network failure (https://bugreports.qt.io/browse/QTQAINFRA-969). 

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Jędrzej Nowacki]

On Monday 29 of February 2016 11:11:28 Иван Комиссаров wrote:
> 2016-02-26 11:43 GMT+03:00 Jędrzej Nowacki <jedrzej.nowa...@theqtcompany.com
> > On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote:
> > 
> > The thought evolved over last months and now I think that QAIM should not
> > be
> > QObject at all, it is just an unnecessary cost.
> 
> Hm... Really? http://doc.qt.io/qt-5/qabstractitemmodel.html#signals AFAIK,
> Q_GADGET doesn't support signals

I was not explicit enough, I do not think QAIM, in the current state, is a 
very good API. I was thinking about new API with a similar functionality.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Jędrzej Nowacki]

On Friday 26 of February 2016 15:56:08 Thiago Macieira wrote:
> > I.e. what problems would we get from having to install the
> > moc files?
> 
> Lots.

And probably all go away if instead of installing anything we use 
QMetaObjectBuilder (assuming it's api stabilization). Yes it would have 
performance impact, but only on the templated version and only during 
initialization, qml is paying that price constantly without bigger complains. 
It would not require any build system changes. The only limitation I can think 
of right now is that in QObject, Foo needs to be know to QMetaType 
system, which is not a big deal.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Jędrzej Nowacki]

On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote:
> On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote:
> > On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote:
> > > This might be a burden for some of the Qt developers (Windows ones).
> > > 
> > > But all the Qt users get a modern / flexible moc, see this thread:
> > > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c9
> > > 0e
> > 
> > I don't think we need a more flexible moc. What do we want to do that we
> > can't do with the current one?
> > 
> > Don't say "template QObjects". That has other reasons for being a bad
> > idea,
> > currently.
> 
> Can you explain what those reasons are? I'd really love to write a generic
> QAbstractTableModel implementation that operates using concepts. Currently
> that would require type erasure and thus another set of virtual function
> calls...
> 
> I.e. in many projects I end up writing the same boiler plate code to display
> a QVector in a view. As far as I can see most of that could be
> abstracted away easily, leaving only slim concepts to the struct:
> 
> struct MyRowType {
> QString foo;
> int bar;
> QVariant data(int column, int role) const
> {
> if (!role == Qt::DisplayRole) return {}
> switch (column) {
>   case 1: return foo;
>   case 2: return bar;
> }
> return {};
> }
> };
> 
> this could easily be extended to other methods, such as setData, headerData,
> etc. pp. In the end, one would only need to implement a trivial minimal API
> at the place where the data is actually stored. And no, I do _not_ consider
> the current QAIM interface trivial to implement, not even for "simple"
> lists!
> 
> If we'd have templates QObjects, the above could easily be written. I bet
> there are other valid use-cases.
> 
> Cheers

Hi,

 When first time I heard about templated QObject, QAIM was my first thought :-) 
The thought evolved over last months and now I think that QAIM should not be 
QObject at all, it is just an unnecessary cost. 

 The main problems of templated QObject are captured more or less in this 
thread: http://lists.qt-project.org/pipermail/development/2013-March/010288.html

 Personally I still think it would be a fancy feature, a bit dangerous to 
implement maybe even dangerous to use, but really cool :-D

Cheers,
 Jędrek

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Auto-assignment in JIRA

[Jędrzej Nowacki]

On Friday 26 of February 2016 00:16:35 Shaw Andy wrote:
> I was creating another bug report earlier today in JIRA and I noticed that
> it was assigning to someone who didn't seem to be right for the component
> at all since I don't believe they are the maintainer for it and I recalled
> that this is not the first time I've noticed that the auto-assigner is
> clearly incorrect and therefore it could end up in some sort of limbo.
> 
> I know that anyone can pick up a bug report not actively being worked on so
> it doesn't have much meaning in that regard, but is there an actual benefit
> to having the auto-assigner set? Are the maintainers actively utilizing
> this or would it be best that all new bugs are unassigned by default and
> then someone picks them up when they are going to actively work on it?
> 
> I don't have an agenda (aside from the auto-assignment being correct if this
> is the work flow we want) either way on this but I am curious as to whether
> it is useful or not. Therefore if it is useful then we can at least clean
> it up a bit so it is assigning correctly (either to the maintainer or to
> unassigned).
> 
> Andy

Hi,

 This was discussed few times already. As far I remember we concluded that it 
is up to maintainer to decide how to handle incoming bugs. Some prefer auto 
assignment to see what is going in and some prefer to see a dashboard and 
reduce amount of noisy emails.

 Regarding invalid auto assignment, ping our JIRA admins, they will clean it 
up.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] We are planning to upgrade qdoc to use clang for parsing C++

[Jędrzej Nowacki]

On Thursday 25 of February 2016 09:56:01 Smith Martin wrote:
> Send ideas for upgrading the Qt documentation to C++11.
>
> 1. Which C++11 constructs will be used in Qt?
All of them, in longer run C++14 too :-)

> 2. Which of these should appear in the documentation?
I do not understand the question. All of them that are documented?

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: lambda or lambda return from lambda?

[Jędrzej Nowacki]

On Monday 01 of February 2016 15:16:33 you wrote:
> I am a great fanboy of algorithms and the STL, as should be clear by now
You are excused ;-) But seriously I do not think there is anything wrong about 
it, STL is a bit obscure, but fast and sometimes a code needs to be fast. 

> But I find the inlined lambda worse than an explicit loop. This is
> write-only  code, imo. Esp. since we can't (yet) use auto in the parameter
> list, but even then, I'd always give a lambda a name (cf. my mail in
> response to Christian).
Hmmm, In my opinion you do not like the most cool feature of lambdas :-) Each 
time I was forced to define a functor somewhere, in a completely different 
place then my code lived, I was sad and jealous of python lambda syntax. I 
value a code that can be read from top to down without major jumps. Naming 
lambdas causes my eyes to jump ("so for each element it calls a function 
FooBar... Ah which does that") and it also suggests that the lambda will be 
re-used ("ok, so now remember FooBar, as it will be used again..."). I would 
much prefer a simple inline comment before sequence of std::remove_if 
std::erase and others then named lambda.

Anyway I guess we are again hitting a "C++11 syntax that we were not used to" 
issue. So please do not create any policy about that, at least not for now. 

Btw. when you are taking an address of a function you force a compiler to de-
inline the function, I hope such de-optimization doesn't happen while naming 
lambdas.

> > For a bigger code we would actually require named functions. What do you 
> > think?
> 
> Named functions have two problems: a) that many compilers don't inline the 
> code. So at a minimum, you'd write a forwarding lambda, or the function
> would  be an auto variable holding a stateless lambda (the difference
> between the two is almost non-existent, anyway). And b) that they cannot
> carry state. Lambdas can.
Sorry I used wrong wording, by named function I meant, assigned lambda, a 
functor or a declared function.  In general a callable with a name, defined in 
a different place then used.

A propos inline'ing of functions, have you tried anonymous namespaces? That 
should help.  At least once I forced gcc to inline the code...

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFC: lambda or lambda return from lambda?

[Jędrzej Nowacki]

On Monday 01 of February 2016 11:08:54 Marc Mutz wrote:
> Hi,
> 
> We're seeing increasing use of lambdas in dev, and I'm a bit unhappy about
> the result.
> 
> E.g. (not picking on Anton here, I have done the same before):
> 
>  auto firstEqualsName = [](const QPair )
> {
>   return qstricmp(name.constData(), header.first) == 0;
>  };
>  fields.erase(std::remove_if(fields.begin(), fields.end(),
>  firstEqualsName),
>   fields.end());
> 
> This is one way to write a unary predicate. But it hides the fact that the
> predicate depends on the parameter 'name' (an argument to the function this
> lambda is defined in).
> 
> With classical function objects, one would have written - at the call site:
> 
>  fields.erase(std::remove_if(fields.begin(), fields.end(),
>  FirstEquals(name)),
>   fields.end());
> 
> See the difference?
> 
> Now, we don't want to go back and write function objects for one-time use,
> but it would be nice to have this explicit syntax, would it not?
> 
> One way to have this with lambdas is to write a lambda that returns a
> lambda. We can do this, because auto return type deduction works for
> lambdas already in C++11, unlike for normal functions. With this, the above
> would become (hold tight):
> 
>   auto firstEquals = [](const auto ) {
> return [](auto header) { return qstricmp(header.first, name) == 0;
> }; }
> 
> where I used auto and dropped the const-& argument passing only for
> exposition, to get it onto a single line.
> 
>  fields.erase(std::remove_if(fields.begin(), fields.end(),
>  firstEquals(name)),
>   fields.end());
> 
> So, where to put the ugliness: on the definition of the lambda, or the call
> site? (Note that "if you use this lambda more than once, then X" is not a
> good answer, because you shouldn't use lambdas more than once. But with the
> lambda- returning-lambda, you could actually reuse them:
> 
> // at global scope:
> 
>   auto firstEquals = [](const auto ) {
> return [](auto header) { return qstricmp(header.first, name) == 0;
> }; }
> 
>   // use in several functions - always the same type
> 
> Whereas without the outer lambda, each use would create a new type, and
> potentially duplicate code (same problem as QStringLiteral, and the same
> soultion, really: wrap them in a function, except for lambdas, because of
> the unnameable return type, we need to use another lambda instead of a
> classical function).
> 
> So, which one to use?
> 
> Thanks,
> Marc

Hi,

 I would just inline the lambda inside remove_if. That way "name" would be 
explicit in place in which it is used and you could avoid 2nd lambda. 

So it would look like that:

  fields.erase(std::remove_if(fields.begin(), 
  fields.end(),
  [](const QPair 
)
  {
  return qstricmp(name.constData(), 
header.first) == 0;
  }),
   fields.end());

// I hope that formating is still ok, and the code is not wrapped.

For a bigger code we would actually require named functions. What do you 
think?

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Setting up test server for QtNetwork tests

[Jędrzej Nowacki]

On Thursday 28 of January 2016 12:37:14 Hausmann Simon wrote:
> Regarding the server that is used for Qt 5.6 and onwards: It is an exact
> clone of the virtual machine that ran in Jenkins with no changes to the
> services, but it is in a different virtual network segment. 

It is exactly the same, minus puppet that caused a test failure every quarter 
by restarting services.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Jędrzej Nowacki]

On Friday 22 of January 2016 08:50:52 Thiago Macieira wrote:
> On Friday 22 January 2016 11:26:55 Bogdan Vatra wrote:
> > AFAIK C++11/14 compilers have zero-cost exception, so, is there any reason
> > why  not start using them in Qt 6.0 ?
> 
> Yes. There's a couple of man-decades worth of work to make entire Qt thread-
> safe. Then there's the whole discussion about what to do in OOM situations
> and whether we can even reliably detect them, which I won't rehash here.
> 
> If you meant it restricted to a few classes, like containers, that's
> achievable within one year. If we decide to do that, to make it truly useful
> we probably should extend to all value-type classes, like QString and
> QNetworkProxy.

I agree, making Qt exception safe is close to impossible in the current 
situation. We could maybe go to basic level of exception safety by adding GC. 
I'm not sure if it is worth it. I like exceptions but Qt is not designed to 
use them.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Jędrzej Nowacki]

On Tuesday 19 of January 2016 13:51:56 Marc Mutz wrote:
> On Tuesday 19 January 2016 11:15:43 Milian Wolff wrote:
> > On Dienstag, 19. Januar 2016 11:51:42 CET Marc Mutz wrote:
> > > I missed one:
> > > 
> > > On Monday 18 January 2016 23:43:37 Marc Mutz wrote:
> > > > #include 
> > > > #include 
> > > > 
> > > > int main() {
> > > > 
> > > > QVector l;
> > > > int oldC = l.capacity();
> > > > for (int i = 0; i < 1000; ++i) {
> > > > 
> > > > char buf[std::numeric_limits::digits + 1];
> > > > sprintf(buf, "%d", i);
> > > > l.push_back(buf);
> > > > int newC = l.capacity();
> > > > if (newC != oldC)
> > > > 
> > > > qDebug("%d", newC);
> > > > 
> > > > oldC = newC;
> > > > 
> > > > }
> > > > 
> > > > }
> > > > 
> > > > $ time ./test
> > > > 
> > > > real0m1.769s
> > > > user0m1.572s
> > > > sys 0m0.192s
> > > 
> > > Same with std::vector:
> > > 
> > > real0m1.776s
> > > user0m1.616s
> > > sys 0m0.156s
> > > 
> > > > best of three runs, core i7-2720QM, GCC 5.3
> > > 
> > > Ditto.
> > > 
> > > So... is realloc actually the optimisation everyone (incl. me) expected
> > > it to be?
> > 
> > Did you run it through a profiler? Where is the time actually spent?
> 
> No. It's not the IO, though. Removing the qDebug() and capacity tracking, it
> performs the same, within error margins.

Hi, 

  I can not reproduce the numbers on gcc version 5.3.1 20151219 (Debian 
5.3.1-4). But there is a bug in the benchmark, std::vector and QVector have 
different grow model, at least I do not see the same count of qDebug messages.
In addition I think the benchmark may be affected by heap allocation executed 
on each l.push_back.

 The feature is also used in QVariant which tries to avoid allocations. That 
was confirmed as important optimization.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Update QtWayland CI to Wayland 1.6+

[Jędrzej Nowacki]

On Monday 11 of January 2016 00:27:08 Pier Luigi Fiorini wrote:
> Hi,
> 
> We are starting to have QtWayland patches that require at least Wayland 1.6
> available, such as:
> 
> - https://codereview.qt-project.org/#/c/104222/
> - https://codereview.qt-project.org/#/c/112141/
> - https://codereview.qt-project.org/#/c/144891/
> 
> We need to update CI to at least Wayland 1.6 as soon as possible.
> 
> If I recall CI is running Ubuntu 14.04 LTS now, but LTS is released every
> two years.
> 
> The next LTS should be 16.04 which means that until April we cannot merge
> those patches making the first one more than 1 year old.
> 
> Would it be possible to switch to a distro that potentially has more
> frequent updates to avoid repeating the same problem again in the future?

Hi,

 I guess the whole point of having Ubuntu 14.04 LTS in CI is to support that 
platform as long as it is important. As you said it will be important until 
16.04 release. I think we could potentially remove 14.04 from CI on dev branch 
after Qt 5.7 release. Can't you "ifdef" you code, so it "works" with the older 
Wayland too?

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Update QtWayland CI to Wayland 1.6+

[Jędrzej Nowacki]

On Thursday 14 of January 2016 06:39:29 Thiago Macieira wrote:
> On Thursday 14 January 2016 10:15:40 Jędrzej Nowacki wrote:
> >  I guess the whole point of having Ubuntu 14.04 LTS in CI is to support
> >  that
> > 
> > platform as long as it is important. As you said it will be important
> > until
> > 16.04 release. I think we could potentially remove 14.04 from CI on dev
> > branch after Qt 5.7 release. Can't you "ifdef" you code, so it "works"
> > with
> > the older Wayland too?
> 
> I don't think it makes sense to support Wayland that old, especially not on
> a distro that decided to not support Wayland. It's probably better to just
> skip building Wayland altogether if the found libraries are too old.
> 
> We just need a newer distro that does support Wayland to be present.

True, so the assumption is that Qt should compile on the 14.04 for now. It 
doesn't mean that the provided Wayland will be used. I'm fine with that :-)

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFD: plugins vs QStringLiterals

[Jędrzej Nowacki]

And every small, movable object kept in QVariant is affected. QMetaType also 
keeps pointers to functions defined in plugins if such register a type. I 
believe that we had that discussion around Qt4->Qt5 migration. Unloading 
plugins is not safe, sometimes it works but still it is very tricky. I agree 
with Simon and I'm in favor of 3.

Cheers,
 Jędrek

On Thursday 05 of November 2015 16:57:49 Hausmann Simon wrote:
> And moc data is affected in a similar way. I continue to be in favor of (3)
> 
> Simon
> 
>   Original Message
> From: Thiago Macieira
> Sent: Friday, November 6, 2015 00:44
> To: development@qt-project.org
> Subject: [Development] RFD: plugins vs QStringLiterals
> 
> 
> Proposal: force QStringLiteral uses to always address a heap-allocated
> QString, instead of pointing to the static data. Possibly, this should be an
> interned atom/quark à la GQuark, so two passes on the same QStringLiteral
> would result in the same heap pointers.
> 
> Alternative: force QPluginLoader / QFactoryLoader to fake unloading but not
> really unload. Maybe even QLibrary, if we find people use QLibrary to load
> Qt- based plugins instead of our own classes.
> 
> Background:
> 
> When we created QStringLiteral, we thought it was the best thing since
> sliced bread. We started using it everywhere and so did our users, after
> our recommendations. I even had a session in last years' Dev Days
> explaining when to use QStringLiteral and when not to. The objective of
> that session was to explain performance.
> 
> The problem we're seeing is that it's quite easy to violate the precondition
> that the QStringLiteral never, ever disappears. This happens when plugins
> are involved. Any QStringLiteral in a plugin or in a library that gets
> loaded by that plugin is subject to disappearing before the end of the
> program.
> 
> [Henceforth, "plugin" is "any dynamically loaded module, whether intended as
> a library or plugin, including all their dependencies that weren't loaded
> before"]
> 
> I've said in the past that unloading plugins is a bad idea in C++. The case
> then was that it's easy to leave objects of a polymorphic class type whose
> virtual table is located in the unloaded plugin. This is not very different,
> since the QStringLiteral's data is also global data not expected to
> disappeaar.
> 
> We've already worked around two cases of crash-at-exit caused by this, both
> coincidentally related to QtDBus's interface cache. But this can also happen
> for any other types of cache, like:
> 
> QRegExp rx(QStringLiteral());
> QPixmapCache::insert(QStringLiteral("foo"), px);
> 
> What do we do then?
> 
> 1) Declare it SEP and only apply workarounds for the places where
> QStringLiteral is used in our plugins, suggesting that people do the same in
> their plugins.
> 
> Problems: libraries loaded by plugins, fragile.
> 
> 2) Deep-copy the QStringLiterals
>  a) with atom/quark
>  b) without
> 
> Problem: performance impact, complexity of the atom/quark solution.
> 
> 3) Never unload any plugins, possibly also compiling our own libraries and
> plugins with -z nodelete. Solves most of the problems, including the C++
> vtable case.
> 
> Problems: doesn't catch bypassing of QLibrary (dlopen/LoadLibrary calls),
> prevents upgrading of plugins without restarting the host application.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] CI links to build results broken

[Jędrzej Nowacki]

On Wednesday 29 of July 2015 10:31:01 Marc Mutz wrote:
 Hi,
 
 Example: https://codereview.qt-project.org/95533
 
 Output link posted there:
 http://testresults.qt.io/logs/qt/qtbase/98ca8036c6d5b37be676503e463c49e8dcc9
 c5de/windows8x86_64winrt8x86_64msvc2013developer-
 build_release_disable-tests/da39a3ee5e6b4b0d3255bfef95601890afd80709/buildl
 og.txt.gz
 
 But that gives a 404.
 
 Can someone please have a look?
 
 Thanks,
 Marc

Hi,
 
Probably CI was restarted during logs upload time, and the log was not 
uploaded. It is a known, but not that common bug, which will be fixed soonish.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QMetaType::registerType: Binary compatibility break -- Size mismatch for type 'QPaintBufferCacheEntry' [1024]. Previously registered size 0, now registering size 16. Aborted (core du

[Jędrzej Nowacki]

On Wednesday 24 of June 2015 14:03:07 Zhang Qun wrote:
 QMetaType::registerType: Binary compatibility break -- Size mismatch for
 type 'QPaintBufferCacheEntry' [1024]. Previously registered size 0, now
 registering size 16.

Hi,

  It looks like a build issue, qt library version mismatch... Does Marble 
support Qt5? 

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] changing Q_GADGET

[Jędrzej Nowacki]

On Friday 28 of November 2014 13:55:44 Simon Hausmann wrote:
 On Friday 28. November 2014 12.41.47 Olivier Goffart wrote:
  On Friday 28 November 2014 12:19:45 Simon Hausmann wrote:
   Hi,
   
   Monsieur Goffart did awesome work in the dev branch on allowing
   structures
   with Q_GADGET to have properties and invokable methods. This brings the
   macro to a much wider audience and I'd like to use this opportunity to
   propose a slight change to it that may be controversial:
   
   The macros Q_OBJECT and Q_GADGET both - towards the end of their
   definition
   - change the member access permission level to private. It's always
   been
   that way.
   
   I'd like to propose changing Q_GADGET to not change the access
   permission
   level, so that you can write
   
   struct MyStructure
   {
   
   Q_PROPERTY(int x MEMBER x)
   Q_GADGET
   
   int x;
   
   }
   
   
   I feel that Q_GADGET has its primary use with structures and the default
   access level for those is public. I find it awkward that you currently
   have
   to write:
   
   structure MyStructure
   {
   
   Q_PROPERTY(int x MEMBER X)
   Q_GADGET
   
   public:
   int x;
   
   }
   
   
   The proposed change would have two effects:
   
   1) It makes any existing code that _relies_ on Q_GADGET turning to
   private
   suddenly expose members in structures.
   
   2) On paper it breaks binary compatibility with MSVC, in the unlikely
   event
   that somebody
   
   a) produces a DLL and cares about binary compatibility
   b) exposes bare structures
   c) relies on Q_GADGET turning access permission levels to private
   
   I feel that the effects are negligible compared to the benefit of a
   better
   API.
   
   What do you think?
  
  I have several times been bitten by the same problem when i used Q_OBJECT
  in a struct.
  But when I weight the pro and the cons, i'm not sure if it's a good idea.
  
  Pros:
   + Save one line when declaring a Q_GADGET in a struct
  
  Cons:
   - The change may change some member (data or function) from private to
  
  public - Is inconsistent with Q_OBJECT (and both are usually used in
  class)
  - Something that is incorrectly set as private will result in compilation
  errors that will be easily spotted and fixed. Something inadvertently left
  public will stay unnoticed until it's too late to change it.
  
  
  Notice that in our code we recommend to always use class and almost never
  struct.  All the Q_GADGET today are class.
 
 Hmm, that's a good point. I may be living in an over-simplified world where
 I use struct more often than others. (in my dream world class also defaults
 to public). The reality is probably that both macros are perhaps more
 likely to be used in the class context and that consistency between the
 macros might outweigh the inconsistency to struct.
 
 
 
 Simon
 
  An alternative to save that line might also be to put the Q_GADGET macro
  at
  the end of the struct.

Hi,

  Personally, I think Q_OBJECT should not change access level and so Q_GADGET. 
It is not really about one additional line to type, it is about surprise 
effect, while reading code. So if we would design the Q_OBJECT macro again, 
would we change the access level again?

Pros: 
 -  it always keep the same access level (may be easier to keep BC on 
Windows?)

Cons:
 - surprise factor, as it doesn't behave as standard, property based, c++ code
 - one line more for structs (minor)

Now, we can not change Q_OBJECT, at least up to Qt6, then should we follow 
it's practice? Q_OBJECT is the only macro, we ship, that changes access level, 
so from these perspective it is an outsider, but I agree that Q_GADGET is it's 
a twin brother. So keeping them in sync is not bad either. 

  - Something that is incorrectly set as private will result in compilation
  errors that will be easily spotted and fixed. Something inadvertently left
  public will stay unnoticed until it's too late to change it.
True, but in my opinion, it is not a problem. Private api should be protected 
by a convention not by a tool, because you can always workaround a tool. But 
that discussion is probably out of scope.

  Notice that in our code we recommend to always use class and almost never
  struct.  All the Q_GADGET today are class.
Do you know why (and where) we recommend that?


Cheers,
  Jędrek



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [FYI] new git-gpush features, a.k.a. the smart way of pushing to gerrit

[Jędrzej Nowacki]

On Thursday 23 of October 2014 19:03:32 Oswald Buddenhagen wrote:
 just to be clear, everybody is expected to use these scripts after they
 leave the beta phase.
 this will be technically enforced at some point.

Hi,

 Now, you got my attention. To be honest I'm a bit surprised. Personally I 
didn't have a need for any additional script while working with gerrit. What 
is rationale for the technical enforcement?

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [FYI] new git-gpush features, a.k.a. the smart way of pushing to gerrit

[Jędrzej Nowacki]

On Friday 24 of October 2014 11:37:29 Oswald Buddenhagen wrote:
 On Fri, Oct 24, 2014 at 10:26:20AM +0200, Jędrzej Nowacki wrote:
  On Thursday 23 of October 2014 19:03:32 Oswald Buddenhagen wrote:
   just to be clear, everybody is expected to use these scripts after they
   leave the beta phase.
   this will be technically enforced at some point.
   
   Now, you got my attention. To be honest I'm a bit surprised. Personally I
  
  didn't have a need for any additional script while working with
  gerrit.
  
  What is rationale for the technical enforcement?
 
 years of preaching don't rebase unnecessarily and don't create
 spurious dependencies being mostly ineffective. i pushed an update to
 your change, take care not to overwrite it accidentally being futile on
 a regular basis. people demanding ridiculously short review cycles,
 because waiting for a review holds them up for 'process' reasons. etc.
 iow, the usual results of inattentivenes, indifference (unless one is
 the reviewer affected by it, of course), impatience, and sheer laziness.
 and sometimes even genuine mistakes.
 
 these scripts give you a much more transparent gerrit experience.
 you can continue your work without regard for the fact that often
 you need to push amended changes, and doing so thoughtlessly creates
 work for *other* people.
 even if you are a paragon of virtue and painstakingly take care to not
 annoy your reviewers with needless noise, you'll find that these scripts
 make this just *so much easier/faster*.
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

Hi,

I admire that you want to improve everyones working process, but I think you 
took the wrong way. You are fixing the problem on odd level, I strongly believe 
that you should fix Gerrit, enforcing a tool on everyone is at the best far 
from ideal.

don't rebase unnecessarily - For us, Gerrit is always cherry-picking, which 
means a user do not really control final parent of a change. Therefore in 
theory rebase should not be a problem. Sadly It is because of two things:
1. It crates new patchset, which sends notification and reset score
2. It breaks web diff.
Both should be fixable on the Gerrit level

don't create spurious dependencies - I didn't even know that it is a 
problem. Especially that in most cases a change is staged by its author, which 
is supposed to know the real dependency. Any external tool, like for example 
qdoc bot, has to take the dependency into account anyway, so there is no 
additional work to do. 

i pushed an update to your change, take care not to overwrite it 
accidentally - Do not do it, unless you explicitly arranged with change 
owner. Some people get angry about it. I can understand that, because it is 
not immediately obvious what kind of changes you did. Moreover maybe they 
already scripted the Gerrit access, in such case your modification would be 
invisible.

In my opinion, enforcing a custom tool is wrong. It is already quite difficult 
to contribute to Qt for newcomers. Putting a new, obligatory tool on top, it 
is not making it easier. Remember that the tool, as specific to one project, 
will be well hidden in google search results (btw. there is already a git 
gpush command out there...). So it would be more difficult to get tutorials or 
help in case of problems. Moreover some some people are already familiar with 
gerrit and git.

Cheers,
  Jędrek

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Problem compiling qtcreator on armhf

[Jędrzej Nowacki]

On Saturday 02 of August 2014 14:53:10 Lisandro Damián Nicanor Pérez Meyer 
wrote:
 Just for the record, I'm also seeing this while compiling:
 
 /home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/model/qmltextg
 enerator.cpp:  In member function 'QString
 QmlDesigner::Internal::QmlTextGenerator::toQml(const 
 QmlDesigner::AbstractProperty, int) const':
 /home/lisandro/qtcreator/src/plugins/qmldesigner/designercore/model/qmltextg
 enerator.cpp:130:13:  warning: case value '38' not in enumerated type
 'QVariant::Type' [-Wswitch] case
 static_castQVariant::Type(QMetaType::Float):

Fixed by e013c7e6.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Compiler bug in Clang 3.4 with precompiled header with QueuedConnection

[Jędrzej Nowacki]

On Monday 21 of July 2014 23:12:04 Olivier Goffart wrote:
 Hi,
 
 I just debugged a quite weird bug with QueuedConnection and foinction
 pointer base connection.
 
 There is a compiler bug in clang 3.4 with precompiled header.
 Normally, a static variable within a template should have a different
 address for different template parameters .
 In other words:
 templatetypename T int *foo() { static int i; return i; }
 so fooint() != foodouble()
 
 However, if foo is in a precompiled header, this is not the case.
 
 And this breaks the detection of the QMetaType for the QueuedConnection
 since we rely on static variables different for each types.
 http://code.woboq.org/qt5/qtbase/src/corelib/kernel/qobject_impl.h.html#105
 
 As a result, Qt believe the metatypes are not what they are, resulting in
 wrong type conversions, and weird crash when the event is received.
 
 The bug is fixed in Clang 3.5. (not released yet)
 I don't know if it was present in earlier version of clang.
 
 Should precompiled header be disabled by default for this compiler version?

Hi,

Yes. I'm not totally sure, but I think we may have more places that depends on 
the correct behavior. Nice catch!

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Converting types in Qt

[Jędrzej Nowacki]

On Thursday 17 of July 2014 10:51:03 you wrote:
 QVariant::operator== is not symmetric
 
  QDateTime dateTime = QDateTime::currentDateTime();
 QTime time = dateTime.time();
 
 qDebug()  (QVariant(dateTime) == QVariant(time));
 qDebug()  (QVariant(time) == QVariant(dateTime));
 
 --
 false
 true

We could make it symmetric, if you want. My recommendation is to not use the 
comparison at all. If you want more features of QVariant you can look into 
isNull() this is a perfect randomizer :P. The whole discussion took wrong 
direction. I didn't want to discuss QVariant API, which is not fixable, even 
Qt6 would not help, to much staff depends on it. 

Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Converting types in Qt

[Jędrzej Nowacki]

On Thursday 17 of July 2014 13:33:49 Daniel Teske wrote:
 On Thursday 17 Jul 2014 13:28:10 Jędrzej Nowacki wrote:
  On Thursday 17 of July 2014 10:51:03 you wrote:
   QVariant::operator== is not symmetric
   
QDateTime dateTime = QDateTime::currentDateTime();
   
   QTime time = dateTime.time();
   
   qDebug()  (QVariant(dateTime) == QVariant(time));
   qDebug()  (QVariant(time) == QVariant(dateTime));
   
   --
   false
   true
  
  We could make it symmetric, if you want.
 
 A equals operator that is not symetric is broken. Such a class cannot be
 reliably used in std nor qt containers. Or do you know which way around,
 QList::contains uses the equals operation?

The example above shows what happens in case of a missing conversion, in this 
case QTime can be converted to QDateTime, but the QDateTime can not be 
converted to the QTime. Fail.

The operator was / is / will be broken. Even if we make it symmetric, it will 
remain conceptually broken. It should compare QVariants and then (maybe) the 
wrapped value, while currently it tries a fuzzy comparison of the wrapped 
value only.  It should look more or less like that:

bool operator ==(const QVariant left, const QVariant right)
{
return left.userType() == right.userType()  
!QMetaType::compare(left.constData(), rigth.constData(), left.userType());
}

To make it more ridiculous, currently it would not work as QMetType::compare 
do not know about built-in types :P

There are few ways to fix it, sorted from the smallest impact on a user code 
base to a-bomb size:
- Add conversion QDateTime - QTime (Up to now only Olivier agreed with me 
that it is ok to add a new conversions)
- If two QVaraints are not equal we can check if swapping left and right sides 
helps. Inefficient, another behavior change and as odd as the current behavior. 
Nothing to gain really.
- Always compare QVariants twice left to right and right to left. Terribly 
inefficient, more sensible output. Big behavior change as most of comparison 
would return false.
- Allow comparisons of the same types or if there is explicitly registered 
comparisons otherwise return false. Completely different behavior then the 
current one.
- Do not allow QVariant comparison, we can not support custom types if they do 
not register conversion anyway so why bother.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Converting types in Qt

[Jędrzej Nowacki]

On Tuesday 15 of July 2014 11:59:03 Olivier Goffart wrote:
   1.3 Should we try to support a user's type conversions out of the
 box? 
   Currently a user needs to manually register a conversion function
 
  so Qt can know it and use it. For certain types we can do much better,
 
  because we can automatically convert some types. For example:
   QVectorchar - QLinkedListint
   QListFoo - QVectorFoo
   QPointerFoo - QObject*
   QPointerFoo - void*
   QSharedDataPointerFoo - bool
   MyQObject* - QPointerMyQObject
   Currently we are not doing it for one reason which is behavior
 
  compatibility. What if a user already defined a conversion that we want to
  add? It could happen because the conversion was not available in a
  previous
  Qt version. The problem is that the new conversion function may behave in
  a
  different way, especially in edge cases and because of the lack of
  perfection mentioned in 1.2. We need to pick only one function. That could
  be the Qt version, but then we risk that an existing code will not work
  anymore. Are we willing to accept that?
 
   I believe that we should document the problem, and allow the
 
  conversions.
 
 I think we could try to automatically do conversion when we know how to do
 it.  And if there is an user defined conversion, it overrides the automatic
 one.

We could implement overriding, but we would not control which conversion is 
registered first / last. Moreover it would mean that a conversion could change 
at any point. I think it would be a bit too nondeterministic.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Converting types in Qt

[Jędrzej Nowacki]

On Tuesday 15 of July 2014 10:38:52 Poenitz Andre wrote:
 Olivier Goffart wrote:
  Jędrzej Nowacki wrote:
 1. Are we allowed to add new conversions?
 
The question is tricky because adding a new conversion is a
behavior
change, as this code:
if (variant.canConvert(QMetaType::int)) ...
may work differently. If we add custom types into the mix,
everything
   
   is even more complex.
  
  I'd say yes, for sensible conversion
  You are right that it is a behaviour change, but i think it is worth
  changing it.
 Why?
 
 On one hand you promise binary compatibility. On the other hand
 behaviour changes are proposed to be done on an nice to have
 base?
 
 Do we really think that's ok to disallow changing some int foo() { return
 42; } to some int bar() { return 42; } that's easy to discover at build
 time, but it's fine to change int foo() { return 42; } to int foo() {
 return -1; } ?

Yes. Because there are two separate issues here. One is that the build time 
sometimes doesn't exist, and you do not want to break an application that had 
no opportunity to rebuild. Second is that I'm not talking about abstract foo 
or bar function. I was explicit what would change, it would be Qt answer for 
a simply question could you convert this value to this type. I guess in most 
cases the question would be placed in a context: could you convert this value 
to this type, because I know only how to handle the type and not any other. 
In my opinion it is good to answer the question with yes.

  so Qt can know it and use it. For certain types we can do much better,
  
  because we can automatically convert some types. For example:
   QVectorchar - QLinkedListint
 
 QVectorchar v; v.append(130);
 QLinkedListint l = /*someSensibleAutomatedConversion*/(v);
 
 assert(l.first() == 130) ?  Depends ?

Invalid code = undefined output. You can simplify the example to:
 QVectorchar v; v.append(130);
 assert(v.first() == 130) ?  Depends ?
The issue has nothing to do with a magic conversion. You can blame C++ 
standard, which doesn't specify if char is signed or not, or people that write 
such code. I guess both options are valid :-)

A conversion may be arbitrary. For example, most of the
conversions
   
   to QString. Should bool(false) - QString return False, 0,
   false?
   What about precision of, for example, double - QString ?
  
  We use common sense on a case by case basic.
 
 I tend to believe the common sense in type conversion land is pretty
 close to avoid to do it automatically, prefer to make it explicit.

You are right, it is good to avoid it, but sometimes it is not possible 
especially, if you do not control full stack.

 Already now it's far too easy to make mistakes based on the nice
 and easy QByteArray - QVariant - QString conversions when
 accidentally writing QByteArrays into QSettings and reading QStrings
 back. There shouldn't be more of that.

 Andre'
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Converting types in Qt

[Jędrzej Nowacki]

On Wednesday 16 of July 2014 06:37:25 Ziller Eike wrote:
  [...]
  When one use QVariant, it is because we want to enjoy dynamic typing and
  nice  conversions.
 
 
 I don’t think we have a single place in Qt Creator where we want automatic
 conversions when using QVariant. A search for QVariant(Map) returns 5400
 hits. In the map case, we usually expect the one retrieving the value for
 a key to know the exact type of what was thrown in (that’s usually the same
 class, or related classes), and then we use item models and QSettings which
 we use in the same way. 
 Even if automatic conversion might be interesting (when, actually?), then
 the point is:
 
 There is no API in QVariant to support the common use case of getting the
 value *without* automatic conversion.

Nobody asked for it, It should be easy to implement something equal to this;

 Q_ASSUME(variant.userType() == qMetaTypeTargetType()); 
 TargetType data = variant.valueTargetType();

I believe such new api make sense, we can add it.

 
  We use common sense on a case by case basic.
 
 
 
 Either there is no “common sense” common to me, or this rule has failed in
 the past already ;)
 
 bool - string ?
 bytearray - int/long/double ?
 keysequence - int ?
 string - bool ?
 string - bytearray ?
 string - int ?
 
 Br, Eike

What is wrong with string - int or bytearray - int?

 -- 
 Eike Ziller, Senior Software Engineer - Digia, Qt
 Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
 Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
 Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg,
 HRB 144331 B 
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Converting types in Qt

[Jędrzej Nowacki]

On Wednesday 16 of July 2014 08:41:07 Poenitz Andre wrote:
 Olivier Goffart wrote:
I'd say yes, for sensible conversion
You are right that it is a behaviour change, but i think it is worth
changing it.
   
   Why?
   
   On one hand you promise binary compatibility. On the other hand
   behaviour changes are proposed to be done on an nice to have
   base?
   
   Do we really think that's ok to disallow changing some int foo() {
   return
   42; } to some int bar() { return 42; } that's easy to discover at build
   time, but it's fine to change int foo() { return 42; } to int foo() {
   return -1; } ?
  
  It's always a dilemma. We have to look at how likely we are to break
  applications and I don't think adding a conversion is likely to cause
  breakages.
 
 Type safety is a safety net that catches errors very early in the
 software production and deployment cycle, and one of the features
 that makes a programming language usable for the development
 of large applications at a reasonable pace.
 
 Implicit type conversions kill type safety. This is widely recognized
 as a bad thing. In case of C++ some are unavoidable due to the
 C legacy, but e.g. for user-defined conversion operators we now got
 explicit, _because_ people learned the hard way that implicit
 conversions are causing more trouble than wanted.

That is a controversial statement. There is many languages, that doesn't offer 
strict type safety and they are fine. Let's no go into this discussion because 
it would lead us nowhere.

 [...]
 
We use common sense on a case by case basic.
   
   I tend to believe the common sense in type conversion land is pretty
   close to avoid to do it automatically, prefer to make it explicit.
   
   Already now it's far too easy to make mistakes based on the nice
   and easy QByteArray - QVariant - QString conversions when
   accidentally writing QByteArrays into QSettings and reading QStrings
   back. There shouldn't be more of that.
  
  What's the mistake here? Wrong encoding? Bad performances?
 
 Wrong encodings under circumstances that are typically not present on
 the developers or test machines. Here the lack of type safety postpones
 a problem that would be immediately visible (and fixable) at compile time,
 to the time after the application has been shipped.
 
 In the best case this only causes a bug report that needs to be handled
 normally, i.e. needs triaging/fixing/integration (and hopefully is not so
 critical to require an immediate emergency release, but can be delivered
 with the next regular one). Worst case this could mean that the application
 is unusable in a larger part of the world. With or without someone reporting
 the problem.
 
 This is a kind of convenience I don't need, and I pretty much prefer
 the inconvenience of having to spell out type conversions explicitly.

In this particular case I would blame QSettings API, which pretends that is 
able to handle everything while it is not. 

  When one use QVariant, it is because we want to enjoy dynamic typing
  and nice conversions.
 
 I wholeheartedly disagree. Most of my QVariant uses are there because
 the Qt API requires me to use it, and I sometimes use it voluntarily for
 type-agnostic storage or transport of things. But in those cases I never
 want to extract anything else from the variant than exactly the thing
 I put into it.
 
 I _never_ (at least not intentionally) use QVariant as a kind of magic
 converter bag where I put something in and get something
 conveniently munged back.

Actually I agree, I believe that QVariant should be just a stupid container 
which allows you to transfer a data in type agnostic way, from one place to 
another. Well, during it lifetime it accumulated a bit of additional 
functionality, but I see that the discussion is floating in wrong direction. 
Let's not talk about implicit QVariant conversions, we have them and we can 
not remove them. We can add, as Olivier suggested qvariant_type_safe_cast to 
our API. Let's talk about QMetaType::convert and 
QmetaType::hasRegisteredConverterFunction,  instead are we allowed to change 
their behavior by adding / modifying conversions ?

Jędrek

 Andre'
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Converting types in Qt

[Jędrzej Nowacki]

On Wednesday 16 of July 2014 12:51:36 Olivier Goffart wrote:
 On Wednesday 16 July 2014 10:06:52 Poenitz Andre wrote:
  Jędrzej Nowacki wrote:
   Eike wrote:
[...]

We use common sense on a case by case basic.

Either there is no “common sense” common to me, or this rule has
failed
in
the past already ;)
bool - string ?
bytearray - int/long/double ?
keysequence - int ?
string - bool ?
string - bytearray ?
string - int ?
   
   What is wrong with string - int or bytearray - int?
  
  At the very least, _implicit_ conversions should not lose data,
  i.e. a  A a1;  B b = a1; A a2 = b; round trip ideally should yield
  a1 == a2.
  
  If I am ready to give up information, I'd like to need to say so
  in the code explicitly. (And yes, part of the deed is done in the
  core language, but even there compilers start to nag about it.)
 
 André, QVariant conversions are not implicit, they are explicit.
 You have to use qvariant_castT, QVariant::valueT, or QVariant::to*.
 That's explicit.
 
 Conversions _to_ QVariant are sometimes implicit, but they are loss-less as
 it just wrap the type into the QVariant.

True conversions from QVariant are explicit, but some of Qt API hides that, 
for example QObject::setProperty which tries hard to implicitly convert data,

Ok, so Andre is in favor of ideal conversions (point 1.2). Ideal round trip 
conversion is possible only if A and B represent the same concept using a 
different representation. So it would work for QLinkedListT  = 
QVectorT, but not for int - long. In my opinion it is really limiting 
and kind of opposite to what we have now :-)

We could potentially split all conversions into two groups ideal and best 
effort and disallow usage of the second group in certain cases. I'm not sure 
if it is worth the effort, and definitely It would break existing behavior as 
effectively it would remove some of the conversions (point 3)

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Converting types in Qt

[Jędrzej Nowacki]

On Wednesday 16 of July 2014 06:37:25 Ziller Eike wrote:
 I don’t think we have a single place in Qt Creator where we want automatic
 conversions when using QVariant. A search for QVariant(Map) returns 5400
 hits. In the map case, we usually expect the one retrieving the value for a
 key to know the exact type of what was thrown in (that’s usually the same
 class, or related classes), and then we use item models and QSettings which
 we use in the same way.

From performance point of view it is good to avoid any conversions. I would 
say even more, if you know all types in your application there is no point in 
using QVariant. Sometimes it is not possible, and sometimes one just don't 
want be bothered. 

I made an extremely unfair experiment.  I switched off all conversions in Qt 
and I recompiled QtCreator. To be honest I expected that it would crash at 
startup, but no (impressive!). I was able to use menu and open dialogs, 
nothing more. From the stderr I could deduct that a QVariant conversion was 
used in reading xml, qws files and in animations.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Converting types in Qt

[Jędrzej Nowacki]

Hi,

I would like to discuss type conversions in Qt. As you may know, Qt has 
the ability to convert a known type to another known type. This works for 
trivial cases like, for example, int to long, but also for more complex 
ones like QByteArray to QString or CustomType to OtherCustomType. Type 
conversion in Qt happens mostly without user interaction, for example in 
QObject introspection or in QML, but it also can be used through public API:
  - QVariant::convert - converts wrapped value to target type
  - QVariant::canConvert - fast check if it may be possible to convert 
wrapped type to a given target, which is, in my opinion, pretty useless, 
unless the real conversion is really heavy
  - QMetaType::registerConverter - allows to register a custom converter 
function for a user defined type
  - QMetaType::convert - perform conversion between two types

I would like to agree on some rules, regarding conversions, as the current 
approach is chaotic:

  1. Are we allowed to add new conversions?

 The question is tricky because adding a new conversion is a behavior 
change, as this code:
 if (variant.canConvert(QMetaType::int)) ...
 may work differently. If we add custom types into the mix, everything is 
even more complex.

 1.1 Patch release or minor release only?

 I would say that new conversions may appear only in minor releases, 
obvious fixes to existing conversions may appear in patch releases, where by 
obvious I mean crash fixes and cases in which the returned value is definitely 
bogus.

 1.2 Should conversion be perfect or based on a best effort?

 Some of the conversion API returns a bool value which is a status 
of conversion. What should it return if a conversion is not perfect, for 
example int(-1) - uint or QVariantList{string, int, myobject} - 
QStringList, should such a case be detected? How do we define the perfect 
conversion? Sometimes only ideal, data lossless, conversions should be 
allowed, for example QtTestLib is quite strict about it and it allows only 
safe conversions. So, for example, int - long but not uint - int, but I 
guess for normal use cases such strictness is not necessary.
 I think we should base conversions on the best effort and set the 
status to false only if a conversion failed completely, that is mainly if a 
conversion is unknown or if underlying implementation detected a failure, like 
QByteArray - float which uses QByteArray::toFloat(bool *ok)

 1.3 Should we try to support a user's type conversions out of the box?

 Currently a user needs to manually register a conversion function so 
Qt can know it and use it. For certain types we can do much better, because we 
can automatically convert some types. For example:
 QVectorchar - QLinkedListint
 QListFoo - QVectorFoo
 QPointerFoo - QObject*
 QPointerFoo - void*
 QSharedDataPointerFoo - bool
 MyQObject* - QPointerMyQObject
 Currently we are not doing it for one reason which is behavior 
compatibility. What if a user already defined a conversion that we want to add? 
It could happen because the conversion was not available in a previous Qt 
version. The problem is that the new conversion function may behave in a 
different way, especially in edge cases and because of the lack of perfection 
mentioned in 1.2. We need to pick only one function. That could be the Qt 
version, but then we risk that an existing code will not work anymore. Are we 
willing to accept that?
 I believe that we should document the problem, and allow the 
conversions.

 1.4 Should a user be able to add Qt types conversion on his own?

 Some conversions are missing, some we consider as not safe. A user, 
assuming that he knows what he is doing, could register a conversion; for 
example, QString - QChar, how bad is it? Currently, such usage is blocked, 
because we are afraid that in the future we may add a conversion that 
overrides it.
 In my opinion it is not needed; it is a corner case, because we a) 
should have the conversion and then it will appear in a future version b) the 
conversion is invalid, and it is a sign of a user's broken code.


  2. Can we modify an existing conversion?

 All modification changes behavior. Of course we assume that changes are 
sensible, but still it may break existing code.

 2.1 Can we improve a conversion?

 For example, QStringList - QString is very tempting, as it works 
only if the list is of size 1. The conversion could join all strings instead, 
it would be almost backward compatible, as we would alter only conversions 
that failed previously.
 I believe we should allow that; I can not wait for the bike-shedding 
about which character or string we should use to join them.

 2.2 How much we can break?

 Is missing data in the result of a conversion a reasonable cause to 
break behavior? For example QVariant(QColor) - 

Re: [Development] Proposal: All Qt modules must use the same version number

[Jędrzej Nowacki]

On Sunday 29 of June 2014 16:19:59 Lisandro Damián Nicanor Pérez Meyer wrote:
  That's of course only the binary installer ... I can't judge whether e.g.
  distributions would appreciate separate releases of QtWebEngine.
 
 No if it uses private headers.
 
 I currently need to rebuild on all arches gammaray, fcitx-qt and pyqt5 each 
 time I upload a new point release for this exact problem [0]. I would
 really like to avoid adding new stuff to that list, as it is a real PITA.

Hi,

  That sounds like an argument against any new releases ;-) Are gammaray and 
pyqt5 depend on private headers of QtWebEngine? If not then they should be 
fine. The detection you were talking about is in QtBase, so releasing a new 
version of QtWebEngine would not affect these apps.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: All Qt modules must use the same version number

[Jędrzej Nowacki]

On Monday 30 of June 2014 10:06:12 Olivier Goffart wrote:
 On Sunday 29 June 2014 16:19:59 Lisandro Damián Nicanor Pérez Meyer wrote:
  No if it uses private headers.
  
  I currently need to rebuild on all arches gammaray, fcitx-qt and pyqt5
  each
  time I upload a new point release for this exact problem [0]. I would
  really like to avoid adding new stuff to that list, as it is a real PITA.
  
  [0] Even if API/ABI matches, there seems to be a runtime detection of
  different versions of Qt in qobjectprivate. I can really understand why
  that check is there, so the best solution is to avoid third party stuff
  to use private headers. Having a different release schedule will
  certainly make any package count as third party in my POV.
 
 Totally off topic: I think using private header should be tried to be
 avoided. In the past, we used private header inside Qt because Qt was not
 split that much.  But one of the goal of modularisation was to allow
 independent release of different component of Qt.  The problem is that we
 could not get rid of the private header dependencies at the time (too much
 work).
 But still now, every module, even new, are using the private headers.
 Nothing is done to try to prevent it.
 
 I think there should be some kind of long term goal to avoid using private
 headers.
 
 We need to find a solution so that one need not to inherit from
 QObjectPrivate. (There is already QObject::setUserData, but it could be done
 better i guess)
 
 We need also to identify private APIs that could be polished and made
 public. For some modules such as QtQuick this is probably too hard.
 But for new modules such as WebEngine or such, it may be possible to avoid
 dependency on private API.

Hi, 

  As I agree in principle I do not think it is feasible in all cases. There 
are few problems:

 1. Lack of public api
 1.1 We have private api that could be polished and promoted to public, that 
could be done of course it is a bit of effort but it make sense.
 1.2 Private api that make sense only to an internal use-case, does it make 
sense to generalize it and potentially make everything more complex, 
especially in context of long term BC?

 2 Performance, public api is generally slower then a private one, because of  
inline'ing, type checks, range checks and so on.


What about creating an intermodule api, which would stay private from a user 
point of view. We can agree on some rules, like for example not removing 
symbols between patch releases, having some test coverage?

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: All Qt modules must use the same version number

[Jędrzej Nowacki]

On Monday 30 of June 2014 09:48:05 Stephen Kelly wrote:
 On Friday, June 27, 2014 14:50:39 you wrote:
  Hi,
  
It seems that Jocelyn answered most of the questions, but I put my
answers
  
  anyway :-)
  
  On Wednesday 25 of June 2014 15:42:36 Stephen Kelly wrote:
   (...)
   
   Conclusion 1) Even if a Qt module has a disparate version scheme,
   bumping
   
   its major version and changing its SONAME are not acceptable. Therefore
   the
   major version must stay the same until Qt 6.
   
   Proposal 1) All Qt modules must use the major version '5' for
   consistency.
  
  Technically it is possible and we should consider to do it if it is
  _really_ necessary.
 
 Can you give us some criteria for 'really necessary' which are not met by
 the enginio situation?
Well, it is exactly the same as breaking any other BC promise. Breaking BC 
just to satisfy SONAME naming convention is not really convincing me. If we 
have to change api and architecture of the module, then we may consider 
bumping the major version. By really necessary I meant that the operation 
should be avoided, and we should try to keep BC as long as possible.

  It is a matter of careful name-spacing in the new major module
  version. We should not get to a situation in which it is easier to abandon
  a module and create a new one then bump the major version number.
 
 Then what is the real value in the major version number being different?
From a user perspective it it different and from technical perspective you can 
keep the same module and class names.

  Enginio is using private API for QObjectPrivate creation. So it has to be
  re- compiled and tested per Qt patch release. I do not see how it creates
  dll hell as Enginio is keeping binary compatibility.
 
 Version 1.0.5 works with Qt 5.3.0. Version 1.0.7 may not work with any
 5.3.x.
 
 Given that qmake has no way of helping you out with that, do you really not
 see a problem?
Not really as Qt5.3.x version would be shipped with specific version of 
Enginio, from qmake perspective there should be only one Enginio library. 

  Each new version is compiled and tested against specific QtCore (and
  friends) version, it would be 1 to 1 mapping.
 
 Such a mapping would exist only in brains or in a wiki page.
 
 Why create a situation where such a mapping is needed at all?
Why? By default we install all submodules so the mapping would be implicit the 
installer.

   Proposal 2) All modules which are 'part of Qt 5.x.y' must use the
   version
   number '5.x.y'.
   
   If a module wants to make an out-of-band release, they must use a
   different
   version number such as 5.x.y.z or some other completely different number
   (1.0.5 would also be ok for an out of band release, but that could not
   be
   part of Qt 5.x.y).
   
   qtenginio is exempt from these proposals because it is a 'past mistake'.
  
  I disagree, then you would end-up with double version numbers which would
  confuse our users. Is version 1.5 newer then 5.4? How to advocate it?
 
 Good questions.
 
 Is qtenginio 1.0.7 newer than Qt 5.4? How to advocate it?
 
 Why get into a situation where such questions need to be asked at all?
If Enginio 1.0.7 is shipped with Qt5.4 then the question is invalid from a 
user point of view, because Enginio is installed already, Whatever it is the 
newest possible one or not is a different story, solved by maintenance tool.

  As far I understand past mistake of Enginio is not having Qt5 prefix,
  not that it has a different version number.
 
 We definitely made multiple mistakes there. At least not discussing the
 break from convention was another one.
Well, it was not a break really. QtWebkit, when it was heavily developed was 
released on own schedule, with an additional version number. Then one of the 
goals of modularization, around five years ago, was to be able to release a 
module on their own. I wrongly assumed that it is a common knowledge, I'm 
sorry for that.  

 Thanks,
Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: All Qt modules must use the same version number

[Jędrzej Nowacki]

Hi,
  It seems that Jocelyn answered most of the questions, but I put my answers 
anyway :-)

On Wednesday 25 of June 2014 15:42:36 Stephen Kelly wrote:
 (...)
 Conclusion 1) Even if a Qt module has a disparate version scheme, bumping
 its major version and changing its SONAME are not acceptable. Therefore the
 major version must stay the same until Qt 6.
 
 Proposal 1) All Qt modules must use the major version '5' for consistency.
Technically it is possible and we should consider to do it if it is _really_ 
necessary. It is a matter of careful name-spacing in the new major module 
version. We should not get to a situation in which it is easier to abandon a 
module and create a new one then bump the major version number.

 qtenginio uses private QtCore API.
 
  $ git grep \-private src/
  src/enginio_client/enginio_client.pro:QT += core-private network
  src/enginio_plugin/enginio_plugin.pro:QT += qml quick enginio
 enginio-private core-private
 
 That means that a particular version of qtenginio is tied to a particular
 version of QtCore.
 
 Conclusion 2) A disparate version scheme for something released 'as part of
 Qt 5.x.y' creates dll-hell.

 Furthermore, the version of qtenginio released with Qt 5.x.y is only tested
 with that 'distribution version' it was part of (that is qtenginio 1.0.5 was
 only tested with and a part of Qt 5.3.0). There is no way anyone is going
 to test any significant portion of the possible combination matrix.
Enginio is using private API for QObjectPrivate creation. So it has to be re-
compiled and tested per Qt patch release. I do not see how it creates dll hell 
as Enginio is keeping binary compatibility. 

Each new version is compiled and tested against specific QtCore (and friends) 
version, it would be 1 to 1 mapping.
 
 Conclusion 3) Using the version of qtenginio released with the version of Qt
 it was distributed with is the only sane thing to do.
 
 A requirement to make newer releases of qtenginio work with previous Qt
 releases would constrain qtenginio development.

 Conclusion 4) If multiple qtenginio releases are made between Qt 5.x.y and
 Qt 5.x.y+1, they can only reasonably be expected to work with Qt 5.x.y, not
 later or earlier releases.
From binary compatibility perspective yes, it is a sensible assumption for 
modules using private api as enginio. From source code perspective it really 
depends.

 Proposal 2) All modules which are 'part of Qt 5.x.y' must use the version
 number '5.x.y'.
 
 If a module wants to make an out-of-band release, they must use a different
 version number such as 5.x.y.z or some other completely different number
 (1.0.5 would also be ok for an out of band release, but that could not be
 part of Qt 5.x.y).
 
 qtenginio is exempt from these proposals because it is a 'past mistake'.
I disagree, then you would end-up with double version numbers which would 
confuse our users. Is version 1.5 newer then 5.4? How to advocate it? I do not 
see how 5.x.y.z is different than z.x.y as modules are shipped together with 
Qt.

As far I understand past mistake of Enginio is not having Qt5 prefix, not 
that it has a different version number.

Cheers,
  Jędrek

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork QtCS Session

[Jędrzej Nowacki]

On Thursday 12 of June 2014 18:24:38 Thiago Macieira wrote:
   if we modularize the repos more, we need to go full monty and modularize
   *everything*.
   i really wouldn't want to do that with the current build system.
 
  
 
  I guess it would be a nice long term goal.
 
 I'm sorry, that's pointless. I don't think that's a nice goal at all.
 
 The modules were invented so that we'd have related libraries together and 
 they could release at different pace if required. It's technically supposed
 to  be possible to use only a subset of the modules.
 
 It makes no sense to build Qt without any platform plugin, for example. The 
 plugins must stay with QtGui, which implies that QtCore, QtNetwork and
 QtDBus must too.

Don't be sorry, you are right :-) From that perspective it doesn't make sense. 
My perspective was a bit closer to autotest execution; for example why to run 
dbus tests while a change is touching only gui. Separate modules are solving 
that problem somehow naturally, but you are right we can fix it on a different 
level, without bumping modules count.

Btw. it seems that only xcb platform plugin depends on dbus and that the 
dependency is optional.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork QtCS Session

[Jędrzej Nowacki]

Hi,

  Thanks for sending the notes :-) I have a question about this point:

 Move QtNetowrk into its own git modules
Thiago: Network cannot swapped out into its own module, due to dbus
reqiring it in the future

Why dbus can not be moved to a separate module or together with networking 
stack?

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtNetwork QtCS Session

[Jędrzej Nowacki]

On Thursday 12 of June 2014 11:47:49 Oswald Buddenhagen wrote:
 On Thu, Jun 12, 2014 at 10:40:03AM +0200, Jędrzej Nowacki wrote:
  Hi,
  
Thanks for sending the notes :-) I have a question about this point:
   Move QtNetowrk into its own git modules
   
  Thiago: Network cannot swapped out into its own module, due to dbus
  reqiring it in the future
  
  Why dbus can not be moved to a separate module or together with networking
  stack?
 
 because some plugins depend on dbus.
Ah, of course

 if we modularize the repos more, we need to go full monty and modularize
 *everything*.
 i really wouldn't want to do that with the current build system.
I guess it would be a nice long term goal.

 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The rowsAboutToBeRemoved signal in ListModel

[Jędrzej Nowacki]

On Friday 16 of May 2014 12:33:49 Ben Lau wrote:
 Why? Is there any special reason to implement in this order? or it is a bug?

It look like a bug.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)

[Jędrzej Nowacki]

On Wednesday 14 of May 2014 08:01:33 Oliver Wolff wrote:
 On 13/05/2014 16:47, Thiago Macieira wrote:
  Em ter 13 maio 2014, às 09:57:59, Knoll Lars escreveu:
  That won't help unless we also disable the revdep for QtQuick, as
  QtQuick
  depends on QtNetwork.
  
  That doesn’t mean we need to run the network tests as a revdep as well.
  
  Then the problem is simply of running the network tests. The CI could be
  smart and decide that it doesn't need to run tests/auto/network if
  src/network wasn't modified.
 
 I don't think that this is a good idea. Changes in QtCore which break
 something in network
 wouldn't cause a CI error and test failures would only surface as soon
 as a change to network
 is made. Isn't that one of the situations we want to avoid?
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

Hi,

  As far I know the plan was to have a full Qt5 build and test cycle per day. 
So no, brokenness would be detected much earlier. Btw. the same argumentation 
could be used for every other module. In my opinion it is fine to break 
intermodule dependencies from time to time, assuming that we can detect and 
recover quickly.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtQml value types

[Jędrzej Nowacki]

On Friday 25 of April 2014 13:03:33 Richard Moore wrote:
 On 25 April 2014 11:51, Alberto Mardegan ma...@users.sourceforge.netwrote:
  For instance, I would like to have a GeoPoint type with latitude and
  longitude properties; if I exposed it as a QVariantMap, I wouldn't be
  able to prevent the QML code from doing stuff like:
  p.latitude = 60
  p.longitde = 10 // note the typo
 
 An approach like http://qt-project.org/doc/qt-4.8/qscriptclass.html would
 allow this to be enforced.
 
 Rich.

Hi,

  This one was elegant but a bit too heavy from performance point of view, 
mostly because it was not possible to cache any data or assume data layout. As 
soon you had qscriptclass in the scope your code was not optimal anymore.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Categorized logging inside Qt

[Jędrzej Nowacki]

On Friday 11 of April 2014 08:31:41 Rutledge Shawn wrote:
 On 11 Apr 2014, at 10:11 AM, Poenitz Andre wrote:
  shawn.rutle...@digia.com wrote:
  On 10 Apr 2014, at 7:20 PM, Frederik Gladhorn wrote:
  Hi all,
  
  I just started to port accessibility to the new and shiny categorized
  logging.
  http://blog.qt.digia.com/blog/2014/03/11/qt-weekly-1-categorized-loggin
  g/
  
  I'd propose we decide on a certain style of declaring categories.
  
  A quick grep shows that we already have some variety, I'd like to unify
  this before Qt 5.3 is out of the door. I actually saw a patch adding
  DBG_FOOBAR as new category, that made me wonder about which style we
  should use. 
  I think the pattern is OK though: all uppercase, with a prefix like DBG
  and try to keep them as short as possible since they get repeated all
  over.
  
  We tend to avoid abbreviations, so DBG instead of DEBUG looks odd.
  
  Your reasoning that it's REPEATED ALL OVER also MAKES ME THINK
  that USING ALL CAPS might be NO GOOD IDEA as it gives ME the
  feeling the code is constantly SHOUTING AT ME.
 
 Not having all caps would be fine, but I still think they should be short,
 and don't see a problem with abbreviations because the context is obvious;
 it doesn't obscure the meaning like making a member variable or function
 name too short would do.  qCDebug is already an abbreviation for Qt
 categorized logging of the debug variety.
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

Hi,

  So 'C' in qCDebug is for categorized, I thought that it is for C-like. 
Abbreviations in code are wrong, please try to avoid them. Meaning is obvious 
for you, because you already knew the meaning, for a newcomer it is not that 
trivial.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding Enginio (qtenginio) to the Qt release

[Jędrzej Nowacki]

On Monday 06 of January 2014 17:23:43 Frederik Gladhorn wrote:
 Hello,
 
 we (some of us at Digia) have been working on Enginio - a convenient cloud
 storage for Qt applications. Since the library is actively maintained we
 would like to integrate it into the official Qt release for Qt 5.3.
 
 For those curious now, there is already the option to get it when using the
 Qt 5.2 online installer.
 
 For more information see http://engin.io

Hi,

  I was asked to conclude the thread, as it seems that the result of it was 
interpreted differently by different people:

  Enginio will be added as an official Qt add-on module. 

  Good that we had alpha to catch such misunderstandings :-) 

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development