POV-Ray : Newsgroups : povray.beta-test : Problem with #read Server Time
2 Nov 2024 05:20:04 EDT (-0400)
  Problem with #read (Message 1 to 7 of 7)  
From: Simon Adameit
Subject: Problem with #read
Date: 2 Jan 2002 20:35:25
Message: <3c33b55d@news.povray.org>
Don't know if this is a bug but it seems to be a somehow strange behavior.
Try to render this and you will see what I mean.

#fopen wfile "nothing.txt" write
#fopen rfile "nothing.txt" read
#read(rfile,ahh)
#ifdef(ahh)
#local ohh=ahh;

433 Celeron Win 98 SE POV 3.5 beta 9

--
#local T=text{ttf"timrom.ttf""Simon Adameit".01,0}#local Y=1;#while(Y>-1)
#local X=0;#while(X<7)#local O=trace(T<X,Y><X,Y>+z);cylinder{<X-3,Y,5>*.01
<X-3,Y,5>*.01+5e-3,5e-5pigment{rgb 25*O}}#debug chr(83-(O.x=0)*51)#local
X=X+.05;#end#debug"\n"#local Y=Y-.05;#end


Post a reply to this message

From:
Subject: Re: Problem with #read
Date: 3 Jan 2002 06:52:32
Message: <5vg83u03fdm9i1iebk1spur4ba0stfbs0k@4ax.com>
On Thu, 3 Jan 2002 02:32:02 +0100, "Simon Adameit" <gom### [at] gmxde> wrote:
> Try to render this and you will see what I mean.

You shouldn't expect that bug appear the same on every computer. It is possible
that behaviour depends on platform, compilation version, processor. So instead
of "you will see" please solve riddle in report and allow confirmations. This
bug is probably connected with IO things and they can be different on
Mac/Win(/UNIX) platforms.

> #local ohh=ahh;

yes, strange behaviour,
  #local ohh=ahh <----ERROR
  Parse Error: Cannot assign uninitialized identifier.
was returned

>433 Celeron Win 98 SE POV 3.5 beta 9

POV 3.5 b 9 on PII 233 128 MB with NT 4 Sp 6

ABX


Post a reply to this message

From: Simon Adameit
Subject: Re: Problem with #read
Date: 3 Jan 2002 07:35:11
Message: <3c344fff@news.povray.org>
> You shouldn't expect that bug appear the same on every computer. It is
possible
> that behaviour depends on platform, compilation version, processor. So
instead
> of "you will see" please solve riddle in report and allow confirmations.
This
> bug is probably connected with IO things and they can be different on
> Mac/Win(/UNIX) platforms.
You're right, wont happen again if I have the "luck" to find a bug.

> > #local ohh=ahh;
>
> yes, strange behaviour,
>   #local ohh=ahh <----ERROR
>   Parse Error: Cannot assign uninitialized identifier.
> was returned
>
This aslo happens if you use #if(defined(ahh)) instead of #idef(ahh)


Post a reply to this message

From: Christian Walther
Subject: Re: Problem with #read
Date: 3 Jan 2002 09:37:01
Message: <B85A2B1A.2813%cwalther@gmx.ch>
> ...This bug is probably connected with IO things and they can be different on
> Mac/Win(/UNIX) platforms.
> ...
> yes, strange behaviour,
> #local ohh=ahh <----ERROR
> Parse Error: Cannot assign uninitialized identifier.
> was returned

> This aslo happens if you use #if(defined(ahh)) instead of #idef(ahh)

I can confirm that the same thing happens with the Mac version (3.5b9, MacOS
9.2.2, PPC G3 266, 192MB RAM).

It seems that "defined" and "initialized" is not the same thing, and you
just found a way to make an identifier that is defined but not initialized.
From the fact that there's a special parse error message for that, it seems
that the possible existence of uninitialized identifiers was foreseen by the
programmers, so it wouldn't be a bug.


Post a reply to this message

From:
Subject: Re: Problem with #read
Date: 3 Jan 2002 09:59:08
Message: <v0s83u42e3mqgn9eljrdba4i9iocoiepcp@4ax.com>
On Thu, 03 Jan 2002 15:36:59 +0100, Christian Walther <cwa### [at] gmxch> wrote:

> It seems that "defined" and "initialized" is not the same thing, and you
> just found a way to make an identifier that is defined but not initialized.
> From the fact that there's a special parse error message for that, it seems
> that the possible existence of uninitialized identifiers was foreseen by the
> programmers, so it wouldn't be a bug.

IMO there is some kind of bug. When you read ten variables from file but there
is nine in file then after ninth reading file handle is udefined (according to
6.2.3.3). So you can simple check EOF. But when you open empty file for reading
then handle should be undefined at begining or some warning/error could be
generated.

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)&_((x+y)*.7,z,.1)&_((x+y+2)*.7,z,.1)&_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35


Post a reply to this message

From: Anders K 
Subject: Re: Problem with #read
Date: 3 Jan 2002 12:16:42
Message: <3c3491fa@news.povray.org>
> When you read ten variables from file but there
> is nine in file then after ninth reading file handle is udefined

Note that in your code, you are testing whether the variable "aah" is
defined, rather than the file handle. However, the following code gives the
same error message:

#fopen wfile "nothing.txt" write
#fopen rfile "nothing.txt" read
#ifdef(rfile)
  #read(rfile,ahh)
  #local ohh=ahh;
#end

Anders

--
light_source{6#macro A(B)#declare C=mod(E B);#declare E=(E-C)/B;C#end
#macro B(E)#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(C<3)cylinder
{0(C=<1 2>).2translate<D+C*A(2)A(4)#else intersection{torus{1 .2}box{
-y 2}rotate<-1 0C+1>*90translate<D+1A(2)*2+1#end-2 13>finish{specular
1}pigment{red 1}}#end#end#end#local D=-8;1}B(445000298)B(519053970)B(
483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)


Post a reply to this message

From:
Subject: Re: Problem with #read
Date: 3 Jan 2002 12:30:29
Message: <j0593uo3n5jl1etbf8b1u5cv9r604roosv@4ax.com>
On Thu, 3 Jan 2002 12:16:40 -0500, "Anders K." <and### [at] prostard2gcom> wrote:
> > When you read ten variables from file but there
> > is nine in file then after ninth reading file handle is udefined
>
> Note that in your code

Note it's not mine code :-)

> you are testing whether the variable "aah" is
> defined, rather than the file handle.

Handle is tested by read, read not work with undefined handle.

ABX


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.