@dnolen can’t tell what this is about https://dev.clojure.org/jira/browse/CLJS-1801 but maybe https://dev.clojure.org/jira/browse/CLJS-2040 fixed it?

On further thought, the code seems fine about the bounded-count. False alarm. If the new way to calculate the bc is now different (ie higher than it was before) it'll give an error, just like before. The error will be thrown from the function's dispatcher so no problem here.

@dnolen Btw, the bounded-count change isn't a micro opt IMO, it's quite significant since bounded-count will always walk the sequence with first/`next` with the created (list* ...). Now by using args we can avoid all those calls. Especially if the user passes in a ICounted. Next optimization would be to rewrite apply-to similarly to the new apply-to-simple.

I won't have time to work on this, but wanted to write down some ideas. The following would make the custom cljs$lang$applyTo method on the function prototypes moot and could improve performance for variadic invokes. Needs to be measured: https://gist.github.com/rauhs/771fb0fc8746958ca6f473914eeb1128

In Clojure, reduce falls back to an iterator based reduce if the collection supports it. In CLJS currently the only fallback is seq-reduce. Would adding iter-reduce be desirable. It would benefit reduce on PHM and PHSs. PAMs implement IReduce in CLJS for some reason but make a call to seq-reduce. Swapping that out for a call to iter-reduce would also make an improvement there. PersistentTreeMaps and PersistentTreeSets are the only major collection in core which do not currently have an iterator.

Looking at cljs.core/take impl. Could someone please explain why the entire coll is being realized here? Maybe I’m missin something https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L4583

@roman01la Seq doesn't realize a lazy sequence:

(first (seq (lazy-seq
              (cons 1
                    (lazy-seq
                      (prn "realize")
                      [3])))))

@rauh makes sense, just trying to read the source properly. thanks 🙂

@rauh I don’t know you would have to show numbers for very typical cases to back up this claim (I’m not saying you don’t have them) - arities 1-4 like the ones you unrolled seemed quite typical

so making apply fast is about making typical fns fast, we don’t care that much about less common cases

@rauh optimizing cljs$lang$applyTo sounds fine - re: that gist, macro-izing apply I’m inclined to say no 🙂

@dnolen Ok, yeah I'm not too excited about macro-izing apply. Seem like apply is most of the time used with higher order invokes.

The code also needs to handle the opposite case, when we need to collect the passed values. Still needs a bunch of work probably.

@tmulvaney seems reasonable to me now that IIterable is a thing

I think that’s the only reason we didn’t do it before, we didn’t have iterators - but we do now post-transducers

related would be es6-iter-reduce

Just curious. Do you plan on cutting a release soon?

@dnolen cool. I'll open a ticket later. I have an old branch around where I played around with iter-reduce.

Also in regards to apply performance, it looks like to-array is used. into-array is much more performant for collections which implement IReduce.

@tmulvaney Yeah, I noted that idea yesterday. It could be worth a try. Only problem is that the values need to be plucked out again.

@rauh not planning on it no

lots of chanages so we should let it stew for a while - also there’s a bunch of tickets I’ve marked for “Next” release

that I would like to see addressed beforehand

The CI at https://travis-ci.org/mfikes/clojurescript is now automatically tracking upstream changes. (Using a core.async 15-minute timeout poll loop in ClojureScript, of course.)

@mfikes ha awesome, you using Planck for that?

@dnolen Of course. This is running on a VPS: https://gist.github.com/mfikes/17f1761d01e42dce5ce15a258291c879

(All of the above is free, in case anyone is curious—no dinero is being expended.)

great!

Not sure if this is the same as CLJS-2102

cljs.user=> (def ^:const one 1)
#'cljs.user/one
cljs.user=> (if-some [x true] one 2)
nil

that second nil is actually undefined

the const replacement fails to emit a js "return" statement

there's a dynamic var that you can set to print the generated js from statements at the repl. what is it?

@favila not the same, file a bug

the issue is we don’t use the var’s :context to figure out what happening, we blindly use :context :expr

put exactly that example in the ticket please, thanks

@dnolen https://dev.clojure.org/jira/browse/CLJS-2104

@favila great thanks

@dnolen Added a patch which fixes this example. Should be vetted, I am not well-versed in the ast

@favila that’s pretty much what I was thinking yes

thanks!

By the way @favila , you were thinking of :repl-verbose: https://clojurescript.org/reference/repl-options#repl-verbose

yeah, I found it eventually

thanks