Here is the patch. It changes the string_bool function an his
declaration, and deletes the check for null before calling it in
several places.
--
Salu2
Index: src/ops/core.ops
===
--- src/ops/core.ops (revisión: 27462)
+++ src/ops/c
On Monday 12 May 2008 09:23:18 NotFound wrote:
> The problem is that the opcode checks for nullness before calling
> string_bool:
>
> op if (invar STR, labelconst INT) {
> if ($1 && string_bool(interp, $1))
> goto OFFSET($2);
> }
>
> And the jitted code apparently calls string_bool unc
I forgot to Cc: the list. Also, I've taken this ticket and will apply
NotFound's patch in a day or so if we don't hear objections.
Pm
On Mon May 12 10:08:19 2008, pmichaud wrote:
> On Mon May 12 09:23:49 2008, [EMAIL PROTECTED] wrote:
> > The easier solution is to redefine string_bool to allow a
On Tue, Sep 18, 2007 at 6:59 PM, via RT Nuno Carvalho
<[EMAIL PROTECTED]> wrote:
> While running 'make fulltest', for today's release, we noticed there
> is a test failling for 't/op/string.t' when using jit runcore. This
> test is currently being skipped.
>
> The test that's failling is tes
On Mon, May 12, 2008 at 08:07:27AM -0700, Will Coleda via RT wrote:
> On Sat May 10 20:42:00 2008, tene wrote:
> > 19:13 <@pmichaud> so, set $PX[$PX], $PX is calling set_pmc_keyed even
> > when [$PX] is an Integer
> > 19:31 <@pmichaud> $P1[$P2] always invokes get_pmc_keyed and never
> > get_pmc
On Sat May 10 20:42:00 2008, tene wrote:
> 19:13 <@pmichaud> so, set $PX[$PX], $PX is calling set_pmc_keyed even
> when [$PX] is an Integer
> 19:31 <@pmichaud> $P1[$P2] always invokes get_pmc_keyed and never
> get_pmc_keyed_int
> 19:31 <@pmichaud> that's a bit of a problem for aggregates that h
On Mon May 12 00:10:26 2008, [EMAIL PROTECTED] wrote:
> On Monday 07 April 2008 21:29:27 Will Coleda via RT wrote:
>
> > ... I'd apply it, except that the following op breaks the build (and
> is
> > already checked in. =-)
> >
> > inline op not(invar PMC) :base_core {
> > $2->vtable->i_logical_n
On May 12, 2008, at 3:11 AM, NotFound wrote:
Maybe the solution is to avoid the problem, that is, put the
declarations outside of the HEADERIZER block. What's the point of
having static functions inside one?
So that declaration and definition are always in sync.
--
Andy Lester => [EMAIL PRO
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon May 12 13:00:04 2008 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with m
# New Ticket Created by Chris Fields
# Please include the string: [perl #54004]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=54004 >
r27449 and r27451, Mac OS X 10.5, Intel. Appears possibly related to
GC issues.
cjfi
There appears to be a possible GC-related bug introduced to Parrot
prior to r27449 which is showing up in Rakudo. Using the following
script (courtesy of Jonathan W):
class Foo {
has $.x;
method boo { say $.x }
}
class Bar is Foo {
method set($v) {
On Mon, May 12, 2008 at 4:34 AM, Andy Lester via RT
<[EMAIL PROTECTED]> wrote:
> This won't work because it modifies the sections in between HEADERIZER
> BEGIN & END sections. As of this writing, there is no solution for this
> problem.
Maybe the solution is to avoid the problem, that is, put t
On Monday 07 April 2008 21:29:27 Will Coleda via RT wrote:
> ... I'd apply it, except that the following op breaks the build (and is
> already checked in. =-)
>
> inline op not(invar PMC) :base_core {
> $2->vtable->i_logical_not(interp, $1);
> goto NEXT();
> }
Parrot::Op::rewrite_body() rewri
13 matches
Mail list logo
