Something I miss: eval directive that would evaluate the string given to
it as an SDL statement.

It isn't too hard to write a macro that does it:

#macro Eval( string )

 #fopen TMP "eval_file.tmp" write
 #write( TMP, string )
 #fclose TMP
 #include "eval_file.tmp"

#end

, but it sure ain't pretty...

Is there a better way to do this? Or is there a directive I have missed?

Of equal value would be a way to pass commands to the system, but aside
from the INI-options I cannot for the life of me figure out how to do it.

The reason I am crossposting this to povray.programming is because I
woudn't mind having a knowledgeable answer to the difficulty of
implementing such eval and system directives in povray-proper.

I have a reasonable background in programming, including some knowledge of
interpreters, but no familiarity what-so-ever with the povray source.

 -- Nikodemus

Post a reply to this message

In povray.programming Nikodemus Siivola <tsi### [at] cchutfi> wrote:
: Something I miss: eval directive that would evaluate the string given to
: it as an SDL statement.

  It's not missing in POV-Ray 3.5 anymore. See 'Parse_String()' in
the section 7.17 of the documentation.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

On Sun, 9 Sep 2001 15:29:32 +0300, Nikodemus Siivola wrote:
>The reason I am crossposting this to povray.programming is because I
>woudn't mind having a knowledgeable answer to the difficulty of
>implementing such eval and system directives in povray-proper.

There was a patch at one time that implemented a system-like directive.
In fact, I think it was even called "system."  Such a patch has serious 
security implications, so you'll probably never see it in the official
POV-Ray, and it's a violation of POVLEGAL, so you'll never see it in a
legal unofficial version either.

-- 
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions

Post a reply to this message

>   It's not missing in POV-Ray 3.5 anymore. See 'Parse_String()' in
> the section 7.17 of the documentation.

And there's a bug in it... see p.b-t ;)

 -- Nikodemus

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote:

> There was a patch at one time that implemented a system-like directive.
> In fact, I think it was even called "system."  Such a patch has serious
> security implications, so you'll probably never see it in the official
> POV-Ray, and it's a violation of POVLEGAL, so you'll never see it in a
> legal unofficial version either.

Maybe in 4.0/derivatives then, since having just read the license it is
given to understand that a more liberal license maybe coming up?

As for the security implications, it would IMO be next to trivial to
implement a switch that would turn of all potentially harmful
functionalities (system and fwrite, for example), or even better: function
along the lines of taint checks in various other languages (Perl and Ruby
come to mind).

   -- Nikodemus

Post a reply to this message

On Mon, 10 Sep 2001 01:23:39 +0300, Nikodemus Siivola wrote:
>Maybe in 4.0/derivatives then, since having just read the license it is
>given to understand that a more liberal license maybe coming up?

Do reflect on the fact that 4.0 will be a complete rewrite and that 3.5
took this long to get out.  I wouldn't make any short-term plans around
4.0.

>As for the security implications, it would IMO be next to trivial to
>implement a switch that would turn of all potentially harmful
>functionalities (system and fwrite, for example), or even better: function
>along the lines of taint checks in various other languages (Perl and Ruby
>come to mind).

The difference is that an entire POV script should be viewed as possibly
tainted, because we don't know its provenance.  In Perl, you usually know
the provenance of the script file and are only concerned about the user
input.  As for adding a switch, yes, that could be done along the lines of
the current I/O restrictions.  It's not something that's been seen as a high
priority.  What are you wanting to do with system that you can't do with a
preframe shellout?

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message:

> Do reflect on the fact that 4.0 will be a complete rewrite and that 3.5
> took this long to get out.  I wouldn't make any short-term plans around
> 4.0.

Don't worry - planning isn't my strong suite... ;) Seriously, though I
cannot help but wonder what baselines has the team set for 4.0:

- how open will the development model be
- what will the license be
- in what direction will the SDL go

> priority.  What are you wanting to do with system that you can't do with
a
> preframe shellout?

Basically I just don't like not being able to call the system during
parsing. I don't like being sandboxed -- but since you asked: ;)

For example:

    #while( i < n )
        #if( i == k )
            system( "makestone -10 -r -fm2 -o stone.mesh2" )
            #declare Stone = #include "stone.mesh2"
        #else
            object{ Stone translate Trans(i) )
        #end
    #end

Now imagine the stone being a huge mesh...

It would be even better if I could treat the STOUD of another program as
being cut and pasted into where the system directive was:

    #declare Stone = system( "makestone -10 -r", pipe )


...yeah. I realize it is not a priority. ;(

 -- Nikodemus Siivola

Post a reply to this message

Nikodemus Siivola wrote:

> As for the security implications, it would IMO be next to trivial to
> implement a switch that would turn of all potentially harmful
> functionalities (system and fwrite, for example), or even better: function
> along the lines of taint checks in various other languages (Perl and Ruby
> come to mind).

RubyPOV Mmmmmm...
 I'd like to see that!

Post a reply to this message

On Mon, 10 Sep 2001 11:07:41 +0300, Nikodemus Siivola wrote:
>
>"Ron Parker" <ron### [at] povrayorg> wrote in message:
>
>> Do reflect on the fact that 4.0 will be a complete rewrite and that 3.5
>> took this long to get out.  I wouldn't make any short-term plans around
>> 4.0.
>
>Don't worry - planning isn't my strong suite... ;) Seriously, though I
>cannot help but wonder what baselines has the team set for 4.0:

The short answer is that we haven't thought about 4.0 at all.  We're still
working on 3.5.


-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

"Daniel Matthews" <dan### [at] 3-enet> wrote:

> RubyPOV Mmmmmm...
>  I'd like to see that!

Actually I was already working on one -- a Ruby based SDL that
translates/exports into POV. It is on hiatus right now, since I am
wondering what I actually want to do with it: for example should it
implement it's own trace, or just export traces to pov.

If you'd like to see it, just give me some ideas of what you would find
useful and sign up for work...

 - Nikodemus

Post a reply to this message