is there an idiomatic way to get the type of a variable in CLJS?

jlongster: goog.typeOf

also type

thanks!

Weird...

I'm trying to define a macro and use it in cljs. I created the macro in a clj file (util.clj) in my clojurescript source directory. The compiler wasn't able to find the namespace. But when I added an empty util.cljs file in the same directory, the compiler was happy and everything worked. Is that expected, or am I missing something?

I thought I understood this, but now I’ve got myself confused. If I want to access the properties of a JS event under advanced compilation, should I use (.-target evt) or (goog.object/get evt “target”) or is there no difference?

I always use aget with strings

(aget js-obj "foo" "bar")

The GClosure compiler never touches strings, so it's safe with advanced compilation

aget isn’t recommended for access on objects https://groups.google.com/forum/#!searchin/clojurescript/aget/clojurescript/XJLWNnMR5ik/DcSY_yfnFgAJ, forgot to mention that

hmm

it's doubtful I will stop using it that way

@sashton: Do you have two different source directories for the two languages? Like src/clj and src/cljs?

I just read that thread; I see where David is coming from

@sashton: I tend to define my macros in a src/clj/app/macros.clj and require them in my CLJS code with the :require-macros ns form.

@sashton: https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure (macro section might be useful)

is this a bug in CLJS? https://gist.github.com/jlongster/d5f1ef9b89f8647e2579

@sonelliot I thought I read somewhere that the macro file needed to be in the clojurescript classpath, src/cljs/.../macros.clj

@sashton: I haven't heard of that sorry 😕 It's my understanding that macros need to be done in a separate compilation phase. Although this may be different with self-hosted CLJS.

Ok I'll try it again tomorrow, thanks

@jlongster: I think case only works w/ literals — e.g. js/ variables won’t work. It also doesn’t work with vars; it has to be ints, chars, strings, etc

Option {:keywordize-keys true} for js->clj function doesn’t seem to work as expected for me. This is an output from my repl

cljs.user=> (get (js->clj (clj->js {:a 1}) {:keywordize-keys true}) :a)
nil
cljs.user=> (get (js->clj (clj->js {:a 1}) {:keywordize-keys true}) "a")
1
cljs.user=> (get (js->clj (clj->js {:a 1}) :keywordize-keys true) :a)
1
cljs.user=> (get (js->clj (clj->js {:a 1}) :keywordize-keys true) "a")
nil

@acron: in Garden, attributes are given in a map, but sometimes you need multiple defs of an attribute, in which case can't do that in a map because duplicate keys

@octo221: Do you mean for CSS such as "border: 1px solid red" ?

@octo221: in Garden for multiple attribute values you use a nested vector, e.g. {:border [[(px 1) :solid :red]]}

@acron, no multiple definitions of the same attribute

what's the use case for that?

e.g. "image-rendering=pixelated image-rendering=moz-crisp-edges ..."

because different browser use different defs

@octo221: have you looked at the vendor prefix stuff?

not sure that'd help..

see examples here: https://developer.mozilla.org/en-US/docs/Web/CSS/image-rendering

that's for values I think

you're right 😕 in that case, no, i'm not sure how you'd do this

same attribute defined multiple times, can't be expressed with a map

unless maybe it can take vectors as keys as well as for values

need to read the source

@acron: found a workaround: add spaces like this [:.class {"attr" 7 " attr" 8 " attr" 9}]

@octo221: ouch! but nice 😛 I hope you've raised an issue in Garden

oh yeh good point

@jaredly ah thanks

has a complete THREE-JS extern file been written yet?

one on CLJSJS is half assed

on a second thought, one could write a JS parser to automatically generate the extern file of any library?

Theoretically, possibly not super easy though, or we would have one already.

I think that is the only missing link to bridge JS and CLJS now.

without extern files, the advanced optimization won't work

I think existing extern generators evaluate the JS code on Node (or such) and check the created JS object to create the extern

Easier than writing parser (or using one) directly

there is an extern generator?

export['a'+(''+Math.random()).substr(2)] = function(){...};

I'm trying to create a bootstrapped browser clojurescript evaluation environment with a namespace which has some macros/fns :used available in the evaluation state. My problem is - I cannot call macros. Should it be at all possible? E.g.:

;;;;;;;;;;;;;;;;;;;;;;;;;; my-ns.cljs - the context of evaluation
(ns my-ns
   (:use-macros [javelin.core :only (cell=)]
   (:require [javelin.core :refer (cell)])))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; eval.clj - evaluator helper to preload the ns into compiler state
(ns eval
  (:require [cljs.env :as env]
                       [cljs.analyzer :as ana]))

;; ---- mimics how the cljs.core ns is loaded
(defmacro dump-my-ns []
  (let [state <@U095WMJNR>/*compiler*]
    `(quote ~(get-in state [::ana/namespaces 'my-ns]))))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;; eval.cljs - provides the environment
(ns eval
   (:require [my-ns]))

(def state (empty-state (fn [state] (assoc-in state [::ana/namespaces 'my-ns] (dump-my-ns)))))

(defn eval [forms]
    (eval state forms {:eval js-eval, :ns 'my-ns, :def-emits-var true} println))


(eval '(def x (cell 1))) ;;; works
(eval '(def y (cell= x))) ;;; fails to find the "javelin.core$macros" ns when resolving the cell= macro

I see that cljs.js does a goog.require("cljs.core$macros") at the top of the file

but this doesn't magically add the mappings

@dm3: Have you set up a load function? (That way, :require, etc. can load the required code.)

@dm3: You may be able to also dump javelin.core and javelin.core$macros (it is not clear to me exactly how to do that, but I suppose you can imitate what the compiler does with core), but while that takes care of the analysis metadata, there’d be the issue of loading the actual code that implements the cell= macro.

@dm3: cljs.js is designed to compile macro code as a result of (dynamically) loading it via the load function. Perhaps you are wanting to AOT transpile the macro code so that its JavaScript is available.

tools.reader says ::ana/namespaces is not a valid token… but it’s in the cljs source https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/js.cljs#L116 — is there some extra config I need to set to make it parseable?

@jaredly: If you control the source you are trying to evaluate in bootstrap, you could consider working around it by using :cljs.analyzer/namespaces

I’m actually working on making a parser, and benchmarking it against tools.reader by reading all of the cljs source, but then I ran into something tools.reader couldn’t handle 😄 so I’m confused

:ana/namespaces in cljs.js would be properly resolved/expanded by the regular JVM-based ClojureScript compiler. Bit, in bootstrapped ClojureScript, there is probably a bug or shortcoming.

(If you aren’t in bootstrap, it is probably still just a shortcoming of that library.)

yeah it’s bootstrapped

I think that corner cases like this one, and recently syntax quoting of symbols, are just bugs being discovered and sorted.

cool. should I report?

To list them off:

`x

`catch

#{1 2 1}

@jaredly: If you report a bootstrapped issue against ClojureScript—I took a stab at documenting the special considerations when doing that: https://github.com/clojure/clojurescript/wiki/Reporting-Bootstrap-Issues

Using these instructions (https://github.com/cljsjs/packages/tree/master/nvd3), I’m trying to use nvd3 packaged by cljsjs like this (https://gist.github.com/sooheon/10a7de8ea0c8c654c2f3). With advanced compilation, the functions still get mangled. Am I doing anything obviously wrong?

@sooheon: it shouldn’t be happening as the objects you are using have externs. could you try turning on :pseudo-names in compiler options to see which ones are getting mangled? details here: https://github.com/clojure/clojurescript/wiki/Compiler-Options#pseudo-names

@rohit sure. recompiling now

I’m seeing the same error in console, how do I see this additional information?

@sooheon: hmm…the error should which name is missing. whats the shape of line-chart-data in your code? perhaps i can help you debug this

here’s the source code and main.js side by side

@sooheon: issue seems to be useInteractiveGuideline

…and it seems that it is missing from the extern

ah that’s all it is. same with axisLabel below, and so on

looks that way

could you give me an example of how to add, say axisLabel to externs? Not sure of what class it belongs to and so on… do I just have to look at the nvd3 docs?

nv.models.lineChart().axisLabel = function(){}; would this work?

nope

let me see if i can generate the externs using a program which can create externs

@sooheon: bummer. looks like externs will need to be done by hand

you can certainly add nv.models.lineChart.axisLabel = function(){} to the bottom of the extern file

and also nv.models.lineChart.useInteractiveGuideline = function(){}

yeah it’s a really one off case, so I don’t doing it by hand, just not sure of the js syntax

Ok, thanks. Actually, something completely different, but how would you add externs to use these dropdowns from semantic-ui? http://semantic-ui.com/modules/dropdown.html#/examples

The function is just .dropdown, but somehow it seems like doing .dropdown = function(){} would not work

https://cdnjs.cloudflare.com/ajax/libs/semantic-ui/2.1.8/semantic.js

not sure how to handle the jQuery bit. let me have a look

Here’s the js file, if you need it^^

have a look here: https://github.com/cljsjs/packages/blob/master/jquery-daterange-picker/resources/cljsjs/common/jquery-daterange-picker.ext.js

that should be similar to your extern.

ok so it should all go under jQuery.prototype?

that would make sense

Got it, thanks :)

sure. best to ping in #C0E66E1H7 as well, a channel dedicated to stuff like this

@mfikes thanks - think I understand the issue now

@gzmask: have a look at this project for generating externs automatically: https://github.com/jmmk/javascript-externs-generator

this may generate full externs

@gzmask: the above project will not be able to handle something like this

var Person = function(name) {
  
  this.name = name;
  this.greet = function() {
    .....
  }
}

or rather it won’t be able to generate the full extern for Person

i think to generate externs for this may require you to get the information from the AST. but don’t hold me to it.

@rohit: I think that mention was meant for me—thanks.

actually @gzmask also raised this issue a few hours ago. but yup, (i think) this is the reason why the nvd3 externs aren’t complete

yea, this extern thing is starting to get out of hand when dealing with large and complicated libraries. I might just give up advanced optimization and go with simple.

If you're doing this for browser that might not be a good idea - non-optimised Clojurescript application can be in megabytes.

If you're doing it for node, then that's probably a good idea.

how large is the core lib of cljs? megabytes?

if you don’t use advanced optimization you don’t get fancy stuff like dead code elimination etc.

ClojureScript with advanced optimizations starts around 20K gzipped and goes up from there, depending on what you’re doing

I guess we do need perfect extern auto-generation then (AST parsing?)

but if you’re using Three.js you’re already OK with a fairly large dep, >100K gzipped

to be clear no you don’t need perfect externs

you can just make a file with all the bits you are actually using

externs aren’t related to dead code elimination - it just prevents advanced optimization renaming

that means I should be using advanced in development profile then?

no

you only need to identify the APIs bit you are actually using

you don’t need to worry about anything you don’t actually call, or property you don’t actually access

that's what I have been doing, everytime I do JS interop I have the extern file open for updating

that’s the only way then - or use something that’s Closure friendly like Toxi’s stuff

I guess that's the price we have to pay for using CLJS.

right though difference in the payload is dramatic

wait, if every time we do (js/sth) an extern sth should be generated, then extern generation could still be automated ?

was slated to be part of the GSoC project but we didn’t get to that bit

anybody can work on it, though probably worth getting in touch with Maria Geller to see if she started down some particular path

excited! when cljs has built-in dead-code-elimination, it will just become a unicorn ; )

well this feature was dubbed “externs inference"

it’s not a particularly a hard task - if it’s going to happen somebody who cares should work on it

(we’re unlikely to bother with much DCE of our own, Closure Compiler is works perfectly well)

on the externs inference bit happy to show anyone who is serious about tackling what needs to be done

but yes inferring js/foo + js type hint should cover most typical non-Closure JS interop

this: http://dev.clojure.org/jira/browse/CLJS-1074

@gzmask: yep

Howdy! I had a question about bundling JS libs into my compiled Closurescript. I’ve added the libs that I want such as JSTZ to my project.clj like so…

:foreign-libs [ {:file ""
                                           :file-min ""
                                           :provides ["jstz”]}

killion: https://github.com/clojure/clojurescript/wiki/Dependencies#bundling-foreign-javascript-code

you need to require it (and possibly even call it) in order for it to be prepended to your output file

Ah, I was wondering if that would be necessary. Thanks, let me try that now.

Yup, that was it exactly. Man I wish I had asked yesterday. Thanks!

@gzmask: I would say that the auto extern generation task is halfway complete. Functionality for parsing existing externs and emitting externs for simple js interop, like (.-foo bar) already works. Still need to add extern generation for more complex js interop, e.g. let bindings. I’ve pushed my progress to a separate branch here (https://github.com/mneise/clojurescript/tree/CLJS-1074). Help is always welcome

Nice @maria, I’ll see if the externs I’m calling are missing any interop types that your branch doesn’t support.

btw, when is ClojureScript 1.8 is planned?