restarting the discussion: parrot build system

There was a flurry of activity on perl6-internals a few weeks ago about creating/finding a cross platform build system for building parrot and perl6. I'm trying to restart that discussion over here in perl6-build, to try and get the collective mindset to put together a proposal for how this

Re: Parrot FAQ

[EMAIL PROTECTED] (Steve Fink) writes: On Wed, Dec 05, 2001 at 11:02:34AM -0500, Dan Sugalski wrote: Q: Who has commit privileges? Who's responsible for what? A: Good question. Simon and Dan, and a handful of others. Can anyone fill in the handful? Ask, maybe? I'm hoping for a

Bytecode portablilty

For the past week or so, I've been working on design and code within this area. While I am waiting for answers to my last couple of questions, I'm throwing this out there. This is mostly FYI, partly RFC, and not an FIX. Portability: There are four levels of potential portability and

[Patch] - for memory.c

This small patch cleans up two things with the allocate aligned memory routine. It cleans up the for loop eliminating the need for the bit operations inside and making it a bit clearer what is happening. It also reduces the memory allocated from twice the rounded up power of two to the

Re: [Patch] - for memory.c

On Sun, 9 Dec 2001, David Jacobs wrote: +for (i = 1; size i; i = 1); Infinite loop if size == MAXINT, eh? So don't do that. Ok. -sam

[Patch] - stacks.c

This patch fixes a bug in the pop_generic_entry's switch statment, changing it from switching on type to (*top)-entry_type. Otherwise when type=0 (i.e., don't care) the logic breaks. The patch also includes a few styalistic changes that make it easier for the compiler to optimize (e.g.,

Re: [Patch] - for memory.c

Thanks for the catch! How about just adding the limit check back in. for (i=1; (sizei) (i0xff); i=1); Do you like the rest of the changes I made to the algorithm? David Jacobs - Original Message - From: Sam Tregar [EMAIL PROTECTED] +for (i = 1; size i; i = 1);

Re: [Patch] - for memory.c

Ack! never mind, I see the problem, I'll submit a new patch if an elegant solution comes to me. Thanks for your time. David - Original Message - From: David Lisa Jacobs [EMAIL PROTECTED] To: Sam Tregar [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, December 09, 2001 5:16 PM

gc object destruction

One of the interesting side-effects of a copying collector is that we can't inherently determine which objects need to be destructed (their memory space just gets reused without notifying anyone). I'm already looking to use some algorithms that utilize linked-lists to determine

mem_allocate_aligned

While implementing one of my IO routines in core.ops I used free_string() on a string that was created ultimately with mem_allocate_aligned() and I get core dumps. I assume it has to do with the fact that the memory allocator adjusts the address before returning the chunk and free() then gets

Re: cvs.perl.org downtime (fwd)

On Fri, 7 Dec 2001, Ask Bjoern Hansen wrote: the city is doing some compliance testing whatever on the building where cvs.perl.org is this Sunday (don't ask, I think it sounds odd too!). power is back up and so is the box where cvs.perl.org is. have fun. :) - ask -- ask bjoern hansen,

Re: cvs.perl.org downtime (fwd)

On Sun, 9 Dec 2001, Ask Bjoern Hansen wrote: power is back up and so is the box where cvs.perl.org is. have fun. :) Ahaa... never mind the man behind the curtain. In a particular clever moment I screwed up the ipfw rules so now the box is running but noone can talk to it. It's 60 miles