MOO-cows Mailing List Archive


Re: fileio vs FUP

I guess some kind of comment from the developers of FUP (Jaime and I) is in

First of all, I'd like to thank Ken Fox for spending the time developing
fileio and making it freely available. After all, this is exactly what we
did with FUP. :)
Still, it might have been nice if *some* kind of coordination had been
attempted between the two packages. I don't recall having received any
prior direct message from Ken Fox.

With the two packages available, people will probably get confused - are
they the same? Do we have to install one, or both? Brack points out that
they don't clash, which is good. Still, having both fileread() and
file_read() suggests possible problems.

Ken Fox wrote:
>Several people have written to me asking what the difference between
>FUP and fileio is.  Here are the important reasons I write fileio
>instead of using FUP for my own project:
>FUP's primary file reading and writing operations work on lists.
>Reading from the file returns a list and writing to a file is a
>single atomic action that writes a list.
>Fileio's primary interface is stdio-style streams.  Opening a file
>returns a handle that can be used as an argument to functions that
>write or read to the file as a stream.

This was planned for [future] version 2.0 of FUP. Since both Jaime and I
dedicate all of our time to working on FUP, but we're lazy, it hasn't come
out yet.
Seriously, we are open for suggestions and bug reports. We will do our best
to fix and improve FUP, as long as there's interest.

>FUP has no provision for binary I/O and may allow raw binary data
>into a MOO string (corrupting the database).  Fileio uses a system
>for binary I/O similar to the network functions.

Before people panic thanks to this comment - at least say 'potentially'
corrupting the database. And I still have to hear of someone that managed
to corrupt their database, unwittingly, using FUP.
As for binary I/O, it is slated for FUP 1.9 (i.e. next version). Colin
McCormick wrote the code and sent it to us so we can add it to the package.
Again, we're working on it all the time, etc etc.

>There are also a number of potential efficency problems with FUP.
>When FUP is reading from a file, it uses listappend which
>potentially allocates a new list for each line being read.

Again, I fail to recall a message pointing this problem out, and suggesting
a better alternative.

>to a file involves copying the file to a temporary file, adding
>lines, and renaming it.

This is done on purpose. We think this reduces significantly the chances of
losing information if something fails during the operation. We could change
this into a compile- or runtime- option, if needed. I fail to recall such a
Out of curiousity, what happens if the MOO crashes while some files are
open with fileio?

Brack wrote:
>not to mention that FUP tends to hang or crash if you use shell characters
>(<, |, etc) in arguments.

As [I think] I pointed out more than once, this statement is wrong. Maybe
it happens on Brack's system. Has anyone else had this problem?

The list of differences between FUP and fileio appears to be, um, slightly
biased against FUP. Why not mention the differences a bit more objectively?
After all, I would think that if you just want to read a whole file (or
part of it) as a LIST of STRings, a single call to fileread() should be
rather simpler than what fileio has to offer.
And I imagine you can implement filegrep() and fileextract() using fileio,
but may I assume they would be somewhat less efficient?

To summarise, what I find odd is the total lack of communication from
fileio's creator. The original announcement didn't mention FUP. The web
pages don't refer to it either.
Why is this? I have added the original fileio announcement to the FUP ftp
directory, so people are aware of fileio when they get FUP.

Collaboration, anyone?

     Gustavo Glusman              Founder/administrator of BioMOO    (public PGP key available)
        Visit BioMOO, the biologists' virtual meeting place, at
     ___________ ___________

Home | Subject Index | Thread Index