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

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

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
> 

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

On Thursday, November 04, 2010 12:51:36 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?

I'll take a look at it, but I do know that it won't be possible to directly move std.datetime's Duration over to core.time, because it does have some code which interacts with other stuff in std.datetime like TickDuration and FracSec, as well as using some helper functions which are in std.datetime (as well as my unittesting functions of course). However, some or all of that could be moved to core.time or duplicated there. I'll have to see what core.time looks like though. I definitely didn't just port over Boost's duration API, though IIRC it's certainly similar.

- Jonathan M Davis

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

by the way I almost forgot for timings and co you want to use the
monotonic time...
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

On Thursday 04 November 2010 12:51:36 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?

Looking at core.time, I'd really suggest just moving over std.datetime.Duration to core.time along with TickDuration, FracSec, and the dur!() function for creating Durations, possibly along with some of the helper functions (which I believe are primarily restricted to template constraints). Most of the unit tests would have to be made to not use my nice unit test functions, so the unit tests would become a bit nastier, and some of the unit tests would probably have to be left in std.datetime, since they rely on Clock.currSystemTick() (or it could be removed from Clock, though I'd prefer not), but it can be done.

In any case, with some alterations, I think that std.datetime.Duration and the other pieces of std.datetime that it relies on can be moved into core.time fairly easily. I really think that on the whole, std.datetime.Duration is superior to core.time.Duration, so I definitely don't want to replace std.datetime's Duration with core.time's Duration.

I can spend some time to create a version which could replace what's currently in core.time, and then std.datetime can publicly import core.time as Steve suggests.

- Jonathan M Davis

On 11/4/2010 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

I haven't been following the thread about time stuff today, but this change seems to have broken the win32 build:

from: http://d.puremagic.com/test-results/test_data.ghtml?dataid=16814

src\core\thread.d(1099): Error: 'val' is not a scalar, it is a Duration
src\core\thread.d(1099): Error: 'val' is not of arithmetic type, it is a Duration


Sorry for the overall horkage of the tester today, comcast was giving me > 50% packet loss for the majority of the day.  Enough that essentially nothing works.

Later,
Brad

On Nov 4, 2010, at 8:24 PM, Brad Roberts wrote:

> On 11/4/2010 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
> 
> I haven't been following the thread about time stuff today, but this change seems to have broken the win32 build:
> 
> from: http://d.puremagic.com/test-results/test_data.ghtml?dataid=16814
> 
> src\core\thread.d(1099): Error: 'val' is not a scalar, it is a Duration
> src\core\thread.d(1099): Error: 'val' is not of arithmetic type, it is a Duration

Crapola.  Thanks for the report.  I'll fix it shortly.