<< Back to previous view

[CLJS-1222] Sequence of a stateful transducer is producing the wrong answer Created: 24/Apr/15  Updated: 24/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3211
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Lucas Cavalcanti Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug, cljs, collections
Environment:

OSX 10.10.3, java 1.8.0-ea-b124



 Description   

I'm producing more than one element on the 1-arity of the transducer, and sequence is only considering the last one.

core.async is working as expected, but sequence is not. I implemented the same transducer on clojure and it works fine for sequence.

Here is the transducer and the tests that pass for core.async and fail for sequence:

======

(defn sliding-window [n]
(fn [rf]
(let [a #js []]
(fn
([] (rf))
([result]
(loop [] ;; Here I'm emitting more than one element
(when (not-empty a)
(rf result (vec (js->clj a)))
(.shift a)
(recur))))
([result input]
(.push a input)
(if (== n (.-length a))
(let [v (vec (js->clj a))]
(.shift a)
(rf result v))
result))))))

(deftest sliding-window-in-a-channel
(testing "sliding"
(let [channel (async/chan 1 (sliding-window 3))]
(async done
(go (async/>! channel 1)
(async/>! channel 2)
(async/>! channel 3)
(async/>! channel 4)
(async/>! channel 5)
(async/close! channel))

(go
(is (= (async/<! channel) [1 2 3]))
(is (= (async/<! channel) [2 3 4]))
(is (= (async/<! channel) [3 4 5]))
(is (= (async/<! channel) [4 5]))
(is (= (async/<! channel) [5]))
(is (= (async/<! channel) nil))
(done))))))

(deftest sliding-window-with-few-elements
(testing "with less elements"
(let [channel (async/chan 1 (sliding-window 3))]
(async done
(go (async/>! channel 1)
(async/>! channel 2)
(async/close! channel))

(go
(is (= (async/<! channel) [1 2]))
(is (= (async/<! channel) [2]))
(is (= (async/<! channel) nil))
(done))))))

;;This test fails! =(
(deftest sliding-window-in-a-sequence
(is (= [[5 4 3]
[4 3 2]
[3 2 1]
[2 1]
[1]]
(sequence (sliding-window 3) [5 4 3 2 1])))

(is (= [[2 1]
[1]]
(sequence (sliding-window 3) [2 1]))))



 Comments   
Comment by Lucas Cavalcanti [ 24/Apr/15 11:18 AM ]

I could make it work by recurring on the result.

([result]
  (loop [res result]
    (if (not-empty a)
      (let [v (vec (js->clj a))]
        (.shift a)
        (recur (rf res v)))
      res)))

even so it's weird that the previous version behaves differently on core.async and sequences in cljs and clj





[CLJS-1223] cljs.repl/doc for unqualified .. macro Created: 24/Apr/15  Updated: 24/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Note: Also affects 0.0-3211 (not yet available in JIRA pulldown)
Quick Start cljs.jar
OS X



 Description   

In the REPL, (doc ..) fails, while it succeeds for similar macros like (doc ->), and it also succeeds for ns-qualified: (doc cljs.core/..).

$ java -jar cljs.jar -m cljs.repl.node
ClojureScript Node.js REPL server listening on 54359
To quit, type: :cljs/quit
cljs.user=> *clojurescript-version*
"0.0-3211"
cljs.user=> (doc ..)
-------------------------
/.
  nil

nil
cljs.user=> (doc cljs.core/..)
-------------------------
cljs.core/..
([x form] [x form & more])
Macro
  form => fieldName-symbol or (instanceMethodName-symbol args*)

  Expands into a member access (.) of the first member on the first
  argument, followed by the next member on the result, etc. For
  instance:

  (.. System (getProperties) (get "os.name"))

  expands to:

  (. (. System (getProperties)) (get "os.name"))

  but is easier to write, read, and understand.

nil





[CLJS-1221] deftype/defrecord getBasis static method Created: 24/Apr/15  Updated: 24/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3211
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None





[CLJS-1220] Invalid regexp in src/clj/cljs/util.clj:130 Created: 23/Apr/15  Updated: 23/Apr/15  Resolved: 23/Apr/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: Next
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Marek Lipert Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None
Environment:

any



 Description   

There is an error in regex introduced in this commit:

https://github.com/clojure/clojurescript/commit/4228ee3a5dad6b04b1f852cb87138ac5c6d595be



 Comments   
Comment by David Nolen [ 23/Apr/15 7:52 PM ]

Tickets must present enough information to reproduce. Please include all information (environment etc.) necessary to replicate. Feel free to reopen when you can supply this.





[CLJS-1219] Eval doesn't work as expected Created: 23/Apr/15  Updated: 23/Apr/15  Resolved: 23/Apr/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Alex Gunnarson Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None
Environment:

Mac OS X Yosemite (10.10.1), lein-figwheel "0.2.7-SNAPSHOT"



 Description   

I've been doing some tests with macros and |eval| in ClojureScript and it doesn't work as expected. Here is the test file I'm using, which figwheel is reloading (src/cljc/quantum/test_fns.cljc):

=======================
(ns quantum.test-fns)

#?(:clj (defmacro eval-test0 [arg] `(eval '~arg)))
#?(:clj (defmacro eval-test1 [arg] (eval `~arg)))

#?(:clj
(defmacro mfn
"|mfn| is short for 'macro-fn'.
Originally named |functionize| by mikera."
{:attribution "mikera, http://stackoverflow.com/questions/9273333/in-clojure-how-to-apply-a-macro-to-a-list/9273560#9273560"}
[macro]
`(fn [& args#]
(eval (cons '~macro args#)))))

#?(:clj
(defmacro mfn-test
[macro]
(fn [& args]
(eval `(cons '~macro args)))))
=======================

I've been trying to get the macro |mfn| working, to be able to create macro aliases in ClojureScript like so:

=======================
(def cljs-for (mfn for))
(defalias lazy-for cljs-for)
=======================

By the way, the equivalent code in Clojure is a lot shorter and simpler, but it doesn't work in ClojureScript:

=======================
(defalias lazy-for for)
=======================

At the moment, |mfn| works in Clojure but not in ClojureScript. The error is as follows:

=======================
quantum.test => (quantum.test-fns/mfn 0)
WARNING: Use of undeclared Var cljs.core/eval at line 1 <cljs repl>
#<TypeError: Cannot read property 'call' of undefined>
=======================

So then I tried testing |eval| all by itself. I realize that runtime |eval| is not supported in ClojureScript, but from what I've read, it is supported within Clojure macros referenced by ClojureScript code. So I tried the following:

=======================
quantum.test => (eval-test0/mfn 0)
=======================

This gave the same error as calling |mfn|. So I tried the following next, which worked for CLJS-278 (http://dev.clojure.org/jira/browse/CLJS-278):

=======================
quantum.test => (eval-test1/mfn 0)
0
=======================

This, as you can see, works. So the problem seems to be nesting |eval| within a syntax-quote. With this in mind, I intended to patch |mfn| with |mfn-test|. So I called it like so, with the following result:

=======================
quantum.test => (quantum.test-fns/mfn-test 0)
java.lang.IllegalArgumentException: No method in multimethod 'emit-constant' for dispatch value: class quantum.test_fns$mfn_test$fn__94072
at clojure.lang.MultiFn.getFn(MultiFn.java:156)
at clojure.lang.MultiFn.invoke(MultiFn.java:229)
at cljs.compiler$eval2597$fn__2599.invoke(compiler.clj:355)
at clojure.lang.MultiFn.invoke(MultiFn.java:229)
at cljs.compiler$emit.invoke(compiler.clj:137)
at cljs.compiler$emit_str.invoke(compiler.clj:165)
at cljs.repl$evaluate_form.invoke(repl.clj:423)
at cljs.repl$eval_cljs.invoke(repl.clj:542)
at cljs.repl$repl_STAR_$read_eval_print__4217.invoke(repl.clj:808)
at cljs.repl$repl_STAR_$fn_4223$fn_4230.invoke(repl.clj:845)
at cljs.repl$repl_STAR_$fn__4223.invoke(repl.clj:844)
at cljs.compiler$with_core_cljs.invoke(compiler.clj:964)
at cljs.repl$repl_STAR_.invoke(repl.clj:810)
at figwheel_sidecar.repl$repl.invoke(repl.clj:172)
at figwheel_sidecar.repl$start_repl.invoke(repl.clj:389)
at figwheel_sidecar.repl$cljs_repl.invoke(repl.clj:405)
at figwheel_sidecar.repl$repl_switching_loop.invoke(repl.clj:416)
at figwheel_sidecar.repl$repl_switching_loop.invoke(repl.clj:412)
at figwheel_sidecar.repl$run_autobuilder.invoke(repl.clj:455)
at user$eval17648.invoke(form-init3534144446427289738.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6792)
at clojure.lang.Compiler.eval(Compiler.java:6782)
at clojure.lang.Compiler.load(Compiler.java:7237)
at clojure.lang.Compiler.loadFile(Compiler.java:7175)
at clojure.main$load_script.invoke(main.clj:275)
at clojure.main$init_opt.invoke(main.clj:280)
at clojure.main$initialize.invoke(main.clj:308)
at clojure.main$null_opt.invoke(main.clj:343)
at clojure.main$main.doInvoke(main.clj:421)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
=======================

This seems to be a problem with ClojureScript, but I may be wrong. Please do let me know.



 Comments   
Comment by David Nolen [ 23/Apr/15 7:50 PM ]

We do not look at tickets that involve tooling beyond involving anything other than ClojureScript. This ticket also suffers from not being a minimal case (conditional reading + something about eval). Feel free to open a new ticket that represents a minimal issue (only one dimension) using only ClojureScript thanks.





[CLJS-1218] Syntax quoting an alias created with :require-macros throws ClassCastException Created: 22/Apr/15  Updated: 23/Apr/15

Status: Reopened
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: 0.0-3211

Type: Defect Priority: Minor
Reporter: Ryan Berdeen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

With ClojureScript 0.0-3196 or the current cljs.jar, ClojureScript fails to read this file:

a.cljs
(ns a
  (:require-macros [clojure.string :as alias]))
 
; this is fine
`xxx/name
 
; this throws clojure.lang.Symbol cannot be cast to clojure.lang.Namespace
`alias/name
java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to clojure.lang.Namespace
        at clojure.tools.reader$resolve_symbol.invoke(reader.clj:633)
        at clojure.tools.reader$syntax_quote_STAR_.invoke(reader.clj:677)
        at clojure.tools.reader$read_syntax_quote.invoke(reader.clj:724)
        at clojure.tools.reader$read_STAR_.invoke(reader.clj:873)


 Comments   
Comment by David Nolen [ 22/Apr/15 11:59 PM ]

Please open an issue in tools.reader first. If it's determined that that is the not source, then you can reopen this one.

Comment by Nicola Mometto [ 23/Apr/15 6:13 AM ]

Not a tools.reader bug – cljs is binding alias-map to a map of sym->sym, the documentation for alias-map talks about mapping ns alias -> ns.

However I realize that providing sym->ns mapping could be problematic for cljs so I've just cut a tools.reader 0.9.2 release allowing for sym->sym mapping (see https://github.com/clojure/tools.reader/commit/6ca3b8899fe3884706fbeb176c008dc43643dc4b)





[CLJS-688] Unhelpful error message when compiling with blank .cljs file Created: 20/Nov/13  Updated: 23/Apr/15  Resolved: 23/Apr/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: John Mumm Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

When compiling, if you have a blank .cljs file in your source path, you get the following unhelpful message:

java.lang.NullPointerException: 
          closure.clj:370 cljs.closure/compiled-file
            core.clj:2485 clojure.core/map[fn]
          LazySeq.java:42 clojure.lang.LazySeq.sval
          LazySeq.java:67 clojure.lang.LazySeq.seq
              RT.java:484 clojure.lang.RT.seq
             core.clj:133 clojure.core/seq
             core.clj:678 clojure.core/concat[fn]
          LazySeq.java:42 clojure.lang.LazySeq.sval
          LazySeq.java:60 clojure.lang.LazySeq.seq
             Cons.java:39 clojure.lang.Cons.next
             RT.java:1654 clojure.lang.RT.boundedLength
          RestFn.java:130 clojure.lang.RestFn.applyTo
             core.clj:619 clojure.core/apply
         closure.clj:1018 cljs.closure/build
          closure.clj:981 cljs.closure/build
          compiler.clj:58 cljsbuild.compiler/compile-cljs[fn]
          compiler.clj:57 cljsbuild.compiler/compile-cljs
         compiler.clj:158 cljsbuild.compiler/run-compiler
form-init6897480153702409709.clj:1 user/eval2998[fn]
form-init6897480153702409709.clj:1 user/eval2998[fn]
          LazySeq.java:42 clojure.lang.LazySeq.sval
          LazySeq.java:60 clojure.lang.LazySeq.seq
              RT.java:484 clojure.lang.RT.seq
             core.clj:133 clojure.core/seq
            core.clj:2780 clojure.core/dorun
            core.clj:2796 clojure.core/doall
form-init6897480153702409709.clj:1 user/eval2998
       Compiler.java:6619 clojure.lang.Compiler.eval
       Compiler.java:6609 clojure.lang.Compiler.eval
       Compiler.java:7064 clojure.lang.Compiler.load
       Compiler.java:7020 clojure.lang.Compiler.loadFile
             main.clj:294 clojure.main/load-script
             main.clj:299 clojure.main/init-opt
             main.clj:327 clojure.main/initialize
             main.clj:362 clojure.main/null-opt
             main.clj:440 clojure.main/main
          RestFn.java:421 clojure.lang.RestFn.invoke
             Var.java:419 clojure.lang.Var.invoke
             AFn.java:163 clojure.lang.AFn.applyToHelper
             Var.java:532 clojure.lang.Var.applyTo
             main.java:37 clojure.main.main


 Comments   
Comment by Travis Thieman [ 06/Dec/13 11:30 AM ]

I tried this using both cljsbuild (from a mies template) and bin/cljsc on a directory. Both of these methods give the following error message, which seems reasonable:

java.lang.AssertionError: Assert failed: file:/repos/empty/src/empty/empty.cljs does not provide a namespace

How are you compiling to get what you're seeing?





[CLJS-1173] standard way to identify types originating from ClojureScript Created: 27/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: easy


 Comments   
Comment by David Nolen [ 23/Apr/15 1:12 AM ]

We expose this only as a property cljs$lang$type. A simple predicate cljs-type? would suffice.





[CLJS-1174] Simple warning if a namespace with dashes not found but a file path with dashes exists Created: 27/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: easy





[CLJS-994] print a warning when :externs file paths can't be found. Created: 30/Jan/15  Updated: 23/Apr/15

Status: Reopened
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3058
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: Crispin Wellington Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: cljs, enhancement, errormsgs, patch,
Environment:

Linux 64bit

java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.14.04.1)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)


Attachments: Text File clojurescript-extern-missing-warning.patch    
Patch: Code

 Description   

clojurescript silently ignores missing externs files possibly leading a developer to chase their tail.

Presently it can be very confusing using advanced compilation if you have made a mistake in the path name of one of your :externs files. This patch makes the compiler print a warning on stderr so you can quickly determine the cause of the broken advanced compilation output.

As a side effect, when doing a basic lein-cljsbuild a warning is always printed:

```
WARNING: js resource path closure-js/externs does not exist
```

This is because lein-cljsbuild quietly adds this extra path to your :externs listing without you knowing.



 Comments   
Comment by David Nolen [ 31/Jan/15 1:59 PM ]

You need to bind *out* to *err*, or just print to it directly a la cljs.util/debug-prn.

Comment by Crispin Wellington [ 31/Jan/15 7:30 PM ]

I did bind out to err. Check the patch.

Comment by David Nolen [ 01/Feb/15 12:30 PM ]

Crispin, oops sorry you are correct. Thanks.

Comment by David Nolen [ 13/Mar/15 7:33 AM ]

fixed https://github.com/clojure/clojurescript/commit/5f66a78bf469a9875e51aa39c29d3e66ce890eb4

Comment by David Nolen [ 14/Mar/15 5:55 AM ]

The solution does not work for cljsbuild. It's unclear why there so much machinery in place over the approach taken for deps.clj.

Comment by David Nolen [ 15/Mar/15 10:37 AM ]

Stalled on this cljsbuild issue https://github.com/emezeske/lein-cljsbuild/issues/383

Comment by Crispin Wellington [ 23/Mar/15 2:50 AM ]

This lein-cljsbuild issue is what made me make it just a warning initially, and not a hard error like raising IllegalArgumentException does. Though I agree it should be a hard error. If we start with a warning, it enables the immediate problem for the developer to be resolved, and leaves a wart that the cljs-build project can then see that need fixing on their end. Then when that end is fixed it could be made a hard error. If cljsbuild is fixed fairly soon then all is well, but if it takes a long time, a warning might be a good first step.





[CLJS-744] ISequential types should implement JS indexOf, lastIndexOf Created: 05/Jan/14  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None





[CLJS-1129] :modules tutorial for wiki Created: 16/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Task Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: documentation, newbie


 Description   

The documentation is nice but something that walks people through the steps would be nicer.






[CLJS-1147] reconnect logic for browser REPLs Created: 18/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Instead of forcing users to refresh browser and lose application state, the browser REPL should poll once a second to connect if connection is unreachable for some reason.



 Comments   
Comment by David Nolen [ 21/Mar/15 8:56 PM ]

This is firmly a major nice-to-have, but not a blocker.





[CLJS-1127] validate compiled file written to disk Created: 16/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If we validate the file written to disk then we can catch common error of running multiple build processes and abort.






[CLJS-349] cljs.compiler: No defmethod for emit-constant clojure.lang.LazySeq Created: 30/Jul/12  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: Julien Fantin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-CLJS-349-Allow-ISeq-to-be-emitted-by-macros-as-a-con.patch     File fixbug349.diff    

 Description   

The cljs compiler errors when trying to emit-constant for a clojure.lang.LazySeq.

Example : https://www.refheap.com/paste/3901

Here syms is defined as a LazySeq on line 3, then on line 7 it is quoted. The error is included in the refheap.

Emitting a cljs.core.list for this type seems to solve the issue.



 Comments   
Comment by David Nolen [ 31/Aug/12 9:27 AM ]

Can you identify precisely where a LazySeq is getting emitted here? A LazySeq is not literal so this seems like a bug in the macro to me. I could be wrong. Thanks!

Comment by Herwig Hochleitner [ 28/Oct/12 9:31 PM ]

The lazy seq seems to be introduced on line 7, the '~syms form

`(let [mappings# (into {} (map-indexed #(identity [%2 %1]) '~syms))

Clojure allows lazy-seqs to be embedded: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L4538

As an aside: The relevant protocol is not literality, but the print-dup multimethod. Do / Should we have print-dup in CLJS?

Comment by Herwig Hochleitner [ 31/Oct/12 10:10 PM ]

Attached patch 0001 doesn't add a case for LazySeq, but folds two cases for PersistentList and Cons into one for ISeq.

Comment by David Nolen [ 19/Nov/13 9:28 PM ]

This approach seems acceptable but this is an old patch can we update for master?





[CLJS-485] clojure.string/replace ignores regex flags Created: 12/Mar/13  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: Esa Virtanen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug, patch, test

Attachments: Text File 0001-Take-regex-flags-m-i-into-account-in-clojure.string-.patch    
Patch: Code and Test

 Description   

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

CLJS
clojure.string/replace "I am NOT matched" #"(?i)not " "")
=> "I am NOT matched"
CLJ
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".



 Comments   
Comment by Chas Emerick [ 19/Mar/14 9:29 AM ]

I can confirm the bug. The attached patch applies cleanly, and works as expected.

Esa, sorry for the long delay (this one must have slipped through the cracks)! Could you please submit a contributor's agreement, so that your patch can be merged? More info is here:

http://clojure.org/contributing





[CLJS-1139] Repeated applications of `ns` form at the REPL are not additive Created: 17/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: Michael Griffiths Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Quick start guide with Node REPL



 Description   

In a Clojure REPL, it is possible to declare the same namespace again, without existing namespaces aliases being altered or removed:

user=> (ns my-test-ns.core (:require [clojure.string :as string]))
nil
my-test-ns.core=> (def a string/blank?)
#'my-test-ns.core/a
my-test-ns.core=> (ns my-test-ns.core)
nil
my-test-ns.core=> (def a string/blank?)
#'my-test-ns.core/a
my-test-ns.core=>

ClojureScript REPLs do not behave in the same way:

ClojureScript:cljs.user> (ns my-test-ns.core (:require [clojure.string :as string]))
true
ClojureScript:my-test-ns.core> (def a string/blank?)
#<function clojure$string$blank_QMARK_(s){
return goog.string.isEmptySafe(s);
}>
ClojureScript:my-test-ns.core> (ns my-test-ns.core)
nil
ClojureScript:my-test-ns.core> (def a string/blank?)
WARNING: No such namespace: string, could not locate string.cljs at line 1 <cljs repl>
WARNING: Use of undeclared Var string/blank? at line 1 <cljs repl>
repl:13
throw e__3919__auto__;
      ^
ReferenceError: string is not defined
    at repl:1:109
    at repl:9:3
    at repl:14:4
    at Object.exports.runInThisContext (vm.js:74:17)
    at Domain.<anonymous> ([stdin]:41:34)
    at Domain.run (domain.js:197:16)
    at Socket.<anonymous> ([stdin]:40:25)
    at Socket.emit (events.js:107:17)
    at readableAddChunk (_stream_readable.js:163:16)
    at Socket.Readable.push (_stream_readable.js:126:10)
ClojureScript:my-test-ns.core>





[CLJS-719] this-as behaves incorrectly in "scoping function" Created: 07/Dec/13  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: Kevin Marolt Assignee: David Nolen
Resolution: Unresolved Votes: 1
Labels: None


 Description   

When a this-as expression gets put in a "scoping function", e.g. in a let-binding, the value bound via this-as refers to the scoping function, and not to the outer scope.

Example:

(def foo
  (js-obj
    "bar" "baz"
    "getBarRight" (fn [] (this-as self (.-bar self)))
    "getBarWrong" (fn []
                    (let [bar (this-as self (.-bar self))]
                      bar))))
     
(.log js/console (.getBarRight foo)) ;; => "baz"
(.log js/console (.getBarWrong foo)) ;; => undefined

Whereas foo.getBarRight expands to something like

function() {
  var self = this; // this refers to foo
  return self.bar; // returns "bar"
}

foo.getBarWrong on the other hand expands to

function() {
  var bar = function() {
    var self = this; // this refers to enclosing function
    return self.bar; // returns undefined
  }();
  return bar; // returns undefined
}





[CLJS-710] port clojure.pprint Created: 02/Dec/13  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Task Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None


 Comments   
Comment by Shaun LeBron [ 15/Aug/14 1:29 PM ]

working on this here: https://github.com/shaunlebron/cljs-pprint

Comment by Shaun LeBron [ 05/Oct/14 12:40 PM ]

I'm ceasing development on the port.

fipp should be ported in place of pprint in cljs. pprint is slow and complex, whereas fipp is fast, simple, and very customizable.

Brandon Bloom is awaiting a go-ahead from the cljs community on whether the fipp port should be completed:
https://github.com/brandonbloom/fipp/issues/7

Comment by David Nolen [ 05/Oct/14 12:55 PM ]

fipp only covers a very small (though important part) of clojure.pprint's functionality. I think it's fine that fipp is a standalone library that user's can adopt in their own projects if they desire. This doesn't change the desire for a full port of clojure.pprint.

Comment by Shaun LeBron [ 27/Oct/14 1:13 PM ]

k, resuming.





[CLJS-742] Compilation with :output-file option set fails Created: 03/Jan/14  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Trivial
Reporter: Timothy Pratley Assignee: Timothy Pratley
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File CLJS-742.diff     File cljs-742-rebased.diff    
Patch: Code

 Description   

./bin/cljsc hello.cljs '{:output-file "foo.js"}'

Expected:
a file called foo.js

Actual:
Compiler throws an internal error

Notes:
The correct option is :output-to
:output-file might be removable (it is broken, nobody is using it?)
Further analysis required to determine if it is useful to keep.



 Comments   
Comment by Timothy Pratley [ 03/Jan/14 12:14 PM ]

Fixes handling of compiling one IJavaScript or many

Comment by Timothy Pratley [ 08/Oct/14 11:03 PM ]

Patch is attached, updating ticket to reflect that

Comment by David Nolen [ 27/Mar/15 7:44 AM ]

Can we get a patch rebased to master? Thanks.

Comment by Timothy Pratley [ 04/Apr/15 1:05 PM ]

updated for latest master





[CLJS-1135] Present more cljs.foo.api interfaces for stable parts of cljs.analyzer, cljs.compiler, and cljs.closure Created: 17/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Task Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None





[CLJS-1194] data_readers.cljc Created: 10/Apr/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Now that conditional reading has landed we can implement support for data_readers.cljc to get both compile time and runtime support.



 Comments   
Comment by David Nolen [ 10/Apr/15 7:45 PM ]

This needs http://dev.clojure.org/jira/browse/CLJ-1699 to be useful.





[CLJS-1168] REPL fails to find .js files in :libs Created: 25/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: Daniel Skarda Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

org.clojure/clojurescript 0.0-3149
Tested with both basic clojurescript REPL and new com.cemerick/piggieback 0.2.0-20150324.120715-1



 Description   

We use Google E2E library for encryption. This library is written using Google Closure.
The library is stored locally in a directory ("closure-libs/e2e") and we pass :libs ["closure-libs/e2e"] to the compiler.

Compilation of our project works fine. Compiler does find the library without problems in all optimization modes.

Recently we have problem with REPL. With same parameters, REPL fails to load the library:

java.lang.IllegalArgumentException: Namespace e2e.async.Result does not exist
at cljs.closure$source_for_namespace.invoke(closure.clj:501)
at cljs.repl$load_namespace.invoke(repl.clj:181)
at cljs.repl$load_dependencies.invoke(repl.clj:201)
at cljs.repl$evaluate_form.invoke(repl.clj:444)
at cljs.repl$eval_cljs.invoke(repl.clj:527)
at cljs.repl$repl_STAR_$read_eval_print__4890.invoke(repl.clj:783)
at cljs.repl$repl_STAR_$fn_4896$fn_4903.invoke(repl.clj:821)
at cljs.repl$repl_STAR_$fn__4896.invoke(repl.clj:820)
at cljs.compiler$with_core_cljs.invoke(compiler.clj:951)
at cljs.repl$repl_STAR_.invoke(repl.clj:785)
at cryptelo.dev.cljs.env$eval11953.invoke(02b7dffab3345931421313ec2fe5d506990ab5e5-init.clj:1)

I spent long time investigating the issue (which is not easy given jungle of compiler and repl option maps, bindings of global variables etc).

What I found:

  • compiler finds the library without problem, all our tests invoked from the command line pass
  • both basic cljs REPL and piggieback (0.2.0 experimental branch) fails to find the library
  • :libs files are not copied to :output-dir
  • at the beginning, repl calls default-compiler-env with options
  • default-compiler-options run js-dependency-index, which scans all libraries and stores it in compiler atom
  • strace proves that clojurescript finds closure-libs/e2e/deps.js and reads it
  • calling (js-dependency-index {:libs ["closure-lib/e2e"]}) proves that the e2e.async.Result was found

But:

  • library-dependencies stores file path as URL in {:url ...}
  • source-for-namespace (from error stack) finds the file, but expects relative path with key :file

This is where my investigation stops. I am sure that fix would be probably easy, but I do not know all details of information cljs stores about .js files. Moreover I do not know why it works in compiler and not in REPL. Probably compiler does not open file and passes
it as a argument to Google Closure, while REPL actually wants to load the file itself.

Hope you have all information to fix the problem.

Thank you.



 Comments   
Comment by David Nolen [ 25/Mar/15 8:49 AM ]

Please do not include piggieback information when reporting issues to JIRA. We do not consider downstream tooling here at all. Will take a look, thanks for the report!





[CLJS-818] Externs don't get loaded when running under immutant as cljs.js-deps/find-js-classpath fails Created: 18/Jun/14  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: James Cash Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Java 1.8.0_05, Clojure 1.6.0, clojurescript 0.0-2234, immutant 1.1.1


Attachments: Text File 818.patch     PNG File Screen Shot 2014-06-18 at 20.14.59 .PNG    

 Description   

When compiling clojurescript that relies on library-provided externs (e.g. Om needing React.js externs), the clojurescript is compiled without errors, but the generated javascript fails to work, due to the externs not being loaded. Externs don't get loaded, as cljs.js-deps/find-js-classpath doesn't find the javascript externs file. This occurs because it uses cljs.js-deps/all-classpath-urls, which filters out the immutant classloader, since org.immutant.core.ImmutantClassLoader is not an instance of java.net.URLClassLoader (and hence lacks a .getURLs method anyway).



 Comments   
Comment by Toby Crawley [ 19/Jun/14 9:23 AM ]

Chas: Is there a reason not to depend on dynapath here? This exact case is kinda why it exists

Comment by David Nolen [ 19/Jun/14 10:47 AM ]

Patch welcome for this.

Comment by James Cash [ 19/Jun/14 2:12 PM ]

Simply replacing cljs.js-deps/all-classpath-urls with dynapath.util/all-classpath-urls worked for me. I don't know if there are policies around adding dependencies to cljs, but the following patch is working for me. Would it be preferable to re-implement the functionality instead?

Comment by David Nolen [ 19/Jun/14 2:19 PM ]

We are not going to take on a dependency for this. The code should be copied over, thanks.

Comment by James Cash [ 19/Jun/14 3:46 PM ]

Due to the way dynapath works, I don't think a straightforward copying of the code will work, since it relies on a protocol. Backing up a step though, would it be reasonable for externs to be loaded via io/resource, in the same way that the :preamble is?

Comment by Toby Crawley [ 19/Jun/14 3:54 PM ]

Unfortunately, the code can't be copied over. Dynapath works by providing a protocol that providers/users of funky classloaders can implement, allowing libraries that use dynapath to access the dynamic features of those classloaders without having to care about the loader's concrete type. Dynapath itself provides implementations for j.n.URLClassLoader and c.l.DynamicClassloader by default, so libraries don't have to do anything special to access the dynamic features of those classes.

java.classpath also provides a similar mechanism that the Immutant classloader implements as well. If you are more open to dependencies that are under org.clojure, using that will work as well. Ideally, I'd like to see java.classpath subsume dynapath.

Comment by James Cash [ 19/Jun/14 4:23 PM ]

Made a new patch that sidesteps the all-classpath-urls issue by just using io/resource instead of iterating over all urls

Comment by David Nolen [ 01/Jul/14 9:26 PM ]

Can people chime in whether the patch works for them, thanks.





[CLJS-1136] Initial require fails to fully load added symbols Created: 17/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Quick Start Browser REPL (OS X / Safari)



 Description   

In the Quick Start, a portion runs the user through adding a symbol (a function named foo) and then requiring the namespace and using that symbol. I'm finding that require fails and that I need to add the :reload directive.

To reproduce:

  1. Run through the Quick Start up through the browser REPL section.
  2. Set src/hello_world/core.cljs so that it does not have the foo function defined.
  3. Remove the out directory: rm -rf out
  4. Start up the REPL: rlwrap java -cp cljs.jar:src clojure.main repl.clj
  5. Connect Safari by going to http://localhost:9000
  6. Show the error console in Safari. (You'll see Hello world.)
  7. Run tail -f out/watch.log
  8. Add the foo function that adds a b to src/hello_world/core.cljs and save it.
  9. Observe that watch.log reflects recompilation
  10. Do {{ (require '[hello-world.core :as hello]) }}
  11. Do {{ (hello/foo 2 3) }}

At this point you will get:
TypeError: undefined is not an object (evaluating 'hello_world.core.foo.call')

But:

ClojureScript:cljs.user> (ns-interns 'hello-world.core)
{foo #'hello-world.core/foo, conn #'hello-world.core/conn}
ClojureScript:cljs.user> (source hello/foo)
(defn foo [a b]
  (+ a b))
nil

Now, if you :reload

ClojureScript:cljs.user> (require '[hello-world.core :as hello] :reload)
nil
ClojureScript:cljs.user> (hello/foo 2 3)
5


 Comments   
Comment by Mike Fikes [ 17/Mar/15 11:30 AM ]

Prior to step 8:

ClojureScript:cljs.user> (ns-interns 'hello-world.core)
{}

Between steps 9 and 10:

ClojureScript:cljs.user> (ns-interns 'hello-world.core)
{foo #'hello-world.core/foo, conn #'hello-world.core/conn}

My guess: Watching is causing symbols to be interned, but not usable, and this is interfering with require forcing you to include :reload.

Comment by David Nolen [ 22/Mar/15 9:46 AM ]

I'm not sure that this is actually an issue, the browser has already required the namespace, it's the entry point. Thus you really do need a :reload. But the reason you see interned symbols is that the watch process shares the compilation environment with the REPL. It may be the case that with the dramatically improved REPLs the watch option becomes entirely unnecessary and counterintuitive, let's see how it goes.





[CLJS-1214] :arglists meta has needless quoting Created: 21/Apr/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None





[CLJS-968] Metadata on function literal inside of a let produces invalid Javascript Created: 07/Jan/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: Bobby Eickhoff Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: bug
Environment:

Originally found with [org.clojure/clojurescript "0.0-2496"]
Still reproducible with the latest cljsc (b5e9a5116259fc9f201bee4b9c6564f35306f9a5)



 Description   

Here is a minimal test case that produces the invalid Javascript:

(defn f []
  (let [a 0]
    ^{"meta" "data"}
    (fn [] true)))

The compiled Javascript includes the invalid token sequence "return return". (Per Chrome: Uncaught SyntaxError: Unexpected token return)

The problem does not occur if the metadata applies to a map literal instead of a function literal.
The problem only occurs when the function and metadata are inside of a let.



 Comments   
Comment by Bobby Eickhoff [ 07/Jan/15 9:45 PM ]

I forgot to try with-meta. Using with-meta does not produce this syntax error, so it's only a problem with the reader macro for metadata.

Comment by David Nolen [ 08/Jan/15 7:41 AM ]

Any quick thoughts about this one Nicola? Quite possibly a compiler issue on the CLJS side.

Comment by Nicola Mometto [ 08/Jan/15 8:07 AM ]

David, I understand why this happens but I don't know enough about how cljs's js emission to propose a fix.
The issue is that with this commit: https://github.com/clojure/clojurescript/commit/d54defd32d6c5ffcf6b0698072184fe8ccecc93a the following scenario is possible:

{:op :meta
 :env {:context :return}
 :expr {:op :fn
        :env {:context :expr}
        :methods [{:op :fn-method 
                   :env {:context :return} ..}]
        ..}
 ..}

i.e. analyze-wrap-meta changes the context of the :fn node to :expr but keeps the context of the :fn-methods to :return.

This causes both
https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/compiler.clj#L575-L576
and
https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/compiler.clj#L488 (https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/compiler.clj#L233)

to be true and emit a "return".





[CLJS-1125] Simple corrupted compiled file detection Created: 16/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

We should include a line at the end of the file that we check for to determine that the file was not corrupted due to either an incomplete write or a clobbered write. It should be be the SHA of the ClojureScript source it was generated from.






[CLJS-1159] compiled files with warnings that otherwise don't need recompilation will not emit warnings on the next compile Created: 23/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The aggressive caching approach is odds with warning visibility. It probably makes sense for a compiled file with warnings to always return true for requires-compilation?.






[CLJS-1142] ClojureScript stream socket REPL Created: 18/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Port relevant bits of CLJ-1671






[CLJS-1207] Emit a warning if multiple resources found for a ClojureScript namespace Created: 15/Apr/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

We should emit a simple warning if a namespace doesn't not appear to be unique on the classpath.






[CLJS-871] .-default property access returns nil Created: 11/Oct/14  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: Joel Holdbrooks Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File 871.patch     Text File 871.patch    
Patch: Code and Test

 Description   

Types defined with deftype/defrecord which have a default field will incorrectly return nil with property access. The following example will return nil.

(deftype Foo [default])

(let [foo (Foo. "bar")]
  (.-default foo))


 Comments   
Comment by Joel Holdbrooks [ 13/Oct/14 4:19 PM ]

Patch attached. I should point out that I had to borrow js-reserved from the compiler namespace and the warning message provided hard codes the munged symbol information instead of reusing the compiler's munge fn.

Comment by Joel Holdbrooks [ 13/Oct/14 9:41 PM ]

For the sake of history, I should provide more context to this patch (I'm unable to edit the issue title for some reason). It isn't just .-default it is any field name that is also a JavaScript identifier (eg. public, private, if).

Comment by David Nolen [ 14/Oct/14 5:26 AM ]

Please lift js-reserved and any helpers like munge into the shared namespace cljs.util so that logic an be shared and hard coding avoided. Thanks.

Comment by Joel Holdbrooks [ 14/Oct/14 5:03 PM ]

Are you sure, David? That might make this patch a bit more noisy. If it's not a problem I'm happy to do it.

Comment by David Nolen [ 14/Oct/14 6:06 PM ]

I'm sure, I'd like to avoid this kind of code duping. Cleaner in the end and better moving forward.

Comment by Joel Holdbrooks [ 18/Mar/15 11:43 AM ]

Updated to use new refactorings

Comment by David Nolen [ 18/Mar/15 11:46 AM ]

The warning is not desirable. Instead we should just munge and ensure property access always works.





[CLJS-1133] REPL require results in warnings to be emitted twice Created: 17/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Quick Start Browser REPL with :watch off



 Description   

Run through the Quick Start and go down through to the Browser REPL portion (https://github.com/clojure/clojurescript/wiki/Quick-Start#browser-repl), but exclude the :watch option from repl.clj.

Then further down, where the new symbol is introduced

;; ADDED
(defn foo [a b]
  (+ a b))

instead cause some duplicate symbols to be introduced in order to provoke compiler warnings:

(def a 1)
(def a 1)

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

Then evaluate the require statement in the tutorial and observe that the warnings are emitted twice:

ClojureScript:cljs.user> (require '[hello-world.core :as hello])
WARNING: a at line 11 is being replaced at line 12 /Users/mfikes/Desktop/hello_world/src/hello_world/core.cljs
WARNING: foo at line 14 is being replaced at line 16 /Users/mfikes/Desktop/hello_world/src/hello_world/core.cljs
WARNING: a at line 11 is being replaced at line 12 /Users/mfikes/Desktop/hello_world/src/hello_world/core.cljs
WARNING: foo at line 14 is being replaced at line 16 /Users/mfikes/Desktop/hello_world/src/hello_world/core.cljs
nil





[CLJS-895] Hello-js sample is broken when following README instructions Created: 02/Dec/14  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Trivial
Reporter: Andrew Rosa Assignee: Andrew Rosa
Resolution: Unresolved Votes: 0
Labels: documentation, newbie

Attachments: Text File 0001-Create-sample-to-demonstrate-only-extern-usage.patch    

 Description   

Currently we have on hello-js the usage of externes libraries. But it not only mix different aspects of cljsc as also have some breakage if we follow the README instructions

So, instead of adding more complexity into it, here I suggest us to extract the extern functionality into it's own sample project, which is much more approachable for newcomers that want to grok cljsc usage. This new sample project is included in my first patch, so anyone could see the end result.

If this patch is desirable, I could move around the other samples and split them into separate, focused aspect (simple hello, calling cljs from js, fixing the dom sample). Only the twitter buzz that I'm not sure how to approach it - I guess it has issues with API limitations of the last Twitter updates.






[CLJS-1070] top-level boolean inference does not work Created: 28/Feb/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Problem for using boolean Closure defines



 Comments   
Comment by Francis Avila [ 30/Mar/15 12:02 PM ]

I am unsure if this is the same issue, but forms like ^boolean (js/isFinite n) also do not seem to analyze correctly: if, and, and or will still emit a call to truth_.





[CLJS-1141] memoization of js-dependency-index and get-upstream-deps needs knobs Created: 18/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS_1141.patch     Text File CLJS-1141-with-js-dep-caching-latest.patch    

 Description   

knobs should be exposed for more dynamic compilation environments like Figwheel which may desire to add dependencies to the classpath on the fly.



 Comments   
Comment by Bruce Hauman [ 21/Mar/15 3:51 PM ]

A patch that caches upstream dependencies in the compiler env.

Comment by Bruce Hauman [ 21/Mar/15 3:59 PM ]

Actually I'm going to submit another patch that includes the memoize calls in js-deps.

Comment by Bruce Hauman [ 28/Mar/15 12:50 PM ]

New patch that moves cljs.js-deps memoization to current env/compiler as well as get-upstream-deps.

Unfortunately there is a circular dep between cljs.env and cljs.js-deps, if we want to cache in env/compiler. I overcame this with a resolve.

Compile performance is either completely unchanged or slightly improved based on several test runs.

Comment by Bruce Hauman [ 28/Mar/15 2:22 PM ]

Hold off on this. Its not behaving as expected. Doesn't seem to be caching in certain situations.

Comment by David Nolen [ 28/Mar/15 2:26 PM ]

Thanks for the update. This will definitely not land until after the pending REPL/piggieback release anyhow.

Comment by Bruce Hauman [ 28/Mar/15 2:44 PM ]

Yeah there is an obvious bug and a subtle one. Hopefully will finish it up soonish.

Comment by Bruce Hauman [ 28/Mar/15 3:43 PM ]

Alright, this latest patch works. There was a subtle memoizing nil value bug.





[CLJS-1195] generic reusable command line argument parsing for REPLs Created: 10/Apr/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: newbie


 Description   

REPLs are more or less started in the same way and all the builtin ones provide a -main entry point. We should supply reusable command line argument parsing that any REPL can use to get standard command line driven start.






[CLJS-794] RegExp flags are being dropped by `string/replace` Created: 09/Apr/14  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: Peter Taoussanis Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

`clojure.string/replace` accepts either a string or pattern argument to match against.

For pattern arguments, the current implementation discards the original RegExp and creates a new one:
`(.replace s (js/RegExp. (.-source match) "g") replacement)`

This is killing any flags on the original pattern (case insensitivity, for example). As a result, things like `(str/replace "Foo" #"(?i)foo" "bar")` currently fail. The result is "Foo", it should be "bar".

Can I submit a patch that'll check for and preserve other (i/m/y) flags?

Thanks



 Comments   
Comment by David Nolen [ 02/Dec/14 5:42 AM ]

A patch is welcome for this. Thanks.





[CLJS-1061] Enhanced control over printing configuration Created: 23/Feb/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: Joel Holdbrooks Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

enable-console-print! is convenient from some developers on a team who like println to print to the console. However, for others, like myself, it is more desirable to print directly to the REPL (e.g. w/in Emacs) instead of the browser console. On occasion enable-console-print! get's checked and can cause errors that result from calling println before the *print-fn* is set. It then becomes a hassle to either comment out the println or the enable-console-print!. Having a disable-console-print! which could restore the previous *print-fn*, whatever that may have been, would be nice to have.

As it currently stands, one must do this manually, which frankly is kind of awkward and not immediately obvious. It is much like having a light you can turn on but not off unless you cut the main power.



 Comments   
Comment by Thomas Heller [ 24/Feb/15 6:01 AM ]

I think the whole print-fn handling is not optimal. The problem is that each namespace can set it and will override the previous setting and the last one wins. While this is most likely one of "my" namespaces and "my" print-fn it may be someone else's while initializing (loading dependant namespaces). So you might run into issues where some log output goes to console and some goes to util.print or whichever other method the library author decided to use. Some libraries already call (enable-console-print!) as the very first thing their namespace.

What I recently added to shadow-build is an option to make this a compiler option (eg. {:print-fn :console}). Code can just use prn, println and never worry about that *print-fn* might not be set. I think this is a very convenient option that can default to :console and one less hurdle new users may stumble over. I don't need to initialize println in Clojure either.

Maybe this option should make it into core.

Comment by David Nolen [ 12/Mar/15 10:03 AM ]

Not going to do disable-console-print!. This ticket is important but it needs further consideration.

Comment by Joel Holdbrooks [ 12/Mar/15 5:39 PM ]

I'm okay with that. I'm just interested in the solution. Thanks for considering it.

Comment by David Nolen [ 15/Mar/15 10:26 AM ]

Putting this in the Backlog for now. It needs more hammock time. More solution ideas welcome on this ticket.





[CLJS-1124] Have cljs.repl.browser/repl-env serve more static file types Created: 16/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Minor
Reporter: Sander Dijkhuis Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: newbie
Environment:

cljs 0.0-3115


Attachments: Text File CLJS-1124-attempt001.patch     GZip Archive CLJS-1124-test.tar.gz     GZip Archive CLJS-1124-test.tar.gz    

 Description   

I'm developing a webpage using CLJS that can be served statically. To iterate quickly on the script, I'm hosting the page using

(cljs.repl/repl
(cljs.repl.browser/repl-env :static-dir ["." "out/" "img/" "fonts/"])
:watch "src")

I expect images and webfonts from the img/ and fonts/ directories to be served as well, but the server dispatch code only seems to deal with some other file types:

https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/repl/browser.clj#L104

(server/dispatch-on :get
(fn [{:keys [path]} _ _]
(or
(= path "/")
(.endsWith path ".js")
(.endsWith path ".cljs")
(.endsWith path ".map")
(.endsWith path ".html")
(.endsWith path ".css")))
send-static)

Could this be extended to support all types of files in the static directories? Or could more cases be added for .jpg, .woff and .png?

My workaround is to load index.html from a separate static server, and use the REPL server only for the REPL connection. But in this setup, somehow (require my-ns.core :reload) keeps reloading the old code. This problem doesn't occur when I load index.html from the REPL server.



 Comments   
Comment by Sander Dijkhuis [ 16/Mar/15 8:04 AM ]

Here’s a quick first attempt. It tries to serve all static files that can be found. I don’t see downsides to this approach yet.

Now images get downloaded but don’t render. I guess this is because the served files’ Content-Type is wrong: e.g. image/jpeg; charset=utf-8. If I’m not mistaken no charset should be specified, and this requires some more checking in cljs.repl.server/end-and-close.

Is it OK to stretch the experimental server’s use to support binary files, or should I look for a more specialised development server?

Comment by Sander Dijkhuis [ 18/Mar/15 3:35 AM ]

I’m giving up on my patch for now. It’s not enough to remove the charset from the Content-Type header. I guess cljs.repl.browser/send-static needs to be adjusted to deal with binary streams instead of slurping binary files into strings. It should also have a more extensive list of MIME types. But then I’m not sure if cljs wants to be a complete experimentation server.

In the attachment is a minimal test case:
1. put a cljs.jar inside the extracted directory
2. run make
3. open http://localhost:9000/

Comment by Sander Dijkhuis [ 18/Mar/15 3:47 AM ]

(Slightly friendlier version of the test case.)





[CLJS-712] resolve-var for symbol with dot still wrong Created: 03/Dec/13  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

We need to recur on the first segment passing an new additional argument to resolve-var indicating that we should not try to resolve in the current namespace and instead warn.






[CLJS-375] loop doesn't seem to preserve tag information as evidenced by extra cljs.core.truth_ calls Created: 06/Sep/12  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None





[CLJS-620] Warnings are generated when using a macro in argument position Created: 14/Oct/13  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: Julien Eluard Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File CLJS-620.diff    

 Description   

Using a macro in argument position (e.g. (map macro [])) generates a warning:
WARNING: Use of undeclared Var test/node at line 4 src/test.cljs

Find a reproduction project here.



 Comments   
Comment by Jozef Wagner [ 15/Oct/13 3:30 AM ]

and what would you like, a better warning? Clojurescript allows same name for macro and for function, so you can both have macro + and fn +. Macro version will be used when is first in the list, fn version otherwise.

Comment by Jonas Enlund [ 15/Oct/13 3:38 AM ]

For reference, Clojure generates the following error message:

user=> (map when [])
CompilerException java.lang.RuntimeException: Can't take value of a macro: #'clojure.core/when, compiling:(NO_SOURCE_PATH:1:1)

The "obvious" approach would be to add

(when-let [m (get-expander sym env)]
  (throw (error env (str "Can’t take value of a macro: " m))))

to resolve-var[1]. Unfortunately this doesn’t work in ClojureScript due to the way inlining works. A simple workaround is to add {:inline true} metadata to macros that are later redefined as functions in core.cljs and check for invalid macro usage like this:

(when-let [m (get-expander sym env)]
  (and (-> m meta :inline not)    
       (throw (error env (str "Can’t take value of a macro: " m)))))

Another approach would perhaps be to rethink how inlining works as it seems kind of brittle to have macros in cljs/core.clj with the same name as functions in cljs/core.cljs (especially since both namespaces are auto-imported. Is cljs.core/inc a function, a macro, or both?). Maybe there’s a better way?

[1] https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/analyzer.clj#L193

Comment by Julien Eluard [ 15/Oct/13 6:23 AM ]

My bad, didn't realize it didn't make sense. Of course it's obvious now. I was confused by recent changes around function/macro name validation.
Now the warning could probably be improved a little but that doesn't seem very important. The Clojure warning is not that much better.

Comment by David Nolen [ 15/Oct/13 11:58 AM ]

We're not going to change how inlining works - the whole point is that we can reuse the same names. Adding :inline metadata seems like a promising way to warn of incorrect usage of inlining macros.





[CLJS-1217] cljs.test/run-tests with default env has no way to access summary Created: 21/Apr/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: Jenan Wise Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

clojure.test/run-tests returns a summary map that can be used to programmatically determine if a test has any errors or failures. As of the inclusion of async tests, cljs.test/run-tests returns nil. This makes it a bit verbose and redundant to write test runners that wish to use the default reporting but need to signal programmatically when there are errors or failures (such as when integrating with continuous build systems). As far as I can tell, the easiest approach under the current implementation looks like this:

;; All we care about is the error+fail count
;; and want cljs.test to print everything else as
;; normal.

(def error-count (atom 0))

(defmethod report [::test :pass] [m]
  ((get-method report [:cljs.test/default :pass]) m))

(defmethod report [::test :begin-test-ns] [m]
  ((get-method report [:cljs.test/default :begin-test-ns]) m))

(defmethod report [::test :error] [m]
  (swap! error-count inc)
  ((get-method report [:cljs.test/default :error]) m))

(defmethod report [::test :fail] [m]
  (swap! error-count inc)
  ((get-method report [:cljs.test/default :fail]) m))

(defmethod report [::test :summary] [m]
  ((get-method report [:cljs.test/default :summary]) m))

(defn runner
  []
  (run-tests (empty-env ::test) '...))

(from here)

This is true even when only sync tests are being used.

The docs mention that there is no support for coordination in cljs.test, which makes sense, but it seems like there should be a way to access the summary value without writing all of the report methods. Also, under the current implementation cljs.test/successful? appears to be unusable.






[CLJS-434] ClojureScript compiler prepends "self__" to defmulti forms when metadata in form of ^:field. Created: 01/Dec/12  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: Andrew Mcveigh Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug
Environment:

Mac OS X (10.7), java version "1.6.0_37", leiningen 2 preview 10, cljsbuild 0.2.9.
clojure/clojurescript master 01 December 2012 - 5ac1503



 Description   

Using the def form, with the specific metadata ^:field causes the cljs compiler
to prepend "self__" to the output js form.

The browser (latest chrome/firefox) does not recognize "self__".

Test Case: Tested against master: 5ac1503
-------------

(ns test-def)

(def ^:foo e identity)
e
; test_def.e = cljs.core.identity;
; test_def.e;

(def ^:field f identity)
f
; test_def.f = cljs.core.identity;
; self__.test_def.f;
; Uncaught ReferenceError: self__ is not defined

https://gist.github.com/4185793



 Comments   
Comment by Brandon Bloom [ 01/Dec/12 5:37 PM ]

code tags

Comment by David Nolen [ 20/Jan/13 12:54 AM ]

This one is a bit annoying. We should probably use namespaced keywords internally.





[CLJS-1200] compare behaves differently from Clojure Created: 13/Apr/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: newbie


 Description   
(compare [:foo 1] [:foo "one"])

Fails, also array-map & hash-map apparently cannot compare.






[CLJS-773] Use unchecked-*-int functions for real 32-bit math Created: 26/Feb/14  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: Francis Avila Assignee: Francis Avila
Resolution: Unresolved Votes: 0
Labels: numerics
Environment:

r2173



 Description   

Currently the unchecked-* functions and macros simply alias the primitive js operators. It would be nice if the unchecked-*-int family of functions and macros implemented C/Java-like signed int operations with silent overflows (just like in Clojure) using asm.js coersion idioms. This should also allow us to share such code between clojure and clojurescript without worrying about their different numerics.

A use case is that porting hash algorithms from java to clojurescript is trickier and more verbose than it needs to be.



 Comments   
Comment by David Nolen [ 08/May/14 6:43 PM ]

This sounds interesting, would like to see more thoughts on approach, benchmarks etc.

Comment by David Nolen [ 02/Dec/14 5:46 AM ]

Bump, this enhancements sound simple & fine.

Comment by Francis Avila [ 02/Dec/14 1:26 PM ]

I'll have time to do this in about a week. The implementation is straightforward (basically use xor 0 everywhere). The goal is correctness, but I expect performance to be as good as or better than it is now on most platforms. I'm not sure if advanced mode will drop intermediate truncations or what impact this has on performance.

Some higher-level numeric analysis using the asm.js type system is possible but I doubt it's worth it.

Comment by Francis Avila [ 16/Mar/15 11:14 AM ]

I completely forgot about this, sorry. I see you have scheduled it for the "next" release. Are you assigning it as well or will you still accept a patch?

Comment by David Nolen [ 16/Mar/15 11:26 AM ]

Be my guest





[CLJS-1138] Add page to Wiki "Slow dev builds" Created: 17/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Task Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: newbie


 Description   

A common mistake with cljsbuild is to include test directories in the source paths. Due to :recompile-dependents defaulting to true, tests will get unnecessarily recompiled.






[CLJS-1128] Describe internationalization strategies via Google Closure on the wiki Created: 16/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Task Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: documentation, newbie


 Description   

This can be done via Google Closure defines or via pulling a specific locale. A page should document how this can be done.






[CLJS-1145] numeric type inference should accept JVM primitive numeric type hints Created: 18/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None





[CLJS-836] Replace seq-based iterators with direct iterators for all non-seq collections that use SeqIterator Created: 08/Aug/14  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File cljs_836_v1.patch     Text File cljs_836_v2.patch    
Patch: Code and Test

 Description   

See http://dev.clojure.org/jira/browse/CLJ-1499



 Comments   
Comment by Peter Schuck [ 12/Dec/14 4:56 PM ]

This is a port of the patches / diffs at http://dev.clojure.org/jira/browse/CLJ-1499. I'm getting around a 2X perf improvement when running the benchmark quite.

Comment by David Nolen [ 13/Dec/14 8:43 AM ]

Thanks, looks great! Will check with Alex Miller about the status of CLJ-1499 and see if we can apply this one.

Comment by Peter Schuck [ 03/Apr/15 10:10 AM ]

CLJ-1499 has been applied to Clojure. I updated the patch to update the tests.





[CLJS-428] Using */ inside of a docstring causes compiler to produce invalid JavaScript Created: 25/Nov/12  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: Murphy McMahon Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux, lein-cljsbuild



 Description   

Due to how function docstrings are output by the ClojureScript compiler, the use of

*/
within a docstring causes the compiler to produce invalid JavaScript, breaking compilation, since '*/' will close the docstring's JavaScript comment block and the remaining docstring text will be uncommented as a result.



 Comments   
Comment by Murphy McMahon [ 25/Nov/12 12:32 PM ]

I didn't realize JIRA treats asterisks as markup, so just for clarification: the characters that produce the defect are slash asterisk, ie JavaScript's block comment closing syntax.

Comment by David Nolen [ 22/Dec/12 3:30 PM ]

Do you have a suggested fix for this?





[CLJS-1213] cljs.analyzer incorrectly marks all defs as tests when eliding test metadata Created: 20/Apr/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Minor
Reporter: Stephen Nelson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/analyzer.clj#L861

Cond threading will unconditionally assoc :test true when eliding test metadata for a namespace def.

This prevents accurate detection of test vars in cljs macros.






[CLJS-868] no arity warnings on recursive calls Created: 03/Oct/14  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If a function recursively invokes itself within its own body the invoke will not be checked for arity mismatch.






[CLJS-1196] Assert failed on 3190+ while :require-ing .js file in :libs directory Created: 12/Apr/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Defect Priority: Major
Reporter: Michal Till Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

OSX, jre 1.8.0_05-b13, Clojure 1.7.0-beta1



 Description   

While :require-ing a GC-compatible .js file that is in one of the :libs directories I get a failed assertion. I tried to hunt it down but wasn't successful.

My setup is:

  • :libs ["libs"] in project.clj
  • test.js in libs/test.js with a proper declaration goog.provide("app.test") at the first line
  • [app.test :as test] in one of the app ns header

This happens specifically from 0.0-3190 and newer, it does NOT happen in 0.0-3178.

Exception in thread "main" java.lang.AssertionError: Assert failed: (or (file? x) (url? x) (string? x)), compiling/private/var/folders/ym/l2qxd7l97kzfzftrdpqsclm40000gn/T/form-init5482203094887638175.clj:1:125)
at clojure.lang.Compiler.load(Compiler.java:7249)
at clojure.lang.Compiler.loadFile(Compiler.java:7175)
at clojure.main$load_script.invoke(main.clj:275)
at clojure.main$init_opt.invoke(main.clj:280)
at clojure.main$initialize.invoke(main.clj:308)
at clojure.main$null_opt.invoke(main.clj:343)
at clojure.main$main.doInvoke(main.clj:421)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.AssertionError: Assert failed: (or (file? x) (url? x) (string? x))
at cljs.util$ext.invoke(util.clj:114)
at cljs.closure$source_on_disk.invoke(closure.clj:1172)
at cljs.closure$output_unoptimized$fn__3624.invoke(closure.clj:1201)
at clojure.core$map$fn__4532.invoke(core.clj:2622)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:507)
at clojure.core$seq__4107.invoke(core.clj:135)
at clojure.core$filter$fn__4559.invoke(core.clj:2677)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:507)
at clojure.core$seq__4107.invoke(core.clj:135)
at clojure.core$map$fn__4532.invoke(core.clj:2614)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.Cons.next(Cons.java:39)
at clojure.lang.RT.next(RT.java:674)
at clojure.core$next__4091.invoke(core.clj:64)
at clojure.core$str$fn__4167.invoke(core.clj:528)
at clojure.core$str.doInvoke(core.clj:526)
at clojure.lang.RestFn.applyTo(RestFn.java:139)
at clojure.core$apply.invoke(core.clj:628)
at cljs.closure$deps_file.invoke(closure.clj:1015)
at cljs.closure$output_deps_file.invoke(closure.clj:1035)
at cljs.closure$output_unoptimized.doInvoke(closure.clj:1215)
at clojure.lang.RestFn.applyTo(RestFn.java:139)
at clojure.core$apply.invoke(core.clj:630)
at cljs.closure$build.invoke(closure.clj:1480)
at cljs.closure$build.invoke(closure.clj:1392)
at cljsbuild.compiler$compile_cljs$fn__3791.invoke(compiler.clj:81)
at cljsbuild.compiler$compile_cljs.invoke(compiler.clj:80)
at cljsbuild.compiler$run_compiler.invoke(compiler.clj:180)
at user$eval3923$iter_39593963$fn3964$fn_3982.invoke(form-init5482203094887638175.clj:1)
at user$eval3923$iter_39593963$fn_3964.invoke(form-init5482203094887638175.clj:1)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:507)
at clojure.core$seq__4107.invoke(core.clj:135)
at clojure.core$dorun.invoke(core.clj:3007)
at clojure.core$doall.invoke(core.clj:3023)
at user$eval3923.invoke(form-init5482203094887638175.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6792)
at clojure.lang.Compiler.eval(Compiler.java:6782)
at clojure.lang.Compiler.load(Compiler.java:7237)
... 11 more






[CLJS-1134] Lift protocols from cljs.closure into cljs.protocols ns Created: 17/Mar/15  Updated: 23/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: Next

Type: Task Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This is task towards presenting a stable API to users without reaching into the implementation namespaces.






[CLJS-1216] varargs not passed properly Created: 21/Apr/15  Updated: 23/Apr/15  Resolved: 23/Apr/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: 0.0-3211

Type: Defect Priority: Critical
Reporter: Karsten Schmidt Assignee: David Nolen
Resolution: Completed Votes: 2
Labels: compiler


 Description   

The following is broken as of 3196 (3165 is still working correctly)

(defn foo
  ([a] (foo a 10))
  ([a b & [c]] [a b c]))

(foo 1)
;; => [1 (10) nil] => should be [1 10 nil]

(foo 1 2)
;; => [1 (2) nil] => should be [1 2 nil]

(foo 1 2 3)
;; => [1 (2 3) nil] => should be [1 2 3]


 Comments   
Comment by Stephen Nelson [ 21/Apr/15 7:18 PM ]

This only occurs with defns that have multiple bodies, it does not occur with fns or with defns with a single body, or when the defn is called via apply rather than directly. Seems like it might be an off-by-one error in the calculation of required arguments in the defn dispatcher function. Test case:

test/dispatch_test.cljs
(ns test.destructuring-test
  (:require [cljs.test :refer-macros [deftest is]]))

(defn destructure
  ([kvs]
   kvs)
  ([k v & args]
   [k v args]))

(deftest test-destructuring
  (is (= [1 2 [3 4]]                                        ;; fails
         (destructure 1 2 3 4)))
  (is (= [1 2 [3 4]]                                        ;; passes
         (apply destructure [1 2 3 4])))
  )

In the compiled javascript the default case of the dispatcher only pulls one argument off before calling the variadic body, whereas the applyTo body pulls two off. Seems like the dispatcher is at fault.

test/dispatch_test.js
...
test.destructuring_test.destructure = (function test$destructuring_test$destructure() {
    var G__48557 = arguments.length;
    switch (G__48557) {
        case 1:
            return test.destructuring_test.destructure.cljs$core$IFn$_invoke$arity$1((arguments[(0)]));

            break;
        default:
            var argseq__17948__auto__ = (new cljs.core.IndexedSeq(Array.prototype.slice.call(arguments, 1), (0)));
            return test.destructuring_test.destructure.cljs$core$IFn$_invoke$arity$variadic((arguments[(0)]), argseq__17948__auto__);

    }
});

test.destructuring_test.destructure.cljs$core$IFn$_invoke$arity$1 = (function (kvs) {
    return kvs;
});

test.destructuring_test.destructure.cljs$core$IFn$_invoke$arity$variadic = (function (k, v, args) {
    return new cljs.core.PersistentVector(null, 3, 5, cljs.core.PersistentVector.EMPTY_NODE, [k, v, args], null);
});

test.destructuring_test.destructure.cljs$lang$applyTo = (function (seq48553) {
    var G__48554 = cljs.core.first.call(null, seq48553);
    var seq48553__$1 = cljs.core.next.call(null, seq48553);
    var G__48555 = cljs.core.first.call(null, seq48553__$1);
    var seq48553__$2 = cljs.core.next.call(null, seq48553__$1);
    return test.destructuring_test.destructure.cljs$core$IFn$_invoke$arity$variadic(G__48554, G__48555, seq48553__$2);
});
...
Comment by Karsten Schmidt [ 22/Apr/15 5:20 AM ]

You're right, Stephen! I've narrowed down the first occurrence, it's starting at r3178 - most likely with the changes done to cljs.core in this commit: https://github.com/clojure/clojurescript/commit/576fb6e054dd50ec458a3c9e4172a5a0002c7aea

will dig more & attempt a patch later today...

Comment by David Nolen [ 23/Apr/15 12:34 AM ]

I have a fix for this, just a simple error around computing the max fixed arity.

Comment by David Nolen [ 23/Apr/15 12:39 AM ]

fixed https://github.com/clojure/clojurescript/commit/c2296b11cc89a81baef1cd6a11567150d48605d9

Comment by David Nolen [ 23/Apr/15 12:51 AM ]

Cut 0.0-3211 with this fix.





[CLJS-1215] Guard against older Clojure dep Created: 21/Apr/15  Updated: 23/Apr/15  Resolved: 23/Apr/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None
Environment:

OS X



 Description   

Not sure if this is even the responsibility of, or possible to address from, the ClojureScript compiler, but here is the ask: If someone uses a project.clj specifying Clojure 1.6.0, emit a warn or balk. (I'm only thinking this is remotely possible from within the ClojureScript compiler if it can check the version of Clojure being used prior to making calls into Clojure.)

Rationale: Discovered a case where important compiler/analyzer warnings were not being emitted until project.clj was revised to specify Clojure 1.7.0-beta1.

Here is a minimal setup exhibiting the problem, (including both Quick Start and cljsbuild bits so it is easy to see the effects of the setup):

src/foo/bar.cljs:

(ns foo.bar
  (:require-macros [foo.macros :refer [call]]))

(call)

src/foo/macros.clj:

(ns foo.macros)

(defmacro call []
  `(foo.baz/quux))

src/foo/baz.cljs:

(ns foo.baz)

(defn quux [])

build.clj (meant to be used with cljs.jar):

(require 'cljs.closure)

(cljs.closure/build "src"
  {:output-to "main.js"})

project.clj:

(defproject ex "0.1.0-SNAPSHOT"
  :dependencies [[org.clojure/clojure "1.6.0"]
                 [org.clojure/clojurescript "0.0-3196"]]
  :plugins [[lein-cljsbuild "1.0.5"]]
  :source-paths ["src"]
  :cljsbuild {
    :builds [{:id "dev"
              :source-paths ["src"]
              :compiler {
                :output-to "main.js"}}]})

In the above project, the code is missing an important :require and the emitted JavaScript will be bad for :none. The good thing is the compiler warns about it:

$ java -cp cljs.jar:src clojure.main build.clj
WARNING: Use of undeclared Var foo.baz/quux at line 4 src/foo/bar.cljs

But, if cljsbuild is used, no warning is issued:

$ rm main.js
$ lein cljsbuild once dev
Compiling ClojureScript.
Compiling "main.js" from ["src"]...
Successfully compiled "main.js" in 4.567 seconds.

If the project.clj is revised to specify 1.7.0-beta1, then:

$ rm main.js 
$ lein cljsbuild once dev
Compiling ClojureScript.
Compiling "main.js" from ["src"]...
WARNING: Use of undeclared Var foo.baz/quux at line 4 src/foo/bar.cljs
Successfully compiled "main.js" in 4.258 seconds.


 Comments   
Comment by Mike Fikes [ 21/Apr/15 1:37 PM ]

An additional note:

If you downgrade the ClojureScript dep in project.clj to 0.0-3126 and use it specifying Clojure 1.6.0, then the desired warning is emitted:

$ lein cljsbuild once dev
Compiling ClojureScript.
Compiling "main.js" from ["src"]...
WARNING: Use of undeclared Var foo.baz/quux at line 4 src/foo/bar.cljs
Successfully compiled "main.js" in 3.969 seconds.

(In other words, the issue at the core of this ticket only happens if and only if you upgrade to the most recent ClojureScript and fail to also upgrade to the required Clojure dep.)

Comment by David Nolen [ 23/Apr/15 12:04 AM ]

Doing this isn't in scope. All the current tools have good support for detecting such issues and the new uberjar for people exploring ClojureScript for the first time doesn't have this problem.





[CLJS-739] fn/recur bug Created: 01/Jan/14  Updated: 20/Apr/15  Resolved: 23/Feb/14

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   
(defn create-functions [arr names]
  (let [name (first names)]
    (if name
      (recur (conj arr (fn [] (println name)))
             (rest names))
      arr)))
 
(doseq [fn (create-functions [] [:a :b :c :d])] (fn))

Generates the following incorrect code, the local name is not closed over:

cljs_play.let_bug.core.create_functions = function create_functions(arr, names) {
  while (true) {
    var name = cljs.core.first.call(null, names);
    if (cljs.core.truth_(name)) {
      var G__4744 = cljs.core.conj.call(null, arr, function(arr, names) {
        return function() {
          return cljs.core.println.call(null, name);
        };
      }(arr, names));
      var G__4745 = cljs.core.rest.call(null, names);
      arr = G__4744;
      names = G__4745;
      continue;
    } else {
      return arr;
    }
    break;
  }
};


 Comments   
Comment by David Nolen [ 01/Jan/14 9:43 PM ]

This is because we don't do two passes to determine if a function uses recur. loop/recur works because we know up front.

Comment by David Nolen [ 23/Feb/14 6:04 PM ]

I actually can't reproduce this in master - I've added tests to confirm https://github.com/clojure/clojurescript/commit/aaae2688aa2646bb252a9a4dd321e9fa8dbedb6a

Comment by Mike Fikes [ 20/Apr/15 3:00 PM ]

This can be reproduced in master with Nashorn, but not Node. (To be frank, I don't know whether this is a bug in Nashorn, or is what was being sought above, but commenting here just in case.)

$ rlwrap java -jar cljs.jar -m cljs.repl.nashorn
To quit, type: :cljs/quit
cljs.user=> *clojurescript-version*
"0.0-3208"
cljs.user=> (defn cljs-739 [arr names]
  (let [name (first names)]
    (if name
      (recur (conj arr (fn [] (println name)))
        (rest names))
      arr)))
#<function cljs$user$cljs_739(arr,names){
while(true){
var name = cljs.core.first.call(null,names);
if(cljs.core.truth_(name)){
var G__30 = cljs.core.conj.call(null,arr,((function (arr,names,name){
return (function (){
return cljs.core.println.call(null,name);
});})(arr,names,name))
);
var G__31 = cljs.core.rest.call(null,names);
arr = G__30;
names = G__31;
continue;
} else {
return arr;
}
break;
}
}>
cljs.user=> (with-out-str (doseq [fn (cljs-739 [] [:a :b :c :d])] (fn)))
:b
:c
:d
":a\n"

Node, on the other hand, honors with-out-string semantics by not printing anything and returning the string ":a\n:b\n:c\n:d\n".





[CLJS-1198] cljs.test may report summary before all async tests complete Created: 12/Apr/15  Updated: 19/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Jenan Wise Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None

Attachments: File cljs-1198-1    

 Description   

cljs.test may report summary before all async tests complete.

E.g, if you have an async test that looks like this:

(deftest a-test
  (async done
         (testing "a slow async test"
           (go
             (<! (timeout 1000))
             (is (= 0 1))
             (done)))))

then the report output may look like this:

Ran 1 tests containing 0 assertions.
0 failures, 0 errors.

<1 second elapses>

FAIL in () (cljs_test_with_slow_async_example/core_test.js:201:49)
expected: (= 0 1)
  actual: (not (= 0 1))

Minimal repo: https://github.com/jenanwise/cljs-test-with-slow-async-example



 Comments   
Comment by Leon Grapenthin [ 15/Apr/15 12:28 PM ]

I am quite surre that the problem has been introduced with this commit: https://github.com/clojure/clojurescript/commit/9bf486b22cebf5aba4154d07f3ad52e990ddc305

@David
I don't understand the intent of the commit message "cljs.test needs to default to sync, remove broken validation"

Why should the execution strategy default to :sync?

From my reading of the commit this would imply that, unless one provides map fixtures, tests are executed without support for async testing.

This is what happens. The problem goes away if I one adds e. g.

(use-fixtures :each {:before (fn [_])
:after (fn [_])})

I don't see why you removed the guard around async tests in the :sync execution. Its purpose was to throw when execution strategy is :sync an and async test is encountered.

If you can help with the intent of your commit, I'd be glad to provide the fix for myself. What validation was broken?

Comment by David Nolen [ 15/Apr/15 1:41 PM ]

Leon, when I changed how top-level fn emission worked for cross module code motion even though I could see good code getting generated I couldn't run the tests because of the validation bit. After poking around I couldn't make heads or tails of the invariant the code was trying to maintain and so I removed it. All the tests started working again.

Happy to see the invariants re-introduced if the code more clearly documents intent so I can understand it

Comment by Leon Grapenthin [ 15/Apr/15 2:26 PM ]

Can you specify on what you mean by the invariant?

Comment by David Nolen [ 15/Apr/15 2:28 PM ]

Leon, I have no idea what the check was doing nor why it was done that way, only that it prevented me from successfully running more important tests. So you will have to explain the approach to me

Comment by Leon Grapenthin [ 16/Apr/15 2:51 PM ]

Here I try to give you a quick overview of what is going on in the code you have removed/altered:

It solved the problem brought up in our discussion regarding the CLJS-988: The style in which clojure.test requires fixtures to be written didn't allow one to determine when an async test is over. Hence you came up with this requirement: http://dev.clojure.org/jira/browse/CLJS-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#issue-tabs

This is the way I have chosen to implement it:

In test-vars-block we create a block that looks up fixtures in the current env and decides whether to support async testing via execution-strategy.

In any case except for wrapped fixtures we run with support for async testing by executing the provided test functions in a block so that they can return async tests which are then picked up by the block runner. Also, via test-var-block additional code is wrapped around and added after them for reporting purposes.

In the case where wrapped fixtures are provided, we can't just create a test-var-block in the same fashion because flow control is passed to the wrapping fixtures and they don't execute or return a block. The only way work around this is to provide them directly with a function that invokes a nested block runner. Implicitly reusing test-var-block here was a decision made for obvious DRY reasons.

Now if async tests are used in the test function, the nested block runner could return before testing is finished, continuing testing too early. This is why the execution strategy is called sync: It expects the nested block runners to finish synchronously.

Per your requirment, testing should be aborted if an async test is encountered in the latter case. We can only know whether a test is async once it has been called and returned something. I didn't see a way to find out what was returned in the :sync result-expr directly, since test-var doesn't return what the test has returned. Hence I picked to look at what the test has returned in the test-var-block and throw if an async test is returned and async tests are disabled, storing this condition in the test-env. Today I see a strong alternative to that: Directly wrap the :test fn in the var in the :sync result-expr to throw if it returns an async test. It surely seems cleaner. You'd get a true invariant because the test-env would be out of the game. Notice though that anyhting thrown there will be catched by the reporting exception handler in test-var-block and testing would continue, so it has to rethrow to truely abort testing. Directly looking up the test-env in the async macro would have been another alternative which I have discarded for its dirtiness because it requires users to invoke async during testing to work.

I hope this helped you to understand the code. To make the code more understandable one could rename execution-strategy to async-supported? and return a boolean.

In any case, the :async execution-strategy needs to be the default, otherwise returned async test objects are not expanded into the root block and this CLJS-1198 happens.

I can provide a patch with the aforementioned improvements on sunday if you like. Finally I have no idea why the check prevented your tests from running - Can you tell me which tests I can use to potentially reproduce the problem?

Comment by Leon Grapenthin [ 19/Apr/15 8:32 AM ]

Patch notes:

  • changes default execution-strategy back to :async
  • prevents async tests from running when execution-strategy is sync

@David: I had to dissect test-var-block a bit because apparently alter-meta! is broken for vars. Please see commented lines 549 and 552 - Also I couldn't check whether this resolves the issue you had with tests being prevented from running after the compiler changes.





[CLJS-1212] Error in set ctor for > 8-entry map literal Created: 18/Apr/15  Updated: 18/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   
orion:Desktop mfikes$ java -jar cljs.jar -m cljs.repl.nashorn
To quit, type: :cljs/quit
cljs.user=> *clojurescript-version*
"0.0-3208"
cljs.user=> (set {:a 0 :b 0 :c 0 :d 0 :e 0 :f 0 :g 0 :h 0})             
#{[:a 0] [:b 0] [:c 0] [:d 0] [:e 0] [:f 0] [:g 0] [:h 0]}
cljs.user=> (set {:a 0 :b 0 :c 0 :d 0 :e 0 :f 0 :g 0 :h 0 :i 0})
TypeError: Cannot call undefined
	 cljs$core$set (.cljs_nashorn_repl/cljs/core.cljs:7912:11)
	 (NO_SOURCE_FILE <eval>:1:0)
	 (NO_SOURCE_FILE <eval>:1:0)
	 (NO_SOURCE_FILE <eval>:1:0)

This doesn't appear to be a recent regression (it is reproducible for versions from several months ago).



 Comments   
Comment by David Nolen [ 18/Apr/15 9:51 AM ]

It appears NodeSeq does not implement INext. We should probably have a fast path for INext implementors and something simpler for everyone else.





Generated at Sat Apr 25 07:32:23 CDT 2015 using JIRA 4.4#649-r158309.