Chris B a écrit :
> 
> "Brickman Brick" <ano### [at] anonymousorg> wrote in message 
> news:4afab1ab@news.povray.org...
>> Hello,
>>
>> I stumbled on some possible strange behaviour in the switch statement. I
>> just want to verify if I am doing something wrong or POV-Ray.
>>
> 
> Hi.
> I use and abuse the switch statement quite a lot and I've not found any 
> problems with it, so I suspect that you're doing something wrong, though 
> you haven't provided enough info to really be sure of that.
> 
> 
>> The switch statement is placed inside a loop to calculate a value of a
>> variable many times.
>>
>> Here is a short example of the code I wrote. I omitted the necessary
>> #break statements for readability.
>>
>> #switch (MySwitchValue)
>> #case (1) //do something
>> #case (2) //do something else
>> #case (3) //etc1
>> #case (0) //etc2
>> #else
>> #end
>>
>> Now this code works perfectly fine most of the time. Only sometimes it
>> breaks and it seems that a #case (1) statement is just partly executed.
>> After that, it continues just as expected.
> 
> My first suspect would be the calculated variable. Are you sure it 
> definitely results in an integer value that will match one of the #case 
> statements? If it's actually a decimal value then it may be slipping 
> through to the #else statement. Beware that it's easy to fool yourself 
> into thinking that you're getting an integer value by using #debug 
> str(MySwitchValue,1,3) which will round the value to 3 decimals, which 
> is not necessarily close enough to trip the #case statement.
> 
> Otherwise I think you'll need to find out the exact circumstances that 
> causes it to break (using strategically placed debug statements), or at 
> least provide a cut-down, but complete example that would enable someone 
> else to replicate the problem. If it only fails 1 in 1000 times then 
> provide an example with a loop that's large enough to consistently fail.
> 
> 
>> Now when I do the following the code works again as expected.
>>
>> #switch (MySwitchValue)
>> #debug "MyMessage"
>> #case (1) //do something
>> #case (2) //do something else
>> #case (3) //etc1
>> #case (0) //etc2
>> #else
>> #end
>>
>> Moving the #case (0) right in front of #case (1) also works.
>> This case gives me the impression that the order seems important. On the
>> other hand the example with the #debug statement indicates the opposite.
>> Also, the docs say I may put the clauses in any order I want.
>>
> 
> This sounds quite odd. When you have explored all other possible causes. 
> it may be worth considering that the file or that your installation may 
> be corrupt in some way. I have occasionally had wierd things happen 
> where simply deleting and manually rekeying lines have cured the 
> problem. I've rationalised this by believing that I may have 
> accidentally typed an invisible hex character into the file that's 
> corrupted it, or that it's somehow been corrupted by a disk read or 
> write error. If you think the application may have gotten corrupted, 
> then you may want to consider reinstalling it. I'd wait for a bit before 
> exploring these more radical ideas though as someone else might come up 
> with other ideas.
> 
> Regards,
> Chris B.
> 

You are much more likely to have a silent data corruption during a disk 
write or read than to accidently imput a non-printable character.

A thing that often work if you do have non-printable character(s) 
causing you problems in a scene file, is to sellect all (Ctrl+A), hit 
Ctrl+C or Ctrl+X, then Ctrl+V, then save the file.
Normaly, the non-printable characters are NOT copied to the clipboard.


Alain

Post a reply to this message

Hello,


Op Wed, 11 Nov 2009 14:11:01 +0000, schreef Chris B:

> I use and abuse the switch statement quite a lot and I've not found any
> problems with it, so I suspect that you're doing something wrong, though
> you haven't provided enough info to really be sure of that.
>

Thank you for your help. I will try to provide more info. The code reads a
text file with integers. These integers are passed to the #switch
statement. In each #switch clause a macro is called to place an object 
and modify two other variables. One of these variables got corrupted. So 
I may be completely wrong with blaming the #switch statement for the 
error in the first place.

> My first suspect would be the calculated variable. Are you sure it
> definitely results in an integer value that will match one of the #case
> statements?

When the data is read from a file it is read as floats. So a converion to
integers wouldn't be a bad idea?

> Otherwise I think you'll need to find out the exact circumstances that
> causes it to break (using strategically placed debug statements), or at
> least provide a cut-down, but complete example that would enable someone
> else to replicate the problem. If it only fails 1 in 1000 times then
> provide an example with a loop that's large enough to consistently fail.

When I try to find the exact place where the code breaks, e.g. with a
#debug statement. The code suddenly doesn't break anymore. When I remove 
the #debug the code is broken again.
This is the frustrating part, when I try to provide a cut-down working
example the code suddenly works again. So it is very hard to find the bug.

> This sounds quite odd. When you have explored all other possible causes.
> it may be worth considering that the file or that your installation may
> be corrupt in some way. I have occasionally had wierd things happen
> where simply deleting and manually rekeying lines have cured the
> problem. I've rationalised this by believing that I may have
> accidentally typed an invisible hex character into the file that's
> corrupted it, or that it's somehow been corrupted by a disk read or
> write error. If you think the application may have gotten corrupted,
> then you may want to consider reinstalling it. I'd wait for a bit before
> exploring these more radical ideas though as someone else might come up
> with other ideas.

I already eliminated the possibility that my povray installation is
corrupt. I copied the data to a virual machine (running another os) and
encountered the same error. 
Could it be some hardware failure? Today, e.g. I am unable to reproduce 
the error (even in the virtual machine). But I think it will show up 
again in the future.

Brickman Brick


-- 
brickcentral.livejournal.com

Post a reply to this message

"Brickman Brick" <ano### [at] anonymousorg> wrote in message 
news:4afbff1c@news.povray.org...
> The code reads a
> text file with integers. These integers are passed to the #switch
> statement.
> ...
> When the data is read from a file it is read as floats. So a converion to
> integers wouldn't be a bad idea?
>

Well strictly speaking there's no separate integer data type in POV-Ray, so 
everything is a float and it just comes down to the value, but if any 
calculations have been done on the value then there's a risk that it could 
potentially result in precision errors. If in doubt you could use the 'int' 
function to make sure.


> When I try to find the exact place where the code breaks, e.g. with a
> #debug statement. The code suddenly doesn't break anymore. When I remove
> the #debug the code is broken again.

Yes I can see how that would be frustrating :-)

I'm just thinking out loud here, so no clear thoughts, but if the 
#switch/#case statements are being used in conjunction with nested macro 
calls, then I wonder whether a wayward macro could sometimes return 
something that's interfering with the #case statements. I can't imagine how 
that could happen though without it producing a parse error of some sort, 
unless the macro contained a #break or a #case statement, which would 
probably be pretty self evident on looking at it.


> This is the frustrating part, when I try to provide a cut-down working
> example the code suddenly works again. So it is very hard to find the bug.

Well, if you do manage to get a version that consistently reproduces the 
problem (even if it's not cut-down), you could maybe post it somewhere like 
povray.text.scene-files or zipped on povray.binaries.scene-files and I'd be 
happy to try and take a look. I can't promise to spot the problem with 
something so intermittent, but sometimes just a fresh pair of eyes can help 
:-)

Regards,
Chris B.

Post a reply to this message

Brickman Brick schrieb:

> Could it be some hardware failure? Today, e.g. I am unable to reproduce 
> the error (even in the virtual machine). But I think it will show up 
> again in the future.

Pretty much unlikely.

I'd rather suspect some very obscure situation that's not handled 
properly in POV-Ray. The parser /does/ have at least one of those (for 
instance, there's a very rare situation in which forgetting a single 
closing parenthesis will actually /crash/ POV-Ray on a Windows machine).

The apparent randomness of the symptoms would strongly indicate a 
"dangling pointer" or some such being involved.

Post a reply to this message

Chris B schrieb:

> Well, if you do manage to get a version that consistently reproduces the 
> problem (even if it's not cut-down), you could maybe post it somewhere 
> like povray.text.scene-files or zipped on povray.binaries.scene-files 
> and I'd be happy to try and take a look. I can't promise to spot the 
> problem with something so intermittent, but sometimes just a fresh pair 
> of eyes can help :-)

... or someone with a debugger, for that matter. I'd be curious to have 
a go at it, too.

Post a reply to this message

Hello,

I made a cut-down version and posted it in povray.binaries.scene-files.
Unfortunately I can't reproduce the bug at the moment. But I you want to
have a look at it, it is there.

Brickman Brick

Op Thu, 12 Nov 2009 13:57:17 +0000, schreef Chris B:


> Well, if you do manage to get a version that consistently reproduces the
> problem (even if it's not cut-down), you could maybe post it somewhere
> like povray.text.scene-files or zipped on povray.binaries.scene-files
> and I'd be happy to try and take a look. I can't promise to spot the
> problem with something so intermittent, but sometimes just a fresh pair
> of eyes can help :-)
> 
> Regards,
> Chris B.





-- 
brickcentral.livejournal.com

Post a reply to this message

Brickman Brick schrieb:
> Hello,
> 
> I made a cut-down version and posted it in povray.binaries.scene-files.
> Unfortunately I can't reproduce the bug at the moment. But I you want to
> have a look at it, it is there.

Oops - something I should have asked earlier: What version of POV-Ray 
are you using?

Post a reply to this message

I am using version 3.6.1 (g++ 3.4.1 @ i686-pc-linux-gnu)


Op Fri, 13 Nov 2009 21:46:31 +0100, schreef clipka:

> Brickman Brick schrieb:
>> Hello,
>> 
>> I made a cut-down version and posted it in povray.binaries.scene-files.
>> Unfortunately I can't reproduce the bug at the moment. But I you want
>> to have a look at it, it is there.
> 
> Oops - something I should have asked earlier: What version of POV-Ray
> are you using?



-- 
brickcentral.livejournal.com

Post a reply to this message

Brickman Brick schrieb:
> Hello,
> 
> I made a cut-down version and posted it in povray.binaries.scene-files.
> Unfortunately I can't reproduce the bug at the moment. But I you want to
> have a look at it, it is there.

I notice that in the code you sum up the total track length; did you 
compare it between "good" and "wrong" case? This might give a hint 
whether the #case statement is really cut short, or whether the 
computatons give wrong results.

Post a reply to this message

Hi,

thanks for the help. Maybe this will lead me to the exact spot of the 
error. I know now that the #case statement has not been cut short, but 
the wrong computation must be somewhere in the code that has been called 
by the #case statement.
I am also going to try if the texture macro causes the error. As soon as 
I am able to reproduce the bug again.

Op Fri, 13 Nov 2009 22:59:40 +0100, schreef clipka:

> I notice that in the code you sum up the total track length; did you
> compare it between "good" and "wrong" case? This might give a hint
> whether the #case statement is really cut short, or whether the
> computatons give wrong results.


-- 
brickcentral.livejournal.com

Post a reply to this message