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
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
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 needs to be
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,
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
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
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 #{...}
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
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
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
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!
DO we
--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
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
broken compiler
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
unhealthy
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
[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 -- and are
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
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
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
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
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
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 but true) ?? True
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
# New Ticket Created by James Keenan
# Please include the string: [perl #43190]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43190
Parrot::Configure::runstep() is the only subroutine in
Parrot::Configure() that
# New Ticket Created by James Keenan
# Please include the string: [perl #43192]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43192
According to its documentation, the purpose of
Parrot::Configure::Step is to hold
25 matches
Mail list logo
