At 4:49 PM +0200 8/9/02, Josef Hook wrote:
> > > If putting all the code into matrix.pmc is going to be a problem
>
>I see another problem coming up which i dont have the exact solution to.
>How are we going to fit operations like
>det() ludcmp() inverse() solve() transp() and others into vtable.
>By that i dont mean that they should exist in vtable, but that
>they must be placed in functions in the existing vtable.
>
>(Q) What vtable function should we call to get determiant?
>(A) get_integer() is quite nice. Calling set I0,P0 and get determinant
>value..
>(Q) What vtable function ...... to get inverse?
>(A) Now this one is really tricky. As i see it there isnt any suitable
> vtable function for this. How are we going to solve
> this?
>
>I believe we need a generall interface for accesess on "custom"
>pmc function. Functions should also be accessable to ops...
I think for these you have two choices:
1) Bind the ops to the PMC implementation and just peek under the hood
2) Make method calls and have the PMCs do what they need to.
#1 requires a way to load up PMC classes along with supporting opcode
libs and parrot bytecode libs, which is infrastructure we've not got
defined yet.
#2 is slow. Yech.
So, then, we need #1. Which needs some infrastructure, as well as the
capability to have multiple bytecode segments and sub loading in the
bytecode. So I think it's time to start defining more stuff. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
