Reposted with permission from from C.G.R.R.

FROM:   Chris Young, POV-Team Coordinator
DATE:   December 30, 1998
TO:     POV-Ray enthusiasts everywhere (feel free to repost this)

Dear POV-Ray enthusiasts,
        The POV-Team has been hard a work achieving its primary
post-3.1 goal.  That goal is NOTHING!  <heheheh>  That's right,
nothing, zip, zilch, nada, null.  Soon after 3.1 release I started a
discussion about our plans for what's next.  The #1 item on everyone's
list was VACATION!
        So we've taken a couple of months off development to rest,
relax and enjoy the holidays (Thanksgiving through New Year's) to be
with family, friends, and to actually trace a few rays.  Sometimes we
spend so much time working ON POV-Ray that we don't have time to play
WITH POV-Ray.
        We did however take the time to roughly outline our other
goals and plans to achieve them.  I'd like to share with you a few of
the things you can look forward to in 1999 and beyond.

BUGFIXES AND POV-Ray 3.1b,c,d,e....
        First an apology on some mixed messages regarding bugfixes.
We in the POV-Team had even ourselves confused.  Our Windows developer
/ newsgroup manger / webmaster / Chris Cason prefers his bug reports
via the newsgroups where we count on other enthusiasts to help weed
out the user mistakes from the real bugs.  Myself (Chris Young)... I
prefer email because I don't have time to monitor newsgroups.  I've
taken the stance that "it posted it in the newsgroup" wasn't
sufficient to insure it'll get fixed.
        After some discussion, the newsgroups are a better route.
POV-Team members who have time to monitor the groups have assured me
that they'll see to it we get all the real bug reports forwarded to me
or some other appropriate team member.  I'll still take emailed
reports at c_y### [at] compuservecom if you'd like (especially bug
fixes).  Mac-specific bug reports are still welcome at
pov### [at] compuservecom but the newsgroup is your best bet if you
aren't 100% sure its a real bug.
        That said... we've got several bug reports we're working on
right now.  I know there has been some frustration that we've not
fixed them sooner and have not used your supplied fixes.  We deeply
appreciate the fixes, keep 'em coming.  But some of the fixes are only
partial fixes, some could have very serious side effects (such as
changing the EPISLON value), and some have major impact on
long-standing parts of the code (such as the averaged normal bug vs.
the double-illuminate workaround).  Nearly ALL of the recent bugs have
existed since 3.0, most since 2.2 and one since before POV-Ray existed
(its a bug from the old DKB-Trace upon which POV-Ray is based.)
Given our need for vacation and the age of these bugs, we've not made
bug fixes a high priority but it is the next item on our agenda.  Look
for POV-Ray 3.1b in a few weeks.

USER PATCHES AND VERSION NUMBERS
        When we started on 3.1 it was supposed to be a "quick" release
before our planned total rewrite in C++ for 4.0.  Unfortunately
version 3.1 took a year longer than expected.  Meanwhile a number of
excellent user-created patches had appeared.  When 3.1 was released
without these patches we were criticized for ignoring them.  Many of
the patches were not available until after 3.1 was well under way.
Some of the patches we were not aware they existed. (Its that nasty
CY-doesn't-read-newsgroups problem again <heheh>)  Hey the Team
Coordinator can't coordinate what he doesn't know existed can he?
Anyway, I think we've recognized and corrected this problem too.
        I did know about a user-submitted #macro patch and although we
didn't use his code directly, it was a VERY BIG help in designing our
own.  As you know, #macros made it into 3.1 along with much requested
arrays and file i/o which was pretty easy to include.  Also halo
author Zsolt Szalavari told me about his idea for generalizing all
patterns such as bozo, gradient, wood etc. for use with halo.  As one
of the major purposes of 3.1 was to turn halo into media, it was the
perfect chance to add this feature.
        So version 3.1 was either based on user-created patches or
some strongly demanded user features.  However we have to recognize
that the whole reason for having a 3.1 version was to correct problems
with a haphazard integration of a user-submitted patch into 3.0.  We
had alrea`y implemented atmosphere when we first heard about halo.
Halo was so wonderful that we could not resist putting it in even
though we were nearly ready to release 3.0.  While the original design
looked good, it was confusing. It was inconsistent with atmosphere. It
created big problems within the core code and it aggravated other
long-standing design problems.  Our zeal to drop in a user patch late
in the game caused lots of problems and it took lots of work in 3.1 to
fix them.
        So we recognize that there is a BIG backlog of user patches
with features we REALLY want.  But do we really want to force them to
wait until a major 4.0 rewrite in a new language?  After much debate
the answer is no.
        Therefore the current plan is to create a POV-Ray 3.5 whose
primary purpose is make official, as many user-submitted patches as
possible.  To borrow Ron Parker's term, this will be a "Super Patch"
version.  Note however we will not simply be rubber-stamping Ron's
work in collecting patches as they currently exist.  Ron's super-patch
is proving useful to the team in evaluating various patches (thanks
Ron) however some work must be done to integrate the new features in
way that won't conflict with future plans.  Also some of the features
will be modified or eliminated.  For example cross-platform
portability is a major design priority and the iso-surface patch makes
use of DLLs that are not portable.  We will likely eliminate that part
of the patch.
        At this point we can't say what will or will not make the
final cut.  We'll be contacting authors of all the patches we know
about.  We'll be asking their permission to use their patch but WE
CANNOT GUARENTEE that it will be used and you should expect that it
may be modified or rewritten in some way if it does make the cut.  If
you have a POV-Ray 3.1 compatible patch and do not receive email from
me by February 1, 1999 then I don't know about your patch and you
should email me at c_y### [at] compuservecom to tell me about it.
        We'll try to keep everyone informed of our progress as best we
can.

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++.
        The part we've not yet decided is when or how to convert.
Some want to start with a blank page.  Others want to phase-in
object-oriented features.  POV-Ray although written in plain C is
already quite object-oriented in that OBJECT and PATTERN are abstract
types that are "inherited" by more complex types that extend them.
Nearly everything has constructors and destructors already defined.
        The current plan is to create a design specification from a
blank page to get the design right first.  The team has voted almost
unanimously to wait and decide later whether to do the actual
implementation of that design in smaller, allegedly easier to manage
chunks or to just dive in and write a new implementation from scratch.
Either way, we've got design work to do first.  We hope to be able to
do some of that work in parallel with our work on 3.5 but that may be
wishful thinking.

ADD-INS, API HOOKS, PARSERS, BINARY FORMATS ETC.
        We've had many requests for the ability to make plug-ins or
DLL type capability.  Although the vast majority of our users run
Windows, we will not be doing anything to hurt the cross-platform
portability of the program.  Not all operating systems have DLL
capability and even if they did, you'd have to re-compile the DLL for
every platform.  If you're going to do that, just patch the POV-Ray
source and re-compile it.  We hope that eventually as our C++ design
encapsulates more of the program, it will be easier for
user-developers to extend or modify our objects without messing up
some other part of the program.  This will be a big design goal for
the new object-oriented design: make it easier to add new features.
        We also get frequent requests for more API (application
program interface) features in POV-Ray.  The problem is that the more
access that external programs have to our internal workings, the
easier it is for commercial programs to blur the line between what
functions are POV-Ray and what functions are not.  We've made solemn
promises to our developers over the years that we will protect their
donated contributions to our freeware from being commercially
exploited.  Our tough language in POVLEGAL.DOC and our refusal to
expand POV-Ray's linkability is our best effort to keep that promise.
        One of the most requested internal features that outside
developers want is our language parser.  Although I don't know why
anyone would want to convert from POV (the World's Greatest Renderer)
to something inferior is a mystery to me.  (<heheh> just kidding.)
Seriously we do appreciate that some way to import POV scenes is a
reasonable request but given our above-stated position on API or DLL
links and our ban on using our source code, its a difficult request to
satisfy.
        One often-suggested solution is a POV binary format in which
would "compile" our scene files into some allegedly more readable (by
machines, not humans) format.  However problems with floating-point
representation and byte ordering make such solutions difficult in a
cross-platform environment.  It is also mistakenly assumed that
loading a binary format would somehow make parsing MUCH faster.
However much of the slow parsing on mega-size files is spent
allocating memory for 100s of thousands of objects and textures
individually.  The really slow parses are slow because you're
thrashing away at a virtual memory swap file.  I won't take the time
to re-argue the whole debate we had.  I'll just say that we came very
close to deciding to go ahead and implement a binary format despite
the difficult technical problems and limited usefulness.  As we began
to discuss the details however, we soon concluded that the benefits
were not worth the effort.
        The POV-Ray language in most respects isn't really that hard
to parse in its current form.  Two issues make it complicated.
POV-Ray 3.1 language isn't hard to parse but the 3.0, 2.0 and 1.0
languages are difficult to parse simultaneously.  Also directives such
as #if, #while, #declare, #macro etc. can appear almost anywhere and
THAT is hard to deal with.
        We decided on the following items which we will work on as
time and manpower permit:
        1) I will be writing an official technical document that
describes the POV-Ray language from a parser-writer's point of view.
It will include a grammar specification using the syntax notation in
our reference docs.  It should be helpful to anyone who wants to
implement their own parser.
        2) We will eventually write a separate utility or an optional
feature in POV-Ray itself to translate (as much as possible) a version
1.0, 2.x or 3.0 scene into 3.1 scene and to possibly unroll loops,
resolve conditionals and expand macros.  This will allow you to create
a much more easy-to-parse scene.
        3) We will continue to look for ways to make parsing faster
and easier and will look for other methods to assist utility authors
needs in regards to the language.

SUMMARY
        We've got a full agenda ahead of us.  We'll continue to do the
best we can given our time and ability.  I'm continually amazed that
we have done so much already and I'm even more amazed at the wonderful
art that you create with POV-Ray.  It inspires us to keep working.
        Happy New Year from the POV-Team.

Post a reply to this message

In light of this information I can only say to all the whining, moaning,
complaing, impatient users out there quit your darn crying. Your
wait is nearly over.

Oh and Happy New Year !

--
Ken Tyler

tyl### [at] pacbellnet

Post a reply to this message

All good news!!!!
I will now proceed to build a small temple to honour the POV-team. Thank
you POV-team for your work on this incredible program.

-- 
Chris Maryan
mailto:cma### [at] geocitiescom
***
Will work for cash.
***
Email me if you are interested in donating
to the Chris Maryan needs money fund.
We will also accept donations to the Chris
needs a Pentium II or SGI workstation 
fund and the Chris needs a car fund.

Post a reply to this message

Once again THANKS Pov team - the only sad news is the probably loss of the
iso patch - can we keep some of it, the non Dll part? I espeacially like
using it to create mathmatical surfaces, normal and color patterns.

Keep up the good work

Mick

Post a reply to this message

Gilles will find that a big loss I'm sure... he does some really cool work
with the ISO patch.

--
Lance.


---
For the latest MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

Ken wrote in message <368AE447.7BEED249@pacbell.net>...
>In light of this information I can only say to all the whining, moaning,
>complaing, impatient users out there quit your darn crying. Your
>wait is nearly over.


I've never really understood why an obvious interest in POV developments is
seen as moaning or being impatient - but hey..

>Oh and Happy New Year !


You too :)


Matt

Post a reply to this message

Matthew Bennett wrote:

> Ken wrote in message <368AE447.7BEED249@pacbell.net>...
> >In light of this information I can only say to all the whining, moaning,
> >complaing, impatient users out there quit your darn crying. Your
> >wait is nearly over.
>
> I've never really understood why an obvious interest in POV developments is
> seen as moaning or being impatient - but hey..

  Your interperatation of my comments shows a lack of understanding
of my sometimes dry sense of humor.

Now in defense of my comments:

  Heck Pov currently has so many wonderful features that even if they
stopped development completely I would never be able to use eveything
the program has to offer now. For a few extras I have the virtue of patience,
so I can and will wait for additions at the teams convienece without feeling
a need to rock the boat or decry the injustices of untimly development.

--
Ken Tyler

tyl### [at] pacbellnet

Post a reply to this message

He said that just the DLL part would have to be removed:

"Also some of the features
will be modified or eliminated.  For example cross-platform
portability is a major design priority and the iso-surface patch makes
use of DLLs that are not portable.  We will likely eliminate that part
of the patch."

-Mike

Mick Hazelgrove wrote:
> 
> Once again THANKS Pov team - the only sad news is the probably loss of the
> iso patch - can we keep some of it, the non Dll part? I espeacially like
> using it to create mathmatical surfaces, normal and color patterns.
> 
> Keep up the good work
> 
> Mick

Post a reply to this message

Oh, thanks for caring, Lance :) (did the survey, BTW)
I sure would miss the iso patch... But I understand the portability problem,
which is a priority.
And there's still quite a lot to do in povray without the iso patch...
The great news is that the pov-team is willing to integrate the patches in the
official version. I'd love to see Mike Hough's dispersion patch in 3.5, for
instance... Quite impressive this one.
Gilles Tran

Lance Birch wrote:

> Gilles will find that a big loss I'm sure... he does some really cool work
> with the ISO patch.
>
> --
> Lance.
>
> ---
> For the latest MAX plug-ins, images and much more, go to:
> The Zone - http://come.to/the.zone

Post a reply to this message

Ken wrote:
> 
>For a few extras I have the virtue of patience,
> so I can and will wait ...

But rickety old codgers like you and I (46) can only afford to wait just
so long...

Jerry Anning
cle### [at] dholcom

Post a reply to this message

Does anyone know whether there will be a Unix version of 3.5 or 4.0?

-Mark Gordon (feeling a little orphaned)

Post a reply to this message

I thought UNIX was far beyond version 3.5 or 4  :~)

Jim

Mark Gordon wrote in message <368BC9A3.21D8828D@mailbag.com>...
>Does anyone know whether there will be a Unix version of 3.5 or 4.0?
>
>-Mark Gordon (feeling a little orphaned)
>
>

Post a reply to this message

On Thu, 31 Dec 1998 11:21:39 -0000, "Mick Hazelgrove"
<mic### [at] virginnet> wrote:

>
>Once again THANKS Pov team - the only sad news is the probably loss of the
>iso patch - can we keep some of it, the non Dll part? I espeacially like
>using it to create mathmatical surfaces, normal and color patterns.
>
>Keep up the good work
>
>Mick
>
The function-based part of iso-surfaces will definitly be used.  Only
the DLL based part.
	Chris Young, POV-Team

Post a reply to this message

On Wed, 30 Dec 1998 18:31:42 -0800, Ken <tyl### [at] pacbellnet> wrote:

>Reposted with permission from from C.G.R.R.
>
>FROM:   Chris Young, POV-Team Coordinator
>DATE:   December 30, 1998
>TO:     POV-Ray enthusiasts everywhere (feel free to repost this)
>        Happy New Year from the POV-Team.

Many thanks for reposting this here.  I tried to post it but something
glitched.  I was just about to do it over when I saw yours.
	cy

Post a reply to this message

Mike <Ama### [at] aolcom> wrote:
: He said that just the DLL part would have to be removed:

: "Also some of the features
: will be modified or eliminated.  For example cross-platform
: portability is a major design priority and the iso-surface patch makes
: use of DLLs that are not portable.  We will likely eliminate that part
: of the patch."

  I wonder if it's absolutely impossible to make the same code without
the dlls. What's so special with the dlls anyways?

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Well, after seeing The Hive and The Reading Room...

(And thanks for doing the survey! :-)

--
Lance.


---
For the latest MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

Dlls are only supported by the Windows operating system... Dynamic Link
Libraries.  The function calls necessary to use a Dll simply don't exist in
other operating systems. (They have their own special ways of doing things)

--
Lance.


---
For the latest MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

Yey!!!

Not that I could ever make anything half decent with it but hey, it was fun
to try :)

--
Lance.


---
For the latest MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

Lance Birch <zon### [at] satcomnetau> wrote:
: Dlls are only supported by the Windows operating system... Dynamic Link
: Libraries.  The function calls necessary to use a Dll simply don't exist in
: other operating systems. (They have their own special ways of doing things)

  I said:

  I wonder if it's absolutely impossible to make the same code WITHOUT
the dlls.

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

It might take some re-writing, but it should be possible, because after all
you could just compile the Dlls functions into the main program and then
nstead of calling the Dll, you just call the function.  So yeah, guess so.

--
Lance.


---
For the latest MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

Lance Birch wrote in message <368c0c62.0@news.povray.org>...
>It might take some re-writing, but it should be possible, because after all
>you could just compile the Dlls functions into the main program and then
>nstead of calling the Dll, you just call the function.  So yeah, guess so.
>
>--
>Lance.
>
>
>---
>For the latest MAX plug-ins, images and much more, go to:
>The Zone - http://come.to/the.zone
>
>

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? I mean.. look at TTF fonts. Just because
they don't work _as fonts_ in any other OS but windows, doesn't mean pov-ray
can't read them. You can read windows TTF fonts on the amiga, for the TTF
object. Amigas don't use TTF fonts in any way, yet the file itself is still
readable.  Why not go from that as a starting point?

twyst

Post a reply to this message

Yes you can add the functions as normal code, however there
are some functions you can do with DLL's that isn't
part of regular functions in iso_surface. But wouldn't be to
hard to even add those. In general new iso_surface functions
can be added with 2 lines + function code itself.

Nieminen Mika wrote:
> 
> Mike <Ama### [at] aolcom> wrote:
> : He said that just the DLL part would have to be removed:
> 
> : "Also some of the features
> : will be modified or eliminated.  For example cross-platform
> : portability is a major design priority and the iso-surface patch makes
> : use of DLLs that are not portable.  We will likely eliminate that part
> : of the patch."
> 
>   I wonder if it's absolutely impossible to make the same code without
> the dlls. What's so special with the dlls anyways?
> 
> --
> main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
> *_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Mick Hazelgrove heeft geschreven in bericht <368b6033.0@news.povray.org>...
>
>Once again THANKS Pov team - the only sad news is the probably loss of the
>iso patch - can we keep some of it, the non Dll part? I espeacially like
>using it to create mathmatical surfaces, normal and color patterns.


I was engaged in the development of FORTRAN programs that were both
user-extendable and had one and the same source code for a variety of
platforms. The trick we played was that we included a number of 'slots' in
the code, where we called dummy subroutines. The user could include his own
features by replacing one of those dummies and then re-linking the program
from the .lib files we supplied along with the .exes. The re-linking was not
considered a problem since the user needed to have a compiler and a linker
for his platform anyway.

This technique may provide a way to allow users to extend POV without
compromising on platform independence.

Happy new year to all of you.

Frans

Post a reply to this message

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.

>I mean.. look at TTF fonts. Just because
>they don't work _as fonts_ in any other OS but windows, doesn't mean pov-ray
>can't read them. You can read windows TTF fonts on the amiga, for the TTF
>object. Amigas don't use TTF fonts in any way, yet the file itself is still
>readable.  Why not go from that as a starting point?

TTFs, except for some hinting rules in a documented pseudocode, are
just big tables.  There isn't any native executable code in one.

Post a reply to this message

Lance Birch wrote:
> 
> Dlls are only supported by the Windows operating system... Dynamic Link
> Libraries.  The function calls necessary to use a Dll simply don't exist in
> other operating systems. (They have their own special ways of doing things)

Actually, Linux and other unix-like OSs have DLLs, though maybe not
normally called by that name.  In 1988 (ten years ago) I read a manual
for SunOS version 3.something and it described DLLs.  That was before I
heard of Microsoft Windows.     For Linux and most other unixes, the
resulting DLL files are named not like wonderful.dll but like
libwonderful.so.   

I have used isosurfaces on Linux, and it was easy, though I don't see
how a non-programmer could use it. 

What I don't know is which OSs *don't* support DLLs (by any name)?

I have some thoughts on implementing isosurface w/o any kind of DLLs -
see the programming newsgroup.
-- 
Daren Scot Wilson
dar### [at] pipelinecom 
www.newcolor.com
----
"A ship in a harbor is safe, but that is not what ships are built for"
                                            -- William Shedd

Post a reply to this message

Daren Scot Wilson <dar### [at] pipelinecom> wrote:
: What I don't know is which OSs *don't* support DLLs (by any name)?

  DOS.
  (I know, I know, DOS is not an operating system...)

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Yeah, that's what I meant.  Even if they aren't called Dlls, the
instructions in each operating system are still there to use a dynamically
linked library.  The only problem is that it would get annoying having to
convert the method of programing for each operating system.  For instance,
I'm sure Windows has a different Dll entry method than Linux or Unix does.
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.


---
For the latest MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

On Sat, 02 Jan 1999 13:19:23 +0000, Daren Scot Wilson
<dar### [at] pipelinecom> wrote:

>What I don't know is which OSs *don't* support DLLs (by any name)?

I assume you mean "operating systems currently supported by POV-Ray."
I can name at least one: MS-DOS.  I think Macs don't support dynamic
libraries, as well, but I'm probably mistaken.  AmigaDOS supports 
dynamic linking, as does OS/2.  Many unices don't support dynamic 
linking.  I think perhaps VMS doesn't support dynamic linking, though 
I suspect there's no longer an official VMS version (if there ever 
was.)

Post a reply to this message

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.


Ronald L. Parker wrote:

> On Sat, 02 Jan 1999 13:19:23 +0000, Daren Scot Wilson
> <dar### [at] pipelinecom> wrote:
>
> >What I don't know is which OSs *don't* support DLLs (by any name)?
>
> I assume you mean "operating systems currently supported by POV-Ray."
> I can name at least one: MS-DOS.  I think Macs don't support dynamic
> libraries, as well, but I'm probably mistaken.  AmigaDOS supports
> dynamic linking, as does OS/2.  Many unices don't support dynamic
> linking.  I think perhaps VMS doesn't support dynamic linking, though
> I suspect there's no longer an official VMS version (if there ever
> was.)

Post a reply to this message

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

--
Ken Tyler

tyl### [at] pacbellnet

Post a reply to this message

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

In article <368ea2e4.0@news.povray.org>, war### [at] cctutfi says...
> Daren Scot Wilson <dar### [at] pipelinecom> wrote:
> : What I don't know is which OSs *don't* support DLLs (by any name)?
> 
>   DOS.
>   (I know, I know, DOS is not an operating system...)

Well, what about the .OVL in the old DOS system ? Wasn't it like the dll 
in a way ? Seems kinda close to me.

Yann

Post a reply to this message

Yann Coupin <pov### [at] club-internetfr> wrote:
: Well, what about the .OVL in the old DOS system ? Wasn't it like the dll 
: in a way ? Seems kinda close to me.

  If a _program_ supports .OVL-files, that doesn't mean that DOS supports them.
  DOS supports .OVL-files if there is a DOS system call which you can use
to use .OVL-file. Is there any?

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message