Fork me on GitHub
#clojurescript
<
2016-04-07
>
urbanslug07:04:19

Hey, reading cljsbuild docs and it says "Note that cljsbuild crossovers are deprecated, and will be removed eventually. "

urbanslug07:04:28

What are cljsbuild crossovers?

urbanslug08:04:05

hmmm from what I can tell it has to do with, now use .cljsc files for your code that does both clj and cljs.

Yehonathan Sharvit13:04:15

A question about extend-type for strings:

Yehonathan Sharvit13:04:02

Why it behaves differently for this and (+ “” this)?

darwin14:04:05

@jonathandale: still need some help with cljs chrome extensions?

jonathandale14:04:29

@darwin, oh thanks for checking in… no, problem solved simple_smile 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.

darwin14:04:03

good to know, I’m glad you have resolved it

darwin14:04:43

btw. if you are using chromex, any feedback welcome, also I can later add your project on the list of projects using the library

jonathandale14:04:12

Alright… will do. We’re just getting started, but looking very promising so far. Thanks!

dnolen16:04:13

@viebel: you should not extend-type js/String you should extend-type string. + is only for numbers not for strings.

jonathandale16:04:43

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?

dnolen16:04:45

@jonathandale: it needs to exist in your source

jonathandale16:04:31

@dnolen: ok, will try that — thanks

dnolen16:04:13

@jonathandale: there’s a goog-define macro helper in the standard lib

dnolen16:04:38

(doc goog-define) in REPL will show you how it works

seanirby20:04:40

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.

dnolen20:04:38

@seanirby: not beyond the website, the book seems informative but likely to be somewhat dated by now

seanirby20:04:38

dnolen: thanks

Yehonathan Sharvit21:04:27

@dnolen: string doesn’t work with extend-type for IFn

Yehonathan Sharvit21:04:57

the snippet above causes an error

Yehonathan Sharvit21:04:06

It is transpiled to the follwowing

Yehonathan Sharvit21:04:45

“a”.call(…) fails because nothing was added to the String prototype

dnolen21:04:35

@viebel: ah right IFn isn’t going to work with string

dnolen21:04:21

but I don’t really recommend doing that to String.prototype, in the past it triggered JS VM deoptimization in some cases

Yehonathan Sharvit21:04:05

@dnolen: so it’s not possible to extend string to behave like keywords with maps?

dnolen21:04:31

@viebel: not in a reasonable way at the moment, and not a priority

Yehonathan Sharvit21:04:46

BTW, why in clojure and clojurescript strings don’t behave like keywords with maps?

dnolen21:04:58

probably a mix of taste and performance, I don’t really know

Yehonathan Sharvit21:04:26

why strings would perform worse than keywords?

dnolen21:04:35

at least for ClojureScript from a implementation perspective too many downsides

dnolen21:04:59

@viebel: string interning is controlled by the VM not the language

dnolen21:04:30

semantically support both means making call sites needlessly polymorphic

dnolen21:04:46

monkey patching String in JS in the past has lead to deoptimization

Yehonathan Sharvit21:04:24

BTW, the same happens with numbers

dnolen21:04:07

it’s not surprising and similarly not really a priority

Yehonathan Sharvit21:04:10

but why extend-type js/String didn’t work without the (+ "" this) trick?

Yehonathan Sharvit21:04:19

I know that it is bad practice

Yehonathan Sharvit21:04:27

Just want to understand...

dnolen21:04:52

I would have to look into that, a minor ticket for that particular quirk is welcome

dnolen21:04:12

but not with +, only interested if that’s the case with str

dnolen21:04:23

using + with anything but numbers is undefined

Yehonathan Sharvit21:04:12

also a minor ticket for extend-type string with IFn?

dnolen21:04:22

no we’re not going to support that

dnolen22:04:14

I’d forgotten that IFn requires the ability to attach call method

Yehonathan Sharvit22:04:18

what’s the diff between string and js/String?

dnolen22:04:22

not possible with JS base types

dnolen22:04:37

base types

Yehonathan Sharvit22:04:39

I see, with string the methods are added to the cljs objects related to the deftype macros etc..

Yehonathan Sharvit22:04:55

while with js/String, the methods are added to the js String prototype

dnolen22:04:01

that’s right

Yehonathan Sharvit22:04:09

the second one is much more dangerous

dnolen22:04:14

for base types you don’t want to patch - too problematic

dnolen22:04:47

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

dnolen22:04:19

but convenience isn’t worth damaging the performance of the fast usual paths

dnolen22:04:27

so that’s why no interest

Yehonathan Sharvit22:04:36

Could you explain again what is the reason for the perf hit?

dnolen22:04:48

I already said above

dnolen22:04:50

VM deoptimization

dnolen22:04:37

if you avoid that by not touching the prototypes we have to do a hash table look up to find the method

dnolen22:04:50

way slower than a bit mask check + direct method call

Yehonathan Sharvit22:04:06

Is it only for IFn or in general there is perf hit with protocols?

dnolen22:04:45

protocols introduce some indirection, about 1.5X slower than a regular fn call (that does nothing)

dnolen22:04:33

but that’s for the fast path

dnolen22:04:44

it’s much worse for trying to figure out if some base type extended a protocol

Yehonathan Sharvit22:04:00

isn’t the same code ?

dnolen22:04:52

@viebel: sorry not going to explain this much more simple_smile you can examine the compiler and the output if you’re really interested in understanding the nitty gritty.

dnolen22:04:03

happy to answer further questions after you’ve done that.

dnolen22:04:56

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

Yehonathan Sharvit22:04:24

Actually, I’m tryin to understand the compiler output with KLIPSE (a cool tool I built)

Yehonathan Sharvit22:04:05

But it’s not easy 😞

Yehonathan Sharvit22:04:20

I see that we first check if the method exists in the object itself (in its prototype)

Yehonathan Sharvit22:04:37

and if not we check in the protocol object

Yehonathan Sharvit22:04:16

That’s the perf hit that you mentioned with base types?

Yehonathan Sharvit22:04:38

@dnolen: did I understand u correctly?

dnolen22:04:58

sorry gotta run