In article <web.3dcd9d73195c50e4178f7f9c0@news.povray.org>,
 "normdoering" <nor### [at] yahoocom> wrote:

> True. That only means you can compile the same C code on different compilers
> for different machines. And can you really do that without changing the
> code in some header or include file somewhere?

Not really sure what you are asking, but the core source code does not 
require any modification (if the compiler supports standards well 
enough).


> > Windows has dll's and *nices have .so's etc.
> I don't know anything about "nices have .so's etc."

You weren't very clear about what you didn't understand, but: different 
platforms have very different ways of dynamically loading pieces of 
code, you can't do this in a platform independant way.


> > Plugins compiled on one platform wouldn't work on other.
> So? Versions of POV-ray compiled for Windows don't work on Apples.

So you would have to recompile plugins for different platforms, in 
addition to recompiling the core program. And third party plugins would 
usually only be released on one platform, so they would have to release 
source code anyway.


> It seems code for plugins could be as platform independent as the POV-ray
> code... unless there's something I'm missing. It may be just a matter of
> changing a few header and include files to make the same code work on
> various platforms, same as POV-ray.

If it were so easy, don't you think it would have been done by now? 
Especially after all the discussion and people asking for it?
The source code for a plugin might be nearly platform independant, the 
loading code and compiled plugins would not be.


> True. That's the price of speed. But I don't want be able to modify
> everything, as a user ... besides, I did say plugins would be an easy
> stepping stone toward compiled macros. Once you could do that the plugins
> would become obsolete. Doing a plugin version gets you part way to compiled
> macros that are platform independent because the compiled macro would
> behave just like a plugin.

I don't know why you think "plugins would be an easy stepping stone 
toward compiled macros". They would not be easy, and they wouldn't bring 
POV any closer to having compiled macros. Their limitations outweigh 
their benefits.


> Make headers and include files for the various platforms available like you
> make different compilations of POV-ray available.

You have to make all the source available. The whole thing would usually 
need to be recompiled. And only by a small percentage of users are 
technically experienced enough to do this.


> True. But that's going to be harder to do because you have to write a
> compiler into POV-ray and doing plugins would take care of one part of the
> work, interfacing with a compiled program, and let users find the bugs
> before you did the more complex task of actually writing a compiler.

POV functions already compile to a bytecode representation that is 
interpreted by a VM. It would not be difficult to make a more complex 
language, I've written bytecode compilers and interpreters for 2 
languages, and started a POV patch for one of them. You are 
overestimating the ease of implementing plugins.


> You could simply implement plugins quicker than you could make macros
> compile.

But you can't. Ignoring the fact that macros can't be compiled anyway 
because they are text replacement macros, you can't implement plugins 
without platform dependancy problems (not without using bytecodes, and 
then you lose any advantage of plugins).

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message