On Mon, Oct 31, 2011 at 2:57 PM, Colin Yates <colin.ya...@gmail.com> wrote: > Don't want to feed the trolls but can you justify "ridiculous"? > Rather a strong term.....or maybe your definition is "I don't > understand the value".
The value of having people piece together ad-hoc test suites vs. adding tests to Clojure (and the Clojure build) is in some sense the same. The tests will flush out undesired behavior regardless. In another sense the value of having your own test suite is higher because you have it test what you care about and don't have to jump through hoops to get it into Clojure's suite. In yet another sense the value of having tests in Clojure's test suite is higher because some failures will be detected early (and fixing it early is some how less expensive). The idea is not ridiculous. The circumstances that would drive to it's implementation would be. It would make Clojure, to my knowledge, the only open source project were contribution of test cases is so difficult the community more or less forks the tests suite from the controlling body and runs it themselves. Your email starts off "Whacky idea… ", so maybe I should have said "which is whack." My guess is rich wrote this in response (at least in some part) to nathan's recent thread about the change to box ints as Longs in Clojure 1.3. This change would cause tests written to detect the boxed type of numbers to fail, but so what? The change is deliberate and planned so of course tests will fail, the tests just no longer reflect what you want. My understanding is what rich wants is use cases to guide changes in the semantics of the language. e.g. "I used to do X in clojure version N, but in the latest snapshot with change C, X isn't as easy to do, is there some C' that would make this better?" e.g. "I used to stick ints into collections and turn around and use them for interop in clojure version 1.2, but in 1.3 with changes to how clojure boxes numbers, interop isn't as easy to do, is there some other change we could use to enforce clojure's semantics in collections that would make this better?" > Maybe you are right, maybe we should provide an easy way to submit > test cases which are automatically run as part of a CI build....no > wait, that was my ridiculous suggestion. > > Please ask yourself how your response added anything at all to this > thread or community other than making it just a little harder for > people to suggest things for fear of being ridiculed without any form > of justification. A much better response would have been "I don't get > it, please explain". Based on your ability to read Rich's thoughts > maybe you have already had that conversation with me telepathically. > Dunno. Keeping up with the state of play is hardly mind reading, and I don't think it is too much to ask of people who want to participate in discussions. I will not pretend to know rich's mind (I still don't understand why Clojure can't take pull requests) but absent clarification by rich and given the "whacky" idea of yours, the "use case" interpretation is the only thing that makes sense. > > My (I.e. this) response hasn't added anything except to flag up a very > unhelpful and negative comment (and been just a little therapeutic) > > Sent from my iPad If you cannot deal with having an idea you profess to be "whacky" called "ridiculous" by someone on the internet, you might need fewer internet connected devices. > > On 31 Oct 2011, at 21:42, Kevin Downey <redc...@gmail.com> wrote: > >> the responses to rich here sort of read like "lets make an ad-hoc test >> suite for clojure and everyone can run it" which is ridiculous. >> >> tests should be contributed back to clojure. >> >> if contributing tests is so difficult people instead create their own >> test suites and report results then we need to stream line the >> contribution process. >> >> I cannot imagine this the kind of response rich was looking for, maybe >> he will clarify. >> >> On Mon, Oct 31, 2011 at 2:08 PM, Stuart Sierra >> <the.stuart.sie...@gmail.com> wrote: >>> Yes, the Sonatype repositories have every Clojure development snapshot since >>> 1.3. >>> >>> -Stuart Sierra >>> clojure.com >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with your >>> first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >> >> >> >> -- >> And what is good, Phaedrus, >> And what is not good— >> Need we ask anyone to tell us these things? >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
