Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
Chris, Thanks for your comments, I'm still trying to hone my perl abilities and I really appreciate your feedback. I certainly need help sometimes with my regular expressions... A few comments: * No, this shouldn't go into UseParrotCoda. Separately enabled policies are more flexible. Actually, I meant putting the UseParrotCoda under CodingStandards::, but as Will pointed out the shebang stuff would probably be better under TestingAndDebugging::. * In fact, yours should probably be broken into two policies. Perhaps CodeStandards::ProhibitShebangWarningsArg and CodeStandards::RequirePortableShebang That's a very good idea, and I thought of that, but didn't know if it was better to split things up than bunch together related tests. * This would be a nice addition to core Perl::Critic! Do you want me to supply a patch for Perl::Critic too, or will the file added to Parrot suffice? * The -w catcher fails on "#!perl -T -w" or other variations on argument lists. Perhaps forbid any arguments at all? Hadn't thought of "perl -T", and I'll update the patch accordingly; thanks :-). I also found that the -w catcher failed when I was testing my patch to resubmit, so again, I think I need to improve my regexp foo. * The shebang line is always a PPI::Token::Comment and is always on the first line. Using PPI::Token::Comment will simplify the test a lot more. I'll have a bit more of a play and see if I can get a better patch in. Thanks again for your feedback! Paul
Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
Chris, This one is still a false negative on "#!perl -Tw" and is a false positive on "package main; #!!! my co-worker provided this non-Perl-licensed code to Parrot!!!". Yes, that's a highly contrived example. :-) But the false positive would be avoidable by checking the line and column number of the element. Well spotted! This is another good point to help me test my test; woah is that meta... Paul
Re: Questions about DEPRECATED.pod
> To remove the deprecated C opcode does one simply remove > the references to it in src/ops/object.ops (and other .ops files), and > remove the function from src/ops/ops.num? Does one then move all of > the ops numbers "up" so that there isn't a gap caused by removing the > opcodes? Is this relabelling of the opcode numbers going to break > anything else? If not, should I go through and remove references to > C and fix up ops.num and patch? I think you mostly got it. For the renumbering of src/ops/ops.num you can use make -f tools/dev/ops_renum.mak Also see the notes in PBC_COMPAT. Thanks Bernhard! Added to my todo list :-) Paul
Re: [perl #40481] [PATCH] C-code coda in pmc files
No problem with the two patch files. Could you add the patches for the amber *.pmc ? Attached to this email. Odd that I missed those files before... Regards, Paul files affected: languages/amber/lib/kernel/pmc/amber_character.pmc languages/amber/lib/kernel/pmc/amber_integer.pmc languages/amber/lib/kernel/pmc/amber_pathname.pmc languages/amber/lib/kernel/pmc/amber_array.pmc languages/amber/lib/kernel/pmc/amber_boolean.pmc languages/amber/lib/kernel/pmc/amber_default.pmc languages/amber/lib/kernel/pmc/amber_string.pmc languages/amber/lib/kernel/pmc/amber_table.pmc Index: languages/amber/lib/kernel/pmc/amber_character.pmc === --- languages/amber/lib/kernel/pmc/amber_character.pmc (revision 14877) +++ languages/amber/lib/kernel/pmc/amber_character.pmc (working copy) @@ -44,10 +44,7 @@ /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: "parrot" * End: - * * vim: expandtab shiftwidth=4: */ Index: languages/amber/lib/kernel/pmc/amber_integer.pmc === --- languages/amber/lib/kernel/pmc/amber_integer.pmc (revision 14877) +++ languages/amber/lib/kernel/pmc/amber_integer.pmc (working copy) @@ -79,10 +79,7 @@ /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: "parrot" * End: - * * vim: expandtab shiftwidth=4: */ Index: languages/amber/lib/kernel/pmc/amber_pathname.pmc === --- languages/amber/lib/kernel/pmc/amber_pathname.pmc (revision 14877) +++ languages/amber/lib/kernel/pmc/amber_pathname.pmc (working copy) @@ -294,10 +294,7 @@ /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: "parrot" * End: - * * vim: expandtab shiftwidth=4: */ Index: languages/amber/lib/kernel/pmc/amber_array.pmc === --- languages/amber/lib/kernel/pmc/amber_array.pmc (revision 14877) +++ languages/amber/lib/kernel/pmc/amber_array.pmc (working copy) @@ -94,10 +94,7 @@ /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: "parrot" * End: - * * vim: expandtab shiftwidth=4: */ Index: languages/amber/lib/kernel/pmc/amber_boolean.pmc === --- languages/amber/lib/kernel/pmc/amber_boolean.pmc (revision 14877) +++ languages/amber/lib/kernel/pmc/amber_boolean.pmc (working copy) @@ -57,10 +57,7 @@ /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: "parrot" * End: - * * vim: expandtab shiftwidth=4: */ Index: languages/amber/lib/kernel/pmc/amber_default.pmc === --- languages/amber/lib/kernel/pmc/amber_default.pmc (revision 14877) +++ languages/amber/lib/kernel/pmc/amber_default.pmc (working copy) @@ -44,13 +44,10 @@ } + /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: "parrot" * End: - * * vim: expandtab shiftwidth=4: */ - Index: languages/amber/lib/kernel/pmc/amber_string.pmc === --- languages/amber/lib/kernel/pmc/amber_string.pmc (revision 14877) +++ languages/amber/lib/kernel/pmc/amber_string.pmc (working copy) @@ -93,10 +93,7 @@ /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: "parrot" * End: - * * vim: expandtab shiftwidth=4: */ Index: languages/amber/lib/kernel/pmc/amber_table.pmc === --- languages/amber/lib/kernel/pmc/amber_table.pmc (revision 14877) +++ languages/amber/lib/kernel/pmc/amber_table.pmc (working copy) @@ -64,10 +64,7 @@ /* * Local variables: - * c-indentation-style: bsd - * c-basic-offset: 4 - * indent-tabs-mode: nil + * c-file-style: "parrot" * End: - * * vim: expandtab shiftwidth=4: */
Re: S5: substitutions
On 10/9/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
Smylers wrote:
> To be consistent your proposal should also suggest that these become
> equivalent:
>
> * "{ function() }"
> * qq[ {function() }]
> * qq{ function() }
> * eval "function()"
How so? AFAIK, string literal syntax requires you to prepend a sigil
on the front of any embedded closure that you want to interpolate a
value from; otherwise, it isn't a closure - it's just a pair of
curly-brace characters. My proposal isn't "curly braces _always_ act
like closures, no matter what"; it's "the second part of a s[]
construct doesn't have to be a literal; it can be anything that can be
evaluated as needed by the algorithm to provide substitute text."
According to S02 bare curlies do interpolate in double-quoted strings:
S02> =item *
S02>
S02> A bare closure also interpolates in double-quotish context. It may
S02> not be followed by any dereferencers, since you can always put them
S02> inside the closure. The expression inside is evaluated in scalar
S02> (string) context. You can force list context on the expression using
S02> the C operator if necessary.
--
Markus Laire
Re: S5: substitutions
Markus Laire wrote: According to S02 bare curlies do interpolate in double-quoted strings: Yeah; that was subsequently pointed out to me. Oops. -- Jonathan "Dataweaver" Lang
Re: Coroutines in Lua
At 18:52 07/10/2006 -0400, Bob Rogers wrote: From: François PERRAD <[EMAIL PROTECTED]> Date: Wed, 04 Oct 2006 08:55:34 +0200 I've tried without success to implement coroutine in language Lua . . . Help is welcome. François. I am not surprised that you have had difficulty. I can't even get a simple recursive coroutine to work in PIR. See the first attachment for an attempt. I think this is a fundamental problem; I know nothing about Lua, but I strongly suspect Parrot coroutines would have to be redesigned to support what the Lua manual says about them [1]. But that's not a show-stopper; continuations alone are powerful enough to do most of what you need. The second attachment is a demo implementation based loosely on the Lua definitions of coroutine.create, coroutine.resume, and coroutine.yield. The first third of the code defines PIR near-equivalents to these, and the rest includes several demos. The demo that runs by default (i.e. without editing the code) is a solution to the "same fringe" problem [2] using a pair of recursive coroutines to enumerate two trees simultaneously. However, the abstraction is poor. This is partly because I was too lazy to figure out whether an object-oriented solution would fail due to the "continuation barrier" problem, and partly because I was too lazy to make the "current coroutine" implicit, as it is in Lua [3]. Still, I hope you find this useful. Probably it ought to get turned into an example . . . Thank for your long response. I included your code in languages/lua/lib/luacoroutine.pir (r14877). I encountered 2 problems : 1) coroutine_yield needs a current coroutine (not surprising) 2) I want replace the LuaThread PMC by a PIR classe. So, I create a classe : $P0 = subclass 'FixedPMCArray', 'thread' But when I replace in coroutine_create coro = new .FixedPMCArray coro = 4 by : find_type $I0, 'thread' coro = new $I0 coro = 4 some test of languages/lua/t/coroutine.t fail with the following message : FixedPMCArray: index out of bounds! François. Also, the "[oops; got 4 and X]" lines in the output seem to suggest that Parrot may be getting confused about parameters. The "4" is really the length of one of the coro structures, which must be getting passed as the first arg. Also, it fails with "too many args" if you don't accept at least two values from the coroutine_yield. I suspect Parrot is reusing some old parameter information; I'll try to nail this down if I get a chance. -- Bob Rogers http://rgrjr.dyndns.org/ [1] http://www.lua.org/manual/5.1/manual.html#2.11 [2] http://www.nsl.com/papers/samefringe.htm, e.g. [3] This also depends on how the "current coroutine" should be scoped. Dynamic scoping seems reasonable, but that's not obvious from [1].
Re: Null PMC access while parsing javascript
Hi Mehmet, you might have run into a Garbage-Collector bug. Try parrot --no-gc main.pir 'x' 'identifier' I had similar problems using PGE::P6Regex. '--no-gc' helped. Regards, Kiwi
Re: Null PMC access while parsing javascript
Hi Mehmet, you might have run into a Garbage-Collector bug. Try parrot --no-gc main.pir 'x' 'identifier' I had similar problems using PGE::P6Regex. '--no-gc' helped. Regards, Kiwi The same problem. I think that I now know the problem: the grammar is not complete. I was thinking that pgc would refuse compiling in that case, but it doesn't. It's probably to allow you define your own rules at runtime, but some warnings would be handy. -- Mehmet
Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
On Oct 10, 2006, at 3:12 AM, Paul Cochrane wrote: * This would be a nice addition to core Perl::Critic! Do you want me to supply a patch for Perl::Critic too, or will the file added to Parrot suffice? That's completely up to you. You seem to have a knack for writing policies, so we'd love to have the help with Perl::Critic. But Parrot is a worthy cause too! :-) If you don't provide a P::C patch, I'll probably do it myself eventually. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Nitpick my Perl6 - parametric roles
HaloO, Darren Duncan wrote: Within a system that already has an underlying set-like type, the Junction in this case, a test for uniqueness is (pardon any spelling): all(@items).elements.size === @items.size The all() will strip any duplicates, so if the number of elements in all(@items) is the same as @items, then @items has no duplicates. OK, but you are not using the 'set with additional behavior' of junctions. How would that be spelled with a pure set? set(@items).elements.size === @items.size perhaps? This would nicely blend with the junction forms. Would it even be the case that Set is a super role of the junctions? Regards, --
Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
Chris,
This one is still a false negative on "#!perl -Tw" and is a false positive
on "package main; #!!! my co-worker provided this non-Perl-licensed code to
Parrot!!!". Yes, that's a highly contrived example. :-) But the false
positive would be avoidable by checking the line and column number of the
element.
I've been playing around for a while with the shebang line tests, and
it struck me that the is_script() function will return true on your
contrived example. Here's my reasoning: the line:
package main; #!!! my co-worker...
gets pulled apart (so-to-speak) by $doc->find_first(
'PPI::Token::Comment' ) and the string
#!!! my co-worker...
gets returned as the first comment, and this matches the regular
expression. m{\A \#!}mx Am I right? I thought it was an interesting,
albeit contrived example.
Also, the fact that you mention that the shebang should be the first
line lead me to think that maybe we could look for misplaced shebang
lines, and report an error there as well. I've got a patch for that
and can send this in too if you want.
Regards,
Paul
Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
Chris,
Attached are three new P::C policies for Parrot:
prohibit_shebang_warnings_arg.patch: checks for C
misplaced_shebang.patch:checks for shebang not on
first line of script
require_portable_shebang.patch:checks for non-portable shebang line
That's completely up to you. You seem to have a knack for writing
policies, so we'd love to have the help with Perl::Critic. But
Parrot is a worthy cause too! :-) If you don't provide a P::C patch,
I'll probably do it myself eventually.
If I get the tuits I'll send a patch in for P::C :-)
Hope this helps!
Paul
Index: lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitShebangWarningsArg.pm
===
--- lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitShebangWarningsArg.pm (revision 0)
+++ lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitShebangWarningsArg.pm (revision 0)
@@ -0,0 +1,70 @@
+# $Id$
+package Perl::Critic::Policy::TestingAndDebugging::ProhibitShebangWarningsArg;
+
+use strict;
+use warnings;
+use Perl::Critic::Utils;
+use Perl::Critic::Violation;
+use base 'Perl::Critic::Policy';
+
+our $VERSION = '0.1';
+$VERSION = eval $VERSION;## no critic
+
+my $desc = q{Warnings argument of perl shebang found.'};
+my $expl = q{All perl source in parrot must 'use warnings;' not the older 'perl -w' usage};
+
+#
+
+sub default_severity { return $SEVERITY_LOW }
+sub applies_to { return 'PPI::Document' }
+
+#
+
+sub violates {
+my ( $self, $elem, $doc ) = @_;
+
+my @elements = $doc->children();
+
+# look for the shebang line, if any
+foreach my $element ( @elements) {
+# if the element isn't on the first line, it's not a valid shebang
+return if ($element->location()->[0] != 1);
+
+if ($element =~ m/^\#! .*? perl/xgs) {
+# if the shebang line matches '-w', report the violation
+if ($element =~ m/-[^w]*w/s) {
+my $sev = $self->get_severity();
+return Perl::Critic::Violation
+->new( $desc, $expl, $element, $sev );
+}
+else {
+last; # shebang line ok; skip to the end of the elements
+}
+}
+}
+
+# we didn't find any dodgy shebang lines, so return with success
+return;
+}
+
+1;
+
+__END__
+
+=head1 NAME
+
+Perl::Critic::Policy::TestingAndDebugging::ProhibitShebangWarningsArg
+
+=head1 DESCRIPTION
+
+Check to see if the old style C shebang line is used to switch on
+warnings. This should be replaced with the newer C syntax.
+
+=cut
+
+# Local Variables:
+# mode: cperl
+# cperl-indent-level: 4
+# fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:
Index: lib/Perl/Critic/Policy/TestingAndDebugging/MisplacedShebang.pm
===
--- lib/Perl/Critic/Policy/TestingAndDebugging/MisplacedShebang.pm (revision 0)
+++ lib/Perl/Critic/Policy/TestingAndDebugging/MisplacedShebang.pm (revision 0)
@@ -0,0 +1,66 @@
+# $Id$
+package Perl::Critic::Policy::TestingAndDebugging::MisplacedShebang;
+
+use strict;
+use warnings;
+use Perl::Critic::Utils;
+use Perl::Critic::Violation;
+use base 'Perl::Critic::Policy';
+
+our $VERSION = '0.1';
+$VERSION = eval $VERSION;## no critic
+
+my $desc = q{Found misplaced shebang line};
+my $expl = q{Perl source in parrot needs shebang line on first line of file};
+
+#
+
+sub default_severity { return $SEVERITY_LOW }
+sub applies_to { return 'PPI::Document' }
+
+#
+
+sub violates {
+my ( $self, $elem, $doc ) = @_;
+
+# grab all elements in the document
+my @elements = $doc->children();
+
+foreach my $element ( @elements ) {
+
+# look for a shebang line
+if ($element =~ m/^\#!/xs) {
+# if the shebang line isn't on the first line, report the
+# policy violation
+if ($element->location()->[0] != 1) {
+my $sev = $self->get_severity();
+return Perl::Critic::Violation
+->new( $desc, $expl, $element, $sev );
+}
+}
+}
+
+# we didn't find any dodgy shebang lines, so return with success
+return;
+}
+
+1;
+
+__END__
+
+=head1 NAME
+
+Perl::Critic::Policy::TestingAndDebugging::MisplacedShebang
+
+=head1 DESCRIPTION
+
+Make sure that the shebang line occurs on the first line of the file.
+
+=cut
+
+# Local Variables:
+# mode: cperl
+# cperl-indent-level: 4
+# fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:
Index: lib/Perl/Critic/Policy/TestingAndDebugging/RequirePortableShebang.pm
Re: [perl #40482] [PATCH] Perl::Critic policy for perl -w, and unix-specific shebang lines
On Oct 10, 2006, at 11:03 AM, Paul Cochrane wrote: I've been playing around for a while with the shebang line tests, and it struck me that the is_script() function will return true on your contrived example. Yeah, I saw that and fixed it in SVN yesterday. :-) It now checks that column == 1 too. Also, the fact that you mention that the shebang should be the first line lead me to think that maybe we could look for misplaced shebang lines, and report an error there as well. I've got a patch for that and can send this in too if you want. Interesting idea. You'll have to ensure it's a PPI::Token::Comment and not a PPI::Token::Quote, for example. Perhaps further discussion should move to the perlcritic.tigris.org dev mailing list or to http://rt.cpan.org/Dist/Display.html?Queue=perl-critic Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
MakeObject - an Object Instantiation Experiment
Hi all, Here's an experiment I worked on yesterday to make creating objects a little easier from PIR. The MakeObject library allows you to create an object by passing its name (or, more usefully, a Key PMC) and a set of named arguments to the initializer. It then calls the class's BUILDALL() method, if it exists, or the BUILD() methods on each class, least-to-most-derived, passing the arguments. This surprisingly removes a lot of complexity in PIR objects. -- c === runtime/parrot/library/MakeObject.pir == --- runtime/parrot/library/MakeObject.pir (revision 22977) +++ runtime/parrot/library/MakeObject.pir (local) @@ -0,0 +1,87 @@ +.include "iterator.pasm" + +.namespace [ 'MakeObject' ] + +.sub make_object + .param pmc classname + .param pmc args :slurpy :named + + .local int obj_type + find_type obj_type, classname + + .local pmc obj + obj = new obj_type + + build_all( obj, args ) + .return( obj ) +.end + +.sub build_all + .param pmc obj + .param pmc args + + .local int can_ba + can_ba = can obj, 'BUILDALL' + + unless can_ba goto do_it_yourself + obj.'BUILDALL'( args ) + .return() + + do_it_yourself: + .local pmc class_pmc + class_pmc = class obj + + .local pmc mro + mro = get_mro class_pmc + + .local pmc iter + iter = new .Iterator, mro + set iter, .ITERATE_FROM_END + + .local pmc class_pmc + .local pmc class_ns + .local pmc build_meth + .local int has_build + iter_loop: + unless iter goto iter_end + class_pmc = pop iter + class_ns = get_class_namespace( class_pmc ) + build_meth = class_ns.'find_sub'( 'BUILD' ) + + has_build = defined build_meth + unless has_build goto iter_loop + + obj.build_meth( args ) + + goto iter_loop + + iter_end: + .return() +.end + +.sub get_class_namespace + .param pmc class_pmc + + .local pmc ns + ns = get_hll_namespace + + .local string class_name + class_name = typeof class_pmc + + .local pmc name_array + name_array = split ';', class_name + + .local pmc iter + iter = new .Iterator, name_array + iter = 0 + + .local pmc elem + iter_loop: + unless iter goto iter_end + elem = shift iter + ns = ns.find_namespace( elem ) + goto iter_loop + + iter_end: + .return( ns ) +.end === t/library/make_object.pir == --- t/library/make_object.pir (revision 22977) +++ t/library/make_object.pir (local) @@ -0,0 +1,83 @@ +.sub main :main + load_bytecode 'MakeObject.pir' + + build_classes() + + .local pmc make_object + make_object = find_global 'MakeObject', 'make_object' + + .local pmc gk_name + gk_name = new .Array + gk_name = 4 + gk_name[0] = 'Grandchild' + gk_name[1] = 'Happy' + gk_name[2] = 'Fun' + gk_name[3] = 'Class' + + .local pmc gk + gk = make_object( gk_name, 'foo' => 'bar', 'baz' => 'quux' ) +.end + +.sub build_classes + .local pmc parent + parent = newclass 'Parent' + + .local pmc kid_name + .local pmc key_item + kid_name = new .Key + kid_name = 'Child' + key_item = new .Key + key_item = 'Class' + push kid_name, key_item + + .local pmc child + child = subclass 'Parent', kid_name + + .local pmc gk_name + gk_name = new .Key + gk_name = 'Grandchild' + key_item = new .Key + key_item = 'Happy' + push gk_name, key_item + key_item = new .Key + key_item = 'Fun' + push gk_name, key_item + key_item = new .Key + key_item = 'Class' + push gk_name, key_item + + .local pmc grandchild + grandchild = subclass child, gk_name +.end + +.namespace [ 'Parent' ] + +.sub BUILD :method + .param pmc args :slurpy :named + .local pmc foo + foo = args['foo'] + args['baz'] = 'fzort' + print "Build in parent\n" + print "Foo: " + print foo + print "\n" +.end + +.namespace [ 'Child'; 'Class' ] + +.sub BUILD :method + .param pmc args :slurpy :named + print "Build in child\n" +.end + +.namespace [ 'Grandchild'; 'Happy'; 'Fun'; 'Class' ] + +.sub BUILD :method + .param pmc args :slurpy :named + .local pmc baz + baz = args['baz'] + print "Build in grandchild\n" + print "Baz: " + print baz + print "\n" +.end
[svn:perl6-synopsis] r13014 - doc/trunk/design/syn
Author: larry Date: Tue Oct 10 11:57:24 2006 New Revision: 13014 Modified: doc/trunk/design/syn/S03.pod Log: For hypers, break out dimensional dwimmery from ordinary shape processing. Dwimming hyperinfixes now point the small end at the "runt". Unaries never dwim. :) Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Oct 10 11:57:24 2006 @@ -717,30 +717,62 @@ =head2 Hyper operators The Unicode characters C<»> (C<\x[BB]>) and C<«> (C<\x[AB]>) and -their ASCII digraphs C<<< >> >>> and C<<< << >>> are used to denote -"list operations", which operate on each element of two lists (or -arrays) and return a list (or array) of the results. Spaces are not -allowed on the "pointy" end of each "hyper", but are allowed on the -blunt end (except for postfix operators, which must still follow postfix -spacing rules, but do allow for an additional dot before the "hyper"). - -The precedence of any hyperoperator is the same as its base operator. -This means that you must parenthesize your lists for most operators. -For example: +their ASCII digraphs C<<< >> >>> and C<<< << >>> are used to denote a +"list operation" that operates on each element of its list (or array) +argument (or arguments) and returns a single list (or array) of +the results. In otherwords, a hyper operator evaluates its arguments in +scalar context but then distributes the operator over them as lists. + +When writing a hyper operator, spaces are not allowed on the inside, +that is, between any "hyper" marker and the operator it's modifying. +On the outside the spacing policy is the same as the base operator. +Likewise the precedence of any hyperoperator is the same as its +base operator. This means that you must parenthesize your comma +lists for most operators. For example: + -« (1,2,3)# (-1, -2, -3) (1,1,2,3,5) »+« (1,2,3,5,8); # (2,3,5,8,13) -If either argument is insufficiently dimensioned, Perl "upgrades" it: +A unary hyper operator (either prefix or postfix) has only one +hyper marker, located on its argument side, while an infix operator +always has one on each side to indicate there are two arguments. +Unary operators always produce a list or array of exactly the same +shape as their single argument. When infix operators are presented with +two lists or arrays of identical shape, a result of that same shape is +produced. Otherwise the result depends on how you write the hyper +markers. - (3,8,2,9,3,8) >>-<< 1; # (2,7,1,8,2,7) +For an infix operator, if either argument is insufficiently +dimensioned, Perl "upgrades" it, but only if you point the "sharp" end +of the hypermarker at it. -In fact, this is the I form that will work for an unordered type -such as a C: + (3,8,2,9,3,8) >>->> 1; # (2,7,1,8,2,7) + @array »+=» 42; # add 42 to each element - Bag(3,8,2,9,3,8) >>-<< 1; # Bag(2,7,1,8,2,7) === Bag(1,2,2,7,7,8) +In fact, an upgraded scalar is the only thing that will work for an +unordered type such as a C: -When using a unary operator, only put the "hyper" on the side of the -single operand: + Bag(3,8,2,9,3,8) >>->> 1; # Bag(2,7,1,8,2,7) === Bag(1,2,2,7,7,8) + +In other words, pointing the small end at an argument tells the hyperoperator +to "dwim" on that side. If you don't know whether one side or the other will +be underdimensioned, you can dwim on both sides: + +$left «*» $right + +The upgrade never happens on the "blunt" end of a hyper. If you write + +$bigger «*« $smaller +$smaller »*» $bigger + +and exception is thrown, and if you write + +$foo »*« $bar + +you are requiring the shapes to be identical, or an exception will be thrown. + +When using a unary operator, you always aim the blunt end at the +single operand, because no dwimmery every happens: @negatives = -« @positives; @@ -757,19 +789,22 @@ Note that method calls are really postfix operators, not infix, so you shouldn't put a C<«> after the dot. -Hyper operators are defined recursively on arrays, so: +Hyper operators are defined recursively on shaped arrays, so: -« [[1, 2], 3] #[-«[1, 2], -«3] # == [[-1, -2], -3] -[[1, 2], 3] »+« [4, [5, 6]] #[[1,2] »+« 4, 3 »+« [5, 6]] + +Likewise the dwimminess of dwimmy infixes propagates: + +[[1, 2], 3] «+» [4, [5, 6]] #[[1,2] «+» 4, 3 «+» [5, 6]] # == [[5, 6], [8, 9]] -More generally, hyper operators work recursively for any object +More generally, a dwimmy hyper operator works recursively for any object matching the C role even if the object itself doesn't support the operator in question: -Bag(3,8,[2,Seq(9,3)],8) >>-<< 1; # Bag(2,7,[1,Seq(8,2)],7) -Seq(3,8,[2,Seq(9,3)],8) >>-<< (1,1,2,1); # Seq
[svn:perl6-synopsis] r13015 - doc/trunk/design/syn
Author: larry Date: Tue Oct 10 12:10:23 2006 New Revision: 13015 Modified: doc/trunk/design/syn/S03.pod Log: Forgot to update version and date. Also forgot to mention self-extending lists using *. :) Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Oct 10 12:10:23 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 8 Mar 2004 - Last Modified: 28 Sept 2006 + Last Modified: 10 Oct 2006 Number: 3 - Version: 69 + Version: 70 =head1 Changes to Perl 5 operators @@ -501,6 +501,16 @@ Note: infinite lists are constructed lazily. And even though C<*..*> can't be constructed at all, it's still useful as a selector object. +For any kind of zip or dwimmy hyper operator, any list ending with C<*> +is assumed to be infinitely extensible by taking its final element +and replicating it: + +@array, * + +is short for something like: + +@[EMAIL PROTECTED], @array[-1] xx * + =item * The unary C<^> operator generates a range from C<0> up to one less than its argument. So C<^4> is short for C<0..^4> or C<0..3>.
[svn:perl6-synopsis] r13016 - doc/trunk/design/syn
Author: larry Date: Tue Oct 10 12:16:52 2006 New Revision: 13016 Modified: doc/trunk/design/syn/S03.pod Log: Clarified dwimminess relationship to * list extension. Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Oct 10 12:16:52 2006 @@ -14,7 +14,7 @@ Date: 8 Mar 2004 Last Modified: 10 Oct 2006 Number: 3 - Version: 70 + Version: 71 =head1 Changes to Perl 5 operators @@ -775,11 +775,15 @@ $bigger «*« $smaller $smaller »*» $bigger -and exception is thrown, and if you write +an exception is thrown, and if you write $foo »*« $bar you are requiring the shapes to be identical, or an exception will be thrown. +By default this dwimmery only upgrades whole dimensions, not short lists. +However, any list ending with C<*> can also be arbitrarily extended as if +the last element of the list were arbitrarily replicated C<*> times. But +this happens only on the "dwimmy" side. When using a unary operator, you always aim the blunt end at the single operand, because no dwimmery every happens:
Re: Recursing? hypers
On Sun, Oct 08, 2006 at 04:07:37PM +0200, Juerd wrote: : S03 says that hypers recurse into subarrays. : : That's a nice and useful feature, but that not-recursing is even more : useful. Especially given that many objects will probably does Array, you : want to be explicit about recursion. : : S03 doesn't give a way to avoid recursion. Recursion is not really the issue here. Conformancy is, I think. : I suggested on #perl6 that standard hypers do not recurse, and a new : operator: double hypers. These are the same, but they do recurse. From : my point of view, hypers should operate on lists, not arrays. Recursive : hypers would work on arrays because arrays are single element lists. See the latest S03 changes. Standard hypers now require conformancy, and I introduced small-ended hypers (whimpers?) to ask for dwimmery. : Audrey agreed. Audrey is very agreeable. :) : It would probably be useful to allow combinations of recursive and : non-recursive hypers. : : »+«# do not dive into arrays : »»+«« # do dive into arrays, on both sides : »+«« # dive into arrays only on the RHS : »»+« # same, but LHS : : 42, 15 »+ 1 # 43, 16 : : ( 42, 15 ) »+ 1 # 43, 16 : : [ 42, 15 ] »+ 1 # 2 : : [ 42, 15 ] »»+ 1 # [ 43, 16 ] : : The ASCII variant is a bit big, but that's okay huffmanwise, IMO. : Recursion can be a pretty big operation anyway. Being explicit about : that is good. I think the current S03 solution is a lot prettier, and keeps most of the symmetry of the old hyper solution, while visually indicating the "smaller" argument: @foo »+» 1 For the old symmetrically dwimmy infix hyper behavior you just write: @foo «+» @bar Larry
[svn:perl6-synopsis] r13019 - doc/trunk/design/syn
Author: larry Date: Tue Oct 10 13:09:12 2006 New Revision: 13019 Modified: doc/trunk/design/syn/S03.pod Log: typo from wolverian++ Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Oct 10 13:09:12 2006 @@ -786,7 +786,7 @@ this happens only on the "dwimmy" side. When using a unary operator, you always aim the blunt end at the -single operand, because no dwimmery every happens: +single operand, because no dwimmery ever happens: @negatives = -« @positives;
Re: [svn:perl6-synopsis] r12875 - doc/trunk/design/syn
[EMAIL PROTECTED] skribis 2006-10-09 0:22 (-0700):
> P5's s[pat][repl] syntax is dead, now use s[pat] = "repl"
Why keep the s?
substr works perfectly as both rvalue and lvalue, and I think m[], also
known as //, can do the same. No need to do things based on delimiter
(bracket versus non-bracket), then.
> + s[pattern] = doit()
m[pattern] = doit();
/pattern/ = doit();
> + $str.subst(/pat/, "replacement");
> + $str.subst(/pat/, {"replacement"});
> + $str.=subst(/pat/, "replacement");
> + $str.=subst(/pat/, {"replacement"});
Hmmm... I have no answer for the non-mutating version, but:
$str.match(/pat/) = "replacement";
$str.m(/pat) = "replacement";
> +This is not a normal assigment, since the right side is evaluated each
> +time the substitution matches
Can't this be generalized somehow? Return an lvalue proxy, like substr
does, and make thunking the default for certain LHS types.
I don't like special syntax that looks like normal syntax.
--
korajn salutojn,
juerd waalboer: perl hacker <[EMAIL PROTECTED]>
convolution: ict solutions and consultancy <[EMAIL PROTECTED]>
Ik vertrouw stemcomputers niet.
Zie
Re: [svn:perl6-synopsis] r12875 - doc/trunk/design/syn
On Tue, Oct 10, 2006 at 10:49:11PM +0200, Juerd wrote:
: [EMAIL PROTECTED] skribis 2006-10-09 0:22 (-0700):
: > P5's s[pat][repl] syntax is dead, now use s[pat] = "repl"
:
: Why keep the s?
Because @Larry felt it was better to keep the intent out in front.
: substr works perfectly as both rvalue and lvalue, and I think m[], also
: known as //, can do the same. No need to do things based on delimiter
: (bracket versus non-bracket), then.
:
: > + s[pattern] = doit()
:
: m[pattern] = doit();
: /pattern/ = doit();
We thought about that, but the intent is obscured.
: > + $str.subst(/pat/, "replacement");
: > + $str.subst(/pat/, {"replacement"});
: > + $str.=subst(/pat/, "replacement");
: > + $str.=subst(/pat/, {"replacement"});
:
: Hmmm... I have no answer for the non-mutating version, but:
:
: $str.match(/pat/) = "replacement";
: $str.m(/pat) = "replacement";
And I even predicted somewhere that someone would immediately ask for
a method form of pseudo-assignment. But macros and dynamic dispatch
don't mix well, and I think if you really want the macro it's just
about as easy to write:
$str ~~ s(/pat) = "replacement";
: > +This is not a normal assigment, since the right side is evaluated each
: > +time the substitution matches
:
: Can't this be generalized somehow? Return an lvalue proxy, like substr
: does, and make thunking the default for certain LHS types.
Well, I'm not sure I like that much hidden run-time apparatus, and it doesn't
solve the basic macroish problem that the replacement has to be a lazy thunk.
: I don't like special syntax that looks like normal syntax.
Then by all means also avoid these:
has $.answer = 42;
state $s = 0;
:-)
Larry
Re: [svn:perl6-synopsis] r12875 - doc/trunk/design/syn
On Tue, Oct 10, 2006 at 02:17:50PM -0700, Larry Wall wrote: : $str ~~ s(/pat) = "replacement"; Er, cut-n-paste error. Make that: $str ~~ s[pat] = "replacement"; Larry
Capturing subexpression numbering example
The example in S05 under "Subpattern numbering" isn't quite complex enough to give the reader a full understanding of the ramifications of the re-numbering that occurs with alternations, especially with respect to the combination of capturing and non-capturing subpatterns. I've written a small example and explanation to address this (attached as diff) based on an IRC conversation with fglock. If it's deemed correct, could this be included, please? --- Rule.pod.orig 2006-10-10 17:26:39.0 -0400 +++ Rule.pod 2006-10-10 17:37:17.0 -0400 @@ -1956,6 +1956,21 @@ C<(undef, undef, undef, undef, undef, undef, 'every', 'green', 'BEM', 'devours', 'faces')> (as the same regex would in Perl 5). +If non-capturing brackets are used, this can become more complex. +Every time C<|> appears inside of non-capturing brackets, the subpattern +index is returned to the index that it had when entering the +brackets. When exiting the brackets, the next capturing subpattern +will have an index one higher than the highest subpattern inside +the non-capturing brackets. Here is such an example: + +#$0$1 $2$1$3 +$match = rx/ (a) [ (b) (c) | (d) ] (e) /; + +Notice that it is not the most recent C<$1> that determines +the index of the C<(e)> subpattern, but the C<(c)> subpattern that +incremented the index to C<$2>. Therefore C<(e)> has an index +of C<$3>. + =item * Note that it is still possible to mimic the monotonic Perl 5 capture
Re: Nitpick my Perl6 - parametric roles
At 4:08 PM +0200 10/10/06, TSa wrote: HaloO, Darren Duncan wrote: Within a system that already has an underlying set-like type, the Junction in this case, a test for uniqueness is (pardon any spelling): all(@items).elements.size === @items.size The all() will strip any duplicates, so if the number of elements in all(@items) is the same as @items, then @items has no duplicates. OK, but you are not using the 'set with additional behavior' of junctions. How would that be spelled with a pure set? set(@items).elements.size === @items.size perhaps? This would nicely blend with the junction forms. Yes, that is exactly how it would be spelled with a pure set. In fact, your example is the more normal one, in that simply turning a collection into a set removes duplicates. I used all() in my example because that is the Junction equivalent of making a set that contains all distinct members of @items. -- Darren Duncan
Re: MakeObject - an Object Instantiation Experiment
On Tuesday 10 October 2006 12:23, Leopold Toetsch wrote:
> PPS: new opcode variant count is 20 now.
>
> I can imagine that we just have these:
>
> new P0, .Class # plain form
> new P0, .Class,
> new P0, [class],
Is a PMC (Hash) or a list of named arguments? Creating a Hash for
every initializer is a real bummer in PIR.
(It makes me want to suggest that, just as [ class ] creates a Key PMC behind
the scenes, so { key => value } creates a Hash PMC.)
-- c
Re: MakeObject - an Object Instantiation Experiment
Am Dienstag, 10. Oktober 2006 20:41 schrieb chromatic: > Hi all, > > Here's an experiment I worked on yesterday to make creating objects a > little easier from PIR. For reference: Subject: PMC and object creation http://groups.google.de/group/perl.perl6.internals/browse_frm/thread/e68dc0a0a96585b7/462023a5939b0844?lnk=st&q=toetsch++new+opcodes&rnum=30#462023a5939b0844 PS: the examples are w/o syntactic sugar support for making the 'new/instantiate' thingy any nicer. It's just an experiment how it could work. The basics are: it combines all the flexible argument passing features we already have with object instantiation. PPS: new opcode variant count is 20 now. I can imagine that we just have these: new P0, .Class # plain form new P0, .Class, new P0, [class], leo
Re: MakeObject - an Object Instantiation Experiment
Am Dienstag, 10. Oktober 2006 21:32 schrieb chromatic: > > new P0, [class], > > Is a PMC (Hash) or a list of named arguments? Creating a Hash for > every initializer is a real bummer in PIR. As said, ought to be everything conforming to current calling conventions. o = new .TypeId, 1, 'baz', 'x' => 'foo', 'y' => 42 or whatever - that's the plan(tm). leo
Re: Coroutines in Lua
From: François PERRAD <[EMAIL PROTECTED]> Date: Tue, 10 Oct 2006 13:39:30 +0200 Thank for your long response. I included your code in languages/lua/lib/luacoroutine.pir (r14877). I encountered 2 problems : 1) coroutine_yield needs a current coroutine (not surprising) Yes, this is the "implicit current coroutine" problem I mentioned. I think this is best solved with a dynamically-bound variable, the value of which Lua's "coroutine.running" can just return. 2) I want replace the LuaThread PMC by a PIR classe . . . some test of languages/lua/t/coroutine.t fail with the following message : FixedPMCArray: index out of bounds! François. On Sunday, to see if it would work, I created a Parrot::Coroutine class, and it works like a charm. I haven't committed it yet because it needs a test case. This will be an extended version of the "same fringe" demo but converted into a proper example; it's also an excellent workout for closures. So please stay tuned. -- Bob
Runtime Role Issues
Hi all, In doing a bit of work with traits (roles) in Perl 5 (http://perlmonks.org/?node_id=577477), I've realized some edge cases which could be problematic. First, when a role is applied to a class at runtime, a instance of that class in another scope may specifically *not* want that role. Is there a way of restricting a role to a particular lexical scope short of merely applying that role to instances instead of classes? Second, how can I remove roles from classes? I've create some code which adds an "is_selected" method to some classes but when I'm done, I'd like top easily remove that role. How do I do that? Seems closely related to my first question, but it's still a distinct issue, I think. Third, http://dev.perl.org/perl6/doc/design/syn/S12.html says: You can also mixin a precomposed set of roles: $fido does Sentry | Tricks | TailChasing | Scratch; Should that be the following? $fido does Sentry & Tricks & TailChasing & Scratch; Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
[svn:perl6-synopsis] r13022 - doc/trunk/design/syn
Author: larry Date: Tue Oct 10 16:55:33 2006 New Revision: 13022 Modified: doc/trunk/design/syn/S03.pod Log: Clarification of non-ambiguity of «*» Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Oct 10 16:55:33 2006 @@ -770,6 +770,15 @@ $left «*» $right +[Note: if you are worried about Perl getting confused by something like this: + +foo «*» + +then you shouldn't worry about it, because unlike previous versions, +Perl 6 never guesses whether the next thing is a term or operator. +In this case it is always expecting a term unless C is predeclared +to be a 0-ary sub.] + The upgrade never happens on the "blunt" end of a hyper. If you write $bigger «*« $smaller
Re: class interface of roles
TSa wrote: TSa wrote: Note that the superclass interface of roles should be mostly inferred from the usage of next METHOD. As such it is a useful guidance for error reports in the class composition process. Actually 'next METHOD' doesn't catch all superclass interface issues. There is the simple case of calling e.g. accessor methods on super which should result in the requirement to provide them. So I still propose a super keyword that in roles means the object as seen from the uncomposed class. I think the word "super" is already to overloaded to be used for this purpose. Setting that aside for now... Do you mean that super.blah() appearing in a method defined in a role A should require that all classes which do A need to provide a blah implementation? (or produce a composition time error if they don't) I'd prefer to have a declarative mechanism for specifying such requirements. Firstly for self-documenting clarity, there's no need to scan for a "super", and secondly because eval and super.$method_name would allow runtime failures. Some alternatives appeared elsewhere in this thread but it's unclear whether they would produce error at composition time or at runtime. (yada methods) The same applies to the "next METHOD" inference suggested: Note that the superclass interface of roles should be mostly inferred from the usage of next METHOD. A Role should be able to say "to do this Role you need to implement these methods" and have a compile/composition time error if not. (There does need to be a way to call, in a Role A, both the "blah" defined in A and whatever the "blah" the final class may use. $self.blah() is the later, $self.A::blah() or similar is likely to be the former.) Brad -- When one is not capable of true intelligence, it is good to consult with someone of good sense. -- Hagakure http://bereft.net/hagakure/
Re: class interface of roles
Brad Bowman wrote: TSa wrote: > TSa wrote: >> Note that the superclass interface of roles should be mostly inferred >> from the usage of next METHOD. As such it is a useful guidance for >> error reports in the class composition process. > > Actually 'next METHOD' doesn't catch all superclass interface issues. > There is the simple case of calling e.g. accessor methods on super > which should result in the requirement to provide them. So I still > propose a super keyword that in roles means the object as seen from > the uncomposed class. What do you mean by "uncomposed class"? I think the word "super" is already to overloaded to be used for this purpose. Setting that aside for now... Do you mean that super.blah() appearing in a method defined in a role A should require that all classes which do A need to provide a blah implementation? (or produce a composition time error if they don't) I hope not; that's exactly what declaring an unimplemented method in a role is supposed to do. (And declaring an implemented method does the same thing, with the addition that it also suggests an implementation that the class is free to use or ignore as it sees fit.) The same applies to the "next METHOD" inference suggested: > Note that the superclass interface of roles should be mostly inferred > from the usage of next METHOD. A Role should be able to say "to do this Role you need to implement these methods" and have a compile/composition time error if not. Agreed. (There does need to be a way to call, in a Role A, both the "blah" defined in A and whatever the "blah" the final class may use. $self.blah() is the later, $self.A::blah() or similar is likely to be the former.) No, there doesn't. Given that C and C, There needs to be a way to call, in class Foo, both the "blah" defined in Foo, the "blah" defined in A (so that Foo can reimplement A's version as a different method or as part of its own), and the "blah" defined in B; and there needs to be a way to call, in role A, both the "blah" defined in Foo and the "blah" defined B; but role A does not need a way to explicitly call a method defined in A. It should assume that if Foo overrides A's implementation of blah, Foo knows what it's doing; by the principle of least surprise, Foo should never end up overriding A's implementation of blah only to find that the original implementation is still being used by another of the methods acquired from A. -- Jonathan "Dataweaver" Lang
Re: class interface of roles
TSa wrote:
Jonathan Lang wrote:
> TSa wrote:
> > Dispatch depends on a partial ordering of roles.
>
> Could someone please give me an example to illustrate what is meant by
> "partial ordering" here?
In addition to Matt Fowles explanation I would like to
give the following example lattice build from the roles
role A { has $.x }
role B { has $.y }
role C { has $.z }
There can be the four union combined roles A|B, A|C, B|C
and A|B|C which complete the type lattice:
Any={}
/ | \
/ | \
/|\
/ | \
/ | \
A={x} B={y} C={z}
| \/ \/ |
| \ / \ / |
| \/ \/ |
| /\ /\ |
| / \ / \ |
| /\ /\ |
A|B={x,y} A|C={x,z} B|C={y,z}
\ | /
\ | /
\|/
\ | /
\ | /
A|B|C={x,y,z}
So if I'm reading this right, a class that does both A and B should be
"lower" in the partial ordering than a class that does just one or the
other. And if A does B, then you'll never have a class that does just
A without also doing B, which trims out a few possible nodes and paths
from the lattice for practical purposes:
Any={}
| \
| \
|\
| \
| \
B={y} C={z}
/ \ |
/ \ |
/ \|
/ \ |
/ \ |
/ \ |
A|B={x,y} B|C={y,z}
\ /
\ /
\ /
\ /
\ /
A|B|C={x,y,z}
I note that while the lattice is related to whatever role hierarchies
may or may not exist, it is not the same as them. In particular,
roles that have no hierarchal relationship to each other _will_ exist
in the same lattice. In fact, all roles will exist in the same
lattice, on the first row under "Any". Right? Or does the fact that
"A does B" mean that A would be placed where "A|B" is, and "A|C" would
end up in the same node as "A|B|C"?
This lattice can then be used for type checks and specificity
comparisons in dispatch. BTW, such a lattice can be calculated lazily
from any set of packages. In pure MMD the selected target has to be
the most specific in all dispatch relevant positions.
By "most specific", you'd mean "closest to the top"?
--
Jonathan "Dataweaver" Lang
[svn:parrot-pdd] r14888 - in trunk: . apps/p3 apps/p3/cgi-pir cage compilers/json compilers/json/JSON config/auto config/auto/cpu/i386 config/auto/cpu/ppc config/auto/cpu/sun4 config/auto/cpu/x86_64 c
Author: coke Date: Tue Oct 10 19:16:37 2006 New Revision: 14888 Modified: trunk/docs/pdds/clip/pddXX_cstruct.pod (props changed) trunk/docs/pdds/clip/pddXX_pmc.pod (props changed) Changes in other areas also in this revision: Modified: trunk/ (props changed) trunk/apps/p3/README (props changed) trunk/apps/p3/cgi-pir/slides.pir (props changed) trunk/apps/p3/index.html (props changed) trunk/apps/p3/p3p.css (props changed) trunk/apps/p3/p3p.html (props changed) trunk/apps/p3/slides.js (props changed) trunk/cage/consting.pod (props changed) trunk/compilers/json/JSON.pir (props changed) trunk/compilers/json/JSON/grammar.pg (props changed) trunk/compilers/json/JSON/pge2pir.tg (props changed) trunk/compilers/json/postalcodes.pir (contents, props changed) trunk/compilers/json/test.pir (props changed) trunk/config/auto/cpu.pm (contents, props changed) trunk/config/auto/cpu/i386/auto.pm (contents, props changed) trunk/config/auto/cpu/i386/test_gcc_cmpxchg.in (props changed) trunk/config/auto/cpu/ppc/auto.pm (contents, props changed) trunk/config/auto/cpu/ppc/test_gcc_cmpset.in (props changed) trunk/config/auto/cpu/sun4/auto.pm (contents, props changed) trunk/config/auto/cpu/sun4/test_atomic.in (props changed) trunk/config/auto/cpu/x86_64/auto.pm (props changed) trunk/config/gen/makefiles/ext.in (contents, props changed) trunk/config/gen/makefiles/json.in (props changed) trunk/config/init/install.pm (contents, props changed) trunk/docs/parrothist.pod (props changed) trunk/docs/pcc_state.pod (props changed) trunk/docs/stm/atomic.pod (props changed) trunk/docs/stm/howto.pod (props changed) trunk/docs/stm/internals.pod (props changed) trunk/docs/stm/stm_frontend.pod (contents, props changed) trunk/docs/stm/thread-issues.pod (props changed) trunk/examples/io/async_select.pir (contents, props changed) trunk/examples/io/httpd2.pir (contents, props changed) trunk/examples/pge/grammars/IO.pg (props changed) trunk/examples/sdl/mandel.pir (contents, props changed) trunk/examples/shootout/ack.pir.output (props changed) trunk/examples/shootout/binarytrees.pir.output (props changed) trunk/examples/shootout/fannkuch.pir.output (props changed) trunk/examples/shootout/fasta.pir.output (props changed) trunk/examples/shootout/knucleotide.pir.input (props changed) trunk/examples/shootout/knucleotide.pir.output (props changed) trunk/examples/shootout/nbody.pir.output (props changed) trunk/examples/shootout/nsieve-bits-2.pir.output (props changed) trunk/examples/shootout/nsieve-bits.pir.output (props changed) trunk/examples/shootout/nsieve.pir.output (props changed) trunk/examples/shootout/partialsums-2.pir.output (props changed) trunk/examples/shootout/partialsums.pir.output (props changed) trunk/examples/shootout/pidigits.pir.output (props changed) trunk/examples/shootout/recursive-2.pir.output (props changed) trunk/examples/shootout/recursive.pir.output (props changed) trunk/examples/shootout/regexdna.pir.input (props changed) trunk/examples/shootout/regexdna.pir.output (props changed) trunk/examples/shootout/revcomp.pir.input (props changed) trunk/examples/shootout/revcomp.pir.output (props changed) trunk/examples/shootout/spectralnorm.pir.output (props changed) trunk/examples/shootout/sumcol.pir.input (props changed) trunk/examples/shootout/sumcol.pir.output (props changed) trunk/examples/shootout/takfp.pir.output (props changed) trunk/ext/Parrot-Embed/Build.PL (props changed) trunk/ext/Parrot-Embed/Changes (props changed) trunk/ext/Parrot-Embed/MANIFEST (props changed) trunk/ext/Parrot-Embed/README (props changed) trunk/ext/Parrot-Embed/TODO (props changed) trunk/ext/Parrot-Embed/lib/Parrot/Embed.pm (props changed) trunk/ext/Parrot-Embed/lib/Parrot/Embed.xs (props changed) trunk/ext/Parrot-Embed/lib/Parrot/Interpreter.pm (props changed) trunk/ext/Parrot-Embed/lib/Parrot/PMC.pm (props changed) trunk/ext/Parrot-Embed/t/embed.t (props changed) trunk/ext/Parrot-Embed/t/greet.pir (props changed) trunk/ext/Parrot-Embed/t/interp.t (props changed) trunk/ext/Parrot-Embed/typemap (props changed) trunk/include/parrot/atomic.h (props changed) trunk/include/parrot/atomic/fallback.h (props changed) trunk/include/parrot/atomic/gcc_pcc.h (props changed) trunk/include/parrot/atomic/gcc_x86.h (props changed) trunk/include/parrot/atomic/sparc.h (props changed) trunk/include/parrot/stm/backend.h (props changed) trunk/languages/WMLScript/src/WMLScript.pir (contents, props changed) trunk/languages/WMLScript/t/libstring.t (contents, props changed) trunk/languages/WMLScript/t/runtime.t (contents, props changed) trunk/languages/c99/c99.pir (props
