Clojurians
#cljs-dev
<
2017-06-19
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

rauh06:06:52

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.

rauh07:06:19

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

rauh07:06:09

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

tmulvaney09:06:38

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.

roman01la11:06:14

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

rauh11:06:19

@roman01la Seq doesn't realize a lazy sequence:

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

roman01la11:06:25

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

dnolen11:06:26

@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

dnolen11:06:55

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

dnolen11:06:10

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

rauh11:06:29

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

rauh11:06:21

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

dnolen11:06:01

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

dnolen11:06:33

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

dnolen11:06:10

related would be es6-iter-reduce

rauh12:06:21

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

tmulvaney12:06:19

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

tmulvaney12:06:04

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

rauh12:06:55

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

dnolen12:06:06

@rauh not planning on it no

dnolen12:06:40

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

dnolen12:06:55

that I would like to see addressed beforehand

mfikes15:06:49

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

dnolen15:06:16

@mfikes ha awesome, you using Planck for that?

mfikes15:06:45

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

favila17:06:31

Not sure if this is the same as CLJS-2102

favila17:06:47

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

favila17:06:16

that second nil is actually undefined

favila17:06:36

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

favila17:06:59

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

dnolen17:06:58

@favila not the same, file a bug

dnolen17:06:33

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

dnolen17:06:40

put exactly that example in the ticket please, thanks

dnolen17:06:47

@favila great thanks

favila18:06:46

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

dnolen18:06:32

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

mfikes18:06:16

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

favila18:06:28

yeah, I found it eventually