Re: [perl #62974] Signed-zero tests failing on Windows XP
Can you give us any update on these tests on the same platform? All seems to be well here, too. (At svn 37803.) C:\parrotprove t\op\arithmetics.t t\op\arithmeticsok All tests successful. Files=1, Tests=23, 4 wallclock secs ( 0.08 usr + 0.01 sys = 0.09 CPU) Result: PASS C:\parrotprove t\pmc\complex.t t\pmc\complexok All tests successful. Files=1, Tests=467, 1 wallclock secs ( 0.25 usr + 0.00 sys = 0.25 CPU) Result: PASS C:\parrotprove t\pmc\float.t t\pmc\floatok All tests successful. Files=1, Tests=61, 8 wallclock secs ( 0.09 usr + 0.00 sys = 0.09 CPU) Result: PASS -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: [perl #62974] Signed-zero tests failing on Windows XP
On Sat, Mar 28, 2009 at 1:15 PM, a...@ippimail.com wrote: Can you give us any update on these tests on the same platform? All seems to be well here, too. (At svn 37803.) C:\parrotprove t\op\arithmetics.t t\op\arithmeticsok All tests successful. Files=1, Tests=23, 4 wallclock secs ( 0.08 usr + 0.01 sys = 0.09 CPU) Result: PASS C:\parrotprove t\pmc\complex.t t\pmc\complexok All tests successful. Files=1, Tests=467, 1 wallclock secs ( 0.25 usr + 0.00 sys = 0.25 CPU) Result: PASS C:\parrotprove t\pmc\float.t t\pmc\floatok All tests successful. Files=1, Tests=61, 8 wallclock secs ( 0.09 usr + 0.00 sys = 0.09 CPU) Result: PASS I would just make sure that the tests aren't passing because they are currently skipped or todo'd. =-) -- Will Coke Coleda
Re: [perl #62974] Signed-zero tests failing on Windows XP
Can you give us any update on these tests on the same platform? I'll be able to check early tomorrow (Saturday) afternoon. BTW, this mail account will be disappearing in a month or so. I have 1parr...@gmail.com as a substitute. -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: [perl #62974] Signed-zero tests failing on Windows XP
yep, seems like an msvc version thing. iirc there was funny -0 handling in msvc 7. can the OP attach Parrot::Configure::Generated? ~jerry I would, if I could find anything with a name like that, (with or without .pm suffix). What should the complete path be? -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: [perl #62974] Signed-zero tests failing on Windows XP
a...@ippimail.com wrote: yep, seems like an msvc version thing. iirc there was funny -0 handling in msvc 7. can the OP attach Parrot::Configure::Generated? ~jerry I would, if I could find anything with a name like that, (with or without .pm suffix). What should the complete path be? lib/Parrot/Config/Generated.pm ... which is exists after Configure.pl creates it.
[perl #62974] Signed-zero tests failing on Windows XP
# New Ticket Created by Alan Rocker # Please include the string: [perl #62974] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=62974 (At #36249). I thought these problems had been fixed. If my memory is at fault, I'll shut up and go back to sleep. If not, I'll file a formal report. Test Summary Report --- t/op/arithmetics(Wstat: 256 Tests: 28 Failed: 1) Failed test: 7 Non-zero exit status: 1 t/pmc/complex (Wstat: 0 Tests: 467 Failed: 2) Failed tests: 380-381 t/pmc/float (Wstat: 256 Tests: 61 Failed: 1) Failed test: 23 Non-zero exit status: 1 Files=388, Tests=11676, 901 wallclock secs ( 8.28 usr + 1.05 sys = 9.33 CPU) Result: FAIL mingw32-make: *** [test] Error 1 -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
[perl #62972] Signed-zero tests failing on Windows XP
# New Ticket Created by Alan Rocker # Please include the string: [perl #62972] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=62972 I thought these problems had been fixed. If my memory is at fault, I'll shut up and go back to sleep. If not, I'll file a formal report. Test Summary Report --- t/op/arithmetics(Wstat: 256 Tests: 28 Failed: 1) Failed test: 7 Non-zero exit status: 1 t/pmc/complex (Wstat: 0 Tests: 467 Failed: 2) Failed tests: 380-381 t/pmc/float (Wstat: 256 Tests: 61 Failed: 1) Failed test: 23 Non-zero exit status: 1 Files=388, Tests=11676, 901 wallclock secs ( 8.28 usr + 1.05 sys = 9.33 CPU) Result: FAIL mingw32-make: *** [test] Error 1 -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: [perl #62974] Signed-zero tests failing on Windows XP
On Sun, Feb 1, 2009 at 12:29 PM, via RT Alan Rocker parrotbug-follo...@parrotcode.org wrote: # New Ticket Created by Alan Rocker # Please include the string: [perl #62974] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=62974 (At #36249). I thought these problems had been fixed. If my memory is at fault, I'll shut up and go back to sleep. If not, I'll file a formal report. Test Summary Report --- t/op/arithmetics(Wstat: 256 Tests: 28 Failed: 1) Failed test: 7 Non-zero exit status: 1 t/pmc/complex (Wstat: 0 Tests: 467 Failed: 2) Failed tests: 380-381 t/pmc/float (Wstat: 256 Tests: 61 Failed: 1) Failed test: 23 Non-zero exit status: 1 Files=388, Tests=11676, 901 wallclock secs ( 8.28 usr + 1.05 sys = 9.33 CPU) Result: FAIL mingw32-make: *** [test] Error 1 These look like the tests that: 1) were skipped on windows 2) were failing on openbsd 3) that I skipped for openbsd 4) that particle then un-skipped for windows since they were passing for him. I suspect that we need more fine-grained skip status for windows (if these can't be fixed.) -- Will Coke Coleda
[perl #62588] [PATCH] inspect tests in t/pmc/class.t no longer seem to need commenting out
# New Ticket Created by Ron Schmidt # Please include the string: [perl #62588] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=62588 The line in the test script read: # 'inspect'() # XXX must fix 'attributes' test On commenting the test routine back in the attributes test worked OK and after moving the number of hash elements from inspect() without arguments from 6 to 7 as clearly indicated by class.pmc the whole routine ran fine. class.dif Description: video/dv
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
[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
[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?
[perl #60642] [CAGE] add a codingstd test to ensure TODOed tests have an RT ticket number
On Wed Nov 19 23:13:27 2008, [EMAIL PROTECTED] wrote: James Keenan via RT wrote: On Tue Nov 18 10:22:25 2008, [EMAIL PROTECTED] wrote: This will probably be quite challenging. Let's assume that all tests are found in files with names ending in '.t'. Those .t files can be written in any language, which probably have different ways of classifying a test as TODO. My count tonight is that 1384 .t files in the distribution. Of these 524 are *not* found under ./languages/. I wonder if we could formulate the specification in this ticket a bit more precisely before someone embarks on coding. Yes, absolutely. I just added the basic ticket on the spur of the moment, to make sure I didn't forget about it. I've been thinking about this. A few things come to mind, for instance detecting the language based on the hashbang (if any) or subdirectory it's in, and invoking a language-specific parser. And detecting the cases we can't handle, and skipping those. But to me that sounds like way too much work. It doesn't really matter to me whether the ticket number occurs within the TODO output string, a nearby comment is good enough for me. So how about skipping all the above nonsense and just ignoring the test language entirely? How about a simple regex-based test that tallies all instances of /TODO/ in the set of test files, skipping the lines that start with obvious comment characters, and for each instance, looks for a match of /#\d+/? It can even expand the search to also look a couple lines above and below the TODO line, for additional flexibility. I think that should be reasonable for most, if not all, possible test languages. Do you think that would catch all the cases? Two thoughts: 1. We already have code that can detect the existence of TODO in certain kinds of files. Cf. t/codingstd/fixme.t. Paul Cochrane used that a couple of years back to generate hundreds of RTs -- most of which are probably still outstanding. Can we leverage that Parrot::Distribution-based code? 2. I've heard a lot of talk lately about languages moving into their own repositories. If so, then we have to ask whether we should be instituting new coding standards for .t files under ./languages/. At what point do we say: You (languages) are responsible for setting and enforcing your own coding standards. That would reduce the scope of this ticket to files that are intrinsically related to Parrot. Feedback welcome. I'm not wedded to any approach and am not committing myself to any. kid51
Re: [perl #60642] [CAGE] add a codingstd test to ensure TODOed tests have an RT ticket number
On Thu, Nov 20, 2008 at 7:16 AM, James Keenan via RT [EMAIL PROTECTED] wrote: 2. I've heard a lot of talk lately about languages moving into their own repositories. If so, then we have to ask whether we should be instituting new coding standards for .t files under ./languages/. At what point do we say: You (languages) are responsible for setting and enforcing your own coding standards. Now is good. That would reduce the scope of this ticket to files that are intrinsically related to Parrot. Good plan. It's certainly possible for languages to grab a slot on googlecode or some other hosting platform and use their own ticketing system. I have found this very helpful to keep things focused for my partcl development at http://code.google.com/p/partcl/ . Jerry has created a bucket for languages that don't want to setup their own area at googlecode: http://code.google.com/p/squawk/ ; That would be a fine place for any language related tickets. (Not that we need to open any new language-related tickets as a result of this core parrot ticket.) Feedback welcome. I'm not wedded to any approach and am not committing myself to any. -- Will Coke Coleda
Re: [perl #60642] [CAGE] add a codingstd test to ensure TODOed tests have an RT ticket number
James Keenan via RT wrote: On Wed Nov 19 23:13:27 2008, [EMAIL PROTECTED] wrote: James Keenan via RT wrote: On Tue Nov 18 10:22:25 2008, [EMAIL PROTECTED] wrote: This will probably be quite challenging. Let's assume that all tests are found in files with names ending in '.t'. Those .t files can be written in any language, which probably have different ways of classifying a test as TODO. My count tonight is that 1384 .t files in the distribution. Of these 524 are *not* found under ./languages/. I wonder if we could formulate the specification in this ticket a bit more precisely before someone embarks on coding. Yes, absolutely. I just added the basic ticket on the spur of the moment, to make sure I didn't forget about it. I've been thinking about this. A few things come to mind, for instance detecting the language based on the hashbang (if any) or subdirectory it's in, and invoking a language-specific parser. And detecting the cases we can't handle, and skipping those. But to me that sounds like way too much work. It doesn't really matter to me whether the ticket number occurs within the TODO output string, a nearby comment is good enough for me. So how about skipping all the above nonsense and just ignoring the test language entirely? How about a simple regex-based test that tallies all instances of /TODO/ in the set of test files, skipping the lines that start with obvious comment characters, and for each instance, looks for a match of /#\d+/? It can even expand the search to also look a couple lines above and below the TODO line, for additional flexibility. I think that should be reasonable for most, if not all, possible test languages. Do you think that would catch all the cases? Two thoughts: 1. We already have code that can detect the existence of TODO in certain kinds of files. Cf. t/codingstd/fixme.t. Paul Cochrane used that a couple of years back to generate hundreds of RTs -- most of which are probably still outstanding. Can we leverage that Parrot::Distribution-based code? I'm sure we can. Though I'm not really sure why the test you mention is limited to only checking C sources. In fact, PDD07 says: If a bug must be fixed soon, use XXX and put a ticket in the bug tracking system. This means that each XXX should have an RT ticket number next to it. As such, we might just extend fixme.t to look for a nearby ticket number, and fail if it can't find one. And do this everywhere, not just C sources or tests. (PDD07 doesn't seem to be talking about code written in a particular language, here.) This sounds quite doable to me, and if it sounds reasonable to everyone else, I'll take a shot at it this evening just to see how badly it breaks. It does also raise the question of how to disambiguate between RT and trac tickets mentioned within the parrot sources. We could just use /#\d+/ for both, which makes the test happy, but then humans won't know where to go find the ticket. Mark
[perl #60642] [CAGE] add a codingstd test to ensure TODOed tests have an RT ticket number
# New Ticket Created by Mark Glines # Please include the string: [perl #60642] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60642
[perl #60662] Failed tests: t/pmc/nci.t
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #60662] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60662 --- osname= linux osvers= 2.6.23-gentoo-r3 arch= x86_64-linux cc= x86_64-pc-linux-gnu-gcc --- Flags: category=core severity=medium ack=no --- I just updated svn and built parrot with just perl ./Configure.pl, make, make test. I had the following test fail: prove -dv t/pmc/nci.t # $Test::Harness::Switches: # 1 tests to run t/pmc/nci# Running: /usr/bin/perl5.8.8 t/pmc/nci.t # PERL5LIB=/etc/perl:/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux:/usr/lib64/perl5/vendor_perl/5.8.8:/usr/lib64/perl5/vendor_perl:/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux:/usr/lib64/perl5/site_perl/5.8.8:/usr/lib64/perl5/site_perl:/usr/lib64/perl5/5.8.8/x86_64-linux:/usr/lib64/perl5/5.8.8:/usr/local/lib/site_perl:. 1..68 ok 1 - load library fails ok 2 - dlfunc on undef ok 3 - dlfunc function not found ok 4 - nci_c - return a char in an INTEGER register ok 5 - nci_d and nci_dlvar_double ok 6 - nci_f and nci_dlvar_float ok 7 - nci_l - return a long in an INTEGER register ok 8 - nci_p - return a pointer to int ok 9 - nci_t - return a C-string ok 10 - nci_s - return a short in an INTEGER register ok 11 - nci_v and nci_dlvar_int ok 12 - nci_dd - PASM ok 13 - nci_dd - PIR ok 14 - get_string() ok 15 - nci_fff ok 16 - nci_isc ok 17 - nci_ssc ok 18 - nci_csc ok 19 - nci_it ok 20 - nci_it ok 21 - nci_tt ok 22 - nci_dd - stress test ok 23 - nci_dd - clone ok 24 - nci_ ok 25 - nci_i4i ok 26 - nci_ii3 ok 27 - nci_tb ok 28 - nci_tB ok 29 - nci_pi - struct with ints ok 30 - nci_pi - struct with floats ok 31 - nci_pi - align ok 32 - nci_pi - char* ok 33 - nci_pi - nested struct * ok 34 - nci_pi - nested struct * w named access ok 35 - nci_pi - func_ptr* with signature ok 36 - nci_pi - nested struct aligned ok 37 - nci_pi - nested struct unaligned ok 38 - nci_pi - nested, unaligned, named ok 39 - nci_pi - int ok 40 - nci_ip ok 41 - nci_vP ok 42 - nci_cb_C1 - PASM ok 43 - nci_cb_C1 - PIR ok 44 - nci_cb_C2 - PASM ok 45 - nci_cb_C3 - PIR ok 46 - nci_cb_D1 - PASM ok 47 - nci_cb_D2 - PASM ok 48 - nci_cb_D2 - PIR ok 49 - nci_cb_D3 - PIR ok 50 - nci_cb_D4 - synchronous callbacks ok 51 - nci_pip - array of structs ok 52 - nci_i33 - out parameters and return values ok 53 - nci_vpii - nested structs ok 54 - nci_p - nested array in a struct ok 55 - nci_pii - writing back to libnci_test.so ok 56 - nci_vv and nci_dlvar_int ok 57 - dlvar - unknown symbol ok 58 - dlfunc - unknown symbol ok 59 - loading same library twice ok 60 - opcode 'does' ok 61 - conversion d - P ok 62 - conversion S - P ok 63 - conversion I - P not ok 64 - nested structs should be independent # TODO RT #31292 # Failed (TODO) test 'nested structs should be independent' # at t/pmc/nci.t line 2538. # got: 'X: 1 # Y: 100 # X: 1 # Y: 200 # ' # expected: 'X: 1 # Y: 100 # X: 1 # Y: 100 # ' ok 65 - arity ok 66 - nci_vVi - void** out parameter ok 67 - nci_ttt - t_tt parameter # Failed test 'nci_vfff - t_tt parameter' not ok 68 - nci_vfff - t_tt parameter # at t/pmc/nci.t line 2689. # Exited with error code: [SIGNAL 3] # Received: # Parrot VM: PANIC: vfff is an unknown signature type. # CAN_BUILD_CALL_FRAMES is disabled, add the signature to src/call_list.txt! # C file src/nci.c, line 7500 # Parrot file (not available), line (not available) # # We highly suggest you notify the Parrot team if you have not been working on # Parrot. Use parrotbug (located in parrot's root directory) or send an # e-mail to [EMAIL PROTECTED] # Include the entire text of this error message and the text of the script that # generated the error. If you've made any modifications to Parrot, please # describe them as well. # # Version : 0.8.1-devel # Configured : Wed Nov 19 05:57:18 2008 GMT # Architecture: nojit # JIT Capable : No # Interp Flags: 0 # Exceptions : (missing from core) # # Dumping Core... # # Expected: # 1 # 1 # 1 # # Looks like you failed 1 test of 68. dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 68 Failed 1/68 tests, 98.53% okay Failed Test Stat Wstat Total Fail List of Failed --- t/pmc/nci.t1 256681 68 Failed 1/1 test scripts. 1/68 subtests failed. Files=1, Tests=68, 6 wallclock secs ( 1.24 cusr + 2.49 csys = 3.73 CPU) Failed 1/1 test programs. 1/68 subtests failed. This is on a machine running Gentoo linux. If there's any other information i can provide let me know. Adam --- Summary of my parrot 0.8.1 (r32864) configuration: configdate='Wed Nov 19 05:57:18 2008 GMT' Platform: osname=linux, archname=x86_64-linux jitcapable=0, jitarchname=nojit, jitosname=linux, jitcpuarch=amd64 execcapable=0 perl=/usr/bin/perl5.8.8 Compiler: cc='x86_64-pc-linux-gnu-gcc', ccflags
Re: [perl #60642] [CAGE] add a codingstd test to ensure TODOed tests have an RT ticket number
James Keenan via RT wrote: On Tue Nov 18 10:22:25 2008, [EMAIL PROTECTED] wrote: This will probably be quite challenging. Let's assume that all tests are found in files with names ending in '.t'. Those .t files can be written in any language, which probably have different ways of classifying a test as TODO. My count tonight is that 1384 .t files in the distribution. Of these 524 are *not* found under ./languages/. I wonder if we could formulate the specification in this ticket a bit more precisely before someone embarks on coding. Yes, absolutely. I just added the basic ticket on the spur of the moment, to make sure I didn't forget about it. I've been thinking about this. A few things come to mind, for instance detecting the language based on the hashbang (if any) or subdirectory it's in, and invoking a language-specific parser. And detecting the cases we can't handle, and skipping those. But to me that sounds like way too much work. It doesn't really matter to me whether the ticket number occurs within the TODO output string, a nearby comment is good enough for me. So how about skipping all the above nonsense and just ignoring the test language entirely? How about a simple regex-based test that tallies all instances of /TODO/ in the set of test files, skipping the lines that start with obvious comment characters, and for each instance, looks for a match of /#\d+/? It can even expand the search to also look a couple lines above and below the TODO line, for additional flexibility. I think that should be reasonable for most, if not all, possible test languages. Do you think that would catch all the cases? It's a heck of a lot more feasable, it would work in every example I can think of (except maybe Befunge), and it seems flexible enough to deal with languages we haven't thought up yet. So I guess I'm seriously proposing this. Looking forward to your opinion, Mark
[perl #60116] t/harness should exit with non-zero value if tests fails
Fixed in r32445. Thanks for reporting!
[perl #60134] [TODO] Add tests for file-based interface to Configure.pl
No complaints. No failures in Smolder tests. Resolving ticket.
[perl #60116] t/harness should exit with non-zero value if tests fails
# New Ticket Created by David Golden # Please include the string: [perl #60116] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60116 As per the subject, the t/harness program should exit with a non-zero value on test failures so that the test failure is picked up by make. -- David
[perl #60134] [TODO] Add tests for file-based interface to Configure.pl
# New Ticket Created by James Keenan # Please include the string: [perl #60134] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60134 We've had file-based configuration since r30640 (2008-08-29). I was prompted by some remarks the other day by chromatic to see what the test coverage was for this feature -- specifically, for lib/Parrot/ Configure/Options/Conf/File.pm. I checked my coverage (http:// thenceforward.net/parrot/coverage/configure-build/coverage.html) and was shocked to see that the statement coverage was only 25%! I then checked our repository and saw that one directory tree which I *thought* I had added to the repository -- xconf/samples/ -- in order to hold configuration files was not actually there. This meant that the documentation in Configure.pl about file-based configuration was inaccurate, as that POD instructed the user to see sample files in that directory. So this morning I opened a branch in SVN, 'fileconfig', to correct this situation. So I am writing unit tests for file-based configuration and am creating dummy copy files as needed for testing. They should be ready in a few days. Thank you very much. kid51
[perl #60134] [TODO] Add tests for file-based interface to Configure.pl
Work completed and merged into trunk in r32182.
[perl #59940] [patch] convert perl tests to parrot
On Thu Oct 23 01:38:59 2008, mgrimes wrote: Christoph, Thanks for your help. This has been a great, low intensity, way to learn a bit of parrot. I think I have addressed everything, and I have attached a new patch. The patch no longer applies cleanly to objects.t, and I thought it'd be better to let you merge the recent changes from svn and add the .pcc_sub Looks like there were just a few changes to spacing. This patch applied cleanly to version 32115. I added the .pcc_sub tests to objects.t. It's a good idea to test for exception types rather than exact messages. This keeps the tests passing if the wording of the message is changed. The exception type is much more likely to remain constant. This recommended but not a blocker. I wanted to keep the changes to the code down to a minimum, so I was reluctant to add ExecptionHandler objects. If there is a simpler way (ie, testing with typeof, etc), I would be happy to look into changing it. Test messages for shouldn't be blank. If a test fails, it should be fairly Oops. Got a bit ahead of myself with complex.t. Messages have been added. This is a minor nit, but -ve and +ve generally expand to negative and Ah... should have known. Thanks. Again, thanks for working on this. Happy to help. Thanks to you and the rest of the team for doing the heavy lifting! -Mark Good times. I changed the register names to use the $P0 format, switched a few tests to isa_ok and made some minor changes (description updates, removing unneeded code/comments). The getting_null_attribute test was only throwing an exception because the old version was trying to print a null PMC. It tests nullness more sanely now. The exception-throwing tests are a little more defensive now. This doesn't matter when they pass but should make debugging easier if they ever fail. pmichaud confirmed that the typeof_class test tests the right thing, so I enabled that one too. Apart from those (mostly cosmetic) changes, the patch was good. It was committed as r32145 and r32149 after I checked that everything was sane and no tests got dropped in the conversion. Thanks.
Re: [perl #60016] [PATCH] Make basic Perl 6 tests pass
--- On Tue, 21/10/08, James Keenan via RT [EMAIL PROTECTED] \ This basic test suite will fail. That's because of this test program: t/00-parrot/06-op-inplace.t I've reported this a couple of times in http://rt.perl.org/rt3/Ticket/Display.html?id=59634 -- but no one paid attention. Since you're proposing a patch, I'll merge 59634 into this one. Thanks. Hopefully this time there will be some traction because there does appear to be a bug in Perl 6, as evidenced by this one-liner: perl6 $ ../../parrot perl6.pbc -e 'my $x = 3; $x **= 2; say $x' 3 Unless, of course, this isn't supposed to be implemented yet, but that seems strange since it's in the basic tests. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [perl #60016] [PATCH] Make basic Perl 6 tests pass
On Tue, Oct 21, 2008 at 12:21:24AM -0700, Ovid wrote: --- On Tue, 21/10/08, James Keenan via RT [EMAIL PROTECTED] Thanks. Hopefully this time there will be some traction because there does appear to be a bug in Perl 6, as evidenced by this one-liner: perl6 $ ../../parrot perl6.pbc -e 'my $x = 3; $x **= 2; say $x' 3 Unless, of course, this isn't supposed to be implemented yet, but that seems strange since it's in the basic tests. The infix:**= code broke as part of the mmd branch merge, because the meaning of Parrot's 'pow' opcode has changed. The infix:**= function used the Parrot opcode (src/builtins/assign.pir:80) a = a ** b # pow a, a, b Before the MMD merge, this opcode meant raise a to the power of b and store the result back in a. However, after the mmd branch merge this opcode now means create a new PMC containing the value of a raised to the b power and set register a to point to that new PMC, leaving the value of its original PMC alone. So, the pow opcode is no longer able to act as an inplace modifier. I've corrected this in r32071, by explicitly assigning the new result back to the PMC referenced by 'a'. I've also applied Ovid's patch (with some fixes) in r32072, so that the test correctly reports failures instead of simply saying there are misnumbered tests. Lastly, we've now reorganized the 'make test' target to make it more obvious when there is a failure in the t/00-parrot/ or t/01-sanity/ tests, and removed the coding standards tests from 'make test'. Thanks, closing ticket! Pm
Fw: Running Perl 6 Tests
It would help if I sent this to the correct mailing list. Oops. Cheers, Ovid --- On Mon, 20/10/08, Ovid [EMAIL PROTECTED] wrote: I've been doing some work integrating Perl 6 into vim and now I'm trying to figure out how to run individual Perl 6 tests. It appears that the incantation is along the lines of: perl t/harness --verbosity 1 t/01-sanity/02-counter.t However, in digging further, I found this: perl t/harness --verbosity 1 t/02-test-pm/1-basic.t That starts off with Statement not terminated properly at line 87, near (\Hello Wo and goes downhill from there. In fact, in reading through the Makefile, I don't see that this gets run unless you do 'make testtest' (added by particle back in Dec 2007). This doesn't appear to be documented. Is it supposed to be run? Should those Perl 6 tests be valid? Also, the way that t/00-parrot/06-op-inplace.t is written forces the test numbers to be out of sequence. This causes make test to fail, even though it's merely a parse error. The Test.pm module appears to work (I've only checked it superficially), so why not use that to make some of these tests a bit easier to write? Are we trying to avoid loading modules while testing core features? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Fw: Running Perl 6 Tests
On Mon, Oct 20, 2008 at 8:55 AM, Ovid [EMAIL PROTECTED] wrote: It would help if I sent this to the correct mailing list. Oops. Cheers, Ovid --- On Mon, 20/10/08, Ovid [EMAIL PROTECTED] wrote: I've been doing some work integrating Perl 6 into vim and now I'm trying to figure out how to run individual Perl 6 tests. It appears that the incantation is along the lines of: perl t/harness --verbosity 1 t/01-sanity/02-counter.t However, in digging further, I found this: perl t/harness --verbosity 1 t/02-test-pm/1-basic.t That starts off with Statement not terminated properly at line 87, near (\Hello Wo and goes downhill from there. In fact, in reading through the Makefile, I don't see that this gets run unless you do 'make testtest' (added by particle back in Dec 2007). This doesn't appear to be documented. Is it supposed to be run? Should those Perl 6 tests be valid? testtest and 02-test-pm/ should either be ripped out or heavily modified. it was intended to be tests required to pass in order to run pugs' Test.pm. rakudo never did use pugs' Test.pm, and no longer attempts to. these tests are failing, and not run by default. i'd like to see requirements for rakudo's Test.pm tested instead. Also, the way that t/00-parrot/06-op-inplace.t is written forces the test numbers to be out of sequence. This causes make test to fail, even though it's merely a parse error. The Test.pm module appears to work (I've only checked it superficially), so why not use that to make some of these tests a bit easier to write? Are we trying to avoid loading modules while testing core features? yes, 00-parrot tests are prerequisites to running Test.pm. they can't use the module to perform their tests. it does indeed look like the test numbers are out of order. ...time passes... it seems infix:**= is broken. the fix isn't obvious to me. perplexing... doubly so as t/spec/S03-operators/assign.t passes these. ~jerry ~jerry
Re: Fw: Running Perl 6 Tests
--- On Mon, 20/10/08, jerry gay [EMAIL PROTECTED] wrote: yes, 00-parrot tests are prerequisites to running Test.pm. they can't use the module to perform their tests. it does indeed look like the test numbers are out of order. ...time passes... it seems infix:**= is broken. the fix isn't obvious to me. perplexing... doubly so as t/spec/S03-operators/assign.t passes these. Well, darn. I just submitted a patch that uses Test.pm. Not only does that make my patch wrong, but I didn't understand the semantics of all of the strange assignments (+^=?), so I assumed their values were correct. Bummer. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [perl #60016] AutoReply: [PATCH] Make basic Perl 6 tests pass
OK, I've updated the patch. I've made the following assumptions: 1. I cannot load modules. 2. I cannot use subroutines. 3. I cannot use inline ops for the test counter (since that's what is being tested) The problem is that I've made the tests pass by assuming that the value of $a at each point is the correct value. I'm assuming from what Jerry has pointed out that these number should be sequential. It's a trivial fix to remedy this in the tests, but I didn't want to try and second-guess what was going on. I think this patch (or something similar) is important as those who want to play with Rakudo will see a test failure if they run 'make test' as the README instructs. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 perl6tests.patch Description: Binary data
Re: Fw: Running Perl 6 Tests
On Mon, Oct 20, 2008 at 09:42:12AM -0700, jerry gay wrote: However, in digging further, I found this: perl t/harness --verbosity 1 t/02-test-pm/1-basic.t testtest and 02-test-pm/ should either be ripped out or heavily modified. it was intended to be tests required to pass in order to run pugs' Test.pm. 02-test-pm/ should be ripped out, especially since we expect the testing functions to become Perl builtins. As such they'll be tested by either the 01-sanity/ suite or by the spectest. The 00-parrot/ set of tests are basic sanity tests for Parrot, to say do we have something that is at least running under Parrot? The 01-sanity/ tests are the tests needed to be able to start running Test.pm and the test suite. Everything else comes from the official test suite, in t/spec/ of the Pugs repository. Pm
Re: [perl #60016] AutoReply: [PATCH] Make basic Perl 6 tests pass
Sorry for the patch spam. I'm embarrassed that I didn't have this correct the first time (hey, YOU stay home and write tests for a strange platform while sick) The test will now fail, but they'll fail for the correct reason: **= is being misparsed, as pointed out earlier. You might not notice the tests failing, but that's because make test seems to run the harness 3 times and the failing test is in the first run. If you don't notice this, you won't notice these tests failing. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 perl6tests.patch Description: Binary data
[perl #60016] [PATCH] Make basic Perl 6 tests pass
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #60016] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60016 If you do this after building parrot: cd languages/perl6 make test This basic test suite will fail. That's because of this test program: t/00-parrot/06-op-inplace.t It was written before modules could be loaded and manually printed out ok $num lines, but it did so out of sequence. This causes Test::Harness to note a parse error and report a failure for the test suite, even though all tests pass. I've updated it to use Test and output test numbers in sequence without altering the semantics of the test. make test in languages/perl6 now passes on my MacBook. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 perl6tests.patch Description: Binary data
[perl #60020] [TODO] remove coding standards tests from 'make test' target
# New Ticket Created by Allison Randal # Please include the string: [perl #60020] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60020 1) Remove the coding standards tests from the main 'make test' target. 2) Add a step to the release manager's guide to run 'make codetest' and fix various stray spaces, lines that are too long, etc. before cutting the release. We'll try this for a couple of releases and see how it goes. Allison
Re: [perl #59940] [patch] convert perl tests to parrot
jerry gay wrote:
On Fri, Oct 17, 2008 at 4:00 PM, Mark Grimes [EMAIL PROTECTED] wrote:
The attached patch now includes the pir/pasm_error_output* tests in
pir. I have also added t/pmc/complex.t. Couple of issues:
1) I am not sure how to deal with pcc_sub's so I put them into
t/pmc/objects-pcc_sub.t
2) There appears to be a bug that shows up in complex.t -
complex_divide_by_zero_*(). I have skip'ed those tests and will submit
a simplified bug report and test.
This drops the test run time for these from 24 seconds to less than 2.
Also, this patch should hopefully apply cleanly. I had to make some
changes to the $Id: line in the patch by hand.
-Mark
On Fri, Oct 17, 2008 at 10:35 AM, Mark Grimes [EMAIL PROTECTED] wrote:
On Fri, Oct 17, 2008 at 12:39 AM, Christoph Otto via RT
[EMAIL PROTECTED] wrote:
You can fix the foo_error_bar tests by using an exception handler to
catch the (appropriate type of) exception.
The simplest way is to use push_eh with a label. If the exception is
raised, control will jump to that label. t/pmc/resizablestringarray.t
uses this style.
Thanks Christoph. That is pretty straight forward. I'll update and
send a new patch.
when I was on my PIRifying binge, but I didn't have nearly enough
patience at the time.
Agreed. Takes quite a bit of patients, but I have put together a vim
function and perl script that takes care of some of the more common
test idioms automatically. I'll make it public after I clean it up a
bit more.
Any suggestion on how to deal the the .pcc_sub tests. I admit, I don't
quite understand what pcc_sub are, and I get an error whenever they
are included:
error:imcc:syntax error, unexpected PCC_SUB, exprint $end ('.pcc_sub')
There are two tests in object.t that use them.
s/\.pcc_sub/\.sub/g; ## this will fix it
~jerry
Hi Mark,
I've reviewed the updated complex.t and string.t, and have a few suggestions.
The patch no longer applies cleanly to objects.t, and I thought it'd be
better to let you merge the recent changes from svn and add the .pcc_sub
tests, given Jerry's suggestion. I'll be glad to review and commit an updated
version.
It's a good idea to test for exception types rather than exact messages. This
keeps the tests passing if the wording of the message is changed. The
exception type is much more likely to remain constant. This recommended but
not a blocker.
Test messages for shouldn't be blank. If a test fails, it should be fairly
obvious from the output what went wrong. This makes debugging easier, which
is always a good goal.
In string.t, don't worry about preserving comments about failing tests if the
relevant test passes.
Use $P0 instead of P0. Both currently work, but the non-$ syntax is deprecated.
This is a minor nit, but -ve and +ve generally expand to negative and
positive. Changing out_of_bounds_substr_neg_ve_offset would increase
readability, although it's already a mouthful.
Again, thanks for working on this.
Christoph
[perl #60016] [PATCH] Make basic Perl 6 tests pass
On Mon Oct 20 09:46:08 2008, [EMAIL PROTECTED] wrote: \ This basic test suite will fail. That's because of this test program: t/00-parrot/06-op-inplace.t I've reported this a couple of times in http://rt.perl.org/rt3/Ticket/Display.html?id=59634 -- but no one paid attention. Since you're proposing a patch, I'll merge 59634 into this one. kid51
Re: [perl #59940] [patch] convert perl tests to parrot
On Fri, Oct 17, 2008 at 12:39 AM, Christoph Otto via RT
[EMAIL PROTECTED] wrote:
You can fix the foo_error_bar tests by using an exception handler to
catch the (appropriate type of) exception.
The simplest way is to use push_eh with a label. If the exception is
raised, control will jump to that label. t/pmc/resizablestringarray.t
uses this style.
Thanks Christoph. That is pretty straight forward. I'll update and
send a new patch.
when I was on my PIRifying binge, but I didn't have nearly enough
patience at the time.
Agreed. Takes quite a bit of patients, but I have put together a vim
function and perl script that takes care of some of the more common
test idioms automatically. I'll make it public after I clean it up a
bit more.
Any suggestion on how to deal the the .pcc_sub tests. I admit, I don't
quite understand what pcc_sub are, and I get an error whenever they
are included:
error:imcc:syntax error, unexpected PCC_SUB, exprint $end ('.pcc_sub')
There are two tests in object.t that use them.
Thanks,
Mark
Re: [perl #59940] [patch] convert perl tests to parrot
On Fri, Oct 17, 2008 at 4:00 PM, Mark Grimes [EMAIL PROTECTED] wrote:
The attached patch now includes the pir/pasm_error_output* tests in
pir. I have also added t/pmc/complex.t. Couple of issues:
1) I am not sure how to deal with pcc_sub's so I put them into
t/pmc/objects-pcc_sub.t
2) There appears to be a bug that shows up in complex.t -
complex_divide_by_zero_*(). I have skip'ed those tests and will submit
a simplified bug report and test.
This drops the test run time for these from 24 seconds to less than 2.
Also, this patch should hopefully apply cleanly. I had to make some
changes to the $Id: line in the patch by hand.
-Mark
On Fri, Oct 17, 2008 at 10:35 AM, Mark Grimes [EMAIL PROTECTED] wrote:
On Fri, Oct 17, 2008 at 12:39 AM, Christoph Otto via RT
[EMAIL PROTECTED] wrote:
You can fix the foo_error_bar tests by using an exception handler to
catch the (appropriate type of) exception.
The simplest way is to use push_eh with a label. If the exception is
raised, control will jump to that label. t/pmc/resizablestringarray.t
uses this style.
Thanks Christoph. That is pretty straight forward. I'll update and
send a new patch.
when I was on my PIRifying binge, but I didn't have nearly enough
patience at the time.
Agreed. Takes quite a bit of patients, but I have put together a vim
function and perl script that takes care of some of the more common
test idioms automatically. I'll make it public after I clean it up a
bit more.
Any suggestion on how to deal the the .pcc_sub tests. I admit, I don't
quite understand what pcc_sub are, and I get an error whenever they
are included:
error:imcc:syntax error, unexpected PCC_SUB, exprint $end ('.pcc_sub')
There are two tests in object.t that use them.
s/\.pcc_sub/\.sub/g; ## this will fix it
~jerry
[perl #59940] [patch] convert perl tests to parrot
On Thu Oct 16 17:43:28 2008, mgrimes wrote: Hi, The attached patch converts two perl based tests into parrot tests: t/pmc/string.t t/pmc/objects.t Each of these included pir_error_is type tests. I am not aware of any way to test those within parrot right now, so I kept them in perl tests and move them to t/pmc/string-errors.t and t/pmc/objects-errors.t. Converting these test to pir dropped their run time from 19 secs to 3 secs, and more than 2 of those seconds are spent in the *-errors.t tests. Unfortunately, I ran into a small issue applying the patch. Since I am changing lines near the # $Id:$ line, svn diff creates a patch that doesn't apply cleanly. The following one liner will clean up the $Id: line, so the patch applies cleanly. $ perl -i.bak -pe's/# \$Id: .*$/# \$Id\$/' t/pmc/string.t t/pmc/objects.t If there is a better way to make the patch, please let me know. Thanks, Mark You can fix the foo_error_bar tests by using an exception handler to catch the (appropriate type of) exception. The simplest way is to use push_eh with a label. If the exception is raised, control will jump to that label. t/pmc/resizablestringarray.t uses this style. The more fine-grained approach is to use an ExceptionHandler PMC. t/pmc/ro.t uses this style. This lets you set the types and min/max severity that the eh will handle and resume execution. t/pmc/exceptionhandler.t has some nice examples. Thanks for rewriting those two tests. I thought about tackling them when I was on my PIRifying binge, but I didn't have nearly enough patience at the time.
Re: [perl #59912] Re: hllmagic branch tests namespace changes
On Wed, Oct 15, 2008 at 1:03 PM, chromatic via RT
[EMAIL PROTECTED] wrote:
On Wednesday 15 October 2008 05:54:59 Will Coleda wrote:
The namespace of the generated file should be changed, the subclass
should probably be updated. (TGE itself should probably be updated to
not live a namespace with a '::' in it. The actual transform sub can
keep the name it has, but the first parameter to add_rule() should
probably be updated as well. This /should/ work with the new automatic
translation of :: that PGE is doing.
Here's a patch for part of TGE to use the keyed form of classnames. PCT may
need some changes as well. In particular, the parsegrammar and astgrammar
methods in src/PCT/HLLCompiler.pir take strings as arguments, as in this
example from Pheme:
$P0 = get_hll_global ['PCT'], 'HLLCompiler'
$P1 = $P0.'new'()
$P1.'language'('Pheme')
$P1.'parsegrammar'( 'Pheme::Grammar' )
$P1.'astgrammar'( 'Pheme::AST::Grammar' )
They should probably transform these strings into keys internally, as
P6MetaObject does.
-- c
With this patch, I get a TGC failure trying to compile tcl :
../../parrot ../../compilers/tge/tgc.pir
--output=src/grammar/expr/pge2past.pir src/grammar/expr/pge2past.tg
Null PMC access in invoke()
current instr.: 'parrot;TGE::Compiler;parse_grammar' pc 28 (TGE/Compiler.pir:34)
called from Sub 'parrot;TGE::Compiler;precompile' pc 653 (TGE/Compiler.pir:293)
called from Sub 'main' pc 101 (../../compilers/tge/tgc.pir:87)
make: *** [src/grammar/expr/pge2past.pir] Error 1
--
Will Coke Coleda
Re: [perl #59912] Re: hllmagic branch tests namespace changes
For tene++; Not quite a test file, but I hope it will suffice.
Allison, can you comment on this, since TGE is yours?
% cat test.tg #simple .tg grammar
grammar TclExpr::PIR::Grammar is TGE::Grammar;
transform pir (Another::Nested::Namespace) {
say hello
}
%../../parrot ../../compilers/tge/tgc.pir --output=test.pir test.tg
%cat test.pir #compiled version
.namespace [ 'TclExpr::PIR::Grammar' ]
.sub '__onload' :load :init
load_bytecode 'TGE.pbc'
push_eh class_loaded
$P1 = subclass 'TGE::Grammar', 'TclExpr::PIR::Grammar'
pop_eh
class_loaded:
.end
.sub '_Another::Nested::Namespace_pir' :method
.param pmc tree
.param pmc node
#line 2 test.tg
say hello
.end
.sub init :vtable :method
self.add_rule('Another::Nested::Namespace', 'pir', '.', '_Another::Nested::
Namespace_pir')
.end
%
The namespace of the generated file should be changed, the subclass
should probably be updated. (TGE itself should probably be updated to
not live a namespace with a '::' in it. The actual transform sub can
keep the name it has, but the first parameter to add_rule() should
probably be updated as well. This /should/ work with the new automatic
translation of :: that PGE is doing.
--
Will Coke Coleda
Re: [perl #59912] Re: hllmagic branch tests namespace changes
On Wednesday 15 October 2008 05:54:59 Will Coleda wrote:
The namespace of the generated file should be changed, the subclass
should probably be updated. (TGE itself should probably be updated to
not live a namespace with a '::' in it. The actual transform sub can
keep the name it has, but the first parameter to add_rule() should
probably be updated as well. This /should/ work with the new automatic
translation of :: that PGE is doing.
Here's a patch for part of TGE to use the keyed form of classnames. PCT may
need some changes as well. In particular, the parsegrammar and astgrammar
methods in src/PCT/HLLCompiler.pir take strings as arguments, as in this
example from Pheme:
$P0 = get_hll_global ['PCT'], 'HLLCompiler'
$P1 = $P0.'new'()
$P1.'language'('Pheme')
$P1.'parsegrammar'( 'Pheme::Grammar' )
$P1.'astgrammar'( 'Pheme::AST::Grammar' )
They should probably transform these strings into keys internally, as
P6MetaObject does.
-- c
--- compilers/tge/TGE/Compiler.pir (revision 31999)
+++ compilers/tge/TGE/Compiler.pir (local)
@@ -397,10 +397,14 @@
.local string code
.local string type
.local string inherit
-type = grammar[type]
+type= grammar[type]
inherit = grammar[inherit]
-code = \n.namespace
+code= \n.namespace
+
if type == '' goto no_type
+.local pmc type_parts
+type_parts = split '::', type
+type = join '; ', type_parts
code .= [ '
code .= type
code .= ' ]
@@ -411,9 +415,9 @@
code .= push_eh class_loaded\n
code .= $P1 = subclass '
code .= inherit
-code .= ', '
+code .= ', [ '
code .= type
-code .= '\n
+code .= ' ]\n
code .= pop_eh\n
code .= class_loaded:\n
code .= \n.end\n\n
[perl #59912] Re: hllmagic branch tests namespace changes
# New Ticket Created by Will Coleda # Please include the string: [perl #59912] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59912 On Tue, Oct 14, 2008 at 8:03 AM, Will Coleda [EMAIL PROTECTED] wrote: On Tue, Oct 14, 2008 at 7:59 AM, François Perrad [EMAIL PROTECTED] wrote: Stephen Weeks a écrit : Not long ago, Patrick R. Michaud proclaimed... Any help others can provide would be greatly appreciated, as we'd like to merge the current hllmagic branch back into trunk in the next day or so. Once that's done we'll be creating a new branch where we can start putting each language into its own hll namespace, instead of most of them sharing the 'parrot' namespace. This branch has been merged as of r31862. Please report any new failures that you need help fixing here or on IRC. TGE needs to be updated in the same way for namespace (pdd21 compliant). TGE is used by : - c99 (currently broken) - Lua (currently fixed with ugly hack r31940) - Pheme (currently broken) partcl uses it as well, but another issue is preventing an upgrade to this revision of parrot. Once that is resolved, I can give you a status on how this affects partcl. partcl seems to be busted against head as well; PGE is splitting the namespaces on ::, but TGE is not. Sending this to parrotbug to open a ticket. -- Will Coke Coleda
Re: [perl #59912] Re: hllmagic branch tests namespace changes
On Wed, Oct 15, 2008 at 10:02:39AM -0700, chromatic wrote:
On Wednesday 15 October 2008 05:54:59 Will Coleda wrote:
The namespace of the generated file should be changed, the subclass
should probably be updated. (TGE itself should probably be updated to
not live a namespace with a '::' in it. The actual transform sub can
keep the name it has, but the first parameter to add_rule() should
probably be updated as well. This /should/ work with the new automatic
translation of :: that PGE is doing.
Here's a patch for part of TGE to use the keyed form of classnames. PCT may
need some changes as well. In particular, the parsegrammar and astgrammar
methods in src/PCT/HLLCompiler.pir take strings as arguments, as in this
example from Pheme:
$P0 = get_hll_global ['PCT'], 'HLLCompiler'
$P1 = $P0.'new'()
$P1.'language'('Pheme')
$P1.'parsegrammar'( 'Pheme::Grammar' )
$P1.'astgrammar'( 'Pheme::AST::Grammar' )
They should probably transform these strings into keys internally, as
P6MetaObject does.
'parsegrammar' already knows to convert a string into a class --
we just need to update 'astgrammar' to do the same.
Pm
[PATCH] Add subclass tests on t/pmc/integer.t and RT #52198
Ok, picked up the committers challenge... :-)
I setup a working Win32/MSVC environment for parrot,
and I'm trying to address the Win32 related tickets.
I started with RT #52198, test failures on Win32.
There are still many .t files with failures.
The first one I started to look into is t/pmc/complex.t.
Two things here:
1) test n.48 passes for me. It was marked as failing for Win32.
Following patch removes the skip block.
-8---
Index: t/pmc/complex.t
===
--- t/pmc/complex.t (revisione 31978)
+++ t/pmc/complex.t (copia locale)
@@ -1607,9 +1607,6 @@
done
OUTPUT
-SKIP: {
-skip 'failling on win32' = 1 if $^O =~ m/win32/i;
-
pir_output_is( 'CODE', 'OUTPUT', sinh of complex numbers );
.macro DoIt(val, res)
c = .val
@@ -1653,8 +1650,6 @@
done
OUTPUT
-}
-
pir_output_is( 'CODE', 'OUTPUT', cosh of complex numbers );
.macro DoIt(val, res)
c = .val
-8---
2) The last test, regarding subclasses of Complex
still fails. Diagnostic output follows:
-8---
ok 48 - sinh of complex numbers
ok 49 - cosh of complex numbers
ok 50 - tanh of complex numbers
ok 51 - coth of complex numbers
ok 52 - sech of complex numbers
ok 53 - csch of complex numbers
not ok 54 - add using subclass of Complex (RT \#59630) # TODO TODO
# Looks like you failed 1 test of 54.
# Failed (TODO) test 'add using subclass of Complex (RT \#59630)'
# at t\pmc\complex.t line 1866.
# got: '1+2i
# 3+4i
# 1+2i
# '
# expected: '1+2i
# 3+4i
# 4+6i
# '
dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 5
Failed 1/54 tests, 98.15% okay (less 4 skipped tests: 49 okay,
90.74%)
Failed Test Stat Wstat Total Fail List of Failed
---
t\pmc\complex.t1 256541 5
4 subtests skipped.
Failed 1/1 test scripts. 1/54 subtests failed.
Files=1, Tests=54, 3 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
Failed 1/1 test programs. 1/54 subtests failed.
-8---
I tried to understand a bit more. Went to t/pmc/integer.t
to look for a similar subclass test. Didn't find it.
I added it, and it fails in the same way. Patch follows:
-8---
Index: t/pmc/integer.t
===
--- t/pmc/integer.t (revisione 31978)
+++ t/pmc/integer.t (copia locale)
@@ -7,7 +7,7 @@
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test tests = 19;
+use Parrot::Test tests = 20;
=head1 NAME
@@ -539,6 +539,36 @@
2147483600 is greater than -1000
OUTPUT
+pir_output_is( 'CODE', 'OUTPUT', add using subclass of Integer);
+.sub main
+$P0 = subclass 'Integer', 'MyInteger'
+
+.local pmc a, b, c
+
+a = new 'MyInteger'
+a = 1
+say a
+
+b = new 'MyInteger'
+b = 2
+say b
+
+c = add a, b
+say c
+.end
+
+.namespace ['MyInteger']
+
+.sub 'init' :vtable
+$P1 = new 'Integer'
+.end
+
+CODE
+1
+2
+3
+OUTPUT
+
# Local Variables:
# mode: cperl
# cperl-indent-level: 4
-8---
I guess this is something a bit beyond my possibilities,
but any hint to put me on the right track?
--
Cosimo
add_subclass_test.diff
Description: Binary data
complex_skip_win32.diff
Description: Binary data
[perl #59442] make benchmark_tests fails 3 tests
# New Ticket Created by Paco Linux
# Please include the string: [perl #59442]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59442
as r31402 : Expanded float precision to 15 digits from 6. One side effect
is that float output no longer always has six digits after the dot; this
drops trailing zeroes. Now the result is correct.
t/benchmark/benchmarks..1/37
# Failed test 'examples/benchmarks/addit.pasm'
# at t/benchmark/benchmarks.t line 222.
# got: '21001097.97
# '
# expected: '21001097.97
# '
t/benchmark/benchmarks..2/37
# Failed test 'examples/benchmarks/addit.pir'
# at t/benchmark/benchmarks.t line 222.
# got: '21001097.97
# '
# expected: '2.10011e+07
# '
t/benchmark/benchmarks..3/37
# Failed test 'examples/benchmarks/addit2.pir'
# at t/benchmark/benchmarks.t line 222.
# got: '21001097.97
# '
# expected: '2.10011e+07
# '
Paco
--- t/benchmark/benchmarks.t 2008-09-29 11:05:48.0 +0200
+++ t/benchmark/benchmarks.new 2008-09-29 11:06:40.0 +0200
@@ -26,9 +26,9 @@
# Expected output from scripts in 'examples/benchmarks'.
# The expected out is needed for checking results with pir_output_is() and pir_output_like().
my %outputs = (
-q{addit.pir}= qq(2.10011e+07\n),
-q{addit.pasm} = qq(21001097.97\n),
-q{addit2.pir} = qq(2.10011e+07\n),
+q{addit.pir}= qq(21001097.97\n),
+q{addit.pasm} = qq(21001097.97\n),
+q{addit2.pir} = qq(21001097.97\n),
q{array_access.pir} = qr/
1\s\*\s1000\s=\s1000\n
100\s\*\s1000\s=\s10\n
Re: [perl #59442] make benchmark_tests fails 3 tests
Paco Linux (via RT) wrote: as r31402 : Expanded float precision to 15 digits from 6. One side effect is that float output no longer always has six digits after the dot; this drops trailing zeroes. Now the result is correct. t/benchmark/benchmarks..1/37 # Failed test 'examples/benchmarks/addit.pasm' # at t/benchmark/benchmarks.t line 222. # got: '21001097.97 # ' # expected: '21001097.97 # ' I think it's fundamentally wrong to rely on a particular stringification format if what you really want to do is compare numbers. If our current harness doesn't offer that option (I don't know, I'm not very familiar with the PIR tests) it should be created. Patching to use the currently-up-to-date number format is just curing the symptoms, not the disease. Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
[perl #58934] [CAGE] 'make fulltest' says PASS at the end, although some tests failed
# New Ticket Created by Moritz Lenz # Please include the string: [perl #58934] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58934 'make fulltest' runs several chunks of tests, and does not show a final summary. So although some tests in some chunks fail, the last thing that the tester sees is something along these lines: ===( 35 )==All tests successful. Files=10, Tests=108, 29 wallclock secs ( 0.04 usr 0.02 sys + 19.55 cusr 1.44 csys = 21.05 CPU) Result: PASS make[1]: Leaving directory `/home/moritz/src/parrot' If only the last chunk succeeded. This is very misleading, and probably dangerous. At the very least it should say something like WARNING: not all tests were successful, scroll up to find out which failed. This could be done by collecting the return values from the various 'make test*' calls. Even better would be real summary at the end listing the failed tests. (Observed with perl-5.10.0 and Test::Harness 3.11, parrot as of shortly-before 0.7.1) Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: [perl #58934] [CAGE] 'make fulltest' says PASS at the end, although some tests failed
On Tue, Sep 16, 2008 at 12:27 PM, via RT Moritz Lenz [EMAIL PROTECTED] wrote: # New Ticket Created by Moritz Lenz # Please include the string: [perl #58934] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58934 'make fulltest' runs several chunks of tests, and does not show a final summary. So although some tests in some chunks fail, the last thing that the tester sees is something along these lines: ===( 35 )==All tests successful. Files=10, Tests=108, 29 wallclock secs ( 0.04 usr 0.02 sys + 19.55 cusr 1.44 csys = 21.05 CPU) Result: PASS make[1]: Leaving directory `/home/moritz/src/parrot' If only the last chunk succeeded. This is very misleading, and probably dangerous. At the very least it should say something like WARNING: not all tests were successful, scroll up to find out which failed. This could be done by collecting the return values from the various 'make test*' calls. Even better would be real summary at the end listing the failed tests. (Observed with perl-5.10.0 and Test::Harness 3.11, parrot as of shortly-before 0.7.1) Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ parrot's fulltest runs the harness multiple times without a very clear distinction. as i understand, this behavior can now be changed, as we require T::H 3. the fulltest target must be modified to report the results from each harness run together at the end, rather than seperately after each harness run. ~jerry
[perl #46857] [TODO] [Pir] Fix smartlinks in exporter PMC tests once speced
Rejected, as we're deleting the test file which the OP calls for expanding.
[perl #46785] [TODO] [Perl] Add more File-related tests to the smartlinks tests
Rejected, as we're deleting the test file which the OP calls for expanding.
[perl #46787] [TODO] [Perl] Add tests of PodFile-tree to the smartlinks tests
Rejected, as we're deleting the file proposed for expansion.
[perl #46789] [TODO] [Perl] Add many more tests of SpecFiles-files to the smartlinks tests
Rejected, as we're deleting the file proposed for expansion.
[perl #46791] [TODO] [Perl] Add more tests of SpecFiles to the smartlinks tests
Rejected, as we're deleting the file proposed for expansion.
[perl #46793] [TODO] [Perl] Add more tests of Test to the smartlinks tests
Rejected, as we're deleting the file proposed for expansion.
[perl #46795] [TODO] [Perl] Add more tests of TestInfo to the smartlinks tests
Rejected, as we're deleting the file proposed for expansion.
[perl #46797] [TODO] [Perl] Add more tests of SmartLinkServer to the smartlinks tests
Rejected, as we're deleting the file proposed for expansion.
[perl #46799] [TODO] [Perl] Perform end-to-end testing of SmartLinks tests
Rejected, as we're deleting the file proposed for expansion.
[perl #46783] [TODO] [Perl] Use temporary files in smartlinks tests
As the discussion evolved in RT 58742, the consensus was that the current smartlink functionality in Parrot is not working and that a fresh approach must be taken. So we're deleting the smartlink-related files (or, at the very least, those outside of the languages/ directory). That means we can this ticket. szbalint++ for moving the discussion forward. Thank you very much. kid51
[perl #49722] [CAGE] Add Tests for SchedulerMessage PMC
On Sun Jan 13 05:38:42 2008, coke wrote: -- Will Coke Coleda On Jan 12, 2008, at 7:33 PM, chromatic (via RT) parrotbug- [EMAIL PROTECTED] wrote: # New Ticket Created by chromatic # Please include the string: [perl #49722] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=49722 The current tests in t/pmc/schedulermessage.t are only a placeholder. This PMC needs full test coverage. Also: Current test is pir with perl coda... r31100 adds tests that hit every VTABLE method except mark() and share_ro(). The tests pretty generic, but they should be good enough to justify my having marked this ticket resolved.
[perl #57530] Fwd: Parallelize the Perl 6 tests
Moritz, I applied parallel-r.patch to trunk at r30978 on Darwin (10.4 PPC), successfully built and tested Parrot, built Perl 6, then got the results below out of 'make test'. Since I build and test Perl 6 infrequently, I'm not sure whether these results are different from what I would have gotten without the patch applied. But everything passed! Thank you very much. kid51 /usr/local/bin/perl t/harness t/00-parrot t/01-sanity t/00-parrot/01-literalsok t/00-parrot/02-op-math.ok t/00-parrot/03-op-logicok t/00-parrot/04-op-cmp..ok t/00-parrot/05-var-array...ok t/00-parrot/05-var.ok t/00-parrot/06-op-inplace..ok t/00-parrot/07-op-string...ok t/00-parrot/08-regex...ok t/01-sanity/01-tap.ok t/01-sanity/02-counter.ok t/01-sanity/03-equal...ok t/01-sanity/04-if..ok t/01-sanity/05-sub.ok t/01-sanity/06-use.ok t/01-sanity/07-binding.ok t/01-sanity/07-defined.ok t/01-sanity/07-end-blocks..ok t/01-sanity/07-for.ok t/01-sanity/07-isa.ok t/01-sanity/07-range...ok t/01-sanity/07-ref.ok t/01-sanity/07-simple-multisubsok t/01-sanity/07-split...ok t/01-sanity/07-substr..ok t/01-sanity/07-try.ok t/01-sanity/08-say.ok t/01-sanity/09-types...ok All tests successful. Files=28, Tests=232, 82 wallclock secs ( 0.36 usr 0.29 sys + 71.43 cusr 6.98 csys = 79.06 CPU) Result: PASS prove t/pmc t/pmc/mutable...ok t/pmc/mutablevarok t/pmc/perl6multisub-arity...ok t/pmc/perl6multisub-basic...ok t/pmc/perl6multisub-tiebreakok t/pmc/perl6multisub-typeok All tests successful. Files=6, Tests=39, 8 wallclock secs ( 0.10 usr 0.08 sys + 6.45 cusr 1.21 csys = 7.84 CPU) Result: PASS make -C /Users/jimk/work/parrot codetest /usr/local/bin/perl t/harness --gc-debug --running-make-test --code-tests t/distro/file_metadata.# Collecting svn:mime-type attributes... t/distro/file_metadata.1/5 # Collecting svn:keywords attributes... t/distro/file_metadata.3/5 # Collecting svn:eol-style attributes... t/distro/file_metadata.4/5 # Collecting svn:eol-style attributes... t/distro/file_metadata.ok t/codingstd/c_code_codaok t/codingstd/c_cppcomments..ok t/codingstd/c_header_guardsok t/codingstd/c_indent...ok t/codingstd/c_macro_args...ok t/codingstd/c_operator.ok t/codingstd/c_parens...ok t/codingstd/c_returns..ok t/codingstd/c_struct...ok t/codingstd/check_isxxxok t/codingstd/check_toxxxok t/codingstd/copyright..ok t/codingstd/cuddled_else...ok t/codingstd/filenames..ok t/codingstd/gmt_utcok t/codingstd/linelength.ok t/codingstd/pccmethod_deps.ok t/codingstd/pdd_format.ok t/codingstd/perlcritic.ok t/codingstd/pir_code_coda..ok t/codingstd/svn_id.ok t/codingstd/tabs...ok t/codingstd/trailing_space.ok All tests successful. Files=24, Tests=374, 960 wallclock secs ( 0.64 usr 0.37 sys + 628.56 cusr 28.01 csys = 657.58 CPU) Result: PASS
Re: [perl #57530] Fwd: Parallelize the Perl 6 tests
2008/9/11 James Keenan via RT [EMAIL PROTECTED]: Moritz, I applied parallel-r.patch to trunk at r30978 on Darwin (10.4 PPC), successfully built and tested Parrot, built Perl 6, then got the results below out of 'make test'. Since I build and test Perl 6 infrequently, I'm not sure whether these results are different from what I would have gotten without the patch applied. But everything passed! Wrong make target. You have to run $ cd languages/perl6 $ make spectest_regression to test this patch and the speed difference. Thank you very much. kid51 /usr/local/bin/perl t/harness t/00-parrot t/01-sanity t/00-parrot/01-literalsok t/00-parrot/02-op-math.ok t/00-parrot/03-op-logicok t/00-parrot/04-op-cmp..ok t/00-parrot/05-var-array...ok t/00-parrot/05-var.ok t/00-parrot/06-op-inplace..ok t/00-parrot/07-op-string...ok t/00-parrot/08-regex...ok t/01-sanity/01-tap.ok t/01-sanity/02-counter.ok t/01-sanity/03-equal...ok t/01-sanity/04-if..ok t/01-sanity/05-sub.ok t/01-sanity/06-use.ok t/01-sanity/07-binding.ok t/01-sanity/07-defined.ok t/01-sanity/07-end-blocks..ok t/01-sanity/07-for.ok t/01-sanity/07-isa.ok t/01-sanity/07-range...ok t/01-sanity/07-ref.ok t/01-sanity/07-simple-multisubsok t/01-sanity/07-split...ok t/01-sanity/07-substr..ok t/01-sanity/07-try.ok t/01-sanity/08-say.ok t/01-sanity/09-types...ok All tests successful. Files=28, Tests=232, 82 wallclock secs ( 0.36 usr 0.29 sys + 71.43 cusr 6.98 csys = 79.06 CPU) Result: PASS prove t/pmc t/pmc/mutable...ok t/pmc/mutablevarok t/pmc/perl6multisub-arity...ok t/pmc/perl6multisub-basic...ok t/pmc/perl6multisub-tiebreakok t/pmc/perl6multisub-typeok All tests successful. Files=6, Tests=39, 8 wallclock secs ( 0.10 usr 0.08 sys + 6.45 cusr 1.21 csys = 7.84 CPU) Result: PASS make -C /Users/jimk/work/parrot codetest /usr/local/bin/perl t/harness --gc-debug --running-make-test --code-tests t/distro/file_metadata.# Collecting svn:mime-type attributes... t/distro/file_metadata.1/5 # Collecting svn:keywords attributes... t/distro/file_metadata.3/5 # Collecting svn:eol-style attributes... t/distro/file_metadata.4/5 # Collecting svn:eol-style attributes... t/distro/file_metadata.ok t/codingstd/c_code_codaok t/codingstd/c_cppcomments..ok t/codingstd/c_header_guardsok t/codingstd/c_indent...ok t/codingstd/c_macro_args...ok t/codingstd/c_operator.ok t/codingstd/c_parens...ok t/codingstd/c_returns..ok t/codingstd/c_struct...ok t/codingstd/check_isxxxok t/codingstd/check_toxxxok t/codingstd/copyright..ok t/codingstd/cuddled_else...ok t/codingstd/filenames..ok t/codingstd/gmt_utcok t/codingstd/linelength.ok t/codingstd/pccmethod_deps.ok t/codingstd/pdd_format.ok t/codingstd/perlcritic.ok t/codingstd/pir_code_coda..ok t/codingstd/svn_id.ok t/codingstd/tabs...ok t/codingstd/trailing_space.ok All tests successful. Files=24, Tests=374, 960 wallclock secs ( 0.64 usr 0.37 sys + 628.56 cusr 28.01 csys = 657.58 CPU) Result: PASS -- Reini Urban http://phpwiki.org/ http://murbreak.at/
[perl #57530] Fwd: Parallelize the Perl 6 tests
On Thu Sep 11 08:30:49 2008, moritz wrote:
Since the feedback so far was mostly positive (and none defeating) I now
applied the patch. Thanks go to all contributers and testers.
If there are some problems with the test harness, please open a new
ticket.
FWIW: Here are the results I got when I ran make spectest_regression as
you advised.
Checked out revision 9.
cd t/spec svn up
At revision 9.
/usr/local/bin/perl t/harness --fudge --keep-exit-code --jobs
--tests-from-file=t/spectest_regression.data
t/spec/S02-builtin_data_types/anon_block.rakudo ok
===( 48 )==Use of
uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
t/spec/S02-builtin_data_types/array.rakudo. ok
t/spec/S02-builtin_data_types/array_extending.rakudo... ok
===( 40 )==Use of
uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
t/spec/S02-builtin_data_types/array_ref.rakudo. ok
t/spec/S02-builtin_data_types/bool.t... ok
===( 16 )==Use of
uninitialized value
Use of uninitialized value
===( 24 )==Use of
uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
t/spec/S02-builtin_data_types/flattening.rakudo ok
===( 12 )==Use of
uninitialized value
Use of uninitialized value
===( 16 )==Use of
uninitialized value
Use of uninitialized value
===( 24 )==Use of
uninitialized value
Use of uninitialized value
===( 32 )==Use of
uninitialized value
Use of uninitialized value
t/spec/S02-builtin_data_types/hash.rakudo.. ok
===( 32 )==Use of
uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
t/spec/S02-builtin_data_types/hash_ref.rakudo.. ok
t/spec/S02-builtin_data_types/nested_arrays.t.. ok
t/spec/S02-builtin_data_types/nested_pairs.t... ok
===( 7
)==error:imcc:syntax
error, unexpected IDENTIFIER, expecting '\n' ('_1')
in file 'EVAL_13' line 54
error:imcc:syntax error, unexpected IDENTIFIER, expecting '\n' ('_2')
in file 'EVAL_13' line 64
error:imcc:syntax error, unexpected IDENTIFIER, expecting '\n' ('_2')
in file 'EVAL_13' line 79
t/spec/S02-builtin_data_types/num.rakudo... ok
t/spec/S02-builtin_data_types/range.rakudo. ok
===( 1 )==Use of
uninitialized value
t/spec/S02-builtin_data_types/subscripts_and_context.rakudo ok
t/spec/S02-builtin_data_types/type.rakudo.. ok
t/spec/S02-literals/array-interpolation.rakudo. ok
t/spec/S02-literals/autoref.rakudo. ok
t/spec/S02-literals/hash-interpolation.rakudo.. ok
t/spec/S02-literals/hex_chars.t ok
t/spec/S02-literals/pairs.rakudo... ok
t/spec/S02-literals/radix.rakudo... ok
t/spec/S02-magicals/dollar-underscore.t ok
===( 3 )==Use of
uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
Use of uninitialized value
===( 24 )==Use of
uninitialized value
t/spec/S02-names_and_variables/perl.rakudo. ok
t/spec/S02-polymorphic_types/subset-code.t. ok
t/spec/S02-polymorphic_types/subset-range.t ok
t/spec/S02-whitespace_and_comments/one-pass-parsing.t.. ok
===( 32 )==Use of
uninitialized
[perl #46783] [TODO] [Perl] Use temporary files in smartlinks tests
Generating a CC to the list: On Wed Sep 10 16:07:58 2008, szbalint wrote: This TODO doesn't really make sense because the tests which would need to create proper temporary files do not actually create any files, they just read some and parse. Therefor I think this ticket can be resolved simply by removing the text from smartlinks.t referring to this ticket. szbalint's patch simply proposed deleting the 4 comments citing this RT. This, of course, forced me to start actually looking at these tickets ... ... which forced me to look at the smartlink.t test ... ... which, to run it, required me to install Moose ... ... which, in turn, required me to install half of CPAN ;-) kid51
[perl #46783] [TODO] [Perl] Use temporary files in smartlinks tests
On Wed Sep 10 16:07:58 2008, szbalint wrote: This TODO doesn't really make sense because the tests which would need to create proper temporary files do not actually create any files, they just read some and parse. Therefor I think this ticket can be resolved simply by removing the text from smartlinks.t referring to this ticket. szbalint also wrote on #parrot: I was thinking about taking RT #46783 , but when I looked at smartlinks.t it turned out the TODO-ed tests do not actually create files temporary or otherwise. I'm just a little confused now, is there some policy to create special test files to _read_ from, instead of using docs/pdds/pdd03_calling_conventions.pod' for example, or the todo is a false alarm? You are correct. (1) The one remaining TODO-ed test does not create files. No need for tempfiles there. (2) The four tests which make reference to this ticket need POD to test. If docs/pdds/pdd03_calling_conventions.pod has enough variety of POD functionality for the purpose of the smartlinks test, then I don't see a compelling reason to, e.g., create a tempdir and copy the POD file into that tempdir for the purpose of testing. So I applied your patch in r30979. I'll leave the RT open for a couple of days in case anyone objects to your/my rationale. Thank you very much. kid51
Re: Why Some MMD Tests Fail
jerry gay wrote: On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal [EMAIL PROTECTED] wrote: a) Do abstract base classes as currently implemented in Parrot serve any useful purpose? If not, eliminate them. can they be replaced by roles? Potentially, yes. In the case of the scalar PMC it would make quite a bit of sense as a role (composing in behavior common to scalar data types). For the default PMC it makes less sense. But then, I can see some argument there that default shouldn't be a PMC at all. Allison
Re: Why Some MMD Tests Fail
On Tuesday 09 September 2008 09:51:37 Allison Randal wrote: jerry gay wrote: can they be replaced by roles? Potentially, yes. In the case of the scalar PMC it would make quite a bit of sense as a role (composing in behavior common to scalar data types). For the default PMC it makes less sense. But then, I can see some argument there that default shouldn't be a PMC at all. When I revised vtable initialization, I reordered PMC class initialization to start at the top of the hierarchy and proceed in inheritance order. This means that PMCs can clone their parent vtables and override only the specific function pointers they provide. Abstract PMCs gave me a little trouble because they don't have vtables (they only exist as names). This isn't really a problem for core PMCs, because they can refer to functions defined in other PMCs as they all get compiled together into libparrot. That's a real violation of encapsulation for dynpmcs though, and it's the reason why we export some 12,000 functions from libparrot. In the case of MMD, we also need to initialize MMD table entries for roles and other abstract PMCs. We need a way of initializing vtable function pointers given a vtable and the name of a PMC, and then we can likely support both features. (We might even use the same mechanism for performing vtable swaps when a Key PMC stops holding an INTVAL and starts holding a STRING or a PMC, for example. Call it the ultimate in PIC.) -- c
Why Some MMD Tests Fail
The scalar PMC is abstract, but it contains multis that need registration with the MMD system at initialization time. PMCs containing multis register those multis in their Parrot_PMC name_class_init() functions. At least, non-abstract PMCs do. I ran into a similar problem with my vtable cloning work. We may need to initialize abstract PMCs somehow. -- c
Re: Why Some MMD Tests Fail
chromatic wrote: The scalar PMC is abstract, but it contains multis that need registration with the MMD system at initialization time. PMCs containing multis register those multis in their Parrot_PMC name_class_init() functions. At least, non-abstract PMCs do. I ran into a similar problem with my vtable cloning work. We may need to initialize abstract PMCs somehow. Yes. I changed scalar to a non-abstract PMC with init a few days ago, but reverted it. (Abstract with init doesn't work, because the abstract class is never registered with Parrot, and therefore doesn't exist for multiple dispatch.) The current top two options in my mind: a) Do abstract base classes as currently implemented in Parrot serve any useful purpose? If not, eliminate them. b) Should abstract base classes be participating in multiple dispatch? If not, move the multi declarations to other real classes. Allison
Re: Why Some MMD Tests Fail
On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal [EMAIL PROTECTED] wrote: a) Do abstract base classes as currently implemented in Parrot serve any useful purpose? If not, eliminate them. can they be replaced by roles? ~jerry
Re: Why Some MMD Tests Fail
On Monday 08 September 2008 07:36:51 jerry gay wrote: On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal [EMAIL PROTECTED] wrote: a) Do abstract base classes as currently implemented in Parrot serve any useful purpose? If not, eliminate them. can they be replaced by roles? Exactly my thought. We would need some way to: * mix in VTABLE and METHOD entries at initialization time (preferably in the former case by not referring to function pointers directly) * register MMD entries only once -- c
[perl #57492] [CAGE] Explore possible speedups of t/configure/*.t tests
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.
[perl #46823] [TODO] [Pir] Rewrite Resizeable*Array tests properly when exceptions are implemented
On Wed Aug 27 22:49:37 2008, cotto wrote: Most of these test wouldn't throw an exception anyway, since assigning to a positive out-of-bounds element simply resizes the array. (This excludes nonsensically large positive indicies, which should probably tested for.) I added exception handling for oob indicies to the one fixed array test in r30610, which still passes. I deleted the other references to this ticket. It's possible that out-of-bounds refers to negative indicies. I added some tests with exception handlers for those cases in r30611. If there are no objections, I'll mark this resolved after the weekend. Christoph Done.
Re: [perl #47503] [RFC] Remove config::init::defaults From configure tests
2008/8/29 James Keenan via RT [EMAIL PROTECTED]:
This dependence has been eliminated from 20 of the 76 current
configuration step tests. More to come.
On MinGW32 (ie gcc on Win32), there are new failure since r30361
D:\fperrad\Parrot\trunkperl t\steps\auto_msvc-01.t
1..39
ok 1 - use config::auto::msvc;
ok 2 - auto::msvc constructor returned defined value
ok 3 - The object isa auto::msvc
ok 4 - auto::msvc has description
C compiler failed (see test_1508.cco) at
lib/Parrot/Configure/Compiler.pm line 101
Parrot::Configure::Compiler::cc_build('Parrot::Configure=HASH(0x1e18ffc)')
called at config/auto/msvc.pm line 45
auto::msvc::_probe_for_msvc('Parrot::Configure=HASH(0x1e18ffc)')
called at config/auto/msvc.pm line 35
auto::msvc::runstep('auto::msvc=HASH(0x15d629c)',
'Parrot::Configure=HASH(0x1e18ffc)') called at t\steps\auto_msvc-01.t
line 39
# Looks like you planned 39 tests but only ran 4.
# Looks like your test died just after 4.
previously, all was fine :
D:\fperrad\Parrot\trunkperl t\steps\auto_msvc-01.t
1..44
ok 1 - use config::init::defaults;
ok 2 - use config::auto::msvc;
ok 3 - init::defaults constructor returned defined value
ok 4 - The object isa init::defaults
ok 5 - init::defaults has description
Set up gcc environment - 3.4.5 (mingw special)
ok 6 - init::defaults runstep() returned defined value
ok 7 - auto::msvc constructor returned defined value
ok 8 - The object isa auto::msvc
ok 9 - auto::msvc has description
ok 10 - runstep() returned true value
ok 11 - auto::msvc constructor returned defined value
ok 12 - The object isa auto::msvc
ok 13 - auto::msvc has description
ok 14 - _evaluate_msvc returned true value
ok 15 - Got expected result
ok 16 - Got expected msvc version string
ok 17 - auto::msvc constructor returned defined value
ok 18 - The object isa auto::msvc
ok 19 - auto::msvc has description
ok 20 - _evaluate_msvc returned true value
ok 21 - Got expected result
ok 22 - Got expected msvc version string
ok 23 - ccflags appropriately adjusted given MSVC version
ok 24 - auto::msvc constructor returned defined value
ok 25 - The object isa auto::msvc
ok 26 - auto::msvc has description
ok 27 - sub return value, as expected, not yet set
ok 28 - result, as expected, not yet set
ok 29 - sub return value, as expected, set to true value
ok 30 - Got expected result
ok 31 - msvcversion is undef, as expected
ok 32 - sub return value, as expected, set to true value
ok 33 - Got expected result
ok 34 - msvcversion is undef, as expected
ok 35 - sub return value, as expected, set to true value
ok 36 - Got expected result
ok 37 - msvcversion is undef, as expected
ok 38 - Got expected verbose output
ok 39 - Got expected MSVC version
ok 40 - Got expected result
ok 41 - Got expected MSVC version
ok 42 - Got expected result
ok 43 - Got expected verbose output
ok 44 - Completed all tests in t\steps\auto_msvc-01.t
kid51
[perl #47503] [RFC] Remove config::init::defaults From configure tests
On Fri Aug 29 13:58:19 2008, fperrad wrote: 2008/8/29 James Keenan via RT [EMAIL PROTECTED]: This dependence has been eliminated from 20 of the 76 current configuration step tests. More to come. On MinGW32 (ie gcc on Win32), there are new failure since r30361 Thanks for the report, François. Reverted in r30639. kid51
[perl #46823] [TODO] [Pir] Rewrite Resizeable*Array tests properly when exceptions are implemented
On Thu Oct 25 00:49:38 2007, pcoch wrote: To be totally honest I wish I knew. I'm just going through converting the todo items in code into RT tickets and sometimes the todo comments aren't necessarily all that clear as to what needs to be done. I'm also (unfortunately) not familiar enough with pir to see in the code of the tests what needs fixing otherwise I might have been able to expand a little in the ticket. I'm really sorry I can't be of more help here! Paul Most of these test wouldn't throw an exception anyway, since assigning to a positive out-of-bounds element simply resizes the array. (This excludes nonsensically large positive indicies, which should probably tested for.) I added exception handling for oob indicies to the one fixed array test in r30610, which still passes. I deleted the other references to this ticket. It's possible that out-of-bounds refers to negative indicies. I added some tests with exception handlers for those cases in r30611. If there are no objections, I'll mark this resolved after the weekend. Christoph
Re: [perl #58076] Configure tests fail with Can't store CODE items
On Tue, 26 Aug 2008, James Keenan via RT wrote: Patched two subs in Parrot::Configure and adjusted test files in r30583. Tested with triggers in hints files on Linux and Darwin. Thanks. That closes this ticket and just leaves us with the old familiar: t/steps/auto_warnings-01.Compilation failed with 'cc' # Looks like you planned 56 tests but only ran 15. dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 16-56 Failed 41/56 tests, 26.79% okay where I've told Configure.pl to use gcc, but the test still falls back on using the incorrect value of 'cc' that perl5 was built with. -- Andy Dougherty [EMAIL PROTECTED]
[perl #47503] [RFC] Remove config::init::defaults From configure tests
This dependence has been eliminated from 20 of the 76 current configuration step tests. More to come. kid51
[perl #58076] Configure tests fail with Can't store CODE items
Marking ticket resolved.
[perl #58076] Configure tests fail with Can't store CODE items
Patched two subs in Parrot::Configure and adjusted test files in r30583. Tested with triggers in hints files on Linux and Darwin. Thank you very much. kid51
[perl #58076] Configure tests fail with Can't store CODE items
# New Ticket Created by Andy Dougherty # Please include the string: [perl #58076] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58076 A number of Configure tests are faililng for me on Solaris 8/SPARC. Specifically, I see: Failed TestStat Wstat Total Fail List of Failed --- t/steps/auto_snprintf-01.t 255 6528038 34 22-38 t/steps/auto_warnings-01.t 255 6528056 80 17-56 t/steps/inter_progs-01.t255 6528044 56 17-44 All of these fail in the same way. Here's an example: prove -v t/steps/auto_snprintf-01.t t/steps/auto_snprintf-011..38 ok 1 - use config::init::defaults; ok 2 - use config::init::hints; ok 3 - use config::auto::attributes; ok 4 - use config::auto::aio; ok 5 - use config::auto::snprintf; ok 6 - init::defaults constructor returned defined value ok 7 - The object isa init::defaults ok 8 - init::defaults has description ok 9 - init::defaults runstep() returned defined value ok 10 - init::hints constructor returned defined value ok 11 - The object isa init::hints ok 12 - init::hints has description ok 13 - init::hints runstep() returned defined value ok 14 - auto::attributes constructor returned defined value ok 15 - The object isa auto::attributes ok 16 - auto::attributes has description ok 17 - auto::attributes runstep() returned defined value ok 18 - auto::aio constructor returned defined value ok 19 - The object isa auto::aio ok 20 - auto::aio has description ok 21 - auto::aio runstep() returned defined value Can't store CODE items at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_freeze.al) line 339, at lib/Parrot/Configure.pm line 509 # Looks like you planned 38 tests but only ran 21. # Looks like your test died just after 21. dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 22-38 Failed 17/38 tests, 55.26% okay Failed TestStat Wstat Total Fail List of Failed --- t/steps/auto_snprintf-01.t 255 6528038 34 22-38 Failed 1/1 test scripts. 17/38 subtests failed. Files=1, Tests=38, 9 wallclock secs ( 2.95 cusr + 2.62 csys = 5.57 CPU) Failed 1/1 test programs. 17/38 subtests failed. The problem is that the solaris hints file uses 'triggers' and the configure tests can't handle them. This can be reproduced on any operating system by introducing a simple 'trigger' in the appropriate hints file (see config/init/hints/solaris.pm for examples). -- Andy Dougherty [EMAIL PROTECTED]
Re: codingstd tests should pass in every release
From: Bernhard Schmalhofer [EMAIL PROTECTED] Date: Mon, 18 Aug 2008 14:28:47 +0200 On Mon, Aug 18, 2008 at 4:39 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: Perhaps make fulltest should run the make codetest target instead of make codingstd_tests? Thumbs up from me. Done in r30345. -- Bob
[perl #57492] [CAGE] Explore possible speedups of t/configure/*.t tests
A net total of 5 t/configure/*.t files were eliminated tonight as part of r30368 (RT 57780).
Re: codingstd tests should pass in every release
On Sun, Aug 17, 2008 at 10:21:18PM -0400, Bob Rogers wrote: From: James E Keenan [EMAIL PROTECTED] Date: Sun, 17 Aug 2008 19:55:02 -0400 Yes, when one of the 'make codingstd_tests' accumulates sufficient PASSes, we promote it to 'make test'. Those that are not yet passing can generally be described as: Requires cage-cleaner with vast number of tuits. . . . So, no, failures in these files are not from showstoppers. They're a TODO for my golden years (and those of several other Parrot developers). I committed a fuller explanation in r30292. Perhaps make fulltest should run the make codetest target instead of make codingstd_tests? The codetest target is the one that means run the codingstd tests that are part of 'make test'. This would allow make fulltest to still run the required subset of coding standard tests (i.e., the same ones as make test) without having to run the entire codingstd suite (which produces the ignorable failures). And we can remove the note from the release_manager guide entirely, since make fulltest will run exactly what we want (and any errors in coding tests are then significant). Pm
Re: codingstd tests should pass in every release
Will Coleda schrieb: On Mon, Aug 18, 2008 at 4:39 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Sun, Aug 17, 2008 at 10:21:18PM -0400, Bob Rogers wrote: From: James E Keenan [EMAIL PROTECTED] Date: Sun, 17 Aug 2008 19:55:02 -0400 Yes, when one of the 'make codingstd_tests' accumulates sufficient PASSes, we promote it to 'make test'. Those that are not yet passing can generally be described as: Requires cage-cleaner with vast number of tuits. . . . So, no, failures in these files are not from showstoppers. They're a TODO for my golden years (and those of several other Parrot developers). I committed a fuller explanation in r30292. Perhaps make fulltest should run the make codetest target instead of make codingstd_tests? The codetest target is the one that means run the codingstd tests that are part of 'make test'. This would allow make fulltest to still run the required subset of coding standard tests (i.e., the same ones as make test) without having to run the entire codingstd suite (which produces the ignorable failures). And we can remove the note from the release_manager guide entirely, since make fulltest will run exactly what we want (and any errors in coding tests are then significant). Pm +1 Thumbs up from me.
codingstd tests should pass in every release
I notice that docs/project/release_manager_guide.pod says (line 123): It is not necessary to quiet all the codingstd tests for a release. Since these tests are on make test (and hence visible to non-developers), and are being tested with Smolder in any case, I think this sentence is bad advice and should be removed. WDOT? -- Bob Rogers http://rgrjr.dyndns.org/
Re: codingstd tests should pass in every release
On Sunday 17 August 2008 09:29:14 Bob Rogers wrote: I notice that docs/project/release_manager_guide.pod says (line 123): It is not necessary to quiet all the codingstd tests for a release. Since these tests are on make test (and hence visible to non-developers), and are being tested with Smolder in any case, I think this sentence is bad advice and should be removed. WDOT? Not all of the codingstd tests are part of make test. There's a specific codingstd test target you can run separately. I estimate about 2/3 of the tests will pass. The others may or may not ever pass. For example, the macro parenthesization tests will never all pass. -- c
Re: codingstd tests should pass in every release
From: chromatic [EMAIL PROTECTED] Date: Sun, 17 Aug 2008 09:39:05 -0700 Not all of the codingstd tests are part of make test. There's a specific codingstd test target you can run separately. I estimate about 2/3 of the tests will pass. The others may or may not ever pass. For example, the macro parenthesization tests will never all pass. -- c Ah, I wasn't aware of that. In that case, I'll update release_manager_guide.pod to spell this out explicitly: The tests on make test must pass, but some on make codingstd are not expected to pass, and are therefore not showstoppers. -- Bob
Re: codingstd tests should pass in every release
Bob Rogers wrote: From: chromatic [EMAIL PROTECTED] Date: Sun, 17 Aug 2008 09:39:05 -0700 Not all of the codingstd tests are part of make test. There's a specific codingstd test target you can run separately. I estimate about 2/3 of the tests will pass. The others may or may not ever pass. For example, the macro parenthesization tests will never all pass. [snip] The tests on make test must pass, but some on make codingstd are not expected to pass, and are therefore not showstoppers. Yes, when one of the 'make codingstd_tests' accumulates sufficient PASSes, we promote it to 'make test'. Those that are not yet passing can generally be described as: Requires cage-cleaner with vast number of tuits. Some output from 'make codingstd_tests' being run right now: t/codingstd/c_function_docs1/1 # Failed test 'Functions documented' # at t/codingstd/c_function_docs.t line 94. # Functions lacking documentation in 114 files: # /Users/jimk/work/parrot/src/intlist.c # /Users/jimk/work/parrot/src/io/io.c ... requires cage-cleaner with vast tuits and knowledge of C ;-) t/codingstd/fixme..1/1 # Failed test 'FIXME strings' # at t/codingstd/fixme.t line 62. # FIXME strings found in 571 instances in 149 files: # file '/Users/jimk/work/parrot/src/io/io_layers.c', line 52: XXX # file '/Users/jimk/work/parrot/src/io/io_layers.c', line 55: FIXME ... requires cage-cleaner to open RTs and replace XXX, TODO or FIXME with ticket number; ptc come back, we need you! t/codingstd/pod_todo...1/1 # Failed test 'No todo items found' # at t/codingstd/pod_todo.t line 98. # got: '/Users/jimk/work/parrot/README_cygwin.pod # /Users/jimk/work/parrot/README_win32.pod # /Users/jimk/work/parrot/compilers/imcc/parser_util.c # /Users/jimk/work/parrot/compilers/imcc/pbc.c # /Users/jimk/work/parrot/compilers/imcc/reg_alloc.c # /Users/jimk/work/parrot/compilers/imcc/symreg.c # /Users/jimk/work/parrot/compilers/pge/PGE/Regex.pir # /Users/jimk/work/parrot/compilers/pirc/README.pod ... requires cage-cleaner who knows C, operating systems and all the languages we're building on Parrot. So, no, failures in these files are not from showstoppers. They're a TODO for my golden years (and those of several other Parrot developers). kid51
Re: codingstd tests should pass in every release
From: James E Keenan [EMAIL PROTECTED] Date: Sun, 17 Aug 2008 19:55:02 -0400 Yes, when one of the 'make codingstd_tests' accumulates sufficient PASSes, we promote it to 'make test'. Those that are not yet passing can generally be described as: Requires cage-cleaner with vast number of tuits. ;-} . . . So, no, failures in these files are not from showstoppers. They're a TODO for my golden years (and those of several other Parrot developers). kid51 So who says open source programmers have no job security? ;-} I committed a fuller explanation in r30292. Thanks for the update, -- Bob
[perl #57492] [CAGE] Explore possible speedups of t/configure/*.t tests
1 test eliminated in RT 57826.
[perl #57796] New cardinal file fails metadata tests.
# New Ticket Created by Will Coleda # Please include the string: [perl #57796] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57796 When adding new files to the repository, please be sure to not only add them to the manifest, but also to fixup their svn properties; You can run t/distro/file_metadata.t to see what the expected property values are. Cardinal is failing 3 of the tests in that file, which causes every smolder report to be marked as a failure. (This may raise other excellent questions about when to run tests, but for now, let's try to shoot for keeping as many smolder reports green as possible.) -- Will Coke Coleda
[perl #57492] [CAGE] Explore possible speedups of t/configure/*.t tests
# New Ticket Created by James Keenan # Please include the string: [perl #57492] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57492 At particle's request, in RT 56716 I consolidated multiple configuration step class tests in t/steps/*.t into, in most cases, one test file per step class. This led to a quicker test run, particularly on Win32, because fewer processes were being initiated. In this RT we will try to do the same for the tests in t/configure/ *.t. We will try to consolidate tests where possible, but only where that is appropriate given the subject matter of the tests. Thank you very much. kid51
[perl #56716] [TODO]: speed up the configure tests
Since we have achieved the single largest feasible speedup discussed in this thread -- consolidation of the steps in t/steps/ -- I am going to mark this ticket resolved. I am opening a new RT, 57492, calling for exploration of the feasibility of consolidating or otherwise speeding up the tests in t/configure/. Thank you very much. kid51
[perl #57386] Configure.pl tests create bad dirs in $TMP
On Tue Jul 29 11:08:30 2008, doughera wrote: After running the Configure.pl test suite, I'm seeing some annoying-to-remove directories staying behind in /tmp. $ ls -lR /tmp/qdEG6yqmCn/ qdEG6yqmCn/: total 16 drwxr-xr-x 3 doughera faculty 181 Jul 29 13:48 alpha/ qdEG6yqmCn/alpha: total 16 d-wxrx 2 doughera faculty 117 Jul 29 13:48 include/ qdEG6yqmCn/alpha/include: qdEG6yqmCn/alpha/include: Permission denied I don't recall writing any tests which call for such strange permissions, but I will nonetheless look into this problem. Thank you very much. kid51
Re: [perl #56716] [TODO]: speed up the configure tests
On Tue, 29 Jul 2008, James Keenan via RT wrote: On Tue Jul 29 11:04:59 2008, doughera wrote: On Tue, 29 Jul 2008, James Keenan via RT wrote: The parallel branch does seem to run in about half the time. This is with perl-5.8.8 on Solaris/SPARC, where perl was built with Sun's cc, but I'm trying to build parrot with gcc. Here are the particulars. Thank you for taking the time to do this benchmarking. trunk: Failed TestStat Wstat Total Fail List of Failed --- t/steps/auto_warnings-01.t 255 6528021 12 16-21 t/steps/auto_warnings-02.t 255 6528020 10 16-20 t/steps/auto_warnings-03.t 255 6528020 10 16-20 t/steps/auto_warnings-04.t 255 6528021 12 16-21 t/steps/auto_warnings-05.t 255 6528021 12 16-21 t/steps/auto_warnings-06.t 255 6528022 14 16-22 t/steps/auto_warnings-07.t 255 6528021 12 16-21 t/steps/auto_warnings-08.t 255 6528022 14 16-22 16 tests and 1 subtest skipped. Failed 8/287 test scripts. 48/3945 subtests failed. Files=287, Tests=3945, 910 wallclock secs (388.00 cusr + 84.00 csys = 472.00 CPU) Since the tests in auto_warnings* are failing in both trunk and branch, I suspect the problem is with the tests themselves rather than my refactoring. IIRC, there was an older ticket (47395 ?) you filed about this. Perhaps this is related. Yes. It's the same problem. That's why I didn't highlight it. branches/parallel: Failed TestStat Wstat Total Fail List of Failed --- t/steps/auto_snprintf-01.t 255 6528038 34 22-38 t/steps/auto_warnings-01.t 255 6528056 80 17-56 t/steps/inter_progs-01.t255 6528044 56 17-44 1 test and 67 subtests skipped. Failed 3/133 test scripts. 85/3331 subtests failed. Files=133, Tests=3331, 533 wallclock secs (202.64 cusr + 42.48 csys = 245.12 CPU) The new-looking failures all look like this: t/steps/inter_progs-01...Can't store CODE items at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_freeze.al) line 339, at lib/Parrot/Configure.pm line 509 Could this be a which version of Storable.pm problem? I don't think so. I tried using both 5.8.8 and 5.10.0 with whatever version of Storable they come with. I haven't dug into the code, but I expect it's a problem with the callbacks in the solaris hints. You can probably reproduce it by putting callbacks in the linux or darwin hints. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #57386] Configure.pl tests create bad dirs in $TMP
On Wed, 30 Jul 2008, James Keenan via RT wrote: On Tue Jul 29 11:08:30 2008, doughera wrote: After running the Configure.pl test suite, I'm seeing some annoying-to-remove directories staying behind in /tmp. $ ls -lR /tmp/qdEG6yqmCn/ qdEG6yqmCn/: total 16 drwxr-xr-x 3 doughera faculty 181 Jul 29 13:48 alpha/ qdEG6yqmCn/alpha: total 16 d-wxrx 2 doughera faculty 117 Jul 29 13:48 include/ qdEG6yqmCn/alpha/include: qdEG6yqmCn/alpha/include: Permission denied I don't recall writing any tests which call for such strange permissions, but I will nonetheless look into this problem. I suspect it's the icu tests. Or at least a quick 'grep' for 'alpha' and 'include' suggest it's the icu tests. -- Andy Dougherty [EMAIL PROTECTED]
[PATCH] Re: [perl #57386] Configure.pl tests create bad dirs in $TMP
On Wed, 30 Jul 2008, James Keenan via RT wrote:
On Tue Jul 29 11:08:30 2008, doughera wrote:
After running the Configure.pl test suite, I'm seeing some
annoying-to-remove directories staying behind in /tmp.
$ ls -lR /tmp/qdEG6yqmCn/
qdEG6yqmCn/:
total 16
drwxr-xr-x 3 doughera faculty 181 Jul 29 13:48 alpha/
qdEG6yqmCn/alpha:
total 16
d-wxrx 2 doughera faculty 117 Jul 29 13:48 include/
qdEG6yqmCn/alpha/include:
qdEG6yqmCn/alpha/include: Permission denied
I don't recall writing any tests which call for such strange
permissions, but I will nonetheless look into this problem.
Ahh -- it's just an octal/decimal mix-up. Here's the patch:
--- parrot-current/t/steps/auto_icu-01.t2008-07-30 13:45:19.0
-0400
+++ parrot-andy/t/steps/auto_icu-01.t 2008-07-30 14:15:44.0 -0400
@@ -228,7 +228,7 @@
my $expected_include_dir =
$expected_dir . $conf-data-get('slash') . q{include};
mkdir $expected_dir or croak Unable to make testing directory;
-mkpath($expected_include_dir, 0, 755)
+mkpath($expected_include_dir, 0, 0755)
or croak Unable to make second-level testing directory;
($icuheaders, $without) =
$step-_handle_icuheaders($conf, qq{$expected_dir\n}, 0);
Mind you, the directories still aren't cleaned up automatically, but this
at least makes that less tedious.
--
Andy Dougherty [EMAIL PROTECTED]
