Re: r7994: win32--msvc-7.1--perl-5.8.6 test error report
At 13:55 06/05/2005 -0700, you wrote: t\op\debuginfo.t 5 1280 85 62.50% 4-8 Consider the last version of my patch attached to [perl #35083]. Francois. ~jerry debuginfo.patch Description: Binary data
Re: [perl #35388] [PATCH] building problems
At 09:43 10/05/2005 +, you wrote: 1) On MinGW, can't execute miniparrot.exe during building Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your fingers ./miniparrot.exe config_lib.pasm runtime/parrot/include/config.fpmc '.' is not recognized as an internal or external command, operable program or batch file. Why did that work with parrot before my changes? It has the same slash. Not the same with MinGW (eg. GNU make + gcc on Win32) Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your fingers .\miniparrot.exe config_lib.pasm runtime/parrot/include/config.fpmc If the next line prints 0.2.0-devel, it did help. .\miniparrot.exe parrot-config.imc VERSION DEVEL See Parrot_Exec_OS_Command (http://xrl.us/fimc) and [perl #34605]. Francois. leo
Re: Question about Parrot and Omniscient Debugging
Autrijus Tang wrote: On Tue, May 10, 2005 at 11:11:12AM -0500, [EMAIL PROTECTED] wrote: Please excuse the possible 'out of left field' (as we say) aspect of this question but I recently heard about Omniscient Debugging (ODB): http://www.lambdacs.com/debugger/debugger.html Sounds very powerful This seems to require almost the same journaling capacity for STM (software transactional memory), although in STM's case we only mark updates for shared variables, whilst in ODB a journal is kept for all updates. Yep It is conceivable to build this facility into the PMCs, much like how tied objects work, but my knowledge of parrot internals is insufficient to answer whether it will be difficult or not. I've already described in my summary http://xrl.us/f234 2.2) that we should split the vtable into various parts[1]. We should be able to switch to a read-only variant of a PMC for example. Switching in some vtable pieces that logs set_*_* vtable calls is more or less the same thing. vtable.tbl already has most of this information: see [STORE]. There is an experimental feature 'pmclass SArray const_too' in the SArray PMC, where two vtables are created, switchable by setting the _ro property. But this is all really rough and not a general solution. See also Layering PMCs http://xrl.us/f236 for an older discussion about vtables and roles and VTABLE methods and interfaces http://xrl.us/f237. [1] The vtable is currently almost 600 bytes (32bit system). By switching full vtables just to get a read-only variant, we'd need a lot of memory. And: a scalar PMC doesn't need nor implement the array-ish vtable slots. I prefer one more indirection for almost all of the vtable slots. leo
Re: Named rules and basic OO support landed.
Autrijus Tang [EMAIL PROTECTED] wrote:
class Point {
has $.x;
has $.y;
The progress pugs makes is really impressive.
[ ... ]
Pugs's Parrot codegen backend needs to be updated
Object attribute access, yeah. IMHO Parrot's current implementation is
wrong.
0) class construction # a bit shortened for this example
.local pmc cl, o, x, y # decls for example
cl = newclass Point
addattribute cl, x # $x what does Python then?
addattribute cl, y # $y what does Python then?
o = new Point # make instance - __init not shown
1) indexed access
$I0 = classoffset o, Point
x = getattribute o, $I0 # 1st attribute at ofs + 0
$I1 = $I0 + 1
y = getattribute o, $I1 # 2nd attribute at ofs + 1
The offset is cached in the bytecode, you could keep it over the whole
program life-time. If the class layout ever changes, things would break
horribly. The compiler needs intimate knowledge of the attribute order
and it's usable for an array-ish object layout only.
2) named access
x = getattribute o, Point\0x
This needs a full qualified attribute name Class ~ NUL ~ Attribute.
That's unusable for at least Python and probably more HLLs as the
compiler has to know in which class the attribute was defined.
We should just have:
x = getattribute o, x
and the set equivalent:
setattribute o, x, x
Comments welcome,
leo
Re: Nested captures
Uri Guttman wrote: DC Sure. Just as $42 is a shorthand for $/[42], so too $whatever is a DC shorthand for $/whatever. but then what about the different index bases for $42 and $/[42]? i don't think that has been resolved (nor has mixing the $1.1 and $1[1] syntaxes). Bear in mind that that reply was posted in haste, late at night, after a long day of teaching. We're lucky it as only off by one! %-) But it does raise an important point: the discrepancy between $42 and $/[41] *is* a great opportunity for off-by-on errors. Previously, however, @Larry have tossed back and forth the possibility of using $0 as the first capture variable so that the indices of $/[0], $/[1], $/[2] match up with the names of $0, $1, $2, etc. I think this error--unintentional, I swear!--argues strongly that internal consistency within Perl 6 is more important than historical consistency with Perl 5's $1, $2, $3... But that's only the opinion of one(@Larry), not of $Larry. Damian
Re: patch to is_cclass for offset beyond end of string
On Wednesday 11 May 2005 04:30, Patrick R. Michaud wrote: ...well, in looking at it some more it's reasonable until I see that returning -1 is the way the other find_* ops work. So, part of me thinks we should either be consistent with those, or make the others consistent with the interpretation I gave above, or rename the find_cclass and find_not_cclass ops to something different (perhaps span_cclass and span_not_cclass) so as to avoid confusion, or deprecate the pre-existing find_* ops. IMO, we should deprecate the old find_* ops. It's a lot of (more or less) duplicate code, and not easy to maintain. jens
Re: [svn:parrot] rev 8042 - trunk/compilers/pge/PGE
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +++ trunk/compilers/pge/PGE/Hs.pirTue May 10 07:10:43 2005 That's the synopsis: @@ -8,7 +8,7 @@ load_bytecode PGE.pbc why don't you here just the same? .sub __onload @LOAD +.local pmc load +load = find_global PGE::TokenHash, __onload +load() and remove the includes: +.include PGE/TokenHash.pir leo
Re: patch to is_cclass for offset beyond end of string
Jens Rieks wrote: IMO, we should deprecate the old find_* ops. It's a lot of (more or less) duplicate code, and not easy to maintain. Yep, as well as the old is_foo opcodes and interfaces. jens leo
Re: Named rules and basic OO support landed.
Sweet candy! I might actually be able to start executing some of my
code! Will try any day now. -- Darren Duncan
At 8:48 AM +0800 5/11/05, Autrijus Tang wrote:
This works:
rule name { Larry | Matz | Guido }
rule project { Perl | Ruby | Python }
rule description { name \s does \s project }
'Larry does Perl' ~~ /description/; # true
'Larry does Java' ~~ /description/; # false
This too:
class Point {
has $.x;
has $.y;
method show () { say Coordinate: ($.x, $.y) }
method set ($x, $y) { $.x = $x; $.y = $y }
}
my $pt = Point.new(:x(10), :y(20));
$pt.show; # Coordinate: (10, 20)
my $pt2 = $pt.clone;
$pt.set(30, 40);
$pt.show; # Coordinate: (30, 40)
$pt2.show; # Coordinate: (10, 20)
say(($pt ~~ Point).perl); # bool:true
say(($pt ~~ Hash).perl);# bool::false
Pugs's Parrot codegen backend needs to be updated to reflect both of
them, but the basics are there. May the hackings commence. :)
Thanks,
/Autrijus/
Re: Nested captures
Damian Conway wrote: I think this error--unintentional, I swear!--argues strongly that internal consistency within Perl 6 is more important than historical consistency with Perl 5's $1, $2, $3... But that's only the opinion of one(@Larry), not of $Larry. My opinion as none(@Larry), too. And correct me if I'm wrong, but Perl6 is a major version change, isn't it? OTOH I don't have any legacy code to support :) -- TSa (Thomas Sandlaß)
MMD leftover: logical_{or,and,xor}
The logical MMD functions currently try to set a passed in destination PMCs value via assign, or they return a clone of themselves. This is verly likely wrong: not all PMCs have to implement assign: Dan: That's why the destination controls assignment. Additionaly we can't assign to singletons or r/o PMCs. So the right thing for the logical functions seems to be, to just return the left or right side according to their boolean value (or return a new Boolean false in case of xor), i.e. you get a reference to one of the PMCs usually. This would break a few tests, which don't cope with these ref semantics. Comments welcome, leo
Re: Nested captures
On Wed, 2005-05-11 at 17:48 +1000, Damian Conway wrote: But it does raise an important point: the discrepancy between $42 and $/[41] *is* a great opportunity for off-by-on errors. Previously, however, @Larry have tossed back and forth the possibility of using $0 as the first capture variable so that the indices of $/[0], $/[1], $/[2] match up with the names of $0, $1, $2, etc. I think this error--unintentional, I swear!--argues strongly that internal consistency within Perl 6 is more important than historical consistency with Perl 5's $1, $2, $3... I've run across many people who have been quite confused by the fact that Perl 5's $n submatch holders aren't 0-indexed, so I don't think this would be a bad change at all. Certainly it should go high in the what changed list as a warning, but that's not a big deal.
Re: embedding/extending interface
On Tue, May 10, 2005 at 01:13:48PM -0400, Jeff Horwitz wrote: as part of both the pugs and mod_parrot effort, i've started working on bringing the embedding and extending interfaces into the modern parrot era. i'd like to start by adding public APIs (Parrot_*) where necessary and adding missing prototypes to the headers. this will clean things up without changing any of the working parts. is there anyone else besides myself and autrijus who is actively working on an embedded parrot application? Following a question I raised about this, chromatic has some automated tools ready to help here http://www.nntp.perl.org/group/perl.perl6.internals/29422 However, I don't feel confident to say if this is the correct way to go. (seems like a design question) Nicholas Clark
Re: Named rules and basic OO support landed.
On Wed, May 11, 2005 at 09:19:50AM +0200, Leopold Toetsch wrote:
2) named access
x = getattribute o, Point\0x
This needs a full qualified attribute name Class ~ NUL ~ Attribute.
That's unusable for at least Python and probably more HLLs as the
compiler has to know in which class the attribute was defined.
Yes. I've encountered this during my PGE::Hs hacking:
.const string PGE_SUB_POS = PGE::Match\x0@:capt
.const string PGE_SUB_NAMED = PGE::Match\x0%:capt
I had no idea why the class name has to be fully qualified
for attributes, whilst methods can be simply invoked.
Pugs would have no easy way to figure out, at runtime,
which attribute to dispatch to, as Perl 6 allows adding
new attribute slots by eval'ing class Foo { has $.x }
blocks, so attributes previously resolved as belong to a
superclass may need to be redispatched.
We should just have:
x = getattribute o, x
and the set equivalent:
setattribute o, x, x
It'd definitely be better if the VM can keep track of
this; otherwise I'd need to marshall the whole attribute
table and do a lookup each time by hand, which would be
slow (and non-interoperable) indeed.
Thanks,
/Autrijus/
pgpRQt7SPjRF1.pgp
Description: PGP signature
[perl #35405] [PATCH] t/pmc/config.t fails
# New Ticket Created by Franois PERRAD # Please include the string: [perl #35405] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35405 This transaction appears to have no content After building different revision of Parrot without 'make clean', t/pmc/config.t fails. $ parrot t/pmc/config_3.pir ok 1 PackFile_unpack: Bytecode not valid for this interpreter: version mismatch Parrot VM: Can't unpack packfile trunk\runtime\parrot\library\config.pbc. Couldn't find PBC file After deleting runtime\parrot\library\config.pbc, the test pass. So it's a dependency problem. All .pbc depend of the parrot executable (not only runtime/parrot/include/parrotlib.pbc). The following patch (quick dirty) delete all .pbc after linking parrot. Francois Perrad pbc_depend.patch Description: Binary data
Re: patch to is_cclass for offset beyond end of string
On Tue, May 10, 2005 at 10:22:35PM +0200, Jens Rieks wrote: On Tuesday 10 May 2005 20:29, Patrick R. Michaud wrote: This is *excellent*. However, now that I look at things, I'm wondering if a slight change to the specification would be in order -- in my original post I said that find_cclass and find_not_cclass would return -1 whenever they (didn't find | found) the character of interest -- perhaps it would be better for them to return the length of the string instead? Yes, sounds reasonable. ...well, in looking at it some more it's reasonable until I see that returning -1 is the way the other find_* ops work. So, part of me thinks we should either be consistent with those, or make the others consistent with the interpretation I gave above, or rename the find_cclass and find_not_cclass ops to something different (perhaps span_cclass and span_not_cclass) so as to avoid confusion, or deprecate the pre-existing find_* ops. Any suggestions from the peanut gallery about how this should work? If I were designing for the long run I'd make the change, but that's really not my decision to make, and I'll happily live with any decision made as long as there's some sort of character class support (and will likely generate+submit a patch for it). I only bring this up because I'm asking myself what we'll want in the long run, as opposed to what we might have now . Some notes about the motivation for the change below... Pm - Why find_not_cclass is useful, and why it's useful to return the length of string instead of an error (-1) indicator: As many of you know, I've written the Perl Grammar Engine, and I'm also working on another parser. In parsing expressions there are many times where I want to be able to skip over a sequence of characters until I find one that is not in a certain class -- i.e., for grabbing sequences of digits, word characters, skipping whitespace, etc. For example, before having find_cclass and find_not_cclass, grabbing a sequence of digits in Parrot required a loop, as in: .local string target # string to scan .local int pos # current scanning position $I0 = pos # keep start of position digits_loop: $I1 = is_digit target, pos unless $I1 goto digits_end inc pos goto digits_loop digits_end: $I1 = pos - $I0 $S0 = substr target, $I0, $I1# extract sequence of digits Having find_not_cclass can make this much simpler .local string target # string to scan .local int pos # current scanning position $I0 = pos # keep start of position pos = find_not_cclass .CCLASS_NUMERIC, target, pos $I1 = pos - $I0 $S0 = substr target, $I0, $I1# extract sequence of digits Similarly, I often want to skip comments (e.g., '#' until the next newline): .local string target # string to scan .local int pos # current scanning position $S0 = substr target, pos, 1 unless $S0 == # goto comment_skipped inc pos pos = find_cclass .CCLASS_NEWLINE, target, pos comment_skipped: # ... Unfortunately, if find_cclass and find_not_cclass return -1 when the desired character isn't available, I have to check for this special return value and handle it accordingly: .local string target # string to scan .local int pos # current scanning position $I0 = pos # keep start of position pos = find_not_cclass .CCLASS_NUMERIC, target, pos unless pos == -1 goto digit_1 pos = length target digit_1: $I1 = pos - $I0 $S0 = substr target, $I0, $I1# extract sequence of digits and .local string target # string to scan .local int pos # current scanning position $S0 = substr target, pos, 1 unless $S0 == # goto comment_skipped inc pos pos = find_cclass .CCLASS_NEWLINE, target, pos unless pos == -1 goto comment_skipped pos = length target comment_skipped: # ... So, in these particular instances, receiving the length of the string is much more useful than the -1 value. Of course, the -1 value is a quick indicator that the desired character class wasn't found; without it we have to check the return value against the string length if we want to know if the character position wasn't located. For example, instead of: $I1 = find_not_cclass .CCLASS_DIGIT, $S0, $I0 if $I1 == -1 goto only_digits_left with find_char returning the length of string it becomes $I2 = length $S0 $I1 = find_not_cclass .CCLASS_DIGIT, $S0, $I0 if $I1 == $I2 goto only_digits_left In the things I'm writing thus far, I'm having to keep the length of the string in a register anyway to know when the scanner has reached the end of input. So, for me, using the string length to indicate that the desired character isn't found doesn't cost me anything over the -1 value. What's best for the long term?
Of fail, exceptions and catching
Given:
fail with configurable behavior
no fatal to make fail just warn
use fatal to make fail throw exceptions
A question came up on #perl6 for the following code:
no fatal;
class Foo {
use fatal;
method bar() { fail; }
}
Foo.bar;
That is, bar() picks up a lexically scoped use fatal, but the caller
of bar desires non-fatal behavior.
Possible results and reasons for them:
* Warning -- For this to work, I think you would need an implicit
CATCH block wrapper around each statement in a no fatal
section. This could be simulated by wrapping the entire no fatal
section in a continuation closure which is then called inside a
CATCH block which warns and re-invokes the continuation... if
continuations can be re-invoked after exceptions. That's an
interesting question on it's own actually.
* Fatal exception -- This implies that the callee's lexically
scoped fatal preference wins, which might be a reasonable thing
in concept, but seems to present no control to the user of a
module when the module author has specified a preference.
Perhaps that's a good thing. Perhaps it's bad. I do see a
problem with a program that uses several modules, all of which
have different opinions about fatality...
* Warning -- Another reason that you might get a warning would be
that there is some sort of dynamically scoped imposition of a
non-fatal context from no fatal. That seems the least likely
to me, but I thought that I'd bring it up.
This came up when someone was considering writing a module, and was
saying that he really wanted use fatal as the default for his modules.
That seems like a reasonable thing to want, but I'm not sure how it
could be controlled correctly.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Of fail, exceptions and catching
Aaron Sherman skribis 2005-05-11 7:44 (-0400): no fatal to make fail just warn I thought it wouldn't warn, but instead silently return undef (an unthrown exception). Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: [perl #35405] [PATCH] t/pmc/config.t fails
Franois PERRAD (via RT) wrote: After building different revision of Parrot without 'make clean', Just don't do that in the same directory. The following patch (quick dirty) delete all .pbc after linking parrot. Not the best idea. Think: Dan's big subs, which compile for 6 hours. And the funtionality is just a few keystrokes away: $ find . -name '*.pbc' | xargs rm Francois Perrad leo
Re: [perl #35393] [PATCH] _config cleanup
Jerry Gay [EMAIL PROTECTED] wrote: the new *_config$(O) files are not cleaned up during make clean/realclean... until now. 'svn status' reports these files have been removed after 'make clean' Thanks, applied. leo
Re: MMD leftover: logical_{or,and,xor}
On Wed, May 11, 2005 at 10:17:30AM +0200, Leopold Toetsch wrote: So the right thing for the logical functions seems to be, to just return the left or right side according to their boolean value (or return a new Boolean false in case of xor), i.e. you get a reference to one of the PMCs usually. This sounds good to me. Pm
Re: Named rules and basic OO support landed.
On Wed, May 11, 2005 at 09:19:50AM +0200, Leopold Toetsch wrote: We should just have: x = getattribute o, x and the set equivalent: setattribute o, x, x I would much prefer this. I don't have much problem with grabbing and using the offsets, but at the moment they're really only useful as a speed optimization when accessing more than a couple of attributes, and then only for the duration of a subroutine. For accessing a single attribute, x = getattribute o, MyClass\x0$.x or (better) x = getattribute o, x is far superior. Pm
[perl #35410] [PATCH] change find_cclass/find_not_cclass return value
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #35410]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35410
The attached patch modifies find_cclass and find_not_cclass
to return the length of the string when no matching character
is found (previously these ops returned -1).
The patch also updates the tests in t/op/string_cclass.t to
test the new behavior.
Pm
Index: charset/iso-8859-1.c
===
--- charset/iso-8859-1.c(revision 8056)
+++ charset/iso-8859-1.c(working copy)
@@ -347,7 +347,7 @@
return pos;
}
}
-return -1;
+return end;
}
static INTVAL
@@ -365,7 +365,7 @@
return pos;
}
}
-return -1;
+return end;
}
Index: charset/ascii.c
===
--- charset/ascii.c (revision 8056)
+++ charset/ascii.c (working copy)
@@ -580,7 +580,7 @@
return pos;
}
}
-return -1;
+return end;
}
static INTVAL
@@ -598,7 +598,7 @@
return pos;
}
}
-return -1;
+return end;
}
/*
Index: t/op/string_cclass.t
===
--- t/op/string_cclass.t(revision 8056)
+++ t/op/string_cclass.t(working copy)
@@ -35,30 +35,30 @@
.param string str
.param int flags
$I0 = 0
+$I2 = length str
loop:
-$I0 = find_cclass flags, str, $I0, 100
-if $I0 == -1 goto end
-print $I0
+$I1 = find_cclass flags, str, $I0, 100
+print $I1
print ;
inc $I0
-branch loop
+if $I0 = $I2 goto loop
end:
print \n
.end
CODE
-0;1;2;3;4;5;6;7;8;10;
-6;7;
-0;1;
-4;8;12;
+0;1;2;3;4;5;6;7;8;10;10;12;12;
+6;6;6;6;6;6;6;7;13;13;13;13;13;13;
+0;1;13;13;13;13;13;13;13;13;13;13;13;13;
+4;4;4;4;4;8;8;8;8;12;12;12;12;13;
OUT
-pir_output_is('CODE', 'OUT', find_cclass, iso-8859-1);
+pir_output_is('CODE', 'OUT', find_not_cclass, ascii);
.include cclass.pasm
.sub main @MAIN
-$S0 = iso-8859-1:test_func(1)
+$S0 = ascii:test_func(1)
test( .CCLASS_WORD, $S0 )
-$S0 = iso-8859-1:ab\nC_X34.\0 \t!
+$S0 = ascii:ab\nC_X34.\0 \t!
test( .CCLASS_NUMERIC, $S0 )
test( .CCLASS_LOWERCASE, $S0 )
test( .CCLASS_PUNCTUATION, $S0 )
@@ -67,30 +67,30 @@
.param string str
.param int flags
$I0 = 0
+$I2 = length str
loop:
-$I0 = find_cclass flags, str, $I0, 100
-if $I0 == -1 goto end
-print $I0
+$I1 = find_not_cclass flags, str, $I0, 100
+print $I1
print ;
inc $I0
-branch loop
+if $I0 = $I2 goto loop
end:
print \n
.end
CODE
-0;1;2;3;4;5;6;7;8;10;
-6;7;
-0;1;
-4;8;12;
+9;9;9;9;9;9;9;9;9;9;11;11;12;
+0;1;2;3;4;5;8;8;8;9;10;11;12;13;
+2;2;2;3;4;5;6;7;8;9;10;11;12;13;
+0;1;2;3;5;5;6;7;9;9;10;11;13;13;
OUT
-pir_output_is('CODE', 'OUT', find_not_cclass, ascii);
+pir_output_is('CODE', 'OUT', find_cclass, iso-8859-1);
.include cclass.pasm
.sub main @MAIN
-$S0 = ascii:test_func(1)
+$S0 = iso-8859-1:test_func(1)
test( .CCLASS_WORD, $S0 )
-$S0 = ascii:ab\nC_X34.\0 \t!
+$S0 = iso-8859-1:ab\nC_X34.\0 \t!
test( .CCLASS_NUMERIC, $S0 )
test( .CCLASS_LOWERCASE, $S0 )
test( .CCLASS_PUNCTUATION, $S0 )
@@ -99,21 +99,21 @@
.param string str
.param int flags
$I0 = 0
+$I2 = length str
loop:
-$I0 = find_not_cclass flags, str, $I0, 100
-if $I0 == -1 goto end
-print $I0
+$I1 = find_cclass flags, str, $I0, 100
+print $I1
print ;
inc $I0
-branch loop
+if $I0 = $I2 goto loop
end:
print \n
.end
CODE
-9;11;
-0;1;2;3;4;5;8;9;10;11;12;
-2;3;4;5;6;7;8;9;10;11;12;
-0;1;2;3;5;6;7;9;10;11;
+0;1;2;3;4;5;6;7;8;10;10;12;12;
+6;6;6;6;6;6;6;7;13;13;13;13;13;13;
+0;1;13;13;13;13;13;13;13;13;13;13;13;13;
+4;4;4;4;4;8;8;8;8;12;12;12;12;13;
OUT
pir_output_is('CODE', 'OUT', find_not_cclass, iso-8859-1);
@@ -131,21 +131,21 @@
.param string str
.param int flags
$I0 = 0
+$I2 = length str
loop:
-$I0 = find_not_cclass flags, str, $I0, 100
-if $I0 == -1 goto end
-print $I0
+$I1 = find_not_cclass flags, str, $I0, 100
+print $I1
print ;
inc $I0
-branch loop
+if $I0 = $I2 goto loop
end:
print \n
.end
CODE
-9;11;
-0;1;2;3;4;5;8;9;10;11;12;
-2;3;4;5;6;7;8;9;10;11;12;
-0;1;2;3;5;6;7;9;10;11;
+9;9;9;9;9;9;9;9;9;9;11;11;12;
+0;1;2;3;4;5;8;8;8;9;10;11;12;13;
+2;2;2;3;4;5;6;7;8;9;10;11;12;13;
+0;1;2;3;5;5;6;7;9;9;10;11;13;13;
OUT
pir_output_is('CODE', 'OUT', is_cclass, ascii);
Re: MMD leftover: logical_{or,and,xor}
Patrick R. Michaud wrote: On Wed, May 11, 2005 at 10:17:30AM +0200, Leopold Toetsch wrote: So the right thing for the logical functions seems to be, to just return the left or right side according to their boolean value (or return a new Boolean false in case of xor), i.e. you get a reference to one of the PMCs usually. This sounds good to me. Done, rev 8061 * logical ops Cor, Cand, Cxor return the left or right PMC * Cxor may return a new scalar, which is set to VTABLE_set_bool(..,0) (this is more a short term hack until we have HLL type mappings) * This invalidates current bytecode as the MMD function numbers did change Please make realclean; ... Pm leo
Re: Of fail, exceptions and catching
On 5/11/05, Aaron Sherman [EMAIL PROTECTED] wrote:
Given:
fail with configurable behavior
no fatal to make fail just warn
Juerd is right here, it doesn't warn. Instead of dieing, it returns
an undef with some helpful diagnostic information (an unthrown
exception as Larry has been calling it).
use fatal to make fail throw exceptions
A question came up on #perl6 for the following code:
no fatal;
class Foo {
use fatal;
method bar() { fail; }
}
Foo.bar;
That is, bar() picks up a lexically scoped use fatal
No it doesn't. The fatal that refers to bar's return value belongs to
the caller of bar. Here's another example:
sub foo() {
fail;
}
use fatal;
sub bar() {
foo(); # foo() throws exception
}
no fatal;
sub baz() {
foo(); # foo() returns undef
}
use fatal;
bar(); # propagates exception from foo()
baz(); # turns baz()'s (from foo()'s) undef into an exception
no fatal;
bar(); # turns exception thrown from foo()'s into an undef
baz(); # returns the undef that it got from foo()
Does that clarify things? (I could tell there was some
misunderstanding going on, but I had a hard time explaining it.
Hopefully this example will clear things up)
Luke
Re: Of fail, exceptions and catching
On 5/11/05, Luke Palmer [EMAIL PROTECTED] wrote:
sub foo() {
fail;
}
use fatal;
sub bar() {
foo(); # foo() throws exception
}
no fatal;
sub baz() {
foo(); # foo() returns undef
}
use fatal;
bar(); # propagates exception from foo()
baz(); # turns baz()'s (from foo()'s) undef into an exception
no fatal;
bar(); # turns exception thrown from foo()'s into an undef
baz(); # returns the undef that it got from foo()
Oh, just to avoid further confusion: In the baz() called under fatal,
it will only turn undefs that were generated by fail calls into
exceptions. Other sorts of undefs will be returned as ordinary
undefs.
Likewise, in the bar() called under no fatal, it will only turn
exceptions that were generated by fail calls into undefs. Other
sorts of exceptions stay as exceptions and propagate outward.
Luke
Re: Nested captures
But it does raise an important point: the discrepancy between $42 and $/[41] *is* a great opportunity for off-by-on errors. Previously, however, @Larry have tossed back and forth the possibility of using $0 as the first capture variable so that the indices of $/[0], $/[1], $/[2] match up with the names of $0, $1, $2, etc. I think this error--unintentional, I swear!--argues strongly that internal consistency within Perl 6 is more important than historical consistency with Perl 5's $1, $2, $3... FWIW, I think that all the /^\$\d+$/ variables should be related to each other, too. Now - here's a question. Can I always address $42 in same way that I could address $2 in P5 at any time? Or, will they only come into scope whenever there was a match higher up? I personally like them only being in scope within the scope of a match, especially under any strictures. Second - is it possible or desirable for @/ to be assignable? I can think of some nice uses for that, primarily in testing ... Rob
Re: Of fail, exceptions and catching
On Wed, 2005-05-11 at 09:50, Luke Palmer wrote:
Oh, just to avoid further confusion: In the baz() called under fatal,
it will only turn undefs that were generated by fail calls into
exceptions. Other sorts of undefs will be returned as ordinary
undefs.
Ok, so let me try to get my head around this:
fail is something like:
return undef but Exception(...some state info...);
the only question is whether the caller reacts to that special return
value like so:
if $return ~~ Exception {
return $return;
}
or simply ignores it. If you ignore the special return value, then you
presumably have the burden of coping with it in some other way, like so:
no fatal;
$socket.bind(:interfacelocalhost, :port80) or
$socket.bind([EMAIL PROTECTED]) or
die Cannot bind: $!;
At the top-level (runtime), you would expect to have something like
(arm-waving some naming specifics):
given $program.(@args) {
when Exception { $*ERR.print $_.err; exit 1 }
default { exit +$_ }
}
Am I getting it now?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Nested captures
On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote: Uri Guttman wrote: DC Sure. Just as $42 is a shorthand for $/[42], so too $whatever is a DC shorthand for $/whatever. but then what about the different index bases for $42 and $/[42]? i don't think that has been resolved (nor has mixing the $1.1 and $1[1] syntaxes). Bear in mind that that reply was posted in haste, late at night, after a long day of teaching. We're lucky it as only off by one! %-) But it does raise an important point: the discrepancy between $42 and $/[41] *is* a great opportunity for off-by-on errors. Indeed. Previously, however, @Larry have tossed back and forth the possibility of using $0 as the first capture variable so that the indices of $/[0], $/[1], $/[2] match up with the names of $0, $1, $2, etc. I think this error--unintentional, I swear!--argues strongly that internal consistency within Perl 6 is more important than historical consistency with Perl 5's $1, $2, $3... But that's only the opinion of one(@Larry), not of $Larry. My opinion too. The $digit vars should be zero-based just as the array indices are. (or, if we can come up with a plausible meaning for the zeroth index of our match arrays, keep starting at $1) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Nested captures
DC == Damian Conway [EMAIL PROTECTED] writes: DC Uri Guttman wrote: DC Sure. Just as $42 is a shorthand for $/[42], so too $whatever is a DC shorthand for $/whatever. but then what about the different index bases for $42 and $/[42]? i don't think that has been resolved (nor has mixing the $1.1 and $1[1] syntaxes). DC Bear in mind that that reply was posted in haste, late at night, after DC a long day of teaching. We're lucky it as only off by one! %-) DC But it does raise an important point: the discrepancy between $42 and DC $/[41] *is* a great opportunity for off-by-on errors. Previously, DC however, @Larry have tossed back and forth the possibility of using $0 DC as the first capture variable so that the indices of $/[0], $/[1], DC $/[2] match up with the names of $0, $1, $2, etc. DC I think this error--unintentional, I swear!--argues strongly that DC internal consistency within Perl 6 is more important than historical DC consistency with Perl 5's $1, $2, $3... i would like them to be consistant too. you could also make $/[1] be the same as $1 and not use $/[0] for a regular grab. then $0 and $/[0] could be used for something special. but just 0 basing them both is fine with me. the key is to align them. we all seem to agree this is a massive off by 1 error waiting to happen. we still haven't seen what @larry has to say about mixing $1[$j] and $1.1 syntaxes (let's assume they both use the same index base). uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Nested captures
On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote: : But that's only the opinion of one(@Larry), not of $Larry. Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens. Our old $0 (P5's $) could be $ instead, short for $MATCH or some such. It's already the case that p5-to-p6 is going to have a *wonderful* time translating $7 to $1[2][0]... I wonder how much call there will be for a rule option that uses P6 syntax but P5 paren binding with push semantics. Larry
Re: Nested captures
On Wed, May 11, 2005 at 08:30:42AM -0700, Larry Wall wrote: On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote: : But that's only the opinion of one(@Larry), not of $Larry. Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens. Our old $0 (P5's $) could be $ instead, short for $MATCH or some such. Both 0-based $0 etc and $ are now implemented in Pugs. It's already the case that p5-to-p6 is going to have a *wonderful* time translating $7 to $1[2][0]... I wonder how much call there will be for a rule option that uses P6 syntax but P5 paren binding with push semantics. Should it be an rule option, or simply an alternate way to address the content in $/? Something like $/.flattened_matches[10], perhaps? Thanks, /Autrijus/ pgpoESxp72tIn.pgp Description: PGP signature
Re: Nested captures
H, On Wed, May 11, 2005 at 08:30:42AM -0700, Larry Wall wrote: On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote: : But that's only the opinion of one(@Larry), not of $Larry. Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens. Our old $0 (P5's $) could be $ instead, short for $MATCH or some such. Both 0-based $0 etc and $ are now implemented in Pugs. Does anybody check if he actually implements what he say? :))) It just doesn't seem possible... :) Autrijus, I assume you started Pugs by creating Time::Machine first... BTW, anybody interested in creating and FastCGI interface for Pugs? - Fagzal
Re: Nested captures
On Thu, May 12, 2005 at 12:06:57AM +0800, Autrijus Tang wrote: On Wed, May 11, 2005 at 08:30:42AM -0700, Larry Wall wrote: On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote: : But that's only the opinion of one(@Larry), not of $Larry. Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens. Our old $0 (P5's $) could be $ instead, short for $MATCH or some such. Both 0-based $0 etc and $ are now implemented in Pugs. $0 is also in PGE, $ will wait for a more definitive statement. I wonder how much call there will be for a rule option that uses P6 syntax but P5 paren binding with push semantics. Should it be an rule option, or simply an alternate way to address the content in $/? Something like $/.flattened_matches[10], perhaps? Could be, although I'd prefer $/.lparens or something like that, to make it clear we're counting left parens. Flattened_matches sounds to me like we're flattening all of the captures into a single list. But then again, lparens looks odd when presented with something like: / $7:=[\s+] / since there really aren't any lparens there. Maybe $/.perl5[10] . :-) To make things work this way, PGE will have to tag match objects along both the nested and non-nested lexical scopes of the rule pattern. Not too big an issue--just more bookkeeping to keep track of. OTOH, since :perl5 is already flattening its paren captures, there's precedent for doing this sort of thing as a rule option. It may make more sense to request flatness within the rule as opposed to (in addition to?) the returned match object. Pm
Re: Nested captures
Larry Wall skribis 2005-05-11 8:30 (-0700): It's already the case that p5-to-p6 is going to have a *wonderful* time translating $7 to $1[2][0]... If I remember correctly, ** recursively flattens, and so (**$/)[7-1] should work. And otherwise a simple method can probably do the trick. I suggest $/.platalseendubbeltje.[7-1], but probably only Dutch people can appreciate that. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Nested captures
Larry Wall skribis 2005-05-11 8:30 (-0700): It's already the case that p5-to-p6 is going to have a *wonderful* time translating $7 to $1[2][0]... Or maybe it just has to change ( to $1 := (, the second ( to $2 := (, etc. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
single element lists
We're discussing the proper semantics of (1)[0] on #perl6. Here's where we're at so far: 1. specialise ()[] to parse as (,)[] 2. scalars are singleton lists, so ()[] naturally 3. make (1)[0] die horribly. We all seem to agree that #3 is least useful and probably wrong. But there's a divide between whether #1 or #2 is the right behavior. #2 implies that (1)[0][0][0][0] == 1 #1 means that (1)[0] == 1 and (1)[0][0] is an error FWIW, I'm in favor of #1 What does p6l think? (What does @Larry think?) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: single element lists
Jonathan Scott Duff wrote: What does p6l think? (What does @Larry think?) I favor #3 as syntax error. But note $TSa == all( none(@Larry), one($p6l) ) or so :) -- TSa (Thomas Sandlaß)
Re: single element lists
Jonathan Scott Duff skribis 2005-05-11 11:45 (-0500): 1. specialise ()[] to parse as (,)[] 2. scalars are singleton lists, so ()[] naturally 3. make (1)[0] die horribly. #2 implies that (1)[0][0][0][0] == 1 #1 means that (1)[0] == 1 and (1)[0][0] is an error #1 also means that ($aref)[0] is $aref, rather than $aref[0]. I pick #2, also because I think being able to pass scalars where arrays are expected simplifies other parts of the language as well. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Nested captures
On Wed, May 11, 2005 at 06:37:53PM +0200, Juerd wrote: Larry Wall skribis 2005-05-11 8:30 (-0700): It's already the case that p5-to-p6 is going to have a *wonderful* time translating $7 to $1[2][0]... Or maybe it just has to change ( to $1 := (, the second ( to $2 := (, etc. More likely $1:=[, $2:=[, etc., to avoid the nested capture contexts. Slightly trickier is going to be handling of quantified captures, since $1 has to somehow be translated into $0 for unquantified captures and $0[-1] for quantified ones. Or we have a method in the match object that can do that for us. And in some cases it might be better to just stick :perl5 on the rule and not translate it. :-) Of course, this now begs the question -- where are things stored after doing ... ? rx :perl5 / (don't) (ray) (me) (for solar) / My guess is that within the rule they're $1, $2, $3, etc. as before, but in the match object they're $/[0], $/[1], $/[2], so that we can still properly do: ($c, $d, $e, $fg) = rx :perl5 / (don't) (ray) (me) (for solar) /; Or perhaps $1, $2, $3, etc become smart aliases into the match object, that somehow know what they're supposed to reference based on the rule that produced it. I.e., they're $/[1], $/[2], $/[3] for perl 6 rules and $/[0], $/[1], $/[2] for :perl5 rules. Or perhaps that just leads to total madness... Pm
Re: Nested captures
On Wed, May 11, 2005 at 12:01:35PM -0500, Patrick R. Michaud wrote: Of course, this now begs the question -- where are things stored after doing ... ? rx :perl5 / (don't) (ray) (me) (for solar) / My guess is that within the rule they're $1, $2, $3, etc. as before, Within the rule, $1 and $2 should still refer to the previous match, as in P5 rules they are spelled as \1 and \2. Of course, with P5 rules, they would not be written as \0 and \1 simply because they are running in Perl 6. However, the subst part of s/// may look weird: pugs $_ = foo foo; s:P5/(\w+) \1/--$0--/; $_ '--foo--' But it's probably unavoidable. Thanks, /Autrijus/ pgp7CKwIDXwVM.pgp Description: PGP signature
Re: single element lists
On 5/11/05, Juerd [EMAIL PROTECTED] wrote: Jonathan Scott Duff skribis 2005-05-11 11:45 (-0500): 1. specialise ()[] to parse as (,)[] 2. scalars are singleton lists, so ()[] naturally 3. make (1)[0] die horribly. #2 implies that (1)[0][0][0][0] == 1 #1 means that (1)[0] == 1 and (1)[0][0] is an error #1 also means that ($aref)[0] is $aref, rather than $aref[0]. I pick #2, also because I think being able to pass scalars where arrays are expected simplifies other parts of the language as well. #2 is also more intuitive and comfortable. () in P5 constructs a list, which is why (split ' ', $foo)[0] works so nicely.
Re: r7994: win32--msvc-7.1--perl-5.8.6 test error report
all is good in r8061. seems i had forgotton to flush during internal_exception in my working copy, so i still had test failures. leo's applied your patch and added the interpreter flushes as well, so i can revert my changes back to HEAD. thanks. ~jerry On 5/10/05, François PERRAD [EMAIL PROTECTED] wrote: At 13:55 06/05/2005 -0700, you wrote: t\op\debuginfo.t 5 1280 85 62.50% 4-8 Consider the last version of my patch attached to [perl #35083]. Francois. ~jerry
Re: Nested captures
On Wed, May 11, 2005 at 08:30:42AM -0700, Larry Wall wrote: Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens. As Decreed on perl6-language, henceforth PGE shall be using $0, $1, $2, ... for subpattern captures and aliases into the match object's array. Thus It has been Made So (r8062), and there is Great Rejoicing and Celebration throughout the Lands. Pm
Re: single element lists
My perspective from PDL is that (1)[0][0][0]...[0] should evaluate to 1. The artificial distinction between a scalar and an array of length 1 (in each dimension) is the source of endless hassles, and it's a pretty simple DWIM to allow indexing of element 0 of any unused dimension. That makes it much, much easier to write code that generalizes, because you don't have to check for the scalar case -- you can always assume that any given dimensional axis will always have one value along it (*), and loop/thread/whatever along that dimension. (*) Of course, that's assuming that there's at least one value in the list as a whole -- PDL does, and perl 6 should, support zero-element lists; any looping or threading construct on a zero-element list is a no-op. Jonathan Scott Duff wrote: We're discussing the proper semantics of (1)[0] on #perl6. Here's where we're at so far: 1. specialise ()[] to parse as (,)[] 2. scalars are singleton lists, so ()[] naturally 3. make (1)[0] die horribly. We all seem to agree that #3 is least useful and probably wrong. But there's a divide between whether #1 or #2 is the right behavior. #2 implies that (1)[0][0][0][0] == 1 #1 means that (1)[0] == 1 and (1)[0][0] is an error FWIW, I'm in favor of #1 What does p6l think? (What does @Larry think?) -Scott
Re: single element lists
On Wed, 2005-05-11 at 12:45, Jonathan Scott Duff wrote: We're discussing the proper semantics of (1)[0] on #perl6. Here's where we're at so far: 1. specialise ()[] to parse as (,)[] 2. scalars are singleton lists, so ()[] naturally 3. make (1)[0] die horribly. It may or may not help, but I direct your attention to: http://groups-beta.google.com/group/perl.perl6.language/browse_frm/thread/24ef8f421548b806/f119fc38427f9f3b?q=comma+one+elementrnum=2#f119fc38427f9f3b -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
small typo in PBC_COMPAT
Hello, I fixed a small typo in PBC_COMPAT. Btw. the tests in t/p6rules/*.t have 'no_plan'. Should this be changed to reflect the correct number of tests? I have this patch ready, but I'm too shy to post :-) Bye, Uwe Index: PBC_COMPAT === --- PBC_COMPAT (revision 8061) +++ PBC_COMPAT (working copy) @@ -5,7 +5,7 @@ # fingerprint inside PBCs and Parrot which is used # for validation. # -# Its pobably not complete or out of date - but a start +# Its probably not complete or out of date - but a start # to get less restrictive fingerprint tests. # # Currently known actions that should be entered here
[perl #35412] [PATCH] remove io_win32.c warning
# New Ticket Created by jerry gay # Please include the string: [perl #35412] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35412 this simple patch removes a build warning in io\io_win32.c: io\io_win32.c(272) : warning C4550: expression evaluates to a function which is missing an argument list with patch applied, all expected tests pass. ~jerry Index: io/io_win32.c === --- io/io_win32.c (revision 8062) +++ io/io_win32.c (working copy) @@ -269,7 +269,6 @@ INTVAL mode; mode = 0; -UNUSED(fdopen); UNUSED(layer); if (PIO_win32_isatty(fd))
Namespaces, again
Seems like the last major thread on namespace issues, especially inter-language issues, was around October last year and didn't reach any firm conclusions. What's the current status? Tim.
Re: small typo in PBC_COMPAT
On Wed, 2005-05-11 at 18:16 +0200, Uwe Voelker wrote: I fixed a small typo in PBC_COMPAT. Thanks, applied. Btw. the tests in t/p6rules/*.t have 'no_plan'. Should this be changed to reflect the correct number of tests? I have this patch ready, but I'm too shy to post :-) That seems reasonable to me. Please do. -- c
Re: small typo in PBC_COMPAT
chromatic schrieb: On Wed, 2005-05-11 at 18:16 +0200, Uwe Voelker wrote: I fixed a small typo in PBC_COMPAT. Thanks, applied. From reading PBC_COMPAT I gathered that PBC_COMPAT should only be changed, when the PBC syntax has changed. # The text in this file is also the base of the # fingerprint inside PBCs and Parrot which is used # for validation. and # After changing PBC_COMPAT either disable t/native_pbc tests or # better, if you have an i386 box at hand, regenerate the PBCs # with tools/dev/mk_native_pbc and commit the changes So shouldn't the speling fixes wait for 0.3.0, or is changing the comments OK? CU, Bernhard
[perl #35412] [PATCH] remove io_win32.c warning
this simple patch removes a build warning in io\io_win32.c: io\io_win32.c(272) : warning C4550: expression evaluates to a function which is missing an argument list The patch is applied. This warning surfaces only because I had inadvertedly enabled PARROT_NET_DEVEL in io/io_private.h in SVN revision 7974. Luckily no major harm seemed to have done by that. The good thing is that the tiny webserver './parrot exambles/io/httpd.imc' should work now out of the box. Thanks to Robert Spiers with a neat Parrot as favicon. CU, Bernhard CU, Bernhard
Re: Nested captures
On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote: : But that's only the opinion of one(@Larry), not of $Larry. Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens. Our old $0 (P5's $) could be $ instead, short for $MATCH or some such. Why can't bare $/ just striingify to the whole match? It's already the case that p5-to-p6 is going to have a *wonderful* time translating $7 to $1[2][0]... Not a real problem. Patrick has already said that his plan is that :p5 REs will return a match object with an already flattened match list using perl5 left peren counting semantics. I wonder how much call there will be for a rule option that uses P6 syntax but P5 paren binding with push semantics. Just add a :flat -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
object attribute access - rev 8067
I've now changed the class attribute code, so that short attribute names work too. The short names are stored in the same hash as the qualified names. The hash is rebuilt in reverse MRO order so that a subclassed short name invalidates a parent's short name. This attribute is still available with a full qualified name, but WRT interoperbility, please don't use this feature. See also t/pmc/objects_62.pasm. I've also cleaned the code a bit by tossing around 50 lines in objects.c. Have fun, leo
Re: Namespaces, again
Tim wrote: Seems like the last major thread on namespace issues, especially inter-language issues, was around October last year and didn't reach any firm conclusions. What's the current status? Pretty much the same. There is now an additional namespace __parrot_core, where MMD subroutines are gathered. The rest is unchanged and needs more design input. Tim. leo
[perl #35413] [PATCH] r8062: convert internal exceptions to real exceptions - array
# New Ticket Created by jerry gay # Please include the string: [perl #35413] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35413 i'm converting many of the remaining internal_exception() calls to real_exception() (except unimplemented ops, and other valid internal exceptions) before i send a list of patches for various files to the list, i'd like to make sure this first patch is agreeable. i added a new exception type (E_IndexOutOfBoundsError,) converted exceptions for the array pmc, and modified it's test file. all expected tests pass. ~jerry exceptions-array.patch Description: Binary data
Re: small typo in PBC_COMPAT
That seems reasonable to me. Please do.
Here it is (together with a gentle reminder at the end of the .t file :-)
But feel free to leave this line out.
Uwe
Index: t/p6rules/anchors.t
===
--- t/p6rules/anchors.t (revision 8065)
+++ t/p6rules/anchors.t (working copy)
@@ -1,4 +1,4 @@
-use Parrot::Test 'no_plan';
+use Parrot::Test tests = 26;
use Parrot::Test::PGE;
$str = q{abc
@@ -36,3 +36,7 @@
p6rule_isnt($str, 'ghi\B', 'EOS nonword boundary');
p6rule_is ($str, 'a\B', '\w\w nonword boundary');
p6rule_is ($str, '-\B', '\W\W nonword boundary');
+
+
+
+# dont forget to change the number of tests :-)
Index: t/p6rules/capture.t
===
--- t/p6rules/capture.t (revision 8065)
+++ t/p6rules/capture.t (working copy)
@@ -1,4 +1,4 @@
-use Parrot::Test 'no_plan';
+use Parrot::Test tests = 34;
use Parrot::Test::PGE;
p6rule_is ('zzzabcdefzzz', '(a.)..(..)', 'basic match');
@@ -66,3 +66,7 @@
p6rule_like('123x', '(.)*x',
qr/mob: 123x @ 0/, 'repeated dot capture')
+
+
+
+# dont forget to change the number of test :-)
Index: t/p6rules/backtrack.t
===
--- t/p6rules/backtrack.t (revision 8065)
+++ t/p6rules/backtrack.t (working copy)
@@ -1,4 +1,4 @@
-use Parrot::Test 'no_plan';
+use Parrot::Test tests = 11;
use Parrot::Test::PGE;
p6rule_is( 'bazaar', 'a* a', 'control');
@@ -15,3 +15,7 @@
p6rule_is( 'whence', '[ when ever ] | whence', 'full backtrack failure');
p6rule_isnt('whence', '[ when ::: ever ] | whence', 'full backtrack failure');
+
+
+
+# dont forget to change the number of tests :-)
Index: t/p6rules/cclass.t
===
--- t/p6rules/cclass.t (revision 8065)
+++ t/p6rules/cclass.t (working copy)
@@ -1,4 +1,8 @@
-use Parrot::Test 'no_plan';
+use Parrot::Test tests = 1;
use Parrot::Test::PGE;
p6rule_is( 'abcdef', 'a\N+?f', 'lazy newline')
+
+
+
+# dont forget to change the number of tests :-)
Re: small typo in PBC_COMPAT
On Wed, May 11, 2005 at 06:16:27PM +0200, Uwe Voelker wrote: Hello, I fixed a small typo in PBC_COMPAT. Btw. the tests in t/p6rules/*.t have 'no_plan'. Should this be changed to reflect the correct number of tests? I have this patch ready, but I'm too shy to post :-) Feel free to correct 'no_plan'. I'll happily apply any and all patches to the tests, and those with commit privs are welcome to directly modify the t/p6rules/*.t files at any time. Pm
Re: Nested captures
On Wed, May 11, 2005 at 06:35:36PM +0200, Juerd wrote: : Larry Wall skribis 2005-05-11 8:30 (-0700): : It's already the case that p5-to-p6 is going to have a *wonderful* : time translating $7 to $1[2][0]... : : If I remember correctly, ** recursively flattens, and so (**$/)[7-1] : should work. It doesn't. It just does one level of flattening, but it does it *now*. : And otherwise a simple method can probably do the trick. I suggest : $/.platalseendubbeltje.[7-1], but probably only Dutch people can : appreciate that. That works with some translated constructs but not others. I'm wondering if it's just a cardinal/ordinal thing, and we can just translate $7 to $7th. Then we don't have to guess where to insert a .flat or :flat. Larry
Re: single element lists
On Wed, May 11, 2005 at 11:45:12AM -0500, Jonathan Scott Duff wrote: : : We're discussing the proper semantics of (1)[0] on #perl6. Here's : where we're at so far: : : 1. specialise ()[] to parse as (,)[] : 2. scalars are singleton lists, so ()[] naturally : 3. make (1)[0] die horribly. : : We all seem to agree that #3 is least useful and probably wrong. But : there's a divide between whether #1 or #2 is the right behavior. : : #2 implies that (1)[0][0][0][0] == 1 : #1 means that (1)[0] == 1 and (1)[0][0] is an error : : FWIW, I'm in favor of #1 : : What does p6l think? (What does @Larry think?) I think it has to be #1. We can't have (@foo)[0] working at two different indirection levels depending on whether @foo == 1. Larry
Re: single element lists
On Wed, May 11, 2005 at 01:11:45PM -0700, Larry Wall wrote: On Wed, May 11, 2005 at 11:45:12AM -0500, Jonathan Scott Duff wrote: : : We're discussing the proper semantics of (1)[0] on #perl6. Here's : where we're at so far: : : 1. specialise ()[] to parse as (,)[] : 2. scalars are singleton lists, so ()[] naturally : 3. make (1)[0] die horribly. : I think it has to be #1. We can't have (@foo)[0] working at two different indirection levels depending on whether @foo == 1. Hm? Under #2, no matter whether @foo is (1) or (1,2), the construct (@foo)[0] would always means @foo.[0]. Not sure how the length of @foo matters here. Thanks, /Autrijus/ pgpiDLzKqsG2b.pgp Description: PGP signature
volunteer wanted for xml grammar thingy
Three years ago I wrote a simple Perl 5 script to convert the EBNF specification of XML to Perl 6's rules. Pugs supports rules now, so perhaps it can be tested. This is a complex job (because it's a complex grammar, and of course it can never work without much tweaking, and debugging grammars is probably hard), that I won't be able ta handle. So now I'm looking for someone who wants to do this. It doesn't have to be done, but I think it'd be really nice to show the world we can parse XML already. It's by no means a useful parsing, but I do think it's a good stress test of PGE. Everything can be found at http://perlmonks.org/index.pl?node_id=179755 Who wants to give this a serious try? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
(1,(2,3),4)[2]
In a somewhat related topic: pugs (1,(2,3),4)[2] 4 Because the invocant to .[] assumes a Singular context. I'm not sure how any invocant can assume a Plural context anyway, so this behaviour seems correct. Is it, though? :) Thanks, /Autrijus/ pgpQf1TyWmCFa.pgp Description: PGP signature
Re: (1,(2,3),4)[2]
On 5/11/05, Autrijus Tang [EMAIL PROTECTED] wrote: In a somewhat related topic: pugs (1,(2,3),4)[2] 4 Because the invocant to .[] assumes a Singular context. Right, but the *inside* of the invocant is still a list, so it's in list context. I think that line should return 3. Luke
Re: (1,(2,3),4)[2]
On Wed, May 11, 2005 at 03:00:15PM -0600, Luke Palmer wrote: On 5/11/05, Autrijus Tang [EMAIL PROTECTED] wrote: In a somewhat related topic: pugs (1,(2,3),4)[2] 4 Because the invocant to .[] assumes a Singular context. Right, but the *inside* of the invocant is still a list, so it's in list context. I think that line should return 3. You're totally right, and I was clearly wahnsinnig. It now returns 3. Thanks, /Autrijus/ pgpLFhPsoPG5N.pgp Description: PGP signature
t/oo/class/basic.t path for class Foo::Bar {} failure
Index: t/oo/class/basic.t
===
--- t/oo/class/basic.t(revision 2970)
+++ t/oo/class/basic.t(working copy)
@@ -21,6 +21,11 @@
my $foo_clone = $foo.clone();
ok($foo_clone ~~ Foo, '... smartmatch our $foo_clone to the Foo
class');
+eval 'class Foo::Bar {}';
+
+my $foo_bar = eval 'Foo::Bar.new()';
+eval_ok('$foo_bar ~~ Foo::Bar', '... smartmatch our $foo_bar to the
Foo::Bar class');
+
# LS12/Classes /An \isa\ is just a trait that happens to be
another class\:/
eval 'class Bar is Foo {}';
Re: single element lists
On Thu, May 12, 2005 at 04:19:02AM +0800, Autrijus Tang wrote: : Hm? Under #2, no matter whether @foo is (1) or (1,2), the construct : (@foo)[0] would always means @foo.[0]. Not sure how the length of @foo : matters here. Tell you what, let's require P5's (...)[] to be translated to [...][], so (...)[] should assume scalar context that will return some kind of array reference. (What Luke said about (1,(2,3),4)[] still holds, though. Commas create lists, and lists by default impose list context, and parens are only for grouping in lists, not scalarifiying.) Larry
Re: single element lists
On Wed, May 11, 2005 at 02:12:41PM -0700, Larry Wall wrote: On Thu, May 12, 2005 at 04:19:02AM +0800, Autrijus Tang wrote: : Hm? Under #2, no matter whether @foo is (1) or (1,2), the construct : (@foo)[0] would always means @foo.[0]. Not sure how the length of @foo : matters here. Tell you what, let's require P5's (...)[] to be translated to [...][], so (...)[] should assume scalar context that will return some kind of array reference. (What Luke said about (1,(2,3),4)[] still holds, though. Commas create lists, and lists by default impose list context, and parens are only for grouping in lists, not scalarifiying.) Sure (and done). Now that #1 is eliminated, the question is now whether a simple scalar can be treated as a small (one-element) array reference, much like a simple pair can be treated as a small (one-element) hash reference. 1.[0]; # evaluates to 1? If yes, then (1)[0] means the same as 1.[0] and 1.[0][0][0]. If no, (1)[0] is a runtime error just like 1.[0] -- i.e. unable to find the matching .[] multisub under Int or its superclasses. Thanks, /Autrijus/ pgpeoBPwdpegh.pgp Description: PGP signature
Re: t/oo/class/basic.t path for class Foo::Bar {} failure
Thanks, both yours and Shillo's tests are applied (and implemented). /Autrijus/ pgpi79NWrtGna.pgp Description: PGP signature
Re: [PATCH] Cosmetic updates to MD5 library
Leopold Toetsch wrote: I have now implemented a Crot opcode and the one used signature for MD5 as a JIT opcode for x86. But the speedup is much smaller: around 5%. Thanks! The problem with md5 code and Parrot JIT seems to be related to the register allocator. md5 code is one big basic block of integer code. As we don't do any register renaming, the CPU-register usage especially on x86 is suboptimal. I must admit that I thought that one basic block of integer code would run pretty well (that's why I inlined it all). It touches lots of registers because its job is to do lots of mashing of bits! Comparing the performance with the OS md5sum was more just a curiosity; it's not really a fair comparison. Cheers Leo, Nick
Re: small typo in PBC_COMPAT
On Wed, 11 May 2005, Patrick R. Michaud wrote: On Wed, May 11, 2005 at 06:16:27PM +0200, Uwe Voelker wrote: Btw. the tests in t/p6rules/*.t have 'no_plan'. Should this be changed to reflect the correct number of tests? I have this patch ready, but I'm too shy to post :-) Feel free to correct 'no_plan'. I'll happily apply any and all patches to the tests, and those with commit privs are welcome to directly modify the t/p6rules/*.t files at any time. Speak of the devil -- I started working on more unit tests for p6rules today, starting with the things Patrick listed the other day in his PGE features update: Newsgroups: perl.perl6.compiler,perl.perl6.internals Date: Sun, 8 May 2005 10:50:57 -0500 To: perl6-internals[at]perl.org, perl6-compiler[at]perl.org Subject: PGE features update Message-ID: 20050508155057.GA25186[at]pmichaud.com From: pmichaud[at]pobox.com (Patrick R. Michaud) There have been a lot of substantial updates to the Parrot Grammar Engine, so I figure it's a good time for a summary report. The latest version (in the Parrot cvs trunk) now incorporates: - subrules - capture aliases (named and numbered) - the :w modifier and ?ws subrules - word boundaries (\b and \B) - simple backreferences ($1, $2, $term, etc.) Also, more tests have been added to t/p6rules, but we definitely need more. Tests are especially needed for: - Rules specified with and without :w modifiers - calls to subrules - named alias captures - numbered alias captures - \s \S \w \W \d \D \n \N I figured this for a good opportunity to get the hang of the new rules syntax. I'm now reading S05 in detail. :) Pm -Dino -- .~.Dino Morelli /V\email: [EMAIL PROTECTED] /( )\ weblog: http://categorically.net/d/blog/ ^^-^^ preferred distro: Debian GNU/Linux http://www.debian.org
Re: (1,(2,3),4)[2]
All~ On 5/11/05, Luke Palmer [EMAIL PROTECTED] wrote: On 5/11/05, Autrijus Tang [EMAIL PROTECTED] wrote: In a somewhat related topic: pugs (1,(2,3),4)[2] 4 Because the invocant to .[] assumes a Singular context. Right, but the *inside* of the invocant is still a list, so it's in list context. I think that line should return 3. I am confused as to why exactly this is the case. Are you saying that nested lists like this flatten? That would certainly catch me off guard. Would you mind explaining that to me a little more? Thanks, Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: single element lists
On Thu, May 12, 2005 at 05:19:11AM +0800, Autrijus Tang wrote: : Sure (and done). Now that #1 is eliminated, the question is now : whether a simple scalar can be treated as a small (one-element) array : reference, much like a simple pair can be treated as a small : (one-element) hash reference. : : 1.[0]; # evaluates to 1? : : If yes, then (1)[0] means the same as 1.[0] and 1.[0][0][0]. If no, : (1)[0] is a runtime error just like 1.[0] -- i.e. unable to find the : matching .[] multisub under Int or its superclasses. Maybe we should just let someone poke a Subscriptable role into some class or other to determine the behavior if they care. Larry
Re: Nested captures
Larry decreed: Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens. Huzzah! Our old $0 (P5's $) could be $ instead, short for $MATCH or some such. According to the new capture semantics document posted earlier this week: A successful match returns a CMatch object whose ... string value is the complete substring that was matched by the entire rule... So the old $0 is just ~$/ Damian
Re: Nested captures
Larry mused: I'm wondering if it's just a cardinal/ordinal thing, and we can just translate $7 to $7th. Then we don't have to guess where to insert a .flat or :flat. That's a very interesting generalization. There are plenty of *other* cases where one wants an ordinal, or some other kind of $n-1 value. If Cth (and Cst, Cnd, Crd) was a subtract one operator, you could write: my $n = prompt How many elems? ; print @array[1st..($n)th]; instead of the out-by-one-prone: print @array[0..$n-1] Hmmm. Damian
Re: (1,(2,3),4)[2]
On Wed, 2005-05-11 at 17:48, Matt Fowles wrote: On 5/11/05, Luke Palmer [EMAIL PROTECTED] wrote: On 5/11/05, Autrijus Tang [EMAIL PROTECTED] wrote: In a somewhat related topic: pugs (1,(2,3),4)[2] 4 Because the invocant to .[] assumes a Singular context. Right, but the *inside* of the invocant is still a list, so it's in list context. I think that line should return 3. I am confused as to why exactly this is the case. Are you saying that nested lists like this flatten? That would certainly catch me off guard. Would you mind explaining that to me a little more? I'm confused as well. How does that play with Larry's comment: http://groups-beta.google.com/group/perl.perl6.language/browse_frm/thread/54a1135c012b97bf/d17b4bc5ae7db058?q=list+commarnum=5hl=en#d17b4bc5ae7db058 -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Nested captures
Damian Conway wrote: print @array[1st..($n)th]; Sounds cool, but what about $n = 0; ? - Fagzal
Re: Nested captures
On Thu, May 12, 2005 at 12:37:06AM +0200, Fagyal Csongor wrote: Damian Conway wrote: print @array[1st..($n)th]; Sounds cool, but what about $n = 0; ? Then it would be 0..-1, an empty range. /Autrijus/ pgpRRkOMafCIK.pgp Description: PGP signature
Re: Nested captures
Autrijus Tang wrote: On Thu, May 12, 2005 at 12:37:06AM +0200, Fagyal Csongor wrote: Damian Conway wrote: print @array[1st..($n)th]; Sounds cool, but what about $n = 0; ? Then it would be 0..-1, an empty range. Yep, but I mean in general isn't it confusing that the 0th element is actually the -1st (in Perl5 sense)? Does this mean that the -1st (Perl6) element would be the -2nd (Perl5)? Or are (-n)th elements invalid? - Fagzal
Re: (1,(2,3),4)[2]
On Wed, May 11, 2005 at 03:00:15PM -0600, Luke Palmer wrote:
On 5/11/05, Autrijus Tang [EMAIL PROTECTED] wrote:
In a somewhat related topic:
pugs (1,(2,3),4)[2]
4
Because the invocant to .[] assumes a Singular context.
Right, but the *inside* of the invocant is still a list, so it's in
list context. I think that line should return 3.
Okay. Here is the current (all-passing) t/data_types/nested_arrays.t:
{
my @a = (1,2,[3,4]);
my $a = (1,2,[3,4]);
my @b = [1,2,[3,4]];
my $b = [1,2,[3,4]];
my @c = (1,2,(3,4));
my $c = (1,2,(3,4));
my @d = [1,2,(3,4)];
my $d = [1,2,(3,4)];
is([EMAIL PROTECTED], 3, 'Array length, nested []');
is(+$a, 3, 'Array ref length, nested []');
is([EMAIL PROTECTED], 1, 'Array length, nested [], outer []s');
is(+$b, 3, 'Array ref length, nested [], outer []s');
is(+$c, 4, 'Array ref length, nested ()');
is([EMAIL PROTECTED], 4, 'Array length, nested ()');
is([EMAIL PROTECTED], 1, 'Array length, nested (), outer []s');
is(+$d, 4, 'Array ref length, nested (), outer []s');
}
Please sanity-check. :-)
Thanks,
/Autrijus/
pgpSkGBNuwZIH.pgp
Description: PGP signature
Re: (1,(2,3),4)[2]
(reformatted to keep initialization with test) Autrijus Tang skribis 2005-05-12 7:04 (+0800): my @a = (1,2,[3,4]); is([EMAIL PROTECTED], 3, 'Array length, nested []'); ok 1 my $a = (1,2,[3,4]); is(+$a, 3, 'Array ref length, nested []'); ok 2 my @b = [1,2,[3,4]]; is([EMAIL PROTECTED], 1, 'Array length, nested [], outer []s'); ok 3 my $b = [1,2,[3,4]]; is(+$b, 3, 'Array ref length, nested [], outer []s'); ok 4 my @c = (1,2,(3,4)); is(+$c, 4, 'Array ref length, nested ()'); ok 5 my $c = (1,2,(3,4)); is([EMAIL PROTECTED], 4, 'Array length, nested ()'); ok 6 my @d = [1,2,(3,4)]; is([EMAIL PROTECTED], 1, 'Array length, nested (), outer []s'); ok 7 my $d = [1,2,(3,4)]; is(+$d, 4, 'Array ref length, nested (), outer []s'); ok 8 Please sanity-check. :-) All sane! :) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
A regression test
This is an addition to t/operators/hyper.t. It regression-checks for
the bug discussed on #perl6 (in a nutshell, hyper ops used to only
work on list literals, but not on array variables).
{ # regression test, ensure that hyper works on arrays
my @r1;
my @r2;
my @e1 = (2, 4, 6);
my @e2 = (2, 3, 4);
my @a = (1, 2, 3);
@r1 = @a + @a;
@r2 = @a + 1;
is([EMAIL PROTECTED], [EMAIL PROTECTED], hyper op works on variables,
too.);
is([EMAIL PROTECTED], [EMAIL PROTECTED], hyper op and correctly
promotes scalars);
};
Re: single element lists
On Wed, May 11, 2005 at 11:45:12AM -0500, Jonathan Scott Duff wrote: We're discussing the proper semantics of (1)[0] on #perl6. Here's where we're at so far: 1. specialise ()[] to parse as (,)[] 2. scalars are singleton lists, so ()[] naturally 3. make (1)[0] die horribly. (1)[0] means 1[0], which is probably undefined, so it dies. That could be detected at compile time. (my $foo = 1)[0] means $foo[0], which would die at runtime, unless there's type inference going on. In any case, I don't see a List in ()[] without a list-creating expression in the (). -Scott -- wolverian signature.asc Description: Digital signature
Re: Nested captures
That's a very interesting generalization. There are plenty of *other* cases where one wants an ordinal, or some other kind of $n-1 value. If Cth (and Cst, Cnd, Crd) was a subtract one operator, you could write: my $n = prompt How many elems? ; print @array[1st..($n)th]; instead of the out-by-one-prone: print @array[0..$n-1] Not to be insolent here, but could it be that the Cth ops be 'smart' enough to recognize the various zero based (vs one based?) situations and behave accordingly? Something like checking the (deprecated) $[ to see if they are supposed to be n or n -1? a Andy Bach, Sys. Mangler Internet: [EMAIL PROTECTED] VOICE: (608) 261-5738 FAX 264-5932 Outside of a dog, a book is man's best friend. Inside of a dog, its too dark to read. Groucho Marx
Re: (1,(2,3),4)[2]
On Thu, May 12, 2005 at 07:04:48AM +0800, Autrijus Tang wrote: : Please sanity-check. :-) Looks good to me. Though that should perhaps not be confused with sanity. Larry
Re: (1,(2,3),4)[2]
On Wed, May 11, 2005 at 06:24:38PM -0400, Aaron Sherman wrote: : I'm confused as well. How does that play with Larry's comment: : : http://groups-beta.google.com/group/perl.perl6.language/browse_frm/thread/54a1135c012b97bf/d17b4bc5ae7db058?q=list+commarnum=5hl=en#d17b4bc5ae7db058 Well, that approach would also work. I'm just not sure it's what people would expect. It's a little retroactive for .[] to change the context of the expressions in (). These days I think I'd rather have something out front that specifically says you want a list of scalars. Perhaps scalar(1,(2,3),4) should be our list of scalars context, and produce [1,[2,3],4]. Or maybe something else should indicate LoS. Larry
character classes in p6 rules
I now have a basic implementation for enumerated character classes in the grammar engine (i.e., [xyz], -[xyz], [x..z], and -[x..z]). I didn't see it specified anywhere, but are the \d, \D, \s, \S, etc. metacharacters still supposed to work inside of a enumerated character class, as they do in Perl 5? Or in p6 do we always use +digit+[xyz], -digit, +sp, -sp, etc.? (Yes, I know that normally the absence of any spec to the contrary indicates that we're still using p5 semantics, but this one is worth verification for me.) While I'm on the subject, let me just ramble a bit -- there are times when alpha, digit, upper, etc. give me a bad feeling -- they look a little too much like subrules to me, especially when looking at +alpha and the like. I keep wondering about things like +ident and -expr. And something like C rx / alpha* / may generate a lot of not-very-useful one-character captures into $/alpha , so that we'll typically want to get in the habit of writing rx / ?alpha* / rx / +alpha* / and then have the engine recognize when this occurs so it can optimize to a much faster character class op rather than a lot of calls to a separate subrule. Plus, +alpha just looks plain ugly and unbalanced to me. Somehow I'd like to get rid of those inner angles, so that we always use +alpha, +digit, -sp, -punct to indicate named character classes, and specify combinations with constructions like +alpha+punct-[aeiou] and +word-[_]. We'd still allow [abc] as a shortcut to +[abc]. To me this looks cleaner overall, makes it clear we're doing a one-character non-capturing match, and may enable a few optimization possibilities. (I'm sure that with enough effort we can get equivalent optimizations out of the existing syntax, and we may need them anyway in the long run, but this might simplify that a fair bit.) I haven't thought far ahead to the question of whether character classes would continue to occupy the same namespace as rules (as they do now) or if they become specialized kinds of rules or what. I'll just leave it at this for now and see what the rest of p6l thinks. Pm
Re: disassemble segfaults
From: Leopold Toetsch [EMAIL PROTECTED] Date: Wed, 04 May 2005 09:38:41 +0200 Bob Rogers wrote: . . . but I can't figure out why. I thought the patch below would help, but it appears that the value of c is itself broken somehow. The memory handling was broken and disassemble didn't know how to handle PMC constants. Fixed - rev 7971. Thanks for testing, leo I'm sorry, but I'm still seeing the same syndrome in r8070, segfaulting in the same place, though now for only a subset of *.pbc files . . . -- Bob [EMAIL PROTECTED] ./disassemble ./runtime/parrot/library/dumper.pbc Segmentation fault [EMAIL PROTECTED] for file in `find . -name '*.pbc'`; do if [ 0 == `./disassemble $file | wc -l` ]; then echo $file; fi; done ./runtime/parrot/library/Data/Dumper/Base.pbc ./runtime/parrot/library/Data/Sort.pbc ./runtime/parrot/library/Stream/Combiner.pbc ./runtime/parrot/library/Stream/Writer.pbc ./runtime/parrot/library/Stream/ParrotIO.pbc ./runtime/parrot/library/Stream/Lines.pbc ./runtime/parrot/library/Stream/Filter.pbc ./runtime/parrot/library/Stream/Replay.pbc ./runtime/parrot/library/Stream/Coroutine.pbc ./runtime/parrot/library/dumper.pbc [EMAIL PROTECTED]
Mailing list indexing project
I'm working on an annotated version of the mailing list so that old postings can be more easily researched. My very primitive implementation is: http://www.ajs.com/~ajs/cgi-bin/p6l-index.cgi The input datafile is: http://www.ajs.com/~ajs/p6l.dat I'm using Google Groups as a back-end of sorts (all of the links go to them for content). Does anyone have any thoughts on how best to proceed? Anyone want to host this thing once it's ready? Indexing is, as always, a massive undertaking, but I figure someone needs to do it. Well, I have to get up at 5, so goodnight all!
rules trouble
I'm working on more p6rules unit tests.
Having some trouble. First, understanding when :w means \s* and when it
means \s+
Also, these tests are failing when I use :: to separate the modifier
from the pattern. But they work when I do ':w blah' (separate with a
space). I'm not sure which ways are right.
The actual failing tests:
my $targ = qq{ foobar
baz quux
zot\tfum};
p6rule_is ($targ, ':w::baz quux', 'baz\s+quux or baz\s*quux matches');
p6rule_is ($targ, ':w::zot fum', 'zot\s+fum or zot\s*fum matches');
-Dino
--
.~.Dino Morelli
/V\email: [EMAIL PROTECTED]
/( )\ weblog: http://categorically.net/d/blog/
^^-^^ preferred distro: Debian GNU/Linux http://www.debian.org
