QUERIES: Questions about Unanswered Elderly or Recent Issues Eventually Solvable
Leopold Toetsch
the specific implementation of some parts.
Interpreter globals
-------------------
We have real globals (e.g. Parrot_base_vtables, Env) and per
interpreter/thread globals (e.g. classname_hash). I think best is to
have the former attached to the first interpreter and let other
interpreters just point to these.
IO Handles/PMCs
---------------
Are they real globals? What happens if two threads write to STDOUT/to
the same file?
See also:
Subject: [RfC] Semantics of clone for PIO-objects.
PMC methods
-----------
ParrotIO has methods via find_method/invoke. Should that be a general
mechanism in default.pmc with one vtable slot for the meth hash?
Calling Conventions
-------------------
The return value convention needs some more thoughts. While the caller
knows everything about how it calls a sub, it may or may not know, how
the sub passes return values.
Exceptions
----------
I presume internal_exception() should throw a real exception. So the
exception reason should be classified (severity/reason).
Resumable ops and exceptions
----------------------------
For example the C<loadlib> opcode currently PANIC()s, if the library
couldn't be opened. Such opcodes could be changed to throw an exception
on failure and allow resuming on the next opcode.
Related:
Subject: Trapping find_lex failure; case for search_lex?
And of course: Don't Panic!
Vtables
-------
Almost warnocked:
Subject: [RfC] disable unused vtable entries
Vtables 2
---------
Are there any design hints on var/value split of vtables?
Currently in a lot of places the address of the vtable is used to
check if a class is e.g. a PerlInt. This will not work if that is a
tied PerlInt. Other checks are done with vtable->base_type, but a tied
PerlInt will have a different class enum too.
So how will we check for "some PerlInt" class?
What is the subtype? And what are int_type, float_type, num_type,
string_type in the vtable?
Event handling
--------------
Should I rediff and commit [perl #23039] [PATCH] event handling-2
Thanks for wading through this list and any comments and answers.
leo
Dan Sugalski
>This is an unordered list of issues - mainly design questions - about
>the specific implementation of some parts.
>
>Interpreter globals
>-------------------
>
>We have real globals (e.g. Parrot_base_vtables, Env) and per
>interpreter/thread globals (e.g. classname_hash). I think best is to
>have the former attached to the first interpreter and let other
>interpreters just point to these.
The problem with that is that some of the base stuff needs to exist
before there is a first interpreter, which is why it's global.
>IO Handles/PMCs
>---------------
>Are they real globals? What happens if two threads write to STDOUT/to
>the same file?
>See also:
>Subject: [RfC] Semantics of clone for PIO-objects.
Some IO handles are global, yes, especially ones handed to us by code
embedding parrot.
>PMC methods
>-----------
>ParrotIO has methods via find_method/invoke. Should that be a general
>mechanism in default.pmc with one vtable slot for the meth hash?
We're going to want lexially nested method caches, so I don't think
we're going to want to do this. The method hash needs to be living in
the interpreter struct, alas.
>Calling Conventions
>-------------------
>The return value convention needs some more thoughts. While the caller
>knows everything about how it calls a sub, it may or may not know, how
>the sub passes return values.
The caller needs to inspect the return value indicators to see what
it got back. The only potential issue is ordering when a sub returns
mixed types, though we could if we wanted to just forbid that for
right now. It's either that or we have to pass back a return
signature.
>Exceptions
>----------
>I presume internal_exception() should throw a real exception. So the
>exception reason should be classified (severity/reason).
Yep. Internal exceptions are generally pretty severe, but they
certainly aren't all that bad.
>Resumable ops and exceptions
>----------------------------
>For example the C<loadlib> opcode currently PANIC()s, if the library
>couldn't be opened. Such opcodes could be changed to throw an exception
>on failure and allow resuming on the next opcode.
>Related:
>Subject: Trapping find_lex failure; case for search_lex?
>And of course: Don't Panic!
Yes, you're right.
>Vtables
>-------
>Almost warnocked:
>Subject: [RfC] disable unused vtable entries
Not warnocked--leave these in for right now.
>Vtables 2
>---------
>Are there any design hints on var/value split of vtables?
>Currently in a lot of places the address of the vtable is used to
>check if a class is e.g. a PerlInt. This will not work if that is a
>tied PerlInt. Other checks are done with vtable->base_type, but a tied
>PerlInt will have a different class enum too.
>So how will we check for "some PerlInt" class?
>What is the subtype? And what are int_type, float_type, num_type,
>string_type in the vtable?
I'm still working on these, and as part of it I'm trying to come up
with a good way to allow layered vtables that aren't horribly
expensive in terms of memory and time.
>Event handling
>--------------
>Should I rediff and commit [perl #23039] [PATCH] event handling-2
>
That I need to go take a look at. Hold off on it for right now.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Benjamin Goldberg
>
> At 11:06 AM +0200 8/8/03, Leopold Toetsch wrote:
> >PMC methods
> >-----------
> >ParrotIO has methods via find_method/invoke. Should that be a general
> >mechanism in default.pmc with one vtable slot for the meth hash?
>
> We're going to want lexially nested method caches, so I don't think
> we're going to want to do this. The method hash needs to be living in
> the interpreter struct, alas.
There's no reason why the find_method in default.pmc can't do lookups in
the interpreter struct, and then of course the normal method would be to
use find_method.
This way, if a pmc class wants to override the normal find_method, it
can.
For example, PerlObject's find_method could be:
PMC * find_method(STRING *name) {
PMC * perlclass = SELF.getprop(string_from_cstring("class"));
return VTABLE_find_method(INTERP, perlclass, name);
}
Then, PerlClass's find_method might be something like:
PMC * find_method(PMC *key, STRING *name) {
PMC * classname = SELF.get_string();
PMC * lookup = scratchpad_get_current(INTERP);
PMC * method = NULL;
{
STRING * lex_name = string_from_cstring(INTERP, "&", 1);
string_append(INTERP, lex_name, classname);
string_append(INTERP, lex_name,
string_from_cstring(INTERP, "::", 2));
string_append(INTERP, lex_name, name);
method = scratchpad_get(INTERP, lookup, lex_name, 0);
if( method ) return method;
}
lookup = SELF.getprop(string_from_cstring(INTERP, "methods"));
method = VTABLE_get_pmc_keyed_string(INTERP, lookup, name);
if( method ) return method;
lookup = SELF.getprop(string_from_cstring(INTERP, "parent"));
if( !lookup ) return NULL;
return VTABLE_find_method(INTERP, lookup, name);
}
> >Exceptions
> >----------
> >I presume internal_exception() should throw a real exception. So the
> >exception reason should be classified (severity/reason).
>
> Yep. Internal exceptions are generally pretty severe, but they
> certainly aren't all that bad.
Indeed -- consider how default.pmc throws ILL_INHERIT all over the
place... those could be caught.
(Hmm, I think that default.pmc would smaller, and no less clear if we
defined a macro:
#define THROW_ILL_INHERIT(METH) \
internal_exception(ILL_INHERIT, \
"METH" "() not implemented in class '%s'\n", \
caller(INTERP, SELF))
And then use
THROW_ILL_INHERIT(get_number_keyed);
Instead of the more verbose code that's currently there.)
[snip]
> >Vtables 2
> >---------
> >Are there any design hints on var/value split of vtables?
> >Currently in a lot of places the address of the vtable is used to
> >check if a class is e.g. a PerlInt. This will not work if that is a
> >tied PerlInt. Other checks are done with vtable->base_type, but a tied
> >PerlInt will have a different class enum too.
That's why encapsulation is so important. If we had a vtable->isa
method, then it could be overridden however we want.
> >So how will we check for "some PerlInt" class?
> >What is the subtype? And what are int_type, float_type, num_type,
> >string_type in the vtable?
>
> I'm still working on these, and as part of it I'm trying to come up
> with a good way to allow layered vtables that aren't horribly
> expensive in terms of memory and time.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Leopold Toetsch
> Dan Sugalski wrote:
>>
>> At 11:06 AM +0200 8/8/03, Leopold Toetsch wrote:
>[snip]
>> >PMC methods
>> >-----------
>> >ParrotIO has methods via find_method/invoke. Should that be a general
>> >mechanism in default.pmc with one vtable slot for the meth hash?
>>
>> We're going to want lexially nested method caches, so I don't think
>> we're going to want to do this. The method hash needs to be living in
>> the interpreter struct, alas.
> There's no reason why the find_method in default.pmc can't do lookups in
> the interpreter struct, and then of course the normal method would be to
> use find_method.
ParrotIO's methods are hard wired functions implemented in C and called
via our NCI mechanism. So the question is, if we should generalize this
scheme. From pmc/io.t:
set S5, "ok\n"
getstdout P5
find_method P0, P5, "puts"
invoke
end
> This way, if a pmc class wants to override the normal find_method, it
> can.
> For example, PerlObject's find_method could be:
> PMC * find_method(STRING *name) {
> PMC * perlclass = SELF.getprop(string_from_cstring("class"));
> return VTABLE_find_method(INTERP, perlclass, name);
> }
This looks like:
s/perl/python/g; s/class/__class__/;
Anyway, that's up to ParrotClass/ParrotObject. I was thinking of a low
level C<find_method> for all PMCs, with (probably) hard wired methods
like C<isa()>. And these methods should probably not pollute the property
namespace.
> (Hmm, I think that default.pmc would smaller, and no less clear if we
> defined a macro:
> #define THROW_ILL_INHERIT(METH) \
> internal_exception(ILL_INHERIT, \
> "METH" "() not implemented in class '%s'\n", \
> caller(INTERP, SELF))
> And then use
> THROW_ILL_INHERIT(get_number_keyed);
Yep. Actually I'd like to have these autogenerated for all functions
that now throw an exception. We have a list of functions in vtable.tbl,
so classes/pmc2c.pl could provide the function body, if there is none.
default.pmc then would only have functions bodies with "real"
functionality.
Patches welcome.
[ snip ]
> That's why encapsulation is so important. If we had a vtable->isa
> method, then it could be overridden however we want.
We have C<can> and C<does>, yep C<isa> seems to be missing.
leo
Leopold Toetsch
> At 11:06 AM +0200 8/8/03, Leopold Toetsch wrote:
>>This is an unordered list of issues - mainly design questions - about
>>the specific implementation of some parts.
>>
>>Interpreter globals
>>-------------------
>>
>>We have real globals (e.g. Parrot_base_vtables, Env) and per
>>interpreter/thread globals (e.g. classname_hash). I think best is to
>>have the former attached to the first interpreter and let other
>>interpreters just point to these.
> The problem with that is that some of the base stuff needs to exist
> before there is a first interpreter, which is why it's global.
global_setup.c:init_world() is called with the interpreter, that is
under construction. So I don't see a problem to attach real globals to
the first interpreter.
May be I'm totally wrong with my dynamic PMCs patch. But here is what
happend:
dynclasses/foo.c had to be linked against libparrot (which has
e.g. the global Parrot_base_vtables). Now when loading F<foo_pmc.so> we
have 2 of these globals, one inside parrot and one in the shared library.
The init function in the shared lib (and code called from there) sees
the Parrot_base_vtables of the shared lib, which isn't that one, that
shall be extended with the new class. So currently I'm copying these
globals around. OTOH, if these globals where attached to the first
interpreter, they could be reached with interpreter->first_interpreter.
>>IO Handles/PMCs
>>---------------
>>Are they real globals? What happens if two threads write to STDOUT/to
>>the same file?
>>See also:
>>Subject: [RfC] Semantics of clone for PIO-objects.
> Some IO handles are global, yes, especially ones handed to us by code
> embedding parrot.
What about C<std*>. Can you be ++verbose about "Some"?
leo