This is not a bug report - I've already mentioned it. This is about source
code which is why it's here under "programming."



"Identifier expected, incomplete function call or spline call found
instead."

I've been spending a lot of time with SDL lines like:
#local dummy_var = -1; //bug avoidance
trying to avoid that message.  It may take 1 character change, or it may
take half an hour or more of changing non-functional code so that it
doesn't error out when dealing with many splines.  In any case, I decided
to see what I could find out about what might be causing it.  I don't have
a compiler to test with or anything, and the following surely has mistakes,
but perhaps somebody might see any wrong turns or have some more insite
etc...

From parse.cpp, line 7822 & 7823:
      // no tokens have been found or a fucntion call had no parameters in
parenthesis
      if (!((Temp_Count==-1) || (Temp_Count==1000)) &&
had_callable_identifier)
         Error("Identifier expected, incomplete function call or spline call
found instead.");

The only way to not get the Error is for the if statement to be false.
(Temp_Count==-1) || (Temp_Count==1000)) && had_callable_identifier), if
true, describes the conditions in which we will not get an error.
Unfortunately that'll leave Temp_Count== almost_anything giving us an error
plus anytime had_callable_identifier==false it'll give us an error.


So.... I noticed both Parse_RValue() and Parse_Unknown_Vector() which is
called from the Parse_RValue() set their defaults of
had_callable_identifier or equivalent to false.  Parse_Unknown_Vector()
sets Identifier_In_Call to false and then does some other things and then
uses the value of Identifier_In_Call to set Parse_RValue()'s
had_callable_identifier via a pointer.

I.e. I'm looking for any place that can set one of these variables to true.

....And I noticed that Parse_Call() is the only place where
Identifier_In_Call can be set to true, so I looked for a pathway from
Parse_R_Value() all the way through Parse_Call().   Here's that chain:


Parse_RValue() >
  Parse_Unknown_Vector() >
    Parse_Rel_Factor() >
      Parse_Num_Term() >
        Parse_Num_Factor() >
          Parse_Spline_Call() >
            Parse_Call()  .... and here's the only place where
Identifier_In_Call can be set to true.



Parse_Call() will set Identifier_In_Call to true if Allow_Identifier_In_Call
is true and the next token is not a "(". Allow_Identifier_In_Call will
indeed be true since Parse_Unknown_Vector() sets it equal to
allow_identifier which is a paremeter passed from Parse_RValue() as true.

I'm likely wrong but I think had_callable_identifier probably isn't the
cause of the trouble....

Adding non-funtional code like #declare dummy_var = -1; nearby has always
affected whether I get the error or not, and would suggest that changing
the value of token_count (by adding tokens) can affect whether the error
occurs even when the difference is not between when the statements
Temp_Count = token_count; and Temp_Count -= token_count; are performed.

Note that Temp_Count = token_count; will always be performed for a spline
identifier since it's "callable".  Supposing the UNGET in Parse_Call() sets
the token_count back by one, then Temp_Count -= token_count; should equal 1,
not -1.  Is this it?


All thoughts/corrections or the ultimate fix would all be great!
Thanks,
Charles

Post a reply to this message

Charles C wrote:
> This is not a bug report - I've already mentioned it. This is about source
> code which is why it's here under "programming."
<snip>
> All thoughts/corrections or the ultimate fix would all be great!

The fix has been known for a long time, there just hasn't been time to
coordinate a 3.6 bugfix release. The bugfix is included in POV-Ray 3.7 betas
as well as (iirc) recent version of MegaPOV.

	Thorsten

Post a reply to this message

Charles C wrote:
> This is not a bug report - I've already mentioned it. 
> [...]

None the less - if you think there is something incorrect you should 
make a complete report (to p.g.) with the usual minimal test scene, 
description of behaviour and versions where it occurs.  If it is 
confirmed post it again to p.bugreports.  This helps to keep all 
necessary information together.

Since you seem to observe your problem in 3.7 beta as well you could 
also post it to p.beta-test.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 15 Oct. 2006)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> None the less - if you think there is something incorrect you should
> make a complete report (to p.g.) with the usual minimal test scene,
> description of behaviour and versions where it occurs.  If it is
> confirmed post it again to p.bugreports.  This helps to keep all
> necessary information together.
>
> Since you seem to observe your problem in 3.7 beta as well you could
> also post it to p.beta-test.

Thanks Thorsten & Christoph.
I have to say, it looks like I was wrong about observing it in 3.7.  I
thought I'd seen it, but I was going back and forth between 3.6 and 3.7 and
I must've had 3.6 up then.  Before I went back to that other machine & found
this out, I did put together something of a "minimal" scene which
demonstrates the behavior, & it looks  even more like it's to do with
token_count.   I'll head over to general & post that.

Thanks,
Charles

Post a reply to this message

Charles C wrote:
> I did put together something of a "minimal" scene which
> demonstrates the behavior, & it looks  even more like it's to do with
> token_count.   I'll head over to general & post that.

As I said, it is  a known 3.6 problem that is really easy to fix. The token
counting variable is (unfortunately) misused for different purposes and it
does not actually count tokens as main purpose (and as its name would
suggest). What it does instead, it flag special uses with the magic value
1000. In order to reduce progress output for parsing on newer, faster
systems, in tokenize.cpp this variable range was changed (iirc to 2500 or
5000 but I don't have an unfixed 3.6 code copy at hand right now). Just
changing the respective single line in tokenize.cpp back to the "proper"
magic value will fix this problem. No need for you to continue searching. As
I said, we know very well what exactly is wrong, the issue is just finding
the time to do an official 3.6 release on all platforms.

	Thorsten

Post a reply to this message

Thanks again Thorsten.  I was really wondering & meaning to ask what that
1000 was about.  Is the source I downloaded off the website the fixed or
unfixed version?  It's  been years since I've compiled anything but it
might be worth it for me to remind myself since I don't think I can
continue in a practical way on my current project without this fix.

Charles

Post a reply to this message