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 happens in the above? Does $s become a Failure object? :Does autodecrement recognize that it's in void context and thus :becomes immediately fatal? I'm not sure what the answer is, but it should be the same as for: my $s = 0; $s = 1 / $s; say $s; In both cases, it is a domain error. Hugo
Re: Octal in p6rules (and strings)
Patrick R. Michaud [EMAIL PROTECTED] wrote: :And we also get \d:0123 as a cheap way of saying \d?null0123. I think the ':' changes the meaning of the rule, so you still need '\d?null0123' (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
:exception of some type. So the above code does seem show a possible
:bug. But as that chr(65535) is an undefined char, who knows what the
:code is acually doing.
In perl5 at least, we support a wider concept of codepoints than the
Unicode consortium. This allows us to use strings for a wider variety
of things than just Unicode text (eg version strings, bit vectors etc).
In perl6 the greatly expanded set of types will presumably allow us
to distinguish actual Unicode data from more arbitrary sequences of
codepoints, and I'd normally expect that the more constrained type
would be a subtype of the less constrained type. In this case that
means I'd expect Unicode string to be a subtype of something like
codepoint sequence.
(In fact it'd probably be useful to have more levels than that - there
are times when you need the Unicode concepts for things like [[:digit:]],
but may be able to get better performance by avoiding the checks for
'legal Unicode codepoint'.)
On the other hand you will probably be able to achieve the things p5
overloads onto strings using packed integer arrays, so maybe this all
represents unnecessary complications. In which case maybe 'relaxed'
variants of Unicode strings aren't needed. We will probably still want
other sorts of strings though, such as ASCII.
Hugo
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 repeated empty expressions:
zen% perl -wle 'print ok if x =~ /()*/'/'
()* matches null string many times in regex; marked by -- HERE in m/()* --
HERE / at -e line 1.
ok
zen%
For optionally empty expressions, we don't allow them to match emptily
more than once:
zen% perl -wle 'while (baa =~ /((b??)*a)/g) { print $1 }'
ba
a
zen%
For optionally empty patterns, we don't allow them to match emptily at
the same location more than once:
zen% perl -wle 'while (a =~ /(a??)/g) { print $1 }'
a
zen%
This last is achieved by magic on the string to which the pattern is
applied, which can lead to problematic interactions with other magic
(eg tainting) or restoration after local(). In principle it may also
be undesirable if you are parsing a string with a variety of //gc
patterns, and want to allow more than one of them to match an empty
string at the same location.
Hugo
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 responsibility of knowing where to start and stop, and what
language it's supposed to be reading. I'd expect it to discover
the language initially from independent contextual information
(ie C use rx deflang('PIR') ), but be able to switch based on
the string being parsed (ie C m/{use grammar 'PIR'; ...}/ ).
It does get tricky if the language you're parsing does (or can) use
'}' in an unbalanced manner, the equivalent of a perl5/6 TERM
starting with a '}' that didn't close a previous '{' - I don't know
how you'd decide in that case which '}' terminates the closure, but
that's a problem for the grammar implementing 'closure' in that
language, not for the 'rule' parser per se. I think that simply
means that not every language can embed every language in this way.
Hugo
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 Chttp://www.cpan.org/modules/04pause.html (or :-equivalent on your nearest mirror) to find out how to do this. :+Every developer publishing modules on CPAN needs a CPAN ID. Visit :+Chttp://pause.perl.org/, select Request PAUSE Account, and wait for :+your request to be approved by the PAUSE administrators. 04pause.html has some useful and important information people should probably read before requesting an account. : =item Cperl Makefile.PL; make test; make dist : :-Once again, Ch2xs has done all the work for you. It produces the :-standard CMakefile.PL you'll have seen when you downloaded and :-installs modules, and this produces a Makefile with a Cdist target. :+Once again, Cmodule-starter or Ch2xs has done all the work for you. :+They produce the standard CMakefile.PL you'll have seen when you :+downloaded and installs modules, and this produces a Makefile with a :+Cdist target. ... you see when you download and install modules. Hugo
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 :options of the same name (deprecated in gcc 3.0, removed along with their :documentation by 3.2) : :*Their* alignment defaults are: : :`-malign-loops=NUM' : Align loops to a 2 raised to a NUM byte boundary. If : `-malign-loops' is not specified, the default is 2 unless gas 2.8 : (or later) is being used in which case the default is to align the : loop on a 16 byte boundary if it is less than 8 bytes away. : :so : :50% of the time your function/label/loop/jump is 16 byte aligned. :50% of the time your function/label/loop/jump is randomly aligned I read this differently: 16n+7 should be aligned to 16n, because it is less than 8 bytes away; 16n+9 should be aligned 16n+16 similarly. Only 16n+8 would be unaligned, so that only in 1/16 random cases would it fail to be 16-byte aligned, and then it would still be 8-byte aligned. That doesn't necessarily invalidate any of the rest of what was said. Hugo
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 specific things. Does this mean that it's still useful? I think I remember seeing a profiler that emulates the x86 instruction set, and so can give theoretically exact timings. Does this ring a bell for anyone? I don't know if the emulation extended to details such as RAM and cache sizes ... Hugo
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 something I hope we can make easier in the 5.9 track. : :Couldn't I just make S_studychunk return some dummy values? I looked at :it, and I'm pretty sure I could do it. It won't be easy for me to check until I'm back home next week, but I believe that we amass optimisation information in several other places, and use it in many places. Hugo
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
