At 04:28 PM 8/2/2002 +0200, Haegl wrote:
>On 2002/08/02 16:11:26 Nicholas Clark <[EMAIL PROTECTED]> wrote:
>
> >It does on reading. I forget the eloquent explanation about the how or
> >why, but all references bar the leftmost are vivified. (Even inside
> >defined). In effect, all bar the last ref
At 8:56 AM -0400 8/3/02, Bryan C. Warnock wrote:
>Sorry for the Wayback Machine...
>
>On Mon, 2002-07-15 at 01:13, Ashley Winters wrote:
>> I decided my next step should be to take a look at the PDDs so I know what's
>> going on. I would expect them to be like a writer's canon for a TV
>>show.
Peter Gibbs wrote:
> I am very much in agreement with this concept in principle. I would like you
> to consider adding a name/tag/id field to all pool headers, containing a
> short text description of the pool, for debugging purposes.
I don't have a problem with that. And yes, it'd definitely he
On Sat, Aug 03, 2002 at 01:42:06AM -0400, Melvin Smith wrote:
> Here is an attempt. I'm assuming the stack of pads is a singly-linked list
> of pads with children pointing to parents, and multiple children can refer
> to the same parent. If they are created on the fly, the creation of
> a Sub or C
On Sat, 3 Aug 2002, Nicholas Clark wrote:
> I wasn't actually expecting you to apply that :-)
> It was more a "where I am at now" informational patch.
Sorry :)
>
> I think that this patch is at good point to pause and take stock. I believe
> it JITs just about every integer op (including some i3
On Fri, Aug 02, 2002 at 09:06:31PM +0100, Nicholas Clark wrote:
> On Fri, Aug 02, 2002 at 06:43:49PM +0200, Jerome Vouillon wrote:
> > Allocating a hash will certainly remain a lot more expensive than
> > allocating an array. And we are going to allocate pads pretty
> > often...
>
> Are we? Or a
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #15971]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=15971 >
Hi,
when trying to compile a perl6 program to native c, pbc2c fails on the
capture
How Freudian can you get. The subject on this email should have been RECALL
renamed to AGAIN. It took me until now to realize this.
Sorry,
Tanton
- Original Message -
From: "Tanton Gibbs (via RT)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 25, 2002 2:36 PM
Subject:
Mike Lambert wrote:
> At one point, we had a mem_alloc_aligned, which guaranteed the start of a
> block of memory given any pointer into the contents of the block. If we
> store a pointer to the pool at the beginning of each set of headers, then
> we navoid the need for a per-header pool pointer,
Mike Lambert wrote:
> I'm currently favoring allowing for header pools on a per-type basis, not
> just a per-size basis. This would give us a 'hash' pool. The pool
> structure would contain function pointers for collection and/or dod
> purposes. (stuff that would otherwise be in a PMC vtable.)
I
Sorry for the Wayback Machine...
On Mon, 2002-07-15 at 01:13, Ashley Winters wrote:
> I decided my next step should be to take a look at the PDDs so I know what's
> going on. I would expect them to be like a writer's canon for a TV show. I'll
> write my impressions as I go on.
>
> PDD00:
> Doe
Sean O'Rourke wrote:
> On Sun, 4 Aug 2002, Mike Lambert wrote:
>
>>Unfortunately, this causes different semantics for whether you are storing
>>primitives or pointers (primitives copy, whereas pointers are shallow). Of
>>course, one could argue that the previous one didn't work at all. :)
>>
>>T
Mike Lambert wrote:
> One idea, which is most closely in line with the current semantics, is to
> add a pool pointer to every header. I've found a few times in the past
> where such a pointer would have come in handy. This would allow us to call
> the pool's mark() function, to handle stuff like
> Okay, I finally give. For purposes of liveness tracing and GC, we're
> going to unify PMCs and strings/buffers. This means we trace through
> strings and buffers if the flags are right, and we need to add a GC
> link pointer to strings/buffers. It'll make things a bit larger,
> which I don't lik
On Sun, 4 Aug 2002, Mike Lambert wrote:
> Unfortunately, this causes different semantics for whether you are storing
> primitives or pointers (primitives copy, whereas pointers are shallow). Of
> course, one could argue that the previous one didn't work at all. :)
>
> Thoughts?
Well, it's certain
15 matches
Mail list logo
