"jr" <cre### [at] gmailcom> wrote:

> good thought, yes.  (and your hunch that the problem lies in the .inc was spot
> on too)

I kinda thought it had to do with the fore_call, but I didn't catch that it was
the #if statement operating ON the fore_call that was the real issue.
TOK to the rescue again.

> I'm not yet quite sure how, but the code needs to be .. re-structured.
> one/the concern is the size of the .inc file; ironically,  the "troublesome"
> 'fore_call()' was written to reduce duplication of code within the "walkers".

Can't you just add the sphere right after the #if, or just add an #else,
depending on when you want the sphere instantiated?

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> > good thought, yes.  (and your hunch that the problem lies in the .inc was spot
> > on too)
>
> I kinda thought it had to do with the fore_call, but I didn't catch that it was
> the #if statement operating ON the fore_call that was the real issue.
> TOK to the rescue again.
>
> > I'm not yet quite sure how, but the code needs to be .. re-structured.
> > one/the concern is the size of the .inc file; ironically,  the "troublesome"
> > 'fore_call()' was written to reduce duplication of code within the "walkers".
>
> Can't you just add the sphere right after the #if, or just add an #else,
> depending on when you want the sphere instantiated?

as I said, not quite sure.  over the coming days I'll do two things: move the
logic of 'fore_call' into the "walker" macros -- 9 items :-(, and re-write the
interface to 'Foreach(array,dictionary)', which will get rid of 'fore_verbose',
give the user named flags (no quite enum, but hey), and keeps all arguments in
one place.


regards, jr.

Post a reply to this message

"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