Re: [Development] Regular expression libraries for QRegExp (what about tre)
On Saturday, 3 de December de 2011 23.39.57, Francesco Riosa wrote: reading these two blogs: http://blog.rburchell.com/2011/12/why-i-avoid-qregexp-in-qt-4-and-so.html http://blogs.kde.org/node/4510 (Regexp library benchmarks...) I've learned of the TRE library (http://laurikari.net/tre/about/) it has interesting functionality like fuzzy matching and seem to have all what you need except for named matches (?name: bla bla) I've tryed to compile it and it's very small. Licensed As is what does it miss for be elected in qt5 inclusion? Two things: 1) a fully-compatible syntax to PCRE or JS, with equal or better performance than existing engines 2) a healthy developer community behind it to ensure that it will continue to be supported -- 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] Regular expression libraries for QRegExp
2011/11/23 Thiago Macieira thi...@kde.org: We don't even have to mark this one deprecated. If the new engine's API is compatible, it could be used for both. well doesn't that depend on how complete you want SC to be? QRegExp uses different syntax than pretty much every other RE engine, definitely different from PCRE, and supports different features. So if people have hardcoded regular expressions, they may function differently, or not at all. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Regular expression libraries for QRegExp
On 11/23/11 3:30 PM, ext Thiago Macieira thi...@kde.org wrote:
On Monday, 21 de November de 2011 21:25:07 lars.kn...@nokia.com wrote:
One interesting piece will be how we continue with this. We will most
likely need one regexp engine in QtCore (as regexp's are being used
internally in Qt in a couple of places). If we move QRegExp out, we
still
need to consider how to keep source compatibility. For inline code we
can
use some template magic to solve this, but it's a bit harder for stuff
living in .cpp files (e.g. QDir and QDirIterator).
All problems in C++ can be solved by another level of indirection.
In this case, the indirection is *already* present: nowhere in the QDir
and
QDirIterator APIs are QRegExps used. It's used only internally for
wildcard
matching, so we can replace that with other suitable RE or actual
globbing
functions.
You're right, these are not problematic.
For QString, we can do:
template class RegExp
inline bool contains(const RegExp rx, QEnableIfsome construct here)
{
return rx.indexIn(*this) != 0;
}
We don't even have to mark this one deprecated. If the new engine's API
is
compatible, it could be used for both.
Note: I'm not saying the new engine needs to be API-compatible with
QRegExp.
We don't need a compatible API to make this work. Simple template
specialization in the corresponding regexp header file should do the trick.
I'm not saying it's impossible to solve, simply that it requires some work
and thinking to do it properly.
Cheers,
Lars
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Regular expression libraries for QRegExp
On Tuesday, 22 de November de 2011 09.58.02, lars.kn...@nokia.com wrote: A IMO better solution would be to have a repository called e.g. qtsupport (KDE had something similar for quite a while) that contains copies to these 3rd party libraries for convenience. I'd prefer that too. And to keep Craig happy for LSB support, if PCRE isn't on it, we should ensure that the qtsupport always builds the libraries it needs as static and privately installs them for Qt only. We'll need then to tweak Qt's build system -- I'm not volunteering! -- to do a whole-archive linkage. That is when you link a static library into a dynamic library by importing all the .o files into it. The static library must have been built with -fPIC and is then known as convenience library. Once conveniently linked, the .a files can be removed. They should not get deployed on devices. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 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] Regular expression libraries for QRegExp
On Friday, November 11, 2011 13:01:55 Zoltán Herczeg wrote: Hi Qt Devs, I am Zoltan Herczeg, a PCRE and a QtWebKit developer. Stephen Kelly told me that Qt would like to replace the QRegExp engine with another regex engine (http://thread.gmane.org/gmane.comp.lib.qt.qt5-feedback/1524/), and he _really_ encouraged me to tell you that we consider adding UTF16 support in PCRE (http://bugs.exim.org/show_bug.cgi?id49). This is a longer-term plan which is only at the planning phase now, however, and only worth something if someone would use it. Do Qt interested in an wchar/UTF16 based PCRE? Regards, Zoltan Thanks Zoltán for sending this. I'm back from vacation, so I'll see if this can get pushed along on the Qt requirements side and if it is possible for Qt5 to use PCRE. 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] Regular expression libraries for QRegExp
On 11/21/11 6:29 PM, ext Thiago Macieira thi...@kde.org wrote: On Monday, 21 de November de 2011 15.45.49, Giuseppe D'Angelo wrote: But first: do we all (esp. Thiago, Lars) agree to use the UTF-8 version for now (and pay for the pattern/subject string/offsets conversions) and then write and enable a UTF-16 codepath when PCRE ships with proper support for it (by detecting its version at runtime)? Yes. And yes. Also note that it might be easier to convert to UTF-8, execute the RE and then scan forward the UTF-16 string by counting the number of UTF-8 bytes per character and map the offsets that we *do* need (match offset and captures). Also: what's the minimum PCRE version Qt should require? I see that Debian 6 (stable) uses 8.02 [1], Ubuntu 10.04 LTS uses 7.8 [2]. For other distributions of course YMMV. Is it OK to depend on even more recent versions? For instance, PCRE 8.10 adds UCP support (basically make \w \d etc. match the corresponding Unicode properties), and PCRE 8.20 adds a JIT feature (which promises large perfomance benefits) [3] [4]. Again: should we resort to depend on a old version, detect the proper one at runtime, and optionally enabling those features? I don't know. We should choose the features we want and then require that. Unicode matching sounds interesting. As does the JIT. Do you have an idea on how much bigger PCRE gets by these features? About the API itself: would you like more three classes (raw pattern - compiled pattern - result of a match), or only two (pattern - result of a match)? Two sounds better. I don't see the point in having a distinction between a raw and a compiled pattern. We might just need a pattern class and simply have a method to compile it. Agree with Thiago. One interesting piece will be how we continue with this. We will most likely need one regexp engine in QtCore (as regexp's are being used internally in Qt in a couple of places). If we move QRegExp out, we still need to consider how to keep source compatibility. For inline code we can use some template magic to solve this, but it's a bit harder for stuff living in .cpp files (e.g. QDir and QDirIterator). Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Regular expression libraries for QRegExp
Hi Qt Devs, I am Zoltan Herczeg, a PCRE and a QtWebKit developer. Stephen Kelly told me that Qt would like to replace the QRegExp engine with another regex engine (http://thread.gmane.org/gmane.comp.lib.qt.qt5-feedback/1524/), and he _really_ encouraged me to tell you that we consider adding UTF16 support in PCRE (http://bugs.exim.org/show_bug.cgi?id=1049). This is a longer-term plan which is only at the planning phase now, however, and only worth something if someone would use it. Do Qt interested in an wchar/UTF16 based PCRE? Regards, Zoltan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Regular expression libraries for QRegExp
Hi Zoltan, Great to hear from you. UTF16 support would be a basic requirement for us using it in Qt. We don't really need wchar_t support though. Our main issue seem to be timing then. We currently have the opportunity of changing API to some extend before we freeze down things for Qt 5 again. Thus we'd need something relatively soon to be able to use it for 5.0. Cheers, Lars On 11/11/11 1:01 PM, ext Zoltán Herczeg hzmes...@freemail.hu wrote: Hi Qt Devs, I am Zoltan Herczeg, a PCRE and a QtWebKit developer. Stephen Kelly told me that Qt would like to replace the QRegExp engine with another regex engine (http://thread.gmane.org/gmane.comp.lib.qt.qt5-feedback/1524/), and he _really_ encouraged me to tell you that we consider adding UTF16 support in PCRE (http://bugs.exim.org/show_bug.cgi?id=1049). This is a longer-term plan which is only at the planning phase now, however, and only worth something if someone would use it. Do Qt interested in an wchar/UTF16 based PCRE? Regards, Zoltan ___ 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] Regular expression libraries for QRegExp
hi, On Fri, Nov 11, 2011 at 1:10 PM, lars.kn...@nokia.com wrote: Our main issue seem to be timing then. We currently have the opportunity of changing API to some extend before we freeze down things for Qt 5 again. Thus we'd need something relatively soon to be able to use it for 5.0. hmm, what stops us from moving QRegExp to an addon (somehow - how are we going to do this e.g. with the methods in QString?) and introducing new regular expressions support later? I guess it's a bit of an inconvenience, but it avoids slipping everything for one feature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
