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:06:33 GMT Content-length: 62741 Connection: Close Proxy-Connection: Close X-Cache: HIT from web1.osuosl.org Server: ProxyTrack 0.5 (HTTrack 3.49.2) Parrot: {1} Active Tickets http://trac.parrot.org/parrot/report/1 Trac Report - * List all active tickets by TT#. * Color each row based on type. en-us Parrot http://trac.parrot.org/parrot/chrome/site/parrot_logo.png http://trac.parrot.org/parrot/report/1 Trac v0.11.7 #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 #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 #505: avoid 2038 bug Thu, 26 Mar 2009 18:47:45 GMT Fri, 25 Feb 2011 17:52:19 GMT <p> Original reported here: <a class="ext-link" href="http://rt.perl.org/rt3/Ticket/Display.html?id=57728"><span class="icon"> </span>http://rt.perl.org/rt3/Ticket/Display.html?id=57728</a> </p> <pre class="wiki">&gt;&gt; we definitely need date/time pmc(s?) not only to have a common epoch &gt;&gt; across platforms, but to deal with 2038. in particular, we should &gt;&gt; leverage schwern's work on perl to address the 2038 bug. &gt;&gt; ~jerry &gt; &gt; We definitely haven't already fixed this. Here's an easy test using &gt; libfaketime: &gt; &gt; $ cat time.pir &gt; .sub main :main &gt; .local int time_int &gt; time time_int &gt; say time_int &gt; .end &gt; $ ./parrot time.pir &gt; 1222213121 &gt; $ LD_PRELOAD=/usr/src/libfaketime-0.8/libfaketime.so.1 FAKETIME="+40y" &gt; ./parrot time.pir &gt; -1811314167 We can't make this example work. If you use an INTVAL, and the INTVAL can be signed 32 bits, there is no way to have a more than 31 bits unsigned stored on it as such. -- Salu2 </pre><p> Since this is unlikely to get resolved shortly and only has a small amount of history, moving tracking of issue here. </p> http://trac.parrot.org/parrot/ticket/505 http://trac.parrot.org/parrot/ticket/505 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 #463: refactor PCT::HLLCompiler's detection of Test::Harness Mon, 16 Mar 2009 14:49:42 GMT Wed, 02 Feb 2011 03:10:43 GMT <p> In order to facilitate using PCT::HLLCompiler with test harnesses, the C&lt;command_line&gt; 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. </p> http://trac.parrot.org/parrot/ticket/463 http://trac.parrot.org/parrot/ticket/463 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 #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 #599: bytecode generation from post Tue, 28 Apr 2009 22:14:30 GMT Sun, 20 Feb 2011 23:50:26 GMT <p> Hello. </p> <p> Yes, in PIRATE and nqp_pct branches there is some initial work on generating PBCs from POST. Not finished yet. </p> <p> I'll probably jump on new NQP train and implement it there with future importing into parrot tree. </p> <p> -- Bacek </p> http://trac.parrot.org/parrot/ticket/599 http://trac.parrot.org/parrot/ticket/599 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 #525: smolder: show which tests passed unexpectedly. Tue, 31 Mar 2009 12:07:53 GMT Mon, 22 Nov 2010 15:58:58 GMT <p> smolder RFC: show which tests passed unexpectedly. Would be very helpful to see which tests we can potentially untodo. </p> http://trac.parrot.org/parrot/ticket/525 http://trac.parrot.org/parrot/ticket/525 Report #565: remove optional features from default config, refactor config probes Tue, 21 Apr 2009 13:29:50 GMT Tue, 21 Jul 2009 01:44:16 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/565 http://trac.parrot.org/parrot/ticket/565 Report #568: hll interop Tue, 21 Apr 2009 13:31:01 GMT Mon, 22 Nov 2010 15:51:51 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/568 http://trac.parrot.org/parrot/ticket/568 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 #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 #616: compacting/copying gc Tue, 28 Apr 2009 23:30:41 GMT Sun, 13 Jun 2010 23:18:12 GMT <p> Implement a compacting/copying garbage collection module for Parrot. This will require some changes to the Parrot core to make it possible to move objects. </p> http://trac.parrot.org/parrot/ticket/616 http://trac.parrot.org/parrot/ticket/616 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 #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 #600: bytecode testing framework Tue, 28 Apr 2009 22:22:47 GMT Tue, 30 Mar 2010 21:13:21 GMT <p> A framework for directly testing bytecode examples. Somewhat similar to the PIR/PASM/C testing framework. </p> http://trac.parrot.org/parrot/ticket/600 http://trac.parrot.org/parrot/ticket/600 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 #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 #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 #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 #567: pdd31-hll interop Tue, 21 Apr 2009 13:30:37 GMT Mon, 22 Nov 2010 15:51:46 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/567 http://trac.parrot.org/parrot/ticket/567 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 #817: [pmc2c] don't require custom #defines for private flags Tue, 07 Jul 2009 22:25:28 GMT Sat, 16 Oct 2010 22:48:42 GMT <p> 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: </p> <pre class="wiki">pmclass FooClass group FooGroup extends FooBase { ATTR PMC *foo; ATTR INTVAL *bar; FLAG FOO_IS_HAVING_A_GOOD_DAY; FLAG FOO_IS_WEARING_YELLOW; </pre><p> 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 . </p> http://trac.parrot.org/parrot/ticket/817 http://trac.parrot.org/parrot/ticket/817 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #1300: sysinfo_s opcode incomplete Tue, 17 Nov 2009 16:12:05 GMT Tue, 17 Nov 2009 16:12:18 GMT <p> "src/interp/inter_misc.c" defines the sysinfo_s function used by the similarly named opcode. </p> <p> The docs define the following parameters: </p> <pre class="wiki"> PARROT_OS PARROT_OS_VERSION PARROT_OS_VERSION_NUMBER CPU_ARCH CPU_TYPE </pre><p> CPU_TYPE is not implemented. </p> http://trac.parrot.org/parrot/ticket/1300 http://trac.parrot.org/parrot/ticket/1300 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 #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 #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 #1522: sweep-free gc Mon, 22 Mar 2010 22:04:58 GMT Tue, 06 Apr 2010 21:41:14 GMT <p> Implement a sweep-free garbage collector. Useful, not high-priority. </p> http://trac.parrot.org/parrot/ticket/1522 http://trac.parrot.org/parrot/ticket/1522 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 #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 #598: bytecode migration tool Tue, 28 Apr 2009 22:12:53 GMT Tue, 30 Mar 2010 21:12:29 GMT <p> Write a tool to translate one bytecode format to another. </p> <p> Extra advantage if the changes to make can be specified in a simple syntax, and if the translations can be chained. (That is, once you write a file that details the changes from 2.0 bytecode to 2.6 bytecode and another one with the details of 2.6 bytecode to 3.0 bytecode, the translation tool is smart enough to use the two files to translate 2.0 bytecode to 3.0 bytecode by translating it to 2.6 as an intermediate step.) </p> <p> The tool will also have to give warnings about opcodes and PMCs that no longer exist, as these can't be mechanically translated. Tell the user to regenerate the bytecode from source instead. </p> http://trac.parrot.org/parrot/ticket/598 http://trac.parrot.org/parrot/ticket/598 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 #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 sr