"jr" <cre### [at] gmailcom> wrote:
>...
> :-)
>
> seriously though, thank you for this clear outline of "events".  excellent.  I
> seem to think too much in terms of (conventional) function/procedure when using
> SDL.  (time for coffee + thinking cap :-))

No problem. It was an interesting challenge to find out what was going on.
It can take a while to become familiar with how POV-Ray's macros really work and
how they can be best utilized.

Then back to your code:
How about writing out (appending ?) all the "user macro" calls to a file while
"walking" the array, and then include that file for parsing afterwards ?
If you do it that way then the fore_call macro can return a single value
suitable for the ! operator.

BTW: Are you aware that there are some macro parameters that are never used ?

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

hi,

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> >...
> > :-)
> >
> > seriously though, thank you for this clear outline of "events".  excellent.  I
> > seem to think too much in terms of (conventional) function/procedure when using
> > SDL.  (time for coffee + thinking cap :-))
>
> No problem. It was an interesting challenge to find out what was going on.
> It can take a while to become familiar with how POV-Ray's macros really work and
> how they can be best utilized.

too true.  (I fear :-))

> Then back to your code:
> How about writing out (appending ?) all the "user macro" calls to a file while
> "walking" the array, and then include that file for parsing afterwards ?
> If you do it that way then the fore_call macro can return a single value
> suitable for the ! operator.

the thought never occurred, and, to be honest, does not appeal.  too "indirect"
for me, I guess.  having said that, I see no reason why the user could not write
a payload macro to do that, where useful.


> BTW: Are you aware that there are some macro parameters that are never used ?

off-hand I can only think of 'a_' in the 'fore_call'.  I thought I'd need it
since the 'cmd_' string refers to it (and I thought expansion happens in line
107).

while on the subject, and given you seem interested :-), I'm pondering how to
reduce duplication of essentially identical/near identical code; am thinking
that an "odometer" type macro to compute the set of indices would allow me to
write much more "compact" walker macros.  any suggestions?  cheers.


regards, jr.

Post a reply to this message

I did a bit of hazy early-morning brainstorming.

You would be able to condense all of your nested #if statements if you were to
write the largest one but then be able to skip certain nest levels.

Can you use the parse thing to assemble a macro of the proper size on the fly?

Can conditionals be stored in an array?   Then you might be able to switch
between #if and // nothing and #end and // nothing as needed.

Do we have some clever way to do the equivalent of:

select (flag, conditional // comment)

or

(flag ? conditional : comment)

Because that would be wicked cool.

Post a reply to this message

Also, will any of these help?

https://stackoverflow.com/questions/25070766/nested-for-loops-recursion

https://corysimon.github.io/articles/recursion/

https://www.vitoshacademy.com/vba-nested-loops-with-recursion/


etc...


https://duckduckgo.com/?q=nested+loops+by+recursive

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I did a bit of hazy early-morning brainstorming.

(incorrigible  :-))

> You would be able to condense all of your nested #if statements if you were to
> write the largest one but then be able to skip certain nest levels.

the new code, published in p.t.scene-files a moment ago, is completely different
from previous.  for instance, only two walkers - void and bool.

> Can you use the parse thing to assemble a macro of the proper size on the fly?

don't see why it could not be used for that.

> Can conditionals be stored in an array?   Then you might be able to switch
> between #if and // nothing and #end and // nothing as needed.

never tried.  :-)


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
>...
> while on the subject, and given you seem interested :-), I'm pondering how to
> reduce duplication of essentially identical/near identical code; am thinking
> that an "odometer" type macro to compute the set of indices would allow me to
> write much more "compact" walker macros.  any suggestions?  cheers.

Bill's recent suggestion to you made me think of ways to iterate over the
indices of an array.

As my favorite programming language is Python, I tried out my ideas there.

So if you are familiar with Python, have a look at attached PDF-file.
The code in the 2 last cells shouldn't be hard to convert to POV-Ray's SDL.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

Attachments:
Download 'iterate over an array.pdf' (42 KB)

hi,

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> >...
> > while on the subject, and given you seem interested :-), I'm pondering how to
> > reduce duplication of essentially identical/near identical code; am thinking
> > that an "odometer" type macro to compute the set of indices would allow me to
> > write much more "compact" walker macros.  any suggestions?  cheers.
>
> Bill's recent suggestion to you made me think of ways to iterate over the
> indices of an array.
>
> As my favorite programming language is Python, I tried out my ideas there.

chalk and cheese.  when, years ago, I heard that Python requires one to use
specific whitespace in order for the code to be "correct", I lost interest.

> So if you are familiar with Python, have a look at attached PDF-file.
> The code in the 2 last cells shouldn't be hard to convert to POV-Ray's SDL.

I had a v quick look just now, there are unfamiliar operators (like '//') so I'm
not sure, but it looks like I hit on the right idea when reducing 'Foreach()' to
calling the payload "product of dims" times[*].  (must have lucked out :-))
I'll try and find some time in next days to see whether I can replicate yr PDF
code in Tcl.


regards, jr.

[*] 20-odd lines in SDL isn't too shabby.

Post a reply to this message

Am 04.04.2021 um 02:40 schrieb Bald Eagle:

> I was also thinking that since we don't have an 'alias' directive, we might be
> able to track the nesting level with something like:
> 
> #macro If (A)
>       #declare Level = Level + 1;
>       #if (A)
> #end
> 
> and then a corresponding EndIf () macro could decrement the counter...

... and here I am, trying to CLEAN UP the parser code...
*shrieks in horror*

Post a reply to this message

Am 04.04.2021 um 19:48 schrieb Bald Eagle:
> Instead of a boolean, return an integer flag to be further processed.
> (POV-Ray treats any non-zero value as "true")
> Then you can initially process the result as a boolean like you do, but then
> have a follow-up procedure that instantiates the sphere, maybe using #select.
> 
> Or maybe you can just do that with the simple "boolean" as well...

Just skimming the thread, but from what I'm gathering, it seems that the 
crux of the matter is that there's some construct where a macro would 
essentially have to emit ("return") _two_ values separately: A status 
result (boolean, apparently) that would have to be plonked into an 
`#if(BOOLEAN)`, and an object that would have to be plonked elsewhere.

Fun fact: Unless my memory has been badly scrambled in the days of my 
abscence, modern POV-Ray v3.8 can do such exciting stuff, using 
tuple-style assignments, like so:

     #declare (Foo,Bar) = (VALUE1,VALUE2);

This allows you to design a macro that is structured like so (and as a 
matter of fact the syntax was introduced for exactly this very purpose):

     #macro Frobnitz()
         // Construct the stuff we want to emit ("return")
         #local V1 = ...;
         #local V2 = ...;
         // Actually emit ("return") the stuff, tuple-style
         (V1,V2)
     #end

And then invoke it from some other code like so:

     #declare (Foo,Bar) = Frobnitz();
     // test for `Foo`
     #if(Foo)
         // emit `Bar` to actually plonk it into the scene
         object { Bar }
     #end

Hope this helps.

Oh, and in case you have a macro that may not have an object to emit as 
the second value, try this (IIRC think it should work):

     #macro Frobnitz()
         #if(GOOD)
           #local V2 = ...;
           (true,V2)
         #else
           (false,)
         #end
     #end

And then invoke it from some other code like so:

     #declare Bar = sphere { ... } // provide default for Bar
     #declare (Foo, optional Bar) = Frobnitz();
     // test for `Foo`
     #if(Foo)
         // emit `Bar` to actually plonk it into the scene
         object { Bar }
     #end

(I'm not 100% sure I recall the `optional` semantics properly; IIRC it 
leaves the variable unchanged if no value is given, but it might also 
set it to undefined instead. Also, I'm not 100% the comma in `(false,)` 
is necessary or not. It's docomented... somewhere.)


Oh, and of course array- and vector-style assignments were also 
introduced on that occasion, just for funsies:

     #declare A = array[2] {VALUE1,VALUE2};
     #declare [Foo,Bar] = A; //(*)

     #declare V = <VALUE1,VALUE2>;
     #declare <Foo,Bar> = V;

(*) I _think_ that was the syntax. Mighth have been curly braces instead 
of square brackets though, i.e `#declare {Foo,Bar} = A;`. Again, it's 
documented... somewhere.

Post a reply to this message

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

> ... and here I am, trying to CLEAN UP the parser code...
> *shrieks in horror*

"No one expects the Spanish Inquisition!"

Yeah - I'm not personally editing anything in that source code any time soon.
But I will do a few backflips on the SDL side to create some ugly hacks that
mimic the desired functionality.  As much as it sucked to implement, it worked
quite nicely, and I added some other things to invoke identifiers by numeric
identifier (so I could easily loop through all the defined objects in the scene
file) or an alias.

Gave a nice nesting diagram in the #debug stream too, labeling the entry and
exit of each control structure with a user-defined label.

Post a reply to this message