Re: [perl #41569] t/distro/file_metadata.t fails on win32

> But if we convert what MANIFEST provides (i.e. Unix directory > separators) into whatever the current platform needs (i.e. what > canonpath() does) then it should agree with whatever svn spits out. > Or am I missing something? No, that's exactly what I think needs to be done. In the patch cano

Removing #pragma

I'm very uncomfortable with removing #pragma once from our header files. It is perfectly valid C89 code, and I think bowing to a broken compiler is unhealthy precedent. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: [perl #41569] t/distro/file_metadata.t fails on win32

Paul Cochrane wrote: >> > But if we convert what MANIFEST provides (i.e. Unix directory >> > separators) into whatever the current platform needs (i.e. what >> > canonpath() does) then it should agree with whatever svn spits out. >> > Or am I missing something? >> >> No, that's exactly what I think

Re: Removing #pragma

On Jun 12, 2007, at 9:38 AM, jerry gay wrote: now, to the matter at hand: i agree with andy. we shouldn't revert this because one broken compiler doesn't like it. however, we should make it clear in the documentation that the particular version of that compiler has trouble compiling valid C89,

Re: Removing #pragma

Andy, I received this email in its own thread so perhaps I missed where it was tied to the problems with Win32/MinGW that we have discussed in #parrot. For those following along at home, MinGW's gcc version 3.4.2 has deprecated #pragma once and will actually cause the compiler to blow up when com

Re: Removing #pragma

On 6/12/07, Andy Lester <[EMAIL PROTECTED]> wrote: I'm very uncomfortable with removing #pragma once from our header files. It is perfectly valid C89 code, and I think bowing to a broken compiler is unhealthy precedent. to add some context, in r18884 andy committed a patch (after my suggestio

[svn:perl6-synopsis] r14418 - doc/trunk/design/syn

Author: larry Date: Tue Jun 12 11:33:55 2007 New Revision: 14418 Modified: doc/trunk/design/syn/S02.pod doc/trunk/design/syn/S03.pod Log: Line-initial #{ is no longer a line-end comment, but starts a "block comment", guaranteed to catch at compile time the accidental use of "#{...} foo(

Re: Removing #pragma

jerry gay wrote: On 6/12/07, Andy Lester <[EMAIL PROTECTED]> wrote: I'm very uncomfortable with removing #pragma once from our header files. It is perfectly valid C89 code, and I think bowing to a broken compiler is unhealthy precedent. to add some context, in r18884 andy committed a patch (

[svn:perl6-synopsis] r14419 - doc/trunk/design/syn

Author: larry Date: Tue Jun 12 12:08:30 2007 New Revision: 14419 Modified: doc/trunk/design/syn/S02.pod Log: just a grammaro Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original

Re: Removing #pragma

On Jun 12, 2007, at 1:39 PM, Allison Randal wrote: Do we have any proof that it does speed up compilation with msvc? Littering our code with "optimizations" for odd compilers is also an unhealthy precedent. Darn you and your pragmatism! DO we indeed have proof of a speedup? xoa -- Andy

Re: Removing #pragma

On 6/12/07, Andy Lester <[EMAIL PROTECTED]> wrote: On Jun 12, 2007, at 1:39 PM, Allison Randal wrote: > Do we have any proof that it does speed up compilation with msvc? > Littering our code with "optimizations" for odd compilers is also > an unhealthy precedent. Darn you and your pragmatism!

Bug Day for 0.4.13: Saturday, June 16th

--From http://rakudo.org/parrot/index.cgi?bug_day_2007_06_16-- Bug Day On Saturday, 16 June 2007, please join us on IRC in #parrot (irc.perl.org) to work on closing out as many RT (https://rt.perl.org/rt3/) tickets as possible in the parrot queue. This will help us get ready for the next rele

Re: Removing #pragma

On Tue, 12 Jun 2007 11:39:35 -0700 Allison Randal <[EMAIL PROTECTED]> wrote: > jerry gay wrote: > > On 6/12/07, Andy Lester <[EMAIL PROTECTED]> wrote: > >> > >> I'm very uncomfortable with removing #pragma once from our header > >> files. It is perfectly valid C89 code, and I think bowing to a >

Re: Removing #pragma

On Tue, Jun 12, 2007 at 01:13:44PM -0700, Mark Glines wrote: > On Tue, 12 Jun 2007 11:39:35 -0700 > Allison Randal <[EMAIL PROTECTED]> wrote: > > Do we have any proof that it does speed up compilation with msvc? > > Littering our code with "optimizations" for odd compilers is also an > > unhealt

Re: Removing #pragma

On Jun 12, 2007, at 3:13 PM, Mark Glines wrote: On the other hand, will #pragma once allow us to get rid of all of those ugly header guard macros? If so, I would argue to keep it for maintenance reasons, regardless of any performance benefits. No, not at all, because #pragma once is only a p

Re: [svn:perl6-synopsis] r14418 - doc/trunk/design/syn

[EMAIL PROTECTED] writes: > Log: > Line-initial #{ is no longer a line-end comment, but starts a "block > comment", guaranteed to catch at compile time the accidental use > of "#{...} foo();". (Old behavior would silently not execute > foo().) Oooh, those block comments look nifty --

Fwd: [TODO] Write test for Parrot::Configure::runstep()

Forwarded to list pending return to life of rt.perl.org: Parrot::Configure::runstep() is the only subroutine in Parrot::Configure() that is still not covered via the tests in t/ configure/ or t/postconfigure/. No test has yet been written in part because this is a subroutine which is not

Fwd: [TODO] Parrot::Configure::Step: Test remaining untested subroutines

Forwarded to list pending return to life of rt.perl.org: According to its documentation, the purpose of Parrot::Configure::Step is to hold "... utility functions for [configuration] steps to use." This package, in relation to others in the Parrot::Configure::* tree, has a relatively lar

Re: Parrot at YAPC::NA::2007 in Houston

On Jun 11, 2007, at 10:03 PM, James E Keenan wrote: See below for the schedule of Perl 6 and Parrot-related talks at YAPC in 2 weeks. Will there be a time for a Parrot BOF there? There's a hackathon scheduled, I think. I'm still trying to figure out if I'll be able to stay past wednesday

Re: Parrot at YAPC::NA::2007 in Houston

Will Coleda wrote: On Jun 11, 2007, at 10:03 PM, James E Keenan wrote: See below for the schedule of Perl 6 and Parrot-related talks at YAPC in 2 weeks. Will there be a time for a Parrot BOF there? Perhaps at 17:00 Mon (after the conclusion of a whole afternoon of Parrot talks) or a 12:

[GC] Pin Key PMCs During Method Lookup

In src/objects.c, around line 82, the function find_vtable_meth_ns() creates a Key PMC to perform a lookup: PMC * const key = VTABLE_nextkey_keyed(interp, key_new(interp), ns, ITERATE_FROM_START); If a GC run happens in the rest of this function, it could collect the ne

Re: Generalizing ?? !!

On Mon, Jun 11, 2007 at 01:43:40AM -, NeonGraal wrote: > Surely if you defined !! to return "undef but true" and both operators > to be left associative then it all works. > > 1==0 ?? "True" !! "False" -> (undef) !! "False" which seems right to > me. > > 1==1 !! "False" ?? "True" -> (undef

Re: Parrot at YAPC::NA::2007 in Houston

On Jun 12, 2007, at 9:24 PM, Will Coleda wrote: There's a hackathon scheduled, I think. I'm still trying to figure out if I'll be able to stay past wednesday. :| I definitely look forward to seeing folks M-W, though, I'm about 50/50 on whether I'm going to YAPC or not, but if I do it's g

[perl #43190] [TODO] Write test for Parrot::Configure::runstep()

# New Ticket Created by James Keenan # Please include the string: [perl #43190] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=43190 > Parrot::Configure::runstep() is the only subroutine in Parrot::Configure() that is sti

[perl #43192] [TODO] Parrot::Configure::Step: Test remaining untested subroutines

# New Ticket Created by James Keenan # Please include the string: [perl #43192] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=43192 > According to its documentation, the purpose of Parrot::Configure::Step is to hold "...

Last bits of PDD 15 implementation

I'm about half-way through a quick classification of the failing PDD 15 tests (in t/pdd15oo). A number of the failures are quick things anyone could pick off, so I'll share the list: We're only failing 157 out of 764 tests, so we'r

Re: Removing #pragma

On Tue, Jun 12, 2007 at 01:13:44PM -0700, Mark Glines wrote: I just came up with an artificial benchmark and found that gcc-3.4.6 runs slightly faster with #pragma once protecting a header that includes lots of other headers. (a chain of 200 other headers, in my test.) By "slightly", I mean "co