HTTP/1.1 -1 Read error in cache disk data: SuccessContent-Type: application/rss+xml; charset="utf-8" Last-Modified: Sat, 22 Jan 2022 02:38:33 GMT Content-length: 71461 Connection: Close Proxy-Connection: Close X-Cache: HIT from web1.osuosl.org Server: ProxyTrack 0.5 (HTTrack 3.49.2) Parrot: {8} Active Tickets, Mine first http://trac.parrot.org/parrot/report/8 Trac Report - * List all active tickets by priority. * Show all tickets owned by the logged in user in a group first. en-us Parrot http://trac.parrot.org/parrot/chrome/site/parrot_logo.png http://trac.parrot.org/parrot/report/8 Trac v0.11.7 #592: Add documentation for parrot_debugger Tue, 28 Apr 2009 21:03:28 GMT Sun, 27 Mar 2011 14:14:19 GMT <p> Add documentation for the PIR debugger, 'parrot_debugger'. We need more examples. </p> http://trac.parrot.org/parrot/ticket/592 http://trac.parrot.org/parrot/ticket/592 Report #1328: announce next release when announcing current release Mon, 23 Nov 2009 15:28:05 GMT Mon, 23 Nov 2009 15:28:05 GMT <p> Seen on the latest perl 5.11 announcement: </p> <pre class="wiki">Jesse Vincent or a delegate will release Perl 5.11.3 on December 20, 2009. Ricardo Signes will release Perl 5.11.4 on January 20, 2010. Steve Hay will release Perl 5.11.5 on February 20, 2010. </pre><p> We should crib this from them and put it in our release notes, make it part of the release process to insure we have at least the next 2 or 3 releases assigned. </p> http://trac.parrot.org/parrot/ticket/1328 http://trac.parrot.org/parrot/ticket/1328 Report #88: update pdd26-ast Wed, 24 Dec 2008 04:38:02 GMT Fri, 20 May 2011 00:35:57 GMT <p> Verify that pdd26-ast is up to date with current implementation and design. </p> http://trac.parrot.org/parrot/ticket/88 http://trac.parrot.org/parrot/ticket/88 Report #624: pluggable everything Wed, 29 Apr 2009 00:19:49 GMT Wed, 04 Jan 2012 10:40:43 GMT <p> 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. </p> http://trac.parrot.org/parrot/ticket/624 http://trac.parrot.org/parrot/ticket/624 Report #1161: pdump - Dumping constants shouldn't unpack the constants Fri, 30 Oct 2009 00:55:58 GMT Fri, 25 Feb 2011 03:35:57 GMT <p> Dumping constants shouldn't unpack the constants, but just print out the segment. </p> <p> (from the TODO file) </p> http://trac.parrot.org/parrot/ticket/1161 http://trac.parrot.org/parrot/ticket/1161 Report #1299: create tests for Config/JSON.pbc Tue, 17 Nov 2009 16:06:58 GMT Tue, 17 Nov 2009 16:06:58 GMT <p> Config/JSON was added in '07 without tests in response to <a class="ext-link" href="http://rt.perl.org/rt3/Ticket/Display.html?id=41870"><span class="icon"> </span>http://rt.perl.org/rt3/Ticket/Display.html?id=41870</a>. </p> <p> Tests are required. </p> http://trac.parrot.org/parrot/ticket/1299 http://trac.parrot.org/parrot/ticket/1299 Report #1196: 'parrot foo' automatically finds and invokes foo.pbc Thu, 05 Nov 2009 05:26:56 GMT Fri, 25 Feb 2011 03:27:02 GMT <p> I just recently committed examples/sdl/blue_rect.pl as an example of exercising the SDL library using NQP. At the beginning of the file the instructions read: </p> <p> To run this file, execute the following command from the Parrot directory: </p> <p> $ ./parrot compilers/nqp/nqp.pbc examples/sdl/blue_rect.pl </p> <p> Typing in that pathname is a bit of a pain -- what I'd really like to be able to say is </p> <p> $ ./parrot nqp examples/sdl/blue_rect.pl </p> <p> and then since parrot can't immediately find anything called 'nqp' to execute, it looks for nqp.pbc in a standard location or locations and invokes that. Similarly </p> <p> $ ./parrot perl6 blue_rect.pl $ ./parrot tgc --output=gen.pir PASTGrammar.tg $ ./parrot abc $ ./parrot tcl xyz.tcl $ ./parrot pynie hello.py etc. </p> <p> Before we get too far, let me point out what I'm *not* asking for. Specifically, I'm *not* asking for parrot to automatically select an appropriate compiler based on a file's signature or magic, as discussed in RT<a class="missing ticket">#32374</a>. In other words, I'm *not* asking that </p> <p> $ ./parrot examples/sdl/blue_rect.pl </p> <p> be able to automatically determine an appropriate compiler and invoke it on the script. While this is a very worthy and important goal, at the moment there seem to be so many issues around "how does Parrot register compilers and figure out which one to use" that I fear it will be a while before this gets implemented. I want something sooner than that. </p> <p> I'm also explicitly *not* asking to try to handle or resolve things based on Unix shebang lines, so that a file starting with </p> <p> #!/path/to/parrot nqp </p> <p> will automatically be executed with nqp. Again, it's something we will eventually want to consider, but given the vagaries of dealing with shebangs in so many different languages and platforms it's not what I'm aiming to get from this ticket. </p> <p> All I'm really looking is to be able to place the .pbc file for a compiler or other application into a standard location where it can be invoked from Parrot without having to give a complete path to the .pbc file. </p> <p> This could also have the benefit of simplifying Makefiles as well. For example, when I moved nqp from languages/ to compilers/ , I had to change the Makefile from </p> <p> $(PARROT) $(PARROT)/languages/nqp/nqp.pbc .... </p> <p> to </p> <p> $(PARROT) $(PARROT)/compilers/nqp/nqp.pbc ... </p> <p> While it was easy to do for this one case -- imagine if we had 10 or 20 applications that were using nqp as part of the build process. With the approach proposed here, the Makefile can have </p> <p> $(PARROT) nqp ... </p> <p> and it all just works. </p> <p> I would also be willing to accept an option-based version of this, such as (pick an appropriate option name or letter): </p> <p> $ ./parrot --prog=nqp blue_rect.pl </p> <p> Comments, suggestions, and (most importantly) implementations welcomed. Thanks, </p> <p> Pm </p> http://trac.parrot.org/parrot/ticket/1196 http://trac.parrot.org/parrot/ticket/1196 Report #1165: need ability to dispatch to parent's method or vtable from PIR Fri, 30 Oct 2009 17:25:29 GMT Mon, 14 Feb 2011 01:58:17 GMT <p> 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. </p> <p> you need to know the name of the ancestor that implements the vtable (this isn't always your direct parent.) </p> <p> that ancestor MUST be a PMC (not another class.) </p> <p> 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. </p> <p> perhaps: </p> <pre class="wiki"># 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 </pre><p> 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.) </p> http://trac.parrot.org/parrot/ticket/1165 http://trac.parrot.org/parrot/ticket/1165 Report #1525: improved NCI/FFI Mon, 22 Mar 2010 22:28:06 GMT Tue, 06 Apr 2010 21:45:37 GMT <p> The existing interface to and implementation of NCI needs refinement. See NCITasklist </p> <p> This task does not depend on Lorito, but design and implementation should take the future of Lorito into consideration. </p> http://trac.parrot.org/parrot/ticket/1525 http://trac.parrot.org/parrot/ticket/1525 Report #622: serialize/resumable execution Wed, 29 Apr 2009 00:17:35 GMT Sat, 27 Aug 2011 17:16:56 GMT <p> A wishlist feature for being able to save off the entire state of a currently executing interpreter and resume it later (or on a different machine). </p> http://trac.parrot.org/parrot/ticket/622 http://trac.parrot.org/parrot/ticket/622 Report #955: need ability to create tempfile from PIR Fri, 28 Aug 2009 18:05:43 GMT Thu, 07 Jul 2011 19:29:50 GMT <p> to fully convert tests from Perl to PIR, we need a PIR-level analog to: </p> <pre class="wiki"> use Parrot::Test::Util 'create_tempfile'; </pre><p> ... I'm not sure if we can automatically delete; that would be nice, but a manual deletion at program exit is sufficient. </p> http://trac.parrot.org/parrot/ticket/955 http://trac.parrot.org/parrot/ticket/955 Report #1155: dynext - dll versioning Wed, 28 Oct 2009 03:12:47 GMT Wed, 28 Oct 2009 03:12:47 GMT <p> Thanks to the Windows DLL Hell L&lt;<a class="ext-link" href="http://en.wikipedia.org/wiki/DLL_hell"><span class="icon"> </span>http://en.wikipedia.org/wiki/DLL_hell</a>&gt; and the impossibility of file hardlinks, windows dll names are hopefully versioned, so either the loadlib function or the various pir's needs more logic for maintainance convenience. </p> <p> Keep the lib_paths and share_ext search, add more name munging for special platforms. </p> <p> Either 1) add the version to each loadlib call, and stem the version from POSIX versions within get_path(). </p> <p> loadlib lib, 'libSDL-1.2.so.0' </p> <p> =&gt; try: libSDL-1.2.so.0, libSDL-1.2.so </p> <p> stemmed: libSDL.so on WIN32: SDL-1.2.dll, SDL.dll on cygwin: cygSDL-1.2.dll, cygSDL.dll </p> <p> Maybe also detect the "-1.2.so.0" and convert it to "-1.2.0.dll" </p> <p> 2) add an optional version argument to loadlib. (preferred) </p> <p> loadlib lib, 'SDL', '1.2.0' </p> <p> =&gt; Try: first always prefix with "lib" libSDL-1.2.0.so, libSDL-1.2.so.0, libSDL-1.2.so, libSDL.so other rules stay as they are. (lib_paths + share_ext) on WIN32: no lib prefix and try versions. SDL-1-2-0.dll, SDL-1-2.dll, SDL-1.2.0.dll, SDL-1.2.dll, SDL.dll on cygwin: cyg prefix and try versions with '.' and '-'. cygSDL-1.2.dll, cygSDL-1.2.0.dll, cygSDL-1-2-0.dll, cygSDL-1-2.dll </p> <p> All the pir's for the latest packaged libraries are fixed with RT<a class="missing ticket">#51328</a>. </p> <p> RT<a class="missing ticket">#51328</a> also applies the addional lib =&gt; cyg dll logic, but does not help with versioned dll's, as for ncurses and SDL most prominently. </p> <p> Examples what we want to avoid: </p> <p> loadlib $P1, 'libform' +if $P1 goto has_lib +loadlib $P1, 'cygform-8' +has_lib: </p> <p> loadlib $P1, 'libncurses' +if $P1 goto has_lib1 +loadlib $P1, 'cygncurses-8' +has_lib1: </p> <p> # third try loadlib libsdl, 'libSDL-1.2.so.0' </p> <p> + loadlib libsdl, 'cygSDL-1-2-0' + $I0 = typeof libsdl + if $I0 != .Undef goto OK </p> <p> loadlib image_lib, 'libSDL_image-1.2.so.0' $I0 = typeof image_lib if $I0 != .Undef goto OK_HINT2 </p> <p> + loadlib image_lib, 'cygSDL_image-1-2-0' + $I0 = typeof image_lib + if $I0 != .Undef goto OK + </p> <p> See also other ffi's, such as cffi, how they do deal or not with this problem. Years ago I wrote an overview at <a class="ext-link" href="http://autocad.xarch.at/lisp/ffis.html"><span class="icon"> </span>http://autocad.xarch.at/lisp/ffis.html</a> -- Reini Urban <a class="ext-link" href="http://phpwiki.org/"><span class="icon"> </span>http://phpwiki.org/</a> <a class="ext-link" href="http://murbreak.at/"><span class="icon"> </span>http://murbreak.at/</a> <a class="ext-link" href="http://helsinki.at/"><span class="icon"> </span>http://helsinki.at/</a> <a class="ext-link" href="http://spacemovie.mur.at/"><span class="icon"> </span>http://spacemovie.mur.at/</a> </p> http://trac.parrot.org/parrot/ticket/1155 http://trac.parrot.org/parrot/ticket/1155 Report #1158: t/op/01-parse_ops.t: figure out how to test parsing of pmc constant parameters Wed, 28 Oct 2009 14:54:58 GMT Fri, 25 Feb 2011 03:43:10 GMT <p> r13601 added a test to check parsing of every parrot opcode. but those that accept pmc constants are skipped, as i haven't figured out how to test them yet. </p> <p> see t/op/01-parse_ops.t ~jerry </p> http://trac.parrot.org/parrot/ticket/1158 http://trac.parrot.org/parrot/ticket/1158 Report #1197: Need some way to copy/rename files from parrot. Thu, 05 Nov 2009 05:34:11 GMT Sat, 07 Nov 2009 03:09:54 GMT <p> This was originally posted as "OS.pmc - file copy" in <a class="ext-link" href="http://rt.perl.org/rt3/Ticket/Display.html?id=38146"><span class="icon"> </span>http://rt.perl.org/rt3/Ticket/Display.html?id=38146</a> </p> <p> We need some way to copy files, whether opcode, pmc method, PIR library... </p> <p> A lot of discussion occurred on the original ticket that I can't easily summarize. No consensus was reached. Features still needs to be added somewhere. </p> http://trac.parrot.org/parrot/ticket/1197 http://trac.parrot.org/parrot/ticket/1197 Report #1332: change get_string on FPA, RPA (et al?) Wed, 25 Nov 2009 04:27:53 GMT Fri, 14 Jan 2011 03:53:59 GMT <p> RPA inherits the get_string vtable from its parent, FPA, which says: </p> <pre class="wiki">Returns the number of elements in the array as a Parrot string. (??? -leo) </pre><p> ??? indeed - why doesn't this return something more useful like, e.g.: join(" ",@foo) ? </p> <p> Anyone like the current functionality, or agree with the proposal? </p> http://trac.parrot.org/parrot/ticket/1332 http://trac.parrot.org/parrot/ticket/1332 Report #1201: Parrot::Pmc2c::Emitter line # error Thu, 05 Nov 2009 05:49:16 GMT Fri, 25 Feb 2011 03:16:28 GMT <p> New ticket opened from comment on list in thread 'Re: Warnings on Solaris, Pmc2c usage/design bug', from Andrew Johnson. </p> <hr /> <p> BTW, there is a fundamental problem with this very common usage of a Parrot::Pmc2c::Emitter: </p> <p> $e-&gt;emit( &lt;&lt;"END", <span class="underline">FILE</span>, <span class="underline">LINE</span> + 1 ); ... code ... END </p> <p> In the above usage, <span class="underline">LINE</span> returns the line number of the line containing the "END" marker, not that of the line containing the "emit" call, so the #line directive it emits points to the wrong place in the source file. </p> http://trac.parrot.org/parrot/ticket/1201 http://trac.parrot.org/parrot/ticket/1201 Report #1290: Produce Single PBC from Multiple PIR Files with -o Tue, 17 Nov 2009 04:10:49 GMT Mon, 23 May 2011 19:23:43 GMT <p> After discussing the idea with Allison, we both believe that Parrot should be able to produce a single PBC file from a command like: </p> <p> parrot -o all_files.pbc file1.pir file2.pir ... filen.pir </p> <p> -- c </p> http://trac.parrot.org/parrot/ticket/1290 http://trac.parrot.org/parrot/ticket/1290 Report #508: JSON libraries should be renamed to something less confusing Thu, 26 Mar 2009 21:50:51 GMT Mon, 10 May 2010 13:19:50 GMT <p> There are three JSON.pbc files currently:- </p> <p> * compilers/json/JSON.pbc - for reading JSON. * library/JSON.pbc - for writing JSON. * library/Config/JSON.pbc for reading and writing config files containing JSON. </p> <p> The supplied patch renames the purely read/write ones to library/JSONReader.pbc and library/JSONWriter.pbc. </p> <p> However, what this patch misses is leaving a stub PBCs to manage a proper deprecation cycle. </p> http://trac.parrot.org/parrot/ticket/508 http://trac.parrot.org/parrot/ticket/508 Report #1173: NCI segfaults with null pcc_params_signature Sun, 01 Nov 2009 16:49:45 GMT Tue, 23 Aug 2011 16:19:52 GMT <p> changes in r32203 cause mod_parrot to segfault, as the param signature is an uninitialized string. specifically, the pcc_params_signature NCI attribute is null. not sure if this corresponds to a specific parrot test... </p> <p> creating the signature as a constant string appears to cause this problem, as removing PObj_constant_FLAG from src/pmc/nci.pmc:82 "fixes" the issue, though that's most certainly not a solution. </p> <p> chromatic thinks we need more COW: "My theory is that the JIT STRING conversion needs a Parrot_make_COW_reference." </p> <p> tewk has a workaround: "short-term comment tools/build/nativecall.pl:308 to disable jitted NCI" </p> <p> backtrace is included, now with more stack smashing! </p> <pre class="wiki">Program received signal SIGSEGV, Segmentation fault. 0x40798304 in Parrot_init_arg_sig (interp_unused=0x81b7bf8, ctx=0x832fd78, sig=0x0, ap=0x0, sti=0xbffff398) at src/inter_call.c:422 422 if (*sig) { (gdb) bt #0 0x40798304 in Parrot_init_arg_sig (interp_unused=0x81b7bf8, ctx=0x832fd78, sig=0x0, ap=0x0, sti=0xbffff398) at src/inter_call.c:422 #1 0x40797f6c in Parrot_init_arg_nci (interp=0x81b7bf8, st=0xbffff36c, sig=0x0) at src/inter_call.c:276 #2 0x082f6451 in ?? () #3 0x081b7bf8 in ?? () #4 0xbffff36c in ?? () #5 0x00000000 in ?? () #6 0x08193458 in ?? () #7 0x08310418 in ?? () #8 0x00000200 in ?? () #9 0x40cdd2d8 in ?? () #10 0x082dda10 in ?? () #11 0x0832fd78 in ?? () #12 0x00000001 in ?? () #13 0x00000000 in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x081b7bf8 in ?? () #18 0x08193458 in ?? () #19 0x00000100 in ?? () #20 0x407a0bc3 in key_next (interp=0x81b7bf8, key=0x82e1f4c) at src/key.c:480 #21 0x40938a6e in Parrot_NCI_invoke (interp=0x81b7bf8, pmc=0x82e1f4c, next=0x40cdd2ec) at nci.pmc:303 #22 0x40717116 in Parrot_invokecc_p (cur_opcode=0x40cdd2e4, interp=0x81b7bf8) at core.ops:475 #23 0x407cd83c in runops_slow_core (interp=0x81b7bf8, pc=0x40cdd2e4) at src/runops_cores.c:222 #24 0x4079edb9 in runops_int (interp=0x81b7bf8, offset=80) at src/interpreter.c:938 #25 0x4079f65f in runops (interp=0x81b7bf8, offs=80) at src/inter_run.c:101 #26 0x4079f904 in runops_args (interp=0x81b7bf8, sub=0x82dd7fc, obj=0x8328fd4, meth_unused=0x826cc5c, sig=0x40ad50e5 "v", ap=0xbffff594 "\2172\b") at src/inter_run.c:236 #27 0x4079fc96 in Parrot_run_meth_fromc_args (interp=0x81b7bf8, sub=0x82dd7fc, obj=0x8328fd4, meth=0x826cc5c, sig=0x40ad50e5 "v") at src/inter_run.c:426 #28 0x409a9042 in initialize_parents (interp=0x81b7bf8, object=0x8328fd4, all_parents=0x8329108) at class.pmc:344 #29 0x409aaf7c in Parrot_Class_instantiate (interp=0x81b7bf8, pmc=0x832923c, init=0x82c8028) at class.pmc:1131 #30 0x40736446 in Parrot_new_p_pc (cur_opcode=0x40c981b0, interp=0x81b7bf8) at pmc.ops:130 #31 0x407cd83c in runops_slow_core (interp=0x81b7bf8, pc=0x40c981b0) at src/runops_cores.c:222 #32 0x4079edb9 in runops_int (interp=0x81b7bf8, offset=2101) at src/interpreter.c:938 #33 0x4079f65f in runops (interp=0x81b7bf8, offs=2101) at src/inter_run.c:101 #34 0x4079f904 in runops_args (interp=0x81b7bf8, sub=0x82e17f8, obj=0x82c8028, meth_unused=0x0, sig=0x4043b4d5 "IP", ap=0xbffff7ec "\2242\b-\btz,\b&lt;-\bT\027.\b\024C@H\027ZC@{\033\b\001#\bIC@x\2242\b`&lt;\bHO\223\025@-\b\2242\b0\2252\b(") at src/inter_run.c:236 #35 0x4079fe56 in Parrot_runops_fromc_arglist_reti (interp=0x81b7bf8, sub=0x82e17f8, sig=0x4043b4d5 "IP", args=0xbffff7ec "\2242\b-\btz,\b&lt;-\bT\027.\b\024C@H\027ZC@{\033\b\001#\bIC@x\2242\b`&lt;\bHO\223\025@-\b\2242\b0\2252\b(") at src/inter_run.c:527 #36 0x4078995c in Parrot_call_sub_ret_int (interp=0x81b7bf8, sub=0x82e17f8, signature=0x4043b4d5 "IP") at src/extend.c:929 #37 0x4043834b in modparrot_call_sub_IP (interp=0x81b7bf8, namespace=0x82301d0 "PIR", name=0x4043af49 "post_read_request_handler", ret=0xbffff878, pmc=0x83294a4) at src/parrot_util.c:167 #38 0x40435a17 in modparrot_call_meta_handler (interp=0x81b7bf8, hll=0x82301d0 "PIR", hook=0x4043af49 "post_read_request_handler", ret=0xbffff878) at src/mod_parrot.c:233 #39 0x40435e91 in modparrot_meta_post_read_request_handler (r=0x83cab60) at src/mod_parrot.c:382 </pre> http://trac.parrot.org/parrot/ticket/1173 http://trac.parrot.org/parrot/ticket/1173 Report #236: implement pdd14-numbers Tue, 27 Jan 2009 19:44:29 GMT Wed, 13 Oct 2010 00:34:28 GMT <p> add NaN/Inf to pdd, review spec against reality, implement what remains. </p> http://trac.parrot.org/parrot/ticket/236 http://trac.parrot.org/parrot/ticket/236 Report #1212: .eof returns false if last read call read the last byte of the file, but not beyond Thu, 05 Nov 2009 17:37:27 GMT Fri, 25 Feb 2011 23:38:54 GMT <p> Hi, </p> <p> 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? </p> <p> Thoughts and fixes welcome! </p> <p> Jonathan </p> http://trac.parrot.org/parrot/ticket/1212 http://trac.parrot.org/parrot/ticket/1212 Report #1181: make cover doesn't show coverage of *.ops files. Mon, 02 Nov 2009 14:29:18 GMT Sun, 06 Dec 2009 23:59:52 GMT <p> e.g.: </p> <p> <a class="ext-link" href="http://tapir2.ro.vutbr.cz/cover/cover-results/42216/c_cover/src-ops-var-ops.html"><span class="icon"> </span>http://tapir2.ro.vutbr.cz/cover/cover-results/42216/c_cover/src-ops-var-ops.html</a> </p> <p> shows zero coverage of these ops. </p> <p> We need a way to report on ops coverage. (and if the coverage is displayed in other files, we shouldn't display the *.ops files.) </p> http://trac.parrot.org/parrot/ticket/1181 http://trac.parrot.org/parrot/ticket/1181 Report #435: languages moved to examples need tests. Wed, 11 Mar 2009 12:31:37 GMT Wed, 13 Oct 2010 02:58:35 GMT <p> The tests for <tt>examples/languages</tt> should: </p> <ol><li> be run as part of <tt>make examples_tests</tt> </li><li>Once covered, they should be skipped from <tt>t/examples/catchall.t</tt> (see line 34 of this file for another skip) </li></ol><p> As it stands, the files in that directory are generating even more failures in examples_tests, because they aren't meant to be run from the top level directory, and <tt>.include</tt>s are failing. </p> http://trac.parrot.org/parrot/ticket/435 http://trac.parrot.org/parrot/ticket/435 Report #157: [TODO] Merge parrotblog.org into parrot.org Sun, 11 Jan 2009 03:10:06 GMT Sun, 19 Sep 2010 12:27:49 GMT <p> 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). </p> <p> (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.) </p> http://trac.parrot.org/parrot/ticket/157 http://trac.parrot.org/parrot/ticket/157 Report #1018: pir compiler must be reentrant Thu, 17 Sep 2009 15:16:52 GMT Mon, 10 May 2010 02:55:49 GMT <p> This ticket can be closed either when IMCC is made re-entrant, or when PIRC (which is re-entrant but not fully functional) is the default pir compiler. </p> <p> For full history, see the <a class="ext-link" href="http://rt.perl.org/rt3/Ticket/Display.html?id=39714"><span class="icon"> </span>Original report</a>. </p> http://trac.parrot.org/parrot/ticket/1018 http://trac.parrot.org/parrot/ticket/1018 Report #357: Enable meaningful testing of t/native_pbc/*.t Wed, 18 Feb 2009 22:28:58 GMT Sat, 26 Feb 2011 12:56:32 GMT <p> Version 0.9.1 was released with failing t/native_pbc/*.t tests. If the tests are to be included in 1.0, it would be nice to have confidence that they will pass in the released version. </p> <p> Offhand, I can think of three big problems that contributed to the failure. I hasten to add that *all* of these were out of the control of the release manager -- they are inherent in the design of the tests. </p> <p> 1. The tests act differently in "DEVELOPING" versus released directories, meaning all the tests done in an svn-checkout -- even those done just prior to release -- weren't necessarily relevant. </p> <p> 2. The release procedure is difficult in practice. It is not easy, on short notice, to get developers with all the requisite different platforms to run the appropriate scripts, commit the appropriate files, and re-run all the appropriate tests. Also, because of item 1, even running all the appropriate tests does not ensure that the tests will actually pass in the released version. </p> <p> 3. There was no meaningful code freeze prior to the release, making it essentially impossible to do the coordination necessary for item 2. </p> <p> What to do? </p> <p> First, if the tests are to be kept, they must be designed so that they can be meaningfully run well in advance of the release. That way, new raw pbc files can be generated ahead of time, committed, and tested, and failures can be addressed. If they cannot be redesigned this way, then I think they are too fragile to waste time on, and they should simply be deleted. </p> <p> Second, I think the ideas of having a code freeze and issuing release candidates merit serious consideration prior to 1.0. </p> http://trac.parrot.org/parrot/ticket/357 http://trac.parrot.org/parrot/ticket/357 Report #607: ordered destruction Tue, 28 Apr 2009 22:56:44 GMT Wed, 04 Jan 2012 10:38:38 GMT <p> Extend or modify the existing GC and GC modules to allow ordered destruction (guarantee that the children of one PMC will all be destroyed before that PMC, etc). </p> http://trac.parrot.org/parrot/ticket/607 http://trac.parrot.org/parrot/ticket/607 Report #132: Can't thaw a Sub (or a PIR subclass of a Sub) Tue, 06 Jan 2009 03:52:34 GMT Wed, 12 May 2010 05:48:35 GMT <p> Code: </p> <pre class="wiki">.sub main :main $P0 = get_class 'Sub' $P1 = subclass $P0, 'myProc' .local pmc pirC pirC = compreg 'PIR' .local string code code = &lt;&lt;"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 </pre><p> Output: </p> <pre class="wiki">hi hi frozen Unsupported key type in Key.thaw current instr.: 'main' pc 48 (borked.pir:30) </pre><p> I'd expect to be able to thaw this PMC, and then invoke the sub after thaw. </p> http://trac.parrot.org/parrot/ticket/132 http://trac.parrot.org/parrot/ticket/132 Report #203: assign_pmc broken for pir subclasses? Wed, 21 Jan 2009 16:05:00 GMT Tue, 21 Jul 2009 02:19:51 GMT <pre class="wiki">.sub main $P1 = new 'Hash' .local pmc undef undef = new 'Undef' assign $P1, undef $S0 = typeof $P1 say $S0 $P1 = get_class 'Hash' $P2 = subclass $P1, 'myHash' $P1 = new 'myHash' .local pmc undef undef = new 'Undef' assign $P1, undef $S0 = typeof $P1 say $S0 .end </pre><p> this prints: </p> <pre class="wiki">Undef myHash </pre><p> but I expect it to print </p> <pre class="wiki">Undef Undef </pre><p> - this is blocking partcl. </p> http://trac.parrot.org/parrot/ticket/203 http://trac.parrot.org/parrot/ticket/203 Report #1031: Free()ing of SymReg variables Mon, 21 Sep 2009 03:46:33 GMT Sat, 02 Jul 2011 21:39:14 GMT <p> From the <a class="ext-link" href="http://rt.perl.org/rt3/Ticket/Display.html?id=44993"><span class="icon"> </span>Original RT</a> </p> <p> On Mon, Aug 27, 2007 at 09:00:42AM -0700, Paul Cochrane wrote: </p> <pre class="wiki">&gt; In looking through some of the warnings that Coverity Prevent has &gt; thrown up one common thing has come up which I'd like some advice &gt; about. We are getting "leaked storage" errors often associated with &gt; variables declared as SymReg[1]. For example, in &gt; compilers/imcc/pbc.c, at line 1463, the variable 'r' is assigned and &gt; then goes out of scope a few lines afterwards. This Coverity picks up &gt; as being leaked storage. However, if I put C&lt;mem_sys_free(r);&gt; at the &gt; end of the relevant block, C&lt;make test&gt; fails. There are other &gt; instances as well compilers/imcc/imcparser.c:2964 (i.e. &gt; compilers/imcc/imcc.y:598) and compilers/imcc/imcparser.c:675, &gt; compilers/imcc/imcparser.c659 (this time with the variable 'r3'). There are definitely some memory leaks here. I've seen these in Valgrind reports for a while. My best explanation is that we stick these new pointers in memory somewhere, but don't free them appropriately. I haven't been able to perform sufficient lifetime analysis to track down where they go and where to free them, yet. Patches welcome. -- c </pre><p> As a first step, it would be nice if someone with access to the Coverity reports could verify if this was still being reported as an issue. </p> http://trac.parrot.org/parrot/ticket/1031 http://trac.parrot.org/parrot/ticket/1031 Report #1162: Pg NCI Test Makes Unportable Connection Fri, 30 Oct 2009 01:10:23 GMT Fri, 25 Feb 2011 03:32:09 GMT <p> t/library/pg.t fails pretty miserably on this line: </p> <p> con = cl.'connectdb'(<i>) # assume table = user is present </i></p> <p> I have PostgreSQL installed, but this assumption doesn't work for me. I've checked in a skip for the remaining tests in this case, as there's no point in running them. (They cause NCI assertion failures, as the NULL connection isn't what NCI expects to pass to the Pg functions.) </p> <p> This test needs another approach to run on multiple platforms successfully. Setting an environment variable for user name and password might work better. </p> <p> -- c </p> http://trac.parrot.org/parrot/ticket/1162 http://trac.parrot.org/parrot/ticket/1162 Report #260: Build error on windows 2008 server Sun, 01 Feb 2009 18:19:48 GMT Wed, 26 Jan 2011 02:56:43 GMT <pre class="wiki">The build process doesn't complete on my windows 2008 server machine. I run activastate perl 5.10 and visual studio 2008 team system edition Version 9.0.21022.8 RTM. I get a crash in the configure step in test_7304 ( determine JIT capability) as it seems that some executbale is being killed by the DEP ( Data Execution Prevention ) facility provided in windows 2008. Nmake then manages to buid the parrot executable but doesn't complete correctly; I attach hereafter the last lines of the build log: Creating library dan_ops_switch.lib and object dan_ops_switch.exp C:\Perl\perlBins\bin\perl.exe -e "chdir shift @ARGV;system 'nmake', '-no logo', @ARGV; exit $? &gt;&gt; 8;" compilers\pct ..\..\parrot.exe -o ..\..\runtime\parrot\library\PCT.pbc --output-pbc PC T.pir ..\..\parrot.exe -o ..\..\runtime\parrot\library\PCT\PAST.pbc --output-p bc src\PAST.pir ..\..\parrot.exe -o ..\..\runtime\parrot\library\PCT\Grammar.pbc --outpu t-pbc src\PCT\Grammar.pir ..\..\parrot.exe -o ..\..\runtime\parrot\library\PCT\HLLCompiler.pbc --o utput-pbc src\PCT\HLLCompiler.pir C:\Perl\perlBins\bin\perl.exe -e "chdir shift @ARGV;system 'nmake', '-no logo', @ARGV; exit $? &gt;&gt; 8;" compilers\pge C:\Perl\perlBins\bin\perl.exe -MExtUtils::Command -e rm_f PGE.pbc ..\..\ runtime\parrot\library\PGE.pbc C:\Perl\perlBins\bin\perl.exe -e "" &gt;PGE\builtins_gen.pir ..\..\parrot.exe -o PGE.pbc --output-pbc PGE.pir ..\..\parrot.exe ..\..\runtime\parrot\library\PGE\Perl6Grammar.pir --ou tput=PGE\builtins_gen.pir PGE\builtins.pg NMAKE : fatal error U1077: '..\..\parrot.exe' : return code '0xc0000005' Stop. NMAKE : fatal error U1077: 'C:\Perl\perlBins\bin\perl.exe' : return code '0x2' Stop. </pre> http://trac.parrot.org/parrot/ticket/260 http://trac.parrot.org/parrot/ticket/260 Report #285: cmp/bitwise/other mmd vtable functions should not go through proxy pmc Fri, 06 Feb 2009 23:25:20 GMT Sun, 03 Jul 2011 17:12:11 GMT <p> In rakudo 1 &lt;=&gt; undef was doing the right thing while undef &lt;=&gt; 1 was failing. The first case works because integer.pmc has a multi cmp_num for undef and the VTABLE_get_integer(INTERP, value) call on the Failure value was correctly calling the Failure get_integer vtable method. When I tried to patch undef.pmcI noticed that I was having trouble getting a cmp_num vtable function in that file to call the Failure get_integer vtable method because the value for SELF was an undef pmc rather than a failure pmc. After further digging I concluded that the cmp_num function was being called through a proxy pmc and cmp_num was behaving differently in that regard from add and subtract which did an mmd call through the default pmc. The module lib/Parrot/Pmc2c/PMC/Object.pm generates the vtable forwarding functions and relies on the vtable_method_does_multi subroutine in lib/Parrot/Pmc2c/PMC.pm to decide which vtable methods go through a proxy and which don't. </p> <p> After dropping by #parrot on Feb 5 I was advised that having bitwise and cmp functions go through a proxy pmc might be an oversight and I was asked to come up with an appropriate test if possible. </p> <p> The patch included (not attached) below relies on the largely baseless assumption that none of the default pmc vtable mmd functions should go through a proxy from an object when I only seem to have been told that fewer of them should. I thought at least parts of it might be useful if taken fwiw. </p> <p> The attached patch to t/oo/vtableoverride.t should provide some testing for the desired behavior. </p> <p> Cheers, Ron </p> <p> The fwiw parrot patch: Index: lib/Parrot/Pmc2c/PMC.pm =================================================================== --- lib/Parrot/Pmc2c/PMC.pm (revision 36383) +++ lib/Parrot/Pmc2c/PMC.pm (working copy) @@ -328,14 +328,27 @@ </p> <blockquote> <p> return $self-&gt;vtable-&gt;attrs($methodname)-&gt;{write}; </p> </blockquote> <blockquote> <p> } </p> </blockquote> <p> +my $multi_cmp = qr/cmp(?:_num|_string|_pmc)?/; +my $multi_logical = qr/logical_(?:or|and|xor)/; +my $multi_bitwise = qr/bitwise_(?:or|and|xor|shl|shr|lsr)/; +my $multi_bitwise_str = qr/bitwise_(?:or|and|xor)/; +my $multi_arithmetic = qr/add|subtract|multiply|divide|floor_divide|modulus|pow/; + +my $multi_bitwise_style = qr/(?:$multi_bitwise|repeat)(?:_int)?/o; +my $multi_bitwise_str_style = qr/(?:$multi_bitwise|concat)(?:_str)?/o; +my $multi_arithmetic_style = qr/$multi_arithmetic(?:_int|_float)?/o; + +my $multi_bit_or_arith_style = qr/ + (?:i_)? + (?:$multi_bitwise_style|$multi_bitwise_str_style|$multi_arithmetic_style) +/xo; + </p> <blockquote> <p> sub vtable_method_does_multi { </p> <blockquote> <p> my ( $self, $methodname ) = @_; </p> </blockquote> </blockquote> <p> </p> <blockquote> <blockquote> <p> return 1 if ($methodname =~ m/<sup> </sup></p> </blockquote> </blockquote> <p> - (?:i_)? - (?:add|subtract|multiply|divide|floor_divide|modulus) - (?:_int|_float)? - $/x); + (?:$multi_cmp|$multi_logical|$multi_bit_or_arith_style) + $/xo); </p> <blockquote> <p> } </p> </blockquote> <p> </p> <blockquote> <p> sub super_method { </p> </blockquote> http://trac.parrot.org/parrot/ticket/285 http://trac.parrot.org/parrot/ticket/285 Report #304: Some files copyright Melvin Smith Tue, 10 Feb 2009 03:04:38 GMT Tue, 27 Jul 2010 21:19:46 GMT <p> To resolve an outstanding copyright issue, the following files need to be updated to reflect a TPF or Parrot Foundation copyright. </p> <p> The easiest way to do this is to get a CLA (<a class="ext-link" href="http://www.parrot.org/files/parrot_cla.pdf"><span class="icon"> </span>http://www.parrot.org/files/parrot_cla.pdf</a>) from Melvin Smith and update the copyright to the Parrot Foundation. </p> <pre class="wiki">imcc/imcc.l imcc/imcc.y imcc/imclexer.c imcc/imcparser.c imcc/main.c imcc/parser_util.c </pre> http://trac.parrot.org/parrot/ticket/304 http://trac.parrot.org/parrot/ticket/304 Report #358: complex NaN Thu, 19 Feb 2009 09:14:33 GMT Wed, 19 Oct 2011 17:34:21 GMT <pre class="wiki">$ perl6 &gt; say NaN*1i NaNNaNi </pre><p> All complex ops with NaN should return NaN. </p> <p> Check the complex ops with NaN, add tests. </p> http://trac.parrot.org/parrot/ticket/358 http://trac.parrot.org/parrot/ticket/358 Report #5: partcl's [puts hi] exposes memory leaks in r33137 Mon, 24 Nov 2008 16:09:14 GMT Wed, 20 Jan 2016 14:39:11 GMT <p> First get a copy of parrot (r33137) and partcl (r172) </p> <p> (( <a class="ext-link" href="http://code.google.com/p/partcl/wiki/PartclSource"><span class="icon"> </span>http://code.google.com/p/partcl/wiki/PartclSource</a> )) </p> <p> Once you've built partcl, run the following command: </p> <p> valgrind --suppressions=/home/coke/sandbox/parrot/tools/dev/parrot.supp --num-callers=500 --leak-check=full --leak-resolution=high --show-reachable=yes ./parrot --leak-test languages/tcl/tcl.pbc -e "puts hi" </p> <p> This generates the about-to-be-attached valgrind output. (I've suppressed some uninit. warnings in this output to highlight the memory issues.) </p> http://trac.parrot.org/parrot/ticket/5 http://trac.parrot.org/parrot/ticket/5 Report #378: Deprecation warnings in in config/gen/platform/darwin/dl.c in r37011 Thu, 26 Feb 2009 01:37:59 GMT Fri, 18 Dec 2009 01:49:21 GMT <pre class="wiki">config/gen/platform/darwin/dl.c: In function ‘Parrot_dlopen’: config/gen/platform/darwin/dl.c:129: warning: ‘NSCreateObjectFileImageFromFile’ is deprecated (declared at /usr/include/mach-o/dyld.h:145) config/gen/platform/darwin/dl.c:133: warning: ‘NSLinkModule’ is deprecated (declared at /usr/include/mach-o/dyld.h:161) config/gen/platform/darwin/dl.c:137: warning: ‘NSDestroyObjectFileImage’ is deprecated (declared at /usr/include/mach-o/dyld.h:147) config/gen/platform/darwin/dl.c:144: warning: ‘NSAddImage’ is deprecated (declared at /usr/include/mach-o/dyld.h:230) config/gen/platform/darwin/dl.c: In function ‘Parrot_dlsym’: config/gen/platform/darwin/dl.c:218: warning: ‘NSIsSymbolNameDefined’ is deprecated (declared at /usr/include/mach-o/dyld.h:176) config/gen/platform/darwin/dl.c:220: warning: ‘NSLookupAndBindSymbol’ is deprecated (declared at /usr/include/mach-o/dyld.h:179) config/gen/platform/darwin/dl.c:226: warning: ‘NSIsSymbolNameDefinedInImage’ is deprecated (declared at /usr/include/mach-o/dyld.h:178) config/gen/platform/darwin/dl.c:228: warning: ‘NSLookupSymbolInImage’ is deprecated (declared at /usr/include/mach-o/dyld.h:182) config/gen/platform/darwin/dl.c:235: warning: ‘NSLookupSymbolInModule’ is deprecated (declared at /usr/include/mach-o/dyld.h:181) config/gen/platform/darwin/dl.c:246: warning: ‘NSAddressOfSymbol’ is deprecated (declared at /usr/include/mach-o/dyld.h:188) config/gen/platform/darwin/dl.c: In function ‘Parrot_dlclose’: config/gen/platform/darwin/dl.c:272: warning: ‘NSUnLinkModule’ is deprecated (declared at /usr/include/mach-o/dyld.h:169) </pre> http://trac.parrot.org/parrot/ticket/378 http://trac.parrot.org/parrot/ticket/378 Report #411: RFC: Remove or fix SDL Fri, 06 Mar 2009 20:10:29 GMT Tue, 27 Jul 2010 21:08:43 GMT <p> t/examples/catchall.t shows a lot of failures even trying to /compile/ the SDL examples/libraries, let alone run them. </p> <p> I propose we remove the library and examples before the next supported release - it can go back into a release once it builds again. </p> <p> Or someone could fix it. </p> http://trac.parrot.org/parrot/ticket/411 http://trac.parrot.org/parrot/ticket/411 Report #457: t/dynpmc/os.t has invalid stat() and lstat() tests. Mon, 16 Mar 2009 13:38:44 GMT Thu, 23 Sep 2010 22:50:48 GMT <p> TT <a class="closed ticket" href="http://trac.parrot.org/parrot/ticket/325" title="bug: case-sensitivity test issues on win32 (closed: fixed)">#325</a> incorrectly put a "TODO" on the stat() and lstat() tests for Solaris in t/pmc/os.t. stat() and lstat() work fine on Solaris. The problem is that the test is wrong. It erroneously assumes that the st_dev value reported by one program (parrot, in this case) is necessarily the same as the st_dev value reported by another program (perl, in this case) that might have been compiled in a different mode. Specifically, on Solaris, the default system perl is compiled in 32-bit mode. If parrot is compiled in 64-bit mode, it will get a different 'st_dev' value. That's not a problem because, according to the Solaris man page for stat(2): </p> <p> <tt> Its value may be used as input to the ustat() function to determine more information about this file system. No other meaning is associated with this value. </tt> </p> <p> The fix is "simple": t/dynpmc/os.t should only compare the last 12 entries returned by stat, not all 13. Alas, I don't know how to do that in PIR. </p> <p> This problem is not necessarily specific to Solaris, though that's the platform where a mix of models is most likely to be encountered. </p> <p> If no one has the time to fix the tests, they should probably be skipped. Currently, it can result in spurious passing TODOs if perl and parrot happen to have been compiled in the same mode. </p> <p> <strong>UPDATE</strong>: Updated description 2010-09-20 to reflect movement of file from <i>t/pmc/</i> to <i>t/dynpmc</i>. </p> http://trac.parrot.org/parrot/ticket/457 http://trac.parrot.org/parrot/ticket/457 Report #1171: Lexicals and :outer not Thawed Properly from PBC Sun, 01 Nov 2009 16:42:19 GMT Fri, 27 Aug 2010 11:48:06 GMT <p> Several tests in t/op/lexicals.t fail when run as PBC (or with parrot -r): </p> <p> t/op/lexicals (Wstat: 1024 Tests: 47 Failed: 4) Failed tests: 38, 40-41, 43 </p> <p> $ ./parrot t/op/lexicals_38.pbc 20 Bug: Context 811aee8 :outer points back to itself. current instr.: '&amp;g' pc 21 (/home/chromatic/dev/parrot/t/op/lexicals_38.pir:17) called from Sub '&amp;main' pc 56 (/home/chromatic/dev/parrot/t/op/lexicals_38.pir:26) </p> <p> $ ./parrot t/op/lexicals_40.pbc Null PMC access in get_string() current instr.: '&amp;g' pc 9 (/home/chromatic/dev/parrot/t/op/lexicals_40.pir:14) called from Sub '&amp;main' pc 33 (/home/chromatic/dev/parrot/t/op/lexicals_40.pir:20) </p> <p> $ ./parrot t/op/lexicals_41.pbc Null PMC access in get_string() current instr.: '&amp;g' pc 9 (/home/chromatic/dev/parrot/t/op/lexicals_41.pir:15) called from Sub '&amp;main' pc 43 (/home/chromatic/dev/parrot/t/op/lexicals_41.pir:22) </p> <p> $ ./parrot t/op/lexicals_43.pbc (hangs; interrupted) </p> <p> I suspect these are all the same problem, and are related to RT <a class="missing ticket">#60650</a>. </p> <p> -- c </p> http://trac.parrot.org/parrot/ticket/1171 http://trac.parrot.org/parrot/ticket/1171 Report #540: installed versions of dynext/*.so still link to -lparrot in build directory Mon, 06 Apr 2009 15:58:02 GMT Mon, 23 May 2011 00:32:01 GMT <p> The installed *.so files in lib/parrot/&lt;version&gt;/dynext/ are linked to the version of -lparrot in the build directory. </p> <p> Before changing them to link to the -lparrot in the installed directory, however, it is worth asking whether they should be linked with -lparrot at all. </p> <p> Once this is all settled, TT <a class="reopened ticket" href="http://trac.parrot.org/parrot/ticket/476" title="bug: Binaries should not contain rpath (reopened)">#476</a> should be revisited because it strips all rpath usage to work around this bug. </p> http://trac.parrot.org/parrot/ticket/540 http://trac.parrot.org/parrot/ticket/540 Report #545: PackFile_unpack followed by PackFile_pack produces wrong results. Wed, 08 Apr 2009 12:19:51 GMT Sat, 19 Feb 2011 20:27:03 GMT <p> PackFile_pack for previously unpacked PBC reuses old PackFile_Header which leads to creating incorrect PBC. </p> http://trac.parrot.org/parrot/ticket/545 http://trac.parrot.org/parrot/ticket/545 Report #218: change function of get_addr and set_addr Fri, 23 Jan 2009 22:22:40 GMT Thu, 18 Nov 2010 19:09:17 GMT <p> I would expect the following code to print out 'a' twice, once for each type. This patch solves the ticket. But I'm not sure how "kosher" is it. </p> <pre class="wiki">.sub main sortme('ResizablePMCArray') $P1 = get_class 'ResizablePMCArray' $P0 = subclass $P1, 'RPA' sortme('RPA') .end .sub sortme .param string type $P0 = new type $P0[0]='z' $P0[1]='a' .local pmc comparator comparator = get_global 'ascii' $P0.'sort'(comparator) $S0 = $P0[0] say $S0 .end .sub ascii .param string a .param string b $I0 = cmp_str a,b .return($I0) .end </pre><p> Instead, it generates: </p> <pre class="wiki">a Method 'sort' not found for invocant of class 'RPA' current instr.: 'sortme' pc 53 (foo.pir:21) called from Sub 'main' pc 25 (foo.pir:10) </pre><p> sort is a method on FixedPMCArray; it's inherited by esizablePMCArray. It is apparently then NOT inherited by my PIR level subclass. </p> http://trac.parrot.org/parrot/ticket/218 http://trac.parrot.org/parrot/ticket/218 Report #558: [doc] < is not always escaped in HTML generation Thu, 16 Apr 2009 10:07:21 GMT Sun, 30 Jan 2011 04:13:05 GMT <p> in PIR block (=begin/end), the character &lt; is not escaped to a valid HTML entity. </p> <p> for example in book/ch03_pir.pod : </p> <pre class="wiki">&lt;pre&gt; .sub _main $I0 = 42 $I1 = 43 if $I0 &lt; $I1 goto L1 print "never printed" L1: print "after branch\n" end .end &lt;/pre&gt; </pre> http://trac.parrot.org/parrot/ticket/558 http://trac.parrot.org/parrot/ticket/558 Report #559: [doc] POD escape E<> is not handled by HTML generation Thu, 16 Apr 2009 10:12:00 GMT Sun, 30 Jan 2011 04:22:00 GMT <p> for example in book/ch09_pasm.pod, </p> <p> POD E&lt;#x3C0&gt; is not transformed to HTML entity &amp;#x3C0; </p> <pre class="wiki">&lt;pre&gt; set I0, 42 # set integer register #0 to the integer value 42 set N3, 3.14159 # set number register #3 to an approximation of E&lt;#x3C0&gt; </pre> http://trac.parrot.org/parrot/ticket/559 http://trac.parrot.org/parrot/ticket/559 Report #579: build failure on Solaris/x86 with GCC and native assembler Fri, 24 Apr 2009 12:09:21 GMT Mon, 17 Jan 2011 15:44:07 GMT http://trac.parrot.org/parrot/ticket/579 http://trac.parrot.org/parrot/ticket/579 Report #1292: Correct destruction of PackFile objects Tue, 17 Nov 2009 04:34:52 GMT Tue, 17 Nov 2009 04:34:52 GMT <p> Originally opened as <a class="ext-link" href="http://rt.perl.org/rt3/Ticket/Display.html?id=46687"><span class="icon"> </span>http://rt.perl.org/rt3/Ticket/Display.html?id=46687</a> </p> <pre class="wiki">In src/pmc/eval.pmc:thaw() there is the todo item (with some context): /* * XXX this isn't ok - it seems that the packfile * gets attached to interp-&gt;code and is * destroyed again during interpreter destruction */ /* PackFile_destroy(INTERP, pf); */ This issue needs correcting such that the PackFile object is cleanly destroyed. </pre><p> jonathan: </p> <pre class="wiki">This problem will go away once packfiles are garbage collectable, as specified in the bytecode PDD </pre> http://trac.parrot.org/parrot/ticket/1292 http://trac.parrot.org/parrot/ticket/1292 Report #1202: build - header file detection w/o perl5 Thu, 05 Nov 2009 06:00:05 GMT Mon, 20 Sep 2010 00:07:07 GMT <p> auto::headers uses the Config module to detect installed header files. It's ok to get default values and the arch name from Config but it's not OK to depend on it for probing the system as the Configure code will liked be compiled down to PIR someday so it can be executed by miniparrot and systems that don't have perl5 installed. </p> http://trac.parrot.org/parrot/ticket/1202 http://trac.parrot.org/parrot/ticket/1202 Report #566: export conventions (cross hll) Tue, 21 Apr 2009 13:30:21 GMT Tue, 06 Apr 2010 21:32:00 GMT <p> From <a href="https://trac.parrot.org/parrot/wiki/ParrotRoadmap">https://trac.parrot.org/parrot/wiki/ParrotRoadmap</a>. </p> http://trac.parrot.org/parrot/ticket/566 http://trac.parrot.org/parrot/ticket/566 Report #593: standard seed libraries (postgres, opengl, etc) Tue, 28 Apr 2009 21:09:03 GMT Sat, 16 Oct 2010 22:21:39 GMT <p> Improve existing libraries for Postgres, OpenGL, etc, so they are reliable, and relatively feature complete. </p> <p> Explore other libraries that we should provide by default in a full Parrot install. </p> <p> The goal is to provide a small set of working libraries, both as an example to other library implementors, and to make it easier for average developers to tackle everyday tasks in Parrot. The set of seed libraries can be small, and libraries already implemented in an existing HLL are reasonable to satisfy the "everyday tasks" goal. </p> http://trac.parrot.org/parrot/ticket/593 http://trac.parrot.org/parrot/ticket/593 Report ass