Re: DateTime::Lite
On Sat, 22 Nov 2008, Daisuke Maki wrote: Hi, I have an RFC/request for blessing for a module. So I have this requirement to make DateTime leaner, in terms of speed, load time, and the amount of memory consumed. The target is for casual users, so the use of XS code is not an option either. Doesn't Time::Piece (core in 5.10) already fill this niche? Ok, it doesn't do the locale and timezone stuff but IMO adding it there would make more sense than a DateTime::Lite. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: DateTime::Lite
On Mon, 24 Nov 2008, Daisuke Maki wrote: No, for 3 reasons: 1. it's XS http://search.cpan.org/src/MSERGEANT/Time-Piece-1.13/Piece.xs Ok yes that would be a dealbreaker. Though if it is part of a default perl installation it is a lot less of a problem for casual users. 2. it would mean different API 3. as you say, it doesn't do everything DateTime can. I doubt if I am the only person who might ask this question. Perhaps you should add a comparison to Time::Piece to the POD? -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: DateTime::Lite
I didn't notice so I didn't write this, but though Time::Piece may be in core, it's not in 5.8.x corelist -a Time::Piece 5.009005 1.11_02 5.01 1.12 If the argument there was Time::Piece has /always/ been in core, I would concede, but since it's only in the latest release, that would defeat my purposes as well. I doubt if I am the only person who might ask this question. Perhaps you should add a comparison to Time::Piece to the POD? Well, not that I'm trying to be terse... but I need DateTime, not Time::Piece. I need something that resembles DateTime, but faster, leaner, without XS. Time::Piece just wouldn't cut it. Since XS rules out Time::Piece, I still don't see why /not/? Is there any reason why? --d
Re: DateTime::Lite
On Mon, 24 Nov 2008, Daisuke Maki wrote: Well, not that I'm trying to be terse... but I need DateTime, not Time::Piece. I need something that resembles DateTime, but faster, leaner, without XS. Time::Piece just wouldn't cut it. Since XS rules out Time::Piece, I still don't see why /not/? Is there any reason why? Now that you have explained it I don't see why not either. However personally I have always thought of Time::Piece as DateTime 'lite' and I am guessing other people might too. So I think an explicit comparison in the docs would be useful. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: DateTime::Lite
Lite may pass the set of tests you extracted, but what about compatability with DateTime extensions like ::Set? I contend that the best way to tackle something like this and yield a more broadly useful Lite kit would be to get DateTime to use AutoSplit and/or subclass DateTime to override the chubbier bits. In my usage of DateTime, loading has never been the issue, but rather things like parameter validation and lack of memoization (friendliness). um, wait wait. Okay, so I don't want, nor intend to claim Datetime::Lite to be 100% API compatible with DateTime. I don't intend for DateTime::*** modules to use DateTime::Lite. This is for people who use the minimal aspects of DateTime, which is mainly to grab a date, do some calculation, and maybe print them out. But at the same time, I don't want Time::Piece (even if it was pure perl), but something that resembles DateTime, because 1. I want something that can (relatively) easily be replaced back to DateTime later. 2. I want something that is as full-featured as DateTime, so my audience don't start saying things like Well, using modules give you performance penalty, so let's /not/ use them at all! or Perl sucks, let's use because of petty performance problems. okay, so I'm starting to suspect that I didn't define my audience, and that's causing people to go WTF, another bad clone?. Perhaps that's what's Jaldhar is asking elsewhere in this thread. --d
Re: DateTime::Lite
Now that you have explained it I don't see why not either. However personally I have always thought of Time::Piece as DateTime 'lite' and I am guessing other people might too. So I think an explicit comparison in the docs would be useful. Thank you. I think I'm starting to see what was missing from my mission statement (or the lack thereof) --d
Re: DateTime::Lite
On Mon, 24 Nov 2008 02:36:53 +0900, Daisuke Maki wrote okay, so I'm starting to suspect that I didn't define my audience, and that's causing people to go WTF, another bad clone?. Perhaps that's what's Jaldhar is asking elsewhere in this thread. Your goals are clear. I welcome a DateTime::Lite pure Perl module that covers the basic needs of DateTime manipulation with minimal overhead. I don't expect full compatibility - hence the Lite. Thanks, Alex
Re: DateTime::Lite
On Sat, November 22, 2008 12:50 am, Daisuke Maki wrote:
So I have this requirement to make DateTime leaner, in terms of speed,
load time, and the amount of memory consumed. The target is for casual
users, so the use of XS code is not an option either.
In terms of speed, one of the things that's unique (AFAIK) to
DateTime is being able to thread-safely convert a datetime from
one timezone to another.
I'd be curious to know how it fares in this regard. Here's a
benchmark that for me shows DateTime proper almost ten times as
slow as non-thread-safely using libc routines (suggestions for
improvement enthusiastically welcomed):
#!/usr/bin/perl -l
use strict;
use warnings;
use DateTime;
use Env::C;
use POSIX mktime;
sub convert_timezone_datetime {
my ($y,$mo,$d,$h,$m,$s,$tz,$new_tz) = @_;
my $dt = DateTime-new(year=$y, month=$mo, day=$d, hour=$h,
minute=$m, second=$s,time_zone=$tz);
$dt-set_time_zone($new_tz);
return map $dt-$_, qw/year month day hour minute second/;
}
sub convert_timezone_env_c {
my ($y,$mo,$d,$h,$m,$s,$tz,$new_tz) = @_;
my $save_tz = Env::C::getenv(TZ);
Env::C::setenv(TZ,$tz,1);
my $time = POSIX::mktime($s,$m,$h,$d,$mo-1,$y-1900,0,0,-1);
Env::C::setenv(TZ,$new_tz,1);
POSIX::tzset(); # localtime_r bug
($s,$m,$h,$d,$mo,$y) = localtime($time);
$mo++; $y+=1900;
# this belongs in a destructor
if (defined $save_tz) { Env::C::setenv(TZ,$save_tz,1) }
else { Env::C::unsetenv(TZ) }
return ($y,$mo,$d,$h,$m,$s);
}
sub convert_timezone_system {
my ($y,$mo,$d,$h,$m,$s,$tz,$new_tz) = @_;
local $ENV{TZ} = $tz;
my $time = POSIX::mktime($s,$m,$h,$d,$mo-1,$y-1900,0,0,-1);
$ENV{TZ} = $new_tz;
POSIX::tzset(); # localtime_r bug
($s,$m,$h,$d,$mo,$y) = localtime($time);
$mo++; $y+=1900;
return ($y,$mo,$d,$h,$m,$s);
}
print join ,,
datetime=convert_timezone_datetime(2008,7,3,23,2,3,America/Denver,America/New_York);
print join ,,
registry=convert_timezone_env_c(2008,7,3,23,2,3,America/Denver,America/New_York);
print join ,,
system=convert_timezone_system(2008,7,3,23,2,3,America/Denver,America/New_York);
use Benchmark timethese;
timethese(-5, {
datetime = sub { my ($y,$mo,$d,$h,$m,$s) =
convert_timezone_datetime(2008,7,3,23,2,3,America/Denver,America/New_York);
return },
env_c = sub { my ($y,$mo,$d,$h,$m,$s) =
convert_timezone_env_c(2008,7,3,23,2,3,America/Denver,America/New_York);
return },
system = sub { my ($y,$mo,$d,$h,$m,$s) =
convert_timezone_system(2008,7,3,23,2,3,America/Denver,America/New_York);
return },
} );
Re: DateTime::Lite
On Sat, November 22, 2008 2:26 am, Daisuke Maki wrote: oops, forgot the SVN url http://svn.coderepos.org/share/lang/perl/DateTime-Lite/trunk Could we have a working tarball, please? I gave up after a very brief attempt to install and use Module::Install.
Re: DateTime::Lite
On Sun, Nov 23, 2008 at 9:45 AM, Alex Teslik [EMAIL PROTECTED] wrote: Your goals are clear. I welcome a DateTime::Lite pure Perl module that covers the basic needs of DateTime manipulation with minimal overhead. I don't expect full compatibility - hence the Lite. +1. I have lots of mostly command line scripts that use DateTime solely to print the current time etc. and have had to convert to something else when asked to make it portable or run with less memory etc. It'll be extremely useful if we can start writing code with DateTime and later replace the 'use' line with DateTime::Lite, or start writing with DateTime::Lite and later upgrade to DateTime when we need more complex stuff like Set or Calendar APIs. -- Tatsuhiko Miyagawa
Re: DateTime::Lite
http://users.endeworks.jp/~daisuke/DateTime-Lite-0.1.tar.gz As noted before, the timezone/locale stuff are not fully portable yet, so you need to be in the distro's root directory for DateTime::Lite to be usable. --d Yitzchak Scott-Thoennes wrote: On Sat, November 22, 2008 2:26 am, Daisuke Maki wrote: oops, forgot the SVN url http://svn.coderepos.org/share/lang/perl/DateTime-Lite/trunk Could we have a working tarball, please? I gave up after a very brief attempt to install and use Module::Install.
Re: DateTime::Lite
On Sun, November 23, 2008 9:09 pm, Daisuke Maki wrote: http://users.endeworks.jp/~daisuke/DateTime-Lite-0.1.tar.gz As noted before, the timezone/locale stuff are not fully portable yet, so you need to be in the distro's root directory for DateTime::Lite to be usable. Nice. 38% faster than DateTime at converting timezones. Can't wait for DateTime::Lite::XS (*ducks*)
Re: DateTime::Lite
Tatsuhiko Miyagawa wrote: It'll be extremely useful if we can start writing code with DateTime and later replace the 'use' line with DateTime::Lite, or start writing with DateTime::Lite and later upgrade to DateTime when we need more complex stuff like Set or Calendar APIs. This module seems to be a nice fit between my DateTime::Lazy and full-blown DateTime. To that end, it would be nice if there was a -to_datetime method that returned the same datetime as a DateTime object. Cheers! Rick Measham -- Message protected for iSite by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au
