Re: [perl #43171] [TODO] replace the value for $(MAKE) with the actual path (config/inter/make.pm)
On Sep 6, 2007, at 7:52 PM, James Keenan via RT wrote:
On Fri Jun 08 06:48:12 2007, ptc wrote:
In the file config/inter/make.pm, there is the following todo item:
# FIXME this is an ugly hack
# replace the value for $(MAKE) with the actual path or we'll
end up
# with a variable that recursively refers to itself
This problem needs to be corrected.
Problem: It can only be corrected by someone who does NOT have any
version of gmake on his/her box. Why? Look at the block of code in
which this comment is embedded:
if ( $conf->data->get('gmake_version') ) {
$conf->data->set( make_c => "$prog -C" );
}
else {
# get the default value
my $make_c = $conf->data->get('make_c');
# RT#43171 this is an ugly hack
# replace the value for $(MAKE) with the actual path or we'll
end up
# with a variable that recursively refers to itself
$make_c =~ s/\$\(MAKE\)/$prog/;
$conf->data->set( make_c => $make_c );
}
Only someone completely lacking a gmake would reach the 'else' block,
and only such a person would be in a position to write a test for
anything that would replace \$\(MAKE\).
Can anyone do that? Otherwise, I will mark the ticket as STALLED.
kid51
How does $(MAKE) get into make_c anyway? Here's a couple prints I
added.
Before substitution:
prog = make
make_c = $(PERL) -e 'chdir shift @ARGV; system q{$(MAKE)}, @ARGV; exit
$$? >> 8;'
After substitution:
make_c = $(PERL) -e 'chdir shift @ARGV; system q{make}, @ARGV; exit
$$? >> 8;'
Oh, and I do have gmake installed, I just don't use it.
Re: mod_perl6 update
http://perlbuzz.com/project-hum/2007/09/first-mod-perl6-handlers.html -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
[svn:perl6-synopsis] r14453 - doc/trunk/design/syn
Author: larry Date: Thu Sep 6 20:56:39 2007 New Revision: 14453 Modified: doc/trunk/design/syn/S03.pod Log: fixed it right this time... Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podThu Sep 6 20:56:39 2007 @@ -3632,7 +3632,7 @@ If you already have a capture variable, you can interpolate all of its bits at once using the C<< prefix:<|> >> operator: -my $capture := func(); +my (|$capture) := func(); push |$capture; =head1 Traversing arrays in parallel
Re: [svn:perl6-synopsis] r14447 - doc/trunk/design/syn
On Thu, Sep 06, 2007 at 08:32:55PM -0400, Joe Gottman wrote: : Do the results of andthen and orelse really bind to ANY arguments of : the second block? If the second block has two parameters it makes more : sense to me for the results to bind to the first parameter and nothing : to bind to the second parameter. I suspect the left side is a Capture context, so test1() could return multiple arguments to be bound to the right side. In any case, if test1() calls fail() then the orelse should fail regardless of whether the orelse is in list or scalar context. Should probably make the orelse itself fail if the binding doesn't work too. Larry
[svn:perl6-synopsis] r14452 - doc/trunk/design/syn
Author: larry Date: Thu Sep 6 20:50:04 2007 New Revision: 14452 Modified: doc/trunk/design/syn/S03.pod Log: extra \ found by sunnavy++ Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podThu Sep 6 20:50:04 2007 @@ -3632,7 +3632,7 @@ If you already have a capture variable, you can interpolate all of its bits at once using the C<< prefix:<|> >> operator: -my \$capture := func(); +my $capture := func(); push |$capture; =head1 Traversing arrays in parallel
[svn:perl6-synopsis] r14451 - doc/trunk/design/syn
Author: larry Date: Thu Sep 6 20:36:26 2007 New Revision: 14451 Modified: doc/trunk/design/syn/S03.pod Log: typo spotted by sunnavy++ Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podThu Sep 6 20:36:26 2007 @@ -2830,7 +2830,7 @@ with C<+>, C<~> and C respectively to indicate whether the bitwise operation is done on a number, a string, or a single bit. But that's just a naming convention, and if you wanted to add a new -bitwise C<¬> operator, you'd have the add the C<+¬>, C<~¬>, and C +bitwise C<¬> operator, you'd have to add the C<+¬>, C<~¬>, and C operators yourself. Similarly, the carets that exclude the endpoints on ranges are there by convention only.
[perl #43315] [TODO] config/inter/lex.pm: Write unit tests
Please review the patch attached, which consists of 5 new test files:
t/configure/109-inter_lex.01.t
... thru ...
t/configure/109-inter_lex.05.t
... as well as a refactored config/inter/lex.pm. The refactorings had
as their objectives (a) eliminating untestable parts of conditions; and
(b) providing a way to rig up tests of code depending on settings of
environmental values.
Feedback welcome on OSes other than Darwin and Linux. Thank you very much.
kid51
Index: MANIFEST
===
--- MANIFEST(revision 21118)
+++ MANIFEST(working copy)
@@ -1,7 +1,7 @@
# ex: set ro:
# $Id$
#
-# generated by tools/dev/mk_manifest_and_skip.pl Thu Sep 6 19:17:40 2007 UT
+# generated by tools/dev/mk_manifest_and_skip.pl Fri Sep 7 02:52:21 2007 UT
#
# See tools/dev/install_files.pl for documentation on the
# format of this file.
@@ -2928,6 +2928,11 @@
t/configure/106-init_headers.t []
t/configure/107-inter_progs.01.t[]
t/configure/107-inter_progs.02.t[]
+t/configure/109-inter_lex.01.t []
+t/configure/109-inter_lex.02.t []
+t/configure/109-inter_lex.03.t []
+t/configure/109-inter_lex.04.t []
+t/configure/109-inter_lex.05.t []
t/configure/testlib/Make_VERSION_File.pm[]
t/configure/testlib/Tie/Filehandle/Preempt/Stdin.pm []
t/configure/testlib/init/alpha.pm []
Index: t/configure/109-inter_lex.01.t
===
--- t/configure/109-inter_lex.01.t (revision 0)
+++ t/configure/109-inter_lex.01.t (revision 0)
@@ -0,0 +1,80 @@
+#! perl
+# Copyright (C) 2007, The Perl Foundation.
+# $Id$
+# 109-inter_lex.01.t
+
+use strict;
+use warnings;
+use Test::More tests => 12;
+use Carp;
+use lib qw( lib t/configure/testlib );
+use_ok('config::init::defaults');
+use_ok('config::inter::lex');
+use Parrot::Configure;
+use Parrot::Configure::Options qw( process_options );
+use Parrot::IO::Capture::Mini;
+use Parrot::Configure::Test qw( test_step_thru_runstep);
+
+my $args = process_options( {
+argv=> [ q{--ask} ],
+mode=> q{configure},
+} );
+
+my $conf = Parrot::Configure->new();
+
+test_step_thru_runstep($conf, q{init::defaults}, $args);
+
+my ($task, $step_name, @step_params, $step, $ret);
+my $pkg = q{inter::lex};
+
+$conf->add_steps($pkg);
+$conf->options->set(%{$args});
+$task = $conf->steps->[1];
+$step_name = $task->step;
[EMAIL PROTECTED] = @{ $task->params };
+
+$step = $step_name->new();
+ok(defined $step, "$step_name constructor returned defined value");
+isa_ok($step, $step_name);
+ok($step->description(), "$step_name has description");
+$ret = $step->runstep($conf);
+ok(defined $ret, "$step_name runstep() returned defined value");
+is($step->result(), q{skipped},
+"Step was skipped as expected; no '--maintainer' option");
+
+pass("Completed all tests in $0");
+
+### DOCUMENTATION ###
+
+=head1 NAME
+
+109-inter_lex.01.t - test config::inter::lex
+
+=head1 SYNOPSIS
+
+% prove t/configure/109-inter_lex.01.t
+
+=head1 DESCRIPTION
+
+The files in this directory test functionality used by F.
+
+The tests in this file test subroutines exported by config::inter::lex. In
+this case, only the C<--ask> option is provided. Because the C<--maintainer>
+option is not provided, the step is skipped and no prompt is ever reached.
+
+=head1 AUTHOR
+
+James E Keenan
+
+=head1 SEE ALSO
+
+config::inter::lex, F.
+
+=cut
+
+# Local Variables:
+# mode: cperl
+# cperl-indent-level: 4
+# fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:
Property changes on: t/configure/109-inter_lex.01.t
___
Name: svn:mime-type
+ text/plain
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Index: t/configure/109-inter_lex.02.t
===
--- t/configure/109-inter_lex.02.t (revision 0)
+++ t/configure/109-inter_lex.02.t (revision 0)
@@ -0,0 +1,84 @@
+#! perl
+# Copyright (C) 2007, The Perl Foundation.
+# $Id$
+# 109-inter_lex.02.t
+
+use strict;
+use warnings;
+use Test::More tests => 12;
+use Carp;
+use lib qw( lib t/configure/testlib );
+use_ok('config::init::defaults');
+use_ok('config::inter::lex');
+use Parrot::Configure;
+use Parrot::Configure::Options qw( process_options );
+use Parrot::Configure::Test qw( test_step_thru_runstep);
+
+$ENV{LEX} = 'foobar';
+
+my $args = process_options( {
+argv=> [ q{--ask}, q{--maintainer} ],
+mode=> q{configure},
+} );
+
+my $conf = Parrot::Configure->new();
+
+test_step_thru_runstep($conf, q{init::defaults}, $args);
+
+my ($tas
[svn:perl6-synopsis] r14450 - doc/trunk/design/syn
Author: larry Date: Thu Sep 6 19:29:21 2007 New Revision: 14450 Modified: doc/trunk/design/syn/S05.pod Log: typo from [particle]++ Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podThu Sep 6 19:29:21 2007 @@ -1280,7 +1280,7 @@ # match a letter and capture in $ <+alpha># match a letter, don't capture -# much null before a letter, don't capture +# match null before a letter, don't capture =item *
[perl #43327] [TODO] config/inter/make.pm: Write unit tests
Here is a new file for the purpose of testing config::inter::make. Due
to the fact that anyone who is running Parrot tests is highly likely to
have some version of 'make' on his/her box and is almost as likely to
have a version of 'gmake' there, it will be very hard to achieve
coverage of very branch and condition in config/inter/make.pm.
Please review. I'll commit to trunk in about 3 days if there is no
objection. Thank you very much.
kid51
Index: MANIFEST
===
--- MANIFEST(revision 21118)
+++ MANIFEST(working copy)
@@ -1,7 +1,7 @@
# ex: set ro:
# $Id$
#
-# generated by tools/dev/mk_manifest_and_skip.pl Thu Sep 6 19:17:40 2007 UT
+# generated by tools/dev/mk_manifest_and_skip.pl Fri Sep 7 01:07:33 2007 UT
#
# See tools/dev/install_files.pl for documentation on the
# format of this file.
@@ -2928,6 +2928,7 @@
t/configure/106-init_headers.t []
t/configure/107-inter_progs.01.t[]
t/configure/107-inter_progs.02.t[]
+t/configure/108-inter_make.t[]
t/configure/testlib/Make_VERSION_File.pm[]
t/configure/testlib/Tie/Filehandle/Preempt/Stdin.pm []
t/configure/testlib/init/alpha.pm []
Index: t/configure/108-inter_make.t
===
--- t/configure/108-inter_make.t(revision 0)
+++ t/configure/108-inter_make.t(revision 0)
@@ -0,0 +1,94 @@
+#! perl
+# Copyright (C) 2007, The Perl Foundation.
+# $Id$
+# 108-inter_make.t
+
+use strict;
+use warnings;
+use Test::More tests => 13;
+use Carp;
+use lib qw( lib t/configure/testlib );
+use_ok('config::init::defaults');
+use_ok('config::inter::make');
+use Parrot::Configure;
+use Parrot::Configure::Options qw( process_options );
+use Parrot::IO::Capture::Mini;
+use Parrot::Configure::Test qw( test_step_thru_runstep);
+use Tie::Filehandle::Preempt::Stdin;
+
+my $args = process_options( {
+argv=> [ q{--ask} ],
+mode=> q{configure},
+} );
+
+my $conf = Parrot::Configure->new();
+
+test_step_thru_runstep($conf, q{init::defaults}, $args);
+
+my ($task, $step_name, @step_params, $step, $ret);
+my $pkg = q{inter::make};
+
+$conf->add_steps($pkg);
+$conf->options->set(%{$args});
+
+$task = $conf->steps->[0];
+$step_name = $task->step;
[EMAIL PROTECTED] = @{ $task->params };
+
+$step = $step_name->new();
+ok(defined $step, "$step_name constructor returned defined value");
+isa_ok($step, $step_name);
+ok($step->description(), "$step_name has description");
+
+my (@prompts, $object);
[EMAIL PROTECTED] = ( q{make} );
+$object = tie *STDIN, 'Tie::Filehandle::Preempt::Stdin', @prompts;
+can_ok('Tie::Filehandle::Preempt::Stdin', ('READLINE'));
+isa_ok($object, 'Tie::Filehandle::Preempt::Stdin');
+
+$ret = $step->runstep($conf);
+ok(defined $ret, "$step_name runstep() returned defined value");
+
+$object = undef;
+untie *STDIN;
+
+pass("Completed all tests in $0");
+
+### DOCUMENTATION ###
+
+=head1 NAME
+
+108-inter_make.t - test config::inter::make
+
+=head1 SYNOPSIS
+
+% prove t/configure/108-inter_make.t
+
+=head1 DESCRIPTION
+
+The files in this directory test functionality used by F.
+
+The tests in this file test subroutines exported by config::inter::make.
+
+B Since F probes for the F program
+found on a particular OS, it will probably be difficult to achieve high
+branch or condition coverage. The module is likely to discover a
+F program long before it reaches the point where it must prompt
+the user for a response.
+
+=head1 AUTHOR
+
+James E Keenan
+
+=head1 SEE ALSO
+
+config::inter::make, F.
+
+=cut
+
+# Local Variables:
+# mode: cperl
+# cperl-indent-level: 4
+# fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:
Property changes on: t/configure/108-inter_make.t
___
Name: svn:mime-type
+ text/plain
Name: svn:keywords
+ Author Date Id Revision
Name: svn:eol-style
+ native
Re: [svn:perl6-synopsis] r14449 - doc/trunk/design/syn
On 9/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > @@ -1254,6 +1273,17 @@ > > =item * > > +A leading C indicates a positive zero-width assertion, and like C > +merely reparses the rest of the assertion recursively as if the C > +were not there. In addition to forcing zero-width, it also suppresses > +any named capture: > + > + # match a letter and capture in $ > +<+alpha># match a letter, don't capture > +# much null before a letter, don't capture > + > +=item * > + > A leading C<~~> indicates a recursive call back into some or all of > the current rule. An optional argument indicates which subpattern > to re-use, and if provided must resolve to a single subpattern. s/much/match/
[perl #43171] [TODO] replace the value for $(MAKE) with the actual path (config/inter/make.pm)
On Fri Jun 08 06:48:12 2007, ptc wrote:
> In the file config/inter/make.pm, there is the following todo item:
>
> # FIXME this is an ugly hack
> # replace the value for $(MAKE) with the actual path or we'll
end up
> # with a variable that recursively refers to itself
>
> This problem needs to be corrected.
Problem: It can only be corrected by someone who does NOT have any
version of gmake on his/her box. Why? Look at the block of code in
which this comment is embedded:
if ( $conf->data->get('gmake_version') ) {
$conf->data->set( make_c => "$prog -C" );
}
else {
# get the default value
my $make_c = $conf->data->get('make_c');
# RT#43171 this is an ugly hack
# replace the value for $(MAKE) with the actual path or we'll end up
# with a variable that recursively refers to itself
$make_c =~ s/\$\(MAKE\)/$prog/;
$conf->data->set( make_c => $make_c );
}
Only someone completely lacking a gmake would reach the 'else' block,
and only such a person would be in a position to write a test for
anything that would replace \$\(MAKE\).
Can anyone do that? Otherwise, I will mark the ticket as STALLED.
kid51
[perl #43317] [TODO] config/init/hints.pm: Write unit tests
Re-opening this ticket (hopefully briefly) to submit one more test file to squeeze a bit more coverage out of the tests of config::init::hints. Unless someone objects, I'll probably apply this tomorrow when I apply patches for config::inter::progs. Thank you very much. kid51 105-init_hints.04.t Description: Binary data
Re: [svn:perl6-synopsis] r14447 - doc/trunk/design/syn
[EMAIL PROTECTED] wrote:
Author: larry
Date: Thu Sep 6 09:31:16 2007
New Revision: 14447
+
+C<< infix: >>, proceed on success
+
+test1() andthen test2()
+
+Returns the left argument if the left argument indicates failure
+(that is, if the result is undefined). Otherwise it
+evaluates and returns the right argument.
+
+If the right side is a block or pointy block, the result of the left
+side is bound to any arguments of the block. If the right side is
+not a block, a block scope is assumed around the right side, and the
+result of the left side is implicitly bound to C<$_> for the scope
+of the right side. That is,
+
+test1() andthen test2()
+
+is equivalent to
+
+test1() andthen -> $_ { test2() }
+
+There is no corresponding high-precedence version.
+
=back
+C<< infix: >>, proceed on failure
-$value err $default
+test1() orelse test2()
-Returns the left argument if it's defined, otherwise evaluates and
-returns the right argument. In list context forces a false return
-to mean C<()>. See C above for high-precedence version.
+Returns the left argument if the left argument indicates success
+(that is, if the result is defined). Otherwise it evaluates and
+returns the right argument.
+
+If the right side is a block or pointy block, the result of the left
+side is bound to any arguments of the block. If the right side is
+not a block, a block scope is assumed around the right side, and the
+result of the left side is implicitly bound to C<$!> for the scope
+of the right side. That is,
+
+test1() orelse test2()
+
+is equivalent to
+
+test1() orelse -> $! { test2() }
+
+(The low-precedence C operator is similar, but does not set C<$!> or
+treat blocks specially.)
=back
Do the results of andthen and orelse really bind to ANY arguments of
the second block? If the second block has two parameters it makes more
sense to me for the results to bind to the first parameter and nothing
to bind to the second parameter.
Joe Gottman
[svn:perl6-synopsis] r14449 - doc/trunk/design/syn
Author: larry
Date: Thu Sep 6 17:12:02 2007
New Revision: 14449
Modified:
doc/trunk/design/syn/S05.pod
Log:
old is now <+foo> to suppress capture
new now is zero-width like
clarifications on backtracking and longest-token semantics
minimal quantifiers are now considered to terminate a longest token
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podThu Sep 6 17:12:02 2007
@@ -14,9 +14,9 @@
Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and
Larry Wall <[EMAIL PROTECTED]>
Date: 24 Jun 2002
- Last Modified: 17 Aug 2007
+ Last Modified: 6 Sep 2007
Number: 5
- Version: 63
+ Version: 64
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them I rather than "regular
@@ -247,13 +247,13 @@
The new C<:s> (C<:sigspace>) modifier causes whitespace sequences
to be considered "significant"; they are replaced by a whitespace
-matching rule, C<< >>. That is,
+matching rule, C<< <+ws> >>. That is,
m:s/ next cmd = /
is the same as:
- m/ next cmd = /
+ m/ <+ws> next <+ws> cmd <+ws> = <+ws> /
which is effectively the same as:
@@ -265,18 +265,18 @@
or equivalently,
- m { (a|\*) (b|\+) }
+ m { (a|\*) <+ws> (b|\+) }
-C<< >> can't decide what to do until it sees the data.
-It still does the right thing. If not, define your own C<< >>
+C<< <+ws> >> can't decide what to do until it sees the data.
+It still does the right thing. If not, define your own C<< ws >>
and C<:sigspace> will use that.
In general you don't need to use C<:sigspace> within grammars because
the parser rules automatically handle whitespace policy for you.
In this context, whitespace often includes comments, depending on
how the grammar chooses to define its whitespace rule. Although the
-default C<< >> subrule recognizes no comment construct, any
-grammar is free to override the rule. The C<< >> rule is not
+default C<< <+ws> >> subrule recognizes no comment construct, any
+grammar is free to override the rule. The C<< <+ws> >> rule is not
intended to mean the same thing everywhere.
It's also possible to pass an argument to C<:sigspace> specifying
@@ -285,7 +285,7 @@
important to distinguish the significant whitespace in the pattern from
the "whitespace" being matched, so we'll call the pattern's whitespace
I, and generally reserve I to indicate whatever
-C<< >> matches in the current grammar. The correspondence
+C<< <+ws> >> matches in the current grammar. The correspondence
between sigspace and whitespace is primarily metaphorical, which is
why the correspondence is both useful and (potentially) confusing.
@@ -336,16 +336,16 @@
If followed by an C, it means repetition. Use C<:x(4)> for the
general form. So
- s:4x [ () = (\N+) $$] [$0 => $1];
+ s:4x [ (<+ident>) = (\N+) $$] [$0 => $1];
is the same as:
- s:x(4) [ () = (\N+) $$] [$0 => $1];
+ s:x(4) [ (<+ident>) = (\N+) $$] [$0 => $1];
which is almost the same as:
$_.pos = 0;
- s:c[ () = (\N+) $$] = "$0 => $1" for 1..4;
+ s:c[ (<+ident>) = (\N+) $$] = "$0 => $1" for 1..4;
except that the string is unchanged unless all four matches are found.
However, ranges are allowed, so you can say C<:x(1..4)> to change anywhere
@@ -450,7 +450,7 @@
and these are equivalent to
$string ~~ m/^ \d+: $/;
-$string ~~ m/^ \d+: $/;
+$string ~~ m/^ <+ws> \d+: <+ws> $/;
=item *
@@ -584,7 +584,8 @@
erroneous to assume either order happens consistently. The C<&&>
form guarantees left-to-right order, and backtracking makes the right
argument vary faster than the left. In other words, C<&&> and C<||> establish
-sequence points.
+sequence points. The left side may be backtracked into when backtracking
+is allowed into the construct as a whole.
The C<&> operator is list associative like C<|>, but has slightly
tighter precedence. Likewise C<&&> has slightly tighter precedence
@@ -1008,10 +1009,14 @@
To pass a string with leading whitespace, or to interpolate any values
into the string, you must use the parenthesized form.
-If the first character is a plus or minus, the initial identifier
-is taken as a character class, so the first character after the
-identifier doesn't matter in this case, and you can use whitespace
-however you like. Therefore
+If the first character is a plus or minus, the rest of the assertion
+is parsed as a set of character classes (though the definition of
+character class is intentionally vague, and may include any other rule
+whether it matches characters exclusively or not).
+
+An initial identifier is taken as a character class, so the first
+character after the identifier doesn't matter in this case, and you
+can use whitespace however you like. Therefore
@@ -1054,15 +1059,21 @@
=i
Re: [svn:perl6-synopsis] r14447 - doc/trunk/design/syn
Larry Wall wrote: > Jonathan Lang wrote: > : So 'orelse' is exactly like '//', except that the result of the left > : side gets passed to the right side as an error message. Is there a > : reason to make this exception, as opposed to altering '//' to behave > : exactly like 'orelse' does? > > How 'bout, it's convenient to have the simpler defaulting semantics > when you don't care what kind of undefined value is on the left. If you don't care what kind of undefined value is on the left, you probably won't notice if it's passed to the right; and the optimizer may very well end up implementing the simpler semantics in this case, even if you use 'orelse'. And if you explicitly want to use the simpler semantics, you can come very close by blocking the right side in a block that takes no arguments. Conversely: if you do care about the undefined value, the subtle distinction between '//' and 'orelse' (beyond the implied difference in precedence) will be yet another language quirk that you'll have to remember. Very inconvenient. -- Jonathan "Dataweaver" Lang
Re: &, &&, and backtracking.
On Thu, Sep 06, 2007 at 03:49:42PM -0700, Larry Wall wrote: : On Thu, Sep 06, 2007 at 04:02:19PM -0500, Patrick R. Michaud wrote: : : I agree. One thought I had was that perhaps non-greedy matching : : could also terminate the token prefix. : : Well, that's more or less arguing it the other way. It kind of assumes : your fooba-ish arguments are smart enough to test for non-r after. The more I think about it, the more I like this approach. Most token should be matched in ratchet mode, and I think minimal matching is perhaps a form of cheating: "Look for the nearest end of this without me actually bothering to parse the middle." And certainly any reasonable grammer is going to be checking that a keyword is properly terminated by a word boundary anyway. Larry
Re: &, &&, and backtracking.
On Thu, Sep 06, 2007 at 04:02:19PM -0500, Patrick R. Michaud wrote: : I agree. One thought I had was that perhaps non-greedy matching : could also terminate the token prefix. Well, that's more or less arguing it the other way. It kind of assumes your fooba-ish arguments are smart enough to test for non-r after. : > [...] : > I think longest-token semantics have to trump minimal matching here, : > and my argument is this. Most uses of *? have additional information : > on what terminates it, either implicitly in what it is matching, or : > explicitly in the next bit of regex. That is, you'd typically see : > either : > foo\w+? | fooba : > or : > foo.+? | fooba : > : > In either case, the clear intent is to match foobar over fooba. : > Therefore I think the DFA matcher just strips ? and does its ordinary : > character by character match, relying on that extra info to match : > the real extent of the quantifier. : : Does this still hold true for a non-greedy quantifier in the : middle of an expression... ? I.e., : : "foobazbar deborah" ~~ /foo .+? b.r | fooba | foobazb / : : matches "foobazbar debor" ? I suppose one approach would be to limit the DFA to the longest known constant string, and then rerun any variable branches individually to see if they will actually match something that long. Alternately, if the DFA engine is smart enough to kick out all the matches of the "foo .+? b.r" branch then it could conceivably be taught to return the shortest one rather than the longest one. Course, the question after than is, what if you mix minimal with maximal quantifiers? Another consideration is the efficiency of matching that pattern against "foobazbar" ~ 'b' x 1. That would definitely run faster if you cut off the DFA after the longest known token, or as soon as the DFA reduces to one possibility, presuming you can know such a thing. Any way we work it, there will be a way to use it wrong. Larry
Re: [svn:perl6-synopsis] r14447 - doc/trunk/design/syn
On Thu, Sep 06, 2007 at 01:40:20PM -0700, Jonathan Lang wrote: : So 'orelse' is exactly like '//', except that the result of the left : side gets passed to the right side as an error message. Is there a : reason to make this exception, as opposed to altering '//' to behave : exactly like 'orelse' does? How 'bout, it's convenient to have the simpler defaulting semantics when you don't care what kind of undefined value is on the left. Larry
Re: &, &&, and backtracking.
On Thu, Sep 06, 2007 at 12:37:37PM -0700, Larry Wall wrote: > On Thu, Sep 06, 2007 at 01:25:12PM -0500, Patrick R. Michaud wrote: > : On a somewhat similar question, what happens with a pattern > : such as > : > : "foobar" ~~ / foo.+? | fooba / > : > : The LHS initially matches "foob", but with backtracking could > : eventually match "foobar". Do the longest-token semantics > : in this case cause the RHS to be dispatched first, even > : though the token declaration of the LHS _could_ match a > : longer token prefix? > > Yow. ICATBW. Non-greedy matching is somewhat antithetical to > longest-token matching. I agree. One thought I had was that perhaps non-greedy matching could also terminate the token prefix. > [...] > I think longest-token semantics have to trump minimal matching here, > and my argument is this. Most uses of *? have additional information > on what terminates it, either implicitly in what it is matching, or > explicitly in the next bit of regex. That is, you'd typically see > either > foo\w+? | fooba > or > foo.+? | fooba > > In either case, the clear intent is to match foobar over fooba. > Therefore I think the DFA matcher just strips ? and does its ordinary > character by character match, relying on that extra info to match > the real extent of the quantifier. Does this still hold true for a non-greedy quantifier in the middle of an expression... ? I.e., "foobazbar deborah" ~~ /foo .+? b.r | fooba | foobazb / matches "foobazbar debor" ? (I completely grant that the examples I'm coming up with here may be completely nonsensical in real application, but I'm just exploring the space a bit.) Pm
Re: [svn:perl6-synopsis] r14447 - doc/trunk/design/syn
So 'orelse' is exactly like '//', except that the result of the left side gets passed to the right side as an error message. Is there a reason to make this exception, as opposed to altering '//' to behave exactly like 'orelse' does? -- Jonathan "Dataweaver" Lang
Re: &, &&, and backtracking.
On Thu, 2007-09-06 at 12:37 -0700, Larry Wall wrote: > Yow. ICATBW. The what now? -'f
Re: &, &&, and backtracking.
On Thu, Sep 06, 2007 at 01:25:12PM -0500, Patrick R. Michaud wrote:
: > Were we using the procedural conjunction:
: >
: > "foobar" ~~ / <[a..z]>+ && [ ... ] /;
: >
: > I would guess that the LHS matches as much as it can ("foobar"), then
: > the RHS matches "foo" [...and then backtracks the LHS until a
: > conjunctional match is found...]
: >
: > Or it's much simpler than that and both of the regexes above just fail
: > because of the greediness of C<+> and there is no intra-conjunction
: > backtracking.
:
: I think we definitely allow intra-conjunction backtracking.
: PGE implements it that way.
That's what I think.
: On a somewhat similar question, what happens with a pattern
: such as
:
: "foobar" ~~ / foo.+? | fooba /
:
: The LHS initially matches "foob", but with backtracking could
: eventually match "foobar". Do the longest-token semantics
: in this case cause the RHS to be dispatched first, even
: though the token declaration of the LHS _could_ match a
: longer token prefix?
Yow. ICATBW. Non-greedy matching is somewhat antithetical to
longest-token matching. But basically it boils down to this:
Does the longest-token matcher ignore the ? and do
foo.+ | fooba
or is there an implicit ordering above and beyond the DFA engine of
foob | fooba ||
fooba | fooba ||
foobar | fooba ||
I think longest-token semantics have to trump minimal matching here,
and my argument is this. Most uses of *? have additional information
on what terminates it, either implicitly in what it is matching, or
explicitly in the next bit of regex. That is, you'd typically see
either
foo\w+? | fooba
or
foo.+? | fooba
In either case, the clear intent is to match foobar over fooba.
Therefore I think the DFA matcher just strips ? and does its ordinary
character by character match, relying on that extra info to match
the real extent of the quantifier.
Larry
Re: &, &&, and backtracking.
On Wed, Sep 05, 2007 at 09:36:24PM -0500, Jonathan Scott Duff wrote:
> How do C<&> and C<&&> differ with respect to backtracking? For instance,
>
> "foobar" ~~ / <[a..z]>+ & [ ... ] /;
>
> Both sides of the C<&> happen in parallel, so I would guess that they
> both match "foo" then stop. Please correct me if that's wrong.
I think the phrase "happen in parallel" overstates things a bit
here. From S05:
The & form is considered declarative rather than procedural;
it allows the compiler and/or the run-time system to decide
which parts to evaluate first, and it is erroneous to assume
either order happens consistently. The && form guarantees
left-to-right order, and backtracking makes the right argument
vary faster than the left.
So, to answer your original question, I think the most we can
say is that C<&&> guarantees a specific order of evaluation,
while C<&> allows the pattern matcher to choose an ordering.
> Were we using the procedural conjunction:
>
> "foobar" ~~ / <[a..z]>+ && [ ... ] /;
>
> I would guess that the LHS matches as much as it can ("foobar"), then
> the RHS matches "foo" [...and then backtracks the LHS until a
> conjunctional match is found...]
>
> Or it's much simpler than that and both of the regexes above just fail
> because of the greediness of C<+> and there is no intra-conjunction
> backtracking.
I think we definitely allow intra-conjunction backtracking.
PGE implements it that way.
On a somewhat similar question, what happens with a pattern
such as
"foobar" ~~ / foo.+? | fooba /
The LHS initially matches "foob", but with backtracking could
eventually match "foobar". Do the longest-token semantics
in this case cause the RHS to be dispatched first, even
though the token declaration of the LHS _could_ match a
longer token prefix?
Thanks,
Pm
[svn:perl6-synopsis] r14448 - doc/trunk/design/syn
Author: larry Date: Thu Sep 6 09:51:18 2007 New Revision: 14448 Modified: doc/trunk/design/syn/S03.pod Log: brainos Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podThu Sep 6 09:51:18 2007 @@ -12,7 +12,7 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 8 Mar 2004 - Last Modified: 6 Aug 2007 + Last Modified: 6 Sep 2007 Number: 3 Version: 121 @@ -59,7 +59,7 @@ =head2 Term precedence This isn't really a precedence level, but it's in here because no operator -can have tighter precedence than a term. See S03 for longer descriptions of +can have tighter precedence than a term. See S02 for longer descriptions of various terms. =over
[svn:perl6-synopsis] r14447 - doc/trunk/design/syn
Author: larry
Date: Thu Sep 6 09:31:16 2007
New Revision: 14447
Modified:
doc/trunk/design/syn/S03.pod
Log:
Add logic programming primitives with decent binding of intermediate state
The much-despised "err" operator is gone; use "orelse" instead
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podThu Sep 6 09:31:16 2007
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 8 Mar 2004
- Last Modified: 30 Aug 2007
+ Last Modified: 6 Aug 2007
Number: 3
- Version: 120
+ Version: 121
=head1 Overview
@@ -48,8 +48,8 @@
Comma operator ,
List infix Z minmax X X~X X*X XeqvX
List prefix = : print push say die map substr ... [+] [*] any $ @
-Loose and and
-Loose oror xor err
+Loose and and andthen
+Loose oror xor orelse
Terminator ; <==, ==>, <<==, ==>>, {...}, modifiers, extra ), ], }
If you don't see your favorite operator there, the following
@@ -59,7 +59,7 @@
=head2 Term precedence
This isn't really a precedence level, but it's in here because no operator
-can have tighter precedence than a term. See S02 for longer descriptions of
+can have tighter precedence than a term. See S03 for longer descriptions of
various terms.
=over
@@ -1008,13 +1008,14 @@
=item *
-C<< infix: >>, defined-or
+C<< infix: >>, default operator
$value // $default
Returns the left argument if it's defined, otherwise evaluates and
returns the right argument. In list context forces a false return
-to mean C<()>. See C below for low-precedence version.
+to mean C<()>. See C below for a similar but not identical
+low-precedence version.
=item *
@@ -1497,6 +1498,30 @@
a false return to mean C<()>. See C<&&> above for high-precedence
version.
+=item *
+
+C<< infix: >>, proceed on success
+
+test1() andthen test2()
+
+Returns the left argument if the left argument indicates failure
+(that is, if the result is undefined). Otherwise it
+evaluates and returns the right argument.
+
+If the right side is a block or pointy block, the result of the left
+side is bound to any arguments of the block. If the right side is
+not a block, a block scope is assumed around the right side, and the
+result of the left side is implicitly bound to C<$_> for the scope
+of the right side. That is,
+
+test1() andthen test2()
+
+is equivalent to
+
+test1() andthen -> $_ { test2() }
+
+There is no corresponding high-precedence version.
+
=back
=head2 Loose or precedence
@@ -1526,13 +1551,28 @@
=item *
-C<< infix: >>, short-circuit defined-or
+C<< infix: >>, proceed on failure
-$value err $default
+test1() orelse test2()
-Returns the left argument if it's defined, otherwise evaluates and
-returns the right argument. In list context forces a false return
-to mean C<()>. See C above for high-precedence version.
+Returns the left argument if the left argument indicates success
+(that is, if the result is defined). Otherwise it evaluates and
+returns the right argument.
+
+If the right side is a block or pointy block, the result of the left
+side is bound to any arguments of the block. If the right side is
+not a block, a block scope is assumed around the right side, and the
+result of the left side is implicitly bound to C<$!> for the scope
+of the right side. That is,
+
+test1() orelse test2()
+
+is equivalent to
+
+test1() orelse -> $! { test2() }
+
+(The low-precedence C operator is similar, but does not set C<$!> or
+treat blocks specially.)
=back
Re: [perl #39088] [CAGE] Add conditional GCC attributes to functions
> You've done a lot of work on this in parrot already and I haven't seen > anything new as far as attributes go for a while. Have you finished > adding gcc attributes? If so, we can close this ticket. On attributes, I think so. Warning flags will be a separate project. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: mod_perl6 update
You've hit different child processes. "James E Keenan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Jeff Horwitz wrote: > > > > > Counter: http://www.smashing.org/sandbox/perl6-handlers/counter > > > > > > When I first clicked on this link, the counter stood at 30. Then, when > I hit the Refresh button, it surprised me by jumping directly to 45. > Subsequent refreshes incremented the counter by 1, as I would have expected. >
Parrot::Configure::Step::_run_command(): problematic global filehandles
Friends:
Parrot::Configure::Step holds an internal subroutine called
_run_command() whose task is to execute a system call on a command
supplied as an argument. The command supplied is typically a small
C-executable created on the fly as a particular configuration step runs.
I've been staring at _run_command() quite a bit in the course of trying
to write unit tests for those configuration steps, and I'm unhappy with
what I see. What I don't like is all the manipulation of globally
scoped filehandles done for the purpose of logging the output of the
C-executable. The manipulation is two-fold:
1. Opening handles to STDOUT and STDERR to log the output and errors of
the C-executable. The log files live (briefly) at the top level of the
Parrot hierarchy.
2. Duplicating those handles (following tricks described in 'perldoc -f
open') so that if verbosity was requested, the output of those files can
be printed on STDOUT or STDERR.
sub _run_command {
...
# Save the old filehandles; we must not let them get closed.
open my $OLDOUT, '>&', \*STDOUT or die "Can't save stdout" if $out;
open my $OLDERR, '>&', \*STDERR or die "Can't save stderr" if $err;
open STDOUT, '>', $out or die "Can't redirect stdout" if $out;
# See 'Obscure Open Tricks' in perlopentut
open STDERR, ">$err" or die "Can't redirect stderr" if $err; ##
no critic InputOutput::ProhibitTwoArgOpen
system $command;
my $exit_code = $? >> 8;
close STDOUT or die "Can't closestdout" if $out;
close STDERR or die "Can't closestderr" if $err;
open STDOUT, '>&', $OLDOUT or die "Can't restore stdout" if $out;
open STDERR, '>&', $OLDERR or die "Can't restore stderr" if $err;
...
}
The problem with having global filehandles STDOUT and STDERR being
manipulated quite deep into a program is that it stymies you from doing
anything with those handles higher up at the surface of your program. I
found this out the hard way over this past weekend when I was trying to
respond to bug reports from Andy D. on some of my tests. For testing
purposes -- in particular, to work around a peculiarity in Test::Harness
-- I wanted to capture STDOUT by tieing. But despite many different
approaches, I could not do so correctly.
While the particular reason why _run_command() was problematic for me is
not of earth-shaking consequence, I can't help but wonder: Is there any
other way we could achieve _run_command()'s objectives without its
internal manipulation of global filehandles?
Thank you very much.
kid51
Re: mod_perl6 update
Jeff Horwitz wrote: Counter: http://www.smashing.org/sandbox/perl6-handlers/counter When I first clicked on this link, the counter stood at 30. Then, when I hit the Refresh button, it surprised me by jumping directly to 45. Subsequent refreshes incremented the counter by 1, as I would have expected.
Re: &, &&, and backtracking.
Jonathan Scott Duff wrote: > How do C<&> and C<&&> differ with respect to backtracking? For instance, > > "foobar" ~~ / <[a..z]>+ & [ ... ] /; > > Both sides of the C<&> happen in parallel, so I would guess that they > both match "foo" then stop. Please correct me if that's wrong. As written, this match would fail, since '<[a..z]>+' would match "foobar" while '[ ... ]' would match "foo". '&' requires that both sides match the same start and end points. I suppose that it might be worth considering requiring only the start points to match, and having the conjoined match use the earliest end point; so that the above match would then match "foo" instead of failing. But it's entirely possible that there's something faulty with this approach. The difference between '&' and '&&' is that '&' evaluates the two sides in an arbitrary order, possibly even in parallel; '&&' always evaluates the left side first, and only bothers with the right side if the left side matched. -- Jonathan "Dataweaver" Lang
Re: mod_perl6 update
On 05/09/07, Jeff Horwitz <[EMAIL PROTECTED]> wrote: > It gives me great pleasure to introduce you to the world's first mod_perl6 > handlers! They are run using Parrot's Perl6 compiler on top of > mod_parrot, and are compiled on the fly the first time a handler is > called. Each handler is passed an [Apache;RequestRec] object instantiated > by mod_parrot, and the handlers can call methods on that object from Perl6 > land. That's fantastic! Great work! :-) Paul
[perl #39088] [CAGE] Add conditional GCC attributes to functions
On Fri May 05 15:18:22 2006, petdance wrote: > > GCC has a number of attributes that we can slap on functions. For > example, GCC's analysis of flow control will be greatly improved when > we put __attribute(noreturn)__ on real_exception(), to tell GCC that > it can't return, like exit(). > > I've done a ton of this for perl5, and can bring it on over. Andy, You've done a lot of work on this in parrot already and I haven't seen anything new as far as attributes go for a while. Have you finished adding gcc attributes? If so, we can close this ticket. Paul
[perl #40626] [BUG] :vtable fails for subclasses of core classes
> thanks for the quick turnaround. this test is perfect for the > 'executed from pir test case', and will be applied shortly. The test case has been added in r21092. > but as > patrick later provided an example of executing a .pbc file, we'll also > need a test for this before the ticket is closed. I propose to close this ticket, as running the PIR and PASM test by generating first PBC is issue of RT#41666. The good news is that it really works: [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot$ ./parrot -o t.pbc t/pmc/objects_78.pir [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot$ ./parrot t.pbc Hello world Hello world [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot$ ./parrot t/pmc/objects_78.pir Hello world Hello world [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot$ Any comments? Bernhard -- /* [EMAIL PROTECTED] */
&, &&, and backtracking.
How do C<&> and C<&&> differ with respect to backtracking? For instance,
"foobar" ~~ / <[a..z]>+ & [ ... ] /;
Both sides of the C<&> happen in parallel, so I would guess that they
both match "foo" then stop. Please correct me if that's wrong.
Were we using the procedural conjunction:
"foobar" ~~ / <[a..z]>+ && [ ... ] /;
I would guess that the LHS matches as much as it can ("foobar"), then
the RHS matches "foo". Since "foobar" ne "foo", the regex engine
backtracks on the LHS matching "fooba" and then the RHS matches "foo"
again. Again, since "fooba" ne "foo", the regex engine backtracks as
before and this behavior continues until both sides match "foo" (or, in
the general case, it can determine that the conjunctions can't match the
same portion of the string)
Or it's much simpler than that and both of the regexes above just fail
because of the greediness of C<+> and there is no intra-conjunction
backtracking.
So ... anyone care to enlighten me on how this is supposed to work?
Thanks,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
[perl #45209] [BUG] parrot considers -0.0 to be true
# New Ticket Created by Colin Kuskie # Please include the string: [perl #45209] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=45209 > Parrot is supposed to follow IEEE conventions for truth. 0.0 and -0.0 are false, NaN is true. Currently, parrot considers -0.0 to be true. This is shown by t/examples/tutorial.t, for the 51_if_unless.pir test.
[perl #45217] [PATCH] Class to 'Class' fixes
# New Ticket Created by Colin Kuskie # Please include the string: [perl #45217] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=45217 > More clean-up of Class to 'Class' in t/op, t/library and t/compilers. Index: t/compilers/imcc/syn/clash.t === --- t/compilers/imcc/syn/clash.t (revision 21102) +++ t/compilers/imcc/syn/clash.t (working copy) @@ -62,7 +62,7 @@ pir_output_is( <<'CODE', <<'OUT', "new" ); .sub test :main -$P1 = new String +$P1 = new 'String' $P1 = "ok 1\n" new P1, 'String' set P1, "ok 2\n" @@ -77,7 +77,7 @@ pir_output_is( <<'CODE', <<'OUT', "clone" ); .sub test :main -$P1 = new String +$P1 = new 'String' $P1 = "ok 1\n" $P0 = clone $P1 new P1, 'String' @@ -94,7 +94,7 @@ pir_output_is( <<'CODE', <<'OUT', "defined" ); .sub test :main -$P1 = new Hash +$P1 = new 'Hash' $I0 = defined $P1 new P1, 'Hash' defined I0, P1 @@ -111,7 +111,7 @@ pir_output_is( <<'CODE', <<'OUT', "defined keyed" ); .sub test :main -$P1 = new Hash +$P1 = new 'Hash' $P1["a"] = "ok 1\n" $I0 = defined $P1["a"] new P1, 'Hash' Index: t/library/dumper.t === --- t/library/dumper.t (revision 21102) +++ t/library/dumper.t (working copy) @@ -1,4 +1,4 @@ -#!perl +#!'perl' # Copyright (C) 2001-2006, The Perl Foundation. # $Id$ Index: t/library/test_more.t === --- t/library/test_more.t (revision 21102) +++ t/library/test_more.t (working copy) @@ -400,13 +400,13 @@ test_test( 'passing isa_ok for PMC/string (super)') test_pass( 'Sossy isa daschund' ) - $P1 = new String + $P1 = new 'String' $P1 = "daschund" isa_ok(Sossy, $P1, "Sossy") test_test( 'passing isa_ok for PMC/PMC (class =)' ) test_pass( 'Sossy isa dog' ) - $P2 = new String + $P2 = new 'String' $P2 = "dog" isa_ok(Sossy, $P2, "Sossy") test_test( 'passing isa_ok for PMC/PMC (super)') Index: t/op/gc.t === --- t/op/gc.t (revision 21102) +++ t/op/gc.t (working copy) @@ -294,7 +294,7 @@ newclass $P0, "b" $I0 = find_type "b" $P0 = new $I0 -$P1 = new Integer +$P1 = new 'Integer' $P1 = 0 n = $P0."b11"($P1) print "ok 1\n" @@ -307,7 +307,7 @@ .local pmc n1 # new_pad -1 # store_lex -1, "n", n -n1 = new Integer +n1 = new 'Integer' n1 = n + 1 push_eh catch n = self."b11"(n1) @@ -571,11 +571,11 @@ addattribute cl, "o3" addattribute cl, "o4" s = new "X" -$P0 = new String +$P0 = new 'String' $S0 = "ok" . " 3\n" $P0 = $S0 setattribute s, "X\0o3", $P0 -$P0 = new String +$P0 = new 'String' $S0 = "ok" . " 4\n" $P0 = $S0 setattribute s, "X\0o4", $P0 Index: t/op/lexicals.t === --- t/op/lexicals.t (revision 21102) +++ t/op/lexicals.t (working copy) @@ -555,11 +555,11 @@ .const .Sub choose_sub = "_choose" .const .Sub fail_sub = "_fail" fail = newclosure fail_sub - arr1 = new ResizablePMCArray + arr1 = new 'ResizablePMCArray' arr1[0] = 1 arr1[1] = 3 arr1[2] = 5 - arr2 = new ResizablePMCArray + arr2 = new 'ResizablePMCArray' arr2[0] = 1 arr2[1] = 5 arr2[2] = 9 @@ -674,7 +674,7 @@ .sub foo .lex 'a', $P0 -$P0 = new Integer +$P0 = new 'Integer' $P0 = 0 .const .Sub bar_sub = "bar" @@ -726,7 +726,7 @@ .sub foo .param int i .lex 'a', $P0 -$P1 = new Integer +$P1 = new 'Integer' $P1 = i store_lex 'a', $P1 print "foo: " @@ -784,7 +784,7 @@ .sub foo .param int i .lex 'a', $P0 -$P1 = new Integer +$P1 = new 'Integer' $P1 = i store_lex 'a', $P1 print "foo: " Index: t/op/calling.t === --- t/op/calling.t (revision 21102) +++ t/op/calling.t (working copy) @@ -257,7 +257,7 @@ pir_output_is( <<'CODE', <<'OUTPUT', "use it in PIR" ); .sub main :main -$P0 = new String +$P0 = new 'String' $P0 = "hello\n" find_name $P1, "foo" # set_args and invoke must be adjacent @@ -329,7 +329,7 @@ pir_output_is( <<'CODE', <<'OUTPUT', "use it in PIR" ); .sub main :main -$P0 = new String +$P0 = new 'String' $P0 = "hello\n" find_name $P1, "foo" # set_args and invoke must be adjacent @@ -346,7 +346,7 @@ pir_output_is( <<'CODE', <<'OUTPUT', "type conversion - autobox" ); .sub main :main -$P0 = new String +$P0 = new 'String' $P0 = "hello" find_name $P1, "foo" # set_args and invoke must be adjacent @@ -434,7 +434,7 @@ .sub main :main .include "errors.pasm" errorson .PAR
mod_perl6 update
It gives me great pleasure to introduce you to the world's first mod_perl6
handlers! They are run using Parrot's Perl6 compiler on top of
mod_parrot, and are compiled on the fly the first time a handler is
called. Each handler is passed an [Apache;RequestRec] object instantiated
by mod_parrot, and the handlers can call methods on that object from Perl6
land.
First is Polly. Polly repeats everything from the query string of a URL.
It uses the puts() method for output and args() to retrieve the query
string from Apache.
sub polly_handler($r)
{
$r.puts("Polly, a mod_perl6 handler\n");
$r.puts("SQUAWK! Polly says "~$r.args());
0; # Apache OK
}
Second is the counter, which increments a counter each time it is called.
It demonstrates the persistence of the interpreter and proper scoping of
the counter variable using "our". Since each Apache process has its own
interpreter, the count might seem to jump between calls, espcially if your
browser isn't using keepalives.
sub counter_handler($r)
{
our $x;
unless ($x) {
$x = 1;
}
$r.puts("Hello, I'm a mod_perl6 response handler!\n");
$r.puts("Page views for this interpreter: $x\n");
$x++;
0; # Apache OK
}
Against my better judgment, here are URLs for each handler:
Polly: http://www.smashing.org/sandbox/perl6-handlers/polly?wanna_cracker
Counter: http://www.smashing.org/sandbox/perl6-handlers/counter
Hopefully the server stays up -- I guess this is a pretty good test of
mod_parrot's stability. ;-)
Enjoy,
-jeff
[perl #45203] [PATCH] fix falsely passing examples/tutorial test
# New Ticket Created by Colin Kuskie # Please include the string: [perl #45203] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=45203 > t/examples/tutorial.t is passing, but should not be due to a parrot bug. -0.0 is supposed to be false, but parrot currently considers it true. This patch adjusts the expected output of that tutorial to expose the bug. Index: t/examples/tutorial.t === --- t/examples/tutorial.t (revision 21091) +++ t/examples/tutorial.t (working copy) @@ -142,6 +142,7 @@ before unless is printed after unless +-0.0 was false END_EXPECTED '52_if_compare.pir' => << 'END_EXPECTED',
