Re: HLA Lib

Perhaps you missed the fact that the delimiters character set can be
user-defined.
allright then

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 just did. the lowmost functions seemed to be done pretty fast. But
the higher level functions suffered from lot of abstraction there, for
example separate predicting number of digits before padding, and
separate conversion.

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.

i believe :)

i was solving this for very long for FASMLIB until some good state.
General answer is: utilize your own read buffering for file.

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.

yes, that is exactly your case.

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).

you see, we agree on this :)

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.

some init and finishing codes are a must-have for solid design
library. How are you going to implement heap for linux without it? It
doesn't have to be hidden, you can force user to always call it :)

???
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.

but other functions regarding stdin seem to act as if stdin shouldn't
never give EOF. for example stdin._geti_ fails to read number if it's
last thing in redirected file.

.

Relevant Pages

  • Re: HLA Lib
    ... I think you should also provide some routine to read stdin even ... The fileio package does not do any buffering, ... stdin input deserves same kind of attention as file I/O. ... EOF is a good example. ...
    (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: problem with getchar
    ... shekhardeodhar wrote: ... You have two function operating on stdin. ... file is still at EOF, ... So read the input once and draw conclusions. ...
    (comp.lang.c)