|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Can somebody explain to me why the following code is halting at the second
read. If I combine the first 2 reads then it fails on the last (third) read.
Error message ...."file identifier expected but undeclared identifier
NB_File found instead"
Typical data line:
5,-5,<331530,4711404,0>, <331493,4711406,0>, <331513,4711428,0>,
<331536,4711408,0>, <331530,4711404,0>,
#fopen NB_File "Build.dat" read // #while (defined(NB_File))
#read (NB_File,Num)
#read (NB_File,Elev)
prism
linear_sweep
linear_spline
(Elev+5),(Elev+30)
Num
#local i=0;
#while (i<Num)
#read (NB_File, Vec)
Vec
#local i=i+1;
#end
pigment {color Red} }
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Vincent-Jones <geo### [at] galaxynetcom> wrote:
> Can somebody explain to me why the following code is halting at the second
> read. If I combine the first 2 reads then it fails on the last (third)
read.
> Error message ...."file identifier expected but undeclared identifier
> NB_File found instead"
[snip]
Did you post the exact code? After adding the opening bracket after the
prism, and removing the unused #end directive, the code rendered fine under
POV 3.1g and MegaPOV. The error message indicates you are running out of
data (i.e. there are less points than the first number in the file
indicates). POV-Ray undefines the file handle when it reaches the end of
the file.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"David Vincent-Jones" <geo### [at] galaxynetcom> wrote:
> Can somebody explain to me why the following code is halting at the second
> read.
As far as I can see, what happens is your second loop reads the last entry
in Build.dat - but it does not close the file, because POV closes the file
when it reads EOF. So the condition of the first while loop is still
satisfied; the loop starts, the first #read reads EOF and closes the file.
After this NB_File is undefined and the second #read gives an error.
Here's a hack that works around the problem; it checks whether NB_File
is still defined after the first #read; if not, it simply runs an empty loop.
#fopen NB_File "Build.dat" read
#while (defined(NB_File))
#read (NB_File,Num)
#if(defined(NB_File))
#read (NB_File,Elev)
prism{
linear_sweep linear_spline
(Elev+5),(Elev+30)
Num
#local i=0;
#while (i<Num)
#read (NB_File, Vec)
Vec
#local i=i+1;
#end
pigment {rgb x}
}
#end
#end
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks guys. Your 'clue' solved the problem.......
An errant comma was not deleted at EOF so.....
Sometimes the error messages lead one to look in the wrong place !!
David
"Margus Ramst" <mar### [at] peakeduee> wrote in message
news:3aa4d98f$1@news.povray.org...
> "David Vincent-Jones" <geo### [at] galaxynetcom> wrote:
>
> > Can somebody explain to me why the following code is halting at the
second
> > read.
>
> As far as I can see, what happens is your second loop reads the last entry
> in Build.dat - but it does not close the file, because POV closes the file
> when it reads EOF. So the condition of the first while loop is still
> satisfied; the loop starts, the first #read reads EOF and closes the file.
> After this NB_File is undefined and the second #read gives an error.
>
> Here's a hack that works around the problem; it checks whether NB_File
> is still defined after the first #read; if not, it simply runs an empty
loop.
>
> #fopen NB_File "Build.dat" read
> #while (defined(NB_File))
> #read (NB_File,Num)
> #if(defined(NB_File))
> #read (NB_File,Elev)
> prism{
> linear_sweep linear_spline
> (Elev+5),(Elev+30)
> Num
> #local i=0;
> #while (i<Num)
> #read (NB_File, Vec)
> Vec
> #local i=i+1;
> #end
> pigment {rgb x}
> }
> #end
> #end
>
> --
> Margus Ramst
>
> Personal e-mail: mar### [at] peakeduee
> TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
> Home page http://www.hot.ee/margusrt
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"David Vincent-Jones" <geo### [at] galaxynetcom> wrote in message
news:3aa52342@news.povray.org...
> Thanks guys. Your 'clue' solved the problem.......
> An errant comma was not deleted at EOF so.....
> Sometimes the error messages lead one to look in the wrong place !!
>
Occasionally inevitable - in any language. For example:
"the cat slept on the mat was a mouse", if parsed, might report an error at
the boundary of "mat" and "was". However, the error is a lack of fullstop
after "slept".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|