Re: [Development] Feature defines in Qt 5?
On Thursday, December 15, 2011 13:12:42 Thiago Macieira wrote: On Thursday, 15 de December de 2011 12.25.10, Stephen Kelly wrote: The reason I'm bringing it up is that I want to be able to communicate through the CMake files which features Qt was built excluding. For example, if Qt was built with QT_NO_DATESTRING, it makes sense for all downstreams to define QT_NO_DATESTRING too. Isn't the define available for everyone including cmake? It should be in qconfig.h, which is installed. You're right. I think that is probably enough. I'll do some experimentation. Thanks, -- Stephen Kelly step...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
On Thursday, 15 de December de 2011 13.01.06, Frans Klaver wrote: I didn't intend to suggest that they should be parachuted in. It could be worth investigating if some people from digia may have already shown that they fit the bill. As far as I know current maintainers and approvers have the possibility to nominate someone for a position, but if no one cares to do that, there won't be any progress. I could be wrong though. A lot of desktop users of Qt would probably be happy if for example QtWidgets fixes end up in the main-line development quickly. If no one from digia has shown enough merit, there's no point in promoting them. I've spoken about this to Tuukka in a couple of occasions. It's my understanding that getting the Digia engineers become approvers and eventually maintainers for the parts they work mostly on is their intention too. However, right now, those engineers are mostly working on Qt 4.8, which is not part of Gerrit, so any work they might have been doing is lost to us. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
Tuukka: How can we most-easily discover the list of changes that are in Qt Commercial 4.8.0 but not in (LGPL) Qt 4.8.0? We have several bugs we're particularly interested in... Atlant From: development-bounces+aschmidt=dekaresearch@qt-project.org [mailto:development-bounces+aschmidt=dekaresearch@qt-project.org] On Behalf Of Turunen Tuukka Sent: Thursday, December 15, 2011 06:22 To: development@qt-project.org Subject: [Development] Qt Commercial 4.8.0 release delta to LGPL version Hi All, Qt 4.8.0 and Qt Commercial 4.8.0 have been released today. I wanted to send you e-mail about the delta between these. We have worked hard with 4.8 to improve it for desktop and embedded platforms according to the needs of commercial licensees. We have fixed a lot of bugs and included support to new platforms. While doing these, we have made close to 200 contributions in the past few months, but unfortunately not all these have yet been merged in to Qt. So now there is total of 108 improvements and bug fixes available in Qt Commercial 4.8.0 that are not part of the LGPL release. I want to underline that this is not the intended way of differentiating our offering. Going forward I hope that we can be more aligned. I would like to see most of the current delta integrated to Qt by the time of 4.8.1, if it is possible. Yours, -- Tuukka Turunen Director, Qt Commercial RD Digia Plc Piippukatu 11, 40100 Jyväskylä, Finland Visit us at: www.digia.comapplewebdata://7FB7E1CD-55A7-4FAD-B1A5-7721230C2E29/www.digia.com or qt.digia.comhttp://qt.digia.com/ Click herehttps://www.mailcontrol.com/sr/LVL08Nbr7bfTndxI!oX7UpIgRUnoDh5v!ATK+M43ncbQwYNGrd1o78jPauZj3vhpWUaH6ZUVxeZGp10b+rkp2Q== to report this email as spam. This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
On Thu, Dec 15, 2011 at 1:29 PM, Thiago Macieira thiago.macie...@intel.com wrote: I've spoken about this to Tuukka in a couple of occasions. It's my understanding that getting the Digia engineers become approvers and eventually maintainers for the parts they work mostly on is their intention too. Right. However, right now, those engineers are mostly working on Qt 4.8, which is not part of Gerrit, so any work they might have been doing is lost to us. Hm, that explains something at least. If Olivier is correct about them not following some policy then it's not too surprising some work got lost on the way. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QRegularExpression -- first round of API review
Hi everybody. Sorry for the length of thjis message, but doing API reviews by mail is hard, and I needed to explain many decisions here and there (and, of course, the API itself). :-( Attached to this mail (and also here: http://pastebin.com/KzsGFXJC -- if you don't want to download and open a file) you can find a stripped down version of the QRegularExpression API I'm working on. It's deliberately stripped down because at this stage I'd like to have feedbacks about the API and not about the code itself. We're still free of changing all parts of it, so, even if you dislike the tiniest bit of something, please go ahead and say it. And it's deliberaltely without comments, so the reader's exercise now is reading it and finding out if it's understandable at a first glance. Once you're done, I'll start commenting the non-obvious points. General As discussed, two implicitly shared, copy on write, reentrant value classes: the regexp itself (pattern + options) and the result of a match against a subject string (fixes the T7 in http://developer.qt.nokia.com/wiki/Regexp_engine_in_Qt5 ). The regexp also stores the compiled form of itself as an hidden optimization -- most const methods actually do modify the shared instance. The backend is PCRE so the feature set is quite big (fixing T1-T4). I have already planned to expand the enums to support even more options. QRegularExpression PatternOptions The PatternOptions flag contains the pattern options, i.e. modify the characters that the pattern should match. * CaseInsensitiveOption is the /i flag (case Insensitive Match). In QRegExp it was set by a separate method (setCaseSensitivity), holding a Qt::CaseSensitivity value. Here IMHO it just clutters the API to have different getters and setters for the options. * InvertedGreedinessOption is the /U flag (not present in Perl) inverts the greediness of the quantifiers: they became not greedy by default, and greedy if followed by ?. See also the T3 in the list. * DotMatchesEverythingOption is the /s flag (Single line match): the dot (.) metacharacter matches everything including newlines. * MultilineMatchOption is the /m flag (Multi line match): the caret (^) and the dollar ($) metacharacters are allowed to match at (and just before) any newline inside the string (as well as the ordinary begin and end of the string) * ExtendedPatternSyntaxOption is the /x flag (eXtended pattern syntax): whitespace data inside the regexp is ignored, and an unescaped # outside a character class starts a comment that goes till the next newline (inside the pattern!). It's probably not very useful in C++, where one can use the default rules for string literals, but it may be handy if one stores complicated regexps in an external file. * UseUnicodePropertiesOption enables the use Unicode properties for character classes such as \w, \s, \d, etc. (and obviously their counterparts \W, \S, etc.), instead of making them just match the standard ASCII ranges * AllowDuplicatedNamesOption allows duplicated named capturing patterns (that is (?NAME ... ) patterns) * DontCaptureOption disables the use of unnamed capturing parenthesis -- they all behave as if they all were (?:...) parenthesis. Named ones continue to work. * MatchFirstlineOnlyOption restricts an unanchored pattern to start to match only before the first newline (although the match can continue over it). * DollarMatchesOnlyAtEndOption changes the meaning of the dollar ($) metacharacter to match only at the very end of the string, while usually it matches at the end AND at a newline right before the end CompileHints The CompileHints are hints to the regexp engine itself. Basically they control the optimization of the compiled regexp (the PCRE API is pcre_study). * StudyPatternCompileHint tells PCRE engine to study the pattern, which basically means performing very simple optimization tasks (f.i., the engine records the minimum size of a string to get a successful match, and if the subject string is shorter the match aborts immediately) * JitCompileHint implies StudyPatternCompileHint, and enables the JIT compilation of the pattern. Of course this has a cost, and there's a tradeoff to consider between spending time compilating the regexp instead of just matching against a string. MatchOptions The MatchOptions control the match itself. * AnchoredMatch forces the match to start at the first matching point inside the subject string, even if the regexp doesn't have carets or other metacharacters that normally force such a
Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
Hi Tuukka, (now that I've left some hours to digest this...) 2011/12/15 Turunen Tuukka tuukka.turu...@digia.com: So now there is total of 108 improvements and bug fixes available in Qt Commercial 4.8.0 that are not part of the LGPL release. I want to underline that this is not the intended way of differentiating our offering. Going forward I hope that we can be more aligned. I would like to see most of the current delta integrated to Qt by the time of 4.8.1, if it is possible. First: let me say thanks for bringing this up sooner rather than later. That is certainly quiet a backlog (in a bad way), and one that should be addressed ASAP, if not yesterday :). It's also pleasing to hear that you want to work to bring these changes back to the Qt Project. In my opinion, there's two issues that need addressing here. The first (already brought up) is gerrit. Gitorious' merge requests are painful for everyone involved, so they're just going to slow you down. Once things get into Gerrit, assuming they work in a similar fashion to Qt 5, I think you'll find that changes can get pushed forward a fair bit easier (especially assuming you know the right people to poke for reviews, which I expect you do for the most part). The second is that these changes have been going to Qt 4.8. Some people seem to have assumed this was an issue, but I'm not entirely sure this was correct, as I seem to recall that Ossi had a magical script to somehow mangle changes from 4.x into Qt 5.x[1] - and if that is the case, there really isn't much further problem I think. If this script doesn't do what I'm hoping, then we're going to have to figure out how to get this work into Qt 5 with the minimum of pain (meaning as soon as possible), before merging becomes impossible or at least impractical. So anyway, the summary of my thoughts on solving this would be: - get 4.x into Gitorious ASAP - get the changes into 4.x (can probably be ongoing while the above isn't finished, but will be helped) - cherry-pick them into Qt 5 (in any way possible) to make sure work isn't lost or duplicated, since I assume that your customers will be asking about Qt 5 sooner rather than later :) ...and we're back to working as one big, happy family in Gerrit :) [1]: http://lists.qt-project.org/pipermail/development/2011-November/000483.html - though this repo has apparently been merged into qtrepotools. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
Hi, On Thu, Dec 15, 2011 at 1:23 PM, Olivier Goffart oliv...@woboq.com wrote: On Thursday 15 December 2011 11:53:12 sinan.tanil...@nokia.com wrote: We hope to move Qt 4 to Gerrit soon. This should enable faster handling of contributions. Wasn't the policy to first push the code in Qt5, then backport in Qt 4.8? I'd agree that would make sense to be a policy. But for it to be a policy, it needs to be documented and communicated somewhere. You can't expect this information to just filter out by itself, or expect that it's common sense for everyone. I don't see this listed on http://wiki.qt-project.org/Commit_Policy. Should it be? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
Hi, On Thu, Dec 15, 2011 at 10:26 PM, Robin Burchell robin...@viroteck.net wrote: Wasn't the policy to first push the code in Qt5, then backport in Qt 4.8? I'd agree that would make sense to be a policy. But for it to be a policy, it needs to be documented and communicated somewhere. You can't expect this information to just filter out by itself, or expect that it's common sense for everyone. I don't see this listed on http://wiki.qt-project.org/Commit_Policy. Should it be? Actually, when I read this a second time looking for something relevant, I see the complete opposite: 11. Make sure you submit against the lowest applicable branch from which a release is still planned. Cherry-picks (backports) are frowned upon, while forward-merging to more recent branches happens on a regular basis. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
On Thursday 15 December 2011 22:31:32 Robin Burchell wrote: Hi, On Thu, Dec 15, 2011 at 10:26 PM, Robin Burchell robin...@viroteck.net wrote: Wasn't the policy to first push the code in Qt5, then backport in Qt 4.8? I'd agree that would make sense to be a policy. But for it to be a policy, it needs to be documented and communicated somewhere. You can't expect this information to just filter out by itself, or expect that it's common sense for everyone. I don't see this listed on http://wiki.qt-project.org/Commit_Policy. Should it be? Actually, when I read this a second time looking for something relevant, I see the complete opposite: 11. Make sure you submit against the lowest applicable branch from which a release is still planned. Cherry-picks (backports) are frowned upon, while forward-merging to more recent branches happens on a regular basis. Well, that is when the branches lies in the same repository. With Qt 4 cannot be merged in Qt 5 because of the modularisation. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving QUndoStack and QUndoCommand out of QtWidgets
On Thursday 15 December 2011 18:40:45 Jesus Sanchez-Palencia wrote: Hi there, I would like to gather your opinion on whether we should move QUndoStack and QUndoCommand out of QtWidgets so they could be used without requiring this module as an extra dependency. After a brief investigation, I believe this could done by: 1- moving QUndoCommand entirely; 2- moving QUndoStack without moving the APIs that rely on or need QAction (QAction *createUndoAction() and QAction *createRedoAction()); 3- creating a new class (QUndoStackAction ??) inside QtWidgets and implement the APIs mentioned above there (createUndoAction and createRedoAction); 4- applying the same logic to QUndoGroup. QtWebKit, for instance, would benefit from this immediately, as we aim on removing the QtWidgets dependencies. Suggestions, comments and any sort of feedback here would be more than welcome. I beleive QAction should also be moved back in QtGui ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRegularExpression -- first round of API review
Hi Giuseppe, I'll start by saying tl;dr. But I didn't stop because of your e-mail, I'm actually referring to the API. I started looking at it and it seems too cluttered. Specially this early in the process. It's hard to review something that is trying to be everything or maybe it's just exposing too many things. I would like to challenge you to do the opposite: give us the minimum API that can offer the most important features. To get there start from short self-contained code examples showing the features in use (I'm interested in seeing those) -- API design is about how it gets used, not so much about the number of features. For instance, in Perl, regular expressions are essentially a string, a couple of operators and some magic variables for the captures (and lots of magic everywhere...). (Now, I'm not saying we should do regular expressions in Qt as they are done in Perl) The API, as it stands seems too hard-wired to the implementation or feature set of the engine giving it little opportunity for evolving. Another issue is that it is hard for me to see if (or where) the API itself is imposing performance penalties on the implementation. Finally, note that it is usually ok to add API as time goes by, but our BC promises mean we have to maintain most of what we add for a long time. Cheers, João From: development-bounces+joao.abecasis=nokia@qt-project.org [development-bounces+joao.abecasis=nokia@qt-project.org] on behalf of ext Giuseppe D'Angelo [dange...@gmail.com] Sent: 15 December 2011 17:43 To: development@qt-project.org Subject: [Development] QRegularExpression -- first round of API review Hi everybody. Sorry for the length of thjis message, but doing API reviews by mail is hard, and I needed to explain many decisions here and there (and, of course, the API itself). :-( Attached to this mail (and also here: http://pastebin.com/KzsGFXJC -- if you don't want to download and open a file) you can find a stripped down version of the QRegularExpression API I'm working on. It's deliberately stripped down because at this stage I'd like to have feedbacks about the API and not about the code itself. We're still free of changing all parts of it, so, even if you dislike the tiniest bit of something, please go ahead and say it. And it's deliberaltely without comments, so the reader's exercise now is reading it and finding out if it's understandable at a first glance. Once you're done, I'll start commenting the non-obvious points. General As discussed, two implicitly shared, copy on write, reentrant value classes: the regexp itself (pattern + options) and the result of a match against a subject string (fixes the T7 in http://developer.qt.nokia.com/wiki/Regexp_engine_in_Qt5 ). The regexp also stores the compiled form of itself as an hidden optimization -- most const methods actually do modify the shared instance. The backend is PCRE so the feature set is quite big (fixing T1-T4). I have already planned to expand the enums to support even more options. QRegularExpression PatternOptions The PatternOptions flag contains the pattern options, i.e. modify the characters that the pattern should match. * CaseInsensitiveOption is the /i flag (case Insensitive Match). In QRegExp it was set by a separate method (setCaseSensitivity), holding a Qt::CaseSensitivity value. Here IMHO it just clutters the API to have different getters and setters for the options. * InvertedGreedinessOption is the /U flag (not present in Perl) inverts the greediness of the quantifiers: they became not greedy by default, and greedy if followed by ?. See also the T3 in the list. * DotMatchesEverythingOption is the /s flag (Single line match): the dot (.) metacharacter matches everything including newlines. * MultilineMatchOption is the /m flag (Multi line match): the caret (^) and the dollar ($) metacharacters are allowed to match at (and just before) any newline inside the string (as well as the ordinary begin and end of the string) * ExtendedPatternSyntaxOption is the /x flag (eXtended pattern syntax): whitespace data inside the regexp is ignored, and an unescaped # outside a character class starts a comment that goes till the next newline (inside the pattern!). It's probably not very useful in C++, where one can use the default rules for string literals, but it may be handy if one stores complicated regexps in an external file. * UseUnicodePropertiesOption enables the use Unicode properties for character classes such as \w, \s, \d, etc. (and obviously their counterparts \W, \S, etc.), instead of making them just match the standard ASCII ranges * AllowDuplicatedNamesOption allows
Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
I'm quoting Robin's email (with some of my comments), because I think it was a great message that I don't want lost: On Thu, Dec 15, 2011 at 2:16 PM, Robin Burchell robin...@viroteck.netwrote: Hi Tuukka, (now that I've left some hours to digest this...) 2011/12/15 Turunen Tuukka tuukka.turu...@digia.com: So now there is total of 108 improvements and bug fixes available in Qt Commercial 4.8.0 that are not part of the LGPL release. I want to underline that this is not the intended way of differentiating our offering. Going forward I hope that we can be more aligned. I would like to see most of the current delta integrated to Qt by the time of 4.8.1, if it is possible. First: let me say thanks for bringing this up sooner rather than later. That is certainly quiet a backlog (in a bad way), and one that should be addressed ASAP, if not yesterday :). It's also pleasing to hear that you want to work to bring these changes back to the Qt Project. We're a Qt Commercial customer, and attended the Commercial Forums at Qt Developer Days in San Francisco a few weeks ago, so this was not a surprise to us. The issue was explained (multiple development processes at different organizations, current in-inefficiencies synchronizing maintenance among the participants), and the greatest concern seemed to be that the community-as-a-whole might be confused about how/why this result-came-about, when the only issue is simply that community-management is still in the process of being launched, and we have not yet established efficient synchronization across the different structures. Agree with Robin: This is an important issue (technical backlog), and it is A Good Thing(TM) it was brought up through a clear message to the community in a timely manner. Further, having the benefit of more-in-depth-information shared by Digia at Developer Days, IMHO this is merely a process issue (albeit a real one). Digia did important work with these changes that benefit the *whole* community, and the goal is to share them with the *whole* community. We (the whole community) merely need a process that permits this to happen as efficiently as possible, and IMHO everybody is already on-board with a positive work-together Goal-And-Attitude to ensure we all vector in the same direction. In short, my opinion is simply: This is merely a (short-term) result from the fact that multiple processes-and-structures currently exist. We can improve this. I see only positive intent-and-actions among all the players, so this clearly seems resolvable. In my opinion, there's two issues that need addressing here. The first (already brought up) is gerrit. Gitorious' merge requests are painful for everyone involved, so they're just going to slow you down. Once things get into Gerrit, assuming they work in a similar fashion to Qt 5, I think you'll find that changes can get pushed forward a fair bit easier (especially assuming you know the right people to poke for reviews, which I expect you do for the most part). The second is that these changes have been going to Qt 4.8. Some people seem to have assumed this was an issue, but I'm not entirely sure this was correct, as I seem to recall that Ossi had a magical script to somehow mangle changes from 4.x into Qt 5.x[1] - and if that is the case, there really isn't much further problem I think. If this script doesn't do what I'm hoping, then we're going to have to figure out how to get this work into Qt 5 with the minimum of pain (meaning as soon as possible), before merging becomes impossible or at least impractical. Very good points. So anyway, the summary of my thoughts on solving this would be: - get 4.x into Gitorious ASAP +1 - get the changes into 4.x (can probably be ongoing while the above isn't finished, but will be helped) +1 - cherry-pick them into Qt 5 (in any way possible) to make sure work isn't lost or duplicated, since I assume that your customers will be asking about Qt 5 sooner rather than later :) +1 We are a commercial customer, and yes, we want Qt5 sooner. ;-)) ...and we're back to working as one big, happy family in Gerrit :) [1]: http://lists.qt-project.org/pipermail/development/2011-November/000483.html - though this repo has apparently been merged into qtrepotools. Really good points and suggestions by Robin, +1. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRegularExpression -- first round of API review
On 15 December 2011 19:45, Oswald Buddenhagen oswald.buddenha...@nokia.com wrote: On Thu, Dec 15, 2011 at 04:43:49PM +, ext Giuseppe D'Angelo wrote: pos, matchedLength, endPos inconsistent naming Well, pos and matchedLength come straight from QRegExp and I kept them. But please, any suggestion is welcome! (I'm not even a native English speaker). (In case it isn't clear: endPos() == pos() + matchedLength() - 1) void setPatternOptions(PatternOptions options, bool on = true); i don't like that too much, because *un*setting options en masse sucks - you need to make a block of options to set, and a block of options to delete. I copied the setXXX(flags, bool on = true) from QPainter::setRenderHints, I was quite sure it's also used somewhere else. So are you suggesting a simple setPatternOptions(options) that simply sets (as in *assigns*) the argument as the current option set? that's half as bad if all options are off by default, but then one has to wonder whether a way to unset them actually makes sense in the first place. Yes, all options are off by default. I don't see any particular problem with turning an option on and then off again. What do you think about this? fwiw, the usual elegant solution is having a value and a mask parameter. the mask could have two magic values meaning un-/set all asserted in vlaue to mean effectively what your bool means. the default argument would be the magic value for setting, so the standard syntax would set all flags named in the first argument. I'm not sure I understand this point completely -- isn't that what the method does? I.e. rx.setPatternOptions(CaseInsensitiveOption | DotMatchesEverythingOption) turns on those two options, and leaves the others unchanged. Thanks for the feedback. Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRegularExpression -- first round of API review
On Thursday, 15 de December de 2011 22.53.19, joao.abeca...@nokia.com wrote: Hi Giuseppe, I'll start by saying tl;dr. But I didn't stop because of your e-mail, I'm actually referring to the API. Hi as well Giuseppe I did read most of your email :-) Thanks for the effort so far. I'd like to start by saying I agree with Ossi: the test/set way of setting flags is un-Qt-ish. I know it exists in a few places, but they are the vast minority. I'd prefer a regular pair of getter and setter on the QFlags type. I started looking at it and it seems too cluttered. Specially this early in the process. It's hard to review something that is trying to be everything or maybe it's just exposing too many things. João is also right: it seems you're trying to provide all the power of PCRE to the user in the first go. It's good that you're exploring everything, so we know which way we may go in the future, but I think we can trim down on the features at the first iteration of the API. The next thing that I find weird is the set of match functions. My first reaction was to ask you to call them indexIn, but since they don't return an index but a match object, the name is fine. But still, do we need a match, partialMatch and exactMatch? Also note that the boolean in partialMatch is also un-Qt-ish, so you'll need to replace it with an enum as well. If you do, you may as well merge all three functions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature freeze date?
Having been release manager for several past Qt feature releases (4.5 to 4.7), I'm wary of setting a single feature freeze date and having a big rush to cram all the new features into the master branch in the last couple of days before the deadline. Instead, I would like to see a staggered delivery of features, where each large change is tested, merged and tested some more before the gate is opened for the next big change. For the Qt 4.5.0 and 4.6.0 releases, we did the former, and in both cases the last minute rush to push in all the new features caused substantial breakage and significantly delayed the alpha and beta releases. For Qt 4.6, it took two weeks after the feature freeze date to get the branch compiling again on all the Tier 1 platforms (that was the criteria for an alpha release) and several months to satisfy the (fairly lax) quality criteria for a beta release. For the Qt 4.7.0 release, we staggered the merging of new features over several weeks and had a much better result, with alpha release packages building successfully on the day after the feature freeze. -- Jason McDonald QTestLib Maintainer ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRegularExpression -- first round of API review
On 15 December 2011 22:53, joao.abeca...@nokia.com wrote:
Hi Giuseppe,
Hi João,
thanks for the comments.
I'll start by saying tl;dr. But I didn't stop because of your e-mail, I'm
actually referring to the API.
I started looking at it and it seems too cluttered. Specially this early in
the process. It's hard to review something that is trying to be everything or
maybe it's just exposing too many things.
I would like to challenge you to do the opposite: give us the minimum API
that can offer the most important features. To get there start from short
self-contained code examples showing the features in use (I'm interested in
seeing those) -- API design is about how it gets used, not so much about the
number of features.
Then we should discuss what those important features are. In my mail
I pointed out how the API is supposed to fix the T1-T7 issues, but I
can understand not all of them have the same priority.
(Other sub-objectives are 1) keeping the QRegExp feature set 2) keep
existing stuff working; but I guess that if QRegExp gets moved in a
stand-alone module, we simply can make other modules in Qt depend on
that one until we have a replacement, and thus not breaking anything.)
I'd like to collect feedbacks about these priorities, especially from
the intended users of the API! If you have the chance, please tell
developers to give their opinions.
Continuing: you're totally right about the missing examples. I'll
write some down and then post them.
For instance, in Perl, regular expressions are essentially a string, a couple
of operators and some magic variables for the captures (and lots of magic
everywhere...). (Now, I'm not saying we should do regular expressions in Qt
as they are done in Perl)
That's basically the same here, but there are also options to control
the optimization level (you may not want to lose time optimizizing,
esp. for quick, one-shot matches; or prefer to optimize in case you
have to filter a model of 100k+ strings) and the match behaviour (some
options are actually implemented in Perl -- see what I wrote about the
/g algorithm -- but they are not avaiable to the user).
At high level:
- QRegularExpression is the pattern+options, as in Perl's /pattern/options.
- QRegularExpressionMatch is the rough equivalent of Perl's capturing variables:
- $ - cap(0)
- $1...$n - cap(n)
- $+[n] - pos(n)
- $-[n] - endPos(n)
- $+{str} - capturedText(str)
- $-{str} - capturedTextsForName(str)
etc.
Plus, the match object is used to implement /g, that is, to repeatedly
match on a string (as convenience API).
The API, as it stands seems too hard-wired to the implementation or feature
set of the engine giving it little opportunity for evolving.
Where do you feel I could improve this? F.i. removing some enum is
easy, but I guess the problem isn't there.
Another issue is that it is hard for me to see if (or where) the API itself
is imposing performance penalties on the implementation.
The biggest hit as of now is obviously the conversions all around the
place from/to UTF-8, which have a memory and time impact. This will
eventually be solved when PCRE ships with native UTF-16 support (see
Stephen Kelly's mail about this). Apart from that the implementation
is almost straightforward -- just call the method in PCRE that does
the work and grab the result.
The other hit I talked about is inside the implementation of iterating
backwards (and lastMatch). I cannot see any good general way to
implement it, apart from iterating forward from the beginning (and
eventually caching such results. A match result in terms of captured
strings is quite small -- we just keep the offsets inside the
subject). The fact is that matching backwards is simply something a
bit outside the regexp world.
Cheers,
--
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRegularExpression -- first round of API review
2011/12/16 Thiago Macieira thiago.macie...@intel.com: I did read most of your email :-) Thanks for the effort so far. Hero :-) Thank you for reading! I'd like to start by saying I agree with Ossi: the test/set way of setting flags is un-Qt-ish. I know it exists in a few places, but they are the vast minority. I'd prefer a regular pair of getter and setter on the QFlags type. No problem. Will do. I started looking at it and it seems too cluttered. Specially this early in the process. It's hard to review something that is trying to be everything or maybe it's just exposing too many things. João is also right: it seems you're trying to provide all the power of PCRE to the user in the first go. It's good that you're exploring everything, so we know which way we may go in the future, but I think we can trim down on the features at the first iteration of the API. Ok, see the other message about this. The next thing that I find weird is the set of match functions. My first reaction was to ask you to call them indexIn, but since they don't return an index but a match object, the name is fine. But still, do we need a match, partialMatch and exactMatch? * match: I think it should stay :-) * exactMatch: it's convenience, and it's there... because QRegExp offered it (although there it was handy to perform partial matching). As I wrote, an user can get the very same result by wrapping a pattern between \A and \z (and that's more or less how it would be implemented). It's just a matter of deciding if we want it or not. Up to the consensus. * lastMatch (again, being there because QRegExp offered it) this is tricky to implement correctly and efficiently, and needs the same discussion about iterating backwards. * partialMatch: the hard version may be removed, for now, in favour of adding, later, a more general way to perform incremental matching over non contiguous chunks of data (and iterating, as in /g, over such matches). The soft version might stay there for validators, if you feel that its behaviour is the right one. Also note that the boolean in partialMatch is also un-Qt-ish, so you'll need to replace it with an enum as well. If you do, you may as well merge all three functions. Surely I can merge match, exactMatch and partialMatch in only one method, with an enum to control the behaviour. OTOH lastMatch may require a different offset (from the *end* of the string), so I'm not sure if merging it as well. Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRegularExpression -- first round of API review
Op 16-12-2011 1:07, Giuseppe D'Angelo schreef: fwiw, the usual elegant solution is having a value and a mask parameter. the mask could have two magic values meaning un-/set all asserted in vlaue to mean effectively what your bool means. the default argument would be the magic value for setting, so the standard syntax would set all flags named in the first argument. I'm not sure I understand this point completely -- isn't that what the method does? I.e. rx.setPatternOptions(CaseInsensitiveOption | DotMatchesEverythingOption) turns on those two options, and leaves the others unchanged. Really? Now to me _that_ is unexpected behaviour. I would have expected that this method call would set the options to exactly (CaseInsensitiveOption | DotMatchesEverythingOption), no matter what the previous value of the matchingOptions value was. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
