Re: S03 - Str autodecrement

"Patrick R. Michaud" <[EMAIL PROTECTED]> wrote: :Howeven, "returns a Failure object" in this context (autodecrement) :still seems a bit ambiguous, because the return values of autoincrement :and autodecrement are often ignored, as in: : :my $s = 'A00'; :$s--; :say $s; : :So, what happen

Re: Octal in p6rules (and strings)

"Patrick R. Michaud" <[EMAIL PROTECTED]> wrote: :And we also get \d:0123 as a cheap way of saying \d0123. I think the ':' changes the meaning of the rule, so you still need '\d0123' (or preferably something shorter) for the uncut semantic. Hugo

Re: [pugs] regexp "bug"?

"Mark A. Biggar" <[EMAIL PROTECTED]> wrote: :BÁRTHÁZI András wrote: : :> Hi, :> :> This code: :> :> my $a='A'; :> $a ~~ s:perl5:g/A/{chr(65535)}/; :> say $a.bytes; :> :> Outputs "0". Why? :> :> Bye, :> Andras :> : :\u is not a legal unicode codepoint. chr(65535) should raise an :except

Re: PGE tests wanted (was P6GE tests wanted)

Larry Wall <[EMAIL PROTECTED]> wrote: :Henry Spencer's original regex routines simply disallowed expressions :that might be infinite. We tried relaxing that in Perl 5, and got :it wrong more than one way. I'm not actually sure what approach p5 :takes right now, if any. We detect and warn of repe

Re: Current state?

"Patrick R. Michaud" <[EMAIL PROTECTED]> wrote: :How does p5 do it? Brokenly. It looks for balanced curlies unintelligently; try: perl -we '/(?{ "})" })/' I'd expect p6 rules to be parsed using a grammar, and within such a context to invoke the 'closure' rule; it's that rule that'd have the res

Re: Updates to modules-related pod

Kirrily Skud Robert <[EMAIL PROTECTED]> wrote: :Here's an initial patch to perlnewmod Thank you. : =item Get a CPAN user ID : :-Every developer publishing modules on CPAN needs a CPAN ID. See the :-instructions at C (or :-equivalent on your nearest mirro

Re: benchmarking - it's now all(-1,0,1,5,6)% faster

Dunno where this 'from' line came from, but it says here: [EMAIL PROTECTED] wrote: :On Sun, Jan 12, 2003 at 10:24:23AM +0100, Leopold Toetsch wrote: :all default to a machine dependent default. This default isn't documented :explicitly, but I presume that on x86 it's the same as the x86 specific -m

Re: benchmarking - it's now all(-1,0,1,5,6)% faster

Nicholas Clark <[EMAIL PROTECTED]> wrote: :So I'm confused. It looks like some bits of perl are incredibly sensitive to :cache alignment, or something similar. And as a consequence, perlbench is :reliably reporting wildly varying timings because of this, and because it :only tries a few, very speci

Re: perl5 regexp optimiser (was Re: [perl #15425] Regex bugfix and speed-up)

"Jeff 'japhy' Pinyan" <[EMAIL PROTECTED]> 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 suspect not. :> :>This is s

Re: perl5 regexp optimiser (was Re: [perl #15425] Regex bugfix and speed-up)

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 suspect not. This is something I hope we can make easier in the 5.9 track. Hugo