You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2001/07/04 14:38:17 UTC
Re: CVS update: ADDED: subversion/libsvn_subr getdate.y
Ben wrote:
> But now win32 developers have no way of converting the .y to a .c
> file.
Perhaps this situation is most easily resolved by someone writing a
getdate parser which doesn't use yacc. Date parsing is, I think,
right on the edge of where yacc is a big complexity-saver, given how
many rough edges yacc has.
In the meantime, checking the .c file into CVS is probably
best... assuming it will even build on Windows machines.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: CVS update: ADDED: subversion/libsvn_subr getdate.y
Posted by Ben Collins-Sussman <su...@collab.net>.
Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> * Even ignoring the warnings you mentioned, the code isn't APRized,
> and I don't think it can be, if we keep generating the C file with
> yacc/byacc/bison.
APRized? It only makes system calls to <time.h>, which is part of the
ISO C library. Nothing un-portable going on.
> * Every one of these parser generators has its own quirks, and works
> a bit differently. Do we want to be tied to a particular version
> of a particular generator?
This parser comes from CVS, which compiles on every OS in the
universe, including my toaster. I'm sure they've fixed all the .y
portability problems. It probably compiles with every version of
bison and yacc that has ever existed.
> * The parser tries to recognize notations that are ambiguous, like
> the famous x/y/z: it'll parse that either as y/m/d or m/d/y, but
> what if, being from Europe, I write d/m/y? Or more likely, d.m.y,
> which isn't supported at all. On top of that, it doesn't support
> ISO 8601 format -- only the date notation.
It *does* support ISO 8601 date formats, as well as email dates (RFC
822). Look at this description from CVS:
http://cvshome.org/docs/manual/cvs_16.html#IDX240
Are you saying that it's leaving out a part of the ISO 8601 time
format? I have to go look it up...
> * Which brings up my last (but not least) objection: the parser is
> not localizable. L10n is more than just providing translations for
> messages.
Good point.
> I don't think we should support any notation that's ambiguous. I'd even
> say it's enough to support ISO 8601 [...]
I certainly wouldn't object if we told subversion users, "you must use
*only* this format to specify times".
But now subversion is exactly as good as CVS in this arena, which is
what we want for 1.0. Rewriting a date parser should probably become
a low-priority post-1.0 task, if anyone wants to bother.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: CVS update: ADDED: subversion/libsvn_subr getdate.y
Posted by Karl Fogel <kf...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> Could we at least remove support for ambiguous notations from the parser?
+1 -- I've no problem with that. Just ask that whoever does it please
notify the list about the notations removed, just in case there's a
question about what's "ambiguous". (I know, I know, there *shouldn't*
be, but you know how these things go...)
I couldn't tell if you were volunteering, Branko. Not a hint -- you
do plenty already, no need to take this one on too. But if you don't
plan to do it, could you add an item to the bite-sized tasks page
(project_tasks.html)? Thanks.
> I'm inclined to agree with Greg Hudson: It's not a good idea to plan
> on removing functionality.
Agree in general, though I think there are cases where it's justified
(for example, when the functionality being removed is not used by many
people nor scripts, and when the new behavior is a clear and
instructive error message telling people why things are different now.
In fact, I think that might be a good way to handle the unsupported
ambiguous date formats. Don't just say "invalid date format", say,
"date format no longer accepted because ambiguous, try this way
instead...".
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: CVS update: ADDED: subversion/libsvn_subr getdate.y
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>Branko �ibej <br...@xbc.nu> writes:
>
>>I think you may be taking the "supports all CVS features" promise a
>>bit too far here. By all means, let's support the features, but not
>>the misfeatures, please. When was the last time you told CVS to up -r
>>'last friday'?
>>
>
>-1. I don't think Ben has taken CVS compatibility too far at all --
>this is the sort of CVS feature we should continue to support.
>
>I have done "last friday" type queries more than once before. I know
>that Brian Fitzpatrick also has, suspect others have also enjoyed the
>convenience.
>
Hum. I stand corrected. People will do the weirdest things. :-)
>>I don't think we should support any notation that's ambiguous. I'd
>>even say it's enough to support ISO 8601
>>(http://www.cl.cam.ac.uk/~mgk25/iso-time.html,
>>http://ano2000.kpnqwest.pt/gen_8601.htm), including interval
>>notation. Things like "today" and "yesterday" are nice, but if we
>>support "last friday," we might as well know when "granny's birthday"
>>is.
>>
>
>+1 on the general principle you propose, we simply aren't reaching it
>in one step.
>
>Ideally, we would support nothing ambiguous. However, "last friday"
>is not ambiguous, whereas "xx/xx/xx" is. Now come on, "Granny's
>birthday" is not a fair example -- how is Subversion supposed to know
>who Granny is? :-)
>
O.K., how about "easter sunday" then? That's nice and deterministic. :-)
>As far as attaining the ideal goes, here is our situation right now:
>
> 1. Before Ben's change, we didn't have any date parsing at all.
>
> 2. After Ben's change, we have the date-parsing functionality that
> CVS has, which, though it certainly has its warts, is familiar
> to many people and does the right thing most of the time.
>
> 3. We do not currently have any code that satisfies the principle of
> supporting various unambiguous date formats, localizably.
>
>Granted that (3) is the ideal, I don't see why we should drop back to
>(1) just because (2) isn't absolute perfection. Let's support what we
>can right away, and feel free to improve it when we are able.
>
Could we at least remove support for ambiguous notations from the parser?
I'm inclined to agree with Greg Hudson: It's not a good idea to plan on
removing functionality.
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: CVS update: ADDED: subversion/libsvn_subr getdate.y
Posted by Karl Fogel <kf...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> I think you may be taking the "supports all CVS features" promise a
> bit too far here. By all means, let's support the features, but not
> the misfeatures, please. When was the last time you told CVS to up -r
> 'last friday'?
-1. I don't think Ben has taken CVS compatibility too far at all --
this is the sort of CVS feature we should continue to support.
I have done "last friday" type queries more than once before. I know
that Brian Fitzpatrick also has, suspect others have also enjoyed the
convenience.
> I don't think we should support any notation that's ambiguous. I'd
> even say it's enough to support ISO 8601
> (http://www.cl.cam.ac.uk/~mgk25/iso-time.html,
> http://ano2000.kpnqwest.pt/gen_8601.htm), including interval
> notation. Things like "today" and "yesterday" are nice, but if we
> support "last friday," we might as well know when "granny's birthday"
> is.
+1 on the general principle you propose, we simply aren't reaching it
in one step.
Ideally, we would support nothing ambiguous. However, "last friday"
is not ambiguous, whereas "xx/xx/xx" is. Now come on, "Granny's
birthday" is not a fair example -- how is Subversion supposed to know
who Granny is? :-)
As far as attaining the ideal goes, here is our situation right now:
1. Before Ben's change, we didn't have any date parsing at all.
2. After Ben's change, we have the date-parsing functionality that
CVS has, which, though it certainly has its warts, is familiar
to many people and does the right thing most of the time.
3. We do not currently have any code that satisfies the principle of
supporting various unambiguous date formats, localizably.
Granted that (3) is the ideal, I don't see why we should drop back to
(1) just because (2) isn't absolute perfection. Let's support what we
can right away, and feel free to improve it when we are able. If
anyone knows of a good, localizable datestring-parsing library that we
can incorporate right now (preferably one not involving a grammar
parser!), please post.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: CVS update: ADDED: subversion/libsvn_subr getdate.y
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>Perhaps this situation is most easily resolved by someone writing a
>getdate parser which doesn't use yacc. Date parsing is, I think,
>right on the edge of where yacc is a big complexity-saver, given how
>many rough edges yacc has.
>
+1
>In the meantime, checking the .c file into CVS is probably
>best... assuming it will even build on Windows machines.
>
+0
Ben Collins-Sussman wrote:
>That would be a neat project... the .y file in our tree does some
>crazy stuff, though. It understands a whole bunch of "conventional"
>date/time formats, as well as magical ones like "last friday", "next
>week", etc. I wouldn't want to rewrite that myself. [:-)]
>
Conventional for whom?
* Even ignoring the warnings you mentioned, the code isn't APRized,
and I don't think it can be, if we keep generating the C file with
yacc/byacc/bison.
* Every one of these parser generators has its own quirks, and works
a bit differently. Do we want to be tied to a particular version
of a particular generator?
* The parser tries to recognize notations that are ambiguous, like
the famous x/y/z: it'll parse that either as y/m/d or m/d/y, but
what if, being from Europe, I write d/m/y? Or more likely, d.m.y,
which isn't supported at all. On top of that, it doesn't support
ISO 8601 format -- only the date notation.
* Which brings up my last (but not least) objection: the parser is
not localizable. L10n is more than just providing translations for
messages.
I think you may be taking the "supports all CVS features" promise a bit
too far here. By all means, let's support the features, but not the
misfeatures, please. When was the last time you told CVS to up -r 'last
friday'?
I don't think we should support any notation that's ambiguous. I'd even
say it's enough to support ISO 8601
(http://www.cl.cam.ac.uk/~mgk25/iso-time.html,
http://ano2000.kpnqwest.pt/gen_8601.htm), including interval notation.
Things like "today" and "yesterday" are nice, but if we support "last
friday," we might as well know when "granny's birthday" is.
Brane
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM : <br...@acm.org> http://www.acm.org/
Re: CVS update: ADDED: subversion/libsvn_subr getdate.y
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> Ben wrote:
> > But now win32 developers have no way of converting the .y to a .c
> > file.
>
> Perhaps this situation is most easily resolved by someone writing a
> getdate parser which doesn't use yacc. Date parsing is, I think,
> right on the edge of where yacc is a big complexity-saver, given how
> many rough edges yacc has.
That would be a neat project... the .y file in our tree does some
crazy stuff, though. It understands a whole bunch of "conventional"
date/time formats, as well as magical ones like "last friday", "next
week", etc. I wouldn't want to rewrite that myself. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org