I think a sanctioned, Leveller-like plug-in architecture would be great.
Instead of having to mix and much unofficial patches, you would just have to
register a plug-in and call it in a standardized way from POv-Ray scripts.
By the way, I have started playing with Linux (besides Win32) and I saw that
also in Linux you have DLLs (even if they are called differently). So,
Windows has DLLs, Linux has DLLs, I presume that other UNIX flavours have
something like DLLs, Macs have the equivalent, VMS has shared libraries....
I think every target of POV-Ray has the system support for DLLs, so PLEASE:
dynamically loaded plug-ins!!!!

Alessandro Coppo
a.c### [at] iolit
www.geocieties.com/SiliconValley/Way/8111

Disnel wrote in message <371C9AE6.D6AF1D34@linux.itam.cas.cz>...
>Some plug-in architecture like GIMP has.
>Its simple and portable.
>
>Disnel

Post a reply to this message

Do it in dos and amiga, and make a plugin cross compilant. (no or little source
changes.)
Then it's worth thinking of. And, you'd have to be able to implement it at a
decent speed level(where/how would the changes be applied?) 
No, that's why the source and patch version is here, to avoid that sort of
struggle, and to KEEP it cross compilant.


-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message

On Wed, 21 Apr 1999 01:05:07 +0200, Spider <spi### [at] bahnhofse> wrote:
>Do it in dos and amiga, and make a plugin cross compilant. (no or little source
>changes.)

Amiga has shared libraries, too.  They've had 'em since the beginning, or 
at least since OS 1.2.

Post a reply to this message

Alessandro Coppo wrote:

> I think a sanctioned, Leveller-like plug-in architecture would be great.
> Instead of having to mix and much unofficial patches, you would just have to
> register a plug-in and call it in a standardized way from POv-Ray scripts.
> By the way, I have started playing with Linux (besides Win32) and I saw that
> also in Linux you have DLLs (even if they are called differently). So,
> Windows has DLLs, Linux has DLLs, I presume that other UNIX flavours have
> something like DLLs, Macs have the equivalent, VMS has shared libraries....
> I think every target of POV-Ray has the system support for DLLs, so PLEASE:
> dynamically loaded plug-ins!!!!
>
>

You know that a shared lib is slower than statically linked code. well now you
do :)
Also it can be quite hard to support this in a generic way.  But I could be
done I think if the build system is converted to gnu autoconf/libtool. Libtool
take care of all the hairy things involving dll's

Post a reply to this message

Ron Parker wrote:
> 
> On Wed, 21 Apr 1999 01:05:07 +0200, Spider <spi### [at] bahnhofse> wrote:
> >Do it in dos and amiga, and make a plugin cross compilant. (no or little source
> >changes.)
> 
> Amiga has shared libraries, too.  They've had 'em since the beginning, or
> at least since OS 1.2.
I'm not an amiga fan, but I am a POV fan, and since POV is on amiga, I had to
add it here for the sake of it. Thanx for the info, at least I've learned
something today(a totally wasted day in other cases)


-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message

On Thu, 22 Apr 1999 00:44:01 +0200, Kenneth Johansson <ken### [at] canitse> wrote:
>You know that a shared lib is slower than statically linked code. well now you
>do :)

You must be kidding.  If it is slower (and it doesn't have to be) it is only
by a few cycles per function call.  

On a 386, a direct intrasegment call takes 7+m cycles, where m is a 
characteristic of the first instruction at the called address and is a constant 
for our purposes.  An indirect intrasegment (all 32-bit flat-model calls are 
intrasegment) call takes either 7+m or 10+m cycles.  Let's be pessimists and 
say that it will take the three extra cycles in every case (as it likely will 
if the address of the target address is specified directly rather than as a 
register.)  On a 33 MHz machine, then, it will take an extra tenth of a 
microsecond to make the indirect call.  If we have to call that function for 
every pixel of an 800x600 image, it will take a whole 48 milliseconds longer to 
use the shared library.  Most of us have faster processors than a 386/33, 
though, so we won't have to wait that long.  If you do have a 386/33, and you 
don't have the 48 milliseconds to spare, just write self-modifying code that 
'fixes up' the dynamic library call to a direct call at bind time.

>Also it can be quite hard to support this in a generic way.  But I could be
>done I think if the build system is converted to gnu autoconf/libtool. Libtool
>take care of all the hairy things involving dll's

Keep in mind that autoconf and libtool are both very Unix-centric.  Autoconf 
generates shell scripts.  Hands up all you Mac and Windows users who have a 
fully-compatible copy of bash.  Thought so.  Libtool supports the following 
build environments.   Note that Windows, MS-DOS, and MacOS are all missing.

------ quoted from http://www.fsf.org/software/libtool/libtool.html
Libtool supports building static libraries on all platforms. 

Shared library support has been implemented for these platforms: 

AIX 3.x (*-*-aix3*) 
AIX 4.x (*-*-aix4*) 
AmigaOS (*-*-amigaos*) 
BSD/OS 4.x (*-*-bsdi4*) 
Digital/UNIX 3.x, 4.x, a.k.a. OSF/1 (*-*-osf3*, *-*-osf4*) 
DG/UX R4.11, R4.12, R4.20 (*-*-dguxR411*, *-*-dguxR412*, *-*-dguxR420*) 
FreeBSD 2.x, 3.x (*-*-freebsd2*, *-*-freebsd3*) 
GNU/Linux ELF (*-*-linux-gnu*, except aout, coff, and oldld) 
HP-UX 9.x, 10.x, 11.x (*-*-hpux9*, *-*-hpux10*, *-*-hpux11*) [see note] 
IRIX 5.x, 6.x (*-*-irix5*, *-*-irix6*) 
NetBSD 1.x (*-*-netbsd*) 
OpenBSD 2.x (*-*-openbsd*) 
OS/2 using EMX (*-*-os2*) 
SCO OpenServer 5.x (*-*-sco3.2v5*) 
SCO UnixWare 7.x (*-*-sysv5*) 
Solaris 2.x (*-*-solaris2*) 
SunOS 4.x, a.k.a. Solaris 1.x (*-*-sunos4*) 
UnixWare 2.x (*-*-sysv4.2uw2*) 
UTS 4.x (*-*-uts4*) 
All ELF targets that use both the GNU C compiler (gcc) and GNU ld

Post a reply to this message

> Amiga has shared libraries, too.  They've had 'em since the beginning, or
> at least since OS 1.2.

So what you're saying is that this can be added to POV if we forget about the DOS
platform? So be it! (Unless the DOS users who post to their newsgroup so often
complain about it).

Post a reply to this message

On Thu, 22 Apr 1999 14:47:57 -0400, TonyB <ben### [at] panamaphoenixnet> wrote:
>So what you're saying is that this can be added to POV if we forget about the DOS
>platform? So be it! (Unless the DOS users who post to their newsgroup so often
>complain about it).

First, keep in mind that those DOS users have only had a newsgroup for a few 
days now.  Many of them probably don't even know the newsgroup exists yet.

Second, there are still a lot of issues with portability of shared library 
implementations.  They aren't all implemented the same way, and of course
there's no standard way of using them.  This could be shuffled off to the
platform-specific code for each platform like the display code is, but 
unlike display code, plugins would quickly become an essential element of
POV.  It's not good to have essential parts of the code be platform-dependent.

Third, there's no way you're going to be able to get the people who write 
plugins to compile a version for every platform out there, so if I write
a plugin to do, say, a hexagon tile pattern, and compile it for Windows 
only, it will be unavailable to those who use MacOS or Linux, whereas if
I write a patch to POV, I am required to release the source so anyone 
else can compile it for their platform of choice.

Post a reply to this message

OK. Gotcha. =)

(How's the 3.1e superpatch coming along?)
(Why do you not mention it on your webpage?)

Post a reply to this message

On Fri, 23 Apr 1999 06:25:55 -0400, TonyB <ben### [at] panamaphoenixnet> wrote:
>OK. Gotcha. =)

Don't get me wrong.  I was one of the first to seriously propose plugins, and
I even started doing some development work and sent a proposal about them to 
the POV Team (required, because to distribute plugin code would be a violation
of POVLEGAL.)  I still think they're a good idea, but we need to come up with 
a way to make them cross-platform.  If Java were as good as Sun would like to 
believe it is, it would be the perfect choice, but at least for now it hasn't
lived up to its hype.  Nevertheless, I'm likely to start playing around with
some JNI stuff to make Java plugins.  Of course, as before, I would have to 
get permission to distribute it, even to someone interested in building and
testing a port.  That could make development interesting.

>(How's the 3.1e superpatch coming along?)

I have it pretty much done.  I'm waiting for my documentation guy to get back
to me with the new stuff, and I'm kinda halfheartedly waiting for the 3.1e 
Windows source to be released so I can build a version that's compatible with
the new editor DLLs.  If anyone wants source for the core 3.1e superpatch code
now, I can point them toward it, but it's not yet documented satisfactorily.

>(Why do you not mention it on your webpage?)

Lack of free time, mainly.  I want to completely overhaul my webpage, putting
a lot more emphasis on POV, but I haven't really had the time.  If you've ever
looked at parts besides traces.html, you'd see that the rest of it is even
crustier.  Parts of it haven't been updated in years.

Post a reply to this message