I've got a project I'm working on which uses a lot of splines.   I'm passing
splines to macros in some cases, and in other cases passing a counter
variable to a macro which in turn deals with splines.   Every once in a
while for either of these two situations I get the message "Parse Error:
Identifier expected, incomplete function call or spline call found
instead."   Well, so far the offending lines have looked good to me and in
fact do work:   Somehow I figured out that if I add a line a few lines up
like -

#declare blah = 1; // bug avoidance

- then it'll parse just fine.  I.e. the offending lines do their job.  This
"bug avoidance" line can be inside the same macro as the offending line, or
outside - it doesn't seem to matter.  If I see the problem again I'll often
just scroll up to where I most likely already have #declare blah = 1; and
change it to #declare blah = -1; or comment it out again, or add another
similar line.  It IS repeatable as long as the code doesn't change.

Longer #while loops containing likely offenders do seem to increase the
chances of getting the error.  The problem also compounds itself when there
are two separate macro calls next to each other which both have a tendancy
to "offend."   The "bug avoidance" line which fixes one macro call might
break the one next to it.  It looks like the trick here is to put a
bug-avoidance line in between the macro calls.

Anyway, I know this is all a bad way to deal with it; I want to know the
real cause.  I've found some macro calls which I had mistakenly left a
comma after the last parameter, but this hasn't been the case for the
problematic ones. However, I wouldn't be surprised if it were something
like this which Pov-Ray tolerates ....sometimes.


Does this sound familiar to anybody or should I start trying to create a
reasonably sized example?

Thanks for any tips.

Charles

Post a reply to this message

BTW, I meant to mention that I'm running POV 3.6 on WinXP.  Also I don't
remember typing "3D" in the the subject line to this thread.
Charles

Post a reply to this message

Charles C wrote:
> BTW, I meant to mention that I'm running POV 3.6 on WinXP.  Also I don't
> remember typing "3D" in the the subject line to this thread.
> Charles

I guess it's related to the already known macro-bug: if you return 
results via the parameters, every now and then the parameter will be 
returned unchanged.

So, if your macro works like this:
#macro DoSomething(Variable)
   #declare Variable=Variable+1;
#end

#declare Value=2;
DoSomething(Value)
#debug concat(str(Value,1,0),"\n")

It will probably debug "3", but if you place it in a loop, every now and 
then a "2" will pop up. That bug, too, is heavily dependant on the scene 
and the error pops up differently on different PCs. It's known and 
should be fixed in 3.7 though.

You might want to try and check which macro this bug pops up in, maybe 
you can find the actual problem and a work-around.

Regards,
Tim

-- 
aka "Tim Nikias"
Homepage: <http://www.nolights.de>

Post a reply to this message

Am Sat,  5 Aug 2006 16:23:42 EDT schrieb Charles C:

> BTW, I meant to mention that I'm running POV 3.6 on WinXP.  Also I don't
> remember typing "3D" in the the subject line to this thread.

=3D is a replace for the equal (=) in a charset encoding called "quoted
printable" but this one is not declared in the Headers of your post, so
other readers can't recode it to the =-sign

So check the options of your UA.
Hmmm... Okay, I see you are reading and posting via Webinterface, so
there is a bug in the Interface...

Bye
Norbert

Post a reply to this message

The macro parameter bug has been fixed in MegaPov 1.2.1, if you're willing
to use an unofficial version.

Tom

Post a reply to this message

Tom York wrote:
> The macro parameter bug has been fixed in MegaPov 1.2.1, if you're willing
> to use an unofficial version.

Of course, it is also fixed in 3.7 betas.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Tom York wrote:
> > The macro parameter bug has been fixed in MegaPov 1.2.1, if you're willing
> > to use an unofficial version.
>
> Of course, it is also fixed in 3.7 betas.
>
>  Thorsten

Yes. I didn't mention the beta for obvious reasons.

Tom

Post a reply to this message

> I guess it's related to the already known macro-bug: if you return results 
> via the parameters, every now and then the parameter will be returned 
> unchanged.
>
> So, if your macro works like this:
> #macro DoSomething(Variable)
>   #declare Variable=Variable+1;
> #end

A good workaround is just to pass values by substitution instead...
#macro DoSomething(Variable)
   #declare result = Variable+1;
   (result)
#end

Then call the macro from a declare.
#declare Variable = DoSomething(Variable);

Post a reply to this message

Tom York <alp### [at] zubenelgenubi34spcom> wrote:
> Yes. I didn't mention the beta for obvious reasons.

  What reasons are those?

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Tom York <alp### [at] zubenelgenubi34spcom> wrote:
> > Yes. I didn't mention the beta for obvious reasons.
>
>   What reasons are those?
>
> --
>                                                           - Warp

Because it's a beta, not a finished release? I'm under the strong impression
that the only reason for using the beta currently is to test it. Hence the
expiry, the warnings in the beta announcements about missing/possibly
missing features, and so on.

Tom

Post a reply to this message