Open question: What problems are there to add PCRE to Pike?
Sure it'd be nice to have a regexp package that groks wide strings but since Regexp isn't better in that regard there's nothing to lose.
Well, I started (that's why I rearranged the regexp module so that one can add Regexp.PCRE) but I didn't get my configure tests to work, so I didn't finish adding PCRE. Wide string support is there, sort of, if you use the utf-8 API, as you suggested. I don't have a good opinion yet if the configure should refuse to recognize PCRE without utf-8 support as a valid PCRE lib (as I said I never got this far).
It would also be good if someone more experienced took a look at the current regexp engine and made it null-safe.
/ Martin Nilsson (saturator)
Previous text:
2003-09-19 03:45: Subject: Adding PCRE to Pike
Open question: What problems are there to add PCRE to Pike?
Sure it'd be nice to have a regexp package that groks wide strings but since Regexp isn't better in that regard there's nothing to lose.
/ Martin Stjernholm, Roxen IS
On Fri, Sep 19, 2003 at 03:55:09AM +0200, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:
you use the utf-8 API, as you suggested. I don't have a good opinion yet if the configure should refuse to recognize PCRE without utf-8 support as a valid PCRE lib (as I said I never got this far).
The better would be to add an option (a flag?) to test if there is a wide string support, or even an exception if wide string is passed while there is no support.
BTW, is there any (draft) description of its API? :) It would be pity to have something restricted to existing API (match() without indication where it is found).
And... Hmm... I recall something related to utf-8 and PCRE... :)
---snip--- From: "Per Hedbor () @ Pike (-) developers forum" 10353@lyskom.lysator.liu.se Date: Wed, 29 Jan 2003 18:15:01 +0100 (CET)
Converting to and from UTF-8 is anything but light-weight, also, accessing and matching in UTF-8 strings is not O(1). ---snip---
No offense... :) But that was one (may be last) objection against :)
Regards, /Al
On Fri, Sep 19, 2003 at 04:18:32AM +0200, Alexander Demenshin wrote:
From: "Per Hedbor () @ Pike (-) developers forum" 10353@lyskom.lysator.liu.se Converting to and from UTF-8 is anything but light-weight, also, accessing and matching in UTF-8 strings is not O(1). ---snip--- No offense... :) But that was one (may be last) objection against :)
that is not an objection, just a note.
pike regexps are already really slow, i am sure this conversion won't result in pcre being slower than current regexps.
please alexander, stop taking every critical response as a rejection.
greetings, martin.
On Fri, Sep 19, 2003 at 04:26:43AM +0200, Martin Baehr wrote:
please alexander, stop taking every critical response as a rejection.
Please re-read that thread again - you will see that it was more than a "critical response". After all, you might name everything here as a "critical response", but often this is a hidden objection.
But OK, let's stop it... It was enough already, I guess...
Regards, /Al
pike regexps are already really slow, i am sure this conversion won't result in pcre being slower than current regexps.
Unless you have data to back that up, could you please stop the FUD. I have seen two regexp benchmarks comparing languages, and Pike performs favorably in both (10% slower than perl, 30% faster than python).
/ Martin Nilsson (saturator)
Previous text:
2003-09-19 04:27: Subject: Re: Adding PCRE to Pike
On Fri, Sep 19, 2003 at 04:18:32AM +0200, Alexander Demenshin wrote:
From: "Per Hedbor () @ Pike (-) developers forum" 10353@lyskom.lysator.liu.se Converting to and from UTF-8 is anything but light-weight, also, accessing and matching in UTF-8 strings is not O(1). ---snip--- No offense... :) But that was one (may be last) objection against :)
that is not an objection, just a note.
pike regexps are already really slow, i am sure this conversion won't result in pcre being slower than current regexps.
please alexander, stop taking every critical response as a rejection.
greetings, martin.
/ Brevbäraren
i had a script that was at least 100% slower if i used regexps compared to other methods in pike. (that was pike 7.0 i think) i can't find it right now though, it would be a good base to make a comparison against pcre.
greetings, martin.
That's not a comparision worth using however. Only shows regexp aren't the god given solution to all problems.
/ David Hedbor
Previous text:
2003-09-19 16:21: Subject: Re: Adding PCRE to Pike
i had a script that was at least 100% slower if i used regexps compared to other methods in pike. (that was pike 7.0 i think) i can't find it right now though, it would be a good base to make a comparison against pcre.
greetings, martin.
/ Brevbäraren
that should not matter if different regexp implementations are compared against each other.
greetings, martin.
If that was the case in "i had a script that was at least 100% slower if i used regexps compared to other methods in pike.", then you might have left out some relevant details here. :-)
/ Johan Sundström, Lysator
Previous text:
2003-09-19 16:57: Subject: Re: Adding PCRE to Pike
that should not matter if different regexp implementations are compared against each other.
greetings, martin.
/ Brevbäraren
That is what I meant. I only commented on you saying regexps was 100% slower than another solution.
/ David Hedbor
Previous text:
2003-09-19 16:57: Subject: Re: Adding PCRE to Pike
that should not matter if different regexp implementations are compared against each other.
greetings, martin.
/ Brevbäraren
Quite so. has_prefix() is about twice as fast as a regexp match for "^something", for instance, not counting the setup time to create a Regexp object. Knowing when to pick up your power drill and when to use some light handy tool will remain a practice worth picking up. :)
/ Johan Sundström, Lysator
Previous text:
2003-09-19 16:48: Subject: Re: Adding PCRE to Pike
That's not a comparision worth using however. Only shows regexp aren't the god given solution to all problems.
/ David Hedbor
There is however no good reason for has_prefix to be faster than ^something once it is compiled.
/ Martin Nilsson (saturator)
Previous text:
2003-09-19 17:00: Subject: Re: Adding PCRE to Pike
Quite so. has_prefix() is about twice as fast as a regexp match for "^something", for instance, not counting the setup time to create a Regexp object. Knowing when to pick up your power drill and when to use some light handy tool will remain a practice worth picking up. :)
/ Johan Sundström, Lysator
Regexps are always a bit slow, regardless of language. A solution without regexps is usually faster, regardless of language.
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2003-09-19 16:21: Subject: Re: Adding PCRE to Pike
i had a script that was at least 100% slower if i used regexps compared to other methods in pike. (that was pike 7.0 i think) i can't find it right now though, it would be a good base to make a comparison against pcre.
greetings, martin.
/ Brevbäraren
as you have stated yourself, it only takes a person to add the code to cvs.
greetings, martin.
On Fri, Sep 19, 2003 at 03:56:29AM +0200, Martin Baehr wrote:
it only takes a person to add the code to cvs.
Right... But it takes time too... I wonder when this might happen again (adding PCRE) if I wouldn' mention it again :P
And wow... This comes from the Pike team... Seems that my tactic isn't so bad ;)
Regards, /Al
Right... But it takes time too... I wonder when this might happen again (adding PCRE) if I wouldn' mention it again :P
As I said I worked on getting PCRE in this summer, but I gave up at first hint of problem since I personally don't care much about PCRE and had lots of other stuff to do. I was going to raise the issue at the conference and I have already put PCRE in on my things-to-do-before-7.6 slide.
And wow... This comes from the Pike team... Seems that my tactic isn't so bad ;)
It sucks.
/ Martin Nilsson (saturator)
Previous text:
2003-09-19 04:26: Subject: Re: Adding PCRE to Pike
On Fri, Sep 19, 2003 at 03:56:29AM +0200, Martin Baehr wrote:
it only takes a person to add the code to cvs.
Right... But it takes time too... I wonder when this might happen again (adding PCRE) if I wouldn' mention it again :P
And wow... This comes from the Pike team... Seems that my tactic isn't so bad ;)
Regards, /Al
/ Brevbäraren
Actually, your tactic is so good that it has placed you in the 'troll' category for me.
/ Per Hedbor ()
Previous text:
2003-09-19 04:26: Subject: Re: Adding PCRE to Pike
On Fri, Sep 19, 2003 at 03:56:29AM +0200, Martin Baehr wrote:
it only takes a person to add the code to cvs.
Right... But it takes time too... I wonder when this might happen again (adding PCRE) if I wouldn' mention it again :P
And wow... This comes from the Pike team... Seems that my tactic isn't so bad ;)
Regards, /Al
/ Brevbäraren
Actually, it's people like you that made me stop working on Pike. Arguing without any real contribution is a very efficient way of killing a project.
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2003-09-19 04:26: Subject: Re: Adding PCRE to Pike
On Fri, Sep 19, 2003 at 03:56:29AM +0200, Martin Baehr wrote:
it only takes a person to add the code to cvs.
Right... But it takes time too... I wonder when this might happen again (adding PCRE) if I wouldn' mention it again :P
And wow... This comes from the Pike team... Seems that my tactic isn't so bad ;)
Regards, /Al
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Alexander Demenshin -
David Hedbor ＠ Pike developers forum -
Fredrik (Naranek) Hubinette (Real Build Master) ＠ Pike (-) developers forum
-
Johan Sundstr�m, Lysator ＠ Pike developers forum
-
Martin Baehr -
Martin Nilsson (saturator) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Per Hedbor () ＠ Pike (-) developers forum