Am 31.05.2016 um 19:04 schrieb Bald Eagle:

> Just curious - will there be mixed data-type support in arrays, if there are
> tuple-style tricks?
> 
> Having arrays where different rows could be of different data types - scalars,
> strings, vectors, whatever...   would be VERY handy.
> 
> Pipe-dream here, but:
> Would you be able to have an array of faux-tuples?

Nope, nope and nope.

Tuple-/style/ /assignments/ it is, nothing more.

Implementing any other tuple-style tricks will be a PITA, thanks to the
clusterfuck we occasionally call a parser.

Post a reply to this message

On 31/05/16 20:24, clipka wrote:
> 
> Tuple-/style/ /assignments/ it is, nothing more.
> 
> Implementing any other tuple-style tricks will be a PITA, thanks to the
> clusterfuck we occasionally call a parser.
> 

... and there was me thinking that you were going to rewrite it ;-)

John
-- 
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Nope, nope and nope.
>
> Tuple-/style/ /assignments/ it is, nothing more.
>
> Implementing any other tuple-style tricks will be a PITA, thanks to the
> clusterfuck we occasionally call a parser.

I honestly get the impression that you're holding something back from us.  I
think that as someone who works so closely with the source code and inner
workings of POV-Ray, you ought to open up and tell us how you really feel.

I mean, if you've got something to say, just say it.  All this waffling and
couching things in layer upon layer of politically correct phraseology makes it
looks as if you're hiding something.






























:D

Post a reply to this message

On 5/31/2016 10:54 PM, Bald Eagle wrote:
> clipka <ano### [at] anonymousorg> wrote:
>
>> Nope, nope and nope.
>>
>> Tuple-/style/ /assignments/ it is, nothing more.
>>
>> Implementing any other tuple-style tricks will be a PITA, thanks to the
>> clusterfuck we occasionally call a parser.
>
> I honestly get the impression that you're holding something back from us.


Yes, don't beat about the bush.
We are all big boys here*. We can handle it. :)

*Unless Janet is lurking.


-- 

Regards
     Stephen

Post a reply to this message

Am 31.05.2016 um 23:54 schrieb Bald Eagle:

>> Implementing any other tuple-style tricks will be a PITA, thanks to the
>> clusterfuck we occasionally call a parser.
> 
> I honestly get the impression that you're holding something back from us.  I
> think that as someone who works so closely with the source code and inner
> workings of POV-Ray, you ought to open up and tell us how you really feel.
> 
> I mean, if you've got something to say, just say it.  All this waffling and
> couching things in layer upon layer of politically correct phraseology makes it
> looks as if you're hiding something.

:)

Post a reply to this message

With respect to scope,

I have a variable that I declare locally:

#local Steps = ....

I tried to:

#declare Steps = Steps;

and then use Steps outside of the macro - "undeclared identifier"   :(

I can't "hand-off" a local value to a global identifier of the same name?
or "redefine a local variable as a global variable" ?

Post a reply to this message

Am 2016-06-02 21:37, also sprach Bald Eagle:
> With respect to scope,
>
> I have a variable that I declare locally:
>
> #local Steps = ....
>
> I tried to:
>
> #declare Steps = Steps;
>
> and then use Steps outside of the macro - "undeclared identifier"   :(
>
> I can't "hand-off" a local value to a global identifier of the same name?
> or "redefine a local variable as a global variable" ?

Anti-patterns are apparently not supported in this case.


-- 
dik

Post a reply to this message

Am 03.06.2016 um 03:37 schrieb Bald Eagle:
> With respect to scope,
> 
> I have a variable that I declare locally:
> 
> #local Steps = ....
> 
> I tried to:
> 
> #declare Steps = Steps;
> 
> and then use Steps outside of the macro - "undeclared identifier"   :(
> 
> I can't "hand-off" a local value to a global identifier of the same name?
> or "redefine a local variable as a global variable" ?

POV-Ray 3.7 indeed provides no way to assign a value to a global
variable if there already exists a variable with the same name at any
"more local" scope.

However, POV-Ray 3.7.1 will introduce a mechanism to specifically access
identifiers at the global scope, allowing you to achieve the desired
effect using the following syntax:

    #declare global(Steps) = Steps;

The `global(IDENTIFIER)` pseudo-function will be available wherever the
"bare" identifier could be used, and will cause any local identifiers of
the same name to be ignored when resolving the identifier.

There will also be a corresponding `local(IDENTIFIER)` pseudo-function
to specifically access identifiers at the "most local" scope, causing
identifiers at any "less local" scope to be ignored.

This functionality is already available in the current development releases.

Post a reply to this message

So, I just finished hunting down an old post by Jaap Frank about working around
the official limitation on datan types in arrays.

Just thought I'd repost the link as a reminder, since that was 13 years ago.  :)

http://news.povray.org/povray.text.tutorials/thread/%3C3f13449b$1@news.povray.org%3E/

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I just finished hunting down an old post by Jaap Frank about working around
> the official limitation on datan types in arrays.
>
> Just thought I'd repost the link as a reminder, since that was 13 years ago.  :)
>
>
http://news.povray.org/povray.text.tutorials/thread/%3C3f13449b$1@news.povray.org%3E/

I hesitate to try to add to what clipka says but...

If you #declare anything in a #macro, it is a global variable and will be known
outside the #macro and will assign a value to that variable name outside the
#macro, which is, of course usually a bad idea. Defining and assigning values to
local variables inside a #macro is what #local is for.

You can use #local to re-assign values to #macro arguments, even though they
must already have been defined outside the #macro before they are passed.

The following will reliably export information out of a #macro using arguments.
Of course, you don't need to define an object inside a #macro, though I have
here.

#version 3.7;
global_settings{assumed_gamma 1.0}
//
#include "colors.inc"
//
#macro in_and_out(num_in,num_out,vec_out,arr_out)
//
  #local num_out = num_in + 2;
  #local vec_out = <num_in+1,num_in+2,num_in+3>;
  #local icount  = 0;
  #while(icount < num_in)
    #local arr_out[icount] = icount+1;
    #local icount = icount + 1;
  #end
//
  sphere{<0,0,0> num_in pigment{Red}}
//
#end
//
#declare MMM_in  = 5;
#declare MMM_out = 0;
#declare MMM_vec = <0,0,0>;
#declare MMM_arr = array[MMM_in];
//
in_and_out(MMM_in,MMM_out,MMM_vec,MMM_arr)
//
sphere{MMM_vec, 1 pigment{Green}}
//
#warning concat("Last value of the array = ",str(MMM_arr[MMM_in-1],8,3))
//
light_source{ <100,100,-300>, 1}
//
camera{orthographic  location<0,0,-200> look_at <0,0,0> angle 15}

Post a reply to this message