[D-runtime] druntime commit, revision 410

[Fawzi Mohamed]

well in blip I use libev for timings, and so I adopted ev_tstamp  
(which is basically a double) for most timeouts and timings.
I find that it works well...
The only other timing related thing that I used is
	https://github.com/fawzi/blip/blob/master/blip/time/RealtimeClock.d
for timings.

I find that this choice works well: most of the low level stuff on  
ev_tstamp (i.e. doubles), while keeping longs for performance and  
special timing purposes (RealtimeClock)

Fawzi
On 4-nov-10, at 22:38, Sean Kelly wrote:

> FWIW, core.time.Duration is basically a port of  
> boost::time_duration, but I've yet to implement the special values  
> (pos/neg infinity, not_a_date_time, etc).  The code is all new  
> according to the Boost docs, but I imagine I should probably credit  
> the Boost authors anyway.
>
> On Nov 4, 2010, at 12:51 PM, Steve Schveighoffer wrote:
>
>> Without looking at it at all, my firm belief is that std.datetime  
>> should use
>> core.time.Duration as its duration type.  One of the big issues I  
>> had with Tango
>> before implementing the time types was that you had 3 or 4  
>> different ways to
>> specify time.
>>
>> In all likelyhood you are going to be using std.datetime to do most  
>> of your code
>> since it provides mechanisms that work with the local clock.  If  
>> you then have
>> to convert your std.datetime structs to core.time structs in order  
>> to call core
>> functions, that's going to be a huge turnoff.
>>
>> In addition, std.datetime should publicly import core.time so it's  
>> seamless to
>> the person who wants to work with time structures.
>>
>> I know the datetime stuff is not final yet, but Jonathan, can we  
>> look at what
>> duration type should be moved to core.time?
>>
>> -Steve
>>
>>
>>
>> ----- Original Message ----
>>> From: Sean Kelly <sean at invisibleduck.org>
>>>
>>> Please let me know what you think about core.time.  My only worry  
>>> is about  the
>>> potential overlap with std.datetime, but it's hard to do without  
>>> any  structured
>>> time representation in druntime.  Should any attempt be made to   
>>> have the
>>> duration type in std.datetime be compatible with this? should the  
>>> names  be made
>>> different so there are no collisions in user code? etc?
>>>
>>> On Nov 4,  2010, at 12:09 PM, dsource.org wrote:
>>>
>>>> druntime commit, revision 410
>>>>
>>>>
>>>> user:  sean
>>>>
>>>> msg:
>>>> Added core.time, which has a Duration type  used to communicate  
>>>> time periods
>>> to relevant routines in druntime.  Right  now, Thread.sleep() is  
>>> the only method
>>> that accepts a Duration, but the routines  in core.sync will be  
>>> modified to do
>>> so as well if core.time passes  muster.
>>>>
>>>> http://www.dsource.org/projects/druntime/changeset/410
>>>>
>>>> _______________________________________________
>>>> D-runtime mailing  list
>>>> D-runtime at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>>>
>>> _______________________________________________
>>> D-runtime  mailing list
>>> D-runtime at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>>>
>>
>>
>>
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime