Re: [tclquadcode] callframe-impl branch, and progress toward namespace variables.

[Donal K. F. <don...@ma...>]

On 23/06/2017 18:07, Kevin Kenny wrote:
> I don't consider [info level] to be a blocker for merging into the
> trunk. There are lots of Tcl features that we don't support yet, and
> [info level] isn't a regression from earlier versions of quadcode.

I've looked into it a bit more, and I've put in place something 
synthetic and a bit nasty. Essentially, I make up the list of arguments 
(making them from the real arguments except for the name of the command) 
and I now manage the resulting object lifespans correctly; the 
information should be at least acceptably close, and doing better will 
require actually passing the whole objc/objv from Tcl. Since I think 
most of the commands for which we do this are the ones where we're 
passing in all the arguments as STRINGs anyway (because we now do the 
parsing inside the generated code, not the thunk) the actual costs will 
be quite small. It took a few attempts (including one that actually 
ended up being committed because I was really tired) but I've now made 
something that works and which isn't nastily expensive as it is able to 
hold the various arrays on the C stack. (We'll also need to rethink that 
when we do NRE support.)

We can revisit this all later, but I think it's good enough for now and 
I've integrated the branch back to trunk. The only test failures we've 
got at the moment are where we don't handle some exception cases quite 
the same, and they're not actually related to callframes. We've a few 
slowdowns too, but they don't look serious.

Donal.