> 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:[email protected] (Jabber or Google Talk only)
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
