On Sat, Nov 15, 2008 at 2:04 PM, Eric Kow <[EMAIL PROTECTED]> wrote: > Thanks for the patch and the review! > > I think I'm willing to apply this, but I'm a bit nervous about losing > the property that the individual shell tests are self-contained. There > is also the question of the bugs directory. Maybe we should rename > lib.sh to lib so that we can keep a copy in bugs. > > Generally we like the shell scripts to be very dumb and simple, with > a relatively small amount of factorisation. I *think* this lib.sh > idea is reasonable, but I do wonder if there are any potential > downsides. > > So please allow me to flip flop on this overnight, and maybe convince > me one way or the other :-)
As I understand it, we like the following qualities in our test suite: 1) Easy to debug with 2) Easy to understand 3) Easy for users to contribute to 4) Portable 5) Extensive/catches bugs/etc Factorization has the potential to hurt (1), (2) and (3) while helping with (4). Other things we might consider important in a test suite: 6) Easy to maintain 7) Attractive -- as in attracts a test suite manager 8) Domain specific -- contains tools for common darcs testing idioms Factorization has the potential to help with each of these. Let me coin a term based on (8), let's suppose we have a tool set, 'the darcs test combinator lbrary' or DTCL. Maybe this is lib.sh, maybe this is a new language for testing that we write, maybe this is pure Haskell or maybe it's a set of command-line tools. For (3), I think it's quite reasonable that we allow users to submit tests in shell and then we have someone translate that test to DTCL. We do this kind of already. The question is how much work is involved in the translation. Currently sh is killing us on (4), and we have things like hspwd, 'yes' is banned and so on. Zooko suggested that we explore whether or not sh is meeting our needs with respect to 1-3 compared to using pure Haskell. Zooko also mentioned that in his experience programmers don't have a problem debugging from test cases written in a language they already know (Haskell in this case). Some have suggested HSH from Hackage, but HSH is not portable to windows it would seem. I have seen Shsh (http://code.haskell.org/shsh/), but it's too soon for me to know if it's going to be a viable option for us. I couldn't build it to try it out and it looks like it's just starting. Here is what I'm thinking about: I found that the grammar of sh is specified here: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_03 I don't know how soon I will get to it, but I would l like to make a parser based on that specification and place it on Hackage as Language.Sh so that darcs and others can build tools from it. For example, we might be able to automate a translation from sh to DTCL using it. We could also implement a pure Haskell shell by using it. We could also explore a DTCL to sh translation too so that (1) remains easy even if DTCL is not sh. Thanks! Jason _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
