Re: [PATCH] Parrot_(re)allocate_buffer

2002-04-03 Thread Peter Gibbs
> this would make mem_realloc and Parrot_reallocate_buffer a little bit more > difficult, since they'd have to allocate a temporary buffer on the stack I had thought of moving the current functionality of Parrot_allocate into an internal-use-only function (allocate_buffer or some such), which wou

Re: [PATCH] Parrot_(re)allocate_buffer

2002-04-03 Thread Bryan C. Warnock
On Wednesday 03 April 2002 16:55, Michel J Lambert wrote: > > Why add new functions instead of patching the current ones? > > I didn't know if the original functions still had a purpose. Perhaps you > would want to Parrot_allocate for something non-bufferish? Thinking about > it, that seems evill

Re: cvs commit: parrot core.ops

2002-04-03 Thread Melvin Smith
>Add a 'depth' operation that returns the depth of the user stack. If >the name bothers anyone, feel free to rename it. (Some might call it >the 'height' of the stack, for instance.) Since you mentioned it... How about a set of ops that does complete environment save/restore. I suppose this w

Re: [PATCH] Parrot_(re)allocate_buffer

2002-04-03 Thread Michel J Lambert
> Why add new functions instead of patching the current ones? I didn't know if the original functions still had a purpose. Perhaps you would want to Parrot_allocate for something non-bufferish? Thinking about it, that seems evilly wrong, so I guess that is not a valid reason. Doing this would ma

Re: [APPLIED] Frame stack patch

2002-04-03 Thread Melvin Smith
At 10:40 AM 3/30/2002 -0500, Melvin Smith wrote: >At 09:09 AM 3/30/2002 -0500, Dan Sugalski wrote: >>At 1:03 AM -0500 3/30/02, Melvin Smith wrote: >>>Frame stacks now keep their size, no use in freeing the chunks; if we >>>reached a frame depth N once, we will typically reach N many more times. >>

[Applied] round up of warning fixes

2002-04-03 Thread Josh Wilmes
Thanks, applied! --Josh At 9:49 on 04/03/2002 +0100, Jonathan Stowe <[EMAIL PROTECTED]> wrote: > This is the residue of the warning fixes I have made and which haven't > been applied before I start a new working copy :) > > Index: chartype.c > =

Re: [PATCH] Parrot_(re)allocate_buffer

2002-04-03 Thread Bryan C. Warnock
On Wednesday 03 April 2002 05:35, Michel J Lambert wrote: > > My first thoughts on this are that we should go the whole way, and have > > Parrot_allocate take a Buffer* and a requested size, and let it fill in the > > bufstart and buflen parameters (as in the not-yet-implemented > > Parrot_reallo

Re: [PATCH] Re: Definition of a null string?

2002-04-03 Thread Bryan C. Warnock
On Wednesday 03 April 2002 01:05, Peter Gibbs wrote: > > > > or something else similar. > > My first thoughts on this are that we should go the whole way, and have > Parrot_allocate take a Buffer* and a requested size, and let it fill in the > bufstart and buflen parameters (as in the not-yet-imp

[PATCH] Parrot_(re)allocate_buffer

2002-04-03 Thread Michel J Lambert
> My first thoughts on this are that we should go the whole way, and have > Parrot_allocate take a Buffer* and a requested size, and let it fill in the > bufstart and buflen parameters (as in the not-yet-implemented > Parrot_reallocate patch). Heh, I thought the exact same thing when I first saw

[PATCH(es)] round up of warning fixes

2002-04-03 Thread Jonathan Stowe
This is the residue of the warning fixes I have made and which haven't been applied before I start a new working copy :) Index: chartype.c === RCS file: /home/perlcvs/parrot/chartype.c,v retrieving revision 1.5 diff -u -r1.5 chartype