-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Assuming "num" uses the underlying floating point semantic (which may
turn 0/0 into NaN without raising exception), what should the default
"Num" do on these forms?
0/0
0*Inf
Inf/Inf
Inf-Inf
0**0
Inf**0
Audrey Tang wrote:
> Assuming "num" uses the underlying floating point semantic (which may
> turn 0/0 into NaN without raising exception), what should the default
> "Num" do on these forms?
>
> 0/0
> 0*Inf
> Inf/Inf
> Inf-Inf
> 0**0
> Inf**0
>
While cleaning up tests for release:
"".split(':')=>
()# Perl 5
("",) # pugs
Which is correct? It doesn's seem to be specced yet.
--
Gaal Yahas <[EMAIL PROTECTED]>
http://gaal.livejournal.com/
On Tue, Jan 17, 2006 at 06:06:50AM +1100, Adam Kennedy wrote:
>
> At the moment all our output is structured XML files, so at some point I
> need to write an XSL to translate it back down into something CPAN
> Testers can deal with, and I can add whatever you want me to at that time.
>
> Do you
On 2006-01-17 12:24 PM, "Gaal Yahas" <[EMAIL PROTECTED]> wrote:
> While cleaning up tests for release:
>
> "".split(':')=>
>
>()# Perl 5
>("",) # pugs
>
> Which is correct? It doesn's seem to be specced yet.
I would prefer the current pugs behavior;
Physicist here. One who believes -2**2 is negative.
At 23:26 +0800 1/17/06, Audrey Tang wrote:
>Several options:
>- - Use whatever the underlying "num" semantics available
That's likely to be in hardware. It might even be hard to detect without
looking at the NaN returned and that would be a was
Doug McNutt wrote:
>> - - Specify them to return some definite value.
> Only on a machine that doesn't do it in hardware or in some special perl
> function that's unlikely.
This question arises as different platform answer things differently for
the native calculation of eg. 1**Inf.
>
>> At this
On 1/17/06, Audrey Tang <[EMAIL PROTECTED]> wrote:
> But putter on #perl6 reports "1" on his amd64. I'd be happy we spec it
> has to have to return 1 always for boxed Num types, even though it means
> additional cycles for boxed numeric types.
Isn't the point of boxing to provide a hardware-indep
I'm still seeing a link failure with r11221.
A confusing bit: I stopped the stripping of libparrot.dll, and nm
seems to see the symbols that the linker's complaining about:
[...]
Compiling with:
xx.c
gcc -I./include -pipe -I/usr/local/include -g -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wi
On 1/17/06, Audrey Tang <[EMAIL PROTECTED]> wrote:
> I personally like having 0/0 be NaN and 1/0 be Inf (as in JavaScript),
> but all of Python/Perl/Ruby/Scheme/OCaml throws exceptions for them...
I believe we've been through this before. We go with a standard,
probably IEEE, horridly mathematica
On Tue, Jan 17, 2006 at 08:28:37AM -0600, Greg Bacon wrote:
: I'm still seeing a link failure with r11221.
:
: A confusing bit: I stopped the stripping of libparrot.dll, and nm
: seems to see the symbols that the linker's complaining about:
:
: [...]
: Compiling with:
: xx.c
: gcc -I./include -pi
It looks like the script 'tools/dev/genrpt.pl' does basically the same as
'parrotbug'.
In order to decrease the level of confusion I propose to remove
genrpt.pl and the associated make targets 'ok', 'okfile', 'nok', 'nokfile'.
CU, Bernhard
> [jonathan - Sa 14. Jan 2006, 09:57:37]:
> > I propose to rename 'src/classes' to 'src/pmc' as IMHO it makes
> > more sene. 't/pmc' is already named 'pmc'.
> >
> Yes, and for consistency please also rename dynclasses to dynpmc and the
> t/dynclass to t/dynpmc.
The first step, renaming 'src/dync
Bob~
On 1/15/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> On Jan 14, 2006, at 21:28, Bob Rogers wrote:
>
> >I had thought this field was being used, but it turns out to be
> > irrelevant. I offer this patch so that no one else is fooled (and
> > because I had to test it anyway to prove
Allison et al.,
I was looking at languages/punie/lib/punie.g in the current SVN head
and got confused. I see:
rule gprint { (print) \s* }
and
rule expr{ | }
Doesn't that imply that "print print print print 1;" is a valid Punie
program? Is that intentional? It seems to me that
On Tuesday 17 January 2006 16:50, Chris Dolan wrote:
> Allison et al.,
>
> I was looking at languages/punie/lib/punie.g in the current SVN head
> and got confused. I see:
>rule gprint { (print) \s* }
> and
>rule expr{ | }
>
> Doesn't that imply that "print print print print 1;" is
Luke Palmer wrote:
> I believe we've been through this before. We go with a standard,
> probably IEEE, horridly mathematically unappealing though it may be.
> It will be easier to implement and it will be more predictable, both
> because most other language follow standards, too.
"The good thing
Audrey Tang wrote:
> That seems to follow from the standard (ruby, ocaml, mzscheme currently
> does that), but some may also argue for NaN bothways (ghc, js) or an
> exception bothways (perl5, python).
Er, wait, ghc also raises an exception for (div 0 0), because it
distinguishes integer (div) wit
On Tuesday 17 January 2006 15:01, Andrew Rodland wrote:
> "print print print print 1;" is certainly a valid Perl 5 program; it
> prints a 1 followed by 3 other things (which are defined to be true, and
> which happen to also be the number 1).
Nit: print doesn't *always* return a true value. It'
OK, I'll make sure there's some level of tagging about that in the reports.
Adam K
Barbie wrote:
On Tue, Jan 17, 2006 at 06:06:50AM +1100, Adam Kennedy wrote:
At the moment all our output is structured XML files, so at some point I
need to write an XSL to translate it back down into something
On Jan 17, 2006, at 18:01, Andrew Rodland wrote:
Doesn't that imply that "print print print print 1;" is a valid Punie
program? Is that intentional? It seems to me that the gprint rule
should instead contain "cexpr":
rule gprint { (print) \s* }
"print print print print 1;" is certainly
From: Matt Fowles <[EMAIL PROTECTED]>
Date: Tue, 17 Jan 2006 16:29:55 -0500
Bob~
On 1/15/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> On Jan 14, 2006, at 21:28, Bob Rogers wrote:
>
> >I had thought this field was being used, but it turns out to be
> > irreleva
At 9:50 AM +0800 1/18/06, Audrey Tang wrote:
However, I think one of P6's idea is that the user should not have
to care between 0 and 0.0's behaviours, so maybe it makes sense to
do the same thing (be it NaN or exception) both ways.
I'm not sure that IEEE 754/854 still applies if we want to merg
# New Ticket Created by jerry gay
# Please include the string: [perl #38262]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38262 >
perl modules necessary for parrot configuration, development, and
testing have been either
# New Ticket Created by Bob Rogers
# Please include the string: [perl #38263]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38263 >
From: Matt Fowles <[EMAIL PROTECTED]>
Date: Tue, 17 Jan 2006 16:29:55 -0500
Bob
# New Ticket Created by Bob Rogers
# Please include the string: [perl #38264]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38264 >
The attached code compiles to byte code OK in r11235, until you
comment out the push_e
# New Ticket Created by Matt Fowles
# Please include the string: [perl #38261]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38261 >
Bob~
On 1/15/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> On Jan 14, 2006, at 21:
# New Ticket Created by jerry gay
# Please include the string: [perl #38260]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38260 >
attached is my lib/Parrot/Config.pm file generated from r11223, on
windows using msvc. ins
On Tue, Jan 17, 2006 at 12:35:57PM -0500, Mark Reed wrote:
> On 2006-01-17 12:24 PM, "Gaal Yahas" <[EMAIL PROTECTED]> wrote:
>
> > While cleaning up tests for release:
> >
> > "".split(':')=>
> >
> >()# Perl 5
> >("",) # pugs
> >
> > Which is correct?
29 matches
Mail list logo
