Hi folks,
There's an interesting discussion going on at Reddit about
choosing a replacement language for 0install:
http://www.reddit.com/r/programming/comments/1g1fhf/case_study_for_replacing_python_in_0install/
I've tried to do a bit of D advocacy there, but there's more to
be done. :) If y
On Monday, 10 June 2013 at 18:25:05 UTC, Graham Fawcett wrote:
Hi folks,
There's an interesting discussion going on at Reddit about
choosing a replacement language for 0install:
http://www.reddit.com/r/programming/comments/1g1fhf/case_study_for_replacing_python_in_0install/
I've tried to do
Graham Fawcett:
http://www.reddit.com/r/programming/comments/1g1fhf/case_study_for_replacing_python_in_0install/
I was about to link that Reddit thread here myself :-)
The original article proposes to translate to your language this
little piece of Python+libs and measure its speed, safety i
On Monday, 10 June 2013 at 20:51:16 UTC, Jesse Phillips wrote:
On Monday, 10 June 2013 at 18:25:05 UTC, Graham Fawcett wrote:
Hi folks,
There's an interesting discussion going on at Reddit about
choosing a replacement language for 0install:
http://www.reddit.com/r/programming/comments/1g1fhf
On Monday, 10 June 2013 at 18:25:05 UTC, Graham Fawcett wrote:
Hi folks,
There's an interesting discussion going on at Reddit about
choosing a replacement language for 0install:
http://www.reddit.com/r/programming/comments/1g1fhf/case_study_for_replacing_python_in_0install/
I've tried to do
On Monday, 10 June 2013 at 22:06:29 UTC, Anthony Goins wrote:
If you want to know what happens on my linux box
1 module hellotest;
2
3 import std.stdio;
4
5 void main()
6 {
7 writeln("hello world.");
8 }
anthony@LinuxGen12:~/projects/temp$ ./hellotest
hello world.
anthon
ixid:
Be careful with advocating D too much, I think what with the
very positive but visible D conference coverage we don't want
to seem like zealous fanboys.
Right.
A better idea is to port the proposed code to D, count how many
points it gets, and show all of it in the Reddit thread.
Bye
On 6/10/2013 4:26 PM, Jesse Phillips wrote:
On Monday, 10 June 2013 at 22:06:29 UTC, Anthony Goins wrote:
If you want to know what happens on my linux box
1 module hellotest;
2
3 import std.stdio;
4
5 void main()
6 {
7 writeln("hello world.");
8 }
anthony@LinuxGen12:~/p
On 6/10/2013 5:35 PM, David Nadlinger wrote:
On Tuesday, 11 June 2013 at 00:27:28 UTC, Walter Bright wrote:
On 6/10/2013 4:26 PM, Jesse Phillips wrote:
So D fails the test too. But now that I think about it, isn't /dev/null where
you write data to a black hole... maybe he meant /dev/zero
Yeah
On Tuesday, 11 June 2013 at 00:27:28 UTC, Walter Bright wrote:
On 6/10/2013 4:26 PM, Jesse Phillips wrote:
So D fails the test too. But now that I think about it, isn't
/dev/null where
you write data to a black hole... maybe he meant /dev/zero
Yeah, I thought /dev/null was a bit bucket. D sho
On Tuesday, 11 June 2013 at 00:36:50 UTC, Walter Bright wrote:
Ah, I see. In that case, writeln should have thrown an
exception. Should submit a bug report.
http://d.puremagic.com/issues/show_bug.cgi?id=10328
On 6/10/13 6:06 PM, Anthony Goins wrote:
On Monday, 10 June 2013 at 20:51:16 UTC, Jesse Phillips wrote:
On Monday, 10 June 2013 at 18:25:05 UTC, Graham Fawcett wrote:
Hi folks,
There's an interesting discussion going on at Reddit about choosing a
replacement language for 0install:
http://www.
On Tuesday, 11 June 2013 at 04:02:59 UTC, Andrei Alexandrescu
wrote:
The test program is flawed; writeln() writes to stdout, and the
redirection is to stdin.
Wouldn't stdin be fd 0?
David
On Tuesday, 11 June 2013 at 04:04:03 UTC, David Nadlinger wrote:
On Tuesday, 11 June 2013 at 04:02:59 UTC, Andrei Alexandrescu
wrote:
The test program is flawed; writeln() writes to stdout, and
the redirection is to stdin.
Wouldn't stdin be fd 0?
David
What David said. Here's the same thin
On 6/11/13 12:04 AM, David Nadlinger wrote:
On Tuesday, 11 June 2013 at 04:02:59 UTC, Andrei Alexandrescu wrote:
The test program is flawed; writeln() writes to stdout, and the
redirection is to stdin.
Wouldn't stdin be fd 0?
David
Oh indeed my bad. But the test is still flawed. Consider:
On 6/11/13 12:16 AM, Infiltrator wrote:
On Tuesday, 11 June 2013 at 04:04:03 UTC, David Nadlinger wrote:
On Tuesday, 11 June 2013 at 04:02:59 UTC, Andrei Alexandrescu wrote:
The test program is flawed; writeln() writes to stdout, and the
redirection is to stdin.
Wouldn't stdin be fd 0?
David
On Tue, 11 Jun 2013 01:39:47 -0400
Andrei Alexandrescu wrote:
> On 6/11/13 12:16 AM, Infiltrator wrote:
> > On Tuesday, 11 June 2013 at 04:04:03 UTC, David Nadlinger wrote:
> >> On Tuesday, 11 June 2013 at 04:02:59 UTC, Andrei Alexandrescu
> >> wrote:
> >>> The test program is flawed; writeln() w
On 2013-06-11 08:38, Nick Sabalausky wrote:
I just tried both on Debian 6:
nick@debian6:~$ cat 1< /dev/null
cfws
cat: write error: Bad file descriptor
nick@debian6:~$ echo meh 1< /dev/null
bash: echo: write error: Bad file descriptor
Maybe OSX behaves differently?
I get the same on Mac OS X
On Tue, 11 Jun 2013 09:09:43 +0200
Jacob Carlborg wrote:
> On 2013-06-11 08:38, Nick Sabalausky wrote:
>
> > I just tried both on Debian 6:
> >
> > nick@debian6:~$ cat 1< /dev/null
> > cfws
> > cat: write error: Bad file descriptor
> > nick@debian6:~$ echo meh 1< /dev/null
> > bash: echo: write
On Tuesday, 11 June 2013 at 10:55:16 UTC, Nick Sabalausky wrote:
On Tue, 11 Jun 2013 09:09:43 +0200
Jacob Carlborg wrote:
On 2013-06-11 08:38, Nick Sabalausky wrote:
> I just tried both on Debian 6:
>
> nick@debian6:~$ cat 1< /dev/null
> cfws
> cat: write error: Bad file descriptor
> nick@deb
On 2013-06-11 12:55, Nick Sabalausky wrote:
I think I remember him saying somewhere that he uses zsh, although I
can't look it up or test it on zsh at the moment.
With zsh and the first one I get:
cat: stdout: Bad file descriptor
With the second one I get nothing and 0 as the exit code.
--
On 6/11/13 3:09 AM, Jacob Carlborg wrote:
On 2013-06-11 08:38, Nick Sabalausky wrote:
I just tried both on Debian 6:
nick@debian6:~$ cat 1< /dev/null
cfws
cat: write error: Bad file descriptor
nick@debian6:~$ echo meh 1< /dev/null
bash: echo: write error: Bad file descriptor
Maybe OSX behaves
On Tue, 11 Jun 2013 13:17:13 +0200
"estew" wrote:
> On Tuesday, 11 June 2013 at 10:55:16 UTC, Nick Sabalausky wrote:
> > On Tue, 11 Jun 2013 09:09:43 +0200
> > Jacob Carlborg wrote:
> >
> >> On 2013-06-11 08:38, Nick Sabalausky wrote:
> >>
> >> > I just tried both on Debian 6:
> >> >
> >> > nic
On Tuesday, 11 June 2013 at 12:37:53 UTC, Andrei Alexandrescu
wrote:
On 6/11/13 3:09 AM, Jacob Carlborg wrote:
On 2013-06-11 08:38, Nick Sabalausky wrote:
I just tried both on Debian 6:
nick@debian6:~$ cat 1< /dev/null
cfws
cat: write error: Bad file descriptor
nick@debian6:~$ echo meh 1< /de
On Tue, 11 Jun 2013 01:37:52 -0400, Andrei Alexandrescu
wrote:
On 6/11/13 12:04 AM, David Nadlinger wrote:
On Tuesday, 11 June 2013 at 04:02:59 UTC, Andrei Alexandrescu wrote:
The test program is flawed; writeln() writes to stdout, and the
redirection is to stdin.
Wouldn't stdin be fd 0?
On 6/11/13 11:57 AM, Steven Schveighoffer wrote:
This code DOES fail:
import std.stdio;
int main()
{
writeln("hello");
std.stdio.stdout.flush();
return 0;
}
Ah, I suspected so. (At a point in D's history writeln() did do a flush;
people wanted to eliminate it for efficiency reasons.)
We co
On Tuesday, 11 June 2013 at 16:50:50 UTC, Andrei Alexandrescu
wrote:
On 6/11/13 11:57 AM, Steven Schveighoffer wrote:
This code DOES fail:
import std.stdio;
int main()
{
writeln("hello");
std.stdio.stdout.flush();
return 0;
}
Ah, I suspected so. (At a point in D's history writeln() did do
a
On Tuesday, 11 June 2013 at 17:01:43 UTC, Lars T. Kyllingstad
wrote:
Ah, I suspected so. (At a point in D's history writeln() did
do a flush; people wanted to eliminate it for efficiency
reasons.)
We could introduce a flush() with throw in std.stdiobase.
As in a module destructor? Isn't it
On Tue, 11 Jun 2013 13:01:41 -0400, Lars T. Kyllingstad
wrote:
On Tuesday, 11 June 2013 at 16:50:50 UTC, Andrei Alexandrescu wrote:
On 6/11/13 11:57 AM, Steven Schveighoffer wrote:
This code DOES fail:
import std.stdio;
int main()
{
writeln("hello");
std.stdio.stdout.flush();
return 0;
}
On 6/11/13 1:01 PM, Lars T. Kyllingstad wrote:
On Tuesday, 11 June 2013 at 16:50:50 UTC, Andrei Alexandrescu wrote:
On 6/11/13 11:57 AM, Steven Schveighoffer wrote:
This code DOES fail:
import std.stdio;
int main()
{
writeln("hello");
std.stdio.stdout.flush();
return 0;
}
Ah, I suspected so
Andrei Alexandrescu wrote:
> On 6/11/13 3:09 AM, Jacob Carlborg wrote:
>> On 2013-06-11 08:38, Nick Sabalausky wrote:
>>
>>> I just tried both on Debian 6:
>>>
>>> nick@debian6:~$ cat 1< /dev/null
>>> cfws
>>> cat: write error: Bad file descriptor
>>> nick@debian6:~$ echo meh 1< /dev/null
>>> bash:
On 6/11/2013 11:38 AM, Andrei Alexandrescu wrote:
On 6/11/13 1:01 PM, Lars T. Kyllingstad wrote:
On Tuesday, 11 June 2013 at 16:50:50 UTC, Andrei Alexandrescu wrote:
On 6/11/13 11:57 AM, Steven Schveighoffer wrote:
This code DOES fail:
import std.stdio;
int main()
{
writeln("hello");
std.std
On Tue, 11 Jun 2013 14:44:17 -0400, Jérôme M. Berger
wrote:
Andrei Alexandrescu wrote:
On 6/11/13 3:09 AM, Jacob Carlborg wrote:
On 2013-06-11 08:38, Nick Sabalausky wrote:
I just tried both on Debian 6:
nick@debian6:~$ cat 1< /dev/null
cfws
cat: write error: Bad file descriptor
nick@deb
On Tue, 11 Jun 2013 14:38:51 -0400, Andrei Alexandrescu
wrote:
On 6/11/13 1:01 PM, Lars T. Kyllingstad wrote:
As in a module destructor? Isn't it better to let the error pass
silently rather than throwing an exception that can't be caught?
It will not be caught but will cause the entire pr
On Tuesday, 11 June 2013 at 18:38:51 UTC, Andrei Alexandrescu
wrote:
On 6/11/13 1:01 PM, Lars T. Kyllingstad wrote:
As in a module destructor? Isn't it better to let the error
pass
silently rather than throwing an exception that can't be
caught?
It will not be caught but will cause the entire
On Tuesday, 11 June 2013 at 16:50:50 UTC, Andrei Alexandrescu
wrote:
On 6/11/13 11:57 AM, Steven Schveighoffer wrote:
This code DOES fail:
import std.stdio;
int main()
{
writeln("hello");
std.stdio.stdout.flush();
return 0;
}
Ah, I suspected so. (At a point in D's history writeln() did do
a
On 6/11/13 3:36 PM, Lars T. Kyllingstad wrote:
On Tuesday, 11 June 2013 at 18:38:51 UTC, Andrei Alexandrescu wrote:
On 6/11/13 1:01 PM, Lars T. Kyllingstad wrote:
As in a module destructor? Isn't it better to let the error pass
silently rather than throwing an exception that can't be caught?
On 6/11/13 3:25 PM, Steven Schveighoffer wrote:
On Tue, 11 Jun 2013 14:38:51 -0400, Andrei Alexandrescu
wrote:
On 6/11/13 1:01 PM, Lars T. Kyllingstad wrote:
As in a module destructor? Isn't it better to let the error pass
silently rather than throwing an exception that can't be caught?
It
On 6/11/2013 12:25 PM, Steven Schveighoffer wrote:
On Tue, 11 Jun 2013 14:38:51 -0400, Andrei Alexandrescu
wrote:
On 6/11/13 1:01 PM, Lars T. Kyllingstad wrote:
As in a module destructor? Isn't it better to let the error pass
silently rather than throwing an exception that can't be caught?
On Tue, 11 Jun 2013 16:42:43 -0700
Walter Bright wrote:
>
> I used to entertain myself and friends by setting up unix so the disk
> is nearly full, and then trying various commands that produced
> output, and sending the output to the disk.
>
> Because so many C programs fail to check for failed
On Tue, 11 Jun 2013 17:36:24 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Tuesday, 11 June 2013 at 16:50:50 UTC, Andrei Alexandrescu wrote:
On 6/11/13 11:57 AM, Steven Schveighoffer wrote:
This code DOES fail:
import std.stdio;
int main()
{
writeln("hello");
std.stdio.stdout.flush()
On 6/11/2013 7:07 PM, Steven Schveighoffer wrote:
On Tue, 11 Jun 2013 17:36:24 -0400, Denis Koroskin <2kor...@gmail.com> wrote:
On Tuesday, 11 June 2013 at 16:50:50 UTC, Andrei Alexandrescu wrote:
On 6/11/13 11:57 AM, Steven Schveighoffer wrote:
This code DOES fail:
import std.stdio;
int ma
On Tue, 11 Jun 2013 23:42:33 -0400, Walter Bright
wrote:
On 6/11/2013 7:07 PM, Steven Schveighoffer wrote:
On Tue, 11 Jun 2013 17:36:24 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Tuesday, 11 June 2013 at 16:50:50 UTC, Andrei Alexandrescu wrote:
On 6/11/13 11:57 AM, Steven Schve
On 6/11/2013 8:55 PM, Steven Schveighoffer wrote:
On Tue, 11 Jun 2013 23:42:33 -0400, Walter Bright
wrote:
On 6/11/2013 7:07 PM, Steven Schveighoffer wrote:
On Tue, 11 Jun 2013 17:36:24 -0400, Denis Koroskin <2kor...@gmail.com> wrote:
On Tuesday, 11 June 2013 at 16:50:50 UTC, Andrei Alexand
On Wed, 12 Jun 2013 00:23:36 -0400, Walter Bright
wrote:
On 6/11/2013 8:55 PM, Steven Schveighoffer wrote:
Note, it's only done once, the very first time anything is written.
The rest of
the time, flushing follows normal procedure.
In effect, the first write confirms the FD is valid, t
On Wednesday, 12 June 2013 at 04:23:39 UTC, Walter Bright wrote:
I don't agree. Buffering is often done on page size boundaries
- throwing out a random number of characters and then flushing
will get it all wonky.
You clearly missed something in the discussion here. The proposal
is to flush o
On 6/11/2013 10:15 PM, deadalnix wrote:
On Wednesday, 12 June 2013 at 04:23:39 UTC, Walter Bright wrote:
I don't agree. Buffering is often done on page size boundaries - throwing out
a random number of characters and then flushing will get it all wonky.
You clearly missed something in the disc
On 6/11/13 10:07 PM, Steven Schveighoffer wrote:
On Tue, 11 Jun 2013 17:36:24 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
The best solution would be for writeln() to throw on use, and I think
it's fairly easy to implement: just flush once after using the file
descriptor for the first time,
On 6/11/13 11:42 PM, Walter Bright wrote:
I think you meant "just flush once after using the FILE * for the
first time"
I think it's a bad idea, it'll muck up the buffering (i.e. make it slower).
The fix is when main() returns to do the flush there.
I agree. One question is, should we flush
On Wed, 12 Jun 2013 02:48:44 -0400, Walter Bright
wrote:
On 6/11/2013 10:15 PM, deadalnix wrote:
On Wednesday, 12 June 2013 at 04:23:39 UTC, Walter Bright wrote:
I don't agree. Buffering is often done on page size boundaries -
throwing out
a random number of characters and then flushing w
On Wed, 12 Jun 2013 08:26:43 -0400, Andrei Alexandrescu
wrote:
On 6/11/13 10:07 PM, Steven Schveighoffer wrote:
On Tue, 11 Jun 2013 17:36:24 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
The best solution would be for writeln() to throw on use, and I think
it's fairly easy to implement:
On 6/12/13 11:18 AM, Steven Schveighoffer wrote:
On Wed, 12 Jun 2013 02:48:44 -0400, Walter Bright
wrote:
On 6/11/2013 10:15 PM, deadalnix wrote:
On Wednesday, 12 June 2013 at 04:23:39 UTC, Walter Bright wrote:
I don't agree. Buffering is often done on page size boundaries -
throwing out
a r
On Wed, 12 Jun 2013 11:32:58 -0400, Andrei Alexandrescu
wrote:
I agree performance is not a problem. But it's just weird behavior. We
should flush stdout termination, anything else would have to be
carefully justified - and this is not.
stdout is flushed on termination. Your code just d
On 6/12/2013 8:18 AM, Steven Schveighoffer wrote:
No, it does perform well. You are still not understanding the proposal.
Yes, I understand your proposal quite well.
Your benchmark is seriously flawed. Most modern systems cache writes in memory,
and have a delayed write to the media. This hi
On Wed, 12 Jun 2013 11:55:39 -0400, Walter Bright
wrote:
On 6/12/2013 8:18 AM, Steven Schveighoffer wrote:
No, it does perform well. You are still not understanding the proposal.
Yes, I understand your proposal quite well.
Your benchmark is seriously flawed. Most modern systems cache wri
On 6/12/2013 8:34 AM, Steven Schveighoffer wrote:
On Wed, 12 Jun 2013 11:32:58 -0400, Andrei Alexandrescu
wrote:
I agree performance is not a problem. But it's just weird behavior. We should
flush stdout termination, anything else would have to be carefully justified -
and this is not.
stdou
On 6/12/2013 5:30 AM, Andrei Alexandrescu wrote:
On 6/11/13 11:42 PM, Walter Bright wrote:
I think you meant "just flush once after using the FILE * for the
first time"
I think it's a bad idea, it'll muck up the buffering (i.e. make it slower).
The fix is when main() returns to do the flush t
On 6/12/13 11:59 AM, Walter Bright wrote:
On 6/12/2013 5:30 AM, Andrei Alexandrescu wrote:
On 6/11/13 11:42 PM, Walter Bright wrote:
I think you meant "just flush once after using the FILE * for the
first time"
I think it's a bad idea, it'll muck up the buffering (i.e. make it
slower).
The f
On 6/12/13 12:02 PM, Steven Schveighoffer wrote:
On Wed, 12 Jun 2013 11:55:39 -0400, Walter Bright
wrote:
On 6/12/2013 8:18 AM, Steven Schveighoffer wrote:
No, it does perform well. You are still not understanding the proposal.
Yes, I understand your proposal quite well.
Your benchmark is
On 6/12/2013 8:59 AM, Walter Bright wrote:
I haven't heard about the fflush(null) thing. That may be gnu-specific. I don't
think that works on Windows.
Followup: I have indeed heard about the fflush(null) thing, as it's in the
fflush code I wrote several eons ago!
On Wednesday, 12 June 2013 at 16:34:08 UTC, Andrei Alexandrescu
wrote:
It's quite an old standard feature albeit obscure, I found it
and forgot about it a couple of times already. Works
everywhere, see
http://www.cplusplus.com/reference/cstdio/ferror/ and
http://msdn.microsoft.com/en-us/librar
On 6/12/2013 9:02 AM, Steven Schveighoffer wrote:
On Wed, 12 Jun 2013 11:55:39 -0400, Walter Bright
wrote:
On 6/12/2013 8:18 AM, Steven Schveighoffer wrote:
No, it does perform well. You are still not understanding the proposal.
Yes, I understand your proposal quite well.
Your benchmark i
On 6/12/13 12:40 PM, Walter Bright wrote:
You are proposing that this repeated write of the first sector be done
for all file output.
No, he's proposing that only the very first write flushes. Not every
write. I'd argue it's a bizarre thing to do, but not that it's
necessarily slow.
Andrei
Denis Koroskin wrote:
> The best solution would be for writeln() to throw on use, and I
> think it's fairly easy to implement: just flush once after using
> the file descriptor for the first time, and throw if it fails.
>
> While it doesn't cover a case where file descriptor becomes
> non-writa
On 6/12/2013 10:07 AM, Andrei Alexandrescu wrote:
On 6/12/13 12:40 PM, Walter Bright wrote:
You are proposing that this repeated write of the first sector be done
for all file output.
No, he's proposing that only the very first write flushes. Not every write. I'd
argue it's a bizarre thing to
On 6/12/2013 10:36 AM, "Jérôme M. Berger" wrote:
Actually, the best solution is to check if the file is writable
before writing and *without flushing*. On Posix systems, this can be
done with:
fcntl (fd, F_GETFL) & W_OK
Sure, but that doesn't cover the case of a write failure because t
On 6/12/2013 9:02 AM, Steven Schveighoffer wrote:
If you can demonstrate your theory, I will concede. Until you do, don't expect
any more responses, it's no use arguing when you don't understand the problem.
There's another reason it won't work. If there are 4 bytes of free space left on
the
Here's a radical thought: should stdout even be global?
With any other file, this wouldn't be an issue because File's
dtor calls close() which (I'm pretty sure) flushes the file, and
thus would detect the error at the latest, when it goes out of
scope.
I think if stdout wasn't global, I'd be
On 6/12/13 1:36 PM, "Jérôme M. Berger" wrote:
Denis Koroskin wrote:
The best solution would be for writeln() to throw on use, and I
think it's fairly easy to implement: just flush once after using
the file descriptor for the first time, and throw if it fails.
While it doesn't cover a case where
On Wed, 12 Jun 2013 11:56:59 -0400, Walter Bright
wrote:
On 6/12/2013 8:34 AM, Steven Schveighoffer wrote:
On Wed, 12 Jun 2013 11:32:58 -0400, Andrei Alexandrescu
wrote:
I agree performance is not a problem. But it's just weird behavior. We
should
flush stdout termination, anything else
On Wed, 12 Jun 2013 12:40:53 -0400, Walter Bright
wrote:
On 6/12/2013 9:02 AM, Steven Schveighoffer wrote:
On Wed, 12 Jun 2013 11:55:39 -0400, Walter Bright
wrote:
On 6/12/2013 8:18 AM, Steven Schveighoffer wrote:
No, it does perform well. You are still not understanding the
proposal
On 6/12/13 2:36 PM, Steven Schveighoffer wrote:
On Wed, 12 Jun 2013 11:56:59 -0400, Walter Bright
wrote:
On 6/12/2013 8:34 AM, Steven Schveighoffer wrote:
On Wed, 12 Jun 2013 11:32:58 -0400, Andrei Alexandrescu
wrote:
I agree performance is not a problem. But it's just weird behavior.
We s
On Wed, 12 Jun 2013 13:58:45 -0400, Walter Bright
wrote:
On 6/12/2013 10:36 AM, "Jérôme M. Berger" wrote:
Actually, the best solution is to check if the file is writable
before writing and *without flushing*. On Posix systems, this can be
done with:
fcntl (fd, F_GETFL) & W_OK
Sure
On Wed, 12 Jun 2013 13:36:17 -0400, Jérôme M. Berger
wrote:
Denis Koroskin wrote:
The best solution would be for writeln() to throw on use, and I
think it's fairly easy to implement: just flush once after using
the file descriptor for the first time, and throw if it fails.
While it doesn't co
On 6/12/2013 11:41 AM, Steven Schveighoffer wrote:
It is already. Why would you think it's not? The specific case being discussed
is when the file descriptor is invalid from the start.
The problem is more general than the specific case, as I pointed out in another
post here.
It is not reli
On 6/12/2013 11:36 AM, Steven Schveighoffer wrote:
If I understand correctly, the buffer is flushed, and ptr is reset to the base,
the count is reset to 0. I don't see any code in there that does any kind of
realignment.
You write 7 bytes, fflush. Now, every 4K buffered write from then on is g
On 6/12/13 3:40 PM, Walter Bright wrote:
I didn't say it was. See my other reply. In any case, if fflush is not
called on subsequent writelns, it is still possible to have the first
writeln succeed, the subsequent writelns fail and have main() return
success.
I'm a bit surprised that there's an
12-Jun-2013 22:36, Steven Schveighoffer пишет:
On Wed, 12 Jun 2013 12:40:53 -0400, Walter Bright
...
No, this is incorrect. fflush is not called on subsequent writeln.
Not only that, but we only have to do this on FILE * that were
initialized with unknown file descriptors (such as
stdin/stdou
On Wed, 12 Jun 2013 15:40:10 -0400, Walter Bright
wrote:
On 6/12/2013 11:36 AM, Steven Schveighoffer wrote:
If I understand correctly, the buffer is flushed, and ptr is reset to
the base,
the count is reset to 0. I don't see any code in there that does any
kind of
realignment.
You wri
On Wed, 12 Jun 2013 16:41:03 -0400, Dmitry Olshansky
wrote:
12-Jun-2013 22:36, Steven Schveighoffer пишет:
On Wed, 12 Jun 2013 12:40:53 -0400, Walter Bright
...
No, this is incorrect. fflush is not called on subsequent writeln.
Not only that, but we only have to do this on FILE * that we
On 6/13/2013 6:24 AM, Steven Schveighoffer wrote:
If this was such a big deal, then FILE * would guarantee the alignment went
back. It's not that hard.
I know it isn't hard. But D's charter is not to go and patch the C runtime
library, nor is that remotely practical across all the thousands o
On Thu, Jun 13, 2013 at 11:11:06AM -0700, Walter Bright wrote:
> On 6/13/2013 6:24 AM, Steven Schveighoffer wrote:
[...]
> >This isn't the problem that was presented. The problem that was
> >presented is that given an invalid file descriptor, writeln happily
> >works (as long as you don't cause a
On 2013-06-13 20:11, Walter Bright wrote:
I know it isn't hard. But D's charter is not to go and patch the C
runtime library, nor is that remotely practical across all the thousands
of C implementations out there.
Why not? Why shouldn't we try to be better than C? Perhaps we shouldn't
rely on
On 6/14/2013 12:10 AM, Jacob Carlborg wrote:
On 2013-06-13 20:11, Walter Bright wrote:
I know it isn't hard. But D's charter is not to go and patch the C
runtime library, nor is that remotely practical across all the thousands
of C implementations out there.
Why not? Why shouldn't we try to b
On Thursday, 13 June 2013 at 18:11:12 UTC, Walter Bright wrote:
What is wrong and needs fixing is the program exiting with
"success" indication when the output has actually failed.
What's wrong is a program existing with a status code *different*
from one that was supplied by a programmer.
On Wednesday, 12 June 2013 at 06:48:48 UTC, Walter Bright wrote:
On 6/11/2013 10:15 PM, deadalnix wrote:
On Wednesday, 12 June 2013 at 04:23:39 UTC, Walter Bright
wrote:
I don't agree. Buffering is often done on page size
boundaries - throwing out
a random number of characters and then flushing
On 6/14/2013 1:11 AM, Denis Koroskin wrote:
Does it look like it's slower? To me it looks like it's actually FASTER with a
flush, although I don't know why.
Because of write caching, you can get very different results from one run to the
next of the same program.
On Friday, 14 June 2013 at 08:17:02 UTC, Walter Bright wrote:
On 6/14/2013 1:11 AM, Denis Koroskin wrote:
Does it look like it's slower? To me it looks like it's
actually FASTER with a
flush, although I don't know why.
Because of write caching, you can get very different results
from one run
On Friday, 14 June 2013 at 08:24:54 UTC, Denis Koroskin wrote:
On Friday, 14 June 2013 at 08:17:02 UTC, Walter Bright wrote:
On 6/14/2013 1:11 AM, Denis Koroskin wrote:
Does it look like it's slower? To me it looks like it's
actually FASTER with a
flush, although I don't know why.
Because of
On Fri, 14 Jun 2013 04:24:53 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Friday, 14 June 2013 at 08:17:02 UTC, Walter Bright wrote:
On 6/14/2013 1:11 AM, Denis Koroskin wrote:
Does it look like it's slower? To me it looks like it's actually
FASTER with a
flush, although I don't kno
On 6/14/2013 8:22 AM, Steven Schveighoffer wrote:
And quite honestly, if disk performance were dependent on user-land C buffering
schemes, C runtime writers would pay more attention to the C buffering scheme
and make sure it performs well!
Actually, this has been a common oversight of C runtime
On Fri, 14 Jun 2013 13:58:33 -0400, Walter Bright
wrote:
On 6/14/2013 8:22 AM, Steven Schveighoffer wrote:
And quite honestly, if disk performance were dependent on user-land C
buffering
schemes, C runtime writers would pay more attention to the C buffering
scheme
and make sure it perfor
On 6/14/2013 11:43 AM, Steven Schveighoffer wrote:
The 80's are a long time ago.
But old code can live on in surprising ways.
Plus, your posting of the source code pretty much
refutes that your buffering scheme takes into account how important this should
be. It ignores alignment of writes
On Fri, 14 Jun 2013 15:17:00 -0400, Walter Bright
wrote:
On 6/14/2013 11:43 AM, Steven Schveighoffer wrote:
The 80's are a long time ago.
But old code can live on in surprising ways.
The code living on is not what I'm talking about. The *assumptions*
living on is the problem :) Old c
On 6/14/2013 1:02 PM, Steven Schveighoffer wrote:
I think in the end, we are optimizing here in the wrong place. If a specific
hardware/software combination requires specific buffering, the place to handle
it is in the runtime, not code on top of it. If the C runtime that D uses isn't
up to snu
On Fri, 14 Jun 2013 16:31:35 -0400, Walter Bright
wrote:
On 6/14/2013 1:02 PM, Steven Schveighoffer wrote:
I think in the end, we are optimizing here in the wrong place. If a
specific
hardware/software combination requires specific buffering, the place to
handle
it is in the runtime, not
On Friday, 14 June 2013 at 20:31:39 UTC, Walter Bright wrote:
On 6/14/2013 1:02 PM, Steven Schveighoffer wrote:
I think in the end, we are optimizing here in the wrong place.
If a specific
hardware/software combination requires specific buffering, the
place to handle
it is in the runtime, not
On 6/14/2013 10:45 PM, deadalnix wrote:
I don't think any of the proposed fixes is a good idea. With he one you are
pushing for, the program can fail behind the feet of the programmer, which is
not better.
Please explain.
On Saturday, 15 June 2013 at 06:49:00 UTC, Walter Bright wrote:
On 6/14/2013 10:45 PM, deadalnix wrote:
I don't think any of the proposed fixes is a good idea. With
he one you are
pushing for, the program can fail behind the feet of the
programmer, which is
not better.
Please explain.
The
On 6/15/2013 1:36 AM, deadalnix wrote:
The solution that consist into flushing in main at the end of the program is
problematic as well. At this point, from programmer perspective, the program ran
fun and is terminated successfully. Still the whole stuff will explode under its
feet, in the runtim
1 - 100 of 105 matches
Mail list logo
