Alex <AJ gmail.com> writes:

1 - 17 ms, 553 ╬╝s, and 1 hnsec

WTH!! is there any way to just get a normal u rather than some 
fancy useless asci hieroglyphic? Why don't we have a fancy M? and 
an h?

What's an hnsec anyways?

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote:
 1 - 17 ms, 553 ╬╝s, and 1 hnsec

 WTH!! is there any way to just get a normal u rather than some 
 fancy useless asci hieroglyphic? Why don't we have a fancy M? 
 and an h?

It's outputting UTF-8, but, your console is not configured to 
display UTF-8.

On Windows, you can do so (before running your program), by 
running: chcp 65001

Or, within your program, by calling: SetConsoleOutputCP(CP_UTF8);

Note that this has some negative side effects, which is why D 
doesn't do it automatically. (Blame Windows.)

 What's an hnsec anyways?

Hecto-nano-second, the smallest representable unit of time in 
SysTime and Duration.

Steven Schveighoffer <schveiguy gmail.com> writes:

On 5/16/19 4:27 PM, Vladimir Panteleev wrote:
 On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote:

 What's an hnsec anyways?

 
 Hecto-nano-second, the smallest representable unit of time in SysTime 
 and Duration.

The output shouldn't involve the inner workings of the type. It should 
be changed to say 10 ns.

-Steve

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

On Thursday, 16 May 2019 at 15:52:05 UTC, Steven Schveighoffer 
wrote:
 Hecto-nano-second, the smallest representable unit of time in 
 SysTime and Duration.

 The output shouldn't involve the inner workings of the type. It 
 should be changed to say 10 ns.

If the output is meant for the developer, then I disagree 
subjectively, as that creates the impression that the lowest 
resolution or representable unit of time is the nanosecond.

If the output is meant for the user, then hectonanoseconds or 
nanoseconds are going to be almost always irrelevant. The 
duration should be formatted appropriately to the use case.

Steven Schveighoffer <schveiguy gmail.com> writes:

On 5/16/19 4:55 PM, Vladimir Panteleev wrote:
 On Thursday, 16 May 2019 at 15:52:05 UTC, Steven Schveighoffer wrote:
 Hecto-nano-second, the smallest representable unit of time in SysTime 
 and Duration.

 The output shouldn't involve the inner workings of the type. It should 
 be changed to say 10 ns.

 
 If the output is meant for the developer, then I disagree subjectively, 
 as that creates the impression that the lowest resolution or 
 representable unit of time is the nanosecond.

It is what it is. The reason hnsecs is used instead of nsecs is because 
it gives a time range of 20,000 years instead of 2,000 years.

We do have a nanosecond resolution, and it's just rounded down to the 
nearest 10.

For example:

     auto d = 15.nsecs;
     assert(d == 10.nsecs);

You shouldn't be relying on what a string says to know what the tick 
resolution is.

For example, if I do writefln("%f", 1.0), I get 1.000000. That doesn't 
mean I should assume floating point precision only goes down to 1/1_000_000.

hnsecs is more confusing than nanoseconds. People know what a nanosecond 
is, a hecto-nano-second is not as familiar a term.

 If the output is meant for the user, then hectonanoseconds or 
 nanoseconds are going to be almost always irrelevant. The duration 
 should be formatted appropriately to the use case.

Depends on the user and the application.

-Steve

Steven Schveighoffer <schveiguy gmail.com> writes:

On 5/16/19 9:17 PM, Steven Schveighoffer wrote:
 On 5/16/19 4:55 PM, Vladimir Panteleev wrote:
 If the output is meant for the developer, then I disagree 
 subjectively, as that creates the impression that the lowest 
 resolution or representable unit of time is the nanosecond.

 
 It is what it is. The reason hnsecs is used instead of nsecs is because 
 it gives a time range of 20,000 years instead of 2,000 years.
 
 We do have a nanosecond resolution, and it's just rounded down to the 
 nearest 10.

And to prove my point about it being an obscure term, I forgot it's not 
10 nanoseconds, but 100 nanoseconds. oops!

 
 For example:
 
      auto d = 15.nsecs;
      assert(d == 10.nsecs);

This is not what I was trying to say, even though it's true (both are 
Duration.zero).

I meant:

auto d = 150.nsecs;
assert(d == 100.nsecs);

-Steve

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer 
wrote:
 We do have a nanosecond resolution, and it's just rounded down 
 to the nearest 10.

 For example:

     auto d = 15.nsecs;
     assert(d == 10.nsecs);

I'm not sure how to feel about this. Maybe there was a better way 
to handle nanoseconds here.

 You shouldn't be relying on what a string says to know what the 
 tick resolution is.

I don't like that with your proposal, it seems to add data that's 
not there. The 0 is entirely fictional. It might as well be part 
of the format string.

 For example, if I do writefln("%f", 1.0), I get 1.000000.

%f is a C-ism, %s does not do that.

 hnsecs is more confusing than nanoseconds. People know what a 
 nanosecond is, a hecto-nano-second is not as familiar a term.

Agreed, which is why Duration.toString shouldn't be used to 
present durations to users.

Developers, however, are expected to know what a hectonanosecond 
is, same as with all the other technical terms.

 If the output is meant for the user, then hectonanoseconds or 
 nanoseconds are going to be almost always irrelevant. The 
 duration should be formatted appropriately to the use case.

 Depends on the user and the application.

If the durations are so small or so precise that it makes sense 
to display them with such precision, then yes, applications would 
do better to use nanoseconds instead of hectonanoseconds.

kdevel <kdevel vogtner.de> writes:

On Thursday, 16 May 2019 at 20:31:23 UTC, Vladimir Panteleev 
wrote:
 On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer

[...]

 hnsecs is more confusing than nanoseconds. People know what a 
 nanosecond is, a hecto-nano-second is not as familiar a term.

 Agreed, which is why Duration.toString shouldn't be used to 
 present durations to users.

 Developers, however, are expected to know what a 
 hectonanosecond is, same as with all the other technical terms.

"hectonanosecond" looks like an illegal combination of SI 
prefixes [1]. I recommend changing the meaning of hnsecs to 
"[one] hundred nanoseconds".

[1] "Prefixes may not be used in combination."
     https://en.wikipedia.org/wiki/Metric_prefix

Alex <AJ gmail.com> writes:

On Friday, 17 May 2019 at 18:02:04 UTC, kdevel wrote:
 On Thursday, 16 May 2019 at 20:31:23 UTC, Vladimir Panteleev 
 wrote:
 On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer

 [...]

 hnsecs is more confusing than nanoseconds. People know what a 
 nanosecond is, a hecto-nano-second is not as familiar a term.

 Agreed, which is why Duration.toString shouldn't be used to 
 present durations to users.

 Developers, however, are expected to know what a 
 hectonanosecond is, same as with all the other technical terms.

 "hectonanosecond" looks like an illegal combination of SI 
 prefixes [1]. I recommend changing the meaning of hnsecs to 
 "[one] hundred nanoseconds".

 [1] "Prefixes may not be used in combination."
     https://en.wikipedia.org/wiki/Metric_prefix

It through me off, it really  makes no sense. The purpose of a 
prefix is to define something better. hectonano seems 
contradictory... and is it any different than nanohecto?

There really is no point in it, the whole reason for the metric 
system is to provide a hierarchical resolution. Just use nano or 
pico....

Daniel =?UTF-8?B?S296w6Fr?= <kozzi11 gmail.com> writes:

On Friday, 17 May 2019 at 18:02:04 UTC, kdevel wrote:
 On Thursday, 16 May 2019 at 20:31:23 UTC, Vladimir Panteleev 
 wrote:
 On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer

 [...]

 hnsecs is more confusing than nanoseconds. People know what a 
 nanosecond is, a hecto-nano-second is not as familiar a term.

 Agreed, which is why Duration.toString shouldn't be used to 
 present durations to users.

 Developers, however, are expected to know what a 
 hectonanosecond is, same as with all the other technical terms.

 "hectonanosecond" looks like an illegal combination of SI 
 prefixes [1]. I recommend changing the meaning of hnsecs to 
 "[one] hundred nanoseconds".

 [1] "Prefixes may not be used in combination."
     https://en.wikipedia.org/wiki/Metric_prefix

Exactly it really does not exist. Just try to search it on net. 
No one know what is it. Only few people from D world use it. 
Every time I need to work with D and time it takes hours to find 
out what hnsecs is.

ag0aep6g <anonymous example.com> writes:

On 16.05.19 17:55, Vladimir Panteleev wrote:
 On Thursday, 16 May 2019 at 15:52:05 UTC, Steven Schveighoffer wrote:

[...]
 The output shouldn't involve the inner workings of the type. It should 
 be changed to say 10 ns.

 
 If the output is meant for the developer, then I disagree subjectively, 
 as that creates the impression that the lowest resolution or 
 representable unit of time is the nanosecond.
 
 If the output is meant for the user, then hectonanoseconds or 
 nanoseconds are going to be almost always irrelevant. The duration 
 should be formatted appropriately to the use case.
 

I'd suggest "17 ms, and 553.1µs" for a better default (1 hns is 0.1 µs, 
right?). No weird "hnsecs", no false precision, still all the data that 
is there.

Bastiaan Veelo <Bastiaan Veelo.net> writes:

On Friday, 17 May 2019 at 18:36:00 UTC, ag0aep6g wrote:
 I'd suggest "17 ms, and 553.1µs" for a better default (1 hns is 
 0.1 µs, right?). No weird "hnsecs", no false precision, still 
 all the data that is there.

I was going to propose the same. Hns is weird.

Bastiaan.

kdevel <kdevel vogtner.de> writes:

On Friday, 17 May 2019 at 20:30:56 UTC, Bastiaan Veelo wrote:
 On Friday, 17 May 2019 at 18:36:00 UTC, ag0aep6g wrote:
 I'd suggest "17 ms, and 553.1µs" for a better default (1 hns 
 is 0.1 µs, right?). No weird "hnsecs", no false precision, 
 still all the data that is there.

 I was going to propose the same. Hns is weird.

Why not simply 17.5531 ms ("%.4f ms") to get rid of the non-ASCII 
µ prefix?

Adam D. Ruppe <destructionator gmail.com> writes:

On Saturday, 18 May 2019 at 00:17:20 UTC, kdevel wrote:
 Why not simply 17.5531 ms ("%.4f ms") to get rid of the 
 non-ASCII µ prefix?

fwiw I like this solution for the output. It is very clear to me.

KnightMare <black80 bk.ru> writes:

 Why not simply 17.5531 ms ("%.4f ms") to get rid of the 
 non-ASCII µ prefix?

 fwiw I like this solution for the output. It is very clear to 
 me.

+1
and without space 17.5531ms

wjoe <invalid example.com> writes:

On Thursday, 16 May 2019 at 15:52:05 UTC, Steven Schveighoffer 
wrote:
 On 5/16/19 4:27 PM, Vladimir Panteleev wrote:
 On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote:

 What's an hnsec anyways?

 
 Hecto-nano-second, the smallest representable unit of time in 
 SysTime and Duration.

 The output shouldn't involve the inner workings of the type. It 
 should be changed to say 10 ns.

 -Steve

It's 100ns. 10ns = 1dans = 1 deka-nano-second.
deka = 10, hecto = 100 [1]

[1] 
https://www.nist.gov/pml/weights-and-measures/metric-si-prefixes

Alex <AJ gmail.com> writes:

On Thursday, 16 May 2019 at 15:27:33 UTC, Vladimir Panteleev 
wrote:
 On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote:
 1 - 17 ms, 553 ╬╝s, and 1 hnsec

 WTH!! is there any way to just get a normal u rather than some 
 fancy useless asci hieroglyphic? Why don't we have a fancy M? 
 and an h?

 It's outputting UTF-8, but, your console is not configured to 
 display UTF-8.

 On Windows, you can do so (before running your program), by 
 running: chcp 65001

 Or, within your program, by calling: 
 SetConsoleOutputCP(CP_UTF8);

 Note that this has some negative side effects, which is why D 
 doesn't do it automatically. (Blame Windows.)

 What's an hnsec anyways?

 Hecto-nano-second, the smallest representable unit of time in 
 SysTime and Duration.

Thanks...

Why not just use u? If that is too much trouble then detect the 
code page and use u rather than the extended ascii which looks 
very out of place?

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

On Thursday, 16 May 2019 at 16:49:35 UTC, Alex wrote:
 Why not just use u?

It generally works fine on all the other filesystems, which today 
have mostly standardized on UTF-8.

 If that is too much trouble then detect the code page and use u 
 rather than the extended ascii which looks very out of place?

Well, a more correct solution would be to check if we're printing 
to the Windows console, and  use Unicode APIs, which would allow 
this to work regardless of the current 8-bit codepage. However, 
this (and your suggestion) are complicated to implement due to 
reasons related to how tightly Phobos is tied to C's FILE* for 
file input and output.

Vladimir Panteleev <thecybershadow.lists gmail.com> writes:

On Thursday, 16 May 2019 at 16:52:22 UTC, Vladimir Panteleev 
wrote:
 On Thursday, 16 May 2019 at 16:49:35 UTC, Alex wrote:
 Why not just use u?

 It generally works fine on all the other filesystems

* operating systems

evilrat <evilrat666 gmail.com> writes:

On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote:
 1 - 17 ms, 553 ╬╝s, and 1 hnsec

 fancy useless asci hieroglyphic

Holy shirt!
All that time I was thinking this is just some sort of encoding 
artifacts in terminal(common problem on windows), especially 
because IIRC on Linux it is displaying this greek 'micro' 
correctly.

This is completely out of context, and so should be replaced with 
something more conventional...

Now when I realize it, for me it immediately start look like some 
sort of cave art or graffiti in art gallery, very unprofessional 
I say.

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote:
 1 - 17 ms, 553 ╬╝s, and 1 hnsec

That's µs* for micro-seconds.

* hurrah for French keyboard which has a rarely used µ key, but 
none for Ç a frequent character of the language.

 WTH!! is there any way to just get a normal u rather than some 
 fancy useless asci hieroglyphic? Why don't we have a fancy M? 
 and an h?

 What's an hnsec anyways?

Les De Ridder <les lesderid.net> writes:

On Saturday, 18 May 2019 at 20:34:33 UTC, Patrick Schluter wrote:
 * hurrah for French keyboard which has a rarely used µ key, but 
 none for Ç a frequent character of the language.

<Caps Lock><key marked with '9' on the number row><Caps Lock>

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

On Saturday, 18 May 2019 at 21:05:13 UTC, Les De Ridder wrote:
 On Saturday, 18 May 2019 at 20:34:33 UTC, Patrick Schluter 
 wrote:
 * hurrah for French keyboard which has a rarely used µ key, 
 but none for Ç a frequent character of the language.

 <Caps Lock><key marked with '9' on the number row><Caps Lock>

That's the lowercase ç. The uppercase Ç is not directly 
composable, annoying or to say it in French to illsutrate: "Ça 
fait chier". I use Alt+1+2+8 on Windows, but most people do not 
know these ancient OEM-437 based character codes going back to 
the orignal IBM-PC. The newer ANSI based Alt+0+1+9+9 is one 
keypress longer and I would have to learn actually the code.

There are 2 other characters that are not available on the french 
keyboard: œ and Œ. Quite annoying if you sell beef (bœuf) and 
eggs (œufs) in the towns of Œutrange or Œting.

Les De Ridder <les lesderid.net> writes:

On Sunday, 19 May 2019 at 12:24:28 UTC, Patrick Schluter wrote:
 On Saturday, 18 May 2019 at 21:05:13 UTC, Les De Ridder wrote:
 On Saturday, 18 May 2019 at 20:34:33 UTC, Patrick Schluter 
 wrote:
 * hurrah for French keyboard which has a rarely used µ key, 
 but none for Ç a frequent character of the language.

 <Caps Lock><key marked with '9' on the number row><Caps Lock>

 That's the lowercase ç. The uppercase Ç is not directly 
 composable,

No, note that I said <Caps Lock> and not <Shift>. Using <Caps 
Lock> it
outputs a 'Ç' for me (at least on X11 with the French layout).

 There are 2 other characters that are not available on the 
 french keyboard: œ and Œ. Quite annoying if you sell beef 
 (bœuf) and eggs (œufs) in the towns of Œutrange or Œting.

It seems those are indeed not on the French layout at all. Might I
suggest using the Belgian layout? It is AZERTY too and has both 
'œ'
and 'Œ'.

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

On Tuesday, 21 May 2019 at 02:12:10 UTC, Les De Ridder wrote:
 On Sunday, 19 May 2019 at 12:24:28 UTC, Patrick Schluter wrote:
 On Saturday, 18 May 2019 at 21:05:13 UTC, Les De Ridder wrote:
 On Saturday, 18 May 2019 at 20:34:33 UTC, Patrick Schluter 
 wrote:
 * hurrah for French keyboard which has a rarely used µ key, 
 but none for Ç a frequent character of the language.

 <Caps Lock><key marked with '9' on the number row><Caps Lock>

 That's the lowercase ç. The uppercase Ç is not directly 
 composable,

 No, note that I said <Caps Lock> and not <Shift>. Using <Caps 
 Lock> it
 outputs a 'Ç' for me (at least on X11 with the French layout).

Does not work on Windows. <Caps lock> and it gives 9. I tested 
also on my Linux Mint box and it output lowercase ç with <Caps 
lock>.

 There are 2 other characters that are not available on the 
 french keyboard: œ and Œ. Quite annoying if you sell beef 
 (bœuf) and eggs (œufs) in the towns of Œutrange or Œting.

 It seems those are indeed not on the French layout at all. 
 Might I
 suggest using the Belgian layout? It is AZERTY too and has both 
 'œ'
 and 'Œ'.

No, it hasn't.
I indeed prefer the Belgian keyboard. It has more composable 
deadkey characters accents, tildas. Brackets [{]} and other 
programming characters < > | etc, are better placed than on the 
French keyboard.
Btw æ and Æ are missing also, but there it's not very important 
as there are really only very few words in French that use them 
ex-æquo, curriculum vitæ, et cætera