[perl #59636] [BUG] t/op/bitwise.t fails on Darwin
On Tue Oct 28 20:03:36 2008, [EMAIL PROTECTED] wrote: This has continued to pass for me on 10.4/PPC. Coke, if it's passing for you as well (which, from Smolder reports, appears to be the case), then can you close the ticket? No feedback from Coke, so I'm closing the ticket.
[perl #59638] [BUG] [MMD] t/pmc/bigint.t intermittently failing on various OSes
On Sun Oct 19 18:34:40 2008, [EMAIL PROTECTED] wrote: I probably spoke too soon. We have a Smolder failure report for this test on AIX. So I'm going to reopen the ticket and rename it failing intermittently on various OSes. The only data I have available on this is from our Smolder reports. It appears that this test has been passing on AIX since Nov 4: http://smolder.plusthree.com/app/public_projects/report_details/8093 So, keeping fingers crossed, I'm re-closing the ticket. kid51
[perl #46519] [BUG] t/stm/runtime.t test failures
No complaints since July, so I'm closing the ticket.
[perl #50920] [BUG]: t/compilers/imcc/syn/macro.t failing
On Sun Jul 20 18:55:22 2008, [EMAIL PROTECTED] wrote:
This patch isn't ideal, but it gets us closer (and avoiding SIGABRT is
good).
Reviewing old tickets today. I applied this patch on my Linux/i386, but
got no improvement. Test #36, which has been TODO-ed, still fails:
not ok 36 - invalid label syntax # TODO RT #47978, RT #51104
# Failed (TODO) test 'invalid label syntax'
# at t/compilers/imcc/syn/macro.t line 469.
# 'compilers/imcc/imcc.l:1004: failed assertion 'valp-s'
# Backtrace - Obtained 10 stack frames (max trace depth is 32).
# (unknown)
# Parrot_confess
# (unknown)
# yylex
# yyparse
# (unknown)
# imcc_run
# (unknown)
# __libc_start_main
# (unknown)
# '
# doesn't match '/Syntax error in macro at: \('\$iter_loop:'\)/
# '
# './parrot t/compilers/imcc/syn/macro_36.pir' failed with exit code
[SIGNAL 6]
Here's the result of gdb:
(gdb) run t/compilers/imcc/syn/macro_36.pir
Starting program: t/compilers/imcc/syn/macro_36.pir
[Thread debugging using libthread_db enabled]
[New Thread 1098391040 (LWP 14520)]
warning: Lowest section in /usr/lib/libicudata.so.36 is .hash at 00b4
compilers/imcc/imcc.l:1004: failed assertion 'valp-s'
Backtrace - Obtained 10 stack frames (max trace depth is 32).
(unknown)
Parrot_confess
(unknown)
yylex
yyparse
(unknown)
imcc_run
(unknown)
__libc_start_main
(unknown)
Program received signal SIGABRT, Aborted.
[Switching to Thread 1098391040 (LWP 14520)]
0x41422947 in raise () from /lib/tls/libc.so.6
(gdb) bt
#0 0x41422947 in raise () from /lib/tls/libc.so.6
#1 0x414240c9 in abort () from /lib/tls/libc.so.6
#2 0x401dcd6b in Parrot_confess (cond=0x405a0438 valp-s,
file=0x405a0422 compilers/imcc/imcc.l, line=1004) at
src/exceptions.c:506
#3 0x404d3d31 in read_macro (valp=0xbf8e6d0c, interp=0x804f048,
yyscanner=0x81178d8) at compilers/imcc/imcc.l:1004
#4 0x404cfea2 in yylex (valp=0xbf8e6d0c, yyscanner=0x81178d8,
interp=0x804f048) at compilers/imcc/imcc.l:455
#5 0x404c944d in yyparse (yyscanner=0x81178d8, interp=0x804f048)
at compilers/imcc/imcparser.c:2781
#6 0x404d6bad in compile_to_bytecode (interp=0x804f048,
sourcefile=0xbf8e7b74 t/compilers/imcc/syn/macro_36.pir,
output_file=0x0)
at compilers/imcc/main.c:950
#7 0x404d6f92 in imcc_run (interp=0x804f048,
sourcefile=0xbf8e7b74 t/compilers/imcc/syn/macro_36.pir, argc=1,
argv=0xbf8e6f48) at compilers/imcc/main.c:1053
#8 0x08048938 in main (argc=1, argv=0xbf8e6f48) at src/main.c:61
Re: [perl #60592] [TODO] change :lexid into :subid.
On Thu, Nov 20, 2008 at 11:38:11AM -0500, Will Coleda wrote: On Thu, Nov 20, 2008 at 11:36 AM, Klaas-Jan Stol [EMAIL PROTECTED] wrote: I'm not entirely sure whether it was *just* a rename... ISTR there was also something to do with a look-up of names. Pm knows more about it :-) (admittedly, the topic is not well-defined then.) kjs The note in the PDD indicated it was just a rename; If there's some other change that needs doing, we can open a new ticket. The other change that needs doing is RT #60590. This will cause .const 'Sub' $P0 = 'xyz' to look up subroutines by :subid instead of subroutine name. (If a subroutine doesn't specify a :subid flag, then its name is its subid.) Pm
[perl #59924] [BUG] t/examples/library.t: new failure
On Sat Oct 18 09:39:52 2008, [EMAIL PROTECTED] wrote: Here is more data concerning the above test failure. Between r31872 (Oct 10) and r31967 (Oct 14), I used 'apt-get' to install 4 additional Debian packages on the Linux box on which these tests were run. The packages were: ii libgmp3-dev4.2.1+dfsg-4 Multiprecision arithmetic library developers ii libgmp3-doc4.2.1+dfsg-4 Multiprecision arithmetic library example co ii libgmp3c2 4.2.1+dfsg-4 Multiprecision arithmetic library ii libgmpxx4 4.2.1+dfsg-4 Multiprecision arithmetic library (C++ bindi I installed these packages because on Linux, Configure.pl was telling me in step auto::gmp that it could not locate GMP. So I was never building Parrot with GMP. After installing these four packages, Configure.pl told me it was now locating GMP. But it was after this install that the test in t/examples/library.t began to fail. So I called 'apt-get remove' to remove the 4 packages above. At this point the test began to pass in both r31967 and HEAD. So, can anyone speculate as to why installation of these 4 packages would cause a failure in a test of PCRE? This morning I found time to reinstall the 3 libgmp3 packages -- but I did not reinstall the libgmp4 package. All tests passed on Linux. So perhaps it was a problem between gmp3 and gmp4. Closing ticket. kid51
Re: [perl #60626] [DEPRECATED] Old-style MMD functions
Will Coleda via RT wrote: * Parrot_mmd_add_function - src/inter_create.c //make_interpreter Delete that line from src/inter_create.c. Also delete the line before which initializes 'interp-binop_mmd_funcs' to NULL. These two lines are initializing the storage for the old MMD subsystem, which is never used anymore. Note that this implies deprecating all functions that refer to 'interp-binop_mmd_funcs'. (It looks like those are all caught in this list, just double-check to make sure. Ah, I don't see 'dump_mmd' in this list, it can also be removed, as it doesn't do anything anymore.) * mmd_cvt_to_types - src/multidispatch.c //Parrot_mmd_get_cached_multi_sig 'Parrot_mmd_get_cached_multi_sig' is only called by 'mmd_distance', which is only called by 'Parrot_mmd_sort_candidates'. 'Parrot_mmd_sort_candidates' is called all over the place (I standardized on that when I did the MMD cleanup). Let's see what chromatic's MMD sort cleanup does. If it eliminates the call to 'mmd_distance' then problem solved. If not, then let's break the deprecation of 'mmd_cvt_to_types' out into a separate ticket for refactoring the unholy trio of 'mmd_cvt_to_types', 'Parrot_mmd_get_cached_multi_sig', and 'mmd_distance'. Allison
[perl #52196] [TODO] Secure F2F user feedback for configure-build-test cycle for Parrot and languages
We should continue to do these build fests -- invite me to your .pm meeting and I'll lead the fest -- but we don't need to keep an RT open to do it. So I'm resolving this ticket. Some issues discovered at individual build fests remain open, but they have their own RTs. Thank you very much. kid51
[perl #60474] Configure.pl doesn't properly detect osname
On Mon Nov 10 22:04:35 2008, pioto wrote: Sorry, I don't have a patch yet, I'm still figuring out how Configure.pl works. To debug this, you may find it helpful to call: perl Configure.pl --test=configure. This will run the tests in t/configure and t/steps. Of particular interest will be t/steps/auto_arch-01.t. kid51
[perl #59112] Failing test in t/examples/library.t
On Wed Oct 22 12:52:39 2008, masak wrote: Just wanted to note that the reported problem does not occur for me anymore. In fact, I don't see the file t/examples/library.t among the tested files in the `make test` output. Neither does grep. Unfortunately, all that demonstrates is that we changed the list of tests run during 'make test' to exclude t/examples/*.t. The test file itself is still very much there. $ ls -l t/examples/library.t -rw-r--r-- 1 jimk jimk 2108 Jul 2 20:26 t/examples/library.t Can you report what results you are currently getting when you run: prove -v t/examples/library.t ? Thank you very much. kid51
[perl #58958] Build of 0.7.1 fails with Intel compiler on Linux
Would it be possible to re-run these attempts to build Parrot using the latest available version (0.8.1, I believe) and report continuing problems? Thank you very much. kid51
[perl #58760] [BUG] perl-5.8.3 fails in dynpmc.pl with Cannot restore overloading on HASH(0x...) at Storable
I believe that since this RT was first posted we have upped our requirement for Storable.pm to v2.12 (without upping our requirement for Perl). Reini, are you still experiencing these problems? Thank you very much. kid51
[perl #58726] [PATCH] add the option encoding to Configure.pl
On Fri Sep 19 07:32:09 2008, pgerd wrote: On Do. 18. Sep. 2008, 10:52:32, julianalbo wrote: Is not good that pir or pasm code meaning be dependent of locale specifics of the system. Also in several operating systems is not the computer who is working with some charset and encoding or other, is each process (depending of user settings on locale env vars, for example). So establishing an immutable global default is not a good idea. I think Parrot use a global default (fixed_8) which should be configurable at least. I think it would be nice to have a changeable default as an Opcode. I think that this is a question which will call for a ruling from the architect and core developers. Allison, care to weigh in? Thank you very much. kid51
[perl #57286] t/examples/library.t fails during make test on OS X 10.5.4
This appears to be the same issue as reported in RT 59112, so I am going to merge this ticket into that. kid51
[perl #56206] [TODO] Modify the smoke server to accept smokes from releases, not just svn
We're in the beginning stages of deprecating smoke.parrotcode.org in favor of our Smolder report system. So it would probably not be worth our effort to modify the smoke system to accept smoke test reports from new sources, such as proposed here for releases. I would like to encourage you to try out the Smolder server by saying: make make smoldertest. It's as simple as that. I will close this ticket in 7 days if no one objects. Thank you very much. kid51
[perl #56032] YAPC::NA 2008 Chicago Buildfest Results
Jeff, Have you tried out the patch, or otherwise tried to build Parrot recently? Thank you very much. kid51
[perl #55504] [BUG] Failing test t/op/spawnw.t
On Wed Sep 10 19:48:04 2008, [EMAIL PROTECTED] wrote: Can someone evaluate where we stand with respect to the issues in this RT? Thank you very much. kid51 Still hoping for feedback on these issues.
[perl #55386] [RFC] Remove Configure.pl -miniparrot option
Coke, notfound: Did we reach any resolution on these questions? Thank you very much. kid51
Re: [perl #45857] [IMCC][RFC] #line vs .line
Klaas-Jan Stol via RT wrote: On Thu Dec 13 04:35:13 2007, pmichaud wrote: On Sat Sep 29 08:57:28 2007, kjs wrote: A few months ago, the #line directive was implemented. I'm wondering what the reason was why it looks like a comment (as # will start a comment). Is there any reason to not replace this by .line? A directive typically tells the assembler/compiler something, and in this case it updates the line number. As this gets addressed we should also address the handling of the 'setline' opcode (RT #43269). Pm .line directive is implemented per r33084. #line still works. I'm not sure what Pm meant by addressing the handling of 'setline' opcode, so leaving this ticket open. I'm planning to work on bytecode annotations Real Soon Now...my thoughts on these issues are: * I think .line and .file will remain for setting the PIR-level line and file (#line and #file maybe too, or we could deprecate those) * .annotate key value / .annotate key value will be added for setting annotations, which will form high level language debug info (.line and .file may be converted to also store data using the new annotations segment rather than keeping a separate PIR debug segment in the future; not sure how soon that will happen, will leave the current debug seg intact for now though) * setline and setfile opcodes can probably go away; I can't think of a use case where we'd want to set these dynamically, since we know the line number/file number/column/whatever else we wish to store at compile time. Doing an op dispatch rather than making an annotation we can look up only when we need it seems odd to me. Thoughts? Jonathan
Re: [perl #45857] [IMCC][RFC] #line vs .line
On Sun, Nov 23, 2008 at 10:08 PM, Jonathan Worthington [EMAIL PROTECTED]wrote: Klaas-Jan Stol via RT wrote: On Thu Dec 13 04:35:13 2007, pmichaud wrote: On Sat Sep 29 08:57:28 2007, kjs wrote: A few months ago, the #line directive was implemented. I'm wondering what the reason was why it looks like a comment (as # will start a comment). Is there any reason to not replace this by .line? A directive typically tells the assembler/compiler something, and in this case it updates the line number. As this gets addressed we should also address the handling of the 'setline' opcode (RT #43269). Pm .line directive is implemented per r33084. #line still works. I'm not sure what Pm meant by addressing the handling of 'setline' opcode, so leaving this ticket open. I'm planning to work on bytecode annotations Real Soon Now...my thoughts on these issues are: * I think .line and .file will remain for setting the PIR-level line and file (#line and #file maybe too, or we could deprecate those) Minor detail: .file does not actually exist, except in PIRC. I do not have a strong preference for adding it. Pro: it's a bit clearer than .line, as .line indicates, ehm, the line :-) Specifying a filename by .line is a bit weird. Con: generating 2 directives instead of 1 each time you want to update the location makes the generated code string a bit longer/more verbose, which might not be desirable. Anyway, I'm open to anything :-) (possibly renaming even to .location (or .loc, but that's another well-known abbreviation) * .annotate key value / .annotate key value will be added for setting annotations, which will form high level language debug info (.line and .file may be converted to also store data using the new annotations segment rather than keeping a separate PIR debug segment in the future; not sure how soon that will happen, will leave the current debug seg intact for now though) * setline and setfile opcodes can probably go away; I can't think of a use case where we'd want to set these dynamically, since we know the line number/file number/column/whatever else we wish to store at compile time. Doing an op dispatch rather than making an annotation we can look up only when we need it seems odd to me. I agree. Thoughts? Jonathan
[perl #50518] [RFC] Is the rpms target dead?
Is there someone on RedHat or Fedora who could take a whack at this?
[perl #49832] [BUG] Storable error during build (0.5.2) in MacosX
On Wed Jun 18 07:43:59 2008, packy wrote: Minor note: Darwin Kernel Version 7.9.0 = OSX 10.3.9 I believe we recently made Storable v2.12 the minimum version for configuration of Parrot. Have you tried configuring recently? Any different results? Thank you very much. kid51
Re: [perl #45857] [IMCC][RFC] #line vs .line
Klaas-Jan Stol wrote: Minor detail: .file does not actually exist, except in PIRC. Well, I guess we can add it... I do not have a strong preference for adding it. Pro: it's a bit clearer than .line, as .line indicates, ehm, the line :-) Specifying a filename by .line is a bit weird. Con: generating 2 directives instead of 1 each time you want to update the location makes the generated code string a bit longer/more verbose, which might not be desirable. Anyway, I'm open to anything :-) (possibly renaming even to .location (or .loc, but that's another well-known abbreviation) Oh, argh, so .line now carries the file *and* the line number?.I wanted it to just carry the line number (the clue's in the name... ;-)) and have .file carry the filename. Then the source you compiled from one file has one .file 'foo.pir' directive, and then you just have .line 42 style things for lines. Wonder how much of a pain it'd be to change that. Since you only just added .line it, we can probably take this opportunity to make it mean what we want (just a line number), add .file, then deprecate #line and #file and we're done...perhaps for the next release. Sound sane? Jonathan
[perl #49912] [BUG] Unable to Configure using Borland C
On Tue Jan 22 16:14:47 2008, [EMAIL PROTECTED] wrote: On Tue Jan 22 14:02:30 2008, ajr wrote: Any suggestions for further floundering would be welcome. Well, here's one thought. You could try running Configure.pl with the addition of the --configure_trace option. Read the POD for Parrot::Configure::Trace to see how you would then be able to trace the evolution of specific values inside the Parrot::Configure object as you go through the 60+ config steps. Alan: Any update on this? Question for any Win32 expert: Is the Borland C compiler worth expending Parrot tuits on? kid51
Re: [perl #57492] [CAGE] Explore possible speedups of t/configure/*.t tests
On Sun, Nov 23, 2008 at 13:26, James Keenan via RT [EMAIL PROTECTED] wrote: On Mon Sep 08 18:43:49 2008, [EMAIL PROTECTED] wrote: On Tue Aug 19 19:28:43 2008, [EMAIL PROTECTED] wrote: A net total of 5 t/configure/*.t files were eliminated tonight as part of r30368 (RT 57780). And I've been able to consolidate a few more over the past few weeks. We now have 47 tests, down from a high of about 61. If anyone wants to suggest specific t/configure/*.t tests which could be merged (in the sense that their individual tests could logically sit within the same file), please speak up. Otherwise, I will resolve this ticket within 7 days. the use_ok tests can all go in one file, so they're only run once. ~jerry
Re: [perl #45857] [IMCC][RFC] #line vs .line
On Mon, Nov 24, 2008 at 02:31:58AM +0100, Jonathan Worthington wrote: Oh, argh, so .line now carries the file *and* the line number?.I wanted it to just carry the line number (the clue's in the name... ;-)) and have .file carry the filename. Then the source you compiled from one file has one .file 'foo.pir' directive, and then you just have .line 42 style things for lines. Either way works for me -- PCT can generate either without much difficulty. It probably makes more sense to have separate .file and .line directives. In particular, I wouldn't want to be repeating the .file annotation information throughout the bytecode! :-) Just a reminder that the central issue for PCT and other HLL's is that the current #line, setline, setfile, etc. instructions are currently intimately tied to lines of PIR source (RT #43269), and they probably shouldn't be. I agree that I don't see a strong need for setting file and line number dynamically -- at least not at this stage. Thanks! Pm
[perl #46865] [TODO] [Perl] Capture STDOUT when running BigNum tests
On Wed Oct 24 14:56:32 2007, pcoch wrote:
In t/pmc/bignum.t there is the todo item:
# XXX Capture STDOUT
runtest( $_[0], $_[1], $ops{ $ARGV[2] }, $_[3], $round{ $_[4] }, $_[5] );
Which means that the output from stdout needs to be captured (and
supposedly used) when running individual BigNum tests.
Am stalling this for same reason as RT 46863: there's no sense
fine-tuning the test if there's nothing yet we can test.
When we *do* have something to test, we can use IO::CaptureOutput to
capture the STDOUT.
Thank you very much.
kid51
[perl #46807] [TODO] [Perl] Thread types tests need rework
On Wed Oct 24 13:06:54 2007, pcoch wrote: In t/pmc/threads.t there is the todo item: # XXX FIXME rework tests since we don't really have thread types? I hope this comment is fairly self-explanatory. Well, I, for one, don't know what it means. Also, shouldn't this be classified as a [PIR] ticket rather than a [Perl] ticket? kid51
Re: [perl #45857] [IMCC][RFC] #line vs .line
Patrick R. Michaud wrote: Either way works for me -- PCT can generate either without much difficulty. It probably makes more sense to have separate .file and .line directives. In particular, I wouldn't want to be repeating the .file annotation information throughout the bytecode! :-) Just a reminder that the central issue for PCT and other HLL's is that the current #line, setline, setfile, etc. instructions are currently intimately tied to lines of PIR source (RT #43269), and they probably shouldn't be. I agree that I don't see a strong need for setting file and line number dynamically -- at least not at this stage. Let me clarify a little. The current .file and .line directives are tied to PIR lines. That's fine, and I'm planning we can keep things that way. We could use such a feature now, e.g. in gen_builtins.pir, for example. It's useful when you're building PIR from other bits of PIR. But I don't expect PCT will be emitting these two directives. Instead, I expect PCT will emit .annotate. This allows you to emit whatever annotations you wish. So you can do file and line annotations, but you can also choose to do column too if needed. We can use it to stash away the source code for a sub so we can do .perl for subs, or for stashing away the compiler version or OS we compiled under for the various $?FOO variables. When an exception is thrown, we already capture the location it was thrown from, and thus there will be a way to get which of these settings were in effect at the point that the exception was thrown. As an upshot of this, .annotate is not at all tied to PIR lines - the latest annotation under a given key takes precedence. So you can emit at the start maybe: .annotate file foo.pl .annotate compiler rakudo-0.1 And then per line: .annotate line 42 When a new source code line starts. And yes, I need to get this all into the PIR docs, though the storage scheme for all of this is in the bytecode PDD already. But it should give us plenty of flexibility. Sound good? Thanks, Jonathan
[perl #46803] [TODO] [Perl] Improve the GC eagerness test in t/stm/basic.t
Why is this test labelled [Perl] rather than [PIR]?
[perl #57492] [CAGE] Explore possible speedups of t/configure/*.t tests
On Sun Nov 23 17:48:48 2008, particle wrote: the use_ok tests can all go in one file, so they're only run once. ~jerry Reviewing them, I think we can probably eliminate them as 'use_ok' tests and simply 'use' the modules. I think I'll do that with all except the config step classes, which are eval-ed in. kid51
[perl #57492] [CAGE] Explore possible speedups of t/configure/*.t tests
Done in r33127. Other suggestions?
Re: [perl #45857] [IMCC][RFC] #line vs .line
On Mon, Nov 24, 2008 at 03:10:47AM +0100, Jonathan Worthington wrote: Patrick R. Michaud wrote: Just a reminder that the central issue for PCT and other HLL's is that the current #line, setline, setfile, etc. instructions are currently intimately tied to lines of PIR source (RT #43269), and they probably shouldn't be. Instead, I expect PCT will emit .annotate. This allows you to emit whatever annotations you wish. [...] And yes, I need to get this all into the PIR docs, though the storage scheme for all of this is in the bytecode PDD already. But it should give us plenty of flexibility. Sound good? Sounds fantastic! I can hardly wait! Pm
