normdoering <nor### [at] yahoocom> wrote:
>> Windows has dll's and *nices have .so's etc.

> I don't know anything about "nices have .so's etc."

  "*nices" is a kind of geek-word meaning "unix operating systems".
In them dynamically linkable libraries use the .so format (which is
different from the .dll format used in windows, even though for the
exact same purpose).

> It seems code for plugins could be as platform independent as the POV-ray
> code...

  The problem is not the plugin code. The problem is how POV-Ray will read
this plugin binary and link it dynamically to itself. This can't be done in a
platform-independent way.

  Even if a plugin system was implemented, it would certainly need serious
and thorough changes to the POV-Ray code. Probably too much for a simple
patch.

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

  That's not enough for a plugin system. It's not only the headers, you need
also some actual C++ code to handle the plugins. This code can't be done
in a portable way.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

normdoering <nor### [at] yahoocom> wrote:
> Meaning the platform independent philosophy you guys have is standing in the
> way of writing faster and more efficient program.

  POV-Ray is not slower and less efficient because it does not support
plugins. It simply does not support plugins, that's it.

  You can try to add plugin support for POV-Ray if you want. Good luck. ;)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

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

> Meaning the platform independent philosophy you guys have is standing in the
> way of writing faster and more efficient program.

Meaning you don't know anything about what you are talking about. 
Plugins would not make POV faster or more efficient. They would not add 
much at all, except for a lot of platform dependant headaches.

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

Christopher James Huff wrote:
>In article <web.3dcd9f8b195c50e4178f7f9c0[at]news.povray.org>,
> "normdoering" <nor### [at] yahoocom> wrote:
>
>> Meaning the platform independent philosophy you guys have is standing in the
>> way of writing faster and more efficient program.
>
>Meaning you don't know anything about what you are talking about.
>Plugins would not make POV faster or more efficient. They would not add
>much at all, except for a lot of platform dependant headaches.

I'm confused. Are you saying a macro that was translated into C code and
compiled wouldn't parse the same size arrays much faster? I know that's not
true. I've done a limited bit of 2D and 3D array coding in C and parsed
larger arrays, written in text, translated to floats, doing more complex
math much faster than POV is parsing the HF_ macros.

Where is the slow down coming from?

Why wouldn't a compiled pluggin go much faster than an interpreted macro?

normdoering

Post a reply to this message

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

> I'm confused. Are you saying a macro that was translated into C code and
> compiled wouldn't parse the same size arrays much faster?

Correct. First, a macro can't be compiled, it's a macro, it operates at 
parse/compile time. You can easily write things that can't be translated 
to C functions.
POV functions could be compiled, and are...to bytecodes run by a VM. 
They are fast enough to use as patterns and as functions for 
isosurfaces, and probably aren't as fast as they could be.


> I know that's not
> true. I've done a limited bit of 2D and 3D array coding in C and parsed
> larger arrays, written in text, translated to floats, doing more complex
> math much faster than POV is parsing the HF_ macros.

Yes, compiled C code is faster than the directly interpreted POV code. 
It would also be faster than an virtual machine running compiled 
bytecode, though not by anywhere near as much. For most things, a VM 
will be fast enough, patching the source code could be done if it isn't.

For the last time:
Plugins would not bring POV any closer to "compiled macros", either a VM 
or native machine code. I don't know why you think it would.

Compiling scene files to native machine code is a bit ridiculous. It is 
completely platform dependant, adds a huge amount of complexity, and 
adds speed where it is needed least. However, a VM could include hooks 
for translating to native code where needed, without breaking 
portability of the core code.

Plugin loading code would not be portable. You either have chunks of 
core code that need to be rewritten for each platform, making porting 
much harder, or you end up with a situation where some POV versions just 
don't support plugins.

Plugins themselves would not be portable, you would need to recompile 
for every platform, possibly with modifications to the plugin code. This 
*would* be a problem. You would need complete source code to port a 
plugin, not just "includes and headers".

So, you have a practically 100% platform dependant solution with lots of 
other headaches like plugins not being available for your platform, and 
only really speeding up a few things that weren't often used anyway. 
Again, little benefit with lots of problems. Unless you have come up 
with some miracle code that lets a plugin load and run on any platform, 
it isn't going to happen.
When you have alternatives that are as portable as the existing code, 
that will provide more speedups in the areas that really need it, though 
not quite as fast as compiled C code, is it so hard to understand why 
plugins aren't being added?

This has all been discussed before, I really suggest you go back and 
read some of the other threads on it and get yourself up to date.

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

Christopher James Huff wrote:
>In article <web.3dcde797195c50e4178f7f9c0[at]news.povray.org>,
> "normdoering" <nor### [at] yahoocom> wrote:
>
>> I'm confused. Are you saying a macro that was translated into C code and
>> compiled wouldn't parse the same size arrays much faster?
>
>Correct. First, a macro can't be compiled, it's a macro, it operates at
>parse/compile time. You can easily write things that can't be translated
>to C functions.
>POV functions could be compiled, and are...to bytecodes run by a VM.
>They are fast enough to use as patterns and as functions for
>isosurfaces, and probably aren't as fast as they could be.
>
>
>> I know that's not
>> true. I've done a limited bit of 2D and 3D array coding in C and parsed
>> larger arrays, written in text, translated to floats, doing more complex
>> math much faster than POV is parsing the HF_ macros.
>
>Yes, compiled C code is faster than the directly interpreted POV code.
>It would also be faster than an virtual machine running compiled
>bytecode, though not by anywhere near as much. For most things, a VM
>will be fast enough, patching the source code could be done if it isn't.
>
>For the last time:
>Plugins would not bring POV any closer to "compiled macros", either a VM
>or native machine code. I don't know why you think it would.
>
>Compiling scene files to native machine code is a bit ridiculous. It is
>completely platform dependant, adds a huge amount of complexity, and
>adds speed where it is needed least. However, a VM could include hooks
>for translating to native code where needed, without breaking
>portability of the core code.
>
>Plugin loading code would not be portable. You either have chunks of
>core code that need to be rewritten for each platform, making porting
>much harder, or you end up with a situation where some POV versions just
>don't support plugins.
>
>Plugins themselves would not be portable, you would need to recompile
>for every platform, possibly with modifications to the plugin code. This
>*would* be a problem. You would need complete source code to port a
>plugin, not just "includes and headers".
>
>So, you have a practically 100% platform dependant solution with lots of
>other headaches like plugins not being available for your platform, and
>only really speeding up a few things that weren't often used anyway.
>Again, little benefit with lots of problems. Unless you have come up
>with some miracle code that lets a plugin load and run on any platform,
>it isn't going to happen.
>When you have alternatives that are as portable as the existing code,
>that will provide more speedups in the areas that really need it, though
>not quite as fast as compiled C code, is it so hard to understand why
>plugins aren't being added?
>
>This has all been discussed before, I really suggest you go back and
>read some of the other threads on it and get yourself up to date.
>
>Christopher James Huff <cja### [at] earthlinknet>
>http://home.earthlink.net/~cjameshuff/
>POV-Ray TAG: chr### [at] tagpovrayorg
>http://tag.povray.org/
>

You've lost me.

However, I'm looking at this from a user's perspective, not a programmers.
Other programs I use have plugins, like Corel Draw and photopaint, and they
have script languages that seem to loop arrays faster. So I think the way I
do because I'm a user who's comparing different programs.

normdoering

Post a reply to this message

On Sun, 10 Nov 2002 17:43:46 EST, "normdoering" <nor### [at] yahoocom> wrote:
> However, I'm looking at this from a user's perspective, not a programmers.

But this is 'povray.programming' group.

If POVRAY could be outdated, slow and not efficent why manufacturers use it to
proof their computers/processors are fast ? What happened with that code
delivered from Intel and introduced in 3.5 ?

Can you start scripts from Corel to achive something on Amiga without
additional tools ? Would it be possible to create macro by macro online ?

Would it be safe to start compiled plugin ? Can you promise nobody would use
it for viruses ? If you can write plugin in Pascal/C why can't you write it as
separate application for your own and it put it in Tools menu of POV-Ray. It
can ask you for inputs and put output in Clipboard so you can put it into POV
editor with simple Ctrl+V.

Note we are here platform independant community. I know what OS use Warp only
becouse of off-topic group, and I know what OS use Christopher James Huff
becouse he had site with mac in url, but for example I never know what OS
currently use Christoph Hormann or Peter Popov becouse I don't need to know.
We can share our knowledges and sources becouse povray is _well_written_
platform independant application. I recently counted 3.5 was sucesfully
compiled with about 7 compilers on different platforms and I have two next to
try.

Note also plugin idea is not new as mentioned earlier. Look what this funny :)
person wrote four years ago: http://news.povray.org/povray.programming/16984/
And you know what ? He is now in povray team and he still not introduced
pluging system. He must be just lazy.... ;-)

ABX

Post a reply to this message

ABX wrote:
> 
> [...]
> 
> Note we are here platform independant community. I know what OS use Warp only
> becouse of off-topic group, and I know what OS use Christopher James Huff
> becouse he had site with mac in url, but for example I never know what OS
> currently use Christoph Hormann or Peter Popov becouse I don't need to know.

You know you just have to look into the posting headers...

> 
> Note also plugin idea is not new as mentioned earlier. Look what this funny :)
> person wrote four years ago: http://news.povray.org/povray.programming/16984/
> And you know what ? He is now in povray team and he still not introduced
> pluging system. He must be just lazy.... ;-)

Funny reading... :-)

Although to be fair extensibility of POV-Ray has much increased since
3.0.  Just think of functions.  Of course this has nothing to do with what
would be called a plugin system.

Christoph

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

Post a reply to this message

On Tue, 12 Nov 2002 10:31:16 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> Although to be fair extensibility of POV-Ray has much increased since
> 3.0.  Just think of functions.

Yes, it is a very nice addition. My favourite. You can replace whole macros
with those functions and it is much much faster in execution.
I have recently hacked it with own extensions and I would like to write a
tutorial about internals of functions similiar to my other tutorials but I
fight with small bug in it. It can be specific bug in polysolver either. I
just have to wait for some quiet day in my life...

ABX

Post a reply to this message