1) There is a new opcode new Px, Sc:
new P0, "PyInt"
2) If the given class doesn't yet exist, Parrot_autoload_class is called
which has hardcode mapping for "Py" => "python_group", "Tcl" =>
"tcl_group". A bit hackish but working ...
3) The pybuiltin.__load__() function is automatically called
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I don't understand this. At all. But the test case added to pyclass.t
(motivated by test 4 in pie/b3.t) only passes if this change to the
get_repr op is made.
[ ... ]
-op get_repr(out STR, in PMC) {
-$1 = $2->vtable->get_repr(int
Leopold Toetsch wrote:
Sam Ruby wrote:
A few observations, first from an Parrot Internal perspective... in
general, the code for the opcodes tend to do things like the following:
$1->vtable->get_string(interpreter, $1)
Note that the object tends to be repeated as the first argument. It
often th
Leopold Toetsch wrote:
Sam Ruby wrote:
Leopold Toetsch wrote:
cvsuser 04/12/15 02:36:29
Modified:.vtable.tbl
Log:
stub in object vtables
[snip]
+void add_parent(PMC* parent)
+void become_parent(PMC* class)
+INTVAL class_type()
+void add_method(STRING* method)
+void r
Leopold Toetsch wrote:
Sam Ruby wrote:
Leopold Toetsch wrote:
+inline op get_repr(out STR, in PMC) {
+STRING *s = $2->vtable->get_repr(interpreter, $2);
+$1 = s;
goto NEXT();
}
Strange. Stranger. Strangest. Did the test fail with JIT/i386 only?
I didn't mean to commit the "inline
Sam Ruby wrote:
Developers could declare such a dependency
with a IMCC macro, something like this:
.lib python_group
That could be
.class_mapping "Py", "python_group"
OTOH when the classes are built in dynclasses, we can as well hard-code
the entries. We'll see.
This would enable JITs to
Sam Ruby wrote:
Leopold Toetsch wrote:
class_self."__super"(args)
so again the invocant is the first argument after interpreter.
Believe it or not, I think we are agreeing.
*g*
To invoke a method on an object using Parrot Calling Conventions, P2
needs to be the object used for dispatch purposes
Sam Ruby wrote:
My need is to be able to call add_method for methods defined as @ANON.
This doesn't make sense to me. The @ANON pragma avoids the add_method
(or store_global) call in the first place.
From the perspective of Parrot, namespaces should be viewed a perfectly
reasonable mechanism fo
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 c
Leopold Toetsch wrote:
Sam Ruby wrote:
My need is to be able to call add_method for methods defined as @ANON.
This doesn't make sense to me. The @ANON pragma avoids the add_method
(or store_global) call in the first place.
I don't want the method added to a namespace, or stored as a global. I
wa
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
Sam Ruby wrote:
This doesn't make sense to me. The @ANON pragma avoids the add_method
(or store_global) call in the first place.
I don't want the method added to a namespace, or stored as a global. I
want it stored as a property of a class object.
I presumed that ;) Well, due to the described p
Sam Ruby wrote:
Leopold Toetsch wrote:
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
V
pseudo-code for runops_args:
runops_args(PMC* sub, char* sig, va_list ap) {
dest = VTABLE_invoke(interpreter, sub, NULL);
REG_*[*] = ap[*], as appropriate
if (dest) runops
}
However, VTABLE_invoke on NCI methods is where the "real work" is done
(including reading from and writing t
Leopold Toetsch wrote:
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.
You'd need in pyclass.pmc:
PMC* get_repr() {
return pmc_new_string( ... "")
}
Ju
Leopold Toetsch wrote:
Python classes are not namespaces. Nor are they global. They are
dictionaries.
Or, the view is a dictionary-like. The dict is CPython's implementation.
I can imagine that Parrot's class namespaces work as well.
Are namespaces subject to garbage collection? Classes may be
Leopold Toetsch wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
Leopold Toetsch writes:
Why do we have the special notion of current_object in the first place?
Why not just pass all in as P5, P6, ...?
I agree that this is the way to go. Especially if we have some marker
somewhere that tells us that
Sam Ruby wrote:
Leopold Toetsch wrote:
+inline op get_repr(out STR, in PMC) {
+STRING *s = $2->vtable->get_repr(interpreter, $2);
+$1 = s;
goto NEXT();
}
Strange. Stranger. Strangest. Did the test fail with JIT/i386 only?
I didn't mean to commit the "inline" portion of the chan
Sam Ruby wrote:
A few observations, first from an Parrot Internal perspective... in
general, the code for the opcodes tend to do things like the following:
$1->vtable->get_string(interpreter, $1)
Note that the object tends to be repeated as the first argument. It
often the case that the first a
Leopold Toetsch wrote:
1) There is a new opcode new Px, Sc:
new P0, "PyInt"
2) If the given class doesn't yet exist, Parrot_autoload_class is called
which has hardcode mapping for "Py" => "python_group", "Tcl" =>
"tcl_group". A bit hackish but working ...
Perhaps longer term, a change to the p
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 11:13 AM +0100 12/14/04, Leopold Toetsch wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>
>>> subclass - To create a subclass of a class object
>>
>>Is existing and used.
>
> Right. I was listing the things we need in the protocol. Some of the
Leopold Toetsch wrote:
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?
C is a low-level function that awaits all properly setup. Around
that are more function that e.g. create a return continuation and do
argu
22 matches
Mail list logo
