Re: [Development] Qt 5.10 schedule etc
Hi, On 08/08/2017 17:56, Allan Sandfeld Jensen wrote: On Dienstag, 8. August 2017 10:41:02 CEST Jani Heikkinen wrote: Hi all, We should have FF & branching today. Unfortunately we are still fighting with some issues in qt5.git integration in 'dev' . That's why we haven't been able to start soft branching yet :( But that doesn't mean we will officially delay the FF ;) So let's freeze new features for Qt 5.10 today as planned. Please don't put any new features in for 5.10 anymore. We will start soft branching immediately when issues with qt5.git integration in' dev' are solved. And we will finalize branching ~ after a week from that date when soft branching starts. So there will be still enough time to get changes in which are currently suffering these issues in dev. I would suggest allowing features that couldnt get in due to git issues, still be allowed to integrate once it is fixed. I don't know of anything specific that has been caught by that though. +1 and on a related note, I keep hitting: Project ERROR: Cannot run compiler '/home/qt/work/b2qt/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++'. Maybe you forgot to setup the environment? when attempting to integrate changes to Qt 3D (for the skeletal animation feature). Could somebody with CI-fu take a look please? Thanks! Sean -- Dr Sean Harmer | sean.har...@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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Tuesday, 8 August 2017 08:49:36 PDT Edward Welbourne wrote:
> Thiago Macieira (7 August 2017 06:14)
>
> > ... there are bigger problems with the implementation, starting with
> > QAbstractCalendar having a static protected QMap member.
>
> That's my fault. We're going to need some way for QML/V4 to get at
> calendars; and I want to ensure our design leaves scope for client code
[cut]
>
> Please suggest a better solution (and explain the problem with the
> present solution), either here or in the review.
The problem is the presence of a protected, static, non-POD member. Remove it.
Store the data in a Q_GLOBAL_STATIC in qabstractcalendar.cpp. If you need to
get a listing or do any kind of searching, add static functions to
QAbstractCalendar. See QTextCodec for inspiration.
> > The big problem is how you've implemented the new API in QDateTime and
> > QLocale. There's code duplication that cannot be there in QLocale,
>
> That's probably best addressed by you commenting on the review; I'm not
> sure what duplication you're referring to ("cannot be there" is strong
> language), although I do know about dateTimeToString(). There are a few
> places I expect to find myself doing clean-up in the aftermath of
> getting this all in, but I don't mind doing some of it before-hand.
The big code block that was added in the commit to qlocale.cpp looks like a
copy & paste of existing code.
> Note, also, that this moves calendar-related data out of QLocale's
> CLDR-derived data blob into calendar-specific data blobs - a step in the
> general direction of making QLocale less monolithic.
That's good.
> > but the way you've removed the duplication in QDateTime also needs
> > changing for performance reasons.
> >
> > int QDate::year() const
> > {
> > return year(QGregorianCalendar());
> > }
> >
> > This creates a polymorphic object and makes a call that ends up delegating
> > to it in
> >
> > if (cal.julianDayToDate(jd, y, m, d))
>
> Please elaborate: why is this a problem ? The Gregorian arithmetic
> naturally belongs in a calendar implementation. The date-time code
> should naturally call it, rather than duplicating it in static functions
> of its own (which have, naturally, been moved to become its methods).
The problems are:
- creating a polymorphic type (QGregorianCalendar) [performance]
- passing it by reference instead of a pointer [coding style]
- calling a non-inline function to do the calculation [performance]
The performance problems are due to performance regressions. I'd rather you
inverted the deduplication: let QDate have the calculation and call that from
QGregorianCalendar.
> > The commit also includes changes that look like unrelated clean-ups and
> > will need to be split into different commits.
>
> Please point these out on the review. Some of them might not be as
> unrelated as you think - I did a fair bit of pulling separable changes
> out already, rebasing Soroush's work onto the results. I may well have
> missed some, but there were bits that couldn't be separated.
I will.
> > It's at this point lacking documentation
>
> Indeed, there remains work to be done. On the other hand, deciding what
> shape the API should be is worth doing before taking pains over
> documenting every detail - that would all change if we decide we need to
> change the API.
Sure. I just replied here because it looked like it was a request to make it
before the FF.
>
> > and there are a couple of coding style mistakes.
>
> Please note in Gerrit.
s/\w& / &/g
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.10 schedule etc
On Dienstag, 8. August 2017 10:41:02 CEST Jani Heikkinen wrote: > Hi all, > > We should have FF & branching today. Unfortunately we are still fighting > with some issues in qt5.git integration in 'dev' . That's why we haven't > been able to start soft branching yet :( But that doesn't mean we will > officially delay the FF ;) > > So let's freeze new features for Qt 5.10 today as planned. Please don't put > any new features in for 5.10 anymore. We will start soft branching > immediately when issues with qt5.git integration in' dev' are solved. And > we will finalize branching ~ after a week from that date when soft > branching starts. So there will be still enough time to get changes in > which are currently suffering these issues in dev. > I would suggest allowing features that couldnt get in due to git issues, still be allowed to integrate once it is fixed. I don't know of anything specific that has been caught by that though. 'Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
Thiago Macieira (7 August 2017 06:14)
> ... there are bigger problems with the implementation, starting with
> QAbstractCalendar having a static protected QMap member.
That's my fault. We're going to need some way for QML/V4 to get at
calendars; and I want to ensure our design leaves scope for client code
to provide a calendar of its choice - e.g. so that a developer whose
target market uses a relatively obscure calendar can support them with a
minimum of pain, without Qt itself needing to contain code for every
calendar that ever has been or will be invented. (Conversely, of
course, it's also worth making it easy to configure which, of the
calendar implementations present in Qt, actually get compiled into any
given build.) Each calendar implementation needs a way to make itself
visible to QML/V4.
My naive idea for how to solve that was to let each calendar
implementation register a factory for its objects under a name
representing its calendar. Then QML/V4 (and, for that matter, C++ APIs)
can look up a calendar by name and get a calendar object to use.
Indeed, we can even consult the map for a list of supported calendars,
to populate a UI's drop-down to select which to use.
Please suggest a better solution (and explain the problem with the
present solution), either here or in the review.
> The big problem is how you've implemented the new API in QDateTime and
> QLocale. There's code duplication that cannot be there in QLocale,
That's probably best addressed by you commenting on the review; I'm not
sure what duplication you're referring to ("cannot be there" is strong
language), although I do know about dateTimeToString(). There are a few
places I expect to find myself doing clean-up in the aftermath of
getting this all in, but I don't mind doing some of it before-hand.
Note, also, that this moves calendar-related data out of QLocale's
CLDR-derived data blob into calendar-specific data blobs - a step in the
general direction of making QLocale less monolithic.
> but the way you've removed the duplication in QDateTime also needs
> changing for performance reasons.
>
> int QDate::year() const
> {
> return year(QGregorianCalendar());
> }
>
> This creates a polymorphic object and makes a call that ends up delegating to
> it in
>
> if (cal.julianDayToDate(jd, y, m, d))
Please elaborate: why is this a problem ? The Gregorian arithmetic
naturally belongs in a calendar implementation. The date-time code
should naturally call it, rather than duplicating it in static functions
of its own (which have, naturally, been moved to become its methods).
> The commit also includes changes that look like unrelated clean-ups and will
> need to be split into different commits.
Please point these out on the review. Some of them might not be as
unrelated as you think - I did a fair bit of pulling separable changes
out already, rebasing Soroush's work onto the results. I may well have
missed some, but there were bits that couldn't be separated.
> It's at this point lacking documentation
Indeed, there remains work to be done. On the other hand, deciding what
shape the API should be is worth doing before taking pains over
documenting every detail - that would all change if we decide we need to
change the API.
> and there are a couple of coding style mistakes.
Please note in Gerrit.
Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] State of 5.9 and dev branches
The dev merge went in, too, so qtbase dev is working again as well. Thanks everyone :) Simon From: Development on behalf of Simon Hausmann Sent: Tuesday, August 8, 2017 9:40:33 AM To: Thiago Macieira; development@qt-project.org Subject: Re: [Development] State of 5.9 and dev branches Thank you Thiago, Sergio and Lars! qtbase 5.6 and 5.9 are good again. Simon From: Development on behalf of Thiago Macieira Sent: Monday, August 7, 2017 10:54:22 PM To: development@qt-project.org Subject: Re: [Development] State of 5.9 and dev branches On Monday, 7 August 2017 13:36:19 PDT Simon Hausmann wrote: > Hi, > > The 5.9 fix went in. Would be most grateful if somebody could do the cherry > pick and merge. I won't have a keyboard until tomorrow late morning. 5.6: https://codereview.qt-project.org/201945 dev: https://codereview.qt-project.org/201946 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] State of 5.9 and dev branches
Hi, I think that's a good idea, although I prefer the approach of making the test adapt the expected output relative to the current time instead of replacing the library state with mock data. Simon From: Development on behalf of Morten Sørvig Sent: Tuesday, August 8, 2017 12:11:13 PM To: development@qt-project.org Subject: Re: [Development] State of 5.9 and dev branches Thanks for cleaning this up quickly! When it comes to testing, do we want to go one step further and make the tests be completely independent of the current time? We would like to avoid time bombs like these, and if something _is_ going to fail at some future date we would like to know so right away. I coded up a strawman proposal here: https://codereview.qt-project.org/201989 It adds a RAII class to QTestLib that allows setting the datetime (as returned by QDateTime) for the duration of a test function: QTestTimeFixer fixedTime(QDateTime(QDate(2015, 1, 1)).toMSecsSinceEpoch()); This is then used to set the date time to sometime in the past for tst_qnetworkcookiejar, which makes the unpatched version of it pass. Going further we could set the time to the future and verify that the cookies expire as expected. Morten > On 8 Aug 2017, at 09:40, Simon Hausmann wrote: > > > Thank you Thiago, Sergio and Lars! > > qtbase 5.6 and 5.9 are good again. > > Simon > From: Development > on behalf of Thiago Macieira > Sent: Monday, August 7, 2017 10:54:22 PM > To: development@qt-project.org > Subject: Re: [Development] State of 5.9 and dev branches > > On Monday, 7 August 2017 13:36:19 PDT Simon Hausmann wrote: > > Hi, > > > > The 5.9 fix went in. Would be most grateful if somebody could do the cherry > > pick and merge. I won't have a keyboard until tomorrow late morning. > > 5.6: https://codereview.qt-project.org/201945 > dev: https://codereview.qt-project.org/201946 > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] State of 5.9 and dev branches
Thanks for cleaning this up quickly! When it comes to testing, do we want to go one step further and make the tests be completely independent of the current time? We would like to avoid time bombs like these, and if something _is_ going to fail at some future date we would like to know so right away. I coded up a strawman proposal here: https://codereview.qt-project.org/201989 It adds a RAII class to QTestLib that allows setting the datetime (as returned by QDateTime) for the duration of a test function: QTestTimeFixer fixedTime(QDateTime(QDate(2015, 1, 1)).toMSecsSinceEpoch()); This is then used to set the date time to sometime in the past for tst_qnetworkcookiejar, which makes the unpatched version of it pass. Going further we could set the time to the future and verify that the cookies expire as expected. Morten > On 8 Aug 2017, at 09:40, Simon Hausmann wrote: > > > Thank you Thiago, Sergio and Lars! > > qtbase 5.6 and 5.9 are good again. > > Simon > From: Development > on behalf of Thiago Macieira > Sent: Monday, August 7, 2017 10:54:22 PM > To: development@qt-project.org > Subject: Re: [Development] State of 5.9 and dev branches > > On Monday, 7 August 2017 13:36:19 PDT Simon Hausmann wrote: > > Hi, > > > > The 5.9 fix went in. Would be most grateful if somebody could do the cherry > > pick and merge. I won't have a keyboard until tomorrow late morning. > > 5.6: https://codereview.qt-project.org/201945 > dev: https://codereview.qt-project.org/201946 > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.10 schedule etc
Hi all,
We should have FF & branching today. Unfortunately we are still fighting with
some issues in qt5.git integration in 'dev' . That's why we haven't been able
to start soft branching yet :( But that doesn't mean we will officially delay
the FF ;)
So let's freeze new features for Qt 5.10 today as planned. Please don't put any
new features in for 5.10 anymore. We will start soft branching immediately when
issues with qt5.git integration in' dev' are solved. And we will finalize
branching ~ after a week from that date when soft branching starts. So there
will be still enough time to get changes in which are currently suffering these
issues in dev.
br,
Jani
From: Development on
behalf of Jani Heikkinen
Sent: Tuesday, August 1, 2017 9:55 AM
To: development@qt-project.org
Cc: releas...@qt-project.org
Subject: [Development] Qt 5.10 schedule etc
Hi all,
Kindly reminder: According to schedule we should have Qt 5.10 feature freeze
after a week, see https://wiki.qt.io/Qt_5.10_Release. So it is time to do
remaining finalizations to 5.10 new features now and focus to bug fixing after
that. Please fill new features page now as well
(https://wiki.qt.io/New_Features_in_Qt_5.10); it seems to be quite empty at the
moment.
And we should start soft branching today. But as Frederik informed yesterday we
are planning to do some changes to coin infrastructure during this week (see
http://lists.qt-project.org/pipermail/development/2017-July/030596.html). So
let's postpone the start of soft branching a bit and do it after coin infra
changes are in & working. Doing one more branch just now makes these coin
changes more difficult & most probably causes more delays in the future.
So the plan with 5.10 is following:
1. Let's keep the agreed ff as it is (8.8.2017)
2. Get first 5.10 binary snapshot from 'dev' out as soon as possible
3. Start soft branching (from 'dev' to '5.10') immediately after coin infra
changes are in & every branch ('5.6', 5.9' & 'dev') is working ok with infra
changes
4. Finalize branching (~ a week from soft branching)
5. Release Qt 5.10 alpha as soon as possible after the branching. We should be
able to do this quite quickly; As usual Alpha will be src packages only and we
can already create needed ones from 'dev'.
* Most probably we should be able to deliver binary snapshot with alpha as
well. If not just at same time then quite soon after the release...
br,
Jani
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] State of 5.9 and dev branches
Thank you Thiago, Sergio and Lars! qtbase 5.6 and 5.9 are good again. Simon From: Development on behalf of Thiago Macieira Sent: Monday, August 7, 2017 10:54:22 PM To: development@qt-project.org Subject: Re: [Development] State of 5.9 and dev branches On Monday, 7 August 2017 13:36:19 PDT Simon Hausmann wrote: > Hi, > > The 5.9 fix went in. Would be most grateful if somebody could do the cherry > pick and merge. I won't have a keyboard until tomorrow late morning. 5.6: https://codereview.qt-project.org/201945 dev: https://codereview.qt-project.org/201946 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
