Re: Re: [rfc] HiRes
> Dave Rolsky <[EMAIL PROTECTED]> wrote: > I take it back. I thought we'd have now() and hires_now(). I think > having nanosecond at 0 makes sense to most people. Hang on, before we go any further and before code exists can I point out that we should have high_res_now() or now_high_res() or now(high_res=>1) rather than 'hires' which looks like the past tense of the verb to 'hire'. At all other times in DateTime we've made sure not to abbreviate, but high_resolution_now() is too cumbersome :) Mainly don't go with hires even though a 'famous' module already does. Cheers! Rick
Re: [rfc] HiRes
> > The more I think about this the more I like it. We'll only have to > > commit the fractional seconds fix to DateTime.pm. I'd suggest > > DateTime::HiRes.pm to be included with the DT distribution. The down > > side is this functionality wouldn't be available to decorators unless > > DateTime::HiRes was a subclass of DT. > > What would DateTime::HiRes offer besides a hires_now() method? Nothing. :) DateTime::HiRes->now() reads nicely. -J --
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Joshua Hoblitt wrote: > > > I take it back. I thought we'd have now() and hires_now(). I think > > > having nanosecond at 0 makes sense to most people. > > > > We have an awful lot of constructors already. Maybe we should put this into > > another package? > > The more I think about this the more I like it. We'll only have to > commit the fractional seconds fix to DateTime.pm. I'd suggest > DateTime::HiRes.pm to be included with the DT distribution. The down > side is this functionality wouldn't be available to decorators unless > DateTime::HiRes was a subclass of DT. What would DateTime::HiRes offer besides a hires_now() method? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [rfc] HiRes
> > # Because epoch may come from Time::HiRes
> > my $fraction = $p{epoch} - int( $p{epoch} );
> > -$args{nanosecond} = $fraction * MAX_NANOSECONDS
> > +$args{nanosecond} = int( $fraction * MAX_NANOSECONDS )
> > if $fraction;
>
> What's this for? I think it was working as is.
Otherwise you will most likely get a fractional result.
> >
> > # use scalar time in case someone's loaded Time::Piece
> > -sub now { shift->from_epoch( epoch => (scalar time), @_ ) }
> > +sub now { shift->from_epoch( epoch => Time::HiRes::time, @_ ) }
>
> Yep, looks right
The comment should be removed too.
> > I'm not sure exactly how to test this. Call now times several times in
> > a row and make that one of the results is non-zero for nanoseconds?
>
> Yeah, I don't know a good solid way to test this either. Maybe override
> Time::HiRes::time() in the test?
We could try it. Will that confuse AUTOLOAD?
-J
--
Re: [rfc] HiRes
> > I take it back. I thought we'd have now() and hires_now(). I think > > having nanosecond at 0 makes sense to most people. > > We have an awful lot of constructors already. Maybe we should put this into another > package? The more I think about this the more I like it. We'll only have to commit the fractional seconds fix to DateTime.pm. I'd suggest DateTime::HiRes.pm to be included with the DT distribution. The down side is this functionality wouldn't be available to decorators unless DateTime::HiRes was a subclass of DT. -J --
Re: [rfc] HiRes
> I take it back. I thought we'd have now() and hires_now(). I think > having nanosecond at 0 makes sense to most people. We have an awful lot of constructors already. Maybe we should put this into another package? -J --
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Dave Rolsky wrote:
> > # use scalar time in case someone's loaded Time::Piece
> > -sub now { shift->from_epoch( epoch => (scalar time), @_ ) }
> > +sub now { shift->from_epoch( epoch => Time::HiRes::time, @_ ) }
>
> Yep, looks right
I take it back. I thought we'd have now() and hires_now(). I think
having nanosecond at 0 makes sense to most people.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Joshua Hoblitt wrote:
> > In general, I have no qualms about dependencies if they're on
> > known-to-be-good modules _and_ they provide some useful functionality. In
> > this case, it's even less of a concern since Time::HiRes is a core module.
>
> We can't import Time::HiRes's time as there is already a DateTime::time()
That's alright. I'm not that big on importing stuff.
> Index: lib/DateTime.pm
> ===
> RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/lib/DateTime.pm,v
> retrieving revision 1.232
> diff -u -r1.232 DateTime.pm
> --- lib/DateTime.pm 31 Jul 2003 23:49:41 - 1.232
> +++ lib/DateTime.pm 2 Aug 2003 21:40:36 -
> @@ -48,6 +48,7 @@
> use DateTime::LeapSecond;
> use Params::Validate qw( validate SCALAR BOOLEAN HASHREF OBJECT );
> use Time::Local ();
> +use Time::HiRes;
>
> # for some reason, overloading doesn't work unless fallback is listed
> # early.
> @@ -385,7 +386,7 @@
>
> # Because epoch may come from Time::HiRes
> my $fraction = $p{epoch} - int( $p{epoch} );
> -$args{nanosecond} = $fraction * MAX_NANOSECONDS
> +$args{nanosecond} = int( $fraction * MAX_NANOSECONDS )
> if $fraction;
What's this for? I think it was working as is.
>
> # Note, for very large negative values this may give a blatantly
> @@ -403,7 +404,7 @@
> }
>
> # use scalar time in case someone's loaded Time::Piece
> -sub now { shift->from_epoch( epoch => (scalar time), @_ ) }
> +sub now { shift->from_epoch( epoch => Time::HiRes::time, @_ ) }
Yep, looks right
> I'm not sure exactly how to test this. Call now times several times in
> a row and make that one of the results is non-zero for nanoseconds?
Yeah, I don't know a good solid way to test this either. Maybe override
Time::HiRes::time() in the test?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: [rfc] HiRes
I'm not really awake yet. I meant to say: I'm not sure exactly how to test this. Call now several times and make sure that one of the results is non-zero for nanoseconds? -J --
Re: [rfc] HiRes
> In general, I have no qualms about dependencies if they're on
> known-to-be-good modules _and_ they provide some useful functionality. In
> this case, it's even less of a concern since Time::HiRes is a core module.
We can't import Time::HiRes's time as there is already a DateTime::time()
Index: lib/DateTime.pm
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/lib/DateTime.pm,v
retrieving revision 1.232
diff -u -r1.232 DateTime.pm
--- lib/DateTime.pm 31 Jul 2003 23:49:41 - 1.232
+++ lib/DateTime.pm 2 Aug 2003 21:40:36 -
@@ -48,6 +48,7 @@
use DateTime::LeapSecond;
use Params::Validate qw( validate SCALAR BOOLEAN HASHREF OBJECT );
use Time::Local ();
+use Time::HiRes;
# for some reason, overloading doesn't work unless fallback is listed
# early.
@@ -385,7 +386,7 @@
# Because epoch may come from Time::HiRes
my $fraction = $p{epoch} - int( $p{epoch} );
-$args{nanosecond} = $fraction * MAX_NANOSECONDS
+$args{nanosecond} = int( $fraction * MAX_NANOSECONDS )
if $fraction;
# Note, for very large negative values this may give a blatantly
@@ -403,7 +404,7 @@
}
# use scalar time in case someone's loaded Time::Piece
-sub now { shift->from_epoch( epoch => (scalar time), @_ ) }
+sub now { shift->from_epoch( epoch => Time::HiRes::time, @_ ) }
sub today { shift->now(@_)->truncate( to => 'day' ) }
--
#!/usr/bin/env perl
use strict;
use DateTime;
my $dt = DateTime->now;
print $dt->datetime, "\n";
print $dt->nanosecond, "\n";
--
2003-08-02T21:43:20
4058957
I'm not sure exactly how to test this. Call now times several times in a row and make
that one of the results is non-zero for nanoseconds?
-J
--
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Claus Färber wrote: > Joshua Hoblitt <[EMAIL PROTECTED]> schrieb/wrote: > >> OTOH, maybe I dont understand how your DateTime->hires( 1 ) call > >> would work without adding HiRes as a dependency. > > > It does - ... > > IMO no DateTime::* module should depend on Time or Date modules outside > of that namespace. DT should replace them eventually. > > Maybe DateTime::Hires as a replacement for Time::HiRes? Um, what would it do differently? Are you really proposing to implement the same functionality as Time::HiRes in a new namespace? That just seems silly. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [rfc] HiRes
Joshua Hoblitt <[EMAIL PROTECTED]> schrieb/wrote: >> OTOH, maybe I dont understand how your DateTime->hires( 1 ) call >> would work without adding HiRes as a dependency. > It does - ... IMO no DateTime::* module should depend on Time or Date modules outside of that namespace. DT should replace them eventually. Maybe DateTime::Hires as a replacement for Time::HiRes? Claus -- http://www.faerber.muc.de
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Joshua Hoblitt wrote: > > $dt = DateTime->now_high_res(); > > or > > $dt = DateTime->now( high_res=>1 ); > > Thats a possibility too. Although to me that syntax would seem to > guarantee HiRes support to be available. I don't know if we want add > Time::HiRes as a dependency. In general, I have no qualms about dependencies if they're on known-to-be-good modules _and_ they provide some useful functionality. In this case, it's even less of a concern since Time::HiRes is a core module. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [rfc] HiRes
> OTOH, maybe I dont understand how your DateTime->hires( 1 ) call > would work without adding HiRes as a dependency. It does - but it could be more of a please use it if you've got it. Having an explicit constructor for the hires behavior says that your guaranteed to get it (IMHO). Maybe your suggestion of using it by default if it's installed is better. -J --
Re: [rfc] HiRes
> $dt = DateTime->now_high_res(); or $dt = DateTime->now( high_res=>1 ); Thats a possibility too. Although to me that syntax would seem to guarantee HiRes support to be available. I don't know if we want add Time::HiRes as a dependency. Yup, it does have that effect and I'd prefer not to have extra dependencies. How about just using it if the user has it installed? So if I don't have it, I get 20:31:59 and if I do have it I get 20:31:59.2334987324 in the call to now(high_res=>1). (of course we should probably thow a warn if its not installed and its called) OTOH, maybe I dont understand how your DateTime->hires( 1 ) call would work without adding HiRes as a dependency. Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners "Write a wise proverb and your name will live forever." -- Anonymous
Re: [rfc] HiRes
> $dt = DateTime->now_high_res(); > or > $dt = DateTime->now( high_res=>1 ); Thats a possibility too. Although to me that syntax would seem to guarantee HiRes support to be available. I don't know if we want add Time::HiRes as a dependency. -J --
Re: [rfc] HiRes
At 11:42 PM -1000 1/8/03, Joshua Hoblitt wrote:
> Alternatively you could just test for it in places where it would be
useful (which are ...?):
if ($INC{'Time/HiRes.pm'}) {
# Work in HiRes
}
The only place it matters inside DT (from_epoch) already supports it.
This means that if the user has loaded Time::HiRes, then we can use
it. Otherwise we dont.
That doesn't make it very easy to say "I want an object that
represents the time 'right now' with sub second resolution".
What I'm proposing is like the Net::Ping syntax but at the class level.
So you're only suggesting it as a part of the now() call? If that's
the case why not have:
$dt = DateTime->now();
and
$dt = DateTime->now_high_res();
or
$dt = DateTime->now( high_res=>1 );
Cheers!
Rick
--
There are 10 kinds of people:
those that understand binary, and those that don't.
The day Microsoft makes something that doesn't suck
is the day they start selling vacuum cleaners
"Write a wise proverb and your name will live forever."
-- Anonymous
Re: [rfc] HiRes
> Alternatively you could just test for it in places where it would be
> useful (which are ...?):
>
> if ($INC{'Time/HiRes.pm'}) {
> # Work in HiRes
> }
The only place it matters inside DT (from_epoch) already supports it.
> This means that if the user has loaded Time::HiRes, then we can use
> it. Otherwise we dont.
That doesn't make it very easy to say "I want an object that represents the time
'right now' with sub second resolution".
What I'm proposing is like the Net::Ping syntax but at the class level.
# High precision syntax (requires Time::HiRes)
$p = Net::Ping->new();
$p->hires();
--
DateTime->hires( 1 );
my $dt = DateTime->now;
-J
--
Re: [rfc] HiRes
At 11:12 PM -1000 1/8/03, Joshua Hoblitt wrote:
Since from_epoch() already supports Time::HiRes I was thinking that
a class method to set use of this would be handy.
Something like:
DateTime->hires( 1 );
Alternatively you could just test for it in places where it would be
useful (which are ...?):
if ($INC{'Time/HiRes.pm'}) {
# Work in HiRes
}
This means that if the user has loaded Time::HiRes, then we can use
it. Otherwise we dont.
Just a thought.
Cheers!
Rick
--
There are 10 kinds of people:
those that understand binary, and those that don't.
The day Microsoft makes something that doesn't suck
is the day they start selling vacuum cleaners
"Write a wise proverb and your name will live forever."
-- Anonymous
[rfc] HiRes
Since from_epoch() already supports Time::HiRes I was thinking that a class method to set use of this would be handy. Something like: DateTime->hires( 1 ); ??? -J --
