Re: Generic and multi parsers
Ok. As I've currently got it: - $class-create_parser(...) This creates a parser coderef. Straight forward so far. Now, the parameters make it more fun: If given a hash: create_parser( params = \%params, regex = qr// ); Then we assume it's a single format parser. I'll call these arguments a 'spec' from now on. A hashref of these params is, of course, a specref. If given a specref as first argument, we assume it's a list of specrefs, which will be tried in the order given. If given a hash of number = specref, for example: create_parser( 15 = \%ical15, 8 = \%ical8, ... ); Then a length mapping parser, like in DT::F::MySQL and DTF'ICal, is created. If the 'number' part isn't actually a number, i.e. label = specref, then the labels are sorted and the parser function goes through in that order. evil And maybe a hook for a callback to determine if the 'spec' is a match? /evil What about mixed numeric and string specrefs? Maybe it would be better to specify an optional match length inside the specref and just make the hash anonymous. I intend to do a code release within a few hours. It won't necessarily be complete, but it should be enough to be disparaged. My offset is -1000 so you'll have to wait until morning to be disparaged (by me). Cheers, -J
Announce: DateTime::Astro::Sunrise 0.01_01 released to CPAN
Hi All, I have just released the DateTime::Astro::Sunrise to CPAN. From the README: This module will return a DateTime Object for sunrise and sunset for a given day. To install this module type the following: perl Makefile.PL make make test make install DEPENDENCIES This module requires these other modules and libraries: DateTime.pm version 0.07 COPYRIGHT AND LICENCE Same as perl Copyright (C) 2003 Ron Hill This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
Announce: DateTime::Format::Builder 0.22 (pre)
Morning all, Wander over to http://perl.dellah.org/modules/ and have a look at DateTime::Format::Builder. It's not finished. The docs need work, it needs more tests, and it's missing some features. (And the tests to test the missing features.) I'm about to sleep and won't get a chance to play with it for quite a few hours, so patches, advice, etc. are welcome. I admit I think I got a bit carried away. =) One thing I just realised I didn't explain in the docs is the purpose of permitting specrefs to be code. That's so you can chain things if you so desire. Want it to first check via lengths, and then via 'normal' specs? Just a simple matter of composing a parser fn that calls two other parser fns. A nice touch, when implemented, that adds quite a bit of power. I do need to clean up the exceptions I throw. I throw too many. Or, feel free to send a patch (to me, or to the list; the rt.cpan.org address won't work until I upload to CPAN). cheers, -- Iain.
Re: Announce: DateTime::Format::Builder 0.22 (pre)
Hi Iain, Looks good. Kind of overwhelming, but once the synopsis is expanded that won't be an issue as much. I'm running out the door and haven't had a chance to play with it, but looking over it 2 thoughts occured to me: 1. You've removed the 'zeroes' functionality. It was useful, what was descision there? 2. I think we should have a DateTime::Format base class, and soon as the ease of writing Format class is going to lead to a proliferation. It could simply be abstract for now, and we could make it into a factory later. (but it might for example, make more sense to throw the format_datetime not implemented exception from there) 3. Builder.pm is very focused on parsing datetimes, we should comment somewhere that formats can also provide other types of parsing and formating, e.g. parse_duration, parse_recurrence, parse_interval, etc (corresponding format_) Good work. kellan On Fri, 21 Mar 2003, Iain 'Spoon' Truskett wrote: Morning all, Wander over to http://perl.dellah.org/modules/ and have a look at DateTime::Format::Builder. It's not finished. The docs need work, it needs more tests, and it's missing some features. (And the tests to test the missing features.) I'm about to sleep and won't get a chance to play with it for quite a few hours, so patches, advice, etc. are welcome. I admit I think I got a bit carried away. =) One thing I just realised I didn't explain in the docs is the purpose of permitting specrefs to be code. That's so you can chain things if you so desire. Want it to first check via lengths, and then via 'normal' specs? Just a simple matter of composing a parser fn that calls two other parser fns. A nice touch, when implemented, that adds quite a bit of power. I do need to clean up the exceptions I throw. I throw too many. Or, feel free to send a patch (to me, or to the list; the rt.cpan.org address won't work until I upload to CPAN). cheers, -- Iain.
ANNOUNCE: DateTime::TimeZone 0.10
0.10 2003-03-20 - Fixed a bug in the DateTime::TimeZone::offset_as_seconds bug when trying given a negative number that resulted in an offset that included minutes (not a whole hour). Found by Flavio Glock. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Announce: DateTime::Format::Builder 0.22 (pre)
On Fri, 21 Mar 2003, Iain 'Spoon' Truskett wrote:
Morning all,
Wander over to
http://perl.dellah.org/modules/
You wrote that in a couple of hours???
and have a look at DateTime::Format::Builder. It's not finished.
The docs need work, it needs more tests, and it's missing some features.
(And the tests to test the missing features.)
I'll try to work on this tonight.
I'm about to sleep and won't get a chance to play with it for quite a
few hours, so patches, advice, etc. are welcome.
I admit I think I got a bit carried away. =)
Yes, you did.
It looks like a great start.
I still think that using the length as a hash key could lead to unexpected behavior.
Consider:
my $new_parser = DateTime::Format::Builder-create_parser(
8 = {
params = [ qw( year month day ) ],
regex = qr/^(\d\d\d\d)(\d\d)(\d\d)$/,
zero = { hour = 0, minute = 0, second = 0 },
},
.
.
8 = {
params = [ qw( month day year ) ],
regex = qr/^(\d\d)(\d\d)(\d\d\d\d)$/,
zero = { hour = 0, minute = 0, second = 0 },
},
);
Maybe this would be safer?
{
length = 8,
params = [ qw( month day year ) ],
regex = qr/^(\d\d)(\d\d)(\d\d\d\d)$/,
zero = { hour = 0, minute = 0, second = 0 },
},
Maybe I'm just paranoid...
DateTime::Format::Builder-create_class(
class = 'DateTime::Format::MySQL',
This scares me. :) The namespace collisions could be spectacular.
--
--- Builder.pm Thu Mar 20 03:23:33 2003
+++ new.Builder.pm Thu Mar 20 13:26:09 2003
@@ -117,7 +117,8 @@
Ccreate_class is different from the other constructors. It creates a
full class for the parser, not just an instance of
-CDateTime::Format::Builder.
+CDateTime::Format::Builder. Please consider the dangers of namespace
+pollution when using this.
For example:
--
And maybe change 'Class' to 'Namespace' to be super clear about what is happening.
Cheers,
-J
Re: DateTime::Set API - constructors
Dave Rolsky wrote: How could a set of discrete datetimes also be a set of spans? Mmm, it's like 'spans with zero-duration', but maybe we just don't need that, actually. $set1 = DateTime::SpanSet-new( spans = [ $dt_span, $dt_span ] ); I think this is necessary. Ok. Maybe we don't need 'span=', since 'spans=' is good enough. $set1 = DateTime::SpanSet-new( start_set = $dt_set, end_set = $dt_set ); What would this create exactly? For example, if I have two sets, one of which is an infinite recurrence every month starting on January 1, 2002, and the other is a set with ... .. every month starting on January 2, 2002, then you get an infinite set of spans like: [ 2002-01-01..2002-01-02 ], [ 2002-02-01..2002-02-02 ], [ 2002-03-01..2002-03-02 ], and so on. That would be useful for defining recurring things like seasons, vacations, and holidays that are longer than a day (I think). - Flavio S. Glock
Re: Announce: DateTime::Format::Builder 0.22 (pre)
* Dave Rolsky ([EMAIL PROTECTED]) [21 Mar 2003 06:32]: On Thu, 20 Mar 2003 [EMAIL PROTECTED] wrote: 1. You've removed the 'zeroes' functionality. It was useful, what was descision there? Actually, it's _not_ useful. DateTime-new has defaults of 0 or 1 (as appropriate) for all the components except year, so there's no need to explicitly pass in 0 or 1 values. And I hadn't removed it. =) That said, it is now 'extras', as per Dave's other email. I'll be mentioning 'truncate' in the 'extras' documentation since that seems appropriate? (Hmm. Does the current DateTime on CPAN have truncate? If not, when's the next DateTime release?) [...] 3. Builder.pm is very focused on parsing datetimes, Yes. It's the primary use case. we should comment somewhere that formats can also provide other types of parsing and formating, e.g. parse_duration, parse_recurrence, parse_interval, etc (corresponding format_) Maybe. I think Builder will grow as we find similarities between existing modules. In fact, that's pretty much the _only_ way it can grow, because until we find these similarities, we don't know how to make a decent Builder API! Correct! I vaguely hinted at having support for formatters. But I've not gotten that far yet (hence the 'abstract' method). I've seen some of them tend to be using strftime (or an equivalent combination of methods), so that seems a logical starting point. And I'll be adding Dave's bit about specifying methods and their parsers, so that should help. Once done with datetimes, I'll do durations, then the others. If someone gives me a section of documentation about the comment somewhere that formats [...] thing, I'll gleefully add it. Thanks for your comments, Kellan. Nicely inspiring and much appreciated. cheers, -- Iain.
Re: DateTime::Set API - constructors
Dave Rolsky wrote: $set1 = DateTime::SpanSet-new( start_set = $dt_set, end_set = $dt_set ); What would this create exactly? This is the same thing, but with another syntax (I prefer this one): $set_start = new DateTime::Set( $day1, $day3 ); $set_end = new DateTime::Set( $day2, $day4 ); $spanset = $set_start-until( $set_end ); It creates this DateTime::SpanSet: [ $day1 .. $day2 ) , [ $day3 .. $day4 ) meaning: a time-span that starts in day1 and ends before day2, then restarts in day3 and ends before day4. - set_start and set_end can be recurrences. - Flavio S. Glock
Re: DateTime::Set API - constructors
On Thu, 20 Mar 2003 [EMAIL PROTECTED] wrote: Dave Rolsky wrote: $set1 = DateTime::SpanSet-new( start_set = $dt_set, end_set = $dt_set ); What would this create exactly? This is the same thing, but with another syntax (I prefer this one): $set_start = new DateTime::Set( $day1, $day3 ); $set_end = new DateTime::Set( $day2, $day4 ); $spanset = $set_start-until( $set_end ); It creates this DateTime::SpanSet: [ $day1 .. $day2 ) , [ $day3 .. $day4 ) meaning: a time-span that starts in day1 and ends before day2, then restarts in day3 and ends before day4. - set_start and set_end can be recurrences. Woah, this is asking for trouble. What if one set has 3 elements and the other 2? Or what if one is infinite and one isn't? There might be some logical way to handle this but I think it'll get way too confusing for most users way too fast, leading to bugs. I think the API needs to be simple and encourage simplicity in its use, because this is a complicated area. It's much simpler to simply have people make a bunch of DateTime::Span objects and have them pass it in. Alternately, we might accept a list of pairs of objects. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Timezone doesn't pass tests
On Thu, 20 Mar 2003 [EMAIL PROTECTED] wrote: DateTime::Timezone from CVS doesn't pass tests: t/02basic.t - there is no method all_names (although it is in the docs) t/03link.t - seems like it can't find 'America/Chicago' You have to run tools/parse_olson in order to generate the individual time zones modules and DateTime::TimeZoneCatalog. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Announce: DateTime::Format::Builder 0.22 (pre)
* Dave Rolsky ([EMAIL PROTECTED]) [21 Mar 2003 06:55]:
How about changing zero to extra or something like that, just to
indicate that it's for generic extra parameters. [...]
Check!
The correct_years parameter should probably go away. It's _way_ too
specific to one format (MySQL).
Well, any format that has two digit years. Still, abolished.
Instead I think there needs to be a post-process callback allowed,
something that gets the paramaters _and_ the original string being
parsed, and is expected to return the parameters, along with any
modifications. This could probably just be the on_match callback.
Hmm. Yes. No. Yes. No. I'd like for on_match to be able to happen
without having to return anything.
The create_class() method needs to be able to create multiple methods in
the new class. So something like this maybe:
[...]
parsers =
{ parse_datetime = { specs },
parse_date = { specs },
...
}
I like it. Though it will be:
parsers = {
parse_datetime = [ specs ],
parse_date = [ specs ],
},
as I'm dropping hash form. Though it would be accepting:
parse_datetime = { spec },
aka parse_datetime = specref,
Does create_parser() have to be recursive? It seems too clever to me.
I have a tendency to think recursively. 'Fixed' =)
And it makes that one method too long. I think it could be moved into
several different methods, and that'd make the code much clearer. I
expect that this area will probably expand in the future.
Yes. The 'simple' case is now its own method, and the more complex ones
are either being completely modified or dropped.
Bare in mind that 0.22 was just what I wrote before any sort of
refactoring. I generally need a decent sized break before refactoring,
to clear my head of any assumptions (one of the useful things about
having a bad memory). That said, I happily accept your criticism.
I'm not sure why you look at the return value of on_match and on_fail.
It's not documented anywhere.
Due to other changes it was dropped. There was a reason, it doesn't
matter now =)
In general, it looks good. I'm a bit concerned about its dual nature,
though, in that in can be used directly by users as well as module
authors. I think this could be made more palatable by re-arranging the
docs a bit and clearly separating them into FOR END USERS and FOR
DateTime::Format MODULE AUTHORS, in that order.
I'm still thinking it's mostly for module authors rather than end users.
It just looks the other way due to the order in which it was written =)
Though I can see why and how end users could use it. Hmm.
Check.
[...]
I do appreciate these notes. You've got a good sense of design, Dave.
Expect an interim release at some point tonight.
Somewhere around TZID=Australia/Sydney:20030321T23
Or earlier. When I've got to another stage.
cheers,
--
Iain.
Re: Announce: DateTime::Format::Builder 0.22 (pre)
On Fri, 21 Mar 2003, Iain 'Spoon' Truskett wrote: The correct_years parameter should probably go away. It's _way_ too specific to one format (MySQL). Well, any format that has two digit years. Still, abolished. Yeah, but others may treat 0-79 as 2000 and 80-00 as 1900, and so on. That was what was too specific. Instead I think there needs to be a post-process callback allowed, something that gets the paramaters _and_ the original string being parsed, and is expected to return the parameters, along with any modifications. This could probably just be the on_match callback. Hmm. Yes. No. Yes. No. I'd like for on_match to be able to happen without having to return anything. Ok, but it seems like some sort of post-processing feature might be good. Bare in mind that 0.22 was just what I wrote before any sort of refactoring. I generally need a decent sized break before refactoring, to clear my head of any assumptions (one of the useful things about having a bad memory). That said, I happily accept your criticism. That's cool. That's what code review's for, right? ;) One more thing. I think the create_class method should simply use the package name of its caller, rather than take one explicitly, and should probably be renamed create_methods. It's going to be used by format module writers who'll do: package DateTime::Format::Gobbledygook; use DateTime::Format::Builder; DateTime::Format::Builder-create_methods( ... ); -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Announce: DateTime::Format::Builder 0.22 (pre)
I like it. Though it will be:
parsers = {
parse_datetime = [ specs ],
parse_date = [ specs ],
},
as I'm dropping hash form. Though it would be accepting:
parse_datetime = { spec },
aka parse_datetime = specref,
My original suggestion was an array of hashes. So you'll listen to Dave but not me
huh?
I don't blame you. :)
-J
--
