On Friday 20 June 2008 10:53:55 Andrew Johnson wrote:
> I'm concluding that these warnings are due to incorrect casting inside of
> packfile.c.
>
> In both cases, the code generating the warnings looks like this:
>
> munmap(PARROT_const_cast(opcode_t *, pf->src), pf->size);
>
> pf->src is
# New Ticket Created by James Keenan
# Please include the string: [perl #56178]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56178 >
Upgrading to the latest CPAN version of Perl::Critic breaks t/
codingstd/perlcritic.t:
Lara:
I was unable to reproduce the test failure you encountered at the YAPC
Parrot build fest. So I'm somewhat groping in the dark as to a
solution. However, I looked at the test and figured that it would
benefit from some simplification.
Can you re-run 'perl Configure.pl', apply the patch at
On Sat May 10 20:22:53 2008, coke 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 me pose some questions:
1. Who actually uses this program? Under what circumstances?
2. Must exist this program as
On Sat, Jun 21, 2008 at 9:03 AM, via RT James Keenan
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by James Keenan
> # Please include the string: [perl #56178]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=56178 >
>
>
Mark: Do you have any objection to closing this RT?
Thanks.
kid51
Looking at Bruce's report more carefully, I don't see anything that we
would consider a real bug. The warnings displayed don't prevent 'make'
from reaching a successful conclusion. We've dealt with the test that
unexpectedly succeeded in another ticket.
So I'm resolving this ticket.
kid51
On Saturday 21 June 2008 07:16:58 James Keenan via RT wrote:
> On Sat May 10 20:22:53 2008, coke 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 me pose some questions:
>
> 1. Who actually use
From: chromatic <[EMAIL PROTECTED]>
Date: Sat, 21 Jun 2008 10:40:29 -0700
On Saturday 21 June 2008 07:16:58 James Keenan via RT wrote:
. . .
> (b) pull the '--renum' option out of tools/build/ops2pm.pl;
>
> (c) replace tools/dev/ops_renum.mak with a pure Perl program which d
On Fri Jun 20 09:01:56 2008, [EMAIL PROTECTED] wrote:
> prove -v t/codingstd/perlcritic.t
> t/codingstd/perlcritic..Undefined subroutine
>
&Perl::Critic::Policy::NamingConventions::ProhibitAmbiguousNames::default_forbidden_words
> called at t/codingstd/perlcritic.t line 142.
> Dubious, test r
# New Ticket Created by Will Coleda
# Please include the string: [perl #56166]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56166 >
Sending this to parrotbug to open a ticket...
On Wed, Jun 18, 2008 at 2:00 PM, Ovid
<[EM
On Fri Jun 20 09:01:56 2008, [EMAIL PROTECTED] wrote:
> prove -v t/codingstd/perlcritic.t
> t/codingstd/perlcritic..Undefined subroutine
>
&Perl::Critic::Policy::NamingConventions::ProhibitAmbiguousNames::default_forbidden_words
> called at t/codingstd/perlcritic.t line 142.
> Dubious, test r
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #56184]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56184 >
Parrot seems to have a problem with lexical handling. Consider
the following Perl
Applied in r28597, thanks!
Pm
On Thursday 19 June 2008 15:09:53 NotFound via RT wrote:
> Another try. Builds and pass tests both with C and C++.
I wish it were cleaner, but I can live with this for now to get C++ building
again.
Thanks, applied as r28602.
-- c
I think we need a slight wording improvement in S03. Currently S03:1772
says that the C contextualizer is equivalent to C<@()>.
However, S05:2328 also says that C<@()> is a shorthand for C<@($/)>.
Taken together, these would seem to imply that C is equivalent
to C<@($/)>, which I suspect is not
Applied in r28599, thanks!
Pm
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #56186]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56186 >
Jonathan says that it's possible to generate and save
bytecode within PIR -- see l
C and being zero width assertions , I think they must
always be called with
a question mark. This is not the case line 394 and 1537.
Perljam suggested that a zero width assertion can be also a capturing
one and that
could explain the dropping of the question mark. I don't agree with
that suggesti
Author: larry
Date: Sat Jun 21 17:43:15 2008
New Revision: 14555
Modified:
doc/trunk/design/syn/S05.pod
Log:
clarifications requested by cognominal++
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn
On Sat, Jun 21, 2008 at 01:59:28PM -0700, cognominal wrote:
: C and being zero width assertions , I think they must
: always be called with
: a question mark. This is not the case line 394 and 1537.
: Perljam suggested that a zero width assertion can be also a capturing
: one and that
: could exp
On Sat, Jun 21, 2008 at 1:40 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Saturday 21 June 2008 07:16:58 James Keenan via RT wrote:
>
>> On Sat May 10 20:22:53 2008, coke wrote:
>> > This make file isn't preprocessed like the standard root.in: it
>> > assumes perl is in your path, and redefines th
Author: larry
Date: Sat Jun 21 18:28:14 2008
New Revision: 14556
Modified:
doc/trunk/design/syn/S03.pod
Log:
clarifications requested by pmichaud++
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S
Resolved per discussion with Infinoid.
24 matches
Mail list logo
