Re: [Development] Qt 5.13 feature freeze is getting closer
On Monday, 14 January 2019 09:50:23 PST Aleksey Kontsevich wrote: > Whether Qt Telemetry module will be included: > https://codereview.qt-project.org/gitweb?p=playground%2Ftelemetry.git;a=summ > ary ? When did this become a Qt module? The only email with "telemetry" in the past 10 months was a request for a Qt Creator plugin. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.13 feature freeze is getting closer
On Wednesday, 16 January 2019 09:44:40 PST Aleksey Kontsevich wrote: > In Nov, there was long discussion in review: > https://codereview.qt-project.org/#/c/240347/ Request was initially for > both: plugin and library - latter was transformed to Qt module. Given that this is a complete surprise, I don't think we can find enough time to do a review of it as a module in time for 5.13. In particular, I want to take a look to see how it can integrate with a project my team is working on: https://clearlinux.org/documentation/clear-linux/concepts/telemetry-about So I think that for 5.13, the module can be at no higher state than experimental. That will allow getting API reviews and testing by others. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Wednesday, 16 January 2019 10:44:27 PST Konstantin Tokarev wrote: > From QtWebKit perpective it would be great if Qt APIs which require QString > now would also accept QLatin1String at least for ASCII-only data Which ones? Currently, the only thing that takes QLatin1String in the API is QString itself. Where would you like to see more QLatin1String API? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Wednesday, 16 January 2019 13:16:39 PST Konstantin Tokarev wrote: > 1. Code points may be encoded as surrogate pairs in UTF-16, e.g. this is the > case for Emoji characters. QString ignores this fact, indexing 16-bit > QChars. To make things worse, several QString methods like left(), right(), > and mid() will happily cut surrogate pair in a half. So does QByteArray or so would an UTF-8 based QString, except it would happen for a lot more characters. What you want is QTextBoundaryFinder and possible QFontMetrics. > 2. When people are talking about character indexing they often imply > indexing of grapheme clusters. In Unicode world grapheme cluster may be > represented as a several code points depending on normalization form of the > source. To make things worse, even in NFC form not every grapheme cluster > that is possible in Unicode is representable as a single code point. Indeed, and SG16 in the C++ Standard is looking into grapheme clusters as the basis unit. Unfortunately, their work does not coincide with our Qt 6 timelines, nor would we be able to adapt that quickly based on how much code there is using QString. We should pay attention to the SG16 work and make sure it works with Qt 6, with eyes towards a better API in Qt 7. Nowhere did I say that we should use UTF-8. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.13 feature freeze is getting closer
On Wednesday, 16 January 2019 11:56:20 PST Lars Knoll wrote: > In particular, I want to > take a look to see how it can integrate with a project my team is working > on: > https://clearlinux.org/documentation/clear-linux/concepts/telemetry-about > > Why should that project influence a telemetry module for Qt? Because both have "telemetry" in the name. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.13 feature freeze is getting closer
On Thursday, 17 January 2019 00:23:56 PST Volker Hilsheimer wrote: > The proposed Qt Telemetry module focues on measuring usage of Qt > applications. How long do end users run an app, what functionality do they > use, etc. It’s not trying to address host or system observability, which is > anyway a fairly crowded space already. Understood. Well, *now* I understand it, because I had no idea until your email waht the module was about. In any case, from your description, it seems like the qttelemetry module could use telemd as a backend to send the telemetry back to a central server. > From a cursory look at your project, I’m curious what it does that > configuration management systems like cfengine/puppet/chef, or dedicated > time-series and monitoring systems like Prometheus don't do, or in what way > you found e.g Prometheus lacking. I have no idea what Prometheus is. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.13 feature freeze is getting closer
On Thursday, 17 January 2019 06:11:13 PST Edward Welbourne wrote: > As I suspect you're thinking of the API reviews I create in the run-up > to a release, I feel obliged to point out these are really API *change* > reviews. Without a prior release to compare against, the tool for that > doesn't know how to report anything. You need an actual review of the > whole API, not just some recent changes to it. Hi Eddy You're confusing the ABI binary compatibility check with the API review. API reviews do indeed review whole new APIs. Just look at the Calendar System API. But for full new APIs, the BC check tool does not make sense. Especially for new modules, this is a much larger discussion than a diff review. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.13 feature freeze is getting closer
On Thursday, 17 January 2019 08:33:23 PST Shawn Rutledge wrote: > > On 17 Jan 2019, at 17:23, Thiago Macieira > > wrote: > > > > I have no idea what Prometheus is. > > Another time-series database in the same category as InfluxDB. This sounds like a server-side tool. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.13 feature freeze is getting closer
On Thursday, 17 January 2019 10:43:19 PST Volker Hilsheimer wrote: > Well it’s a pretty comprehensive solution including client components, > agents and probes etc > > https://prometheus.io > > Database and query language etc are a significant part of it, and from my > experience one of the more operable systems in that space. Which matters a > lot. Nice, a CNCF project. > But system monitoring, probing and reporting/responding is a part of every > config management tool out there. I wonder what was missing in that space > to kick off a new thing. I don't know for sure. The team was already working on the tool when I joined it last year. I've never needed to look into their reasons or their competitors. I think it shows I wasn't prepared for a discussion on telemetry. This module's existence came as a complete surprise. So no, it's nowhere near ready even for experimental release in 5.13. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Thursday, 17 January 2019 13:27:40 PST Martin Koller wrote: > On Mittwoch, 16. Jänner 2019 19:44:27 CET Konstantin Tokarev wrote: > > From QtWebKit perpective it would be great if Qt APIs which require > > QString now would also accept QLatin1String at least for ASCII-only data > is QtWebKit still alive ? > Seems there is nobody working on it since more than a year... Konstantin is the maintainer, but I haven't seen releases recently, so it's not something I could recommend depending on. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.13 feature freeze is getting closer
On Thursday, 17 January 2019 18:23:53 PST Kevin Kofler wrote: > One discussion point that I miss here is whether spyware tooling should ever > become a Qt component in the first place, independently of the outcome of > the code and API reviews. The difference between spyware and legitimate telemetry is the use it's put on and that can be said of almost all technology too. An opt-in solution, with a link to a good privacy policy probably doesn't count as spyware. The Clear Linux installer, for example, asks you if you want to turn telemetry on, but the checkbox is unchecked by default.[1] And if Qt Creator as built by The Qt Company ever builds in telemetry support, remember the The Qt Company is subject to the GPDR. [1] if you turn telemetry on, the system will send our team anonymised crash backtraces, for example. Weekly, we review the crashes reported and see if we can fix it. I'm already fed up with seeing g_variant_* stuff crashing... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Friday, 18 January 2019 07:26:51 PST Tor Arne Vestbø wrote:
> If we plan to standardise on our Qt source code being UTF8, can we please
> allow QString(“Tor Arne Vestbø") without going through
> QLatin1Literal/QStringLiteral/QLatin1String/etc etc?
I think we now can. The last problem we had was MSVC pre-2015 update 2, which
added the /utf-8 switch. Without that option, any non-ASCII character in the
source code, even in comments, could cause compilation errors by causing a
decoding error in whichever codepage the user used in his/her OS.
I think all our builds now use /utf-8, which means UTF-8 is permitted
everywhere now. You can use it in comments ("Copyright Klarälvdalens ...", for
example) and in strings. Please don't use it in identifiers.
As for strings, the QString constructor takes UTF-8 input, but however fast
the decoder is, it's still slightly slower than the Latin1 decoder. So if your
string is purely US-ASCII, using QLatin1String is recommended.
PS: we don't need SG16's char8_t, but we'll need to add support for it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Friday, 18 January 2019 08:13:40 PST Kai Koehne wrote: > 1. We generally compile Qt code with QT_NO_CAST_FROM_ASCII that disables the > QString(const char *) overload. And we do that so that you have to make it > explicit whether you really want to do the implicit conversion from UTF-8 > to UTF-16, use QStringLiteral() to encode it as UTF-16 at compile time, or > rather have it translated with a tr() call. > > I think for Qt code explicit is better than implicit, so I actually would > stay with QT_NO_CAST_FROM_ASCII. Actually, what we should do is allow everywhere functionTakingString(u"Tor Arne Vestbø") // (note the u) Which causes the compiler to encode the string in UTF-16, bypassing the need for runtime decoding, and enforcing sources as UTF-8, so we get consistent binaries. It's just one step short of QStringLiteral in that it will still allocate memory, but it only needs a memcpy. Such code also works with functions taking QStringView without memory allocation. We all know that QStringLiteral has drawbacks when it comes to unloading modules. For QtCore, obviously QStringLiteral is not a problem, but other modules may decide to avoid it. PS: I still want to improve QStringLiteral, but it will still be different from a pure char16_t literal. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Friday, 18 January 2019 08:57:19 PST Tor Arne Vestbø wrote:
> > On 18 Jan 2019, at 17:21, Thiago Macieira
> > Actually, what we should do is allow everywhere
> >
> > functionTakingString(u"Tor Arne Vestbø")
> > // (note the u)
>
> Yes, this would be awesome! Please let’s do this 😊
>
> And I guess without QT_NO_CAST_FROM_ASCII you’d still be able to do:
>
> functionTakingString("Tor Arne Vestbø”) // without the ‘u’, runtime cost
Right, but given the benefit of char16_t literals, we should encourage the
QT_NO_CAST_FROM_ASCII even more! It's a single extra letter in your source and
even if the compiler is misconfigured and is producing mojibake for your
surname, my middle name or Jędrzej's first name, it will still work for US-
ASCII content ("a broken clock is right twice a day" type of "work").
In fact, we ought to look into replacing our QLatin1String content with
char16_t literals in our sources. Pros: avoid the Latin1 decoder, which is
slower[¹] than a pure memcpy. Cons: doubles the size of the string. So I'd use
QLatin1String only for uncommonly used strings, where saving a few bytes is
worth it.
[¹] see https://analysis.godbolt.org/z/OZ-5Gz, which contains the inner loop
of qt_from_latin1_internal (an AVX2 build[²]) and compare to an equivalent
memcpy in https://analysis.godbolt.org/z/7vR2jW. Note how the memcpy loop
according to llvm-mca has 3 cycles fewer of latency than the latin1 decoder.
And this is not an optimal memcpy loop.
[²] Our builds are not AVX2 by default. You're only going to get this
performance if you build with -march=native (Gentoo?) or you use Clear Linux.
The defaults are much worse.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Tuesday, 22 January 2019 06:49:51 PST Jason H wrote: > typedef QSymbolSequence QLatin1String; > typedef QSymbolSequence QByteArray; > typedef QSymbolSequence QByteArray; > typedef QSymbolSequence QString; > > So they can have the same API? It really seems to me that the issue is > storage, not that they need a different API to operate on the storage. That QSymbolSequence template class does not exist and is not easy to implement. Storage is not the problem, it's actually the algorithms that operate on and transform the contents. They'd have to be rewritten for each of the four. Go ahead and give it a try, though. This may also be what SG16 intends for C++23, so it may be an interesting trial run. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Tuesday, 22 January 2019 11:02:22 PST Matthew Woehlke wrote: > On 18/01/2019 11.09, Thiago Macieira wrote: > > As for strings, the QString constructor takes UTF-8 input, but however > > fast > > the decoder is, it's still slightly slower than the Latin1 decoder. So if > > your string is purely US-ASCII, using QLatin1String is recommended. > > ...but I assume QStringLiteral remains even faster? (I would think so; > not only is *no* decoding needed, which you could also get just by using > wide string literals, but also no *allocation*...) Yes. In terms of CPU cycles, for a given string length of US-ASCII content: QUtf8::convertToUnicode > qt_from_latin1 > memcpy > ∅ (fromUtf8, fromLatin1, fromUtf16, QStringLiteral) The empty set symbol indicates that QStringLiteral is requires no operation on the content (O(1) on length). The others are O(n). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Tuesday, 22 January 2019 09:01:16 PST Arnaud Clère wrote: > QByteArray is the official way to deal with utf8 strings but: > 1. This discussion shows it is not as known as it should be and I argue the > name does not help > 2. Dealing with binary data and all kind of string > encodings in a single class is error-prone And yet that's what we used to have in Qt 3 (remember QCString?). We went away from it for a reason. And 3: some character-mutating operations in QByteArray (toUpper, etc.) are Latin1, not UTF-8. > Hence my suggestion of adding a QUtf8String deriving from QByteArray... Not likely to happen. If we add a QUtf8String, it will be like QLatin1String, which in turn was meant to be similar to QStringView, not like QString. That means no mutation and no owning memory. And I don't want to add QUtf8String until SG16's char8_t gets settled. It'll probably be settled by C++20, which means we can probably work on this during Qt 6 lifetime, possibly even 6.1 or 6.2. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Wednesday, 23 January 2019 05:53:00 PST Edward Welbourne wrote: > What are our chances of getting this right in Qt 6 ? Not bad. But what you described is what SG16 is working on for std::text. So let's not do something different from them. We can prototype it and be first, though. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Wednesday, 23 January 2019 07:25:44 PST Jason H wrote: > > From: "Arnaud Clère" > > > > > And I don't want to add QUtf8String until SG16's char8_t gets settled. > > > It'll probably be settled by C++20, which means we can probably work on > > > this during Qt 6 lifetime, possibly even 6.1 or 6.2.> > > It makes sense to avoid future incompatibilities with the standard but > > fortunately Qt sometimes chooses to solve real problems ahead in time > > ;-) > Well C++20 is really how many months away? Qt6 won't be released until when? Give me the exact answers and I'll tell you if we can have this in Qt 6.0. The fact you can't is the problem: they're too much in flux and too close to each other for us to be able to accept char8_t as an established functionality that won't change by a later paper and design a solution for Qt 6.0. If we're lucky, we can do it. More likely, we'll have to wait a bit, possibly even for a compiler to implement it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: New branch model
On Wednesday, 23 January 2019 08:37:57 PST Konstantin Tokarev wrote: > > Disadvantages: > > - git history would be a bit wilder, "git branch --contains" would not > > work > > - commit messages in some branches would have kind of ugly footer as an > > > > effect of "cherry-pick -x" > > Gerrit's Change-Id can be used to track presence of patch in branches of > interest Yes, but not as easily, since the git branch --contains and git tag --contains are pure DAG operations. The search you're talking about is a text search (usually implemented by a regexp search) on the commit message, with no DAG boundaries. You have to scan all valid branches for a given string. And then you still have to run git branch --contains on each entry you found to figure out which branches contain those commits. So this is scriptable. It's going to be something like 100x slower than today, but it should still finish within 10 seconds, even on slow machines. Test in qtbase (Linux): Run: git rev-list --grep=5d809703aa2d2a08ae7e9610fd42025b081d3d0c --all Output: bd38ff3c5456b1f2fc03e4899e73d650ad5f858a Runtime: 0,52s user 0,03s system 99% cpu 0,555 total Same test on Windows: real0m0.800s, user0m0.593s, sys 0m0.171s (Both machines are Intel Skylakes, and both have SSDs and 16 GB of RAM) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Wednesday, 23 January 2019 06:07:37 PST Marco Bubke wrote: > Would it be not better to use a simple container and then functions on top > which use a view, so we could use them with any container If only we had a class that found boundaries in text... http://doc.qt.io/qt-5/qtextboundaryfinder.html -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: New branch model
On Wednesday, 23 January 2019 11:01:53 PST Volker Hilsheimer wrote: > I think that’s fine. What’s much worse is having a fix in 5.12 and not > knowing how to deal with the merge conflicts into dev. That means dev might > regress, unless whoever authored the change is willing to spend time on > making it work. In the end, if contributors can’t own their changes for all > various branches of Qt, then I much prefer for them to own the changes at > least for dev. And with Qt 6, this will become a much bigger problem. The problem is I can turn this around and say that we introduce regressions into the older branches due to an improper cherry-pick that didn't conflict. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Wednesday, 23 January 2019 23:32:28 PST Olivier Goffart wrote: > - Introduce some iterator that iterates over unicode code points. I wrote that about a decade ago. It's called QStringIterator and it's inside our sources, but in a private header. But we may want to make it iterate over grapheme clusters instead of Unicode codepoints. That is, make it use QTextBoundaryFinder to iterate, instead of decode the storage to UTF-32. > - Deprecate utf16() and other API that assume that QString is UTF-16 > - Replace them by a toUtf16 which returns a QVector. I believe > that it is possible to make the cotent implicitly shared with the QString, > avoiding copies. (since it is just a QTypedArrayData internally) QVector. Sharing QVector and QString is possible, but we need to fix a few discrepancies, especially that of QVector not being allowed to be raw data, while QString can be (QVector::fromRawData was proposed for Qt 5.0 [Andreas Hartmetz, if I'm not mistaken] but we never added it). So this is fixable for Qt 6, but not before Qt 6. I think I tried even in my branch and ran into a lot of trouble. It was a non- obvious change. So I abandoned it. Still, we're not going to switch away from UTF-16 in Qt 6. The best we can do is pave the way for switching in Qt 7, if we add the methods you're talking about, change ALL the Windows, Cocoa and Android code that calls .data() and assumes it to be UTF-16 to toUtf16(). We may want to have some #defines like the QStringView stirng level or the ASCII-cast ones, so we catch those. But we WILL NOT change from UTF-16 in the next 2 years. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Thursday, 24 January 2019 05:06:58 PST Konstantin Tokarev wrote: > I will be officially pissed off if possibility to access raw data of QString > without extra copy is gone It would be better if there is a way to figure > out internal storage encoding (e.g. isUtf16()) and access raw data How often do you need that, oustide of QString itself? And maybe a few efficient QtCore classes? (QCborValue comes to mind) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation of QByteArray operator const char *()?
On Friday, 25 January 2019 12:11:33 PST Christian Ehrlicher wrote: > Hello, > > The two implicit conversions from QByteArray to const char*/void* > (QByteArray::operator const char *() and QByteArray::operator const > void*()) were marked as obsolete with Qt5.0 but never get decorated as > such. This means their usage even inside QtBase is huge (I would say at > least 70-80 locations). > Therefore my question before I'm pushing a patch to add QT_DEPRECATED_X > to them - is the deprecation still valid? I'd un-deprecate them. The use to casting to char* is way too useful. But I wasn't aware we event had a void* cast. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Friday, 25 January 2019 08:54:38 PST Konstantin Tokarev wrote: > > How often do you need that, oustide of QString itself? And maybe a few > > efficient QtCore classes? (QCborValue comes to mind) > > Each time I need to interact efficiently with extenal code which isn't > Qt-based, e.g. WebKit, ICU. In particular, this extra copy would certainly > degrade performance of QtWebKit. > > Oh and you've mentioned CBOR, this implies that it won't be possible for Qt > users to make efficient implementation of a different serialization format. I didn't say we shouldn't have it. I was just trying to gather information about the need. So it looks like we do need it, if we ever change the encoding. My worry is that people will fail to handle the combinations properly. Which is why I dislike different encodings even more than changing it wholesale with an API- breaking change. However, one of my pending Qt 6 changes is to store a flag in QString that says "this UTF-16 string is known to contain only US-ASCII characters". That way, toUtf8() can use the faster toLatin1() algorithm (the flag is set by toUtf8() and toLatin1() the first time they're called). The problem is that it needs to clear that flag in all detach() calls. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Friday, 25 January 2019 04:54:22 PST Edward Welbourne wrote: > we > fail to properly support cultures whose scripts are relegated to the > outer planes of Unicode - as, for example, the Chakma language's number > system All living languages are supposed to be stored in the BMP, which means no UTF-16 surrogate pairs to encode them. That doesn't mean a single code unit, mind you. Think of combining characters. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: New branch model
On Friday, 25 January 2019 01:10:35 PST Simon Hausmann wrote: > I do quite like what Allan suggested: We could try the cherry-pick the other > way around. Volker, Lars, Thiago etc. surely remember the p4i script we > used to have when we were using Perforce. Imagine that with more > automation. I vaguely remember it. But your bringing it up is *not* an argument in favour of cherry-picking. Doing backporting properly in the Perforce days was a nightmare. We did not consistently backport fixes to earlier releases, even when we had a somewhat long stable series (4.3 went through 4.3.5). Also, unlike Git, Perforce "merges" *were* a series of cherry-picks and it did know which commits had been cherry-picked and which ones hadn't. So if you told it to merge a range, it would tell you everything that was missing. More importantly, the range did not have to be contiguous, so you could cherry-pick only your own changes and let others deal with theirs. It also helped p4 had a pretty good automated conflict resolution in the command-line (today, I use kdiff3 for that, via git mergetool). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: New branch model
On Friday, 25 January 2019 04:30:52 PST Shawn Rutledge wrote: > Could we simplify testing for some types of patches? E.g. if the patch only > touches documentation, don’t run tests, except those that involve building > docs, if we have any of those. I think that's a good idea to investigate, but remember that you *can* break things with doc changes. Maybe a way for a "low-priority stage", which stages a change but doesn't trigger the integration unless a timeout comes around or a regular priority change is also staged. One time back in the TT/Nokia days Frans asked me for a quick review of a "### Qt5" change he wanted to add and I gave him my approval verbally (that was before code review systems). So he pushed it. 5 minutes later, Paul waked into our office saying we had broken the build: we forgot the // to *start* the comment. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation of QByteArray operator const char *()?
On Friday, 25 January 2019 13:36:04 PST Christian Ehrlicher wrote: > Here the commit which deprecated the functions: > https://codereview.qt-project.org/#/c/17343/ > I found one place inside QtBase which hit this problem: > https://codereview.qt-project.org/#/c/251028/ I'm not questioning the usefulness of the macro to disable the operator. I am questioning deprecating the operators. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6: Adding UTF-8 storage support to QString
On Friday, 25 January 2019 13:39:49 PST Konstantin Tokarev wrote: > > All living languages are supposed to be stored in the BMP, which means no > > UTF-16 surrogate pairs to encode them. > > AFAIK all emojis are encoded with surrogate pairs Emojis are not part of a living language. They're drawings. But yes, they're outside the BMP. In any case, they're often represented by more than one codepoint anyway, so whether we used N*2 UTF-16 code units to represent them or N UTF-32 code units, it makes no difference. Your code needs to know how to deal with them, where to properly break, how to combine them, how to calculate the width, etc. Also note how they'd be represented by N*4 bytes in UTF-8, which means all three representations take exactly the same amount of memory. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: New branch model
On Monday, 28 January 2019 04:54:58 PST Volker Hilsheimer wrote: > A change making it into dev where it can be noticed and scrutinized by a > bunch of people that didn’t participate in the merge request, where it can > pass additional build and configurations, and generally be exposed to > different cases that are not covered by CI - isn’t that valuable? Valuable, but how is that different from today? All it takes is that people run the stable branch, which they should, so as to give more eyes to the thing that needs stability the soonest. I've been doing that for 7 years. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Enum classes in signals?
On Tuesday, 5 February 2019 08:43:03 PST Jason H wrote: > While I prefer enum classes myself, I just had to connect to a signal with > one in it. This was unfortunate as I was attempting to use the old > connection syntax SIGNAL()/SLOT() macros. I was not aware that the old > syntax were being deprecated? What is the policy on this? They're not exactly deprecated, but they're older than the new syntax and they don't check at compile time that the connection can succeed. > Should signals not use enum classes? Unknown. I don't see why they shouldn't, but you haven't shared any error messages, so I can't tell. > Should Qt not use enum classes? Enum classes are fine in Qt. > Should Qt support old connection syntax? Where/when? Yes. It should be supported for the millions of lines of code that existed before the new syntax was introduced in 2012. > Should all new connections be in the modern syntax? Yes, if you can. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Enum classes in signals?
On Tuesday, 5 February 2019 10:46:45 PST Matthew Woehlke wrote: > On that note, will uic in Qt6 finally use the new PMF syntax? We can add this mode right now. It won't replace the connectSlotsByName() feature, of course, since that is entirely based on runtime (it depends on the object name). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Intention of dropping UWP 2015 x86 builds in favour of MinGW 32-bit packages
On Wednesday, 6 February 2019 04:40:24 PST Tuukka Turunen wrote: > I do agree that we should avoid dropping configurations in patch releases. > However, we should be pragmatic and provide the set that is most valuable > for the users and still feasible to maintain. So in my opinion adding > something and removing another is fine if that is what best serves our > users. That said, we should not do this very often as LTS is about > continuity. I'm going to say +1 on this exception to the rule. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] All deprecation warnings are P1 for 5.13.0
Commit 7847e6bc02552fa7fc7f518e5cb3336f667b5a6d in qtbase madee the QT_DEPRECATED and QT_DEPRECATED_X warnings on by default in Qt builds. That means we started seeing lots of warnings that weren't there in 5.12. ALL such warnings must be fixed by 5.13.0 release. Please treat them as P1 (or P½ because flooding my output while building makes finding legitimate warnings and errors more difficult). I've begun reporting in Gerrit on the commits that added the deprecation, if that commit was recent enough. But there's new code using years after those functions were deprecated... By beta, those that aren't fixed will get P1 bug reports in JIRA. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] All deprecation warnings are P1 for 5.13.0
On Saturday, 9 February 2019 07:30:36 PST Christian Ehrlicher wrote: > QT_DISABLE_DEPRECATED_BEFORE=0x051300: Uh, that's 0x050d00 :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] All deprecation warnings are P1 for 5.13.0
On Saturday, 9 February 2019 01:00:46 PST Allan Sandfeld Jensen wrote: > By fixed I guess you also mean suppressed were appropriate? some are from > tests testing deprecated functions, and other are deprecated functions > calling other deprecated functions because they belong together. Yes, disable where strictly necessary. But keep this as a last-resort scenario. If we deprecated an API our own code used, then we must have a suitable replacement. If we don't, there's a good indication the deprecation is either unwarranted or needs new API. This does not apply to tests. We should simply disable deprecation warnings from tests. All the warnings I have reported are from src/ and tools/ builds. I have not got to examples, but they should also be clean of warnings too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] All deprecation warnings are P1 for 5.13.0
On Friday, 8 February 2019 22:34:21 PST Giuseppe D'Angelo via Development wrote: > Agree with the rest of the email. From a purely technical point of > view, however, I'm wondering why we didn't see those warnings before? Qt > was already built with warnings enabled AFAICS? For instance: Warnings switches were enabled in the compiler command-line and even -Werror and headersclean. However, QT_DEPRECATED did not produce a warning and deprecation warnings are not fatal. Now they do produce a warning, since your commit. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake Workshop Summary
On Wednesday, 13 February 2019 02:06:13 PST Simon Hausmann wrote:
> (2) Have a super-project that allows building all of Qt with one call to
> "cmake", a call to "cmake --build" and finally "$maketool install".
>
> The latter has not been "developed" yet but I think it's necessary to allow
> for a convenient transition for the users of Qt.
#2 can be supported with a plain script, or even just a plain Makefile. All
you need is the dependency order.
Attached is the one I use. You can run
make -f Makefile.qthelpers T=target
and it'll run
make target
in each of the submodules.
You can even make it run shell commands:
make -f Makefile.qthelpers CMD='f() { cd $$1; git pull; } f'
The above I often run with -j so it launches all gits in parallel :-)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
all:
qtbase :
MODULES += qtbase
qtnetworkauth : qtbase
MODULES += qtnetworkauth
qtx11extras : qtbase
MODULES += qtx11extras
qtserialport : qtbase
MODULES += qtserialport
qtimageformats : qtbase
MODULES += qtimageformats
qtxmlpatterns : qtbase
MODULES += qtxmlpatterns
qtsvg : qtbase
MODULES += qtsvg
qtserialbus : qtserialport
MODULES += qtserialbus
qtdeclarative : qtbase qtsvg qtxmlpatterns
MODULES += qtdeclarative
qtremoteobjects : qtbase qtdeclarative
MODULES += qtremoteobjects
qtscxml : qtbase qtdeclarative
MODULES += qtscxml
qtcanvas3d : qtdeclarative
MODULES += qtcanvas3d
qtwebsockets : qtbase qtdeclarative
MODULES += qtwebsockets
qtgamepad : qtbase qtdeclarative
MODULES += qtgamepad
qtwayland : qtbase qtdeclarative
MODULES += qtwayland
qtconnectivity : qtbase qtdeclarative
MODULES += qtconnectivity
qtsensors : qtbase qtdeclarative
MODULES += qtsensors
qtgraphicaleffects : qtdeclarative
MODULES += qtgraphicaleffects
qtmultimedia : qtbase qtdeclarative
MODULES += qtmultimedia
qttools : qtbase qtdeclarative
MODULES += qttools
qtwebglplugin : qtbase qtwebsockets qtdeclarative
MODULES += qtwebglplugin
qtwebchannel : qtbase qtdeclarative qtwebsockets
MODULES += qtwebchannel
qt3d : qtbase qtdeclarative qtimageformats qtgamepad
MODULES += qt3d
qtquickcontrols2 : qtgraphicaleffects qtimageformats
MODULES += qtquickcontrols2
qtquickcontrols : qtdeclarative qtgraphicaleffects
MODULES += qtquickcontrols
qtvirtualkeyboard : qtbase qtdeclarative qtsvg qtmultimedia qtquickcontrols
MODULES += qtvirtualkeyboard
qtspeech : qtbase qtdeclarative qtmultimedia
MODULES += qtspeech
qtdatavis3d : qtbase qtdeclarative qtmultimedia
MODULES += qtdatavis3d
qtcharts : qtbase qtdeclarative qtmultimedia
MODULES += qtcharts
qtscript : qtbase qttools
MODULES += qtscript
qttranslations : qttools
MODULES += qttranslations
qtlocation : qtbase qtdeclarative qtquickcontrols qtquickcontrols2 qtserialport
MODULES += qtlocation
qtwebengine : qtquickcontrols qtwebchannel qtlocation qttools
MODULES += qtwebengine
qtwebview : qtdeclarative qtwebengine
MODULES += qtwebview
all: $(MODULES)
list:
@$(MAKE) -sf $(firstword $(MAKEFILE_LIST)) CMD=@echo T= | sed s/-echo//
$(MODULES):
$(CMD) $@ $(T)
CMD = +$(MAKE) -C
.PHONY: all list $(MODULES)
.SUFFIXES:
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] CMake Workshop Summary
On Wednesday, 13 February 2019 02:22:15 PST Vitaly Fanaskov wrote: > It's not clear why you included version to a package name (e.g. Qt5/Qt6). > With CMake you can pass a version as the second argument, e.g.: > find_package(Qt 5.12) Perhaps it would be better, what do you think? Because applications not yet ported that ask for 5.12 should not find 6.1. The Qt major version number is its source compatibility requirement. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake Workshop Summary
On Wednesday, 13 February 2019 05:58:18 PST Kevin Funk via Development wrote:
> The problem is, besides the reasons Simon mentioned, that just using "Qt" as
> the package prefix will make it more difficult for distros to co-install
> the CMake config files for different Qt versions.
>
> Still all up for discussions though. Happy to get more people involved.
Is it possible to use Qt6 and make the system export "Qt::" as an alias,
possibly behind an extra option passed in find_package()? If an alias is not
possible, is it possible to make find_package() set variables like ${QTCORE}
that will be either Qt5::Core or Qt6::Core, depending on the one found?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] CMake Workshop Summary
On Wednesday, 13 February 2019 09:08:58 PST Stephen Kelly via Development wrote: > Of course it is easy to create a `Qt5or6::Core` target for transitional use > and get all the benefits. > > target_link_libraries(mything PRIVATE Qt5or6::Core) That should plain be Qt::Core, which is the same as Qt 4. The number of packages still transitioning from Qt 4 is small and in any case would be what is expected anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Interest] Need help with deprecated QVariant functions
On Friday, 22 February 2019 12:38:55 PST Giuseppe D'Angelo via Development wrote: > IIRC, the reason for qVariantSetValue is to work around VS2005 not > supporting member function templates. Almost. That wasn't VS2005 (a.k.a VS 8.0) that had the problem. It was VS 6.0, which predated the C++98 template definition. You can still see a bunch of other relics of that in template functions that take an extra T* parameter that is defaulted to nullptr. They're usually #ifdef'ed out for QDoc. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake Workshop Summary
On Thursday, 21 February 2019 02:59:20 PST Kevin Funk wrote: > So, yep, add_subdirectory() sounds like the way to go; we'll need to check > how that performs with the amount of existing Qt submodules, though. We > might need to do a couple more optimizations of the CMake macros/functions > in qtbase.git for that. It also means making sure they don't step on each other's toes, but I think that a little discipline in writing our CMakeLists.txt should get us there. But do note that our parallelism isn't that bad right now. There's a long critical path before parallel things can currently be built, but once QtQml is built, the number of jobs that can be launched in parallel is very big. What doesn't need that build isn't very large. Currently, I can briefly saturate the 276-node Icecream farm at the office for a few minutes while QtQuick builds and just after it. Let's see if CMake can make it better. It certainly did for KDE back in 4.0, though the biggest gain was getting rid of libtool. PS: the build could be faster if Icecream maintainers reviewed pull requests. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake Workshop Summary
On Saturday, 23 February 2019 01:52:06 PST Richard Weickelt wrote: > > But do note that our parallelism isn't that bad right now. There's a long > > critical path before parallel things can currently be built, but once > > QtQml is built, the number of jobs that can be launched in parallel is > > very big. What doesn't need that build isn't very large. > > Could you elaborate a bit on that? Are you saying that the number of modules > depending on QtQml is "very big" and hence it is on a critical path or is > this module different from other critical modules like QtNetwork or QtCore? I am saying that there are enough libraries or plugins depending on QtQml or QtQuick, causing a lot of Git repositories to depend on qtdeclarative. That puts them in the critical path. On a switch to a different buildsystem, if it can determine that things like qttools/src/designer don't depend on QtQml, it can start building that earlier, which should increase parallelism. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake Workshop Summary
On Sunday, 24 February 2019 08:08:39 PST Lisandro Damián Nicanor Pérez Meyer wrote: > For 5.11 something along: > > <https://qt-kde-team.pages.debian.net/images/qt5_build_deps.png> > > Note that only critical path is followed, +/- docs. > > In other words: only 6 submodules can be built without qtdeclarative: > qtbase, qtgamepad, qtimageformats, qtxmlpatterns and qtscript. > qtstyleplugins is not part of the "official" submodules if I'm not > mistaken. You listed 5. I assume the 6th is qtsvg. But that doesn't work either, since there's qtserialport. Anyway, the parallelism would be welcome for developers like me, as our build farm hit 350 nodes on Friday. But it won't help package building, since they work at a tarball granularity. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Deprecating the static QProcess::startDetached() overloads
With a lot of thanks to Jörg's effort, since Qt 5.9 we have a non-static
startDetached() method, which do honour the environment set with
setProcessEnvironment, the current working dir with setWorkingDirectory, etc.
I think it's a far superior option. By far, it avoids the mistake that led to
QTBUG-74074, where someone wrote:
QProcess exeB;
QProcessEnvironment env = QProcessEnvironment::systemEnvironment();
env.insert("PYTHONHOME", "NewVariable");
exeB.setProcessEnvironment(env);
exeB.startDetached("AnotherProcess/AnotherProcess.exe");
Unfortunately, that startDetached is static, so the setting made in the object
are not relevant. The author needed to write:
exeB.setProgram("AnotherProcess/AnotherProcess.exe");
exeB.startDetached();
Ok to deprecate it?
We will not be able to recover those overloads in Qt 6, but we may be able to
bring them back in Qt 7.
Alternative: deprecate *ALL* startDetached() overloads and instead add a
setDetachedMode(bool enable), and allow start() to start detachedly.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecating the static QProcess::startDetached() overloads
On Tuesday, 26 February 2019 22:59:12 PST J-P Nurmi wrote: > Is it technically possible to start() and then detach()? No, because the way to start changes. The detached mode requires a double fork and the actual detaching from the TTYs. You can orphan / forget about the child, but it won't be detached. It may still get killed by SIGHUP when the parent process exits. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecating the static QProcess::startDetached() overloads
On Wednesday, 27 February 2019 11:35:21 PST Oswald Buddenhagen wrote:
> it's unreasonable to risk tearing down "detached" children on process
> exit; that would be a totally fake api. also, you can't just pretend
> that the children aren't yours, because you need to collect the zombies,
> so at best the QProcess frontend could detach from them.
Good point: so long as the parent process is still running, it MUST waitpid()
on the child processes. So even if we make QProcess front-end abandon the
child, the backend in forkfd must still know about it.
When the parent process exits, the children will be reparented to PID 1. But
their controlling TTYs, process groups and session IDs will not change. We can
assume you properly redirected std{in,out,err} away from the TTYs if you meant
to detach, but we need to know whether to detach the controlling TTY too (if
any), otherwise the process will get a SIGHUP when the TTY itself gets closed.
As for PGRP and SID, I don't remember those Unix arcana details to predict
what would happen.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecating the static QProcess::startDetached() overloads
On Wednesday, 27 February 2019 12:22:05 PST Thiago Macieira wrote:
> Good point: so long as the parent process is still running, it MUST
> waitpid() on the child processes. So even if we make QProcess front-end
> abandon the child, the backend in forkfd must still know about it.
>
> When the parent process exits, the children will be reparented to PID 1. But
> their controlling TTYs, process groups and session IDs will not change. We
> can assume you properly redirected std{in,out,err} away from the TTYs if
> you meant to detach, but we need to know whether to detach the controlling
> TTY too (if any), otherwise the process will get a SIGHUP when the TTY
> itself gets closed. As for PGRP and SID, I don't remember those Unix arcana
> details to predict what would happen.
I've just realised that my alternative implementation of forkfd that
implements the double-forking for all processes could be handy here. For every
child that you start, it starts an intermediary babysitter process whose only
job is to waitpid() on the child. I implemented this because this babysitter
process is not running alongside third party library code that could interfere
with the SIGCHLD signal handler.
However, it has serious drawbacks, so I don't think we should use it:
1) it creates one extra process per child, which lowers the number of
concurrent children you can have by half;
2) it's Linux-only, since I can't use fork() due to deadlocks. It uses
syscall(SYS_clone, ...) directly. And since it can't allocate memory due to
the same deadlocks, it needs to use syscall(SYS_getdents64) to list open files
in /proc/self/fd.
3) the babysitter process does not know when the parent exits, so it will keep
running and keep the entire set of libraries of the Qt parent application
loaded in memory for as long as the child process is running.
3.bis) as a result of (3), it will cause COW in any memory written to by the
parent process.
I implemented this because, unlike the current solution, if you pass the
forkfd pipe to another process and exit, the receiving process will still be
able to get the exit notification, as the kernel implementation intended to
do.
(3) can be mitigated polling on the outgoing pipe, which allows us to find out
if all the reading ends have closed, then exit the babysitter process. That
won't solve (3.bis) nor will it solve the case where the parent execve()s a
smaller executable. To do that, we'd need to go deeper into Linux-only and
unmap any other memory regions we didn't need, and switch to an alternate
stack.
To remove the Linux-only dependency, the only solution I can think of is to
use a libexec executable, but that has a startup cost of its own. And nothing
solves (1).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] On deprecating functions
On Monday, 4 March 2019 09:58:40 PST Edward Welbourne wrote: > Christian Ehrlicher (4 March 2019 17:51) wrote > > > So what's the correct way to deprecate a function and not forgetting > > about QT_DEPRECATED later on as it happened with a lot of functions > > during Qt4 times? > > Isn't that what > #if QT_DEPRECATED_SINCE(5, 13) > is for ? The point raised by hjk is that this causes warnings to anyone compiling code that needs to retain compatibility. There's no grace period. This is probably why we only documented the functions were deprecated with \obsolete, but never enabled warnings (except for Qt4-compat things). In that scheme, finding deprecated functions is done by raising QT_DEPRECATED_SINCE in your buildsystem and see what fails, instead of having warnings printed at you. Should we go back to this? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] On deprecating functions
On Monday, 4 March 2019 10:46:00 PST Christian Ehrlicher wrote: > You know what happens in this case - nothing since noone notices... see > all the usages of deprecated functions within QtBase which have been > unrecognized for ages. I do, but who's to say people will fix warnings? Will they do that only because it's now "in their face"? > Lars mentioned a new macro Q_WARN_DEPRECATED_SINCE(major, minor) here: > https://codereview.qt-project.org/#/c/254857/ - maybe this could help here? The grace period for warnings as I'd understood from hjk would not solve the problem. It would only cause the problem to be pushed further down the line, if we take your thesis into account that developers won't solve deprecations until there's a warning. That means they'll still complain, despite having had a grace period (which they didn't know about). Adding a controllable warning setting could help, especially if we default it to the current (or past) release. Codebases that wish to silence those warnings would explicitly push it forward. There'll be codebases that set the warning to 0x057f00... Anyway, how would that be different from our pre-5.12 model, where you'd explicitly enable warnings if you want them. That's why we use QT_DEPRECATED, not Q_DECL_DEPRECATED. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] On deprecating functions
On Monday, 4 March 2019 13:48:25 PST André Pönitz wrote: > The proposed model would effectively introduce another user-visible > level including associated period of time between "alternative > solution gets introducd" and "getting nagged about not using it" > that is "hopefully" long enough, to cover "most interesting" > (to be blunt: read: "including my") use case. I don't think we should deprecate things, much less warn about, until there's a suitable example, except in few cases where the API was mis-designed and has no solution. That doesn't mean the solution needs to be a simple search-and- replace, but it needs to exist. Does that change what you're proposing? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] On deprecating functions
On Monday, 4 March 2019 13:27:42 PST André Pönitz wrote: > Truly personally, I'd even go for > "no deprecation at all *for purely cosmetical reasons*" as I've seen > too many taking route That's a good point. Often we deprecate things because we had a misspelling or failed to take our own naming convention into account. So maybe what we need is a two-level warning system: one for bad things that you really should be doing differently and one for cosmetic things. Definition of cosmetic: a typedef or a function that will be inline in 6.0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] forcing libxkbcommon to be present in the system makes newer Qt unusable on older linux distros
On Tuesday, 5 March 2019 06:52:27 PST Gatis Paeglis wrote: > "This library is present on all supported platforms." Please note the implication on this: the Linux distribution you're using is NOT a supported one. The commit removing xkbcommon explicitly says so: http://code.qt.io/cgit/qt/qtbase.git/commit/? id=c3a963da1f9e7b1d37e63eedded61da4fbdaaf9a Having libxkbcommon in 3rdparty sources is not necessary anymore, after RHEL 6.6 was removed from the list of supported platforms for Qt 5.12. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtWebEngine file path too long
On Tuesday, 12 March 2019 15:44:22 PDT Samuel Gaist wrote: > The solution currently is to move the build out of the encrypted partition. That's not an option for me. Company requires full hard-drive encryption. What OS and what encryption are you using? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtWebEngine file path too long
On Wednesday, 13 March 2019 13:44:44 PDT Samuel Gaist wrote: > I’m using KDE Neon with the default setup for encrypted disk. IIRC it’s done > through LVM. Then encryption has nothing to do with it. If you use a regular LUKS-based block encryption, then you're running a regular filesystem which should exhibit the same path limitations as without. If you're using ecryptfs, upgrade on your next reinstallation. ecryptfs is deprecated and buggy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QStringLiteral is broken(ish) on MSVC (compiler bug?)
On Thursday, 14 March 2019 13:54:29 PDT NIkolai Marchenko wrote:
> I've posted about this issue (I think) on slack a bit earlier, see
> https://cpplang.slack.com/archives/C29936TQC/p154989901601
For those who can't read it, the suggestion was to use the /utf-8 option to
the compiler (with qmake, CONFIG += utf8_source). But a quick set of testing
does not show correct results. For
char16_t text1[] = u"" "\u0102";
It produces, without /utf-8 (see https://msvc.godbolt.org/z/EvtKzq):
?text1@@3PA_SA DB '?', 00H, 00H, 00H; text1
And with /utf-8:
?text1@@3PA_SA DB 0c4H, 00H, 01aH, ' ', 00H, 00H; text1
Those two values make no sense. U+0102 is neither 0x003f (question mark) nor
0x00c4 0x201a ("Ä‚"). This is a clear compiler bug. An interpretation of the
C++11 standard could say that the translation is correct for the no-/utf-8
build, but with /utf-8 or /execution-charset:utf-8 it should have produced the
correct result.
C++11 2.14.5 [lex.string]/13 (now 5.13.5/12 [1]) says:
"If one string-literal has no encoding-prefix, it is treated as a string-
literal of the same encoding-prefix as the other operand."
In table 9:
u"a" "b"is the same as u"ab"
[1] http://eel.is/c++draft/lex.string#12
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QStringLiteral is broken(ish) on MSVC (compiler bug?)
On Friday, 15 March 2019 05:27:09 PDT Giuseppe D'Angelo via Development wrote: > The mapping of \u escape sequences to the execution character set > happens before string literal concatenation (translation phases 5/6). > But AFAIU the mapping is purely symbolic, and has nothing to do with any > actual encoding, so MSVC is at fault here? The people from the SG16 in the committee think it is and are preparing a paper to clarify. They came to the same conclusion regarding the steps the compiler performed as you did, but those steps still lead to an absurd result. Why in the world would anyone want the UTF-16 representation of the UTF-8 encoding of something? The point is that the compiler had 0xC4 0x82, knew it was UTF-8 and was being asked to provide an UTF-16 representation. It should have performed a UTF-8- to-UTF-16 transformation, not CP1252-to-UTF-8 one. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QStringLiteral is broken(ish) on MSVC (compiler bug?)
On Friday, 15 March 2019 11:09:20 PDT Matthew Woehlke wrote:
> (Note: Another solution is to redefine QT_UNICODE_LITERAL_II to `u ##
> str`, but that's SIC.)
And doesn't help, because you *can* write
QStringLiteral("a" "b" "c")
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QStringLiteral is broken(ish) on MSVC (compiler bug?)
On Friday, 15 March 2019 11:12:30 PDT Thiago Macieira wrote:
> On Friday, 15 March 2019 11:09:20 PDT Matthew Woehlke wrote:
> > (Note: Another solution is to redefine QT_UNICODE_LITERAL_II to `u ##
> > str`, but that's SIC.)
>
> And doesn't help, because you *can* write
>
> QStringLiteral("a" "b" "c")
Extra note: you couldn't write this prior to MSVC 2013 getting dropped from
the Qt support matrix, as that compiler failed to properly concatenate strings
as per Lexer Phase 6 requires.
It was a different problem with supporting the same part of the spec as the
problem you've found.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Continuous Integration for 3rd party projects using Qt
On Sunday, 17 March 2019 11:05:08 PDT Denis Kormalev wrote: > Travis can cover macosx, linux (and using docker it can cover different > environments/compilers and packaging for various distribs) and android > (with linux as host). Appveyor can cover Windows builds. Those two are what I use for TinyCBOR, which uses Qt for its unit test system (in turn, Qt uses TinyCBOR). I usually hate working with Travis, since it's always hit and miss and if you stop looking at it for a few months, things will bit-rot and break, but because of its macOS support, it's the best out there. AppVeyor is much nicer and has Qt pre-installed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Continuous Integration for 3rd party projects using Qt
On Sunday, 17 March 2019 23:49:09 PDT Uwe Rathmann wrote: > Hi, > > thanks for the all the hints in this thread - I will check them if I > can't find a service, that is more specific: > > a) > > The very first of my problems is to know about the platforms I need to > test. I guess the list of all operating system and compiler combinations > can be found somewhere in the Qt docs, but considering, that only on > "Linux" you have to consider gcc/icc/clang - for gcc only you have > v4/5/6/7/8 ... As Denis said, you can easily use container images to get most of those operating systems tested. Just be careful with containers that Qt 5.10 through 5.12.2 will not like being run on a kernel that is older than the distribution usually ships with. By coincidence, I submitted a fix for that today[1]. But I don't think you need to test all GCC combinations, much less in each OS. Compiling with the latest is usually sufficient for most cases, as usually the compilers start catching things they didn't use to. Especially if you want to be warning-clean, like Qt. You'll likely need to test at least the oldest compiler you still support, to make sure that you're not using some C++11/14/17 language or standard library feature that the compiler lacks. > b) > > Furthermore a project like Qwt supports all Qt versions >= 4.4. Even, > when limiting the tests to a set of relevant versions - let's say > 4.8/5.6/5.9/5.12 - complexity grows significantly. Here's where distribution packaging helps. When using Travis, I use Stephan Binner's Qt PPAs[2]. With Travis, you can easily select between Ubuntu 12.04 (Trusty) and 14.04 (Xenial) by a simple line in the .yml file, so that will give you all the way from 4.8.7 to 5.12.1. I've never installed older versions of Qt using Homebrew (on macOS), so I don't even know fi this is possible. I doubt they'll have really old stuff. As for AppVeyor, they also have quite a few Qt versions (see [3]), but not including 4.8. [1] https://codereview.qt-project.org/256162 [2] https://launchpad.net/~beineri [3] https://www.appveyor.com/docs/windows-images-software/ -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Brett Stottlemeyer for Approver status
On Monday, 18 March 2019 01:05:22 PDT Ville Voutilainen wrote: > Brett is the maintainer of Qt Remote Objects. Thus he should be > documented as a maintainer, and should also be an approver. Brett has > been effectively maintaining QRO since 2014, so it seems like a slam > dunk to give him the rights. +1, of course. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QML preprocessor
On Tuesday, 19 March 2019 09:03:16 PDT Jason H wrote: > I don't know why you can't just use a C/C++ preprocessor to generate the > qml? For Clang, -E : Only run the preprocessor qglobal.h is assembler-safe too. -D__ASSEMBLER__ and it won't produce C or C++ code that would confuse your parser. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QVariant container API
On Monday, 1 April 2019 11:09:27 CEST Vasily Pupkin wrote: > Hi. > > I would like to submit a patch. Since it is probably going to break binary > compatibility and is mostly about coding conventions, I would like to have > some feedback before investing time. If it's going to break BC, it's a Qt6 API only. Please design your change so that it exists inside an #ifdef alongside the existing code. > The general idea is to create a playground project for automatic > (de)serialization for Qt (not manual, i.e. overriding operators). The only > stopper is container deserialization. I'm not sure I want to see more Datastream-based serialisation. The code there is too fragile and not compatible enough with standards. I recommend you reconsider and think about a more standard format. > Seriazation is quite straightforward via QSequentialIterable and > QAssociativeIterable. But deserialization is currently possible only by > QMetaType::registerConverter. I think, that this is would be so nice to > have an ability to create a container via QVariant from collection of > QVariant instances without a need for custom converters. > ~ > QList variantContainer; > variantContainer.append(QVariant(123)); > variantContainer.append(QVariant(321)); > QVariant variant(QVariant::fromValue(variantContainer)); > QVariant containerVariant(variant.convert(qMetaTypeId >())); > ~ This is a very lossy conversion without sufficient error reporting. That's an example of why I don't think we should invest more time in this type of API. > And so I have stumbled into a problem. QSequentialIterable and > QAssociativeIterable related code is scattered across and > . All related conversions are conveyed in templates, instead > of > https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.cpp#n > 387 . > I just don't feel, that further > https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.h#n78 > 2 and > https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qmetatype.h#n1 > 121 development > is the way to go. Nor I. That code is black magic to me and I don't touch it. > And so the question is: should I try to refactor sequential and associative > iterators, so templates are used only to staticaly gather information about > containers and conversions are made in qvariant.cpp, where they belong? I suggest you leave it alone. > It also would be nice to hear, if someone acknowledges this conversion > feature to be of use. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QVariant container API
On Monday, 1 April 2019 12:41:59 CEST Vasily Pupkin wrote: > > is too fragile and not compatible enough with standards. I recommend you > > reconsider and think about a more standard format. > > Just wanted to clarify, that I am working on a solution, which is totaly > different from datastream serialization (and opposes it) and is format > agnostic. It has an abstract module, which can be implemented for XML, JSON > and so on. > The API would be QByteArray serialize(const QVariant& value), and QVariant > might be a gadget or a collection of any depth. The only thing it does, is > peaking inside QVariant and recursively (de)serializes properties or items. My first reaction is that I don't like it. We already have too many of those and we've had proposals for such API before. But I'm not going to stop you. Make a proof of concept and we may be able to discuss. Worst case is that we don't add it to QtCore, but it gets released elsewhere. > > Nor I. That code is black magic to me and I don't touch it. > > Is it going to be left like that forever :( ? Yes, unless someone steps up and maintains it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QVariant container API
On Monday, 1 April 2019 12:41:59 CEST Vasily Pupkin wrote: > The API would be QByteArray serialize(const QVariant& value), and QVariant > might be a gadget or a collection of any depth. The only thing it does, is > peaking inside QVariant and recursively (de)serializes properties or items. By the way, conversions through QVariant are *exactly* what I implemented in the examples/corelib/serialization/convert tool. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QtScript review required: https://codereview.qt-project.org/253585
There's a patch for QtScript that has gone unreviewed for close to 2 months now. Can someone make a yay or nay decision on it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Adding more Datetime classes to Qt
On Tuesday, 9 April 2019 05:11:03 PDT Pouya Shahinfar wrote: > You open a project which is developed by someone else, and he/she used > QDateTime for holding time and date. The problem here is you as a newcomer > to project do not know the value in the class is based on UTC or local > time, etc. if there was a class like QLocalDateTime, the code was more > maintainable. Why is the code unmaintainable or unreadable just because the information is not in the class name? The information *is* there, held inside the object. You can ask it (timeSpec(), offsetFromUtc() and timeZone()) what it is. So what is the problem? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Adding more Datetime classes to Qt
On Wednesday, 10 April 2019 03:36:47 PDT Mark De Wit wrote: > It might be good to highlight, for instance, that MSecsSinceEpoch is not > share-able between users in different timezones unless QDateTime is > instantiated with a timespec of Qt::UTC (which is not the default). Of course it is sharable. If I tell you that I replied to your email 33 hours after you sent it, it's completely irrelevant that you're in British Summer Time and I'm in Pacific Daylight Time. The span of time between those time points is the thing that matters, the same way that the milliseconds since epoch do. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Static Package
On Sunday, 14 April 2019 16:47:07 PDT Carlos Enrique Pérez Sánchez wrote: > There is a Jira suggestion: > https://bugreports.qt.io/browse/QTBUG-72810 > > Please give an upvote there it if you agree. Better yet: instead of upvoting, omeone post the full command-line that produces a working build. The problem with static is that it requires changes to the user application's .pro file to make sure all the plugins were properly linked. Anything but qmake at this point is probably just going to fail too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt online SDK security problems
On Thursday, 18 April 2019 17:31:57 +08 Khuram Ali via Development wrote: > I agree. Why not offer a patch for the bug fixes, instead of a new release > which needs to be installed separately. The patch is available for download from the Git repository. After you apply it, re-run configure and make again. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Static Package
On Friday, 19 April 2019 08:11:41 +08 Carlos Enrique Pérez Sánchez wrote: > ``` > ./configure -prefix "/somePath/Qt512Static" -static -release -opensource > -confirm-license -qt-zlib -qt-pcre -qt-libpng -qt-libjpeg -fontconfig > -qt-xcb -opengl desktop -sql-sqlite -make libs -make tools -nomake examples > -nomake tests -skip qtwebengine > ``` Please note the -qt-zlib option and family: if you choose to use the bundled versions from Qt, you'll need to monitor those upstreams for security issues and, if any is found, rebuild your application after applying the fix to the sources bundled in Qt. Far better to use -system-zlib and family. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Static Package
On Friday, 19 April 2019 00:43:29 PDT Khuram Ali via Development wrote: > ERROR: Feature 'xcb' was enabled, but the pre-condition 'features.thread && > features.xkbcommon && libs.xcb' failed. What i am missing? Very likely, a recent version of xkbcommon. It's no longer bundled with Qt. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] MSVC 2019 pre-built binaries
On Thursday, 25 April 2019 05:13:55 PDT resurrect...@centrum.cz wrote: > I was wondering what are the plans for the Qt pre-built binary release built > with MSVC 2019 (16.0+)? The SP support for MSVC 2017 ends along with Window > 7 support on 14th January 2020 > (https://support.microsoft.com/en-us/lifecycle/search?alpha=Visual%20Studio > %202017 > <https://support.microsoft.com/en-us/lifecycle/search?alpha=Visual%20Studio > %202017>) and after that only the maintenance and no active development will > be done for MSVC 2017. It would make sense to switch to the 2019 even > before that happens and favour it in the installer over the 2017 version. > Or perhaps provide both for some time similar to how now there are both > 2015 and 2017 versions now - having 2017+2019 and dropping 2015 whose > support ends in 2020 anyway. The 2017 binaries should work in 2019. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Static Package
On Monday, 29 April 2019 00:27:14 PDT Mitch Curtis wrote: > -static -release -ltcg -opensource -confirm-license -nomake tests -nomake > examples -silent -static -ltcg is most definitely not redistributable. That build is only usable in your exact machine, and only for so long as you don't perform a system update. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Static Package
On Monday, 29 April 2019 08:36:09 PDT Ola Røer Thorsen wrote: > man. 29. apr. 2019 kl. 17:20 skrev Thiago Macieira < > > thiago.macie...@intel.com>: > > On Monday, 29 April 2019 00:27:14 PDT Mitch Curtis wrote: > > > -static -release -ltcg -opensource -confirm-license -nomake tests > > > -nomake > > > examples -silent > > > > -static -ltcg is most definitely not redistributable. That build is only > > usable in your exact machine, and only for so long as you don't perform a > > system update. > > Why is that exactly? Do you mean the Qt libraries are not redistributable, > or a final application built with it (also using lto)? Just curious. The problem is the combination -static -ltcg. Any LTCG .o can only be consumed by the exact toolchain you have in your system. You can't upgrade it, much less change to a different Linux distribution. I'd venture that changing *any* header used in the build is a problem. With -static, all those .o files get added to the .a that are distributed. Since you can't even upgrade, allowing other users to use your output is a bad idea. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] unique_ptr and Qt, Take 2
On Friday, 3 May 2019 10:22:20 PDT Daniel Teske wrote:
> std::unique_ptr rightButton =
> std::make_unique("RIGHT");
> layout->addWidget(std::move(rightButton));
The problem in this particular example is that once you've added the widget,
the rightButton smart pointer no longer has a pointer. You can't continue to
set up your push button. In most cases, this is just a matter of moving the
set up before the addition / reparenting, or using the other idiom where the
object is never in a smart pointer in the first place.
So this begs the question of whether std::unique_ptr is the best smart pointer
for this scenario. Would it make sense to create one that understands parent-
child relationship?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] unique_ptr and Qt, Take 2
On Friday, 3 May 2019 11:41:16 PDT Иван Комиссаров wrote: > auto button = layout->addWidget(make_unique(«RIGHT»)); > button->setFlat(true); The problem with code that has pre- and post-addition setup is that now you have two objects in the stack, which complicates your stack frame. The compilers aren't currently smart enough to deduce std::unique_ptr whose payload is completely null and can be early-destroyed. I'm wary of making user code less readable, but it's something we should do if it's for a good reason. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] unique_ptr and Qt, Take 2
On Friday, 3 May 2019 12:04:40 PDT Giuseppe D'Angelo via Development wrote: > Anyhow, I too feel that we may need a dedicated smart pointer class for > this, to catch all the corner cases and allow the existing flow of > > 1) create something > 2) (re)parent it > 3) keep using that something via a non-owning pointer. Same here. I think Daniel is on to something and we really should explore having smart pointers in Qt 6, but at this point I'm not convinced std::unique_ptr alone is it. I'd like to see what we could achieve with a QObject-specific smart pointer that understood ownership-taking functions (setParent, addWidget, etc.) and observing-only API (like connect()). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] unique_ptr and Qt, Take 2
On Friday, 3 May 2019 12:32:01 PDT Allan Sandfeld Jensen wrote: > Alternatively QObjects should be referenced counted, one reference could be > from a parent, but you could also strong reference with an explicit shared > pointer. The problem with that is that you can create QObjects on the stack and those mustn't be refcounted. That said, the QPointer mechanism since 5.0 is basically refcounting, Technically, it's a refcounted refcounter. Since it shares the same class as QSharedPointer, it *has* the strong refcount inside, which could be used for this. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] unique_ptr and Qt, Take 2
On Friday, 3 May 2019 13:00:52 PDT Иван Комиссаров wrote: > Which should be considered bad practice and banned on an API level No way. Are you going to forbid creation of QFile on the stack? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] unique_ptr and Qt, Take 2
On Friday, 3 May 2019 16:14:09 PDT Иван Комиссаров wrote: > What I am talking about is that explicit is better than implicit. Taking an > address of an object on a stack and passing it to a function that (possibly > can) delete your object is not explicit. Wrapping that operation in a > construction of a smart pointer is explicit. Moving a unique_ptr is > explicit. When you’re «casting» your on-a-stack-QFile to a some smart > pointer, you’re telling the compiler (and other people who read the code) > «trust me, I know what I’m doing, this is intended». That I can agree with, but this goes back to the suggestion of our own smart QObject pointer classes. In non-compatibility mode, a function that adopts the passed object should only accept from another smart pointer. If you pass a naked pointer, it should reject and force you to clearly state that you know what you're doing. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Gerrit Upgrade
On Tuesday, 7 May 2019 02:11:55 PDT Jukka Jokiniva wrote: > If someone want to see the new UI in action, the Gerrit code is reviewed in > Gerrit: https://gerrit-review.googlesource.com/ Just a note that the site > is using the very latest 3.0 RC, and we will be using 2.16.7, but the UI is > pretty much the same. The biggest issue with the new Gerrit UI and the reason we hadn't switched was the lack of full-commit review mode. But this looks to be a newer UI than the one I knew about and it does look like it has a full-commit review mode, in the same page that the previous comments show up. Looks like a definite improvement! -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Linking androiddeployqt: boot-strap library or libQt5Core
On Monday, 13 May 2019 07:28:55 PDT Edward Welbourne wrote: > Does anyone know why androiddeployqt links against the boot-strap > library ? i.e. Is there any good reason not to change it to link > against libQt5Core instead ? androiddeployqt is a host tool. You don't run it on-device, but on the machine you compiled Qt on. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QList for Qt 6
On Thursday, 16 May 2019 06:05:37 PDT Mutz, Marc via Development wrote: > Going forward, we should be looking into removing more and more owning > containers from the interface and replace them with views. The standard > is working on a solution for the stale reference problem, and by the > time Qt 7 comes around, it will be hopefully widely available. That goes against the Qt API design. Do not return views, since it implies that internally there is an object that produces that view and that it does not go out of scope. The reason we return full, owning containers is so we have the freedom inside to change how we store the data without that affecting our API. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Views (was: Re: QList for Qt 6)
On Thursday, 16 May 2019 08:26:08 PDT Mutz, Marc via Development wrote:
> > That goes against the Qt API design. Do not return views, since it
> > implies
> > that internally there is an object that produces that view and that it
> > does
> > not go out of scope. The reason we return full, owning containers is so
> > we
> > have the freedom inside to change how we store the data without that
> > affecting
> > our API.
>
> I believe the opposite to be true: I believe owning container use in the
> API to break a class' encapsulation:
>
> If you return QVector<>, which choices do you have for the internal data
> structure? A QVector.
When you first design the class, sure. But 5 years later, you may have the
data internally kept in a QMap or QHash, mapped to some other information. So
your function that used to "return d->member;" now does
"return d->member.keys();"
Another case would be where you're keeping extra data in the internal
structure and you need to filter that out before returning. Or the dual:
augment with some implied data. The latter could be quite common if the class
is not storing anything in the regular case, but synthesising it on demand for
the benefit of the old API.
> If you return a view, you can use a std::vector, a QVector, a C array
> internally, even switch at runtime (like QRegion does for the case of a
> single rect). So views allow the implementation to vary its internal
> data storage strategy while returning owning containers does not.
But only so long as each of those containers store lay the data out the same
way in memory, which is not the case for my QMap example.
> And no, you _can_ write views for node-based containers, too. Cf. how
> QVariant is (indirectly) iterable these days.
Sure, but you'd have to change the public API to return that view instead of
the contiguous-storage one. Unless we predict that that would be the case and
always return a view that uses an indirect data-access method, which
potentially owns the data. Does such a view exist?
> Sure, you'd not return a view to data that the class in question does
> not already own, though with coroutines you could return a generator
> instead. This is about the data that is already stored in the object.
> This is about QRegion::rects() and QGradient::stops(). This is also
> about QAIM::roleNames(). All these APIs lock down the implementation to
> a particular data store, thus _reducing_ the implementation's freedom to
> adjust it's internal workings. And by Hyrum's Law, they also make users
> depend on idiosyncrasies of the implementation, as witnessed by the
> pre-QRegion::begin/end() anti-pattern of abusing boundingRect() when
> rectCount() == 1 in order to avoid the building of a QVector just to
> store one rectangle, a special-casing I could remove in 100% of cases
> once QRegion became iterable (= a view on it's rects property).
Two of your examples basically return an internal structure, so I'm not seeing
how they are relevant. QGradient::stops is a good example that synthesises
data on-demand in one case:
if (m_stops.isEmpty()) {
QGradientStops tmp;
tmp << QGradientStop(0, Qt::black) << QGradientStop(1, Qt::white);
return tmp;
}
return m_stops;
How would you implement this one with a view-based return?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Views (was: Re: QList for Qt 6)
On Thursday, 16 May 2019 11:00:58 PDT Иван Комиссаров wrote: > > Another case would be where you're keeping extra data in the internal > > structure and you need to filter that out before returning. > > And now trivial getter allocates and has an O(N) complexity. > > Please, don’t do changes like that. It’s really not cool to find > *interesting* things in a profiler after the Qt upgrade. These changes are not done trivially, but if we think it's the best way, then we certainly will do them again. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Views
On Thursday, 16 May 2019 11:18:08 PDT Mutz, Marc via Development wrote:
> > When you first design the class, sure. But 5 years later, you may have
> > the
> > data internally kept in a QMap or QHash, mapped to some other
> > information. So
> > your function that used to "return d->member;" now does
> > "return d->member.keys();"
>
> Can you point out a Qt class where this was the case in the past?
I'll have to look it up, but it has happened in the past and if not in Qt,
then in one of the KDE libraries. The Library API Design Policy includes this
particular point (don't return references) for a reason.
> > Another case would be where you're keeping extra data in the internal
> > structure and you need to filter that out before returning. Or the
> > dual:
> > augment with some implied data. The latter could be quite common if the
> > class
> > is not storing anything in the regular case, but synthesising it on
> > demand for
> > the benefit of the old API.
>
> This one is simple: Array of struct -> struct of arrays. Well-known
> optimisation in the games industry.
Sure, but if you returned a view of structs, how would you later make that
view of structs work with your internally-stored struct of arrays?
> > But only so long as each of those containers store lay the data out the
> > same
> > way in memory, which is not the case for my QMap example.
>
> You basically have a dichotomy: Either you have contiguous storage, in
> which case you return pointers, or you have non-contiguous storage, in
> which case you need some form of runtime-dispatch Iterator Pattern.
Or you have a well-known storage pattern, in which case you don't return an
array of pointers (which would need to be allocated anyway), but you return a
means of finding those elements. That's what the containers do for you.
So I don't have a problem returning a type that is cheap when you're designing
the API, so long as you don't lock yourself into it if you later want to
change. I don't see anything but actual containers here.
> I don't think you'd ever come into a situation where you'd need to
> switch from one to the other. If you think so, please provide an example
> where this was necessary in the past.
I'll look it up. Note that in hindsight all of those will look like bad
design, but the point is that we didn't know any better when the design was
first done.
> > Two of your examples [QRegion, QGradient] basically return an internal
> > structure, so I'm not seeing
> > how they are relevant.
>
> How are they not relevant? Because the class basically _is_ a container?
> Well, then see QAIM::roleNames(). Apart from the questionable design to
> return a node-based associative container for the O(10) elements in
> there, instead of a (view to a) sorted array of structs[1], it is a
> prime example of how the API requires a particular implementation. I
> don't remember whether it returns a QMap or a QHash, but either way, one
> might want to return the other, down the road - or even depending on the
> number of elements in the container, like QRegion does.
I meant they are not good examples because they always return something that
currently is stored in the d pointer. So there's no problem in changing them
to return a view to that storage, since that storage does not go out of scope
at function exit.
> For an example of where roleNames() goes horribly wrong, see
> QQmlListModel. Is has the data stored elsewhere and re-constructs a
> QHash each time it's called. With a runtime iterator, it could probably
> produce the values on the fly, and with a sorted array of {role, name}
> it would allocate one block of memory per call, not O(n).
I don't understand what you meant here. Are you advocating that the return
type should have been different? What type would have helped?
Or are you saying that if we had different tools internally, the
implementation of QQmlListModel::roleNames could have been better?
Either way, this is a very good example for why the return type mustn't be a
reference or a non-owning container: the two sources for the function are not
compatible with the return type.
> > How would you implement this one with a view-based return?
>
> Glad you asked:
>
> static constexpr QGradientStop defaultStops[] = {{0,
> QColorLiterals::black}, {1, QColorLiterals::white}};
> return SomeView{std::begin(defaultStops), std::end(defaultStops)};
>
> Instead of the simple solution shown here, what we'll more likely see is
> QVector::fromRawData(). Which is trying to retrofit a view onto an
> owning container. Yuck.
It's a price
Re: [Development] Views
On Friday, 17 May 2019 09:38:05 PDT Marco Bubke wrote: > Thiago, you partially implying that BC is still needed but with technologies > like flatpak or snappy this will maybe not common use case anymore. They > provide even behaviour compatibility if you stay with the same runtime. > Something which is not provided by binary compability. I personally think > if the behaviour is changed it should not even compile anymore so you can > fix it easily. Some level of compatibility is of course required, unless you're proposing we provide a certain level of bugfixing for ALL releases for a number of years. That is, if 6.2 isn't source-compatible with 6.1, then 6.1 needs to be supported for 3+ years with bugfixes for code that was ported to 6.1 but hasn't been ported further to 6.2. If we're still keeping source compatibility but not binary, the problem is not as big as above. But it still exists if you're not in a position to recompile all modules (think third party's component). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ 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?
On Sunday, 19 May 2019 05:24:14 PDT Giuseppe D'Angelo via Development wrote: > 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. I think there are two answers: what an object MUST be and what it SHOULD be. Obviously, the object must be destructible. And at a minimum, the object should be assignable, so a new, valid state can be created. This is the bare minimum. I'd also add that the moved-from object does not hold non-negligible resources still allocated. Classes that allocate O(n) or worse memory, not O(1) like the d pointer. But I think all Qt classes should go beyond that, unless they have VERY good reasons not to do so (and document so). The moved-from object should also be in a valid state so all the accessor and mutation API in the class can operate in the object without ill effects. What they actually do, we can't tell, since the initial state is unknowable. So apply the principle of GIGO. Usually, the easiest way to accomplish that is for the moved-from object to be reset to the default-constructed state. So this is what the Qt move constructors and move assignment operators should be aiming at, by default, unless they have reasons not to. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ 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?
On Monday, 20 May 2019 05:51:49 PDT Mutz, Marc via Development wrote: > Or maybe we don't disagree at all and Thiago would accept allocating > memory (or, by extension, anything that's noexcept(false)) as a very > good reason to have a nullptr d? I hadn't thought of noexcept, but let's be clear: yes, move constructors must be noexcept. That might be the good reason why it can't reset to a valid state. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ 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?
On Monday, 20 May 2019 06:56:56 PDT Lars Knoll wrote: > I actually think we should consider getting rid of shared_null and instead > have d == nullptr as the null/default constructed state of the object. Yes, > that means we need to check for d == nullptr in member functions, but I > don’t think the overhead is a problem, as d will have to be loaded into a > register in any case. It does introduce a compare-and-branch that wouldn't otherwise be there, but the cost is minimal compared to what most API would be doing, indeed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Using Gerrit for new approver proposals?
On Monday, 20 May 2019 01:50:03 PDT Florian Bruhin wrote: > What about using Gerrit to do so? I'm not sure how the repository would look > (probably just text files with the proposal text)? Then people could +1 > that change instead. I'm neutral on this, so long as the announcement of the proposal is sent to the list first. The list is the ultimate decision-making body in the Qt Project. Just as QUIPs record a decision made in the mailing list, the +1 for new approvers and maintainers can be recorded in Gerrit. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
On Monday, 20 May 2019 15:41:16 PDT Bernhard Lindner wrote: > Hi! > > Is it correct that the Qt XML and Qt Xml Patterns components are both > deprecated? Yes, they are. > > If yes, are there any details known like: > - How long or up to which Qt version will these components be part of Qt? > - Will replacment components be available? The replacement for QtXml are the streaming classes in QtCore. They've been available for 10 years. There is no replacement for the XMLPatterns module. > - Are security fixes still be implemented? Yes, definitely, for as long as we ship them plus 5 years. > - Are the deprecations irrevocable? No. Deprecations are only irrevocable when we want to get rid of code that is in the way of making progress, such as the QList discussion. Those two modules are not in the way of anything else, so the decision can change. All it takes is someone stepping up to maintain either or both of them. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ 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?
On Monday, 20 May 2019 12:05:58 PDT Allan Sandfeld Jensen wrote: > I agree. I would consider anything other than deleting or reassigning a > moved object undefined behavior, so asserting on it seems like a good help > to users of our APIs. I agree, but we should leave this as a fallback case, albeit legitimate and not too difficult to justify. Here are a couple justifications: - allocating memory (violates noexcept) - retaining unknown quantities of memory (in the case of the assignment op) - complex or slow code - pessimises code elsewhere -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
On Monday, 20 May 2019 19:35:03 PDT Kevin Kofler wrote:
> Thiago Macieira wrote:
> > The replacement for QtXml are the streaming classes in QtCore. They've
> > been available for 10 years.
>
> But those are no replacement for the QDom* DOM API. They are also not
> idiomatic SAX, by design. Both those limitations make them an insufficient
> replacement for QtXml even for new code, let alone all the existing legacy
> code.
The replacement is not a 1:1 API style and was never meant to. The stream XML
are StAX, whereas QDomDocument is DOM and QXmlReader is SAX. The point is that
you can still read and write XML, it's fast and supports namespaces properly.
> Looking around (e.g., in KDE projects and/or related third-party Free
> Software projects), you will find QtXml still widely used, probably even
> more widely than the newer QtCore XML streaming API (depending on your
> sample).
I know. The DOM is extremely useful, which is why I wrote QCborValue (DOM) in
addition to QCborStream{Reader,Writer} (StAX) and that's why QJsonDocument
(DOM) is so easy to use.
But the fact is that QDomElement and friends aren't getting maintained.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
On Tuesday, 21 May 2019 00:15:04 PDT Bernhard Lindner wrote: > Unlucky me. Deprecation of these two components literally broke every > application I have ever written using Qt. I hope they will have new > maintainers some day. Note I said QtXml is deprecated, but it might actually be in Done state. I don't remember. Does anyone? Where's our authoritative source? The difference between Done and Deprecated is whether we're telling you to start porting code away. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
