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
# 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
--- 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,
--- 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
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
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
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
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
# 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
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
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 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 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
# 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
# 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
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 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
# 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
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 .
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 --
# 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
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
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 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
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 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"
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
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 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
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 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 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 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 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
34 matches
Mail list logo
