> I suppose it is just you (and the fact that this has not been a problem
> for others despite POV-Ray 3.6 being available for long supports this).

Hm. Strange though, because sometimes it works, and sometimes it doesn't.
Still strange though is that when it doesn't, the problem is reproducable to
a certain extent. I'll see how much I can narrow it down to check if others
just haven't run into this sort of problem.

Ah well, I always seem to have some special cases evolving around me. :-)

Regards,
Tim

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

Post a reply to this message

Someone else posted a similar experience (Mael)
in message news:413ad105$1@news.povray.org...
with the following:

File test.inc :

#macro sph()
  sphere { 0, 1 }
#end

File test.pov :

#include "test.inc"
sph()
#if (true
#end

============================
It's missing a closing paren after "true" and
it throws an exception when run. Does it on
3.6 under Win98 and 3.6.1 under Win2K.
=Bob=

Post a reply to this message

Yup, I get an exception there as well. Strange thing is, without the
included file and use of macro, it works fine and tells me, that the closing
bracket is missing. So it seems like using an un-initialized variable
triggers that problem as well. Hm. Anyone with insight in regards to the
POV-source have any idea where this comes from?

And thanks =Bob=, for pointing that out.

Regards,
Tim

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

Post a reply to this message

"Tim Nikias" <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> wrote in message
news:41499b3b$1@news.povray.org...
: Yup, I get an exception there as well. Strange thing is, without the
: included file and use of macro, it works fine and tells me, that the closing
: bracket is missing. So it seems like using an un-initialized variable
: triggers that problem as well. Hm. Anyone with insight in regards to the
: POV-source have any idea where this comes from?

I tried removing the call to the sph() macro, and Pov recovers
and displays the proper error.

If I change 'true' to something undeclared, like 'ntrue' and
add the appropriate closing paren, Pov recovers as long as
there is no call to the macro. If I put the call back in, Pov
throws an exception.

If I move the call to the macro sph() to below the #if (ntrue)
and #end, Pov recovers and displays the proper error.

If I change the #if to #while, Pov throws. If I write:

#include "test.inc"

sph()

#ifdef
#end

Pov throws an exception.
So it always seems to throw when the order is:

#include
call macro
# style script error

If I remove the # style error and place an object like
a box there using an undeclared variable, Pov recovers
and displays the proper error.

=Bob=

Post a reply to this message

Hm. With all this detailed information, shouldn't it be possible to submit a
bug report? Perhaps we'd need to rally a few more Windows Users to check the
bug, cause if it's just us two, then there isn't much point in having the
POV-Team work on such a small-scale issue. After all, now we know the source
of the problem and know what to look for when we get that exception. If
there are more people that can confirm this, it would be worth a report
though.


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

Post a reply to this message

"Tim Nikias" <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> wrote in message
news:414a0d27@news.povray.org...
: Hm. With all this detailed information, shouldn't it be possible to submit a
: bug report? Perhaps we'd need to rally a few more Windows Users to check the
: bug, cause if it's just us two, then there isn't much point in having the
: POV-Team work on such a small-scale issue. After all, now we know the source
: of the problem and know what to look for when we get that exception. If
: there are more people that can confirm this, it would be worth a report
: though.

Four people have confirmed the error so far.

I think it's a bug now. I downloaded the source and
made a debug version. I can make a work-a-round
to eliminate the problem for a missing parameter in
an "ifdef" or an "ifndef" and it works fine. It seems to
be in the source file, tokenize.cpp in the function
Get_Token. That doesn't mean that really is the problem,
just that it's where I traced it to and I don't have time to
look any deeper.

No flames from the Pov Programmers please...
Just trying to help...
=Bob=

Post a reply to this message

On Thu, 16 Sep 2004 16:13:06 -0700, =Bob=  
<robertUNDERSCOREdobbinsATmailDOTtdsDOTnet> wrote:
> Four people have confirmed the error so far.


You can add me to that list.



> I think it's a bug now. I downloaded the source and
> made a debug version. I can make a work-a-round
> to eliminate the problem for a missing parameter in
> an "ifdef" or an "ifndef" and it works fine. It seems to
> be in the source file, tokenize.cpp in the function
> Get_Token. That doesn't mean that really is the problem,
> just that it's where I traced it to and I don't have time to
> look any deeper.


For me, the exception occurs in the function Terminate_Tokenizer.

I was able to "fix" it, but I'm not very familiar with the code that  
handles macro calls, so I can't at this point be sure that I didn't break  
something else.
For what it's worth, here's what I did:

In the file tokenize.cpp:
  In the function Return_From_Macro:
    After the line:
     Input_File->In_File = Cond_Stack[CS_Index].Macro_File ;
    Add the line:
     Cond_Stack[CS_Index].Macro_Same_Flag = true;


Perhaps someone who knows more about the code than I do could tell us if  
that is a good fix or not.



-- 
FE

Post a reply to this message

"Fredrik Eriksson" <noo### [at] nowherecom> wrote in message
news:ops### [at] frogeaterbredbandsbolagetse...
: On Thu, 16 Sep 2004 16:13:06 -0700, =Bob=
: <robertUNDERSCOREdobbinsATmailDOTtdsDOTnet> wrote:
: > Four people have confirmed the error so far.
:
: You can add me to that list.

Five!

: For me, the exception occurs in the function Terminate_Tokenizer.
:
: I was able to "fix" it, but I'm not very familiar with the code that
: handles macro calls, so I can't at this point be sure that I didn't break
: something else.
: For what it's worth, here's what I did:

I tried your fix, but it doesn't deal with the missing parameter
in an ifdef or ifndef for me. I'll look further tomorrow. Thanks
for posting this.

Note to Pov Programmers: We really appreciate all your
efforts. We appreciate you so much that we will try to
help all we can. Thanks for such a great piece of software!
=Bob=

Post a reply to this message

On Thu, 16 Sep 2004 16:59:02 -0700, =Bob=  
<robertUNDERSCOREdobbinsATmailDOTtdsDOTnet> wrote:
> I tried your fix, but it doesn't deal with the missing parameter
> in an ifdef or ifndef for me.


The good news is: I think I may have found the problem.

The bad news is: The fix is not as "clean" as my previous attempt (which I  
now think was wrong, by the way).


It boils down to this:

In the function Parse_Directive, there are a number of clauses (e.g.  
IF_TOKEN, WHILE_TOKEN etc.) that begin with calling Inc_CS_Index() (which  
basically does ++CS_Index). After incrementing CS_Index, it is important  
to assign the correct value to Cond_Stack[CS_Index].Cond_Type before  
calling any parsing functions. Unfortunately, some of those clauses do  
call parsing functions in between incrementing CS_Index and setting  
Cond_Stack[CS_Index].Cond_Type.

The solution is simple, but somewhat tedious: Go through each of those  
clauses and make sure CS_Index is always incremented just before assigning  
to Cond_Stack[CS_Index].Cond_Type. This involves moving about and  
duplicating calls to Inc_CS_Index().


What happens in the test code (the one in Bob's previous posts) is this:

When the macro is invoked, CS_Index is incremented, and Cond_Type set to  
INVOKING_MACRO_COND. When the #end is reached (the one inside the macro),  
CS_Index is decremented. So far so good.
After parsing the #ifdef, CS_Index is incremented, but before Cond_Type is  
set, Parse_Ifdef_Param() is called. Parse_Ifdef_Param finds the #end (the  
one in the scene file), and checks the current (corrupt) Cond_Type. It  
sees that Cond_Type is INVOKING_MACRO_COND (because that happens to be on  
the Cond_Stack due to the macro being called previously), thinks that it  
has reached the end of a macro invokation, and consequently calls  
Return_From_Macro. This results, among other things, in the outermost  
symbol table (in this case, "global identifiers") being destroyed and  
CS_Index being decremented. At this point, the program state is hopelessly  
corrupted, and bad things happen.



-- 
FE

Post a reply to this message

"Fredrik Eriksson" <noo### [at] nowherecom> wrote in message
news:ops### [at] frogeaterbredbandsbolagetse...
[deletions]
: The solution is simple, but somewhat tedious: Go through each of those
: clauses and make sure CS_Index is always incremented just before assigning
: to Cond_Stack[CS_Index].Cond_Type. This involves moving about and
: duplicating calls to Inc_CS_Index(). [more deletions]

Ok Fredrik! Looks like enough info here to for the developers
to work with now, that is, if they have the time. Good sleuthing!
=Bob=

Post a reply to this message