hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> > File 'fore_demo.pov' line 199: Parse Error: Expected 'numeric expression',
> >  sphere found instead
>
> Because it is looking for a numeric expression that you somehow left out.

hmm, the 'bigSphere' macro does work until one tries to instantiate an object,
it runs otherwise.  and, well, I cannot see anything amiss.

> When I insert a line before the sphere and put "0", I get:
>
> Possible Parse Error: Unmatched (
> at File: foreach.inc Line: 344 Col: 11
> Parse Error: No matching ), sphere found instead
>
> But then curiously, when I put "0)" I get:
>
> Parse Warning: Unbalanced ) in include file
> Parse Warning: Unbalanced } in include file
> Parse Error: Unbalanced #end directives in include file.

yes, as it should, having just a '0)' before the primitive.  I don't get the
line before thing but suspect it's for the same reason -- extra ("spurious")
characters.

as for adding more output in the include, the error does occur in the scene
file.  (btw, a 'bool' type payload with debug on will print return info).

thanks for looking.


regards, jr.

Post a reply to this message

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

> yes, as it should, having just a '0)' before the primitive.  I don't get the
> line before thing but suspect it's for the same reason -- extra ("spurious")
> characters.

Right on, but we're looking at "as it shouldn't".

I commented out the macro call in bigSphere  (look at you, using capital
letters... :o)  and put an actual sphere in its place.
Same error.

Put a 1 on the line above it.   Same error as last time.

But when I closed the ), this time I got

Parse Error: Unbalanced #end directives in include file.
at File: fore_demo.pov Line: 213 Col: 1
e[0] = 0  e[1] = 0  e[2] = 'one'  e[3] = 7.
Parse Warning: Unbalanced ) in include file

So the error gets triggered in the scene file, but seems to be actually due to
an omission in some nested thing in the include file.
Also, 213 is a different line than when I did the 0) in the mkSphere macro.

If you can't find the issue, you may have to resort to mapping the nesting
levels like I did in that blood cells scene.

Post a reply to this message

Further,
if I put a 2) before the #debug statement in bigSphere, it complains about line
_214_ instead.

You've got an extra ( somewhere that got injected or a missing ), or something
even harder to track down.

Just on the off chance:
The file is clean and has none of those weird non-ASCII characters, ...?

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> ...
> I commented out the macro call in bigSphere  (look at you, using capital
> letters... :o)  and put an actual sphere in its place.
> Same error.

yes, I too tried that.


> Put a 1 on the line above it.   Same error as last time.
>
> But when I closed the ), this time I got
>
> Parse Error: Unbalanced #end directives in include file.
> at File: fore_demo.pov Line: 213 Col: 1
> e[0] = 0  e[1] = 0  e[2] = 'one'  e[3] = 7.
> Parse Warning: Unbalanced ) in include file
>
> So the error gets triggered in the scene file, but seems to be actually due to
> an omission in some nested thing in the include file.
> Also, 213 is a different line than when I did the 0) in the mkSphere macro.

maybe I should have mentioned earlier.  before I got to the stage of calling
payload macros, I worked to get the "walking" done properly.  for that I've a
test scene with arrays from one to five dims, and the 'fore_call()' at the time
only spat out the 'cmd_' content, ie the index/indices of the current element.
while it is possible that I fucked up, I did test pretty thoroughly.

my gut feeling, given the "because it is looking for a numeric expression", is
that the parser somehow expects a RHS where it sees an object/primitive.

(and to add to the indignation :-), earlier I'd written a camera {} and left
forgot to fill in the details, and .. not a beep from the program.)


> If you can't find the issue, you may have to resort to mapping the nesting
> levels like I did in that blood cells scene.

yes, last resort though.  I do hope "one of the gods" can shed some light on
this.


regards, jr.

Post a reply to this message

To CYA, check your "end"s    :D

I noticed that you have a
#ifndef (fore_include_temp)

but I'm not sure where it should be terminated.

Also, I'm not sure if there are enough #ends in
#macro Foreach(arr_,mac_,flg_,optional dim_)






I would sorely love different terminators for #macro, #if, #for, #while, etc....

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> To CYA, check your "end"s    :D

are you looking at an unmodified file?  if yes, as posted, the indentation looks
correct.


> I noticed that you have a
> #ifndef (fore_include_temp)
>
> but I'm not sure where it should be terminated.

line 429.  :-)


> Also, I'm not sure if there are enough #ends in
> #macro Foreach(arr_,mac_,flg_,optional dim_)

no spare or missing '#end's, I'm confident.

(do you need to top up caffeine level?  :-))
(and please give it a whirr with some "normal" macros.  any errors?)


> I would sorely love different terminators for #macro, #if, #for, #while, etc....

yes, self prefers braced blocks (think Tcl), eg '#for () { ... }'.


regards, jr.

Post a reply to this message

"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

I think that with this, you are trying to get into the running on "Who breaks
POV-Ray the most?"

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


> 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
with equally ambiguous {'s

Post a reply to this message

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