In article <368ed156.70446727@news.povray.org> , par### [at] mailfwicom (Ronald L.
Parker) wrote:

>I think Macs don't support dynamic
>libraries, as well, but I'm probably mistaken.

They do, but have a different name for them: "shared library".


    Thorsten

Post a reply to this message

Ken wrote:

> Jon A. Cruz wrote:
>
> > Well, if people really needed cross-platform 'dll's, you could always go
> > the route of setting up JNI hooks and writing the 'dll' in Java. That way
> > you'd have bytecodes that would run on many platforms. (Or maybe...
> > POV-Ray could be made to call a Java method. That Java method could be
> > set up to in turn call a platform-specific native module via JNI, or just
> > fall back to a pure Java implementation, and could even switch
> > dynamically at run-time. Arrrggghhh! No.....! Stop!!! my head hurts....)
> >
> > Of course, with the speed factor and all, especially with raytracing, I
> > would definitely say don't do that. Just stick to good clean C.
> >
>
> To quote Chris Young concerning Pov a Jave:
>
> WHAT LANGUAGE TO USE?  WHEN?  HOW?
>         As I mentioned earlier, we originally planned that our next
> release would be a major rewrite in C++ however we had lots of input
> from users and team members that a compiled Java rewrite might be a
> good alternative.  In the 18 months since that debate, Java has not
> fulfilled its promise to unite the world in the peaceful harmony of a
> single, portable language.  The whole industry (not just Microsoft) is
> doing things to ruin Java.  Enough politics... Java is out.  We're
> sticking with our original plan for C++.
>

Yes. But that's for the main program itself. I fully agree with that decision,
especially for the performance needed for raytracing. I was just mentioning
that Java could in essence be used as a glue layer for 'dlls' or plugins that
could have the same bytes work on different platforms. For POV-Ray, however, it
would probably not be worth it. (thus my general tounge in cheek mention of
it).

But.... To see something like this in action, you can see Java interfaced with
Quake at http://www.openquake.org/jquake/

Post a reply to this message

On Sat, 02 Jan 1999 21:18:24 -0800, "Jon A. Cruz"
<jon### [at] geocitiescom> wrote:

>Well, if people really needed cross-platform 'dll's, you could always go
>the route of setting up JNI hooks and writing the 'dll' in Java. 

I'm sure the Amiga and DOS users would love to hear that one, even if
it were halfway efficient.  POV-Ray is still more cross-platform than
Java is.  Java is only officially supported on the "popular"
platforms.

Post a reply to this message

On Sun, 03 Jan 1999 12:41:59 +0100, "Thorsten Froehlich"
<fro### [at] charliecnsiitedu> wrote:

>In article <368ed156.70446727@news.povray.org> , par### [at] mailfwicom (Ronald L.
>Parker) wrote:
>
>>I think Macs don't support dynamic
>>libraries, as well, but I'm probably mistaken.
>
>They do, but have a different name for them: "shared library".

The same name as Unix and Amigados, then. :)

Post a reply to this message

Lance Birch wrote:
[snip]

> What I was thinking is to incorporate the Dll into the actual program (so
> it's no longer linked).  That way access to it would be faster also and it
> would save rewriting the Dll entry point for each OS.
>
> Just a thought anyway.
>
> --
> Lance.

I don't know about it being faster, but it is quite easy to move the
functionality of the (isosurface, in this case) DLL's into the main program.
In fact, I've been giving myself headaches by trying to put some functions
that I hard-coded into the v3.0 isosurface patch into DLL's to use with the
SuperPatch.
Oh well, I'll probably wait for updated SuperPatch code to be available and
hard-code the functions into that ...

    Mike Andrews.

Post a reply to this message

Ronald L. Parker wrote:
> I think perhaps VMS doesn't support dynamic linking, though
> I suspect there's no longer an official VMS version (if there ever
> was.)
As the creature working on a povray 3.1 port to OpenVMS I think I can 
say that VMS isn't dead (yet). Around summer version 7.2 of VMS vill
enter the market. (there is even talk about FreeVMS, well, mostly talk)

As of dynamic linking I think you are correct in that it does not exist.
There is support of code-sharing between different processes but that is
not the same thing.
 
www.openvms.digital.com can tell more about the future of VMS.
Or if you are more interested in freeVMS then check out www.free.lp.se

minus

Post a reply to this message

On Tue, 05 Jan 1999 20:02:44 +0100, minus <MIN### [at] ctrl-cliuse> wrote:
>Ronald L. Parker wrote:
>> I think perhaps VMS doesn't support dynamic linking, though
>> I suspect there's no longer an official VMS version (if there ever
>> was.)
>As the creature working on a povray 3.1 port to OpenVMS I think I can 
>say that VMS isn't dead (yet). Around summer version 7.2 of VMS vill
>enter the market. (there is even talk about FreeVMS, well, mostly talk)

No slight intended; I meant that I didn't think there was an official
version of POV for VMS.  Since you're working on a port, I guess that's 
true.  Still, even without an official VMS port, there's no reason we 
should ignore that platform, or lots of other platforms people still 
use.

Post a reply to this message

"Ronald L. Parker" wrote:
> 
> On Thu, 31 Dec 1998 17:23:16 -0700, "Twyst" <twy### [at] twystednet> wrote:
> 
> >Here's a different look: why not write a pov-ray SPECIFIC library. IE. place
> >the files in, and using a customized interface, povray reads the library.
> >Who says anything about making it a DLL? Why not make a simple binary format
> >that povray can read crossplatform?
> 
> Because the code in the current isosurface DLLs is compiled C, in the
> form of processor-specific instructions, and would thus be useless to
> the average Amiga user (and possibly even the average DOS user).  You
> could write an entire virtual machine and make the 'libraries' contain
> p-code, but there would be a bit of a performance hit over just
> compiling the functions into the source directly.
Did I hear a JAVA whisper here, and a sob about the loss of Speed?
 
//Spider

Post a reply to this message

On Sun, 10 Jan 1999 13:59:25 +0100, Spider <spi### [at] bahnhofse> wrote:

>
>
>"Ronald L. Parker" wrote:
>> You
>> could write an entire virtual machine and make the 'libraries' contain
>> p-code, but there would be a bit of a performance hit over just
>> compiling the functions into the source directly.
>Did I hear a JAVA whisper here, and a sob about the loss of Speed?

Only if you naively think VM==JAVA.  There have been bytecode compiled
machines around for decades. One such was UCSD Pascal.  Perl, too,
worked like this until the most recent version.  Java doesn't really
offer anything new in the arena of cross-platform operation, except
for the standardized interfaces in places like the AWT, and even that
is debatable with things like Tcl/Tk (and to a lesser extent Perl/Tk)

Be that as it may, it's actually not a bad idea, and I've been tossing
it around in the back of my head for a while now.  For the isosurface
stuff, at least, most of the work has already been done.  It's just a
matter of extending the existing formula mechanisms to handle looping
and conditionals, but I know from experience that extending those
mechanisms is not for the fainthearted.

The same principle applies to using Renderman-compliant shaders in
POV-Ray.  Again, you'd use a bytecode method (perhaps with a JIT
compiler on some platforms).  But again, you'd hardly use the Java VM.
It's designed to run Java, and it runs applications written in other
languages with less alacrity due to its choice of atomic operations.

Post a reply to this message

"Ronald L. Parker" wrote:
> 
> On Sun, 10 Jan 1999 13:59:25 +0100, Spider <spi### [at] bahnhofse> wrote:
> 
> >
> >
> >"Ronald L. Parker" wrote:
> >> You
> >> could write an entire virtual machine and make the 'libraries' contain
> >> p-code, but there would be a bit of a performance hit over just
> >> compiling the functions into the source directly.
> >Did I hear a JAVA whisper here, and a sob about the loss of Speed?
> 
> Only if you naively think VM==JAVA.  There have been bytecode compiled
> machines around for decades. One such was UCSD Pascal.  Perl, too,
> worked like this until the most recent version.  Java doesn't really
> offer anything new in the arena of cross-platform operation, except
> for the standardized interfaces in places like the AWT, and even that
> is debatable with things like Tcl/Tk (and to a lesser extent Perl/Tk)
No, I'm not that naive... 
Java came to my mind after the decision to drop it from POV (see original post)
As for the other examples, some of them are new to me(most) since I'm not a *nixer..

> 
> Be that as it may, it's actually not a bad idea, and I've been tossing
> it around in the back of my head for a while now.  For the isosurface
> stuff, at least, most of the work has already been done.  It's just a
> matter of extending the existing formula mechanisms to handle looping
> and conditionals, but I know from experience that extending those
> mechanisms is not for the fainthearted.
I think it would be easies to implement it in the POV main source...
I can't tell, since I haven't looked at the source.

> 
> The same principle applies to using Renderman-compliant shaders in
> POV-Ray.  Again, you'd use a bytecode method (perhaps with a JIT
> compiler on some platforms).  But again, you'd hardly use the Java VM.
> It's designed to run Java, and it runs applications written in other
> languages with less alacrity due to its choice of atomic operations.
Ok.
Thanks for the hard coding information..
Been a while since I thought about it...

//Spider

Post a reply to this message