1. standard read_file()
Jeremy, the read_file() function in EusLibs and the new one in file.e are
giving different results. I don't know which one is valid, though. The code
for the EusLibs version is below.
The only significant difference I see is that EusLibs reads it in binary
mode, while the standard one does not.
-- read_file(object f)
-- returns the contents of file /f
-- /f can be a filename or a file number as returned by open()
-- -1 is returned if failed
global function euslibs_read_file(object f)
object fn, ret, kar, len
if sequence(f) then
len = file_length(f)
if len = 0 then
return ""
elsif len < 0 then
return -1
end if
ret = repeat(0, len)
fn = open(f, "rb")
if fn < 0 then return -1 end if
for i = 1 to len do
ret[i] = getc(fn)
end for
close(fn)
else
ret = ""
while 1 do
kar = getc(f)
if kar != -1 then
ret &= kar
else
exit
end if
end while
end if
return ret
end function
2. Re: standard read_file()
c.k.lester wrote:
>
> Jeremy, the read_file() function in EusLibs and the new one in file.e are
> giving different results. I don't know which one is valid, though. The code
> for the EusLibs version is below.
>
> The only significant difference I see is that EusLibs reads it in binary
> mode, while the standard one does not.
>
> }}}
<eucode>-- read_file(object f)
> -- returns the contents of file /f
> -- /f can be a filename or a file number as returned by open()
> -- -1 is returned if failed
> global function euslibs_read_file(object f)
> object fn, ret, kar, len
> if sequence(f) then
> len = file_length(f)
> if len = 0 then
> return ""
> elsif len < 0 then
> return -1
> end if
>
> ret = repeat(0, len)
> fn = open(f, "rb")
> if fn < 0 then return -1 end if
>
> for i = 1 to len do
> ret[i] = getc(fn)
> end for
> close(fn)
> else
> ret = ""
> while 1 do
> kar = getc(f)
> if kar != -1 then
> ret &= kar
> else
> exit
> end if
> end while
> end if
> return ret
> end function</eucode>
{{{
I thought file.e already had a "read_file()", it's this:
global function getf(sequence filename)
object junk, file, filecontents, readbyte
file = open(filename,"rb")
if not equal(file,-1) then
junk = dir(filename) -- get some info about it
junk = junk[1][3] -- the filesize
filecontents = repeat(0,junk)
-- i wish i could set a pointer to bulk memory here,
-- use allocate(),
-- and later return just this pointer,
-- which could then be deallocated,
-- saving memory and time
junk = 0
readbyte = getc(file)
while not equal(readbyte,-1) do
junk += 1
filecontents[junk] = readbyte
readbyte = getc(file)
end while
close(file)
return filecontents
end if
return -1
end function
Kat
3. Re: standard read_file()
Kat,
I do not see getf in the docs, nor in file.e in SVN or 3.1 ... where do you see
it?
--
Jeremy Cowgar
http://jeremy.cowgar.com
4. Re: standard read_file()
c.k.lester wrote:
>
> Jeremy, the read_file() function in EusLibs and the new one in file.e are
> giving different results. I don't know which one is valid, though. The code
> for the EusLibs version is below.
>
> The only significant difference I see is that EusLibs reads it in binary
> mode, while the standard one does not.
>
I updated read_file() to use "rb" ... can you run your tests again?
--
Jeremy Cowgar
http://jeremy.cowgar.com
5. Re: standard read_file()
Jeremy Cowgar wrote:
> c.k.lester wrote:
> > Jeremy, the read_file() function in EusLibs and the new one in file.e are
> > giving different results. I don't know which one is valid, though. The code
> > for the EusLibs version is below.
> >
> > The only significant difference I see is that EusLibs reads it in binary
> > mode, while the standard one does not.
>
> I updated read_file() to use "rb" ... can you run your tests again?
Okay, they're equal now. Except your read_file() is twice as fast! Nice! :)
6. Re: standard read_file()
c.k.lester wrote:
>
> Okay, they're equal now.
Great!
> Except your read_file() is twice as fast! Nice! :)
Well, when your good, your good.... er, um, I mean lucky 
--
Jeremy Cowgar
http://jeremy.cowgar.com
7. Re: standard read_file()
Jeremy Cowgar wrote:
>
> Kat,
>
> I do not see getf in the docs, nor in file.e in SVN or 3.1 ... where do you
> see it?
I thought it was in the code i posted here a minute ago. Didn't you see it?
Kat
8. Re: standard read_file()
Kat wrote:
>
> I thought it was in the code i posted here a minute ago. Didn't you see it?
>
Yes, but you said it was in file.e already. I was looking in existing file.e's
for it, as being distributed with Euphoria already.
I thought that's what you meant that file.e has a read_file like function
already?
--
Jeremy Cowgar
http://jeremy.cowgar.com
9. Re: standard read_file()
Jeremy Cowgar wrote:
>
> Kat wrote:
> >
> > I thought it was in the code i posted here a minute ago. Didn't you see it?
> >
>
> Yes, but you said it was in file.e already. I was looking in existing file.e's
> for it, as being distributed with Euphoria already.
>
> I thought that's what you meant that file.e has a read_file like function
> already?
A file.e i got from the archives had a read_file like function in it. And it
seemed right to have a file function in file.e. The function itself has gone thru
many iterations here as i made efforts to speed it up. I never checked the
standard distribution, since i move all include and runtime files in one
directory for each application, and often just copy over directories full of
files known to run well together, rather than build a new application dir with
hunt-and-find files from the archive. This saves trouble with different include
files, different Eu versions, and mostly different win32lib versions. But all my
file.e have this same getf() in it, i've been using it for many years. Eight
years, perhaps more.
I still should get it to use Jordah's or Hayden's memory routines, since the
sequence allocated for the file to be read into isn't freed by Eu when done with
it. This computer has more memory than the old computer.
Quite a while ago, Euman , Tommy Carlier , and Derek did some memory store
routines for reading/writing files thru. I have them, but a quick search in the
Eu archives online does not turn them up. They use kernal32 calls, and last i
used them was on an older win95b box, and i didn't get the same performance Derek
did on his newer equipment. I should try them again, on the new computer.
Jeffrey Fielding made a file include as well, using win32 calls. Perhaps
win32fil.zip would be a good thing to look at, altho he did not include file
reading or writing in it. I don't expect it to be *nix compatable for kernal32
calls, but the rest of it may be useful.
Kat
10. Re: standard read_file()
c.k.lester wrote:
> Okay, they're equal now. Except your read_file() is twice as fast! Nice! :)
I want to defend my read_file :P
I tried to test that too, with this result for 7 MB file, 5 iteration:
0.672 -- my read_file
0.407 -- j_cougar's read_file
0.265 -- my read_file
0.391 -- j_cougar's read_file
0.266 -- my read_file
0.39 -- j_cougar's read_file
0.266 -- my read_file
0.39 -- j_cougar's read_file
0.266 -- my read_file
0.422 -- j_cougar's read_file
Maybe what happened to you was that you only tried for one iteration.
It is slower because the file is not cached by windows or whatever OS you
are using.
11. Re: standard read_file()
While read_fie() is being discussed, I'd suggest enhancing gets() so that files
with a Mac format (lines ending in \r) can be read as well.
his could have been done with a trivial backend mod, but would have made rading
in ASCII or binary mode different under Linux, which is said to be unexpected..
Yet, even though Eu is not ported to the Mac platform, one can have to process
txt files in the Mac format, related with programming or not, and expect to
process them using Euphoria. There has been a thread on this topic some time ago.
CChris
12. Re: standard read_file()
CChris wrote:
>
>
> Yet, even though Eu is not ported to the Mac platform
Actually, it has been ported. You can get a 3.x version that runs great on Intel
macs from The Archive. It was never accepted into the core for some reason.
--
Jeremy Cowgar
http://jeremy.cowgar.com
