[darcs-users] [patch374] the state of the adventure

Eric Kow kowey at darcs.net
Mon Sep 6 15:07:16 UTC 2010


> Other than that, there aren't many new patches here, but I have worked a
> lot on Storage.Hashed.Path. Please look in the h-s HEAD repo. There's a number
> of QC properties now. Eric, if you had a bit of time for this, you could maybe
> look at that part?

Yay! But sorry, I didn't give you very much time.  I hope these off-the-cuff
glanced-at-the-code-and-ran-some-tests comments are useful anyway.

I hope Jason sees this thread, because I think it's something he could
provide some useful insights on.

I got a cabal error without -ftest.  I think you ran into the same problem I
did, which was that baking tests into code modules, means you have to include
test-framework in the dependencies as well.

| class Cook raw cooked | raw -> cooked, raw -> cooked where
|   cook :: raw -> cooked

Hmm, I think I'm looking at a functional dependency.

If nothing else, working on Darcs is helping me to learn more functional
programming concepts, by giving me concrete examples I find naturally
compelling.

| newtype RawAbsPath = RawAbsPath BS.ByteString deriving (Eq)
| newtype RawRelPath = RawRelPath BS.ByteString deriving (Eq)
| newtype Component = Component BS.ByteString deriving (Eq, Show)
| 
|  instance Cook RawAbsPath Absolute where
|    cook (RawAbsPath x) = case parsePathBS x of
|      Nothing -> error $ "Parse failed on path: " ++ show x
|      Just y -> y
|  instance Cook RawRelPath Relative where
|    cook (RawRelPath x) = case parsePathBS x of
|      Nothing -> error $ "Parse failed on path: " ++ show x
|      Just y -> y

Are these errors OK to have because you assume random path generators
that give you valid paths to begin with?

Should there be more testing on bad path inputs, of the
we-should-refuse-X variety?

I like how to seem to have a lot of code reuse, testing the same
invariants on all sorts of operations you can do with paths, and
also making sure you're testing both relative and absolute paths
the same way.

I wonder if it would be useful to:

1. copy tests from from System.FilePath.
2. randomly test combinations of operations, like "any random sequence
   of Storage.Hashed.Path operations should result in a valid path"
3. worry about portability for AbsolutePath - do we need lots of HUnit
   cases detailing all the fun things that Windows paths can do?
4. be more formal about testing for mathy properties, like "I think
   this relation should be symmetrical", and so on.  The reason why
   the formality may help is simply so that folks trained to think
   in those terms can recognise our tests more easily and just say
   "oh, yeah, that's an antisymmetry test"

Eric

PS: A bit off-topic, but how about adding a cabal haddock to
    repos.mornfall.net/hashed-storage?
    
    I'm partly interested because I'd like darcs.net/api-doc to be
    clever about linking to it as needed (pony request by Ganesh), and
    also because I think it will help us to see the current state of
    documentation.  Two birds, one stone.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
For a faster response, try +44 (0)1273 64 2905 or
xmpp:kowey at jabber.fr (Jabber or Google Talk only)


More information about the darcs-users mailing list