The simplest way I found is: TickDuration.from!"hnsecs"(duration.total!"hnsecs")

Is there a simpler way?

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On Tuesday, September 13, 2011 04:32:28 Vladimir Panteleev wrote:
> The simplest way I found is:
> TickDuration.from!"hnsecs"(duration.total!"hnsecs")
> 
> Is there a simpler way?

I don't believe so. A TickDuration can be cast (or use std.conv.to) to convert to a Duration, but there is no cast in the opposite direction. One could be added (and perhaps it should be), but I do find it a bit odd to convert from Duration to TickDuration. Usually, you'd get a TickDuration from timing stuff (like benchmarking or some other type of stopwatch functionality), and I would expect creating TickDurations in other ways to be fairly rare. What are you doing that you want to create a TickDuration from a Duration?

- Jonathan M Davis

On Tue, 13 Sep 2011 05:01:31 +0300, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> What are you doing that you want to create a TickDuration from a Duration?

On the one side, I have a module for running scheduled events. Event timing is specified using a TickDuration, indicating the time interval after which to run the event.

On the other side, I have an application which replays an event log from a file. Events are timestamped in stdTime format, and are stored in SysTime instances. Subtracting one SysTime instance from another returns a Duration.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On Tuesday, September 13, 2011 05:13:02 Vladimir Panteleev wrote:
> On Tue, 13 Sep 2011 05:01:31 +0300, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > What are you doing that you want to create a TickDuration from a Duration?
> 
> On the one side, I have a module for running scheduled events. Event timing is specified using a TickDuration, indicating the time interval after which to run the event.
> 
> On the other side, I have an application which replays an event log from a file. Events are timestamped in stdTime format, and are stored in SysTime instances. Subtracting one SysTime instance from another returns a Duration.

Personally, I'd just Duration far those and not TickDuration. Duration is just as precise (if not more precise) than TickDuration as long as the system ticks aren't less than 1 hnsec apart. TickDuration is useful in that it gives you timing in clock ticks if you need it (e.g. if the system clocks ticks were faster than 1 ever 1 hnsecs), but in the general case, it doesn't buy you anything over Duration, and I don't see why it would in your case either. Maybe something in how you're doing events?

- Jonathan M Davis

On Tue, 13 Sep 2011 06:27:44 +0300, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> Personally, I'd just Duration far those and not TickDuration. Duration is just
> as precise (if not more precise) than TickDuration as long as the system ticks
> aren't less than 1 hnsec apart. TickDuration is useful in that it gives you
> timing in clock ticks if you need it (e.g. if the system clocks ticks were
> faster than 1 ever 1 hnsecs), but in the general case, it doesn't buy you
> anything over Duration, and I don't see why it would in your case either.
> Maybe something in how you're doing events?

Well, TickDuration.currSystemTick() returns a TickDuration, so I went with that all across. I'll be needing to do some conversions at one point or another, though optimally it'd happen when creating events, and not when processing them, as that would have less total overhead.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On Tuesday, September 13, 2011 15:45:27 Vladimir Panteleev wrote:
> On Tue, 13 Sep 2011 06:27:44 +0300, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > Personally, I'd just Duration far those and not TickDuration. Duration
> > is just
> > as precise (if not more precise) than TickDuration as long as the system
> > ticks
> > aren't less than 1 hnsec apart. TickDuration is useful in that it gives
> > you
> > timing in clock ticks if you need it (e.g. if the system clocks ticks
> > were
> > faster than 1 ever 1 hnsecs), but in the general case, it doesn't buy
> > you
> > anything over Duration, and I don't see why it would in your case
> > either.
> > Maybe something in how you're doing events?
> 
> Well, TickDuration.currSystemTick() returns a TickDuration, so I went with that all across. I'll be needing to do some conversions at one point or another, though optimally it'd happen when creating events, and not when processing them, as that would have less total overhead.

That makes some sense. The cast probably should be added to Duration anyway, even if the need is somewhat of an abnormality. And maybe such conversions will end up being more common than I would have thought anyway.

- Jonathan M Davis

On Tuesday, September 13, 2011 04:32:28 Vladimir Panteleev wrote:
> The simplest way I found is:
> TickDuration.from!"hnsecs"(duration.total!"hnsecs")
> 
> Is there a simpler way?

There's now a pull request which adds opCast to Duration which casts to TickDuration: https://github.com/D-Programming-Language/druntime/pull/73

- Jonathan M Davis