I'm accepting these; notes below. > Sat Dec 9 14:39:16 PST 2006 David Roundy <[EMAIL PROTECTED]> > * fix pending bug that broke several_commands.sh. > > Sun Dec 10 13:18:46 PST 2006 David Roundy <[EMAIL PROTECTED]> > * resolve conflict in white space.
Ok, I don't entirely understand this, but I'll trust that David actually understands the pending stuff really well, in any case much better than me and I do see that tests do now pass where they didn't before. Notes ----- 1) Remove.lhs - I smell a refactor. Maybe? 2) What exactly does moving add_to_pending before the moving/replacing/etc accomplish? Is this about correctness, robustness or something else? 3) add_to_pending now uses get_unrecorded, which includes read_pending that we used to invoke. I'm guess this is the bit that fixes the bugs, but is there any chance that this introduces a new category of bugs? Is there such a thing as unrecorded changes that shouldn't go on pending being dumped there by accident? And now a general remark ------------------------ One thing that seems to be missing in our comments is an explanation how pending really works. Maybe there is none, because there is nothing to explain. I would suspect that other developers would appreciate some sort of hand-holding on the subtleties behind pending vs. regular old unrecord changes, even a basic list of gotchas and sanity checks we should make when mucking around in there. I claim also that with David having recently cleaned up all this stuff and pushed it into the Repository module, now would be a good time to work on said documentation, while it's still fresh in our collective head. > Sun Dec 10 13:35:36 PST 2006 David Roundy <[EMAIL PROTECTED]> > * change Maybe Patch to Hopefully Patch. > > Sun Dec 10 15:16:23 PST 2006 David Roundy <[EMAIL PROTECTED]> > * don't use HopefullyPrivate outside of Hopefully. > > Sun Dec 10 15:44:53 PST 2006 David Roundy <[EMAIL PROTECTED]> > * fix bug in haskell_policy check for HopefullyPrivate. This version of the Hopefully stuff answers some of my previous questions, so I've copied over the ones I still find relevant and added some more Notes 2 ------- 4) should hopefully be expressed in terms of conscientiously? 5) There is one disadvantage to this new code, and that is that we lose the source code line numbers that tell use where the fromJust/ hopefully error was triggered. I would argue that this is worth getting back, because hopefully still gets called in many different places, so it might not be entirely clear why/when patch stuff becomes Unavailable. Would it be possible for hopefully to have some of the same impossible.h line number magic? That would cover the top of the chain, just like fromJust did. What would also be nice is if we could cover the bottom of the chain by putting the same magic in our calls to the Unavailable constructors. 6) Perhaps we should have the policy checker "enforce" that Unavailable should never be passed the empty string. We now have much more capacity for error tracking, so it seems like we should adopt a discipline of actually using it. 7) Maybe refactor hopefullyNoParseError? I see it in two places; maybe there'll be more? -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français.
pgpDWTLAISxqQ.pgp
Description: PGP signature
_______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
