Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Where exactly would you put those lines and what would they do? What will
> > the library contain and where exactly should POV-Ray call the functions
> > in those libraries? Exactly what kind of interface should POV-Ray offer
> > to those libraries and what would they do? How would you write such a
> > library to do what you want? How could you use such library to add a
> > new feature (eg. a new primitive or a new pattern) to POV-Ray?

> Alright, so to get specific, *I* would add a preprocessor directive, 
> that says "the function named X is implemented at offset Y in library 
> Z."  Then POV-Ray, while interpreting the code, when it sees a call to 
> the function X, when it does its normal look-up, would find that it's 
> implemented in the DLL/SO, would load same, and invoke the specified 
> offset, with arguments matching the pattern of arguments supplied in the 
> declaration. Note, this is all pretty bog-standard stuff. :-)

  Perhaps you have reading comprehension difficulties?
  I asked "where?", not "how?".

  And even your answer to "how?" is obscure. Which "function named X"?
POV-Ray has thousands of functions and functionalities. Which one of
them could be overridden by the dll? If you are talking about a whole
new function, where exactly should POV-Ray call that function and
what it should give to it and what it should expect as a result?
What will be the feature the dll will be implementing (and why that
exact feature and not the tons of others in POV-Ray)?

> >   How would you make sure that the library is compilable in all platforms?

> If it only needs an entry point and an exit point, you could provide a 
> wrapper for it that is OS-specific. So for example POV-Ray comes with 
> code that is system-specific and which invokes the external function 
> "MyFunction" or some such. Again, this isn't *difficult*. It just needs 
> to be written.

  You still fail to answer the relevant questions: *Where* should POV-Ray
call these functions and what will they be doing?

  You seem to talk as if plugins where some kind of magic: You just
"plug them in" and they magically add a new feature to the program.
  A patch is exactly that: You merge it to the existing code, recompile
and presto, we have a completely new feature. However, a dll plugin does
not (and simply cannot) work like this because it can't modify the existing
code nor magically insert itself wherever it pleases. The core code needs
to support it specifically for a certain given task. So my question remains:
Where should POV-Ray call the functions in the dll and what will these
functions do?

> Or, as in Tcl, the DLL MyCode.dll has an entry point called 
> InitMyCode(), which registers in the internal tables of the interpreter 
> the names and calling conventions of its functions.

  That sounds to me more like scripting language extensions.
  POV-Ray is more than a scripting language interpreter. How do you
expect to add new rendering features (or modify existing ones) with
just a scripting language extension?

> (Or... compile stuff into some intermediate code and write a JIT for the 
> final step, if you *really* want to. This is *all* solved problems.)

  Now we are starting to go to the right direction:
  Not binary dlls. Scripting language.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message