At 6:52 PM -0500 4/3/02, Bryan C. Warnock wrote:
>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 someth
On Thursday 04 April 2002 16:30, Michel J Lambert wrote:
>
> Yeah, but I can't go ahead changing this stuff, especially if all the code
> isn't converted over to using it yet. One working step at a time, says
> Refactoring Man. :)
Say no more... ;-)
>
> > IIUC, the mem*alloc routines are for
> The concern is that both functions are still using the same arenas, which
> means the original problems still wouldn't be solved, and we'd still have to
> do all the workarounds around them. ;-)
Yeah, but I can't go ahead changing this stuff, especially if all the code
isn't converted over to
> 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
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
> 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
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
> 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
