|
![](/i/fill.gif) |
"Lurker" <sha### [at] night com> wrote in message
news:40664bea@news.povray.org...
> </lurker>
>
> Hello everybody,
>
> I'm new to this group and never posted before, my knowledge about POV-Ray
is
> really small. That said, I'd wanted to point peoples interrested about the
> scripting abilities to a few ressources about Parrot, the next Perl 6 VM:
Hmm... I'm not sure if this will really work. Parrot is a VM for
programming languages; that is, the compiled bytecode is interpreted. Any
kind of compiled byte-code for POV-Ray is, essentially, data rather than
machine instructions. As such, it's hard to justify needing *any*
interpreter other than the rendering engine.
> Development time: Someone said that POV-Ray developers should spend more
time
> working on the rendering engine than on the parsing one.
Just because someone said it, isn't necessarily true. I think work on the
parsing engine is pretty important, at least for complex scenes. Anyway, I
haven't seen work on the parser conflict with work on the renderer, but I
also am not a member of the TAG or the POV team.
> - Language choice: peoples proposed lua, mono, perl, python, tcl, and
other
> scripting languages. Here is what's in the languages directory of the last
You can already use those language to generate POV-Ray scene code, but they
wouldn't work for actually scene files. In fact, most of them would be
worse for scene files than the POV-Ray SDL.
> Of
> course POV-Ray probably doesn't need all the CPAN modules, but, admit it,
'use
> Moon::Phase; use Weather::Underground;' might come handy to add some
realistic
> features to a scene, no? ;-)
This is already possible quite easily with #include files (well, the use
is - writing these features is as difficult as ever, and another
interpreting language won't change that :)
> - Sandboxing: Some people suggested that too much scripting abilities
might be
> harmful, in the form of trojans, exploits, etc. As every decent scripting
While the possibility of a POV-Ray virus has been mentioned, I/O
restrictions seriously limit this threat.
--
...Chambers
http://www.geocities.com/bdchambers79
Post a reply to this message
|
![](/i/fill.gif) |