On Aug 4, 2007, at 5:28 AM, Paul Cochrane wrote:
On 03/08/07, via RT Joshua Isom <[EMAIL PROTECTED]>
wrote:
# New Ticket Created by Joshua Isom
# Please include the string: [perl #44391]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Disp
At 12:58 -0700 8/4/07, chromatic wrote:
>On Wednesday 01 August 2007 13:50:45 Joshua Hoblitt wrote:
> > #include
>> #include
>>
>> int main ()
>> {
>> printf("0.0 : %f\n", 0.0);
>> printf("-0.0 : %f\n", -0.0);
>> printf("0.0 == -0.0 : %d\n", 0.0 == -0.0);
> > }
I'm afraid that would
On Sat, Aug 04, 2007 at 12:56:06PM -0700, Larry Wall wrote:
> for '❶' .. '❿' { .say }
>
> But it's not clear what to do if you try to increment ❿ though.
> Probably just return a failure.
Assuming that '❶' .. '❿' is a range similar to '0'..'9', then
consistency with the other ranges would see
On Sat, Aug 04, 2007 at 12:56:06PM -0700, Larry Wall wrote:
: multi token numrange:<0x> (--> StrHex){ '0x' <[0..9a..fA..F]>+ }
Though sanity would probably force us to use numerics internally anyway
as the canonical comparison form, or we'd have trouble getting
'0x00' .. '0x0Ff'
to
On Wednesday 01 August 2007 13:50:45 Joshua Hoblitt wrote:
> I'm not sure if 0.0 == -0.0 is true on all platforms. It should be for
> IEEE754 compliance but in the real world...
>
> It might be nice to throw in a few tests to see if the example code
> below would have the same results on all plat
On Thursday 02 August 2007 16:39:07 Joshua Hoblitt wrote:
> Does anyone object to this patch?
>
> Index: exceptions.c
> ===
> --- exceptions.c(revision 20408)
> +++ exceptions.c(working copy)
> @@ -771,7 +771,7 @@
> {
On Sat, Aug 04, 2007 at 12:55:58PM -0500, Patrick R. Michaud wrote:
: On Thu, Aug 02, 2007 at 04:19:18PM -0700, [EMAIL PROTECTED] wrote:
: > Increment of a C (in a suitable container) works similarly to
: > Perl 5, but is generalized slightly. First, the string is examined
: > to see if it coul
On Friday 03 August 2007 05:15:33 Bram Geron wrote:
> At Parrot exit, we force-destroy all PObjs. It can happen that a context
> is destroyed after its sub is destroyed. Usually that's not a problem,
> but if you run with -D80 (show when contexts are destroyed, and print
> out the name of the sub)
On Thu, Aug 02, 2007 at 04:19:18PM -0700, [EMAIL PROTECTED] wrote:
> Increment of a C (in a suitable container) works similarly to
> Perl 5, but is generalized slightly. First, the string is examined
> to see if it could be the string representation of a number in
> any common representation,
Author: larry
Date: Sat Aug 4 09:06:15 2007
New Revision: 14434
Modified:
doc/trunk/design/syn/S06.pod
Log:
relaxed restriction on placeholders as suggested by Aaron Crane++
Modified: doc/trunk/design/syn/S06.pod
==
chromatic wrote:
Ahh, this patch fixes things for me. My gcc is also available as cc (and I'm
using ccache), so checking that it matches the literal string 'gcc' doesn't
work. Explicitly checking that it has a GCC version number works better.
Unfortunately, it did not improve things for
[EMAIL PROTECTED] writes:
> +Placeholder names may only be lowercase, not because we're mean, but
> +because it helps us catch references to obsolete Perl 5 variables such as
> $^O.
That seems unnecessarily restrictive. How about "may not consist
solely of uppercase letters" instead? That would
> does nothing for other compilers. Obviously, all the compiles fail,
> since no test.c file is generated. I don't know, for example, if 'icc'
> handles attributes, or if it might in the future.
icc handles all gcc attributes. I'd started digging into why the
attributes were being ignored by ic
On 03/08/07, via RT Joshua Isom <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Joshua Isom
> # Please include the string: [perl #44391]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=44391 >
>
>
> After a fair amount
On 8/3/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 03, 2007 at 03:37:39PM -0700, Bob Rogers wrote:
> >A naive PIR implementation of this loop is included as the second
> > attachment. It fails miserably, because PIR can't distinguish between
> > the different scopes for "$i
On Friday 03 August 2007 21:35:36 chromatic wrote:
> r20454 doesn't help. Of course, it looks like that's papering over the
> fact that the noreturn attribute expands (for me on x86 Linux, that is) to:
>
> #define PARROT_DOES_NOT_RETURN /[EMAIL PROTECTED]@*/
> __attribute__noreturn__
16 matches
Mail list logo
