Christopher James Huff wrote:
> In article <pan### [at] NOSPAMml1net>,
>  Tyler Eaves <tyl### [at] NOSPAMml1net> wrote:
>>8. A C(++) API
>>    This is another way of acheiving some of the above speed-related 
>>    goals. Allowing creating a pov-scene by linking against the API,
>>    giving code that builds a binary to render the scene. The ultimate
>>    for CPU intensive stuff.
> 
> 
> Not practical. There is no standard way of loading object code on 
> different platforms, and the code itself would have to be compiled for 
> the platform the scene is to be rendered on. Including a compiler along 
> with POV would be a lot of effort, and distributing precompiled code 
> would create compatibility problems.

You know this one as always bugged me, the whole not practical thing.

For a guess the library author would have a compiler and it only takes
on willing person per platform to compile it for others. So that not to 
much of a problem really. The lack of a complier would only effect
people want to use a libraries features for a platform that one one has 
complied it for which is no different to those who want to use a 
Unofficial version of Pov in the same scenario.

The object code loading thing. Yes there is no standard way to do this, 
so you create one. All You'd need to do is pull back a C++ object so it 
does not need to be to complex does everything dlopen can do API. Simply 
wrap dlopen and LoadLibrary and that would cover Linux, Mac OSX and 
Windows.
something like

#define dsoOpen(x) dlopen(x, RTLD_NOW);
#define dsoGetSymbol(x,y) dlsym(x, y)
#define dsoError()  dlerror()
#define dsoClose(x)  dlclose(x)

and windows ...

#define dsoOpen(x) LoadLibrary(x)
#define dsoGetSymbol(x,y) GetProcAddress((HINSTANCE )x, y)
#define dsoError()  GetLastError()
#define dsoClose(x)  FreeLibrary(x)

If anything more fancy is required for other OS's then that
platform's dso* code become actual functions. The Mac
version could use the CFBundles? stuff directly for example.


The library exports functions that return a new instance
of a class, which inherits from a predefined povray class.
You could have a povFunction classes which return a float,
povPigment classes that return rgbft etc or one class which
has evaluateAsFloat, evaluateAsPigment etc methods

void *perlins_noise(void){
     return new myPerlinFunctionClass();
}

There will need to be extensions to SDL to..

Load the library,
Identify the class required and its type if there are different classes 
     for different functionality,
Pass the parameters to a 'setParmaters' method. Perhaps something like a 
color_map using keyed pairs.

dso {
  function
  "/path/to/library"
  "perlins_noise"
  parameter_map {
    ["octaves" 6]
    ["frequency 2.0]
  }
}

All the code is from memory so I may have got the function names or 
usage wrong, but I can't see why it wouldn't work from a technical point 
of view.

Dave

Post a reply to this message

In article <405b1638@news.povray.org> , David Burnett <var### [at] ntlworldcom>
wrote:

> You know this one as always bugged me, the whole not practical thing.

This whole issue of plug-ins has been beaten to death years ago.  No kind of
compiled plug-in system is going to be added to POV-Ray, period.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Fri, 19 Mar 2004 18:55:23 +0100, Thorsten Froehlich wrote:

> In article <405b1638@news.povray.org> , David Burnett <var### [at] ntlworldcom>
> wrote:
> 
>> You know this one as always bugged me, the whole not practical thing.
> 
> This whole issue of plug-ins has been beaten to death years ago.  No kind of
> compiled plug-in system is going to be added to POV-Ray, period.
> 
>     Thorsten

Why would plug-ins have to be *compiled*? Why not embed something like,
say, Lua, or going a bit more heavyweight a language like Python or even
Lisp?

Post a reply to this message

Darren New wrote:
> Tyler Eaves wrote:
> 
>> Why would plug-ins have to be *compiled*? Why not embed something like,
>> say, Lua, or going a bit more heavyweight a language like Python or even
>> Lisp?
> 
> 
> What would this gain you over using the SDL?
> 

Functions that can be more than one line. I'm guessing
that would be number one on the list.

Personally I'd love to see parrot used so you could pick
from a range of languages.

Dave

Post a reply to this message

Thorsten Froehlich wrote:

> In article <405b1638@news.povray.org> , David Burnett <var### [at] ntlworldcom>
> wrote:
> 
> 
>>You know this one as always bugged me, the whole not practical thing.
> 
> 
> This whole issue of plug-ins has been beaten to death years ago.  No kind of
> compiled plug-in system is going to be added to POV-Ray, period.

I didn't say it should, I just said I was bugged by the reason's
given.

Having said that, there's no reason why an unofficial version
shouldn't give it a shot.

Dave

Post a reply to this message

On Fri, 19 Mar 2004 12:51:31 -0800, Darren New wrote:

> Tyler Eaves wrote:
>> Why would plug-ins have to be *compiled*? Why not embed something like,
>> say, Lua, or going a bit more heavyweight a language like Python or even
>> Lisp?
> 
> What would this gain you over using the SDL?

Performance. (Compared to SDL anyways)
Extensibility 
Data structures
Nicer syntax

Post a reply to this message

In article <pan### [at] NOSPAMml1net>,
 Tyler Eaves <tyl### [at] NOSPAMml1net> wrote:

> Why would plug-ins have to be *compiled*? Why not embed something like,
> say, Lua, or going a bit more heavyweight a language like Python or even
> Lisp?

No reason. In fact, such a mechanism is already in place. What do you 
think include files are?

-- 
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

In article <405b66f8@news.povray.org>,
 David Burnett <var### [at] ntlworldcom> wrote:

> Functions that can be more than one line. I'm guessing
> that would be number one on the list.

Then change functions to allow more complex constructs. Lua and Python 
would be too slow for most of the things functions are used for anyway. 
The POV-Ray scene description language does some pretty specialized 
things...ever try to describe a scene in another programming language? 
Gets messy, fast.


> Personally I'd love to see parrot used so you could pick
> from a range of languages.

None of them being very well suited to the task. I think improving 
POV-Ray's language would be a better approach.

-- 
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

In article <405b1638@news.povray.org>,
 David Burnett <var### [at] ntlworldcom> wrote:

> For a guess the library author would have a compiler and it only takes
> on willing person per platform to compile it for others. So that not to 
> much of a problem really. The lack of a complier would only effect
> people want to use a libraries features for a platform that one one has 
> complied it for which is no different to those who want to use a 
> Unofficial version of Pov in the same scenario.

Except that unofficial versions are relatively few, and the source code 
is guaranteed to be available. As you mention, library loading can be 
abstracted and two implementations would cover almost every user, but 
the result will be a lot of plugins being distributed as binaries for 
just one platform, people trying to use plugins for other platforms and 
asking why it doesn't work, and so on. The main reason against it is the 
support headaches.

There is also a small security issue...if any scene could load and run 
code from a plugin included with it, it would be easy to write a trojan. 
If this were done with an unofficial version, word would get around 
quickly, but it could be a big problem when it can be done with 
individual plugins and scenes. You'd need an option to have POV only 
load plugins from certain specified locations, similarly to the file I/O 
restrictions.

-- 
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

On Fri, 19 Mar 2004 16:52:37 -0500, Christopher James Huff wrote:

> 
> Then change functions to allow more complex constructs. Lua and Python 
> would be too slow for most of the things functions are used for anyway. 
> The POV-Ray scene description language does some pretty specialized 
> things...ever try to describe a scene in another programming language? 
> Gets messy, fast.

Take a look at psyco. It's essentially a JIT compiler for Python. For
really mathy stuff speed is often not that far from C.

Post a reply to this message