Hi Neil, (I'm redirecting this to the users list)
On Wed, Sep 16, 2009 at 14:37:32 +0000, Neil Mitchell wrote: > I think the easiest thing is for me to tackle the improvements to the > command line argument library, and a structure for darcs options, then > for some darcs person to pick up my work after and merge it with the > rest of darcs. It will take a fair while for me to improve cmdargs > (since I'm on honeymoon for 3 weeks soon), so I'll let everyone know > when it's ready. Sounds great :-) > 1) For boolean options, like summary/no-summary in whatsnew, how does > darcs choose a default value? In the flag help it doesn't say what the > default one is. If neither is specified does it pick the value out of > a preferences set? Does it have some other behaviour? This seems to be > a common pattern. I'm afraid we don't have a mechanism for dealing with default values now. We get defaults hard-coded into the business logic which makes me rather unhappy. Getting this cleaned up is going to take some work, but it definitely needs doing. My ideal would be that somehow every choice in Darcs be explicitly expressed in the core code and that defaults be handled just on a surface layer. You flip a switch and the default changes. No need to actually muck around with the internals. How things work right now is that we have a giant sum type DarcsFlag which contains all the settings. To figure out how it needs to behave, the core logic checks for the presence/absence of certain flags. I believe that what needs to happen as a first step is for this to be broken up into smaller more limited types with fewer choices, eg. Compression | NoCompression This is discussed a bit in http://bugs.darcs.net/issue1157 Note also that we have a feature request to change our current --foo, no-foo setup into a --foo={yes,no} one which you may be interested in. http://bugs.darcs.net/issue1291 One thing which may make sense to do is to assume that we have gone the route of breaking up DarcsFlag as proposed. For example, we already have a data Compression = NoCompression | GzipCompression which may simplify things. > 2) Why would anyone specify "--dont-look-for-adds" given it's the > default? Is this just a no-op there for symmetry? Or so you can > specify --look-for-adds --no-look-for-adds and restore the default > behaviour. Because they may want to override a default setting of --look-for-adds that they put either in their global or repo-specific defaults > 3) For many things such as repodir/umask it seems you are only > expecting one value. If the user specifies multiple values what > happens? Is it an error, or do you only keep the last value. It's not well defined. For example, see * http://bugs.darcs.net/issue1116 * http://bugs.darcs.net/issue1158 as examples of where this bites us. So I hope I'm not being off-putting by giving the impression that work on our flags is basically going to involve overhauling everything. It's actually (for me) a second reason to be excited about CmdArgs. I have a feeling that if we attack this the right way, we can get much cleaner darcs code out of it. It's not just about outsourcing anymore. Thanks! -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
pgpX73iFyBUM5.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
