Re: [perl #43719] [TODO] Complain about using, e.g. $3 in an op with only 2 args
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() rewrites this so that it's not a problem. See line
355:
C macros are enforced by converting C<<< I<< x >>->vtable->I<<
method >> >>> to C>.
Apply away.
-- c
Re: [perl #53990] [CAGE] [PATCH] warnings in compilers/imcc/optimizer.c
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 the declarations outside of the HEADERIZER block. What's the point of having static functions inside one? -- Salu2
Parrot Bug Summary
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 most open tickets --- Numbers Ticket Counts: 13 new + 685 open = 698 Created this week: 19 Closed this week: 88 --- New Issues New issues that have not been responded to yet 1 - 2 weeks old 53610 [BUG] Extra libraries on CC build command. 2 - 3 weeks old 53396 [BUG] Miscellaneous test failures on Windows 53394 [BUG] Divide-by-zero error in test on Windows 53392 [BUG] Sign tests failing on Windows 3 - 4 weeks old 52886 [BUG] including gmp.h causes build break in C++ build 4 - 5 weeks old 5 - 6 weeks old 6 - 7 weeks old 7 - 8 weeks old 8 - 9 weeks old 51634 [BUG] docs/parrotbyte.pod && docs/pdds/pdd13_bytecode.pod are either incorrect/unclear 9 - 10 weeks old 10 - 11 weeks old 51330 [TODO] dynext - dll versioning 11 - 12 weeks old 12 - 13 weeks old 13 - 14 weeks old 14 - 15 weeks old 50360 [RFE] Redesign Parrot NCI callback functionality 15 - 16 weeks old 16 - 17 weeks old 17 - 18 weeks old 18 - 19 weeks old 19 - 20 weeks old 20 - 21 weeks old --- Overview of Open Issues PlatformSeverity Tag Lang aix0abandoned 05005threads 0 Amber 0 All1fatal 2bounce0 BASIC 0 bsdos 0High 0Bug 82 bc 0 cygwin 2low 1compiler 0 befunge 0 cygwin_nt 0medium0configure 3 bf 0 darwin10none 1core 2 cola0 dec_osf0Normal2dailybuild0 forth 0 dgux 0unknown 0docs 3 jako0 dos0Wishlist 3duplicate 0 Lisp0 dynixptx 0 install 2 lolcode 0 freebsd8 library 0 m4 0 generic0 notabug 0 ook 0 gnu0 notok 0 perl6 1 HPUX 2 ok0 plot0 irix 0 Patch34 punie 0 irix64 0 regex 2 pynie 0 Linux 3 sendToCPAN0 python 0 lynxos 0 Todo356 ruby0 mac0 unknown 0 scheme 0 machten0 utilities 0 tcl 0 macos 0 wontfix 0 urm 0 MacOS X8 Zcode 0 mswin321 netbsd 1 next 0 openbsd2 os20 os390 0 other 0 powerux0 qnx0 riscos 0 sco0 Solaris4 sunos 1 svr4 0 svr5 0 sysv 0 unicos 0 unicosmk 0 unix 0 unknown0 uts0 vms0 VOS0 Win32 9 --- Ticket Status By Version New or OpenResolved --- Requestors with most open tickets Paul Cochrane 262 Will Coleda61 Patrick R. Michaud 31 chromatic 31 Jerry Gay 27 James Keenan 24 Klaas-Jan Stol 19 Mark Glines19 Bernhard Schmalhofer 15 Leopold Toetsch11 --- * Total Issues * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- This page is CPU intensive to create, it will be updated only once every 30 minutes
Re: [perl #53990] [CAGE] [PATCH] warnings in compilers/imcc/optimizer.c
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 PROTECTED] => www.petdance.com => AIM:petdance
[perl #43719] [TODO] Complain about using, e.g. $3 in an op with only 2 args
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_not(interp, $1);
> > goto NEXT();
> > }
>
> Parrot::Op::rewrite_body() rewrites this so that it's not a problem.
> See line
> 355:
>
> C macros are enforced by converting C<<< I<< x >>->vtable-
> >I<<
> method >> >>> to C>.
>
> Apply away.
>
> -- c
>
Done in r27462, closing ticket. Thanks for the detective work.
[perl #53978] Keyed lookup error
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 have > both hash keys and int keys > > There is some inline PIR in rakudo that needs to be removed when this is > fixed. Check r27433. I think it's arguable that the current behavior is correct; If you want to use the keyed int syntax, isn't: $I0 = $P1 $P2[$I0] the proper way to trigger that?
Re: [perl #53978] Keyed lookup error
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_keyed_int > > 19:31 <@pmichaud> that's a bit of a problem for aggregates that have > > both hash keys and int keys > > > > There is some inline PIR in rakudo that needs to be removed when this is > > fixed. Check r27433. > > I think it's arguable that the current behavior is correct; If you want > to use the keyed int syntax, isn't: > > $I0 = $P1 > $P2[$I0] > > the proper way to trigger that? Yes. But this also means that we have to have separate PAST node types for keyed versus keyed_int. That's not necessarily a bad thing, but it does increase the amount of code a bit. (And yes, this is the approach I'm planning to adopt for the time being.) Pm
Re: [perl #45503] one test in 't/op/string.t' is failling for jit runcore
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 test number #91 "if_s_ic", the last part 'ok
> 10':
>
> clears
> if S1, BAD10
> branch OK10
>
> the if op for S1, which is null, is giving an assertion error. I tried
> to poke around the jit core source code for a bit, but wasn't able to
> fix it. My parrot's jit knowledge is not that good, I admit. Can
> anyone more confortable on this area shed some light on the subject.
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 unconditionally.
The easier solution is to redefine string_bool to allow a NULL
argument and return false in that case. Many places in the code does
that check before the call, so this change will simplify it.
I expect to hear some comments before preparing a patch, given that
this will change the signature of a widely used function.
--
Salu2
[perl #45503] [BUG] one test in 't/op/string.t' is failling for jit runcore
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 NULL > > argument and return false in that case. Many places in the code does > > that check before the call, so this change will simplify it. > > +1 from me. I'd even give this +2 if I could. > > Notably, many of the functions in src/string.c check for NULL values > prior to performing a function (e.g., string_equal, string_concat, etc.) > so it makes very good sense to me for string_bool to do the same. > > Pm
Re: [perl #45503] one test in 't/op/string.t' is failling for jit runcore
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 unconditionally.
>
> The easier solution is to redefine string_bool to allow a NULL
> argument and return false in that case. Many places in the code does
> that check before the call, so this change will simplify it.
>
> I expect to hear some comments before preparing a patch, given that
> this will change the signature of a widely used function.
I fixed a few similar problems with the optimized build. Is r27069 any
guidance? r23771 looks like it might affect this function as well.
-- c
Re: [perl #45503] [BUG] one test in 't/op/string.t' is failling for jit runcore
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/core.ops (copia de trabajo)
@@ -315,7 +315,7 @@
}
op if (invar STR, labelconst INT) {
-if ($1 && string_bool(interp, $1))
+if (string_bool(interp, $1))
goto OFFSET($2);
}
@@ -349,7 +349,7 @@
}
op unless(invar STR, labelconst INT) {
-if (!$1 || !string_bool(interp, $1))
+if (!string_bool(interp, $1))
goto OFFSET($2);
}
Index: src/string.c
===
--- src/string.c (revisión: 27462)
+++ src/string.c (copia de trabajo)
@@ -1806,9 +1806,9 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
INTVAL
-string_bool(PARROT_INTERP, ARGIN(const STRING *s))
+string_bool(PARROT_INTERP, ARGIN_NULLOK(const STRING *s))
{
-const INTVAL len = string_length(interp, s);
+const INTVAL len = s ? string_length(interp, s) : 0;
if (len == 0)
return 0;
Index: src/pmc/string.pmc
===
--- src/pmc/string.pmc (revisión: 27462)
+++ src/pmc/string.pmc (copia de trabajo)
@@ -167,7 +167,7 @@
VTABLE INTVAL get_bool() {
STRING * const s = VTABLE_get_string(INTERP, SELF);
-return s ? string_bool(INTERP, s) : 0;
+return string_bool(INTERP, s);
}
/*
Index: CREDITS
===
--- CREDITS (revisión: 27462)
+++ CREDITS (copia de trabajo)
@@ -1,4 +1,4 @@
-# $Id$
+ÿ# $Id$
Following in the steps of other open source projects that
eventually take over the world, here is the partial list
@@ -498,6 +498,10 @@
N: Nigelsandever
D: Win32 patches
+N: NotFound
+D: Bug fixing and cage cleaning.
+E: [EMAIL PROTECTED]
+
N: Nuno 'smash' Carvalho
D: PGE/perl6/abc debugging and testing
E: [EMAIL PROTECTED]
Index: include/parrot/string_funcs.h
===
--- include/parrot/string_funcs.h (revisión: 27462)
+++ include/parrot/string_funcs.h (copia de trabajo)
@@ -150,9 +150,8 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
-INTVAL string_bool(PARROT_INTERP, ARGIN(const STRING *s))
-__attribute__nonnull__(1)
-__attribute__nonnull__(2);
+INTVAL string_bool(PARROT_INTERP, ARGIN_NULLOK(const STRING *s))
+__attribute__nonnull__(1);
PARROT_API
PARROT_WARN_UNUSED_RESULT
