On Aug 22, 2013, at 3:37 PM, Tanaka Akira wrote:

> Process.clock_getres can return rational if it supports
> :rational_second as a unit.
>=20
> The current default of unit is :float_second and
> I think float is good enough.

Agreed.  Plus, if someone really wants, they can request nanosecond =
precision, which is all that clock_getres supports (at least on Linux).

>=20
>>> Process.clock_getres(:SUS_GETRUSAGE_BASED_CLOCK_PROCESS_CPUTIME_ID, =
:hertz) #=3D> 1000000.0
>>=20
>> How would you feel about supporting :ns and :hz as equivalents for =
:nanosecond and :hertz?
>=20
> It is difficult to support :microsecond in that style
> because the SI prefix, Greek m, is not representable in ASCII.

I know it's not SI, but I often use ASCII "u" for Greek m ("=B5"), so =
:microsecond would be aliased by :us.

> Someone may argue :hz should be :Hz.

No doubt! :-)

> I feel :float_s is bit curious.

How about separating the type and the resolution into two different =
parameters?

    Process.clock_getres(Process::CLOCK_MONOTONIC, :float, :second)

...or...

    Process.clock_getres(Process::CLOCK_MONOTONIC, Float, :second)

> So it is difficult to adopt :ns style as canonical style of unit.
>=20
> I think several aliases are possible but
> I'd like to concentrate to main feature.
> The discussion for what aliases should be added or not can be diverge.

Agreed.  I think the main feature is great!

>=20
>>> Note that
>>> Process.clock_getres(:POSIX_TIMES_BASED_CLOCK_PROCESS_CPUTIME_ID, =
:hertz) is the clock ticks per second (CLK_TCK) and
>>> Process.clock_getres(:ISO_C_CLOCK_BASED_CLOCK_PROCESS_CPUTIME_ID, =
:hertz) is CLOCK_PER_SEC.
>>> I wanted to access them easily to investigate emulated clock =
behaviors on
>>> various OSes.
>>=20
>> Those are some long symbols!  Are these intended only for =
experimental/investigative use?
>=20
> I choose the long symbols that is longer than =
Process::CLOCK_PROCESS_CPUTIME_ID.
> Basically users should use Process::CLOCK_PROCESS_CPUTIME_ID if no =
reason.

Sounds good.

Dave