"lein cljsbuild" generates "Symbol X is not a protocol" warning. The following code snippet reproduces the issue. Renaming "my.foo" namespace to "foo" compiles with no warning.

;; file:: foo.cljs
(ns my.foo)

(defprotocol IFoo
(bar[this]))

;; file: fubar.cljs
(ns fubar
(:require
[my.foo :as foo]))

(deftype FuBar []
foo/IFoo
(bar [this]))

cljs output:
WARNING: Symbol foo/IFoo is not a protocol at line 5 src/fubar.cljs

1) IReduce protocol is missing implementation for array and List.
2) append! uses (.add array), while the correct array method name is push

Patch attached.

Note: what is your experience with array.push performance? ClojureScript reducers/foldcat uses arrays for append! / cat implementation. My experience was that (into [] ...) using conj! and TransientVector was at least 5 times faster than reducers/foldcat using array and push. The reason is probably inefficient push implementation in Chrome/V8

Put together an easy to run series of persistent data structure benchmarks that can be easily run. For example we would like to submit to this Mozilla ticket http://bugzilla.mozilla.org/show_bug.cgi?id=874174

Problem:
Some code has different semantics when compiled in advanced mode.
Clojurescript tries to minimize those cases, but examples are usage of aget or forgotten externs files.
There exits closure compiler options to generate names based on original expressions, even with advanced optimizations.
However, there exists no clojurescript compiler option for that.

Proposal:
Add a :debug compiler option to clojurescript, which can be set to true to turn the following closure compiler options on:

• generatePseudoNames true
• anonymousFunctionNaming AnonymousFunctionNamingPolicy/UNMAPPED

Attached patch implements this, as a result the compiled test suite is indeed quite readable.

reduce-kv seems to fail with certain datasets in clojurescript but works in clojure. plain reduce works in both. Test dataset and functions:

(def tst '{0 (0.16245458703559382 0.16299961144753652), 1 (0.17095488518209803 0.1662484375243468), 2 (0.19709700082585824 0.1876248353737042 0.18162592547515274), 3 (0.21941419798490325 0.21807914100386067 0.21533585716040135 0.21307519864852958 0.20703453840254027 0.20459935129415552), 4 (0.2254558759699653 0.22553167887455705 0.2234426184638531), 5 (0.23427611508459756 0.2325434766605363 0.22990656317710662 0.22720478209110223), 6 (0.236386202300682 0.237142940385559 0.23819488667547528 0.23768692982616965 0.23701568705350426 0.2519226069678777), 7 (0.23496439825060444 0.2366135730772095 0.2358487071572212 0.2343505595436482 0.2339754113241729 0.23574632954272087 0.2342899279492302 0.23394402094793673 0.2253325456308313 0.23115349467838542 0.23764956541775945 0.24569178483873644 0.24935940319340053), 8 (0.20547261591662125 0.20726089154784122 0.21592818189465432 0.21750737743637422), 9 (0.18799738410585773 0.195400717149256 0.19631498833296726), 10 (0.1719302696659648 0.17805792401151166 0.18237267730425885), 11 (0.1623645568284537 0.16481390708298796 0.16716904262359314), 12 (0.16156804839942243 0.16211838120784386), 13 (0.16995648347966535 0.16559349825186068), 14 (0.19176771652550495 0.17696322624338934), 15 (0.23973485828855146 0.22420582245618542 0.2145975801770993 0.20208630026741867), 16 (0.2946896009888785 0.28676176338007714 0.28325454941805994 0.2716914099321759 0.26202250017945194 0.25452401319317824 0.2458771184353157), 17 (0.33300741045445653 0.3282046117335755 0.32330639472087175 0.3191873692036449 0.31290612056170736 0.30418343504691503 0.3004101566486822), 18 (0.341869650592079 0.34431149263906713 0.3457698150448536 0.34421452862514235 0.3429726966458358 0.3388988973880783 0.33579154357727864), 19 (0.2968748091051211 0.3023852506442652 0.3121637065261914 0.31141190562184173 0.32205821745972246 0.32898706631919056 0.33322752162957553 0.3396066565159988), 20 (0.2317683974879252 0.24538548478582375 0.2645130722935203 0.27362218406430894), 21 (0.20128274621982342 0.21819083560963268), 22 (0.1732991500114435 0.1811216605973363 0.19151484878018085), 23 (0.16575238432187128)})

; this returns nil in clojurescript, returns a sorted dataset in clojure.
(defn sortpi [pi]
(reduce-kv (fn [c k v] (assoc c k (sort v))) {} pi))

(sortpi tst)

; this version works in both clojurescript and clojure:
(defn sortpi2 [pi]
(reduce (fn [c [k v]] (assoc c k (sort v))) {} pi))

(sortpi2 tst)

This is in CLJS v. 0.0-1803

The original symptom was that these objects didn't round-trip properly:

cljs.user=> (js->clj (clj->js {}))
{"" nil}

A little more digging shows the underlying issue:

cljs.user=> (seq (array)) 
(nil)

The same issue, with the same fix, exists for strings, so I'm including that here as well.

We check for nil coercively with != and = because we want to handle both JavaScript null and undefined. These operations are slower than !== and ==. We would like to fix this but we can't simply make nil? not be coercive. The persistent data structures rely on this because they reach into JS Arrays that been allocated with a certain size. However in JS the empty slots are filled with undefined and null requiring the more expensive coercive nil? check.

Making nil? non-coercive seems to bring less of performance boost in WebKit/Firefox Nightlies, but v8 is still the king and everyone seems to be moving towards it performance wise.

One issue with making nil? non-coercive is that undefined will then fall through many of the core library functions. This means that users will need to be more careful in interop scenarios.

This is helpful in JVM Clojure for replacing vars for testing purposes (think mocks/stubs).

adding per discussion w/ David Nolen in #clojure IRC

we often type-hint return values as boolean when they are not, we should instead provide a boolean coercion fn like Clojure has.

When compiling something like spectral norm http://github.com/swannodette/cljs-stl/blob/master/src/cljs_stl/spectral/demo.cljs where no ClojureScript data structures are used we still see many constructors in the advanced compiled output. The total KLOC of pretty printed advanced compiled code using master is ~3800.

Quick testing shows that the following ctors are present in spectral norm:

PersistentTreeMap
RedNode
BlackNode
PersistentTreeMapSeq
TransientHashMap
PersistentHashMap
ArrayNodeSeq
NodeSeq
HashCollisionNode
ArrayNode
BitmapIndexedNode
TransientArrayMap
PersistentArrayMap
ObjMap
NeverEquiv
TransientVector
ChunkedSeq
PersistentVector
VectorNode
ChunkedCons
ArrayChunk
ChunkBuffer
LazySeq
Keyword
Cons
EmptyLIst
List
IndexedSeq

We removed the runtime function dependency of cljs.core.PersistentTreeSet/EMPTY, all ctors related to PTSs disappeared.

Removing the runtime constructions of the other EMPTY collections seems to have no further effect on code size, probably because we have avoided dependencies elsewhere.

Here are some benchmarks after performance improvements have been applied to PersistentArrayMap in master:

• ObjMap vs PersistentArrayMap 1 entry -lookup, http://jsperf.com/ojbmap-vs-persistentarraymap-lookup-1
• ObjMap vs PersistentArrayMap 3 entry -lookup, http://jsperf.com/objectmap-vs-persistentarraymap-3-lookup
• ObjMap vs PersistentArrayMap 7 entry -lookup, http://jsperf.com/objmap-vs-persistentarraymap-7-lookup

For the smallest sizes PAMs are nearly identical in performance to OMs, as we start nearing the PHM threshold PAMs are nearly 2X faster on WebKit Nightly, and nearly 3X faster on the latest Chrome. Only Firefox Nightly lags behind for lookup times at larger sizes.

• ObjMap vs PersistentArrayMap assoc empty, http://jsperf.com/objmap-vs-persistentarraymap-assoc-empty
• ObjMap vs PersistentArrayMap assoc 3kv, http://jsperf.com/objmap-vs-persistentarraymap-assoc-3
• ObjMap vs PersistentArrayMap assoc 7kv, http://jsperf.com/objmap-vs-persistentarraymap-assoc-7kv

Again we see nearly identical (or much better) performance at small sizes and much better performance for PAMs as we approach the PHM threshold.

On V8, PAMs are competitive with OMs. On other browsers the performance doesn't look as good but this is probably due to the higher order code in array-map-index-of. We should remove the higher order code and more closely follow the Java PAM implementation which has different lookup loops for the different cases.

We should optimize constant literals, in particular keywords. This optimization means that we will have to decide whether to make identical? slower by testing for keywords (this means it's probably a bad idea to continue to inline it) or to provide a special keyword-identical? that does the right thing.

There are a number of compatibility functions that are currently defined as identity functions. Among these, char

Suggested better implementation for char:

(defn char [code]
(.fromCharCode js/String code))

rather than current

(defn char [x] x)

(not sure of compatibility with node)

The current `undefined?` function will blow up with a JavaScript reference error if you pass it an undeclared variable.

It'd be nice to have a way to test if a JavaScript variable has been declared.
My use case is writing a ClojureScript library that extends cljs protocols to JavaScript things.
I'd like to write

(when-not (undefined? js/jQuery)

...)

to extend-type jQuery when jQuery is around.

I noticed that -lookup method is called incorrectly at two places

There are two -lookup methods defined for ILookup:

cljs/cljs/core.cljs:198
(defprotocol ILookup
(-lookup [o k] [o k not-found]))

clj/cljs/core.clj:426
(defmacro get
([coll k]
`(-lookup ~coll ~k nil))
([coll k not-found]
`(-lookup ~coll ~k ~not-found)))

As you see, macro (get foo bar) never calls first method. In first case it supplies default argument (instead calling method with 2 arguments).

Same for IFn and keywords:

(deftype Keyword [k]
IFn
(invoke [_ coll]
(when-not (nil? coll)
(let [strobj (.-strobj coll)]
(if (nil? strobj)
(-lookup coll k nil)
(aget strobj k)))))

The following throws instead of returning nil:

(get 42 :anything)

A function like

(defn bar [a b c d e f g h i j & more])

currently receives a cljs$lang$applyTo property of the following form:

function (arglist__4466) {
    var a = cljs.core.first(arglist__4466);
    var b = cljs.core.first(cljs.core.next(arglist__4466));
    var c = cljs.core.first(cljs.core.next(cljs.core.next(arglist__4466)));
    var d = cljs.core.first(cljs.core.next(cljs.core.next(cljs.core.next(arglist__4466))));
    var e = cljs.core.first(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(arglist__4466)))));
    var f = cljs.core.first(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(arglist__4466))))));
    var g = cljs.core.first(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(arglist__4466)))))));
    var h = cljs.core.first(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(arglist__4466))))))));
    var i = cljs.core.first(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(arglist__4466)))))))));
    var j = cljs.core.first(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(arglist__4466))))))))));
    var more = cljs.core.rest(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(cljs.core.next(arglist__4466))))))))));
    return bar__delegate(a, b, c, d, e, f, g, h, i, j, more);
}

The forthcoming patch changes that to

function (arglist__4460) {
    var a = cljs.core.first(arglist__4460);
    arglist__4460 = cljs.core.next(arglist__4460);
    var b = cljs.core.first(arglist__4460);
    arglist__4460 = cljs.core.next(arglist__4460);
    var c = cljs.core.first(arglist__4460);
    arglist__4460 = cljs.core.next(arglist__4460);
    var d = cljs.core.first(arglist__4460);
    arglist__4460 = cljs.core.next(arglist__4460);
    var e = cljs.core.first(arglist__4460);
    arglist__4460 = cljs.core.next(arglist__4460);
    var f = cljs.core.first(arglist__4460);
    arglist__4460 = cljs.core.next(arglist__4460);
    var g = cljs.core.first(arglist__4460);
    arglist__4460 = cljs.core.next(arglist__4460);
    var h = cljs.core.first(arglist__4460);
    arglist__4460 = cljs.core.next(arglist__4460);
    var i = cljs.core.first(arglist__4460);
    arglist__4460 = cljs.core.next(arglist__4460);
    var j = cljs.core.first(arglist__4460);
    var more = cljs.core.rest(arglist__4460);
    return bar__delegate(a, b, c, d, e, f, g, h, i, j, more);
}

The included benchmark seems to demonstrate a substantial reduction in {apply} overhead on V8 for a function with 10 positional arguments preceding the rest arg and a less substantial reduction for a function with 2 positional arguments, as one would expect. The other benchmark entries for {apply} remain in the same ballpark ({list} actually produces the same compilation output with or without the patch; {+} is changed, but only slightly).

cljs.core/subvec (or rather build-subvec, the implementation detail behind it) currently fails to check whether its vector argument is already a Subvec and, if so, base the new Subvec off the original regular vector. The Clojure implementation does perform the unwrapping.

The forthcoming patch fixes this and includes a basic test.

get-upstream-deps* currently uses the context classloader for the current thread, which causes issues when called from within a clojure runtime that has the intended classloader bound to Compiler.LOADER. Is there a specific reason to use the TCCL directly, or would calling RT.baseLoader suffice here? I'm attaching a patch that uses baseLoader instead.

The current implementation of browser-REPL yields a number of usability problems:

• only one browser-REPL can be used at a time due to globals used to track REPL state
• Browser-REPL currently involves two web servers: the one you're serving your app from, and the one that the REPL itself uses
  • This makes setup difficult in the interactive case — especially for newcomers, the less experienced, or the tired
  • Perhaps more significantly, coordinating the two servers and their associated state is less than easy if one wants to automate the browser-REPL for testing of DOM-related cljs code

Attached is a patch that addresses these issues:

• Multiple concurrent browser-REPLs can be safely used
• The browser-REPL's HTTP server is now always-on
• Replaced the custom HTTP server with com.sun.net.httpserver.* bits, which are a part of J2SE 6+, not random implementation details http://docs.oracle.com/javase/7/docs/technotes/guides/net/enhancements-6.0.html
• Each browser-REPL session supports a new top-level "entry" URL that can be used to easily start the REPL in a browser or other JS runtime (i.e. you don't need to have a separate webapp running to initiate the browser-REPL connection)
• The entry (and REPL) URLs are available in slots on the browser-REPL's environment, making it trivial to automate browser-REPL sessions with e.g. phantomjs or a headless chromium or etc. This pattern is implemented by a new `exec-env` function; the default is to start the REPL in phantomjs using a temporary script, but it's super-easy to use a regular browser. e.g. this will use Chrome on OS X in the background:

(cljs.repl/repl (cljs.repl.browser/exec-env
                  :exec-cmds ["open" "-ga" "/Applications/Google Chrome.app"]))

(This enhancement has been discussed previously {here|http://groups.google.com/group/clojurescript/browse_thread/thread/963d6b7334bdf61c}.)

The folks from Pedestal encountered this.

I'll like cljsc to copy my js sources to the public directory as it does when compiling the cljs sources and make the correct entry in the generated deps.js so that the source can be retrievable with GET without extra configuration.

External tools often have the need to redefine ClojureScript's
cljs.core.print-fn var in order to get printing in different
runtimes working. In a browser environment it is usually
redefined to console.log for example.

This works fine in whitespace and simple mode because the
cljs.core.print-fn var is accessible from the outside
environment. However, in advanced mode the cljs.core.print-fn
gets renamed and external tools can't access this var anymore.

Since it looks like redefining cljs.core.print-fn is common
task, it would make sense to add ^:export to it's meta data to
prevent the Goolge Closure Compiler from renaming it.

References:

• http://clojure-log.n01se.net/date/2013-03-12.html#14:25
• https://github.com/cemerick/clojurescript.test/pull/2#discussion_r3334941

The replace function in namespace clojure.string ignores regex flag provided in the match pattern. For example:

clojure.string/replace "I am NOT matched" #"(?i)not " "")
=> "I am NOT matched"

clojure.string/replace "I am NOT matched" #"(?i)not " "")
=> "I am matched"

The attached patch fixes this by parsing the m and i flags, if set, from the match object, instead of explicitly setting only "g".

Test case

> (defmulti foo bar {:hierarchy h})
java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Throwable

with the attached patch this is
clojure.lang.ExceptionInfo: The syntax for defmulti has changed. Example: (defmulti name dispatch-fn :default dispatch-value)

lein-cljsbuild compiles files via cljs.closure/compile-dir which in turn calls compile-file. If one file fails to compile it can be rather hard to find out which file caused the error since the reference to the file is lost.

The patch ensures that the file is known and wraps the compile exception.

See example confusing trace:
https://gist.github.com/thheller/5103320#file-lein-cljsbuild-stracktrace-txt

And the more helpful version:
https://gist.github.com/thheller/5103320#file-better-trace-txt

All non-terminal REPLs bind *out*, so printing REPL output to System/out is unexpected (and sometimes black-holed depending on the environment).

Attached patch binds *out* in place of System/out in the Rhino evaluation Context.

This seems to be a subtler version of CLJS-39:

(let [fs (atom [])]
  (doseq [x (range 4)
          :let [y (inc x)
                f (fn [] y)]]
    (swap! fs conj f))
  (map #(%) @fs))

;; => (4 4 4 4)
;; should be (1 2 3 4)

I think this example is minimal. The bug is not present if we use a proper let.

It looks like *cljs-data-readers* is not being bound to *data-readers* where it should be.

At a minimum, cljs.repl/load-stream does not. The practical effect of this instance is that e.g. (load-file "some/cljs/file.cljs") will fail if that file or any other contains a user-defined literal tag. Similar behaviour exists elsewhere, e.g. (load-namespace 'some.cljs.ns) will not load a namespace that contains user-defined tags (I think that one is due to *cljs-data-readers* not being bound in the analyzer).

This is related to CLJS-479 insofar as it's another symptom of ClojureScript loading code in subtly different ways in multiple places.

I'm happy to do either of:

1. submit issues+patches fixing issues as I encounter them, or
2. attempt a more significant refactoring that sets up (hopefully) one and only one place where ClojureScript reads code (i.e. uses LispReader) so that behaviour can be consistent

I'm somewhat hesitant re: (2) insofar as the specific requirements of the compiler and analyzer and REPL may be divergent in ways that I'm not yet aware of, but it seems like it's worth a shot.

This can be seen by opening a REPL and:

(load-file "cljs/ns_test/foo.cljs")

The ::foo keyword in that file is resolved improperly:

ClojureScript:cljs.user> cljs.ns-test.foo/kw
:user/foo

cljs.repl/load-stream needs to force *ns* to track *cljs-ns* so that the Clojure reader will properly resolve auto-namespacing keywords. A patch is attached that does this, ensuring that any Clojure namespaces created solely for this purpose are removed.

I've updated to 0.0-1586 build #22 from a much older release: 0.0-1450

I'm now geting a problem with (js->clj token) not converting token to a map; this worked before I upgraded.

token is generated by the google OAuth 2 process: "gapi.auth.authorize"

I don't think the problem is with js->clj rather something about token so it isn't recognised as a js/Object.

(println (expose token true)) gives:

access_token = ya29.AHES6ZSgnk3Ws5bB-2aDx41Bbr335hKugjZJfcNAs83d121S306fxy64
token_type = Bearer
expires_in = 3600
client_id = 52351124085.apps.googleusercontent.com
scope = https://www.googleapis.com/auth/drive.file,https://www.googleapis.com/auth/drive.metadata.readonly,https://www.googleapis.com/auth/drive.readonly
g_user_cookie_policy = undefined
cookie_policy = undefined
issued_at = 1361807171
expires_at = 1361810771

This looks ok.

however
> token

gives:

"Error evaluating:" token :as "esef.client.evidence.token"
#<TypeError: Object [object Object] has no method 'toString'>
TypeError: Object [object Object] has no method 'toString'

> (type token)

gives a blank line. I think this is why js->clj isn't converting.

> (alength token)

gives a blank line.

(.-token_type token)

Correctly gives ya29.AHES6ZSgnk3Ws5bB-2aDx41Bbr335hKugjZJfcNAs83d121S306fxy64

I haven't managed to recreate 'token' with a minimal test case but I'm fairly new to javascript. It's impractical to to include my OAuth 2 code because its tied into all my google security.
If you can suggest anything that will provide you with more info on 'token' I'll try and help.

As a work-around I manually create the MAP by explicitly reading each property, I couldn't get a list of properties.

If the first of the variable arguments to a vararg function is the javascript value undefined, the function behaves as though it didn't receive any variable arguments at all:

(defn f [& rest] rest)

(f 1 2 3)
;; => (1 2 3) ; correct

(f 1 js/undefined 3)
;; => (1 nil 3) ; correct

(f js/undefined 2 3)
;; => nil ; wrong

Referring to a value in a module can have a scoping issue when using the "static accessor" operator of module/VALUE_NAME. The static accessor works if the module is loaded into a local value but not if def'ed. This example uses the mmap module for Node.js, and successfully reads the PROT_READ value:

(ns stat.core)
(defn -main []
(let [m (js/require "mmap")]
(println "value: " m/PROT_READ)))
(set! main-cli-fn -main)

This correctly prints "value: 1"

However, if the value for m is def'ed instead, then the compiler assumes that the reference to m is local to the function and therefore not defined:

(ns stat.core)
(def m (js/require "mmap"))
(defn -main []
(println "value: " m/PROT_READ))
(set! main-cli-fn -main)

/Users/pag/src/test/clj/stat/target/stat.js:12836
return cljs.core.println.call(null, "value: ", m.PROT_READ)
^
ReferenceError: m is not defined
at Function.stat.core._main (/Users/pag/src/test/clj/stat/target/stat.js:12836:50)
at cljs.core.apply.b (/Users/pag/src/test/clj/stat/target/stat.js:5621:14)
at cljs.core.apply.a (/Users/pag/src/test/clj/stat/target/stat.js:5656:18)
at Object.<anonymous> (/Users/pag/src/test/clj/stat/target/stat.js:12844:17)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)

In this case, the value of m.PROT_READ should have been stat.core.m.PROT_READ.

On the other hand, using . syntax fixes the scoping issue:
(ns stat.core)
(def m (js/require "mmap"))
(defn -main []
(println "value: " (.-PROT_READ m)))
(set! main-cli-fn -main)

Compiling a hello world program for Node.js works fine if using optimizations of :advanced or :simple, but if using :none or :whitespace then an error will be reported for either "goog undefined" or "goog.string" undefined respectively.

The program is shown here:

(ns pr.core)
(defn -main []
(println "Hello World!"))
(set! main-cli-fn -main)

This program is in src/cljs/pr/core.cljs. The repl line used to compile is:
(cljs.closure/build "src/cljs" {:output-to "src/js/pr.js" :target :nodejs :pretty-print true :optimizations :none})

When compiled with optimizations of :none, the output is:

$ node src/js/pr.js

/Users/pag/src/test/clj/pr/src/js/pr.js:1
(function (exports, require, module, __filename, __dirname) { goog.addDependen
^
ReferenceError: goog is not defined
at Object.<anonymous> (/Users/pag/src/test/clj/pr/src/js/pr.js:1:63)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)

—
When running with optimizations of :whitespace the output is:

$ node src/js/pr.js

/Users/pag/src/test/clj/pr/src/js/pr.js:493
goog.string.Unicode = {NBSP:"\u00a0"};
^
TypeError: Cannot set property 'Unicode' of undefined
at Object.<anonymous> (/Users/pag/src/test/clj/pr/src/js/pr.js:493:21)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)

—
When running with optimizations of either :simple or :advanced, the output is:

$ node src/js/pr.js
Hello World!

—
I have included the two javascript output files that match the above errors.

As mentioned here: https://groups.google.com/forum/?fromgroups=#!topic/clojurescript/ZX6M4KXx8I8

Naming every fn in the compiled javascript functions makes it a little easier to find out whats going on when looking at a stacktrace. This patch names every function generated as fn_<ns>/<orig-name>_<line>. See example stacktrace in the discussion above.

The optional cljs snippet (https://gist.github.com/thheller/4972200) then also transforms this data and prints functions as

(pr-str name)
=> #<function cljs.core/name line:5876>

instead of dumping the javascript source on you.

The .patch has the drawback that the generated source size grows a bit (about 10% on my codebase), but advanced compilation takes care of that (although even that is still a bit larger, the closure compiler doesnt seem to strip unused function names). One could make this a compiler option if the size differences are too big.

cljs.closure/add-dep-string calls wrong munge (Clojure one), while it should be calling cljs.compiler/munge.

The problem shows up when namespace contains a reserved js name and incremental dev build is performed.

An empty regexp of the form #"" compiles to //, which is not an empty regexp but a comment, causing the code following the supposed regexp on the affected line to be commented out. This tends to cause compiler errors when Closure Compiler tries to parse it.

#"" should instead produce either /(?:)/ or new RegExp("").

When a multi-fn has no dispatch method for a given value the current exception string prints the cljs.core/name function instead of the actual name of the mf. Minor bug but makes it kinda hard to track down which multi-fn actually failed to dispatch.

The attached patch fixes that but directly accessing the name property of the multi-fn which is not very clean but better than the current error. AFAICT cljs doesnt have the clojure.lang.Named protocol, which would probably be cleaner.

This has been accepted and fixed for Clojure in CLJ-1098

When gaps are present in an ArrayNode's array, kv-reduce would skip nodes after the first gap due to a missing else branch.

When printing a Record it is currently printed without the proper namespace.

(ns dummy)
(defrecord Foo [bar])
(pr-str (Foo. "bar"))

will print as "#dummy.Foo{..." in CLJ but "#Foo{..." in CLJS.

The attached patch fixes the implementation as well as the "incorrect" test.

Summary self explanatory

In Clojurescript:
(get-in {:a {:b 1}} [:a :b :c])
=> Error: 1 is not an instance of ILookup

In Clojure:
(get-in {:a {:b 1}} [:a :b :c])
=> nil

Currently it's not really possible to use to the existing deftype/record to construct "classes" that interop well with Google Closure. It seems odd to ship Closure and then provide no tools for writing ClojureScript against it, especially the UI component parts. Several people have asked for this now so perhaps we really should offer the ClojureScript equivalent of genclass.

cljs/reader.cljs:120 (def symbol-pattern (re-pattern "[:]?([^0-9/].*/)?([^0-9/][^/]*)"))
cljs/reader.cljs:330 a (re-matches* symbol-pattern token)

symbol-pattern is not consistent with clojure's interpretation of valid keywords, e.g. the following are valid keywords in clojure that are not allowed by this regex:

:0foo
:/foo/bar/baz

When running this loop, then the map's meta is lost after 32 assocs:

(loop [i 0, m (with-meta {} {:foo :bar})]
  (when (<= i 34)
    (.log js/console i (pr-str (meta m)))
    (recur (inc i) (assoc m (str i) i))))

The last 4 lines of output read

31 {:foo :bar}
  32 {:foo :bar}
  33 nil
  34 nil

cljs.core.ObjMap/HASHMAP_THRESHOLD happens to be 32, so I guess
there is a connection.

When an alternative hierarchy is provided to a defmulti declaration it should be used in place of the global hierarchy for isa?-based method dispatch. However, clojurescript multimethods seem to ignore this hierarchy and always use the global hierarchy. Test case provided.

On master, (reduce-kv prn nil (sorted-map :foo 1 :bar 2)) prints :foo before :bar. With the forthcoming patch applied, :bar comes first.

(get-in {:a {:b 1}} [:a :b :c] :nothing-there)

cljs throws exception "Error: No protocol method ILookup.-lookup defined for type number: 1"
clj returns :nothing-there

Following snippet contains an additional (satisfies? ILookup m) test to end iteration and return no-value.
If solution looks ok, I can provide a patch.

--------

(defn get-in*
  "Returns the value in a nested associative structure,
  where ks is a sequence of keys. Returns nil if the key is not present,
  or the not-found value if supplied."
  {:added "1.2"
   :static true}
  ([m ks]
     (reduce get m ks))
  ([m ks not-found]
     (loop [sentinel lookup-sentinel
            m m
            ks (seq ks)]
       (if ks
         (if-not (satisfies? ILookup m)
           not-found
           (let [m (get m (first ks) sentinel)]
             (if (identical? sentinel m)
               not-found
               (recur sentinel m (next ks)))))
         m))))

The following REPL snippets show different behavior for "unbound" vars in cljs and clj:

--------
ClojureScript:cljs.user> (def a nil)
nil
ClojureScript:cljs.user> (def b)

ClojureScript:cljs.user> (= a b)
true
--------
user=> (def a nil)
#'user/a
user=> (def b)
#'user/b
user=> (= a b)
false
--------

As a possible solution, D. Nolen suggested that we could "simulate this by creating a Unbound type and initializing def'ed vars without init expressions to instances of it."

In a fresh script/repljs on clojurescript master I see the following behaviour:

ClojureScript:cljs.user> (ns foo.bar)
ClojureScript:foo.bar> (defn id [x] x)
#<
  function id(x) {
      return x;
  }
  >
  ClojureScript:foo.bar> (defn foo [] (id 42))
  #<
  function foo() {
      return foo.bar.id.call(null, 42);
  }
  >
ClojureScript:foo.bar> (foo)
  "Error evaluating:" (foo) :as "foo.bar.foo.call(null)"
  org.mozilla.javascript.EcmaError: TypeError: Cannot read property "id" from undefined (<cljs repl>#4)
      at <cljs repl>:4 (foo)
      at <cljs repl>:4 (anonymous)
      at <cljs repl>:4
 
nil
ClojureScript:foo.bar>

(https://www.refheap.com/paste/8494 in case formatting fails)

The ClojureScript compiler happily accepts forms like js/Math.MAX_NUMBER and (js/Math.ceil 3.14) which is not valid Clojure code. The correct way to write these expressions in ClojureScript is (.-MAX_NUMBER js/Math) and (.ceil js/Math 3.14).

The ClojureScript analyzer should at least emit a warning when these bad forms are encountered. Preferably compilation should fail but that would probably break lots of existing code.

Any timestamps with a greater than millisecond precision cannot be handled by the ClouseScript reader:

> cljs.reader.read_date("2012-12-30T23:20:05.066980000-00:00")
> Error: Assert failed: timestamp millisecond field must be in range 0..999 Failed:  0<=66980000<=999 (<= low n high)

Here "2012-12-30T23:20:05.066980000-00:00" is an example of an ordinary timestamp that is returned from Postgres.

ClojureScript reader interprets the nanosecond portion "066980000" as milliseconds and the check here fails:

def parse-and-validate-timestamp
...
   (check 0 ms 999 "timestamp millisecond field must be in range 0..999")

Just like we have an ArrayMap for small maps, I propose to have an ArrayVector for small vectors.

Use cases:

• pair of values, e.g. coordinates, triples and other tuple values
• returning multiple values from a function and subsequent destructuring in a caller fn

ArrayVector has 100x faster vector creation compared to PersistentVector.
With an ^ArrayVector hint, it offers more than 10x faster destructuring. Without it, it is still about 40% faster.

Example of such destructuring:

(defn foo [a b] 
  [(+ a b) (- a b) (* a b)])

(defn bar []
  (let [[plus minus times] ^ArrayVector (foo 1 2)]
    (str "bla bla" plus "blaah" minus)))

I've attached a patch with complete implementation of such vector, supporting all basic functionalities as well as transients. This patch also replaces default vector implementation with ArrayVector, falling back to PersistentVector for large vectors.

ArrayVector implementation can also be found at array-vec branch at https://github.com/wagjo/clojurescript/tree/array-vec

In https://github.com/clojure/clojurescript/blob/master/src/cljs/clojure/browser/net.cljs there's a nicely prepared support for WebSockets with the note

;; WebSocket is not supported in the 3/23/11 release of Google
;; Closure, but will be included in the next release.

is there anything preventing us from enable the support for WebSockets with the next release of ClojureScript?

patch 0001-enable-websockets.patch do just enable the functionality. No test-cases included.

Keywords are currently implemented as JavaScript strings. This makes certain JavaScript interop situations awkward: to provide a javascript api a function that can pull data from a map, one must use #(:foo %) instead of the more natural :foo. This is confusing because ClojureScript functions are otherwise fully usable in contexts expecting JavaScript functions.

The proposed alternative is to have keywords instead be implemented as JavaScript functions that accept a map and optional default value, assuming this doesn't otherwise screw up their core functionality of providing fast equality tests, etc.

An (ns) within a (do) doesn't quite work as expected at the REPL:

ClojureScript:cljs.user> (do (ns foo) (def x 42))   
nil
ClojureScript:foo> x
nil
ClojureScript:cljs.user> cljs.user/x
42

The Clojure equivalent:

user=> (do (ns foo) (def x 42))
#'foo/x
foo=> x
42

Currently, ex-info exceptions have no stack traces, which makes them.. much less useful.

Attached patch (0001-hack-ex-info-stacktraces.patch) is one hackish way of getting stack traces back when Error.captureStackTrace is available (at least in Chrome, presumably in Node as well).

But this seems unacceptable — all the stuff emitted for the deftype (making the constructor print as a type) gets overwritten.

Is there a better way?

Will this maybe be made irrelevant by source maps?

We ned the abilty to supply custom and default tag parsers when using cljs.reader/read-string (found in src/cljs/cljs/reader.cljs) in running ClojureScript applications.

ns prefixed tags

As per the edn specification "user tags must contain a prefix component". Currently, because (name tag) is being called, the ns prefix component is dropped when looking up the tag in *tag-table*

default reader fn

Currently, there is no support for supplying a default reader fn (akin to *default-data-reader-fn* in Clojure proper).

2 issues rolled into one?

I know this may be bad practice rolling 2 issues into one, but I do not know how to formulate the separate patches that affect the same lines of code and have the apply correctly regardless of order. If I need to correct this, please advise.

Already reported?

I know this issue was already raised in CLJS-335, but from my experience with making these modifications for a running ClojureScript app, I did not come across the fns in the files mentioned in that task. I assume this is because that had more to do with compiling cljs code, but please correct me if I'm wrong.

Along those lines, is this patch not acceptable if it doesn't fix both places at once?

Approach & Naming

I followed the approach that was already in place for tag parsers, supplying register and deregister helper fns. I was a bit torn on naming because in Clojure *default-data-reader-fn* is used, but in the existing ClojureScript code they are called tag-parser. Should the "reader" vs "parser" nomenclature be unified between Clojure and ClojureScript, or are they named differently because they are fundamentally different in some way that I am missing?

Take for example this code:

(ns foo
  (:require [views.bar :as bar]
            [model.bar :as bar]))

;; this is meant to use views.bar
(bar/update-view)

The call to update-view fails with a "Cannot call method call of undefined", which is quite confusing if you have a big list of requires at the beginning. The expected behavior would be a compile-time error.

This only affects functions - functions get a second pass from the compiler in order to leverage arity information for self call optimization.

Typing a declare statement in the REPL gives an error

(def x) now fails in the REPL, this is very likely a result of CLJS-397 and CLJS-403