Fork me on GitHub
#cljs-dev
<
2018-11-21
>
richiardiandrea01:11:41

I have a report of a problem that seems to affect humane-test-output and latest cljs

richiardiandrea01:11:55

it does pretty weird things so gear up!

mfikes01:11:28

I wonder what percentage of users considering filing a defect actually create a JIRA account to file one.

richiardiandrea01:11:17

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

mfikes01:11:26

binding now does what its docstring describes, and matches Clojure

mfikes01:11:30

(with respect to parallel binding)

richiardiandrea01:11:11

yep I think that broke the library - not blaming just saying 😄 - https://github.com/pjstadig/humane-test-output/issues/37

mfikes01:11:42

Yes that binding of *sb* and its use in the same binding won’t work

andy.fingerhut01:11:37

@mfikes But the ones who DO file JIRA issues, perhaps do so disproportionately often 🙂

richiardiandrea01:11:12

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)

richiardiandrea01:11:35

cause folks (me included) might not be aware of "how Clojure does it"

richiardiandrea01:11:50

but the breakage might happen

richiardiandrea02:11:31

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

mfikes02:11:51

Maybe a PR to the release notes?

richiardiandrea02:11:09

that's what I am doing

favila04:11:36

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”

mfikes04:11:05

I’d try (def ^js f ,,,)

plexus15:11:14

hi all I've started work on cljs integration for Kaocha (a test runner), so I might have some questions in the near future...

👀 4
plexus15:11:00

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
...

plexus15:11:13

I guess there's some setup I'm missing?

plexus15:11:07

comp/with-core-cljs did the trick

mfikes16:11:41

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?)

mfikes16:11:22

I could see an argument that this shouldn't be done, as seq has no "expected type", at least not in a static sense.

mfikes16:11:20

Or maybe it does? It expects an ISeqable (or perhaps a few other allowed things).

jaawerth21:11:33

@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

jaawerth21:11:32

same error if you try to do other things that require items to be an iterable, such as [...items], or Promise.all(items)

jaawerth21:11:58

if it's cool to do with native protocols, it's cool to do with any protocol 😉