On Thu, Jun 23, 2011 at 2:52 PM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 6/23/2011 11:48 AM, Jimmy Cao wrote:
>
>> But that's not possible (to set it to line-buffering) on Windows, right?
>>
>
> Sure it is, using the usual C functions. This is not a Windows thing, it's a C runtime library thing.
>

How do you make it have line-buffering?
It's not possible to set line-buffering in Windows using setvbuf, it seems:
http://msdn.microsoft.com/en-us/library/86cebhfs(v=vs.71).aspx
_IOFBF and _IOLBF are the same.

I think this is the cause of the strange flushing inconsistencies with stdio.d from my earlier example on Windows.

On 6/23/2011 1:03 PM, Jimmy Cao wrote:
> On Thu, Jun 23, 2011 at 2:52 PM, Walter Bright <newshound2@digitalmars.com
> <mailto:newshound2@digitalmars.com>> wrote:
>
>     On 6/23/2011 11:48 AM, Jimmy Cao wrote:
>
>         But that's not possible (to set it to line-buffering) on Windows, right?
>
>
>     Sure it is, using the usual C functions. This is not a Windows thing, it's a
>     C runtime library thing.
>
>
> How do you make it have line-buffering?
> It's not possible to set line-buffering in Windows using setvbuf, it seems:
> http://msdn.microsoft.com/en-us/library/86cebhfs(v=vs.71).aspx
> _IOFBF and _IOLBF are the same.
>
> I think this is the cause of the strange flushing inconsistencies with stdio.d
> from my earlier example on Windows.

I can't say anything about VC++, but dmd on Windows is designed to work with DMC++.

http://www.digitalmars.com/rtl/stdio.html#setvbuf

On Thu, Jun 23, 2011 at 3:16 PM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 6/23/2011 1:03 PM, Jimmy Cao wrote:
>
>> On Thu, Jun 23, 2011 at 2:52 PM, Walter Bright <
>> newshound2@digitalmars.com
>> <mailto:newshound2@**digitalmars.com <newshound2@digitalmars.com>>>
>> wrote:
>>
>>    On 6/23/2011 11:48 AM, Jimmy Cao wrote:
>>
>>        But that's not possible (to set it to line-buffering) on Windows,
>> right?
>>
>>
>>    Sure it is, using the usual C functions. This is not a Windows thing,
>> it's a
>>    C runtime library thing.
>>
>>
>> How do you make it have line-buffering?
>> It's not possible to set line-buffering in Windows using setvbuf, it
>> seems:
>> http://msdn.microsoft.com/en-**us/library/86cebhfs(v=vs.71).**aspx<http://msdn.microsoft.com/en-us/library/86cebhfs(v=vs.71).aspx>
>> _IOFBF and _IOLBF are the same.
>>
>> I think this is the cause of the strange flushing inconsistencies with
>> stdio.d
>> from my earlier example on Windows.
>>
>
> I can't say anything about VC++, but dmd on Windows is designed to work with DMC++.
>
> http://www.digitalmars.com/**rtl/stdio.html#setvbuf<http://www.digitalmars.com/rtl/stdio.html#setvbuf>
>

On Windows:

import std.stdio;

extern(C) int getch();

void main()
{
    stdout.setvbuf(100, _IOLBUF);
    string mystr = "Hello\n";
    fwrite(mystr.ptr, mystr[0].sizeof, mystr.length, stdout.getFP);

    // FPUTC('\n', cast(_iobuf*)stdout.getFP);

   getch();
}

Am I doing anything wrong there? That code as it is does not flush until after a keypress (when the program terminates).  Uncomment the FPUTC call and it does flush before the keypress.

On 6/23/2011 1:30 PM, Jimmy Cao wrote:
>          stdout.setvbuf(100, _IOLBUF);


You're mixing up D and C stdio. Try using std.c.stdio.setvbuf().

On Thu, Jun 23, 2011 at 3:59 PM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 6/23/2011 1:30 PM, Jimmy Cao wrote:
>
>>         stdout.setvbuf(100, _IOLBUF);
>>
>
>
> You're mixing up D and C stdio. Try using std.c.stdio.setvbuf().
>
>
It gives me the same result.

import std.stdio;

extern(C) int getch();

void main()
{
    std.c.stdio.setvbuf(stdout.getFP, null, std.c.stdio._IOLBF, 100);
    string mystr = "Hello\n";
    fwrite(mystr.ptr, mystr[0].sizeof, mystr.length, stdout.getFP);

    // FPUTC('\n', cast(_iobuf*)stdout.getFP);

    getch();
}

On Thu, 23 Jun 2011 07:27:34 -0400, Jimmy Cao <jcao219@gmail.com> wrote:


>     Thread.sleep( 70_000_000 );  // 7 sec

Gah!

Here, let me fix that for you:

Thread.sleep(dur!"seconds"(7));

:)

-Steve

On 6/23/11, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Thu, 23 Jun 2011 07:27:34 -0400, Jimmy Cao <jcao219@gmail.com> wrote:
>
>
>>     Thread.sleep( 70_000_000 );  // 7 sec
>
> Gah!
>
> Here, let me fix that for you:
>
> Thread.sleep(dur!"seconds"(7));
>
> :)
>
> -Steve
>

I find it very odd that for seconds we use "seconds", but for everything else we use "msec", "usec", "hnsecs" abbreviations.

On 2011-06-23 14:50, Andrej Mitrovic wrote:
> On 6/23/11, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> > On Thu, 23 Jun 2011 07:27:34 -0400, Jimmy Cao <jcao219@gmail.com> wrote:
> >> Thread.sleep( 70_000_000 ); // 7 sec
> > 
> > Gah!
> > 
> > Here, let me fix that for you:
> > 
> > Thread.sleep(dur!"seconds"(7));
> > 
> > :)
> > 
> > -Steve
> 
> I find it very odd that for seconds we use "seconds", but for everything else we use "msec", "usec", "hnsecs" abbreviations.

Because it makes sense to use the full names up to seconds. After that, they're too long, so they get abbreviated.

- Jonathan M Davis

On Thu, 23 Jun 2011 18:02:02 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On 2011-06-23 14:50, Andrej Mitrovic wrote:
>> On 6/23/11, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> > On Thu, 23 Jun 2011 07:27:34 -0400, Jimmy Cao <jcao219@gmail.com>  
>> wrote:
>> >> Thread.sleep( 70_000_000 ); // 7 sec
>> >
>> > Gah!
>> >
>> > Here, let me fix that for you:
>> >
>> > Thread.sleep(dur!"seconds"(7));
>> >
>> > :)
>> >
>> > -Steve
>>
>> I find it very odd that for seconds we use "seconds", but for
>> everything else we use "msec", "usec", "hnsecs" abbreviations.
>
> Because it makes sense to use the full names up to seconds. After that,
> they're too long, so they get abbreviated.

You could argue that mseconds is not much longer than seconds.  It's still an abbreviation.

You could also argue that seconds is too long, couldn't it be secs?  One thing that sucks about having inconsistent abbreviations, I have to look them up, even when I know what I'm typing makes sense to a reader, it just may not be what the function expects.  For instance, before I sent this message, I had to look it up to make sure it was valid.

But here's an idea -- milliseconds, msecs, and mseconds could all map to the same template function.

hectonanoseconds, hm.. that's a long one :)

-Steve

Why don't we use unicode for microseconds then? :p

duration!"μs"(10);

Personally I'd be fine with:
"sec"
"ms"
"ns"
"us"

If you're dealing with time you know what those are. But the existing names are ok, except seconds because I always put "sec" by accident.