On 6/23/2011 2:05 PM, Jimmy Cao wrote:
> It gives me the same result.

It seems to be an issue with fwrite(). With fprintf, it works as expected.

On 2011-06-23 15:10, Steven Schveighoffer wrote:
> 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.

Unfortunately, there are so many variations on what they could be that there's no way to make them so that everyone is going to remember them correctly. So, no matter what I picked, someone would have been unhapy with it.

> But here's an idea -- milliseconds, msecs, and mseconds could all map to the same template function.
> 
> hectonanoseconds, hm.. that's a long one :)

I thought about doing that (though it _never_ occurred to me to use mseconds, since that feels to me like you abbreviated half of it, which is just weird to me). The problem is that that feels a bit too much like the inconsistent horror that is html where it accepts just about anything. I generally prefer things to be strict and consistent over trying to guess what was meant. It also makes the template constraints uglier. I'm not completely against the idea, but I'm not convinced that it's a good one either.

As it stands, all units seconds and greater are completely unabbreviated, and all of the sub-second units are abbreviated, which if you're going to abbreviate some but not all feels very consistent to me (though again, what seems perfectly logical to one person may not seem that way to another). I _don't_ want to change them to something else at this point. There's enough in core.time and std.datetime to get used to already, and that's a pretty heavily-used feature in those modules. It _might_ be worth making it so that other variants of the units' names work, but I'm not convinced that being lax about it is necessarily a good idea.

- Jonathan M Davis

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

> On 2011-06-23 15:10, Steven Schveighoffer wrote:
>> 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.
>
> Unfortunately, there are so many variations on what they could be that there's
> no way to make them so that everyone is going to remember them correctly. So,
> no matter what I picked, someone would have been unhapy with it.

Right.  I totally agree, if you have to have one, you just have to choose and be done with it.  The only reason we can have this conversation is because it's really easy to just add another "overload". :)

>> But here's an idea -- milliseconds, msecs, and mseconds could all map to
>> the same template function.
>>
>> hectonanoseconds, hm.. that's a long one :)
>
> I thought about doing that (though it _never_ occurred to me to use mseconds,
> since that feels to me like you abbreviated half of it, which is just weird to
> me). The problem is that that feels a bit too much like the inconsistent
> horror that is html where it accepts just about anything. I generally prefer
> things to be strict and consistent over trying to guess what was meant. It
> also makes the template constraints uglier. I'm not completely against the
> idea, but I'm not convinced that it's a good one either.

I'm not completely for it either, it was just a thought.  Personally, I think super-abbreviated and fully-spelled-out would be the two best options to have.  Since you are already sticking it in a namespace (dur), it should be rather obvious what each is:

hns or hectonanoseconds
us or microseconds
ms or milliseconds
s or seconds
m or minutes
h or hours
d or days
w or weeks
mo or months (yeah, this one is sucky)
y or years

>
> As it stands, all units seconds and greater are completely unabbreviated, and
> all of the sub-second units are abbreviated, which if you're going to
> abbreviate some but not all feels very consistent to me (though again, what
> seems perfectly logical to one person may not seem that way to another).

It would be good to highlight this pattern in the documentation.  It makes it easier to remember which ones are abbreviated!

> I
> _don't_ want to change them to something else at this point. There's enough in
> core.time and std.datetime to get used to already, and that's a pretty
> heavily-used feature in those modules. It _might_ be worth making it so that
> other variants of the units' names work, but I'm not convinced that being lax
> about it is necessarily a good idea.

To me, an optimal API is one you don't have to look up.  It just makes sense.  There are various ways to achieve this, and it's probably achievable with your scheme as long as you give an easy rule to remember (i.e. subseconds are abbreviated, everything else is not).

One thing that would be good to have is to have a more defined error message when you type the wrong term.  i.e.:

Error: millis is not a valid unit, try hnsecs, usecs, msecs, ...

-Steve

Jimmy Cao Wrote:

> 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();
> }

fwrite is from so called low-level file API supposed to write binary data without extra processing.

Steven Schveighoffer Wrote:

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

BTW, why it's not opDispatch?

On Fri, 24 Jun 2011 08:45:44 -0400, Kagamin <spam@here.lot> wrote:

> Jimmy Cao Wrote:
>
>> 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();
>> }
>
> fwrite is from so called low-level file API supposed to write binary data without extra processing.

As stated in a previous post, it does flush on newline in Linux (just tested it).  I don't know if flushing-on-newline-if-console is part of the C standard, so both implementations are likely compliant.  But it is an inconsistency.

-Steve

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.vxjw48ereav7ka@localhost.localdomain...
> On Thu, 23 Jun 2011 18:42:45 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
>> On 2011-06-23 15:10, Steven Schveighoffer wrote:
>>> 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.
>>
>> Unfortunately, there are so many variations on what they could be that there's
>> no way to make them so that everyone is going to remember them correctly. So,
>> no matter what I picked, someone would have been unhapy with it.
>
> Right.  I totally agree, if you have to have one, you just have to choose and be done with it.  The only reason we can have this conversation is because it's really easy to just add another "overload". :)
>
>>> But here's an idea -- milliseconds, msecs, and mseconds could all map to
>>> the same template function.
>>>
>>> hectonanoseconds, hm.. that's a long one :)
>>
>> I thought about doing that (though it _never_ occurred to me to use mseconds,
>> since that feels to me like you abbreviated half of it, which is just weird to
>> me). The problem is that that feels a bit too much like the inconsistent
>> horror that is html where it accepts just about anything. I generally prefer
>> things to be strict and consistent over trying to guess what was meant. It
>> also makes the template constraints uglier. I'm not completely against the
>> idea, but I'm not convinced that it's a good one either.
>
> I'm not completely for it either, it was just a thought.  Personally, I think super-abbreviated and fully-spelled-out would be the two best options to have.  Since you are already sticking it in a namespace (dur), it should be rather obvious what each is:
>
> hns or hectonanoseconds
> us or microseconds
> ms or milliseconds
> s or seconds
> m or minutes
> h or hours
> d or days
> w or weeks
> mo or months (yeah, this one is sucky)
> y or years
>
>>
>> As it stands, all units seconds and greater are completely unabbreviated, and
>> all of the sub-second units are abbreviated, which if you're going to
>> abbreviate some but not all feels very consistent to me (though again, what
>> seems perfectly logical to one person may not seem that way to another).
>
> It would be good to highlight this pattern in the documentation.  It makes it easier to remember which ones are abbreviated!
>
>> I
>> _don't_ want to change them to something else at this point. There's enough in
>> core.time and std.datetime to get used to already, and that's a pretty
>> heavily-used feature in those modules. It _might_ be worth making it so that
>> other variants of the units' names work, but I'm not convinced that being lax
>> about it is necessarily a good idea.
>
> To me, an optimal API is one you don't have to look up.  It just makes sense.  There are various ways to achieve this, and it's probably achievable with your scheme as long as you give an easy rule to remember (i.e. subseconds are abbreviated, everything else is not).
>
> One thing that would be good to have is to have a more defined error message when you type the wrong term.  i.e.:
>
> Error: millis is not a valid unit, try hnsecs, usecs, msecs, ...
>
> -Steve

Yeh. Use the SI prefixes for units of time, where applicable (and no unicode :-) )

-=mike=- 

On 2011-06-24 05:50, Kagamin wrote:
> Steven Schveighoffer Wrote:
> > But here's an idea -- milliseconds, msecs, and mseconds could all map to the same template function.
> 
> BTW, why it's not opDispatch?

It's not a function call. It's a template parameter to a variety of functions - some of which are not member functions (e.g. core.time.dur).

- Jonathan M Davis

On Fri, Jun 24, 2011 at 7:45 AM, Kagamin <spam@here.lot> wrote:

> Jimmy Cao Wrote:
>
> > 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();
> > }
>
> fwrite is from so called low-level file API supposed to write binary data without extra processing.
>

No, it writes to stdout which (in this case) is line-buffered.  Whenever there's a newline character, it is supposed to flush.

On 6/24/2011 9:41 AM, Jimmy Cao wrote:
> No, it writes to stdout which (in this case) is line-buffered.  Whenever there's
> a newline character, it is supposed to flush.

Please file a bug report!

http://bugzilla.digitalmars.com/issues/buglist.cgi?quicksearch=.