On Wednesday 24 July 2002 05:42 am, Jeff 'japhy' Pinyan wrote:
> On Jul 24, [EMAIL PROTECTED] said:
> >Nicholas Clark <[EMAIL PROTECTED]> wrote:
> >:Is there an easy way any regexp internals guru can suggest to patch
> >: perl5's regexp code to disable the optimiser?
> >
> >At the moment, I suspec
On Tuesday 23 July 2002 02:43 pm, you wrote:
> On Tue, Jul 23, 2002 at 08:54:29PM +, Angel Faus wrote:
> > As a result of this bugfix, very simple regular expressions get a
> > noticable speed-up.
> >
> > For example, this is the data of matching the pattern /^zza/ against
> > "zzabcdc
On Thursday 06 June 2002 00:33, Hugo van der Sanden wrote:
> No, not attached. :)
>
> Just wanted to write down a thought I had during the discussion
> phase, about how someone might go about implementing it.
>
> This might be more obvious to someone who hasn't been corrupted
> by the p5 engine, b
With the addition of int_save and int_restore, I decided to test the
matching speed for the regex code I have been playing with. I tested
two versions of the regex matching code with only core ops, one using
the normal stack and one using the integer stack. All other aspects of
the code remained u
Steve Fink recently made it easy to test parrot under various runtime
options:
-g - suppress use of computed goto
-P - use prederef
-j - use JIT compiler
I was curious to see what effects these would have on regex timings
for the various schemes I cooked up. As before, I am using the t
In the interests of brevity, I cut huge tracts of quoted text.
On Mon, 6 May 2002, Brent Dax wrote:
> (FYI, I'm the main author of Parrot's rx package.)
>
I'm pleased to meet you.
> Mark Kvale:
> # Warning: this is a long message, a small paper really. The
...
Warning: this is a long message, a small paper really. The synopsis is
that I have created a simple regex compiler with multiple backends to
test proposed regex coding schemes. Details and test results are
below.
Hi all,
One of the upcoming decisions that needs to be made is on the design
of th
