[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc.
From: |
Aaron Bentley |
Subject: |
Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc. |
Date: |
Wed, 21 Jul 2004 21:04:55 -0400 |
User-agent: |
Mozilla Thunderbird 0.5 (X11/20040306) |
James Blackwell wrote:
That's a lot of stuff to tack onto a revision control system, right?
Well, this is how we win the game. We make it so easy for a project to
handle every aspect of revision control (there's a lot more than just
merging cleanly), that o use anything else would be idioic. Already,
some of our compeitors, like darcs and bitkeeper, already have some of
these things in place.
I disagree here. Choice is important. When you glom everything up
together, you reduce choice, and everyone gets stuck with one solution
that fits no one perfectly. I think that changes that would enhance
Arch at the cost of hobbling other programs are not to be made lightly.
Otherwise, feel free to turn Arch into a PQM.
About the worst that you'll bump into will
look something like (but not exactly like) this:
(define mirror-locations ( '("http://siteone.com"
"http://sitetwo.com"
"http://sitethree.com")))
If that's the case, Tom should stop posting code like this:
tom> (define my-default-archive
tom> (archive-of my-default-fq-vesion))
If Tom promises we'll never see code like that example, then we can all
go home early. But that would raise the question: why go further than xl0?
See, xl0 looks like a perfect balance to me, in terms of its structure.
I agree that it's better to have one system for managing configuration
data, and I can't imagine having difficulty writing a parser for xl0.
Now, some of you may still be saying "But I don't
want to do even that much". That's absolutely fine. There's still the
front-end interface ( the hypothetical "tla add-mirror" command) for the
nondevelopers.
Here's my argument: I don't want more than xl0, because beyond that,
configuration data becomes opaque to programs. To continue with Tom's
example, if my-default-archive is defined in terms of
my-default-fq-version, I must execute the configuration statement in
order to determine the value.
Let's assume that my default-fq-version is defined as
"address@hidden/tlacontib--aba--1.3"
What should a GUI display for the value of my-default-archive?
One obvious answer is "address@hidden", but that
would be false. Since it's a computed value, it will be affected if I
change (or delete) my default-fq-version.
Okay, so we can display it like this:"(computed)
address@hidden". Now we're telling the truth, but
it's not the whole truth. We don't really know where the value came
from, and what could affect it. Now, what happens when we want to
change this value to "(computed) address@hidden"?
1. We could prohibit changing computed values. The behavour would be
correct, but users would curse us.
2. We could change the calculation: (define
my-default-archive(archive-of my-default-fq-version)+1) (Okay, that's
not real xl, but it gets the point across.) While it looks pretty dumb
in this case, I believe there are cases where this makes sense.
3. We could change the value of my-default-fq-version. This might be
the right approach, or it could be a nightmare. Depends on what
address@hidden contains. And what if
my-default-fq-version is, itself, a computed value?
4. We could change the definition to (define my-default-archive
"address@hidden")
If faced with this situation, I'd probably prompt the user: "Do you wish
to update your default version?" and pick option 3 or 4 accordingly.
But in the ideal, I think the GUI should look like this:
+-----------------------------------------------------------+
| Default version |
| address@hidden/tlacontib--aba--1.3] |
| |
| [X] Override default archive |
| address@hidden |
+-----------------------------------------------------------+
What have I done here? I've blessed the common cases, and sacrificed
fringe functionality for the sake of ease of use. There are no computed
values; either my-default-archive is assigned to a string, or it's not
defined. If it's not defined, there's a rule that conforming Arch
implementations must substitute the archive of the default version.
That rule may be implemented in whatever languages the Arch
implementation is written in, including POSIX shell, C, Furth, xl1,
Perl, Python, Haskell...
I believe this is an appropriate approch for most kinds of configuration
data. How many useful ways can there be to assign a value to
"upstream"? Isn't it better to give them first-class support than to
throw a scripting language at the problem?
For especially strange functionality, people are going to want to use
their own languages anyhow.
When you treat code as data, you make data opaque to other programs.
That reduces choice, and in some cases, forces people to execute code in
their heads in order to evaluate values. I think that for most cases,
the cost is not worth it.
And, if you think this just applies to GUIS, ask yourself how you'd deal
with it in "tla my-default-archive". Surely "tla my-default-archive
$(tla my-default-archive)" should be a no-op.
In
order to help addres this exact issue, I have created
address@hidden/tla--devo--1.3, and into that branch I have
started merging changesets from a variety of sources.
I appreciate you taking this on, and I'll do my best to support you. I
have faith in your ability to put out a 1.2.1 release that that's an
icremental, but useful improvement on 1.2.
But my feeling is that Tom's irreplaceable. Even if Tom's clone were to
wander in from the street and offer to take over, I wouldn't hand him
stuff like the backbuilder, because only Tom knows the archive format
inside out. Twice now, I've caught bugs in the backbuilder that would
not be caught by testing normal archives, because
- no one* tags into a version after committing (but it's valid).
- only larch can do an import after base-0 (but it's valid).
*except David Allouche, and he started long after I wrote the code.
Both of these came as nagging doubts long after I'd written the code in
question. There's no way I'd have seen it if someone submitted it to
me, and even Tom didn't see the deficiency in my proposed interface.
On the other hand, maybe it's a question of which invasive features are
most important. I can keep the backbuilder from going stale until Tom's
ready to look at it.
Aaron
- Re: [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., (continued)
- Re: [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Bruce Stephens, 2004/07/21
- [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Miles Bader, 2004/07/21
- Re: [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., John Meinel, 2004/07/21
- [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Miles Bader, 2004/07/21
- [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., John Meinel, 2004/07/21
- Re: [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Jan Hudec, 2004/07/22
- Re: [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Bruce Stephens, 2004/07/22
- Re: [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Jan Hudec, 2004/07/22
- [Gnu-arch-users] Re: Round II -- new language, arch, furth, etc., Stefan Monnier, 2004/07/22
Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., James Blackwell, 2004/07/21
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc.,
Aaron Bentley <=
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., James Blackwell, 2004/07/21
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Tom Lord, 2004/07/22
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Tom Lord, 2004/07/22
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Aaron Bentley, 2004/07/22
- Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Tom Lord, 2004/07/22
Re: [Gnu-arch-users] Round II -- new language, arch, furth, etc., Tom Lord, 2004/07/22