[Gambas-user] EOF problem

[Ed & Clare Kelm]

Dimitris &  Les:

First Dimitris:

OK, I pasted in your code.  I had to change "temp" to "tmp", because 
Temp seems to be a Keyword.  With that out of the way, the problem 
persists.  When it fails, I get "EOF" both in label1 and the debug 
window.  When it works OK, I get a blank label1 and the text appears in 
the debug window.  The state of being at EOF seems to arise (randomly) 
as soon as the file is opened.  After that, everthing happens as one 
would expect - an EOF directs execution to the EOF stuff, and lack of 
EOF executes the text reading stuff.

I can't believe this is a common problem - by now hundreds of people 
would have noticed that their database and any other programs reading a 
text file don't work reliably.  There's got to be something peculiar 
about my installation.

Now to Les:

It still fails for me with your code.  To clarify a little, the problem 
is that the file is detected as empty when it's not, not the other way 
around.  Your code works like mine - when the file is opened it may 
randomly immediately come up as being at EOF.  The "IF not EOF..." 
statement then sends it directly to the ELSE, and the game is over. 

If you can reproduce my problem by reading the same file over and over, 
closing the program after every try, but using Gambas 2.20.2, then I've 
got to suspect Ubuntu, at least the 9.04 I have.  If you cannot, then I 
should upgrade Gambas.  I suppose a shotgun approach might be to upgrade 
to Ubuntu 9.10 AND Gambas 2.20.2.

Lastly, I don't think having a file with just a single 0A should be 
called empty.  To me EOF means just that, End of File - no more data to 
be read.  I would consider the 0A to be data, a blank line if you like.  
So, I think Gambas not raising EOF on such a file until the line is read 
is appropriate.

Both:  I'll chew on this for a few days, and then think about upgrading 
something. 

Thanks for your efforts!

Ed K.

Les Hardy wrote:
> Hi Ed,
> I figured it out.
> First of all, depending how the text file was emptied/created, the 
> contents may not be truely empty.
> Gedit for example leaves the 0A (end-of-line) character in the 'empty' 
> file. This is recognised by eof() as a character, so, end-of-file is not 
> found.
> I am not sure if this can be considered a bug in Gambas, but it does 
> mean an eof() is only good for preventing read errors, and is not 
> reliable for testing if a file is empty.
>
> The following code gets around the problem.
> It's not ideal, but it does work. Maybe someone else can improve on it.
> Regards
> Les Hardy
>
> PUBLIC SUB Button1_Click()
>
>  DIM tfile AS File
>  DIM Fname AS String
>  DIM t, txt AS String
>
>  Label1.text = ""
>  Fname = "/home/les/Documents/testdat.txt"
>  tfile = OPEN Fname FOR READ
>   
>  IF NOT Eof(tfile) THEN
>   LINE INPUT #tfile, t
>   txt = IIf(Trim(t) > "", t, "EOF")
>   Label1.text = txt
>  ELSE
>   Label1.text = "EOF"
>    
>  ENDIF
>  CLOSE #tfile
> END
>
>
>
>
>
> Ed & Clare Kelm wrote:
>   
>> Hi!
>>
>> I'm having a problem reliably reading a text file.
>>
>> I am using:
>>
>> Panasonic CF-51 Toughbook
>> Ubuntu 9.04 , Kernel 2.6.28-18
>> Gambas 2.8, QT
>>
>> Below is the code for a test program which demonstrates the problem.  
>> This is a simple form, with one button, and one label. The only code is 
>> the Button1_click event shown.  The file "testdat.txt" contained in 
>> Fname is a text file with one short line of text, created with GEDIT.
>>
>> One would expect that clicking Button1 would open the file, read the 
>> line of text, and place it into label1.  Indeed, this is exactly what 
>> happens roughly 4 times out of 5.  However, sometimes the file comes up 
>> empty, with an immediate EOF.  When the program is first started from 
>> the IDE, if it works correctly the first time, it will do so every time 
>> the button is clicked.  However, if it fails (indicates EOF) the first 
>> time, it will fail everytime the button is clicked.  Stopping the 
>> program and restarting it will roll the dice anew.  There does not seem 
>> to be any pattern to the failure.  It might happen twice in a row, it 
>> might not happen for 10 starts.
>>
>> Does anybody have any ideas?  Is this an Ubuntu issue?
>>
>> Thanks!
>>
>> Ed K.
>>
>>
>> PUBLIC SUB Button1_Click()
>>
>>    DIM tfile AS File
>>    DIM Fname AS String
>>
>>    Fname = "/home/us/Documents/testdat.txt"
>>
>>    tfile = OPEN Fname FOR READ
>>
>>    label1.Text = ""
>>
>>    IF Eof(tfile) THEN
>>       label1.Text = "EOF"
>>    ELSE
>>       LINE INPUT #tfile, label1.Text
>>    END IF
>>
>>    CLOSE #tfile 
>>
>> END
>>
>>
>>   
>>     
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>
>