(A note--when this says "stack" I really mean all the stacks)
Okay, I've been thinking about stacks and stack frames, and suchlike
things. Well, calling them "stacks" is a bit of a misnomer, since
they're really trees, and that's partially where things get nasty.
Looking at them as trees does
I've updated http://www.parrotcode.org/todo with the latest info from
Dan.
Dan Sugalski writes:
>Here's the list 'o stuff I'd like to get done for August:
>
>*) Multiple interpreters with inter-interpreter calling done right
>*) Threads with multiple independent interpreters
>*) Method calls
>*
Here's the list 'o stuff I'd like to get done for August:
*) Multiple interpreters with inter-interpreter calling done right
*) Threads with multiple independent interpreters
*) Method calls
*) PMC attributes
--
Dan
--
At 8:17 PM -0400 6/10/02, Jeff wrote:
>If anyone would like 'inc_i_ic' and the like to still be called 'inc_',
>speak within the next few days or hold your peace until someone else
>decides to add them back to CVS. I'll rewrite the tests to 'add_n_ic'
>and that ilk.
Too bad, they lose. :) add is
At 19:33 on 06/10/2002 EDT, Jason Gloudon <[EMAIL PROTECTED]> wrote:
> Someone may want to write the code to do something useful with the results
> of stat() when mmap() is not being used.
It's supposed to already do that... did i goof?
--Josh
Tests are now failing because of the removal of the 'inc_n_ic' opcode. I
find this interesting for several reasons. One, the tests probably
should have been removed. Two, once the 'inc' operator has two
parameters, it is no longer 'increment' in my mind. I would call
two-parameter 'inc' two-parame
This fixes the problem with reading .pbc files on win32. Someone may want to
write the code to do something useful with the results of stat() when mmap() is
not being used.
Index: assemble.pl
===
RCS file: /cvs/public/parrot/assemb
At 11:31 AM +0200 6/10/02, Jerome Vouillon wrote:
>On Sun, Jun 09, 2002 at 05:18:31PM -0400, Dan Sugalski wrote:
>> Who says we're only using callcc to capture continuations? We can do
>> it anywhere, so we potentially need the registers stored so we can
>> properly restore state when we're inv
On Sun, 9 Jun 2002 [EMAIL PROTECTED] wrote:
: The parsing of perl 6 is the application of a huge, compiled, regex, correct?
No, it's a system of compiled regexes which we're calling a grammar.
: In order to parse the new syntax, perl6 is going to have to compile the
: new rule, and stick it in
On Sun, Jun 09, 2002 at 05:18:31PM -0400, Dan Sugalski wrote:
> Who says we're only using callcc to capture continuations? We can do
> it anywhere, so we potentially need the registers stored so we can
> properly restore state when we're invoked.
I don't understand what you mean. In scheme, ca
At 11:09 AM -0400 6/6/02, Jason Gloudon wrote:
>
>This seems like a good time to send in this patch:
>
>It allocates the stack content memory using a buffer. This makes the stack
>chunks and the memory used to hold stack contents visible to the garbage
>collector. One can incrementally add to thi
At 12:53 PM +0200 6/9/02, Jerome Vouillon wrote:
>On Sat, Jun 08, 2002 at 03:54:06PM -0400, Melvin Smith wrote:
>The Java bytecode interpreter is clearly not optimized for speed.
>David Gregg, Anton Ertl and Andreas Krall have experimented with an
>improved Java bytecode interpreter. One of the
12 matches
Mail list logo
