RE: [perl #50956] AutoReply: Problems building in VS2008 with latest SVN tip
By the way, being new to posting bugs to the Parrot system, if there's more I can provide by way of info, don't hesitate to let me know. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -Original Message- > From: Parrot via RT [mailto:[EMAIL PROTECTED] > Sent: Monday, February 18, 2008 1:46 AM > To: [EMAIL PROTECTED] > Subject: [perl #50956] AutoReply: Problems building in VS2008 with > latest SVN tip > > Greetings, > > This message has been automatically generated in response to the > creation of a parrotbug regarding: > "Problems building in VS2008 with latest SVN tip" > > There is no need to reply to this message right now. Your ticket has > been > assigned an ID of [perl #50956]. > > Please include the string: > [perl #50956] > In the subject line of all future correspondence about this issue. To > do so, > you may reply to this message. > > Thank you, > parrotbug > > http://rt.perl.org/rt3/Ticket/Display.html?id=50956 > --- > -- > X-Originalarrivaltime: 18 Feb 2008 09:44:49.0742 (UTC) > FILETIME=[E76876E0:01C87212] > MIME-Version: 1.0 > X-Spam-Status: No, hits=-2.6 required=8.0 tests=BAYES_00,HTML_MESSAGE > X-Mailer: Microsoft Office Outlook 12.0 > X-Virus-Checked: Checked > X-Virus-Checked: Checked > Content-Language: en-us > X-Old-Spam-Check-BY: la.mx.develooper.com > Content-Type: multipart/alternative; boundary=" > =_NextPart_000_0058_01C871CF.D9691290" > Message-ID: <[EMAIL PROTECTED]> > Received: (qmail 26158 invoked by alias); 18 Feb 2008 09:45:16 - > Received: (qmail 26153 invoked from network); 18 Feb 2008 09:45:16 - > > Received: from localhost (HELO la.mx.develooper.com) (127.0.0.1) by > localhost with SMTP; 18 Feb 2008 09:45:16 - > Received: (qmail 26115 invoked by alias); 18 Feb 2008 09:45:15 - > Received: from la.mx.develooper.com (HELO x1.develooper.com) > (63.251.223.176) by la.mx.develooper.com (qpsmtpd/0.28) with SMTP; Mon, > 18 Feb 2008 01:45:07 -0800 > Received: (qmail 26067 invoked by uid 225); 18 Feb 2008 09:45:04 - > Received: (qmail 26063 invoked by alias); 18 Feb 2008 09:45:03 - > Received: from kyle.guhhome.com (HELO kyle.guhhome.com) (216.232.79.64) > by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Mon, 18 Feb 2008 > 01:44:55 -0800 > Received: from XPWork ([71.112.81.67] RDNS failed) by kyle.guhhome.com > with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Feb 2008 01:44:49 -0800 > Delivered-To: [EMAIL PROTECTED] > Delivered-To: [EMAIL PROTECTED] > Delivered-To: [EMAIL PROTECTED] > Subject: Problems building in VS2008 with latest SVN tip > Return-Path: <[EMAIL PROTECTED]> > Return-Path: [EMAIL PROTECTED] > X-Spam-Check-BY: la.mx.develooper.com > Thread-Index: AchyEuTVBFRApfpfR3yjE0dM/w0zCQ== > X-Old-Spam-Status: No, hits=-2.6 required=8.0 > tests=BAYES_00,HTML_MESSAGE > Date: Mon, 18 Feb 2008 01:44:46 -0800 > To: <[EMAIL PROTECTED]> > From: "Ted Neward" <[EMAIL PROTECTED]> > > Steps look as follows: > > > > > > C:\Prg\parrot-svn>svn up > > At revision 25835. > > > > C:\Prg\parrot-svn>build_env.bat > > ActiveState Perl now on the PATH > > Setting environment for using Microsoft Visual Studio 2008 x86 tools. > > > > C:\Prg\parrot-svn>perl Configure.pl > > Parrot Version 0.5.2 Configure 2.0 > > Copyright (C) 2001-2008, The Perl Foundation. > > > > Hello, I'm Configure. My job is to poke and prod your system to figure > out > > how to build Parrot. The process is completely automated, unless you > passed > in > > the `--ask' flag on the command line, in which case I'll prompt you for > a > few > > pieces of info. > > > > Since you're running this program, you obviously have Perl 5--I'll be > pulling > > some defaults from its configuration. > > > > Checking > MANIFEST.done. > > Setting up Configure's default > values.done. > > Setting up installation > paths.done. > > Tweaking settings for > miniparrot...skipped. > > Loading platform and local hints > filesdone. > > Finding header files distributed with > Parrot..done. > > Determining what C compiler and linker to > use.done. > > Determining whether make is > installed..yes. > > Determining whether lex is > installed...skipped. > > Determining whether yacc is > installed..skipped. > > Determining if your C compiler is actually > gcc..no. > > Determining whether libc has the backtrace* functions (glibc > only)..no. > > Determining Fink location on > Darwinskipped. > > Determining i
[perl #50956] Problems building in VS2008 with latest SVN tip
# New Ticket Created by "Ted Neward" # Please include the string: [perl #50956] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50956 > Steps look as follows: C:\Prg\parrot-svn>svn up At revision 25835. C:\Prg\parrot-svn>build_env.bat ActiveState Perl now on the PATH Setting environment for using Microsoft Visual Studio 2008 x86 tools. C:\Prg\parrot-svn>perl Configure.pl Parrot Version 0.5.2 Configure 2.0 Copyright (C) 2001-2008, The Perl Foundation. Hello, I'm Configure. My job is to poke and prod your system to figure out how to build Parrot. The process is completely automated, unless you passed in the `--ask' flag on the command line, in which case I'll prompt you for a few pieces of info. Since you're running this program, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking MANIFEST.done. Setting up Configure's default values.done. Setting up installation paths.done. Tweaking settings for miniparrot...skipped. Loading platform and local hints filesdone. Finding header files distributed with Parrot..done. Determining what C compiler and linker to use.done. Determining whether make is installed..yes. Determining whether lex is installed...skipped. Determining whether yacc is installed..skipped. Determining if your C compiler is actually gcc..no. Determining whether libc has the backtrace* functions (glibc only)..no. Determining Fink location on Darwinskipped. Determining if your C compiler is actually Visual C++..yes. Detecting compiler attributes (-DHASATTRIBUTE_xxx)done. Detecting supported compiler warnings (-Wxxx)..skipped. Enabling optimization...no. Determining flags for building shared libraries...done. Determine if parrot should be linked against a shared library..yes. Determining what charset files should be compiled in..done. Determining what encoding files should be compiled in.done. Determining what types Parrot should use..done. Determining what opcode files should be compiled in...done. Determining what pmc files should be compiled in..done. Determining your minimum pointer alignment. 1 byte. Probing for C headers.done. Determining some sizesdone. Computing native byteorder for Parrot's wordsize.little-endian. Test the type of va_ptr (this test is likely to segfault)stack. Figuring out how to pack() Parrot's types.done. Figuring out what formats should be used for sprintf..done. Determining if your C library has a working S_ISREG.no. Determining CPU architecture and OS...done. Determining architecture, OS and JIT capability...done. Generating CPU specific stuff.done. Verifying that the compiler supports function pointer castsyes. Determining whether your compiler supports computed gotono. Determining if your compiler supports inline...yes. Determining what allocator to use.done. Determining if your C library supports memalign.no. Determining some signal stuff.done. Determining whether there is socklen_t..no. Determining if your C library has setenv / unsetenv...unsetenv. Determining if your platform supports AIO...no. Determining if your platform supports GMP...no. Determining if your platform supports readline..no. Determining if your platform supports gdbm..no. Testing snprintf..done. Determining whether perldoc is installed...yes. Determining whether python is installed.yes, 2.5.1. Determining whether GNU m4 is installedyes. Determining whether (exuberant) ctags is installed..no. Determining Parrot's revision
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.
Parrot Bug Summary
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Feb 18 14:00:07 2008 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with most open tickets
---
Numbers
Ticket Counts: 115 new + 732 open = 847
Created this week: 19
Closed this week: 14
---
New Issues
New issues that have not been responded to yet
1 - 2 weeks old
50708 segfault in pbc_merge
50648 [TODO][C] mark_object_cache in src/oo.c needs implementation
50644 [TODO] refactor src/oo.c: fail_if_type_exists() and fail_if_exist
50642 [CAGE] refactor init_class_from_hash & parrot_class_register
50616 [PATCH] add lists to pynie
50596 [PATCH][PCT] Add basic "tests"
2 - 3 weeks old
50520 [PATCH][NQP] method call and =:= tests
50508 [PATCH] evaluate the first child of a PAST::Var :scope('attribute') as
the object
50500 [PROPOSAL][PAST] add PAST::Var :scope('attribute')
50448 [Memory Leak] IMCC Can Leak Lexer Data on Exception
50424 [PROPOSAL][PCT] allow empty PAST::Stmts nodes
50400 [BUG] segfault in pdd17pmc branch
50360 Redesign Parrot NCI callback functionality
3 - 4 weeks old
50238 [PATCH] Remove cast in fetch_buf_... calls in pf_items.c
50092 [TODO] pct - explicit transcode in PCT::Grammar::string_literal
50090 [TODO] pge - throw useful exception on non-quoted non-word characters
50068 Configure doesn't detect backtrace* on ubuntu gutsy
4 - 5 weeks old
49970 [BUG] -O1 and -O2 don't turn on -Ot as per docs
49968 [BUG] 'parrot -O2 oofib.pir' errors out, when -O1 succeeds
49966 [BUG] parrot -v -O2 segfaults, when -v and -O2 separately both work
49832 Error making parrot-0.5.2 in MacosX
49818 [PATCH] Build on QNX 6
5 - 6 weeks old
49718 JIT Core Needs to Handle Scheduler Tasks
6 - 7 weeks old
49328 [BUG] problem between PBC loading and garbage collection
49258 Parrot::Test with --run-exec assumes "." is in $PATH
7 - 8 weeks old
49177 [TODO] pct - PAST::Val node should throw exception if :value attribute
not set
8 - 9 weeks old
49023 Error in library/pg on Ubuntu 7.10
49001 [PROPOSAL][DOCS] Change word "compilation_unit" into something else (like
"sub")
48877 [TODO] Don't generate .constant declarations for vtable method names.
9 - 10 weeks old
48749 [BUG] t/examples/tutorial.t if_unless failure (Win32)
48645 [CAGE] Make PMCs depend on Parrot::Pmc2c::* Modules
48587 [BUG] pmc.num contains missing PMCs
48581 [DEPRECATED] vtable type_keyed_str
48549 [RFC][PIR] Let .namespace (no args) have empty brackets
48513 [TODO][PCT] Use of int registers in PCT.
48507 [BUG] oo - n_add, n_sub, etc. don't work with objects
48467 [BUG] assignment of objects creates Ref instead of copy
48445 [TODO] [NQP] - report undeclared variable usage
48439 [TODO] [configure] compiling Parrot with LLVM
10 - 11 weeks old
48367 intlist_get could be dereferencing NULL
48357 Initialize vtables for newly created interpreter
48296 Implement get_namespace vtable from pdd17
48286 [TODO] [C] Warnings aren't emitted if a var isn't initialised and -w flag
is on in propagate_need()
48282 [TODO] [C] Check that invoke is ok near the set_addr instruction in
bb_findadd_edge()
48280 [TODO] [C] Check for a sub with more up-to-date unit->type lookup
48274 [TODO] [C] Stop ignoring the known errors in Parrot_dlopen()
48272 [TODO] [C] Stop exporting Parrot_signbit()
48264 [TODO] [C] Write file-level documentation
48212 "make smoke" hangs on win32 latest build
48206 [TODO] [cola] Check that expression evaluates to a method in
gen_method_call()
48204 [TODO] [cola] Check method signature in gen_arg_list_expr() and find out
what type is expected
48202 [TODO] [cola] Rewrite push_sym() to call generic Node versions of calls
48200 [TODO] [cola] Add documentation to files and functions
48198 [TODO] [cola] Add support for member resolution in lookup_type()
48196 [TODO] [APL] Should the PMC in set_shape() be cloned?
48194 [TODO] [APL] Move any constant string declarations into class_init()
48192 [TODO] [amber] Correct overflow issue in integer()
48190 [TODO] [amber] Can null variable check be reinstated by generating n_neg
instead of neg?
48188 [TODO] [amber] Correct overflow for -maxint in abs()
48186 [TODO] [amber] Consider using unicode in character()
48184 [TODO] [amber] Use has(index) to check indices in set_item()
48182 [TODO] [amber] Reject out of range values in item()
48180 [TODO] [amber] Reject first() and last() methods if count = 0
48176 [TODO] [pugs] Warning: use of uninitialized value
48174 [TODO] [pugs] Store undef for consistency
48172 [TODO] [pugs] Getting nonexistent value, exception or undef?
48170 [TODO] [regex] Remove 'use of uninitialized value' issues in match.pmc
48168 [TODO] [regex] Implement init_pmc
48164 [TODO] [Tcl] Doc
Re: r25810 - make error
[snip] > Am attaching my results for contrast. Mine are achieved with the > wrapper around Configure.pl which I posted on list earlier in > thread. Note that in mine 'ld' picks up the value passed via shell > setting at step 'inter::progs'. > > This works for me, but may not be relevant to your problem. I had to > adopt this approach due to an abortive effort to build my own gcc-4.1 > on my iBook prior to joining the Parrot project. 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? init::manifest => init::defaults => env MACOSX_DEPLOYMENT_TARGET=10.3 cc init::install => env MACOSX_DEPLOYMENT_TARGET=10.3 cc init::miniparrot => env MACOSX_DEPLOYMENT_TARGET=10.3 cc init::hints => c++ init::headers => c++ inter::progs => g++-4.0 inter::make => g++-4.0 inter::lex => g++-4.0 inter::yacc => g++-4.0 auto::gcc => g++-4.0 auto::backtrace => g++-4.0 auto::fink => g++-4.0 auto::msvc => g++-4.0 auto::attributes => g++-4.0 auto::warnings => g++-4.0 init::optimize => g++-4.0 inter::shlibs => g++-4.0 inter::libparrot => g++-4.0 inter::charset => g++-4.0 inter::encoding => g++-4.0 inter::types => g++-4.0 auto::ops => g++-4.0 auto::pmc => g++-4.0 auto::alignptrs => g++-4.0 auto::headers => g++-4.0 auto::sizes => g++-4.0 auto::byteorder => g++-4.0 auto::va_ptr => g++-4.0 auto::pack => g++-4.0 auto::format => g++-4.0 auto::isreg => g++-4.0 auto::arch => g++-4.0 auto::jit => g++-4.0 auto::cpu => g++-4.0 auto::funcptr => g++-4.0 auto::cgoto => g++-4.0 auto::inline => g++-4.0 auto::gc => g++-4.0 auto::memalign => g++-4.0 auto::signal => g++-4.0 auto::socklen_t => g++-4.0 auto::env => g++-4.0 auto::aio => g++-4.0 auto::gmp => g++-4.0 auto::readline => g++-4.0 auto::gdbm => g++-4.0 auto::snprintf => g++-4.0 auto::perldoc => g++-4.0 auto::python => g++-4.0 auto::m4 => g++-4.0 auto::ctags => g++-4.0 auto::revision => g++-4.0 gen::icu => g++-4.0 gen::config_h => g++-4.0 gen::core_pmcs => g++-4.0 gen::parrot_include => g++-4.0 gen::languages => g++-4.0 gen::makefiles => g++-4.0 gen::platform => g++-4.0 gen::config_pm => g++-4.0 init::manifest => init::defaults => -L/opt/local/lib -L/usr/local/lib init::install => -L/opt/local/lib -L/usr/local/lib init::miniparrot => -L/opt/local/lib -L/usr/local/lib init::hints => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace init::headers => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace inter::progs => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace inter::make => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace inter::lex => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace inter::yacc => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace auto::gcc => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace auto::backtrace => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace auto::fink => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace auto::msvc => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace auto::attributes => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace auto::warnings => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace init::optimize => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace inter::shlibs => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace inter::libparrot => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace inter::charset => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace inter::encoding => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace inter::types => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace auto::ops => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace auto::pmc => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace auto::alignptrs => -L/opt/local/lib -L/usr/local/lib -L/Users/joshua/Development/parrot/blib/lib -flat_namespace auto::headers => -L/opt/local/lib -L/usr/local/lib -L/Users/jos
Re: r25810 - make error
On Sun, 17 Feb 2008, chromatic wrote: > On Sunday 17 February 2008 17:13:37 James E Keenan wrote: > > > > /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. > > Compiling with gcc and linking with g++ looks more suspicious to me. Is that > really how things work on Darwin? > > I'm fairly certain C and C++ have very different ABIs. It should be fine. In general, some of the libraries to be linked with parrot are written in C (e.g. -lparrot itself, most system libraries, etc.) but others may have been written in C++ (e.g. icu). Using C++ as a linker seems the most robust way to deal with this situation. I'd expect in the future that more and more extensions will come to rely on C++ libraries, so this will become more of an issue in the future than it is now. 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. This is also a good example of why parrot shouldn't be installed at present, and why I think attempts to make it easy to install (e.g via yum, macports, rpm, apt-get, etc.) are not a good idea at this time. -- Andy Dougherty [EMAIL PROTECTED]
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
> 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. 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. 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 t/src/intlist.t(Wstat: 1024 Tests: 4 Failed: 4) Failed tests: 1-4 Non-zero exit status: 4 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 Files=554, Tests=11167, 1568 wallclock secs (10.36 usr 9.70 sys + 581.23 cusr 230.30 csys = 831.59 CPU) Result: FAIL Failed 5/554 test programs. 11/11167 subtests failed. make: *** [test] Error 255
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
On Feb 18, 2008, at 11:04 AM, James E Keenan wrote: I suspect a 'make realclean' should fix this. or make distclean, which is even more thorough than realclean. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
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
On Monday 18 February 2008 06:43:22 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. Ah, you're right. > This is also a good example of why parrot shouldn't be installed at > present, and why I think attempts to make it easy to install (e.g via yum, > macports, rpm, apt-get, etc.) are not a good idea at this time. We have to fix it eventually. What kind of solution do you think is best? Will re-arranging the order of library include paths to the linker fix it, or is there something even better? -- c
Re: r25810 - make error
On Mon, 18 Feb 2008, James E Keenan wrote: > 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? I don't know. In general, if you install something via some sort of package manager, then it is usually best to use the same package manager to uninstall. Otherwise, the package manager may get confused. If you installed by hand (e.g. with parrot's "make reallyinstall", then you have to uninstall by hand, since parrot doesn't have a 'make uninstall' target. The original poster mentioned something called 'macports', but I don't know anything about it. A simple 'rm /usr/local/lib/libparrot.dylib' will obviously remove the file in question, but will leave behind any other files installed by parrot. Other than by looking at file and directory names and timestamps, I don't know any way to identify "parrot stuff" that might have been installed at the same time. -- Andy Dougherty [EMAIL PROTECTED]
Re: [RT#48260] Documentation missing]
Two straight comment patches seeking commitment: currently attached. (to exception.c and headers.c) -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.comIndex: src/exceptions.c === --- src/exceptions.c (revision 25797) +++ src/exceptions.c (working copy) @@ -180,7 +180,9 @@ =item C -RT#48260: Not yet documented!!! +Takes an interpreter name and a stack pointer. +Runs the action subroutine with an INTVAL arg of 0. +Used in Parrot_push_action. =cut @@ -762,7 +764,10 @@ =item C -RT#48260: Not yet documented!!! +Takes an interpreter name. +Destroys (frees the memory allocated to) the exception buffers list and the +associated exceptions free list for the specified interpreter. +Uses really_destroy_exception_list (see below) to do the job. =cut @@ -779,7 +784,9 @@ =item C -RT#48260: Not yet documented!!! +Takes a pointer to an exception (which had better be the last one in the list). +Walks back through the list, freeing the memory of each one, until NULL encountered. +Used by destroy_exception_list. =cut @@ -1000,7 +1007,8 @@ =item C -RT#48260: Not yet documented!!! +Display the primrose path to disaster, (the stack frames leading up to the abort). +Used by Parrot_confess. =cut Index: src/headers.c === --- src/headers.c (revision 25797) +++ src/headers.c (working copy) @@ -726,7 +726,9 @@ =item C -RT#48260: Not yet documented!!! +Takes a pointer to a pool. +Loops backwards through it, freeing all arenas and their associated objects. +Used by sweep_cb_buf, sweep_cb_pmc, & Parrot_destroy_header_pools =cut @@ -750,7 +752,11 @@ =item C -RT#48260: Not yet documented!!! +Take an interpreter name, pointer to an object pool, an unused argument, +and a pointer to a boolean. +Garbage-collect unused memory from the pool. +Used by Parrot_destroy_header_pools. +Returns 0. =cut @@ -781,7 +787,10 @@ =item C -RT#48260: Not yet documented!!! +Take an interpreter name and a pointer to a pool. +Remove dead objects from the pool and free the memory. +Returns 0. +Used by sweep_cb_buf. =cut @@ -840,7 +849,10 @@ =item C -RT#48260: Not yet documented!!! +Takes pointers to an interpreter and a pool. +Goes through the arena looking for shared objects and transferring +them to the interpreter, so none get orphaned. +Used by Parrot_merge_header_pools. =cut
Re: r25810 - make error
On Mon, 18 Feb 2008, chromatic wrote: > On Monday 18 February 2008 06:43:22 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. > > Ah, you're right. > > > This is also a good example of why parrot shouldn't be installed at > > present, and why I think attempts to make it easy to install (e.g via yum, > > macports, rpm, apt-get, etc.) are not a good idea at this time. > > We have to fix it eventually. What kind of solution do you think is best? > Will re-arranging the order of library include paths to the linker fix it, or > is there something even better? I think there are two broad issues, the first primarily aimed at end users, and the second primarily aimed at developers. First, installing libparrot.so into any prominent public directory (such as /usr/local/lib) makes it available for others to use, and can even reasonably be seen as inviting others to use it, no matter what version number you put on it or what caveats you stick in the documentation. However, I don't think libparrot's ABI is anywhere near remotely stable enough for this to be a wise course of action. libparrot currently exports thousands and thousands of symbols that it probably shouldn't, and there are whole subsystems waiting to be implemented. It is reasonable to expect that subsequent releases of parrot over the coming years will repeatedly break binary compatibility in big ways. If people want to install a shared libparrot.so anyway, some sort of mechanism to support simultaneous installation of different versions will be needed to avoid breaking everything that relies on libparrot.so. Second, there is a difficulty building and testing a development version of parrot if you already have a shared libparrot.so in a directory that is part of the standard load path. To be specific: Suppose you have installed libparrot.so into /usr/lib/libparrot.so, and you are now building a fresh copy of parrot in $HOME/src. How can you ensure that during building and testing that the new $HOME/src/parrot executable picks up the new version of the shared library in $HOME/src/parrot/lib/blib/libparrot.so, and doesn't pick up /usr/lib/libparrot.so? The answer is "it depends on your operating system, and I'm not sure there's a guaranteed way to do it on every operating system." We face the same issue with perl5's shared libperl.so, so I'll share some relevant snippets of that documentation here. Here is the relevant passage from perl5's INSTALL document. (This only applies to Unix systems. I don't know the equivalent Windows incantations.) There is also an potential problem with the shared perl library if you want to have more than one "flavor" of the same version of perl (e.g. with and without -DDEBUGGING). For example, suppose you build and install a standard Perl 5.10.0 with a shared library. Then, suppose you try to build Perl 5.10.0 with -DDEBUGGING enabled, but everything else the same, including all the installation directories. How can you ensure that your newly built perl will link with your newly built libperl.so.8 rather with the installed libperl.so.8? The answer is that you might not be able to. The installation directory is encoded in the perl binary with the LD_RUN_PATH environment variable (or equivalent ld command-line option). On Solaris, you can override that with LD_LIBRARY_PATH; on Linux, you can only override at runtime via LD_PRELOAD, specifying the exact filename you wish to be used; and on Digital Unix, you can override LD_LIBRARY_PATH by setting the _RLD_ROOT environment variable to point to the perl build directory. In other words, it is generally not a good idea to try to build a perl with a shared library if $archlib/CORE/$libperl already exists from a previous build. A good workaround is to specify a different directory for the architecture-dependent library for your -DDEBUGGING version of perl. You can do this by changing all the *archlib* variables in config.sh to point to your new architecture-dependent library. Also in the perl5 source tree, in the file Porting/pumpkin.pod, (available with 'perldoc pumpkin' on most systems) I have the following musings on a this topic: =head2 Shared libperl.so location Why isn't the shared libperl.so installed in /usr/lib/ along with "all the other" shared libraries? Instead, it is installed in $archlib, which is typically something like /usr/local/lib/perl5/archname/5.00404 and is architecture- and version-specific. The basic reason why a shared libperl.so gets put in $archlib is so that you can have more th
[perl #50966] PATCH: Allow git checkouts to pass at least one test that is svn checkout dependent
# New Ticket Created by "Joshua McAdams" # Please include the string: [perl #50966] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50966 > I'm using git-svn to check parrot; however, some of the parrot tests look for SVN-specific information. This patch is the beginning of allowing for a git-based checkout to pass all of the parrot tests. It includes adding a couple of subroutines to Parrot::Distribution and then using the results of those subs (at least one of them... the other was a suggestion from particle) to skip svn tests if the checkout isn't from svn. Files Changed: - lib/Parrot/Distribution.pm -> Added two subroutines. One checks for a .svn directory in the distribution base, the other checks for a .git directory. The check for svn or git could be more complex, but this simple solution seems to be enough for me at least. - /t/perl/Parrot_IO.t -> used Parrot::Distribution, created a new instance of it, and then used the 'is_svn_co' subroutine that was just added to skip a test if the checkout is not an svn checkout. - CREDITS -> because the submisson.pod told me to git_or_svn.patch Description: Binary data
perl6-all@perl.org
This is actually a bug from Perl 5, but Perl 5's given is supposed to
act like Perl 6's given. The long post is in use.perl:
http://use.perl.org/~brian_d_foy/journal/35682
I was playing with a when condition that used a logical operator to see
if the topic was both an element of an array and a key of a hash:
given( $foo ) {
when( @array && %hash ) { ... }
}
I thought that should acting like two smart matches:
given( $foo ) {
when( (@array ~~ $_) && (%hash ~~ $_) ) { ... }
}
In Perl 5.10.0, it's acting like one smart match, which I'm pretty sure
is a bug:
given( $foo ) {
when( ( scalar @array and scalar %hash ) ~~ $_) ) { ... }
}
Perl 5's perlsyn talks about smart matching with logical operators, but
I don't see that in S04 (or anywhere else). Knowing what is supposed to
happen in Perl 6 would help me fix the Perl 5.10 version.
So what would Perl 6 do (WWP6D) ? :)
[perl #50968] [BUG] trouble with perl 6 grammars and capturing '.*?'
# New Ticket Created by Jerry Gay
# Please include the string: [perl #50968]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=50968 >
in rakudo's perl6doc parser
(languages/perl6/src/utils/perl6doc/grammar.pg), i have the following:
token pod_delimited_block {
^^ '=' <.unsp>? 'begin' <.ws> * \n
.*?
^^ '=' <.unsp>? 'end' <.ws> $ \N*
{*}
}
i'd like to capture '.*?' either via an alias or better, via a
subrule. however, modifying the grammar to something that will
capture, like
(.*?)
or
$=[.*?]
or
causes the match to fail. smells like a pge bug to me.
~jerry
Re: [perl #50708] segfault in pbc_merge
On Sunday 10 February 2008 21:56:06 Ryan Voots wrote: > When calling pbc_merge outside of the parrot root I encountered a > segfault because pbc_merge cannot find lua_group.so, when run inside the > parrot root it is able to find the .so inside the runtime directory. > > a simple test case of this is to compile these two files to pbc's and > then use pbc_merge on them outside the parrot root. I would think > either an option to pbc_merge to tell it where to find the parrot > runtime, or an envrionment variable might be appropriate, but a check > should be made that it can find the needed files to merge and print an > error when not found I can't reproduce this as of r25855; can you provide a backtrace from pbc_merge? -- c
Re: [RT#48260] Documentation missing]
On Monday 18 February 2008 07:38:57 [EMAIL PROTECTED] wrote: > Two straight comment patches seeking commitment: currently attached. > > (to exception.c and headers.c) Thanks, applied with some tweaks as r25858. -- c
Re: [perl #50938] [PATCH] Remove instantiate opcode
On Sunday 17 February 2008 07:01:00 Paul Cochrane wrote: > the attached patch removes the instantiate opcode (see RT#48022). The > patch also removes three tests in t/pmc/integer.t, which is something > I'm not 100% sure about. After I'd tried to update the tests to use > "new" instead of "instantiate" (but without total success), and after > an off-list discussion with kjs++, I got the feeling that the three > tests were basically testing the "instantiate" opcode and so since the > opcode is no longer there, that the tests should be removed. However, > since I'm somewhat loath to remove tests it was decided it would be > best to ask the list. So, yeah, what are people's opinions? +1 -- c
Re: [perl #50942] [PATCH] Parrot-SDL-TTF font color
On Sunday 17 February 2008 10:45:21 Richard Hainsworth wrote:
> /examples/sdl/blue_font.pir
> works but produces random colors even though it should be blue
> while .../blue_rect.pir gives a solid blue
>
> The native SDL routine for font needs to have a color integer (as for
> rectangles) not a color pmc (as currently). The signature for the font
> rendering routines needs to be changed too.
It doesn't really take an integer though. It takes a struct (not a pointer to
a struct) composed of four unsigned integers:
typedef struct SDL_Color {
Uint8 r;
Uint8 g;
Uint8 b;
Uint8 unused;
} SDL_Color;
SDL_Surface * SDLCALL TTF_RenderText_Solid(TTF_Font *font,
const char *text, SDL_Color fg);
Passing a pointer is definitely wrong, but it looks to me like we should
review the shifts of the individual components of the integer. That makes me
wonder if there's an endianness problem somewhere.
> Files changed:
> /runtime/parrot/library/SDL.pir
> - change to _init_ttf
> - change to signatures for TTF_Render* functions.
>
> /runtime/parrot/library/SDL/Font.pir
> - change render_text method
Can you send these as unified diffs next time? They're difficult to apply
this way.
-- c
Re: [perl #50908] [CAGE] gcc -Werror=declaration-after-statement
On Friday 15 February 2008 11:35:04 Will Coleda wrote: > According to http://gcc.gnu.org/onlinedocs/index.html#DIR, looks like > as of gcc 4.2.3 (but not 4.1.2), we can use the following option to > gcc: > > -Werror=declaration-after-statement > > To help enforce our C89 compliance by causing this particular style to > become an error instead of just a warning. This should be added as a > default to the build options if a recent enough version of gcc is > available. Works for me with gcc 4.1.3; I think this is closeable. -- c
Remove Test::Simple from Repository
If we're relying on at least Perl 5.8.0 to build Parrot, can we rely on the presence of Test::Simple in the installed Perl? It's a core module as far back as 5.8.0. -- c
Re: [perl #50908] [CAGE] gcc -Werror=declaration-after-statement
On Feb 18, 2008 8:39 PM, chromatic <[EMAIL PROTECTED]> wrote: > On Friday 15 February 2008 11:35:04 Will Coleda wrote: > > > According to http://gcc.gnu.org/onlinedocs/index.html#DIR, looks like > > as of gcc 4.2.3 (but not 4.1.2), we can use the following option to > > gcc: > > > > -Werror=declaration-after-statement > > > > To help enforce our C89 compliance by causing this particular style to > > become an error instead of just a warning. This should be added as a > > default to the build options if a recent enough version of gcc is > > available. > > Works for me with gcc 4.1.3; I think this is closeable. > > -- c > > It's not checked in anywhere, though. We're just using -Wdeclaration-after-statement not -Werror=declaration-after-statement -- Will "Coke" Coleda
Re: Remove Test::Simple from Repository
On Feb 18, 2008 5:41 PM, chromatic <[EMAIL PROTECTED]> wrote: > If we're relying on at least Perl 5.8.0 to build Parrot, can we rely on the > presence of Test::Simple in the installed Perl? It's a core module as far > back as 5.8.0. > +1 ~jerry
Re: Remove Test::Simple from Repository
chromatic wrote: If we're relying on at least Perl 5.8.0 to build Parrot, can we rely on the presence of Test::Simple in the installed Perl? Yes. remove++ to all 3 packages in lib/Test/
perl6-all@perl.org
On Mon, Feb 18, 2008 at 04:22:57PM -0600, brian d foy wrote:
: This is actually a bug from Perl 5, but Perl 5's given is supposed to
: act like Perl 6's given.
Unfortunately, "supposed to" is pretty far off the mark in this case...
Perl 5's switch differs from Perl 6's in several significant ways.
First, it copied an old design when smartmatching was symmetrical, which
it hasn't been for some time in Perl 6. The design of how arrays match
has changed as well. (They match as a whole in Perl 6, and you must use
any(@array) to match against the individual array elements. Finally,
there are just quite a few things that cannot be done the same way in
Perl 5 because of the fundamentally different way it parses and treats
various object references in scalar context.
: The long post is in use.perl:
:
:http://use.perl.org/~brian_d_foy/journal/35682
:
: I was playing with a when condition that used a logical operator to see
: if the topic was both an element of an array and a key of a hash:
:
:given( $foo ) {
: when( @array && %hash ) { ... }
: }
:
: I thought that should acting like two smart matches:
:
:given( $foo ) {
: when( (@array ~~ $_) && (%hash ~~ $_) ) { ... }
: }
:
: In Perl 5.10.0, it's acting like one smart match, which I'm pretty sure
: is a bug:
:
:given( $foo ) {
: when( ( scalar @array and scalar %hash ) ~~ $_) ) { ... }
: }
which is exactly what I would expect from Perl 5, unless when is
really a very intelligent macro of some sort. As far as I know
Perl 5's when has no clue how to distribute a smartmatch.
: Perl 5's perlsyn talks about smart matching with logical operators, but
: I don't see that in S04 (or anywhere else). Knowing what is supposed to
: happen in Perl 6 would help me fix the Perl 5.10 version.
:
: So what would Perl 6 do (WWP6D) ? :)
Certainly nothing like you'd expect from the P5 implementation. :)
To see the exact semantics of smartmatching in P6, I highly recommend
the section on "Smart Matching" in S03.
To write what you want there, you'd need something like:
when any(@array) & any(%hash.keys) {...}
Actually, you might just get away with:
when %hash & any(@array) {...}
There can be no corresponding operation in Perl 5 because %hash in
scalar context would not return the hash, but only its bucket count.
And, of course, there's no "&" infix for "and" junctional logic.
At best you could use
when (all(\%hash, any(@array))) {...}
assuming you've used something that pulls in Quantum::Superpositions
or Perl6::Junctions.
But even in Perl 6, "&&" or "and" is not going to autothread the
junction for you, which is why you need "&" or all() to distribute the
"~~" if you don't do it the explicit way by distributing $_ yourself:
when %hash.:exists{$_} and @array.any ~~ $_ {...}
Larry
Re: [perl #50886] Re: [PATCH] fixed unreachable code warnings after real_exception calls
On Thursday 14 February 2008 21:25:35 Andrew Whitworth wrote: > ..forgot the patch, again. I'll get better at this, i swear. Thanks, applied with tweaks as r25863. I removed the commented-out lines, for two reasons. First, we stick with C89 which doesn't allow C++-style comments. Second, there's no reason to comment out code. If we need to get it back, we can look in our revision control history. There were also some tab characters and weird line endings, but that's a minor thing. -- c
perl6-all@perl.org
In article <[EMAIL PROTECTED]>, Larry Wall
<[EMAIL PROTECTED]> wrote:
> :given( $foo ) {
> : when( ( scalar @array and scalar %hash ) ~~ $_) ) { ... }
> : }
> which is exactly what I would expect from Perl 5, unless when is
> really a very intelligent macro of some sort. As far as I know
> Perl 5's when has no clue how to distribute a smartmatch.
Well, I don't think you'd expect that based on perlsyn, so it looks
like the docs need to change to match what it does. I think the idea in
P5 is seriously borken.
> To write what you want there, you'd need something like:
>
> when any(@array) & any(%hash.keys) {...}
It's not that I want that, but I'm trying to figure out what happens
with the logical operators based on the P5 docs. I'm starting from the
syntax rules and finding out what I can do with them rather than
starting with a task and looking for a way to do it. My interest is how
I'm going to answer questions in front of a bunch of students who use
the rules in unexpected ways.
So, this isn't a Perl 6 issue, and I'll relay to the P5 folks that they
aren't even close, have no hope of being close, and that they'll have
to figure it out on their own. :)
Re: [perl #50776] myops alarm test failure
On Wednesday 13 February 2008 01:47:49 Klaas-Jan Stol wrote: > I still get this test failure, as shown below. > (I checked in rt and saw that a patch was applied unrolling some loop in > this test somewhere in June 2007.) > > kjs > > === > t/dynpmc/sub.ok > t/dynpmc/subclass_with_pir_methodok > t/dynoplibs/dan..ok > t/dynoplibs/myopsok 6/10 > t/dynoplibs/myopsNOK 7/10# Failed test > (t/dynoplibs/myops.t at line 148) > # Exited with error code: 255 > # Received: > # alarm > # alarm > # alarm > # alarm > # > # Expected: > # /alarm > # alarm > # alarm/ > # > t/dynoplibs/myopsok 8/10# Looks like you failed > 1 test of 10. > t/dynoplibs/myopsdubious > Test returned status 1 (wstat 256, 0x100) > DIED. FAILED test 7 > Failed 1/10 tests, 90.00% okay Which platform and compiler? -- c
Re: [perl #50238] [PATCH] Remove cast in fetch_buf_... calls in pf_items.c
On Friday 25 January 2008 10:05:38 NotFound wrote: > As I said in a previous message, there are two casts in pf_items.c > that are unnecessary and seems to be wrong. > > This patch removes both, avoiding warnings. Tested in Ubuntu 7.10 on > Intel platform. Thanks, applied with tweaks (someone silenced them, but they're still unnecessary) as r25864. -- c
