On Thursday 18 November 2010 03:35:49 Kagamin wrote:
> Jonathan M Davis Wrote:
> > If you have a better way to do it, I'm all ears. However, it's the only
> > way that I know of to get high-precision time on Windows.
>
> Use GetSystemTime. At least, it will be correct.
Actually, looking at TickDu
Jonathan M Davis Wrote:
> If you have a better way to do it, I'm all ears. However, it's the only way
> that
> I know of to get high-precision time on Windows.
Use GetSystemTime. At least, it will be correct.
On Wednesday 17 November 2010 21:51:24 Kagamin wrote:
> Jonathan M Davis Wrote:
> > I'd have to study up on it to see whether there are any real problems
> > with it.
>
> Speaking in posix terms, performance counter is more like CLOCK_MONOTONIC
> and using it as CLOCK_REALTIME is a dependency on u
On Wednesday 17 November 2010 21:57:58 Steve Teale wrote:
> It's difficult to find a suitable entry point in this thread, so I'll just
> arbitrarily use here.
>
> Various language libraries have flexible facilities for formatting
> date/time values, maybe c#, and certainly PHP, whereby you can spe
It's difficult to find a suitable entry point in this thread, so I'll just
arbitrarily use here.
Various language libraries have flexible facilities for formatting date/time
values, maybe c#, and certainly PHP, whereby you can specify a format string,
something like "%d'th %M %Y".
Is this a us
Jonathan M Davis Wrote:
> I'd have to study up on it to see whether there are any real problems with it.
Speaking in posix terms, performance counter is more like CLOCK_MONOTONIC and
using it as CLOCK_REALTIME is a dependency on undefined behavior.
On Wednesday 17 November 2010 16:09:22 Todd VanderVeen wrote:
> The article was written in 2004. A high precision event timer has been
> incorporated in chipsets since 2005.
>
> http://en.wikipedia.org/wiki/High_Precision_Event_Timer
>
> I hope were not basing decisions on support for NT4.0 :)
I
The article was written in 2004. A high precision event timer has been
incorporated in chipsets since 2005.
http://en.wikipedia.org/wiki/High_Precision_Event_Timer
I hope were not basing decisions on support for NT4.0 :)
== Quote from Kagamin (s...@here.lot)'s article
> Jonathan M Davis Wrote:
On Wednesday, November 17, 2010 13:44:32 Kagamin wrote:
> Jonathan M Davis Wrote:
> > Latest: http://is.gd/gSwDv
>
> You use QueryPerformanceCounter.
> Is this code tested on Windows? MSDN doesn't specify what
> QueryPerformanceCounter returns. see
> http://msdn.microsoft.com/en-us/magazine/cc1639
Jonathan M Davis Wrote:
> Latest: http://is.gd/gSwDv
>
You use QueryPerformanceCounter.
Is this code tested on Windows? MSDN doesn't specify what
QueryPerformanceCounter returns.
see http://msdn.microsoft.com/en-us/magazine/cc163996.aspx
On Sunday 14 November 2010 02:31:00 Dmitry Olshansky wrote:
> On 14.11.2010 7:47, Jonathan M Davis wrote:
> So bi-directionality is one of places where generator-on-previous-date
> approach is failing.
> I see that with current API the user need to be aware which delegate use
> when:
> auto func =
On 14.11.2010 7:47, Jonathan M Davis wrote:
On Thursday 11 November 2010 13:42:37 Dmitry Olshansky wrote:
I'm afraid that I don't really get what you're trying to do here. A range
needs to be created from an interval. It really wouldn't make sense to
do it otherwise. And when you create a range,
On Thursday 11 November 2010 13:42:37 Dmitry Olshansky wrote:
> > I'm afraid that I don't really get what you're trying to do here. A range
> > needs to be created from an interval. It really wouldn't make sense to
> > do it otherwise. And when you create a range, it needs a delegate which
> > gene
Jonathan M Davis napisał:
> On Thursday, November 11, 2010 16:31:56 Tomek Sowiński wrote:
> That would require you to be able to have unary +. I didn't think that
> that was legal. Upon checking it out though, it looks like it is. I don't
> really have any problem with the way that I did it, but I
On Thursday, November 11, 2010 16:31:56 Tomek Sowiński wrote:
> Jonathan M Davis napisał:
> > I don't see any real benefit in splitting a function into two overloads
> > rather than using static ifs in this manner. The resulting source code is
> > likely nearly identical. You only end up with one f
Jonathan M Davis napisał:
> On Wednesday, November 10, 2010 15:03:11 Tomek Sowiński wrote:
>> Jonathan M Davis napisał:
>> > Latest: http://is.gd/gSwDv
>>
>> My 2 cents:
>>
>> Units of time are represented more naturally by an integer enum (could be
>> anonymous) than a string.
>>
>> A problem
On 11.11.2010 8:55, Jonathan M Davis wrote:
On Wednesday 10 November 2010 10:18:27 Dmitry Olshansky wrote:
OK, I looked through the docs, to me it's very solid. I fact I never
written any code that heavily uses date-time stuff, most of the time I
just converted everything to UNIX timestamp, and
On Wednesday 10 November 2010 10:18:27 Dmitry Olshansky wrote:
> OK, I looked through the docs, to me it's very solid. I fact I never
> written any code that heavily uses date-time stuff, most of the time I
> just converted everything to UNIX timestamp, and back to printable form,
> once the proces
On Wednesday, November 10, 2010 15:03:11 Tomek Sowiński wrote:
> Jonathan M Davis napisał:
> > Latest: http://is.gd/gSwDv
>
> My 2 cents:
>
> Units of time are represented more naturally by an integer enum (could be
> anonymous) than a string.
>
> A problem recurring in many methods:
>
> /+
Jonathan M Davis napisał:
> Latest: http://is.gd/gSwDv
My 2 cents:
Units of time are represented more naturally by an integer enum (could be
anonymous) than a string.
A problem recurring in many methods:
/+ref+/ Date opOpAssign(string op, D)(in D duration) nothrow
if((op == "+" ||
On 10.11.2010 4:52, Jonathan M Davis wrote:
On Tuesday, November 09, 2010 17:34:15 Jonathan M Davis wrote:
On Tuesday, November 09, 2010 16:23:56 Yao G. wrote:
On Tue, 09 Nov 2010 18:11:59 -0600, Jonathan M Davis
wrote:
I think that the real question here is how good the API is.
I think tha
Steven Schveighoffer:
> Well, I'm not certain that this is the reason, but calendars are riddled
> with corner cases. I would expect a well-tested date/time library to test
> all those corner cases.
I have never suggested to remove unit tests. But in several languages and
projects there is
On Tue, 09 Nov 2010 18:48:30 -0500, bearophile
wrote:
Yao G.:
Ugh. The datetime.d file is 1.5 MB? 0_o
So it will be very well tested :) Look, the huge benefit of unit tests
are that they are inline with the code. Either you want that or you want
small files, I don't understand the e
On Tuesday 09 November 2010 17:45:51 Yao G. wrote:
> On Tue, 09 Nov 2010 19:34:15 -0600, Jonathan M Davis
>
> wrote:
> > That's quite understandable, but that's part of the reason that the ddoc
> > html files are there.
>
> Yes, but I also wanted to look at the implementation.
>
> > You don't a
On Tuesday, November 09, 2010 17:34:15 Jonathan M Davis wrote:
> On Tuesday, November 09, 2010 16:23:56 Yao G. wrote:
> > On Tue, 09 Nov 2010 18:11:59 -0600, Jonathan M Davis
> >
> >
> > wrote:
> > > I think that the real question here is how good the API is.
> >
> > I think that the sheer size
On Tue, 09 Nov 2010 19:34:15 -0600, Jonathan M Davis
wrote:
That's quite understandable, but that's part of the reason that the ddoc
html files are there.
Yes, but I also wanted to look at the implementation.
You don't actually have to go trolling through the code to look at the
API.
On Tuesday, November 09, 2010 16:42:32 bearophile wrote:
> > An option may be to modify the compiler so it allows to override
> > protection in code contained inside unittest{...}.
>
> Another option is to modify the compiler so it sees unittests modules as
> part of another module (using a mixin(
On Tuesday, November 09, 2010 16:23:56 Yao G. wrote:
> On Tue, 09 Nov 2010 18:11:59 -0600, Jonathan M Davis
>
> wrote:
> > I think that the real question here is how good the API is.
>
> I think that the sheer size of the library, specially with a datetime.d
> file with almost 31,600 lines of co
> An option may be to modify the compiler so it allows to override protection
> in code contained inside unittest{...}.
Another option is to modify the compiler so it sees unittests modules as part
of another module (using a mixin() on a string import is too much hacky).
Bye,
bearophile
Jonathan M Davis:
> While there seem to be a lot of tests, they've turned out to be _really_
> helpful
> and by their very nature, they _need_ to be repetitive.
Repetitive doesn't mean it has to take lot of space. Tests are a cross between
code and documentation, and both are better not too mu
On Tue, 09 Nov 2010 18:11:59 -0600, Jonathan M Davis
wrote:
I think that the real question here is how good the API is.
I think that the sheer size of the library, specially with a datetime.d
file with almost 31,600 lines of code (granted, most of them are unit test
and documentation),
On Tuesday, November 09, 2010 15:48:30 bearophile wrote:
> Yao G.:
> > Ugh. The datetime.d file is 1.5 MB? 0_o
Heavy unit testing and documenting everything adds up. The implementation isn't
all that small either, but it's the unit tests and ddoc comments which really
increase the size. Most of
Yao G.:
> Ugh. The datetime.d file is 1.5 MB? 0_o
It contains too-much-repetitive code like:
assertEqual(SysTime(DateTime(2010, 8, 1, 23, 59, 59),
FracSec.from!"msecs"(999)).dayOfGregorianCal, 733_985);
assertEqual(SysTime(DateTime(2010, 8, 31, 23, 59, 59),
FracSec.from!"msecs"
On 10.11.2010 0:51, Yao G. wrote:
On Tue, 09 Nov 2010 15:03:10 -0600, Jonathan M Davis
wrote:
Ugh. The datetime.d file is 1.5 MB? 0_o
That must be huge unittests :)
--
Dmitry Olshansky
On Tue, 09 Nov 2010 15:03:10 -0600, Jonathan M Davis
wrote:
Ugh. The datetime.d file is 1.5 MB? 0_o
--
Yao G.
Latest: http://is.gd/gSwDv
After some discussion on the runtime list, it was decided that core.time and
std.datetime should share their Duration type, so I created time.d as a
prospective core.time and moved or copied datetime's Duration and any other
types or functions that it needed to time.d
36 matches
Mail list logo
