Leopold Toetsch wrote:
Sam Ruby wrote:
Before this line is executed,
(gdb) p interpreter->ctx.bp $1 = (struct parrot_regs_t *) 0x40b6bd88
After the above line is executed:
(gdb) p interpreter->ctx.bp $2 = (struct parrot_regs_t *) 0x40b6bae8
Then is obviously your implementation of get_repr broken.
Two questions come to mind:
1) Should this call to run_meth change the context?
Yes because a subroutine is run. But returning from it via a (return-) continuation restores the context and the register frame pointer or it ought to.
... In this case, repr happens to be a Closure based on some assumptions I made early on in this process that I need to revisit. Arguably, this is a bug, but in the general case, can one always assume that the context does not change?
Only function calls / returns may change the context. A simple opcode like get_repr isn't allowed to do that.
The question isn't about what opcodes are or are not allowed to do. The question is what VTABLE_* functions are or are not allowed to do. Can VTABLE_invoke change the context? How about VTABLE_get_string?
If you look at the current delegate PMC, every VTABLE call is translated to a call of a method. Are such methods allowed to change the context?
What are the rules?
Note: if the context is not supposed to change as a result of runops, perhaps an internal exception should be thrown.
We can't check that on each opcode. That just must not happen :)
I mustn't have been clear.
If things invoked by runops are not allowed to change the context, then runops should throw an internal exception if the context changes.
On the other hand, if runops can't change the context, then why is runops_args careful to capture the context prior to calling runops?
Again, what are the rules?
But before you implement more and more methods I'd rather have inheritance and method calling conventions fixed. Parrot should call the approriate method if it exists in the class namespace (if find_method did return something).
How I chose to invest my time is up to me. If all that comes of it is the few minor contributions I have made to the core of Parrot... then I will be OK with that.
In most cases, I think I could adapt to a change in a matter of minutes. You've seen me clone classes like BigInt and Complex wholesale, only to gut them back once I had some partial ability to inherit MMD methods.
In the worst case, adapting to a major change would be a matter of days. Again, my time to burn. Also, if you note, I am only writing the minimum necessary to pass the given set of tests. That way there is less for me to change when things change.
The reason why I am proceeding this way is that I found the previous discussions on topics like object, classes, and metaclasses to be frustrating. I want the next round to be based on specifics.
In particular, I don't want to have to respond to statements like "It doesn't buy us anything, if we force all languages to create wrappers.". I want to be able to point at a specific wrapper and ask the question: how could it be done better?
Parrot_PyClass_get_repr is one such wrapper. How could it be done better? If you make a specific suggestion there, I'll either adopt it or produce a test case as a counter example.
- Sam Ruby
