On 3 December 2011 22:39, 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 int
>
>
> That would at the same time imply that anybody can add any regexp engine
> as an add-on to Qt, and we should be careful about the one we put into
> QtCore. I believe the most important points for inclusion into QtCore are
> speed, small footprint (RAM and ROM) and being reentrant. I am less
>
The benchmark numbers mentioned on
http://public.kitware.com/pipermail/cmake-developers/2011-November/002547.h
tml
is something we shouldn't simply ignore.
It sounds like Re2 is worth looking into. Do we have any information about
size and performance of that one?
In general we will need to allow
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/ab
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 a
On Fri, Nov 25, 2011 at 09:28:18AM +0100, ext João Abecasis wrote:
> What is the use case for *not* compiling in the constructor?
>
it makes use of the property-based api inefficient.
> And how is an uncompiled Regular Expression object different from,
> say, a QString?
>
it has some parameters,
On Nov 25, 2011, at 4:50 AM, ext Giuseppe D'Angelo wrote:
> On 24 November 2011 22:49, Oswald Buddenhagen
> wrote:
>> On Wed, Nov 23, 2011 at 03:35:57PM +0100, ext Thiago Macieira wrote:
>>> At first thought, I'd say that the pattern class should be a regular,
>>> implicitly-shared, atomic copy-
On 11/25/11 5:03 AM, "ext Giuseppe D'Angelo" wrote:
>2011/11/23 Thiago Macieira :
>> Question: where does it get its Unicode tables from? Are they compiled
>>in, or
>> does it link to another library, such as ICU?
>>
>> Here, my libpcre links to nothing but libc.
>
>Same here. They're internal ta
On Friday 25 November 2011 03:50:37 Giuseppe D'Angelo wrote:
> On 24 November 2011 22:49, Oswald Buddenhagen
>
> wrote:
> > On Wed, Nov 23, 2011 at 03:35:57PM +0100, ext Thiago Macieira wrote:
> >> At first thought, I'd say that the pattern class should be a regular,
> >> implicitly-shared, atomi
2011/11/23 Thiago Macieira :
> Question: where does it get its Unicode tables from? Are they compiled in, or
> does it link to another library, such as ICU?
>
> Here, my libpcre links to nothing but libc.
Same here. They're internal tables, f.i. pcre_ucd.c
http://vcs.pcre.org/viewvc/code/trunk/pcr
On 24 November 2011 22:49, Oswald Buddenhagen
wrote:
> On Wed, Nov 23, 2011 at 03:35:57PM +0100, ext Thiago Macieira wrote:
>> At first thought, I'd say that the pattern class should be a regular,
>> implicitly-shared, atomic copy-on-write value class. If you call a non-const
>> method, it detache
On Thursday, 24 de November de 2011 23:49:02 Oswald Buddenhagen wrote:
> On Wed, Nov 23, 2011 at 03:35:57PM +0100, ext Thiago Macieira wrote:
> > At first thought, I'd say that the pattern class should be a regular,
> > implicitly-shared, atomic copy-on-write value class. If you call a
> > non-cons
On Wed, Nov 23, 2011 at 03:35:57PM +0100, ext Thiago Macieira wrote:
> At first thought, I'd say that the pattern class should be a regular,
> implicitly-shared, atomic copy-on-write value class. If you call a non-const
> method, it detaches.
>
> There should be no const methods that modify inte
On 11/23/11 3:30 PM, "ext Thiago Macieira" 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
On Wednesday, 23 de November de 2011 15:48:41 Robin Burchell wrote:
> 2011/11/23 Thiago Macieira :
> > 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
2011/11/23 Thiago Macieira :
> 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 differ
On Wednesday, 23 de November de 2011 08:33:35 craig.sc...@csiro.au wrote:
> I don't think you need to install these static libraries (although it won't
> do any harm if you do). The main need is for Qt to use it internally, not
> to expose anything from it through its API. That makes the use of PCR
On Tuesday, 22 de November de 2011 15:07:46 Giuseppe D'Angelo wrote:
> On 32bit Linux:
>
>text data bss dec hex filename
> 387691 728 176 388595 5edf3 libpcre-
jit/lib/libpcre.so
> 260245 580 12 260837 3fae5 libpcre/lib/libpcre.so
> 15
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
On 22/11/2011, at 9:55 PM, Thiago Macieira wrote:
> 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 lib
On 22 November 2011 01:11, wrote:
> I would suggest that the Qt source should include its own local copy of pcre
> and a configure time switch should allow selection between the system or the
> local (Qt source) version of pcre. This is already the approach offered for
> things like image-rela
On 21 November 2011 21:25, wrote:
>>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?
On 32bit Linux:
textdata bss dec
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 kee
On 11/22/11 2:11 AM, "ext craig.sc...@csiro.au"
wrote:
>
>On 22/11/2011, at 2:45 AM, Giuseppe D'Angelo wrote:
>
>> On 16 November 2011 16:08, wrote:
>>> Yes, the implementation based on UTF-8 vs UTF-16 version of PCRE would
>>> only differ on two lines, the UTF-16 -> UTF-8 and UTF-8 > UTF-16
>>
On 22/11/2011, at 2:45 AM, Giuseppe D'Angelo wrote:
> On 16 November 2011 16:08, wrote:
>> Yes, the implementation based on UTF-8 vs UTF-16 version of PCRE would
>> only differ on two lines, the UTF-16 -> UTF-8 and UTF-8 > UTF-16
>> conversion before and after the matching.
>>
>> I suggest we
On 11/21/11 6:29 PM, "ext Thiago Macieira" 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
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 f
On 16 November 2011 16:08, wrote:
> Yes, the implementation based on UTF-8 vs UTF-16 version of PCRE would
> only differ on two lines, the UTF-16 -> UTF-8 and UTF-8 > UTF-16
> conversion before and after the matching.
>
> I suggest we get started on this with the current version of PCRE, and
> ho
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/), an
On 11/11/11 7:24 AM, "ext Giuseppe D'Angelo" wrote:
>On 11 November 2011 12:32, Robin Burchell wrote:
>> hi,
>>
>> On Fri, Nov 11, 2011 at 1:10 PM, wrote:
>>> Our main issue seem to be timing then. We currently have the
>>>opportunity
>>> of changing API to some extend before we freeze down th
On 11 November 2011 12:32, Robin Burchell wrote:
> hi,
>
> On Fri, Nov 11, 2011 at 1:10 PM, 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 soo
hi,
On Fri, Nov 11, 2011 at 1:10 PM, 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
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. Th
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 UT
34 matches
Mail list logo
