Mark Biggar wrote:
Handling promotion (and demotion) between single and multi-precision
integers is fairly easy. And once you have that doing it for rationals
is basically free. Likewise promoting an Integer up to rational is
trivial and vice versa. But promotion (or demotion) between IEEE flo
In src/string.c, the documentation for string_substr() says:
=item C
Copies the substring of length C from C from the specified
Parrot string and stores it in C<**d>, allocating memory if necessary. The
substring is also returned.
=cut
*/
The signature is:
PARROT_API
PARROT_CANNOT_RETURN_NULL
Handling promotion (and demotion) between single and multi-precision
integers is fairly easy. And once you have that doing it for rationals
is basically free. Likewise promoting an Integer up to rational is
trivial and vice versa. But promotion (or demotion) between IEEE floats
and rationals i
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Sat, 4 Oct 2008 22:08:10 -0400
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Sat, 4 Oct 2008 18:15:57 -0500
. . .
All of the mechanisms I've been able to find in Parrot for
converting an arbitrary PMC to a num
On Sat, Oct 04, 2008 at 10:08:10PM -0400, Bob Rogers wrote:
> Hmm. My instinct would be to rely on MMD:
>
> .sub 'infix:*' :multi(Perl6Array,_)
> .param pmc a
> .param pmc b
> $P0 = new 'Integer'
> $P0 = a
> .return 'infix:*'($P0, b)
>
Patrick R. Michaud wrote:
Correct. I suspect that eventually the Rakudo developers will have
to develop a custom set of PMCs for Perl 6 behaviors rather than
relying on the Parrot ones.
I think it would be better for things like unlimited-precision integers and
rationals to be Parrot generic
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Sat, 4 Oct 2008 18:15:57 -0500
One of the big problems with Parrot's n_* opcodes is that they
often assume that the type of the result should be the same as
the type of the first operand . . .
I kinda thought it wouldn't be that
On Sat, Oct 04, 2008 at 05:09:47PM -0400, Bob Rogers wrote:
Content-Description: message body text
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Sat, 4 Oct 2008 09:41:22 -0500
>
>On Fri, Oct 03, 2008 at 09:47:38PM -0700, Larry Wall wrote:
>> On Fri, Oct 03, 2008 at 11:57:3
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Sat, 4 Oct 2008 09:41:22 -0500
On Fri, Oct 03, 2008 at 09:47:38PM -0700, Larry Wall wrote:
> On Fri, Oct 03, 2008 at 11:57:30PM -0400, Michael G Schwern wrote:
> : What's the status of numeric upgrades in Perl 6? Is see the
>
On Sat, Oct 4, 2008 at 8:01 AM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 03, 2008 at 07:22:28PM -0700, [EMAIL PROTECTED] wrote:
>> Log:
>> [rakudo] implement 'package' package declarator
>>
>> Modified: trunk/languages/perl6/perl6.pir
>> ==
On Fri, Oct 03, 2008 at 06:23:42AM -0700, I Sop wrote:
> > From: Patrick R. Michaud via RT <[EMAIL PROTECTED]>
> > On Thu, Oct 02, 2008 at 02:16:01PM -0700, I Sop wrote:
> > >
> > > I just copied the 'attribute' method, renamed
> > > everything, and changed the parameter order for the
> > > 'getpr
On Fri, Oct 03, 2008 at 07:22:28PM -0700, [EMAIL PROTECTED] wrote:
> Log:
> [rakudo] implement 'package' package declarator
>
> Modified: trunk/languages/perl6/perl6.pir
> ==
> --- trunk/languages/perl6/perl6.pir (origin
On Fri, Oct 03, 2008 at 09:47:38PM -0700, Larry Wall wrote:
> On Fri, Oct 03, 2008 at 11:57:30PM -0400, Michael G Schwern wrote:
> : What's the status of numeric upgrades in Perl 6? Is see the
> : docs say "Perl 6 intrinsically supports big integers and rationals
> : through its system of type d
>> Your point is very interesting. However, if you believe this issue
>> merits more extended discussion, I would recommend you open up a new RT
>> ticket, perhaps in the [RFC] category (or [RFP] or whatever it's called).
>>
>> I would like to keep the discussion in *this* RT focused on the issues
2008/10/4 James Keenan via RT <[EMAIL PROTECTED]>:
> On Fri Oct 03 08:55:12 2008, coke wrote:
>> This is a patch-response to r31585, which required a particular
>> version of Storable in one file.
>>
>> Attached, find a patch which bumps our core perl requirement to 5.8.6,
>> the first time this pa
> The problem is that pc 9/line 3 is the location of the invokecc
> instruction that calls the erring test sub, not the location of the
> get_results instruction where the problem is detected. I'm not sure how
> to fix this, because it messes greatly with the modularity of how return
> addresses a
> When fiddling with 'make splint' I ran into a Splint parse error:
>
> src/exceptions.c:500:25: Variable size initialized to type int, expects
> size_t: backtrace(array, 32)
> src/exceptions.c:503:36: Unrecognized format code: %zd stack frames (max
> trace depth is %d).\n
> src/exceptions.c:507:17
# New Ticket Created by Bob Rogers
# Please include the string: [perl #59614]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=59614 >
Invoking the attached test case fails in the following way:
[EMAIL PROTECTED]>
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #59596]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=59596 >
Rakudo r31589 does not follow S03 in deferring ++ to a user-defined
.succ method.
$ ./p
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #59590]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=59590 >
When fiddling with 'make splint' I ran into a Splint parse error:
src/exception
> From: Patrick R. Michaud via RT <[EMAIL PROTECTED]>
> Subject: Re: [perl #59576] [PATCH] 'property' scope for PAST::Var
> To: [EMAIL PROTECTED]
> Date: Friday, October 3, 2008, 12:31 PM
> On Thu, Oct 02, 2008 at 02:16:01PM -0700, I Sop wrote:
> >
> > I just copied the 'attribute' method, renamed
# New Ticket Created by Chris Fields
# Please include the string: [perl #59586]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=59586 >
Attaching a patch for a partial implementation of the :g or :global
modifier with .mat
In-Reply-To: Message from Michael G Schwern <[EMAIL PROTECTED]>
of "Sat, 04 Oct 2008 02:06:18 EDT." <[EMAIL PROTECTED]>
> Larry Wall wrote:
>> The status of numeric upgrades in Perl 6 is fine. It's rakudo that
>> doesn't do so well. :)
>>
>> As another datapoint:
>>
>> $ pugs -e 'say 2**40'
23 matches
Mail list logo
