We've replaced Parrot::IO::Capture::Mini throughout with
IO::CaptureOutput, so I'm removing Mini.pm from the distribution and
resolving the ticket. Thanks to Alan Rocker for assistance.
I merged the 'cpu' branch into trunk in r24235. This merges
config/auto/cpu.pm into config/gen/cpu.pm, as well as merging the
various CPU-specific auto.pm classes underneath config/auto/cpu/ into
their corresponding config/gen/cpu/ classes. Additional test files were
provided. Parrot::Configure:
particle added tests in t/configure/045-generated_file_header.t for
generated_file_header(). Tests once again cover 100% of code:
http://thenceforward.net/parrot/coverage/configure-build/lib-Parrot-BuildUtil-pm.html.
Resolving ticket.
On Thu Dec 27 11:08:34 2007, rgrjr wrote:
>
> Test results on an x86_64 box for revision 24229 of
> parrot/branches/cpu/
> are shown below -- this is the same as for revision 24227 of the
> trunk.
>
> [snip]
> Failed Test
On Dec 25, 2007 4:37 PM, Allison Randal <[EMAIL PROTECTED]> wrote:
> Klaas-Jan Stol wrote:
> > I guess you're right :-) I was thinking of ambiguity, like
> >
> > sub foo :multi(Integer, Integer)
> > .param pmc i :invocant
> > .param pmc j
> > .param pmc k :invocant
> > end
> >
> > sub foo :mult
From: "James Keenan via RT" <[EMAIL PROTECTED]>
Date: Tue, 25 Dec 2007 18:06:00 -0800
. . .
svn co https://svn.perl.org/parrot/branches/cpu/
cd cpu
perl Configure.pl --test
make
make test
Thank you very much.
kid51
Test results on an x86_64 box for revision 2422
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #49135]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=49135 >
There's a probable bug in PGE with processing zero-quantified
captures. When pro
On Thu, Dec 27, 2007 at 07:56:35PM +0200, Allison Randal wrote:
> Patrick R. Michaud wrote:
> >On Thu, Dec 27, 2007 at 07:15:40PM +0200, Allison Randal wrote:
> >>With autoboxing/unboxing, there's not really a need to differentiate
> >>between the PMC Integer/String/Float types and the I/S/N regis
On Thu, Dec 27, 2007 at 07:45:03PM +0200, Allison Randal wrote:
> Patrick R. Michaud wrote:
> >On Thu, Dec 27, 2007 at 07:26:30PM +0200, Allison Randal wrote:
> >>Agreed. (It's worth noting that the problem existed before :invocant was
> >>added.) Adding :invocant, and giving it a string parameter
On Thu Dec 27 07:10:13 2007, ptc wrote:
> >
> > svn co https://svn.perl.org/parrot/branches/cpu/
> > cd cpu
> > perl Configure.pl --test
> > make
> > make test
>
> Solaris 9, Sun C 5.8:
>
> Failed TestStat Wstat Total Fail List of Failed
>
---
Patrick R. Michaud wrote:
On Thu, Dec 27, 2007 at 07:15:40PM +0200, Allison Randal wrote:
With autoboxing/unboxing, there's not really a need to differentiate
between the PMC Integer/String/Float types and the I/S/N registers.
Coming into this discussion from the middle (and having not read
pd
Allison Randal wrote:
.param pmc a :invocant(['Foo'; 'Bar'])
And this has me wondering, for languages that do strict type-checking,
will they want to be able to specify the types of non-invocant
parameters? So, maybe that should be:
.param pmc a :type(['Foo'; 'Bar']) :invocant
To allo
Patrick R. Michaud wrote:
On Thu, Dec 27, 2007 at 07:26:30PM +0200, Allison Randal wrote:
Agreed. (It's worth noting that the problem existed before :invocant was
added.) Adding :invocant, and giving it a string parameter, means we
could do away with the list of types on the :multi flag (we'd s
On Thu, Dec 27, 2007 at 07:26:30PM +0200, Allison Randal wrote:
> Agreed. (It's worth noting that the problem existed before :invocant was
> added.) Adding :invocant, and giving it a string parameter, means we
> could do away with the list of types on the :multi flag (we'd still need
> the :mult
On Thu, Dec 27, 2007 at 07:15:40PM +0200, Allison Randal wrote:
>
> With autoboxing/unboxing, there's not really a need to differentiate
> between the PMC Integer/String/Float types and the I/S/N registers.
Coming into this discussion from the middle (and having not read
pdd15 in great detail),
Klaas-Jan Stol wrote:
we just removed the ".pcc_" prefix... (i know, only from some other
directives...) :-P
anyway, the .invocant, .arg , .result and other directives are "grouped"
together already by the .begin_call/.end_call directives. IMHO, we don't
need a prefix to indicate such a groupi
Bob Rogers wrote:
Thought so. I ask because Common Lisp has provision for anonymous
classes, and I was wondering how I might support that some day. But my
interest is just academic curiosity at this point, because I'm (still)
nowhere near implementation.
CLOS dispatches on anonymous classes?
On 26/12/2007, James Keenan via RT <[EMAIL PROTECTED]> wrote:
> Once I got the tuits, the merging of these two Parrot configuration
> steps went quite quickly. But before applying a patch to trunk, I would
> like the assistance of other testers on the 4 CPU platforms handled by
> gen::cpu and what
Author: kjs
Date: Thu Dec 27 02:00:14 2007
New Revision: 24226
Modified:
trunk/docs/pdds/draft/pdd19_pir.pod
Log:
[pdd19] remove depr. that are gone now. Some other minor layout.
Modified: trunk/docs/pdds/draft/pdd19_pir.pod
Coming back to this code after nearly two months, I realized that the
analysis I posted on Nov 05 was slightly inaccurate, though its main
point -- that the control flow of auto::gc is peculiar and confusing --
is still correct.
As currently structured, the control flow inside this step's runstep(
20 matches
Mail list logo
