> I would like to ask why this would be not portable? Any platform POVRay 
> runs on should support dynamic loading.

  Show me the C++ code which performs loading of dynamically linked
libraries in any platform.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

> Thorsten Froehlich schrieb:
> 
>> verjigorm wrote:
>>
>>> Yes, I already downloaded the code. Just wanted to check if any 
>>> extension
>>> already exists and if a feature like library support is going to be 
>>> added
>>> some day.
>>
>>  > Sounds like a good idea to me, you know like in MATLAB for instance.
>>
>> No, it is an extremely bad idea as it is not portable and all this has 
>> been explained several times in these groups.  It is never going to be 
>> added to any official version of POV-Ray.
> 
> 
> I would like to ask why this would be not portable? Any platform POVRay 
> runs on should support dynamic loading. Or does POVRay compiles under 
> plain DOS?

Not sure if in there completely, but certainly searching further would 
reveal some of the even older threads about the very same topic:

<http://news.povray.org/povray.programming/thread/%3Cweb.3dc175b4282cec51d2ac4d730%40news.povray.org%3E/>

Please lets not have the same disscussion over and over again.  Just Google 
for something like

site:news.povray.org povray.programming plugin

and you get enough hits with thread about this topic.

	Thorsten

Post a reply to this message

Warp wrote:

> 
>>I would like to ask why this would be not portable? Any platform POVRay 
>>runs on should support dynamic loading.
> 
> 
>   Show me the C++ code which performs loading of dynamically linked
> libraries in any platform.

More important: Show that every potential user of POV-Ray on even just there 
three officially supported platforms has a C/C++ compiler to compile the 
plug-ins not available for this platform.  And don't get me started about 
platform-specific plug-ins.  This whole discussion always ends up in the 
same obvious points getting mentioned, and I really fail to see why so many 
people don't first try to think about the potential problems (when they are 
told there are problems) rather than expecting them to be spoonfed to them 
<sigh>

	Thorsten

Post a reply to this message

Warp schrieb:

>> I would like to ask why this would be not portable? Any platform POVRay 
>> runs on should support dynamic loading.
> 
>   Show me the C++ code which performs loading of dynamically linked
> libraries in any platform.

Not on any. The platform has to support dynamic loading. If POVRay also 
compiles on plain old DOS than this feature will not be possible. But on 
all others:


#ifdef WIN32
     LoadLibrary("foo.dll");
#endif

#ifdef LINUX
     dlopen("bar.so", some_mode );
#endif

#ifdef SOMEOTHEROS
    loadsoordllonthisosfunction("foo.bar");
#endif

OK. Thats not complete but I don't see a problem there which can not be 
solved. Others can do this too.

-- 

mat### [at] matweide
http://www.matwei.de

Post a reply to this message

Thorsten Froehlich wrote:

> ends up in the same obvious points getting mentioned, and I really fail 
> to see why so many people don't first try to think about the potential 
> problems (when they are told there are problems) rather than expecting 
> them to be spoonfed to them <sigh>

<cynic mode>
Sorry for interrupting your little flame war here. But I just wanted to 
say that I really love to see people who only see problems and refuse to 
see solutions.
;-)
</cynic mode>

Post a reply to this message

>>
>>   Show me the C++ code which performs loading of dynamically linked
>> libraries in any platform.
> 
> 
> Not on any. The platform has to support dynamic loading. If POVRay also
 
> compiles on plain old DOS than this feature will not be possible. But o
n 
> all others:
> 
> 
> #ifdef WIN32
>     LoadLibrary("foo.dll");
> #endif
> 
> #ifdef LINUX
>     dlopen("bar.so", some_mode );
> #endif
> 
> #ifdef SOMEOTHEROS
>    loadsoordllonthisosfunction("foo.bar");
> #endif
> 

None of the variants is standard C++.  And note you won't find any such 
port to specific platforms in the POV-Ray core code - it is portable per 

se because it complies with the standard and does not need to be ported.

Also note the #ifdef LINUX is incorrenct because only some of the 
various flavours of Linux support this.

This whole thread is - like its predecessors - completely pointless 
because it lacks examples what such a feature can be useful for that 
won't be better solved with a different technique.  I don't know any 
(and don't come up with nonsense like 'controlling Excel from a POV-SDL 
script').

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Maurice wrote:
> <cynic mode>
> Sorry for interrupting your little flame war here. But I just wanted to 
> say that I really love to see people who only see problems and refuse to 
> see solutions.
> ;-)
> </cynic mode>

No, it is a matter of experience.  Would you go to your local car mechanic 
and ask him to attach wings to your car?  You don't (I hope) because you 
know that would not give you a flying car and in general be useless.  Of 
course there is a solution even to getting a car to fly, but how feasible is it?

Either way, the real point here is that this whole discussion is *pointless* 
and I would really wish people would just for once not argue over something 
they so obviously do not understand.  After having had the same discussion 
for the 10th time in five years, it is only annoying, nothing else.

	Thorsten

Post a reply to this message

> #ifdef WIN32
>      LoadLibrary("foo.dll");
> #endif

> #ifdef LINUX
>      dlopen("bar.so", some_mode );
> #endif

> #ifdef SOMEOTHEROS
>     loadsoordllonthisosfunction("foo.bar");
> #endif

  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?
  How would you make sure that the library is compilable in all platforms?
How would you handle scene files which are eg. windows-only because only
the windows-version of the library has been provided?

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

Darren New <dne### [at] sanrrcom> wrote:
> Since the owners of POV-Ray have said they're not going to do it anyway, 
> is there a point in answering all these questions?

  The point is that if people stopped thinking only like "I want plugins,
plugins are cool" and started to think how these plugins should work,
what their interface (in C++ terms) should be, where exactly should the
core code call these plugins and what should the core code offer these
plugins, how the core code should implement the things to offer to the
plugins and so on, they could perhaps start realizing that "adding
support for plugins" is not just a question of laziness nor even of
portability (even though portability is an important issue as well).
  Just to present an example: How exactly should the core code be modified
and which kinds of interfaces should it offer to the plugins so that the
plugins could create new primitives, new patterns, new texture properties,
and even completely new features unrelated to anything else already
existing in the core?

> Or is your point that 
> there's no possible answer to these questions, in spite of there being 
> plenty of highly portable systems that do allow such things? Just 
> curious, really. :-)

  Usually dll plugins in windows programs perform one single isolated task
which is very well defined. Let's take for example a Winamp DSP effect
plugin: The concept is rather simple. There's probably a function or two
which winamp calls and which the dll implements. These functions get a
well-defined raw sample which the function can modify and then just 
return to the caller. And that's it.
  How about a photoshop filter? There's probably one function in
the dll which photoshop calls which is of the kind "here is the
raw image, do whatever you want with it". Then the function in question
does something to it and returns. And that's it.

  Now, would you care to explain how this basically simple plugin
ideology could be embedded into POV-Ray? Where exactly should POV-Ray
call what? Should there perhaps be a dll function call for each one of
the hundreds or thousands of features POV-Ray performs so that the
dll plugin could affect it? For example, should POV-Ray make a dll function
call for each ray it shoots, for each color it computes, for each
media sample interval it calculates, for each radiosity sample it
computes, for each photon ray, for each parsed token, for each
primitive created, for each transformation parsed... The list could
go forever. There would be literally thousands of functions being
called, cluttering and adding overhead. I think you get the idea.

  So once again: How exactly should the plugin engine be implemented?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Darren New wrote:
> horribly impossible

Nobody said anything in that regard.  You are confused, please stop 
spreading confusion.  This topic is just a dead end discussion as you won't 
get plug-ins in any official 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