Re: HLA Lib

On Mar 19, 1:22 pm, "vid...@xxxxxxxxx" <vid...@xxxxxxxxx> wrote:
http://webster.cs.ucr.edu/AsmTools/HLA/stdlib2/index.html

allright, so my few points:

1. why does integer reading routines skip over "," ":" and ";"? I
understand skipping over blank chars in typed input, but these are IMO
not a good idea. Same for underscores in fileio.geti funcs. Can you
explain why you decided so?

2. I think you should also provide some routine to read stdin even
without skipping initial blank characters. Most of times it is fine,
but sometimes people may not want this.

Perhaps you missed the fact that the delimiters character set can be
user-defined. Yes, the default delimiters character set was chosen to
be acceptable most of the time, but by calling conv.setdelimiters you
can change it to whatever you want.


3. reported bug with bad error catching of errors returned by linux
remained there. "os_fileio/readln" for linux is screwed copypastery of
win version ;) :DDD

Sorry, none of the Linux stuff has been done yet. I'm saving that for
last because that's when I'll be doing the FreeBSD port and the two
will (obviously) share a lot of code in common.


4. have you been thinking about speed of your routines a little bit? I
know it isn't the most important stuff, but still some border is
required.

Sure, take a look at the conversion routines.

I believe that calling all the APIs in fileio.eof

fileio.eof is ugly, no doubt. If you can suggest better code that
works in *all* cases, I'll be more than happy to use it. Every
optimization I've tried in the past has failed on one case or another.

Not to mention the fact that if someone's code is being slowed down by
calling fileio.eof, that should be a red flag that they should be
doing blocked I/O and using fileio.read to grab a large percentage of
the file at once. Better yet, they ought to be using memory-mapped I/
O. fileio.eof (and the associated item-at-a-time I/O) is really great
for knocking out quick and dirty programs (e.g., beginning student
projects), but this isn't the programming paradigm to use for high-
performance programming.


for every
converted char of fileio.geti is little too much

The fileio package does not do any buffering, on input or output.
That's the bottom line. Buffering opens up a whole host of additional
problems that I don't want to have to deal with (like handling what
happens when the program aborts for one reason or another and "hot"
buffers are laying around). Sure, all this could be handled, but that
would involve having HLA emit some code behind the user's back to
execute whenever the program quits, and surely you've seen the
reaction to that kind of stuff around here. With the single exception
of exception handling, the HLA stdlib does not require any startup or
cleanup code. I want to keep it that way. Again, if someone wants
buffering, they can use memory-mapped files (or fileio.read) and use
the conv.* library to do their processing.



5. stdin input deserves same kind of attention as file I/O. There are
several things taken in account for file I/O, but not handled in stdin
I/O. Remember stdin can be any type of file handle aswell. Handling of
EOF is a good example.

???
stdin.readln will raise the EOF exception if you insist on reading
beyond the EOF. If you're writing filter programs that generally take
file data on the stdin, you can handle EOF that way. If you *really*
want to use generic fileio functions on stdin, just call
stdin.handle() and use the resulting handing as the parameter to the
fileio functions. stdin is mainly intended for console-like input.
Cheers,
Randy Hyde



.

Relevant Pages

  • Re: HLA Lib
    ... take a look at the conversion routines. ... utilize your own read buffering for file. ... beyond the EOF. ... file data on the stdin, you can handle EOF that way. ...
    (alt.lang.asm)
  • Re: I/O buffers
    ... I am not sure where the problem resides, ... I think that buffering of stdin might be causing your problems, ... >with the engine through pipes to these handles. ...
    (comp.lang.cpp)
  • Re: fgetc() past EOF
    ... it stops reading the BrainFuck program and starts interpreting it; ... The problem is that stdin seems to lock after fgetcgets ... > an EOF from it, ... > get an EOF, and keep on trying to read from it, the interpreter hangs. ...
    (comp.lang.c)
  • Re: Is there any way to force line-buffering in a pipeline?
    ... By default unbuffer does not read from stdin. ... it is awkward to use because it exits when ... it sees EOF on input, so you have to resort to things like: ... the final grep to have finished reading the data before you close ...
    (comp.unix.shell)
  • Re: Is there any way to force line-buffering in a pipeline?
    ... > By default unbuffer does not read from stdin. ... it is awkward to use because it exits when ... > it sees EOF on input, so you have to resort to things like: ... > the final grep to have finished reading the data before you close ...
    (comp.unix.shell)