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

"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