Mark Hammond wrote:
yes I'm happy - chris
You should be! So how come nobody else is <wink/frown>?
(to Tim) I believe this comes simply since following me would force people to change their way of thinking. I am through this already, but it was hard for me. And after accepting to be stackless, there is no way to go back. Today I'm wondering about my past: "how could I think of stacks when thinking of programs?" This is so wrong. The truth is: Programs are just some data, part of it called code, part of it is local state, and! its future of computation. Out, over, roger. All the rest is artificial showstoppers.
Im a little unhappy as this will break the Active Debugging stuff - ie, the ability for Python, Java, Perl, VBScript etc to all exist in the same process, each calling each other, and each being debuggable (makes a _great_ demo :-)
Im not _really_ unhappy, Im just throwing this in as an FYI.
Well, yet I see no problem.
The Active Debugging interfaces need some way of sorting a call stack. As many languages may be participating in a debugging session, there is no implicit ordering available. Inter-language calls are not made via the debugger, so it has no chance to intercept.
So the solution MS came up with was, surprise surprise, the machine stack! :-) The assumption is that all languages will make _some_ use of the stack, so they ask a language to report its "stack base address" and "stack size". Using this information, the debugger sorts into the correct call sequence.
Now, I can give it a machine stack. There is just a frame dispatcher sitting on the stack, and it grabs frames from the current thread state.
Indeed, getting this information (even the half of it I did manage :-) was painful, and hard to get right.
I would have to see the AX interface. But for sure there will be some method hooks with which I can tell AX how to walk the frame chain. And why don't I simply publish frames as COM objects? This would give you much more than everything else, I guess. BTW, as it is now, there is no need to use AX debugging for Python, since Python can do it alone now. Of course it makes sense to have it all in the AX environment. You will be able to modify a running programs local variables, its evaluation stack, change its code, change where it returns to, all is doable. ...
Bit I also understand completely the silence on this issue. When the thread started, there was much discussion about exactly what the hell these continuation/coroutine thingies even were. However, there were precious few real-world examples where they could be used. A few acedemic, theoretical places, but the only real contender I have seen brought up was Medusa. There were certainly no clear examples of "as soon as we have this, I could change abc to take advantage, and this would give us the very cool xyz"
The problem was for me, that I had also no understanding what I was doing, actually. Implemented continuations without an idea how they work. But Tim and Sam said they were the most powerful control strucure possible, so I used all my time to find this out. Now I'm beginning to understand. And my continuation based coroutine example turns out to be twenty lines of Python code. Coming soon, after I served my whining customers.
So, if anyone else if feeling at all like me about this issue, they are feeling all warm and fuzzy knowing that a few smart people are giving us the facility to do something we hope we never, ever have to do. :-)
Think of it as just a flare gun in your hands. By reading the fine print, you will realize that you actually hold an atom bomb, with a little code taming it for you. :-) back-to-the-future - ly y'rs - chris -- Christian Tismer :^) <mailto:tismer@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