So, I was just coding a few more macros, and I wanted to return a few vectors.

Pre-3.8, I'd normally handle this using a small array, but the nested macro call
that I was copy-paste-editing had the output that I needed as arguments, and I
figured I'd just use the tuple-style #declare.

I got a weird error about "expecting } found ; instead" and as all of my other
bits of code in the scene were working, with #declare LValue = value; inside of
union {}s, I was puzzled and confused.

After checking that there wasn't some { that got put somewhere by accident, I
took one of the tuple assignments
#declare (this, that) = ThisMacroReturns2Values (arg1, arg2, ar3);
and deleted the trailing semicolon - and BEHOLD!  the error vanishes.

That makes for coding awkwardness and confusion.

(I also run into the same kind of thing when I'm putting commas into a cylinder
{} and use an extra comma in between the second endpoint and the cylinder
radious - POV-Ray no likey.)

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ...
> After checking that there wasn't some { that got put somewhere by accident, I
> took one of the tuple assignments
> #declare (this, that) = ThisMacroReturns2Values (arg1, arg2, ar3);
> and deleted the trailing semicolon - and BEHOLD!  the error vanishes.
>
> That makes for coding awkwardness and confusion.

had a quick look at some code where I use tuple assignments, all are '#local'
rather than '#declare', but I think your example should work.  (see my
'pvars.inc')



regards, jr.

Post a reply to this message

On 3/26/23 15:32, Bald Eagle wrote:
> After checking that there wasn't some { that got put somewhere by accident, I
> took one of the tuple assignments
> #declare (this, that) = ThisMacroReturns2Values (arg1, arg2, ar3);
> and deleted the trailing semicolon - and BEHOLD!  the error vanishes.
> 
> That makes for coding awkwardness and confusion.
> 
> (I also run into the same kind of thing when I'm putting commas into a cylinder
> {} and use an extra comma in between the second endpoint and the cylinder
> radious - POV-Ray no likey.)

Tried a few things quickly and v3.8 behavior I think OK. Test scene below:

//---
#version 3.8;

#macro Mac00()
     (1,2)
#end

#declare (V1,V2) = Mac00();
#debug concat(str(V1,-1,-1)," ",str(V2,-1,-1),"\n")

#declare (V1,V2) = Mac00()
#debug concat(str(V1,-1,-1)," ",str(V2,-1,-1),"\n")

#declare Cyl00 = cylinder { 0 1 0.1 }
#declare Cyl01 = cylinder { 0, 1 0.1 }
#declare Cyl02 = cylinder { 0, 1, 0.1 }
#declare Cyl03 = cylinder { 0 1, 0.1 }
// #declare Cyl04 = cylinder { 0 1,, 0.1 }  // Valid complaint
// #declare Cyl05 = cylinder { 0 1, 0.1, }  // Valid complaint
// #declare Cyl06 = cylinder { 0, 1,, 0.1 } // Valid complaint

#error "stopping early"
//---

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> Tried a few things quickly and v3.8 behavior I think OK. Test scene below:

Yeah, I don't know.
It seems like these things happen only sometimes, and in hard-to replicate
manners.

For instance, I just did a macro call on a macro that returns a 2 element array.
I got the ole' can't assign an unidentified something or other to Lvalue...

The macro has 2 lines.
#local Result = array {Val1, Val2};

Result

But somehow it thinks Result hasn't been defined.

So I deleted the #local and the Result, and just left the array.
Works fine now.

I don't get it.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> ....
> I got the ole' can't assign an unidentified something or other to Lvalue...
>
> The macro has 2 lines.
> #local Result = array {Val1, Val2};
>
> Result
>
> But somehow it thinks Result hasn't been defined.
>
> So I deleted the #local and the Result, and just left the array.
> Works fine now.
>
> I don't get it.

eg:
#version 3.8;
global_settings {assumed_gamma 1}
box {0,1}

#macro has2lines ()
  #local Result = array {1234,5678};
  (Result[0], Result[1])
#end

#declare (first,second) = has2lines();
#debug concat("first ",str(first,0,0)," second ",str(second,0,0),"\n")
#warning "end-of-scene"


note (a) you need to provide two return values if you want to assign two values
from the call, and (b) nothing doing w/out parentheses.  (and coffee !! :-))


regards, jr.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> (I also run into the same kind of thing when I'm putting commas into a cylinder
> {} and use an extra comma in between the second endpoint and the cylinder
> radious - POV-Ray no likey.)

In v3.8xx in Windows, the extra comma works OK for me. I had always assumed it
was necessary anyway, as per docs (using the cylinder syntax there):

cylinder{-.5*x,.5*x,.1 texture{...}}

Leaving out the 2nd comma works as well, but that seems to be undocumented
'shorthand' behavior, IMHO.

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > (I also run into the same kind of thing when I'm putting commas into a cylinder
> > {} and use an extra comma in between the second endpoint and the cylinder
> > radious - POV-Ray no likey.)
>
> In v3.8xx in Windows, the extra comma works OK for me. I had always assumed it
> was necessary anyway, as per docs (using the cylinder syntax there):
>
> cylinder{-.5*x,.5*x,.1 texture{...}}
>
> Leaving out the 2nd comma works as well, but that seems to be undocumented
> 'shorthand' behavior, IMHO.

agree.  fwiw, here both self-compiled beta.2 and (WFP's) povr, on Linux, are
perfectly ok with all three forms:
  #declare a_ = cylinder {0 1 .1 open};
  #declare b_ = cylinder {0,1 .1 open};
  #declare c_ = cylinder {0,1,.1 open};


regards, jr.

Post a reply to this message

I am back at it, and still experiencing a lot of weird behaviour with regard to
assigning tuple-style values via macros.

And that somehow seems to be a subset of just generally weird parser behaviour
overall.

I have a scene that I've run dozens of times.
I've let it sit while I've pursued other projects and IRL stuff.
I added some fairly inconsequential code WAY at the end of the .pov file.

Now the parser is complaining about semicolons and undeclared Lvalues.

So I fiddled and restructured the macro it was complaining about, and now I'm
getting a totally inexplicable "all #declares..... require a semicolon..." error
in a macro where _everything has a semicolon_.

Okay - maybe I'm mid-parse on some other #declare or #local  and I need to fix
something upstream of the macro call.  So I add in all my macro calls that track
what level in the nesting of things I'm in, and that all seems fine ---

EXCEPT

that the parser tells me that my error occurs on line 205.

My macro calls that output the debugging stack, and current position in the
stack, both execute to completion --- but those are AFTER the cited error line,
at lines 207 and 208.

I honestly have no idea what's going on.

Either something is very weirdly wrong with my code
or
I am losing my mind
or
there is a problem in the source code for the parser
and/or
there is a problem with the parsing of tuple-style assignments

Parsing a scene should not be this - fussy.
Nor should debugging the problem be so cryptic and mysterious.


I think there needs to be a better mechanism to structure code, and follow the
flow when parse errors are triggered.
If the parser thinks that I need a semicolon to close a #local or #declare, then
it should give me the line number of the opening #local or #declare statement
that it's expecting the semicolon to finalize.

For some reason, this particular pov/inc scene pairing has been nothing but
trouble, and I'm not really sure why.  I've written vastly more complex code.

I can use all the help and advice I can get as to how to proceed.

This is very frustrating, annoying, and angering.

Trying to run previously working code shouldn't result in a failed 2-day
debugging odyssey.

Post a reply to this message

Attachments:
Download 'parseerror.jpg' (165 KB)

Preview of image 'parseerror.jpg'

On 5/3/23 15:36, Bald Eagle wrote:
> I am back at it, and still experiencing a lot of weird behaviour with 
> regard to assigning tuple-style values via macros.

Well, another longer post just went poof...

The short of what I wrote is I just ran across some buggy tuple behavior 
trying to assign results from a macro.

Post a reply to this message

On 11/1/23 09:51, William F Pokorny wrote:
> The short of what I wrote is I just ran across some buggy tuple behavior 
> trying to assign results from a macro.

Fixed in my yuqk fork. The error was in code I added to better handle 
empty parentheses in certain situations. The return state was wrong 
which confused the parser at the tuple assignment.

In official v3.8 parsers the test case generates unbalanced parentheses 
errors on some sets of balanced ones - where the inner most pair is empty.

Bill P.

Post a reply to this message