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

William Tracy escribió:
> 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? ;-)

That is already possible, since 3.something. Have you ever seen 
"shell-out commands"? Post_Scene_Command and stuff?

Post a reply to this message

"Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote in message 
news:web.47012662e7dc7428e8ba46670@news.povray.org...
> 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! (


    Mr. Gena Obukhov springs to mind here for some reason.


     ~Steve~









>    Bruno
>
>

Post a reply to this message

nemesis wrote:
> 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.

As Thorsten mentioned, check llvm.org.

-- Chris

Post a reply to this message

In article <web.47012662e7dc7428e8ba46670@news.povray.org>, 
bru### [at] alcatelaleniaspacefr says...
> 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?
> 
Umm.. Yuck! For two reasons>

1. The language isn't too friendly when it comes to figuring out what 
the heck its doing. Its almost as bad as C++, if you don't know it. 
Going so far towards that level of language is imho, unnecessary, 
especially if you sacrifice understandability.

2. We are dealing with a "lot" of data types here that are not handled 
when at all by "most" languages. Well, not without some overly 
complicated things to make it work anyway.

I would suggest something like Lua. It has more readability, less syntax 
pickiness, at least as much functionality, once you add "necessary" 
libraries, which most you won't need anyway. And its method of 
representing arrays allow you to *literally* drop complex data 
structures in to the array, for immediate use. For example, in the 
client I use it in, if you want to get data on something as simple as a 
line of text, you need to just push the data into a table in Lua, then 
access it like an array. The method for transferring such data "into" 
Lua is fairly trivial. Other languages *can't* handle the transfer of 
such structured data. They are forced to rely on creating multiple 
arrays, to hold each subtype of data. So while Lua uses a single table 
that looks like:

mytable (position)
  \---Letter
  \---Font
  \---Color
  \---Ect.

In *any* other language you need to do something like:

dim letter()
dim font()
dim color()
dim etc()

Then load **each** of those independently. From what I understand, it 
only gets worse if you are trying to cram such data across ActiveScript, 
but that issue isn't really relevant. Tables, and the ease of 
integration where *huge* factors in the client's maker deciding in favor 
of Lua, instead of every other option, including Java.

Put simply, if you wanted to make an array/table containing every aspect 
of a named object in POVRay, it would be relatively simple to do that in 
Lua. Doing it in any other language would instead require that you 
create a mess of function calls, to retrieve individual parts of the 
object, and manipulate them. I.e., it naturally produces a result that 
"looks" like:

Now, how you handle changing the content of a table, then having it take 
effect as an object, may be more complicated, but your looking at doing 
this:

table = getobject("myobject")
table.leg.rotate = ...
setobject("mynewobject", table)

Presuming that "setobject" used the data in "table" to generate the 
internal representation of all the data that was copied from the call to 
"getobject". In fact, this is, from what I understand, even how Lua 
links to external libraries. Its creates a table, which contains the 
functional layout of the data types it needs, the Lua function name and 
the reference address for the libraries entry points. When you make a 
call to something in Lua's IO libraries, its actually looking in the 
table for you function, like io.systemdate, then *calling* the external 
function referenced by that name in the table. You don't have to do 
anything but set up the table to point at the right things.

Its not hard to imagine how that type of flexibility in its most basic 
data manipulations could make handling a 3D scene easier to work with.

Mostly though, I just hate Java when it comes to syntax. lol I suppose I 
would have to learn if it was picked.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

In article <47015269$1@news.povray.org>, ele### [at] netscapenet 
says...
> 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 limite
d,
> >> closed, virtual machine and only have access to what YOU want it to se
e.
> > 
> > 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, whic
h
> > is what we were talking about.
> > 
> > - --
> > William Tracy
> You don't need a full-scale virtual machine, only a prety limited one onl
y 
> 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 ma
y 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 independanc
e, 
> whitch allows you to use those external modules regardless of what OS you
 use.
> 
> 
Actually, this isn't that horrible an idea. There are full linux-like 
environments that run off something as small as a floppy. You don't even 
need the console or video code, since the only data in/out is going to 
go through the engine and you can do the same thing that DOSBox does, 
and only "mount" specific folders, and subfolders, as valid places to 
run things from.

The only real issue is that this makes it hardly any better than just 
coding it all in the JIT anyway, since anything you wanted to run in it 
would have to be coded/recoded to run in that modified environment. 
Rewriting it as a module for the script language might be easier than 
writing it for the sandbox. And you "can" sandbox some languages too. 
The client application I have does that, defining the "io" and some 
other high risk libraries as "null", so that any attempt to call them 
generates a runtime error.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott wrote:

<snip long story about programming language>

In all this talk about this or that programming language I feel that one
question is being side stepped. Does POV really need a new language or can
all this be accomplished with a good spring cleaning of the SDL. Most of
the discussion going on at the moment is far too technically language
specific. Mind you, I know zip about the innards of any language, but I do
know that if and when the current SDL is replaced by something entirely
different you are going to upset a large portion of the POV user group.

And then there is that other discussion going on about what all one would
want inside POV. Do I want it to convert my images to JPG? Heck no. I want
them in a lossless format. Top quality. For the occasional post here I'll
compress it separately. Do I want POV to be able to create animations on
the go? Nope. There are plenty programs out there that will do a much
better job will all the thrills and frills of an editing studio. I
personally use MainActor and I don't see any way one could combine that
into POV. The same goes for any form of post processing. The best one can
do is a very limited form of The Gimp and the likes. 

Don't get me wrong. I'm not saying all these discussions are wrong but lets
not forget that POV needs 3 things most. Speed, more speed and some speed.
In my view POV is a (restructured) SDL and parser with a lean and mean
render engine behind it. 
-- 
Ger

Post a reply to this message