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-svnsvn up At revision 25835. C:\Prg\parrot-svnbuild_env.bat ActiveState Perl now on the PATH Setting environment for using Microsoft Visual Studio 2008 x86 tools. C:\Prg\parrot-svnperl 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
[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. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=50956 Steps look as follows: C:\Prg\parrot-svnsvn up At revision 25835. C:\Prg\parrot-svnbuild_env.bat ActiveState Perl now on the PATH Setting environment for using Microsoft Visual Studio 2008 x86 tools. C:\Prg\parrot-svnperl 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
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] Document the
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/joshua/Development/parrot/blib/lib -flat_namespace auto::sizes = -L/opt/local/lib
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 Cstatic void run_cleanup_action -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 Cvoid destroy_exception_list -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 Cvoid really_destroy_exception_list -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 Cvoid Parrot_print_backtrace -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 Cstatic void free_pool -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 Cstatic int sweep_cb_buf -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 Cstatic int sweep_cb_pmc -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 Cstatic void fix_pmc_syncs -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 than one version of perl on the
when(), smart matching, and
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.
# URL: 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 block_type pod_option* \n
.*?
^^ '=' .unsp? 'end' .ws $block_type \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
$body=[.*?]
or
some_subrule
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:
parrot_dir/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:
parrot_dir/runtime/parrot/library/SDL.pir
- change to _init_ttf
- change to signatures for TTF_Render* functions.
parrot_dir/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/
Re: when(), smart matching, and
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
Re: when(), smart matching, and
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
