On 12/11/2015 01:20 AM, Mike Horvath a dit:

> I think basing things of SVG would be a good idea. I.e. XML + SMIL +
> JavaScript.

    XML is just a giant garbage.

-- 
http://foo.bar.quux.over-blog.com/article-thsf-2013-114632120.html

Post a reply to this message

> On 12/11/2015 01:20 AM, Mike Horvath a dit:
>
>> I think basing things of SVG would be a good idea. I.e. XML + SMIL +
>> JavaScript.
>
>     XML is just a giant garbage.
>

I think that you may over-react to some degree here.
XML does have some very legitimate uses, the real problem, is that's it 
have been abused in ways that where unintended to do things that are not 
supposed to be supported.
The base is mostly OK.
The abuse IS garbage.

Post a reply to this message

> Please notice, I wrote "If I was crazy".
>
> of course C++11/14/17 could be abused with initialiser list in
> constructor for:
>
> scene += Cone( {0,0,0},{0,1,0}, 2);
>
> that is just a matter of supported syntax for any language, I took
> C++, but it would be the same with any other.

I've got a good scene:

scene += Cone( {0,0,0},{0,1,0}, 2);
std::remove("some important file");

Is there any way to limit what damage a compiled C++ program can do?

Post a reply to this message

Am 14.12.2015 um 09:41 schrieb scott:
>> Please notice, I wrote "If I was crazy".
>>
>> of course C++11/14/17 could be abused with initialiser list in
>> constructor for:
>>
>> scene += Cone( {0,0,0},{0,1,0}, 2);
>>
>> that is just a matter of supported syntax for any language, I took
>> C++, but it would be the same with any other.
> 
> I've got a good scene:
> 
> scene += Cone( {0,0,0},{0,1,0}, 2);
> std::remove("some important file");
> 
> Is there any way to limit what damage a compiled C++ program can do?

Absolutely.

If by "compiled" you really do mean "compiled", it's as easy as
permitting only linkage to a tightly controlled set of libraries, of
which you know that they can't possibly do any harm (which may require
providing a custom runtime library).

If by "compiled" you actually mean "built", i.e. compiled /and/ linked,
it's as "easy" as running the program in a virtual machine.

Post a reply to this message

>> I've got a good scene:
>>
>> scene += Cone( {0,0,0},{0,1,0}, 2);
>> std::remove("some important file");
>>
>> Is there any way to limit what damage a compiled C++ program can do?
>
> Absolutely.
>
> If by "compiled" you really do mean "compiled", it's as easy as
> permitting only linkage to a tightly controlled set of libraries, of
> which you know that they can't possibly do any harm (which may require
> providing a custom runtime library).

That sounds a lot of work, with still a small risk of someone finding a 
loophole to do something bad in their scene.

> If by "compiled" you actually mean "built", i.e. compiled /and/ linked,
> it's as "easy" as running the program in a virtual machine.

Sounds a lot of work too, so that it's transparent to the casual user 
that the scene is being rendered in a virtual machine.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >> I've got a good scene:
> >>
> >> scene += Cone( {0,0,0},{0,1,0}, 2);
> >> std::remove("some important file");
> >>
> >> Is there any way to limit what damage a compiled C++ program can do?
> >
> > Absolutely.
> >
> > If by "compiled" you really do mean "compiled", it's as easy as
> > permitting only linkage to a tightly controlled set of libraries, of
> > which you know that they can't possibly do any harm (which may require
> > providing a custom runtime library).
>
> That sounds a lot of work, with still a small risk of someone finding a
> loophole to do something bad in their scene.
>
> > If by "compiled" you actually mean "built", i.e. compiled /and/ linked,
> > it's as "easy" as running the program in a virtual machine.
>
> Sounds a lot of work too, so that it's transparent to the casual user
> that the scene is being rendered in a virtual machine.

I didn't say there's any /feasible/ way (nor did I mean to) - just that there
/is/ a way ;)

Post a reply to this message

Am 12.12.2015 um 13:27 schrieb clipka:
> Am 12.12.2015 um 09:32 schrieb Le_Forgeron:
> 
>> [cutting the very good list of expectations]
>>
>> Just beware of the NIH syndrome.
> 
> There's really nothing to beware there; if I could find a language out
> there that does suit POV-Ray's needs, I'd probably be the first to go
> for it; if nothing else, it would save us all the work of defining the
> new SDL in the first place; a pre-existing parser to just plug into
> POV-Ray would save a lot of work, too.

I /think/ I've found a language that might be suitable; at any rate, it...

(1) shares the design goal of providing both declarative and procedural
elements;

(2) has native support for /all/ of the domain-specific basic types we
would need (most notably vectors and colours);

(3) already covers a major subset of POV-Ray's language domain; and

(4) is already established, /specifically/ in the domain of 3D rendering.


Have a look at NVIDIA's Material Definition Language (MDL):

http://www.nvidia-arc.com/fileadmin/user_upload/iray_documentation/nvidia_mdl_introduction.140512.A4.pdf

http://www.nvidia-arc.com/fileadmin/user_upload/MDL_spec_1.2.2_28Apr2015.pdf

I think all we'd have to do is provide some intrinsic data types for
geometric shapes and some odds & ends (such as light sources, global
settings, etc.), and we'd have a useful Scene Description Language.

Is it pretty to use? Don't know yet.

Can we get Nvidia's implementation for free? Don't know yet, but I'd
doubt it. The language specs are open though, so we could write our own
parser.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> If I was crazy, I would use C++ and a compiler as the parser

This is actually not such an absolutely crazy idea. Consider that
Apple's Metal shading language (which is an alternative to glsl)
uses C++11 as its syntax (and AFAIK pretty much a C++11 compiler
to generate the shader binary). These shaders are compiled at
runtime rather than compile time (they are not compiled from
*within* the shader code, but from the calling code, but
nevertheless, it's done at runtime.)

Nowadays this would be extremely feasible because LLVM has been
designed from the ground up for precisely this kind of thing.

-- 
                                                          - Warp

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> > Still unnecessarily complex, as compared to (e.g.)
> > 
> > cone { <0,0,0>, <0,1,0>, 2 }
> > 

> Please notice, I wrote "If I was crazy".

> of course C++11/14/17 could be abused with initialiser list in
> constructor for:

> scene += Cone( {0,0,0},{0,1,0}, 2);

Actually I don't see a reason why this line of code:

    cone( { 0, 0, 0 }, { 0, 1, 0 }, 2);

couldn't add the cone to the (default) scene.

It could even work something like this:

    Cone( { 0, 0, 0 }, { 0, 1, 0 }, 2)
    .pigment( some pigment def here )
    .finish( some finish def here )
    .rotate(10, 20, 30)
    .scale(0.5, 1.0, 2.0);

-- 
                                                          - Warp

Post a reply to this message

Am 23.05.2016 um 18:02 schrieb Warp:
> Le_Forgeron <jgr### [at] freefr> wrote:
>> If I was crazy, I would use C++ and a compiler as the parser
> 
> This is actually not such an absolutely crazy idea. Consider that
> Apple's Metal shading language (which is an alternative to glsl)
> uses C++11 as its syntax (and AFAIK pretty much a C++11 compiler
> to generate the shader binary). These shaders are compiled at
> runtime rather than compile time (they are not compiled from
> *within* the shader code, but from the calling code, but
> nevertheless, it's done at runtime.)
> 
> Nowadays this would be extremely feasible because LLVM has been
> designed from the ground up for precisely this kind of thing.

Not specifically for C++, but yes.

Use of LLVM in a future POV-Ray SDL parser can be considered a given,
both for the scene in general and, even more importantly, any
user-defined "functions" (which will presumably be much more powerful
than they are now).

(Unless something even better than LLVM happens to pop up before we
actually start working on that new parser.)

Post a reply to this message