Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Mouse CPAN distribution.

Report information
The Basics
Id: 55048
Status: resolved
Priority: 0/
Queue: Mouse
People
Owner: Nobody in particular
Requestors: avar [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Important
Broken in: 0.50_03
Fixed in: (no value)

History Show all quoted text
  Sat Feb 27 16:30:30 2010 avar [...] cpan.org - Ticket created
Subject: [PATCH] Mouse's Int type doesn't handle >2^32 Ints on 32bit systems
I've fixed this in Mouse's Git in the more_than_32_bit_Int_on_32_bit_systems branch. Merge it if you think it looks good, it passes all the tests that previously passed plus new ones that I added.
  Sun Feb 28 01:30:20 2010 gfuji [...] cpan.org - Correspondence added
Hi, AEvar. Thanks! I have merged your branch into master, renaming the test file name because of its portability. -- Goro Fuji (gfx) GFUJI at CPAN.org
  Sun Feb 28 01:30:22 2010 The RT System itself - Status changed from 'new' to 'open'
  Wed Mar 03 03:15:09 2010 gfuji [...] cpan.org - Correspondence added
Hi, AEvar. I'm thinking about your change. 10e100, for example, is exactly an integer, but how about 10e100+0.1? We cannot distinguish 10e100 from 10e100+0.1. What do you think of it? If there is no specific reason, I'd like to revert the change. -- Goro Fuji (gfx) GFUJI at CPAN.org
  Wed Mar 03 03:40:15 2010 avar [...] cpan.org - Correspondence added
On Wed Mar 03 03:15:09 2010, GFUJI wrote: Show quoted text
> Hi, AEvar. > > I'm thinking about your change. 10e100, for example, > is exactly an integer, but how about 10e100+0.1? > We cannot distinguish 10e100 from 10e100+0.1. > > What do you think of it? If there is no specific reason, > I'd like to revert the change.
I just picked 10e100 as a really large number at the boundary of the numbers perl can handle on 32bit systems. But yes, it's indistinguishable from 10e100+0.1 but there's nothing we can do about that since that's all perl's own IV type can hold: $ perl -E 'say "too bad" if sprintf("%f", 10e100) eq sprintf("%f", 10e100+0.1)' too bad So revert what change exactly? And what would you revert it to?
  Wed Mar 03 06:28:33 2010 gfuji [...] cpan.org - Correspondence added
I'd like to revert: 1f1ccccdb5564d10867ffb11df17a5155999a62a (by AEVar) 9ab5eba8f47dea20ad51f8dccb18c574399748c9 (by AEVar) 1adf864effeeff1cfdbe79f6014a483860e2ec3f (by gfx) And I should fix Changes. -- Goro Fuji (gfx) GFUJI at CPAN.org
  Wed Mar 03 06:44:11 2010 avar [...] cpan.org - Correspondence added
On Wed Mar 03 06:28:33 2010, GFUJI wrote: Show quoted text
> I'd like to revert: > 1f1ccccdb5564d10867ffb11df17a5155999a62a (by AEVar) > 9ab5eba8f47dea20ad51f8dccb18c574399748c9 (by AEVar) > 1adf864effeeff1cfdbe79f6014a483860e2ec3f (by gfx) > > And I should fix Changes.
That's everything I commited, so you'd like to revert: else if(SvNOKp(sv)) { NV const nv = SvNVX(sv); NV mod = Perl_fmod( nv, 1 ); return mod == 0; } Back to this: else if(SvNOKp(sv)){ NV const nv = SvNVX(sv); return nv > 0 ? (nv == (NV)(UV)nv) : (nv == (NV)(IV)nv); } ? That would again break Mouse on 32bit systems and why? Because Perl_fmod() can't tell the difference between 10e100+0.1 and 10e100? Well neither can the rest of perl.
  Sun Mar 07 03:29:36 2010 gfuji [...] cpan.org - Correspondence added
TC should refuse 10e100+0.1, as well as 10+0.1, but most systems cannot distinguish 10e100 from 10e100+0.1. Currently, the only one way to refuse 10e100+0.1 is to refuse NV which is lager than UV_MAX (or smaller than IV_MAX), although 10e100+0.1 is actually the same as 10e100. If one want otherwise, TMTOWTDI. That is, one can define a subtype of Num which may be sub { POSIX::fmod($_, 1) == 0 }, or can use Math::BigInt with coercion. The core types must be as safe as possible, I think. -- Goro Fuji (gfx) GFUJI at CPAN.org
  Sun Mar 14 22:40:48 2010 gfuji [...] cpan.org - Correspondence added
Hi, AEvar. Please try 0.50_09. It might not perfect, but is better than previous versions, I believe. Under the new rule, Int is exactly what is matched to /^[+-][0-9]+$/. So 2**46 is always groked as Int, and 2**46+0.5 is not. And, as you can see in perl -E 'say 10e100' (=> "1e+101"), it is not groked as Int. What do you think of the new rule? If it meets your need, I'll released 0.51. -- Goro Fuji (gfx) GFUJI at CPAN.org
  Sun Mar 14 23:08:43 2010 avar [...] cpan.org - Correspondence added
On Sun Mar 14 22:40:48 2010, GFUJI wrote: Show quoted text
> Hi, AEvar. > > Please try 0.50_09. It might not perfect, but is better than previous > versions, I believe. > > Under the new rule, Int is exactly what is matched to /^[+-][0-9]+$/. > So 2**46 is always groked as Int, and 2**46+0.5 is not. And, as you can > see in perl -E 'say 10e100' (=> "1e+101"), it is not groked as Int. > > What do you think of the new rule? If it meets your need, I'll released > 0.51.
Looks sane, and as long as the tests I added still pass I'm all for it.
  Mon Mar 15 02:42:00 2010 gfuji [...] cpan.org - Correspondence added
Show quoted text
> Looks sane, and as long as the tests I added still pass I'm all for it.
Good. I have released 0.51 just. Thanks! -- Goro Fuji (gfx) GFUJI at CPAN.org
  Mon Mar 15 02:42:01 2010 gfuji [...] cpan.org - Status changed from 'open' to 'resolved'