 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
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.
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.
Does anyone know more about this?
Thanks in advance,
Brickman Brick
--
brickcentral.livejournal.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Brickman Brick" <ano### [at] anonymous org> 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Brickman Brick schrieb:
> 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.
Never seen or heard of anything like that. Are you using some
unconventional constructs in your SDL file?
If anything, I'd expect the variant /with/ the #debug statement to cause
problems.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
