In preparation of more realistic regex opcodes (which will all be
prefixed with rx_), I've committed some changes to allow underscores in
op names. As it turned out, the only changes needed were to ops2c.pl
and friends; the assembler was already ready already.
--Brent Dax
[EMAIL PROTECTED]
Confi
Okay, I've got another argument for you: speed.
Basically, I took my current RE code, copied-and-pasted it, renamed the
ops a bit (s/rx_/rx2_/g), and modified each op to reflect the new
backtracking and push/pop meanings, doing the minimum amount of work on
each op that I could get away with. N
On Sun, Nov 25, 2001 at 02:32:34AM -0500, Angel Faus wrote:
> If there is interest in this
You bet! This is utterly wonderful. Angel, fantastic work, thanks.
I'll apply it soon.
--
I did write and prove correct a 20-line program in January, but I made
the mistake of testing it on our VAX and it
On Sun, Nov 25, 2001 at 12:57:19AM -0500, Jeff G wrote:
> Along with testing in t/op/pmc.t
Wait! This is all bogus. Not only do we need overflow checking, but
we also need to deal with the contingency that in, say,
add P1, P2, P3
the "value" PMC may not be an integer, and hence we have to p
On Sun, Nov 25, 2001 at 02:32:34AM -0500, Angel Faus wrote:
> use Text::Balanced 'extract_bracketed';
Urgh. We need to work around this.
--
If a 6600 used paper tape instead of core memory, it would use up tape
at about 30 miles/second.
-- Grishman, Assembly Language Programmin
If you're running a tinderbox client, you need to (at least temporarily)
install Text::Balanced, until we work around it. Thanks very much.
--
If the code and the comments disagree, then both are probably wrong.
-- Norm Schryer
> Okay, I've got another argument for you: speed.
>
That was a killer one.
>
> C:\Brent\VISUAL~1\PERL6~1\parrot\parrot>rebench.pl
> Explicit backtracking: 75 iterations, about 30.5380001068115
> seconds.
> Implicit backtracking: 75 iterations, about 655.510995864868
> seconds.
>
> The nu
On Sun, 25 Nov 2001 13:14:22 +, Simon Cozens wrote:
>On Sun, Nov 25, 2001 at 02:32:34AM -0500, Angel Faus wrote:
>> use Text::Balanced 'extract_bracketed';
>
>Urgh. We need to work around this.
Can somebody fill me in exactly how this is supposed to behave?
I think that this may come close
Simon Cozens wrote:
>
> On Sun, Nov 25, 2001 at 12:57:19AM -0500, Jeff G wrote:
> > Along with testing in t/op/pmc.t
>
> Wait! This is all bogus. Not only do we need overflow checking, but
> we also need to deal with the contingency that in, say,
>
> add P1, P2, P3
>
> the "value" PMC may
Dan Sugalski:
# Sent: Sunday, November 25, 2001 11:48
# To: Brent Dax
# Cc: Angel Faus; [EMAIL PROTECTED]
# Subject: RE: Re: [Proposal] Regex documentation
#
#
# On Sun, 25 Nov 2001, Brent Dax wrote:
#
# > Unfortunately, because Parrot currently has no GC system
# and thus leaks
# > all over the p
I realize that benchmarking the RE engine's a pain, what with no GC so we
leak until we blow memory and die, but...
I'd like to take a series of regexes that exercise various bits of the
perl 5 engine and time them against the equivalent perl 6 RE code. I think
it's important at this point to see
Dan Sugalski:
# I realize that benchmarking the RE engine's a pain, what with
# no GC so we
# leak until we blow memory and die, but...
#
# I'd like to take a series of regexes that exercise various bits of the
# perl 5 engine and time them against the equivalent perl 6 RE
# code. I think
# it's i
On Sunday 25 November 2001 10:34 pm, Brent Dax wrote:
> Perl 5's REs will always appear faster because Perl 5 has an
> intelligent, optimizing regex compiler. For example, take the following
> simple regex:
>
> /a+bc+/
>
> pregcomp will optimize that by searching for a 'b' and working outwa
Bryan C. Warnock:
# On Sunday 25 November 2001 10:34 pm, Brent Dax wrote:
# > Perl 5's REs will always appear faster because Perl 5 has an
# > intelligent, optimizing regex compiler. For example, take
# the following
# > simple regex:
# >
# > /a+bc+/
# >
# > pregcomp will optimize that by sea
On Sunday 25 November 2001 11:09 pm, Brent Dax wrote:
> Not exactly.
>
> C:\perl572\perl\win32>perl -mre=debug -e "print 'xaaabx'=~/a+bc+/"
>
> Guessing start of match, REx `a+bc+' against `xaaabx'...
> Found floating substr `abc' at offset 3...
> Found anchored substr `a' at offset 1
Allows the following operations to work:
new P0,0
new P1,0
set P0,3
set P1,-3.65
add P1,P0,P1
print P1
end
I'll add appropriate string conversions some time this week.
Numeric operations are finicky enough that it's probably not worth
attempting to do down-conversion from numeric back t
Bryan C. Warnock:
# On Sunday 25 November 2001 11:09 pm, Brent Dax wrote:
# > Not exactly.
# > It finds the 'a', then the 'abc', then tries the match. My mistake.
# > Still, that's a hell of a lot more intelligent than just 'proceeding
# > dumbly left-to-right'.
#
# It shows up better if you thr
On Sun, Nov 25, 2001 at 11:32:51AM -0500, Jeff G wrote:
> Yes we do, and I agree, but I wasn't able to figure out how to load in
> the PerlNum class
Uncomment the following line in global_setup.c:
/* Parrot_PerlNum_class_init(); */
But put some methods in it first. :)
Simon
--
I decided t
Okay, the Darwin box I've got here has pretty much everything perlish on
it I can think of. (Well, 5.6.0 perl at least--it's what comes
pre-installed, and I'm not sure I can get and reinstall any
Darwin-specific perl modules that come with it) I know that builds will
guaranteed fail on the machine
On Sun, 25 Nov 2001, Brent Dax wrote:
> Unfortunately, because Parrot currently has no GC system and thus leaks
> all over the place
I'll see about fixing that.
> and for some reason trying to mem_sys_free() the RE
> handle's stack sometimes segfaults the interpreter,
I know what that problem
20 matches
Mail list logo
