|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
https://github.com/c-lipka/povray/releases/tag/v3.7.1-alpha.8141620
Aside from fixing an issue with self-intersecting toruses, this build
provides some new extensions to the SDL syntax:
* The recently introduced tuple-style assignment syntax has been
extended to allow for arrays on the right-hand side, like so:
#declare A = array[10] { 0,1,2,3,4,5,6,7,8,9 };
#declare { E0, E1, E2 } = A;
or:
#declare { E0, E1, E2 } = array[10] { 0,1,2,3,4,5,6,7,8,9 };
(The latter may seem rather useless at first, until you consider that
the right-hand side might be generated by a macro.)
Note how the array size does not need to match the number of left-hand
side elements; the surplus array elements are simply ignored.
* The tuple-style assignment syntax has been extended to allow for
omission of elements on either side, or specifying an uinitialized
identifiers on the right-hand side, like so:
#declare ( A,,C ) = ( 1,2,3 );
#declare ( A, optional B, C ) = ( 1,,3 );
#undef Fnord;
#declare ( A,,C ) = ( 1,Fnord,3 );
#declare ( A, optional B, C ) = ( 1,Fnord,3 );
Right-hand side elements may only be uninitialized or omitted if the
corresponding left-hand side element is omitted or the "optional"
keyword is specified for it.
Note: If a right-hand side element is uninitialized or omitted, the
corresponding left-hand side element is /not/ undefined, but left
entirely untouched.
Note: Uninitialized array elements can /not/ be used on the right-hand
side, due to some quirks of the parser that would be hard to overcome.
However, when using the array variant of the tuple-style assignment,
elements of the array /may/ be uninitialized, like so:
#declare A = array[3];
#declare A[0] = 0;
#declare A[2] = 2;
#declare { E0,,E2 } = A;
#declare { E0, optional E1, E2 } = A;
* The macro syntax has been extended to allow for omission of
parameters, or specifying uninitialized identifiers as parameter values,
like so:
#macro Foo ( A, optional B, C ) ... #end
Foo ( 1,,3 )
Foo ( 1,Fnord,3 )
If a parameter in the macro call is uninitialized or omitted, the
parameter is undefined within the macro. As with tuple-style
assignments, a parameter may only be left empty or uninitialized if it
is declared with the "optional" keyword.
Note: As with the tuple-style assignment, uninitialized array elements
don't work here.
When a parameter is undefined within the macro, it may still be defined
as a global variable. To safely deal with this situation, a new
pseudo-function has been introduced to specifically refer to a local
identifier:
local ( IDENTIFIER )
When used in a macro, this will specifically access only macro
parameters, or identifiers defined as "#local" within that macro,
ignoring any "less local" identifiers. When used outside a macro in an
include file, it will specifically access only identifiers defined as
"#local" in that file.
Note: In the main file, this syntax is of no practical use outside of
macros, as the "most local" identifiers there are the global ones.
For instance, you can reliably test whether a macro parameter has been
left empty, or pass an optional parameter on to another macro,
regardless of whether a global identifier of the same name exists, like so:
#declare C = "not a problem for us";
#macro Bar ( A, optional B, optional C )
#ifndef(local(C))
#local C = 42;
#end
Foo (A, local(B), local(C))
#end
As an interesting side note, this also allows to test whether the
current file is an include file, like so:
#declare NotALocalIdentifier = 1;
#ifdef(local(NotALocalIdentifier))
#debug "We're in the main file.\n"
#end
* The array syntax has been extended to allow for omission of individual
elements in an initializer list, or specifying uinitialized identifiers
in such a list, like so:
#declare A = array[10] optional { 0,1,2,3,,Fnord,6,7,8,9 }
Again, elements may only be omitted or uninitialized if the "optional"
keyword is present.
Note: Again, uninitialized array elements can't be used in an array
initializer list, e.g. the following will not work:
#declare A = array[10] optional { 0,,,,,,,,,9 }
#declare B = array[2] optional { A[0], A[1] }
Please test and enjoy!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> https://github.com/c-lipka/povray/releases/tag/v3.7.1-alpha.8141620
>
> Aside from fixing an issue with self-intersecting toruses, this build
> provides some new extensions to the SDL syntax:
>
>
> * The recently introduced tuple-style assignment syntax has been
> extended to allow for arrays on the right-hand side, like so:
>
> #declare A = array[10] { 0,1,2,3,4,5,6,7,8,9 };
> #declare { E0, E1, E2 } = A;
>
> or:
>
> #declare { E0, E1, E2 } = array[10] { 0,1,2,3,4,5,6,7,8,9 };
>
> (The latter may seem rather useless at first, until you consider that
> the right-hand side might be generated by a macro.)
>
> Note how the array size does not need to match the number of left-hand
> side elements; the surplus array elements are simply ignored.
>
>
> * The tuple-style assignment syntax has been extended to allow for
> omission of elements on either side, or specifying an uinitialized
> identifiers on the right-hand side, like so:
>
> #declare ( A,,C ) = ( 1,2,3 );
> #declare ( A, optional B, C ) = ( 1,,3 );
>
> #undef Fnord;
> #declare ( A,,C ) = ( 1,Fnord,3 );
> #declare ( A, optional B, C ) = ( 1,Fnord,3 );
>
> Right-hand side elements may only be uninitialized or omitted if the
> corresponding left-hand side element is omitted or the "optional"
> keyword is specified for it.
>
> Note: If a right-hand side element is uninitialized or omitted, the
> corresponding left-hand side element is /not/ undefined, but left
> entirely untouched.
>
> Note: Uninitialized array elements can /not/ be used on the right-hand
> side, due to some quirks of the parser that would be hard to overcome.
> However, when using the array variant of the tuple-style assignment,
> elements of the array /may/ be uninitialized, like so:
>
> #declare A = array[3];
> #declare A[0] = 0;
> #declare A[2] = 2;
> #declare { E0,,E2 } = A;
> #declare { E0, optional E1, E2 } = A;
>
>
> * The macro syntax has been extended to allow for omission of
> parameters, or specifying uninitialized identifiers as parameter values,
> like so:
>
> #macro Foo ( A, optional B, C ) ... #end
> Foo ( 1,,3 )
> Foo ( 1,Fnord,3 )
>
> If a parameter in the macro call is uninitialized or omitted, the
> parameter is undefined within the macro. As with tuple-style
> assignments, a parameter may only be left empty or uninitialized if it
> is declared with the "optional" keyword.
>
> Note: As with the tuple-style assignment, uninitialized array elements
> don't work here.
>
> When a parameter is undefined within the macro, it may still be defined
> as a global variable. To safely deal with this situation, a new
> pseudo-function has been introduced to specifically refer to a local
> identifier:
>
> local ( IDENTIFIER )
>
> When used in a macro, this will specifically access only macro
> parameters, or identifiers defined as "#local" within that macro,
> ignoring any "less local" identifiers. When used outside a macro in an
> include file, it will specifically access only identifiers defined as
> "#local" in that file.
>
> Note: In the main file, this syntax is of no practical use outside of
> macros, as the "most local" identifiers there are the global ones.
>
> For instance, you can reliably test whether a macro parameter has been
> left empty, or pass an optional parameter on to another macro,
> regardless of whether a global identifier of the same name exists, like so:
>
> #declare C = "not a problem for us";
> #macro Bar ( A, optional B, optional C )
> #ifndef(local(C))
> #local C = 42;
> #end
> Foo (A, local(B), local(C))
> #end
>
> As an interesting side note, this also allows to test whether the
> current file is an include file, like so:
>
> #declare NotALocalIdentifier = 1;
> #ifdef(local(NotALocalIdentifier))
> #debug "We're in the main file.\n"
> #end
>
>
> * The array syntax has been extended to allow for omission of individual
> elements in an initializer list, or specifying uinitialized identifiers
> in such a list, like so:
>
> #declare A = array[10] optional { 0,1,2,3,,Fnord,6,7,8,9 }
>
> Again, elements may only be omitted or uninitialized if the "optional"
> keyword is present.
>
> Note: Again, uninitialized array elements can't be used in an array
> initializer list, e.g. the following will not work:
>
> #declare A = array[10] optional { 0,,,,,,,,,9 }
> #declare B = array[2] optional { A[0], A[1] }
>
>
> Please test and enjoy!
Thank you for the effort on updating pov-ray.
I would like to try it.
Post a reply to this message
|
|
| |
| |
|
|
From: James Holsenback
Subject: Re: Semi-official development build v3.7.1-alpha.8141620
Date: 10 Jul 2015 14:53:18
Message: <55a0149e$1@news.povray.org>
|
|
|
| |
| |
|
|
On 06/24/2015 08:32 PM, clipka wrote:
> https://github.com/c-lipka/povray/releases/tag/v3.7.1-alpha.8141620
<snip>
> Please test and enjoy!
better late than never i suppose ... builds fine on my nix platform:
ash@linux-c2bm:~/ScratchPad/povray/povray-3.7.1-alpha.8141620 $ povray
--version
POV-Ray 3.7.1-alpha.8141620.unofficial
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|