Re: [Development] Qt API review with clazy

[Mathias Hasselmann]

Just that the approach of clang-tidy is fundamentally wrong:

You simply don't do static checks as a after thought, at random times 
when sun, mars and moon are in proper constellation.


Why? Because when running this checks occasionally too much cruft will 
have accumulated that it is worth and reasonable to fix those issues: 
Too big chunk of boring and still expensive work. Too big risk to 
introduce regressions.


You really want to make this checks part of your daily development 
experience, you want the compiler to tell you about your mistakes as 
soon as you compile that code for the first time. It's much easier to 
fix your mistakes if you just wrote them. It's much safer to fix them 
before even doing the first tests. Well, and you'll learn much earlier 
about possible anti-patterns, so you'll write less of such code.


I hear you saying "but you could add clang-tidy" to your build scripts, 
but that's not a valid argument adding the following flags is considered 
too much effort already:


  -Xclang -load -Xclang ClangLazy.so -Xclang -add-plugin -Xclang clang-lazy

Thanks,
Mathias

Disclaimer: I am working with Sergio and using his awesome plugin since 
its very first days.


Am 12.09.2016 um 08:38 schrieb Ch'Gans:

On 12 September 2016 at 10:34, Sergio Martins  wrote:

On Sunday, 11 September 2016 21:43:46 WEST Jérémie Delaitre wrote:

Can the same checks be implemented in clang-tidy instead of having yet
another tool? clang-tidy now has boost specific checks so maybe they would
also accept a Qt specific module in there.


I haven't been able to use clang-tidy on big qmake projects such as Qt, it
either crashes or stops with "include not found" errors. It also requires an
intermediate step, where you generate a "compiler command database" file with
yet another tool [1]


Both CMake (since 2.8.5, see [1]) and Qbs (master branch) can generate
this "compiler command database".
Maybe your tool could be made to work with this DB (via clang-tidy)
and as a clang plugin.
The DB approach has the added advantage that it doesn't require
modifying CXX flags, which can be a problem on projects that have
"buggy" build files.
Having your checks run by clang-tidy would also definitely widen your user base.
clang-tidy have specific rules for LLVM, boost, google, ... Would be
nice to add Qt.

Chris

[1] http://clang.llvm.org/docs/JSONCompilationDatabase.html#supported-systems


clazy, otoh, is a compiler plugin, it integrates with your normal compilation
run, you don't have to run any more tools after doing "make" as you usually
do.

Enabling clazy is just a matter of modifying your CXX flags,  which you can
easily do with qmake or mkspec. Or ENABLE_CLAZY in CMake if you're building
KDE.


[1] https://github.com/rizsotto/Bear

Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt Experts
___
Development mailing list
Development@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] No Gerrit notification email?

[Tuukka Turunen]

Hi,

There have been issues with Gerrit mail server integration, so the 
notifications were disabled during the weekend. We'll see if these can soon be 
re-enabled - but first we need to get the Gerrit / CI properly working again.

Yours,

Tuukka

> -Original Message-
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Marc Mutz
> Sent: perjantaina 9. syyskuuta 2016 9.40
> To: development@qt-project.org
> Subject: [Development] No Gerrit notification email?
> 
> Hi,
> 
> I don't get notification emails from Gerrit anymore, and since the big
> downtime of Gerrit and dev ML two(?) days ago only sporadically.
> 
> Anyone else seeing this? Or is it KDAB's mail server problem?
> 
> Thanks,
> Marc
> 
> --
> Marc Mutz  | Senior Software Engineer KDAB
> (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@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 API review with clazy

[Ch'Gans]

On 12 September 2016 at 19:06, Mathias Hasselmann
 wrote:
> Just that the approach of clang-tidy is fundamentally wrong:

Hi Mathias,

No offense, but you arguments are fundamentally wrong too. Your
workflow is not everyone's workflow!

>
> You simply don't do static checks as a after thought, at random times when
> sun, mars and moon are in proper constellation.

I don't see the problem, people are free to choose if, when and which
checks they fancy run.

> Why? Because when running this checks occasionally too much cruft will have
> accumulated that it is worth and reasonable to fix those issues: Too big
> chunk of boring and still expensive work. Too big risk to introduce
> regressions.

Running clang-tidy is way slower than compiling code, a nightly check
might be enough (or not, again this is a personal choice), or you
could decide to run the checks systematically on pull requests because
you don't trust the authors (for whatever reason, inc the usual "oops,
forgot to do that", human do errors).

> You really want to make this checks part of your daily development
> experience, you want the compiler to tell you about your mistakes as soon as
> you compile that code for the first time. It's much easier to fix your
> mistakes if you just wrote them. It's much safer to fix them before even
> doing the first tests. Well, and you'll learn much earlier about possible
> anti-patterns, so you'll write less of such code.

Maybe, but again, this is a personal choice based on personal usage of
the said tool.

> I hear you saying "but you could add clang-tidy" to your build scripts, but
> that's not a valid argument adding the following flags is considered too
> much effort already:
>
>   -Xclang -load -Xclang ClangLazy.so -Xclang -add-plugin -Xclang clang-lazy

This has nothing to do with clang-tidy, this is how you would use
Sergio's *clang plugin*.
Clang tidy is a separate tool that you can run externally once you
have extracted the compilation database from your project. clang-tidy
doesn't compile anything, it just run sanity checks, period.

Sanity checks ran by clang-tidy can be of arbitrary complexity, and as
such can take really long time. You might not want to be slow down by
this while you're actively developing.
If you go this way, then why don't you always run your applications in
profiling mode to make sure you don't introduce bottle-necks or memory
leaks "as-you-go"? Well we all know the answer: Because it is way too
slow.

Chris.

> Thanks,
> Mathias
>
> Disclaimer: I am working with Sergio and using his awesome plugin since its
> very first days.
>
>
> Am 12.09.2016 um 08:38 schrieb Ch'Gans:
>>
>> On 12 September 2016 at 10:34, Sergio Martins 
>> wrote:
>>>
>>> On Sunday, 11 September 2016 21:43:46 WEST Jérémie Delaitre wrote:

 Can the same checks be implemented in clang-tidy instead of having yet
 another tool? clang-tidy now has boost specific checks so maybe they
 would
 also accept a Qt specific module in there.
>>>
>>>
>>> I haven't been able to use clang-tidy on big qmake projects such as Qt,
>>> it
>>> either crashes or stops with "include not found" errors. It also requires
>>> an
>>> intermediate step, where you generate a "compiler command database" file
>>> with
>>> yet another tool [1]
>>
>>
>> Both CMake (since 2.8.5, see [1]) and Qbs (master branch) can generate
>> this "compiler command database".
>> Maybe your tool could be made to work with this DB (via clang-tidy)
>> and as a clang plugin.
>> The DB approach has the added advantage that it doesn't require
>> modifying CXX flags, which can be a problem on projects that have
>> "buggy" build files.
>> Having your checks run by clang-tidy would also definitely widen your user
>> base.
>> clang-tidy have specific rules for LLVM, boost, google, ... Would be
>> nice to add Qt.
>>
>> Chris
>>
>> [1]
>> http://clang.llvm.org/docs/JSONCompilationDatabase.html#supported-systems
>>
>>> clazy, otoh, is a compiler plugin, it integrates with your normal
>>> compilation
>>> run, you don't have to run any more tools after doing "make" as you
>>> usually
>>> do.
>>>
>>> Enabling clazy is just a matter of modifying your CXX flags,  which you
>>> can
>>> easily do with qmake or mkspec. Or ENABLE_CLAZY in CMake if you're
>>> building
>>> KDE.
>>>
>>>
>>> [1] https://github.com/rizsotto/Bear
>>>
>>> Regards,
>>> --
>>> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
>>> Klarälvdalens Datakonsult AB, a KDAB Group company
>>> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
>>> KDAB - The Qt Experts
>>> ___
>>> Development mailing list
>>> Development@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
>>
> ___
> Developmen

Re: [Development] Qt API review with clazy

[Konstantin Tokarev]

10.09.2016, 18:29, "Sergio Martins" :
> Hi,
>
> I've been developing a Qt oriented clang compiler plugin called clazy [1].
>
> It has about 50 custom checks/warnings for common Qt and C++ mistakes.
> I would like to propose clazy to be used to sanitize API of new Qt modules. Of
> course, only a few of the 50 checks are relevant to API, so I will only talk
> about those.
>
> ** Checks that can find bugs **
>
> * clazy-copyable-polymorphic
>
> polymorphic copyable classes are usually vulnerable to slicing [2]
> The cases I found were either real bugs or easily fixable by adding
> Q_DISABLE_COPY.
>
> * clazy-rule-of-two-soft
>
> Finds when you're calling the compiler generated copy-ctor of a class that has
> a user-defined assign operator (and vice-versa).
> You'll want to write both, or none. I've found many bugs where one of them was
> missing (where the copy-ctor didn't have the same behavior as the assign-
> operator).
>
> In most cases you can simply remove the user defined methods and let the
> compiler generate them.
>
> * clazy-rule-of-three
>
> Either implement all 3 dtor, copy-ctor and assign-op or none of them.
>
> This is my favorite as it finds many bugs which are easy to fix.
>
> It's very common to have a class that is holding a resource and frees it in
> the DTOR, but if that class gets copied then two DTORs might run, freeing the
> resource twice, which might crash or misbehave the app.
>
> See for example https://codereview.qt-project.org/#/c/151488/ , QBasicTimer is
> copyable, but when a copy is destroyed it stops both timers.
>
> Also common is copying a class that has a d-pointer and getting a crash when
> both DTORs are run because you forgot the copy-ctor and assign-op.
>
> So either implement the copy-ctor and assign-op too, or use Q_DISABLE_COPY, or
> in the majority of cases, just remove your DTOR if it doesn't do any work.
>
> * mutable-container-key
>
> QMap or QHash having a key that can be modified by external factors (like
> QPointer)
>
> ** Nice to haves (don't find real bugs but are related to performance) **
>
> * clazy-function-args-by-ref
>
> Pass big or non-trivial types (so copy-ctor and dtor don't get called) by
> const-ref
>
> * clazy-missing-typeinfo
>
> Types used in containers but missing a Q_DECLARE_TYPEINFO
>
> * clazy-qenums:
>
> Use Q_ENUM instead of Q_ENUMS

Q_ENUM increases amount of metacode generated for enum. Is it really a good 
idea to replace Q_ENUMS everywhere?

>
> * clazy-missing-qobject-macro
>
> missing a Q_OBJECT macro
>
> ** Debatable **
>
> * clazy-function-args-by-value
> Pass small and trivial types by value
>
> Thanks for reading.
>
> [1] https://github.com/KDE/clazy
> [2] https://en.wikipedia.org/wiki/Object_slicing
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] which part of the editor's shared files is a Kate from

[Eike Ziller]

> On Sep 9, 2016, at 5:35 PM, Ernst Maurer  wrote:
> 
> In my qtc-based projects, there is a lot of doxygen.
> Qtc contains a highlighter for doxygen-style comments,
> but no highlighter for doxyfile,
> I've wrote this (a little bit smarter than simple INI format) 
> and using this for some time. I'd like to share , probably this can be 
> helpful for someone else.
> 
> does qtc store own copy of the highlighters? or check this out from kate 
> editor repository ? 

We ship a few ourselves 
(http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/share/3rdparty/generic-highlighter)
and since there already is the one for .dox/.doxygen, I’d say one for doxyfile 
would be ok to have there too.
They are mostly copies from the original Kate files though, so it would be good 
to have the doxyfile one in Kate too.
(You can also get the other Kate highlighting files by downloading them in the 
options > Text Editor > Generic Highlighter.)

Br, Eike

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B




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

Re: [Development] which part of the editor's shared files is a Kate from

[Ernst Maurer]

This is doxygen comments for, but I was talking about doxygen configuring
files.
But anyway, ok, i got

пн, 12 сен 2016 г., 10:46 Eike Ziller :

>
> > On Sep 9, 2016, at 5:35 PM, Ernst Maurer  wrote:
> >
> > In my qtc-based projects, there is a lot of doxygen.
> > Qtc contains a highlighter for doxygen-style comments,
> > but no highlighter for doxyfile,
> > I've wrote this (a little bit smarter than simple INI format)
> > and using this for some time. I'd like to share , probably this can be
> helpful for someone else.
> >
> > does qtc store own copy of the highlighters? or check this out from kate
> editor repository ?
>
> We ship a few ourselves (
> http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/share/3rdparty/generic-highlighter
> )
> and since there already is the one for .dox/.doxygen, I’d say one for
> doxyfile would be ok to have there too.
> They are mostly copies from the original Kate files though, so it would be
> good to have the doxyfile one in Kate too.
> (You can also get the other Kate highlighting files by downloading them in
> the options > Text Editor > Generic Highlighter.)
>
> Br, Eike
>
> --
> Eike Ziller
> Principal Software Engineer
>
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
> eike.zil...@qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
>
>
>
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Maintainers: your action needed: Qt 5.6.2 change files mostly missing!

[Sean Harmer]

Hi,

Qt 3D doesn’t need one for 5.6.2.

Cheers,

Sean

> On 12 Sep 2016, at 06:45, Jani Heikkinen  wrote:
> 
> Hi all,
> 
> It seems most of change files for Qt 5.6.2 is still missing from packages :( 
> Here are the links for open changes:
> 
> qt3d:https://codereview.qt-project.org/#/c/170367/ 
> 
> qtandroidextras: https://codereview.qt-project.org/#/c/170387/3 
> 
> qtbase: https://codereview.qt-project.org/#/c/170370/ 
> qtcanvas3d: 
> https://codereview.qt-project.org/#/c/170369/ 
> 
> qtconnectivity: https://codereview.qt-project.org/#/c/170389/ 
> 
> qtlocation: https://codereview.qt-project.org/#/c/170413/ 
> qtmultimedia: 
> https://codereview.qt-project.org/#/c/170406/ 
> 
> qtsensors: https://codereview.qt-project.org/#/c/170379/ 
> qtserialport:https://codereview.qt-project.org/#/c/170373/
>  
> qtwayland: https://codereview.qt-project.org/#/c/170414/ 
> qtwebengine: 
> https://codereview.qt-project.org/#/c/170310/ 
> 
> qtwebview: https://codereview.qt-project.org/#/c/170378/ 
> 
> 
>  
> Maintainers, please make sure you finalize these & get it approved today (or 
> comment if one isn't needed in 5.6.2). These are now delaying our Qt 5.6.2 
> release! It seems mandatory fixes are in, we just need to get these change 
> files in and final packages created. Then we should be ready for the 
> release...
> 
> br,
> Jani
> 
> 
> 
> From: Jani Heikkinen
> Sent: Wednesday, September 7, 2016 3:27 PM
> To: development@qt-project.org
> Subject: Maintainers: your action needed
>  
> Hi all (maintainers),
> 
> We in the release team did initial versions of change files for Qt 5.6.2 
> release (to those modules where it was missing). Please take those over & 
> finalize those as soon as possible; We are planning to release Qt 5.6.2 
> already during next week. Changes are pushed to gerrit as WIP so please just 
> add/modify content, get the change approved & we will then stage those in.
> 
> br,
> Jani
> 
> Jani Heikkinen
> Release Manager
> 
> The Qt Company
> Elektroniikkatie 13
> 90590 Oulu Finland
> jani.heikki...@qt.io
> +358 50 4873735
> http://qt.io 
> 
>  
>      
>   
>  
> 
> ___
> 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 API review with clazy

[Mathias Hasselmann]

Am 12.09.2016 um 09:33 schrieb Konstantin Tokarev:

Use Q_ENUM instead of Q_ENUMS


Q_ENUM increases amount of metacode generated for enum. Is it really a good 
idea to replace Q_ENUMS everywhere?


One thing that makes Qt easy to use is consistency. Once you know enough 
of its classes using most other class is trivial as you know what to 
expect, what to look for.


So if ease of use and therefore consistency is a goal of Qt
I am happily paying that price.

Anywhere: Where would you draw the line for Q_ENUM vs. Q_ENUMS enums? 
Any rule about this would be arbitrary and therefore hard to remember, 
hard to get consistent.


I am a big fan of Q_ENUMS, the benefits it adds for QML and the benefits 
it adds for debugging, the benefits it adds for reliable data serialization.


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

Re: [Development] Qt 5.8 API review (vs 5.7.0)

[Mitch Curtis]

> -Original Message-
> From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
> project.org] On Behalf Of Edward Welbourne
> Sent: Friday, 9 September 2016 1:56 PM
> To: development@qt-project.org
> Subject: [Development] Qt 5.8 API review (vs 5.7.0)
> 
> Hi all,
> 
> It's that time in the release cycle again - API review time.
> If you can catch a moment when Gerrit isn't hiding, please take a look at
> any modules you care for:
> 
> https://codereview.qt-project.org/170634 -- qtbase
> https://codereview.qt-project.org/170635 -- qtdeclarative
> https://codereview.qt-project.org/170636 -- qtactiveqt
> https://codereview.qt-project.org/170637 -- qtmultimedia
> https://codereview.qt-project.org/170638 -- qttools
> https://codereview.qt-project.org/170639 -- qtlocation
> https://codereview.qt-project.org/170640 -- qtconnectivity
> https://codereview.qt-project.org/170641 -- qtwayland
> https://codereview.qt-project.org/170642 -- qt3d
> https://codereview.qt-project.org/170643 -- qtserialbus
> https://codereview.qt-project.org/170644 -- qtserialport
> https://codereview.qt-project.org/170645 -- qtandroidextras
> https://codereview.qt-project.org/170646 -- qtwebsockets
> https://codereview.qt-project.org/170647 -- qtwebengine
> https://codereview.qt-project.org/170648 -- qtcanvas3d
> https://codereview.qt-project.org/170649 -- qtcharts
> https://codereview.qt-project.org/170650 -- qtdatavis3d
> https://codereview.qt-project.org/170651 -- qtvirtualkeyboard

qtvirtualkeyboard looks OK.

> https://codereview.qt-project.org/170652 -- qtscxml
> 
>   Eddy.
> ___
> Development mailing list
> Development@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 API review with clazy

[Ulf Hermann]

On 09/12/2016 10:25 AM, Mathias Hasselmann wrote:

Am 12.09.2016 um 09:33 schrieb Konstantin Tokarev:

Use Q_ENUM instead of Q_ENUMS


Q_ENUM increases amount of metacode generated for enum. Is it really a good 
idea to replace Q_ENUMS everywhere?


One thing that makes Qt easy to use is consistency. Once you know enough of its 
classes using most other class is trivial as you know what to expect, what to 
look for.

So if ease of use and therefore consistency is a goal of Qt
I am happily paying that price.

Anywhere: Where would you draw the line for Q_ENUM vs. Q_ENUMS enums? Any rule 
about this would be arbitrary and therefore hard to remember, hard to get 
consistent.


Following this argument you'll have to draw the line at public Qt headers vs 
other other Qt code. The user will see the nice consistency and we can still 
save some metacode where we don't need the benefits of Q_ENUM. I haven't 
checked how much space it actually saves, though.

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

Re: [Development] QBS module git cloning

[Edward Welbourne]

Ernst Maurer said:
> Each time, when I'm trying to clone qt creator I'm getting the error related 
> with QBS

I'm able to clone this repo without problems, both bare and with work-tree.
The cloned repos appear entirely sane.

> Submodule 'qbs' (http://code.qt.io/cgit/qt-labs/qbs.git) registered for path 
> 'src/shared/qbs'

It's conceivable the git submodule infrastructure is what's causing the problem.
I just cloned qbs directly, rather than via cloning of creator.  My commands 
were
git clone --bare http://code.qt.io/cgit/qt-labs/qbs.git
and the same without --bare (run on Debian/testing GNU/Linux).

What source are you cloning creator from ?
What's the actual clone command you run ?
What sort of system are you running this from ?

> error: Failed connect to code.qt.io:80; No error 
> (curl_result = 7, http_code = 0, sha1 = 
> e1d5dc0b836dc6f709b2deeff2d0051d03b2c135)

The curl man-page decodes curl_result = 7 as:

   7  Failed to connect to host.

You clearly connected repeatedly to the host to fetch other blobs, failing just 
this once.
I'd guess flaky network (or flaky server), but you say this recurs.
Does it always fail with the same sha1s or do they vary ?

> error: Unable to find f073f4556ca26a0df1e8df1d8684c61d76394c53 under 
> http://code.qt.io/cgit/qt-labs/qbs.git
> Cannot obtain needed blob f073f4556ca26a0df1e8df1d8684c61d76394c53

My clone contains this blob: it is a version of file
tests/auto/api/tst_api.cpp

> while processing commit 9bbbf55ea6d1e80871ab810eebaeaf377bc0aad0.
> error: Fetch failed.

This commit is a few steps short of branch 1.4.
I am able to access it without problems in my clones.
However, if you failed to fetch one of its blobs, it would indeed be broken.

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

Re: [Development] Qt API review with clazy

[Mathias Hasselmann]

Hello Chris,


On 12 September 2016 at 19:06, Mathias Hasselmann
 wrote:

Just that the approach of clang-tidy is fundamentally wrong:


Hi Mathias,

No offense, but you arguments are fundamentally wrong too. Your
workflow is not everyone's workflow!



You simply don't do static checks as a after thought, at random times when
sun, mars and moon are in proper constellation.


I don't see the problem, people are free to choose if, when and which
checks they fancy run.


Why? Because when running this checks occasionally too much cruft will have
accumulated that it is worth and reasonable to fix those issues: Too big
chunk of boring and still expensive work. Too big risk to introduce
regressions.


Running clang-tidy is way slower than compiling code, a nightly check
might be enough (or not, again this is a personal choice), or you
could decide to run the checks systematically on pull requests because
you don't trust the authors (for whatever reason, inc the usual "oops,
forgot to do that", human do errors).

> Sanity checks ran by clang-tidy can be of arbitrary complexity, and as
> such can take really long time. You might not want to be slow down by
> this while you're actively developing.

Well, with clang-tidy being slow you just gave another reason to have a 
compiler plugin for this quick, very obvious tests. In my experience 
clazy has no measurable impact to compile time.



If you go this way, then why don't you always run your applications in
profiling mode to make sure you don't introduce bottle-necks or memory
leaks "as-you-go"? Well we all know the answer: Because it is way too
slow.


Besides clazy being blasting fast you are comparing apples with oranges. 
The issues clazy blames are plain Qt usage bugs. Just the same kind of 
issues the compiler reports for regular C++ already. Ideally the 
compilers would checks those issues out of the box already. Obviously 
they can't because Qt layers stuff on top of C++.


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

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

[Edward Welbourne]

Marc Mutz said:
> The obvious question is, then, why is only "the one person" doing merges?
> Allow more people to upload merges, and you will get the spreading you desire.

Several people can upload merges.
One person looks after integration in qt5 and all its sub-modules.
We can spread the load (indeed, I carried it for a few weeks while
Liang was on holiday), and I believe module owners can do their own
merges (which saves the integration team work), but the integration team
takes responsibility for ensuring merges are happening.
So it ends up being that Liang, as integrator, does most merges.

> In fact, one could also be led to think that the perceived security of "it has
> passed CI in dev, so it's safe for LTS" will cause more and less appropriate
> commits to be backported to LTS.

I shall amend sanity-bot to object to cherry-picks to LTS unless they
come from gerrit/stable.
So "it has passed  CI in dev" won't get it into LTS.
It has to have passed review and CI in stable to be a candidate for
cherry-picking to LTS.
Then the second review can haggle about whether it belongs in LTS.
That can take a long time without delaying the change's merge-journey up
to dev.

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

Re: [Development] QBS module git cloning

[Konstantin Tokarev]

10.09.2016, 01:10, "Ernst Maurer" :
> Each time, when I'm trying to clone qt creator I'm getting the error related 
> with QBS
>  (I'm not an active developer, and I do this probably monthly)
> Do I something wrong? because it happens always when I'm trying to get 
> creator from git
>
> Submodule 'qbs' (http://code.qt.io/cgit/qt-labs/qbs.git) registered for path 
> 'src/shared/qbs'
>
> Cloning into 'src/shared/qbs'...
>
> error: Failed connect to code.qt.io:80; No error (curl_result = 7, http_code 
> = 0, sha1 = e1d5dc0b836dc6f709b2deeff2d0051d03b2c135)
>
> error: Unable to find f073f4556ca26a0df1e8df1d8684c61d76394c53 under 
> http://code.qt.io/cgit/qt-labs/qbs.git
> Cannot obtain needed blob f073f4556ca26a0df1e8df1d8684c61d76394c53
> while processing commit 9bbbf55ea6d1e80871ab810eebaeaf377bc0aad0.
> error: Fetch failed.

That's probably unrelated to you issue, but I'd recommended you to use git 
protocol instead of http


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

[Development] QtCon 2016 session notes: Qt for macOS

[Morten Sorvig]

Session held friday september 2nd. 

Around 15 persons in attendance, with a good mix of full-time Qt developers,
Qt contributors, and Qt application developers.

1) We briefly went through the work on QTBUG-49827 (Qt on macOS 
Graphics/integration update):

   Development of native autotests and manual tests.
   Layer-backed QWindows.
   Color space support.
   Improving support for embedding QWindow in native view hierarchies.

This was mostly information sharing. Some questions were asked (and answered):

Q: Should layer mode be enabled by default, like on UIKit? 
A: Maybe. Let’s make it work first.

Q: Will this require changes to application code? 
A: The goal is no changes to application code. Some changes to non-platform 
plugin code may
   be wanted, for example all QWindow users should drive animations using 
QWindow::requestUpdate().

2) We discussed dropping 32-bit support, which will enable us to (easily) use 
automated reference
counting (ARC) internally. As of today Qt does not support any 32-bit mac 
hardware, the only 
reason for keeping 32-bit going is to support applications with 32-bit 
components (non 64-bit 
clean source code or 32-bit only binaries). Other Apple platforms are 64-bit 
only.

In favor of keeping 32-bit support is the normal “Qt runs everywhere” argument, 
and not
having macOS be the only (desktop) port without 32-bit support.

Recommendation: We deprecate/obsolete 32-bit builds and phase in ARC usage in 
all apple-platform code.

3) Notifications: 

   There are patches for improving native notification support.
https://codereview.qt-project.org/#/c/166456/ (and one more)
   Do we want a new module? Cross-platform support via plugins.
   Can the deprecate existing QSystrayIcon/platform plugin support
   Some API revising needed. Do we want a signal-slot API to support
   user interaction with the notification.

4) Optional private API usage.

We may be able to improve e.g. the Mac style (see below) by using private API.
Apparently there are instances of private API usage on the App store, also from
“big name” applications.

Recommendation: Okay as long as applications have to opt-in to taking the risk
(the default Qt build is app-store compliant)

5) Styling:
  The mac style can be improved, with some/much effort.
  At the same time it does not help us in the native “feel”.
  Improvement: use new (10.7) alignment rectangle API.
  Improvement: perhaps also by using the CoreUI private framework directly.
  If exact native behavior is needed: use native components, for example 
NSToolBar
  directly, or wrapped via QMacToolBar.
  Meta-point: how do we (Qt) deal with continuing platform divergence?


We ran out of time and may have missed some topics and/or input - following up 
on
this email is possible.

Morten





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

Re: [Development] QBS module git cloning

[Ernst Maurer]

Thank you,
I'll try.
Seems it doesn't work from time to time,
Yesterday, I could do this, with no issues

пн, 12 сен 2016 г., 12:34 Konstantin Tokarev :

>
>
> 10.09.2016, 01:10, "Ernst Maurer" :
> > Each time, when I'm trying to clone qt creator I'm getting the error
> related with QBS
> >  (I'm not an active developer, and I do this probably monthly)
> > Do I something wrong? because it happens always when I'm trying to get
> creator from git
> >
> > Submodule 'qbs' (http://code.qt.io/cgit/qt-labs/qbs.git) registered for
> path 'src/shared/qbs'
> >
> > Cloning into 'src/shared/qbs'...
> >
> > error: Failed connect to code.qt.io:80; No error (curl_result = 7,
> http_code = 0, sha1 = e1d5dc0b836dc6f709b2deeff2d0051d03b2c135)
> >
> > error: Unable to find f073f4556ca26a0df1e8df1d8684c61d76394c53 under
> http://code.qt.io/cgit/qt-labs/qbs.git
> > Cannot obtain needed blob f073f4556ca26a0df1e8df1d8684c61d76394c53
> > while processing commit 9bbbf55ea6d1e80871ab810eebaeaf377bc0aad0.
> > error: Fetch failed.
>
> That's probably unrelated to you issue, but I'd recommended you to use git
> protocol instead of http
>
>
> --
> Regards,
> Konstantin
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Maintainers: your action needed: Qt 5.6.2 change files mostly missing!

[Alexander Blasche]

Hi Sean,

> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Sean Harmer
> Sent: Monday, 12 September 2016 9:59

> Qt 3D doesn’t need one for 5.6.2.

If that's the case then please add a statement to the change log telling the 
reader that there were no noteworthy changes. To the Qt user there is no way to 
distinguish a missing change log due to no changes from a missing change log 
because we didn't write it (despite having potentially a lot).

In my opinion there are noteworthy changes in Qt3D. There are 2 bugs fixed and 
hover event related changes... Don't you think this is relevant?

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

Re: [Development] Qt 5.8 API review (vs 5.7.0)

[Edward Welbourne]

I mentioned:
>> https://codereview.qt-project.org/170651 -- qtvirtualkeyboard
Mitch Curtis replied:
> qtvirtualkeyboard looks OK.

Please give review responses on the reviews themselves
(if you can catch Gerrit up for long enough to do so).

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

Re: [Development] Qt API review with clazy

[Ch'Gans]

On 12 September 2016 at 21:13, Mathias Hasselmann
 wrote:
> Hello Chris,
>
>> On 12 September 2016 at 19:06, Mathias Hasselmann
>>  wrote:
>>>
>>> Just that the approach of clang-tidy is fundamentally wrong:
>>
>>
>> Hi Mathias,
>>
>> No offense, but you arguments are fundamentally wrong too. Your
>> workflow is not everyone's workflow!
>>
>>>
>>> You simply don't do static checks as a after thought, at random times
>>> when
>>> sun, mars and moon are in proper constellation.
>>
>>
>> I don't see the problem, people are free to choose if, when and which
>> checks they fancy run.
>>
>>> Why? Because when running this checks occasionally too much cruft will
>>> have
>>> accumulated that it is worth and reasonable to fix those issues: Too big
>>> chunk of boring and still expensive work. Too big risk to introduce
>>> regressions.
>>
>>
>> Running clang-tidy is way slower than compiling code, a nightly check
>> might be enough (or not, again this is a personal choice), or you
>> could decide to run the checks systematically on pull requests because
>> you don't trust the authors (for whatever reason, inc the usual "oops,
>> forgot to do that", human do errors).
>
>> Sanity checks ran by clang-tidy can be of arbitrary complexity, and as
>> such can take really long time. You might not want to be slow down by
>> this while you're actively developing.
>
> Well, with clang-tidy being slow you just gave another reason to have a
> compiler plugin for this quick, very obvious tests. In my experience clazy
> has no measurable impact to compile time.

I never said that clazy was not useful, I was just saying that you
should use the right tool for the right job. Both tools are
complimentary, people have different use-cases.

>
>> If you go this way, then why don't you always run your applications in
>> profiling mode to make sure you don't introduce bottle-necks or memory
>> leaks "as-you-go"? Well we all know the answer: Because it is way too
>> slow.
>
>
> Besides clazy being blasting fast you are comparing apples with oranges. The
> issues clazy blames are plain Qt usage bugs. Just the same kind of issues
> the compiler reports for regular C++ already. Ideally the compilers would
> checks those issues out of the box already. Obviously they can't because Qt
> layers stuff on top of C++.

Effectively, I'm not sure we're talking about the same things here.
Maybe clazy plugin could be even use by Qtc clang code model if it's
that fast (I really like the "compile errors/warnings" as you type,
altho not perfect). I was talking about "deeper" checks, like the ones
listed in the "group of checks" table as per
http://clang.llvm.org/extra/clang-tidy/index.html#using-clang-tidy
They are really more than what clazy proposes (for now). And you
definitely don't want them to be run each time you build your app.

So, all in all, it looks to me that the clazy plugin is the way to go
for fast checks, and clang-tidy for the more thoughtfully ones. Hence
my message about being able to use these new checks both form the
compiler command and from an external tool such as clang-tidy. Deeper,
time-consuming, Qt-specific checks would be welcome as a new
clang-tidy check group.
The checks clang-tidy propose are not limited to "potential bugs", it
does cover as well coding guideline and styles and AFAIR Qt use custom
perl scripts for style and basic errors checking (might have changed
since last time i checked).

Cherry on the cake, with clang-tidy (actually a llvm feature used by
clang-tidy) is that it can generates the fixes as well, and even apply
them in one go. A feature which I believe is used by QtC to propose
you the "hot fix" accessible with Alt-Return (On Linux).

"clang-tidy -checks=* -list-checks" here gives me a list of 184 checks
(LLVM v3.8.0). Not all are useful and some of them are not always
applicable or sometimes give false positive, but it should give you a
fair idea of what does already exists in there.

Chris

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

Re: [Development] Qt API review with clazy

[Ch'Gans]

On 12 September 2016 at 21:13, Mathias Hasselmann
 wrote:
> Hello Chris,
[...]
> Besides clazy being blasting fast you are comparing apples with oranges. The
> issues clazy blames are plain Qt usage bugs. Just the same kind of issues
> the compiler reports for regular C++ already. Ideally the compilers would
> checks those issues out of the box already. Obviously they can't because Qt
> layers stuff on top of C++.

BTW, have you tried to use clazy by adding the flags in QtC C++ clang
model? (tools->options->C++->code model)
I have no clue if it is even doable, i'm just asking.

Chris

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

Re: [Development] Qt API review with clazy

[Milian Wolff]

On Montag, 12. September 2016 22:04:47 CEST Ch'Gans wrote:
> On 12 September 2016 at 21:13, Mathias Hasselmann
> 
>  wrote:
> > Hello Chris,
> 
> [...]
> 
> > Besides clazy being blasting fast you are comparing apples with oranges.
> > The issues clazy blames are plain Qt usage bugs. Just the same kind of
> > issues the compiler reports for regular C++ already. Ideally the
> > compilers would checks those issues out of the box already. Obviously
> > they can't because Qt layers stuff on top of C++.
> 
> BTW, have you tried to use clazy by adding the flags in QtC C++ clang
> model? (tools->options->C++->code model)
> I have no clue if it is even doable, i'm just asking.

It's possible. We did that in KDevelop. But it depends on a libclang patch 
that was not yet accepted upstream:

https://reviews.llvm.org/D15729

Cheers

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Maintainers: your action needed: Qt 5.6.2 change files mostly missing!

[Simon Hausmann]

Hi,


It should be noted that Qt3D has "preview" status in the Qt 5.6 branch. So I 
don't think anybody should rely on the content

of qt3d in the 5.6 branch and consequently look for a changelog :)



Simon


From: Development  on 
behalf of Alexander Blasche 
Sent: Monday, September 12, 2016 11:46:31 AM
To: Sean Harmer; Jani Heikkinen
Cc: development@qt-project.org
Subject: Re: [Development] Maintainers: your action needed: Qt 5.6.2 change 
files mostly missing!

Hi Sean,

> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Sean Harmer
> Sent: Monday, 12 September 2016 9:59

> Qt 3D doesn’t need one for 5.6.2.

If that's the case then please add a statement to the change log telling the 
reader that there were no noteworthy changes. To the Qt user there is no way to 
distinguish a missing change log due to no changes from a missing change log 
because we didn't write it (despite having potentially a lot).

In my opinion there are noteworthy changes in Qt3D. There are 2 bugs fixed and 
hover event related changes... Don't you think this is relevant?

--
Alex
___
Development mailing list
Development@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-creator] [FYI] on gerrit change retargeting requests

[Orgad Shaneh]

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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Maintainers: your action needed: Qt 5.6.2 change files mostly missing!

[Alexander Blasche]

Ok, I was not aware of TP status. In this case I stand corrected.

--
Alex


From: Simon Hausmann
Sent: Monday, 12 September 2016 1:25:16 PM
To: Alexander Blasche; Sean Harmer; Jani Heikkinen
Cc: development@qt-project.org
Subject: Re: [Development] Maintainers: your action needed: Qt 5.6.2 change 
files mostly missing!

Hi,


It should be noted that Qt3D has "preview" status in the Qt 5.6 branch. So I 
don't think anybody should rely on the content

of qt3d in the 5.6 branch and consequently look for a changelog :)



Simon


From: Development  on 
behalf of Alexander Blasche 
Sent: Monday, September 12, 2016 11:46:31 AM
To: Sean Harmer; Jani Heikkinen
Cc: development@qt-project.org
Subject: Re: [Development] Maintainers: your action needed: Qt 5.6.2 change 
files mostly missing!

Hi Sean,

> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Sean Harmer
> Sent: Monday, 12 September 2016 9:59

> Qt 3D doesn’t need one for 5.6.2.

If that's the case then please add a statement to the change log telling the 
reader that there were no noteworthy changes. To the Qt user there is no way to 
distinguish a missing change log due to no changes from a missing change log 
because we didn't write it (despite having potentially a lot).

In my opinion there are noteworthy changes in Qt3D. There are 2 bugs fixed and 
hover event related changes... Don't you think this is relevant?

--
Alex
___
Development mailing list
Development@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] Gerrit down

[Frederik Gladhorn]

Both gerrit and mailing lists should be running again.

It seems like there was a problem with DNS on the machine that runs the mail 
server and mailman. I don't know the exact details, but the machine has been 
fixed and also the backups have been tuned, so mails and gerrit should be 
rolling again.
There are still seven changes in a weird state, I'll clean these up now, but I 
don't want to risk creating a bigger mess, so it'll take a bit of time to 
fully understand which state they are in. Gerrit shows them in integrating 
state and the CI thinks they're done.

Happy hacking!
Frederik


On lørdag 10. september 2016 01.36.40 CEST Giuseppe D'Angelo wrote:
> Il 09/09/2016 17:48, Frederik Gladhorn ha scritto:
> > Since the problem is very likely something with the mail setup being
> > broken, we'll disable gerrit mails - so expect not to see any emails from
> > gerrit until this is fixed. Occasional mail might still make it, we'll
> > try giving mails a short timeout before dropping them.
> 
> By the way, this very mailing list seems to suffer from something, I've
> just received a bunch of messages sent today which were stuck somewhere,
> notice the gigantic gap in time:
> 
> [snip]
> 
> > Received: from mx.qt-project.org (mx.qt-project.org [193.209.87.4])
> > 
> > (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
> > (No client certificate requested)
> > by mail.kdab.com (Postfix) with ESMTPS id 26B8B28070C
> > for ; Sat, 10 Sep 2016 00:18:07 +0200 (CEST)
> > 
> > X-Original-To: development@qt-project.org
> > Delivered-To: development@qt-project.org
> > Received: by mx.qt-project.org (Postfix, from userid 1233)
> > 
> > id 7A7A550264; Sat, 10 Sep 2016 00:18:24 +0200 (CEST)
> > 
> > Received: from EUR01-VE1-obe.outbound.protection.outlook.com
> > 
> > (mail-ve1eur01on0100.outbound.protection.outlook.com [104.47.1.100])
> > by mx.qt-project.org (Postfix) with ESMTP id AA75D50262
> > for ; Sat, 10 Sep 2016 00:18:23 +0200 (CEST)
> > 
> > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> > 
> > d=qtcompany.onmicrosoft.com; s=selector1-qt-io;
> > h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
> > bh=mN6vAFQ72mV+/H1wStOxJTboKGXq95PRWd5/52UDCzA=;
> > 
> > b=SfGAI+ERzPwuKluQOanFfg8rqTcgBrRu5aFLxhRg9ThTegmFmjXLeSOYdQAuRzh02TWyaH4
> > 
> > y8HMcYqKuS/9vjsW9vUA4UMJWC9fap2j6YJYFlvOiQWVst++hKk3GZSrnLXvbW7pJj60K8ok+
> > CYBQc+ptL2DwfF4N5NOYouWR+t8=> 
> > Authentication-Results: spf=none (sender IP is )
> > 
> > smtp.mailfrom=frederik.gladh...@qt.io;
> > 
> > Received: from frederik-thinkcentre-m93p.localnet (185.55.107.82) by
> > 
> > AM5PR0201MB2404.eurprd02.prod.outlook.com (10.169.243.142) with
> > Microsoft SMTP Server (version=TLS1_0,
> > cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384)
> > id 15.1.609.9; Fri, 9 Sep 2016 15:48:04 +
> > 
> > From: Frederik Gladhorn 
> > To: 
> > Date: Fri, 9 Sep 2016 17:48:00 +0200
> 
> Cheers,


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

Re: [Development] QtCon 2016 session notes: Qt for macOS

[Edward Welbourne]

Morten Sorvig
> Session held friday september 2nd.

Notes transformed into a Wiki page:
https://wiki.qt.io/Qt_for_macOS_at_QtCon_2016

> We ran out of time and may have missed some topics and/or input - following 
> up on
> this email is possible.

Additions to the wiki page might be another way to approach some types of 
follow-up.

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Edward Welbourne]

For reference, I've turned Andrew's notes (see ur-ancestor post of this thread) 
into:
https://wiki.qt.io/Qt_build_systems_at_QtCon_2016

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

Re: [Development] Gerrit down

[Frederik Gladhorn]

On mandag 12. september 2016 14.03.36 CEST Frederik Gladhorn wrote:
> Both gerrit and mailing lists should be running again.
> 
> It seems like there was a problem with DNS on the machine that runs the mail
> server and mailman. I don't know the exact details, but the machine has
> been fixed and also the backups have been tuned, so mails and gerrit should
> be rolling again.
> There are still seven changes in a weird state, I'll clean these up now, but
> I don't want to risk creating a bigger mess, so it'll take a bit of time to
> fully understand which state they are in. Gerrit shows them in integrating
> state and the CI thinks they're done.

The offending changes have been "failed" now and should be ready to be 
restaged. Please let me know if you see anything still hanging for a day or 
longer.

Cheers,
Frederik

> 
> Happy hacking!
> Frederik
> 
> On lørdag 10. september 2016 01.36.40 CEST Giuseppe D'Angelo wrote:
> > Il 09/09/2016 17:48, Frederik Gladhorn ha scritto:
> > > Since the problem is very likely something with the mail setup being
> > > broken, we'll disable gerrit mails - so expect not to see any emails
> > > from
> > > gerrit until this is fixed. Occasional mail might still make it, we'll
> > > try giving mails a short timeout before dropping them.
> > 
> > By the way, this very mailing list seems to suffer from something, I've
> > just received a bunch of messages sent today which were stuck somewhere,
> > notice the gigantic gap in time:
> > 
> > [snip]
> > 
> > > Received: from mx.qt-project.org (mx.qt-project.org [193.209.87.4])
> > > 
> > >   (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
> > >   (No client certificate requested)
> > >   by mail.kdab.com (Postfix) with ESMTPS id 26B8B28070C
> > >   for ; Sat, 10 Sep 2016 00:18:07 +0200 
(CEST)
> > > 
> > > X-Original-To: development@qt-project.org
> > > Delivered-To: development@qt-project.org
> > > Received: by mx.qt-project.org (Postfix, from userid 1233)
> > > 
> > >   id 7A7A550264; Sat, 10 Sep 2016 00:18:24 +0200 (CEST)
> > > 
> > > Received: from EUR01-VE1-obe.outbound.protection.outlook.com
> > > 
> > >   (mail-ve1eur01on0100.outbound.protection.outlook.com [104.47.1.100])
> > >   by mx.qt-project.org (Postfix) with ESMTP id AA75D50262
> > >   for ; Sat, 10 Sep 2016 00:18:23 +0200
> > >   (CEST)
> > > 
> > > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> > > 
> > >   d=qtcompany.onmicrosoft.com; s=selector1-qt-io;
> > >   h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
> > >   bh=mN6vAFQ72mV+/H1wStOxJTboKGXq95PRWd5/52UDCzA=;
> > >   b=SfGAI
+ERzPwuKluQOanFfg8rqTcgBrRu5aFLxhRg9ThTegmFmjXLeSOYdQAuRzh02TWya
> > >   H4
> > >   y8HMcYqKuS/9vjsW9vUA4UMJWC9fap2j6YJYFlvOiQWVst+
+hKk3GZSrnLXvbW7pJj60K8o
> > >   k+
> > >   CYBQc+ptL2DwfF4N5NOYouWR+t8=>
> > > 
> > > Authentication-Results: spf=none (sender IP is )
> > > 
> > >   smtp.mailfrom=frederik.gladh...@qt.io;
> > > 
> > > Received: from frederik-thinkcentre-m93p.localnet (185.55.107.82) by
> > > 
> > >   AM5PR0201MB2404.eurprd02.prod.outlook.com (10.169.243.142) with
> > >   Microsoft SMTP Server (version=TLS1_0,
> > >   cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384)
> > >   id 15.1.609.9; Fri, 9 Sep 2016 15:48:04 +
> > > 
> > > From: Frederik Gladhorn 
> > > To: 
> > > Date: Fri, 9 Sep 2016 17:48:00 +0200
> > 
> > Cheers,
> 
> ___
> 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] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly via Development]

Hi Edward,


You copied the line:


(Stephen) "In reality, rewriting Qt's build system in CMake will 
actually be a PITA, and will require changes to CMake to make everything 
better"



That was a stenography error. Can you remove it?

Thanks,


On 12/09/16 16:08, Edward Welbourne wrote:

For reference, I've turned Andrew's notes (see ur-ancestor post of this thread) 
into:
https://wiki.qt.io/Qt_build_systems_at_QtCon_2016

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


--
Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany
Management Board: Gerhard Behles, Jan Bohl
Chair of the Supervisory Board: Uwe Struck
Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838

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

Re: [Development] Qt 5.8 API review (vs 5.7.0)

[Sune Vuorela]

On 2016-09-09, Edward Welbourne  wrote:
> https://codereview.qt-project.org/170634 -- qtbase

Added some comments. Though didn't detailed read all template magic.
One enum have reordered some members. This is likely an issue.

> https://codereview.qt-project.org/170635 -- qtdeclarative

Kind of looks ok to me from a BC standpoint. 

> https://codereview.qt-project.org/170637 -- qtmultimedia

OK. Single added enum and single added function.

> https://codereview.qt-project.org/170638 -- qttools

How much of this is actually changes in installed headers, and how much
is just internal stuff ?


> https://codereview.qt-project.org/170647 -- qtwebengine

How much of this is external api, and how much is internal ?
Comment on one set of the api provided.

/Sune

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

[Development] Proposal: JSON single value documents

[Matt Newell]

I would like to propose an addition to the QtJson api to allow single value 
json documents (SVJ for brevity).

There have been various discussions regarding whether or not a SVJ is a valid 
json document, with more recent rfc's saying yes.   Here is one discussion 
which also has links to others:
http://stackoverflow.com/questions/18419428/what-is-the-minimum-valid-json

Regardless of whether a SJV is a valid document, the fact remains that to be 
fully interoperable with many other existing projects Qt should support them.  
My initial motivation is full support for the json/jsonb column type in 
Postgresql.

My proposed change would add the following methods to QJsonDocument:
  bool isValue() const;
  QJsonValue value() const;
  void setValue(const QJsonValue &value);

The only backwards compatibility issue that i can think of would be that 
fromVariant and fromJson will now return valid values documents.  For that 
reason it may be needed to provide new fromVariant and fromJson overloads.

I have figured out an elegant way to handle SVJ's without changing qt's binary 
format.  Because the binary format in it's current form can only hold a top-
level object or array, and because any old code will not be able to load a 
binary document containing a single value, a version bump is required.  My 
idea is to have a SVJ stored as a single element json array containing the 
value, but have the version set to 2.  This results in no actual changes to 
the binary format at all.  Any non-SVJ document continues to use version 1 
retaining full backwards compatibility for any document that was valid 
previously.

Attached is a preliminary patch that compiles, passes the existing tests in 
tests/auto/corelib/json, and adds a few new tests to exercise the new 
functionality.

If it's determined that this is a reasonable approach I will work on extending 
the tests and updating the documentation.

Thanks,
Matt Newell
diff --git a/src/corelib/json/qjson.cpp b/src/corelib/json/qjson.cpp
index 4b98ef0..fcf9b20 100644
--- a/src/corelib/json/qjson.cpp
+++ b/src/corelib/json/qjson.cpp
@@ -81,7 +81,7 @@ void Data::compact()
 h->version = 1;
 Base *b = h->root();
 b->size = size;
-b->is_object = header->root()->is_object;
+b->is_object = base->is_object;
 b->length = base->length;
 b->tableOffset = reserve + sizeof(Array);
 
@@ -131,7 +131,7 @@ void Data::compact()
 
 bool Data::valid() const
 {
-if (header->tag != QJsonDocument::BinaryFormatTag || header->version != 1u)
+if (header->tag != QJsonDocument::BinaryFormatTag || (header->version != 1u && header->version != 2u))
 return false;
 
 bool res = false;
diff --git a/src/corelib/json/qjsondocument.cpp b/src/corelib/json/qjsondocument.cpp
index 6eca54b..4873280 100644
--- a/src/corelib/json/qjsondocument.cpp
+++ b/src/corelib/json/qjsondocument.cpp
@@ -236,7 +236,7 @@ QJsonDocument QJsonDocument::fromBinaryData(const QByteArray &data, DataValidati
 memcpy(&root, data.constData() + sizeof(QJsonPrivate::Header), sizeof(QJsonPrivate::Base));
 
 // do basic checks here, so we don't try to allocate more memory than we can.
-if (h.tag != QJsonDocument::BinaryFormatTag || h.version != 1u ||
+if (h.tag != QJsonDocument::BinaryFormatTag || (h.version != 1u && h.version != 2u) ||
 sizeof(QJsonPrivate::Header) + root.size > (uint)data.size())
 return QJsonDocument();
 
@@ -274,6 +274,10 @@ QJsonDocument QJsonDocument::fromVariant(const QVariant &variant)
 doc.setArray(QJsonArray::fromVariantList(variant.toList()));
 } else if (variant.type() == QVariant::StringList) {
 doc.setArray(QJsonArray::fromStringList(variant.toStringList()));
+} else {
+QJsonValue v = QJsonValue::fromVariant(variant);
+if (!v.isNull())
+doc.setValue(v);
 }
 return doc;
 }
@@ -291,9 +295,12 @@ QVariant QJsonDocument::toVariant() const
 if (!d)
 return QVariant();
 
-if (d->header->root()->isArray())
-return QJsonArray(d, static_cast(d->header->root())).toVariantList();
-else
+if (d->header->root()->isArray()) {
+QJsonArray a(d, static_cast(d->header->root()));
+if (d->header->version == 2u && a.size() == 1u)
+return a[0].toVariant();
+return a.toVariantList();
+} else
 return QJsonObject(d, static_cast(d->header->root())).toVariantMap();
 }
 
@@ -347,9 +354,13 @@ QByteArray QJsonDocument::toJson(JsonFormat format) const
 
 QByteArray json;
 
-if (d->header->root()->isArray())
-QJsonPrivate::Writer::arrayToJson(static_cast(d->header->root()), json, 0, (format == Compact));
-else
+if (d->header->root()->isArray()) {
+QJsonPrivate::Array *a = static_cast(d->header->root());
+if (d->header->version == 1u)
+QJsonPrivate::Writer::arrayToJson(a, json, 0, (format == Compact));
+else if (d->header->version == 2u && a->length == 1u)
+   

Re: [Development] Proposal: JSON single value documents

[Thiago Macieira]

On segunda-feira, 12 de setembro de 2016 14:40:19 PDT Matt Newell wrote:
> My proposed change would add the following methods to QJsonDocument:
>   bool isValue() const;

I'm not sure it. Arrays and objects are JSON values, so this function would 
return a constant true, for all values, except when isEmpty() is true. Maybe 
we want isValid() instead.

These are ok:

>   QJsonValue value() const;
>   void setValue(const QJsonValue &value);

That would also mean the object()/setObject() and array()/setArray() pairs 
become convenience functions around value().to{Array,Object}() and setValue() 
with type constraining.

> The only backwards compatibility issue that i can think of would be that
> fromVariant and fromJson will now return valid values documents.  For that
> reason it may be needed to provide new fromVariant and fromJson overloads.

Indeed.

> I have figured out an elegant way to handle SVJ's without changing qt's
> binary format.  Because the binary format in it's current form can only
> hold a top- level object or array, and because any old code will not be
> able to load a binary document containing a single value, a version bump is
> required.  My idea is to have a SVJ stored as a single element json array
> containing the value, but have the version set to 2.  This results in no
> actual changes to the binary format at all.  Any non-SVJ document continues
> to use version 1 retaining full backwards compatibility for any document
> that was valid previously.

Lars to comment.

> Attached is a preliminary patch that compiles, passes the existing tests in
> tests/auto/corelib/json, and adds a few new tests to exercise the new
> functionality.

And way too big (> 10 lines), so no one interested in this feature should open 
your patch and read it: it could become a problem if someone were to later 
implement it. Instead, please upload it to Gerrit so we can get your patch 
with the Contribution Licence Agreement.

> If it's determined that this is a reasonable approach I will work on
> extending the tests and updating the documentation.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
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] [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