This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-07
Channels
- # admin-announcements (4)
- # aws (2)
- # beginners (25)
- # boot (116)
- # braid-chat (4)
- # cider (6)
- # cljsjs (4)
- # cljsrn (17)
- # clojure (196)
- # clojure-austin (23)
- # clojure-belgium (5)
- # clojure-dev (78)
- # clojure-dusseldorf (6)
- # clojure-italy (2)
- # clojure-japan (6)
- # clojure-poland (1)
- # clojure-russia (132)
- # clojure-sdn (1)
- # clojure-uk (26)
- # clojurescript (87)
- # code-reviews (3)
- # core-async (26)
- # cursive (8)
- # datomic (40)
- # devcards (8)
- # emacs (4)
- # funcool (32)
- # hoplon (30)
- # jaunt (34)
- # jobs (1)
- # lein-figwheel (1)
- # leiningen (5)
- # om (14)
- # onyx (8)
- # overtone (31)
- # parinfer (14)
- # proton (8)
- # protorepl (1)
- # re-frame (30)
- # reagent (10)
- # spacemacs (2)
- # untangled (107)
- # yada (3)
Hey, reading cljsbuild docs and it says "Note that cljsbuild crossovers are deprecated, and will be removed eventually. "
hmmm from what I can tell it has to do with, now use .cljsc files for your code that does both clj and cljs.
A question about extend-type
for strings:
Why it behaves differently for this
and (+ “” this)
?
@jonathandale: still need some help with cljs chrome extensions?
@darwin, oh thanks for checking in… no, problem solved
I’m using cljs-ajax
lib and they use goog-json/parse
which…. unless a USE_NATIVE_JSON flag is set to true (default is false), it uses eval
.
Which…. was throwing an error in my released extension.
btw. if you are using chromex, any feedback welcome, also I can later add your project on the list of projects using the library
Alright… will do. We’re just getting started, but looking very promising so far. Thanks!
@viebel: you should not extend-type js/String
you should extend-type string
. +
is only for numbers not for strings.
I’m having difficulty setting a :closure-define
correctly.
I want to set goog.json.USE_NATIVE_JSON
to true (as false is default: http://google.github.io/closure-library/api/source/closure/goog/json/json.js.src.html#l33)
But when I put :closure-defines {goog.json.USE_NATIVE_JSON true}
in the compiler config I get this error:
WARNING: WARNING - unknown @define variable goog.json.USE_NATIVE_JSON
Any ideas?
@jonathandale: it needs to exist in your source
@dnolen: ok, will try that — thanks
@jonathandale: there’s a goog-define
macro helper in the standard lib
any online and free resources for learning about google closure? the oreilly book is a bit expensive and there's not much practical info online.
@seanirby: not beyond the website, the book seems informative but likely to be somewhat dated by now
@dnolen: string
doesn’t work with extend-type
for IFn
the snippet above causes an error
It is transpiled to the follwowing
“a”.call(…)
fails because nothing was added to the String prototype
@dnolen: what am I missing?
but I don’t really recommend doing that to String.prototype
, in the past it triggered JS VM deoptimization in some cases
@dnolen: so it’s not possible to extend string to behave like keywords with maps?
BTW, why in clojure
and clojurescript
strings don’t behave like keywords with maps?
why strings would perform worse than keywords?
what downsides?
BTW, the same happens with numbers
but why extend-type js/String
didn’t work without the (+ "" this)
trick?
I know that it is bad practice
Just want to understand...
ok. thanks
also a minor ticket for extend-type string
with IFn
?
what’s the diff between string and js/String?
I see, with string
the methods are added to the cljs
objects related to the deftype
macros etc..
while with js/String, the methods are added to the js String prototype
the second one is much more dangerous
a huge perf hit either way - so extending base types is really about convenience, expressivity - no way at the moment for it to be performant
Could you explain again what is the reason for the perf hit?
if you avoid that by not touching the prototypes we have to do a hash table look up to find the method
Is it only for IFn
or in general there is perf hit with protocols?
protocols introduce some indirection, about 1.5X slower than a regular fn call (that does nothing)
isn’t the same code ?
@viebel: sorry not going to explain this much more you can examine the compiler and the output if you’re really interested in understanding the nitty gritty.
ok. thx
@viebel: the defprotocol
macro is the place to start. Admittedly it’s all kind of a doozy as it’s all hand tweaked stuff to appease JS VMs.
Actually, I’m tryin to understand the compiler output with KLIPSE (a cool tool I built)
But it’s not easy 😞
I see that we first check if the method exists in the object itself (in its prototype)
and if not we check in the protocol object
That’s the perf hit that you mentioned with base types?
@dnolen: did I understand u correctly?