David Robins wrote:
On Wed, 18 Dec 2002, Leopold Toetsch wrote:
always compare ids (vtables may change) - yes, many pmc's do like above,
but will need changes too.
What do you mean by ids? pmc->type()?
Yes, ->vtable->type().
morph "dest" to be a "ret"?
unimplemented, unused, but yo
Looking at some of the test failures, I see several instances where
t/src/sprintf test 1 is failing because
printf("0x%x", (int) -1) is 0x
but
Parrot_sprintf("%08vd", (INTVAL) -1) is 0x
Except that the latter seems correct to me, for a 64-bit platform.
For now, I'm
On Wed, 18 Dec 2002, Leopold Toetsch wrote:
> David Robins wrote:
> > if(value->vtable == &Parrot_base_vtables[enum_class_Vec2D_in_Y_plane]) {
>
> always compare ids (vtables may change) - yes, many pmc's do like above,
> but will need changes too.
What do you mean by ids? pmc->type()?
> >
Nicholas Clark wrote:
On Tue, Dec 17, 2002 at 09:40:26AM +0100, Leopold Toetsch wrote:
what would your response be? :-)
dddp (s. docs/jit.pod)
[if I remove either the set N1, or the sub N2, the answer is correct in the
JIT]
Register allocation problem WRT K5
Nicholas Clark
leo
Steve Fink wrote:
I propose that we have configure probes for the variations that we can
support, but have everything else (including miniparrot) fall back to
a registration scheme. In other words, whenever you allocate a
collectible pointer and don't immediately anchor it to something, you
have
Marco Baringer wrote:
speaking of compiling directly to pbc, parrotbyte.pod says that number
constants should be encoded as FLOATVALs, which is a system dependant
careteristic, shouldn't there be a specified format for floats? ie
either ieee single/double float or, preferably, the number segment
David Robins wrote:
What's the cleanest way to return a new PMC from an op?
e.g. Suppose I have a Vec2D_in_X_plane and a Vec2D_in_Y_plane and I add them
and want to always produce a Vec3D - is this correct (and is it efficient?):
void add(PMC* value, PMC* dest) {
if(value->vtable == &Par
Attribution lists are getting a bit complex. This is in response to what Piers wrote
on Wed, Dec 18, 2002 at 03:50:44PM +.
DKS
> > [specifying types]
> > Hm. I'm way short on sleep today, so I'm probably missing something,
> > but I don't see why Perl can't sort this out without a specific
If it's not obvious, we're pausing briefly in the documentation effort
to wait for A6. We're stuck on a few fronts that should become
slightly clearer when we get a better idea of how subroutines (and,
more importantly, their parameters!) work, so it's a good place for a
break.
After A6 comes
What's the cleanest way to return a new PMC from an op?
e.g. Suppose I have a Vec2D_in_X_plane and a Vec2D_in_Y_plane and I add them
and want to always produce a Vec3D - is this correct (and is it efficient?):
void add(PMC* value, PMC* dest) {
if(value->vtable == &Parrot_base_vtables[enum_
Dave Storrs <[EMAIL PROTECTED]> writes:
> On Wed, Dec 18, 2002 at 09:31:41AM +, Piers Cawley wrote:
>> Dave Storrs <[EMAIL PROTECTED]> writes:
>> > It seems like Perl6 is moving farther and farther away from Perl5's
>> > (almost) typelessness.
>>
>> It depends what you mean by typed. Perl h
On Wed, Dec 18, 2002 at 09:31:41AM +, Piers Cawley wrote:
> Dave Storrs <[EMAIL PROTECTED]> writes:
> > It seems like Perl6 is moving farther and farther away from Perl5's
> > (almost) typelessness.
>
> It depends what you mean by typed. Perl has always had strongly typed
> *values* (which s
On Tue, Dec 17, 2002 at 09:40:26AM +0100, Leopold Toetsch wrote:
> Tracking this further down would need some extensive debug sessions on
> this machine, which would currently imply to prepare pasm's w/o macros
> and empty lines.
Aha. But say I cut it down to this:
set N1, 0.0
We have indeed gone through this before. The last time the dominant argument
was that these types of mark/unmark operations can be mis-used just as readily
as malloc/free, because the programmer has to know when and where to call them.
I'm just repeating this for everyone's benefit, not giving an
The Perl Summary for the week ending 20021215
Hi, and welcome to the first summary prepared on my shiny second hand
TiBook (no, it wasn't a gift from a grateful summary reader, it was
bought from a friend who was upgrading, gifts from grateful summary
readers are, of course, still w
On Tue, Dec 17, 2002 at 09:48:56AM -0500, Dan Sugalski wrote:
> >Simon Cozens wrote:
> >> Once again we're getting steadily closer to inventing Ruby.
> >
> >Agreed, but I don't think this is necessarily a Bad Thing.
>
> Disagreed--we're getting steadily closer to inventing Smalltalk. :)
Silly r
Steve Fink wrote:
> (UNPIN would probably be better than RELEASE, huh?)
Maybe ATTACH / DETACH or AQUIRE / RELEASE?
A
On Tue, Dec 17, 2002 at 11:49:50PM -0800, Steve Fink wrote:
> As a more concrete demonstration of what I'm talking about, here's an
> implementiation of the easy part: the pinning and releasing macros.
> (UNPIN would probably be better than RELEASE, huh?) It's a naive
> implementation with a low fi
Dave Storrs <[EMAIL PROTECTED]> writes:
> On Mon, Dec 09, 2002 at 03:58:54PM -0700, Luke Palmer wrote:
>> > From: Dave Storrs <[EMAIL PROTECTED]>
>> > My understanding was that in Perl6, you could use pretty much anything
>> > for a hashkey--string, number, object, whatever, and that it did not
>>
On Wed, Dec 18, 2002 at 03:11:59AM +, Bruce Gray wrote:
> 2) PTR_SIZE == INTVAL_SIZE == LONG_SIZE (x86 Linux and Win32)
> Intermediate casts to (unsigned long) removed, i.e.
> (any)(unsigned long)(d)
> becomes
> (any)(d)
> Under MS VC++ for .Net, this patch changes the results of
20 matches
Mail list logo
