This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-21
Channels
- # 100-days-of-code (1)
- # announcements (2)
- # beginners (164)
- # cider (23)
- # cljs-dev (30)
- # cljsjs (11)
- # cljsrn (7)
- # clojure (116)
- # clojure-boston (1)
- # clojure-dev (20)
- # clojure-finland (2)
- # clojure-italy (4)
- # clojure-nl (1)
- # clojure-uk (10)
- # clojurescript (39)
- # core-async (19)
- # cursive (43)
- # data-science (2)
- # datomic (24)
- # emacs (10)
- # figwheel-main (20)
- # fulcro (63)
- # hoplon (7)
- # hyperfiddle (7)
- # instaparse (3)
- # kaocha (1)
- # nrepl (3)
- # off-topic (170)
- # onyx (13)
- # other-languages (3)
- # parinfer (13)
- # re-frame (39)
- # reagent (5)
- # reitit (22)
- # ring-swagger (4)
- # shadow-cljs (284)
- # spacemacs (2)
- # sql (27)
- # testing (28)
- # unrepl (2)
I have a report of a problem that seems to affect humane-test-output
and latest cljs
it does pretty weird things so gear up!
I wonder what percentage of users considering filing a defect actually create a JIRA account to file one.
about the above 👆 it seems like the semantics around binding
maybe are not allowing it anymore, so the library, which does admittedly crazy things in order to work with pprint
, will probably need to change to an atom or something
yep I think that broke the library - not blaming just saying 😄 - https://github.com/pjstadig/humane-test-output/issues/37
@mfikes But the ones who DO file JIRA issues, perhaps do so disproportionately often 🙂
one observation I have is: when things are breaking Clojure semantics, is it still a ClojureScript breaking change? (with appropriate version change if ClojureScript follows semver)
cause folks (me included) might not be aware of "how Clojure does it"
but the breakage might happen
it is still impacting people so probably it should be mentioned somewhere, for instance here: https://github.com/clojure/clojurescript-site/blob/master/content/news/2018-11-02-release.adoc sorry I don't mean to trouble anyone, just mentioning something that ClojureScript should think about doing
that's what I am doing
Is there any way to tell cljs “no really this var is a plain js function not a cljs function I promise, please invoke it directly all the time and don’t look for an arity-specific invocation”
hi all I've started work on cljs integration for Kaocha (a test runner), so I might have some questions in the near future...
first one, when I run this, I get lots of warnings
(binding [env/*compiler* (env/default-compiler-env)]
(ana/analyze-file (io/file "/home/arne/github/lambdaisland/kaocha-cljs/test/cljs/ktest/first_test.cljs")))
WARNING: Use of undeclared Var clojure.string/reduce at line 16 file:/home/arne/.m2/repository/org/clojure/clojurescript/1.10.439/clojurescript-1.10.439.jar!/clojure/string.cljs
...
If we were to revise seq
to throw TypeError
when the value passed cannot be dynamically converted to a seq, would that be odd to JavaScript programmers? (In other words, is TypeError
usually thought of as a static thing?)
I could see an argument that this shouldn't be done, as seq
has no "expected type", at least not in a static sense.
@mfikes That should be totally kosher, and is mirrored by the behavior of modern engines' implementation of JS's iterator protocol. For example if you try to run const items = {a: 1, b: 2, c: 3}; for (const foo of items) console.log(foo);
, it will give you TypeError: items is not iterable
because plain objects don't have a Symbol.iterator
method