On Monday 02 June 2008 10:58:29 Paco Linux wrote:
> Both patches tested in 10.3/ppc and 10.4/intel and works OK for me
Confirmation from both of you is good enough for me. Thanks, applied as
r28915.
-- c
On Wednesday 11 June 2008 12:48:51 NotFound via RT wrote:
> Another attempt: this is a minimalistic change that does not broke any
> test in parrot nor in rakudo, and can avoid segfaulting in other related
> usages.
Thanks, applied with a test in r28884.
I tried to add an exception in NameSpace'
On Wednesday 18 June 2008 07:42:00 Michael Peters wrote:
> It seems that archname was not defined in $PConfig, so I just used cpuarch.
> I also changed $^X to be $PConfig{osname}. The fixed patch is attached.
>
> I also noticed that I didn't include the new Test::Harness in that patch.
> So I've a
On Monday 30 June 2008 08:49:32 [EMAIL PROTECTED] wrote:
> Modified:
>trunk/tools/util/perlcritic.conf
>
> Log:
> Resolve RT# 56470;
>
> Tell perlcritic not to warn about uninstalled modules.
>
>
>
> Modified: trunk/tools/util/perlcritic.conf
> =
On Monday 30 June 2008 14:53:17 [EMAIL PROTECTED] wrote:
> Modified:
>branches/gsoc_pdd09/include/parrot/smallobject.h
>branches/gsoc_pdd09/src/gc/gc_it.c
>branches/gsoc_pdd09/src/gc/memory.c
>branches/gsoc_pdd09/src/headers.c
>
> Log:
> [gsoc_pdd09] add a few ugly but remarkably h
On Mon Jun 30 17:02:32 2008, coke wrote:
>
> In a fresh checkout, if I 'make renumberops' with no local
> modifications, src/ops/ops.num changes.
With my non-fresh branch, I could not confirm this.
> If I rename the op store_lex to barf_lex, and run 'make renumberops',
> the opcode barf_lex does
Andrew Whitworth via RT wrote:
With some help from DietCoke, we got most of the problem solved.
However, several tests are failing now, especially those dealing with
overriding the invoke vtable method.
One error specifically caught my eye, from t/pmc/namespace.t:1672:
sub 'main' :main
$P0
On Sun, Jun 22, 2008 at 1:05 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> On Sat Jun 21 07:16:56 2008, [EMAIL PROTECTED] wrote:
> [snip]
>>
>> (a) pull renum_op_map_file() out of Parrot::Ops2pm::Utils and into a
>> subclass -- the better to emphasize that it's not part of the regular
>> 'ma
On Wed Nov 21 07:45:53 2007, [EMAIL PROTECTED] wrote:
> Setting the :vtable pragma on a sub should enable the 'self' shortcut
> for the current invocant. As in the following code example where a
> method is called from within a vtable override:
>
>.sub main :main
> $P1 = newclass "Foo"
With some help from DietCoke, we got most of the problem solved.
However, several tests are failing now, especially those dealing with
overriding the invoke vtable method.
One error specifically caught my eye, from t/pmc/namespace.t:1672:
.sub 'main' :main
$P0 = newclass 'Override'
$P1 =
On Mon, 30 Jun 2008, chromatic wrote:
> > On Mon, Jun 30, 2008 at 3:55 PM, Ron Blaschke <[EMAIL PROTECTED]> wrote:
> > > Given a regular x86 (GNU/Linux) box, using GCC 4.2.3, should the
> > > following produce a working Parrot, using 64-bit ints?
> > >
> > > perl Configure.pl --intval="long long
chromatic wrote:
On Monday 30 June 2008 13:00:37 Will Coleda wrote:
# New Ticket Created by Will Coleda
# Please include the string: [perl #56484]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56484 >
Any time we can pro
On Monday 30 June 2008 13:00:37 Will Coleda wrote:
> # New Ticket Created by Will Coleda
> # Please include the string: [perl #56484]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=56484 >
>
>
> Any time we can produce a s
# New Ticket Created by Will Coleda
# Please include the string: [perl #56484]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56484 >
Any time we can produce a segfault, that's bad. CC'ing rt to get a ticket.
On Mon, Jun
Any time we can produce a segfault, that's bad. CC'ing rt to get a ticket.
On Mon, Jun 30, 2008 at 3:55 PM, Ron Blaschke <[EMAIL PROTECTED]> wrote:
> Given a regular x86 (GNU/Linux) box, using GCC 4.2.3, should the following
> produce a working Parrot, using 64-bit ints?
>
> perl Configure.pl --
Given a regular x86 (GNU/Linux) box, using GCC 4.2.3, should the
following produce a working Parrot, using 64-bit ints?
perl Configure.pl --intval="long long int" --opcode="long long int"
If fails for me on C while building PGE.
../../parrot -o PGE.pbc --output-pbc PGE.pir
../../parrot .
# New Ticket Created by Will Coleda
# Please include the string: [perl #56476]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56476 >
This ticket can be used to track any issues (or plans) regarding the
adoption of compiler
On Mon Jun 30 07:53:20 2008, coke wrote:
> Find a perlcritic-sane way to silence this warning for codetest:
>
> Policy "Perl::Critic::Policy::Bangs::ProhibitFlagComments" is not
installed.
>
Fixed in r28867.
--
Will "Coke" Coleda
On Mon Jun 30 06:26:57 2008, pmichaud wrote:
> The islt, isle, isgt, and isge opcodes give the wrong results on
> subclasses of Float.
>
> Here's the test case:
>
> $ cat y.pir
> .sub 'main' :main
> $P99 = subclass 'Float', 'MyFloat'
>
> $P0 = new 'MyFloat'
>
# New Ticket Created by Will Coleda
# Please include the string: [perl #56470]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56470 >
Find a perlcritic-sane way to silence this warning for codetest:
Policy "Perl::Critic::P
# New Ticket Created by Will Coleda
# Please include the string: [perl #56468]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56468 >
Now that we can subclass PMCs with Objects, we need to go through all
the code in src/pmc
On Mon, Jun 30, 2008 at 07:25:11AM -0500, Patrick R. Michaud wrote:
: So my question is really whether or not we consider grep and
: reverse to be universal methods in this sense also, so that
: C< $x.grep(...) > and C< $x.reverse > will work even if $x
: isn't a value that normally does list-typ
On Mon Jun 30 06:26:57 2008, pmichaud wrote:
> The islt, isle, isgt, and isge opcodes give the wrong results on
> subclasses of Float.
>
> Here's the test case:
>
> $ cat y.pir
> .sub 'main' :main
> $P99 = subclass 'Float', 'MyFloat'
>
> $P0 = new 'MyFloat'
>
On Sun, 29 Jun 2008, Andrew Whitworth wrote:
> There are a few other simplifications that I think can be made also.
> For instance, in calculating the size of a new Stack_Chunk_t, we use
> the convoluted equation "size = sizeof(Stack_Entry_t) +
> offsetof(Stack_Chunk_t, u.data)", which is much mor
On Mon, Jun 30, 2008 at 07:25:11AM -0500, Patrick R. Michaud wrote:
> Moritz is correct -- in order to get ('foo').join(':') to work as
> people will expect, it was decided to define "universal" methods
> in the Any class as part of the prelude [1].
I forgot to include the reference link:
1. htt
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #56464]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56464 >
The islt, isle, isgt, and isge opcodes give the wrong results on
subclasses of Flo
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Jun 30 13:00:01 2008 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with m
On Mon, Jun 30, 2008 at 01:43:11PM +0200, Moritz Lenz wrote:
> Ovid wrote:
> > --- On Sun, 29/6/08, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> >
> >> Do C and C act like the
> >> C method, in that
> >> they work for C object and not just objects of
> >> type C?
> >>
> >> In other words,, sho
In a message dated Mon, 30 Jun 2008, Ovid writes:
I just noticed you included 'reverse' in that list of methods. I
thought junctions were inherently unordered, thus making reverse
kind of useless (which leads me even more to believe that I've
misunderstood the question).
Yes--Junction is a s
Ovid wrote:
> --- On Sun, 29/6/08, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
>
>> Do C and C act like the
>> C method, in that
>> they work for C object and not just objects of
>> type C?
>>
>> In other words,, should C< $x.grep(...) > work even
>> if $x isn't normally a list type?
>
> If
--- On Mon, 30/6/08, Ovid <[EMAIL PROTECTED]> wrote:
> --- On Sun, 29/6/08, Patrick R. Michaud
> <[EMAIL PROTECTED]> wrote:
>
> > Do C and C act like the
> > C method, in that
> > they work for C object and not just objects
> of
> > type C?
> >
> > In other words,, should C< $x.grep(...) > work
--- On Sun, 29/6/08, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> Do C and C act like the
> C method, in that
> they work for C object and not just objects of
> type C?
>
> In other words,, should C< $x.grep(...) > work even
> if $x isn't normally a list type?
If I understand you correctly,
# New Ticket Created by Bob Rogers
# Please include the string: [perl #56458]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56458 >
Every RetContinuation in the active call chain must be promoted to a
full Continuation
The segfault occurs inside clone_key_arg() inside src/inter_call.c (at
line 871), which has the following leading POD description (committed by
chromatic who also committed most of the implementation):
Replaces any src registers by their values (done inside clone). This
needs a test for tailcalls
34 matches
Mail list logo
