Re: Windows once more

2003-06-04 Thread John Peacock
Hill, Ronald wrote:

But DT::TZ installs normally without DT.pm being installed, so I don't
know what the problem is.
-dave
But you can't run the tests without DT.pm. I think
that is what he is referring to.
I would once again suggest including exclusively those portions of DT::TZ in the 
DT distribution that are required to sucessfully test DT.  They can be installed 
as is, so that DT is not *per se* dependent on DT::TZ, with a strong warning 
that the full DT::TZ is required for full functionality.  Then the DT::TZ module 
could be made dependent on DT, so that both modules can be tested as fully as 
their tests allow.  This would make both CPAN and ActiveState happy, I think.

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: Windows once more

2003-06-04 Thread Hill, Ronald


> 
> But DT::TZ installs normally without DT.pm being installed, so I don't
> know what the problem is.
> 
> 
> -dave
But you can't run the tests without DT.pm. I think
that is what he is referring to.

Ron


Re: Windows once more

2003-06-04 Thread Iain Truskett
* Randy W. Sims ([EMAIL PROTECTED]) [04 Jun 2003 13:19]:

[...]
> ActiveState uses scripts to automatically create PPDs for all modules
> on CPAN that will build/test successfully. See
>  for the results and logs of these
> builds. Currently DT fails on all platforms; probably because of the
> weird circular dependence with DT::TimeZone. It would be nice if DT
> were stubbed out so that it would build normally ;)

Unfortunately there are no logs for DT or DT-TZ.


cheers,
-- 
Iain.


Re: Windows once more

2003-06-04 Thread Dave Rolsky
On Tue, 3 Jun 2003, Randy W. Sims wrote:

> ActiveState uses scripts to automatically create PPDs for all modules on
> CPAN that will build/test successfully. See
>  for the results and logs of these
> builds. Currently DT fails on all platforms; probably because of the
> weird circular dependence with DT::TimeZone. It would be nice if DT were
> stubbed out so that it would build normally ;)

But DT::TZ installs normally without DT.pm being installed, so I don't
know what the problem is.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/


RE: Windows once more

2003-06-03 Thread Dave Rolsky
On Mon, 2 Jun 2003, Hill, Ronald wrote:

> > I'd have to write a script to automatically grab the CVS stuff, but I
> > suppose it's possible.
>
> If you do write a script, can you send me a copy?

Sure, but it's kind of low on my to-do list.

> > The links on datetime.perl.org are for PPDs, which are
> > rapidly aging.  I'm
> > considering removing them since they're so out of date.  I
> > think we need a
> > script to generate those as well.
>
> Yes I agree! I would be willing to write something
> just as soon as we can build DateTime.pm on Windows :)

Hopefully John will fix it ;)


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/


RE: Windows once more

2003-06-03 Thread Hill, Ronald

Hi Dave,

> 
> I'd have to write a script to automatically grab the CVS stuff, but I
> suppose it's possible.

If you do write a script, can you send me a copy?

> 
> The links on datetime.perl.org are for PPDs, which are 
> rapidly aging.  I'm
> considering removing them since they're so out of date.  I 
> think we need a
> script to generate those as well.

Yes I agree! I would be willing to write something
just as soon as we can build DateTime.pm on Windows :)

Ron Hill 


RE: Windows once more

2003-06-03 Thread Hill, Ronald

Hi Dave,

> 
> On Mon, 2 Jun 2003, Hill, Ronald wrote:
> > I can't even get it to work on HPUX :(
> 
> Try removing the "ifdef _HPUX_SOURCE" part entirely.
> 
> 
> -dave

I removed the section you suggested
Still no joy :(

Ron Hill


Re: Windows once more

2003-06-03 Thread Dave Rolsky
On Mon, 2 Jun 2003, John Peacock wrote:

> Dave Rolsky wrote:
> > ARGH!
> >
> > I give up.  Someone else is going to have to fix this on Windows at this
> > point, or maybe I'll just disable these tests on Win32.
> >
>
> I use Windows/VC-- (shudder) in my day job, but SourceForge is down for their
> weekly restore from tape (did they forget to update their Apache again??? ;~),
> so I cannot get the latest CVS snapshot.  Any chance the datetime.perl.org could
> be kept synced to the SF repository (it currently has links to DateTime 0.08!)?

I'd have to write a script to automatically grab the CVS stuff, but I
suppose it's possible.

The links on datetime.perl.org are for PPDs, which are rapidly aging.  I'm
considering removing them since they're so out of date.  I think we need a
script to generate those as well.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/


Re: Windows once more

2003-06-03 Thread John Peacock
Dave Rolsky wrote:
ARGH!

I give up.  Someone else is going to have to fix this on Windows at this
point, or maybe I'll just disable these tests on Win32.
I use Windows/VC-- (shudder) in my day job, but SourceForge is down for their 
weekly restore from tape (did they forget to update their Apache again??? ;~), 
so I cannot get the latest CVS snapshot.  Any chance the datetime.perl.org could 
be kept synced to the SF repository (it currently has links to DateTime 0.08!)?

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: Windows once more

2003-06-03 Thread Dave Rolsky
On Mon, 2 Jun 2003, Hill, Ronald wrote:

> > ARGH!
> >
> > I give up.  Someone else is going to have to fix this on
> > Windows at this
> > point, or maybe I'll just disable these tests on Win32.
> >
> >
> > -dave
>
> Oh, Dave please don't give up. We need this for all Platforms
> Otherwise, modules that use recurences will fail horribly!
> (like mine). This is the reason I need to install the latest
> DateTime.pm module, So I can test my module.

I give up in the sense of "patches welcome", but I don't have any idea
what the problem is, so it's going to take someone who actually
understands Windows to fix this.

> I can't even get it to work on HPUX :(

Try removing the "ifdef _HPUX_SOURCE" part entirely.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/


RE: Windows once more

2003-06-03 Thread Hill, Ronald

Hi Dave,

> 
> On Mon, 2 Jun 2003, Hill, Ronald wrote:
> 
> > I was not able to find the Time::Local module on CPAN
> 
> Yeah, it's not there yet.

I guess I will wait for it.

> ARGH!
> 
> I give up.  Someone else is going to have to fix this on 
> Windows at this
> point, or maybe I'll just disable these tests on Win32.
> 
> 
> -dave

Oh, Dave please don't give up. We need this for all Platforms
Otherwise, modules that use recurences will fail horribly!
(like mine). This is the reason I need to install the latest
DateTime.pm module, So I can test my module.
I can't even get it to work on HPUX :(

I guess I have to bite the bullet and try on AIX :(

Ron Hill


RE: Windows once more

2003-06-03 Thread Dave Rolsky
On Mon, 2 Jun 2003, Hill, Ronald wrote:

> I was not able to find the Time::Local module on CPAN

Yeah, it's not there yet.

> t\20infinite..NOK 12# Failed test (t\20infinite.t at line 55)
> #  got: '1.#QNAN'
> # expected: '-1.#IND'
> t\20infinite..NOK 13# Failed test (t\20infinite.t at line 55)
> #  got: '1.#QNAN'
> # expected: '-1.#IND'
> t\20infinite..NOK 14# Failed test (t\20infinite.t at line 55)
> #  got: '0'
> # expected: '-1.#IND'
> t\20infinite..ok 36/36# Looks like you failed 3 tests of 36.

ARGH!

I give up.  Someone else is going to have to fix this on Windows at this
point, or maybe I'll just disable these tests on Win32.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/


RE: Windows once more

2003-06-02 Thread Hill, Ronald


> 
> Ok, I think the test results for 20infinite.t may be 
> different because of
> recent changes in subtract_datetime.  Could a Windows user 
> run the tests
> again, please?
> 
> For the 04epoch.t failures, I think I'll need to be able to 
> use the latest
> Time::Local code, which means releasing it to CPAN.  
> Hopefully this will
> happen soon.

I was not able to find the Time::Local module on CPAN
Here are the results of nmake test

G:\modules\DateTime.pm>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\00load.t t\01sanity.t
t\02last_day.t t\03components.t t\04
poch.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\15jd.t t\16truncate.t t\17set_return.t
t\18today.t t\19leap_secon
.t t\20infinite.t t\21bad_params.t t\22_from_doy.t t\zz_00load.t
t\zz_01sanity.t t\zz_02last_day.t
\zz_03components.t t\zz_04epoch.t t\zz_05set.t t\zz_05tz.t t\zz_06add.t
t\zz_07compare.t t\zz_09gre
.t t\zz_10subtract.t t\zz_11duration.t t\zz_12week.t t\zz_13strftime.t
t\zz_14language.t t\zz_15jd.
 t\zz_16truncate.t t\zz_17set_return.t t\zz_18today.t t\zz_19leap_second.t
t\zz_20infinite.t t\zz_2
bad_params.t t\zz_22_from_doy.t
Using G:/modules/DateTime.pm/blib
t\00load..ok
t\01sanityok
t\02last_day..ok
t\03componentsok
t\04epoch.NOK 25# Failed test (t\04epoch.t at line 96)
#  got: undef
# expected: '-2082844800'
The 'day' parameter to DateTime::new was an 'undef', which is not one of the
allowed types: scalar
 at t\04epoch.t line 101
# Looks like you planned 28 tests but only ran 25.
# Looks like your test died just after 25.
t\04epoch.dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 25-28
Failed 4/28 tests, 85.71% okay
t\05set...ok
t\05tzok
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
t\16truncate..ok
t\17set_returnok
t\18today.ok
t\19leap_second...ok
t\20infinite..NOK 12# Failed test (t\20infinite.t at line 55)
#  got: '1.#QNAN'
# expected: '-1.#IND'
t\20infinite..NOK 13# Failed test (t\20infinite.t at line 55)
#  got: '1.#QNAN'
# expected: '-1.#IND'
t\20infinite..NOK 14# Failed test (t\20infinite.t at line 55)
#  got: '0'
# expected: '-1.#IND'
t\20infinite..ok 36/36# Looks like you failed 3 tests of 36.
t\20infinite..dubious
Test returned status 3 (wstat 768, 0x300)
DIED. FAILED tests 12-14
Failed 3/36 tests, 91.67% okay
t\21bad_paramsok
t\22_from_doy.ok
t\zz_00load...ok
t\zz_01sanity.ok
t\zz_02last_day...ok
t\zz_03components.ok
t\zz_04epoch..NOK 25# Failed test (t\zz_04epoch.t at line 100)
#  got: undef
# expected: '-2082844800'
The 'day' parameter to DateTime::new was an 'undef', which is not one of the
allowed types: scalar
 at t\zz_04epoch.t line 105
# Looks like you planned 28 tests but only ran 25.
# Looks like your test died just after 25.
t\zz_04epoch..dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 25-28
Failed 4/28 tests, 85.71% okay
t\zz_05setok
t\zz_05tz.ok
t\zz_06addok
t\zz_07compareok
t\zz_09greg...ok 34/35# this may take a minute...
t\zz_09greg...ok
t\zz_10subtract...ok
t\zz_11duration...ok
t\zz_12week...ok
t\zz_13strftime...ok
t\zz_14language...ok
t\zz_15jd.ok
t\zz_16truncate...ok
t\zz_17set_return.ok
t\zz_18today..ok
t\zz_19leap_secondok
t\zz_20infinite...NOK 12# Failed test (t\zz_20infinite.t at line 59)
#  got: '1.#QNAN'
# expected: '-1.#IND'
t\zz_20infinite...NOK 13# Failed test (t\zz_20infinite.t at line 59)
#  got: '1.#QNAN'
# expected: '-1.#IND'
t\zz_20infinite...NOK 14# Failed test (t\zz_20infinite.t at line 59)
#  got: '0'
# expected: '-1.#IND'
t\zz_20infinite...ok 36/36# Looks like you failed 3 tests of 36.
t\zz_20infinite...dubious
Test returned status 3 (wstat 768, 0x300)
DIED. FAILED tests 12-14
Failed 3/36 tests, 91.67% okay
t\zz_21bad_params.ok
t\zz_22_from_doy..ok
Failed Test   Stat Wstat Total Fail  Failed  List of Failed

---
t\04epoch.t255 65280284  14.29%  25