On Tue, Oct 23, 2007 at 12:48:50AM +0200, Eric Y. Kow wrote: > Hi David and Ganesh, > > I've skimmed over your patches in the conflicts tree. > > Using the 'x' key, I am ignoring everything in Darcs.Patch.Conflic* > which is changing rapidly anyway, and all of Ganesh's QuickCheck work as > I tend to ignore the unit tests anyway (this may not be so wise; I ought > to treat the tests as documentation). > > My superficial guess is that the result of Ganesh's work is that not > only will the checks reveal bugs, they will also produce human-readable > test cases when they do, in which case, hooray!
That's basically the idea. It's not *very* human-readable, but it's at least droundy-readable (I'm learning), and that's good. > As I write this, my last three patches are: > * another merge example, and some more verbosity. > * add more traces. > * move commuteWhatWeCanFL. > > Please let me know if you would like me to push any of these patches > into unstable, or if you would prefer I held off for a while. I don't think things can go into unstable until we get the tests working again. This will be a pain, since we've switched to QuickCheck 2 (which unfortunately is incompatible with QuickCheck 1.x, and isn't in a separate module). > Also, some minor comments on everything else. > > ====================================================================== > eliminate unsafe join_patches. > ====================================================================== > > > - Just (Sealed p, rest) -> p : rp rest > > + Just (Sealed x, _) -> x > > I saw this change in finalize_patch_changes and withTentative. This > is intentional, right? I'm guessing so because I see it in two places. Right, this is because we can noew directly readPatches. > ====================================================================== > make empty hunk patches (never generated by darcs) commute like identity. > ====================================================================== > > > +commuteFP f (Hunk line1 [] [] :< p2) = seq f $ Succeeded (FP f p2 :< FP f > > (Hunk line1 [] [])) > > +commuteFP f (p2 :< Hunk line1 [] []) = seq f $ Succeeded (FP f (Hunk line1 > > [] []) :< FP f p2) > > I know they are empty, but should the line numbers change if we > encounter another hunk patch? The key is that these patches are never generated by darcs (*should* never be generated by darcs), and so we can do what we like. In particular, we can treat such a patch as (almost) a synonymn for identity. It's not quite a synonymn for Identity, because it won't commute with "add f". So the line number is treated as meaningless. This change is really only relevant for quickcheck, which might generate such changes. > ====================================================================== > missing unsafeCompare case for Prim > ====================================================================== > > > + unsafeCompare Identity Identity = True > > Hmm. Why are hunk patches excluded from this? > I might have already asked this and forgotten the answer. I'm not sure I understand what you mean by hunk patches being excluded. Do you mean why don't we say that unsafeCompare Identity (FP _ (Hunk _ [] [])) = True ? That's not really necessary, since we don't generate such hunk patches. -- David Roundy Department of Physics Oregon State University
signature.asc
Description: Digital signature
_______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
