Re: [Development] Unicode/i18n support

On 4 December 2011 21:16, Sylvain Pointeau wrote: > Hi, > > would it be possible to have the code somewhere in git on gitorious or > github? > I would like to contribute by adding boost regexp... Since you're there, could you please help me in keeping http://developer.qt.nokia.com/wiki/Regexp_eng

Re: [Development] Unicode/i18n support

On 5 December 2011 10:49, Sylvain Pointeau wrote: > sorry, I made a mistake: > RE2 does not support arbitrary lookahead or lookbehind assertions, nor does > it support backreferences TBH, it does not support lookaheads or lookbehinds at all -- not only "arbitrary" ones, which usually means unboun

Re: [Development] Unicode/i18n support

On 4 December 2011 21:16, Sylvain Pointeau wrote: > Hi, > > would it be possible to have the code somewhere in git on gitorious or > github? > I would like to contribute by adding boost regexp... > > after all, boost could be also interesting, you can anyway embed it in qt to > avoid the binary br

Re: [Development] Unicode/i18n support

sorry, I made a mistake: RE2 does not support arbitrary lookahead or lookbehind assertions, nor does it support backreferences This was definitely making RE2 out in one of our previous discussion on regexp. ___ Development mailing list Development@qt-pro

Re: [Development] Unicode/i18n support

I understood that re2 couldn't be in the list because it does not support backtracking. am I wrong? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Unicode/i18n support

Yes, please. I think it's important that we can all have a look at the benchmark and also check what exactly is being tested. And let's also add re2 to to the list. Cheers, Lars On 12/4/11 1:16 PM, "ext Sylvain Pointeau" wrote: >Hi, >would it be possible to have the code somewhere in git on g

Re: [Development] Unicode/i18n support

Hi, would it be possible to have the code somewhere in git on gitorious or github? I would like to contribute by adding boost regexp... after all, boost could be also interesting, you can anyway embed it in qt to avoid the binary break. boost regexp can rely on ICU for unicode, let's see how it c

Re: [Development] Unicode/i18n support

On 1 December 2011 14:44, Giuseppe D'Angelo wrote: > I'll do some other benchmarks later... Robin kindly reminded me that I forgot the baseline, i.e. QRegExp in Qt4 :-) * Start testing of REBenchmark * Config: Using QTest library 4.7.4, Qt 4.7.4 PASS : REBenchmark::initTestCase

Re: [Development] Unicode/i18n support

On 1 December 2011 09:13, Sylvain Pointeau wrote: > and if you remove the jit compile from PCRE? is it closer to ICU? Studying the pattern, without JIT: * Start testing of REBenchmark * Config: Using QTest library 4.7.4, Qt 4.7.4 PASS : REBenchmark::initTestCase() RESULT : REBe

Re: [Development] Unicode/i18n support

and if you remove the jit compile from PCRE? is it closer to ICU? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Unicode/i18n support

2011/11/29 Thiago Macieira : > On Friday, 25 de November de 2011 08.30.56, lars.kn...@nokia.com wrote: >> My proposal would be to simplify this setup and start relying on ICU for >> many of the tasks. We would still expose things through a Qt API though. >> It would simplify the maintenance of our

Re: [Development] Unicode/i18n support

On Tuesday, 29 de November de 2011 21.41.58, John Layt wrote: > I'm generally in favour, even if it means throwing away most of my work > from the last few months :-) In QLocale it will definitely save us a lot > of code and maintenance , give advanced features at no extra cost, and > solves the l

Re: [Development] Unicode/i18n support

On 25 November 2011 08:30, wrote: > I have been thinking a bit on how to move forward with Unicode support in > Qt lately. The current state is in my opinion not sustainable. > > Unicode and i18n support consists of quite a few different tasks. Roughly > speaking, we currently have a handful of

Re: [Development] Unicode/i18n support

On Friday, 25 de November de 2011 08.30.56, lars.kn...@nokia.com wrote: > My proposal would be to simplify this setup and start relying on ICU for > many of the tasks. We would still expose things through a Qt API though. > It would simplify the maintenance of our Unicode support, as we can rely >

Re: [Development] Unicode/i18n support

Hi, Boost in the latest version (1.48 released on 15th November 2011 ) added the Locale library, which can provide ICU or non-ICU locale support. Not necessarily use

Re: [Development] Unicode/i18n support

On 11/25/11 11:42 AM, "ext Thiago Macieira" wrote: >On Friday, 25 de November de 2011 10:54:59 Simon Hausmann wrote: >> > At the same time I'd propose to (over time) get rid of relying on >>glibc, >> > windows and Mac specific APIs as much as possible. We could also >>remove >> > most Unicode rel

Re: [Development] Unicode/i18n support

but if you are moving to using ICU, you could use as well the regexp from ICU, do you still want to use PCRE then? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Unicode/i18n support

On Friday, 25 de November de 2011 10:54:59 Simon Hausmann wrote: > > At the same time I'd propose to (over time) get rid of relying on glibc, > > windows and Mac specific APIs as much as possible. We could also remove > > most Unicode related data tables in Qt and only keep the ones that are > > pe

Re: [Development] Unicode/i18n support

On Friday, November 25, 2011 08:30:56 AM ext lars.kn...@nokia.com wrote: > Hi, > > I have been thinking a bit on how to move forward with Unicode support in > Qt lately. The current state is in my opinion not sustainable. > > Unicode and i18n support consists of quite a few different tasks. Rough

[Development] Unicode/i18n support

Hi, I have been thinking a bit on how to move forward with Unicode support in Qt lately. The current state is in my opinion not sustainable. Unicode and i18n support consists of quite a few different tasks. Roughly speaking, we currently have a handful of places where Unicode data and support han