This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-09
Channels
- # beginners (38)
- # boot (160)
- # cider (143)
- # cljs-dev (62)
- # cljsjs (2)
- # cljsrn (3)
- # clojure (278)
- # clojure-austin (8)
- # clojure-brasil (5)
- # clojure-greece (2)
- # clojure-italy (11)
- # clojure-russia (188)
- # clojure-sg (2)
- # clojure-spec (118)
- # clojure-uk (103)
- # clojurescript (87)
- # core-async (8)
- # cryogen (2)
- # cursive (12)
- # datomic (119)
- # emacs (13)
- # hoplon (4)
- # immutant (12)
- # off-topic (12)
- # om (54)
- # om-next (5)
- # onyx (1)
- # pedestal (2)
- # portland-or (2)
- # re-frame (58)
- # reagent (18)
- # ring-swagger (18)
- # rum (4)
- # spacemacs (4)
- # specter (3)
- # untangled (65)
- # yada (25)
@ewen re: the other thing, return array-map instead - also sounds fine, open a minor ticket + patch for that if you like
@dnolen what about subvec ? any chance we could get either the docstring updated, or subvec to check its argument type, or better, ranged iterator to only use the vector protocols ?
@ewen also this doesn’t seem particularly important to me - a trivial ticket is OK but it’s unlikely to ever get bumped up higher in priority
@tmulvaney ranged iterator is not public but subvec is, and subvec uses ranged iterator. This means that using subvec with a custom vector implementation won't work
@r0man undefined
isn’t a ClojureScript value - so that seems like a questionable thing to me at the moment
@dnolen I run into this while working with React. They use js/undefined
as the value for uncontrolled inputs. I had a map like {:value js/undefined}
and called clj->js
on it to pass it to React. I would have expcted clj->js
to return #js {:value js/undefined}
, but got #js {:value nil}
. You can't spot this very quickly because they print both as #js {:value nil}
in the REPL. I'm also not quite sure if clj->js should convert it or not. Just wanted to mention it.
I would argue that clj->js shouldn't be destructive or loose more information than necessary. Converting nil and js/undefined to both nil is loosing information. You can't figure out the difference afterwards. So that would be an argument for not converting. But I agree it's questionable. 🙂
Also, a lot of the {object,long,int}-array
function duplicate the code. Could this all be mapped to one function?
Yeah I understand they usually double the underlying memory to have amortized cost of O(1)
if it’s not nothing - then you need to come up with something that affects a wide variety of cases not just the one you are having
10 years of JS and 5 years of ClojureScript have convinced me the distinction in JS is abomination
it's not too important to me. I was just wondering if things like that could be made more user friendly.
you do realize that changing how js/undefined
prints now is also pretty much going to be disaster
Hmm, but aren't there other unreadable things things that we also print? Or do you mean the chance we break other code is too high?
I just solved this one for CLJS: http://dev.clojure.org/jira/browse/CLJ-1402 ~5x speedup for a relatively simple :x
keyfn, so can potentially speed up much more depending on how expensive keyfn
is
On a 10k element collection, the keyfn is called by Chrome's sort implementation ~270k times.
@rauh for expensive keyfn
, isn’t memoize
good enough? https://clojuredocs.org/clojure.core/memoize
@andrewhr Well given that avoiding the map lookup resulted in 5x speedup and memoize itself does a map lookup. Probably not
Okay! I've written a patch for http://dev.clojure.org/jira/browse/CLJS-1453. I'd appreciate any feedback about the approach.
@angusiguess please remove all whitespace changes from the patch
will do
Done and done 🙂