instrument and unstrument always return the var in Clojure. In ClojureScript, calling instrument on an already-instrumented var returns nil. The docstring doesn’t seem to specify what should occur, but perhaps ClojureScript could be made to behave like Clojure. Can do a JIRA if there’s interest.

@mfikes: I'm OK with that

@dnolen: i’ve applied Rich’s improvements for seq destructuring to clojurescript. Jira ticket with patch is here: http://dev.clojure.org/jira/browse/CLJS-1662

@rohit sweet thanks!

@dnolen: cool.

@rohit if you have a second can you fix your benchmark in the patch

(if xs …) should be (if-not (nil? xs) …) and rerun and put the updated numbers in

I think we should be seeing much better than only 2X

@dnolen: I'll do that. Cheers!

if Clojure is seeing 10X, I would be suprised if we can't at least get 5X as well

to explain, (if xs …) is a slow test in ClojureScript due to the need to check for 0 and the blank string

ah JavaScript

Ah. Thanks for the tip!

not a big deal for most code, but for understanding peak perf, it matters

@dnolen: the perf improvement is there but somehow I am not getting the improvement you are expecting. So for v8 and spidermoney the perf is about the same. For JSC, it improves from 1.4x to 2.2x

@rohit JSC is looking good

we may not be able to achieve Clojure’s gains without some more fiddling

due to protocol indirection

cool. i’ll update the patch and the benchmarks on the jira ticket.

thanks

thanks for the guidance. 🙏

@rohit I noticed you didn’t have sufficient JIRA privileges to do everything on that ticket, fixed now

excellent. thanks!

@dnolen: I’m trying to shepherd this jira ticket as well: http://dev.clojure.org/jira/browse/CLJS-1650. its a very minor fix. if you could have a look, that’d be great.

@rohit hrm, looks OK though we’re missing out on a big optimization here with read-delimited-list

we could be reading into an array and calling the super fast array adopting ctors instead of using apply which is crazy slow

i’ll definitely give it a shot. cheers!

@rohit: I would do that in separate patch though, this one is OK

@dnolen: cool.

@dnolen: just got what you meant. makes sense! 😊

just updated to Dirac to 1.9.14, found a tiny regression: (doc filter) in REPL prints “Spec” with empty info, I assume this should not be printed if given fn does not have spec attached https://travis-ci.org/binaryage/dirac/builds/134871220#L924

@darwin I noticed that someone mentioned this to Alex and he said it will be fixed in Clojure. Presumably changes in Clojure will somehow make their way to ClojureScript over time.

sometimes working on the ClojureScript compiler is bananas

and sometimes the flexibility of JavaScript comes to rescue

https://github.com/clojure/clojurescript/commit/2f012cec88d05f42dd145338d9c942498d3ceb13

feel free to install master and check it out

planning on cutting a release of master tomorrow

wow didn't know it was possible to extend objects like this

@mfikes not sure if you have any time tomorrow, but I noticed that multi-arity fns don’t return vars

not a big deal but I thought you might be better person to look at that one

@darwin fix in master thanks

thanks, testing master...

btw. I wonder why compilation caches do not get invalidated when I change clojurescript version in my lein dependencies, got bitten by this several times

@dnolen: Yes, I’ll take a look. Assigned http://dev.clojure.org/jira/browse/CLJS-1611 to me just now.

I’ll also see if I can fix a similar case: (defn f [& r])

confirmed, the unwanted “Spec” printing is fixed in master