This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-17
Channels
- # admin-announcements (1)
- # aleph (1)
- # architecture (1)
- # bangalore-clj (14)
- # beginners (15)
- # boot (89)
- # braveandtrue (1)
- # cider (1)
- # cljs-dev (33)
- # cljsjs (1)
- # cljsrn (147)
- # clojure (149)
- # clojure-quebec (1)
- # clojure-russia (82)
- # clojure-spec (18)
- # clojure-taiwan (2)
- # clojure-uk (15)
- # clojurescript (97)
- # cursive (11)
- # datomic (22)
- # funcool (2)
- # hoplon (53)
- # immutant (16)
- # jobs-rus (8)
- # lambdaisland (1)
- # off-topic (13)
- # om (7)
- # onyx (58)
- # parinfer (6)
- # planck (19)
- # protorepl (2)
- # re-frame (17)
- # reagent (201)
- # rum (6)
- # specter (9)
- # test-check (68)
- # untangled (47)
- # yada (94)
@dnolen: even though test.check is added to the pom.xml and project.clj it hasn’t been added to script/bootstrap which results in test.check not being available in the classpath
@anmonteiro: ah right
@dnolen: should make your job easier ^
@dnolen: I wonder if it’s OK to introduce test.check as a dependency for running CLJS tests
this came up because I was working on http://dev.clojure.org/jira/browse/CLJS-1754 and wanted to provide a test
but it would introduce the new dependency of requiring clojure.test.check.generators
in the tests
the fix for that one is simple enough that I can provide a patch without a test, in case we don’t want to introduce the new dep
@anmonteiro: it’s fine to include it as a test dependency yes
problem is including that in the self-parity
not sure how to load test.check there
@dnolen: adding this as a test dep paves the way for eventual generative tests in the CLJS codebase 🙂
I’ll help @anmonteiro sort out how to include that dep with the self-parity test
@dnolen: running the self parity tests for this will need an updated script/bootstrap
script, should I create a ticket for updating that one as well?
@anmonteiro: go for it
awesome
Perhaps the groundwork for this could ultimately lead to the ability to employ generative tests in the ClojureScript test suite itself. (http://dev.clojure.org/jira/browse/TCHECK-105 is pending and would make test.check
fully usable from self-hosted ClojureScript, covering all bases.)
@dnolen: why cljs.spec.impl.gen
and not cljs.spec.gen
?
I know there’s an issue in JIRA for a special case alias, but the actual doubt I have is if it’s not possible to mimic Clojure namespaces for this one?
@anmonteiro: because Closure namespaces can have clashes due to being represented as JS objects
right
makes sense, but sounds annoying
I can’t argue with you on that, as I haven’t needed to require that one yet, except for the boolean?
patch test
I agree, was just curious about the justification for the difference in naming between CLJ and CLJS
ah awesome, could you point me to an example of that in the codebase?