This is an automatically generated mail to inform you that tests are now
available in b/t/spec/S12-class/instantiate.t
This is an automatically generated mail to inform you that tests are now
available in b/t/spec/S04-declarations/my.t
This is an automatically generated mail to inform you that tests are now
available in b/t/spec/S03-operators/numeric-context.t
This is an automatically generated mail to inform you that tests are now
available in b/t/spec/S12-construction/construction.t
This is an automatically generated mail to inform you that tests are now
available in b/t/spec/S12-construction/BUILD.t
This is an automatically generated mail to inform you that tests are now
available in b/t/spec/S32-list/map.t
This is an automatically generated mail to inform you that tests are now
available in b/t/spec/S06-signature/errors.t
This is an automatically generated mail to inform you that tests are now
available in b/t/spec/S05-interpolation/regex-in-variable.t
This is an automatically generated mail to inform you that tests are now
available in b/t/spec/S03-operators/value_equivalence.t
This is an automatically generated mail to inform you that tests are now
available in b/t/spec/S09-subscript_slice/slice.t
This is an automatically generated mail to inform you that tests are now
available in b/t/spec/S02-builtin_data_types/nil.t
This is an automatically generated mail to inform you that tests are now
available in b/t/spec/S29-conversions/ord_and_chr.t
This is an automatically generated mail to inform you that tests are now
available in b/t/spec/S02-names_and_variables/perl.t
On Thu, Jul 16, 2009 at 4:30 PM, Moritz Lenz via
RT wrote:
> I like the idea very much, but the current implementation is a bit
> confusing. The test code dies, but dies_ok still fails. Maybe adding a
> diag($explanation) might improve that. (Maybe I get around to implement
> that, but right now I
Kyle Hasselbacher (via RT) wrote:
> Sometimes something dies, as it should, but with the wrong error. The
> best way to test this is to specify the correct error, but we don't
> always have the correct error. This patch makes dies_ok reject a
> particular Rakudo-specific error that is always inco
# New Ticket Created by "Kyle Hasselbacher"
# Please include the string: [perl #67622]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=67622 >
Sometimes something dies, as it should, but with the wrong error. The
best way t
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #67612]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=67612 >
10:28 < szabgab> rakudo: if ('abc' ~~ m/ (#) /) { say "match '$/'" }
10:28 < p6eval> rak
On Sun Mar 15 08:36:42 2009, masak wrote:
> rakudo: sub foo { return }; say foo.WHAT; say ?(foo ~~ Nil)
> rakudo 5b1ff9: OUTPUT«Nil0»
> * masak submits
>
> Expected behavior: a "Nil" and a 1. Or an explanation about why a
> value shouldn't smartmatch successfully against its own type.
Note th
--- On Thu, 7/9/09, Moritz Lenz wrote:
> . . .
> Somehow the current file test syntax, 'filename' ~~ :e, looks like a not
> well-though-out translation of Perl 5's syntax, -e 'filename'.
> Apart from totally feeling wrong to me,
Dunno about totally. I'm still trying to get a P6 mindset, but the
# New Ticket Created by Minimiscience
# Please include the string: [perl #67600]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=67600 >
Rakudo is unable to parse any of the following declarations:
my @a[5];
my @b
20 matches
Mail list logo