POV-Ray : Newsgroups : povray.news-submissions : Semi-official development build v3.7.1-alpha.8141620 Server Time
21 Dec 2024 11:41:59 EST (-0500)
  Semi-official development build v3.7.1-alpha.8141620 (Message 1 to 1 of 1)  
From: clipka
Subject: Semi-official development build v3.7.1-alpha.8141620
Date: 24 Jun 2015 20:32:09
Message: <558b4c09$1@news.povray.org>
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

From: And
Subject: Re: Semi-official development build v3.7.1-alpha.8141620
Date: 1 Jul 2015 06:40:02
Message: <web.5593c2d9bf6fcc76c8c73900@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.