[DGD]EPP 2.0

[Ludger Merkens]

On Thu, 9 Mar 2000, Felix A. Croes wrote:

> "Jason Cone" <jcone at uscdev.com> wrote:
> 
> > From: "Felix A. Croes" <felix at dworkin.nl>
> >
> >[...]
> > > This comes up every now and then.  I am not sure if it is simply too
> > > difficult to add kfuns -- perhaps I should write a doc? -- or if there
> > > really is a good reason for linking to C code in another way.
> >
> > Well, no matter the end result of this discussion, adding a fairly detailed
> > document on how to extend the driver is a _great_ idea.
> 
> Okay.  Things have gotten more regular recently, with the addition
> of macros for common stack manipulations, which will make writing
> new kfuns easier.
> 
> 
> >[...]
> > I'm not an advocate of creating a pure "inside-to-outside" bridge (a la, a
> > single kfun to call any external function -- there are too many OS-specific
> > issues to deal with there), but rather the ability to extend DGD at
> > run-time.
> 
> I can see why you want this, but I don't like it; such an addition
> would make DGD a lot less portable.  I especially fear for a lot of
> Unix platforms which at present I can treat as identical.  To a lesser
> extend, I also dislike the idea of kfun modules being developed that
> work on one platform only.
> 
> I propose a compromise:
> 
> I will add functionality to the code of DGD which allows for the
> addition of kfuns, and perhaps other things, at runtime.  I will only
> implement the interface, and leave out the platform dependent code.
> I document this interface in the kfun doc mentioned above.  Others can
> now write platform-dependent module load functionality which will have
> to be compiled together with the driver; but once compiled, arbitrary
> modules can be added to DGD at runtime without recompiling DGD.
> 

Hmm, thats much more than I had in mind when I wrote my statement about
calling c-functions from dgd. All I had in mind was a clean (and
well documented) interface that should allow to add a class written
entirely in C at compile time to dgd similar to a prcompiled LPC function
bound to dgd with dgd's prcompile feature. Of course destruct or
compile_object would not work on such a class. I wanted some support to
package functions written in the style of a kfun, some functions or
macros, or even a compiler that automates the necessary c-lpc data/stack
conversion. The result should have been a class which could be 
>>inherited<< from any lpc class. The only difference to writing a new 
kfun would be that there is no need to patch the driver and populate the
kfun table with lots of new functions. 

Platform dependend code to call function from .o, .so .dll files was not
what I had in mind. As well as I don't have an idea how to handle the
data/stack conversion problem with such libraries.


Ludger


List config page:  http://list.imaginary.com/mailman/listinfo/dgd