__color__,__group__,ticket,summary,component,milestone,type,created,_changetime,_description,_reporter
4,allison,304,Some files copyright Melvin Smith,none,,bug,2009-02-10T03:04:38Z,2010-07-27T21:19:46Z,"To resolve an outstanding copyright issue, the following files need to be updated to reflect a TPF or Parrot Foundation copyright.

The easiest way to do this is to get a CLA (http://www.parrot.org/files/parrot_cla.pdf) from Melvin Smith and update the copyright to the Parrot Foundation.

{{{
imcc/imcc.l
imcc/imcc.y
imcc/imclexer.c
imcc/imcparser.c
imcc/main.c
imcc/parser_util.c
}}}",coke
4,allison,1165,need ability to dispatch to parent's method or vtable from PIR,none,,RFC,2009-10-30T17:25:29Z,2011-02-14T01:58:17Z,"If you write a class in PIR, you can access certain ancestral methods/vtables by getting the 'proxy' attribute for that ancestor, with two big limitations.

you need to know the name of the ancestor that implements the vtable (this isn't always your direct parent.)

that ancestor MUST be a PMC (not another class.)

Since there is no generic mechanism to invoke a vtable by name, we should probably continue to use a proxy object to access this functionality.

perhaps:

{{{
# INT values only!
.sub set_pmc_keyed :vtable
    .param pmc key
    .param pmc value
    $I0 = value
    .local pmc proxy
    proxy = get_proxy self
    proxy[key] = $I0
.end
}}}

Bikeshed away. Tcl needs this or something like it to fully implement the trace builtin. (which basically lets us run code before and after each vtable access.)",coke
4,allison,592,Add documentation for parrot_debugger,docs,2.5,roadmap,2009-04-28T21:03:28Z,2011-03-27T14:14:19Z,"Add documentation for the PIR debugger, 'parrot_debugger'. We need more examples.",allison
4,allison,624,pluggable everything,core,2.11,roadmap,2009-04-29T00:19:49Z,2012-01-04T10:40:43Z,A blanket wishlist item to change a substantial part of the core to dynamic extensions. The first step of the task is reviewing Parrot core to decide what parts might be good candidates for a pluggable architecture.,allison
4,ash,1787,OS X --m=32 doesn't work in snow leopard,configure,,bug,2010-09-13T15:37:23Z,2010-09-21T02:46:33Z,"In OS X, if you try to build parrot as 32 bit using --m=32 it has no effect. 

Also, it would be nice if there was a configuration option for building a universal binary in OS X (which means configuring for 32-bit, 64-bit x86 and possibly ppc, and ppc64).",ash
3,bacek,1801,Properly merge pools in GC MS2 when child interpreter destroyed.,GC,,todo,2010-09-24T01:10:15Z,2010-09-24T03:52:47Z,Currently GC MS2 doesn't properly clean up in finalize mode due absence of merging pools functionality. It should be implemented.,bacek
4,bacek,599,bytecode generation from post,none,2.6,roadmap,2009-04-28T22:14:30Z,2011-02-20T23:50:26Z,"Hello.

Yes, in PIRATE and nqp_pct branches there is some initial work on generating PBCs from POST. Not finished yet.

I'll probably jump on new NQP train and implement it there with future importing into parrot tree.

-- 
Bacek",allison
4,bacek,1052,[TODO] Add --target=pbc to HLLCompiler,PCT,,todo,2009-09-21T18:51:07Z,2011-02-01T23:47:44Z,"HLLCompiler should be able to produce bytecode files directly.  See RT #56186 for discussion.

Pm",pmichaud
5,brianwisti,1830,docs.parrot.org should render POD in files that don't end in .pod,docs,,todo,2010-10-16T22:31:56Z,2011-03-27T14:23:55Z,"For instance, the POD for the String::Utils PIR library is not on docs.parrot.org",dukeleto
3,bubaflub,1195,"Add cross-compiling support to Configure.pl, such as --target=i386-rtems4.10",configure,,feature,2009-11-05T03:54:55Z,2011-03-27T14:42:30Z,"Parrot is currently being ported to the RTEMS real-time OS. This means that we need to support cross-compiling.

More info here: 

http://leto.net/dukeleto.pl/2009/11/realtime-embedded-parrots.html",dukeleto
4,bubaflub,1657,Make it so that Parrot on RTEMS does not call the system exit(),core,,bug,2010-05-25T23:45:47Z,2011-03-27T14:40:37Z,"There are various ways to make this happen, and various levels of configurability, such as allowing a custom exit handler, but for starters, we just want Parrot on RTEMS to unconditionally not call the system exit() when shutting down, as this causes RTEMS to reboot.

Other tickets can be opened for a more features in the future.
",dukeleto
4,bubaflub,2130,Cannot run examples/library/ncurses_life.pir,library,,bug,2011-06-08T12:18:44Z,2011-06-23T21:57:04Z,"{{{
<masak> getting this error when trying to run ncurses_life.pir on a freshly
        checked-out and built Parrot: https://gist.github.com/1014297
<masak> :(
<moritz> ticket it!
* masak tickets it
}}}

For completeness, here are the contents of the gist:

{{{
$ ./parrot examples/library/ncurses_life.pir examples/library/acorn.life
Unknown param Signature 3

current instr.: '__ncurses_init' pc 41 (runtime/parrot/library/ncurses.pir:1)
called from Sub '_MAIN' pc 0 (examples/library/ncurses_life.pir:57)
... call repeated 1 times
}}}",masak
4,chromatic,748,memory leak in IMCC,imcc,,bug,2009-06-09T14:17:20Z,2011-03-03T04:08:42Z,"From a valgrind run against partcl (r440) on parrot (r39470) using

parrot tcl.pbc -e ""puts hi""

{{{
==12199== 25,242 bytes in 1,120 blocks are definitely lost in loss record 48 of 48
==12199==    at 0x402601E: malloc (vg_replace_malloc.c:207)
==12199==    by 0x40D78B3: mem_sys_allocate (alloc_memory.c:47)
==12199==    by 0x4136C0B: str_dup (primitives.c:357)
==12199==    by 0x43210B9: yylex_skip (imcc.l:859)
==12199==    by 0x431F527: yylex (imcc.l:416)
==12199==    by 0x431649E: yyparse (imcparser.c:3117)
==12199==    by 0x431C03D: compile_string (imcc.l:1351)
==12199==    by 0x4338A84: imcc_compile (parser_util.c:683)
==12199==    by 0x4338D2D: imcc_compile_pir_ex (parser_util.c:876)
==12199==    by 0x439708C: ???
==12199==    by 0x426112B: Parrot_NCI_invoke (nci.pmc:326)
==12199==    by 0x4061835: Parrot_invokecc_p (core.ops:504)
==12199==    by 0x413124F: runops_slow_core (cores.c:462)
==12199==    by 0x412FE4D: runops_int (main.c:987)
==12199==    by 0x40EC710: runops (ops.c:107)
==12199==    by 0x40ECB03: runops_args (ops.c:256)
==12199==    by 0x40ED9B5: Parrot_runops_fromc_args (ops.c:325)
==12199==    by 0x40CA856: Parrot_runcode (embed.c:1014)
==12199==    by 0x4322A5E: imcc_run_pbc (main.c:801)
==12199==    by 0x432365B: imcc_run (main.c:1092)
==12199==    by 0x8048967: main (main.c:61)
}}}

This is 82% of the leaked memory.
",coke
4,chromatic,800,Parrot assumes command line arguments are ASCII,core,,bug,2009-06-30T13:34:45Z,2011-02-21T14:17:38Z,"Currently Parrot (incorrectly) assumes that all command line arguments are ASCII:

{{{
$ cat x.pir
.sub 'main'
    .param pmc args

    $S0 = args[1]
    say $S0

    $I1 = charset $S0
    $S1 = charsetname $I1
    say $S1

    $I1 = encoding $S0
    $S1 = encodingname $I1
    say $S1

    $I1 = length $S0
    say $I1
.end
$ ./parrot x.pir 'say «hello»'
say «hello»
ascii
fixed_8
13
$ 
}}}

Most would expect the above to be a unicode/utf8 string of length 11.

If Parrot itself cannot be easily changed to accept unicode/utf8 command line arguments, then it would be nice to have a way to easily convert the ""ascii"" strings in args into proper unicode strings.  Thus far I've been unable to find a good way of doing that.

This ticket also relates to Rakudo RT #66364.

Pm",pmichaud
4,chromatic,1086,[BUG]  Test::More doesn't support plan('no_plan'),testing,,bug,2009-10-02T15:48:44Z,2010-11-22T11:03:33Z,"The documentation for Test::More (runtime/parrot/library/Test/More.pir:77) says that one can specify ""no_plan"" as a value to the plan() function, but it doesn't appear to work:

{{{
$ cat x.t
#!./parrot

.sub 'main' :main
    load_bytecode 'Test/More.pbc'

    .local pmc exports, curr_namespace, test_namespace
    curr_namespace = get_namespace
    test_namespace = get_namespace ['Test';'More']
    exports        = split ' ', 'plan diag ok nok is todo'
    test_namespace.'export_to'(curr_namespace, exports)

    plan('no_plan')

    ok(1, 'because I said so')
.end

$ prove x.t
x.t .. All 1 subtests passed 

Test Summary Report
-------------------
x.t (Wstat: 0 Tests: 1 Failed: 0)
  Parse errors: No plan found in TAP output
Files=1, Tests=1,  0 wallclock secs ( 0.03 usr  0.01 sys +  0.02 cusr  0.00 csys =  0.06 CPU)
Result: FAIL
$ ./parrot x.t
ok 1 - because I said so
$ 
}}}
",pmichaud
3,cotto,1916,"Deprecate freeze, thaw, and thawfinish VTABLEs",core,3.0,deprecation,2010-12-30T16:38:09Z,2011-08-27T17:08:29Z,"I would like to deprecate the freeze, thaw, and thawfinish vtables as they currently exist. freeze and thaw can both be implemented with the existing ""visit"" vtable. In many cases, freeze and thaw already redirect to visit. For consistency, I would like to rename thawfinish to ""visitfinish"". We do not need to modify thawfinish any further.

",whiteknight
4,cotto,1379,Port Perl 5 built-in times() to PIR,profiling,,bug,2009-12-18T07:24:16Z,2009-12-18T07:24:16Z,"It would be nice to be able to have something like Perl 5's times() builtin in PIR for calculating user time:

{{{
       times   Returns a four‐element list giving the user and system times,
               in seconds, for this process and the children of this process.

                   ($user,$system,$cuser,$csystem) = times;

               In scalar context, ""times"" returns $user.

               Note that times for children are included only after they
               terminate.

}}}",dukeleto
4,cotto,446,[CAGE] Fixed a few warnings and a NCI example on Windows using MSVS,configure,,cage,2009-03-14T12:01:04Z,2010-12-01T19:49:11Z,"Fixed '''warnings''' like unused variables, unreachable code in core.ops[[BR]]
config/gen/platform/win32/exec.c[[BR]]
config/gen/platform/win32/stat.c[[BR]]
include/parrot/encoding.h[[BR]]
src/embed.c[[BR]]
src/oo.c[[BR]]
src/ops/core.ops[[BR]]
src/packfile.c[[BR]]
src/spf_render.c[[BR]]
src/string/encoding.c[[BR]]
src/string/encoding/fixed_8.c[[BR]]
src/thread.c[[BR]]


also Fixed a '''NCI example'''[[BR]]
examples/nci/PQt.C[[BR]]
examples/nci/PQt.cpp[[BR]]
examples/nci/QtHelloWorld.pasm[[BR]]
examples/nci/QtHelloWorld.pir [[BR]]

this is a good way to get comfortable with code base :)[[BR]]


{{{
 CREDITS                          |    2
 config/gen/platform/win32/exec.c |    3
 config/gen/platform/win32/stat.c |    3
 examples/nci/PQt.C               |  149 --------------------------------------
 examples/nci/PQt.cpp             |  151 +++++++++++++++++++++++++++++++++++++++
 examples/nci/QtHelloWorld.pasm   |   22 ++---
 examples/nci/QtHelloWorld.pir    |   69 +++++++++++++++++
 include/parrot/encoding.h        |    8 +-
 src/embed.c                      |    2
 src/oo.c                         |    2
 src/ops/core.ops                 |   13 ++-
 src/packfile.c                   |    2
 src/spf_render.c                 |    3
 src/string/encoding.c            |   10 ++
 src/string/encoding/fixed_8.c    |    8 +-
 src/thread.c                     |    6 +
 16 files changed, 275 insertions(+), 178 deletions(-)
}}}



{{{
:
[FIXED]src\ops\core_ops.c
[FIXED]src\ops\core.ops(920) : warning C4189: 'resume' : local variable is initialized but not referenced
[FIXED]src\ops\core.ops(920) : warning C4189: 'resume' : local variable is initialized but not referenced
[FIXED]src\ops\core.ops(920) : warning C4189: 'resume' : local variable is initialized but not referenced
[FIXED]src\ops\core.ops(920) : warning C4189: 'resume' : local variable is initialized but not referenced
:
[NOT FIXED]src\ops\experimental.ops(52) : warning C4189: 'unused' : local variable is initialized but not referenced
:
:
[FIXED]f:\git\rakudo\parrot\src\ops\core.ops(1453) : warning C4702: unreachable code
[FIXED]f:\git\rakudo\parrot\src\ops\core.ops(1472) : warning C4702: unreachable code
[FIXED]f:\git\rakudo\parrot\src\ops\core.ops(1472) : warning C4702: unreachable code
src\ops\core_ops_switch.c
[FIXED]src\ops\core.ops(920) : warning C4189: 'resume' : local variable is initialized but not referenced
[FIXED]src\ops\core.ops(920) : warning C4189: 'resume' : local variable is initialized but not referenced
[FIXED]src\ops\core.ops(920) : warning C4189: 'resume' : local variable is initialized but not referenced
[FIXED]src\ops\core.ops(920) : warning C4189: 'resume' : local variable is initialized but not referenced
:
[FIXED]src\embed.c(1296) : warning C4189: 'pf' : local variable is initialized but not referenced
[FIXED]src\string\encoding.c
[FIXED]src\string\encoding.c(156) : warning C4646: function declared with __declspec(noreturn) has non-void return type
[FIXED]src\string\encoding.c(445) : warning C4646: function declared with __declspec(noreturn) has non-void return type
:
:
[FIXED]src\packfile.c(868) : warning C4189: 'pf' : local variable is initialized but not referenced
:
[FIXED]src\spf_render.c
[FIXED]src\spf_render.c(115) : warning C4005: 'snprintf' : macro redefinition
[FIXED]F:\git\rakudo\parrot\include\parrot/misc.h(28) : see previous definition of 'snprintf'
:
:
[FIXED]config/gen/platform/win32/stat.c(115) : warning C4244: '=' : conversion from 'time_t' to 'INTVAL', possible loss of data
[FIXED]config/gen/platform/win32/stat.c(118) : warning C4244: '=' : conversion from 'time_t' to 'INTVAL', possible loss of data
[FIXED]config/gen/platform/win32/stat.c(121) : warning C4244: '=' : conversion from 'time_t' to 'INTVAL', possible loss of data
[FIXED]config/gen/platform/win32/exec.c(218) : warning C4090: 'function' : different 'const' qualifiers
src\pmc_freeze.c
f:\git\rakudo\parrot\src\pmc_freeze.c(1725) : warning C4706: assignment within conditional expression
:
:
[FIXED]src\thread.c
[FIXED]f:\git\rakudo\parrot\src\thread.c(639) : warning C4701: potentially uninitialized local variable 'val_sub' used
[FIXED]f:\git\rakudo\parrot\src\thread.c(503) : warning C4700: uninitialized local variable 'interp' used
:
:
[FIXED]src\string\encoding\fixed_8.c
[FIXED]src\string\encoding\fixed_8.c(236) : warning C4646: function declared with __declspec(noreturn) has non-void return type
:


}}}
",ujwal
4,cotto,2042,Deprecate VTABLE_can,core,3.9,deprecation,2011-03-07T14:22:53Z,2011-07-19T05:55:28Z,"VTABLE_can is defined in two places: object.pmc and default.pmc. In both cases, it performs exactly this operation:

{{{
return !PMC_IS_NULL(VTABLE_find_method(interp, self, name));
}}}

Also, VTABLE_can is not able (yet) to be overridden from PIR code, which means that the vast majority of classes written by users will always have this same exact default behavior.

I suggest we deprecate and remove VTABLE_can. The ""can"" PIR op can remain, but should call VTABLE_find_method directly. ",whiteknight
4,cotto,1378,Hash or by-string interface to interp object / interpinfo / sysinfo,none,,feature,2009-12-18T03:16:12Z,2009-12-23T07:59:41Z,"See http://irclog.perlgeek.de/parrot/2009-12-18#i_1850474 for details, but basically I would like an NQP- and introspection-friendly interface to sysinfo, interpinfo, and the object returned by getinterp.

Right now, you must index these three with magic integers; this is hidden somewhat through the use of PASM macro constants, but these are not available to NQP or other HLL code.

In addition, it is not possible to cleanly introspect these to find extensions (such as special sysinfo values available only on certain OSen).

An iterable string-keyed hash interface would probably work well for this task.
",japhb
4,cotto,774,deprecate PMC multiple inheritance,pmc2c,,RFC,2009-06-18T18:23:06Z,2010-12-02T09:13:49Z,"I'd like to deprecate the behavior of pmc2c which allows C-level PMC multiple inheritance.  The behavior needs supporting code which isn't properly tested in Parrot's test suite.  Any modification to pmc2c that deals with a PMC's parents also needs to take this behavior into account or risk causing failures in HLLs which may not be reported for some time.

Currently the only language I know of that uses MI is Lua (partcl no longer needs it), and coke claims that MI doesn't allow anything that can't be done in another way.  I've asked fperrad about how much work it would be for him to avoid MI.  If it's a big deal for him (or any other HLL devs) I don't mind continuing to support it.

Once I hear back from fperrad and don't get any other objections, I'll add a proper deprecation notice so this feature can be removed post-1.4.",cotto
4,cotto,1212,".eof returns false if last read call read the last byte of the file, but not beyond",core,,RFC,2009-11-05T17:37:27Z,2011-02-25T23:38:54Z,"Hi,

It seems that the .eof() method on file handles can sometimes return 
true even if there is nothing more to read. This occurs when you have 
read upto the last byte of a file (e.g. when a readline reads up to the 
end of a newline, and that newline is the last thing in the file), but 
not beyond (which seems to be what causes the EOF flag to be set). I'm 
thinking this is the wrong behaviour?

Thoughts and fixes welcome!

Jonathan",jonathan
4,cotto,1885,Parrot_load_bytecode should only load bytecode,core,,RFC,2010-12-09T15:09:03Z,2011-08-27T18:02:49Z,"The function src/packfile.c:Parrot_load_bytecode() is too magical. It not only loads bytecode, but it also does some rudimentary extension string matching to also allow it to load .pir and .pasm file. This is extremely magical and is not made clear through the function's name.

This function is exposed primarily through the load_bytecode PIR op, which has similar magical behavior.

I suggest that we eliminate the magical behavior of this function and the opcode that exposes it: load_bytecode and Parrot_load_bytecode should *only* load bytecode files under any extension. If the user wants to compile a PIR source file they should use the PIR compreg.",whiteknight
4,cotto,1921,RFC: decorate all functions in src/platform.c with PARROT_EXPORT,core,,RFC,2011-01-01T00:12:50Z,2011-08-29T23:46:40Z,"I propose that we add PARROT_EXPORT to all functions in src/platform.c (i.e. all functions in all files used to generate src/platform.c).  This is necessary so that users of libparrot, in this case dynpmcs, can access platform-specific functions.  The problem that brought this up was that the OS pmc couldn't access Parrot_get_user_id, but I can imagine this cropping up in other places too.

I've created a gci task for this and rfw plans to work on it, but I want to make sure I'm not missing anything before I merge into master.",cotto
4,cotto,709,Pmc2c should generate mark and destroy VTABLES,core,,todo,2009-05-26T18:57:27Z,2011-02-14T00:36:51Z,"Pending discussion today in #ps: 
{{{
<Whiteknight> Propose adding a PObj flag ""PObj_uses_malloc_attrs_FLAG"" to automatically deallocate Parrot_*_attribute structures in the GC. Thoughts?
<chromatic> Alternative: smarten Pmc2C such that it automatically generates mark() and destroy() VTABLEs as necessary.
<allison> prefer chromatic's solution
}}}

Pmc2c.pl should be smart enough to:
 - automatically generate a mark() vtable to mark all STRING and PMC attrs, unless the user has specifically provided one, and
 - automatically generate a destroy() vtable to deallocate the Parrot_*_attributes structure, unless the user has already provided one.

There are lots of good reasons to do this.
",whiteknight
4,cotto,985,proper Configure.pl-time check for hires timers,profiling,,todo,2009-09-07T00:35:14Z,2011-03-12T11:53:15Z,"Currently parrot uses clock_gettime() unless the platform is darwin, in which it uses gettimeofday(). Any other esoteric platform that does not have clock_gettime() will currently not build on parrot. 

A proper check for each function should be done at Configure.pl-time for these. Devel::NYTProf2 has already solved most of these issues, we should emulate that.",dukeleto
5,cotto,817,[pmc2c] don't require custom #defines for private flags,build,,cage,2009-07-07T22:25:28Z,2010-10-16T22:48:42Z,"It'd be nice if pmc2c didn't require that custom private PObj flags be #defined, but rather provided a way to declare them as part of the pmclass declaration.  The syntax could look something like this:
{{{
pmclass FooClass
    group FooGroup
    extends FooBase {

    ATTR PMC    *foo;
    ATTR INTVAL *bar;

    FLAG FOO_IS_HAVING_A_GOOD_DAY;
    FLAG FOO_IS_WEARING_YELLOW;
}}}

This would be a good introductory task for someone wanting to get into Parrot since it's not urgent and wouldn't cause any compatibility breaks.  The majority of the code that would need to be changed is in lib/Parrot/Pmc2c/Parser.pm and lib/Parrot/Pmc2c/PMCEmitter.pm .",cotto
5,cotto,61,Investigate using an external hash library,library,,RFC,2008-12-17T20:42:04Z,2011-02-02T19:27:58Z,"We spend a lot of cycles on our hand-rolled hashing, both in terms of developer effort and CPU.

It would be nice if we could use an off the shelf hash package.

Any package under consideration would have to have a compatible license, and work on our minimal core platforms.",coke
5,cotto,1418,t/src/checkdepend.t should verify PIR/PBC dependencies,testing,,todo,2010-01-26T02:53:42Z,2011-08-27T17:46:37Z,"We need to verify our .pir build dependencies in the same way way we do our .c deps.

(Some of this code was in the original version in {{{tools/dev/checkdepend.pl}}} but was removed as it was not fully baked.

Current version is testing (and passing) all c deps.
",jkeenan
5,darbelo,1150,test all parrot command line flags,testing,,todo,2009-10-27T22:43:33Z,2011-02-25T01:32:07Z,"Update t/run/options.t to test all command line flags, as well as some invalid ones.

See original ticket at http://rt.perl.org/rt3/Ticket/Display.html?id=42339
",coke
3,dukeleto,2003,Configure.pl from tools/dev/create_language.pl doesn't play nice with git,tools,,bug,2011-02-09T20:36:48Z,2011-02-20T20:10:51Z,"The `Configure.pl` script generated by `tools/dev/create_language.pl` clones Parrot from GitHub, but it's not quite right. It still thinks `build/PARROT_REVISION` contains a numeric revision number, not a tag or checksum, which makes it emit this error:

`Argument ""RELEASE_3_0_0"" isn't numeric in addition (+) at Configure.pl line 25, <$REQ> line 1.`

The corresponding `build/gen_parrot.pl` has a similar problem:

`Argument ""RELEASE_3_0_0"" isn't numeric in addition (+) at build/gen_parrot.pl line 31, <$REQ> line 1.`

Perhaps the simplest way to fix this would be to adapt the solution used in Rakudo's `Configure.pl`.",arnsholt
3,dukeleto,1825,How To Utilize The GCC Compile Farm,build,,RFC,2010-10-13T00:55:18Z,2010-10-20T17:27:39Z,"Parrot now has access to the GCC Compile Farm, graciously hosted by the Free Software France organization. We need to figure out how best to use it i.e. installing BuildBot, TapTinder, smokers and benchmarkers across different configurations of Parrot, such as ICU/GMP/optimized/etc.

Here are some links to a presentation about the Compile Farm:

https://mail.gna.org/public/gcc-cfarm-users/2010-07/msg00025.html

This is the main wiki page: http://gcc.gnu.org/wiki/CompileFarm",dukeleto
3,dukeleto,236,implement pdd14-numbers,core,,todo,2009-01-27T19:44:29Z,2010-10-13T00:34:28Z,"add NaN/Inf to pdd, review spec against reality, implement what remains.",particle
4,dukeleto,358,complex NaN,core,,bug,2009-02-19T09:14:33Z,2011-10-19T17:34:21Z,"{{{
$ perl6
> say NaN*1i
NaNNaNi
}}}
All complex ops with NaN should return NaN.

Check the complex ops with NaN, add tests.",rurban
4,dukeleto,1491,mk_language_shell.pl and create_language.pl cause confusion,tools,,bug,2010-03-03T04:30:06Z,2011-08-03T02:23:39Z,It's confusing to have two scripts that appear to do the same thing without a clear indication why they both exist.  We need to differentiate the documentation of these scripts to the point where a potential HLL dev can look the inline POD of both of them and easily decide which one is appropriate for his or her needs.,cotto
4,dukeleto,1735,Pmc2c line numbering confuses gdb,tools,,bug,2010-08-10T06:14:56Z,2011-11-20T09:54:58Z,"Using the default configuration, gdb is unable to step through vtables, giving messages such as:

{{{

0x00007ffff7a90ae4 in Parrot_OpLib_init_pmc (
    interp=0x60a080, _self=0x789770, 
    name_pmc=0x7892d0)
   from /home/pitr/dev/parrot/dynop_mapping/blib/lib/libparrot.so.2.6.0
(gdb) n
Single stepping until exit from function Parrot_OpLib_init_pmc, 
which has no line number information.
Parrot_pmc_new_init (interp=0x60a080, base_type=37, 
    init=0x7892d0) at src/pmc.c:551
551	        return pmc;

}}}

This is a significant drag because much Parrot functionality is inside vtables.

Reconfiguring with --no-line-directives, which disables line directive generation from tools such as pmc2c, the vtables become steppable.",plobsing
4,dukeleto,1740,pbc_dump crashes on certain inputs,none,,bug,2010-08-13T17:51:50Z,2010-08-24T14:02:05Z,"A number of bugs discovered in pbc_dump by Avalanche dynamic program analysis tool (http://code.google.com/p/avalanche/). 

pbc_dump crashes on certain exploit inputs (attached).
",ild
4,dukeleto,1971,Oplib paths are truncated in PBC files,tools,,bug,2011-01-16T19:31:11Z,2011-05-22T02:07:59Z,"The problem seems to be that IMCC uses the correct path to load the oplib object file when compiling, but drops all directory information when producing the packfile, so that loading the PBC file fails to find the library.

1.  Unpack the attached test case tarball, and edit the PARROT-HOME macro in the makefile to point to a local Parrot working copy.

2.  Run ""make"" to build and run the test.  Here's what the output looks like on my machine (GNU/Linux, openSUSE 11.3):

    rogers@rgr> make
    /usr/src/parrot/ops2c --dynamic dynops/kea_cl.ops --quiet
    cc -I/usr/src/parrot/include -I/usr/src/parrot/include/pmc \
		    -o dynops/kea_cl_ops.o -c dynops/kea_cl_ops.c
    ld -o dynops/kea_cl_ops.so dynops/kea_cl_ops.o -shared
    /usr/src/parrot/parrot -o test.pbc test.pir
    /usr/src/parrot/parrot -o aux.pbc aux.pir
    /usr/src/parrot/parrot test.pbc
    Could not load oplib `kea_cl_ops'
    current instr.: 'main' pc 0 (test.pir:4)
    make: *** [test] Error 1
    rogers@rgr> 

3.  Apply parrot-lib-debugging.patch to the Parrot working copy, do ""make parrot"", and rerun the test:

    rogers@rgr> make clean
    rm -f *.pbc *.dump *.dis dynops/kea_cl_ops.*
    rogers@rgr> make
    /usr/src/parrot/ops2c --dynamic dynops/kea_cl.ops --quiet
    Got path '/usr/src/parrot/runtime/parrot/dynext/os.so' for os
    cc -I/usr/src/parrot/include -I/usr/src/parrot/include/pmc \
		    -o dynops/kea_cl_ops.o -c dynops/kea_cl_ops.c
    ld -o dynops/kea_cl_ops.so dynops/kea_cl_ops.o -shared
    /usr/src/parrot/parrot -o test.pbc test.pir
    Got path 'dynops/kea_cl_ops.so' for dynops/kea_cl_ops
    /usr/src/parrot/parrot -o aux.pbc aux.pir
    Got path 'dynops/kea_cl_ops.so' for dynops/kea_cl_ops
    /usr/src/parrot/parrot test.pbc
    Got path '' for kea_cl_ops
    Could not load oplib `kea_cl_ops'
    current instr.: 'main' pc 0 (test.pir:4)
    make: *** [test] Error 1
    rogers@rgr> 

This shows that IMCC is looking for ""dynops/kea_cl_ops"" (as you would expect), but the PBC file is looking for ""kea_cl_ops"" at load time and failing.  Indeed, if you do ""strings aux.pbc"", you will find the latter but not the former.  (As an aside, pbc_dump and pbc_disassemble do not work on aux.pbc.  Unless you copy dynops/kea_cl_ops.so to runtime/parrot/dynext/ in the Parrot working copy, where it will be found.)

4.  Change the aux.pir source to use the absolute pathname.  This does not help:

    rogers@rgr> make
    /usr/src/parrot/parrot -o aux.pbc aux.pir
    Got path '/home/rogers/projects/kea2/bug/dynops/kea_cl_ops.so' for /home/rogers/projects/kea2/bug/dynops/kea_cl_ops
    /usr/src/parrot/parrot test.pbc
    Got path '' for kea_cl_ops
    Could not load oplib `kea_cl_ops'
    current instr.: 'main' pc 0 (test.pir:4)
    make: *** [test] Error 1
    rogers@rgr> 

As before, just ""kea_cl_ops"" is stored in the PBC file.

FWIW, Parrot has never had this problem with dynamic PMC classes; the exact pathname used in the .loadlib directive makes it into the PBC file.
",rgrjr
4,dukeleto,2131,pbc_merge discards annotations,tools,,bug,2011-06-10T01:09:05Z,2011-06-10T01:09:05Z,"bytecode files output from pbc_merge do not contain any annotation information. HLLs that use annotations for debugging can't use pbc_merge.

pbc_merge should be updated to maintain annotation information, if possible.",whiteknight
4,dukeleto,1381,Parrot-based project skeleton creation script,tools,,feature,2009-12-18T18:56:09Z,2011-05-22T18:00:50Z,"Since not all Parrot projects are languages, it would be nice to have a project skeleton generator morally equivalent to Perl's Module::Starter.

Given `<project-builder> --module=Foo` (for one possible usage example), the following minimal layout might be generated:


    * Foo/
        * lib/
            * Foo.pir
        * t/
            * harness.pir
            * 00-sanity.t
        * setup.pir

setup.pir would manage primary tasks such as build, test, and install.

Extra credit items could include: a flag to define the project as mostly PIR or mostly NQP; a Foo/bin folder whose contents would go into an appropriate location (/usr/local/bin, $PARROT_BIN, whatever); other standard project files such as README.",brianwisti
4,dukeleto,1840,Config step to detect RTEMS,configure,,feature,2010-10-24T22:41:04Z,2011-03-27T14:41:18Z,"We need a config step that checks for __rtems__ and sets the parrot_config key of 'rtems' to true or false, depending on whether the symbol is defined.
",dukeleto
4,dukeleto,1819,mk_language_shell.pl generates broken PMC boilerplate,tools,,patch,2010-10-08T00:45:59Z,2010-10-09T07:27:09Z,"When one runs mk_language_shell.pl --with-pmc, the resulting boilerplate .pmc file doesn't even compile. There's a ""property"" variable that's used uninitialized, and a mysterious ""shape"" variable that's never defined. What's up with that?

Patch attached.
",ellefu
4,dukeleto,922,Coding standard tests for examples/ directories without tests,coding_standards,,todo,2009-08-15T02:51:19Z,2011-02-24T10:53:10Z,"A TODO test should be added for each directory in examples/ that does not have a corresponding file in t/examples . So the directory examples/foobar should have a corresponding test t/examples/foobar.t

Some important examples that fail this currently are SDL and OpenGL.

",dukeleto
4,dukeleto,1161,pdump - Dumping constants shouldn't unpack the constants,tools,,todo,2009-10-30T00:55:58Z,2011-02-25T03:35:57Z,"Dumping constants shouldn't unpack the constants, but
just print out the segment.

(from the TODO file)",coke
4,dukeleto,1226,Increase code coverage of json,library,,todo,2009-11-07T14:23:07Z,2011-02-25T01:30:49Z,"In the file t/compilers/json/to_parrot.t there is the todo item:

# XXX Need many more tests, exercising all aspects of http://www.json.org/

Previously tracked in RT#44443.",kjs
4,dukeleto,1880,Parrot_new should not need to be passed previously-created interps,core,,todo,2010-12-03T18:08:34Z,2011-10-20T17:17:57Z,"Currently Parrot_new requires being passed in the 1st interp that was ever created to create subsequent interpreter objects.

In PL/Parrot, many interps must be created, some are trusted, some are not. But they all need to know about the 1st interp that was created, which, from a security standpoint, is suboptimal. Here is a snippet from PL/Parrot's plparrot.c :

{{{
    untrusted_interp = Parrot_new(NULL);

    /* Must use the first created interp as the parent of subsequently created interps */
    trusted_interp = Parrot_new(untrusted_interp);

}}}
",dukeleto
5,dukeleto,2147,"ops2c and a variable with ""return"" in its name",tools,,bug,2011-07-09T12:40:11Z,2011-10-19T17:32:09Z,"{{{
15:00 <@jnthn__> So it turns out that if you have a variable called returns or
                 return_type in an ops file, ops2c goes and wraps it up in an
                 extra level of parens, causing an innevitable C syntax error.
                 WTF.
15:01 <@jnthn__> foo->return_type ends up coming out as foo->(return_type)
15:01 <@jnthn__> Rename that to rtype and it works
15:01 <@jnthn__> :/
}}}",jonathan
5,dukeleto,463,refactor PCT::HLLCompiler's detection of Test::Harness,tools,,todo,2009-03-16T14:49:42Z,2011-02-02T03:10:43Z,"In order to facilitate using PCT::HLLCompiler with test harnesses,
the C<command_line> method of PCT::HLLCompiler object exits silently
if it detects that it is being run in a sample run from Perl's
Test::Harness.  Currently this detection is done by checking the
second command line argument for ""@INC""; future releases may
use a different detection mechanism or eliminate it altogether.

",pmichaud
3,fperrad,326,win32 Wide API needed . 'make smoke' failed 63 tests.,core,,bug,2009-02-13T15:38:38Z,2011-02-21T14:21:13Z,"It failed 63 tests.

see http://smolder.plusthree.com/app/public_projects/report_details/17984

parrot fails to load:
.\parrot.exe -o C:/DOCUME~1/ÃÂ¢Â»Â¨ÃÃÃÃ/LOCALS~1/Temp/tySepN24eO

The Windows Wide API is not enabled.

As workaround $TEMP could be checked to point to a pure ascii path.",jimmy
4,Infinoid,157,[TODO] Merge parrotblog.org into parrot.org,website,,todo,2009-01-11T03:10:06Z,2010-09-19T12:27:49Z,"Before the 1.0 release, merge parrotblog.org into parrot.org. The tutorial posts should become regular pages in the developer section of the site. Other posts can be entered as news items (with the date set to match the original posting date).

(Anyone who had posting access on parrotblog.org should have access to post stories on parrot.org now, but if you don't, let us know.)",allison
4,japhb,1389,[LHF] Add tests for Plumage's Util.nqp,plumage,,todo,2009-12-23T02:04:12Z,2009-12-26T06:02:07Z,"Plumage's test suite is sorely lacking, and I could really use help from anyone with basic NQP skills to greatly expand it.  Looking for some low hanging fruit to help Plumage and Parrot?  Here's some.  `:-)`

`t/03-util.t`, which tests `src/lib/Util.nqp`, is the first test file that should get this attention, as `Util.nqp` is used throughout the project -- and in fact some or all of it may eventually move to be part of NQP-rx.

The Plumage repository is at `http://gitorious.org/parrot-plumage/parrot-plumage` .  There are basic layout and naming guidelines in `t/docs/hacking/add-tests.pod` (it's short, don't worry).

If you're a Plumage committer, just go ahead and commit.  If you want to be one, contact `japhb` on `#parrot` to get your commitbit.  Otherwise, patches attached to this ticket work just as well.

THANKS IN ADVANCE!
",japhb
4,jkeenan,1044,Configure.pl relies too heavily on perl5 ccflags settings.,configure,,bug,2009-09-21T12:58:49Z,2011-08-28T18:26:49Z,"See [http://rt.perl.org/rt3/Ticket/Display.html?id=38823 Original RT]
for more details.",doughera
4,jkeenan,1864,[RFC] Change coding standard to avoid 2 space outdent.,coding_standards,2.11,RFC,2010-11-23T10:53:52Z,2011-08-27T17:38:53Z,"Hello.

Current coding standard requires 2 space indent on switch/case indent. I would like to propose to change it to 4 space and close #1547 as ""wontfix"".

Basically I speak about this patch:
{{{
diff --git a/docs/pdds/pdd07_codingstd.pod b/docs/pdds/pdd07_codingstd.pod
index 8741a1b..52dc866 100644
--- a/docs/pdds/pdd07_codingstd.pod
+++ b/docs/pdds/pdd07_codingstd.pod
@@ -110,11 +110,6 @@ the level of indenting to increase.
 
 =item *
 
-Labels (including case labels) must be outdented two columns relative to the
-code they label.
-
-=item *
-
 Closing braces for control structures must line up vertically with the
 start of the control structures; e.g. C<}> that closes an C<if> must
 line up with the C<if>.
}}}

Or at least change ""including"" to ""excluding"".

-- 
Bacek",bacek
4,jkeenan,1726,Missing POD in .pmc files (and a couple of others),coding_standards,,todo,2010-08-01T18:51:51Z,2010-10-31T15:13:07Z,"We recently completed an exercise whereby the coding standard test t/codingstd/c_function_docs.t and the associated documentation was fixed so that no TODO's remain for missing POD in c functions in parrot.

I had occasion to run make headerizer and found that it reported missing POD in some other files, mostly .pmc files and one .y file (plus 3 .c files from compilers/src/pirc not tested by c_function_docs.t).

It is suggested that .pmc files be included in c_function_docs.t or possibly in a new test.

at r48245 make headerizer furnishes the following output:
{{{
compilers/imcc/imcc.y: adv_named_set_u has no POD
compilers/pirc/src/main.c: process_file has no POD
compilers/pirc/src/pircompunit.c: set_sub_multi_types has no POD
compilers/pirc/src/pirparser.c: YYID  has no POD
src/pmc/bigint.pmc: bigint_init has no POD
src/pmc/bigint.pmc: bigint_clear has no POD
src/pmc/bigint.pmc: bigint_set has no POD
src/pmc/bigint.pmc: bigint_set_str has no POD
src/pmc/bigint.pmc: bigint_get_self has no POD
src/pmc/bigint.pmc: bigint_set_self has no POD
src/pmc/bigint.pmc: bigint_get_long has no POD
src/pmc/bigint.pmc: bigint_get_bool has no POD
src/pmc/bigint.pmc: bigint_get_string has no POD
src/pmc/bigint.pmc: bigint_get_double has no POD
src/pmc/bigint.pmc: bigint_add_bigint has no POD
src/pmc/bigint.pmc: bigint_add_bigint_int has no POD
src/pmc/bigint.pmc: bigint_sub_bigint has no POD
src/pmc/bigint.pmc: bigint_sub_bigint_int has no POD
src/pmc/bigint.pmc: bigint_mul_bigint has no POD
src/pmc/bigint.pmc: bigint_mul_bigint_int has no POD
src/pmc/bigint.pmc: bigint_pow_bigint_int has no POD
src/pmc/bigint.pmc: int_check_divide_zero has no POD
src/pmc/bigint.pmc: bigint_check_divide_zero has no POD
src/pmc/bigint.pmc: bigint_div_bigint has no POD
src/pmc/bigint.pmc: bigint_div_bigint_int has no POD
src/pmc/bigint.pmc: bigint_fdiv_bigint has no POD
src/pmc/bigint.pmc: bigint_fdiv_bigint_int has no POD
src/pmc/bigint.pmc: bigint_mod_bigint has no POD
src/pmc/bigint.pmc: bigint_mod_bigint_int has no POD
src/pmc/bigint.pmc: bigint_cmp has no POD
src/pmc/bigint.pmc: bigint_cmp_int has no POD
src/pmc/bigint.pmc: bigint_abs has no POD
src/pmc/bigint.pmc: bigint_neg has no POD
src/pmc/callcontext.pmc: ensure_positionals_storage has no POD
src/pmc/callcontext.pmc: ensure_positionals_storage_ap has no POD
src/pmc/callcontext.pmc: get_cell_at has no POD
src/pmc/callcontext.pmc: autobox_intval has no POD
src/pmc/callcontext.pmc: autobox_floatval has no POD
src/pmc/callcontext.pmc: autobox_string has no POD
src/pmc/callcontext.pmc: autobox_pmc has no POD
src/pmc/callcontext.pmc: get_hash has no POD
src/pmc/callcontext.pmc: mark_cell has no POD
src/pmc/callcontext.pmc: mark_positionals has no POD
src/pmc/callcontext.pmc: mark_hash has no POD
src/pmc/callcontext.pmc: get_named_names has no POD
src/pmc/class.pmc: pointer_compare has no POD
src/pmc/class.pmc: key_hash_pointer has no POD
src/pmc/class.pmc: cache_class_attribs has no POD
src/pmc/class.pmc: build_attrib_index has no POD
src/pmc/class.pmc: init_class_from_hash has no POD
src/pmc/class.pmc: initialize_parents has no POD
src/pmc/class.pmc: initialize_parents_pmc has no POD
src/pmc/class.pmc: make_class_name has no POD
src/pmc/class.pmc: calculate_mro has no POD
src/pmc/complex.pmc: int_check_divide_zero has no POD
src/pmc/complex.pmc: float_check_divide_zero has no POD
src/pmc/complex.pmc: complex_check_divide_zero has no POD
src/pmc/coroutine.pmc: print_sub_name has no POD
src/pmc/eval.pmc: clear_fixups has no POD
src/pmc/eval.pmc: get_sub has no POD
src/pmc/eval.pmc: mark_subs has no POD
src/pmc/fixedintegerarray.pmc: auxcmpfunc has no POD
src/pmc/hashiterator.pmc: advance_to_next has no POD
src/pmc/imageio.pmc: GET_VISIT_CURSOR has no POD
src/pmc/imageio.pmc: SET_VISIT_CURSOR has no POD
src/pmc/imageio.pmc: INC_VISIT_CURSOR has no POD
src/pmc/imageio.pmc: create_buffer has no POD
src/pmc/imageio.pmc: ensure_buffer_size has no POD
src/pmc/imageio.pmc: INFO_HAS_DATA has no POD
src/pmc/imageio.pmc: id_list_get has no POD
src/pmc/imageio.pmc: visit_todo_list_thaw has no POD
src/pmc/imageio.pmc: visit_todo_list_freeze has no POD
src/pmc/imageiosize.pmc: visit_todo_list_freeze has no POD
src/pmc/integer.pmc: maybe_throw_overflow_error has no POD
src/pmc/integer.pmc: upgrade_self_to_bignum has no POD
src/pmc/namespace.pmc: add_to_class has no POD
src/pmc/namespace.pmc: ns_insert_sub_keyed_str has no POD
src/pmc/namespace.pmc: maybe_add_sub_to_namespace has no POD
src/pmc/namespace.pmc: add_nci_to_namespace has no POD
src/pmc/namespace.pmc: add_multi_to_namespace has no POD
src/pmc/nci.pmc: pcc_params has no POD
src/pmc/nci.pmc: build_func has no POD
src/pmc/null.pmc: null_pmc_access has no POD
src/pmc/object.pmc: get_attrib_index has no POD
src/pmc/object.pmc: get_attrib_index_keyed has no POD
src/pmc/object.pmc: find_cached has no POD
src/pmc/object.pmc: cache_method has no POD
src/pmc/orderedhash.pmc: get_list_item has no POD
src/pmc/orderedhash.pmc: find_bounds has no POD
src/pmc/orderedhash.pmc: box_string has no POD
src/pmc/orderedhash.pmc: box_integer has no POD
src/pmc/orderedhash.pmc: box_number has no POD
src/pmc/packfile.pmc: copy_packfile_header has no POD
src/pmc/role.pmc: init_role_from_hash has no POD
src/pmc/sub.pmc: print_sub_name has no POD
src/pmc/threadinterpreter.pmc: stop_GC has no POD
Headerization complete.
}}}
",mikehh
5,jkeenan,855,config/init/defaults.pm:  Profiling options are too specific to GCC,configure,,bug,2009-07-19T23:46:59Z,2011-01-03T22:54:34Z,"This ticket was created in [http://rt.perl.org/rt3/Ticket/Display.html?id=41497 RT #41497] by Paul T Cochrane in February 2007.  I am moving it into the Trac system to raise its visibility.  I believe it could be moved toward resolution by someone -- a newcomer, perhaps -- who was willing to spend some time doing Internet searching on the profiling options of various C compilers.

Original description:[[BR]]
'''The profiling options used in config/init/defaults.pm are specific to gcc. This should probably be specified in the relevant hints file.'''

The relevant code in ''config/init/defaults.pm'' is this:
{{{
    if ( $conf->options->get('profile') ) {
        $conf->data->set(
            cc_debug => "" -pg "",
            ld_debug => "" -pg "",
        );
    }
}}}
In the original ticket, Infinoid subsequently commented:  ''This flag convinces gcc to generate profiling code specifically for
the GNU profiler, `gprof`. I find it *extremely* unlikely that this
flag would be available and/or mean the same thing for other compilers ...''

In addition, Andy Dougherty commented:  ''[These options] are gcc-specific. A plain `-p` is common on Unix systems, but `-pg` is gcc-specific. For example, with Sun's C compiler, `-xpg` would be
the equivalent flag. (Though Sun's C compiler also has other profile
options selected by `-xprofile` ...)''

Could someone research profiling options on a variety of C compilers, including the principal C compilers for Windows?

Thank you very much.[[BR]]
kid51",jkeenan
2,kjs,562,"subclassing basic number types fails to inherit basic ops like add, sub, mul and div",core,,bug,2009-04-18T11:05:14Z,2009-12-05T23:00:15Z,"When subclassing base types like Integer, Float and Complex. The ops sub, add, mul and div are not properly inherited by the derived class.

A basic example is provided by the following code: -

{{{
.sub '' :main
    $P0 = subclass 'Integer', 'FooInt'
    
    print 'Integer: 10 - 1 = '
    $P0 = new 'Integer'
    $P0 = 10
    sub $P1, $P0, 1
    say $P1
 
    print 'FooInt: 10 - 1 = '
    $P0 = new 'FooInt'
    $P0 = 10
    #$P1 = new 'FooInt' # uncommenting here does not help
    sub $P1, $P0, 1
    say $P1 
.end
}}}

outputs the following: -

{{{
Integer: 10 - 1 = 9
FooInt: 10 - 1 = Multiple Dispatch: No suitable candidate found for 'subtract_int', with signature 'PIP->P'
...
}}}

This appears to be related to RT http://rt.perl.org/rt3/Public/Bug/Display.html?id=59630 which outlines the problem for a specific case of a Complex type.

The attached script proves the bug also affects add, sub, mul, div for Integer, Float and Complex. It could be used as a test case.",bsdz
4,kthakore,1639,StringHandle should be updated to use StringBuilder internally.,core,,todo,2010-05-15T03:14:07Z,2010-12-01T00:01:29Z,"Hello.

In immutable strings world current implementation of StringHandle is sub-optimal. It should be migrated to use StringBuilder internally instead of String.

-- 
Bacek",bacek
4,mikehh,1275,failure with eq_num op in t/op/comp.t with g++ 4.4.1 --optimized build,testing,,bug,2009-11-16T09:01:02Z,2010-09-20T00:41:12Z,"I switched to Ubuntu 9.10 i386 and eventually got parrot to build with g++ ver 4.4.1 (about two weeks ago) I started getting an error with t/op/comp.t on an optimized build with g++ on i386 - the error did not effect the build without --optimize and the gcc build passes the test both with and without --optimize.  The test also passed with all four options on amd64, both on Ubuntu 9.04 amd64 and Ubuntu 9.10 amd64 (gcc/g++ 4.4.1 and 4.3.4) respectively) - I had upgraded my Ubuntu 9.04 i386 to Ubuntu 9.10 i386 so could no longer test there.  NotFound++ did test on that platform and it passed, however when he installed Ubuntu 9.10 i386 on his laptop he got the same results with g++ and --optimize.

see comments by NotFound and mikehh on TT #1176.

I was working on converting the test to .pir from .pasm when bubaflub++ posted a patch to do this in TT #1269 - I applied this in r42518 - the test is now sub-test 17

I was on amd64 at the time, but when I re-booted to i386 the test still gave a failure with the eq_num op on i386 with an --optimize build with g++. (PASSes on all my other platform/options.)

Specifically the code:
{{{
.sub test_eq_num
    new $P0, 'Float'
    set $P0, -1.2
    new $P1, 'String'
    set $P1, ""-1.2""
    eq_num $P0, $P1, OK
    ok(0, ""not eq_num"")
    .return()
  OK:
    ok(1, ""eq_num"")
.end

}}}
the eq_num $P0, $P1, OK does not take the OK branch

if I change to set P1, ""-1.2000000000"" the test passes (with all options on i386), fewer zeros still fail (more ok).

if I set POW to powl (as per TT #1176) the test also passes (with $P1 as ""-1.2"")

'''Analysis'''

What is happening here is that with g++ 4.4.1 (with --optimize) actually uses higher precision in intermediate code (as allowed by the standard)

On further consideration I decided that although this is related to TT #1176 it is actually a different problem in that as we are not specifying use of long double POW would be set to pow rather than powl in this case.

I have serious doubts as to the validity of using the eq_num op in comparing float to string, certainly when using binary floats as opposed to decimal floats. see [http://speleotrove.com/decimal/]

excuse the excessive verbosity in the post, but I felt explanations were necessary, (and I cut out quite a bit)

We can get the test to pass using the set P1, ""-1.2000000000"" as it also passes with the normally passing tests (at least on i386, will check on amd64 in a bit).
",mikehh
4,NotFound,1996,Function Parrot_ext_try for extenders,embed/extend,,experimental,2011-02-04T14:43:28Z,2011-02-04T14:59:33Z,"I'm going to add the experimental function Parrot_ext_try, to help handling exceptions from extension code.

It takes as parameters an interpreter a function to call, a handler function and a pointer for data.

The main function is called with the interpreter and the data.

The handler function, if not null, is called if an exception is thrown during the main call, passing to it the interpreter, the exception and the data.

The data pointer is opaque, the caller and the functions used can use it for any purpose.
",NotFound
4,NotFound,707,[RFC] StringHandle interface,core,,RFC,2009-05-26T15:30:06Z,2011-01-15T13:11:22Z,"There some points in the StringHandle pmc that needs clarification:

- Read/Write mode: Must it works the same as FileHandle? Several tests use read methods in a StringHanlde opened for writing. IMO will be better to have methods to get/set the string content, use the get_string/set_string/native vtable functions, or both, and have the read methods throw exceptions when not opened for read.

- Mode when reopened without second argument: must use the flags used on the previous open, or use the 'r' default? Several tests assume the second, but works only because of the first issue.
",NotFound
4,nwellnhof,1724,Add getprotobyname to Socket PMCs,core,,patch,2010-08-01T13:15:14Z,2011-08-27T21:50:12Z,"I couldn't see any implementation of getprotobyname which seems like a standard function that should be available. This adds it to Socket PMCs.

I'm not entirely sure this is the correct approach - because normally you'd call this before creating a socket object. For PIR this is OK, but in something like Perl 6 this will create a Socket object to call getprotobyname, then destroy it, then probably create another one straight after.

Anyway, this is the best I could come up with given my extremely limited knowledge of Parrot - please advise!",ocharles
4,particle,1413,Convert planet.parrotcode.org to planet.parrot.org,website,,meta,2010-01-24T00:52:37Z,2011-06-11T14:23:20Z,"Over the past year we've been trying to move all our online activity from http://parrotcode.org to http://parrot.org.  However, our blog aggregator can still be found ''only'' at http://planet.parrotcode.org; http://planet.parrot.org/ gives a Page Load Error.

We should change this.  We should provide a redirect link that will provide a prompt to people to go to the new site.

Thank you very much.

kid51",jkeenan
4,Paul C. Anagnostopoulos,370,Rounding Inf and NaN,core,,bug,2009-02-24T08:52:42Z,2010-09-09T20:31:59Z,"$ ./perl6
> say ceiling(NaN)
-2147483648
> say floor(NaN)
-2147483648
> say floor(Inf)
-2147483648
> say ceiling(Inf)
-2147483648
",dukeleto
4,Paul C. Anagnostopoulos,943,Real counterparts of some trig functions not defined,core,,bug,2009-08-24T08:14:22Z,2010-09-16T23:00:51Z,"The Complex PMC defines cot, acot, coth, etc but they are not defined for real numbers.

All trig/hyperbolic functions that get defined for the Complex PMC should have real counterparts.",dukeleto
4,Paul C. Anagnostopoulos,987,Make breakpoints actually work in parrot_debugger,tools,,bug,2009-09-07T05:52:55Z,2011-03-27T14:05:42Z,"Currently, you can add and delete breakpoints, but they don't actually stop the program flow.

A failing test for this would be a good start.",dukeleto
4,Paul C. Anagnostopoulos,1731,Assumption made about buffer header alignment,core,,bug,2010-08-05T19:28:23Z,2010-08-13T14:19:01Z,"Various memory management routines (e.g., `gc_ms_allocate_buffer_storage`) assume that the size of a buffer header is equal to the size of a pointer. This is probably true throughout the system as it stands, but those same routines take pains not to make that assumption in other places.

Here is a line from the above routine:
{{{
    Buffer_buflen(buffer)   = new_size - sizeof (void *);
}}}
If the size of a pointer is less than the buffer header size, the value stored in `buflen` will be too big. `new_size` includes the entire size of the buffer header, which may include alignment padding in addition to the pointer.
",Paul C. Anagnostopoulos
4,petdance,2201,"This product has only a moose, not a pony",none,,bug,2011-10-25T04:51:41Z,2011-10-25T05:42:43Z,This is a scratch ticket for Andy's testing.,petdance
4,plobsing,132,Can't thaw a Sub (or a PIR subclass of a Sub),core,,bug,2009-01-06T03:52:34Z,2010-05-12T05:48:35Z,"Code:

{{{
.sub main :main

  $P0 = get_class 'Sub'
  $P1 = subclass $P0, 'myProc'

  .local pmc pirC
  pirC = compreg 'PIR'

  .local string code
  code = <<""END_CODE""

.sub bar
  say ""hi""
.end
END_CODE

  .local pmc compiled
  compiled = pirC(code)
  compiled = compiled[0] # just want the first executable sub here.

  compiled() # works

  .local pmc sub
  sub = new 'myProc'
  assign sub, compiled
  sub() # works

  $S0 = freeze sub
  say ""frozen""
  $P2 = thaw $S0
  say ""thawed""
  $P2()
.end
}}}

Output:
{{{
hi
hi
frozen
Unsupported key type in Key.thaw
current instr.: 'main' pc 48 (borked.pir:30)
}}}

I'd expect to be able to thaw this PMC, and then invoke the sub after thaw.
",coke
4,plobsing,1424,Parrot will not parse PIR missing newline at EOF,imcc,,bug,2010-02-06T21:06:48Z,2011-07-18T01:43:49Z,"This script:
{{{
perl -e 'print "".sub foo\n\tsay \""Hello, world\""\n.end\n# Last line""' > x.pir 
}}}

produces a .pir file with no newline at the end. (Vim really WANTS to add a trailing newline, so beware how you look at it.)

You can check with
{{{
od -tx1z x.pir
}}}
which outputs something like:
{{{
0000000 2e 73 75 62 20 66 6f 6f 0a 09 73 61 79 20 22 48  >.sub foo..say ""H<
0000020 65 6c 6c 6f 2c 20 77 6f 72 6c 64 22 0a 2e 65 6e  >ello, world""..en<
0000040 64 0a 23 20 4c 61 73 74 20 6c 69 6e 65           >d.# Last line<
0000055
}}}

At any rate, feeding that input to parrot (v2.0) produces:
{{{
austin@andLinux:~/kakapo$ parrot --output x.pbc x.pir
error:imcc:syntax error, unexpected $undefined, expecting $end (' ')
	in file 'x.pir' line 4
}}}

Appending a newline satisfies the parser.",Austin_Hastings
4,plobsing,1704,Implicit selection of main sub is deprecated.,imcc,3.0,deprecation,2010-07-15T11:41:07Z,2011-08-27T16:59:18Z,"After 2.6 current behaviour of selecting main Sub will be changed. Instead of something like ""First sub in PIR file if there is no :main Sub"" we will use only first Sub marked with "":main"" modifier.

Main reason - enable args validation of 0-arity subs. See also http://irclog.perlgeek.de/parrotsketch/2010-07-13#i_2550626 for discussion.

Eligible in 2.7.",bacek
4,plobsing,1359,[RFC] Merge freeze/thaw with PBC,core,,RFC,2009-12-05T02:13:29Z,2010-01-25T23:21:34Z,"= Problems =

freeze/thaw and PBC are already inter-related:
 * PBC uses freeze/thaw for constants
 * freeze/thaw uses PBC's low level binary IO abstraction

freeze/thaw currently has issues related to subs. Specifically, the opcodes for the sub aren't frozen with the sub. The reason for this is that, when a sub is a constant in a PBC, the opcodes are stored elsewhere and the sub should be an index into the code segment.

Also, PBCs as they currently exist are more or less equivalent to frozen Eval PMCs (in function, not format).

The bottom line is we have 2 formats that are inter-dependant and have overlapping functionality.

= Proposed Solution =

Have freeze/thaw operate on a slight variant of PBC. That is, freeze returns a string containing the contents of a PBC file, and thaw would operate on such strings.

= Required Modifications to PBC =

Minimal. A new segment would need to be added for non-constant objects. For backwards compatibility, we could make the absence of this segment default to creating an Eval PMC.

= Required Modifications to freeze/thaw =

The IMAGE_IO object (or whatever we replace it with) would need to gain the concept of bytecode management. Sub PMCs would be responsible for adding their bytecode to the image on freeze and obtaining their bytecode on thaw. Eval PMCs would no longer manage the bytecode for all contained subs for freeze/thaw as these are now responsible for handling that themselves.

= Benefits =

 * Elimination of duplicated functionality.
 * Sub PMCs frozen/thawed sanely.
 * PBC becomes more flexible from PIR/HLL perspective:
   * compilation: just freeze an Eval PMC.
   * examination: thaw to Eval PMC and poke it
   * load_bytecode is something like:
{{{
.sub 'load_bytecode'
  .param string filename
  $S0 = slurp_file(filename)
  $P0 = thaw $S0
  $P0()
.end
}}}",plobsing
4,plobsing,1421,[RFC] zero length FxA behaviour,none,,RFC,2010-01-28T17:29:45Z,2010-11-24T17:01:03Z,"FixedBooleanArray, FixedStringArray, FixedIntegerArray, and FixedFloatArray do not allow specifying a length of 0, giving a misleading error of ""Fixed${type}Array: can't resize"".

FixedPMCArray ignores being set to zero length, remaining uninitialized.

Allowing for zero lengthed arrays allows code that handles ""0 or more elements"" cases to avoid checking against the zero case. For example:

{{{

.sub 'fixed_ints_upto'
    .param int i
    .local pmc retv
    retv = new ['FixedIntegerArray']
    retv = i
    $I0 = 0
    loop:
         if $I0 >= i goto end_loop:
         retv[$I0] = $I0
         inc $I0
         goto loop
    end_loop:

    .return (retv)
.end

}}}

This will currently fail. To avoid failures, we would have to check for a zero valued argument and handle that case separately.

Zero is a valid length for an array, so I propose that we allow FxAs to be set to zero length (and not be subsequently resizable).

Alternatively, the behaviour could be to ignore setting the length to zero (as is done now in FPA). However, this can be seen as violating the set once property of FxA length.",plobsing
4,plobsing,1323,t/compilers/imcc/syn/clash.t:  Is test complete?,imcc,,todo,2009-11-21T14:46:37Z,2010-10-16T22:47:18Z,"In the file in question we see this:
{{{
173 pir_error_output_like( <<'CODE', <<'OUTPUT', 'new with a native type, no str    ing constant', todo => 'RT #51662 not done yet' );
174 .sub test :main
175         $P1 = new INTVAL
176     print ""never\n""
177     end
178 .end
179 CODE
180 /error:imcc:syntax error, unexpected IDENTIFIER \('INTVAL'\)/
181 OUTPUT
}}}
[http://rt.perl.org/rt3/Ticket/Display.html?id=51662 RT #51662] was resolved, but the 'todo' reference was left in the test file.

This must be tracked in Trac.",jkeenan
4,pmichaud,1308,NQPrx does not vivify globals in all cases,nqp,,bug,2009-11-18T10:12:46Z,2011-10-19T20:15:11Z,"This code:
{{{
module Z;
our $Global;
sub zzz() {
        unless $Global {
                say(""Not set"");
        }
}
INIT {
        zzz();
}

module A;

sub aaa() {
	our $G2;

	unless $G2 {
		say(""Not set"");
	}
}
}}}

generates:
{{{
    get_global $P21, ""$Global""
    unless $P21, unless_20
}}}

for the access code in `sub zzz`. There is no guard for null. But in the access code in `sub aaa` there is this:
{{{
    get_global $P31, ""$G2""
    unless_null $P31, vivify_17
}}}
Apparently the scope isn't being looked up correctly, or something?
",Austin_Hastings
4,pmichaud,1510,NQP-rx doesn't create PMC for string // expressions,nqp,,bug,2010-03-16T03:35:45Z,2011-10-19T21:23:43Z,"{{{
austin@andLinux:~/kakapo$ cat test.nqp

my %hash;
%hash<key> := 1;

#my $x := ~ %hash<key>;
my $y := ~ %hash<key> // 'r';
}}}
Produces:
{{{
austin@andLinux:~/kakapo$ parrot-nqp test.nqp
Null PMC access in set_string_native()
current instr.: '_block11' pc 0 (EVAL_1:6)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc -1 ((unknown file):-1)
called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1303 (compilers/pct/src/PCT/HLLCompiler.pir:707)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1489 (compilers/pct/src/PCT/HLLCompiler.pir:794)
called from Sub 'parrot;NQP;Compiler;main' pc -1 ((unknown file):-1)
austin@andLinux:~/kakapo$ 
}}}
The bad part of the code seems to be:
{{{
    vivify_13:
    set $S21, $P20
    set $P18, $S21
    defined $I23, $P18
    if $I23, default_22
    new $P24, ""String""
    assign $P24, ""r""
    set $P18, $P24
}}}
Note here the use of $P18, which has never been initialized.",Austin_Hastings
4,pmichaud,1512,NQP-rx generates bad access code for non-twigiled attribute,nqp,,bug,2010-03-16T12:28:13Z,2011-02-02T02:16:01Z,"This code, with twigil:
{{{
austin@andLinux:~/kakapo$ cat test.nqp
method foo() {
	has @!attr;

	for my @a {
		say(@!attr);
	}
}
}}}
Generates this pir:
{{{
.annotate ""line"", 5
    find_lex $P24, ""self""
    getattribute $P25, $P24, ""@!attr""
    unless_null $P25, vivify_14
    new $P25, ""ResizablePMCArray""
  vivify_14:
}}}
Whereas this code, sans twigil:
{{{
austin@andLinux:~/kakapo$ cat test.nqp
method foo() {
	has @attr;

	for my @a {
		say(@attr);
	}
}
}}}
Generates this output:
{{{
.annotate ""line"", 5
    getattribute $P24, self, ""@attr""
    $P25 = ""say""($P24)
.annotate ""line"", 4
}}}

Because the sub is a nested block, it has no method declaration and so must do a find-lex lookup to get 'self'. This is not happening.
 
Since the grammar does not support '.' as a twigil, which I think it should, I'm not sure if an attribute with no twigil is or isn't valid. If it's not valid, then the `has @attr` declaration should throw an error. If it's valid, then the access code should work.",Austin_Hastings
4,pmichaud,1631,Exception handler throwing exception in NQP-rx causes segfault,nqp,,bug,2010-05-13T08:57:43Z,2010-07-13T18:52:33Z,"{ pir::die(""""); CATCH { pir::die(""""); } }

The NQP-rx generated exception handler does not call pop_eh in the handler path, which apparently it should, according to bacek.
",sorear
4,pmichaud,88,update pdd26-ast,docs,,todo,2008-12-24T04:38:02Z,2011-05-20T00:35:57Z,Verify that pdd26-ast is up to date with current implementation and design.,pmichaud
2,soh_cah_toa,1589,Move . to the end of the library search path,core,,bug,2010-04-24T05:39:42Z,2011-06-11T01:10:19Z,"Here's a snippet of strace output after I accidentally ran parrot-nqp in a directory with a Regex.pbc file:

{{{
stat64(""./Regex.pbc"", {st_mode=S_IFREG|0644, st_size=100432, ...}) = 0
open(""./Regex.pbc"", O_RDONLY|O_LARGEFILE) = 3
stat64(""./P6object.pbc"", 0xbf9ee9bc)    = -1 ENOENT (No such file or directory)
stat64(""./P6object.pir"", 0xbf9ee9bc)    = -1 ENOENT (No such file or directory)
stat64(""./P6object.pasm"", 0xbf9ee9bc)   = -1 ENOENT (No such file or directory)
stat64(""./P6object.pbc"", 0xbf9ee9bc)    = -1 ENOENT (No such file or directory)
stat64(""/usr/local/./P6object.pbc"", 0xbf9ee9bc) = -1 ENOENT (No such file or directory)
stat64(""/usr/local/./P6object.pir"", 0xbf9ee9bc) = -1 ENOENT (No such file or directory)
stat64(""/usr/local/./P6object.pasm"", 0xbf9ee9bc) = -1 ENOENT (No such file or directory)
stat64(""/usr/local/./P6object.pbc"", 0xbf9ee9bc) = -1 ENOENT (No such file or directory)
stat64(""/usr/local/lib/parrot/2.3.0-devel/library/P6object.pbc"", {st_mode=S_IFREG|0644, st_size=18448, ...}) = 0
stat64(""/usr/local/lib/parrot/2.3.0-devel/library/P6object.pbc"", {st_mode=S_IFREG|0644, st_size=18448, ...}) = 0
stat64(""/usr/local/lib/parrot/2.3.0-devel/library/P6object.pbc"", {st_mode=S_IFREG|0644, st_size=18448, ...}) = 0
stat64(""/usr/local/lib/parrot/2.3.0-devel/library/P6object.pbc"", {st_mode=S_IFREG|0644, st_size=18448, ...}) = 0
open(""/usr/local/lib/parrot/2.3.0-devel/library/P6object.pbc"", O_RDONLY|O_LARGEFILE) = 3
}}}

Parrot has taken Regex.pbc in the current directory before even checking for it in the standard libraries.  The same behavior occurs with all other Parrot-based programs which use installed libraries.  This provides an attack vector against Parrot users:

 1. Wait for Perl6-on-Parrot to hit the big time.
 1. Distribute a shady tarball containing a malicious P6Regex.pbc inside it.
 1. The victim unpacks the tarball and attempts to analyze the contents.
 1. The user runs his Perl 6 based editor.
 1. Rakudo loads Perl6.pbc from the current directory.  My code is now running.

It's probably best to follow Perl 5's example here:

{{{
$ perl -V
...
  @INC:
    /usr/local/lib/perl5/site_perl/5.12.0/i686-linux-thread-multi
    /usr/local/lib/perl5/site_perl/5.12.0
    /usr/local/lib/perl5/5.12.0/i686-linux-thread-multi
    /usr/local/lib/perl5/5.12.0
    .
}}}

With the current directory at the end, installed programs which use only installed libraries will never be tricked into running code in the current directory.  Hopefully it is not too common for installed programs to reference nonexistant libraries.
",sorear
5,soh_cah_toa,2155,Additional README Files in Top-Level Directories,docs,,RFC,2011-07-17T23:02:20Z,2011-08-02T02:43:18Z,"In a recent [http://lists.parrot.org/pipermail/parrot-dev/2011-July/006010.html email] to parrot-dev, kid51 brought up the question of whether each top-level directory could benefit from a small README file describing their purpose.

A few of them already do but I think making this a consistent practice is a great idea. The purpose of these directories is not always self-evident and personally, I still don't know what they all are for. I don't see any immediate disadvantages to this other than a small increase in size. Even so, if the cost of further clarifying our directory structure is just a couple extra kilobytes, I say ""so what.""

The format of each README should be consistent and in plain text. Perhaps something like:

{{{
Directory: [name]
Summary: [short summary]

Description
-----------

[more verbose description]

Subdirectories
--------------

[name - short summary]
[name - short summary]
...
}}}
",soh_cah_toa
7,soh_cah_toa,2093,Remove :base_core modifier from *.ops files,core,,cage,2011-04-12T18:39:19Z,2011-04-12T18:56:24Z,"I've noticed that the {{{:base_core}}} modifier only appears in the *.ops files. ''cotto'' and ''benabik'' seem to think that this is just a leftover historical artifact that no longer has a purpose.

That being said, I think it's safe to remove {{{:base_core}}}.

I will take care of this within the next 2-3 days.",soh_cah_toa
4,Util,919,"On Mac OS X 10.5.8, Configure.pl : lazy symbol binding failed",configure,,bug,2009-08-14T19:41:13Z,2011-06-11T01:11:37Z,"Hi,

I'm running Mac OS X 10.5.8 with the dev tools installed.

I just downloaded parrot 1.4.0, unpacked it into my `~/opt/src` directory,
and ran `perl Configure.pl --prefix=/Users/john/opt`.

Although the configure seemed to succeed, it complained thusly:

{{{
auto::readline -      Does your platform support readline...dyld: lazy symbol binding failed: Symbol not found: _rl_get_keymap
  Referenced from: /Users/john/opt/src/parrot-1.4.0/./test_2640
  Expected in: dynamic lookup

dyld: Symbol not found: _rl_get_keymap
  Referenced from: /Users/john/opt/src/parrot-1.4.0/./test_2640
  Expected in: dynamic lookup

.............done.
}}}

At the end, it reported:

{{{
Okay, we're done!

You can now use `make' to build your Parrot.
After that, you can use `make test' to run the test suite.

Happy Hacking,
        The Parrot Team
}}}

Here is some other info that was in the output from running parrotbug:

{{{
---
osname= darwin
osvers= 9.0
arch=   darwin-thread-multi-2level
cc=     cc
---
Flags:
    category=install
    severity=medium
    ack=no
---
Summary of my parrot 1.4.0 (r0) configuration:
  configdate='Fri Aug 14 19:11:27 2009 GMT'
  Platform:
    osname=darwin, archname=darwin-2level
    jitcapable=0, jitarchname=nojit,
    jitosname=darwin, jitcpuarch=i386
    execcapable=0
    perl=perl
  Compiler:
    cc='/usr/bin/gcc-4.0', ccflags='-fno-common -I/opt/local/include -no-cpp-precomp  -pipe -I/opt/local/include -pipe -fno-common -Wno-long-double  -DHASATTRIBUTE_CONST  -DHASATTRIBUTE_DEPRECATED  -DHASATTRIBUTE_MALLOC  -DHASATTRIBUTE_
NONNULL  -DHASATTRIBUTE_NORETURN  -DHASATTRIBUTE_PURE  -DHASATTRIBUTE_UNUSED  -DHASATTRIBUTE_WARN_UNUSED_RESULT  -falign-functions=16 -fvisibility=hidden -funit-at-a-time -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wcast-ali
gn -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wmissing-b
races -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-include-dirs -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wsw
itch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wvariadic-macros -Wwrite-strings -Wbad-function-cast -Wdeclaration-after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-pr
ototypes -Wnested-externs -Wnonnull',
  Linker and Libraries:
    ld='c++', ldflags='-L/opt/local/lib -L/Users/john/opt/src/parrot-1.4.0/blib/lib',
    cc_ldflags='',
    libs='-lm -lutil -lgmp -lreadline'
  Dynamic Linking:
    share_ext='.dylib', ld_share_flags='-dynamiclib -undefined dynamic_lookup',
    load_ext='.bundle', ld_load_flags='-undefined dynamic_lookup -bundle'
  Types:
    iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
    ptrsize=4, ptr_alignment=1 byteorder=1234, 
    nv=double, numvalsize=8, doublesize=8, longdoublesize=16

---
Environment:
    DYLD_LIBRARY_PATH  (unset)
    HOME =/Users/john
    LANG =en_US.UTF-8
    LANGUAGE  (unset)
    LD_LIBRARY_PATH  (unset)
    LOGDIR  (unset)
    PATH =/opt/local/bin:/opt/local/sbin:/usr/local/mysql/bin:/Users/john/.cabal/bin:/Users/john/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
    SHELL =/bin/bash
}}}
",jgabr
4,Util,1891,"Problems with acosh, asech, atanh and acoth  in Complex PMC",core,2.11,bug,2010-12-14T17:19:30Z,2011-07-21T05:02:56Z,"Hello,

While doing [http://www.google-melange.com/gci/task/show/google/gci2010/parrot_perl_foundations/t129193205977 this GCI task] I had some problems with ""acosh"".

Here is the output of tests that I wrote:
{{{
not ok 529 - acosh of 0-1i
# Have: -0.881374+1.570796i
# Want: 0.881374-1.570796i

not ok 530 - acosh of 0-0.5i
# Have: -0.481212+1.570796i
# Want: 0.481212-1.570796i

not ok 535 - acosh of 2-3i
# Have: -1.983387+1.000144i
# Want: 1.983387-1.000144i

not ok 537 - acosh of -2-3i
# Have: -1.983387+2.141449i
# Want: 1.983387-2.141449i
}}}

The ""want"" values were taken from WolframAlpha (ex [http://www.wolframalpha.com/input/?i=acosh(2-3i)]).

Some other methods that relies on ""acosh"" are also returning a wrong value, like ""asech"".

{{{
not ok 587 - asech of 0.5+0i
# Have: -1.316958+0.000000i
# Want: 1.316958+0.000000i

not ok 593 - asech of 0+0.5i
# Have: -1.443635+1.570796i
# Want: 1.443635-1.570796i

not ok 594 - asech of 0+1i
# Have: -0.881374+1.570796i
# Want: 0.881374-1.570796i

not ok 595 - asech of 0+2i
# Have: -0.481212+1.570796i
# Want: 0.481212-1.570796i

not ok 596 - asech of 2+3i
# Have: -0.231335+1.420411i
# Want: 0.231335-1.420411i

not ok 598 - asech of -2+3i
# Have: -0.231335+1.721182i
# Want: 0.231335-1.721182i
}}}

I also found some errors in  ""atanh"" and ""acoth"":
{{{
not ok 538 - atanh of -2+0i
# Have: -0.549306-1.570796i
# Want: -0.549306+1.570796i

not ok 554 - acoth of -0.5+0i
# Have: -0.549306-1.570796i
# Want: -0.549306+1.570796i
}}}

The tests that I wrote can be found here: https://github.com/fernandobrito/parrot/commits/gci_tests

Environment: Ubuntu 10.10, Parrot 2.10.1 (master branch), Perl 5.10.1 i686-linux-gnu-thread-multi, cc (gcc 4.4), i386, linux",fbrito
1,whiteknight,760,readline_interactive method no longer returns PMCNULL on eof,core,,patch,2009-06-13T13:28:00Z,2011-03-03T17:46:00Z,"Sending EOF to the standard input (typically: hitting Control-G) does not make HLLCompiler end interactive sessions when readline is used.

To reproduce: take your favorite HLL written with HLLCompiler, and a Parrot with readline, and run it without any argument. This should start an interactive session (i.e., you get a prompt for the language), but hitting {{{^G}}} makes HLLCompiler display a new prompt instead of exiting.

This bug has two origins:

* the ""readline_interactive"" method of FileHandle always returns a string (that's because of its type: when it seems to return NULL, it is actually converted to the empty string). On the other hand, HLLCompiler tests if the value returned by ""readline_interactive"" is null to detect EOF: this test is always false... The fix is to test EOF using the ""get_bool"" vtable of FileHandle; and

* the method ""readline_interactive"" never sets the EOF flag when readline is activated.

The attached patch fixes this.",flh
2,whiteknight,1886,set_string_native() not implemented in class 'TclString',none,,bug,2010-12-10T17:31:07Z,2011-10-20T01:53:24Z,"This error has cropped up in the last few months in partcl-nqp. (No changes in partcl, just upgrading parrot was sufficient to gen the error)

In one case, there was a concat operation in our src/Partcl/commands/time.pm ; prefixing the first element with a ~ avoided the error. (but should have been unnecessary.)

There is another location where this error occurs, triggered by the following tcl:

{{{
$ cat error.tcl
for {set i 0} {$i < 2} {set i [expr $i+1]} {puts $i}
$ ./partcl error.tcl
0
1
set_string_native() not implemented in class 'TclString'
    while executing
eval
    (file ""<unknown file>"" line 7)
for
    (file ""<unknown file>"" line 12)
HLL::Compiler::eval
    (file ""<unknown file>"" line 151)
PCT::HLLCompiler::evalfiles
    (file ""<unknown file>"" <unknown line>)
PCT::HLLCompiler::command_line
    (file ""<unknown file>"" <unknown line>)
main
    (file ""<unknown file>"" line 1)
}}}

In eval (src/Partcl/commands/eval.pm) the error is occurring when invoking the sub generated by:

{{{
my &sub := Partcl::Compiler.compile($code);
&sub(); #BOOM
}}}

In any case, TclString should in fact have a set_string_native, inherited from its parent class of String; it's declared in an nqp file as:

{{{
class TclString is String
}}}
",coke
3,whiteknight,1500,API to tell which opcode group an opcode is in,core,,RFC,2010-03-06T03:57:05Z,2011-10-24T14:58:11Z,"I am currently hacking on PL/Parrot and one of the very important features that we need is disallowing certain operations, most notably file I/O. The motivation for this is that you do not want a stored procedure written in PIR to be able to modify the database via disk operations.

I talked with chromatic in #parrot about needing some security subsystem features and he agreed that we need an API for telling if an opcode is in a particular opcode group. This is talked about in PDD18 if you want to get the full background.

For instance, take the open opcode: 
{{{
inline op open(out PMC, in STR, in STR) :filesys_open {
/* etc... */
}
}}}

It is defined to be in the ""filesys_open"" opcode group. Currently there is no way to tell if a certain opcode is in a given group. The information does not seem to make it into op_info_t, but it is in lib/Parrot/OpLib/core.pm . I propose a public C API that will consist of at least these three functions:

{{{ Parrot_sec_opcode_is_in_group(string opcode_name, string group_name) }}}

This function would take an opcode name and opcode group name as argument and return true if the opcode is in the group, false otherwise.

{{{ Parrot_sec_opcodes_in_group(string opcode_group) }}}

This function takes a string argument of an opcode group name and returns a ResizableStringArray containing all opcodes in that group.

{{{ Parrot_sec_groups_containing_opcode(string opcode_name) }}}

This function takes a string argument of an opcode name and returns a ResizableStringArray listing all groups that contain the given opcode name.

Once an API in C is available to accomplish these things, then it should be straight forward to access this information from PIR.

",dukeleto
4,whiteknight,802,freeze opcode segfaults on working bytecode from Rakudo,core,,bug,2009-07-02T15:20:50Z,2011-08-27T16:50:29Z,"The following compiles bytecode from PIR and perl6 source strings and verifies that a subroutine works in both cases. The PIR example can be frozen (and thawed in other tests) but the perl6 example causes freeze to segfault. Tested only on linux/amd64. Fixing this would be assist a project to build a versioned module database for Rakudo (Synopsis 11).
{{{
# freeze-test.pir
# Assumes parrot was installed by Rakudo's Configure --gen-parrot
# - edit the load_bytecode line otherwise.

.sub 'testmain' :main
    .local string testPIRsource
    testPIRsource = <<'    testPIRsource_end'
        .sub test_PIR
            .param string x
            .local string result
            result = 'test PIR '
            result .= x
            .return ( result )
        .end
    testPIRsource_end
    .local pmc PIRcompiler, testPIRbytecode, parrotnamespace, test_PIR
    PIRcompiler = compreg 'PIR' # parrot/docs/pdds/draft/pdd06_pasm.pod
    testPIRbytecode = PIRcompiler( testPIRsource )
    parrotnamespace = get_root_namespace [ 'parrot' ]
    test_PIR = parrotnamespace.'find_sub' ('test_PIR')
    $S0 = test_PIR ( '10 b' ) # execute the generated bytecode
    print $S0
    say ' PIR code compiled, ready to be frozen'

    .local string testP6source
    testP6source = <<'    testP6source_end'
        sub test_P6 ( Str $x ) {
            return ""test P6 $x"";
        }
    testP6source_end
    # the next line assumes rakudo configured with --gen-parrot
    load_bytecode '../perl6.pbc' # adjust directory if different
    .local pmc P6compiler, testP6bytecode, P6namespace, test_P6
    # see similar code in .sub 'eval' in rakudo/src/builtins/control.pir
    P6compiler = compreg 'perl6'
    testP6bytecode = P6compiler.'compile' ( testP6source )
    P6namespace = get_root_namespace [ 'perl6' ]
    test_P6 = P6namespace.'find_sub' ('test_P6')
    $S0 = test_P6 ( '10 c' )
    print $S0
    say ' Perl 6 code compiles, ready to be frozen'

    .local string frozenPIR, filename
    frozenPIR = freeze testPIRbytecode
    filename  = ""/tmp/bytecode_from_PIR.frozen""
    .local pmc filehandle
    filehandle = open filename, ""w""
    print filehandle, frozenPIR
    close filehandle
    $I0 = stat filename, 1 # 1 means get file size
    print $I0
    say ' bytes frozen from PIR'

    .local string frozenP6
# Uncomment the next line to see the problem
#   frozenP6 = freeze testP6bytecode            # segfaults
    filename  = ""/tmp/bytecode_from_P6.frozen""
    filehandle = open filename, ""w""
    print filehandle, frozenP6
    close filehandle
    $I0 = stat filename, 1 # 1 means get file size
    print $I0
    say ' bytes frozen from Perl 6'

.end

# Original problem encountered in:
# http://gitorious.org/parrot-module-lib/main/blobs/master/t/10-make-bytecode.t
}}}",mberends
4,whiteknight,1015,clone_p_p segfaults with self-referential Hash pmc.,core,,bug,2009-09-17T06:11:01Z,2011-02-25T01:36:06Z,"If a complex data structure, built with Hash and Array structures, is self-referencing, running clone_p_p on it will quickly segfault.

{{{
our %Global_hash;

sub bsu() {
	say(""BSU: starting."");
	%Global_hash<key><key2> := 1;
	%Global_hash<key><loop> := %Global_hash;
	
	my %local := %Global_hash;
	
	my $result := Q:PIR {{
		$P0 = find_lex '%local'
		%r = clone $P0
	}};
	
	say(""BSU: returning."");
	return $result;
	
}

bsu();
}}}

The solution here is likely to be involved -- perhaps disabling the GC and using the mark bit to track what has been cloned. But segmentation fault is not a parrot exception, which is what a memory problem should become.

Dukeleto confirms this problem exists on Darwin, and his Linux box.

FYI: I discovered this because PCT clones the symbol table of PAST::Block nodes.",Austin_Hastings
4,whiteknight,1492,Get_class <namespace> confuses NSes that have same final name.,core,,bug,2010-03-03T15:06:09Z,2010-11-21T20:13:19Z,"Having already created a class ""Matcher"", I was trying in NQP to create a related class Mimus::CallSignature::Matcher. (Note the last name.)
 
Far too many hours later, it appears that the get_class op on a namespace apparently returns invalid results when the namespace shares a last name with an already-extant class.

This code, inspired by the `get_parrotclass` method in P6object.pir, looks up (and tries to create, if needed) two classes with different namespace paths but the same class name (last name in the nsp), one called P and the other N::S::P :
{{{
.sub foo :main
	.local pmc class_p
	.local int addr_p

	.local pmc class_nsp
	.local int addr_nsp

	class_p = newclass [ 'P' ]
	addr_p = get_addr class_p
	

	$S0 = 'N::S::P'		# Change to ..Q and it changes
	$P0 = split '::', $S0

	$P1 = get_hll_namespace $P0
	unless null $P1 goto have_ns
	
	die ""Namespace was null""
have_ns:
	
	class_nsp = get_class $P1
	$P2 = class_nsp
	addr_nsp = get_addr class_nsp

	print ""Addr of class 'P' is: ""
	say addr_p

	print ""Addr of 'N::S::P' is: ""
	say addr_nsp

	unless addr_p == addr_nsp goto end
	say ""*** The addrs are the same. I think that's wrong.""

	goto end

got_class:
	say ""Got the class. I didn't see that coming.""
end:
.end

.namespace ['N';'S';'P']

.sub bar :method
	.return (1)
.end


.namespace ['N';'S';'Q']

.sub bar :method
	.return (1)
.end
}}}

The effect of this seems to be that any code which relies on P6object cannot create classes that have the same name.

The workaround is, trivially, to make sure that class names are distinct. Anyone who has ever coded C89 should be okay.
",Austin_Hastings
4,whiteknight,1515,Duplicate named args cause fatal error in subs,none,,bug,2010-03-17T21:18:45Z,2011-01-30T04:45:26Z,"Calling a sub with duplicate named args:
{{{
.sub main :main
	foo( 1 :named('a'), 2 :named('a') )
.end
}}}
triggers an error:
{{{
duplicate named argument in call
current instr.: 'main' pc 0 (test.pir:4)
}}}

Unfortunately, this means that setting defaults in a hash, then flattening the hash together with any explicit named args, is no longer a valid way to handle argument defaulting.
 
Given that, either (1) this is a bug, and duplicate named args should be permitted; or (2) this is the official new way, in which case what is the model for arg-defaulting?
",Austin_Hastings
4,whiteknight,1542,HLLs sometimes leak into loaded modules,core,,bug,2010-04-04T06:29:12Z,2010-11-21T15:53:17Z,"{{{
stefan@stefans:~$ perl6 -e 'pir::load_bytecode(""/usr/local/lib/parrot/2.2.0-devel/languages/nqp/nqp.pbc"")'
Parent isn't a Class.
current instr.: 'parrot;P6metaclass;add_parent' pc 224 (runtime/parrot/library/P6object.pir:232)
called from Sub 'parrot;P6metaclass;register' pc 532 (runtime/parrot/library/P6object.pir:408)
called from Sub 'perl6;PCT;Grammar;onload' pc -1 ((unknown file):-1)
called from Sub 'perl6;PCT;__onload' pc 0 (compilers/pct/PCT.pir:18)
... call repeated 1 times
}}}

I'm not sure what's going on here or how to start debugging it.  Austin thinks that Rakudo is redefining something somewhere, but that wouldn't explain the fact that PCT has somehow become loaded into the perl6 top level namespace.  I suspect a Parrot bug somewhere.
",sorear
4,whiteknight,1833,Incompatible bytecode error lacks file name of offending file,core,,bug,2010-10-19T10:22:09Z,2011-02-09T09:03:14Z,"{{{
PackFile_unpack: This Parrot cannot read bytecode files with version 9.0.

PackFile header failed during unpack
}}}

This error message should include the name of the file that caused this error; otherwise it is very hard to figure out which file caused the problem.

(Happens on amd64 linux, with gcc 4.4.5)",moritz
4,whiteknight,1903,tailcall method invocation pops exception handlers,none,,bug,2010-12-24T16:34:29Z,2011-01-11T15:53:21Z,Tailcalling a function call leaves the exception handlers created for the current frame active. Tailcalling a method invocation does not.,plobsing
4,whiteknight,2048,cmp_pmc vtable acting wonky,embed/extend,,bug,2011-03-12T06:00:12Z,2011-11-20T09:43:35Z,"This commit: https://github.com/parrot/parrot/compare/cmp_pmc

gives this error:

{{{

not ok 63 - Parrot_PMC_cmp_pmc

#   Failed test 'Parrot_PMC_cmp_pmc'
#   at t/src/extend_vtable.t line 1098.
#          got: 'Failed!
# Exception is: type 44 severity 2 message 'Multiple Dispatch: No suitable candidate found for 'cmp_pmc', with signature 'PP->P''
# '
#     expected: '1
# -1
# 0
# Done!
# '
# './t/src/extend_vtable_63' failed with exit code 0

}}}

Anybody know what is going on?",dukeleto
4,whiteknight,2124,Including extend.h without first including parrot.h blows up in Rakudo,embed/extend,,bug,2011-05-26T22:19:49Z,2011-05-26T23:42:02Z,"{{{
15:15:49     @pmichaud | NotFound: http://gist.github.com/994223   # results of including extend.h without first including parrot.h          
}}}

Sample:
{{{
cd src/binder && cc -c -o bind.o -I../../src/pmc -I/home/pmichaud/rakudo/parrot_install/include/3.4.0-devel -I/home/pmichaud/rakudo/parrot_install/include/3.4.0-devel/pmc -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -DHASATTRIBUTE_HOT -DHASATTRIBUTE_COLD -DDISABLE_GC_DEBUG=1 -DNDEBUG -DHAS_GETTEXT -fPIC -falign-functions=16 -funit-at-a-time -fexcess-precision=standard -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wdiv-by-zero -Wenum-compare -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wjump-misses-init -Wlogical-op -Wmissing-braces -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-include-dirs -Wmultichar -Wpacked -Wparentheses -Wpointer-arith -Wpointer-sign -Wreturn-type -Wsequence-point -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wno-unused -Wunknown-pragmas -Wvariadic-macros -Wwrite-strings -Wc++-compat -Wdeclaration-after-statement -Werror=declaration-after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull -Wold-style-definition -Wstrict-prototypes -fvisibility=hidden bind.c
In file included from /home/pmichaud/rakudo/parrot_install/include/3.4.0-devel/parrot/extend.h:19:0,
                 from bind.c:8:
/home/pmichaud/rakudo/parrot_install/include/3.4.0-devel/parrot/interpreter.h:557:34: error: expected ‘)’ before ‘(’ token
In file included from /home/pmichaud/rakudo/parrot_install/include/3.4.0-devel/parrot/extend.h:55:0,
                 from bind.c:8:
/home/pmichaud/rakudo/parrot_install/include/3.4.0-devel/parrot/extend_vtable.h:17:47: error: expected ‘)’ before ‘(’ token
/home/pmichaud/rakudo/parrot_install/include/3.4.0-devel/parrot/extend_vtable.h:18:42: error: expected ‘)’ before ‘(’ token
/home/pmichaud/rakudo/parrot_install/include/3.4.0-devel/parrot/extend_vtable.h:19:46: error: expected ‘)’ before ‘(’ token
/home/pmichaud/rakudo/parrot_install/include/3.4.0-devel/parrot/extend_vtable.h:20:48: error: expected ‘)’ before ‘(’ token
/home/pmichaud/rakudo/parrot_install/include/3.4.0-devel/parrot/extend_vtable.h:21:46: error: expected ‘)’ before ‘(’ token
/home/pmichaud/rakudo/parrot_install/include/3.4.0-devel/parrot/extend_vtable.h:22:43: error: expected ‘)’ before ‘(’ token
/home/pmichaud/rakudo/parrot_install/include/3.4.0-devel/parrot/extend_vtable.h:23:43: error: expected ‘)’ before ‘(’ token
/home/pmichaud/rakudo/parrot_install/include/3.4.0-devel/parrot/extend_vtable.h:24:41: error: expected ‘)’ before ‘(’ token
/home/pmichaud/rakudo/parrot_install/include/3.4.0-devel/parrot/extend_vtable.h:25:52: error: expected ‘)’ before ‘(’ token
}}}",dukeleto
4,whiteknight,2126,Parrot_PMC_morph acting odd,embed/extend,,bug,2011-05-28T18:24:18Z,2011-05-28T18:24:18Z,"The commit here:

https://github.com/parrot/parrot/commit/e8495b86f1c5aec8b050104fdd43f12f96174349

morphs a PMC and then checks the name of it, and it returns ""default"". Is that expected?",dukeleto
4,whiteknight,1697,Remove the open and close opcodes,core,,deprecation,2010-06-29T18:08:26Z,2011-08-23T16:17:25Z,"The open and close opcodes are redundant and since the IO ops became dynops, have subtle problems, as found by PL/Parrot:

{{{ arg count mismatch: op #1119 'open' needs 17820 given 3 }}}

http://groups.google.com/group/parrot-dev/browse_thread/thread/d99dfeabda257cf1
http://groups.google.com/group/parrot-dev/browse_thread/thread/b8f6e3f2e0f285ff

Uses of the open/close opcode can easily be changed to use the open/close methods on the File or FileHandle PMC.


",dukeleto
4,whiteknight,1800,"[DEPRECATED] Current behaviour of ""timely destruction"" is deprecated.",GC,,deprecation,2010-09-23T07:37:59Z,2010-11-24T16:57:07Z,"Current behaviour of ""timely destruction"" of PMC is proven to be unreliable and deprecated.",bacek
4,whiteknight,1868,[DEPRECATED] PIR compiler availability,core,2.11,deprecation,2010-11-23T22:05:33Z,2011-05-22T01:39:15Z,"PIR as a language is currently always available in parrot. This privileged status is part of why PIR is a growing pain for Parrot (usually experienced as hatred for IMCC).

PIR will become no different to parrot than any language. It will not be baked-in to libparrot and be always available. In stead, PIR will become a separately loadable component.

PIR will remain available to Parrot programs, however it will require loading before use (via the load_language instruction).

A separate executable (tentatively named ""parrot-imcc"") will be made available for compiling and running PIR programs as the main parrot executable does today.",plobsing
4,whiteknight,1870,Move OpenGL Bindings to their own project/repo,library,,deprecation,2010-11-24T14:00:20Z,2011-07-09T11:09:11Z,"We currently have bindings to OpenGL included in the Parrot master repository. I suggest that these should be moved out into their own project. This could give these bindings more visibility, and help them to be treated like any other normal ecosystem project.

I suggested this idea yesterday at #parrotsketch and received very mild support for the idea. I'm opening this ticket as an RFC in an attempt to build more support for it. If we do decide to go this route we can change this to a deprecation and begin the process of moving the bindings out of the repo.",whiteknight
4,whiteknight,1892,[DEPRECATED] Complex PMC,core,2.11,deprecation,2010-12-14T18:16:23Z,2011-08-27T17:47:02Z,"This PMC is large and neglected. It's implementation is inefficient for the sole purpose of supporting behaviours that are unintuitive. It's code coverage is poor, and some of its operations return incorrect results.

These problems prevent it from being useful to users, so it will be removed.

Users that care about complex math are encouraged to implent their own alternative and make it public for code sharing and cooperation. An implementation by someone who cares about complex math stands a much better chance of being correct and well supported.",plobsing
4,whiteknight,1969,Deprecate Eval PMC,core,,deprecation,2011-01-15T16:00:00Z,2011-10-24T14:45:17Z,"We should deprecate this PMC. compregs should return the packfile PMC, or maybe the Sub PMC, but not Eval.",whiteknight
4,whiteknight,2186,Add 6model to Parrot,core,,experimental,2011-08-27T17:13:06Z,2011-08-27T17:13:13Z,I've started the whiteknight/6model branch to start moving 6model from NQP to Parrot. When it is merged 6model will be considered experimental until it is fully integrated into Parrot core.,whiteknight
4,whiteknight,850,Handle loadlib and libraries with '.' in the name,library,,patch,2009-07-18T14:43:12Z,2010-01-25T23:02:41Z,"This ticket originally appeared in RT on Sep 23 2005 as [http://rt.perl.org/rt3/Ticket/Display.html?id=37258 RT #32758], a submission by Ross McFarland.  It has not been resolved.  chromatic looked at it in June 2008, noting that the latest version of the patch submitted by Ross did not synch up properly with our source code.

The original ticket cited [http://www.nntp.perl.org/group/perl.perl6.internals/2005/09/msg30979.html an extensive discussion on the old perl6-internals list].

This ticket was mentioned by [http://wknight8111.blogspot.com/2009/07/parrot4newbies-platforms.html Whiteknight in his blog], also available on [http://planet.parrotcode.org/ planet.parrotcode (July 17)].

I am moving this ticket to Trac.  I am attaching what I think was the last version of the patch submitted in the RT.

Could someone -- particularly someone on Win32 -- take a look at this and determine:

1.  Is there still a problem needing resolution?

2.  Can the patch be reworked to provide a solution?

Thank you very much.

kid51",jkeenan
4,whiteknight,649,Should parrot_config report separate inst_ and build variables?,install,,RFC,2009-05-08T12:42:22Z,2010-11-24T03:16:32Z,"Some discussion of this topic is on the parrot-dev mailling list, starting at: [http://lists.parrot.org/pipermail/parrot-dev/2009-April/002158.html]
(The thread continues into the beginning of the next month, here at
[http://lists.parrot.org/pipermail/parrot-dev/2009-May/002162.html] and [http://lists.parrot.org/pipermail/parrot-dev/2009-May/002172.html].)

I have tentatively assigned this ticket a milestone of 1.4, the next ""supported"" release.  If indeed version 1.4 is to be packaged and widely distributed, then it would be nice to clear up such issues beforehand.",doughera
4,whiteknight,1356,[TODO] add method FixedStringArray.sort(),core,,RFC,2009-12-03T17:54:22Z,2011-05-26T23:54:21Z,"Add the method sort in the FixedStringArray PMC.

Currently, the method sort is only implemented in FixedPMCArray (and inherited by ResizablePMCArray).

This method uses the C function Parrot_quicksort (in src/utils.c) which handles only PMC and not STRING.",fperrad
4,whiteknight,2133,src/extend.c Review,embed/extend,,RFC,2011-06-13T00:57:37Z,2011-06-13T23:29:20Z,"The functions in extend.c and extend_vtable.c use the PARROT_CALLIN_START and PARROT_CALLIN_END macros to ensure the stacktop value is set for proper GC operation. This is unnecessary for two reasons:

1) We have an embedding API, and a clear distinction between embedding and extending situations. In an extending situation, the stacktop should always be set.

2) The functions in extend.c and extend_vtable.c represent only a small subset of what we currently consider the ""extending API"". Many extension libraries use other subsystem API functions directly, and some extension libraries never use any of the functions defined in extend.c or extend_vtable.c, which means those libraries would never see this protection (and they aren't any worse off for it).

If those two macros go away (And I suggest they should), there are a few functions in extend.c which can go away because they are nothing but wrappers around other functions:

 - Parrot_PMC_new (Parrot_pmc_new)
 - Parrot_free_cstring (Parrot_str_free_cstring)
 - Parrot_register_pmc and Parrot_unregister_pmc
 - Parrot_register_string and Parrot_unregister_string

Also, there are a few other functions which need to be re-considered:

 - Parrot_get_*reg and Parrot_set_*reg (These functions should take a PMC * for the context, because the *_REG macros are going to read from the current context, which in an extending or NCI context is likely to be worthless. Also, these functions don't do any bounds-checking)
 - All the Parrot_printf-related functions. We have similar functions in src/utils.c and elsewhere which integrate properly with the IO and String subsystems
 - Parrot_new_string (Should probably be moved to src/string/api.c, because it's just a wrapper around Parrot_str_new_init with some logic to lookup encodings by name)
 
Also, it would be very good if we had an ""official"" definition for what our extending API is. Is it, as is the de facto definition, the sum of the individual subsystem APIs, or is it something distinct?",whiteknight
4,whiteknight,567,pdd31-hll interop,hll_interop,2.6,roadmap,2009-04-21T13:30:37Z,2010-11-22T15:51:46Z,From https://trac.parrot.org/parrot/wiki/ParrotRoadmap.,coke
4,whiteknight,568,hll interop,hll_interop,2.6,roadmap,2009-04-21T13:31:01Z,2010-11-22T15:51:51Z,From https://trac.parrot.org/parrot/wiki/ParrotRoadmap.,coke
4,whiteknight,955,need ability to create tempfile from PIR,testing,,todo,2009-08-28T18:05:43Z,2011-07-07T19:29:50Z,"to fully convert tests from Perl to PIR, we need a PIR-level analog to:

{{{
    use Parrot::Test::Util 'create_tempfile';
}}}

... I'm not sure if we can automatically delete; that would be nice, but a manual deletion at program exit is sufficient.",coke
4,whiteknight,1223,Parrot_find_name_op() should walk up the scopes,core,,todo,2009-11-07T14:08:05Z,2011-07-06T02:27:18Z,"In src/global.c:Parrot_find_name_op() there is the todo item:

TODO - THIS IS BROKEN - it doesn't walk up the scopes yet - TODO


Previously tracked in RT#46171.",kjs
4,whiteknight,1284,Integer PMC missing math methods,core,,todo,2009-11-17T02:58:11Z,2011-05-16T16:58:13Z,"IMO, this code:

{{{
.sub main
  $P1 = box 1.0
  $N1 = $P1.'exp'()
  say $N1
  $P1 = box 1
  $N1 = $P1.'exp'()
  say $N1
.end
}}}

should print 
2.71828182845905
2.71828182845905

... but it dies with:

{{{
2.71828182845905
Method 'exp' not found for invocant of class 'Integer'
}}}

Clearly, exp isn't defined on Integer, but IMO, all the math methods defined on Float should be defined on Integer. (otherwise, given an arbitrary numeric PMC, we have to jump through hoops.

(Alternatively, we can remove these methods from the Float PMC and rely on the opcodes.)

This becomes even more confusing when you take in the morphing of the core types - a PMC that was a Float can morph into an Integer which is then unable to invoke the various methods.

This issue was originally opened as http://rt.perl.org/rt3/Ticket/Display.html?id=38896",coke
4,whiteknight,1650,Parrot needs Date/DateTime Object,none,,todo,2010-05-20T15:40:52Z,2011-11-23T19:05:37Z,"PL/Parrot would like to have a Date and DateTime object. This would be similar to http://github.com/moritz/Date but implemented as PMC or dynpmc, probably in PIR.",dukeleto
5,whiteknight,277,revive examples/c/test_main,testing,,bug,2009-02-06T07:14:47Z,2010-11-22T20:29:25Z,"Attached patch makes examples/c/test_main.c work again.

It is a useful example for 
  make exec EXEC=examples/c/test_main
So I also added $(EXEC).o as convenience dependency for make exec

",rurban
5,whiteknight,676,Fix namespace pollution,core,,cage,2009-05-17T05:16:07Z,2011-01-15T14:17:27Z,"This is the trac equivalent of RTs #40059 and #40060.

There are many global symbols we're exporting which don't have a ""Parrot_"" prefix.  This list might vary a bit depending on OS and platform, but I'll attach my current list.  By my count, there are currently 182 functions and 1 variable (PMCNULL) exported by default.

I think the idea is that these functions should be renamed from ""funcname"" to ""Parrot_funcname"", and some #defines should be left behind (inside an #ifdef PARROT_IN_CORE) so we don't need to fix up all the callers (and therefore, don't need a deprecation cycle).

I think it would be a good idea to make headerizer do this for us.
",Infinoid
5,whiteknight,1754,The Scalar PMC,core,,deprecation,2010-08-23T01:00:14Z,2011-08-17T02:10:33Z,"The Scalar PMC is quite confusing. Why do some scalars inherit from it and others don't? What exactly does it provide? For example, it appears to be the only PMC providing logical_not. Why does it mean to `provide scalar` and why does PDD17 say that Foo is the only PMC to do it?

Perhaps the Scalar PMC should be eliminated, or perhaps it should be refactored with the Default class. At least it should be clearly documented.",Paul C. Anagnostopoulos
5,whiteknight,67,Allow user to specify maximum size of GC allocation on command line,core,,feature,2008-12-19T00:59:33Z,2011-05-19T23:14:40Z,We should have a command line option for parrot that allows us to specify the maximum amount of memory the GC is allowed to allocate,coke
5,whiteknight,1448,Modify `throw` opcode to pass through pre-configured resume continuation,core,,RFC,2010-02-16T01:10:15Z,2011-10-24T12:49:43Z,"Presently, the throw opcode creates and sets a resume continuation on the exception being thrown. 

Since 'resume' is an attribute of the Exception, throw should check first for a preconfigured continuation, and if one exists should preserve it.

(Of course, if unset it should continue to do what it does.)",Austin_Hastings
5,whiteknight,858,HLL exception handling,core,,todo,2009-07-20T01:52:53Z,2011-01-10T14:45:48Z,"This TT replaces two tickets originally opened in the RT system:  [http://rt.perl.org/rt3/Ticket/Display.html?id=36261 HLL exception handling] and [http://rt.perl.org/rt3/Ticket/Display.html?id=47966 pdd23 doesn't list exception;death as a standard exception].  I am combining the two and moving them to Trac at Tene's suggestion.

Original description (RT 36261) by Coke (probably from an older TODO file):[[BR]]
'''Document how HLL languages can implement their own exception hierarchy, and perhaps define how they can have parrot reformat their exception output for them.'''

Original description (RT 49766) by pmichaud:[[BR]]
'''In the list of ""Standard Parrot Exceptions"" in pdd23, there's no item given for ""exception;death"" even though it's mentioned as part of the ""die"" opcode earlier in the text.  The same is true for the ""exception;exit"" type thrown by the exit opcode.  Also, ""die"" and ""exit"" aren't listed in the ""Opcodes that Throw Exceptions"" section a bit later in pdd23.'''

In the latter RT, Klaus-Jan Stol subsequently contributed a documentation patch, but Patrick Michaud continued:

'''... how exactly does one use `exception;death`, `exception;exit`, and the other exception types from PIR? I see them mentioned throughout pdd23, but I've never actually seen an example of how these constants (are they constants?) might appear in actual code, whether it's PIR, C, or otherwise.  The only ""types"" I'm aware of for exceptions are the severity values and exception type values in ''include/parrot/exceptions.h'' and ''runtime/parrot/include/except_*.pasm'', and none of these seem to have any real correspondence to the ""exception types"" given in pdd23.

Let's see if we can make some progress on these issues in the context of this ticket.

Thank you very much.

kid51",jkeenan
5,whiteknight,974,Mark publicly exposed functions in src/call/context.c with PARROT_EXPORT tag,core,,todo,2009-09-03T12:24:32Z,2011-05-22T01:43:19Z,"Hello.

There is some functions in src/call/context.c which marked as PARROT_EXPORT but shouldn't be exposed as PARROT_API. For example Parrot_pcc_get_context_struct must not be in public API, etc. Functions exposed as public should be marked as PUBLIC_API to avoid and confusion between internals and exposed API for 3rd party developers.

-- 
Bace",bacek
7,whiteknight,560,"When we can't find a library, we shouldn't silently continue and give weird errors later",core,,todo,2009-04-17T09:47:54Z,2011-07-09T11:24:11Z,"In particular, I'd argue that we should quit with an error, and show the path we searched.  ",wayland
4,Yuki`N,1282,OS.cwd returns platform specific slashes...,core,,todo,2009-11-17T02:34:48Z,2011-11-26T01:56:12Z,"... but some languages need a way to get agnostic slashes. Rather than have every HLL implement this, there should be some way to canonicalize the path, and a way to get the platform-specific path. (This will allow hlls to pick whichever method they prefer.)

I don't particularly care about the implementation, as long as I can make

{{{
C:\Tcl\bin>tclsh
% puts [pwd]
C:/Tcl/bin
}}}

work.

This issue originally opened as http://rt.perl.org/rt3/Ticket/Display.html?id=39853",coke
