plans for 0.0.6 release
rusty at rustcorp.com.au
Mon Jun 6 08:10:34 BST 2005
On Sat, 2005-06-04 at 11:54 +1000, Martin Pool wrote:
> On 3 Jun 2005, Rusty Russell <rusty at rustcorp.com.au> wrote:
> > On Wed, 2005-06-01 at 10:39 -0500, Nicholas Nethercote wrote:
> > > - I think the "to" syntax is horrid -- ambiguous and thus error-prone both
> > > to implement and use, and inconsistent with every other command line
> > > option in the universe. "4 to 5" might look nice and Python-ish, but
> > > Python-style syntax doesn't mix well with shell syntax.
> > >
> > > - I think using '-' as a range operator is bad. '-' is already used
> > > to introduce options (ie. -r), and also in some revision names, so why
> > > overload it with another meaning? It just makes command lines harder to
> > > parse (for humans and machines). I mentally parse "-r4-5" as "-r4 -5".
> A worse case is '-r-4' vs '-r -4'.
1) -r-4 is silly. You always know the lower bound, it's 1.
2) -r -4 is silly because if we go the namespace route, it's -r last:4
> > We went down the ":" path in netfilter for port ranges, and I've
> > regretted it ever since.
> It seems it's particularly confusing there because colon is already
> mentally associated with HOST:PORT syntax. Do you think that's the main effect?
Not really, it's used as "iptables -A FORWARD -p tcp --ports 1:4".
Colon was used because ports referred to by names can have "-" in them,
but in the vast majority of cases it just irritates newbies.
> > It is the most common mistake I make in
> > writing rules.
> What happens? You write 20-21 when you should say 20:21?
> > There is no parsing ambiguity when combined with the "<namespace>:"
> > syntax, which I think everyone quite likes.
> > > - I quite like ':' as a range operator, it works fine in Subversion. But
> > > if ':' has another use in revision names, then avoiding overloading
> > > it is a good idea.
> > : has merit because it is used in CVS and svn. CVS also uses :: to
> > indicate a collapsed range in some cases. Two -r options are used in
> > RCS.
> Two -r options would nicely avoid the debate, and they've been
> proposed in some patches. I think the main drawback is they can't
> distinguish "20-" and "-20" and "20".
"-r 20 -r now", "-r last:20" and "-r 20"?
> On the whole I think '-r A-B' is right, perhaps with ':' supported
> where it doesn't clash with the prefix form for dates and so on.
But how do you parse this?
Banning "-" in tag names is probably not a good idea (banning anything
in tag names is probably not a good idea, because of
I think the parser should be flexible in what it accepts, but there must
be a canonical form for eg. scripts to use which guaranteed protection
against people who create a tag called "tag:tag:-20.. to 7"!
I can have a go at writing something if you want, but it'll be much
slower than someone else doing it.
A bad analogy is like a leaky screwdriver -- Richard Braakman
More information about the bazaar