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.
Re: [perl #60926] [BUG] t/compilers/imcc/syn/macro.t 'unterminated macro 2' fails on Darwin PPC
On Nov 29, 2008, at 11:16 PM, chromatic wrote: If you're continuing to bisect to the offending patch, you don't need to update the ticket with ranges is useful. If you can't narrow it down further that's one thing, but if you haven't hit the limit of what you can find, I don't need these mini-status updates to help me fix it. I haven't hit the limit of what I can find -- but that's because the machine on which I observed this failure is slow and I can't do that many bisects in one session. So posting where I leave off at night may permit someone else to pick up the bisecting process and work on a solution. Thank you very much. kid51
Re: [perl #60068] [BUG] t/pmc/packfile.t: set_integer_keyed_str test failing on Darwin PPC
chromatic wrote: On Tuesday 28 October 2008 20:07:18 James Keenan via RT wrote: Still failing as of r32225; cf http://smolder.plusthree.com/app/public_projects/tap_stream/7437/260 not ok 6 - set_integer_keyed_str # Failed test 'set_integer_keyed_str' # at t/pmc/packfile.t line 140. # Exited with error code: [SIGNAL 11] # Received: # # Expected: # not equal # Can you post a backtrace? -- c Have been on vacation with poor net access, so I haven't been able to respond to much. I don't actually know how to do a backtrace. Can you instruct or post link to how this would interact with 'perl thistest' or 'prove thistest'? Thank you very much. kid51
Re: Parrot doesn't build on OS X
[EMAIL PROTECTED] wrote: Just a data point - fresh svn on a Macbook pro x86 failsr3205: [snip] auto::readline - Does your platform support readline...dyld: lazy symbol binding failed: Symbol not found: _rl_get_keymap Referenced from: /usr/share/cvs/afbach/parrot/./test_51162 Expected in: dynamic lookup dyld: Symbol not found: _rl_get_keymap Referenced from: /usr/share/cvs/afbach/parrot/./test_51162 Expected in: dynamic lookup ...no. It's bck! The same problem we were struggling with last March, and again at the Parrot build fest at YAPC. Cf. the never fully resolved: http://rt.perl.org/rt3/Ticket/Display.html?id=52212 kid51
Re: Parrot doesn't build on OS X
Ovid wrote: For the past few days, Parrot has failed to build on my MacBook. Today I moved my parrot directory and did a fresh svn checkout. perl Configure.pl ran fine without problem. make does fine until about here: $ make Compiling with: xx.c /usr/bin/gcc-4.0 loads of output skipped... make -C compilers/pge perl -MExtUtils::Command -e rm_f PGE.pbc ../../runtime/parrot/library/PGE.pbc perl -e PGE/builtins_gen.pir ../../parrot -o PGE.pbc --output-pbc PGE.pir ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg make[1]: *** [PGE.pbc] Bus error make[1]: *** Deleting file `PGE.pbc' make: *** [compilers.dummy] Error 2 Is this the same problem as being reported in http://rt.perl.org/rt3/Ticket/Display.html?id=60178 ?
Re: New Parrot mailing list
Allison sent me this reply: On Sep 19, 2008, at 3:42 AM, Allison Randal wrote: James E Keenan wrote: Does this mean that the newsgroup perl.perl6.internal on nntp.perl.org is dying as well? If so, I think that will be a real loss. I vastly prefer the news interface to a mailing list for following such groups. I set up the Google Group, because I know a number of people are using it. Can I see a show of hands of people who are only using NNTP and would have difficulty switching to a regular email subscription or Google Group? (I can't send to a newsgroup from my email client, so Jim, could you forward this on?) And I wish this had been discussed publicly before this announcement!) I mentioned it on #parrotsketch and other places. It's part of the general migration away from perl.org infrastructure. Allison
Re: New Parrot mailing list
Allison Randal wrote: James E Keenan wrote: I set up the Google Group, because I know a number of people are using it. Can I see a show of hands of people who are only using NNTP and would have difficulty switching to a regular email subscription or Google Group? (I can't send to a newsgroup from my email client, so Jim, could you forward this on?) And only just now found that Jim had CC'd the parrot mailing list as well as the news group that I wasn't able to reply to. I wouldn't be sad to see NNTP go. Allison: That's false. I replied to the newsgroup, which is mirrored by the mailing list. Whenever I've posted to the list (independent of posts to RT), the posts have been mirrored by the mailing list. You asked we to forward this on, so I did exactly what I've done for hundreds of other posts over the last two years.
Re: New Parrot mailing list
Allison Randal wrote: The new Parrot mailing list (replacing perl6-internals/parrot-porters) is [EMAIL PROTECTED]. If you were subscribed to the old list, you're now subscribed to the new list. If you were a digest subscriber to the old list, you're now a digest subscriber to the new list. More information about the list and public archives are available at: http://lists.parrot.org/mailman/listinfo/parrot-dev Does this mean that the newsgroup perl.perl6.internal on nntp.perl.org is dying as well? If so, I think that will be a real loss. I vastly prefer the news interface to a mailing list for following such groups. (And I wish this had been discussed publicly before this announcement!) kid51
Re: Where did the toggle switch go?
Vasily Chekalkin wrote: Will Coleda wrote: On Thu, Sep 11, 2008 at 8:11 AM, James E Keenan [EMAIL PROTECTED] wrote: Is it just me ...? Yup. I've got same problems... This link not always appears on reply page. (In my case it's appears very rare...) Ah, so it's not just me! I had to completely exit the browser (SeaMonkey) and open and login anew. The toggle link then reappeared.
Re: [CAGE] Opportunities for Perl 5 programmers in Parrot project
James E Keenan wrote: 1. I will encourage all of you who wrote me to get Bitcard accounts (http://tinyurl.com/5eqcw8) so that you're eligible to post patches through our RT interface (http://rt.perl.org/rt3/Public). One of the 6 already has an RT account; the others of you should get one. I know that at least one of the five has acquired a Bitcard account. 2. I will file an RT for some cleanup work on the configuration steps tests and direct one person who specifically volunteered for that to that RT. (Of course, once an RT is filed, anyone can take a crack at it.) http://rt.perl.org/rt3/Ticket/Display.html?id=58740 3. I will file a separate RT for another project. This second RT will actually be a way to track progress on more than a dozen RTs focusing on smartlinks. I will encourage the other people who wrote me over the past night and day to work on those. http://rt.perl.org/rt3/Ticket/Display.html?id=58742 is the marker ticket, and thanks to szbalint we have resolved one of the 12 remaining underlying tickets. 4. Any other Perl 5 projects connected to Parrot we can have people work on? Please let me know. Here is a search query for our RT that will yield plenty of open tickets -- though they're not limited to Perl 5. They cover C and PIR as well. http://tinyurl.com/4kd4g8 Paul T Cochrane was the cage cleaner par excellence but hasn't been as active recently. So here are tickets that he opened that have not been resolved or rejected. Paul had a program to go through our source code searching for inline comments marked with TODO or XXX. The program would then open an RT with the substance of the code and, in the code itself, replace TODO or XXX with RT #n. This was cage cleaning with a top-of-the-line Electrolux! But what it meant was that many tickets were opened saying that something *ought* to be implemented but not necessarily explaining why. After all, the inline comment could have been written years previously. So when we're looking at this type of RT, we have to study the context carefully first to determine whether the TODO item should actually be done or not. If the former, we have to do it. Ladies and gentlemen, start your engines! kid51
Re: [CAGE] Opportunities for Perl 5 programmers in Parrot project
James E Keenan wrote: This post is addressed to those of you who (a) have Perl 5 programming skills and (b) have been lurking on the list or on #parrot without yet dipping your toes in the water. I have a number of projects, some of which are already in the form of RT tickets, some not, which require only Perl 5 programming skills and common sense. I would like to share the joys of cage-cleaning with others. Wow! I was getting responses within hours, and I got a total of 6 responses in 24 hours. That's much better than the response to any previous calls for volunteers I've put out in Parrot (or any other OS project, for that matter). I started to respond individually last night, but got even more responses during the day today. Better still, of the 6 responses I got, 5 are from people whose names I have not previously seen on the Parrot. 3 are from people who were previously unknown to me. 1 is from a person I know only from the YAPC list. And another is from a person who responded to a post I made about the joys of collective hacking on the Perl Seminar NY list two years ago! And, based on email addresses, at least two are from countries whose country identifiers I have not previously seen on our list! In fact, we're in the unusual position of being oversubscribed: more volunteers than we (or, at least, I have) at the moment. So what I'm going to do is this: 1. I will encourage all of you who wrote me to get Bitcard accounts (http://tinyurl.com/5eqcw8) so that you're eligible to post patches through our RT interface (http://rt.perl.org/rt3/Public). One of the 6 already has an RT account; the others of you should get one. 2. I will file an RT for some cleanup work on the configuration steps tests and direct one person who specifically volunteered for that to that RT. (Of course, once an RT is filed, anyone can take a crack at it.) 3. I will file a separate RT for another project. This second RT will actually be a way to track progress on more than a dozen RTs focusing on smartlinks. I will encourage the other people who wrote me over the past night and day to work on those. 4. Any other Perl 5 projects connected to Parrot we can have people work on? Please let me know. Thank you very much. kid51
[CAGE] Opportunities for Perl 5 programmers in Parrot project
This post is addressed to those of you who (a) have Perl 5 programming skills and (b) have been lurking on the list or on #parrot without yet dipping your toes in the water. I have a number of projects, some of which are already in the form of RT tickets, some not, which require only Perl 5 programming skills and common sense. I would like to share the joys of cage-cleaning with others. I'll describe them to you off-list. Contact me at jkeen at verizon dot net or ping kid51 on #parrot. Thanks.
Re: Beta of web services to fulfill smoke Queryability requirements.
I updated the wiki a little about this. http://www.perlfoundation.org/parrot/index.cgi?rfp_parrot_needs_better_smoke_reports
Re: [perl #57920] Patch suggestion for Parrot Configure test of AIO
Allison Randal wrote: James Keenan via RT wrote: 3. For future reference, submit bug reports to: [EMAIL PROTECTED] I recommend beginning Subject line with: [BUG]. And I recommend submitting patches as email attachment ending in : .txt (because that seems to render best in browsers, mail, news interfaces). Generally recommend attaching patches as files ending in .patch (as documented in docs/submissions.pod) for the sanity of the patch monsters. It makes patches immediately identifiable, versus large text files of output from some debugging process. Would you accept '*.patch.txt' as a compromise?
Re: [CAGE] clean up stray test files
Allison Randal wrote: Running 'make test' now fills the main directory of the repository with junk files like: test_98093.out test_37653.c test_98093.ldo test_97159.c The offending tests need to be modified to clean up after themselves. Are these happening notwithstanding the patches I applied for RTs 57956, 57958 and 58036? If so, could you please post the content of the straggler files? That way, I can identify whether they're a byproduct of configuration tests or not. Along the same lines, after deleting existing straggler files, could you run perl Configure.pl, with and without --test=configure, so that we can see whether they're coming from configuration itself or from the pre-configuration tests. Thank you very much. kid51
Re: Parrot 0.7.0 publicity
Bob Rogers wrote: I take that back; I did eventually conquer use.perl.org, but forgot to tick it off my list. I just submitted to use.perl.org, so if yours doesn't get through perhaps mine will. kid51
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: make fulltest failures
Bob Rogers wrote: *** gmake manifest_tests Failed Test Stat Wstat Total Fail Failed List of Failed t/manifest/02-regenerate_file.t1 256121 8.33% 5 Failed 1/5 test scripts, 80.00% okay. 1/47 subtests failed, 97.87% okay. I was not able to reproduce this. Can you send output of 'prove -v'? Thanks.
Re: make fulltest failures
Bob Rogers wrote: *** gmake codingstd_tests Failed Test Stat Wstat Total Fail Failed List of Failed t/codingstd/c_function_docs.t1 256 11 100.00% 1 t/codingstd/fixme.t 1 256 11 100.00% 1 t/codingstd/pdd_format.t 1 256 11 100.00% 1 Did *not* get any failures in pdd_format.t t/codingstd/pod_todo.t 1 256 11 100.00% 1 1 test and 1 subtest skipped. Failed 4/26 test scripts, 84.62% okay. 4/37 subtests failed, 89.19% okay. But, as discussed in other thread, these are non-showstoppers.
Re: [perl #55954] [PATCH]: Add 'make smolder_test' target
On Jul 18, 2008, at 3:37 AM, Bernhard Schmalhofer via RT wrote:
I was told on #parrot that you have to replace # TODO comments by
creating RT tickets and referencing the RT instead of the TODO.
Perhaps it would be simpler to just delete these comments. Please
advise. Thank you very much.
I think it is a good idea to centralize all interactions with svn.
So how about using $Parrot::Revision::current or PConfig{revision}
there?
Barney, I'm afraid I don't see what this has to do with application
of a Perl::Critic policy.
'make' concludes noisily on Darwin
Parrot has been building successfully, albeit slowly, for me on Darwin for several months now. But I must say that the very last line of 'make' output always shows a lot of warnings of multiple definitions of symbol. Can anyone evaluate these? Thanks. /usr/bin/g++ -o pbc_merge \ src/pbc_merge.o \ src/parrot_config.o \ src/string_primitives.o \ -L/Users/jimk/work/parrot/blib/lib -L/Users/jimk/work/parrot/ blib/lib -lparrot -lm -lgmp -lreadline -framework OpenGL -framework GLUT -lcrypto -lintl -undefined dynamic_lookup -L/sw/lib /usr/bin/ld: warning multiple definitions of symbol _str_dup src/string_primitives.o definition of _str_dup in section (__TEXT,__text) /Users/jimk/work/parrot/blib/lib/libparrot.dylib(string_primitives.o) definition of _str_dup /usr/bin/ld: warning multiple definitions of symbol _Parrot_char_digit_value src/string_primitives.o definition of _Parrot_char_digit_value in section (__TEXT,__text) /Users/jimk/work/parrot/blib/lib/libparrot.dylib(string_primitives.o) definition of _Parrot_char_digit_value /usr/bin/ld: warning multiple definitions of symbol _string_unescape_one src/string_primitives.o definition of _string_unescape_one in section (__TEXT,__text) /Users/jimk/work/parrot/blib/lib/libparrot.dylib(string_primitives.o) definition of _string_unescape_one /usr/bin/ld: warning multiple definitions of symbol _string_set_data_directory src/string_primitives.o definition of _string_set_data_directory in section (__TEXT,__text) /Users/jimk/work/parrot/blib/lib/libparrot.dylib(string_primitives.o) definition of _string_set_data_directory Here's how I wrap Configure.pl: #!/bin/sh echo MACOSX_DEPLOYMENT_TARGET is $MACOSX_DEPLOYMENT_TARGET CC=/usr/bin/gcc CX=/usr/bin/g++ /usr/local/bin/perl Configure.pl --cc=$CC --cxx=$CX --link=$CX \ --ld=$CX \ --configure_trace \ $@ Here's myconfig: [parrot] 518 $ cat myconfig Summary of my parrot 0.6.4 (r29599) configuration: configdate='Fri Jul 18 22:51:48 2008 GMT' Platform: osname=darwin, archname=darwin-2level jitcapable=1, jitarchname=ppc-darwin, jitosname=DARWIN, jitcpuarch=ppc execcapable=1 perl=/usr/local/bin/perl Compiler: cc='/usr/bin/gcc', ccflags='-fno-common -no-cpp-precomp -pipe - I/opt/local/include -pipe -fno-common -Wno-long-double - DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED - DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL - DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED - DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 - fvisibility=hidden -W -Wall -Waggregate-return -Wcast-align -Wcast- qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wendif- labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral - Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self - Winline -Winvalid-pch -Wmissing-braces -Wmissing-field-initializers - Wno-missing-format-attribute -Wmissing-include-dirs -Wpacked - Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno- shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch - Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused - Wvariadic-macros -Wwrite-strings -Wbad-function-cast -Wdeclaration- after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs - Wnonnull -I/sw/include -DHAS_GETTEXT', Linker and Libraries: ld='/usr/bin/g++', ldflags=' -L/opt/local/lib -L/Users/jimk/work/ parrot/blib/lib -L/sw/lib', cc_ldflags='', libs='-lm -lgmp -lreadline -framework OpenGL -framework GLUT - lcrypto -lintl' Dynamic Linking: share_ext='.dylib', ld_share_flags='-dynamiclib -undefined dynamic_lookup', load_ext='.bundle', ld_load_flags='-undefined dynamic_lookup - bundle' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=4321, nv=double, numvalsize=8, doublesize=8
Re: CPAN-Permissions for Perl 5 Modules
Bernhard Schmalhofer wrote: Hi, for Parrot 0.6.4 following Perl 5 modules were not indexed: Parrot::Configure::Options::Test::Prepare Parrot::Pmc2c::PMC::PrintTree Barney: I know that I wrote the two modules above (or, at least, refactored them into their current form). What, if anything, should I have done when I wrote/committed them. kid51 (who doesn't understand these indexing issues)
Re: Parallel branch
Will Coleda wrote: What's this branch for, out of curiosity? http://rt.perl.org/rt3/Ticket/Display.html?id=56716
Re: Parrot and Smolder
I forwarded this to parrotbug so that an RT is opened.
Re: Renaming Plumhead
Bernhard Schmalhofer wrote: Hi, As Plumhead is a stupid name, cotto proposed to rename to Pharrot. Problem: Pharrot in English is a homonym for ferret: http://en.wikipedia.org/wiki/Ferret. Are we really sure we want to saddle part of our project with that association? (OTOH, former NYC Mayor Rudy Giuliani fully exposed his sadistic streak when he berated a caller to his radio show for opposing the city ordinance against keeping ferrets as pets. That little incident helped sink his presidential bid -- thankfully, IMO.) kid51
Re: Parrot at YAPC::NA::2008 in Chicago June 16-18
James E Keenan wrote: A couple of points about YAPC: I've started a page on the YAPC Conference Wiki to provide YAPC attendees with information about our Parrot/Rakudo Buildfest. http://conferences.mongueurs.net/yn2008/wiki?node=Parrot%20and%20Perl%206%20Workshop Those of us who are organizing the Parrot/Rakudo Buildfest have set up a temporary mailing list for our planning. You can join it here: http://tech.groups.yahoo.com/group/parrot-yapc/ kid51
Re: NEWS, PLATFORMS, and make fulltest Results Wanted
chromatic wrote: Parrot 0.6.2 is on schedule for the 20 May release. In preparation, please gather up any NEWS you find important for your subsystem, please report any PLATFORMS updates, and please run make fulltest on every architecture you can find. Here's the one non-codingstd failure I got when running 'make fulltest' on Linux/386 at r27599 today. IIRC, this was the very first time I ever ran make fulltest, so judge results accordingly. make testj make[1]: Entering directory `/home/jimk/work/parrot' Compiling with: xx.c cc -I./include -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -fvisibility=hidden -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wbad-function-cast -Wc++-compat -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdeclaration-after-statement -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wimport -Winit-self -Winline -Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wvariadic-macros -Wwrite-strings -DHAS_GETTEXT -g -DHAS_JIT -DI386 -DHAVE_COMPUTED_GOTO -fPIC -I. -o xx.o -c xx.c [snip] /usr/local/bin/perl t/harness --gc-debug --running-make-test -j --runcore-tests [snip] t/compilers/imcc/syn/regressions. # Failed test 'cannot constant fold div by 0' # at t/compilers/imcc/syn/regressions.t line 19. # Exited with error code: [SIGNAL 8] # Received: # # Expected: # ok 1 - caught div_i_ic_ic exception # ok 2 - caught div_n_nc_nc exception # # Looks like you failed 1 test of 3. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/3 subtests
Re: [perl #42393] [TODO] regex - FIXME items in languages/regex/lib/Regex/Grammar.y
Patrick R. Michaud via RT wrote: plus I don't know that languages/regex is being used or maintained. I vote to remove languages/regex, either for the May 2008 release or soon thereafter. FWIW, svn status -v languages/regex/ suggests that François, Barney and chromatic have worked in this tree in the last year. So it's getting some degree of attention. kid51
Re: NEWS, PLATFORMS, and make fulltest Results Wanted
chromatic wrote: Parrot 0.6.2 is on schedule for the 20 May release. In preparation, please gather up any NEWS you find important for your subsystem, please report any PLATFORMS updates, and please run make fulltest on every architecture you can find. Running 'make fulltest' on Darwin/ppc (Mac OS X 10.4), during the 'make testj' part, I got an indefinite hang on t/compilers/pge/pge_examples.t I then called: /usr/local/bin/perl t/harness --gc-debug --running-make-test -j --runcore-test ... and got the same indefinite hang -- even thought the test passes 'prove' when run by itself: t/compilers/pge/pge_examples.1/2 ^C [parrot] 519 $ prove -v t/compilers/pge/pge_examples.tt/compilers/pge/pge_examples..1..2 ok 1 - This made Parrot m4 fail ok 2 - parse FASTA ok All tests successful. Files=1, Tests=2, 3 wallclock secs ( 0.03 usr 0.01 sys + 1.82 cusr 0.43 csys = 2.29 CPU) Result: PASS kid51
Re: Parrot at YAPC::NA::2008 in Chicago June 16-18
James E Keenan wrote: On the basis of doing two of these buildfests in the past month, I would say that TAs are what we *most* need. Except for the first 5 and last 10 minutes of the session, all the Parrot team members present will be moving around the room coaching people on how to configure and build Parrot, then build Rakudo ... or any other language that, as of YAPC time, we can build on top of Parrot. This is not intended to be an expert standing in front of the room, lecturing for 75 minutes, then taking questions type of presentation. So far, other than Bob Rogers, no one has indicated that they would be willing to participate as a mentor/TA/co-leader of this workshop. This workshop will be held on Wed June 18, 10:05 am. We could draw anywhere from 20-80 participants. On the basis of my experience at the build fests in Toronto and New York, I'd say we should try to get 1 mentor for every 8-12 attendees. If you are willing to work on this with me, please sign up *in advance of YAPC* on our wiki: http://www.perlfoundation.org/parrot/index.cgi?yapc_na_2008 Thank you very much. Jim Keenan
Re: [perl #53142] [TODO] Cage-cleaner's request: PDD for configuration; Create RTs for new or heavily modified config steps
On May 7, 2008, at 10:35 PM, Geoffrey Broadwell via RT wrote: On Wed, 2008-05-07 at 18:22 -0700, James Keenan via RT wrote: On Sun Apr 20 19:01:44 2008, [EMAIL PROTECTED] wrote: I would like to propose both short-term and long-term remedies. Short-term: If you are proposing a new configuration step, or doing a significant overhaul of any existing step, please post an RT with the code and with a [TODO] tag several days ahead of time. This will give people a chance to run it on different OSes right away, without compromising trunk. And if I get advance notice of any new config step, I pledge to work with you to develop tests for that step. Since I filed this RT, two completely new configuration step classes have been added -- neither of which was preceded by an RT. So it is evident that the committers do not like this suggestion. I hope that you are not referring to config/gen/call_list here -- I definitely tried to follow your request. I created my patch only after specifically asking you for anything you wanted from a new config step. My error. I was too hasty. You did follow the procedure I recommended.
RT Needs Cage Tag
At ny.pm tonight, I was discussing the joys and sorrows of Parrot cage cleaning with one attendee. I just discovered that while you can search the newsgroup for the string 'cage' in a posting's subject line, there is no 'cage' tag in our RT system. So you can't construct a query string as you can for 'patch' or 'todo'. Can we remedy this? Thank you very much. kid51
Re: Parrot at YAPC::NA::2008 in Chicago June 16-18
Bob Rogers wrote: I don't expect to be able to co-lead (since, for one thing, that would require putting in significant time in advance), but I would be willing to help TA such a thing. I suspect it would be valuable to have a number of TAs with diverse areas of trouble-shooting expertise, since (for example) I would be pretty useless if someone was having build problems on Windows. On the basis of doing two of these buildfests in the past month, I would say that TAs are what we *most* need. Except for the first 5 and last 10 minutes of the session, all the Parrot team members present will be moving around the room coaching people on how to configure and build Parrot, then build Rakudo ... or any other language that, as of YAPC time, we can build on top of Parrot. This is not intended to be an expert standing in front of the room, lecturing for 75 minutes, then taking questions type of presentation. So I look forward to seeing you there and working with you. Jim Keenan
YAPC::NA::2008 status updates needed
1. If you have had a Parrot- or Rakudo-oriented presentation accepted at YAPC::NA::2008 in Chicago, please add your name and presentation's name to: http://www.perlfoundation.org/parrot/index.cgi?yapc_na_2008 2. The Parrot/Rakudo buildfest workshop has been accepted. If you are able to be present during this session and help coach people to get to Hello World either in Perl 6 on Parrot -- or in any other language on Parrot -- then please add your name to the Parrot and Rakudo Buildfest section of the page cited above. Thank you very much. kid51
Re: [svn:parrot] r27051 - trunk/t/steps
chromatic wrote: On Saturday 19 April 2008 17:06:44 [EMAIL PROTECTED] wrote: Author: jkeenan Date: Sat Apr 19 17:06:44 2008 New Revision: 27051 Added: trunk/t/steps/auto_opengl-03.t - copied, changed from r27050, /trunk/t/steps/auto_opengl-02.t Modified: trunk/t/steps/auto_opengl-02.t Log: Add file to test auto::opengl internal subs where verbose output has been requested. Why a separate file? The Parrot::Configure object is a singleton. From my experiences over the past year, I have found that this means it's difficult to test all the effects of different command-line options in a single file. The more complex the code in a given config step's runstep() method, the more individual objects have to be created, which leads to more files. Thank you very much. kid51
Re: parrot benchmarking
Tim Bunce wrote:
I'd suggest a simpler approach than Geoffrey's: The default 'make'
target could default to a reasonably safe portable optimized target, but
be overridable by an env var.
[snip]
Developers working on parrot (wanting unoptimized/debug quick builds)
would just need to set an env var in their .profile, for example, and
carry on as now. No changes in their procedures, and no changes in the
docs (other than to mention the env var).
If I understand the configuration system correctly, we currently handle
this via flags to Configure.pl:
--optimize Optimized compile
--optimize=flags Add given optimizer flags
(I'm attaching config/init/optimize.pm for reference.)
Would there be something gained by using env vars rather than (or in
addition to) the configuration options?
kid51
# Copyright (C) 2001-2005, The Perl Foundation.
# $Id: optimize.pm 24769 2008-01-12 01:22:59Z jkeenan $
=head1 NAME
config/init/optimize.pm - Optimization
=head1 DESCRIPTION
Enables optimization by adding the appropriate flags for the local platform to
the CCCFLAGS. Should this be part of config/inter/progs.pm ? XXX
=cut
package init::optimize;
use strict;
use warnings;
use base qw(Parrot::Configure::Step);
sub _init {
my $self = shift;
my %data;
$data{description} = q{Enabling optimization};
$data{result} = q{};
return \%data;
}
our $verbose;
sub runstep {
my ( $self, $conf ) = @_;
$verbose = $conf-options-get( 'verbose' );
print \n if $verbose;
print (optimization options: init::optimize)\n
if $verbose;
# A plain --optimize means use perl5's $Config{optimize}. If an argument
# is given, however, use that instead.
my $optimize = $conf-options-get('optimize');
if ( defined $optimize ) {
$self-set_result('yes');
# disable debug flags
$conf-data-set( cc_debug = '' );
$conf-data-add( ' ', ccflags = -DDISABLE_GC_DEBUG=1 -DNDEBUG );
if ( $optimize eq 1 ) {
# use perl5's value
# gcc 4.1 doesn't like -mcpu=xx, i.e. it's deprecated
my $opts = $conf-data-get_p5('optimize');
my $gccversion = $conf-data-get( 'gccversion' );
my $arch_opt = 'cpu';
if ( defined $gccversion and $gccversion 3.3 ) {
$arch_opt = 'arch';
}
$opts =~ s/-mcpu=/-m$arch_opt=/;
$conf-data-add( ' ', ccflags = $opts );
print opts: , $opts, \n if $verbose;
# record what optimization was enabled
$conf-data-set( optimize = $opts );
}
else {
# use what was passed to --optimize on the CLI
$conf-data-add( ' ', ccflags = $optimize );
# record what optimization was enabled
$conf-data-set( optimize = $optimize );
}
}
else {
$self-set_result('no');
print (none requested) if $conf-options-get('verbose');
}
return 1;
}
1;
# Local Variables:
# mode: cperl
# cperl-indent-level: 4
# fill-column: 100
# End:
# vim: expandtab shiftwidth=4:
Re: [PATCH] Re: build failure with gmake on Solaris
Andy Dougherty wrote:
On Sun, 13 Apr 2008, James E Keenan wrote:
[snip]
/opt/SUNWspro/bin/CC -o miniparrot src/main.o \
-L/home/kid51/work/parrot/blib/lib -lparrot -lsocket -lnsl -ldl -lm
-lpthread -lrt -lgmp -lcrypto -L/usr/lib -L/usr/ccs/lib
-L/opt/SUNWspro/prod/lib/sparc -L/opt/SUNWspro/prod/lib -L/lib
-L/usr/local/lib -xlibmieee src/null_config.o
ld: fatal: library -lgmp: not found
ld: fatal: library -lcrypto: not found
ld: fatal: File processing errors. No output written to miniparrot
gmake: *** [miniparrot] Error 1
It's not clear why 'ld' failed to find gmp or crypto, because Configure.pl
located them without difficulty.
(Incidentally -- gmake is not necessary. I don't know why Configure.pl
suggests it.
DDMPK51: See this code from config/inter/make.pm:
# check the candidates for a 'make' program in this order:
# environment ; option ; probe ; ask ; default
# first pick wins. On cygwin prefer make over nmake.
$prog ||= $ENV{ uc($util) };
$prog ||= $conf-options-get($util);
$prog ||= check_progs( $^O eq 'cygwin' ? ['gmake', 'make'] :
['gmake', 'mingw32-make', 'nmake', 'make'], $verbose );
'gmake' wins where it's available.
You should try regular 'make' instead (you may have to
add /usr/ccs/bin to your PATH). If you want to check out parallel builds,
you can try 'dmake' if it's installed.)
This failure is probably due to the order of the arguments to CC.
Traditional Unix linkers look things up in the order specified on the
command line. You don't say where libgmp and libcrypto are installed, but
I'll guess they are in /usr/local/lib.
I'm beginning to suspect that this is a more general problem in our
configuration system. For example, problems we've been having recently
with config/auto/readline.pm, config/auto/gdbm.pm,
config/auto/crypto.pm. The presence of '-lgmp -lcrypto -L/usr/lib
-L/usr/ccs/lib' above in a situation where something didn't work is
reminiscent of '-lgdbm -L/sw/lib' in cases where, on Darwin, we've
installed a library with Fink and either can't locate it or have a
testing problem.
[snip]
1. Use rsync. rsync is very useful for this, when it works.
Unfortunately, the parrot rsync server tends to be a bit unreliable,
but it's working today. Use something like:
rsync -avz --delete svn.perl.org::parrot-HEAD parrot-current
(rsync is not standard on solaris -- you'd have to build your own.)
As I learned the hard way; goes on my Solaris TODO list.
[snip]
3. Fetch the current snapshots with something like
wget http://svn.perl.org/snapshots/parrot/parrot-latest.tar.gz
(wget is not standard on solaris -- you'd have to build your own.)
As I learned the hard way; goes on my Solaris TODO list.
[snip]
Thanks for the feedback. I suspect I'm going to have to set one
day/night a week to these Solaris problems, because it's more unlike
other *nix environments where I've worked.
kid51
Re: build failure with gmake on Solaris
Will check on all these things next time I get tuits for Solaris work.
build failure with gmake on Solaris
I recently obtained shell accounts on some Solaris boxes. Today I made my first attempt to compile and build Parrot on one of them. Configuration was very smooth. See log attached. Note for reference: Determining if your platform supports GMP.yes. ... Determining if your platform supports crypto..yes, 0.9.8g. At the completion of configuration, I was prompted to use gmake to build. The build generated many warning: statement not reached messages. (See log attached.) Then the build failed completely here: /opt/SUNWspro/bin/CC -o miniparrot src/main.o \ -L/home/kid51/work/parrot/blib/lib -lparrot -lsocket -lnsl -ldl -lm -lpthread -lrt -lgmp -lcrypto -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro/prod/lib/sparc -L/opt/SUNWspro/prod/lib -L/lib -L/usr/local/lib -xlibmieee src/null_config.o ld: fatal: library -lgmp: not found ld: fatal: library -lcrypto: not found ld: fatal: File processing errors. No output written to miniparrot gmake: *** [miniparrot] Error 1 It's not clear why 'ld' failed to find gmp or crypto, because Configure.pl located them without difficulty. So I never got to 'gmake test'. 'myconfig' and the output of uname are attached. Since this is a shell account on an OS on which I am just beginning, debugging will not be that easy for me. It appears 'svn' is not available. Suggestions? kid51 [parrot] 42 $ gmake gmake test Compiling with: xx.c /opt/SUNWspro/bin/cc -I./include -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHASATTRIBUTE_CONST -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -g -DHAVE_COMPUTED_GOTO -KPIC -I. -o xx.o -c xx.c perl tools/build/vtable_extend.pl perl tools/build/pbcversion_h.pl include/parrot/pbcversion.h perl tools/build/ops2pm.pl src/ops/core.ops src/ops/bit.ops src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops src/ops/set.ops src/ops/stack.ops src/ops/stm.ops src/ops/string.ops src/ops/sys.ops src/ops/var.ops gcd_i_n_n 1223 experimental, not in ops.num gcd_i_nc_n1224 experimental, not in ops.num gcd_i_n_nc1225 experimental, not in ops.num gcd_i_nc_nc 1226 experimental, not in ops.num gcd_i_i_i_i_i 1227 experimental, not in ops.num gcd_i_i_i_ic_i1228 experimental, not in ops.num gcd_i_i_i_i_ic1229 experimental, not in ops.num gcd_i_i_i_ic_ic 1230 experimental, not in ops.num splice_p_p_i_i1231 experimental, not in ops.num splice_p_p_ic_i 1232 experimental, not in ops.num splice_p_p_i_ic 1233 experimental, not in ops.num splice_p_p_ic_ic 1234 experimental, not in ops.num slice_p_p_k 1235 experimental, not in ops.num slice_p_p_kc 1236 experimental, not in ops.num slice_p_p_k_ic1237 experimental, not in ops.num slice_p_p_kc_ic 1238 experimental, not in ops.num iter_p_p 1239 experimental, not in ops.num morph_p_i 1240 experimental, not in ops.num morph_p_ic1241 experimental, not in ops.num morph_p_s 1242 experimental, not in ops.num morph_p_sc1243 experimental, not in ops.num exec_s1244 experimental, not in ops.num exec_sc 1245 experimental, not in ops.num classname_p_p 1246 experimental, not in ops.num trap 1247 experimental, not in ops.num pow_n_n_i 1248 experimental, not in ops.num pow_n_nc_i1249 experimental, not in ops.num pow_n_n_ic1250 experimental, not in ops.num pow_n_nc_ic 1251 experimental, not in ops.num new_p_i_s 1252 experimental, not in ops.num new_p_ic_s1253 experimental, not in ops.num new_p_i_sc1254 experimental, not in ops.num new_p_ic_sc 1255 experimental, not in ops.num add_io_event_p_p_p_ic 1256 experimental, not in ops.num need_finalize_p 1257 experimental, not in ops.num setstdout_p 1258 experimental, not in ops.num setstderr_p 1259 experimental, not in ops.num runinterp_p_p 1260 experimental, not in ops.num runinterp_p_pc1261 experimental, not in ops.num substr_r_s_s_i_i 1262 experimental, not in ops.num substr_r_s_sc_i_i 1263 experimental, not in ops.num substr_r_s_s_ic_i 1264 experimental, not in ops.num substr_r_s_sc_ic_i1265 experimental, not in ops.num substr_r_s_s_i_ic
[Fwd: [svn:parrot-pdd] r26719 - trunk/docs/pdds]
A bunch of my SVN commits from yesterday suddenly showed up on the main list this morning -- and not from any (conscious) action on my part. Why are these showing up here and *not* in perl.cvs.parrot? (See: http://www.nntp.perl.org/group/perl.cvs.parrot/) Wouldn't it be better to have all commits show up in a single location? ---BeginMessage--- Author: jkeenan Date: Thu Apr 3 11:51:58 2008 New Revision: 26719 Modified: trunk/docs/pdds/pdd00_pdd.pod Log: Make PPD conform to coding standard for PDDs (https://rt.perl.org/rt3/Ticket/Display.html?id=52054). Modified: trunk/docs/pdds/pdd00_pdd.pod == --- trunk/docs/pdds/pdd00_pdd.pod (original) +++ trunk/docs/pdds/pdd00_pdd.pod Thu Apr 3 11:51:58 2008 @@ -14,6 +14,10 @@ This document defines the content and format of Parrot Design Documents (PDDs). +=head1 SYNOPSIS + +Not applicable. + =head1 DESCRIPTION PDDs are living documents, which should be maintained to reflect the current ---End Message---
Re: [perl #52416] [BUG] Test 4 of t/stm/runtime.t sigbus on ppc
Seneca Cunningham wrote: # New Ticket Created by Seneca Cunningham # Please include the string: [perl #52416] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52416 The ticket referred to in the prove -v output was resolved last year. I merged this ticket back into the original, which I reopened.
Re: [perl #51916] Error in tests after build
Ted Neward wrote: BTW, I didn't want to file a bug, but the Lua compiler in the latest bits uses a tool yapp that doesn't appear to be a part of the bundle--is it supposed to be? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com I don't think so ... but can our Lua experts respond to this?
Re: [perl #51916] Error in tests after build
Ted Neward wrote: Where do I get it? Is it part of the Parrot distro? No, and it appears not be part of Bundle::Parrot on CPAN, either. We'll have to rectify this. But you could always install it directly from CPAN: http://search.cpan.org/dist/Parse-Yapp/
Re: Parrot r26458 Darwin 10.5 (x86) results
[EMAIL PROTECTED] wrote: As of r26458 - configure has the readline issue: Determining if your platform supports readline...dyld: lazy symbol binding failed: Symbol not found: _rl_get_keymap Referenced from: /usr/share/cvs/parrot/./test Expected in: dynamic lookup dyld: Symbol not found: _rl_get_keymap Referenced from: /usr/share/cvs/parrot/./test Expected in: dynamic lookup We'll be fixing this one by applying a reversion patch: http://rt.perl.org/rt3/Ticket/Display.html?id=50056. I've periodically experienced the others you reported but am not currently getting them.
Re: Committer Reminder: Please Check RT
chromatic wrote: We have some 845 open tickets in RT, which is approximately 840 more than I'd like to see at any one time. I closed a dozen or so today. If every active committer could close one or two every week, we'd make real progress very shortly. And if you *really* have tuits available, you can take a look at our TODO list: http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=TagValue=Todo
Re: Parrot r26391 broken?
Alberto Simões wrote: Hi I can't compile Parrot on MacOS X 10.5.2: Final building messages are: i686-apple-darwin9-g++-4.0.1: sha256.o: No such file or directory i686-apple-darwin9-g++-4.0.1: sha512.o: No such file or directory partial link of digest_group failed (256) make[1]: *** [all] Error 2 make: *** [dynpmc.dummy] Error 2 Under discussion in http://rt.perl.org/rt3/Ticket/Display.html?id=51756
Re: Character sets PDD ready for review
Simon Cozens wrote: Simon Cozens wrote: I think I've finished doing what I can with docs/pdds/draft/pdd28_character_sets.pod for the time being. Please have a look at it, and let me know if there's anything wrong, anything unclear, anything missing or anything objectionable about it Warnock Warnock Warnock. Can I get a witness, even if it's Looks good but I don't understand it or Good luck, pal, but who do you think's going to implement it?? 1. Why is grapheme normalization form abbreviated as NFG rather than GNF? 2. If a character set is officially a deprecated term (by whom?), won't our use of it cause problems down the road -- even if we currently find it advantageous to use it to mean the standard which defines both a repertoire and a code? 3. A grapheme is our concept. Who is the we in our? 4. I'm very glad it's *not* written in man-page terse.
[TODO]: Parrot not detecting GMP
Alberto Simões wrote: Hi Latest parrot version (r26311) is not detecting GMP installed under /opt/local/lib/libgmp* (default location for macports). If I remember it correctly, previous versions detected it without any problem. Alberto: The only configuration step which makes specific reference to macports is config/auto/readline.pm: $ fnsa config '*.pm' | xargs grep -l macport config/auto/readline.pm Let me continue from an oblique angle. There are three configuration step classes which search for features that a user might have installed via Fink: auto::readline, auto::gdbm and auto::gmp. There was a lot of repeated Fink-finding code in these three steps, so I refactored that out into a separate module, config/auto/fink.pm. This searches for Fink in its default location and for a user-supplied alternate location. Because I use Fink myself, I was able to verify that this code works and, in particular, able to study the Fink configuration file which tells whether Fink is installed in its standard location or not. There are two reasons why I did this for Fink and not for macports: (1) Because when I took over maintenance of these modules, there was Fink code in 3 files and macports code only in 1 -- which is probably just a historical accident. (2) I've never used macports myself (is it the same as darwinports?) and I didn't want to install something solely for the purpose of weaving it into Parrot configuration steps. I wonder if you could look at the macport-specific code in config/auto/readline.pm and hack up config/auto/gmp.pm with the same or very similar code. If you then re-ran Configure.pl and the macports install of GMP was successfully detected, then we could add a config step to search for macports as we did for Fink. I'm transforming this into an RT so we can track it there. Thank you very much. kid51
Re: Assistance requested for Parrot testing
A developer who recently attended Perl Seminar NY asked me this question, to which I didn't have the answer. Hi James, Is Parrot embeddable into C programs, like Perl is ? Can anyone advise? Thanks. jimk
Re: Parrot at YAPC::NA::2008 in Chicago June 16-18
James E Keenan wrote: 3. YAPC is trying out a new format for some time slots this year. Josh McAdams writes on use.perl.org: This year we are also planning on introducing more hands-on workshop-style tracks to the conference. These sessions will typically be a little longer than a normal presentation and will be much more informal. During the workshops, conference attendees will be able to interact with presenters to actually do things like compile Parrot or create a hello world program in Perl 6. Since the RFP deadline is fast approaching, I took the liberty of filing a proposal for such a lab session/workshop. This proposal is mainly intended to be a placeholder for a better proposal which we would develop collectively on this list. The title and description I provided for this proposal is as follows: ### Parrot and Perl 6 Workshop Have you been avoiding trying out Parrot or Rakudo (the Perl 6 implementation on the Parrot virtual machine)? Come to this lab session and solve your avoidance problems. We'll walk you through a download of the Parrot source code, building and testing Parrot on your laptop or remote machine. Then we'll show you how to build Perl 6 on Parrot and get you to Hello, world. At that point, you'll be ready to start playing with Perl 6 yourself. The Parrot team is particularly interested in having you attend this workshop if you want to try out Parrot and Perl 6 on operating systems for which we do not regularly get smoke test reports. So we welcome participants working on Win32, OpenBSD, Solaris, etc., as well as Linux, Darwin and FreeBSD. ### Feedback welcome -- particularly if it comes from people who'd be willing to co-lead such a workshop with me! :-) kid51
Re: Scheduler, Timer and DOD
Ron Blaschke wrote: Hi, I've been looking into a failure of Ft/dynoplibs/myops.t on Windows, but I don't think the problem is limited to that platform. $ prove t\dynoplibs\myops.t t\dynoplibs\myops..5/10 t\dynoplibs\myops..6/10 # Failed test 'three alarm' # at t\dynoplibs\myops.t line 118. # Exited with error code: 255 A friend on Win32 reported a failure in this test on March 1, but the only output presented was: t/dynoplibs/myops.t(Wstat: 256 Tests: 10 Failed: 1) Failed test: 5 Non-zero exit status: 1 I was unable to reproduce the error on either Darwin or Linux. kid51
Re: [svn:parrot] r26248 - trunk/src/pmc
Andy Lester wrote: We should also have 100% code coverage, too. Ah, I'm so glad someone in addition to me said that! ;-) kid51
Parrot Blogs
From #parrotsketch yesterday, I learned of the existence of http:// www.parrotblog.org/. I also learned (or, perhaps, re-learned) of the existence of http://planet.parrotcode.org/. What are the purpose and intended audience of each? kid51
Re: pdd17pmc branch review
James E Keenan wrote: As I would have expected, the branch passed all the tests run via 'perl Configure.pl --test'. But having said that, it failed 'make' on the same box (a box where trunk consistently passes 'make'). src/scheduler.c seems to have a problem. See attached. kid51 Compiling with: xx.c cc -I./include -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -fvisibility=hidden -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wbad-function-cast -Wc++-compat -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdeclaration-after-statement -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wimport -Winit-self -Winline -Winvalid-pch -Wmain -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wvariadic-macros -Wwrite-strings -g -DHAS_JIT -DI386 -DHAVE_COMPUTED_GOTO -fPIC -I. -o xx.o -c xx.c /usr/local/bin/perl tools/build/ops2pm.pl src/ops/core.ops src/ops/bit.ops src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops src/ops/set.ops src/ops/stack.ops src/ops/stm.ops src/ops/string.ops src/ops/sys.ops src/ops/var.ops gcd_i_n_n 1226 experimental, not in ops.num gcd_i_nc_n1227 experimental, not in ops.num gcd_i_n_nc1228 experimental, not in ops.num gcd_i_nc_nc 1229 experimental, not in ops.num gcd_i_i_i_i_i 1230 experimental, not in ops.num gcd_i_i_i_ic_i1231 experimental, not in ops.num gcd_i_i_i_i_ic1232 experimental, not in ops.num gcd_i_i_i_ic_ic 1233 experimental, not in ops.num splice_p_p_i_i1234 experimental, not in ops.num splice_p_p_ic_i 1235 experimental, not in ops.num splice_p_p_i_ic 1236 experimental, not in ops.num splice_p_p_ic_ic 1237 experimental, not in ops.num slice_p_p_k 1238 experimental, not in ops.num slice_p_p_kc 1239 experimental, not in ops.num slice_p_p_k_ic1240 experimental, not in ops.num slice_p_p_kc_ic 1241 experimental, not in ops.num iter_p_p 1242 experimental, not in ops.num morph_p_i 1243 experimental, not in ops.num morph_p_ic1244 experimental, not in ops.num morph_p_s 1245 experimental, not in ops.num morph_p_sc1246 experimental, not in ops.num exec_s1247 experimental, not in ops.num exec_sc 1248 experimental, not in ops.num classname_p_p 1249 experimental, not in ops.num trap 1250 experimental, not in ops.num pow_n_n_i 1251 experimental, not in ops.num pow_n_nc_i1252 experimental, not in ops.num pow_n_n_ic1253 experimental, not in ops.num pow_n_nc_ic 1254 experimental, not in ops.num new_p_i_s 1255 experimental, not in ops.num new_p_ic_s1256 experimental, not in ops.num new_p_i_sc1257 experimental, not in ops.num new_p_ic_sc 1258 experimental, not in ops.num add_io_event_p_p_p_ic 1259 experimental, not in ops.num need_finalize_p 1260 experimental, not in ops.num setstdout_p 1261 experimental, not in ops.num setstderr_p 1262 experimental, not in ops.num runinterp_p_p 1263 experimental, not in ops.num runinterp_p_pc1264 experimental, not in ops.num substr_r_s_s_i_i 1265 experimental, not in ops.num substr_r_s_sc_i_i 1266 experimental, not in ops.num substr_r_s_s_ic_i 1267 experimental, not in ops.num substr_r_s_sc_ic_i1268 experimental, not in ops.num substr_r_s_s_i_ic 1269 experimental, not in ops.num substr_r_s_sc_i_ic1270 experimental, not in ops.num substr_r_s_s_ic_ic1271 experimental, not in ops.num substr_r_s_sc_ic_ic 1272 experimental, not in ops.num
Re: r25810 - make error
chromatic wrote: On Sunday 17 February 2008 17:13:37 James E Keenan wrote: Compiling with gcc and linking with g++ looks more suspicious to me. Is that really how things work on Darwin? That's what I've been doing -- with satisfactory results -- since I first joined the project.
Re: r25810 - make error
Joshua McAdams wrote: [snip] I've attached my ld and ldflags trace too. I used your ccc wrapper and directly linked to gcc and g++ instead of going through the cc and c++ links found on my system. Other than the inclusion of /opt/local/lib twice, the thing that stands out the me is that the config seems to be targeting 'init::defaults = env MACOSX_DEPLOYMENT_TARGET=10.3 cc' and I'm on 10.4.11 of the OS. Do you think that matters? It should not. Allison was having me experiment with some things a couple of weeks back, and, IIRC, we determined that for our purposes '10.3' was the correct value for MACOSX_DEPLOYMENT_TARGET for 10.3 and 10.4. I, too, am on 10.4.11. But see Andy Dougherty's post in this thread.
Re: r25810 - make error
Andy Dougherty wrote: The problem here looks relatively simple: The symbol _Parrot_conv_i2_i is defined in two places: myops_ops.o and /usr/local/lib/libparrot.dylib(core_ops.o) That '/usr/local/lib/libparrot.dylib' shouldn't be there. It's probably a remnant of an old installation. Uninstalling the old libparrot should fix this problem. Assuming someone needed to do this uninstall, what's the best way to do it? Thanks. kid51
Re: r25810 - make error
Joshua McAdams wrote: I think I did install a version of parrot from macports and then uninstalled it... must not have cleaned up enough. Regardless, deleting /usr/local/lib/libparrot.dylib solved the problem and I now have a compiling and [almost] test-passing version of parrot on my system. Thanks everyone. Hurray! BTW, here are the failures that I'm getting: Test Summary Report --- t/postconfigure/05-trace.t (Wstat: 512 Tests: 40 Failed: 2) Failed tests: 7, 9 Non-zero exit status: 2 I suspect a 'make realclean' should fix this. t/src/intlist.t(Wstat: 1024 Tests: 4 Failed: 4) Failed tests: 1-4 Non-zero exit status: 4 I applied a patch over the weekend which fixed a failure in this test. Are you working from HEAD? t/src/io.t (Wstat: 768 Tests: 20 Failed: 3) Failed tests: 16-17, 19 Non-zero exit status: 3 t/perl/Parrot_IO.t (Wstat: 256 Tests: 57 Failed: 1) Failed test: 52 Non-zero exit status: 1 t/examples/library.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 3 Non-zero exit status: 1 Hmm, haven't seen errors in these tests lately.
Re: r25810 - make error
Joshua McAdams wrote: t/examples/library.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 3 Non-zero exit status: 1 I'm getting this failure too. But I think it's a side effect from Coke's work on .pir files this weekend, as he's marked it as a 'fail'. Coke: Will you be able to fix this before release? kid51
Re: r25810 - make error
Joshua McAdams wrote: I just checked out parrot r25810 and ran 'perl Configure.pl' and 'make' and got the following error. This is on a PowerBook G4 running Darwin 8.11.0. Could someone point me to what I am doing wrong? Are you using the Apple-supplied C and C++ compilers? Presuming that 'cc' and 'c++' are symlinks, what do they link to? [snip] c++ -o dan_ops_switch.bundle dan_ops_switch.o -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace -L/opt/local/lib -L/Users/joshua/Development/parrot/blib/lib -bundle -undefined suppress -L/Users/joshua/Development/parrot/blib/lib -lparrot Copy myops_ops.bundle failed (0) make[1]: *** [all] Error 2 make: *** [dynoplibs.dummy] Error 2 No immediate diagnosis. I feel your pain: you got 93% of the way thru 'make'. jimk
Re: r25810 - make error
Joshua McAdams wrote: I just checked out parrot r25810 and ran 'perl Configure.pl' and 'make' and got the following error. This is on a PowerBook G4 running Darwin 8.11.0. Could someone point me to what I am doing wrong? [snip] /usr/bin/ld: multiple definitions of symbol _Parrot_conv_i2_i myops_ops.o definition of _Parrot_conv_i2_i in section (__TEXT,__text) /usr/local/lib/libparrot.dylib(core_ops.o) definition of _Parrot_conv_i2_i /usr/bin/ld: multiple definitions of symbol _Parrot_conv_u2_i myops_ops.o definition of _Parrot_conv_u2_i in section (__TEXT,__text) /usr/local/lib/libparrot.dylib(core_ops.o) definition of _Parrot_conv_u2_i collect2: ld returned 1 exit status This looks suspicious.
Re: r25810 - make error
Will Coleda wrote:
Josh: For some time, I've been config'ing parrot this way on OS X:
%cat ~/bin/ccc
CCACHE=ccache
CC=${CCACHE}gcc-4.0
CX=${CCACHE}g++-4.0
perl Configure.pl --cc=$CC --cxx=$CX --link=$CX --ld=$CX $@
Give this a whirl. (setting CCACHE to if you don't have it.) This
should avoid the ld issue James pointed out.
I do something similar (which is not surprising, because Coke taught me
how to do it!)
#!/bin/sh
#MACOSX_DEPLOYMENT_TARGET=10.3
echo MACOSX_DEPLOYMENT_TARGET is $MACOSX_DEPLOYMENT_TARGET
CC=/usr/bin/gcc-3.3
CX=/usr/bin/g++-3.3
/usr/local/bin/perl Configure.pl --cc=$CC --cxx=$CX --link=$CX \
--ld=$CX \
--without-icu \
--configure_trace \
$@
You can omit the --configure_trace (unless you want to help me out with
configuration tests ;-) ) and the --without-icu represents a local
adaptation. I formerly had to configure with --without-gmp as well, but
I've got that going now.
kid51
Re: r25810 - make error
Joshua McAdams wrote: g++-4.0 -o myops_ops.bundle myops_ops.o -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace -L/opt/local/lib -L/Users/joshua/Development/parrot/blib/lib -bundle -undefined suppress -L/Users/joshua/Development/parrot/blib/lib -lparrot By the way, is it suspicious that /opt/local/lib is included before /usr/local/lib and that /opt/local/lib is included twice? I'm wondering if darwinports is interfering with the compilation. It does cause a light bulb in my tired brain to begin glowing dimly. IIRC, sometime in the last month I added some code to one of the config step classes to preclude the possibility of a flag being added more than once to a string of flags. But I don't recall exactly where I did that; will have to research it. In any case, you can use Parrot::Configure::Trace to trace how a particular Parrot::Configure object attribute develops over the course of the 60+ configuration steps. My guess is that you'd want to look at 'ld' and 'ldflags', perhaps others. We've had enough experience with Fink to warrant extracting Fink-related code from 3 different config step classes and put it in a step of its own, and we have a little macports-specific code in config/auto/readline.pm -- but we have no darwinports-specific code in the configuration system. kid51
Re: r25810 - make error
Joshua McAdams wrote: g++-4.0 -o myops_ops.bundle myops_ops.o -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace -L/opt/local/lib -L/Users/joshua/Development/parrot/blib/lib -bundle -undefined suppress -L/Users/joshua/Development/parrot/blib/lib -lparrot By the way, is it suspicious that /opt/local/lib is included before /usr/local/lib and that /opt/local/lib is included twice? I'm wondering if darwinports is interfering with the compilation. The patch I was trying to remember a minute ago was in http://rt.perl.org/rt3/Ticket/Display.html?id=50390. Cf: lib/Parrot/Configure/Step/Methods.pm sub _handle_darwin_for_fink(). This is Fink-specific, but Coke did raise the question of whether it should be generalized. Whether that will help out with your immediate problem, I don't know; I would like to see the output of P::C::Trace first. kid51
Re: r25810 - make error
James E Keenan wrote:
In any case, you can use Parrot::Configure::Trace to trace how a
particular Parrot::Configure object attribute develops over the course
of the 60+ configuration steps. My guess is that you'd want to look at
'ld' and 'ldflags', perhaps others.
Try adapting the attached.
#!/usr/local/bin/perl
use strict;
use warnings;
use Data::Dumper;
use Carp;
use lib ('/Users/jimk/work/parrot/lib');
use Parrot::Configure::Trace;
$Data::Dumper::Indent = 1;
my $workdir = qq{/Users/jimk/work};
my $sandbox = shift @ARGV;
chdir qq{$workdir/$sandbox}
or croak Unable to change to $sandbox: $!;
my @tobetraced = @ARGV;
my $obj = Parrot::Configure::Trace-new();
foreach my $attr (@tobetraced) {
print Tracing evolution of $attr ...\n\n;
$attr = $obj-trace_data_c( {
attr= $attr,
verbose = 1,
} );
foreach my $step (@{$attr}) {
my ($k,$v) = each %$step;
$v = q{} if not defined $v;
print $k = $v\n;
}
}
Re: Quick config/auto/pack.pm Question
Ron Blaschke wrote: l is documented as: l A signed long (32-bit) value. I'm not expert in this, so let me ask: Where is this documented other than 'perldoc -f pack'? kid51 (... who refactored the code cited into subroutines but didn't come up with it in the first place.)
Re: [perl #50056] [BUG] Undefined symbols on OS X
Allison Randal via RT wrote: If you're running some flavor of OS X, please test this patch. Allison: I have 3 different patches from you in this thread in the last day. Which one or which combination do you most want tried out? (moi: ppc-darwin 10.4.11)
Re: New wiki page: RFP Parrot needs better smoke reports
I have added more content to this wiki page concerning what's wrong with our current smoke test reporting and some things I'd like to see in an improved version. Allison added some links to older RT tickets re smoke testing, which led me to merge one of those tickets into one I started in the last month. Please read and comment. Thank you very much. kid51
Re: [perl #45137] [TODO] Add a revision control test in Configure.pl
On Jan 18, 2008, at 10:49 PM, Jerry Gay via RT wrote: can you still do: svn update perl Configure.pl make svn update (new revision) make ?? No. 'make' invokes tools/build/revision_c.pl, which has this restriction in it: exit 1 unless ( $current == $config ); this is a common scenario for developers. in the case where updating the working copy does not change any files that would affect the configuration process, the developer should not be forced to reconfigure. if this behavior is allowed, this patch should fit the bill. if not, then i'll have a problem with it. i certainly don't want to be forced to run configure and rebuild parrot from scratch every time i update my working copy (for example, if a pod comment was modified in a high-level language.) Then we'll have to have a discussion of what we all want from revision-seeking code. In developing this patch, I was primarily responding to the issue raised in this ticket: Paul Cochrane's and Andy Dougherty's observation that we were repeatedly asking what version control system was being used (which internally translated into repeated runnings of $Parrot::Revision::__get_revision_number() to get $Parrot::Revision::current). I was also responding to the bizarre (IMHO) structure of lib/Parrot/Revision.pm, where we repeatedly run the VCS-discovery code, assign it to $current, assign *that* to $config, and then -- at the very last moment -- say Oh, by the way, if you've already configured, behave in a completely different manner. Assign a different value to $config. I had to write four separate test files to accommodate every twist and turn in this code. What happens under different scenarios if you comment out the 'exit 1' code above in revision_c.pl?
Re: Test Results
Alberto Simões wrote: Hi James E Keenan wrote: Which OS-cpu? Which Parrot version? Forgot to tell it. Mac OS Tiger on PPC G4 Perl 5.10 Parrot Revision: 24263 Alberto: Are you still getting these errors? If so, could you please add something to http://rt.perl.org/rt3/Ticket/Display.html?id=48965 so that we can track it via RT? Thank you very much.
Re: [svn:parrot] r24767 - in trunk: . config/auto t/configure
chromatic wrote:
On Friday 11 January 2008 16:44:58 [EMAIL PROTECTED] wrote:
Log:
auto::msvc: Refactored some code to increase testability:
_handle_not_msvc(). Add 113-auto_msvc-04.t to test this internal
subroutine. In 113-auto_msvc-01.t, SKIP only test for runstep() on
non-Win32 platforms. Small corrections in other test files.
I don't understand this. What's the value of testing any part of this code on
non-Windows platforms? It doesn't (and can't) tell us anything interesting
about our configuration system.
I can't speak for others but it tells me something interesting about
auto::msvc. It tells me that the code is sound and thorough Perl 5
notwithstanding the fact that I don't have a Windows box on which to
build and test Parrot.
The configuration step classes have a considerable amount of code which
is specific to a particular operating system, platform (chip), C
compiler or any combination thereof. Some of the time this is broken
out into focused subclasses (init::hints::{OS};
auto::cpu::{platform}::auto; etc.). Most of the time it is found inside
a particular config step class's runstep() routine. As we have
previously discussed, this makes thorough testing difficult, because a
given human tester has only a limited number of OSes, platforms and C
compilers available.
We can overcome this difficulty to a considerable extent by refactoring
that mocks the conditions found on various OS/platform/compiler
combinations. Even if we're not on a Windows box, we can write tests
that ask, Suppose that we were on Windows and were provided with
information as to whether we had a VC++ compiler or not. Is the code
which uses that information sound? Have we considered what happens at
all diversion points in the control flow after we have received that
information? If we were on Windows, would our tests exercise every nook
and cranny of the code?
And that's what these tests do. The fact that they achieve high test
coverage of auto::msvc
(http://thenceforward.net/parrot/coverage/configure-build/config-auto-msvc-pm.html)
when run on a non-Windows system gives me considerable confidence that
auto::msvc will do the right thing when run on Windows. It also gives
anyone in the future doing refactoring on auto::msvc a framework with
which to test the soundness of that refactoring.
kid51
Re: [PATCH] tru64: hints tweaks
Jarkko Hietaniemi wrote: --- config/init/hints/dec_osf.pm.dist 2008-01-09 04:57:50.0 +0200 +++ config/init/hints/dec_osf.pm2008-01-09 05:23:23.0 +0200 @@ -14,8 +14,10 @@ Jarkko: Our RT system doesn't pick up new submissions that go (only) to [EMAIL PROTECTED] Could you please submit this patch as an attachment to an email to [EMAIL PROTECTED] That way, it will get an RT number assigned. The original submission will be cc-ed to the list. Thank you very much. Jim Keenan
Re: [PATCH] probe for gcc -Wxxx only when gcc (well, g++)
Jarkko Hietaniemi wrote: --- config/auto/warnings.pm.dist2008-01-08 05:51:42.0 +0200 +++ config/auto/warnings.pm 2008-01-08 06:01:23.0 +0200 @@ -132,17 +132,22 @@ Thanks, Jarkko. Since I'm working on correcting other problems with auto::warnings and its tests in another RT ticket (http://rt.perl.org/rt3/Ticket/Display.html?id=47395), I'm going to add your patch to that ticket. I hope to be getting to it soon.
Re: [perl #49274] [CAGE] script to generate ports/debian/parrot-doc.docs
Allison Randal wrote: Alan Rocker wrote: I've attached a quickie shell script, in case that's what you want. It's a naive little thing, but I think you'll be amused by its presumption. Good start. Committed in r24479, with a small change to run it from the top-level directory instead of tools/dev. A little extra polish would be to make it skip docs/Makefile, and skip any files that start with . (like .filename.pod.swp) For portability reasons, however, shouldn't it be converted to Perl 5? I don't think we proceed on the assumption that all our target OSes can handle shell.
Re: [svn:parrot] r24497 - in trunk: languages/lolcode/src/parser tools/dev
chromatic wrote: On Thursday 03 January 2008 12:05:48 [EMAIL PROTECTED] wrote: Log: Add copyright statement to file which lacked it; t/codingstd/copyright.t should once again pass. Modified: trunk/languages/lolcode/src/parser/actions.pm === === --- trunk/languages/lolcode/src/parser/actions.pm (original) +++ trunk/languages/lolcode/src/parser/actions.pm Thu Jan 3 12:05:48 2008 @@ -1,3 +1,4 @@ +# Copyright (C) 2001-2007, The Perl Foundation. # $Id$ -# Copyright (c) 2007, The Perl Foundation +# Copyright (C) 2001-2008, The Perl Foundation. # $Id$ I'm not sure this is legal. Certainly TPF holds a copyright on Parrot from 2001 - 2008, but these files are new in 2008, so I'm not sure TPF can assert copyright on them for previous years. Hey, I was just trying to fix a test that was failing across the board on our smoke tests. If the dating is incorrect, please go ahead and change. IANAA. kid51
New wiki page: RFP Parrot needs better smoke reports
Following up on today's Parrotsketch discussion, I have begun a wiki page whose purpose is to develop a specification for an improved smoke testing setup for Parrot. http://www.perlfoundation.org/parrot/index.cgi?rfp_parrot_needs_better_smoke_reports I invite you to: -- correct any factual errors in what I've written so far -- fill in sections which are marked 'TK'. Let's see if this enables us to develop a plan more quickly or effectively than back-and-forth on the mailing list. Once we have a completed first draft of a specification, we'll open up an RT. (At least, that's my suggestion.) Thank you very much. kid51
Re: Current status on Solaris 8/SPARC
Andy Dougherty wrote: After fixing various minor little things, here's where I stand on Solaris 8/SPARC after the recent changes. I have not identified any particular common theme. Do these ring any bells? Failed TestStat Wstat Total Fail List of Failed --- t/configure/115-auto_warnings-02.t7 179222 14 16-22 t/configure/115-auto_warnings-03.t7 179222 14 16-22 t/configure/115-auto_warnings-04.t7 179222 14 16-22 t/configure/115-auto_warnings-05.t8 204823 16 16-23 t/configure/115-auto_warnings-06.t8 204823 16 16-23 t/configure/115-auto_warnings-07.t9 230424 18 16-24 t/configure/146-auto_snprintf-01.t 13 332830 26 18-30 Could you open an RT ticket for these -- or perhaps one for auto::warnings and one for aut::snprintf? I will then re-work the tests, as I have a general idea of the problem. What also would be helpful: (1) Output of prove -v on these. (2) How did you configure? I.e., which (of your many!) perls did you use? which command-line options? any interactive configuration? Thank you very much.
Re: expected test failures in t/pmc, t/run, and t/stm
Here's where we stand after r24412 on Linux. t/dynoplibs/myops..1..10 ok 1 - fortytwo ok 2 - what_do_you_get_if_you_multiply_six_by_nine ok 3 - hcf ok 4 - a short cheating quine ok 5 - one alarm ok 6 - three alarm ok 7 - repeating alarm ok 8 - bxand - A AND B, but not BOTH ok 9 - conv_u2_i ok 10 - conv_i2_i ok t/examples/shootout1..20 examples/shootout/ack.pir -Oc -Cj ok 1 - examples/shootout/ack.pir examples/shootout/binarytrees.pir -C ok 2 - examples/shootout/binarytrees.pir examples/shootout/fannkuch.pir -j ok 3 - examples/shootout/fannkuch.pir examples/shootout/fasta.pir -C # Failed test (t/examples/shootout.t at line 108) # Exited with error code: [SIGNAL 11] # Received: # # Expected: # ONE Homo sapiens alu # GGCCGGGCGCGGTGGCTCACGCCTGTAATCCCAGCACTTTGGGAGGCCGAGGCGGGCGGA # TCACCTGAGGTCAGGAGTTCGAGACCAGCCTGGCCAACATGGTGAAAGTCTCTACT # ATACATTAGCCGGGCGTGGTGGCGCGCGCCTGTAATCCCAGCTACTCGGGAG # GCTGAGGCAGGAGAATCGCTTGAACCCGGGAGGCGGAGGTTGCAGTGAGCCGAGATCGCG # CCACTGCACTCCAGCCTGGGCGACAGAGCGAGACTCCGTCTCAGGCCGGGCGCGGT # GGCTCACGCCTGTAATCCCAGCACTTTGGGAGGCCGAGGCGGGCGGATCACCTGAGGTCA # GGAGTTCGAGACCAGCCTGGCCAACATGGTGAAAGTCTCTACTATACA # TTAGCCGGGCGTGGTGGCGCGCGCCTGTAATCCCAGCTACTCGGGAGGCTGAGGCAGGAG # AATCGCTTGAACCCGGGAGGCGGAGGTTGCAGTGAGCCGAGATCGCGCCACTGCACTCCA # GCCTGGGCGACAGAGCGAGACTCCGTCTCAGGCCGGGCGCGGTGGCTCACGCCTGT # AATCCCAGCACTTTGGGAGGCCGAGGCGGGCGGATCACCTGAGGTCAGGAGTTCGAGACC # AGCCTGGCCAACATGGTGAAAGTCTCTACTATACATTAGCCGGGCGTG # GTGGCGCGCGCCTGTAATCCCAGCTACTCGGGAGGCTGAGGCAGGAGAATCGCTTGAACC # CGGGAGGCGGAGGTTGCAGTGAGCCGAGATCGCGCCACTGCACTCCAGCCTGGGCGACAG # AGCGAGACTCCGTCTCAGGCCGGGCGCGGTGGCTCACGCCTGTAATCCCAGCACTT # TGGGAGGCCGAGGCGGGCGGATCACCTGAGGTCAGGAGTTCGAGACCAGCCTGGCCAACA # TGGTGAAAGTCTCTACTATACATTAGCCGGGCGTGGTGGCGCGCGCCT # GTAATCCCAGCTACTCGGGAGGCTGAGGCAGGAGAATCGCTTGAACCCGGGAGGCGGAGG # TTGCAGTGAGCCGAGATCGCGCCACTGCACTCCAGCCTGGGCGACAGAGCGAGACTCCGT # CTCAGGCCGGGCGCGGTGGCTCACGCCTGTAATCCCAGCACTTTGGGAGGCCGAGG # CGGGCGGATCACCTGAGGTCAGGAGTTCGAGACCAGCCTGGCCAACATGGTGAAAG # TCTCTACTATACATTAGCCGGGCGTGGTGGCGCGCGCCTGTAATCCCAGCTA # CTCGGGAGGCTGAGGCAGGAGAATCGCTTGAACCCGGGAGGCGGAGGTTGCAGTGAGCCG # AGATCGCGCCACTGCACTCCAGCCTGGGCGACAGAGCGAGACTCCGTCTCAGGCCG # GGCGCGGTGGCTCACGCCTGTAATCCCAGCACTTTGGGAGGCCGAGGCGGGCGGATCACC # TGAGGTCAGGAGTTCGAGACCAGCCTGGCCAACATGGTGAAAGTCTCTACTA # TACATTAGCCGGGCGTGGTGGCGCGCGCCTGTAATCCCAGCTACTCGGGAGGCTGA # GGCAGGAGAATCGCTTGAACCCGGGAGGCGGAGGTTGCAGTGAGCCGAGATCGCGCCACT # GCACTCCAGCCTGGGCGACAGAGCGAGACTCCGTCTCAGGCCGGGCGCGGTGGCTC # ACGCCTGTAATCCCAGCACTTTGGGAGGCCGAGGCGGGCGGATCACCTGAGGTCAGGAGT # TCGAGACCAGCCTGGCCAACATGGTGAAAGTCTCTACTATACATTAGC # CGGGCGTGGTGGCGCGCGCCTGTAATCCCAGCTACTCGGGAGGCTGAGGCAGGAGAATCG # CTTGAACCCGGGAGGCGGAGGTTGCAGTGAGCCGAGATCGCGCCACTGCACTCCAGCCTG # GGCGACAGAGCGAGACTCCG # TWO IUB ambiguity codes # cttBtatcatatgctaKggNcataaaSatgtaaaDcDRtBggDtctttataattcBgtcg # tactDtDagcctatttSVHtHttKtgtHMaSattgWaHKHagacatWatgtRgaaa # NtactMcSMtYtcMgRtacttctWBacgaaatatagScDtttgaagacacatagtVgYgt # cattHWtMMWcStgttaggKtSgaYaaccWStcgBttgcgaMttBYatcWtgacaYcaga # gtaBDtRaccWatMttDBcatWtatcttactaBgaYtcttgYaaScYa # HgtgttNtSatcMtcVaaaStccRcctDaataataStcYtRDSaMtDttgttSagtRRca # tttHatSttMtWgtcgtatSSagactYaaattcaMtWatttaSgYttaRgKaRtccactt # tattRggaMcDaWaWaggacatgttctacaaaRaatataataaMttcgDacgaSSt # acaStYRctVaNMtMgtaggcKatcattagVWaHKYagtatttaacct # tacgtVtcVaattVMBcttaMtttaStgacttagattWWacVtgWYagWVRctDattBYt # gtttaagaagattattgacVatMaacattVctgtBSgaVtgWWggaKHaatKWcBScSWa # accRVacacaaactaccScattRatatKVtactatatttHttaagtttSKtRtacaaagt # RDttcWgcacatWaDgtDKacgaacaattacaRNWaatHtttStgttattaaMtgt # tgDcgtMgcatBtgcttcgcgaDWgagctgcgaVtaaScNatttacttaatgacag # cacatYScaMgtaggtYaNgttctgaMaacNaMRaacaaacaKctacatagYWctg # ttWaaattaRattagHacacaagcgKatacBttRttaagtatttccgatctHSaat # actcNttMaagtattMtgRtgaMgcataatHcMtaBSaRattagttgatHtMttaaKagg # YtaaBataSaVatactWtataVWgKgttcagtgcgRatatacatVtHRtVYataSa # KtWaStVcNKHKttactatccctcatgWHatWaRcttactaggatctataDtDHBttata # aaaHgtacVtagaYttYaKcctattcttcttaataNDaaggaaaDYgcggctaaWSctBa # aNtgctggMBaKctaMVKagBaactaWaDaMaccYVtNtaHtVWtKgRtcaaNtYaNacg # gtttNattgVtttctgtBaWgtaattcaagtcaVWtactNggattctttaYtaaagccgc # tcttagHVggaYtgtNcDaVagctctctKgacgtatagYcctRYHDtgBattDaaDgccK # tcHaaStttMcctagtattgcRgWBaVatHtaYtgtttagMDMRtaataaggatMt # ttctWgtNtgtgMaatatRtttMtDgHHtgtcacWattRSHcVagaagtacg # ggtaKVattKYagactNaatgtttgKMMgYNtcccgSKttctaStatatNVataYHgtNa # BKRgNacaactgatttcctttaNcgatttctctataScaHtataRagtcRVttacDSDtt # aRtSatacHgtSKacYagttMHtWataggatgactNtatSaNctataVtttRNKtgRacc # tttYtatgttactcctttaaacatacaHactMacacggtWataMtBVacRaSaatc # cgtaBVttccagccBcttaRKtgtgcctRtgtcagcRttKtaaacKtaaatctcac # aattgcaNtSBaaccgggttattaaBcKatDagttactcttcattVtttHaaggctKKga # tacatcBggScagtVcacagaHaDSgHatRMaHWggtatatRgccDttcgtatcga # aacaHtaagttaRatgaVacttagattVKtaaYttaaatcaNatccRttRRaMScNaaaD #
Re: make pbc_to_c fails
Ovid wrote: I'm having trouble with the initial Configure.pl and with the pbc_to_c target on my Intel Macbook. I have rough notes below about the steps I've taken. If anyone needs more information, just ask and I'd be happy to send anything I can. Following the instructions in chromatic's post at use.perl about building a Perl 6 binary: http://use.perl.org/article.pl?sid=07/12/30/0912211 I got this error on the latest version from svn: parrot $ perl Configure.pl Base class package Parrot::Configure::Compiler is empty. (Perhaps you need to 'use' the module which defines that package first.) at lib/Parrot/Configure.pm line 44 Ovid et al.: I apologize for the confusion. Barney diagnosed the problem and corrected it in r24298 and r24303. I had failed to copy lib/Parrot/Configure/Compiler.pm from branch to trunk. Lacking that, nothing else made sense. If you do an 'svn update', you should get a correct distribution. I have successfully configured on i386-linux and am now doing so on ppc-darwin. Although it is not required for running chromatic's process, you might wish to begin with: perl Configure.pl --test ... to see that the configuration and build tools all work properly before you say 'make'. chromatic recommended that I check out r24278, which I did with a clean install (blew everything away and started over), and I tried again. Here's a summary: Checked out revision 24278. code $ cd parrot/ parrot $ perl Configure.pl Parrot Version 0.5.1 Configure 2.0 Copyright (C) 2001-2007, The Perl Foundation. ... snip ... Checking MANIFEST...No such file: t/configure/104-init_miniparrot.t No such file: t/configure/106-init_headers.t No such file: t/configure/122-auto_ops.t No such file: t/configure/128-auto_va_ptr.t The tests were renumbered subsequent to 24278. [snip] Since configuration did not complete successfully, there was no way that any 'make' target could be run. parrot $ make pbc_to_c perl tools/dev/pbc_to_c_gen.pl \ './CFLAGS cc -I./include -g -pipe -fno-common -no-cpp-precomp -I/usr/local/include -pipe -fno-common -Wno-long-double I haven't tried this new thing; will have to do so myself. kid51
Re: make pbc_to_c fails
On Dec 30, 2007, at 10:04 AM, Ovid wrote: --- James E Keenan [EMAIL PROTECTED] wrote: Hi James, Although it is not required for running chromatic's process, you might wish to begin with: perl Configure.pl --test ... to see that the configuration and build tools all work properly before you say 'make'. Thanks for that tip. I assume from other comments that you've made that if there are Configure test failures, that trying to continue is useless. svn co https://svn.perl.org/parrot/trunk parrot \ cd parrot \ perl Configure.pl --test 4/1089 tests failed. Test below. As usual, if there is anything else I can do, please let me know. Cheers, Ovid Try a 'make realclean' and then re-run the above commands.
Why different results with 'make smoke' from 'make test'
From 'make test': t/dynpmc/foo.ok 1/9 skipped: various reasons t/dynpmc/gdbmhashok t/dynpmc/rationalok 1/8 skipped: various reasons ... and these have been the results for these tests for months. Same box (ppc-darwin, Mac 0S X 10.4.11), 'make smoke' (possibly a few revisions later): - t/dynpmc/foo.t # Failed test (t/dynpmc/foo.t at line 57) # Exited with error code: 1 # Received: # Class 'Foo' not found # current instr.: 'main' pc 16 (/Users/jimk/smoke/brooklyn.kid51.at.gmail.com/t/dynpmc/foo_3.pir:15) # # Expected: # 42 # # Looks like you failed 1 test of 9. - t/dynpmc/gdbmhash.t - t/dynpmc/rational.t # Failed test (t/dynpmc/rational.t at line 57) # Exited with error code: 1 # Received: # Class 'Rational' not found # current instr.: 'main' pc 16 (/Users/jimk/smoke/brooklyn.kid51.at.gmail.com/t/dynpmc/rational_3.pir:15) # # Expected: # 43 # # Looks like you failed 1 test of 8.
Re: Another deadlock on Mac OS 10.5.1
Andy Armstrong wrote: Sorry if I've missed something recent that means that this is expected behaviour but r24318 is hanging during make test on Mac OS 10.5.1 / Intel. The test log and pictures of the process probe are here: http://hexten.net/junk/20071230-193600/ I also have a few test failures on Ubuntu PPC: Test Summary Report --- t/configure/115-auto_warnings-01.t (Wstat: 0 Tests: 4 Failed: 0) TODO passed: 4 t/src/intlist.t(Wstat: 0 Tests: 4 Failed: 0) TODO passed: 1-4 t/src/io.t (Wstat: 0 Tests: 20 Failed: 0) TODO passed: 16-17, 19 These are the same TODO-ed out tests that are failing most everywhere. In the case of the failure in 115-auto_warnings-01.t, I think the problem is mostly a defect in the construction of the test. When ptc gets back, I hope to speak with him about it. It's not a major concern. I don't know what's wrong with intlist.t and io.t, but you're not alone there and those tests must be TODO-ed out for a reason. t/examples/shootout.t (Wstat: 2560 Tests: 20 Ah! The shootout! Our old nemesis. Join the crowd; google the list archives. It almost never passes on Darwin and there's an old-ish ticket about it failing on Gentoo Linux. But it seems to pass on Debian. I don't know what to say about the stall on Mac. I haven't upgraded to either 10.5 or Intel, so I don't know what dangers lurk there.
Re: Test Results
Alberto Simões wrote: Hi Probably this is all known, but as I am quite out from Parrot lately, and just wanted to try a make test under Perl 6, today I compiled Parrot, and run a make test. Which OS-cpu? Which Parrot version? This was the result: Test Summary Report --- t/configure/115-auto_warnings-01.t (Wstat: 0 Tests: 4 Failed: 0) TODO passed: 4 t/configure/124-auto_alignptrs-05.t(Wstat: 0 Tests: 21 Failed: 0) TODO passed: 20 Known issues; working on them. t/library/mime_base64.t(Wstat: 6 Tests: 0 Failed: 0) Parse errors: No plan found in TAP output Can you send output of prove -v? t/compilers/json/to_parrot.t (Wstat: 15104 Tests: 60 Failed: 59) Failed test number(s): 1-58, 60 Non-zero exit status: 59 This test had some failures last week (see http://rt.perl.org/rt3/Ticket/Display.html?id=48965), but were reported fixed via r24163. Can you send output of prove -v? t/examples/shootout.t (Wstat: 2304 Tests: 20 Failed: 9) Failed test number(s): 6-11, 17-19 Non-zero exit status: 9 Has failed a lot. Nowadays, passes for me on Linux, but always fails on Darwin. See also http://rt.perl.org/rt3/Ticket/Display.html?id=43481.
Re: Test Results
Alberto Simões wrote: Hi James E Keenan wrote: Which OS-cpu? Which Parrot version? Forgot to tell it. Mac OS Tiger on PPC G4 Perl 5.10 Parrot Revision: 24263 t/library/mime_base64.t(Wstat: 6 Tests: 0 Failed: 0) Parse errors: No plan found in TAP output Can you send output of prove -v? [EMAIL PROTECTED] parrot]$ prove -v t/library/mime_base64.t t/library/mime_base64..src/pmc_freeze.c:1202: failed assertion 'must_have_seen' No subtests run Test Summary Report --- t/library/mime_base64.t (Wstat: 6 Tests: 0 Failed: 0) Parse errors: No plan found in TAP output Files=1, Tests=0, 1 wallclock secs ( 0.02 usr 0.02 sys + 0.17 cusr 0.09 csys = 0.30 CPU) Result: FAIL This is a new one to me, and the test file itself has not recently been changed. Could you file a [BUG] ticket at [EMAIL PROTECTED] t/compilers/json/to_parrot.t (Wstat: 15104 Tests: 60 Failed: 59) Failed test number(s): 1-58, 60 Non-zero exit status: 59 This test had some failures last week (see http://rt.perl.org/rt3/Ticket/Display.html?id=48965), but were reported fixed via r24163. Can you send output of prove -v? See attach :) I reopened this ticket with your attachment: http://rt.perl.org/rt3/Ticket/Display.html?id=48965 kid51
Re: [perl #43307] [TODO] config/auto/aio.pm: Write unit tests
James Keenan via RT wrote: I haven't completely sorted through the above issues, but here's a somewhat refactored module and two test files. Because of issues discussed in RT 48070, I'm suggesting the use of IO::CaptureOutput rather than Parrot::IO::Capture::Mini for capturing verbose output. I've enclosed the relevant tests in a SKIP block for those (many) of you who do not have this module installed. Please let me know of any problems. I will apply the patch in 2-3 days if no one objects. Thank you very much. kid51 This code was committed, but I did some additional refactoring on this step class and added two additional test files.
Re: Test failures on Solaris 9
Paul Cochrane wrote: Hi everyone, these failures probably aren't critical for release, however I thought it best to mention them. Paul System: Solaris 9 cc: Sun C 5.8 2005/10/13 Parrot revision: 24033 t/library/pcre... # Failed test (t/library/pcre.t at line 35) Paul: See http://rt.perl.org/rt3/Ticket/Display.html?id=48074 ... which, perhaps for different reasons, proposes a patch to this test. kid51
Re: [perl #48493] [CAGE] Parrot::Configure::Step: Explicitly pass all arguments to all methods
James Keenan via RT wrote: For no reason more profound than ease of editing, when I went to require that each of 6 Parrot::Configure::Step methods be passed $conf explicitly, I put that argument first. Which of course makes it look much like a Parrot::Configure method call. And since the Parrot::Configure object constructed within Parrot::Configure::Step is *the* singleton P::C object, that's not surprising. So is there any compelling reason why these 6 methods should *not* be moved into Parrot::Configure.pm? That would leave P::C::Step as a location for utility subroutines which do not depend on the P::C object. Thoughts? kid51 am working on a patch to implement this
Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2config st
On Tue Dec 11 10:41:18 2007, doughera wrote: [snip] I think you're missing three things: cc_build() consults the global $conf, and hence doesn't need it passed in. I would certainly agree that the flow of information isn't well controlled here. Passing the object in sometimes and other times consulting the global object does seem like a recipe for confusion. It might make sense to always do one or the other. You're (unnumbered) fourth point is, IMHO, the decisive one. You have called my attention to two big puddles of parrot excrement sitting on the bottom of the cage. Neither cc_build() nor cc_run() fully encapsulates its arguments. This is what led me astray. Patch is withdrawn. Expect to see a [CAGE] ticket filed soon to make all these C-related Parrot::Configure::Step methods require all their arguments to be explicitly passed. You'll probably also see a new branch created to test out these revisions. Since this cage-cleaning can be accomplished by any competent Perl 5 hackers, I should ask: Are there any new Parrot folks out there who would like to take this job on? kid51
Re: [perl #48138] [BUG] t/native_pbc/integer.t, t/native_pbc/number.t fail on Darwin
On Dec 5, 2007, at 12:49 PM, chromatic via RT wrote:
On Wednesday 05 December 2007 09:27:58 James Keenan via RT wrote:
... and on Windows:
http://tinyurl.com/2mvrhz
So they're pretty much borken all around.
What happens when you do:
$ parrot -o i.pbc -a - EOF
print 0x10203040
end
EOF
$ mv i.pbc t/native_pbc/integer_${N}.pbc
... and run the integer test again?
-- c
On Linux/x86:
[parrot] 515 $ ./parrot -o i.pbc -a - EOF
print 0x10203040
end
EOF
[parrot] 516 $ mv i.pbc t/native_pbc/integer_${N}.pbc
[parrot] 517 $ prove -v t/native_pbc/integer.t
t/native_pbc/number.t
t/native_pbc/integer1..1
# Failed test (t/native_pbc/integer.t at line 56)
# Exited with error code: [SIGNAL 11]
# Received:
#
# Expected:
# 270544960
not ok 1 - i386 32 bit opcode_t, 32 bit intval
# Looks like you failed 1 test of 1.
dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
t/native_pbc/number.1..1
not ok 1 - i386 double float 32 bit opcode_t
# Failed test (t/native_pbc/number.t at line 86)
# got:
'012345678910111213141516171819202122232425'
# expected: '1.00
# 4.00
# 16.00
# 64.00
# 256.00
# 1024.00
# 4096.00
# 16384.00
# 65536.00
# 262144.00
# 1048576.00
# 4194304.00
# 16777216.00
# 67108864.00
# 268435456.00
# 1073741824.00
# 4294967296.00
# 17179869184.00
# 68719476736.00
# 274877906944.00
# 1099511627776.00
# 4398046511104.00
# 17592186044416.00
# 70368744177664.00
# 281474976710656.00
# 1125899906842620.00
# '
# Looks like you failed 1 test of 1.
dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed TestStat Wstat Total Fail Failed
List of Failed
---
t/native_pbc/integer.t1 256 11 100.00%
1
t/native_pbc/number.t 1 256 11 100.00%
1
Failed 2/2 test scripts, 0.00% okay. 2/2 subtests
failed, 0.00% okay.
On Darwin/PPC (r23512):
[parrot] 505 $ ./parrot -o i.pbc -a - EOF
print 0x10203040
end
EOF
[parrot] 506 $ mv i.pbc t/native_pbc/integer_${N}.pbc
[parrot] 507 $ prove -v t/native_pbc/integer.t t/native_pbc/number
number.t number_2.pbc number_4.pbc
number_1.pbc number_3.pbc number_5.pbc
[parrot] 507 $ prove -v t/native_pbc/integer.t t/native_pbc/number.t
t/native_pbc/integer1..1
not ok 1 - i386 32 bit opcode_t, 32 bit intval
# Failed test (t/native_pbc/integer.t at line 56)
# Exited with error code: [SIGNAL 11]
# Received:
#
# Expected:
# 270544960
# Looks like you failed 1 test of 1.
dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
t/native_pbc/number.1..1
not ok 1 - i386 double float 32 bit opcode_t
# Failed test (t/native_pbc/number.t at line 86)
# got: '012345678910111213141516171819202122232425'
# expected: '1.00
# 4.00
# 16.00
# 64.00
# 256.00
# 1024.00
# 4096.00
# 16384.00
# 65536.00
# 262144.00
# 1048576.00
# 4194304.00
# 16777216.00
# 67108864.00
# 268435456.00
# 1073741824.00
# 4294967296.00
# 17179869184.00
# 68719476736.00
# 274877906944.00
# 1099511627776.00
# 4398046511104.00
# 17592186044416.00
# 70368744177664.00
# 281474976710656.00
# 1125899906842620.00
# '
# Looks like you failed 1 test of 1.
dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed TestStat Wstat Total Fail List of Failed
---
t/native_pbc/integer.t1 256 11 1
t/native_pbc/number.t 1 256 11 1
Failed 2/2 test scripts. 2/2 subtests failed.
Files=2, Tests=2, 10 wallclock secs ( 0.31 cusr + 0.19 csys = 0.50
CPU)
Failed 2/2 test programs. 2/2 subtests failed.
Summary: no change in results; both tests still failing
Re: [perl #48138] [BUG] t/native_pbc/integer.t, t/native_pbc/number.t fail on Darwin
On Dec 5, 2007, at 9:12 PM, chromatic via RT wrote:
On Wednesday 05 December 2007 17:46:19 James E Keenan wrote:
[parrot] 506 $ mv i.pbc t/native_pbc/integer_${N}.pbc
In that step, replace ${N} with the test number, that is,
integer_1.pbc,
integer_2.pbc, etc. Otherwise the test will use the same .pbc
files it was
failing on before, and the failures won't be any more interesting.
On both Darwin and Linux, the integer.t now passes; number.t
continues to fail. Here's the Linux output:
[li11-226:parrot] 517 $ prove -v t/native_pbc/integer.t \
t/native_pbc/number.t
t/native_pbc/integer1..1
ok 1 - i386 32 bit opcode_t, 32 bit intval
ok
t/native_pbc/number.1..1
not ok 1 - i386 double float 32 bit opcode_t
# Failed test (t/native_pbc/number.t at line 86)
# Exited with error code: [SIGNAL 11]
# Received:
#
# Expected:
# 1.00
# 4.00
# 16.00
# 64.00
# 256.00
# 1024.00
# 4096.00
# 16384.00
# 65536.00
# 262144.00
# 1048576.00
# 4194304.00
# 16777216.00
# 67108864.00
# 268435456.00
# 1073741824.00
# 4294967296.00
# 17179869184.00
# 68719476736.00
# 274877906944.00
# 1099511627776.00
# 4398046511104.00
# 17592186044416.00
# 70368744177664.00
# 281474976710656.00
# 1125899906842620.00
#
# Looks like you failed 1 test of 1.
dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed Test Stat Wstat Total Fail List of Failed
---
t/native_pbc/number.t1 256 11 1
Failed 1/2 test scripts. 1/2 subtests failed.
Files=2, Tests=2, 2 wallclock secs ( 0.08 cusr + 0.01 csys = 0.09
CPU)
Failed 1/2 test programs. 1/2 subtests failed.
Re: [perl #41597] [PATCH] replacing explicit access to $^O in Configure
Bernhard Schmalhofer wrote: James, could you look into this patch and apply it if appropriate? Obviously you are the person that knows best, whether it can be applied right away or needs some fiddling or merging. Yes. In line with my second post in RT 47902, I'm thinking that in step #2, init::defaults, we should define a space within the Parrot::Configure object in which we store our readings from the %Config, $^O and other readings we take from the instance of Perl being used to run Configure.pl ($^X, in other words). We'll take these readings in that step and then assign them to real elements in the Parrot::Configure object as needed. Later configuration steps which need the original values will consult this special section. I will work on this tonight and over the next few days.
Re: [perl #47792] [BUG]: languages/dotnet/Configure.pl causes configuration error
On Nov 25, 2007, at 12:52 PM, Paul Cochrane via RT wrote: This error has been happening in dotnet for a long time. I can't give you a better timeframe than that, but it's been in that state (giving these warnings) since before I managed to get it's Configure.pl to go again, (which was a few months ago now). Paul: I really have to wonder about that. In my work, I am *constantly* running: svn update;perl Configure.pl ... and I only started to get this error today. As I was offline for a couple of days, the error has to have crept in since Thursday.
Re: [perl #47391] t/configure/1*.t tests incorrectly rely on init::defaults
On Nov 17, 2007, at 11:25 AM, Andy Dougherty via RT wrote: I used something like perl5.8 Configure.pl --cc=gcc --link=gcc --ld=gcc --ask (the --ask is because I also changed the ccflags, ldflags, and libs to match gcc, and the --ask version prompts with a default that is almost, but not quite, what I want.) How wedded are you to the continued existence of the --ask option, i.e., to the interactive mode in Parrot configuration? While at the gym today, I realized that almost no matter what I did, I would probably never be able to write tests of the configuration steps which are robust enough to meet the situations you and chromatic have described if users can change the direction of configuration seven or more steps into the configuration process. If, however, users were required to specify their variants as options to Configure.pl, then I could adapt existing code such that: perl5.8 Configure.pl --test --cc=gcc --link=gcc --ld=gcc ... ... makes all those options immediately available to the tests in t/ configure/ as well as to Configure.pl. The configuration tools tests would then have available from the outset (a) all information available from the Perl 5 Config, and (b) all information the user wants/needs to specifically supply. This would have the following consequences: 1) The test suite could be revised so that it more accurately reflects the situation on the user's system. 2) The configuration system could be considerably simplified, as the values determined in the current 'inter::' steps could either be set in 'init::' steps or 'auto::' steps. 3) The test suite would be simplified, as many test files now exist solely to test the '--ask' option in 'inter::' steps. 4) Since we could more accurately test our configuration tools *before* actual configuration -- which, I have argued, is the right time to do it, we could remove the 't/configure/*.t' tests from the suite of tests run by 'make test'. Those Parrot developers working on the configuration and build systems would have to run the pre- and post-configuration tests, but other Parrot developers and language porters would not. 5) We would be in a better position to move to particle's proposed file-based configuration in the future. Command-line options, interactive prompts and file-based configuration are all a way of getting information from the user and stuffing it into the Parrot::Configure object. Both command-line options and file-based configuration supply Parrot::Configure::runsteps() with all the information it needs before it starts running. The tests for individual config steps which we have currently written would not require adaptation to work with file-based configuration. Supplying that information via interactive prompts, however, means supplying information once Parrot::Configure::runsteps() has already started running. The various situations there are too numerous to mock. Going forward, I'm willing to maintain two ways of getting information into the Parrot::Configure object -- but not three. For the work I do on Parrot, I am constantly re-running Configure.pl. On Linux I can get away with no command-line options at all. On Darwin, I have to use some like --without-gdbm because of the limitations of my iBook and some to get around a mistaken attempt to build my own 'gcc'. (The latter options were taught to me by chromatic and Coke. I wrap them in a shell script and *never* change them.) So I have no use for interactive configuration steps whatsoever. (Hey, I get frightened when I see interactive prompts when installing CPAN modules!) I suspect that anyone who has to reconfigure Parrot repeatedly can be persuaded to put all the options up front. If that's the case, then we could scrap the interactive mode -- and I could write much more robust tests! So, how many people out there find that interactive prompts are absolutely essential for configuring Parrot? kid51
Re: [perl #47531] [BUG] t/src/intlist.t and t/src/io.t: 'undefined reference' test failures
On Nov 17, 2007, at 3:22 PM, chromatic via RT wrote: On Saturday 17 November 2007 11:56:59 James E Keenan wrote: On Nov 17, 2007, at 2:50 PM, chromatic via RT wrote: Hm, does your Makefile contain -fvisibility=hidden in the CFLAGS line? No. There's the problem them. Assuming you're using gcc 4.x, I'm not. [parrot] 505 $ grep gcc myconfig cc='/usr/bin/gcc-3.3', ccflags='-fno-common -no-cpp-precomp - pipe -I/usr/local/include -pipe -fno-common -Wno-long-double - DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED - DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL - DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED ', Remember all that problem I was having at the hackathon getting my first build of Parrot. You and Chip and subsequently Coke diagnosed it as due to my botched attempt to build my own gcc 4.x. So ever since, I've specified the Apple-supplied build of gcc as a command- line option. [parrot] 507 $ /usr/bin/gcc-3.3 --version gcc-3.3 (GCC) 3.3 20030304 (Apple Computer, Inc. build 1495) ... [parrot] 509 $ cat myconfigure.sh #!/bin/sh CC=/usr/bin/gcc-3.3 CX=/usr/bin/g++-3.3 /usr/local/bin/perl Configure.pl --cc=$CC --cxx=$CX --link=$CX \ --ld=$CX --without-icu --without-gmp \ $@ (Not sure how that affects the current problem, however.)
Re: [perl #47503] Remove config::init::defaults From configure tests
chromatic wrote: # New Ticket Created by chromatic # Please include the string: [perl #47503] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47503 I've seen a lot of test failures under t/configure/*.t lately where linking failed because I don't have libgdbm installed. Are you getting failures in test files other than the one you reported (auto::msvc, IIRC) and the 3 that Andy D reported? The vendor Perl has libgdbm in its libs setting within Config.pm, so any code that probes my Perl 5 configuration may think that it's okay to link against libgdbm even though it doesn't exist on my system. config::init::defaults pulls the libs setting out of the Perl 5 configuration and various tests of the Parrot configuration process use config::init::defaults to set up the environment for testing. When these tests attempt to compile and link programs, they may fail because the Perl 5 configuration may not reflect the actual run-time environment of the code. Yes, they may fail there, but only because the *only* configuration step I ran in a particular test file was config::init::defaults. For most test files and on many systems, that has sufficed. Parrot::Config::Generated is a much more reliable source of information, and if the tests truly need information about the local system for compiling and linking purposes, they should fetch the information from there, not from the Perl 5 configuration which does not necessarily reflect the state of the local machine. I can imagine an objection to this suggestion, specifically But these tests should be runnable without having previously configured Parrot! We cannot rely on the configuration process working correctly unless we can test that process! And that is precisely my objection. Parrot::Config::Generated is not available until after you've configured. You can't use it to test the configuration system before you've run Configure.pl (as you would by running, say, 'perl Configure.pl --test=configure'). I've been working on this problem and getting valuable feedback from Bernard. I've developed a way of using Parrot::Configure::Trace to more accurately identify the state of the Parrot::Configure object at each point in the configuration process, thereby enabling us to write more precisely targeted tests. I would ask you to try out these patches as I submit them and give me feedback. Thank you very much. kid51
Re: [perl #47523] [NEW] Coding standards test for spacing after commas and semicolons
Paul Cochrane wrote: # New Ticket Created by Paul Cochrane # Please include the string: [perl #47523] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47523 Hi everyone! One nit I have about C-code is that I think there should be a space after commas and semicolons. I am not a C-coder, so I don't have an authoritative opinion about this. But I would like to ask: In this a common standard/'best practice' in C programming? If so, then I think the standard should be approved. But if it's not yet generally accepted, I would say no. kid51
Re: [perl #47391] t/configure/1*.t tests incorrectly rely on init::defaults
On Nov 14, 2007, at 5:37 PM, Andy Dougherty via RT wrote: On Tue, 13 Nov 2007, James Keenan via RT wrote: Could you supply the output of perl -V for the system where you are encountering these problems? This was a perl compiled with Sun's cc. $ perl5.8 -V Thanks. I think this may prove useful. kid51
[TODO] Why two configuration steps where one would suffice?
Currently, Parrot configuration step #32 is gen::cpu, while step #50
is auto:cpu. Let's do a diff between their respective packages (at
r22775):
[parrot] 504 $ diff -w config/gen/cpu.pm config/auto/cpu.pm ~/learn/
parrot/diff.gen.auto.cpu.txt
1c1
# Copyright (C) 2001-2006, The Perl Foundation.
---
# Copyright (C) 2001-2007, The Perl Foundation.
6c6
config/gen/cpu.pm - CPU specific Files
---
config/auto/cpu.pm - CPU specific Files
10c10
Runs Crun_cpu() in Fconfig/gen/cpu/${cpuarch}/auto.pm if it
exists.
---
Runs Crun_cpu() in Fconfig/auto/cpu/${cpuarch}/auto.pm if it
exists.
14c14
package gen::cpu;
---
package auto::cpu;
18a19
21c22
use Parrot::Configure::Step qw(copy_if_diff);
---
use Parrot::Configure::Step;
24d24
28c28
$data{description} = q{Generating CPU specific stuff};
---
$data{description} = q{Running CPU specific stuff};
44c44,46
my $hints = gen::cpu:: . $conf-data-get('cpuarch') . ::auto;
---
$conf-data-add( ' ', TEMP_atomic_o = '' );# assure a
default
my $hints = auto::cpu:: . $conf-data-get('cpuarch') .
::auto;
Not very much, if you think about it. Both classes exist primarily
to run a subroutine in an OS/platform-specific .pm hints file one
level down in the hierarchy.
config/gen/cpu.pm has hints files for i386 and x86_64. In neither
case are any Makefiles, header files or any other kind of files
generated, so the name 'gen::cpu' for this config step is a misnomer.
config/auto/cpu.pm has hints files for i386, ppc, sun4 and x86_64.
They run C probes of the platform much like any other 'auto'
configuration step.
I haven't yet run Parrot::Configure::Trace to see how the values in
the Parrot::Configure object set by gen::cpu affect the steps between
#32 and #50. Nor have I experimented yet with combining the two
packages into one and running it at step #32.
But does anyone know any reason why that kind of experimentation
should be rejected *a priori*? Does anyone recall anything about
these packages that in the past mandated that their functionality be
split between the two widely separated configuration steps?
Thank you very much.
kid51
Re: [perl #46727] [TODO] config/auto/ctags.pm: Write unit tests
On Nov 4, 2007, at 11:06 PM, Paul Cochrane via RT wrote: kid51, On 05/11/2007, James Keenan via RT parrotbug- [EMAIL PROTECTED] wrote: The patch attached refactors configuration step auto::ctags to maximize testability. It also provides 3 test files to replace ptc's original test file. ptc's original functionality is, however, maintained intact. Assuming no objection, I'll apply this in 2-3 days. The patch looks good. One thing which would be a nice to have is the documentation to say what the difference between the four test files is. Or put another way: a comment as to what specific feature of ctags is being tested. Agreed, and the point applies to tests for steps other than this one. I did that when I was writing tests for some of the earlier configuration steps and have made a mental note to do that for the steps I've been working on in the last two weeks.
Re: [perl #47127] [PATCH] t/configure/111-auto_gcc-01.t test failure
On Nov 4, 2007, at 3:13 AM, Cosimo Streppone via RT wrote: However, just out of curiosity... Would the attached test work as well? I replaced all the code that does the hand-testing of auto::gcc with the automated `test_step_thru_runstep()' function. IIUC, that function does exactly what the replaced code is supposed to do. That is correct, at least up to a point. 1. The tests in t/configure/1??-*.t were originally designed to simulate the structure of Configure.pl. So they had to have a certain amount of code to get to the same point that Configure.pl arrives at just before it calls Parrot::Configure::runsteps() (which, internally, calls each step's own runstep() method). 2. The tests in t/configure/1??-*.t had to test other aspects of the way the config steps were specified, e.g., the presence of 'description'. 3. On the other hand, later configuration steps depend, to a greater or less extent, on earlier steps. I didn't want each test in t/ configure/1??-*.t to have to replicate what Configure.pl does by running *all* earlier configuration steps in order to test one aspect of a given step. The challenge was to determine how much information a given step needed in order to be testable, i.e., how many and which earlier config steps need to be run via test_step_thru_runstep() in order to be able to write more detailed tests for a given step. (In retrospect, test_step_thru_runstep() might better have been named something like: test_prerequisite_step().) In the case at hand, it turned out that 111-auto_gcc-01.t needed more information in order to test auto::gcc::runstep(). kid51
