Re: [Development] Q_DECLARE_TYPEINFO compile time checks
-Original Message- From: m...@kdab.com [mailto:m...@kdab.com] On Behalf Of Marc Mutz Sent: Monday, 27 July 2015 3:29 PM To: Curtis Mitch mitch.cur...@theqtcompany.com Cc: development@qt-project.org Subject: Re: Q_DECLARE_TYPEINFO compile time checks On Monday 27 July 2015 14:02:59 Curtis Mitch wrote: You mentioned that you have some kind of enforcement of the Q_DECLARE_TYPEINFO stuff - can you please share this so that others can run it on their modules? It currently conflicts with Thiago's changes to add Q_RELOCATABLE_TYPE. I'll upstream parts of it that can be upstreamed once his stuff has merged, but the basic trick is: - add isSpecialized = false to the primary QTypeInfo template ( = Q_IS_ENUM when Q_RELOCATABLE_TYPE lands) - add isSpecialized = true to all specialisations - static_assert that QTypeInfoT::isSpecialized in various places: * inside QVector::append * QList::node_construct * Q_DECLARE_METATPYE * whereever else it makes sense (I have the above three) That doesn't catch all cases, of course, and it will not compile as long as QtCore hasn't been fully fixed (which requires Q_RELOCATABLE_TYPE), but we don't have a central macro that declares a type as a value type, so the three places above are the best I have come up with so far. I'll upstream the addition of isSpecialized once Thiago's stuff is in. We should probably also change the Q_DECLARE_SHARED to be Q_DECLARE_VALUE_TYPE and _WITH_SWAP(). Then we have a central macro to put these checks, maybe just for headerscheck. Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts Hmmm, I don't think that helps with https://codereview.qt-project.org/#/c/122268/, for example. Oh well. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replace QtXml backend
On Monday 27 July 2015 09:47:34 Knoll Lars wrote: With the old QXmlReader or with QXmlStreamReader? We are currently using QXmlSchemaValidator for the validation. QXmlStreamReader is not a SAX parser. But the approach is very similar. Both are iterative. :) Best regards Gerhard ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Q_DECLARE_TYPEINFO compile time checks
On Monday 27 July 2015 14:02:59 Curtis Mitch wrote: You mentioned that you have some kind of enforcement of the Q_DECLARE_TYPEINFO stuff - can you please share this so that others can run it on their modules? It currently conflicts with Thiago's changes to add Q_RELOCATABLE_TYPE. I'll upstream parts of it that can be upstreamed once his stuff has merged, but the basic trick is: - add isSpecialized = false to the primary QTypeInfo template ( = Q_IS_ENUM when Q_RELOCATABLE_TYPE lands) - add isSpecialized = true to all specialisations - static_assert that QTypeInfoT::isSpecialized in various places: * inside QVector::append * QList::node_construct * Q_DECLARE_METATPYE * whereever else it makes sense (I have the above three) That doesn't catch all cases, of course, and it will not compile as long as QtCore hasn't been fully fixed (which requires Q_RELOCATABLE_TYPE), but we don't have a central macro that declares a type as a value type, so the three places above are the best I have come up with so far. I'll upstream the addition of isSpecialized once Thiago's stuff is in. We should probably also change the Q_DECLARE_SHARED to be Q_DECLARE_VALUE_TYPE and _WITH_SWAP(). Then we have a central macro to put these checks, maybe just for headerscheck. Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replace QtXml backend
On Monday 27. July 2015 14:24:27 Gerhard Scheikl wrote: On Monday 27 July 2015 09:47:34 Knoll Lars wrote: With the old QXmlReader or with QXmlStreamReader? We are currently using QXmlSchemaValidator for the validation. QXmlStreamReader is not a SAX parser. But the approach is very similar. Both are iterative. :) I believe the confusion comes from the fact you said QtXml instead of QtXmlPattern. This is an entierly different module. (Maybe the bug you are talking about is https://bugreports.qt.io/browse/QTBUG-12534 which indeed is quite bad.) IMHO, having another backend than the current unmaintained one would indeed be preferable. The problem is that we have to be sure we can do everything that the current one is doing without too many regressions. And still working on all supported platforms. This can be a lot of work. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Q_DECLARE_TYPEINFO compile time checks
On Monday 27 July 2015 17:59:24 Marc Mutz wrote: On Monday 27 July 2015 15:12:03 Curtis Mitch wrote: Hmmm, I don't think that helps with https://codereview.qt-project.org/#/c/122268/, for example. Oh well. We could have syncqt.pl check for Q_DECLARE_TYPEINFO(T, X) for any T it generates a header for, but that doesn't work for several reasons: 1. It doesn't catch nested types 2. It doesn't work when the typeinfo is declared without the macro, e.g. with QTypeInfoMerger. 3. It doesn't catch private types (both in _p.h and .cpp) I have a pending patch to syncqt that makes it scan _p.h. 4. It doesn't catch enums (Q_RELOCATABLE_TYPE will be set for enums, but in private API, we still want to manually set Q_PRIMITIVE_TYPE). Of course, one could use some GCC or Clang output to get a list of all I doubt there's a better way currently than manually marking all types. That's why it's important to insisit on it in reviews. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
On Monday 27. July 2015 01:25:18 NIkolai Marchenko wrote: Hi! We (Russian Qt community) have a situation we could not resolve with Thiago Macieira in bug tracker, so have to ask for Chief Maintainer's attention. The bug in question is there: https://bugreports.qt.io/browse/QTBUG-47316 [...] I agree with you that by default qDebug() someString; should indeed not escape the printable character, and print them as it. This is what most would expect. QString is meant to contains unicode! (For QByteArray this is different since QByteArray does not specify the encoding) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 08:44:30 Knoll Lars wrote: I can understand the issues that non latin speakers are facing with this well. I’ve often used qDebug() to debug non latin use cases, and in 90% of the cases I just want to know what the string reads. The unicode content of it is interesting to me in only 10% of the cases. For most users not debugging Qt’s internals I would assume that ratio to be more like 99 to 1. As I said in my email, the problem is that you will not turn this on for those 10% of the cases until you've already lost data, either visibly or really. I'm counting ambiguity and homographs as apparent data loss because it will send you down the wrong debugging path. Thiago, which backends can’t handle utf8 or utf16 output these days? Android log, slog2, syslog and the regular stderr output if the system locale isn't UTF-8. In particular, on Windows the system locale is never UTF-8 unless you're using Vietnamese Windows. On the other hand, the OS X system locale is always UTF-8 unless you've messed up, including with setCodecForLocale. Or, if I list those that always do: WIndows OutputDebugString and journald. None of those are binary-safe, which means they will not work with a QString containing a NUL character. One idea could be a slightly modified approach that is more compatible: * We always encode QStrings as utf8 (maybe utf16 for the windows console) when sending them to qDebug() That would change behaviour for people with non-UTF-8 systems, as they'd now see mojibake. * We quote every character that is not printable (ie. !QChar::isPrint()) This is what I've done, except that I used ctype.h's isprint(), under the C locale. I considered using QChar::isPrint here, but it would be very expensive and it would not solve the homograph and ambiguity problem anyway. Better to just do nothing than use QChar::isPrint. * We add a flag that would give fully quoted strings so you can get a quoted version if required (e.g. qDebug() quoteStrings) I'm ok with a flag, as long as it's the default. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Q_DECLARE_TYPEINFO compile time checks
On Monday 27 July 2015 15:12:03 Curtis Mitch wrote: Hmmm, I don't think that helps with https://codereview.qt-project.org/#/c/122268/, for example. Oh well. We could have syncqt.pl check for Q_DECLARE_TYPEINFO(T, X) for any T it generates a header for, but that doesn't work for several reasons: 1. It doesn't catch nested types 2. It doesn't work when the typeinfo is declared without the macro, e.g. with QTypeInfoMerger. 3. It doesn't catch private types (both in _p.h and .cpp) 4. It doesn't catch enums (Q_RELOCATABLE_TYPE will be set for enums, but in private API, we still want to manually set Q_PRIMITIVE_TYPE). Of course, one could use some GCC or Clang output to get a list of all I doubt there's a better way currently than manually marking all types. That's why it's important to insisit on it in reviews. -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replace QtXml backend
On Monday 27 July 2015 09:58:42 Gerhard Scheikl wrote: How is it licensed? Apache 2.0 This is a deal-breaker. Maybe creating a 3rd party library would be the better choice. Maybe creating something like QtXml2 would be an option. QtXml2 under an LGPLv3 licence might be a acceptable instead. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 01:25:18 NIkolai Marchenko wrote: Hi! We (Russian Qt community) have a situation we could not resolve with Thiago Macieira in bug tracker, so have to ask for Chief Maintainer's attention. The bug in question is there: https://bugreports.qt.io/browse/QTBUG-47316 Yes, I asked that they post here if there's a need to overrule me. I wanted Nikolai to get his story out first, which is why I waited a day before replying. Now, let's start with the subject: it's a change in behaviour, properly documented in the changelog[*], in an area that did not work properly before. Previously, the debugging of QStrings would produce ambiguous output if the source string had any quote characters. More importantly, it could lose data, as the qDebug output was not 8-bit clean. Therefore, the functionality was never officially supported. [* Important: the changelog was not posted for the 5.5 release] The change makes the functionality now consistent across all platforms, through all qDebug backends. It also makes the output unambiguous, since a quote character is escaped to indicate it's still part of the string. It adds two more interesting features: 1) the string can be copied back into the source code and will compile to exactly the contents of the QString or QByteArray that produced it. No more need to escape backslashes, for example. 2) the output has no homographs, no control characters and no zero-width codepoints (including no combining characters), allowing for easier debugging. A homograph is a character whose glyph is identical to another character. The most widely publicised case is that of the Latin letter a and the Cyrillic а, which was the attack vector for homograph sites like pаypal.com or pаypаl.com or раураl.com or other permutations of the letters. A control character could change the way the text gets logged, like for example the carriage return character causing overwrite of what had already been output in a terminal. I'm not saying qDebug's output is a security issue or possible attack vector, but having no ambiguity and no homographs makes for easier debugging. It could save quite a few minutes of staring at a string that *looks* right but whose manipulation generates an apparently unexpected result. That is, after all, the purpose of qDebug: debugging. By the way, the output of QtTest has also changed in the same way. In version 5.5 Thiago Macieira introduced a compatibility break with older qt versions. This break has come in the form of completely changing the way qDebug() prints non-english characters to console. Let's be clear: this is about non-US-ASCII characters and only if we're talking about a QString or QByteArray. If you're passing a character literal or char* directly, the feature does not kick in. People who did not want the quotes around the string before Qt 5.4 would have already used qPrintable() or similar mechanisms. Anyone using the noquote() feature since 5.4 is also similarly not affected. In essense - his fix to qDebug() will make it so that all non-english output from QString variable to qDebug() will be passed as a sequence of unicode escaped characters along the lines of: \u043F\u0440\u043E\u0432\u0435\u0440\u043A\u0430 043A\u0438\u0440\u0438\u043B\u043B\u0438\u0446\u044B Previously, in _some_ cases, but not reliably cross platform it would actually appear in console as readable output in user's language. I have to admit that Thiago is right about it being non-reliable contradicts qt's goal. Still... Right. What Thiago completely disregards as unimportant - qDebug()'s been around for a long time. Even during times of qt4, users, through the use of setCodec functions, achieved readable output from qDebug in the console in their native language. Again, not properly and not everywhere. Moreover, the requirements to continue to make it work have changed along the way. In Qt 5.0, we introduced a message handler that took QString instead of a char*, so the previous solutions that relied in setCodecForLocale may have stopped working. (I actually don't know if it did, as we've never tested, which goes to prove my point of it being an unsupported feature) Along the next few Qt 5.x releases, we introduced different output backends too, some of which took the data in UTF-8 and others didn't. Note that I say qt4. It's been around for almost a decade and there being no warning qDebug ever changing, it's become a standard on a lot of non-english installations, that actually allowed getting readable output, to use qDebug for tracing variables.. After all, opening debugger to inspect every little thing is very counterproductive. Agreed, even if poor practice to debug via qDebug. A debugger is always a superior solution. Systems where a debugger will not run are not systems worth developing for (fix your toolchain instead or stop using that vendor). Note that superior solution does
Re: [Development] Replace QtXml backend
On Monday 27 July 2015 14:24:27 Gerhard Scheikl wrote: QXmlStreamReader is not a SAX parser. But the approach is very similar. Both are iterative. :) Indeed. The term is StAX parser. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
Or just use qPrintable() around your strings. you do realize, that it will require editing thousands of instances of qDebug in the old code? On Mon, Jul 27, 2015 at 7:26 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Monday 27 July 2015 19:20:34 NIkolai Marchenko wrote: b) getting the old behaviour back requires using noquote everywhere which breaks the code if you need to build it with earlier qt version Or just use qPrintable() around your strings. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Monday 27 July 2015 08:01:53 André Somers wrote: I am not a lawer and I don't know the wording of the KDE Free Qt Foundation agreement, but are you sure that in case that agreement is triggered the verion you branched off off will fall under that licence and be the one that will be released under BSD? I'm just wondering if all versions would retroactively be relicenced or just the current code... _If_ it is the latter, you have a problem in your CLA, as you may not have the right to do the BSD relicencing you promissed seeing that you forked Qt 4 and not 5... https://www.kde.org/community/whatiskde/images/nokia-agreement-3.jpg The section 2 says grants the Foundation [...] the right and license, to use, copy, duplicate [...] any and all existing and future Qt Free Edition releases ... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 19:27:44 NIkolai Marchenko wrote: Or just use qPrintable() around your strings. you do realize, that it will require editing thousands of instances of qDebug in the old code? Yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
If we are to believe Thiago, every developer that needs to see trace information from an old code, now needs to edit all of his qDebug()'ed instances to use qPrintable. Yes, all of them. However much there is, manually, one by one. On Mon, Jul 27, 2015 at 7:34 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Monday 27 July 2015 19:27:44 NIkolai Marchenko wrote: Or just use qPrintable() around your strings. you do realize, that it will require editing thousands of instances of qDebug in the old code? Yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 20:52:24 NIkolai Marchenko wrote: Let's make it harder, can you guesss that it even is a link to paypal website with qDebug() as you intend it to work without copypasting? раураl.соm ? Hint: only 2 letters here are in english. With qDebug() as it is in Qt 5.5, it would be quite evident. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 19:20:34 NIkolai Marchenko wrote: b) getting the old behaviour back requires using noquote everywhere which breaks the code if you need to build it with earlier qt version Or just use qPrintable() around your strings. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 16:54:49 Knoll Lars wrote: QChar::isPrint() is not that expensive, and this is about debug output. Your code escaping all these chars is a more expensive if it gets hit. I don't think so. The code is pretty efficient and it's just a simple stateful loop. QChar::isPrint requires an out-of-line function call for every character and then looking it up in our Unicode tables. That's a lot of data for the L1 cache: qstring.o's .rodata section is 188200 bytes. And I don't see how homographs are a problem for debug output. Unless you're debugging certain rather special cases in which case you should be able to turn full escaping on. I would guess that 98% of our users are using qDebug differently than you are. That is again what I am trying to avoid: having to know that you need this before you actually see the problem. In any case, if we want to escape characters 32, we need to escape the backslash too, which also was a source of complaints in the bug report, as C:\Users became C:\\Users Nikolai didn't include this in his mail to the list. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
you do realize, that it will require editing thousands of instances of qDebug in the old code? Yes. And here, ladies and gentlemen, is exactly the reason this discussion is even happening. This.Should. Not. Be. The. Case. This is just wrong on so many levels I cannot express it in words. On Mon, Jul 27, 2015 at 7:34 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Monday 27 July 2015 19:27:44 NIkolai Marchenko wrote: Or just use qPrintable() around your strings. you do realize, that it will require editing thousands of instances of qDebug in the old code? Yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
On 27/07/15 18:13, development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of thiago.macie...@intel.com wrote: On Monday 27 July 2015 08:44:30 Knoll Lars wrote: I can understand the issues that non latin speakers are facing with this well. I’ve often used qDebug() to debug non latin use cases, and in 90% of the cases I just want to know what the string reads. The unicode content of it is interesting to me in only 10% of the cases. For most users not debugging Qt’s internals I would assume that ratio to be more like 99 to 1. As I said in my email, the problem is that you will not turn this on for those 10% of the cases until you've already lost data, either visibly or really. I'm counting ambiguity and homographs as apparent data loss because it will send you down the wrong debugging path. That's a wrong argument. This happens very rarely in real world use cases. And you don't loose data because of debug output. In most cases, you want to quickly see whether the string says bøh or bæh, and I loose a lot of time as a developer if I don't see that at a glance. Thiago, which backends can’t handle utf8 or utf16 output these days? Android log, slog2, syslog and the regular stderr output if the system locale isn't UTF-8. Well, Android systems are always utf8 afaik. And all modern linux systems are utf8 as well. In particular, on Windows the system locale is never UTF-8 unless you're using Vietnamese Windows. On the other hand, the OS X system locale is always UTF-8 unless you've messed up, including with setCodecForLocale. On Windows we use OutputDebugString by default, which takes utf16. So Mac and Windows are ok as well. That leaves QNX/slog2, and if the system charset there is not utf8, I'm happy if you escape all chars that it can't show on that platform (and in this case QNX should fix their OS). But we should penalize everybody because of one platform that very few people use. Or, if I list those that always do: WIndows OutputDebugString and journald. None of those are binary-safe, which means they will not work with a QString containing a NUL character. Yes, that's why I said that we should encode non printable characters. One idea could be a slightly modified approach that is more compatible: * We always encode QStrings as utf8 (maybe utf16 for the windows console) when sending them to qDebug() That would change behaviour for people with non-UTF-8 systems, as they'd now see mojibake. Well, I think there are no non utf8 systems left apart from Windows, where this isn't a problem (since we use OutputDebugString). * We quote every character that is not printable (ie. !QChar::isPrint()) This is what I've done, except that I used ctype.h's isprint(), under the C locale. I considered using QChar::isPrint here, but it would be very expensive and it would not solve the homograph and ambiguity problem anyway. Better to just do nothing than use QChar::isPrint. QChar::isPrint() is not that expensive, and this is about debug output. Your code escaping all these chars is a more expensive if it gets hit. And I don't see how homographs are a problem for debug output. Unless you're debugging certain rather special cases in which case you should be able to turn full escaping on. I would guess that 98% of our users are using qDebug differently than you are. * We add a flag that would give fully quoted strings so you can get a quoted version if required (e.g. qDebug() quoteStrings) I'm ok with a flag, as long as it's the default. Well, having to turn this on on every qDebug() line is a major issue for large existing code bases. You can say that this was never really supported by qDebug, but in practice, it worked on Windows, any modern Linux, Mac OS X (and I'd assume also iOS and Android). So people were using it. Suddenly breaking it is a major issue for anybody developing programs in non ascii (esp non latin) languages and trying to debug these. Just think of the use case of trying to figure out what a string contains at a certain point in your program. If the output is human readable it's immediately obvious. If I just get escaped data, I need to spend lots of time figuring it out. So IMO the default behaviour should be to show unicode strings in a form that is readable but at the same time doesn't hide things like zero width spaces (ie. It should escape non printable chars). Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
On 27/07/15 18:52, development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of thiago.macie...@intel.com wrote: On Monday 27 July 2015 19:49:15 NIkolai Marchenko wrote: If we are to believe Thiago, every developer that needs to see trace information from an old code, now needs to edit all of his qDebug()'ed instances to use qPrintable. Yes, all of them. However much there is, manually, one by one. You need to qualify this as every developer who wants to see the string printed without the quotes and escaping. This reduces your every developer to maybe 5% of them, probably less. I think you underestimate this. We have a huge amount of developers in non latin countries and for everybody doing development in these countries this is a very common problem. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 16:57:23 Knoll Lars wrote: On 27/07/15 18:52, development-bounces+lars.knoll=theqtcompany.com@qt- project.org on behalf of Thiago Macieira development- bounces+lars.knoll=theqtcompany@qt-project.org on behalf of thiago.macie...@intel.com wrote: On Monday 27 July 2015 19:49:15 NIkolai Marchenko wrote: If we are to believe Thiago, every developer that needs to see trace information from an old code, now needs to edit all of his qDebug()'ed instances to use qPrintable. Yes, all of them. However much there is, manually, one by one. You need to qualify this as every developer who wants to see the string printed without the quotes and escaping. This reduces your every developer to maybe 5% of them, probably less. I think you underestimate this. We have a huge amount of developers in non latin countries and for everybody doing development in these countries this is a very common problem. I'm not thinking of people's languages. I'm thinking of the intent to read the string in the output, as opposed to inspecting it for why it contains the content it contains. The whole thinking is that the use of operator for QString implies you're trying to figure out why that string is the way it is, as opposed to trying to convey a message. If you wanted the latter case, you'd have used operator for const char*, which wasn't affected. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
The problem with your approach to qDebug is that it only works well where most of the text is in English and only individual letters are unicode. Once we venture into the territory of debugging 50%+ non-latin, it will be impossible to extract any useful information from debug output at a glance. 2015-07-27 20:25 GMT+03:00 Thiago Macieira thiago.macie...@intel.com: On Monday 27 July 2015 09:05:29 Thiago Macieira wrote: а, which was the attack vector for homograph sites like pаypal.com or pаypаl.com or раураl.com or other permutations of the letters. A control Question: which of the three is the legit website? And what method did you use to find out? The following is an excerpt from the Japanese Wikipedia homepage just so that KMail will encode the email in Base64 instead of quoted-printable: 1988年10月に競走馬としてデビュー。翌1989年にアメリカ三冠のうち二冠（ケンタッキーダービー、プリークネスステークス）、さらにブリーダーズカップ・クラ シックを勝つなどG1を5勝する活躍を見せ、エクリプス賞年度代表馬に選ばれた。1990年に右前脚の靭帯を痛めて競走馬を引退。引退後は日本で種牡馬となり、初年度 産駒がデビューした翌年の1995年から13年連続で日本のリーディングサイアーを獲得。さらに中央競馬における種牡馬にまつわる記録を次々と更新した。サンデーサイ レンスを起点とするサイアーラインは日本競馬界における一大勢力となり、サンデーサイレンス系とも呼ばれる。幼少期は見栄えのしない容貌ゆえに買い手がつかず、生命に かかわる事態に見舞われながら競走馬、さらに種牡馬として成功した生涯は童話『みにくいアヒルの子』に例えられる。 PS: if you've answered that you opened in the web browser, please send me your credit card number so I can credit you for $5. You may also want to talk to this prince who came into a fortune recently -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 19:49:15 NIkolai Marchenko wrote: If we are to believe Thiago, every developer that needs to see trace information from an old code, now needs to edit all of his qDebug()'ed instances to use qPrintable. Yes, all of them. However much there is, manually, one by one. You need to qualify this as every developer who wants to see the string printed without the quotes and escaping. This reduces your every developer to maybe 5% of them, probably less. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
Question, how much do you think this use case happens for non-latin users compared to the one I, and Knoll Lars are arguing about? 2015-07-27 20:25 GMT+03:00 Thiago Macieira thiago.macie...@intel.com: On Monday 27 July 2015 09:05:29 Thiago Macieira wrote: а, which was the attack vector for homograph sites like pаypal.com or pаypаl.com or раураl.com or other permutations of the letters. A control Question: which of the three is the legit website? And what method did you use to find out? The following is an excerpt from the Japanese Wikipedia homepage just so that KMail will encode the email in Base64 instead of quoted-printable: 1988年10月に競走馬としてデビュー。翌1989年にアメリカ三冠のうち二冠（ケンタッキーダービー、プリークネスステークス）、さらにブリーダーズカップ・クラ シックを勝つなどG1を5勝する活躍を見せ、エクリプス賞年度代表馬に選ばれた。1990年に右前脚の靭帯を痛めて競走馬を引退。引退後は日本で種牡馬となり、初年度 産駒がデビューした翌年の1995年から13年連続で日本のリーディングサイアーを獲得。さらに中央競馬における種牡馬にまつわる記録を次々と更新した。サンデーサイ レンスを起点とするサイアーラインは日本競馬界における一大勢力となり、サンデーサイレンス系とも呼ばれる。幼少期は見栄えのしない容貌ゆえに買い手がつかず、生命に かかわる事態に見舞われながら競走馬、さらに種牡馬として成功した生涯は童話『みにくいアヒルの子』に例えられる。 PS: if you've answered that you opened in the web browser, please send me your credit card number so I can credit you for $5. You may also want to talk to this prince who came into a fortune recently -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
I'm ok with a flag, as long as it's the default. I am ok with a flag too. As long as escaping can be turned off, preferably in one place instead of editing qDebug()'s everywhere it is ok. I am so vehemently against the change as it is now primarily because it a) cannot be contained in a simple #ifdef block b) getting the old behaviour back requires using noquote everywhere which breaks the code if you need to build it with earlier qt version On Mon, Jul 27, 2015 at 7:13 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Monday 27 July 2015 08:44:30 Knoll Lars wrote: I can understand the issues that non latin speakers are facing with this well. I’ve often used qDebug() to debug non latin use cases, and in 90% of the cases I just want to know what the string reads. The unicode content of it is interesting to me in only 10% of the cases. For most users not debugging Qt’s internals I would assume that ratio to be more like 99 to 1. As I said in my email, the problem is that you will not turn this on for those 10% of the cases until you've already lost data, either visibly or really. I'm counting ambiguity and homographs as apparent data loss because it will send you down the wrong debugging path. Thiago, which backends can’t handle utf8 or utf16 output these days? Android log, slog2, syslog and the regular stderr output if the system locale isn't UTF-8. In particular, on Windows the system locale is never UTF-8 unless you're using Vietnamese Windows. On the other hand, the OS X system locale is always UTF-8 unless you've messed up, including with setCodecForLocale. Or, if I list those that always do: WIndows OutputDebugString and journald. None of those are binary-safe, which means they will not work with a QString containing a NUL character. One idea could be a slightly modified approach that is more compatible: * We always encode QStrings as utf8 (maybe utf16 for the windows console) when sending them to qDebug() That would change behaviour for people with non-UTF-8 systems, as they'd now see mojibake. * We quote every character that is not printable (ie. !QChar::isPrint()) This is what I've done, except that I used ctype.h's isprint(), under the C locale. I considered using QChar::isPrint here, but it would be very expensive and it would not solve the homograph and ambiguity problem anyway. Better to just do nothing than use QChar::isPrint. * We add a flag that would give fully quoted strings so you can get a quoted version if required (e.g. qDebug() quoteStrings) I'm ok with a flag, as long as it's the default. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
Not to mention, this is cumbersome to the extreme. On Mon, Jul 27, 2015 at 7:26 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Monday 27 July 2015 19:20:34 NIkolai Marchenko wrote: b) getting the old behaviour back requires using noquote everywhere which breaks the code if you need to build it with earlier qt version Or just use qPrintable() around your strings. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 09:05:29 Thiago Macieira wrote: а, which was the attack vector for homograph sites like pаypal.com or pаypаl.com or раураl.com or other permutations of the letters. A control Question: which of the three is the legit website? And what method did you use to find out? The following is an excerpt from the Japanese Wikipedia homepage just so that KMail will encode the email in Base64 instead of quoted-printable: 1988年10月に競走馬としてデビュー。翌1989年にアメリカ三冠のうち二冠（ケンタッキーダービー、プリークネスステークス）、さらにブリーダーズカップ・クラ シックを勝つなどG1を5勝する活躍を見せ、エクリプス賞年度代表馬に選ばれた。1990年に右前脚の靭帯を痛めて競走馬を引退。引退後は日本で種牡馬となり、初年度 産駒がデビューした翌年の1995年から13年連続で日本のリーディングサイアーを獲得。さらに中央競馬における種牡馬にまつわる記録を次々と更新した。サンデーサイ レンスを起点とするサイアーラインは日本競馬界における一大勢力となり、サンデーサイレンス系とも呼ばれる。幼少期は見栄えのしない容貌ゆえに買い手がつかず、生命に かかわる事態に見舞われながら競走馬、さらに種牡馬として成功した生涯は童話『みにくいアヒルの子』に例えられる。 PS: if you've answered that you opened in the web browser, please send me your credit card number so I can credit you for $5. You may also want to talk to this prince who came into a fortune recently -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
Let's make it harder, can you guesss that it even is a link to paypal website with qDebug() as you intend it to work without copypasting? раураl.соm ? Hint: only 2 letters here are in english. 2015-07-27 20:25 GMT+03:00 Thiago Macieira thiago.macie...@intel.com: On Monday 27 July 2015 09:05:29 Thiago Macieira wrote: а, which was the attack vector for homograph sites like pаypal.com or pаypаl.com or раураl.com or other permutations of the letters. A control Question: which of the three is the legit website? And what method did you use to find out? The following is an excerpt from the Japanese Wikipedia homepage just so that KMail will encode the email in Base64 instead of quoted-printable: 1988年10月に競走馬としてデビュー。翌1989年にアメリカ三冠のうち二冠（ケンタッキーダービー、プリークネスステークス）、さらにブリーダーズカップ・クラ シックを勝つなどG1を5勝する活躍を見せ、エクリプス賞年度代表馬に選ばれた。1990年に右前脚の靭帯を痛めて競走馬を引退。引退後は日本で種牡馬となり、初年度 産駒がデビューした翌年の1995年から13年連続で日本のリーディングサイアーを獲得。さらに中央競馬における種牡馬にまつわる記録を次々と更新した。サンデーサイ レンスを起点とするサイアーラインは日本競馬界における一大勢力となり、サンデーサイレンス系とも呼ばれる。幼少期は見栄えのしない容貌ゆえに買い手がつかず、生命に かかわる事態に見舞われながら競走馬、さらに種牡馬として成功した生涯は童話『みにくいアヒルの子』に例えられる。 PS: if you've answered that you opened in the web browser, please send me your credit card number so I can credit you for $5. You may also want to talk to this prince who came into a fortune recently -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
Once we venture into the territory of debugging 50%+ non-latin, it will be impossible to extract any useful information from debug output at a glance. And that is the situation, where aforementioned flag to change the behaviour in one place will be VERY useful. Unlike your suggestion of fixing source code everywhere line by line. And users genrally know if they need to consider the case you are arguing about or not. On Mon, Jul 27, 2015 at 8:58 PM, NIkolai Marchenko enmarantis...@gmail.com wrote: The problem with your approach to qDebug is that it only works well where most of the text is in English and only individual letters are unicode. Once we venture into the territory of debugging 50%+ non-latin, it will be impossible to extract any useful information from debug output at a glance. 2015-07-27 20:25 GMT+03:00 Thiago Macieira thiago.macie...@intel.com: On Monday 27 July 2015 09:05:29 Thiago Macieira wrote: а, which was the attack vector for homograph sites like pаypal.com or pаypаl.com or раураl.com or other permutations of the letters. A control Question: which of the three is the legit website? And what method did you use to find out? The following is an excerpt from the Japanese Wikipedia homepage just so that KMail will encode the email in Base64 instead of quoted-printable: 1988年10月に競走馬としてデビュー。翌1989年にアメリカ三冠のうち二冠（ケンタッキーダービー、プリークネスステークス）、さらにブリーダーズカップ・クラ シックを勝つなどG1を5勝する活躍を見せ、エクリプス賞年度代表馬に選ばれた。1990年に右前脚の靭帯を痛めて競走馬を引退。引退後は日本で種牡馬となり、初年度 産駒がデビューした翌年の1995年から13年連続で日本のリーディングサイアーを獲得。さらに中央競馬における種牡馬にまつわる記録を次々と更新した。サンデーサイ レンスを起点とするサイアーラインは日本競馬界における一大勢力となり、サンデーサイレンス系とも呼ばれる。幼少期は見栄えのしない容貌ゆえに買い手がつかず、生命に かかわる事態に見舞われながら競走馬、さらに種牡馬として成功した生涯は童話『みにくいアヒルの子』に例えられる。 PS: if you've answered that you opened in the web browser, please send me your credit card number so I can credit you for $5. You may also want to talk to this prince who came into a fortune recently -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
27.07.2015, 11:01, "NIkolai Marchenko" enmarantis...@gmail.com: Once we venture into the territory of debugging 50%+ non-latin, it will be impossible to extract any useful information from debug output at a glance. And that is the situation, where aforementioned flag to change the behaviour in one place will be VERY useful. Unlike your suggestion of fixing source code everywhere line by line.And users genrally know if they need to consider the case you are arguing about or not. qDebug is just a macro so you may override it:#define qDebug() qDebug() unescape It's a bit more tricky if you use it as both function and output stream, but it's still solvable by single header include. P.S. As a Russian speaker I prefer Thiago's solution, I've faced numerous times with ambiguous output of qDebug and even 'a' vs 'а' problem (which led to lots of text.toHex()) and I'm happy that it's finally solved. On Mon, Jul 27, 2015 at 8:58 PM, NIkolai Marchenko enmarantis...@gmail.com wrote:The problem with your approach to qDebug is that it only works well where most of the text is in English and only individual letters are unicode. Once we venture into the territory of debugging 50%+ non-latin, it will be impossible to extract any useful information from debug output at a glance.2015-07-27 20:25 GMT+03:00 Thiago Macieira thiago.macie...@intel.com:On Monday 27 July 2015 09:05:29 Thiago Macieira wrote: "а", which was the attack vector for homograph sites like pаypal.com or pаypаl.com or раураl.com or other permutations of the letters. A control Question: which of the three is the legit website? And what method did you use to find out?The following is an excerpt from the Japanese Wikipedia homepage just so that KMail will encode the email in Base64 instead of quoted-printable: 1988年10月に競走馬としてデビュー。翌1989年にアメリカ三冠のうち二冠（ケンタッキーダービー、プリークネスステークス）、さらにブリーダーズカップ・クラ シックを勝つなどG1を5勝する活躍を見せ、エクリプス賞年度代表馬に選ばれた。1990年に右前脚の靭帯を痛めて競走馬を引退。引退後は日本で種牡馬となり、初年度 産駒がデビューした翌年の1995年から13年連続で日本のリーディングサイアーを獲得。さらに中央競馬における種牡馬にまつわる記録を次々と更新した。サンデーサイ レンスを起点とするサイアーラインは日本競馬界における一大勢力となり、サンデーサイレンス系とも呼ばれる。幼少期は見栄えのしない容貌ゆえに買い手がつかず、生命に かかわる事態に見舞われながら競走馬、さらに種牡馬として成功した生涯は童話『みにくいアヒルの子』に例えられる。PS: if you've answered that you opened in the web browser, please send me your credit card number so I can credit you for $5. You may also want to talk to this prince who came into a fortune recently -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ,___Development mailing listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development --Ruslan Nigmatullin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 21:41:44 NIkolai Marchenko wrote: Yes,but this requires making override visible in every file of the project. We can solve this by having a global #ifdef that can change the setting. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
\u0440\u0430\u0443\u0440\u0430l.\u0441\u043em Can you really tell at a glance what exactly you are looking at here without consulting the oracle or, at least, reencoding it to readable format? On Mon, Jul 27, 2015 at 9:22 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Monday 27 July 2015 20:52:24 NIkolai Marchenko wrote: Let's make it harder, can you guesss that it even is a link to paypal website with qDebug() as you intend it to work without copypasting? раураl.соm ? Hint: only 2 letters here are in english. With qDebug() as it is in Qt 5.5, it would be quite evident. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 21:27:23 NIkolai Marchenko wrote: \u0440\u0430\u0443\u0440\u0430l.\u0441\u043em Oh, really? Note, I said, without copypasting to uncode converter. It's quite evident it's not a link to paypal.com because I can't see paypal there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
Oh, but now you KNOW that it is a misspeled link to paypal. In real situation you won't have this forward knowlegde. On Mon, Jul 27, 2015 at 9:43 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Monday 27 July 2015 21:27:23 NIkolai Marchenko wrote: \u0440\u0430\u0443\u0440\u0430l.\u0441\u043em Oh, really? Note, I said, without copypasting to uncode converter. It's quite evident it's not a link to paypal.com because I can't see paypal there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
Giuseppe D'Angelo wrote: Also nobody says that middle insertions of removals should be extra cheap. This is a very common operation for a random-access, ordered but not auto- sorted, array/vector-type list. The array of pointers data structure is an effective compromise to make this reasonably cheap (though still O(n)) while keeping the O(1) random access. * Accessing the i-th element is performed in guaranteed O(1) time. For bad types for QList, that O(1) is hiding two indirections. Only one with QVector. That's a huge cost you're not talking about. It's a factor 2, vs. a factor sizeof(T)/sizeof(T*) in the opposite direction for the middle insertions/removals. For any nontrivial class, sizeof(T)/sizeof(T*) can be a lot larger than 2. * Inserting an element performs at most 1 heap allocation. (This is the only performance metric that can change, but the changing from the usual 1 to 0 is a very welcome optimization for the cases it applies to.) Inserting an element of a wrong type performs *at least* 1 heap allocation. Consider: ListContainerWrongType list; list.reserve(1000); /* insert 1000 elements */ This performs (at least?) 1001 heap allocations with QList and 1 with QVector. This performs only 1 allocation with QList. The documentation says: Note that the reservation applies only to the internal pointer array. Looking at the code, the reserved pointers are simply not initialized at all (not even zeroed). The actual 1000 allocations of the WrongType elements are only done if and when you actually insert them. Therefore, you get the behavior I explained: insert does 1 allocation for a wrong type (or 2 in the rare event it needs to grow the pointer array), 0 for a good type (or 1 in the rare event it needs to grow the array). The latter matching the behavior of QVector, of course. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
On 27 Jul 2015, at 21:14, Thiago Macieira thiago.macie...@intel.com wrote: On Monday 27 July 2015 21:50:15 NIkolai Marchenko wrote: Oh, but now you KNOW that it is a misspeled link to paypal. In real situation you won't have this forward knowlegde. The point is that I have all of the information I need. If I see a debug output saying: ClassName::openLink: trying to open \u0440\u0430\u0443\u0440\u0430l. \u0441\u043em Thiago what was the original cause for the change? Shouldn’t a change like this be argued in, rather than out? Andreas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
Yes,but this requires making override visible in every file of the project. On Mon, Jul 27, 2015 at 9:34 PM, Ruslan Nigmatullin euroeles...@yandex.ru wrote: 27.07.2015, 11:01, NIkolai Marchenko enmarantis...@gmail.com: Once we venture into the territory of debugging 50%+ non-latin, it will be impossible to extract any useful information from debug output at a glance. And that is the situation, where aforementioned flag to change the behaviour in one place will be VERY useful. Unlike your suggestion of fixing source code everywhere line by line. And users genrally know if they need to consider the case you are arguing about or not. qDebug is just a macro so you may override it: #define qDebug() qDebug() unescape It's a bit more tricky if you use it as both function and output stream, but it's still solvable by single header include. P.S. As a Russian speaker I prefer Thiago's solution, I've faced numerous times with ambiguous output of qDebug and even 'a' vs 'а' problem (which led to lots of text.toHex()) and I'm happy that it's finally solved. On Mon, Jul 27, 2015 at 8:58 PM, NIkolai Marchenko enmarantis...@gmail.com wrote: The problem with your approach to qDebug is that it only works well where most of the text is in English and only individual letters are unicode. Once we venture into the territory of debugging 50%+ non-latin, it will be impossible to extract any useful information from debug output at a glance. 2015-07-27 20:25 GMT+03:00 Thiago Macieira thiago.macie...@intel.com: On Monday 27 July 2015 09:05:29 Thiago Macieira wrote: а, which was the attack vector for homograph sites like pаypal.com or pаypаl.com or раураl.com or other permutations of the letters. A control Question: which of the three is the legit website? And what method did you use to find out? The following is an excerpt from the Japanese Wikipedia homepage just so that KMail will encode the email in Base64 instead of quoted-printable: 1988年10月に競走馬としてデビュー。翌1989年にアメリカ三冠のうち二冠（ケンタッキーダービー、プリークネスステークス）、さらにブリーダーズカップ・クラ シックを勝つなどG1を5勝する活躍を見せ、エクリプス賞年度代表馬に選ばれた。1990年に右前脚の靭帯を痛めて競走馬を引退。引退後は日本で種牡馬となり、初年度 産駒がデビューした翌年の1995年から13年連続で日本のリーディングサイアーを獲得。さらに中央競馬における種牡馬にまつわる記録を次々と更新した。サンデーサイ レンスを起点とするサイアーラインは日本競馬界における一大勢力となり、サンデーサイレンス系とも呼ばれる。幼少期は見栄えのしない容貌ゆえに買い手がつかず、生命に かかわる事態に見舞われながら競走馬、さらに種牡馬として成功した生涯は童話『みにくいアヒルの子』に例えられる。 PS: if you've answered that you opened in the web browser, please send me your credit card number so I can credit you for $5. You may also want to talk to this prince who came into a fortune recently -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development , ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Ruslan Nigmatullin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 21:50:15 NIkolai Marchenko wrote: Oh, but now you KNOW that it is a misspeled link to paypal. In real situation you won't have this forward knowlegde. The point is that I have all of the information I need. If I see a debug output saying: ClassName::openLink: trying to open \u0440\u0430\u0443\u0440\u0430l. \u0441\u043em I would know to inspect why that is an unexpected URL. Also note how QUrl would also mangle it and would show: QUrl( xn--l-7sba6dbr.xn--m-0tbi ) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
\u0440\u0430\u0443\u0440\u0430l.\u0441\u043em Oh, really? Note, I said, without copypasting to uncode converter. On Mon, Jul 27, 2015 at 9:22 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Monday 27 July 2015 20:52:24 NIkolai Marchenko wrote: Let's make it harder, can you guesss that it even is a link to paypal website with qDebug() as you intend it to work without copypasting? раураl.соm ? Hint: only 2 letters here are in english. With qDebug() as it is in Qt 5.5, it would be quite evident. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
On Monday 27 July 2015 21:44:32 Kevin Kofler wrote: For bad types for QList, that O(1) is hiding two indirections. Only one with QVector. That's a huge cost you're not talking about. It's a factor 2, vs. a factor sizeof(T)/sizeof(T*) in the opposite direction for the middle insertions/removals. For any nontrivial class, sizeof(T)/sizeof(T*) can be a lot larger than 2. You're comparing apples and oranges here. The total memory allocated for QList is always equal to or bigger than QVector for the same size, regardless of T. So in addition to having the same memory size, you access the data through one extra indirection. The only benefit QList has is that it's really quick to resize and insert at any point compared to a QVector of a complex or large type. QListT and QVectorT allocate the same amount of memory if sizeof(T) == sizeof(T*) and T is movable. QVectorT allocates less memory if: - sizeof(T) sizeof(T*) and T is movable - sizeof(T) = sizeof(T*) - T is not movable In the first case, QVector allocates n * sizeof(T) and QList allocates n * sizeof(T*). In the latter two cases, , then QList allocates n * (sizeof(T) + sizeof(T*)) while QVector allocates n * sizeof(T) And this is not including the memory overhead of malloc, which is 16 bytes on 64-bit systems. QVector does exactly one malloc, whereas QList for the non- movable case will do n + 1, which increases the memory consumption by 16 * n bytes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replace QtXml backend
On 7/27/2015 11:21 PM, Cristian Adam wrote: On Mon, Jul 27, 2015 at 9:58 AM, Gerhard Scheikl g.sche...@avibit.com wrote: I didn't fully think it through yet, was just an idea. :) So we came up with the idea to replace the back-end with Xerces and try to leave the Qt API part the same. That's interesting. On Mon, Jul 27, 2015 at 6:03 PM, Thiago Macieira thiago.macie...@intel.com mailto:thiago.macie...@intel.com wrote: On Monday 27 July 2015 09:58:42 Gerhard Scheikl wrote: How is it licensed? Apache 2.0 This is a deal-breaker. Gerhard, have you also tested libxml2 https://en.wikipedia.org/wiki/Libxml2? Unlike Xerces, libxml2 is MIT licensed. Cheers, Cristian. libxml2 and libxlt are already part of the Qt source tree, part of QtWebEngine-chromium http://code.qt.io/cgit/qt/qtwebengine-chromium.git/tree/chromium/third_party/libxml http://code.qt.io/cgit/qt/qtwebengine-chromium.git/tree/chromium/third_party/libxslt Reusing libxml2 and libxlt should actually cause code decrease. Cheers, Cristian. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 22:01:26 Andreas Aardal Hanssen wrote: On 27 Jul 2015, at 21:14, Thiago Macieira thiago.macie...@intel.com wrote: On Monday 27 July 2015 21:50:15 NIkolai Marchenko wrote: Oh, but now you KNOW that it is a misspeled link to paypal. In real situation you won't have this forward knowlegde. The point is that I have all of the information I need. If I see a debug output saying: ClassName::openLink: trying to open \u0440\u0430\u0443\u0440\u0430l. \u0441\u043em Thiago what was the original cause for the change? Shouldn’t a change like this be argued in, rather than out? It was argued for and approved by the reviewers. It did not seem such a big deal, which is why it wasn't brought up to the list. Now we need to decide whether to go back, continue or change again. The whole story is as follows: For Qt 5.4, I changed QtTest printing of QStrings. See 579526cfec082679241548a0fca1ff9ba2c350a7: Make the printing of complex Unicode in a QString prettier This also has the advantage of not requiring the use of the locale codec. Quite an advantage if you're debugging the locale codec. But it's mostly so that we don't get question marks that hide the difference we were trying to locate. [ChangeLog][QtTest] QtTest now prints an escaped version of QStrings that failed to compare with QCOMPARE. That is, instead of converting non-printable characters to question marks, QtTest will print the Unicode representation of the character in question. This was a net benefit because, like the commit message says, it avoided the conversion from non-ASCII to question marks, which often hid the exact character you were trying to compare. I had a corresponding change for QByteArray, but it did not integrate in time for 5.4 branching, so landed in 5.5 as f5b609cac864e010085d5965b84832b2d85643e6 Make the printing of complex byte arrays prettier Similar to what we've done to QString, only we print each byte that is not ASCII as \OOO (octal representation). [ChangeLog][QtTest] QtTest now prints an escaped version of QByteArrays that failed to compare with QCOMPARE, instead of the hex dump. This was again a net benefit because the common case of QByteArray is to contain an arbitrarily-encoded human text. After I'd done that, we decided that we'd actually do the same for QDebug as it's used in often the same situations as QtTest. Also note that we changed from octal to hex at Ossi's insistence, which made the code a more complex in the process. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replace QtXml backend
On Mon, Jul 27, 2015 at 9:58 AM, Gerhard Scheikl g.sche...@avibit.com mailto:g.sche...@avibit.com wrote: I didn't fully think it through yet, was just an idea. :) So we came up with the idea to replace the back-end with Xerces and try to leave the Qt API part the same. That's interesting. On Mon, Jul 27, 2015 at 6:03 PM, Thiago Macieira thiago.macie...@intel.com mailto:thiago.macie...@intel.com wrote: On Monday 27 July 2015 09:58:42 Gerhard Scheikl wrote: How is it licensed? Apache 2.0 This is a deal-breaker. Gerhard, have you also tested libxml2 https://en.wikipedia.org/wiki/Libxml2? Unlike Xerces, libxml2 is MIT licensed. Cheers, Cristian. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
Thiago Macieira wrote: The total memory allocated for QList is always equal to or bigger than QVector for the same size, regardless of T. So in addition to having the same memory size, you access the data through one extra indirection. I was talking about speed, not memory consumption. The only benefit QList has is that it's really quick to resize and insert at any point compared to a QVector of a complex or large type. That was my point (especially the insert at any point case). (And you forgot remove at any point, which is like insert at any point except for moving in the other direction.) The speed difference can be arbitrarily large. Even infinite if the type is not movable and the copy constructor or the destructor does not halt. ;-) Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replace QtXml backend
On Monday 27 July 2015 23:43:06 Cristian Adam wrote: libxml2 and libxlt are already part of the Qt source tree, part of QtWebEngine-chromium http://code.qt.io/cgit/qt/qtwebengine-chromium.git/tree/chromium/third_party /libxml http://code.qt.io/cgit/qt/qtwebengine-chromium.git/tree/chromium/third_part y/libxslt Reusing libxml2 and libxlt should actually cause code decrease. Huh... not really :-) It would cause a minimal decrease for anyone using qtwebengine, but it would increase the code size for everyone who isn't. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replace QtXml backend
On Monday 27 July 2015 16:25:10 Thiago Macieira wrote: Reusing libxml2 and libxlt should actually cause code decrease. Huh... not really It would cause a minimal decrease for anyone using qtwebengine, but it would increase the code size for everyone who isn't. Remember that every shared library loaded at runtime implies an additional minimum of 4 kB of non-sharable, faulted in and dirty memory. libxml2 has a RW segment of 0xa6f8 bytes, while libxslt has 0x1620 bytes. Since those segments are not aligned at page boundaries, that means libxslt occupies 8 kB and libxml2 16 kB -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On Tuesday 28 July 2015 06:19:03 Andre Somers wrote: The section 2 says grants the Foundation [...] the right and license, to use, copy, duplicate [...] any and all existing and future Qt Free Edition releases ... So, the foundation has the right, but not the obligation to do so. So they probably will, but that's not an automatic given. Thanks for the link and quote. Well, the passage is legalese for saying that the Foundation gets all rights to the source code. What the Foundation does with the source code is its own decision. It can: a) do nothing and let the code die b) release it to an open source project under BSD licence c) ditto, but using LGPL d) give it to a company to commercialise it under the dual licensing scheme again e) something else, but the options b, c,and d are the most likely ones The important thing to note is that the source code reverting to the Foundation does not imply neither the end of either the open source project nor the end of commercial licensing. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
Hi Thiago, 2015-07-28 1:34 GMT+09:00 Thiago Macieira thiago.macie...@intel.com: On Monday 27 July 2015 19:27:44 NIkolai Marchenko wrote: Or just use qPrintable() around your strings. you do realize, that it will require editing thousands of instances of qDebug in the old code? Yes. grepped QDebug\s*?operator\s*\\(QDebug under qtbase/src, and checked if QDebug operator(QDebug, const QString) is used in it for strings that can be utf8 very roughly. Do we fix those functions? QtCore: QDebug operator(QDebug debug, const QDir dir) QDebug operator(QDebug, const QJsonValue ) QDebug operator(QDebug, const QVariant ) QtSql: QDebug operator(QDebug dbg, const QSqlDatabase d) QDebug operator(QDebug dbg, const QSqlError s) QDebug operator(QDebug dbg, const QSqlField f) QDebug operator(QDebug dbg, const QSqlRecord r) QtGui: QDebug operator(QDebug d, const QAccessibleInterface *iface) QDebug operator(QDebug stream, const QFont font) QDebug operator(QDebug dbg, const QPageSize pageSize) QtDBus: QDebug operator(QDebug, const QDBusError ) Qt itself uses QDebug operator(QDebug, const QString) to get warning messages useful. e.g. http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qiodevice.cpp#n83 Do we apply qPrintable() everywhere in Qt? Will it be possible to apply qPrintable() to QString in containers? Best Regards, -- Tasuku Suzuki ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5
On 27-7-2015 18:13, Thiago Macieira wrote: On Monday 27 July 2015 08:44:30 Knoll Lars wrote: I can understand the issues that non latin speakers are facing with this well. I’ve often used qDebug() to debug non latin use cases, and in 90% of the cases I just want to know what the string reads. The unicode content of it is interesting to me in only 10% of the cases. For most users not debugging Qt’s internals I would assume that ratio to be more like 99 to 1. As I said in my email, the problem is that you will not turn this on for those 10% of the cases until you've already lost data, either visibly or really. I'm counting ambiguity and homographs as apparent data loss because it will send you down the wrong debugging path. In that case, I think your solution _causes_ data loss when debugging path-related issues in Windows. If paths get their separators doubled all of a sudden, then that is certainly going to send people down the wrong debugging track. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
On 27-7-2015 18:21, Thiago Macieira wrote: On Monday 27 July 2015 08:01:53 André Somers wrote: I am not a lawer and I don't know the wording of the KDE Free Qt Foundation agreement, but are you sure that in case that agreement is triggered the verion you branched off off will fall under that licence and be the one that will be released under BSD? I'm just wondering if all versions would retroactively be relicenced or just the current code... _If_ it is the latter, you have a problem in your CLA, as you may not have the right to do the BSD relicencing you promissed seeing that you forked Qt 4 and not 5... https://www.kde.org/community/whatiskde/images/nokia-agreement-3.jpg The section 2 says grants the Foundation [...] the right and license, to use, copy, duplicate [...] any and all existing and future Qt Free Edition releases ... So, the foundation has the right, but not the obligation to do so. So they probably will, but that's not an automatic given. Thanks for the link and quote. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
Op 27-7-2015 om 03:47 schreef Ansel Sermersheim: On 7/26/15 3:01 PM, Kevin Kofler wrote: Ansel Sermersheim wrote: We do in fact have a CLA in place. However, our CLA has one single purpose. In the event that Qt is re-licensed under a BSD style license (whether due to the KDE Free Qt Foundation or some other reason), we will re-license CopperSpice under that same license. That is the only permission we ask from contributors. That in turn allows everyone else, or even you, to take the code proprietary, so in the case this clause is triggered (which depends on Qt, i.e., neither on you nor on the contributor), it is functionally equivalent to a CLA allowing proprietary relicensing. There is one fundamental difference between the CopperSpice and Qt licensing situation. In the (unlikely) event that CopperSpice becomes BSD licensed, it becomes BSD licensed for everyone. This means anyone, anywhere, has equal rights to make changes and profit from them. This is very different from one particular entity owning the right to profit from an open source project. The argument between GPL-style vs BSD-style licenses is as old as the hills, but both licenses do treat all contributors equally. Ansel Sermersheim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development I am not a lawer and I don't know the wording of the KDE Free Qt Foundation agreement, but are you sure that in case that agreement is triggered the verion you branched off off will fall under that licence and be the one that will be released under BSD? I'm just wondering if all versions would retroactively be relicenced or just the current code... _If_ it is the latter, you have a problem in your CLA, as you may not have the right to do the BSD relicencing you promissed seeing that you forked Qt 4 and not 5... André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replace QtXml backend
On Friday 24 July 2015 08:50:07 Thiago Macieira wrote: On Friday 24 July 2015 15:26:30 Gerhard Scheikl wrote: Hello Gerhard Your question is answered mostly by your paragraph above: QtXml is in Done state, so we really don't want to do major surgery in it, which could open the door up for subtle incompatibilities. I'm not even talking about introducing bugs that aren't there. That's sure a concern. But even if you do your best, you may *fix* bugs that people are accidentally depending on; or the simple fact of a change in behaviour could result in existing code getting broken. Are you prepared to accept all of those reports and react to them? Hi I didn't fully think it through yet, was just an idea. :) So we came up with the idea to replace the back-end with Xerces and try to leave the Qt API part the same. That's interesting. How big is Xerces? Around 260k LOC. How easy is it to build? ./configure make make install How is it licensed? Apache 2.0 If we succeed, we would like to give this code back to the community and replace the current QtXml classes. Do you include accepting maintainership of the module and reacting to bug reports in give this code back to the community? We're all for new and improved code, but when it comes with a large maintenance burden, we have to analyse whether it's worth the hassle. We have to maintain our code anyway. We definitely need to create a library that allows us to bring fast and working XML processing to our Qt backend. Even better if we get external bug reports. Maybe creating a 3rd party library would be the better choice. Maybe creating something like QtXml2 would be an option. What do you think? Could we arrange a conference call to talk about options? Thanks! Best regards, Gerhard ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
On Monday 27 July 2015 00:27:18 Kevin Kofler wrote: It doesn't switch the stuff it actually guarantees: That sentence is perfectly correct. But here's the catch: The docs guarantee _a certain implementation_, incl. the switching. The problem is that the conditions under which the switch occurs are quite hard for non-experts to check. This is the beauty of the STL: without mentioning the actual implementation anywhere, its containers have such tailor-made guarantees that effectively only one implementation possibility is left (they even rule out CoW without mentioning it!). But since the STL doesn't specify any implementation, if research finds a data structure that meets those guarantees, the new structure automatically becomes permissible. This is what made std::make_shared's optimisation possible, e.g. Qt containers are not like that. QList docs say exactly how it's implemented, but not exactly what it guarantees. Thus, coming to depend on details of the implementation is a perfectly reasonable thing to do for a developer. It's documented, after all, if only indirectly. Quite some code in QtBase alone already depends on the de-facto guarantee of stable references, among them, just off the top of my head: - QDataWidgetMapper - QToolBox - one of the lists in QMime* - QListQMakeLocalFileName in qmake Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backwards compatibiltiy break in Qt 5.5
On Monday 27 July 2015 00:25:18 NIkolai Marchenko wrote: (I am not entirely sure why I haven't received at least a notification of why this post has not appeared the first time I tried to send it, so here we go again. Btw, it was Thiago Macieira himself who actually suggested I mail this list) Hi! We (Russian Qt community) have a situation we could not resolve with Thiago Macieira in bug tracker, so have to ask for Chief Maintainer's attention. The bug in question is there: https://bugreports.qt.io/browse/QTBUG-47316 In version 5.5 Thiago Macieira introduced a compatibility break with older qt versions. This break has come in the form of completely changing the way qDebug() prints non-english characters to console. I don't think qDebug() should guarantee any output, but your position might become a relevant one if logging output also changed. That is something that we shoudn't change, and since IIIRC, qDebug and logging use the same stream, you may have a point here. Just my 2ct, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
I guess we could add some output to your container benchmark app that explains what your QListT will actually do and not do. martin From: development-bounces+martin.smith=theqtcompany@qt-project.org development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Marc Mutz marc.m...@kdab.com Sent: Monday, July 27, 2015 11:16 AM To: development@qt-project.org Subject: Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO On Monday 27 July 2015 00:27:18 Kevin Kofler wrote: It doesn't switch the stuff it actually guarantees: That sentence is perfectly correct. But here's the catch: The docs guarantee _a certain implementation_, incl. the switching. The problem is that the conditions under which the switch occurs are quite hard for non-experts to check. This is the beauty of the STL: without mentioning the actual implementation anywhere, its containers have such tailor-made guarantees that effectively only one implementation possibility is left (they even rule out CoW without mentioning it!). But since the STL doesn't specify any implementation, if research finds a data structure that meets those guarantees, the new structure automatically becomes permissible. This is what made std::make_shared's optimisation possible, e.g. Qt containers are not like that. QList docs say exactly how it's implemented, but not exactly what it guarantees. Thus, coming to depend on details of the implementation is a perfectly reasonable thing to do for a developer. It's documented, after all, if only indirectly. Quite some code in QtBase alone already depends on the de-facto guarantee of stable references, among them, just off the top of my head: - QDataWidgetMapper - QToolBox - one of the lists in QMime* - QListQMakeLocalFileName in qmake Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replace QtXml backend
On 27/07/15 09:58, Gerhard Scheikl g.sche...@avibit.com wrote: On Friday 24 July 2015 08:50:07 Thiago Macieira wrote: On Friday 24 July 2015 15:26:30 Gerhard Scheikl wrote: Hello Gerhard Your question is answered mostly by your paragraph above: QtXml is in Done state, so we really don't want to do major surgery in it, which could open the door up for subtle incompatibilities. I'm not even talking about introducing bugs that aren't there. That's sure a concern. But even if you do your best, you may *fix* bugs that people are accidentally depending on; or the simple fact of a change in behaviour could result in existing code getting broken. Are you prepared to accept all of those reports and react to them? Hi I didn't fully think it through yet, was just an idea. :) So we came up with the idea to replace the back-end with Xerces and try to leave the Qt API part the same. That's interesting. How big is Xerces? Around 260k LOC. How easy is it to build? ./configure make make install How is it licensed? Apache 2.0 If we succeed, we would like to give this code back to the community and replace the current QtXml classes. Do you include accepting maintainership of the module and reacting to bug reports in give this code back to the community? We're all for new and improved code, but when it comes with a large maintenance burden, we have to analyse whether it's worth the hassle. We have to maintain our code anyway. We definitely need to create a library that allows us to bring fast and working XML processing to our Qt backend. Even better if we get external bug reports. Maybe creating a 3rd party library would be the better choice. Maybe creating something like QtXml2 would be an option. Did you consider using QXmlStreamReader/Writer instead of the old QXml? These classes are fully compliant, well tested and very fast. The only drawback is that there is no equivalent to the QDom* classes, but in most cases you’re better off parsing directly into your own data structures anyway. Cheers, Lars What do you think? Could we arrange a conference call to talk about options? Thanks! Best regards, Gerhard ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replace QtXml backend
On 27/07/15 11:23, Gerhard Scheikl g.sche...@avibit.com wrote: Did you consider using QXmlStreamReader/Writer instead of the old QXml? These classes are fully compliant, well tested and very fast. The only drawback is that there is no equivalent to the QDom* classes, but in most cases you’re better off parsing directly into your own data structures anyway. Hi Currently, our main problem is that the XML validator goes into an infinite loop and therefor out of memory. Besides that, the validation is really slow. With the old QXmlReader or with QXmlStreamReader? (around 20 times slower than with xerces) Unfortunately, for our use case, SAX parsing is not an option. QXmlStreamReader is not a SAX parser. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Tool to record GIFs
Hi. I recently pushed a patch [1] that adds a GIF recorder tool (it's a manual test) to qt-labs/qtquickcontrols2. The tool provides a convenient way to record a GIF as you interact with a Qt application. It can also record the events that occurred during the recording and output them as calls to QTest functions (currently only mouse events), which can then be reused to reproduce the events later. This is mostly useful for cases where you have an existing GIF that shows interaction with some UI, and the appearance/styling of the UI is altered at some point and you don't want to have to waste time trying to recreate the events yourself through interaction with the application. You can see an example of its usage here: https://codereview.qt-project.org/#/c/122111/6/tests/manual/gifs/tst_gifs.cpp I'm interested to know if anyone else would get a use out of this. Other Qt modules could benefit from it. Currently the GifRecorder class assumes a QQuickView, but it should be quite trivial to have a WidgetGifRecorder and a QuickGifRecorder. Cheers. [1] https://codereview.qt-project.org/#/c/122111/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] FW: Backwards compatibiltiy break in Qt 5.5
Hi, I can understand the issues that non latin speakers are facing with this well. I’ve often used qDebug() to debug non latin use cases, and in 90% of the cases I just want to know what the string reads. The unicode content of it is interesting to me in only 10% of the cases. For most users not debugging Qt’s internals I would assume that ratio to be more like 99 to 1. Thiago, which backends can’t handle utf8 or utf16 output these days? One idea could be a slightly modified approach that is more compatible: * We always encode QStrings as utf8 (maybe utf16 for the windows console) when sending them to qDebug() * We quote every character that is not printable (ie. !QChar::isPrint()) * We add a flag that would give fully quoted strings so you can get a quoted version if required (e.g. qDebug() quoteStrings) Could such an approach work in practice? Cheers, Lars On 27/07/15 00:25, NIkolai Marchenko enmarantis...@gmail.com wrote: (I am not entirely sure why I haven't received at least a notification of why this post has not appeared the first time I tried to send it, so here we go again. Btw, it was Thiago Macieira himself who actually suggested I mail this list) Hi! We (Russian Qt community) have a situation we could not resolve with Thiago Macieira in bug tracker, so have to ask for Chief Maintainer's attention. The bug in question is there: https://bugreports.qt.io/browse/QTBUG-47316 In version 5.5 Thiago Macieira introduced a compatibility break with older qt versions. This break has come in the form of completely changing the way qDebug() prints non-english characters to console. In essense - his fix to qDebug() will make it so that all non-english output from QString variable to qDebug() will be passed as a sequence of unicode escaped characters along the lines of: \u043F\u0440\u043E\u0432\u0435\u0440\u043A\u0430 043A\u0438\u0440\u0438\u043B\u043B\u0438\u0446\u044B Previously, in _some_ cases, but not reliably cross platform it would actually appear in console as readable output in user's language. I have to admit that Thiago is right about it being non-reliable contradicts qt's goal. Still... What Thiago completely disregards as unimportant - qDebug()'s been around for a long time. Even during times of qt4, users, through the use of setCodec functions, achieved readable output from qDebug in the console in their native language. Note that I say qt4. It's been around for almost a decade and there being no warning qDebug ever changing, it's become a standard on a lot of non-english installations, that actually allowed getting readable output, to use qDebug for tracing variables.. After all, opening debugger to inspect every little thing is very counterproductive. So here is where we are now, there are hundreds (probably thousands actually) codebases, where there is code like that: qDebug() someLabel; // skip qDebug() someVariableFromDatabase; // skip qDebug() someTextFromNetworkService; This is kinda normal and completely adhering to Kai Kohne's message he posted on youtube in qt-dev days video of using qDebug() to log program execution to console. Now, we arrive to Qt5.5. From here on now, instead of reading the trace of program execution everyone using the old code will be subjected to strings like \u043F\u0440\u043E\u0432\u0435\u0440\u043A\u0430 043A\u0438\u0440\u0438\u043B\u043B\u0438\u0446\u044B Note, that there are dozens to hundreds of such lines per application. And in SUCH a format, the trace posted above becomes completely useless for the purposes of debugging, because people, generaly, don't have unicode parser plugged into their brains. Thiago argues that his way, user will always get exactly which type of A the symbol is. Our point - now user will first need to pass the output of qDebug to unicode converter to even understand what's he looking at. Now, again, I do not dispute that qDebug in a way it was being used was correct or reliable across all platforms or allowed to check exactly which symbol was contained in a string. But BETTER way to fix that, in my opinion, and all of the Russian users who are already aware of the problem is to introduce a qDebug().escape() or something along those lines, in those RARE cases when instead of just tracing variables, user NEEDS to see unicode. (note I say Russian, because that is the community I come from, but in reality the situation is the same for greek, japanese, whatever non-english) Here we have a conflict of interest: Do we fix qDebug() in a way it is SUPPOSED to work, breaking code for users, or do we make a different flavour of qDebug that actually works as we intended it to, cross platform and escapes everything and let people who need it switch to that? Personally, from what I know of application development, breaking codebase is always bad. breaking a LARGE codebase, is horrible. So, I am at a loss of why Thiago decided to go the first way. We've tried to convince him he underestimates the
Re: [Development] Backwards compatibiltiy break in Qt 5.5
My first instinct was suggesting MS to support Unicode in their console... but then I tried to reproduce the described issue on OS X and succeeded. qDebug() this is сообщение на русском; which I'd expect to be treated like a byte array, gives me this is сообщение на русском though qDebug() QString::fromUtf8(this is сообщение на русском); gives me this is \u0441\u043E\u043E\u0431\u0449\u0435\u043D\u0438\u0435 \u043D\u0430 \u0440\u0443\u0441\u0441\u043A\u043E\u043C A bit unexpected, isn't it? Regards, Konstantin 2015-07-27 12:20 GMT+03:00 Marc Mutz marc.m...@kdab.com: On Monday 27 July 2015 00:25:18 NIkolai Marchenko wrote: (I am not entirely sure why I haven't received at least a notification of why this post has not appeared the first time I tried to send it, so here we go again. Btw, it was Thiago Macieira himself who actually suggested I mail this list) Hi! We (Russian Qt community) have a situation we could not resolve with Thiago Macieira in bug tracker, so have to ask for Chief Maintainer's attention. The bug in question is there: https://bugreports.qt.io/browse/QTBUG-47316 In version 5.5 Thiago Macieira introduced a compatibility break with older qt versions. This break has come in the form of completely changing the way qDebug() prints non-english characters to console. I don't think qDebug() should guarantee any output, but your position might become a relevant one if logging output also changed. That is something that we shoudn't change, and since IIIRC, qDebug and logging use the same stream, you may have a point here. Just my 2ct, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replace QtXml backend
Did you consider using QXmlStreamReader/Writer instead of the old QXml? These classes are fully compliant, well tested and very fast. The only drawback is that there is no equivalent to the QDom* classes, but in most cases you’re better off parsing directly into your own data structures anyway. Hi Currently, our main problem is that the XML validator goes into an infinite loop and therefor out of memory. Besides that, the validation is really slow. (around 20 times slower than with xerces) Unfortunately, for our use case, SAX parsing is not an option. Best regards Gerhard ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
