I've thrown in my bignumber stuff, it's in types/bignum*, along with a
couple of perl files I've been using to test them against a set of
regression tests that IBM have made available.
It is far from finished, and needs support for bigints added in, I
plan to do this by using a negative precision
Dan Sugalski:
# So, what about the ramifications of:
#
# $foo = @bar
#
# @bar's get_integer method is called, and $foo's set_integer method is
# called. No temp PMCs.
Huh? Assigning an array to a scalar yields a reference to an array. In
integer context that yields the length. In string c
At 11:39 PM + 2/12/02, Simon Cozens wrote:
>Dan Sugalski:
>> So, what about the ramifications of:
>
>No. You've glossed over the details of how we know that
>
>this assignment is integer, and
>
>this assignment is string,
>
>and this assignment is integer.
>
>Parrot can't know this, surely.
Dan Sugalski:
> So, what about the ramifications of:
No. You've glossed over the details of how we know that
> $foo = @bar
> @bar's get_integer method is called, and $foo's set_integer method is
> called. No temp PMCs.
this assignment is integer, and
> $foo = %bar
> calls %bar's get_s
Currently the add, subtract, multiply and divide methods in perlnum.pmc
are all coded along the lines of:
void add (PMC * value, PMC* dest) {
if(value->vtable == &Parrot_base_vtables[enum_class_PerlInt]) {
*dest->vtable = &Parrot_base_vtables[enum_class_PerlNum];
*
We've been going around a bit about how PMCs should be set and
assigned to and suchlike things. So, here's the scoop.
There are three sorts of assignment:
1) Pointer assignment
2) Requests to get a value
3) Forced value sets
#1 is essentially a sort of bookkeeping. A pointer to one sort of PMC
Most of the PerlUndef tests in pmc.t appear to have been added twice.
Enclosed patch removes the duplicates.
Simon
--- t/pmc/pmc.t.old Tue Feb 12 15:23:30 2002
+++ t/pmc/pmc.t Tue Feb 12 15:25:07 2002
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test tests => 61;
+use Parrot::Test tests =>
| > Excellent. Until, of course, we have to implement it. We'll implement
| > it by calling some vtable method on P1, that much is obvious. But which
| > one? Our implementation of the set_p_p op can't know whether or not P1
| > wants a string, an integer, or a number. Or something entirely differ
Simon Cozens <[EMAIL PROTECTED]> writes:
> Are you sitting comfortably? Then I'll begin.
>
> It's a pretty simple concept. We need to assign one PMC to another.
> We'll have to do it all the time:
>
> $a = $b;
>
> $a and $b are both PMCs, and we need to set the value of one to the
> value
Dave Mitchell:
> Just to clarify this - so there will be 2 separate tarballs, each with
> their own set of READMEs, config scripts etc. You install one of them first,
> then the second install makes use of the just-installed
> /usr/local/lib/parrot.so or perl6.so for its own build
Yes to READMEs,
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Melvin Smith:
> > I agree with your config/ dir suggestion, but I'm not sure about
> > moving everything else down into perl6/parrot subdirectory,
>
> Me neither. I don't see much point in it.
>
> > 1) Will Perl6 and Parrot distributions be separate?
>
> Are you sitting comfortably?
yes.
>
> It's a pretty simple concept. We need to assign one PMC to another.
> We'll have to do it all the time:
>
> $a = $b;
>
> $a and $b are both PMCs, and we need to set the value of one to the
> value of the other, so let's write it as
>
> set P1,
On Mon, 2002-02-11 at 18:30, Bryan C. Warnock wrote:
> On Monday 11 February 2002 16:18, Gregor N. Purdy wrote:
> > Bryan --
> >
> > > > IIRC sizeof(opcode_t) === 4, since it is required that opcode_t be 32
> > > > bits. So, that 4 is supposed to be a 4, although turning it into a
> > > > symbolic
13 matches
Mail list logo
