At 10:33 AM 9/17/2001 -0400, Gregor N. Purdy wrote:
>Any thoughts?
The big one is you shouldn't assume that we are only going to have a single
chunk of bytecode--we may well have several loaded from disk, and more
created on the fly by eval/do/dynamic recompilation.
Also, we're trying to keep the stuff in the loop to a minimum, so for this
I'd rather have a separate runops function, as well as having the actual
funky stuff in the body separated out. (I'd really like it abstracted out
into a generic debugging runops, but we can do that later)
Other than that it looks pretty good.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
- [PATCH] Bytecode bounds checking and TRACE_OPS Gregor N. Purdy
- Re: [PATCH] Bytecode bounds checking and TRACE_OPS Dan Sugalski
- Re: [PATCH] Bytecode bounds checking and TRACE_OPS Simon Cozens
- Re: [PATCH] Bytecode bounds checking and TRACE_OPS Gregor N. Purdy
- Re: [PATCH] Bytecode bounds checking and TRACE_OPS Dan Sugalski
- Re: [PATCH] Bytecode bounds checking and TRACE_OPS Gregor N. Purdy
- Re: [PATCH] Bytecode bounds checking and TRACE_OPS Simon Cozens
- Re: [PATCH] Bytecode bounds checking and TRACE_OPS Dan Sugalski
- Re: [PATCH] Bytecode bounds checking and TRACE_OPS Dan Sugalski
- Re: [PATCH] Bytecode bounds checking and TRACE_OPS Gregor N. Purdy
- Re: [PATCH] Bytecode bounds checking and TRACE_OPS Leon Brocard
