Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-15 Thread Marc Mutz via Development 
HI Thiago,

On 15.11.22 17:33, Thiago Macieira wrote:
> On Tuesday, 15 November 2022 01:42:55 PST Marc Mutz via Development wrote:
>>> Returning as an iteratable interface requires that we return a proxy
>>> object, like QRegularExpressionMatch, so that the solution is
>>> thread-safe. This is neither simple to understand, to code, or to port
>>> existing code over to. It also requires copying the data over (hopefully,
>>> implicitly) to the proxy object, so it doesn't solve anything.
>>
>> I disagree on all points. QREM is complicated because we need to
>> shoehorn a coroutine into an iterator concept. Same with
>> QStringTokenizer. Coroutines with lazy sequences (generator<>) are very easy
>> to implement and use.
>>
>> If we're to discuss further, please watch my Meeting C++ presentation,
>> which lays out all the pros and cons I'm aware of. No need to re-iterate
>> them in text here. https://youtu.be/tvdwYwTyrig
> 
> It will take some time to watch it.

Thanks. 2× is about the right speed :)

> In the meantime, I'd appreciate a short answer on how you return the keys from
> a stored associative map,

   std::generator func() {
  for (auto &[key, value] : m_assoc_cont)
  co_yield key;
   }

> in a thread-safe manner (such that if something in
> the same thread or another thread-safely modifies that map, the original user
> isn't affected).

The above isn't thread-safe, it isn't even re-entrant, in the same way 
that iteration using iterators isn't. This is a known issue whenever you 
hand out references, and it's nothing that violates our 
const-is-thread-safe promise, otherwise

 static const QMap map = ~~~;
 // T1
 map["x"].size();

would also be affected. The promise doesn't end when you return from the 
const member function, it extends to references handed out in the 
process (op[], begin, end, any lazy sequence).

Of course, in special cases where you have the need for actual 
thread-safety, some form of owning container will be required. But then 
we're talking about maybe 0,1% of all APIs, if even that many.

> Because you pointed to QStringTokenizer and that implicitly-
> copies a QString.

That's imprecise. QStringTokenizer extends rvalue lifetimes ("rvalue 
pinning") so's to make this safe:

for (auto part : qTokenize(label->text(), u';'))

even though the return value of label->text() would ordinarily be 
destroyed at the end of the full-expression, which, seeing the way 
ranged-for is specified:

{
auto && __range = qTokenize(label->text(), u';');
// would be here
auto __begin = begin-expr(__range);
auto __end = end-expr(__range);
while (__begin != __end) {
decl = *__begin;
++__begin;
}
}

iow: too early. It does this only for rvalue owning containers, not for 
lvalues and not for views (!borrowed_range in C++20 ranges parlor). This 
has nothing to do with multi-threading.

Thanks,
Marc

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B

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

Re: [Development] Problems porting Qt5.15 to Qt 6.2 for OS/2

2022-11-15 Thread Paul Smedley 

Thanks Alexey and Fabian - this worked a treat!

On 15/11/22 20:08, Fabian Kosmale via Development wrote:

Hi,

to expand on what Alexey said: Without linking against Qt::Gui, you will 
not have qpa in your include paths, which in turn means that 
QPlatformIntegrationFactoryInterface_iid  won't be macro-expanded to the 
string literals that is defined in qplatformintegrationplugin.h. In 
turn, moc will complain because it is expecting a string literal after IID.


Regards,
Fabian

On 15.11.22 10:28, Alexey Edelev via Development wrote:

Hi,

Please try to add
LIBRARIES
Qt::Gui

to the qt_internal_add_plugin call in 
https://github.com/psmedley/qt6-os2/blob/main/src/plugins/platforms/os2/CMakeLists.txt 


Regards,
Alexey.


*From:* Development  on behalf of 
Paul Smedley 

*Sent:* Tuesday, November 15, 2022 10:01 AM
*To:* development@qt-project.org 
*Subject:* [Development] Problems porting Qt5.15 to Qt 6.2 for OS/2
Hi All,

I'm attempting to update the OS/2 port of Qt 5.15
(https://github.com/bitwiseworks/qtbase-os2 
) to Qt 6.2.4
(https://github.com/psmedley/qt6-os2 
)


Things are going pretty well and I have a number of DLLs built, howeever
I'm now stuck on building the OS/2 plugin.

I'm getting the following:

AutoMoc subprocess error

The moc process failed to compile
    "SRC:/src/plugins/platforms/os2/main.cpp"
into

"SRC:/build/src/plugins/platforms/os2/QOS2IntegrationPlugin_autogen/include/main.moc"
included by
    "SRC:/src/plugins/platforms/os2/main.cpp"

Command
---
U:/DEV/qtbase-everywhere-src-6.2.4/build/bin/moc.exe
-DQOS2IntegrationPlugin_EXPORTS -DQT_DEPRECATED_WARNINGS
-DQT_DEPRECATED_WARNINGS_SINCE=0x06
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_DEBUG -DQT_NO_EXCEPTIONS
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT
-DQT_PLUGIN
-IU:/DEV/qtbase-everywhere-src-6.2.4/src/plugins/platforms/os2
-IU:/DEV/qtbase-everywhere-src-6.2.4/build/src/plugins/platforms/os2
-IU:/DEV/qtbase-everywhere-src-6.2.4/build/include
-IU:/DEV/qtbase-everywhere-src-6.2.4/mkspecs/os2-g++ -Iu:/extras/include
-Iu:/openldap/include -Iu:/usr/include -IU:/OS2TK45/H
-IU:/usr/local1220/include/c++/12.2.0
-IU:/usr/local1220/include/c++/12.2.0/i686-pc-os2-emx
-IU:/usr/local1220/include/c++/12.2.0/backward
-IU:/usr/local1220/lib/gcc/i686-pc-os2-emx/12.2.0/include
-IU:/usr/local1220/lib/gcc/i686-pc-os2-emx/12.2.0/include-fixed
-I/usr/local/include -IU:/usr/local1220/include --include
U:/DEV/qtbase-everywhere-src-6.2.4/build/src/plugins/platforms/os2/QOS2IntegrationPlugin_autogen/moc_predefs.h
-o
U:/DEV/qtbase-everywhere-src-6.2.4/build/src/plugins/platforms/os2/QOS2IntegrationPlugin_autogen/include/main.moc
U:/DEV/qtbase-everywhere-src-6.2.4/src/plugins/platforms/os2/main.cpp

Output
--
U:/DEV/qtbase-everywhere-src-6.2.4/src/plugins/platforms/os2/main.cpp:49:1:
error: Parse error at "IID"

Line 49 of main.cpp contains:
Q_PLUGIN_METADATA(IID QPlatformIntegrationFactoryInterface_iid FILE
"os2.json")

Any clues on how to resolve the parse error?

Cheers,

Paul

___
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] How qAsConst and qExchange lead to qNN

2022-11-15 Thread Marc Mutz via Development 
Hi Thiago,

On 15.11.22 17:25, Thiago Macieira wrote:
> On Tuesday, 15 November 2022 00:52:24 PST Marc Mutz via Development wrote:
>> That remains to be proven. A rule of thumb for atomics is that they're
>> two orders of magnitude slower than a normal int. They also still act as
>> optimizer firewalls. With that rule of thumb, copying 50 char16_t's is
>> faster than one ref-count update. What really is the deciding point is
>> whether or not there's a memory allocation involved. I mentioned that
>> for many use-cases, therefore, a non-CoW SBO container is preferable over a
>> CoW non-SBO one.
> 
> That's irrelevant so long as we don't have SBO containers.

We have not-quite-SBO-but-close QVLA for arbitrary types, and we have 
std::string as a stand-in for QByteArray and u16string for QString. 
There are also tons of such container classes in 3rd-party libraries, 
which suddenly become viable because we've decoupled the API from the 
implementation.

> So what we need to really compare are memory allocations versus the atomics. A
> locked operation on a cacheline on x86 will take in the order of 20 cycles of
> latency on top of any memory delays[1], but do note the CPU keeps running
> meanwhile (read: an atomic inc has a much smaller impact than an atomic dec
> that uses the result). A memory allocation for a single byte will have an
> impact bigger than this, hundreds of cycles.
> 
> Therefore, in the case of CoW versus deep copy, CoW always wins.
> 
> [1] https://uops.info/html-instr/INC_LOCK_M32.html says 23 cycles on an 11-
> year-old Sandy Bridge, 19 on Haswell, 18 on everything since Skylake.

In the problematic case where a temporary container is created at the 
call site for the sole purpose of providing function arguments, it's 
specifically the dec, though, which is problematic (deref-to-zero has an 
acquire fence). The compiler cannot prove that the atomic hasn't been 
manipulated, so it can't optimize the deref out and go directly to 
deallocation. This includes the case of a defaulted extra argument 
(https://bugreports.qt.io/browse/QTBUG-98117), maybe not with QString, 
anymore, but, most recently, with QKeySequence (which prompted the 
addActions() revamp).

Seeing as destruction of temps is sequenced before the end of the 
full-expression and seeing as atomics are synchronization points, the 
C++ memory model says that these atomic decs _will_ hold up execution of 
the next statements.

Thanks,
Marc

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B

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

[Development] Meeting minutes from Qt Release Team meeting 15.11.2022

2022-11-15 Thread Jani Heikkinen via Development 
Qt 6.4 status:
- Qt 6.4.1 released
- Plan is to release Qt 6.4.2 at the beginning of next year

Qt 6.5 status:
- Dependency update rounds passed quite well recently in 'dev'
- Platform and module freeze will be in effect Fri 25th November
- Qt 6.5 feature freeze will be in effect Fri 9th December 
   * It is time to start updating new features to the  what's new in Qt 6.5' 
page: 
https://codereview.qt-project.org/gitweb?p=qt/qtdoc.git;a=blob;f=doc/src/whatsnew/whatsnew65.qdoc;h=82ec5a2e5fa1662ab79c871c4a0c0f0c31d2e427;hb=HEAD

Next meeting Tue 29th November 2022 16:00 CET

br,
Jani Heikkinen
Release Manager

irc log below:
[17:00:05]  akseli: alblasch: carewolf: mapaaso:The-Compiler: 
thiago: ping
[17:00:26]  jaheikki3_: pong
[17:01:12]  Time to start qt release team meeting
[17:01:50]  jaheikki3_: pong
[17:01:53]  In the agenda today:
[17:02:00]  Qt 6.4 status
[17:02:05]  Qt 6.5 status:
[17:02:13]  Any additional item to the agenda?
[17:03:37]  Let's start from Qt 6.4 status:
[17:03:45]  Qt 6.4.1 released today
[17:04:01]  See https://www.qt.io/blog/qt-6.4.1-released
[17:04:28]  Plan is to release Qt 6.4.2 january 2023
[17:04:52]  That's pretty much all about 6.4 status at this time. 
Any comments or questions?
[17:05:08]  congrats to the release :)
[17:06:10]  Ok, then quick Qt 6.5 status
[17:06:53]  Dependency updates as well as submodule updates succeed 
pretty well in 'dev' recently
[17:07:15]  And so on snapshot updated reqularly as well
[17:07:42]  Let's hope this same continues now when FF is getting 
closer
[17:08:14]  Platform and Module freeze will be in effect next 
Friday (25th November)
[17:08:30]  and Qt 6.5 feature freeze Fri 9th December
[17:08:48]  So there isn't that much time to finalize new things 
for Qt 6.5
[17:09:35]  But that's pretty much all what I have at this time. 
Any comments or questions?
[17:10:18]  the whatsnew page for 6.5 is already available in the qtdoc 
repo, perhaps a good time to remind people to add things to it?
[17:10:55]  That's true, I'll add a reminder to meeting minutes
[17:11:29]  will we get the header review process going soon after 
feature freeze?
[17:12:10]  Yes, target is to start the review process immediately 
after we have branched '6.5' from the 'dev'
[17:13:26]  ok, great. hopefully some activity on that before January!
[17:14:12]  ok, it was all at this time. Let's end this meeting now 
& have new meeting tue 29th November at this same time; I can't join tue 22nd 
[17:14:31]  Thanks for your participation, bye!
[17:15:10]  bye, thanks!
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-15 Thread Thiago Macieira 
On Tuesday, 15 November 2022 01:42:55 PST Marc Mutz via Development wrote:
> > Returning as an iteratable interface requires that we return a proxy
> > object, like QRegularExpressionMatch, so that the solution is
> > thread-safe. This is neither simple to understand, to code, or to port
> > existing code over to. It also requires copying the data over (hopefully,
> > implicitly) to the proxy object, so it doesn't solve anything.
> 
> I disagree on all points. QREM is complicated because we need to
> shoehorn a coroutine into an iterator concept. Same with
> QStringTokenizer. Coroutines with lazy sequences (generator<>) are very easy
> to implement and use.
>
> If we're to discuss further, please watch my Meeting C++ presentation,
> which lays out all the pros and cons I'm aware of. No need to re-iterate
> them in text here. https://youtu.be/tvdwYwTyrig

It will take some time to watch it.

In the meantime, I'd appreciate a short answer on how you return the keys from 
a stored associative map, in a thread-safe manner (such that if something in 
the same thread or another thread-safely modifies that map, the original user 
isn't affected). Because you pointed to QStringTokenizer and that implicitly-
copies a QString.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-15 Thread Thiago Macieira 
On Tuesday, 15 November 2022 00:52:24 PST Marc Mutz via Development wrote:
> That remains to be proven. A rule of thumb for atomics is that they're
> two orders of magnitude slower than a normal int. They also still act as
> optimizer firewalls. With that rule of thumb, copying 50 char16_t's is
> faster than one ref-count update. What really is the deciding point is
> whether or not there's a memory allocation involved. I mentioned that
> for many use-cases, therefore, a non-CoW SBO container is preferable over a
> CoW non-SBO one.

That's irrelevant so long as we don't have SBO containers.

So what we need to really compare are memory allocations versus the atomics. A 
locked operation on a cacheline on x86 will take in the order of 20 cycles of 
latency on top of any memory delays[1], but do note the CPU keeps running 
meanwhile (read: an atomic inc has a much smaller impact than an atomic dec 
that uses the result). A memory allocation for a single byte will have an 
impact bigger than this, hundreds of cycles.

Therefore, in the case of CoW versus deep copy, CoW always wins.

[1] https://uops.info/html-instr/INC_LOCK_M32.html says 23 cycles on an 11-
year-old Sandy Bridge, 19 on Haswell, 18 on everything since Skylake.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-15 Thread Thiago Macieira 
On Monday, 14 November 2022 23:52:23 PST Marc Mutz via Development wrote:
> Unless and until we replace all QString/QStringView overload sets with a
> single QAnyStringView function (possibly accompanied by a QString
> Q_WEAK_OVERLOAD), we can't make QString implicitly convertible from
> char16_t literals. While we can QT_REMOVED_SINCE our own API, we can't
> do the same for user API that relies on the explicit guarantee of
> QString/QStringView overloadability.

And then there's user library code. Our changing this would affect them, unless 
they make the same type of change that we do.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



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

[Development] HEADS-UP: Qt 6.5 Platform and Module Freeze is almost there...

2022-11-15 Thread Jani Heikkinen via Development 
Hi all,

Kindly reminder:

- Qt 6.5 platform and module freeze will be in effect Fri 25th November 2022. 
So only a bit more than a week left.
   * All new modules needs to be in CI and qt5.git (if needed) at that point. 
Otherwise those will be postponed to Qt 6.6 (or with granted exception those 
can be taken in later to Qt 6.5)
   * No provisioning changes between 'platform and module freeze' & beta1 
release. 

- Qt 6.5 Feature Freeze will be in effect Fri 9th December

br,
Jani 

> -Original Message-
> From: Jani Heikkinen
> Sent: maanantai 24. lokakuuta 2022 10.42
> To: development@qt-project.org
> Subject: HEADS-UP: Qt 6.5 Feature Freeze is getting closer
> 
> Hi all,
> 
> Just a kindly reminder: Qt 6.5 Feature freeze will be in effect 9.12.2022 and
> Qt 6.5 platform and module freeze 25th November 2022, see
> https://wiki.qt.io/Qt_6.5_Release
> 
> Please inform me about all new modules planned to be released in Qt 6.5;
> we should start adding those in CI & packages asap.
> 
> br,
> Jani
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-15 Thread Philippe 
On Tue, 15 Nov 2022 08:52:24 +
Marc Mutz via Development  wrote:

> There's nothing inherently Qt-ish about owning containers.

Yes and no, because owning containers are part of the very "Qt-ish"
Implicit Sharing idiom, which one is _great_ for the ease of use, safety
and optimization it provides.

~115 Qt classes: https://doc.qt.io/qt-6/implicit-sharing.html

>QAnyStringView, QUtf8StringView and, later, QAnyString, QUtf8String,
> can be used to to make UTF-8 a first-class citizen in Qt.

Maybe, but I see a deviation from simplicity (not "Qt-ish")

>But UTF-16 is sacrosanct in Qt. It's a cult. Irregardless of how many 
>deep copies it takes to convert to and from UTF-16 from native 
>encodings, people still worship it as god-given. It's not.

If this is "sacrosanct", this is simply because many people appreciate
QString for its rich API and ease of use. This has to be respected.

Philippe

> On 15.11.22 08:14, Ulf Hermann via Development wrote:
> >>> So, if the method immediately converts whatever it gets to QList or
> >>> QString, then there is no point in passing it a span or view.
> >>
> >> My point is that there _is_. Citing my blog post:
> >>
> >>     callConsumeQStringHelloWorld():
> >  > [...]
> > 
> > That's the worst case scenario of passing an 8bit string literal to a 
> > function that takes a QString. We have QStringLiteral to avoid the 8bit 
> > to 16bit conversion, but I know there are more problems with that.
> > 
> > Now lets look at the case of passing a pre-existing QString (i.e. one we 
> > don't have to create in place) to a function taking QAnyStringView and 
> > storing the result as QString.
> > 
> >      // somewhere:
> >      QString a;
> >      void setter(QAnyStringView view) { a = view.toString(); }
> > 
> >      // elsewhere:
> >      QString foo;
> >      [ ... modify foo ... ]
> >      setter(QAnyStringView(foo));
> > 
> > That's a deep copy. A deep copy of a string is obviously more expensive 
> > than the overhead of calling the QString ctor and dtor.
> 
> That remains to be proven. A rule of thumb for atomics is that they're 
> two orders of magnitude slower than a normal int. They also still act as 
> optimizer firewalls. With that rule of thumb, copying 50 char16_t's is 
> faster than one ref-count update. What really is the deciding point is 
> whether or not there's a memory allocation involved. I mentioned that 
> for many use-cases, therefore, a non-CoW SBO container is preferable over a 
> CoW 
> non-SBO one.
> 
> If QString and QByteArray had both efficient substringing and SBO, my 
> arguments would carry much less weight. But we have neither, and adding 
> it (esp. SBO) to QString for Qt 7 will break users, silently. Therefore 
> it's prudent _not_ to change QString, but to add QSmallString or 
> something instead. Until then, u16string and QVLA can be used, 
> by users and implementations.
> 
> Any way you turn it, non-owning containers in the API make for long-term 
> stable APIs even as we improve our container classes in incompatible ways.
> 
> > Which case is 
> > more common? And by what factor?
>  >
> > I can't say what case is more common. What I can say is that the risk of 
> > creating deep copies sounds worse to me than the risk of calling the 
> > QString ctor and dtor too often.
> >
> > This is what I mean with "fuzzy". We don't really have the data to 
> > support a move to QAnyStringView for all of our API.
> 
> I can say with firm belief that, _atm_, passing QString is more common. 
> But this is a self-fulfilling fact. The tst_qsettings experiment shows 
> what can happen if you port an API that doesn't naturally receive 
> pre-made QStrings.
> 
> If you want to take a peek at a world without owning containers, use the 
> Qt 6 QXmlStreamParser API or llvm.
> 
> With the caveat that the problem with QXmlStreamParser is that it needs 
> to convert to UTF-16. The vast majority of XML data is _not_ in UTF-16. 
> If QXmlStreamReader's API was formulated in QAnyStringView, it wouldn't 
> have to. We could just mmap() files and hand out QAnyStringViews to 
> tokens. Not going into whattaboutism here, but what about all those 
> unnecessary encoding conversions? Each one is a deep copy, too. UTF-16 
> is a total alien in the Unix world, and, connecting to your world, I 
> think it's safe to assume that very few QML files are encoded in UTF-16, 
> either. And PySide string are also not encoded in UTF-16, I think.
> 
> But UTF-16 is sacrosanct in Qt. It's a cult. Irregardless of how many 
> deep copies it takes to convert to and from UTF-16 from native 
> encodings, people still worship it as god-given. It's not.
> 
> No-one would use Clang if it internally converted everything to UTF-16 
> first. It would be too slow.
> 
> QAnyStringView, QUtf8StringView and, later, QAnyString, QUtf8String, can 
> be used to to make UTF-8 a first-class citizen in Qt.
> 
> Likewise, owning containers are also sacrosanct in Qt. They're a cult. 
> Irregardless of how

[Development] [Announce] Qt 6.4.1 Released

2022-11-15 Thread List for announcements regarding Qt releases and development via Announce via Development 
Hi all!

We have released Qt 6.4.1 today, see https://www.qt.io/blog/qt-6.4.1-released

Big thanks to everyone involved!

Br,
Jani Heikkinen 
Release Manager
___
Announce mailing list
annou...@qt-project.org
https://lists.qt-project.org/listinfo/announce
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-15 Thread Marc Mutz via Development 
On 14.11.22 22:17, Thiago Macieira wrote:
> On Monday, 14 November 2022 12:53:19 PST Marc Mutz via Development wrote:
>>> I don't think we will ever change return types.
>>
>> Your short interjections would be more valuable if you didn't just state
>> an opinion, but also give rationale ;-)
> 
> That's why I said "I think".
> 
> We can't return a non-owning view because that requires that we store
> internally *as* a contiguous area.

The "stored" here is much more of a constraint than the "contiguous". 
Even associative containers can be contiguous (QFlatMap, or a sorted 
vector or struct { key, value }). But I wrote that for non-stored or 
non-contiguous coroutines returning generators can be used. No-one 
suggests to use spans for non-stored or non-contiguous data, so this a 
straw man.

> If we are already doing that, we can store
> as QList and return *as* QList with implicit sharing.

In comparison, returning a QList requires us to store a QList. This is 
objectively a stronger constraint than merely string contiguous data. 
It's also a substantial constraint, as it excludes SBO, like in the 
QRegion case.

> Returning as an iteratable interface requires that we return a proxy object,
> like QRegularExpressionMatch, so that the solution is thread-safe. This is
> neither simple to understand, to code, or to port existing code over to. It
> also requires copying the data over (hopefully, implicitly) to the proxy
> object, so it doesn't solve anything.

I disagree on all points. QREM is complicated because we need to 
shoehorn a coroutine into an iterator concept. Same with 
QStringTokenizer. Coroutines with lazy sequences (generator<>) are very easy to 
implement and use.

If we're to discuss further, please watch my Meeting C++ presentation, 
which lays out all the pros and cons I'm aware of. No need to re-iterate 
them in text here. https://youtu.be/tvdwYwTyrig

See esp. https://youtu.be/tvdwYwTyrig?t=1219 for how trivial a QREMatch 
becomes when coroutines are available.

Thanks,
Marc

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B

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

Re: [Development] Problems porting Qt5.15 to Qt 6.2 for OS/2

2022-11-15 Thread Fabian Kosmale via Development 

Hi,

to expand on what Alexey said: Without linking against Qt::Gui, you will 
not have qpa in your include paths, which in turn means that 
QPlatformIntegrationFactoryInterface_iid  won't be macro-expanded to the 
string literals that is defined in qplatformintegrationplugin.h. In 
turn, moc will complain because it is expecting a string literal after IID.


Regards,
Fabian

On 15.11.22 10:28, Alexey Edelev via Development wrote:

Hi,

Please try to add
LIBRARIES
Qt::Gui

to the qt_internal_add_plugin call in 
https://github.com/psmedley/qt6-os2/blob/main/src/plugins/platforms/os2/CMakeLists.txt 


Regards,
Alexey.


*From:* Development  on behalf of 
Paul Smedley 

*Sent:* Tuesday, November 15, 2022 10:01 AM
*To:* development@qt-project.org 
*Subject:* [Development] Problems porting Qt5.15 to Qt 6.2 for OS/2
Hi All,

I'm attempting to update the OS/2 port of Qt 5.15
(https://github.com/bitwiseworks/qtbase-os2 
) to Qt 6.2.4

(https://github.com/psmedley/qt6-os2 )

Things are going pretty well and I have a number of DLLs built, howeever
I'm now stuck on building the OS/2 plugin.

I'm getting the following:

AutoMoc subprocess error

The moc process failed to compile
    "SRC:/src/plugins/platforms/os2/main.cpp"
into

"SRC:/build/src/plugins/platforms/os2/QOS2IntegrationPlugin_autogen/include/main.moc"
included by
    "SRC:/src/plugins/platforms/os2/main.cpp"

Command
---
U:/DEV/qtbase-everywhere-src-6.2.4/build/bin/moc.exe
-DQOS2IntegrationPlugin_EXPORTS -DQT_DEPRECATED_WARNINGS
-DQT_DEPRECATED_WARNINGS_SINCE=0x06
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_DEBUG -DQT_NO_EXCEPTIONS
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT
-DQT_PLUGIN
-IU:/DEV/qtbase-everywhere-src-6.2.4/src/plugins/platforms/os2
-IU:/DEV/qtbase-everywhere-src-6.2.4/build/src/plugins/platforms/os2
-IU:/DEV/qtbase-everywhere-src-6.2.4/build/include
-IU:/DEV/qtbase-everywhere-src-6.2.4/mkspecs/os2-g++ -Iu:/extras/include
-Iu:/openldap/include -Iu:/usr/include -IU:/OS2TK45/H
-IU:/usr/local1220/include/c++/12.2.0
-IU:/usr/local1220/include/c++/12.2.0/i686-pc-os2-emx
-IU:/usr/local1220/include/c++/12.2.0/backward
-IU:/usr/local1220/lib/gcc/i686-pc-os2-emx/12.2.0/include
-IU:/usr/local1220/lib/gcc/i686-pc-os2-emx/12.2.0/include-fixed
-I/usr/local/include -IU:/usr/local1220/include --include
U:/DEV/qtbase-everywhere-src-6.2.4/build/src/plugins/platforms/os2/QOS2IntegrationPlugin_autogen/moc_predefs.h
-o
U:/DEV/qtbase-everywhere-src-6.2.4/build/src/plugins/platforms/os2/QOS2IntegrationPlugin_autogen/include/main.moc
U:/DEV/qtbase-everywhere-src-6.2.4/src/plugins/platforms/os2/main.cpp

Output
--
U:/DEV/qtbase-everywhere-src-6.2.4/src/plugins/platforms/os2/main.cpp:49:1:
error: Parse error at "IID"

Line 49 of main.cpp contains:
Q_PLUGIN_METADATA(IID QPlatformIntegrationFactoryInterface_iid FILE
"os2.json")

Any clues on how to resolve the parse error?

Cheers,

Paul

___
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


--
Fabian Kosmale
Manager R

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosm...@qt.io
+49 1638686070
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Problems porting Qt5.15 to Qt 6.2 for OS/2

2022-11-15 Thread Alexey Edelev via Development 
Hi,

Please try to add
LIBRARIES
Qt::Gui

to the qt_internal_add_plugin call in 
https://github.com/psmedley/qt6-os2/blob/main/src/plugins/platforms/os2/CMakeLists.txt

Regards,
Alexey.


From: Development  on behalf of Paul 
Smedley 
Sent: Tuesday, November 15, 2022 10:01 AM
To: development@qt-project.org 
Subject: [Development] Problems porting Qt5.15 to Qt 6.2 for OS/2

Hi All,

I'm attempting to update the OS/2 port of Qt 5.15
(https://github.com/bitwiseworks/qtbase-os2) to Qt 6.2.4
(https://github.com/psmedley/qt6-os2)

Things are going pretty well and I have a number of DLLs built, howeever
I'm now stuck on building the OS/2 plugin.

I'm getting the following:

AutoMoc subprocess error

The moc process failed to compile
   "SRC:/src/plugins/platforms/os2/main.cpp"
into

"SRC:/build/src/plugins/platforms/os2/QOS2IntegrationPlugin_autogen/include/main.moc"
included by
   "SRC:/src/plugins/platforms/os2/main.cpp"

Command
---
U:/DEV/qtbase-everywhere-src-6.2.4/build/bin/moc.exe
-DQOS2IntegrationPlugin_EXPORTS -DQT_DEPRECATED_WARNINGS
-DQT_DEPRECATED_WARNINGS_SINCE=0x06
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_DEBUG -DQT_NO_EXCEPTIONS
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT
-DQT_PLUGIN
-IU:/DEV/qtbase-everywhere-src-6.2.4/src/plugins/platforms/os2
-IU:/DEV/qtbase-everywhere-src-6.2.4/build/src/plugins/platforms/os2
-IU:/DEV/qtbase-everywhere-src-6.2.4/build/include
-IU:/DEV/qtbase-everywhere-src-6.2.4/mkspecs/os2-g++ -Iu:/extras/include
-Iu:/openldap/include -Iu:/usr/include -IU:/OS2TK45/H
-IU:/usr/local1220/include/c++/12.2.0
-IU:/usr/local1220/include/c++/12.2.0/i686-pc-os2-emx
-IU:/usr/local1220/include/c++/12.2.0/backward
-IU:/usr/local1220/lib/gcc/i686-pc-os2-emx/12.2.0/include
-IU:/usr/local1220/lib/gcc/i686-pc-os2-emx/12.2.0/include-fixed
-I/usr/local/include -IU:/usr/local1220/include --include
U:/DEV/qtbase-everywhere-src-6.2.4/build/src/plugins/platforms/os2/QOS2IntegrationPlugin_autogen/moc_predefs.h
-o
U:/DEV/qtbase-everywhere-src-6.2.4/build/src/plugins/platforms/os2/QOS2IntegrationPlugin_autogen/include/main.moc
U:/DEV/qtbase-everywhere-src-6.2.4/src/plugins/platforms/os2/main.cpp

Output
--
U:/DEV/qtbase-everywhere-src-6.2.4/src/plugins/platforms/os2/main.cpp:49:1:
error: Parse error at "IID"

Line 49 of main.cpp contains:
Q_PLUGIN_METADATA(IID QPlatformIntegrationFactoryInterface_iid FILE
"os2.json")

Any clues on how to resolve the parse error?

Cheers,

Paul

___
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] Problems porting Qt5.15 to Qt 6.2 for OS/2

2022-11-15 Thread Paul Smedley 

Hi All,

I'm attempting to update the OS/2 port of Qt 5.15 
(https://github.com/bitwiseworks/qtbase-os2) to Qt 6.2.4 
(https://github.com/psmedley/qt6-os2)


Things are going pretty well and I have a number of DLLs built, howeever 
I'm now stuck on building the OS/2 plugin.


I'm getting the following:

AutoMoc subprocess error

The moc process failed to compile
  "SRC:/src/plugins/platforms/os2/main.cpp"
into

"SRC:/build/src/plugins/platforms/os2/QOS2IntegrationPlugin_autogen/include/main.moc"
included by
  "SRC:/src/plugins/platforms/os2/main.cpp"

Command
---
U:/DEV/qtbase-everywhere-src-6.2.4/build/bin/moc.exe 
-DQOS2IntegrationPlugin_EXPORTS -DQT_DEPRECATED_WARNINGS 
-DQT_DEPRECATED_WARNINGS_SINCE=0x06 
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_DEBUG -DQT_NO_EXCEPTIONS 
-DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT 
-DQT_PLUGIN 
-IU:/DEV/qtbase-everywhere-src-6.2.4/src/plugins/platforms/os2 
-IU:/DEV/qtbase-everywhere-src-6.2.4/build/src/plugins/platforms/os2 
-IU:/DEV/qtbase-everywhere-src-6.2.4/build/include 
-IU:/DEV/qtbase-everywhere-src-6.2.4/mkspecs/os2-g++ -Iu:/extras/include 
-Iu:/openldap/include -Iu:/usr/include -IU:/OS2TK45/H 
-IU:/usr/local1220/include/c++/12.2.0 
-IU:/usr/local1220/include/c++/12.2.0/i686-pc-os2-emx 
-IU:/usr/local1220/include/c++/12.2.0/backward 
-IU:/usr/local1220/lib/gcc/i686-pc-os2-emx/12.2.0/include 
-IU:/usr/local1220/lib/gcc/i686-pc-os2-emx/12.2.0/include-fixed 
-I/usr/local/include -IU:/usr/local1220/include --include 
U:/DEV/qtbase-everywhere-src-6.2.4/build/src/plugins/platforms/os2/QOS2IntegrationPlugin_autogen/moc_predefs.h 
-o 
U:/DEV/qtbase-everywhere-src-6.2.4/build/src/plugins/platforms/os2/QOS2IntegrationPlugin_autogen/include/main.moc 
U:/DEV/qtbase-everywhere-src-6.2.4/src/plugins/platforms/os2/main.cpp


Output
--
U:/DEV/qtbase-everywhere-src-6.2.4/src/plugins/platforms/os2/main.cpp:49:1: 
error: Parse error at "IID"


Line 49 of main.cpp contains:
Q_PLUGIN_METADATA(IID QPlatformIntegrationFactoryInterface_iid FILE 
"os2.json")


Any clues on how to resolve the parse error?

Cheers,

Paul

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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-15 Thread Marc Mutz via Development 
On 15.11.22 08:14, Ulf Hermann via Development wrote:
>>> So, if the method immediately converts whatever it gets to QList or
>>> QString, then there is no point in passing it a span or view.
>>
>> My point is that there _is_. Citing my blog post:
>>
>>     callConsumeQStringHelloWorld():
>  > [...]
> 
> That's the worst case scenario of passing an 8bit string literal to a 
> function that takes a QString. We have QStringLiteral to avoid the 8bit 
> to 16bit conversion, but I know there are more problems with that.
> 
> Now lets look at the case of passing a pre-existing QString (i.e. one we 
> don't have to create in place) to a function taking QAnyStringView and 
> storing the result as QString.
> 
>      // somewhere:
>      QString a;
>      void setter(QAnyStringView view) { a = view.toString(); }
> 
>      // elsewhere:
>      QString foo;
>      [ ... modify foo ... ]
>      setter(QAnyStringView(foo));
> 
> That's a deep copy. A deep copy of a string is obviously more expensive 
> than the overhead of calling the QString ctor and dtor.

That remains to be proven. A rule of thumb for atomics is that they're 
two orders of magnitude slower than a normal int. They also still act as 
optimizer firewalls. With that rule of thumb, copying 50 char16_t's is 
faster than one ref-count update. What really is the deciding point is 
whether or not there's a memory allocation involved. I mentioned that 
for many use-cases, therefore, a non-CoW SBO container is preferable over a CoW 
non-SBO one.

If QString and QByteArray had both efficient substringing and SBO, my 
arguments would carry much less weight. But we have neither, and adding 
it (esp. SBO) to QString for Qt 7 will break users, silently. Therefore 
it's prudent _not_ to change QString, but to add QSmallString or 
something instead. Until then, u16string and QVLA can be used, 
by users and implementations.

Any way you turn it, non-owning containers in the API make for long-term 
stable APIs even as we improve our container classes in incompatible ways.

> Which case is 
> more common? And by what factor?
 >
> I can't say what case is more common. What I can say is that the risk of 
> creating deep copies sounds worse to me than the risk of calling the 
> QString ctor and dtor too often.
>
> This is what I mean with "fuzzy". We don't really have the data to 
> support a move to QAnyStringView for all of our API.

I can say with firm belief that, _atm_, passing QString is more common. 
But this is a self-fulfilling fact. The tst_qsettings experiment shows 
what can happen if you port an API that doesn't naturally receive 
pre-made QStrings.

If you want to take a peek at a world without owning containers, use the 
Qt 6 QXmlStreamParser API or llvm.

With the caveat that the problem with QXmlStreamParser is that it needs 
to convert to UTF-16. The vast majority of XML data is _not_ in UTF-16. 
If QXmlStreamReader's API was formulated in QAnyStringView, it wouldn't 
have to. We could just mmap() files and hand out QAnyStringViews to 
tokens. Not going into whattaboutism here, but what about all those 
unnecessary encoding conversions? Each one is a deep copy, too. UTF-16 
is a total alien in the Unix world, and, connecting to your world, I 
think it's safe to assume that very few QML files are encoded in UTF-16, 
either. And PySide string are also not encoded in UTF-16, I think.

But UTF-16 is sacrosanct in Qt. It's a cult. Irregardless of how many 
deep copies it takes to convert to and from UTF-16 from native 
encodings, people still worship it as god-given. It's not.

No-one would use Clang if it internally converted everything to UTF-16 
first. It would be too slow.

QAnyStringView, QUtf8StringView and, later, QAnyString, QUtf8String, can 
be used to to make UTF-8 a first-class citizen in Qt.

Likewise, owning containers are also sacrosanct in Qt. They're a cult. 
Irregardless of how many deep copies it takes just to call a Qt function 
from Python, Java/Script or QML, people still 
worship them as god-given. They're not.

There's nothing inherently Qt-ish about owning containers. Qt is all 
about allowing developers to write great applications across platforms. 
Ideally, we'd focus on picking up developers where they come from. That 
means instead of inflicting a Java-ish C++ API on Python programmers, we 
make PySide rock by minimizing copies between Python and Qt/C++ data 
structures. iow: NOI.

Guys, take the blinkers off :)

Thanks,
Marc

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B

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

Re: [Development] How qAsConst and qExchange lead to qNN

2022-11-15 Thread Marc Mutz via Development 
On 14.11.22 23:04, A. Pönitz wrote:
>> Marc’s proposal of a Non-Owning Interface is already
>> become manifest in QRegion::begin/end
>>
>> https://doc.qt.io/qt-6/qregion.html#begin
>>
>> allowing us to write
>>
>>
>> for (auto rect : region) doSomethingWith(rect);
> Yes, and that's fine [but not quite matching the rest of the discussion
> of using spans?]
> 
>> (while QRegion::rects will have to create a QList even if there is
>> only a single rect in the inline storage, which is then not a QList).
>>
>> This is a*good*  addition to Qt. I think we can make more such
>> additions to Qt, in places where it makes a real difference for
>> today’s client code using owning containers, and without changing the
>> world.
> Fine with me.
> 
> With emphasis on "addition" and "real", and notable absense of "change"
> and "removal"...

QVector QRegion::rects() const _was_ removed for Qt 6.0.

The trick to treat QRegion as a container of QRect, simplifying both 
users and implementation of QRegion (no more vectorize()), only worked 
because QRegion is home to only one collection. It's also a trick you 
need to see to be able to use it, so discoverability is poor. In the 
general case, a given class may have more than one collection of items. 
E.g. if circular windows became the new rage, QRegion could be a 
collection not just of rects, but also of ellipses. Then what?

Enter span-retuning getters:

for (QRect rect : region.rects())
  ~~~
for (QEllipse ell : recion.ellipses())
  ~~~

Even while we wait for the circles-based GUIs to become en vogue, the 
.rects() is already more discoverable than pure QRegion-as-container.

There's a logical incompatibility between "QRegion as a QRect container 
= good" and "QRection::rects() returning a span of QRect = bad".

Either both are good ideas or neither are. They both grant the same 
freedoms and put the same constraints on the implementation of QRegion, 
but one is more flexible than the other.

Thanks,
Marc

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B

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