 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I know that trying to call a variable before you declare it is not generally
considered very bright, but I'm attempting to understand what's going on in the
code below:
----------------------------------------
(test.pov)
#declare RdmA = seed(574647);
#include "rand2.inc"
#declare X = RRand(-5,5,RdmA);
#if (Y = 0) #end
----------------------------------------
----------------------------------------
(rand2.inc)
#macro RRand(Min, Max, RS) (rand(RS)*(Max-Min) + Min) #end
----------------------------------------
"rand2.inc" consists of a macro copied from the original "rand.inc" file. If I
run "test.pov" above, POV-Ray throws an unhandled exception and I'm forced to
close the program.
If, however, I change "test.pov" to be:
----------------------------------------
(test2.pov)
#declare RdmA = seed(574647);
#macro RRand(Min, Max, RS) (rand(RS)*(Max-Min) + Min) #end
#declare X = RRand(-5,5,RdmA);
#if (Y = 0) #end
----------------------------------------
......that is, I replace the '#include' call with the macro from "rand2.inc",
then POV produces a simple parse error, as expected.
So, what's the difference between using this macro in an include file and
placing it directly in my .pov code?
OS: WinXP
POV: 3.6.1c
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>I know that trying to call a variable before you declare it is not
>generally
> considered very bright, but I'm attempting to understand what's going on
> in the
> code below:
>
> ----------------------------------------
> (test.pov)
> #declare RdmA = seed(574647);
> #include "rand2.inc"
> #declare X = RRand(-5,5,RdmA);
> #if (Y = 0) #end
> ----------------------------------------
>
> ----------------------------------------
> (rand2.inc)
> #macro RRand(Min, Max, RS) (rand(RS)*(Max-Min) + Min) #end
> ----------------------------------------
>
> "rand2.inc" consists of a macro copied from the original "rand.inc" file.
> If I
> run "test.pov" above, POV-Ray throws an unhandled exception and I'm forced
> to
> close the program.
>
> If, however, I change "test.pov" to be:
>
> ----------------------------------------
> (test2.pov)
> #declare RdmA = seed(574647);
> #macro RRand(Min, Max, RS) (rand(RS)*(Max-Min) + Min) #end
> #declare X = RRand(-5,5,RdmA);
> #if (Y = 0) #end
> ----------------------------------------
>
> ......that is, I replace the '#include' call with the macro from
> "rand2.inc",
> then POV produces a simple parse error, as expected.
>
> So, what's the difference between using this macro in an include file and
> placing it directly in my .pov code?
>
> OS: WinXP
> POV: 3.6.1c
>
As far as the SDL is concerned this "should" be the same result,
but the first one involves file access, so it's probably a bug in POV,
or possibly in the OS. There may be a "slew time" involved with
including a file, moving the location of the include to the beginning
of the calling file may help (other commands would be processed
before using the macro, giving the files a little time to close). The
same sort of crash can happen if you include the same files from
an included file as in the calling file. For example if you have some
file "scene.pov" and it includes "rand.inc" and "mymacro.inc",
then if you include "rand.inc" inside "mymacro.inc" it could
cause a problem.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <47cf0413$1@news.povray.org>, tim### [at] comcast net says...
> >I know that trying to call a variable before you declare it is not
> >generally
> > considered very bright, but I'm attempting to understand what's going o
n
> > in the
> > code below:
> >
> > ----------------------------------------
> > (test.pov)
> > #declare RdmA = seed(574647);
> > #include "rand2.inc"
> > #declare X = RRand(-5,5,RdmA);
> > #if (Y = 0) #end
> > ----------------------------------------
> >
> > ----------------------------------------
> > (rand2.inc)
> > #macro RRand(Min, Max, RS) (rand(RS)*(Max-Min) + Min) #end
> > ----------------------------------------
> >
> > "rand2.inc" consists of a macro copied from the original "rand.inc" fil
e.
> > If I
> > run "test.pov" above, POV-Ray throws an unhandled exception and I'm for
ced
> > to
> > close the program.
> >
> > If, however, I change "test.pov" to be:
> >
> > ----------------------------------------
> > (test2.pov)
> > #declare RdmA = seed(574647);
> > #macro RRand(Min, Max, RS) (rand(RS)*(Max-Min) + Min) #end
> > #declare X = RRand(-5,5,RdmA);
> > #if (Y = 0) #end
> > ----------------------------------------
> >
> > ......that is, I replace the '#include' call with the macro from
> > "rand2.inc",
> > then POV produces a simple parse error, as expected.
> >
> > So, what's the difference between using this macro in an include file a
nd
> > placing it directly in my .pov code?
> >
> > OS: WinXP
> > POV: 3.6.1c
> >
> As far as the SDL is concerned this "should" be the same result,
> but the first one involves file access, so it's probably a bug in POV,
> or possibly in the OS. There may be a "slew time" involved with
> including a file, moving the location of the include to the beginning
> of the calling file may help (other commands would be processed
> before using the macro, giving the files a little time to close). The
> same sort of crash can happen if you include the same files from
> an included file as in the calling file. For example if you have some
> file "scene.pov" and it includes "rand.inc" and "mymacro.inc",
> then if you include "rand.inc" inside "mymacro.inc" it could
> cause a problem.
>
Hmm. Sounds like the parser needs to flag cases like this and, at
minimum, ignore requests to include files of the same name and location.
You "may" have cases where you have the same name, but different
contents, in a different directory though, so you do need to account for
and allow that, but that means more complex checking, like seeing if the
files are identical via a "diff" type parse. Just storing the name and
directory, then refusing to load it, wouldn't cause as much of a problem
though. Though, why it doesn't just replace one set of definitions with
the new ones (or fail with an error), and not crash....
--
void main () {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>Hmm. Sounds like the parser needs to flag cases like this and, at
>minimum, ignore requests to include files of the same name and location.
>You "may" have cases where you have the same name, but different
>contents, in a different directory though, so you do need to account for
>and allow that, but that means more complex checking, like seeing if the
>files are identical via a "diff" type parse. Just storing the name and
>directory, then refusing to load it, wouldn't cause as much of a problem
>though. Though, why it doesn't just replace one set of definitions with
>the new ones (or fail with an error), and not crash....
There's nothing conceptually wrong with being able to include
files from sub-include files, it's just what causes the crashes.
(Though it's possible to create infinite loops that way, which
probably would cause a nesting error.)
It would be good to just add a handler for those file errors,
either with a parse fail, or a retry after closing and re-opening
the file, (and seeking to the last spot read in).
A typical work-around is to use #ifndef in include files...
#ifndef (_TRANSFORMS_INC)
#include "transforms.inc"
#end
It's also possible to get invisible garbage at the end of a
file, adding a few blank lines and hitting delete a bit can
fix that sometimes.
Or you could just increase max_trace_level and do a
little voodoo dance =P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott <sel### [at] rraznet> wrote:
> Hmm. Sounds like the parser needs to flag cases like this and, at
> minimum, ignore requests to include files of the same name and location.
I think we're talking about two separate symptoms, aren't
we? I cannot, however, reproduce Tim's scenario -- POV seems to handle
identically-included files gracefully and eventually throws a 'Too many nested
include files' parse error.
But #including a macro, using that macro, and then attempting to call an
undefined variable consistently crashes POV on both XP and Vista for me.
Simplest case:
//test.inc
#macro A(B) B+1 #end
//test.pov
#include "test.inc"
#declare X=A(3);
#if (Y=0) #end
I somehow had the naive impression that '#include' just copied the contents of
the .inc file and placed them at the #include marker in the .pov file.
Apparently, reality is more complicated than that...?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Though, why it doesn't just replace one set of definitions with
> the new ones (or fail with an error), and not crash....
Any crash is a bug.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Patrick Elliott <sel### [at] rraznet> wrote:
>
>> Hmm. Sounds like the parser needs to flag cases like this and, at
>> minimum, ignore requests to include files of the same name and location.
>
> I think we're talking about two separate symptoms, aren't
> we? I cannot, however, reproduce Tim's scenario -- POV seems to handle
> identically-included files gracefully and eventually throws a 'Too many nested
> include files' parse error.
>
> But #including a macro, using that macro, and then attempting to call an
> undefined variable consistently crashes POV on both XP and Vista for me.
> Simplest case:
>
> //test.inc
> #macro A(B) B+1 #end
>
> //test.pov
> #include "test.inc"
> #declare X=A(3);
> #if (Y=0) #end
>
> I somehow had the naive impression that '#include' just copied the contents of
> the .inc file and placed them at the #include marker in the .pov file.
> Apparently, reality is more complicated than that...?
>
>
>
>
Hello.
I experienced the same crash, i think. (in the same pov version). Before
closing, i can see in the message window that the parser has catched the
typo in the variable name, but despite this, the renderer is launched.
In my case, the unhandled exception comes from the renderer
--------
Martin.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Any crash is a bug.
Yes, POV shouldn't crash, even if it can't render.
I believe this bug is already fixed in 3.7 beta,
at least I can't duplicate it in beta.
And of course Y is an undefined identifier, it's
just a mishandled exception in 3.6, so just make
sure you create that sort of variable before using
it in an #if and everything will be fine.
(shouldn't this thread have been in p.bugreports?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Attwood" <tim### [at] comcastnet> wrote:
> I believe this bug is already fixed in 3.7 beta,
> at least I can't duplicate it in beta.
Good to know. Can anyone else verify this?
> And of course Y is an undefined identifier, it's
> just a mishandled exception in 3.6, so just make
> sure you create that sort of variable before using
> it in an #if and everything will be fine.
Yes, there's clearly an easy away around the issue. But the fact that it
crashes instead of throws a parse error is worth noting, IMHO.
> (shouldn't this thread have been in p.bugreports?)
My understanding has always been it's better to discuss and verify an issue
before burdening the POV Team with a true bugreport. Case in point, if they've
fixed the issue in 3.7 beta then there's probably no real point in posting an
official bugreport about 3.6...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
