Clojurians
#cljs-dev
<
2016-04-20
>

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

r0man12:04:02

@dnolen: Hello David, would you accept a patch that makes (.for js/Symbol "react.element") printable in ClojureScript? At the moment this raises the follwoing exception: #object[TypeError TypeError: Cannot convert a Symbol value to a string]

dnolen12:04:46

@r0man: need more context, nothing in your last sentence makes any sense to me

dnolen12:04:56

I haven’t been following the Symbol stuff very closely.

r0man12:04:11

React uses (.for js/Symbol "react.element") in it's nodes. They have a $$typeof property on their node that is an instance of js/Symbol.

r0man12:04:26

When you try to print one of those nodes in the REPL you get an exception.

anmonteiro12:04:24

FWIW, I’ve seen this too. React Symbols can’t be printed with println. js/console.log works fine (as expected)

r0man12:04:33

I think it should print as #object[Symbol "react.element"] and not throw an exception

dnolen12:04:29

is there a reliable Symbol predicate?

dnolen12:04:57

modifying the Symbol prototype is out of the question

dnolen12:04:09

users can do that themselves

dnolen12:04:45

if there is a symbol predicate then also have to consider feature detection

anmonteiro12:04:53

@dnolen: goog/typeOf returns “symbol”

dnolen12:04:17

probably won’t work with shims

r0man12:04:59

extending the js/Symbol with the printer protocol didn't work for me, so I tried hooking into pr-writer-impl

r0man12:04:11

and yes, I used goog/typeof

dnolen12:04:23

extending the protocol to js/Symbol is unacceptable anyway

dnolen12:04:37

goog/typeOf isn’t good enough because of shimming

dnolen12:04:07

so I’m interested as long as the patch addresses these two points

r0man12:04:34

do you have an idea, how to solve the shim problem?

dnolen12:04:44

I’m not going to spend anytime on this myself :simple_smile:

r0man12:04:02

was looking for a hint. :simple_smile:

r0man12:04:14

should I open a ticket for this?

dnolen12:04:29

yeah I have no idea - I would look around to see what people might be doing in JS land around Symbol shims

dnolen12:04:41

collect information and then proceed

dnolen12:04:45

@r0man: sure

dnolen12:04:59

we do detect Symbol in cljs.core already for ES6 iterator support

dnolen12:04:06

so worth looking at that too

r0man12:04:36

@dnolen Yes I saw this. I'll open a ticket a attach a patch

roman01la12:04:25

@dnolen: Could you give any hints on where to look at for http://dev.clojure.org/jira/browse/CLJS-1620 ?

roman01la12:04:37

I’d like to invest into this issue, but can not figure out where to start.

dnolen12:04:53

@roman01la: look at the munging stuff in compiler.cljc, you’ll see that it uses a js-reserved set

dnolen12:04:22

it should probably only do this if the language setting is appropriate

dnolen12:04:48

cljs.compiler/munge is the place to start

dnolen12:04:31

then look at the cljs.closure namespace for the language setting stuff

dnolen12:04:08

the compiler binds all the compiler options to a dynamic var - this is what you may need to check in cljs.compiler/munge if threading the options through is too invasive

mfikes14:04:56

http://dev.clojure.org/jira/browse/CLJS-1626 (cljs.test for bootstrap) is now working. A gist showing running the compiler tests the normal way and via bootstrapped ClojureScript in Node: https://gist.github.com/mfikes/b0f28f2bd6442e79d072d30baf68a6a9

mfikes17:04:46

@dnolen: http://dev.clojure.org/jira/browse/CLJS-1626 (cljs.test for bootstrap) would involve changing a couple files from .clj to .cljc. Is your preference to have the renames done first? (To make it easier to see the subsequent diffs.) (I don’t mind either way, just want to do what’s easiest for review in the end.)

dnolen17:04:46

@mfikes: having one patch that does everything together is preferred

mfikes19:04:18

OK, a candidate patch for http://dev.clojure.org/jira/browse/CLJS-1626 is in the ticket. Pretty exciting change :simple_smile: If you are into bootstrap, please give this one a spin to see if it works for you.

dnolen19:04:38

@r0man: the patch source seems contradictory

dnolen19:04:53

a typeof check for both “function” and “symbol” ?

anmonteiro19:04:05

@dnolen: I was also looking at the patch, I think that the check for “function” is against the constructor

anmonteiro19:04:13

while the check for “symbol” against the instance

anmonteiro19:04:14

I’m just left wondering if for strings using identical? or = is interchangeable

r0man19:04:15

@dnolen I'm awfk at the moment. Leave a comment and I'll take a look tomorrow

dnolen19:04:42

@anmonteiro: ah k, still @r0man seems undesirable from shim perspective unless you’ve confirmed shims do the right thing with goog.typeOf

dnolen19:04:33

@r0man: sounds good, added both my comments to the ticket