[perl #59340] t/stm/runtime_4.pir segfaults on FreeBSD 7 (i386)
On Thu Sep 25 15:09:30 2008, geraud wrote: > I reported a problem on IRC yesterday and was prompted to file a bug. >So here we go. The GeJ reports that this test is passing now so I'm marking this ticket resolved.
[perl #59742] postgres.pir creates exception the wrong way
# New Ticket Created by Hans Dieter Pearcey # Please include the string: [perl #59742] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59742 > When libpq can't be loaded, this unhelpful message appears: No such string attribute '0' the attached patch fixes that. hdp. Index: runtime/parrot/library/postgres.pir === --- runtime/parrot/library/postgres.pir (revision 31812) +++ runtime/parrot/library/postgres.pir (working copy) @@ -8,7 +8,7 @@ loadlib $P1, 'cygpq' if $P1 goto has_lib $P2 = new 'Exception' -$P2[0] = 'error loading libpg - loadlib failed' +$P2 = 'error loading libpq - loadlib failed' throw $P2 has_lib: dlfunc $P2, $P1, 'PQconnectStart', 'pt'
Re: [perl #59742] postgres.pir creates exception the wrong way
On Wednesday 08 October 2008 21:26:04 Hans Dieter Pearcey wrote: > When libpq can't be loaded, this unhelpful message appears: > > No such string attribute '0' > > the attached patch fixes that. Thanks, applied as r31857. -- c
[RFC][PATCH] Rename Rakudo's "spectest_regression" to "spectest"
Many people who try out Rakudo want to inform us about hanging or failing "make spectest" - which is expected to fail until we implement all of Perl 6 that is currently tested. Therefore I'd like to rename 'spectest_regression' to 'spectest', and provide a 'spectest_full' for running all tests. Attached patch does that, thoughts (and testing on various platforms) welcome. (To paraphrase Nicholas: "Works on my machine", ie on boring 32 bit Linux). The old "spectest_regression" remains as an alias. Should I also rename t/spectest_regression.data to t/spectest.data? -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/ Index: README === --- README (revision 31857) +++ README (working copy) @@ -45,10 +45,10 @@ to make sure that the Rakudo compiler is basically working and that it's capable of running a simple test harness. -Running "make spectest_regression" will import relevant portions +Running "make spectest" will import relevant portions of the "official Perl 6 test suite" from the Pugs repository -(http://svn.pugscode.org/pugs/t/spec/) and run all tests from -there. +(http://svn.pugscode.org/pugs/t/spec/) and run all of these tests that +are currently known to pass. At present we do not have any plans to directly store the official test suite as part of the Rakudo/Parrot repository, Index: config/makefiles/root.in === --- config/makefiles/root.in (revision 31857) +++ config/makefiles/root.in (working copy) @@ -165,8 +165,9 @@ @echo " coretest: Run rakudo's core tests." @echo " codetest: Run Parrot's code tests." @echo " testclean: Clean up test results." - @echo " spectest: Run the official Perl 6 tests." - @echo " spectest_regression: Run the tests of the official test suite that are known to pass." + @echo " spectest: Run the tests of the official test suite that are known to pass." + @echo " spectest: Run the tests of the official test suite that are known to pass." + @echo " spectest_full: Run all tests of the official test suite" @echo " localtest: Run the official tests given in t/localtest.data." @echo " fulltest: Run coretest, spectest_regression, and codetest." @echo "" @@ -199,12 +200,13 @@ HARNESS_WITH_FUDGE = $(PERL) t/harness --fudge --keep-exit-code HARNESS_WITH_FUDGE_JOBS = $(HARNESS_WITH_FUDGE) --jobs -spectest: all t/spec +spectest_full: all t/spec -cd t/spec && svn up $(HARNESS_WITH_FUDGE_JOBS) t/spec # Run the spectests that we know work. -spectest_regression: all t/spec t/spectest_regression.data +spectest_regression: spectest +spectest: all t/spec t/spectest_regression.data -cd t/spec && svn up $(HARNESS_WITH_FUDGE_JOBS) --tests-from-file=t/spectest_regression.data
Re: [RFC][PATCH] Rename Rakudo's "spectest_regression" to "spectest"
jerry gay wrote: > On Fri, Oct 10, 2008 at 5:26 AM, Moritz Lenz > <[EMAIL PROTECTED]> wrote: >> Many people who try out Rakudo want to inform us about hanging or >> failing "make spectest" - which is expected to fail until we implement >> all of Perl 6 that is currently tested. >> >> Therefore I'd like to rename 'spectest_regression' to 'spectest', and >> provide a 'spectest_full' for running all tests. Attached patch does >> that, thoughts (and testing on various platforms) welcome. (To >> paraphrase Nicholas: "Works on my machine", ie on boring 32 bit Linux). >> The old "spectest_regression" remains as an alias. >> >> Should I also rename t/spectest_regression.data to t/spectest.data? >> > during this week's design meeting, i mentioned that i think it's time > to rename 'spectest_regression' to 'test'. Even better ;-) > we didn't discuss it much, > but i imagine something like: > > test : coretest codetest spectest_regression > > with appropriate documentation changes. In principle yes, but running them all in sequence is a bad idea, because you'll only see the summary of the one that runs last, so you're likely to miss failures from earlier test blocks. A combined harness is much better in terms of reporting. > the tests we expect to pass reliably should be the default tests we > run. we expect all spectest_regression tests to pass reliably. the > default test target should always be named 'test'. it seems natural > that we add spectest_regression to the 'test' makefile target. > additionally, this would have possibly prevented the 74 failures > post-mdd-merge, since allison didn't know about the additional test > target in the makefile. well, if reading the README is too much even for our architect then we shouldn't assume that anybody else does ;-) Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: [RFC][PATCH] Rename Rakudo's "spectest_regression" to "spectest"
On Fri, Oct 10, 2008 at 5:26 AM, Moritz Lenz <[EMAIL PROTECTED]> wrote: > Many people who try out Rakudo want to inform us about hanging or > failing "make spectest" - which is expected to fail until we implement > all of Perl 6 that is currently tested. > > Therefore I'd like to rename 'spectest_regression' to 'spectest', and > provide a 'spectest_full' for running all tests. Attached patch does > that, thoughts (and testing on various platforms) welcome. (To > paraphrase Nicholas: "Works on my machine", ie on boring 32 bit Linux). > The old "spectest_regression" remains as an alias. > > Should I also rename t/spectest_regression.data to t/spectest.data? > during this week's design meeting, i mentioned that i think it's time to rename 'spectest_regression' to 'test'. we didn't discuss it much, but i imagine something like: test : coretest codetest spectest_regression with appropriate documentation changes. the tests we expect to pass reliably should be the default tests we run. we expect all spectest_regression tests to pass reliably. the default test target should always be named 'test'. it seems natural that we add spectest_regression to the 'test' makefile target. additionally, this would have possibly prevented the 74 failures post-mdd-merge, since allison didn't know about the additional test target in the makefile. ~jerry
[perl #59778] Rakudo Recursive Exception Throwing
# New Ticket Created by chromatic # Please include the string: [perl #59778] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59778 > While tracking down another bug in Rakudo, I saw this backtrace. Note that the "Class already registered!" exception gets thrown multiple times. I've seen this before several times in other Rakudo backtraces since the exceptions/concurrency merge. #0 0xb7d434ef in PIO_buf_write (interp=0x804f040, layer=0x80ffc78, io=0x80ffd28, s=0xb765e150) at src/io/io_buf.c:749 #1 0xb7d461ab in PIO_write_down (interp=0x804f040, layer=0x80ffc78, io=0x80ffd28, s=0xb765e150) at src/io/io_passdown.c:177 #2 0xb7d41fa6 in PIO_putps (interp=0x804f040, pmc=0x80dd5fc, s=0xb765e150) at src/io/io.c:1058 #3 0xb7b7ccda in Parrot_say_s (cur_opcode=0xb77eb3c4, interp=0x804f040) at src/ops/io.ops:221 #4 0xb7c2db8c in runops_slow_core (interp=0x804f040, pc=0xb77eb3c4) at src/runops_cores.c:222 #5 0xb7bedb79 in runops_int (interp=0x804f040, offset=3288) at src/interpreter.c:937 #6 0xb7bee453 in runops (interp=0x804f040, offs=3288) at src/inter_run.c:101 #7 0xb7bee71f in runops_args (interp=0x804f040, sub=0x81c2ecc, obj=0x80b8220, meth_unused=0x0, sig=0xb7ed14a0 "vP", ap=0xbfc4221c "(\037\034\b\2248�\233D\bX\"Ŀ \br��@�004\b(\037\034\b\b") at src/inter_run.c:236 #8 0xb7bee86c in Parrot_runops_fromc_args (interp=0x804f040, sub=0x81c2ecc, sig=0xb7ed14a0 "vP") at src/inter_run.c:300 #9 0xb7bd77a7 in Parrot_ex_throw_from_c (interp=0x804f040, exception=0x81c1f28) at src/exceptions.c:291 #10 0xb7bd787e in Parrot_ex_throw_from_c_args (interp=0x804f040, ret_addr=0x0, exitcode=20, format=0xb7ed4bf8 "Class %Ss already registered!\n") at src/exceptions.c:338 #11 0xb7c22439 in Parrot_oo_register_type (interp=0x804f040, name=0x81c2c48) at src/oo.c:589 #12 0xb7e05f2a in init_class_from_hash (interp=0x804f040, self=0x81c2874, info=0x81c22fc) at ./src/pmc/class.pmc:222 #13 0xb7e079b8 in Parrot_Class_init_pmc (interp=0x804f040, pmc=0x81c2874, init_data=0x81c2c48) at ./src/pmc/class.pmc:512 #14 0xb7c2d171 in pmc_new_init (interp=0x804f040, base_type=50, init=0x81c2c48) at src/pmc.c:368 #15 0xb7b85de8 in Parrot_newclass_p_p (cur_opcode=0xb7a18b24, interp=0x804f040) at src/ops/object.ops:249 #16 0xb7c2db8c in runops_slow_core (interp=0x804f040, pc=0xb7a18b24) at src/runops_cores.c:222 #17 0xb7bedb79 in runops_int (interp=0x804f040, offset=3288) at src/interpreter.c:937 #18 0xb7bee453 in runops (interp=0x804f040, offs=3288) at src/inter_run.c:101 #19 0xb7bee71f in runops_args (interp=0x804f040, sub=0xb704c970, obj=0x80b8220, meth_unused=0x0, sig=0xb7ed14a0 "vP", ap=0xbfc4253c "�\004�\2248�036D\bx%Ŀ \br��@�004\b�\004�L��\024") at src/inter_run.c:236 #20 0xb7bee86c in Parrot_runops_fromc_args (interp=0x804f040, sub=0xb704c970, sig=0xb7ed14a0 "vP") at src/inter_run.c:300 #21 0xb7bd77a7 in Parrot_ex_throw_from_c (interp=0x804f040, exception=0xb704c5d4) at src/exceptions.c:291 #22 0xb7bd787e in Parrot_ex_throw_from_c_args (interp=0x804f040, ret_addr=0x0, exitcode=20, format=0xb7ed4bf8 "Class %Ss already registered!\n") at src/exceptions.c:338 #23 0xb7c22439 in Parrot_oo_register_type (interp=0x804f040, name=0xb704c874) at src/oo.c:589 #24 0xb7e05f2a in init_class_from_hash (interp=0x804f040, self=0xb704c778, info=0xb704c60c) at ./src/pmc/class.pmc:222 #25 0xb7e079b8 in Parrot_Class_init_pmc (interp=0x804f040, pmc=0xb704c778, init_data=0xb704c874) at ./src/pmc/class.pmc:512 #26 0xb7c2d171 in pmc_new_init (interp=0x804f040, base_type=50, init=0xb704c874) at src/pmc.c:368 #27 0xb7b85de8 in Parrot_newclass_p_p (cur_opcode=0xb7a18b24, interp=0x804f040) at src/ops/object.ops:249 #28 0xb7c2db8c in runops_slow_core (interp=0x804f040, pc=0xb7a18b24) at src/runops_cores.c:222 #29 0xb7bedb79 in runops_int (interp=0x804f040, offset=3288) at src/interpreter.c:937 #30 0xb7bee453 in runops (interp=0x804f040, offs=3288) at src/inter_run.c:101 #31 0xb7bee71f in runops_args (interp=0x804f040, sub=0xb7052320, obj=0x80b8220, meth_unused=0x0, sig=0xb7ed14a0 "vP", #32 0xb7bee86c in Parrot_runops_fromc_args (interp=0x804f040, sub=0xb7052320, sig=0xb7ed14a0 "vP") at src/inter_run.c:300 #33 0xb7bd77a7 in Parrot_ex_throw_from_c (interp=0x804f040, exception=0xb70520d4) at src/exceptions.c:291 #34 0xb7bd787e in Parrot_ex_throw_from_c_args (interp=0x804f040, ret_addr=0x0, exitcode=20, format=0xb7ed4bf8 "Class %Ss already registered!\n") at src/exceptions.c:338 #35 0xb7c22439 in Parrot_oo_register_type (interp=0x804f040, name=0xb7052294) at src/oo.c:589 #36 0xb7e05f2a in init_class_from_hash (interp=0x804f040, self=0xb7052240, info=0xb705210c) at ./src/pmc/class.pmc:222 #37 0xb7e079b8 in Parrot_Class_init_pmc (interp=0x804f040, pmc=0xb7052240, init_data=0xb7052294) at ./src/pmc/class.
[perl #59788] [BUG] inplace shift left (shl_p_p, shl_p_i) fails
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #59788] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59788 > The inplace shift left and inplace shift right opcodes are failing after the mmd branch merge. Here's the test code: $ cat x.pir .sub main :main $P0 = new 'Integer' $P0 = 1 $P1 = $P0 << 3 say $P1 $P0 <<= 3 say $P0 .end $ ./parrot x.pir 8 1 $ Both should produce the same value (8), but don't. Pm
Re: [RFC][PATCH] Rename Rakudo's "spectest_regression" to "spectest"
On Fri, Oct 10, 2008 at 04:03:35PM +0200, Moritz Lenz wrote: > > during this week's design meeting, i mentioned that i think it's time > > to rename 'spectest_regression' to 'test'. > > Even better ;-) Not necessarily. Make 'spectest_regression' doesn't work for people who don't have command-line svn or a local copy of t/spec/ . I'd like to leave it as 'make spectest' to run the spectests, with 'make test' only running the tests that are part of the Parrot distribution. Perhaps we can get the 'make test' target to display a message at the end pointing to the 'make spectest(_regression)' target. Pm
Re: [RFC][PATCH] Rename Rakudo's "spectest_regression" to "spectest"
On Friday 10 October 2008 06:45:16 jerry gay wrote: > during this week's design meeting, i mentioned that i think it's time > to rename 'spectest_regression' to 'test'. we didn't discuss it much, > but i imagine something like: > > test : coretest codetest spectest_regression > > with appropriate documentation changes. Please, no more coding standards tests run by default, unless you want to make a serious argument that someone who's never built Parrot or Rakudo before should really believe that the software may not work correctly if there's a trailing space in one file, or if the Subversion commit ID is missing from another file. I fully support coding standards, but we don't have enough volunteer patch creator or patch monster time to investigate trace every Smolder failure to "Oh, someone added a new file *again*". -- c
Re: [RFC][PATCH] Rename Rakudo's "spectest_regression" to "spectest"
On Fri, Oct 10, 2008 at 02:26:19PM +0200, Moritz Lenz wrote: > Therefore I'd like to rename 'spectest_regression' to 'spectest', and > provide a 'spectest_full' for running all tests. Attached patch does > that, thoughts (and testing on various platforms) welcome. (To > paraphrase Nicholas: "Works on my machine", ie on boring 32 bit Linux). > The old "spectest_regression" remains as an alias. I forget whether I made a habit of any qualification to that phrase, but the basic phrase comes from http://www.codinghorror.com/blog/archives/000818.html [which is in a tab on my work web browser in case I need to refer to it :-)] Although to be fair (and to cross promote something (a.k.a. "off topic")) the only thing I'm going to guarantee about perl 5.8.9 *is* that it works on my machine*. If you want to be confident that it works on yours, and with your code, you'd best be testing with the release candidate when it comes (soon) or the latest snapshot (http://www.ccl4.org/~nick/P/perl-34467.tar.bz2 available now, whilst stocks last). Nicholas Clark * May not actually be "my" machine in the legal, ownership sense, for several instances of "machine". But I have shell accounts on them.
Re: building Parrot and Parrot::Embed
On Friday 10 October 2008 14:52:54 Gabor Szabo wrote: Hi Gabor, > Now at r31867 I get the following. > This PASS-es but there seem to be an error somewhere anyway. > [EMAIL PROTECTED]:~/work/parrot/ext/Parrot-Embed$ ./Build test > t/00-loadok > t/interp.1/26 Parrot VM: Can't stat no file here, code 2. > error:imcc:syntax error, unexpected IDENTIFIER > in file 'EVAL_2' line 1 > t/interp.ok > All tests successful. > Files=2, Tests=35, 0 wallclock secs ( 0.03 usr 0.02 sys + 0.09 cusr > 0.02 csys = 0.16 CPU) > Result: PASS That's a Parrot warning more than anything else. I've never made it into an exception or anything interesting; IMCC just prints to standard error then. It's kind of dumb that way. -- c
Re: [perl #59788] [BUG] inplace shift left (shl_p_p, shl_p_i) fails
what PASM opcodes to "<<" and "<<=" produce? are they the same opcodes or something different? -Andrew Whitworth On Fri, Oct 10, 2008 at 4:07 PM, Patrick R. Michaud (via RT) <[EMAIL PROTECTED]> wrote: > # New Ticket Created by Patrick R. Michaud > # Please include the string: [perl #59788] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=59788 > > > > The inplace shift left and inplace shift right opcodes > are failing after the mmd branch merge. Here's the test > code: > > $ cat x.pir > .sub main :main >$P0 = new 'Integer' >$P0 = 1 >$P1 = $P0 << 3 >say $P1 >$P0 <<= 3 >say $P0 > .end > $ ./parrot x.pir > 8 > 1 > $ > > Both should produce the same value (8), but don't. > > Pm >
Re: [perl #59788] [BUG] inplace shift left (shl_p_p, shl_p_i) fails
On Friday 10 October 2008 15:20:45 Andrew Whitworth wrote: > what PASM opcodes to "<<" and "<<=" produce? are they the same opcodes > or something different? > > $ cat x.pir > > .sub main :main > >$P0 = new 'Integer' > >$P0 = 1 > >$P1 = $P0 << 3 This is shl_p_p_i. > >say $P1 > >$P0 <<= 3 This is shl_p_i. > >say $P0 > > .end See src/ops/math.ops for the dispatch chain for both. -- c
[perl #59636] [BUG] t/op/bitwise.t fails on Darwin
Still failing as of r31872.
[perl #59638] [BUG] t/pmc/bigint.t fails on Darwin
Still failing as of r31872.
