-01-29#i_15750058
It works as expected, with Junction type affecting the `where` check. You
can achieve what you want by threading through a block inside a where:
https://irclog.perlgeek.de/perl6/2018-01-29#i_15750022
> Now, removing Mu, just because :). When used with none, a strange warning
> mes
-01-29#i_15750058
It works as expected, with Junction type affecting the `where` check. You
can achieve what you want by threading through a block inside a where:
https://irclog.perlgeek.de/perl6/2018-01-29#i_15750022
> Now, removing Mu, just because :). When used with none, a strange warning
> mes
x/3/, rx/2/))
in sub search at line 1
in block at line 1
> my Regex @rxs = (rx/3/, rx/2/); my @L = (1 .. 23); sub search(Mu $r where
Regex) { grep $r, :v, @L }; say search( none(@rxs) );
Died with X::TypeCheck::Binding::Parameter
in sub search at line 1
in block at line 1
>
`
N
s a bit across releases:
¦2015.12,2016.01.1,2016.02,2016.03,2016.04,2016.05,2016.06,2016.07.1,2016.08.1,2016.09,2017.09,HEAD(b6982e6):
«Lower»
¦2016.10,2016.11,2016.12,2017.02,2017.03,2017.04.3,2017.05,2017.06,2017.07,2017.08:
«ALetter»
¦2017.01: «None»
Explanation by samcv++:
ht
Of course there should have been a "," between (list) and $othervar.
But perl5 won't accept
for $var (list) $othervar (anotherlist) { ... }
right?
So we definitely shouldn't complain, or at least we should point out the
workaround of putting a dot between $var and (list)
On 30/03/17 03:51, Brandon Allbery wrote:
> That *is* Perl 5 syntax, though; it looks li
That *is* Perl 5 syntax, though; it looks like the schema
for $var (list) { ... } # the space is not required between the var and
the parenthesized list
On Wed, Mar 29, 2017 at 9:35 PM, Aleks-Daniel Jakimenko-Aleksejev <
perl6-bugs-follo...@perl.org> wrote:
> # New Ticket Created by Aleks-
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #131076]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131076 >
Code:
my $x = *²; for $x(42), $x(50) { say $_ }
Result:
===SORRY!===
On Tue, 27 Dec 2016 11:02:17 -0800, c...@zoffix.com wrote:
> In this code, I would've expected the second multi to be used, since
> I'm not providing
> any named args. I'm fuzzy on whether named params affect multi
> dispatch, but even if they
> wouldn't the multi without any named params is later
On Tue, 10 May 2016 14:27:20 -0700, sml...@gmail.com wrote:
> It may have to do with their signature (as reported by the
> `.signature` introspection method):
They're actually special-cased in the grammar[^1] based on their name:
https://github.com/rakudo/rakudo/blob/4570238de7260b7360333aa216bb
I messed up the end of the ticket, should read:
Yet it still works like in the first case, if we turn off the
optimizer:
$ perl6 --optimize=off test.p6
there
Or give a name to the parameter:
$ cat test.p6
multi foo($, :$) { say "there"; }
multi foo($x ) { foo $x, $; }
# New Ticket Created by Zoffix Znet
# Please include the string: [perl #130415]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130415 >
In this code, I would've expected the second multi to be used, since I'm not
providing
an
On Sat, Jan 08, 2011 at 02:59:38PM -0800, Carl Mäsak wrote:
> rakudo: my &r = &return; sub f { &return := -> $v { say
> "LOL!"; &r($v) }; return(42) }; say f [23:45]
> rakudo e7e9d5:
> OUTPUT«LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!LOL!
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #81982]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=81982 >
rakudo: my &r = &return; sub f { &return := -> $v { say
"LOL!"; &r($v) }; return(42) };
On Wed Jun 09 05:12:54 2010, masak wrote:
> well, it was $_, so just .all works
> ooh!
> rakudo: .all
> rakudo 34c1ba: OUTPUT«Method 'all' not found for invocant of
> class '' [...]
> * masak submits rakudobug
> What type is .all supposed to be defined on?
> Any -> List
> Ah, then it is a ra
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #75626]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=75626 >
well, it was $_, so just .all works
ooh!
rakudo: .all
rakudo 34c1ba: OUTPUT«Method '
you never want to use negative comparison operators
and junctions together. They don't do what you think. Use prefix "not"
instead:
$ ./perl6 -e 'my @a = ; my @b = ; say @a.grep: { not $_
eq any(@b) }'
ac
>> my @a = ; my @b = ; say @a.grep: { $_ eq none(@b) };
> a
Hi there,
> my @a = ; my @b = ; say @a.grep: { $_ eq any(@b) };
bd
> my @a = ; my @b = ; say @a.grep: { $_ ne any(@b) };
abcd
hm. I expect: ac
But Rakudo and PUGS both return abcd. May by I missed something?
> my @a = ; my @b = ; say @a.grep: { $_ eq none(@b) };
ac
> my @a = ; m
Patrick R. Michaud wrote:
In most other places in Parrot at the moment, fetching a nonexisting
key from a hash-like object returns a null PMC, and fetching a nonexisting
element from an array-like object returns Undef.
So, I'd be in favor of changing the above TODO to read "return null
for none
bject line of all future correspondence about this issue.
># http://rt.perl.org/rt3/Ticket/Display.html?id=46391 >
>
>In src/dynpmc/gdbmhash.c there is the todo item:
>
>TODO: return None PMC for nonexisting keys.
>
>This is relevant when fetching keys, and ne
Ticket/Display.html?id=46391 >
In src/dynpmc/gdbmhash.c there is the todo item:
TODO: return None PMC for nonexisting keys.
This is relevant when fetching keys, and needs to be implemented.
Maybe not; see "None Must Die" [perl #40178] . . .
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46391]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46391 >
In src/dynpmc/gdbmhash.c there is the todo item:
TODO: return None PMC
Chip Salzenberg wrote:
How about a 'default' opcode that provides a value instead of null? It
would work for strings and PMCs. Something like:
$S0 = default hsh['key'], ''
or
$P0 = new .Undef
...
$P1 = default hsh['key1'], $P0
$P1 = default hsh['key2'], $P0
..
{ not replying to the ticket }
On Fri, Aug 18, 2006 at 01:10:07AM +0200, Leopold Toetsch wrote:
> Am Donnerstag, 17. August 2006 08:24 schrieb Chip Salzenberg:
> > The None class serves no useful (portable) purpose and it should be
> > removed, especially from the public in
Am Donnerstag, 17. August 2006 08:24 schrieb Chip Salzenberg:
> The None class serves no useful (portable) purpose and it should be
> removed, especially from the public interface of Hash.
This ticket could be closed, but replying to rt would reopen it - please check
subjects and recipie
Am Donnerstag, 17. August 2006 08:24 schrieb Chip Salzenberg:
> The None class serves no useful (portable) purpose and it should be
> removed, especially from the public interface of Hash.
... and the None class is gone.
As mentioned:
$S0 = hsh['no_such_key']
is unchanged and
On Fri, Aug 18, 2006 at 12:17:58AM +0200, Leopold Toetsch wrote:
> A lot of src/string string_ operations are capable of dealing with NULL
> strings currently [1]. *But* that's AFAIK specificied nowhere, and might just
> be an accident, i.e. an extra (unneeded/unwanted) check for A NULL argument.
Am Donnerstag, 17. August 2006 21:55 schrieb Chip Salzenberg:
> > $S0 = hsh['key']
> >
> > with
> >
> > $S0 = hsh['key']
> > unless null $S0 goto label
> > $S0 = ''
> > label:
>
> Indeed. I think we can reduce the pain of dealing with this to the point
> where you'll hardly feel
Am Donnerstag, 17. August 2006 21:50 schrieb Chip Salzenberg:
> > Folks, please check your usage of testing for existing hash keys.
>
> Well, we (core hackers) changing the interface out from underneath them, so
> if their code breaks, we should fix it up, if we can. Code outside the svn
> tree (e
On 8/17/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
There might be a cognitive dissonance here with "err", since
C in pasm/pir is testing for null, while C in
perl6 tests for definedness. While it doesn't much matter
for strings in the examples above, it might make a difference for
$
On Thu, Aug 17, 2006 at 01:11:00PM -0700, jerry gay wrote:
> On 8/17/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > $S0 = default hsh['key'], ''
> >[...]
> > $P0 = new .Undef
> > $P1 = default hsh['key1'], $P0
> > $P1 = default hsh['key2'], $P0
> > ...
> >
> >It would work w
On Thu, Aug 17, 2006 at 12:55:54PM -0700, Chip Salzenberg wrote:
> {DESIGNER ALERT - Allison, what think?}
>
> On Thu, Aug 17, 2006 at 12:31:11PM -0700, Patrick R. Michaud via RT wrote:
> > I rely on the "return empty string" behavior. In particular, changing it
> > to return NULL will mean in ma
On 8/17/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
How about a 'default' opcode that provides a value instead of null? It
would work for strings and PMCs. Something like:
$S0 = default hsh['key'], ''
or
$P0 = new .Undef
...
$P1 = default hsh['key1'], $P0
$P1 = d
{DESIGNER ALERT - Allison, what think?}
On Thu, Aug 17, 2006 at 12:31:11PM -0700, Patrick R. Michaud via RT wrote:
> I rely on the "return empty string" behavior. In particular, changing it
> to return NULL will mean in many places that I will have to replace
> single-line key lookups
>
> $S
On Thu, Aug 17, 2006 at 12:13:30PM -0700, Leopold Toetsch via RT wrote:
> Am Donnerstag, 17. August 2006 08:24 schrieb Chip Salzenberg:
> > The None class serves no useful (portable) purpose and it should be
> > removed, especially from the public interface of Hash.
>
> I&#
On Thu, Aug 17, 2006 at 09:12:07PM +0200, Leopold Toetsch wrote:
> A releated change:
>
> $S0 = hsh['no_such_key']
>
> used to return an empty STRING*, it'll soon return a NULL STRING*.
Just a note (to copy from irc #parrot) -- this will cause a number
of things in PGE and perl6 to break, as
Am Donnerstag, 17. August 2006 08:24 schrieb Chip Salzenberg:
>
> The None class serves no useful (portable) purpose and it should be
> removed, especially from the public interface of Hash.
I've started fixing that. I'll do that in small steps, as there are some build
and te
# New Ticket Created by Chip Salzenberg
# Please include the string: [perl #40179]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40179 >
The None class serves no useful (portable) purpose and it should be remo
# New Ticket Created by Chip Salzenberg
# Please include the string: [perl #40178]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40178 >
The None class serves no useful (portable) purpose and it should be remo
previously, the get_string method of the .None PMC returned "None".
it's been modified to return the somewhat more sane "", or empty
string. this may affect code using .Hash PMCs, as the get_string
method of the .None PMC is called when the value of a non-existant
hash k
On Sun, Jun 12, 2005 at 12:52:03AM -0400, William Coleda wrote:
> open currently returns an Undef PMC if it fails to open a file. Should it
> instead return a None? Or, IMO, a Null?
Undef PMC ... or more precisely, any old PMC value that is not
defined() ... seems the most useful return
open currently returns an Undef PMC if it fails to open a file. Should it
instead return a None? Or, IMO, a Null?
Someone should probably do a cleanup in the core on None vs. Undef vs. Null to
insure they are used consistently and appropriately.
FWIW, it also seems unfair (or at least
Andy Dougherty (via RT) wrote:
In a release tarball, the .svn directories don't exist, so
config/gen/revision.pl can't find the svn revision number. That's fine,
but it's probably wiser in that case to not report "failed" during the
Configure.pl process, but to simply skip over the missing numbe
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #35361]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=35361 >
In a release tarball, the .svn directories don't exist, so
config/gen/revision.pl ca
Thomas Sandlaà writes:
> Luke Palmer wrote:
>
> >But I counter that arguability by saying that you really shouldn't be
> >putting one() in type signatures. If you want something to be an A or a
> >B, and you're not doing any checking later on in the code, then it's
> >fine if it's both A and B.
Luke Palmer wrote:
But I counter that arguability by saying that you really shouldn't be
putting one() in type signatures. If you want something to be an A or a
B, and you're not doing any checking later on in the code, then it's
fine if it's both A and B. If you are doing checking later on, then
. People complain about a lot of things.
That's why I'm here: to comfort people out of their complaints, and to
replace them with my own. :-)
> >I definitely like the symmetry. But we have to remember that the P in
> >Perl (can) stand for Practical. The advantages of
and they aid learning. But they aren't nearly as
important as semantic symmetry/consistency. (Not to say that they
aren't important)
The lack of infix ops to go with the none junction has worried others
before me. Unfortunately I don't find the thread were Larry rambles
about this.
low. I've found a posting of Damian where he
> opposes the usage of binary '!' and '!!' because it looks too negative.
> Is there another grammar reason why there is no single character list op
> for the none junction?
Yeah. Because it doesn't exist in English,
#x27; because it looks too negative.
Is there another grammar reason why there is no single character list op
for the none junction?
Another unanswered question is: how often is the ref operator needed
in Perl6?
eval | value | | bitwise ops
rhs if | returning |
On Fri, Feb 11, 2005 at 07:45:33PM +0100, Thomas Sandlaï wrote:
> Autrijus Tang wrote:
> >as well as the non-short-circuitting "!!" logical operator, and the
> >lower-precedenced "nor".
>
> I'm not sure if '!' fits the heavy weight perl6 grammar. But why is
> 'nor' not short-circuitting? It only c
Autrijus Tang wrote:
as well as the non-short-circuitting "!!" logical operator, and the
lower-precedenced "nor".
I'm not sure if '!' fits the heavy weight perl6 grammar. But why is
'nor' not short-circuitting? It only continues when the left side is
true --- like '||' and '//'. At least this is wh
1|2|3; # any
> my $x = 1^2^3; # one
> my $x = 1&2&3; # all
> my $x = 1\2\3; # none
That's quite nice, but I've been kind of wanting to go the other way.
You know, not every operation in Perl 6 needs to have a punctuation
operator.
I think we should no
On Fri, Feb 11, 2005 at 06:48:29PM +0100, Thomas Sandlaï wrote:
> Accepting the above completes the junction constructing operators:
>
> my $x = 1|2|3; # any
> my $x = 1^2^3; # one
> my $x = 1&2&3; # all
> my $x = 1\2\3; # none
Pugs currently impl
Thomas Sandlaß wrote:
my $x = 1|2|3; # any
my $x = 1^2^3; # one
my $x = 1&2&3; # all
my $x = 1\2\3; # none
[...]
if $a && $b { ... } # and
if $a || $b { ... } # or
if $a ^^ $b { ... } # xor
if $a // $b { ... } # err
if $a \\ $b { ... } # nor
Well?
that&
()?
my $x = \* (1,2,3); # also without ()?
Accepting the above completes the junction constructing operators:
my $x = 1|2|3; # any
my $x = 1^2^3; # one
my $x = 1&2&3; # all
my $x = 1\2\3; # none
The rational behind the none delimeter is that 'none(a,b,c)' is
On Wednesday 02 July 2003 00:25, Adrian Howard wrote:
> On Monday, June 30, 2003, at 02:07 pm, Fergal Daly wrote:
> The footer doesn't indicates that the correct number of tests ran
> (that's the plan's job), it just shows that a test script completed
> without error.
I think that would be usef
On Monday, June 30, 2003, at 02:07 pm, Fergal Daly wrote:
On Wednesday 25 June 2003 20:15, Adrian Howard wrote:
Add an explicit "test script finished" footer?
But how does the footer-adder know that the correct number of tests
ran. You
would need to declare a plan to run x additional extensions
On Wednesday 25 June 2003 20:15, Adrian Howard wrote:
> Add an explicit "test script finished" footer?
But how does the footer-adder know that the correct number of tests ran. You
would need to declare a plan to run x additional extensions at which point
you're doing sub-plans.
I suppose I'm th
NIFEST. Perhaps a README. There is no
.pm files for the CPAN indexer to pick up on. search.cpan.org shouldn't
even pick up on it. The only way a user could find that tarball is to
manually download it from CPAN. Its just a hollow dummy. There's no other
reason someone would downloa
On Sat, Jun 28, 2003 at 10:13:06PM +0100, Fergal Daly wrote:
> Is there a way to
> know if Makefile.PL is being run by CPAN.pm?
Not as far as I know, but Jos tells me that there should be some way in
the next version of CPANPLUS.
My person
On Saturday 28 June 2003 02:51, Michael G Schwern wrote:
> When I merged Test::Simple with Test::More I left a Test-More tarball lying
> around containing a Makefile.PL which simply died saying "download
> Test-Simple instead".
That's OK for a merge (or you could have an empty archive with a depen
On Tue, Jun 24, 2003 at 08:39:39PM +0100, Fergal Daly wrote:
> Test::NoWarnings sounds good to me. What is the correct etiquette for
> abandoning a namespace? Just delete the files with PAUSE or should I leave a
> pointer behind? Not too important with this module but I'm just curious,
When I me
On Wed, Jun 25, 2003 at 07:09:26PM +0100, Fergal Daly wrote:
> I just thought of a big problem with plan extensions. If the script silently
> eat's itself just before you extend the plan, then you don't know that
> anything went wrong.
It would have to also exit normally. That is rare.
--
Is
Hiya,
On Wednesday, June 25, 2003, at 07:09 pm, Fergal Daly wrote:
On Wednesday 25 June 2003 17:49, Adrian Howard wrote:
The thread from the start of May about having optional / extendable
plans supported by Test::Harness would seem to be a good match for
this
feature.
http://archive.d
3.html (Plan is
> YAGNI)
>
> Test::Warn::None could then just extend the plan in the END block with
> no worries about mucking up existing plans.
I forgot about that stuff.
I just thought of a big problem with plan extensions. If the script silently
eat's itself just before you exte
On Tuesday, June 24, 2003, at 07:53 pm, Michael G Schwern wrote:
On Tue, Jun 24, 2003 at 12:07:19PM +0100, Fergal Daly wrote:
Consider the following.
use Test::More;
use Test::Warn::None;
plan tests => 42;
To make this work I'd have to overhaul the internal Test::Builder
rn() vs diag() vs print STDERR).
>
> Besides, Test::Harness can't portably trap STDERR. If you can figure out
> a way to do it that would solve lots of problems.
>
> If you want to do it to a whole test suite, PERL5OPT=-MTest::Warn::None comes
> to mind.
Provided
Michael G Schwern wrote in perl.qa :
> On Tue, Jun 24, 2003 at 01:36:52PM +0200, Rafael Garcia-Suarez wrote:
>> BTW, what about modules that define their own category of warnings
>> (via warnings::register) ? It'd be useful to have a module to ease
>> testing for warnings presence/absence on certai
ap STDERR. If you can figure out
a way to do it that would solve lots of problems.
If you want to do it to a whole test suite, PERL5OPT=-MTest::Warn::None comes
to mind.
--
"Congratulations, you're a thieving bastard... Now give me back my pants."
"That's MISTER Pants!&quo
On Tue, Jun 24, 2003 at 01:36:52PM +0200, Rafael Garcia-Suarez wrote:
> BTW, what about modules that define their own category of warnings
> (via warnings::register) ? It'd be useful to have a module to ease
> testing for warnings presence/absence on certain conditions.
There's Test::Warn, but I d
On Tue, Jun 24, 2003 at 12:07:19PM +0100, Fergal Daly wrote:
> > Consider the following.
> >
> > use Test::More;
> > use Test::Warn::None;
> > plan tests => 42;
> >
> > To make this work I'd have to overhaul the internal Test::Builde
On Tue, Jun 24, 2003 at 12:37:36PM +0100, Fergal Daly wrote:
> Also how about calling it Test::Warn::Auto? I'm not particularly happy with
> None,
Test::Warn::Auto doesn't say anything about its main purpose: to ensure
that you have no warnings. Instead it documents an imple
On Tuesday 24 June 2003 20:31, Michael G Schwern wrote:
> If you want to do it to a whole test suite, PERL5OPT=-MTest::Warn::None
comes
> to mind.
That's cool, I never saw that before.
It's also a pretty convincing argument for an "I'm going to add an extra test"
method in Test::Builder,
F
On Tuesday 24 June 2003 19:55, Michael G Schwern wrote:
> I like Test::Warn::None or some variation on it. Or even Test::NoWarnings.
> Doesn't have to sit in the Test::Warn namespace.
Test::NoWarnings sounds good to me. What is the correct etiquette for
abandoning a namespace? Just
On Tuesday 24 June 2003 20:04, Andy Lester wrote:
> All this "make sure no warnings fired" is good thinking. But why not
> roll it into Test::Harness, and make it switch selectable? It's
> really T::H that we want keeping an eye on this, right?
Possibly...
...except how does Test::Harness know
All this "make sure no warnings fired" is good thinking. But why not
roll it into Test::Harness, and make it switch selectable? It's
really T::H that we want keeping an eye on this, right?
xoa
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
On Tuesday 24 June 2003 19:56, Michael G Schwern wrote:
> I don't quite understsand what "spanning perl interpreters" means.
Neither did I until just now. I think it's the fact that forks will cause the
END to run multiple times. It would be nice if Test::Builder gave a method to
give us access
On Tuesday 24 June 2003 12:36, Rafael Garcia-Suarez wrote:
> +1 for ::Auto.
>
> BTW, what about modules that define their own category of warnings
> (via warnings::register) ? It'd be useful to have a module to ease
> testing for warnings presence/absence on certain conditions.
> (Avoiding to span
Fergal Daly wrote:
>
> Also how about calling it Test::Warn::Auto? I'm not particularly happy with
> None,
+1 for ::Auto.
BTW, what about modules that define their own category of warnings
(via warnings::register) ? It'd be useful to have a module to ease
testing for warnin
x27;m not particularly happy with
None,
F
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 24-Jun-03 Fergal Daly carved into stone:
> On Tuesday 24 June 2003 11:37, Tels wrote:
>> Actually, I can see that Test::Warn::None could make the no_warnings()
>> line
>> obsolete by calling this automatically in an END block. So
On Tuesday 24 June 2003 11:22, Michael G Schwern wrote:
> > >> use Test::More::None;
>
> Typo?
Yeso.
> >
> > Can't nowarings() call Test::More::plan_add(1) or something like this?
> >
>
> Consider the following.
>
> use Test::Mor
On Tuesday 24 June 2003 11:37, Tels wrote:
> Actually, I can see that Test::Warn::None could make the no_warnings() line
> obsolete by calling this automatically in an END block. So:
It IS obsolete. I DOES call it from an END block ;-)
F
on hackery necesssary. :(
>>
>>
>> Can't nowarings() call Test::More::plan_add(1) or something like this?
>>
>
> Consider the following.
>
> use Test::More;
> use Test::Warn::None;
> plan tests => 42;
>
> To make this work I'd have
your test
> >> script didn't emit any warnings. Just add
> >>
> >> use Test::More::None;
Typo?
> >> to the top your test script, update your plan (if you've got one) and
> >> that's
> >> it. You'll get an extra test, exe
Test::Warn. It tests that your test
>> script didn't emit any warnings. Just add
>>
>> use Test::More::None;
>>
>> to the top your test script, update your plan (if you've got one) and
>> that's
>> it. You'll get an extra test, exec
On Mon, Jun 23, 2003 at 05:49:06PM +0100, Fergal Daly wrote:
> I'm looking for comment or suggestions about this new module. It's
> independent of and complementary to Test::Warn. It tests that your test
> script didn't emit any warnings. Just add
>
> use Tes
Hi,
I'm looking for comment or suggestions about this new module. It's
independent of and complementary to Test::Warn. It tests that your test
script didn't emit any warnings. Just add
use Test::More::None;
to the top your test script, update your plan (if you've
Ashley Winters <[EMAIL PROTECTED]> writes:
>> Patches welcome.
>
> Excellent...
>
> Forgive any formatting errors, I have mail issues.
Thanks, applying. With a few caveats.
> @@ -62,6 +62,7 @@
> class SchemePair is SchemeExpr {
>my $nil //= class is SchemeExpr {
> method is_nil {1}
>
90 matches
Mail list logo
