If I've got this right:
mangle $foo :a;# mangle($foo, a => 1);
mangle $foo: a;# $foo.mangle(a());
So these --
mangle $foo:a;
mangle $foo : a;
are ambiguous and, as far as I can tell from the synopses, undefined. So
what's the rule: that indirect-object colon needs whitespace after but
Visually, I interpret ":a" as a token unto itself, though that's
probably Ruby's fault. That interpretation would man that the
dual-whitespace version would have to be an indirect object.
I would argue for disallowing the all-jammed-together case, lest we
run into longest-match arguments where "f
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #46213]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46213 >
hi,
while converting lang/PIR into the new Perl6Grammar syntax, I came across
the fol
On 10/7/07, Mark J. Reed <[EMAIL PROTECTED]> wrote:
> I would argue for disallowing the all-jammed-together case, lest we
> run into longest-match arguments where "foobar:baz" is "foobar: baz"
> but "foo:barbaz" is "foo :barbaz". Yuck.
Uh, that doesn't make sense. Longest match arguments are lef
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46221]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46221 >
Coverity Prevent has managed to throw up some difficult-to-fix issues
in Parrot, howeve
Hi,
some days ago near #parrot:
17:13 if you get a chance, allison has modified pdd17 (pmc). i'm
reviewing it, but i think you'd be a better judge of its implications on gc,
etc.
17:14 I'll have a look at it - thx
Well, xx days after, I had a very brief look at it:
- it's mostly a summary o
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46223]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46223 >
Coverity Prevent mentions that the code after the C
comparison in src/pmc/pair.pmc can
On Sun, Oct 07, 2007 at 08:52:26AM -0700, Klaas-Jan Stol wrote:
> hi,
>
> while converting lang/PIR into the new Perl6Grammar syntax, I came across
> the following.
>
> token relational_operator {
> || '=='
> || '!='
> || '<='
> || '<'
> || '>'
> || '>='
> }
>
> At first,
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46225]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46225 >
In Coverity CID 22 there is a warning about potentially passing a
negative index to an
On 10/6/07, brian d foy wrote:
That looks like it might mean that these are corresponding forms:
8 => 377:8<377>:8(377)
Now, if I can do that, what happens to the pair form in a hash composer
when I want the key of '8' and the value of :10<377>?
What happened to the suggestion of us
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46227]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46227 >
This patch is brought to you by the RT command line utility because
parrotbug doesn't s
In article <[EMAIL PROTECTED]>, Moritz Lenz
<[EMAIL PROTECTED]> wrote:
> brian d foy wrote:
> > * If I can match $x to NaN (or its stand-in), what happens when $x is
> > undef?
>
> undef is a property of the container variable (that it holds no value),
> whereas NaN is a property of the content
In article <[EMAIL PROTECTED]>, Darren Duncan
<[EMAIL PROTECTED]> wrote:
> At 3:20 PM -0500 10/6/07, brian d foy wrote:
> >For comparisons, how are we going to use Inf and NaN? Are those going
> >to be special flyweight objects, so:
> >
> >$x = 1 / 0;
> >
> >$x == Inf;# is it the sa
Applied to trunk in r21956.
From: Allison Randal <[EMAIL PROTECTED]>
Date: Mon, 01 Oct 2007 15:58:24 -0700
My goal was to wrap up the pdd15oo branch by the end of September. We're
quite close. The two remaining big things are PGE and multiple dispatch,
and then test cleanup. Thanks to chromatic and particle
James E Keenan wrote:
Allison Randal wrote:
So, how about we make both --fatal-step and --verbose-step accept
either a step number or step name.
Didn't I hear someone recently remark, "Simplification is a good idea"?
;-)
This is doable, but it will take me at least 9 separate test files
chromatic wrote:
On Friday 05 October 2007 14:02:32 [EMAIL PROTECTED] wrote:
Modified: branches/pdd15oo/src/pmc/namespace.pmc
===
=== --- branches/pdd15oo/src/pmc/namespace.pmc (original)
+++ branches/pdd15oo/src/pmc/namesp
Klaas-Jan Stol wrote:
I think it should be something like this:
/* RT46099 Check we don't already have this parent. */
/* If we have already added a method with this name... */
if (VTABLE_exists_keyed_str(interp, _class->all_parents,
VTABLE_name(interp, parent))) {
18 matches
Mail list logo
