Re: [darcs-users] Darcs utterly melts my brain: why PatchInfoAnd?
Florent Becker [EMAIL PROTECTED] writes: Le 30 sept. 08 à 23:30, Eric Kow a écrit : On Tue, Sep 30, 2008 at 22:27:24 +0100, Eric Kow wrote: Fast-tracking. On second thought, you have some haddock errors (nothing which prevents haddocking). Would you like to submit a cleaned-up version? I'm still willing to just go ahead and apply it, on the grounds that somebody else can clean up afterwards. Here is an updated version, which only complains that it cannot find the documentation for the base library, which i don't have on my system. What is the error you're seeing? I found out what was happening: the C(x y) macro was messing with haddock strings. Here is a corrected version. This yields a question: do we want the C(x y) to appear in the api-doc. They don't appear in the automatically-generated parts of the html, but they do appear in the code, so there has to be a discrepancy somewhere. Florent Wed Oct 1 10:13:15 CEST 2008 [EMAIL PROTECTED] * haddock documentation for Hopefully New patches: [haddock documentation for Hopefully [EMAIL PROTECTED] hunk ./src/Darcs/Hopefully.lhs 43 +-- | @'Hopefully' p C@ @(x y)@ is @'Either' String (p C@ @(x y))@ in a +-- form adapted to darcs patches. The @C@ @(x y)@ represents the type +-- witness for the patch that should be there. The @Hopefully@ type +-- just tells whether we expect the patch to be hashed or not, and +-- 'SimpleHopefully' does the real work of emulating +-- 'Either'. @Hopefully sh@ represents an expected unhashed patch, and +-- @Hashed hash sh@ represents an expected hashed patch with its hash. hunk ./src/Darcs/Hopefully.lhs 52 +-- | @SimpleHopefully@ is a variant of @Either String@ adapted for +-- type witnesses. @Actually@ is the equivalent of @Right@, while +-- @Unavailable@ is @[EMAIL PROTECTED] hunk ./src/Darcs/Hopefully.lhs 57 +-- | @'PatchInfoAnd' p C(a b)@ represents a hope we have to get a +-- patch through its info. We're not sure we have the patch, but we +-- know its info. hunk ./src/Darcs/Hopefully.lhs 74 - +-- | @returnH@ is the equivalent of @return@ in the @Either String@ monad. hunk ./src/Darcs/Hopefully.lhs 78 +-- | @=@ is a version of @=@ which accounts for type witnesses +-- (i. e. contexts) hunk ./src/Darcs/Hopefully.lhs 86 + +-- | @@ is a version of @@ which accounts for type witnesses +-- (i. e. contexts) hunk ./src/Darcs/Hopefully.lhs 95 + +-- | @fmapH@ is a version of @fmap@ which accounts for type witnesses +-- (i. e. contexts) hunk ./src/Darcs/Hopefully.lhs 104 +-- | @'piap' i p@ creates a PatchInfoAnd containing p with info i. hunk ./src/Darcs/Hopefully.lhs 108 +-- | @n2pia@ creates a PatchInfoAnd represeting a @Named@ patch. hunk ./src/Darcs/Hopefully.lhs 115 +-- | @'hopefully' hp@ tries to get a patch from a 'PatchInfoAnd' +-- value. If it fails, it outputs an error \failed to read patch: +-- \description of the patch\. We get the description of the patch +-- from the info part of 'hp' hunk ./src/Darcs/Hopefully.lhs 122 +-- | @'conscientiously' er hp@ tries to extract a patch from a 'PatchInfoAnd'. +-- If it fails, it applies the error handling function @er@ to a description +-- of the patch info component of @[EMAIL PROTECTED] hunk ./src/Darcs/Hopefully.lhs 132 +-- | @hopefullyM@ is a version of @hopefully@ which calls @fail@ in a +-- monad instead of erroring. Context: [generate a tidier hoogle frame, add required files, simplify framed doc generation Simon Michael [EMAIL PROTECTED]**20080930204518 Ignore-this: e60b456f1fdd001b5ae456f9aae05999 ] [make installdocs should not install TeX intermediaries. Trent W. Buck [EMAIL PROTECTED]**20080930030315 I'm unilaterally classing the DVI and PostScript versions as intermediaries to the PDF version, and only installing the latter. ] [Add test cases for issue1043. Eric Kow [EMAIL PROTECTED]**20080930105032 There are two known variants, one of which was fixed by resolve issue1043: fix bug in mergeAfterConflicting. ] [resolve issue1043: fix bug in mergeAfterConflicting. David Roundy [EMAIL PROTECTED]**20080926211928 Ignore-this: 1416605539b44b32c18b348f3b4f459d This is moderately deep in the internals of the darcs-2 conflict handling code. I had made an assumption that turned out not to be correct. I fix this by switching to use a variant of the commute function that doesn't allow conflicting patches to commute, which I think should restore correctness here. It's a scary bug, though, and if anyone were to create a moderately small test case, I'd be extremely grateful. ] [add test that show bug works right. David Roundy [EMAIL PROTECTED]**20080929152909 Ignore-this: 4829e300015120adeed108079324e5e2 ] [Add a test case for issue1110. Eric Kow [EMAIL PROTECTED]**20080929151743] [Tone down unnecessarily scary language when cancelling Simon Michael [EMAIL PROTECTED]**20080928004013 Ignore-this: c5940d14099953b7bc963c70591739d1 ] [darcshoogle script and emacs integration example Simon Michael [EMAIL PROTECTED]**20080927210609
[darcs-users] patch: haddockification of Arguments.lhs
It's partial, but I believe the most important part are there. Is the --^ syntax ok? I feel it does add clarity where I have used it. Florent Wed Oct 1 10:13:15 CEST 2008 [EMAIL PROTECTED] * haddock documentation for Hopefully New patches: [haddock documentation for Hopefully [EMAIL PROTECTED] hunk ./src/Darcs/Hopefully.lhs 43 +-- | @'Hopefully' p C@ @(x y)@ is @'Either' String (p C@ @(x y))@ in a +-- form adapted to darcs patches. The @C@ @(x y)@ represents the type +-- witness for the patch that should be there. The @Hopefully@ type +-- just tells whether we expect the patch to be hashed or not, and +-- 'SimpleHopefully' does the real work of emulating +-- 'Either'. @Hopefully sh@ represents an expected unhashed patch, and +-- @Hashed hash sh@ represents an expected hashed patch with its hash. hunk ./src/Darcs/Hopefully.lhs 52 +-- | @SimpleHopefully@ is a variant of @Either String@ adapted for +-- type witnesses. @Actually@ is the equivalent of @Right@, while +-- @Unavailable@ is @[EMAIL PROTECTED] hunk ./src/Darcs/Hopefully.lhs 57 +-- | @'PatchInfoAnd' p C(a b)@ represents a hope we have to get a +-- patch through its info. We're not sure we have the patch, but we +-- know its info. hunk ./src/Darcs/Hopefully.lhs 74 - +-- | @returnH@ is the equivalent of @return@ in the @Either String@ monad. hunk ./src/Darcs/Hopefully.lhs 78 +-- | @=@ is a version of @=@ which accounts for type witnesses +-- (i. e. contexts) hunk ./src/Darcs/Hopefully.lhs 86 + +-- | @@ is a version of @@ which accounts for type witnesses +-- (i. e. contexts) hunk ./src/Darcs/Hopefully.lhs 95 + +-- | @fmapH@ is a version of @fmap@ which accounts for type witnesses +-- (i. e. contexts) hunk ./src/Darcs/Hopefully.lhs 104 +-- | @'piap' i p@ creates a PatchInfoAnd containing p with info i. hunk ./src/Darcs/Hopefully.lhs 108 +-- | @n2pia@ creates a PatchInfoAnd represeting a @Named@ patch. hunk ./src/Darcs/Hopefully.lhs 115 +-- | @'hopefully' hp@ tries to get a patch from a 'PatchInfoAnd' +-- value. If it fails, it outputs an error \failed to read patch: +-- \description of the patch\. We get the description of the patch +-- from the info part of 'hp' hunk ./src/Darcs/Hopefully.lhs 122 +-- | @'conscientiously' er hp@ tries to extract a patch from a 'PatchInfoAnd'. +-- If it fails, it applies the error handling function @er@ to a description +-- of the patch info component of @[EMAIL PROTECTED] hunk ./src/Darcs/Hopefully.lhs 132 +-- | @hopefullyM@ is a version of @hopefully@ which calls @fail@ in a +-- monad instead of erroring. Context: [generate a tidier hoogle frame, add required files, simplify framed doc generation Simon Michael [EMAIL PROTECTED]**20080930204518 Ignore-this: e60b456f1fdd001b5ae456f9aae05999 ] [make installdocs should not install TeX intermediaries. Trent W. Buck [EMAIL PROTECTED]**20080930030315 I'm unilaterally classing the DVI and PostScript versions as intermediaries to the PDF version, and only installing the latter. ] [Add test cases for issue1043. Eric Kow [EMAIL PROTECTED]**20080930105032 There are two known variants, one of which was fixed by resolve issue1043: fix bug in mergeAfterConflicting. ] [resolve issue1043: fix bug in mergeAfterConflicting. David Roundy [EMAIL PROTECTED]**20080926211928 Ignore-this: 1416605539b44b32c18b348f3b4f459d This is moderately deep in the internals of the darcs-2 conflict handling code. I had made an assumption that turned out not to be correct. I fix this by switching to use a variant of the commute function that doesn't allow conflicting patches to commute, which I think should restore correctness here. It's a scary bug, though, and if anyone were to create a moderately small test case, I'd be extremely grateful. ] [add test that show bug works right. David Roundy [EMAIL PROTECTED]**20080929152909 Ignore-this: 4829e300015120adeed108079324e5e2 ] [Add a test case for issue1110. Eric Kow [EMAIL PROTECTED]**20080929151743] [Tone down unnecessarily scary language when cancelling Simon Michael [EMAIL PROTECTED]**20080928004013 Ignore-this: c5940d14099953b7bc963c70591739d1 ] [darcshoogle script and emacs integration example Simon Michael [EMAIL PROTECTED]**20080927210609 Ignore-this: 93d5a0ff269d314d32f213dfbe4325be ] [Fix doubled verb `be' in documentation on apply posthooks in _darcs/prefs/defaults. Taylor R Campbell [EMAIL PROTECTED]**20080928200954] [the issue864 test was misnamed Simon Michael [EMAIL PROTECTED]**20080928231942 Ignore-this: a0b643bf0abc6f4b6237e5683e9f6dad ] [add tests for pull --union and --intersection. David Roundy [EMAIL PROTECTED]**20080929150711 Ignore-this: 356f506f79ca89a2d1246d068aaa8b2b --intersection fails, which is issue. ] [add more output to URL bug message. David Roundy [EMAIL PROTECTED]**20080929145544 Ignore-this: 868e0ba5819dba2a4f5b8819080e9407 I triggered this bug a few times, but once I added the extra output, I wasn't able to do it again. So I'm leaving the extra information in the bug
Re: [darcs-users] Darcs utterly melts my brain: why PatchInfoAnd?
On Wed, Oct 01, 2008 at 10:28:02 +0200, Florent Becker wrote: This yields a question: do we want the C(x y) to appear in the api-doc. They don't appear in the automatically-generated parts of the html, but they do appear in the code, so there has to be a discrepancy somewhere. Hmm, I think this may not be the best place to put the contexts: the 'function' @arg1 arg2@ does foo comments tell us what happens when we pass particular objects (err, what's the right word to use here?) to functions. Putting type arguments in there is bound to confuse somebody, me at least ;-) 'function' @arg1 String arg2@ does foo -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 signature.asc Description: Digital signature ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] patch: haddockification of Arguments.lhs
On Wed, Oct 01, 2008 at 10:31:06 +0200, Florent Becker wrote: It's partial, but I believe the most important part are there. Is the --^ syntax ok? I feel it does add clarity where I have used it. Did you send the wrong bundle? In a previous message, David said that he would prefer avoiding the --^ syntax on specific arguments because it makes it harder to read the type signatures. So we should use it sparingly. For sure, there may be cases that call for it though, for example, but we should avoid it if it is already self-evident from from the type signature and the comment. -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 signature.asc Description: Digital signature ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
[darcs-users] Solaris/x86 buildbot update (ghc 6.8.3 + maybench)
Hi, just a short note: I've updated Solaris/x86 buildbot to GHC 6.8.3 and also installed maybench as Eric requested in the past. Cheers, Karel ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] Solaris/x86 buildbot update (ghc 6.8.3 + maybench)
On Wed, Oct 01, 2008 at 11:22:21 +0200, Karel Gardas wrote: just a short note: I've updated Solaris/x86 buildbot to GHC 6.8.3 and also installed maybench as Eric requested in the past. Thanks! Once darcs 2.1 is released, I hope to have a little bit more time to look at the performance numbers. -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 signature.asc Description: Digital signature ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] Darcs utterly melts my brain: why PatchInfoAnd?
Eric Kow a écrit : On Wed, Oct 01, 2008 at 10:28:02 +0200, Florent Becker wrote: This yields a question: do we want the C(x y) to appear in the api-doc. They don't appear in the automatically-generated parts of the html, but they do appear in the code, so there has to be a discrepancy somewhere. Hmm, I think this may not be the best place to put the contexts: the 'function' @arg1 arg2@ does foo comments tell us what happens when we pass particular objects (err, what's the right word to use here?) to functions. Putting type arguments in there is bound to confuse somebody, me at least ;-) 'function' @arg1 String arg2@ does foo I was documenting a type application, so it _is_ code you would find in the source. I wrote 'Hopefully p C(x y)' is equivalent to 'Either String (p C(x y))'. (or did I do a typo and put Cs in a function?) ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] patch: haddockification of Arguments.lhs
Eric Kow a écrit : By the way, why not use darcs send? If it's just not working for you, we may have an interesting use case of darcs send not being good enough. Both you and zooko being affected by this must surely be a bad sign. I don't use darcs send for three reasons: -1/ I'm a lazy and dumb and I don't know how to configure mac OS X to get send working -2/ This way I can reply to threads with patches. -3/ Editing the mail in a aquamacs is more comfortable for me than in vim (I don't know how to give $EDITOR a sensible value on mac OS X) 1' on linux is I'm not sure how to check my mua /did/ send the patches. Florent ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] Darcs utterly melts my brain: why PatchInfoAnd?
On Wed, Oct 01, 2008 at 11:35:57 +0200, Florent Becker wrote: I was documenting a type application, so it _is_ code you would find in the source. Doh! My apologies. I shouldn't be doing this with half-attention, sorry. I wrote 'Hopefully p C(x y)' is equivalent to 'Either String (p C(x y))'. (or did I do a typo and put Cs in a function?) By the way, why not Hopefully (p C(x y))? -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 signature.asc Description: Digital signature ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] patch: haddockification of Arguments.lhs
Eric Kow [EMAIL PROTECTED] writes: On Wed, Oct 01, 2008 at 10:31:06 +0200, Florent Becker wrote: It's partial, but I believe the most important part are there. Is the --^ syntax ok? I feel it does add clarity where I have used it. Did you send the wrong bundle? Oops, it looks like I did. Here is the correct one. Wed Oct 1 10:18:59 CEST 2008 [EMAIL PROTECTED] * Partial haddock documentation for Darcs.Arguments New patches: [Partial haddock documentation for Darcs.Arguments [EMAIL PROTECTED] hunk ./src/Darcs/Arguments.lhs 127 +-- | 'get_content' returns the content of a flag, if any. +-- For instance, the content of @Author \Louis Aragon\@ is @StringContent +-- \Louis Aragon\@, while the content of @Pipe@ is @NoContent@ hunk ./src/Darcs/Arguments.lhs 286 +-- | @a `'isa'` b@ tests wether @a@ is flag @b@ with a string argument. +-- @b@ typically is a Flag constructor expecting a string +-- For example, @(Author \Ted Hughes\) `isa` Author@ returns true. hunk ./src/Darcs/Arguments.lhs 294 +-- | @a `'isAnAbsolute'` b@ tests wether @a@ is flag @b@ with an absolute path argument. +-- @b@ typically is a Flag constructor expecting an absolute path argument +-- For example, @(Context contextfile) `isAnAbsolute` Context@ returns true. hunk ./src/Darcs/Arguments.lhs 302 +-- | @a `'isAnAbsoluteOrStd'` b@ tests wether @a@ is flag @b@ with a path argument. +-- @b@ typically is a Flag constructor expecting a path argument +-- For example, @(Output o) `isAnAbsoluteOrStd` @ returns true. hunk ./src/Darcs/Arguments.lhs 310 +-- | A type for darcs' options. The value contains the command line +-- switch(es) for the option, a help string, and a function to build a +-- @DarcsFlag@ from the command line arguments. for each constructor, +-- 'shortSwitches' represents the list of short command line switches +-- which invoke the option, longSwitches the list of long command line +-- switches, optDescr the description of the option, and argDescr the description +-- of its argument, if any. mkFlag is a function which makes a @DarcsFlag@ from +-- the arguments of the option. hunk ./src/Darcs/Arguments.lhs 320 +-- ^ @DarcsArgOption shortSwitches longSwitches mkFlag ArgDescr OptDescr@ +-- The constructor for options with a string argument, such as +-- @--tag@ + hunk ./src/Darcs/Arguments.lhs 325 -| DarcsAbsPathOrStdOption [Char] [String] (AbsolutePathOrStd - DarcsFlag) String String +-- ^ @DarcsAbsPathOption shortSwitches longSwitches mkFlag ArgDescr OptDescr@ +-- The constructor for option with an absolute path argument, such as +-- @--sibling@ + +| DarcsAbsPathOrStdOption [Char] [String] (AbsolutePathOrStd - DarcsFlag) String String +-- ^ @DarcsAbsPathOrStdOption shortSwitches longSwitches mkFlag ArgDescr OptDescr@ +-- The constructor for options with a path argument, such as @-o@ + hunk ./src/Darcs/Arguments.lhs 334 +-- ^ @DarcsOptAbsPathOrStdOption shortSwitches longSwitches defaultPath +-- mkFlag ArgDescr OptDescr@ where defaultPath is a default value +-- for the Path, as a string to be parsed as if it had been given +-- on the command line. +-- The constructor for options with an optional path argument, such as @-O@ + hunk ./src/Darcs/Arguments.lhs 341 +-- ^ @DarcsNoArgOption shortSwitches longSwitches mkFlag optDescr@ +-- The constructon fon options with no arguments. hunk ./src/Darcs/Arguments.lhs 344 +-- ^ A constructor for grouping related options together, such as +-- @--hashed@, @--darcs-2@ and @[EMAIL PROTECTED] + hunk ./src/Darcs/Arguments.lhs 355 +-- | 'concat_option' creates a DarcsMultipleChoicOption from a list of +-- option, flattening any DarcsMultipleChoiceOption in the list. hunk ./src/Darcs/Arguments.lhs 413 +-- | 'list_option' is an option which lists the command's arguments hunk ./src/Darcs/Arguments.lhs 555 +-- | 'get_repourl' takes a list of flags and returns the url of the +-- repository specified by @Repodir \directory\@ in that list of flags, if any. +-- This flag is present if darcs was invoked with @--repodir=DIRECTORY@ hunk ./src/Darcs/Arguments.lhs 578 +-- | 'remote_repo' is the option used to specify the URL of the remote +-- repository to work with hunk ./src/Darcs/Arguments.lhs 584 +-- | 'get_remote_repo' takes a list of flags and returns the url of the remote +-- repository specified by @RemoteRepo \directory\@ in that list of flags, if any. hunk ./src/Darcs/Arguments.lhs 680 +-- | 'get_context' takes a list of flags and returns the context +-- specified by @Context c@ in that list of flags, if any. +-- This flag is present if darcs was invoked with @--context=FILE@ hunk ./src/Darcs/Arguments.lhs 789 +-- | 'get_author' takes a list of flags and returns the author of the +-- change specified by @Author \Leo Tolstoy\@ in that list of flags, if any. +-- Otherwise, if @Pipe@ is present, asks the user who is the author and +-- returns the answer. If neither are present, try to guess the author, +-- from
Re: [darcs-users] darcs patch: Add another test case for issue1110.
On Tue, Sep 30, 2008 at 10:10:32PM +, [EMAIL PROTECTED] wrote: It's possible that the inverse of issue1110 fails too, get --old-fashioned of a hashed repository. Maybe this is interaction between the command line defaults and the stored preferences? Or I might just be tired/mistaken Tue Sep 30 23:08:18 BST 2008 Eric Kow [EMAIL PROTECTED] * Add another test case for issue1110. Applied. Thanks! David ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] Darcs utterly melts my brain: why PatchInfoAnd?
On Wed, Oct 01, 2008 at 10:28:02AM +0200, Florent Becker wrote: Florent Becker [EMAIL PROTECTED] writes: Le 30 sept. 08 à 23:30, Eric Kow a écrit : On Tue, Sep 30, 2008 at 22:27:24 +0100, Eric Kow wrote: Fast-tracking. On second thought, you have some haddock errors (nothing which prevents haddocking). Would you like to submit a cleaned-up version? I'm still willing to just go ahead and apply it, on the grounds that somebody else can clean up afterwards. Here is an updated version, which only complains that it cannot find the documentation for the base library, which i don't have on my system. What is the error you're seeing? I found out what was happening: the C(x y) macro was messing with haddock strings. Here is a corrected version. This yields a question: do we want the C(x y) to appear in the api-doc. They don't appear in the automatically-generated parts of the html, but they do appear in the code, so there has to be a discrepancy somewhere. The C(x y) is an important part of the type signature in any of the code that has been converted to actually use type witnesses, as it documents how the patches relate to one another. So if the haddock documentation is to be useful, this should be included. David ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
[darcs-users] darcs patch: Resolve issue1105: check if default opti... (and 3 more)
Hi all (and especially Dmitry),
In reviewing the first patch in this bundle, I found a bug, for which
I wrote a test (that passes before the fix) and a fix. Review would
be appreciated.
David
Mon Sep 29 10:19:48 EDT 2008 Dmitry Kurochkin [EMAIL PROTECTED]
* Resolve issue1105: check if default options are valid.
Mon Sep 29 10:22:05 EDT 2008 Dmitry Kurochkin [EMAIL PROTECTED]
* Test for issue1105.
Wed Oct 1 13:56:45 EDT 2008 David Roundy [EMAIL PROTECTED]
* add test that overriding of defaults works right.
Wed Oct 1 13:59:07 EDT 2008 David Roundy [EMAIL PROTECTED]
* fix bug in 1105 fix that led to improper overrides of defaults
The problem is illustrated in the tests/override-defaults.sh that I've
recorded separately. We want conflicting defaults in
~/.darcs/defaults and _darcs/prefs/defaults to be resolved in favor of
the default residing in _darcs/prefs/defaults.
New patches:
[Resolve issue1105: check if default options are valid.
Dmitry Kurochkin [EMAIL PROTECTED]**20080929141948
Ignore-this: 17b4b27e31545689f21496f7fc9c9fe7
] hunk ./src/Darcs/ArgumentDefaults.lhs 19
% Boston, MA 02110-1301, USA.
\begin{code}
-module Darcs.ArgumentDefaults ( get_default_flag,
-) where
+module Darcs.ArgumentDefaults ( get_default_flags ) where
import Control.Monad (
liftM,
)
hunk ./src/Darcs/ArgumentDefaults.lhs 23
-import Data.Maybe ( catMaybes )
+import Data.Maybe ( catMaybes, listToMaybe, mapMaybe )
import Darcs.Arguments
import Darcs.Repository.Prefs
hunk ./src/Darcs/ArgumentDefaults.lhs 118
ones will take precedence.
\begin{code}
-get_default_flag :: String - DarcsOption - IO [DarcsFlag]
-get_default_flag com flag = do
+get_default_flags :: String - [DarcsOption] - [DarcsOption] - [DarcsFlag] - IO [DarcsFlag]
+get_default_flags com com_opts all_opts already = do
repo_defs - default_content $ get_preflist defaults
global_defs - default_content $ get_global defaults
hunk ./src/Darcs/ArgumentDefaults.lhs 122
-case get_flag_from repo_defs of
- [] - return $ get_flag_from global_defs
- f - return $ f
- where
-get_flag_from defs =
-case gda com flag defs of
- [] - gda ALL flag defs
- f - f
+return $ get_flags_from com com_opts all_opts already repo_defs ++
+ get_flags_from com com_opts all_opts already global_defs
hunk ./src/Darcs/ArgumentDefaults.lhs 125
-gda :: String - DarcsOption - [(String,String,String)] - [DarcsFlag]
-gda com opt all_defs = gda' $ filter (\ (c,_,_)- c == com) all_defs
-where gda' defs = concatMap (choose_option opt) defs
- choose_option (DarcsNoArgOption _ fls c _) (_,f,d)
+get_flags_from :: String - [DarcsOption] - [DarcsOption] - [DarcsFlag] - [(String,String,String)] - [DarcsFlag]
+get_flags_from com com_opts all_opts already defs =
+options_for com_defs com_opts com_opts ++
+options_for all_defs com_opts all_opts
+where com_defs = filter (\ (c,_,_) - c == com) defs
+ all_defs = filter (\ (c,_,_) - c == ALL) defs
+ options_for d o ao = concatMap (find_option o ao already) d
+
+find_option :: [DarcsOption] - [DarcsOption] - [DarcsFlag] - (String,String,String) - [DarcsFlag]
+find_option opts all_opts already (c, f, d) =
+if null $ mapMaybe choose_option all_opts
+then error $ Bad default option: command '++c++' has no option '++f++'.
+else concat $ mapMaybe choose_option opts
+where choose_option (DarcsNoArgOption _ fls o _)
+ | o `elem` already = Just []
| f `elem` fls = if null d
hunk ./src/Darcs/ArgumentDefaults.lhs 141
- then [c]
- else error $ Bad default option: command '++com
+ then Just [o]
+ else error $ Bad default option: '++f
++' takes no argument, but '++d
++' argument given.
hunk ./src/Darcs/ArgumentDefaults.lhs 145
- choose_option (DarcsArgOption _ fls c _ _) (_,f,d)
+ choose_option (DarcsArgOption _ fls o _ _)
+ | o `isin` already = Just []
| f `elem` fls = if null d
hunk ./src/Darcs/ArgumentDefaults.lhs 148
- then error $ Bad default option: command '++com
+ then error $ Bad default option: '++f
++' requires an argument, but no
++argument given.
hunk ./src/Darcs/ArgumentDefaults.lhs 151
- else [c d]
- choose_option (DarcsMultipleChoiceOption os) p =
- concatMap (\o - choose_option o p) os
- choose_option _ _ = []
+ else Just [o d]
+ choose_option (DarcsMultipleChoiceOption os)
+ | os `arein` already = Just []
+
Re: [darcs-users] darcs patch: check if default options are valid
On Mon, Sep 29, 2008 at 06:38:00PM +0400, Dmitry Kurochkin wrote: Hello. Attached is fix for issue1105 and test. I am not very happy with it. IMHO code became more complex. Suggestions how to make it better or fix the bug another way are welcomed. Hmmm. This code doesn't look so bad to me. The only ugly bit is the passing of all_opts around, but it's hard to see any fix that would be less than a major module refactor. For those who haven't read the patch, the issue is that we would like to warn users (crash?) if they have a broken ALL default in their defaults file, but to do that when parsing the defaults, we need to know what *all* the possible flags are. This list of flags is a global constant, but the functions that need it can't import the list of all commands, since they are in modules that are imported by the commands themselves, so this would cause a dependency loop. :( I think the best solution to this issue would be to refactor Darcs.Commands, which is to big anyways. I think that we could separate the logic to run commands (which includes looking up the defaults) from the data and helper-function definitions that the commands themselves need to import. But this is a job for another day and/or another person than myself (as are so many jobs!). I also found one bug, which was in how we combine the global and per-repository defaults. I'm sending a separate patch bundle with a fix for that bug (and a new regression test for the test suite), so I won't discuss it more here. That was the only issue I found, so I'm pushing with my fix, but further review by other developers would be most welcome! David ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
Re: [darcs-users] patch: haddockification of Arguments.lhs
On Wed, Oct 1, 2008 at 5:45 AM, Florent Becker [EMAIL PROTECTED] wrote: Eric Kow a écrit : By the way, why not use darcs send? If it's just not working for you, we may have an interesting use case of darcs send not being good enough. Both you and zooko being affected by this must surely be a bad sign. I don't use darcs send for three reasons: -1/ I'm a lazy and dumb and I don't know how to configure mac OS X to get send working -2/ This way I can reply to threads with patches. Note that replying to threads with patches and not sending patches to me are both excellent ways to get your patches ignored by me. I'm afraid it's not really practical for me to change my work habits for your benefit. I don't have the time to read every message sent to the mailing list. David ___ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
[darcs-users] darcs patch: fixed accidental merge of two lines in default boring
Wed Oct 1 22:18:38 CEST 2008 [EMAIL PROTECTED] * fixed accidental merge of two lines in default boring New patches: [fixed accidental merge of two lines in default boring [EMAIL PROTECTED] hunk ./src/Darcs/Repository/Prefs.lhs 134 \\.p_hi$, \\.p_o$, -- profiling Haskell \\.mod$, -- FORTRAN module files \\.installed-pkg-config, \\.setup-config, - \\.setup-config^dist(/|$), -- Cabal intermediates + \\.setup-config,^dist(/|$), -- Cabal intermediates # *.ko files aren't boring by default because they might, # be Korean translations rather than kernel modules., # \\.ko$, Context: [generate a tidier hoogle frame, add required files, simplify framed doc generation Simon Michael [EMAIL PROTECTED]**20080930204518 Ignore-this: e60b456f1fdd001b5ae456f9aae05999 ] [haddock documenation for DateTester [EMAIL PROTECTED] [haddock documentation for DateMatcher [EMAIL PROTECTED] [make installdocs should not install TeX intermediaries. Trent W. Buck [EMAIL PROTECTED]**20080930030315 I'm unilaterally classing the DVI and PostScript versions as intermediaries to the PDF version, and only installing the latter. ] [Add test cases for issue1043. Eric Kow [EMAIL PROTECTED]**20080930105032 There are two known variants, one of which was fixed by resolve issue1043: fix bug in mergeAfterConflicting. ] [resolve issue1043: fix bug in mergeAfterConflicting. David Roundy [EMAIL PROTECTED]**20080926211928 Ignore-this: 1416605539b44b32c18b348f3b4f459d This is moderately deep in the internals of the darcs-2 conflict handling code. I had made an assumption that turned out not to be correct. I fix this by switching to use a variant of the commute function that doesn't allow conflicting patches to commute, which I think should restore correctness here. It's a scary bug, though, and if anyone were to create a moderately small test case, I'd be extremely grateful. ] [add test that show bug works right. David Roundy [EMAIL PROTECTED]**20080929152909 Ignore-this: 4829e300015120adeed108079324e5e2 ] [Add a test case for issue1110. Eric Kow [EMAIL PROTECTED]**20080929151743] [Tone down unnecessarily scary language when cancelling Simon Michael [EMAIL PROTECTED]**20080928004013 Ignore-this: c5940d14099953b7bc963c70591739d1 ] [darcshoogle script and emacs integration example Simon Michael [EMAIL PROTECTED]**20080927210609 Ignore-this: 93d5a0ff269d314d32f213dfbe4325be ] [Fix doubled verb `be' in documentation on apply posthooks in _darcs/prefs/defaults. Taylor R Campbell [EMAIL PROTECTED]**20080928200954] [the issue864 test was misnamed Simon Michael [EMAIL PROTECTED]**20080928231942 Ignore-this: a0b643bf0abc6f4b6237e5683e9f6dad ] [add tests for pull --union and --intersection. David Roundy [EMAIL PROTECTED]**20080929150711 Ignore-this: 356f506f79ca89a2d1246d068aaa8b2b --intersection fails, which is issue. ] [add more output to URL bug message. David Roundy [EMAIL PROTECTED]**20080929145544 Ignore-this: 868e0ba5819dba2a4f5b8819080e9407 I triggered this bug a few times, but once I added the extra output, I wasn't able to do it again. So I'm leaving the extra information in the bug message so if someone else runs into it, we can more easily track down the issue. ] [answer darcs-doc question: no, that would be wrong. David Roundy [EMAIL PROTECTED]**20080926220229 Ignore-this: 419afd7bd9832e06d3dca45880276296 ] [Make UglyFileName.super_name work with /foo paths. Dmitry Kurochkin [EMAIL PROTECTED]**20080926223753 Ignore-this: 6e4abb72087272ed03e5839a5420f82f ] [make api-doc-frames converts api docs to a frame layout Simon Michael [EMAIL PROTECTED]**20080927091919 Ignore-this: 2a600aefe4399d17a4c2f14ea1cec350 ] [hoogleindex no longer depends on api-doc dir Simon Michael [EMAIL PROTECTED]**20080927090139 Ignore-this: 3a29b9bbd1ba1cdbccea03f4c04727c8 ] [make hoogle targets more robust Simon Michael [EMAIL PROTECTED]**20080927083125 Ignore-this: 2aac81020d3855ce8ffc9c4deef3e949 ] [haddockification of IsoDate [EMAIL PROTECTED] Docstrings by Eric Kow ] [fix makefile indentation Simon Michael [EMAIL PROTECTED]**20080927020444 Ignore-this: 847051698f40dc1fd03a8e1db93ff7a1 ] [make hoogleweb configures the hoogle web interface in hoogle/ Simon Michael [EMAIL PROTECTED]**20080927015904 Ignore-this: dcc4e2526b3c92859ccf9a6f1cb57ad2 The hoogle index target is now make hoogleindex. Requires the hoogle source tree (perhaps patched to configure result link urls). Tested on GNU/Linux with hoogle 4.0.0.5. ] [make haddock less noisy Simon Michael [EMAIL PROTECTED]**20080927012958 Ignore-this: 84921fbd34b1f7345dec2571c3ec32ae ] [Rollback 'simplify patches in rollback' Eric Kow [EMAIL PROTECTED]**20080926225411 I made the mistake of pulling this into stable despite a darcs 2.1 feature freeze. rolling back: Tue Sep 23 16:06:19 BST 2008 David Roundy
