From filippocucchetto at gmail.com  Fri Jul  1 09:38:11 2016
From: filippocucchetto at gmail.com (Filippo Cucchetto)
Date: Fri, 1 Jul 2016 09:38:11 +0200
Subject: [Development] Input events handling ideas and feedback
In-Reply-To: <22773438-3EA5-4FD4-A8D6-8E788F5FF9E6@qt.io>
References: <CA+zKVJd1O6mdx=nvuXKT+VNZwiidskqfzUVY7d5tS2hvj7LmjA@mail.gmail.com>
	<073A4C5F-6278-4354-8F01-3F5E8C68230E@qt.io>
	<CA+zKVJdmZYc+MBEFUvB_BBkge5Vt6Tkbn+xNH+f-5LAB7p57fw@mail.gmail.com>
	<22773438-3EA5-4FD4-A8D6-8E788F5FF9E6@qt.io>
Message-ID: <CA+zKVJdDncCK7a4QhxTN0=uZcVZZJ-S2KQdXH5TqtEDF+Bia8w@mail.gmail.com>

> if we had time to filter out all the good ideas from all the frameworks, we’d have a better chance of making ours the best.  ;-)
Agreed :)

> Well we advertise that it’s a declarative language.  We could make it even more that way, even if it’s not strictly necessary.  Would it be more elegant?
Yes absolutely

> Well in my experience, handling clicks inside delegates works fine
Yes it works fine in the sense that you receive the event in the
delegate MouseArea. But if you received the click event that means
that you accepted the press event (given that the click is a composed
event) and this in turn imply that a view child MouseArea doesn't
receive the press event. This breaks selection in TreeViews or
TableViews (probably because the do not monitor childMouseEvents) and
in the delegate MouseArea there's no way to receive a click event
without "stealing" the press event.

> I think we could say that QQuickWindowPrivate::deliverInitialMousePressEvent() does tunnelling: it starts with the root and goes recursively _down_ through the children until the event is accepted (Handled in WPF terminology).  But for each child recursively, it calls QQuickWindow::sendEvent(), which in the case of mouse events calls sendFilteredMouseEvent(item->parentItem(), item, e, &hasFiltered).  And that goes recursively _up_ the parent hierarchy, calling childMouseEventFilter on any ancestor Item which has the filtersChildMouseEvents flag set.  So it’s kindof like bubbling, but it happens before the real event handling in the leaf Item, rather than afterwards. And it happens multiple times per “target", which would be inefficient and redundant, so QSet<QQuickItem *> *hasFiltered is used to keep track of the items that have already had their chance at filtering.  (Yeah, a fresh new QSet gets populated for every event.  But it’s not the only case of that, either.)  So that’s already rather like bubbling, but I'd worry about changing the order: WPF gives the “source” a chance to handle the event first, then the bubbling happens after; whereas QtQuick does sendFilteredMouseEvent first and then lets the Item have the event.  That might be a big change to make.  But then again, by the time the ListView’s drag threshold is exceeded, the MouseArea inside the delegate has already been the grabber for a while; so the grab must be canceled, and that involves sending another event to tell it that it was canceled.  So if we did tunnelling followed by bubbling, we’d need to keep doing that, and maybe it would be OK.

I think that the childMouseEventFilter way of being called it's weird.
I would expect that if A and B are two nodes where B is higher in Z
stack, A::childMouseEventFilter should be called before B. Instead
from what you explain and by looking at the code it seems that the
deliverInitialMousePressEvent() first goes down the hierarchy and then
calls childMouseEventFilter from child to root (so
B::childMouseEventFilter will be called before A). Given that i think
that childMouseEventFilter it's basically tunneling in the WPF way (so
an handle where you can receive an event before it gets delivered to a
child).

> Then under WPF Input Events there is a tree of elements.  Based on the explanation, I guess it does start with the root element and does tunnelling, but is that the first step or do they already know by magic that leaf #2 “raised” the event?  How did they skip the step of tunnelling to leaf #1?

In pseudocode (and please skip the naive implementation) i think that
they basically do

let mouseEvent
let a = x in allItems() where if x.enabled and x.contains(mouseEvent.pos())
let b = a.sortByGlobalZOrder() // So if x is before y in b than x is
painted over y
// Here we know that b[0] will raise the event
for (x in b.reverse())
  if (x.onPreviewMouseEvent(mouseEvent)
    return
for (x in b)
  if (x.handleAlreadyAcceptedEvents or not mouseEvent.accepted)
     x.onMouseEvent(mouseEvent)

What i see it's that have the concepted of "raise" and "handle". So in
the example they first find the item that "raise" the event After that
by doing tunneling and later bubbling they will find the event that
accept it. Furthermore during the calls to handlers they propagate
some information about the previous item who has been called by doing
bubbling/tunneling and who raised the event.

> Aha… so bubbling doesn’t always occur:
For what i see bubbling always happen if the event has not been pre
filtered by tunneling. In this case the event bubble up until it gets
accepted. After being accepted the bubbling continue iff there'are
items who what to handle "AlreadyAccepted" events.



-- 
Filippo Cucchetto


From kollix at aon.at  Fri Jul  1 13:26:17 2016
From: kollix at aon.at (Martin Koller)
Date: Fri, 01 Jul 2016 13:26:17 +0200
Subject: [Development] dev branch compile fails module-qtdatavis3d
Message-ID: <5970992.y8V6gHAJt6@lapi.koller>

Hi,

trying to build module-qtdatavis3d on dev branch (with a namespace) fails here with:

make[3]: Entering directory '/home/PACKAGES/qt/qt-repo/qt5/qtdeclarative/tools/qml'
g++ -Wl,--gc-sections -Wl,-rpath,/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib -o /home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/qml .obj/main.o .obj/qrc_qml.o .obj/moc_conf.o   -L/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib -lQt5QmlWinCC_OA -lQt5NetworkWinCC_OA -lQt5WidgetsWinCC_OA -lQt5GuiWinCC_OA -lQt5CoreWinCC_OA -lGL -lpthread
/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib/libQt5GuiWinCC_OA.so: undefined reference to `qt_version_tag'
collect2: error: ld returned 1 exit status
Makefile:67: recipe for target '/home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/qml' failed

any idea why this fails ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\                        - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at


From thiago.macieira at intel.com  Fri Jul  1 17:39:07 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 01 Jul 2016 08:39:07 -0700
Subject: [Development] dev branch compile fails module-qtdatavis3d
In-Reply-To: <5970992.y8V6gHAJt6@lapi.koller>
References: <5970992.y8V6gHAJt6@lapi.koller>
Message-ID: <3777990.ppmVsU8688@tjmaciei-mobl1>

On sexta-feira, 1 de julho de 2016 13:26:17 PDT Martin Koller wrote:
> g++ -Wl,--gc-sections -Wl,-rpath,/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib -o
> /home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/qml .obj/main.o .obj/qrc_qml.o
> .obj/moc_conf.o   -L/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib
> -lQt5QmlWinCC_OA -lQt5NetworkWinCC_OA -lQt5WidgetsWinCC_OA -lQt5GuiWinCC_OA
> -lQt5CoreWinCC_OA -lGL -lpthread

> /home/PACKAGES/qt/qt-repo/qt5/qtbase/lib/libQt5GuiWinCC_OA.so: undefined
> reference to `qt_version_tag'

This error indicates your Qt headers do not match the QtCore library.

Did you by any chance also build with a namespace?

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



From thiago.macieira at intel.com  Fri Jul  1 20:36:56 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 01 Jul 2016 11:36:56 -0700
Subject: [Development] Use of Standard Library containers in Qt source code
Message-ID: <6461895.FPZQEgjcFK@tjmaciei-mobl1>

Premises not under discussion:

	Qt source code is product and meant to be read by our users
	Qt source code must be clean and readable

The above is not up for debate.

For some time now, we've had a flurry of changes to Qt source code that uses 
the Standard Library's containers and algorithms, in the name of performance 
and often code size gains.

I'm not disputing that there is a gain. But I am wondering about the trade-off 
we're making with regards to readability. For example, I was just reviewing 
this code:

    if (d->currentReadChannel >= d->readHeaders.size()
        || d->readHeaders[d->currentReadChannel].empty()) {
        Q_ASSERT(d->buffer.isEmpty());

The use of the Standard Library member "empty" is highly confusing at first 
sight because it does not follow the Qt naming guidelines. It's even more 
confusing because the next line has "isEmpty". When I read this code, I had to 
wonder if that "empty" was a verb in the imperative, meaning the author was 
trying to remove all elements from the container. 

I had to look up the definition of readHeaders in the review and note that it 
was a std::deque, not a Qt container.

What do we do?

Option 1:
Not use Standard Library containers, just use the Qt containers as they exist.

Option 2:
Create new Qt containers to have the same complexity as Standard Library 
containers, but following the Qt naming conventions. Possibly with implicit 
sharing.

Option 3:
Create Qt API wrappers for those containers like std::deque, adding only a few 
inline functions to match the Qt-style API where the Standard Library API 
deviates. Examples are:
	empty		->	isEmpty
	push_back	->	append
	front		-> 	first
	pop_front	->	takeFirst
	cbegin		->	constBegin
	cfind		->	constFind

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



From thiago.macieira at intel.com  Fri Jul  1 21:34:15 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 01 Jul 2016 12:34:15 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
Message-ID: <2133524.ekmAkN6kfG@tjmaciei-mobl1>

On sexta-feira, 1 de julho de 2016 11:36:56 PDT Thiago Macieira wrote:
> Option 1:
> Not use Standard Library containers, just use the Qt containers as they
> exist.
> 
> Option 2:
> Create new Qt containers to have the same complexity as Standard Library 
> containers, but following the Qt naming conventions. Possibly with implicit 
> sharing.
> 
> Option 3:
> Create Qt API wrappers for those containers like std::deque, adding only a
> few  inline functions to match the Qt-style API where the Standard Library
> API deviates. Examples are:
>         empty           ->      isEmpty
>         push_back       ->      append
>         front           ->      first
>         pop_front       ->      takeFirst
>         cbegin          ->      constBegin
>         cfind           ->      constFind

Of course, Option 4:
Continue to allow Standard Library containers in internal code (no API or ABI 
constraining) where there's a clear gain in performance and/or size.

Option 5:
Allow Standard Library containers in internal code even if performance or code 
size gains are not appreciable or have not been measured.

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



From kollix at aon.at  Fri Jul  1 21:36:21 2016
From: kollix at aon.at (Martin Koller)
Date: Fri, 01 Jul 2016 21:36:21 +0200
Subject: [Development] dev branch compile fails module-qtdatavis3d
In-Reply-To: <3777990.ppmVsU8688@tjmaciei-mobl1>
References: <5970992.y8V6gHAJt6@lapi.koller>
	<3777990.ppmVsU8688@tjmaciei-mobl1>
Message-ID: <1752970.1ZvLjpp7pR@lapi.koller>

On Friday 01 July 2016 08:39:07 Thiago Macieira wrote:
> On sexta-feira, 1 de julho de 2016 13:26:17 PDT Martin Koller wrote:
> > g++ -Wl,--gc-sections -Wl,-rpath,/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib -o
> > /home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/qml .obj/main.o .obj/qrc_qml.o
> > .obj/moc_conf.o   -L/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib
> > -lQt5QmlWinCC_OA -lQt5NetworkWinCC_OA -lQt5WidgetsWinCC_OA -lQt5GuiWinCC_OA
> > -lQt5CoreWinCC_OA -lGL -lpthread
> 
> > /home/PACKAGES/qt/qt-repo/qt5/qtbase/lib/libQt5GuiWinCC_OA.so: undefined
> > reference to `qt_version_tag'
> 
> This error indicates your Qt headers do not match the QtCore library.
> 
> Did you by any chance also build with a namespace?

yes, this is what I said in my first mail.

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\                        - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at


From thiago.macieira at intel.com  Fri Jul  1 21:45:07 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 01 Jul 2016 12:45:07 -0700
Subject: [Development] dev branch compile fails module-qtdatavis3d
In-Reply-To: <1752970.1ZvLjpp7pR@lapi.koller>
References: <5970992.y8V6gHAJt6@lapi.koller>
	<3777990.ppmVsU8688@tjmaciei-mobl1>
	<1752970.1ZvLjpp7pR@lapi.koller>
Message-ID: <1690774.AWVGoT3XG7@tjmaciei-mobl1>

On sexta-feira, 1 de julho de 2016 21:36:21 PDT Martin Koller wrote:
> On Friday 01 July 2016 08:39:07 Thiago Macieira wrote:
> > On sexta-feira, 1 de julho de 2016 13:26:17 PDT Martin Koller wrote:
> > > g++ -Wl,--gc-sections
> > > -Wl,-rpath,/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib -o
> > > /home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/qml .obj/main.o .obj/qrc_qml.o
> > > .obj/moc_conf.o   -L/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib
> > > -lQt5QmlWinCC_OA -lQt5NetworkWinCC_OA -lQt5WidgetsWinCC_OA
> > > -lQt5GuiWinCC_OA
> > > -lQt5CoreWinCC_OA -lGL -lpthread
> > > 
> > > /home/PACKAGES/qt/qt-repo/qt5/qtbase/lib/libQt5GuiWinCC_OA.so: undefined
> > > reference to `qt_version_tag'
> > 
> > This error indicates your Qt headers do not match the QtCore library.
> > 
> > Did you by any chance also build with a namespace?
> 
> yes, this is what I said in my first mail.

"qt_version_tag" is the name of the tag for unnamespaced Qt. If you do 
	readelf -s libQt5CoreWinCC_OA.so.5

You'll probably see "qt_version_tag_X" where X is your namespace, some with 
extra suffixes for previous Qt versions and one with @@. Can you confirm that?

Can you check if the build of this application had QT_NAMESPACE defined? Please 
paste the command-line that was used to compile main.cpp.

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



From annulen at yandex.ru  Fri Jul  1 21:52:24 2016
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 01 Jul 2016 22:52:24 +0300
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
Message-ID: <5159741467402744@web6j.yandex.ru>



01.07.2016, 21:37, "Thiago Macieira" <thiago.macieira at intel.com>:
> Premises not under discussion:
>
>         Qt source code is product and meant to be read by our users
>         Qt source code must be clean and readable
>
> The above is not up for debate.
>
> For some time now, we've had a flurry of changes to Qt source code that uses
> the Standard Library's containers and algorithms, in the name of performance
> and often code size gains.
>
> I'm not disputing that there is a gain. But I am wondering about the trade-off
> we're making with regards to readability. For example, I was just reviewing
> this code:
>
>     if (d->currentReadChannel >= d->readHeaders.size()
>         || d->readHeaders[d->currentReadChannel].empty()) {
>         Q_ASSERT(d->buffer.isEmpty());
>
> The use of the Standard Library member "empty" is highly confusing at first
> sight because it does not follow the Qt naming guidelines. It's even more
> confusing because the next line has "isEmpty". When I read this code, I had to
> wonder if that "empty" was a verb in the imperative, meaning the author was
> trying to remove all elements from the container.
>
> I had to look up the definition of readHeaders in the review and note that it
> was a std::deque, not a Qt container.

STL was standardized 18 years ago, I think it should be enough to get used to empty().

>
> What do we do?
>
> Option 1:
> Not use Standard Library containers, just use the Qt containers as they exist.
>
> Option 2:
> Create new Qt containers to have the same complexity as Standard Library
> containers, but following the Qt naming conventions. Possibly with implicit
> sharing.
>
> Option 3:
> Create Qt API wrappers for those containers like std::deque, adding only a few
> inline functions to match the Qt-style API where the Standard Library API
> deviates. Examples are:
>         empty -> isEmpty
>         push_back -> append
>         front -> first
>         pop_front -> takeFirst
>         cbegin -> constBegin
>         cfind -> constFind
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From thiago.macieira at intel.com  Fri Jul  1 22:05:45 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 01 Jul 2016 13:05:45 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <5159741467402744@web6j.yandex.ru>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<5159741467402744@web6j.yandex.ru>
Message-ID: <122393150.dApz54YNzL@tjmaciei-mobl1>

On sexta-feira, 1 de julho de 2016 22:52:24 PDT Konstantin Tokarev wrote:
> > I had to look up the definition of readHeaders in the review and note that
> > it was a std::deque, not a Qt container.
> 
> STL was standardized 18 years ago, I think it should be enough to get used
> to empty().

Qt API conventions predate the Standard Library standardisation. Qt's style 
exists because -- quite by definition -- Qt developers think their style is 
better. Moreover, Qt is recognised for having a nice, easy-to-learn API, 
whereas the C++ Standard Library meets quite often the exact opposite reaction 
(yes, anecdotal evidence).

More to the point, Qt developers don't have to know the Standard Library. *I* 
don't and I don't have time or interest in learning it. You will always see me 
write a for-loop to fill something rather than use std::fill.

Qt users don't have to learn it either. If they read the Qt source code, they 
should understand it. They might do that because they were debugging their 
application and stepped into Qt to find out what's happening.

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



From giuseppe.dangelo at kdab.com  Fri Jul  1 22:13:42 2016
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Fri, 1 Jul 2016 22:13:42 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <2133524.ekmAkN6kfG@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<2133524.ekmAkN6kfG@tjmaciei-mobl1>
Message-ID: <5776CEF6.9020603@kdab.com>

Howdy,

Il 01/07/2016 21:34, Thiago Macieira ha scritto:
> On sexta-feira, 1 de julho de 2016 11:36:56 PDT Thiago Macieira wrote:
>> Option 1:
>> Not use Standard Library containers, just use the Qt containers as they
>> exist.

However this is an anti-goal. As you stated, STL containers usage inside 
Qt is increasing for very good reasons. In the case in question, there 
isn't even a Qt equivalent for std::deque, and I don't see one coming 
anytime soon. (And even so, is it really going to outperform a container 
which has been around, studied, profiled, optimized, instrumented, for 
15+ years?)

>> Option 2:
>> Create new Qt containers to have the same complexity as Standard Library
>> containers, but following the Qt naming conventions. Possibly with implicit
>> sharing.

Again, also this looks like a massive anti-goal. I don't think we should 
invest any resource in this massive effort that reinvents the wheel, 
just for the sake of renaming a few functions.

(... not to mention that is extremely likely that we will always lag 
behind the current Standard and perform worse than any other STL 
implementation under any possible benchmark.

Even today: where is QList::push_back(T&&)? Where are our emplacement 
functions and their try versions? Where are our exception guarantees?)

>>
>> Option 3:
>> Create Qt API wrappers for those containers like std::deque, adding only a
>> few  inline functions to match the Qt-style API where the Standard Library
>> API deviates. Examples are:
>>          empty           ->      isEmpty
>>          push_back       ->      append
>>          front           ->      first
>>          pop_front       ->      takeFirst
>>          cbegin          ->      constBegin
>>          cfind           ->      constFind
>
> Of course, Option 4:
> Continue to allow Standard Library containers in internal code (no API or ABI
> constraining) where there's a clear gain in performance and/or size.

3 and 4 actually don't conflict, do they? If we subclass STL containers 
(say, in a QtStl namespace) and add those inline functions we would 
still be using them in the end. But before going this way, is it 
possible to estimate the amount of work to get this in place?

>
> Option 5:
> Allow Standard Library containers in internal code even if performance or code
> size gains are not appreciable or have not been measured.

Which again seems like a sensible thing to do in general, unless there 
are documented cases in which Qt containers significantly outperform STL 
ones (apart from implicit sharing).

IIRC, when there was the big thread about whether allowing STL 
containers or not in Qt implementation, people did such benchmarks and 
the results were always in favour of STL. Can anyone find the relative 
links...?

My 2 cents,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160701/465658fb/attachment.bin>

From mwoehlke.floss at gmail.com  Fri Jul  1 22:25:14 2016
From: mwoehlke.floss at gmail.com (Matthew Woehlke)
Date: Fri, 01 Jul 2016 16:25:14 -0400
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <5776CEF6.9020603@kdab.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>	<2133524.ekmAkN6kfG@tjmaciei-mobl1>
	<5776CEF6.9020603@kdab.com>
Message-ID: <nl6jja$cr3$1@ger.gmane.org>

On 2016-07-01 16:13, Giuseppe D'Angelo wrote:
> Even today: where is QList::push_back(T&&)? Where are our emplacement
> functions and their try versions? Where are our exception guarantees?)

...what's an exception? ;-) Never heard of those in Qt...

-- 
Matthew



From rafael.roquetto at kdab.com  Fri Jul  1 23:31:17 2016
From: rafael.roquetto at kdab.com (Rafael Roquetto)
Date: Fri, 1 Jul 2016 18:31:17 -0300
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <122393150.dApz54YNzL@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<5159741467402744@web6j.yandex.ru>
	<122393150.dApz54YNzL@tjmaciei-mobl1>
Message-ID: <20160701213115.GA5075@orion>

On Fri, Jul 01, 2016 at 01:05:45PM -0700, Thiago Macieira wrote:
> On sexta-feira, 1 de julho de 2016 22:52:24 PDT Konstantin Tokarev wrote:
> > > I had to look up the definition of readHeaders in the review and note that
> > > it was a std::deque, not a Qt container.
> > 
> > STL was standardized 18 years ago, I think it should be enough to get used
> > to empty().
> 
> Qt API conventions predate the Standard Library standardisation. Qt's style 
> exists because -- quite by definition -- Qt developers think their style is 
> better. Moreover, Qt is recognised for having a nice, easy-to-learn API, 
> whereas the C++ Standard Library meets quite often the exact opposite reaction 
> (yes, anecdotal evidence).

I second this. Qt API is highly praised, for a good reason. It is one of the
big assets of Qt. IMHO the compromise of subclassing STL stuff inside the
QtStl namespace seems like a good deal - it may require some effort, but we
get to keep a clean API. I would even go as far as saying this is better than
simply allowing unrestricted STL code into Qt source code, because unless we
rename (ruin) some method signatures in the Qt API, we would end up with the sort
of inconsistent source code demonstrated by Thiago's example, which I judge to
be the worst-case scenario.

Of course, all this assumes the introduction of a QtStl namespace to be a
feasible task. Whether it really is I cannot say.


-- 
Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3599 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160701/ab04145c/attachment.bin>

From thiago.macieira at intel.com  Fri Jul  1 23:56:36 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 01 Jul 2016 14:56:36 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <5776CEF6.9020603@kdab.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<2133524.ekmAkN6kfG@tjmaciei-mobl1> <5776CEF6.9020603@kdab.com>
Message-ID: <3399679.28OPHdOIhQ@tjmaciei-mobl1>

On sexta-feira, 1 de julho de 2016 22:13:42 PDT Giuseppe D'Angelo wrote:
> Even today: where is QList::push_back(T&&)? Where are our emplacement
> functions and their try versions? Where are our exception guarantees?)

We don't care about exceptions, so we won't be adding those.

As for the move-versions, since we can't take move-only types in our 
containers due to the implicit sharing, does it really make a difference if we 
have them or not?

> >> Option 3:
> >> Create Qt API wrappers for those containers like std::deque, adding only
> >> a
> >> few  inline functions to match the Qt-style API where the Standard
> >> Library
> >> 
> >> API deviates. Examples are:
> >>          empty           ->      isEmpty
> >>          push_back       ->      append
> >>          front           ->      first
> >>          pop_front       ->      takeFirst
> >>          cbegin          ->      constBegin
> >>          cfind           ->      constFind
> > 
> > Of course, Option 4:
> > Continue to allow Standard Library containers in internal code (no API or
> > ABI constraining) where there's a clear gain in performance and/or size.
> 3 and 4 actually don't conflict, do they? If we subclass STL containers
> (say, in a QtStl namespace) and add those inline functions we would
> still be using them in the end. But before going this way, is it
> possible to estimate the amount of work to get this in place?

The difference is the API used elsewhere in our code.

The amount of work should be minimal. There's just a handful of functions that 
need different names, plus two more like takeFirst and takeLast that do two 
things in one.

> > Option 5:
> > Allow Standard Library containers in internal code even if performance or
> > code size gains are not appreciable or have not been measured.
> 
> Which again seems like a sensible thing to do in general, unless there
> are documented cases in which Qt containers significantly outperform STL
> ones (apart from implicit sharing).

I would prefer the opposite: use non-Qt only if that is better than the Qt 
equivalent. If you can't prove it or if it's too small, it's not worth the 
difference in readability that it creates.

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



From thiago.macieira at intel.com  Fri Jul  1 23:58:04 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 01 Jul 2016 14:58:04 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <20160701213115.GA5075@orion>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<122393150.dApz54YNzL@tjmaciei-mobl1> <20160701213115.GA5075@orion>
Message-ID: <2453627.h6joPLscdv@tjmaciei-mobl1>

On sexta-feira, 1 de julho de 2016 18:31:17 PDT Rafael Roquetto wrote:
> Of course, all this assumes the introduction of a QtStl namespace to be a
> feasible task. Whether it really is I cannot say.

I'd say we start with it in a private header, add classes to it as needed. If 
we're happy with it, then we can consider making it public, later.

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



From samuel.gaist at edeltech.ch  Sat Jul  2 01:11:28 2016
From: samuel.gaist at edeltech.ch (Samuel Gaist)
Date: Sat, 2 Jul 2016 01:11:28 +0200
Subject: [Development] New configuration system
In-Reply-To: <4D7485AB-6F17-49F7-B5A6-DAA776FE613A@qt.io>
References: <4D7485AB-6F17-49F7-B5A6-DAA776FE613A@qt.io>
Message-ID: <67346AF5-ACB5-465A-8DAC-354C9E51754C@edeltech.ch>


On 23 juin 2016, at 09:29, Lars Knoll <Lars.Knoll at qt.io> wrote:

> Hi,
> 
> As some of you might know, I’ve been working for some time now on developing a new configuration system for Qt. As the first large change went in yesterday evening, I guess it’s time I describe it a little, and also tell you a bit about what’s still coming.
> 
> The goal of the new system is twofold. First of all, we are seeing a large need, especially with our embedded users, to customise how Qt is being built. Many of them have size restrictions ore rather hard testing requirements, where being able to limit the functionality available in Qt is extremely helpful. We had such a system (see src/corelib/global/qfeatures.txt) before, but it was disconnected from the configure script, wasn’t really maintained since Qt 4 times, and had quite many limitations that I hope to solve with the new system.
> 
> Secondly, we have had to deal for a long time with two different configuration systems. We had a monster of a shell script for unix, and an Qt based executable on Windows. Changes to Qt often required changing both, and it was very easy to sneak subtle errors in. Maintainability of the old system was in general very poor.
> 
> So with that comes the new system. As I said, the first (but largest) patch went yesterday evening (see https://codereview.qt-project.org/#/c/149202/). It basically moves most of the configuration handling from the shell script over to a declarative json file (currently configure.json) that is being processed by qmake. This currently only affects Unix, Windows platforms are still being configured through configure.exe. The change aims to be a 1 to 1 (or at least as close as possible) mapping of the old shell script to the new system. So if you find that some configuration you’re using is suddenly broken let me know.
> 
> I’ll send out a separate email describing the new system in more detail for those who are interested.
> 
> For everybody else, there are a couple of changes that will still come in over the next couple of weeks:
> 
> * Give every module a qtmoduleglobal.h and qtmoduleglobal_p.h file
> 
> We already have per module global files for many modules (they are often required for the export/import handling of classes/symbols). With the new system we will add a public and private global file per module. I’ll start requiring that all public headers of the module include the public global file first, all private headers the private global file.
> 
> This is needed some steps below to modularise the configuration system and to allow us to track whether a certain feature we rely upon in code is actually available or not.
> 
> See https://codereview.qt-project.org/#/c/161143 and subsequent changes (the change adding global_p.h is still missing here, but will come as well)
> 
> * Saner handling of 3rd party libs
> 
> Currently all our dependencies to external libs are handled in a rather ad-hoc way in the pro files. The goal is to unify this, see https://codereview.qt-project.org/#/c/161660/
> 
> * Modularisation of the new configuration system
> 
> I have some patches pending to modularise the new system. We will basically have one json configuration file per module/shared library. This will also allow us to use the system fully on repositories outside of qtbase, who currently have rather limited support for being configured.
> 
> With this change, we will start creating a qtmodule-config.h and qtmodule-config_p.h file as well as a corresponding public and private .pri files for each module. qtmodule-config.h will get included from the public global header for the module, qtmodule-config_p.h from the private one.
> 
> The public pro file will contain definitions for the features that are being exported by the module, the private one for features that are only relevant in the context of the module itself. As an example, ‘mimetypes’ would be a public feature of QtCore (as it changes the set of available API), whereas ‘glib’ would be most likely a private one (as it only determines which event loop to use and doesn’t change API).
> 
> See change https://codereview.qt-project.org/#/c/159604/40 and the following commit
> 
> * Integration of the old feature system
> 
> As said above, there is the old feature system (see qfeatures.txt in corelib/global). With the work above done, integrating it into the system will be trivial (change https://codereview.qt-project.org/#/c/159763/)
> 
> * With this done, I will also want to introduce a new mechanism to handle features in our cpp and header files. The current double negated #ifndef QT_NO_FOO is hard to read and unsafe. By unsafe, I mean that the compiler won’t error out or warn us if the feature ‘foo’ isn’t available (because of a typo or because the feature is actually defined in widgets and you tried using it in gui). I have some pending work that would change this to use a macro function "#if QT_HAS_FEATURE(foo)” where we would actually get a compile error if the feature foo isn’t known to the system. As a nice side effect I’m planning on having the same names for features between .pro and c++ files.
> 
> * Further reduce the shell script
> 
> The longer term goal will be to reduce the shell script further, until it’s basically a bootstrapping step for qmake, and hand all the other configuration work over to qmake. Some more patches for this are pending, but further help here would be appreciated.
> 
> 
> * Get rid of configure.exe
> 
> Finally, I’d also like to get rid of configure.exe, and do the same thing on Windows (ie. Bootstrap qmake from a small script, like we bootstrap configure.exe today) and then let qmake deal with the rest. With that we should be able to get to one cross-platform configuration system. For this task I’d be looking for volunteers :)
> 
> Cheers,
> Lars
> 

Hi,

Pretty nice ! That will be very useful to simplify Qt customization for constrained hardware.

Will there also be a GUI available to help create custom configurations ?

A side question, I've got a few submissions adding handling for a bunch of missing QT_NO_DRAGANDDROP/CLIBOARD tests. Should I ping them to get them in before the QT_HAS_FEATURE migration or rather wait for it and update the patches then ?

Regards
Samuel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160702/3dbb615f/attachment.sig>

From thiago.macieira at intel.com  Sat Jul  2 02:35:04 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 01 Jul 2016 17:35:04 -0700
Subject: [Development] Announcing moc_combine
In-Reply-To: <2097120.WNQMIhggTj@tjmaciei-mobl1>
References: <2097120.WNQMIhggTj@tjmaciei-mobl1>
Message-ID: <1986017.uhvd8pa52r@tjmaciei-mobl1>

On domingo, 29 de maio de 2016 13:05:07 PDT Thiago Macieira wrote:
> I've just pushed a feature[1]

Change is now abandoned due to lack of volunteers to modify qmake to generate 
a suitable Makefile.

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



From marc.mutz at kdab.com  Sat Jul  2 07:46:28 2016
From: marc.mutz at kdab.com (Marc Mutz)
Date: Sat, 2 Jul 2016 07:46:28 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
Message-ID: <201607020746.30009.marc.mutz@kdab.com>

On Friday 01 July 2016 20:36:56 Thiago Macieira wrote:
> The use of the Standard Library member "empty" is highly confusing at
> first  sight because it does not follow the Qt naming guidelines. It's
> even more confusing because the next line has "isEmpty". When I read this
> code, I had to wonder if that "empty" was a verb in the imperative,
> meaning the author was trying to remove all elements from the container.

Don't make this about the STL. Your arguments trivally extend to any third-
party code.

So what you are actually proposing is to not use any third-party code in Qt 
unless it is wrapped in a Qtsy API first.

This is a bit over the top, isn't it? We want to allow our users to stay in 
the cozy Qt bubble for their own projects. As implementers of that bubble, we 
have no right to stay in it ourselves if doing so would be to the detriment of 
our users. And even creating an API wrapper is to the detriment of our users, 
because it requires resources that are then no longer available to fix real 
problems.

If this is straw poll, I'm voting for Option 5. C++ programmers (those that 
wish to implement a C++ library) should be familiar with the STL.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts


From marc.mutz at kdab.com  Sat Jul  2 08:42:42 2016
From: marc.mutz at kdab.com (Marc Mutz)
Date: Sat, 2 Jul 2016 08:42:42 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <122393150.dApz54YNzL@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<5159741467402744@web6j.yandex.ru>
	<122393150.dApz54YNzL@tjmaciei-mobl1>
Message-ID: <201607020842.44832.marc.mutz@kdab.com>

On Friday 01 July 2016 22:05:45 Thiago Macieira wrote:
>  I 
> don't and I don't have time or interest in learning it. You will always see
> me  write a for-loop to fill something rather than use std::fill.

This reminds of the party quip: "I was always bad at math in school <giggle>" 
:)

But seriously:

This sort of sentiment fosters mistakes such as looping over 
QVector::erase(it), turning a linear operation quadratic, and people trying to 
reimplement binary search, leading to unstable search results that depend on 
the size of the container. IOW: bugs.

Yes. I'm saying: Less STL use == more bugs.

We should instead foster the use of STL algorithms ("No raw loops"), not use 
ignorance of the greatest C++ library ever written as a reason not to use what 
it has to offer.

About APIs:

The STL has a great API. push_back() / back() vs. append() / last(), e.g. It 
just happens to be largely consistent with itself instead of with Qt. But 
camelCase is not intrinsically "better" than underscored_names, and I also 
fail to see why first() should be intrinsically superior to front().

And as an aside: please stop claiming that "the Qt API was there before the 
STL one".

Tell the world how the Qt containers looked when the STL was released. Go on. 
If you want Qtsy containers, go back _there_. The current Qt containers are 
more STLsy than Qtsy, and they're better for it.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts


From Lars.Knoll at qt.io  Sat Jul  2 09:43:04 2016
From: Lars.Knoll at qt.io (Lars Knoll)
Date: Sat, 2 Jul 2016 07:43:04 +0000
Subject: [Development] New configuration system
In-Reply-To: <67346AF5-ACB5-465A-8DAC-354C9E51754C@edeltech.ch>
References: <4D7485AB-6F17-49F7-B5A6-DAA776FE613A@qt.io>
	<67346AF5-ACB5-465A-8DAC-354C9E51754C@edeltech.ch>
Message-ID: <AD8A4720-2C56-4703-BB32-D4DDB466DEC5@qt.io>

Hi Samuel,

On 02/07/16 01:11, "Samuel Gaist" <samuel.gaist at edeltech.ch> wrote:
> Pretty nice ! That will be very useful to simplify Qt customization for constrained hardware.

Yes, that’s one of the goals.

> Will there also be a GUI available to help create custom configurations ?

We’re planning on having that as part of Qt for Device Creation.

> A side question, I've got a few submissions adding handling for a bunch of missing 
> QT_NO_DRAGANDDROP/CLIBOARD tests. Should I ping them to get them in before the 
> QT_HAS_FEATURE migration or rather wait for it and update the patches then ?

I’ll leave that up to you. For a while we’ll anyway need to support both in parallel.

Cheers,
Lars



From thiago.macieira at intel.com  Sat Jul  2 09:48:29 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Jul 2016 00:48:29 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <201607020746.30009.marc.mutz@kdab.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<201607020746.30009.marc.mutz@kdab.com>
Message-ID: <5187188.QzO9zDZ9Yv@tjmaciei-mobl1>

On sábado, 2 de julho de 2016 07:46:28 PDT Marc Mutz wrote:
> Don't make this about the STL. Your arguments trivally extend to any third-
> party code.
> 
> So what you are actually proposing is to not use any third-party code in Qt
> unless it is wrapped in a Qtsy API first.

Not exactly. The Standard Library API is close enough to Qt's that it could be 
mistaken for Qt's, but subtly different. No one will mistake the Win32 API, 
Objective C API or, for that matter, any C library's API for Qt's.

The only thing worse than code you don't understand is code that you 
misunderstand.

> This is a bit over the top, isn't it? We want to allow our users to stay in
> the cozy Qt bubble for their own projects. As implementers of that bubble,
> we have no right to stay in it ourselves if doing so would be to the
> detriment of our users. And even creating an API wrapper is to the
> detriment of our users, because it requires resources that are then no
> longer available to fix real problems.

I get your point: we'd spend resources on something other than fixing real 
things. My counter point is that creating these wrappers increases our 
productivity. At the very least, it increases mine.

> If this is straw poll, I'm voting for Option 5. C++ programmers (those that
> wish to implement a C++ library) should be familiar with the STL.

In my opinion, Qt's existence negates your reasoning: we are creating a set of 
libraries that allow users not to know the Standard Library. And I am a 
product of that generation, as are many of our own developers.

Anyway, for the record, I vote for option 3: create simple wrappers. I will 
volunteer to do them too, if this is the option we choose.

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



From thiago.macieira at intel.com  Sat Jul  2 09:41:04 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Jul 2016 00:41:04 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <201607020842.44832.marc.mutz@kdab.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<122393150.dApz54YNzL@tjmaciei-mobl1>
	<201607020842.44832.marc.mutz@kdab.com>
Message-ID: <2857546.BvG1HL49Xq@tjmaciei-mobl1>

On sábado, 2 de julho de 2016 08:42:42 PDT Marc Mutz wrote:
> This sort of sentiment fosters mistakes such as looping over
> QVector::erase(it), turning a linear operation quadratic, and people trying
> to reimplement binary search, leading to unstable search results that
> depend on the size of the container. IOW: bugs.
> 
> Yes. I'm saying: Less STL use == more bugs.

Which is why I grudgingly accept std::erase + std::remove_if, despite being 
ugly-to-read code.

> We should instead foster the use of STL algorithms ("No raw loops"), not use
> ignorance of the greatest C++ library ever written as a reason not to use
> what it has to offer.

If there's no difference in performance, I prefer the raw loop.

> About APIs:
> 
> The STL has a great API. push_back() / back() vs. append() / last(), e.g. It
> just happens to be largely consistent with itself instead of with Qt. But
> camelCase is not intrinsically "better" than underscored_names, and I also
> fail to see why first() should be intrinsically superior to front().

Intrinsically, neither is superior to the other. But that was not my point.

My point is that inside Qt, Qt API is more readable than the Standard Library 
API because one is consistent with the rest of the code, the other isn't.

> And as an aside: please stop claiming that "the Qt API was there before the
> STL one".

I claimed that Qt had its API published before the C++ standard was out. I 
know that SGI had published STL before the standard.

> Tell the world how the Qt containers looked when the STL was released. Go
> on. If you want Qtsy containers, go back _there_. The current Qt containers
> are more STLsy than Qtsy, and they're better for it.

The API style is pretty much the same and this is my only point here: API and 
consistency.

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



From nospam at vuorela.dk  Sat Jul  2 09:53:47 2016
From: nospam at vuorela.dk (Sune Vuorela)
Date: Sat, 2 Jul 2016 07:53:47 +0000 (UTC)
Subject: [Development] Use of Standard Library containers in Qt source
 code
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
Message-ID: <nl7rub$49n$1@ger.gmane.org>

On 2016-07-01, Thiago Macieira <thiago.macieira at intel.com> wrote:
> confusing because the next line has "isEmpty". When I read this code, I had to 
> wonder if that "empty" was a verb in the imperative, meaning the author was 
> trying to remove all elements from the container. 

Hah. I found some code in a large project the other day. The code is a
monstrosity of stl, mfc and qt code.
There was an empty() function. It returned void. and was not const.

Yes. it was clearing its internal collections and states.

/Sune



From philwave at gmail.com  Sat Jul  2 10:08:31 2016
From: philwave at gmail.com (Philippe)
Date: Sat, 02 Jul 2016 10:08:31 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <5187188.QzO9zDZ9Yv@tjmaciei-mobl1>
References: <201607020746.30009.marc.mutz@kdab.com>
	<5187188.QzO9zDZ9Yv@tjmaciei-mobl1>
Message-ID: <20160702100830.633A.6F0322A@gmail.com>

> The only thing worse than code you don't understand is code that you 
> misunderstand.

Very wise remark !

> STL was standardized 18 years ago, I think it should be enough to get used to empty().

A bad name remains a bad name. The mind has more important energy to
spend than "getting used to".

Option 3 has my vote.

Philippe



From kollix at aon.at  Sat Jul  2 10:23:57 2016
From: kollix at aon.at (Martin Koller)
Date: Sat, 02 Jul 2016 10:23:57 +0200
Subject: [Development] dev branch compile fails module-qtdatavis3d
In-Reply-To: <1690774.AWVGoT3XG7@tjmaciei-mobl1>
References: <5970992.y8V6gHAJt6@lapi.koller> <1752970.1ZvLjpp7pR@lapi.koller>
	<1690774.AWVGoT3XG7@tjmaciei-mobl1>
Message-ID: <2053372.XPjC1Obgrh@lapi.koller>

On Friday 01 July 2016 12:45:07 Thiago Macieira wrote:
> On sexta-feira, 1 de julho de 2016 21:36:21 PDT Martin Koller wrote:
> > On Friday 01 July 2016 08:39:07 Thiago Macieira wrote:
> > > On sexta-feira, 1 de julho de 2016 13:26:17 PDT Martin Koller wrote:
> > > > g++ -Wl,--gc-sections
> > > > -Wl,-rpath,/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib -o
> > > > /home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/qml .obj/main.o .obj/qrc_qml.o
> > > > .obj/moc_conf.o   -L/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib
> > > > -lQt5QmlWinCC_OA -lQt5NetworkWinCC_OA -lQt5WidgetsWinCC_OA
> > > > -lQt5GuiWinCC_OA
> > > > -lQt5CoreWinCC_OA -lGL -lpthread
> > > > 
> > > > /home/PACKAGES/qt/qt-repo/qt5/qtbase/lib/libQt5GuiWinCC_OA.so: undefined
> > > > reference to `qt_version_tag'
> > > 
> > > This error indicates your Qt headers do not match the QtCore library.
> > > 
> > > Did you by any chance also build with a namespace?
> > 
> > yes, this is what I said in my first mail.
> 
> "qt_version_tag" is the name of the tag for unnamespaced Qt. If you do 
> 	readelf -s libQt5CoreWinCC_OA.so.5
> 
> You'll probably see "qt_version_tag_X" where X is your namespace, some with 
> extra suffixes for previous Qt versions and one with @@. Can you confirm that?

yes, I find those.
e.g. qt_version_tag_WinCC_OA_5

> Can you check if the build of this application had QT_NAMESPACE defined? Please 
> paste the command-line that was used to compile main.cpp.

It is failing when building qtdeclarative/tools/qml

/home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/moc -DQT_QML_DEBUG_NO_WARNING -DQT_USE_QSTRINGBUILDER -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NAMESPACE=WinCC_OA -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/mkspecs/linux-g++ -I/home/PACKAGES/qt/qt-repo/qt5/qtdeclarative/tools/qml -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtQml -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtNetwork -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0 -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0/QtCore -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtWidgets -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtGui -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore -I/usr/include/c++/4.8 -I/usr/include/c++/4.8/x86_64-suse-linux -I/usr/include/c++/4.8/backward -I/usr/lib64/gcc/x86_64-suse-linux/4.8/include -I/usr/local/include -I/usr/lib64/gcc/x86_64-suse-linux/4.8/include-fixed -I/usr/x86_64-suse-linux/include -I/usr/include main.cpp -o .moc/main.moc
g++ -c -pipe -g -std=c++11 -fno-exceptions -Wall -W -Wvla -Werror -Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow -D_REENTRANT -fPIC -DQT_QML_DEBUG_NO_WARNING -DQT_USE_QSTRINGBUILDER -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NAMESPACE=WinCC_OA -I. -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtQml -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtNetwork -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0 -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0/QtCore -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtWidgets -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtGui -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore -I.moc -isystem /usr/include/libdrm -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/mkspecs/linux-g++ -o .obj/main.o main.cpp
/home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/rcc -name qml qml.qrc -o .rcc/qrc_qml.cpp
g++ -c -pipe -g -std=c++11 -fno-exceptions -Wall -W -Wvla -Werror -Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow -D_REENTRANT -fPIC -DQT_QML_DEBUG_NO_WARNING -DQT_USE_QSTRINGBUILDER -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NAMESPACE=WinCC_OA -I. -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtQml -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtNetwork -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0 -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0/QtCore -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtWidgets -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtGui -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore -I.moc -isystem /usr/include/libdrm -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/mkspecs/linux-g++ -o .obj/qrc_qml.o .rcc/qrc_qml.cpp
/home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/moc -DQT_QML_DEBUG_NO_WARNING -DQT_USE_QSTRINGBUILDER -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NAMESPACE=WinCC_OA -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/mkspecs/linux-g++ -I/home/PACKAGES/qt/qt-repo/qt5/qtdeclarative/tools/qml -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtQml -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtNetwork -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0 -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0/QtCore -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtWidgets -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtGui -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore -I/usr/include/c++/4.8 -I/usr/include/c++/4.8/x86_64-suse-linux -I/usr/include/c++/4.8/backward -I/usr/lib64/gcc/x86_64-suse-linux/4.8/include -I/usr/local/include -I/usr/lib64/gcc/x86_64-suse-linux/4.8/include-fixed -I/usr/x86_64-suse-linux/include -I/usr/include conf.h -o .moc/moc_conf.cpp
g++ -c -pipe -g -std=c++11 -fno-exceptions -Wall -W -Wvla -Werror -Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow -D_REENTRANT -fPIC -DQT_QML_DEBUG_NO_WARNING -DQT_USE_QSTRINGBUILDER -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NAMESPACE=WinCC_OA -I. -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtQml -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtNetwork -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0 -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore/5.8.0/QtCore -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtWidgets -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtGui -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/include/QtCore -I.moc -isystem /usr/include/libdrm -I/home/PACKAGES/qt/qt-repo/qt5/qtbase/mkspecs/linux-g++ -o .obj/moc_conf.o .moc/moc_conf.cpp
g++ -Wl,--gc-sections -Wl,-rpath,/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib -o /home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/qml .obj/main.o .obj/qrc_qml.o .obj/moc_conf.o   -L/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib -lQt5QmlWinCC_OA -lQt5NetworkWinCC_OA -lQt5WidgetsWinCC_OA -lQt5GuiWinCC_OA -lQt5CoreWinCC_OA -lGL -lpthread
/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib/libQt5GuiWinCC_OA.so: undefined reference to `qt_version_tag'
collect2: error: ld returned 1 exit status
Makefile:67: recipe for target '/home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/qml' failed
make: *** [/home/PACKAGES/qt/qt-repo/qt5/qtbase/bin/qml] Error 1


It seems QtGui is referring to the symbol:
/home/PACKAGES/qt/qt-repo/qt5/qtbase/lib/libQt5GuiWinCC_OA.so: undefined reference to `qt_version_tag'

so I checked in the gui Makefile and find something I do not understand:

DEFINES       = -DQT_NO_USING_NAMESPACE -DQT_ENABLE_HARFBUZZ_NG -DENABLE_PIXMAN_DRAWHELPERS -DQT_BUILD_GUI_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB -DQT_NAMESPACE=WinCC_OA

Why does it use -DQT_NO_USING_NAMESPACE _and_ -DQT_NAMESPACE=WinCC_OA ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\                        - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

From denis.shienkov at gmail.com  Sat Jul  2 11:26:33 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Sat, 2 Jul 2016 12:26:33 +0300
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
Message-ID: <59a7fab6-2248-f832-cda8-f7130f1866b0@gmail.com>

Hi all.

Then it is necessary to bring up a question of use of C-style of 'arrays',
e.g. there has to be something like:

qt:containers vs std::containers vs C-arrays

Because I see in Qt sources, that often are uses C-arrays, that is "worse"
than qt:containers vs std::containers.

So, then we need do not use C-arrays at all too.. )))

PS: I prefer to use STL if it is justified, so, seems I vote for p.5.

PS2: If you Qt's developer, you should know STL (at least, you should 
read about :) )!

BR,
Denis


01.07.2016 21:36, Thiago Macieira пишет:
> Premises not under discussion:
>
> 	Qt source code is product and meant to be read by our users
> 	Qt source code must be clean and readable
>
> The above is not up for debate.
>
> For some time now, we've had a flurry of changes to Qt source code that uses
> the Standard Library's containers and algorithms, in the name of performance
> and often code size gains.
>
> I'm not disputing that there is a gain. But I am wondering about the trade-off
> we're making with regards to readability. For example, I was just reviewing
> this code:
>
>      if (d->currentReadChannel >= d->readHeaders.size()
>          || d->readHeaders[d->currentReadChannel].empty()) {
>          Q_ASSERT(d->buffer.isEmpty());
>
> The use of the Standard Library member "empty" is highly confusing at first
> sight because it does not follow the Qt naming guidelines. It's even more
> confusing because the next line has "isEmpty". When I read this code, I had to
> wonder if that "empty" was a verb in the imperative, meaning the author was
> trying to remove all elements from the container.
>
> I had to look up the definition of readHeaders in the review and note that it
> was a std::deque, not a Qt container.
>
> What do we do?
>
> Option 1:
> Not use Standard Library containers, just use the Qt containers as they exist.
>
> Option 2:
> Create new Qt containers to have the same complexity as Standard Library
> containers, but following the Qt naming conventions. Possibly with implicit
> sharing.
>
> Option 3:
> Create Qt API wrappers for those containers like std::deque, adding only a few
> inline functions to match the Qt-style API where the Standard Library API
> deviates. Examples are:
> 	empty		->	isEmpty
> 	push_back	->	append
> 	front		-> 	first
> 	pop_front	->	takeFirst
> 	cbegin		->	constBegin
> 	cfind		->	constFind
>



From steveire at gmail.com  Sat Jul  2 12:26:02 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Sat, 02 Jul 2016 12:26:02 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<5159741467402744@web6j.yandex.ru>
	<122393150.dApz54YNzL@tjmaciei-mobl1>
Message-ID: <nl84rq$9cs$1@ger.gmane.org>

Thiago Macieira wrote:

> More to the point, Qt developers don't have to know the Standard Library.
> *I* don't and I don't have time or interest in learning it.

There is a big division within the C++ community. There is the Qt way and 
the non-Qt way, and they don't overlap.

The approach of many raw loops and no algorithms is taken often in Qt 
implementation (and documentation).

On the other side of the dividing line is people who value boost::irange, 
boost::indexed_range, boost::max_element and others.

As someone who 'crossed over' to the range/algorithm/stl way after starting 
at Ableton, I can say I prefer it greatly.

Here is a patch from me which fixes two bugs in one line of code (which I 
wrote several years previously):

 https://quickgit.kde.org/?p=kitemmodels.git&a=commitdiff&h=49609b8b53

Those kinds of bugs don't occur if you use algorithms instead of nested 
loops. Classes of bugs get eliminated:

 for (auto j = 0; j <= model->rowCount(); ++i) { // Double oops!

 }

 for (auto row : boost::irange(0, model->rowCount()) { 

 }

Yes, code could still mistakenly use `i` inside the loop, but that is a 
different class of bug which would be present in both cases (and the 
solution is more scoping by extracting named functions).

Thanks,

Steve.



From steveire at gmail.com  Sat Jul  2 12:40:53 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Sat, 02 Jul 2016 12:40:53 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<5159741467402744@web6j.yandex.ru>
	<122393150.dApz54YNzL@tjmaciei-mobl1> <nl84rq$9cs$1@ger.gmane.org>
Message-ID: <nl85nl$ltc$1@ger.gmane.org>

Stephen Kelly wrote:

> Thiago Macieira wrote:
> 
>> More to the point, Qt developers don't have to know the Standard Library.
>> *I* don't and I don't have time or interest in learning it.
> 
> There is a big division within the C++ community. There is the Qt way and
> the non-Qt way, and they don't overlap.

This is the real point of my email. There is division along a Qt and non-Qt 
boundary on things like this. 

It is analogous to different sides voting in a referendum: Each side is 
completely perplexed with the other and can't understand their thinking, 
thinks the other side is 'stupid' or otherwise low-quality, and doesn't want 
to waste time understanding it.

For people who learn programming and learn C++ by learning Qt (myself 
included), the Qt implementation seems familiar with all the raw loops if 
you have never encountered the alternative.

However, everyone else is excluded by it. When my colleagues find long 
functions, lots of nested if()s and for()s, ++foo somewhere in while loops, 
they find it much harder to reason about the code. Now I do too. 

So, by sticking to lots of raw loops, you're actually actively excluding 
other parts of the C++ community from participating. I don't have numbers to 
qualify it, but there seems to me to be a much larger community following 
modern C++ practices than following Qt practices on questions like this.

I encourage you and everyone else to dive into it.

Thanks,

Steve.




From iamsergio at gmail.com  Sat Jul  2 14:11:32 2016
From: iamsergio at gmail.com (Sergio Martins)
Date: Sat, 02 Jul 2016 13:11:32 +0100
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
Message-ID: <5476906.2mKDsrTdxL@desktop>

On Friday, 1 July 2016 11:36:56 WEST Thiago Macieira wrote:
> Premises not under discussion:
> 
> 	Qt source code is product and meant to be read by our users
> 	Qt source code must be clean and readable
> The above is not up for debate.
> 
> For some time now, we've had a flurry of changes to Qt source code that uses
> the Standard Library's containers and algorithms, in the name of
> performance and often code size gains.

and in some cases better readability too. For example, whenever you use 
cbegin, cfind, push_back you're writing code that's not only understandable by 
Qt developers but also C++ developers.

Lowering the bar for C++ developers to start contributing is important.
I agree that STL also has many examples of worse readability, like very 
verbose algorithms. We should tackle this on a case by case basis.

> 
> I'm not disputing that there is a gain. But I am wondering about the
> trade-off we're making with regards to readability. For example, I was just
> reviewing this code:
> 
>     if (d->currentReadChannel >= d->readHeaders.size()
> 
>         || d->readHeaders[d->currentReadChannel].empty()) {
> 
>         Q_ASSERT(d->buffer.isEmpty());
> 

"empty" is evil, I've fixed many places where the developer meant "clear()":

https://quickgit.kde.org/?
p=kdelibs4support.git&a=commit&h=c27b851e62307dd16780bf94aff8e6c650ac8dc7

I think we should even remove QList::empty() in Qt6, we want STL compat with 
the good things, not the bad things.

> What do we do?

What do we do to fix what ? First state the problem.
You made a case against "empty" and then extrapolated to STL, as if you had a 
3rd premise "STL is always less readable".

> 	empty		->	isEmpty

Agreed, it's error prone.

> 	push_back	->	append
> 	front		-> 	first
> 	pop_front	->	takeFirst
> 	cbegin		->	constBegin
> 	cfind		->	constFind

Disagreed, the later form is the common denominator between C++ and Qt 
developers.


Regards,
Sérgio Martins


From markg85 at gmail.com  Sat Jul  2 15:44:50 2016
From: markg85 at gmail.com (Mark Gaiser)
Date: Sat, 2 Jul 2016 15:44:50 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
Message-ID: <CAPd6JnHwrUM7bsjC8MUNpTd+rJmWwhAdySG-w9Ku=fwjHMC5qA@mail.gmail.com>

On Fri, Jul 1, 2016 at 8:36 PM, Thiago Macieira <thiago.macieira at intel.com>
wrote:

> Premises not under discussion:
>
>         Qt source code is product and meant to be read by our users
>         Qt source code must be clean and readable
>
> The above is not up for debate.
>
> For some time now, we've had a flurry of changes to Qt source code that
> uses
> the Standard Library's containers and algorithms, in the name of
> performance
> and often code size gains.
>
> I'm not disputing that there is a gain. But I am wondering about the
> trade-off
> we're making with regards to readability. For example, I was just reviewing
> this code:
>
>     if (d->currentReadChannel >= d->readHeaders.size()
>         || d->readHeaders[d->currentReadChannel].empty()) {
>         Q_ASSERT(d->buffer.isEmpty());
>
> The use of the Standard Library member "empty" is highly confusing at first
> sight because it does not follow the Qt naming guidelines. It's even more
> confusing because the next line has "isEmpty". When I read this code, I
> had to
> wonder if that "empty" was a verb in the imperative, meaning the author was
> trying to remove all elements from the container.
>
> I had to look up the definition of readHeaders in the review and note that
> it
> was a std::deque, not a Qt container.
>
> What do we do?
>
> Option 1:
> Not use Standard Library containers, just use the Qt containers as they
> exist.
>
> Option 2:
> Create new Qt containers to have the same complexity as Standard Library
> containers, but following the Qt naming conventions. Possibly with implicit
> sharing.
>
> Option 3:
> Create Qt API wrappers for those containers like std::deque, adding only a
> few
> inline functions to match the Qt-style API where the Standard Library API
> deviates. Examples are:
>         empty           ->      isEmpty
>         push_back       ->      append
>         front           ->      first
>         pop_front       ->      takeFirst
>         cbegin          ->      constBegin
>         cfind           ->      constFind
>
> I don't get why you would be confused by - for instance - the empty method.
STL has that method, but so does Qt [1] apparently in an attempt to be
compatible with the STL API.

Even if you don't want to learn or know how the STL API looks like, it
should not matter since the very same members also apply on Qt containers
with the same .
This is the case for all your examples in Option 3.

Imho it would be nice - when using Qt and STL containers in the same
statement - to use common functions that mean the same in both API's. Thus
in your example both should have been empty() calls, even on the Qt
container to be consistent. But that's just my opinion :)

[1] http://doc.qt.io/qt-5/qlist.html#empty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160702/e6f0ed57/attachment.html>

From b.terrier at gmail.com  Sat Jul  2 15:45:58 2016
From: b.terrier at gmail.com (Benjamin TERRIER)
Date: Sat, 2 Jul 2016 15:45:58 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <nl85nl$ltc$1@ger.gmane.org>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<5159741467402744@web6j.yandex.ru>
	<122393150.dApz54YNzL@tjmaciei-mobl1> <nl84rq$9cs$1@ger.gmane.org>
	<nl85nl$ltc$1@ger.gmane.org>
Message-ID: <CAO+E9oo2=MNKQFgieMoAT98ps-0k7CZvT+d8m-D1nfxcwsSccA@mail.gmail.com>

> However, everyone else is excluded by it. When my colleagues find long
> functions, lots of nested if()s and for()s, ++foo somewhere in while
loops,
> they find it much harder to reason about the code. Now I do too.
>
> So, by sticking to lots of raw loops, you're actually actively excluding
> other parts of the C++ community from participating. I don't have numbers
to
> qualify it, but there seems to me to be a much larger community following
> modern C++ practices than following Qt practices on questions like this.

You can't say that using raw loops (vs stl algorithms) is "actively
excluding" any C++ developer.
I would agree to say that simplifying code by using STL makes the code more
readable for developers used to the STL. And that raw loops and nested
controls can be less readable.
But how come a raw loop can be excluding? It should be understandable by
any C++ developer and, I would dare to say, by any C-style programming
language developer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160702/8b4d1c14/attachment.html>

From olivier at woboq.com  Sat Jul  2 16:04:01 2016
From: olivier at woboq.com (Olivier Goffart)
Date: Sat, 02 Jul 2016 16:04:01 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <3399679.28OPHdOIhQ@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1> <5776CEF6.9020603@kdab.com>
	<3399679.28OPHdOIhQ@tjmaciei-mobl1>
Message-ID: <3340000.yQtmuOTAP1@maurice>

On Freitag, 1. Juli 2016 14:56:36 CEST Thiago Macieira wrote:
> On sexta-feira, 1 de julho de 2016 22:13:42 PDT Giuseppe D'Angelo wrote:
> > Even today: where is QList::push_back(T&&)? Where are our emplacement
> > functions and their try versions? Where are our exception guarantees?)
> 
> We don't care about exceptions, so we won't be adding those.

Ok.

> As for the move-versions, since we can't take move-only types in our
> containers due to the implicit sharing, does it really make a difference if
> we have them or not?

Well, you point out another weakness of our contaners (not supporting move-
only types).
But even then, the push_back(T&&) overload or emplace functions would still 
usefull to avoid an uneeded copy in some cases. (possibly saving memory 
alocations)

[...]
> > Which again seems like a sensible thing to do in general, unless there
> > are documented cases in which Qt containers significantly outperform STL
> > ones (apart from implicit sharing).
> 
> I would prefer the opposite: use non-Qt only if that is better than the Qt
> equivalent. If you can't prove it or if it's too small, it's not worth the
> difference in readability that it creates.

I think you have an unjustified bias against the STL.
With the exception of "empty", you are overestimating the readability problem 
it pauses.

You also write in another email on this thread:
> You will always see me write a for-loop to fill something rather than use
> std::fill.

And I think you are making a mistake.

Consider:

a)
 std::fill(vec.begin(), vec.end(), computeBackgroundColor());

b)
 for(int i = 0; i < vec.size(); i++)
   vec[i] = computeBackgroundColor();

c)
 auto backgroundColor = computeBackgroundColor();
 for (auto it = vec.begin(); it != vec.end(); ++it)
   *it = backgroundColor;


Personally I find that a. is more readable, as it is objectively more concise 
and cearly express the intent.  b. has some overhead.
Conciseness is important as it reduce the likelyhood of mistake. Also more 
code means more time to read it.

It is true that a lot is a matter of taste, but I totaly buy the reasoning 
behind the "no raw loop".

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org



From steveire at gmail.com  Sat Jul  2 16:30:18 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Sat, 02 Jul 2016 16:30:18 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<5159741467402744@web6j.yandex.ru>
	<122393150.dApz54YNzL@tjmaciei-mobl1>
	<nl84rq$9cs$1@ger.gmane.org> <nl85nl$ltc$1@ger.gmane.org>
	<CAO+E9oo2=MNKQFgieMoAT98ps-0k7CZvT+d8m-D1nfxcwsSccA@mail.gmail.com>
Message-ID: <nl8j5r$jq6$1@ger.gmane.org>

Benjamin TERRIER wrote:

>> However, everyone else is excluded by it. When my colleagues find long
>> functions, lots of nested if()s and for()s, ++foo somewhere in while
> loops,
>> they find it much harder to reason about the code. Now I do too.
>>
>> So, by sticking to lots of raw loops, you're actually actively excluding
>> other parts of the C++ community from participating. I don't have numbers
> to
>> qualify it, but there seems to me to be a much larger community following
>> modern C++ practices than following Qt practices on questions like this.
> 
> You can't say that using raw loops (vs stl algorithms) is "actively
> excluding" any C++ developer.

Yes, maybe 'actively' was not correct.

> But how come a raw loop can be excluding? It should be understandable by
> any C++ developer and, I would dare to say, by any C-style programming
> language developer.

I don't think anyone can understand or reason about raw-loop-heavy code (see 
PS below). I use 'excluded' to refer to people who are not willing to do so. 
They exclude themselves from working on Qt code because they can not reason 
about it.

In the same sense, Thiago is 'excluded' from reading and understanding code 
which uses 'container.empty()' or which doesn't use raw-loops, because he 
would choose to not work on such code.

There is a divide. The 'exclusion' is self-decided.

Does that make sense? If you have a better phrase than 'self-exclusion' for 
that then it could be useful to share it.

Thanks,

Steve.

PS: Take QQuickListViewPrivate::applyInsertionChange as it is currently 
written as an example:

 http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/items/qquicklistview.cpp?id=5d23470b#n3068

There's a `++index` somewhere in the middle 3 scopes deep. Further up in the 
function `index` is assigned, but then assigned again (conditionally) from 
the `count` of a container. Then `index` is used later in the function, but 
I can't reason about what it is when it is used.

There are many other problems with that function, which are caused by many 
'raw' loops nested up to four levels, affecting variables assigned outside 
top-level if() conditions half a page up. Extracting such code into named 
functions would indicate the intent of the function.

Someone unwilling to attempt to reason about the code in that function is 
'excluded' from fixing something in it or extending whatever features it 
has.




From b.terrier at gmail.com  Sat Jul  2 17:34:06 2016
From: b.terrier at gmail.com (Benjamin TERRIER)
Date: Sat, 2 Jul 2016 17:34:06 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <nl8j5r$jq6$1@ger.gmane.org>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<5159741467402744@web6j.yandex.ru>
	<122393150.dApz54YNzL@tjmaciei-mobl1> <nl84rq$9cs$1@ger.gmane.org>
	<nl85nl$ltc$1@ger.gmane.org>
	<CAO+E9oo2=MNKQFgieMoAT98ps-0k7CZvT+d8m-D1nfxcwsSccA@mail.gmail.com>
	<nl8j5r$jq6$1@ger.gmane.org>
Message-ID: <CAO+E9opVaaqBYGWt_WjArui2Umi2jL8k84yx8MC6QF6qs+6Pzw@mail.gmail.com>

2016-07-02 16:30 GMT+02:00 Stephen Kelly <steveire at gmail.com>:
> Benjamin TERRIER wrote:
>
>> But how come a raw loop can be excluding? It should be understandable by
>> any C++ developer and, I would dare to say, by any C-style programming
>> language developer.
>
> I don't think anyone can understand or reason about raw-loop-heavy code (see
> PS below). I use 'excluded' to refer to people who are not willing to do so.
> They exclude themselves from working on Qt code because they can not reason
> about it.
>
> In the same sense, Thiago is 'excluded' from reading and understanding code
> which uses 'container.empty()' or which doesn't use raw-loops, because he
> would choose to not work on such code.
>
> There is a divide. The 'exclusion' is self-decided.
>
> Does that make sense? If you have a better phrase than 'self-exclusion' for
> that then it could be useful to share it.

Ok for me if you meant it this way.

> Someone unwilling to attempt to reason about the code in that function is
> 'excluded' from fixing something in it or extending whatever features it
> has.

I'd boldly reply to that that if one is unwilling to reason about a
piece of code, one should not be fixing it.
But I'd also agree that the code should be as readable as possible to
get a many developers to contribute.

Back to Qt current situation I think that the lack of comments in some
parts is a bigger throwback than
the code style.

And back to the actual topic of Qt/STL containers, I am for option 3
if the project can afford the
extra development and maintenance otherwise I'd go with option 4.

Br,

Benjamin Terrier


From thiago.macieira at intel.com  Sat Jul  2 19:06:08 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Jul 2016 10:06:08 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <5476906.2mKDsrTdxL@desktop>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1> <5476906.2mKDsrTdxL@desktop>
Message-ID: <1704608.bauXxcjfj5@tjmaciei-mobl1>

On sábado, 2 de julho de 2016 13:11:32 PDT Sergio Martins wrote:
> On Friday, 1 July 2016 11:36:56 WEST Thiago Macieira wrote:
> > Premises not under discussion:
> > 	Qt source code is product and meant to be read by our users
> > 	Qt source code must be clean and readable
> > 
> > The above is not up for debate.
> > 
> > For some time now, we've had a flurry of changes to Qt source code that
> > uses the Standard Library's containers and algorithms, in the name of
> > performance and often code size gains.
> 
> and in some cases better readability too. For example, whenever you use
> cbegin, cfind, push_back you're writing code that's not only understandable
> by Qt developers but also C++ developers.
> 
> Lowering the bar for C++ developers to start contributing is important.
> I agree that STL also has many examples of worse readability, like very
> verbose algorithms. We should tackle this on a case by case basis.

See also my reply to Stephen on the same topic.

I agree with the logic, but I have to question the effort vs benefit.

This is the same question as with our CLA: how many developers are we turning 
away because of the issue? How many would make meaningful contributions if 
only the situation were different? You can extend this to other minor issues, 
like coding style (use of spaces instead of tabs) or even buildsystems ("I 
won't touch qmake").

I honestly do not see a horde of developers stopped at the gates of the API. I 
really don't think that's the case, as most of the developers willing to make 
contributions have usually used Qt and are somewhat familiar with our API. 
That is, the contributors usually are users of Qt that move upstream.

There are a few exceptions of developers moving downstream. For example, 
Wayland developers that come take a look at our code. How do we cater for both 
low-level C coders and for algorithms-using C++ coders?

> > I'm not disputing that there is a gain. But I am wondering about the
> > trade-off we're making with regards to readability. For example, I was
> > just
> > 
> > reviewing this code:
> >     if (d->currentReadChannel >= d->readHeaders.size()
> >     
> >         || d->readHeaders[d->currentReadChannel].empty()) {
> >         
> >         Q_ASSERT(d->buffer.isEmpty());
> 
> "empty" is evil, I've fixed many places where the developer meant "clear()":

Yeah, except that here it *wasn't* clear(). It was "size() == 0" (isEmpty).

But I had to check.

> > What do we do?
> 
> What do we do to fix what ? First state the problem.
> You made a case against "empty" and then extrapolated to STL, as if you had
> a 3rd premise "STL is always less readable".

The situation (not everyone will agree there is a problem) is what I said at 
the beginning of my email and left quoted here: there's a flurry of new code 
using the Standard Library containers and algorithms. Do we do something about 
it?

Note that option 1 is status quo.

> > 	empty		->	isEmpty
> 
> Agreed, it's error prone.
> 
> > 	push_back	->	append
> > 	front		-> 	first
> > 	pop_front	->	takeFirst
> > 	cbegin		->	constBegin
> > 	cfind		->	constFind
> 
> Disagreed, the later form is the common denominator between C++ and Qt
> developers.

You mean the former, not latter.

Indeed, but my whole argument is that developers writing Qt code and, more 
importantly, those *reading* Qt code, are more familiar with the latter cases.

If the problem is only "empty", we can get around the problem by requiring 
"size() == 0" instead.

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



From thiago.macieira at intel.com  Sat Jul  2 18:51:50 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Jul 2016 09:51:50 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <nl85nl$ltc$1@ger.gmane.org>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1> <nl84rq$9cs$1@ger.gmane.org>
	<nl85nl$ltc$1@ger.gmane.org>
Message-ID: <4490054.sMN0YLkbx6@tjmaciei-mobl1>

On sábado, 2 de julho de 2016 12:40:53 PDT Stephen Kelly wrote:
> So, by sticking to lots of raw loops, you're actually actively excluding 
> other parts of the C++ community from participating. I don't have numbers
> to  qualify it, but there seems to me to be a much larger community
> following modern C++ practices than following Qt practices on questions
> like this.

The converse is also true: by using auxiliary functions to do things where a 
simple loop would do, you're excluding a sizeable community that has never 
encountered those functions. Especially if those auxiliary types and functions 
have different and sometimes bewildering names, different from Qt's.

Like you, I don't have numbers. But I can tell you one thing for sure: that 
community that follows non-Qt practices is not here. It would be nice to 
attract them, but not at the expense of losing the people we already have and 
are familiar with Qt internals.

> I encourage you and everyone else to dive into it.

No, thanks. You will also see me iterating over QChar and char instead of 
using those algorithms or even some of Qt's. See QUrlPrivate::parse, my recent 
changes to QTzTimeZonePrivate, for examples.

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



From thiago.macieira at intel.com  Sat Jul  2 18:43:51 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Jul 2016 09:43:51 -0700
Subject: [Development] dev branch compile fails module-qtdatavis3d
In-Reply-To: <2053372.XPjC1Obgrh@lapi.koller>
References: <5970992.y8V6gHAJt6@lapi.koller>
	<1690774.AWVGoT3XG7@tjmaciei-mobl1>
	<2053372.XPjC1Obgrh@lapi.koller>
Message-ID: <2156213.PCUHDssgLi@tjmaciei-mobl1>

On sábado, 2 de julho de 2016 10:23:57 PDT Martin Koller wrote:
> It seems QtGui is referring to the symbol:
> /home/PACKAGES/qt/qt-repo/qt5/qtbase/lib/libQt5GuiWinCC_OA.so: undefined
> reference to `qt_version_tag'

Oh, right. So the problem is not in the tool being built but in QtGui itself.

First question is: how did QtGui link in the first place? It should have the 
flag to fail to link with undefined symbols, so either that flag is missing or 
the symbol was found.

> so I checked in the gui Makefile and find something I do not understand:
> 
> DEFINES       = -DQT_NO_USING_NAMESPACE -DQT_ENABLE_HARFBUZZ_NG
> -DENABLE_PIXMAN_DRAWHELPERS -DQT_BUILD_GUI_LIB -DQT_BUILDING_QT
> -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
> -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
> -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS
> -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB
> -DQT_NAMESPACE=WinCC_OA
> 
> Why does it use -DQT_NO_USING_NAMESPACE _and_ -DQT_NAMESPACE=WinCC_OA ?

They mean different things. QT_NO_USING_NAMESPACE causes qglobal.h NOT to do 
"using namespace QT_NAMESPACE;".

Still, QT_NAMESPACE was set. Can you find which .o in QtGui made a reference to 
qt_version_tag?

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



From thiago.macieira at intel.com  Sat Jul  2 19:10:11 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 02 Jul 2016 10:10:11 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <CAPd6JnHwrUM7bsjC8MUNpTd+rJmWwhAdySG-w9Ku=fwjHMC5qA@mail.gmail.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<CAPd6JnHwrUM7bsjC8MUNpTd+rJmWwhAdySG-w9Ku=fwjHMC5qA@mail.gmail.com>
Message-ID: <1594825.rovEIMYOfq@tjmaciei-mobl1>

On sábado, 2 de julho de 2016 15:44:50 PDT Mark Gaiser wrote:
> I don't get why you would be confused by - for instance - the empty
> method.
> STL has that method, but so does Qt [1] apparently in an attempt to be
> compatible with the STL API.

That doesn't mean we will allow the use of those methods in our own libraries. 
I *will* reject any code that uses empty() to mean isEmpty() on a Qt 
container.

The whole point of this thread is that using certain methods is misleading or, 
at best, confusing.

> Even if you don't want to learn or know how the STL API looks like, it
> should not matter since the very same members also apply on Qt containers
> with the same .
> This is the case for all your examples in Option 3.
> 
> Imho it would be nice - when using Qt and STL containers in the same
> statement - to use common functions that mean the same in both API's. Thus
> in your example both should have been empty() calls, even on the Qt
> container to be consistent. But that's just my opinion :)

I agree with your premise and the benefits in your conclusion. I just don't 
agree with using the Standard Library names, in detriment to Qt's own API. 

The whole point of Option 3 is to provide the Qt-like names so that we have 
*only* Qt-like names in Qt's source code. We'd achieve the same as you 
proposed (consistency) and we'd be consistent with the rest of the existing 
code as well as our recommended API.

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



From steveire at gmail.com  Sun Jul  3 11:26:42 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Sun, 03 Jul 2016 11:26:42 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
Message-ID: <nlaloi$514$1@ger.gmane.org>

Thiago Macieira wrote:

> What do we do?

    {
    int container[1];
    Q_ASSERT(!qIsEmpty(container));
    }
    {
    std::vector<int> container;
    Q_ASSERT(qIsEmpty(container));
    }
    {
    std::deque<int> container;
    Q_ASSERT(qIsEmpty(container));
    }
    {
    std::list<int> container;
    Q_ASSERT(qIsEmpty(container));
    }
    {
    std::forward_list<int> container;
    Q_ASSERT(qIsEmpty(container));
    }
    {
    QVector<int> container;
    Q_ASSERT(qIsEmpty(container));
    }
    {
    QList<int> container;
    Q_ASSERT(qIsEmpty(container));
    }
    {
    QLinkedList<int> container;
    Q_ASSERT(qIsEmpty(container));
    }
    {
    QString container;
    Q_ASSERT(qIsEmpty(container));
    }



From steveire at gmail.com  Sun Jul  3 12:04:14 2016
From: steveire at gmail.com (Stephen Kelly)
Date: Sun, 03 Jul 2016 12:04:14 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1> <nl84rq$9cs$1@ger.gmane.org>
	<nl85nl$ltc$1@ger.gmane.org> <4490054.sMN0YLkbx6@tjmaciei-mobl1>
Message-ID: <nlanuv$2sv$1@ger.gmane.org>

Thiago Macieira wrote:

> On sábado, 2 de julho de 2016 12:40:53 PDT Stephen Kelly wrote:
>> So, by sticking to lots of raw loops, you're actually actively excluding
>> other parts of the C++ community from participating. I don't have numbers
>> to  qualify it, but there seems to me to be a much larger community
>> following modern C++ practices than following Qt practices on questions
>> like this.
> 
> The converse is also true

I agree, and I encourage you to raise std::empty as a problem

 http://en.cppreference.com/w/cpp/iterator/empty

so that it can be renamed to is_empty.  C++ developers should get 'is' in 
the name if that is the correct thing to do (ignore the camelCase/snake_case 
difference - that is orthogonal to the 'is' issue).

Giving that feedback that such a method must have 'is' in the name would be 
a valuable contribution from Qt experiences to the C++ community and work 
towards bridging the divide that I claimed exists (in both directions). 

> : by using auxiliary functions to do things where
> a simple loop would do, you're excluding a sizeable community that has
> never encountered those functions. Especially if those auxiliary types and
> functions have different and sometimes bewildering names, different from
> Qt's.

You can make Qt names for things. The important thing is that there is a 
name. Why don't we write 

 std::begin(container) == std::end(container)

everywhere? Because we named that concept 'emptiness'.

Consider this caricature of the kind of code that exists throughout Qt:

 int index = someFunctionParameter;
 int foo = containerOfIndexes.size();
 if (something) {
    while (anotherThing) {
      if (foo % 2 == 0) {
        ++foo;
        ++index;
      }
    }
 } else {
   ++foo;
 }

 while (foo) {
   if (bar && bang) {
     if (bang) {
       for (int i = 0, e = containerOfIndexes.size(); i != e; ++i) {
         if (index < containerOfIndexes[i]) {
           index = containerOfIndexes[i];
         }
       }
     }
     if (index < 0)
       break;
   }
 }

 return index;


It is not possible to reason about code like that. I have the feeling that 
faced with code like that, people just don't attempt to reason about it 
while at the same time trying to get on with what they are trying to do.

Here's a recent example of a contributor responding exactly that way to such 
code:

 https://codereview.qt-project.org/#/c/161133

The way to deal with functions like that is to extract loops and other 
concepts into functions with names. Delegating things like that has the 
effect of making the function shorter. Adding comments instead would not 
have a positive effect on the size of the function and good names are less 
likely to bitrot than comments.

In the above example you would start by extracting a qMaxValue function. You 
could implement that function in terms of std::max_element, or you could 
write a loop in the function if that's more comfortable. Even in the latter 
case, it is not a 'raw loop'. You have named a concept and using it will 
make other code more readable.

> Like you, I don't have numbers. But I can tell you one thing for sure:
> that community that follows non-Qt practices is not here.

I don't think that's true. People who do follow modern practices or boost do 
sometimes appear on this mailing list (and more than that read it - hello 
lurkers!). They don't tend to become long-term contributors though.

> It would be nice
> to attract them, but not at the expense of losing the people we already
> have and are familiar with Qt internals.

I think starting small to introduce the concepts and with Qt names like 
qMaxValue would work. Yes, learning and change would need to happen, but 
that can happen at whatever pace you choose. 

I'm not going to recommend replacing all loops with some Qt version of range 
adaptors starting tomorrow. 

There are many small steps which have benefits for readability.

>> I encourage you and everyone else to dive into it.
> 
> No, thanks.

I expect that, but I continue to encourage it (to everyone) anyway :).

Thanks,

Steve.




From staniek at kde.org  Sun Jul  3 12:33:50 2016
From: staniek at kde.org (Jaroslaw Staniek)
Date: Sun, 3 Jul 2016 12:33:50 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
Message-ID: <CAOj7QQ2qCQQ2OJXAesUy3phEAwmfE9taAmBa4BrQQWbNGN7KRw@mail.gmail.com>

On 1 July 2016 at 20:36, Thiago Macieira <thiago.macieira at intel.com> wrote:

> Premises not under discussion:
>
>         Qt source code is product and meant to be read by our users
>         Qt source code must be clean and readable
>
> The above is not up for debate.
>
> For some time now, we've had a flurry of changes to Qt source code that
> uses
> the Standard Library's containers and algorithms, in the name of
> performance
> and often code size gains.
>


​[..]

Thanks for raising this topic, Thiago.
The topic resonates for me in the following way (as just a reader of the
code):

1. No doubt the algorithms and such improve our programming experience and
the simplifies activity that costs us most: reading/understanding the code
and intents. I'd applaud having the Option 3 and see Option 2 as nice to
have for future Qt.
Moreover I would happily consider using the wrappers (once stabilized
enough, they would be inline anyway?) in my projects out of the Qt source
tree. Sometimes I do consider adding that myself and like many others
probably already have a tiny bit of buried in my "utility" codes. That
would be no longer so much a necessity.

2. A mature C++ engineer shall not forget that the market average is way
below that level. I think it's not our intent to build a barrier for
contributors this way. I've seen a few projects that use no single
algorithm constructs, yet these are successful and mature projects. It's
unscientific but I recognize average level for a C/C++ programmer is way
below of level represented on this mailing list or boost/STL lists.
People have chosen Qt for simplicity _and_ consistency (no particular
order). Before knowing one or more typical profile of Qt contributors (like
personal in UX design?) it's too easy to assume everyone is so clever or on
its way to awesomeness.

3. I think it would be a good signal to the user base if Option 3 (or/and
then Option 2) would be communicated publicly that the Qt-ifed container
extensions will come to the public API. Not tomorrow but one day, like it
was the case with the QtJSEngine feature that started as a private
component. A next small-big thing from the Qt team.

4. I perceive *consistency in naming* as a higher value for a project than
potentially encouraging or winking at some "other" sub-communities to get
more people on board. A building block of a project is its internal coding
guideline. Qt is known from promoting consistency. I remember the
guidelines were used as a template in my professional work while creating
similar guidelines for others.
After all it's even a bit poisonous to compare release dates of projects.
E.g. Fortran or Visual Basic 1.0 predates HP's STL. Despite different
markets addressed, all of them are potentially interesting to build
contributor base; would it be sane to propose allowing for VB naming
schemes inside Qt? Or Fortran's?

Even if I am repeating someone else's observation, let's not forget: even
if a fraction of Qt's source code would contain bits familiar for
programmers thinking the "STL" way and having "STL" muscle memory, the
rest, the majority of the code follows the Qt guidelines. It's easy to
imagine single expressions or a simple code block that uses two naming
guidelines, usage of verbs/nouns, camel case, underscores. Some of that is
an aesthetic layer, some of that is more like provoking human errors. I bet
it can be independently measured how much effort it costs to switch between
naming while reading a single C++ block with mixed naming.[*]
And such code could not be too easily rejected in a code review.

Engineers are good at switching context once a while, but I am not sure
they are good at switching it every few seconds. Pros can cope with that,
75% of their efficiency is still very good, but that's just it.

I am afraid we would move to  discussions about where the borders are, how
to change our (currently) very good guideline document to address the
change. We would enter area where this (specific, dedicated) project has
not even two two approaches but a mix that's hard to clean up, and with no
way to undo.

[*] Extreme example of the mix is having HTML/JS/CSS/CSSS/PHP/Perl blocks
in one file.
​


>
> I'm not disputing that there is a gain. But I am wondering about the
> trade-off
> we're making with regards to readability. For example, I was just reviewing
> this code:
>
>     if (d->currentReadChannel >= d->readHeaders.size()
>         || d->readHeaders[d->currentReadChannel].empty()) {
>         Q_ASSERT(d->buffer.isEmpty());
>
> The use of the Standard Library member "empty" is highly confusing at first
> sight because it does not follow the Qt naming guidelines. It's even more
> confusing because the next line has "isEmpty". When I read this code, I
> had to
> wonder if that "empty" was a verb in the imperative, meaning the author was
> trying to remove all elements from the container.
>
> I had to look up the definition of readHeaders in the review and note that
> it
> was a std::deque, not a Qt container.
>
> What do we do?
>
> Option 1:
> Not use Standard Library containers, just use the Qt containers as they
> exist.
>
> Option 2:
> Create new Qt containers to have the same complexity as Standard Library
> containers, but following the Qt naming conventions. Possibly with implicit
> sharing.
>
> Option 3:
> Create Qt API wrappers for those containers like std::deque, adding only a
> few
> inline functions to match the Qt-style API where the Standard Library API
> deviates. Examples are:
>         empty           ->      isEmpty
>         push_back       ->      append
>         front           ->      first
>         pop_front       ->      takeFirst
>         cbegin          ->      constBegin
>         cfind           ->      constFind
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160703/d1044004/attachment.html>

From julien.blanc at nmc-company.com  Mon Jul  4 08:14:21 2016
From: julien.blanc at nmc-company.com (Julien Blanc)
Date: Mon, 04 Jul 2016 08:14:21 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <1594825.rovEIMYOfq@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<CAPd6JnHwrUM7bsjC8MUNpTd+rJmWwhAdySG-w9Ku=fwjHMC5qA@mail.gmail.com>
	<1594825.rovEIMYOfq@tjmaciei-mobl1>
Message-ID: <1467612861.2991.26.camel@nmc-company.com>

Le samedi 02 juillet 2016 à 10:10 -0700, Thiago Macieira a écrit :
> On sábado, 2 de julho de 2016 15:44:50 PDT Mark Gaiser wrote:
> > I don't get why you would be confused by - for instance - the empty
> > method.
> > STL has that method, but so does Qt [1] apparently in an attempt to be
> > compatible with the STL API.
> 
> That doesn't mean we will allow the use of those methods in our own libraries. 
> I *will* reject any code that uses empty() to mean isEmpty() on a Qt 
> container.
> 
> The whole point of this thread is that using certain methods is misleading or, 
> at best, confusing.

While I agree with you that isEmpty is a far better name than empty, I
don’t think renaming is the best idea.

As for the argument of using size() == 0 (which I prefer over renaming),
note that :
- std::forward_list does not have a size() member
- std::list size() may have linear complexity before C++11

About the example you gave, I see two things that could be improved,
with a much broader scope than just empty -> isEmpty (which is a
particular case) :

- the use of side-effects functions (aka : non const) in conditionals :
IMHO they’re bad for readability, especially if the condition is a bit
complex. If it is banned (or, banned unless commented), then there is no
ambiguity.
- visual distinction between const / non-const functions / variables
usages in QtCreator/whatever ide you’re using. This one would be a
must : the fact that empty is const makes it really clear what it does,
but you currently have to either know it or read the doc.

Following Stephen Kelly’s mails, I’m convinced that instead of wrapping
stl containers, implementing a free function qIsEmpty is less work and
addresses all your readability concerns.

Regards,

Julien



From thiago.macieira at intel.com  Mon Jul  4 08:41:07 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sun, 03 Jul 2016 23:41:07 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <1467612861.2991.26.camel@nmc-company.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<1594825.rovEIMYOfq@tjmaciei-mobl1>
	<1467612861.2991.26.camel@nmc-company.com>
Message-ID: <1932645.mCeXXNuYup@tjmaciei-mobl1>

On segunda-feira, 4 de julho de 2016 08:14:21 PDT Julien Blanc wrote:
> Following Stephen Kelly’s mails, I’m convinced that instead of wrapping
> stl containers, implementing a free function qIsEmpty is less work and
> addresses all your readability concerns.

But it is uglier and does not help with .append() for .push_back().

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



From andre at familiesomers.nl  Mon Jul  4 09:47:12 2016
From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=)
Date: Mon, 4 Jul 2016 09:47:12 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <1932645.mCeXXNuYup@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<1594825.rovEIMYOfq@tjmaciei-mobl1>
	<1467612861.2991.26.camel@nmc-company.com>
	<1932645.mCeXXNuYup@tjmaciei-mobl1>
Message-ID: <78e8bdea-8174-977e-e900-807e8d1f9a38@familiesomers.nl>



Op 04/07/2016 om 08:41 schreef Thiago Macieira:
> On segunda-feira, 4 de julho de 2016 08:14:21 PDT Julien Blanc wrote:
>> Following Stephen Kelly’s mails, I’m convinced that instead of wrapping
>> stl containers, implementing a free function qIsEmpty is less work and
>> addresses all your readability concerns.
> But it is uglier
Actually, I disagree with that. As someone who has come to appreciate 
STL after growing up in the Qt world, I think that memberfunctions are 
over-used. Emptyness is a concept that can be applied to many objects, 
and it would be nice if I don't need a different function for all of 
them. The problem with implementing things in a member function is that 
the implementation will be specific for that class only, even if it did 
not really have to be. You end up re-creating algorithms for no good 
reason. And yes, that mistake has been made in the standard libraries as 
well.

Note that there is work going on by Bjarne S. on a universal calling 
conventions. As in: making calling a free function on an object and 
calling a member function on that object to be interchangeble in syntax.

> and does not help with .append() for .push_back().
>
Why not? You could do the same thing there if you prefer.

append(Container c, T item) can be made to work for both STL and Qt 
containers I think?

André


From christian.kandeler at qt.io  Mon Jul  4 09:59:44 2016
From: christian.kandeler at qt.io (Christian Kandeler)
Date: Mon, 4 Jul 2016 09:59:44 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
Message-ID: <183a8a2c-240e-9afc-5834-f8c68f441eaa@qt.io>

On 07/01/2016 08:36 PM, Thiago Macieira wrote:
> For some time now, we've had a flurry of changes to Qt source code that uses
> the Standard Library's containers and algorithms, in the name of performance
> and often code size gains.
>
> I'm not disputing that there is a gain. But I am wondering about the trade-off
> we're making with regards to readability. For example, I was just reviewing
> this code:
>
>     if (d->currentReadChannel >= d->readHeaders.size()
>         || d->readHeaders[d->currentReadChannel].empty()) {
>         Q_ASSERT(d->buffer.isEmpty());
>
> The use of the Standard Library member "empty" is highly confusing at first
> sight because it does not follow the Qt naming guidelines. It's even more
> confusing because the next line has "isEmpty". When I read this code, I had to
> wonder if that "empty" was a verb in the imperative, meaning the author was
> trying to remove all elements from the container.

I must admit I don't see a problem here. We are not talking about some 
random third-party library that people are pulling in gratuitously, but 
about the Standard Library, an integral part of C++ that every developer 
should be at least generally familiar with.
Having said that, I personally follow the "use Qt types by default" 
approach, but should we really regard STL containers as dangerous 
intruders that need to be kept out if at all possible?


Christian



From philwave at gmail.com  Mon Jul  4 10:03:11 2016
From: philwave at gmail.com (Philippe)
Date: Mon, 04 Jul 2016 10:03:11 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <78e8bdea-8174-977e-e900-807e8d1f9a38@familiesomers.nl>
References: <1932645.mCeXXNuYup@tjmaciei-mobl1>
	<78e8bdea-8174-977e-e900-807e8d1f9a38@familiesomers.nl>
Message-ID: <20160704100310.6DC3.6F0322A@gmail.com>

>>Actually, I disagree with that. As someone who has come to appreciate 
>>STL after growing up in the Qt world,

Exact opposite here: I learned STL from its early days, and could never
become at ease with its namings... and I started to breath with Qt
containers :)

Philippe


From andre at familiesomers.nl  Mon Jul  4 10:14:58 2016
From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=)
Date: Mon, 4 Jul 2016 10:14:58 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <20160704100310.6DC3.6F0322A@gmail.com>
References: <1932645.mCeXXNuYup@tjmaciei-mobl1>
	<78e8bdea-8174-977e-e900-807e8d1f9a38@familiesomers.nl>
	<20160704100310.6DC3.6F0322A@gmail.com>
Message-ID: <ff5db22b-5992-98ad-e655-a68e16c51f5c@familiesomers.nl>



Op 04/07/2016 om 10:03 schreef Philippe:
>>> Actually, I disagree with that. As someone who has come to appreciate
>>> STL after growing up in the Qt world,
> Exact opposite here: I learned STL from its early days, and could never
> become at ease with its namings... and I started to breath with Qt
> containers :)
>
I'm not saying the namings are good, and I still find snake_case ugly. I 
dislike the use of abreviations, and yet, isEmpty() is way clearer than 
empty(). But the principles are very sound, especially the use of named 
algorithms over raw loops. Note that Qt has basicaly abandoned it's own 
algorithm collection for the stl one. That's mostly a Good Thing IMHO, 
though having your own collection of algorithms building on top of stl 
good practice I think. STL is by no means complete; you're encouraged to 
extend it. Defining a well-named free function to bridge the gap where 
it improves things is one way of enhancing both: you enhance STL by 
making it more readable to use, and you enhance Qt by embracing 
well-tested algorithms and containers.

André



From marc.mutz at kdab.com  Mon Jul  4 10:53:05 2016
From: marc.mutz at kdab.com (Marc Mutz)
Date: Mon, 4 Jul 2016 10:53:05 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <20160704100310.6DC3.6F0322A@gmail.com>
References: <1932645.mCeXXNuYup@tjmaciei-mobl1>
	<78e8bdea-8174-977e-e900-807e8d1f9a38@familiesomers.nl>
	<20160704100310.6DC3.6F0322A@gmail.com>
Message-ID: <201607041053.07385.marc.mutz@kdab.com>

On Monday 04 July 2016 10:03:11 Philippe wrote:
> >>Actually, I disagree with that. As someone who has come to appreciate 
> >>STL after growing up in the Qt world,
> 
> Exact opposite here: I learned STL from its early days, and could never
> become at ease with its namings... and I started to breath with Qt
> containers :)

The value of the STL is not in the containers, it's in the algorithms.

We who use std containers in Qt would be on very thin ice if the Qt containers 
would stand an ice-balls chance in hell against the STL containers. But if 
using a std::deque in place of a QList<QByteArray> speeds up code by 40%, then 
Qt has failed and either needs to fix its containers (impossible w/o abandoning 
CoW) or accept STL container use.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts


From edward.welbourne at qt.io  Mon Jul  4 14:07:19 2016
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Mon, 4 Jul 2016 12:07:19 +0000
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <CAOj7QQ2qCQQ2OJXAesUy3phEAwmfE9taAmBa4BrQQWbNGN7KRw@mail.gmail.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>,
	<CAOj7QQ2qCQQ2OJXAesUy3phEAwmfE9taAmBa4BrQQWbNGN7KRw@mail.gmail.com>
Message-ID: <AM2PR02MB0754950AA8E1E6F531AAD64387380@AM2PR02MB0754.eurprd02.prod.outlook.com>

Stephen Kelly gave QQuickListViewPrivate::applyInsertionChange as an
example of "raw" for-loops being tricky to follow:

>>>> There's a `++index` somewhere in the middle 3 scopes deep. Further
>>>> up in the function `index` is assigned, but then assigned again
>>>> (conditionally) from the `count` of a container. Then `index` is
>>>> used later in the function, but I can't reason about what it is
>>>> when it is used.
>>>>
>>>> There are many other problems with that function, which are caused
>>>> by many 'raw' loops nested up to four levels, affecting variables
>>>> assigned outside top-level if() conditions half a page
>>>> up. Extracting such code into named functions would indicate the
>>>> intent of the function.

I've fixed issues in qmake [0] where for-loops caused similar problems.
I *was* able to reason about them, but I made mistakes.  Fortunately, we
have some good disciplines like auto-testing and code-review, that
helped me notice them.

[0] e.g. https://codereview.qt-project.org/#/c/161133

Benjamin TERRIER opined:

>>> I'd boldly reply to that that if one is unwilling to reason about a
>>> piece of code, one should not be fixing it.

and yet, when I am tracking an elusive bug to its lair, I have to make
sense of all the pieces of code that I stumble upon in the course of my
hunt.  I may not be competent to fix it, but I have to be able to make
sense of it to determine *whether* it's the cause of my bug; and, even
if it isn't, I have to make enough sense of it to determine *how* its
eccentricities interact with the rest of the tangle of moving parts that
might be implicated in my bug.  I don't mind having to go to someone
else to get it fixed half as much as I do the problem of having to make
sense of whether it's to blame, when I'm not getting any response to my
e-mail to the author for help determining what part it plays in the bug
I'm chasing.  Each bug I hunt obliges me to make sense of way more
pieces of code than the roughly one that I actually end up having to
fix.

>>> But I'd also agree that the code should be as readable as possible
>>> to get a many developers to contribute.

+1.  Also: to waste as little of my time as possible.

>>> Back to Qt current situation I think that the lack of comments in
>>> some parts is a bigger throwback than the code style.

+1.  Sometimes code is solving a complex problem; then, it likely can't
help but *be* complex.  A gentle dusting of comments (and, in extreme
cases, a big fat overview-and-theory comment somewhere easy to find in
the right file) can go a long way towards helping the visiting
bug-hunter to make sense of the thicket they're stumbling through.

Stephen Kelly gave an example of some code I would complain about in
review, for quite other reasons than those he intended, and then said:

>> It is not possible to reason about code like that.

I attest, for the record, that I can reason about code like that.  Then
again, I came to C++ via a long history of C and some pre-history I'd
rather not talk about.  I know it can get tricky, and I'm glad you
didn't stoop to goto in your example.

>> I have the feeling that faced with code like that, people just don't
>> attempt to reason about it while at the same time trying to get on
>> with what they are trying to do.

There's always some code that's harder than others to make sense of.
Everything should be made as simple as possible - but no simpler.  When
solving a complex problem, the solution is apt to be likewise complex;
as long as its complexity is truly implied by the problem being solved,
this has to be OK.

>> Here's a recent example of a contributor responding exactly that way
>> to such code:

>> https://codereview.qt-project.org/#/c/161133

I fail to see a contributor responding the way you describe: you fixed
the problem - thank you - and you clearly reasoned about the code to do
so.  It ain't pretty, but you found something that worked.

>> The way to deal with functions like that is to extract loops and
>> other concepts into functions with names.

Breaking up long functions into conceptually compact parts is indeed a
recommended practice - and has been for decades.  This is uncontentious.
(Standard practice, in contrast, is some place else entirely - which is
why I do not regard software as an engineering discipline, yet.)

>> Delegating things like that has the effect of making the function
>> shorter. Adding comments instead would not have a positive effect on
>> the size of the function and good names are less likely to bitrot
>> than comments.

Sometimes a function mutates enough to make its name misguided - but
even so, that is more apt to be picked up in code review than comments
going stale.

>> In the above example you would start by extracting a qMaxValue
>> function.

... or just by calling some suitable .max() method on the container, if
it was sensibly defined.  This is a case of a standard pattern that any
API designer should take into account and that client code shouldn't
implement "by hand", as in your example.  The nice thing about the
standard algorithms is that they free container classes from the need to
implement endlessly many methods, such as max; an algorithm can use
standard iteration to implement a generic max.  Someone who needs
max-and-min can do likewise, returning a pair.  Someone who needs to
also know the key (or index) at which max (or min) happened can have a
generic solution using pairs in place of the simple values.  There's a
long long tail of less-often-wanted generics that traditional OO would
have needed to be methods of every container class, with a painful (and
likely jagged) cut-off as different containers vary how far down that
tail they reach.  Generic algorithms get rid of those methods and save
the API designer from needing to decide how far down that tail to ride.

The tricky stuff comes when you need to do something eccentric, like
finding the max but treating -1 or 0 specially (for whatever reason), or
doing something else entirely if the object whose attribute we're
maximising meets some condition on its other members.  For good reasons,
those typically don't fit nicely into the standard patterns; and trying
to shoe-horn them into those patterns tends to implicate traversing the
data-structure more times than you will if you use raw loops (smartly).

>> You could implement that function in terms of std::max_element, or
>> you could write a loop in the function if that's more
>> comfortable. Even in the latter case, it is not a 'raw loop'. You
>> have named a concept and using it will make other code more readable.

Where that is possible, yes - by all means - do that.  Indeed, one good
argument for using the standard patterns is so that raw for loops go
away wherever the code is "essentially straight-forward".  Then any
surviving for loop becomes a clear alert to the presence of something
out of the ordinary - such as essential complexity that we can't get
away from.  Coders still need to learn how to reason about such loops.
Be glad you don't have to cope with the spaghetti that flows from
liberal use of goto.

>> I'm not going to recommend replacing all loops with some Qt version
>> of range adaptors starting tomorrow.
>>
>> There are many small steps which have benefits for readability.

There are many ways we can improve our code-base.  Where changing to use
implementations of standard patterns is one of them, by all means do it.

Jaroslaw Staniek contributed:

> 1. No doubt the algorithms and such improve our programming experience
> and the simplifies activity that costs us most: reading/understanding
> the code and intents.

I agree with your focus: *where* standard implementations of common
patterns *do* help readers make sense of code, they (like anything else
that serves this goal) are welcome.

> 4. I perceive *consistency in naming* as a higher value [...] A
> building block of a project is its internal coding guideline.

It's also worth noting that differences between projects can actually be
helpful: when I'm looking at code in one project (e.g. Qt) that calls
code from another (e.g. OpenSSL), the difference in naming style helps
by alerting me to which bits of the code are "alien" and can't be relied
on to follow the *other* guidelines (behaviour, not just naming) of our
project.  This is an argument against adding STL-style aliases for
methods of our containers *unless* the container really does behave the
way STL containers do - i.e. when someone used to the STL forms
expectations based on STL-normality, due to seeing STL-style method
names on a container, that container had better actually behave fully
like an STL container, or they'll get surprised.

> Engineers are good at switching context once a while, but I am not
> sure they are good at switching it every few seconds.

Context-switches are expensive.  If I am obliged to make many of them
(as is not uncommon when keeping up with the endless stream of code
reviews) I get tired fast.  Fortunately I can take a nap if I have to.


To the extent that Qt Does Things Differently than STL, it is actually a
feature that the two camps name things differently - that cues the
reader in to which idioms to expect will work, based on which naming
scheme is in use.  To the extent Qt Works The Same Way As STL, it's good
to mirror STL naming in the Qt API.

	Eddy.


From edward.welbourne at qt.io  Mon Jul  4 17:21:42 2016
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Mon, 4 Jul 2016 15:21:42 +0000
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <AM2PR02MB0754950AA8E1E6F531AAD64387380@AM2PR02MB0754.eurprd02.prod.outlook.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>,
	<CAOj7QQ2qCQQ2OJXAesUy3phEAwmfE9taAmBa4BrQQWbNGN7KRw@mail.gmail.com>,
	<AM2PR02MB0754950AA8E1E6F531AAD64387380@AM2PR02MB0754.eurprd02.prod.outlook.com>
Message-ID: <AM2PR02MB075411FE9AF4FEB8FF895F6187380@AM2PR02MB0754.eurprd02.prod.outlook.com>

Thanks to Olivier for pointing out a mistake:

> I've fixed issues in qmake [0] where for-loops caused similar problems.
> [0] e.g. https://codereview.qt-project.org/#/c/161133

That should have been:
[0] https://codereview.qt-project.org#/c/141305/14//ALL,unified

        Eddy.


From annulen at yandex.ru  Mon Jul  4 17:47:15 2016
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Mon, 04 Jul 2016 18:47:15 +0300
Subject: [Development] Why QFontDatabase::hasFamily() is marked as internal?
Message-ID: <1431467647235@web4o.yandex.ru>

Hello,

Are there any reasons not to make QFontDatabase::hasFamily() a part of public API?

-- 
Regards,
Konstantin


From gzjjgod at gmail.com  Mon Jul  4 17:59:13 2016
From: gzjjgod at gmail.com (Jiang Jiang)
Date: Mon, 4 Jul 2016 23:59:13 +0800
Subject: [Development] Why QFontDatabase::hasFamily() is marked as
 internal?
In-Reply-To: <1431467647235@web4o.yandex.ru>
References: <1431467647235@web4o.yandex.ru>
Message-ID: <CALhZiQWxYZcc1_kg52M4+7MkVtF38z33epYU=kNpc405aDpMSg@mail.gmail.com>

On Mon, Jul 4, 2016 at 11:47 PM, Konstantin Tokarev <annulen at yandex.ru> wrote:
> Hello,
>
> Are there any reasons not to make QFontDatabase::hasFamily() a part of public API?

Looks like it was originally added for QtWebKit and stayed internal as
is since then.

https://github.com/qt/qtbase/commit/b2553443739f78756ffe0cabc1b02fc62bda09c6

It probably wouldn’t hurt to make it public if it’s useful externally
and someone(tm) is willing to submit a patch adding proper docs.

- Jiang


From mwoehlke.floss at gmail.com  Mon Jul  4 19:26:13 2016
From: mwoehlke.floss at gmail.com (Matthew Woehlke)
Date: Mon, 04 Jul 2016 13:26:13 -0400
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <3399679.28OPHdOIhQ@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>	<2133524.ekmAkN6kfG@tjmaciei-mobl1>
	<5776CEF6.9020603@kdab.com> <3399679.28OPHdOIhQ@tjmaciei-mobl1>
Message-ID: <nle67m$nbl$1@ger.gmane.org>

On 2016-07-01 17:56, Thiago Macieira wrote:
> On sexta-feira, 1 de julho de 2016 22:13:42 PDT Giuseppe D'Angelo wrote:
>> Even today: where is QList::push_back(T&&)? Where are our emplacement
>> functions and their try versions? Where are our exception guarantees?)
> 
> We don't care about exceptions, so we won't be adding those.
> 
> As for the move-versions, since we can't take move-only types in our 
> containers due to the implicit sharing, does it really make a difference if we 
> have them or not?

Yes... and ironically, for the same reason implicit sharing is useful;
because the copy ctor might be horrendously expensive. Emplacement and
move-insert are (also) useful purely from a performance perspective.

> I would prefer the opposite: use non-Qt only if that is better than the Qt 
> equivalent. If you can't prove it or if it's too small, it's not worth the 
> difference in readability that it creates.

Option N+1: Convince the committee to adopt Qt's naming conventions and
convenience API's in STL2¹ ;-).

(¹ Or whatever it's being called...)

-- 
Matthew



From mwoehlke.floss at gmail.com  Mon Jul  4 19:54:45 2016
From: mwoehlke.floss at gmail.com (Matthew Woehlke)
Date: Mon, 04 Jul 2016 13:54:45 -0400
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <201607020842.44832.marc.mutz@kdab.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>	<5159741467402744@web6j.yandex.ru>	<122393150.dApz54YNzL@tjmaciei-mobl1>
	<201607020842.44832.marc.mutz@kdab.com>
Message-ID: <nle7t5$fpo$1@ger.gmane.org>

On 2016-07-02 02:42, Marc Mutz wrote:
> The STL has a great API. push_back() / back() vs. append() / last(), e.g. It 
> just happens to be largely consistent with itself instead of with Qt. But 
> camelCase is not intrinsically "better" than underscored_names, and I also 
> fail to see why first() should be intrinsically superior to front().

TBH, this is the fault of the English language :-). The words that Qt
uses for its API are more intuitive to English speakers, if less
consistent. The words STL uses are more logical¹ and consistent, but
less intuitive.

I've never actually stopped to think about STL being logical¹; every
time I use it, it drives me nuts because the API is not "natural".

(¹ In the sense of "strictly conforming to formal logic".)

Consider... if I ask you what relation the letter 'A' has to the
alphabet, is it the letter *at the front*, or is it the *first* letter?
I bet you, and most (native, certainly) English speakers said it's the
*first* letter. STL's word choices are... a bit like writing code in
King James' English.


I do however feel that Qt's consistent use of verbs for actions and
non-verbs for properties (i.e. empty vs. isEmpty/is_empty) is far superior.

-- 
Matthew



From thiago.macieira at intel.com  Mon Jul  4 22:01:55 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 04 Jul 2016 13:01:55 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <183a8a2c-240e-9afc-5834-f8c68f441eaa@qt.io>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<183a8a2c-240e-9afc-5834-f8c68f441eaa@qt.io>
Message-ID: <3314025.8Kf2oNKqXH@tjmaciei-mobl1>

On segunda-feira, 4 de julho de 2016 09:59:44 PDT Christian Kandeler wrote:
> > The use of the Standard Library member "empty" is highly confusing at
> > first
> > sight because it does not follow the Qt naming guidelines. It's even more
> > confusing because the next line has "isEmpty". When I read this code, I
> > had to wonder if that "empty" was a verb in the imperative, meaning the
> > author was trying to remove all elements from the container.
> 
> I must admit I don't see a problem here. We are not talking about some 
> random third-party library that people are pulling in gratuitously, but 
> about the Standard Library, an integral part of C++ that every developer 
> should be at least generally familiar with.

Of course, I was able to reason what it was after looking up the definition of 
the variable in question. It didn't cost me more than 60 seconds to do this, 
between the wondering "wtf is he doing", forming a hypothesis, proving it, 
then navigating back and then restoring my frame of mind.

The problem is that I do more than one review a day. I would be surprised if 
there are more than 5 people who do more reviews than I do. And I spend less 
than 10% of my week on Qt, so it's important for me and for those whose 
changes I review that I be efficient.

In this particular case, the fact of using a QVector of std::deques completely 
threw me off and I didn't understand the author's intention at all. I had to 
stop the review, which led to this email.

> Having said that, I personally follow the "use Qt types by default" 
> approach, but should we really regard STL containers as dangerous 
> intruders that need to be kept out if at all possible?

No, I agree we should allow them when there's a clear benefit. Qt has no 
equivalent for std::deque and I do think our time is best spent in other 
things than reimplementing one. That is the status quo and Option 4 in my 
list.

But I am thinking of Option 3: use the Standard Library containers (cake) and 
still have our API (eat it too).

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



From thiago.macieira at intel.com  Mon Jul  4 22:03:56 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 04 Jul 2016 13:03:56 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <nle67m$nbl$1@ger.gmane.org>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<3399679.28OPHdOIhQ@tjmaciei-mobl1> <nle67m$nbl$1@ger.gmane.org>
Message-ID: <9113587.zvgDvqfJTn@tjmaciei-mobl1>

On segunda-feira, 4 de julho de 2016 13:26:13 PDT Matthew Woehlke wrote:
> Option N+1: Convince the committee to adopt Qt's naming conventions and
> convenience API's in STL2¹ ;-).
> 
> (¹ Or whatever it's being called...)

We can try, but that is orthogonal to the discussion. Such a standard does not 
exist and will not be usable until at least 2025.

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



From thiago.macieira at intel.com  Mon Jul  4 22:08:23 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 04 Jul 2016 13:08:23 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <nle7t5$fpo$1@ger.gmane.org>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<201607020842.44832.marc.mutz@kdab.com>
	<nle7t5$fpo$1@ger.gmane.org>
Message-ID: <1706543.7KqyZ9rnDB@tjmaciei-mobl1>

On segunda-feira, 4 de julho de 2016 13:54:45 PDT Matthew Woehlke wrote:
> Consider... if I ask you what relation the letter 'A' has to the
> alphabet, is it the letter *at the front*, or is it the *first* letter?
> I bet you, and most (native, certainly) English speakers said it's the
> *first* letter. STL's word choices are... a bit like writing code in
> King James' English.

Hence "push" and "pop" for a stack, "front" and "back" for queues, but not the 
2x2 combination of those on a random-access container...

 > I do however feel that Qt's consistent use of verbs for actions and
> non-verbs for properties (i.e. empty vs. isEmpty/is_empty) is far superior.

Not just verbs for actions, that's verbs in the imperative. We also use verbs, 
but in the past participle, for signals ("changed", "happened", "written", 
except where the English language falls short, like "read / read / read" - 
that's why "readyRead" instead of "bytesRead").

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



From kollix at aon.at  Tue Jul  5 08:40:27 2016
From: kollix at aon.at (Martin Koller)
Date: Tue, 05 Jul 2016 08:40:27 +0200
Subject: [Development] dev branch compile fails module-qtdatavis3d
In-Reply-To: <2156213.PCUHDssgLi@tjmaciei-mobl1>
References: <5970992.y8V6gHAJt6@lapi.koller> <2053372.XPjC1Obgrh@lapi.koller>
	<2156213.PCUHDssgLi@tjmaciei-mobl1>
Message-ID: <5826252.l3ClDsV50f@lapi.koller>

On Saturday 02 July 2016 09:43:51 Thiago Macieira wrote:
> Can you find which .o in QtGui made a reference to 
> qt_version_tag?

Not sure I do it the correct way.. I grepped in objdump -x and find the symbol in all .o files, e.g.:
...
0000000000000000 l       .group 0000000000000000 qt_version_tag
0000000000000000 l    d  .comment       0000000000000000 .comment
0000000000000000 l    d  .group 0000000000000000 .group
0000000000000000         *UND*  0000000000000000 _GLOBAL_OFFSET_TABLE_
0000000000000000         *UND*  0000000000000000 qt_version_tag_WinCC_OA

in .obj/moc_qaccessible.o

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\                        - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at


From thiago.macieira at intel.com  Tue Jul  5 09:24:22 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 05 Jul 2016 00:24:22 -0700
Subject: [Development] dev branch compile fails module-qtdatavis3d
In-Reply-To: <5826252.l3ClDsV50f@lapi.koller>
References: <5970992.y8V6gHAJt6@lapi.koller>
	<2156213.PCUHDssgLi@tjmaciei-mobl1>
	<5826252.l3ClDsV50f@lapi.koller>
Message-ID: <24170234.u22TmC7dJm@tjmaciei-mobl1>

On terça-feira, 5 de julho de 2016 08:40:27 PDT Martin Koller wrote:
> On Saturday 02 July 2016 09:43:51 Thiago Macieira wrote:
> > Can you find which .o in QtGui made a reference to
> > qt_version_tag?
> 
> Not sure I do it the correct way.. I grepped in objdump -x and find the

> 0000000000000000         *UND*  0000000000000000 qt_version_tag_WinCC_OA

That's qt_version-tag_WinCC_OA. Please find the .o that refers to 
qt_version_tag, without suffix.

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



From kollix at aon.at  Tue Jul  5 19:57:44 2016
From: kollix at aon.at (Martin Koller)
Date: Tue, 05 Jul 2016 19:57:44 +0200
Subject: [Development] dev branch compile fails module-qtdatavis3d
In-Reply-To: <24170234.u22TmC7dJm@tjmaciei-mobl1>
References: <5970992.y8V6gHAJt6@lapi.koller> <5826252.l3ClDsV50f@lapi.koller>
	<24170234.u22TmC7dJm@tjmaciei-mobl1>
Message-ID: <2813808.n314I7OqCj@lapi.koller>

On Tuesday 05 July 2016 00:24:22 Thiago Macieira wrote:
> On terça-feira, 5 de julho de 2016 08:40:27 PDT Martin Koller wrote:
> > On Saturday 02 July 2016 09:43:51 Thiago Macieira wrote:
> > > Can you find which .o in QtGui made a reference to
> > > qt_version_tag?
> > 
> > Not sure I do it the correct way.. I grepped in objdump -x and find the
> 
> > 0000000000000000         *UND*  0000000000000000 qt_version_tag_WinCC_OA
> 
> That's qt_version-tag_WinCC_OA. Please find the .o that refers to 
> qt_version_tag, without suffix.

I thought maybe the .group thingy
0000000000000000 l       .group 0000000000000000 qt_version_tag
is something interesting ...

I did now a grep in all dirs (not only src/gui) and found:
The files below ./3rdparty/harfbuzz-ng have
0000000000000000         *UND*  0000000000000000 qt_version_tag
0000000000000000 R_X86_64_GOT64    qt_version_tag

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\                        - against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at


From thiago.macieira at intel.com  Tue Jul  5 22:04:10 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 05 Jul 2016 13:04:10 -0700
Subject: [Development] dev branch compile fails module-qtdatavis3d
In-Reply-To: <2813808.n314I7OqCj@lapi.koller>
References: <5970992.y8V6gHAJt6@lapi.koller>
	<24170234.u22TmC7dJm@tjmaciei-mobl1>
	<2813808.n314I7OqCj@lapi.koller>
Message-ID: <4517176.GaT8XqCht6@tjmaciei-mobl1>

On terça-feira, 5 de julho de 2016 19:57:44 PDT Martin Koller wrote:
> I did now a grep in all dirs (not only src/gui) and found:
> The files below ./3rdparty/harfbuzz-ng have
> 0000000000000000         *UND*  0000000000000000 qt_version_tag
> 0000000000000000 R_X86_64_GOT64    qt_version_tag

Thanks, that is actually important.

Does the Makefile for harfbuzz have -DQT_NAMESPACE=WinCC_OA?

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



From thiago.macieira at intel.com  Tue Jul  5 22:12:40 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 05 Jul 2016 13:12:40 -0700
Subject: [Development] dev branch compile fails module-qtdatavis3d
In-Reply-To: <4517176.GaT8XqCht6@tjmaciei-mobl1>
References: <5970992.y8V6gHAJt6@lapi.koller> <2813808.n314I7OqCj@lapi.koller>
	<4517176.GaT8XqCht6@tjmaciei-mobl1>
Message-ID: <10094212.LE6bgoFnJb@tjmaciei-mobl1>

On terça-feira, 5 de julho de 2016 13:04:10 PDT Thiago Macieira wrote:
> On terça-feira, 5 de julho de 2016 19:57:44 PDT Martin Koller wrote:
> > I did now a grep in all dirs (not only src/gui) and found:
> > The files below ./3rdparty/harfbuzz-ng have
> > 0000000000000000         *UND*  0000000000000000 qt_version_tag
> > 0000000000000000 R_X86_64_GOT64    qt_version_tag
> 
> Thanks, that is actually important.
> 
> Does the Makefile for harfbuzz have -DQT_NAMESPACE=WinCC_OA?

Try this fix:
https://codereview.qt-project.org/164425

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



From marc.mutz at kdab.com  Wed Jul  6 11:08:22 2016
From: marc.mutz at kdab.com (Marc Mutz)
Date: Wed, 6 Jul 2016 11:08:22 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <nlanuv$2sv$1@ger.gmane.org>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<4490054.sMN0YLkbx6@tjmaciei-mobl1> <nlanuv$2sv$1@ger.gmane.org>
Message-ID: <201607061108.23855.marc.mutz@kdab.com>

On Sunday 03 July 2016 12:04:14 Stephen Kelly wrote:
> It is not possible to reason about code like that. I have the feeling that 
> faced with code like that, people just don't attempt to reason about it 
> while at the same time trying to get on with what they are trying to do.

The underlying theme here, I think, is: idiomatic code. Qt has its set of 
idioms (like ending QObject subclass ctors in QObject *parent=nullptr), but it 
largely ignores C++ idioms. And that leads to complicated code and throws off 
contributors that are used to idiomatic C++.

Take this example:

https://codereview.qt-project.org/159693

The copy-swap idiom is two decades old (at least as old as Effective C++ 
ed. 1), but the only uses in Qt are those that I introduced myself. Following 
the idiom trivialises the implementation of both copy and move assignment 
operators. Not following it leads to bugs such as the one linked above.

Using algorithms is idiomatic. too: erase-remove is an idiom, also nearing two 
decades old. It reduces bugs, and helps grok the code for those that know the 
idioms, but, like in any other language, if you don't know the idioms, you 
don't really understand the language.

C++ is the language Qt is written in. You need to learn the language's idioms.

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts


From announce at qt-project.org  Wed Jul  6 11:18:13 2016
From: announce at qt-project.org (List for announcements regarding Qt releases and development)
Date: Wed, 6 Jul 2016 09:18:13 +0000
Subject: [Development] [Announce] Qt Creator 4.1.0 Beta1 released
Message-ID: <mailman.352.1467796696.23668.announce@qt-project.org>

We are happy to announce the release of Qt Creator 4.1.0 Beta1!

https://blog.qt.io/blog/2016/07/06/qt-creator-4-1-0-beta-released/

Br, 
-- 
Eike Ziller
Principal Software Engineer

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



_______________________________________________
Announce mailing list
Announce at qt-project.org
http://lists.qt-project.org/mailman/listinfo/announce

From thiago.macieira at intel.com  Wed Jul  6 17:52:18 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 06 Jul 2016 08:52:18 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <201607061108.23855.marc.mutz@kdab.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1> <nlanuv$2sv$1@ger.gmane.org>
	<201607061108.23855.marc.mutz@kdab.com>
Message-ID: <1838403.mAHyQTJ32t@tjmaciei-mobl1>

On quarta-feira, 6 de julho de 2016 11:08:22 PDT Marc Mutz wrote:
> The underlying theme here, I think, is: idiomatic code. Qt has its set of 
> idioms (like ending QObject subclass ctors in QObject *parent=nullptr), but
> it  largely ignores C++ idioms. And that leads to complicated code and
> throws off contributors that are used to idiomatic C++.
[cut]
> C++ is the language Qt is written in. You need to learn the language's
> idioms.

I dispute calling them "C++ idioms". Can you prove that all other major C++ 
libraries except Qt use them? For example, Google code, Folly, etc. Do they 
all use those idioms? Are their developers familiar with it?

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



From thiago.macieira at intel.com  Thu Jul  7 03:00:08 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 06 Jul 2016 18:00:08 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <2133524.ekmAkN6kfG@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<2133524.ekmAkN6kfG@tjmaciei-mobl1>
Message-ID: <1775643.FonJhWLViK@tjmaciei-mobl1>

On sexta-feira, 1 de julho de 2016 12:34:15 PDT Thiago Macieira wrote:
> On sexta-feira, 1 de julho de 2016 11:36:56 PDT Thiago Macieira wrote:
> > Option 1:
> > Not use Standard Library containers, just use the Qt containers as they
> > exist.
> > 
> > Option 2:
> > Create new Qt containers to have the same complexity as Standard Library
> > containers, but following the Qt naming conventions. Possibly with
> > implicit
> > sharing.
> > 
> > Option 3:
> > Create Qt API wrappers for those containers like std::deque, adding only a
> > few  inline functions to match the Qt-style API where the Standard Library
> > 
> > API deviates. Examples are:
> >         empty           ->      isEmpty
> >         push_back       ->      append
> >         front           ->      first
> >         pop_front       ->      takeFirst
> >         cbegin          ->      constBegin
> >         cfind           ->      constFind
> 
> Of course, Option 4:
> Continue to allow Standard Library containers in internal code (no API or
> ABI constraining) where there's a clear gain in performance and/or size.
> 
> Option 5:
> Allow Standard Library containers in internal code even if performance or
> code size gains are not appreciable or have not been measured.

Concluding this thread:

The opinions are pretty much evenly split among the respondents, so for now 
we'll remain at status quo (Option 4).

In case we're not getting the deserved attention due to Summer vacations, I'll 
post again in a month or so to see if there's any change.

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



From marc.mutz at kdab.com  Thu Jul  7 09:10:50 2016
From: marc.mutz at kdab.com (Marc Mutz)
Date: Thu, 7 Jul 2016 09:10:50 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <1775643.FonJhWLViK@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<2133524.ekmAkN6kfG@tjmaciei-mobl1>
	<1775643.FonJhWLViK@tjmaciei-mobl1>
Message-ID: <201607070910.51615.marc.mutz@kdab.com>

On Thursday 07 July 2016 03:00:08 Thiago Macieira wrote:
> In case we're not getting the deserved attention due to Summer vacations,
> I'll  post again in a month or so to see if there's any change.

We have The Chief on record saying that we should use whatever is most efficient 
internally  (https://codereview.qt-project.org/114327 comment from 
2015-06-15), and you agreeing (ibid, 1st @ 2015-06-16).

So from my pov, the only question is whether we stay with Option 4 or relax to 
Option 5, and I'm fine with either.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts


From andre at familiesomers.nl  Thu Jul  7 09:20:10 2016
From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=)
Date: Thu, 7 Jul 2016 09:20:10 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <201607070910.51615.marc.mutz@kdab.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<2133524.ekmAkN6kfG@tjmaciei-mobl1> <1775643.FonJhWLViK@tjmaciei-mobl1>
	<201607070910.51615.marc.mutz@kdab.com>
Message-ID: <c65d0c5f-3211-6b4b-dc37-3b56208cf93d@familiesomers.nl>



Op 07/07/2016 om 09:10 schreef Marc Mutz:
> On Thursday 07 July 2016 03:00:08 Thiago Macieira wrote:
>> In case we're not getting the deserved attention due to Summer vacations,
>> I'll  post again in a month or so to see if there's any change.
> We have The Chief on record saying that we should use whatever is most efficient
> internally  (https://codereview.qt-project.org/114327 comment from
> 2015-06-15), and you agreeing (ibid, 1st @ 2015-06-16).
>
> So from my pov, the only question is whether we stay with Option 4 or relax to
> Option 5, and I'm fine with either.
>
I don't think that rules out option 3 either, does it?

André


From Martin.Smith at qt.io  Thu Jul  7 09:25:18 2016
From: Martin.Smith at qt.io (Martin Smith)
Date: Thu, 7 Jul 2016 07:25:18 +0000
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <c65d0c5f-3211-6b4b-dc37-3b56208cf93d@familiesomers.nl>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<2133524.ekmAkN6kfG@tjmaciei-mobl1> <1775643.FonJhWLViK@tjmaciei-mobl1>
	<201607070910.51615.marc.mutz@kdab.com>,
	<c65d0c5f-3211-6b4b-dc37-3b56208cf93d@familiesomers.nl>
Message-ID: <DB5PR0201MB1607D44C66FF5DC63798AA3D9F3B0@DB5PR0201MB1607.eurprd02.prod.outlook.com>


How about a merger of options 3 & 4 for Qt 6.0? A QtSTL that combines the ease of use of the Qt collections with the efficiency of STL algorithms.


martin

________________________________
From: Development <development-bounces+martin.smith=qt.io at qt-project.org> on behalf of André Somers <andre at familiesomers.nl>
Sent: Thursday, July 7, 2016 9:20:10 AM
To: development at qt-project.org
Subject: Re: [Development] Use of Standard Library containers in Qt source code



Op 07/07/2016 om 09:10 schreef Marc Mutz:
> On Thursday 07 July 2016 03:00:08 Thiago Macieira wrote:
>> In case we're not getting the deserved attention due to Summer vacations,
>> I'll  post again in a month or so to see if there's any change.
> We have The Chief on record saying that we should use whatever is most efficient
> internally  (https://codereview.qt-project.org/114327 comment from
> 2015-06-15), and you agreeing (ibid, 1st @ 2015-06-16).
>
> So from my pov, the only question is whether we stay with Option 4 or relax to
> Option 5, and I'm fine with either.
>
I don't think that rules out option 3 either, does it?

André
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160707/2a82077f/attachment.html>

From dangelog at gmail.com  Thu Jul  7 10:39:21 2016
From: dangelog at gmail.com (Giuseppe D'Angelo)
Date: Thu, 7 Jul 2016 10:39:21 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <DB5PR0201MB1607D44C66FF5DC63798AA3D9F3B0@DB5PR0201MB1607.eurprd02.prod.outlook.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<2133524.ekmAkN6kfG@tjmaciei-mobl1>
	<1775643.FonJhWLViK@tjmaciei-mobl1>
	<201607070910.51615.marc.mutz@kdab.com>
	<c65d0c5f-3211-6b4b-dc37-3b56208cf93d@familiesomers.nl>
	<DB5PR0201MB1607D44C66FF5DC63798AA3D9F3B0@DB5PR0201MB1607.eurprd02.prod.outlook.com>
Message-ID: <CAPm+cviFxixvYf6JmcyhM66OTnzYMDAiXakA4699HoySdBEWzg@mail.gmail.com>

On Thu, Jul 7, 2016 at 9:25 AM, Martin Smith <Martin.Smith at qt.io> wrote:
>
> How about a merger of options 3 & 4 for Qt 6.0? A QtSTL that combines the
> ease of use of the Qt collections with the efficiency of STL algorithms.

If anything, why would it need to wait for Qt 6?

-- 
Giuseppe D'Angelo


From marc.mutz at kdab.com  Thu Jul  7 11:36:57 2016
From: marc.mutz at kdab.com (Marc Mutz)
Date: Thu, 7 Jul 2016 11:36:57 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <DB5PR0201MB1607D44C66FF5DC63798AA3D9F3B0@DB5PR0201MB1607.eurprd02.prod.outlook.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<c65d0c5f-3211-6b4b-dc37-3b56208cf93d@familiesomers.nl>
	<DB5PR0201MB1607D44C66FF5DC63798AA3D9F3B0@DB5PR0201MB1607.eurprd02.prod.outlook.com>
Message-ID: <201607071136.59540.marc.mutz@kdab.com>

On Thursday 07 July 2016 09:25:18 Martin Smith wrote:
> How about a merger of options 3 & 4 for Qt 6.0? A QtSTL that combines the
> ease of use of the Qt collections with the efficiency of STL algorithms.

Yes, for Qt 6, a template that takes an STL API and provides the Qt methods on 
it is something I'd welcome. But not to be required in internal 
implementation, as is implied in this thread. Game devs on CppCon report that 
compilers have problems fully inlining STL container use where it should be 
fully inlined (I myself ran into such a case: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621)

We use STL containers because they are more friendly to the compiler[1], which 
equates to faster and/or smaller, adding more stuff on top will make them 
slower, unless we fiddle with compiler-specific settings such as inlining 
depths, if that helps at all (it didn't for the bug report linked above).

Thanks,
Marc

[1] I don't think everyone here knows that every asm volatile as part of a 
QAtomic operation makes the compiler forget everything it knows about memory / 
value propagation, ie. it writes back registers to memory before and needs to 
re-load values from memory after the asm volatile. It gets better if QAtomic 
is backed by std::atomic, but even on x86, those ops aren't cheap. A cmpxchg 
takes more than 200 cycles to complete, if the memory is off-socket, compared 
to ≤ 0.5 cycles for a reg-reg operation. That's only the case if the object is 
actually shared among processors, but it shows just how bad it can be. On-die, 
it's still something like 20 cycles.


-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts


From denis.shienkov at gmail.com  Thu Jul  7 11:50:51 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Thu, 7 Jul 2016 12:50:51 +0300
Subject: [Development] Configurable Maintenance Tool
Message-ID: <CAHtcb0wravGf9wuXnCjusXu+zeRhstB7UHUx_wFQ3vr-_bKkaQ@mail.gmail.com>

Hi All,

Is it possible to make the Maintenance Tool utility is more configurable?
Or, maybe, is it planned in future?

e.g. I want to able to add/remove some modules by own choosing:

- QtMultimedia
- QtConnectivity
- QtSerialPort

and so on..

But, currently the Maintenance Tool does not provide this feature, and
I remove all desired "unused" modules "by hand"...

BR,
Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160707/b923a2d0/attachment.html>

From Marco.Bubke at qt.io  Thu Jul  7 12:06:05 2016
From: Marco.Bubke at qt.io (Marco Bubke)
Date: Thu, 7 Jul 2016 10:06:05 +0000
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <DB5PR0201MB1607D44C66FF5DC63798AA3D9F3B0@DB5PR0201MB1607.eurprd02.prod.outlook.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<2133524.ekmAkN6kfG@tjmaciei-mobl1> <1775643.FonJhWLViK@tjmaciei-mobl1>
	<201607070910.51615.marc.mutz@kdab.com>,
	<c65d0c5f-3211-6b4b-dc37-3b56208cf93d@familiesomers.nl>,
	<DB5PR0201MB1607D44C66FF5DC63798AA3D9F3B0@DB5PR0201MB1607.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB1652BE25DB1BDF0F86B93840F03B0@AM4PR02MB1652.eurprd02.prod.outlook.com>

I think it simply a question of time to get used to the STL. You get used to many things.


I think we should mind about the new features of C++ which are coming, which cannot integrated very well with Qt because we use a different idiom.


I really think we should make it easier for the developer but if we provide no way to go the fast path do we really make it easier?


If the context is changing over time, is it not smart to reevaluate decision again and maybe go a different route? I don't mean to do it all the time but maybe there is a middle path between different "fundamentalisms". [😉]

________________________________
From: Development <development-bounces+marco.bubke=qt.io at qt-project.org> on behalf of Martin Smith <Martin.Smith at qt.io>
Sent: Thursday, July 7, 2016 9:25:18 AM
To: André Somers; development at qt-project.org
Subject: Re: [Development] Use of Standard Library containers in Qt source code



How about a merger of options 3 & 4 for Qt 6.0? A QtSTL that combines the ease of use of the Qt collections with the efficiency of STL algorithms.


martin

________________________________
From: Development <development-bounces+martin.smith=qt.io at qt-project.org> on behalf of André Somers <andre at familiesomers.nl>
Sent: Thursday, July 7, 2016 9:20:10 AM
To: development at qt-project.org
Subject: Re: [Development] Use of Standard Library containers in Qt source code



Op 07/07/2016 om 09:10 schreef Marc Mutz:
> On Thursday 07 July 2016 03:00:08 Thiago Macieira wrote:
>> In case we're not getting the deserved attention due to Summer vacations,
>> I'll  post again in a month or so to see if there's any change.
> We have The Chief on record saying that we should use whatever is most efficient
> internally  (https://codereview.qt-project.org/114327 comment from
> 2015-06-15), and you agreeing (ibid, 1st @ 2015-06-16).
>
> So from my pov, the only question is whether we stay with Option 4 or relax to
> Option 5, and I'm fine with either.
>
I don't think that rules out option 3 either, does it?

André
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160707/4d2a2cf2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OutlookEmoji-😉.png
Type: image/png
Size: 390 bytes
Desc: OutlookEmoji-😉.png
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160707/4d2a2cf2/attachment.png>

From konstantin at podsvirov.pro  Thu Jul  7 12:14:45 2016
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Thu, 07 Jul 2016 13:14:45 +0300
Subject: [Development] Configurable Maintenance Tool
In-Reply-To: <CAHtcb0wravGf9wuXnCjusXu+zeRhstB7UHUx_wFQ3vr-_bKkaQ@mail.gmail.com>
References: <CAHtcb0wravGf9wuXnCjusXu+zeRhstB7UHUx_wFQ3vr-_bKkaQ@mail.gmail.com>
Message-ID: <2756971467886485@web9g.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160707/4589117e/attachment.html>

From thiago.macieira at intel.com  Thu Jul  7 09:20:07 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 07 Jul 2016 00:20:07 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <201607070910.51615.marc.mutz@kdab.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<1775643.FonJhWLViK@tjmaciei-mobl1>
	<201607070910.51615.marc.mutz@kdab.com>
Message-ID: <9830555.ImG14tleL6@tjmaciei-mobl1>

On quinta-feira, 7 de julho de 2016 09:10:50 PDT Marc Mutz wrote:
> On Thursday 07 July 2016 03:00:08 Thiago Macieira wrote:
> > In case we're not getting the deserved attention due to Summer vacations,
> > I'll  post again in a month or so to see if there's any change.
> 
> We have The Chief on record saying that we should use whatever is most
> efficient internally  (https://codereview.qt-project.org/114327 comment
> from 2015-06-15), and you agreeing (ibid, 1st @ 2015-06-16).

He hasn't chimed in on this discussion, which makes me wonder if he's out for 
vacations.

> So from my pov, the only question is whether we stay with Option 4 or relax
> to Option 5, and I'm fine with either.

For me, it's whether we stay with 4 or write the classes from Option 3.


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



From ci.monitoring at qt.io  Fri Jul  8 11:58:19 2016
From: ci.monitoring at qt.io (Ci Monitoring)
Date: Fri, 8 Jul 2016 09:58:19 +0000
Subject: [Development] monitoring of CI servers
Message-ID: <DB6PR0201MB239022D9331AFDDF7842F18B973C0@DB6PR0201MB2390.eurprd02.prod.outlook.com>

Hi,

For your information, Qt Continuous Integration (CI) servers are monitored 24/7. However, if you notice any problems in Qt CI systems, please send email to this address: ci.monitoring at qt.io<mailto:ci.monitoring at qt.io>. Out of Eastern European Time Zone<https://www.google.fi/search?client=firefox-b&q=Eastern+European+Time&stick=H4sIAAAAAAAAAONgVuLUz9U3MC7ISUsBAO3VLp4NAAAA> office hours there might be slight delay. Thank you for understanding.

Br, Qt team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160708/ef684bad/attachment.html>

From swarit.wipra at gmail.com  Sat Jul  9 20:01:19 2016
From: swarit.wipra at gmail.com (swarit wipra)
Date: Sat, 9 Jul 2016 23:31:19 +0530
Subject: [Development] QTableView gets freezed in showing data read from
 SQLite database , which is updated dynamically with 2000 rows in 2s
Message-ID: <CAMNhMCiyD_guwn2QOiVZxgSSey8WcJK8aX-TWREB+D5i4KannA@mail.gmail.com>

Hi folks,

i have issues in showing huge data in QTableView ,data read from sqlite
database which is being updated dynamically .. 2k rows in 2s.
i am using QSQLRelationModel
let me describe the scenario in detail.

My Qt application has a view i.e QTableView , each row has following
structure:

 ****************************************
 *QPushButton*|QLabel | QLabel | QLabel *
 ****************************************
 i have created it using QItemDelegate

 each row isinserted dynamicaly , after sometime gui gets freezed.

could anyone tell me the way to fix the issue.

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160709/4752a8f1/attachment.html>

From milian.wolff at kdab.com  Sun Jul 10 13:25:48 2016
From: milian.wolff at kdab.com (Milian Wolff)
Date: Sun, 10 Jul 2016 13:25:48 +0200
Subject: [Development] QTableView gets freezed in showing data read from
 SQLite database , which is updated dynamically with 2000 rows in 2s
In-Reply-To: <CAMNhMCiyD_guwn2QOiVZxgSSey8WcJK8aX-TWREB+D5i4KannA@mail.gmail.com>
References: <CAMNhMCiyD_guwn2QOiVZxgSSey8WcJK8aX-TWREB+D5i4KannA@mail.gmail.com>
Message-ID: <2419699.p3rdbzShFY@agathebauer>

On Samstag, 9. Juli 2016 23:31:19 CEST swarit wipra wrote:
> Hi folks,
> 
> i have issues in showing huge data in QTableView ,data read from sqlite
> database which is being updated dynamically .. 2k rows in 2s.
> i am using QSQLRelationModel
> let me describe the scenario in detail.
> 
> My Qt application has a view i.e QTableView , each row has following
> structure:
> 
>  ****************************************
>  *QPushButton*|QLabel | QLabel | QLabel *
>  ****************************************
>  i have created it using QItemDelegate
> 
>  each row isinserted dynamicaly , after sometime gui gets freezed.
> 
> could anyone tell me the way to fix the issue.

Profile the code, find the hotspot, fix it.

From the above, it becomes clear already that you should not be using QLabel 
for plain text delegates but rather the default delegate.

Bye

-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5903 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160710/06ae2f0a/attachment.bin>

From olszak.tomasz at gmail.com  Mon Jul 11 11:38:06 2016
From: olszak.tomasz at gmail.com (Tomasz Olszak)
Date: Mon, 11 Jul 2016 10:38:06 +0100
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
Message-ID: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>

Hello,

QImage:: transformed(const QTransform &matrix, Qt::TransformationMode mode
= Qt::FastTransformation) docs:

"Returns a copy of the image that is transformed using the given
transformation matrix and transformation mode."

But if matrix.type() == QTransform::TxNone then shallow instead of deep
copy is returned.

I'm happy to submit a fix but I don't know what is expected behaviour?
Should implementation follow docs or docs or docs follow implementation
here?

T.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160711/2071d96d/attachment.html>

From Simon.Hausmann at qt.io  Mon Jul 11 11:59:34 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Mon, 11 Jul 2016 09:59:34 +0000
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
Message-ID: <DB4PR02MB0541D51424FC79CBA6EA6A448C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>

Hi,


Could you elaborate on what you see as the discrepancy between docs and implementation? The docs don't say whether

it's a shallow or a deep copy, so it looks to me that the implementation is within the bounds of the docs.


Plus it seems sensible to return a shallow copy, doesn't it?



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Tomasz Olszak <olszak.tomasz at gmail.com>
Sent: Monday, July 11, 2016 11:38:06 AM
To: development at qt-project.org
Subject: [Development] QImage::transformed returns shallow copy for QTransform::TxNone matrix type.

Hello,

QImage:: transformed(const QTransform &matrix, Qt::TransformationMode mode = Qt::FastTransformation) docs:

"Returns a copy of the image that is transformed using the given transformation matrix and transformation mode."

But if matrix.type() == QTransform::TxNone then shallow instead of deep copy is returned.

I'm happy to submit a fix but I don't know what is expected behaviour? Should implementation follow docs or docs or docs follow implementation here?

T.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160711/06fea613/attachment.html>

From olszak.tomasz at gmail.com  Mon Jul 11 12:53:51 2016
From: olszak.tomasz at gmail.com (Tomasz Olszak)
Date: Mon, 11 Jul 2016 11:53:51 +0100
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <DB4PR02MB0541D51424FC79CBA6EA6A448C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<DB4PR02MB0541D51424FC79CBA6EA6A448C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
Message-ID: <CAGuVYzCSvhwR7rRTyX8i7gnjuCD=MTGcU-jL7GFmspKVmXADOg@mail.gmail.com>

QImage::copy returns deep copy and has similar documentation so I assumed
that when docs say copy it means deep copy.

Let's consider common case:

1. QImage img created from raw data pointer got from e.g. driver.
2. img used in thread to perform some transforms
3. Save result as deep copy

Ensuring step 3 is most efficient and does not perform unnecessary copying
I need to write something like:

QTransform t;
if (m.type() == QTransform::TxNone)
    return img.copy();
else
    return img.transformed(m);

AFAIU img.transformed(m).copy() will copy twice when  m.type() !=
QTransform::TxNone right?

Don't you think that is seems strange and is not documented enough?

2016-07-11 10:59 GMT+01:00 Simon Hausmann <Simon.Hausmann at qt.io>:

> Hi,
>
>
> Could you elaborate on what you see as the discrepancy between docs and
> implementation? The docs don't say whether
>
> it's a shallow or a deep copy, so it looks to me that the implementation
> is within the bounds of the docs.
>
>
> Plus it seems sensible to return a shallow copy, doesn't it?
>
>
>
> Simon
> ------------------------------
> *From:* Development <development-bounces+simon.hausmann=
> qt.io at qt-project.org> on behalf of Tomasz Olszak <olszak.tomasz at gmail.com>
> *Sent:* Monday, July 11, 2016 11:38:06 AM
> *To:* development at qt-project.org
> *Subject:* [Development] QImage::transformed returns shallow copy for
> QTransform::TxNone matrix type.
>
> Hello,
>
> QImage:: transformed(const QTransform &matrix, Qt::TransformationMode mode
> = Qt::FastTransformation) docs:
>
> "Returns a copy of the image that is transformed using the given
> transformation matrix and transformation mode."
>
> But if matrix.type() == QTransform::TxNone then shallow instead of deep
> copy is returned.
>
> I'm happy to submit a fix but I don't know what is expected behaviour?
> Should implementation follow docs or docs or docs follow implementation
> here?
>
> T.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160711/706a80e0/attachment.html>

From Simon.Hausmann at qt.io  Mon Jul 11 13:10:13 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Mon, 11 Jul 2016 11:10:13 +0000
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <CAGuVYzCSvhwR7rRTyX8i7gnjuCD=MTGcU-jL7GFmspKVmXADOg@mail.gmail.com>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<DB4PR02MB0541D51424FC79CBA6EA6A448C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>,
	<CAGuVYzCSvhwR7rRTyX8i7gnjuCD=MTGcU-jL7GFmspKVmXADOg@mail.gmail.com>
Message-ID: <DB4PR02MB05418CA69FA81BF3B35C3DE18C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>

Hi,


Thank you for the explanation of your use-case. What remains unclear to me is why it is necessary for you to ensure a deep copy?


Is it related to the fact that your image is created from a raw data pointer and after your worker thread is done, you cannot guarantee

for the life-time of the raw data anymore?


Perhaps you could use the QImage constructor that takes a cleanup function (and cleanupInfo pointer). If your worker thread

ends up making a copy of the image data as a result of your transformation, then your original copy can and will be deleted

when you discard the source of the transform() call. That is something that you can keep track of. Vice-versa if it's not being called,

then you know that transformed() (or generally speaking _any_ sequence of operations you may have done) still operate on a shallow

copy. Then you can do an explicit deep copy.


Generally speaking my impression - assuming I did understand your use-case correctly - is that your problem stems from the unknown

life-cycle of your data. I don't think the behavior of QImage::transformed() should be made worse for the common case where shallow

copying benefits performance and memory consumption.


Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Tomasz Olszak <olszak.tomasz at gmail.com>
Sent: Monday, July 11, 2016 12:53:51 PM
To: development at qt-project.org
Subject: Re: [Development] QImage::transformed returns shallow copy for QTransform::TxNone matrix type.

QImage::copy returns deep copy and has similar documentation so I assumed that when docs say copy it means deep copy.

Let's consider common case:

1. QImage img created from raw data pointer got from e.g. driver.
2. img used in thread to perform some transforms
3. Save result as deep copy

Ensuring step 3 is most efficient and does not perform unnecessary copying I need to write something like:

QTransform t;
if (m.type() == QTransform::TxNone)
    return img.copy();
else
    return img.transformed(m);

AFAIU img.transformed(m).copy() will copy twice when  m.type() != QTransform::TxNone right?

Don't you think that is seems strange and is not documented enough?

2016-07-11 10:59 GMT+01:00 Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>>:

Hi,


Could you elaborate on what you see as the discrepancy between docs and implementation? The docs don't say whether

it's a shallow or a deep copy, so it looks to me that the implementation is within the bounds of the docs.


Plus it seems sensible to return a shallow copy, doesn't it?



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:qt.io at qt-project.org>> on behalf of Tomasz Olszak <olszak.tomasz at gmail.com<mailto:olszak.tomasz at gmail.com>>
Sent: Monday, July 11, 2016 11:38:06 AM
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: [Development] QImage::transformed returns shallow copy for QTransform::TxNone matrix type.

Hello,

QImage:: transformed(const QTransform &matrix, Qt::TransformationMode mode = Qt::FastTransformation) docs:

"Returns a copy of the image that is transformed using the given transformation matrix and transformation mode."

But if matrix.type() == QTransform::TxNone then shallow instead of deep copy is returned.

I'm happy to submit a fix but I don't know what is expected behaviour? Should implementation follow docs or docs or docs follow implementation here?

T.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160711/9d2124eb/attachment.html>

From olszak.tomasz at gmail.com  Mon Jul 11 13:40:25 2016
From: olszak.tomasz at gmail.com (Tomasz Olszak)
Date: Mon, 11 Jul 2016 12:40:25 +0100
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <DB4PR02MB05418CA69FA81BF3B35C3DE18C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<DB4PR02MB0541D51424FC79CBA6EA6A448C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<CAGuVYzCSvhwR7rRTyX8i7gnjuCD=MTGcU-jL7GFmspKVmXADOg@mail.gmail.com>
	<DB4PR02MB05418CA69FA81BF3B35C3DE18C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
Message-ID: <CAGuVYzDOgMiCDqdOnyDXa8pxmOjb8RYUDw=CQwECLMDbb=-Z2g@mail.gmail.com>

The pointer comes from external object and it's lifetime is managed by it.
I need to ensure that I will not use it anymore after leaving certain
function. Hence it don't even need to be thread operation, So using clean
function won't help here.

The problem here is that you can't say if transformed returns shallow or
deep copy. Result depends on argument value. Of course the transform
returning shallow copy on identity matrix is nice but should be documented
somewhere. After reading docs I expected deep copy like from copy function.
But maybe it's only me :)

Thanks for profound explanation.


2016-07-11 12:10 GMT+01:00 Simon Hausmann <Simon.Hausmann at qt.io>:

> Hi,
>
>
> Thank you for the explanation of your use-case. What remains unclear to me
> is why it is necessary for you to ensure a deep copy?
>
>
> Is it related to the fact that your image is created from a raw data
> pointer and after your worker thread is done, you cannot guarantee
>
> for the life-time of the raw data anymore?
>
>
> Perhaps you could use the QImage constructor that takes a cleanup function
> (and cleanupInfo pointer). If your worker thread
>
> ends up making a copy of the image data as a result of your
> transformation, then your original copy can and will be deleted
>
> when you discard the source of the transform() call. That is something
> that you can keep track of. Vice-versa if it's not being called,
>
> then you know that transformed() (or generally speaking _any_ sequence of
> operations you may have done) still operate on a shallow
>
> copy. Then you can do an explicit deep copy.
>
>
> Generally speaking my impression - assuming I did understand your use-case
> correctly - is that your problem stems from the unknown
>
> life-cycle of your data. I don't think the behavior of
> QImage::transformed() should be made worse for the common case where shallow
>
> copying benefits performance and memory consumption.
>
>
> Simon
> ------------------------------
> *From:* Development <development-bounces+simon.hausmann=
> qt.io at qt-project.org> on behalf of Tomasz Olszak <olszak.tomasz at gmail.com>
> *Sent:* Monday, July 11, 2016 12:53:51 PM
> *To:* development at qt-project.org
> *Subject:* Re: [Development] QImage::transformed returns shallow copy for
> QTransform::TxNone matrix type.
>
> QImage::copy returns deep copy and has similar documentation so I assumed
> that when docs say copy it means deep copy.
>
> Let's consider common case:
>
> 1. QImage img created from raw data pointer got from e.g. driver.
> 2. img used in thread to perform some transforms
> 3. Save result as deep copy
>
> Ensuring step 3 is most efficient and does not perform unnecessary copying
> I need to write something like:
>
> QTransform t;
> if (m.type() == QTransform::TxNone)
>     return img.copy();
> else
>     return img.transformed(m);
>
> AFAIU img.transformed(m).copy() will copy twice when  m.type() !=
> QTransform::TxNone right?
>
> Don't you think that is seems strange and is not documented enough?
>
> 2016-07-11 10:59 GMT+01:00 Simon Hausmann <Simon.Hausmann at qt.io>:
>
>> Hi,
>>
>>
>> Could you elaborate on what you see as the discrepancy between docs and
>> implementation? The docs don't say whether
>>
>> it's a shallow or a deep copy, so it looks to me that the implementation
>> is within the bounds of the docs.
>>
>>
>> Plus it seems sensible to return a shallow copy, doesn't it?
>>
>>
>>
>> Simon
>> ------------------------------
>> *From:* Development <development-bounces+simon.hausmann=
>> qt.io at qt-project.org> on behalf of Tomasz Olszak <olszak.tomasz at gmail.com
>> >
>> *Sent:* Monday, July 11, 2016 11:38:06 AM
>> *To:* development at qt-project.org
>> *Subject:* [Development] QImage::transformed returns shallow copy for
>> QTransform::TxNone matrix type.
>>
>> Hello,
>>
>> QImage:: transformed(const QTransform &matrix, Qt::TransformationMode
>> mode = Qt::FastTransformation) docs:
>>
>> "Returns a copy of the image that is transformed using the given
>> transformation matrix and transformation mode."
>>
>> But if matrix.type() == QTransform::TxNone then shallow instead of deep
>> copy is returned.
>>
>> I'm happy to submit a fix but I don't know what is expected behaviour?
>> Should implementation follow docs or docs or docs follow implementation
>> here?
>>
>> T.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160711/0cbad791/attachment.html>

From Simon.Hausmann at qt.io  Mon Jul 11 13:52:03 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Mon, 11 Jul 2016 11:52:03 +0000
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <CAGuVYzDOgMiCDqdOnyDXa8pxmOjb8RYUDw=CQwECLMDbb=-Z2g@mail.gmail.com>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<DB4PR02MB0541D51424FC79CBA6EA6A448C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<CAGuVYzCSvhwR7rRTyX8i7gnjuCD=MTGcU-jL7GFmspKVmXADOg@mail.gmail.com>
	<DB4PR02MB05418CA69FA81BF3B35C3DE18C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>,
	<CAGuVYzDOgMiCDqdOnyDXa8pxmOjb8RYUDw=CQwECLMDbb=-Z2g@mail.gmail.com>
Message-ID: <DB4PR02MB0541199BC46CBFA3557BD3918C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>

Hi,


What I'm suggesting is not to use the cleanup function to release any memory. As you have explained that is not possible as you do not own the data. But you can use

the cleanup callback as a way to determine if Qt still has a reference to your image data or not. If your image _was_ transformed then there should not be any reference

anymore. If it wasn't called, then you do need to call copy() explicitly to release the reference.


Another way would be to call QImage::isDetached(), but that is not public API.


Both are approached that allow you to replace your existing check with something that is less dependent on the implementation of QImage::transformed - in case

it changes one day - but are supposed to make your code more robust.



Simon

________________________________
From: Tomasz Olszak <olszak.tomasz at gmail.com>
Sent: Monday, July 11, 2016 1:40:25 PM
To: Simon Hausmann
Cc: development at qt-project.org
Subject: Re: [Development] QImage::transformed returns shallow copy for QTransform::TxNone matrix type.

The pointer comes from external object and it's lifetime is managed by it. I need to ensure that I will not use it anymore after leaving certain function. Hence it don't even need to be thread operation, So using clean function won't help here.

The problem here is that you can't say if transformed returns shallow or deep copy. Result depends on argument value. Of course the transform returning shallow copy on identity matrix is nice but should be documented somewhere. After reading docs I expected deep copy like from copy function. But maybe it's only me :)

Thanks for profound explanation.


2016-07-11 12:10 GMT+01:00 Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>>:

Hi,


Thank you for the explanation of your use-case. What remains unclear to me is why it is necessary for you to ensure a deep copy?


Is it related to the fact that your image is created from a raw data pointer and after your worker thread is done, you cannot guarantee

for the life-time of the raw data anymore?


Perhaps you could use the QImage constructor that takes a cleanup function (and cleanupInfo pointer). If your worker thread

ends up making a copy of the image data as a result of your transformation, then your original copy can and will be deleted

when you discard the source of the transform() call. That is something that you can keep track of. Vice-versa if it's not being called,

then you know that transformed() (or generally speaking _any_ sequence of operations you may have done) still operate on a shallow

copy. Then you can do an explicit deep copy.


Generally speaking my impression - assuming I did understand your use-case correctly - is that your problem stems from the unknown

life-cycle of your data. I don't think the behavior of QImage::transformed() should be made worse for the common case where shallow

copying benefits performance and memory consumption.


Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:qt.io at qt-project.org>> on behalf of Tomasz Olszak <olszak.tomasz at gmail.com<mailto:olszak.tomasz at gmail.com>>
Sent: Monday, July 11, 2016 12:53:51 PM
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] QImage::transformed returns shallow copy for QTransform::TxNone matrix type.

QImage::copy returns deep copy and has similar documentation so I assumed that when docs say copy it means deep copy.

Let's consider common case:

1. QImage img created from raw data pointer got from e.g. driver.
2. img used in thread to perform some transforms
3. Save result as deep copy

Ensuring step 3 is most efficient and does not perform unnecessary copying I need to write something like:

QTransform t;
if (m.type() == QTransform::TxNone)
    return img.copy();
else
    return img.transformed(m);

AFAIU img.transformed(m).copy() will copy twice when  m.type() != QTransform::TxNone right?

Don't you think that is seems strange and is not documented enough?

2016-07-11 10:59 GMT+01:00 Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>>:

Hi,


Could you elaborate on what you see as the discrepancy between docs and implementation? The docs don't say whether

it's a shallow or a deep copy, so it looks to me that the implementation is within the bounds of the docs.


Plus it seems sensible to return a shallow copy, doesn't it?



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org<mailto:qt.io at qt-project.org>> on behalf of Tomasz Olszak <olszak.tomasz at gmail.com<mailto:olszak.tomasz at gmail.com>>
Sent: Monday, July 11, 2016 11:38:06 AM
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: [Development] QImage::transformed returns shallow copy for QTransform::TxNone matrix type.

Hello,

QImage:: transformed(const QTransform &matrix, Qt::TransformationMode mode = Qt::FastTransformation) docs:

"Returns a copy of the image that is transformed using the given transformation matrix and transformation mode."

But if matrix.type() == QTransform::TxNone then shallow instead of deep copy is returned.

I'm happy to submit a fix but I don't know what is expected behaviour? Should implementation follow docs or docs or docs follow implementation here?

T.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160711/0066ff40/attachment.html>

From dangelog at gmail.com  Mon Jul 11 13:52:30 2016
From: dangelog at gmail.com (Giuseppe D'Angelo)
Date: Mon, 11 Jul 2016 13:52:30 +0200
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <CAGuVYzDOgMiCDqdOnyDXa8pxmOjb8RYUDw=CQwECLMDbb=-Z2g@mail.gmail.com>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<DB4PR02MB0541D51424FC79CBA6EA6A448C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<CAGuVYzCSvhwR7rRTyX8i7gnjuCD=MTGcU-jL7GFmspKVmXADOg@mail.gmail.com>
	<DB4PR02MB05418CA69FA81BF3B35C3DE18C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<CAGuVYzDOgMiCDqdOnyDXa8pxmOjb8RYUDw=CQwECLMDbb=-Z2g@mail.gmail.com>
Message-ID: <CAPm+cvgfJFF-3mzgGqp_uSbAiKUqwyuskr=N9gk=TkU2CHrreQ@mail.gmail.com>

On Mon, Jul 11, 2016 at 1:40 PM, Tomasz Olszak <olszak.tomasz at gmail.com> wrote:
> The problem here is that you can't say if transformed returns shallow or
> deep copy. Result depends on argument value. Of course the transform
> returning shallow copy on identity matrix is nice but should be documented
> somewhere. After reading docs I expected deep copy like from copy function.
> But maybe it's only me :)

Then always deep copy and then move on with the processing? Because
relying on shallow copies is a bit of a gamble -- by the same
reasoning, can you be sure that setPixel(x, y, color) always detaches?
What if it gets implemented in a way that first checks if the pixel
already has that color, and if so, it doesn't do anything?

-- 
Giuseppe D'Angelo


From olszak.tomasz at gmail.com  Mon Jul 11 14:42:17 2016
From: olszak.tomasz at gmail.com (Tomasz Olszak)
Date: Mon, 11 Jul 2016 13:42:17 +0100
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <DB4PR02MB0541199BC46CBFA3557BD3918C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<DB4PR02MB0541D51424FC79CBA6EA6A448C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<CAGuVYzCSvhwR7rRTyX8i7gnjuCD=MTGcU-jL7GFmspKVmXADOg@mail.gmail.com>
	<DB4PR02MB05418CA69FA81BF3B35C3DE18C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<CAGuVYzDOgMiCDqdOnyDXa8pxmOjb8RYUDw=CQwECLMDbb=-Z2g@mail.gmail.com>
	<DB4PR02MB0541199BC46CBFA3557BD3918C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
Message-ID: <CAGuVYzC8R+H33KHRVatmjy=uo9M1VoZRXxtVWT_ndbch+AF9rg@mail.gmail.com>

Yes seems more robust but it also seems like using a sledgehammer to crack
a nut. Seems like it is not worth to burn you time for that. If everyone is
ok with docs I'm too :)

2016-07-11 12:52 GMT+01:00 Simon Hausmann <Simon.Hausmann at qt.io>:

> Hi,
>
>
> What I'm suggesting is not to use the cleanup function to release any
> memory. As you have explained that is not possible as you do not own the
> data. But you can use
>
> the cleanup callback as a way to determine if Qt still has a reference to
> your image data or not. If your image _was_ transformed then there should
> not be any reference
>
> anymore. If it wasn't called, then you do need to call copy() explicitly
> to release the reference.
>
>
> Another way would be to call QImage::isDetached(), but that is not public
> API.
>
>
> Both are approached that allow you to replace your existing check with
> something that is less dependent on the implementation of
> QImage::transformed - in case
>
> it changes one day - but are supposed to make your code more robust.
>
>
>
> Simon
> ------------------------------
> *From:* Tomasz Olszak <olszak.tomasz at gmail.com>
> *Sent:* Monday, July 11, 2016 1:40:25 PM
> *To:* Simon Hausmann
> *Cc:* development at qt-project.org
>
> *Subject:* Re: [Development] QImage::transformed returns shallow copy for
> QTransform::TxNone matrix type.
>
> The pointer comes from external object and it's lifetime is managed by it.
> I need to ensure that I will not use it anymore after leaving certain
> function. Hence it don't even need to be thread operation, So using clean
> function won't help here.
>
> The problem here is that you can't say if transformed returns shallow or
> deep copy. Result depends on argument value. Of course the transform
> returning shallow copy on identity matrix is nice but should be documented
> somewhere. After reading docs I expected deep copy like from copy function.
> But maybe it's only me :)
>
> Thanks for profound explanation.
>
>
> 2016-07-11 12:10 GMT+01:00 Simon Hausmann <Simon.Hausmann at qt.io>:
>
>> Hi,
>>
>>
>> Thank you for the explanation of your use-case. What remains unclear to
>> me is why it is necessary for you to ensure a deep copy?
>>
>>
>> Is it related to the fact that your image is created from a raw data
>> pointer and after your worker thread is done, you cannot guarantee
>>
>> for the life-time of the raw data anymore?
>>
>>
>> Perhaps you could use the QImage constructor that takes a cleanup
>> function (and cleanupInfo pointer). If your worker thread
>>
>> ends up making a copy of the image data as a result of your
>> transformation, then your original copy can and will be deleted
>>
>> when you discard the source of the transform() call. That is something
>> that you can keep track of. Vice-versa if it's not being called,
>>
>> then you know that transformed() (or generally speaking _any_ sequence of
>> operations you may have done) still operate on a shallow
>>
>> copy. Then you can do an explicit deep copy.
>>
>>
>> Generally speaking my impression - assuming I did understand your
>> use-case correctly - is that your problem stems from the unknown
>>
>> life-cycle of your data. I don't think the behavior of
>> QImage::transformed() should be made worse for the common case where shallow
>>
>> copying benefits performance and memory consumption.
>>
>>
>> Simon
>> ------------------------------
>> *From:* Development <development-bounces+simon.hausmann=
>> qt.io at qt-project.org> on behalf of Tomasz Olszak <olszak.tomasz at gmail.com
>> >
>> *Sent:* Monday, July 11, 2016 12:53:51 PM
>> *To:* development at qt-project.org
>> *Subject:* Re: [Development] QImage::transformed returns shallow copy
>> for QTransform::TxNone matrix type.
>>
>> QImage::copy returns deep copy and has similar documentation so I assumed
>> that when docs say copy it means deep copy.
>>
>> Let's consider common case:
>>
>> 1. QImage img created from raw data pointer got from e.g. driver.
>> 2. img used in thread to perform some transforms
>> 3. Save result as deep copy
>>
>> Ensuring step 3 is most efficient and does not perform unnecessary
>> copying I need to write something like:
>>
>> QTransform t;
>> if (m.type() == QTransform::TxNone)
>>     return img.copy();
>> else
>>     return img.transformed(m);
>>
>> AFAIU img.transformed(m).copy() will copy twice when  m.type() !=
>> QTransform::TxNone right?
>>
>> Don't you think that is seems strange and is not documented enough?
>>
>> 2016-07-11 10:59 GMT+01:00 Simon Hausmann <Simon.Hausmann at qt.io>:
>>
>>> Hi,
>>>
>>>
>>> Could you elaborate on what you see as the discrepancy between docs and
>>> implementation? The docs don't say whether
>>>
>>> it's a shallow or a deep copy, so it looks to me that the implementation
>>> is within the bounds of the docs.
>>>
>>>
>>> Plus it seems sensible to return a shallow copy, doesn't it?
>>>
>>>
>>>
>>> Simon
>>> ------------------------------
>>> *From:* Development <development-bounces+simon.hausmann=
>>> qt.io at qt-project.org> on behalf of Tomasz Olszak <
>>> olszak.tomasz at gmail.com>
>>> *Sent:* Monday, July 11, 2016 11:38:06 AM
>>> *To:* development at qt-project.org
>>> *Subject:* [Development] QImage::transformed returns shallow copy for
>>> QTransform::TxNone matrix type.
>>>
>>> Hello,
>>>
>>> QImage:: transformed(const QTransform &matrix, Qt::TransformationMode
>>> mode = Qt::FastTransformation) docs:
>>>
>>> "Returns a copy of the image that is transformed using the given
>>> transformation matrix and transformation mode."
>>>
>>> But if matrix.type() == QTransform::TxNone then shallow instead of deep
>>> copy is returned.
>>>
>>> I'm happy to submit a fix but I don't know what is expected behaviour?
>>> Should implementation follow docs or docs or docs follow implementation
>>> here?
>>>
>>> T.
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160711/e1a3238f/attachment.html>

From olszak.tomasz at gmail.com  Mon Jul 11 14:45:18 2016
From: olszak.tomasz at gmail.com (Tomasz Olszak)
Date: Mon, 11 Jul 2016 13:45:18 +0100
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <CAPm+cvgfJFF-3mzgGqp_uSbAiKUqwyuskr=N9gk=TkU2CHrreQ@mail.gmail.com>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<DB4PR02MB0541D51424FC79CBA6EA6A448C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<CAGuVYzCSvhwR7rRTyX8i7gnjuCD=MTGcU-jL7GFmspKVmXADOg@mail.gmail.com>
	<DB4PR02MB05418CA69FA81BF3B35C3DE18C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<CAGuVYzDOgMiCDqdOnyDXa8pxmOjb8RYUDw=CQwECLMDbb=-Z2g@mail.gmail.com>
	<CAPm+cvgfJFF-3mzgGqp_uSbAiKUqwyuskr=N9gk=TkU2CHrreQ@mail.gmail.com>
Message-ID: <CAGuVYzDpUk7i-zsoe5erS_fZeQ7JA41zZc=oiYxprHsdi1_dJQ@mail.gmail.com>

QTransform m.
img.transformed(m).copy()

will create one copy. But:

QTransform m.
m.rotate(10);
img.transformed(m).copy()

will copy image twice; On embedded device, if you do some video decoding it
is a problem :)

2016-07-11 12:52 GMT+01:00 Giuseppe D'Angelo <dangelog at gmail.com>:

> On Mon, Jul 11, 2016 at 1:40 PM, Tomasz Olszak <olszak.tomasz at gmail.com>
> wrote:
> > The problem here is that you can't say if transformed returns shallow or
> > deep copy. Result depends on argument value. Of course the transform
> > returning shallow copy on identity matrix is nice but should be
> documented
> > somewhere. After reading docs I expected deep copy like from copy
> function.
> > But maybe it's only me :)
>
> Then always deep copy and then move on with the processing? Because
> relying on shallow copies is a bit of a gamble -- by the same
> reasoning, can you be sure that setPixel(x, y, color) always detaches?
> What if it gets implemented in a way that first checks if the pixel
> already has that color, and if so, it doesn't do anything?
>
> --
> Giuseppe D'Angelo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160711/f0e4fa04/attachment.html>

From Simon.Hausmann at qt.io  Mon Jul 11 14:54:58 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Mon, 11 Jul 2016 12:54:58 +0000
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <CAGuVYzDpUk7i-zsoe5erS_fZeQ7JA41zZc=oiYxprHsdi1_dJQ@mail.gmail.com>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<DB4PR02MB0541D51424FC79CBA6EA6A448C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<CAGuVYzCSvhwR7rRTyX8i7gnjuCD=MTGcU-jL7GFmspKVmXADOg@mail.gmail.com>
	<DB4PR02MB05418CA69FA81BF3B35C3DE18C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<CAGuVYzDOgMiCDqdOnyDXa8pxmOjb8RYUDw=CQwECLMDbb=-Z2g@mail.gmail.com>
	<CAPm+cvgfJFF-3mzgGqp_uSbAiKUqwyuskr=N9gk=TkU2CHrreQ@mail.gmail.com>,
	<CAGuVYzDpUk7i-zsoe5erS_fZeQ7JA41zZc=oiYxprHsdi1_dJQ@mail.gmail.com>
Message-ID: <DB4PR02MB05418ED95070F612273D62278C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>

Hi,


I realize that there may be an even simpler way of ensure that you get a deep copy, but only if transformed() hasn't already

made one (so that you don't have to worry about your potentially dangling pointer):


Instead of using copy(), why not call the non-const bits() function (and don't use the returned value). That will detach (and thus

deep-copy) the data if your transformation produced no copy. If a copy was produced, then that will be the only copy and no

copying happens.




Simon

________________________________
From: Tomasz Olszak <olszak.tomasz at gmail.com>
Sent: Monday, July 11, 2016 2:45:18 PM
To: Giuseppe D'Angelo
Cc: Simon Hausmann; development at qt-project.org
Subject: Re: [Development] QImage::transformed returns shallow copy for QTransform::TxNone matrix type.

QTransform m.
img.transformed(m).copy()

will create one copy. But:

QTransform m.
m.rotate(10);
img.transformed(m).copy()

will copy image twice; On embedded device, if you do some video decoding it is a problem :)

2016-07-11 12:52 GMT+01:00 Giuseppe D'Angelo <dangelog at gmail.com<mailto:dangelog at gmail.com>>:
On Mon, Jul 11, 2016 at 1:40 PM, Tomasz Olszak <olszak.tomasz at gmail.com<mailto:olszak.tomasz at gmail.com>> wrote:
> The problem here is that you can't say if transformed returns shallow or
> deep copy. Result depends on argument value. Of course the transform
> returning shallow copy on identity matrix is nice but should be documented
> somewhere. After reading docs I expected deep copy like from copy function.
> But maybe it's only me :)

Then always deep copy and then move on with the processing? Because
relying on shallow copies is a bit of a gamble -- by the same
reasoning, can you be sure that setPixel(x, y, color) always detaches?
What if it gets implemented in a way that first checks if the pixel
already has that color, and if so, it doesn't do anything?

--
Giuseppe D'Angelo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160711/60244969/attachment.html>

From olszak.tomasz at gmail.com  Mon Jul 11 15:08:54 2016
From: olszak.tomasz at gmail.com (Tomasz Olszak)
Date: Mon, 11 Jul 2016 14:08:54 +0100
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <DB4PR02MB05418ED95070F612273D62278C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<DB4PR02MB0541D51424FC79CBA6EA6A448C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<CAGuVYzCSvhwR7rRTyX8i7gnjuCD=MTGcU-jL7GFmspKVmXADOg@mail.gmail.com>
	<DB4PR02MB05418CA69FA81BF3B35C3DE18C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<CAGuVYzDOgMiCDqdOnyDXa8pxmOjb8RYUDw=CQwECLMDbb=-Z2g@mail.gmail.com>
	<CAPm+cvgfJFF-3mzgGqp_uSbAiKUqwyuskr=N9gk=TkU2CHrreQ@mail.gmail.com>
	<CAGuVYzDpUk7i-zsoe5erS_fZeQ7JA41zZc=oiYxprHsdi1_dJQ@mail.gmail.com>
	<DB4PR02MB05418ED95070F612273D62278C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
Message-ID: <CAGuVYzBZHYbtku6rDcdaomDdPd9XgmZ46BPwDbU=UY4HHPrdjA@mail.gmail.com>

Oh good spot, thanks for that. It doesn't depend on QIMage::transformed
 impl.

Thanks!

2016-07-11 13:54 GMT+01:00 Simon Hausmann <Simon.Hausmann at qt.io>:

> Hi,
>
>
> I realize that there may be an even simpler way of ensure that you get a
> deep copy, but only if transformed() hasn't already
>
> made one (so that you don't have to worry about your potentially dangling
> pointer):
>
>
> Instead of using copy(), why not call the non-const bits() function (and
> don't use the returned value). That will detach (and thus
>
> deep-copy) the data if your transformation produced no copy. If a copy was
> produced, then that will be the only copy and no
>
> copying happens.
>
>
>
>
> Simon
> ------------------------------
> *From:* Tomasz Olszak <olszak.tomasz at gmail.com>
> *Sent:* Monday, July 11, 2016 2:45:18 PM
> *To:* Giuseppe D'Angelo
> *Cc:* Simon Hausmann; development at qt-project.org
> *Subject:* Re: [Development] QImage::transformed returns shallow copy for
> QTransform::TxNone matrix type.
>
> QTransform m.
> img.transformed(m).copy()
>
> will create one copy. But:
>
> QTransform m.
> m.rotate(10);
> img.transformed(m).copy()
>
> will copy image twice; On embedded device, if you do some video decoding
> it is a problem :)
>
> 2016-07-11 12:52 GMT+01:00 Giuseppe D'Angelo <dangelog at gmail.com>:
>
>> On Mon, Jul 11, 2016 at 1:40 PM, Tomasz Olszak <olszak.tomasz at gmail.com>
>> wrote:
>> > The problem here is that you can't say if transformed returns shallow or
>> > deep copy. Result depends on argument value. Of course the transform
>> > returning shallow copy on identity matrix is nice but should be
>> documented
>> > somewhere. After reading docs I expected deep copy like from copy
>> function.
>> > But maybe it's only me :)
>>
>> Then always deep copy and then move on with the processing? Because
>> relying on shallow copies is a bit of a gamble -- by the same
>> reasoning, can you be sure that setPixel(x, y, color) always detaches?
>> What if it gets implemented in a way that first checks if the pixel
>> already has that color, and if so, it doesn't do anything?
>>
>> --
>> Giuseppe D'Angelo
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160711/87f2a7c6/attachment.html>

From paul.tvete at qt.io  Mon Jul 11 16:03:32 2016
From: paul.tvete at qt.io (Paul Olav Tvete)
Date: Mon, 11 Jul 2016 16:03:32 +0200
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <DB4PR02MB05418ED95070F612273D62278C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<CAGuVYzDpUk7i-zsoe5erS_fZeQ7JA41zZc=oiYxprHsdi1_dJQ@mail.gmail.com>
	<DB4PR02MB05418ED95070F612273D62278C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
Message-ID: <3374551.Hg99cgf9bJ@dragaera>

On mandag 11. juli 2016 12.54.58 CEST Simon Hausmann wrote:
> Instead of using copy(), why not call the non-const bits() function (and
> don't use the returned value). That will detach [...]

Instead of using bits(), why not call detach() directly? ;)

- Paul



From b.terrier at gmail.com  Mon Jul 11 16:05:50 2016
From: b.terrier at gmail.com (Benjamin TERRIER)
Date: Mon, 11 Jul 2016 16:05:50 +0200
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <3374551.Hg99cgf9bJ@dragaera>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<CAGuVYzDpUk7i-zsoe5erS_fZeQ7JA41zZc=oiYxprHsdi1_dJQ@mail.gmail.com>
	<DB4PR02MB05418ED95070F612273D62278C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<3374551.Hg99cgf9bJ@dragaera>
Message-ID: <CAO+E9ooD+9vacodp_gLJxSLr2gL1qHjHtz8Zv_FHRue+U+pS3Q@mail.gmail.com>

2016-07-11 16:03 GMT+02:00 Paul Olav Tvete <paul.tvete at qt.io>:
> On mandag 11. juli 2016 12.54.58 CEST Simon Hausmann wrote:
>> Instead of using copy(), why not call the non-const bits() function (and
>> don't use the returned value). That will detach [...]
>
> Instead of using bits(), why not call detach() directly? ;)
>
> - Paul
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Hi,

QImage::detach() is not public API.
However QPixmap::detach() is, so why QImage::detach() couldn't be made
public too?

BR,

Benjamin


From Simon.Hausmann at qt.io  Mon Jul 11 16:07:01 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Mon, 11 Jul 2016 14:07:01 +0000
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <3374551.Hg99cgf9bJ@dragaera>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<CAGuVYzDpUk7i-zsoe5erS_fZeQ7JA41zZc=oiYxprHsdi1_dJQ@mail.gmail.com>
	<DB4PR02MB05418ED95070F612273D62278C3F0@DB4PR02MB0541.eurprd02.prod.outlook.com>,
	<3374551.Hg99cgf9bJ@dragaera>
Message-ID: <cf81a3d0-8af9-47a8-836b-7727257ba6ba@qt.io>

Detach() is marked with \internal - wouldn't want to suggest the use of private api;)


Simon


________________________________
From: Paul Olav Tvete
Sent: Jul 11, 2016 16:03
To: development at qt-project.org
Subject: Re: [Development] QImage::transformed returns shallow copy for QTransform::TxNone matrix type.

On mandag 11. juli 2016 12.54.58 CEST Simon Hausmann wrote:
> Instead of using copy(), why not call the non-const bits() function (and
> don't use the returned value). That will detach [...]

Instead of using bits(), why not call detach() directly? ;)

- Paul

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160711/3925b2aa/attachment.html>

From kde at carewolf.com  Mon Jul 11 16:47:08 2016
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Mon, 11 Jul 2016 16:47:08 +0200
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <CAO+E9ooD+9vacodp_gLJxSLr2gL1qHjHtz8Zv_FHRue+U+pS3Q@mail.gmail.com>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<3374551.Hg99cgf9bJ@dragaera>
	<CAO+E9ooD+9vacodp_gLJxSLr2gL1qHjHtz8Zv_FHRue+U+pS3Q@mail.gmail.com>
Message-ID: <201607111647.09054.kde@carewolf.com>

On Monday 11 July 2016, Benjamin TERRIER wrote:
> 2016-07-11 16:03 GMT+02:00 Paul Olav Tvete <paul.tvete at qt.io>:
> > On mandag 11. juli 2016 12.54.58 CEST Simon Hausmann wrote:
> >> Instead of using copy(), why not call the non-const bits() function (and
> >> don't use the returned value). That will detach [...]
> > 
> > Instead of using bits(), why not call detach() directly? ;)
> > 
> > - Paul
> > 
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> Hi,
> 
> QImage::detach() is not public API.
> However QPixmap::detach() is, so why QImage::detach() couldn't be made
> public too?
> 
It probably should be. It is a lot more sensible to use than copy(rect()).

BR
`Allan


From andre at familiesomers.nl  Mon Jul 11 20:33:43 2016
From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=)
Date: Mon, 11 Jul 2016 20:33:43 +0200
Subject: [Development] QTableView gets freezed in showing data read from
 SQLite database , which is updated dynamically with 2000 rows in 2s
In-Reply-To: <CAMNhMCiyD_guwn2QOiVZxgSSey8WcJK8aX-TWREB+D5i4KannA@mail.gmail.com>
References: <CAMNhMCiyD_guwn2QOiVZxgSSey8WcJK8aX-TWREB+D5i4KannA@mail.gmail.com>
Message-ID: <f4fdfc87-fdba-da69-ff76-873817783d65@familiesomers.nl>



Op 09/07/2016 om 20:01 schreef swarit wipra:
> Hi folks,
>
> i have issues in showing huge data in QTableView ,data read from 
> sqlite database which is being updated dynamically .. 2k rows in 2s.
> i am using QSQLRelationModel
> let me describe the scenario in detail.
>
> My Qt application has a view i.e QTableView , each row has following 
> structure:
>
>  ****************************************
>  *QPushButton*|QLabel | QLabel | QLabel *
>  ****************************************
>  i have created it using QItemDelegate
>
>  each row isinserted dynamicaly , after sometime gui gets freezed.
>
> could anyone tell me the way to fix the issue.
Don't implement it like this. You are creating 8k widgets and act 
suprised that it isn't fast... Even if you did not use QLabel but the 
default delegate, 2k push buttons is still pushing it I think.

Note that this is by no means a new issue. Search and you will find 
better options, even ones using widgets but creating far less instances.

André



From nospam at vuorela.dk  Mon Jul 11 21:21:06 2016
From: nospam at vuorela.dk (Sune Vuorela)
Date: Mon, 11 Jul 2016 19:21:06 +0000 (UTC)
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<3374551.Hg99cgf9bJ@dragaera>
	<CAO+E9ooD+9vacodp_gLJxSLr2gL1qHjHtz8Zv_FHRue+U+pS3Q@mail.gmail.com>
	<201607111647.09054.kde@carewolf.com>
Message-ID: <nm0rj2$spf$1@ger.gmane.org>

On 2016-07-11, Allan Sandfeld Jensen <kde at carewolf.com> wrote:
> On Monday 11 July 2016, Benjamin TERRIER wrote:
>> QImage::detach() is not public API.
>> However QPixmap::detach() is, so why QImage::detach() couldn't be made
>> public too?
>> 
> It probably should be. It is a lot more sensible to use than copy(rect()).

https://codereview.qt-project.org/#/c/164886/

/Sune



From cristian.adam at gmail.com  Tue Jul 12 00:20:01 2016
From: cristian.adam at gmail.com (Cristian Adam)
Date: Tue, 12 Jul 2016 00:20:01 +0200
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <AM4PR02MB1652BE25DB1BDF0F86B93840F03B0@AM4PR02MB1652.eurprd02.prod.outlook.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<2133524.ekmAkN6kfG@tjmaciei-mobl1>
	<1775643.FonJhWLViK@tjmaciei-mobl1>
	<201607070910.51615.marc.mutz@kdab.com>
	<c65d0c5f-3211-6b4b-dc37-3b56208cf93d@familiesomers.nl>
	<DB5PR0201MB1607D44C66FF5DC63798AA3D9F3B0@DB5PR0201MB1607.eurprd02.prod.outlook.com>
	<AM4PR02MB1652BE25DB1BDF0F86B93840F03B0@AM4PR02MB1652.eurprd02.prod.outlook.com>
Message-ID: <CA+u+m-LC8pDin-QKWYEs=bMTZ6vGt8-SOMKVTHwk0Q7K6U5e2Q@mail.gmail.com>

On Thu, Jul 7, 2016 at 12:06 PM, Marco Bubke <Marco.Bubke at qt.io> wrote:

> I think it simply a question of time to get used to the STL. You get used
> to many things.
>
> I think we should mind about the new features of C++ which are coming,
> which cannot integrated very well with Qt because we use a different idiom.
>
> I really think we should make it easier for the developer but if we
> provide no way to go the fast path do we really make it easier?
>
> If the context is changing over time, is it not smart to reevaluate
> decision again and maybe go a different route? I don't mean to do it all
> the time but maybe there is a middle path between different
> "fundamentalisms". [image: 😉]
>
Luckily there's Copper Spice, and it seems they want to be the more
*modern* C++ Qt library.

Their latest presentation
<https://github.com/boostcon/cppnow_presentations_2016/blob/master/00_tuesday/copperspice_the_next_generation_of_signals.pdf>
has
at page 6 this:

[image: Inline image 1]

The STL containers part is not yet done. Will they keep the move semantics
for the upcoming
containers?

What would QString refactor would bring? UTF-8? QStringView?

Cheers,
Cristian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160712/4b416cb0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OutlookEmoji-😉.png
Type: image/png
Size: 390 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160712/4b416cb0/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: copper_spice_1.3.png
Type: image/png
Size: 92329 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160712/4b416cb0/attachment-0001.png>

From thiago.macieira at intel.com  Tue Jul 12 07:33:16 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 11 Jul 2016 22:33:16 -0700
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <CA+u+m-LC8pDin-QKWYEs=bMTZ6vGt8-SOMKVTHwk0Q7K6U5e2Q@mail.gmail.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<AM4PR02MB1652BE25DB1BDF0F86B93840F03B0@AM4PR02MB1652.eurprd02.prod.outlook.com>
	<CA+u+m-LC8pDin-QKWYEs=bMTZ6vGt8-SOMKVTHwk0Q7K6U5e2Q@mail.gmail.com>
Message-ID: <2712893.3zGXhzZ5Tl@tjmaciei-mobl1>

On terça-feira, 12 de julho de 2016 00:20:01 PDT Cristian Adam wrote:
> Their latest presentation
> <https://github.com/boostcon/cppnow_presentations_2016/blob/master/00_tuesda
> y/copperspice_the_next_generation_of_signals.pdf> has
> at page 6 this:

Criticism:
* Qt's dependency on qmake: that's only for building Qt itself, not for your 
application. Otherwise, we could always criticise any library for choosing to 
use buildsystem X instead of Y.

* Remove moc: why? Moc has a very important use besides signals, that being of 
reflection of C++. Until at least C++ 2020, but most likely WAY further, 
there's no replacement for that. Therefore, removing moc is removing important 
functionality. Let's see CS implement QtScript, QtDBus and QtQml without 
moc...

* Use native C++ atomics: done in Qt 5.7, except for MSVC which doesn't 
implement it properly.

* Signal / slot delivery as a separate library: interesting, I'll give CS 
that, but not sure what the value of this is.

* Containers: leveraging STL only makes sense if we drop implicit sharing. 
There are many arguments in favour and against doing that, which I will not 
get into. What I will say: doing implicit-sharing with STL is the worst of 
both worlds.

* Use C++ native pointers: granted, that's also the reason why we're not 
reimplementing std::unique_ptr or extending QScopedPointer to have move 
semantics.

* Refactor QString: huh?

> What would QString refactor would bring? UTF-8? QStringView?

Why would we want UTF-8? There's no native type for it, unlike UTF-16's 
char16_t. And ALL the good Unicode-capable API in most OSes uses UTF-16 (Java, 
ICU, Win32, Cocoa, all are UTF-16; POSIX's wide-char API is neither good nor 
guaranteed to be UTF-32).

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



From b.terrier at gmail.com  Tue Jul 12 10:15:01 2016
From: b.terrier at gmail.com (Benjamin TERRIER)
Date: Tue, 12 Jul 2016 10:15:01 +0200
Subject: [Development] QImage::transformed returns shallow copy for
 QTransform::TxNone matrix type.
In-Reply-To: <nm0rj2$spf$1@ger.gmane.org>
References: <CAGuVYzC9tTzKqNM+JHmacsWuNKtb_9=0onWDFQaPw3QuyPFHcw@mail.gmail.com>
	<3374551.Hg99cgf9bJ@dragaera>
	<CAO+E9ooD+9vacodp_gLJxSLr2gL1qHjHtz8Zv_FHRue+U+pS3Q@mail.gmail.com>
	<201607111647.09054.kde@carewolf.com> <nm0rj2$spf$1@ger.gmane.org>
Message-ID: <CAO+E9ooiKv7fwSpxuqNRLbNN2ODJhwDK9xBAXLdxMvpCtQMS_A@mail.gmail.com>

2016-07-11 21:21 GMT+02:00 Sune Vuorela <nospam at vuorela.dk>:
> On 2016-07-11, Allan Sandfeld Jensen <kde at carewolf.com> wrote:
>> On Monday 11 July 2016, Benjamin TERRIER wrote:
>>> QImage::detach() is not public API.
>>> However QPixmap::detach() is, so why QImage::detach() couldn't be made
>>> public too?
>>>
>> It probably should be. It is a lot more sensible to use than copy(rect()).
>
> https://codereview.qt-project.org/#/c/164886/
>
> /Sune
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Just something worth stating here, from Mark Mutz on the codereview:
    "QImage::detach() doesn't (if the QImage was constructed from the
mutable-uchar* ctor)."

So it's seem that all detach() functions which are internal will not
detach when using external data which is the case discussed here in
the first place.
However detach() member functions which are part of the public API
(e.g QPixmap::detach()) will always detach.

The consequence is that for Tomasz Olszak's use case calling
QImage::detach() is a bad idea because (1) it is not public API and
(2) it will NOT detach. So the only solution seems to call the non
const version of bits() as suggested earlier.

BR,

Benjamin Terrier


From mitch.curtis at qt.io  Tue Jul 12 10:49:47 2016
From: mitch.curtis at qt.io (Mitch Curtis)
Date: Tue, 12 Jul 2016 08:49:47 +0000
Subject: [Development] QTableView gets freezed in showing data read from
 SQLite database , which is updated dynamically with 2000 rows in 2s
In-Reply-To: <f4fdfc87-fdba-da69-ff76-873817783d65@familiesomers.nl>
References: <CAMNhMCiyD_guwn2QOiVZxgSSey8WcJK8aX-TWREB+D5i4KannA@mail.gmail.com>
	<f4fdfc87-fdba-da69-ff76-873817783d65@familiesomers.nl>
Message-ID: <AM4PR0201MB190504B21789E1DA626914ED88300@AM4PR0201MB1905.eurprd02.prod.outlook.com>

As someone who has more experience with Qt Quick, I gotta ask... does QTableView create widgets for every row in the model all at once?

> -----Original Message-----
> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-
> project.org] On Behalf Of André Somers
> Sent: Monday, 11 July 2016 8:34 PM
> To: development at qt-project.org
> Subject: Re: [Development] QTableView gets freezed in showing data read
> from SQLite database , which is updated dynamically with 2000 rows in 2s
> 
> 
> 
> Op 09/07/2016 om 20:01 schreef swarit wipra:
> > Hi folks,
> >
> > i have issues in showing huge data in QTableView ,data read from
> > sqlite database which is being updated dynamically .. 2k rows in 2s.
> > i am using QSQLRelationModel
> > let me describe the scenario in detail.
> >
> > My Qt application has a view i.e QTableView , each row has following
> > structure:
> >
> >  ****************************************
> >  *QPushButton*|QLabel | QLabel | QLabel *
> >  ****************************************
> >  i have created it using QItemDelegate
> >
> >  each row isinserted dynamicaly , after sometime gui gets freezed.
> >
> > could anyone tell me the way to fix the issue.
> Don't implement it like this. You are creating 8k widgets and act suprised
> that it isn't fast... Even if you did not use QLabel but the default
> delegate, 2k push buttons is still pushing it I think.
> 
> Note that this is by no means a new issue. Search and you will find better
> options, even ones using widgets but creating far less instances.
> 
> André
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From giuseppe.dangelo at kdab.com  Tue Jul 12 11:27:33 2016
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Tue, 12 Jul 2016 11:27:33 +0200
Subject: [Development] QTableView gets freezed in showing data read from
 SQLite database , which is updated dynamically with 2000 rows in 2s
In-Reply-To: <AM4PR0201MB190504B21789E1DA626914ED88300@AM4PR0201MB1905.eurprd02.prod.outlook.com>
References: <CAMNhMCiyD_guwn2QOiVZxgSSey8WcJK8aX-TWREB+D5i4KannA@mail.gmail.com>
	<f4fdfc87-fdba-da69-ff76-873817783d65@familiesomers.nl>
	<AM4PR0201MB190504B21789E1DA626914ED88300@AM4PR0201MB1905.eurprd02.prod.outlook.com>
Message-ID: <5784B805.6020904@kdab.com>

Il 12/07/2016 10:49, Mitch Curtis ha scritto:
> As someone who has more experience with Qt Quick, I gotta ask... does QTableView create widgets for every row in the model all at once?

It does not create any sub widget. The whole point of the design of item 
views is to use a few delegate objects (1, out of the box) to paint 
themselves, not to create thousands of sub-widgets.

(Besides, this is the wrong ML for discussing this problem...)

Cheers,

-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160712/84ca7340/attachment.bin>

From Marco.Bubke at qt.io  Tue Jul 12 11:47:48 2016
From: Marco.Bubke at qt.io (Marco Bubke)
Date: Tue, 12 Jul 2016 09:47:48 +0000
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <2712893.3zGXhzZ5Tl@tjmaciei-mobl1>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<AM4PR02MB1652BE25DB1BDF0F86B93840F03B0@AM4PR02MB1652.eurprd02.prod.outlook.com>
	<CA+u+m-LC8pDin-QKWYEs=bMTZ6vGt8-SOMKVTHwk0Q7K6U5e2Q@mail.gmail.com>,
	<2712893.3zGXhzZ5Tl@tjmaciei-mobl1>
Message-ID: <AM4PR02MB1652CD73001583BA359E8418F0300@AM4PR02MB1652.eurprd02.prod.outlook.com>

> Why would we want UTF-8? There's no native type for it, unlike UTF-16's
> char16_t. And ALL the good Unicode-capable API in most OSes uses UTF-16 (Java,
> ICU, Win32, Cocoa, all are UTF-16; POSIX's wide-char API is neither good nor
> guaranteed to be UTF-32).


UTF-8 is used by many libraries and converting between UTF-16 and UTF-8 makes things not faster or better. If you work with text which is annotated with ASCII, which is quite common today, the advantages of Utf8 looks quite compelling.


But without changing QString to UTF-8 our UTF-8 support could be much better . For example we convert mostly to a QByteArray which has to be copied again because we have move the ownership of that string to API which is not supporting QByteArray. In that case it would be already nice that you would have something like QByteArray::takeData(). And this is only one case. Lets face it, the world is much bigger than Qt, and I think there is much to gain if we integrate better with alien libraries. Actually as I used Qt in the nineties it was my impression that Qt had that mindset but than it changed gradually.

________________________________
From: Development <development-bounces+marco.bubke=qt.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Tuesday, July 12, 2016 7:33:16 AM
To: development at qt-project.org
Subject: Re: [Development] Use of Standard Library containers in Qt source code

On terça-feira, 12 de julho de 2016 00:20:01 PDT Cristian Adam wrote:
> Their latest presentation
> <https://github.com/boostcon/cppnow_presentations_2016/blob/master/00_tuesda
> y/copperspice_the_next_generation_of_signals.pdf> has
> at page 6 this:

Criticism:
* Qt's dependency on qmake: that's only for building Qt itself, not for your
application. Otherwise, we could always criticise any library for choosing to
use buildsystem X instead of Y.

* Remove moc: why? Moc has a very important use besides signals, that being of
reflection of C++. Until at least C++ 2020, but most likely WAY further,
there's no replacement for that. Therefore, removing moc is removing important
functionality. Let's see CS implement QtScript, QtDBus and QtQml without
moc...

* Use native C++ atomics: done in Qt 5.7, except for MSVC which doesn't
implement it properly.

* Signal / slot delivery as a separate library: interesting, I'll give CS
that, but not sure what the value of this is.

* Containers: leveraging STL only makes sense if we drop implicit sharing.
There are many arguments in favour and against doing that, which I will not
get into. What I will say: doing implicit-sharing with STL is the worst of
both worlds.

* Use C++ native pointers: granted, that's also the reason why we're not
reimplementing std::unique_ptr or extending QScopedPointer to have move
semantics.

* Refactor QString: huh?

> What would QString refactor would bring? UTF-8? QStringView?

Why would we want UTF-8? There's no native type for it, unlike UTF-16's
char16_t. And ALL the good Unicode-capable API in most OSes uses UTF-16 (Java,
ICU, Win32, Cocoa, all are UTF-16; POSIX's wide-char API is neither good nor
guaranteed to be UTF-32).

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

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160712/299fd25f/attachment.html>

From mitch.curtis at qt.io  Tue Jul 12 14:19:03 2016
From: mitch.curtis at qt.io (Mitch Curtis)
Date: Tue, 12 Jul 2016 12:19:03 +0000
Subject: [Development] QTableView gets freezed in showing data read from
 SQLite database , which is updated dynamically with 2000 rows in 2s
In-Reply-To: <5784B805.6020904@kdab.com>
References: <CAMNhMCiyD_guwn2QOiVZxgSSey8WcJK8aX-TWREB+D5i4KannA@mail.gmail.com>
	<f4fdfc87-fdba-da69-ff76-873817783d65@familiesomers.nl>
	<AM4PR0201MB190504B21789E1DA626914ED88300@AM4PR0201MB1905.eurprd02.prod.outlook.com>
	<5784B805.6020904@kdab.com>
Message-ID: <AM4PR0201MB1905CCD0BC547052BFE27A9D88300@AM4PR0201MB1905.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-
> project.org] On Behalf Of Giuseppe D'Angelo
> Sent: Tuesday, 12 July 2016 11:28 AM
> To: development at qt-project.org
> Subject: Re: [Development] QTableView gets freezed in showing data read
> from SQLite database , which is updated dynamically with 2000 rows in 2s
> 
> Il 12/07/2016 10:49, Mitch Curtis ha scritto:
> > As someone who has more experience with Qt Quick, I gotta ask... does
> QTableView create widgets for every row in the model all at once?
> 
> It does not create any sub widget. The whole point of the design of item
> views is to use a few delegate objects (1, out of the box) to paint
> themselves, not to create thousands of sub-widgets.

So what Andre said ("2k push buttons") is wrong?

> (Besides, this is the wrong ML for discussing this problem...)

Why? I'm just clarifying a point brought up in response to someone's question about usage of Qt.

> Cheers,
> 
> --
> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The
> Qt Experts


From mitch.curtis at qt.io  Tue Jul 12 14:20:41 2016
From: mitch.curtis at qt.io (Mitch Curtis)
Date: Tue, 12 Jul 2016 12:20:41 +0000
Subject: [Development] QTableView gets freezed in showing data read from
 SQLite database , which is updated dynamically with 2000 rows in 2s
In-Reply-To: <AM4PR0201MB1905CCD0BC547052BFE27A9D88300@AM4PR0201MB1905.eurprd02.prod.outlook.com>
References: <CAMNhMCiyD_guwn2QOiVZxgSSey8WcJK8aX-TWREB+D5i4KannA@mail.gmail.com>
	<f4fdfc87-fdba-da69-ff76-873817783d65@familiesomers.nl>
	<AM4PR0201MB190504B21789E1DA626914ED88300@AM4PR0201MB1905.eurprd02.prod.outlook.com>
	<5784B805.6020904@kdab.com>
	<AM4PR0201MB1905CCD0BC547052BFE27A9D88300@AM4PR0201MB1905.eurprd02.prod.outlook.com>
Message-ID: <AM4PR0201MB19050D9507EF992FCB5E859788300@AM4PR0201MB1905.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-
> project.org] On Behalf Of Mitch Curtis
> Sent: Tuesday, 12 July 2016 2:19 PM
> To: Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>; development at qt-
> project.org
> Subject: Re: [Development] QTableView gets freezed in showing data read
> from SQLite database , which is updated dynamically with 2000 rows in 2s
> 
> 
> 
> > -----Original Message-----
> > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-
> > project.org] On Behalf Of Giuseppe D'Angelo
> > Sent: Tuesday, 12 July 2016 11:28 AM
> > To: development at qt-project.org
> > Subject: Re: [Development] QTableView gets freezed in showing data
> > read from SQLite database , which is updated dynamically with 2000
> > rows in 2s
> >
> > Il 12/07/2016 10:49, Mitch Curtis ha scritto:
> > > As someone who has more experience with Qt Quick, I gotta ask...
> > > does
> > QTableView create widgets for every row in the model all at once?
> >
> > It does not create any sub widget. The whole point of the design of
> > item views is to use a few delegate objects (1, out of the box) to
> > paint themselves, not to create thousands of sub-widgets.
> 
> So what Andre said ("2k push buttons") is wrong?
> 
> > (Besides, this is the wrong ML for discussing this problem...)
> 
> Why? I'm just clarifying a point brought up in response to someone's
> question about usage of Qt.

Ah, right, I didn't realise the original post was in the dev list..

> > Cheers,
> >
> > --
> > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software
> > Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK
> > +44-1625-809908 KDAB - The Qt Experts
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From giuseppe.dangelo at kdab.com  Tue Jul 12 14:35:08 2016
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Tue, 12 Jul 2016 14:35:08 +0200
Subject: [Development] QTableView gets freezed in showing data read from
 SQLite database , which is updated dynamically with 2000 rows in 2s
In-Reply-To: <AM4PR0201MB1905CCD0BC547052BFE27A9D88300@AM4PR0201MB1905.eurprd02.prod.outlook.com>
References: <CAMNhMCiyD_guwn2QOiVZxgSSey8WcJK8aX-TWREB+D5i4KannA@mail.gmail.com>
	<f4fdfc87-fdba-da69-ff76-873817783d65@familiesomers.nl>
	<AM4PR0201MB190504B21789E1DA626914ED88300@AM4PR0201MB1905.eurprd02.prod.outlook.com>
	<5784B805.6020904@kdab.com>
	<AM4PR0201MB1905CCD0BC547052BFE27A9D88300@AM4PR0201MB1905.eurprd02.prod.outlook.com>
Message-ID: <5784E3FC.5080700@kdab.com>

Il 12/07/2016 14:19, Mitch Curtis ha scritto:
>> >It does not create any sub widget. The whole point of the design of item
>> >views is to use a few delegate objects (1, out of the box) to paint
>> >themselves, not to create thousands of sub-widgets.
> So what Andre said ("2k push buttons") is wrong?

Well, no, from the first message in the thread it looked like OP's was 
indeed filling the view by manually creating thousands of QPushButton / 
QLabel / etc.

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160712/8802d8dd/attachment.bin>

From charleyb123 at gmail.com  Tue Jul 12 14:58:11 2016
From: charleyb123 at gmail.com (charleyb123 .)
Date: Tue, 12 Jul 2016 06:58:11 -0600
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <AM4PR02MB1652CD73001583BA359E8418F0300@AM4PR02MB1652.eurprd02.prod.outlook.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<AM4PR02MB1652BE25DB1BDF0F86B93840F03B0@AM4PR02MB1652.eurprd02.prod.outlook.com>
	<CA+u+m-LC8pDin-QKWYEs=bMTZ6vGt8-SOMKVTHwk0Q7K6U5e2Q@mail.gmail.com>
	<2712893.3zGXhzZ5Tl@tjmaciei-mobl1>
	<AM4PR02MB1652CD73001583BA359E8418F0300@AM4PR02MB1652.eurprd02.prod.outlook.com>
Message-ID: <CAOqNE30d8Q84H3A1oT5naUO-AF63+TMLNkXbmiKmyYfPbhFgJQ@mail.gmail.com>

On Tue, Jul 12, 2016 at 3:47 AM, Marco Bubke <Marco.Bubke at qt.io> wrote:

> <snip>, Lets face it, the world is much bigger than Qt, and I think there
> is much to gain if we integrate better with alien libraries.
>
My understanding is that most alien libraries are not binary-based (i.e.,
they are ternary or use other forms of multi-valued-logic (MVL)).

;-))

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160712/caa80e27/attachment.html>

From Jake.Petroules at qt.io  Tue Jul 12 17:25:20 2016
From: Jake.Petroules at qt.io (Jake Petroules)
Date: Tue, 12 Jul 2016 15:25:20 +0000
Subject: [Development] Use of Standard Library containers in Qt source
 code
In-Reply-To: <CAOqNE30d8Q84H3A1oT5naUO-AF63+TMLNkXbmiKmyYfPbhFgJQ@mail.gmail.com>
References: <6461895.FPZQEgjcFK@tjmaciei-mobl1>
	<AM4PR02MB1652BE25DB1BDF0F86B93840F03B0@AM4PR02MB1652.eurprd02.prod.outlook.com>
	<CA+u+m-LC8pDin-QKWYEs=bMTZ6vGt8-SOMKVTHwk0Q7K6U5e2Q@mail.gmail.com>
	<2712893.3zGXhzZ5Tl@tjmaciei-mobl1>
	<AM4PR02MB1652CD73001583BA359E8418F0300@AM4PR02MB1652.eurprd02.prod.outlook.com>
	<CAOqNE30d8Q84H3A1oT5naUO-AF63+TMLNkXbmiKmyYfPbhFgJQ@mail.gmail.com>
Message-ID: <9489423D-3A33-4F2D-8C7F-285C6B6ED073@qt.io>

I always find it hilarious how people start debates about UTF-8 vs UTF-16 in string APIs. Let us not forget that in an ideal world, the QString API wouldn't expose the underlying encoding *at all*, and it would be an implementation detail unknown to users.

See Swift's String class for example: https://developer.apple.com/swift/blog/?id=30

If you're thinking in terms of code units instead of in terms of grapheme clusters, you don't truly understand Unicode. And also end up with historical radioactive waste like UTF-16.

On Jul 12, 2016, at 5:58 AM, charleyb123 . <charleyb123 at gmail.com<mailto:charleyb123 at gmail.com>> wrote:

On Tue, Jul 12, 2016 at 3:47 AM, Marco Bubke <Marco.Bubke at qt.io<mailto:Marco.Bubke at qt.io>> wrote:

<snip>, Lets face it, the world is much bigger than Qt, and I think there is much to gain if we integrate better with alien libraries.

My understanding is that most alien libraries are not binary-based (i.e., they are ternary or use other forms of multi-valued-logic (MVL)).

;-))

--charley

_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development

--
Jake Petroules - jake.petroules at qt.io<mailto:jake.petroules at qt.io>
Consulting Services Engineer - The Qt Company
Qbs build tool evangelist - qbs.io<http://qbs.io>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160712/36c92d57/attachment.html>

From oswald.buddenhagen at qt.io  Wed Jul 13 11:08:07 2016
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Wed, 13 Jul 2016 11:08:07 +0200
Subject: [Development] [FYI] commit/review policy refactored
Message-ID: <20160713090807.GA15458@troll08>

just a heads-up that i (finally) split off the review policy from the
commit policy. see https://wiki.qt.io/Review_Policy .
if you have suggestions for improvement, please discuss them upfront on
irc.

you're expected to read the document even if you're not interested in
actively improving it any time soon. ;)



From Martin.Smith at qt.io  Wed Jul 13 11:57:28 2016
From: Martin.Smith at qt.io (Martin Smith)
Date: Wed, 13 Jul 2016 09:57:28 +0000
Subject: [Development] [FYI] commit/review policy refactored
In-Reply-To: <20160713090807.GA15458@troll08>
References: <20160713090807.GA15458@troll08>
Message-ID: <DB5PR0201MB16077D651C1B5B5D7A35DF6B9F310@DB5PR0201MB1607.eurprd02.prod.outlook.com>

Sometimes I am listed as a reviewer for a code change in Qt that also involves documentation changes. The code change is sometimes outside my expertise, but I assume I have been included to approve the documentation changes. I always give +1 in such cases. Is that correct?


martin

________________________________
From: Development <development-bounces+martin.smith=qt.io at qt-project.org> on behalf of Oswald Buddenhagen <oswald.buddenhagen at qt.io>
Sent: Wednesday, July 13, 2016 11:08:07 AM
To: development at qt-project.org; qt-creator at qt-project.org
Subject: [Development] [FYI] commit/review policy refactored

just a heads-up that i (finally) split off the review policy from the
commit policy. see https://wiki.qt.io/Review_Policy .
if you have suggestions for improvement, please discuss them upfront on
irc.

you're expected to read the document even if you're not interested in
actively improving it any time soon. ;)

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160713/736f0f59/attachment.html>

From oswald.buddenhagen at qt.io  Wed Jul 13 12:14:53 2016
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Wed, 13 Jul 2016 12:14:53 +0200
Subject: [Development] [FYI] commit/review policy refactored
In-Reply-To: <DB5PR0201MB16077D651C1B5B5D7A35DF6B9F310@DB5PR0201MB1607.eurprd02.prod.outlook.com>
References: <20160713090807.GA15458@troll08>
	<DB5PR0201MB16077D651C1B5B5D7A35DF6B9F310@DB5PR0201MB1607.eurprd02.prod.outlook.com>
Message-ID: <20160713101453.GA22702@troll08>

On Wed, Jul 13, 2016 at 11:57:28AM +0200, Martin Smith wrote:
> Sometimes I am listed as a reviewer for a code change in Qt that also involves
> documentation changes. The code change is sometimes outside my expertise, but I
> assume I have been included to approve the documentation changes. I always give
> +1 in such cases. Is that correct?
> 
yes. i added a respective point to the policy.



From Kai.Koehne at qt.io  Wed Jul 13 12:15:44 2016
From: Kai.Koehne at qt.io (Kai Koehne)
Date: Wed, 13 Jul 2016 10:15:44 +0000
Subject: [Development] [FYI] commit/review policy refactored
In-Reply-To: <20160713090807.GA15458@troll08>
References: <20160713090807.GA15458@troll08>
Message-ID: <AM4PR0201MB21315A9A8B74F39A48B9A12998310@AM4PR0201MB2131.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-bounces+kai.koehne=qt.io at qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Wednesday, July 13, 2016 11:08 AM
> To: development at qt-project.org; qt-creator at qt-project.org
> Subject: [Development] [FYI] commit/review policy refactored
> 
> just a heads-up that i (finally) split off the review policy from the commit
> policy. see https://wiki.qt.io/Review_Policy .
> if you have suggestions for improvement, please discuss them upfront on irc.

I prefer to reply here :)

The page is obviously written from the viewpoint of a maintainer. I'd prefer to write
It in a less intimidating way to the contributor, and make it helpful for first time,
inexperienced contributors.



> As a Contributor

Maybe link back to https://wiki.qt.io/Commit_Policy .

"Make sure that your commit matches the Qt Commit Policy.

> 1. Invite relevant reviewers.
> * Always invite the respective domain experts, not somebody convenient.

Scrap the 'not somebody convenient'. It's the job of the reviewer to decide what he can approve.

Instead, mention how one can find the 'domain expert'. Something like

 * Domain experts can usually be found by inspecting the git log, and mailing lists. If in doubt also add the [https://wiki.qt.io/Maintainers Maintainer] of an area if there is one.

> 2. Give reviewers ample time to respond.
> * Unless everyone who can be reasonably expected to have a relevant opinion to offer has already done so, a full working day waiting time is the absolute minimum; three days are reasonable.
> * In particular, give watchers (usually higher-level maintainers) enough time to voice concerns even if you did not explicitly invite them.

The sub-points are only valid if you have a +2 already. So maybe move them down to a section ("If your change got approved"). Rather mention that it can take some working days until added people respond.

> 3. Discuss objections. Do not override a -1 unless there is a broad expert consensus that the objection is unfounded.

A Contributor cannot usually 'override' a -1 - that can only be done by an approver. Maybe your point is though that, if you got a +2, and somebody voiced objections, one shouldn't stage it?

> 4. Do not ignore/fight the Early Warning System. Justify each override.
> [...]

Isn't that limited to Approvers, too?

> 5. Do not approve your own changes.
[...]

Again that's limited to Approvers, and should be in the 'As a Reviewer' section. 


Regards

Kai

From alexander.blasche at qt.io  Wed Jul 13 12:44:13 2016
From: alexander.blasche at qt.io (Alexander Blasche)
Date: Wed, 13 Jul 2016 10:44:13 +0000
Subject: [Development]  Source break policy for function overloads
Message-ID: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>

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, &QModbusClient::timeoutChanged, element.timer.data(), &QTimer::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


From oswald.buddenhagen at qt.io  Wed Jul 13 12:48:51 2016
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Wed, 13 Jul 2016 12:48:51 +0200
Subject: [Development] [FYI] commit/review policy refactored
In-Reply-To: <AM4PR0201MB21315A9A8B74F39A48B9A12998310@AM4PR0201MB2131.eurprd02.prod.outlook.com>
References: <20160713090807.GA15458@troll08>
	<AM4PR0201MB21315A9A8B74F39A48B9A12998310@AM4PR0201MB2131.eurprd02.prod.outlook.com>
Message-ID: <20160713104851.GB22702@troll08>

On Wed, Jul 13, 2016 at 12:15:44PM +0200, Kai Köhne wrote:
> The page is obviously written from the viewpoint of a maintainer. I'd
> prefer to write It in a less intimidating way to the contributor, and
> make it helpful for first time, inexperienced contributors.
> 
first-timers can ask in case of doubt. this is meant to be a policy, not
an intro. somewhat unsurprisingly, i finally took the effort to do this
work because i witnessed several unrelated violations in the last weeks/
months.

> > As a Contributor
> 
> Maybe link back to https://wiki.qt.io/Commit_Policy .
> 
it's linked from the reviewer section, which i find more logical.

> "Make sure that your commit matches the Qt Commit Policy.
> 
> > 1. Invite relevant reviewers.
> > * Always invite the respective domain experts, not somebody convenient.
> 
> Scrap the 'not somebody convenient'. It's the job of the reviewer to decide what he can approve.
> 
it's the responsibility of both sides. don't pretend that these social
dynamics don't exist.

> Instead, mention how one can find the 'domain expert'. Something like
> 
>  * Domain experts can usually be found by inspecting the git log, and mailing lists. If in doubt also add the [https://wiki.qt.io/Maintainers Maintainer] of an area if there is one.
> 
that's already listed in the contribution guidelines and i wanted to
avoid excessive redundancy. i may reconsider, or move parts of the
content. some more linking is necessary anyway.

> > 2. Give reviewers ample time to respond.
> > * Unless everyone who can be reasonably expected to have a relevant opinion to offer has already done so, a full working day waiting time is the absolute minimum; three days are reasonable.
> > * In particular, give watchers (usually higher-level maintainers) enough time to voice concerns even if you did not explicitly invite them.
> 
> The sub-points are only valid if you have a +2 already. So maybe move them down to a section ("If your change got approved"). Rather mention that it can take some working days until added people respond.
> 
that's a good idea. a section about staging and re-staging is needed
anyway.

> > 3. Discuss objections. Do not override a -1 unless there is a broad expert consensus that the objection is unfounded.
> 
> A Contributor cannot usually 'override' a -1 - that can only be done by an approver. Maybe your point is though that, if you got a +2, and somebody voiced objections, one shouldn't stage it?
> 
every approver is a contributor by definition. ;)
but i guess "disregard" is a better word than "override" in this case.

> > 4. Do not ignore/fight the Early Warning System. Justify each override.
> > [...]
> 
> Isn't that limited to Approvers, too?
> 
...

> > 5. Do not approve your own changes.
> [...]
> 
> Again that's limited to Approvers,
>
yes

> and should be in the 'As a Reviewer' section. 
> 
no. it's addressing the contributor.


From Kai.Koehne at qt.io  Wed Jul 13 13:10:20 2016
From: Kai.Koehne at qt.io (Kai Koehne)
Date: Wed, 13 Jul 2016 11:10:20 +0000
Subject: [Development] [Qt-creator] [FYI] commit/review policy refactored
In-Reply-To: <20160713104851.GB22702@troll08>
References: <20160713090807.GA15458@troll08>
	<AM4PR0201MB21315A9A8B74F39A48B9A12998310@AM4PR0201MB2131.eurprd02.prod.outlook.com>
	<20160713104851.GB22702@troll08>
Message-ID: <AM4PR0201MB2131DD89B2BD9A8F0BA2A83498310@AM4PR0201MB2131.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Qt-creator [mailto:qt-creator-bounces+kai.koehne=qt.io at qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Wednesday, July 13, 2016 12:49 PM
> To: development at qt-project.org; qt-creator at qt-project.org
> Subject: Re: [Qt-creator] [Development] [FYI] commit/review policy
> refactored
> 
> On Wed, Jul 13, 2016 at 12:15:44PM +0200, Kai Köhne wrote:
> > The page is obviously written from the viewpoint of a maintainer. I'd
> > prefer to write It in a less intimidating way to the contributor, and
> > make it helpful for first time, inexperienced contributors.
> >
> first-timers can ask in case of doubt. this is meant to be a policy, not an intro.

If we'll have a separate intro page (which is linked from here), then fine with me :)

> somewhat unsurprisingly, i finally took the effort to do this work because i
> witnessed several unrelated violations in the last weeks/ months.

That's what I suspected :)
 
> > > As a Contributor
> >
> > Maybe link back to https://wiki.qt.io/Commit_Policy .
> >
> it's linked from the reviewer section, which i find more logical.

Fair enough.

> > "Make sure that your commit matches the Qt Commit Policy.
> >
> > > 1. Invite relevant reviewers.
> > > * Always invite the respective domain experts, not somebody
> convenient.
> >
> > Scrap the 'not somebody convenient'. It's the job of the reviewer to decide
> what he can approve.
> >
> it's the responsibility of both sides. don't pretend that these social dynamics
> don't exist.

Well, in doubt the blame is always on the approver, not on the contributor. Also,
it's perfectly fine to add 'convenient' people, be it only to check commit logs,
or notify them about stuff. The point is just that they shouldn't approve it if they're 
not 'domain experts' - which is covered in the Approver's section.

> > Instead, mention how one can find the 'domain expert'. Something like
> >
> >  * Domain experts can usually be found by inspecting the git log, and
> mailing lists. If in doubt also add the [https://wiki.qt.io/Maintainers
> Maintainer] of an area if there is one.
> >
> that's already listed in the contribution guidelines and i wanted to avoid
> excessive redundancy. i may reconsider, or move parts of the content. some
> more linking is necessary anyway.

Fine with me if there's another page that's linked.

> > > 2. Give reviewers ample time to respond.
> > > * Unless everyone who can be reasonably expected to have a relevant
> opinion to offer has already done so, a full working day waiting time is the
> absolute minimum; three days are reasonable.
> > > * In particular, give watchers (usually higher-level maintainers) enough
> time to voice concerns even if you did not explicitly invite them.
> >
> > The sub-points are only valid if you have a +2 already. So maybe move
> them down to a section ("If your change got approved"). Rather mention
> that it can take some working days until added people respond.
> >
> that's a good idea. a section about staging and re-staging is needed anyway.
> 
> > > 3. Discuss objections. Do not override a -1 unless there is a broad expert
> consensus that the objection is unfounded.
> >
> > A Contributor cannot usually 'override' a -1 - that can only be done by an
> approver. Maybe your point is though that, if you got a +2, and somebody
> voiced objections, one shouldn't stage it?
> >
> every approver is a contributor by definition. ;) 

Not every contributor is an approver though, so it makes IMO more sense to put stuff specific to approvers into the reviewers section.

Or prefix them with "For contributors that are also approvers:".

> but i guess "disregard" is a
> better word than "override" in this case.

Fine with me. I think 'consensus' instead of 'broad expert consensus' is enough too :)

> > > 4. Do not ignore/fight the Early Warning System. Justify each override.
> > > [...]
> >
> > Isn't that limited to Approvers, too?
> >
> ...
> 
> > > 5. Do not approve your own changes.
> > [...]
> >
> > Again that's limited to Approvers,
> >
> yes
> 
> > and should be in the 'As a Reviewer' section.
> >
> no. it's addressing the contributor.

A contributor that's also an approver, which is the minority.

My point is: This text reads like a proverbial stick you want to use against fellows that overstep their limits (as you perceive it). I'm somewhat skeptical that putting down draconical rules somewhere on the wiki helps on this , but whatever.

My fear is that this is rather read, and taken literally, by first-time/seldom contributors that already feel intimidated by the whole process in the first place ('can't I just append my patch to bugreports?'). So let's make it clear what they have to take care of, and what not.

Regards

Kai

From jedrzej.nowacki at qt.io  Wed Jul 13 13:39:19 2016
From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki)
Date: Wed, 13 Jul 2016 13:39:19 +0200
Subject: [Development] Source break policy for function overloads
In-Reply-To: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
Message-ID: <163158774.0JonikA3mm@42>

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, &QModbusClient::timeoutChanged, element.timer.data(),
> &QTimer::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 at 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

 


From Kai.Koehne at qt.io  Wed Jul 13 13:55:32 2016
From: Kai.Koehne at qt.io (Kai Koehne)
Date: Wed, 13 Jul 2016 11:55:32 +0000
Subject: [Development] Source break policy for function overloads
In-Reply-To: <163158774.0JonikA3mm@42>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
	<163158774.0JonikA3mm@42>
Message-ID: <AM4PR0201MB213155176D024C34A7AB18BD98310@AM4PR0201MB2131.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-bounces+kai.koehne=qt.io at qt-
> [...]
>  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.

We should fix 

https://wiki.qt.io/Qt-Version-Compatibility

then.

I agree though that we can't guarantee source compatibility in all cases
(indirect includes are one example).

We could establish a rule that methods marked with Q_SLOTS shouldn't
be overloaded. Not that this would've helped, since QTimer::setInterval is not 
marked as a slot.

Regards

Kai

From giuseppe.dangelo at kdab.com  Wed Jul 13 14:15:44 2016
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Wed, 13 Jul 2016 14:15:44 +0200
Subject: [Development] Source break policy for function overloads
In-Reply-To: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
Message-ID: <578630F0.4080108@kdab.com>

Il 13/07/2016 12:44, Alexander Blasche ha scritto:
> 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?

While it would be nice not to add overloads to signals and slots, and we 
can keep an eye on that, the fact that you can connect to *any* function 
makes such a policy hard to enforce (unless we start introducing a weird 
naming policy for functions).

Note that this has nothing to do with Qt, but it's a C++ language 
"feature" -- hence I would say that if you care about your source 
compatibility you should start using qOverload in your code base every 
time you take a pointer to a function.

My 2 cents,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160713/aa519212/attachment.bin>

From oswald.buddenhagen at qt.io  Wed Jul 13 15:17:53 2016
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Wed, 13 Jul 2016 15:17:53 +0200
Subject: [Development] [Qt-creator] [FYI] commit/review policy refactored
In-Reply-To: <AM4PR0201MB2131DD89B2BD9A8F0BA2A83498310@AM4PR0201MB2131.eurprd02.prod.outlook.com>
References: <20160713090807.GA15458@troll08>
	<AM4PR0201MB21315A9A8B74F39A48B9A12998310@AM4PR0201MB2131.eurprd02.prod.outlook.com>
	<20160713104851.GB22702@troll08>
	<AM4PR0201MB2131DD89B2BD9A8F0BA2A83498310@AM4PR0201MB2131.eurprd02.prod.outlook.com>
Message-ID: <20160713131753.GA10013@troll08>

On Wed, Jul 13, 2016 at 01:10:20PM +0200, Kai Köhne wrote:
> Oswald Buddenhagen wrote:
> > On Wed, Jul 13, 2016 at 12:15:44PM +0200, Kai Köhne wrote:
> > > "Make sure that your commit matches the Qt Commit Policy.
> > >
> > > > 1. Invite relevant reviewers.
> > > > * Always invite the respective domain experts, not somebody convenient.
> > >
> > > Scrap the 'not somebody convenient'. It's the job of the reviewer to decide
> > > what he can approve.
> > >
> > it's the responsibility of both sides. don't pretend that these social dynamics
> > don't exist.
> 
> Well, in doubt the blame is always on the approver, not on the contributor.
>
when the outcome is predictable, it doesn't matter who is technically
responsible. by inviting a reviewer (in particular, just *one* reviewer)
you're expressing an expectation.

> Also, it's perfectly fine to add 'convenient' people, be it only to
> check commit logs, or notify them about stuff.
>
then you're not inviting them to an actual review, and you're expected
to state that, and disregard their approval in case they still give it.

> > every approver is a contributor by definition. ;) 
> 
> Not every contributor is an approver though, so it makes IMO more sense to put stuff specific to approvers into the reviewers section.
> 
> Or prefix them with "For contributors that are also approvers:".
> 
you're mixing things up. this is about the roles in any given
contribution, not about the titles anyone may hold. this is indicated by
the use of definite articles in the section headers (apart from the fact
that "reviewer" is no defined title in the first place).

> I think 'consensus' instead of 'broad expert consensus' is enough too :)
> 
the point was about clarifying that the opinion of one actual expert
weights more than half a dozen me-too's from non-experts.

> My point is: This text reads like a proverbial stick you want to use
> against fellows that overstep their limits (as you perceive it).
>
that's exactly the point of anything that calls itself a policy.
otherwise it would be a convention.

> I'm somewhat skeptical that putting down draconical rules somewhere on
> the wiki helps on this , but whatever.
> 
no, but it helps when it's written down clearly and the majority gives
the impression of expecting that these rules are followed. given that
this page just codifies the usual practice of the last five years, it
seems reasonable to think that this is the case.



From Simon.Hausmann at qt.io  Wed Jul 13 15:55:20 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Wed, 13 Jul 2016 13:55:20 +0000
Subject: [Development] Source break policy for function overloads
In-Reply-To: <163158774.0JonikA3mm@42>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>,
	<163158774.0JonikA3mm@42>
Message-ID: <DB4PR02MB05414D8ADE629FB72C5F02B48C310@DB4PR02MB0541.eurprd02.prod.outlook.com>

Hi,


I think in the interest of our users and the popularity of Qt, the maintenance of source compatibility

should be a supremely important goal.


That said, breakages of source compatibility for the sake of cleanups appear to have been accepted by

approvers in the past.


I think if we allow source compatibility breakages like the one here (overloaded slot added), then I think

it should require a prominent notice in the changelog / release notes. One can argue that with includes

it's pretty easy to "fix" the error, but with the QObject::connect error on ambiguous overloads the error

messages are crap and I think we should make an effort help our users.



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Jędrzej Nowacki <jedrzej.nowacki at qt.io>
Sent: Wednesday, July 13, 2016 1:39:19 PM
To: development at qt-project.org
Subject: Re: [Development] Source break policy for function overloads

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, &QModbusClient::timeoutChanged, element.timer.data(),
> &QTimer::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 at 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 at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160713/1f582ba3/attachment.html>

From giuseppe.dangelo at kdab.com  Wed Jul 13 16:16:39 2016
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Wed, 13 Jul 2016 16:16:39 +0200
Subject: [Development] Source break policy for function overloads
In-Reply-To: <DB4PR02MB05414D8ADE629FB72C5F02B48C310@DB4PR02MB0541.eurprd02.prod.outlook.com>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
	<163158774.0JonikA3mm@42>
	<DB4PR02MB05414D8ADE629FB72C5F02B48C310@DB4PR02MB0541.eurprd02.prod.outlook.com>
Message-ID: <57864D47.1010506@kdab.com>

Il 13/07/2016 15:55, Simon Hausmann ha scritto:
>
> I think if we allow source compatibility breakages like the one here
> (overloaded slot added), then I think
>
> it should require a prominent notice in the changelog / release notes.

Note that setInterval is not even a slot (but an overload of start(), a 
slot, was also added in the same commit). Do we need to add changelog 
notes for *any* overload added to free functions or QObject subclass 
member functions?

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160713/95fd44bb/attachment.bin>

From Simon.Hausmann at qt.io  Wed Jul 13 16:30:52 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Wed, 13 Jul 2016 14:30:52 +0000
Subject: [Development] Source break policy for function overloads
In-Reply-To: <57864D47.1010506@kdab.com>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
	<163158774.0JonikA3mm@42>
	<DB4PR02MB05414D8ADE629FB72C5F02B48C310@DB4PR02MB0541.eurprd02.prod.outlook.com>,
	<57864D47.1010506@kdab.com>
Message-ID: <DB4PR02MB0541B70C5EC023FD8690D4C08C310@DB4PR02MB0541.eurprd02.prod.outlook.com>

Hi,


I suppose that if this is the first time an overload is added, then the risk of ambiguity exists. It

seems that this is the case here. If released API has overloads and a new overload is added,

then the caller code using QObject::connect would already use qOverload or similar, right? In that

case perhaps it is not necessary to document the addition as source compatibility may be preserved.



It all comes down to the question: What impression do we want to give people when they upgrade to

a newer version of Qt?



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>
Sent: Wednesday, July 13, 2016 4:16:39 PM
To: development at qt-project.org
Subject: Re: [Development] Source break policy for function overloads

Il 13/07/2016 15:55, Simon Hausmann ha scritto:
>
> I think if we allow source compatibility breakages like the one here
> (overloaded slot added), then I think
>
> it should require a prominent notice in the changelog / release notes.

Note that setInterval is not even a slot (but an overload of start(), a
slot, was also added in the same commit). Do we need to add changelog
notes for *any* overload added to free functions or QObject subclass
member functions?

Cheers,
--
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160713/9bc7e0a6/attachment.html>

From ola at silentwings.no  Wed Jul 13 16:45:05 2016
From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=)
Date: Wed, 13 Jul 2016 16:45:05 +0200
Subject: [Development] Source break policy for function overloads
In-Reply-To: <DB4PR02MB0541B70C5EC023FD8690D4C08C310@DB4PR02MB0541.eurprd02.prod.outlook.com>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
	<163158774.0JonikA3mm@42>
	<DB4PR02MB05414D8ADE629FB72C5F02B48C310@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<57864D47.1010506@kdab.com>
	<DB4PR02MB0541B70C5EC023FD8690D4C08C310@DB4PR02MB0541.eurprd02.prod.outlook.com>
Message-ID: <CAMEHBtOQq4-Ghg+5s8Xt5pBr8xYtwZBYWjzzNo5hmxh5U3hXmg@mail.gmail.com>

2016-07-13 16:30 GMT+02:00 Simon Hausmann <Simon.Hausmann at qt.io>:

>
> It all comes down to the question: What impression do we want to give
> people when they upgrade to
>
> a newer version of Qt?
>
>
>
In my experience, I first had problems with this when I converted to the
new "connect" syntax some years ago and hit the overloaded "error"
functions in QAbstractSocket where just one of them is a signal. It cost me
quite some time figuring out how to solve that, ending with getting help on
the interest mailing list. If qOverload would have existed back then, I
would not have known that I should or could use that either.

So if similar problems appear when upgrading Qt because of added
functionality it will cost developers a lot of time. The compiler error
will probably not point to a suggested solution like "use qOverload" or
"use
static_cast<void(QTcpSocket::*)(QAbstractSocket::SocketError)>(&QTcpSocket::error)"
instead.

In my opinion, please try to avoid these overloads as much as possible.

Cheers,
Ola
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160713/41ab289a/attachment.html>

From sschilz at pasco.com  Wed Jul 13 18:08:11 2016
From: sschilz at pasco.com (Steve Schilz)
Date: Wed, 13 Jul 2016 16:08:11 +0000
Subject: [Development] QWebEngine - H.264 playback, proprietary codecs.
Message-ID: <6CAA1D13-1848-483C-84EA-857BE73C7CDF@pasco.com>

We are using QWebEngine to drive a hybrid app (Html5 + Javascript + C++) on windows.  According to QWebEngineFeatures Doc, http://doc.qt.io/qt-5/qtwebengine-features.html#pepper-plugin-api
You must pass a flag to qmake, WEBENGINE_CONFIG+=use_proprietary_codecs, and build Qt from source yourself in order to support h.264 video decoding.

In researching this, I became aware that Cisco provides a downloadable binary codec, where Cisco pays the MPEG-LA royalties.   Apparently this is the method used
To provide h.264 playback in Firefox.  If you watch the intellectual property rights video at http://vimeo.com/cullenfluffyjennings/openh264-ipr, they explain why they
Did this, and how you can even make changes to the codec via open source if needed.

Would it make sense for QWebEngine to support this codec, in order to be able to provide ‘out of the box’ (via download at end user’s computer), support for h.264 playback in <video> tags?


Steve Schilz
Software Engineer
PASCO scientific
10101 Foothills Blvd.
Roseville, CA. 95747 USA
916-786-3800 x8271
sschilz at pasco.com<mailto:sschilz at pasco.com>
www.pasco.com<http://www.pasco.com/>
think science

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160713/7a09daa8/attachment.html>

From thiago.macieira at intel.com  Wed Jul 13 18:47:28 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 13 Jul 2016 09:47:28 -0700
Subject: [Development] Source break policy for function overloads
In-Reply-To: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
Message-ID: <6279245.f20ygS2Rua@tjmaciei-mobl1>

Em quarta-feira, 13 de julho de 2016, às 10:44:13 PDT, Alexander Blasche 
escreveu:
> 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, &QModbusClient::timeoutChanged, element.timer.data(),
> &QTimer::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?

We do have this policy since 5.0 that we have to be careful about overloads 
due to the connect syntax. The breakage was accidental and not intended.

I did intend to add overloads, as they're nice to use, I just hadn't 
considered the consequences.

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



From thiago.macieira at intel.com  Wed Jul 13 18:51:52 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 13 Jul 2016 09:51:52 -0700
Subject: [Development] Source break policy for function overloads
In-Reply-To: <CAMEHBtOQq4-Ghg+5s8Xt5pBr8xYtwZBYWjzzNo5hmxh5U3hXmg@mail.gmail.com>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
	<DB4PR02MB0541B70C5EC023FD8690D4C08C310@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<CAMEHBtOQq4-Ghg+5s8Xt5pBr8xYtwZBYWjzzNo5hmxh5U3hXmg@mail.gmail.com>
Message-ID: <3379608.D2vZPpJDEZ@tjmaciei-mobl1>

Em quarta-feira, 13 de julho de 2016, às 16:45:05 PDT, Ola Røer Thorsen 
escreveu:
> In my opinion, please try to avoid these overloads as much as possible.

That's the current policy.

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



From thiago.macieira at intel.com  Wed Jul 13 18:54:43 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 13 Jul 2016 09:54:43 -0700
Subject: [Development] QWebEngine - H.264 playback, proprietary codecs.
In-Reply-To: <6CAA1D13-1848-483C-84EA-857BE73C7CDF@pasco.com>
References: <6CAA1D13-1848-483C-84EA-857BE73C7CDF@pasco.com>
Message-ID: <12040212.ITR1EgX9IA@tjmaciei-mobl1>

Em quarta-feira, 13 de julho de 2016, às 16:08:11 PDT, Steve Schilz escreveu:
> Would it make sense for QWebEngine to support this codec, in order to be
> able to provide ‘out of the box’ (via download at end user’s computer),
> support for h.264 playback in <video> tags?

If we're able to ship a build with no codecs, but for which a user could 
download a plugin and just drop-in to their application to enable the feature, 
we should do it.

That's exactly what we do for other technologies like:
 * SSL (you need to install OpenSSL)
 * MySQL and Postgres databases (build plugins)

Note that QtMultimedia uses GStreamer as a backend, which already supports 
plugins, including proprietary ones. It's just Chromium/Blink that do things 
differently.

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



From kde at carewolf.com  Wed Jul 13 19:21:16 2016
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Wed, 13 Jul 2016 19:21:16 +0200
Subject: [Development] QWebEngine - H.264 playback, proprietary codecs.
In-Reply-To: <6CAA1D13-1848-483C-84EA-857BE73C7CDF@pasco.com>
References: <6CAA1D13-1848-483C-84EA-857BE73C7CDF@pasco.com>
Message-ID: <201607131921.16144.kde@carewolf.com>

On Wednesday 13 July 2016, Steve Schilz wrote:
> We are using QWebEngine to drive a hybrid app (Html5 + Javascript + C++) on
> windows.  According to QWebEngineFeatures Doc,
> http://doc.qt.io/qt-5/qtwebengine-features.html#pepper-plugin-api You must
> pass a flag to qmake, WEBENGINE_CONFIG+=use_proprietary_codecs, and build
> Qt from source yourself in order to support h.264 video decoding.
> 
> In researching this, I became aware that Cisco provides a downloadable
> binary codec, where Cisco pays the MPEG-LA royalties.   Apparently this is
> the method used To provide h.264 playback in Firefox.  If you watch the
> intellectual property rights video at
> http://vimeo.com/cullenfluffyjennings/openh264-ipr, they explain why they
> Did this, and how you can even make changes to the codec via open source
> if needed.
> 
> Would it make sense for QWebEngine to support this codec, in order to be
> able to provide ‘out of the box’ (via download at end user’s computer),
> support for h.264 playback in <video> tags?
> 
That sounds a bit complicated, since it needs to hook into Chromiums media 
backend and have a download mechanism.

 Note activating it the codecs is not a matter of cost. AFAIK the h.264 and 
h.265 codecs are currently patented but royalty free to decode. This makes it 
possible for our customers to activate them without paying anyway. This is 
however just the status quo, and I am not sure I want to risk enabling 
something that might make the open-source package something that you need to 
pay for in the future, which is why we prefer to stick with the same codecs 
Google makes available in their free open source browser Chromium.

I would be more interested in making it easier to enable, or maybe offer 
somehow. It is just something we have to make sure we offer without 
guaranteeing it is and will remain free. 

`Allan


From marc.mutz at kdab.com  Wed Jul 13 20:10:21 2016
From: marc.mutz at kdab.com (Marc Mutz)
Date: Wed, 13 Jul 2016 20:10:21 +0200
Subject: [Development] Source break policy for function overloads
In-Reply-To: <6279245.f20ygS2Rua@tjmaciei-mobl1>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
	<6279245.f20ygS2Rua@tjmaciei-mobl1>
Message-ID: <201607132010.26585.marc.mutz@kdab.com>

On Wednesday 13 July 2016 18:47:28 Thiago Macieira wrote:
> We do have this policy since 5.0 that we have to be careful about
> overloads  due to the connect syntax. The breakage was accidental and not
> intended.
> 
> I did intend to add overloads, as they're nice to use, I just hadn't 
> considered the consequences.

When I reported an SC breakage from an added overload in Qt 4, I got back a 
WONTFIX.

I agree.

There are two problems with adding overloads:

1. You may make existing calls ambiguous.
   This should be prevented as much as possible (by adding sufficiently many
   additional overloads to restore unambiguity).

2. You can make taking a function pointer ambiguous when adding the 2nd
   overload. This cannot be prevented, and we shouldn't strive to
   (effectively) ban overloads because of it. If examples and other docs
   would consistently use qOverload, instead of pretending that the naked
   addressof operator is sufficient, our users wouldn't hit the compiler
   errors mentioned by Ola.

It should also be noted that there are two categories of SiCs:

a. those that can be fixed client-side without breaking compat with older Qt
   versions, and
b. those which cannot

IMO, SiCs of type (a) are acceptable, those of type (b) are obviously no-no's.

Adding an overload (both cases: 1 + 2 above) is type (a), so is acceptable. 
Adding explicit to a ctor that should have been but wasn't is also SiC Type 
(a). In these cases, code that breaks is code that deserves to be broken, 
because it was brittle.

Renaming a public inline function of a non-exported class is BC, but SiC Type 
(b), so not acceptable.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts


From rich at kde.org  Thu Jul 14 00:29:42 2016
From: rich at kde.org (Richard Moore)
Date: Wed, 13 Jul 2016 23:29:42 +0100
Subject: [Development] Source break policy for function overloads
In-Reply-To: <201607132010.26585.marc.mutz@kdab.com>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
	<6279245.f20ygS2Rua@tjmaciei-mobl1>
	<201607132010.26585.marc.mutz@kdab.com>
Message-ID: <CAMp7mVtAqy6N=JJp-h+KsAkL7nxv7-BqNU0FmDFZV=R7pr0ueg@mail.gmail.com>

On 13 July 2016 at 19:10, Marc Mutz <marc.mutz at kdab.com> wrote:

> Renaming a public inline function of a non-exported class is BC, but SiC
> Type
> (b), so not acceptable.
>

​Good analysis, however isn't the compiler allowed to not inline stuff too
which would mean this example is not b/c either.
​

​Cheers

Rich.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160713/201c5274/attachment.html>

From thiago.macieira at intel.com  Thu Jul 14 00:59:51 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 13 Jul 2016 15:59:51 -0700
Subject: [Development] Source break policy for function overloads
In-Reply-To: <CAMp7mVtAqy6N=JJp-h+KsAkL7nxv7-BqNU0FmDFZV=R7pr0ueg@mail.gmail.com>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
	<201607132010.26585.marc.mutz@kdab.com>
	<CAMp7mVtAqy6N=JJp-h+KsAkL7nxv7-BqNU0FmDFZV=R7pr0ueg@mail.gmail.com>
Message-ID: <2640266.ChRLZajFm4@tjmaciei-mobl1>

Em quarta-feira, 13 de julho de 2016, às 23:29:42 PDT, Richard Moore escreveu:
> On 13 July 2016 at 19:10, Marc Mutz <marc.mutz at kdab.com> wrote:
> > Renaming a public inline function of a non-exported class is BC, but SiC
> > Type
> > (b), so not acceptable.
> 
> ​Good analysis, however isn't the compiler allowed to not inline stuff too
> which would mean this example is not b/c either.

Indeed, but compilers need to emit the out-of-line copy if they decided not to 
inline. That means the previous copy exists for code that wasn't recompiled, 
regardless of whether the class has changed since. That is why it's BC but not 
SC.

This applies even for MSVC, for non-exported classes (Marc's case). For 
exported classes, MSVC in debug mode (unlike the IA-64 C++ ABI) calls the out-
of-line copy without emitting it, which the DLL that exported the class must 
have emitted. That is why removing inline functions in exported classes is not 
BC.

It's also why MSVC exports too much from template classes, if you derive from 
it and export (QPolygon and QVector case). I believe it has a nasty Level 4 
warning, about dllexporting a class that isn't dllexported, but we have turned 
it off for at least 10 years.

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



From thomas.senyk at pelagicore.com  Thu Jul 14 16:33:26 2016
From: thomas.senyk at pelagicore.com (Thomas Senyk)
Date: Thu, 14 Jul 2016 16:33:26 +0200
Subject: [Development] leak in QMetaObject?
Message-ID: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>

Hi,

I lately wanted to validate that a connecting&disconnecting to a lambda
will not leak the lambda object .. and found that more then that is leaked.

Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv

After the 10million connections are executed and disconnected (all of
them a successful), I assume a drop in memory consumption and more
importantly a drop of cpu load to close to 0%.

I see neither one nor the other. I see continues 100% consume with no
memory consumption drop what so ever.

I did a quick peak into QMetaObject::activate and it seems no clean up
happened .. the list returned in
  list = &connectionLists->at(signal_index);
  (line #3660 in 5.6 checkout from today)

seems rather long! (10million?)

However all "if (!c->receiver)" shows no receiver and therefor will
continue right away .. at least

Is this expected? A bug? ... I'm happy to fill a bug report, I just
wanted to get some feedback, maybe I'm just doing something wrong



Some background:
I wanted to check if a single-shot-connection (connection to a signal
and disconnect at first execute, using a lambda as slot) would be a
feasible thing to do.

Greets
Thomas


From dangelog at gmail.com  Thu Jul 14 16:48:09 2016
From: dangelog at gmail.com (Giuseppe D'Angelo)
Date: Thu, 14 Jul 2016 16:48:09 +0200
Subject: [Development] leak in QMetaObject?
In-Reply-To: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
Message-ID: <CAPm+cvhKqF=ax5kTL0OSjsQzLvftoid4H1dxv6weXDKdfv99rQ@mail.gmail.com>

On Thu, Jul 14, 2016 at 4:33 PM, Thomas Senyk
<thomas.senyk at pelagicore.com> wrote:
>
> Is this expected? A bug? ... I'm happy to fill a bug report, I just
> wanted to get some feedback, maybe I'm just doing something wrong

First and foremost, which Qt version are you using? :)

Cheers,
-- 
Giuseppe D'Angelo


From olivier at woboq.com  Thu Jul 14 17:10:40 2016
From: olivier at woboq.com (Olivier Goffart)
Date: Thu, 14 Jul 2016 17:10:40 +0200
Subject: [Development] leak in QMetaObject?
In-Reply-To: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
Message-ID: <2341736.oJ5JHeR8WT@maurice>

On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote:
> Hi,
> 
> I lately wanted to validate that a connecting&disconnecting to a lambda
> will not leak the lambda object .. and found that more then that is leaked.
> 
> Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv
> 
> After the 10million connections are executed and disconnected (all of
> them a successful), I assume a drop in memory consumption and more
> importantly a drop of cpu load to close to 0%.
> 
> I see neither one nor the other. I see continues 100% consume with no
> memory consumption drop what so ever.
> 
> I did a quick peak into QMetaObject::activate and it seems no clean up
> happened .. the list returned in
>   list = &connectionLists->at(signal_index);
>   (line #3660 in 5.6 checkout from today)
> 
> seems rather long! (10million?)
> 
> However all "if (!c->receiver)" shows no receiver and therefor will
> continue right away .. at least
> 
> Is this expected? A bug? ... I'm happy to fill a bug report, I just
> wanted to get some feedback, maybe I'm just doing something wrong


The lambda object and its capture is destroyed by the call to 
  slotObj->destroyIfLastRef()

The internal data structre (QObjectPrivate::Connection) is deleted by 
QObjectPrivate::cleanConnectionLists which is actually only called when 
a new connection is made to this object.

I don't think there is a leak, but it is true that some memory is only free'ed 
when you add new connection or that the object is destroyed. (but the lambda 
object is destroyed right after the disconnection)


> Some background:
> I wanted to check if a single-shot-connection (connection to a signal
> and disconnect at first execute, using a lambda as slot) would be a
> feasible thing to do.

You can do that already:

 QTimer::sigleShot(100, [] { qDebug() << "hello"; });

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org




From andre at familiesomers.nl  Thu Jul 14 17:18:50 2016
From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=)
Date: Thu, 14 Jul 2016 17:18:50 +0200
Subject: [Development] leak in QMetaObject?
In-Reply-To: <2341736.oJ5JHeR8WT@maurice>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<2341736.oJ5JHeR8WT@maurice>
Message-ID: <46fd590e-4995-7c1c-1ecd-98e7775b734d@familiesomers.nl>



Op 14/07/2016 om 17:10 schreef Olivier Goffart:
> On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote:
>> Hi,
>>
>> I lately wanted to validate that a connecting&disconnecting to a lambda
>> will not leak the lambda object .. and found that more then that is leaked.
>>
>> Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv
>>
>> After the 10million connections are executed and disconnected (all of
>> them a successful), I assume a drop in memory consumption and more
>> importantly a drop of cpu load to close to 0%.
>>
>> I see neither one nor the other. I see continues 100% consume with no
>> memory consumption drop what so ever.
>>
>> I did a quick peak into QMetaObject::activate and it seems no clean up
>> happened .. the list returned in
>>    list = &connectionLists->at(signal_index);
>>    (line #3660 in 5.6 checkout from today)
>>
>> seems rather long! (10million?)
>>
>> However all "if (!c->receiver)" shows no receiver and therefor will
>> continue right away .. at least
>>
>> Is this expected? A bug? ... I'm happy to fill a bug report, I just
>> wanted to get some feedback, maybe I'm just doing something wrong
>
> The lambda object and its capture is destroyed by the call to
>    slotObj->destroyIfLastRef()
>
> The internal data structre (QObjectPrivate::Connection) is deleted by
> QObjectPrivate::cleanConnectionLists which is actually only called when
> a new connection is made to this object.
>
> I don't think there is a leak, but it is true that some memory is only free'ed
> when you add new connection or that the object is destroyed. (but the lambda
> object is destroyed right after the disconnection)
>
>
>> Some background:
>> I wanted to check if a single-shot-connection (connection to a signal
>> and disconnect at first execute, using a lambda as slot) would be a
>> feasible thing to do.
> You can do that already:
>
>   QTimer::sigleShot(100, [] { qDebug() << "hello"; });
>
That's not the same thing.
This looks like my earlier suggestion 
https://bugreports.qt.io/browse/QTBUG-44219

André



From thomas.senyk at pelagicore.com  Thu Jul 14 17:45:58 2016
From: thomas.senyk at pelagicore.com (Thomas Senyk)
Date: Thu, 14 Jul 2016 17:45:58 +0200
Subject: [Development] leak in QMetaObject?
In-Reply-To: <46fd590e-4995-7c1c-1ecd-98e7775b734d@familiesomers.nl>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<2341736.oJ5JHeR8WT@maurice>
	<46fd590e-4995-7c1c-1ecd-98e7775b734d@familiesomers.nl>
Message-ID: <25dd1da6-1eac-4b18-b024-74bf3b527494@pelagicore.com>

On 14.07.2016 17:18, André Somers wrote:
> 
> 
> Op 14/07/2016 om 17:10 schreef Olivier Goffart:
>> On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote:
>>> Hi,
>>>
>>> I lately wanted to validate that a connecting&disconnecting to a lambda
>>> will not leak the lambda object .. and found that more then that is
>>> leaked.
>>>
>>> Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv
>>>
>>> After the 10million connections are executed and disconnected (all of
>>> them a successful), I assume a drop in memory consumption and more
>>> importantly a drop of cpu load to close to 0%.
>>>
>>> I see neither one nor the other. I see continues 100% consume with no
>>> memory consumption drop what so ever.
>>>
>>> I did a quick peak into QMetaObject::activate and it seems no clean up
>>> happened .. the list returned in
>>>    list = &connectionLists->at(signal_index);
>>>    (line #3660 in 5.6 checkout from today)
>>>
>>> seems rather long! (10million?)
>>>
>>> However all "if (!c->receiver)" shows no receiver and therefor will
>>> continue right away .. at least
>>>
>>> Is this expected? A bug? ... I'm happy to fill a bug report, I just
>>> wanted to get some feedback, maybe I'm just doing something wrong
>>
>> The lambda object and its capture is destroyed by the call to
>>    slotObj->destroyIfLastRef()
>>
>> The internal data structre (QObjectPrivate::Connection) is deleted by
>> QObjectPrivate::cleanConnectionLists which is actually only called when
>> a new connection is made to this object.
>>
>> I don't think there is a leak, but it is true that some memory is only
>> free'ed
>> when you add new connection or that the object is destroyed. (but the
>> lambda
>> object is destroyed right after the disconnection)

Then this:
http://paste.ofcode.org/37rxyitynhEqi5gira88hR9

should "fix" it? .. but I still see 100% cpu and same memory consumption?


>>
>>
>>> Some background:
>>> I wanted to check if a single-shot-connection (connection to a signal
>>> and disconnect at first execute, using a lambda as slot) would be a
>>> feasible thing to do.
>> You can do that already:
>>
>>   QTimer::sigleShot(100, [] { qDebug() << "hello"; });
>>
> That's not the same thing.
> This looks like my earlier suggestion
> https://bugreports.qt.io/browse/QTBUG-44219

+1, this is similar but not the same,

> 
> André
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



From thomas.senyk at pelagicore.com  Thu Jul 14 17:48:41 2016
From: thomas.senyk at pelagicore.com (Thomas Senyk)
Date: Thu, 14 Jul 2016 17:48:41 +0200
Subject: [Development] leak in QMetaObject?
In-Reply-To: <CAPm+cvhKqF=ax5kTL0OSjsQzLvftoid4H1dxv6weXDKdfv99rQ@mail.gmail.com>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<CAPm+cvhKqF=ax5kTL0OSjsQzLvftoid4H1dxv6weXDKdfv99rQ@mail.gmail.com>
Message-ID: <eb072189-38e7-cfe0-5ca9-b81315829a0a@pelagicore.com>

On 14.07.2016 16:48, Giuseppe D'Angelo wrote:
> On Thu, Jul 14, 2016 at 4:33 PM, Thomas Senyk
> <thomas.senyk at pelagicore.com> wrote:
>>
>> Is this expected? A bug? ... I'm happy to fill a bug report, I just
>> wanted to get some feedback, maybe I'm just doing something wrong
> 
> First and foremost, which Qt version are you using? :)
> 

Ah yes .. I only mentioned it in the sub-text :)
5.6 branch from git (checkout from this morning)




From thiago.macieira at intel.com  Thu Jul 14 18:25:48 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 14 Jul 2016 09:25:48 -0700
Subject: [Development] leak in QMetaObject?
In-Reply-To: <25dd1da6-1eac-4b18-b024-74bf3b527494@pelagicore.com>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<46fd590e-4995-7c1c-1ecd-98e7775b734d@familiesomers.nl>
	<25dd1da6-1eac-4b18-b024-74bf3b527494@pelagicore.com>
Message-ID: <1924454.VinU0ac6of@tjmaciei-mobl1>

On quinta-feira, 14 de julho de 2016 17:45:58 PDT Thomas Senyk wrote:
> should "fix" it? .. but I still see 100% cpu and same memory consumption?

Can you attach the debugger to see what it is still doing after you're done?

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



From thomas.senyk at pelagicore.com  Thu Jul 14 18:37:17 2016
From: thomas.senyk at pelagicore.com (Thomas Senyk)
Date: Thu, 14 Jul 2016 18:37:17 +0200
Subject: [Development] leak in QMetaObject?
In-Reply-To: <1924454.VinU0ac6of@tjmaciei-mobl1>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<46fd590e-4995-7c1c-1ecd-98e7775b734d@familiesomers.nl>
	<25dd1da6-1eac-4b18-b024-74bf3b527494@pelagicore.com>
	<1924454.VinU0ac6of@tjmaciei-mobl1>
Message-ID: <d0392894-192e-e4aa-9e7a-57e0b12481bb@pelagicore.com>

On 14.07.2016 18:25, Thiago Macieira wrote:
> On quinta-feira, 14 de julho de 2016 17:45:58 PDT Thomas Senyk wrote:
>> should "fix" it? .. but I still see 100% cpu and same memory consumption?
> 
> Can you attach the debugger to see what it is still doing after you're done?
> 

Still the same, goes in circles around in QMetaObject::activate

#3671 => #3673 =>  if (!c->receiver) continue => while => ...
... pressing F10 for a while doesn't let you out of that (short) cycle.

If you want to know (I know it's not saying much) the values for
list->first and list->last: @0x1529ac0, @0x6a3a3250


Is that what you wanted to know? If I misunderstood, please clarify :)

Greets
Thomas



From thiago.macieira at intel.com  Thu Jul 14 18:56:39 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 14 Jul 2016 09:56:39 -0700
Subject: [Development] leak in QMetaObject?
In-Reply-To: <d0392894-192e-e4aa-9e7a-57e0b12481bb@pelagicore.com>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<1924454.VinU0ac6of@tjmaciei-mobl1>
	<d0392894-192e-e4aa-9e7a-57e0b12481bb@pelagicore.com>
Message-ID: <4953729.Zy6zGIe2KL@tjmaciei-mobl1>

On quinta-feira, 14 de julho de 2016 18:37:17 PDT Thomas Senyk wrote:
> On 14.07.2016 18:25, Thiago Macieira wrote:
> > On quinta-feira, 14 de julho de 2016 17:45:58 PDT Thomas Senyk wrote:
> >> should "fix" it? .. but I still see 100% cpu and same memory consumption?
> > 
> > Can you attach the debugger to see what it is still doing after you're
> > done?
> Still the same, goes in circles around in QMetaObject::activate
> 
> #3671 => #3673 =>  if (!c->receiver) continue => while => ...
> ... pressing F10 for a while doesn't let you out of that (short) cycle.
> 
> If you want to know (I know it's not saying much) the values for
> list->first and list->last: @0x1529ac0, @0x6a3a3250
> 
> 
> Is that what you wanted to know? If I misunderstood, please clarify :)

I wanted a backtrace. Are you saying the trace is 3700 frames deep?

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



From thomas.senyk at pelagicore.com  Thu Jul 14 19:08:11 2016
From: thomas.senyk at pelagicore.com (Thomas Senyk)
Date: Thu, 14 Jul 2016 19:08:11 +0200
Subject: [Development] leak in QMetaObject?
In-Reply-To: <4953729.Zy6zGIe2KL@tjmaciei-mobl1>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<1924454.VinU0ac6of@tjmaciei-mobl1>
	<d0392894-192e-e4aa-9e7a-57e0b12481bb@pelagicore.com>
	<4953729.Zy6zGIe2KL@tjmaciei-mobl1>
Message-ID: <fe95a8e3-c0df-9194-8d88-28c94740be4f@pelagicore.com>

On 14.07.2016 18:56, Thiago Macieira wrote:
> On quinta-feira, 14 de julho de 2016 18:37:17 PDT Thomas Senyk wrote:
>> On 14.07.2016 18:25, Thiago Macieira wrote:
>>> On quinta-feira, 14 de julho de 2016 17:45:58 PDT Thomas Senyk wrote:
>>>> should "fix" it? .. but I still see 100% cpu and same memory consumption?
>>>
>>> Can you attach the debugger to see what it is still doing after you're
>>> done?
>> Still the same, goes in circles around in QMetaObject::activate
>>
>> #3671 => #3673 =>  if (!c->receiver) continue => while => ...
>> ... pressing F10 for a while doesn't let you out of that (short) cycle.
>>
>> If you want to know (I know it's not saying much) the values for
>> list->first and list->last: @0x1529ac0, @0x6a3a3250
>>
>>
>> Is that what you wanted to know? If I misunderstood, please clarify :)
> 
> I wanted a backtrace. Are you saying the trace is 3700 frames deep?
> 

Sorry that was line numbers :) No it's not.

http://paste.ofcode.org/u3gGqxAfX9hWefeUszDEx

About to generate a callgrind output.

Greets
Thomas


From thomas.senyk at pelagicore.com  Thu Jul 14 19:29:42 2016
From: thomas.senyk at pelagicore.com (Thomas Senyk)
Date: Thu, 14 Jul 2016 19:29:42 +0200
Subject: [Development] leak in QMetaObject?
In-Reply-To: <fe95a8e3-c0df-9194-8d88-28c94740be4f@pelagicore.com>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<1924454.VinU0ac6of@tjmaciei-mobl1>
	<d0392894-192e-e4aa-9e7a-57e0b12481bb@pelagicore.com>
	<4953729.Zy6zGIe2KL@tjmaciei-mobl1>
	<fe95a8e3-c0df-9194-8d88-28c94740be4f@pelagicore.com>
Message-ID: <0e5faaf2-736a-4442-27e4-97471cbdd431@pelagicore.com>

On 14.07.2016 19:08, Thomas Senyk wrote:
> On 14.07.2016 18:56, Thiago Macieira wrote:
>> On quinta-feira, 14 de julho de 2016 18:37:17 PDT Thomas Senyk wrote:
>>> On 14.07.2016 18:25, Thiago Macieira wrote:
>>>> On quinta-feira, 14 de julho de 2016 17:45:58 PDT Thomas Senyk wrote:
>>>>> should "fix" it? .. but I still see 100% cpu and same memory consumption?
>>>>
>>>> Can you attach the debugger to see what it is still doing after you're
>>>> done?
>>> Still the same, goes in circles around in QMetaObject::activate
>>>
>>> #3671 => #3673 =>  if (!c->receiver) continue => while => ...
>>> ... pressing F10 for a while doesn't let you out of that (short) cycle.
>>>
>>> If you want to know (I know it's not saying much) the values for
>>> list->first and list->last: @0x1529ac0, @0x6a3a3250
>>>
>>>
>>> Is that what you wanted to know? If I misunderstood, please clarify :)
>>
>> I wanted a backtrace. Are you saying the trace is 3700 frames deep?
>>
> 
> Sorry that was line numbers :) No it's not.
> 
> http://paste.ofcode.org/u3gGqxAfX9hWefeUszDEx
> 
> About to generate a callgrind output.

attached

-------------- next part --------------
version: 1
creator: callgrind-3.11.0
pid: 20467
cmd:  ./LambdaDisconnect
part: 1


desc: I1 cache: 
desc: D1 cache: 
desc: LL cache: 

desc: Timerange: Basic block 0 - 40467613674
desc: Trigger: Program termination

positions: line
events: Ir
summary: 141911466742


ob=(3) /usr/lib/libc-2.23.so
fl=(3) ???
fn=(446) sysconf
0 397
cfn=(448) getpagesize
calls=13 0 
0 65
0 26

fn=(1398) __GI_strchr
0 92

fn=(1410) _nl_normalize_codeset
0 142
cob=(2) ???
cfi=(2) ???
cfn=(1412) 0x0000000005d0f838
calls=2 0 
0 410
0 136

fn=(388) ptmalloc_init.part.5
0 411
cfn=(390) _dl_addr
calls=1 0 
0 56605
0 6

fn=(3206) realpath@@GLIBC_2.3
0 808
cfn=(1414) __GI_mempcpy
calls=9 0 
0 237
0 54
cfn=(3188) _lxstat
calls=9 0 
0 90
0 174
cfn=(3208) readlink
calls=1 0 
0 5
0 9
cfn=(342) strlen
calls=1 0 
0 16
0 8
cfn=(3210) __GI_memmove
calls=1 0 
0 33
0 5
cfn=(1416) __GI_memcpy
calls=1 0 
0 66
0 6
cfn=(446)
calls=1 0 
0 29
0 11
cob=(2)
cfi=(2)
cfn=(1412)
calls=1 0 
0 596
0 8

fn=(4682) __poll_nocancel
0 2690

fn=(5316) _IO_file_overflow@@GLIBC_2.2.5
0 13968
cfn=(5320) _IO_do_write@@GLIBC_2.2.5
calls=634 0 
0 2536
0 2
cfn=(5318) _IO_doallocbuf
calls=1 0 
0 24
0 6

fn=(5320)
0 2536

fn=(176) gettimeofday
0 110
cfn=(166) _dl_vdso_vsym
calls=2 0 
0 12
0 10

fn=(1120) _setjmp
0 2
cfn=(1122) __sigsetjmp
calls=1 0 
0 26

fn=(1124) __sigjmp_save
0 8

fn=(1396) __GI_strncmp
0 6098

fn=(1400) _nl_find_locale
0 228
cfn=(1394) __GI_strcmp
calls=12 0 
0 314
0 60
cfn=(1394)
calls=12 0 
0 314
0 156
cfn=(342)
calls=12 0 
0 192
0 48
cfn=(340) getenv
calls=12 0 
0 6564
0 120
cfn=(340)
calls=12 0 
0 5909
0 81
cfn=(340)
calls=9 0 
0 3906
0 162
cfn=(1402) memmem
calls=12 0 
0 641
0 168
cfn=(1404) memchr
calls=12 0 
0 245
0 108
cfn=(1406) _nl_load_locale_from_archive
calls=12 0 
0 23850
0 24

fn=(1428) strdup
0 70
cfn=(342)
calls=14 0 
0 224
0 42
cob=(2)
cfi=(2)
cfn=(1412)
calls=14 0 
0 2672
0 126
cfn=(1416)
calls=14 0 
0 308

fn=(1434) __GI_stpcpy
0 1226

fn=(1664) strcmp
0 10

fn=(278) _init
0 70
cfn=(166)
calls=1 0 
0 6
0 8
cfn=(166)
calls=1 0 
0 6
0 7
cfn=(280) __init_misc
calls=1 0 
0 78
0 1
cfn=(284) __ctype_init
calls=1 0 
0 16
0 14

fn=(288) handle_intel
0 42
cfn=(290) intel_check_word
calls=2 0 
0 666
0 14
cfn=(290)
calls=2 0 
0 236
0 42

fn=(386) malloc_hook_ini
0 8
cfn=(388)
calls=1 0 
0 57022
0 3
cfn=(385) malloc'2
calls=1 0 
0 1088

fn=(3208)
0 5

fn=(4420) __syscall_clock_gettime
0 3237

fn=(5136) __strncmp_sse42
0 29

fn=(174) strspn
0 6

fn=(1404)
0 490

fn=(1646) index
0 5

fn=(1692) __memcpy_chk_avx_unaligned
0 17

fn=(256) __libc_dl_error_tsd
0 3

fn=(3826) eventfd
0 7

fn=(5306) vfprintf
0 24091
cfn=(5308) buffered_vfprintf
calls=634 0 
0 435128
0 1268

fn=(5307) vfprintf'2
0 23458
cfn=(1408) strchrnul
calls=634 0 
0 12680
0 8242
cfn=(5310) _IO_default_xsputn
calls=634 0 
0 2536
0 53256
cfn=(1408)
calls=634 0 
0 12680
0 8242
cfn=(5310)
calls=634 0 
0 27896
0 17752
cfn=(5310)
calls=634 0 
0 51512
0 43740

fn=(5322) new_do_write
0 8242
cfn=(5324) _IO_file_write@@GLIBC_2.2.5
calls=634 0 
0 27896
0 17118

fn=(5338) _IO_file_sync@@GLIBC_2.2.5
0 8242

fn=(170) strncasecmp
0 5

fn=(172) strpbrk
0 6

fn=(402) _int_malloc
0 1320168662
cfn=(404) malloc_consolidate
calls=11 0 
0 2217
0 3360254222
cfn=(404)
calls=338 0 
0 51039
0 9584
cfn=(408) sysmalloc
calls=1733 0 
0 455263
0 450004464

fn=(472) __gettimeofday_syscall
0 5

fn=(708) __memmove_avx_unaligned
0 28

fn=(1172) getuid
0 3

fn=(1394)
0 1582

fn=(1402)
0 252
cfn=(1404)
calls=12 0 
0 245
0 144

fn=(1406)
0 156
cfn=(446)
calls=12 0 
0 396
0 94
cfn=(1394)
calls=19 0 
0 505
0 254
cfn=(1398)
calls=2 0 
0 46
0 19
cfn=(342)
calls=2 0 
0 32
0 212
cfn=(1394)
calls=2 0 
0 89
0 432
cob=(2)
cfi=(2)
cfn=(1412)
calls=2 0 
0 410
0 10
cfn=(1428)
calls=2 0 
0 322
0 290
cfn=(1430) _nl_intern_locale_data
calls=24 0 
0 19014
0 234
cfn=(1408)
calls=2 0 
0 40
0 12
cfn=(1410)
calls=2 0 
0 688
0 14
cfn=(1396)
calls=2 0 
0 62
0 8
cfn=(342)
calls=2 0 
0 32
0 6
cfn=(342)
calls=2 0 
0 32
0 28
cfn=(1414)
calls=2 0 
0 44
0 8
cfn=(1414)
calls=2 0 
0 36
0 10
cfn=(1416)
calls=2 0 
0 36
0 4
cob=(2)
cfi=(2)
cfn=(1418) 0x0000000005d0f860
calls=2 0 
0 178
0 18
cfn=(1424) _fxstat
calls=1 0 
0 10
0 10
cfn=(1426) mmap
calls=1 0 
0 33
0 26

fn=(1574) nl_langinfo
0 3
cfn=(1576) nl_langinfo_l
calls=1 0 
0 16

fn=(1614) strncpy
0 10

fn=(1666) __strcmp_sse2_unaligned
0 27325

fn=(1690) __memcpy_chk
0 14

fn=(286) init_cacheinfo
0 13
cfn=(288)
calls=1 0 
0 454
0 4
cfn=(288)
calls=1 0 
0 546
0 142

fn=(342)
0 5134

fn=(3156) realloc
0 41244
cfn=(3160) _int_realloc
calls=644 0 
0 79699
0 10313
cfn=(3158) realloc_hook_ini
calls=1 0 
0 141
0 9
cfn=(384) malloc
calls=1 0 
0 196

fn=(3157) realloc'2
0 64
cfn=(3160)
calls=1 0 
0 53
0 16

fn=(3160)
0 29307
cfn=(402)
calls=6 0 
0 849
0 192
cfn=(1422) _int_free
calls=6 0 
0 444
0 8614
cfn=(1422)
calls=538 0 
0 39808
0 538

fn=(3188)
0 100

fn=(5328) __write_nocancel
0 3170

fn=(5382) systrim.isra.0
0 68
cfn=(410) __default_morecore
calls=2 0 
0 50
0 10

fn=(168) strcspn
0 6

fn=(408)
0 156343
cfn=(410)
calls=1733 0 
0 88150
0 61748
cfn=(1426)
calls=1671 0 
0 55143
0 23421
cfn=(410)
calls=1 0 
0 25
0 31445
cfn=(1422)
calls=337 0 
0 24601
0 14387

fn=(410)
0 3472
cfn=(412) sbrk
calls=1736 0 
0 76073
0 8680

fn=(1104) (below main)
0 22
cfn=(602) __cxa_atexit
calls=1 0 
0 66
0 11
cob=(19) /home/tsenyk/projects/misc/build-LambdaDisconnect-Desktop-Release/LambdaDisconnect
cfi=(70) ???
cfn=(1106) __libc_csu_init
calls=1 0 
0 56
0 8
cfn=(1120)
calls=1 0 
0 28
0 14
cob=(19)
cfi=(70)
cfn=(1126) main
calls=1 0 
0 141907886425
0 2

fn=(1422)
0 1460387210
cfn=(404)
calls=2 0 
0 710013530
0 243
cfn=(5382)
calls=2 0 
0 128
0 2

fn=(1430)
0 782
cob=(2)
cfi=(2)
cfn=(1412)
calls=24 0 
0 4792
0 13440

fn=(1432) new_composite_name
0 38
cfn=(342)
calls=12 0 
0 192
0 112
cfn=(1394)
calls=2 0 
0 48
0 156
cob=(2)
cfi=(2)
cfn=(1412)
calls=1 0 
0 197
0 57
cfn=(1434)
calls=12 0 
0 746
0 48
cfn=(1434)
calls=12 0 
0 480
0 160

fn=(162) strcasecmp
0 5

fn=(164) time
0 55
cfn=(166)
calls=1 0 
0 6
0 5

fn=(264) __register_atfork
0 54

fn=(280)
0 12
cfn=(282) rindex
calls=1 0 
0 54
0 12

fn=(340)
0 585
cfn=(342)
calls=65 0 
0 1130
0 22375
cfn=(1396)
calls=154 0 
0 6036
0 424

fn=(3168) _xstat
0 52

fn=(4418) clock_gettime
0 11869
cfn=(4420)
calls=1079 0 
0 3237
0 6474

fn=(5308)
0 15216
cfn=(5307)
calls=634 0 
0 261994
0 17752
cfn=(5314) _IO_file_xsputn@@GLIBC_2.2.5
calls=634 0 
0 100858
0 19654
cob=(5) /usr/lib/libpthread-2.23.so
cfi=(5) ???
cfn=(5330) _pthread_cleanup_pop_restore
calls=634 0 
0 5072
0 5072
cob=(5)
cfi=(5)
cfn=(5312) _pthread_cleanup_push_defer
calls=634 0 
0 8876
0 634

fn=(5324)
0 17752
cfn=(5326) write
calls=634 0 
0 4438
0 5706

fn=(404)
0 710066138
cfn=(406) malloc_init_state
calls=1 0 
0 648

fn=(406)
0 648

fn=(1390) setlocale
0 49
cfn=(340)
calls=1 0 
0 465
0 98
cfn=(1398)
calls=1 0 
0 23
0 10
cob=(5)
cfi=(5)
cfn=(1392) pthread_rwlock_wrlock
calls=1 0 
0 24
0 7
cfn=(1394)
calls=1 0 
0 24
0 167
cfn=(1400)
calls=11 0 
0 29922
0 7
cfn=(1400)
calls=1 0 
0 13168
0 168
cfn=(1394)
calls=12 0 
0 288
0 48
cfn=(1428)
calls=12 0 
0 3120
0 41
cob=(2)
cfi=(2)
cfn=(1418)
calls=1 0 
0 8
0 2
cob=(2)
cfi=(2)
cfn=(1418)
calls=1 0 
0 8
0 7
cfn=(1432)
calls=1 0 
0 2234
0 145
cfn=(1436) _nl_postload_ctype
calls=1 0 
0 45
0 136
cob=(5)
cfi=(5)
cfn=(1438) pthread_rwlock_unlock
calls=1 0 
0 34
0 4

fn=(1414)
0 21677

fn=(166)
0 30

fn=(282)
0 108

fn=(384)
0 540074581
cfn=(402)
calls=30004143 0 
0 5130942296
0 840116009
cfn=(386)
calls=1 0 
0 58121

fn=(385)
0 18
cfn=(402)
calls=1 0 
0 1042
0 28

fn=(3210)
0 33

fn=(3890) __memset_avx2
0 172

fn=(4680) poll
0 1076
cfn=(4682)
calls=538 0 
0 2690

fn=(5310)
0 48104
cfn=(1414)
calls=534 0 
0 21360
0 12480

fn=(178) memcpy at GLIBC_2.2.5
0 33

fn=(184) strncmp
0 14

fn=(448)
0 65

fn=(488) calloc
0 736
cfn=(402)
calls=10 0 
0 1264
0 108
cfn=(490) __GI_memset
calls=6 0 
0 397
0 6

fn=(602)
0 208
cfn=(604) __new_exitfn
calls=26 0 
0 1138
0 364

fn=(604)
0 1138

fn=(1166) geteuid
0 3

fn=(1416)
0 410

fn=(1576)
0 16

fn=(1696) __memcpy_avx_unaligned
0 22180

fn=(252) getrlimit
0 5

fn=(284)
0 16

fn=(290)
0 902

fn=(5304) fprintf
0 9510
cfn=(5306)
calls=634 0 
0 460487
0 1268

fn=(5318)
0 24

fn=(5336) fflush
0 13948
cfn=(5338)
calls=634 0 
0 8242
0 10778

fn=(1122)
0 18
cfn=(1124)
calls=1 0 
0 8

fn=(1420) free
0 300060372
cfn=(1422)
calls=20004024 0 
0 2170336260
0 2

fn=(262) __libc_pthread_init
0 8
cfn=(264)
calls=1 0 
0 54
0 385

fn=(390)
0 14
cob=(5)
cfi=(5)
cfn=(392) pthread_mutex_lock
calls=1 0 
0 34
0 2
cob=(2)
cfi=(2)
cfn=(394) 0x0000000005d0f850
calls=1 0 
0 68
0 17

ob=(19)
fl=(70)
fn=(1106)
0 15
cob=(2)
cfi=(2)
cfn=(1108) 0x0000000000400f20
calls=1 0 
0 6
0 8
cfn=(1112) 0x0000000000401550
calls=1 0 
0 16
0 11

fn=(1126)
0 16
cob=(1) /usr/lib/ld-2.23.so
cfi=(1) ???
cfn=(243) _dl_runtime_resolve_avx'2
calls=1 0 
0 826373
0 5
0 2
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1279
0 5
0 4
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1593
0 5
0 3
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1014
0 5
0 70000006
cob=(13) /usr/lib/libstdc++.so.6.0.22
cfi=(59) /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/new_op.cc
cfn=(888) operator new(unsigned long)
calls=10000000 43 
0 2160257497
0 10000000
0 220000000
cob=(17) /opt/pelagicore/Qt5.6.2d/lib/libQt5Core.so.5.6.2
cfi=(53) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qobject.cpp
cfn=(4226) QObject::connectImpl(QObject const*, void**, QObject const*, void**, QtPrivate::QSlotObjectBase*, Qt::ConnectionType, int const*, QMetaObject const*)
calls=9999999 4637 
0 19850186860
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 5773
0 10000004
0 120000000
cob=(17)
cfi=(53)
cfn=(4322) QMetaObject::Connection::~Connection()
calls=9999999 4929 
0 109999989
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1067
0 10000004
0 150000000
cob=(13)
cfi=(59)
cfn=(888)
calls=10000000 43 
0 2160078761
0 10000000
0 90000000
cob=(17)
cfi=(53)
cfn=(4220) QMetaObject::Connection::Connection()
calls=9999999 4924 
0 79999992
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1064
0 10000004
0 90000002
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 20573
0 5
0 1
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 116756504514
0 5

fn=(1096) _start
0 11
cob=(1)
cfi=(1)
cfn=(242) _dl_runtime_resolve_avx
calls=1 0 
0 141907888271
0 5

fn=(1112)
0 16

fn=(4886) std::_Sp_counted_ptr_inplace<QMetaObject::Connection, std::allocator<QMetaObject::Connection>, (__gnu_cxx::_Lock_policy)2>::_M_destroy()
0 10000000
cob=(13)
cfi=(128) /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/del_op.cc
cfn=(2658) operator delete(void*)
calls=9999999 49 
0 899999910
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1154
0 10000004

fn=(4870) QtPrivate::QFunctorSlotObject<main::{lambda()#1}, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*)
0 330000000
cob=(13)
cfi=(128)
cfn=(2658)
calls=10000000 49 
0 900000000
0 10000000
0 80000000
cob=(17)
cfi=(53)
cfn=(4876) QObject::disconnect(QMetaObject::Connection const&)
calls=9999999 4735 
0 7069999293
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1964
0 10000004
0 330000007
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
0 117
0 1
0 14
cob=(17)
cfi=(53)
cfn=(4226)
calls=1 4637 
0 1886
0 1
0 3
cob=(17)
cfi=(53)
cfn=(4322)
calls=1 4929 
0 61
0 1
0 1001
cob=(17)
cfi=(39) /home/tsenyk/qt5/qt5/qtbase/src/corelib/global/qlogging.cpp
cfn=(4908) QMessageLogger::debug() const
calls=99 391 
0 194931
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 3233
0 104
0 300
cob=(17)
cfi=(193) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qtextstream.cpp
cfn=(4964) QTextStream::operator<<(int)
calls=99 2425 
0 410789
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 5200
0 104
0 800
cob=(17)
cfi=(193)
cfn=(5014) QTextStream::operator<<(char const*)
calls=99 2629 
0 68607
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1670
0 104
0 500
cob=(17)
cfi=(198) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qdebug.cpp
cfn=(5026) QDebug::~QDebug()
calls=99 142 
0 776436
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 77575
0 104
0 400
cob=(17)
cfi=(193)
cfn=(5000) QTextStream::operator<<(char)
calls=100 2383 
0 30200
0 100
0 300
cob=(17)
cfi=(193)
cfn=(5000)
calls=99 2383 
0 29898
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1245
0 104
0 30000200
cfn=(4884) std::_Sp_counted_ptr_inplace<QMetaObject::Connection, std::allocator<QMetaObject::Connection>, (__gnu_cxx::_Lock_policy)2>::_M_dispose()
calls=10000000 0 
0 140000000
0 70000000
cfn=(4886)
calls=10000000 0 
0 920001068
0 10000000

fn=(5362) QtPrivate::QFunctorSlotObject<main::{lambda()#1}::operator()()::{lambda()#1}, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*)
0 9078
cob=(17)
cfi=(39)
cfn=(4908)
calls=534 391 
0 132503164
0 534
0 2136
cob=(17)
cfi=(86) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qstring.cpp
cfn=(5368) QString::fromUtf8_helper(char const*, int)
calls=533 4757 
0 991931
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 3022
0 538
0 1602
cob=(17)
cfi=(193)
cfn=(5376) QTextStream::operator<<(QString const&)
calls=533 2565 
0 128347425
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 2601
0 538
0 5874

ob=(3)
fl=(3)
fn=(390)
0 56424
cob=(5)
cfi=(5)
cfn=(398) pthread_mutex_unlock
calls=1 0 
0 33
0 13

fn=(5314)
0 20288
cfn=(5316)
calls=634 0 
0 16536
0 8876
cfn=(5322)
calls=634 0 
0 53256
0 1902

fn=(412)
0 43006
cfn=(414) brk
calls=1 0 
0 12
0 3470
cfn=(414)
calls=1733 0 
0 25809
0 3776

fn=(414)
0 19137

ob=(19)
fl=(70)
fn=(5362)
0 1068
cob=(17)
cfi=(198)
cfn=(5026)
calls=534 142 
0 845510151
0 534

ob=(3)
fl=(3)
fn=(414)
0 6684

fn=(490)
0 397

fn=(1408)
0 25400

fn=(1424)
0 10

fn=(1426)
0 55176

fn=(1436)
0 45

fn=(1616) __strncpy_sse2_unaligned
0 87

fn=(1762) memcpy@@GLIBC_2.14
0 21

fn=(3052) getpid
0 5

fn=(3158)
0 8
cfn=(3157)
calls=1 0 
0 133

fn=(3808) syscall
0 11

fn=(3888) memset
0 8

fn=(5326)
0 1268
cfn=(5328)
calls=634 0 
0 3170

ob=(19)
fl=(70)
fn=(5362)
0 5340
cob=(17)
cfi=(96) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qarraydata.cpp
cfn=(2160) QArrayData::deallocate(QArrayData*, unsigned long, unsigned long)
calls=533 129 
0 93808
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1316
0 538
0 1602
cob=(17)
cfi=(193)
cfn=(5000)
calls=534 2383 
0 161268
0 534
0 534

fn=(4884)
0 20000000
cob=(17)
cfi=(53)
cfn=(4322)
calls=10000000 4929 
0 110000000
0 10000000

ob=(12) /usr/lib/libgcc_s.so.1
fl=(13) /build/gcc-multilib/src/gcc-build/gcc/include/cpuid.h
fn=(564) __get_cpuid_output
242 2
fi=(12) /build/gcc-multilib/src/gcc/libgcc/config/i386/cpuinfo.c
393 4
fe=(13)
242 2
fi=(12)
393 2
fe=(13)
224 8
+20 4
+3 8
+1 2
-1 4
fi=(12)
395 4
fe=(13)

fl=(14) ???
fn=(568) 0x0000000000003140
0 17

fl=(12)
fn=(566) get_available_features
306 1
-3 1
+3 2
+3 4
+2 4
+2 4
+2 4
+2 4
+2 4
+2 4
+2 4
+2 4
+2 4
+2 4
+2 4
+3 2
+3 3
+2 4
+2 4
+2 4
+2 4
+2 4
+2 4
+2 4
+2 4
+2 4
+2 4
+2 4
+2 4
+6 2
+2 2
+2 2
+3 4
+2 4
+2 4
+3 2
+1 2

fn=(562) __cpu_indicator_init at GCC_4.8.0
406 6
+10 1
-10 1
+9 4
+71 9
-67 11
cfi=(13)
cfn=(564)
calls=1 242 
* 20
* 3
+7 1
-1 1
+3 2
+6 6
cfi=(13)
cfn=(564)
calls=1 242 
* 20
* 2
+6 2
+1 1
+2 1
-3 1
+1 1
+2 1
+1 1
-4 1
+1 1
+2 1
+3 1
-2 1
+2 1
+3 1
-7 1
+7 1
+5 2
207 7
460 3
+25 1
-25 1
cfn=(566)
calls=1 306 
* 127

ob=(11) /usr/lib/libpcre16.so.0.2.7
fl=(11) ???
fn=(538) 0x00000000000017f0
0 17

ob=(12)
fl=(12)
fn=(562)
461 3
-6 1
199 2
+59 2
+1 2

ob=(1)
fl=(1)
fn=(92) open
0 252

fn=(156) _dl_lookup_symbol_x
0 1031710
cfn=(158) do_lookup_x
calls=2952 0 
0 1478251
0 101181

fn=(40) rtld_lock_default_unlock_recursive
0 284

fn=(48) _dl_init_paths
0 14
cfn=(50) _dl_important_hwcaps
calls=1 0 
0 377
0 3
cob=(2)
cfi=(2)
cfn=(26) 0x0000000004000b68
calls=1 0 
0 30
0 14
cob=(2)
cfi=(2)
cfn=(26)
calls=1 0 
0 30
0 67
cfn=(54) decompose_rpath
calls=1 0 
0 1286
0 2

fn=(226) _dl_init
0 247
cfn=(228) call_init.part.0
calls=18 0 
0 172950
0 31
cfn=(228)
calls=1 0 
0 8555
0 1

fn=(68) free
0 24

fn=(140) _dl_check_all_versions
0 145
cfn=(142) _dl_check_map_versions
calls=19 0 
0 66189
0 140

fn=(150) _dl_allocate_tls_storage
0 7
cob=(2)
cfi=(2)
cfn=(30) 0x0000000004000b60
calls=1 0 
0 77
0 303
cfn=(152) allocate_dtv
calls=1 0 
0 58
0 6

fn=(14) dl_main
0 38
cfn=(16) _dl_next_ld_env_entry
calls=1 0 
0 382
0 2
cfn=(16)
calls=1 0 
0 6
0 79
cfn=(20) _dl_new_object
calls=1 0 
0 252
0 11
cfn=(36) _dl_add_to_namespace_list
calls=1 0 
0 33
0 130
cfn=(42) strcmp
calls=1 0 
0 24
0 283
cfn=(4) _dl_setup_hash
calls=1 0 
0 23
0 5
cfn=(44) _dl_discover_osversion
calls=1 0 
0 86
0 64
cfn=(18) bcmp
calls=1 0 
0 18
0 18
cfn=(18)
calls=1 0 
0 36
0 7
cfn=(48)
calls=1 0 
0 1823
0 3
cfn=(70) _dl_debug_initialize
calls=1 0 
0 17
0 54
cfn=(72) _dl_count_modids
calls=1 0 
0 4
0 10
cfn=(74) _dl_debug_state
calls=1 0 
0 1
0 13
cfn=(108) access
calls=1 0 
0 9
0 20
cfn=(110) _dl_map_object_deps
calls=1 0 
0 154073
0 306
cfn=(136) _dl_receive_error
calls=1 0 
0 66514
0 5
cfn=(146) init_tls
calls=1 0 
0 839
0 25
cfn=(216) _dl_allocate_tls_init
calls=1 0 
0 289
0 348
cfn=(154) _dl_relocate_object
calls=18 0 
0 3159322
0 118
cfn=(182) _dl_add_to_slotinfo
calls=3 0 
0 60
0 23
cfn=(154)
calls=1 0 
0 6472
0 7
cfn=(218) _dl_sysdep_start_cleanup
calls=1 0 
0 1
0 6
cfn=(70)
calls=1 0 
0 8
0 2
cfn=(74)
calls=1 0 
0 1
0 1
cfn=(220) _dl_unload_cache
calls=1 0 
0 15
0 20
cfn=(10) strlen
calls=1 0 
0 34
0 8
cfn=(34) memcpy
calls=1 0 
0 76
0 10
cfn=(60) strsep
calls=1 0 
0 908
0 3
cfn=(60)
calls=1 0 
0 7
0 15
cfn=(76) do_preload
calls=1 0 
0 2384
0 16

fn=(102) mprotect
0 155

fn=(128) memmove
0 324
cfn=(134) _wordcopy_fwd_dest_aligned
calls=2 0 
0 88
0 546
cfn=(130) _wordcopy_bwd_aligned
calls=3 0 
0 69
0 9
cfn=(132) _wordcopy_fwd_aligned
calls=6 0 
0 196
0 12

fn=(144) match_symbol
0 10760
cfn=(42)
calls=112 0 
0 4646
0 1120

fn=(148) _dl_determine_tlsoffset
0 130

fn=(0) 0x0000000000000d90
0 2
cfn=(2) _dl_start
calls=1 0 
0 3396652
0 14
cfn=(226)
calls=1 0 
0 181784
0 3
cob=(19)
cfi=(70)
cfn=(1096)
calls=1 0 
0 141907888287

fn=(24) calloc
0 320
cob=(2)
cfi=(2)
cfn=(26)
calls=40 0 
0 1512

fn=(106) close
0 90

fn=(182)
0 60

fn=(218)
0 1

fn=(28) malloc
0 297
cob=(2)
cfi=(2)
cfn=(30)
calls=99 0 
0 2988

fn=(84) map_doit
0 11
cfn=(86) _dl_map_object
calls=1 0 
0 2281
0 3

fn=(98) _fxstat
0 180

fn=(108)
0 9

fn=(134)
0 88

fn=(10)
0 2252

fn=(42)
0 240255

fn=(116) _xstat
0 39

fn=(146)
0 10
cob=(2)
cfi=(2)
cfn=(22) 0x0000000004000b70
calls=1 0 
0 90
0 141
cfn=(148)
calls=1 0 
0 130
0 1
cfn=(150)
calls=1 0 
0 451
0 16

fn=(246) _dl_get_tls_static_info
0 5

fn=(56) strdup
0 90
cfn=(10)
calls=18 0 
0 522
0 54
cob=(2)
cfi=(2)
cfn=(26)
calls=18 0 
0 540
0 162
cfn=(34)
calls=18 0 
0 555

fn=(110)
0 3941
cfn=(64) index
calls=58 0 
0 1622
0 522
cfn=(78) _dl_catch_error
calls=58 0 
0 135714
0 1959
cob=(2)
cfi=(2)
cfn=(26)
calls=17 0 
0 510
0 153
cfn=(34)
calls=17 0 
0 520
0 102
cfn=(34)
calls=17 0 
0 520
0 273
cob=(2)
cfi=(2)
cfn=(26)
calls=1 0 
0 30
0 243
cfn=(104) memset
calls=1 0 
0 16
0 5177
cfn=(128)
calls=6 0 
0 478
0 219
cfn=(104)
calls=17 0 
0 257
0 762
cfn=(128)
calls=6 0 
0 562
0 401
cfn=(34)
calls=1 0 
0 89
0 3

fn=(118) _dl_next_tls_modid
0 18

fn=(2)
0 253
cfn=(4)
calls=1 0 
0 23
0 17
cfn=(6) _dl_sysdep_start
calls=1 0 
0 3396020
0 339

fn=(16)
0 388

fn=(34)
0 2754

fn=(44)
0 22
cfn=(46) uname
calls=1 0 
0 5
0 59

fn=(60)
0 1301

fn=(62) expand_dynamic_string_token
0 26
cfn=(64)
calls=2 0 
0 94
0 22
cfn=(56)
calls=2 0 
0 244

fn=(86)
0 7445
cfn=(88) _dl_name_match_p
calls=478 0 
0 44800
0 5086
cfn=(42)
calls=325 0 
0 10116
0 1402
cfn=(64)
calls=17 0 
0 487
0 40
cfn=(62)
calls=1 0 
0 199
0 13
cfn=(90) open_verify.constprop.7
calls=1 0 
0 282
0 24
cfn=(96) _dl_map_object_from_fd
calls=1 0 
0 1430
0 240
cfn=(96)
calls=16 0 
0 27522
0 83
cfn=(10)
calls=16 0 
0 328
0 766
cfn=(114) open_path
calls=16 0 
0 5155
0 327
cfn=(126) cache_rpath.part.6
calls=2 0 
0 16
0 156
cfn=(120) _dl_load_cache_lookup
calls=15 0 
0 22549
0 270
cfn=(90)
calls=15 0 
0 4579
0 194
cfn=(126)
calls=2 0 
0 16
0 4

fn=(100) mmap
0 1667

fn=(154)
0 36541
cob=(4) /usr/lib/libm-2.23.so
cfi=(4) ???
cfn=(212) sin
calls=1 0 
0 8
cob=(4)
cfi=(4)
cfn=(210) __atan2_finite
calls=1 0 
0 8
cob=(4)
cfi=(4)
cfn=(208) __asin_finite
calls=1 0 
0 5
cob=(4)
cfi=(4)
cfn=(206) floor
calls=1 0 
0 5
cob=(4)
cfi=(4)
cfn=(204) floorf
calls=1 0 
0 5
cob=(4)
cfi=(4)
cfn=(202) __acos_finite
calls=1 0 
0 5
cob=(4)
cfi=(4)
cfn=(200) rintf
calls=1 0 
0 5
cob=(4)
cfi=(4)
cfn=(198) __log_finite
calls=1 0 
0 8
cob=(4)
cfi=(4)
cfn=(196) __pow_finite
calls=1 0 
0 5
cob=(4)
cfi=(4)
cfn=(194) ceil
calls=1 0 
0 5
cob=(4)
cfi=(4)
cfn=(192) ceilf
calls=1 0 
0 5
cob=(4)
cfi=(4)
cfn=(190) rint
calls=1 0 
0 5
cob=(4)
cfi=(4)
cfn=(188) cos
calls=1 0 
0 8
cob=(4)
cfi=(4)
cfn=(186) __exp_finite
calls=1 0 
0 8
0 410
cfn=(180) _dl_protect_relro
calls=15 0 
0 375
0 446714
cfn=(156)
calls=2690 0 
0 2453585
0 137634
cob=(3)
cfi=(3)
cfn=(178)
calls=1 0 
0 11
cob=(3)
cfi=(3)
cfn=(176)
calls=1 0 
0 66
cob=(3)
cfi=(3)
cfn=(174)
calls=1 0 
0 6
cob=(3)
cfi=(3)
cfn=(172)
calls=1 0 
0 6
cob=(3)
cfi=(3)
cfn=(170)
calls=1 0 
0 5
cob=(3)
cfi=(3)
cfn=(168)
calls=1 0 
0 6
cob=(3)
cfi=(3)
cfn=(164)
calls=1 0 
0 66
cob=(3)
cfi=(3)
cfn=(162)
calls=1 0 
0 5
0 317
cob=(3)
cfi=(3)
cfn=(184)
calls=1 0 
0 7
0 47052
cfn=(156)
calls=5 0 
0 5437
0 37466

fn=(216)
0 147
cfn=(52) mempcpy
calls=3 0 
0 51
0 12
cfn=(104)
calls=3 0 
0 59
0 20

fn=(8) brk
0 11

fn=(88)
0 15064
cfn=(42)
calls=2152 0 
0 62950
0 25953
cfn=(42)
calls=2217 0 
0 71495
0 17346

fn=(138) version_check_doit
0 6
cfn=(140)
calls=1 0 
0 66474
0 4

fn=(220)
0 7
cfn=(222) munmap
calls=1 0 
0 5
0 3

fn=(20)
0 270
cfn=(10)
calls=18 0 
0 378
0 378
cob=(2)
cfi=(2)
cfn=(22)
calls=18 0 
0 912
0 252
cfn=(34)
calls=18 0 
0 488
0 985
cfn=(10)
calls=17 0 
0 488
0 470
cfn=(52)
calls=17 0 
0 528
0 1200
cob=(2)
cfi=(2)
cfn=(26)
calls=17 0 
0 561
0 87

fn=(38) rtld_lock_default_lock_recursive
0 284

fn=(74)
0 2

fn=(76)
0 17
cfn=(78)
calls=1 0 
0 2356
0 11

fn=(82) __sigsetjmp
0 1121

fn=(96)
0 306
cfn=(70)
calls=17 0 
0 136
0 85
cfn=(98)
calls=17 0 
0 170
0 2210
cfn=(20)
calls=17 0 
0 6745
0 4234
cfn=(118)
calls=3 0 
0 18
0 669
cfn=(100)
calls=17 0 
0 593
0 6569
cfn=(106)
calls=3 0 
0 15
0 28
cfn=(106)
calls=14 0 
0 70
0 204
cfn=(4)
calls=17 0 
0 391
0 101
cfn=(128)
calls=3 0 
0 204
0 213
cfn=(36)
calls=17 0 
0 1207
0 368
cfn=(104)
calls=16 0 
0 2646
0 229
cfn=(102)
calls=16 0 
0 80
0 270
cfn=(100)
calls=17 0 
0 527
0 397
cfn=(100)
calls=7 0 
0 217
0 50

fn=(126)
0 32

fn=(132)
0 196

fn=(180)
0 240
cfn=(102)
calls=15 0 
0 75
0 60

fn=(244) _dl_fixup
0 6273
cfn=(156)
calls=123 0 
0 152120
0 2967
cob=(3)
cfi=(3)
cfn=(184)
calls=1 0 
0 7
cob=(7) /usr/lib/librt-2.23.so
cfi=(7) ???
cfn=(4416) clock_gettime
calls=1 0 
0 2
cob=(3)
cfi=(3)
cfn=(3888)
calls=1 0 
0 8
cob=(3)
cfi=(3)
cfn=(1762)
calls=3 0 
0 21
cob=(3)
cfi=(3)
cfn=(1690)
calls=1 0 
0 14
cob=(3)
cfi=(3)
cfn=(1664)
calls=2 0 
0 10
cob=(3)
cfi=(3)
cfn=(1646)
calls=1 0 
0 5
cob=(3)
cfi=(3)
cfn=(1614)
calls=2 0 
0 10
cob=(3)
cfi=(3)
cfn=(178)
calls=2 0 
0 22
cob=(3)
cfi=(3)
cfn=(176)
calls=1 0 
0 66
0 15

fn=(52)
0 2059

fn=(64)
0 2203

fn=(78)
0 767
cfn=(80) _dl_initial_error_catch_tsd
calls=59 0 
0 118
0 472
cfn=(82)
calls=59 0 
0 1121
0 354
cfn=(112) openaux
calls=58 0 
0 132176
cfn=(84)
calls=1 0 
0 2295
0 767

fn=(114)
0 736
cfn=(52)
calls=16 0 
0 576
0 755
cfn=(52)
calls=19 0 
0 295
0 76
cfn=(52)
calls=19 0 
0 493
0 266
cfn=(90)
calls=19 0 
0 1083
0 208
cob=(2)
cfi=(2)
cfn=(26)
calls=1 0 
0 81
0 8
cfn=(34)
calls=1 0 
0 50
0 471
cfn=(116)
calls=3 0 
0 39
0 18

fn=(130)
0 69

fn=(214) _dl_higher_prime_number
0 152

fn=(6)
0 472
cfn=(8)
calls=1 0 
0 11
0 47
cfn=(10)
calls=1 0 
0 32
0 3
cfn=(12) sbrk
calls=1 0 
0 17
0 11
cfn=(14)
calls=1 0 
0 3395367
0 60

fn=(12)
0 17

fn=(80)
0 122

fn=(122) _dl_sysdep_read_whole_file
0 11
cfn=(92)
calls=1 0 
0 5
0 7
cfn=(98)
calls=1 0 
0 10
0 8
cfn=(106)
calls=1 0 
0 5
0 13
cfn=(100)
calls=1 0 
0 33
0 2

fn=(124) _dl_cache_libcmp
0 4075
cfn=(125) _dl_cache_libcmp'2
calls=26 0 
0 982
0 9998

fn=(125)
0 485
cfn=(125)
calls=10 0 
0 357
0 497

fn=(142)
0 3159
cfn=(88)
calls=383 0 
0 34755
0 2443
cfn=(144)
calls=7 0 
0 897
0 420
cfn=(144)
calls=105 0 
0 15629
0 2762
cob=(2)
cfi=(2)
cfn=(22)
calls=17 0 
0 714
0 5410

fn=(396) _dl_find_dso_for_object
0 67

fn=(18)
0 1878

fn=(36)
0 126
cfn=(38)
calls=18 0 
0 36
0 1028
cfn=(40)
calls=17 0 
0 34
0 12
cfn=(40)
calls=1 0 
0 2
0 2

fn=(54)
0 16
cfn=(56)
calls=1 0 
0 116
0 235
cob=(2)
cfi=(2)
cfn=(26)
calls=1 0 
0 30
0 12
cfn=(58) fillin_rpath
calls=1 0 
0 855
0 2
cob=(2)
cfi=(2)
cfn=(66) 0x0000000004000b80
calls=1 0 
0 7
0 13

fn=(90)
0 735
cfn=(92)
calls=35 0 
0 247
0 309
cfn=(94) read
calls=17 0 
0 85
0 221
cfn=(18)
calls=17 0 
0 435
0 153
cfn=(18)
calls=17 0 
0 612
0 1868
cfn=(18)
calls=5 0 
0 125
0 68
cfn=(18)
calls=17 0 
0 510
0 498
cfn=(18)
calls=3 0 
0 72
0 6

fn=(160) check_match
0 70300
cfn=(42)
calls=325 0 
0 21160
0 69235
cfn=(42)
calls=2620 0 
0 67204
0 7860

fn=(46)
0 5

fn=(50)
0 84
cob=(2)
cfi=(2)
cfn=(26)
calls=1 0 
0 30
0 161
cfn=(52)
calls=1 0 
0 22
0 4
cfn=(52)
calls=1 0 
0 18
0 4
cfn=(52)
calls=1 0 
0 22
0 4
cfn=(52)
calls=1 0 
0 18
0 10

fn=(104)
0 2978

fn=(112)
0 754
cfn=(86)
calls=58 0 
0 131248
0 174

fn=(152)
0 9
cob=(2)
cfi=(2)
cfn=(22)
calls=1 0 
0 39
0 10

fn=(32) __libc_memalign
0 1889
cfn=(100)
calls=9 0 
0 297
0 779

fn=(58)
0 20
cfn=(60)
calls=1 0 
0 379
0 3
cfn=(60)
calls=1 0 
0 7
0 8
cfn=(62)
calls=1 0 
0 187
0 3
cfn=(10)
calls=1 0 
0 34
0 15
cob=(2)
cfi=(2)
cfn=(66)
calls=1 0 
0 7
0 5
cfn=(10)
calls=1 0 
0 16
0 8
cob=(2)
cfi=(2)
cfn=(26)
calls=1 0 
0 30
0 9
cfn=(52)
calls=1 0 
0 36
0 40
cfn=(34)
calls=1 0 
0 18
0 30

fn=(72)
0 4

fn=(120)
0 2797
cfn=(124)
calls=138 0 
0 11912
0 983
cfn=(124)
calls=9 0 
0 779
0 75
cfn=(124)
calls=15 0 
0 2364
0 738
cfn=(10)
calls=15 0 
0 420
0 135
cfn=(34)
calls=15 0 
0 438
0 30
cfn=(56)
calls=15 0 
0 1563
0 124
cfn=(122)
calls=1 0 
0 94
0 10
cfn=(18)
calls=1 0 
0 38
0 15
cfn=(18)
calls=1 0 
0 32
0 2

fn=(222)
0 5

fn=(242)
0 624
cfn=(244)
calls=24 0 
0 34627
0 576
cob=(3)
cfi=(3)
cfn=(1104)
calls=1 0 
0 141907886632
cob=(5)
cfi=(5)
cfn=(952) pthread_self
calls=1 0 
0 2
cob=(13)
cfi=(19) /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/guard.cc
cfn=(624) __cxa_guard_release
calls=1 388 
0 15
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
0 216
cob=(13)
cfi=(19)
cfn=(618) __cxa_guard_acquire
calls=1 243 
0 36
cob=(14) /usr/lib/libicuuc.so.57.1
cfi=(28) ???
cfn=(696) icu_57::UnicodeString::UnicodeString(unsigned short const*)
calls=1 0 
0 1787
cob=(13)
cfi=(18) /build/gcc-multilib/src/gcc/libstdc++-v3/src/c++11/future.cc
cfn=(612) std::future_category()
calls=1 64 
0 1761
cob=(3)
cfi=(3)
cfn=(602)
calls=3 0 
0 192
cob=(13)
cfi=(16) /build/gcc-multilib/src/gcc/libstdc++-v3/src/c++11/compatibility-c++0x.cc
cfn=(596) std::error_category::error_category()
calls=1 135 
0 4
cob=(5)
cfi=(5)
cfn=(498) pthread_setspecific
calls=1 0 
0 34
cob=(3)
cfi=(3)
cfn=(488)
calls=1 0 
0 464
cob=(3)
cfi=(3)
cfn=(472)
calls=1 0 
0 5
cob=(3)
cfi=(3)
cfn=(446)
calls=1 0 
0 33
cob=(5)
cfi=(5)
cfn=(434) pthread_getspecific
calls=1 0 
0 11
cob=(5)
cfi=(5)
cfn=(424) pthread_key_create
calls=1 0 
0 19
cob=(3)
cfi=(3)
cfn=(384)
calls=3 0 
0 58528
cob=(3)
cfi=(3)
cfn=(340)
calls=1 0 
0 428
cob=(3)
cfi=(3)
cfn=(262)
calls=1 0 
0 447
cob=(3)
cfi=(3)
cfn=(252)
calls=1 0 
0 5
cfn=(246)
calls=1 0 
0 5

fn=(243)
0 2574
cfn=(244)
calls=99 0 
0 126913
0 2376
cob=(17)
cfi=(96)
cfn=(2160)
calls=1 129 
0 176
cob=(17)
cfi=(193)
cfn=(5376)
calls=1 2565 
0 1571
cob=(17)
cfi=(86)
cfn=(5368)
calls=1 4757 
0 1960
cob=(3)
cfi=(3)
cfn=(5336)
calls=1 0 
0 52
cob=(3)
cfi=(3)
cfn=(5304)
calls=1 0 
0 790
cob=(3)
cfi=(3)
cfn=(5136)
calls=1 0 
0 29
cob=(5)
cfi=(5)
cfn=(5094) close
calls=1 0 
0 7
cob=(5)
cfi=(5)
cfn=(5078) fcntl
calls=1 0 
0 22
cob=(17)
cfi=(198)
cfn=(5026)
calls=1 142 
0 76727
cob=(17)
cfi=(193)
cfn=(5014)
calls=1 2629 
0 693
cob=(17)
cfi=(193)
cfn=(5000)
calls=1 2383 
0 302
cob=(17)
cfi=(193)
cfn=(4964)
calls=1 2425 
0 4226
cob=(17)
cfi=(39)
cfn=(4908)
calls=1 391 
0 2211
cob=(17)
cfi=(53)
cfn=(4876)
calls=1 4735 
0 707
cob=(5)
cfi=(5)
cfn=(4798) read
calls=2 0 
0 14
cob=(3)
cfi=(3)
cfn=(4680)
calls=1 0 
0 7
cob=(8) /usr/lib/libglib-2.0.so.0.4800.1
cfi=(8) ???
cfn=(4560) g_main_context_iteration
calls=1 0 
0 8060
cob=(17)
cfi=(187) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qeventloop.cpp
cfn=(4508) QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)
calls=1 155 
0 116756501271
cob=(17)
cfi=(50) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp
cfn=(4492) QCoreApplication::exec()
calls=1 1267 
0 116756503515
cob=(3)
cfi=(3)
cfn=(4418)
calls=1 0 
0 20
cob=(13)
cfi=(184) /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/new_opv.cc
cfn=(4376) operator new[](unsigned long)
calls=1 32 
0 910
cob=(17)
cfi=(175) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qtimer.cpp
cfn=(4338) QTimer::start()
calls=1 199 
0 19654
cob=(17)
cfi=(53)
cfn=(4322)
calls=1 4929 
0 11
cob=(17)
cfi=(53)
cfn=(4226)
calls=1 4637 
0 4037
cob=(17)
cfi=(53)
cfn=(4220)
calls=1 4924 
0 8
cob=(17)
cfi=(175)
cfn=(4214) QTimer::setInterval(int)
calls=1 551 
0 15
cob=(17)
cfi=(175)
cfn=(4206) QTimer::QTimer(QObject*)
calls=1 141 
0 632
cob=(13)
cfi=(59)
cfn=(888)
calls=2 43 
0 400
cob=(17)
cfi=(50)
cfn=(4194) qt_startup_hook
calls=1 222 
0 5
cob=(8)
cfi=(8)
cfn=(4048) g_source_set_priority
calls=1 0 
0 42
cob=(8)
cfi=(8)
cfn=(3914) g_source_attach
calls=1 0 
0 2681
cob=(8)
cfi=(8)
cfn=(3908) g_source_set_can_recurse
calls=1 0 
0 19
cob=(8)
cfi=(8)
cfn=(3902) g_source_new
calls=1 0 
0 434
cob=(3)
cfi=(3)
cfn=(3890)
calls=1 0 
0 20
cob=(8)
cfi=(8)
cfn=(3876) g_main_context_push_thread_default
calls=1 0 
0 3009
cob=(8)
cfi=(8)
cfn=(3870) g_main_context_ref
calls=1 0 
0 11
cob=(5)
cfi=(5)
cfn=(3854) write
calls=1 0 
0 7
cob=(3)
cfi=(3)
cfn=(3826)
calls=1 0 
0 7
cob=(3)
cfi=(3)
cfn=(3808)
calls=1 0 
0 11
cob=(8)
cfi=(8)
cfn=(3778) g_main_context_default
calls=1 0 
0 8026
cob=(17)
cfi=(53)
cfn=(3586) qt_removeObject
calls=1 148 
0 6
cob=(5)
cfi=(5)
cfn=(3524) __errno_location
calls=1 0 
0 3
cob=(5)
cfi=(5)
cfn=(3514) open
calls=1 0 
0 11
cob=(3)
cfi=(3)
cfn=(3206)
calls=1 0 
0 2155
cob=(3)
cfi=(3)
cfn=(3188)
calls=1 0 
0 10
cob=(3)
cfi=(3)
cfn=(3168)
calls=1 0 
0 10
cob=(3)
cfi=(3)
cfn=(3156)
calls=2 0 
0 383
cob=(3)
cfi=(3)
cfn=(3052)
calls=1 0 
0 5
cob=(13)
cfi=(128)
cfn=(2658)
calls=2 49 
0 1762
cob=(13)
cfi=(127) /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/del_ops.cc
cfn=(2652) operator delete(void*, unsigned long)
calls=1 32 
0 2374
cob=(5)
cfi=(5)
cfn=(1822) pthread_cond_broadcast@@GLIBC_2.3.2
calls=1 0 
0 12
cob=(3)
cfi=(3)
cfn=(340)
calls=2 0 
0 820
cob=(3)
cfi=(3)
cfn=(1696)
calls=3 0 
0 54
cob=(14)
cfi=(28)
cfn=(1730) ucnv_getStandardName_57
calls=1 0 
0 10194
cob=(3)
cfi=(3)
cfn=(1420)
calls=4 0 
0 369
cob=(3)
cfi=(3)
cfn=(1692)
calls=1 0 
0 17
cob=(3)
cfi=(3)
cfn=(1666)
calls=2 0 
0 42
cob=(3)
cfi=(3)
cfn=(1398)
calls=1 0 
0 23
cob=(3)
cfi=(3)
cfn=(384)
calls=1 0 
0 196
cob=(3)
cfi=(3)
cfn=(1616)
calls=2 0 
0 87
cob=(3)
cfi=(3)
cfn=(1574)
calls=1 0 
0 19
cob=(5)
cfi=(5)
cfn=(398)
calls=1 0 
0 22
cob=(5)
cfi=(5)
cfn=(392)
calls=1 0 
0 28
cob=(14)
cfi=(28)
cfn=(1532) ucnv_getDefaultName_57
calls=1 0 
0 19743
cob=(3)
cfi=(3)
cfn=(342)
calls=2 0 
0 50
cob=(3)
cfi=(3)
cfn=(282)
calls=1 0 
0 54
cob=(3)
cfi=(3)
cfn=(1390)
calls=2 0 
0 50252
cob=(17)
cfi=(53)
cfn=(1334) qt_addObject
calls=1 145 
0 6
cob=(5)
cfi=(5)
cfn=(1312) pthread_condattr_destroy
calls=1 0 
0 2
cob=(5)
cfi=(5)
cfn=(1306) pthread_cond_init@@GLIBC_2.3.2
calls=1 0 
0 18
cob=(5)
cfi=(5)
cfn=(1300) pthread_condattr_setclock
calls=1 0 
0 10
cob=(3)
cfi=(3)
cfn=(446)
calls=1 0 
0 30
cob=(5)
cfi=(5)
cfn=(1274) pthread_condattr_init
calls=1 0 
0 3
cob=(5)
cfi=(5)
cfn=(1264) pthread_mutex_init
calls=1 0 
0 9
cob=(5)
cfi=(5)
cfn=(498)
calls=1 0 
0 34
cob=(5)
cfi=(5)
cfn=(424)
calls=1 0 
0 26
cob=(5)
cfi=(5)
cfn=(1236) pthread_once
calls=1 0 
0 1332
cfn=(1184) __tls_get_addr
calls=1 0 
0 129
cob=(3)
cfi=(3)
cfn=(1172)
calls=1 0 
0 3
cob=(3)
cfi=(3)
cfn=(1166)
calls=1 0 
0 3
cob=(17)
cfi=(50)
cfn=(1132) QCoreApplication::QCoreApplication(int&, char**, int)
calls=1 744 
0 825341
cob=(3)
cfi=(3)
cfn=(708)
calls=2 0 
0 28
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
0 15
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
0 36

fn=(1184)
0 51678
cfn=(1186) tls_get_addr_tail
calls=1 0 
0 118

fn=(1186)
0 33
cob=(5)
cfi=(5)
cfn=(392)
calls=1 0 
0 34
0 10
cob=(5)
cfi=(5)
cfn=(398)
calls=1 0 
0 33
0 8

fn=(4)
0 437

fn=(70)
0 161

fn=(94)
0 85

fn=(136)
0 11
cfn=(80)
calls=1 0 
0 2
0 7
cfn=(138)
calls=1 0 
0 66484
0 10

fn=(158)
0 798023
cfn=(88)
calls=1291 0 
0 113253
0 106964
cfn=(38)
calls=124 0 
0 248
0 6453
cfn=(42)
calls=40 0 
0 2660
0 520
cfn=(40)
calls=40 0 
0 80
0 3175
cfn=(40)
calls=84 0 
0 168
0 171033
cfn=(160)
calls=2760 0 
0 235759
0 9202
cfn=(214)
calls=2 0 
0 152
0 8
cob=(2)
cfi=(2)
cfn=(22)
calls=2 0 
0 78
0 2380
cfn=(68)
calls=2 0 
0 12
0 3221
cob=(2)
cfi=(2)
cfn=(22)
calls=1 0 
0 39
0 24823

fn=(228)
0 477
cob=(2)
cfi=(2)
cfn=(1082) 0x0000000004a264f8
calls=1 0 
0 6
cob=(2)
cfi=(2)
cfn=(728) 0x0000000004caa1f8
calls=1 0 
0 6
cob=(2)
cfi=(2)
cfn=(716) 0x0000000006093010
calls=1 0 
0 6
cob=(2)
cfi=(2)
cfn=(676) 0x0000000006363d90
calls=1 0 
0 6
cob=(2)
cfi=(2)
cfn=(664) 0x000000000677c498
calls=1 0 
0 6
cob=(2)
cfi=(2)
cfn=(576) 0x00000000054d7338
calls=1 0 
0 6
cob=(2)
cfi=(2)
cfn=(558) 0x0000000005adc790
calls=1 0 
0 6
cob=(2)
cfi=(2)
cfn=(546) 0x00000000057db3b8
calls=1 0 
0 6
cob=(2)
cfi=(2)
cfn=(534) 0x00000000085464c8
calls=1 0 
0 6
cob=(2)
cfi=(2)
cfn=(520) 0x00000000087aeca0
calls=1 0 
0 6
cob=(2)
cfi=(2)
cfn=(508) 0x00000000089b2630
calls=1 0 
0 6
cob=(2)
cfi=(2)
cfn=(316) 0x0000000008bcdba0
calls=1 0 
0 6
cob=(2)
cfi=(2)
cfn=(304) 0x0000000008ec4d88
calls=1 0 
0 6
cob=(2)
cfi=(2)
cfn=(292) 0x00000000090cc538
calls=1 0 
0 6
cob=(3)
cfi=(3)
cfn=(278)
calls=1 0 
0 206
cob=(2)
cfi=(2)
cfn=(230) 0x00000000052375c8
calls=1 0 
0 8462
0 272
cob=(18) /usr/lib/valgrind/vgpreload_core-amd64-linux.so
cfi=(69) ???
cfn=(1086) 0x0000000000000620
calls=1 0 
0 17
cob=(17)
cfi=(31) ???
cfn=(732) 0x0000000000084530
calls=1 0 
0 17
cob=(16) /usr/lib/libz.so.1.2.8
cfi=(30) ???
cfn=(720) 0x00000000000023e0
calls=1 0 
0 17
cob=(15) /usr/lib/libicui18n.so.57.1
cfi=(29) ???
cfn=(680) 0x00000000000c0800
calls=1 0 
0 17
cob=(14)
cfi=(28)
cfn=(668) 0x000000000005c710
calls=1 0 
0 17
cob=(13)
cfi=(15) ???
cfn=(580) 0x000000000008c050
calls=1 0 
0 17
cob=(12)
cfi=(12)
cfn=(562)
calls=1 406 
0 255
cob=(4)
cfi=(4)
cfn=(550) 0x0000000000005640
calls=1 0 
0 17
cob=(11)
cfi=(11)
cfn=(538)
calls=1 0 
0 17
cob=(10) /usr/lib/libdl-2.23.so
cfi=(10) ???
cfn=(524) 0x0000000000000e80
calls=1 0 
0 17
cob=(9) /usr/lib/libgthread-2.0.so.0.4800.1
cfi=(9) ???
cfn=(512) 0x0000000000000760
calls=1 0 
0 17
cob=(8)
cfi=(8)
cfn=(320) 0x000000000001ae80
calls=1 0 
0 17
cob=(7)
cfi=(7)
cfn=(308) 0x0000000000002260
calls=1 0 
0 17
cob=(6) /usr/lib/libpcre.so.1.2.7
cfi=(6) ???
cfn=(296) 0x00000000000019f0
calls=1 0 
0 17
cob=(3)
cfi=(3)
cfn=(286)
calls=1 0 
0 1159
cob=(5)
cfi=(5)
cfn=(268) 0x0000000000005b50
calls=1 0 
0 17
0 120
cob=(17)
cfi=(54) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/.rcc/qrc_mimetypes.cpp
cfn=(850) _GLOBAL__sub_I_qrc_mimetypes.cpp
calls=1 15813 
0 9994
cob=(17)
cfi=(52) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/.moc/moc_qobject.cpp
cfn=(844) _GLOBAL__sub_I_qobject.cpp
calls=1 224 
0 5662
cob=(17)
cfi=(51) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qcoreevent.cpp
cfn=(832) _GLOBAL__sub_I_qcoreevent.cpp
calls=1 635 
0 66629
cob=(17)
cfi=(50)
cfn=(828) _GLOBAL__sub_I_qcoreapplication.cpp
calls=1 2792 
0 57
cob=(17)
cfi=(49) /home/tsenyk/qt5/qt5/qtbase/src/corelib/plugin/qlibrary.cpp
cfn=(822) _GLOBAL__sub_I_qlibrary.cpp
calls=1 1129 
0 136
cob=(17)
cfi=(47) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/forkfd_qt.cpp
cfn=(796) _GLOBAL__sub_I_forkfd_qt.cpp
calls=1 70 
0 796
cob=(17)
cfi=(46) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qlockfile_unix.cpp
cfn=(792) _GLOBAL__sub_I_qlockfile_unix.cpp
calls=1 316 
0 57
cob=(17)
cfi=(44) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/.moc/moc_qfileselector.cpp
cfn=(786) _GLOBAL__sub_I_qfileselector.cpp
calls=1 88 
0 57
cob=(17)
cfi=(43) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qsettings.cpp
cfn=(782) _GLOBAL__sub_I_qsettings.cpp
calls=1 3512 
0 57
cob=(17)
cfi=(42) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qregexp.cpp
cfn=(778) _GLOBAL__sub_I_qregexp.cpp
calls=1 4594 
0 57
cob=(17)
cfi=(41) /home/tsenyk/qt5/qt5/qtbase/src/corelib/thread/qthread_unix.cpp
cfn=(766) _GLOBAL__sub_I_qthread_unix.cpp
calls=1 758 
0 1713
cob=(17)
cfi=(40) /home/tsenyk/qt5/qt5/qtbase/src/corelib/thread/qthreadstorage.cpp
cfn=(762) _GLOBAL__sub_I_qthreadstorage.cpp
calls=1 203 
0 57
cob=(17)
cfi=(39)
cfn=(758) _GLOBAL__sub_I_qlogging.cpp
calls=1 1864 
0 57
cob=(17)
cfi=(38) /home/tsenyk/qt5/qt5/qtbase/src/corelib/global/qglobal.cpp
cfn=(754) _GLOBAL__sub_I_qglobal.cpp
calls=1 3884 
0 57
cob=(17)
cfi=(32) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/.moc/moc_qvariantanimation.cpp
cfn=(740) _GLOBAL__sub_I_qvariantanimation.cpp
calls=1 195 
0 57
cob=(15)
cfi=(29)
cfn=(688) 0x00000000000c06f0
calls=1 0 
0 4977
cob=(13)
cfi=(25) /build/gcc-multilib/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets_nonio.h
cfn=(658) _GLOBAL__sub_I_wlocale_inst.cc
calls=1 1373 
0 49
cob=(13)
cfi=(25)
cfn=(652) _GLOBAL__sub_I_locale_inst.cc
calls=1 1373 
0 49
cob=(13)
cfi=(25)
cfn=(646) _GLOBAL__sub_I_cxx11_wlocale_inst.cc
calls=1 1373 
0 33
cob=(13)
cfi=(25)
cfn=(640) _GLOBAL__sub_I_cxx11_locale_inst.cc
calls=1 1373 
0 33
cob=(13)
cfi=(24) /build/gcc-multilib/src/gcc/libstdc++-v3/src/c++11/system_error.cc
cfn=(638) _GLOBAL__sub_I_system_error.cc
calls=1 70 
0 144
cob=(13)
cfi=(23) /build/gcc-multilib/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/parallel/settings.h
cfn=(636) _GLOBAL__sub_I_parallel_settings.cc
calls=1 338 
0 54
cob=(13)
cfi=(21) /build/gcc-multilib/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/bitmap_allocator.h
cfn=(632) _GLOBAL__sub_I_bitmap_allocator.cc
calls=1 1094 
0 73
cob=(13)
cfi=(20) /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/eh_alloc.cc
cfn=(626) _GLOBAL__sub_I_eh_alloc.cc
calls=1 326 
0 1732
cob=(13)
cfi=(17) /build/gcc-multilib/src/gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc
cfn=(606) _GLOBAL__sub_I_compatibility_thread_c__0x.cc
calls=1 124 
0 2604
cob=(13)
cfi=(16)
cfn=(588) _GLOBAL__sub_I_compatibility_c__0x.cc
calls=1 257 
0 2637
cob=(12)
cfi=(14)
cfn=(568)
calls=1 0 
0 17
cob=(10)
cfi=(10)
cfn=(532) 0x0000000000001950
calls=1 0 
0 3
cob=(8)
cfi=(8)
cfn=(328) 0x000000000001ad80
calls=1 0 
0 72113
cob=(5)
cfi=(5)
cfn=(276) elision_init
calls=1 0 
0 16
0 255

ob=(18)
fl=(69)
fn=(1086)
0 17

ob=(14)
fl=(28)
fn=(1632) ucnv_getName_57
0 12

fn=(1710) ucnv_close_57
0 31
cfn=(1712) uprv_free_57
calls=1 0 
0 1860
0 6

fn=(1748) icu_57::StringPiece::StringPiece(char const*)
0 49
cob=(3)
cfi=(3)
cfn=(342)
calls=7 0 
0 112
0 7
0 21

fn=(1876) udata_getHeaderSize_57
0 12

fn=(1982) 0x000000000005fed0
0 21
cfn=(1990) 0x000000000006e170
calls=1 0 
0 12
0 4
cfn=(1882) UDataMemory_createNewInstance_57
calls=1 0 
0 252
0 8

fn=(2064) uprv_asciitolower_57
0 90

fn=(668)
0 17

fn=(1532)
0 9
cfn=(1534) umtx_lock_57
calls=1 0 
0 1269
0 3
cfn=(1540) umtx_unlock_57
calls=1 0 
0 1475
0 13
cfn=(1546) uprv_getDefaultCodepage_57
calls=1 0 
0 5448
0 7
cfn=(1618) ucnv_open_57
calls=1 0 
0 2137
0 9
cfn=(1632)
calls=1 0 
0 12
0 12
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1704
0 5
0 5
cfn=(1638) 0x000000000006c1b0
calls=1 0 
0 5735
0 2
cfn=(1710)
calls=1 0 
0 1897
0 1

fn=(1620) ucnv_createConverter_57
0 23
cfn=(1622) ucnv_loadSharedData_57
calls=1 0 
0 56
0 5
cfn=(1624) ucnv_createConverterFromSharedData_57
calls=1 0 
0 2033
0 11

fn=(1624)
0 114
cfn=(1626) uprv_malloc_57
calls=1 0 
0 1914
0 5

fn=(1814) u_setDataDirectory_57
0 19
cfn=(1700) ucln_common_registerCleanup_57
calls=1 0 
0 77

fn=(1842) 0x0000000000060ab0
0 35
cfn=(1846) 0x00000000000607e0
calls=1 0 
0 728
0 12
cfn=(1918) 0x0000000000061930
calls=1 0 
0 808
0 11
cfn=(1982)
calls=1 0 
0 297
0 21

fn=(696)
0 12
cfn=(698) icu_57::UnicodeString::doAppend(unsigned short const*, int, int)
calls=1 0 
0 1771
0 4

fn=(1548) 0x000000000005caa0
0 10
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1709
0 5
0 12

fn=(1734) 0x000000000006e310
0 7
cfn=(1700)
calls=1 0 
0 77
0 7
cfn=(1738) udata_openChoice_57
calls=1 0 
0 8809
0 6
cfn=(2036) udata_getMemory_57
calls=1 0 
0 18
0 71

fn=(1738)
0 57
cfn=(1754) icu_57::CharString::append(char const*, int, UErrorCode&)
calls=1 0 
0 1892
0 5
cfn=(1754)
calls=1 0 
0 94
0 5
cfn=(1754)
calls=1 0 
0 94
0 8
cfn=(1748)
calls=1 0 
0 27
0 4
cfn=(1774) icu_57::CharString::append(char, UErrorCode&)
calls=1 0 
0 48
0 5
cfn=(1754)
calls=1 0 
0 96
0 3
cfn=(1748)
calls=1 0 
0 27
0 4
cfn=(1774)
calls=1 0 
0 48
0 5
cfn=(1754)
calls=1 0 
0 96
0 12
cfn=(1808) u_getDataDirectory_57
calls=1 0 
0 3722
0 55
cfn=(1842)
calls=1 0 
0 1912
0 6
cfn=(1748)
calls=1 0 
0 27
0 5
cfn=(1748)
calls=1 0 
0 27
0 5
cfn=(1754)
calls=1 0 
0 99
0 5
cfn=(1754)
calls=1 0 
0 100
0 3
cfn=(1748)
calls=1 0 
0 27
0 3
cfn=(1748)
calls=1 0 
0 27
0 5
cfn=(1754)
calls=1 0 
0 99
0 5
cfn=(1754)
calls=1 0 
0 100
0 5
cfn=(1748)
calls=1 0 
0 27
0 15

fn=(1874) udata_checkCommonData_57
0 23
cfn=(1876)
calls=1 0 
0 6
0 15

fn=(1880) 0x000000000005fcb0
0 10
cfn=(1882)
calls=1 0 
0 252
0 14
cfn=(1888) UDatamemory_assign_57
calls=1 0 
0 17
0 2
cfn=(1534)
calls=1 0 
0 33
0 11
cfn=(1540)
calls=1 0 
0 27
0 3
cfn=(1700)
calls=1 0 
0 77
0 2

fn=(1882)
0 20
cfn=(1626)
calls=2 0 
0 422
0 12
cfn=(1850) UDataMemory_init_57
calls=2 0 
0 38
0 12

fn=(1578) 0x000000000005c8c0
0 45

fn=(1626)
0 18
cob=(3)
cfi=(3)
cfn=(384)
calls=2 0 
0 408
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1903
0 7

fn=(1774)
0 20
cfn=(1756) icu_57::CharString::ensureCapacity(int, int, UErrorCode&)
calls=2 0 
0 46
0 30

fn=(1846)
0 18
cfn=(1850)
calls=1 0 
0 19
0 8
cfn=(1534)
calls=1 0 
0 33
0 19
cfn=(1540)
calls=1 0 
0 27
0 2
cfn=(1850)
calls=1 0 
0 19
0 3
cfn=(1868) UDataMemory_setData_57
calls=1 0 
0 13
0 3
cfn=(1874)
calls=1 0 
0 44
0 4
cfn=(1880)
calls=1 0 
0 448
0 2
cfn=(1534)
calls=1 0 
0 33
0 4
cfn=(1540)
calls=1 0 
0 27
0 2

fn=(1868)
0 4
cfn=(1870) UDataMemory_normalizeDataPointer_57
calls=1 0 
0 6
0 3

fn=(1888)
0 17

fn=(1990)
0 12

fn=(1546)
0 10
cfn=(1534)
calls=1 0 
0 33
0 4
cfn=(1540)
calls=1 0 
0 27
0 33
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1704
0 5
0 16
cfn=(1578)
calls=1 0 
0 45
0 6
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1815
0 5
0 6
cfn=(1548)
calls=1 0 
0 1736
0 3

fn=(1618)
0 9
cfn=(1620)
calls=1 0 
0 2128

fn=(1700)
0 36
cfn=(1534)
calls=4 0 
0 132
0 32
cfn=(1540)
calls=4 0 
0 108

fn=(1712)
0 7
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1848
0 5

fn=(1918)
0 808

fn=(2036)
0 8
cfn=(1876)
calls=1 0 
0 6
0 4

fn=(2052) 0x000000000006e850
0 15
cfn=(2054) 0x000000000006e670
calls=1 0 
0 425
0 7
cob=(3)
cfi=(3)
cfn=(342)
calls=1 0 
0 16
0 1
0 64
cob=(3)
cfi=(3)
cfn=(1666)
calls=10 0 
0 210
0 10
0 172
cfn=(1654) ucnv_io_stripASCIIForCompare_57
calls=1 0 
0 86
0 1

fn=(1754)
0 419
cfn=(1756)
calls=9 0 
0 207
0 63
cob=(3)
cfi=(3)
cfn=(1696)
calls=8 0 
0 110
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1804
0 13
0 54

fn=(1540)
0 40
cob=(5)
cfi=(5)
cfn=(398)
calls=9 0 
0 198
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1466
0 14

fn=(2062) uprv_stricmp_57
0 99
cfn=(2064)
calls=9 0 
0 45
0 27
cfn=(2064)
calls=9 0 
0 45
0 124

fn=(698)
0 49
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1682
0 5
0 20
cfn=(700) u_strlen_57
calls=1 0 
0 10
0 5

fn=(1652) 0x000000000006c0d0
0 17
cfn=(1654)
calls=1 0 
0 86
0 51
cob=(3)
cfi=(3)
cfn=(1666)
calls=4 0 
0 126
0 4
0 2
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1681
0 5
0 10

ob=(4)
fl=(4)
fn=(550)
0 17

fn=(210)
0 8

fn=(204)
0 5

fn=(206)
0 5

fn=(208)
0 5

fn=(212)
0 8

fn=(188)
0 8

fn=(200)
0 5

fn=(202)
0 3

ob=(14)
fl=(28)
fn=(1652)
0 16

fn=(1654)
0 172

fn=(1732) icu_57::umtx_initImplPreInit(icu_57::UInitOnce&)
0 8
cob=(5)
cfi=(5)
cfn=(392)
calls=2 0 
0 56
0 2
0 14
cob=(5)
cfi=(5)
cfn=(398)
calls=2 0 
0 44
0 2
0 6

fn=(1870)
0 6

fn=(2054)
0 62
cfn=(2062)
calls=5 0 
0 298
0 6
cfn=(2062)
calls=1 0 
0 42
0 17

fn=(700)
0 10

fn=(1534)
0 40
cob=(5)
cfi=(5)
cfn=(392)
calls=9 0 
0 252
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1260
0 14

fn=(1622)
0 56

fn=(1638)
0 17
cob=(3)
cfi=(3)
cfn=(342)
calls=1 0 
0 16
0 1
0 4
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1709
0 5
0 15
cfn=(1652)
calls=1 0 
0 1998
0 4
cfn=(1534)
calls=1 0 
0 33
0 8
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1807
0 5
0 6
cfn=(1700)
calls=1 0 
0 77
0 2
cfn=(1540)
calls=1 0 
0 27
0 1

fn=(1730)
0 13
cfn=(1732)
calls=1 0 
0 66
0 8
cfn=(1734)
calls=1 0 
0 8995
0 5
cfn=(1816) icu_57::umtx_initImplPostInit(icu_57::UInitOnce&)
calls=1 0 
0 75
0 11
cfn=(2052)
calls=1 0 
0 1007
0 14

fn=(1756)
0 253

fn=(1808)
0 6
cfn=(1732)
calls=1 0 
0 66
0 6
cfn=(1816)
calls=1 0 
0 1390
0 5
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 2142
0 5
0 5
cfn=(1814)
calls=1 0 
0 96
0 1

fn=(1816)
0 8
cob=(5)
cfi=(5)
cfn=(392)
calls=2 0 
0 56
0 2
0 6
cob=(5)
cfi=(5)
cfn=(1822)
calls=1 0 
0 12
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1323
0 6
0 6
cob=(5)
cfi=(5)
cfn=(398)
calls=2 0 
0 44
0 2

fn=(1850)
0 76

ob=(2)
fl=(2)
fn=(22)
0 40
cob=(1)
cfi=(1)
cfn=(24)
calls=40 0 
0 1832

fn=(508)
0 6

fn=(520)
0 6

fn=(546)
0 6

fn=(664)
0 6

fn=(1082)
0 6

fn=(316)
0 6

fn=(716)
0 6

fn=(1412)
0 44
cob=(3)
cfi=(3)
cfn=(384)
calls=44 0 
0 9033

fn=(30)
0 100
cob=(1)
cfi=(1)
cfn=(32)
calls=100 0 
0 2965

fn=(230)
0 2
cob=(5)
cfi=(5)
cfn=(232) __pthread_initialize_minimal
calls=1 0 
0 8458
0 2

fn=(1108)
0 6

fn=(1418)
0 4
cob=(3)
cfi=(3)
cfn=(1420)
calls=4 0 
0 190

fn=(534)
0 6

ob=(4)
fl=(4)
fn=(202)
0 2

fn=(186)
0 8

fn=(198)
0 8

fn=(190)
0 5

fn=(192)
0 5

fn=(194)
0 5

fn=(196)
0 5

ob=(2)
fl=(2)
fn=(304)
0 6

fn=(676)
0 6

fn=(254) 0x0000000005237a60
0 1
cob=(3)
cfi=(3)
cfn=(256)
calls=1 0 
0 3

ob=(15)
fl=(29)
fn=(680)
0 17

fn=(688)
0 4
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
0 3099
0 5
0 5
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
0 1859
0 5

ob=(2)
fl=(2)
fn=(576)
0 6

fn=(728)
0 6

fn=(26)
0 99
cob=(1)
cfi=(1)
cfn=(28)
calls=99 0 
0 3285

fn=(66)
0 2
cob=(1)
cfi=(1)
cfn=(68)
calls=2 0 
0 12

fn=(394)
0 1
cob=(1)
cfi=(1)
cfn=(396)
calls=1 0 
0 67

fn=(558)
0 6

fn=(292)
0 6

ob=(16)
fl=(30)
fn=(720)
0 17

ob=(17)
fl=(87) /home/tsenyk/qt5/qt5/qtbase/src/corelib/codecs/qtextcodec.cpp
fn=(2180) QTextCodec::QTextCodec()
468 9
+2 2
cfi=(56) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/global/qglobalstatic.h
cfn=(1516) QGlobalStatic<QMutex, (anonymous namespace)::Q_QGS_textCodecsMutex::innerFunction(), (anonymous namespace)::Q_QGS_textCodecsMutex::guard>::operator()()
calls=1 129 
* 72
* 5
cfi=(34) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/thread/qmutex.h
cfn=(920) QMutexLocker::QMutexLocker(QBasicMutex*)
calls=1 121 
* 350
+2 1
cfi=(88) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qcoreglobaldata.cpp
cfn=(1472) QCoreGlobalData::instance()
calls=1 54 
* 78
* 1
+1 4
cfi=(64) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qlist.h
cfn=(2182) QList<QTextCodec*>::isEmpty() const
calls=1 185 
* 22
* 2
+1 1
cfn=(2186) setup()
calls=1 302 
* 5
+2 8
cfi=(64)
cfn=(2188) QList<QTextCodec*>::prepend(QTextCodec* const&)
calls=1 603 
* 673
-6 3
cfi=(34)
cfn=(1050) QMutexLocker::~QMutexLocker()
calls=1 132 
* 272
+7 5

fn=(4938) QTextCodec::ConverterState::~ConverterState()
325 10144
+2 10144
cfi=(95) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/global/qflags.h
cfn=(4940) QFlags<QTextCodec::ConversionFlag>::operator&(QTextCodec::ConversionFlag) const
calls=2536 136 
* 131872
* 10144
cfi=(95)
cfn=(4944) QFlags<QTextCodec::ConversionFlag>::operator unsigned int() const
calls=2536 128 
* 17752
* 10144
+2 10144
+2 7608

fn=(1470) QTextCodec::codecForLocale()
678 3834
+1 1278
cfi=(88)
cfn=(1472)
calls=1278 54 
* 101249
* 1278
+1 2556
+3 5112
cfi=(35) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/thread/qbasicatomic.h
cfn=(1508) QBasicAtomicPointer<QTextCodec>::loadAcquire() const
calls=1278 258 
* 60066
* 1278
+1 2556
+2 2
cfi=(56)
cfn=(1516)
calls=1 129 
* 821
* 2
cfi=(58) /home/tsenyk/qt5/qt5/qtbase/src/corelib/thread/qmutex.cpp
cfn=(924) QMutex::lock()
calls=1 217 
* 545
+1 1
cfi=(93) /home/tsenyk/qt5/qt5/qtbase/src/corelib/codecs/qicucodec.cpp
cfn=(1526) QIcuCodec::defaultCodecUnlocked()
calls=1 431 
* 41051
* 1
+1 2
cfi=(56)
cfn=(1516)
calls=1 129 
* 72
* 2
cfi=(58)
cfn=(1058) QMutex::unlock()
calls=1 269 
* 525
+7 1278
+1 2556

fn=(1522) (anonymous namespace)::Q_QGS_textCodecsMutex::innerFunction()::Holder::Holder()
93 8
cfn=(1524) (anonymous namespace)::Q_QGS_textCodecsMutex::innerFunction()::HolderBase::HolderBase()
calls=1 * 
* 6
* 4
cfi=(58)
cfn=(882) QMutex::QMutex(QMutex::RecursionMode)
calls=1 +84 
* 544
* 3
cfi=(35)
cfn=(910) QBasicAtomicInteger<int>::store(int)
calls=1 +24 
* 44
* 5

fn=(2186)
302 5

fn=(1520) (anonymous namespace)::Q_QGS_textCodecsMutex::innerFunction()
93 29
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 7
cfn=(1522)
calls=1 * 
* 614
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 -93 
* 66
* 1
* 18

fn=(1524)
93 6

fl=(189) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/kernel/qeventloop.h
fn=(4502) QEventLoop::d_func()
47 4312
cfi=(62) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/global/qglobal.h
cfn=(1322) QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::pointer qGetPtrHelper<QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> > >(QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> > const&)
calls=539 1014 
* 8624
* 1078

fl=(201) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/io/qloggingcategory.h
fn=(5130) QLoggingCategory::categoryName() const
65 14

fl=(100) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/codecs/qtextcodec.h
fn=(2204) QTextCodec::toUnicode(char const*, int, QTextCodec::ConverterState*) const
102 40
+1 50
cfi=(101) /home/tsenyk/qt5/qt5/qtbase/src/corelib/codecs/qutfcodec.cpp
cfn=(2206) QUtf8Codec::convertToUnicode(char const*, int, QTextCodec::ConverterState*) const
calls=5 671 
* 8964
* 15

fn=(3128) QTextCodec::fromUnicode(QChar const*, int, QTextCodec::ConverterState*) const
104 5112
+1 6390
cfi=(101)
cfn=(3130) QUtf8Codec::convertFromUnicode(QChar const*, int, QTextCodec::ConverterState*) const
calls=639 661 
* 133123640
* 1917

fn=(4924) QTextCodec::ConverterState::ConverterState(QFlags<QTextCodec::ConversionFlag>)
90 10144
+1 55792

fl=(119) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qshareddata.h
fn=(4978) QSharedDataPointer<QLocalePrivate>::detach_helper()
230 400
+2 300
cfi=(126) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/tools/qlocale_p.h
cfn=(4980) QSharedDataPointer<QLocalePrivate>::clone()
calls=100 359 
* 24400
* 100
+1 400
cfi=(35)
cfn=(1010) QBasicAtomicInteger<int>::ref()
calls=100 127 
* 2900
+1 500
cfi=(35)
cfn=(1364) QBasicAtomicInteger<int>::deref()
calls=100 128 
* 3200
* 300
+2 300
+1 300

fn=(2934) QSharedData::QSharedData()
54 88
cfi=(61) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/thread/qatomic.h
cfn=(994) QAtomicInt::QAtomicInt(int)
calls=11 155 
* 682
* 33

fn=(3002) QSharedDataPointer<QFileInfoPrivate>::~QSharedDataPointer()
83 45
-83 72
fi=(31)
cfi=(35)
cfn=(1364)
calls=9 128 
0 288
0 117
fi=(31)
cfi=(139) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfileinfo_p.h
cfn=(3006) QFileInfoPrivate::~QFileInfoPrivate()
calls=9 61 
0 12961
0 27
fi=(31)
cob=(13)
cfi=(127)
cfn=(2652)
calls=9 32 
0 1127
fi=(31)
0 9
fe=(119)
0 45

fn=(2638) QSharedDataPointer<QLocalePrivate>::~QSharedDataPointer()
83 2980
-83 6705
fi=(31)
cfi=(35)
cfn=(1364)
calls=745 128 
0 23840
0 5076
fi=(31)
cob=(13)
cfi=(127)
cfn=(2652)
calls=101 32 
0 9292
fi=(31)
0 101
fe=(119)
0 2235

fn=(2766) QSharedDataPointer<QLocalePrivate>::QSharedDataPointer(QSharedDataPointer<QLocalePrivate> const&)
86 10
-86 26
fi=(31)
cfi=(35)
cfn=(1010)
calls=2 127 
0 58
0 6

fn=(2716) QSharedDataPointer<QLocalePrivate>::operator->() const
72 2835

fn=(2944) QSharedDataPointer<QFileInfoPrivate>::QSharedDataPointer(QFileInfoPrivate*)
219 45
+1 27
0 72
fi=(31)
cfi=(35)
cfn=(1010)
calls=9 127 
0 261
0 27

fn=(3308) QSharedDataPointer<QDirPrivate>::constData() const
77 14

fn=(2634) QSharedDataPointer<QLocalePrivate>::operator=(QSharedDataPointer<QLocalePrivate> const&)
87 45
+1 54
+1 32
+1 40
cfi=(35)
cfn=(1010)
calls=8 +37 
* 232
+1 24
+1 32
+1 48
cfi=(35)
cfn=(1364)
calls=8 +35 
* 256
* 52
+1 16
cob=(13)
cfi=(127)
cfn=(2652)
calls=3 -62 
* 276
cob=(1)
cfi=(1)
cfn=(243)
calls=1 -94 
* 3534
* 8
+2 9
+1 18

fn=(2952) QSharedDataPointer<QFileInfoPrivate>::constData() const
77 77

fn=(2434) QSharedDataPointer<QLocalePrivate>::QSharedDataPointer(QLocalePrivate*)
219 3740
+1 2244
0 6732
fi=(31)
cfi=(35)
cfn=(1010)
calls=748 127 
0 21692
0 2244

fn=(2672) QSharedDataPointer<QLocalePrivate>::operator->()
71 707
cfn=(2674) QSharedDataPointer<QLocalePrivate>::detach()
calls=101 -3 
* 39156
* 404

fn=(2674)
68 404
-68 909
fi=(31)
cfi=(35)
cfn=(864) QBasicAtomicInteger<int>::load() const
calls=101 116 
0 3535
0 905
fi=(31)
cfn=(4978)
calls=100 230 
0 33100
0 303

fn=(3300) QSharedDataPointer<QDirPrivate>::QSharedDataPointer(QDirPrivate*)
219 10
+1 6
0 16
fi=(31)
cfi=(35)
cfn=(1010)
calls=2 127 
0 58
0 6

fn=(3352) QSharedDataPointer<QDirPrivate>::~QSharedDataPointer()
83 10
-83 16
fi=(31)
cfi=(35)
cfn=(1364)
calls=2 128 
0 64
0 26
fi=(31)
cfi=(148) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qdir_p.h
cfn=(3356) QDirPrivate::~QDirPrivate()
calls=2 53 
0 2341
0 6
fi=(31)
cob=(13)
cfi=(127)
cfn=(2652)
calls=2 32 
0 251
fi=(31)
0 2
fe=(119)
0 10

fl=(93)
fn=(1526)
431 3
+1 1
cfi=(88)
cfn=(1472)
calls=1 54 
* 78
* 1
+1 2
+2 4
cfi=(35)
cfn=(1508)
calls=1 258 
* 47
* 1
+1 2
+6 1
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 20914
* 5
* 1
+2 3
cfn=(1718) QIcuCodec::codecForNameUnlocked(char const*)
calls=1 +7 
* 19918
* 1
+1 6
cfi=(35)
cfn=(2196) QBasicAtomicPointer<QTextCodec>::storeRelease(QTextCodec*)
calls=1 259 
* 60
+1 1
+1 2

fn=(2176) loadQtCodec(char const*)
351 6
+1 4
cob=(3)
cfi=(3)
cfn=(1666)
calls=1 0 
* 21
* 1
* 2
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 216
* 1
* 3
cfi=(99) /home/tsenyk/qt5/qt5/qtbase/src/corelib/codecs/qutfcodec_p.h
cfn=(2178) QUtf8Codec::QUtf8Codec()
calls=1 -51 
* 1527
* 2
+25 5

fn=(1718)
451 6
+2 4
cfi=(67) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qbytearray.cpp
cfn=(1720) qstrcmp(char const*, char const*)
calls=1 261 
* 1568
* 4
+2 4
cfi=(67)
cfn=(1720)
calls=1 261 
* 39
* 4
+3 4
cfi=(67)
cfn=(1720)
calls=1 261 
* 39
+4 2
-3 4
cfi=(67)
cfn=(1720)
calls=1 261 
* 39
* 2
+1 4
cfi=(67)
cfn=(1720)
calls=1 261 
* 39
* 2
+1 4
cfi=(67)
cfn=(1720)
calls=1 261 
* 39
* 2
+1 4
cfi=(67)
cfn=(1720)
calls=1 261 
* 39
* 3
-4 2
+7 1
+2 5
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 11301
* 5
* 1
+1 3
cfi=(94) /usr/include/unicode/utypes.h
cfn=(2118) U_FAILURE(UErrorCode)
calls=1 703 
* 7
* 7
+4 1
+1 3
cfi=(94)
cfn=(2118)
calls=1 703 
* 7
* 7
+8 4
cfi=(67)
cfn=(1720)
calls=1 261 
* 39
* 6
cfi=(67)
cfn=(1720)
calls=1 261 
* 39
* 5
+2 4
cfi=(67)
cfn=(1720)
calls=1 261 
* 39
* 6
cfi=(67)
cfn=(1720)
calls=1 261 
* 39
* 6
cfi=(67)
cfn=(1720)
calls=1 261 
* 39
* 5
+4 1
cfi=(88)
cfn=(1472)
calls=1 54 
* 78
* 1
+1 3
+3 2
+1 6
cfi=(67)
cfn=(2120) QByteArray::QByteArray(char const*, int)
calls=1 1477 
* 2592
* 5
cfi=(92) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qhash.h
cfn=(2152) QHash<QByteArray, QTextCodec*>::value(QByteArray const&) const
calls=1 +97 
* 18
* 4
cfi=(98) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qbytearray.h
cfn=(2154) QByteArray::~QByteArray()
calls=1 -27 
* 1853
+1 2
+4 6
cfi=(64)
cfn=(2168) QList<QTextCodec*>::constBegin() const
calls=1 315 
* 40
* 6
cfi=(64)
cfn=(2172) QList<QTextCodec*>::constEnd() const
calls=1 319 
* 40
* 5
cfi=(64)
cfn=(2174) QList<QTextCodec*>::const_iterator::operator!=(QList<QTextCodec*>::const_iterator const&) const
calls=1 292 
* 12
* 2
+17 3
cfn=(2176)
calls=1 351 
* 1790
* 1
+1 3
+1 2
+18 2
+1 5

fl=(38)
fn=(4110) (anonymous namespace)::Q_QGS_global_callback_table::innerFunction()::HolderBase::HolderBase()
3849 6

fn=(4108) (anonymous namespace)::Q_QGS_global_callback_table::innerFunction()::Holder::Holder()
3849 7
cfn=(4110)
calls=1 * 
* 6
* 5
cfn=(4112) QInternal_CallBackTable::QInternal_CallBackTable()
calls=1 -4 
* 31
* 3
cfi=(35)
cfn=(910)
calls=1 117 
* 44
* 3

fn=(4106) (anonymous namespace)::Q_QGS_global_callback_table::innerFunction()
3849 3761
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 6
cfn=(4108)
calls=1 * 
* 99
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 0 
* 66
* 1
* 1611

fn=(4112)
3845 7
cfi=(76) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qvector.h
cfn=(4114) QVector<QList<bool (*)(void**)> >::QVector()
calls=1 65 
* 21
* 3

fn=(754)
3884 5
cfn=(756) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 50
* 2

fn=(756)
3884 9
3155 2
cfi=(34)
cfn=(746) QBasicMutex::QBasicMutex()
calls=1 54 
* 36
3884 3

fn=(3756) qEnvironmentVariableIsEmpty(char const*)
3207 5
+1 4
cfi=(34)
cfn=(920)
calls=1 121 
* 218
+9 3
cob=(3)
cfi=(3)
cfn=(340)
calls=1 0 
* 410
* 1
* 1
+1 4
-10 3
cfi=(34)
cfn=(1050)
calls=1 132 
* 221
+10 1
+2 4

fn=(3526) qt_error_string(int)
3085 6
+1 1
+1 3
cfi=(72) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qstring.h
cfn=(1156) QString::QString()
calls=1 1064 
* 21
+1 2
+7 10
+10 2
+1 1
+40 2
+3 6
cfi=(72)
cfn=(2478) QString::fromLatin1(char const*, int)
calls=1 528 
* 1644
* 5
cfi=(72)
cfn=(2234) QString::operator=(QString&&)
calls=1 227 
* 69
* 3
cfi=(72)
cfn=(2230) QString::~QString()
calls=1 1065 
* 65
+1 5
cfi=(72)
cfn=(3528) QString::trimmed() const &
calls=1 402 
* 495
* 1
-63 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
+63 1
+1 5

fn=(4100) QInternal::activateCallbacks(QInternal::Callback, void**)
3872 3222
+1 2148
cfi=(62)
cfn=(922) qt_noop()
calls=537 623 
* 2685
+2 1074
cfi=(56)
cfn=(4102) QGlobalStatic<QInternal_CallBackTable, (anonymous namespace)::Q_QGS_global_callback_table::innerFunction(), (anonymous namespace)::Q_QGS_global_callback_table::guard>::operator()()
calls=537 129 
* 36212
* 537
+1 2685
cfi=(76)
cfn=(4118) QVector<QList<bool (*)(void**)> >::size() const
calls=537 83 
* 4296
* 3759
+7 1611
+1 2148

fn=(2264) qgetenv(char const*)
3173 156
+1 104
cfi=(34)
cfn=(920)
calls=26 121 
* 5668
+14 78
cob=(3)
cfi=(3)
cfn=(340)
calls=25 0 
* 11228
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1913
* 30
* 156
cfi=(67)
cfn=(2120)
calls=26 1477 
* 9373
* 26
-14 78
cfi=(34)
cfn=(1050)
calls=26 132 
* 5746
+14 26
+2 130

fl=(44)
fn=(786)
88 5
cfn=(788) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 50
* 2

fn=(788)
88 9
fi=(45) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfileselector.cpp
-34 2
cfi=(34)
cfn=(746)
calls=1 * 
* 36
fe=(44)
+34 3

fl=(104) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qloggingregistry.cpp
fn=(2254) QLoggingRegistry::QLoggingRegistry()
240 4
+1 4
cfi=(58)
cfn=(882)
calls=1 -64 
* 119
* 4
cfi=(76)
cfn=(2256) QVector<QLoggingRule>::QVector()
calls=1 65 
* 21
* 4
cfi=(76)
cfn=(2256)
calls=1 65 
* 21
* 4
cfi=(76)
cfn=(2256)
calls=1 65 
* 21
* 4
cfi=(76)
cfn=(2256)
calls=1 65 
* 21
* 4
cfi=(76)
cfn=(2256)
calls=1 65 
* 21
* 4
cfi=(92)
cfn=(2260) QHash<QLoggingCategory*, QtMsgType>::QHash()
calls=1 -6 
* 9
* 3
+2 3

fn=(5122) QLoggingRegistry::defaultCategoryFilter(QLoggingCategory*)
399 5
+1 1
cfn=(2242) QLoggingRegistry::instance()
calls=1 -10 
* 78
* 1
+1 6
cfi=(92)
cfn=(5052) QHash<QLoggingCategory*, QtMsgType>::contains(QLoggingCategory* const&) const
calls=1 873 
* 169
* 4
cfi=(62)
cfn=(922)
calls=1 623 
* 5
+1 6
cfi=(92)
cfn=(5128) QHash<QLoggingCategory*, QtMsgType>::value(QLoggingCategory* const&) const
calls=1 589 
* 180
* 1
+4 3
+1 5
+1 5
+1 5
+5 3
cfi=(201)
cfn=(5130)
calls=1 65 
* 7
* 3
+2 4
cob=(3)
cfi=(3)
cfn=(1666)
calls=1 0 
* 21
* 1
* 7
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1509
* 5
* 2
+4 3
cfi=(201)
cfn=(5130)
calls=1 65 
* 7
* 5
cfi=(72)
cfn=(2518) QLatin1String::QLatin1String(char const*)
calls=1 87 
* 37
* 6
cfi=(72)
cfn=(3304) QString::QString(QLatin1String)
calls=1 863 
* 1403
+1 6
cfi=(62)
cfn=(5138) QForeachContainer<QVector<QLoggingRule> >::QForeachContainer(QVector<QLoggingRule> const&)
calls=1 922 
* 212
* 10
cfi=(62)
cfn=(5154) QForeachContainer<QVector<QLoggingRule> >::~QForeachContainer()
calls=1 919 
* 75
+15 5
cfi=(199) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qloggingcategory.cpp
cfn=(5156) QLoggingCategory::setEnabled(QtMsgType, bool)
calls=1 335 
* 92
+1 5
cfi=(199)
cfn=(5156)
calls=1 335 
* 92
+1 5
cfi=(199)
cfn=(5156)
calls=1 335 
* 92
+1 5
cfi=(199)
cfn=(5156)
calls=1 335 
* 92
-19 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
+20 5

fn=(2252) (anonymous namespace)::Q_QGS_qtLoggingRegistry::innerFunction()::HolderBase::HolderBase()
50 6

fn=(2262) QLoggingRegistry::init()
272 5
+2 4
cfi=(38)
cfn=(2264)
calls=1 3173 
* 2415
+1 3
cfi=(98)
cfn=(2272) QByteArray::isEmpty() const
calls=1 477 
* 10
* 3
+3 4
cfi=(38)
cfn=(2264)
calls=1 3173 
* 926
* 5
cfi=(67)
cfn=(2274) QByteArray::replace(char, char)
calls=1 2279 
* 16
* 5
cfi=(98)
cfn=(2276) QByteArray::QByteArray(QByteArray const&)
calls=1 494 
* 66
* 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
+1 3
cfi=(98)
cfn=(2272)
calls=1 477 
* 10
* 3
+8 5
cfn=(2280) QLoggingRegistry::init()::{lambda()#2}::operator()() const
calls=1 * 
* 92
+5 4
cfi=(105) /home/tsenyk/qt5/qt5/qtbase/src/corelib/global/qlibraryinfo.cpp
cfn=(2286) QLibraryInfo::location(QLibraryInfo::LibraryLocation)
calls=1 409 
* 576865
* 5
cfi=(109) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qdir.cpp
cfn=(3230) QDir::QDir(QString const&)
calls=1 534 
* 6830
* 6
cfi=(109)
cfn=(3408) QDir::absoluteFilePath(QString const&) const
calls=1 709 
* 12490
* 3
cfi=(109)
cfn=(3350) QDir::~QDir()
calls=1 577 
* 1394
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
+1 5
cfn=(3422) loadRulesFromFile(QString const&)
calls=1 -41 
* 18848
* 6
cfi=(76)
cfn=(3630) QVector<QLoggingRule>::operator=(QVector<QLoggingRule>&&)
calls=1 73 
* 194
* 3
cfi=(76)
cfn=(3644) QVector<QLoggingRule>::~QVector()
calls=1 69 
* 65
+5 4
cfi=(95)
cfn=(3648) QFlags<QStandardPaths::LocateOption>::QFlags(QStandardPaths::LocateOption)
calls=1 111 
* 10
* 5
cfi=(72)
cfn=(2478)
calls=1 528 
* 1625
* 6
cfi=(150) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qstringbuilder.h
cfn=(3650) QStringBuilder<QConcatenable<QString>::type, QConcatenable<QString>::type> operator+<QString, QString>(QString const&, QString const&)
calls=1 +84 
* 49
* 5
cfi=(150)
cfn=(3658) QStringBuilder<QString, QString>::operator QString() const
calls=1 140 
* 1785
* 6
cfi=(166) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qstandardpaths.cpp
cfn=(3660) QStandardPaths::locate(QStandardPaths::StandardLocation, QString const&, QFlags<QStandardPaths::LocateOption>)
calls=1 410 
* 40880
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 319
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
+1 3
cfi=(72)
cfn=(1456) QString::isEmpty() const
calls=1 874 
* 10
* 3
+3 4
cfi=(76)
cfn=(3742) QVector<QLoggingRule>::isEmpty() const
calls=1 85 
* 10
* 7
cfi=(76)
cfn=(3742)
calls=1 85 
* 10
* 7
cfi=(76)
cfn=(3742)
calls=1 85 
* 10
* 6
-4 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
-6 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
-5 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
-9 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
-4 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
+32 5

fn=(2250) (anonymous namespace)::Q_QGS_qtLoggingRegistry::innerFunction()::Holder::Holder()
50 8
cfn=(2252)
calls=1 * 
* 6
* 3
cfn=(2254)
calls=1 240 
* 271
* 3
cfi=(35)
cfn=(910)
calls=1 +67 
* 44
* 5

fn=(3422)
252 6
+1 5
cfi=(106) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfile.cpp
cfn=(3424) QFile::QFile(QString const&)
calls=1 -2 
* 1991
+1 3
cfi=(156) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/io/qiodevice.h
cfn=(3458) operator|(QIODevice::OpenModeFlag, QIODevice::OpenModeFlag)
calls=1 -92 
* 79
* 5
cfi=(106)
cfn=(3464) QFile::open(QFlags<QIODevice::OpenModeFlag>)
calls=1 865 
* 13505
* 2
+9 3
cfi=(76)
cfn=(2256)
calls=1 65 
* 21
-10 3
cfi=(106)
cfn=(3558) QFile::~QFile()
calls=1 +26 
* 3219
* 1
+11 5

fn=(5050) QLoggingRegistry::registerCategory(QLoggingCategory*, QtMsgType)
315 7
+1 5
cfi=(34)
cfn=(920)
calls=1 121 
* 218
+2 6
cfi=(92)
cfn=(5052)
calls=1 873 
* 56
* 3
+1 7
cfi=(92)
cfn=(5058) QHash<QLoggingCategory*, QtMsgType>::insert(QLoggingCategory* const&, QtMsgType const&)
calls=1 736 
* 6094
+1 5
cfn=(5122)
calls=1 +79 
* 4486
-4 3
cfi=(34)
cfn=(1050)
calls=1 132 
* 221
+6 5

fn=(2248) (anonymous namespace)::Q_QGS_qtLoggingRegistry::innerFunction()
50 29
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 7
cfn=(2250)
calls=1 * 
* 340
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 -50 
* 66
* 1
* 18

fn=(2242)
390 6
+1 6
cfi=(56)
cfn=(2244) QGlobalStatic<QLoggingRegistry, (anonymous namespace)::Q_QGS_qtLoggingRegistry::innerFunction(), (anonymous namespace)::Q_QGS_qtLoggingRegistry::guard>::operator()()
calls=3 129 
* 691
+1 6

fn=(2280)
287 7
cfi=(72)
cfn=(2282) QStaticStringData<13>::data_ptr() const
calls=1 -89 
* 65
* 6
cfi=(72)
cfn=(2284) QString::QString(QStringDataPtr)
calls=1 782 
* 10
* 4

fl=(106)
fn=(3558)
279 11
cfi=(151) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfiledevice.cpp
cfn=(3560) QFileDevice::~QFileDevice()
calls=1 -59 
* 3205
+2 3

fn=(3426) QFilePrivate::QFilePrivate()
56 7
cfi=(151)
cfn=(3428) QFileDevicePrivate::QFileDevicePrivate()
calls=1 -9 
* 1165
* 7
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
+2 3

fn=(3464)
865 7
+1 3
cfi=(145) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/io/qfile.h
cfn=(3456) QFile::d_func()
calls=1 55 
* 26
* 1
+1 3
cfi=(152) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qiodevice.cpp
cfn=(3466) QIODevice::isOpen() const
calls=1 517 
* 47
* 2
+4 4
cfi=(95)
cfn=(3472) QFlags<QIODevice::OpenModeFlag>::operator&(QIODevice::OpenModeFlag) const
calls=1 136 
* 52
* 4
cfi=(95)
cfn=(3470) QFlags<QIODevice::OpenModeFlag>::operator int() const
calls=1 128 
* 7
* 4
+3 3
cfi=(151)
cfn=(3474) QFileDevice::unsetError()
calls=1 589 
* 93
+1 3
cfi=(156)
cfn=(3458)
calls=1 162 
* 79
* 4
cfi=(95)
cfn=(3470)
calls=1 128 
* 7
* 5
cfi=(95)
cfn=(3480) QFlags<QIODevice::OpenModeFlag>::operator&(int) const
calls=1 134 
* 52
* 4
cfi=(95)
cfn=(3470)
calls=1 128 
* 7
* 4
+6 7
cfn=(3482) QFilePrivate::engine() const
calls=1 97 
* 3324
* 8
cfi=(95)
cfn=(3460) QFlags<QIODevice::OpenModeFlag>::operator|(QIODevice::OpenModeFlag) const
calls=1 131 
* 52
* 3
cfi=(158) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfsfileengine.cpp
cfn=(3500) QFSFileEngine::open(QFlags<QIODevice::OpenModeFlag>)
calls=1 196 
* 9198
* 2
+6 4
cfi=(113) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qabstractfileengine.cpp
cfn=(3550) QAbstractFileEngine::error() const
calls=1 1230 
* 38
* 1
+1 2
+2 6
cfi=(113)
cfn=(3554) QAbstractFileEngine::errorString() const
calls=1 1243 
* 151
* 6
cfi=(151)
cfn=(3556) QFileDevicePrivate::setError(QFileDevice::FileError, QString const&)
calls=1 74 
* 174
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
+1 2
+1 5

fn=(3592) QFilePrivate::~QFilePrivate()
60 4
+2 3
cfn=(3593) QFilePrivate::~QFilePrivate()'2
calls=1 -2 
* 2009
* 4
cob=(13)
cfi=(127)
cfn=(2652)
calls=1 -30 
* 130
* 1
* 2

fn=(3593)
60 11
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
* 3
cfi=(151)
cfn=(3594) QFileDevicePrivate::~QFileDevicePrivate()
calls=1 -6 
* 1894
+2 3

fn=(3424)
251 7
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 291
* 1
* 3
cfn=(3426)
calls=1 56 
* 1203
* 6
cfi=(151)
cfn=(3452) QFileDevice::QFileDevice(QFileDevicePrivate&, QObject*)
calls=1 -41 
* 276
* 4
+2 3
cfi=(145)
cfn=(3456)
calls=1 55 
* 26
* 1
+1 6
cfi=(86)
cfn=(2534) QString::operator=(QString const&)
calls=1 1791 
* 156
+1 6

fn=(2312) QFile::exists(QString const&)
430 8
+1 6
cfi=(107) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfileinfo.cpp
cfn=(2314) QFileInfo::exists(QString const&)
calls=2 694 
* 489634
+1 4

fn=(3482)
97 4
+1 4
+1 4
cfi=(113)
cfn=(3484) QAbstractFileEngine::create(QString const&)
calls=1 199 
* 3305
* 3
+1 2
+1 2

fl=(110) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfilesystemmetadata_p.h
fn=(3190) QFileSystemMetaData::isLegacyLink() const
185 9
cfi=(95)
cfn=(3108) QFlags<QFileSystemMetaData::MetaDataFlag>::operator&(QFileSystemMetaData::MetaDataFlag) const
calls=1 -49 
* 52
* 4
cfi=(95)
cfn=(3094) QFlags<QFileSystemMetaData::MetaDataFlag>::operator unsigned int() const
calls=1 -57 
* 7
* 4

fn=(3178) QFileSystemMetaData::exists() const
178 18
cfi=(95)
cfn=(3108)
calls=2 -42 
* 104
* 8
cfi=(95)
cfn=(3094)
calls=2 -50 
* 14
* 8

fn=(3264) QFileSystemMetaData::clear()
168 8
+2 8
cfi=(95)
cfn=(2328) QFlags<QFileSystemMetaData::MetaDataFlag>::QFlags(int QFlags<QFileSystemMetaData::MetaDataFlag>::Private::*)
calls=2 -58 
* 18
* 6
+1 6

fn=(3172) operator|(QFileSystemMetaData::MetaDataFlag, QFileSystemMetaData::MetaDataFlag)
244 40
cfi=(95)
cfn=(3090) QFlags<QFileSystemMetaData::MetaDataFlag>::QFlags(QFileSystemMetaData::MetaDataFlag)
calls=4 111 
* 40
* 20
cfi=(95)
cfn=(3174) QFlags<QFileSystemMetaData::MetaDataFlag>::operator|(QFileSystemMetaData::MetaDataFlag) const
calls=4 131 
* 208
* 8

fn=(3346) QFileSystemMetaData::clearFlags(QFlags<QFileSystemMetaData::MetaDataFlag>)
173 15
fi=(143) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/io/qfilesystemmetadata_p.h
+2 9
cfi=(95)
cfn=(3112) QFlags<QFileSystemMetaData::MetaDataFlag>::operator~() const
calls=3 -38 
* 153
* 12
cfi=(95)
cfn=(3094)
calls=3 -47 
* 21
* 15
cfi=(95)
cfn=(3114) QFlags<QFileSystemMetaData::MetaDataFlag>::operator&=(unsigned int)
calls=3 -54 
* 39
+1 9
fe=(110)

fn=(2326) QFileSystemMetaData::QFileSystemMetaData()
68 56
+2 56
cfi=(95)
cfn=(2328)
calls=14 +42 
* 126
* 70
cfi=(95)
cfn=(2328)
calls=14 +42 
* 126
* 28
fi=(143)
+2 42
fe=(110)

fl=(116) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qlocale.cpp
fn=(2372) (anonymous namespace)::Q_QGS_defaultLocalePrivate::innerFunction()
701 20
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 7
cfn=(2374) (anonymous namespace)::Q_QGS_defaultLocalePrivate::innerFunction()::Holder::Holder()
calls=1 * 
* 455628
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 0 
* 66
* 1
* 12

fn=(2380) systemData()
635 2
+3 3
+1 1
cfn=(2382) QLocalePrivate::updateSystemPrivate()
calls=1 -51 
* 455255
+2 1
+4 2

fn=(2392) (anonymous namespace)::Q_QGS_QSystemLocale_globalSystemLocale::innerFunction()::Holder::Holder()
74 8
cfn=(2394) (anonymous namespace)::Q_QGS_QSystemLocale_globalSystemLocale::innerFunction()::HolderBase::HolderBase()
calls=1 * 
* 6
* 3
cfn=(2396) QSystemLocaleSingleton::QSystemLocaleSingleton()
calls=1 -3 
* 26
* 3
cfi=(35)
cfn=(910)
calls=1 +43 
* 44
* 5

fn=(2404) (anonymous namespace)::Q_QGS_globalLocaleData::innerFunction()
76 9
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 6
cfn=(2406) (anonymous namespace)::Q_QGS_globalLocaleData::innerFunction()::Holder::Holder()
calls=1 * 
* 99
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 -76 
* 66
* 1
* 3

fn=(2432) c_private()
535 1476
+2 738
+1 1476

fn=(2516) localePrivateByName(QString const&)
705 36
+1 36
cfi=(72)
cfn=(2518)
calls=9 87 
* 333
* 54
cfi=(86)
cfn=(2522) QString::operator==(QLatin1String) const
calls=9 2699 
* 297
* 18
+2 27
cfn=(2526) findLocaleData(QString const&)
calls=9 478 
* 366158
* 9
+1 81
cfi=(125) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qlocale_p.h
cfn=(2626) QLocalePrivate::create(QLocaleData const*, int)
calls=9 307 
* 2583
+1 18

fn=(3066) QLocaleData::c()
655 2
+1 4
cfi=(62)
cfn=(922)
calls=1 -33 
* 5
+1 1
+1 2

fn=(2376) (anonymous namespace)::Q_QGS_defaultLocalePrivate::innerFunction()::HolderBase::HolderBase()
701 6

fn=(2378) defaultData()
648 2
+1 3
+1 1
cfn=(2380)
calls=1 -15 
* 455264
* 1
+1 1
+1 2

fn=(2514) QLocale::QLocale(QString const&)
768 45
+1 27
cfn=(2516)
calls=9 -64 
* 369650
* 45
cfi=(119)
cfn=(2434)
calls=9 219 
* 441
+2 27

fn=(2530) qt_splitLocaleName(QString const&, QString&, QString&, QString&)
403 72
+1 27
cfi=(72)
cfn=(2532) QString::length() const
calls=9 866 
* 72
* 9
+2 27
cfi=(72)
cfn=(1156)
calls=9 1064 
* 189
* 45
cfi=(72)
cfn=(2234)
calls=9 227 
* 621
* 45
cfi=(86)
cfn=(2534)
calls=9 1791 
* 1116
* 45
cfi=(86)
cfn=(2534)
calls=9 1791 
* 1116
* 27
cfi=(72)
cfn=(2230)
calls=9 1065 
* 585
+2 45
cfn=(2536) qt_splitLocaleName(QString const&, QString&, QString&, QString&)::{lambda()#1}::operator()() const
calls=9 * 
* 828
+2 9
+1 144
+1 54
cfi=(72)
cfn=(1156)
calls=18 1064 
* 378
+1 108
cfn=(2540) parse_locale_tag(QString const&, int&, QString*, QString const&)
calls=18 -30 
* 47070
* 108
cfi=(72)
cfn=(1456)
calls=18 874 
* 180
* 90
+2 144
cfi=(72)
cfn=(2574) QString::at(int) const
calls=18 868 
* 1674
* 36
+1 90
+2 27
cfi=(114) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qchar.h
cfn=(2578) QChar::isNull() const
calls=9 +11 
* 81
* 81
cfi=(72)
cfn=(2550) QString::contains(QChar, Qt::CaseSensitivity) const
calls=9 1119 
* 2412
* 54
+4 45
cfi=(86)
cfn=(2534)
calls=9 1791 
* 1404
+1 27
+5 9
+1 9
+2 45
cfi=(72)
cfn=(2478)
calls=9 +97 
* 30800
+1 27
cfi=(72)
cfn=(2532)
calls=9 866 
* 72
* 45
+6 45
cfi=(86)
cfn=(2534)
calls=9 1791 
* 1404
+1 9
+2 9
-10 27
cfi=(72)
cfn=(2230)
calls=9 1065 
* 2763
* 9
+21 126
cfi=(72)
cfn=(2230)
calls=18 1065 
* 1764
* 36
-40 18
-1 18
+43 27
cfi=(72)
cfn=(2532)
calls=9 866 
* 72
* 36
-46 27
cfi=(72)
cfn=(2230)
calls=9 1065 
* 585
+46 18
+1 36

fn=(2754) QLocale::zeroDigit() const
1949 4
+1 3
cfi=(119)
cfn=(2716)
calls=1 72 
* 7
* 2
cfi=(125)
cfn=(2756) QLocalePrivate::zero() const
calls=1 320 
* 26
+1 2

fn=(2374)
701 8
cfn=(2376)
calls=1 * 
* 6
* 3
cfn=(2378)
calls=1 -53 
* 455274
* 3
cfi=(125)
cfn=(2626)
calls=1 307 
* 228
* 5
cfi=(119)
cfn=(2434)
calls=1 219 
* 49
* 3
cfi=(35)
cfn=(910)
calls=1 117 
* 44
* 5

fn=(4976) QLocale::operator!=(QLocale const&) const
873 600
+1 300
cfi=(119)
cfn=(2716)
calls=100 72 
* 700
* 400
cfi=(119)
cfn=(2716)
calls=100 72 
* 700
* 600
cfi=(119)
cfn=(2716)
calls=100 72 
* 700
* 400
cfi=(119)
cfn=(2716)
calls=100 72 
* 700
* 400
+1 400

fn=(2394)
74 6

fn=(2408) (anonymous namespace)::Q_QGS_globalLocaleData::innerFunction()::HolderBase::HolderBase()
76 6

fn=(2584) QLocalePrivate::codeToLanguage(QString const&)
88 54
+1 27
cfi=(72)
cfn=(2532)
calls=9 866 
* 72
* 9
+1 18
+2 36
cfi=(72)
cfn=(2344) QString::operator[](int) const
calls=9 870 
* 837
* 36
cfi=(114)
cfn=(2586) QChar::toLower() const
calls=9 407 
* 999
* 36
cfi=(114)
cfn=(2556) QChar::unicode()
calls=9 421 
* 54
* 18
+1 36
cfi=(72)
cfn=(2344)
calls=9 870 
* 837
* 36
cfi=(114)
cfn=(2586)
calls=9 407 
* 999
* 36
cfi=(114)
cfn=(2556)
calls=9 421 
* 54
* 18
+1 81
+2 18
+1 1328
+1 1846
+1 108
-2 646
+31 45

fn=(2636) QLocale::~QLocale()
852 5215
cfi=(119)
cfn=(2638)
calls=745 83 
* 50229
+2 2235

fn=(2714) QLocale::decimalPoint() const
1919 4
+1 3
cfi=(119)
cfn=(2716)
calls=1 72 
* 7
* 2
cfi=(125)
cfn=(2718) QLocalePrivate::decimal() const
calls=1 316 
* 26
+1 2

fn=(4986) QLocaleData::unsLongLongToString(QChar, QChar, QChar, unsigned long long, int, int, int, unsigned int)
2982 1300
+1 100
+1 200
+1 100
+1 100
+3 700
cfi=(142) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qlocale_tools.cpp
cfn=(3074) qulltoa(unsigned long long, int, QChar)
calls=100 121 
* 102212
+2 100
+1 400
+7 300
cfi=(72)
cfn=(2532)
calls=100 866 
* 800
* 400
+5 400
-2 200
+2 200
-2 400
+2 500
-2 200
+7 200
+2 400
+2 200
+14 400
+3 200
+2 200
+4 400
+2 400
+3 100
+1 800

fn=(2382)
588 4
+1 1
cfn=(2384) systemLocale()
calls=1 -8 
* 311
* 1
+1 3
+1 2
cfi=(56)
cfn=(2400) QGlobalStatic<QLocaleData, (anonymous namespace)::Q_QGS_globalLocaleData::innerFunction(), (anonymous namespace)::Q_QGS_globalLocaleData::guard>::operator()()
calls=1 129 
* 300
* 1
+3 7
cfi=(117) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/kernel/qvariant.h
cfn=(2410) QVariant::QVariant()
calls=1 193 
* 30
* 7
cfi=(118) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qlocale_unix.cpp
cfn=(2414) QSystemLocale::query(QSystemLocale::QueryType, QVariant) const
calls=1 128 
* 380069
* 3
cfi=(129) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qvariant.cpp
cfn=(2664) QVariant::~QVariant()
calls=1 1373 
* 25
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
+2 10
cfi=(118)
cfn=(2666) QSystemLocale::fallbackUiLocale() const
calls=1 105 
* 52225
* 3
cfi=(119)
cfn=(2672)
calls=1 71 
* 67
* 45
cfn=(2636)
calls=1 852 
* 163
+2 7
cfi=(117)
cfn=(2410)
calls=1 193 
* 30
* 7
cfi=(118)
cfn=(2414)
calls=1 128 
* 1262
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
+1 3
cfi=(129)
cfn=(2690) QVariant::isNull() const
calls=1 3607 
* 105
* 3
+4 7
cfi=(117)
cfn=(2410)
calls=1 193 
* 30
* 7
cfi=(118)
cfn=(2414)
calls=1 128 
* 1262
* 5
cfi=(117)
cfn=(2704) QVariant::operator=(QVariant&&)
calls=1 260 
* 123
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
+1 3
cfi=(129)
cfn=(2690)
calls=1 3607 
* 105
* 3
+4 7
cfi=(117)
cfn=(2410)
calls=1 193 
* 30
* 7
cfi=(118)
cfn=(2414)
calls=1 128 
* 1262
* 5
cfi=(117)
cfn=(2704)
calls=1 260 
* 123
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
+1 3
cfi=(129)
cfn=(2690)
calls=1 3607 
* 105
* 3
+3 7
cfi=(117)
cfn=(2410)
calls=1 193 
* 30
* 7
cfi=(118)
cfn=(2414)
calls=1 128 
* 1367
* 5
cfi=(117)
cfn=(2704)
calls=1 260 
* 123
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
+1 3
cfi=(129)
cfn=(2690)
calls=1 3607 
* 141
* 3
+1 6
cfi=(129)
cfn=(2738) QVariant::toString() const
calls=1 2247 
* 1304
* 4
cfi=(72)
cfn=(2574)
calls=1 868 
* 93
* 4
cfi=(114)
cfn=(2570) QChar::unicode() const
calls=1 420 
* 7
* 4
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
+2 7
cfi=(117)
cfn=(2410)
calls=1 193 
* 30
* 7
cfi=(118)
cfn=(2414)
calls=1 128 
* 1367
* 5
cfi=(117)
cfn=(2704)
calls=1 260 
* 123
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
+1 3
cfi=(129)
cfn=(2690)
calls=1 3607 
* 141
* 3
+1 6
cfi=(129)
cfn=(2738)
calls=1 2247 
* 1304
* 4
cfi=(72)
cfn=(2574)
calls=1 868 
* 93
* 4
cfi=(114)
cfn=(2570)
calls=1 420 
* 7
* 4
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
+2 7
cfi=(117)
cfn=(2410)
calls=1 193 
* 30
* 7
cfi=(118)
cfn=(2414)
calls=1 128 
* 1367
* 5
cfi=(117)
cfn=(2704)
calls=1 260 
* 123
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
+1 3
cfi=(129)
cfn=(2690)
calls=1 3607 
* 141
* 3
+1 6
cfi=(129)
cfn=(2738)
calls=1 2247 
* 1304
* 4
cfi=(72)
cfn=(2574)
calls=1 868 
* 93
* 4
cfi=(114)
cfn=(2570)
calls=1 420 
* 7
* 4
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
+2 7
cfi=(117)
cfn=(2410)
calls=1 193 
* 30
* 7
cfi=(118)
cfn=(2414)
calls=1 128 
* 1367
* 5
cfi=(117)
cfn=(2704)
calls=1 260 
* 123
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
+1 3
cfi=(129)
cfn=(2690)
calls=1 3607 
* 141
* 3
+1 6
cfi=(129)
cfn=(2738)
calls=1 2247 
* 1304
* 4
cfi=(72)
cfn=(2574)
calls=1 868 
* 93
* 4
cfi=(114)
cfn=(2570)
calls=1 420 
* 7
* 4
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
+2 7
cfi=(117)
cfn=(2410)
calls=1 193 
* 30
* 7
cfi=(118)
cfn=(2414)
calls=1 128 
* 1367
* 5
cfi=(117)
cfn=(2704)
calls=1 260 
* 123
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
* 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
+1 3
cfi=(129)
cfn=(2690)
calls=1 3607 
* 141
* 3
+1 6
cfi=(129)
cfn=(2738)
calls=1 2247 
* 1304
* 4
cfi=(72)
cfn=(2574)
calls=1 868 
* 93
* 4
cfi=(114)
cfn=(2570)
calls=1 420 
* 7
* 4
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
-32 3
cfi=(129)
cfn=(2664)
calls=1 1373 
* 25
+33 5

fn=(2406)
76 7
cfn=(2408)
calls=1 * 
* 6
* 39
cfi=(35)
cfn=(910)
calls=1 +41 
* 44
* 3

fn=(2428) QLocale::QLocale(QLocale::Language, QLocale::Country)
805 4428
+1 3690
cfn=(2430) findLocalePrivate(QLocale::Language, QLocale::Script, QLocale::Country)
calls=738 -92 
* 12546
* 3690
cfi=(119)
cfn=(2434)
calls=738 219 
* 36162
+2 2214

fn=(2536)
408 63
cfi=(72)
cfn=(2538) QStaticStringData<4>::data_ptr() const
calls=9 198 
* 585
* 54
cfi=(72)
cfn=(2284)
calls=9 782 
* 90
* 36

fn=(2600) QLocalePrivate::codeToScript(QString const&)
131 36
+1 27
cfi=(72)
cfn=(2532)
calls=9 866 
* 72
* 9
+1 18
+1 18
+14 18

fn=(2758) QLocale::negativeSign() const
1959 4
+1 3
cfi=(119)
cfn=(2716)
calls=1 72 
* 7
* 2
cfi=(125)
cfn=(2760) QLocalePrivate::minus() const
calls=1 322 
* 26
+1 2

fn=(2384)
581 2
+1 3
+2 2
cfi=(56)
cfn=(2386) QGlobalStatic<QSystemLocaleSingleton, (anonymous namespace)::Q_QGS_QSystemLocale_globalSystemLocale::innerFunction(), (anonymous namespace)::Q_QGS_QSystemLocale_globalSystemLocale::guard>::operator()()
calls=1 129 
* 302
+1 2

fn=(2396)
71 8
cfn=(2398) QSystemLocale::QSystemLocale(bool)
calls=1 564 
* 12
* 6

fn=(2398)
564 9
+1 3

fn=(2526)
478 36
+4 54
cfn=(2528) QLocalePrivate::getLangAndCountry(QString const&, QLocale::Language&, QLocale::Script&, QLocale::Country&)
calls=9 -23 
* 133493
+2 54
cfn=(2614) QLocaleData::findLocaleData(QLocale::Language, QLocale::Script, QLocale::Country)
calls=9 336 
* 232503
+1 18

fn=(2540)
383 126
+1 90
cfi=(86)
cfn=(2210) QString::QString(int, Qt::Initialization)
calls=18 1557 
* 13464
* 90
cfi=(72)
cfn=(2234)
calls=18 227 
* 1242
* 54
cfi=(72)
cfn=(2230)
calls=18 1065 
* 1170
+1 54
cfi=(72)
cfn=(2542) QString::data()
calls=18 880 
* 2160
* 18
+1 54
cfi=(72)
cfn=(2548) QString::data() const
calls=18 878 
* 864
* 126
+1 54
cfi=(72)
cfn=(2532)
calls=18 866 
* 144
* 18
+1 18
+1 324
+1 324
cfi=(72)
cfn=(2550)
calls=54 1119 
* 21744
* 108
+2 108
cfi=(114)
cfn=(2570)
calls=36 +28 
* 252
* 162
cfi=(114)
cfn=(2570)
calls=18 +28 
* 126
* 54
+1 54
cfi=(114)
cfn=(2570)
calls=18 +27 
* 126
* 18
-1 36
+1 54
cfi=(114)
cfn=(2570)
calls=18 +27 
* 126
* 54
-1 108
+4 288
-7 252
+2 18
+7 90
cfi=(86)
cfn=(2224) QString::truncate(int)
calls=18 4971 
* 2844
+1 18
+1 36

fn=(2618) QLocaleId::withLikelySubtagsAdded() const
229 36
+2 36
+1 108
cfi=(125)
cfn=(2616) QLocaleId::fromIds(unsigned short, unsigned short, unsigned short)
calls=9 -92 
* 342
* 72
+1 27
cfn=(2620) addLikelySubtags(QLocaleId&)
calls=9 -19 
* 208951
* 18
+4 36
+1 90
cfi=(125)
cfn=(2616)
calls=9 -98 
* 342
* 72
+1 27
cfn=(2620)
calls=9 -25 
* 20969
* 18
+1 27
+1 45
+20 171
+1 18

fn=(3070) QLocaleData::longLongToString(QChar, QChar, QChar, QChar, long long, int, int, int, unsigned int)
2887 13
+1 1
+1 2
+1 1
+1 1
+3 3
+1 2
+7 3
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
+1 2
+1 6
cfi=(142)
cfn=(3072) qlltoa(long long, int, QChar)
calls=1 153 
* 997
* 5
cfi=(72)
cfn=(2234)
calls=1 227 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
* 1
+4 1
+1 4
+7 3
cfi=(72)
cfn=(2532)
calls=1 866 
* 8
* 4
+5 4
-2 2
+2 2
-2 4
+2 5
-2 2
+7 2
+2 4
+2 2
+20 4
+3 2
+2 2
+4 2
+2 4
+2 4
+3 1
+1 8

fn=(2390) (anonymous namespace)::Q_QGS_QSystemLocale_globalSystemLocale::innerFunction()
74 11
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 7
cfn=(2392)
calls=1 * 
* 95
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 -74 
* 66
* 1
* 6

fn=(2430)
714 4428
+1 1476
+1 738
cfn=(2432)
calls=738 535 
* 3690
* 738
+12 1476

fn=(2528)
459 72
+1 18
+1 18
+1 18
+2 27
cfi=(72)
cfn=(1156)
calls=9 1064 
* 189
+1 27
cfi=(72)
cfn=(1156)
calls=9 1064 
* 189
+1 27
cfi=(72)
cfn=(1156)
calls=9 1064 
* 189
+1 54
cfn=(2530)
calls=9 -64 
* 97121
* 27
+3 27
cfn=(2584)
calls=9 88 
* 8284
* 27
+1 36
+2 27
cfn=(2600)
calls=9 131 
* 198
* 27
+1 27
cfn=(2602) QLocalePrivate::codeToCountry(QString const&)
calls=9 151 
* 20816
* 63
cfi=(72)
cfn=(2230)
calls=9 1065 
* 2610
* 18
-8 45
cfi=(72)
cfn=(2230)
calls=9 1065 
* 585
* 18
-1 45
cfi=(72)
cfn=(2230)
calls=9 1065 
* 2610
* 9
-1 9
+11 36

fn=(2614)
336 54
+1 81
cfi=(125)
cfn=(2616)
calls=9 140 
* 342
* 72
+1 27
cfn=(2618)
calls=9 229 
* 231405
* 72
+2 72
+2 81
+2 18
+3 54
cfi=(62)
cfn=(922)
calls=9 623 
* 45
+2 54
+3 90
+1 18
+27 18

fn=(2750) QLocale::groupSeparator() const
1929 4
+1 3
cfi=(119)
cfn=(2716)
calls=1 72 
* 7
* 2
cfi=(125)
cfn=(2752) QLocalePrivate::group() const
calls=1 317 
* 26
+1 2

fn=(2762) QLocale::positiveSign() const
1969 4
+1 3
cfi=(119)
cfn=(2716)
calls=1 72 
* 7
* 2
cfi=(125)
cfn=(2764) QLocalePrivate::plus() const
calls=1 321 
* 26
+1 2

fn=(3068) QLocaleData::longLongToString(long long, int, int, int, unsigned int) const
2877 9
+1 2
+1 5
cfi=(114)
cfn=(2348) QChar::QChar(unsigned short)
calls=1 76 
* 11
-1 2
+1 5
cfi=(114)
cfn=(2348)
calls=1 76 
* 11
-1 2
+1 5
cfi=(114)
cfn=(2348)
calls=1 76 
* 11
-1 2
+1 5
cfi=(114)
cfn=(2348)
calls=1 76 
* 11
* 16
cfn=(3070)
calls=1 +8 
* 1269
* 1
+1 3

fn=(4984) QLocaleData::unsLongLongToString(unsigned long long, int, int, int, unsigned int) const
2972 900
+1 200
+1 500
cfi=(114)
cfn=(2348)
calls=100 76 
* 1100
-1 200
+1 500
cfi=(114)
cfn=(2348)
calls=100 76 
* 1100
-1 200
+1 500
cfi=(114)
cfn=(2348)
calls=100 76 
* 1100
* 1500
cfn=(4986)
calls=100 +8 
* 111912
* 100
+1 300

fn=(2366) QLocale::QLocale()
781 8
+1 4
cfi=(56)
cfn=(2368) QGlobalStatic<QSharedDataPointer<QLocalePrivate>, (anonymous namespace)::Q_QGS_defaultLocalePrivate::innerFunction(), (anonymous namespace)::Q_QGS_defaultLocalePrivate::guard>::operator*()
calls=2 135 
* 455919
* 10
cfi=(119)
cfn=(2766)
calls=2 86 
* 100
+2 6

fn=(2602)
151 54
+1 27
cfi=(72)
cfn=(2532)
calls=9 866 
* 72
* 9
+1 18
+2 36
cfi=(72)
cfn=(2344)
calls=9 870 
* 837
* 36
cfi=(114)
cfn=(2604) QChar::toUpper() const
calls=9 408 
* 999
* 36
cfi=(114)
cfn=(2556)
calls=9 421 
* 54
* 18
+1 36
cfi=(72)
cfn=(2344)
calls=9 870 
* 837
* 36
cfi=(114)
cfn=(2604)
calls=9 408 
* 999
* 36
cfi=(114)
cfn=(2556)
calls=9 421 
* 54
* 18
+1 81
+2 18
+1 5848
+1 7598
+1 108
-2 2906
+6 45

fn=(2620)
214 72
+2 18
+1 36
+1 54
+1 22227
+1 88800
cfi=(125)
cfn=(2622) QLocaleId::operator==(QLocaleId) const
calls=7400 -74 
* 89014
* 14800
+1 54
+1 18
-3 14782
+6 9
+1 36

fn=(2632) QLocale::operator=(QLocale const&)
862 45
+1 45
cfi=(119)
cfn=(2634)
calls=9 87 
* 4676
+1 9
+1 18

fn=(5292) QLocaleData::bytearrayToUnsLongLong(char const*, int, bool*)
3377 6
+3 6
cfi=(142)
cfn=(5294) qstrtoull(char const*, char const**, int, bool*)
calls=1 73 
* 155
* 1
+2 4
+1 2
+1 2
+1 2
+6 2

fl=(121) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/thread/qreadwritelock.h
fn=(2688) QReadLocker::unlock()
84 32
+2 32
+1 40
+1 48
+1 24
cfn=(2682) QReadLocker::readWriteLock() const
calls=8 +15 
* 64
* 16
cfi=(90) /home/tsenyk/qt5/qt5/qtbase/src/corelib/thread/qreadwritelock.cpp
cfn=(2646) QReadWriteLock::unlock()
calls=8 407 
* 4024
+3 24

fn=(2680) QReadLocker::relock()
94 32
+2 32
+1 40
+1 24
cfn=(2682)
calls=8 +6 
* 64
* 16
cfi=(90)
cfn=(2684) QReadWriteLock::lockForRead()
calls=8 +38 
* 3984
+1 48
+3 24

fn=(2448) QWriteLocker::relock()
138 8
+2 8
+1 10
+1 6
cfn=(2450) QWriteLocker::readWriteLock() const
calls=2 +6 
* 16
* 4
cfi=(90)
cfn=(2452) QReadWriteLock::lockForWrite()
calls=2 275 
* 986
+1 12
+3 6

fn=(2644) QWriteLocker::unlock()
128 8
+2 8
+1 10
+1 12
+1 6
cfn=(2450)
calls=2 +15 
* 16
* 4
cfi=(90)
cfn=(2646)
calls=2 407 
* 1018
+3 6

fn=(2678) QReadLocker::QReadLocker(QReadWriteLock*)
112 40
+1 24
+2 24
+1 16
-1 8
cfi=(62)
cfn=(922)
calls=8 623 
* 40
+2 24
cfn=(2680)
calls=8 -23 
* 4264
+1 24

fn=(2682)
104 48
+1 80

fn=(2446) QWriteLocker::QWriteLocker(QReadWriteLock*)
157 10
+1 6
+2 6
+1 4
-1 2
cfi=(62)
cfn=(922)
calls=2 623 
* 10
+2 6
cfn=(2448)
calls=2 -24 
* 1056
+1 6

fn=(2450)
148 12
+1 20

fn=(2686) QReadLocker::~QReadLocker()
81 32
+1 24
cfn=(2688)
calls=8 +2 
* 4304
* 24

fn=(2642) QWriteLocker::~QWriteLocker()
125 8
+1 6
cfn=(2644)
calls=2 +2 
* 1088
* 6

fl=(156)
fn=(3458)
162 20
cfi=(95)
cfn=(3432) QFlags<QIODevice::OpenModeFlag>::QFlags(QIODevice::OpenModeFlag)
calls=2 -51 
* 20
* 10
cfi=(95)
cfn=(3460)
calls=2 -31 
* 104
* 4

fn=(3468) QIODevice::d_func() const
158 16
cfi=(62)
cfn=(1322)
calls=2 1014 
* 32
* 4

fl=(77) /home/tsenyk/qt5/qt5/qtbase/src/corelib/thread/qthread_p.h
fn=(1358) QAdoptedThread::d_func()
304 16
cfi=(62)
cfn=(1322)
calls=2 1014 
* 32
* 4

fn=(1196) QPostEventList::QPostEventList()
110 5
+1 3
cfi=(76)
cfn=(1198) QVector<QPostEvent>::QVector()
calls=1 -46 
* 21
* 11
cfi=(58)
cfn=(882)
calls=1 +66 
* 119
+1 5

fn=(1222) QThreadData::FlaggedDebugSignatures::FlaggedDebugSignatures()
260 6
+1 8
cfi=(78) /usr/include/c++/6.1.1/bits/stl_algobase.h
cfn=(1224) char const** std::fill_n<char const**, unsigned int, char*>(char const**, unsigned int, char* const&)
calls=1 784 
* 54
* 3

fl=(130) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/kernel/qmetatype_p.h
fn=(2694) QModulesPrivate::moduleForType(unsigned int)
56 39
+1 26
+1 26
+6 26

fl=(52)
fn=(844)
224 5
cfn=(846) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 5655
* 2

fn=(846)
224 11
fi=(53)
-93 529
cfi=(34)
cfn=(746)
calls=131 -77 
* 4716
* 393
fe=(52)
+93 6

fl=(113)
fn=(3484)
199 6
+1 5
cfi=(108) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfilesystementry.cpp
cfn=(2316) QFileSystemEntry::QFileSystemEntry(QString const&)
calls=1 80 
* 164
+1 3
cfi=(110)
cfn=(2326)
calls=1 68 
* 36
+1 5
cfi=(111) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfilesystemengine.cpp
cfn=(2330) QFileSystemEngine::resolveEntryAndCreateLegacyEngine(QFileSystemEntry&, QFileSystemMetaData&)
calls=1 -14 
* 1265
* 1
+3 2
+2 5
cfi=(108)
cfn=(2336) QFileSystemEntry::filePath() const
calls=1 -84 
* 151
* 3
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 126
* 1
* 4
cfi=(158)
cfn=(3486) QFSFileEngine::QFSFileEngine(QString const&)
calls=1 -63 
* 1239
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
* 1
-7 3
cfi=(138) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/io/qfilesystementry_p.h
cfn=(2930) QFileSystemEntry::~QFileSystemEntry()
calls=1 57 
* 177
* 2
+11 5

fn=(2340) qt_custom_file_engine_handler_create(QString const&)
155 65
+1 13
+2 39
+11 26
+1 52

fn=(2824) QAbstractFileEngine::QAbstractFileEngine(QAbstractFileEnginePrivate&)
357 30
cfi=(81) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qscopedpointer.h
cfn=(2826) QScopedPointer<QAbstractFileEnginePrivate, QScopedPointerDeleter<QAbstractFileEnginePrivate> >::QScopedPointer(QAbstractFileEnginePrivate*)
calls=2 94 
* 20
+2 8
cfi=(81)
cfn=(2828) QScopedPointer<QAbstractFileEnginePrivate, QScopedPointerDeleter<QAbstractFileEnginePrivate> >::operator->() const
calls=2 110 
* 36
* 6
+1 6

fn=(3554)
1243 5
+1 3
cfi=(115) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/io/qabstractfileengine_p.h
cfn=(3552) QAbstractFileEngine::d_func() const
calls=1 199 
* 26
* 1
+1 6
cfi=(72)
cfn=(2320) QString::QString(QString const&)
calls=1 889 
* 107
+1 3

fn=(3546) QAbstractFileEngine::setError(QFileDevice::FileError, QString const&)
1256 6
+1 3
cfi=(115)
cfn=(3548) QAbstractFileEngine::d_func()
calls=1 199 
* 26
* 1
+1 3
+1 6
cfi=(86)
cfn=(2534)
calls=1 1791 
* 156
+1 3

fn=(3020) QAbstractFileEngine::~QAbstractFileEngine()
365 24
cfi=(81)
cfn=(3022) QScopedPointer<QAbstractFileEnginePrivate, QScopedPointerDeleter<QAbstractFileEnginePrivate> >::~QScopedPointer()
calls=2 98 
* 2469
+2 6

fn=(3550)
1230 4
+1 3
cfi=(115)
cfn=(3552)
calls=1 199 
* 26
* 1
+1 2
+1 2

fl=(192) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/io/qdebug.h
fn=(4914) QDebug::Stream::Stream(QtMsgType)
62 3170
+1 2536
cfi=(95)
cfn=(3432)
calls=634 +48 
* 6340
* 4438
cfi=(193)
cfn=(4916) QTextStream::QTextStream(QString*, QFlags<QIODevice::OpenModeFlag>)
calls=634 1043 
* 132529027
* 2536
cfi=(72)
cfn=(1156)
calls=634 1064 
* 13314
* 8242
cfi=(197) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/global/qlogging.h
cfn=(4956) QMessageLogContext::QMessageLogContext()
calls=634 -3 
* 10144
* 3170

fn=(4910) QDebug::QDebug(QtMsgType)
101 4438
0 1268
fi=(31)
cob=(13)
cfi=(59)
cfn=(888)
calls=634 43 
0 74277
fi=(31)
0 634
fe=(192)
0 3170
fi=(31)
cfn=(4914)
calls=634 62 
0 132582917
0 5072

fl=(148)
fn=(3356)
53 16
cfi=(138)
cfn=(2930)
calls=2 +4 
* 321
* 8
cfi=(138)
cfn=(2930)
calls=2 +4 
* 354
* 8
cfi=(81)
cfn=(3014) QScopedPointer<QAbstractFileEngine, QScopedPointerDeleter<QAbstractFileEngine> >::~QScopedPointer()
calls=2 +45 
* 44
* 8
cfi=(120) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qstringlist.h
cfn=(3036) QStringList::~QStringList()
calls=2 +40 
* 1244
* 8
cfi=(64)
cfn=(3282) QList<QFileInfo>::~QList()
calls=2 814 
* 148
* 8
cfi=(120)
cfn=(3036)
calls=2 +40 
* 168
* 6

fl=(202) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qloggingcategory.h
fn=(5168) QLoggingCategory::isDebugEnabled() const
55 5072
cfi=(35)
cfn=(5170) QBasicAtomicInteger<bool>::load() const
calls=634 +61 
* 31066
* 1268

fl=(48) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/../../3rdparty/forkfd/forkfd.c
fn=(804) Header::Header()
119 7
cfi=(35)
cfn=(806) QBasicAtomicPointer<BigArray>::QBasicAtomicPointer()
calls=1 329 
* 26
* 4
cfi=(35)
cfn=(812) QBasicAtomicInteger<int>::QBasicAtomicInteger()
calls=1 233 
* 26
* 3

fn=(802) SmallArray::SmallArray()
131 6
0 3
fi=(31)
cfn=(804)
calls=1 119 
0 66
0 70
fi=(31)
cfn=(820) process_info::process_info()
calls=16 112 
0 576
0 54

fn=(820)
112 112
cfi=(35)
cfn=(812)
calls=16 233 
* 416
* 48

fl=(81)
fn=(4954) QScopedPointer<QTextStreamPrivate, QScopedPointerDeleter<QTextStreamPrivate> >::data() const
133 8208
+2 5472
+1 5472

fn=(2826)
94 14
+2 6

fn=(2828)
110 8
+2 10
cfi=(62)
cfn=(922)
calls=2 623 
* 10
+1 4
+1 4

fn=(3030) QScopedPointer<QResourcePrivate, QScopedPointerDeleter<QResourcePrivate> >::~QScopedPointer()
98 4
+2 3
+1 3
cfn=(3032) QScopedPointerDeleter<QResourcePrivate>::cleanup(QResourcePrivate*)
calls=1 -55 
* 1381
+1 3

fn=(1326) QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::operator->() const
110 4712
+2 5890
cfi=(62)
cfn=(922)
calls=1178 623 
* 5890
+1 2356
+1 2356

fn=(3366) QScopedPointer<QSettings, QScopedPointerDeleter<QSettings> >::data() const
133 9
+2 6
+1 6

fn=(1324) QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::data() const
133 210034491
+2 140022994
+1 140022994

fn=(2816) QScopedPointer<QResourcePrivate, QScopedPointerDeleter<QResourcePrivate> >::QScopedPointer(QResourcePrivate*)
94 7
+2 3

fn=(2956) QScopedPointer<QAbstractFileEngine, QScopedPointerDeleter<QAbstractFileEngine> >::isNull() const
138 33
+2 44
+1 22

fn=(3014)
98 44
+2 33
+1 33
cfn=(3016) QScopedPointerDeleter<QAbstractFileEngine>::cleanup(QAbstractFileEngine*)
calls=11 -55 
* 1944
+1 33

fn=(3024) QScopedPointerDeleter<QAbstractFileEnginePrivate>::cleanup(QAbstractFileEnginePrivate*)
46 8
+8 18
cfi=(160) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfsfileengine_p.h
cfn=(3602) QFSFileEnginePrivate::~QFSFileEnginePrivate()
calls=1 +74 
* 736
cfi=(55) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qresource.cpp
cfn=(3026) QResourceFileEnginePrivate::~QResourceFileEnginePrivate()
calls=1 1183 
* 1675
+1 6

fn=(3032)
46 5
+8 5
cfi=(55)
cfn=(3034) QResourcePrivate::~QResourcePrivate()
calls=1 212 
* 1270
* 3
cob=(13)
cfi=(127)
cfn=(2652)
calls=1 -22 
* 92
* 1
+1 5

fn=(4260) QScopedPointer<QObjectPrivate::Connection, QScopedPointerDeleter<QObjectPrivate::Connection> >::data() const
133 30000003
+2 20000002
+1 20000002

fn=(5348) QScopedPointer<QTextStreamPrivate, QScopedPointerDeleter<QTextStreamPrivate> >::~QScopedPointer()
98 2536
+2 1902
+1 1902
cfn=(5350) QScopedPointerDeleter<QTextStreamPrivate>::cleanup(QTextStreamPrivate*)
calls=634 -55 
* 725103
+1 1902

fn=(3370) QScopedPointer<QSettings, QScopedPointerDeleter<QSettings> >::isNull() const
138 3
+2 4
+1 2

fn=(1452) QScopedPointer<QStringList, QScopedPointerDeleter<QStringList> >::QScopedPointer(QStringList*)
94 14
+2 6

fn=(2822) QScopedPointer<QResourcePrivate, QScopedPointerDeleter<QResourcePrivate> >::data() const
133 12
+2 8
+1 8

fn=(4256) QScopedPointer<QObjectPrivate::Connection, QScopedPointerDeleter<QObjectPrivate::Connection> >::QScopedPointer(QObjectPrivate::Connection*)
94 70000007
+2 30000003

fn=(4324) QScopedPointer<QObjectPrivate::Connection, QScopedPointerDeleter<QObjectPrivate::Connection> >::~QScopedPointer()
98 40000004
+2 30000003
+1 30000003
cfn=(4326) QScopedPointerDeleter<QObjectPrivate::Connection>::cleanup(QObjectPrivate::Connection*)
calls=10000001 -55 
* 130000013
+1 30000003

fn=(2954) QScopedPointer<QAbstractFileEngine, QScopedPointerDeleter<QAbstractFileEngine> >::operator QAbstractFileEngine* QScopedPointer<QAbstractFileEngine, QScopedPointerDeleter<QAbstractFileEngine> >::*() const
127 40
+2 30
cfn=(2956)
calls=10 +9 
* 90
* 39
+1 20

fn=(3022)
98 8
+2 6
+1 6
cfn=(3024)
calls=2 -55 
* 2443
+1 6

fn=(3268) QScopedPointer<QAbstractFileEngine, QScopedPointerDeleter<QAbstractFileEngine> >::reset(QAbstractFileEngine*)
143 10
+2 8
+1 2
+4 4

fn=(4258) QScopedPointer<QObjectPrivate::Connection, QScopedPointerDeleter<QObjectPrivate::Connection> >::operator->() const
110 240000024
+2 300000030
cfi=(62)
cfn=(922)
calls=60000006 623 
* 300000030
+1 120000012
+1 120000012

fn=(4326)
46 50000005
+8 30000003
+1 50000005

fn=(4948) QScopedPointer<QTextStreamPrivate, QScopedPointerDeleter<QTextStreamPrivate> >::QScopedPointer(QTextStreamPrivate*)
94 4438
+2 1902

fn=(1318) QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::QScopedPointer(QObjectData*)
94 4480
+2 1920

fn=(2302) QScopedPointer<QSettings, QScopedPointerDeleter<QSettings> >::QScopedPointer(QSettings*)
94 7
+2 3

fn=(2834) QScopedPointer<QAbstractFileEnginePrivate, QScopedPointerDeleter<QAbstractFileEnginePrivate> >::data() const
133 24
+2 16
+1 16

fn=(2936) QScopedPointer<QAbstractFileEngine, QScopedPointerDeleter<QAbstractFileEngine> >::QScopedPointer(QAbstractFileEngine*)
94 77
+2 33

fn=(3016)
46 44
+8 29
cfi=(55)
cfn=(3018) QResourceFileEngine::~QResourceFileEngine()
calls=1 1236 
* 1838
+1 33

fn=(3364) QScopedPointer<QSettings, QScopedPointerDeleter<QSettings> >::reset(QSettings*)
143 5
+2 4
+1 1
+4 2

fn=(4892) QScopedPointer<QtPrivate::QSlotObjectBase, QSlotObjectBaseDeleter>::reset(QtPrivate::QSlotObjectBase*)
143 50002670
+2 40002136
+2 30001602
+1 30001602
+1 30001602
cfi=(53)
cfn=(4894) QSlotObjectBaseDeleter::cleanup(QtPrivate::QSlotObjectBase*)
calls=10000534 -70 
* 1810030438
* 10000534
+1 20001068

fn=(2988) QScopedPointer<QAbstractFileEngine, QScopedPointerDeleter<QAbstractFileEngine> >::operator->() const
110 4
+2 5
cfi=(62)
cfn=(922)
calls=1 623 
* 5
+1 2
+1 2

fn=(4864) QScopedPointer<QtPrivate::QSlotObjectBase, QSlotObjectBaseDeleter>::QScopedPointer(QtPrivate::QSlotObjectBase*)
94 70003738
+2 30001602

fn=(4898) QScopedPointer<QtPrivate::QSlotObjectBase, QSlotObjectBaseDeleter>::~QScopedPointer()
98 40002136
+2 30001602
+1 30001602
cfi=(53)
cfn=(4894)
calls=10000534 -22 
* 90004806
+1 30001602

fn=(4308) QScopedPointer<QObjectPrivate::Connection, QScopedPointerDeleter<QObjectPrivate::Connection> >::take()
152 30000003
+2 30000003
+1 20000002
+1 10000001
+1 20000002

fn=(3590) QScopedPointerDeleter<QObjectData>::cleanup(QObjectData*)
46 2540
+8 5715
cfi=(53)
cfn=(3622) QObjectPrivate::~QObjectPrivate()
calls=634 227 
* 180056
cfi=(106)
cfn=(3592)
calls=1 +6 
* 2153
+1 1905

fn=(4866) QScopedPointer<QtPrivate::QSlotObjectBase, QSlotObjectBaseDeleter>::operator->() const
110 40002136
+2 50002670
cfi=(62)
cfn=(922)
calls=10000534 623 
* 50002670
+1 20001068
+1 20001068

fn=(3368) QScopedPointer<QSettings, QScopedPointerDeleter<QSettings> >::operator QSettings* QScopedPointer<QSettings, QScopedPointerDeleter<QSettings> >::*() const
127 4
+2 3
cfn=(3370)
calls=1 +9 
* 9
* 4
+1 2

fn=(2962) QScopedPointer<QAbstractFileEngine, QScopedPointerDeleter<QAbstractFileEngine> >::operator!() const
116 3
+2 4
+1 2

fn=(3588) QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::~QScopedPointer()
98 2540
+2 1905
+1 1905
cfn=(3590)
calls=635 -55 
* 192369
+1 1905

fn=(3744) QScopedPointer<QStringList, QScopedPointerDeleter<QStringList> >::take()
152 6
+2 6
+1 4
+1 2
+1 4

fn=(5350)
46 3170
+8 3170
cfi=(193)
cfn=(5352) QTextStreamPrivate::~QTextStreamPrivate()
calls=634 337 
* 616004
* 1902
cob=(13)
cfi=(127)
cfn=(2652)
calls=634 -22 
* 97053
* 634
+1 3170

fl=(162) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/kernel/qcore_unix_p.h
fn=(5082) qt_safe_read(int, void*, long long)
248 6
+1 1
+1 6
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1069
* 5
* 3
+1 1
+1 2

fn=(3508) qt_safe_open(char const*, int, unsigned int)
158 6
+2 1
+3 7
cob=(5)
cfi=(5)
cfn=(3514)
calls=1 0 
* 7
* 1
* 3
+4 2
+1 6
cob=(5)
cfi=(5)
cfn=(5078)
calls=1 0 
* 22
* 1
+1 1
+1 2
-12 6
+2 1
+3 7
cob=(5)
cfi=(5)
cfn=(3514)
calls=1 0 
* 7
* 1
* 3
+4 2
+1 6
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1084
* 5
+1 1
+1 2
-12 6
+2 1
+3 7
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1081
* 5
* 4
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1187
* 5
* 3
+4 2
+2 1
+1 2

fn=(4436) operator<(timespec const&, timespec const&)
106 10744
0 40578

fn=(5088) qt_safe_close(int)
272 4
+2 3
cob=(5)
cfi=(5)
cfn=(5094)
calls=1 0 
* 7
* 1
* 3
+1 1
+1 2
-4 4
+2 3
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1069
* 5
* 3
+1 1
+1 2

fl=(203) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qelapsedtimer.h
fn=(5212) QElapsedTimer::QElapsedTimer()
53 3
+2 6
+2 3

fl=(56)
fn=(2368)
135 8
+2 6
cfn=(2370) QGlobalStatic<QSharedDataPointer<QLocalePrivate>, (anonymous namespace)::Q_QGS_defaultLocalePrivate::innerFunction(), (anonymous namespace)::Q_QGS_defaultLocalePrivate::guard>::isDestroyed() const
calls=2 -11 
* 90
* 6
cfi=(62)
cfn=(922)
calls=2 623 
* 10
+1 2
cfi=(116)
cfn=(2372)
calls=2 701 
* 455793
+1 4

fn=(2400)
129 7
cfn=(2402) QGlobalStatic<QLocaleData, (anonymous namespace)::Q_QGS_globalLocaleData::innerFunction(), (anonymous namespace)::Q_QGS_globalLocaleData::guard>::isDestroyed() const
calls=1 -3 
* 45
* 3
cfi=(116)
cfn=(2404)
calls=1 -53 
* 243
* 2

fn=(4174) QGlobalStatic<QList<void (*)()>, (anonymous namespace)::Q_QGS_preRList::innerFunction(), (anonymous namespace)::Q_QGS_preRList::guard>::operator()()
129 7
cfn=(4176) QGlobalStatic<QList<void (*)()>, (anonymous namespace)::Q_QGS_preRList::innerFunction(), (anonymous namespace)::Q_QGS_preRList::guard>::isDestroyed() const
calls=1 -3 
* 45
* 3
cfi=(50)
cfn=(4178) (anonymous namespace)::Q_QGS_preRList::innerFunction()
calls=1 +97 
* 229
* 2

fn=(5202) QGlobalStatic<QMessagePattern, (anonymous namespace)::Q_QGS_qMessagePattern::innerFunction(), (anonymous namespace)::Q_QGS_qMessagePattern::guard>::isDestroyed() const
126 3804
cfi=(35)
cfn=(864)
calls=634 -10 
* 22190
* 2536

fn=(978) QGlobalStatic<QList<QResourceRoot*>, (anonymous namespace)::Q_QGS_resourceList::innerFunction(), (anonymous namespace)::Q_QGS_resourceList::guard>::operator()()
129 35
cfn=(980) QGlobalStatic<QList<QResourceRoot*>, (anonymous namespace)::Q_QGS_resourceList::innerFunction(), (anonymous namespace)::Q_QGS_resourceList::guard>::isDestroyed() const
calls=5 -3 
* 225
* 15
cfi=(55)
cfn=(982) (anonymous namespace)::Q_QGS_resourceList::innerFunction()
calls=5 +16 
* 269
* 10

fn=(1440) QGlobalStatic<QCoreApplicationData, (anonymous namespace)::Q_QGS_coreappdata::innerFunction(), (anonymous namespace)::Q_QGS_coreappdata::guard>::operator()()
129 28
cfn=(1442) QGlobalStatic<QCoreApplicationData, (anonymous namespace)::Q_QGS_coreappdata::innerFunction(), (anonymous namespace)::Q_QGS_coreappdata::guard>::isDestroyed() const
calls=4 -3 
* 180
* 12
cfi=(50)
cfn=(1444) (anonymous namespace)::Q_QGS_coreappdata::innerFunction()
calls=4 383 
* 378
* 8

fn=(4348) QGlobalStatic<QFreeList<void, QtTimerIdFreeListConstants>, (anonymous namespace)::Q_QGS_timerIdFreeList::innerFunction(), (anonymous namespace)::Q_QGS_timerIdFreeList::guard>::isDestroyed() const
126 6
cfi=(35)
cfn=(864)
calls=1 -10 
* 35
* 4

fn=(980)
126 30
cfi=(35)
cfn=(864)
calls=5 -10 
* 175
* 20

fn=(1476) QGlobalStatic<QCoreGlobalData, (anonymous namespace)::Q_QGS_globalInstance::innerFunction(), (anonymous namespace)::Q_QGS_globalInstance::guard>::isDestroyed() const
126 7686
cfi=(35)
cfn=(864)
calls=1281 -10 
* 44835
* 5124

fn=(1518) QGlobalStatic<QMutex, (anonymous namespace)::Q_QGS_textCodecsMutex::innerFunction(), (anonymous namespace)::Q_QGS_textCodecsMutex::guard>::isDestroyed() const
126 18
cfi=(35)
cfn=(864)
calls=3 -10 
* 105
* 12

fn=(2290) QGlobalStatic<QLibrarySettings, (anonymous namespace)::Q_QGS_qt_library_settings::innerFunction(), (anonymous namespace)::Q_QGS_qt_library_settings::guard>::operator()()
129 14
cfn=(2292) QGlobalStatic<QLibrarySettings, (anonymous namespace)::Q_QGS_qt_library_settings::innerFunction(), (anonymous namespace)::Q_QGS_qt_library_settings::guard>::isDestroyed() const
calls=2 -3 
* 90
* 6
cfi=(105)
cfn=(2294) (anonymous namespace)::Q_QGS_qt_library_settings::innerFunction()
calls=2 -51 
* 557089
* 4

fn=(4104) QGlobalStatic<QInternal_CallBackTable, (anonymous namespace)::Q_QGS_global_callback_table::innerFunction(), (anonymous namespace)::Q_QGS_global_callback_table::guard>::isDestroyed() const
126 3222
cfi=(35)
cfn=(864)
calls=537 -10 
* 18795
* 2148

fn=(862) QGlobalStatic<QMutex, (anonymous namespace)::Q_QGS_resourceMutex::innerFunction(), (anonymous namespace)::Q_QGS_resourceMutex::guard>::isDestroyed() const
126 18
cfi=(35)
cfn=(864)
calls=3 -10 
* 105
* 12

fn=(2292)
126 12
cfi=(35)
cfn=(864)
calls=2 -10 
* 70
* 8

fn=(2370)
126 12
cfi=(35)
cfn=(864)
calls=2 -10 
* 70
* 8

fn=(4346) QGlobalStatic<QFreeList<void, QtTimerIdFreeListConstants>, (anonymous namespace)::Q_QGS_timerIdFreeList::innerFunction(), (anonymous namespace)::Q_QGS_timerIdFreeList::guard>::operator()()
129 7
cfn=(4348)
calls=1 -3 
* 45
* 3
cfi=(172) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qabstracteventdispatcher.cpp
cfn=(4350) (anonymous namespace)::Q_QGS_timerIdFreeList::innerFunction()
calls=1 -46 
* 297
* 2

fn=(1474) QGlobalStatic<QCoreGlobalData, (anonymous namespace)::Q_QGS_globalInstance::innerFunction(), (anonymous namespace)::Q_QGS_globalInstance::guard>::operator()()
129 8967
cfn=(1476)
calls=1281 -3 
* 57645
* 3843
cfi=(88)
cfn=(1478) (anonymous namespace)::Q_QGS_globalInstance::innerFunction()
calls=1281 -90 
* 20780
* 2562

fn=(1516)
129 21
cfn=(1518)
calls=3 -3 
* 135
* 9
cfi=(87)
cfn=(1520)
calls=3 -36 
* 794
* 6

fn=(2244)
129 21
cfn=(2246) QGlobalStatic<QLoggingRegistry, (anonymous namespace)::Q_QGS_qtLoggingRegistry::innerFunction(), (anonymous namespace)::Q_QGS_qtLoggingRegistry::guard>::isDestroyed() const
calls=3 -3 
* 135
* 9
cfi=(104)
cfn=(2248)
calls=3 -79 
* 520
* 6

fn=(2402)
126 6
cfi=(35)
cfn=(864)
calls=1 -10 
* 35
* 4

fn=(2416) QGlobalStatic<QSystemLocaleData, (anonymous namespace)::Q_QGS_qSystemLocaleData::innerFunction(), (anonymous namespace)::Q_QGS_qSystemLocaleData::guard>::operator()()
129 63
cfn=(2418) QGlobalStatic<QSystemLocaleData, (anonymous namespace)::Q_QGS_qSystemLocaleData::innerFunction(), (anonymous namespace)::Q_QGS_qSystemLocaleData::guard>::isDestroyed() const
calls=9 -3 
* 405
* 27
cfi=(118)
cfn=(2420) (anonymous namespace)::Q_QGS_qSystemLocaleData::innerFunction()
calls=9 -31 
* 189302
* 18

fn=(4176)
126 6
cfi=(35)
cfn=(864)
calls=1 -10 
* 35
* 4

fn=(1442)
126 24
cfi=(35)
cfn=(864)
calls=4 -10 
* 140
* 16

fn=(2246)
126 18
cfi=(35)
cfn=(864)
calls=3 -10 
* 105
* 12

fn=(2386)
129 7
cfn=(2388) QGlobalStatic<QSystemLocaleSingleton, (anonymous namespace)::Q_QGS_QSystemLocale_globalSystemLocale::innerFunction(), (anonymous namespace)::Q_QGS_QSystemLocale_globalSystemLocale::guard>::isDestroyed() const
calls=1 -3 
* 45
* 3
cfi=(116)
cfn=(2390)
calls=1 -55 
* 245
* 2

fn=(2388)
126 6
cfi=(35)
cfn=(864)
calls=1 -10 
* 35
* 4

fn=(2418)
126 54
cfi=(35)
cfn=(864)
calls=9 -10 
* 315
* 36

fn=(5036) QGlobalStatic<QLoggingCategory, (anonymous namespace)::Q_QGS_qtDefaultCategory::innerFunction(), (anonymous namespace)::Q_QGS_qtDefaultCategory::guard>::operator()()
129 4438
cfn=(5038) QGlobalStatic<QLoggingCategory, (anonymous namespace)::Q_QGS_qtDefaultCategory::innerFunction(), (anonymous namespace)::Q_QGS_qtDefaultCategory::guard>::isDestroyed() const
calls=634 -3 
* 28530
* 1902
cfi=(199)
cfn=(5040) (anonymous namespace)::Q_QGS_qtDefaultCategory::innerFunction()
calls=634 -88 
* 21001
* 1268

fn=(860) QGlobalStatic<QMutex, (anonymous namespace)::Q_QGS_resourceMutex::innerFunction(), (anonymous namespace)::Q_QGS_resourceMutex::guard>::operator()()
129 21
cfn=(862)
calls=3 -3 
* 135
* 9
cfi=(55)
cfn=(872) (anonymous namespace)::Q_QGS_resourceMutex::innerFunction()
calls=3 +13 
* 4248
* 6

fn=(4102)
129 3759
cfn=(4104)
calls=537 -3 
* 24165
* 1611
cfi=(38)
cfn=(4106)
calls=537 3849 
* 5603
* 1074

fn=(5038)
126 3804
cfi=(35)
cfn=(864)
calls=634 -10 
* 22190
* 2536

fn=(5200) QGlobalStatic<QMessagePattern, (anonymous namespace)::Q_QGS_qMessagePattern::innerFunction(), (anonymous namespace)::Q_QGS_qMessagePattern::guard>::operator()()
129 4438
cfn=(5202)
calls=634 -3 
* 28530
* 1902
cfi=(39)
cfn=(5204) (anonymous namespace)::Q_QGS_qMessagePattern::innerFunction()
calls=634 1245 
* 62391
* 1268

fl=(62)
fn=(3078) int qAbs<int>(int const&)
520 10

fn=(5154)
919 7
cfi=(76)
cfn=(3644)
calls=1 69 
* 65
* 3

fn=(4952) QScopedPointer<QTextStreamPrivate, QScopedPointerDeleter<QTextStreamPrivate> >::pointer qGetPtrHelper<QScopedPointer<QTextStreamPrivate, QScopedPointerDeleter<QTextStreamPrivate> > >(QScopedPointer<QTextStreamPrivate, QScopedPointerDeleter<QTextStreamPrivate> > const&)
1014 19152
cfi=(81)
cfn=(4954)
calls=2736 133 
* 19152
* 5472

fn=(922)
623 850198400

fn=(2236) void qSwap<QTypedArrayData<unsigned short>*>(QTypedArrayData<unsigned short>*&, QTypedArrayData<unsigned short>*&)
860 800
+4 800
cfi=(103) /usr/include/c++/6.1.1/bits/move.h
cfn=(2238) std::enable_if<std::__and_<std::is_move_constructible<QTypedArrayData<unsigned short>*>, std::is_move_assignable<QTypedArrayData<unsigned short>*> >::value, void>::type std::swap<QTypedArrayData<unsigned short>*>(QTypedArrayData<unsigned short>*&, QTypedArrayData<unsigned short>*&)
calls=160 179 
* 6880
+1 480

fn=(3638) void qSwap<QTypedArrayData<QLoggingRule>*>(QTypedArrayData<QLoggingRule>*&, QTypedArrayData<QLoggingRule>*&)
860 5
+4 5
cfi=(103)
cfn=(3640) std::enable_if<std::__and_<std::is_move_constructible<QTypedArrayData<QLoggingRule>*>, std::is_move_assignable<QTypedArrayData<QLoggingRule>*> >::value, void>::type std::swap<QTypedArrayData<QLoggingRule>*>(QTypedArrayData<QLoggingRule>*&, QTypedArrayData<QLoggingRule>*&)
calls=1 179 
* 43
+1 3

fn=(5138)
922 10
cfi=(76)
cfn=(5140) QVector<QLoggingRule>::QVector(QVector<QLoggingRule> const&)
calls=1 355 
* 74
* 3
cfi=(76)
cfn=(5142) QVector<QLoggingRule>::begin() const
calls=1 199 
* 51
* 6
cfi=(76)
cfn=(5150) QVector<QLoggingRule>::end() const
calls=1 203 
* 60
* 8

fn=(1322)
1014 490065275
cfi=(81)
cfn=(1324)
calls=70009325 133 
* 490065275
* 140018664
cfi=(81)
cfn=(1324)
calls=2 133 
* 14
* 18
cfi=(81)
cfn=(1324)
calls=2 133 
* 14
* 18
cfi=(81)
cfn=(1324)
calls=2 133 
* 14
* 3777
cfi=(81)
cfn=(1324)
calls=539 133 
* 3773
* 4886
cfi=(81)
cfn=(1324)
calls=544 133 
* 3808
* 4903
cfi=(81)
cfn=(1324)
calls=545 133 
* 3815
* 4856
cfi=(81)
cfn=(1324)
calls=538 133 
* 3766
* 1076

fn=(2832) QScopedPointer<QAbstractFileEnginePrivate, QScopedPointerDeleter<QAbstractFileEnginePrivate> >::pointer qGetPtrHelper<QScopedPointer<QAbstractFileEnginePrivate, QScopedPointerDeleter<QAbstractFileEnginePrivate> > >(QScopedPointer<QAbstractFileEnginePrivate, QScopedPointerDeleter<QAbstractFileEnginePrivate> > const&)
1014 21
cfi=(81)
cfn=(2834)
calls=3 133 
* 21
* 20
cfi=(81)
cfn=(2834)
calls=2 133 
* 14
* 25
cfi=(81)
cfn=(2834)
calls=3 133 
* 21
* 6

fn=(3080) int const& qMax<int>(int const&, int const&)
547 2168
0 5413

fn=(4966) long long qAbs<long long>(long long const&)
520 1000

fn=(2820) QScopedPointer<QResourcePrivate, QScopedPointerDeleter<QResourcePrivate> >::pointer qGetPtrHelper<QScopedPointer<QResourcePrivate, QScopedPointerDeleter<QResourcePrivate> > >(QScopedPointer<QResourcePrivate, QScopedPointerDeleter<QResourcePrivate> > const&)
1014 28
cfi=(81)
cfn=(2822)
calls=4 133 
* 28
* 8

fn=(4432) unsigned int const& qMin<unsigned int>(unsigned int const&, unsigned int const&)
545 3032
0 6839

fn=(2456) void qSwap<QTypedArrayData<char>*>(QTypedArrayData<char>*&, QTypedArrayData<char>*&)
860 80
+4 80
cfi=(103)
cfn=(2458) std::enable_if<std::__and_<std::is_move_constructible<QTypedArrayData<char>*>, std::is_move_assignable<QTypedArrayData<char>*> >::value, void>::type std::swap<QTypedArrayData<char>*>(QTypedArrayData<char>*&, QTypedArrayData<char>*&)
calls=16 179 
* 688
+1 48

fn=(2706) void qSwap<QVariant::Private>(QVariant::Private&, QVariant::Private&)
860 35
+4 35
cfi=(103)
cfn=(2708) std::enable_if<std::__and_<std::is_move_constructible<QVariant::Private>, std::is_move_assignable<QVariant::Private> >::value, void>::type std::swap<QVariant::Private>(QVariant::Private&, QVariant::Private&)
calls=7 179 
* 679
+1 21

fn=(2792) void qSwap<QListData::Data*>(QListData::Data*&, QListData::Data*&)
860 75
+4 75
cfi=(103)
cfn=(2794) std::enable_if<std::__and_<std::is_move_constructible<QListData::Data*>, std::is_move_assignable<QListData::Data*> >::value, void>::type std::swap<QListData::Data*>(QListData::Data*&, QListData::Data*&)
calls=15 179 
* 645
+1 45

fn=(3338) int const& qMin<int>(int const&, int const&)
545 2580
0 5805

fn=(5384) unsigned int const& qMax<unsigned int>(unsigned int const&, unsigned int const&)
547 1244
0 3073

fl=(95)
fn=(2976) QFlags<QAbstractFileEngine::FileFlag>::operator&(int) const
134 13
cfn=(2130) QFlag::QFlag(int)
calls=1 -82 
* 10
* 5
cfn=(2972) QFlags<QAbstractFileEngine::FileFlag>::QFlags(QFlag)
calls=1 -21 
* 21
* 3

fn=(2984) QFlags<QAbstractFileEngine::FileFlag>::operator&=(int)
120 39

fn=(3100) QFlag::QFlag(unsigned int)
63 25890

fn=(3432)
111 12720

fn=(3490) QFlags<QIODevice::OpenModeFlag>::QFlags(int QFlags<QIODevice::OpenModeFlag>::Private::*)
112 5715

fn=(4972) QFlags<QTextStream::NumberFlag>::QFlags(QFlag)
113 3200
cfn=(2134) QFlag::operator int() const
calls=400 -60 
* 2800
* 2400

fn=(2134)
53 113414

fn=(2982) QFlags<QAbstractFileEngine::FileFlag>::operator|=(QAbstractFileEngine::FileFlag)
124 26

fn=(3094)
128 427

fn=(4544) QFlags<QEventLoop::ProcessEventsFlag>::operator&(QEventLoop::ProcessEventsFlag) const
136 27963
cfn=(2130)
calls=2151 -84 
* 21510
* 10755
cfn=(4538) QFlags<QEventLoop::ProcessEventsFlag>::QFlags(QFlag)
calls=2151 -23 
* 45171
* 6453

fn=(4940)
136 32968
cfn=(3100)
calls=2536 -73 
* 25360
* 12680
cfn=(4942) QFlags<QTextCodec::ConversionFlag>::QFlags(QFlag)
calls=2536 -23 
* 53256
* 7608

fn=(2122) QFlags<QArrayData::AllocationOption>::QFlags(QArrayData::AllocationOption)
111 13610

fn=(2136) QFlags<QArrayData::AllocationOption>::operator!() const
139 53982

fn=(3090)
111 130

fn=(3110) QFlags<QFileSystemMetaData::MetaDataFlag>::operator|=(QFileSystemMetaData::MetaDataFlag)
124 221

fn=(3462) QFlags<QIODevice::OpenModeFlag>::QFlags(QFlag)
113 96
cfn=(2134)
calls=12 -60 
* 84
* 72

fn=(4946) QFlags<QTextCodec::ConversionFlag>::operator|=(QTextCodec::ConversionFlag)
124 8242

fn=(2130)
52 162020

fn=(2958) QFlags<QAbstractFileEngine::FileFlag>::QFlags(QAbstractFileEngine::FileFlag)
111 20

fn=(3102) QFlags<QFileSystemMetaData::MetaDataFlag>::QFlags(QFlag)
113 424
cfn=(3104) QFlag::operator unsigned int() const
calls=53 -47 
* 371
* 318

fn=(4538)
113 25800
cfn=(2134)
calls=3225 -60 
* 22575
* 19350

fn=(4944)
128 17752

fn=(2986) QFlags<QAbstractFileEngine::FileFlag>::operator&(QAbstractFileEngine::FileFlag) const
136 39
cfn=(2130)
calls=3 -84 
* 30
* 15
cfn=(2972)
calls=3 -23 
* 63
* 9

fn=(3148) QFlags<QArrayData::AllocationOption>::operator|(QArrayData::AllocationOption) const
131 8307
cfn=(2130)
calls=639 -79 
* 6390
* 3195
cfn=(2132) QFlags<QArrayData::AllocationOption>::QFlags(QFlag)
calls=639 -18 
* 13419
* 1917

fn=(4974) QFlags<QTextStream::NumberFlag>::operator int() const
128 2800

fn=(4942)
113 20288
cfn=(3104)
calls=2536 -47 
* 17752
* 15216

fn=(2138) QFlags<QArrayData::AllocationOption>::operator int() const
128 36946

fn=(2964) QFlags<QAbstractFileEngine::FileFlag>::QFlags(int QFlags<QAbstractFileEngine::FileFlag>::Private::*)
112 18

fn=(3108)
136 455
cfn=(3100)
calls=35 -73 
* 350
* 175
cfn=(3102)
calls=35 -23 
* 735
* 105

fn=(3242) QFlags<QDir::Filter>::QFlags(QDir::Filter)
111 20

fn=(3732) QFlags<QStandardPaths::LocateOption>::operator int() const
128 14

fn=(4536) QFlags<QEventLoop::ProcessEventsFlag>::operator|(QEventLoop::ProcessEventsFlag) const
131 13962
cfn=(2130)
calls=1074 -79 
* 10740
* 5370
cfn=(4538)
calls=1074 -18 
* 22554
* 3222

fn=(4554) QFlags<QEventLoop::ProcessEventsFlag>::operator!() const
139 9675

fn=(2132)
113 100448
cfn=(2134)
calls=12556 -60 
* 87892
* 75336

fn=(2972)
113 40
cfn=(2134)
calls=5 -60 
* 35
* 30

fn=(2974) QFlags<QAbstractFileEngine::FileFlag>::operator int() const
128 56

fn=(3112)
137 96
cfn=(3100)
calls=8 -74 
* 80
* 40
cfn=(3102)
calls=8 -24 
* 168
* 24

fn=(3238) QFlags<QDir::SortFlag>::QFlags(QFlag)
113 16
cfn=(2134)
calls=2 -60 
* 14
* 12

fn=(3480)
134 13
cfn=(2130)
calls=1 -82 
* 10
* 5
cfn=(3462)
calls=1 -21 
* 21
* 3

fn=(3730) QFlags<QStandardPaths::LocateOption>::QFlags(QFlag)
113 16
cfn=(2134)
calls=2 -60 
* 14
* 12

fn=(4546) QFlags<QEventLoop::ProcessEventsFlag>::operator int() const
128 7532

fn=(4970) QFlags<QTextStream::NumberFlag>::operator&(QTextStream::NumberFlag) const
136 5200
cfn=(2130)
calls=400 -84 
* 4000
* 2000
cfn=(4972)
calls=400 -23 
* 8400
* 1200

fn=(2128) QFlags<QArrayData::AllocationOption>::operator&(QArrayData::AllocationOption) const
136 146588
cfn=(2130)
calls=11276 -84 
* 112760
* 56380
cfn=(2132)
calls=11276 -23 
* 236796
* 33828

fn=(2328)
112 270

fn=(3104)
66 18123

fn=(3114)
121 104

fn=(3174)
131 52
cfn=(3100)
calls=4 -68 
* 40
* 20
cfn=(3102)
calls=4 -18 
* 84
* 12

fn=(3236) QFlags<QDir::SortFlag>::operator|(QDir::SortFlag) const
131 26
cfn=(2130)
calls=2 -79 
* 20
* 10
cfn=(3238)
calls=2 -18 
* 42
* 6

fn=(3472)
136 104
cfn=(2130)
calls=8 -84 
* 80
* 40
cfn=(3462)
calls=8 -23 
* 168
* 24

fn=(3648)
111 10

fn=(4922) QFlags<QTextCodec::ConversionFlag>::QFlags(QTextCodec::ConversionFlag)
111 25360

fn=(2970) QFlags<QAbstractFileEngine::FileFlag>::operator|(QAbstractFileEngine::FileFlag) const
131 13
cfn=(2130)
calls=1 -79 
* 10
* 5
cfn=(2972)
calls=1 -18 
* 21
* 3

fn=(3098) QFlags<QFileSystemMetaData::MetaDataFlag>::operator&(unsigned int) const
135 78
cfn=(3100)
calls=6 -72 
* 60
* 30
cfn=(3102)
calls=6 -22 
* 126
* 18

fn=(3176) QFlags<QFileSystemMetaData::MetaDataFlag>::operator|=(QFlags<QFileSystemMetaData::MetaDataFlag>)
123 52

fn=(3234) QFlags<QDir::SortFlag>::QFlags(QDir::SortFlag)
111 20

fn=(3450) QFlags<QFileDevice::FileHandleFlag>::QFlags(int QFlags<QFileDevice::FileHandleFlag>::Private::*)
112 9

fn=(3460)
131 39
cfn=(2130)
calls=3 -79 
* 30
* 15
cfn=(3462)
calls=3 -18 
* 63
* 9

fn=(3470)
128 84

fn=(3728) QFlags<QStandardPaths::LocateOption>::operator&(QStandardPaths::LocateOption) const
136 26
cfn=(2130)
calls=2 -84 
* 20
* 10
cfn=(3730)
calls=2 -23 
* 42
* 6

fn=(4040) QFlags<QEventLoop::ProcessEventsFlag>::QFlags(QEventLoop::ProcessEventsFlag)
111 20

fn=(4928) QFlags<QTextStream::NumberFlag>::QFlags(int QFlags<QTextStream::NumberFlag>::Private::*)
112 11412

fl=(99)
fn=(3212) int QUtf8Functions::fromUtf8<QUtf8BaseTraits, unsigned short*, unsigned char const*>(unsigned char, unsigned short*&, unsigned char const*&, unsigned char const*)
178 64264
+6 24099
+2 40165
cfn=(3214) QUtf8BaseTraits::appendUtf16(unsigned short*&, unsigned short)
calls=8033 77 
* 120495
+1 16066
+83 16066

fn=(3138) int QUtf8Functions::toUtf8<QUtf8BaseTraits, unsigned char*, unsigned short const*>(unsigned short, unsigned char*&, unsigned short const*&, unsigned short const*)
115 73952
+2 27732
+2 55464
cfn=(3140) QUtf8BaseTraits::appendByte(unsigned char*&, unsigned char)
calls=9244 -54 
* 138660
fi=(146) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/codecs/qutfcodec_p.h
+1 18488
+48 18488
fe=(99)

fn=(3140)
65 46220
+1 92440

fn=(3214)
77 40165
+1 80330

fn=(2178)
302 7
cfi=(87)
cfn=(2180)
calls=1 468 
* 1513
* 7

fl=(122) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qchar.cpp
fn=(3064) QChar::digitValue(unsigned int)
1071 16
+1 8
+2 12
cfi=(123) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qunicodetables.cpp
cfn=(2592) QUnicodeTables::qGetProp(unsigned int)
calls=4 8251 
* 120
* 12
+1 8

fn=(2588) QChar::toLower(unsigned int)
1461 72
+1 36
+2 54
cfn=(2590) unsigned int convertCase_helper<QUnicodeTables::LowercaseTraits, unsigned int>(unsigned int)
calls=18 -30 
* 1296
+1 36

fn=(2608) unsigned int convertCase_helper<QUnicodeTables::UppercaseTraits, unsigned int>(unsigned int)
1434 72
+2 54
cfi=(123)
cfn=(2592)
calls=18 8251 
* 540
* 18
+2 54
cfi=(124) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qunicodetables_p.h
cfn=(2610) QUnicodeTables::UppercaseTraits::caseSpecial(QUnicodeTables::Properties const*)
calls=18 97 
* 180
* 90
+6 54
cfi=(124)
cfn=(2612) QUnicodeTables::UppercaseTraits::caseDiff(QUnicodeTables::Properties const*)
calls=18 95 
* 144
* 54
+1 36

fn=(2590)
1434 72
+2 54
cfi=(123)
cfn=(2592)
calls=18 8251 
* 540
* 18
+2 54
cfi=(124)
cfn=(2594) QUnicodeTables::LowercaseTraits::caseSpecial(QUnicodeTables::Properties const*)
calls=18 89 
* 180
* 90
+6 54
cfi=(124)
cfn=(2596) QUnicodeTables::LowercaseTraits::caseDiff(QUnicodeTables::Properties const*)
calls=18 87 
* 144
* 54
+1 36

fn=(2606) QChar::toUpper(unsigned int)
1481 72
+1 36
+2 54
cfn=(2608)
calls=18 -50 
* 1296
+1 36

fl=(185) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qeventdispatcher_glib_p.h
fn=(4400) QEventDispatcherGlib::d_func()
60 4304
cfi=(62)
cfn=(1322)
calls=538 1014 
* 8608
* 1076

fl=(49)
fn=(826) (anonymous namespace)::qlibraryCleanup_dtor_class_::qlibraryCleanup_dtor_class_()
423 6

fn=(822)
1129 5
cfn=(824) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 129
* 2

fn=(824)
1129 9
370 2
cfi=(34)
cfn=(746)
calls=1 54 
* 36
+53 2
cfn=(826)
calls=1 * 
* 6
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 0 
* 66
* 1
1129 3

fl=(54)
fn=(854) (anonymous namespace)::initializer::initializer()
15810 5
cfn=(856) qInitResources_mimetypes()
calls=1 -16 
* 9894
* 3

fn=(850)
15813 5
cfn=(852) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 9987
* 2

fn=(856)
15794 2
+2 5
cfi=(55)
cfn=(858) qRegisterResourceData(int, unsigned char const*, unsigned char const*, unsigned char const*)
calls=1 824 
* 9884
+1 1
+1 2

fn=(852)
15813 9
-1 2
cfn=(854)
calls=1 -2 
* 9902
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 0 
* 66
* 1
+1 3

fl=(55)
fn=(880) (anonymous namespace)::Q_QGS_resourceMutex::innerFunction()::HolderBase::HolderBase()
142 6

fn=(2770) QResource::QResource(QString const&, QLocale const&)
362 10
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 216
* 1
* 5
cfn=(2772) QResourcePrivate::QResourcePrivate(QResource*)
calls=1 211 
* 991
* 4
cfi=(81)
cfn=(2816)
calls=1 94 
* 10
+2 3
cfi=(134) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qresource.h
cfn=(2818) QResource::d_func()
calls=1 86 
* 25
* 1
+1 6
cfi=(86)
cfn=(2534)
calls=1 1791 
* 124
+1 5
cfi=(116)
cfn=(2632)
calls=1 862 
* 27
+1 6

fn=(2842) QResourcePrivate::ensureInitialized() const
290 10
+1 8
cfi=(64)
cfn=(2844) QList<QResourceRoot*>::isEmpty() const
calls=2 185 
* 44
* 6
+2 4
+1 8
cfi=(72)
cfn=(2518)
calls=2 87 
* 74
* 16
cfi=(86)
cfn=(2522)
calls=2 2699 
* 66
* 4
+2 14
cfi=(86)
cfn=(2534)
calls=2 1791 
* 248
+1 8
cfi=(114)
cfn=(2350) QLatin1Char::QLatin1Char(char)
calls=2 47 
* 22
* 10
cfi=(114)
cfn=(2352) QChar::QChar(QLatin1Char)
calls=2 82 
* 44
* 14
cfi=(86)
cfn=(2846) QString::startsWith(QChar, Qt::CaseSensitivity) const
calls=2 4395 
* 202
* 6
+3 12
cfi=(72)
cfn=(2320)
calls=2 889 
* 150
+1 8
cfi=(114)
cfn=(2350)
calls=2 47 
* 22
* 10
cfi=(114)
cfn=(2352)
calls=2 82 
* 44
* 12
cfi=(86)
cfn=(2846)
calls=2 4395 
* 202
* 4
+1 12
cfi=(86)
cfn=(2848) QString::mid(int, int) const
calls=2 4344 
* 1886
* 10
cfi=(72)
cfn=(2234)
calls=2 -75 
* 138
* 6
cfi=(72)
cfn=(2230)
calls=2 1065 
* 130
+2 8
cfi=(114)
cfn=(2350)
calls=2 47 
* 22
* 10
cfi=(114)
cfn=(2352)
calls=2 82 
* 44
* 12
cfi=(86)
cfn=(2846)
calls=2 4395 
* 202
* 4
+1 10
cfn=(2854) QResourcePrivate::load(QString const&)
calls=2 -53 
* 13084
* 2
-5 6
cfi=(72)
cfn=(2230)
calls=2 1065 
* 580
* 2
+18 8

fn=(2902) QStringSplitter::hasNext()
68 8
+1 72
cfi=(114)
cfn=(2356) operator==(QChar, QChar)
calls=4 567 
* 40
* 22
+1 10
-1 2
+2 12
+1 4

fn=(2772)
211 9
cfi=(116)
cfn=(2366)
calls=1 781 
* 142
* 4
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
* 4
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
* 4
cfi=(64)
cfn=(988) QList<QResourceRoot*>::QList()
calls=1 -70 
* 19
* 4
cfi=(120)
cfn=(2438) QStringList::QStringList()
calls=1 97 
* 29
* 6
cfn=(2774) QResourcePrivate::clear()
calls=1 +24 
* 723
* 5

fn=(2836) QResource::setFileName(QString const&)
410 5
+1 3
cfi=(134)
cfn=(2818)
calls=1 86 
* 25
* 1
+1 3
cfn=(2774)
calls=1 235 
* 723
+1 6
cfi=(86)
cfn=(2534)
calls=1 1791 
* 124
+1 3

fn=(2916) QResourceRoot::hash(int) const
581 10
+1 4
+2 10
cfn=(2918) QResourceRoot::findOffset(int) const
calls=2 98 
* 16
* 2
+1 38
+1 18
-1 2
+1 20
+1 2
+1 38
+1 18
-1 2
+1 18
+1 4

fn=(3034)
212 7
cfn=(2774)
calls=1 +23 
* 889
* 4
cfi=(120)
cfn=(3036)
calls=1 93 
* 84
* 4
cfi=(64)
cfn=(2812) QList<QResourceRoot*>::~QList()
calls=1 814 
* 74
* 4
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
* 4
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
* 3
cfi=(116)
cfn=(2636)
calls=1 852 
* 64
* 3

fn=(986) (anonymous namespace)::Q_QGS_resourceList::innerFunction()::HolderBase::HolderBase()
145 6

fn=(2360) QResourceFileEnginePrivate::QResourceFileEnginePrivate()
1194 5
0 3
fi=(31)
cfi=(115)
cfn=(2362) QAbstractFileEnginePrivate::QAbstractFileEnginePrivate()
calls=1 247 
0 37
0 8
fi=(31)
cfi=(116)
cfn=(2366)
calls=1 781 
0 455905
0 3
fi=(31)
cfi=(72)
cfn=(1156)
calls=1 1064 
0 21
0 7
fi=(31)
cfn=(2770)
calls=1 362 
0 1434
0 3
fi=(31)
cfi=(72)
cfn=(2230)
calls=1 1065 
0 65
0 3
fi=(31)
cfi=(116)
cfn=(2636)
calls=1 852 
0 64
0 4
fi=(31)
cfi=(98)
cfn=(2324) QByteArray::QByteArray()
calls=1 464 
0 21
0 5

fn=(2854)
252 12
+1 8
cfi=(64)
cfn=(2802) QList<QResourceRoot*>::clear()
calls=2 862 
* 624
+1 4
cfi=(56)
cfn=(860)
calls=2 129 
* 144
* 10
cfi=(34)
cfn=(920)
calls=2 121 
* 1164
+1 4
cfi=(56)
cfn=(978)
calls=2 129 
* 134
* 2
+1 10
cfn=(2856) cleanPath(QString const&)
calls=2 131 
* 6032
+1 8
cfi=(64)
cfn=(1006) QList<QResourceRoot*>::size() const
calls=2 -97 
* 44
* 6
cfi=(64)
cfn=(1006)
calls=2 -97 
* 44
* 16
+1 10
cfi=(64)
cfn=(2890) QList<QResourceRoot*>::at(int) const
calls=2 530 
* 128
* 4
+1 12
cfn=(2896) QResourceRoot::findNode(QString const&, QLocale const&) const
calls=2 616 
* 2948
* 2
+1 4
+16 12
cfn=(2924) QResourceRoot::mappingRootSubdir(QString const&, QString*) const
calls=2 800 
* 282
* 4
-19 4
+28 8
cfi=(64)
cfn=(2844)
calls=2 185 
* 44
* 4
-29 6
cfi=(72)
cfn=(2230)
calls=2 1065 
* 196
-2 6
cfi=(34)
cfn=(1050)
calls=2 132 
* 1132
+31 4
+1 8

fn=(2856)
131 12
+1 10
cfi=(109)
cfn=(2858) QDir::cleanPath(QString const&)
calls=2 2175 
* 5134
+3 8
cfi=(72)
cfn=(2518)
calls=2 -48 
* 74
* 12
cfi=(86)
cfn=(2876) QString::startsWith(QLatin1String, Qt::CaseSensitivity) const
calls=2 4384 
* 766
* 4
+2 2
+1 10

fn=(2904) QStringSplitter::next()
74 10
+1 6
+1 108
cfi=(114)
cfn=(2862) operator!=(QChar, QChar)
calls=6 570 
* 138
* 34
+1 20
-1 4
+2 18
cfi=(72)
cfn=(2906) QStringRef::QStringRef(QString const*, int, int)
calls=2 1498 
* 36
+1 6

fn=(2990) QResourceFileEngine::fileFlags(QFlags<QAbstractFileEngine::FileFlag>) const
1357 6
+1 3
cfi=(135) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qresource_p.h
cfn=(2992) QResourceFileEngine::d_func() const
calls=1 56 
* 26
* 1
+1 4
cfi=(95)
cfn=(2964)
calls=1 112 
* 9
+1 4
cfn=(2994) QResource::isValid() const
calls=1 451 
* 8789
* 3
+1 2
+16 4

fn=(982)
145 37
cob=(13)
cfi=(19)
cfn=(618)
calls=1 +98 
* 36
* 1
* 6
cfn=(984) (anonymous namespace)::Q_QGS_resourceList::innerFunction()::Holder::Holder()
calls=1 * 
* 85
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 0 
* 66
* 1
* 15

fn=(2838) QResource::isCompressed() const
475 4
+1 3
cfi=(134)
cfn=(2840) QResource::d_func() const
calls=1 86 
* 25
* 1
+1 3
cfn=(2842)
calls=1 290 
* 8724
+1 5
+1 2

fn=(2898) QResourceRoot::mappingRoot() const
113 32
cfi=(72)
cfn=(1156)
calls=4 1064 
* 84
* 12

fn=(2922) QStringSplitter::~QStringSplitter()
59 14
cfi=(72)
cfn=(2230)
calls=2 1065 
* 196
* 6

fn=(872)
142 29
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
* 1235
* 5
* 7
cfn=(878) (anonymous namespace)::Q_QGS_resourceMutex::innerFunction()::Holder::Holder()
calls=1 * 
* 1664
* 2
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
* 1212
* 5
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 0 
* 66
* 1
* 18

fn=(1004) QResourceRoot::setSource(unsigned char const*, unsigned char const*, unsigned char const*)
123 12
+1 6
+1 6
+1 6
+1 6

fn=(858)
824 8
+1 2
cfi=(56)
cfn=(860)
calls=1 129 
* 4275
* 5
cfi=(34)
cfn=(920)
calls=1 121 
* 1759
+1 4
cfi=(56)
cfn=(978)
calls=1 129 
* 286
* 6
+1 1
+1 6
cfn=(992) QResourceRoot::QResourceRoot(unsigned char const*, unsigned char const*, unsigned char const*)
calls=1 106 
* 104
+1 3
cfi=(56)
cfn=(978)
calls=1 129 
* 67
* 2
cfi=(64)
cfn=(1006)
calls=1 160 
* 22
* 4
+6 4
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 216
* 1
* 7
cfn=(992)
calls=1 106 
* 104
* 1
+1 4
cfi=(35)
cfn=(1010)
calls=1 127 
* 29
+1 2
cfi=(56)
cfn=(978)
calls=1 129 
* 67
* 5
cfi=(64)
cfn=(1016) QList<QResourceRoot*>::append(QResourceRoot* const&)
calls=1 569 
* 2299
+2 1
-12 3
cfn=(1048) QResourceRoot::~QResourceRoot()
calls=1 107 
* 9
* 1
-3 3
cfi=(34)
cfn=(1050)
calls=1 132 
* 566
* 2
+18 4

fn=(878)
142 8
cfn=(880)
calls=1 * 
* 6
* 4
cfi=(58)
cfn=(882)
calls=1 +35 
* 1594
* 3
cfi=(35)
cfn=(910)
calls=1 -25 
* 44
* 5

fn=(3018)
1236 4
+2 3
cfn=(3019) QResourceFileEngine::~QResourceFileEngine()'2
calls=1 -2 
* 1732
* 4
cob=(13)
cfi=(127)
cfn=(2652)
calls=1 32 
* 92
* 1
* 2

fn=(3019)
1236 10
cfi=(113)
cfn=(3020)
calls=1 365 
* 1719
+2 3

fn=(2900) QStringSplitter::QStringSplitter(QString const&)
62 10
+1 10
cfi=(72)
cfn=(2320)
calls=2 889 
* 214
* 6
cfi=(72)
cfn=(2216) QString::constData() const
calls=2 882 
* 96
* 14
cfi=(114)
cfn=(2868) QChar::QChar()
calls=2 +12 
* 16
* 6
cfi=(72)
cfn=(2532)
calls=2 866 
* 16
* 10
+2 8
cfi=(114)
cfn=(2350)
calls=2 -18 
* 22
* 10
cfi=(114)
cfn=(2352)
calls=2 +17 
* 44
* 6
+1 6

fn=(2924)
800 16
+1 18
cfn=(2898)
calls=2 113 
* 64
+1 6
cfi=(72)
cfn=(1456)
calls=2 +72 
* 20
* 6
+17 2
-18 6
cfi=(72)
cfn=(2230)
calls=2 1065 
* 130
* 4
+19 10

fn=(3026)
1183 7
cfn=(3027) QResourceFileEnginePrivate::~QResourceFileEnginePrivate()'2
calls=1 * 
* 1569
* 4
cob=(13)
cfi=(127)
cfn=(2652)
calls=1 32 
* 92
* 1
* 2

fn=(3027)
1183 11
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
* 4
cfn=(3028) QResource::~QResource()
calls=1 372 
* 1404
* 3
cfi=(115)
cfn=(3038) QAbstractFileEnginePrivate::~QAbstractFileEnginePrivate()
calls=1 251 
* 79
* 3

fn=(3028)
372 7
cfi=(81)
cfn=(3030)
calls=1 98 
* 1394
+2 3

fn=(984)
145 7
cfn=(986)
calls=1 * 
* 6
* 3
cfi=(64)
cfn=(988)
calls=1 -4 
* 19
* 3
cfi=(35)
cfn=(910)
calls=1 -28 
* 44
* 3

fn=(1048)
107 9

fn=(2896)
616 16
+1 10
cfi=(72)
cfn=(2320)
calls=2 889 
* 214
+2 18
cfn=(2898)
calls=2 113 
* 64
+1 6
cfi=(72)
cfn=(1456)
calls=2 874 
* 20
* 6
-1 6
cfi=(72)
cfn=(2230)
calls=2 1065 
* 130
+18 8
cfi=(72)
cfn=(2518)
calls=2 87 
* 74
* 12
cfi=(86)
cfn=(2522)
calls=2 2699 
* 66
* 4
+4 28
+1 12
-1 2
+1 14
+1 28
+1 12
-1 2
+1 14
+3 2
+2 10
cfn=(2900)
calls=2 62 
* 494
+1 10
cfn=(2902)
calls=2 68 
* 170
* 12
+1 10
cfn=(2904)
calls=2 74 
* 380
+8 6
cfi=(137) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qhash.cpp
cfn=(2908) qt_hash(QStringRef const&)
calls=2 378 
* 350
* 2
+3 8
+1 18
+1 6
+10 4
+3 2
+1 10
cfn=(2916)
calls=2 -97 
* 202
* 8
+59 10
+1 8
cfi=(72)
cfn=(2920) QStringRef::~QStringRef()
calls=2 1375 
* 12
* 8
+5 2
-94 6
cfn=(2922)
calls=2 59 
* 216
-32 6
cfi=(72)
cfn=(2230)
calls=2 1065 
* 196
* 4
744 10

fn=(2994)
451 4
+1 3
cfi=(134)
cfn=(2840)
calls=1 86 
* 25
* 1
+1 3
cfn=(2842)
calls=1 290 
* 8724
+1 4
cfi=(64)
cfn=(2844)
calls=1 185 
* 22
* 1
+1 2

fn=(992)
106 30
cfi=(61)
cfn=(994)
calls=2 +49 
* 124
* 12
cfn=(1004)
calls=2 +17 
* 36
* 6

fn=(2358) QResourceFileEngine::QResourceFileEngine(QString const&)
1222 7
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 216
* 1
* 3
cfn=(2360)
calls=1 -29 
* 457588
* 5
cfi=(113)
cfn=(2824)
calls=1 357 
* 53
* 3
+2 3
cfi=(135)
cfn=(2830) QResourceFileEngine::d_func()
calls=1 56 
* 26
* 1
+1 6
cfn=(2836)
calls=1 410 
* 893
+1 4
cfn=(2838)
calls=1 475 
* 8767
* 5
+7 6

fn=(2774)
235 12
+1 12
cfi=(72)
cfn=(2776) QString::clear()
calls=3 888 
* 277
+1 12
+1 6
+1 6
+1 12
cfi=(64)
cfn=(2782) QList<QString>::clear()
calls=3 862 
* 936
+1 12
+1 15
cfi=(64)
cfn=(1006)
calls=3 -82 
* 66
* 12
+5 12
cfi=(64)
cfn=(2802)
calls=3 862 
* 936
+1 9

fn=(2918)
98 16

fl=(90)
fn=(2646)
407 50
+1 70
cfi=(34)
cfn=(920)
calls=10 121 
* 2180
+2 60
cfi=(62)
cfn=(922)
calls=10 623 
* 50
+2 10
+1 50
+2 40
+9 80
+1 34
+2 2
+1 6
+3 20
+1 50
+2 50
-26 30
cfi=(34)
cfn=(1050)
calls=10 132 
* 2210
+30 50

fn=(1488) QReadWriteLock::QReadWriteLock(QReadWriteLock::RecursionMode)
111 14
+1 4
cob=(13)
cfi=(59)
cfn=(888)
calls=2 -69 
* 432
* 2
* 10
cfi=(91) /home/tsenyk/qt5/qt5/qtbase/src/corelib/thread/qreadwritelock_p.h
cfn=(1490) QReadWriteLockPrivate::QReadWriteLockPrivate(QReadWriteLock::RecursionMode)
calls=2 -55 
* 2010
* 4
+1 12

fn=(2684)
136 40
+1 56
cfi=(34)
cfn=(920)
calls=8 -16 
* 1744
+2 8
+1 40
+13 80
+5 40
+3 40
+1 48
cfi=(62)
cfn=(922)
calls=8 623 
* 40
* 32
cfi=(34)
cfn=(1050)
calls=8 -30 
* 1768
* 8
-25 8
+26 32

fn=(2452)
275 10
+1 14
cfi=(34)
cfn=(920)
calls=2 121 
* 436
+2 2
+1 10
+11 10
+5 10
+3 10
+1 12
cfi=(62)
cfn=(922)
calls=2 623 
* 10
* 8
cfi=(34)
cfn=(1050)
calls=2 132 
* 442
* 2
-23 2
+24 8

fl=(96)
fn=(2160)
129 11940
+2 15920
cfi=(62)
cfn=(922)
calls=1990 623 
* 9950
+5 5970
+4 9950
cfi=(65) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qrefcount.h
cfn=(2162) QtPrivate::RefCount::isStatic() const
calls=1990 -53 
* 91540
* 5970
cfi=(62)
cfn=(922)
calls=1990 623 
* 9950
+2 5970
cob=(3)
cfi=(3)
cfn=(1420)
calls=1989 0 
* 710178334
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1647
* 1994
* 1990
+1 3980

fn=(2850) QtPrivate::QContainerImplHelper::mid(int, int*, int*)
150 10
+1 4
+1 4
+1 8
+3 8
+7 20
+1 12
+3 8
+3 14
+1 4

fn=(2126) QArrayData::allocate(unsigned long, unsigned long, unsigned long, QFlags<QArrayData::AllocationOption>)
61 16016
+2 16016
cfi=(62)
cfn=(922)
calls=2002 623 
* 10010
+4 8008
cfi=(95)
cfn=(2128)
calls=2002 +69 
* 104104
* 10010
cfi=(95)
cfn=(2136)
calls=2002 +72 
* 18018
* 16020
+2 16
cfi=(95)
cfn=(2128)
calls=4 +67 
* 208
* 16
cfi=(95)
cfn=(2138)
calls=4 +59 
* 28
* 16
+1 6
+2 2
+3 1998
+6 7992
cfi=(95)
cfn=(2128)
calls=1998 +55 
* 103896
* 7992
cfi=(95)
cfn=(2136)
calls=1998 +58 
* 17982
* 3996
+1 9990
+3 7992
cfi=(95)
cfn=(2128)
calls=1998 +51 
* 103896
* 7992
cfi=(95)
cfn=(2138)
calls=1998 +43 
* 13986
* 7992
+3 3
cfi=(180) /usr/include/c++/6.1.1/limits
cfn=(4282) std::numeric_limits<unsigned long>::max()
calls=3 1207 
* 15
* 18
+4 18
cfi=(97) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/global/qnumeric_p.h
cfn=(2140) QtPrivate::QEnableIf<QtPrivate::is_unsigned<unsigned long>::value, bool>::Type (anonymous namespace)::mul_overflow<unsigned long>(unsigned long, unsigned long, unsigned long*)
calls=3 252 
* 48
* 6
+4 24
+3 18
cfi=(67)
cfn=(1028) qAllocMore(int, int)
calls=3 +27 
* 219
* 24
+4 18
cfi=(97)
cfn=(2140)
calls=3 252 
* 48
* 11970
cfi=(97)
cfn=(2140)
calls=1995 252 
* 31920
* 3996
+2 11988
cfi=(97)
cfn=(2142) QtPrivate::QEnableIf<QtPrivate::is_unsigned<unsigned long>::value, bool>::Type (anonymous namespace)::add_overflow<unsigned long>(unsigned long, unsigned long, unsigned long*)
calls=1998 239 
* 33966
* 3996
+3 5994
cob=(3)
cfi=(3)
cfn=(384)
calls=1998 0 
* 258888765
* 1998
* 1998
+1 3996
+1 7992
+1 7992
+3 7992
cfi=(95)
cfn=(2128)
calls=1998 +22 
* 103896
* 7992
cfi=(95)
cfn=(2136)
calls=1998 +25 
* 17982
* 9990
cfi=(35)
cfn=(910)
calls=1998 +3 
* 87912
+4 3996
+1 19980
+1 7992
cfi=(95)
cfn=(2128)
calls=1998 +16 
* 103896
* 7992
cfi=(95)
cfn=(2138)
calls=1998 +8 
* 13986
* 17982
+1 13986
+3 1998
+1 8008

fl=(137)
fn=(5068) QHashData::detach_helper(void (*)(QHashData::Node*, void*), void (*)(QHashData::Node*), int, int)
462 9
+5 3
+1 1
cfn=(5070) qt_initialize_qhash_seed()
calls=1 286 
* 4534
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 117
* 1
* 3
cfi=(92)
cfn=(5098) QHashData::QHashData()
calls=1 56 
* 47
* 1
-3 1
+4 1
-4 1
+5 1
-5 1
+6 3
cfi=(65)
cfn=(1038) QtPrivate::RefCount::initializeOwned()
calls=1 99 
* 55
-6 1
+7 3
-7 1
+8 2
-8 1
+9 3
-9 1
+10 3
-10 1
+11 3
-11 1
+12 6
cfi=(35)
cfn=(864)
calls=1 116 
* 35
* 2
-12 1
+13 3
-13 1
+14 8
-14 1
+15 3
+2 4
+41 2
+1 4

fn=(5070)
286 3
+1 3
cfi=(35)
cfn=(864)
calls=1 116 
* 35
* 4
+1 1
cfn=(5072) qt_create_qhash_seed()
calls=1 -66 
* 4345
* 2
+1 6
cfi=(35)
cfn=(4392) QBasicAtomicInteger<int>::testAndSetRelaxed(int, int)
calls=1 133 
* 132
+2 3

fn=(5116) QHashData::allocateNode(int)
444 5
+1 10
cob=(3)
cfi=(3)
cfn=(384)
calls=1 0 
* 105
* 1
* 1
+1 3
+1 1
+1 2

fn=(5112) primeForNumBits(int)
407 3
+1 11
+1 2

fn=(5110) QHashData::rehash(int)
613 5
+1 2
+7 2
+1 1
+3 5
+1 2
+1 3
+1 3
+2 3
cfn=(5112)
calls=1 407 
* 16
* 1
+1 8
cob=(13)
cfi=(184)
cfn=(4376)
calls=1 32 
* 210
* 1
* 3
+1 4
+1 3
+1 74
+1 136
-1 34
+3 4
+17 2
+2 3

fn=(2908)
378 10
+1 6
cfi=(72)
cfn=(2910) QStringRef::size() const
calls=2 1380 
* 14
* 8
cfi=(72)
cfn=(2912) QStringRef::unicode() const
calls=2 1425 
* 136
* 6
cfn=(2914) qt_hash(QChar const*, int)
calls=2 -26 
* 162
+1 8

fn=(2914)
353 12
+1 2
+2 42
+1 32
cfi=(114)
cfn=(2570)
calls=4 +63 
* 28
* 12
+1 16
+1 4
-3 4
+5 2
+1 8

fn=(5072)
222 4
+1 1
+3 4
cfi=(38)
cfn=(2264)
calls=1 3173 
* 908
+1 3
cfi=(67)
cfn=(2466) QByteArray::isNull() const
calls=1 3389 
* 19
* 3
+4 4
cfi=(162)
cfn=(3508)
calls=1 -73 
* 1125
* 1
+1 2
+2 2
+1 6
cfi=(162)
cfn=(5082)
calls=1 +13 
* 1093
* 4
+1 3
cfi=(162)
cfn=(5088)
calls=1 +36 
* 1087
+1 2
-11 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
* 2
+40 4

fl=(199)
fn=(5048) QLoggingCategory::init(char const*, QtMsgType)
233 6
+1 5
cfi=(35)
cfn=(910)
calls=1 117 
* 44
+2 2
+1 4
+4 1
cfi=(104)
cfn=(2242)
calls=1 390 
* 78
* 3
+1 6
cfi=(104)
cfn=(5050)
calls=1 +73 
* 11116
+1 3

fn=(5156)
335 28
+1 44
+2 6
cfi=(35)
cfn=(5158) QBasicAtomicInteger<bool>::store(bool)
calls=1 117 
* 64
* 1
+1 6
cfi=(35)
cfn=(5158)
calls=1 117 
* 64
* 1
+1 6
cfi=(35)
cfn=(5158)
calls=1 117 
* 64
* 1
+1 6
cfi=(35)
cfn=(5158)
calls=1 117 
* 64
* 1
+9 12

fn=(5034) QLoggingCategory::defaultCategory()
380 1268
+1 1268
cfi=(56)
cfn=(5036)
calls=634 129 
* 57139
+1 1268

fn=(5044) (anonymous namespace)::Q_QGS_qtDefaultCategory::innerFunction()::HolderBase::HolderBase()
41 6

fn=(5166) QLoggingCategory::isEnabled(QtMsgType) const
313 3170
+1 6974
+1 1902
cfi=(202)
cfn=(5168)
calls=634 55 
* 37406
* 634
+7 1268

fn=(5042) (anonymous namespace)::Q_QGS_qtDefaultCategory::innerFunction()::Holder::Holder()
41 8
cfn=(5044)
calls=1 * 
* 6
* 4
cfn=(5046) QLoggingCategory::QLoggingCategory(char const*)
calls=1 210 
* 11286
* 3
cfi=(35)
cfn=(910)
calls=1 +76 
* 44
* 5

fn=(5046)
210 5
+2 4
+2 6
cfn=(5048)
calls=1 +19 
* 11268
+1 3

fn=(5040)
41 5708
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 7
cfn=(5042)
calls=1 * 
* 11356
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 -41 
* 66
* 1
* 3804

fl=(42)
fn=(778)
4594 5
cfn=(780) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 50
* 2

fn=(780)
4594 9
3812 2
cfi=(34)
cfn=(746)
calls=1 54 
* 36
4594 3

fl=(66) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qlist.cpp
fn=(1024) QListData::detach_grow(int*, int)
77 54
+1 27
+1 63
+1 36
+1 27
cfn=(1026) grow(int)
calls=9 -23 
* 828
* 9
+1 54
cob=(3)
cfi=(3)
cfn=(384)
calls=8 -82 
* 1125
cob=(1)
cfi=(1)
cfn=(242)
calls=1 -82 
* 1729
* 13
* 9
+1 27
+2 27
cfi=(65)
cfn=(1038)
calls=9 +14 
* 495
+1 27
+8 36
+3 36
+1 21
+1 14
+1 12
+3 2
+2 6
+1 10
+1 6
+2 2
+1 4
-5 21
+1 35
+1 21
+2 7
+1 14

fn=(5226) QListData::append(int)
171 20
+1 16
cfi=(65)
cfn=(1018) QtPrivate::RefCount::isShared() const
calls=4 -79 
* 192
* 12
cfi=(62)
cfn=(922)
calls=4 623 
* 20
+1 16
+1 32
+1 4
+1 16
+6 5
cfn=(3708) QListData::realloc_grow(int)
calls=1 -29 
* 581
+3 24
+1 28
+1 8

fn=(5224) QListData::append()
191 16
+1 16
cfn=(5226)
calls=4 -21 
* 974
+1 8

fn=(3708)
153 10
+1 8
cfi=(65)
cfn=(1018)
calls=2 -61 
* 96
* 6
cfi=(62)
cfn=(922)
calls=2 623 
* 10
+1 14
cfn=(1026)
calls=2 -97 
* 184
* 2
+1 18
cob=(3)
cfi=(3)
cfn=(3156)
calls=2 0 
* 685
* 2
* 2
+1 6
+2 6
+1 8
+1 6

fn=(4832) QListData::erase(void**)
330 2680
+1 2144
cfi=(65)
cfn=(1018)
calls=536 93 
* 25728
* 1608
cfi=(62)
cfn=(922)
calls=536 623 
* 2680
+1 7504
+1 2680
cfn=(4834) QListData::remove(int)
calls=536 -74 
* 52528
+1 6432
+1 1072

fn=(3362) QListData::dispose(QListData::Data*)
164 20
+1 15
cfi=(65)
cfn=(1018)
calls=5 -72 
* 250
* 15
cfi=(62)
cfn=(922)
calls=5 623 
* 25
+1 15
cob=(3)
cfi=(3)
cfn=(1420)
calls=5 0 
* 440
* 5
+1 15

fn=(3706) QListData::prepend()
202 2148
+1 2148
cfi=(65)
cfn=(1018)
calls=537 93 
* 25776
* 1611
cfi=(62)
cfn=(922)
calls=537 623 
* 2685
+1 2685
+1 15
+1 4
cfn=(3708)
calls=1 -53 
* 482
+2 15
+1 13
+4 20
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1496
* 5
+1 10
+2 12
+1 2
-1 6432
+1 1072

fn=(4834)
259 2680
+1 2144
cfi=(65)
cfn=(1018)
calls=536 93 
* 25728
* 1608
cfi=(62)
cfn=(922)
calls=536 623 
* 2680
+1 2144
+1 5896
+1 4824
+2 2680
+6 2144

fn=(4838) QListData::insert(int)
220 2680
+1 2144
cfi=(65)
cfn=(1018)
calls=536 93 
* 25728
* 1608
cfi=(62)
cfn=(922)
calls=536 623 
* 2680
+1 1072
+1 1608
cfn=(3706)
calls=536 -21 
* 44488
* 536
+33 1072

fn=(1026)
58 44
+1 44
+3 55
cfi=(67)
cfn=(1028)
calls=11 +64 
* 803
* 33
+1 11
+1 22

fl=(71) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/kernel/qobject.h
fn=(1138) QObjectData::QObjectData()
85 7680
cfi=(64)
cfn=(1140) QList<QObject*>::QList()
calls=640 +56 
* 12160
* 1920

fn=(1320) QObject::d_func()
110 560074576
cfi=(62)
cfn=(1322)
calls=70009322 1014 
* 1120149152
* 140018644

fn=(4128) QObject::isWidgetType() const
137 4296
cfi=(81)
cfn=(1326)
calls=537 -27 
* 9666
* 3222

fn=(3772) QObject::d_func() const
110 4360
cfi=(62)
cfn=(1322)
calls=545 1014 
* 8720
* 1090

fn=(4152) QObject::parent() const
419 8
cfi=(81)
cfn=(1326)
calls=1 110 
* 18
* 3

fl=(142)
fn=(3072)
153 7
+1 11
cfn=(3074)
calls=1 -33 
* 976
+1 3

fn=(3074)
121 707
+2 303
+2 505
cfi=(114)
cfn=(2570)
calls=101 420 
* 707
* 606
+1 1596
+1 4879
+2 697
+2 1394
+1 3485
+4 4182
-10 697
+23 1313
cfi=(86)
cfn=(2852) QString::QString(QChar const*, int)
calls=101 1506 
* 81814
+1 303

fn=(5294)
73 7
+4 2
+1 5
cfi=(125)
cfn=(5296) ascii_isspace(unsigned char)
calls=1 409 
* 9
* 2
+2 4
+5 2
+1 1
cob=(5)
cfi=(5)
cfn=(3524)
calls=1 -86 
* 3
* 1
* 1
+1 1
+1 6
cfi=(204) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/../../3rdparty/freebsd/strtoull.c
cfn=(5298) qt_strtoull(char const*, char**, int)
calls=1 -45 
* 85
* 1
+1 2
+1 3
+2 3
cob=(5)
cfi=(5)
cfn=(3524)
calls=1 -92 
* 3
* 1
* 5
-1 2
+2 2
+1 2
+3 2

fl=(167) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qstandardpaths_unix.cpp
fn=(3662) QStandardPaths::standardLocations(QStandardPaths::StandardLocation)
311 6
+1 3
cfi=(120)
cfn=(2438)
calls=1 97 
* 29
+1 12
+3 3
cfn=(3664) xdgConfigDirs()
calls=1 -17 
* 4041
* 5
cfi=(120)
cfn=(3298) QStringList::operator=(QStringList&&)
calls=1 93 
* 214
* 3
cfi=(120)
cfn=(3036)
calls=1 93 
* 84
+1 1
+23 5
cfn=(3674) QStandardPaths::writableLocation(QStandardPaths::StandardLocation)
calls=1 66 
* 11121
+1 5
cfi=(64)
cfn=(3704) QList<QString>::prepend(QString const&)
calls=1 603 
* 2354
+1 1
-2 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
+2 1
+1 5

fn=(3664)
299 5
+1 3
cfi=(120)
cfn=(2438)
calls=1 97 
* 29
+2 4
cfi=(38)
cfn=(2264)
calls=1 3173 
* 1378
* 5
cfi=(145)
cfn=(3666) QFile::decodeName(QByteArray const&)
calls=1 84 
* 73
* 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
+1 3
cfi=(72)
cfn=(1456)
calls=1 874 
* 10
* 2
+1 5
cfi=(72)
cfn=(2478)
calls=1 528 
* 1494
* 5
cfi=(64)
cfn=(3290) QList<QString>::append(QString const&)
calls=1 569 
* 780
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
+3 2
-5 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
+5 1
+1 5

fn=(3674)
66 9
+1 12
+36 4
cfi=(38)
cfn=(2264)
calls=1 3173 
* 1366
* 5
cfi=(145)
cfn=(3666)
calls=1 -19 
* 73
* 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
+1 1
cfi=(166)
cfn=(3676) QStandardPaths::isTestModeEnabled()
calls=1 654 
* 5
* 2
+2 3
cfi=(72)
cfn=(1456)
calls=1 874 
* 10
* 2
+1 4
cfi=(72)
cfn=(2518)
calls=1 -20 
* 37
* 3
cfi=(109)
cfn=(3678) QDir::homePath()
calls=1 1945 
* 7169
* 5
cfi=(150)
cfn=(3682) QStringBuilder<QConcatenable<QString>::type, QConcatenable<QLatin1String>::type> operator+<QString, QLatin1String>(QString const&, QLatin1String const&)
calls=1 382 
* 49
* 7
cfi=(150)
cfn=(3690) QStringBuilder<QString, QLatin1String>::operator QString() const
calls=1 +18 
* 1742
* 5
cfi=(72)
cfn=(2234)
calls=1 227 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
+1 2
+2 5
cfi=(72)
cfn=(2228) QString::QString(QString&&)
calls=1 226 
* 26
-7 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
* 1
264 8

fl=(36) /usr/include/c++/6.1.1/atomic
fn=(808) std::atomic<BigArray*>::atomic()
326 7
cfi=(37) /usr/include/c++/6.1.1/bits/atomic_base.h
cfn=(810) std::__atomic_base<BigArray*>::__atomic_base()
calls=1 580 
* 6
* 3

fn=(840) std::atomic<unsigned int>::atomic()
629 14126
cfi=(37)
cfn=(842) std::__atomic_base<unsigned int>::__atomic_base()
calls=2018 249 
* 12108
* 6054

fn=(934) std::atomic<QMutexData*>::compare_exchange_strong(QMutexData*&, QMutexData*, std::memory_order)
471 420039767
+4 180017043
cfi=(37)
cfn=(936) std::__cmpexch_failure_order(std::memory_order)
calls=60005681 95 
* 3000284050
* 600056810
fi=(37)
746 240022724
cfn=(868) std::operator&(std::memory_order, std::__memory_order_modifier)
calls=60005681 81 
* 540051129
* 60005681
+1 240022724
cfn=(868)
calls=60005681 81 
* 540051129
* 60005681
+5 540051139
fe=(36)
476 120011362

fn=(1148) std::atomic<QtSharedPointer::ExternalRefCountData*>::atomic(QtSharedPointer::ExternalRefCountData*)
332 6400
cfi=(37)
cfn=(1150) std::__atomic_base<QtSharedPointer::ExternalRefCountData*>::__atomic_base(QtSharedPointer::ExternalRefCountData*)
calls=640 587 
* 6400
* 1920

fn=(1346) std::atomic<QThread*>::load(std::memory_order) const
415 21570
+1 17256
fi=(37)
709 17256
cfn=(868)
calls=4314 81 
* 38826
* 4314
+4 8628
fe=(36)
416 12942

fn=(3750) std::atomic<QAbstractEventDispatcher*>::load(std::memory_order) const
415 5395
+1 4316
fi=(37)
709 4316
cfn=(868)
calls=1079 81 
* 9711
* 1079
+4 2158
fe=(36)
416 3237

fn=(5192) std::atomic<void (*)(QtMsgType, QMessageLogContext const&, QString const&)>::load(std::memory_order) const
415 3170
+1 2536
fi=(37)
709 2536
cfn=(868)
calls=634 81 
* 5706
* 634
+4 1268
fe=(36)
416 1902

fn=(814) std::atomic<int>::atomic()
610 910
cfi=(37)
cfn=(816) std::__atomic_base<int>::__atomic_base()
calls=130 249 
* 780
* 390

fn=(960) std::atomic<void*>::load(std::memory_order) const
415 25
+1 20
fi=(37)
709 20
cfn=(868)
calls=5 81 
* 45
* 5
+4 10
fe=(36)
416 15

fn=(4252) std::atomic<int const*>::atomic(int const*)
332 100000010
cfi=(37)
cfn=(4254) std::__atomic_base<int const*>::__atomic_base(int const*)
calls=10000001 587 
* 100000010
* 30000003

fn=(1000) std::atomic<int>::atomic(int)
616 100000830
cfi=(37)
cfn=(1002) std::__atomic_base<int>::__atomic_base(int)
calls=10000083 256 
* 100000830
* 30000249

fn=(4164) std::atomic<QAbstractEventDispatcher*>::store(QAbstractEventDispatcher*, std::memory_order)
405 6
+2 6
fi=(37)
685 4
cfn=(868)
calls=1 81 
* 9
* 1
+6 4
fe=(36)
407 3

fn=(4366) std::atomic<QFreeListElement<void>*>::load(std::memory_order) const
415 5
+1 4
fi=(37)
709 4
cfn=(868)
calls=1 81 
* 9
* 1
+4 2
fe=(36)
416 3

fn=(1502) std::atomic<QTextCodec*>::atomic(QTextCodec*)
332 10
cfi=(37)
cfn=(1504) std::__atomic_base<QTextCodec*>::__atomic_base(QTextCodec*)
calls=1 587 
* 10
* 3

fn=(3572) std::atomic<QtSharedPointer::ExternalRefCountData*>::load(std::memory_order) const
415 3175
+1 2540
fi=(37)
709 2540
cfn=(868)
calls=635 81 
* 5715
* 635
+4 1270
fe=(36)
416 1905

fn=(974) std::atomic<void*>::store(void*, std::memory_order)
405 48
+2 48
fi=(37)
685 32
cfn=(868)
calls=8 81 
* 72
* 8
+6 32
fe=(36)
407 24

fn=(1074) std::atomic<QMutexData*>::load(std::memory_order) const
415 20
+1 16
fi=(37)
709 16
cfn=(868)
calls=4 81 
* 36
* 4
+4 8
fe=(36)
416 12

fn=(1354) std::atomic<QThread*>::store(QThread*, std::memory_order)
405 18
+2 18
fi=(37)
685 12
cfn=(868)
calls=3 81 
* 27
* 3
+6 12
fe=(36)
407 9

fn=(4388) std::atomic<QFreeListElement<void>*>::compare_exchange_strong(QFreeListElement<void>*&, QFreeListElement<void>*, std::memory_order)
471 7
+4 3
cfi=(37)
cfn=(936)
calls=1 95 
* 50
* 10
fi=(37)
746 4
cfn=(868)
calls=1 81 
* 9
* 1
+1 4
cfn=(868)
calls=1 81 
* 9
* 1
+5 9
fe=(36)
476 2

fn=(5174) std::atomic<bool>::load(std::memory_order) const
101 3170
+1 2536
fi=(37)
392 2536
cfn=(868)
calls=634 81 
* 5706
* 634
+4 2536
fe=(36)
102 1902

fn=(5184) std::atomic<void (*)(QtMsgType, char const*)>::load(std::memory_order) const
415 3170
+1 2536
fi=(37)
709 2536
cfn=(868)
calls=634 81 
* 5706
* 634
+4 1268
fe=(36)
416 1902

fn=(898) std::atomic<void*>::atomic(void*)
332 20
cfi=(37)
cfn=(900) std::__atomic_base<void*>::__atomic_base(void*)
calls=2 587 
* 20
* 6

fn=(906) std::atomic<QMutexData*>::store(QMutexData*, std::memory_order)
405 54
+2 54
fi=(37)
685 36
cfn=(868)
calls=9 81 
* 81
* 9
+6 36
fe=(36)
407 27

fn=(5162) std::atomic<bool>::store(bool, std::memory_order)
93 28
+1 28
fi=(37)
369 16
cfn=(868)
calls=4 81 
* 36
* 4
+5 16
fe=(36)
94 12

fn=(750) std::atomic<QMutexData*>::atomic()
326 1050
cfi=(37)
cfn=(752) std::__atomic_base<QMutexData*>::__atomic_base()
calls=150 580 
* 900
* 450

fn=(1214) std::atomic<QAbstractEventDispatcher*>::atomic(QAbstractEventDispatcher*)
332 20
cfi=(37)
cfn=(1216) std::__atomic_base<QAbstractEventDispatcher*>::__atomic_base(QAbstractEventDispatcher*)
calls=2 587 
* 20
* 6

fn=(2200) std::atomic<QTextCodec*>::store(QTextCodec*, std::memory_order)
405 6
+2 6
fi=(37)
685 4
cfn=(868)
calls=1 81 
* 9
* 1
+6 4
fe=(36)
407 3

fn=(1206) std::atomic<QThread*>::atomic(QThread*)
332 30
cfi=(37)
cfn=(1208) std::__atomic_base<QThread*>::__atomic_base(QThread*)
calls=3 587 
* 30
* 9

fn=(1512) std::atomic<QTextCodec*>::load(std::memory_order) const
415 6395
+1 5116
fi=(37)
709 5116
cfn=(868)
calls=1279 81 
* 11511
* 1279
+4 2558
fe=(36)
416 3837

fl=(51)
fn=(4088) QChildEvent::QChildEvent(QEvent::Type, QObject*)
546 6
+1 5
cfn=(4090) QEvent::QEvent(QEvent::Type)
calls=1 280 
* 29
* 7
+1 3

fn=(4840) QTimerEvent::QTimerEvent(int)
499 2680
+1 2144
cfn=(4090)
calls=536 280 
* 15544
* 3752
+1 1608

fn=(4090)
280 2148
+1 11814
+1 1611

fn=(836) (anonymous namespace)::QBasicAtomicBitField<64536ul>::QBasicAtomicBitField()
391 9
cfi=(35)
cfn=(838) QBasicAtomicInteger<unsigned int>::QBasicAtomicInteger()
calls=1 233 
* 26
* 8074
cfi=(35)
cfn=(838)
calls=2017 233 
* 52442
* 6057

fn=(4148) QChildEvent::~QChildEvent()
553 11
cfn=(4150) QEvent::~QEvent()
calls=1 325 
* 29
+2 3

fn=(4150)
325 4288
+2 4288
+2 2680
cfi=(62)
cfn=(922)
calls=536 623 
* 2680
+1 1608

fn=(832)
635 5
cfn=(834) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 66622
* 2

fn=(834)
635 9
443 2
cfn=(836)
calls=1 -52 
* 66608
635 3

fn=(5358) QTimerEvent::~QTimerEvent()
506 5885
cfn=(4150)
calls=535 325 
* 15515
+2 1605

fl=(105)
fn=(2294)
78 20
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 7
cfn=(2296) (anonymous namespace)::Q_QGS_qt_library_settings::innerFunction()::Holder::Holder()
calls=1 * 
* 556924
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 -78 
* 66
* 1
* 12

fn=(2298) (anonymous namespace)::Q_QGS_qt_library_settings::innerFunction()::HolderBase::HolderBase()
78 6

fn=(2286)
409 6
+21 3
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
+16 1
cfn=(2288) QLibraryInfoPrivate::configuration()
calls=1 97 
* 557159
* 4
+3 1
+1 2
+7 2
+1 11
+11 5
+1 6
cfi=(72)
cfn=(1462) QString::fromLocal8Bit(char const*, int)
calls=1 +67 
* 1508
* 5
cfi=(72)
cfn=(2234)
calls=1 227 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
* 1
+61 3
cfi=(72)
cfn=(1456)
calls=1 874 
* 10
* 6
cfi=(109)
cfn=(3312) QDir::isRelativePath(QString const&)
calls=1 2212 
* 4312
* 6
+1 3
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
+15 2
+25 4
cfn=(2287) QLibraryInfo::location(QLibraryInfo::LibraryLocation)'2
calls=1 409 
* 6722
* 5
cfi=(72)
cfn=(2234)
calls=1 227 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
+3 4
cfi=(114)
cfn=(2350)
calls=1 47 
* 11
* 5
cfi=(150)
cfn=(3372) QStringBuilder<QConcatenable<QString>::type, QConcatenable<QLatin1Char>::type> operator+<QString, QLatin1Char>(QString const&, QLatin1Char const&)
calls=1 382 
* 49
* 7
cfi=(150)
cfn=(3380) QStringBuilder<QConcatenable<QStringBuilder<QString, QLatin1Char> >::type, QConcatenable<QString>::type> operator+<QStringBuilder<QString, QLatin1Char>, QString>(QStringBuilder<QString, QLatin1Char> const&, QString const&)
calls=1 382 
* 49
* 7
cfi=(150)
cfn=(3388) QStringBuilder<QStringBuilder<QString, QLatin1Char>, QString>::operator QString() const
calls=1 125 
* 1364
* 5
cfi=(109)
cfn=(2858)
calls=1 2175 
* 4301
* 5
cfi=(72)
cfn=(2234)
calls=1 227 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
-43 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
+45 2
+1 5

fn=(2287)
409 6
+21 3
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
+16 1
cfn=(2288)
calls=1 97 
* 100
* 4
+3 1
+1 2
+6 1
-5 2
+18 5
+1 6
cfi=(72)
cfn=(1462)
calls=1 +67 
* 2250
* 5
cfi=(72)
cfn=(2234)
calls=1 227 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
* 1
+61 3
cfi=(72)
cfn=(1456)
calls=1 874 
* 10
* 6
cfi=(109)
cfn=(3312)
calls=1 2212 
* 4147
* 5
+46 1
+1 5

fn=(2288)
97 6
+2 4
cfi=(56)
cfn=(2290)
calls=2 +30 
* 557203
* 2
+1 4
+2 14
+3 6
cfi=(81)
cfn=(3366)
calls=2 +28 
* 14
* 2
+4 4

fn=(2296)
78 8
cfn=(2298)
calls=1 * 
* 6
* 3
cfn=(2300) QLibrarySettings::QLibrarySettings()
calls=1 +36 
* 556855
* 3
cfi=(35)
cfn=(910)
calls=1 +39 
* 44
* 5

fn=(2300)
114 9
cfi=(81)
cfn=(2302)
calls=1 -20 
* 10
+2 3
cfn=(2304) QLibrarySettings::load()
calls=1 +4 
* 556828
+1 5

fn=(2306) QLibraryInfoPrivate::findConfiguration()
159 5
+1 5
cfn=(2308) QLibraryInfoPrivate::findConfiguration()::{lambda()#1}::operator()() const
calls=1 * 
* 92
+1 3
cfi=(106)
cfn=(2312)
calls=1 430 
* 482933
* 2
+22 1
cfi=(84) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/kernel/qcoreapplication.h
cfn=(3042) QCoreApplication::instance()
calls=1 -73 
* 6
* 4
+1 3
cfi=(50)
cfn=(3044) QCoreApplication::applicationDirPath()
calls=1 2089 
* 47978
* 5
cfi=(109)
cfn=(3230)
calls=1 534 
* 6920
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
+1 4
cfi=(72)
cfn=(2518)
calls=1 -98 
* 37
* 6
cfi=(72)
cfn=(3304)
calls=1 863 
* 1460
* 6
cfi=(109)
cfn=(3306) QDir::filePath(QString const&) const
calls=1 686 
* 8311
* 5
cfi=(72)
cfn=(2234)
calls=1 +42 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
+1 3
cfi=(106)
cfn=(2312)
calls=1 430 
* 6719
* 2
+1 4
cfi=(109)
cfn=(3350)
calls=1 577 
* 1352
* 2
-3 1
+6 1
-30 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 328
* 2
+31 5

fn=(2308)
160 7
cfi=(72)
cfn=(2310) QStaticStringData<16>::data_ptr() const
calls=1 +38 
* 65
* 6
cfi=(72)
cfn=(2284)
calls=1 782 
* 10
* 4

fn=(2304)
120 9
+2 1
cfn=(2306)
calls=1 +37 
* 556739
* 5
cfi=(81)
cfn=(3364)
calls=1 +21 
* 12
+2 3
cfi=(81)
cfn=(3366)
calls=1 +9 
* 7
* 3
cfi=(84)
cfn=(3042)
calls=1 -14 
* 6
* 5
+5 3
cfi=(81)
cfn=(3368)
calls=1 -2 
* 22
* 4
+27 9

fl=(114)
fn=(2356)
567 8440

fn=(2604)
408 162
cfi=(122)
cfn=(2606)
calls=18 1481 
* 1494
* 90
cfn=(2598) QChar::QChar(unsigned int)
calls=18 79 
* 198
* 54

fn=(5002) QChar::fromLatin1(char)
427 8074
cfn=(2348)
calls=734 76 
* 8074
* 2202

fn=(2348)
76 20240

fn=(2352)
82 11960
cfn=(2354) QLatin1Char::unicode() const
calls=1495 -33 
* 11960
* 8970

fn=(2598)
79 396

fn=(3062) QChar::digitValue() const
406 36
cfi=(122)
cfn=(3064)
calls=4 1071 
* 176
* 8

fn=(3332) QChar::QChar(int)
80 11

fn=(3542) QChar::isSpace() const
432 18
cfn=(3544) QChar::isSpace(unsigned int)
calls=2 +86 
* 26
* 4

fn=(2586)
407 162
cfi=(122)
cfn=(2588)
calls=18 1461 
* 1494
* 90
cfn=(2598)
calls=18 79 
* 198
* 54

fn=(2862)
570 130
cfn=(2356)
calls=13 -3 
* 130
* 39

fn=(3544)
518 8
+4 4
-1 4
+1 6
+1 4

fn=(2354)
49 11960

fn=(2578)
429 126

fn=(2868)
75 6288

fn=(2350)
47 16445

fn=(2570)
420 3031

fn=(2556)
421 5418

fl=(194) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/io/qtextstream_p.h
fn=(4920) QDeviceClosedNotifier::QDeviceClosedNotifier()
60 2536
+1 2536
cfi=(53)
cfn=(4208) QObject::QObject(QObject*)
calls=634 814 
* 330470
* 4438

fn=(5354) QDeviceClosedNotifier::~QDeviceClosedNotifier()
56 6974
cfi=(53)
cfn=(3566) QObject::~QObject()
calls=634 893 
* 343628
* 1902

fn=(4988) QTextStreamPrivate::putString(QString const&, bool)
172 8242
cfi=(72)
cfn=(2532)
calls=634 866 
* 5072
* 2536
cfi=(72)
cfn=(2216)
calls=634 882 
* 30432
* 3804
cfi=(193)
cfn=(4990) QTextStreamPrivate::putString(QChar const*, int, bool)
calls=634 952 
* 128411977
* 3804

fn=(4926) QTextStreamPrivate::Params::Params()
84 5072
cfi=(114)
cfn=(2868)
calls=634 -9 
* 5072
* 3170
cfi=(95)
cfn=(4928)
calls=634 +28 
* 5706
* 1902

fl=(65)
fn=(1038)
99 80
cfi=(35)
cfn=(910)
calls=10 +18 
* 440
* 30

fn=(5100) QtPrivate::RefCount::RefCount()
45 7
cfi=(35)
cfn=(812)
calls=1 233 
* 26
* 3

fn=(1018)
93 80033776
+2 60025332
cfi=(35)
cfn=(864)
calls=20008444 +21 
* 700295540
* 20008444
+1 60029248
+1 40016888

fn=(2162)
87 8016
+3 6012
cfi=(35)
cfn=(864)
calls=2004 +26 
* 70140
* 4008
+1 4008

fn=(2278) QtPrivate::RefCount::ref()
48 3344
+1 2508
cfi=(35)
cfn=(864)
calls=836 +67 
* 29260
* 836
+2 1672
+3 1672
+1 2304
cfi=(35)
cfn=(1010)
calls=768 +72 
* 22272
+1 836
+1 1672

fn=(1044) QtPrivate::RefCount::deref()
59 23620
+1 17715
cfi=(35)
cfn=(864)
calls=5905 +56 
* 206675
* 5905
+2 11810
+3 11810
+1 7352
+1 6687
cfi=(35)
cfn=(1364)
calls=2229 +61 
* 71328
+1 11810

fn=(4284) QtPrivate::RefCount::isSharable() const
80 12
+3 9
cfi=(35)
cfn=(864)
calls=3 +33 
* 105
* 6
+1 6

fl=(132) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/kernel/qmetatypeswitcher_p.h
fn=(2700) bool QMetaTypeSwitcher::switcher<bool, QVariantIsNull<(anonymous namespace)::CoreTypesFilter> >(QVariantIsNull<(anonymous namespace)::CoreTypesFilter>&, int, void const*)
65 48
+2 80
+1 25
cfi=(131) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/kernel/qvariant_p.h
cfn=(2730) bool QVariantIsNull<(anonymous namespace)::CoreTypesFilter>::delegate<QChar>(QChar const*)
calls=5 330 
* 240
* 5
+3 15
cfi=(131)
cfn=(2702) QVariantIsNull<(anonymous namespace)::CoreTypesFilter>::delegate(QMetaTypeSwitcher::UnknownType const*)
calls=3 336 
* 36
* 3
+6 16

fl=(129)
fn=(2664)
1373 72
+2 324
+2 54

fn=(2696) (anonymous namespace)::isNull(QVariant::Private const*)
127 32
+1 40
cfi=(131)
cfn=(2698) QVariantIsNull<(anonymous namespace)::CoreTypesFilter>::QVariantIsNull(QVariant::Private const*)
calls=8 326 
* 80
+1 72
cfi=(132)
cfn=(2700)
calls=8 -64 
* 468
+1 16

fn=(2690)
3607 32
+1 48
cfn=(2692) (anonymous namespace)::HandlersManager::operator[](unsigned int) const
calls=8 91 
* 184
* 32
cfn=(2696)
calls=8 127 
* 708
+1 16

fn=(2742) (anonymous namespace)::convert(QVariant::Private const*, int, void*, bool*)
366 50
+1 40
cfi=(62)
cfn=(922)
calls=5 623 
* 25
+1 20
cfi=(62)
cfn=(922)
calls=5 623 
* 25
+2 35
+9 10
+1 10
+2 55
+31 10
+1 65
+2 20
cfi=(131)
cfn=(2736) QChar const* v_cast<QChar>(QVariant::Private const*, QChar*)
calls=5 85 
* 35
* 25
cfi=(86)
cfn=(2744) QString::operator=(QChar)
calls=5 1873 
* 5050
+1 5
+71 5
970 15
+1 30

fn=(2738)
2247 25
+1 30
cfn=(2740) QString qVariantToHelper<QString>(QVariant::Private const&, (anonymous namespace)::HandlersManager const&)
calls=5 -44 
* 6450
+1 15

fn=(2740)
2204 35
+2 5
+1 25
+3 15
cfi=(72)
cfn=(1156)
calls=5 1064 
* 105
+1 25
+6 40
cfn=(2692)
calls=5 91 
* 115
* 30
cfn=(2742)
calls=5 366 
* 5530
+1 25
cfi=(72)
cfn=(2228)
calls=5 226 
* 130
-8 15
cfi=(72)
cfn=(2230)
calls=5 1065 
* 325
* 5
+9 25

fn=(2692)
91 65
+2 39
cfi=(130)
cfn=(2694)
calls=13 -37 
* 117
* 52
+1 26

fn=(2720) QVariant::QVariant(QChar)
1728 25
+1 20
cfi=(117)
cfn=(2722) QVariant::Private::Private(unsigned int)
calls=5 370 
* 125
+1 25
cfi=(131)
cfn=(2724) void v_construct<QChar>(QVariant::Private*, QChar const&)
calls=5 143 
* 220
* 15

fl=(68) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/kernel/qmath.h
fn=(1032) qNextPowerOfTwo(unsigned int)
241 3894
+1 2596
+2 9086
+1 2596

fn=(1030) qNextPowerOfTwo(int)
279 5192
+1 3894
cfn=(1032)
calls=1298 -39 
* 18172
+1 2596

fl=(112) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfilesystementry_p.h
fn=(3260) QFileSystemEntry::operator=(QFileSystemEntry&&)
57 25
fi=(138)
* 25
cfi=(72)
cfn=(2234)
calls=5 227 
* 345
* 35
cfi=(98)
cfn=(2454) QByteArray::operator=(QByteArray&&)
calls=5 186 
* 345
* 75
fe=(112)

fn=(2332) QFileSystemEntry::QFileSystemEntry(QFileSystemEntry const&)
57 140
cfi=(72)
cfn=(2320)
calls=14 889 
* 1402
* 98
cfi=(98)
cfn=(2276)
calls=14 494 
* 924
* 210

fn=(2928) QFileSystemEntry::operator=(QFileSystemEntry const&)
57 140
cfi=(86)
cfn=(2534)
calls=14 1791 
* 2483
* 98
cfi=(67)
cfn=(2462) QByteArray::operator=(QByteArray const&)
calls=14 1045 
* 1736
* 210

fl=(155) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qbytearraylist.h
fn=(3440) QListSpecialMethods<QByteArray>::QListSpecialMethods()
55 12

fn=(3616) QListSpecialMethods<QByteArray>::~QListSpecialMethods()
60 6

fl=(170) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qabstracteventdispatcher_p.h
fn=(3764) QAbstractEventDispatcherPrivate::QAbstractEventDispatcherPrivate()
59 4
+1 4
cfi=(53)
cfn=(1136) QObjectPrivate::QObjectPrivate(int)
calls=1 198 
* 159
* 8
cfi=(64)
cfn=(3766) QList<QAbstractNativeEventFilter*>::QList()
calls=1 +81 
* 19
* 3

fl=(37)
fn=(1014) std::__atomic_base<int>::operator++()
295 30008436
+1 60016872

fn=(4254)
587 100000010

fn=(810)
580 6

fn=(842)
249 12108

fn=(938) std::__cmpexch_failure_order2(std::memory_order)
88 180017052
+1 120011368
+1 240022736
+1 120011368

fn=(1504)
587 10

fn=(868)
81 1040236060
+1 780177045
+1 520118030

fn=(936)
95 300028420
+1 240022736
cfn=(868)
calls=60005684 -15 
* 540051156
* 120011368
cfn=(938)
calls=60005684 -8 
* 660062524
* 60005684
+1 240022736
cfn=(868)
calls=60005684 -16 
* 540051156
* 60005684
+1 240022736

fn=(752)
580 900

fn=(900)
587 20

fn=(1216)
587 20

fn=(1002)
256 100000830

fn=(1150)
587 6400

fn=(1208)
587 30

fn=(1368) std::__atomic_base<int>::operator--()
303 90012792
+1 270038376

fn=(816)
249 780

fl=(174) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/kernel/qcoreevent.h
fn=(4846) QTimerEvent::timerId() const
332 3752

fn=(4140) QEvent::type() const
291 4304

fl=(35)
fn=(968) QBasicAtomicPointer<QMutexData>::testAndSetAcquire(QMutexData*, QMutexData*)
266 24
+1 24
cfi=(57) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/arch/qatomic_cxx11.h
cfn=(932) bool QAtomicOps<QMutexData*>::testAndSetAcquire<QMutexData*>(std::atomic<QMutexData*>&, QMutexData*, QMutexData*, QMutexData**)
calls=4 156 
* 512
* 8

fn=(1280) QBasicAtomicInteger<int>::loadAcquire() const
119 18872
cfi=(57)
cfn=(1282) int QAtomicOps<int>::loadAcquire<int>(std::atomic<int> const&)
calls=2696 -13 
* 70096
* 5392

fn=(1376) QBasicAtomicPointer<QThread>::operator=(QThread*)
255 10
cfn=(1350) QBasicAtomicPointer<QThread>::storeRelease(QThread*)
calls=1 +4 
* 60
* 3

fn=(4250) QBasicAtomicPointer<int const>::QBasicAtomicPointer(int const*)
330 100000010
cfi=(36)
cfn=(4252)
calls=10000001 +2 
* 230000023
* 30000003

fn=(806)
329 7
cfi=(36)
cfn=(808)
calls=1 -3 
* 16
* 3

fn=(838)
233 14126
cfi=(36)
cfn=(840)
calls=2018 629 
* 32288
* 6054

fn=(998) QBasicAtomicInteger<int>::QBasicAtomicInteger(int)
234 100000830
cfi=(36)
cfn=(1000)
calls=10000083 616 
* 230001909
* 30000249

fn=(1010)
127 70019684
cfi=(57)
cfn=(1012) bool QAtomicOps<int>::ref<int>(std::atomic<int>&)
calls=10002812 +5 
* 200056240
* 20005624

fn=(1146) QBasicAtomicPointer<QtSharedPointer::ExternalRefCountData>::QBasicAtomicPointer(QtSharedPointer::ExternalRefCountData*)
330 6400
cfi=(36)
cfn=(1148)
calls=640 +2 
* 14720
* 1920

fn=(1370) QBasicAtomicPointer<QThread>::operator QThread*() const
254 15141
cfn=(1342) QBasicAtomicPointer<QThread>::loadAcquire() const
calls=2163 +4 
* 101661
* 4326

fn=(4384) QBasicAtomicPointer<QFreeListElement<void> >::testAndSetRelease(QFreeListElement<void>*, QFreeListElement<void>*)
268 6
+1 6
cfi=(57)
cfn=(4386) bool QAtomicOps<QFreeListElement<void>*>::testAndSetRelease<QFreeListElement<void>*>(std::atomic<QFreeListElement<void>*>&, QFreeListElement<void>*, QFreeListElement<void>*, QFreeListElement<void>**)
calls=1 165 
* 128
* 2

fn=(970) QBasicAtomicPointer<void>::store(void*)
253 80
cfi=(57)
cfn=(972) void QAtomicOps<void*>::store<void*>(std::atomic<void*>&, void*)
calls=8 118 
* 376
* 24

fn=(1062) QBasicAtomicPointer<QMutexData>::testAndSetRelease(QMutexData*, QMutexData*, QMutexData*&)
277 210019852
+1 180017016
cfi=(57)
cfn=(1064) bool QAtomicOps<QMutexData*>::testAndSetRelease<QMutexData*>(std::atomic<QMutexData*>&, QMutexData*, QMutexData*, QMutexData**)
calls=30002836 165 
* 3930371521
* 60005672

fn=(4392)
133 12
+1 12
cfi=(57)
cfn=(4394) bool QAtomicOps<int>::testAndSetRelaxed<int>(std::atomic<int>&, int, int, int*)
calls=2 +13 
* 236
* 4

fn=(5188) QBasicAtomicPointer<void (QtMsgType, QMessageLogContext const&, QString const&)>::load() const
252 4438
cfi=(57)
cfn=(5190) void (*QAtomicOps<void (*)(QtMsgType, QMessageLogContext const&, QString const&)>::load<void (*)(QtMsgType, QMessageLogContext const&, QString const&)>(std::atomic<void (*)(QtMsgType, QMessageLogContext const&, QString const&)> const&))(QtMsgType, QMessageLogContext const&, QString const&)
calls=634 94 
* 24092
* 1268

fn=(956) QBasicAtomicPointer<void>::load() const
252 35
cfi=(57)
cfn=(958) void* QAtomicOps<void*>::load<void*>(std::atomic<void*> const&)
calls=5 94 
* 190
* 10

fn=(1350)
259 30
cfi=(57)
cfn=(1352) void QAtomicOps<QThread*>::storeRelease<QThread*>(std::atomic<QThread*>&, QThread*)
calls=3 124 
* 141
* 9

fn=(4362) QBasicAtomicPointer<QFreeListElement<void> >::loadAcquire() const
258 7
cfi=(57)
cfn=(4364) QFreeListElement<void>* QAtomicOps<QFreeListElement<void>*>::loadAcquire<QFreeListElement<void>*>(std::atomic<QFreeListElement<void>*> const&)
calls=1 106 
* 38
* 2

fn=(896) QBasicAtomicPointer<void>::QBasicAtomicPointer(void*)
330 20
cfi=(36)
cfn=(898)
calls=2 +2 
* 46
* 6

fn=(902) QBasicAtomicPointer<QMutexData>::store(QMutexData*)
253 90
cfi=(57)
cfn=(904) void QAtomicOps<QMutexData*>::store<QMutexData*>(std::atomic<QMutexData*>&, QMutexData*)
calls=9 118 
* 423
* 27

fn=(4160) QBasicAtomicPointer<QAbstractEventDispatcher>::storeRelease(QAbstractEventDispatcher*)
259 10
cfi=(57)
cfn=(4162) void QAtomicOps<QAbstractEventDispatcher*>::storeRelease<QAbstractEventDispatcher*>(std::atomic<QAbstractEventDispatcher*>&, QAbstractEventDispatcher*)
calls=1 124 
* 47
* 3

fn=(864)
116 140154938
cfi=(57)
cfn=(866) int QAtomicOps<int>::load<int>(std::atomic<int> const&)
calls=20022134 -22 
* 520575484
* 40044268

fn=(910)
117 22020
cfi=(57)
cfn=(912) void QAtomicOps<int>::store<int>(std::atomic<int>&, int)
calls=2202 +1 
* 68262
* 6606

fn=(1290) QBasicAtomicInteger<int>::storeRelease(int)
120 20
cfi=(57)
cfn=(1292) void QAtomicOps<int>::storeRelease<int>(std::atomic<int>&, int)
calls=2 +4 
* 62
* 6

fn=(1364)
128 210029848
cfi=(57)
cfn=(1366) bool QAtomicOps<int>::deref<int>(std::atomic<int>&)
calls=30004264 +10 
* 690098072
* 60008528

fn=(2196)
259 10
cfi=(57)
cfn=(2198) void QAtomicOps<QTextCodec*>::storeRelease<QTextCodec*>(std::atomic<QTextCodec*>&, QTextCodec*)
calls=1 124 
* 47
* 3

fn=(3746) QBasicAtomicPointer<QAbstractEventDispatcher>::load() const
252 7546
cfi=(57)
cfn=(3748) QAbstractEventDispatcher* QAtomicOps<QAbstractEventDispatcher*>::load<QAbstractEventDispatcher*>(std::atomic<QAbstractEventDispatcher*> const&)
calls=1078 94 
* 40964
* 2156

fn=(4156) QBasicAtomicPointer<QAbstractEventDispatcher>::loadAcquire() const
258 7
cfi=(57)
cfn=(4158) QAbstractEventDispatcher* QAtomicOps<QAbstractEventDispatcher*>::loadAcquire<QAbstractEventDispatcher*>(std::atomic<QAbstractEventDispatcher*> const&)
calls=1 106 
* 38
* 2

fn=(5158)
117 44
cfi=(57)
cfn=(5160) void QAtomicOps<bool>::store<bool>(std::atomic<bool>&, bool)
calls=4 +1 
* 200
* 12

fn=(748) QBasicAtomicPointer<QMutexData>::QBasicAtomicPointer()
329 1050
cfi=(36)
cfn=(750)
calls=150 -3 
* 2400
* 450

fn=(812)
233 910
cfi=(36)
cfn=(814)
calls=130 610 
* 2080
* 390

fn=(1204) QBasicAtomicPointer<QThread>::QBasicAtomicPointer(QThread*)
330 30
cfi=(36)
cfn=(1206)
calls=3 +2 
* 69
* 9

fn=(1212) QBasicAtomicPointer<QAbstractEventDispatcher>::QBasicAtomicPointer(QAbstractEventDispatcher*)
330 20
cfi=(36)
cfn=(1214)
calls=2 +2 
* 46
* 6

fn=(1372) QBasicAtomicPointer<QThread>::load() const
252 15043
cfi=(57)
cfn=(1374) QThread* QAtomicOps<QThread*>::load<QThread*>(std::atomic<QThread*> const&)
calls=2149 94 
* 81662
* 4298

fn=(1508)
258 8953
cfi=(57)
cfn=(1510) QTextCodec* QAtomicOps<QTextCodec*>::loadAcquire<QTextCodec*>(std::atomic<QTextCodec*> const&)
calls=1279 106 
* 48602
* 2558

fn=(3568) QBasicAtomicPointer<QtSharedPointer::ExternalRefCountData>::load() const
252 4445
cfi=(57)
cfn=(3570) QtSharedPointer::ExternalRefCountData* QAtomicOps<QtSharedPointer::ExternalRefCountData*>::load<QtSharedPointer::ExternalRefCountData*>(std::atomic<QtSharedPointer::ExternalRefCountData*> const&)
calls=635 94 
* 24130
* 1270

fn=(5170)
116 4438
cfi=(57)
cfn=(5172) bool QAtomicOps<bool>::load<bool>(std::atomic<bool> const&)
calls=634 -22 
* 25360
* 1268

fn=(5180) QBasicAtomicPointer<void (QtMsgType, char const*)>::load() const
252 4438
cfi=(57)
cfn=(5182) void (*QAtomicOps<void (*)(QtMsgType, char const*)>::load<void (*)(QtMsgType, char const*)>(std::atomic<void (*)(QtMsgType, char const*)> const&))(QtMsgType, char const*)
calls=634 94 
* 24092
* 1268

fn=(930) QBasicAtomicPointer<QMutexData>::testAndSetAcquire(QMutexData*, QMutexData*, QMutexData*&)
275 210019859
+1 180017022
cfi=(57)
cfn=(932)
calls=30002837 156 
* 3930371652
* 60005674

fn=(1070) QBasicAtomicPointer<QMutexData>::load() const
252 28
cfi=(57)
cfn=(1072) QMutexData* QAtomicOps<QMutexData*>::load<QMutexData*>(std::atomic<QMutexData*> const&)
calls=4 94 
* 152
* 8

fn=(1500) QBasicAtomicPointer<QTextCodec>::QBasicAtomicPointer(QTextCodec*)
330 10
cfi=(36)
cfn=(1502)
calls=1 +2 
* 23
* 3

fn=(1080) QBasicAtomicPointer<QMutexData>::testAndSetRelease(QMutexData*, QMutexData*)
268 24
+1 24
cfi=(57)
cfn=(1064)
calls=4 165 
* 512
* 8

fn=(1342)
258 15155
cfi=(57)
cfn=(1344) QThread* QAtomicOps<QThread*>::loadAcquire<QThread*>(std::atomic<QThread*> const&)
calls=2165 106 
* 82270
* 4330

fl=(172)
fn=(4354) (anonymous namespace)::Q_QGS_timerIdFreeList::innerFunction()::HolderBase::HolderBase()
83 6

fn=(4070) QAbstractEventDispatcher::QAbstractEventDispatcher(QAbstractEventDispatcherPrivate&, QObject*)
145 6
+2 6
cfi=(53)
cfn=(1316) QObject::QObject(QObjectPrivate&, QObject*)
calls=1 839 
* 2981
* 7

fn=(4350)
83 9
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 6
cfn=(4352) (anonymous namespace)::Q_QGS_timerIdFreeList::innerFunction()::Holder::Holder()
calls=1 * 
* 153
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 -83 
* 66
* 1
* 3

fn=(4342) QAbstractEventDispatcher::registerTimer(int, Qt::TimerType, QObject*)
251 7
+1 1
cfn=(4344) QAbstractEventDispatcherPrivate::allocateTimerId()
calls=1 86 
* 11883
* 1
+1 10
cfi=(169) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp
cfn=(4398) QEventDispatcherGlib::registerTimer(int, int, Qt::TimerType, QObject*)
calls=1 506 
* 5044
+1 1
+1 2

fn=(4344)
86 2
+1 2
cfi=(56)
cfn=(4346)
calls=1 +42 
* 354
* 2
cfi=(183) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/tools/qfreelist_p.h
cfn=(4358) QFreeList<void, QtTimerIdFreeListConstants>::next()
calls=1 228 
* 11521
+1 2

fn=(4352)
83 7
cfn=(4354)
calls=1 * 
* 6
* 3
cfi=(183)
cfn=(4356) QFreeList<void, QtTimerIdFreeListConstants>::QFreeList()
calls=1 202 
* 87
* 3
cfi=(35)
cfn=(910)
calls=1 +34 
* 44
* 3

fn=(4196) QAbstractEventDispatcher::startingUp()
328 6

fl=(32)
fn=(740)
195 5
cfn=(742) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 50
* 2

fn=(742)
195 9
fi=(33) /home/tsenyk/qt5/qt5/qtbase/src/corelib/animation/qvariantanimation.cpp
397 2
cfi=(34)
cfn=(746)
calls=1 54 
* 36
fe=(32)
195 3

fl=(151)
fn=(3428)
47 5
+3 3
cfi=(152)
cfn=(3430) QIODevicePrivate::QIODevicePrivate()
calls=1 +94 
* 242
* 10
cfi=(154) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/tools/qringbuffer_p.h
cfn=(3436) QRingBuffer::QRingBuffer(int)
calls=1 +6 
* 880
* 7
cfi=(95)
cfn=(3450)
calls=1 +62 
* 9
* 4
+2 5

fn=(3452)
211 6
+1 6
cfi=(152)
cfn=(3454) QIODevice::QIODevice(QIODevicePrivate&, QObject*)
calls=1 403 
* 257
* 4
+2 3

fn=(3556)
74 6
+1 3
+1 6
cfi=(86)
cfn=(2534)
calls=1 1791 
* 156
+1 3

fn=(3560)
220 8
+2 3
cfn=(3562) QFileDevice::close()
calls=1 +96 
* 93
-2 3
cfi=(152)
cfn=(3564) QIODevice::~QIODevice()
calls=1 416 
* 3095
+3 3

fn=(3594)
54 7
+2 13
cfi=(158)
cfn=(3596) QFSFileEngine::~QFSFileEngine()
calls=1 169 
* 964
+1 2
-3 4
cfi=(154)
cfn=(3608) QRingBuffer::~QRingBuffer()
calls=1 -1 
* 397
* 3
cfi=(152)
cfn=(3618) QIODevicePrivate::~QIODevicePrivate()
calls=1 158 
* 501
+4 3

fn=(3474)
589 4
+1 3
cfi=(157) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfiledevice.h
cfn=(3476) QFileDevice::d_func()
calls=1 49 
* 26
* 1
+1 4
cfn=(3478) QFileDevicePrivate::setError(QFileDevice::FileError)
calls=1 68 
* 52
+1 3

fn=(3478)
68 5
+1 3
+1 4
cfi=(72)
cfn=(2776)
calls=1 888 
* 37
+1 3

fn=(3562)
318 5
+1 3
cfi=(157)
cfn=(3476)
calls=1 49 
* 26
* 1
+1 3
cfi=(152)
cfn=(3466)
calls=1 517 
* 47
* 3
+1 1
+13 4

fl=(175)
fn=(4338)
199 4
+1 4
+2 14
+1 11
cfi=(53)
cfn=(4340) QObject::startTimer(int, Qt::TimerType)
calls=1 1624 
* 19615
* 3
+1 3

fn=(4844) QTimer::timerEvent(QTimerEvent*)
243 3216
+1 1608
cfi=(174)
cfn=(4846)
calls=536 +88 
* 3752
* 3752
+1 2680
+2 2680
cfi=(177) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/.moc/moc_qtimer.cpp
cfn=(4848) QTimer::timeout(QTimer::QPrivateSignal)
calls=536 -47 
* 116752246449
* 535
+2 2140

fn=(4206)
141 5
+1 5
cfi=(53)
cfn=(4208)
calls=1 814 
* 596
* 23
+2 3

fn=(4214)
551 5
+1 3
+1 4
+4 3

fl=(150)
fn=(3406) QConcatenable<QLatin1Char>::appendTo(QLatin1Char, QChar*&)
190 24
+1 40
cfi=(114)
cfn=(2352)
calls=4 82 
* 88
* 28

fn=(3418) QStringBuilder<QConcatenable<QString>::type, QConcatenable<QLatin1Char>::type> operator%<QString, QLatin1Char>(QString const&, QLatin1Char const&)
372 5
+2 6
cfn=(3374) QStringBuilder<QString, QLatin1Char>::QStringBuilder(QString const&, QLatin1Char const&)
calls=1 99 
* 34
* 2
+1 2

fn=(3658)
140 6
+1 6
cfi=(72)
cfn=(2320)
calls=1 889 
* 107
* 6
cfi=(72)
cfn=(3342) QString::operator+=(QString const&)
calls=1 447 
* 1654
* 6

fn=(3372)
382 15
+2 18
cfn=(3374)
calls=3 99 
* 102
* 6
+1 6

fn=(3390) QString QStringBuilder<QStringBuilder<QString, QLatin1Char>, QString>::convertTo<QString>() const
103 24
+2 12
cfn=(3392) QConcatenable<QStringBuilder<QStringBuilder<QString, QLatin1Char>, QString> >::size(QStringBuilder<QStringBuilder<QString, QLatin1Char>, QString> const&)
calls=4 359 
* 312
* 4
+1 24
cfi=(86)
cfn=(2210)
calls=4 1557 
* 3403
+4 12
cfi=(72)
cfn=(2216)
calls=4 882 
* 192
* 4
+1 8
+1 20
cfn=(3400) void QConcatenable<QStringBuilder<QStringBuilder<QString, QLatin1Char>, QString> >::appendTo<QChar>(QStringBuilder<QStringBuilder<QString, QLatin1Char>, QString> const&, QChar*&)
calls=4 363 
* 1232
+7 8
+1 20

fn=(3420) QStringBuilder<QConcatenable<QStringBuilder<QString, QLatin1Char> >::type, QConcatenable<QString>::type> operator%<QStringBuilder<QString, QLatin1Char>, QString>(QStringBuilder<QString, QLatin1Char> const&, QString const&)
372 5
+2 6
cfn=(3382) QStringBuilder<QStringBuilder<QString, QLatin1Char>, QString>::QStringBuilder(QStringBuilder<QString, QLatin1Char> const&, QString const&)
calls=1 99 
* 34
* 2
+1 2

fn=(3684) QStringBuilder<QString, QLatin1String>::QStringBuilder(QString const&, QLatin1String const&)
99 9
cfn=(3686) QStringBuilderBase<QStringBuilder<QString, QLatin1String>, QString>::QStringBuilderBase()
calls=1 -11 
* 16
* 9

fn=(3694) QConcatenable<QStringBuilder<QString, QLatin1String> >::size(QStringBuilder<QString, QLatin1String> const&)
359 5
+2 4
cfn=(3396) QConcatenable<QString>::size(QString const&)
calls=1 251 
* 17
* 8
cfn=(3696) QConcatenable<QLatin1String>::size(QLatin1String)
calls=1 231 
* 20
* 1
+1 4

fn=(3386) QStringBuilderCommon<QStringBuilder<QStringBuilder<QString, QLatin1Char>, QString>, QString>::QStringBuilderCommon()
73 24

fn=(3392)
359 20
+2 16
cfn=(3394) QConcatenable<QStringBuilder<QString, QLatin1Char> >::size(QStringBuilder<QString, QLatin1Char> const&)
calls=4 -2 
* 168
* 20
cfn=(3396)
calls=4 251 
* 68
* 4
+1 16

fn=(3650)
382 6
+2 6
cfn=(3652) QStringBuilder<QString, QString>::QStringBuilder(QString const&, QString const&)
calls=1 137 
* 34
+1 3

fn=(3652)
137 9
cfn=(3654) QStringBuilderBase<QStringBuilder<QString, QString>, QString>::QStringBuilderBase()
calls=1 -49 
* 16
* 9

fn=(3688) QStringBuilderCommon<QStringBuilder<QString, QLatin1String>, QString>::QStringBuilderCommon()
73 6

fn=(3696)
231 11
cfi=(72)
cfn=(2524) QLatin1String::size() const
calls=1 92 
* 7
* 2

fn=(3698) void QConcatenable<QStringBuilder<QString, QLatin1String> >::appendTo<QChar>(QStringBuilder<QString, QLatin1String> const&, QChar*&)
363 5
+2 6
cfn=(3404) QConcatenable<QString>::appendTo(QString const&, QChar*&)
calls=1 252 
* 109
+1 8
cfn=(3700) QConcatenable<QLatin1String>::appendTo(QLatin1String, QChar*&)
calls=1 232 
* 720
+1 3

fn=(3384) QStringBuilderBase<QStringBuilder<QStringBuilder<QString, QLatin1Char>, QString>, QString>::QStringBuilderBase()
88 28
cfn=(3386)
calls=4 -15 
* 24
* 12

fn=(3388)
125 40
cfn=(3390)
calls=4 -22 
* 5275
* 12

fn=(3396)
251 63
cfi=(72)
cfn=(2342) QString::size() const
calls=9 -20 
* 72
* 18

fn=(3686)
88 7
cfn=(3688)
calls=1 -15 
* 6
* 3

fn=(3700)
232 12
+2 5
cfi=(72)
cfn=(2524)
calls=1 92 
* 7
* 4
cfi=(72)
cfn=(2880) QLatin1String::latin1() const
calls=1 91 
* 7
* 4
cfi=(86)
cfn=(3702) QAbstractConcatenable::appendLatin1To(char const*, int, QChar*)
calls=1 10591 
* 657
+1 3
cfi=(72)
cfn=(2524)
calls=1 92 
* 7
* 8
+1 6

fn=(3374)
99 36
cfn=(3376) QStringBuilderBase<QStringBuilder<QString, QLatin1Char>, QString>::QStringBuilderBase()
calls=4 -11 
* 64
* 36

fn=(3380)
382 15
+2 18
cfn=(3382)
calls=3 99 
* 102
* 6
+1 6

fn=(3402) void QConcatenable<QStringBuilder<QString, QLatin1Char> >::appendTo<QChar>(QStringBuilder<QString, QLatin1Char> const&, QChar*&)
363 20
+2 24
cfn=(3404)
calls=4 252 
* 448
+1 24
cfn=(3406)
calls=4 190 
* 180
+1 12

fn=(3404)
252 54
+2 27
cfi=(72)
cfn=(2342)
calls=9 -23 
* 72
* 9
+1 54
cfi=(72)
cfn=(2216)
calls=9 882 
* 432
* 63
cob=(3)
cfi=(3)
cfn=(1696)
calls=9 0 
* 164
* 9
+1 72
+1 45

fn=(3656) QStringBuilderCommon<QStringBuilder<QString, QString>, QString>::QStringBuilderCommon()
73 6

fn=(3394)
359 20
+2 16
cfn=(3396)
calls=4 251 
* 68
* 20
cfn=(3398) QConcatenable<QLatin1Char>::size(QLatin1Char)
calls=4 189 
* 24
* 4
+1 16

fn=(3398)
189 24

fn=(3654)
88 7
cfn=(3656)
calls=1 -15 
* 6
* 3

fn=(3682)
382 5
+2 6
cfn=(3684)
calls=1 99 
* 34
* 2
+1 2

fn=(3690)
125 10
cfn=(3692) QString QStringBuilder<QString, QLatin1String>::convertTo<QString>() const
calls=1 -22 
* 1729
* 3

fn=(3378) QStringBuilderCommon<QStringBuilder<QString, QLatin1Char>, QString>::QStringBuilderCommon()
73 24

fn=(3382)
99 36
cfn=(3384)
calls=4 -11 
* 64
* 36

fn=(3376)
88 28
cfn=(3378)
calls=4 -15 
* 24
* 12

fn=(3400)
363 20
+2 24
cfn=(3402)
calls=4 -2 
* 708
+1 24
cfn=(3404)
calls=4 252 
* 444
+1 12

fn=(3692)
103 6
+2 3
cfn=(3694)
calls=1 359 
* 59
* 1
+1 6
cfi=(86)
cfn=(2210)
calls=1 1557 
* 737
+4 3
cfi=(72)
cfn=(2216)
calls=1 882 
* 48
* 1
+1 2
+1 5
cfn=(3698)
calls=1 363 
* 851
+7 2
+1 5

fl=(67)
fn=(1720)
261 65
+1 117
cob=(3)
cfi=(3)
cfn=(1666)
calls=12 0 
* 277
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1546
* 17
+1 13
+1 26

fn=(3134) QByteArray::QByteArray(int, Qt::Initialization)
1522 3840
+2 2560
cfi=(95)
cfn=(2122)
calls=640 111 
* 6400
* 4480
cfi=(73) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qarraydata.h
cfn=(2124) QTypedArrayData<char>::allocate(unsigned long, QFlags<QArrayData::AllocationOption>)
calls=640 211 
* 131529481
* 1920
+1 2560
+1 2560
+1 2560
cfi=(73)
cfn=(2144) QTypedArrayData<char>::data()
calls=640 199 
* 24320
* 3200
+1 1920

fn=(5286) QByteArray::nulTerminated() const
1642 6
+2 5
+1 5
cfi=(98)
cfn=(2276)
calls=1 494 
* 66
* 1
+5 5

fn=(5290) toIntegral_helper(char const*, bool*, int, unsigned long long)
3397 7
+1 6
cfi=(116)
cfn=(5292)
calls=1 -21 
* 180
+1 2

fn=(3144) QByteArray::resize(int)
1543 3195
+1 1278
+3 5112
+5 1278
+5 5112
+15 2556
cfi=(65)
cfn=(1018)
calls=639 93 
* 30672
+1 1278
-1 5112
+1 7029
+1 5751
-1 1278
-1 1278
+3 2556
cfi=(73)
cfn=(3146) QArrayData::detachFlags() const
calls=639 93 
* 8307
* 3195
cfi=(95)
cfn=(3148)
calls=639 131 
* 33228
* 4473
cfn=(3150) QByteArray::reallocData(unsigned int, QFlags<QArrayData::AllocationOption>)
calls=639 +28 
* 340248
+1 3834
+1 2556
+1 2556
cfi=(73)
cfn=(2144)
calls=639 199 
* 24282
* 3195
+3 1278

fn=(5288) unsigned int toIntegral_helper<unsigned int>(char const*, bool*, int)
3402 6
+3 1
+11 6
cfn=(5290)
calls=1 -19 
* 195
* 1
+1 4
+5 1
+1 2

fn=(1028)
126 6490
+1 9086
cfi=(62)
cfn=(922)
calls=1298 623 
* 6490
+1 6490
cfi=(62)
cfn=(922)
calls=1298 623 
* 6490
+2 6490
cfi=(68)
cfn=(1030)
calls=1298 279 
* 29854
* 1298
+2 7788
cfi=(62)
cfn=(922)
calls=1298 623 
* 6490
+2 5192
+1 2596

fn=(2274)
2279 8
+1 5
+7 1
+1 2

fn=(2462)
1045 90
+1 72
cfi=(65)
cfn=(2278)
calls=18 48 
* 1028
+1 72
cfi=(65)
cfn=(1044)
calls=18 59 
* 918
* 54
+2 72
+1 18
+1 36

fn=(2466)
3389 112
cfi=(73)
cfn=(1160) QArrayData::sharedNull()
calls=14 116 
* 70
* 84

fn=(2120)
1477 203
+2 58
+1 15
cfi=(73)
cfn=(2270) QTypedArrayData<char>::sharedNull()
calls=15 240 
* 150
* 45
+14 15
-12 28
+1 42
cob=(3)
cfi=(3)
cfn=(342)
calls=14 0 
* 224
* 14
* 14
+1 28
+1 4
cfi=(95)
cfn=(2122)
calls=1 111 
* 10
* 4
cfi=(73)
cfn=(2124)
calls=1 211 
* 191
* 3
+9 1
-7 52
cfi=(95)
cfn=(2122)
calls=13 111 
* 130
* 91
cfi=(73)
cfn=(2124)
calls=13 211 
* 9018
* 39
+1 52
+1 52
+1 78
cfi=(73)
cfn=(2144)
calls=13 199 
* 494
* 78
cob=(3)
cfi=(3)
cfn=(1696)
calls=12 0 
* 149
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1672
* 17
+1 52
cfi=(73)
cfn=(2144)
calls=13 199 
* 494
* 65
+3 145

fn=(3150)
1603 5112
+1 2556
cfi=(65)
cfn=(1018)
calls=639 93 
* 30672
* 6390
+10 2556
cfi=(95)
cfn=(2128)
calls=639 136 
* 33228
* 2556
cfi=(95)
cfn=(2138)
calls=639 128 
* 4473
* 2556
+1 1278
+2 2556
cfn=(1028)
calls=639 126 
* 46647
* 639
+2 4473
cob=(3)
cfi=(3)
cfn=(3156)
calls=638 0 
* 128966
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1686
* 643
* 639
+1 1917
+1 5751
+1 3195
cfi=(95)
cfn=(2128)
calls=639 136 
* 33228
* 2556
cfi=(95)
cfn=(2138)
calls=639 128 
* 4473
* 5751
+1 1917
+2 3834

fn=(5284) QByteArray::toUInt(bool*, int) const
3524 7
+1 5
cfn=(5286)
calls=1 1642 
* 88
* 3
cfi=(98)
cfn=(2472) QByteArray::constData() const
calls=1 489 
* 40
* 6
cfn=(5288)
calls=1 3402 
* 216
* 4
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
* 2
+1 4

fl=(134)
fn=(2840)
86 14
cfi=(62)
cfn=(2820)
calls=2 1014 
* 32
* 4

fn=(2818)
86 14
cfi=(62)
cfn=(2820)
calls=2 1014 
* 32
* 4

fl=(187)
fn=(4510) QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)::LoopReference::LoopReference(QEventLoopPrivate*, QMutexLocker&)
172 14
+2 2
+1 5
cfi=(35)
cfn=(1290)
calls=1 -55 
* 44
+1 5
+1 3
cfi=(188) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qeventloop_p.h
cfn=(4512) QEventLoopPrivate::q_func()
calls=1 54 
* 7
* 8
cfi=(75) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qstack.h
cfn=(4514) QStack<QEventLoop*>::push(QEventLoop* const&)
calls=1 48 
* 1907
+1 3
cfi=(34)
cfn=(1052) QMutexLocker::unlock()
calls=1 -44 
* 211
+1 3

fn=(4498) QEventLoop::QEventLoop(QObject*)
92 7
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 -50 
* 208
* 1
* 3
cfi=(188)
cfn=(4500) QEventLoopPrivate::QEventLoopPrivate()
calls=1 -37 
* 400
* 6
cfi=(53)
cfn=(1316)
calls=1 839 
* 238
* 4
+2 3
cfi=(189)
cfn=(4502)
calls=1 -48 
* 26
* 1
+1 1
cfi=(84)
cfn=(3042)
calls=1 +14 
* 6
* 5
+2 5
cfi=(35)
cfn=(3746)
calls=1 252 
* 47
* 4
+3 6

fn=(4540) QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
124 2685
+1 1611
cfi=(189)
cfn=(4502)
calls=537 -78 
* 13962
* 537
+1 2685
cfi=(35)
cfn=(3746)
calls=537 252 
* 25239
* 2148
+2 2685
cfi=(35)
cfn=(3746)
calls=537 252 
* 25239
* 3759
cfi=(169)
cfn=(4542) QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
calls=537 399 
* 116756329321
+1 1072

fn=(4508)
155 6
+1 3
cfi=(189)
cfn=(4502)
calls=1 47 
* 26
* 1
+2 5
cfi=(35)
cfn=(1370)
calls=1 +96 
* 56
* 2
cfi=(164) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/kernel/qobject_p.h
cfn=(4262) QObjectPrivate::get(QObject*)
calls=1 +33 
* 35
* 5
cfi=(34)
cfn=(920)
calls=1 -37 
* 218
+1 5
+3 4
+36 6
cfn=(4510)
calls=1 -26 
* 2212
+3 1
cfi=(84)
cfn=(3042)
calls=1 -91 
* 6
* 1
+1 5
cfi=(53)
cfn=(3770) QObject::thread() const
calls=1 1424 
* 95
* 4
cfi=(53)
cfn=(3770)
calls=1 1424 
* 95
* 6
+1 4
cfi=(50)
cfn=(4534) QCoreApplication::removePostedEvents(QObject*, int)
calls=1 1681 
* 534
+2 2148
cfi=(35)
cfn=(1280)
calls=537 -86 
* 18795
* 2148
+1 2148
cfi=(95)
cfn=(4536)
calls=537 -75 
* 27924
* 2685
cfi=(95)
cfn=(4536)
calls=537 -75 
* 27924
* 2685
cfn=(4540)
calls=537 -82 
* 116756410943
-1 536

fl=(34)
fn=(1054) QMutexLocker::mutex() const
157 60010104
+2 60010104
+1 40006736

fn=(4896) QMutexLocker::relock()
142 40002136
fi=(63) /home/tsenyk/qt5/qt5/qtbase/src/corelib/thread/qmutex.h
+2 40002136
fe=(34)
+1 50002670
+1 30001602
cfn=(1054)
calls=10000534 +11 
* 80004272
* 20001068
cfi=(58)
cfn=(924)
calls=10000534 +71 
* 1810096654
+1 60003204
+3 30001602

fn=(920)
121 11505
+2 4602
+1 4602
-1 2301
cfi=(62)
cfn=(922)
calls=2301 623 
* 11505
+2 9204
+1 13806
+2 6903
cfi=(58)
cfn=(924)
calls=2301 +89 
* 418882
+1 13806
+2 6903

fn=(1050)
132 16093
cfn=(1052)
calls=2299 +2 
* 486175
* 6897

fn=(746)
54 1050
cfi=(35)
cfn=(748)
calls=150 329 
* 3900
* 450

fn=(1052)
134 40011336
+2 50014170
+1 60017004
fi=(63)
+1 30008502
cfi=(34)
cfn=(1054)
calls=10002834 +19 
* 80022672
* 20005668
cfi=(58)
cfn=(1058)
calls=10002834 269 
* 1800511206
+2 30008502
fe=(34)

fl=(58)
fn=(882)
177 70
cfi=(34)
cfn=(746)
calls=7 54 
* 252
+2 18
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 216
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
* 1262
* 6
* 6
cfn=(890) QRecursiveMutexPrivate::QRecursiveMutexPrivate()
calls=2 69 
* 404
* 29
cfi=(35)
cfn=(902)
calls=5 +74 
* 300
* 8
cfi=(35)
cfn=(902)
calls=2 +74 
* 120
+1 42

fn=(883) QMutex::QMutex(QMutex::RecursionMode)'2
177 20
cfi=(34)
cfn=(746)
calls=2 54 
* 72
+2 14
cfi=(35)
cfn=(902)
calls=2 +74 
* 120
+1 12

fn=(924)
217 120011348
+2 150014185
cfi=(63)
cfn=(926) QBasicMutex::fastTryLock(QMutexData*&)
calls=30002837 81 
* 5010473784
* 60005674
+2 15
cfn=(942) isRecursive(QMutexData*)
calls=5 54 
* 125
* 10
+1 20
cfn=(944) QRecursiveMutexPrivate::lock(int)
calls=5 646 
* 2590
* 5
-2 30002832
+5 60005674

fn=(1066) QRecursiveMutexPrivate::unlock()
669 20
+1 20
+1 5
+5 1
-3 20
cfi=(35)
cfn=(970)
calls=4 253 
* 240
+1 16
cfi=(63)
cfn=(1068) QBasicMutex::unlock()
calls=4 62 
* 924
+2 15

fn=(944)
646 25
+1 5
cfi=(41)
cfn=(946) QThread::currentThreadId()
calls=5 413 
* 1257
* 5
+1 20
cfi=(35)
cfn=(956)
calls=5 252 
* 235
* 20
+1 5
+1 5
cfi=(62)
cfn=(922)
calls=1 -27 
* 5
+1 2
+2 4
+1 8
+1 16
cfi=(63)
cfn=(964) QBasicMutex::lock()
calls=4 57 
* 688
* 4
+5 8
+1 24
cfi=(35)
cfn=(970)
calls=4 253 
* 240
+1 4
+1 10

fn=(942)
54 40
+1 20
+1 50
+3 60
cfi=(62)
cfn=(922)
calls=10 623 
* 50
+1 10
+4 20

fn=(890)
69 8
+1 8
cfi=(60) /home/tsenyk/qt5/qt5/qtbase/src/corelib/thread/qmutex_p.h
cfn=(892) QMutexData::QMutexData(QMutex::RecursionMode)
calls=2 +3 
* 22
* 10
cfi=(61)
cfn=(894) QAtomicPointer<void>::QAtomicPointer(void*)
calls=2 +94 
* 98
* 14
cfn=(883)
calls=2 177 
* 238
* 6

fn=(1058)
269 120011344
+2 150014180
cfi=(63)
cfn=(1060) QBasicMutex::fastTryUnlock(QMutexData*&)
calls=30002836 84 
* 4980470781
* 60005672
+2 15
cfn=(942)
calls=5 54 
* 125
* 10
+1 15
cfn=(1066)
calls=5 669 
* 1261
* 5
-2 30002831
+5 60005672

fl=(181) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/kernel/qobjectdefs.h
fn=(4320) QMetaObject::Connection::Connection(QMetaObject::Connection&&)
531 130000013

fn=(4310) QMetaObject::Connection::Connection(void*)
513 100000010

fl=(196) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qtextstream.h
fn=(4950) QTextStream::d_func()
58 21888
cfi=(62)
cfn=(4952)
calls=2736 1014 
* 43776
* 5472

fl=(97)
fn=(2142)
239 33966

fn=(2140)
252 32016

fl=(158)
fn=(3494) QFSFileEnginePrivate::init()
118 4
+1 4
+1 4
+2 4
+1 4
+2 4
cfi=(95)
cfn=(3432)
calls=1 -14 
* 10
* 3
+1 2
+1 2
+1 2
+1 2
+1 2
+9 3

fn=(3596)
169 4
+11 3
cfn=(3597) QFSFileEngine::~QFSFileEngine()'2
calls=1 -11 
* 858
* 4
cob=(13)
cfi=(127)
cfn=(2652)
calls=1 32 
* 92
* 1
* 2

fn=(3597)
169 8
+2 3
cfi=(159) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/io/qfsfileengine_p.h
cfn=(3496) QFSFileEngine::d_func()
calls=1 66 
* 26
* 1
+1 4
+7 3
cfn=(3598) QFSFileEnginePrivate::unmapAll()
calls=1 464 
* 27
-10 3
cfi=(113)
cfn=(3020)
calls=1 365 
* 780
+11 3

fn=(3500)
196 8
+1 3
cfi=(159)
cfn=(3496)
calls=1 66 
* 26
* 1
+1 4
cfi=(108)
cfn=(3198) QFileSystemEntry::isEmpty() const
calls=1 321 
* 22
* 2
+7 4
cfi=(95)
cfn=(3472)
calls=1 -69 
* 52
* 4
cfi=(95)
cfn=(3470)
calls=1 -77 
* 7
* 4
+4 6
cfi=(95)
cfn=(3472)
calls=1 -73 
* 52
* 5
cfi=(95)
cfn=(3470)
calls=1 -81 
* 7
* 8
+3 3
+1 2
+1 4
+1 2
+1 2
+2 5
cfi=(161) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfsfileengine_unix.cpp
cfn=(3502) QFSFileEnginePrivate::nativeOpen(QFlags<QIODevice::OpenModeFlag>)
calls=1 -66 
* 8958
* 1
+1 6

fn=(3598)
464 5
+1 4
cfi=(92)
cfn=(3600) QHash<unsigned char*, QPair<int, unsigned long> >::isEmpty() const
calls=1 261 
* 10
* 3
+5 5

fn=(3488) QFSFileEnginePrivate::QFSFileEnginePrivate()
109 8
cfi=(115)
cfn=(2362)
calls=1 247 
* 37
* 7
cfi=(108)
cfn=(3254) QFileSystemEntry::QFileSystemEntry()
calls=1 -41 
* 62
* 5
cfi=(95)
cfn=(3490)
calls=1 +3 
* 9
* 4
cfi=(110)
cfn=(2326)
calls=1 -41 
* 36
* 4
cfi=(92)
cfn=(3492) QHash<unsigned char*, QPair<int, unsigned long> >::QHash()
calls=1 235 
* 9
+2 3
cfn=(3494)
calls=1 +7 
* 50
+1 5

fn=(3486)
144 7
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 397
* 1
* 3
cfn=(3488)
calls=1 -36 
* 239
* 5
cfi=(113)
cfn=(2824)
calls=1 357 
* 53
* 4
+2 3
cfi=(159)
cfn=(3496)
calls=1 -81 
* 26
* 1
+1 5
cfi=(108)
cfn=(2316)
calls=1 -68 
* 164
* 6
cfi=(112)
cfn=(3260)
calls=1 -91 
* 170
* 3
cfi=(138)
cfn=(2930)
calls=1 -91 
* 144
+1 6

fl=(204)
fn=(5298)
43 6
+10 2
+2 5
+1 2
-2 2
cfi=(125)
cfn=(5296)
calls=1 409 
* 9
* 2
+3 2
+4 1
+1 2
+3 4
+9 2
+2 2
+1 4
+3 6
+1 7
+2 2
+2 2
+2 2
+14 2
+3 2
+2 1
cob=(5)
cfi=(5)
cfn=(3524)
calls=1 0 
* 3
* 1
* 2
+3 2
+1 5
+1 1
+1 2

fl=(46)
fn=(792)
316 5
cfn=(794) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 50
* 2

fn=(794)
316 9
127 2
cfi=(34)
cfn=(746)
calls=1 -73 
* 36
316 3

fl=(147) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qdir.h
fn=(3232) operator|(QDir::SortFlag, QDir::SortFlag)
227 20
cfi=(95)
cfn=(3234)
calls=2 111 
* 20
* 10
cfi=(95)
cfn=(3236)
calls=2 -96 
* 104
* 4

fn=(3310) QDir::isAbsolutePath(QString const&)
165 8
fi=(149) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/io/qdir.h
* 6
cfi=(109)
cfn=(3312)
calls=2 2212 
* 12226
* 6
fe=(147)

fl=(145)
fn=(3666)
84 15
+2 15
cfi=(72)
cfn=(3668) QString::fromLocal8Bit(QByteArray const&)
calls=3 545 
* 3225
fi=(168) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfile.h
+1 9
fe=(145)

fn=(3122) QFile::encodeName(QString const&)
80 25
+2 25
cfi=(72)
cfn=(3124) QString::toLocal8Bit() const &
calls=5 516 
* 16893
+1 15

fn=(3456)
55 16
cfi=(62)
cfn=(1322)
calls=2 1014 
* 32
* 4

fl=(39)
fn=(5030) qt_message_output(QtMsgType, QMessageLogContext const&, QString const&)
1659 3804
+1 3804
cfn=(5032) qt_message_print(QtMsgType, QMessageLogContext const&, QString const&)
calls=634 -64 
* 135067152
+1 1902
cfn=(5342) isFatal(QtMsgType)
calls=634 151 
* 9510
* 1268
+2 1902

fn=(5032)
1596 4438
+3 5706
cob=(3)
cfi=(3)
cfn=(1666)
calls=634 0 
* 13314
* 634
* 1268
+1 634
cfi=(199)
cfn=(5034)
calls=634 380 
* 60943
* 1902
+1 3170
cfi=(199)
cfn=(5166)
calls=634 313 
* 51354
* 1902
+8 634
cfn=(5178) grabMessageHandler()
calls=634 -32 
* 23458
* 1268
+2 1268
cfi=(35)
cfn=(5180)
calls=634 252 
* 29798
* 634
+1 3170
-1 1268
+2 1268
cfi=(35)
cfn=(5188)
calls=634 252 
* 29798
* 4438
cfn=(5196) qDefaultMessageHandler(QtMsgType, QMessageLogContext const&, QString const&)
calls=634 -82 
* 134807767
* 634
+4 634
cfn=(5340) ungrabMessageHandler()
calls=634 -31 
* 12680
* 634
+4 2536

fn=(5198) qFormatLogMessage(QtMsgType, QMessageLogContext const&, QString const&)
1262 6340
+1 1902
cfi=(72)
cfn=(1156)
calls=634 1064 
* 13314
+2 2536
cfi=(34)
cfn=(920)
calls=634 121 
* 138212
+2 1268
cfi=(56)
cfn=(5200)
calls=634 129 
* 98529
* 634
+1 1268
+6 634
+3 634
+2 634
+5 34870
+1 25360
+1 9510
+1 1268
+1 5072
+4 3804
+3 3804
+4 3804
+1 3170
cfi=(86)
cfn=(3344) QString::append(QString const&)
calls=634 2036 
* 132506
* 634
+1 1902
+2 1902
+8 1902
+5 1902
+2 1902
+6 1902
+2 1902
+2 1902
+3 1902
+4 1902
+59 1902
+19 1902
+1 5706
cob=(3)
cfi=(3)
cfn=(1666)
calls=634 0 
* 13314
* 634
* 1268
+1 1268
1284 6340
1429 634
1265 1902
cfi=(34)
cfn=(1050)
calls=634 132 
* 140114
* 634
1430 4438

fn=(5196)
1531 4438
+1 3804
cfn=(5198)
calls=634 1262 
* 688783
+4 1902
cfi=(72)
cfn=(2778) QString::isNull() const
calls=634 775 
* 15216
* 1268
+3 634
cfn=(5280) qt_logging_to_console()
calls=634 212 
* 11125
+20 3170
cfi=(72)
cfn=(3124)
calls=634 516 
* 133275443
* 1902
cfi=(98)
cfn=(2472)
calls=634 489 
* 30432
* 4438
cob=(3)
cfi=(3)
cfn=(5304)
calls=633 0 
* 470475
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 2261
* 638
* 1902
cfi=(98)
cfn=(2154)
calls=634 465 
* 183860
+1 2536
cob=(3)
cfi=(3)
cfn=(5336)
calls=633 0 
* 32916
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1514
* 638
* 2536
cfi=(72)
cfn=(2230)
calls=634 1065 
* 62132
* 634
-28 634
+29 2536

fn=(5204)
1245 5708
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 7
cfn=(5206) (anonymous namespace)::Q_QGS_qMessagePattern::innerFunction()::Holder::Holder()
calls=1 * 
* 52746
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 0 
* 66
* 1
* 3804

fn=(4958) QMessageLogContext::copy(QMessageLogContext const&)
1859 2536
+1 2536
+1 2536
+1 2536
+1 2536
+1 1902

fn=(5210) QMessagePattern::QMessagePattern()
1004 5
+3 8
cfi=(64)
cfn=(2440) QList<QString>::QList()
calls=1 141 
* 19
* 4
cfi=(203)
cfn=(5212)
calls=1 53 
* 12
* 4
cfi=(76)
cfn=(5214) QVector<QMessagePattern::BacktraceParams>::QVector()
calls=1 65 
* 21
* 2
+3 4
cfi=(80) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qelapsedtimer_unix.cpp
cfn=(5218) QElapsedTimer::start()
calls=1 195 
* 118
+2 4
cfi=(38)
cfn=(2264)
calls=1 3173 
* 926
* 5
cfi=(72)
cfn=(3668)
calls=1 545 
* 60
* 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
+1 3
cfi=(72)
cfn=(1456)
calls=1 874 
* 10
* 2
+1 4
cfi=(72)
cfn=(2518)
calls=1 87 
* 55
* 6
cfi=(72)
cfn=(3304)
calls=1 863 
* 2064
* 5
cfn=(5222) QMessagePattern::setPattern(QString const&)
calls=1 +18 
* 48901
* 3
cfi=(72)
cfn=(2230)
calls=1 +51 
* 290
* 1
-2 3
cfi=(72)
cfn=(2230)
calls=1 +53 
* 65
+7 5

fn=(758)
1864 5
cfn=(760) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 50
* 2

fn=(760)
1864 9
1002 2
cfi=(34)
cfn=(746)
calls=1 54 
* 36
1864 3

fn=(4908)
391 3170
+1 2536
cfi=(192)
cfn=(4910)
calls=634 101 
* 132671776
+1 2536
+1 3170
cfn=(4958)
calls=634 1859 
* 14582
+1 634
+1 1902

fn=(5178)
1577 1902
+1 634
cob=(1)
cfi=(1)
cfn=(1184)
calls=634 0 
* 6974
* 634
* 1902
+1 634
+2 634
cob=(1)
cfi=(1)
cfn=(1184)
calls=634 0 
* 6974
* 634
* 634
+1 634
+1 1268

fn=(5208) (anonymous namespace)::Q_QGS_qMessagePattern::innerFunction()::HolderBase::HolderBase()
1245 6

fn=(5222)
1032 8
+1 4
+5 4
+3 3
cfi=(64)
cfn=(2440)
calls=1 141 
* 19
+1 3
cfi=(72)
cfn=(1156)
calls=1 +22 
* 21
+1 1
+1 4
cfi=(72)
cfn=(2342)
calls=1 231 
* 8
* 135
cfi=(72)
cfn=(2342)
calls=45 231 
* 360
* 184
+1 225
cfi=(72)
cfn=(2574)
calls=45 868 
* 4185
* 45
+1 180
cfi=(114)
cfn=(2350)
calls=45 47 
* 495
* 270
cfi=(114)
cfn=(2352)
calls=45 82 
* 990
+1 45
-1 225
cfi=(114)
cfn=(2356)
calls=45 567 
* 450
+1 155
-1 180
+3 8
-1 20
cfi=(72)
cfn=(2342)
calls=4 231 
* 32
+1 24
cfi=(114)
cfn=(2350)
calls=4 47 
* 44
* 24
cfi=(114)
cfn=(2352)
calls=4 82 
* 88
* 28
cfi=(72)
cfn=(2574)
calls=4 868 
* 372
* 20
cfi=(114)
cfn=(2356)
calls=4 567 
* 40
* 24
-1 8
+3 12
cfi=(72)
cfn=(1456)
calls=4 874 
* 40
* 12
+1 5
cfi=(64)
cfn=(3290)
calls=1 569 
* 919
+1 3
cfi=(72)
cfn=(2776)
calls=1 888 
* 236
+2 4
+4 20
cfi=(86)
cfn=(5008) QString::append(QChar)
calls=4 2121 
* 5072
* 205
cfi=(86)
cfn=(5008)
calls=41 2121 
* 11240
+2 180
cfi=(114)
cfn=(2350)
calls=45 47 
* 495
* 270
cfi=(114)
cfn=(2352)
calls=45 82 
* 990
* 270
cfi=(114)
cfn=(2356)
calls=45 567 
* 450
* 327
+2 20
cfi=(64)
cfn=(3290)
calls=4 569 
* 1719
+1 12
cfi=(72)
cfn=(2776)
calls=4 888 
* 944
+1 4
-21 90
+24 3
cfi=(72)
cfn=(1456)
calls=1 874 
* 10
* 3
+4 4
cfi=(136) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qvarlengtharray.h
cfn=(5228) QVarLengthArray<char const*, 256>::QVarLengthArray(int)
calls=1 230 
* 31
+1 3
cfi=(64)
cfn=(5230) QList<QString>::size() const
calls=1 160 
* 22
* 8
cob=(13)
cfi=(184)
cfn=(4376)
calls=1 32 
* 119
* 1
* 4
+1 5
cfi=(64)
cfn=(5230)
calls=1 160 
* 22
* 4
+2 1
+1 1
+1 3
cfi=(72)
cfn=(1156)
calls=1 -14 
* 21
+2 4
cfi=(64)
cfn=(5230)
calls=1 160 
* 22
* 15
cfi=(64)
cfn=(5230)
calls=5 160 
* 110
* 24
+1 25
cfi=(64)
cfn=(5232) QList<QString>::at(int) const
calls=5 530 
* 320
* 25
cfi=(72)
cfn=(2320)
calls=5 889 
* 535
+2 10
-1 20
cfi=(72)
cfn=(2518)
calls=5 87 
* 185
+1 5
-1 30
cfi=(86)
cfn=(2876)
calls=5 4384 
* 1855
+1 26
cfi=(114)
cfn=(2350)
calls=4 47 
* 44
* 24
cfi=(114)
cfn=(2352)
calls=4 82 
* 88
* 28
cfi=(86)
cfn=(2874) QString::endsWith(QChar, Qt::CaseSensitivity) const
calls=4 4469 
* 436
* 19
-1 3
+1 8
-1 12
+3 16
cfi=(72)
cfn=(2518)
calls=4 87 
* 148
* 24
cfi=(86)
cfn=(2522)
calls=4 2699 
* 132
* 8
+2 16
cfi=(72)
cfn=(2518)
calls=4 87 
* 148
* 24
cfi=(86)
cfn=(2522)
calls=4 2699 
* 639
* 8
+1 9
+1 12
cfi=(72)
cfn=(2518)
calls=3 87 
* 111
* 18
cfi=(86)
cfn=(2522)
calls=3 2699 
* 542
* 6
+1 9
+1 8
cfi=(72)
cfn=(2518)
calls=2 87 
* 74
* 12
cfi=(86)
cfn=(2522)
calls=2 2699 
* 66
* 4
+2 8
cfi=(72)
cfn=(2518)
calls=2 87 
* 74
* 12
cfi=(86)
cfn=(2522)
calls=2 2699 
* 66
* 4
+2 8
cfi=(72)
cfn=(2518)
calls=2 87 
* 74
* 12
cfi=(86)
cfn=(2522)
calls=2 2699 
* 66
* 4
+2 8
cfi=(72)
cfn=(2518)
calls=2 87 
* 74
* 12
cfi=(86)
cfn=(2522)
calls=2 2699 
* 66
* 4
+2 8
cfi=(72)
cfn=(2518)
calls=2 87 
* 74
* 12
cfi=(86)
cfn=(2522)
calls=2 2699 
* 66
* 4
+2 8
cfi=(72)
cfn=(2518)
calls=2 87 
* 74
* 12
cfi=(86)
cfn=(2522)
calls=2 2699 
* 66
* 4
+2 8
cfi=(72)
cfn=(2518)
calls=2 87 
* 74
* 12
cfi=(86)
cfn=(2522)
calls=2 2699 
* 66
* 4
+2 8
cfi=(72)
cfn=(2518)
calls=2 87 
* 74
* 12
cfi=(86)
cfn=(2876)
calls=2 4384 
* 894
* 4
+7 8
cfi=(72)
cfn=(2518)
calls=2 87 
* 74
* 12
cfi=(86)
cfn=(2876)
calls=2 4384 
* 436
* 4
+34 8
cfi=(72)
cfn=(2518)
calls=2 87 
* 74
* 12
cfi=(86)
cfn=(2522)
calls=2 2699 
* 765
* 16
+1 4
cfi=(72)
cfn=(2518)
calls=1 87 
* 37
* 6
cfi=(86)
cfn=(2522)
calls=1 2699 
* 33
* 2
+1 4
cfi=(72)
cfn=(2518)
calls=1 87 
* 37
* 6
cfi=(86)
cfn=(2522)
calls=1 2699 
* 33
* 2
+1 4
cfi=(72)
cfn=(2518)
calls=1 87 
* 37
* 6
cfi=(86)
cfn=(2522)
calls=1 2699 
* 33
* 2
+1 4
cfi=(72)
cfn=(2518)
calls=1 87 
* 37
* 6
cfi=(86)
cfn=(2522)
calls=1 2699 
* 33
* 2
+1 4
cfi=(72)
cfn=(2518)
calls=1 87 
* 37
* 6
cfi=(86)
cfn=(2522)
calls=1 2699 
* 33
* 2
+2 4
cfi=(72)
cfn=(2518)
calls=1 87 
* 37
* 6
cfi=(86)
cfn=(2522)
calls=1 2699 
* 348
* 2
+1 8
+1 4
+2 2
+7 3
cfi=(72)
cfn=(2342)
calls=1 231 
* 8
* 4
cob=(13)
cfi=(184)
cfn=(4376)
calls=1 32 
* 119
* 1
* 1
+1 3
cfi=(72)
cfn=(2342)
calls=1 231 
* 8
* 6
cfi=(72)
cfn=(5248) QString::toLatin1() const &
calls=1 508 
* 1185
* 3
cfi=(98)
cfn=(2472)
calls=1 489 
* 48
* 6
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1600
* 5
* 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 290
+1 3
cfi=(72)
cfn=(2342)
calls=1 231 
* 8
* 4
+1 7
cfi=(136)
cfn=(5272) QVarLengthArray<char const*, 256>::append(char const* const&)
calls=1 141 
* 29
+1 8
-87 3
cfi=(72)
cfn=(2230)
calls=1 -16 
* 98
* 12
cfi=(72)
cfn=(2230)
calls=4 -16 
* 392
-1 10
+91 2
+2 2
+2 3
cfi=(72)
cfn=(1456)
calls=1 874 
* 10
* 3
+14 3
cfi=(136)
cfn=(5274) QVarLengthArray<char const*, 256>::size() const
calls=1 109 
* 7
* 8
cob=(13)
cfi=(184)
cfn=(4376)
calls=1 32 
* 119
* 1
* 4
+1 5
cfi=(136)
cfn=(5274)
calls=1 109 
* 7
* 4
+1 3
cfi=(136)
cfn=(5274)
calls=1 109 
* 7
* 5
cfi=(136)
cfn=(5276) QVarLengthArray<char const*, 256>::constData() const
calls=1 167 
* 7
* 7
cob=(3)
cfi=(3)
cfn=(1696)
calls=1 0 
* 12
* 1
1078 3
cfi=(72)
cfn=(2230)
calls=1 -13 
* 65
-6 3
cfi=(136)
cfn=(5278) QVarLengthArray<char const*, 256>::~QVarLengthArray()
calls=1 77 
* 13
-30 3
cfi=(72)
cfn=(2230)
calls=1 +23 
* 65
-1 3
cfi=(64)
cfn=(2798) QList<QString>::~QList()
calls=1 814 
* 1804
1192 7

fn=(5340)
1586 1902
+1 634
cob=(1)
cfi=(1)
cfn=(1184)
calls=634 0 
* 6974
* 634
* 634
+1 1902

fn=(5282) willLogToConsole()
169 4
+15 1
+1 4
cfi=(38)
cfn=(2264)
calls=1 3173 
* 926
* 6
cfi=(67)
cfn=(5284)
calls=1 3524 
* 440
* 4
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
+1 3
+7 4
cfi=(162)
cfn=(3508)
calls=1 -35 
* 59
* 1
+1 2
+3 2
+2 3
cfi=(162)
cfn=(5088)
calls=1 +73 
* 21
+1 2
+9 4

fn=(5280)
212 2536
+1 3172
cob=(13)
cfi=(19)
cfn=(618)
calls=1 +30 
* 36
* 1
* 6
cfn=(5282)
calls=1 -44 
* 1551
* 3
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
+1 1268
+1 2536

fn=(5342)
151 2536
+1 1268
+3 1268
+5 2536
+5 634
+1 1268

fn=(5206)
1245 8
cfn=(5208)
calls=1 * 
* 6
* 3
cfn=(5210)
calls=1 1004 
* 52677
* 3
cfi=(35)
cfn=(910)
calls=1 117 
* 44
* 5

fl=(75)
fn=(4514)
48 10
cfi=(76)
cfn=(4516) QVector<QEventLoop*>::append(QEventLoop* const&)
calls=1 627 
* 1894
* 3

fn=(1190) QStack<QEventLoop*>::QStack()
43 7
cfi=(76)
cfn=(1192) QVector<QEventLoop*>::QVector()
calls=1 +22 
* 21
* 3

fl=(153) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qiodevice_p.h
fn=(3620) QIODevicePrivateLinearBuffer::~QIODevicePrivateLinearBuffer()
71 4
+1 4
+1 3

fn=(3434) QIODevicePrivateLinearBuffer::QIODevicePrivateLinearBuffer(int)
69 12
+1 3

fl=(179) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/thread/qorderedmutexlocker_p.h
fn=(4312) QOrderedMutexLocker::unlock()
82 120000008
+2 120000008
+1 160000008
cfi=(58)
cfn=(1058)
calls=20000001 269 
* 3600000180
+1 80000004
+1 40000002
+2 90000006

fn=(4328) QOrderedMutexLocker::~QOrderedMutexLocker()
68 80000004
+2 60000003
cfn=(4312)
calls=20000001 +12 
* 2160000011
+1 60000003

fn=(4242) QOrderedMutexLocker::QOrderedMutexLocker(QMutex*, QMutex*)
61 140000007
+1 120000006
+2 40000002
-2 20000001
+2 20000001
-1 120000006
+1 40000002
-1 20000001
+1 40000002
+2 60000003
cfn=(4244) QOrderedMutexLocker::relock()
calls=20000001 +7 
* 4140000207
+1 100000005

fn=(4244)
73 80000004
+2 100000005
+1 160000008
cfi=(58)
cfn=(924)
calls=20000001 217 
* 3620000181
+1 80000004
+1 40000002
+2 60000003

fl=(92)
fn=(1506) QHash<QByteArray, QTextCodec*>::QHash()
235 9

fn=(3604) QHash<unsigned char*, QPair<int, unsigned long> >::~QHash()
246 4
0 5
fi=(31)
cfi=(65)
cfn=(1044)
calls=1 59 
0 51
0 6

fn=(5060) QHash<QLoggingCategory*, QtMsgType>::detach()
267 4
0 5
fi=(31)
cfi=(65)
cfn=(1018)
calls=1 93 
0 51
0 5
fi=(31)
cfn=(5064) QHash<QLoggingCategory*, QtMsgType>::detach_helper()
calls=1 565 
0 4977
0 3

fn=(5098)
56 8
cfi=(65)
cfn=(5100)
calls=1 -11 
* 36
* 3

fn=(5124) QHashNode<QLoggingCategory*, QtMsgType>::same_key(unsigned int, QLoggingCategory* const&) const
150 10
0 28

fn=(2260)
235 9

fn=(5054) QHash<QLoggingCategory*, QtMsgType>::findNode(QLoggingCategory* const&, unsigned int*) const
895 30
+3 5
+2 29
+1 28
cfi=(200) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qhashfunctions.h
cfn=(5102) unsigned int qHash<QLoggingCategory*>(QLoggingCategory* const&, unsigned int)
calls=4 103 
* 148
* 4
+1 8
+1 6
+2 12
cfn=(5056) QHash<QLoggingCategory*, QtMsgType>::findNode(QLoggingCategory* const&, unsigned int) const
calls=2 -26 
* 66
* 18
cfn=(5056)
calls=3 -26 
* 184
+1 10

fn=(5120) QHash<QLoggingCategory*, QtMsgType>::iterator::iterator(void*)
310 10

fn=(5066) QHash<QLoggingCategory*, QtMsgType>::alignOfNode()
232 20
cfi=(62)
cfn=(3080)
calls=2 547 
* 26
* 6

fn=(5056)
879 30
+4 25
+1 45
+1 31
cfi=(62)
cfn=(922)
calls=3 623 
* 15
+1 32
cfn=(5124)
calls=2 150 
* 38
* 15
+3 4
+2 2
+1 4
-1 3
+1 6

fn=(5058)
736 6
+3 3
cfn=(5060)
calls=1 267 
* 5045
+3 6
cfn=(5054)
calls=1 895 
* 88
* 1
+1 6
+1 4
cfn=(5108) QHashData::willGrow()
calls=1 96 
* 547
* 2
+1 6
cfn=(5054)
calls=1 895 
* 120
* 1
+1 8
cfn=(5114) QHash<QLoggingCategory*, QtMsgType>::createNode(unsigned int, QLoggingCategory* const&, QtMsgType const&, QHashNode<QLoggingCategory*, QtMsgType>**)
calls=1 532 
* 232
* 5
cfn=(5120)
calls=1 310 
* 10
* 2
+6 2

fn=(5114)
532 9
+2 1
cfn=(5066)
calls=1 232 
* 26
* 6
cfi=(137)
cfn=(5116)
calls=1 -90 
* 128
* 3
cfi=(133) /usr/include/c++/6.1.1/new
cfn=(2728) operator new(unsigned long, void*)
calls=1 147 
* 7
* 12
cfn=(5118) QHashNode<QLoggingCategory*, QtMsgType>::QHashNode(QLoggingCategory* const&, QtMsgType const&, unsigned int, QHashNode<QLoggingCategory*, QtMsgType>*)
calls=1 148 
* 24
* 3
+1 3
+1 5
+1 1
+1 4

fn=(1492) QHash<void*, int>::QHash()
235 18

fn=(5128)
589 5
+3 11
cfn=(5054)
calls=1 895 
* 151
* 9
+3 2
+2 2

fn=(3492)
235 9

fn=(5064)
565 4
+2 1
cfn=(5066)
calls=1 232 
* 26
* 9
cfi=(137)
cfn=(5068)
calls=1 462 
* 4871
* 1
+1 5
cfi=(65)
cfn=(1044)
calls=1 59 
* 51
* 3
+2 3
+1 3

fn=(3600)
261 10

fn=(5052)
873 10
+2 12
cfn=(5054)
calls=2 +20 
* 189
* 10
+1 4

fn=(5118)
148 7
+1 17

fn=(2152)
589 5
+3 9
+1 2
+4 2

fn=(5108)
96 4
+1 6
+1 8
cfi=(137)
cfn=(5110)
calls=1 613 
* 525
+1 2
+4 2

fl=(111)
fn=(3088) _q_checkEntry(QFileSystemEntry&, QFileSystemMetaData&, bool)
106 96
+1 24
+8 24
+1 48

fn=(3170) QFileSystemMetaData::fillFromStatBuf(stat64 const&)
233 5
+2 5
+1 5
cfi=(95)
cfn=(3110)
calls=1 124 
* 13
+1 5
+1 5
cfi=(95)
cfn=(3110)
calls=1 124 
* 13
+1 5
+1 5
cfi=(95)
cfn=(3110)
calls=1 124 
* 13
+2 5
+1 5
cfi=(95)
cfn=(3110)
calls=1 124 
* 13
+1 5
+2 5
+1 5
cfi=(95)
cfn=(3110)
calls=1 124 
* 13
+2 5
+1 5
cfi=(95)
cfn=(3110)
calls=1 124 
* 13
+1 5
+2 5
+1 5
cfi=(95)
cfn=(3110)
calls=1 124 
* 13
+3 5
+1 5
cfi=(95)
cfn=(3110)
calls=1 124 
* 13
* 1
+7 5
cfi=(95)
cfn=(3110)
calls=1 124 
* 13
+1 4
+9 9
+1 4
+1 4
+1 4
+1 4
+1 3

fn=(2334) _q_resolveEntryAndCreateLegacyEngine_recursive(QFileSystemEntry&, QFileSystemMetaData&, QAbstractFileEngine*&, bool)
133 130
+1 65
cfi=(108)
cfn=(2336)
calls=13 -11 
* 1899
* 26
+1 39
cfi=(113)
cfn=(2340)
calls=13 +20 
* 195
* 117
+4 52
cfi=(72)
cfn=(2342)
calls=13 +92 
* 104
* 63
cfi=(72)
cfn=(2342)
calls=21 +92 
* 168
* 136
+1 155
cfi=(72)
cfn=(2344)
calls=31 870 
* 2883
* 31
+1 124
cfi=(114)
cfn=(2350)
calls=31 -94 
* 341
* 155
cfi=(114)
cfn=(2352)
calls=31 -59 
* 682
* 155
cfi=(114)
cfn=(2356)
calls=31 567 
* 310
* 62
+3 88
cfi=(114)
cfn=(2350)
calls=22 -97 
* 242
* 110
cfi=(114)
cfn=(2352)
calls=22 -62 
* 484
* 110
cfi=(114)
cfn=(2356)
calls=22 567 
* 220
* 44
+1 2
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 216
* 1
* 5
cfi=(55)
cfn=(2358)
calls=1 1222 
* 467589
* 2
+1 5
cfn=(2926) _q_checkEntry(QAbstractFileEngine*&, bool)
calls=1 -28 
* 14
* 2
-8 42
+3 18
+32 72
cfn=(3088)
calls=12 -68 
* 192
* 12
-40 36
cfi=(72)
cfn=(2230)
calls=12 1065 
* 1143
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
* 26
+41 65

fn=(2926)
119 7
+1 2
+8 1
+1 4

fn=(2330)
188 78
+1 65
cfi=(112)
cfn=(2332)
calls=13 57 
* 2601
+1 13
+2 78
cfn=(2334)
calls=13 -59 
* 478702
* 26
+2 65
cfi=(112)
cfn=(2928)
calls=13 57 
* 4355
* 13
+4 13
-9 39
cfi=(138)
cfn=(2930)
calls=13 57 
* 2235
+9 26
+1 52

fl=(76)
fn=(1218) QVector<void*>::QVector()
65 5
cfi=(73)
cfn=(1220) QTypedArrayData<void*>::sharedNull()
calls=1 240 
* 10
* 6

fn=(4118)
83 4296

fn=(4278) QVector<QObjectPrivate::ConnectionList>::reallocData(int, int, QFlags<QArrayData::AllocationOption>)
522 8
+2 6
cfi=(62)
cfn=(922)
calls=1 +99 
* 5
+1 3
+2 4
cfi=(65)
cfn=(1018)
calls=1 93 
* 51
* 1
+2 2
+1 6
+3 6
cfi=(73)
cfn=(4280) QTypedArrayData<QObjectPrivate::ConnectionList>::allocate(unsigned long, QFlags<QArrayData::AllocationOption>)
calls=1 211 
* 854
* 1
+1 3
+3 3
cfi=(65)
cfn=(4284)
calls=1 80 
* 46
* 4
cfi=(62)
cfn=(922)
calls=1 +86 
* 5
+2 3
cfi=(65)
cfn=(2162)
calls=1 87 
* 46
* 3
cfi=(62)
cfn=(922)
calls=1 +84 
* 5
+1 3
+2 5
cfi=(73)
cfn=(4286) QTypedArrayData<QObjectPrivate::ConnectionList>::begin(QObjectPrivate::ConnectionList*)
calls=1 202 
* 40
* 1
+1 10
cfi=(73)
cfn=(4290) QTypedArrayData<QObjectPrivate::ConnectionList>::end(QObjectPrivate::ConnectionList*)
calls=1 203 
* 46
* 2
+1 4
cfi=(73)
cfn=(4286)
calls=1 202 
* 48
* 1
+4 3
+12 5
+3 4
cfi=(73)
cfn=(4290)
calls=1 203 
* 54
* 6
cfn=(4292) QVector<QObjectPrivate::ConnectionList>::defaultConstruct(QObjectPrivate::ConnectionList*, QObjectPrivate::ConnectionList*)
calls=1 309 
* 136
+11 12
+15 5
+1 4
cfi=(65)
cfn=(1044)
calls=1 59 
* 51
* 3
+9 3
+3 4
cfi=(73)
cfn=(4288) QTypedArrayData<QObjectPrivate::ConnectionList>::data()
calls=1 199 
* 38
* 3
cfi=(62)
cfn=(922)
calls=1 +21 
* 5
+1 11
cfi=(62)
cfn=(922)
calls=1 +20 
* 5
+2 3
cfi=(73)
cfn=(4294) QTypedArrayData<QObjectPrivate::ConnectionList>::unsharableEmpty()
calls=1 253 
* 214
* 3
cfi=(62)
cfn=(922)
calls=1 +18 
* 5
+2 5
cfi=(73)
cfn=(4270) QTypedArrayData<QObjectPrivate::ConnectionList>::sharedNull()
calls=1 240 
* 10
* 6
cfi=(62)
cfn=(922)
calls=1 +16 
* 5
+1 9
cfi=(62)
cfn=(922)
calls=1 +15 
* 5
+1 6
cfi=(62)
cfn=(922)
calls=1 +14 
* 5
+1 5

fn=(1192)
65 5
cfi=(73)
cfn=(1194) QTypedArrayData<QEventLoop*>::sharedNull()
calls=1 240 
* 10
* 6

fn=(1198)
65 5
cfi=(73)
cfn=(1200) QTypedArrayData<QPostEvent>::sharedNull()
calls=1 240 
* 10
* 6

fn=(4276) QVector<QObjectPrivate::ConnectionList>::resize(int)
400 5
+3 5
+1 1
+2 3
+1 2
+1 4
cfi=(95)
cfn=(2122)
calls=1 111 
* 10
* 3
+4 6
cfn=(4278)
calls=1 522 
* 1858
+1 3

fn=(4462) QVector<int>::QVector()
65 5
cfi=(73)
cfn=(4464) QTypedArrayData<int>::sharedNull()
calls=1 240 
* 10
* 6

fn=(4516)
627 6
+2 12
+1 3
cfn=(4518) QVector<QEventLoop*>::isDetached() const
calls=1 102 
* 62
* 7
+1 3
+1 8
cfi=(95)
cfn=(2122)
calls=1 111 
* 10
+1 14
cfn=(4520) QVector<QEventLoop*>::reallocData(int, int, QFlags<QArrayData::AllocationOption>)
calls=1 522 
* 1695
+5 5
cfi=(73)
cfn=(4530) QTypedArrayData<QEventLoop*>::end(QEventLoop**)
calls=1 203 
* 46
* 4
cfi=(103)
cfn=(4532) std::remove_reference<QEventLoop*&>::type&& std::move<QEventLoop*&>(QEventLoop*&)
calls=1 101 
* 6
* 3
+8 5
+1 5

fn=(4304) QVector<QObjectPrivate::ConnectionList>::isDetached() const
102 160000016
cfi=(65)
cfn=(1018)
calls=20000002 -9 
* 960000096
* 60000006

fn=(3644)
69 12
-69 12
fi=(31)
cfi=(65)
cfn=(1044)
calls=3 59 
0 153
0 18

fn=(4472) QVector<int>::isDetached() const
102 8
cfi=(65)
cfn=(1018)
calls=1 -9 
* 51
* 3

fn=(4114)
65 5
cfi=(73)
cfn=(4116) QTypedArrayData<QList<bool (*)(void**)> >::sharedNull()
calls=1 240 
* 10
* 6

fn=(4470) QVector<int>::append(int const&)
627 6
+2 12
+1 3
cfn=(4472)
calls=1 102 
* 62
* 7
+1 3
+1 8
cfi=(95)
cfn=(2122)
calls=1 111 
* 10
+1 14
cfn=(4474) QVector<int>::reallocData(int, int, QFlags<QArrayData::AllocationOption>)
calls=1 522 
* 1695
+5 5
cfi=(73)
cfn=(4484) QTypedArrayData<int>::end(int*)
calls=1 203 
* 46
* 4
cfi=(103)
cfn=(4486) std::remove_reference<int&>::type&& std::move<int&>(int&)
calls=1 101 
* 6
* 3
+8 5
+1 5

fn=(5214)
65 5
cfi=(73)
cfn=(5216) QTypedArrayData<QMessagePattern::BacktraceParams>::sharedNull()
calls=1 240 
* 10
* 6

fn=(2938) QVector<QDateTime>::QVector()
65 45
cfi=(73)
cfn=(2940) QTypedArrayData<QDateTime>::sharedNull()
calls=9 240 
* 90
* 54

fn=(4454) QVector<QObjectUserData*>::QVector()
65 5
cfi=(73)
cfn=(4456) QTypedArrayData<QObjectUserData*>::sharedNull()
calls=1 240 
* 10
* 6

fn=(4474)
522 8
+2 6
cfi=(62)
cfn=(922)
calls=1 +99 
* 5
+1 3
+2 4
cfi=(65)
cfn=(1018)
calls=1 93 
* 51
* 1
+2 2
+1 6
+3 6
cfi=(73)
cfn=(4476) QTypedArrayData<int>::allocate(unsigned long, QFlags<QArrayData::AllocationOption>)
calls=1 211 
* 878
* 1
+1 3
+3 3
cfi=(65)
cfn=(4284)
calls=1 80 
* 46
* 4
cfi=(62)
cfn=(922)
calls=1 +86 
* 5
+2 3
cfi=(65)
cfn=(2162)
calls=1 87 
* 46
* 3
cfi=(62)
cfn=(922)
calls=1 +84 
* 5
+1 3
+2 5
cfi=(73)
cfn=(4478) QTypedArrayData<int>::begin(int*)
calls=1 202 
* 40
* 1
+1 10
cfi=(73)
cfn=(4478)
calls=1 202 
* 40
* 6
+1 4
cfi=(73)
cfn=(4478)
calls=1 202 
* 40
* 1
+8 10
cob=(3)
cfi=(3)
cfn=(1696)
calls=1 0 
* 13
* 1
+1 5
+3 5
+4 5
+14 12
+15 5
+1 4
cfi=(65)
cfn=(1044)
calls=1 59 
* 51
* 3
+9 3
+3 4
cfi=(73)
cfn=(4480) QTypedArrayData<int>::data()
calls=1 199 
* 30
* 3
cfi=(62)
cfn=(922)
calls=1 +21 
* 5
+1 11
cfi=(62)
cfn=(922)
calls=1 +20 
* 5
+2 3
cfi=(73)
cfn=(4482) QTypedArrayData<int>::unsharableEmpty()
calls=1 253 
* 214
* 3
cfi=(62)
cfn=(922)
calls=1 +18 
* 5
+2 5
cfi=(73)
cfn=(4464)
calls=1 240 
* 10
* 6
cfi=(62)
cfn=(922)
calls=1 +16 
* 5
+1 9
cfi=(62)
cfn=(922)
calls=1 +15 
* 5
+1 6
cfi=(62)
cfn=(922)
calls=1 +14 
* 5
+1 5

fn=(4496) QVector<QEventLoop*>::isEmpty() const
85 10

fn=(4518)
102 8
cfi=(65)
cfn=(1018)
calls=1 -9 
* 51
* 3

fn=(4854) QVector<QObjectPrivate::ConnectionList>::at(int) const
418 2680
+1 4288
cfi=(62)
cfn=(922)
calls=536 623 
* 2680
+1 2680
cfi=(73)
cfn=(4286)
calls=536 202 
* 25728
* 3752

fn=(5140)
355 7
+2 4
cfi=(65)
cfn=(2278)
calls=1 48 
* 50
* 2
+1 4
+15 7

fn=(3008) QVector<QDateTime>::~QVector()
69 36
-69 36
fi=(31)
cfi=(65)
cfn=(1044)
calls=9 59 
0 459
0 54

fn=(4268) QVector<QObjectPrivate::ConnectionList>::QVector()
65 5
cfi=(73)
cfn=(4270)
calls=1 240 
* 10
* 6

fn=(4458) QVector<QVariant>::QVector()
65 5
cfi=(73)
cfn=(4460) QTypedArrayData<QVariant>::sharedNull()
calls=1 240 
* 10
* 6

fn=(4756) QVector<QPostEvent>::size() const
83 16

fn=(2256)
65 30
cfi=(73)
cfn=(2258) QTypedArrayData<QLoggingRule>::sharedNull()
calls=6 240 
* 60
* 36

fn=(4274) QVector<QObjectPrivate::ConnectionList>::count() const
228 80004296

fn=(4292)
309 6
+3 15
+1 24
cfi=(133)
cfn=(2728)
calls=4 147 
* 28
* 16
cfi=(165) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qobject_p.h
cfn=(4272) QObjectPrivate::ConnectionList::ConnectionList()
calls=4 156 
* 40
-1 4
+6 3

fn=(4520)
522 8
+2 6
cfi=(62)
cfn=(922)
calls=1 +99 
* 5
+1 3
+2 4
cfi=(65)
cfn=(1018)
calls=1 93 
* 51
* 1
+2 2
+1 6
+3 6
cfi=(73)
cfn=(4522) QTypedArrayData<QEventLoop*>::allocate(unsigned long, QFlags<QArrayData::AllocationOption>)
calls=1 211 
* 878
* 1
+1 3
+3 3
cfi=(65)
cfn=(4284)
calls=1 80 
* 46
* 4
cfi=(62)
cfn=(922)
calls=1 +86 
* 5
+2 3
cfi=(65)
cfn=(2162)
calls=1 87 
* 46
* 3
cfi=(62)
cfn=(922)
calls=1 +84 
* 5
+1 3
+2 5
cfi=(73)
cfn=(4524) QTypedArrayData<QEventLoop*>::begin(QEventLoop**)
calls=1 202 
* 40
* 1
+1 10
cfi=(73)
cfn=(4524)
calls=1 202 
* 40
* 6
+1 4
cfi=(73)
cfn=(4524)
calls=1 202 
* 40
* 1
+8 10
cob=(3)
cfi=(3)
cfn=(1696)
calls=1 0 
* 13
* 1
+1 5
+3 5
+4 5
+14 12
+15 5
+1 4
cfi=(65)
cfn=(1044)
calls=1 59 
* 51
* 3
+9 3
+3 4
cfi=(73)
cfn=(4526) QTypedArrayData<QEventLoop*>::data()
calls=1 199 
* 30
* 3
cfi=(62)
cfn=(922)
calls=1 +21 
* 5
+1 11
cfi=(62)
cfn=(922)
calls=1 +20 
* 5
+2 3
cfi=(73)
cfn=(4528) QTypedArrayData<QEventLoop*>::unsharableEmpty()
calls=1 253 
* 214
* 3
cfi=(62)
cfn=(922)
calls=1 +18 
* 5
+2 5
cfi=(73)
cfn=(1194)
calls=1 240 
* 10
* 6
cfi=(62)
cfn=(922)
calls=1 +16 
* 5
+1 9
cfi=(62)
cfn=(922)
calls=1 +15 
* 5
+1 6
cfi=(62)
cfn=(922)
calls=1 +14 
* 5
+1 5

fn=(5142)
199 9
cfi=(73)
cfn=(5144) QTypedArrayData<QLoggingRule>::constBegin(QLoggingRule const*) const
calls=1 +7 
* 40
* 2

fn=(4298) QVector<QObjectPrivate::ConnectionList>::operator[](int)
426 50000005
+1 80000008
cfi=(62)
cfn=(922)
calls=10000001 623 
* 50000005
+1 30000003
cfn=(4300) QVector<QObjectPrivate::ConnectionList>::data()
calls=10000001 123 
* 2050000205
* 70000007

fn=(3634) QVector<QLoggingRule>::QVector(QVector<QLoggingRule>&&)
72 10
cfi=(73)
cfn=(2258)
calls=1 240 
* 10
* 6

fn=(3636) QVector<QLoggingRule>::swap(QVector<QLoggingRule>&)
76 10
cfi=(62)
cfn=(3638)
calls=1 860 
* 56
* 3

fn=(3742)
85 30

fn=(4300)
123 70000007
cfn=(4302) QVector<QObjectPrivate::ConnectionList>::detach()
calls=10000001 376 
* 1430000143
* 50000005
cfi=(73)
cfn=(4286)
calls=10000001 +79 
* 480000048
* 20000002

fn=(4302)
376 40000004
+2 30000003
cfn=(4304)
calls=10000001 102 
* 590000059
* 30000003
+8 30000003
cfn=(4304)
calls=10000001 102 
* 590000059
* 40000004
cfi=(62)
cfn=(922)
calls=10000001 623 
* 50000005
+1 30000003

fn=(3630)
73 6
+1 3
cfi=(103)
cfn=(3632) std::remove_reference<QVector<QLoggingRule>&>::type&& std::move<QVector<QLoggingRule>&>(QVector<QLoggingRule>&)
calls=1 +27 
* 6
* 5
cfn=(3634)
calls=1 -2 
* 26
* 5
cfn=(3636)
calls=1 +2 
* 69
* 4
cfn=(3644)
calls=1 -5 
* 65
* 5

fn=(5150)
203 9
cfi=(73)
cfn=(5152) QTypedArrayData<QLoggingRule>::constEnd(QLoggingRule const*) const
calls=1 +4 
* 49
* 2

fl=(47)
fn=(796)
70 5
cfn=(798) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 789
* 2

fn=(798)
70 9
fi=(48)
+66 2
cfn=(802)
calls=1 -5 
* 775
fe=(47)
-66 3

fl=(86)
fn=(2490) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}::operator()(int) const
242 12075

fn=(3702)
10591 6
+1 7
cfn=(2482) qt_from_latin1(unsigned short*, char const*, unsigned long)
calls=1 207 
* 641
+1 3

fn=(5236) QString::compare_helper(QChar const*, int, QLatin1String, Qt::CaseSensitivity)
5413 40
+1 8
+1 24
+1 12
cfi=(72)
cfn=(2880)
calls=4 91 
* 28
* 4
+2 8
+3 8
+1 12
cfi=(72)
cfn=(2524)
calls=4 92 
* 28
* 24
cfn=(5238) ucstrcmp(QChar const*, int, unsigned char const*, int)
calls=4 646 
* 1420
* 4
+4 8

fn=(2480) QString::fromLatin1_helper(char const*, int)
4622 135
+2 54
+2 162
+3 54
+2 108
cfi=(95)
cfn=(2122)
calls=27 111 
* 270
* 189
cfi=(73)
cfn=(2212) QTypedArrayData<unsigned short>::allocate(unsigned long, QFlags<QArrayData::AllocationOption>)
calls=27 211 
* 20024
* 27
+1 81
+1 81
+1 81
cfi=(73)
cfn=(2214) QTypedArrayData<unsigned short>::data()
calls=27 199 
* 1026
* 162
+1 81
cfi=(73)
cfn=(2214)
calls=27 199 
* 1026
* 27
+2 189
cfn=(2482)
calls=27 207 
* 34538
+2 27
+1 54

fn=(2492) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<14u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
165 1071
+10 238
+1 4
+2 585
cfn=(2488) void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}::operator()(int) const
calls=117 +16 
* 3978
* 117
+1 234
+5 1521
cfn=(2494) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<13u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
calls=117 -19 
* 25602
* 117
+1 357

fn=(2498) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<11u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
165 1053
+10 234
+1 200
+2 85
cfn=(2488)
calls=17 +16 
* 578
* 17
+1 34
+5 221
cfn=(2500) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<10u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
calls=17 -19 
* 6432
* 17
+1 351

fn=(2504) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<8u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
165 153
+10 34
+1 4
+2 75
cfn=(2488)
calls=15 +16 
* 510
* 15
+1 30
+5 195
cfn=(2506) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<7u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
calls=15 -19 
* 2970
* 15
+1 51

fn=(2510) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<5u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
165 108
+10 24
+1 2
+2 55
cfn=(2488)
calls=11 +16 
* 374
* 11
+1 22
+5 143
cfn=(2512) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<4u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
calls=11 -19 
* 386
* 11
+1 36

fn=(2560) findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#1}::operator()(int) const
689 3213

fn=(2564) int (anonymous namespace)::UnrollTailLoop<5u>::exec<int, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#1}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#2}>(int, {lambda(int)#2}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#1}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#2}, int)
165 450
+10 90
+3 180
cfn=(2560)
calls=45 689 
* 765
* 45
+1 90
+1 36
cfn=(2572) findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#2}::operator()(int) const
calls=9 690 
* 162
* 27
+1 27
+3 576
cfn=(2566) int (anonymous namespace)::UnrollTailLoop<4u>::exec<int, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#1}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#2}>(int, {lambda(int)#2}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#1}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#2}, int)
calls=36 -19 
* 2628
* 36
+1 135

fn=(2744)
1873 25
+1 15
cfi=(72)
cfn=(2746) QString::isDetached() const
calls=5 886 
* 310
* 25
+7 25
cfn=(2748) QString::QString(QChar)
calls=5 1575 
* 3925
* 25
cfi=(72)
cfn=(2234)
calls=5 227 
* 345
* 15
cfi=(72)
cfn=(2230)
calls=5 1065 
* 325
+2 5
+1 10

fn=(2878) qt_starts_with(QChar const*, int, QLatin1String, Qt::CaseSensitivity)
10050 121
+1 22
+2 22
+2 33
cfi=(72)
cfn=(2524)
calls=11 92 
* 77
* 11
+1 33
+1 2
+1 20
+1 30
cfi=(72)
cfn=(2880)
calls=10 91 
* 70
* 10
+1 20
+1 60
cfn=(2882) ucstrncmp(QChar const*, unsigned char const*, int)
calls=10 531 
* 2081
* 30
+7 44

fn=(5238)
646 28
+1 20
cfi=(62)
cfn=(3338)
calls=4 545 
* 52
* 8
+1 24
cfn=(2882)
calls=4 531 
* 1248
* 4
+1 28
+1 8

fn=(5256) void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})
188 9
+6 10
cfn=(5258) qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<15u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})::{lambda(int)#2}, int)
calls=1 -29 
* 176
* 1
+1 3

fn=(5258)
165 9
+10 2
+3 5
cfn=(5260) void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})::{lambda(int)#1}::operator()(int) const
calls=1 +16 
* 44
* 1
+1 2
+5 13
cfn=(5264) qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<14u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})::{lambda(int)#2}, int)
calls=1 -19 
* 96
* 1
+1 3

fn=(5266) qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<13u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1})::{lambda(int)#2}, int)
165 9
+10 2
+1 2
+9 3

fn=(2522)
2699 470
+1 282
cfi=(72)
cfn=(2524)
calls=47 92 
* 329
* 188
+1 86
+2 12
cfi=(72)
cfn=(2524)
calls=4 92 
* 28
* 16
+3 12
cfi=(72)
cfn=(2342)
calls=4 231 
* 32
* 16
cfi=(72)
cfn=(2548)
calls=4 878 
* 192
* 28
cfn=(5236)
calls=4 5413 
* 1628
* 8
+1 188

fn=(2572)
690 486

fn=(2882)
531 98
+1 28
+1 84
fi=(102) /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include/emmintrin.h
755 14
fe=(86)
536 14
+1 14
+4 98
+37 98
+2 20
fi=(206) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/global/qendian.h
88 5
+4 15
+3 25
fi=(102)
587 20
fe=(86)
-7 25
fi=(102)
989 15
fe=(86)
581 5
+2 25
fi=(102)
698 10
fe=(86)
583 25
fi=(102)
1300 15
fe=(86)
584 15
fi=(102)
1392 10
fe=(86)
585 10
+1 15
+2 2
fi=(207) /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include/ia32intrin.h
33 2
fe=(86)
588 1
+1 23
+4 4
+9 12
+1 8
+3 24
+1 80
cfn=(2884) int (anonymous namespace)::UnrollTailLoop<7u>::exec<int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}>(int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}, int)
calls=4 165 
* 772
-5 27
+1 18
+3 54
+1 180
cfn=(2884)
calls=9 165 
* 1364
* 13
+12 42

fn=(3054) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<3u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
165 18
+10 4
+1 2
+2 5
cfn=(2488)
calls=1 +16 
* 34
* 1
+1 2
+5 13
cfn=(5220) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<2u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
calls=1 -19 
* 16
* 1
+1 6

fn=(2534)
1791 3460
+1 2768
cfi=(65)
cfn=(2278)
calls=692 48 
* 55976
+1 2768
cfi=(65)
cfn=(1044)
calls=692 59 
* 35688
* 2076
+2 2768
+1 692
+1 1384

fn=(2552) QString::indexOf(QChar, int, Qt::CaseSensitivity) const
3124 504
+1 189
cfi=(72)
cfn=(2532)
calls=63 866 
* 504
* 252
cfi=(72)
cfn=(2222) QString::unicode() const
calls=63 876 
* 3024
* 567
cfn=(2554) findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)
calls=63 662 
* 17793
+1 252

fn=(2562) int (anonymous namespace)::UnrollTailLoop<6u>::exec<int, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#1}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#2}>(int, {lambda(int)#2}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#1}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#2}, int)
165 450
+10 90
+3 180
cfn=(2560)
calls=45 689 
* 765
* 45
+1 90
+5 720
cfn=(2564)
calls=45 -19 
* 5247
* 45
+1 135

fn=(2848)
4344 16
+2 16
cfi=(96)
cfn=(2850)
calls=2 150 
* 92
* 16
+11 10
cfi=(73)
cfn=(2214)
calls=2 199 
* 76
* 20
cfn=(2852)
calls=2 1506 
* 1628
* 2
+4 10

fn=(3076) replaceArgEscapes(QString const&, ArgEscapeData const&, int, QString const&, QString const&, QChar)
7225 11
+1 3
cfi=(72)
cfn=(2222)
calls=1 876 
* 48
* 1
+1 3
cfi=(72)
cfn=(2532)
calls=1 866 
* 8
* 5
+2 3
cfi=(62)
cfn=(3078)
calls=1 520 
* 10
* 1
+1 3
cfi=(72)
cfn=(2532)
calls=1 866 
* 8
* 1
+1 4
+1 6
+1 3
cfi=(72)
cfn=(2532)
calls=1 866 
* 8
* 6
cfi=(62)
cfn=(3080)
calls=1 547 
* 14
* 2
-1 1
+2 2
+1 3
cfi=(72)
cfn=(2532)
calls=1 866 
* 8
* 6
cfi=(62)
cfn=(3080)
calls=1 547 
* 13
* 4
+2 6
cfn=(2210)
calls=1 1557 
* 737
+1 3
cfi=(72)
cfn=(2222)
calls=1 876 
* 48
* 1
+2 2
+1 2
+1 1
+1 6
+5 2
+2 3
cfi=(114)
cfn=(2570)
calls=1 420 
* 7
* 18
cfi=(114)
cfn=(2570)
calls=6 420 
* 42
* 28
+1 6
-1 6
+3 4
+2 1
+1 3
cfi=(114)
cfn=(2570)
calls=1 420 
* 7
* 4
+5 3
cfi=(114)
cfn=(3062)
calls=1 406 
* 55
* 1
+1 2
+1 8
cfi=(114)
cfn=(3062)
calls=1 406 
* 55
* 5
+6 4
+5 1
+2 10
cob=(3)
cfi=(3)
cfn=(1696)
calls=1 0 
* 12
* 1
+1 5
+3 2
+3 3
cfi=(72)
cfn=(2532)
calls=1 866 
* 8
* 6
cfi=(62)
cfn=(3080)
calls=1 547 
* 14
* 4
cfi=(72)
cfn=(2532)
calls=1 866 
* 8
* 3
+2 3
+5 2
+5 3
cfi=(72)
cfn=(2532)
calls=1 866 
* 8
* 5
cfi=(72)
cfn=(2222)
calls=1 876 
* 48
* 6
cob=(3)
cfi=(3)
cfn=(1696)
calls=1 0 
* 12
* 1
+1 3
cfi=(72)
cfn=(2532)
calls=1 866 
* 8
* 3
+3 3
+5 7
+1 10
cob=(3)
cfi=(3)
cfn=(1696)
calls=1 0 
* 12
* 1
+1 5
+1 11
cfi=(62)
cfn=(922)
calls=1 623 
* 5
+1 2
-65 1
+69 8
cfi=(62)
cfn=(922)
calls=1 623 
* 5
+2 1
+1 6

fn=(3344)
2036 4452
+1 1908
cfi=(73)
cfn=(1158) QTypedArrayData<unsigned short>::sharedNull()
calls=636 240 
* 6360
* 2544
+1 1908
cfi=(73)
cfn=(1158)
calls=636 240 
* 6360
* 2544
+1 3170
cfn=(2534)
calls=634 1791 
* 98904
* 634
+2 8
cfi=(65)
cfn=(1018)
calls=2 93 
* 99
* 25
+1 13
cfn=(3336) QString::reallocData(unsigned int, bool)
calls=1 1739 
* 1343
+1 18
cfi=(73)
cfn=(2214)
calls=2 199 
* 76
* 10
cfi=(73)
cfn=(2214)
calls=2 199 
* 76
* 22
cob=(3)
cfi=(3)
cfn=(1696)
calls=2 0 
* 28
* 2
+1 20
+1 8
cfi=(73)
cfn=(2214)
calls=2 199 
* 76
* 16
+3 2
+1 10
-1 634
+1 3170

fn=(5252) QString::toLatin1_helper(QChar const*, int)
4485 7
+1 6
cfi=(67)
cfn=(3134)
calls=1 1522 
* 736
+4 3
cfi=(98)
cfn=(2472)
calls=1 489 
* 48
* 1
+1 5
cfn=(5254) qt_to_latin1(unsigned char*, unsigned short const*, int)
calls=1 312 
* 248
+1 1
+1 5

fn=(5260)
194 20
cfn=(5262) qt_to_latin1(unsigned char*, unsigned short const*, int)::{lambda(int)#1}::operator()(int) const
calls=2 335 
* 62
* 6

fn=(5368)
4757 3204
+1 1068
+3 1602
cfi=(62)
cfn=(922)
calls=534 623 
* 2670
+1 3204
cfi=(101)
cfn=(5370) QUtf8::convertToUnicode(char const*, int)
calls=534 245 
* 980541
+1 1602

fn=(1468) QString::fromLocal8Bit_helper(char const*, int)
4687 30
+1 10
+2 30
+5 10
+2 5
cfi=(87)
cfn=(1470)
calls=5 678 
* 45299
* 5
+1 10
+1 35
cfi=(100)
cfn=(2204)
calls=5 102 
* 9069
* 5
+3 15

fn=(2210)
1557 3378
+2 2252
cfi=(95)
cfn=(2122)
calls=563 111 
* 5630
* 3941
cfi=(73)
cfn=(2212)
calls=563 211 
* 366032
* 1689
+1 2252
+1 2252
+1 2252
cfi=(73)
cfn=(2214)
calls=563 199 
* 21394
* 3378
+1 1689

fn=(2494)
165 1053
+10 234
+3 585
cfn=(2488)
calls=117 +16 
* 3978
* 117
+1 234
+5 1521
cfn=(2496) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<12u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
calls=117 -19 
* 17412
* 117
+1 351

fn=(2500)
165 153
+10 34
+3 85
cfn=(2488)
calls=17 +16 
* 578
* 17
+1 34
+5 221
cfn=(2502) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<9u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
calls=17 -19 
* 5242
* 17
+1 51

fn=(2506)
165 135
+10 30
+1 4
+2 65
cfn=(2488)
calls=13 +16 
* 442
* 13
+1 26
+5 169
cfn=(2508) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<6u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
calls=13 -19 
* 2028
* 13
+1 45

fn=(2512)
165 99
+10 22
+1 18
+2 10
cfn=(2488)
calls=2 +16 
* 68
* 2
+1 4
+5 26
cfn=(3054)
calls=2 -19 
* 102
* 2
+1 33

fn=(2748)
1575 30
+2 20
cfi=(95)
cfn=(2122)
calls=5 111 
* 50
* 20
cfi=(73)
cfn=(2212)
calls=5 211 
* 3240
* 15
+1 20
+1 15
+1 20
cfi=(73)
cfn=(2214)
calls=5 199 
* 190
* 20
cfi=(114)
cfn=(2556)
calls=5 421 
* 30
* 10
+1 20
cfi=(73)
cfn=(2214)
calls=5 199 
* 190
* 10
+1 25

fn=(2852)
1506 742
+2 212
+3 212
+5 212
+3 424
cfi=(95)
cfn=(2122)
calls=106 111 
* 1060
* 742
cfi=(73)
cfn=(2212)
calls=106 211 
* 69118
* 318
+1 424
+1 424
+1 742
cfi=(73)
cfn=(2214)
calls=106 199 
* 4028
* 636
cob=(3)
cfi=(3)
cfn=(1696)
calls=106 0 
* 1352
* 106
+1 424
cfi=(73)
cfn=(2214)
calls=106 199 
* 4028
* 636
+3 530

fn=(2884)
165 130
+10 26
+1 2
+2 48
cfn=(2886) ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}::operator()(int) const
calls=12 606 
* 276
* 36
+1 24
+1 4
cfn=(2886)
calls=1 606 
* 23
* 3
+1 3
+3 176
cfn=(2888) int (anonymous namespace)::UnrollTailLoop<6u>::exec<int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}>(int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}, int)
calls=11 -19 
* 1335
* 11
+1 39

fn=(3126) QString::toLocal8Bit_helper(QChar const*, int)
4569 3834
+2 639
cfi=(87)
cfn=(1470)
calls=639 678 
* 90738
* 639
+1 1278
+1 4473
cfi=(100)
cfn=(3128)
calls=639 104 
* 133137059
* 639
+3 1917

fn=(3220) QString::lastIndexOf(QChar, int, Qt::CaseSensitivity) const
3277 16
+1 6
cfi=(72)
cfn=(2342)
calls=2 231 
* 16
* 8
cfi=(72)
cfn=(2222)
calls=2 876 
* 96
* 18
cfn=(3222) qt_last_index_of(QChar const*, int, QChar, int, Qt::CaseSensitivity)
calls=2 9945 
* 396
+1 8

fn=(4994) QString::append(QChar const*, int)
2058 4438
+1 2536
+1 2536
cfi=(65)
cfn=(1018)
calls=634 93 
* 32334
* 3804
+1 6974
cfn=(3336)
calls=634 1739 
* 128245397
+1 4438
cfi=(73)
cfn=(2214)
calls=634 199 
* 19020
* 7608
cob=(3)
cfi=(3)
cfn=(1696)
calls=634 0 
* 11884
* 634
+1 5072
+1 2536
cfi=(73)
cfn=(2214)
calls=634 199 
* 24092
* 5072
+2 634
+1 2536

fn=(5020) QString::append(QLatin1String)
2075 900
+1 300
cfi=(72)
cfn=(2880)
calls=100 91 
* 700
* 100
+1 200
+1 300
cfi=(72)
cfn=(2524)
calls=100 92 
* 700
* 100
+1 400
cfi=(65)
cfn=(1018)
calls=100 93 
* 4800
* 1700
+2 400
cfi=(73)
cfn=(2214)
calls=100 199 
* 3800
* 800
+1 700
cfn=(2482)
calls=100 207 
* 36100
+1 600
+1 800
+2 100
+1 200

fn=(5220)
165 9
+10 2
+1 2
+9 3

fn=(5246) int (anonymous namespace)::UnrollTailLoop<1u>::exec<int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}>(int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}, int)
165 10
+10 2
+1 2
+9 3

fn=(2224)
4971 2785
+1 2785
+1 115
cfn=(2226) QString::resize(int)
calls=23 1671 
* 3220
+1 1671

fn=(2876)
4384 121
+1 33
cfi=(72)
cfn=(2342)
calls=11 231 
* 88
* 44
cfi=(72)
cfn=(2778)
calls=11 775 
* 264
* 55
cfi=(72)
cfn=(2222)
calls=11 876 
* 528
* 88
cfn=(2878)
calls=11 10050 
* 2686
+1 44

fn=(2886)
606 805

fn=(3336)
1739 5805
+1 1290
+1 1290
+2 3225
cfi=(67)
cfn=(1028)
calls=645 126 
* 47085
* 1935
+3 2580
cfi=(65)
cfn=(1018)
calls=645 93 
* 32883
* 3886
+1 7051
cfi=(95)
cfn=(2130)
calls=641 52 
* 6410
* 3205
cfi=(95)
cfn=(2132)
calls=641 113 
* 13461
+1 3205
cfi=(73)
cfn=(2212)
calls=641 211 
* 127974549
* 641
+1 1923
+1 7051
cfi=(62)
cfn=(3338)
calls=641 545 
* 8333
* 1282
+1 5128
cfi=(73)
cfn=(2214)
calls=641 199 
* 19246
* 2564
cfi=(73)
cfn=(2214)
calls=641 199 
* 19246
* 2564
cob=(3)
cfi=(3)
cfn=(1696)
calls=641 0 
* 8365
* 641
+1 1923
cfi=(73)
cfn=(2214)
calls=641 199 
* 19246
* 4487
+1 2564
cfi=(65)
cfn=(1044)
calls=641 59 
* 32757
* 1923
+2 1923
+8 641
-6 32
cob=(3)
cfi=(3)
cfn=(3156)
calls=4 0 
* 1568
* 4
* 4
+1 12
+1 12
+1 40
+1 12
+2 3870

fn=(5244) int (anonymous namespace)::UnrollTailLoop<2u>::exec<int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}>(int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}, int)
165 10
+10 2
+3 4
cfn=(2886)
calls=1 606 
* 23
* 3
+1 2
+5 16
cfn=(5246)
calls=1 -19 
* 17
* 1
+1 3

fn=(5262)
335 62

fn=(2568) int (anonymous namespace)::UnrollTailLoop<3u>::exec<int, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#1}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#2}>(int, {lambda(int)#2}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#1}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#2}, int)
165 360
+10 72
+1 72
+9 108

fn=(2874)
4469 5168
+2 646
-1 1938
+1 2584
+1 2584
cfi=(73)
cfn=(2214)
calls=646 199 
* 24548
* 9044
cfi=(114)
cfn=(2348)
calls=646 76 
* 7106
-1 646
+1 3230
cfi=(114)
cfn=(2356)
calls=646 567 
* 6460
-1 2584
+1 8
+2 40
-2 638
+2 3190

fn=(2888)
165 110
+10 22
+3 44
cfn=(2886)
calls=11 606 
* 253
* 33
+1 22
+1 8
cfn=(2886)
calls=2 606 
* 46
* 6
+1 6
+3 144
cfn=(5234) int (anonymous namespace)::UnrollTailLoop<5u>::exec<int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}>(int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}, int)
calls=9 -19 
* 599
* 9
+1 33

fn=(5028) QString::chop(int)
4992 3170
+1 1268
+1 5706
cfn=(2226)
calls=634 1671 
* 88760
+1 1902

fn=(5242) int (anonymous namespace)::UnrollTailLoop<3u>::exec<int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}>(int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}, int)
165 10
+10 2
+3 4
cfn=(2886)
calls=1 606 
* 23
* 3
+1 2
+5 16
cfn=(5244)
calls=1 -19 
* 81
* 1
+1 3

fn=(5264)
165 9
+10 2
+3 5
cfn=(5260)
calls=1 +16 
* 44
* 1
+1 2
+5 13
cfn=(5266)
calls=1 -19 
* 16
* 1
+1 3

fn=(2482)
207 896
+6 512
+1 128
+3 2514
+1 1164
fi=(102)
698 582
fe=(86)
218 2910
fi=(102)
599 2619
fe=(86)
226 1455
fi=(102)
989 873
fe=(86)
229 291
+1 2037
fi=(102)
716 2037
965 873
fe=(86)
233 291
+1 2328
fi=(102)
716 873
fe=(86)
217 582
+21 128
+1 384
+1 256
+2 1792
cfn=(2484) void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})
calls=128 -54 
* 45242
+12 512

fn=(2484)
188 1152
+6 1280
cfn=(2486) qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1} (anonymous namespace)::UnrollTailLoop<15u>::exec<int, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#1}, void (anonymous namespace)::UnrollTailLoop<15u>::exec<{lambda(int)#1}>(int, qt_from_latin1(unsigned short*, char const*, unsigned long)::{lambda(int)#1})::{lambda(int)#2}, int)
calls=128 -29 
* 42298
* 128
+1 384

fn=(2486)
165 1152
+10 256
+1 18
+2 595
cfn=(2488)
calls=119 +16 
* 4046
* 119
+1 238
+5 1547
cfn=(2492)
calls=119 -19 
* 33824
* 119
+1 384

fn=(2496)
165 1053
+10 234
+3 585
cfn=(2488)
calls=117 +16 
* 3978
* 117
+1 234
+5 1521
cfn=(2498)
calls=117 -19 
* 9222
* 117
+1 351

fn=(2502)
165 153
+10 34
+3 85
cfn=(2488)
calls=17 +16 
* 578
* 17
+1 34
+5 221
cfn=(2504)
calls=17 -19 
* 4052
* 17
+1 51

fn=(2508)
165 117
+10 26
+1 2
+2 60
cfn=(2488)
calls=12 +16 
* 408
* 12
+1 24
+5 156
cfn=(2510)
calls=12 -19 
* 1172
* 12
+1 39

fn=(2554)
662 756
+1 126
+1 189
cfi=(114)
cfn=(2556)
calls=63 421 
* 378
* 126
+1 126
+2 189
+1 378
+1 378
+1 126
+2 819
fi=(102)
-73 567
fe=(86)
+73 63
+3 378
+13 567
+2 567
cfn=(2558) int (anonymous namespace)::UnrollTailLoop<7u>::exec<int, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#1}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#2}>(int, {lambda(int)#2}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#1}, findChar(QChar const*, int, QChar, int, Qt::CaseSensitivity)::{lambda(int)#2}, int)
calls=63 165 
* 11493
* 126
+16 441

fn=(2558)
165 630
+10 126
+3 252
cfn=(2560)
calls=63 689 
* 1071
* 63
+1 126
+1 72
cfn=(2572)
calls=18 690 
* 324
* 54
+1 54
+3 720
cfn=(2562)
calls=45 -19 
* 7767
* 45
+1 189

fn=(3058) QString::arg(long long, int, int, QChar) const
7551 10
+1 3
cfn=(3060) findArgEscapes(QString const&)
calls=1 7162 
* 505
* 2
+2 3
+5 1
+1 4
cfi=(114)
cfn=(2350)
calls=1 47 
* 11
* 5
cfi=(114)
cfn=(2352)
calls=1 82 
* 22
* 5
cfi=(114)
cfn=(2356)
calls=1 567 
* 10
* 2
+3 3
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
+1 4
+1 1
cfi=(116)
cfn=(3066)
calls=1 655 
* 14
* 14
cfi=(116)
cfn=(3068)
calls=1 2877 
* 1370
* 6
cfi=(72)
cfn=(2234)
calls=1 227 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
+2 3
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
+1 3
+7 11
cfn=(3076)
calls=1 7225 
* 1511
* 1
-8 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
-4 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
* 1
+13 4

fn=(3060)
7162 4
+1 3
cfi=(72)
cfn=(2222)
calls=1 876 
* 48
* 1
+1 3
cfi=(72)
cfn=(2532)
calls=1 866 
* 8
* 5
+4 1
+1 1
+1 1
+1 1
+2 2
+1 6
+1 69
cfi=(114)
cfn=(2570)
calls=11 420 
* 77
* 68
+1 10
-1 10
+3 6
+2 2
+1 6
+3 1
+1 3
cfi=(114)
cfn=(2570)
calls=1 420 
* 7
* 4
+6 3
cfi=(114)
cfn=(3062)
calls=1 406 
* 55
* 1
+1 2
+3 1
+2 3
+1 3
cfi=(114)
cfn=(3062)
calls=1 406 
* 55
* 1
+1 2
+6 3
+3 3
+1 2
+1 1
+1 1
+1 1
+3 3
+1 2
+2 10
-39 2
+41 2
+1 2

fn=(3530) QString::trimmed_helper(QString const&)
4896 5
+1 5
cfi=(163) /home/tsenyk/qt5/qt5/qtbase/src/corelib/tools/qstringalgorithms_p.h
cfn=(3532) QStringAlgorithms<QString const>::trimmed_helper(QString const&)
calls=1 96 
* 469
+1 3

fn=(5240) int (anonymous namespace)::UnrollTailLoop<4u>::exec<int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}>(int, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, ucstrncmp(QChar const*, unsigned char const*, int)::{lambda(int)#1}, {lambda(int)#1}, int)
165 20
+10 4
+1 2
+2 4
cfn=(2886)
calls=1 606 
* 23
* 3
+1 2
+5 16
cfn=(5242)
calls=1 -19 
* 145
* 1
+1 6

fn=(5250) QString::toLatin1_helper(QString const&)
4477 6
+1 3
cfi=(72)
cfn=(2778)
calls=1 775 
* 24
* 5
+3 3
cfi=(72)
cfn=(2532)
calls=1 866 
* 8
* 4
cfi=(72)
cfn=(2216)
calls=1 882 
* 48
* 6
cfn=(5252)
calls=1 +4 
* 1060
+1 5

fn=(5254)
312 9
+2 5
+1 1
+3 6
+12 7
+1 2
+1 3
+3 10
cfn=(5256)
calls=1 188 
* 199
+34 6

fn=(2226)
1671 3285
+1 1314
+3 5256
+5 2628
cfi=(65)
cfn=(1018)
calls=657 93 
* 31536
* 8541
+2 3942
+1 2628
+1 2628
cfi=(73)
cfn=(2214)
calls=657 199 
* 24966
* 3942
+2 1314

fn=(2488)
194 5750
cfn=(2490)
calls=575 +48 
* 12075
* 1725

fn=(2566)
165 360
+10 72
+3 144
cfn=(2560)
calls=36 689 
* 612
* 36
+1 72
+5 576
cfn=(2568)
calls=36 -19 
* 612
* 36
+1 108

fn=(2846)
4395 48
+2 6
-1 18
+1 24
+1 24
cfi=(73)
cfn=(2214)
calls=6 199 
* 228
* 36
cfi=(114)
cfn=(2348)
calls=6 76 
* 66
-1 6
+1 30
cfi=(114)
cfn=(2356)
calls=6 567 
* 60
-1 24
+1 6
+2 30

fn=(3222)
9945 16
+1 6
cfi=(114)
cfn=(2556)
calls=2 421 
* 12
* 4
+1 4
+1 4
+1 8
+2 4
+1 4
+1 12
+1 4
+1 102
+1 136
+1 12
-2 64
+13 4

fn=(3224) QString::left(int) const
4302 12
+1 14
+2 8
cfi=(73)
cfn=(2214)
calls=2 199 
* 76
* 12
cfn=(2852)
calls=2 1506 
* 1940
+1 6

fn=(5008)
2121 4674
+1 3116
cfi=(65)
cfn=(1018)
calls=779 93 
* 37407
* 11644
+1 81
cfn=(3336)
calls=9 1739 
* 7747
+1 3116
cfi=(73)
cfn=(2214)
calls=779 199 
* 29562
* 9348
cfi=(114)
cfn=(2556)
calls=779 421 
* 4674
* 1558
+1 3116
cfi=(73)
cfn=(2214)
calls=779 199 
* 29602
* 6232
+1 779
+1 3116

fn=(5234)
165 90
+10 18
+1 10
+2 16
cfn=(2886)
calls=4 606 
* 92
* 12
+1 8
+1 8
cfn=(2886)
calls=2 606 
* 46
* 6
+1 6
+3 32
cfn=(5240)
calls=2 -19 
* 226
* 2
+1 27

fl=(120)
fn=(2442) QListSpecialMethods<QString>::QListSpecialMethods()
57 150

fn=(2438)
97 56
cfi=(64)
cfn=(2440)
calls=8 +44 
* 152
* 24

fn=(3036)
93 77
cfi=(64)
cfn=(2798)
calls=11 814 
* 2726
* 33

fn=(2800) QListSpecialMethods<QString>::~QListSpecialMethods()
62 150

fn=(3288) QStringList::QStringList(QString const&)
98 18
cfi=(64)
cfn=(2440)
calls=2 +43 
* 38
* 10
cfi=(64)
cfn=(3290)
calls=2 569 
* 1671
* 10

fn=(3298)
93 30
cfi=(64)
cfn=(2784) QList<QString>::operator=(QList<QString>&&)
calls=3 +55 
* 603
* 9

fn=(3250) QStringList::QStringList(QStringList const&)
93 20
cfi=(64)
cfn=(3252) QList<QString>::QList(QList<QString> const&)
calls=2 796 
* 148
* 6

fl=(205) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qdebug.h
fn=(5344) QDebug::Stream::~Stream()
55 5072
cfi=(72)
cfn=(2230)
calls=634 1065 
* 710186855
* 1902
cfi=(193)
cfn=(5346) QTextStream::~QTextStream()
calls=634 1144 
* 772653
* 1902

fl=(177)
fn=(4232) QTimer::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)
92 80000008
+1 20000002
+11 20000002
+1 30000003
+1 30000003
+3 160000016
+1 20000002
+1 10000001
+32 30000003

fn=(4848)
200 2144
+1 3216
cfi=(53)
cfn=(4550) QMetaObject::activate(QObject*, QMetaObject const*, int, void**)
calls=536 3594 
* 116752239484
+1 1605

fl=(159)
fn=(3496)
66 12
fi=(160)
* 12
cfi=(62)
cfn=(2832)
calls=3 1014 
* 48
* 6
fe=(159)

fl=(191) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/kernel/qobject_impl.h
fn=(4878) QtPrivate::QSlotObjectBase::destroyIfLastRef()
120 80002136
0 60001602
fi=(31)
cfi=(35)
cfn=(1364)
calls=20000534 128 
0 640017088
0 140001602
fi=(31)
cob=(19)
cfi=(70)
cfn=(4870)
calls=10000000 0 
0 1160000000
0 60001602

fn=(4862) QtPrivate::QSlotObjectBase::ref()
119 70003738
cfi=(35)
cfn=(1010)
calls=10000534 +8 
* 290015486
* 30001602

fn=(4868) QtPrivate::QSlotObjectBase::call(QObject*, void**)
124 140007476
cob=(19)
cfi=(70)
cfn=(5362)
calls=534 0 
* 1107645136
cob=(19)
cfi=(70)
cfn=(4870)
calls=10000000 0 
* 8741608325
* 30001602

fl=(41)
fn=(1178) get_thread_data()
182 8385
+2 2795
cob=(1)
cfi=(1)
cfn=(1184)
calls=2794 0 
* 30734
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 3037
* 2799
* 2795
+5 5590

fn=(946)
413 1084
+2 542
cob=(5)
cfi=(5)
cfn=(952)
calls=541 0 
* 1082
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
* 1175
* 546
* 1084
cfn=(954) QtPrivate::QEnableIf<QTypeInfo<unsigned long>::isIntegral, void*>::Type to_HANDLE<unsigned long>(unsigned long)
calls=542 209 
* 3252
+1 1084

fn=(1230) set_thread_data(QThreadData*)
192 5
+2 1
cob=(1)
cfi=(1)
cfn=(1184)
calls=1 0 
* 11
* 1
* 3
+2 3
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 2450
* 5
+1 5
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1242
* 5
+1 3

fn=(1360) QAdoptedThread::init()
262 3
+1 3

fn=(766)
758 5
cfn=(768) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 1706
* 2

fn=(768)
758 9
177 2
cfn=(770) (anonymous namespace)::destroy_current_thread_data_key_dtor_class_::destroy_current_thread_data_key_dtor_class_()
calls=1 * 
* 6
* 4
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
* 1677
* 5
758 3

fn=(1176) QThreadData::current(bool)
238 19558
+1 2794
cfn=(1178)
calls=2794 -57 
* 56116
* 2794
+1 5590
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 216
* 1
* 4
cfi=(74) /home/tsenyk/qt5/qt5/qtbase/src/corelib/thread/qthread.cpp
cfn=(1188) QThreadData::QThreadData(int)
calls=1 51 
* 501
* 1
+2 3
cfn=(1230)
calls=1 -51 
* 3734
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 216
* 1
* 5
cfi=(74)
cfn=(1254) QAdoptedThread::QAdoptedThread(QThreadData*)
calls=1 110 
* 10193
* 4
cfi=(61)
cfn=(1202) QAtomicPointer<QThread>::QAtomicPointer(QThread*)
calls=1 -80 
* 49
* 6
cfi=(61)
cfn=(1340) QAtomicPointer<QThread>::operator=(QAtomicPointer<QThread> const&)
calls=1 -68 
* 123
+7 3
cfi=(74)
cfn=(1362) QThreadData::deref()
calls=1 99 
* 45
+1 2
+1 1
cob=(5)
cfi=(5)
cfn=(952)
calls=1 0 
* 2
* 1
* 2
cfn=(954)
calls=1 -44 
* 6
* 3
+1 3
cfi=(35)
cfn=(1370)
calls=1 * 
* 56
* 4
+1 4
cfi=(35)
cfn=(1372)
calls=1 -3 
* 47
* 4
cfi=(35)
cfn=(1376)
calls=1 * 
* 73
+2 5588
+1 13970

fn=(1177) QThreadData::current(bool)'2
238 7
+1 1
cfn=(1178)
calls=1 -57 
* 19
* 1
+1 2
+17 2
+1 5

fn=(770)
177 6

fn=(1242) create_current_thread_data_key()
162 2
+1 3
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1260
* 5
+1 3

fn=(954)
209 1629
+2 543
+1 1086

fl=(50)
fn=(830) __static_initialization_and_destruction_0(int, int)
2792 9
230 2
cfi=(34)
cfn=(746)
calls=1 54 
* 36
2792 3

fn=(3226) QCoreApplicationPrivate::setApplicationFilePath(QString const&)
2062 5
+1 4
+3 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 192
* 1
* 5
cfi=(72)
cfn=(2320)
calls=1 889 
* 107
* 2
+1 5

fn=(3754) QCoreApplicationPrivate::createEventDispatcher()
508 6
+1 3
cfi=(85) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qcoreapplication_p.h
cfn=(1382) QCoreApplicationPrivate::q_func()
calls=1 66 
* 7
* 1
+12 2
cfi=(38)
cfn=(3756)
calls=1 3207 
* 875
* 3
cfi=(169)
cfn=(3758) QEventDispatcherGlib::versionSupported()
calls=1 +73 
* 5
* 6
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 117
* 1
* 5
cfi=(169)
cfn=(3760) QEventDispatcherGlib::QEventDispatcherGlib(QObject*)
calls=1 351 
* 31009
* 2
+13 6

fn=(4136) QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*)
1116 3222
+1 537
cfi=(84)
cfn=(3042)
calls=537 110 
* 3222
* 2682
cfi=(71)
cfn=(1320)
calls=536 110 
* 13936
* 3755
+1 2144
cfi=(71)
cfn=(1320)
calls=536 110 
* 13936
* 2144
cfi=(64)
cfn=(4842) QList<QPointer<QObject> >::size() const
calls=536 160 
* 11792
* 2144
+12 537
+1 2148

fn=(4168) QCoreApplicationPrivate::eventDispatcherReady()
538 3
+1 3

fn=(4754) QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
1513 7
+1 2
+5 5
+6 5
+2 6
cfi=(34)
cfn=(920)
calls=1 121 
* 218
+5 4
cfi=(76)
cfn=(4756)
calls=1 83 
* 8
* 4
+2 4
cfi=(76)
cfn=(4756)
calls=1 83 
* 8
* 6
+1 6
+1 1
+43 3
cfi=(34)
cfn=(1050)
calls=1 132 
* 221
* 1
-52 1
1658 4

fn=(4182) (anonymous namespace)::Q_QGS_preRList::innerFunction()::HolderBase::HolderBase()
226 6

fn=(1446) (anonymous namespace)::Q_QGS_coreappdata::innerFunction()::Holder::Holder()
383 7
cfn=(1448) (anonymous namespace)::Q_QGS_coreappdata::innerFunction()::HolderBase::HolderBase()
calls=1 * 
* 6
* 3
cfn=(1450) QCoreApplicationData::QCoreApplicationData()
calls=1 -53 
* 138
* 3
cfi=(35)
cfn=(910)
calls=1 117 
* 44
* 3

fn=(4178)
226 9
cob=(13)
cfi=(19)
cfn=(618)
calls=1 +17 
* 36
* 1
* 6
cfn=(4180) (anonymous namespace)::Q_QGS_preRList::innerFunction()::Holder::Holder()
calls=1 * 
* 85
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 0 
* 66
* 1
* 3

fn=(1134) QCoreApplicationPrivate::QCoreApplicationPrivate(int&, char**, unsigned int)
417 8
+15 4
cfi=(53)
cfn=(1136)
calls=1 198 
* 159
* 9
cfi=(61)
cfn=(994)
calls=1 155 
* 62
* 10
cfi=(64)
cfn=(1152) QList<QTranslator*>::QList()
calls=1 141 
* 19
* 6
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
* 10
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
+5 5
+2 9
+13 2
+3 6
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1519
* 5
* 2
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1535
* 5
* 5
+5 1
cfi=(41)
cfn=(946)
calls=1 -47 
* 16
* 1
+3 1
cfi=(74)
cfn=(1174) QThread::currentThread()
calls=1 362 
* 18462
* 1
+1 3
cfi=(35)
cfn=(1370)
calls=1 254 
* 56
* 4
+3 5

fn=(3044)
2089 5
+1 4
+5 4
cfi=(84)
cfn=(1378) QCoreApplication::d_func()
calls=1 80 
* 26
* 1
+1 4
cfi=(72)
cfn=(2778)
calls=1 775 
* 24
* 2
+1 3
cfn=(3046) QCoreApplication::applicationFilePath()
calls=1 +20 
* 42224
* 5
cfi=(107)
cfn=(3084) QFileInfo::QFileInfo(QString const&)
calls=1 332 
* 2601
* 5
cfi=(107)
cfn=(3228) QFileInfo::path() const
calls=1 613 
* 1395
* 6
cfi=(72)
cfn=(2234)
calls=1 227 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
* 3
cfi=(107)
cfn=(3000) QFileInfo::~QFileInfo()
calls=1 379 
* 1309
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
+1 6
cfi=(72)
cfn=(2320)
calls=1 889 
* 107
* 1
+1 5

fn=(4126) QCoreApplicationPrivate::checkReceiverThread(QObject*)
557 4833
+1 537
cfi=(74)
cfn=(1174)
calls=537 362 
* 60681
* 537
+1 1611
cfi=(53)
cfn=(3770)
calls=537 1424 
* 51015
* 537
+9 10203
-8 2148
cfi=(62)
cfn=(922)
calls=537 +63 
* 2685
* 15573
+8 537
+3 4833

fn=(4130) QCoreApplicationPrivate::notify_helper(QObject*, QEvent*)
1139 3222
+3 1074
+1 1074
-1 1611
cfi=(71)
cfn=(1320)
calls=537 110 
* 13962
* 2148
cfi=(35)
cfn=(1370)
calls=537 254 
* 30072
* 1074
cfn=(4132) QCoreApplicationPrivate::mainThread()
calls=537 543 
* 60144
* 1074
+1 2148
cfi=(84)
cfn=(1378)
calls=537 80 
* 13962
* 3222
cfn=(4134) QCoreApplicationPrivate::sendThroughApplicationEventFilters(QObject*, QEvent*)
calls=537 -49 
* 121899
* 1611
-2 1074
+5 2685
cfn=(4136)
calls=537 -30 
* 62199
* 1074
+3 4833
cfi=(53)
cfn=(4142) QObject::event(QEvent*)
calls=536 +85 
* 116752290924
cfn=(4138) QCoreApplication::event(QEvent*)
calls=1 1780 
* 79
+1 2144

fn=(4132)
543 2148
+1 3222
cfi=(35)
cfn=(1372)
calls=1074 252 
* 50478
* 3222
cfi=(62)
cfn=(922)
calls=1074 +79 
* 5370
+1 3222
cfi=(35)
cfn=(1372)
calls=1074 252 
* 50478
+1 2148

fn=(4170) QCoreApplicationPrivate::processCommandLineArguments()
182 4
+1 8
+1 6
+20 5
+4 3

fn=(1454) QCoreApplicationPrivate::appName() const
157 6
+1 3
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
+4 3
cfi=(72)
cfn=(1456)
calls=1 874 
* 10
* 11
+1 6
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1541
* 5
* 1
+1 10
cfi=(72)
cfn=(1462)
calls=1 537 
* 47724
* 5
cfi=(72)
cfn=(2234)
calls=1 +63 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
+3 2
+1 5

fn=(4134)
1094 3759
+2 1611
cfi=(71)
cfn=(1320)
calls=537 110 
* 13962
* 2148
cfi=(35)
cfn=(1370)
calls=537 254 
* 30072
* 1074
cfn=(4132)
calls=537 543 
* 60144
* 1611
cfi=(62)
cfn=(922)
calls=537 623 
* 2685
+2 2148
+14 537
+1 2148

fn=(4138)
1780 5
+1 3
cfi=(174)
cfn=(4140)
calls=1 291 
* 8
* 4
+4 5
cfi=(53)
cfn=(4142)
calls=1 1234 
* 52
+1 2

fn=(4492)
1267 4
+1 2
cfn=(4494) QCoreApplicationPrivate::checkInstance(char const*)
calls=1 174 
* 16
* 3
+3 4
cfi=(84)
cfn=(1378)
calls=1 80 
* 26
* 2
+1 2
cfi=(41)
cfn=(1176)
calls=1 238 
* 37
* 4
+4 4
cfi=(76)
cfn=(4496)
calls=1 85 
* 10
* 3
+5 2
+1 4
cfi=(187)
cfn=(4498)
calls=1 92 
* 973
+1 4
cfi=(84)
cfn=(1378)
calls=1 80 
* 26
* 1
+1 4
cfi=(84)
cfn=(1378)
calls=1 80 
* 26
* 1
+1 4
cfi=(95)
cfn=(4040)
calls=1 111 
* 10
* 5
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 116756502333
* 5

fn=(4494)
174 4
+1 5
+1 4
+2 1
+1 2

fn=(828)
2792 5
cfn=(830)
calls=1 * 
* 50
* 2

fn=(1450)
330 7
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
* 4
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
* 4
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
* 4
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
* 5
cfi=(81)
cfn=(1452)
calls=1 94 
* 10
* 5
cfi=(81)
cfn=(1452)
calls=1 94 
* 10
+1 2
+1 3

fn=(4096) QCoreApplication::notifyInternal2(QObject*, QEvent*)
993 3222
+1 537
cfn=(4098) QCoreApplicationPrivate::threadRequiresCoreApplication()
calls=537 549 
* 26313
* 537
+1 2148
+5 537
+1 3222
+1 2148
cfi=(38)
cfn=(4100)
calls=537 3872 
* 60377
* 1074
+8 1611
cfi=(71)
cfn=(1320)
calls=537 110 
* 13962
* 537
+1 1611
+1 2685
cfi=(173) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/5.6.2/QtCore/private/../../../../../../../qt5/qtbase/src/corelib/thread/qthread_p.h
cfn=(4120) QScopedLoopLevelCounter::QScopedLoopLevelCounter(QThreadData*)
calls=537 294 
* 8055
+1 2148
+2 5907
cfn=(4122) QCoreApplication::notify(QObject*, QEvent*)
calls=537 +57 
* 116752817698
* 536
-3 1608
cfi=(173)
cfn=(4146) QScopedLoopLevelCounter::~QScopedLoopLevelCounter()
calls=536 297 
* 5896
* 1072
+4 2144

fn=(4124) doNotify(QObject*, QEvent*)
1080 2685
+1 1074
+6 1611
cfn=(4126)
calls=537 557 
* 155730
+3 1611
cfi=(71)
cfn=(4128)
calls=537 137 
* 17184
* 3759
cfn=(4130)
calls=537 +49 
* 116752623309
* 536
+1 1072

fn=(4172) qt_call_pre_routines()
271 4
+1 2
cfi=(56)
cfn=(4174)
calls=1 129 
* 286
* 1
+1 2
+3 4
cfi=(34)
cfn=(920)
calls=1 121 
* 218
+5 4
cfi=(64)
cfn=(4188) QList<void (*)()>::count() const
calls=1 +52 
* 22
* 4
-5 3
cfi=(34)
cfn=(1050)
calls=1 132 
* 221
* 1
+7 4

fn=(1132)
744 9
+8 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 208
* 1
* 7
cfn=(1134)
calls=1 417 
* 21972
* 6
cfi=(53)
cfn=(1316)
calls=1 +87 
* 238
* 4
+3 3
cfi=(84)
cfn=(1378)
calls=1 80 
* 26
* 3
+1 3
cfi=(84)
cfn=(1378)
calls=1 80 
* 26
* 2
cfn=(1380) QCoreApplicationPrivate::init()
calls=1 +8 
* 802810
+2 9
cfi=(172)
cfn=(4196)
calls=1 328 
* 6
+2 6

fn=(1380)
764 6
+1 3
cfi=(85)
cfn=(1382)
calls=1 66 
* 7
* 1
+2 1
cfn=(1384) QCoreApplicationPrivate::initLocale()
calls=1 601 
* 51789
+2 5
cfi=(62)
cfn=(922)
calls=1 623 
* 5
+1 3
+3 2
cfi=(56)
cfn=(1440)
calls=1 129 
* 405
* 4
+1 5
cfn=(1454)
calls=1 157 
* 49490
* 2
cfi=(56)
cfn=(1440)
calls=1 129 
* 67
* 5
cfi=(72)
cfn=(2234)
calls=1 227 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
+2 1
cfi=(104)
cfn=(2242)
calls=1 390 
* 553
* 2
cfi=(104)
cfn=(2262)
calls=1 272 
* 666284
+6 2
cfi=(56)
cfn=(1440)
calls=1 129 
* 67
* 3
cfi=(81)
cfn=(3744)
calls=1 152 
* 11
* 1
+1 2
cfi=(56)
cfn=(1440)
calls=1 129 
* 67
* 3
cfi=(81)
cfn=(3744)
calls=1 152 
* 11
* 1
+1 2
+26 4
+1 5
cfi=(35)
cfn=(3746)
calls=1 252 
* 47
* 3
+2 4
+1 7
cfn=(3754)
calls=1 508 
* 32050
+1 5
cfi=(62)
cfn=(922)
calls=1 623 
* 5
+2 4
cfi=(71)
cfn=(4152)
calls=1 419 
* 29
* 4
+5 6
cfi=(61)
cfn=(1210) QAtomicPointer<QAbstractEventDispatcher>::QAtomicPointer(QAbstractEventDispatcher*)
calls=1 164 
* 49
* 7
cfi=(61)
cfn=(4154) QAtomicPointer<QAbstractEventDispatcher>::operator=(QAtomicPointer<QAbstractEventDispatcher> const&)
calls=1 176 
* 123
+1 7
cfn=(4168)
calls=1 538 
* 6
+8 3
cfn=(4170)
calls=1 182 
* 26
+2 1
cfn=(4172)
calls=1 271 
* 776
+1 1
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 671
* 5
+2 7
+5 2
+2 6

fn=(1448)
383 6

fn=(4098)
549 1611
+1 1074
cfi=(41)
cfn=(1176)
calls=537 238 
* 19869
* 537
+1 1074
+2 1074
+1 1074

fn=(4180)
226 7
cfn=(4182)
calls=1 * 
* 6
* 3
cfi=(64)
cfn=(4184) QList<void (*)()>::QList()
calls=1 -85 
* 19
* 3
cfi=(35)
cfn=(910)
calls=1 117 
* 44
* 3

fn=(1444)
383 30
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 6
cfn=(1446)
calls=1 * 
* 204
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 +5 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 0 
* 66
* 1
* 12

fn=(3046)
2117 6
+1 4
+5 4
cfi=(84)
cfn=(1378)
calls=1 80 
* 26
* 1
+2 5
+1 7
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 10
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
+1 7
cfi=(67)
cfn=(1720)
calls=1 261 
* 64
* 4
+7 4
+48 4
cfi=(114)
cfn=(2350)
calls=1 47 
* 11
* 5
cfi=(114)
cfn=(2352)
calls=1 82 
* 22
* 1
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1476
* 5
* 6
cfi=(72)
cfn=(2478)
calls=1 528 
* 1765
* 9
cfi=(72)
cfn=(3056) QString::arg(int, int, int, QChar) const
calls=1 908 
* 4092
* 5
cfi=(107)
cfn=(3084)
calls=1 332 
* 2455
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
+1 3
cfi=(107)
cfn=(2948) QFileInfo::exists() const
calls=1 670 
* 8464
* 5
cfi=(107)
cfn=(3180) QFileInfo::isSymLink() const
calls=1 1074 
* 2860
* 6
+1 5
cfi=(107)
cfn=(3192) QFileInfo::canonicalFilePath() const
calls=1 549 
* 17863
* 3
cfn=(3226)
calls=1 2062 
* 323
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
+1 6
cfi=(72)
cfn=(2320)
calls=1 889 
* 107
* 1
-3 3
cfi=(107)
cfn=(3000)
calls=1 379 
* 2022
* 1
+42 6

fn=(4122)
1072 3222
+2 2148
+2 2685
cfn=(4124)
calls=537 +4 
* 116752808571
+1 1072

fn=(4194)
222 2
+1 3

fn=(1384)
601 2
+1 3
+2 1
+2 3
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 51772
* 5
* 1
+2 2

fn=(4534)
1681 6
+1 5
cfi=(71)
cfn=(1320)
calls=1 110 
* 26
* 3
+1 6
cfi=(34)
cfn=(920)
calls=1 121 
* 218
+6 5
cfi=(71)
cfn=(1320)
calls=1 110 
* 26
* 8
+1 1
+4 3
cfi=(34)
cfn=(1050)
calls=1 132 
* 221
* 1
-11 1
+46 4

fn=(4752) QCoreApplication::sendPostedEvents(QObject*, int)
1505 5
+1 2
cfi=(41)
cfn=(1176)
calls=1 238 
* 37
* 1
+2 6
cfn=(4754)
calls=1 +5 
* 514
+1 3

fl=(98)
fn=(2472)
489 15456
cfi=(73)
cfn=(2144)
calls=1932 199 
* 73408
* 3864

fn=(2470) QByteArray::size() const
467 152

fn=(2276)
494 216
+1 96
cfi=(65)
cfn=(2278)
calls=24 48 
* 1424
* 72

fn=(2474) qstrnlen(char const*, unsigned int)
72 40
+1 10
+1 20
+1 1503
+1 111
-1 111
+3 10
+1 20

fn=(2668) operator==(QByteArray const&, QByteArray const&)
594 14
0 6
fi=(31)
cfn=(2470)
calls=2 467 
0 16
0 8
fi=(31)
cfn=(2470)
calls=2 467 
0 16
0 16

fn=(2154)
465 2868
0 2868
fi=(31)
cfi=(65)
cfn=(1044)
calls=717 59 
0 58413
0 4755
fi=(31)
cfi=(73)
cfn=(2158) QTypedArrayData<char>::deallocate(QArrayData*)
calls=651 219 
0 124009
0 2151

fn=(2454)
186 80
+1 80
cfi=(62)
cfn=(2456)
calls=16 860 
* 896
* 48

fn=(2476) QByteArray::data() const
487 80
cfi=(73)
cfn=(2144)
calls=10 199 
* 380
* 20

fn=(2272)
477 360

fn=(2324)
464 130
cfi=(73)
cfn=(2270)
calls=26 240 
* 260
* 156

fl=(138)
fn=(2930)
57 288
cfi=(98)
cfn=(2154)
calls=36 465 
* 3523
* 108
cfi=(72)
cfn=(2230)
calls=36 1065 
* 3357
* 108

fl=(53)
fn=(4322)
4929 120000008
+2 120000008
+1 4
cfi=(165)
cfn=(4882) QObjectPrivate::Connection::deref()
calls=1 147 
* 46
+1 90000006

fn=(3624) QObjectData::~QObjectData()
191 7620
cfi=(64)
cfn=(3626) QList<QObject*>::~QList()
calls=635 814 
* 46990
* 1905

fn=(4072) check_parent_thread(QObject*, QThreadData*, QThreadData*)
782 9
+1 5
+13 1
+1 6

fn=(1136)
198 3200
+1 1920
cfi=(71)
cfn=(1138)
calls=640 85 
* 21760
* 12160
cfi=(61)
cfn=(1144) QAtomicPointer<QtSharedPointer::ExternalRefCountData>::QAtomicPointer(QtSharedPointer::ExternalRefCountData*)
calls=640 -35 
* 31360
+7 1280
+6 1280
+1 1280
+1 2560
+1 2560
+1 2560
+1 2560
+1 2560
+1 2560
+1 1280
+1 1280
+1 3840
+1 1280
+1 2560
+1 1920

fn=(4076) QObjectPrivate::setParent_helper(QObject*)
1971 6
+1 3
cfi=(165)
cfn=(4078) QObjectPrivate::q_func()
calls=1 103 
* 7
* 1
+1 4
+2 4
+19 3
+1 4
+2 6
cfi=(71)
cfn=(1320)
calls=1 110 
* 26
* 5
+5 4
cfi=(71)
cfn=(1320)
calls=1 110 
* 26
* 5
cfi=(64)
cfn=(4080) QList<QObject*>::append(QObject* const&)
calls=1 569 
* 745
+1 9
cfi=(71)
cfn=(1320)
calls=1 110 
* 26
* 8
+1 5
+1 5
cfi=(51)
cfn=(4088)
calls=1 546 
* 50
+1 6
cfi=(84)
cfn=(4092) QCoreApplication::sendEvent(QObject*, QEvent*)
calls=1 225 
* 1493
-1 3
cfi=(51)
cfn=(4148)
calls=1 553 
* 43
+5 14
+2 4

fn=(4142)
1234 3759
+1 1611
cfi=(174)
cfn=(4140)
calls=537 291 
* 4296
* 5370
+2 4824
cfi=(175)
cfn=(4844)
calls=536 243 
* 116752266812
+1 535
+5 9
cfn=(4144) QObject::childEvent(QChildEvent*)
calls=1 +95 
* 7
+1 1
+39 1072
+1 2680

fn=(4266) QObjectConnectionListVector::QObjectConnectionListVector()
297 4
+1 3
cfi=(76)
cfn=(4268)
calls=1 65 
* 21
* 10
cfi=(165)
cfn=(4272)
calls=1 156 
* 10
+1 3

fn=(4858) QConnectionSenderSwitcher::switchSender(QObject*, QObject*, int)
163 70003738
+2 30001602
+1 30001602
+1 30001602
+1 20001068
+1 60003204
cfi=(165)
cfn=(4860) QObjectPrivate::setCurrentSender(QObject*, QObjectPrivate::Sender*)
calls=10000534 +88 
* 710037914
* 30001602
+1 20001068
+1 30001602

fn=(4306) QObjectPrivate::cleanConnectionLists()
407 40000004
+1 50000010
+32 30000003

fn=(4318) QObject::connectNotify(QMetaMethod const&)
3146 40000004
+2 30000003

fn=(4894)
79 80004272
+1 70003738
cfi=(191)
cfn=(4878)
calls=10000534 +40 
* 1690024030
+1 60003204

fn=(3622)
227 9
+2 7
+14 4
+3 4
cfi=(74)
cfn=(1362)
calls=1 99 
* 45
+2 4
+3 4
+3 4
-27 3
cfn=(3624)
calls=1 -36 
* 89
+28 5
-28 2536
+28 1902
cfn=(3623) QObjectPrivate::~QObjectPrivate()'2
calls=634 -28 
* 112852
* 2536
cob=(13)
cfi=(127)
cfn=(2652)
calls=634 32 
* 58328
* 634
* 1268

fn=(3623)
227 5706
+2 4438
+14 2536
+3 2536
cfi=(74)
cfn=(1362)
calls=634 99 
* 28530
+2 2536
+3 2536
+3 2536
-27 1902
cfn=(3624)
calls=634 -36 
* 56426
+28 3170

fn=(3770)
1424 2180
+1 1635
cfi=(71)
cfn=(3772)
calls=545 110 
* 14170
* 2180
cfi=(35)
cfn=(1370)
calls=545 254 
* 30520
+1 1090

fn=(4208)
814 4445
+1 3810
cob=(13)
cfi=(59)
cfn=(888)
calls=635 43 
* 74526
* 635
* 2540
cfn=(1136)
calls=635 198 
* 100965
* 3175
cfi=(81)
cfn=(1318)
calls=635 94 
* 6350
+2 1905
cfi=(71)
cfn=(1320)
calls=635 110 
* 16510
* 635
+1 2540
cfi=(81)
cfn=(1326)
calls=635 110 
* 11430
* 1905
+1 2540
cfi=(41)
cfn=(1176)
calls=635 238 
* 23495
* 1270
+1 2540
cfi=(74)
cfn=(1328) QThreadData::ref()
calls=635 91 
* 53975
+1 1270
+10 1905
cfn=(1334)
calls=635 145 
* 3810
* 635
+1 4445
+2 3810

fn=(4264) QObjectPrivate::addConnection(int, QObjectPrivate::Connection*)
376 70000007
+1 70000007
cfi=(62)
cfn=(922)
calls=10000001 623 
* 50000005
+1 40000004
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 192
* 1
* 3
cfn=(4266)
calls=1 -82 
* 51
* 2
+1 4
cfi=(76)
cfn=(4274)
calls=1 228 
* 8
* 40000000
cfi=(76)
cfn=(4274)
calls=10000000 228 
* 80000000
* 40000004
+1 7
cfi=(76)
cfn=(4276)
calls=1 +19 
* 1900
+2 60000006
cfn=(4296) QObjectConnectionListVector::operator[](int)
calls=10000001 -82 
* 2470000247
* 10000001
+1 40000004
+1 50000000
+2 3
+2 3
+2 3
cfn=(4306)
calls=1 +16 
* 12
-2 30000000
+2 30000000
cfn=(4306)
calls=10000000 +16 
* 120000005
+2 40000004
cfi=(164)
cfn=(4262)
calls=10000001 191 
* 350000035
* 30000003
+1 50000005
+1 40000004
+1 40000004
+1 49999995
+2 20000002
+2 20000002
+1 220000022
+2 50000005

fn=(1316)
839 35
+1 50
cfi=(81)
cfn=(1318)
calls=5 94 
* 50
+2 15
cfi=(71)
cfn=(1320)
calls=5 110 
* 130
* 5
+1 20
cfi=(81)
cfn=(1326)
calls=5 110 
* 90
* 15
+1 13
cfn=(3770)
calls=1 1424 
* 95
* 12
cfi=(41)
cfn=(1176)
calls=4 238 
* 148
cfi=(41)
cfn=(1177)
calls=1 238 
* 37
* 10
+1 20
cfi=(74)
cfn=(1328)
calls=5 91 
* 425
+1 10
+2 7
cfi=(71)
cfn=(1320)
calls=1 110 
* 26
* 7
cfn=(4072)
calls=1 -66 
* 21
* 3
+2 5
+7 5
cfn=(4074) QObject::setParent(QObject*)
calls=1 1947 
* 2569
+7 15
cfn=(1334)
calls=4 145 
* 24
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 648
* 9
+1 35
+2 25

fn=(3566)
893 6350
+2 1905
cfi=(71)
cfn=(1320)
calls=635 110 
* 16510
* 635
+1 2540
+1 2540
+2 2540
cfi=(35)
cfn=(3568)
calls=635 252 
* 29845
* 635
+1 1270
+12 5715
cfi=(164)
cfn=(3576) QObjectPrivate::isSignalConnected(unsigned int) const
calls=635 248 
* 22225
* 3175
+4 2540
+11 2540
+2 1270
+2 5080
1033 2540
cfi=(64)
cfn=(3580) QList<QObject*>::isEmpty() const
calls=635 185 
* 13970
* 1905
+3 1905
cfn=(3586)
calls=634 148 
* 3804
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 672
* 639
+1 4445
+3 2540
893 2540
cfi=(81)
cfn=(3588)
calls=635 98 
* 200624
1042 3810

fn=(3586)
148 3810

fn=(4550)
3594 11263
+1 4827
cfi=(176) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qmetaobject.cpp
cfn=(4236) QMetaObjectPrivate::signalOffset(QMetaObject const*)
calls=1609 808 
* 62751
* 9654
cfn=(4552) QMetaObject::activate(QObject*, int, int, void**)
calls=1609 +7 
* 116752318918
+1 4824

fn=(4552)
3602 14481
+1 6436
+2 6436
cfi=(71)
cfn=(1320)
calls=1609 110 
* 41834
* 4827
cfi=(164)
cfn=(3576)
calls=1609 248 
* 54707
* 1609
+2 3218
-1 4292
+1 6974
-2 3218
+6 1608
cfi=(71)
cfn=(1320)
calls=536 110 
* 13936
* 3216
+3 1608
cfi=(71)
cfn=(1320)
calls=536 110 
* 13936
* 3216
+4 536
+1 2144
+5 536
cfi=(41)
cfn=(946)
calls=536 413 
* 8576
* 536
+3 1608
cfn=(4240) signalSlotLock(QObject const*)
calls=536 138 
* 10184
* 2680
cfi=(34)
cfn=(920)
calls=536 121 
* 116848
+23 1608
cfi=(71)
cfn=(1320)
calls=536 110 
* 13936
* 2680
cfn=(4850) QMetaObject::activate(QObject*, int, int, void**)::ConnectionListsRef::ConnectionListsRef(QObjectConnectionListVector*)
calls=536 -20 
* 9112
+1 1608
+8 1608
cfn=(4852) QMetaObject::activate(QObject*, int, int, void**)::ConnectionListsRef::operator->() const
calls=536 -11 
* 3752
* 1072
cfi=(76)
cfn=(4274)
calls=536 228 
* 4288
* 2144
+1 1608
cfn=(4852)
calls=536 -12 
* 3752
* 2680
cfi=(76)
cfn=(4854)
calls=536 418 
* 41808
* 1072
+5 3213
+1 2142
+3 1608
+3 21435990908
+3 30001602
+1 30001602
cfi=(71)
cfn=(1320)
calls=10000534 110 
* 260013884
* 50002670
+4 50002670
+1 50002670
+4 50002670
+19 30001602
cfn=(4856) QConnectionSenderSwitcher::QConnectionSenderSwitcher()
calls=10000534 156 
* 80004272
+2 20001068
+1 60003204
cfn=(4858)
calls=10000534 163 
* 1030055002
+2 30001602
+1 40002136
+1 50002670
+1 40002136
cfi=(191)
cfn=(4862)
calls=10000534 119 
* 390020826
+1 60003204
cfi=(81)
cfn=(4864)
calls=10000534 94 
* 100005340
+1 30001602
cfi=(34)
cfn=(1052)
calls=10000534 134 
* 2110112674
+1 70003738
cfi=(81)
cfn=(4866)
calls=10000534 110 
* 180009612
* 60003204
cfi=(191)
cfn=(4868)
calls=10000534 124 
* 10019262539
+5 40002136
cfi=(81)
cfn=(4892)
calls=10000534 143 
* 2020041652
+2 30001602
cfi=(34)
cfn=(4896)
calls=10000534 142 
* 2160115344
-9 30001602
cfi=(81)
cfn=(4898)
calls=10000534 98 
* 220011748
* 10000534
+40 30001602
cfn=(4852)
calls=10000534 3648 
* 70003738
* 30001602
+1 40002136
cfn=(4900) QConnectionSenderSwitcher::~QConnectionSenderSwitcher()
calls=10000534 173 
* 670035778
* 20001068
-50 10000534
-31 5348997193
+82 53589974060
-84 16076992645
+86 1605
cfn=(4852)
calls=535 3648 
* 3745
* 2140
-91 535
+93 1605
cfn=(4852)
calls=535 3648 
* 3745
* 1605
cfn=(4852)
calls=535 3648 
* 3745
* 3210
+2 1605
cfn=(4852)
calls=535 3648 
* 3745
* 1070
-2 1605
-95 2675
+94 2140
cfn=(5356) QMetaObject::activate(QObject*, int, int, void**)::ConnectionListsRef::~ConnectionListsRef()
calls=535 3635 
* 19260
* 1070
3650 2675
cfi=(34)
cfn=(1050)
calls=535 132 
* 118235
* 1070
-23 535
3765 2140
3608 2146
3768 8040

fn=(5356)
3635 2675
+2 2140
+3 2675
+1 3210
cfi=(62)
cfn=(922)
calls=535 623 
* 2675
+1 2675
-6 535
+10 2675

fn=(4340)
1624 7
+1 3
cfi=(71)
cfn=(1320)
calls=1 110 
* 26
* 1
+2 5
+4 5
cfi=(35)
cfn=(3746)
calls=1 252 
* 47
* 7
+4 3
cfn=(3770)
calls=1 1424 
* 95
* 2
cfi=(74)
cfn=(1174)
calls=1 362 
* 113
* 7
+4 5
cfi=(35)
cfn=(3746)
calls=1 252 
* 47
* 6
cfi=(172)
cfn=(4342)
calls=1 251 
* 16949
* 1
+1 4
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 216
* 1
* 3
cfi=(165)
cfn=(4452) QObjectPrivate::ExtraData::ExtraData()
calls=1 108 
* 152
* 2
+1 7
cfi=(76)
cfn=(4470)
calls=1 627 
* 1894
+1 1
+1 4

fn=(4074)
1947 5
+1 3
cfi=(71)
cfn=(1320)
calls=1 110 
* 26
* 1
+1 6
cfi=(62)
cfn=(922)
calls=1 623 
* 5
+1 5
cfn=(4076)
calls=1 +21 
* 2515
+1 3

fn=(4144)
1338 4
+1 3

fn=(4226)
4637 100000010
+1 20000002
+7 10000001
+1 40000004
+1 50000005
+1 70000007
cfi=(176)
cfn=(4228) QMetaObject::static_metacall(QMetaObject::Call, int, void**) const
calls=10000001 279 
* 800000080
+1 60000006
cfi=(178) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qmetaobject_p.h
cfn=(4234) QMetaObjectPrivate::get(QMetaObject const*)
calls=10000001 179 
* 70000007
* 80000008
+1 10000001
+2 20000002
+5 30000003
cfi=(176)
cfn=(4236)
calls=10000001 808 
* 390000039
* 40000004
+1 130000013
cfn=(4238) QObjectPrivate::connectImpl(QObject const*, int, QObject const*, void**, QtPrivate::QSlotObjectBase*, Qt::ConnectionType, int const*, QMetaObject const*)
calls=10000001 +14 
* 17880192586
* 10000001
+1 40000004

fn=(4852)
3648 70026222

fn=(4296)
301 50000005
+2 20000002
+2 50000005
cfi=(76)
cfn=(4298)
calls=10000001 426 
* 2330000233
+1 20000002

fn=(1334)
145 3840

fn=(4220)
4924 80000000

fn=(4240)
138 120001614
+2 560007532
+1 80001076

fn=(4850)
3630 3752
+2 1072
+1 2680
+1 1608

fn=(4856)
156 80004272

fn=(4900)
173 40002136
+2 40002136
+1 90004806
cfi=(165)
cfn=(4902) QObjectPrivate::resetCurrentSender(QObject*, QObjectPrivate::Sender*, QObjectPrivate::Sender*)
calls=10000534 +90 
* 470025098
+1 30001602

fn=(4238)
4672 100000010
+1 60000006
+7 20000002
+1 20000002
+3 30000003
cfn=(4240)
calls=10000001 138 
* 190000019
* 40000004
cfn=(4240)
calls=10000001 138 
* 190000019
* 60000006
cfi=(179)
cfn=(4242)
calls=10000001 61 
* 2430000243
+2 40000004
+17 20000002
cob=(13)
cfi=(59)
cfn=(888)
calls=10000001 43 
* 2160188863
* 10000001
* 30000003
cfi=(165)
cfn=(4246) QObjectPrivate::Connection::Connection()
calls=10000001 141 
* 1340000134
* 40000004
cfi=(81)
cfn=(4256)
calls=10000001 94 
* 100000010
+1 30000003
cfi=(81)
cfn=(4258)
calls=10000001 110 
* 180000018
* 30000003
+1 30000003
cfi=(81)
cfn=(4258)
calls=10000001 110 
* 180000018
* 80000008
+1 30000003
cfi=(81)
cfn=(4258)
calls=10000001 110 
* 180000018
* 30000003
+1 30000003
cfi=(81)
cfn=(4258)
calls=10000001 110 
* 180000018
* 30000003
+1 30000003
cfi=(81)
cfn=(4258)
calls=10000001 110 
* 180000018
* 80000008
+1 30000003
cfi=(81)
cfn=(4258)
calls=10000001 110 
* 180000018
* 30000003
+1 20000002
+5 30000003
cfi=(81)
cfn=(4260)
calls=10000001 133 
* 70000007
* 40000004
cfi=(164)
cfn=(4262)
calls=10000001 191 
* 350000035
* 60000006
cfn=(4264)
calls=10000001 376 
* 4110002562
+1 30000003
cfi=(81)
cfn=(4308)
calls=10000001 152 
* 110000011
* 50000005
cfi=(181)
cfn=(4310)
calls=10000001 513 
* 100000010
+1 30000003
cfi=(179)
cfn=(4312)
calls=10000001 82 
* 2050000205
+2 50000005
cfi=(176)
cfn=(4314) QMetaObjectPrivate::signal(QMetaObject const*, int)
calls=10000001 861 
* 1060000106
* 20000002
+1 30000003
cfi=(182) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qmetaobject.h
cfn=(4316) QMetaMethod::isValid() const
calls=10000001 163 
* 90000009
* 40000004
cfi=(62)
cfn=(922)
calls=10000001 623 
* 50000005
+1 90000009
cfn=(4318)
calls=10000001 3146 
* 70000007
+2 50000005
cfi=(181)
cfn=(4320)
calls=10000001 531 
* 130000013
-7 30000003
cfn=(4322)
calls=10000001 4929 
* 110000011
-13 30000003
cfi=(81)
cfn=(4324)
calls=10000001 98 
* 260000026
-19 30000003
cfi=(179)
cfn=(4328)
calls=10000001 68 
* 210000021
* 10000001
+40 50000005

fn=(4876)
4735 50000000
+1 30000000
+2 60000000
+3 40000000
cfn=(4240)
calls=10000000 138 
* 190000000
* 10000000
+1 40000000
cfn=(4240)
calls=10000000 138 
* 190000000
* 10000000
+3 60000000
cfi=(179)
cfn=(4242)
calls=10000000 61 
* 2430000000
+2 40000000
cfi=(164)
cfn=(4262)
calls=10000000 191 
* 350000000
* 20000000
+1 40000000
cfi=(62)
cfn=(922)
calls=10000000 623 
* 50000000
+1 20000000
+2 50000000
+1 40000000
+2 20000000
-9 30000000
cfi=(179)
cfn=(4328)
calls=10000000 68 
* 2150000000
+13 50000000
+1 40000000
cfi=(191)
cfn=(4878)
calls=10000000 120 
* 450000000
+1 40000000
+3 20000000
+1 30000000
cfi=(165)
cfn=(4882)
calls=10000000 147 
* 460000000
+4 20000000
+1 40000000

fl=(133)
fn=(2728)
147 10080

fl=(139)
fn=(2978) QFileInfoPrivate::getCachedFlag(unsigned int) const
168 4
0 14

fn=(3006)
61 45
-61 36
fi=(31)
cfi=(76)
cfn=(3008)
calls=9 69 
0 585
0 225
fi=(31)
cfi=(72)
cfn=(2230)
calls=18 1065 
0 1170
0 684
fi=(31)
cfi=(72)
cfn=(2230)
calls=81 1065 
0 5552
0 117
fi=(31)
cfi=(81)
cfn=(3014)
calls=9 98 
0 2043
0 36
fi=(31)
cfi=(138)
cfn=(2930)
calls=9 57 
0 2423
0 45

fn=(2996) QFileInfoPrivate::setCachedFlag(unsigned int) const
170 4
0 21

fn=(3086) QFileInfoPrivate::QFileInfoPrivate(QString const&)
87 56
+9 24
cfi=(119)
cfn=(2934)
calls=8 -42 
* 584
-8 40
cfi=(109)
cfn=(2318) QDir::fromNativeSeparators(QString const&)
calls=8 834 
* 928
+8 48
cfi=(108)
cfn=(2316)
calls=8 -16 
* 1280
-8 24
cfi=(72)
cfn=(2230)
calls=8 1065 
* 751
+8 32
cfi=(110)
cfn=(2326)
calls=8 -28 
* 288
* 56
cfi=(111)
cfn=(2330)
calls=8 +92 
* 14359
* 48
cfi=(81)
cfn=(2936)
calls=8 -2 
* 80
* 336
cfi=(72)
cfn=(1156)
calls=72 1064 
* 1512
* 328
cfi=(72)
cfn=(1156)
calls=16 1064 
* 336
* 208
cfi=(76)
cfn=(2938)
calls=8 -31 
* 168
+2 48

fn=(2932) QFileInfoPrivate::QFileInfoPrivate(QFileSystemEntry const&, QFileSystemMetaData const&, QAbstractFileEngine*)
115 9
+10 3
cfi=(119)
cfn=(2934)
calls=1 -71 
* 73
* 6
cfi=(112)
cfn=(2332)
calls=1 -68 
* 173
* 20
cfi=(81)
cfn=(2936)
calls=1 -31 
* 10
* 42
cfi=(72)
cfn=(1156)
calls=9 1064 
* 189
* 41
cfi=(72)
cfn=(1156)
calls=2 1064 
* 42
* 26
cfi=(76)
cfn=(2938)
calls=1 -60 
* 21
+2 6

fl=(117)
fn=(2704)
260 35
+1 35
cfi=(62)
cfn=(2706)
calls=7 860 
* 770
* 21

fn=(2410)
193 91
cfn=(2412) QVariant::Private::Private()
calls=13 366 
* 260
* 39

fn=(2722)
370 20
+1 90
+1 15

fn=(2712) QVariant::Private::Private(QVariant::Private const&)
374 28
+2 28
-1 28
+1 210
+1 21

fn=(2412)
366 195
+1 65

fl=(164)
fn=(3576)
248 15708
fi=(165)
+2 40392
fe=(164)
+1 6832
-1 2780
+3 11220

fn=(4262)
191 120000012
+1 90000009
cfi=(71)
cfn=(1320)
calls=30000003 -82 
* 780000078
+1 60000006

fl=(190) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/.moc/moc_qabstracteventdispatcher.cpp
fn=(4776) QAbstractEventDispatcher::awake()
143 2144
+1 3216
cfi=(53)
cfn=(4550)
calls=536 3594 
* 86296
+1 1608

fn=(4548) QAbstractEventDispatcher::aboutToBlock()
137 2148
+1 3222
cfi=(53)
cfn=(4550)
calls=537 3594 
* 86457
+1 1611

fl=(43)
fn=(782)
3512 5
cfn=(784) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 50
* 2

fn=(784)
3512 9
142 2
cfi=(34)
cfn=(746)
calls=1 -88 
* 36
3512 3

fl=(193)
fn=(4992) QTextStreamPrivate::write(QChar const*, int)
822 3804
+1 2536
+2 4438
cfi=(86)
cfn=(4994)
calls=634 2058 
* 128381545
+6 2536

fn=(5346)
1144 5072
+2 1902
cfi=(196)
cfn=(4950)
calls=634 58 
* 16484
* 634
+4 2536
cfi=(72)
cfn=(1456)
calls=634 874 
* 6340
* 1902
-6 2536
cfi=(81)
cfn=(5348)
calls=634 98 
* 733345
+8 1902

fn=(4932) QTextStreamPrivate::reset()
386 3170
+1 2536
cfn=(4934) QTextStreamPrivate::Params::reset()
calls=634 -15 
* 49452
+2 1268
+1 1268
+1 1268
+1 1268
+1 2536
cfi=(95)
cfn=(3432)
calls=634 111 
* 6340
* 1902
+2 1268
+1 1268
+1 1268
+3 634
cfi=(87)
cfn=(1470)
calls=634 678 
* 90028
* 1902
+1 2536
cfn=(4936) resetCodecConverterStateHelper(QTextCodec::ConverterState*)
calls=634 -49 
* 94466
+1 2536
cfn=(4936)
calls=634 -50 
* 94466
+1 2536
+1 1268
+1 3170
cfi=(95)
cfn=(4946)
calls=634 124 
* 8242
+1 1268
+2 3170

fn=(4990)
952 5706
+1 4438
+20 3804
cfn=(4992)
calls=634 822 
* 128394859
+2 3170

fn=(4916)
1043 5072
+1 3804
cob=(13)
cfi=(59)
cfn=(888)
calls=634 43 
* 131555681
* 634
* 3170
cfn=(4918) QTextStreamPrivate::QTextStreamPrivate(QTextStream*)
calls=634 322 
* 923260
* 3170
cfi=(81)
cfn=(4948)
calls=634 94 
* 6340
+6 1902
cfi=(196)
cfn=(4950)
calls=634 58 
* 16484
* 634
+1 1902
+1 1902
+1 1268
+1 3804

fn=(5018) QTextStreamPrivate::write(QLatin1String)
852 900
+1 400
+2 700
cfi=(86)
cfn=(5020)
calls=100 2075 
* 53700
+6 400

fn=(5376)
2565 2670
+1 1602
cfi=(196)
cfn=(4950)
calls=534 58 
* 13884
* 534
+1 2136
+1 3204
cfi=(194)
cfn=(4988)
calls=534 172 
* 128323364
+1 534
+1 1068

fn=(5004) QTextStreamPrivate::putChar(QChar)
905 3670
+1 2936
+3 3670
cfn=(5006) QTextStreamPrivate::write(QChar)
calls=734 -72 
* 153406
+1 2202

fn=(5014)
2629 500
+1 300
cfi=(196)
cfn=(4950)
calls=100 58 
* 2600
* 100
+1 400
+1 500
cfi=(72)
cfn=(2518)
calls=100 87 
* 3700
* 600
cfn=(5016) QTextStreamPrivate::putString(QLatin1String, bool)
calls=100 981 
* 60300
+1 100
+1 200

fn=(4968) QTextStreamPrivate::putNumber(unsigned long long, bool)
2320 1000
+1 300
cfi=(72)
cfn=(1156)
calls=100 1064 
* 2100
+2 100
+1 300
+1 400
cfi=(95)
cfn=(4970)
calls=100 136 
* 5200
* 400
cfi=(95)
cfn=(4974)
calls=100 128 
* 700
* 400
+2 400
cfi=(95)
cfn=(4970)
calls=100 136 
* 5200
* 400
cfi=(95)
cfn=(4974)
calls=100 128 
* 700
* 400
+2 400
cfi=(95)
cfn=(4970)
calls=100 136 
* 5200
* 400
cfi=(95)
cfn=(4974)
calls=100 128 
* 700
* 400
+2 400
cfi=(95)
cfn=(4970)
calls=100 136 
* 5200
* 400
cfi=(95)
cfn=(4974)
calls=100 128 
* 700
* 400
+5 500
cfi=(195) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qlocale.h
cfn=(4930) QLocale::c()
calls=100 968 
* 9700
* 700
cfi=(116)
cfn=(4976)
calls=100 873 
* 5900
* 1000
cfi=(116)
cfn=(2636)
calls=100 852 
* 6400
* 200
+3 400
cfi=(119)
cfn=(2672)
calls=100 71 
* 40200
* 200
+1 600
+1 200
+3 200
+8 1200
cfi=(116)
cfn=(4984)
calls=100 2972 
* 120112
* 600
cfi=(72)
cfn=(2234)
calls=100 227 
* 6900
* 300
cfi=(72)
cfn=(2230)
calls=100 1065 
* 6500
+4 600
-1 300
+5 600
cfi=(194)
cfn=(4988)
calls=100 172 
* 142503
-39 300
cfi=(72)
cfn=(2230)
calls=100 1065 
* 29000
+40 700

fn=(5006)
837 3670
+1 2936
+2 4404
cfi=(86)
cfn=(5008)
calls=734 2121 
* 139460
+6 2936

fn=(4934)
372 2536
+1 1268
+1 1268
+1 1268
+1 2536
cfi=(114)
cfn=(2350)
calls=634 47 
* 6974
* 3170
cfi=(114)
cfn=(2352)
calls=634 82 
* 13948
* 1902
+1 1268
+1 1268
+1 2536
cfi=(95)
cfn=(4928)
calls=634 112 
* 5706
* 1902
+1 1902

fn=(4918)
322 3804
+6 2536
cfi=(194)
cfn=(4920)
calls=634 60 
* 339980
* 3170
cfi=(95)
cfn=(3490)
calls=634 112 
* 5706
* 2536
cfi=(95)
cfn=(4922)
calls=634 111 
* 6340
* 3804
cfi=(100)
cfn=(4924)
calls=634 90 
* 16484
* 2536
cfi=(95)
cfn=(4922)
calls=634 111 
* 6340
* 3804
cfi=(100)
cfn=(4924)
calls=634 90 
* 16484
* 3804
cfi=(72)
cfn=(1156)
calls=634 1064 
* 13314
* 2536
cfi=(72)
cfn=(1156)
calls=634 1064 
* 13314
* 3804
cfi=(194)
cfn=(4926)
calls=634 84 
* 20922
* 2536
cfi=(195)
cfn=(4930)
calls=634 968 
* 61498
+2 1902
+1 1902
cfn=(4932)
calls=634 +55 
* 381034
+1 3170

fn=(5000)
2383 4404
+1 2202
cfi=(196)
cfn=(4950)
calls=734 58 
* 19084
* 734
+1 2936
+1 2202
cfi=(114)
cfn=(5002)
calls=734 427 
* 18350
* 3670
cfn=(5004)
calls=734 905 
* 165884
+1 734
+1 1468

fn=(5016)
981 1200
+1 500
cfi=(72)
cfn=(2524)
calls=100 92 
* 700
* 700
+19 600
cfn=(5018)
calls=100 852 
* 56100
+2 500

fn=(5352)
337 3170
+2 2536
+7 2536
-9 2536
cfi=(116)
cfn=(2636)
calls=634 852 
* 50476
* 2536
cfi=(72)
cfn=(2230)
calls=634 1065 
* 41210
* 2536
cfi=(72)
cfn=(2230)
calls=634 1065 
* 41210
* 2536
cfi=(87)
cfn=(4938)
calls=634 -12 
* 51988
* 2536
cfi=(87)
cfn=(4938)
calls=634 -12 
* 51988
* 2536
cfi=(194)
cfn=(5354)
calls=634 56 
* 352504
+11 3170

fn=(4936)
352 5072
+1 3804
cfi=(87)
cfn=(4938)
calls=1268 -28 
* 103976
+1 5072
cfi=(95)
cfn=(4922)
calls=1268 111 
* 12680
* 5072
cfi=(133)
cfn=(2728)
calls=1268 147 
* 8876
* 7608
cfi=(100)
cfn=(4924)
calls=1268 90 
* 32968
+1 3804

fn=(4964)
2425 600
+1 300
cfi=(196)
cfn=(4950)
calls=100 58 
* 2600
* 100
+1 400
+1 900
cfi=(62)
cfn=(4966)
calls=100 520 
* 1000
* 600
cfn=(4968)
calls=100 2320 
* 408015
+1 100
+1 400

fl=(160)
fn=(3602)
128 7
cfn=(3603) QFSFileEnginePrivate::~QFSFileEnginePrivate()'2
calls=1 * 
* 601
* 4
cob=(13)
cfi=(127)
cfn=(2652)
calls=1 -96 
* 121
* 1
* 2

fn=(3603)
128 11
cfi=(92)
cfn=(3604)
calls=1 246 
* 66
* 4
cfi=(138)
cfn=(2930)
calls=1 -71 
* 402
* 3
cfi=(115)
cfn=(3038)
calls=1 251 
* 112
* 3

fn=(3504) QFSFileEnginePrivate::q_func()
130 7

fl=(200)
fn=(5102)
103 20
+2 20
cfn=(5104) unsigned int qHash<QLoggingCategory>(QLoggingCategory const*, unsigned int)
calls=4 -6 
* 96
* 12

fn=(5104)
99 20
+2 20
cfn=(5106) qHash(unsigned long long, unsigned int)
calls=4 -20 
* 48
+1 8

fn=(5106)
81 16
+1 24
+1 8

fl=(80)
fn=(4038) QElapsedTimer::isMonotonic()
141 2150
+1 1075
cfn=(1276) QElapsedTimer::clockType()
calls=1075 +4 
* 63425
* 2150
+1 2150

fn=(4410) qt_clock_gettime(int, timespec*)
101 5395
+1 5395
cob=(3)
cfi=(3)
cfn=(4418)
calls=1078 0 
* 21560
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 3052
* 1083
+1 3237

fn=(1276)
146 2160
+1 1080
cfn=(1278) unixCheckClockType()
calls=1080 -40 
* 56665
* 3240
+1 2160

fn=(4408) do_gettime(long long*, long long*)
151 5395
+2 1079
cfn=(1278)
calls=1079 -46 
* 55029
* 5395
cfn=(4410)
calls=1079 -52 
* 39722
+1 3237
+1 3237
+1 3237

fn=(1278)
107 6477
+15 4318
cfi=(35)
cfn=(1280)
calls=2159 -3 
* 75565
* 2159
+1 12954
+1 4316
+3 2
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1526
* 5
* 5
+1 4
cfi=(35)
cfn=(1290)
calls=1 -8 
* 44
+1 1
+9 4318

fn=(4406) qt_gettime()
160 3234
+2 5390
cfn=(4408)
calls=1078 -11 
* 116226
+3 2156
+1 2156
+2 2156
+1 2156

fn=(5218)
195 4
+1 6
cfn=(4408)
calls=1 -45 
* 105
+1 3

fl=(107)
fn=(2314)
694 10
+1 10
cfi=(108)
cfn=(2316)
calls=2 80 
* 296
+1 6
cfi=(110)
cfn=(2326)
calls=2 68 
* 72
+2 10
cfi=(111)
cfn=(2330)
calls=2 188 
* 470207
* 2
+2 4
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 208
* 1
* 7
cfi=(139)
cfn=(2932)
calls=1 115 
* 661
* 4
cfn=(2942) QFileInfo::QFileInfo(QFileInfoPrivate*)
calls=1 311 
* 61
* 3
cfn=(2948)
calls=1 -31 
* 9579
* 4
cfn=(3000)
calls=1 379 
* 3109
* 1
+2 4
cfi=(95)
cfn=(3090)
calls=1 111 
* 10
* 6
cfi=(144) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfilesystemengine_unix.cpp
cfn=(3106) QFileSystemEngine::fillMetaData(QFileSystemEntry const&, QFileSystemMetaData&, QFlags<QFileSystemMetaData::MetaDataFlag>)
calls=1 418 
* 4684
+1 3
cfi=(110)
cfn=(3178)
calls=1 178 
* 76
* 1
-9 3
cfi=(138)
cfn=(2930)
calls=1 57 
* 431
* 3
cfi=(138)
cfn=(2930)
calls=1 57 
* 144
* 4
+10 8

fn=(3192)
549 5
+1 3
cfi=(140) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qfileinfo.h
cfn=(2950) QFileInfo::d_func() const
calls=1 138 
* 16
* 1
+1 6
+2 6
cfn=(3194) QFileInfoPrivate::getFileName(QAbstractFileEngine::FileName) const
calls=1 43 
* 17823
+1 3

fn=(3228)
613 5
+1 3
cfi=(140)
cfn=(2950)
calls=1 138 
* 16
* 1
+1 6
+2 6
cfi=(108)
cfn=(3216) QFileSystemEntry::path() const
calls=1 190 
* 1355
+1 3

fn=(2948)
670 10
+1 6
cfi=(140)
cfn=(2950)
calls=2 138 
* 32
* 2
+1 12
+2 8
cfi=(81)
cfn=(2954)
calls=2 127 
* 43
* 8
+1 11
cfi=(95)
cfn=(3090)
calls=1 111 
* 10
* 7
cfi=(143)
cfn=(3092) QFileSystemMetaData::hasFlags(QFlags<QFileSystemMetaData::MetaDataFlag>) const
calls=1 158 
* 101
* 8
+1 4
cfi=(95)
cfn=(3090)
calls=1 111 
* 10
* 8
cfi=(144)
cfn=(3106)
calls=1 418 
* 8159
+1 4
cfi=(110)
cfn=(3178)
calls=1 178 
* 76
* 1
+2 4
cfi=(95)
cfn=(2958)
calls=1 111 
* 10
* 5
cfn=(2960) QFileInfoPrivate::getFileFlags(QFlags<QAbstractFileEngine::FileFlag>) const
calls=1 119 
* 9494
* 2
+1 8

fn=(3180)
1074 5
+1 3
cfi=(140)
cfn=(2950)
calls=1 138 
* 16
* 1
+1 6
+2 4
cfi=(81)
cfn=(2954)
calls=1 127 
* 22
* 4
+1 11
cfi=(95)
cfn=(3090)
calls=1 111 
* 10
* 7
cfi=(143)
cfn=(3092)
calls=1 158 
* 101
* 8
+1 4
cfi=(95)
cfn=(3090)
calls=1 111 
* 10
* 8
cfi=(144)
cfn=(3106)
calls=1 418 
* 2555
+1 4
cfi=(110)
cfn=(3190)
calls=1 185 
* 76
* 1
+3 4

fn=(3194)
43 7
+1 14
cfi=(72)
cfn=(2778)
calls=1 775 
* 24
* 6
+3 3
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
+1 4
cfi=(81)
cfn=(2954)
calls=1 +79 
* 22
* 4
+1 12
+3 8
cfi=(144)
cfn=(3196) QFileSystemEngine::canonicalName(QFileSystemEntry const&, QFileSystemMetaData&)
calls=1 226 
* 14907
+1 5
+1 5
cfi=(108)
cfn=(2336)
calls=1 +69 
* 151
* 6
cfi=(72)
cfn=(2234)
calls=1 227 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
+1 5
cfi=(108)
cfn=(3216)
calls=1 190 
* 1517
* 6
cfi=(72)
cfn=(2234)
calls=1 227 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
+2 2
+1 5
cfi=(108)
cfn=(2336)
calls=1 +65 
* 151
* 5
cfi=(72)
cfn=(2234)
calls=1 227 
* 69
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
+3 2
-9 3
cfi=(138)
cfn=(2930)
calls=1 +5 
* 177
* 1
+35 3
cfi=(72)
cfn=(2778)
calls=1 775 
* 24
* 2
+2 5
+1 11
cfi=(86)
cfn=(2534)
calls=1 1791 
* 189
+1 5
cfi=(72)
cfn=(2228)
calls=1 226 
* 26
-44 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
* 1
+45 5

fn=(3734) QFileInfo::isFile() const
1004 10
+1 6
cfi=(140)
cfn=(2950)
calls=2 138 
* 32
* 2
+1 12
+2 8
cfi=(81)
cfn=(2954)
calls=2 127 
* 44
* 8
+1 22
cfi=(95)
cfn=(3090)
calls=2 111 
* 20
* 14
cfi=(143)
cfn=(3092)
calls=2 158 
* 202
* 16
+1 8
cfi=(95)
cfn=(3090)
calls=2 111 
* 20
* 16
cfi=(144)
cfn=(3106)
calls=2 418 
* 9142
+1 8
cfi=(143)
cfn=(3736) QFileSystemMetaData::isFile() const
calls=2 181 
* 152
* 2
+3 8

fn=(3314) QFileInfo::isRelative() const
637 16
+1 12
cfi=(140)
cfn=(2950)
calls=4 138 
* 64
* 4
+1 24
+2 16
cfi=(81)
cfn=(2954)
calls=4 127 
* 88
* 16
+1 16
cfi=(108)
cfn=(3316) QFileSystemEntry::isRelative() const
calls=4 281 
* 721
* 4
+2 8

fn=(3084)
332 72
cob=(13)
cfi=(59)
cfn=(888)
calls=8 43 
* 2254
* 8
* 40
cfi=(139)
cfn=(3086)
calls=8 87 
* 21534
* 32
cfi=(119)
cfn=(2944)
calls=8 219 
* 384
+2 48

fn=(2942)
311 10
cfi=(119)
cfn=(2944)
calls=1 -92 
* 48
+2 3

fn=(2960)
119 6
+1 4
cfi=(81)
cfn=(2962)
calls=1 -4 
* 9
* 3
cfi=(62)
cfn=(922)
calls=1 623 
* 5
+10 4
cfi=(95)
cfn=(2964)
calls=1 -18 
* 9
+1 1
+2 3
cfi=(115)
cfn=(2966) operator|(QAbstractFileEngine::FileFlag, QAbstractFileEngine::FileFlag)
calls=1 +70 
* 79
* 4
cfi=(95)
cfn=(2974)
calls=1 -5 
* 7
* 5
cfi=(95)
cfn=(2976)
calls=1 +1 
* 52
* 4
cfi=(95)
cfn=(2974)
calls=1 -5 
* 7
* 4
+1 4
cfi=(139)
cfn=(2978)
calls=1 +34 
* 18
* 3
+1 4
cfi=(95)
cfn=(2982)
calls=1 -11 
* 13
+1 4
cfi=(95)
cfn=(2982)
calls=1 -12 
* 13
+1 4
cfi=(95)
cfn=(2984)
calls=1 -17 
* 13
+1 4
cfi=(95)
cfn=(2984)
calls=1 -18 
* 13
+2 1
+3 4
cfi=(95)
cfn=(2986)
calls=1 -7 
* 52
* 4
cfi=(95)
cfn=(2974)
calls=1 -15 
* 7
* 4
+7 4
cfi=(95)
cfn=(2986)
calls=1 -14 
* 52
* 4
cfi=(95)
cfn=(2974)
calls=1 -22 
* 7
* 4
+8 4
cfi=(95)
cfn=(2986)
calls=1 -22 
* 52
* 4
cfi=(95)
cfn=(2974)
calls=1 -30 
* 7
* 4
+7 3
cfi=(95)
cfn=(2974)
calls=1 -37 
* 7
* 4
+1 5
+1 4
cfi=(95)
cfn=(2984)
calls=1 -47 
* 13
* 1
+4 4
cfi=(81)
cfn=(2988)
calls=1 -61 
* 18
* 7
cfi=(55)
cfn=(2990)
calls=1 1357 
* 8851
* 1
+1 3
cfi=(95)
cfn=(2974)
calls=1 -44 
* 7
* 6
+1 5
cfi=(139)
cfn=(2996)
calls=1 -3 
* 25
+3 5
cfi=(95)
cfn=(2974)
calls=1 -48 
* 7
* 1
+1 4

fn=(3000)
379 63
cfi=(119)
cfn=(3002)
calls=9 83 
* 14691
+2 27

fl=(152)
fn=(3430)
144 4
+4 4
cfi=(53)
cfn=(1136)
calls=1 +50 
* 159
* 9
cfi=(95)
cfn=(3432)
calls=1 -37 
* 10
* 4
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
* 5
cfi=(153)
cfn=(3434)
calls=1 -79 
* 15
* 8
+5 3

fn=(3466)
517 8
+1 6
cfi=(156)
cfn=(3468)
calls=2 158 
* 52
* 6
cfi=(95)
cfn=(3470)
calls=2 128 
* 14
* 4
+1 4

fn=(3454)
403 6
+1 6
cfi=(53)
cfn=(1316)
calls=1 839 
* 238
* 4
+2 3

fn=(3564)
416 11
cfi=(53)
cfn=(3566)
calls=1 893 
* 3081
+5 3

fn=(3618)
158 12
cfi=(153)
cfn=(3620)
calls=1 -87 
* 11
* 4
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
* 3
cfi=(53)
cfn=(3622)
calls=1 +69 
* 178
+2 3

fl=(115)
fn=(3548)
199 8
cfi=(62)
cfn=(2832)
calls=1 1014 
* 16
* 2

fn=(3552)
199 16
cfi=(62)
cfn=(2832)
calls=2 1014 
* 32
* 4

fn=(2362)
247 8
+1 18
cfi=(72)
cfn=(1156)
calls=2 1064 
* 42
+2 6

fn=(2966)
203 5
fi=(141) /home/tsenyk/qt5/qt5/qtbase/src/corelib/io/qabstractfileengine_p.h
* 5
cfi=(95)
cfn=(2958)
calls=1 -92 
* 10
* 5
cfi=(95)
cfn=(2970)
calls=1 -72 
* 52
* 2
fe=(115)

fn=(3038)
251 8
fi=(141)
* 14
cfi=(72)
cfn=(2230)
calls=2 1065 
* 163
* 6
fe=(115)

fl=(135)
fn=(2830)
56 8
cfi=(62)
cfn=(2832)
calls=1 1014 
* 16
* 2

fn=(2992)
56 8
cfi=(62)
cfn=(2832)
calls=1 1014 
* 16
* 2

fl=(166)
fn=(3726) existsAsSpecified(QString const&, QFlags<QStandardPaths::LocateOption>)
396 12
+1 8
cfi=(95)
cfn=(3728)
calls=2 136 
* 104
* 8
cfi=(95)
cfn=(3732)
calls=2 128 
* 14
* 8
+2 10
cfi=(107)
cfn=(3084)
calls=2 -67 
* 4956
* 6
cfi=(107)
cfn=(3734)
calls=2 1004 
* 9752
* 8
cfi=(107)
cfn=(3000)
calls=2 -20 
* 3097
* 4
+1 8

fn=(3660)
410 8
+1 5
cfi=(167)
cfn=(3662)
calls=1 311 
* 17994
* 2
+1 5
cfi=(64)
cfn=(3714) QList<QString>::constBegin() const
calls=1 -97 
* 40
* 15
cfi=(64)
cfn=(3718) QList<QString>::constEnd() const
calls=3 -93 
* 120
* 15
cfi=(64)
cfn=(3720) QList<QString>::const_iterator::operator!=(QList<QString>::const_iterator const&) const
calls=3 292 
* 36
* 6
+1 8
cfi=(114)
cfn=(2350)
calls=2 47 
* 22
* 6
cfi=(64)
cfn=(3722) QList<QString>::const_iterator::operator*() const
calls=2 288 
* 32
* 10
cfi=(150)
cfn=(3372)
calls=2 -31 
* 98
* 14
cfi=(150)
cfn=(3380)
calls=2 -31 
* 98
* 14
cfi=(150)
cfn=(3388)
calls=2 125 
* 2746
+1 10
cfn=(3726)
calls=2 -18 
* 17995
* 4
+1 8
cfi=(72)
cfn=(2230)
calls=2 1065 
* 580
* 4
-2 2
-1 6
cfi=(64)
cfn=(3740) QList<QString>::const_iterator::operator++()
calls=2 297 
* 22
* 2
+5 3
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
-6 3
cfi=(120)
cfn=(3036)
calls=1 93 
* 920
* 1
+7 5

fn=(3676)
654 2
+1 1
+1 2

fl=(183)
fn=(4360) QFreeList<void, QtTimerIdFreeListConstants>::blockfor(int&)
149 4
+2 3
+1 6
+1 4
+1 2
+5 2

fn=(4370) QFreeList<void, QtTimerIdFreeListConstants>::allocate(int, int)
162 8
+3 8
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1964
* 5
* 264
cfn=(4382) QFreeListElement<void>::QFreeListElement()
calls=64 -85 
* 4672
* 193
+1 196
+1 768
cfi=(35)
cfn=(910)
calls=64 -50 
* 2816
-1 128
+2 1
+1 6

fn=(4358)
228 4
+5 4
cfi=(35)
cfn=(864)
calls=1 116 
* 35
* 1
+2 3
+1 3
cfn=(4360)
calls=1 -87 
* 21
* 1
+1 7
cfi=(35)
cfn=(4362)
calls=1 +21 
* 47
* 1
+2 2
+1 14
cfn=(4370)
calls=1 -78 
* 11029
* 1
+1 10
cfi=(35)
cfn=(4384)
calls=1 +27 
* 142
* 3
+8 7
cfi=(35)
cfn=(864)
calls=1 116 
* 35
* 5
+1 7
cfi=(35)
cfn=(4392)
calls=1 133 
* 132
-18 3
+23 2
+1 2

fn=(4356)
202 4
+1 18
cfi=(61)
cfn=(994)
calls=1 -48 
* 62
+1 3

fn=(4382)
80 512
cfi=(61)
cfn=(994)
calls=64 +75 
* 3968
* 192

fl=(123)
fn=(2592)
8251 120
+1 1000
+1 80

fl=(154)
fn=(3608)
53 7
cfi=(64)
cfn=(3610) QList<QByteArray>::~QList()
calls=1 814 
* 387
* 3

fn=(3436)
56 6
+1 3
cfi=(64)
cfn=(3438) QList<QByteArray>::QList()
calls=1 +84 
* 19
* 11
+1 3
cfi=(98)
cfn=(2324)
calls=1 464 
* 21
* 5
cfi=(64)
cfn=(3442) QList<QByteArray>::append(QByteArray const&)
calls=1 569 
* 739
* 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
+1 5

fl=(161)
fn=(3502)
152 7
+1 3
cfi=(160)
cfn=(3504)
calls=1 -23 
* 7
* 1
+2 4
cfi=(95)
cfn=(3472)
calls=1 -19 
* 52
* 4
cfi=(95)
cfn=(3470)
calls=1 -27 
* 7
* 4
+1 3
cfn=(3506) openModeToOpenFlags(QFlags<QIODevice::OpenModeFlag>)
calls=1 -51 
* 297
* 1
+4 6
cfi=(108)
cfn=(3116) QFileSystemEntry::nativeFilePath() const
calls=1 -31 
* 3295
* 3
cfi=(98)
cfn=(2472)
calls=1 489 
* 48
* 6
cfi=(162)
cfn=(3508)
calls=1 -2 
* 2304
* 6
cfi=(98)
cfn=(2154)
calls=1 465 
* 98
+1 5
cob=(5)
cfi=(5)
cfn=(3524)
calls=1 0 
* 3
* 1
* 3
+3 4
+2 1
cob=(5)
cfi=(5)
cfn=(3524)
calls=1 0 
* 3
* 1
* 5
cfi=(38)
cfn=(3526)
calls=1 3085 
* 2448
-1 1
cob=(5)
cfi=(5)
cfn=(3524)
calls=1 0 
* 3
* 1
* 5
+1 4
cfi=(113)
cfn=(3546)
calls=1 1256 
* 204
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
+1 2
+75 2
+1 5

fn=(3506)
105 6
+1 1
+5 4
cfi=(95)
cfn=(3472)
calls=1 +25 
* 52
* 4
cfi=(95)
cfn=(3470)
calls=1 +17 
* 7
* 4
+2 4
cfi=(95)
cfn=(3472)
calls=1 +23 
* 52
* 4
cfi=(95)
cfn=(3470)
calls=1 +15 
* 7
* 4
+4 4
cfi=(95)
cfn=(3472)
calls=1 +19 
* 52
* 4
cfi=(95)
cfn=(3470)
calls=1 +11 
* 7
* 4
+2 4
cfi=(95)
cfn=(3472)
calls=1 +17 
* 52
* 4
cfi=(95)
cfn=(3470)
calls=1 +9 
* 7
* 4
+5 1
+1 5

fl=(60)
fn=(892)
73 8
+1 14

fl=(101)
fn=(2206)
671 40
+1 30
cfn=(2208) QUtf8::convertToUnicode(char const*, int, QTextCodec::ConverterState*)
calls=5 296 
* 8879
+1 15

fn=(5370)
245 3738
+13 3204
cfi=(86)
cfn=(2210)
calls=534 1557 
* 393675
+2 1602
cfi=(72)
cfn=(2216)
calls=534 882 
* 25632
* 534
+1 1068
+1 2670
+3 1068
+1 3204
cfn=(2218) simdDecodeAscii(unsigned short*&, unsigned char const*&, unsigned char const*&, unsigned char const*)
calls=534 90 
* 44856
* 1602
+3 3204
+6 3204
+1 1068
+1 3204
cfn=(2218)
calls=534 90 
* 10680
* 1068
+4 40050
+1 48060
cfi=(99)
cfn=(3212)
calls=8010 178 
* 280350
* 8010
+1 16020
+4 32040
-7 7476
+11 2670
cfi=(72)
cfn=(2216)
calls=534 882 
* 25632
* 4272
cfi=(86)
cfn=(2224)
calls=534 4971 
* 6942
+1 1068
+1 2670

fn=(3130)
661 5112
+1 3834
cfn=(3132) QUtf8::convertFromUnicode(QChar const*, int, QTextCodec::ConverterState*)
calls=639 176 
* 133112777
+1 1917

fn=(2208)
296 40
+1 5
+1 5
+1 5
+2 5
+12 35
cfi=(86)
cfn=(2210)
calls=5 1557 
* 4123
+2 15
cfi=(72)
cfn=(2216)
calls=5 882 
* 240
* 5
+1 10
+1 25
+2 10
+45 5
+1 10
+1 10
+1 140
+1 240
cfn=(2218)
calls=24 90 
* 928
* 121
+3 115
+1 138
cfi=(99)
cfn=(3212)
calls=23 178 
* 805
* 23
+1 100
+1 4
+1 20
+6 46
-12 1
+19 20
+7 25
cfi=(72)
cfn=(2222)
calls=5 876 
* 240
* 40
cfi=(86)
cfn=(2224)
calls=5 4971 
* 790
+1 10
+12 25
cfi=(72)
cfn=(2228)
calls=5 226 
* 130
-95 15
cfi=(72)
cfn=(2230)
calls=5 1065 
* 325
* 5
+96 25

fn=(2218)
90 7644
+2 11431
+1 1623
fi=(102)
698 1082
fe=(101)
93 541
+14 1623
fi=(102)
1392 1082
fe=(101)
111 541
+1 1082
fi=(102)
755 2705
989 1623
fe=(101)
114 2164
fi=(102)
716 1623
+39 2705
965 1623
fe=(101)
115 2705
fi=(102)
716 1623
fe=(101)
116 541
-24 5951
+42 4368
+1 2184

fn=(3132)
176 5112
+1 639
+1 3195
+1 639
+1 1278
+10 3834
cfi=(67)
cfn=(3134)
calls=639 1522 
* 131585065
+1 1917
cfi=(98)
cfn=(2472)
calls=639 489 
* 30672
* 639
+1 1278
+1 3834
+2 639
+1 4473
+7 1278
+1 29649
+3 18490
+5 92450
cfn=(3136) simdEncodeAscii(unsigned char*&, unsigned short const*&, unsigned short const*&, unsigned short const*)
calls=9245 51 
* 219716
* 46226
+3 46220
+1 55464
cfi=(99)
cfn=(3138)
calls=9244 115 
* 332784
* 9244
+2 55464
+1 9244
-15 9244
+9 1
+18 5
cfi=(98)
cfn=(2472)
calls=1 489 
* 48
* 3190
cfi=(98)
cfn=(2472)
calls=638 489 
* 30624
* 4473
cfi=(67)
cfn=(3144)
calls=639 1543 
* 500637
+1 1278
+9 639
+1 3195

fn=(3136)
51 64715
+2 68523
+1 1632
fi=(102)
698 1088
fe=(101)
54 544
+1 2176
fi=(102)
698 1088
fe=(101)
55 2720
fi=(102)
959 1632
fe=(101)
66 544
fi=(102)
755 2720
1330 1632
fe=(101)
67 544
+3 2720
fi=(102)
716 2720
1392 1088
fe=(101)
73 1088
+1 1088
-21 5984
+33 36980
+1 18490

fl=(197)
fn=(4956)
60 1902
+1 8242

fl=(195)
fn=(4930)
968 6606
cfi=(116)
cfn=(2428)
calls=734 805 
* 62390
* 2202

fl=(118)
fn=(2424) (anonymous namespace)::Q_QGS_qSystemLocaleData::innerFunction()::HolderBase::HolderBase()
98 6

fn=(2422) (anonymous namespace)::Q_QGS_qSystemLocaleData::innerFunction()::Holder::Holder()
98 8
cfn=(2424)
calls=1 * 
* 6
* 3
cfn=(2426) QSystemLocaleData::QSystemLocaleData()
calls=1 -51 
* 188963
* 3
cfi=(35)
cfn=(910)
calls=1 +19 
* 44
* 5

fn=(2426)
47 5
+4 4
cfi=(90)
cfn=(1488)
calls=1 +60 
* 1244
* 6
cfi=(116)
cfn=(2428)
calls=1 805 
* 85
* 6
cfi=(116)
cfn=(2428)
calls=1 805 
* 85
* 6
cfi=(116)
cfn=(2428)
calls=1 805 
* 85
* 6
cfi=(116)
cfn=(2428)
calls=1 805 
* 85
* 4
cfi=(98)
cfn=(2324)
calls=1 464 
* 21
* 4
cfi=(98)
cfn=(2324)
calls=1 464 
* 21
* 4
cfi=(120)
cfn=(2438)
calls=1 +46 
* 29
+2 3
cfn=(2444) QSystemLocaleData::readEnvironment()
calls=1 +17 
* 187255
+1 5

fn=(2420)
98 83
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 7
cfn=(2422)
calls=1 * 
* 189032
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 -98 
* 66
* 1
* 54

fn=(2444)
70 10
+1 10
cfi=(121)
cfn=(2446)
calls=2 +86 
* 1106
+2 8
cfi=(38)
cfn=(2264)
calls=2 3173 
* 2090
+1 6
cfi=(98)
cfn=(2272)
calls=2 477 
* 20
* 12
cfi=(38)
cfn=(2264)
calls=2 3173 
* 2090
* 2
+1 6
cfi=(98)
cfn=(2272)
calls=2 477 
* 20
* 12
cfi=(38)
cfn=(2264)
calls=2 3173 
* 3025
* 2
+1 6
cfi=(98)
cfn=(2272)
calls=2 477 
* 20
* 12
cfi=(38)
cfn=(2264)
calls=2 3173 
* 3701
* 2
+1 6
cfi=(98)
cfn=(2272)
calls=2 477 
* 20
* 12
cfi=(38)
cfn=(2264)
calls=2 3173 
* 2182
* 14
cfi=(98)
cfn=(2454)
calls=2 186 
* 138
* 6
cfi=(98)
cfn=(2154)
calls=2 465 
* 355
+1 6
cfi=(98)
cfn=(2272)
calls=2 477 
* 20
* 12
cfi=(38)
cfn=(2264)
calls=2 3173 
* 3111
* 14
cfi=(98)
cfn=(2454)
calls=2 186 
* 138
* 6
cfi=(98)
cfn=(2154)
calls=2 465 
* 355
+1 8
cfi=(38)
cfn=(2264)
calls=2 3173 
* 3563
+1 6
cfi=(98)
cfn=(2272)
calls=2 477 
* 20
* 4
+2 6
cfi=(98)
cfn=(2272)
calls=2 477 
* 20
* 4
+1 10
cfi=(67)
cfn=(2462)
calls=2 1045 
* 312
+1 6
cfi=(98)
cfn=(2272)
calls=2 477 
* 20
* 4
+2 6
cfi=(98)
cfn=(2272)
calls=2 477 
* 20
* 4
+2 8
cfi=(98)
cfn=(2272)
calls=2 477 
* 20
* 4
+1 12
cfi=(67)
cfn=(2462)
calls=2 1045 
* 312
+1 8
cfi=(98)
cfn=(2272)
calls=2 477 
* 20
* 4
+2 10
cfi=(72)
cfn=(2464) QString::fromLatin1(QByteArray const&)
calls=2 541 
* 4129
* 10
cfi=(116)
cfn=(2514)
calls=2 768 
* 84064
* 12
cfi=(116)
cfn=(2632)
calls=2 862 
* 3776
* 6
cfi=(116)
cfn=(2636)
calls=2 852 
* 128
* 6
cfi=(72)
cfn=(2230)
calls=2 1065 
* 580
+1 10
cfi=(72)
cfn=(2464)
calls=2 541 
* 4030
* 10
cfi=(116)
cfn=(2514)
calls=2 768 
* 80169
* 12
cfi=(116)
cfn=(2632)
calls=2 862 
* 330
* 6
cfi=(116)
cfn=(2636)
calls=2 852 
* 128
* 6
cfi=(72)
cfn=(2230)
calls=2 1065 
* 580
+1 10
cfi=(72)
cfn=(2464)
calls=2 541 
* 4030
* 10
cfi=(116)
cfn=(2514)
calls=2 768 
* 80169
* 12
cfi=(116)
cfn=(2632)
calls=2 862 
* 330
* 6
cfi=(116)
cfn=(2636)
calls=2 852 
* 128
* 6
cfi=(72)
cfn=(2230)
calls=2 1065 
* 580
+1 12
cfi=(72)
cfn=(2464)
calls=2 541 
* 4030
* 10
cfi=(116)
cfn=(2514)
calls=2 768 
* 83841
* 12
cfi=(116)
cfn=(2632)
calls=2 862 
* 330
* 6
cfi=(116)
cfn=(2636)
calls=2 852 
* 128
* 6
cfi=(72)
cfn=(2230)
calls=2 1065 
* 580
-16 6
cfi=(98)
cfn=(2154)
calls=2 465 
* 196
-3 6
cfi=(98)
cfn=(2154)
calls=2 465 
* 580
-1 6
cfi=(98)
cfn=(2154)
calls=2 465 
* 580
-1 6
cfi=(98)
cfn=(2154)
calls=2 465 
* 196
-1 6
cfi=(98)
cfn=(2154)
calls=2 465 
* 130
-2 6
cfi=(121)
cfn=(2642)
calls=2 +54 
* 1108
+25 10

fn=(2414)
128 72
+1 18
cfi=(56)
cfn=(2416)
calls=9 * 
* 189815
* 9
+2 18
+1 3
cfn=(2444)
calls=1 -62 
* 190775
+1 3
cfi=(117)
cfn=(2410)
calls=1 +60 
* 30
* 1
+3 40
cfi=(121)
cfn=(2678)
calls=8 -24 
* 4464
+2 24
+1 24
+1 24
+1 24
+2 88
+2 3
cfi=(116)
cfn=(2714)
calls=1 1919 
* 44
* 5
cfi=(129)
cfn=(2720)
calls=1 1728 
* 86
* 1
+2 3
cfi=(116)
cfn=(2750)
calls=1 1929 
* 44
* 5
cfi=(129)
cfn=(2720)
calls=1 1728 
* 86
* 1
+2 3
cfi=(116)
cfn=(2754)
calls=1 1949 
* 44
* 5
cfi=(129)
cfn=(2720)
calls=1 1728 
* 86
* 1
+2 3
cfi=(116)
cfn=(2758)
calls=1 1959 
* 44
* 5
cfi=(129)
cfn=(2720)
calls=1 1728 
* 86
* 1
+38 3
cfi=(116)
cfn=(2762)
calls=1 1969 
* 44
* 5
cfi=(129)
cfn=(2720)
calls=1 1728 
* 86
* 1
+65 3
+2 9
cfi=(117)
cfn=(2410)
calls=3 -63 
* 90
136 24
cfi=(121)
cfn=(2686)
calls=8 -55 
* 4384
* 8
257 45

fn=(2666)
105 8
+1 4
cfi=(38)
cfn=(2264)
calls=1 3173 
* 1045
+1 3
cfi=(98)
cfn=(2272)
calls=1 477 
* 10
* 2
+1 4
cfi=(38)
cfn=(2264)
calls=1 3173 
* 1091
* 5
cfi=(98)
cfn=(2454)
calls=1 +78 
* 69
* 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
+1 3
cfi=(98)
cfn=(2272)
calls=1 477 
* 10
* 2
+1 4
cfi=(38)
cfn=(2264)
calls=1 3173 
* 1732
* 5
cfi=(98)
cfn=(2454)
calls=1 +76 
* 69
* 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
+2 5
cfi=(98)
cfn=(2272)
calls=1 477 
* 10
* 7
cfi=(67)
cfn=(2120)
calls=1 1477 
* 832
* 6
cfi=(98)
cfn=(2668)
calls=1 594 
* 38
* 7
cfi=(67)
cfn=(2120)
calls=1 1477 
* 930
* 6
cfi=(98)
cfn=(2668)
calls=1 594 
* 38
* 8
cfi=(98)
cfn=(2154)
calls=1 465 
* 290
* 6
cfi=(98)
cfn=(2154)
calls=1 465 
* 290
* 2
+5 4
cfi=(38)
cfn=(2264)
calls=1 3173 
* 848
+1 3
cfi=(98)
cfn=(2272)
calls=1 477 
* 10
* 3
+6 5
cfi=(72)
cfn=(2464)
calls=1 541 
* 2015
* 5
cfi=(116)
cfn=(2514)
calls=1 768 
* 41992
* 4
cfi=(72)
cfn=(2230)
calls=1 1065 
* 290
-7 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 65
-11 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 290
* 1
+19 7

fl=(176)
fn=(4230) priv(unsigned int const*)
140 300009684

fn=(4314)
861 50000005
+1 20000002
+1 20000002
+2 30000003
cfi=(62)
cfn=(922)
calls=10000001 623 
* 50000005
+1 20000002
+1 30000003
cfn=(4236)
calls=10000001 -59 
* 390000039
* 10000001
+1 20000002
+3 60000006
cfn=(4230)
calls=10000001 140 
* 60000006
* 70000007
+1 20000002
+1 40000004
cfn=(4230)
calls=10000001 140 
* 60000006
* 70000007
+2 20000002
+1 20000002

fn=(4236)
808 80006444
+1 60004833
cfi=(62)
cfn=(922)
calls=20001611 623 
* 100008055
+1 20001611
+1 140011277
+1 80006444
cfn=(4230)
calls=20001611 140 
* 120009666
* 40003222
-1 80006444
+2 20001611
+1 40003222

fn=(4228)
279 70000007
+1 40000004
cfn=(4230)
calls=10000001 140 
* 60000006
* 40000004
cfi=(62)
cfn=(922)
calls=10000001 623 
* 50000005
+1 40000004
+2 70000007
cfi=(177)
cfn=(4232)
calls=10000001 92 
* 400000040
+1 10000001
+1 20000002

fl=(180)
fn=(4282)
1207 15

fl=(57)
fn=(972)
118 40
+2 48
cfi=(36)
cfn=(974)
calls=8 405 
* 264
+1 24

fn=(3748)
94 4312
+2 4312
cfi=(36)
cfn=(3750)
calls=1078 415 
* 30184
+1 2156

fn=(1510)
106 5116
+2 5116
cfi=(36)
cfn=(1512)
calls=1279 415 
* 35812
+1 2558

fn=(4394)
147 14
+2 10
fi=(37)
499 6
cfn=(936)
calls=2 95 
* 100
* 20
-28 8
cfn=(868)
calls=2 81 
* 18
* 2
+1 8
cfn=(868)
calls=2 81 
* 18
* 2
+5 18
fe=(57)
149 2
+1 4
+2 2
+1 4

fn=(932)
156 210019887
+2 180017046
cfi=(36)
cfn=(934)
calls=30002841 471 
* 3270309674
* 30002841
+1 60005682
+1 90008511
+1 30002837
+1 60005674
-1 4
+1 8

fn=(4364)
106 4
+2 4
cfi=(36)
cfn=(4366)
calls=1 415 
* 28
+1 2

fn=(5160)
118 24
+2 24
cfi=(36)
cfn=(5162)
calls=4 -27 
* 140
+1 12

fn=(958)
94 20
+2 20
cfi=(36)
cfn=(960)
calls=5 415 
* 140
+1 10

fn=(1344)
106 8660
+2 8660
cfi=(36)
cfn=(1346)
calls=2165 415 
* 60620
+1 4330

fn=(4158)
106 4
+2 4
cfi=(36)
cfn=(3750)
calls=1 415 
* 28
+1 2

fn=(4386)
165 7
+2 6
cfi=(36)
cfn=(4388)
calls=1 471 
* 109
* 1
+1 2
+2 1
+1 2

fn=(866)
94 80088536
+2 60066402
fi=(37)
392 80088536
cfn=(868)
calls=20022134 81 
* 180199206
* 20022134
+4 40044268
fe=(57)
96 20022134
+1 40044268

fn=(912)
118 11010
+2 11010
fi=(37)
369 8808
cfn=(868)
calls=2202 81 
* 19818
* 2202
+5 8808
fe=(57)
121 6606

fn=(1292)
124 10
+2 10
fi=(37)
369 8
cfn=(868)
calls=2 81 
* 18
* 2
+5 8
fe=(57)
127 6

fn=(1352)
124 15
+2 18
cfi=(36)
cfn=(1354)
calls=3 405 
* 99
+1 9

fn=(3570)
94 2540
+2 2540
cfi=(36)
cfn=(3572)
calls=635 415 
* 17780
+1 1270

fn=(4162)
124 5
+2 6
cfi=(36)
cfn=(4164)
calls=1 405 
* 33
+1 3

fn=(5182)
94 2536
+2 2536
cfi=(36)
cfn=(5184)
calls=634 415 
* 17752
+1 1268

fn=(5190)
94 2536
+2 2536
cfi=(36)
cfn=(5192)
calls=634 415 
* 17752
+1 1268

fn=(904)
118 45
+2 54
cfi=(36)
cfn=(906)
calls=9 405 
* 297
+1 27

fn=(1064)
165 210019880
+2 180017040
cfi=(36)
cfn=(934)
calls=30002840 471 
* 3270309565
* 30002840
+1 60005680
+1 90008508
+1 30002836
+1 60005672
-1 4
+1 8

fn=(1366)
138 120017056
+2 90012792
cfi=(37)
cfn=(1368)
calls=30004264 303 
* 360051168
* 60008528
+1 60008528

fn=(1374)
94 8596
+2 8596
cfi=(36)
cfn=(1346)
calls=2149 415 
* 60172
+1 4298

fn=(5172)
94 2536
+2 2536
cfi=(36)
cfn=(5174)
calls=634 +5 
* 19020
+1 1268

fn=(1012)
132 40011248
+2 30008436
cfi=(37)
cfn=(1014)
calls=10002812 295 
* 90025308
* 20005624
+1 20005624

fn=(1072)
94 16
+2 16
cfi=(36)
cfn=(1074)
calls=4 415 
* 112
+1 8

fn=(1282)
106 10784
+2 8088
fi=(37)
392 10784
cfn=(868)
calls=2696 81 
* 24264
* 2696
+4 5392
fe=(57)
108 2696
+1 5392

fn=(2198)
124 5
+2 6
cfi=(36)
cfn=(2200)
calls=1 405 
* 33
+1 3

fl=(84)
fn=(1378)
80 4352
cfi=(62)
cfn=(1322)
calls=544 1014 
* 8704
* 1088

fn=(4092)
225 2685
0 5907
fi=(31)
cfi=(50)
cfn=(4096)
calls=537 993 
0 116752965585
0 1072

fn=(3042)
110 3252

fl=(136)
fn=(5272)
141 5
+1 6
+2 6
+4 9
+2 3

fn=(2870) QVarLengthArray<QChar, 256>::data()
165 35

fn=(5276)
167 7

fn=(5278)
77 4
+6 6
+2 3

fn=(5228)
230 5
+1 3
+2 5
cfi=(62)
cfn=(922)
calls=1 623 
* 5
+1 4
+5 4
+1 2
+7 3

fn=(5274)
109 21

fn=(2866) QVarLengthArray<QChar, 256>::QVarLengthArray(int)
230 25
+1 15
+2 25
cfi=(62)
cfn=(922)
calls=5 623 
* 25
+1 20
+5 20
+1 10
+3 40
+1 620
+1 750
cfi=(133)
cfn=(2728)
calls=150 -98 
* 1050
* 600
cfi=(114)
cfn=(2868)
calls=150 75 
* 1200
-1 150
+3 15

fn=(2872) QVarLengthArray<QChar, 256>::~QVarLengthArray()
77 20
+2 40
+1 1545
+3 30
+2 15

fl=(64)
fn=(2784)
148 48
+1 24
cfi=(103)
cfn=(2786) std::remove_reference<QList<QString>&>::type&& std::move<QList<QString>&>(QList<QString>&)
calls=8 -48 
* 48
* 40
cfn=(2788) QList<QString>::QList(QList<QString>&&)
calls=8 -3 
* 192
* 40
cfn=(2790) QList<QString>::swap(QList<QString>&)
calls=8 +2 
* 552
* 32
cfn=(2798)
calls=8 814 
* 592
* 40

fn=(2890)
530 10
+1 10
cfn=(1008) QListData::size() const
calls=2 107 
* 26
* 6
cfi=(62)
cfn=(922)
calls=2 +92 
* 10
+1 10
cfn=(2892) QListData::at(int) const
calls=2 109 
* 36
* 4
cfn=(2894) QList<QResourceRoot*>::Node::t()
calls=2 132 
* 12
* 4

fn=(3284) QListSpecialMethods<QFileInfo>::~QListSpecialMethods()
69 36

fn=(3286) QList<QString>::isEmpty() const
185 14
cfn=(2184) QListData::isEmpty() const
calls=2 -77 
* 26
* 4

fn=(3358) QList<QString>::dealloc(QListData::Data*)
853 20
+3 24
-1 48
cfn=(3360) QList<QString>::node_destruct(QList<QString>::Node*, QList<QString>::Node*)
calls=4 481 
* 2730
+2 12
cfi=(66)
cfn=(3362)
calls=4 164 
* 640
+1 12

fn=(3438)
141 14
cfi=(155)
cfn=(3440)
calls=2 -86 
* 12
* 12

fn=(3448) QList<QByteArray>::node_construct(QList<QByteArray>::Node*, QByteArray const&)
423 6
+3 4
cfi=(133)
cfn=(2728)
calls=1 147 
* 7
* 6
cfi=(98)
cfn=(2276)
calls=1 +68 
* 66
+10 3

fn=(3716) QList<QString>::const_iterator::const_iterator(QList<QString>::Node*)
277 40

fn=(3768) QListSpecialMethods<QAbstractNativeEventFilter*>::QListSpecialMethods()
66 6

fn=(4082) QList<QObject*>::detach_helper_grow(int, int)
743 8
+2 3
cfn=(1022) QListData::begin() const
calls=1 110 
* 14
* 1
+1 6
cfi=(66)
cfn=(1024)
calls=1 77 
* 395
* 1
+3 3
cfn=(1022)
calls=1 110 
* 14
* 5
-1 3
cfn=(1022)
calls=1 110 
* 14
* 7
cfn=(4084) QList<QObject*>::node_copy(QList<QObject*>::Node*, QList<QObject*>::Node*, QList<QObject*>::Node*)
calls=1 446 
* 21
+9 3
-1 2
+1 3
cfn=(1042) QListData::end() const
calls=1 111 
* 14
* 1
-1 3
cfn=(1022)
calls=1 110 
* 14
* 13
cfn=(4084)
calls=1 446 
* 21
+10 3
cfi=(65)
cfn=(1044)
calls=1 59 
* 51
* 3
+3 3
cfn=(1022)
calls=1 110 
* 14
* 5
+1 5

fn=(4446) QList<QTimerInfo*>::detach_helper_grow(int, int)
743 8
+2 3
cfn=(1022)
calls=1 110 
* 14
* 1
+1 6
cfi=(66)
cfn=(1024)
calls=1 77 
* 421
* 1
+3 3
cfn=(1022)
calls=1 110 
* 14
* 5
-1 3
cfn=(1022)
calls=1 110 
* 14
* 7
cfn=(4448) QList<QTimerInfo*>::node_copy(QList<QTimerInfo*>::Node*, QList<QTimerInfo*>::Node*, QList<QTimerInfo*>::Node*)
calls=1 446 
* 21
+9 3
-1 2
+1 3
cfn=(1042)
calls=1 111 
* 14
* 1
-1 3
cfn=(1022)
calls=1 110 
* 14
* 13
cfn=(4448)
calls=1 446 
* 21
+10 3
cfi=(65)
cfn=(1044)
calls=1 59 
* 51
* 3
+3 3
cfn=(1022)
calls=1 110 
* 14
* 6
+1 5

fn=(4466) QList<QPointer<QObject> >::QList()
141 7
cfn=(4468) QListSpecialMethods<QPointer<QObject> >::QListSpecialMethods()
calls=1 -75 
* 6
* 6

fn=(4632) QList<QTimerInfo*>::const_iterator::operator*() const
288 12896
cfn=(4634) QList<QTimerInfo*>::Node::t()
calls=1612 132 
* 9672
* 3224

fn=(4634)
132 6453
+2 6453

fn=(4718) QList<QTimerInfo*>::isEmpty() const
185 15050
cfn=(2184)
calls=2150 -77 
* 27950
* 4300

fn=(988)
141 49
cfn=(990) QListSpecialMethods<QResourceRoot*>::QListSpecialMethods()
calls=7 -75 
* 42
* 42

fn=(1040) QList<QResourceRoot*>::node_copy(QList<QResourceRoot*>::Node*, QList<QResourceRoot*>::Node*, QList<QResourceRoot*>::Node*)
446 14
+2 4
+27 18
+3 6

fn=(1152)
141 7
cfn=(1154) QListSpecialMethods<QTranslator*>::QListSpecialMethods()
calls=1 -75 
* 6
* 6

fn=(3252)
796 14
+1 8
+2 8
cfi=(65)
cfn=(2278)
calls=2 48 
* 100
* 6
+12 12

fn=(3740)
297 22

fn=(4086) QList<QObject*>::node_construct(QList<QObject*>::Node*, QObject* const&)
423 5
+8 4
+5 3

fn=(4732) QList<QTimerInfo*>::iterator::operator*() const
231 4312
cfn=(4634)
calls=539 -99 
* 3234
* 1078

fn=(990)
66 72

fn=(1046) QList<QResourceRoot*>::node_construct(QList<QResourceRoot*>::Node*, QResourceRoot* const&)
423 5
+8 4
+5 3

fn=(1154)
66 6

fn=(1494) QList<QTextCodec*>::QList()
141 7
cfn=(1496) QListSpecialMethods<QTextCodec*>::QListSpecialMethods()
calls=1 -75 
* 6
* 6

fn=(2170) QList<QTextCodec*>::const_iterator::const_iterator(QList<QTextCodec*>::Node*)
277 20

fn=(2182)
185 7
cfn=(2184)
calls=1 -77 
* 13
* 2

fn=(2184)
108 36309

fn=(2844)
185 35
cfn=(2184)
calls=5 -77 
* 65
* 10

fn=(3282)
814 24
+2 24
cfi=(65)
cfn=(1044)
calls=6 59 
* 306
* 18
+2 18
cfn=(3284)
calls=6 69 
* 36
* 18

fn=(3292) QList<QString>::detach_helper_grow(int, int)
743 32
+2 12
cfn=(1022)
calls=4 110 
* 56
* 4
+1 24
cfi=(66)
cfn=(1024)
calls=4 77 
* 1391
* 4
+3 12
cfn=(1022)
calls=4 110 
* 56
* 20
-1 12
cfn=(1022)
calls=4 110 
* 56
* 28
cfn=(3294) QList<QString>::node_copy(QList<QString>::Node*, QList<QString>::Node*, QList<QString>::Node*)
calls=4 446 
* 60
+9 12
-1 8
+1 12
cfn=(1042)
calls=4 111 
* 56
* 4
-1 12
cfn=(1022)
calls=4 110 
* 56
* 52
cfn=(3294)
calls=4 446 
* 60
+10 12
cfi=(65)
cfn=(1044)
calls=4 59 
* 204
* 12
+3 12
cfn=(1022)
calls=4 110 
* 56
* 24
+1 20

fn=(3444) QList<QByteArray>::detach_helper_grow(int, int)
743 8
+2 3
cfn=(1022)
calls=1 110 
* 14
* 1
+1 6
cfi=(66)
cfn=(1024)
calls=1 77 
* 320
* 1
+3 3
cfn=(1022)
calls=1 110 
* 14
* 5
-1 3
cfn=(1022)
calls=1 110 
* 14
* 7
cfn=(3446) QList<QByteArray>::node_copy(QList<QByteArray>::Node*, QList<QByteArray>::Node*, QList<QByteArray>::Node*)
calls=1 446 
* 15
+9 3
-1 2
+1 3
cfn=(1042)
calls=1 111 
* 14
* 1
-1 3
cfn=(1022)
calls=1 110 
* 14
* 13
cfn=(3446)
calls=1 446 
* 15
+10 3
cfi=(65)
cfn=(1044)
calls=1 59 
* 51
* 3
+3 3
cfn=(1022)
calls=1 110 
* 14
* 6
+1 5

fn=(3714)
315 8
cfn=(1022)
calls=1 110 
* 14
* 5
cfn=(3716)
calls=1 -38 
* 10
* 3

fn=(3718)
319 24
cfn=(1042)
calls=3 111 
* 42
* 15
cfn=(3716)
calls=3 -42 
* 30
* 9

fn=(4012) QList<GPollFDWithQSocketNotifier*>::QList()
141 7
cfn=(4014) QListSpecialMethods<GPollFDWithQSocketNotifier*>::QListSpecialMethods()
calls=1 -75 
* 6
* 6

fn=(4080)
569 6
+2 4
cfi=(65)
cfn=(1018)
calls=1 93 
* 51
* 2
+1 5
cfn=(4082)
calls=1 743 
* 653
* 1
+2 6
cfn=(4086)
calls=1 423 
* 12
+26 5

fn=(4084)
446 14
+2 4
+27 18
+3 6

fn=(4626) QList<QTimerInfo*>::const_iterator::const_iterator(QList<QTimerInfo*>::Node*)
277 37560

fn=(4730) QList<QTimerInfo*>::iterator::iterator(QList<QTimerInfo*>::Node*)
225 16110

fn=(4820) QList<QTimerInfo*>::const_iterator::operator++()
297 5896

fn=(4822) QList<QTimerInfo*>::removeFirst()
341 2144
0 1608
fi=(31)
cfn=(4718)
calls=536 185 
0 11792
0 1608
fi=(31)
cfi=(62)
cfn=(922)
calls=536 623 
0 2680
0 2680
fi=(31)
cfn=(4724) QList<QTimerInfo*>::begin()
calls=536 312 
0 55744
0 3216
fi=(31)
cfn=(4826) QList<QTimerInfo*>::erase(QList<QTimerInfo*>::iterator)
calls=536 518 
0 231016
0 1608

fn=(4830) QList<QTimerInfo*>::node_destruct(QList<QTimerInfo*>::Node*)
439 2144
+4 1608

fn=(5230)
160 56
cfn=(1008)
calls=8 -53 
* 104
* 16

fn=(1016)
569 6
+2 4
cfi=(65)
cfn=(1018)
calls=1 93 
* 51
* 2
+1 5
cfn=(1020) QList<QResourceRoot*>::detach_helper_grow(int, int)
calls=1 743 
* 2207
* 1
+2 6
cfn=(1046)
calls=1 423 
* 12
+26 5

fn=(1140)
141 4480
cfn=(1142) QListSpecialMethods<QObject*>::QListSpecialMethods()
calls=640 -75 
* 3840
* 3840

fn=(1496)
66 6

fn=(2172)
319 8
cfn=(1042)
calls=1 111 
* 14
* 5
cfn=(2170)
calls=1 -42 
* 10
* 3

fn=(2804) QList<QResourceRoot*>::operator=(QList<QResourceRoot*>&&)
148 30
+1 15
cfi=(103)
cfn=(2806) std::remove_reference<QList<QResourceRoot*>&>::type&& std::move<QList<QResourceRoot*>&>(QList<QResourceRoot*>&)
calls=5 -48 
* 30
* 25
cfn=(2808) QList<QResourceRoot*>::QList(QList<QResourceRoot*>&&)
calls=5 -3 
* 120
* 25
cfn=(2810) QList<QResourceRoot*>::swap(QList<QResourceRoot*>&)
calls=5 +2 
* 345
* 20
cfn=(2812)
calls=5 814 
* 370
* 25

fn=(2814) QListSpecialMethods<QResourceRoot*>::~QListSpecialMethods()
69 66

fn=(3274) QList<QFileInfo>::operator=(QList<QFileInfo>&&)
148 12
+1 6
cfi=(103)
cfn=(3276) std::remove_reference<QList<QFileInfo>&>::type&& std::move<QList<QFileInfo>&>(QList<QFileInfo>&)
calls=2 -48 
* 12
* 10
cfn=(3278) QList<QFileInfo>::QList(QList<QFileInfo>&&)
calls=2 -3 
* 48
* 10
cfn=(3280) QList<QFileInfo>::swap(QList<QFileInfo>&)
calls=2 +2 
* 138
* 8
cfn=(3282)
calls=2 814 
* 148
* 10

fn=(3580)
185 4445
cfn=(2184)
calls=635 -77 
* 8255
* 1270

fn=(4184)
141 7
cfn=(4186) QListSpecialMethods<void (*)()>::QListSpecialMethods()
calls=1 -75 
* 6
* 6

fn=(4720) QList<QTimerInfo*>::first()
335 2156
0 1617
fi=(31)
cfn=(4718)
calls=539 185 
0 11858
0 1617
fi=(31)
cfi=(62)
cfn=(922)
calls=539 623 
0 2695
0 2695
fi=(31)
cfn=(4724)
calls=539 312 
0 56056
0 1617
fi=(31)
cfn=(4732)
calls=539 231 
0 8624
0 1078

fn=(4826)
518 3752
+2 2680
cfn=(4828) QList<QTimerInfo*>::isValidIterator(QList<QTimerInfo*>::iterator const&) const
calls=536 402 
* 64856
* 2144
cfi=(62)
cfn=(922)
calls=536 623 
* 2680
+1 2144
cfi=(65)
cfn=(1018)
calls=536 93 
* 25728
* 1072
+5 3216
cfn=(4830)
calls=536 -87 
* 3752
+1 3216
cfi=(66)
cfn=(4832)
calls=536 330 
* 105056
* 2680
cfn=(4730)
calls=536 225 
* 5360
+1 2680

fn=(1142)
66 3840

fn=(2168)
315 8
cfn=(1022)
calls=1 110 
* 14
* 5
cfn=(2170)
calls=1 -38 
* 10
* 3

fn=(3246) QList<QFileInfo>::QList()
141 28
cfn=(3248) QListSpecialMethods<QFileInfo>::QListSpecialMethods()
calls=4 -75 
* 24
* 24

fn=(3278)
146 10
+1 6
cfn=(3248)
calls=2 -81 
* 12
* 20

fn=(3290)
569 48
+2 32
cfi=(65)
cfn=(1018)
calls=8 93 
* 396
* 16
+1 20
cfn=(3292)
calls=4 743 
* 2379
* 4
+2 24
cfn=(3296) QList<QString>::node_construct(QList<QString>::Node*, QString const&)
calls=4 423 
* 532
+26 4
-10 24
cfn=(3296)
calls=4 423 
* 532
+2 12
cfi=(66)
cfn=(5224)
calls=4 191 
* 1014
* 4
+5 12
+3 36

fn=(3294)
446 56
+2 16
+16 24
+14 24

fn=(3442)
569 6
+2 4
cfi=(65)
cfn=(1018)
calls=1 93 
* 51
* 2
+1 5
cfn=(3444)
calls=1 743 
* 567
* 1
+2 6
cfn=(3448)
calls=1 423 
* 92
+26 5

fn=(3446)
446 14
+2 4
+16 6
+14 6

fn=(3720)
292 36

fn=(3766)
141 7
cfn=(3768)
calls=1 -75 
* 6
* 6

fn=(4186)
66 6

fn=(4624) QList<QTimerInfo*>::constBegin() const
315 12880
cfn=(1022)
calls=1610 110 
* 22540
* 8050
cfn=(4626)
calls=1610 -38 
* 16100
* 4830

fn=(4628) QList<QTimerInfo*>::constEnd() const
319 17168
cfn=(1042)
calls=2146 111 
* 30044
* 10730
cfn=(4626)
calls=2146 -42 
* 21460
* 6438

fn=(4724)
312 8600
cfn=(4726) QList<QTimerInfo*>::detach()
calls=1075 162 
* 65575
* 3225
cfn=(1022)
calls=1075 110 
* 15050
* 5375
cfn=(4730)
calls=1075 -87 
* 10750
* 3225

fn=(4842)
160 3752
cfn=(1008)
calls=536 -53 
* 6968
* 1072

fn=(1020)
743 8
+2 3
cfn=(1022)
calls=1 110 
* 14
* 1
+1 6
cfi=(66)
cfn=(1024)
calls=1 77 
* 1948
* 1
+3 3
cfn=(1022)
calls=1 110 
* 14
* 5
-1 3
cfn=(1022)
calls=1 110 
* 14
* 7
cfn=(1040)
calls=1 446 
* 21
+9 3
-1 2
+1 3
cfn=(1042)
calls=1 111 
* 14
* 1
-1 3
cfn=(1022)
calls=1 110 
* 14
* 13
cfn=(1040)
calls=1 446 
* 21
+10 3
cfi=(65)
cfn=(1044)
calls=1 59 
* 51
* 3
+3 3
cfn=(1022)
calls=1 110 
* 14
* 6
+1 5

fn=(1042)
111 30226

fn=(2174)
292 12

fn=(2190) QList<QTextCodec*>::detach_helper_grow(int, int)
743 8
+2 3
cfn=(1022)
calls=1 110 
* 14
* 1
+1 6
cfi=(66)
cfn=(1024)
calls=1 77 
* 322
* 1
+3 3
cfn=(1022)
calls=1 110 
* 14
* 5
-1 3
cfn=(1022)
calls=1 110 
* 14
* 7
cfn=(2192) QList<QTextCodec*>::node_copy(QList<QTextCodec*>::Node*, QList<QTextCodec*>::Node*, QList<QTextCodec*>::Node*)
calls=1 446 
* 21
+9 3
-1 2
+1 3
cfn=(1042)
calls=1 111 
* 14
* 1
-1 3
cfn=(1022)
calls=1 110 
* 14
* 13
cfn=(2192)
calls=1 446 
* 21
+10 3
cfi=(65)
cfn=(1044)
calls=1 59 
* 51
* 3
+3 3
cfn=(1022)
calls=1 110 
* 14
* 6
+1 5

fn=(2782)
862 20
+2 15
cfn=(2440)
calls=5 141 
* 95
* 25
cfn=(2784)
calls=5 148 
* 1005
* 15
cfn=(2798)
calls=5 -50 
* 370
+1 15

fn=(2810)
151 50
cfi=(62)
cfn=(2792)
calls=5 860 
* 280
* 15

fn=(2812)
814 44
+2 44
cfi=(65)
cfn=(1044)
calls=11 59 
* 561
* 33
+2 33
cfn=(2814)
calls=11 69 
* 66
* 33

fn=(2892)
109 126

fn=(3248)
66 36

fn=(3296)
423 54
+3 36
cfi=(133)
cfn=(2728)
calls=9 147 
* 63
* 54
cfi=(72)
cfn=(2320)
calls=9 889 
* 963
+10 27

fn=(3614) QList<QByteArray>::node_destruct(QList<QByteArray>::Node*, QList<QByteArray>::Node*)
481 6
+5 10
cfi=(98)
cfn=(2154)
calls=1 -21 
* 65
* 1
+1 3

fn=(3628) QListSpecialMethods<QObject*>::~QListSpecialMethods()
69 3810

fn=(4188)
333 7
cfn=(1008)
calls=1 107 
* 13
* 2

fn=(4468)
66 6

fn=(4712) QList<GPollFDWithQSocketNotifier*>::count() const
333 3766
cfn=(1008)
calls=538 107 
* 6994
* 1076

fn=(2192)
446 14
+2 4
+27 18
+3 6

fn=(2788)
146 40
+1 24
cfi=(120)
cfn=(2442)
calls=8 -90 
* 48
* 80

fn=(3280)
151 20
cfi=(62)
cfn=(2792)
calls=2 860 
* 112
* 6

fn=(3610)
814 4
+2 4
cfi=(65)
cfn=(1044)
calls=1 59 
* 84
* 3
+1 6
cfn=(3612) QList<QByteArray>::dealloc(QListData::Data*)
calls=1 +36 
* 274
+1 3
cfi=(155)
cfn=(3616)
calls=1 60 
* 6
* 3

fn=(4034) QList<QTimerInfo*>::QList()
141 7
cfn=(4036) QListSpecialMethods<QTimerInfo*>::QListSpecialMethods()
calls=1 -75 
* 6
* 6

fn=(4442) QList<QTimerInfo*>::size() const
160 3759
cfn=(1008)
calls=537 -53 
* 6981
* 1074

fn=(4448)
446 14
+2 4
+27 18
+3 6

fn=(4630) QList<QTimerInfo*>::const_iterator::operator!=(QList<QTimerInfo*>::const_iterator const&) const
292 19320

fn=(4828)
402 4288
+2 3216
cfn=(4624)
calls=536 -89 
* 21440
* 6968
cfn=(4628)
calls=536 -85 
* 21440
* 4288
+1 3216

fn=(2188)
603 6
+2 4
cfi=(65)
cfn=(1018)
calls=1 93 
* 51
* 2
+1 5
cfn=(2190)
calls=1 743 
* 581
* 1
+2 6
cfn=(2194) QList<QTextCodec*>::node_construct(QList<QTextCodec*>::Node*, QTextCodec* const&)
calls=1 423 
* 12
+26 5

fn=(2194)
423 5
+8 4
+5 3

fn=(2894)
132 6
+2 6

fn=(3360)
481 24
+5 75
cfi=(72)
cfn=(2230)
calls=9 1065 
* 2610
* 9
+1 12

fn=(3612)
853 5
+3 6
-1 12
cfn=(3614)
calls=1 481 
* 85
+2 3
cfi=(66)
cfn=(3362)
calls=1 164 
* 160
+1 3

fn=(3626)
814 2540
+2 2540
cfi=(65)
cfn=(1044)
calls=635 59 
* 32385
* 1905
+2 1905
cfn=(3628)
calls=635 69 
* 3810
* 1905

fn=(4014)
66 6

fn=(4036)
66 6

fn=(4450) QList<QTimerInfo*>::node_construct(QList<QTimerInfo*>::Node*, QTimerInfo* const&)
423 2685
+8 2148
+5 1611

fn=(1006)
160 56
cfn=(1008)
calls=8 -53 
* 104
* 16

fn=(1008)
107 21255

fn=(1022)
110 38248

fn=(2440)
141 119
cfi=(120)
cfn=(2442)
calls=17 -84 
* 102
* 102

fn=(2790)
151 80
cfi=(62)
cfn=(2792)
calls=8 860 
* 448
* 24

fn=(2798)
814 100
+2 100
cfi=(65)
cfn=(1044)
calls=25 59 
* 1407
* 75
+1 24
cfn=(3358)
calls=4 +36 
* 3486
+1 75
cfi=(120)
cfn=(2800)
calls=25 62 
* 150
* 75

fn=(2802)
862 20
+2 15
cfn=(988)
calls=5 141 
* 95
* 25
cfn=(2804)
calls=5 148 
* 1005
* 15
cfn=(2812)
calls=5 -50 
* 370
+1 15

fn=(2808)
146 25
+1 15
cfn=(990)
calls=5 -81 
* 30
* 50

fn=(3272) QList<QFileInfo>::clear()
862 8
+2 6
cfn=(3246)
calls=2 141 
* 38
* 10
cfn=(3274)
calls=2 148 
* 402
* 6
cfn=(3282)
calls=2 -50 
* 148
+1 6

fn=(3704)
603 6
+2 4
cfi=(65)
cfn=(1018)
calls=1 93 
* 48
* 2
+19 6
cfn=(3296)
calls=1 423 
* 133
+2 3
cfi=(66)
cfn=(3706)
calls=1 202 
* 2143
* 1
+5 3
+3 5

fn=(3722)
288 16
cfn=(3724) QList<QString>::Node::t()
calls=2 132 
* 12
* 4

fn=(3724)
132 21
+2 21

fn=(4444) QList<QTimerInfo*>::insert(int, QTimerInfo* const&)
637 3759
+2 2148
cfi=(65)
cfn=(1018)
calls=537 93 
* 25779
* 1074
+1 6
cfn=(4446)
calls=1 743 
* 680
* 1
+2 6
cfn=(4450)
calls=1 423 
* 12
+26 1
-10 3216
cfn=(4450)
calls=536 423 
* 6432
+2 2680
cfi=(66)
cfn=(4838)
calls=536 220 
* 83616
* 536
+5 1608
+3 2684

fn=(4726)
162 4300
0 4300
fi=(31)
cfi=(65)
cfn=(1018)
calls=1075 93 
0 51600
0 5375

fn=(5232)
530 25
+1 25
cfn=(1008)
calls=5 107 
* 65
* 15
cfi=(62)
cfn=(922)
calls=5 +92 
* 25
+1 25
cfn=(2892)
calls=5 109 
* 90
* 10
cfn=(3724)
calls=5 132 
* 30
* 10

fl=(171) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qtimerinfo_unix.cpp
fn=(4622) QTimerInfoList::repairTimersIfNeeded()
154 4296
+1 1074
cfi=(80)
cfn=(4038)
calls=1074 -14 
* 70884
* 2148
+1 1074
+4 2148

fn=(4402) QTimerInfoList::registerTimer(int, int, Qt::TimerType, QObject*)
440 8
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 216
* 1
* 1
+1 3
+1 3
+1 3
+1 3
+1 2
+2 3
cfn=(4404) QTimerInfoList::updateCurrentTime()
calls=1 83 
* 3174
* 7
cfn=(4422) operator+(timespec const&, int)
calls=1 192 
* 77
* 2
+2 3
+12 2
+4 5
+1 2
+3 2
+1 7
cfn=(4430) calculateCoarseTimerTimeout(QTimerInfo*, timespec)
calls=1 224 
* 210
+2 2
+17 5
cfn=(4440) QTimerInfoList::timerInsert(QTimerInfo*)
calls=1 174 
* 822
+10 3

fn=(4620) QTimerInfoList::timerWait(timespec&)
380 3228
+1 1614
cfn=(4404)
calls=538 83 
* 74244
* 1076
+1 1614
cfn=(4622)
calls=538 154 
* 40888
+3 538
+1 2690
cfi=(64)
cfn=(4624)
calls=538 -71 
* 21520
* 2690
cfi=(64)
cfn=(4628)
calls=538 -67 
* 21520
* 2690
cfi=(64)
cfn=(4630)
calls=538 -94 
* 6456
* 1076
+1 1614
cfi=(64)
cfn=(4632)
calls=538 -99 
* 8608
* 3228
+1 1614
cfi=(64)
cfn=(4632)
calls=538 288 
* 8608
* 1076
+1 538
+4 1076
+3 3228
cfi=(162)
cfn=(4436)
calls=538 106 
* 10243
* 1076
+2 18
cfi=(186) /home/tsenyk/qt5/qt5/qtbase/src/corelib/kernel/qcore_unix_p.h
cfn=(4636) operator-(timespec const&, timespec const&)
calls=3 125 
* 171
* 18
cfn=(4640) roundToMillisecond(timespec)
calls=3 198 
* 144
* 12
+3 1070
+1 1070
+3 535
+1 2140
-1 3
+1 12

fn=(4404)
83 5390
+1 2156
cfi=(80)
cfn=(4406)
calls=1078 +76 
* 133474
* 6468
+1 4312

fn=(4640)
198 24
+4 39
+1 18
+1 9
cfi=(186)
cfn=(4426) normalizedTimespec(timespec&)
calls=3 94 
* 42
* 6
+1 6

fn=(4836) calculateNextTimeout(QTimerInfo*, timespec)
334 4824
+1 3216
+3 3752
cfn=(4424) operator+=(timespec&, int)
calls=536 185 
* 31973
+1 3216
cfi=(162)
cfn=(4436)
calls=536 106 
* 7515
* 1072
+1 2675
+1 3745
cfn=(4424)
calls=535 185 
* 31810
+9 2144
+1 3216
cfn=(4430)
calls=536 224 
* 111217
+1 1608
+21 1072

fn=(4430)
224 4833
+17 1611
+1 3759
+1 1611
cfi=(62)
cfn=(922)
calls=537 623 
* 2685
+3 3222
+2 1074
+18 4833
cfi=(62)
cfn=(3080)
calls=537 547 
* 7514
* 1074
+1 5370
cfi=(62)
cfn=(4432)
calls=537 545 
* 6982
* 1074
+5 1611
+1 4
+1 4
+1 1599
+1 1
+1 1
+9 5852
+7 5852
+2 3192
+1 2128
+3 2128
+2 1064
+12 2660
+1 3192
+1 1596
+1 1555
cfi=(62)
cfn=(5384)
calls=311 547 
* 4317
* 933
+2 1989
cfi=(62)
cfn=(4432)
calls=221 545 
* 2889
* 442
+4 1074
+1 5
+1 3
+2 2680
+3 3216
cfi=(162)
cfn=(4436)
calls=536 106 
* 13088
* 6
cfi=(162)
cfn=(4436)
calls=1 106 
* 19
* 1074
+2 1611

fn=(4422)
192 5
+1 5
+1 5
cfn=(4424)
calls=1 -9 
* 58
* 2
+1 2

fn=(4818) QTimerInfoList::activateTimers()
563 2680
+1 3752
cfi=(64)
cfn=(4718)
calls=536 185 
* 11792
* 2680
+3 1072
+1 1072
+2 1608
cfn=(4404)
calls=536 83 
* 73968
* 1072
+2 1608
cfn=(4622)
calls=536 154 
* 40736
+4 2680
cfi=(64)
cfn=(4624)
calls=536 315 
* 21440
* 5360
cfi=(64)
cfn=(4628)
calls=1072 319 
* 42880
* 5360
cfi=(64)
cfn=(4630)
calls=1072 292 
* 12864
* 2144
+1 1608
cfi=(64)
cfn=(4632)
calls=536 288 
* 8576
* 3216
cfi=(162)
cfn=(4436)
calls=536 106 
* 10190
* 1072
+2 536
-3 1608
cfi=(64)
cfn=(4820)
calls=536 297 
* 5896
* 536
+7 7497
+1 1608
cfi=(64)
cfn=(4718)
calls=536 185 
* 11792
* 1072
+3 1608
cfi=(64)
cfn=(4720)
calls=536 335 
* 89512
* 1072
+1 3216
cfi=(162)
cfn=(4436)
calls=536 106 
* 10190
* 1072
+3 2144
+1 2144
+10 1608
cfi=(64)
cfn=(4822)
calls=536 341 
* 314096
+23 3216
cfn=(4836)
calls=536 334 
* 213055
+3 2680
cfn=(4440)
calls=536 174 
* 159192
+1 2144
+1 536
+2 2144
+2 1608
+2 3216
cfi=(51)
cfn=(4840)
calls=536 499 
* 25728
+1 3216
cfi=(84)
cfn=(4092)
calls=536 225 
* 116752973756
+2 1605
+1 1070
-4 1605
cfi=(51)
cfn=(5358)
calls=535 506 
* 23005
-53 535
+61 1070
+2 1070
+1 2140

fn=(4032) QTimerInfoList::QTimerInfoList()
58 8
cfi=(64)
cfn=(4034)
calls=1 +83 
* 19
+3 1
cfi=(80)
cfn=(4038)
calls=1 +80 
* 66
* 3
+11 6
+1 2
+1 2
+1 2
+4 2
+1 5

fn=(4424)
185 5360
+1 16080
+1 20368
+1 3216
cfi=(186)
cfn=(4426)
calls=1072 -94 
* 16673
+1 2144

fn=(4440)
174 2685
+1 1611
cfi=(64)
cfn=(4442)
calls=537 -15 
* 11814
* 537
+1 3759
+5 3759
cfi=(64)
cfn=(4444)
calls=537 637 
* 134238
+1 1611

fl=(61)
fn=(4154)
176 5
+2 3
cfi=(35)
cfn=(4156)
calls=1 +80 
* 47
* 5
cfi=(35)
cfn=(4160)
calls=1 +81 
* 60
+1 1
+1 2

fn=(996) QAtomicInteger<int>::QAtomicInteger(int)
53 100000830
cfi=(35)
cfn=(998)
calls=10000083 234 
* 360002988
* 30000249

fn=(1202)
164 30
cfi=(35)
cfn=(1204)
calls=3 330 
* 108
* 9

fn=(1340)
176 10
+2 6
cfi=(35)
cfn=(1342)
calls=2 +80 
* 94
* 10
cfi=(35)
cfn=(1350)
calls=2 +81 
* 120
+1 2
+1 4

fn=(994)
155 100000830
cfn=(996)
calls=10000083 53 
* 490004067
* 30000249

fn=(1144)
164 6400
cfi=(35)
cfn=(1146)
calls=640 330 
* 23040
* 1920

fn=(1210)
164 20
cfi=(35)
cfn=(1212)
calls=2 330 
* 72
* 6

fn=(1498) QAtomicPointer<QTextCodec>::QAtomicPointer(QTextCodec*)
164 10
cfi=(35)
cfn=(1500)
calls=1 330 
* 36
* 3

fn=(894)
164 20
cfi=(35)
cfn=(896)
calls=2 330 
* 72
* 6

fn=(4248) QAtomicPointer<int const>::QAtomicPointer(int const*)
164 100000010
cfi=(35)
cfn=(4250)
calls=10000001 330 
* 360000036
* 30000003

fl=(82) /home/tsenyk/qt5/qt5/qtbase/src/corelib/thread/qthread.h
fn=(1336) QThread::d_func()
122 4
fi=(83) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/thread/qthread.h
* 4
cfi=(62)
cfn=(1322)
calls=1 1014 
* 16
* 2
fe=(82)

fl=(88)
fn=(1472)
54 2562
+1 2562
cfi=(56)
cfn=(1474)
calls=1281 +74 
* 93797
+1 2562

fn=(1480) (anonymous namespace)::Q_QGS_globalInstance::innerFunction()::Holder::Holder()
39 8
cfn=(1482) (anonymous namespace)::Q_QGS_globalInstance::innerFunction()::HolderBase::HolderBase()
calls=1 * 
* 6
* 3
cfn=(1484) QCoreGlobalData::QCoreGlobalData()
calls=1 +2 
* 1361
* 3
cfi=(35)
cfn=(910)
calls=1 +78 
* 44
* 5

fn=(1478)
39 11531
cob=(13)
cfi=(19)
cfn=(618)
calls=1 243 
* 36
* 1
* 7
cfn=(1480)
calls=1 * 
* 1430
* 2
cob=(13)
cfi=(19)
cfn=(624)
calls=1 388 
* 15
* 1
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 -39 
* 66
* 1
* 7686

fn=(1484)
41 5
+1 3
cfi=(89) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qmap.h
cfn=(1486) QMap<QString, QStringList>::QMap()
calls=1 324 
* 9
* 5
cfi=(90)
cfn=(1488)
calls=1 +69 
* 1244
* 4
cfi=(64)
cfn=(1494)
calls=1 +99 
* 19
* 5
cfi=(61)
cfn=(1498)
calls=1 164 
* 49
* 4
cfi=(92)
cfn=(1506)
calls=1 235 
* 9
+2 5

fn=(1482)
39 6

fl=(131)
fn=(2730)
330 25
+2 20
cfn=(2732) QVariantIsNull<(anonymous namespace)::CoreTypesFilter>::CallIsNull<QChar, true>::isNull(QVariant::Private const*)
calls=5 -21 
* 185
+1 10

fn=(2702)
336 36

fn=(2698)
326 32
+1 24
+1 24

fn=(2732)
311 20
+2 15
cfn=(2734) QVariantIsNull<(anonymous namespace)::CoreTypesFilter>::CallFilteredIsNull<QChar, true>::isNull(QVariant::Private const*)
calls=5 -19 
* 140
+1 10

fn=(2726) void v_construct_helper<QChar>(QVariant::Private*, QChar const&, QtPrivate::integral_constant<bool, true>)
115 25
+2 20
cfi=(133)
cfn=(2728)
calls=5 +30 
* 35
* 25
+1 20
+1 15

fn=(2734)
294 20
+2 20
cfn=(2736)
calls=5 85 
* 35
* 10
cfi=(114)
cfn=(2578)
calls=5 429 
* 45
+1 10

fn=(2724)
143 25
+3 35
cfn=(2726)
calls=5 -31 
* 140
* 5
+1 15

fn=(2736)
85 40
+4 10
+1 20

fl=(178)
fn=(4234)
179 30000003
+1 40000004

fl=(85)
fn=(1382)
66 14

fl=(143)
fn=(3736)
181 8
fi=(110)
* 10
cfi=(95)
cfn=(3108)
calls=2 -45 
* 104
* 8
cfi=(95)
cfn=(3094)
calls=2 -53 
* 14
* 8
fe=(143)

fn=(3092)
158 36
fi=(110)
+2 18
cfi=(95)
cfn=(3094)
calls=6 -32 
* 42
* 30
cfi=(95)
cfn=(3098)
calls=6 -25 
* 312
* 24
cfi=(95)
cfn=(3094)
calls=6 -32 
* 42
* 24
cfi=(95)
cfn=(3094)
calls=6 -32 
* 42
* 12
+1 24
fe=(143)

fl=(169)
fn=(4618) timerSourcePrepareHelper(GTimerSource*, int*)
124 3228
+1 1076
+1 2690
cfi=(95)
cfn=(4544)
calls=538 +10 
* 27976
* 2690
cfi=(95)
cfn=(4554)
calls=538 +13 
* 4842
* 4304
cfi=(171)
cfn=(4620)
calls=538 380 
* 227946
* 3766
+1 9146
+4 3228
+1 2152

fn=(4714) timerSourceCheck(_GSource*)
163 2152
+1 1076
+1 2152
+1 1070
+1 9
cfn=(4716) timerSourceCheckHelper(GTimerSource*)
calls=3 -32 
* 1390
+1 1076

fn=(4750) postEventSourceDispatch(_GSource*, int (*)(void*), void*)
267 6
+1 2
+1 4
cfi=(35)
cfn=(864)
calls=1 116 
* 35
* 3
+1 3
cfi=(50)
cfn=(4752)
calls=1 1505 
* 568
+1 4
cfn=(4758) QEventDispatcherGlibPrivate::runTimersOnceWithNormalPriority()
calls=1 +76 
* 9
+1 1
+1 2

fn=(4398)
506 9
+2 6
+3 3
cfi=(53)
cfn=(3770)
calls=1 1424 
* 95
* 4
cfi=(53)
cfn=(3770)
calls=1 1424 
* 95
* 5
cfi=(53)
cfn=(3770)
calls=1 1424 
* 95
* 2
cfi=(74)
cfn=(1174)
calls=1 362 
* 113
* 5
+6 3
cfi=(185)
cfn=(4400)
calls=1 60 
* 26
* 1
+1 10
cfi=(171)
cfn=(4402)
calls=1 -78 
* 4568
+1 4

fn=(4778) idleTimerSourcePrepare(_GSource*, int*)
196 2685
+1 1074
+1 1611
+1 2685
+2 4
+1 4
+1 4
+3 2675
cfn=(4618)
calls=535 -82 
* 291040
+1 1074

fn=(3758)
594 2
+4 1
+2 2

fn=(3760)
351 7
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 43 
* 349
* 1
* 4
cfn=(3762) QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*)
calls=1 -67 
* 27630
* 6
cfi=(172)
cfn=(4070)
calls=1 145 
* 3000
* 4
+2 6

fn=(3762)
285 8
+1 3
cfi=(170)
cfn=(3764)
calls=1 59 
* 197
* 7
+11 4
+3 1
cfi=(84)
cfn=(3042)
calls=1 110 
* 6
* 1
+1 3
cfi=(74)
cfn=(1174)
calls=1 +61 
* 113
* 4
cfi=(53)
cfn=(3770)
calls=1 1424 
* 95
* 6
+1 1
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 9383
* 5
* 3
+1 4
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1313
* 5
* 1
+7 4
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 4461
* 5
+4 3
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1655
* 5
* 3
+2 6
cfi=(35)
cfn=(910)
calls=1 117 
* 44
+1 4
+1 5
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1369
* 5
+1 7
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 3926
* 5
+4 3
cob=(8)
cfi=(8)
cfn=(3902)
calls=1 0 
* 500
* 1
* 1
-1 2
+3 6
cfi=(133)
cfn=(2728)
calls=1 147 
* 7
* 4
cfi=(64)
cfn=(4012)
calls=1 141 
* 19
+1 5
cob=(8)
cfi=(8)
cfn=(3908)
calls=1 0 
* 19
* 1
+1 7
cob=(8)
cfi=(8)
cfn=(3914)
calls=1 0 
* 358
* 1
+3 3
cob=(8)
cfi=(8)
cfn=(3902)
calls=1 0 
* 567
* 1
* 3
+2 6
cfi=(133)
cfn=(2728)
calls=1 147 
* 7
* 5
cfi=(171)
cfn=(4032)
calls=1 58 
* 116
+1 6
cfi=(95)
cfn=(4040)
calls=1 111 
* 10
* 2
+1 3
+1 5
cob=(8)
cfi=(8)
cfn=(3908)
calls=1 0 
* 19
* 1
+1 7
cob=(8)
cfi=(8)
cfn=(3914)
calls=1 0 
* 346
* 1
+2 3
cob=(8)
cfi=(8)
cfn=(3902)
calls=1 0 
* 500
* 1
* 3
+2 5
+1 5
cob=(8)
cfi=(8)
cfn=(3908)
calls=1 0 
* 19
* 1
+1 5
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1421
* 5
+1 7
cob=(8)
cfi=(8)
cfn=(3914)
calls=1 0 
* 935
* 1
+1 7

fn=(4614) socketNotifierSourcePrepare(_GSource*, int*)
62 2152
+1 1076
+1 1076
+1 538
+1 1076

fn=(4810) idleTimerSourceCheck(_GSource*)
210 4
+1 2
+1 3
+1 5
+2 2
+3 2

fn=(4542)
399 2685
+1 1611
cfi=(185)
cfn=(4400)
calls=537 60 
* 13962
* 537
+2 2148
cfi=(95)
cfn=(4544)
calls=537 136 
* 27924
* 2148
cfi=(95)
cfn=(4546)
calls=537 128 
* 3759
* 1611
+1 1074
+1 1611
cfi=(190)
cfn=(4548)
calls=537 137 
* 93438
* 537
+5 2148
+1 2148
+2 2148
cfi=(95)
cfn=(4544)
calls=537 136 
* 27924
* 2148
cfi=(95)
cfn=(4554)
calls=537 139 
* 4833
* 1074
+5 3222
cob=(8)
cfi=(8)
cfn=(4560)
calls=536 0 
* 97394401336
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 9478
* 541
* 1608
+1 1078
+1 6
cob=(8)
cfi=(8)
cfn=(4560)
calls=1 0 
* 19361616883
* 1
* 3
-1 1
+3 2144
+2 1072
+1 1608
cfi=(190)
cfn=(4776)
calls=536 143 
* 93264
+2 536
+1 1072

fn=(4616) timerSourcePrepare(_GSource*, int*)
147 2690
+2 1076
+3 1076
+1 2152
+1 1070
+1 1070
+1 1070
+3 15
cfn=(4618)
calls=3 -35 
* 2004
+1 1076

fn=(4710) socketNotifierSourceCheck(_GSource*)
69 3228
+1 1076
+2 538
+1 4842
cfi=(64)
cfn=(4712)
calls=538 333 
* 11836
* 2690
+15 538
+1 2690

fn=(4808) postEventSourceCheck(_GSource*)
262 2148
+1 2148
cfn=(4602) postEventSourcePrepare(_GSource*, int*)
calls=537 -18 
* 308775
+1 1074

fn=(5360) idleTimerSourceDispatch(_GSource*, int (*)(void*), void*)
221 3210
+1 1605
+1 2675
cfn=(4816) timerSourceDispatch(_GSource*, int (*)(void*), void*)
calls=535 -52 
* 97392574018
+1 534
+1 1068

fn=(4758)
347 3
+1 3
+1 3

fn=(4816)
171 3216
+1 1072
+1 2680
cfi=(95)
cfn=(4544)
calls=536 -37 
* 27872
* 2144
cfi=(95)
cfn=(4546)
calls=536 -45 
* 3752
* 2144
+2 1072
+1 2144
cfi=(171)
cfn=(4818)
calls=536 563 
* 116754139228
+1 535
+1 1070

fn=(4602)
245 5375
+1 2150
cfi=(41)
cfn=(1176)
calls=1075 -8 
* 39775
* 1075
+1 2150
+4 2150
+1 1074
+1 1611
cfi=(173)
cfn=(4604) QThreadData::canWaitLocked()
calls=537 -9 
* 247020
* 1614
cfi=(173)
cfn=(4604)
calls=538 -9 
* 247480
* 1075
+1 6450
+2 2150
+1 2150
+1 6450
cfi=(35)
cfn=(864)
calls=1075 116 
* 37625
* 7525
+1 2148
-1 1
+1 2

fn=(4716)
135 15
+2 3
-1 12
cfi=(64)
cfn=(4718)
calls=3 +49 
* 66
+1 21
cfi=(95)
cfn=(4544)
calls=3 -1 
* 156
* 15
cfi=(95)
cfn=(4546)
calls=3 -9 
* 21
* 12
-1 6
+4 12
cfi=(64)
cfn=(4720)
calls=3 335 
* 501
* 18
cfi=(171)
cfn=(4404)
calls=3 -57 
* 414
* 18
cfi=(162)
cfn=(4436)
calls=3 -34 
* 77
* 6
+1 4
+2 1
+1 12

fl=(198)
fn=(5026)
142 3804
+2 6340
+1 6974
cfi=(114)
cfn=(2350)
calls=634 -98 
* 6974
* 3804
cfi=(114)
cfn=(2352)
calls=634 -63 
* 13948
* 5706
cfi=(86)
cfn=(2874)
calls=634 4469 
* 69106
* 5072
+1 3804
cfi=(86)
cfn=(5028)
calls=634 4992 
* 100806
+1 3170
+3 1268
-2 634
+1 1268
-1 2536
+2 1902
cfi=(39)
cfn=(5030)
calls=634 1659 
* 135089342
+2 3804
cfi=(205)
cfn=(5344)
calls=634 -97 
* 710968384
* 1902
cob=(13)
cfi=(127)
cfn=(2652)
calls=634 32 
* 58328
* 634
+2 3804

fl=(89)
fn=(1486)
324 9

fl=(109)
fn=(3244) QDirPrivate::QDirPrivate(QString const&, QStringList const&, QFlags<QDir::SortFlag>, QFlags<QDir::Filter>)
78 18
+5 6
cfi=(119)
cfn=(2934)
calls=2 -29 
* 146
* 12
cfi=(120)
cfn=(2438)
calls=2 +14 
* 58
* 8
cfi=(64)
cfn=(3246)
calls=2 +58 
* 38
* 12
cfi=(120)
cfn=(3250)
calls=2 +10 
* 174
* 22
cfi=(81)
cfn=(2936)
calls=2 +11 
* 20
* 8
cfi=(108)
cfn=(3254)
calls=2 -15 
* 124
* 8
cfi=(108)
cfn=(3254)
calls=2 -15 
* 124
* 8
cfi=(110)
cfn=(2326)
calls=2 -15 
* 72
+2 6
cfi=(72)
cfn=(1456)
calls=2 874 
* 20
* 14
cfi=(72)
cfn=(2320)
calls=2 889 
* 214
* 10
cfn=(3256) QDirPrivate::setPath(QString const&)
calls=2 +65 
* 6496
* 6
cfi=(72)
cfn=(2230)
calls=2 1065 
* 196
+2 8
cfi=(64)
cfn=(3286)
calls=2 +98 
* 44
* 2
+1 8
+9 4
+1 10
cfi=(72)
cfn=(2478)
calls=2 528 
* 2079
* 10
cfi=(120)
cfn=(3288)
calls=2 * 
* 1747
* 12
cfi=(120)
cfn=(3298)
calls=2 -5 
* 428
* 6
cfi=(120)
cfn=(3036)
calls=2 -5 
* 168
* 6
cfi=(72)
cfn=(2230)
calls=2 1065 
* 196
+1 12

fn=(3408)
709 7
+1 3
cfi=(119)
cfn=(3308)
calls=1 77 
* 7
* 1
+1 3
cfi=(147)
cfn=(3310)
calls=1 165 
* 6584
* 2
+3 3
cfn=(3410) QDirPrivate::resolveAbsoluteEntry() const
calls=1 180 
* 4090
+1 6
cfi=(108)
cfn=(2336)
calls=1 123 
* 151
+1 3
cfi=(72)
cfn=(1456)
calls=1 874 
* 10
* 2
+2 4
cfi=(114)
cfn=(2350)
calls=1 47 
* 11
* 5
cfi=(114)
cfn=(2352)
calls=1 82 
* 22
* 6
cfi=(86)
cfn=(2874)
calls=1 4469 
* 109
* 3
+1 4
cfi=(114)
cfn=(2350)
calls=1 47 
* 11
* 5
cfi=(150)
cfn=(3418)
calls=1 372 
* 49
* 7
cfi=(150)
cfn=(3420)
calls=1 372 
* 49
* 7
cfi=(150)
cfn=(3388)
calls=1 125 
* 1217
* 2
-4 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
* 1
+6 5

fn=(3410)
180 5
+1 4
cfi=(108)
cfn=(3198)
calls=1 321 
* 39
* 7
cfi=(108)
cfn=(3198)
calls=1 321 
* 22
* 5
+3 3
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
+1 4
cfi=(81)
cfn=(2956)
calls=1 -47 
* 9
* 2
+1 4
cfi=(108)
cfn=(3316)
calls=1 +95 
* 181
* 7
cfi=(108)
cfn=(3412) QFileSystemEntry::isClean() const
calls=1 384 
* 3377
* 6
+1 7
cfi=(112)
cfn=(2928)
calls=1 57 
* 312
* 1
+1 1
+8 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
* 1
-12 1
+13 3

fn=(2858)
2175 35
+1 15
cfi=(72)
cfn=(1456)
calls=5 874 
* 50
* 10
+2 25
cfi=(72)
cfn=(2320)
calls=5 889 
* 535
+1 5
cfn=(2860) QDir::separator()
calls=5 1846 
* 240
* 5
+1 20
cfi=(114)
cfn=(2350)
calls=5 47 
* 55
* 25
cfi=(114)
cfn=(2352)
calls=5 82 
* 110
* 25
cfi=(114)
cfn=(2862)
calls=5 570 
* 115
* 10
+3 5
+5 30
cfn=(2864) qt_normalizePathSegments(QString const&, bool)
calls=5 2047 
* 16422
+3 25
cfi=(72)
cfn=(2532)
calls=5 866 
* 40
* 30
cfi=(114)
cfn=(2350)
calls=5 47 
* 55
* 30
cfi=(114)
cfn=(2352)
calls=5 82 
* 110
* 35
cfi=(86)
cfn=(2874)
calls=5 4469 
* 545
* 35
+11 25
cfi=(72)
cfn=(2228)
calls=5 226 
* 130
-14 15
cfi=(72)
cfn=(2230)
calls=5 1065 
* 325
-10 15
cfi=(72)
cfn=(2230)
calls=5 1065 
* 490
* 5
+25 30

fn=(3270) QDirPrivate::clearFileLists()
173 8
+1 4
+1 8
cfi=(64)
cfn=(2782)
calls=2 862 
* 624
+1 8
cfi=(64)
cfn=(3272)
calls=2 862 
* 624
+1 6

fn=(3256)
150 16
+1 10
cfn=(2318)
calls=2 834 
* 240
+1 8
cfi=(114)
cfn=(2350)
calls=2 47 
* 22
* 12
cfi=(114)
cfn=(2352)
calls=2 -70 
* 44
+1 2
-1 12
cfi=(86)
cfn=(2874)
calls=2 4469 
* 218
+1 6
-1 8
+13 14
cfi=(108)
cfn=(3258) QFileSystemEntry::QFileSystemEntry(QString const&, QFileSystemEntry::FromInternalPath)
calls=2 -72 
* 302
* 14
cfi=(112)
cfn=(3260)
calls=2 57 
* 340
* 6
cfi=(138)
cfn=(2930)
calls=2 57 
* 288
+1 8
cfi=(110)
cfn=(3264)
calls=2 +2 
* 46
+1 6
cfn=(3266) QDirPrivate::initFileEngine()
calls=2 333 
* 2594
+1 6
cfn=(3270)
calls=2 +5 
* 1282
+1 6
cfi=(108)
cfn=(3254)
calls=2 68 
* 124
* 12
cfi=(112)
cfn=(3260)
calls=2 57 
* 340
* 6
cfi=(138)
cfn=(2930)
calls=2 57 
* 288
-18 6
cfi=(72)
cfn=(2230)
calls=2 1065 
* 196
+19 14

fn=(3266)
333 8
+1 14
cfi=(111)
cfn=(2330)
calls=2 188 
* 2530
* 12
cfi=(81)
cfn=(3268)
calls=2 143 
* 24
+1 6

fn=(3678)
1945 4
+1 3
cfi=(144)
cfn=(3680) QFileSystemEngine::homePath()
calls=1 681 
* 7159
+1 3

fn=(2864)
2047 40
+1 15
cfi=(72)
cfn=(2532)
calls=5 866 
* 40
* 5
+2 10
+3 15
+1 25
cfi=(136)
cfn=(2866)
calls=5 230 
* 4565
+1 10
+1 15
cfi=(136)
cfn=(2870)
calls=5 165 
* 35
* 5
+1 15
cfi=(72)
cfn=(2222)
calls=5 876 
* 240
* 5
+1 10
+1 5
+2 5
+2 25
+8 15
cfi=(114)
cfn=(2570)
calls=5 420 
* 35
* 20
+1 5
+2 20
+1 10
+3 45
cfi=(114)
cfn=(2570)
calls=5 420 
* 35
* 25
+5 48
+2 133
cfi=(114)
cfn=(2570)
calls=19 420 
* 133
* 76
+1 1
+1 1
+4 126
cfi=(114)
cfn=(2570)
calls=18 420 
* 126
* 46
cfi=(114)
cfn=(2570)
calls=1 420 
* 7
* 57
+1 1
+1 1
+5 34
-1 119
cfi=(114)
cfn=(2570)
calls=17 420 
* 119
* 34
+1 17
-1 34
+8 169
cfi=(114)
cfn=(2556)
calls=12 421 
* 72
* 99
+1 120
cfi=(114)
cfn=(2350)
calls=12 47 
* 132
* 60
cfi=(114)
cfn=(2352)
calls=12 82 
* 264
* 24
+3 296
+1 1001
cfi=(114)
cfn=(2570)
calls=143 420 
* 1001
* 572
+1 12
+1 12
+4 262
+1 1703
+1 131
-9 131
+13 34
-39 2
+44 10
+8 20
+2 10
+1 55
cfi=(114)
cfn=(2556)
calls=5 421 
* 30
* 30
+5 35
+1 65
-1 10
+16 30
cfi=(72)
cfn=(2320)
calls=4 889 
* 428
* 16
cfi=(86)
cfn=(2852)
calls=1 1506 
* 988
+1 25
cfi=(72)
cfn=(2228)
calls=5 226 
* 130
-1 15
cfi=(72)
cfn=(2230)
calls=5 1065 
* 325
2054 15
cfi=(136)
cfn=(2872)
calls=5 77 
* 1650
* 5
2161 25

fn=(3350)
577 14
cfi=(119)
cfn=(3352)
calls=2 83 
* 2726
+2 6

fn=(2318)
834 115
+17 115
cfi=(72)
cfn=(2320)
calls=23 +38 
* 2365
+1 69

fn=(2860)
1846 15
+4 20
cfi=(114)
cfn=(2350)
calls=5 47 
* 55
* 25
cfi=(114)
cfn=(2352)
calls=5 82 
* 110
* 5
+2 10

fn=(3230)
534 20
cfi=(120)
cfn=(2438)
calls=2 97 
* 58
* 2
fi=(148)
57 6
cfi=(147)
cfn=(3232)
calls=2 227 
* 158
* 2
fe=(109)
534 8
cfi=(95)
cfn=(3242)
calls=2 111 
* 20
* 4
cob=(13)
cfi=(59)
cfn=(888)
calls=2 43 
* 600
* 2
* 20
cfn=(3244)
calls=2 78 
* 12560
* 8
cfi=(119)
cfn=(3300)
calls=2 219 
* 96
* 6
cfi=(120)
cfn=(3036)
calls=2 93 
* 168
+2 12

fn=(3120) QDir::toNativeSeparators(QString const&)
801 25
+17 25
cfi=(72)
cfn=(2320)
calls=5 +71 
* 535
+1 15

fn=(3306)
686 11
+1 3
cfi=(119)
cfn=(3308)
calls=1 77 
* 7
* 1
+1 3
cfi=(147)
cfn=(3310)
calls=1 165 
* 5662
* 2
+3 6
cfi=(108)
cfn=(2336)
calls=1 123 
* 151
+1 3
cfi=(72)
cfn=(1456)
calls=1 874 
* 10
* 3
+1 8
cfi=(72)
cfn=(1456)
calls=1 874 
* 10
* 7
cfi=(114)
cfn=(2350)
calls=1 47 
* 11
* 6
cfi=(114)
cfn=(2352)
calls=1 82 
* 22
* 4
cfi=(72)
cfn=(2532)
calls=1 866 
* 8
* 5
cfi=(72)
cfn=(3322) QString::operator[](int)
calls=1 1093 
* 37
* 6
cfi=(72)
cfn=(3328) QCharRef::operator QChar() const
calls=1 980 
* 82
* 5
cfi=(114)
cfn=(2862)
calls=1 570 
* 23
* 6
cfi=(114)
cfn=(2350)
calls=1 47 
* 11
* 6
cfi=(114)
cfn=(2352)
calls=1 82 
* 22
* 5
cfi=(72)
cfn=(2344)
calls=1 870 
* 93
* 5
cfi=(114)
cfn=(2862)
calls=1 570 
* 23
* 11
+1 4
cfi=(114)
cfn=(2350)
calls=1 47 
* 11
* 5
cfi=(114)
cfn=(2352)
calls=1 82 
* 22
* 5
cfi=(72)
cfn=(3334) QString::operator+=(QChar)
calls=1 438 
* 1568
+1 5
cfi=(72)
cfn=(3342)
calls=1 447 
* 304
+2 5
cfi=(72)
cfn=(2228)
calls=1 226 
* 26
-6 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 65
* 1
+7 9

fn=(3312)
2212 20
+1 20
cfi=(107)
cfn=(3084)
calls=4 332 
* 14360
* 12
cfi=(107)
cfn=(3314)
calls=4 637 
* 989
* 16
cfi=(107)
cfn=(3000)
calls=4 379 
* 5244
* 8
+1 16

fl=(163)
fn=(3532)
96 5
+2 3
cfi=(72)
cfn=(3534) QString::cbegin() const
calls=1 1101 
* 48
* 1
+1 3
cfi=(72)
cfn=(3536) QString::cend() const
calls=1 1109 
* 55
* 1
+1 5
cfn=(3538) QStringAlgorithms<QString const>::trimmed_helper_positions(QChar const*&, QChar const*&)
calls=1 -16 
* 111
+2 3
cfi=(72)
cfn=(3534)
calls=1 1101 
* 48
* 7
cfi=(72)
cfn=(3536)
calls=1 1109 
* 55
* 8
+1 5
cfi=(72)
cfn=(2320)
calls=1 889 
* 107
* 1
+4 3

fn=(3538)
84 5
+3 10
cfn=(3540) QStringAlgorithms<QString const>::isSpace(QChar)
calls=1 -26 
* 33
* 5
+3 6
+1 11
cfn=(3540)
calls=1 -30 
* 33
* 5
+3 3

fn=(3540)
61 14
cfi=(114)
cfn=(3542)
calls=2 432 
* 48
* 4

fl=(40)
fn=(762)
203 5
cfn=(764) __static_initialization_and_destruction_0(int, int)
calls=1 * 
* 50
* 2

fn=(764)
203 9
66 2
cfi=(34)
cfn=(746)
calls=1 -12 
* 36
203 3

fl=(173)
fn=(4146)
297 1608
+1 4288

fn=(4120)
294 2148
+1 1611
+1 4296

fn=(4604)
244 5375
+2 6450
cfi=(34)
cfn=(920)
calls=1075 121 
* 234350
+1 2150
-1 3225
cfi=(34)
cfn=(1050)
calls=1075 132 
* 237575
+1 1075
+1 4300

fl=(188)
fn=(4500)
56 4
+1 4
cfi=(53)
cfn=(1136)
calls=1 198 
* 159
* 8
cfi=(61)
cfn=(994)
calls=1 +98 
* 62
* 4
cfi=(35)
cfn=(812)
calls=1 233 
* 26
* 4
cfi=(35)
cfn=(812)
calls=1 233 
* 26
* 2
+2 5
cfi=(35)
cfn=(910)
calls=1 +58 
* 44
+1 5
cfi=(35)
cfn=(910)
calls=1 +57 
* 44
+1 3

fn=(4512)
54 7

fl=(78)
fn=(1224)
784 6
+5 3
cfn=(1226) char const** std::__niter_base<char const**>(char const**)
calls=1 277 
* 6
* 6
cfn=(1228) __gnu_cxx::__enable_if<std::__is_scalar<char*>::__value, char const**>::__type std::__fill_n_a<char const**, unsigned int, char*>(char const**, unsigned int, char* const&)
calls=1 -40 
* 31
+1 2

fn=(1228)
749 5
+2 3
+1 2
+1 6
+1 6
-2 6
+3 1
+1 2

fn=(1226)
277 3
+1 3

fl=(79) /home/tsenyk/qt5/qt5/qtbase/src/corelib/thread/qwaitcondition_unix.cpp
fn=(1258) QWaitCondition::QWaitCondition()
163 20
+2 10
cob=(13)
cfi=(59)
cfn=(888)
calls=5 43 
* 1080
* 5
* 15
+1 25
cob=(5)
cfi=(5)
cfn=(1264)
calls=4 0 
* 36
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1217
* 9
* 20
cfn=(1266) report_error(int, char const*, char const*)
calls=5 66 
* 70
+1 30
cfn=(1268) qt_initialize_pthread_cond(pthread_cond_t*, char const*)
calls=5 -95 
* 7459
+1 35
+1 15

fn=(1266)
66 70
+1 20
+2 50

fn=(1268)
72 25
+3 15
cob=(5)
cfi=(5)
cfn=(1274)
calls=4 -75 
* 12
cob=(1)
cfi=(1)
cfn=(243)
calls=1 -75 
* 1251
* 9
+6 5
cfi=(80)
cfn=(1276)
calls=5 +65 
* 1880
* 20
+1 20
cob=(5)
cfi=(5)
cfn=(1300)
calls=4 -82 
* 40
cob=(1)
cfi=(1)
cfn=(243)
calls=1 -82 
* 1292
* 9
+3 25
cob=(5)
cfi=(5)
cfn=(1306)
calls=4 -85 
* 72
cob=(1)
cfi=(1)
cfn=(243)
calls=1 -85 
* 1378
* 9
* 30
cfn=(1266)
calls=5 -19 
* 70
+1 15
cob=(5)
cfi=(5)
cfn=(1312)
calls=4 -86 
* 8
cob=(1)
cfi=(1)
cfn=(243)
calls=1 -86 
* 1250
* 9
+1 15

fl=(91)
fn=(1490)
57 12
+2 8
cfi=(58)
cfn=(882)
calls=2 177 
* 238
* 8
cfi=(79)
cfn=(1258)
calls=2 163 
* 838
* 8
cfi=(79)
cfn=(1258)
calls=2 163 
* 838
* 32
cfi=(92)
cfn=(1492)
calls=2 235 
* 18
+1 10

fl=(165)
fn=(4246)
141 110000011
cfi=(61)
cfn=(4248)
calls=10000001 +23 
* 490000049
* 50000005
cfi=(61)
cfn=(994)
calls=10000001 +14 
* 620000062
* 40000004
+2 30000003

fn=(4452)
108 7
cfi=(76)
cfn=(4454)
calls=1 -43 
* 21
* 4
cfi=(64)
cfn=(3438)
calls=1 +33 
* 19
* 4
cfi=(76)
cfn=(4458)
calls=1 -43 
* 21
* 4
cfi=(76)
cfn=(4462)
calls=1 -43 
* 21
* 4
cfi=(64)
cfn=(4466)
calls=1 +33 
* 19
* 4
cfi=(72)
cfn=(1156)
calls=1 1064 
* 21
* 3

fn=(4902)
266 60003204
+2 40002136
+1 30001602
cfi=(71)
cfn=(1320)
calls=10000534 110 
* 260013884
* 30001602
+2 20001068
+2 30001602

fn=(4272)
156 50

fn=(4882)
147 40000004
+1 40000004
cfi=(35)
cfn=(1364)
calls=10000001 -20 
* 320000032
* 30000003
+4 30000003

fn=(4860)
257 50002670
+1 30001602
cfi=(71)
cfn=(1320)
calls=10000534 110 
* 260013884
* 20001068
+1 30001602
cfi=(71)
cfn=(1320)
calls=10000534 110 
* 260013884
* 30001602
+1 10000534
+1 20001068

fn=(4078)
103 7

fl=(157)
fn=(3476)
49 16
cfi=(62)
cfn=(1322)
calls=2 1014 
* 32
* 4

fl=(186)
fn=(4426)
94 3234
fi=(162)
+1 4756
+1 555
+1 555
fe=(186)
-2 111
fi=(162)
+4 4324
+1 15
+1 15
fe=(186)
-2 3
fi=(162)
+4 1078
+1 2156
fe=(186)

fn=(4636)
125 15
+2 24
+1 24
fi=(162)
+1 9
cfi=(186)
cfn=(4426)
calls=3 -35 
* 87
* 6
+1 6
fe=(186)

fl=(72)
fn=(2478)
528 144
+2 114
cob=(3)
cfi=(3)
cfn=(342)
calls=6 0 
* 146
* 6
* 96
cfi=(86)
cfn=(2480)
calls=18 4622 
* 45362
* 24
cfi=(86)
cfn=(2480)
calls=6 4622 
* 8233
* 24
+1 120
cfn=(2284)
calls=24 782 
* 240
+1 72

fn=(3056)
908 20
cfi=(86)
cfn=(3058)
calls=1 7551 
* 4069
* 3

fn=(2222)
876 736
cfi=(73)
cfn=(2214)
calls=92 199 
* 3496
* 184

fn=(2344)
870 340
0 204
fi=(31)
cfn=(2342)
calls=68 231 
0 544
0 340
fi=(31)
cfi=(62)
cfn=(922)
calls=68 623 
0 340
0 272
fi=(31)
cfi=(73)
cfn=(2214)
calls=68 199 
0 2584
0 748
fi=(31)
cfi=(114)
cfn=(2348)
calls=68 76 
0 748
0 204

fn=(2532)
866 7144

fn=(3304)
863 39
cfn=(2524)
calls=3 92 
* 21
* 12
cfn=(2880)
calls=3 91 
* 21
* 9
cfi=(86)
cfn=(2480)
calls=3 4622 
* 4801
* 9
+1 15

fn=(3534)
1101 16
cfi=(73)
cfn=(2214)
calls=2 199 
* 76
* 4

fn=(5248)
508 5
+1 5
cfi=(86)
cfn=(5250)
calls=1 4477 
* 1172
* 3

fn=(2216)
882 18904
cfi=(73)
cfn=(2214)
calls=2363 199 
* 89794
* 4726

fn=(2310)
198 4
+2 3
cfi=(65)
cfn=(2162)
calls=1 87 
* 46
* 4
cfi=(62)
cfn=(922)
calls=1 623 
* 5
+1 1
+1 2

fn=(2880)
91 826

fn=(3528)
402 5
+1 5
cfi=(86)
cfn=(3530)
calls=1 4896 
* 482
* 3

fn=(1462)
537 30
+2 32
cob=(3)
cfi=(3)
cfn=(342)
calls=3 0 
* 110
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 1540
* 8
* 10
cfi=(86)
cfn=(1468)
calls=1 4687 
* 2731
* 20
cfi=(86)
cfn=(1468)
calls=4 4687 
* 51792
+1 15

fn=(2230)
1065 12532
0 12532
fi=(31)
cfi=(65)
cfn=(1044)
calls=3133 59 
0 210867
0 12619
fi=(31)
cfi=(73)
cfn=(2582) QTypedArrayData<unsigned short>::deallocate(QArrayData*)
calls=805 219 
0 710154584
0 9399

fn=(2282)
198 4
+2 3
cfi=(65)
cfn=(2162)
calls=1 87 
* 46
* 4
cfi=(62)
cfn=(922)
calls=1 623 
* 5
+1 1
+1 2

fn=(2778)
775 5264
cfi=(73)
cfn=(1158)
calls=658 240 
* 6580
* 3948

fn=(3342)
447 20
cfi=(86)
cfn=(3344)
calls=2 2036 
* 1934
* 4

fn=(3416) QString::constEnd() const
1111 200
cfi=(73)
cfn=(2214)
calls=25 199 
* 950
* 225

fn=(3668)
545 24
0 12
fi=(31)
cfi=(67)
cfn=(2466)
calls=4 3389 
0 76
0 17
fi=(31)
cfn=(1156)
calls=3 1064 
0 63
0 6
fi=(31)
cfi=(98)
cfn=(2470)
calls=1 467 
0 8
0 4
fi=(31)
cfi=(98)
cfn=(2472)
calls=1 489 
0 48
0 3
fi=(31)
cfi=(98)
cfn=(2474)
calls=1 72 
0 196
0 4
fi=(31)
cfi=(98)
cfn=(2476)
calls=1 487 
0 48
0 6
fi=(31)
cfn=(1462)
calls=1 537 
0 2750
0 20

fn=(1456)
874 7230

fn=(2320)
889 891
0 396
fi=(31)
cfi=(62)
cfn=(922)
calls=99 623 
0 495
0 396
fi=(31)
cfi=(65)
cfn=(2278)
calls=99 48 
0 7798
0 297

fn=(2524)
92 1904

fn=(2538)
198 36
+2 27
cfi=(65)
cfn=(2162)
calls=9 87 
* 414
* 36
cfi=(62)
cfn=(922)
calls=9 623 
* 45
+1 9
+1 18

fn=(2548)
878 176
cfi=(73)
cfn=(2214)
calls=22 199 
* 836
* 44

fn=(2550)
1119 819
cfi=(86)
cfn=(2552)
calls=63 3124 
* 23085
* 252

fn=(2574)
868 385
0 231
fi=(31)
cfn=(2342)
calls=77 231 
0 616
0 385
fi=(31)
cfi=(62)
cfn=(922)
calls=77 623 
0 385
0 308
fi=(31)
cfi=(73)
cfn=(2214)
calls=77 199 
0 2926
0 847
fi=(31)
cfi=(114)
cfn=(2348)
calls=77 76 
0 847
0 231

fn=(3322)
1093 5
0 3
fi=(31)
cfi=(62)
cfn=(922)
calls=1 623 
0 5
0 6
fi=(31)
cfn=(3326) QCharRef::QCharRef(QString&, int)
calls=1 972 
0 14
0 4

fn=(3328)
980 4
0 13
fi=(31)
cfi=(73)
cfn=(2214)
calls=1 199 
0 38
0 13
fi=(31)
cfi=(114)
cfn=(3332)
calls=1 80 
0 11
0 3

fn=(2464)
541 54
0 27
fi=(31)
cfi=(67)
cfn=(2466)
calls=9 3389 
0 171
0 45
fi=(31)
cfi=(98)
cfn=(2470)
calls=9 467 
0 72
0 36
fi=(31)
cfi=(98)
cfn=(2472)
calls=9 489 
0 432
0 27
fi=(31)
cfi=(98)
cfn=(2474)
calls=9 72 
0 1629
0 36
fi=(31)
cfi=(98)
cfn=(2476)
calls=9 487 
0 432
0 54
fi=(31)
cfn=(2478)
calls=9 528 
0 15174
0 45

fn=(3124)
516 3834
+1 1917
cfn=(2342)
calls=639 231 
* 5112
* 2556
cfn=(2216)
calls=639 882 
* 30672
* 3834
cfi=(86)
cfn=(3126)
calls=639 4569 
* 133241216
* 3195

fn=(2518)
87 810
-87 810
fi=(31)
cob=(3)
cfi=(3)
cfn=(342)
calls=162 0 
0 2610
fi=(31)
0 162
fe=(72)
0 1620

fn=(2542)
880 126
cfn=(2544) QString::detach()
calls=18 +4 
* 1242
* 72
cfi=(73)
cfn=(2214)
calls=18 199 
* 684
* 36

fn=(2544)
884 72
0 72
fi=(31)
cfi=(65)
cfn=(1018)
calls=18 93 
0 864
0 234

fn=(2920)
1375 12

fn=(3326)
972 5
+1 9

fn=(3334)
438 6
+1 4
cfi=(65)
cfn=(1018)
calls=1 93 
* 51
* 6
+1 9
cfi=(86)
cfn=(3336)
calls=1 1739 
* 1375
+1 4
cfi=(73)
cfn=(2214)
calls=1 199 
* 38
* 12
cfi=(114)
cfn=(2556)
calls=1 -20 
* 6
* 2
+1 4
cfi=(73)
cfn=(2214)
calls=1 199 
* 38
* 8
+1 1
+1 4

fn=(3414) QString::constBegin() const
1103 8
cfi=(73)
cfn=(2214)
calls=1 199 
* 38
* 2

fn=(2746)
886 40
cfi=(65)
cfn=(1018)
calls=5 93 
* 255
* 15

fn=(2912)
1425 8
+1 8
+2 8
cfn=(2222)
calls=2 876 
* 96
* 12
+1 4

fn=(3536)
1109 16
cfi=(73)
cfn=(2214)
calls=2 199 
* 76
* 18

fn=(1156)
1064 14205
cfi=(73)
cfn=(1158)
calls=2841 240 
* 28410
* 17046

fn=(2228)
226 230
cfi=(73)
cfn=(1158)
calls=23 +14 
* 230
* 138

fn=(2234)
227 800
+1 800
cfi=(62)
cfn=(2236)
calls=160 860 
* 8960
* 480

fn=(2284)
782 350

fn=(2342)
231 7248

fn=(2776)
888 36
0 27
fi=(31)
cfn=(2778)
calls=9 775 
0 216
0 45
fi=(31)
cfn=(1156)
calls=6 1064 
0 126
0 30
fi=(31)
cfn=(2234)
calls=6 227 
0 414
0 18
fi=(31)
cfn=(2230)
calls=6 1065 
0 555
0 27

fn=(2906)
1498 12
+1 24

fn=(2910)
1380 14

fl=(144)
fn=(3196)
226 7
+1 3
cfi=(108)
cfn=(3198)
calls=1 +94 
* 22
* 5
cfi=(108)
cfn=(3200) QFileSystemEntry::isRoot() const
calls=1 +80 
* 120
* 5
+8 1
+30 5
cfi=(108)
cfn=(3116)
calls=1 129 
* 160
* 3
cfi=(98)
cfn=(2472)
calls=1 489 
* 48
* 3
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
* 3788
* 5
* 4
cfi=(98)
cfn=(2154)
calls=1 465 
* 98
+11 2
+1 4
cfi=(95)
cfn=(3110)
calls=1 124 
* 13
+1 5
cfi=(95)
cfn=(3110)
calls=1 124 
* 13
+1 6
cfi=(72)
cfn=(1462)
calls=1 537 
* 2056
* 5
cfi=(109)
cfn=(2858)
calls=1 2175 
* 8025
* 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
+1 3
cob=(3)
cfi=(3)
cfn=(1420)
calls=1 0 
* 119
* 1
+1 5
cfi=(108)
cfn=(2316)
calls=1 80 
* 164
* 1
-2 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
* 1
+10 5

fn=(3106)
418 40
+12 20
cfi=(95)
cfn=(3108)
calls=5 136 
* 260
* 20
cfi=(95)
cfn=(3094)
calls=5 128 
* 35
* 20
+1 8
cfi=(95)
cfn=(3110)
calls=2 124 
* 26
+2 20
cfi=(95)
cfn=(3108)
calls=5 136 
* 260
* 20
cfi=(95)
cfn=(3094)
calls=5 128 
* 35
* 20
+2 8
cfi=(95)
cfn=(3110)
calls=2 124 
* 26
+3 15
cfi=(95)
cfn=(3112)
calls=5 137 
* 255
* 20
cfi=(95)
cfn=(3094)
calls=5 128 
* 35
* 30
cfi=(95)
cfn=(3114)
calls=5 121 
* 65
+5 25
cfi=(108)
cfn=(3116)
calls=5 129 
* 16503
* 10
+1 15
cfi=(98)
cfn=(2472)
calls=5 +45 
* 240
* 5
+1 15
cfi=(98)
cfn=(2470)
calls=5 +22 
* 40
* 5
-2 15
cfi=(98)
cfn=(2154)
calls=5 +22 
* 490
+6 5
+3 5
+1 20
cfi=(95)
cfn=(3108)
calls=5 136 
* 260
* 20
cfi=(95)
cfn=(3094)
calls=5 128 
* 35
* 20
+1 5
cfi=(31)
cfn=(3182) lstat64
calls=1 0 
* 1530
* 4
+1 4
+1 5
cfi=(95)
cfn=(3110)
calls=1 124 
* 13
* 1
+9 4
cfi=(95)
cfn=(3110)
calls=1 124 
* 13
+3 35
cfi=(95)
cfn=(3108)
calls=5 136 
* 260
* 25
cfi=(95)
cfn=(3094)
calls=5 128 
* 35
* 34
+1 24
+1 20
cfi=(31)
cfn=(3162) stat64
calls=4 0 
* 1571
* 12
+2 8
+1 5
cfi=(111)
cfn=(3170)
calls=1 233 
* 250
* 1
+2 3
+1 6
+1 6
+1 6
+1 6
+1 6
+1 6
+5 9
cfi=(110)
cfn=(3172)
calls=3 244 
* 237
* 3
cfi=(110)
cfn=(3172)
calls=1 244 
* 79
* 20
cfi=(95)
cfn=(3176)
calls=4 123 
* 52
+12 20
cfi=(95)
cfn=(3108)
calls=5 136 
* 260
* 20
cfi=(95)
cfn=(3094)
calls=5 128 
* 35
* 20
+20 20
cfi=(95)
cfn=(3108)
calls=5 136 
* 260
* 5
+1 20
cfi=(95)
cfn=(3094)
calls=5 128 
* 35
* 15
-1 15
+20 20
+1 15
cfi=(110)
cfn=(3346)
calls=3 173 
* 273
+1 6
+2 10
cfi=(143)
cfn=(3092)
calls=2 158 
* 202
+1 25

fn=(3680)
681 5
+1 4
cfi=(38)
cfn=(2264)
calls=1 3173 
* 1389
* 5
cfi=(145)
cfn=(3666)
calls=1 84 
* 3118
* 3
cfi=(98)
cfn=(2154)
calls=1 465 
* 290
+1 3
cfi=(72)
cfn=(1456)
calls=1 874 
* 10
* 2
+2 5
cfi=(109)
cfn=(2858)
calls=1 2175 
* 2217
* 1
-3 3
cfi=(72)
cfn=(2230)
calls=1 1065 
* 98
+3 1
+1 5

fl=(124)
fn=(2610)
97 54
+1 126

fn=(2612)
95 54
+1 90

fn=(2594)
89 54
+1 126

fn=(2596)
87 54
+1 90

fl=(103)
fn=(2708)
179 35
+11 21
cfn=(2710) std::remove_reference<QVariant::Private&>::type&& std::move<QVariant::Private&>(QVariant::Private&)
calls=7 -89 
* 42
* 35
cfi=(117)
cfn=(2712)
calls=7 374 
* 315
+1 21
cfn=(2710)
calls=7 -90 
* 42
* 42
+1 21
cfn=(2710)
calls=7 -91 
* 42
* 42
+1 21

fn=(2710)
101 63
+1 63

fn=(2794)
179 75
+11 45
cfn=(2796) std::remove_reference<QListData::Data*&>::type&& std::move<QListData::Data*&>(QListData::Data*&)
calls=15 -89 
* 90
* 30
+1 45
cfn=(2796)
calls=15 -90 
* 90
* 45
+1 45
cfn=(2796)
calls=15 -91 
* 90
* 45
+1 45

fn=(2796)
101 135
+1 135

fn=(3276)
101 6
+1 6

fn=(3632)
101 3
+1 3

fn=(2238)
179 800
+11 480
cfn=(2240) std::remove_reference<QTypedArrayData<unsigned short>*&>::type&& std::move<QTypedArrayData<unsigned short>*&>(QTypedArrayData<unsigned short>*&)
calls=160 -89 
* 960
* 320
+1 480
cfn=(2240)
calls=160 -90 
* 960
* 480
+1 480
cfn=(2240)
calls=160 -91 
* 960
* 480
+1 480

fn=(2460) std::remove_reference<QTypedArrayData<char>*&>::type&& std::move<QTypedArrayData<char>*&>(QTypedArrayData<char>*&)
101 144
+1 144

fn=(3640)
179 5
+11 3
cfn=(3642) std::remove_reference<QTypedArrayData<QLoggingRule>*&>::type&& std::move<QTypedArrayData<QLoggingRule>*&>(QTypedArrayData<QLoggingRule>*&)
calls=1 -89 
* 6
* 2
+1 3
cfn=(3642)
calls=1 -90 
* 6
* 3
+1 3
cfn=(3642)
calls=1 -91 
* 6
* 3
+1 3

fn=(2458)
179 80
+11 48
cfn=(2460)
calls=16 -89 
* 96
* 32
+1 48
cfn=(2460)
calls=16 -90 
* 96
* 48
+1 48
cfn=(2460)
calls=16 -91 
* 96
* 48
+1 48

fn=(2240)
101 1440
+1 1440

fn=(2806)
101 15
+1 15

fn=(3642)
101 9
+1 9

fn=(4532)
101 3
+1 3

fn=(2786)
101 24
+1 24

fn=(4486)
101 3
+1 3

fl=(108)
fn=(3118) QFileSystemEntry::resolveNativeFilePath() const
152 35
+1 21
cfi=(72)
cfn=(1456)
calls=7 874 
* 70
* 49
cfi=(98)
cfn=(2272)
calls=7 477 
* 70
* 40
+9 25
cfi=(109)
cfn=(3120)
calls=5 801 
* 600
* 25
cfi=(145)
cfn=(3122)
calls=5 -82 
* 16958
* 30
cfi=(98)
cfn=(2454)
calls=5 +24 
* 345
* 15
cfi=(98)
cfn=(2154)
calls=5 465 
* 325
* 15
cfi=(72)
cfn=(2230)
calls=5 1065 
* 490
+15 40

fn=(3116)
129 35
+1 21
cfn=(3118)
calls=7 +22 
* 19153
+1 42
cfi=(98)
cfn=(2276)
calls=7 494 
* 686
+1 21

fn=(3254)
68 28
+3 21
cfi=(72)
cfn=(1156)
calls=7 1064 
* 147
* 28
cfi=(98)
cfn=(2324)
calls=7 464 
* 147
* 42
+2 21

fn=(2338) QFileSystemEntry::resolveFilePath() const
135 135
+1 81
cfi=(72)
cfn=(1456)
calls=27 874 
* 270
* 135
+13 135

fn=(3200)
307 4
+1 3
cfn=(2338)
calls=1 135 
* 28
+1 4
cfi=(72)
cfn=(2518)
calls=1 87 
* 37
* 6
cfi=(86)
cfn=(2522)
calls=1 2699 
* 33
* 2
+8 1
+1 2

fn=(3218) QFileSystemEntry::findLastSeparator() const
328 8
+1 8
+1 6
cfn=(2338)
calls=2 135 
* 56
+1 8
cfi=(114)
cfn=(2350)
calls=2 47 
* 22
* 10
cfi=(114)
cfn=(2352)
calls=2 82 
* 44
* 12
cfi=(86)
cfn=(3220)
calls=2 3277 
* 564
* 6
+2 6

fn=(3318) QFileSystemEntry::isAbsolute() const
286 25
+1 15
cfn=(2338)
calls=5 135 
* 140
+1 20
cfi=(72)
cfn=(1456)
calls=5 874 
* 50
* 35
cfi=(72)
cfn=(2574)
calls=5 868 
* 465
* 25
cfi=(114)
cfn=(2570)
calls=5 420 
* 35
* 20
+1 12
-1 2
+1 8

fn=(2336)
123 90
+1 54
cfn=(2338)
calls=18 +11 
* 504
+1 90
cfi=(72)
cfn=(2320)
calls=18 889 
* 1862
+1 54

fn=(3198)
321 16
+1 12
cfi=(72)
cfn=(1456)
calls=4 874 
* 40
* 12
cfi=(98)
cfn=(2272)
calls=1 477 
* 10
* 7
+1 8

fn=(3316)
281 20
+1 15
cfn=(3318)
calls=5 +4 
* 852
* 5
+1 10

fn=(2316)
80 65
+4 65
cfi=(109)
cfn=(2318)
calls=13 834 
* 1496
* 52
cfi=(98)
cfn=(2324)
calls=13 464 
* 273
* 78
+2 39

fn=(3412)
384 4
+1 3
cfn=(2338)
calls=1 135 
* 28
+1 1
+1 1
+1 1
+1 3
cfi=(72)
cfn=(3414)
calls=1 1103 
* 48
* 4
cfi=(72)
cfn=(3416)
calls=1 1111 
* 55
* 72
cfi=(72)
cfn=(3416)
calls=24 1111 
* 1320
* 100
+1 96
cfi=(114)
cfn=(2350)
calls=24 47 
* 264
* 120
cfi=(114)
cfn=(2352)
calls=24 82 
* 528
* 120
cfi=(114)
cfn=(2356)
calls=24 567 
* 240
* 48
+1 12
+2 12
+2 3
+1 3
+1 6
+1 42
+1 3
+1 12
cfi=(114)
cfn=(2350)
calls=3 47 
* 33
* 15
cfi=(114)
cfn=(2352)
calls=3 82 
* 66
* 15
cfi=(114)
cfn=(2356)
calls=3 567 
* 30
* 6
+6 3
+1 3
-18 48
+22 7
+1 2

fn=(3216)
190 10
+1 6
cfn=(3218)
calls=2 328 
* 750
+1 8
+7 8
+6 16
cfi=(86)
cfn=(3224)
calls=2 4302 
* 2068
+1 6

fn=(3258)
93 10
+4 10
cfi=(72)
cfn=(2320)
calls=2 889 
* 214
* 8
cfi=(98)
cfn=(2324)
calls=2 464 
* 42
* 12
+2 6

fl=(125)
fn=(2752)
317 12
cfi=(114)
cfn=(2348)
calls=1 76 
* 11
* 3

fn=(2764)
321 12
cfi=(114)
cfn=(2348)
calls=1 76 
* 11
* 3

fn=(2628) QLocalePrivate::QLocalePrivate()
304 880
cfi=(35)
cfn=(812)
calls=110 -71 
* 2860
* 330

fn=(2616)
140 189
+2 162
+1 621
+1 54

fn=(2626)
307 660
+2 220
cob=(13)
cfi=(59)
cfn=(888)
calls=110 43 
* 13401
* 110
* 330
cfn=(2628)
calls=110 -5 
* 4070
* 110
fi=(126)
+1 330
fe=(125)
+1 550
cfi=(35)
cfn=(910)
calls=110 117 
* 4840
fi=(126)
+1 440
fe=(125)
+1 110
+1 440

fn=(2718)
316 12
cfi=(114)
cfn=(2348)
calls=1 76 
* 11
* 3

fn=(2756)
320 12
cfi=(114)
cfn=(2348)
calls=1 76 
* 11
* 3

fn=(5296)
409 8
+1 6
+1 4

fn=(2760)
322 12
cfi=(114)
cfn=(2348)
calls=1 76 
* 11
* 3

fn=(2622)
146 29600
0 59414

fl=(74)
fn=(1328)
91 2560
+2 1920
cfi=(35)
cfn=(1010)
calls=640 +34 
* 18560
+1 1920
cfi=(35)
cfn=(864)
calls=640 +22 
* 22400
* 1920
cfi=(62)
cfn=(922)
calls=640 623 
* 3200
+2 1920

fn=(1314) QThread::QThread(QThreadPrivate&, QObject*)
386 7
+1 6
cfi=(53)
cfn=(1316)
calls=1 839 
* 884
* 4
+2 3
cfi=(82)
cfn=(1336)
calls=1 122 
* 26
* 1
+2 5
cfi=(61)
cfn=(1202)
calls=1 164 
* 49
* 7
cfi=(61)
cfn=(1340)
calls=1 176 
* 123
+1 5

fn=(1254)
110 7
+1 2
cob=(13)
cfi=(59)
cfn=(888)
calls=1 -68 
* 208
* 1
* 5
cfn=(1256) QThreadPrivate::QThreadPrivate(QThreadData*)
calls=1 +28 
* 8767
* 5
cfn=(1314)
calls=1 386 
* 1120
* 3
+5 3
cfi=(77)
cfn=(1358)
calls=1 304 
* 26
* 1
+1 3
cfi=(77)
cfn=(1358)
calls=1 304 
* 26
* 1
+1 3
cfi=(41)
cfn=(1360)
calls=1 262 
* 6
+4 6

fn=(1256)
139 7
+4 4
cfi=(53)
cfn=(1136)
calls=1 +55 
* 159
* 8
cfi=(58)
cfn=(882)
calls=1 +34 
* 119
* 5
cfi=(61)
cfn=(994)
calls=1 +12 
* 62
* 20
cfi=(79)
cfn=(1258)
calls=1 +20 
* 8370
* 3
+12 4
+2 6

fn=(1188)
51 6
+3 5
cfi=(61)
cfn=(994)
calls=1 155 
* 62
* 6
cfi=(75)
cfn=(1190)
calls=1 -11 
* 31
* 4
cfi=(77)
cfn=(1196)
calls=1 +56 
* 164
* 5
cfi=(61)
cfn=(1202)
calls=1 164 
* 49
* 7
cfi=(61)
cfn=(1210)
calls=1 164 
* 49
* 4
cfi=(76)
cfn=(1218)
calls=1 +11 
* 21
* 4
cfi=(77)
cfn=(1222)
calls=1 260 
* 71
* 8
+3 5

fn=(1174)
362 1623
+1 1082
cfi=(41)
cfn=(1176)
calls=541 238 
* 38366
* 541
+1 1623
cfi=(62)
cfn=(922)
calls=541 623 
* 2705
+1 2164
cfi=(35)
cfn=(1370)
calls=541 254 
* 30296
+1 1082

fn=(1362)
99 2544
+2 1908
cfi=(35)
cfn=(1364)
calls=636 +27 
* 20352
* 1908
+3 1908

fl=(182)
fn=(4316)
163 30000003
fi=(208) /home/tsenyk/qt5/qt5-desktop-5.6.2/qtbase/src/corelib/../../include/QtCore/../../../../qt5/qtbase/src/corelib/kernel/qmetaobject.h
* 60000006
fe=(182)

fl=(63)
fn=(928) QBasicMutex::dummyLocked()
93 120011362
+1 60005681
+1 120011362

fn=(964)
57 16
+1 12
cfn=(966) QBasicMutex::fastTryLock()
calls=4 +17 
* 636
* 12
+2 12

fn=(1068)
62 16
+1 12
cfi=(35)
cfn=(1070)
calls=4 252 
* 188
* 12
cfi=(62)
cfn=(922)
calls=4 623 
* 20
+1 12
cfn=(1078) QBasicMutex::fastTryUnlock()
calls=4 +14 
* 640
* 12
+2 12

fn=(966)
75 16
+1 4
cfn=(928)
calls=4 +17 
* 20
* 20
cfi=(35)
cfn=(968)
calls=4 266 
* 568
+1 8

fn=(1060)
84 150014180
+1 30002836
cfn=(928)
calls=30002836 +8 
* 150014180
* 210019852
cfi=(35)
cfn=(1062)
calls=30002836 277 
* 4380414061
+1 60005672

fn=(1078)
78 16
+1 4
cfn=(928)
calls=4 +14 
* 20
* 24
cfi=(35)
cfn=(1080)
calls=4 268 
* 568
+1 8

fn=(926)
81 150014185
+1 30002837
cfn=(928)
calls=30002837 +11 
* 150014185
* 240022696
cfi=(35)
cfn=(930)
calls=30002837 275 
* 4380414207
+1 60005674

fl=(140)
fn=(2950)
138 44
+2 33
cfi=(119)
cfn=(2952)
calls=11 -63 
* 77
+1 22

fl=(31)
fn=(3182)
0 4
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1521
0 5

fn=(3162)
0 16
cob=(3)
cfi=(3)
cfn=(3168)
calls=3 0 
0 42
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1505
0 8

fn=(732)
0 17

fl=(73)
fn=(4482)
253 3
+3 4
cfi=(95)
cfn=(2122)
calls=1 111 
* 10
* 4
cfn=(4476)
calls=1 -45 
* 191
+1 2

fn=(4530)
203 8
cfn=(4526)
calls=1 -4 
* 30
* 8

fn=(5144)
206 8
cfn=(5146) QTypedArrayData<QLoggingRule>::data() const
calls=1 -6 
* 30
* 2

fn=(2144)
199 22729
cfn=(2146) QArrayData::data()
calls=3247 51 
* 94155
* 6494

fn=(4116)
240 2
+3 1
cfn=(1160)
calls=1 116 
* 5
+1 2

fn=(4522)
211 10
+5 14
cfi=(96)
cfn=(2126)
calls=2 61 
* 1041
+1 4

fn=(1158)
240 9588
+3 4794
cfn=(1160)
calls=4794 116 
* 23970
+1 9588

fn=(2582)
219 3220
+3 4025
cfi=(96)
cfn=(2160)
calls=805 -93 
* 710144924
+1 2415

fn=(4286)
202 80004312
cfn=(4288)
calls=10000539 -3 
* 380020474
* 20001078

fn=(4456)
240 2
+3 1
cfn=(1160)
calls=1 116 
* 5
+1 2

fn=(5152)
207 8
cfn=(5146)
calls=1 -7 
* 30
* 11

fn=(1220)
240 2
+3 1
cfn=(1160)
calls=1 116 
* 5
+1 2

fn=(2124)
211 3270
+5 4578
cfi=(96)
cfn=(2126)
calls=654 61 
* 131529534
+1 1308

fn=(2212)
211 6710
+5 9394
cfi=(96)
cfn=(2126)
calls=1342 61 
* 128414175
+1 2684

fn=(4524)
202 24
cfn=(4526)
calls=3 -3 
* 90
* 6

fn=(4528)
253 3
+3 4
cfi=(95)
cfn=(2122)
calls=1 111 
* 10
* 4
cfn=(4522)
calls=1 -45 
* 191
+1 2

fn=(1194)
240 4
+3 2
cfn=(1160)
calls=2 116 
* 10
+1 4

fn=(1200)
240 2
+3 1
cfn=(1160)
calls=1 116 
* 5
+1 2

fn=(2258)
240 14
+3 7
cfn=(1160)
calls=7 116 
* 35
+1 14

fn=(3146)
93 2556
+2 639
+1 3195
+2 639
+1 1278

fn=(4464)
240 4
+3 2
cfn=(1160)
calls=2 116 
* 10
+1 4

fn=(4476)
211 10
+5 14
cfi=(96)
cfn=(2126)
calls=2 61 
* 1041
+1 4

fn=(2146)
51 40053916
+2 130154675
cfi=(62)
cfn=(922)
calls=10013479 623 
* 50067395
+2 50067395
+1 20026958

fn=(2158)
219 2604
+3 3255
cfi=(96)
cfn=(2160)
calls=651 -93 
* 116197
+1 1953

fn=(4288)
199 70003794
cfn=(2146)
calls=10000542 51 
* 290015702
* 20001084

fn=(5216)
240 2
+3 1
cfn=(1160)
calls=1 116 
* 5
+1 2

fn=(2214)
199 67760
cfn=(2146)
calls=9680 51 
* 260272
* 19360

fn=(4478)
202 24
cfn=(4480)
calls=3 -3 
* 90
* 6

fn=(4480)
199 35
cfn=(2146)
calls=5 51 
* 105
* 10

fn=(4484)
203 8
cfn=(4480)
calls=1 -4 
* 30
* 8

fn=(4294)
253 3
+3 4
cfi=(95)
cfn=(2122)
calls=1 111 
* 10
* 4
cfn=(4280)
calls=1 -45 
* 191
+1 2

fn=(2270)
240 82
+3 41
cfn=(1160)
calls=41 116 
* 205
+1 82

fn=(2940)
240 18
+3 9
cfn=(1160)
calls=9 116 
* 45
+1 18

fn=(4270)
240 4
+3 2
cfn=(1160)
calls=2 116 
* 10
+1 4

fn=(4526)
199 35
cfn=(2146)
calls=5 51 
* 105
* 10

fn=(5148) QArrayData::data() const
58 8
+2 10
cfi=(62)
cfn=(922)
calls=2 623 
* 10
+2 10
+1 4

fn=(1160)
116 24385

fn=(4280)
211 10
+5 14
cfi=(96)
cfn=(2126)
calls=2 61 
* 1017
+1 4

fn=(4290)
203 16
cfn=(4288)
calls=2 -4 
* 68
* 16

fn=(4460)
240 2
+3 1
cfn=(1160)
calls=1 116 
* 5
+1 2

fn=(5146)
200 14
cfn=(5148)
calls=2 58 
* 42
* 4

fl=(126)
fn=(4980)
359 400
+3 1000
cfi=(125)
cfn=(2626)
calls=100 -55 
* 22800
fi=(125)
+1 200
fe=(126)

fl=(94)
fn=(2118)
703 14

ob=(6)
fl=(6)
fn=(296)
0 17

ob=(9)
fl=(9)
fn=(512)
0 17

ob=(10)
fl=(10)
fn=(524)
0 17

fn=(532)
0 3

ob=(13)
fl=(128)
fn=(2658)
49 20002024
cob=(3)
cfi=(3)
cfn=(1420)
calls=20002023 -49 
* 1760217182
cob=(1)
cfi=(1)
cfn=(243)
calls=1 -49 
* 1666
* 20002028

fl=(24)
fn=(638)
70 3
184 1
70 1
cob=(3)
cfi=(3)
cfn=(602)
calls=1 -70 
* 66
* 1
+1 3
184 1
71 1
cob=(3)
cfi=(3)
cfn=(602)
calls=1 -71 
* 66
* 1

fl=(15)
fn=(580)
0 17

fl=(21)
fn=(632)
1094 4
106 4
1107 3
+5 3
fi=(22) /build/gcc-multilib/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/concurrence.h
132 1
fe=(21)
1112 1
fi=(22)
132 13
fe=(21)
1094 4
106 4
1107 3
+5 3
fi=(22)
132 1
fe=(21)
1112 1
fi=(22)
132 14
fe=(21)
1107 1
412 3
+8 1
+1 2
1107 1
412 3
+8 1
+1 2

fl=(16)
fn=(588)
257 1
-43 2
-30 2
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
* 868
* 5
+30 2
+1 1
-31 1
+30 1
-30 1
+30 1
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
* 1665
* 5
-15 1
+16 1
-16 1
cfn=(596)
calls=1 -64 
* 4
* 1
+16 1
-16 1
+16 1
+42 1
-42 1
-16 1
+16 1
cob=(3)
cfi=(3)
cfn=(602)
calls=1 0 
* 66
* 1

fn=(596)
135 8

fl=(20)
fn=(626)
326 1
123 1
fi=(22)
+9 5
fe=(20)
-11 1
+2 1
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
* 1710
* 5
+1 1
-1 1
+1 1
+9 1
+2 1
+1 1
326 2

fl=(18)
fn=(612)
64 4
+10 1
-10 1
cob=(1)
cfi=(1)
cfn=(243)
calls=1 -64 
* 844
* 5
* 4
cob=(1)
cfi=(1)
cfn=(243)
calls=1 -64 
* 823
* 5
* 4
cob=(3)
cfi=(3)
cfn=(602)
calls=1 -64 
* 66
* 1
+10 3

fl=(17)
fn=(606)
124 1
-75 1
cob=(1)
cfi=(1)
cfn=(242)
calls=1 -49 
* 2593
* 5
* 2
+75 2

fl=(184)
fn=(4376)
32 5
cfi=(59)
cfn=(888)
calls=4 +11 
* 559
cob=(1)
cfi=(1)
cfn=(243)
calls=1 -32 
* 904
* 9

fl=(19)
fn=(618)
243 171
119 19
248 38
+6 76
-54 38
+81 38
-17 19
-1 19
+1 38
-26 38
345 190

fn=(624)
388 76
+4 38
200 19
397 19
+2 38
+26 95

fl=(23)
fn=(636)
338 54

fl=(25)
fn=(652)
1373 8
1603 4
1760 4
fi=(26) /build/gcc-multilib/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets.h
1879 4
2273 4
2553 4
fe=(25)
318 4
887 4
754 4
1966 4
fi=(27) /build/gcc-multilib/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_classes.h
792 5
fe=(25)

fn=(658)
1373 8
1603 4
1760 4
fi=(26)
1879 4
2273 4
2553 4
fe=(25)
318 4
887 4
754 4
1966 4
fi=(27)
792 5
fe=(25)

fn=(640)
1373 8
1603 4
1760 4
fi=(26)
1879 4
fe=(25)
754 4
1966 4
fi=(27)
792 5
fe=(25)

fn=(646)
1373 8
1603 4
1760 4
fi=(26)
1879 4
fe=(25)
754 4
1966 4
fi=(27)
792 5
fe=(25)

fl=(59)
fn=(888)
43 30002061
+5 30002061
-5 30002061
+5 60004122
+2 60004122
cob=(3)
cfi=(3)
cfn=(384)
calls=30002061 -50 
* 6252228705
* 30002061
* 60004122
+9 60004122

fl=(127)
fn=(2652)
32 2024
cfi=(128)
cfn=(2658)
calls=2023 +17 
* 221228
cob=(1)
cfi=(1)
cfn=(243)
calls=1 -32 
* 2368
* 2028

ob=(5)
fl=(5)
fn=(232)
0 64
cfn=(234) __libc_sigaction
calls=1 0 
0 62
0 7
cfn=(234)
calls=1 0 
0 62
0 11
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
0 3819
0 5
0 14
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
0 1925
0 5
0 31
cob=(2)
cfi=(2)
cfn=(254)
calls=1 0 
0 4
0 3
cob=(1)
cfi=(1)
cfn=(80)
calls=1 0 
0 2
0 23
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
0 2409
0 5
0 7

fn=(424)
0 165

fn=(398)
0 32
cfn=(400) __pthread_mutex_unlock_usercnt
calls=16 0 
0 342

fn=(400)
0 342

fn=(4798)
0 6
cfn=(4800) __read_nocancel
calls=3 0 
0 19

fn=(5078)
0 22
cfn=(5080) do_fcntl
calls=2 0 
0 18
0 4

fn=(5094)
0 4
cfn=(5096) __close_nocancel
calls=2 0 
0 10

fn=(1312)
0 10

fn=(234)
0 124

fn=(3854)
0 2
cfn=(3856) __write_nocancel
calls=1 0 
0 5

fn=(5330)
0 5072

fn=(434)
0 27822

fn=(1238) __pthread_once_slow
0 31
cfn=(1240) _pthread_cleanup_push
calls=1 0 
0 6
0 1
cob=(17)
cfi=(41)
cfn=(1242)
calls=1 162 
0 1273
0 3
cfn=(1248) _pthread_cleanup_pop
calls=1 0 
0 5
0 9

fn=(1264)
0 45

fn=(1438)
0 34

fn=(392)
0 460

fn=(1248)
0 5

fn=(1822)
0 24

fn=(276)
0 16

fn=(3514)
0 6
cfn=(3516) __open_nocancel
calls=3 0 
0 19

fn=(3524)
0 21

fn=(5312)
0 8876

fn=(268)
0 17

fn=(4800)
0 19

fn=(5096)
0 10

fn=(1274)
0 15

fn=(3856)
0 5

fn=(952)
0 1086

fn=(1392)
0 24

fn=(5080)
0 18

fn=(498)
0 170

fn=(1300)
0 50

fn=(1306)
0 90

fn=(3516)
0 19

fn=(1236)
0 4
cfn=(1238)
calls=1 0 
0 1328

ob=(7)
fl=(7)
fn=(4416)
0 2

fn=(308)
0 17

ob=(5)
fl=(5)
fn=(1240)
0 6

ob=(8)
fl=(8)
fn=(370) g_hash_table_new
0 6
cfn=(372) g_hash_table_new_full
calls=2 0 
0 70030

fn=(374) g_slice_alloc
0 190
cfn=(376) g_private_get
calls=19 0 
0 62400
0 171
cfn=(500) g_malloc
calls=19 0 
0 3076
0 325
cfn=(436) g_mutex_lock
calls=1 0 
0 5
0 3
cfn=(438) 0x0000000000065d10
calls=1 0 
0 3696
0 2
cfn=(480) g_mutex_unlock
calls=1 0 
0 5
0 9
cfn=(482) g_malloc0
calls=1 0 
0 1958
0 8
cfn=(492) g_private_set
calls=1 0 
0 1106
0 1

fn=(3778)
0 6
cfn=(436)
calls=2 0 
0 10
0 8
cfn=(480)
calls=2 0 
0 10
0 7
cfn=(3780) g_main_context_new
calls=1 0 
0 8003
0 2

fn=(4690) g_ptr_array_add
0 4833
cfn=(4692) 0x000000000001d2c0
calls=537 0 
0 7723
0 4833

fn=(500)
0 110
cob=(3)
cfi=(3)
cfn=(384)
calls=22 0 
0 3382
0 22
0 88

fn=(3790) g_slist_remove
0 7
cfn=(3792) g_slist_free_1
calls=1 0 
0 1702
0 5

fn=(3810) g_mutex_init
0 2

fn=(3870)
0 11

fn=(3876)
0 4
cfn=(3878) g_main_context_acquire
calls=1 0 
0 2062
0 3
cfn=(3778)
calls=1 0 
0 20
0 4
cfn=(376)
calls=1 0 
0 271
0 7
cfn=(3894) g_queue_push_head
calls=1 0 
0 285
0 3
cfn=(3892) g_queue_new
calls=1 0 
0 294
0 4
cfn=(492)
calls=1 0 
0 50
0 2

fn=(3922) g_hash_table_contains
0 68
cfn=(3924) g_direct_hash
calls=4 0 
0 8
0 146

fn=(4660) g_main_context_query
0 6994
cfn=(436)
calls=538 0 
0 2690
0 18298
cfn=(480)
calls=2 0 
0 10
0 1072
cfn=(480)
calls=536 0 
0 2680
0 4842

fn=(328)
0 6
cfn=(332) 0x0000000000045380
calls=1 0 
0 1973
0 1
cfn=(354) 0x0000000000045460
calls=1 0 
0 439
0 9
cfn=(370)
calls=1 0 
0 69480
0 3
cfn=(500)
calls=1 0 
0 197
0 5

fn=(372)
0 22
cfn=(374)
calls=2 0 
0 69086
0 32
cfn=(482)
calls=2 0 
0 429
0 10
cfn=(502) g_malloc0_n
calls=2 0 
0 433
0 18

fn=(3782) g_once_init_enter
0 6
cfn=(436)
calls=1 0 
0 5
0 5
cfn=(480)
calls=1 0 
0 5
0 9
cfn=(3784) g_slist_find
calls=1 0 
0 4
0 6
cfn=(3786) g_slist_prepend
calls=1 0 
0 194
0 2

fn=(3784)
0 4

fn=(3902)
0 40
cfn=(482)
calls=4 0 
0 795
0 12
cfn=(3882) g_slice_alloc0
calls=4 0 
0 1110
0 44

fn=(3930) g_hash_table_insert
0 76
cfn=(3924)
calls=4 0 
0 8
0 129
cfn=(3946) 0x0000000000037fa0
calls=3 0 
0 165
0 9
cfn=(3946)
calls=1 0 
0 1840
0 50

fn=(4048)
0 42

fn=(4648) 0x00000000000470a0
0 4340

fn=(4692)
0 3765
cfn=(4700) g_realloc
calls=1 0 
0 1802
0 2156

fn=(4738) g_main_context_dispatch
0 6456
cfn=(436)
calls=538 0 
0 2690
0 3226
cfn=(480)
calls=537 0 
0 2685
0 6444
cfn=(4740) 0x0000000000046990
calls=537 0 
0 20514
0 17719
cfn=(436)
calls=536 0 
0 2680
0 13943
cfn=(480)
calls=537 0 
0 2685
0 4296
cob=(17)
cfi=(169)
cfn=(5360)
calls=535 221 
0 97392583110
cob=(17)
cfi=(169)
cfn=(4816)
calls=1 171 
0 19361612911
cob=(17)
cfi=(169)
cfn=(4750)
calls=1 267 
0 637
0 3752
cfn=(4584) g_ptr_array_set_size
calls=536 0 
0 31624
0 536

fn=(4586) 0x0000000000046fc0
0 198940

fn=(436)
0 48450

fn=(320)
0 17

fn=(332)
0 26
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
0 1931
0 5
0 11

fn=(378) 0x000000000008d6a0
0 24
cob=(3)
cfi=(3)
cfn=(384)
calls=3 0 
0 564
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
0 59658
0 8
0 24
cob=(5)
cfi=(5)
cfn=(424)
calls=3 0 
0 120
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
0 1081
0 8
0 28

fn=(3892)
0 2
cfn=(3882)
calls=1 0 
0 292

fn=(3894)
0 6
cfn=(3896) g_list_prepend
calls=1 0 
0 272
0 7

fn=(3914)
0 52
cfn=(436)
calls=4 0 
0 20
0 16
cfn=(3916) 0x0000000000046b40
calls=4 0 
0 4180
0 12
cfn=(480)
calls=4 0 
0 20
0 20

fn=(4560)
0 4842
cfn=(436)
calls=538 0 
0 2690
0 538
cfn=(3880) g_thread_self
calls=538 0 
0 19906
0 2152
cfn=(4562) 0x0000000000049e50
calls=538 0 
0 116755989170
0 1611
cfn=(480)
calls=537 0 
0 2685
0 2685

fn=(4562)
0 7532
cfn=(480)
calls=538 0 
0 2690
0 1076
cfn=(3878)
calls=538 0 
0 39812
0 8596
cfn=(436)
calls=538 0 
0 2690
0 3766
cfn=(480)
calls=538 0 
0 2690
0 1614
cfn=(4582) g_main_context_prepare
calls=538 0 
0 904105
0 3766
cfn=(4660)
calls=538 0 
0 36586
0 7532
cfn=(4688) g_main_context_check
calls=538 0 
0 609851
0 3226
cfn=(4766) g_main_context_release
calls=537 0 
0 13425
0 1074
cfn=(436)
calls=537 0 
0 2685
0 1613
cfn=(436)
calls=538 0 
0 2690
0 1614
cfn=(480)
calls=538 0 
0 2690
0 2152
cfn=(4674) g_poll
calls=538 0 
0 6868
0 2152
cfn=(4738)
calls=538 0 
0 116754315908
0 541
cfn=(4574) g_malloc_n
calls=1 0 
0 223
0 3

fn=(4674)
0 1076
cob=(3)
cfi=(3)
cfn=(4680)
calls=537 0 
0 3759
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1491
0 542

fn=(4574)
0 9
cfn=(500)
calls=1 0 
0 214

fn=(482)
0 70
cob=(3)
cfi=(3)
cfn=(488)
calls=9 0 
0 2047
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
0 1942
0 14
0 40

fn=(502)
0 18
cfn=(482)
calls=2 0 
0 415

fn=(3818) 0x000000000008cb40
0 9
cfn=(374)
calls=1 0 
0 181
0 4
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1550
0 5
0 12

fn=(3924)
0 16

fn=(4760) g_ptr_array_remove_range
0 20904

fn=(4766)
0 4296
cfn=(436)
calls=537 0 
0 2685
0 3759
cfn=(480)
calls=537 0 
0 2685

fn=(3780)
0 8
cfn=(482)
calls=1 0 
0 516
0 3
cfn=(3810)
calls=1 0 
0 2
0 3
cfn=(3812) g_cond_init
calls=1 0 
0 2
0 3
cfn=(370)
calls=1 0 
0 556
0 11
cfn=(3814) g_ptr_array_new
calls=1 0 
0 198
0 3
cfn=(3818)
calls=1 0 
0 1761
0 4
cfn=(3834) 0x000000000008cc40
calls=1 0 
0 5
0 4
cfn=(3836) 0x0000000000046360
calls=1 0 
0 1209
0 2
cfn=(436)
calls=1 0 
0 5
0 3
cfn=(3864) g_slist_append
calls=1 0 
0 207
0 3
cfn=(480)
calls=1 0 
0 5
0 7
cfn=(3782)
calls=1 0 
0 236
0 5
cfn=(3788) g_once_init_leave
calls=1 0 
0 3241
0 1

fn=(3794) g_slice_free1
0 39
cfn=(3796) g_free
calls=1 0 
0 1655
0 5

fn=(3954) g_memdup
0 9
cfn=(500)
calls=1 0 
0 115
0 4
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1635
0 5
0 4

fn=(3978) 0x00000000000469e0
0 67
cfn=(3882)
calls=1 0 
0 292
0 5
cfn=(3984) g_list_append
calls=1 0 
0 286
0 78
cfn=(3882)
calls=1 0 
0 292
0 5
cfn=(3984)
calls=1 0 
0 274
0 2

fn=(3984)
0 14
cfn=(374)
calls=2 0 
0 512
0 12
cfn=(4068) g_list_last
calls=1 0 
0 8
0 14

fn=(4068)
0 8

fn=(4700)
0 7
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1788
0 5
0 2

fn=(4792) 0x000000000008cc50
0 26
cob=(5)
cfi=(5)
cfn=(4798)
calls=1 0 
0 11
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 913
0 6
0 18

fn=(4582)
0 8608
cfn=(436)
calls=538 0 
0 2690
0 7532
cfn=(4584)
calls=538 0 
0 8608
0 6994
cfn=(4586)
calls=538 0 
0 18830
0 4839
cfn=(4586)
calls=1613 0 
0 59128
0 43035
cfn=(480)
calls=2151 0 
0 10755
0 6453
cob=(17)
cfi=(169)
cfn=(4778)
calls=537 196 
0 302856
cob=(17)
cfi=(169)
cfn=(4616)
calls=538 147 
0 13299
cob=(17)
cfi=(169)
cfn=(4614)
calls=538 62 
0 5918
cob=(17)
cfi=(169)
cfn=(4602)
calls=538 245 
0 308275
0 6453
cfn=(436)
calls=2151 0 
0 10755
0 28523
cfn=(4586)
calls=538 0 
0 21532
0 2681
cfn=(4648)
calls=535 0 
0 2140
0 6
cfn=(4648)
calls=3 0 
0 24
0 1076
cfn=(480)
calls=538 0 
0 2690
0 20405

fn=(4584)
0 16648
cfn=(4760)
calls=536 0 
0 20904
0 2680

fn=(466) g_get_current_time
0 11
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
0 1629
0 5
0 10

fn=(376)
0 19632
cob=(5)
cfi=(5)
cfn=(434)
calls=1634 0 
0 27778
0 1634
0 20
cob=(5)
cfi=(5)
cfn=(434)
calls=3 0 
0 33
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
0 1069
0 8
0 12
cfn=(378)
calls=4 0 
0 61515
0 16

fn=(3812)
0 2

fn=(3816) g_ptr_array_sized_new
0 5
cfn=(374)
calls=1 0 
0 181
0 10

fn=(3836)
0 8
cfn=(374)
calls=1 0 
0 181
0 45
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 968
0 5
0 2

fn=(3880)
0 3243
cfn=(376)
calls=1081 0 
0 32664
0 4324
cfn=(3882)
calls=1 0 
0 1696
0 5
cfn=(492)
calls=1 0 
0 50
0 3

fn=(3908)
0 76

fn=(3916)
0 76
cfn=(3922)
calls=4 0 
0 222
0 36
cfn=(3930)
calls=4 0 
0 2277
0 12
cfn=(3978)
calls=4 0 
0 1301
0 72
cfn=(3880)
calls=4 0 
0 148
0 36

fn=(480)
0 48450

fn=(3788)
0 13
cfn=(436)
calls=1 0 
0 5
0 3
cfn=(3790)
calls=1 0 
0 1714
0 3
cfn=(3802) g_cond_broadcast
calls=1 0 
0 1495
0 3
cfn=(480)
calls=1 0 
0 5

fn=(3802)
0 8
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1482
0 5

fn=(3834)
0 5

fn=(3864)
0 7
cfn=(374)
calls=1 0 
0 190
0 10

fn=(3878)
0 2695
cfn=(3880)
calls=539 0 
0 21931
0 2695
cfn=(436)
calls=539 0 
0 2695
0 6463
cfn=(480)
calls=538 0 
0 2690
0 5
cfn=(480)
calls=1 0 
0 5
0 2695

fn=(3882)
0 45
cfn=(374)
calls=9 0 
0 2187
0 63
cob=(3)
cfi=(3)
cfn=(3890)
calls=8 0 
0 152
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1493
0 13
0 45

fn=(3896)
0 7
cfn=(374)
calls=1 0 
0 256
0 9

fn=(3946)
0 121
cfn=(3954)
calls=1 0 
0 1772
0 112

fn=(438)
0 8
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
0 1547
0 5
0 16
cob=(3)
cfi=(3)
cfn=(340)
calls=1 0 
0 410
0 1
0 8
cfn=(466)
calls=1 0 
0 1655
0 46

fn=(492)
0 36
cob=(5)
cfi=(5)
cfn=(498)
calls=3 0 
0 102
cob=(1)
cfi=(1)
cfn=(242)
calls=1 0 
0 1086
0 8
0 24

fn=(354)
0 15
cob=(3)
cfi=(3)
cfn=(340)
calls=1 0 
0 410
0 1
0 13

fn=(3786)
0 7
cfn=(374)
calls=1 0 
0 181
0 6

fn=(3792)
0 3
cfn=(3794)
calls=1 0 
0 1699

fn=(3796)
0 3
cob=(1)
cfi=(1)
cfn=(243)
calls=1 0 
0 1647
0 5

fn=(3814)
0 2
cfn=(3816)
calls=1 0 
0 196

fn=(4688)
0 8070
cfn=(436)
calls=538 0 
0 2690
0 20976
cfn=(4586)
calls=538 0 
0 18830
0 4839
cfn=(4586)
calls=1613 0 
0 59143
0 27974
cfn=(4690)
calls=537 0 
0 17389
0 2685
cfn=(4586)
calls=537 0 
0 21477
0 2150
cfn=(4648)
calls=538 0 
0 2176
0 1076
cfn=(480)
calls=538 0 
0 2690
0 19368
cfn=(480)
calls=1614 0 
0 8070
0 3228
cob=(17)
cfi=(169)
cfn=(4810)
calls=1 210 
0 18
cob=(17)
cfi=(169)
cfn=(4808)
calls=537 262 
0 314145
cob=(17)
cfi=(169)
cfn=(4714)
calls=538 163 
0 8925
cob=(17)
cfi=(169)
cfn=(4710)
calls=538 69 
0 27438
0 4842
cfn=(436)
calls=1614 0 
0 8070
0 22602
cfn=(4792)
calls=2 0 
0 974
0 6

fn=(4740)
0 1611
cfn=(376)
calls=537 0 
0 16382
0 2148
cfn=(3882)
calls=1 0 
0 316
0 4
cfn=(492)
calls=1 0 
0 50
0 3

totals: 141911466742

From thiago.macieira at intel.com  Thu Jul 14 20:39:31 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 14 Jul 2016 11:39:31 -0700
Subject: [Development] leak in QMetaObject?
In-Reply-To: <fe95a8e3-c0df-9194-8d88-28c94740be4f@pelagicore.com>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<4953729.Zy6zGIe2KL@tjmaciei-mobl1>
	<fe95a8e3-c0df-9194-8d88-28c94740be4f@pelagicore.com>
Message-ID: <1678130.UyVkYXaTSW@tjmaciei-mobl1>

On quinta-feira, 14 de julho de 2016 19:08:11 PDT Thomas Senyk wrote:
> On 14.07.2016 18:56, Thiago Macieira wrote:
> > On quinta-feira, 14 de julho de 2016 18:37:17 PDT Thomas Senyk wrote:
> >> On 14.07.2016 18:25, Thiago Macieira wrote:
> >>> On quinta-feira, 14 de julho de 2016 17:45:58 PDT Thomas Senyk wrote:
> >>>> should "fix" it? .. but I still see 100% cpu and same memory
> >>>> consumption?
> >>> 
> >>> Can you attach the debugger to see what it is still doing after you're
> >>> done?
> >> 
> >> Still the same, goes in circles around in QMetaObject::activate
> >> 
> >> #3671 => #3673 =>  if (!c->receiver) continue => while => ...
> >> ... pressing F10 for a while doesn't let you out of that (short) cycle.
> >> 
> >> If you want to know (I know it's not saying much) the values for
> >> list->first and list->last: @0x1529ac0, @0x6a3a3250
> >> 
> >> 
> >> Is that what you wanted to know? If I misunderstood, please clarify :)
> > 
> > I wanted a backtrace. Are you saying the trace is 3700 frames deep?
> 
> Sorry that was line numbers :) No it's not.
> 
> http://paste.ofcode.org/u3gGqxAfX9hWefeUszDEx
> 
> About to generate a callgrind output.

It's a little hard to tell from your backtrace. The Qt Creator copy & paste is 
never the right thing, since it doesn't include function parameters. Please 
use the gdb "bt" command whenever possible. That means debugging outside 
Creator, since Creator can't get the output from that. If that is too difficult, 
the "full backtrace" is a good compromise.

Anyway, I think your test is faulty. When you write:

            if ((i%10000000)==0) {
                QObject::connect(t, &QTimer::timeout, []() {
                    qDebug() << "test .. it should be empty now?";
                });
            }

First of all, why did you use a modulo instead of straight up comparison?

Anyway, as far as I can tell, the sender (the QTimer) connectionLists vector 
contains 4 entries, only one of which is non-empty. That's the one 
corresponding to the timeout() signal. Each connection list is a *singly* 
linked list, so it has O(n) behaviour and your n is 10 million.

We talked about cleanConnectionLists. But that function starts with 

    if (connectionLists->dirty && !connectionLists->inUse) {

For the first 10 million times this function is called, the "dirty" flag is 
false. Then your lambdas start getting called and set the "dirty" flag to true.

On the 10 million + 1 time that the function is called, from that connect() 
call above, "dirty" is true, but so is "inUse", because you're in the middle 
of delivering signals. 

So the list isn't cleaned.

After this, there's only one slot connected to the signal, but the list is 10M
+1 items long.

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



From nospam at vuorela.dk  Thu Jul 14 22:43:52 2016
From: nospam at vuorela.dk (Sune Vuorela)
Date: Thu, 14 Jul 2016 20:43:52 +0000 (UTC)
Subject: [Development] leak in QMetaObject?
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<2341736.oJ5JHeR8WT@maurice>
	<46fd590e-4995-7c1c-1ecd-98e7775b734d@familiesomers.nl>
	<25dd1da6-1eac-4b18-b024-74bf3b527494@pelagicore.com>
Message-ID: <nm8ti8$gm4$1@ger.gmane.org>

On 2016-07-14, Thomas Senyk <thomas.senyk at pelagicore.com> wrote:
>>>> I see neither one nor the other. I see continues 100% consume with no
>>>> memory consumption drop what so ever.
> should "fix" it? .. but I still see 100% cpu and same memory consumption?

I debugged some time ago a case of a unresponsive application (for 30
seconds on a fairly beefy windows machine with sufficient ram)

There was a memory leak that involved leaking connections to lambdas of
the pattern:

m_foo = std::make_shared<SomeQObject>();
(void)connect(m_foo.get(), &SomeQObject::someSignal, [m_foo]() {
  });

But a interesting point here was that after leaking some thousand
objects, the application became crawling when recreating most of the
UI's quickitems. There was still plenty of memory free on the system.

Plugging this leak didn't do much for the memory consumption of the
application, but the speed of the 'recreate ui' didn't slow down over
time any longer, at least within the testing done with that.

(This was qt5.4.1)

I haven't gotten around investigating it any further. But it kind of
feels relevant here.

/Sune
(I wrote a bit more of that code on http://pusling.com/blog/?p=446
should anyone be curious)



From alexander.blasche at qt.io  Fri Jul 15 08:07:31 2016
From: alexander.blasche at qt.io (Alexander Blasche)
Date: Fri, 15 Jul 2016 06:07:31 +0000
Subject: [Development] Be aware: QtLocation's free MapQuest service
 discontinued
Message-ID: <AM4PR0201MB2164682A9284E507561B4AE8E7330@AM4PR0201MB2164.eurprd02.prod.outlook.com>

Hi,

Qt Location provides three content/map provider plugins (HERE, MapBox and MapQuest). The first two providers require an account to run and MapQuest was free of any registration so far. Unfortunately this changed this Monday. More details in:

https://bugreports.qt.io/browse/QTBUG-54599

As a consequence any QtLocation application that uses MapQuest will no longer receive any map tiles. The only possible way to fix this today is to change from MapQuest to HERE or MapBox. Although those providers require a registration they do offer free of charge usage models. Please be aware of their terms and conditions though. 

We are very sorry for this problem but at the end of the day there is not much Qt can do. We are working on a patch to change to a new registration free provider and even a related indirection but at the end of the day, registration free access is becoming a thing of the past.

Going forward I would suggest to to always consider some form of registered usage for any map provider. While we will continue to address upcoming service changes this does ensure that there is some form of business relationship between you and your chosen map tile provider. At the very least it means that  notifications can be received before drastic changes happen.

--
Alex

From konrad at silmor.de  Sat Jul 16 13:56:00 2016
From: konrad at silmor.de (Konrad Rosenbaum)
Date: Sat, 16 Jul 2016 13:56 +0200
Subject: [Development] Why is QVariant::data() \internal?
Message-ID: <2363391.iQtkevNy5N@zaphod>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160716/1f6c33c9/attachment.sig>

From jedrzej.nowacki at qt.io  Mon Jul 18 07:59:21 2016
From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki)
Date: Mon, 18 Jul 2016 07:59:21 +0200
Subject: [Development] Why is QVariant::data() \internal?
In-Reply-To: <2363391.iQtkevNy5N@zaphod>
References: <2363391.iQtkevNy5N@zaphod>
Message-ID: <2237761.AXeKDNI8Ok@42>

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?


From albert.astals at canonical.com  Mon Jul 18 10:24:11 2016
From: albert.astals at canonical.com (Albert Astals Cid)
Date: Mon, 18 Jul 2016 10:24:11 +0200
Subject: [Development] Image and PreserveAspectCrop
Message-ID: <CAA0DqqD0BdhDCqW0z925+0Cm=Uia8rEcEbfZ4A8WC4Qhh9WxcA@mail.gmail.com>

There is a problem when trying to optimally[*] show an Image with
PreserveAspectCrop fillMode.
[*]optimally => as best looking as possible while using as litte
memory as possible

You can see that problem in the screenshot at http://i.imgur.com/LSSlFEB.png
that corresponds with the code at http://paste.ubuntu.com/19480453/

As you can see when displaying a landscape (width > height) image in a
square Image Item the optimal way
is to set the source size height only, but if the image is portrait
(height > width) then the optimal way
is to set the source size width only.

The requirement my program has is to have the best rendering quality
and memory usage for Image Items using PreserveAspectCrop.
Image sources are totally arbitrary, they can be from disk, from the
internet or even from QQuickImageProviders
(since we are plugin based and plugins can bring their own QQuickImageProvider)

This can be fixed in several ways.

Workaround A
**********
Changing the Image Item source size comparing the aspect ratio of the
image file with the one Image Item.

You can see an implementation of that workaround at
http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/plugins/Dash/CroppedImageMinimumSourceSize.qml

The problem with this workaround is that half of the times you end up
loading the image a second time.
This means extra CPU and potentially network usage.



Workaround B
**********
Implementing your own image provider that does compare the aspect
ratios before loading the image.

You can see a partial implementation of this workaround at
https://code.launchpad.net/~aacid/unity8/croppedImageMinimumSourceSizeProvider/+merge/300176

There are two problems with this workaround:
 * You end up implementing quite a bit of duplicated functionality
from qquickpixmapcache.cpp
 * For the chained image providers (i.e. the original source was an
image provider url) you
   still have to query the image provider twice half of the times



Solution
********
Implementing the change in QtQuick internals so that when
PreserveAspectCrop fillMode is used
together with a sourceSize that has both width and height it does
return the optimal image

You can see a work in progress implementation of this solution at
https://codereview.qt-project.org/#/c/165299/
And how the previews could would look at
http://i.imgur.com/NRoXNzy.png (notice how the last column now is good
in both cases)

There are two issues with this solution:
 * It's a small behaviour change (but in my opinion for the better)
 * Needs new api for the QQuickImageProvider to be able to implement
it, so we either need the proposed
   QQuickImageProviderV2 or with a new "bool
shouldPreserveAspectRatioCrop(url, requestSize)" getter in the
   existing QQuickImageProvider API



All in all I think the solution i propose for QtQuick is acceptable
but i would like some agreeing that is fine adding new API before
finishing the patch.


From konstantin at podsvirov.pro  Mon Jul 18 20:17:45 2016
From: konstantin at podsvirov.pro (Konstantin Podsvirov)
Date: Mon, 18 Jul 2016 21:17:45 +0300
Subject: [Development] [Review Request][Draft] CMake project for QtIFW
Message-ID: <25141468865865@web4m.yandex.ru>

Hello guys!

I like CMake and Qt and i initial write and now support CPack IFW generator.

For more project integrations i create sugestion:
https://bugreports.qt.io/browse/QTIFW-876

And start work on it:
https://codereview.qt-project.org/#/c/165493

It's draft, but any feedback will be appreciated.

--
Regards,
Konstantin Podsvirov


From konrad at silmor.de  Mon Jul 18 23:15:22 2016
From: konrad at silmor.de (Konrad Rosenbaum)
Date: Mon, 18 Jul 2016 23:15:22 +0200
Subject: [Development] Why is QVariant::data() \internal?
In-Reply-To: <2237761.AXeKDNI8Ok@42>
References: <2363391.iQtkevNy5N@zaphod> <2237761.AXeKDNI8Ok@42>
Message-ID: <1837442.4ddaBHsu6c@zaphod>

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.


	Konrad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160718/1f5ba5a1/attachment.sig>

From sschilz at pasco.com  Tue Jul 19 01:37:01 2016
From: sschilz at pasco.com (Steve Schilz)
Date: Mon, 18 Jul 2016 23:37:01 +0000
Subject: [Development] QWebEngine - H.264 playback, proprietary codecs.
Message-ID: <1C2A7CDC-7561-4AFF-9F6E-6CAED80E0840@pasco.com>

-----------------------------

Thiago, Allan, Thanks for responding.

Probably complicated indeed!  Qt in general does a pretty great job of shielding us from lots of complexity.   I need to look into the ‘Free for decoding’ part more carefully, as that is my immediate need.  It seemed worth mentioning, and certainly imho makes QWebEngine all the more attractive if it could be made to work.

Steve Schilz
Pasco Scientific


Allan SandField Jensen Wrote:
>> Date: Wed, 13 Jul 2016 19:21:16 +0200
>> From: Allan Sandfeld Jensen <kde at carewolf.com<mailto:kde at carewolf.com>>
>> To: development at qt-project.org<mailto:development at qt-project.org>
>> Subject: Re: [Development] QWebEngine - H.264 playback, proprietary
>>    codecs.
>> Message-ID: <201607131921.16144.kde at carewolf.com<mailto:201607131921.16144.kde at carewolf.com>>
>> Content-Type: Text/Plain;  charset="utf-8"
>>
>> On Wednesday 13 July 2016, Steve Schilz wrote:
>> We are using QWebEngine to drive a hybrid app (Html5 + Javascript + C++) on
>> windows.  According to QWebEngineFeatures Doc,
>> http://doc.qt.io/qt-5/qtwebengine-features.html#pepper-plugin-api You must
>> pass a flag to qmake, WEBENGINE_CONFIG+=use_proprietary_codecs, and build
>> Qt from source yourself in order to support h.264 video decoding.
>>
>> In researching this, I became aware that Cisco provides a downloadable
>> binary codec, where Cisco pays the MPEG-LA royalties.   Apparently this is
>> the method used To provide h.264 playback in Firefox.  If you watch the
>> intellectual property rights video at
>> http://vimeo.com/cullenfluffyjennings/openh264-ipr, they explain why they
>> Did this, and how you can even make changes to the codec via open source
>> if needed.
>>
>> Would it make sense for QWebEngine to support this codec, in order to be
>> able to provide ?out of the box? (via download at end user?s computer),
>> support for h.264 playback in <video> tags?


> That sounds a bit complicated, since it needs to hook into Chromiums media
> backend and have a download mechanism.
>
> Note activating it the codecs is not a matter of cost. AFAIK the h.264 and
> h.265 codecs are currently patented but royalty free to decode. This makes it
> possible for our customers to activate them without paying anyway. This is
> however just the status quo, and I am not sure I want to risk enabling
> something that might make the open-source package something that you need to
> pay for in the future, which is why we prefer to stick with the same codecs
> Google makes available in their free open source browser Chromium.
>
> I would be more interested in making it easier to enable, or maybe offer
> somehow. It is just something we have to make sure we offer without
> guaranteeing it is and will remain free.
>
> `Allan




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160718/17a3f03e/attachment.html>

From louai.al-khanji at qt.io  Tue Jul 19 03:08:52 2016
From: louai.al-khanji at qt.io (Louai Al-Khanji)
Date: Tue, 19 Jul 2016 01:08:52 +0000
Subject: [Development] Source break policy for function overloads
In-Reply-To: <6279245.f20ygS2Rua@tjmaciei-mobl1>
References: <AM4PR0201MB216405BF9A466223CFC1005CE7310@AM4PR0201MB2164.eurprd02.prod.outlook.com>
	<6279245.f20ygS2Rua@tjmaciei-mobl1>
Message-ID: <D2B4A4E8-929D-487C-A7D0-DB2FADED90A4@qt.io>


> On Jul 13, 2016, at 9:47 AM, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> Em quarta-feira, 13 de julho de 2016, às 10:44:13 PDT, Alexander Blasche 
> escreveu:
>> 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, &QModbusClient::timeoutChanged, element.timer.data(),
>> &QTimer::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?
> 
> We do have this policy since 5.0 that we have to be careful about overloads 
> due to the connect syntax. The breakage was accidental and not intended.
> 
> I did intend to add overloads, as they're nice to use, I just hadn't 
> considered the consequences.
> 

While I agree that we must be careful when adding new overloads, I think we can do better with QObject::connect as well. I played around with this patch today, it fixes the breakage that sparked this thread without any other modifications:

https://codereview.qt-project.org/165505

There are obviously things to improve in this WIP patch, but I do believe we can make improvements by hinting to the compiler which member function it should choose. I’ll explore this some more unless someone has a clear reason not to go down this road.

Cheers,
Louai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160719/4e9fb204/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3577 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160719/4e9fb204/attachment.bin>

From pr12og2 at programist.ru  Tue Jul 19 10:57:20 2016
From: pr12og2 at programist.ru (Prav)
Date: Tue, 19 Jul 2016 11:57:20 +0300
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
Message-ID: <726314440.20160719115720@programist.ru>

Hello, Everyone!

> The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to
> focus on two aspects:
>     1) Automatic scale factor configuration based on system settings.
There so many debates about this topic and how to get real DPI for all devices correctly.
But I personally does get this as SO important thing. And this is because people are different
and have different preferences about reading from screen (because of eyes or just personally).
Which brings me to understanding that it does not matter what is the DPI of screen. It matter only
how large PERSON want program font normally be.
So I would expect that the main intention in developing of apps should be moved toward giving
the user possibility to scale the app.
And you are done!

All this problems in getting correct DPI of screen would NOT be so painfull. Your phone or monitor or OS or something
resulted in incorrect scale factor? ... does not matter! ... increase/decrease scale factor for that app as you like ... and here you are ... having this app
comfortable for eyes and personal preferences (not for DPI of scrrent ... most people even do not know what it is and why they should care)!
App should remember of couse this setting to restore it back at restart

>     2) Handling fractional scale factors (rounding).
Previous idea need fractional scale factors to work ... FOR SURE!



PS I can give many more cases then getting right DPI does not give usability to user.
1. Developers or Designers are young, have good eyes are pretty conformable with small fonts.
    They produce app with HighDPI support which correctly scales to DPI of HighDPI user device. But ... this does not mean
    that old persons would feel comfortable with the app ... their eyes see not as good as when they were young.
2. Could be a reverse case ... like you want smaller because devs created app which seems larger to you.
3. Devs and Designers usually have good tech. I mean good monitors, modern phones with good crisp screen.
    But user's tablet/phone can be not modern or be cheap or with tons of scratches (for example with plastic (not glass screens)).
    Sooo ... visibility is much worse ... but DPI could be same.
4. You are OK with design and size of app's fonts at your notebook/tablet with like 10'', devs and designer see things the same good as you
    and your screen is modern and good with gorilla glass or something same and DPI scale factor was determined exactly as it is.
    But now you are inside city transport ... and guess what ...
    you are shaken! ... and this mean you see the screen worse ... you need to increase the scale!
    And if you sit/lay still in the bedroom you what smaller font to see more info at once.

I have nothing against getting right DPI at app's startup ...

I wanted just to say that I see that it is actually NOT THE MAIN PURPOSE! ... for usability!

May be Qt need to move accents from getting right DPI to making it user changeable ... FRACTIONALLY (as a good new practice)!
Like 10-20 % steps ... not just 2,3,4,5.

I do not see much trend in Qt-discussions/apps-interfaces about user-defined scale factor. But only THIS is important to user.
And NOT DPI ;)



From frank at hemer.org  Tue Jul 19 12:07:31 2016
From: frank at hemer.org (Frank Hemer)
Date: Tue, 19 Jul 2016 12:07:31 +0200
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <726314440.20160719115720@programist.ru>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<726314440.20160719115720@programist.ru>
Message-ID: <2813435.GFRHcYJinp@master>

On Tuesday 19 July 2016 11:57:20 Prav wrote:
> Hello, Everyone!
> 
> > The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to
> > 
> > focus on two aspects:
> >     1) Automatic scale factor configuration based on system settings.
> 
> There so many debates about this topic and how to get real DPI for all
> devices correctly. But I personally does get this as SO important thing.
> And this is because people are different and have different preferences
> about reading from screen (because of eyes or just personally). Which
> brings me to understanding that it does not matter what is the DPI of
> screen. It matter only how large PERSON want program font normally be.
> So I would expect that the main intention in developing of apps should be
> moved toward giving the user possibility to scale the app.
> And you are done!
> 
> All this problems in getting correct DPI of screen would NOT be so painfull.
> Your phone or monitor or OS or something resulted in incorrect scale
> factor? ... does not matter! ... increase/decrease scale factor for that
> app as you like ... and here you are ... having this app comfortable for
> eyes and personal preferences (not for DPI of scrrent ... most people even
> do not know what it is and why they should care)! App should remember of
> couse this setting to restore it back at restart
> >     2) Handling fractional scale factors (rounding).
> 
> Previous idea need fractional scale factors to work ... FOR SURE!
> 
> 
> 
> PS I can give many more cases then getting right DPI does not give usability
> to user. 1. Developers or Designers are young, have good eyes are pretty
> conformable with small fonts. They produce app with HighDPI support which
> correctly scales to DPI of HighDPI user device. But ... this does not mean
> that old persons would feel comfortable with the app ... their eyes see not
> as good as when they were young. 2. Could be a reverse case ... like you
> want smaller because devs created app which seems larger to you. 3. Devs
> and Designers usually have good tech. I mean good monitors, modern phones
> with good crisp screen. But user's tablet/phone can be not modern or be
> cheap or with tons of scratches (for example with plastic (not glass
> screens)). Sooo ... visibility is much worse ... but DPI could be same.
> 4. You are OK with design and size of app's fonts at your notebook/tablet
> with like 10'', devs and designer see things the same good as you and your
> screen is modern and good with gorilla glass or something same and DPI
> scale factor was determined exactly as it is. But now you are inside city
> transport ... and guess what ...
>     you are shaken! ... and this mean you see the screen worse ... you need
> to increase the scale! And if you sit/lay still in the bedroom you what
> smaller font to see more info at once.
> 
> I have nothing against getting right DPI at app's startup ...
> 
> I wanted just to say that I see that it is actually NOT THE MAIN PURPOSE!
> ... for usability!
> 
> May be Qt need to move accents from getting right DPI to making it user
> changeable ... FRACTIONALLY (as a good new practice)! Like 10-20 % steps
> ... not just 2,3,4,5.
> 
> I do not see much trend in Qt-discussions/apps-interfaces about user-defined
> scale factor. But only THIS is important to user. And NOT DPI ;)

Precisely my experience
+1

Frank


From edward.welbourne at qt.io  Tue Jul 19 12:38:04 2016
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Tue, 19 Jul 2016 10:38:04 +0000
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <2813435.GFRHcYJinp@master>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<726314440.20160719115720@programist.ru>,<2813435.GFRHcYJinp@master>
Message-ID: <AM2PR02MB075425155C43A2EF5FAB806A87370@AM2PR02MB0754.eurprd02.prod.outlook.com>

On Tuesday 19 July 2016 11:57:20 Prav wrote:
>> it does not matter what is the DPI of screen. It matter only how
>> large PERSON want program font normally be.  So I would expect that
>> the main intention in developing of apps should be moved toward
>> giving the user possibility to scale the app.
[snip]
>> I do not see much trend in Qt-discussions/apps-interfaces about
>> user-defined scale factor. But only THIS is important to user. And
>> NOT DPI ;)

The situation with app-UIs reminds me of that with web-pages.

Back in 1994, when I first met the web, one of the things that delighted
me about it was that the user was in control of how things were
displayed; the author's mark-up said the general necessities
(paragraphs, headings, etc.) and left it to the user agent and user to
find a way of displaying the content that the user found it convenient
and easy to read.

This flew in the face of graphic design orthodoxy, where the author must
control every particular of the user's experience - the size of the
page, the fonts and colours used, the margins and layout.  In time, the
graphic designers got their way and now they are able to impose their
choices on users.  So their lamentation is great when the can't take all
control away from the user.

I'm still entirely sure that "let the user decide" was a better way to
settle how big the page should be, what fonts and colour-schemes to use;
by all means let the author give hints and suggestions to the
presentation system, but let the user have the final say.  I shall like
the look of your document better if it's in a font I've chosen because I
find it easier or nicer to read; I shall like the appearance of your
page better if the overall colour scheme fits in with my desktop
environment; I shall like your web-site better if it adapts itself to my
tastes - and letting it do so spares you the need to agonise over which
entirely subjective details appeal to a bigger audience.

It used to be easy on the web; now it has become difficult, because the
emphasis has all been on giving the author control, not the user.  Let
us try to give app-UI designers the chance to go in the opposite
direction.

Frank Hemer replied:
> Precisely my experience
> +1

Likewise,
+1

	Eddy.


From ulf.hermann at qt.io  Tue Jul 19 12:48:02 2016
From: ulf.hermann at qt.io (Ulf Hermann)
Date: Tue, 19 Jul 2016 12:48:02 +0200
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <AM2PR02MB075425155C43A2EF5FAB806A87370@AM2PR02MB0754.eurprd02.prod.outlook.com>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<726314440.20160719115720@programist.ru> <2813435.GFRHcYJinp@master>
	<AM2PR02MB075425155C43A2EF5FAB806A87370@AM2PR02MB0754.eurprd02.prod.outlook.com>
Message-ID: <fa870138-825f-eb9b-91ec-8ce732349260@qt.io>


> I'm still entirely sure that "let the user decide" was a better way to
> settle how big the page should be, what fonts and colour-schemes to use;
> by all means let the author give hints and suggestions to the
> presentation system, but let the user have the final say.  I shall like
> the look of your document better if it's in a font I've chosen because I
> find it easier or nicer to read; I shall like the appearance of your
> page better if the overall colour scheme fits in with my desktop
> environment; I shall like your web-site better if it adapts itself to my
> tastes - and letting it do so spares you the need to agonise over which
> entirely subjective details appeal to a bigger audience.

I totally agree with this as long as we're talking about documents - mostly consisting of text, to be read top to bottom (or some other direction, depending on locale). It gets hairy if we're talking about graphical applications where text only plays a minor role, and most of the visual elements have size constraints. It's very hard to have all those visual elements and their interactions scale smoothly to any dimensions or color schemes the user may choose. So, for those applications the designer usually chooses a few predefined UI styles, and tries to prevent the user from messing with those, as the result of that messing would only look bad and glitchy.

Ulf


From s.stirtzel at googlemail.com  Tue Jul 19 13:38:13 2016
From: s.stirtzel at googlemail.com (Samuel Stirtzel)
Date: Tue, 19 Jul 2016 13:38:13 +0200
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <fa870138-825f-eb9b-91ec-8ce732349260@qt.io>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<726314440.20160719115720@programist.ru>
	<2813435.GFRHcYJinp@master>
	<AM2PR02MB075425155C43A2EF5FAB806A87370@AM2PR02MB0754.eurprd02.prod.outlook.com>
	<fa870138-825f-eb9b-91ec-8ce732349260@qt.io>
Message-ID: <CAGiJk9c-HVd-MzhbGThMODC3SgbUqspB_J2YnaxnFnt6HjtdPQ@mail.gmail.com>

2016-07-19 12:48 GMT+02:00 Ulf Hermann <ulf.hermann at qt.io>:
>
>> I'm still entirely sure that "let the user decide" was a better way to
>> settle how big the page should be, what fonts and colour-schemes to use;
>> by all means let the author give hints and suggestions to the
>> presentation system, but let the user have the final say.  I shall like
>> the look of your document better if it's in a font I've chosen because I
>> find it easier or nicer to read; I shall like the appearance of your
>> page better if the overall colour scheme fits in with my desktop
>> environment; I shall like your web-site better if it adapts itself to my
>> tastes - and letting it do so spares you the need to agonise over which
>> entirely subjective details appeal to a bigger audience.
>
>
> I totally agree with this as long as we're talking about documents - mostly
> consisting of text, to be read top to bottom (or some other direction,
> depending on locale). It gets hairy if we're talking about graphical
> applications where text only plays a minor role, and most of the visual
> elements have size constraints. It's very hard to have all those visual
> elements and their interactions scale smoothly to any dimensions or color
> schemes the user may choose. So, for those applications the designer usually
> chooses a few predefined UI styles, and tries to prevent the user from
> messing with those, as the result of that messing would only look bad and
> glitchy.
>

No offense, but that sounds very biased towards a designers standpoint.
Applications like the Winamp media player for example have shown that
user designed styles can very well benefit software that is not even
close to a document viewer.
Even if some user created style would look bad (based on opinions),
how would anyone blame the application for being customizable?

>From a technical standpoint it may not be trivial to develop a scaling
user interface, but OTOH the gained usability may be worth it (also it
saves the developers from the DPI hassle).
The topic may be as well compared to HTML, where the users can scale
the user interface and have utilities at hands that are capable of
changing the appearance of every website to their personal flavor.



-- 
Regards
Samuel


From Shawn.Rutledge at qt.io  Tue Jul 19 14:58:37 2016
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Tue, 19 Jul 2016 12:58:37 +0000
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <726314440.20160719115720@programist.ru>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<726314440.20160719115720@programist.ru>
Message-ID: <F788AEB5-8EB6-4ED5-938F-3EBED66B01D5@qt.io>


> On 19 Jul 2016, at 10:57, Prav <pr12og2 at programist.ru> wrote:
> 
> Hello, Everyone!
> 
>> The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to
>> focus on two aspects:
>>    1) Automatic scale factor configuration based on system settings.
> There so many debates about this topic and how to get real DPI for all devices correctly.
> But I personally does get this as SO important thing. And this is because people are different
> and have different preferences about reading from screen (because of eyes or just personally).
> Which brings me to understanding that it does not matter what is the DPI of screen. It matter only
> how large PERSON want program font normally be.
> So I would expect that the main intention in developing of apps should be moved toward giving
> the user possibility to scale the app.
> And you are done!

I agree that most apps should have a means of scaling.  Control-mousewheel and control+/- are common on the desktop, so maybe it ought to be universal.  So far we have browsers, image and drawing viewers and editors, text editors (like Creator’s) and terminals which have the feature, but many other applications don’t.  I got a 4K display at work, so now I want to use konsole instead of urxvt, because of this feature: I need to zoom it depending on the use case, and which screen it’s on.  (On the Mac though, I wouldn’t need it so urgently.  The window has a similar physical size as I move it from one screen to another; whereas on Linux, the non-highdpi-aware window manager will keep the same pixel dimensions as I move it across.  So it’s a much smaller window on the 4K screen, regardless whether the content inside gets scaled or not.  Is that right or wrong?  Are we waiting for window managers to catch up here?  I don’t think resizing the window is necessarily Qt’s problem, although sometimes the layout does drive the minimum window size.)  I don’t use Qt’s auto-scaling, because in general I want smaller fonts on the 4K display, but I want to be able to choose the scale, and fractional scaling works so badly now.  Widget styles seem to need some re-design to be scalable.

But there should also be a system-wide setting for font sizes, and it should be respected by default.  Unfortunately the settings like this in most OSes are kindof coarse.  With distance field rendering, font scaling can be completely continuous, but that’s only in QtQuick apps.

The most common problem with zooming will be the need to use good layout management in the application.  Apps should do that anyway, if they want any portability at all.  But there will be threshold problems: if the screen/font-size ratio doesn’t allow enough space, you want to switch from a layout which uses too much horizontal space to a completely different one that doesn't.

There are also cases when accurate calibration is important though.  Some people are actually still engaged in preparing print media, for example.  They will appreciate having 100% zoom result in the same scale as it will be on paper.  And such people should either buy monitors which have correct EDID, or know how to correct it in their OSes.

> App should remember of couse this setting to restore it back at restart

How should Qt encourage this?  So far we have QSettings, but you need to define your own setting.  And we have not made it easy to scale all fonts simultaneously, interactively.  Bindings are too cumbersome and expensive to be the universal solution.  To avoid setting the font on every individual Text item in a QtQuick app, for example, you can use QGuiApplication::setFont().  But that’s just for the default.  Maybe there should be an event of some sort when you do that at runtime, which every Text will react to, and which will then trigger the necessary layout changes.  But that would only take care of Text which uses the default font, so we need that unit support in QML (which has been discussed for years but not done yet) to be able to have a unit which represents the default font size, so that larger text could have a size 1.2x as big as the default instead of an actual point size.  Or maybe the event should be sent when you do QHighDpiScaling::setScreenFactor(), but that’s private API so far, and it’s still not clear to me which of those Qt high dpi-things are intended to affect only or mainly font sizes, and which of them demand everything to be scaled even if it will cause crappy results (scaling up pixmaps or pre-rendered widgets by non-integral ratios).  The prototype zoom-slider is in qtbase/tests/manual/highdpi, but you can see what goes wrong with that.  We need a similar test for QtQuick to see what goes wrong with dynamic scaling there.

Maybe we should have an optional feature in QQmlApplicationEngine (just set one flag or property, plus setOrganizationName and setApplicationName), or in a subclass, which makes it easy to make an application zoomable (even taking over those key and mouse shortcuts), and remember the last setting.  But maybe it’s controversial to push QSettings into even broader use… some think it’s obsolete and don’t know what to replace it with.  Some want to use JSON.  And what about touch-oriented apps?  We can’t take over the pinch-zoom gesture for the single purpose of scaling text sizes, because each app can use that gesture in its own way.  Maybe we could at least make it easy to declare a handler which makes the pinch gesture do that, if that’s what you want, and your app doesn’t have another use case for pinch.  Or, come up with another gesture for that kind of zooming.

The devil’s in the details, and we’ve had a proliferation of details over the last few years.

> PS I can give many more cases then getting right DPI does not give usability to user.
> 1. Developers or Designers are young, have good eyes are pretty conformable with small fonts.
>    They produce app with HighDPI support which correctly scales to DPI of HighDPI user device. But ... this does not mean
>    that old persons would feel comfortable with the app ... their eyes see not as good as when they were young.
> 2. Could be a reverse case ... like you want smaller because devs created app which seems larger to you.
> 3. Devs and Designers usually have good tech. I mean good monitors, modern phones with good crisp screen.
>    But user's tablet/phone can be not modern or be cheap or with tons of scratches (for example with plastic (not glass screens)).
>    Sooo ... visibility is much worse ... but DPI could be same.
> 4. You are OK with design and size of app's fonts at your notebook/tablet with like 10'', devs and designer see things the same good as you
>    and your screen is modern and good with gorilla glass or something same and DPI scale factor was determined exactly as it is.
>    But now you are inside city transport ... and guess what ...
>    you are shaken! ... and this mean you see the screen worse ... you need to increase the scale!
>    And if you sit/lay still in the bedroom you what smaller font to see more info at once.

Yes, exactly.

The same goes for switching between light and dark themes.  It should be system-wide and as effortless as possible.  When I use my laptop on my morning commute, I want a light theme, and typically a dark one on the way home, depending on the season and the weather.  Android is wrong - they enforce inconsistency and lack of choice by letting every application hard-code the theme.  Creator is wrong for making me restart it if I change the UI theme.  And everyone else is wrong for not making a handy system-wide toggle.

> I do not see much trend in Qt-discussions/apps-interfaces about user-defined scale factor. But only THIS is important to user.
> And NOT DPI ;)

We can’t say that DPI is never important though.  The consensus so far seems to be that some apps need accurate scaling, while most don’t.  Qt has to support both, and the one doesn’t prevent the other.


From Morten.Sorvig at qt.io  Tue Jul 19 15:04:46 2016
From: Morten.Sorvig at qt.io (Morten Sorvig)
Date: Tue, 19 Jul 2016 13:04:46 +0000
Subject: [Development] Revisiting high-DPI configuration options
Message-ID: <BEEFE773-42FF-4180-918F-06704B5A3CFA@qt.io>


> On 19 Jul 2016, at 10:57, Prav <pr12og2 at programist.ru> wrote:
> 
> May be Qt need to move accents from getting right DPI to making it user changeable ... FRACTIONALLY (as a good new practice)!
> Like 10-20 % steps ... not just 2,3,4,5.
> 
> I do not see much trend in Qt-discussions/apps-interfaces about user-defined scale factor. But only THIS is important to user.
> And NOT DPI ;)


I would like to separate the use cases of adapting to hardware with
different DPI and adapting to user preferences. We can support both
and they don’t have to be mutually exclusive. They may share 
implementation details.

Is user control an OS setting or an application setting? Many
windowing systems have global font preferences which Qt should respect.

If we want to re-use the existing high-DPI work we can add

	QGuiApplication::setGlobalScaleFactor(qreal factor);

Setting the factor to something other than 1 would uniformly scale all
application windows. This would interact with the current high-DPI support:
a factor of 1.5 on a 2x display gives an effective devicePixelRatio of 3,
ensuing a consistent visual UI size.

Morten


From olivier at woboq.com  Tue Jul 19 18:06:56 2016
From: olivier at woboq.com (Olivier Goffart)
Date: Tue, 19 Jul 2016 18:06:56 +0200
Subject: [Development] leak in QMetaObject?
In-Reply-To: <25dd1da6-1eac-4b18-b024-74bf3b527494@pelagicore.com>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<46fd590e-4995-7c1c-1ecd-98e7775b734d@familiesomers.nl>
	<25dd1da6-1eac-4b18-b024-74bf3b527494@pelagicore.com>
Message-ID: <21304192.mPGEk30DdD@maurice>

On Donnerstag, 14. Juli 2016 17:45:58 CEST Thomas Senyk wrote:
> On 14.07.2016 17:18, André Somers wrote:
> > Op 14/07/2016 om 17:10 schreef Olivier Goffart:
> >> On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote:
> >>> Hi,
> >>> 
> >>> I lately wanted to validate that a connecting&disconnecting to a lambda
> >>> will not leak the lambda object .. and found that more then that is
> >>> leaked.
> >>> 
> >>> Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv
> >>> 
> >>> After the 10million connections are executed and disconnected (all of
> >>> them a successful), I assume a drop in memory consumption and more
> >>> importantly a drop of cpu load to close to 0%.
> >>> 
> >>> I see neither one nor the other. I see continues 100% consume with no
> >>> memory consumption drop what so ever.
> >>> 
> >>> I did a quick peak into QMetaObject::activate and it seems no clean up
> >>> happened .. the list returned in
> >>> 
> >>>    list = &connectionLists->at(signal_index);
> >>>    (line #3660 in 5.6 checkout from today)
> >>> 
> >>> seems rather long! (10million?)
> >>> 
> >>> However all "if (!c->receiver)" shows no receiver and therefor will
> >>> continue right away .. at least
> >>> 
> >>> Is this expected? A bug? ... I'm happy to fill a bug report, I just
> >>> wanted to get some feedback, maybe I'm just doing something wrong
> >> 
> >> The lambda object and its capture is destroyed by the call to
> >> 
> >>    slotObj->destroyIfLastRef()
> >> 
> >> The internal data structre (QObjectPrivate::Connection) is deleted by
> >> QObjectPrivate::cleanConnectionLists which is actually only called when
> >> a new connection is made to this object.
> >> 
> >> I don't think there is a leak, but it is true that some memory is only
> >> free'ed
> >> when you add new connection or that the object is destroyed. (but the
> >> lambda
> >> object is destroyed right after the disconnection)
> 
> Then this:
> http://paste.ofcode.org/37rxyitynhEqi5gira88hR9
> 
> should "fix" it? .. but I still see 100% cpu and same memory consumption?

As thiago says, your thing still does not work because when you connect from a 
signal connected to the same object, the list is inUse and will not be 
cleaned.

for (int i = 1; i <= 10000000; i++) {
 // ... your code 
}
QTimer::singleShot(200, // so it's after the last disconnect
  [] { QObject::disconnect(QObject::connect(t, &QTimer::timeout, []{})); });

So the connect happens after everything was disconnected.

In practice you probably don't need to use this workaround, unless you always 
add new connection from a slot connected to a signal of the object you 
continue to connect and disconnect to. Is that what you are doing?

It is true that we could consider trying to clean the connection list after 
each signal emission if it is dirty.
We don't want to do it after each disconnect because this can turn a O(n) 
algorithm into a O(n^2)   (cleaning the list is O(n), if we have to do it for 
every disconnect, that n*O(n))


> >>> Some background:
> >>> I wanted to check if a single-shot-connection (connection to a signal
> >>> and disconnect at first execute, using a lambda as slot) would be a
> >>> feasible thing to do.
> >> 
> >> You can do that already:
> >>   QTimer::sigleShot(100, [] { qDebug() << "hello"; });
> > 
> > That's not the same thing.
> > This looks like my earlier suggestion
> > https://bugreports.qt.io/browse/QTBUG-44219
> 
> +1, this is similar but not the same,

Ah right, I got confused because you use the term "single shot" and your 
testcase was using a QTimer.

Yes that's a valid feature request. But I have no plan to spend time 
implementing this myself anytime soon.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org



From alexis.jeandet at member.fsf.org  Tue Jul 19 19:26:27 2016
From: alexis.jeandet at member.fsf.org (jeandet)
Date: Tue, 19 Jul 2016 19:26:27 +0200
Subject: [Development] Qt Charts poor dynamic/resolution with OpenGL
Message-ID: <1468949187.3072.83.camel@member.fsf.org>

Hi All,

We are developing in my lab a scientific data plot/analysis software
using Qt Charts module. In order to plot quite large data-sets
(XYSeries) we enabled OpenGL which produce unexpected behavior. The
plots values are grouped by X values see here:
https://ao.lpp.polytechnique.fr/s/T2HcZDtrdL0DcDi
passwd:àààà
-Plot0 with OpenGL
-Plot1 without OpenGL

We found that it was due to float conversion with OpenGL, as far as I
know we can't safely use doubles with OpenGL since not al GPU/drivers
support it(and it increase version requirement). So for now it really
limits plots quality since float has a 23+1 bits mantissa so +/-8M
relative dynamic.

For example data with X values representing seconds since epoch(1970)
would have to store:
(2016-1970)*365*24*60*60 = 1450656000 seconds ~2^31
This indeed doesn't fit in 23 bits, to store it in a float you will
need to truncate it and you would get something close to 3 minutes
resolution.
Here is a tool to see what append.
http://babbage.cs.qc.cuny.edu/IEEE-754.old/Decimal.html

It will also fail with  non uniform X values, packets of data with a
small dX spaced by bigger dX. For example 8kSps time series grouped in
packets of 1000 points with few minutes between each packets would
fail.

That said there seems to be solutions to make the situation better. 
I think that before plotting te data we should perform a coordinate
change to fit float dynamic.
This pipeline might be implemented like this?:

CPU:  -Data domain analysis (min, max, dynamic)
CPU:  -Produce a Temporary vector of visible data centered and reduced
CPU:  -Push Temporary vector to GPU
GPU:  -Generate Vertices with or without downsampling strategy
CPU:  -Build Axes from visible bounds in data coordinates

Note that this would also work without OpenGL and the downsampling
insanely increase performances. On QCustomPlot if we replace data
containers which are QMap by QVector you can plot more than 10M points
without problems.
Here is one example with 3M points with QCustomPlot and without OpenGL:
https://hephaistos.lpp.polytechnique.fr/data/QLop_new_Features2.webm

This would imply to store two coordinate systems for Data and View.
We are happy to discuss about that and contribute to the development if
we agree on a solution.
Anyway I would be happy to have any feedback on this.

Some readings:
http://blogs.agi.com/insight3d/index.php/2008/09/03/precisions-precisio
ns/
http://www.urbanrobots.com/Blogs/WW/2006/01/working-to-solution-in-prec
ision.html
http://www.urbanrobots.com/Blogs/WW/2006/01/solving-coordinate-precisio
n-problems.html


Best regards
Alexis Jeandet
Laboratory of Plasma Physics(LPP)
http://www.lpp.fr/?lang=en


From sean.harmer at kdab.com  Tue Jul 19 21:26:57 2016
From: sean.harmer at kdab.com (Sean Harmer)
Date: Tue, 19 Jul 2016 20:26:57 +0100
Subject: [Development] Qt Charts poor dynamic/resolution with OpenGL
In-Reply-To: <1468949187.3072.83.camel@member.fsf.org>
References: <1468949187.3072.83.camel@member.fsf.org>
Message-ID: <1be818f4-de31-f7e0-e630-f468ec15919e@kdab.com>



On 19/07/2016 18:26, jeandet wrote:
> Hi All,
>
> We are developing in my lab a scientific data plot/analysis software
> using Qt Charts module. In order to plot quite large data-sets
> (XYSeries) we enabled OpenGL which produce unexpected behavior. The
> plots values are grouped by X values see here:
> https://ao.lpp.polytechnique.fr/s/T2HcZDtrdL0DcDi
> passwd:àààà
> -Plot0 with OpenGL
> -Plot1 without OpenGL
>
> We found that it was due to float conversion with OpenGL, as far as I
> know we can't safely use doubles with OpenGL since not al GPU/drivers
> support it(and it increase version requirement). So for now it really
> limits plots quality since float has a 23+1 bits mantissa so +/-8M
> relative dynamic.
>
> For example data with X values representing seconds since epoch(1970)
> would have to store:
> (2016-1970)*365*24*60*60 = 1450656000 seconds ~2^31
> This indeed doesn't fit in 23 bits, to store it in a float you will
> need to truncate it and you would get something close to 3 minutes
> resolution.
> Here is a tool to see what append.
> http://babbage.cs.qc.cuny.edu/IEEE-754.old/Decimal.html
>
> It will also fail with  non uniform X values, packets of data with a
> small dX spaced by bigger dX. For example 8kSps time series grouped in
> packets of 1000 points with few minutes between each packets would
> fail.
>
> That said there seems to be solutions to make the situation better.
> I think that before plotting te data we should perform a coordinate
> change to fit float dynamic.
> This pipeline might be implemented like this?:
>
> CPU:  -Data domain analysis (min, max, dynamic)
> CPU:  -Produce a Temporary vector of visible data centered and reduced
> CPU:  -Push Temporary vector to GPU
> GPU:  -Generate Vertices with or without downsampling strategy
> CPU:  -Build Axes from visible bounds in data coordinates

That's essentially the same strategy I've implemented in the past. I 
don't know the code of Qt Charts or how easily this woudl fit into it 
but as an approach I think it's sound.

Cheers,

Sean

>
> Note that this would also work without OpenGL and the downsampling
> insanely increase performances. On QCustomPlot if we replace data
> containers which are QMap by QVector you can plot more than 10M points
> without problems.
> Here is one example with 3M points with QCustomPlot and without OpenGL:
> https://hephaistos.lpp.polytechnique.fr/data/QLop_new_Features2.webm
>
> This would imply to store two coordinate systems for Data and View.
> We are happy to discuss about that and contribute to the development if
> we agree on a solution.
> Anyway I would be happy to have any feedback on this.
>
> Some readings:
> http://blogs.agi.com/insight3d/index.php/2008/09/03/precisions-precisio
> ns/
> http://www.urbanrobots.com/Blogs/WW/2006/01/working-to-solution-in-prec
> ision.html
> http://www.urbanrobots.com/Blogs/WW/2006/01/solving-coordinate-precisio
> n-problems.html
>
>
> Best regards
> Alexis Jeandet
> Laboratory of Plasma Physics(LPP)
> http://www.lpp.fr/?lang=en
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts


From pr12og2 at programist.ru  Wed Jul 20 01:56:52 2016
From: pr12og2 at programist.ru (Prav)
Date: Wed, 20 Jul 2016 02:56:52 +0300
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <F788AEB5-8EB6-4ED5-938F-3EBED66B01D5@qt.io>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io> 
	<726314440.20160719115720@programist.ru>
	<F788AEB5-8EB6-4ED5-938F-3EBED66B01D5@qt.io>
Message-ID: <581570494.20160720025652@programist.ru>

Hello, Everyone!

> Or, come up with another gesture for that kind of zooming.
> The devil’s in the details, and we’ve had a proliferation of details over the last few years.
> ... and many other thoughts

I wanted to say that right DPI for screen should give only default scale factor for the app. And app should be able to change the scale
factor easy at runtime and with fractional values so that user can unjust the scale factor according to himself and his current environment.

So here I confirm that I see that "HighDPI" and "scaling factor" should be solved with the same technology. BUT ... we need screen's DPI only as a starting guess for setting the scale factor.
Later we need to let user adjust it.

I think that Qt lib should not go deeper in this by now ... like forcing some standard way to do scaling for the app. With common gesture or std shortcut.
And this is simply because we are not sure what the best way is. I think what Qt have to make app scaling as easy
as calling of one function and advertise on every corner that apps have to use this function and let user change scale factor if app wants to be considered "modern" and "good".

After that users and apps will create the best practice in this area and then Qt can implement it. Currently it is too early.


I am not sure that this "setScaleFactor" function is currently implemented.
For example here
http://blog.qt.io/blog/2016/01/26/high-dpi-support-in-qt-5-6/
I see only use of environment variable before start of the app for manual setting of scale factor.
But why I can not change it in runtime is still unclear for me.


I agree that changing of scale factor means that size of window will be changed. And what if this cannot be done more ... end of screen size ... what to do?
Well we have layouts for this. But here is the problem ... Qt layouts have not been changed/extended for so long that in current new conditions
devs would probably think that they are not happy with standard Qt layouts and would like to extend them (for example Horizontal layout
can not ever layout things vertically ... even if there is no space in horizontal direction and plenty in vertical).
But here is the problem ... we have mechanism to extend widgets (Promotion) but
this mechanism somehow is absent for layouts! Why?!
I am not sure about QML layouts problems ... probably anchors make it easier to define custom layouting in QML (but still not sure that everything is without problems in QML)
but with widgets ... I never saw news about adding or extending any widget-layout.
But this is in need after setScaleFactor will be implemented! ... because you can scroll the page vertically
but horizontal scrolling is a bad tone ... so there is need in some std layout which will use vertical direction if the layout is out of horizontal space and
there devs need possibility to extend layouts something like we have for widgets.


Another problem will be with icons. They will scale bad. We are used to make icons with versions like _x2, _x3 ... and what we going to do if scale factor
will be fractional? ... have icons versions like _1.1 _1.2 _1.3?
Probably we need to rethink why in the world we make so many copies of one icon in compile time if we can make one SVG icon which can be scaled
to any size without loss of crispness in runtime. Especially material design makes this easier because we mostly see only contours in material design icons.
So the next step for Qt can be supporting of SVG-icons as main and preferable way for setting icons. In this case icons can be scaled clearly.


I mean that this scaling-problem have to be discussed more in this terms ... in terms of support of already known technologies which by now were
not developed enough to make fractional runtime scaling easy ... but not only in terms of getting right DPI. Right DPI-factor is not close to the problem solution ... at ALL!



From sschilz at pasco.com  Wed Jul 20 01:57:11 2016
From: sschilz at pasco.com (Steve Schilz)
Date: Tue, 19 Jul 2016 23:57:11 +0000
Subject: [Development] QWebEngine - H.264 playback, proprietary  codecs.
Message-ID: <F2423333-726E-4BCA-BBC9-31CF07C452CA@pasco.com>

I have been going over the MPEG-LA writings on the web, and find no convincing argument that you can 
release a decoder for free.  You can distribute videos for free, but if you sell them, or distribute an encoder
or decoder you are apparently liable for fees if you sell > 100K units per year.

A quote from: http://www.mpegla.com/main/programs/AVC/Documents/avcweb.pdf
<quote>
       MPEG-LA online summary of terms:
       AVC/H.264 License Terms
       Codec Manufacture and Sale
						
       o Products sold to end users and OEM for PC but not part of OS  (decoder, encoder or product consisting of one decoder and one encoder = “unit”)
 	o 0 - 100,000 units/year = no royalty (available to one legal entity in an affiliated group)
	o US $0.20 per unit after first 100,000 units/year
	o Above 5 million units/year, royalty = US $0.10 per unit
	o Enterprise cap: 
       $3.5M per year 2005-2006, 
$4.25M per year 2007-08,
$5M per year 2009-10, 
$6.5Mper year 2011-2015; 
$8.125M in 2016 and 
$9.75M per year in  2017 through 2020
</quote>						  

This amounts to $20,000 us as soon as you exceed the minimum.

Also note that AAC audio codec that is normally used with H.264 is a separate, and apparently more expensive license,
Although I have not read about that as much.
  http://www.via-corp.com/licensing/aac/licensefees.html
  http://www.via-corp.com/licensing/aac/faq.html


Steve Schilz
PASCO scientific - think science

On Mon July 18, Steve Schilz Wrote:
>    Thiago, Allan, Thanks for responding.
>    
>   Probably complicated indeed!  Qt in general does a pretty great job of shielding us from lots of complexity.  
>   I need to look into the ?Free for decoding? part more carefully, as that is my immediate need.  
>  It seemed worth mentioning, and certainly imho makes QWebEngine all the more attractive if it could be made to work.
>    
>
 
    
On Weds July 16: Allan SandField Jensen Wrote:
   >>Date: Wed, 13 Jul 2016 19:21:16 +0200
   >>From: Allan Sandfeld Jensen <kde at carewolf.com<mailto:kde at carewolf.com>>>
   >>To: development at qt-project.org<mailto:development at qt-project.org>
   >>>Subject: Re: [Development] QWebEngine - H.264 playback, proprietary  codecs.
   >>
   > >That sounds a bit complicated, since it needs to hook into Chromiums media
    >>backend and have a download mechanism.
    >>
    >>Note activating it the codecs is not a matter of cost. AFAIK the h.264 and
    >>h.265 codecs are currently patented but royalty free to decode. This makes it
    >>possible for our customers to activate them without paying anyway. This is
    >>however just the status quo, and I am not sure I want to risk enabling
    >>something that might make the open-source package something that you need to
    >>pay for in the future, which is why we prefer to stick with the same codecs
    >>Google makes available in their free open source browser Chromium.
    >>
    >>I would be more interested in making it easier to enable, or maybe offer
    >>somehow. It is just something we have to make sure we offer without
    >>guaranteeing it is and will remain free.
    >>
    >>Allan
On Wednesday 13 July 2016, Steve Schilz wrote:
   
   >>>We are using QWebEngine to drive a hybrid app (Html5 + Javascript + C++) on
    >>>windows.  According to QWebEngineFeatures Doc,
    >>>http://doc.qt.io/qt-5/qtwebengine-features.html#pepper-plugin-api You must
    >>>pass a flag to qmake, WEBENGINE_CONFIG+=use_proprietary_codecs, and build
    >>>Qt from source yourself in order to support h.264 video decoding.
    >>>
    >>>In researching this, I became aware that Cisco provides a downloadable
    >>>binary codec, where Cisco pays the MPEG-LA royalties.   Apparently this is
    >>>the method used To provide h.264 playback in Firefox.  If you watch the
    >>>intellectual property rights video at
    >>>http://vimeo.com/cullenfluffyjennings/openh264-ipr, they explain why they
    >>>Did this, and how you can even make changes to the codec via open source
    >>>if needed.
    >>>
    >>>Would it make sense for QWebEngine to support this codec, in order to be
    >>>able to provide ?out of the box? (via download at end user?s computer),
    >>>support for h.264 playback in <video> tags?
    
    

    
    


From andre at familiesomers.nl  Wed Jul 20 10:01:26 2016
From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=)
Date: Wed, 20 Jul 2016 10:01:26 +0200
Subject: [Development] leak in QMetaObject?
In-Reply-To: <21304192.mPGEk30DdD@maurice>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<46fd590e-4995-7c1c-1ecd-98e7775b734d@familiesomers.nl>
	<25dd1da6-1eac-4b18-b024-74bf3b527494@pelagicore.com>
	<21304192.mPGEk30DdD@maurice>
Message-ID: <3263fecb-6d0d-d77e-215a-65664e51854f@familiesomers.nl>



Op 19/07/2016 om 18:06 schreef Olivier Goffart:
> On Donnerstag, 14. Juli 2016 17:45:58 CEST Thomas Senyk wrote:
>> On 14.07.2016 17:18, André Somers wrote:
>>> Op 14/07/2016 om 17:10 schreef Olivier Goffart:
>>>> On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote:
>>>>> Hi,
>>>>>
>>>>> I lately wanted to validate that a connecting&disconnecting to a lambda
>>>>> will not leak the lambda object .. and found that more then that is
>>>>> leaked.
>>>>>
>>>>> Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv
>>>>>
>>>>> After the 10million connections are executed and disconnected (all of
>>>>> them a successful), I assume a drop in memory consumption and more
>>>>> importantly a drop of cpu load to close to 0%.
>>>>>
>>>>> I see neither one nor the other. I see continues 100% consume with no
>>>>> memory consumption drop what so ever.
>>>>>
>>>>> I did a quick peak into QMetaObject::activate and it seems no clean up
>>>>> happened .. the list returned in
>>>>>
>>>>>     list = &connectionLists->at(signal_index);
>>>>>     (line #3660 in 5.6 checkout from today)
>>>>>
>>>>> seems rather long! (10million?)
>>>>>
>>>>> However all "if (!c->receiver)" shows no receiver and therefor will
>>>>> continue right away .. at least
>>>>>
>>>>> Is this expected? A bug? ... I'm happy to fill a bug report, I just
>>>>> wanted to get some feedback, maybe I'm just doing something wrong
>>>> The lambda object and its capture is destroyed by the call to
>>>>
>>>>     slotObj->destroyIfLastRef()
>>>>
>>>> The internal data structre (QObjectPrivate::Connection) is deleted by
>>>> QObjectPrivate::cleanConnectionLists which is actually only called when
>>>> a new connection is made to this object.
>>>>
>>>> I don't think there is a leak, but it is true that some memory is only
>>>> free'ed
>>>> when you add new connection or that the object is destroyed. (but the
>>>> lambda
>>>> object is destroyed right after the disconnection)
>> Then this:
>> http://paste.ofcode.org/37rxyitynhEqi5gira88hR9
>>
>> should "fix" it? .. but I still see 100% cpu and same memory consumption?
> As thiago says, your thing still does not work because when you connect from a
> signal connected to the same object, the list is inUse and will not be
> cleaned.
>
> for (int i = 1; i <= 10000000; i++) {
>   // ... your code
> }
> QTimer::singleShot(200, // so it's after the last disconnect
>    [] { QObject::disconnect(QObject::connect(t, &QTimer::timeout, []{})); });
>
> So the connect happens after everything was disconnected.
>
> In practice you probably don't need to use this workaround, unless you always
> add new connection from a slot connected to a signal of the object you
> continue to connect and disconnect to. Is that what you are doing?
>
> It is true that we could consider trying to clean the connection list after
> each signal emission if it is dirty.
> We don't want to do it after each disconnect because this can turn a O(n)
> algorithm into a O(n^2)   (cleaning the list is O(n), if we have to do it for
> every disconnect, that n*O(n))
>
Did anyone ever measure in practice what the distribution in values for 
n is here? My *guess* is that it won't be all that large. I expect a 
distribution with a spike at n=1 or 2, and then a dropoff with a very 
long tail, perhaps spiking at a bit larger number when using QML for all 
the propertybindings going on. Big-O notation doesn't make a lot of 
sense if the n is small, it only starts to have an impact if n grows. I 
would be suprised if the impact of the list being a single-linked list 
and thus having to skip through memory to get from node to node was not 
bigger than any "big-O" benefits you gained from doing it this way in 
the first place.

On the other hand, you'd have to consider the likelyhood of another 
connect hapening after a disconnect. If that is nearly 1, then sure, 
that may be a good time to clean up. But if it is closer to 0 in reality...

Note that if you are worried of somebody disconnecting in a loop or 
something: simply make sure to have a fast path. A disconnect 
(ptrSender, 0, ptrReceiver, 0) obviously doesn't need a cleanup after 
every individual disconnect...

André



From olivier at woboq.com  Wed Jul 20 10:41:16 2016
From: olivier at woboq.com (Olivier Goffart)
Date: Wed, 20 Jul 2016 10:41:16 +0200
Subject: [Development] leak in QMetaObject?
In-Reply-To: <3263fecb-6d0d-d77e-215a-65664e51854f@familiesomers.nl>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<21304192.mPGEk30DdD@maurice>
	<3263fecb-6d0d-d77e-215a-65664e51854f@familiesomers.nl>
Message-ID: <1849105.64iH2RfVEc@maurice>

On Mittwoch, 20. Juli 2016 10:01:26 CEST André Somers wrote:
> Op 19/07/2016 om 18:06 schreef Olivier Goffart:
> > It is true that we could consider trying to clean the connection list
> > after
> > each signal emission if it is dirty.
> > We don't want to do it after each disconnect because this can turn a O(n)
> > algorithm into a O(n^2)   (cleaning the list is O(n), if we have to do it
> > for every disconnect, that n*O(n))
> 
> Did anyone ever measure in practice what the distribution in values for
> n is here? My *guess* is that it won't be all that large. I expect a
> distribution with a spike at n=1 or 2, and then a dropoff with a very
> long tail, perhaps spiking at a bit larger number when using QML for all
> the propertybindings going on. Big-O notation doesn't make a lot of
> sense if the n is small, it only starts to have an impact if n grows. 

The distribution does not matter. If it can be big, quadradic complexity can 
be a blocker.

> I would be suprised if the impact of the list being a single-linked list
> and thus having to skip through memory to get from node to node was not
> bigger than any "big-O" benefits you gained from doing it this way in
> the first place.

Maybe changing to a vector could be indeed beneficial. Note that it's not that 
simple as the nodes are in two different linked list at the same time. And 
this is used for efficient disconnect when a reciever is destroyed.

> On the other hand, you'd have to consider the likelyhood of another
> connect hapening after a disconnect. If that is nearly 1, then sure,
> that may be a good time to clean up. But if it is closer to 0 in reality...

It would still not be a leak since the used memory is bounded to O (maximum 
amount of connection on that object at the same time)

If you do:

 forever {
   QObject::connect(&myObject, ...);
 }

you have a leak because the amount of connection grow to infinity. but that's 
your fault.

If you do:

 forever {
   QObject::connect(&myObject, ...);
   QObject::disconnect(&myObject, ...);
 }

You have no leak. Sure, there will always be one unused node in the internal 
datastructure, but it is not a leak as the memory usage does not grow. 
And that node will be also removed when the object is destroyed.


So people have been memory profiling applications, and i don't think the 
amount of connection (and especially 'dead' connection) has been a problem.


In Thomas's example, the issue was that he made 1000's of connections, then 
disconnect them all, and the internal nodes are staying. But that should not 
be a problem as this fabricated example does not exist in practice.
For example, here is an example based on his that simulate this single shot 
connection.
http://paste.ofcode.org/Gb5y5GyzCcDVFvCgQRe3V7
This will run forever, and the memory usage should not grow.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org



From andre at familiesomers.nl  Wed Jul 20 11:02:53 2016
From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=)
Date: Wed, 20 Jul 2016 11:02:53 +0200
Subject: [Development] leak in QMetaObject?
In-Reply-To: <1849105.64iH2RfVEc@maurice>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<21304192.mPGEk30DdD@maurice>
	<3263fecb-6d0d-d77e-215a-65664e51854f@familiesomers.nl>
	<1849105.64iH2RfVEc@maurice>
Message-ID: <64185c6a-120a-37e9-defc-b3615ba33ca6@familiesomers.nl>



Op 20/07/2016 om 10:41 schreef Olivier Goffart:
> On Mittwoch, 20. Juli 2016 10:01:26 CEST André Somers wrote:
>> Op 19/07/2016 om 18:06 schreef Olivier Goffart:
>>> It is true that we could consider trying to clean the connection list
>>> after
>>> each signal emission if it is dirty.
>>> We don't want to do it after each disconnect because this can turn a O(n)
>>> algorithm into a O(n^2)   (cleaning the list is O(n), if we have to do it
>>> for every disconnect, that n*O(n))
>> Did anyone ever measure in practice what the distribution in values for
>> n is here? My *guess* is that it won't be all that large. I expect a
>> distribution with a spike at n=1 or 2, and then a dropoff with a very
>> long tail, perhaps spiking at a bit larger number when using QML for all
>> the propertybindings going on. Big-O notation doesn't make a lot of
>> sense if the n is small, it only starts to have an impact if n grows.
> The distribution does not matter. If it can be big, quadradic complexity can
> be a blocker.
Nonsense. There is no need to pessimize the frequent cases to cater for 
avoiding a performance issue in an exceptional case. The test case 
presented is clearly not a normal usage pattern. Of course, if you can 
optimize the algorithmic complexity for the exceptional cases without 
affecting the performance for the cases where n is small, then by all 
means do just that. I also don't think it is up to Qt to try to mitigate 
wrong usage patterns like disconnecting many slots from a single signal 
in a loop.
>
>> I would be suprised if the impact of the list being a single-linked list
>> and thus having to skip through memory to get from node to node was not
>> bigger than any "big-O" benefits you gained from doing it this way in
>> the first place.
> Maybe changing to a vector could be indeed beneficial. Note that it's not that
> simple as the nodes are in two different linked list at the same time. And
> this is used for efficient disconnect when a reciever is destroyed.
You know much more about this than I do of course, and perhaps a linked 
list _is_ the best data structure for this case.
>
>> On the other hand, you'd have to consider the likelyhood of another
>> connect hapening after a disconnect. If that is nearly 1, then sure,
>> that may be a good time to clean up. But if it is closer to 0 in reality...
> It would still not be a leak since the used memory is bounded to O (maximum
> amount of connection on that object at the same time)
No, it would not be a leak. I did not claim it was. It would still be 
wasted memory though that is kept for (way) longer than needed.

André



From edward.welbourne at qt.io  Wed Jul 20 11:12:53 2016
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Wed, 20 Jul 2016 09:12:53 +0000
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <581570494.20160720025652@programist.ru>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<726314440.20160719115720@programist.ru>
	<F788AEB5-8EB6-4ED5-938F-3EBED66B01D5@qt.io>,
	<581570494.20160720025652@programist.ru>
Message-ID: <AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>

Prav said:
> Another problem will be with icons. They will scale bad. We are used
> to make icons with versions like _x2, _x3 ... and what we going to do
> if scale factor will be fractional? ... have icons versions like _1.1
> _1.2 _1.3?  Probably we need to rethink why in the world we make so
> many copies of one icon in compile time if we can make one SVG icon
> which can be scaled to any size without loss of crispness in
> runtime. Especially material design makes this easier because we
> mostly see only contours in material design icons.  So the next step
> for Qt can be supporting of SVG-icons as main and preferable way for
> setting icons. In this case icons can be scaled clearly.

I am baffled that anyone does the _x2, etc., approach to icons any more,
when most icons are indeed well-suited to SVG - in most cases, a tiny
SVG, smaller (in file-size) than any one of the many icons it makes
redundant, can do an excellent job of presenting the clear visual that
the icon is supposed to provide.  Making many larger files seems to
serve no purpose - other than letting web-or-UI designers bill their
clients for large amounts of pointless make-work.

Then again, our SVG support is embarrassingly poor,

        Eddy.


From michael.zanetti at canonical.com  Wed Jul 20 11:23:06 2016
From: michael.zanetti at canonical.com (Michael Zanetti)
Date: Wed, 20 Jul 2016 11:23:06 +0200
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<726314440.20160719115720@programist.ru>
	<F788AEB5-8EB6-4ED5-938F-3EBED66B01D5@qt.io>
	<581570494.20160720025652@programist.ru>
	<AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>
Message-ID: <578F42FA.9090606@canonical.com>



On 20.07.2016 11:12, Edward Welbourne wrote:
> Prav said:
>> Another problem will be with icons. They will scale bad. We are used
>> to make icons with versions like _x2, _x3 ... and what we going to do
>> if scale factor will be fractional? ... have icons versions like _1.1
>> _1.2 _1.3?  Probably we need to rethink why in the world we make so
>> many copies of one icon in compile time if we can make one SVG icon
>> which can be scaled to any size without loss of crispness in
>> runtime. Especially material design makes this easier because we
>> mostly see only contours in material design icons.  So the next step
>> for Qt can be supporting of SVG-icons as main and preferable way for
>> setting icons. In this case icons can be scaled clearly.
> 
> I am baffled that anyone does the _x2, etc., approach to icons any more,
> when most icons are indeed well-suited to SVG - in most cases, a tiny
> SVG, smaller (in file-size) than any one of the many icons it makes
> redundant, can do an excellent job of presenting the clear visual that
> the icon is supposed to provide.  Making many larger files seems to
> serve no purpose - other than letting web-or-UI designers bill their
> clients for large amounts of pointless make-work.

Well, in smaller icons you can have less details than in bigger icons,
so having multiple icons does make sense. Also rendering svg icons is
slower than bitmaps so in some cases that won't work out either.

What we do in ubuntu is to find the closes available icon that's larger
than the current ui scale and then scale it down. In case no larger one
is available we fall back to the closest available smaller one and scale
it up. And as I said before, we also use icon_x2.svg and icon_x3.svg for
different levels of details in the image.


> 
> Then again, our SVG support is embarrassingly poor,
> 
>         Eddy.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160720/a702ddb0/attachment.sig>

From edward.welbourne at qt.io  Wed Jul 20 11:39:00 2016
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Wed, 20 Jul 2016 09:39:00 +0000
Subject: [Development] leak in QMetaObject?
In-Reply-To: <64185c6a-120a-37e9-defc-b3615ba33ca6@familiesomers.nl>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<21304192.mPGEk30DdD@maurice>
	<3263fecb-6d0d-d77e-215a-65664e51854f@familiesomers.nl>
	<1849105.64iH2RfVEc@maurice>,
	<64185c6a-120a-37e9-defc-b3615ba33ca6@familiesomers.nl>
Message-ID: <AM2PR02MB075489CF38A10878E102979787080@AM2PR02MB0754.eurprd02.prod.outlook.com>

Op 20/07/2016 om 10:41 schreef Olivier Goffart:
>> The distribution does not matter. If it can be big, quadradic
>> complexity can be a blocker.

André Somers replied
> Nonsense. There is no need to pessimize the frequent cases to cater
> for avoiding a performance issue in an exceptional case.

Well, it depends ...

You've got some function, F, from number of connections to cost of any
given way of handling connections.  You've got some distribution P over
values n takes.  Your total cost is the sum of P(n).F(n) over that range
of values.  The big-O discussion is usually about how F varies; but what
actually matters is the sum of P(n).F(n).

If your distribution has a long tail (so sum(P(n); n > N) dies off
slowly as N grows) and F(n) grows fast, it is quite easy for
sum(P(n).F(n)) to be dominated by its contributions from large n, even
if they are rare, as long as there are enough of them to - when scaled
by their relatively huge F(n) - add up.

The frequency distribution P effectively acts like the constant of
proportionality that your big-O notation ignores; if that constant is
large for an O(n) algorithm but small for an O(n^2) algorithm, n has to
be large compared to the ratio between those two constants of
proportionality before O(n^2) is worse than O(n).  If one in a thousand
of your population has n ~ 1k then an O(n^2) algorithm has those costing
as much as all the (vastly more common) cases with n ~ 1.

So optimising for the rare case (which may indeed make the common case
more expensive) can indeed be worth it, because the rare case can end up
making a disproportionate contribution to your total costs.  You have to
know your distribution before you make up your mind about this - and
dumb statistics like mean and median are no substitute for the actual
distribution, for all that they're better than no data.  Long tails matter.

	Eddy.


From andre at familiesomers.nl  Wed Jul 20 11:55:20 2016
From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=)
Date: Wed, 20 Jul 2016 11:55:20 +0200
Subject: [Development] leak in QMetaObject?
In-Reply-To: <AM2PR02MB075489CF38A10878E102979787080@AM2PR02MB0754.eurprd02.prod.outlook.com>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<21304192.mPGEk30DdD@maurice>
	<3263fecb-6d0d-d77e-215a-65664e51854f@familiesomers.nl>
	<1849105.64iH2RfVEc@maurice>
	<64185c6a-120a-37e9-defc-b3615ba33ca6@familiesomers.nl>
	<AM2PR02MB075489CF38A10878E102979787080@AM2PR02MB0754.eurprd02.prod.outlook.com>
Message-ID: <9aec61a2-7161-a1bd-107a-0ebdefd3a028@familiesomers.nl>



Op 20/07/2016 om 11:39 schreef Edward Welbourne:
> Op 20/07/2016 om 10:41 schreef Olivier Goffart:
>>> The distribution does not matter. If it can be big, quadradic
>>> complexity can be a blocker.
> André Somers replied
>> Nonsense. There is no need to pessimize the frequent cases to cater
>> for avoiding a performance issue in an exceptional case.
> Well, it depends ...
>
> You've got some function, F, from number of connections to cost of any
> given way of handling connections.  You've got some distribution P over
> values n takes.  Your total cost is the sum of P(n).F(n) over that range
> of values.  The big-O discussion is usually about how F varies; but what
> actually matters is the sum of P(n).F(n). [...]
Yes, you are right of course.

But then again, it is easier to optimize the rare-but-expensive case in 
the application code than doing something about a frequent action that 
is slower than it could be. To stick to the concrete issue here: 
disconnecting a long list of connections using a loop is not very 
efficient if you do that one-by-one, Olivier pointed out you turn a O(N) 
into an O(N^2) if you then also do the clean-up. So you optize that to 
make sure that you can disconnect *all* connections for a given signal 
or slot instead, even if that means using an intermediary object or 
signal. If analysis shows that this case is slow, you spend a bit of 
time to optimize _that_ case. You cannot do the same for the many 
individual cases where there is maximum a handful of connections to any 
given signal or slot.

But: this reasoning is as much dependent on actual data on what the 
distribution of n is as the orignal statement that it does make sense. 
Hence my question on the availability of such data...

André



From pr12og2 at programist.ru  Wed Jul 20 12:03:03 2016
From: pr12og2 at programist.ru (Prav)
Date: Wed, 20 Jul 2016 13:03:03 +0300
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io> 
	<726314440.20160719115720@programist.ru>
	<F788AEB5-8EB6-4ED5-938F-3EBED66B01D5@qt.io>,
	<581570494.20160720025652@programist.ru>
	<AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>
Message-ID: <313158393.20160720130303@programist.ru>

Heello, Everyone!

> Then again, our SVG support is embarrassingly poor,
Exactly!
For example if you set SVG icon for button and then scale the app with something like QT_SCALE_FACTOR=2 before running the app ... icon will be bluered like this is not SVG!
With QT_SCALE_FACTOR=1 icon looks fine.
But fonts looks sharp for both QT_SCALE_FACTOR=1 and =2. Strange?
(Qt 5.6.1, Windows).

SVG icons are not shown at all in static builds of Qt, but png icons are fine (both icons are taken from resorse file). Static and shred Qt 5.6.1 build were done with same config settings except of cause "static".
Strange too.
(Qt 5.6.1, Windows).



From edward.welbourne at qt.io  Wed Jul 20 12:47:48 2016
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Wed, 20 Jul 2016 10:47:48 +0000
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <578F42FA.9090606@canonical.com>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<726314440.20160719115720@programist.ru>
	<F788AEB5-8EB6-4ED5-938F-3EBED66B01D5@qt.io>
	<581570494.20160720025652@programist.ru>
	<AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>,
	<578F42FA.9090606@canonical.com>
Message-ID: <AM2PR02MB0754A031C82E6E703F1773E087080@AM2PR02MB0754.eurprd02.prod.outlook.com>

Michael Zanetti

> Well, in smaller icons you can have less details than in bigger icons,
> so having multiple icons does make sense.

That's fair enough - but the thing that makes sense is having more and
less detailed icons, not bigger and smaller ones.  Of course, you'll
want to use the more detailed one for bigger uses and the less detailed
for smaller uses, but each should cover a wide range of sizes cleanly.

> Also rendering svg icons is
> slower than bitmaps so in some cases that won't work out either.

That means the SVG renderer isn't good enough.  I really wish we could
get hold of the team that implemented Opera's SVG engine in Presto - now
discarded in favour of Chrome - to do the job well: they wrote a good
engine that worked fast.

        Eddy.


From edward.welbourne at qt.io  Wed Jul 20 12:54:11 2016
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Wed, 20 Jul 2016 10:54:11 +0000
Subject: [Development] leak in QMetaObject?
In-Reply-To: <9aec61a2-7161-a1bd-107a-0ebdefd3a028@familiesomers.nl>
References: <4585649b-444b-36b3-2a44-20ecedf5aa37@pelagicore.com>
	<21304192.mPGEk30DdD@maurice>
	<3263fecb-6d0d-d77e-215a-65664e51854f@familiesomers.nl>
	<1849105.64iH2RfVEc@maurice>
	<64185c6a-120a-37e9-defc-b3615ba33ca6@familiesomers.nl>
	<AM2PR02MB075489CF38A10878E102979787080@AM2PR02MB0754.eurprd02.prod.outlook.com>,
	<9aec61a2-7161-a1bd-107a-0ebdefd3a028@familiesomers.nl>
Message-ID: <AM2PR02MB075468A46692213B9EE1055B87080@AM2PR02MB0754.eurprd02.prod.outlook.com>

André Somers said:

> But then again, it is easier to optimize the rare-but-expensive case
> in the application code than doing something about a frequent action
> that is slower than it could be.

Indeed - when possible, this can give you the best of both worlds.
A judicious API addition to do a job in bulk can often be a big win.

> But: this reasoning is as much dependent on actual data on what the
> distribution of n is as the orignal statement that it does make sense.
> Hence my question on the availability of such data...

and with that I agree entirely :-)

	Eddy.


From Kai.Koehne at qt.io  Wed Jul 20 13:13:39 2016
From: Kai.Koehne at qt.io (Kai Koehne)
Date: Wed, 20 Jul 2016 11:13:39 +0000
Subject: [Development] Documenting 3rd party code Qt
Message-ID: <AM4PR0201MB21310C0672F7ECDC5C36D0BD98080@AM4PR0201MB2131.eurprd02.prod.outlook.com>

Hi,

A while ago I proposed to generate 3rd party code attributions out of files that are right beside the code, instead of hand-editing 3rdparty.html in qtdoc. I've now a set of patches that are IMO worth to take a look at (also because FF for 5.8 is coming ;)

# Information Flow

Every 3rd party code in our repositories should get a 'qt_attribution.json' file containing metadata about the code. When the documentation of a module is built, a new tool 'licensescanner' is automatically run by qmake that scans the sources for qt_attribution.json files, and generates a .qdoc file with pages for every attribution it finds. An overview of the attributions is shown on each modules entry page. Finally, the current 3rdparty overview page should be automatically generated from all modules' attribution pages.

# File Format

I had a look at SPDX, README.Chromium, debian/copyright (btw thanks for the pointer!). In the end I went for a custom format, because they all seem to not quite fit for our use case. Anyhow, it's easy to extend licensescanner to generate other formats, too.

The current format is documented in  https://wiki.qt.io/Qt_attribution.json .

Real-life examples for qtbase can be found in https://codereview.qt-project.org/#/c/160970/ .

# QDoc Extension

To be able to document and structure the 3rd party content I introduced a new 'attribution' attribute to qdoc's \page command, and added \generatelist{attributions}, \generatelist{annotatedattributions} commands.

# Patches

qttools patches (licensescanner, qdoc modifications): https://codereview.qt-project.org/#/q/status:open+project:qt/qttools+branch:dev+topic:3rdparty,n,z
qtbase patches (qt_attributions.json files, build integration, overview pages): https://codereview.qt-project.org/#/q/status:open+project:qt/qtbase+branch:dev+topic:3rdparty,n,z
qtdoc patch (for general overview page): https://codereview.qt-project.org/#/q/status:open+project:qt/qtdoc+branch:dev+topic:3rdparty,n,z

# FAQ

Q: Why do we need such an elaborate setup? Wouldn't it be easier to just write .qdoc files?

Keeping the 'documentation' close to the actual sources hopefully makes sure they're up to date and complete. Admittedly we could also just have .qdoc files right beside each code snipped, and include this one. In the future I'd like to extend the tool though so that attribution information (say HTML) for an app bundling Qt can be generated. The qt_attribution.json file could also be used as input to 3rd party code scanners popular in the industry, or used as a source for generating SPDX files ... Keeping the metadata outside of .qdoc makes this a lot easier.

Q: What about 3rd party code in tests/examples ...?

I think they should get a qt_attribution.json file too. We have to mark though what actually ends up in the Qt libs, and what only ends up in tests / build system / host tools ... I'm still contemplating how to best document this in the qt_attribution.json file.

Regards

Kai

-- 
Kai Köhne, Senior Manager R&D | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

From olivier at woboq.com  Wed Jul 20 13:50:49 2016
From: olivier at woboq.com (Olivier Goffart)
Date: Wed, 20 Jul 2016 13:50:49 +0200
Subject: [Development] Why is QVariant::data() \internal?
In-Reply-To: <1837442.4ddaBHsu6c@zaphod>
References: <2363391.iQtkevNy5N@zaphod> <2237761.AXeKDNI8Ok@42>
	<1837442.4ddaBHsu6c@zaphod>
Message-ID: <2220871.eUmBLObRF3@maurice>

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


-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org



From Morten.Sorvig at qt.io  Wed Jul 20 13:54:08 2016
From: Morten.Sorvig at qt.io (Morten Sorvig)
Date: Wed, 20 Jul 2016 11:54:08 +0000
Subject: [Development] Revisiting high-DPI configuration options
Message-ID: <832583CF-7CA7-4553-9103-8220BD4BE00F@qt.io>


> On 20 Jul 2016, at 12:47, Edward Welbourne <edward.welbourne at qt.io> wrote:
> 
> Michael Zanetti
> 
>> Well, in smaller icons you can have less details than in bigger icons,
>> so having multiple icons does make sense.
> 
> That's fair enough - but the thing that makes sense is having more and
> less detailed icons, not bigger and smaller ones.  Of course, you'll
> want to use the more detailed one for bigger uses and the less detailed
> for smaller uses, but each should cover a wide range of sizes cleanly.
> 

I’d like us to support both, were an icon/image with more pixels can be
designated as either “larger” (more content) or “higher resolution”
(more detail).

Morten


From Morten.Sorvig at qt.io  Wed Jul 20 14:23:57 2016
From: Morten.Sorvig at qt.io (Morten Sorvig)
Date: Wed, 20 Jul 2016 12:23:57 +0000
Subject: [Development] Revisiting high-DPI configuration options
Message-ID: <E9B424BC-B4DB-464A-A025-8000DE57AFBD@qt.io>


> On 19 Jul 2016, at 14:58, Shawn Rutledge <Shawn.Rutledge at qt.io> wrote:
> 
> 
> I agree that most apps should have a means of scaling.  Control-mousewheel and control+/- are common on the desktop, so maybe it ought to be universal.  So far we have browsers, image and drawing viewers and editors, text editors (like Creator’s) and terminals which have the feature, but many other applications don’t.  

This would be a "document scaling” feature. Notice that the application UI
does not scale when using and control+/-. So this is orthogonal to the
current high-DPI support and can’t reuse that implementation.


> I got a 4K display at work, so now I want to use konsole instead of urxvt, because of this feature: I need to zoom it depending on the use case, and which screen it’s on.  (On the Mac though, I wouldn’t need it so urgently.  The window has a similar physical size as I move it from one screen to another; whereas on Linux, the non-highdpi-aware window manager will keep the same pixel dimensions as I move it across.  So it’s a much smaller window on the 4K screen, regardless whether the content inside gets scaled or not.  Is that right or wrong?  Are we waiting for window managers to catch up here?  I don’t think resizing the window is necessarily Qt’s problem, although sometimes the layout does drive the minimum window size.)  

Yes, we are waiting :) Display pixel density is a rendering detail and should
not affect layouts or window sizes. Some windowing systems are not there yet
and in those cases we may be in the business of resising on screen change.


> I want smaller fonts on the 4K display, but I want to be able to choose the scale, and fractional scaling works so badly now.  Widget styles seem to need some re-design to be scalable.

You may be in a minority here. I think the most common case is similarly
sized fonts (visually) on different displays. 

> 
> There are also cases when accurate calibration is important though.  Some people are actually still engaged in preparing print media, for example.  They will appreciate having 100% zoom result in the same scale as it will be on paper.  And such people should either buy monitors which have correct EDID, or know how to correct it in their OSes.


This is also in the “document” domain. It’s OK if the application UI is not exactly physically calibrated.

Morten


From edward.welbourne at qt.io  Wed Jul 20 14:52:43 2016
From: edward.welbourne at qt.io (Edward Welbourne)
Date: Wed, 20 Jul 2016 12:52:43 +0000
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <832583CF-7CA7-4553-9103-8220BD4BE00F@qt.io>
References: <832583CF-7CA7-4553-9103-8220BD4BE00F@qt.io>
Message-ID: <AM2PR02MB0754EA98F838F539B176CD5987080@AM2PR02MB0754.eurprd02.prod.outlook.com>

Morten Sorvig said:
> I’d like us to support both, were an icon/image with more pixels can
> be designated as either “larger” (more content) or “higher resolution”
> (more detail).

which is why SVG has to be the way to go - so you just specify the
different levels of detail and let size be a display-time choice - else
you'll end up with a quadratic explosion of different images,
parameterised by detail-ness and by size.

	Eddy.


From Morten.Sorvig at qt.io  Wed Jul 20 15:10:44 2016
From: Morten.Sorvig at qt.io (Morten Sorvig)
Date: Wed, 20 Jul 2016 13:10:44 +0000
Subject: [Development] Revisiting high-DPI configuration options
Message-ID: <928F79D3-BC63-4989-9E3F-1D9D906CCAE2@qt.io>


> On 20 Jul 2016, at 14:52, Edward Welbourne <edward.welbourne at qt.io> wrote:
> 
> Morten Sorvig said:
>> I’d like us to support both, were an icon/image with more pixels can
>> be designated as either “larger” (more content) or “higher resolution”
>> (more detail).
> 
> which is why SVG has to be the way to go - so you just specify the
> different levels of detail and let size be a display-time choice - else
> you'll end up with a quadratic explosion of different images,
> parameterised by detail-ness and by size.

Yes, as an application developer I will seriously consider using SVGs only. As
library developers we should support both approaches.

Morten




From Morten.Sorvig at qt.io  Wed Jul 20 15:13:08 2016
From: Morten.Sorvig at qt.io (Morten Sorvig)
Date: Wed, 20 Jul 2016 13:13:08 +0000
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <51dac7d0-ba1a-beed-6cc2-171d96dc6f12@familiesomers.nl>
References: <E9B424BC-B4DB-464A-A025-8000DE57AFBD@qt.io>
	<51dac7d0-ba1a-beed-6cc2-171d96dc6f12@familiesomers.nl>
Message-ID: <567B31B7-FBFF-4FF3-AFCA-CCB3E5100E01@qt.io>


> On 20 Jul 2016, at 14:51, André Somers <andre at familiesomers.nl> wrote:
> 
> 
> 
> Op 20/07/2016 om 14:23 schreef Morten Sorvig:
>>> On 19 Jul 2016, at 14:58, Shawn Rutledge <Shawn.Rutledge at qt.io> wrote:
>>> 
>>> 
>>> I agree that most apps should have a means of scaling.  Control-mousewheel and control+/- are common on the desktop, so maybe it ought to be universal.  So far we have browsers, image and drawing viewers and editors, text editors (like Creator’s) and terminals which have the feature, but many other applications don’t.
>> This would be a "document scaling” feature. Notice that the application UI
>> does not scale when using and control+/-. So this is orthogonal to the
>> current high-DPI support and can’t reuse that implementation.
>> 
>> 
> Not really. In the browser, the web content often is the real application the user interacts with.
> 

I think this is a special case that does not invalidate the general point. The
browser UI still does not scale. But I agree, if you have application UI elements
in your document those should scale too.

Morten

From bahadir.can at outlook.com  Wed Jul 20 15:41:49 2016
From: bahadir.can at outlook.com (=?iso-8859-9?Q?Bahad=FDr_Can?=)
Date: Wed, 20 Jul 2016 13:41:49 +0000
Subject: [Development] Boot to Qt Device problem.
Message-ID: <VI1PR07MB11655CA085F589E79A4CECC6EB080@VI1PR07MB1165.eurprd07.prod.outlook.com>

Hello Qt Developers Team,


I am currently working on a Sabre Automative Board with i.MX6Quad. I just started to use Qt Embedded .


I am following this guide :


http://doc.qt.io/QtForDeviceCreation/qtee-preparing-hardware-imx6sabresd.html


I insterted a clean SD card to my device and run the flash boot to Qt Device. (with the option Sabre SD i.MX6Quad)


After installation of image finished. I inserted SD card  to Board and restarted the board but nothing happened. (Terminal and screen didn't work.)


I also tried it with a beaglebone black but got nothing on it too.


Am I missing any steps?


Thanks from now.


Bahadır

Preparing SABRE SD i.MX6Quad | Qt 5.7 for Device Creation<http://doc.qt.io/QtForDeviceCreation/qtee-preparing-hardware-imx6sabresd.html>
doc.qt.io
Take the following steps to prepare Freescale SABRE SD i.MX6Quad for Boot to Qt: Note: It is important that you repeat the steps in this section after you update Qt ...



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160720/777371e1/attachment.html>

From dominik.holland at pelagicore.com  Wed Jul 20 15:44:49 2016
From: dominik.holland at pelagicore.com (Dominik Holland)
Date: Wed, 20 Jul 2016 15:44:49 +0200
Subject: [Development] Boot to Qt Device problem.
In-Reply-To: <VI1PR07MB11655CA085F589E79A4CECC6EB080@VI1PR07MB1165.eurprd07.prod.outlook.com>
References: <VI1PR07MB11655CA085F589E79A4CECC6EB080@VI1PR07MB1165.eurprd07.prod.outlook.com>
Message-ID: <c11160ee-5b07-92d1-54ec-4af7b93ce502@pelagicore.com>

Hi,

Am 07/20/2016 um 03:41 PM schrieb Bahadır Can:
> Hello Qt Developers Team,
> 
> 
> I am currently working on a Sabre Automative Board with i.MX6Quad. I
> just started to use Qt Embedded . 
> 
> 
> I am following this guide :
> 
> 
> http://doc.qt.io/QtForDeviceCreation/qtee-preparing-hardware-imx6sabresd.html
> 
> 
> I insterted a clean SD card to my device and run the flash boot to Qt
> Device. (with the option Sabre SD i.MX6Quad)
> 
> 
> After installation of image finished. I inserted SD card  to Board and
> restarted the board but nothing happened. (Terminal and screen didn't work.)

That could be related to an too old uboot version. It's probably a good
idea to update the uboot on the board using the instructions here:

http://doc.qt.io/QtForDeviceCreation/qtee-preparing-hardware-imx6.html

Dominik

> 
> 
> I also tried it with a beaglebone black but got nothing on it too. 
> 
> 
> Am I missing any steps?
> 
> 
> Thanks from now.
> 
> 
> Bahadır
> 
> Preparing SABRE SD i.MX6Quad | Qt 5.7 for Device Creation
> <http://doc.qt.io/QtForDeviceCreation/qtee-preparing-hardware-imx6sabresd.html>
> doc.qt.io
> Take the following steps to prepare Freescale SABRE SD i.MX6Quad for
> Boot to Qt: Note: It is important that you repeat the steps in this
> section after you update Qt ...
> 
> 
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 

-- 
Dominik Holland
SENIOR SOFTWARE ENGINEER

Pelagicore AG
Balanstr. 55, 81541 Munich, Germany
+49 (0)171 760 25 96
dominik.holland at pelagicore.com
www.pelagicore.com



From perezmeyer at gmail.com  Wed Jul 20 16:03:54 2016
From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer)
Date: Wed, 20 Jul 2016 11:03:54 -0300
Subject: [Development] Documenting 3rd party code Qt
In-Reply-To: <AM4PR0201MB21310C0672F7ECDC5C36D0BD98080@AM4PR0201MB2131.eurprd02.prod.outlook.com>
References: <AM4PR0201MB21310C0672F7ECDC5C36D0BD98080@AM4PR0201MB2131.eurprd02.prod.outlook.com>
Message-ID: <2028289.dGVgjQelNG@luna>

On miércoles, 20 de julio de 2016 11:13:39 A. M. ART Kai Koehne wrote:
> Hi,
[snip]
> # File Format
> 
> I had a look at SPDX, README.Chromium, debian/copyright (btw thanks for the
> pointer!).

My pleasure :)

> In the end I went for a custom format, because they all seem to
> not quite fit for our use case. Anyhow, it's easy to extend licensescanner
> to generate other formats, too.

 That might be helpful, although the current format lacks, for example, per-
entity copyright (yes, each contributor name).

I *know* this is a big burden because I have to do it :) But if this can be 
added, even if optional, we the ones who need this info can fill these details 
on each of our reviews.

Would that be a good compromise for you?

-- 
Si vives cada día de tu vida como si fuera el último,
algún día realmente tendrás razón.
  Steve Jobs

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160720/7914bb59/attachment.sig>

From Kai.Koehne at qt.io  Wed Jul 20 17:14:02 2016
From: Kai.Koehne at qt.io (Kai Koehne)
Date: Wed, 20 Jul 2016 15:14:02 +0000
Subject: [Development] Documenting 3rd party code Qt
In-Reply-To: <2028289.dGVgjQelNG@luna>
References: <AM4PR0201MB21310C0672F7ECDC5C36D0BD98080@AM4PR0201MB2131.eurprd02.prod.outlook.com>
	<2028289.dGVgjQelNG@luna>
Message-ID: <DB6PR0201MB2135B49E8AF20790B09DA5F398080@DB6PR0201MB2135.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-bounces+kai.koehne=qt.io at qt-
> project.org] On Behalf Of Lisandro Damián Nicanor Pérez Meyer
> Sent: Wednesday, July 20, 2016 4:04 PM
> To: development at qt-project.org
> Subject: Re: [Development] Documenting 3rd party code Qt
> 
> On miércoles, 20 de julio de 2016 11:13:39 A. M. ART Kai Koehne wrote:
> > Hi,
> [snip]
> > # File Format
> >
> > I had a look at SPDX, README.Chromium, debian/copyright (btw thanks
> > for the pointer!).
> 
> My pleasure :)
> 
> > In the end I went for a custom format, because they all seem to not
> > quite fit for our use case. Anyhow, it's easy to extend licensescanner
> > to generate other formats, too.
> 
>  That might be helpful, although the current format lacks, for example, per-
> entity copyright (yes, each contributor name).
>
> I *know* this is a big burden because I have to do it :) But if this can be
> added, even if optional, we the ones who need this info can fill these details
> on each of our reviews.

It can easily get laborious, but I don't see why we shouldn't allow something like

"CopyrightFiles" : [
   { "*": "Copyright (c) 1920 Joe Doe", },
   { "special_file": "Copyright (c) 2040 Jane Roe" }
]

in the format, sure. 

I'm genuinely curious though why debian/copyright needs this on a file level.  Do you know the reasons?

Regards

Kai


From Kai.Koehne at qt.io  Wed Jul 20 17:27:09 2016
From: Kai.Koehne at qt.io (Kai Koehne)
Date: Wed, 20 Jul 2016 15:27:09 +0000
Subject: [Development] Documenting 3rd party code Qt
In-Reply-To: <DB6PR0201MB2135B49E8AF20790B09DA5F398080@DB6PR0201MB2135.eurprd02.prod.outlook.com>
References: <AM4PR0201MB21310C0672F7ECDC5C36D0BD98080@AM4PR0201MB2131.eurprd02.prod.outlook.com>
	<2028289.dGVgjQelNG@luna>
	<DB6PR0201MB2135B49E8AF20790B09DA5F398080@DB6PR0201MB2135.eurprd02.prod.outlook.com>
Message-ID: <DB6PR0201MB213541849C7081863A05F89F98080@DB6PR0201MB2135.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-bounces+kai.koehne=qt.io at qt-
> [...]
> >  That might be helpful, although the current format lacks, for
> > example, per- entity copyright (yes, each contributor name).
> [...]
> I'm genuinely curious though why debian/copyright needs this on a file level.
> Do you know the reasons?

Actually re-reading " Example files paragraphs" from https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ :

> Files: *
> Copyright: 1975-2010 Ulla Upstream
> License: GPL-2+
>
> Files: debian/*
> Copyright: 2010 Daniela Debianizer
> License: GPL-2+
>
> Files: debian/patches/fancy-feature
> Copyright: 2010 Daniela Debianizer
> License: GPL-3+
> 
> Files: */*.1
> Copyright: 2010 Manuela Manpager
> License: GPL-2+
>
> [...]
> Since the license of the manual pages is the same as the other files in the package, the last paragraph above could instead be combined with the first paragraph, listing both copyright 
> statements in one Copyright field. Whether to combine paragraphs with the same license is left to the discretion of the author of the debian/copyright file.

If I got this right it says you can combine copyright lines from multiple files if the license is the same. So far we don't actually support differently licensed files in one json object (that's why e.g. https://codereview.qt-project.org/#/c/160970/11/src/3rdparty/angle/qt_attribution.json is split up in multiple objects). Hence I'm questioning whether we really need to support separating Copyright's per file.

Kai

From thiago.macieira at intel.com  Wed Jul 20 18:41:47 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 20 Jul 2016 09:41:47 -0700
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<581570494.20160720025652@programist.ru>
	<AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>
Message-ID: <2523329.S8XnEsz8Oz@tjmaciei-mobl1>

On quarta-feira, 20 de julho de 2016 09:12:53 PDT Edward Welbourne wrote:
> I am baffled that anyone does the _x2, etc., approach to icons any more,
> when most icons are indeed well-suited to SVG - in most cases, a tiny
> SVG, smaller (in file-size) than any one of the many icons it makes
> redundant, can do an excellent job of presenting the clear visual that
> the icon is supposed to provide.  Making many larger files seems to
> serve no purpose - other than letting web-or-UI designers bill their
> clients for large amounts of pointless make-work.
> 
> Then again, our SVG support is embarrassingly poor,

That's one reason, but there are two more equally, if not more important:

1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy 
applications suffer if they use it.

2) SVG icons designed for higher resolution, with a lot of details, look 
complex and polluted in lower resolutions. From past experience, icon artists 
prefer to render the SVG to a lower resolution and retouch them.

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



From thiago.macieira at intel.com  Wed Jul 20 18:47:23 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 20 Jul 2016 09:47:23 -0700
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <313158393.20160720130303@programist.ru>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>
	<313158393.20160720130303@programist.ru>
Message-ID: <2352511.zGkT0Kkulc@tjmaciei-mobl1>

On quarta-feira, 20 de julho de 2016 13:03:03 PDT Prav wrote:
> SVG icons are not shown at all in static builds of Qt, but png icons are
> fine (both icons are taken from resorse file). Static and shred Qt 5.6.1
> build were done with same config settings except of cause "static".

Remember to force the inclusion of the svg icon plugin into your application.

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



From thiago.macieira at intel.com  Wed Jul 20 18:56:55 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 20 Jul 2016 09:56:55 -0700
Subject: [Development] Documenting 3rd party code Qt
In-Reply-To: <AM4PR0201MB21310C0672F7ECDC5C36D0BD98080@AM4PR0201MB2131.eurprd02.prod.outlook.com>
References: <AM4PR0201MB21310C0672F7ECDC5C36D0BD98080@AM4PR0201MB2131.eurprd02.prod.outlook.com>
Message-ID: <1771284.IzB2cIzol8@tjmaciei-mobl1>

On quarta-feira, 20 de julho de 2016 11:13:39 PDT Kai Koehne wrote:
> I had a look at SPDX, README.Chromium, debian/copyright (btw thanks for the
> pointer!). In the end I went for a custom format, because they all seem to
> not quite fit for our use case. Anyhow, it's easy to extend licensescanner
> to generate other formats, too.

What's missing from SPDX and have you tried to talk to them about adding the 
missing information?

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



From pr12og2 at programist.ru  Wed Jul 20 19:13:07 2016
From: pr12og2 at programist.ru (Prav)
Date: Wed, 20 Jul 2016 20:13:07 +0300
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <2523329.S8XnEsz8Oz@tjmaciei-mobl1>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io> 
	<581570494.20160720025652@programist.ru>
	<AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>
	<2523329.S8XnEsz8Oz@tjmaciei-mobl1>
Message-ID: <1623941832.20160720201307@programist.ru>

Hello, Everyone.

> That's one reason, but there are two more equally, if not more important:
> 1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy
> applications suffer if they use it.
Why SVG support of QIcon can not cache rendered result? So re-rendering will be as fast as for PNGs.
Or you are saying about app startup time?

Also there was idea in this thread earlier that SVG rendering can be done much faster ... like in old Opera browser.
Why Qt company cann't ask Opera to share this part of old Presto engine? They decided to not use Presto
nowdays so no loses for them.


> 2) SVG icons designed for higher resolution, with a lot of details, look
> complex and polluted in lower resolutions. From past experience, icon artists
> prefer to render the SVG to a lower resolution and retouch them.
This is a problem. But I do not see many such icons in Material-style. They are mostly simple.
So I would expect modern styled-apps will not have this problem massively.

But for people who really want raster images to be aplied ... may be it is possible to add some method
to QIcon which will store this specially rastered QPixmap in icon and will render icon with this
pixmap if icon size is small. But I am sure most apps will be happy with just SVG rendering.
This is such a detailed work ... not sure that many apps creators will decide this work as a high priority.



From annulen at yandex.ru  Wed Jul 20 19:15:55 2016
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Wed, 20 Jul 2016 20:15:55 +0300
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <1623941832.20160720201307@programist.ru>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io> 
	<581570494.20160720025652@programist.ru>
	<AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>
	<2523329.S8XnEsz8Oz@tjmaciei-mobl1>
	<1623941832.20160720201307@programist.ru>
Message-ID: <101201469034955@web19h.yandex.ru>



20.07.2016, 20:12, "Prav" <pr12og2 at programist.ru>:
> Hello, Everyone.
>
>>  That's one reason, but there are two more equally, if not more important:
>>  1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy
>>  applications suffer if they use it.
>
> Why SVG support of QIcon can not cache rendered result? So re-rendering will be as fast as for PNGs.
> Or you are saying about app startup time?
>
> Also there was idea in this thread earlier that SVG rendering can be done much faster ... like in old Opera browser.
> Why Qt company cann't ask Opera to share this part of old Presto engine? They decided to not use Presto
> nowdays so no loses for them.

Is SVG engine of Opera really faster than that of WebKit?

>
>>  2) SVG icons designed for higher resolution, with a lot of details, look
>>  complex and polluted in lower resolutions. From past experience, icon artists
>>  prefer to render the SVG to a lower resolution and retouch them.
>
> This is a problem. But I do not see many such icons in Material-style. They are mostly simple.
> So I would expect modern styled-apps will not have this problem massively.
>
> But for people who really want raster images to be aplied ... may be it is possible to add some method
> to QIcon which will store this specially rastered QPixmap in icon and will render icon with this
> pixmap if icon size is small. But I am sure most apps will be happy with just SVG rendering.
> This is such a detailed work ... not sure that many apps creators will decide this work as a high priority.
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From thiago.macieira at intel.com  Wed Jul 20 19:44:16 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 20 Jul 2016 10:44:16 -0700
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <1623941832.20160720201307@programist.ru>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<2523329.S8XnEsz8Oz@tjmaciei-mobl1>
	<1623941832.20160720201307@programist.ru>
Message-ID: <2251291.h06p8NutaS@tjmaciei-mobl1>

On quarta-feira, 20 de julho de 2016 20:13:07 PDT Prav wrote:
> Hello, Everyone.
> 
> > That's one reason, but there are two more equally, if not more important:
> > 1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy
> > applications suffer if they use it.
> 
> Why SVG support of QIcon can not cache rendered result? So re-rendering will
> be as fast as for PNGs. Or you are saying about app startup time?

Startup.

> Also there was idea in this thread earlier that SVG rendering can be done
> much faster ... like in old Opera browser. Why Qt company cann't ask Opera
> to share this part of old Presto engine? They decided to not use Presto
> nowdays so no loses for them.

I can't speak for business decisions. But however faster that engine is, it'll 
still be orders of magnitude slower than PNG.

> > 2) SVG icons designed for higher resolution, with a lot of details, look
> > complex and polluted in lower resolutions. From past experience, icon
> > artists prefer to render the SVG to a lower resolution and retouch them.
> 
> This is a problem. But I do not see many such icons in Material-style. They
> are mostly simple. So I would expect modern styled-apps will not have this
> problem massively.

I don't know what Material is, but whatever it is, I doubt it allows you to 
make that generalised assumption.

> But for people who really want raster images to be aplied ... may be it is
> possible to add some method to QIcon which will store this specially
> rastered QPixmap in icon and will render icon with this pixmap if icon size
> is small. But I am sure most apps will be happy with just SVG rendering.
> This is such a detailed work ... not sure that many apps creators will
> decide this work as a high priority.

As Morten said, Qt does not have a choice: we have to support both SVG and 
raster icons.

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



From pr12og2 at programist.ru  Wed Jul 20 20:03:48 2016
From: pr12og2 at programist.ru (Prav)
Date: Wed, 20 Jul 2016 21:03:48 +0300
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <2251291.h06p8NutaS@tjmaciei-mobl1>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io> 
	<2523329.S8XnEsz8Oz@tjmaciei-mobl1>
	<1623941832.20160720201307@programist.ru>
	<2251291.h06p8NutaS@tjmaciei-mobl1>
Message-ID: <1966367350.20160720210348@programist.ru>

> Startup.

Approximately how many icons app have to have to see influence on app's startup?


>> Also there was idea in this thread earlier that SVG rendering can be done
>> much faster ... like in old Opera browser. Why Qt company cann't ask Opera
>> to share this part of old Presto engine? They decided to not use Presto
>> nowdays so no loses for them.

> I can't speak for business decisions. But however faster that engine is, it'll
> still be orders of magnitude slower than PNG.

But scaling is a problem.


>> But for people who really want raster images to be aplied ... may be it is
>> possible to add some method to QIcon which will store this specially
>> rastered QPixmap in icon and will render icon with this pixmap if icon size
>> is small. But I am sure most apps will be happy with just SVG rendering.
>> This is such a detailed work ... not sure that many apps creators will
>> decide this work as a high priority.

> As Morten said, Qt does not have a choice: we have to support both SVG and
> raster icons.

Agree. I am about details. If user can only select SVG OR PNG this is one way to support both icon formats.

I was trying to say that combined variant is imaginable and is interesting because can have benefits of both formats.



From thiago.macieira at intel.com  Wed Jul 20 20:08:25 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 20 Jul 2016 11:08:25 -0700
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <1966367350.20160720210348@programist.ru>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<2251291.h06p8NutaS@tjmaciei-mobl1>
	<1966367350.20160720210348@programist.ru>
Message-ID: <1975378.x7RacEeekv@tjmaciei-mobl1>

On quarta-feira, 20 de julho de 2016 21:03:48 PDT Prav wrote:
> > Startup.
> 
> Approximately how many icons app have to have to see influence on app's
> startup?

That depends on the complexity of your SVG icons and how powerful your CPU is.

> > I can't speak for business decisions. But however faster that engine is,
> > it'll still be orders of magnitude slower than PNG.
> 
> But scaling is a problem.

Yes. It's a trade-off.

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



From annulen at yandex.ru  Wed Jul 20 20:21:48 2016
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Wed, 20 Jul 2016 21:21:48 +0300
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <1975378.x7RacEeekv@tjmaciei-mobl1>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<2251291.h06p8NutaS@tjmaciei-mobl1>
	<1966367350.20160720210348@programist.ru>
	<1975378.x7RacEeekv@tjmaciei-mobl1>
Message-ID: <167621469038908@web25m.yandex.ru>



20.07.2016, 21:08, "Thiago Macieira" <thiago.macieira at intel.com>:
> On quarta-feira, 20 de julho de 2016 21:03:48 PDT Prav wrote:
>>  > Startup.
>>
>>  Approximately how many icons app have to have to see influence on app's
>>  startup?
>
> That depends on the complexity of your SVG icons and how powerful your CPU is.
>
>>  > I can't speak for business decisions. But however faster that engine is,
>>  > it'll still be orders of magnitude slower than PNG.
>>
>>  But scaling is a problem.
>
> Yes. It's a trade-off.

One could use SVG to C++ translator to trade CPU usage / startup time to code size (and probably feature set)

http://zrusin.blogspot.ru/2006/07/compiling-svg-to-c.html

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From Uwe.Rathmann at tigertal.de  Wed Jul 20 21:00:18 2016
From: Uwe.Rathmann at tigertal.de (Uwe Rathmann)
Date: Wed, 20 Jul 2016 19:00:18 +0000 (UTC)
Subject: [Development] Revisiting high-DPI configuration options
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<2523329.S8XnEsz8Oz@tjmaciei-mobl1>
	<1623941832.20160720201307@programist.ru>
	<2251291.h06p8NutaS@tjmaciei-mobl1>
Message-ID: <nmoho1$6n8$1@ger.gmane.org>

On Wed, 20 Jul 2016 10:44:16 -0700, Thiago Macieira wrote:

>> Why SVG support of QIcon can not cache rendered result? So re-rendering
>> will be as fast as for PNGs. Or you are saying about app startup time?
> 
> Startup.

When using SVGs you have to load/parse it into QSvgRenderer and later it 
needs to be replayed via QPainter in the size you need.

While the second step can't be avoided at runtime, it is possible to 
convert SVGs into something, that can be loaded significantly faster, at 
compile time.

I'm using an implementation based on this class: http://
qwt.sourceforge.net/class_qwt_graphic.html. This is a record/replay 
device for QPainter commands - like QPicture, but suitable for vector 
graphics. I added load/save methods ( not yet in SVN ) and then the 
compiler itself is 20 lines of code only.

When using such a concept with Qt Quick, better don't use standard Image 
classes as they are designed for raster graphics. Better write your own 
type of control for it - at least this is what I did.

Uwe




From denis.shienkov at gmail.com  Wed Jul 20 22:16:37 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Wed, 20 Jul 2016 23:16:37 +0300
Subject: [Development] [QtMultimedia] Still is supported, active?
Message-ID: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>

Hi guys,

I write the angry letter concerning fixing of errors in QtMM the module. 
Sorry, but I have no more patience to be silent.

This module contains a set of *critical* errors, some of which aren't 
not fixed within 6 months. For example, currently
it is impossible to use QtMM > 5.6 in Windows for video playback, e.g:
  https://bugreports.qt.io/browse/QTBUG-53019

This epic bug was introduces in 5.6 and above, though in 5.5.1 it works 
"fine".

I had an impression that the maintainer of QtMM (Yoann Lopes) has become
deaf, has become blind, or just ignores any task in the bug tracker. WTF?

As I know he is working in Qt's company (at least from e-mail), receives 
money
  for his work, but does nothing.. WTF?

WTF? If you don't support this module - then, please, remove away him to 
devils, to hell.

Thanks for attension.

BR,
Denis



From Andy.Nichols at qt.io  Wed Jul 20 22:38:58 2016
From: Andy.Nichols at qt.io (Andy Nichols)
Date: Wed, 20 Jul 2016 20:38:58 +0000
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>
Message-ID: <HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>

Hi Denis,


This type of mail in not constructive at all, and is not appropriate on this list.


You could propose your concerns about your bug on the bug tracker and this mailing list without the personal attacks on a Qt Project developer.


There is active development on the QtMultimedia module even now in the vacation season:

https://codereview.qt-project.org/#/q/project:qt/qtmultimedia,n,z


And your claim that the QtMultimedia maintainer Yoann is somehow not doing his job is dead wrong:

https://codereview.qt-project.org/#/q/owner:%22Yoann+Lopes%22,n,z


It's not right for you to try shame a fellow developer about someone on the public mailing list just because you are upset your bug is not being fixed.


Not cool.


Andy Nichols

________________________________
From: Development <development-bounces+andy.nichols=qt.io at qt-project.org> on behalf of Denis Shienkov <denis.shienkov at gmail.com>
Sent: Wednesday, July 20, 2016 10:16:37 PM
To: development at qt-project.org
Subject: [Development] [QtMultimedia] Still is supported, active?

Hi guys,

I write the angry letter concerning fixing of errors in QtMM the module.
Sorry, but I have no more patience to be silent.

This module contains a set of *critical* errors, some of which aren't
not fixed within 6 months. For example, currently
it is impossible to use QtMM > 5.6 in Windows for video playback, e.g:
  https://bugreports.qt.io/browse/QTBUG-53019

This epic bug was introduces in 5.6 and above, though in 5.5.1 it works
"fine".

I had an impression that the maintainer of QtMM (Yoann Lopes) has become
deaf, has become blind, or just ignores any task in the bug tracker. WTF?

As I know he is working in Qt's company (at least from e-mail), receives
money
  for his work, but does nothing.. WTF?

WTF? If you don't support this module - then, please, remove away him to
devils, to hell.

Thanks for attension.

BR,
Denis

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160720/aacc72ab/attachment.html>

From thiago.macieira at intel.com  Wed Jul 20 23:03:11 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 20 Jul 2016 14:03:11 -0700
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <167621469038908@web25m.yandex.ru>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<1975378.x7RacEeekv@tjmaciei-mobl1>
	<167621469038908@web25m.yandex.ru>
Message-ID: <3623367.qVL8lEfHpM@tjmaciei-mobl1>

On quarta-feira, 20 de julho de 2016 21:21:48 PDT Konstantin Tokarev wrote:
> One could use SVG to C++ translator to trade CPU usage / startup time to
> code size (and probably feature set)
> 
> http://zrusin.blogspot.ru/2006/07/compiling-svg-to-c.html

And who do you think wrote QtSvg in the first place? Same person :-)

(Zack, are you still lurking around in the ML?)

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



From denis.shienkov at gmail.com  Wed Jul 20 23:19:44 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Thu, 21 Jul 2016 00:19:44 +0300
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>
	<HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>
Message-ID: <8fa890de-7145-4fe0-bfd3-b600faf8bd2a@gmail.com>

Hi Andy,

I periodically do watching for qt codereview status. So, your provided 
links has not effect for me (I'm do not surprised).

It is strange for me that the majority of these commits have no 
task-numbers, there is an impression, that bugs in a tracker are just 
ignored.

It is strange for me, that is performed some "unclear" work there (which 
is improves nothing, but introduces a new bugs IMHO) instead of fixing 
of a *critical* bugs.

Do you tests before release our module? I think - NOT!

Concerning QtMM maintainer: he should at least let us to know to 
bug-tracker, that the concrete issue will been accepted or not (at least 
not to be silent there).

Otherwise there is an impression that I talk there to myself or to a 
blank wall.

Besides, I don't understand, how is it possible to skip such critical 
bug (and others critical bugs), and not to notice it.

PS: I already repeatedly wrote to mailing-list concerning to QtMM 
status, but nothing changes. I think, nothing will change in future too.

BR,

Denis







20.07.2016 23:38, Andy Nichols пишет:
>
> Hi Denis,
>
>
> This type of mail in not constructive at all, and is not appropriate 
> on this list.
>
>
> You could propose your concerns about your bug on the bug tracker and 
> this mailing list without the personal attacks on a Qt Project developer.
>
>
> There is active development on the QtMultimedia module even now in the 
> vacation season:
>
> https://codereview.qt-project.org/#/q/project:qt/qtmultimedia,n,z
>
>
> And your claim that the QtMultimedia maintainer Yoann is somehow not 
> doing his job is dead wrong:
>
> https://codereview.qt-project.org/#/q/owner:%22Yoann+Lopes%22,n,z
>
>
> It's not right for you to try shame a fellow developer about someone 
> on the public mailing list just because you are upset your bug is not 
> being fixed.
>
>
> Not cool.
>
>
> Andy Nichols
>
> ------------------------------------------------------------------------
> *From:* Development 
> <development-bounces+andy.nichols=qt.io at qt-project.org> on behalf of 
> Denis Shienkov <denis.shienkov at gmail.com>
> *Sent:* Wednesday, July 20, 2016 10:16:37 PM
> *To:* development at qt-project.org
> *Subject:* [Development] [QtMultimedia] Still is supported, active?
> Hi guys,
>
> I write the angry letter concerning fixing of errors in QtMM the module.
> Sorry, but I have no more patience to be silent.
>
> This module contains a set of *critical* errors, some of which aren't
> not fixed within 6 months. For example, currently
> it is impossible to use QtMM > 5.6 in Windows for video playback, e.g:
> https://bugreports.qt.io/browse/QTBUG-53019
>
> This epic bug was introduces in 5.6 and above, though in 5.5.1 it works
> "fine".
>
> I had an impression that the maintainer of QtMM (Yoann Lopes) has become
> deaf, has become blind, or just ignores any task in the bug tracker. WTF?
>
> As I know he is working in Qt's company (at least from e-mail), receives
> money
>   for his work, but does nothing.. WTF?
>
> WTF? If you don't support this module - then, please, remove away him to
> devils, to hell.
>
> Thanks for attension.
>
> BR,
> Denis
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160721/127e16c0/attachment.html>

From thiago.macieira at intel.com  Wed Jul 20 23:38:32 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 20 Jul 2016 14:38:32 -0700
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <8fa890de-7145-4fe0-bfd3-b600faf8bd2a@gmail.com>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>
	<HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>
	<8fa890de-7145-4fe0-bfd3-b600faf8bd2a@gmail.com>
Message-ID: <1652868.Lj3xVX6QOI@tjmaciei-mobl1>

On quinta-feira, 21 de julho de 2016 00:19:44 PDT Denis Shienkov wrote:
> It is strange for me, that is performed some "unclear" work there (which
> is improves nothing, but introduces a new bugs IMHO) instead of fixing
> of a *critical* bugs.

The one you linked to is P2 - Important. It's neither critical nor 
showstopper.

> Do you tests before release our module? I think - NOT!

Where's your proof?

> Concerning QtMM maintainer: he should at least let us to know to
> bug-tracker, that the concrete issue will been accepted or not (at least
> not to be silent there).

Bugs are fixed when they are fixed. You won't get any estimate before the 
developer actually starts fixing the issue. And even then, it may take months 
or more until it actually gets fixed.

> Otherwise there is an impression that I talk there to myself or to a
> blank wall.
> 
> Besides, I don't understand, how is it possible to skip such critical
> bug (and others critical bugs), and not to notice it.

It's not critical, according to whoever triaged it.

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



From techabc at gmail.com  Thu Jul 21 08:01:16 2016
From: techabc at gmail.com (techabc)
Date: Thu, 21 Jul 2016 14:01:16 +0800
Subject: [Development] Are QT winmigrate framework will be back in qt
 5.x ?
In-Reply-To: <CAPPwZt64u8T7Lf==dWhM19ua4A2kFOrvGbmG6Nqr5mYyyf4OBQ@mail.gmail.com>
References: <CAPPwZt64u8T7Lf==dWhM19ua4A2kFOrvGbmG6Nqr5mYyyf4OBQ@mail.gmail.com>
Message-ID: <CAPPwZt7iVx8X6WVjMBdSt+YcvV5kTkCUtB+TsRW2iPT==9XO0g@mail.gmail.com>

How can I reuse the MFC based GUI dll in a QT application?


2016-06-26 21:53 GMT+08:00 techabc <techabc at gmail.com>:

> I need to call 300+ MFC extending DLL in a new QT 5.x application, if
> except winmigrate, whatthing else can do it?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160721/46fba791/attachment.html>

From scott at towel42.com  Thu Jul 21 08:20:31 2016
From: scott at towel42.com (Scott Aron Bloom)
Date: Thu, 21 Jul 2016 06:20:31 +0000
Subject: [Development] Are QT winmigrate framework will be back in qt
 5.x ?
In-Reply-To: <CAPPwZt7iVx8X6WVjMBdSt+YcvV5kTkCUtB+TsRW2iPT==9XO0g@mail.gmail.com>
References: <CAPPwZt64u8T7Lf==dWhM19ua4A2kFOrvGbmG6Nqr5mYyyf4OBQ@mail.gmail.com>
	<CAPPwZt7iVx8X6WVjMBdSt+YcvV5kTkCUtB+TsRW2iPT==9XO0g@mail.gmail.com>
Message-ID: <CY1PR10MB0170DA02D2FB2578C4FBFB80A9090@CY1PR10MB0170.namprd10.prod.outlook.com>

A lot of it will depend on what you are using Qt for.

I used the Qt Solution for WinMigrate, which essentially (At a very high level) makes sure the Qt event loop gets called when the MFC event loop is run.

Where I used it was to add Qt windows and Qt eventloop driven functionality (QHttp before QNetworkAccessManager existed).  It worked fine for stand alone top level windows.

I don’t recommend it for modal windows, or for “child widgets”.

Im not sure what you are looking for besides the qt solution for winmigrate.

Scott
From: Development [mailto:development-bounces+scott=towel42.com at qt-project.org] On Behalf Of techabc
Sent: Wednesday, July 20, 2016 23:01
To: development <development at qt-project.org>
Subject: Re: [Development] Are QT winmigrate framework will be back in qt 5.x ?

How can I reuse the MFC based GUI dll in a QT application?


2016-06-26 21:53 GMT+08:00 techabc <techabc at gmail.com<mailto:techabc at gmail.com>>:
I need to call 300+ MFC extending DLL in a new QT 5.x application, if except winmigrate, whatthing else can do it?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160721/a258927b/attachment.html>

From Kai.Koehne at qt.io  Thu Jul 21 09:04:51 2016
From: Kai.Koehne at qt.io (Kai Koehne)
Date: Thu, 21 Jul 2016 07:04:51 +0000
Subject: [Development] Documenting 3rd party code Qt
In-Reply-To: <1771284.IzB2cIzol8@tjmaciei-mobl1>
References: <AM4PR0201MB21310C0672F7ECDC5C36D0BD98080@AM4PR0201MB2131.eurprd02.prod.outlook.com>
	<1771284.IzB2cIzol8@tjmaciei-mobl1>
Message-ID: <AM4PR0201MB21317741171A40949930C4E998090@AM4PR0201MB2131.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-bounces+kai.koehne=qt.io at qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: Wednesday, July 20, 2016 6:57 PM
> To: development at qt-project.org
> Subject: Re: [Development] Documenting 3rd party code Qt
> 
> On quarta-feira, 20 de julho de 2016 11:13:39 PDT Kai Koehne wrote:
> > I had a look at SPDX, README.Chromium, debian/copyright (btw thanks
> > for the pointer!). In the end I went for a custom format, because they
> > all seem to not quite fit for our use case. Anyhow, it's easy to
> > extend licensescanner to generate other formats, too.
> 
> What's missing from SPDX and have you tried to talk to them about adding
> the missing information?

I'm not sure whether anything particular is missing in the standard - my best
guess is we could create a syntactically valid SPDX file containing the same
information that we currently have in the proposed qt_attribution.json file format.

However, SPDX is a standard for "software packages" - it would probably make
more sense to add an SPDX file for QtCore or even qtbase. Using a SPDX file for
a single file in 3rdparty feels a bit like a misuse. 

Also, the tools I found to process spdx files are written in Java, which I certainly 
do not want to add as a build dependency. This would mean we'd write a custom 
parser for the subset of SPDX we'd support.

In the end I concluded it's just easier to have a tailored format we have full
control over, but can be used as a source for generating SPDX/debian_copyright/...
files as they're needed. I'd be happy to have a discussion about this with
someone interested in this.

My proposal is to use the names and matching guidelines from
https://spdx.org/licenses/ though. 


Regards

Kai

From pr12og2 at programist.ru  Thu Jul 21 09:20:59 2016
From: pr12og2 at programist.ru (Prav)
Date: Thu, 21 Jul 2016 10:20:59 +0300
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <1652868.Lj3xVX6QOI@tjmaciei-mobl1>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com> 
	<HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>
	<8fa890de-7145-4fe0-bfd3-b600faf8bd2a@gmail.com>
	<1652868.Lj3xVX6QOI@tjmaciei-mobl1>
Message-ID: <180642004.20160721102059@programist.ru>

Hello, Everyone.

> Bugs are fixed when they are fixed. You won't get any estimate before the
> developer actually starts fixing the issue. And even then, it may take months
> or more until it actually gets fixed.

Agree but devil is in details. Currently there is a practice to not fill-out necessary fields for the bugs and not to change its status.
I exactly mean
* Not changing from Reported to Opened (or Need Info or Closed) ... like it is with discussed QTBUG-53019 (1/2 year old)
* Not assigning responsible person in Assignee field like it is for ex. with QTBUG-46812 (1 year old)
* Not assigning Fix Version/s ... which can mean there is no plans for the bug.
     No plans can be because of 3 reasons:
        I do not care and going to silently ignore the bug
          OR
        I agree with the bug but have so many bugs to fix already so that this is to far from my 1 month plan (or 3 month plan or 1 year plan ... nobody knows what plan is meant)
          OR
        I except the bug but do not want to bother myself with filling this field about my plans


Having these details like this make such letters from time to time appear in mailing list. This is natural and is predictable result.

So while I agree that angriness is not helpful for mail list ... messages like this are probably the seed to rethink strategy of working with bugs.

This is probably means that we need some easy to use query in bug-tracker system which can show up "unprocessed bugs" ... which is bugs with
  state Reported
OR
  no Assignee
OR
  no Fix version
With sorting from oldest creation date to newest.

All unprocessed bugs make people float in unconditional state like
 floating 1: was the bug accepted or not (state is still Reported)
 floating 2: does anyone (mighty to fix it) knows about it (Assignee filed is empty)
 floating 3: how long approximately to wait for fix ... month, 3 months, year, 10 years (Fix Version blank)

This unconditional state make people do what they do. For example angry letter can be easy the result of "floating 1".
May be my request need more buzz so that it will be processed.

If Yoann Lopes will fill the bugs fields why in the world would Denis Shienkov ever wrote this letter. Never.
Because attitude to the bug will be clear to him.
And Denis can only live with this (like trying to fix himself, or hire someone or stick to Qt 5.5.1 forever or whatever else)

I IMHO see Denis Shienkov's personal attacks to Yoann Lopes quite reasonable not in sense of not-fixing the bug but
in sense of not filling bug's fields ... Those fields are in the bug-tracker system FOR A REASON and it is
MORE THAN IMPORTANT for reporter to see them filled.


So I am trying to say that there is tendency for qt-devs maintainers to ignore value of described fields for reporters of bugs and
angry letter is predictable result of this tendency.

Instead of trying to shut up the Denis we better discuss current situation with bug-tracker and decide to make some clear for everyone tools
which can show up forgotten bugs (described idea of unprocessed bug query) which makes people write angry.


And I totally agree that "Bugs are fixed when they are fixed". And agree that maintainers need to respect Best Practices of working with bug-tracking ALSO
(which exactly mean filling out ALL these 3 fields ... they ALL are important).


>> Otherwise there is an impression that I talk there to myself or to a blank wall.
You see. He is telling that he feels unheard... he see no reaction ... and he start making buzz in mailing list. Very predictable.
But why this reaction should be exactly in fixing the bug? It can be enough to fill the bug's fields I think.
Maintainers also have limited working-time.



So what I propose IMHO seems to be a good balance for maintainers and bug-reporters.



So I have 3 questions in my mind about this:

Can we discuss this theme (about bug-tracker system) with some practical things which can be improved from ballancing perspectives of view to tracking of bugs?

Can Qt Product Managers arise the importance of Best Practices of working with bugs-tracker for developers?

Can someone create this query inside bug-tracker system and share it with everyone so that unprocessed bugs can be shown?



From Kai.Koehne at qt.io  Thu Jul 21 09:41:15 2016
From: Kai.Koehne at qt.io (Kai Koehne)
Date: Thu, 21 Jul 2016 07:41:15 +0000
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <180642004.20160721102059@programist.ru>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>
	<HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>
	<8fa890de-7145-4fe0-bfd3-b600faf8bd2a@gmail.com>
	<1652868.Lj3xVX6QOI@tjmaciei-mobl1>
	<180642004.20160721102059@programist.ru>
Message-ID: <AM4PR0201MB2131882844D7450ED35146B998090@AM4PR0201MB2131.eurprd02.prod.outlook.com>

> -----Original Message-----
> From: Development [mailto:development-bounces+kai.koehne=qt.io at qt-
> [...]
> So while I agree that angriness is not helpful for mail list ... messages like this
> are probably the seed to rethink strategy of working with bugs.

Somewhat a side remark, but the unfortunate consequence of this thinking is
that the objectively best way to get a lot of Qt developers interested in your
problem is to write e-mails that breach of etiquette (to put it mildly).

If Denis would have written a reasonable e-mail asking about the status of Qt
Multimedia (without insults, attacks, and wishing anyone to hell), we most
probably won't have this discussion.



I think Denis should end this e-mail thread by apologizing, and start a new one
in a reasonable way.

Just my 2 cents,

Kai

From denis.shienkov at gmail.com  Thu Jul 21 11:01:18 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Thu, 21 Jul 2016 12:01:18 +0300
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <AM4PR0201MB2131882844D7450ED35146B998090@AM4PR0201MB2131.eurprd02.prod.outlook.com>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>
	<HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>
	<8fa890de-7145-4fe0-bfd3-b600faf8bd2a@gmail.com>
	<1652868.Lj3xVX6QOI@tjmaciei-mobl1>
	<180642004.20160721102059@programist.ru>
	<AM4PR0201MB2131882844D7450ED35146B998090@AM4PR0201MB2131.eurprd02.prod.outlook.com>
Message-ID: <CAHtcb0ycscGRYqmnLwsGfoTWVq8dBpkab8qoZoDh0xGJKS_MgQ@mail.gmail.com>

@ Thiago,

>The one you linked to is P2 - Important. It's neither critical nor
showstopper.

It isn't I did the decision about assigning the P2 status. I personally
would establish P0/P1 if it would make sense (but, it is just "empty work"
which won't change anything).
Since many bugs with P1 statuses still are not considered.

> It's not critical, according to whoever triaged it.

If the AVI video playback shows with 0.5-1 FPS then it is not critical for
you? Then it is strange for me... o_O

> Where's your proof?

My proof - it is a BUG tracker and current QtMM status.

@ Kai,

> I think Denis should end this e-mail thread by apologizing, and start a
new one
in a reasonable way.

I do not consider myself as the guilty person and I have nothing to
apologize.

BR,
Denis




2016-07-21 10:41 GMT+03:00 Kai Koehne <Kai.Koehne at qt.io>:

> > -----Original Message-----
> > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt-
> > [...]
> > So while I agree that angriness is not helpful for mail list ...
> messages like this
> > are probably the seed to rethink strategy of working with bugs.
>
> Somewhat a side remark, but the unfortunate consequence of this thinking is
> that the objectively best way to get a lot of Qt developers interested in
> your
> problem is to write e-mails that breach of etiquette (to put it mildly).
>
> If Denis would have written a reasonable e-mail asking about the status of
> Qt
> Multimedia (without insults, attacks, and wishing anyone to hell), we most
> probably won't have this discussion.
>
>
>
> I think Denis should end this e-mail thread by apologizing, and start a
> new one
> in a reasonable way.
>
> Just my 2 cents,
>
> Kai
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160721/6e9f350c/attachment.html>

From jturcotte at woboq.com  Thu Jul 21 11:29:03 2016
From: jturcotte at woboq.com (Jocelyn Turcotte)
Date: Thu, 21 Jul 2016 11:29:03 +0200
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <CAHtcb0ycscGRYqmnLwsGfoTWVq8dBpkab8qoZoDh0xGJKS_MgQ@mail.gmail.com>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>
	<HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>
	<8fa890de-7145-4fe0-bfd3-b600faf8bd2a@gmail.com>
	<1652868.Lj3xVX6QOI@tjmaciei-mobl1>
	<180642004.20160721102059@programist.ru>
	<AM4PR0201MB2131882844D7450ED35146B998090@AM4PR0201MB2131.eurprd02.prod.outlook.com>
	<CAHtcb0ycscGRYqmnLwsGfoTWVq8dBpkab8qoZoDh0xGJKS_MgQ@mail.gmail.com>
Message-ID: <03B99D59-476B-48DB-8C3B-717E6D0173C5@woboq.com>


> On 21 Jul 2016, at 11:01, Denis Shienkov <denis.shienkov at gmail.com> wrote:
> 
> @ Thiago,
> 
> >The one you linked to is P2 - Important. It's neither critical nor
> showstopper.
> 
> It isn't I did the decision about assigning the P2 status. I personally would establish P0/P1 if it would make sense (but, it is just "empty work" which won't change anything).  
> Since many bugs with P1 statuses still are not considered.
> 
> > It's not critical, according to whoever triaged it.
> 
> If the AVI video playback shows with 0.5-1 FPS then it is not critical for you? Then it is strange for me... o_O
> 
> > Where's your proof?
> 
> My proof - it is a BUG tracker and current QtMM status.
> 
> @ Kai,
> 
> > I think Denis should end this e-mail thread by apologizing, and start a new one
> in a reasonable way.
> 
> I do not consider myself as the guilty person and I have nothing to apologize.

I think that the bug is important, and I can understand how hard this bug can affect the product that you're trying to ship but you can't be angry at Yoan personally. If he choses to fix your bug to justify his salary, he will have to decide what else NOT to do, which will most likely make somebody else angry. It's his decision as to what to fix, and knowing how difficult it is to maintain a cross-platform multimedia library I think that you greatly underestimate his value as the QtMM maintainer in your message.

The real issue is that QtMM is understaffed, and I can only see one outcome resulting from you making him responsible for your user's disappointment: make him less motivated to do his job to the point where nobody else wants to work on QtMM. Is this what you want?

If you want this bug fixed, or to improve the QtMM quality there are far better ways:

- Get a Qt support license from the Qt Company and raise the issue to them. They very often help raising important customer issues like this one to P1 since in the end, it's that money that pays Qt Company developers.
- Try to fix the issue yourself. You already did more than many users by bisecting the issue, thanks for that. But if this issue is really a showstopper like you say, it can't be that Yoan is the only person in the world that can and would be willing to fix it.
- Hire somebody to fix the bug. We at Woboq can help fixing nasty issues like those in a very reasonable timeframe, KDAB does so as well.

It can be frustrating relying on somebody else for your own software's quality, but open source projects have no responsibilities other than managing a flow of efforts toward a common goal. The project itself isn't responsible for fixing every issue or regression and there has to be a system of mutual benefit (usually ultimately involving money) to make things go forward. Food and coffee needs to go in the mouth of developers to produce those patches through key presses and mouse clicks, and anger doesn't help growing coffee.

Cheers,

Jocelyn Turcotte
http://woboq.com

> 
> BR,
> Denis
> 
> 
> 
> 
> 2016-07-21 10:41 GMT+03:00 Kai Koehne <Kai.Koehne at qt.io>:
> > -----Original Message-----
> > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt-
> > [...]
> > So while I agree that angriness is not helpful for mail list ... messages like this
> > are probably the seed to rethink strategy of working with bugs.
> 
> Somewhat a side remark, but the unfortunate consequence of this thinking is
> that the objectively best way to get a lot of Qt developers interested in your
> problem is to write e-mails that breach of etiquette (to put it mildly).
> 
> If Denis would have written a reasonable e-mail asking about the status of Qt
> Multimedia (without insults, attacks, and wishing anyone to hell), we most
> probably won't have this discussion.
> 
> 
> 
> I think Denis should end this e-mail thread by apologizing, and start a new one
> in a reasonable way.
> 
> Just my 2 cents,
> 
> Kai
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



From pr12og2 at programist.ru  Thu Jul 21 12:52:57 2016
From: pr12og2 at programist.ru (Prav)
Date: Thu, 21 Jul 2016 13:52:57 +0300
Subject: [Development] [Qt-creator] [Windows] Qt Versions/Kit
 auto-detection doesn't work on snapshots
In-Reply-To: <90039149a226410fa781dc5c3bf8975a@SRV1.asctec.local>
References: <90039149a226410fa781dc5c3bf8975a@SRV1.asctec.local>
Message-ID: <18910190677.20160721135257@programist.ru>

An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160721/1695b89a/attachment.html>

From pr12og2 at programist.ru  Thu Jul 21 12:55:48 2016
From: pr12og2 at programist.ru (Prav)
Date: Thu, 21 Jul 2016 13:55:48 +0300
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <AM4PR0201MB2131882844D7450ED35146B998090@AM4PR0201MB2131.eurprd02.prod.outlook.com>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com> 
	<HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>
	<8fa890de-7145-4fe0-bfd3-b600faf8bd2a@gmail.com>
	<1652868.Lj3xVX6QOI@tjmaciei-mobl1>
	<180642004.20160721102059@programist.ru>
	<AM4PR0201MB2131882844D7450ED35146B998090@AM4PR0201MB2131.eurprd02.prod.outlook.com>
Message-ID: <1466640676.20160721135548@programist.ru>

Hello, Everyone.

>> So while I agree that angriness is not helpful for mail list ... messages like this
>> are probably the seed to rethink strategy of working with bugs.

> Somewhat a side remark, but the unfortunate consequence of this thinking is
> that the objectively best way to get a lot of Qt developers interested in your
> problem is to write e-mails that breach of etiquette (to put it mildly).

This will NOT ever be a result (unfortunate consequence) of such thinking. And this is again about details. Proposed reaction is NOT about fixing Denis's bug.
Proposed improvements probably will not help with exactly this bug ever as this is more about maintainer's work.
Because if fixing start to be a result of insulting in emails/mailinglist ... then mailinglist became in majority "insulting platform"

Improvement is for making bug-tracking better is sense of giving less reasons for bug-reporters in general to ever write such letters.
And as result will be lower insulting ... and NOT like you have said
> "objectively best way to get a lot of Qt developers interested in your problem is to write e-mails that breach of etiquette"
... we always meet this devil in details.


Predictable "unfortunate consequence" of not improving will be more such letters (IMHO). Which mean that "objectively best way" (as you have said) to react to such letters is
to improve bug-trackering in general ... to give less food to write such letters.

Food for this is "floating"/unstable state of reporter which comes from silent behaviour of maintainer (bug is unprocessed ... which means necessary fields are still blank).
Do NOT make reporter's state unstable and you will never get unstable messages from reporter. EASY!


> If Denis would have written a reasonable e-mail asking about the status of Qt
> Multimedia (without insults, attacks, and wishing anyone to hell), we most
> probably won't have this discussion.

> I think Denis should end this e-mail thread by apologizing, and start a new one
> in a reasonable way.

Agree. But his behavior is the result of some objective problems which should not be rejected ALSO.

I think this is about of mutual respect. Maintainer have to consider influence of keeping silent about bugs as NEGATIVE INFLUENCE on bug-reporter.
And IMHO this influence is not fully understanded by some maintainers ... and now we have Denis's letter.

I do not know what can be the best analogy ... probably it is like
when you ask librarian about some missing book you can not find and he/she does not answer ... with not NO, not YES ...
zero reaction on you ... just keep doing something he/she was doing ... this surely earlier or later will piss you off.
And next event - reaction ... it depends on person. And you gess what ... some people will start insulting!
So here we are ... predictable percent of insulting in such cases.


Again IMHO ... in this case probably better to ask both sides to make 1 step toward peace.
Yoann Lopes to process the bug (fill the fields ... not fixing it ... fixing is up to mainteiners plans which should come from bugs priority) and Denis Shienkov to apologies for rudeness.



PS
People with high emotional level can be considered as bad because of negative effect of insulting overs.

BUT having such persons inside society helps find problems earlier because they are ones who feels problems most painfully because of this high emotionality.
So this feature can be used by society in positive key. And I do not reject that insulting practice badly influence society too. Here we simply have phenomenon (medal) with two sides


And I agree that probably we can start another thread for discussion of ways to improve bug-tracker.
Because this thread has some too negative messages which gives unproductive effect for cooperation for improving things.

Let's see if Denis will start the new thread for making bug-tracker better place. And I will copy with pleasure my letter about my vision on improvements in this thread.



From mitch.curtis at qt.io  Thu Jul 21 13:04:14 2016
From: mitch.curtis at qt.io (Mitch Curtis)
Date: Thu, 21 Jul 2016 11:04:14 +0000
Subject: [Development] Stack Overflow Documentation
Message-ID: <AM4PR0201MB190503BFF091E89C2A77046B88090@AM4PR0201MB1905.eurprd02.prod.outlook.com>

Hello.

Stack Overflow Documentation is now in Beta. You can read more about it here:

http://stackoverflow.com/tour/documentation

It is much more accessible than our contribution system, so I see a lot of documentation/example contributions going there instead of to Gerrit.

I also wonder if we should consider the popularity (i.e upvotes) of the pages there when we decide which examples to create and add to our documentation. I wonder if the licensing is such that the frameworks like Qt can benefit from the content by "upstreaming" it into their own documentation.

I'm interested to hear what others think about this.


From bahadir.can at outlook.com  Thu Jul 21 13:28:39 2016
From: bahadir.can at outlook.com (=?iso-8859-9?Q?Bahad=FDr_Can?=)
Date: Thu, 21 Jul 2016 11:28:39 +0000
Subject: [Development] Ynt: Boot to Qt Device problem.
In-Reply-To: <VI1PR07MB11655CA085F589E79A4CECC6EB080@VI1PR07MB1165.eurprd07.prod.outlook.com>
References: <VI1PR07MB11655CA085F589E79A4CECC6EB080@VI1PR07MB1165.eurprd07.prod.outlook.com>
Message-ID: <VI1PR07MB11652ECA3DF658C10891A9CDEB080@VI1PR07MB1165.eurprd07.prod.outlook.com>

I can't check if the uboot is too old because board can't boot itself when i use flashboot image of Qt. So I can't update uboot from sd card too. It does nothing basically.


Also uboot is working at yocto images if it shows it is okay.

________________________________
Gönderen: Bahadır Can <bahadir.can at outlook.com>
Gönderildi: 20 Temmuz 2016 Çarşamba 16:41:49
Kime: development at qt-project.org
Konu: Boot to Qt Device problem.


Hello Qt Developers Team,


I am currently working on a Sabre Automative Board with i.MX6Quad. I just started to use Qt Embedded .


I am following this guide :


http://doc.qt.io/QtForDeviceCreation/qtee-preparing-hardware-imx6sabresd.html


I insterted a clean SD card to my device and run the flash boot to Qt Device. (with the option Sabre SD i.MX6Quad)


After installation of image finished. I inserted SD card  to Board and restarted the board but nothing happened. (Terminal and screen didn't work.)


I also tried it with a beaglebone black but got nothing on it too.


Am I missing any steps?


Thanks from now.


Bahadır

Preparing SABRE SD i.MX6Quad | Qt 5.7 for Device Creation<http://doc.qt.io/QtForDeviceCreation/qtee-preparing-hardware-imx6sabresd.html>
doc.qt.io
Take the following steps to prepare Freescale SABRE SD i.MX6Quad for Boot to Qt: Note: It is important that you repeat the steps in this section after you update Qt ...



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160721/cd22af23/attachment.html>

From pr12og2 at programist.ru  Thu Jul 21 13:31:55 2016
From: pr12og2 at programist.ru (Prav)
Date: Thu, 21 Jul 2016 14:31:55 +0300
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <03B99D59-476B-48DB-8C3B-717E6D0173C5@woboq.com>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com> 
	<HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>
	<8fa890de-7145-4fe0-bfd3-b600faf8bd2a@gmail.com>
	<1652868.Lj3xVX6QOI@tjmaciei-mobl1>
	<180642004.20160721102059@programist.ru>
	<AM4PR0201MB2131882844D7450ED35146B998090@AM4PR0201MB2131.eurprd02.prod.outlook.com>
	<CAHtcb0ycscGRYqmnLwsGfoTWVq8dBpkab8qoZoDh0xGJKS_MgQ@mail.gmail.com>
	<03B99D59-476B-48DB-8C3B-717E6D0173C5@woboq.com>
Message-ID: <38899413.20160721143155@programist.ru>

Hello, Everyone.

> If you want this bug fixed, or to improve the QtMM quality there are far better ways:

> - Get a Qt support license from the Qt Company and raise the issue
> to them. They very often help raising important customer issues like
> this one to P1 since in the end, it's that money that pays Qt Company developers.
> - Try to fix the issue yourself. You already did more than many
> users by bisecting the issue, thanks for that. But if this issue is
> really a showstopper like you say, it can't be that Yoan is the only
> person in the world that can and would be willing to fix it.
> - Hire somebody to fix the bug. We at Woboq can help fixing nasty
> issues like those in a very reasonable timeframe, KDAB does so as well.

Here is also one important detail. If Denis need to decide to hire someone he need information about plans of fixing the bug.
If he need to wait 1/2 year to get estimation that this bug is not going to be fixed in nearest months this can make him piss off. Easy imaginable!

If "Fix Version" is filled by Yoann Lopes 6 months ago then he will get this estimation and can decide to hire Woboq or someone else to fix or whatever.
Currently he is in "floating"/unstable/non-informative situation. So less reasons to act smart and more food for emotional letters.
If this situation looks fine for maintainers then there is no sense in shutting up Denis. What to expect? People cry/insult if it hurts and no one listen. So predictable!

Maintainers need to think about bug-reporters ALSO ... and keep bug-reporters in stable state.
Imagine if for this bug "Fix Version" was filled with "Qt 6.0" then Denis Shienkov will get estimation of what waits him. And he can act.
If for some reasons this estimation will be changed by maintainer to let's say 6.5 (or 5.10) then bug-reporter will send email notification to Denis
about change of attitude to the bug he care about. Easy!

So IMHO here we have violation of Best Practices of bug-tracking from maintainer
and emotional angry-letter as the result of 1/2 year influence of this violation on bug-reporter. Simple!

That is why I propose to create query in bug-tracker which will show up such violations.
This is not about fixing bugs ... this is about respecting from maintainer’s side the bug-tracker fields which need to be filled and which influences bug-reporters.

Just fill 3 fields.
Done!



From mitch.curtis at qt.io  Thu Jul 21 13:54:15 2016
From: mitch.curtis at qt.io (Mitch Curtis)
Date: Thu, 21 Jul 2016 11:54:15 +0000
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <38899413.20160721143155@programist.ru>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>
	<HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>
	<8fa890de-7145-4fe0-bfd3-b600faf8bd2a@gmail.com>
	<1652868.Lj3xVX6QOI@tjmaciei-mobl1>	<180642004.20160721102059@programist.ru>
	<AM4PR0201MB2131882844D7450ED35146B998090@AM4PR0201MB2131.eurprd02.prod.outlook.com>
	<CAHtcb0ycscGRYqmnLwsGfoTWVq8dBpkab8qoZoDh0xGJKS_MgQ@mail.gmail.com>
	<03B99D59-476B-48DB-8C3B-717E6D0173C5@woboq.com>
	<38899413.20160721143155@programist.ru>
Message-ID: <AM4PR0201MB1905939750E4B3551F323E3788090@AM4PR0201MB1905.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-
> project.org] On Behalf Of Prav
> Sent: Thursday, 21 July 2016 1:32 PM
> To: development at qt-project.org
> Subject: Re: [Development] [QtMultimedia] Still is supported, active?
> 
> Hello, Everyone.
> 
> > If you want this bug fixed, or to improve the QtMM quality there are far
> better ways:
> 
> > - Get a Qt support license from the Qt Company and raise the issue to
> > them. They very often help raising important customer issues like this
> > one to P1 since in the end, it's that money that pays Qt Company
> developers.
> > - Try to fix the issue yourself. You already did more than many users
> > by bisecting the issue, thanks for that. But if this issue is really a
> > showstopper like you say, it can't be that Yoan is the only person in
> > the world that can and would be willing to fix it.
> > - Hire somebody to fix the bug. We at Woboq can help fixing nasty
> > issues like those in a very reasonable timeframe, KDAB does so as well.
> 
> Here is also one important detail. If Denis need to decide to hire someone
> he need information about plans of fixing the bug.
> If he need to wait 1/2 year to get estimation that this bug is not going
> to be fixed in nearest months this can make him piss off. Easy imaginable!
> 
> If "Fix Version" is filled by Yoann Lopes 6 months ago then he will get
> this estimation and can decide to hire Woboq or someone else to fix or
> whatever.

This is an unreasonable expectation to place on developers. For blockers (which, as far as I understand, this was not), yes, the fix version is most likely going to be known, but for many bugs, it's extremely difficult to know when they will be fixed. Things happen, priorities change. Also, there are always lots of bugs waiting to be fixed. It's a huge product.

The more reasonable approach to this is to contact the maintainer or the current assignee and let them know that you're planning on working on it, to avoid stepping on each other's toes.

But then again.. we both know that anyone who is *serious* about getting something fixed would have taken this approach, right? :) Only those who complain (regardless of the facts and realities presented to them) while making no attempts to come forward with a solution would consider this an effective use of their time.

> Currently he is in "floating"/unstable/non-informative situation. So less
> reasons to act smart and more food for emotional letters.
> If this situation looks fine for maintainers then there is no sense in
> shutting up Denis. What to expect? People cry/insult if it hurts and no
> one listen. So predictable!
> 
> Maintainers need to think about bug-reporters ALSO ... and keep bug-
> reporters in stable state.
> Imagine if for this bug "Fix Version" was filled with "Qt 6.0" then Denis
> Shienkov will get estimation of what waits him. And he can act.
> If for some reasons this estimation will be changed by maintainer to let's
> say 6.5 (or 5.10) then bug-reporter will send email notification to Denis
> about change of attitude to the bug he care about. Easy!
> 
> So IMHO here we have violation of Best Practices of bug-tracking from
> maintainer and emotional angry-letter as the result of 1/2 year influence
> of this violation on bug-reporter. Simple!
> 
> That is why I propose to create query in bug-tracker which will show up
> such violations.
> This is not about fixing bugs ... this is about respecting from
> maintainer's side the bug-tracker fields which need to be filled and which
> influences bug-reporters.
> 
> Just fill 3 fields.
> Done!
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From boud at valdyas.org  Thu Jul 21 15:19:38 2016
From: boud at valdyas.org (Boudewijn Rempt)
Date: Thu, 21 Jul 2016 15:19:38 +0200 (CEST)
Subject: [Development] qtbase-opensource-src-5.6.1-1.tar.xz
Message-ID: <alpine.LNX.2.00.1607211518030.5250@calcifer.valdyas.org>

I just found that qtbase-opensource-src-5.6.1-1.tar.xz
unpacks to qtbase-opensource-src-5.6.1, which completely
breaks any automated system like mxe (mxe.cc) which depends
on the foldername being the same tarball name.

Was this intentional, or just an oversight?

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org


From pr12og2 at programist.ru  Thu Jul 21 16:05:42 2016
From: pr12og2 at programist.ru (Prav)
Date: Thu, 21 Jul 2016 17:05:42 +0300
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <AM4PR0201MB1905939750E4B3551F323E3788090@AM4PR0201MB1905.eurprd02.prod.outlook.com>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com> 
	<HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>
	<8fa890de-7145-4fe0-bfd3-b600faf8bd2a@gmail.com>
	<1652868.Lj3xVX6QOI@tjmaciei-mobl1>
	<180642004.20160721102059@programist.ru>
	<AM4PR0201MB2131882844D7450ED35146B998090@AM4PR0201MB2131.eurprd02.prod.outlook.com>
	<CAHtcb0ycscGRYqmnLwsGfoTWVq8dBpkab8qoZoDh0xGJKS_MgQ@mail.gmail.com>
	<03B99D59-476B-48DB-8C3B-717E6D0173C5@woboq.com>
	<38899413.20160721143155@programist.ru>
	<AM4PR0201MB1905939750E4B3551F323E3788090@AM4PR0201MB1905.eurprd02.prod.outlook.com>
Message-ID: <1916290805.20160721170542@programist.ru>

Hello, Everyone.

>> If "Fix Version" is filled by Yoann Lopes 6 months ago then he will get
>> this estimation and can decide to hire Woboq or someone else to fix or
>> whatever.

> This is an unreasonable expectation to place on developers. For
> blockers (which, as far as I understand, this was not), yes, the fix
> version is most likely going to be known, but for many bugs, it's
> extremely difficult to know when they will be fixed. Things happen,
> priorities change. Also, there are always lots of bugs waiting to be fixed. It's a huge product.

Agree with you if this field was unchangeable once it was set (nobody knows the future exactly ... ).
But this field is CHANGEBLE! So Fix Version SHOULD NOT BE KNOWN. It is how maintainer see planning of it currently.

If you maintain something you know best about plans. So share your estimation! (this field is here for a reason).
You know tasks, you visit meetings there plans are discussed, you communicate with other who involved ... you
know situation with module better then others ... so why not share your vision in this simple field?

Moreover this field can be used to better support prioritization for maintainer plans.
Bugs with same priority but lower Fix Version have higher priority. So actually beneficial for maintainers too.


Moreover there are other 2 fields which also need to be set. And not filling them give instability for the bug too.
Do not want instability in feedback ... make bug's state stable. Easy!



From szehowe.koh at gmail.com  Thu Jul 21 16:35:56 2016
From: szehowe.koh at gmail.com (Sze Howe Koh)
Date: Thu, 21 Jul 2016 22:35:56 +0800
Subject: [Development] Stack Overflow Documentation
In-Reply-To: <AM4PR0201MB190503BFF091E89C2A77046B88090@AM4PR0201MB1905.eurprd02.prod.outlook.com>
References: <AM4PR0201MB190503BFF091E89C2A77046B88090@AM4PR0201MB1905.eurprd02.prod.outlook.com>
Message-ID: <CALW8pfUpsL7bmX5PThZB1cw05XW+Vg7Fp250mhKwfNUSThEbVw@mail.gmail.com>

On 21 July 2016 at 19:04, Mitch Curtis <mitch.curtis at qt.io> wrote:
> Hello.
>
> Stack Overflow Documentation is now in Beta. You can read more about it here:
>
> http://stackoverflow.com/tour/documentation
>
> It is much more accessible than our contribution system, so I see a lot of documentation/example contributions going there instead of to Gerrit.
>
> I also wonder if we should consider the popularity (i.e upvotes) of the pages there when we decide which examples to create and add to our documentation.

That makes sense to me. Another similar metric is how often a question
gets asked at our forum, although this is a bit hard to count.


> I wonder if the licensing is such that the frameworks like Qt can benefit from the content by "upstreaming" it into their own documentation.

According to your link, Stack Overflow Documentation contributions are
licensed the same way as regular Stack Overflow, i.e. CC BY-SA 3.0.
We'll need a legal expert's input to be sure, but from what I
understand we can't relicense CC BY-SA 3.0 material under GFDL 1.3...

(Perhaps we can ask Stack Overflow for an exception?)


> I'm interested to hear what others think about this.


Regards,
Sze-Howe


From mitch.curtis at qt.io  Thu Jul 21 16:38:54 2016
From: mitch.curtis at qt.io (Mitch Curtis)
Date: Thu, 21 Jul 2016 14:38:54 +0000
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <1916290805.20160721170542@programist.ru>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>
	<HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>
	<8fa890de-7145-4fe0-bfd3-b600faf8bd2a@gmail.com>
	<1652868.Lj3xVX6QOI@tjmaciei-mobl1>	<180642004.20160721102059@programist.ru>
	<AM4PR0201MB2131882844D7450ED35146B998090@AM4PR0201MB2131.eurprd02.prod.outlook.com>
	<CAHtcb0ycscGRYqmnLwsGfoTWVq8dBpkab8qoZoDh0xGJKS_MgQ@mail.gmail.com>
	<03B99D59-476B-48DB-8C3B-717E6D0173C5@woboq.com>
	<38899413.20160721143155@programist.ru>
	<AM4PR0201MB1905939750E4B3551F323E3788090@AM4PR0201MB1905.eurprd02.prod.outlook.com>
	<1916290805.20160721170542@programist.ru>
Message-ID: <AM4PR0201MB190523B18A83E238CAEAFEDA88090@AM4PR0201MB1905.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-
> project.org] On Behalf Of Prav
> Sent: Thursday, 21 July 2016 4:06 PM
> To: development at qt-project.org
> Subject: Re: [Development] [QtMultimedia] Still is supported, active?
> 
> Hello, Everyone.
> 
> >> If "Fix Version" is filled by Yoann Lopes 6 months ago then he will
> >> get this estimation and can decide to hire Woboq or someone else to
> >> fix or whatever.
> 
> > This is an unreasonable expectation to place on developers. For
> > blockers (which, as far as I understand, this was not), yes, the fix
> > version is most likely going to be known, but for many bugs, it's
> > extremely difficult to know when they will be fixed. Things happen,
> > priorities change. Also, there are always lots of bugs waiting to be
> fixed. It's a huge product.
> 
> Agree with you if this field was unchangeable once it was set (nobody
> knows the future exactly ... ).
> But this field is CHANGEBLE! So Fix Version SHOULD NOT BE KNOWN. It is how
> maintainer see planning of it currently.

It sure is changeable, and we do change it... when:

1) It's a blocker and it has to be fixed by a certain version.
2) The bug is fixed.

Read this thread:

http://lists.qt-project.org/pipermail/development/2015-November/023847.html

The conclusion from the chief maintainer was:

> I think this makes most sense. The old way where we had a Fix Version set for open bugs is at the minimum confusing to users. Usually it's worse, because it creates false expectations. Setting a Fix Version on an open bug is somewhat of a commitment by us that we will do what we can to get that bug fixed for this version. And that's more the exception than the rule, ie. It makes the bug a showstopper for that release.

Which implies that if anything, we'd create a separate field for estimated fix dates, if we ended up doing that at all. Being an estimated fix date, and given everything that has already been said so far, this field will never be close to accurate enough to be relied upon. This defeats the purpose of it for situations where someone actually wants to contribute a fix and is (for some reason) relying on it to know whether they can begin working on it, rather than just taking action and contacting the responsible developer. And if it's not useful in that scenario, when would it be useful?

That is to say, P1s and P0s will (hopefully) always get fixed quickly, but anything beyond that depends on a huge factor of things. There's no useful estimate that can be given unless the set of bugs is tiny. Even if estimates could be given for some specific bugs, there's no guarantee it would be for the ones that Denis is interested in, and so you'd still end up with people being wished away to hell... and I think we can both agree that hell is not a productive working environment.

> If you maintain something you know best about plans. So share your
> estimation! (this field is here for a reason).

Nope, that's not what it's for.

> You know tasks, you visit meetings there plans are discussed, you
> communicate with other who involved ... you know situation with module
> better then others ... so why not share your vision in this simple field?

See above.

> Moreover this field can be used to better support prioritization for
> maintainer plans.

I don't see how this changes anything. The maintainer already has an overview over the priority of bugs. As always, people will disagree with that priority, and, as always, they'll get told the same things they're being told by others in this thread.
 
> Bugs with same priority but lower Fix Version have higher priority. So
> actually beneficial for maintainers too.
> 
> 
> Moreover there are other 2 fields which also need to be set. And not
> filling them give instability for the bug too.
> Do not want instability in feedback ... make bug's state stable. Easy!
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From robin+qt at viroteck.net  Thu Jul 21 16:41:27 2016
From: robin+qt at viroteck.net (Robin Burchell)
Date: Thu, 21 Jul 2016 16:41:27 +0200
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <1916290805.20160721170542@programist.ru>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>
	<HE1PR02MB1433AB09E2EC3AADE6888DD597080@HE1PR02MB1433.eurprd02.prod.outlook.com>
	<8fa890de-7145-4fe0-bfd3-b600faf8bd2a@gmail.com>
	<1652868.Lj3xVX6QOI@tjmaciei-mobl1>
	<180642004.20160721102059@programist.ru>
	<AM4PR0201MB2131882844D7450ED35146B998090@AM4PR0201MB2131.eurprd02.prod.outlook.com>
	<CAHtcb0ycscGRYqmnLwsGfoTWVq8dBpkab8qoZoDh0xGJKS_MgQ@mail.gmail.com>
	<03B99D59-476B-48DB-8C3B-717E6D0173C5@woboq.com>
	<38899413.20160721143155@programist.ru>
	<AM4PR0201MB1905939750E4B3551F323E3788090@AM4PR0201MB1905.eurprd02.prod.outlook.com>
	<1916290805.20160721170542@programist.ru>
Message-ID: <1469112087.3437835.672829761.59400B6F@webmail.messagingengine.com>

On Thu, Jul 21, 2016, at 04:05 PM, Prav wrote:
> Agree with you if this field was unchangeable once it was set (nobody
> knows the future exactly ... ).
> But this field is CHANGEBLE! So Fix Version SHOULD NOT BE KNOWN. It is
> how maintainer see planning of it currently.

Looking at my current world of choice: QtQuick (not QML, & not Controls)
currently has - roughly - 385 open bugs. Three maintainers (Shawn &
myself for QtQuick, Gunnar for scenegraph parts) - one of which works on
Qt full time - plus a number of assorted contributors (in and outside
the Qt Company) who all have their own priorities, wants, needs, and
desires.

The very nature of an open source project is that the resources that it
has are unreliable. Outside of the core of people paid to work on it,
there is no predictability about how much effort people are able to put
in, let alone the completely unpredictable nature of software estimates,
which is a widely known problem: I expect you've heard of it before so I
won't go into it. And of the core of people paid to work on it, they
have their priorities set based on a number of different variables:
things they want to work on, things they are paid to work on, feature
work vs bugs (and then: paid customers vs not, etc).

On top of that, many bugs can't be estimated just by looking at the
report. It requires knowledge of the code to find a fix, to understand
possible implications and side-effects, testing, etc. I'm the first
person to tell you that I don't have a clue how long a number of the
bugs filed on QtQuick will take to fix right now, simply because I don't
have an immediate understanding of what the problem actually is.

I've rambled a bit here, but the point that I'm trying to make is: even
if I *wanted* to, I couldn't try plan all 385 of those into something
sensible, even if I was willing to spend all of the time that I spend
looking at code/bugs/reviews on the meta-work that you're proposing
(planning with all of those people) here. And that's just for one small
part of Qt.

Long story short, I don't see that happening. I don't think it's
actually written down or formalised anywhere, but AFAIK, fix version
tends to only be set on bugs that are actually fixed, to indicate which
version the fix is going to land in, or on high priority blockers.

-- 
  Robin Burchell
  robin at viroteck.net


From andre at familiesomers.nl  Thu Jul 21 16:54:55 2016
From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=)
Date: Thu, 21 Jul 2016 16:54:55 +0200
Subject: [Development] Stack Overflow Documentation
In-Reply-To: <CALW8pfUpsL7bmX5PThZB1cw05XW+Vg7Fp250mhKwfNUSThEbVw@mail.gmail.com>
References: <AM4PR0201MB190503BFF091E89C2A77046B88090@AM4PR0201MB1905.eurprd02.prod.outlook.com>
	<CALW8pfUpsL7bmX5PThZB1cw05XW+Vg7Fp250mhKwfNUSThEbVw@mail.gmail.com>
Message-ID: <10893c7c-a7d4-3620-41c2-0e94de13012b@familiesomers.nl>



Op 21/07/2016 om 16:35 schreef Sze Howe Koh:
> On 21 July 2016 at 19:04, Mitch Curtis <mitch.curtis at qt.io> wrote:
>> Hello.
>>
>> Stack Overflow Documentation is now in Beta. You can read more about it here:
>>
>> http://stackoverflow.com/tour/documentation
>>
>> It is much more accessible than our contribution system, so I see a lot of documentation/example contributions going there instead of to Gerrit.
>>
>> I also wonder if we should consider the popularity (i.e upvotes) of the pages there when we decide which examples to create and add to our documentation.
> That makes sense to me. Another similar metric is how often a question
> gets asked at our forum, although this is a bit hard to count.
>
>
>> I wonder if the licensing is such that the frameworks like Qt can benefit from the content by "upstreaming" it into their own documentation.
> According to your link, Stack Overflow Documentation contributions are
> licensed the same way as regular Stack Overflow, i.e. CC BY-SA 3.0.
> We'll need a legal expert's input to be sure, but from what I
> understand we can't relicense CC BY-SA 3.0 material under GFDL 1.3...
>
> (Perhaps we can ask Stack Overflow for an exception?)
>
>
>> I'm interested to hear what others think about this.
>
I still think the removal of the documentation annotation feature that 
was on the online documentation a year or two ago is regrettable 
mistake. Instead of extending the feature by  making it more 
fine-grained, be able to integrate it into documentation viewer. There 
was good content there, and it was discouraging for the members of the 
community who had been contributing to it to see it just being removed 
instead of used.

André



From thiago.macieira at intel.com  Thu Jul 21 17:56:23 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 21 Jul 2016 08:56:23 -0700
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <180642004.20160721102059@programist.ru>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>
	<1652868.Lj3xVX6QOI@tjmaciei-mobl1>
	<180642004.20160721102059@programist.ru>
Message-ID: <2452152.LGnUjzhAUd@tjmaciei-mobl1>

On quinta-feira, 21 de julho de 2016 10:20:59 PDT Prav wrote:
> Hello, Everyone.
> 
> > Bugs are fixed when they are fixed. You won't get any estimate before the
> > developer actually starts fixing the issue. And even then, it may take
> > months or more until it actually gets fixed.
> 
> Agree but devil is in details. Currently there is a practice to not fill-out
> necessary fields for the bugs and not to change its status. I exactly mean
> * Not changing from Reported to Opened (or Need Info or Closed) ... like it
> is with discussed QTBUG-53019 (1/2 year old) 

Bugs should be triaged, which means they should go to Opened, Need Info or 
Closed in a timely basis. This is a mistake and should be corrected.

> * Not assigning responsible person in Assignee field like it is for ex. with 
> QTBUG-46812 (1 year old) 

Assignee is only important when the bug is being worked on. If no one is 
working on it, Unassigned is fine.

> * Not assigning Fix Version/s ... which can mean there is no plans for the
> bug. No plans can be because of 3 reasons:
>         I do not care and going to silently ignore the bug
>           OR
>         I agree with the bug but have so many bugs to fix already so that
> this is to far from my 1 month plan (or 3 month plan or 1 year plan ...
> nobody knows what plan is meant) OR
>         I except the bug but do not want to bother myself with filling this
> field about my plans

Or, the actual case, which is neither: "Fix version" is assigned when the fix 
is committed to that particular version and the issue moves to Closed. "Fix 
version" is not used for wishes, but for actual fact.

> This is probably means that we need some easy to use query in bug-tracker
> system which can show up "unprocessed bugs" ... which is bugs with state
> Reported
> OR
>   no Assignee
> OR
>   no Fix version
> With sorting from oldest creation date to newest.

Just the first counts as "untriaged".

> If Yoann Lopes will fill the bugs fields why in the world would Denis
> Shienkov ever wrote this letter. Never. Because attitude to the bug will be
> clear to him.

Or, like I've just proven, people can misunderstand intentions and might still 
have complained. If the bug had been accepted (status Opened) but no work done 
in one year, I can bet there would still be complaining now.

> And Denis can only live with this (like trying to fix himself, or hire
> someone or stick to Qt 5.5.1 forever or whatever else)

This option is open to you right now. Why are we spending time discussing the 
issue report attributes instead of fixing the issue?

> I IMHO see Denis Shienkov's personal attacks to Yoann Lopes quite reasonable

Personal attacks ARE NEVER REASONABLE.

I'm going to repeat myself: PERSONAL ATTACKS ARE COMPLETELY UNACCEPTABLE.

You can and should frankly discuss technical issues. You can argue why a 
commit should be different, why a bug deserves a different priority and you 
can argue that someone should dedicate more time to a given task.

However, I don't care how much you may hate someone for any perceived or real 
insult, work or lack of work. YOU NEVER ATTACK PERSONALLY. That's entirely 
unacceptable under the Qt Project governance rules and any governance rules of 
any project I participate in and especially helped create. I only know of one 
notable exception that permits personal attacks and almost everyone I know 
(except the involved ones) think it's a bad idea to permit it.

> And I totally agree that "Bugs are fixed when they are fixed". And agree
> that maintainers need to respect Best Practices of working with
> bug-tracking ALSO (which exactly mean filling out ALL these 3 fields ...
> they ALL are important).

Except that our practice is not to set those fields. The only field that could 
have been set in this particular case is the Status: the bug should have been 
triaged and then transitioned from Reported to Opened.

> Can Qt Product Managers arise the importance of Best Practices of working
> with bugs-tracker for developers?

We already have. I remember discussing this in one of the Contributor Summits. 
It should be in the wiki somewhere.

> Can someone create this query inside bug-tracker system and share it with
> everyone so that unprocessed bugs can be shown?

Everyone can. It's easy with JIRA. Takes a couple of clicks to find all bugs 
that are in Reported state and needs to be triaged. Takes a couple of other 
clicks to find all Open bugs (verified to be issues) and thus any developer can 
take ownership of and start working.

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



From thiago.macieira at intel.com  Thu Jul 21 17:58:29 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 21 Jul 2016 08:58:29 -0700
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <38899413.20160721143155@programist.ru>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>
	<03B99D59-476B-48DB-8C3B-717E6D0173C5@woboq.com>
	<38899413.20160721143155@programist.ru>
Message-ID: <2185740.VTgKT4znHk@tjmaciei-mobl1>

On quinta-feira, 21 de julho de 2016 14:31:55 PDT Prav wrote:
> Here is also one important detail. If Denis need to decide to hire someone
> he need information about plans of fixing the bug. If he need to wait 1/2
> year to get estimation that this bug is not going to be fixed in nearest
> months this can make him piss off. Easy imaginable!

He doesn't need to wait. If the bug is not actively being worked on right now, 
anyone can simply take ownership and begin working on it. I'm sure others 
would be delighted to have less work.

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



From thiago.macieira at intel.com  Thu Jul 21 17:59:12 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 21 Jul 2016 08:59:12 -0700
Subject: [Development] [QtMultimedia] Still is supported, active?
In-Reply-To: <1916290805.20160721170542@programist.ru>
References: <bdbac24e-6183-1238-7e95-14a938bce69b@gmail.com>
	<AM4PR0201MB1905939750E4B3551F323E3788090@AM4PR0201MB1905.eurprd02.prod.outlook.com>
	<1916290805.20160721170542@programist.ru>
Message-ID: <3036869.ZDjKSNeru9@tjmaciei-mobl1>

On quinta-feira, 21 de julho de 2016 17:05:42 PDT Prav wrote:
> But this field is CHANGEBLE! So Fix Version SHOULD NOT BE KNOWN. It is how
> maintainer see planning of it currently.

That is not how we use the bug tracker, as I've explained. The rest of your 
email is not relevant.

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



From thiago.macieira at intel.com  Thu Jul 21 18:01:59 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 21 Jul 2016 09:01:59 -0700
Subject: [Development] qtbase-opensource-src-5.6.1-1.tar.xz
In-Reply-To: <alpine.LNX.2.00.1607211518030.5250@calcifer.valdyas.org>
References: <alpine.LNX.2.00.1607211518030.5250@calcifer.valdyas.org>
Message-ID: <22676739.5hB3QksqQr@tjmaciei-mobl1>

On quinta-feira, 21 de julho de 2016 15:19:38 PDT Boudewijn Rempt wrote:
> I just found that qtbase-opensource-src-5.6.1-1.tar.xz
> unpacks to qtbase-opensource-src-5.6.1, which completely
> breaks any automated system like mxe (mxe.cc) which depends
> on the foldername being the same tarball name.
> 
> Was this intentional, or just an oversight?

It's an oversight because the whole 5.6.1-1 release was rushed, done without 
proper procedures.

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



From thiago.macieira at intel.com  Thu Jul 21 18:27:58 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 21 Jul 2016 09:27:58 -0700
Subject: [Development] Remember to rebuild qmake in dev
Message-ID: <1860018.tsR3b8YFqq@tjmaciei-mobl1>

Hello

moc.prf with MSVC now depends on a side feature in qmake to help support 
generating the moc_predefs.h file. If you're using MSVC, please remember to 
recompile qmake soon.

This does not affect GCC (any OS) or the Intel compiler (any OS), as both 
support the "dump macros" hidden feature. I have tested Clang but I did not 
test clang-cl.  

If clang-cl does not support compatibility with cl's -Bx argument, please edit 
moc.prf line 34 and submit a patch.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From mitch.curtis at qt.io  Thu Jul 21 20:02:51 2016
From: mitch.curtis at qt.io (Mitch Curtis)
Date: Thu, 21 Jul 2016 18:02:51 +0000
Subject: [Development] Remember to rebuild qmake in dev
In-Reply-To: <1860018.tsR3b8YFqq@tjmaciei-mobl1>
References: <1860018.tsR3b8YFqq@tjmaciei-mobl1>
Message-ID: <AM4PR0201MB1905D9B1C25214F1805E9C4788090@AM4PR0201MB1905.eurprd02.prod.outlook.com>

It's probably worth pointing out what kind of errors we can expect should we forget (so that we can recognise the problem).

________________________________________
From: Development <development-bounces+mitch.curtis=qt.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Thursday, 21 July 2016 6:27:58 PM
To: development at qt-project.org
Subject: [Development] Remember to rebuild qmake in dev

Hello

moc.prf with MSVC now depends on a side feature in qmake to help support
generating the moc_predefs.h file. If you're using MSVC, please remember to
recompile qmake soon.

This does not affect GCC (any OS) or the Intel compiler (any OS), as both
support the "dump macros" hidden feature. I have tested Clang but I did not
test clang-cl.

If clang-cl does not support compatibility with cl's -Bx argument, please edit
moc.prf line 34 and submit a patch.
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From oswald.buddenhagen at qt.io  Thu Jul 21 20:23:19 2016
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Thu, 21 Jul 2016 20:23:19 +0200
Subject: [Development] Remember to rebuild qmake in dev
In-Reply-To: <1860018.tsR3b8YFqq@tjmaciei-mobl1>
References: <1860018.tsR3b8YFqq@tjmaciei-mobl1>
Message-ID: <20160721182319.GA6475@troll08>

On Thu, Jul 21, 2016 at 09:27:58AM -0700, Thiago Macieira wrote:
> moc.prf with MSVC now depends on a side feature in qmake to help support 
> generating the moc_predefs.h file. If you're using MSVC, please remember to 
> recompile qmake soon.
> 
a much better recommendation is "run config.status (or configure -redo
on windows) *every time* after pulling". this ensures that qmake is
rebuilt, and possible adjustments to the configuration are done.
it takes about half a minute (soon much quicker, as we're about to
finally add chaching), and if nothing actually changes, it won't have
any impact on the subsequent rebuild.

this requirement certainly seems a bit arbitrary, but it's an inevitable
consequence of the qmake bootstrapping.


From pr12og2 at programist.ru  Thu Jul 21 22:11:28 2016
From: pr12og2 at programist.ru (Prav)
Date: Thu, 21 Jul 2016 23:11:28 +0300
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <2352511.zGkT0Kkulc@tjmaciei-mobl1>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io> 
	<AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>
	<313158393.20160720130303@programist.ru>
	<2352511.zGkT0Kkulc@tjmaciei-mobl1>
Message-ID: <357613386.20160721231128@programist.ru>

Hello, Everyone and Thiago.

>> SVG icons are not shown at all in static builds of Qt, but png icons are
>> fine (both icons are taken from resorse file). Static and shred Qt 5.6.1
>> build were done with same config settings except of cause "static".

> Remember to force the inclusion of the svg icon plugin into your application.

This seems a valuable advise which worked for me. I finally found how to do this, In pro-file add:
QTPLUGIN *= qsvg


Without this svg icons just do not render SILENTLY (in "static").



From thiago.macieira at intel.com  Thu Jul 21 22:50:41 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 21 Jul 2016 13:50:41 -0700
Subject: [Development] Remember to rebuild qmake in dev
In-Reply-To: <AM4PR0201MB1905D9B1C25214F1805E9C4788090@AM4PR0201MB1905.eurprd02.prod.outlook.com>
References: <1860018.tsR3b8YFqq@tjmaciei-mobl1>
	<AM4PR0201MB1905D9B1C25214F1805E9C4788090@AM4PR0201MB1905.eurprd02.prod.outlook.com>
Message-ID: <1692930.XtpH1gv5N8@tjmaciei-mobl1>

On quinta-feira, 21 de julho de 2016 18:02:51 PDT Mitch Curtis wrote:
> It's probably worth pointing out what kind of errors we can expect should we
> forget (so that we can recognise the problem).

The moc_predefs.h file contains qmake's help output, as opposed to a valid C 
source file. Since that file is consumed by moc itself, you're going to get moc 
parsing errors.

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



From thiago.macieira at intel.com  Thu Jul 21 23:54:17 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 21 Jul 2016 14:54:17 -0700
Subject: [Development] Remember to rebuild qmake in dev
In-Reply-To: <20160721182319.GA6475@troll08>
References: <1860018.tsR3b8YFqq@tjmaciei-mobl1> <20160721182319.GA6475@troll08>
Message-ID: <4768672.9btQ58TZ2Q@tjmaciei-mobl1>

On quinta-feira, 21 de julho de 2016 20:23:19 PDT Oswald Buddenhagen wrote:
> On Thu, Jul 21, 2016 at 09:27:58AM -0700, Thiago Macieira wrote:
> > moc.prf with MSVC now depends on a side feature in qmake to help support
> > generating the moc_predefs.h file. If you're using MSVC, please remember
> > to
> > recompile qmake soon.
> 
> a much better recommendation is "run config.status (or configure -redo
> on windows) *every time* after pulling". this ensures that qmake is

configure -redo on Windows doesn't work at all on a shadow build:

On one run:
Unable to detect the platform from environment. Use -platform command line
argument or set the QMAKESPEC environment variable and run configure again.
See the README file for a list of supported operating systems and compilers.

On another:
Invalid option "win32-icc" for -platform.
See the README file for a list of supported operating systems and compilers

To redo the configuration, I have to use:

cmd \ /c $QTSRCDIR/configure -redo

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



From Kai.Koehne at qt.io  Fri Jul 22 08:19:02 2016
From: Kai.Koehne at qt.io (Kai Koehne)
Date: Fri, 22 Jul 2016 06:19:02 +0000
Subject: [Development] Remember to rebuild qmake in dev
In-Reply-To: <1692930.XtpH1gv5N8@tjmaciei-mobl1>
References: <1860018.tsR3b8YFqq@tjmaciei-mobl1>
	<AM4PR0201MB1905D9B1C25214F1805E9C4788090@AM4PR0201MB1905.eurprd02.prod.outlook.com>
	<1692930.XtpH1gv5N8@tjmaciei-mobl1>
Message-ID: <AM4PR0201MB2131AB4C5174ED87116FAA0C980A0@AM4PR0201MB2131.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-bounces+kai.koehne=qt.io at qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: Thursday, July 21, 2016 10:51 PM
> To: development at qt-project.org
> Subject: Re: [Development] Remember to rebuild qmake in dev
> 
> On quinta-feira, 21 de julho de 2016 18:02:51 PDT Mitch Curtis wrote:
> > It's probably worth pointing out what kind of errors we can expect
> > should we forget (so that we can recognise the problem).
> 
> The moc_predefs.h file contains qmake's help output, as opposed to a valid C
> source file. Since that file is consumed by moc itself, you're going to get moc
> parsing errors.

Actually the qmake call already returns with an error code, so what you see is just something like

jom: D:\dev\qt\dev\msvc-2015-32\qtbase\src\testlib\Makefile.Debug [.moc\debug\moc_predefs.h] Error 2

with no previous error message.

Been there, done that :)

Kai

From oswald.buddenhagen at qt.io  Fri Jul 22 09:25:11 2016
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Fri, 22 Jul 2016 09:25:11 +0200
Subject: [Development] Remember to rebuild qmake in dev
In-Reply-To: <4768672.9btQ58TZ2Q@tjmaciei-mobl1>
References: <1860018.tsR3b8YFqq@tjmaciei-mobl1> <20160721182319.GA6475@troll08>
	<4768672.9btQ58TZ2Q@tjmaciei-mobl1>
Message-ID: <20160722072511.GA9753@troll08>

On Thu, Jul 21, 2016 at 02:54:17PM -0700, Thiago Macieira wrote:
> On quinta-feira, 21 de julho de 2016 20:23:19 PDT Oswald Buddenhagen wrote:
> > On Thu, Jul 21, 2016 at 09:27:58AM -0700, Thiago Macieira wrote:
> > > moc.prf with MSVC now depends on a side feature in qmake to help support
> > > generating the moc_predefs.h file. If you're using MSVC, please remember
> > > to
> > > recompile qmake soon.
> > 
> > a much better recommendation is "run config.status (or configure -redo
> > on windows) *every time* after pulling". this ensures that qmake is
> 
> configure -redo on Windows doesn't work at all on a shadow build:
> 
> On one run:
> Unable to detect the platform from environment. Use -platform command line
> argument or set the QMAKESPEC environment variable and run configure again.
> See the README file for a list of supported operating systems and compilers.
> 
> On another:
> Invalid option "win32-icc" for -platform.
> See the README file for a list of supported operating systems and compilers
> 
> To redo the configuration, I have to use:
> 
> cmd \ /c $QTSRCDIR/configure -redo
> 
not sure what the cmd stuff is supposed to be good for, but it's correct
that you *always* need to run the configure from the source dir (i.e.,
the .bat file if you're building from git).

(which is why i'm actually considering generating a config.status.bat
file on windows.)


From thiago.macieira at intel.com  Fri Jul 22 17:28:47 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 22 Jul 2016 08:28:47 -0700
Subject: [Development] Remember to rebuild qmake in dev
In-Reply-To: <20160722072511.GA9753@troll08>
References: <1860018.tsR3b8YFqq@tjmaciei-mobl1>
	<4768672.9btQ58TZ2Q@tjmaciei-mobl1> <20160722072511.GA9753@troll08>
Message-ID: <1634602.o9d77hU1Ez@tjmaciei-mobl1>

On sexta-feira, 22 de julho de 2016 09:25:11 PDT Oswald Buddenhagen wrote:
> > To redo the configuration, I have to use:
> > 
> > cmd \ /c $QTSRCDIR/configure -redo
> 
> not sure what the cmd stuff is supposed to be good for, but it's correct
> that you *always* need to run the configure from the source dir (i.e.,
> the .bat file if you're building from git).

sh.exe can't run .bat files. You need to ask cmd to do it for you.

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



From thiago.macieira at intel.com  Fri Jul 22 22:25:19 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 22 Jul 2016 13:25:19 -0700
Subject: [Development] Programs crashing left and right in the CI
Message-ID: <2608077.ZIMrPSxkf7@tjmaciei-mobl1>

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            = C0000005
  ExceptionFlags           = 00000000
  ExceptionAddress         = 00007FF64939415B (00007FF649370000) "C:\Program 
Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\link.exe"
  NumberParameters         = 00000002
  ExceptionInformation[ 0] = 0000000000000000
  ExceptionInformation[ 1] = 000000020226BDF8

Can someone check whether there are memory problems in some of the CI 
machines?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From vviktor2 at gmail.com  Sun Jul 24 08:28:15 2016
From: vviktor2 at gmail.com (=?UTF-8?Q?Vereb=C3=A9lyi_Viktor?=)
Date: Sun, 24 Jul 2016 07:28:15 +0100
Subject: [Development] Are there any limitations on implementing the
 changing of the screen for a QWindow on systems using EGLFS?
Message-ID: <CAGpMZc3r6Z7vq=D379RMqSSqtWqKMFQc=wQ3u10F7nP3xhBsCQ@mail.gmail.com>

I looked at the code for the EGLFS BRCM integration and the screen it uses
is hard-coded. After trying some test code for Dispmanx it seems that it is
fairly straight forward to change the screen it uses.

My question is: Are there any limitations to implementing the functions
that would allow us to change the screen using QWindows->setScreen()?

The reason for why I'm asking is, because I'd like to implement this, but
I'd like to know whether if this is not implemented beacuse of some
limitations or because of lack of intrest/contributors?


-- 
- Viktor Verebelyi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160724/e79fc55e/attachment.html>

From jedrzej.nowacki at qt.io  Mon Jul 25 12:04:26 2016
From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki)
Date: Mon, 25 Jul 2016 12:04:26 +0200
Subject: [Development] Why is QVariant::data() \internal?
In-Reply-To: <2220871.eUmBLObRF3@maurice>
References: <2363391.iQtkevNy5N@zaphod> <1837442.4ddaBHsu6c@zaphod>
	<2220871.eUmBLObRF3@maurice>
Message-ID: <34175160.frTBlXYi3K@42>

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


 


From jedrzej.nowacki at qt.io  Mon Jul 25 14:07:04 2016
From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki)
Date: Mon, 25 Jul 2016 14:07:04 +0200
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <2608077.ZIMrPSxkf7@tjmaciei-mobl1>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1>
Message-ID: <5951295.MVm6SEVxWd@42>

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            = C0000005
>   ExceptionFlags           = 00000000
>   ExceptionAddress         = 00007FF64939415B (00007FF649370000) "C:\Program
> Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\link.exe"
>   NumberParameters         = 00000002
>   ExceptionInformation[ 0] = 0000000000000000
>   ExceptionInformation[ 1] = 000000020226BDF8
> 
> 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



From thiago.macieira at intel.com  Mon Jul 25 17:51:36 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 25 Jul 2016 08:51:36 -0700
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <5951295.MVm6SEVxWd@42>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1> <5951295.MVm6SEVxWd@42>
Message-ID: <10723215.7zoGWthJmd@tjmaciei-mobl1>

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.

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



From thiago.macieira at intel.com  Mon Jul 25 19:27:30 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 25 Jul 2016 10:27:30 -0700
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <10723215.7zoGWthJmd@tjmaciei-mobl1>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1> <5951295.MVm6SEVxWd@42>
	<10723215.7zoGWthJmd@tjmaciei-mobl1>
Message-ID: <1722326.r6PVoyhCB5@tjmaciei-mobl1>

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: 0x00007FF8DB7367B4
 Exception code   : 0xc0000005
 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() - 0x00007FF8DEC08CD0
 #  2: UnhandledExceptionFilter() - 0x00007FF8E4001AD0
 #  3: TpDbgDumpHeapUsage() - 0x00007FF8E6D01BE0
 #  4: TpDbgDumpHeapUsage() - 0x00007FF8E6D01BE0
 #  5: memset() - 0x00007FF8E6C95140
 #  6: _C_specific_handler() - 0x00007FF8E6C82800
 #  7: wcstok_s() - 0x00007FF8E6C8D8C0
 #  8: _chkstk() - 0x00007FF8E6C93E70
 #  9: RtlRaiseException() - 0x00007FF8E6C53920
 # 10: KiUserExceptionDispatcher() - 0x00007FF8E6C93060
 # 11: DllUnregisterServer() - 0x00007FF8DB7097B0
 # 12: DllUnregisterServer() - 0x00007FF8DB7097B0
 # 13: DllUnregisterServer() - 0x00007FF8DB7097B0
 # 14: DllGetActivationFactory() - 0x00007FF8DC9D1860
 # 15: DllGetActivationFactory() - 0x00007FF8DC9D1860
 # 16: DllGetActivationFactory() - 0x00007FF8DC9D1860
 # 17: DllGetActivationFactory() - 0x00007FF8DC9D1860
 # 18: DllGetActivationFactory() - 0x00007FF8DC9D1860
 # 19: SwMemFree() - 0x00007FF8E3E29770
 # 20: SwMemFree() - 0x00007FF8E3E29770
 # 21: QueryProtectedPolicy() - 0x00007FF8E3F45C80
 # 22: RtlGetActiveActivationContext() - 0x00007FF8E6C1C6B0
 # 23: RtlFreeUnicodeString() - 0x00007FF8E6C37100
 # 24: BaseThreadInitThunk() - 0x00007FF8E44B13B0
 # 25: RtlUserThreadStart() - 0x00007FF8E6C15410

http://testresults.qt.io/coin/integration/qt/qtbase/tasks/
1469463068.thrift_bin
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From swarit.wipra at gmail.com  Tue Jul 26 05:55:53 2016
From: swarit.wipra at gmail.com (swarit wipra)
Date: Tue, 26 Jul 2016 09:25:53 +0530
Subject: [Development] Error in running Qt3D app
Message-ID: <CAMNhMCjdFs5QP=y3puvDjogO=318i7Bpc+fPmMAGT4XH3G1xaA@mail.gmail.com>

Hi,
I am getting following error, when running Qt 3d app.

05-19 19:26:06.857 17339 17339 W libClimateHMI.so: (null):0 ((null)): Can't
find surface 2
05-19 19:26:06.869   221   628 D AudioFlinger: mixer(0xab962fb0) throttle
end: throttle time(3)
05-19 19:26:06.877 17339 17339 W libClimateHMI.so: (null):0 ((null)): Can't
find surface 2
05-19 19:26:47.118   221   628 D audio_hw_primary: out_set_parameters:
enter: usecase(0: playback) kvpairs: routing=2 out->devices(2) adev->mode(0)
05-19 19:26:47.169 17339 17434 E libEGL  : call to OpenGL ES API with no
current context (logged once per thread)
05-19 19:26:47.248 17339 17339 I System.out: ClimateServiceIFClient :
onPause
05-19 19:26:47.248 17339 17339 D libClimateHMI.so: (null):0 ((null)):
ClimateHmiIF :  NotifyOnPause  ---  0xf7452b34
05-19 19:26:47.248 17339 17339 D libClimateHMI.so: (null):0 ((null)):
UIClimateNotification :  NotifyOnPause  ---  0xf7452b34
05-19 19:26:47.290 17339 17405 W art     : Native thread exiting without
having called DetachCurrentThread (maybe it's going to use a
pthread_key_create destructor?):
Thread[10,tid=17405,Native,Thread*=0xab7c3548,peer=0x12d330a0,"QtThread"]

Please guide me to fix it.
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160726/d2af3b98/attachment.html>

From jedrzej.nowacki at qt.io  Tue Jul 26 11:22:04 2016
From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki)
Date: Tue, 26 Jul 2016 11:22:04 +0200
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <1722326.r6PVoyhCB5@tjmaciei-mobl1>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1>
	<10723215.7zoGWthJmd@tjmaciei-mobl1>
	<1722326.r6PVoyhCB5@tjmaciei-mobl1>
Message-ID: <8962629.AlkaZky8x8@42>

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: 0x00007FF8DB7367B4
>  Exception code   : 0xc0000005
>  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() - 0x00007FF8DEC08CD0
>  #  2: UnhandledExceptionFilter() - 0x00007FF8E4001AD0
>  #  3: TpDbgDumpHeapUsage() - 0x00007FF8E6D01BE0
>  #  4: TpDbgDumpHeapUsage() - 0x00007FF8E6D01BE0
>  #  5: memset() - 0x00007FF8E6C95140
>  #  6: _C_specific_handler() - 0x00007FF8E6C82800
>  #  7: wcstok_s() - 0x00007FF8E6C8D8C0
>  #  8: _chkstk() - 0x00007FF8E6C93E70
>  #  9: RtlRaiseException() - 0x00007FF8E6C53920
>  # 10: KiUserExceptionDispatcher() - 0x00007FF8E6C93060
>  # 11: DllUnregisterServer() - 0x00007FF8DB7097B0
>  # 12: DllUnregisterServer() - 0x00007FF8DB7097B0
>  # 13: DllUnregisterServer() - 0x00007FF8DB7097B0
>  # 14: DllGetActivationFactory() - 0x00007FF8DC9D1860
>  # 15: DllGetActivationFactory() - 0x00007FF8DC9D1860
>  # 16: DllGetActivationFactory() - 0x00007FF8DC9D1860
>  # 17: DllGetActivationFactory() - 0x00007FF8DC9D1860
>  # 18: DllGetActivationFactory() - 0x00007FF8DC9D1860
>  # 19: SwMemFree() - 0x00007FF8E3E29770
>  # 20: SwMemFree() - 0x00007FF8E3E29770
>  # 21: QueryProtectedPolicy() - 0x00007FF8E3F45C80
>  # 22: RtlGetActiveActivationContext() - 0x00007FF8E6C1C6B0
>  # 23: RtlFreeUnicodeString() - 0x00007FF8E6C37100
>  # 24: BaseThreadInitThunk() - 0x00007FF8E44B13B0
>  # 25: RtlUserThreadStart() - 0x00007FF8E6C15410
> 
> 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.




From s at dragly.com  Tue Jul 26 13:33:36 2016
From: s at dragly.com (Svenn-Arne Dragly)
Date: Tue, 26 Jul 2016 13:33:36 +0200
Subject: [Development] Error in running Qt3D app
In-Reply-To: <CAMNhMCjdFs5QP=y3puvDjogO=318i7Bpc+fPmMAGT4XH3G1xaA@mail.gmail.com>
References: <CAMNhMCjdFs5QP=y3puvDjogO=318i7Bpc+fPmMAGT4XH3G1xaA@mail.gmail.com>
Message-ID: <4556724d-5f4d-50d0-eecd-2df9d0343eb0@dragly.com>

Hi,

Are you trying to run the example on Android? If so, try to make a 
simple Qt3D example with a QML Scene3D object, like this: 
https://doc.qt.io/qt-5/qt3d-scene3d-example.html

I have had some trouble with running the other Qt3D examples on Android, 
but I have not seen the same error message as you got. It has often 
helped to run it through a Scene3D object, however. This is of course 
only a long term solution if you are working on a QML project. But, 
testing the example will give you a good indication of whether Qt3D in 
general works on your device or not. If not, there might be some issue 
with getting access to an OpenGL context on your device. Then I would 
try to find a simple OpenGL example for Android in Java just to check.


Cheers,

Svenn-Arne

On 26. juli 2016 05:55, swarit wipra wrote:
> Hi,
> I am getting following error, when running Qt 3d app.
>
> 05-19 19:26:06.857 17339 17339 W libClimateHMI.so: (null):0 ((null)): 
> Can't find surface 2
> 05-19 19:26:06.869   221   628 D AudioFlinger: mixer(0xab962fb0) 
> throttle end: throttle time(3)
> 05-19 19:26:06.877 17339 17339 W libClimateHMI.so: (null):0 ((null)): 
> Can't find surface 2
> 05-19 19:26:47.118   221   628 D audio_hw_primary: out_set_parameters: 
> enter: usecase(0: playback) kvpairs: routing=2 out->devices(2) 
> adev->mode(0)
> 05-19 19:26:47.169 17339 17434 E libEGL  : call to OpenGL ES API with 
> no current context (logged once per thread)
> 05-19 19:26:47.248 17339 17339 I System.out: ClimateServiceIFClient : 
> onPause
> 05-19 19:26:47.248 17339 17339 D libClimateHMI.so: (null):0 ((null)): 
> ClimateHmiIF :  NotifyOnPause  ---  0xf7452b34
> 05-19 19:26:47.248 17339 17339 D libClimateHMI.so: (null):0 ((null)): 
> UIClimateNotification :  NotifyOnPause  --- 0xf7452b34
> 05-19 19:26:47.290 17339 17405 W art     : Native thread exiting 
> without having called DetachCurrentThread (maybe it's going to use a 
> pthread_key_create destructor?): 
> Thread[10,tid=17405,Native,Thread*=0xab7c3548,peer=0x12d330a0,"QtThread"]
>
> Please guide me to fix it.
> Best Regards
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160726/ab2e75f8/attachment.html>

From denis.shienkov at gmail.com  Tue Jul 26 13:41:25 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Tue, 26 Jul 2016 14:41:25 +0300
Subject: [Development] Commits: Is it possible to add a missed "default"
 parameters of methods?
Message-ID: <CAHtcb0wMB3hupwgYbG3uWR+tsyxCR7OjiwkLoWHdpEnoz+PpLQ@mail.gmail.com>

Hi all, Thiago.

Seems, we (I'am) have missed default parameters for the waitFor() methods
of QSerialPort:

* https://codereview.qt-project.org/#/c/165583/

So, my questions:

1. Is it possible just to add of a missed default params and to merge it?
2. If yes, then, what of a branch is makes sense?

BR,
Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160726/4193a2b1/attachment.html>

From marc.mutz at kdab.com  Tue Jul 26 13:51:19 2016
From: marc.mutz at kdab.com (Marc Mutz)
Date: Tue, 26 Jul 2016 14:51:19 +0300
Subject: [Development] Commits: Is it possible to add a missed "default"
 parameters of methods?
In-Reply-To: <CAHtcb0wMB3hupwgYbG3uWR+tsyxCR7OjiwkLoWHdpEnoz+PpLQ@mail.gmail.com>
References: <CAHtcb0wMB3hupwgYbG3uWR+tsyxCR7OjiwkLoWHdpEnoz+PpLQ@mail.gmail.com>
Message-ID: <201607261451.21476.marc.mutz@kdab.com>

On Tuesday 26 July 2016 14:41:25 Denis Shienkov wrote:
> Hi all, Thiago.
> 
> Seems, we (I'am) have missed default parameters for the waitFor() methods
> of QSerialPort:
> 
> * https://codereview.qt-project.org/#/c/165583/
> 
> So, my questions:
> 
> 1. Is it possible just to add of a missed default params and to merge it?

Yes. It's forward- and backwards-BC and backwards-SC.

> 2. If yes, then, what of a branch is makes sense?

dev, since it's not forward-SC (a call omitting the defaulted argument will 
not compile on a version without the default argument).

> BR,
> Denis

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts


From denis.shienkov at gmail.com  Tue Jul 26 14:04:58 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Tue, 26 Jul 2016 15:04:58 +0300
Subject: [Development] Commits: Is it possible to add a missed "default"
 parameters of methods?
In-Reply-To: <201607261451.21476.marc.mutz@kdab.com>
References: <CAHtcb0wMB3hupwgYbG3uWR+tsyxCR7OjiwkLoWHdpEnoz+PpLQ@mail.gmail.com>
	<201607261451.21476.marc.mutz@kdab.com>
Message-ID: <CAHtcb0z4-CYnrdNo=pCYE-Qqmy24-SKXd1+XERZQqjY-W6_ghA@mail.gmail.com>

Ok, many thanks.

2016-07-26 14:51 GMT+03:00 Marc Mutz <marc.mutz at kdab.com>:

> On Tuesday 26 July 2016 14:41:25 Denis Shienkov wrote:
> > Hi all, Thiago.
> >
> > Seems, we (I'am) have missed default parameters for the waitFor() methods
> > of QSerialPort:
> >
> > * https://codereview.qt-project.org/#/c/165583/
> >
> > So, my questions:
> >
> > 1. Is it possible just to add of a missed default params and to merge it?
>
> Yes. It's forward- and backwards-BC and backwards-SC.
>
> > 2. If yes, then, what of a branch is makes sense?
>
> dev, since it's not forward-SC (a call omitting the defaulted argument will
> not compile on a version without the default argument).
>
> > BR,
> > Denis
>
> --
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - Qt, C++ and OpenGL Experts
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160726/337e1c86/attachment.html>

From laszlo.agocs at qt.io  Tue Jul 26 15:33:38 2016
From: laszlo.agocs at qt.io (Laszlo Agocs)
Date: Tue, 26 Jul 2016 13:33:38 +0000
Subject: [Development] Are there any limitations on implementing the
 changing of the screen for a QWindow on systems using EGLFS?
In-Reply-To: <CAGpMZc3r6Z7vq=D379RMqSSqtWqKMFQc=wQ3u10F7nP3xhBsCQ@mail.gmail.com>
References: <CAGpMZc3r6Z7vq=D379RMqSSqtWqKMFQc=wQ3u10F7nP3xhBsCQ@mail.gmail.com>
Message-ID: <DB5PR0201MB200759FB3297937B023CB969870E0@DB5PR0201MB2007.eurprd02.prod.outlook.com>

Lack of contributions and suitable hardware setup. There was a patch for making the target screen configurable via an environment variable which never made it to integration. We are now reviving it for 5.6 at https://codereview.qt-project.org/#/c/166117/


Additional patches for discovering and exposing all available screens as separate QScreens are welcome. Not entirely sure about the feasibility, especially when it comes to discovering and monitoring the connected outputs, but it is definitely worth a try.


Best regards,

Laszlo


<https://codereview.qt-project.org/#/c/166117/>

________________________________
From: Development <development-bounces+laszlo.agocs=qt.io at qt-project.org> on behalf of Verebélyi Viktor <vviktor2 at gmail.com>
Sent: Sunday, July 24, 2016 8:28:15 AM
To: development at qt-project.org
Subject: [Development] Are there any limitations on implementing the changing of the screen for a QWindow on systems using EGLFS?


I looked at the code for the EGLFS BRCM integration and the screen it uses is hard-coded. After trying some test code for Dispmanx it seems that it is fairly straight forward to change the screen it uses.

My question is: Are there any limitations to implementing the functions that would allow us to change the screen using QWindows->setScreen()?

The reason for why I'm asking is, because I'd like to implement this, but I'd like to know whether if this is not implemented beacuse of some limitations or because of lack of intrest/contributors?


--
- Viktor Verebelyi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160726/331f6a15/attachment.html>

From dominik.holland at pelagicore.com  Tue Jul 26 16:00:16 2016
From: dominik.holland at pelagicore.com (Dominik Holland)
Date: Tue, 26 Jul 2016 16:00:16 +0200
Subject: [Development] Are there any limitations on implementing the
 changing of the screen for a QWindow on systems using EGLFS?
In-Reply-To: <DB5PR0201MB200759FB3297937B023CB969870E0@DB5PR0201MB2007.eurprd02.prod.outlook.com>
References: <CAGpMZc3r6Z7vq=D379RMqSSqtWqKMFQc=wQ3u10F7nP3xhBsCQ@mail.gmail.com>
	<DB5PR0201MB200759FB3297937B023CB969870E0@DB5PR0201MB2007.eurprd02.prod.outlook.com>
Message-ID: <01c34190-7c50-97fc-9b76-40215de8d654@pelagicore.com>

Hi,

Am 07/26/2016 um 03:33 PM schrieb Laszlo Agocs:
> Lack of contributions and suitable hardware setup. There was a patch for
> making the target screen configurable via an environment variable which
> never made it to integration. We are now reviving it for 5.6 at
> https://codereview.qt-project.org/#/c/166117/
> 

Can't we do something similar to QT_QPA_EGLFS_KMS_CONFIG and share the
json file setup here as well ? This would make it way more consistent.

Dominik

> 
> Additional patches for discovering and exposing all available screens as
> separate QScreens are welcome. Not entirely sure about the feasibility,
> especially when it comes to discovering and monitoring the connected
> outputs, but it is definitely worth a try.
> 
> 
> Best regards,
> 
> Laszlo
> 
> 
> <https://codereview.qt-project.org/#/c/166117/>
> 
> ------------------------------------------------------------------------
> *From:* Development
> <development-bounces+laszlo.agocs=qt.io at qt-project.org> on behalf of
> Verebélyi Viktor <vviktor2 at gmail.com>
> *Sent:* Sunday, July 24, 2016 8:28:15 AM
> *To:* development at qt-project.org
> *Subject:* [Development] Are there any limitations on implementing the
> changing of the screen for a QWindow on systems using EGLFS?
>  
> 
> I looked at the code for the EGLFS BRCM integration and the screen it
> uses is hard-coded. After trying some test code for Dispmanx it seems
> that it is fairly straight forward to change the screen it uses.
> 
> My question is: Are there any limitations to implementing the functions
> that would allow us to change the screen using QWindows->setScreen()?
> 
> The reason for why I'm asking is, because I'd like to implement this,
> but I'd like to know whether if this is not implemented beacuse of some
> limitations or because of lack of intrest/contributors?
> 
> 
> 
> -- 
> - Viktor Verebelyi
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 

-- 
Dominik Holland
SENIOR SOFTWARE ENGINEER

Pelagicore AG
Balanstr. 55, 81541 Munich, Germany
+49 (0)171 760 25 96
dominik.holland at pelagicore.com
www.pelagicore.com



From and.bernabei at gmail.com  Tue Jul 26 16:12:08 2016
From: and.bernabei at gmail.com (Andrea Bernabei)
Date: Tue, 26 Jul 2016 15:12:08 +0100
Subject: [Development] Proposal: change QML Flickable's flickableDirection
 default value to AutoFlickIfNeeded in 5.8
Message-ID: <CAJkYZaTkogHEXKr2eBMhmr1EX04mFugav+tAN+LizjxDvRnX2w@mail.gmail.com>

Hello everyone,

I'd like to propose changing the default value of QML Flickable's
flickableDirection in Qt 5.8.

The current default value is Flickable.AutoFlickDirection
The description is: it "allows flicking vertically if the *contentHeight*
is not equal to the *height* of the Flickable. Allows flicking horizontally
if the *contentWidth* is not equal to the *width* of the Flickable."

It seems to me like the current default was chosen to make it so that the
surface is always draggable except for things like vertical ListViews
(where contentWidth==width, or the same for height in the case of
horizontal lists).

I propose we should change the default value to Flickable.AutoFlickIfNeeded
(added by Shawn, Flickable's maintainer, in 5.7
https://codereview.qt-project.org/#/c/150388/ ).

I'll try using bullet points to avoid a wall of text.

Proposal:
Change default Flickable's flickableDirection to AutoFlickIfNeeded in
Qt5.8, and only available when importing QtQuick >= 2.8

Why:
The current behaviour is a bit confusing. If we only take the horizontal
dimension into account:
- content narrower than Flickable --> content IS draggable (why?)
- content same size as Flickable --> content NOT draggable
- content wider than Flickable      --> content IS draggable

While with the proposed change:
- content narrower than Flickable --> content NOT draggable
- content same size as Flickable --> content NOT draggable
- content wider than Flickable      --> content IS draggable

I believe the new behaviour is better, the content is only draggable when
dragging "makes sense", i.e. when dragging would reveal additional content
that would otherwise be hidden.

What do you guys think?

Cheers,
Andrea (faenil)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160726/891b7c4d/attachment.html>

From laszlo.agocs at qt.io  Tue Jul 26 16:22:30 2016
From: laszlo.agocs at qt.io (Laszlo Agocs)
Date: Tue, 26 Jul 2016 14:22:30 +0000
Subject: [Development] Are there any limitations on implementing the
 changing of the screen for a QWindow on systems using EGLFS?
In-Reply-To: <01c34190-7c50-97fc-9b76-40215de8d654@pelagicore.com>
References: <CAGpMZc3r6Z7vq=D379RMqSSqtWqKMFQc=wQ3u10F7nP3xhBsCQ@mail.gmail.com>
	<DB5PR0201MB200759FB3297937B023CB969870E0@DB5PR0201MB2007.eurprd02.prod.outlook.com>,
	<01c34190-7c50-97fc-9b76-40215de8d654@pelagicore.com>
Message-ID: <DB5PR0201MB200790D9FD9C68E9BB7F57CC870E0@DB5PR0201MB2007.eurprd02.prod.outlook.com>


Sure, you could add something like that on top once the basic multiple QScreen support is in place. (for HDMI at least, replicating more or less what 'tvservice' does. Not sure what (if any) API you have for other type of displays, though.)

Laszlo

________________________________
From: Development <development-bounces+laszlo.agocs=qt.io at qt-project.org> on behalf of Dominik Holland <dominik.holland at pelagicore.com>
Sent: Tuesday, July 26, 2016 4:00 PM
To: development at qt-project.org
Subject: Re: [Development] Are there any limitations on implementing the changing of the screen for a QWindow on systems using EGLFS?

Hi,

Am 07/26/2016 um 03:33 PM schrieb Laszlo Agocs:
> Lack of contributions and suitable hardware setup. There was a patch for
> making the target screen configurable via an environment variable which
> never made it to integration. We are now reviving it for 5.6 at
> https://codereview.qt-project.org/#/c/166117/
>

Can't we do something similar to QT_QPA_EGLFS_KMS_CONFIG and share the
json file setup here as well ? This would make it way more consistent.

Dominik

>
> Additional patches for discovering and exposing all available screens as
> separate QScreens are welcome. Not entirely sure about the feasibility,
> especially when it comes to discovering and monitoring the connected
> outputs, but it is definitely worth a try.
>
>
> Best regards,
>
> Laszlo
>
>
> <https://codereview.qt-project.org/#/c/166117/>
>
> ------------------------------------------------------------------------
> *From:* Development
> <development-bounces+laszlo.agocs=qt.io at qt-project.org> on behalf of
> Verebélyi Viktor <vviktor2 at gmail.com>
> *Sent:* Sunday, July 24, 2016 8:28:15 AM
> *To:* development at qt-project.org
> *Subject:* [Development] Are there any limitations on implementing the
> changing of the screen for a QWindow on systems using EGLFS?
>
>
> I looked at the code for the EGLFS BRCM integration and the screen it
> uses is hard-coded. After trying some test code for Dispmanx it seems
> that it is fairly straight forward to change the screen it uses.
>
> My question is: Are there any limitations to implementing the functions
> that would allow us to change the screen using QWindows->setScreen()?
>
> The reason for why I'm asking is, because I'd like to implement this,
> but I'd like to know whether if this is not implemented beacuse of some
> limitations or because of lack of intrest/contributors?
>
>
>
> --
> - Viktor Verebelyi
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

--
Dominik Holland
SENIOR SOFTWARE ENGINEER

Pelagicore AG
Balanstr. 55, 81541 Munich, Germany
+49 (0)171 760 25 96
dominik.holland at pelagicore.com
www.pelagicore.com<http://www.pelagicore.com>

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160726/53eecb69/attachment.html>

From bogdan at kdab.com  Tue Jul 26 16:50:38 2016
From: bogdan at kdab.com (BogDan Vatra)
Date: Tue, 26 Jul 2016 17:50:38 +0300
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML ?
Message-ID: <30621599.Di3TuLGYCH@debian>

Hi,

Is there any reason why C++11 scoped enums are not scoped in QML ?
If I have something like the following code in C++

class MyClass : public QObject
{
 Q_OBJECT
public:
 enum class MyEnum : uint16_t {
   Val1,
   Val2,
 }
 Q_ENUM(MyEnum)
);

// register the class 

I'd like to use it in QML as:
console.log(MyClass.MyEnum.Val1)
not as 
console.log(MyClass.Val1)

Cheers,
BogDan.


From Simon.Hausmann at qt.io  Tue Jul 26 16:54:46 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Tue, 26 Jul 2016 14:54:46 +0000
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML
 ?
In-Reply-To: <30621599.Di3TuLGYCH@debian>
References: <30621599.Di3TuLGYCH@debian>
Message-ID: <DB4PR02MB054158F85B2F88F800B21A288C0E0@DB4PR02MB0541.eurprd02.prod.outlook.com>

Hi,


By the time this aspect of the QML engine was implemented, C++11 scoped enums did not exist. I think it would be fine

to add this feature to the JavaScript bindings for C++ classes.


Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of BogDan Vatra <bogdan at kdab.com>
Sent: Tuesday, July 26, 2016 4:50:38 PM
To: development at qt-project.org
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML ?

Hi,

Is there any reason why C++11 scoped enums are not scoped in QML ?
If I have something like the following code in C++

class MyClass : public QObject
{
 Q_OBJECT
public:
 enum class MyEnum : uint16_t {
   Val1,
   Val2,
 }
 Q_ENUM(MyEnum)
);

// register the class

I'd like to use it in QML as:
console.log(MyClass.MyEnum.Val1)
not as
console.log(MyClass.Val1)

Cheers,
BogDan.
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160726/404c6eea/attachment.html>

From bogdan at kdab.com  Tue Jul 26 17:00:50 2016
From: bogdan at kdab.com (BogDan Vatra)
Date: Tue, 26 Jul 2016 18:00:50 +0300
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML
 ?
In-Reply-To: <DB4PR02MB054158F85B2F88F800B21A288C0E0@DB4PR02MB0541.eurprd02.prod.outlook.com>
References: <30621599.Di3TuLGYCH@debian>
	<DB4PR02MB054158F85B2F88F800B21A288C0E0@DB4PR02MB0541.eurprd02.prod.outlook.com>
Message-ID: <16897410.OI9fUgkcjY@debian>

Hi,

Thanks for the super quick reply !

I created a bug report for you here https://bugreports.qt.io/browse/
QTBUG-54961 .

Cheers,
BogDan.

On marți, 26 iulie 2016 14:54:46 EEST Simon Hausmann wrote:
> Hi,
> 
> 
> By the time this aspect of the QML engine was implemented, C++11 scoped
> enums did not exist. I think it would be fine
> 
> to add this feature to the JavaScript bindings for C++ classes.
> 
> 
> Simon
> 
> ________________________________
> From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org>
> on behalf of BogDan Vatra <bogdan at kdab.com> Sent: Tuesday, July 26, 2016
> 4:50:38 PM
> To: development at qt-project.org
> Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML ?
> 
> Hi,
> 
> Is there any reason why C++11 scoped enums are not scoped in QML ?
> If I have something like the following code in C++
> 
> class MyClass : public QObject
> {
>  Q_OBJECT
> public:
>  enum class MyEnum : uint16_t {
>    Val1,
>    Val2,
>  }
>  Q_ENUM(MyEnum)
> );
> 
> // register the class
> 
> I'd like to use it in QML as:
> console.log(MyClass.MyEnum.Val1)
> not as
> console.log(MyClass.Val1)
> 
> Cheers,
> BogDan.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development




From bogdan at kdab.com  Tue Jul 26 17:18:48 2016
From: bogdan at kdab.com (BogDan Vatra)
Date: Tue, 26 Jul 2016 18:18:48 +0300
Subject: [Development] [QML]: Register global enums/flags to QML ?
Message-ID: <1610394.huzr6IiSWS@debian>

Hello,

I'd like to be able to register some "global" enums/flags to QML. I checked a 
little bit how Qt does with all the enums from Qt namespace (qnamespace.h) and 
I end-up in qqmlbuiltinfunctions which does all the "magic" which can't be 
used by normal developers/libs.

Because I think having "global" enums is a very nice feature, I'd like to know 
if other people and QML maintainers agree with me :). 
If yes, then want to propose the followings:
 - add one more Q_OBJECT/Q_GADGET like macro for namespaces (Q_NAMESPACE?), 
which declares the mandatory "extern const QMetaObject staticMetaObject" ( or 
just "extern const QMetaEnum  staticMetaEnum" ? because in principle we'll 
only be able to declare enums/flags ?) into that namespace. Most probably moc 
will need some love to properly handle the new Q_magic_macro. If is too much 
trouble we can use the qnamespace.h hack.

 - add a helper macro/function to register the namespace enums/flags (i.e. 
qmlRegisterNamespace or even better qmlRegisterEnums(const QMetaEnum 
&staticMetaEnum, ....). 

I think it depends on QML c++11 scoped enums task, because most probably the 
enums enumerators names will clash.

Cheers,
BogDan.



From thiago.macieira at intel.com  Tue Jul 26 17:28:28 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 26 Jul 2016 08:28:28 -0700
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <8962629.AlkaZky8x8@42>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1>
	<1722326.r6PVoyhCB5@tjmaciei-mobl1> <8962629.AlkaZky8x8@42>
Message-ID: <3902504.djodUWfD60@tjmaciei-mobl1>

Em terça-feira, 26 de julho de 2016, às 11:22:04 PDT, Jędrzej Nowacki 
escreveu:
> > # 11: DllUnregisterServer() - 0x00007FF8DB7097B0
> > # 12: DllUnregisterServer() - 0x00007FF8DB7097B0
> > # 13: DllUnregisterServer() - 0x00007FF8DB7097B0
> > # 14: DllGetActivationFactory() - 0x00007FF8DC9D1860
> > # 15: DllGetActivationFactory() - 0x00007FF8DC9D1860
> > # 16: DllGetActivationFactory() - 0x00007FF8DC9D1860
> > # 17: DllGetActivationFactory() - 0x00007FF8DC9D1860
> > # 18: DllGetActivationFactory() - 0x00007FF8DC9D1860
> > # 19: SwMemFree() - 0x00007FF8E3E29770
> > # 20: SwMemFree() - 0x00007FF8E3E29770
> > # 21: QueryProtectedPolicy() - 0x00007FF8E3F45C80
> > # 22: RtlGetActiveActivationContext() - 0x00007FF8E6C1C6B0
> > # 23: RtlFreeUnicodeString() - 0x00007FF8E6C37100
> > # 24: BaseThreadInitThunk() - 0x00007FF8E44B13B0
> > # 25: RtlUserThreadStart() - 0x00007FF8E6C15410
> > 
> > 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*.

I'm not sure this one is Qt's fault. It seems to crash completely inside 
Windows code. tst_QDir doesn't start any threads, but it's possible that 
Windows itself does to accomplish some task.

It's also possible that the Windows code is simply recovering, and that 
QTest::toString is actually causing the crash. In other words, it's possible 
the code that deals with crashes in QtTest is causing the crash.

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



From bogdan at kdab.com  Tue Jul 26 17:28:35 2016
From: bogdan at kdab.com (BogDan Vatra)
Date: Tue, 26 Jul 2016 18:28:35 +0300
Subject: [Development] [QML]: Why can't create Q_GADGETs from QML ?
Message-ID: <1768132.ztWhMOdFS9@debian>

Hi,

Is there any reason why I can only use Q_GADGETs objects in QML, but not to 
create them?

It will be nice if we can register Q_GADGETs  as qml creatable types too.

Cheers,
BogDan.


From thiago.macieira at intel.com  Tue Jul 26 17:33:31 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 26 Jul 2016 08:33:31 -0700
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML
 ?
In-Reply-To: <30621599.Di3TuLGYCH@debian>
References: <30621599.Di3TuLGYCH@debian>
Message-ID: <3892193.gsOItmPEK2@tjmaciei-mobl1>

Em terça-feira, 26 de julho de 2016, às 17:50:38 PDT, BogDan Vatra escreveu:
> Hi,
> 
> Is there any reason why C++11 scoped enums are not scoped in QML ?

There's no trait to tell apart a scoped enum from an unscoped one. An enum is 
en enum, that's all.

If you want a given enum to be scoped in QML, it should be a QML engine 
feature and should be available to any C++ enum, whether it's scoped or not.

> If I have something like the following code in C++
> 
[cut]
>  Q_ENUM(MyEnum)

This is all the engine sees. It's an enum.

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



From Simon.Hausmann at qt.io  Tue Jul 26 17:37:04 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Tue, 26 Jul 2016 15:37:04 +0000
Subject: [Development] [QML]: Why can't create Q_GADGETs from QML ?
In-Reply-To: <1768132.ztWhMOdFS9@debian>
References: <1768132.ztWhMOdFS9@debian>
Message-ID: <DB4PR02MB0541F37247E2E53D1ADF950E8C0E0@DB4PR02MB0541.eurprd02.prod.outlook.com>

Hi,


No objection per-se, but we'd have to figure out some details. For example declarative instantiation is

not an object, as the ownership rules do not comply with QObject. That would leave us with a JavaScript

constructor function, replacing Qt.point(...) for example. But then we'd have to comply with the namespace

rules, so we'd have


    qmlRegisterGadget<MyGadget>("MyModule", "ThatName", 1, 0);


and then


    import MyModule 1.0


and in expressions we'd have


    var g = new ThatName();


and the same for a namespaced import:


    import MyModule 1.0 as Foo


    var g = new Foo.ThatName();


It's a bit of work to do, but I don't see a problem in principle.


Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of BogDan Vatra <bogdan at kdab.com>
Sent: Tuesday, July 26, 2016 5:28:35 PM
To: development at qt-project.org
Subject: [Development] [QML]: Why can't create Q_GADGETs from QML ?

Hi,

Is there any reason why I can only use Q_GADGETs objects in QML, but not to
create them?

It will be nice if we can register Q_GADGETs  as qml creatable types too.

Cheers,
BogDan.
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160726/2085db10/attachment.html>

From dangelog at gmail.com  Tue Jul 26 17:41:01 2016
From: dangelog at gmail.com (Giuseppe D'Angelo)
Date: Tue, 26 Jul 2016 17:41:01 +0200
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML
 ?
In-Reply-To: <3892193.gsOItmPEK2@tjmaciei-mobl1>
References: <30621599.Di3TuLGYCH@debian> <3892193.gsOItmPEK2@tjmaciei-mobl1>
Message-ID: <CAPm+cviNZm5h_Zqgq4CcLN9ogZMxu9NPSLK_-TmhD7vZhb9x_g@mail.gmail.com>

On Tue, Jul 26, 2016 at 5:33 PM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> This is all the engine sees. It's an enum.

But moc might help in this, extracting the relevant information
alongside the enum's metadata.

Also if std::is_enum<E>::value is true and std::is_convertible<E,
typename std::underlying_type<T>::type>::value is false, then the enum
is scoped. (Surely in C++something this might break if user-provided
conversions get allowed, but for now it's enough).

My 2 c,

-- 
Giuseppe D'Angelo


From thiago.macieira at intel.com  Tue Jul 26 18:35:58 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 26 Jul 2016 09:35:58 -0700
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML?
In-Reply-To: <CAPm+cviNZm5h_Zqgq4CcLN9ogZMxu9NPSLK_-TmhD7vZhb9x_g@mail.gmail.com>
References: <30621599.Di3TuLGYCH@debian> <3892193.gsOItmPEK2@tjmaciei-mobl1>
	<CAPm+cviNZm5h_Zqgq4CcLN9ogZMxu9NPSLK_-TmhD7vZhb9x_g@mail.gmail.com>
Message-ID: <489854821.OQxReSnndV@tjmaciei-mobl1>

Em terça-feira, 26 de julho de 2016, às 17:41:01 PDT, Giuseppe D'Angelo 
escreveu:
> On Tue, Jul 26, 2016 at 5:33 PM, Thiago Macieira
> 
> <thiago.macieira at intel.com> wrote:
> > This is all the engine sees. It's an enum.
> 
> But moc might help in this, extracting the relevant information
> alongside the enum's metadata.
> 
> Also if std::is_enum<E>::value is true and std::is_convertible<E,
> typename std::underlying_type<T>::type>::value is false, then the enum
> is scoped. (Surely in C++something this might break if user-provided
> conversions get allowed, but for now it's enough).

I'd still say this should be an opt-in feature for the QML engine that should 
not be required to depend on the type of C++ enum used to back it.

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



From bogdan at kdab.com  Tue Jul 26 19:08:30 2016
From: bogdan at kdab.com (BogDan Vatra)
Date: Tue, 26 Jul 2016 20:08:30 +0300
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML?
In-Reply-To: <3892193.gsOItmPEK2@tjmaciei-mobl1>
References: <30621599.Di3TuLGYCH@debian> <3892193.gsOItmPEK2@tjmaciei-mobl1>
Message-ID: <3579105.DXyiqcnOYR@debian>

On marți, 26 iulie 2016 08:33:31 EEST Thiago Macieira wrote:
> Em terça-feira, 26 de julho de 2016, às 17:50:38 PDT, BogDan Vatra escreveu:
> > Hi,
> > 
> > Is there any reason why C++11 scoped enums are not scoped in QML ?
> 
> There's no trait to tell apart a scoped enum from an unscoped one. An enum
> is en enum, that's all.
> 

scoped enums are declared differenty : enum *class* MyEnum :) 
Even more, scoped enums in C++ must me used with fully qualified name *MyEnum a 
= MyEnum.Val1* not *MyEnum a = Val1*, so a scoped enum is not exacly an enum 
:)

> If you want a given enum to be scoped in QML, it should be a QML engine
> feature and should be available to any C++ enum, whether it's scoped or not.

> > If I have something like the following code in C++
> 
> [cut]
> 
> >  Q_ENUM(MyEnum)
> 
> This is all the engine sees. It's an enum.

Well, that's all the *moc* sees and I'm pretty sure it knows also the *class* 
keyword, otherwise it can't skip it properly...

Cheers,
BogDan.



From nassian at bitshift-dynamics.de  Tue Jul 26 19:42:17 2016
From: nassian at bitshift-dynamics.de (Alexander Nassian)
Date: Tue, 26 Jul 2016 19:42:17 +0200
Subject: [Development] Proposal: change QML Flickable's
 flickableDirection default value to AutoFlickIfNeeded in 5.8
In-Reply-To: <CAJkYZaTkogHEXKr2eBMhmr1EX04mFugav+tAN+LizjxDvRnX2w@mail.gmail.com>
References: <CAJkYZaTkogHEXKr2eBMhmr1EX04mFugav+tAN+LizjxDvRnX2w@mail.gmail.com>
Message-ID: <4BBA4A96-401D-490B-9759-9A1F054A5C17@bitshift-dynamics.de>

Hi Andrea,

Good proposal! But one little hint: The current behavior is not that confusing as you describe. On iOS and OS X for example the current behavior is normal.


Beste Grüße / Best regards,
Alexander Nassian
http://www.bitshift-dynamics.de

> Am 26.07.2016 um 16:12 schrieb Andrea Bernabei <and.bernabei at gmail.com>:
> 
> Hello everyone,
> 
> I'd like to propose changing the default value of QML Flickable's flickableDirection in Qt 5.8.
> 
> The current default value is Flickable.AutoFlickDirection
> The description is: it "allows flicking vertically if the contentHeight is not equal to the height of the Flickable. Allows flicking horizontally if the contentWidth is not equal to the width of the Flickable."
> 
> It seems to me like the current default was chosen to make it so that the surface is always draggable except for things like vertical ListViews (where contentWidth==width, or the same for height in the case of horizontal lists).
> 
> I propose we should change the default value to Flickable.AutoFlickIfNeeded (added by Shawn, Flickable's maintainer, in 5.7 https://codereview.qt-project.org/#/c/150388/ ).
> 
> I'll try using bullet points to avoid a wall of text.
> 
> Proposal:
> Change default Flickable's flickableDirection to AutoFlickIfNeeded in Qt5.8, and only available when importing QtQuick >= 2.8
> 
> Why:
> The current behaviour is a bit confusing. If we only take the horizontal dimension into account:
> - content narrower than Flickable --> content IS draggable (why?)
> - content same size as Flickable --> content NOT draggable
> - content wider than Flickable      --> content IS draggable
> 
> While with the proposed change:
> - content narrower than Flickable --> content NOT draggable
> - content same size as Flickable --> content NOT draggable
> - content wider than Flickable      --> content IS draggable
> 
> I believe the new behaviour is better, the content is only draggable when dragging "makes sense", i.e. when dragging would reveal additional content that would otherwise be hidden. 
> 
> What do you guys think? 
> 
> Cheers,
> Andrea (faenil)
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160726/45687a39/attachment.html>

From olivier at woboq.com  Tue Jul 26 20:08:52 2016
From: olivier at woboq.com (Olivier Goffart)
Date: Tue, 26 Jul 2016 20:08:52 +0200
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML?
In-Reply-To: <3892193.gsOItmPEK2@tjmaciei-mobl1>
References: <30621599.Di3TuLGYCH@debian> <3892193.gsOItmPEK2@tjmaciei-mobl1>
Message-ID: <11219652.DBPjSgSVCN@maurice>

On Dienstag, 26. Juli 2016 08:33:31 CEST Thiago Macieira wrote:
> Em terça-feira, 26 de julho de 2016, às 17:50:38 PDT, BogDan Vatra escreveu:
> > Hi,
> > 
> > Is there any reason why C++11 scoped enums are not scoped in QML ?
> 
> There's no trait to tell apart a scoped enum from an unscoped one. An enum
> is en enum, that's all.
> 
> If you want a given enum to be scoped in QML, it should be a QML engine
> feature and should be available to any C++ enum, whether it's scoped or not.
> > If I have something like the following code in C++
> 
> [cut]
> 
> >  Q_ENUM(MyEnum)
> 
> This is all the engine sees. It's an enum.


It's trivial to let QMetaEnum know about scoped enum:

https://codereview.qt-project.org/166136/


That said, it would be a behavior change not to allow anymore the previous 
(unscoped) syntax to work with QML

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org



From Stephen.Chu at mathworks.com  Tue Jul 26 20:53:20 2016
From: Stephen.Chu at mathworks.com (Stephen Chu)
Date: Tue, 26 Jul 2016 18:53:20 +0000
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<726314440.20160719115720@programist.ru>
	<F788AEB5-8EB6-4ED5-938F-3EBED66B01D5@qt.io>
	<581570494.20160720025652@programist.ru>
	<AM2PR02MB07546A0A59AFB94CB3C6ECBE87080@AM2PR02MB0754.eurprd02.prod.outlook.com>
Message-ID: <7B7BB45D-78BC-4883-88E4-D89474C95DA0@mathworks.com>



On 7/20/16, 5:12 AM, "Development on behalf of Edward Welbourne" <development-bounces+stephen.chu=mathworks.com at qt-project.org on behalf of edward.welbourne at qt.io> wrote:

>
>Then again, our SVG support is embarrassingly poor,

Especially when it doesn’t support clip path. Which I imagine will be vital for icon designs.

From and.bernabei at gmail.com  Tue Jul 26 22:44:04 2016
From: and.bernabei at gmail.com (Andrea Bernabei)
Date: Tue, 26 Jul 2016 21:44:04 +0100
Subject: [Development] Proposal: change QML Flickable's
 flickableDirection default value to AutoFlickIfNeeded in 5.8
In-Reply-To: <4BBA4A96-401D-490B-9759-9A1F054A5C17@bitshift-dynamics.de>
References: <CAJkYZaTkogHEXKr2eBMhmr1EX04mFugav+tAN+LizjxDvRnX2w@mail.gmail.com>
	<4BBA4A96-401D-490B-9759-9A1F054A5C17@bitshift-dynamics.de>
Message-ID: <CAJkYZaQanYe66cSh=rN7sbjZMLBamqusVS5d5c0PvijYYrweRw@mail.gmail.com>

2016-07-26 18:42 GMT+01:00 Alexander Nassian <nassian at bitshift-dynamics.de>:

> Hi Andrea,
>
> Good proposal! But one little hint: The current behavior is not that
> confusing as you describe. On iOS and OS X for example the current behavior
> is normal.
>
>
Thanks Alexander!

And thanks for your input, that's exactly the kind of info I'm looking for
:) Let's hear some more opinions :)


>
> Beste Grüße / Best regards,
> Alexander Nassian
> http://www.bitshift-dynamics.de
>
> Am 26.07.2016 um 16:12 schrieb Andrea Bernabei <and.bernabei at gmail.com>:
>
> Hello everyone,
>
> I'd like to propose changing the default value of QML Flickable's
> flickableDirection in Qt 5.8.
>
> The current default value is Flickable.AutoFlickDirection
> The description is: it "allows flicking vertically if the *contentHeight*
> is not equal to the *height* of the Flickable. Allows flicking
> horizontally if the *contentWidth* is not equal to the *width* of the
> Flickable."
>
> It seems to me like the current default was chosen to make it so that the
> surface is always draggable except for things like vertical ListViews
> (where contentWidth==width, or the same for height in the case of
> horizontal lists).
>
> I propose we should change the default value to
> Flickable.AutoFlickIfNeeded (added by Shawn, Flickable's maintainer, in 5.7
> https://codereview.qt-project.org/#/c/150388/ ).
>
> I'll try using bullet points to avoid a wall of text.
>
> Proposal:
> Change default Flickable's flickableDirection to AutoFlickIfNeeded in
> Qt5.8, and only available when importing QtQuick >= 2.8
>
> Why:
> The current behaviour is a bit confusing. If we only take the horizontal
> dimension into account:
> - content narrower than Flickable --> content IS draggable (why?)
> - content same size as Flickable --> content NOT draggable
> - content wider than Flickable      --> content IS draggable
>
> While with the proposed change:
> - content narrower than Flickable --> content NOT draggable
> - content same size as Flickable --> content NOT draggable
> - content wider than Flickable      --> content IS draggable
>
> I believe the new behaviour is better, the content is only draggable when
> dragging "makes sense", i.e. when dragging would reveal additional content
> that would otherwise be hidden.
>
> What do you guys think?
>
> Cheers,
> Andrea (faenil)
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160726/224e6d9d/attachment.html>

From thiago.macieira at intel.com  Tue Jul 26 23:04:29 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 26 Jul 2016 14:04:29 -0700
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML?
In-Reply-To: <3579105.DXyiqcnOYR@debian>
References: <30621599.Di3TuLGYCH@debian> <3892193.gsOItmPEK2@tjmaciei-mobl1>
	<3579105.DXyiqcnOYR@debian>
Message-ID: <1785795.qA1LLDjrBE@tjmaciei-mobl1>

Em terça-feira, 26 de julho de 2016, às 20:08:30 PDT, BogDan Vatra escreveu:
> scoped enums are declared differenty : enum *class* MyEnum :) 
> Even more, scoped enums in C++ must me used with fully qualified name
> *MyEnum a  = MyEnum.Val1* not *MyEnum a = Val1*, so a scoped enum is not
> exacly an enum
> :)

The point is that given "MyEnum", you can't tell whether it's scoped or not.

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



From dangelog at gmail.com  Tue Jul 26 23:24:21 2016
From: dangelog at gmail.com (Giuseppe D'Angelo)
Date: Tue, 26 Jul 2016 23:24:21 +0200
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <10723215.7zoGWthJmd@tjmaciei-mobl1>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1> <5951295.MVm6SEVxWd@42>
	<10723215.7zoGWthJmd@tjmaciei-mobl1>
Message-ID: <CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>

On Mon, Jul 25, 2016 at 5:51 PM, Thiago Macieira
<thiago.macieira at intel.com> 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/ddfe2ba984be5d652fe500f6695040959db98fa4/OSXOSX_10_11x86_64OSXOSX_10_11x86_64Clangqtci-osx-10.11-x86_64DebugAndRelease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz

-- 
Giuseppe D'Angelo


From fromqt at tungware.se  Tue Jul 26 23:33:03 2016
From: fromqt at tungware.se (Henry Skoglund)
Date: Tue, 26 Jul 2016 23:33:03 +0200
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1> <5951295.MVm6SEVxWd@42>
	<10723215.7zoGWthJmd@tjmaciei-mobl1>
	<CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>
Message-ID: <751ccba7-e222-ea3a-52c7-8a3540c98349@tungware.se>

Hi, most likely I've had too much coffee, but has anyone checked if 
these intermittent crashes are due to outside DDOS/some trying to 
introduce a race condition and injecting new code into Qt's codebase?

Rgrds Henry


On 2016-07-26 23:24, Giuseppe D'Angelo wrote:
> On Mon, Jul 25, 2016 at 5:51 PM, Thiago Macieira
> <thiago.macieira at intel.com> 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/ddfe2ba984be5d652fe500f6695040959db98fa4/OSXOSX_10_11x86_64OSXOSX_10_11x86_64Clangqtci-osx-10.11-x86_64DebugAndRelease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz
>




From rich at kde.org  Wed Jul 27 00:16:13 2016
From: rich at kde.org (Richard Moore)
Date: Tue, 26 Jul 2016 23:16:13 +0100
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <751ccba7-e222-ea3a-52c7-8a3540c98349@tungware.se>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1> <5951295.MVm6SEVxWd@42>
	<10723215.7zoGWthJmd@tjmaciei-mobl1>
	<CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>
	<751ccba7-e222-ea3a-52c7-8a3540c98349@tungware.se>
Message-ID: <CAMp7mVskFwdQPAME-3tz5wgfizzYjUtKSEKKQ5nDbgbJB4XJ3A@mail.gmail.com>

On 26 July 2016 at 22:33, Henry Skoglund <fromqt at tungware.se> wrote:

> Hi, most likely I've had too much coffee, but has anyone checked if these
> intermittent crashes are due to outside DDOS/some trying to introduce a
> race condition and injecting new code into Qt's codebase?
>

​The CI machines aren't internet accessible.

Cheers

Rich.
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160726/ad949d72/attachment.html>

From thiago.macieira at intel.com  Wed Jul 27 00:30:48 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 26 Jul 2016 15:30:48 -0700
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1>
	<10723215.7zoGWthJmd@tjmaciei-mobl1>
	<CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>
Message-ID: <1770814.TfGvLeZc4p@tjmaciei-mobl1>

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
> 
> <thiago.macieira at intel.com> 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/ddfe2ba984be5d652fe500f6695040959db9
> 8fa4/OSXOSX_10_11x86_64OSXOSX_10_11x86_64Clangqtci-osx-10.11-x86_64DebugAndR
> 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?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From krnekit at gmail.com  Wed Jul 27 01:49:31 2016
From: krnekit at gmail.com (Nikita Krupenko)
Date: Wed, 27 Jul 2016 02:49:31 +0300
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <F788AEB5-8EB6-4ED5-938F-3EBED66B01D5@qt.io>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<726314440.20160719115720@programist.ru>
	<F788AEB5-8EB6-4ED5-938F-3EBED66B01D5@qt.io>
Message-ID: <CAJayRjAb2NMefD7xot-SqU7ejDV4Yg81VwxXdPrEkuQru3qj5Q@mail.gmail.com>

2016-07-19 15:58 GMT+03:00 Shawn Rutledge <Shawn.Rutledge at qt.io>:
>> App should remember of couse this setting to restore it back at restart
>
> How should Qt encourage this?  So far we have QSettings, but you need to define your own setting.  And we have not made it easy to scale all fonts simultaneously, interactively.  Bindings are too cumbersome and expensive to be the universal solution.  To avoid setting the font on every individual Text item in a QtQuick app, for example, you can use QGuiApplication::setFont().  But that’s just for the default.  Maybe there should be an event of some sort when you do that at runtime, which every Text will react to, and which will then trigger the necessary layout changes.  But that would only take care of Text which uses the default font, so we need that unit support in QML (which has been discussed for years but not done yet) to be able to have a unit which represents the default font size, so that larger text could have a size 1.2x as big as the default instead of an actual point size.  Or maybe the event should be sent when you do QHighDpiScaling::setScreenFactor(), but that’s private API so far, and it’s still not clear to me which of those Qt high dpi-things are intended to affect only or mainly font sizes, and which of them demand everything to be scaled even if it will cause crappy results (scaling up pixmaps or pre-rendered widgets by non-integral ratios).  The prototype zoom-slider is in qtbase/tests/manual/highdpi, but you can see what goes wrong with that.  We need a similar test for QtQuick to see what goes wrong with dynamic scaling there.

In Material Design guidelines [1] all font sizes are in scaleable
pixels (sp). So this size could be multiplied by some factor and all
fonts should scale equally.

I think, it's worth to add the support of the font scale factor to the
Qt (enabled by something like Qt::AA_EnableFontScaling). And platform
plugin could try to get font scale factor from the OS settings and use
it by default.

[1] https://material.google.com/layout/units-measurements.html#units-measurements-scaleable-pixels-sp-


From thiago.macieira at intel.com  Wed Jul 27 03:02:07 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 26 Jul 2016 18:02:07 -0700
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <CAJayRjAb2NMefD7xot-SqU7ejDV4Yg81VwxXdPrEkuQru3qj5Q@mail.gmail.com>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<F788AEB5-8EB6-4ED5-938F-3EBED66B01D5@qt.io>
	<CAJayRjAb2NMefD7xot-SqU7ejDV4Yg81VwxXdPrEkuQru3qj5Q@mail.gmail.com>
Message-ID: <1809884.rtjrOtqX50@tjmaciei-mobl1>

Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko 
escreveu:
> In Material Design guidelines [1] all font sizes are in scaleable
> pixels (sp). So this size could be multiplied by some factor and all
> fonts should scale equally.

Maybe we should instead use a size calculated in physical units, like 1/72th 
of an inch. Oh, we have such a unit: points.

> I think, it's worth to add the support of the font scale factor to the
> Qt (enabled by something like Qt::AA_EnableFontScaling). And platform
> plugin could try to get font scale factor from the OS settings and use
> it by default.


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



From krnekit at gmail.com  Wed Jul 27 04:56:52 2016
From: krnekit at gmail.com (Nikita Krupenko)
Date: Wed, 27 Jul 2016 05:56:52 +0300
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <1809884.rtjrOtqX50@tjmaciei-mobl1>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<F788AEB5-8EB6-4ED5-938F-3EBED66B01D5@qt.io>
	<CAJayRjAb2NMefD7xot-SqU7ejDV4Yg81VwxXdPrEkuQru3qj5Q@mail.gmail.com>
	<1809884.rtjrOtqX50@tjmaciei-mobl1>
Message-ID: <CAJayRjBXm2FSfgPMN1-YLSGYWFzfh+hpwvXih60pDpxyzNrGZQ@mail.gmail.com>

2016-07-27 4:02 GMT+03:00 Thiago Macieira <thiago.macieira at intel.com>:
> Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko
> escreveu:
>> In Material Design guidelines [1] all font sizes are in scaleable
>> pixels (sp). So this size could be multiplied by some factor and all
>> fonts should scale equally.
>
> Maybe we should instead use a size calculated in physical units, like 1/72th
> of an inch. Oh, we have such a unit: points.

The idea of scaleable pixels is somewhat different: user can select
big/small fonts in the OS/application settings and font sizes would be
multiplied by some factor, for example 1.5.

BTW, why use font size in points? As other elements, like widgets,
images, etc has size in pixels, it's better to use pixels for fonts
too. Auto HiDPI scaling in Qt works for font sizes in pixels.


From thiago.macieira at intel.com  Wed Jul 27 05:21:11 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 26 Jul 2016 20:21:11 -0700
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <CAJayRjBXm2FSfgPMN1-YLSGYWFzfh+hpwvXih60pDpxyzNrGZQ@mail.gmail.com>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<1809884.rtjrOtqX50@tjmaciei-mobl1>
	<CAJayRjBXm2FSfgPMN1-YLSGYWFzfh+hpwvXih60pDpxyzNrGZQ@mail.gmail.com>
Message-ID: <2992376.j12HRIvq3a@tjmaciei-mobl1>

On quarta-feira, 27 de julho de 2016 05:56:52 PDT Nikita Krupenko wrote:
> 2016-07-27 4:02 GMT+03:00 Thiago Macieira <thiago.macieira at intel.com>:
> > Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko
> > 
> > escreveu:
> >> In Material Design guidelines [1] all font sizes are in scaleable
> >> pixels (sp). So this size could be multiplied by some factor and all
> >> fonts should scale equally.
> > 
> > Maybe we should instead use a size calculated in physical units, like
> > 1/72th of an inch. Oh, we have such a unit: points.
> 
> The idea of scaleable pixels is somewhat different: user can select
> big/small fonts in the OS/application settings and font sizes would be
> multiplied by some factor, for example 1.5.
> 
> BTW, why use font size in points? As other elements, like widgets,
> images, etc has size in pixels, it's better to use pixels for fonts
> too. Auto HiDPI scaling in Qt works for font sizes in pixels.

My point is that we already have such a unit. Instead of inventing a new one 
that didn't exist before, then use it in a context where a unit was already 
proper, why not use the proper unit for everything? Measure images in points 
too.

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



From randy.oreilly at Colorado.EDU  Wed Jul 27 05:21:48 2016
From: randy.oreilly at Colorado.EDU (Randall O'Reilly)
Date: Wed, 27 Jul 2016 03:21:48 +0000
Subject: [Development] Revisiting high-DPI configuration options
In-Reply-To: <CAJayRjBXm2FSfgPMN1-YLSGYWFzfh+hpwvXih60pDpxyzNrGZQ@mail.gmail.com>
References: <A948FD7E-AA5B-4B7B-9F30-CEDB7953CBDD@qt.io>
	<F788AEB5-8EB6-4ED5-938F-3EBED66B01D5@qt.io>
	<CAJayRjAb2NMefD7xot-SqU7ejDV4Yg81VwxXdPrEkuQru3qj5Q@mail.gmail.com>
	<1809884.rtjrOtqX50@tjmaciei-mobl1>
	<CAJayRjBXm2FSfgPMN1-YLSGYWFzfh+hpwvXih60pDpxyzNrGZQ@mail.gmail.com>
Message-ID: <71BDCBB0-B225-4BB3-939D-57B94C044978@colorado.edu>

I migrated to Qt from InterViews: http://www.ivtools.org/ivtools/doc/refman3.1/index.html  which used floating-point units that could be arbitrarily rescaled, but default to points, like many other standards (e.g., SVG, Postscript).  I always found it strange that Qt used integer pixel coords.  Seemed like a very time-limited solution even back in the day in terms of rendering to a printer vs. a screen, and anticipated increases in screen resolution which are now (finally) happening.

Seems like it might be time to do a global replace int -> float and just fix the “standard” meaning of the coordinate system in terms of points, given that it is probably pretty close to the pixel density of the “classic” displays that Qt was developed on, and it is used in these other standards, and existing apps should probably perform reasonably well with such a definition.  But internally support an arbitrary floating-point scaling factor so people can use whatever coordinate system they want going forward.  It just seems like any other solution is going to end up being a dead-end for future displays, and rather ugly in any case (as the current solution is demonstrating).

Also, another nice thing that InterViews got right was a multi-pass layout algorithm that “just worked” to best fit elements in available display spaces — including the option of using a LaTeX-inspired layout algorithm.  You specify “natural” sizes and flexibility factors, and the algorithm optimizes from there.  This works well when moving away from having to do precise layouts in pixel coordinates.. 

- Randy

> On Jul 26, 2016, at 8:56 PM, Nikita Krupenko <krnekit at gmail.com> wrote:
> 
> 2016-07-27 4:02 GMT+03:00 Thiago Macieira <thiago.macieira at intel.com>:
>> Em quarta-feira, 27 de julho de 2016, às 02:49:31 PDT, Nikita Krupenko
>> escreveu:
>>> In Material Design guidelines [1] all font sizes are in scaleable
>>> pixels (sp). So this size could be multiplied by some factor and all
>>> fonts should scale equally.
>> 
>> Maybe we should instead use a size calculated in physical units, like 1/72th
>> of an inch. Oh, we have such a unit: points.
> 
> The idea of scaleable pixels is somewhat different: user can select
> big/small fonts in the OS/application settings and font sizes would be
> multiplied by some factor, for example 1.5.
> 
> BTW, why use font size in points? As other elements, like widgets,
> images, etc has size in pixels, it's better to use pixels for fonts
> too. Auto HiDPI scaling in Qt works for font sizes in pixels.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From techabc at gmail.com  Wed Jul 27 07:58:49 2016
From: techabc at gmail.com (techabc)
Date: Wed, 27 Jul 2016 13:58:49 +0800
Subject: [Development] Are QT winmigrate framework will be back in qt
 5.x ?
In-Reply-To: <CY1PR10MB0170DA02D2FB2578C4FBFB80A9090@CY1PR10MB0170.namprd10.prod.outlook.com>
References: <CAPPwZt64u8T7Lf==dWhM19ua4A2kFOrvGbmG6Nqr5mYyyf4OBQ@mail.gmail.com>
	<CAPPwZt7iVx8X6WVjMBdSt+YcvV5kTkCUtB+TsRW2iPT==9XO0g@mail.gmail.com>
	<CY1PR10MB0170DA02D2FB2578C4FBFB80A9090@CY1PR10MB0170.namprd10.prod.outlook.com>
Message-ID: <CAPPwZt5Xy+2sDHQOstW0AgaQMMw7_K2yUbvU2WxMgpxObrxmBA@mail.gmail.com>

Thinks for reply, nice of you.

I have an application that based on MFC MDI and it call 300+ DLLs(based on
MFC, type is MFC regular DLL, each DLL contains GUI based on Dialog, and
each DLL send && receive messages with MFC MDI application, as a plugin
cowork with the MFC MDI application). for some reason, I will rewrite the
application with QT 5.x, but I won't rewrite these DLLs because develop and
test are all huge work, espetialy test.
I have all source code in my hands, but,
How can I reuse these MFC based GUI DLLs in the new QT application without
rewrite it?


2016-07-21 14:20 GMT+08:00 Scott Aron Bloom <scott at towel42.com>:

> A lot of it will depend on what you are using Qt for.
>
>
> I used the Qt Solution for WinMigrate, which essentially (At a very high
> level) makes sure the Qt event loop gets called when the MFC event loop is
> run.
>
> Where I used it was to add Qt windows and Qt eventloop driven
> functionality (QHttp before QNetworkAccessManager existed).  It worked fine
> for stand alone top level windows.
>
>
>
> I don’t recommend it for modal windows, or for “child widgets”.
>
>
> Im not sure what you are looking for besides the qt solution for
> winmigrate.
>
>
>
> Scott
>
> *From:* Development [mailto:development-bounces+scott=
> towel42.com at qt-project.org] *On Behalf Of *techabc
> *Sent:* Wednesday, July 20, 2016 23:01
> *To:* development <development at qt-project.org>
> *Subject:* Re: [Development] Are QT winmigrate framework will be back in
> qt 5.x ?
>
>
>
> How can I reuse the MFC based GUI dll in a QT application?
>
>
>
>
>
> 2016-06-26 21:53 GMT+08:00 techabc <techabc at gmail.com>:
>
> I need to call 300+ MFC extending DLL in a new QT 5.x application, if
> except winmigrate, whatthing else can do it?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160727/2674fd23/attachment.html>

From Friedemann.Kleint at qt.io  Wed Jul 27 08:28:08 2016
From: Friedemann.Kleint at qt.io (Friedemann Kleint)
Date: Wed, 27 Jul 2016 08:28:08 +0200
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <1770814.TfGvLeZc4p@tjmaciei-mobl1>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1>
	<10723215.7zoGWthJmd@tjmaciei-mobl1>
	<CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>
	<1770814.TfGvLeZc4p@tjmaciei-mobl1>
Message-ID: <57985478.3070305@qt.io>

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?)

 >It's also possible that the Windows code is simply recovering, and that
 >QTest::toString is actually causing the crash. In other words, it's 
possible
 >the code that deals with crashes in QtTest is causing the crash.

I think the QTest::toString appearing is an artifact of the code that 
walks the stack.

We know that it seems to depends on some obscure CI parameters (load?), 
so far, we have not been able to see anything useful in the stack traces.

Regards,
Friedemann

-- 
Friedemann Kleint, The Qt Company GmbH



From Simon.Hausmann at qt.io  Wed Jul 27 08:35:07 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Wed, 27 Jul 2016 06:35:07 +0000
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <57985478.3070305@qt.io>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1>
	<10723215.7zoGWthJmd@tjmaciei-mobl1>
	<CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>
	<1770814.TfGvLeZc4p@tjmaciei-mobl1>,<57985478.3070305@qt.io>
Message-ID: <DB4PR02MB0541AD493B971480FE63B6F98C0F0@DB4PR02MB0541.eurprd02.prod.outlook.com>


Excellent summary. I'd like to add one point: The crashes appear to happen with a big majority in qtbase.

Outside of qtbase I've only seen moc crash, on macOS I think.



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Friedemann Kleint <Friedemann.Kleint at qt.io>
Sent: Wednesday, July 27, 2016 8:28:08 AM
To: development at qt-project.org
Subject: Re: [Development] Programs crashing left and right in the CI

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?)

 >It's also possible that the Windows code is simply recovering, and that
 >QTest::toString is actually causing the crash. In other words, it's
possible
 >the code that deals with crashes in QtTest is causing the crash.

I think the QTest::toString appearing is an artifact of the code that
walks the stack.

We know that it seems to depends on some obscure CI parameters (load?),
so far, we have not been able to see anything useful in the stack traces.

Regards,
Friedemann

--
Friedemann Kleint, The Qt Company GmbH

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160727/2ba410dd/attachment.html>

From denis.shienkov at gmail.com  Wed Jul 27 08:49:14 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Wed, 27 Jul 2016 09:49:14 +0300
Subject: [Development] [QLockFile] Whether it is reasonable to use 0644
 permission ?
Message-ID: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>

Hi all.

As I can see, the QLockFile opens a lock-file with the 0644 permissions 
in Linux, e.g. see QLockFile::LockError QLockFilePrivate::tryLock_sys() [1].

That means that only one user (owner) can modify this file. But it leads 
to problems, for example, when this use-case:

1. User 'A' creates the lock-file for the some resource

2. The application crashed, and this lock-file stays undeleted/unchanged

3. User 'B' tries to use same free resource, but it is failed due to 
QLockFile can not write appropriate pid to the lock-file, since user 'B' 
has not access to modify this lock-file.

This happens, e.g. when user 'A' is root and so on.

Currently this problem belongs to QSerialPort which internally uses 
QLockFile to indication of employment of the /dev/ttyXYZ resources.
When it is impossible to open serial port when its lock-file has been 
created from other user. There are only one workaround - it is remove
this lock-file manually.

Why just do not use 0666 permissions for this?

BR,
Denis







[1] 
http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qlockfile_unix.cpp#n181



From thiago.macieira at intel.com  Wed Jul 27 09:01:20 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 27 Jul 2016 00:01:20 -0700
Subject: [Development] [QLockFile] Whether it is reasonable to use 0644
 permission ?
In-Reply-To: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>
References: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>
Message-ID: <3749077.YVGmbvSETS@tjmaciei-mobl1>

On quarta-feira, 27 de julho de 2016 09:49:14 PDT Denis Shienkov wrote:
> Why just do not use 0666 permissions for this?

We should use 0666 and let the umask determine which bits to exclude.

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



From denis.shienkov at gmail.com  Wed Jul 27 09:31:35 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Wed, 27 Jul 2016 10:31:35 +0300
Subject: [Development] [QLockFile] Whether it is reasonable to use 0644
 permission ?
In-Reply-To: <3749077.YVGmbvSETS@tjmaciei-mobl1>
References: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>
	<3749077.YVGmbvSETS@tjmaciei-mobl1>
Message-ID: <69475e7b-f670-43f7-6558-1993281477c9@gmail.com>

 > and let the umask determine which bits to exclude.

what do you mean here? why we need to use umask, and why we need to 
exclude bits?


27.07.2016 10:01, Thiago Macieira пишет:
> On quarta-feira, 27 de julho de 2016 09:49:14 PDT Denis Shienkov wrote:
>> Why just do not use 0666 permissions for this?
> We should use 0666 and let the umask determine which bits to exclude.
>



From albert.astals at canonical.com  Wed Jul 27 09:41:34 2016
From: albert.astals at canonical.com (Albert Astals Cid)
Date: Wed, 27 Jul 2016 09:41:34 +0200
Subject: [Development] [QLockFile] Whether it is reasonable to use 0644
 permission ?
In-Reply-To: <69475e7b-f670-43f7-6558-1993281477c9@gmail.com>
References: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>
	<3749077.YVGmbvSETS@tjmaciei-mobl1>
	<69475e7b-f670-43f7-6558-1993281477c9@gmail.com>
Message-ID: <CAA0DqqDtvcsbcV-CSAjocoZZa9V51y1ECMteDJUGQ-p4d89XDQ@mail.gmail.com>

FWIW this is slightly related to https://bugreports.qt.io/browse/QTBUG-53570

On Wed, Jul 27, 2016 at 9:31 AM, Denis Shienkov
<denis.shienkov at gmail.com> wrote:
>> and let the umask determine which bits to exclude.
>
> what do you mean here? why we need to use umask, and why we need to exclude
> bits?
>
>
> 27.07.2016 10:01, Thiago Macieira пишет:
>>
>> On quarta-feira, 27 de julho de 2016 09:49:14 PDT Denis Shienkov wrote:
>>>
>>> Why just do not use 0666 permissions for this?
>>
>> We should use 0666 and let the umask determine which bits to exclude.
>>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From bogdan at kdab.com  Wed Jul 27 09:53:29 2016
From: bogdan at kdab.com (BogDan Vatra)
Date: Wed, 27 Jul 2016 10:53:29 +0300
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML?
In-Reply-To: <11219652.DBPjSgSVCN@maurice>
References: <30621599.Di3TuLGYCH@debian> <3892193.gsOItmPEK2@tjmaciei-mobl1>
	<11219652.DBPjSgSVCN@maurice>
Message-ID: <1536201.SuI4YCqMRi@debian>

On marți, 26 iulie 2016 20:08:52 EEST Olivier Goffart wrote:
> On Dienstag, 26. Juli 2016 08:33:31 CEST Thiago Macieira wrote:
> > Em terça-feira, 26 de julho de 2016, às 17:50:38 PDT, BogDan Vatra 
escreveu:
> > > Hi,
> > > 
> > > Is there any reason why C++11 scoped enums are not scoped in QML ?
> > 
> > There's no trait to tell apart a scoped enum from an unscoped one. An enum
> > is en enum, that's all.
> > 
> > If you want a given enum to be scoped in QML, it should be a QML engine
> > feature and should be available to any C++ enum, whether it's scoped or
> > not.> 
> > > If I have something like the following code in C++
> > 
> > [cut]
> > 
> > >  Q_ENUM(MyEnum)
> > 
> > This is all the engine sees. It's an enum.
> 
> It's trivial to let QMetaEnum know about scoped enum:
> 
> https://codereview.qt-project.org/166136/
> 

What timing ! :) Thanks Olivier!

> 
> That said, it would be a behavior change not to allow anymore the previous
> (unscoped) syntax to work with QML

The unscoped enums should work as they are woring now, just the scoped ones 
should be scoped in QML as well.

Based on your patch, I'll try to prepare a patch for QML.

Cheers,
BogDan.



From jedrzej.nowacki at qt.io  Wed Jul 27 09:53:32 2016
From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki)
Date: Wed, 27 Jul 2016 09:53:32 +0200
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <1770814.TfGvLeZc4p@tjmaciei-mobl1>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1>
	<CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>
	<1770814.TfGvLeZc4p@tjmaciei-mobl1>
Message-ID: <1545815.ve7CAfvpSs@42>

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
> > 
> > <thiago.macieira at intel.com> 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


From jedrzej.nowacki at qt.io  Wed Jul 27 10:12:18 2016
From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki)
Date: Wed, 27 Jul 2016 10:12:18 +0200
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <57985478.3070305@qt.io>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1>
	<1770814.TfGvLeZc4p@tjmaciei-mobl1> <57985478.3070305@qt.io>
Message-ID: <2817451.agYINOn3Jy@42>

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


From andre at familiesomers.nl  Wed Jul 27 10:35:01 2016
From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=)
Date: Wed, 27 Jul 2016 10:35:01 +0200
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML?
In-Reply-To: <1536201.SuI4YCqMRi@debian>
References: <30621599.Di3TuLGYCH@debian> <3892193.gsOItmPEK2@tjmaciei-mobl1>
	<11219652.DBPjSgSVCN@maurice> <1536201.SuI4YCqMRi@debian>
Message-ID: <0e610d52-ff18-8b92-e6b1-1211da16aada@familiesomers.nl>



Op 27/07/2016 om 09:53 schreef BogDan Vatra:
>
>> That said, it would be a behavior change not to allow anymore the previous
>> (unscoped) syntax to work with QML
> The unscoped enums should work as they are woring now, just the scoped ones
> should be scoped in QML as well.
>
> Based on your patch, I'll try to prepare a patch for QML.
>
Would that not break existing QML applications that now use enums backed 
by scoped enums in C++?

André



From bogdan at kdab.com  Wed Jul 27 10:47:03 2016
From: bogdan at kdab.com (BogDan Vatra)
Date: Wed, 27 Jul 2016 11:47:03 +0300
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML?
In-Reply-To: <0e610d52-ff18-8b92-e6b1-1211da16aada@familiesomers.nl>
References: <30621599.Di3TuLGYCH@debian> <1536201.SuI4YCqMRi@debian>
	<0e610d52-ff18-8b92-e6b1-1211da16aada@familiesomers.nl>
Message-ID: <183706514.k8FeVR6CAG@debian>

On miercuri, 27 iulie 2016 10:35:01 EEST André Somers wrote:
> Op 27/07/2016 om 09:53 schreef BogDan Vatra:
> >> That said, it would be a behavior change not to allow anymore the
> >> previous
> >> (unscoped) syntax to work with QML
> > 
> > The unscoped enums should work as they are woring now, just the scoped
> > ones
> > should be scoped in QML as well.
> > 
> > Based on your patch, I'll try to prepare a patch for QML.
> 
> Would that not break existing QML applications that now use enums backed
> by scoped enums in C++?
> 

It will, but personaly I can't see a better solution ... 
So, either we break the existing QML apps that used scoped enums in C++ (which 
is useless, because in QML side you'll get name clashing) or we keep it as it 
is now and never "fix" it. I'd like the first option :). 
Of course if we can find a better solution to have them both is even better !

Cheers,
BogDan.



From dangelog at gmail.com  Wed Jul 27 10:48:49 2016
From: dangelog at gmail.com (Giuseppe D'Angelo)
Date: Wed, 27 Jul 2016 10:48:49 +0200
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML?
In-Reply-To: <183706514.k8FeVR6CAG@debian>
References: <30621599.Di3TuLGYCH@debian> <1536201.SuI4YCqMRi@debian>
	<0e610d52-ff18-8b92-e6b1-1211da16aada@familiesomers.nl>
	<183706514.k8FeVR6CAG@debian>
Message-ID: <CAPm+cvgAGzdrbtkM2LUvHn-0t7yNARd4WR4SyP_bLwmE9wxWcg@mail.gmail.com>

On Wed, Jul 27, 2016 at 10:47 AM, BogDan Vatra <bogdan at kdab.com> wrote:
> Of course if we can find a better solution to have them both is even better !

I guess you'll need a pragma to enable this feature as opt-in. And/or
a pragma to warn about the other usage so that in 5.10/5.11 you can
break that code.

-- 
Giuseppe D'Angelo


From vviktor2 at gmail.com  Wed Jul 27 11:12:13 2016
From: vviktor2 at gmail.com (=?UTF-8?Q?Vereb=C3=A9lyi_Viktor?=)
Date: Wed, 27 Jul 2016 10:12:13 +0100
Subject: [Development] Fwd: Are there any limitations on implementing the
 changing of the screen for a QWindow on systems using EGLFS?
In-Reply-To: <CAGpMZc3w5rvJQ3mx7h_v-1sTSSL8CXLNqKtJYhOUME7xrqBHYA@mail.gmail.com>
References: <CAGpMZc3r6Z7vq=D379RMqSSqtWqKMFQc=wQ3u10F7nP3xhBsCQ@mail.gmail.com>
	<DB5PR0201MB200759FB3297937B023CB969870E0@DB5PR0201MB2007.eurprd02.prod.outlook.com>
	<CAGpMZc3w5rvJQ3mx7h_v-1sTSSL8CXLNqKtJYhOUME7xrqBHYA@mail.gmail.com>
Message-ID: <CAGpMZc0EWtSVO_q+afNqqZGqap9m4UJJPsUjZqbVMEMvFYFQFQ@mail.gmail.com>

I've seen that patch, and it is definitely a good starter. I was able to
change the screen and run two screens simultaneously using Raspbian's
Dispmanx example (one screen was connected through the PI's DSI port the
other one through HDMI) quite easily, so I think it does worth poking
around with.

There is a callback that can be used for monitoring the status of the
HDMI/SDTV connection (couldn't find anything for the DSI port) , but I'm
not sure how to access those. See :
https://github.com/raspberrypi/userland/blob/master/interface/vmcs_host/vc_hdmi.h

I'll try to come up with a Proof of Concept when I get some time next week,
but first I have to read through some of the other platform integrations,
to get a better understanding of QPA.

On 26 Jul 2016 14:33, "Laszlo Agocs" <laszlo.agocs at qt.io> wrote:

> Lack of contributions and suitable hardware setup. There was a patch for
> making the target screen configurable via an environment variable which
> never made it to integration. We are now reviving it for 5.6 at
> https://codereview.qt-project.org/#/c/166117/
>
>
> Additional patches for discovering and exposing all available screens as
> separate QScreens are welcome. Not entirely sure about the feasibility,
> especially when it comes to discovering and monitoring the connected
> outputs, but it is definitely worth a try.
>
>
> Best regards,
>
> Laszlo
>
>
> <https://codereview.qt-project.org/#/c/166117/>
> ------------------------------
> *From:* Development <development-bounces+laszlo.agocs=qt.io at qt-project.org>
> on behalf of Verebélyi Viktor <vviktor2 at gmail.com>
> *Sent:* Sunday, July 24, 2016 8:28:15 AM
> *To:* development at qt-project.org
> *Subject:* [Development] Are there any limitations on implementing the
> changing of the screen for a QWindow on systems using EGLFS?
>
>
> I looked at the code for the EGLFS BRCM integration and the screen it uses
> is hard-coded. After trying some test code for Dispmanx it seems that it is
> fairly straight forward to change the screen it uses.
>
> My question is: Are there any limitations to implementing the functions
> that would allow us to change the screen using QWindows->setScreen()?
>
> The reason for why I'm asking is, because I'd like to implement this, but
> I'd like to know whether if this is not implemented beacuse of some
> limitations or because of lack of intrest/contributors?
>
>
> --
> - Viktor Verebelyi
>



-- 
- Viktor Verebelyi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160727/81eb1a1c/attachment.html>

From oswald.buddenhagen at qt.io  Wed Jul 27 11:37:51 2016
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Wed, 27 Jul 2016 11:37:51 +0200
Subject: [Development] [QLockFile] Whether it is reasonable to use 0644
 permission ?
In-Reply-To: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>
References: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>
Message-ID: <20160727093751.GB20544@troll08>

On Wed, Jul 27, 2016 at 09:49:14AM +0300, Denis Shienkov wrote:
> Currently this problem belongs to QSerialPort which internally uses 
> QLockFile to indication of employment of the /dev/ttyXYZ resources.
>
well, that's kinda the problem. this approach is a hack to work around
inadequate locking on the device itself. is this still a problem on
modern unixes?

> Why just do not use 0666 permissions for this?
> 
because any malicious user can then sabotage other users' lock files.

also, isn't this actually mostly about the permissions of the directory
containing the locks? lock grabbing should be mostly about deleting and
re-creating the file.


From oswald.buddenhagen at qt.io  Wed Jul 27 11:40:18 2016
From: oswald.buddenhagen at qt.io (Oswald Buddenhagen)
Date: Wed, 27 Jul 2016 11:40:18 +0200
Subject: [Development] [QLockFile] Whether it is reasonable to use 0644
 permission ?
In-Reply-To: <CAA0DqqDtvcsbcV-CSAjocoZZa9V51y1ECMteDJUGQ-p4d89XDQ@mail.gmail.com>
	<3749077.YVGmbvSETS@tjmaciei-mobl1>
Message-ID: <20160727094018.GC20544@troll08>

On Wed, Jul 27, 2016 at 12:01:20AM -0700, Thiago Macieira wrote:
> On quarta-feira, 27 de julho de 2016 09:49:14 PDT Denis Shienkov wrote:
> > Why just do not use 0666 permissions for this?
> 
> We should use 0666 and let the umask determine which bits to exclude.
> 
how exactly is this response supposed to be helpful in any way?

On Wed, Jul 27, 2016 at 09:41:34AM +0200, Albert Astals Cid wrote:
> FWIW this is slightly related to https://bugreports.qt.io/browse/QTBUG-53570
> 
it's probably the correct solution *if* qlockfile can be actually used
for this purpose at all without causing other problems.


From denis.shienkov at gmail.com  Wed Jul 27 13:47:05 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Wed, 27 Jul 2016 14:47:05 +0300
Subject: [Development] Is the MNG format supported in official installer?
Message-ID: <CAHtcb0xBQtP5wcC3GMZ84+xfKss7zPDwtr=FLuEWNQsYRkvPhQ@mail.gmail.com>

Hi all.

I want to use an MNG animation, using official Qt 5.7 from MSVC2015
installer..

BUT: I do not see in 5.7\msvc2015\plugins\imageformats\ apropriate qmng.dll
(or something like) plugin, so leads to fails with the QML's AnimatedSprite
item, with error:

<Unknown File>: QML Sprite: Error decoding: file:///foo.mng: Unsupported
image format

What is workaround? Should I recompile the ImageFormats module himself?

BR,
Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160727/d3ab7640/attachment.html>

From jedrzej.nowacki at qt.io  Wed Jul 27 13:47:45 2016
From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki)
Date: Wed, 27 Jul 2016 13:47:45 +0200
Subject: [Development] New Coin feature: automatic provisioning
Message-ID: <1764246.GsXfPSTX0N@42>

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.



From dominik.holland at pelagicore.com  Wed Jul 27 13:58:44 2016
From: dominik.holland at pelagicore.com (Dominik Holland)
Date: Wed, 27 Jul 2016 13:58:44 +0200
Subject: [Development] New Coin feature: automatic provisioning
In-Reply-To: <1764246.GsXfPSTX0N@42>
References: <1764246.GsXfPSTX0N@42>
Message-ID: <5fa74fc7-be71-ca9f-a34c-4ac2a94cfa19@pelagicore.com>

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

> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 

-- 
Dominik Holland
SENIOR SOFTWARE ENGINEER

Pelagicore AG
Balanstr. 55, 81541 Munich, Germany
+49 (0)171 760 25 96
dominik.holland at pelagicore.com
www.pelagicore.com



From denis.shienkov at gmail.com  Wed Jul 27 14:03:27 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Wed, 27 Jul 2016 15:03:27 +0300
Subject: [Development] Is the MNG format supported in official installer?
In-Reply-To: <CAHtcb0xBQtP5wcC3GMZ84+xfKss7zPDwtr=FLuEWNQsYRkvPhQ@mail.gmail.com>
References: <CAHtcb0xBQtP5wcC3GMZ84+xfKss7zPDwtr=FLuEWNQsYRkvPhQ@mail.gmail.com>
Message-ID: <CAHtcb0wWE45P5+EsnAMJ_ho41FD5o=8u6RHssfYni=Pb+eS1_Q@mail.gmail.com>

Hmm.. Now I have cloned the "imageformats" source module, open its *.pro
file from QtC, and re-build it...

BUT: I too do not see the output qmng.dll target, though, I see this 'mng'
plugin in the source's tree...
Seems it did not compiles.. o_O

2016-07-27 14:47 GMT+03:00 Denis Shienkov <denis.shienkov at gmail.com>:

> Hi all.
>
> I want to use an MNG animation, using official Qt 5.7 from MSVC2015
> installer..
>
> BUT: I do not see in 5.7\msvc2015\plugins\imageformats\ apropriate
> qmng.dll (or something like) plugin, so leads to fails with the QML's
> AnimatedSprite item, with error:
>
> <Unknown File>: QML Sprite: Error decoding: file:///foo.mng: Unsupported
> image format
>
> What is workaround? Should I recompile the ImageFormats module himself?
>
> BR,
> Denis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160727/84f27f5b/attachment.html>

From denis.shienkov at gmail.com  Wed Jul 27 14:06:29 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Wed, 27 Jul 2016 15:06:29 +0300
Subject: [Development] Is the MNG format supported in official installer?
In-Reply-To: <CAHtcb0wWE45P5+EsnAMJ_ho41FD5o=8u6RHssfYni=Pb+eS1_Q@mail.gmail.com>
References: <CAHtcb0xBQtP5wcC3GMZ84+xfKss7zPDwtr=FLuEWNQsYRkvPhQ@mail.gmail.com>
	<CAHtcb0wWE45P5+EsnAMJ_ho41FD5o=8u6RHssfYni=Pb+eS1_Q@mail.gmail.com>
Message-ID: <CAHtcb0wx6fdd7GPmtrpXTkrP+VNWA6JNtpMHSNS=Y9+og-HXMw@mail.gmail.com>

Ahh... seems, the config.tests for MNG fails..

2016-07-27 15:03 GMT+03:00 Denis Shienkov <denis.shienkov at gmail.com>:

> Hmm.. Now I have cloned the "imageformats" source module, open its *.pro
> file from QtC, and re-build it...
>
> BUT: I too do not see the output qmng.dll target, though, I see this
> 'mng' plugin in the source's tree...
> Seems it did not compiles.. o_O
>
> 2016-07-27 14:47 GMT+03:00 Denis Shienkov <denis.shienkov at gmail.com>:
>
>> Hi all.
>>
>> I want to use an MNG animation, using official Qt 5.7 from MSVC2015
>> installer..
>>
>> BUT: I do not see in 5.7\msvc2015\plugins\imageformats\ apropriate
>> qmng.dll (or something like) plugin, so leads to fails with the QML's
>> AnimatedSprite item, with error:
>>
>> <Unknown File>: QML Sprite: Error decoding: file:///foo.mng: Unsupported
>> image format
>>
>> What is workaround? Should I recompile the ImageFormats module himself?
>>
>> BR,
>> Denis
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160727/1e439e63/attachment.html>

From jedrzej.nowacki at qt.io  Wed Jul 27 14:53:16 2016
From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki)
Date: Wed, 27 Jul 2016 14:53:16 +0200
Subject: [Development] New Coin feature: automatic provisioning
In-Reply-To: <5fa74fc7-be71-ca9f-a34c-4ac2a94cfa19@pelagicore.com>
References: <1764246.GsXfPSTX0N@42>
	<5fa74fc7-be71-ca9f-a34c-4ac2a94cfa19@pelagicore.com>
Message-ID: <7861063.Dvr8jF8FDj@42>

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


From thiago.macieira at intel.com  Wed Jul 27 17:43:30 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 27 Jul 2016 08:43:30 -0700
Subject: [Development] [QLockFile] Whether it is reasonable to use 0644
 permission ?
In-Reply-To: <69475e7b-f670-43f7-6558-1993281477c9@gmail.com>
References: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>
	<3749077.YVGmbvSETS@tjmaciei-mobl1>
	<69475e7b-f670-43f7-6558-1993281477c9@gmail.com>
Message-ID: <2917686.iL4xoHNLrF@tjmaciei-mobl1>

On quarta-feira, 27 de julho de 2016 10:31:35 PDT Denis Shienkov wrote:
>  > and let the umask determine which bits to exclude.
> 
> what do you mean here? why we need to use umask, and why we need to
> exclude bits?

Because we don't have a choice. The umask bits apply when you create a fie.

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



From thiago.macieira at intel.com  Wed Jul 27 17:45:58 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 27 Jul 2016 08:45:58 -0700
Subject: [Development] [QLockFile] Whether it is reasonable to use 0644
 permission ?
In-Reply-To: <20160727093751.GB20544@troll08>
References: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>
	<20160727093751.GB20544@troll08>
Message-ID: <8743368.u9PecXUntd@tjmaciei-mobl1>

On quarta-feira, 27 de julho de 2016 11:37:51 PDT Oswald Buddenhagen wrote:
> also, isn't this actually mostly about the permissions of the directory
> containing the locks? lock grabbing should be mostly about deleting and
> re-creating the file.

That's also a good point. If you have permission to delete the stale lock, 
problem solved.

If you don't have permission to delete it, then you're going to have a problem 
to drop your own lock if you steal the lock by writing to the file.

Either way, the mode in the call should be 0666.

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



From thiago.macieira at intel.com  Wed Jul 27 17:50:32 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 27 Jul 2016 08:50:32 -0700
Subject: [Development] Is the MNG format supported in official installer?
In-Reply-To: <CAHtcb0wx6fdd7GPmtrpXTkrP+VNWA6JNtpMHSNS=Y9+og-HXMw@mail.gmail.com>
References: <CAHtcb0xBQtP5wcC3GMZ84+xfKss7zPDwtr=FLuEWNQsYRkvPhQ@mail.gmail.com>
	<CAHtcb0wWE45P5+EsnAMJ_ho41FD5o=8u6RHssfYni=Pb+eS1_Q@mail.gmail.com>
	<CAHtcb0wx6fdd7GPmtrpXTkrP+VNWA6JNtpMHSNS=Y9+og-HXMw@mail.gmail.com>
Message-ID: <1936297.b9P55p4WAz@tjmaciei-mobl1>

On quarta-feira, 27 de julho de 2016 15:06:29 PDT Denis Shienkov wrote:
> Ahh... seems, the config.tests for MNG fails..

That's because we removed the bundled copy of libmng. You need to install it 
yourself first.

We did that because our copy was very old and, at Qt 5.6 times, we thought 
that libmng and jasper development had completely stalled, including for 
security issues. Turns out there's a newer copy in

https://sourceforge.net/projects/libmng/files/libmng-devel/

But now the burden is on you to compile it and install it before 
qtimageformats.

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



From thiago.macieira at intel.com  Wed Jul 27 18:05:57 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 27 Jul 2016 09:05:57 -0700
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <1545815.ve7CAfvpSs@42>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1>
	<1770814.TfGvLeZc4p@tjmaciei-mobl1> <1545815.ve7CAfvpSs@42>
Message-ID: <3090030.9PkAQK6gYW@tjmaciei-mobl1>

On quarta-feira, 27 de julho de 2016 09:53:32 PDT Jędrzej Nowacki wrote:
> 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 have been tools to collect core dumps for years. The modern choice is 
systemd-coredump, which automatically logs and compresses them for you. The CI 
system should ask coredumpctl for all core dumps that were created after the 
build started, then transfer them out before the machine is destroyed (it's 
easier to do that 

A lot of information is logged on the journal. Just run:

	journalctl -o json /usr/lib/systemd/systemd-coredump
(use "-o verbose" to read more easily)

It's easier to filter if the build is run in a separate slice or cgroup. 
Otherwise, filter by UID or write a simple journal walker that executes a more 
complex match.

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



From thiago.macieira at intel.com  Wed Jul 27 18:08:32 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 27 Jul 2016 09:08:32 -0700
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML?
In-Reply-To: <183706514.k8FeVR6CAG@debian>
References: <30621599.Di3TuLGYCH@debian>
	<0e610d52-ff18-8b92-e6b1-1211da16aada@familiesomers.nl>
	<183706514.k8FeVR6CAG@debian>
Message-ID: <9175479.tdaMBSsZmC@tjmaciei-mobl1>

On quarta-feira, 27 de julho de 2016 11:47:03 PDT BogDan Vatra wrote:
> On miercuri, 27 iulie 2016 10:35:01 EEST André Somers wrote:
> > Op 27/07/2016 om 09:53 schreef BogDan Vatra:
> > Would that not break existing QML applications that now use enums backed
> > by scoped enums in C++?
> 
> It will, but personaly I can't see a better solution ...

I have already said what to do: make it an opt-in on registration of the enum 
to the QML/JS engine.

> So, either we break the existing QML apps that used scoped enums in C++
> (which is useless, because in QML side you'll get name clashing) or we keep
> it as it is now and never "fix" it. I'd like the first option :).

I really hate it. Breaking applications should not even be an option on the 
table. Let's start with "we won't gratuitously break applications" and work to 
find a solution from there.

> Of course if we can find a better solution to have them both is even better
> !

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



From kevin.kofler at chello.at  Wed Jul 27 22:15:45 2016
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 27 Jul 2016 22:15:45 +0200
Subject: [Development] [QLockFile] Whether it is reasonable to use 0644
 permission ?
References: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>
	<20160727093751.GB20544@troll08>
	<8743368.u9PecXUntd@tjmaciei-mobl1>
Message-ID: <nnb4pi$6od$1@ger.gmane.org>

Thiago Macieira wrote:
> If you don't have permission to delete it, then you're going to have a
> problem to drop your own lock if you steal the lock by writing to the
> file.

So this means that the permission should be 0644 to prevent that from 
happening. Thus, I don't understand how you get to:

> Either way, the mode in the call should be 0666.

        Kevin Kofler




From dangelog at gmail.com  Wed Jul 27 23:00:36 2016
From: dangelog at gmail.com (Giuseppe D'Angelo)
Date: Wed, 27 Jul 2016 23:00:36 +0200
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1> <5951295.MVm6SEVxWd@42>
	<10723215.7zoGWthJmd@tjmaciei-mobl1>
	<CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>
Message-ID: <CAPm+cvhmT=0AnG6FZXvK4j-aGrfKS-AGOhiEkUqWSYLSV24YpQ@mail.gmail.com>

On Tue, Jul 26, 2016 at 11:24 PM, Giuseppe D'Angelo <dangelog at gmail.com> wrote:
>
>
> It just happened again:
>
> http://testresults.qt.io/logs/qt/qtbase/ddfe2ba984be5d652fe500f6695040959db98fa4/OSXOSX_10_11x86_64OSXOSX_10_11x86_64Clangqtci-osx-10.11-x86_64DebugAndRelease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz

And again:

http://testresults.qt.io/logs/qt/qtbase/b9a646e12aec277c7f286ceb3b08a7b775993023/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRelease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/testrun_1469648044/testlog.txt.gz

-- 
Giuseppe D'Angelo


From thiago.macieira at intel.com  Wed Jul 27 23:23:08 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 27 Jul 2016 14:23:08 -0700
Subject: [Development] [QLockFile] Whether it is reasonable to use 0644
 permission ?
In-Reply-To: <nnb4pi$6od$1@ger.gmane.org>
References: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>
	<8743368.u9PecXUntd@tjmaciei-mobl1> <nnb4pi$6od$1@ger.gmane.org>
Message-ID: <1696750.ElF78xHDzo@tjmaciei-mobl1>

On quarta-feira, 27 de julho de 2016 22:15:45 PDT Kevin Kofler wrote:
> Thiago Macieira wrote:
> > If you don't have permission to delete it, then you're going to have a
> > problem to drop your own lock if you steal the lock by writing to the
> > file.
> 
> So this means that the permission should be 0644 to prevent that from
> happening. Thus, I don't understand how you get to:

The permission of the file is irrelevant. The permission of the dir is the one 
that matters.

> > Either way, the mode in the call should be 0666.

Because that will result in 0644 or 0664, depending on the user's umask. The 
correct modes for creat() and open() should be only 0600, 0700, 0666 and 0777. 
Anything else is suspicious and probably wrong. Like this case.

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



From thiago.macieira at intel.com  Wed Jul 27 23:26:32 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 27 Jul 2016 14:26:32 -0700
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <CAPm+cvhmT=0AnG6FZXvK4j-aGrfKS-AGOhiEkUqWSYLSV24YpQ@mail.gmail.com>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1>
	<CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>
	<CAPm+cvhmT=0AnG6FZXvK4j-aGrfKS-AGOhiEkUqWSYLSV24YpQ@mail.gmail.com>
Message-ID: <2616633.A3EQoNLrHp@tjmaciei-mobl1>

On quarta-feira, 27 de julho de 2016 23:00:36 PDT Giuseppe D'Angelo wrote:
> On Tue, Jul 26, 2016 at 11:24 PM, Giuseppe D'Angelo <dangelog at gmail.com> 
wrote:
> > It just happened again:
> > 
> > http://testresults.qt.io/logs/qt/qtbase/ddfe2ba984be5d652fe500f6695040959d
> > b98fa4/OSXOSX_10_11x86_64OSXOSX_10_11x86_64Clangqtci-osx-10.11-x86_64Debug
> > AndRelease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.g
> > z
> And again:
> 
> http://testresults.qt.io/logs/qt/qtbase/b9a646e12aec277c7f286ceb3b08a7b77599
> 3023/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndR
> elease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/testrun_1469648044/t
> estlog.txt.gz

*sigh*

Does anyone have a clue how to reproduce this?

Or capture a core dump on OS X?

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



From dangelog at gmail.com  Thu Jul 28 00:00:16 2016
From: dangelog at gmail.com (Giuseppe D'Angelo)
Date: Thu, 28 Jul 2016 00:00:16 +0200
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <CAPm+cvhmT=0AnG6FZXvK4j-aGrfKS-AGOhiEkUqWSYLSV24YpQ@mail.gmail.com>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1> <5951295.MVm6SEVxWd@42>
	<10723215.7zoGWthJmd@tjmaciei-mobl1>
	<CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>
	<CAPm+cvhmT=0AnG6FZXvK4j-aGrfKS-AGOhiEkUqWSYLSV24YpQ@mail.gmail.com>
Message-ID: <CAPm+cvj2P=gJJwuYdJkWXKmHewXk_UwC-heSGTcFBV72fsLHBg@mail.gmail.com>

On Wed, Jul 27, 2016 at 11:00 PM, Giuseppe D'Angelo <dangelog at gmail.com> wrote:
>
>> http://testresults.qt.io/logs/qt/qtbase/ddfe2ba984be5d652fe500f6695040959db98fa4/OSXOSX_10_11x86_64OSXOSX_10_11x86_64Clangqtci-osx-10.11-x86_64DebugAndRelease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz
>
> And again:
>
> http://testresults.qt.io/logs/qt/qtbase/b9a646e12aec277c7f286ceb3b08a7b775993023/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRelease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/testrun_1469648044/testlog.txt.gz

And again and again and again, can't hug every cat:

http://testresults.qt.io/logs/qt/qtbase/b9a646e12aec277c7f286ceb3b08a7b775993023/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRelease_Release/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz

-- 
Giuseppe D'Angelo


From denis.shienkov at gmail.com  Thu Jul 28 08:27:58 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Thu, 28 Jul 2016 09:27:58 +0300
Subject: [Development] Is the MNG format supported in official installer?
In-Reply-To: <1936297.b9P55p4WAz@tjmaciei-mobl1>
References: <CAHtcb0xBQtP5wcC3GMZ84+xfKss7zPDwtr=FLuEWNQsYRkvPhQ@mail.gmail.com>
	<CAHtcb0wWE45P5+EsnAMJ_ho41FD5o=8u6RHssfYni=Pb+eS1_Q@mail.gmail.com>
	<CAHtcb0wx6fdd7GPmtrpXTkrP+VNWA6JNtpMHSNS=Y9+og-HXMw@mail.gmail.com>
	<1936297.b9P55p4WAz@tjmaciei-mobl1>
Message-ID: <5c0f4928-35f1-794e-4b31-9b3c98cb979c@gmail.com>

 > That's because we removed the bundled copy of libmng.

Then, please, adjust the documentation, because currently it confused users:

http://doc.qt.io/qt-5/qtimageformats-index.html

since MNG is not 'bundled' anymore.

 > You need to install it yourself first.

Ohh... seems it is problem (especially with MSVC), because libmng 
depends on others libraries (as I see).

But, thanks anyway.

27.07.2016 18:50, Thiago Macieira пишет:
> On quarta-feira, 27 de julho de 2016 15:06:29 PDT Denis Shienkov wrote:
>> Ahh... seems, the config.tests for MNG fails..
> That's because we removed the bundled copy of libmng. You need to install it
> yourself first.
>
> We did that because our copy was very old and, at Qt 5.6 times, we thought
> that libmng and jasper development had completely stalled, including for
> security issues. Turns out there's a newer copy in
>
> https://sourceforge.net/projects/libmng/files/libmng-devel/
>
> But now the burden is on you to compile it and install it before
> qtimageformats.
>



From denis.shienkov at gmail.com  Thu Jul 28 08:34:03 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Thu, 28 Jul 2016 09:34:03 +0300
Subject: [Development] [QLockFile] Whether it is reasonable to use 0644
 permission ?
In-Reply-To: <1696750.ElF78xHDzo@tjmaciei-mobl1>
References: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>
	<8743368.u9PecXUntd@tjmaciei-mobl1> <nnb4pi$6od$1@ger.gmane.org>
	<1696750.ElF78xHDzo@tjmaciei-mobl1>
Message-ID: <2521217f-9ec6-4f3c-068d-373b28e0fbf9@gmail.com>

So, as I understand, you agree that QLockFile should be fixed.. Who will 
produce a patch? Thiago, maybe you can do it? :)

PS: Because I do not understand an idea with the umask... I simply would 
replace 0644 with 0666 in sources... and nothing more..

28.07.2016 0:23, Thiago Macieira пишет:
> On quarta-feira, 27 de julho de 2016 22:15:45 PDT Kevin Kofler wrote:
>> Thiago Macieira wrote:
>>> If you don't have permission to delete it, then you're going to have a
>>> problem to drop your own lock if you steal the lock by writing to the
>>> file.
>> So this means that the permission should be 0644 to prevent that from
>> happening. Thus, I don't understand how you get to:
> The permission of the file is irrelevant. The permission of the dir is the one
> that matters.
>
>>> Either way, the mode in the call should be 0666.
> Because that will result in 0644 or 0664, depending on the user's umask. The
> correct modes for creat() and open() should be only 0600, 0700, 0666 and 0777.
> Anything else is suspicious and probably wrong. Like this case.
>



From Simon.Hausmann at qt.io  Thu Jul 28 08:42:43 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Thu, 28 Jul 2016 06:42:43 +0000
Subject: [Development] [QLockFile] Whether it is reasonable to use 0644
 permission ?
In-Reply-To: <2521217f-9ec6-4f3c-068d-373b28e0fbf9@gmail.com>
References: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>
	<8743368.u9PecXUntd@tjmaciei-mobl1> <nnb4pi$6od$1@ger.gmane.org>
	<1696750.ElF78xHDzo@tjmaciei-mobl1>,
	<2521217f-9ec6-4f3c-068d-373b28e0fbf9@gmail.com>
Message-ID: <DB4PR02MB0541B49677F016746B6AE62E8C000@DB4PR02MB0541.eurprd02.prod.outlook.com>


Here you go :)


https://codereview.qt-project.org/166278



Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Denis Shienkov <denis.shienkov at gmail.com>
Sent: Thursday, July 28, 2016 8:34:03 AM
To: development at qt-project.org
Subject: Re: [Development] [QLockFile] Whether it is reasonable to use 0644 permission ?

So, as I understand, you agree that QLockFile should be fixed.. Who will
produce a patch? Thiago, maybe you can do it? :)

PS: Because I do not understand an idea with the umask... I simply would
replace 0644 with 0666 in sources... and nothing more..

28.07.2016 0:23, Thiago Macieira пишет:
> On quarta-feira, 27 de julho de 2016 22:15:45 PDT Kevin Kofler wrote:
>> Thiago Macieira wrote:
>>> If you don't have permission to delete it, then you're going to have a
>>> problem to drop your own lock if you steal the lock by writing to the
>>> file.
>> So this means that the permission should be 0644 to prevent that from
>> happening. Thus, I don't understand how you get to:
> The permission of the file is irrelevant. The permission of the dir is the one
> that matters.
>
>>> Either way, the mode in the call should be 0666.
> Because that will result in 0644 or 0664, depending on the user's umask. The
> correct modes for creat() and open() should be only 0600, 0700, 0666 and 0777.
> Anything else is suspicious and probably wrong. Like this case.
>

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160728/a2d8ba6b/attachment.html>

From denis.shienkov at gmail.com  Thu Jul 28 08:45:16 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Thu, 28 Jul 2016 09:45:16 +0300
Subject: [Development] [QLockFile] Whether it is reasonable to use 0644
 permission ?
In-Reply-To: <20160727093751.GB20544@troll08>
References: <4b225de0-b479-d76f-a8d5-1fd1b36a3f6e@gmail.com>
	<20160727093751.GB20544@troll08>
Message-ID: <28805475-db24-30bb-95c2-8986ef78d57b@gmail.com>

>> Currently this problem belongs to QSerialPort which internally uses
QLockFile to indication of employment of the /dev/ttyXYZ resources.> is this still a problem on modern unixes?

 > is this still a problem on modern unixes?

Yes, of course, it still is a problem...

There are one TIOCEXCL flag to make 'exclusive' access, but this flag 
does not work if the root
user want to open an already 'locked' device, because the root ignores 
TIOCEXCL..

So, stays one adequate way, it is use  the lock files, where even root 
won't be able to open an
already locked device (of course, if root's software parses lock-files, 
and if looks for these lock-files in necessary directory).. :)

PS: So, Unix in this case is a ZOO of different solutions, which do not 
work, IMHO...



From olivier at woboq.com  Thu Jul 28 09:22:37 2016
From: olivier at woboq.com (Olivier Goffart)
Date: Thu, 28 Jul 2016 09:22:37 +0200
Subject: [Development] [QML]: Register global enums/flags to QML ?
In-Reply-To: <1610394.huzr6IiSWS@debian>
References: <1610394.huzr6IiSWS@debian>
Message-ID: <4011190.8qyANoXpTy@maurice>

On Dienstag, 26. Juli 2016 18:18:48 CEST BogDan Vatra wrote:
> Hello,
> 
> I'd like to be able to register some "global" enums/flags to QML. I checked
> a little bit how Qt does with all the enums from Qt namespace
> (qnamespace.h) and I end-up in qqmlbuiltinfunctions which does all the
> "magic" which can't be used by normal developers/libs.
> 
> Because I think having "global" enums is a very nice feature, I'd like to
> know if other people and QML maintainers agree with me :).
> If yes, then want to propose the followings:
>  - add one more Q_OBJECT/Q_GADGET like macro for namespaces (Q_NAMESPACE?),
> which declares the mandatory "extern const QMetaObject staticMetaObject" (
> or just "extern const QMetaEnum  staticMetaEnum" ? because in principle
> we'll only be able to declare enums/flags ?) into that namespace. Most
> probably moc will need some love to properly handle the new Q_magic_macro.
> If is too much trouble we can use the qnamespace.h hack.
> 
>  - add a helper macro/function to register the namespace enums/flags (i.e.
> qmlRegisterNamespace or even better qmlRegisterEnums(const QMetaEnum
> &staticMetaEnum, ....).
> 
> I think it depends on QML c++11 scoped enums task, because most probably the
> enums enumerators names will clash.

Yes, i think a Q_NAMESPACE would be a nice addition in order to allow Q_ENUM 
at namespace scope.   We have some example for example in the QSsl namespace 
that has enumerations.

One issue is that moc need to have a complete view of the namespace as it 
generates the QMetaObject for it, so it should not be possible to have Q_ENUM 
in a other header than the one which have the Q_NAMESPACE keyword.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org


From bogdan at kdab.com  Thu Jul 28 09:32:54 2016
From: bogdan at kdab.com (BogDan Vatra)
Date: Thu, 28 Jul 2016 10:32:54 +0300
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML?
In-Reply-To: <9175479.tdaMBSsZmC@tjmaciei-mobl1>
References: <30621599.Di3TuLGYCH@debian> <183706514.k8FeVR6CAG@debian>
	<9175479.tdaMBSsZmC@tjmaciei-mobl1>
Message-ID: <50683565.2T8bX9I0HT@debian>

On miercuri, 27 iulie 2016 09:08:32 EEST Thiago Macieira wrote:
> On quarta-feira, 27 de julho de 2016 11:47:03 PDT BogDan Vatra wrote:
> > On miercuri, 27 iulie 2016 10:35:01 EEST André Somers wrote:
> > > Op 27/07/2016 om 09:53 schreef BogDan Vatra:
> > > Would that not break existing QML applications that now use enums backed
> > > by scoped enums in C++?
> > 
> > It will, but personaly I can't see a better solution ...
> 
> I have already said what to do: make it an opt-in on registration of the
> enum to the QML/JS engine.
> 

Got it  :)

> > So, either we break the existing QML apps that used scoped enums in C++
> > (which is useless, because in QML side you'll get name clashing) or we
> > keep
> > it as it is now and never "fix" it. I'd like the first option :).
> 
> I really hate it. Breaking applications should not even be an option on the
> table. Let's start with "we won't gratuitously break applications" and work
> to find a solution from there.
> 
> > Of course if we can find a better solution to have them both is even
> > better
> > !

What I was trying to say here is that I'd like to have by default C++11 scoped 
enums scoped also on QML, but if everybody thinks is a no go, than we can co 
the other way around.

Anyway, I checked the code a little bit, hopping it will be a few lines 
change, but I was so wrong :). I tried to prefix the (scoped) enum keys with 
the "EnumName." but of course it didn't worked :D, "EnumName_" works fine. It 
seems it needs much love (probably some virtual types based on EnumName), 
unfortunately my QML engine knowledge are too limited to continue :).

Cheers,
BogDan.


From olivier at woboq.com  Thu Jul 28 09:41:48 2016
From: olivier at woboq.com (Olivier Goffart)
Date: Thu, 28 Jul 2016 09:41:48 +0200
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML?
In-Reply-To: <50683565.2T8bX9I0HT@debian>
References: <30621599.Di3TuLGYCH@debian> <9175479.tdaMBSsZmC@tjmaciei-mobl1>
	<50683565.2T8bX9I0HT@debian>
Message-ID: <2765145.ymZXfK1IRj@maurice>

On Donnerstag, 28. Juli 2016 10:32:54 CEST BogDan Vatra wrote:
> On miercuri, 27 iulie 2016 09:08:32 EEST Thiago Macieira wrote:
> > On quarta-feira, 27 de julho de 2016 11:47:03 PDT BogDan Vatra wrote:
> > > On miercuri, 27 iulie 2016 10:35:01 EEST André Somers wrote:
> > > > Op 27/07/2016 om 09:53 schreef BogDan Vatra:
> > > > Would that not break existing QML applications that now use enums
> > > > backed
> > > > by scoped enums in C++?
> > > 
> > > It will, but personaly I can't see a better solution ...
> > 
> > I have already said what to do: make it an opt-in on registration of the
> > enum to the QML/JS engine.
> 
> Got it  :)
> 
> > > So, either we break the existing QML apps that used scoped enums in C++
> > > (which is useless, because in QML side you'll get name clashing) or we
> > > keep
> > > it as it is now and never "fix" it. I'd like the first option :).
> > 
> > I really hate it. Breaking applications should not even be an option on
> > the
> > table. Let's start with "we won't gratuitously break applications" and
> > work
> > to find a solution from there.
> > 
> > > Of course if we can find a better solution to have them both is even
> > > better
> > > !
> 
> What I was trying to say here is that I'd like to have by default C++11
> scoped enums scoped also on QML, but if everybody thinks is a no go, than
> we can co the other way around.
> 
> Anyway, I checked the code a little bit, hopping it will be a few lines
> change, but I was so wrong :). I tried to prefix the (scoped) enum keys with
> the "EnumName." but of course it didn't worked :D, "EnumName_" works fine.
> It seems it needs much love (probably some virtual types based on
> EnumName), unfortunately my QML engine knowledge are too limited to
> continue :).

Note that in C++11, all enums can be used scoped. (even the normal ones)
I think it would make sens to allow all enum to be used scoped in QML too.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org





From dominik.holland at pelagicore.com  Thu Jul 28 09:52:56 2016
From: dominik.holland at pelagicore.com (Dominik Holland)
Date: Thu, 28 Jul 2016 09:52:56 +0200
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML?
In-Reply-To: <2765145.ymZXfK1IRj@maurice>
References: <30621599.Di3TuLGYCH@debian> <9175479.tdaMBSsZmC@tjmaciei-mobl1>
	<50683565.2T8bX9I0HT@debian> <2765145.ymZXfK1IRj@maurice>
Message-ID: <40c397d4-4b7a-5cf1-f685-2f44f50c7e2d@pelagicore.com>



Am 28.07.16 um 09:41 schrieb Olivier Goffart:
> On Donnerstag, 28. Juli 2016 10:32:54 CEST BogDan Vatra wrote:
>> On miercuri, 27 iulie 2016 09:08:32 EEST Thiago Macieira wrote:
>>> On quarta-feira, 27 de julho de 2016 11:47:03 PDT BogDan Vatra wrote:
>>>> On miercuri, 27 iulie 2016 10:35:01 EEST André Somers wrote:
>>>>> Op 27/07/2016 om 09:53 schreef BogDan Vatra:
>>>>> Would that not break existing QML applications that now use enums
>>>>> backed
>>>>> by scoped enums in C++?
>>>>
>>>> It will, but personaly I can't see a better solution ...
>>>
>>> I have already said what to do: make it an opt-in on registration of the
>>> enum to the QML/JS engine.
>>
>> Got it  :)
>>
>>>> So, either we break the existing QML apps that used scoped enums in C++
>>>> (which is useless, because in QML side you'll get name clashing) or we
>>>> keep
>>>> it as it is now and never "fix" it. I'd like the first option :).
>>>
>>> I really hate it. Breaking applications should not even be an option on
>>> the
>>> table. Let's start with "we won't gratuitously break applications" and
>>> work
>>> to find a solution from there.
>>>
>>>> Of course if we can find a better solution to have them both is even
>>>> better
>>>> !
>>
>> What I was trying to say here is that I'd like to have by default C++11
>> scoped enums scoped also on QML, but if everybody thinks is a no go, than
>> we can co the other way around.
>>
>> Anyway, I checked the code a little bit, hopping it will be a few lines
>> change, but I was so wrong :). I tried to prefix the (scoped) enum keys with
>> the "EnumName." but of course it didn't worked :D, "EnumName_" works fine.
>> It seems it needs much love (probably some virtual types based on
>> EnumName), unfortunately my QML engine knowledge are too limited to
>> continue :).
> 
> Note that in C++11, all enums can be used scoped. (even the normal ones)
> I think it would make sens to allow all enum to be used scoped in QML too.
> 

Mhh how do you make sure that the Enum names are unique ? E.g. having
two custom Items and both having a Enum in them called Type, what whould
you get if you do Type.FOO ?

I think this is dangerous to add as currently the enums are not typesafe
in QML and are basically just ints, last time i checked it was able to
assign an enum value from enumA to and an property holding enumB without
any warning

Dominik



From bogdan at kdab.com  Thu Jul 28 09:54:31 2016
From: bogdan at kdab.com (BogDan Vatra)
Date: Thu, 28 Jul 2016 10:54:31 +0300
Subject: [Development] [QML]: Register global enums/flags to QML ?
In-Reply-To: <4011190.8qyANoXpTy@maurice>
References: <1610394.huzr6IiSWS@debian> <4011190.8qyANoXpTy@maurice>
Message-ID: <3367699.x3TbY3ak5d@debian>

On joi, 28 iulie 2016 09:22:37 EEST Olivier Goffart wrote:
> On Dienstag, 26. Juli 2016 18:18:48 CEST BogDan Vatra wrote:
> > Hello,
> > 
> > I'd like to be able to register some "global" enums/flags to QML. I
> > checked
> > a little bit how Qt does with all the enums from Qt namespace
> > (qnamespace.h) and I end-up in qqmlbuiltinfunctions which does all the
> > "magic" which can't be used by normal developers/libs.
> > 
> > Because I think having "global" enums is a very nice feature, I'd like to
> > know if other people and QML maintainers agree with me :).
> > 
> > If yes, then want to propose the followings:
> >  - add one more Q_OBJECT/Q_GADGET like macro for namespaces
> >  (Q_NAMESPACE?),
> > 
> > which declares the mandatory "extern const QMetaObject staticMetaObject" (
> > or just "extern const QMetaEnum  staticMetaEnum" ? because in principle
> > we'll only be able to declare enums/flags ?) into that namespace. Most
> > probably moc will need some love to properly handle the new Q_magic_macro.
> > If is too much trouble we can use the qnamespace.h hack.
> > 
> >  - add a helper macro/function to register the namespace enums/flags (i.e.
> > 
> > qmlRegisterNamespace or even better qmlRegisterEnums(const QMetaEnum
> > &staticMetaEnum, ....).
> > 
> > I think it depends on QML c++11 scoped enums task, because most probably
> > the enums enumerators names will clash.
> 
> Yes, i think a Q_NAMESPACE would be a nice addition in order to allow Q_ENUM
> at namespace scope.   We have some example for example in the QSsl
> namespace that has enumerations.
> 
> One issue is that moc need to have a complete view of the namespace as it
> generates the QMetaObject for it, so it should not be possible to have
> Q_ENUM in a other header than the one which have the Q_NAMESPACE keyword.

Thanks Olivier!

I created two new taks:
 - https://bugreports.qt.io/browse/QTBUG-54981 (moc part)
 - https://bugreports.qt.io/browse/QTBUG-54982 (qml part)

Cheers,
BogDan.



From michal.klocek at qt.io  Thu Jul 28 10:06:49 2016
From: michal.klocek at qt.io (Michal Klocek)
Date: Thu, 28 Jul 2016 10:06:49 +0200
Subject: [Development] Programs crashing left and right in the CI
In-Reply-To: <CAPm+cvj2P=gJJwuYdJkWXKmHewXk_UwC-heSGTcFBV72fsLHBg@mail.gmail.com>
References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1> <5951295.MVm6SEVxWd@42>
	<10723215.7zoGWthJmd@tjmaciei-mobl1>
	<CAPm+cvgwzQK_TThmmqxkQHWnk+fGsX0Hb4NTnHJUwMaJugDtAg@mail.gmail.com>
	<CAPm+cvhmT=0AnG6FZXvK4j-aGrfKS-AGOhiEkUqWSYLSV24YpQ@mail.gmail.com>
	<CAPm+cvj2P=gJJwuYdJkWXKmHewXk_UwC-heSGTcFBV72fsLHBg@mail.gmail.com>
Message-ID: <5799BD19.5010600@qt.io>

Hi

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.


http://testresults.qt.io/logs/qt/qttools/19be2439dce662a3c2cfee15bce24f8b399c7a45/OSXOSX_10_09x86_64OSXOSX_10_09x86_64Clangqtci-osx-10.9-x86_64Release_NoFramework/f7cbe1e5f2b918c36be693265f81e0e4da6e5658/buildlog.txt.gz

http://testresults.qt.io/coin/logview/qt/qtlocation/4215524eedd8aca38b749b3baba5301d7b5f8745/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRelease_Release/26d001a8dcaf69e4e44fec119fe4c103605013df/buildlog.txt.gz

Br

Mike


From bogdan at kdab.com  Thu Jul 28 10:08:28 2016
From: bogdan at kdab.com (BogDan Vatra)
Date: Thu, 28 Jul 2016 11:08:28 +0300
Subject: [Development] [QML]: Why can't create Q_GADGETs from QML ?
In-Reply-To: <DB4PR02MB0541F37247E2E53D1ADF950E8C0E0@DB4PR02MB0541.eurprd02.prod.outlook.com>
References: <1768132.ztWhMOdFS9@debian>
	<DB4PR02MB0541F37247E2E53D1ADF950E8C0E0@DB4PR02MB0541.eurprd02.prod.outlook.com>
Message-ID: <21617695.oifGpZmFpT@debian>

Hi,

Task created here https://bugreports.qt.io/browse/QTBUG-54983

Cheers,
BogDan.

On marți, 26 iulie 2016 15:37:04 EEST Simon Hausmann wrote:
> Hi,
> 
> 
> No objection per-se, but we'd have to figure out some details. For example
> declarative instantiation is
> 
> not an object, as the ownership rules do not comply with QObject. That would
> leave us with a JavaScript
> 
> constructor function, replacing Qt.point(...) for example. But then we'd
> have to comply with the namespace
> 
> rules, so we'd have
> 
> 
>     qmlRegisterGadget<MyGadget>("MyModule", "ThatName", 1, 0);
> 
> 
> and then
> 
> 
>     import MyModule 1.0
> 
> 
> and in expressions we'd have
> 
> 
>     var g = new ThatName();
> 
> 
> and the same for a namespaced import:
> 
> 
>     import MyModule 1.0 as Foo
> 
> 
>     var g = new Foo.ThatName();
> 
> 
> It's a bit of work to do, but I don't see a problem in principle.
> 
> 
> Simon
> 
> ________________________________
> From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org>
> on behalf of BogDan Vatra <bogdan at kdab.com> Sent: Tuesday, July 26, 2016
> 5:28:35 PM
> To: development at qt-project.org
> Subject: [Development] [QML]: Why can't create Q_GADGETs from QML ?
> 
> Hi,
> 
> Is there any reason why I can only use Q_GADGETs objects in QML, but not to
> create them?
> 
> It will be nice if we can register Q_GADGETs  as qml creatable types too.
> 
> Cheers,
> BogDan.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development




From bogdan at kdab.com  Thu Jul 28 10:14:04 2016
From: bogdan at kdab.com (BogDan Vatra)
Date: Thu, 28 Jul 2016 11:14:04 +0300
Subject: [Development] QML: Why C++11 scoped enums are not scoped in QML?
In-Reply-To: <40c397d4-4b7a-5cf1-f685-2f44f50c7e2d@pelagicore.com>
References: <30621599.Di3TuLGYCH@debian> <2765145.ymZXfK1IRj@maurice>
	<40c397d4-4b7a-5cf1-f685-2f44f50c7e2d@pelagicore.com>
Message-ID: <2891972.MpLORe5y7y@debian>

On joi, 28 iulie 2016 09:52:56 EEST Dominik Holland wrote:
> Am 28.07.16 um 09:41 schrieb Olivier Goffart:
> > On Donnerstag, 28. Juli 2016 10:32:54 CEST BogDan Vatra wrote:
> >> On miercuri, 27 iulie 2016 09:08:32 EEST Thiago Macieira wrote:
> >>> On quarta-feira, 27 de julho de 2016 11:47:03 PDT BogDan Vatra wrote:
> >>>> On miercuri, 27 iulie 2016 10:35:01 EEST André Somers wrote:
> >>>>> Op 27/07/2016 om 09:53 schreef BogDan Vatra:
> >>>>> Would that not break existing QML applications that now use enums
> >>>>> backed
> >>>>> by scoped enums in C++?
> >>>> 
> >>>> It will, but personaly I can't see a better solution ...
> >>> 
> >>> I have already said what to do: make it an opt-in on registration of the
> >>> enum to the QML/JS engine.
> >> 
> >> Got it  :)
> >> 
> >>>> So, either we break the existing QML apps that used scoped enums in C++
> >>>> (which is useless, because in QML side you'll get name clashing) or we
> >>>> keep
> >>>> it as it is now and never "fix" it. I'd like the first option :).
> >>> 
> >>> I really hate it. Breaking applications should not even be an option on
> >>> the
> >>> table. Let's start with "we won't gratuitously break applications" and
> >>> work
> >>> to find a solution from there.
> >>> 
> >>>> Of course if we can find a better solution to have them both is even
> >>>> better
> >>>> !
> >> 
> >> What I was trying to say here is that I'd like to have by default C++11
> >> scoped enums scoped also on QML, but if everybody thinks is a no go, than
> >> we can co the other way around.
> >> 
> >> Anyway, I checked the code a little bit, hopping it will be a few lines
> >> change, but I was so wrong :). I tried to prefix the (scoped) enum keys
> >> with the "EnumName." but of course it didn't worked :D, "EnumName_"
> >> works fine. It seems it needs much love (probably some virtual types
> >> based on
> >> EnumName), unfortunately my QML engine knowledge are too limited to
> >> continue :).
> > 
> > Note that in C++11, all enums can be used scoped. (even the normal ones)
> > I think it would make sens to allow all enum to be used scoped in QML too.
> 
> Mhh how do you make sure that the Enum names are unique ? E.g. having
> two custom Items and both having a Enum in them called Type, what whould
> you get if you do Type.FOO ?
> 
Nothing, C++11 scoped enums just add one more scope of their existing scope. 
So, if you have:
class Type {
enum class Enum {
  FOO
}
};

In C++ you'll need to use *Type.Enum.FOO* to access it, and we want to have 
the *same thing* in QML :).

[...]

Cheers,
BogDan.


From denis.shienkov at gmail.com  Thu Jul 28 14:37:53 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Thu, 28 Jul 2016 15:37:53 +0300
Subject: [Development] [QML] Avoiding graphics flicker in Quick2
Message-ID: <CAHtcb0x3bxLb7LyDGC9Sw6dGjBrDENY9aW_UkNdpx7A=mdrSqQ@mail.gmail.com>

Hi all.

I have some QML application, where just use QQuickView as QML container.
This application uses Qt 5.7.x and running on Linux embedded board with the
NVIDIA core (Toradex Apalis T30).

But sometimes I got flickering in process of animation. A flickering
represents in form of a "white" strips with full-screen width and 1/5-1/6
screen heigth. This flickers happens quickly and frequently (every ~20-60
seconds, randomly)...

I have seen this "Avoiding graphics flicker in Qt / QML" [1] blog where are
used QML with Qt 4.x,
where were used this trics:

{code}
int main(int argc, char **argv)
{
    ...
    view.setAttribute(Qt::WA_OpaquePaintEvent);
    view.setAttribute(Qt::WA_NoSystemBackground);
    view.viewport()->setAttribute(Qt::WA_OpaquePaintEvent);
    view.viewport()->setAttribute(Qt::WA_NoSystemBackground);
    ...
}
{code}

But, in my case I have use Quick v2, with QQuickView instead of
QDeclarativeView,
which does not allowed to setup any attributes.

So, my questions is: is there are any way to setup Qt::WA_OpaquePaintEvent
and/or
Qt::WA_NoSystemBackground in Quck2? Or, maybe is it possible to use another
tricks?

BR,
Denis

[1]
https://blog.rburchell.com/2011/11/avoiding-graphics-flicker-in-qt-qml.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160728/7ad4bf37/attachment.html>

From thiago.macieira at intel.com  Thu Jul 28 19:08:01 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 28 Jul 2016 10:08:01 -0700
Subject: [Development] QtCon rooms for QCS
Message-ID: <8642194.NpyjyqBHBu@tjmaciei-mobl1>

Looking at https://conf.qtcon.org/en/qtcon/public/schedule/2016-09-02 and the 
other days, I see only one room reserved for QCS at any particular hour. We 
usually occupy two or three rooms, based on past QCSs.

Can we have more rooms, please? At least one more, for the entire period.

I'm trying to evaluate if I should even come this time. If QCS is so 
restricted and if I can't arrive in time for the KDE e.V. meeting, it's 
probably not worth my time and money (Intel is not paying for me to go this 
time).

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



From Morten.Sorvig at qt.io  Fri Jul 29 11:57:11 2016
From: Morten.Sorvig at qt.io (Morten Sorvig)
Date: Fri, 29 Jul 2016 09:57:11 +0000
Subject: [Development] QtCon rooms for QCS
In-Reply-To: <8642194.NpyjyqBHBu@tjmaciei-mobl1>
References: <8642194.NpyjyqBHBu@tjmaciei-mobl1>
Message-ID: <E919482B-30D3-414F-BABB-7B286AF91A1B@qt.io>


> On 28 Jul 2016, at 19:08, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> Looking at https://conf.qtcon.org/en/qtcon/public/schedule/2016-09-02 and the 
> other days, I see only one room reserved for QCS at any particular hour. We 
> usually occupy two or three rooms, based on past QCSs.
> 
> Can we have more rooms, please? At least one more, for the entire period.
> 
> I'm trying to evaluate if I should even come this time. If QCS is so 
> restricted and if I can't arrive in time for the KDE e.V. meeting, it's 
> probably not worth my time and money (Intel is not paying for me to go this 
> time).


Is there a sharp division between QtCon and QCS?

I was told I should register my QCS topics for QtCon, which I have. If others
have done the same then rooms may already have been reserved. (An extra free room
for the unconference could not hurt though)

Morten




From robin+qt at viroteck.net  Fri Jul 29 12:49:38 2016
From: robin+qt at viroteck.net (Robin Burchell)
Date: Fri, 29 Jul 2016 12:49:38 +0200
Subject: [Development] [QML] Avoiding graphics flicker in Quick2
In-Reply-To: <CAHtcb0x3bxLb7LyDGC9Sw6dGjBrDENY9aW_UkNdpx7A=mdrSqQ@mail.gmail.com>
References: <CAHtcb0x3bxLb7LyDGC9Sw6dGjBrDENY9aW_UkNdpx7A=mdrSqQ@mail.gmail.com>
Message-ID: <1469789378.2193186.680249033.7DB0AF3B@webmail.messagingengine.com>

On Thu, Jul 28, 2016, at 02:37 PM, Denis Shienkov wrote:
> So, my questions is: is there are any way to setup
> Qt::WA_OpaquePaintEvent
> and/or
> Qt::WA_NoSystemBackground in Quck2? Or, maybe is it possible to use
> another
> tricks?

Ah, the memories. Good times.

Unfortunately for you, QQ2 is a very different beast. Rendering is done
using OpenGL (unless you're using a different scenegraph backend, but
that's probably not very likely right now) and then pushed to the
windowing system of your choice using a QPA plugin via QWindow (how
exactly this is done, of course, depends on your windowing system & the
QPA plugin you are using).

If you're seeing flickering, this means you have four possibilities,
ranked in no real order:

1) OpenGL driver bug (the world is full of them..)
2) Application-side bug (make sure you don't have anything that could be
flickering in your application). Using an overlay to debug item
positions (QSG_VISUALIZE=overdraw) could be handy for trying to rule
this out, as if it is specific to the application, you'd see which part
of the application is flickering - and the overlay wouldn't be affected.
3) A problem or bug with the QPA plugin you're using (you mention
embedded, so I'm going to guess you're using eglfs or something like
that)
4) Relatedly, a problem or bug with the windowing system (particularly
if you're doing something rather custom. If you're using e.g. OS X or
some other mainstream setup though, this is less likely)

-- 
  Robin Burchell
  robin at viroteck.net


From thiago.macieira at intel.com  Fri Jul 29 17:43:32 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 29 Jul 2016 08:43:32 -0700
Subject: [Development] QtCon rooms for QCS
In-Reply-To: <E919482B-30D3-414F-BABB-7B286AF91A1B@qt.io>
References: <8642194.NpyjyqBHBu@tjmaciei-mobl1>
	<E919482B-30D3-414F-BABB-7B286AF91A1B@qt.io>
Message-ID: <2705185.RybRm9rTJg@tjmaciei-mobl1>

On sexta-feira, 29 de julho de 2016 09:57:11 PDT Morten Sorvig wrote:
> > I'm trying to evaluate if I should even come this time. If QCS is so
> > restricted and if I can't arrive in time for the KDE e.V. meeting, it's
> > probably not worth my time and money (Intel is not paying for me to go
> > this
> > time).
> 
> Is there a sharp division between QtCon and QCS?

That's a good question.

> I was told I should register my QCS topics for QtCon, which I have. If
> others have done the same then rooms may already have been reserved. (An
> extra free room for the unconference could not hurt though)

Registering topics is fine, but we always have free rooms for the second half 
of the event because topics turn up. And where is the list of registered 
discussion session topics? I see 11 rooms but I can't tell what's a 
presentation and what's a discussion. If I come, I come to discuss Qt's future 
and I'm not really interested in most presentations (and I'm not presenting 
anything).

I also didn't see a call to register topics. There was a call for papers for 
regular-style presentations, which isn't QCS style and is not what I am 
looking for. I may be mistaken, though.

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