On Sun, 04 Sep 2011 00:30:33 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
On 9/3/2011 7:33 PM, Steven Schveighoffer wrote:
Please, leave all pitchforks and torches at rest for the moment :)
I know what I wrote was a bit brutal, but this needs to be settled
before we've gone so far down that path that turning away then would be
horribly unfair to you.
I appreciate feedback, but I think there was a misunderstanding of what
this "review" was for. I think people thought I was proposing this as a
ready-to-pull replacement for std.stdio. That is not the case. It's very
much up in the air and under development. I just wanted to show people
some progress and get feedback (which I've gotten a lot of!)
The next version of it will look drastically different based on what's
been said here. But it will still contain some of the basic designs. In
essence, I am very *early* in the path, and I *want* people to turn me in
the right direction before I go too far the other way. This is the first
version that *actually works*, which is why I wanted to share it :)
Not anyone has really commented on the new interfaces. It's my fault, for
letting Andrei post the documentation as the main subject, and also not
fully documenting the module. I have no excuses, so I'll just have to
take this as a "ok, we'll try this again later".
But I did get some very good information, and know I have a lot of work to
do.
I think what you need is a marketing spiel to sell the concept of what
you're trying to do. It should include:
1. The benefits over the current std.stdio
2. Why the new API is needed to achieve those benefits
3. A migration plan for existing std.stdio code
OK
Just being more flexible isn't enough, it has to be more flexible in a
way that matters, i.e. a real example showing how kickass it is compared
to the current way.
I'll post some numbers.
2. the performance. It's much better than current stdio. Aren't people
continuously complaining at how slow i/o is in Phobos compared to other
libraries?
Why is it faster? I.e. is a wholly new interface required to make it
faster, or does it just need to be better under the hood?
Yes, a new interface is required to make it faster. You need direct
buffer access, and the current stdio does not provide that.
That being said, I think this proposal goes nowhere unless it's a mostly
drop-in replacement to the existing std.stdio. So I have to find a way to
make it fit.
3. There is no indication of how it interacts with C stdio. A primary
goal of
std.stdio was interoperability with C stdio.
useCStdio();
For some reason that just seems like a giant wart with a hair sticking
out of it. Why not just use the C stdio buffers?
1. Because most people don't care. I never ever use printf, except when I
was testing my new stdio stuff, and I needed something that worked :) My
opinion, if you are using this line, you are doing something weird, legacy
related, or you are debugging something.
2. Because C does not provide enough access to the buffers. With my
library, you can read an entire xml file, for instance, and never copy any
data out of the buffer. C never gives direct access to the buffers, and
while we can hack our way into it, its interface is still kludgy. If I
wanted to implement, for example, readUntil using C buffers, I'd have to
reimplement almost all of FILE *'s functions so I could do it properly.
And even then, I'd still have to sacrifice some things -- C is still going
to want to use its way of doing things, and I'd have to respect that.
If you read my response to the first post in this thread, you can see my
rationale.
5. flushCheck - flushing should be done based on the file type. tty's
should
be \n flushed, files when the buffer is full. I question the
performance of
using a delegate to check for flushing. How often will it be called?
Once per write to the buffer. Data is only checked once (the delegate
is never
given the same data to check again). If you want, I can look at adding
a means
to avoid using a delegate when the trigger is a single character.
And TextInput/TextOutput auto detect whether a device is a tty, and
install the
right flushcheck function if necessary.
Flushing once per write is wrong - consider the user who does a zillion
putc's. I don't see a purpose to anything beyond the C stdio ones - per
character, per \n, and per buffer.
a *check* to see if it should be flushed is done once per write. Not a
flush. A flush is only done if the check says to (or the buffer is
full). I think C's FILE * checks once per write as well, no?
I also have thought of ways to optimize this so it's, say, once per call
to writef.
7. I see nothing for 'raw' character by character input.
The interface is geared to read by processing the buffer, not one
character at a
time. Given access to the buffer, you can process one character at a
time if you
want.
See InputRange in TextInput to see how raw character-by-character input
can be
done.
Raw mode is more than that - you have to set the OS to raw mode,
otherwise it won't give you any characters until a \n is typed.
That is not an OS issue, that is a terminal issue.
Note that the current std.stdio does not provide this functionality. The
only raw functions are rawRead and rawWrite, which set binary mode. All
binary mode does is on windows enable or disable translation of \r\n to
\n. They will not do what you are asking.
8. I see nothing for determining if a char is available on the input.
How
would one implement "press any key to continue"?
I need more information. I would probably implement this as a
read(ubyte[1]), so
I don't see why it can't be that way.
There's more to it than that. Try writing it in C and you'll see what I
mean. (You have to set the io to "raw" mode, turn "echo" off, etc.)
File provides access to the OS handle, which can be used to set terminal
settings.
It might be good to add these settings as member functions of File.
-Steve
