Weekly Perl 6 mailing list summary for 5-11 November, 2006

Weekly Perl 6 mailing list summary This week on the Perl 6 mailing lists "...problem 2 is probably just me being confused (though I'd love an explanation, from @leo ;-))." -- Jonathan Worthington, in 'set_pmc_keyed_int delegates to set_pmc_keyed...? ' Lan

[perl #40834] [BUG] - PMC methods aren't inherited to PIR subclasses

# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #40834] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40834 > If a METHOD is defined in a *.pmc file, that METHOD is not automatically inherited

[perl #40818] [PATCH] Silence warning in t/library/pcre.t

Thanks, applied (only slightly modifie) as r15442.

[perl #40803] [BUG] 'make' fails on Darwin at -lgmp

On Sat Nov 11 03:56:22 2006, [EMAIL PROTECTED] wrote: > I believe that the attachment containing your make output was truncated. > Can you try again or just inline the make error(s)? > > Thanks, It should be noted that I upgraded to GMP 4.2.1. before trying to build Parrot (or, more precisely,

Re: [perl #40803] [BUG] 'make' fails on Darwin at -lgmp

Joshua Hoblitt wrote: > I believe that the attachment containing your make output was truncated. > Can you try again or just inline the make error(s)? > > Thanks, > > -J > At Jerry Gay's suggestion, I did a 'make clean' and started anew. Compiling with: xx.c cc -I./include -fno-common -no-cpp

[perl #40803] [BUG] 'make' fails on Darwin at -lgmp

Next attempt: At Jerry's and Chip's suggestions, we tried a different configuration: perl Configure.pl --without-gmp --cc=gcc --ccflags=-DAN where 'AN' was intended to be a harmless option for --ccflags. This time, 'make' got a few lines farther; see attachment. Compiling with: xx.c gcc -I

[perl #40814] [PATCH] Assorted Solaris fixes

# New Ticket Created by Steve Peters # Please include the string: [perl #40814] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40814 > The attached patches get Parrot to compile on Solaris, and fixes one test failure. Stev

[perl #40815] Summary of 'make test' failures on Darwin

# New Ticket Created by James Keenan # Please include the string: [perl #40815] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40815 > perl Configure.pl --without-gmp --cc=gcc --ccflags='-fno-common -pipe -I/usr/local/inc

[perl #40815] Summary of 'make test' failures on Darwin

On Sat Nov 11 10:17:33 2006, [EMAIL PROTECTED] wrote: > perl Configure.pl --without-gmp --cc=gcc --ccflags='-fno-common -pipe > -I/usr/local/include -pipe -fno-common' > > Then chromatic suggested manually editing the Makefile to delete '- > bundle' from the following line. > LD_LOAD_FLAGS =

Re: [perl #40834] [BUG] - PMC methods aren't inherited to PIR subclasses

Am Sonntag, 12. November 2006 16:54 schrieb Patrick R.Michaud: > If a METHOD is defined in a *.pmc file, that METHOD is not > automatically inherited by PIR-based subclasses. This isn't quite true. But some METHODs / vtables / MMDs are implemented in a way that doesn't cope with inheritance. See

[perl #40816] open opcode creates file if it doesn't exist

# New Ticket Created by Jonathan Rockway # Please include the string: [perl #40816] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40816 > Not sure if this is a bug or not, but I noticed that the open opcode creates its arg

Re: [perl #40814] [PATCH] Assorted Solaris fixes

On Saturday 11 November 2006 10:02, Steve Peters wrote: > The attached patches get Parrot to compile on Solaris, and fixes one > test failure. Thanks, applied as 15445. -- c

[perl #40818] [PATCH] Silence warning in t/library/pcre.t

# New Ticket Created by Steve Peters # Please include the string: [perl #40818] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40818 > When running test t/library/pcre.t, it spits out the following warning... Argument "[

Re: [perl #40279] [CAGE] C coding standards coda.

Sure. On Nov 12, 2006, at 7:56 AM, Paul Cochrane via RT wrote: On Tue Sep 05 13:13:05 2006, coke wrote: From the recently updated pdd07: C source files, and files largely consisting of C (e.g. yacc, lex, PMC, and opcode source files), must end with this block: /* * Local variables: *

Assertion failed: (PTR2UINTVAL(mmd_table[i].func_ptr) & 3) == 0

This is about revision 15444. Parrot seems to smoke not bad on my Windows XP / Visual C++ 8 box. 6734 test cases: 6687 ok, 47 failed, 268 todo, 585 skipped and 0 unexpectedly succeeded I thought I'd remove C<-DNDEBUG> from the compiler flags for smoking Parrot, but this causes t

Re: [perl #40823] Win32 vs. the world - length for sprintf('%e') - what's right?

On Sat, Nov 11, 2006 at 04:34:55PM -0800, Chip Salzenberg wrote: > Please somebody figure out what Perl does on Win32 for testing sprintf, > because the Perl sprintf test suite seems to think that the right value > for sprintf('%e',1) is "1e+00", but Win32 seems to return "1e+000" (note > the extr

Re: Coding Standard Questions

On Tue, Oct 17, 2006 at 02:33:55PM -0600, Kevin Tew wrote: > While exploring Parrot internals I started cleaning up some code. > I'll post patches to the list, but here are some things that are not > defined by the coding standards, but of which I'm a fan. > So the question is are they acceptable

Re: Coding Standard Questions

On Tue, Oct 17, 2006 at 04:01:36PM -0500, Andy Lester wrote: > if ( foo ) { > bar(); > } > else { > bat(); > } Well, that's not correct either: Our coding standards already say to omit needless braces, and don't space inside the parens of if/while/etc. Thus, this is the preferred format:

Re: Coding Standard Questions

On Nov 12, 2006, at 6:46 PM, Chip Salzenberg wrote: char *p, q; /* not misleading, at least */ Here we see clearly expressed that both *p and q are of type char. I think it IS misleading. I would do this as: char *p; char q; As MJD says, it's better to look than to think.

Re: Coding Standard Questions

On Tue, Oct 17, 2006 at 11:41:06PM +0200, Leopold Toetsch wrote: > Anything that has the smallest smell of ever needing an extra statement after > if or else shall use braces in the first place (IMHO). Predicting the future is something humans are bad at, sadly. -- Chip Salzenberg <[EMAIL PROTEC