Re: [Development] Gerrit is back
Please accept also my thank You's. The update definitely brings many improvements and much fresh air :) Br, Alessandro Von: Development im Auftrag von Simon Hausmann Gesendet: Donnerstag, 23. Mai 2019 09:32 An: Jukka Jokiniva; development@qt-project.org Betreff: Re: [Development] Gerrit is back Hi, After a few days of usage and getting used to the new UI, I'd like to say that I'm very impressed! This upgrade went smoothly and the new functionality is a real productivity booster. I love the fact that there's now a usable mobile interface. And that I can edit commits to make small changes (typos). And the ability to respond to individual selections of text/code. Oh, and the conflict markers. And and and... :) There are more tweaks that would be nice to apply to the UI to make it better. Does the new version make this any easier? What's your advice for people who'd like to contribute UI tweaks? What's the best way to proceed? (in the sense of empowering potential contributors instead of asking you to do all the changes) Thank you Jukka, Frederik and everyone else who made this happen! Simon From: Development on behalf of Jukka Jokiniva Sent: Monday, May 20, 2019 15:00 To: development@qt-project.org Subject: [Development] Gerrit is back Dear all, we are happy to inform you that Gerrit and COIN are back online and all operation can resume. All access has been restored. Please refer to the public wiki for further information, https://wiki.qt.io/Gerrit_Upgrade_2019. Bug reports and improvement ideas can be reported to bugreports.qt.io (project=QTQAINFRA component= Gerrit). Here is a tiny link: http://tiny.cc/new-qt-gerrit-issue Best regards, your friendly Gerrit admin team. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
> It's good that Bernhard has received an official statement. I agree! Thank you! > In general, I think the Qt Company could make a little more effort to > communicate such decisions, educate its user community, and attract new > potential maintainers. Actually, communication should start before a problem > results in a decision. Isn't that an important aspect of community building? Agreed as well. Assuming that Qt Xml is deprecated as well (still not sure) this is the fourth time a deprecated component tears major holes in my applications. Regarding Qt Xml and Qt Xml Patterns it surprises me a lot since I consider them essential components. I will use the stream classes under no circumstances. This means in my book Qt does not support one of the most important techniques (XML) anymore. Hard to believe. Obviously "no maintainer" is enough for a deprecation. This means (at least for new code) there is no significant difference (only a delay) between "no maintainer" and "deprecated". Thiagos criteria sounded ok but obviously they are not valid anymore. Qt must to be in a very strong market position if such a strategy is accepted. -- Best Regards Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QList for Qt 6
On 2019-05-23 10:40, Lars Knoll wrote:
[...]
4. Use QVector to implement QList, if sizeof(Foo) <=
sizeof(quint64) and Foo is movable. I’m intentionally not using
sizeof(void *) here, as types with sizes between 4 and 8 bytes would
not have stable references in cross platform code, so I do not
believe
lots of code would assume that (or it would have broken on 64 bit).
Agreed. This matches what QList currently does, minus the padding,
which is good.
I tried this, and the problem here is that this requires T to be fully
declared at the time you instantiate QList. This is a source
incompatibility for class declarations such as
class MyClass {
QList list;
};
This worked in Qt 5, but wouldn’t work here anymore as I can’t select
the implementation of QList for a forward declared class.
I agree we should not break this. The standard has just added similar
guarantees for it's own containers.
At the same time, I’m not really willing to compromise on this point,
as I really want to have a zero copy conversion between QList and
QVector for small movable types (the most common case).
I don't see why a zero-copy conversion between QList and QVector for
vector-like QList is needed.
You said that QList should vanish from Qt API. So we don't care. We'll
have that switch to make QList _be_ QVector for ese of porting, but as a
template alias. There's your zero-copy conversion :) That leaves users.
And I repeat: I'd leave QList alone (as QArrayList, possibly with always
IndirectLayout), and just have implicit deprecated conversions between
QArrayList and QVector. You shouldn't care about performance of unported
code: It's easy to target both Qt 5 and Qt 6 if you use auto for
receiving from Qt API. For sending to Qt API, it's a bit more tricky.
You need to ifdef or live with the implicit conversion in a Qt 6 build,
but it's not something that we should optimize for. Really. Don't.
So, I'd try the following:
- have a compile switch that hides QList and replaces it with a template
alias to QVector. This is BC if you compiled with the switch off.
Clients using the alias will never see the QList name, so won't use the
code compiled into QtCore for it. So, no need to make it all-inline.
#if QList-as-QVector
template using QList = QVector;
#else
~~~ QList impl, unchanged, except for implicit deprecated
conversions to/from QVector added ~~~
#endif
- port QtCore away from QList
- flip the switch (in CI) for all other libraries except QtCore (so
QtCore keeps compiling QList in, for other users)
- deal with the fallout
- once reasonably sure all stability-of-reference users have been ported
away from QList, do s/QList/QVector/g when convenient and unflip the
switch in CI
- ok, so keep the switch for final release, buf off (and it never
affects the QtCore build)
- bonus: rename QList to QArrayList, using IndirectLayout
unconditionally, and make the name 'QList' a deprecated template alias
for (depending on compile switch) QArrayList (default) or QVector (for
the fireworks). I'd go to this length _only_ if we think that QArrayList
(always IndirectLayout) is a worthwhile container to have (remember,
there's always vector) and thus it's going to be maintained
going forward. If it's not, I'd leave it as QList and deprecate it.
Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QList for Qt 6
On Thu, May 23, 2019 at 12:15 PM Shawn Rutledge wrote: > > On 23 May 2019, at 07:51, Konstantin Shegunov > wrote: > > Yes, exactly like, though it'd need to regrow automatically; and on > regrow it may need to normalize the order of elements (hence the > "amortized”). > > When should it regrow? It’s part of the definition that it overwrites the > oldest elements when you try to insert too much data. > Yes, I meant specifically for the QQueue, we'd want it to grow so we can accommodate the data. The most obvious thing that comes to mind for the regrowth is when you need an element and the begin iterator (i.e. pointer) is end iterator + 1. It does waste one element, but on the other hand allows to easily distinguish between an empty buffer and a full one. > I’m a big fan of the concept, have actually need one of these several > times, and would like to see it moved to qtbase and made public Makes sense to me. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QList for Qt 6
> On 23 May 2019, at 11:50, Olivier Goffart wrote: > > On 22.05.19 15:49, Lars Knoll wrote: > [...] >> 2. Move QStringList and QByteArrayList over to inherit from QVector (that >> should be source compatible) >> 3. Rename QStringList to QStringVector (keep QStringList as a compatibility >> name), same for QBAList > > I wouldn't do that. > I'd just make using QStringList = QVector; > and let QVector inherit from QVectorSpecialMethods which would be > specialized for QString and QByteArray (similar to what QListSpecialMethods > is today) Of course, that’s what I actually meant :) Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QList for Qt 6
On 22.05.19 15:49, Lars Knoll wrote: [...] 2. Move QStringList and QByteArrayList over to inherit from QVector (that should be source compatible) 3. Rename QStringList to QStringVector (keep QStringList as a compatibility name), same for QBAList I wouldn't do that. I'd just make using QStringList = QVector; and let QVector inherit from QVectorSpecialMethods which would be specialized for QString and QByteArray (similar to what QListSpecialMethods is today) -- Olivier ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QList for Qt 6
> On 23 May 2019, at 07:51, Konstantin Shegunov wrote: > > On Thu, May 23, 2019 at 8:12 AM Mutz, Marc via Development > wrote: > On 2019-05-22 22:38, Konstantin Shegunov wrote: > > What about a rather smart (in terms of storage) circular buffer; a > > vector. Then the push, pop, enqueue and dequeue would be amortized > > O(1)? > > You mean like QCircularBuffer? > > Yes, exactly like, though it'd need to regrow automatically; and on regrow it > may need to normalize the order of elements (hence the "amortized”). When should it regrow? It’s part of the definition that it overwrites the oldest elements when you try to insert too much data. I’m a big fan of the concept, have actually need one of these several times, and would like to see it moved to qtbase and made public, provided that the implementation is efficient and the API is maintainable (including for small numbers of small elements). But we have several of them. The so-called QRingBuffer is a different beast, and I am dubious that it’s the right solution even in its own use cases, let alone for general use. IMO we should try to use a proper ring buffer/circular buffer template container to replace as many of these ring-buffer-like things as possible (there are really several of them). QPODVector velocityBuffer in the flickable implementation is a prime candidate to get replaced, for example (and in other cases where we are smoothing the velocity of something by keeping a running average). Could we even agree that fixed-size (with size as a template parameter) is good enough? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QList for Qt 6
On 23 May 2019, at 10:40, Lars Knoll
mailto:lars.kn...@qt.io>> wrote:
Hi,
Been trying to implement this, and of course there are some complications :)
On 22 May 2019, at 21:36, Mutz, Marc via Development
mailto:development@qt-project.org>> wrote:
Hi Lars,
On 2019-05-22 15:49, Lars Knoll wrote:
Let’s conclude the topic of QList. I do see the concern about silent
source breakages. Here’s what we’ll (I’ll) do then for Qt 6:
1. Rename QList to QArrayList and make QList an alias to QArrayList
Agreed.
2. Move QStringList and QByteArrayList over to inherit from QVector
(that should be source compatible)
Agreed.
3. Rename QStringList to QStringVector (keep QStringList as a
compatibility name), same for QBAList
Not necessary, in my mind (List is a general concept, think ListView, not just
a linked list). But not strongly opposed b/c/o the compat typedef.
4. Use QVector to implement QList, if sizeof(Foo) <=
sizeof(quint64) and Foo is movable. I’m intentionally not using
sizeof(void *) here, as types with sizes between 4 and 8 bytes would
not have stable references in cross platform code, so I do not believe
lots of code would assume that (or it would have broken on 64 bit).
Agreed. This matches what QList currently does, minus the padding, which is
good.
I tried this, and the problem here is that this requires T to be fully declared
at the time you instantiate QList. This is a source incompatibility for
class declarations such as
class MyClass {
QList list;
};
This worked in Qt 5, but wouldn’t work here anymore as I can’t select the
implementation of QList for a forward declared class.
At the same time, I’m not really willing to compromise on this point, as I
really want to have a zero copy conversion between QList and QVector for small
movable types (the most common case).
See https://codereview.qt-project.org/c/qt/qtbase/+/262602 for a WIP change
implementing this.
5. Add a compile time switch that allows mapping QList completely to
QVector or to a compatibility mode where QLists of large/non movable
types are mapped to QArrayList
I agree with the compile-time switch, provided a) it defaults to QList as per
(4), otherwise QArrayList (iow: Q5List behaviour minus the padding) and b) the
switch goes away before Qt 6.0.0 is released. I see this as a way to help
wip/qt6 get to all-vector APIs without breaking the world. So CI on wip/qt6
would flip the switch to all-vector to see what breaks, at the same time the
default would be to keep Q5List-mod-padding to not destroy git-bisect-ability
across wip/qt6 commits.
6. For now we don’t yet want to explicitly change all our API that
uses QList to use QVector (as that would make merging from dev a pain,
let’s do that later this year). But to test that everything we have
works with QVector, we’ll set the compile switch to default to mapping
to QVector.
This is the only reason why I'd accept a compile switch, and that's why I'd
very much like it to be gone by Qt 6, and why I think it shouldn't default to
QVector. The CI can test with that (and with the old behaviour), individual
developers may choose what they want, too, but the default for the wider
audience tracking development should be backwards-compat. We don't want Qt to
break for everyone because a few people are trying to eradicate the last
reference-stability users.
I don’t see why you’d want to remove the switch for Qt 6. It would be a porting
help for application developers.
7. Make the implementation of QArrayList fully inline and deprecate the class.
I don't think it needs to be fully inline, but I'm not opposed. If it's called
QArrayList and always heap-allocates, incl. for , I'm also not sure it
needs deprecating.
Let’s see. I agree that we should in this case consider it always using
IndirectLayout to make it consistent and easy to understand.
Cheers,
Lars
Let me know if there are any major concerns with this plan. It should
give us a good compromise, where we can move all of Qt over to QVector
and test things early, as well as providing a compatibility mode for
our users (slower but won’t silently break).
To summarize: I agree with the plan, provided QList in Qt 6.0.0 unconditionally
behaves like Q5List-mod-padding (upping the trigger from sizeof(void*) to 8 is
ok, too), QList as as name is deprecated and as any type has implicit
deprecated conversions from/to QVector.
Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QList for Qt 6
Hi,
Been trying to implement this, and of course there are some complications :)
> On 22 May 2019, at 21:36, Mutz, Marc via Development
> wrote:
>
> Hi Lars,
>
> On 2019-05-22 15:49, Lars Knoll wrote:
>> Let’s conclude the topic of QList. I do see the concern about silent
>> source breakages. Here’s what we’ll (I’ll) do then for Qt 6:
>> 1. Rename QList to QArrayList and make QList an alias to QArrayList
>
> Agreed.
>
>> 2. Move QStringList and QByteArrayList over to inherit from QVector
>> (that should be source compatible)
>
> Agreed.
>
>> 3. Rename QStringList to QStringVector (keep QStringList as a
>> compatibility name), same for QBAList
>
> Not necessary, in my mind (List is a general concept, think ListView, not
> just a linked list). But not strongly opposed b/c/o the compat typedef.
>
>> 4. Use QVector to implement QList, if sizeof(Foo) <=
>> sizeof(quint64) and Foo is movable. I’m intentionally not using
>> sizeof(void *) here, as types with sizes between 4 and 8 bytes would
>> not have stable references in cross platform code, so I do not believe
>> lots of code would assume that (or it would have broken on 64 bit).
>
> Agreed. This matches what QList currently does, minus the padding, which is
> good.
I tried this, and the problem here is that this requires T to be fully declared
at the time you instantiate QList. This is a source incompatibility for
class declarations such as
class MyClass {
QList list;
};
This worked in Qt 5, but wouldn’t work here anymore as I can’t select the
implementation of QList for a forward declared class.
At the same time, I’m not really willing to compromise on this point, as I
really want to have a zero copy conversion between QList and QVector for small
movable types (the most common case).
>
>> 5. Add a compile time switch that allows mapping QList completely to
>> QVector or to a compatibility mode where QLists of large/non movable
>> types are mapped to QArrayList
>
> I agree with the compile-time switch, provided a) it defaults to QList as per
> (4), otherwise QArrayList (iow: Q5List behaviour minus the padding) and b)
> the switch goes away before Qt 6.0.0 is released. I see this as a way to help
> wip/qt6 get to all-vector APIs without breaking the world. So CI on wip/qt6
> would flip the switch to all-vector to see what breaks, at the same time the
> default would be to keep Q5List-mod-padding to not destroy git-bisect-ability
> across wip/qt6 commits.
>
>> 6. For now we don’t yet want to explicitly change all our API that
>> uses QList to use QVector (as that would make merging from dev a pain,
>> let’s do that later this year). But to test that everything we have
>> works with QVector, we’ll set the compile switch to default to mapping
>> to QVector.
>
> This is the only reason why I'd accept a compile switch, and that's why I'd
> very much like it to be gone by Qt 6, and why I think it shouldn't default to
> QVector. The CI can test with that (and with the old behaviour), individual
> developers may choose what they want, too, but the default for the wider
> audience tracking development should be backwards-compat. We don't want Qt to
> break for everyone because a few people are trying to eradicate the last
> reference-stability users.
I don’t see why you’d want to remove the switch for Qt 6. It would be a porting
help for application developers.
>
>> 7. Make the implementation of QArrayList fully inline and deprecate the
>> class.
>
> I don't think it needs to be fully inline, but I'm not opposed. If it's
> called QArrayList and always heap-allocates, incl. for , I'm also not
> sure it needs deprecating.
Let’s see. I agree that we should in this case consider it always using
IndirectLayout to make it consistent and easy to understand.
Cheers,
Lars
>
>> Let me know if there are any major concerns with this plan. It should
>> give us a good compromise, where we can move all of Qt over to QVector
>> and test things early, as well as providing a compatibility mode for
>> our users (slower but won’t silently break).
>
> To summarize: I agree with the plan, provided QList in Qt 6.0.0
> unconditionally behaves like Q5List-mod-padding (upping the trigger from
> sizeof(void*) to 8 is ok, too), QList as as name is deprecated and as any
> type has implicit deprecated conversions from/to QVector.
>
> Thanks,
> Marc
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] What's the status of a moved-from object?
Hi, I favor a well-formed (null) state over a partially-formed state. I agree with the suggestion of adding null pointer checks into member functions where applicable. I think a well-formed state is more likely to enable our users to have a productive time. Operating - by accident - on a partially-formed object and either (1) seeing a back-trace that points into Qt, not my application code (2) spending time in the debugger stepping through Qt code is IMHO a direction that we should avoid. Simon From: Development on behalf of Giuseppe D'Angelo via Development Sent: Sunday, May 19, 2019 14:24 To: development@qt-project.org Subject: [Development] What's the status of a moved-from object? Hi, I'm trying to find a resolution for > https://codereview.qt-project.org/#/c/261564/ TL;DR: the patch removes the move constructor from QColorSpace, because that move constructor leaves the moved-from object in a partially-formed state. I have nothing against that idea (on the contrary), but I am against the principle of introducing such inconsistencies in Qt without a previous agreement. Hence, I'll ask here: what should the status of a moved-from object be? I'm not really interested in _how_ to achieve such status (although of course it's very important, and should influence the decision); I'm interested in what's our contract with our users. A few datapoints for discussion are in the patch comments. Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Gerrit is back
Hi, After a few days of usage and getting used to the new UI, I'd like to say that I'm very impressed! This upgrade went smoothly and the new functionality is a real productivity booster. I love the fact that there's now a usable mobile interface. And that I can edit commits to make small changes (typos). And the ability to respond to individual selections of text/code. Oh, and the conflict markers. And and and... :) There are more tweaks that would be nice to apply to the UI to make it better. Does the new version make this any easier? What's your advice for people who'd like to contribute UI tweaks? What's the best way to proceed? (in the sense of empowering potential contributors instead of asking you to do all the changes) Thank you Jukka, Frederik and everyone else who made this happen! Simon From: Development on behalf of Jukka Jokiniva Sent: Monday, May 20, 2019 15:00 To: development@qt-project.org Subject: [Development] Gerrit is back Dear all, we are happy to inform you that Gerrit and COIN are back online and all operation can resume. All access has been restored. Please refer to the public wiki for further information, https://wiki.qt.io/Gerrit_Upgrade_2019. Bug reports and improvement ideas can be reported to bugreports.qt.io (project=QTQAINFRA component= Gerrit). Here is a tiny link: http://tiny.cc/new-qt-gerrit-issue Best regards, your friendly Gerrit admin team. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
