Re: datetime::format::w3cdtf
On Wed, 19 Feb 2003, Rick Measham wrote: > On 19/2/03 11:44 am, [EMAIL PROTECTED] at [EMAIL PROTECTED] spake thus: > > I wrote DateTime::Format::W3CDTF > > Just a thought ... once we have a few Formats, maybe we should start > distributing Bundle::DateTime::Format which would contain all the formats > released at the time of downloading? (when we upload a new format, we upload > a new bundle) Sure, if someone wants to that I won't stop them ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: datetime::format::w3cdtf
> back and forth between just making seconds a floating point number and > having an explicit sub-second (nano/milli/zetto/groucho-seconds) slot in > the object. I cast my 2 cents for floating point, because its what I've seen used and its easier to work with. But I think either is a good solution. I think HH::MM::SS.nnn (for an abritrary number of n's) is the way to go. > Absolutely. The API will basically work like this, I think: > > parse_foo - where foo is datetime, duration, interval, recurrence > > format_foo - same deal Cool, so we should be on the look out for DT::Interval, and DT::Recurrence? > I'm not sure how much value there is in [a Format base class]. A simple > API document might be just as useful. Its good OO methodology which tends to repeat its own rewards, often when least expected. I mentioned in a previous email that strftime() could pontentially be passed a Format object, in which case it would be nice to make sure that the blessed ref we're dealing is indeed a descendent of Format. (just an example) kellan -- "the truth is always revolutionary" [antonio gramsci] [EMAIL PROTECTED]
Re: DateTime in XS
On Wed, 19 Feb 2003, Stephen R. Wilcoxon wrote: > > It was pretty slow. I know that the main reason people use Date::Calc is > > that it's really fast. In order to provide a reasonable alternative I > > wanted to try to focus on speed as well as functionality. > > For me (and the company I work for), Dave is correct. I'd love to use > DateTime, but until it is as fast as Date::Calc (and more mature than > current), we'll stick with Date::Calc with a custom wrapper to add some of > the functionality of Date::Manip. Date::Manip and several other modules > we tried were too slow. It's hard to say what "as fast as Date::Calc" would mean, since DateTime.pm does a lot more stuff than Date::Calc. For example, if you wanted to compare two different datetimes with two different time zones, you'd have to manage the offset handling yourself when using Date::Calc. With DateTime.pm you don't. Similarly, when doing date math DateTime.pm properly handles DST changes and so on, with Date::Calc you'd once again have to do this yourself. I started tying to come up with some benchmarks to compare the two but they just didn't make any sense. Date::Calc is definitely still faster, but there are things that are part of the core of DateTime.pm that Date::Calc simply doesn't do. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime::TimeZone 0.07
Basically, the only change here is that tests are skipped unless DateTime.pm 0.06 is installed. This avoids the bootstrapping problem of DateTime.pm 0.06 needs DT::TZ 0.06+ -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime in XS
On Wed, 19 Feb 2003, Tim Bunce wrote: > > 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. The big speedup of moving to XS was taking a whole bunch of math and doing it in C. I don't know that there is any way to optimize this in Perl. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime 0.06 problems
On Wed, 19 Feb 2003, Stephen R. Wilcoxon wrote: > First, on both Solaris 2.6 (Ultra-2) and FreeBSD 4.6.2 (P2-233) under perl > 5.6.1, DateTime::TimeZone fails make test with: > > t/01load.ok > t/02basicok 1468/1478Can't locate object method "utc_year" via package >"DateTime" (perhaps you forgot to load "DateTime"?) at >/home/.cpan/build/DateTime-TimeZone-0.06/blib/lib/DateTime/TimeZone/America/Chicago.pm > line 1834. > # Looks like you planned 1478 tests but only ran 1468. > # Looks like your test died just after 1468. > t/02basicdubious > Test returned status 255 (wstat 65280, 0xff00) > DIED. FAILED tests 1469-1478 > Failed 10/1478 tests, 99.32% okay > t/03link.ok > t/04localok > > After that failure, DateTime still tries to build and has the following > problems: > > On Solaris, it "sticks" on t/05tz test 24 and uses about 1.3GB or memory > and 40% of the cpu. > > On FreeBSD, it fails with the following (probably as a result of only > having DateTime::TimeZone 0.05): Yes. Force the installation of DateTime::TimeZone 0.06 and it should all work. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Datetime 0.06 fails on W2K
On Wed, 19 Feb 2003, Hill, Ronald wrote: > Testing DateTime-0.06 I receive an out of memory error. It stops at > 05tz test 24 this is where I receive the error. CPU util > is 100% memory usage is 2.0 gig Like Stephen pointed out, this may be a problem with DateTime::TimeZone pre-0.06. Can you install the latest version and see if this is still a problem? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: t/05tz further info
On Wed, 19 Feb 2003, Stephen R. Wilcoxon wrote: > In any case, t/05tz of DateTime tests reached 40% cpu and 1.4GB of memory > and seemed to stick on test 24 before I killed it. Maybe we should add an > early test making sure that DateTime::TimeZone is the right version > (assuming the older version caused the huge memory usage)? Wow, that's a lot! ;) I'd bet it's the older version. At least on my system perl only occupies 4.5 MB by the end of the 05tz test. I think previous version of DateTime::TimeZone may have had a bug that could cause it to enter an endless loop in which it generated lots of data. > I thought that a prereq failing to install would cause the "parent" to > fail? In this case, DateTime::TimeZone 0.06 was (attempted) installed as > a prereq of DateTime 0.06. I'll try to fix this. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
DateTime 0.06 problems
First, on both Solaris 2.6 (Ultra-2) and FreeBSD 4.6.2 (P2-233) under perl 5.6.1, DateTime::TimeZone fails make test with: t/01load.ok t/02basicok 1468/1478Can't locate object method "utc_year" via package "DateTime" (perhaps you forgot to load "DateTime"?) at /home/.cpan/build/DateTime-TimeZone-0.06/blib/lib/DateTime/TimeZone/America/Chicago.pm line 1834. # Looks like you planned 1478 tests but only ran 1468. # Looks like your test died just after 1468. t/02basicdubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1469-1478 Failed 10/1478 tests, 99.32% okay t/03link.ok t/04localok After that failure, DateTime still tries to build and has the following problems: On Solaris, it "sticks" on t/05tz test 24 and uses about 1.3GB or memory and 40% of the cpu. On FreeBSD, it fails with the following (probably as a result of only having DateTime::TimeZone 0.05): t/00load..ok t/01sanityok t/02last_day..ok t/03componentsok t/04epoch.ok t/05set...ok t/05tzNOK 25# Failed test (t/05tz.t at line 150) # got: '2050 063019 CDT' # expected: '2050 07 1 1 CDT' The 'year' parameter to DateTime::last_day_of_month was an 'undef', which is not one of the allowed types: scalar at /usr/local/lib/perl5/site_perl/5.6.1/DateTime/TimeZone/OlsonDB.pm line 197 # Looks like you planned 65 tests but only ran 25. # Looks like your test died just after 25. t/05tzdubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 25-65 Failed 41/65 tests, 36.92% okay t/06add...ok t/07compare...ok t/09greg..ok 34/35# this may take a minute... t/09greg..ok t/10subtract..ok t/11duration..ok t/12week..ok t/13strftime..ok t/14language..ok t/15jdok
Re: DateTime in XS
Dave Rolsky wrote: 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* IMNSHO, this is an unrealistic view. We should not take the blame for Sun's failure to ship a C compiler (without an enormous charge) with their systems. If DateTime succeeds, someone will build binary distributions for each platform which lacks a free C compiler (like Windows, btw). This should not be a primary constraint on development for DateTime. If it is obvious that performance for isolated users on relatively unloaded systems (like my desktop ;~) is being harmed by the need to remain "Pure Perl" then XS is pretty much going to be required for all true server platforms. If we build it, someone else will distribute the binary files. Like I said, I could maintain a pure Perl version as well. I would suggest that you do so only so far as it is used to model what the XS version needs to do. Once the API is settled, the pure Perl version should be maintained strictly as a reference implementation (bugfixes only), and not as a parallel development project. My two cents... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
RE: t/05tz in DateTime
Hi Stephen, > > Any way of making t/05tz more resource friendly? > > Running under Perl 5.6.1 on Solaris 2.6 on an Ultra-2, it's > taking 15% cpu > and 760M of memory (113M resident). > > The only other perl process I've seen use that much memory was a > Spreadsheet::ParseExcel job ripping apart a 2M xls file. > Same issues on W2K for that test! I actually ran out of memory :-( Ron Hill
Re: DateTime in XS
On Wed 2003/02/19 11:07:40 CST, Dave Rolsky <[EMAIL PROTECTED]> writes: > On Wed, 19 Feb 2003, Peter J. Acklam wrote: > > > I don't see any point in making DateTime run faster unless someone > > has complained about it being too slow. > > It was pretty slow. I know that the main reason people use Date::Calc is > that it's really fast. In order to provide a reasonable alternative I > wanted to try to focus on speed as well as functionality. For me (and the company I work for), Dave is correct. I'd love to use DateTime, but until it is as fast as Date::Calc (and more mature than current), we'll stick with Date::Calc with a custom wrapper to add some of the functionality of Date::Manip. Date::Manip and several other modules we tried were too slow.
t/05tz further info
It appears the real culprit is that DateTime::TimeZone 0.06 failed on make test: t/02basicok 1468/1478Can't locate object method "utc_year" via package "DateTime" (perhaps you forgot to load "DateTime"?) at /home/users/tmp/wilcoxon/.cpan/build/DateTime-TimeZone-0.06/blib/lib/DateTime/TimeZone/America/Chicago.pm line 1834. # Looks like you planned 1478 tests but only ran 1468. # Looks like your test died just after 1468. t/02basicdubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 1469-1478 Failed 10/1478 tests, 99.32% okay Any ideas what's wrong with this (perl 5.6.1 on Solaris 2.6)? In any case, t/05tz of DateTime tests reached 40% cpu and 1.4GB of memory and seemed to stick on test 24 before I killed it. Maybe we should add an early test making sure that DateTime::TimeZone is the right version (assuming the older version caused the huge memory usage)? I thought that a prereq failing to install would cause the "parent" to fail? In this case, DateTime::TimeZone 0.06 was (attempted) installed as a prereq of DateTime 0.06.
Datetime 0.06 fails on W2K
Hi All, Testing DateTime-0.06 I receive an out of memory error. It stops at 05tz test 24 this is where I receive the error. CPU util is 100% memory usage is 2.0 gig Ron Hill F:\perl_modules\DateTime-0.06>nmake test Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. F:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib\lib', 'blib\arch' )" t\00load.t t\01sanity.t t\02last_day.t t\03components.t t\04epoch.t t\05set.t t\05tz.t t\06add.t t\07compare.t t\09greg.t t\10subtract.t t\11duration.t t\12week.t t\13strftime.t t\14language.t t\15 jd.t t\00load..ok t\01sanityok t\02last_day..ok t\03componentsok t\04epoch.ok t\05set...ok t\05tzdubious Test returned status 5 (wstat 1280, 0x500) DIED. FAILED tests 25-65 Failed 41/65 tests, 36.92% okay t\06add...ok t\07compare...ok t\09greg..ok 21/35# this may take a minute... t\09greg..ok t\10subtract..ok t\11duration..ok t\12week..ok t\13strftime..ok t\14language..ok t\15jdok Failed Test Stat Wstat Total Fail Failed List of Failed --- t\05tz.t 5 128065 41 63.08% 25-65 Failed 1/16 test scripts, 93.75% okay. 41/1048 subtests failed, 96.09% okay. NMAKE : fatal error U1077: 'F:\perl\bin\perl.exe' : return code '0xff' Stop. F:\perl_modules\DateTime-0.06>
Re: datetime::format::w3cdtf
On Tue, 18 Feb 2003 [EMAIL PROTECTED] wrote:
> First I just want to confirm that DateTime does not support fractional
> seconds? Its a little used part of the spec,so I hardly think its a big
> deal, but it would be nice to support if possible.
Not yet. I do want to support sub-seconds resolutions, but feedback from
people on the list and from documents I've been reading seems to go back
and forth between just making seconds a floating point number and having
an explicit sub-second (nano/milli/zetto/groucho-seconds) slot in the
object.
> W3CDTf doesn't have any concept of a duration, so I left the
> parse_duration(), and format_duration() methods out of the class, is this
> allowed by the Format API? (understanding that formats are still an alpha
> feature)
Absolutely. The API will basically work like this, I think:
parse_foo - where foo is datetime, duration, interval, recurrence
format_foo - same deal
and the values of foo are those values that make sense for the format.
Ical happens to have both a datetime and duration format (and recurrences
as well). The DateTime::Format::Common module (or maybe
DateTime::Parse::Common, since it'll only do parsing), which will be like
Graham Barr's Date::Parse, will probably just implement parse_datetime.
> Any thoughts on creating a Date::Format base class? I imagine it would be
> empty exception for some minimal documentation of the API. (or you could
> stick in methods like parse_format { die "Must be overriden"; } but that
> makes it impossible to use can() )
I'm not sure how much value there is in that. A simple API document might
be just as useful.
> Are you interested in having this (and this sort of thing) checked into
> the perl-date-time project on Sourceforge, or maintained separately?
If you want to add it to the perl-date-time repository, that's fine with
me, as long as you can live with the dev standards I'm trying to impose
(which has been easy so far since I've written most of the code ;) This
is documented under docs/development-standards.pod in the repository.
It's nothing too draconian, just an attempt to ensure certain
documentation standards, mostly (and that we all use the same license).
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Params-Validate-0.52 installation error on Win32
On Wed, 19 Feb 2003, Hill, Ronald wrote:
> I received an error when installing Params-Validate-0.52 for Win32 systems.
>
> Basically, the makefile.PL file needs to be changed (to reconize the c
> compiler)
>
> Here are the changes:
>
> if ($^O eq "MSWin32") {
> system("nmake test$Config{obj_ext}") and no_cc();
> }else{
> system("make test$Config{obj_ext}") and no_cc();
> }
Thanks, I just uploaded 0.53, which should fix this.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Params-Validate-0.52 installation error on Win32
Hi David,
I received an error when installing Params-Validate-0.52 for Win32 systems.
Basically, the makefile.PL file needs to be changed (to reconize the c
compiler)
Here are the changes:
if ($^O eq "MSWin32") {
system("nmake test$Config{obj_ext}") and no_cc();
}else{
system("make test$Config{obj_ext}") and no_cc();
}
once this was done all is fine
F:\perl_modules\Params-Validate-0.52>nmake test
Microsoft (R) Program Maintenance Utility Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
F:\perl\bin\Perl.exe -Mblib -IF:\Perl\lib -IF:\Perl\lib -e "use
Test::Harness qw(&runtests $
verbose); $verbose=0; runtests @ARGV;" t\01-validate.t t\02-noop.t
t\03-attribute.t t\04-defaults.t
t\05-noop_default.t t\06-options.t t\07-with.t t\08-noop_with.t t\09-regex.t
t\10-noop_regex.t
Using F:/perl_modules/Params-Validate-0.52/blib
t\01-validateok
t\02-noopok
t\03-attribute...ok
t\04-defaultsok
t\05-noop_defaultok
t\06-options.ok
t\07-withok
t\08-noop_with...ok
t\09-regex...ok
t\10-noop_regex..ok
All tests successful.
Files=10, Tests=276, 1 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
F:\perl_modules\Params-Validate-0.52>nmake install
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;
t/05tz in DateTime
Any way of making t/05tz more resource friendly? Running under Perl 5.6.1 on Solaris 2.6 on an Ultra-2, it's taking 15% cpu and 760M of memory (113M resident). The only other perl process I've seen use that much memory was a Spreadsheet::ParseExcel job ripping apart a 2M xls file.
Re: DateTime in XS
On Wed, 19 Feb 2003, Peter J. Acklam wrote: > I don't see any point in making DateTime run faster unless someone > has complained about it being too slow. It was pretty slow. I know that the main reason people use Date::Calc is that it's really fast. In order to provide a reasonable alternative I wanted to try to focus on speed as well as functionality. > 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* So you don't use DBI, DB_File or BerkeleyDB, Compress::Zlib, etc., etc.? Like I said, I could maintain a pure Perl version as well. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime in XS
[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. 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;
