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

> </grin>  thanks.  can do with some lightheartedness.  :-)

No, truly.  You're busting in on my turf.
I have not seen such a tangle of ever-changing errors and line numbers since the
last 4 times I broke POV-Ray.
This is a real head-scratcher you've coded up.


> intrigued.  what can you not do with just '#end's?

http://news.povray.org/povray.advanced-users/thread/%3Cweb.5ba2723e83bd6a1ec437ac910%40news.povray.org%3E/

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...

I was also trying to simplify reading ASCII stl files in, and since they are SO
similar to the mesh {} syntax, an alias or ignore or error trapping or a
comma-free #read from file mechanism would be really nice to process external
files with....

I suppose after I get some of the mountain of SDL POV-Ray stuff off my plate, I
should really start learning to read the source code more accurately and figure
out how to add functionality to it.

Post a reply to this message

On 4/3/21 2:37 PM, jr wrote:
> hi,
> 
...

Hi jr,
I'm short on time; busy with real life for a few days.

I did quickly run your code with my current povr branch recompiled with 
my new --disable-no-lc-identifiers ./configure option or aka -jr ;-).

My branch has all the parser fixes identified since the last v3.8 
commit. I see the issue too so none of those a help.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I'm short on time; busy with real life for a few days.
>
> I did quickly run your code with my current povr branch recompiled with
> my new --disable-no-lc-identifiers ./configure option or aka -jr ;-).

</grin>  _like_


> My branch has all the parser fixes identified since the last v3.8
> commit. I see the issue too so none of those a help.

thank you, good (or rather not) to know that 'povr' gives same result.  hope yr
schedule will leave you time for coffees.  :-)


regards, jr.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> > intrigued.  what can you not do with just '#end's?
>
>
http://news.povray.org/povray.advanced-users/thread/%3Cweb.5ba2723e83bd6a1ec437ac910%40news.povray.org%3E/

still not entirely clear, will try and re-read this (interesting) thread later.


> 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...

some mechanism like that seems useful, it would need to "loadable on demand", ie
abstracted into its own include.


> I was also trying to simplify reading ASCII stl files in, ...

check yr inbox.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> I've run into a problem which I cannot understand.  I'm working on a 'Foreach'
> macro, to process arrays.  it works as expected, except..
>
> the below shows the error message I'm getting when I try to create an object
> from within the "payload" macro; first run displays the values supplied from an
> array, with the offending line (208) commented out.
>...

Hi jr

I suspect that your problem is that your bigSphere and mkSphere macros insert
the code for a sphere as the argument to the ! (logical not) operator.

I think it is happening in this line in your fore_walker1D macro:

      #if (!fore_call(a_,cmd_,fore_flagBoolean(f_)))

--
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:
> > ...
> > the below shows the error message I'm getting when I try to create an object
> > from within the "payload" macro; ...
>
> I suspect that your problem is that your bigSphere and mkSphere macros insert
> the code for a sphere as the argument to the ! (logical not) operator.

first off thank you for taking a look.  appreciated.


> I think it is happening in this line in your fore_walker1D macro:
>
>       #if (!fore_call(a_,cmd_,fore_flagBoolean(f_)))

you mean the parser (ultimately) emits code like '#if (!sphere {...})'?  that
would certainly explain the expect numeric expression message.  disclaimer first
:-): I know nothing of the POV-Ray parser or its internal "voodoo"
managing/unwinding the call stack, and (all) too little about parsing in
general.

when I look at the 'fore_call()' macro code, given that the "payload" is a
void-type macro, the '#else' branch (line 106) will be used.  I expect(ed) the
sphere to be inserted replacing line 107.  certainly, when debug is enabled, the
subsequent '#debug concat()' always displays the value it's received in line
108.  so, not knowing the parser etc, how [cw]ould the sphere code wind up in
'fore_walker1D'?


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> > > ...
> > > the below shows the error message I'm getting when I try to create an object
> > > from within the "payload" macro; ...
> >
> > I suspect that your problem is that your bigSphere and mkSphere macros insert
> > the code for a sphere as the argument to the ! (logical not) operator.
>
> first off thank you for taking a look.  appreciated.
>
>
> > I think it is happening in this line in your fore_walker1D macro:
> >
> >       #if (!fore_call(a_,cmd_,fore_flagBoolean(f_)))
>
> you mean the parser (ultimately) emits code like '#if (!sphere {...})'?  that
> would certainly explain the expect numeric expression message.  disclaimer first
> :-): I know nothing of the POV-Ray parser or its internal "voodoo"
> managing/unwinding the call stack, and (all) too little about parsing in
> general.
>
> when I look at the 'fore_call()' macro code, given that the "payload" is a
> void-type macro, the '#else' branch (line 106) will be used.  I expect(ed) the
> sphere to be inserted replacing line 107.  certainly, when debug is enabled, the
> subsequent '#debug concat()' always displays the value it's received in line
> 108.  so, not knowing the parser etc, how [cw]ould the sphere code wind up in
> 'fore_walker1D'?

You don't have to know a lot about the parser. You only have to pay attention to
what the macros "insert" or "leave behind".

The fore_call macro inserts two items: a call to the fore_exec macro and the
number 1.

And the call to the fore_exec macro inserts the contents of the parse_fore.tmp
file, which is this: bigSphere(7,a_[7])

That call to the bigSphere macro again calls the mkSphere macro, which inserts
the sphere { } statement.

Now the resulting if statement looks somewhat like this:

#if (! sphere { } 1)

- and that's not good...

--
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:
> > ...
> You don't have to know a lot about the parser. You only have to pay attention to
> what the macros "insert" or "leave behind".
>
> The fore_call macro inserts two items: a call to the fore_exec macro and the
> number 1.
>
> And the call to the fore_exec macro inserts the contents of the parse_fore.tmp
> file, which is this: bigSphere(7,a_[7])
>
> That call to the bigSphere macro again calls the mkSphere macro, which inserts
> the sphere { } statement.
>
> Now the resulting if statement looks somewhat like this:
>
> #if (! sphere { } 1)
>
> - and that's not good...

:-)

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 :-))


regards, jr.

Post a reply to this message

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...

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> 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.

good thought, yes.  (and your hunch that the problem lies in the .inc was spot
on too)  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".


regards, jr.

Post a reply to this message