Re: [perl #43481] t/examples/shootout.t (shootout_16.pir) fails on gentoo/x86

2007-07-05 Thread chromatic
On Wednesday 04 July 2007 15:17:33 Mark Glines wrote: > It helps, thanks. Glad to know I can't just blame gentoo. > After doing the binary search I mentioned earlier and finding that it > started breaking in svn r19441, there was some discussion in the IRC > channel. The important bit is: > > [

Re: [perl #43549] [BUG] Upgrade of flex and other software causes Parrot 'make' to fail

2007-07-05 Thread chromatic
On Wednesday 04 July 2007 19:41:03 James Keenan wrote: > Parrot 'make' failed tonight on my Debian Linux server, a location where > it had long been working successfully. I suspect that an upgrade of > non-Parrot software may be the problem, and would like suggestions for > remedies. > > In the c

[perl #43549] [BUG] Upgrade of flex and other software causes Parrot 'make' to fail

2007-07-05 Thread James Keenan via RT
I think you're correct in attributing the problem to the glibc upgrade, but make realclean did not lead to different results: -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt /usr/lib/libc_nonshared.a(stat64.oS)(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.get_pc_thunk.bx': : multiple

Sun Studio on Solaris

2007-07-05 Thread Andy Lester
I've set up a box at home running Solaris 10 with Sun Studio 12. If anyone wants an account on it so that they can work on the platform, let me know, preferably in IRC. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

[perl #43567] [PATCH] Parrot::Configure::Data: Check for Sortkeys instead of Data::Dumper version

2007-07-05 Thread brian d foy
# New Ticket Created by "brian d foy" # Please include the string: [perl #43567] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=43567 > The PAUSE indexer is confused by Parrot::Configure::Data because it sees a line that ha

[perl #43569] [PATCH] Declare PIO_win32_isatty and make it static

2007-07-05 Thread via RT
# New Ticket Created by Ron Blaschke # Please include the string: [perl #43569] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=43569 > Problem: Building Parrot on Win32 currently emits a warning for VC and an error for

Nulls for Parrot_make_COW_reference

2007-07-05 Thread Andy Lester
Is there any reason we'd want to legitimately pass a NULL string to Parrot_reuse_COW_reference and Parrot_make_COW_reference? I'd like to flag them as NN. Right now, if you pass in a NULL, you get back a NULL, and nothing is checking the return value to make sure that it's not NULL. If

[perl #43579] [PATCH] Typo in docs/glossary.pod

2007-07-05 Thread via RT
# New Ticket Created by Bob Wilkinson # Please include the string: [perl #43579] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=43579 > Hello I know that what is current is incorrect. I think that my patch correc

Re: [perl #43549] [BUG] Upgrade of flex and other software causes Parrot 'make' to fail

2007-07-05 Thread James E Keenan
James Keenan via RT wrote: I think you're correct in attributing the problem to the glibc upgrade, but make realclean did not lead to different results: -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt /usr/lib/libc_nonshared.a(stat64.oS)(.text.__i686.get_pc_thunk.bx+0x0): In function `__i686.ge

[perl #43579] [PATCH] Typo in docs/glossary.pod

2007-07-05 Thread James Keenan via RT
Patch applied in r19631.

Odd Memory Corruption

2007-07-05 Thread chromatic
In theory, this patch should apply and run cleanly. It doesn't. Thus, something somewhere pokes into memory it shouldn't. Any ideas? Alternately, any comments on this analysis? -- c === include/parrot/pobj.h == --- include/parrot

Re: Odd Memory Corruption

2007-07-05 Thread Patrick R. Michaud
On Thu, Jul 05, 2007 at 06:30:44PM -0700, chromatic wrote: > In theory, this patch should apply and run cleanly. It doesn't. > > Thus, something somewhere pokes into memory it shouldn't. > > Any ideas? Alternately, any comments on this analysis? I also get segfaults after applying this patch.