Re: infinity stringification bug in Perl 5.9.0?
On Wed, Sep 03, 2003 at 11:23:44PM +, [EMAIL PROTECTED] wrote: I've got a report that Perl 5.9.0 stringifies infinity and minus infinity with extra spaces, like this: -Inf Inf Is this a bug? Works correctly for me. What do perl -V and perl -V:d_Gconvert say for the offending perl?
Re: DateTime::Set - Number of elements in set
Flavio S. Glock wrote: Sets of type 4 are 'huge sets'. These have an 'unknown' count. The count can be thousands or even millions of dates, but it is not infinite. - or two or three - Before version 0.10, you would run out of memory if you specified something like all seconds in the century. Now, the program will just go on normally - it creates a 'huge set'. And it doesn't attempt to count the set elements. Would there be some way we could 'guess' if it's loo large to count? Or maybe if a count is requested, we count 10,000 and then return undef if there's more? I'm thinking there would be a lot of recurrences such as 'every tuesday' with restraints such as 'in 2003'. This is easily countable and probably useful. The 'guess' part would be to look at the recurrence and check it's 'density'. With the occurrence above, the density is 1/week. Given a start and end date, we could calculate this for a large number of years. Lets say this module doesn't return counts over 10,000. We build in yearly guestimates for our density denominators. The week guestimate is 52. So we can count the elements for (range as years in float)/52 recurrences. If we have a recurrence of 'every second' then the yearly guestimate is 60*60*24*356.25. Now we can take our (range as years in float) and divide it by our yearly guestimate. If the result is over 10,000 we return undef. While all this is a heap of code, we can quickly see if it's worth counting the actual occurrences. ALSO If we go this path or not, I'd prefer not to get plain undef back. I'd like an indication that it was 'too hard to count', or that it was 'over 10,000'. Cheers! Rick
Re: Set modules - Perl 5.005_03
+-le 02/09/2003 10:20 -0300, Flavio S. Glock écrivait : | The 'Set' modules now run with Perl 5.005_03. | | If you have access to DateTime CVS, you can update the following | modules: | | - Set::Infinite | - DateTime::Event::Recurrence | - DateTime::Event::ICal I'll add DateTime::Format::ICal to the list of the ones which don't work :) Attached a make test :) -- Mathieu Arnold out Description: Binary data
Re: DateTime::Set - Number of elements in set
Rick Measham wrote: Flavio S. Glock wrote: Sets of type 4 are 'huge sets'. These have an 'unknown' count. The count can be thousands or even millions of dates, but it is not infinite. - or two or three - Two or three are ok :) Before version 0.10, you would run out of memory if you specified something like all seconds in the century. Now, the program will just go on normally - it creates a 'huge set'. And it doesn't attempt to count the set elements. Would there be some way we could 'guess' if it's loo large to count? Or maybe if a count is requested, we count 10,000 and then return undef if there's more? That's the way it works, kind of. I set the count limit to 200 elements. This seems to fit most practical uses. I'm thinking there would be a lot of recurrences such as 'every tuesday' with restraints such as 'in 2003'. This is easily countable and probably useful. No problem with this, it's below the limit. The 'guess' part would be to look at the recurrence and check it's 'density'. With the occurrence above, the density is 1/week. Given a start and end date, we could calculate this for a large number of years. Lets say this module doesn't return counts over 10,000. We build in yearly guestimates for our density denominators. The week guestimate is 52. So we can count the elements for (range as years in float)/52 recurrences. If we have a recurrence of 'every second' then the yearly guestimate is 60*60*24*356.25. Now we can take our (range as years in float) and divide it by our yearly guestimate. If the result is over 10,000 we return undef. While all this is a heap of code, we can quickly see if it's worth counting the actual occurrences. That's a good idea, but some sets have a variable density, such as friday-13. ALSO If we go this path or not, I'd prefer not to get plain undef back. I'd like an indication that it was 'too hard to count', or that it was 'over 10,000'. That would be ok, can you suggest an API? Is it ok to die with a message? - Flavio S. Glock
Re: Set modules - Perl 5.005_03
Dave: Can you check these failures? t/02duration..NOK 43# Failed test (t/02duration.t at line 92) t/02duration..NOK 49# Failed test (t/02duration.t at line 99) # got: '+P4W2D' # expected: '-P4W2D' (DateTime::Format::ICal, Perl 5.00503) The other failing tests are already fixed - they were due to differences in 'hash ordering' between versions. (install DateTime-Event-ICal 0.06, in CVS CPAN) - Flavio S. Glock Mathieu Arnold wrote: I'll add DateTime::Format::ICal to the list of the ones which don't work :) Attached a make test :)
Re: Set modules - Perl 5.005_03
+-le 04/09/2003 10:48 -0300, Flavio S. Glock écrivait : | Dave: | | Can you check these failures? | | t/02duration..NOK 43# Failed test (t/02duration.t at line 92) | | t/02duration..NOK 49# Failed test (t/02duration.t at line 99) | # got: '+P4W2D' | # expected: '-P4W2D' | (DateTime::Format::ICal, Perl 5.00503) Still the same with Set-Infinite 0.53 and DTE::ICal 0.06. -- Mathieu Arnold
Re: Set modules - Perl 5.005_03
Ok, I found the problem - I'll fix it. - Flavio S. Glock Mathieu Arnold wrote: +-le 04/09/2003 10:48 -0300, Flavio S. Glock écrivait : | Dave: | | Can you check these failures? | | t/02duration..NOK 43# Failed test (t/02duration.t at line 92) | | t/02duration..NOK 49# Failed test (t/02duration.t at line 99) | # got: '+P4W2D' | # expected: '-P4W2D' | (DateTime::Format::ICal, Perl 5.00503) Still the same with Set-Infinite 0.53 and DTE::ICal 0.06.
Re: DateTime::Set - Number of elements in set
On Tue, 3 Sep 2003, Rick Measham wrote:
ALSO If we go this path or not, I'd prefer not to get plain undef back.
I'd like an indication that it was 'too hard to count', or that it was
'over 10,000'.
But undef means unknown, and if we can't count, we don't know how many
elements are in the set. We certainly can't return a number, and we can't
return a string or object because then people will do:
if ( my $count = $set-count ) { ... }
and that would succeed. So that leaves undef or an exception. It seems
silly to throw an exception here, and in fact I really don't like the idea
of accessor methods throwing exceptions.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
ANNOUNCE: DateTime::Format::ICal 0.08
0.08 2003-09-04 - Negative durations were formatted as positive with Perl 5.00503. Fixed by Flavio Glock. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Problem with DateTime::Format::DateManip v0.01
Hi, Thanks to Eugene for fixing up a new release of DateTime::Calendar::Pataphysical - that works (for me, anyway). I'm having consistent problems with DateTime::Format::DateManip v0.01, on both Solaris 8 and MacOS X 10.2.6 with Perl 5.8.1. Extracting DateTime-Format-DateManip-0.01/README Running [/usr/perl/v5.8.1/bin/perl Build.PL]... Checking whether your kit is complete... Looks good Creating new 'Build' script for 'DateTime-Format-DateManip' version '0.01' Running [/usr/perl/v5.8.1/bin/perl Build UNINST=1]... *** ERROR: unterminated C... at line 313 in file blib/lib/DateTime/Format/DateManip.pm lib/DateTime/Format/DateManip.pm - blib/lib/DateTime/Format/DateManip.pm Manifying blib/lib/DateTime/Format/DateManip.pm - blib/libdoc/DateTime::Format::DateManip.3 Running [/usr/perl/v5.8.1/bin/perl Build UNINST=1 test]... t/00load...ok t/01conversions# Failed test (t/01conversions.t at line 69) # got: '2003032300:00:00' # expected: '2003032303:00:00' # Failed test (t/01conversions.t at line 69) # got: '2003032312:00:00' # expected: '2003032315:00:00' # Looks like you failed 2 tests of 6. dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 3-4 Failed 2/6 tests, 66.67% okay Failed Test Stat Wstat Total Fail Failed List of Failed t/01conversions.t2 512 62 33.33% 3-4 Failed 1/2 test scripts, 50.00% okay. 2/7 subtests failed, 71.43% okay. I don't know if it is significant that I'm running in US/Pacific time zone, which is 3 hours adrift from US/Eastern - it doesn't seem to be that simple as running with TZ=US/Eastern does not alter the answers. -- Jonathan Leffler #include disclaimer.h STSM, Informix Database Engineering, IBM Data Management Phone: +1 650-926-6921 Fax: +1 650-926-6971 Tie-line: 630-6921 Email: [EMAIL PROTECTED] Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org
Re: Problem with DateTime::Format::DateManip v0.01
On Thu, 4 Sep 2003, Jonathan Leffler wrote: I don't know if it is significant that I'm running in US/Pacific time zone, which is 3 hours adrift from US/Eastern - it doesn't seem to be that simple as running with TZ=US/Eastern does not alter the answers. It's probably that simple. Simply setting the TZ env var probably won't do much. An app has to call POSIX::tzset() for that take effect. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Problem with DateTime::Format::DateManip v0.01
On Thu, 4 Sep 2003, Dave Rolsky wrote: On Thu, 4 Sep 2003, Jonathan Leffler wrote: I don't know if it is significant that I'm running in US/Pacific time zone, which is 3 hours adrift from US/Eastern - it doesn't seem to be that simple as running with TZ=US/Eastern does not alter the answers. It's probably that simple. Simply setting the TZ env var probably won't do much. An app has to call POSIX::tzset() for that take effect. I take it back. The real problem is that Date::Manip doesn't parse time zone offsets when given an ical format datetime. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Problem with DateTime::Format::DateManip v0.01
On Thursday, September 4, 2003, at 12:53 PM, Dave Rolsky wrote:
It's probably that simple. Simply setting the TZ env var probably
won't
do much. An app has to call POSIX::tzset() for that take effect.
I find that for most date and time handling I do, just setting $ENV{TZ}
does the trick -- except perhaps on Debian. Are you saying that if I
want the setting of TZ to portably affect, e.g., localtime, that I need
to always POSIX::tzset() after I do it? Seems a waste to load all of
POSIX.pm just for that...
Cheers,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Kineticode. Setting knowledge in motion.[sm]
