| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
set all other modules in dist/bignum to 0.36 too, the CPAN dist has
them all at the same version
|
| |
|
|
|
|
| |
Bump $VERSION.
|
|
|
|
|
| |
Also document that this means that ranges and bigint.pm do not mix perfectly.
Bump version numbers.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
These were all uncovered by the new Pod::Checker, not yet in core.
Fixing these will speed up debugging the new Checker.
|
|
|
|
|
|
|
|
| |
5.6 does not like it when a sub is declared with a prototype after a
reference to it has been taken.
5.6 does not think lowercase module names should be exempt from
reserved word warnings before ->.
|
|
|
|
|
|
|
|
|
|
| |
We use the ;$ prototype for testing global overrides under 5.8, as it
had no _ prototype. But back then (before 5.14, in fact) ;$ did not
give a function unary precedence.
Comparing against 5.009004 in bigint scope is the same as comparing
against 5, resulting in incorrect version checks and skips being
skipped.
|
|
|
|
|
| |
Older versions of Math::BigInt required the input to from_oct to
begin with a 0.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As mentioned in <https://rt.cpan.org/Ticket/Display.html?id=79915>,
bigint.pm does not use any prototype when globally overriding hex.
This means that map { hex } ... will stop working in completely unre-
lated code if bigint happens to be loaded. (Explicit $_ will con-
tinue to work.)
I thought it would be a simple matter of adding the right prototype
depending on perl version (and inferring $_), but the basic tests
I added failed for other reasons after I fixed the prototype and
$_ handling.
It turns out this whole thing is a mess, so I have basically reimple-
mented these two overrides.
What bigint, bignum and bigrat were doing was this: In import,
*CORE::GLOBAL::hex and ::oct are assigned functions that create
Math::BigInt objects if the pragma is in effect. If import is passed
'hex' or 'oct', then the function assigned does not check the pragma
hints, but simply creates Math::BigInt objects regardless.
This means that ‘use bigrat’ stops hex() and oct() from creating
objects in ‘use bigint’ scopes, and vice versa. In fact, whichever
pragma is loaded last wins. Any scopes elsewhere in the program that
use the same pragma will have special hex() and oct() behaviour. But
the other two lowercase big* pragmata will be disabled with regard to
hex and oct.
Having ‘use bigint 'hex'’ override hex globally makes no sense to me.
I have no qualms about changing it, as it was already broken. Any
subsequent ‘use bigint;’ would turn off the global override. So now
it exports hex or oct to the calling package, just like a normal mod-
ule. You can now also call bigint::hex.
Also, in writing tests I found that oct("20") gives me 20. Apparently
this was never tested properly.
I also found notes about ‘5.9.4 or later’ when the code checked
$] > 5.009004. (Actually, in one place the code checked > 5.009003,
so I made it match, as we use the _ prototype now, which was intro-
duced in 5.9.5.) One was in the docs, so I changed it to 5.10.0,
since it is not helpful to mention dev versions. The docs were also
wrong to imply that ‘no bigint’ would countermand ‘use bigint 'hex'’.
|
| |
|
|
|
|
|
| |
Some copy/paste and insertion errors in bignum 0.19 left the docs in
a confusing state.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
The POD has a typo in the following three pragmas:
bigint
bignum
bigrat
The typo is similar for each pragma: CAVAETS should be changed to CAVEATS.
|
|
|
|
|
|
| |
Some whitespace is being interpreted as "not a blank line" causing it (and
possibly other parsers) to assume that subsequent text is part of the preceding
=head or =item
|
| |
|
|
|
|
|
|
|
|
|
| |
# New Ticket Created by (Peter J. Acklam)
# Please include the string: [perl #81888]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=81888 >
Signed-off-by: Abigail <abigail@abigail.be>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This was only needed for testing in the core, when the core's tests all ran in
the top level t/ directory. Without this getting in the way, we don't need
t/TEST and t/harness to run the tests with absolute paths in @INC. Testing in
the CPAN distribution is unaffected.
|
| |
|
|
|