Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

2015-07-13 Thread Thiago Macieira
On Monday 13 July 2015 08:26:09 Gunnar Roth wrote: > Hi Thiago > > > Am 12.07.2015 um 19:42 schrieb Thiago Macieira > > : > > > > On Sunday 12 July 2015 16:57:39 Gunnar Roth wrote: > >> "QMap_insert -- 1 > >> ","WalltimeMilliseconds",0.625,80,128 > > > > Please run with -perf

Re: [Development] QML CameraimageProcessing

2015-07-13 Thread Lopes Yoann
> On 13 Jul 2015, at 04:24, Matías Néstor Ares wrote: > > No matter what is set on imageProcessing (saturation, contrast, etc) there > are no changes in the images. > > My question is: Do this feature work? if it is the case, is there something > else to include in addition to the examples cod

Re: [Development] New headers popping up: possibly missing a build dependency?

2015-07-13 Thread Oswald Buddenhagen
On Sun, Jul 12, 2015 at 10:48:10AM -0700, Thiago Macieira wrote: > On Sunday 12 July 2015 14:18:04 Lisandro Damián Nicanor Pérez Meyer wrote: > > While preparing qtbase for a Debian upload on a not-so-clean chroot I've > > got: > > > > QtPlatformSupport: created fwd-include header(s) for > > /src/

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

2015-07-13 Thread Giuseppe D'Angelo
Il 12/07/2015 23:19, Alejandro Exojo ha scritto: El Sunday 12 July 2015, Thiago Macieira escribió: On Sunday 12 July 2015 16:16:07 Smith Martin wrote: I can see by your explanation that QVector is almost always more efficient than QList. But sometimes the difference doesn't matter. If it does

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

2015-07-13 Thread Ulf Hermann
Mind that all this talk about QList being bad does *not* hold for primitively movable types of exactly sizeof(void *). For example QByteArray, which only consists of a single d-pointer. For those the disadvantages of QList against QVector don't manifest themselves, but the generated code is smal

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

2015-07-13 Thread Milian Wolff
On Monday 13 July 2015 13:26:03 Ulf Hermann wrote: > Mind that all this talk about QList being bad does *not* hold for > primitively movable types of exactly sizeof(void *). For example > QByteArray, which only consists of a single d-pointer. For those the > disadvantages of QList against QVector d

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

2015-07-13 Thread Marc Mutz
On Monday 13 July 2015 14:42:38 Milian Wolff wrote: > and `strip` the binaries afterwards. So it's still ~2KB worse off - any > chance for using `extern templates` or similar to reduce this code bloat? Might work for QList, but for most types, no. Explicitly instantiating QList also instantiates

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

2015-07-13 Thread Иван Комиссаров
AFAIK unused methods doesn't get instantiated, am i wrong? 2015-07-13 18:09 GMT+03:00 Marc Mutz : > On Monday 13 July 2015 14:42:38 Milian Wolff wrote: > > and `strip` the binaries afterwards. So it's still ~2KB worse off - any > > chance for using `extern templates` or similar to reduce this co

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

2015-07-13 Thread Marc Mutz
On Monday 13 July 2015 16:04:44 Иван Комиссаров wrote: > AFAIK unused methods doesn't get instantiated, am i wrong? You're thinking about normal instantiation as-you-go. I was talking about explict instantiation (required when using extern templates (forbidding to instantiate) in the header. --

Re: [Development] New headers popping up: possibly missing a build dependency?

2015-07-13 Thread Thiago Macieira
On Monday 13 July 2015 10:24:40 Oswald Buddenhagen wrote: > that's not the solution. > if the headers actually *are* supposed to be distributed, they need to > be pre-declared. > if they are supposed to be private, they need to be excluded. > both are changes to be done in sync.profile. Those are

Re: [Development] New headers popping up: possibly missing a build dependency?

2015-07-13 Thread Oswald Buddenhagen
On Mon, Jul 13, 2015 at 07:28:38AM -0700, Thiago Macieira wrote: > On Monday 13 July 2015 10:24:40 Oswald Buddenhagen wrote: > > that's not the solution. > > if the headers actually *are* supposed to be distributed, they need to > > be pre-declared. > > if they are supposed to be private, they need

[Development] ios build issues

2015-07-13 Thread Hausmann Simon
‎Hi, We're seeing odd build issues on ios in declarative since this morning. The forwarded email below contain more details as well as a link to the complete build log. Does anyone have an idea what could cause this? There is no stale state on the virtual machine, it's created and booted from

[Development] 5.5 CI having problems on tst_qmimedatabase-xml

2015-07-13 Thread Thiago Macieira
This test began failing about a week ago, for no apparent reason. I don't think it's a Qt issue, but more of a CI issue. It's failing on: FAIL! : tst_QMimeDatabase::initTestCase() 'm_temporaryDir.isValid()' returned FALSE. () c: \work\build\qt\qtbase\tests\auto\corelib\mimetypes\qmimedatabase\

Re: [Development] QML CameraimageProcessing

2015-07-13 Thread Matías Néstor Ares
Thank you for the info Yoann. Is there some place to take a look to a list of supported features and available platforms? Best Regards 2015-07-13 4:28 GMT-03:00 Lopes Yoann : > > On 13 Jul 2015, at 04:24, Matías Néstor Ares wrote: > > > > No matter what is set on imageProcessing (saturation, c

Re: [Development] 5.5 CI having problems on tst_qmimedatabase-xml

2015-07-13 Thread Thiago Macieira
On Monday 13 July 2015 14:48:40 Thiago Macieira wrote: > This test began failing about a week ago, for no apparent reason. I don't > think it's a Qt issue, but more of a CI issue. > > It's failing on: > > FAIL! : tst_QMimeDatabase::initTestCase() 'm_temporaryDir.isValid()' > returned FALSE. () >

Re: [Development] Qt LTS & C++11 plans

2015-07-13 Thread Thiago Macieira
On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote: > The only compiler I currently know that will have problems with this is the > Intel compiler on OS X when using libc++ older than Subversion r215305. > Unfortunately, _LIBCPP_VERSION has been at value 1101 since way before that > change.