Jeremy Hylton wrote:
>
> I think it makes sense to avoid being obscure or unclear in order to
> minimize the size of the patch or the diff. Realistically, it's
> unlikely that anything like your original patch is going to make it
> into the CVS tree. It's primary value is as proof of concept and as
> code that the rest of us can try out. If you make large changes, but
> they are clearer, you'll help us out a lot.
Many many thanks. This is good advice.
I will make absolutely clear what's going on, keep
parts untouched as possible, cut out parts which must
change, and I will not look into speed too much.
Better have a function call more and a bit less optimization,
but a clear and rock-solid introduction of a concept.
> We can worry about minimizing the impact of the changes on the
> codebase after, after everyone has figured out what's going on and
> agree that its worth doing.
>
> feeling-much-more-confident-because-I-didn't-say-continuation-ly yr's,
> Jeremy
Hihi - the new little slot with local variables of the
interpreter happens to have the name "continuation".
Maybe I'd better rename it to "activation record"?.
Now, there is no longer a recoursive call. Instead, a frame
object is returned, which is waiting to be activated
by a dispatcher.
Some more ideas are popping up. Right now, only the recursive
calls can vanish. Callbacks from C code which is called by
the interpreter whcih is called by... is still a problem.
But it might perhaps vanish completely. We have to see
how much the cost is. But if I can manage to let the interpreter
duck and cover also on every call to a builtin? The interpreter
again returns to the dispatcher which then calls the builtin.
Well, if that builtin happens to call to the interpreter again,
it will be a dispatcher again. The machine stack grows a little,
but since everything is saved in the frames, these stacks are
no longer related. This means, the principle works with existing
extension modules, since interpreter-world and C-stack world
are decoupled.
To avoid stack growth, of course a number of builtins would
be better changed, but it is no must in the first place.
execfile for instance is a candidate which needn't call the
interpreter. It could equally parse the file, generate the
code object, build a frame and just return it. This is what
the dispatcher likes: returned frames are put on the chain
and fired.
waah, my bus - running - ciao - chris
--
Christian Tismer :^) <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4