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

On Fri, 11 Feb 2005 20:11:32 -0600, Thorsten Froehlich wrote:

> This topic is just a dead end discussion as you
> won't get plug-ins in any official POV-Ray

Please pardon my butting in here, all due respect to you and the POV-Ray
team (been a user of the software for years, like many here I remember
DKBTrace and the running the early releases of POV on a 386 - in fact, I
bought a 387 coprocessor specifically for running POV), but just because
the feature won't appear in an official POV-Ray build, is there any harm
in those who are interested discussing the possibilities for an unofficial
build?

And if they managed to pull it off somehow, isn't there at least the
potential that at that time someone from the POV-Ray team might consider
it a valuable addition to the existing code?

I don't have all the history on the discussions on the topic in the past,
but I really don't understand why there is such apparent hostility towards
even the idea of discussing the possibility of how such an extension might
be accomplished.

If anything, for those who are either not familiar with
cross-platform coding practices and those not as familiar with the POV-Ray
code as you are certainly could learn a lot from the exercise of examining
this aspect of the code.

Just MHO, of course.

Jim

Post a reply to this message

Jim Henderson wrote:
> the feature won't appear in an official POV-Ray build, is there any harm
> in those who are interested discussing the possibilities for an unofficial
> build?

It is not up to me or anybody else how others waste their time, you just 
have to face the fact that it will never be added to an official version and 
as such it is a waste of time.  You are also free to write your own 
ray-tracer or whatever else you like doing during your free time.

> And if they managed to pull it off somehow,

This will not happen.  All you will ever get is some hack.  In fact such a 
hack has existed before in some ancient isosurface code.  The fact that 
nobody supports it any more should tell you something.

 > isn't there at least the
> potential that at that time someone from the POV-Ray team might consider
> it a valuable addition to the existing code?

No, it is certainly not going to be considered for all he reasons outlined 
so many times in the past and for the millionth time in this thread.

	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

Warp wrote:
>   Now, would you care to explain how this basically simple plugin
> ideology could be embedded into POV-Ray?

Isn't that what macros are for?  O.o;

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message