On Sat, May 10, 2008 at 08:22:53PM -0700, Will Coleda wrote:
> This make file isn't preprocessed like the standard root.in: it
> assumes perl is in your path, and redefines the list of OPSFILES.
>
> Let's move the step into the core makefile, and add another
> --maintainer tweak like the one for
# New Ticket Created by Will Coleda
# Please include the string: [perl #53976]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53976 >
This make file isn't preprocessed like the standard root.in: it
assumes perl is in your p
Brandon S. Allbery KF8NH allbery-at-ece.cmu.edu |Perl 6| wrote:
On 2008 May 10, at 21:46, John M. Dlugosz wrote:
In S06, what is the difference between "is ref" and "is rw"? The
text says that the rw may be converted to an lvalue, and that ref
must already be. But what is that supposed to m
On Sat, May 10, 2008 at 09:51:26PM -0400, Brandon S. Allbery KF8NH wrote:
>
> On 2008 May 10, at 21:46, John M. Dlugosz wrote:
>
>> In S06, what is the difference between "is ref" and "is rw"? The text
>> says that the rw may be converted to an lvalue, and that ref must already
>> be. But what
On Sun, May 11, 2008 at 01:46:57AM -, John M. Dlugosz wrote:
: In S06, what is the difference between "is ref" and "is rw"? The text says
that the rw may be converted to an lvalue, and that ref must already be. But
what is that supposed to mean?
Mostly that means that rw will cause autov
On 2008 May 10, at 21:46, John M. Dlugosz wrote:
In S06, what is the difference between "is ref" and "is rw"? The
text says that the rw may be converted to an lvalue, and that ref
must already be. But what is that supposed to mean?
At a guess, "is rw" makes a parameter variable into a l
In S06, what is the difference between "is ref" and "is rw"? The text says
that the rw may be converted to an lvalue, and that ref must already be. But
what is that supposed to mean?
--John
On Saturday 10 May 2008 08:15:01 NotFound wrote:
> The attached patch makes explicit the assumptions about non-nullness
> in parrot_mark_hash and asserts them.
Thanks, applied as r27432.
Ideally this is unnecessary, but if it helps clear up other GC bugs, we can
fix their hash marking as well.
Thanks, applied as r27430.
Thanks, applied with a couple of tweaks as r27429.
Thanks, applied as r27428.
Thanks, applied in r27427.
Thanks, applied as r27426.
I tried this patch, and I'm getting warnings:
Generating runtime/parrot/include...Use of uninitialized value in hash
element at config/gen/parrot_include.pm line 105, <$fh> line 32.
Use of uninitialized value in pattern match (m//) at
config/gen/parrot_include.pm line 105, <$fh> line 32.
.
On Sat, May 10, 2008 at 02:37:19PM -0700, chromatic via RT wrote:
> On Saturday 10 May 2008 14:19:30 Patrick R.Michaud wrote:
> > I vote we deprecate remove Super entirely, since there doesn't
> > appear to anything using it. PDD15 defines other methods to
> > do what the Super PMC was intended to
On Saturday 10 May 2008 14:19:30 Patrick R.Michaud wrote:
> While scanning through RT tickets I noticed RT#41557, which
> involved some changes to the 'Super' PMC. However, PDD15
> has since superceded much of the object implementation, and
> a quick 'ack "Super"' on the repository shows that the
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #53968]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53968 >
While scanning through RT tickets I noticed RT#41557, which
involved some changes
# New Ticket Created by Stephane Payrard
# Please include the string: [perl #53956]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53956 >
The copy opcode is described as :
=item B(inout PMC, invar PMC)
Morphs the
There will always be a few situations where it's not possible to throw a
real exception (because there's no interpreter argument, or it's an
error within the exception subsystem, etc.). So, we need to keep one
simple fatal error sub around. I replaced 'internal_exception' with
'exit_fatal' in the p
The attached patch makes explicit the assumptions about non-nullness
in parrot_mark_hash and asserts them.
--
Salu2
Index: src/hash.c
===
--- src/hash.c (revisión: 27411)
+++ src/hash.c (copia de trabajo)
@@ -299,6 +299,7 @@
=item
chromatic wrote:
[...]
These are the headerizer changes that bother me the most.
Reverted in r27414.
Allison
On Sat, May 10, 2008 at 09:43:38AM +0100, Nicholas Clark wrote:
> On Fri, May 09, 2008 at 06:47:12PM -0500, Patrick R. Michaud wrote:
> > On Thu, May 08, 2008 at 11:28:36AM -0700, Moritz Lenz wrote:
> > > > my @a, @b; say @a
> > > Scope not found for PAST::Var '@b'
> >
> > Rakudo has this one cor
Patrick R. Michaud pmichaud-at-pobox.com |Perl 6| wrote:
Reasonable to expect it, yes -- but whether or not this rises to the
level of being a "requirement in the spec" may be a different matter.
I could envision the possibility that some otherwise-very-capable
Perl 6 implementation might be bet
Patrick (>), Carl (>>), Patrick (>>>):
>> > But yes, I expect that it will be caught as
>> > a compile-time error.
>>
>> And do you agree it's reasonable to expect this of every compiler?
>
> Reasonable to expect it, yes -- but whether or not this rises to the
> level of being a "requirement in th
On Fri, May 09, 2008 at 06:47:12PM -0500, Patrick R. Michaud wrote:
> On Thu, May 08, 2008 at 11:28:36AM -0700, Moritz Lenz wrote:
> > Rakudo as of r27393 can't handle multiple declarations in a single "my":
> >
> > > my (@a, @b); say @a
> > Scope not found for PAST::Var '@a'
>
> We'll work on t
25 matches
Mail list logo
