[perl #59642] Return the empty list on non-positive LIMIT
# New Ticket Created by "Chris Davaz" # Please include the string: [perl #59642] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59642 > Here is a small patch to make split return the empty list on non-positive limit arguments instead of returning the string split entirely. Moritz, I think it was you who suggested that negative arguments be 'rejected by the signature' but I am not sure how to do this in PIR. Index: src/builtins/any-str.pir === --- src/builtins/any-str.pir (revision 31687) +++ src/builtins/any-str.pir (working copy) @@ -411,8 +411,7 @@ # per Perl 5's negative LIMIT behavior unless has_count goto positive_count -unless count < 1 goto positive_count -has_count = 0 +if count < 1 goto done positive_count: match = regex($S0)
Practical Considerations
My company sells an application that links a bugtracking tool with an SCM tool so that, for example, the files changed for each bug are recorded in the bugtracking tool. It is currently written in (mostly) non-object-oriented perl5. We are re-architecting the application so that it can work with different bugtracking tools and SCM tools, and do things like sync data from specific fields between a help desk tool and the bugtracking tool. This would be a good time for us to transition to perl6. As far as I can tell from the various faqs and wikis, the existing functionality in rakudo should support most of our needs for the initial release. I may need to assist with the porting of some database access and other modules from CPAN to C6PAN in the longer term. However, I am concerned about deployment of a perl6 based product to customers. Perl5 can be reasonably specified as a prerequisite for loading our application, since it is generally available (and shipped with some of the products we integrate). That is not the case with Perl6. Is it practical now to deploy a Perl6/Parrot runtime with a (possibly precompiled) version of our product? Will it be practical any time soon? I can probably get away with occasionally requiring Linux and Solaris users to rebuild Parrot to fit their local configuration, but Windows is another matter. (Shipping a known version of the runtime with our product will also allow us to tune our application to a known set of available perl6 functions.) The mechanism for generating the packages I ship to my customers does not need to be pretty, it just needs to exist. If there are instructions already online about how to generate such packages (now or in the near future), I would appreciate a pointer to them. Thanks -- Elyse Grasso CTO ReleaseTEAM Inc. http://www.releaseteam.com phone 720-887-0489 fax 720-977-8010 cell 303-356-2717
Parrot Bug Summary
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Oct 6 13:00:01 2008 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with most open tickets
---
Numbers
Ticket Counts: 45 new + 628 open = 673
Created this week: 15
Closed this week: 4
---
New Issues
New issues that have not been responded to yet
1 - 2 weeks old
59340 t/stm/runtime_4.pir segfaults on FreeBSD 7 (i386)
2 - 3 weeks old
58990 [TODO] Design new spec coverage mechanism
58988 [RFC] Parrot_get_runtime_prefix function
58980 [TODO][IMCC] .return in a .begin/end_return will be replaced by
.set_return
58978 [TODO][IMCC] replace .result by .get_result
58976 [TODO][IMCC] .arg will be replaced by .set_arg
58974 [TODO][IMCC] replace .return in tailcall context by .tailcall
58946 [META] October 2008 release
58932 [DEPRECATED] P6object .new_class('Foo::Bar') will create ['Foo';'Bar']
3 - 4 weeks old
58852 [PATCH] enhance tools/install/smoke.pl
58740 [CAGE] t/configure/*.t and t/steps/*.t: Cleanup test setup/teardown code
4 - 5 weeks old
58672 [TODO] implement method lookup iterators
58670 Parrot_print_backtrace() depends on __USE_GNU
58668 src/exceptions.c exposes brokenness in make cover
58590 [PATCH] dotnet make
58488 crashing parrot when calling create_lexinfo
5 - 6 weeks old
6 - 7 weeks old
58250 [TODO] Generate callgrind output
58188 [TODO] Parrot_find_encoding_converter
58108 [BUILD] languages/Makefile 'test' target has too many deps
58070 [RFC] Disallow .local declarations in long-style call statement
7 - 8 weeks old
58050 Segfault in "make testr" for t/compilers/imcc/syn/hll.t:2
8 - 9 weeks old
57680 [CAGE] Problems in find_write_record
57678 [CAGE] Poor Man's Deadlock Detection
57676 [CAGE] Check for shared status of STM handle
57638 [IMCC] old-style PASM registers no longer supported.
9 - 10 weeks old
57432 [DEPRECATED] [PDD19] .HLL_map with comma
57426 [TODO] [PDD19] Implement new .HLL directive
10 - 11 weeks old
57236 [TODO] pbc_to_exe --install pbc1 [pbc2...]
11 - 12 weeks old
57120 [BUG] examples/library/ncurses_life.pir broken
57088 Tcl's [lsort] failure (aka inferior runloop problem)
56972 Error in link
12 - 13 weeks old
56782 [TODO] question in getNameForKey in Getopt::Obj
13 - 14 weeks old
56634 [RFC] future direction for config
56622 [BUG?] 'isa' opcode returns inconsistent results
14 - 15 weeks old
56458 Failure to promote RetContinuation objects
15 - 16 weeks old
16 - 17 weeks old
17 - 18 weeks old
18 - 19 weeks old
19 - 20 weeks old
20 - 21 weeks old
54236 [TODO] Allow Parrot Hashes to have PMC keys
---
Overview of Open Issues
Platform Severity Tag Lang
aix 0abandoned 05005threads 0 Amber 0
All 1fatal 1bounce0 BASIC 0
bsdos 0High 0Bug 104 bc 0
cygwin2low 0compiler 0 befunge 0
cygwin_nt 0medium1configure 3 bf 0
darwin8none 1core 2 cola0
dec_osf 0Normal1dailybuild0 forth 0
dgux 0unknown 0docs 3 jako0
dos 0Wishlist 3duplicate 0 Lisp0
dynixptx 0 install 2 lolcode 0
freebsd 5 library 0 m4 0
generic 0 notabug 0 ook 0
gnu 0 notok 0 perl6 2
HPUX 2 ok0 plot0
irix 0 Patch33 punie 0
irix640 regex 2 pynie 0
Linux 1 sendToCPAN0 python 0
lynxos0 Todo300 ruby0
mac 0 unknown 0 scheme 0
machten 0 utilities 0 tcl 1
macos 0 wontfix 0 urm 0
MacOS X 8Zcode 0
mswin32 2
netbsd1
next 0
openbsd 2
os2 0
os390 0
other 0
powerux 0
qnx 0
riscos0
sco 0
Solaris 7
sunos 1
svr4 0
svr5 0
sysv 0
unicos0
unicosmk 0
unix 0
unknown 0
uts 0
vms 0
VOS 0
Win32 9
-
Re: Practical Considerations
On Mon, Oct 6, 2008 at 5:49 AM, Elyse M. Grasso <[EMAIL PROTECTED]> wrote: > My company sells an application that links a bugtracking tool with an SCM tool > so that, for example, the files changed for each bug are recorded in the > bugtracking tool. It is currently written in (mostly) non-object-oriented > perl5. > > We are re-architecting the application so that it can work with different > bugtracking tools and SCM tools, and do things like sync data from specific > fields between a help desk tool and the bugtracking tool. This would be a good > time for us to transition to perl6. > yes, it seems perfectly reasonable to consider language choices when re-designing your product's architecture. certainly, the perl 6 specification makes it an attractive choice. > As far as I can tell from the various faqs and wikis, the existing > functionality in rakudo should support most of our needs for the initial > release. I may need to assist with the porting of some database access and > other modules from CPAN to C6PAN in the longer term. > the core functionality of rakudo may support what you need, but at this point i have some concerns with chosing rakudo as the runtime for a client-facing production product. mainly, there are un- and under-tested portions of the language implementation, which to me suggests that there are bugs lurking as it hasn't been proven otherwise by passing tests. this isn't to suggest that rakudo is not ready for use, but it is a risk--until we (rakudo project team) have higher test coverage and more passing tests. anybody can help, by adding tests which cover the official perl 6 specification (http://spec.pugscode.org/) to the pugs repository (http://svn.pugscode.org/). anyone who is interested can get commit priviliges to the repository; the procedure is simple, and approval is always granted. feel free to contact this list with a commit bit request. also, there are a number of us with experience writing tests that cover the spec, and we're happy to share our knowledge on the subject. porting modules to perl 6 definitely needs some help. currently there is no c6pan, there is only the pugs repository, where some previously ported modules live. i haven't seen much visible work on c6pan lately, and i'm sure there's no solution nearing production. this means it's best to package any required modules with your product rather than relying on an external resource to provide perl 6 modules at build/configure/install-time. > However, I am concerned about deployment of a perl6 based product to > customers. Perl5 can be reasonably specified as a prerequisite for loading our > application, since it is generally available (and shipped with some of the > products we integrate). That is not the case with Perl6. > this is another case for concern, for sure. parrot's installation code is not extremely robust, but is improving quickly. as of last month's release (0.7.1), parrot is released as a source distribution from the source repository (http://svn.perl.org/parrot/tags/RELEASE_0_7_1), a CPAN module (http://search.cpan.org/~pmic/parrot-0.7.1/), a windows installation package (http://parrotwin32.wiki.sourceforge.net/), a cygwin package (libparrot0 and libparrot-devel), and a debian package (http://packages.qa.debian.org/p/parrot.html). these installation methods are in varying states of maturity, and all are being actively improved. depending on your user system requirements, these methods may work well for you. i suggest investigating further. > Is it practical now to deploy a Perl6/Parrot runtime with a (possibly > precompiled) version of our product? Will it be practical any time soon? I can > probably get away with occasionally requiring Linux and Solaris users to > rebuild Parrot to fit their local configuration, but Windows is another > matter. > (Shipping a known version of the runtime with our product will also allow us > to tune our application to a known set of available perl6 functions.) > possible? yes, definitely. practical? that's hard to say. if parrot and rakudo meet your functionality needs, and the packages are available, then yes. however, i can't call it practical until i've tried it successfully at least three times in simulated user environments. > The mechanism for generating the packages I ship to my customers does not need > to be pretty, it just needs to exist. If there are instructions already online > about how to generate such packages (now or in the near future), I would > appreciate a pointer to them. > parrot has a guide for creating the monthly release package, and there is a guide for debian packaging as well, found at http://svn.perl.org/parrot/trunk/docs/project/). questions here or on other related mailing lists are most welcome. if, during the course of your further examination of parrot and rakudo, you develop concerns on stability, portability, packaging, completeness or other topics, there are multiple ways to address those concerns. firstly, the mai
[perl #59630] [BUG] Complex subtraction fails for subclasses of Complex
I've done some work in this problem. The attached patch is a way to make
the examples work but I think this is not the way to go, or a lot of
functions in a lot of pmc will need changes.
Index: src/pmc/complex.pmc
===
--- src/pmc/complex.pmc (revision 31697)
+++ src/pmc/complex.pmc (working copy)
@@ -758,14 +758,21 @@
*/
MULTI PMC *subtract(Complex value, PMC *dest) {
-if (dest)
-VTABLE_morph(INTERP, dest, SELF->vtable->base_type);
+if (dest) {
+ if(! VTABLE_isa(INTERP, dest, CONST_STRING(INTERP, 'Complex')))
+VTABLE_morph(INTERP, dest, SELF->vtable->base_type);
+}
else
-dest = pmc_new(INTERP, SELF->vtable->base_type);
+dest = VTABLE_clone(INTERP, SELF);
-RE(dest) = RE(SELF) - RE(value);
-IM(dest) = IM(SELF) - IM(value);
-
+{
+FLOATVAL re1 = VTABLE_get_number_keyed_int(INTERP, SELF, 0);
+FLOATVAL im1 = VTABLE_get_number_keyed_int(INTERP, SELF, 1);
+FLOATVAL re2 = VTABLE_get_number_keyed_int(INTERP, value, 0);
+FLOATVAL im2 = VTABLE_get_number_keyed_int(INTERP, value, 1);
+VTABLE_set_number_keyed_int(INTERP, dest, 0, re1 - re2);
+VTABLE_set_number_keyed_int(INTERP, dest, 1, im1 - im2);
+}
return dest;
}
Re: [svn:perl6-synopsis] r14586 - doc/trunk/design/syn
Larry Wall wrote:
> On Sun, Oct 05, 2008 at 08:19:42PM -0700, Jon Lang wrote:
> : <[EMAIL PROTECTED]> wrote:
> : > Log:
> : > Add missing series operator, mostly for readability.
> :
> : Is there a way for the continuing function to access its index as well
> : as, or instead of, the values of one or more preceding terms? And/or
> : to access elements by counting forward from the start rather than
> : backward from the end?
>
> That's what the other message was about. @_ represents the entire list
> generated so far, so you can look at its length or index it from the
> beginning. Not guaranteed to be as efficient though.
If I understand you correctly, an "All even numbers" list could be written as:
my @even = () ... { 2 * [EMAIL PROTECTED] }
And the Fibonacci series could be written as:
my @fib = () ... { (pow((1 + sqrt(5))/2, [EMAIL PROTECTED]) - pow((1 -
sqrt(5))/2,
[EMAIL PROTECTED])) / sqrt(5)) }
Mind you, these are bulkier than the versions described in the patch.
And as presented, they don't have any advantage to offset their
bulkiness, because you still have to determine every intervening
element in sequential order. If I could somehow replace '[EMAIL PROTECTED]' in
the
above code with an integer that identifies the element that's being
asked for, it would be possible to skip over the unnecessary elements,
leaving them undefined until they're directly requested. So:
say @fib[4];
would be able to calculate the fifth fibonacci number without first
calculating the prior four.
It's possible that the '...' series operator might not be the right
way to provide random access to elements. Perhaps there should be two
series operators, one for sequential access (i.e., 'infix:<...>') and
one for random access (e.g., 'infix:<...[]>'). This might clean
things up a lot: the sequential access series operator would feed the
last several elements into the generator:
0, 1 ... -> $a, $b { $a + $b }
while the random access series operator would feed the requested index
into the generator:
() ...[] -> $n { (pow((1 + sqrt(5))/2, $n) - pow((1 - sqrt(5))/2,
$n)) / sqrt(5)) }
I'd suggest that both feed the existing array into @_.
__
> : It would be nice if the programmer
> : were given the tools to do this sort of thing explicitly instead of
> : having to rely on the optimizer to know how to do this implicitly.
>
> Um, I don't understand what you're asking for. Explicit solutions
> are always available...
This was a reaction to something I (mis)read in the patch, concerning
what to do when the series operator is followed by a 'whatever'.
Please ignore.
__
On an additional note: the above patch introduces some ambiguity into
the documentation. Specifically, compare the following three lines:
X List infixZ minmax X X~X X*X XeqvX ...
R List prefix : print push say die map substr ... [+] [*] any $ @
N Terminator; <==, ==>, <<==, ==>>, {...}, unless, extra ), ], }
On the first line, '...' is the name of an operator; on the second and
third lines, '...' is documentation intended to mean "...and so on"
and "yadda-yadda", respectively. However, it is not immediately
apparent that this is so: a casual reader will be inclined to read the
first line as "...and so on" rather than 'infix:<...>', and will not
realize his error until he gets down to the point where the series
operator is defined.
__
Another question: what would the following do?
0 ... { $_ + 2 } ... &infix:<+> ... *
If I'm reading it right, this would be the same as:
infix:<...> (0; { $_ + 2 }; &infix:<+>; *)
...but beyond that, I'm lost.
__
Jonathan "Dataweaver" Lang
Re: [perl #59630] [BUG] Complex subtraction fails for subclasses of Complex
On Mon, Oct 06, 2008 at 06:05:20AM -0700, NotFound via RT wrote:
> I've done some work in this problem. The attached patch is a way to make
> the examples work but I think this is not the way to go, or a lot of
> functions in a lot of pmc will need changes.
> [...]
I agree this really isn't the way to go.
Also, I'm very curious about the use of VTABLE_morph here --
indeed, if we just look at the Integer PMC class we see some
oddities. For example, here is the code for adding and
subtracting an Integer PMC and a Complex PMC:
/* src/pmc/integer.pmc:341 */
MULTI PMC *add(Complex value, PMC *dest) {
const INTVAL a = SELF.get_integer();
dest = pmc_new(INTERP, VTABLE_type(interp, value));
VTABLE_set_number_native(INTERP, dest,
a + VTABLE_get_number_keyed_int(INTERP, value, 0));
VTABLE_set_number_keyed_int(INTERP, dest, 1,
VTABLE_get_number_keyed_int(INTERP, value, 1));
return dest;
}
/* src/pmc/integer.pmc:452 */
MULTI PMC *subtract(Complex value, PMC *dest) {
const INTVAL a = SELF.get_integer();
if (dest)
VTABLE_morph(INTERP, dest, value->vtable->base_type);
else
dest = pmc_new(INTERP, VTABLE_type(INTERP, value));
VTABLE_set_number_native(INTERP, dest,
a - VTABLE_get_number_keyed_int(INTERP, value, 0));
VTABLE_set_number_keyed_int(INTERP, dest, 1,
-VTABLE_get_number_keyed_int(INTERP, value, 1));
return dest;
}
The add operation always creates a new PMC and returns it
(never using the C PMC passed in), but the subtract
operation tries to reuse an existing C PMC if it's
not null. (Note: it actually tests for NULL and not PMCNULL,
which also seems odd.)
Seems like it should be one way or the other, but in the new
MMD code I'm not sure which.
Pm
Re: [svn:perl6-synopsis] r14586 - doc/trunk/design/syn
On Mon, Oct 06, 2008 at 09:09:55AM -0700, Jon Lang wrote:
: Larry Wall wrote:
: > On Sun, Oct 05, 2008 at 08:19:42PM -0700, Jon Lang wrote:
: > : <[EMAIL PROTECTED]> wrote:
: > : > Log:
: > : > Add missing series operator, mostly for readability.
: > :
: > : Is there a way for the continuing function to access its index as well
: > : as, or instead of, the values of one or more preceding terms? And/or
: > : to access elements by counting forward from the start rather than
: > : backward from the end?
: >
: > That's what the other message was about. @_ represents the entire list
: > generated so far, so you can look at its length or index it from the
: > beginning. Not guaranteed to be as efficient though.
:
: If I understand you correctly, an "All even numbers" list could be written as:
:
: my @even = () ... { 2 * [EMAIL PROTECTED] }
:
: And the Fibonacci series could be written as:
:
: my @fib = () ... { (pow((1 + sqrt(5))/2, [EMAIL PROTECTED]) - pow((1 -
sqrt(5))/2,
: [EMAIL PROTECTED])) / sqrt(5)) }
:
: Mind you, these are bulkier than the versions described in the patch.
: And as presented, they don't have any advantage to offset their
: bulkiness, because you still have to determine every intervening
: element in sequential order. If I could somehow replace '[EMAIL PROTECTED]'
in the
: above code with an integer that identifies the element that's being
: asked for, it would be possible to skip over the unnecessary elements,
: leaving them undefined until they're directly requested. So:
:
: say @fib[4];
:
: would be able to calculate the fifth fibonacci number without first
: calculating the prior four.
:
: It's possible that the '...' series operator might not be the right
: way to provide random access to elements. Perhaps there should be two
: series operators, one for sequential access (i.e., 'infix:<...>') and
: one for random access (e.g., 'infix:<...[]>'). This might clean
: things up a lot: the sequential access series operator would feed the
: last several elements into the generator:
:
: 0, 1 ... -> $a, $b { $a + $b }
:
: while the random access series operator would feed the requested index
: into the generator:
:
: () ...[] -> $n { (pow((1 + sqrt(5))/2, $n) - pow((1 - sqrt(5))/2,
: $n)) / sqrt(5)) }
:
: I'd suggest that both feed the existing array into @_.
That's what the ++(state $) example was about in the other message.
The only downside is that it's assuming only one element is feed in
on the left. Otherwise you need to initialize the anonymous state
variable to some larger number. Maybe it's an idiom where you just
always initialize $n to the number of elements on the left:
0,1,2 ... { state $n = 3; $n++ }
I don't see much need for additional relief, especially since
it's normally trivial to write such lists other ways:
map { func($^n) } 0..*
func($_) for 0..*
for 0..* { .func }
: On an additional note: the above patch introduces some ambiguity into
: the documentation. Specifically, compare the following three lines:
:
: X List infixZ minmax X X~X X*X XeqvX ...
: R List prefix : print push say die map substr ... [+] [*] any $ @
:
: N Terminator; <==, ==>, <<==, ==>>, {...}, unless, extra ), ], }
:
: On the first line, '...' is the name of an operator; on the second and
: third lines, '...' is documentation intended to mean "...and so on"
: and "yadda-yadda", respectively. However, it is not immediately
: apparent that this is so: a casual reader will be inclined to read the
: first line as "...and so on" rather than 'infix:<...>', and will not
: realize his error until he gets down to the point where the series
: operator is defined.
No, the second one not metasyntactic--it's the prefix:<...>, also known
as yada. It's essentially a synonym for fail, and so takes a list
argument. The third one is not yada--it's metasyntactic to represent
any "expect infix" block that stops the current expression such as in
if $x { say "yup" }
Admittedly the table is rather terse.
: __
: Another question: what would the following do?
:
: 0 ... { $_ + 2 } ... &infix:<+> ... *
:
: If I'm reading it right, this would be the same as:
:
: infix:<...> (0; { $_ + 2 }; &infix:<+>; *)
:
: ...but beyond that, I'm lost.
It would never get to the + or the * because $_ + 2 is never ().
The operator iterates each function until the function fails to
produce any list elements. Note you can go the other way too: the
function can actually return multiple list elements at once, so you
can interleave two (or more) independent lists:
0,1 ... { $^even + 2, $^odd + 2 }
Interestingly, since the returned list is a capture, such a list
in slice context would turn into [0,1],[2,3],[4,5]..., In list
context it's just 0,1,2,3,4,5...
I think that's just wicked cool.
Larry
[svn:perl6-synopsis] r14588 - doc/trunk/design/syn
Author: larry
Date: Mon Oct 6 18:15:17 2008
New Revision: 14588
Modified:
doc/trunk/design/syn/S05.pod
Log:
Added ~ twiddle macro to make it easier to write bracketing constructs.
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podMon Oct 6 18:15:17 2008
@@ -14,9 +14,9 @@
Maintainer: Patrick Michaud <[EMAIL PROTECTED]> and
Larry Wall <[EMAIL PROTECTED]>
Date: 24 Jun 2002
- Last Modified: 7 Jul 2008
+ Last Modified: 6 Oct 2008
Number: 5
- Version: 83
+ Version: 84
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them I rather than "regular
@@ -685,6 +685,59 @@
[ !~~ 'moose' ] || 'squirrel'
+=item *
+
+The C<~> operator is a helper for matching nested subrules with a
+specific terminator as the goal. It appears to be placed between the
+opening and closing bracket, like so:
+
+'(' ~ ')'
+
+However, it mostly ignores the left argument, and operates on the next
+two atoms (which may be quantified). Its operation on those next
+two atoms is to "twiddle" them so that they are actually matched in
+reverse order. Hence the expression above, at first blush, is merely
+shortand for:
+
+'(' ')'
+
+But beyond that, when it rewrites the atoms it also inserts the
+apparatus that will set up the inner expression to recognize the
+terminator, and to produce an appropriate error message if the
+inner expression does not terminate on the required closing atom.
+So it really does pay attention to the left bracket as well, and it
+actually rewrites our example to something more like:
+
+$ = '(' [ $GOAL || ]
+
+Note that you can use this construct to set up expectations for
+a closing construct even when there's no opening bracket:
+
+ ~ ')' \d+
+
+By default the error message uses the name of the current rule as an
+indicator of the abstract goal of the parser at that point. However,
+often this is not terribly informative, especially when rules are named
+according to an internal scheme that will not make sense to the user.
+The C<:dba> ("doing business as") adverb may be used to set up a more
informative name for
+what the following code is trying to parse:
+
+token postfix:sym<[ ]> {
+ :dba
+ '[' ~ ']'
+}
+
+Then instead of getting a message like:
+
+Unable to parse expression in postfix:sym<[ ]>; couldn't find final ']'
+
+you'll get a message like:
+
+Unable to parse expression in array subscript; couldn't find final ']'
+
+(The C<:dba> adverb may also be used to give names to alternations
+and alternatives, which helps the lexer give better error messages.)
+
=back
=head1 Bracket rationalization
[perl #59636] [BUG] t/op/bitwise.t fails on Darwin
This was passing on Darwin as of r31667, i.e., just before the merge. See http://smolder.plusthree.com/app/public_projects/tap_stream/5891/163
[perl #59638] [BUG] t/pmc/bigint.t fails on Darwin
This was passing as of r31667, i.e., just before the merge. See http://smolder.plusthree.com/app/public_projects/tap_stream/5891/201
