Dan --
> 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.
Yeah. It seems we should have a parrot_bytecode structure that keeps the
pointer to the block-o-bytes, and also memoizes the pointers to the
other bits, and the length(s).
I didn't mess with that, though, because I didn't want to conflate too
many issues.
> 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)
So, shall I make a runops_trace() function and modify test_prog to run
that if it is passed an approproate --trace (or something) flag?
> Other than that it looks pretty good.
I'll wait for a little more feedback, modify, and submit another patch.
If that looks good, I'll go ahead and commit.
Regards,
-- Gregor
_____________________________________________________________________
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\_____________________________________________________________________/
