Re: [Hla-stdlib-talk] HLA StdLib project Task List

[Frank K. <fbk...@co...>]

rh...@cs... wrote:
>>To get things kind of organized, we might want to put together a "task
>>list" of items that project participants could work on.  Some  items that
>>have come up recently:
>>
>>  1)  fileio.append implementation not consistent
> 
> Yes.

Consistently raises an exception, actually. The constant exists (for 
Linux), but isn't checked for in the open routine. I can see three 
approaches to this.

1) Remove it, 'cause it isn't portable. If we do this with every new OS 
that's added, we'll soon have a very small standard library. Easy to 
maintain! :)

2) Let it work for Linux, and raise an exception for Windows. Not very 
portable. :(

3) *Make* it portable! The Windows API apparently hasn't got an "open 
for append" option (dos didn't - my 8-bit Atari did... Progress!). H:A 
can accept that option, open the file (read/write, I guess - open for 
append for readonly isn't too useful), and "seek" (SetFilePointer) to 
the end of it - "SetFilePointer (handle, 0, 0, w.FILE_END);", as a 
guess. Unless there are issues I don't see, this shouldn't be hard.

>>  2)  fileio.eof code is "crufty" according to Frank :)
> 
> The whole concept of how testing for end of file needs to be rethought. We
> may want to clean this up a tiny bit and then develop a new fileio package
> that does I/O completely differently.

FWIW, I withdraw my objection to that. "feof" isn't too pretty, but I 
don't see how else you'd do it. I was under the impression that "fread" 
*didn't* return the number of bytes read. I don't know if I 
misunderstood what I was looking at, or if it's been changed, but it 
*does* return the number of bytes read. So we don't need to do...

read one or more bytes
maybe process 'em
write one or more bytes
check for EOF
if not, do more

... which is what I thought was "crufty". We can:

read one or more bytes
if zero, goto we_be_done
process?
write
do more

... so we can "just don't do it". There's a lot of example code that 
*does* do it. Not a library problem.

>>  3)  Windows-only functions (fileio.move and copy, etc) being  removed
>>from the library.  Randy, could you give us a complete  list of these?
> 
> 
> conv.cstr and conv.a_cstr are being deprecated. Though there are
> equivalent routines in the str package.
> 
> Also, fileio.cd, .gwd, .delete, .size, and several others are being
> deprecated and moved into a new "filesys" namespace. It would be nice to
> have a *lot* of new routines added to the filesys module. In particular,
> one that would be nice to have *immediately* is a directory iterator that
> returns strings containing all the filenames in a given directory.

I smiled when I heard you were working on a "findfirst" and "findnext" 
for Linux :) We've got readdir (89) and getdents (141). I started out 
with getdents, which reads a buffer-full of dirents*, since readdir, 
which just gets one, is "obsolete". This introduced another "loop" into 
what was a recursive routine anyway... I think readdir would have been 
easier.

(* actually, seems to read some maximum number of entries, no matter how 
big your buffer is)

(note: the dirent structure is one of the things that *is* different in 
BSD - joy!)

> In other news: I am working away on the fileio module right now, doing a
> lot of clean up. I'm hoping that in about a week I'll be able to post the
> code and we can get started on the multi-lingual header files and unit
> tests for that module.
> 
> I would advise against *any* modifications to the existing library code.
> Almost every routine is going to have at least minor changes when I begin
> posting new code. That means that any effort expended right now may be
> wasted.

In the event that the new code introduces bugs (I've heard of this 
happening), you'll wish you had the changes documented in a CVS 
repository, or some such...

Best,
Frank