-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Henderson wrote:
> Only so far as the features one wants are in the OS that one is using.  
> If you've used any OS other than Windows in the last 10 years, you've 
> come to expect that full functionality may not be available in the OS of 
> your choice.

Yeah. Vista *still* doesn't seem to support sed, or even grep. I don't
know how anyone even gets anything done on Windows. :-D

> Now extend that to features in the language itself - that's a recipe for 
> chaos, because the POVRay you use on *nix may not necessarily have the 
> same functionality as the Windows version, and your scene files won't 
> actually render because of missing functionality.  You end up with an SDL 
> that is *not* portable.  Nonportability is BAD.
...
> That's a bit different than limiting the featureset of POVRay itself for 
> users of some OSes.

I am seeing your point.

In all fairness, there *are* platform-independent uses for this sort of
thing. How about being able to call Python from SDL? You don't want to
just hard-code links to Python in POV...because then the Perl and Ruby
hackers would get mad. ;-)

Anyway, I think we both agree on the fundamental points--cross-plaform
is good, and flexibility is also good. Possibly we're just disagreeing
on how this sort of feature would end up getting used.

In any case, POV bindings to external programs are probably not going to
happen, so this discussion is mostly moot, anyway.

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you want to cheat and look
at nature's source code.
    -- Mark Stock
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHARn+cCmTzQ++ZncRAnaJAJsHnJ80MGbPORS49u+t/sZj1uni8QCdE7XX
ORqhZ9bBxFYtHCOhXB2I9+M=
=YT2M
-----END PGP SIGNATURE-----

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:
> nemesis wrote:
> > I was thinking... the next Povray supposedly is going to be GPL.  Would you
> > guys find it feasible to ship it together with GCC?  My point is:
> > JIT-compilation is still a relatively new area and there aren't sufficient
> > open-source implementations out there.  But traditional ahead-of-time
> > compilation is easily achieved.  If it was possible for a povray SDL script
> > to be compiled before running, performance wouldn't be a problem any more.
>
> I really can't say how SDL would take to being compiled; I can say that
> GCC is going to be a little bit of overkill for our needs. ;-)
>
> Writing a new GCC frontend for SDL would be a big project in itself.

That's not what I had in mind:  we'd likely ship both GCC (for the backend
compilation) and a front-end language system capable of producing C code
which would in turn get compiled.  Many high level languages today target C
as a lowlevel portable assembly.

I certainly wouldn't like to program SDL in C (nor C++).  My point was to
adapt a particular high-level language to suit the needs of Povray SDL and
program in that subset.  An then, get it compiled to C, which would in turn
get compiled to native code by GCC.  Too much of a trouble?  chicken does it
in a single pass with a high-level script.

> > then, I could even suggest getting a Scheme implementation like chicken to
> > be a possible SDL frontend... :)
>
> If you want to get yourself lynched, sure... ;-)

No need to fear once you get past the parentheses (with proper indentation
and structural editing)...

but then again, perhaps we should stop daydreaming and first help rewrite
all that old C/C++ code...

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bruno Cabasson wrote:
> > -) What are the current langages supporting JIT? What are their
> > performances?
>
> How about the Java runtime? Sun has already opened up the parts that
> we'd actually need. (We have no use for the Java class libraries, and
> once you strip those out the runtime binaries are only a couple
> megabytes in size.)
>
> > -) What are the langages which are best cross-platform and OS-independent?
>
> Some of the existing Open Source JVMs support more processors than Sun's
> OpenJDK; at the same time, Sun's implementation seems to be better
> optimized on those platforms that are supported.
>
> - --
> William Tracy
> afi### [at] gmailcom -- wtr### [at] calpolyedu

Java provides many of what has been evocated (OO, modularity, JIT,
platform/OS comptibility, etc ..). But how could we take advantage of it
without ending with something too heavy?

Java cannot be the choice for the rendering engine for obvious performance
reasons, but it might be a good candidate for the language/syntax aspect,
provided we can define some restrictions and rules. But I absolutely don't
know what and how ... Alladin's lamp welcome! (Might be a good name for
something, no? You just polish, and something magic comes out!)

Java provides JNI, an interface for external libraries, with the concern
that was evocated earlier in the thread, but which might be a 'ready-made'
solution.

OTOH, I cannot imagine we can do something new and entirey specific from
scratch. It represents way too much work and maturation.

We can (have to) reuse POV syntax, augment it with the new features, keep
the POV spirit. We can write an efficient and powerful rendering engine,
whatever language it is written in, the pure technical/math part is never
much of a problem. And we have some skilled and genius people here. My
opinion is that the difficulty resdes in between, between the syntax itself
and the rendering engine.

In conclusion, we have the following chain:

Features -> Syntax -> Parse and make features take form -> Rendering engine

And the related questions:

WHAT features? (not answered yet, first thing to do)
WHAT syntax? (not answered yet, in conjuction with features)
HOW linguistic features are implemented? (here resides the core problem and
main choices, possibly needs loop-back with features for compromise)
HOW the rendring engine is implemented? (only technical, not easy at all but
not really blocking)

People here can write some significant pieces of code to illustrate features
they have in mind with the syntax they envision, or to show what they would
have liked to have at least once in their POVer's life, and blocked them
more or less. Can we open a new group for that purpose? Or use rather the
povray.programming group?


    Bruno

Post a reply to this message

William Tracy escribió:
> In all fairness, there *are* platform-independent uses for this sort of
> thing. How about being able to call Python from SDL? You don't want to
> just hard-code links to Python in POV...because then the Perl and Ruby
> hackers would get mad. ;-)

I honestly don't know either of those three languages. What about PHP? :P

Post a reply to this message

> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> And if the shader language is, in fact, an existing language, like C or Ruby,
>> or any smart choice, making use of POV-Ray-specific classes, efficient
>> compilation shouldn't be a problem (I think).
> 
>   There's a difference between something being inside the core C++ codebase,
> and something JIT-compiled at runtime.
> 
>   Modern C++ compilers are quite good at optimizing, and it would be quite
> hard for the JIT-compiler of any given scripting language to match that
> level of optimization.
> 
>   Even if some JIT-compiler of some scripting language would achieve the
> same speeds, the C++ compiler still has some advantages, such as being
> able to inline certain functions for added speed (which naturally cannot
> be done with JIT-compiled functions because they are unknown at the core
> code compilation stage). Not that this matters a whole lot, but still.
> 

So why not use a modern C++ compiler for JIT? Have a look at this:

http://www.cip.physik.uni-muenchen.de/~wwieser/render/povray/patches/jitc-patch/

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> So why not use a modern C++ compiler for JIT? Have a look at this:
>
> http://www.cip.physik.uni-muenchen.de/~wwieser/render/povray/patches/jitc-patch/

really cool!  sad it's last version is from 2004.  That's the kind of thing
I have in mind, though I'm not sure it can be appropriately called a JIT...

Post a reply to this message

William Tracy nous apporta ses lumieres en ce 2007/09/30 18:37:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alain wrote:
>> There is a way, it's called "sandboxing". The process runs in a limited,
>> closed, virtual machine and only have access to what YOU want it to see.
> 
> So, you propose that every time POV code loads an external program, you
> launch a full-scale virtual machine? Are we going to license something
> from VMware? Are you going to ask people to buy extra licenses from
> Microsoft for the copies of the operating system running inside the VM?
> (Jeez, I'm starting to sound like Warp.)
> 
> Sandboxing is great for your language's own scripts/bytecode, but is
> less than helpful for _external_ libraries and arbitrary programs, which
> is what we were talking about.
> 
> - --
> William Tracy
You don't need a full-scale virtual machine, only a prety limited one only 
supporting what you need it to support. You don't need to launch several of 
those, you can reuse the same one for several modules. How about one that 
simulate some opensource, limited linux-like environment. In fact, you may not 
even need to have an OS running in that sandbox! A little like running a ROM 
based application on a diskless box. That way, you gain an OS independance, 
whitch allows you to use those external modules regardless of what OS you use.

-- 
Alain
-------------------------------------------------
What happens if you get scared half to death twice?

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruno Cabasson wrote:
> Java provides many of what has been evocated (OO, modularity, JIT,
> platform/OS comptibility, etc ..). But how could we take advantage of it
> without ending with something too heavy?

Remove the Java class libraries. :-) Seriously, the VM itself is not
that bad.

> Java cannot be the choice for the rendering engine for obvious performance
> reasons, but it might be a good candidate for the language/syntax aspect,
> provided we can define some restrictions and rules. But I absolutely don't
> know what and how ... Alladin's lamp welcome! (Might be a good name for
> something, no? You just polish, and something magic comes out!)

I'm not suggesting Java the _language_, I was suggesting the Java _VM_.

That said, now that I've thought about it, Mono might be a better
choice. Much as I dislike using something that has Microsoft's fingers
in it, .Net is much better suited to building other languages on. The
Java VM is fairly tied to the Java language (though that is improving,
these days).

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when your 18 year-old daughter
asks if she can marry one of the POV Team, and you give her your
complete blessing.
    -- Taps a.k.a. Tapio Vocadlo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAVhocCmTzQ++ZncRAhAOAJ9bZ5/kDQfiSCg/p7kSaamAeAGhswCdGdK2
J2AEP1Qp2LSFsEiXC3gVOhI=
=9S33
-----END PGP SIGNATURE-----

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alain wrote:
> You don't need a full-scale virtual machine, only a prety limited one
> only supporting what you need it to support. You don't need to launch
> several of those, you can reuse the same one for several modules. How
> about one that simulate some opensource, limited linux-like environment.
> In fact, you may not even need to have an OS running in that sandbox! A
> little like running a ROM based application on a diskless box. That way,
> you gain an OS independance, whitch allows you to use those external
> modules regardless of what OS you use.

I think we've been talking past each other here. :-P I'm assuming that
"external libraries" means being able to execute arbitrary, existing
software. I can't think of any good Windows examples (launch Halo, do a
screen capture, and use it as a texture?), but it would be cool to, say,
 automatically run ffmpeg to convert your frames into a move, or run the
Gimp in batch mode to do post-processing (automatic convert to jpeg?).
Maybe control X10 devices from SDL? ;-)

Now that I've read your description, though, I'm intrigued. You're
talking about only running programs written _for_ this POV virtual
machine? In that sense, it would be a sort of heavyweight extension to
the SDL.

You could have your run-of-the-mill SDL code running in an interpreter
heavily optimized for speed, and then have the option of launching this
VM code when you need flexibility more than speed.

That's kind of cool. :-)

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when your electricity bill is
extortionate because you refuse to let any rooms in your house be unlit,
even overnight.
    -- Richard Morton
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAVq8cCmTzQ++ZncRAgAUAKCVIea1K+62Yl4Cevbqd9zIczK0SgCfbbZ7
kY0JEseEoF+C7azbi6s1BSs=
=SXSO
-----END PGP SIGNATURE-----

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry, now that I've re-read your post...

Bruno Cabasson wrote:
> People here can write some significant pieces of code to illustrate features
> they have in mind with the syntax they envision, or to show what they would
> have liked to have at least once in their POVer's life, and blocked them
> more or less. Can we open a new group for that purpose? Or use rather the
> povray.programming group?

+1 on creating a povray.v4 discussion group. :-)

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you collapse in the middle
of a sermon in church, mumbling about CSGs, #declares, and finishes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAVuGcCmTzQ++ZncRAlmSAJ9bE18avq9u5Tzfy56Sgp/spCA0kwCfQ6JG
s/kePTx1jvhdO0xhWeCXNB0=
=3jgN
-----END PGP SIGNATURE-----

Post a reply to this message