Re: DateTime does not build from the repository
On Tue, Aug 10, 2010 at 10:14:04AM -0700, David E. Wheeler wrote: On Aug 10, 2010, at 4:23 AM, Michael G Schwern wrote: I updated Dist::Zilla, that usually fixes things, and I got a face full of Moose poop. The sort of stack trace that obscures the real problem. Picking through that, turns out it wants Dist::Zilla::Plugin::ModuleBuild::XSOrPP. I install that and try again... another face full of poop. This time its Dist::Zilla::Plugin::InstallGuide. Pooped on again, now it wants Dist::Zilla::Plugin::SurgicalPodWeaver. This one blows up in tests. I cannot build DateTime. This is a royal PITA. It sure seems like dzil, if not used properly, can significantly raise the barrier to contribution for a project, even if it does optimize things for the core developers. Just chatted with RJBS about this. He said: My line has always been that of COURSE it does. It is to optimize the existing developers' time, not to lower general barrier to becoming a developer. Other people may claim that it doesn't. ... you can use DZ in ways that do nothing to change the barrier to entry i.e., only for release management and VCS integration, or other such configurations I think that this is especially important for widely-used modules, such as DateTime, that require a build process to test (that is, you can't just run `prove -l t`. So perhaps it'd be helpful to check in the Build.PL, even though it's generated, so that the barrier to contribution isn't so high. The Git::CommitBuild plugin can help: http://search.cpan.org/perldoc?Dist::Zilla::Plugin::Git::CommitBuild Once the build is done, this plugin will commit the results of the build to a branch that is completely separate from your regular code branches (i.e. with a different root commit). This potentially makes your repository more useful to those who may not have Dist::Zilla and all of its dependencies installed. Tim.
Re: Moving to subversion?
On Fri, Apr 23, 2004 at 12:54:34AM +0100, David Wheeler wrote: On Apr 22, 2004, at 8:54 PM, Tim Bunce wrote: I should have added that the emails include the diff. No. See example below. As an attachment? That's what has distinguished activitymail over the last two years or so. It's probably trivial to change. It's hardly rocket science. Tim. Author: timbo Date: Thu Apr 22 14:29:51 2004 New Revision: 291 Modified: dbd-oracle/trunk/dbdimp.c dbd-oracle/trunk/t/24implicit_utf8.t Log: Extend new unicode logic to Oracle versions below 9.2 (at least = Oracle 9.0.1 works now) Modified: dbd-oracle/trunk/dbdimp.c == --- dbd-oracle/trunk/dbdimp.c (original) +++ dbd-oracle/trunk/dbdimp.c Thu Apr 22 14:29:51 2004 @@ -39,7 +39,6 @@
Re: Moving to subversion?
On Thu, Apr 22, 2004 at 08:39:17AM +0100, David Wheeler wrote: On Apr 22, 2004, at 5:45 AM, Dave Rolsky wrote: Objections? Comments? My only objection to svn is that activitymail doesn't work with it. Perhaps someone could convince the maintainer of that program to find the tuits to port it, eh? I don't know what activitymail is, but I do know that svn.perl.org sends emails for each commit (to a mailing list that corresponds to the module being changed). Tim.
Re: Moving to subversion?
I should have added that the emails include the diff. Tim. On Thu, Apr 22, 2004 at 04:07:11PM +0100, David Wheeler wrote: On Apr 22, 2004, at 4:01 PM, Tim Bunce wrote: I don't know what activitymail is, but I do know that svn.perl.org sends emails for each commit (to a mailing list that corresponds to the module being changed). That's what activitymail does, but it sends the diffs from the (CVS) commits, too, optionally as an attachment. http://search.cpan.org/dist/activitymail/ Regards, David
Re: [OT] Re: DateTime::Stringify ... Data::Dumper'ing DT objects
On Sun, Feb 22, 2004 at 02:34:58PM -0500, Andrew Pimlott wrote:
On Sat, Feb 21, 2004 at 03:42:40PM -0600, Dave Rolsky wrote:
I think the problem is that Data::Dumper has historically had two
orthogonal uses. One was serializing data structures for persistence, ala
Storable, and the other was for debugging.
Nowadays, I'm guessing most people use Storable for the first, and so it's
probably used more for debugging. But just dumping the structure as is
may not be ideal for debugging.
This dichotomy is unfortunate. It's quite nice to have a readable
serialized format, when space is not important. However, you must use
Data::Dumper _very_ carefully to get reliable serialization, and when I
suggested that it be made easier, people said Data::Dumper is for
pretty-printing, use Storable. Meanwhile, Data::Dumper is much more
verbose than a pretty-printer needs to be. So it's sort of stuck in
no-man's land.
I'd support a patch to Data::Dumper that added (something like) a
$Data::Dumper::Stringify = ...
Where 0 (the default) means dig into objects the way it does now.
And 1 means if $obj-can('') then dump the object as a string.
That seems simple, fast and effective.
An extra layer of the icing on the cake could be:
$Data::Dumper::Stringify = {
DEFAULT = 1, # or 0
$class_name = 0, # or 1
};
to control stringification style of individual classes.
(But that icing doesn't work well in the face of subclasses.)
An alternative/complementary approach would be to allow a callback
to be called for each newly encountered class during a Dump.
The return value would then control how Data::Dumper behaves
for instances of that class.
The callback can use $obj-isa($base_class) to control stringification
so that subclasses are also covered.
Tim.
p.s. CC'd to Ilya Martynov [EMAIL PROTECTED], the current maintainer
Re: DateTime Performance
On Mon, Aug 04, 2003 at 11:32:15PM -0500, Dave Rolsky wrote: Maybe that looks more sane to you? What makes no sense is for BEGIN to show up as a significant chunk of the time it would take to do anything, since this stuff should only happen once. I'm somewhat skeptical that Devel::DProf is working, or works properly at all in general. It's working okay but unhelpfully... Devel::DProf records the name of the sub only when it's first called (naturally, for performance reasons). The problem with BEGIN blocks is that they're called once *then freed* and then the same address is then reused for the next sub definition. Probably easy to fix but I've never had the time. Tim.
Re: DT::F::DBI docs
On 20 Jul 2003 22:53:00 +0200, Claus Färber [EMAIL PROTECTED] wrote: Tim Bunce [EMAIL PROTECTED] schrieb/wrote: The DBI has a (currently private) method to determine the underlying database type. It was borrowed from DBIx::AnyDBD. Take a look at _dbtype_names() in DBI.pm Yeah, I just updated DT::F::DBI to use that function. I intend to extend it to use $dbh-get_info(17); (=SQL_DBMS_NAME), and give it a public api, in the medium term. One of the problems I can see is that it just returns the type ODBC returns, which is already a problem for MySQL (returns /^mysqld-.*/[1]) That is an issue. But that's part of the reason why _dbtype_names() returns an ordered list. For mysqld-foo-bar it may return something like (mysqld-foo-bar, mysqld-foo, mysqld). and PostgreSQL (returns 'PostgreSQL', not 'Pg'[1]). I'm not sure what DBD::PgPP and DBD::PgSPI return, either. Maybe DBI::_dbtype_names should normalise these DBMS names (e.g. to the corresponding DBD::* driver name, if one exists). More likely that the DBI would supply a module that provides mapping between the sets of names. BTW, is there a CVS server for DBI somewhere? No. One day... Tim. Claus [1] I have only looked at unixODBC's source code and not installed it, so I might be wrong there.
Re: Converting to DT
On Tue, Jun 10, 2003 at 03:30:05PM -0500, Dave Rolsky wrote: On Tue, 10 Jun 2003, Ben Bennett wrote: However, I have no idea how fast this is and how much memory it consumes. I will try to release what I have tonight (when I hope to have it in a more usable state). I played with P::RecDescent for Mason, and it is slow and a memory hog. That's no dis to Damian, cause it's a great tool, but in most cases a custom regex-based parser is way faster. I agree. And I'll repeat my (carefully worded) statement that A single regex could handle all formats that follow the ISO 8601 general left-to-right decreasing resolution style, with assorted optional punctuation, plus optional appended TZ. I'm assuming here that a DateTime::Format::Common module should only support four digit years. If you need two digit years then use a specific date parser module. Similarly I'd prefer it to not handle named months (as per ISO 8601) but if it does, then only the English three character abbreviations. Again, if you need more, use a specific date parser module. The DateTime::Format::Common should be *small and fast*. So no Parse::RecDescent, and no fancy features. Those that want an all-singing-all-dancing-guess-your-weight date parser should work on a new, separate, module that can be loaded with all the smarts you want. Tim.
Re: Converting to DT
On Mon, Jun 09, 2003 at 06:16:23PM -0500, Dave Rolsky wrote: On Mon, 9 Jun 2003, Joshua Hoblitt wrote: I just got back from Perl Whirl. Having spent most of the last week plugging DT as a replacement for many of the examples given in the talks, I think we need a converting to DT section in the FAQ or a separate document dedicated to this. For example (I saw this in many presentations ): use POSIX qw( strftime ); my $time = strftime( %Y-%m-%d %H:%M:%S, localtime() ); Of course, if this is _all_ you'll ever need, converting to DT is almost certainly a mistake. And the FAQ needs to make that clear. Perhaps in a When Inot to use DateTime section. I think including the key _facts_ from the recent heated debate (memory usage etc) would also be helpful. Tim.
Re: Request for DateTime API addition: today() constructor
On Tue, Mar 25, 2003 at 09:42:30AM -1000, Joshua Hoblitt wrote: On Tue, 25 Mar 2003, Tim Bunce wrote: On Mon, Mar 24, 2003 at 06:59:17PM -0600, Dave Rolsky wrote: On Mon, 24 Mar 2003, Joshua Hoblitt wrote: True. Though it'll be so commonly used I think it deserves a constructor. Ditto. It would also be nice if it defaults to current TZ instead of a floating time. The same for -now. Actually, both -now and -today default to UTC, because they use Time::Local::timegm internally. I would regularly need either of those so I think I'd like to see constructors for those four common forms. Perhaps: now_local() now_utc() today_local() today_utc Why not have the constructors take any timezone as an argument? -now( 'utc' ) or -now( timezone = 'local' ) or even -now( timezone = 'floating' ) If no arguments are specified you get still get UTC. You could, but I like the simplicity and clarity for these common cases. Tim.
Re: Request for DateTime API addition: today() constructor
On Mon, Mar 24, 2003 at 06:59:17PM -0600, Dave Rolsky wrote: On Mon, 24 Mar 2003, Joshua Hoblitt wrote: True. Though it'll be so commonly used I think it deserves a constructor. Ditto. It would also be nice if it defaults to current TZ instead of a floating time. The same for -now. Actually, both -now and -today default to UTC, because they use Time::Local::timegm internally. I would regularly need either of those so I think I'd like to see constructors for those four common forms. Perhaps: now_local() now_utc() today_local() today_utc Tim.
Re: round() - DateTime method proposal
On Thu, Mar 06, 2003 at 12:05:30PM -0600, Dave Rolsky wrote: On Wed, 5 Mar 2003, Tim Bunce wrote: Or trunc() / truncate to match the Oracle SQL function that does the same thing. It's definitely not 'rounding', though there is some use for rounding and Oracle has a round() function for dates. I like truncate. I think its a winner ;) What does Oracle's round() do, BTW? Looks like this does a reasonable job of explaining it: http://www.unix.org.ua/orelly/oracle/prog2/ch12_01.htm Tim.
Re: DateTime in XS
On Wed, Feb 19, 2003 at 09:22:53AM +0100, Peter J. Acklam wrote: [EMAIL PROTECTED] (Dave Rolsky) wrote: Joshua Hoblitt wrote: Are you planning on requiring XS for DT or also maintaining a pure Perl implementation? Good question. I could maintain the pure Perl code as well, but it's kind of a pain. I think that if the DateTime project is to succeed, speed will count, so I'm kind of leaning towards just requiring XS, which I know is a pain for some OS's I don't see any point in making DateTime run faster unless someone has complained about it being too slow. Agreed. And then first try to make the perl code faster. Tim. Most of the computers I administer don't have C compilers (the run Solaris). Requiring XS makes DateTime useless. I thought DateTime was a great idea, but now I hope the older Date and Time modules will be maintained so I can use them -- or I'll have to roll my own modules. This leaves me at the point I was before the DateTime project started. *groan* Peter -- #!/local/bin/perl5 -wp -*- mode: cperl; coding: iso-8859-1; -*- # matlab comment stripper (strips comments from Matlab m-files) s/^((?:(?:[])}\w.]'+|[^'%])+|'[^'\n]*(?:''[^'\n]*)*')*).*/$1/x;
Re: Including Date::Leapyear in DateTime
On Mon, Feb 17, 2003 at 04:21:11PM +0100, Peter J. Acklam wrote:
Since DateTime aims at cleaning up the module mess related to time,
wouldn't it be a good thing to avoid using Date:: and Time:: modules
altogether?
Particularely in this case, I really don't see the need to use an
external module. It only requires one line of Perl code to figure out
whether a given year is a leap year or a common year in the Gregorian
calendar. Take your pick:
sub isleap {
$_[0] % 4 ? 0 : $_[0] % 100 ? 1 : $_[0] % 400 ? 0 : 1;
}
sub isleap {
($_[0] % 4 == 0 $_[0] % 100 != 0) || $_[0] % 400 == 0;
}
sub isleap {
(! ($_[0] % 4) ($_[0] % 100)) || ! ($_[0] % 400);
}
Or $foo-is_leap_year (leaving the way open for $obj-is_leap_second one day ;-)
Tim.
Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
On Wed, Feb 05, 2003 at 04:39:04PM -0600, Dave Rolsky wrote: On Wed, 5 Feb 2003, Tim Bunce wrote: Er, I may well be missing something as I've not paid attention to this thread, but why not ship them both in the same distribution? Then some tests in t/*.t will test DT and some DT::DZ and both DT and DT::TZ being tested will be the ones in the distribution about to be installed. Assuming that we continue to pre-generate TZ data based on the Olson DB (which may or may not happen), it makes sense to separate them because the two code bases will change at different speeds. One DT::TZ has a firm API and has been reasonably well debugged, it's likely that we'd only have to make a new release when a new Olson DB is released, which happens a few times a year. The DT module, OTOH, may stay in flux longer than DT::TZ, and is likely to continue to stay immature for a longer period of time, meaning initially it'll have many more releases. Eventually, it may become fairly stable (dead? ;) and only see a release very infrequently. Sure. Some modules within the DBI distribution change very rarely, but I still ship them within the DBI distribution as they're closely related and it's a convienience for the user. If size is the issue, why not generate the DT::TZ::foo modules when the user runs perl Makefile.PL? That would make the distribution much smaller. That's that's not okay then I'd suggest creating distributions for each of DT::TZ::Africa::*, DT::TZ::Europe::*, DT::TZ::Pacific::* etc. Add a Bundle::DateTime::TimeZone module to automate the fetch/install of all of them. Then ship the core DT::TZ modules plus one set of zones (say DT::TZ::America) in the DT distribution. Or, then again, given the relative simplicity/portability of the DT::TZ code you could just keep doing what you're doing... :) Tim.
Re: ANNOUNCE: DateTime.pm and DateTime::TimeZone 0.01_00
On Wed, Feb 05, 2003 at 10:58:52AM -0500, John Peacock wrote: Dave Rolsky wrote: Patches welcome ;) The time zone stuff is quite bizarre, I admin. But I really can't think of a way to handle recurring rules (like ongoing DST rules) without being able to date math, for example. How else do you figure out the last Sunday of October? No, it's clear that the modules are deeply intertwined. My primary concern is that it is currently impossible to install both on a fresh machine without skipping the tests on one of the two (at least to begin with). In my mind, DateTime is the parent module (and DateTime::TimeZone is the crazy cousin ;) and should be installed first. DT::TZ should be dependent on DT, IMHO, not the other way round. Er, I may well be missing something as I've not paid attention to this thread, but why not ship them both in the same distribution? Then some tests in t/*.t will test DT and some DT::DZ and both DT and DT::TZ being tested will be the ones in the distribution about to be installed. Tim.
Re: Working time zone code!
On Fri, Jan 31, 2003 at 12:32:57AM -0600, Dave Rolsky wrote: On Thu, 30 Jan 2003, John Peacock wrote: Dave Rolsky wrote: I just checked in a lot of new/changed code under modules/DateTime-TimeZone. This code actually seems to work, and provides access to the complete Olson historical data, plus ongoing time zone changes in the future. t/01load.NOK 1# Failed test (t/01load.t at line 7) # Tried to use 'DateTime::TimeZone'. # Error: Can't locate DateTime/TimeZoneCatalog.pm in @INC Did you forget to add this file to the CVS repository??? Oops, um, you need to run the script tools/parse_olson to generate most of the time zone stuff. Something like: PERL5LIB=/path/to/DateTime.pm/lib/ tools/parse_olson --dir=/path/to/olson/files/ But now I realize DateTime.pm require DateTime::TimeZone, which require DateTime::TimeZoneCatalog, which is generated, which requires ... Bootstrapping problem! I should probably just check in the generated files and be done with it. Anyone have any objections to that? Nope. It's the way many projects with generated files work, including perl. Tim.
Re: Summary of API?
On Wed, Jan 29, 2003 at 11:39:00AM -0600, Dave Rolsky wrote:
On Wed, 29 Jan 2003, Tim Bunce wrote:
The code shown by the URL you posted generates two digit years:
sub ymd {
my ( $self, $sep ) = @_;
$sep = '-' unless defined $sep;
return sprintf( %02d$sep%02d$sep%02d, $self-_as_greg );
}
*date = \ymd;
sub mdy {
my ( $self, $sep ) = @_;
$sep = '-' unless defined $sep;
return sprintf( %02d$sep%02d$sep%02d, ($self-_as_greg)[1,2,0] );
}
sub dmy {
my ( $self, $sep ) = @_;
$sep = '-' unless defined $sep;
return sprintf( %02d$sep%02d$sep%02d, reverse $self-_as_greg );
}
Maybe there's a later version.
[autarch@penguin ~]$ perl -le 'print sprintf(%02d, 1970)'
1970
[autarch@penguin ~]$ perl -le 'print sprintf(%02d, 1)'
01
Maybe it should be %04d though.
Yeap. As you're specifically supporting years 1000, I believe.
Tim.
Re: Summary of API?
On Tue, Jan 28, 2003 at 05:05:07PM -0600, Dave Rolsky wrote:
On Tue, 28 Jan 2003, Tim Bunce wrote:
On Tue, Jan 28, 2003 at 11:07:51AM -0600, Dave Rolsky wrote:
On Tue, 28 Jan 2003, Tim Bunce wrote:
The ymd, mdy, and dmy methods all use two digit years. That's not
ideal but I can understand people might like it. I'd strongly suggest
that they be renamed yymmdd, mmddyy, ddmmyy, and the corresponding
four digit year methods added as: mmdd, mmdd, ddmm.
(Similary hms could be renamed hhmmss for consistency.)
Um, no they don't.
Eh?
They return 4 digit years. In fact, the only way to get a 2-digit year
right now is is $dt-strftime('%y').
The code shown by the URL you posted generates two digit years:
sub ymd {
my ( $self, $sep ) = @_;
$sep = '-' unless defined $sep;
return sprintf( %02d$sep%02d$sep%02d, $self-_as_greg );
}
*date = \ymd;
sub mdy {
my ( $self, $sep ) = @_;
$sep = '-' unless defined $sep;
return sprintf( %02d$sep%02d$sep%02d, ($self-_as_greg)[1,2,0] );
}
sub dmy {
my ( $self, $sep ) = @_;
$sep = '-' unless defined $sep;
return sprintf( %02d$sep%02d$sep%02d, reverse $self-_as_greg );
}
Maybe there's a later version.
Tim.
Re: Summary of API?
On Fri, Jan 24, 2003 at 05:33:05PM -0600, Dave Rolsky wrote:
On Fri, 24 Jan 2003, Tim Bunce wrote:
Would someone do me the great favour of summarizing some things for me?
Just the Goals and Design Principles would be great, an outline of
the API(s) would be a bonus.
I'm particularly interested in:
Basic object API (there is going to be an object right?)
Yes, it will be an object. The API is not even close to finalized, but
you can take a look at the docs for the DateTime.pm module in CVS to get
an idea of where it's going:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/perl-date-time/modules/DateTime.pm/lib/DateTime.pm?rev=1.16content-type=text/vnd.viewcvs-markup
Thanks. Some comments:
I've a bunch of relatively minor efficiency concerns but I'll address
those by sending a patch once more dust has settled :)
The 'floating' param needs a better name. Perhaps 'no_timezone', or
at least someing that better indicates it's related to timezones.
Maybe just use a specific value for the 'time_zone' parameter:
time_zone = undef.
The elsif ( exists( $args{offset} ) ) branch at the end of new()
contains if ($args{floating} which will never be true there.
All internal functions (not methods) should probably begin with an
underscore for the same reasons as internal methods do.
Class data is bad (just doesn't scale to big applications, consider
mod_perl for example). Use of class data should be limited to
providing default values for undefined object attributes.
The docs for new() are confusing about timezone handling.
First it says It defaults times to UTC (Greenwich Mean Time, also
called Zulu). Then The new() method tries to be intelligent about
figuring out your local time zone. If you enter a time that's not
*explicitly* in UTC, it looks at the environment variable CTZ.
The ymd, mdy, and dmy methods all use two digit years. That's not
ideal but I can understand people might like it. I'd strongly suggest
that they be renamed yymmdd, mmddyy, ddmmyy, and the corresponding
four digit year methods added as: mmdd, mmdd, ddmm.
(Similary hms could be renamed hhmmss for consistency.)
The parsetime method should be renamed hour_min_sec and return
values in that order (removing the need for a reverse in hms)
and documented as a public method. It's very common for all to be
needed together.
A corresponding public year_month_day method should be provided.
So your example:
The core functionality will be extensible by simply by having a
well-defined, simple API. For example, a module that provides ICal
datetime format output does this:
my $date = join '', $dt-year, $dt-month, $dt-day;
$date .= join '', $dt-hour, $dt-minute, $dt-second;
could now use:
my $date = join '', $dt-year_month_day
$date .= join '', $dt-hour_min_sec;
and save four method calls.
I think hour_min_sec (aka parsetime) either shouldn't int() the seconds
or a separate hour_min_secf method should be provided.
As for speed, there's a couple ways to attack this. First of all, a lot
of the calculations the core object will be doing can be memoized quite
easily, and reset only when the object is changed (which will be
infrequent in most uses).
Don't memoize until the API is stable and only after you've given myself
and others a chance to optimize the internals. Most of the core
DateTime.pm code can probably be made fast enough that the overhead
of memoizing may be too great to make an improvement.
The other bottleneck that may occur is the time zone code. Since this
will largely be generated from the Olson DB, it's not too much of a
stretch to imagine generating XS code instead of Perl.
Again, don't rush. The most important thing to get right is the API.
All else is changable in time.
Overall it looks good.
Tim.
Re: Summary of API?
On Tue, Jan 28, 2003 at 11:07:51AM -0600, Dave Rolsky wrote: On Tue, 28 Jan 2003, Tim Bunce wrote: The ymd, mdy, and dmy methods all use two digit years. That's not ideal but I can understand people might like it. I'd strongly suggest that they be renamed yymmdd, mmddyy, ddmmyy, and the corresponding four digit year methods added as: mmdd, mmdd, ddmm. (Similary hms could be renamed hhmmss for consistency.) Um, no they don't. Eh? Tim.
Summary of API?
Would someone do me the great favour of summarizing some things for me? Just the Goals and Design Principles would be great, an outline of the API(s) would be a bonus. I'm particularly interested in: Basic object API (there is going to be an object right?) Extensibility (through subclasses or in other ways) Using the extensibility well to avoid bloat of the basic object Efficiency for common usage Thanks. Tim. p.s. Yes, I've looked at the archives.
