Re: Test::Kwalitee 0.10
Hi!
On Thu, Feb 16, 2006 at 08:02:27AM +0100, Andreas J. Koenig wrote:
> I've just opened a ticket on RT about the issue.
A new version is on it's way to CPAN.
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Param count mismatch errors are on now
As discussed since quite a time and specced in pdd03, param count mismatches throw an exception. Use :optional or :slurpy args if needed, or just fix function calls and/or .param directives to prevent that error. Below is a list of currently (r11570) failing core tests. Please note that return/result count mismatches are still not checked. Fixes welcome, I'll try to resolve some too. leo Failed Test Stat Wstat Total Fail Failed List of Failed --- t/compilers/imcc/syn/objects.t 1 256111 9.09% 5 t/compilers/imcc/syn/pcc.t 1 256211 4.76% 7 t/configure/configure.t 255 65280243 12.50% 23-24 t/examples/streams.t 7 1792127 58.33% 1-3 5-8 t/library/dumper.t 2 512272 7.41% 12-13 t/library/parrotlib.t 1 256 61 16.67% 6 t/library/streams.t8 2048208 40.00% 9-11 13-16 19 t/library/test_builder_tester.t1 256128 66.67% 9-12 t/library/test_more.t 1 25620 40 200.00% 1-20 t/pmc/coroutine.t 1 256101 10.00% 2 t/pmc/mmd.t1 256311 3.23% 11 t/pmc/object-meths.t 1 256331 3.03% 12 9 tests and 369 subtests skipped. Failed 12/228 test scripts, 94.74% okay. 49/4529 subtests failed, 98.92% okay.
retrieving bugs from the gulag
There were a large number of open and owner-less bugs in the Parrot bug queue (48 after a cleaning up about half a dozen). I've changed the status on all of these bugs to 'new' as it's really not appropriate to have open and ownerless bugs (can we change RT's behavior to stop change the status to open if there's no owner?). I'd like to ask everyone with RT privs to take a few minutes to look at the 'new' queue and attempt to resolve 2 or 3 bugs. Thanks, -J -- pgp1ta2eiy0GF.pgp Description: PGP signature
Re: Next release ...
On Thu, Feb 16, 2006 at 01:42:50AM +0100, Leopold Toetsch wrote: > The next release is delayed a bit, you might already have noticed that. > > The reason is: GPW (German Perl Workshop) is at the beginning of March, > then a hackaton with Audrey will follow. This would collide with the > March release. Therefore I've postponed this release until next week. > > BTW: I'm inclined to turn on strict argument/param count checking (not > return values yet) tomorrow. Any opinions WRT that? I'm in favor of it. If something in PGE breaks, I'll be available (and willing) to fix it. Pm
Re: [perl #38549] pod check test checks wrong files
I've checked this in as r11565 but with some cleanup (not everything needed to be in a BEGIN block, etc.). I believe Joshua Isom and myself have also fixed all of the newly caught Pod syntax errors. I'll be closing out this bug momentarily. Cheers, -J -- On Wed, Feb 15, 2006 at 06:44:12PM -0500, Will Coleda wrote: > Looks good. I note that it doesn't include something I thought I had > already committed. Here's a suggested alternative that fails fast > instead of slow if *either* module isn't installed, and includes your > changes. > > > > > > On Feb 15, 2006, at 5:41 PM, Joshua Hoblitt wrote: > > >On Tue, Feb 14, 2006 at 11:52:55PM -1000, Joshua Hoblitt wrote: > >>On Tue, Feb 14, 2006 at 05:23:39PM -0800, Will Coleda wrote: > >>>2) checks every file with pod in that directory hierarchy. > >>> > >>>It should only check those files that are in MANIFEST. (And > >>>*possibly* MANIFEST.generated) > >> > >>It's trivial to parse those files but is there a pre-existing parser > >>module I don't know about? There's no point in getting locked > >>into the > >>current format if we don't have to. > > > >It turns out there is a 'maniread()' function in ExtUtils::Manifest > >that > >I'd overlooked. > > > >Attached is a patch to t/doc/pod.t that changes it to only test > >files in > >MANIFEST & MANIFEST.generated. It also induces a change in what's > >considered a 'Pod' file. Currently only files named 'foo.pod', > >'foo.pl', 'foo.pm' are being tested for containing pod. This patch > >tests all files in MANIFEST, including '.c' files, to see if they > >contain pod. I'd like to get some feedback about this change before > >committing the patch. > > > >Cheers, > > > >-J > > > >-- > > > pgpE8y1XxBBzV.pgp Description: PGP signature
Next release ...
The next release is delayed a bit, you might already have noticed that. The reason is: GPW (German Perl Workshop) is at the beginning of March, then a hackaton with Audrey will follow. This would collide with the March release. Therefore I've postponed this release until next week. BTW: I'm inclined to turn on strict argument/param count checking (not return values yet) tomorrow. Any opinions WRT that? leo
Re: Test::Kwalitee 0.10
> On Tue, 14 Feb 2006 21:15:01 -0800, chromatic <[EMAIL PROTECTED]> said: > Hi all, > I've released a snapshot of the long-promised Test::Kwalitee. Internally, it > uses the CPANTS code to analyze a module along 13 of the Kwalitee indicators. > I recommend using this in developer tests before distributing a module > publicly. > I haven't written any documentation besides the t/01-kwalitee.t file, but > using it is straightforward. I'll be sure to add more explanation and such > before releasing it more publicly. > http://wgz.org/chromatic/perl/Test-Kwalitee.tar.gz The prerequisite Module::CPANTS::Analyse can currently not be installed because it relies on sme YAML import feature: t/analyse.."all" is not defined in %YAML::EXPORT_TAGS at /usr/local/[EMAIL PROTECTED]/lib/site_perl/5.9.4/YAML.pm line 5 cannot load Module::CPANTS::Kwalitee::Prereq: Can't continue after import errors at /home/k/.cpan/build/Module-CPANTS-Analyse-0.5/blib/lib/Module/CPANTS/Kwalitee/Prereq.pm line 5 BEGIN failed--compilation aborted at /home/k/.cpan/build/Module-CPANTS-Analyse-0.5/blib/lib/Module/CPANTS/Kwalitee/Prereq.pm line 5. Compilation failed in require at (eval 13) line 3. at /home/k/.cpan/build/Module-CPANTS-Analyse-0.5/blib/lib/Module/CPANTS/Analyse.pm line 27 # Looks like your test died before it could output anything. t/analyse..dubious This will give you plenty of minus points:) Thomas, I'e tried YAML 0.57 and 0.58, both with bleadperl. The harness output is good for a laugh, actually: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/analyse.t255 6528010 20 200.00% 1-10 t/calc.t 255 6528011 22 200.00% 1-11 t/plugins.t255 65280 5 10 200.00% 1-5 t/testdir.t255 65280 24 200.00% 1-2 t/testfile.t 255 65280 36 200.00% 1-3 t/unpack.t 255 65280 5 10 200.00% 1-5 t/unpack_notextractable.t 255 65280 24 200.00% 1-2 Failed 7/10 test scripts, 30.00% okay. 38/56 subtests failed, 32.14% okay. -- andreas
Re: [perl #38549] pod check test checks wrong files
I'd say anything in languages/ should be ignored, because those should be the responsibility of the language maintainer to test. But I've just completed fixing all the broken pods(and a few that aren't invalid bug are broken) except those in languages/, plus languages/t/harness. I haven't committed it yet. On Feb 15, 2006, at 4:41 PM, Joshua Hoblitt wrote: On Tue, Feb 14, 2006 at 11:52:55PM -1000, Joshua Hoblitt wrote: ... ... MANIFEST & MANIFEST.generated. It also induces a change in what's considered a 'Pod' file. Currently only files named 'foo.pod', 'foo.pl', 'foo.pm' are being tested for containing pod. This patch tests all files in MANIFEST, including '.c' files, to see if they contain pod. I'd like to get some feedback about this change before committing the patch. Cheers, -J --
Re: [perl #38549] pod check test checks wrong files
Seems reasonable. I'll commit it once I've fixed the 32 files now being tested that have Pod errrors. -J -- On Wed, Feb 15, 2006 at 06:44:12PM -0500, Will Coleda wrote: > Looks good. I note that it doesn't include something I thought I had > already committed. Here's a suggested alternative that fails fast > instead of slow if *either* module isn't installed, and includes your > changes. > > > > > > On Feb 15, 2006, at 5:41 PM, Joshua Hoblitt wrote: > > >On Tue, Feb 14, 2006 at 11:52:55PM -1000, Joshua Hoblitt wrote: > >>On Tue, Feb 14, 2006 at 05:23:39PM -0800, Will Coleda wrote: > >>>2) checks every file with pod in that directory hierarchy. > >>> > >>>It should only check those files that are in MANIFEST. (And > >>>*possibly* MANIFEST.generated) > >> > >>It's trivial to parse those files but is there a pre-existing parser > >>module I don't know about? There's no point in getting locked > >>into the > >>current format if we don't have to. > > > >It turns out there is a 'maniread()' function in ExtUtils::Manifest > >that > >I'd overlooked. > > > >Attached is a patch to t/doc/pod.t that changes it to only test > >files in > >MANIFEST & MANIFEST.generated. It also induces a change in what's > >considered a 'Pod' file. Currently only files named 'foo.pod', > >'foo.pl', 'foo.pm' are being tested for containing pod. This patch > >tests all files in MANIFEST, including '.c' files, to see if they > >contain pod. I'd like to get some feedback about this change before > >committing the patch. > > > >Cheers, > > > >-J > > > >-- > > > pgp5flwCdzyU1.pgp Description: PGP signature
Re: [perl #38549] pod check test checks wrong files
Looks good. I note that it doesn't include something I thought I had already committed. Here's a suggested alternative that fails fast instead of slow if *either* module isn't installed, and includes your changes. counteroffer.patch Description: Binary data On Feb 15, 2006, at 5:41 PM, Joshua Hoblitt wrote: On Tue, Feb 14, 2006 at 11:52:55PM -1000, Joshua Hoblitt wrote: On Tue, Feb 14, 2006 at 05:23:39PM -0800, Will Coleda wrote: 2) checks every file with pod in that directory hierarchy. It should only check those files that are in MANIFEST. (And *possibly* MANIFEST.generated) It's trivial to parse those files but is there a pre-existing parser module I don't know about? There's no point in getting locked into the current format if we don't have to. It turns out there is a 'maniread()' function in ExtUtils::Manifest that I'd overlooked. Attached is a patch to t/doc/pod.t that changes it to only test files in MANIFEST & MANIFEST.generated. It also induces a change in what's considered a 'Pod' file. Currently only files named 'foo.pod', 'foo.pl', 'foo.pm' are being tested for containing pod. This patch tests all files in MANIFEST, including '.c' files, to see if they contain pod. I'd like to get some feedback about this change before committing the patch. Cheers, -J --
Re: [perl #38549] pod check test checks wrong files
On Tue, Feb 14, 2006 at 11:52:55PM -1000, Joshua Hoblitt wrote:
> On Tue, Feb 14, 2006 at 05:23:39PM -0800, Will Coleda wrote:
> > 2) checks every file with pod in that directory hierarchy.
> >
> > It should only check those files that are in MANIFEST. (And
> > *possibly* MANIFEST.generated)
>
> It's trivial to parse those files but is there a pre-existing parser
> module I don't know about? There's no point in getting locked into the
> current format if we don't have to.
It turns out there is a 'maniread()' function in ExtUtils::Manifest that
I'd overlooked.
Attached is a patch to t/doc/pod.t that changes it to only test files in
MANIFEST & MANIFEST.generated. It also induces a change in what's
considered a 'Pod' file. Currently only files named 'foo.pod',
'foo.pl', 'foo.pm' are being tested for containing pod. This patch
tests all files in MANIFEST, including '.c' files, to see if they
contain pod. I'd like to get some feedback about this change before
committing the patch.
Cheers,
-J
--
=== t/doc/pod.t
==
--- t/doc/pod.t (revision 11560)
+++ t/doc/pod.t (local)
@@ -5,8 +5,9 @@
use strict;
use warnings;
use lib qw( . lib ../lib ../../lib );
-use vars qw( %docs $n_docs );
+use vars qw(@docs);
use Parrot::Config;
+use ExtUtils::Manifest qw(maniread);
BEGIN {
eval "use Pod::Find";
@@ -14,18 +15,23 @@
print "1..1\nok 1 # skip Pod::Find not installed\n";
exit;
}
+
# XXX this should really be using src_dir insetad of build_dir but it
# doesn't exist (yet)
-%docs = Pod::Find::pod_find(
-{ -verbose => 0, -inc => 0 },
-$PConfig{build_dir} # search path(s)
-);
+my $build_dir = $PConfig{build_dir};
+my $manifest = maniread("$build_dir/MANIFEST");
+my $manifest_gen = maniread("$build_dir/MANIFEST.generated");
-$n_docs = scalar keys %docs;
+foreach my $file (keys(%$manifest), keys(%$manifest_gen)) {
+$file = "$build_dir/$file";
+# skip missing MANIFEST.generated files
+next unless -e $file;
+push @docs, $file if Pod::Find::contains_pod($file, 0);
+}
}
-use Test::More tests => $n_docs;
+use Test::More tests => scalar @docs;
=head1 NAME
@@ -45,6 +51,6 @@
eval "use Test::Pod 0.95";
SKIP: {
-skip "Test::Pod 0.95 not installed.", $n_docs if $@;
-Test::Pod::pod_file_ok( $_ ) foreach keys %docs;
+skip "Test::Pod 0.95 not installed.", scalar @docs if $@;
+Test::Pod::pod_file_ok( $_ ) foreach @docs;
}
pgprJD8ONG4va.pgp
Description: PGP signature
Re: Test::Kwalitee 0.10
On Wednesday 15 February 2006 12:33, Andreas J. Koenig wrote: > The prerequisite Module::CPANTS::Analyse can currently not be > installed because it relies on sme YAML import feature: Ahh right, I forgot to mention I removed the ':all' import request in that module manually. Everything still worked for my purposes. -- c
svn access (was: [perl #38576] [PATCH] Make DETAIL_MEMORY_DEBUG work. )
On Feb 15, 2006, at 18:53, Andy Dougherty (via RT) wrote: # New Ticket Created by Andy Dougherty Andy, I've already asked once: don't you have svn access? If no (and if you want it) please mail me your auth.perl.org account data, to get you svn priv bits. If yes, I'd really prefer that such patches just go in. And honestly all your patches are well-thought and hight quality. Thanks, leo
Re: [perl #38577] [PATCH] Reduce memory consumption of t/pmc/resizablebooleanarray_17.pasm
On 2/15/06, via RT Andy Dougherty <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Andy Dougherty
> # Please include the string: [perl #38577]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/rt3/Ticket/Display.html?id=38577 >
>
>
> Would there be any objection to cutting the size of memory required by
> t/pmc/resizablebooleanarray_17.pasm in half? As is, it's sometimes
> hitting PANIC("Out of mem") for me. I don't think there's anything
> fundamental about the number 1,100,000 used in the test.
>
no objection at all, applied as r11553.
> (My system is PANIC-ing when asked for a realloc of 64MB. I suppose you
> could also regard it as a bug that we're apparently using 64 bytes to
> store each bit of information :-).
>
definitely a bug. i'll forward that to dino, who's promised to pick up
his work on the ResizableBooleanArray PMC again. in the meantime, i'll
leave this ticket open, and we'll revisit when the kinks have been
worked out of RBA.
> Alternatively, I suppose you could reasonab
>
??? hope this wasn't terribly important, it seems too have been lost
in transmission.
thanks for submitting.
~jerry
[perl #38577] [PATCH] Reduce memory consumption of t/pmc/resizablebooleanarray_17.pasm
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #38577]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38577 >
Would there be any objection to cutting the size of memory required by
t/pmc/resizablebooleanarray_17.pasm in half? As is, it's sometimes
hitting PANIC("Out of mem") for me. I don't think there's anything
fundamental about the number 1,100,000 used in the test.
(My system is PANIC-ing when asked for a realloc of 64MB. I suppose you
could also regard it as a bug that we're apparently using 64 bytes to
store each bit of information :-).
Alternatively, I suppose you could reasonab
--- parrot-current/t/pmc/resizablebooleanarray.tSat Feb 11 12:30:37 2006
+++ parrot-andy/t/pmc/resizablebooleanarray.t Wed Feb 15 12:55:35 2006
@@ -662,7 +662,7 @@
pasm_output_is(<<'CODE', <<'OUTPUT', "direct access 2");
#new P0, .IntList
new P0, .ResizableBooleanArray
-set I10, 110
+set I10, 55
set I0, 1
lp1:
add I1, I0, 5
--
Andy Dougherty [EMAIL PROTECTED]
[perl #38576] [PATCH] Make DETAIL_MEMORY_DEBUG work.
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #38576]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38576 >
While trying to debug an "Out of mem" PANIC, I decided to try using
DETAIL_MEMORY_DEBUG in src/memory.c. Alas, it didn't help for two
reasons:
1. It prints to standard output, so that when you try to rebuild
parrot, you get things like
$ make parrot
Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your
fingers
./miniparrot config_lib.pasm > runtime/parrot/include/config.fpmc
perl5.6 tools/build/parrot_config_c.pl > src/parrot_config.c
[ . . . ]
cc -o parrot [. . . ] src/parrot_config.o [ . . . ]
which ends up putting all that debug information into
src/parrot_config.o, and, eventually, into parrot. The resulting
parrot dumps core immediately. Not very helpful.
2. Some (but not all) of the debugging statements were *after* the
call to PANIC. That means that you never get to see the call to the
function that triggered the panic.
The following patch to src/memory.c re-orders statements, and prints to
stderr instead of stdout. I know stderr might not be available in
all situations, but this at least can work sometimes.
Finally, I put in a guard against calling free(0). It might not be
necessary, but we do end up trying to call it, and old habits die
hard.:-).
--- parrot-current/src/memory.c Sat Feb 11 12:23:31 2006
+++ parrot-andy/src/memory.cWed Feb 15 12:36:51 2006
@@ -41,11 +41,11 @@
mem_sys_allocate(size_t size)
{
void *ptr = malloc((size_t)size);
-if (!ptr)
-PANIC("Out of mem");
#ifdef DETAIL_MEMORY_DEBUG
-printf("Allocated %i at %p\n", size, ptr);
+fprintf(stderr, "Allocated %i at %p\n", size, ptr);
#endif
+if (!ptr)
+PANIC("Out of mem");
return ptr;
}
@@ -54,7 +54,7 @@
{
void *ptr = malloc((size_t)size);
#ifdef DETAIL_MEMORY_DEBUG
-printf("Internal malloc %i at %p (%s/%d)\n", size, ptr, file, line);
+fprintf(stderr, "Internal malloc %i at %p (%s/%d)\n", size, ptr, file,
line);
#endif
if (!ptr)
PANIC("Out of mem");
@@ -76,11 +76,11 @@
mem_sys_allocate_zeroed(size_t size)
{
void *ptr = calloc(1, (size_t)size);
-if (!ptr)
-PANIC("Out of mem");
#ifdef DETAIL_MEMORY_DEBUG
-printf("Allocated %i at %p\n", size, ptr);
+fprintf(stderr, "Allocated %i at %p\n", size, ptr);
#endif
+if (!ptr)
+PANIC("Out of mem");
return ptr;
}
@@ -88,11 +88,11 @@
mem__internal_allocate_zeroed(size_t size, const char *file, int line)
{
void *ptr = calloc(1, (size_t)size);
-if (!ptr)
-PANIC("Out of mem");
#ifdef DETAIL_MEMORY_DEBUG
-printf("Internal malloc %i at %p (%s/%d)\n", size, ptr, file, line);
+fprintf(stderr, "Internal malloc %i at %p (%s/%d)\n", size, ptr, file,
line);
#endif
+if (!ptr)
+PANIC("Out of mem");
return ptr;
}
@@ -112,14 +112,14 @@
{
void *ptr;
#ifdef DETAIL_MEMORY_DEBUG
-printf("Freed %p (realloc -- %i bytes)\n", from, size);
+fprintf(stderr, "Freed %p (realloc -- %i bytes)\n", from, size);
#endif
ptr = realloc(from, size);
-if (!ptr)
- PANIC("Out of mem");
#ifdef DETAIL_MEMORY_DEBUG
-printf("Allocated %i at %p\n", size, ptr);
+fprintf(stderr, "Allocated %i at %p\n", size, ptr);
#endif
+if (!ptr)
+ PANIC("Out of mem");
return ptr;
}
@@ -127,12 +127,12 @@
mem__internal_realloc(void *from, size_t size, const char *file, int line)
{
void *ptr = realloc(from, size);
-if (!ptr)
-PANIC("Out of mem");
#ifdef DETAIL_MEMORY_DEBUG
-printf("internal free of %p (realloc -- %i bytes) (%s/%d)\n", from, size,
file, line);
-printf("Internal malloc %i at %p (%s/%d)\n", size, ptr, file, line);
+fprintf(stderr, "internal free of %p (realloc -- %i bytes) (%s/%d)\n",
from, size, file, line);
+fprintf(stderr, "Internal malloc %i at %p (%s/%d)\n", size, ptr, file,
line);
#endif
+if (!ptr)
+PANIC("Out of mem");
return ptr;
}
#undef interpreter
@@ -152,16 +152,17 @@
mem_sys_free(void *from)
{
#ifdef DETAIL_MEMORY_DEBUG
-printf("Freed %p\n", from);
+fprintf(stderr, "Freed %p\n", from);
#endif
-free(from);
+if (from)
+ free(from);
}
void
mem__internal_free(void *from, const char *file, int line)
{
#ifdef DETAIL_MEMORY_DEBUG
-printf("Internal free of %p (%s/%d)\n", from, file, line);
+fprintf(stderr, "Internal free of %p (%s/%d)\n", from, file, line);
#endif
free(from);
}
--
Andy Dougherty [EMAIL PROTECTED]
Re: Instance attributes collision
On 2/15/06, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> On 2/14/06, Stevan Little <[EMAIL PROTECTED]> wrote:
> > I think that the metaclass (stored in the pseudo-lexical $::CLASS)
> > should create a number of anonymous roles on the fly:
> >
> >role {
> > multi method a (::CLASS $self) { ... }
> > multi method a (::CLASS $self, Scalar $value) { ... }
> >}
> >
> >role {
> > multi method a (::CLASS $self) { ... }
> > multi method a (::CLASS $self, Array @value) { ... }
> >}
> >
> > These roles would then be added to the metaclass using the normal
> > rules of role composition. (NOTE: I assume that ::CLASS is unbound
> > until the role is composed into a class, I think A12 might have stated
> > this detail)
> >
> > Now obviously we have a conflict in our multi-methods. S12 only states
> > that multi methods will be compared by their long names (name +
> > signature) to resolve ambiguity, it does not state what happens when
> > those long names conflict. I propose that they work just as normal
> > method conflicts do, which is that both methods are excluded and the
> > consuming class is then required to implement that method.
>
> Is it just the first multimethod a(::CLASS $self) from each role being
> excluded or are all the multimethod a(...)'s being excluded?
I would think it could be the first one only, the one where the long
name conflicts.
Stevan
Re: some newbie questions about synopsis 5
On Wed, Feb 15, 2006 at 10:09:05AM +0100, H. Stelling wrote:
> - Capture numbering:
>
> /(a) [ (b) (c) (d) | (e) & (f) ] (g)/ capture.t suggests something like
> $0$1 $2 $3$1$2$4, but I'm only guessing about the
> "&" bit.
Yes.
> In the following,
>
> / (a) [ (b) (c) | $5 := (d) $0 := (e) ] (f) /
>
> does the first alias have any effect on where the f's will go
> (probably not)?
I'll defer to @Larry on this one, but my initial impression is
that the (f) capture would go into $6.
> - Which rules do apply to repeated captures with the same alias? For
> example,
> the second array aliasing example
>
> m:w/ Mr?s? @ := W\. @ :=
>| Mr?s? @ :=
>/;
>
> seems to suggests that by using $, the lower branch would have
> resulted in a single Match object instead of an array (like the array we
> would have gotten if we hadn't used the aliases in the first place). Is
> this right?
Yes, that's correct.
> And could the same effect have been achieved by something
> like
>
> / $ := **{1} / ?
Yes, a quantified capturing subrule or subpattern results in an
array of Match objects (even if the quantification is "1").
> - More array aliasing:
>
> is / mv @ := [...]* /
> just (slightly) shorter for / mv [$ := [...]]* / ?
I think so.
> Likewise, could/ @ := ( (\w+) \: (\N+) )+ /
> have also been written / [ $ := (\w+) \: $ := (\N+) ]+ / ?
Seems like it would work.
> - Array and hash aliasing of quantified subpatterns or subrules: what
> happens
> to the named captures?
>
> / @ := ( ... $bar := (...) ... )* /
Presuming you meant $ there instead of $bar, I have no idea
what would happen. (With $bar it's an external alias and would
capture an array of matches into the scope in which the rule was
declared.)
> And if the subpattern or subrule ends with an alternation, can the
> number of
> array elements to be appended (or hashed) vary depending on whitch
> branch is
> taken?
Again I have to refer this to @Larry, but my initial impression is
"yes, it would vary".
> - Which of the following constructs could possibly be ok (I hope, none)?
>
> / $ := ... & $ := ... /
I think this one is okay. $ is an array of Match objects, and
each Match is likely repeated within the array.
> / $ := ... % := ... /
I hope this is not okay. It's certainly not going to be okay anytime
soon in the PGE implementation of Perl 6 rules. :-)
> / $ := ... | % := ... /
Since the two aliases are in separate alternation branches, I think
this is okay. The argument would be similar to
/ $ := ... | @ := .../
in which $ is either a single Match object or an array of
Match objects depending on the branch matched.
> / $ := $ := ... /
While my instinctual reaction is to say that this ought to be okay,
upon thinking about it a bit more I think I'd prefer to say that
it's not. At least initially, if nothing else. In particular, I
wonder about something like
/ @ := $ := [...]+ /
If we say that an alias always requires a subpattern or subrule
(and not another alias), then we avoid a lot of ambiguity, and the
above could be written as
/ @ := [ $ := [...]+ ] /
/ @ := [ $ := [...] ]+ /
depending on what is desired.
> - Do aliases bind right-to-left, as do assignments?
> / $2 := $5 := ... / # next should be $3, not $6
Assuming we allow chained aliases such as this (see above note),
I'd still argue for $6 instead of $3.
> - Which kind of escape sequences are allowed (or required) in enumerated
> character classes?
AFAIK, this hasn't been completely decided or specified yet.
Pm
Re: Instance attributes collision
On 2/14/06, Stevan Little <[EMAIL PROTECTED]> wrote:
> I think that the metaclass (stored in the pseudo-lexical $::CLASS)
> should create a number of anonymous roles on the fly:
>
>role {
> multi method a (::CLASS $self) { ... }
> multi method a (::CLASS $self, Scalar $value) { ... }
>}
>
>role {
> multi method a (::CLASS $self) { ... }
> multi method a (::CLASS $self, Array @value) { ... }
>}
>
> These roles would then be added to the metaclass using the normal
> rules of role composition. (NOTE: I assume that ::CLASS is unbound
> until the role is composed into a class, I think A12 might have stated
> this detail)
>
> Now obviously we have a conflict in our multi-methods. S12 only states
> that multi methods will be compared by their long names (name +
> signature) to resolve ambiguity, it does not state what happens when
> those long names conflict. I propose that they work just as normal
> method conflicts do, which is that both methods are excluded and the
> consuming class is then required to implement that method.
Is it just the first multimethod a(::CLASS $self) from each role being
excluded or are all the multimethod a(...)'s being excluded?
Rob
Re: [perl #38549] pod check test checks wrong files
On Tue, Feb 14, 2006 at 05:23:39PM -0800, Will Coleda wrote: > t/doc/pod.t currently: > > 1) starts checking from the current directory. > > It should start at the parrot root based on Parrot::Config Fixed in r11551. > 2) checks every file with pod in that directory hierarchy. > > It should only check those files that are in MANIFEST. (And > *possibly* MANIFEST.generated) It's trivial to parse those files but is there a pre-existing parser module I don't know about? There's no point in getting locked into the current format if we don't have to. -J -- pgpoPofuh7rwC.pgp Description: PGP signature
Re: RetContinuation promotion, closures, and context leakage
On Feb 14, 2006, at 4:06, Bob Rogers wrote: 1. Closure still needs a destroy method, and having one is in fact sufficient to reclaim contexts that would otherwise be lost. Ack. 2. In order to prove this (not to mention for debugging of RetContinuation hackery), I added a fair amount of new CTX_LEAK_DEBUG trace code, centralized it in interpreter.h, and put all of this output under control of PARROT_CTX_DESTROY_DEBUG_FLAG so that it could be turned on/off without recompiling. Good. That simplifies further fixes. 3. While I was at it, I flushed most of the "#if CHUNKED_CTX_MEM" code in src/register.c -- this code has serious bit-rot, and having two implementations of Parrot_free_context et. al. tended to get in the way, especially since M-. usually found the wrong one. (Though you could argue that I didn't go far enough in flushing all of the CHUNKED_CTX_MEM stuff . . .) Well, the original plan contained the usage of a linear chunked context/register memory. But it's right that the code is fully out-dated and non-functional and it's in the way, when jumping around through tags. Therefore it's really better to just drop that code and maybe re-implement it cleanly again *after* all issues are sorted out. leo
some newbie questions about synopsis 5
Hello,
I've stumbled upon Perl6 a couple of weeks ago and I'm really looking
forward
to seeing the finished product. Currently, I'm trying to implement a
perl-like
rules module for Python, and I've got some questions which I think aren't
covered in the Synopsis or anywhere else I looked, mostly concerning
captures
and aliases:
- Capture numbering:
/(a) [ (b) (c) (d) | (e) & (f) ] (g)/ capture.t suggests something like
$0$1 $2 $3$1$2$4, but I'm only guessing about the
"&" bit.
In the following,
/ (a) [ (b) (c) | $5 := (d) $0 := (e) ] (f) /
does the first alias have any effect on where the f's will go
(probably not)?
- Which rules do apply to repeated captures with the same alias? For
example,
the second array aliasing example
m:w/ Mr?s? @ := W\. @ :=
| Mr?s? @ :=
/;
seems to suggests that by using $, the lower branch would have
resulted in a single Match object instead of an array (like the array we
would have gotten if we hadn't used the aliases in the first place). Is
this right? And could the same effect have been achieved by something
like
/ $ := **{1} / ?
- More array aliasing:
is / mv @ := [...]* /
just (slightly) shorter for / mv [$ := [...]]* / ?
Likewise, could/ @ := ( (\w+) \: (\N+) )+ /
have also been written / [ $ := (\w+) \: $ := (\N+) ]+ / ?
- Array and hash aliasing of quantified subpatterns or subrules: what
happens
to the named captures?
/ @ := ( ... $bar := (...) ... )* /
And if the subpattern or subrule ends with an alternation, can the
number of
array elements to be appended (or hashed) vary depending on whitch
branch is
taken?
- Which of the following constructs could possibly be ok (I hope, none)?
/ $ := ... & $ := ... /
/ $ := ... % := ... /
/ $ := ... | % := ... /
/ $ := $ := ... /
- Do aliases bind right-to-left, as do assignments?
/ $2 := $5 := ... / # next should be $3, not $6
- Which kind of escape sequences are allowed (or required) in enumerated
character classes?
Thanks in advance for any answers!
