hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > (do you need to top up caffeine level?  :-))
>
> Yes.
> Though with what you've got going on, I'm gonna need either some crystal meth -
> or a crystal ball - to see how you've gone and broken things this time.   :P

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


> ...
> > (and please give it a whirr with some "normal" macros.  any errors?)
> Give WHAT a whirr...

the 'Foreach()'.  I'm sure you've plenty data (lingering in arrays).  if the
payload macros just do calculations etc, I'd expect it to run w/out issues.


> > yes, self prefers braced blocks (think Tcl), eg '#for () { ... }'.
>
> Well, yes, that would be functional.
>
> But I would still prefer #endif #endfor #endwhile #endmacro
> as it would allow some interesting coding that wouldn't otherwise be possible

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


regards, jr.

Post a reply to this message

"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