<< Back to previous view

[CLJS-1286] REPL environment should be able to provide advice if source mapping fails Created: 23/May/15  Updated: 25/May/15

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

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


 Description   

For example browser REPL will often need users to supply :host-port, :host, and :asset-path in order to correctly parse files from stacktraces.






[CLJS-1287] CLJS exceptions should use same format as Clojure 1.7 (#exception {...}) Created: 25/May/15  Updated: 25/May/15

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

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


 Description   

Recent Clojure 1.7-RC adds new print format compatible with EDN syntax:

(ex-info "foobar" {:bar :baz})
#error {
 :cause "foobar"
 :data {:bar :baz}
 :via
 [{:type clojure.lang.ExceptionInfo
   :message "foobar"
   :data {:bar :baz}
   :at [clojure.core$ex_info invoke "core.clj" 4591]}]
 ...
}

(try (.indexOf 0 "baz") (catch Throwable e e))
#error {
 :cause "No matching method found: indexOf for class java.lang.Long"
 :via
 [{:type java.lang.IllegalArgumentException
   :message "No matching method found: indexOf for class java.lang.Long"
   :at [clojure.lang.Reflector invokeMatchingMethod "Reflector.java" 53]}]
 ...
}

Unfortunatelly ClojureScript format is different (and sometimes even not compatible with EDN):

(ex-info "foobar" {:bar :baz})
#ExceptionInfo{:message "foobar", :data {:bar :baz}}

(try (.indexOf 0  "baz") (catch js/Error e e))
#<TypeError: Object 0 has no method 'indexOf'>

The request to unify the output of exceptions might sound like "nitpicking".

However please consider applications, which share (lots of) code between server and client.
Any arbitrary difference between Clojure and ClojureScript adds future accidental complexity.

Hint: looking for green light and answer patches welcome

Last thing to consider is how to deal with stacktraces in the patch. Recent CLJS parses have a parser implemented on server side in Clojure. Should the patch move parsing to ClojureScript?



 Comments   
Comment by David Nolen [ 25/May/15 10:14 AM ]

Yes patch welcome. Thanks!





[CLJS-1284] IndexedSeq -seq implementation incorrect for i >= alength internal array Created: 23/May/15  Updated: 23/May/15  Resolved: 23/May/15

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

Type: Defect Priority: Major
Reporter: Daniel Skarda Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

ClojureScript 0.0-3291



 Description   
(defn foo-ok
  ([x0 & xs] [x0 xs]))

(defn foo-fail
  ([] nil)
  ([x0 & xs] [x0 xs]))


(foo-ok 0) => [0 nil]     ;; OK
(foo-ok 0 1) => [0 (1)]   ;; OK

(foo-fail) => nil         ;; OK
(foo-fail 0) => [0 (nil)] ;; INCORRECT
(foo-fail 0 1) => [0 (1)] ;; OK


 Comments   
Comment by David Nolen [ 23/May/15 1:53 PM ]

This is a bug with IndexedSeq, not fn arities.

Comment by David Nolen [ 23/May/15 2:10 PM ]

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

Comment by David Nolen [ 23/May/15 2:15 PM ]

I cut a 0.0-3297 interim release with this fix.

Comment by Daniel Skarda [ 23/May/15 5:33 PM ]

David, thank you for very fast analysis, fix and release!





[CLJS-1285] load-file regression Created: 23/May/15  Updated: 23/May/15  Resolved: 23/May/15

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

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


 Description   

We need to make load-file more robust. Currently we don't properly check goog.dependencies.written_ for the sourcePath, we always delete the basePath + source path.



 Comments   
Comment by David Nolen [ 23/May/15 5:12 PM ]

fixed https://github.com/clojure/clojurescript/commit/22ba5a6d0b780183d21bd69a64492e2216a7b379





[CLJS-1176] Push node.js REPL output through *out* and *err* Created: 27/Mar/15  Updated: 23/May/15  Resolved: 28/Mar/15

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

Type: Enhancement Priority: Major
Reporter: Chas Emerick Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File CLJS-1176.diff    
Patch: Code

 Description   

The node.js REPL environment currently lets the child node process inherit the JVM's stdout/err. This is bad for nREPL, and for any other setup where one would like to rebind *out* and/or *err* in order to redirect content print ed by ClojureScript code. Turning off the inheritance and pumping output from the process to *out* and *err* should be straightforward.

Related nREPL/piggieback issue: https://github.com/cemerick/piggieback/issues/41



 Comments   
Comment by Chas Emerick [ 28/Mar/15 5:10 AM ]

Patch attached. Node REPL now sends output to *out* and *err*.

Comment by David Nolen [ 28/Mar/15 12:07 PM ]

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

Comment by Joel Wilsson [ 08/Apr/15 7:10 AM ]

This doesn't work for me, because java.lang.Process does not have an isAlive() method. Maybe you were thinking of java.lang.Thread isAlive()?

user=> (require '[cljs.repl :as repl])
nil
user=> (require '[cljs.repl.node :as node])
nil
user=> (def env (node/repl-env))
#'user/env
user=> (repl/repl env)
Exception in thread "Thread-8" Exception in thread "Thread-9" java.lang.IllegalArgumentException: No matching field found: isAlive for class java.lang.UNIXProcess
	at clojure.lang.Reflector.getInstanceField(Reflector.java:271)
	at clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:315)
	at cljs.repl.node$pipe.invoke(node.clj:85)
	at cljs.repl.node$setup$fn__10733.invoke(node.clj:109)
...
Comment by Chas Emerick [ 08/Apr/15 7:37 AM ]

Damn, no, looks like I was using the JDK 8 javadoc when I wrote the patch: http://docs.oracle.com/javase/8/docs/api/java/lang/Process.html#isAlive--

Looks like this would be an equivalent expression:

(try (.exitValue proc) false (catch IllegalThreadStateException _ true))

We'll see if David prefers a patch for this, or to paste it in himself…

Comment by Chas Emerick [ 08/Apr/15 8:03 AM ]

Patch attached to CLJS-1192. Sorry for the snafu! :-/

Comment by Daniel Skarda [ 23/May/15 1:03 PM ]

In 0.0-3291 there is still one call to isAlive left on src/main/clojure/cljs/repl/node.clj:92

Comment by David Nolen [ 23/May/15 1:32 PM ]

fixed https://github.com/clojure/clojurescript/commit/46af7373d88f77972eb0f030ca43724d43c6b648





[CLJS-1283] (long \7) produces different result on Clojure/ClojureScript Created: 22/May/15  Updated: 22/May/15

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

Type: Defect Priority: Minor
Reporter: Sean Corfield Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In Clojure (long \7) produces 55 which is the ASCII code value for the character 7.

In ClojureScript, it seems this just converts the single character string "7" to a number and you get 7 as the answer. This might make writing portable string manipulation code rather hazardous?

(reported by irctc_ on IRC)



 Comments   
Comment by David Nolen [ 22/May/15 11:23 PM ]

Coercions like long only exist to simplify porting code. In general such things should be replaced.





[CLJS-1282] Add a :pprint option to the default reporter in cljs.test Created: 22/May/15  Updated: 22/May/15

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

Type: Enhancement Priority: Minor
Reporter: Sebastian Bensusan Assignee: Sebastian Bensusan
Resolution: Unresolved Votes: 0
Labels: test


 Description   

Now that cljs.pprint has landed, cljs.test could report failures and exceptions with it. The exact API is TBD.






[CLJS-1281] preserve test order Created: 21/May/15  Updated: 22/May/15

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

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: Sebastian Bensusan
Resolution: Unresolved Votes: 0
Labels: newbie


 Description   

We can keep tests sorted by :line var meta information.






[CLJS-1278] Asserts still fail while :require-ing .js file (either in :libs or in :source-paths) (same as CLJS-1196) Created: 20/May/15  Updated: 22/May/15

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

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

Attachments: Text File cljs_1278.patch    

 Description   

Following on CLJS-1196, I can't get it to work.

In version 0.0-3264 lein-cljsbuild crashed on weird eception `Caused by: java.lang.IllegalArgumentException: No implementation of method: :make-reader of protocol: #'clojure.java.io/IOFactory found for class: nil"` but the current version 0.0-3269 gives the same failed assertion as previously.

I've put up a sample project to illustrate the issue.

Steps to reproduce:

`git clone https://github.com/tillda/stackone`
`cd stackone`
`git checkout 537e5c69b844bc53c159e85cafc24310543cc918`
`lein clean && lein cljsbuild once temp`

Expected behaviour: cljs compiled successfully with src/vendor/client/closure.js and env/stackone/helpersjs.js being included.

Actual behaviour:

```
Compiling "resources/public/lein-cljsbuild-temp/dev-mode-deps.js" failed.
Exception in thread "main" java.lang.AssertionError: Assert failed: (or (file? x) (url? x) (string? x)), compiling/private/var/folders/ym/l2qxd7l97kzfzftrdpqsclm40000gn/T/form-init3642888309490821030.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.cljc:115)
at cljs.closure$source_on_disk.invoke(closure.clj:1206)
at cljs.closure$output_unoptimized$fn__3708.invoke(closure.clj:1235)
at clojure.core$map$fn__4551.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__4126.invoke(core.clj:135)
at clojure.core$filter$fn__4578.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__4126.invoke(core.clj:135)
at clojure.core$map$fn__4551.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__4110.invoke(core.clj:64)
at clojure.core$str$fn__4186.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:1040)
at cljs.closure$output_deps_file.invoke(closure.clj:1060)
at cljs.closure$output_unoptimized.doInvoke(closure.clj:1243)
at clojure.lang.RestFn.applyTo(RestFn.java:139)
at clojure.core$apply.invoke(core.clj:630)
at cljs.closure$build.invoke(closure.clj:1514)
at cljs.closure$build.invoke(closure.clj:1426)
at cljsbuild.compiler$compile_cljs$fn__3884.invoke(compiler.clj:81)
at cljsbuild.compiler$compile_cljs.invoke(compiler.clj:80)
at cljsbuild.compiler$run_compiler.invoke(compiler.clj:187)
at user$eval4018$iter_40544058$fn4059$fn_4077.invoke(form-init3642888309490821030.clj:1)
at user$eval4018$iter_40544058$fn_4059.invoke(form-init3642888309490821030.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__4126.invoke(core.clj:135)
at clojure.core$dorun.invoke(core.clj:3007)
at clojure.core$doall.invoke(core.clj:3023)
at user$eval4018.invoke(form-init3642888309490821030.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
Subprocess failed
```



 Comments   
Comment by David Nolen [ 20/May/15 10:21 AM ]

This issue is in danger of being closed. Please supply minimal steps to reproduce that do not involve anything other than the ClojureScript compiler. We no longer have time to wade through the indirection introduced by cljsbuild or any other downstream tooling. Thanks.

Comment by Michal Till [ 20/May/15 11:14 AM ]

@David Nolen: I have created a failing minimal testcase based on the Quick Start document. Here it is: https://github.com/tillda/cljs-testcase/

Comment by David Nolen [ 20/May/15 11:27 AM ]

Michal the failing example is not correct. You are not supplying any :libs option.

Comment by Michal Till [ 20/May/15 11:45 AM ]

Ah! Thank you very much! This additional issue was therefore my error. Now it seems to work even in my "big" example.

However it would be cool if there was a meaningful error message stating that a file path can't be resolved. If one is not an expert in the cljs compiler this is almost impossible to figure out. After all the error message in the CLJS-1196 issue and in this wrongfully reported one are exactly the same.

You may close this issue.

Comment by David Nolen [ 20/May/15 11:55 AM ]

We'll leave it open for the improving the error message.

Comment by Sebastian Bensusan [ 22/May/15 7:16 AM ]

Added the check in cljs.closure/source-on-disk where there is info for the error message.

For the supplied case, the error message is:

java.lang.IllegalArgumentException: The file file:/home/carlos/Playground/cljs-testcase/src/hello_world/closure.js 
lacks an associated source file. If it is a JavaScript library please add it to :libs}}

If a different wording or location of the check is needed, I'll submit a new patch with corrections.

Notes:

  • Changed:(:provides js) to (-provides js) in order to be consistent with IJavaScript.
  • cljs.clojure/source-on-disk takes a js argument that should satisfy with IJavaScript and ISourceMap if :source-map is enabled but the implementation is hardcoded to maps because :source-map and :source-url are used instead of ISourceMap methods -source-map and -source-url. I propose to extend PersistentMap and PersistentArrayMap to ISourceMap to make source-on-disk compliant with both protocols.




[CLJS-1280] double analysis warnings when using cljs.repl/load-file special fn Created: 21/May/15  Updated: 21/May/15

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

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





[CLJS-1206] Images in HTML don't show up when served from localhost:9000 Created: 15/Apr/15  Updated: 20/May/15  Resolved: 20/May/15

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

Type: Defect Priority: Minor
Reporter: J David Eisenberg Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: brepl, bug
Environment:

Fedora core 21, java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b26) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)


Attachments: Text File cljs_1206.patch     Text File cljs_1206_v2.patch     File imgtest_files.tgz    
Patch: Code

 Description   

In a project built from latest version of mies (from github), put an img element in the index.html page. When running scripts/brepl and loading http://localhost:9000, the image does not appear and the console gives a 404 error (see screenshot in attached tarball). The image shows up fine when loading the index.html as a plain file:/// in the browser, so the image definitely does exist in the correct directory.

I think the problem is in file src/clj/cljs/repl/browser.clj, the code starting server/dispatch-on; it lacks options for paths ending in .jpg and .png

I've included a diff -u file in the tarball as well with a possible patch. The patch also adds .svg as a valid type of file to serve, which was the particular thing I needed when I first saw this problem.



 Comments   
Comment by David Nolen [ 15/Apr/15 8:47 AM ]

Please attach patches directly, thanks!

Comment by J David Eisenberg [ 15/Apr/15 10:12 AM ]

Not sure what the format for a patch is, nor where it should be attached. (Add another attachment with the diff file?) Also, I think I see why the image doesn't appear -somewhere in the input or output process, the binary data is being converted to UTF-8.

Comment by Francis Avila [ 15/Apr/15 10:47 AM ]

Patch instructions. Add patch file as independent attachment to this ticket.

Before your code can be accepted you must sign a contributor's agreement.

Comment by J David Eisenberg [ 15/Apr/15 7:04 PM ]

Patch that allows server to correctly serve PNG, JPG, and SVG files. Patch uses maps to store data about MIME types and encoding, so other file extensions and types can be added easily if necessary.

Comment by Sander Dijkhuis [ 05/May/15 1:50 AM ]

Related / same issue:
http://dev.clojure.org/jira/browse/CLJS-1124

Comment by David Nolen [ 14/May/15 9:35 PM ]

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

Comment by kovas boguta [ 20/May/15 2:50 PM ]

New patch.

Comment by David Nolen [ 20/May/15 3:01 PM ]

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

Comment by J David Eisenberg [ 20/May/15 3:47 PM ]

Why no love for SVG? It's part of HTML5, and is used to a fair extent in the "real world."

Comment by David Nolen [ 20/May/15 4:24 PM ]

We just have to draw the line somewhere. browser REPL is not a replacement for a real web server.





[CLJS-1279] Node.js REPL does not flush process out and err immediately Created: 20/May/15  Updated: 20/May/15  Resolved: 20/May/15

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

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


 Comments   
Comment by David Nolen [ 20/May/15 2:49 PM ]

fixed https://github.com/clojure/clojurescript/commit/03529c47f9c38f3923a827166699f511f5ec0356





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

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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.

Comment by Nikita Prokopov [ 19/May/15 7:58 AM ]

CLJ-1699 has landed.

Right now CLJS tries to compile data_readers.cljc as a regular source code file:

Exception in thread "main" java.lang.AssertionError: No ns form found in src/data_readers.cljc, compiling:(/private/var/folders/0h/9vv4g3d955l6ctwwl4k9xjy40000gn/T/form-init3533791126017861878.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)
Comment by David Nolen [ 19/May/15 8:53 AM ]

This should be addressed first: http://dev.clojure.org/jira/browse/CLJS-1277





[CLJS-1277] relax requirement that files must declare a namespace, default to cljs.user Created: 19/May/15  Updated: 19/May/15

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

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


 Description   

This aligns better with Clojure itself supports.






[CLJS-1262] Write to compiler out before :merge-opts Created: 10/May/15  Updated: 19/May/15  Resolved: 19/May/15

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

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


 Description   

cljs.repl/repl* supports a :merge-opts, allowing derived REPLs, for example to specify :output-dir as a result of -setup.

A recent change in with_core_cljs appears to cause output to be (prematurely) written to the default :output-dir of "out": The call to -setup is wrapped with this macro.

This did not appear to occur with previous releases (I checked the last release of ClojureScript that was still on Clojure 1.6.0, but I haven't bisected to pinpoint the change.)

I haven't yet produced a minimal reproduction. (I will try to do so with QuickStart and add a comment).

I produced this with Ambly by manually creating an empty "out", and chmod a-w on it so that it can't be written in, and then when starting Ambly, I get a trace provoking the problem, showing where the write occurs:

$ script/repl
Exception in thread "main" java.io.FileNotFoundException: out/cljs/core.cljs.cache.edn (No such file or directory), compiling:(/private/var/folders/pd/w1724j050nd445hpm7mwlxs80000gn/T/form-init5299557692903408511.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.io.FileNotFoundException: out/cljs/core.cljs.cache.edn (No such file or directory)
	at java.io.FileOutputStream.open0(Native Method)
	at java.io.FileOutputStream.open(FileOutputStream.java:270)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
	at clojure.java.io$fn__9185.invoke(io.clj:230)
	at clojure.java.io$fn__9122$G__9091__9129.invoke(io.clj:69)
	at clojure.java.io$fn__9159.invoke(io.clj:166)
	at clojure.java.io$fn__9135$G__9087__9142.invoke(io.clj:69)
	at clojure.java.io$writer.doInvoke(io.clj:119)
	at clojure.lang.RestFn.invoke(RestFn.java:410)
	at clojure.lang.AFn.applyToHelper(AFn.java:154)
	at clojure.lang.RestFn.applyTo(RestFn.java:132)
	at clojure.core$apply.invoke(core.clj:630)
	at clojure.core$spit.doInvoke(core.clj:6662)
	at clojure.lang.RestFn.invoke(RestFn.java:425)
	at cljs.analyzer$write_analysis_cache.invoke(analyzer.cljc:2186)
	at cljs.analyzer$analyze_file.invoke(analyzer.cljc:2237)
	at cljs.compiler$with_core_cljs.invoke(compiler.cljc:967)
	at cljs.repl$repl_STAR_.invoke(repl.cljc:779)
	at cljs.repl$repl.doInvoke(repl.cljc:929)
	at clojure.lang.RestFn.invoke(RestFn.java:410)
	at user$eval4493.invoke(form-init5299557692903408511.clj:3)
	at clojure.lang.Compiler.eval(Compiler.java:6792)
	at clojure.lang.Compiler.eval(Compiler.java:6755)
	at clojure.core$eval.invoke(core.clj:3079)
	at clojure.main$eval_opt.invoke(main.clj:289)
	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)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
	at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:207)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
	at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:207)
	at user$eval5.invoke(form-init5299557692903408511.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


 Comments   
Comment by Mike Fikes [ 10/May/15 9:54 AM ]

Reproduction with lein:

project.clj:

(defproject foo "0.1.0"
  :dependencies [[org.clojure/clojure "1.7.0-beta2"]
                 [org.clojure/clojurescript "0.0-3255"]])

Make out not writable. (chmod a-w out). Or, alternatively, just look for the presence of out on filesystem alongside abc.

In any case, if you don't make out not writable, then this minimal repo will subsequently fail with an unrelated java.lang.IllegalArgumentException: No matching clause: as it is simply trying to exhibit the problem with out.

lein repl

Then execute these forms:

(require 'cljs.repl)

(defrecord FooEnv []
    cljs.repl/IJavaScriptEnv
  (-setup [repl-env opts]
    {:merge-opts {:output-dir "abc"}})
  (-evaluate [_ _ _ _])
  (-load [_ _ _])
  (-tear-down [_]))

(defn repl-env 
  [& {:as options}]
  (FooEnv.))

(cljs.repl/repl (repl-env))

With this older version, the out directory is not created:

(defproject foo "0.1.0"
  :dependencies [[org.clojure/clojure "1.7.0-beta1"]
                 [org.clojure/clojurescript "0.0-3196"]])
Comment by David Nolen [ 10/May/15 10:17 AM ]

Right the problem is that with-core-cljs calls analyze-file which will attempt to write the analysis cache. It's just a matter of considering the best way to avoid this.

Comment by Mike Fikes [ 18/May/15 9:27 PM ]

No longer occurs with 0.0-3269 and was fixed with this commit: https://github.com/clojure/clojurescript/commit/07bb585b181c02b3c33c7d88c46ddb888279b07f





[CLJS-1229] Simplify Closure CommonJS & ES 2015 Module support Created: 30/Apr/15  Updated: 18/May/15  Resolved: 18/May/15

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

Type: Task Priority: Major
Reporter: David Nolen Assignee: Maria Neise
Resolution: Completed Votes: 1
Labels: None


 Description   

Google Closure Compiler's ProcessCommonJSModules constructors are currently private. ES6ModuleLoader is a package private class with private constructors. All of these things must be made public if we are going to use them as individual passes on files. The current state of this functionality in Closure Compiler assumes being driven from the command line to produce a final build. In our case we want to use them as part of incremental compilation.



 Comments   
Comment by Maria Neise [ 18/May/15 2:44 PM ]

This has been fixed with https://github.com/google/closure-compiler/pull/952. In addition to making ProcessCommonJSModules and ES6ModuleLoader public, we also made ProcessEs6Modules public.





[CLJS-1276] var equality differs from Clojure Created: 18/May/15  Updated: 18/May/15

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

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


 Description   

(= #'x #'x) and (identical? #'x #'x) both fail. One solution would be to implement IEquiv and add var-identical? a la keyword-identical?.






[CLJS-1275] lein test configuration is broken Created: 18/May/15  Updated: 18/May/15  Resolved: 18/May/15

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

Type: Defect Priority: Major
Reporter: Sebastian Bensusan Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File cljs_1275.patch    

 Description   

When running lein test on a fresh copy of master it fails to find the tests. The :test-paths in project.clj is pointing to an old location.



 Comments   
Comment by Sebastian Bensusan [ 18/May/15 7:35 AM ]

This patch redirects :test-paths to the current directory of the tests: src/test/clojure.

Comment by David Nolen [ 18/May/15 8:39 AM ]

fixed https://github.com/clojure/clojurescript/commit/08398b25400b363ca22db885b7ed2460c92bd5fa





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

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

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

Linux, lein-cljsbuild


Attachments: Text File cljs_428.patch    

 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?

Comment by Sebastian Bensusan [ 18/May/15 7:23 AM ]

I added one extra step in cljs.compiler/emit-comment to replace all occurrences of "*/" into "* /" and it worked for V8, Spidermonkey, and Nashorn.

Notes:

  • The patch includes a test.
  • I couldn't find a standard way to escape */ on JavaScript. If there are other suggestions, like *\/, I wouldn't mind resubmitting the patch.




[CLJS-1273] clojure.lang.Symbol cannot be cast to clojure.lang.Namespace on macro expansion Created: 17/May/15  Updated: 17/May/15  Resolved: 17/May/15

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

Type: Defect Priority: Major
Reporter: lvh Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

Following macro & macro call:

{{
(defmacro defroutes
[routes]
(let [route-defs (for [{:keys [path view]} routes]
`(secretary/defroute ~path []
(session/put! :current-page ~view)))]
`(do (def ~'routes ~routes) ~@route-defs)))

(defroutes
[{:name "Home"
:path "/"
:view #'home-page}
{:name "Foo bar"
:path "/foo-bar"
:view #'foo-bar-page}
{:name "Baz quux"
:path "/baz-quux"
:view #'baz-quux-page}])
}}

... results in following compile-time exception:

{{
clojure.lang.ExceptionInfo : failed compiling file:src/cljs/shrieker/core.cljs
clojure.lang.ExceptionInfo : clojure.lang.Symbol cannot be cast to clojure.lang.Namespace
java.lang.ClassCastException : clojure.lang.Symbol cannot be cast to clojure.lang.Namespace
Error on file /Users/lvh/Projects/rackspace/shrieker/src/cljs/shrieker/core.cljs, line 106, column 60
}}

I believe this to be a bug, because replacing that macro call with its expansion works fine:

{{
(do
(def routes
[{:name "Home"
:path "/"
:view #'home-page}
{:name "Foo bar"
:path "/foo-bar"
:view #'foo-bar-page}
{:name "baz quux"
:path "/baz-quux"
:view #'baz-quux-page}])
(secretary/defroute "/" []
(session/put! :current-page #'home-page))
(secretary/defroute "/foo-bar" []
(session/put! :current-page #'foo-bar-page))
(secretary/defroute "/endpoint-quux" []
(session/put! :current-page #'baz-quux-page)))
}}

I was unable to repeat the experiment on more recent Clojurescripts, as some of my dependencies don't quite agree with it.



 Comments   
Comment by lvh [ 17/May/15 7:14 PM ]

JIRA doesn't appear to like my markup. Sorry about that

Comment by David Nolen [ 17/May/15 10:59 PM ]

You need to verify that this affects a released version of ClojureScript in a reproducible way (minimal case). Thanks.





[CLJS-1274] Allow assignment to namespace-qualified names in current namespace Created: 17/May/15  Updated: 17/May/15

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

Type: Enhancement Priority: Minor
Reporter: lvh Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In Clojure, you can def to a namespace-qualified name as long as it's in the current namespace. You can't do that in Clojurescript. This makes writing some macros that def to a local name a bit more annoying, since the syntax-quote will automatically namespace-qualify any symbols, so you have to write the somewhat unsightly and not super obvious ~'sym.






[CLJS-1272] :include-macros description inaccurate in require Created: 17/May/15  Updated: 17/May/15  Resolved: 17/May/15

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

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: docstring

Attachments: Text File CLJS-1272.patch    

 Description   

The description for :include-macros in the docstring for require indicates

:include-macros takes a list of macro symbols to refer from the namespace.

when really the spec only takes true as an argument, where the semantics are "causes macros to be required"



 Comments   
Comment by David Nolen [ 17/May/15 6:46 PM ]

fixed https://github.com/clojure/clojurescript/commit/721ba892892d7aa000460c45a6eb1afecd33eff5





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

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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.



 Comments   
Comment by Sebastian Bensusan [ 01/May/15 1:30 PM ]

This problem is solved by the inclusion of :end-run-tests as specified in CLJS-1226.

You can define:

(defmethod cljs.test/report [:cljs.test/default :end-run-tests] [m]
  (cljs.test/successful? m]))

since m is the summary with {:type :end-run-tests}.





[CLJS-1271] Defining a variable with the same name as an imported object compiles without errors Created: 17/May/15  Updated: 17/May/15

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

Type: Defect Priority: Minor
Reporter: Sebastian Bensusan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Importing a Google Closure ns and defining a variable with the same name compiles without exception, while in Clojure it throws an Exception with "Expecting var, but #VarName is mapped to class some.java.class".

Minimal sample:

(ns import-names.core
  (:import [goog debug]))

(def debug goog.debug)





[CLJS-1267] New :end-run-tests event not present in all public cljs.test functions Created: 13/May/15  Updated: 17/May/15

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

Type: Defect Priority: Minor
Reporter: Sebastian Bensusan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File cljs_1267.patch    

 Description   

After CLJS-1226, cljs.test API is inconsistent since only one of its public functions (run-tests) emits the new :end-run-tests event. The event should be added to test-all-vars, test-ns, test-var, and test-vars, making sure it is only fired once.



 Comments   
Comment by Leon Grapenthin [ 13/May/15 3:13 AM ]

To my knowledge all four are not reused within cljs.test, only the -block versions are, so there should be no worries about the event fired twice.

Comment by Sebastian Bensusan [ 17/May/15 12:37 PM ]

The patch includes the :end-run-tests event to test-ns, test-all-vars, test-vars, and test-var. I didn't add the event to the block functions since those can be reused and composed.

Notes:

  • If any of those functions are used sequentially in a script the event will be fired multiple times.
  • On each function the map passed to cljs.test/report contains different information besides {:type :end-run-tests}. test-var passes :var, test-vars passes :vars, test-ns and test-all-vars pass :ns.




[CLJS-1270] Docstring for delay not printed by cljs.repl/doc Created: 16/May/15  Updated: 17/May/15  Resolved: 17/May/15

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

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

Attachments: Text File CLJS-1270.patch    

 Description   
cljs.user=> (doc delay)
-------------------------
cljs.core/delay
([& body])
Macro
  nil

nil
cljs.user=> (source delay)
(defmacro delay [& body]
  "Takes a body of expressions and yields a Delay object that will
  invoke the body only the first time it is forced (with force or deref/@), and
  will cache the result and return it on all subsequent force
  calls."
  `(new cljs.core/Delay (fn [] ~@body) nil))
nil


 Comments   
Comment by Mike Fikes [ 16/May/15 8:12 PM ]

Attached CLJS-1270.patch

Comment by David Nolen [ 17/May/15 10:28 AM ]

fixed https://github.com/clojure/clojurescript/commit/264eb2b5153d6d1c3b6fcf0a42aad31956297cc5





[CLJS-1269] realized? docstring refers to promise and future Created: 16/May/15  Updated: 17/May/15  Resolved: 17/May/15

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

Type: Defect Priority: Trivial
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: docstring

Attachments: Text File CLJS-1269.patch    

 Description   

The docstring for realized? refers to nonexistent promise and future.

Likely copied over verbatim from Clojure:

cljs.user=> (doc realized?)
-------------------------
cljs.core/realized?
([d])
  Returns true if a value has been produced for a promise, delay, future or lazy sequence.

nil


 Comments   
Comment by Mike Fikes [ 16/May/15 7:57 PM ]

Added CLJS-1269.patch

Comment by David Nolen [ 17/May/15 10:27 AM ]

fixed https://github.com/clojure/clojurescript/commit/27ad78bb3f7fdfe64b4041bf60532489c2847105





[CLJS-1268] cljc support for cljs.closure/compile-file Created: 13/May/15  Updated: 14/May/15  Resolved: 14/May/15

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

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


 Description   

When calling cljs.closure/compile-file on a cljc file I get

ExceptionInfo Conditional read not allowed {:type :reader-exception, :line 5, :column 5, :file nil}
clojure.core/ex-info (core.clj:4591)
clojure.tools.reader/read* (reader.clj:896)
clojure.tools.reader/read-delimited (reader.clj:189)
clojure.tools.reader/read-list (reader.clj:202)
clojure.tools.reader/read* (reader.clj:878)
clojure.tools.reader/read (reader.clj:927)
cljs.analyzer/forms-seq*/forms-seq--124424/fn124425/fn-124426 (analyzer.cljc:24)
cljs.analyzer/forms-seq*/forms-seq--124424/fn-124425 (analyzer.cljc:18)
clojure.lang.LazySeq.sval (LazySeq.java:40)
clojure.lang.LazySeq.seq (LazySeq.java:49)
clojure.lang.Cons.next (Cons.java:39)
clojure.lang.RT.next (RT.java:674)
clojure.core/next--4109 (core.clj:64)
cljs.closure/compile-form-seq/fn-7854/fn-7855 (closure.clj:341)
cljs.closure/compile-form-seq/fn--7854 (closure.clj:340)
cljs.compiler/with-core-cljs (compiler.cljc:968)
cljs.closure/compile-form-seq (closure.clj:337)
cljs.closure/compile-file (closure.clj:376)

The issue is that forms-seq* is already called with a reader and the cljc check in there is not getting a file. Checking for ana/cljs-file is probably a solution.



 Comments   
Comment by David Nolen [ 14/May/15 9:36 PM ]

fixed https://github.com/clojure/clojurescript/commit/98ed0f4a08dfe757b7c647dbce22e235ef45b0a3





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

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

Type: Enhancement Priority: Minor
Reporter: Sander Dijkhuis Assignee: Unassigned
Resolution: Completed 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.)

Comment by David Nolen [ 14/May/15 9:36 PM ]

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





[CLJS-1249] cljs$lang$type gets removed during :advanced optimization, externs is not a solution Created: 06/May/15  Updated: 14/May/15  Resolved: 07/May/15

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

Type: Defect Priority: Minor
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None

Attachments: Text File cljs_1249.patch    

 Description   

This is a follow up to https://github.com/swannodette/mori/issues/144.

The problem:
In advanced mode, Closure Compiler removes most (or all) cljs$lang$type properties from generated constructor prototypes. It probably thinks that they are not referenced anywhere so it is safe to remove them.

There are two functions in cljs.core which depend on cljs$lang$type test and are definitely broken in advanced mode compilation:
1. pr-writer-impl method does the check to write user-friendly constructor name
2. missing-protocol method does the check as well (used in very rare scenario)

This is a test to reproduce the problem with bare clojurescript checkout:
https://gist.github.com/darwin/a83ea91f2e365946f076

I spent a good chunk of my day trying to find externs declaration which is IMO not possible.

None of these worked:

var cljs$lang$type;
Object.prototype.cljs$lang$type;

Note: This problem is not only affecting cljs$lang$type, it affects all properties set on type prototypes via (set! ...). It does not affect code which directly calls getBasis or reads a property on a specific type (Closure compiler sees that and prevents removal). It affects all code accessing those properties via "unknown" object when Closure compiler has no information about the object and it could be of any type so it does not connect the dots.

A proposal for a possible solution:

1. find a way how to instruct closure compiler to not remove cljs$lang$type and friend under without changing cljs.core implementation (I failed)
2. or use aset instead of set! to prevent closure compiler to reason about those things and leave them alone
3. or some better solution?



 Comments   
Comment by David Nolen [ 06/May/15 7:09 AM ]

Your externs should look like the following:

Object.cljs$lang$type;
Comment by Antonin Hildebrand [ 07/May/15 12:22 AM ]

Negative. Object.cljs$lang$type; does not work.

I'm pretty sure I'm including those externs correctly (debugged it to the point where externs are passed to the .compile call).

I will try to prepare a patch with aset.

Comment by Antonin Hildebrand [ 07/May/15 1:42 AM ]

the patch is based on top of http://dev.clojure.org/jira/browse/CLJS-1251

Comment by Thomas Heller [ 07/May/15 3:49 AM ]

I don't quite understand your motivation for this? As far as I understand the mori issue you are trying to create an add-on for mori which is based on top of a advanced compiled mori output?

Google Closure "advanced" mode is intended to optimize the whole program not just parts of it. AFAICT you intent to optimize mori and mori.devtools separately and then combine them later. That is not a good idea as both parts would include their own version of cljs.core (and others). Using aset basically bypasses the good parts of the Closure compiler which I'd be very careful with. Closure has facilities to export certain properties/functions but I'm not totally sure this should be done at all. Basically it looks like your are trying to get into the "guts" of an advanced compiled blob without the blob being prepared for it. Which will likely cause problems in many areas.

devtools also sounds like something that I want to use in :none and removed in :advanced. Why should my users carry the extra "weight" of a debug feature they are never going to see?

Comment by Antonin Hildebrand [ 07/May/15 4:18 AM ]

I agree with your points when cljs-devtools is used by a developer in a clojurescript project. Dev mode with :none works well and the developer has full control over removing cljs-devtools in :advanced mode.

Unfortunately with mori.js the story is different. Developers consuming the library typically use precompiled .js files from :advanced mode compilation. Javascript developers are unlikely to install clojure(script) tools and compile mori in dev mode with :none (they will use 'npm install mori').

That is why I forked mori.js and added mori.devtools.js as a new module. This enables mori users to optionally include this file in the same fashion as they could or could not include other optional mori parts (mori.mutable.js, mori.extras.js). Using modules properly should not affect mori.js size. As long as the developer uses the same version of precomiled mori.js and mori.devtools.js they should be good.

But mori is not the only case for this. I can imagine some clojurescript project would like to use modules to build devtools support module as a part of their release process and use it in special cases for debugging release builds. There should be no problem to use devtools in :advanced build if someone really wants to (for whatever reason).

While jumping through the hooks of advanced compilation, I discovered bugs which are real and should be fixed on clojurescript side. The problem of missing cljs$lang$type is not huge but exists and affects existing cljs.core code.

Comment by David Nolen [ 07/May/15 7:44 AM ]

I just confirmed that externs work fine for Object.cljs$type$lang.

Comment by Antonin Hildebrand [ 13/May/15 8:49 AM ]

Can you be more specific where did you put Object.cljs$type$lang to make it work?

I tried:
1. adding it into cljs-devtools, under resources/closure-js/externs/devtools.externs.js (to use Leiningen magic to include library externs) - and it really includes it
2. adding it into clojurescript compiler itself by adding it into src/main/cljs/cljs/externs.js (no effect)
3. adding it into mori.js as an extern file (I don't want to do that in mori)

None of those worked for me.

I'm ok with declining my proposed change. But you could copy and paste my test cases and investigate them. There is a real problem and they expose it.

(pr-str SampleType) should return user-friendly type name, not function string dump

Comment by David Nolen [ 14/May/15 11:41 AM ]

Antonin I don't have time to look into this for you. But believe me externs always work, the entire ClojureScript ecosystem depends on it.

Comment by Antonin Hildebrand [ 14/May/15 11:46 AM ]

Thanks for your reply. No worries. I understand. Thank you for all your work on ClojureScript.





[CLJS-1226] Add on-testing-complete hook Created: 27/Apr/15  Updated: 13/May/15  Resolved: 12/May/15

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

Type: Enhancement Priority: Minor
Reporter: Sebastian Bensusan Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: cljs, enhancement, test

Attachments: Text File cljs_1226.patch     Text File cls_1226_v2.patch    
Patch: Code

 Description   

When a test runner runs async tests created with cljs.test/async there is no reliable way to return the control from the async code in the test suite to the test runner. This is problematic since the test script might need the tests results to proceed or terminate.

A function to be called after all tests are done is proposed: cljs.test/*on-testing-complete-fn* and it would take the test summary as its only argument

It can be set by the user by calling cljs.test/set-on-testing-complete! which should be callable from JS (^:export)

Notes:
In the patch, the function cljs.test/successful? also has the ^:export metadata to be called from JS test runners.
The code was tested manually with V8, Spidermonkey, Nashorn, SlimerJs, and PhantomJS but not with JavaScript Core.



 Comments   
Comment by Jenan Wise [ 01/May/15 2:40 PM ]

Rather than relying on a global, what about if run-tests took a callback? It would differentiate the API from clojure.test but they are already different due to the env arg and nil return value.

Comment by Sebastian Bensusan [ 01/May/15 2:59 PM ]

It is currently in a global to allow easy access from outside cljs (js runners). By having it to pass it to run-tests it would be harder to make reusable test runners from outside cljs/ Said runners would have to know both the ns to run (TBD in each project) and the callback (what we want to reuse, i.e. phantom.exit(0))

Comment by David Nolen [ 05/May/15 7:02 AM ]

Is there any particular reason to not invoke do-report with a suitable dispatch value instead of adding a new function here?

Comment by Sebastian Bensusan [ 05/May/15 7:29 AM ]

I'm not sure that I understand. I thought do-report and report were meant for printing out the summary as a report. This on-testing-complete hook should allow the caller to do whatever he/she wants after all tests are done. Do you want to allow the caller to specify how report works for some new dispatch value by adding:

(defmethod report [::default :on-testing-complete] [m]
..custom-code)

Comment by David Nolen [ 05/May/15 7:32 AM ]

The purpose of report is just side effects, printing is only one possibility. Note there are several testing events that aren't even really used by the standard reporter.

Comment by Leon Grapenthin [ 05/May/15 12:37 PM ]

IMHO if you want to run anything synchronously before after or between tests, you should use fixtures or if necessary compose the desired blocks yourself.

At least making the latter possible is why I made run-block and the block builder fns public.

You can easily run

(run-block (concat (run-tests-block 'a-ns-to-be-tested 'another-ns-to-be-test )
[(fn []
;; your continuation code here
)]))

This is a reliable way to pick up control after testing.

This patch only affects testing done via run-tests. E. g. on-testing-complete-fn won't be invoked if a user invoked test-ns and testing is complete. You could hack it into the block composer in test-ns, but still users composing blocks in the way mentioned above couldn't rely on it being invoked.

Comment by Sebastian Bensusan [ 11/May/15 10:25 AM ]

I followed Leon's suggestions and used run-block to make my own test-block. The only problem is that my continuation function doesn't get the summary/env as an argument. From what I understood I could pass env as an argument to run-tests but it would get cleared right before my continuation function. I don't know how to work around this yet.

If you think my solution is a correct use of the cljs.test API then this patch isn't needed. If you believe that run-tests should report on-testing-done I'd be happy to submit a new patch adding a new event to the report event system. Then I could get the summary/env from a custom report method as David suggested.

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

I would not consider anything at the level of run-block part of the public API nor anything that anyone should be looking into. This stuff may change.

Please add a real reporting hook thanks.

Comment by Sebastian Bensusan [ 12/May/15 5:39 AM ]

Added :end-run-test event to cljs.test and a dummy event handler for it.

Comment by David Nolen [ 12/May/15 3:04 PM ]

fixed https://github.com/clojure/clojurescript/commit/31736450c6ca951c63bb685d744c11074fbfe323

Comment by Leon Grapenthin [ 12/May/15 4:09 PM ]

For API consistency this should also be in the blocks of `test-all-vars` in `test-ns`, `test-var` and `test-vars`.

Comment by David Nolen [ 12/May/15 4:24 PM ]

Happy to see a new ticket + patch that addresses the consistency issue.

Comment by Sebastian Bensusan [ 13/May/15 2:51 AM ]

Leon, I filled CLJS-1267 to address your point. Feel free to add any other API inconsistencies that :end-run-tests introduced.





[CLJS-1256] cljs.core/UUID should cache hash value Created: 08/May/15  Updated: 12/May/15  Resolved: 12/May/15

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

Type: Enhancement Priority: Major
Reporter: Nikita Prokopov Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File cljs-1256-cache-uuid-hash-3.patch    

 Description   

cljs.core/UUID calculates hash each time hash is called on it. This patch adds caching of the calculated hash value. It also avoids going through pr-str for hash calculation which involves string concatenation and couple of object allocations.

Updated patch also introduces public constructor cljs.core/uuid for creating UUID objects. All places where UUID. ctor was used will now generate a warning.



 Comments   
Comment by David Nolen [ 10/May/15 2:42 PM ]

The patch needs work. Declare __hash as a ^:mutable field on UUID. Thanks.

Comment by Nikita Prokopov [ 10/May/15 2:53 PM ]

This was the first thing I tried. Unfortunately new field breaks all the places where UUID is constructed, including user code. Suggestions how to avoid that?

Comment by David Nolen [ 10/May/15 5:18 PM ]

Raw constructors are generally considered implementation details but sadly we never provided a public fn ctor in this case. There's not much to do other than supply a uuid fn. Any users directly using the deftype ctor will get warnings about invalid arity and they will have to fix their code and rely on the new uuid ctor fn.

Comment by Nikita Prokopov [ 11/May/15 5:00 AM ]

Attaching fixed path

Comment by David Nolen [ 12/May/15 3:07 PM ]

The patch does not apply cleanly on master. Can we get a rebased patch? Thanks!

Comment by Nikita Prokopov [ 12/May/15 3:35 PM ]

Rebased onto 31736450c6ca951c63bb685d744c11074fbfe323

Comment by David Nolen [ 12/May/15 4:27 PM ]

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





[CLJS-1264] ClojureScript 0.0-3255 breaks compatibility with Clojure 1.6.0 Created: 11/May/15  Updated: 12/May/15  Resolved: 12/May/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3255, 0.0-3269
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Stephen Nelson Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

ClojureScript 0.0-3255 renamed several core files from clj to cljc. This breaks compatibility with Clojure 1.6.0, which is significant because Clojure 1.7.0 hasn't been released yet. This change forces any projects that bundle ClojureScript to switch to an unreleased Clojure or fall behind ClojureScript.

Falling behind ClojureScript is a significant problem as most development tools and libraries follow CLJS head, so a project that uses an old CLJS must use old libraries and build tools too, or maintain forks for pulling in bug fixes.

It would be good if this change could be reverted until CLJ 1.7 lands. If this is not possible, please consider maintaining a CLJ 1.6 branch and back porting bug fixes.



 Comments   
Comment by David Nolen [ 12/May/15 3:08 PM ]

There are stable releases of ClojureScript that work with Clojure 1.6.0. Use them if you need to. We're not going to maintain a 1.6.0 branch.





[CLJS-1265] Rename from .cljs to .cljc results in :reload failing Created: 12/May/15  Updated: 12/May/15

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

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


 Description   

Set up QuickStart browser REPL.

1. On disk, create a new file in src, say foo/bar.cljs and define a symbol in it.
2. In the REPL (require 'foo.bar) and then make use of the symbol.
3. On disk, rename the file to bar.cljc, and then edit the file to introduce a new symbol.
4. In the REPL (require 'foo.bar :reload) and then try to make use of the new symbol.

For a function defnition, at this point I get an error

TypeError: undefined is not an object (evaluating 'foo.bar.call_me.call')


 Comments   
Comment by Mike Fikes [ 12/May/15 2:05 PM ]

FWIW as a comparison, the same use case works properly with Clojure 1.7.0-beta2 (in regular lein repl).





[CLJS-1266] Node: Rename .cljs to .cljc -> old filenames in stacktrace Created: 12/May/15  Updated: 12/May/15

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

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


 Description   

Using QuickStart, set up Node REPL.

Manually add a foo/bar.cljs to filesystem with

(ns foo.bar)

(defn throw-ex [] (ffirst 1))

(defn call-me [] (throw-ex))

Check that it works:

cljs.user=> (require 'foo.bar)
nil
cljs.user=> (foo.bar/call-me)
repl:13
throw e__4210__auto__;
      ^
Error: 1 is not ISeqable
    at Object.cljs$core$seq [as seq] (/Users/mfikes/Desktop/hello_world-node/out/cljs/core.cljs:956:20)
    at Object.cljs$core$first [as first] (/Users/mfikes/Desktop/hello_world-node/out/cljs/core.cljs:965:16)
    at cljs$core$ffirst (/Users/mfikes/Desktop/hello_world-node/out/cljs/core.cljs:1398:11)
    at foo$bar$throw_ex (/Users/mfikes/Desktop/hello_world-node/out/foo/bar.cljs:3:20)
    at foo$bar$call_me (/Users/mfikes/Desktop/hello_world-node/out/foo/bar.cljs:5:19)
    at repl:1:105
    at repl:9:3
    at repl:14:4
    at Object.exports.runInThisContext (vm.js:74:17)
    at Domain.<anonymous> ([stdin]:41:34)

Then manually move bar.cljs to bar.cljc and add a new symbol so it looks like:

(ns foo.bar)

(defn throw-ex [] (ffirst 1))

(defn call-me [] (throw-ex))

(defn call-again [] (call-me))

Then reload the ns and use the new symbol:

cljs.user=> (require 'foo.bar :reload)
nil
cljs.user=> (foo.bar/call-again)
repl:13
throw e__4210__auto__;
      ^
Error: 1 is not ISeqable
    at Object.cljs$core$seq [as seq] (/Users/mfikes/Desktop/hello_world-node/out/cljs/core.cljs:956:20)
    at Object.cljs$core$first [as first] (/Users/mfikes/Desktop/hello_world-node/out/cljs/core.cljs:965:16)
    at cljs$core$ffirst (/Users/mfikes/Desktop/hello_world-node/out/cljs/core.cljs:1398:11)
    at foo$bar$throw_ex (/Users/mfikes/Desktop/hello_world-node/out/foo/bar.cljs:3:20)
    at foo$bar$call_me (/Users/mfikes/Desktop/hello_world-node/out/foo/bar.cljs:5:19)
    at foo$bar$call_again (/Users/mfikes/Desktop/hello_world-node/out/foo/bar.cljs:5:19)
    at repl:1:108
    at repl:9:3
    at repl:14:4
    at Object.exports.runInThisContext (vm.js:74:17)

This illustrates the defect. call_again and the other symbols are shown as being in the old filename.

Stop the REPL and restart it to see correct behavior:

cljs.user=> :cljs/quit
orion:hello_world-node mfikes$ rlwrap java -cp cljs.jar:src clojure.main node_repl.clj
Reading analysis cache for jar:file:/Users/mfikes/Desktop/hello_world-node/cljs.jar!/cljs/core.cljs
Compiling src/foo/bar.cljc
ClojureScript Node.js REPL server listening on 49397
Watch compilation log available at: out/watch.log
To quit, type: :cljs/quit
cljs.user=> (require 'foo.bar)
nil
cljs.user=> (foo.bar/call-again)
repl:13
throw e__4210__auto__;
      ^
Error: 1 is not ISeqable
    at Object.cljs$core$seq [as seq] (/Users/mfikes/Desktop/hello_world-node/out/cljs/core.cljs:956:20)
    at Object.cljs$core$first [as first] (/Users/mfikes/Desktop/hello_world-node/out/cljs/core.cljs:965:16)
    at cljs$core$ffirst (/Users/mfikes/Desktop/hello_world-node/out/cljs/core.cljs:1398:11)
    at foo$bar$throw_ex (/Users/mfikes/Desktop/hello_world-node/out/foo/bar.cljc:3:20)
    at foo$bar$call_me (/Users/mfikes/Desktop/hello_world-node/out/foo/bar.cljc:5:19)
    at foo$bar$call_again (/Users/mfikes/Desktop/hello_world-node/out/foo/bar.cljc:7:22)
    at repl:1:108
    at repl:9:3
    at repl:14:4
    at Object.exports.runInThisContext (vm.js:74:17)


 Comments   
Comment by Mike Fikes [ 12/May/15 2:04 PM ]

FWIW as a comparison, the same use case works properly with Clojure 1.7.0-beta2.





[CLJS-1263] :libs regression, can no longer specify specific files Created: 11/May/15  Updated: 11/May/15  Resolved: 11/May/15

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

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


 Description   

:libs currently works great for directories but the support for individual files specified by the user is broken.



 Comments   
Comment by David Nolen [ 11/May/15 3:43 PM ]

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





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

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

Type: Defect Priority: Major
Reporter: Jenan Wise Assignee: David Nolen
Resolution: Completed 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.

Comment by Sebastian Bensusan [ 01/May/15 3:36 PM ]

Experience report: tested this patch with the problematic repo and some other slow async test cases including fixture variations and it seems to work as expected. It also worked with ClojureScript's own tests (tested on all platforms but JavaScriptCore).

Hope this helps.

Comment by David Nolen [ 05/May/15 6:58 AM ]

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

Comment by Jenan Wise [ 11/May/15 12:31 PM ]

Many thanks!





[CLJS-1242] Add cljs.core/pattern? predicate Created: 03/May/15  Updated: 10/May/15

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

Type: Enhancement Priority: Minor
Reporter: Brandon Bloom Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: patch

Attachments: Text File CLJS-1242_v01.patch    
Patch: Code and Test

 Description   

Just like http://dev.clojure.org/jira/browse/CLJS-1241 , this helps with clj/cljs cross-platform development.



 Comments   
Comment by Brandon Bloom [ 03/May/15 2:38 PM ]

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

Comment by Brandon Bloom [ 10/May/15 11:36 PM ]

Note that there already is a cljs.core/regexp?, since it's used in a few places by core.





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

Status: In Progress
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
Fix Version/s: Next

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


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

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






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

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

Type: Defect Priority: Minor
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.

Here is the transducer and the tests that 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))))))

;;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

Comment by David Nolen [ 26/Apr/15 4:04 AM ]

Please demonstrate the problem without core.async. Thanks.

Comment by Lucas Cavalcanti [ 26/Apr/15 7:32 PM ]

Hi,

the last test I posted on the ticket, fails in cljs, but not in clj:

;;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]))))
Comment by David Nolen [ 27/Apr/15 7:43 AM ]

I've removed the core.async bits from the description to clarify the issue.

Comment by David Nolen [ 10/May/15 2:40 PM ]

The implementation of sliding-window above does not appear to be correct, it doesn't return the result. This ticket needs more information.

Comment by Lucas Cavalcanti [ 10/May/15 3:51 PM ]

As I said on http://dev.clojure.org/jira/browse/CLJS-1222?focusedCommentId=38620&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-38620

changing the 1-arity of the sliding-window to that fixes the transducer.

The point of this ticket now is that the behavior of the same (wrong) transducer in clj (both core.async and sequence) and cljs (core.async) is different than cljs sequence.





[CLJS-1209] Reduce produces additional final nil when used w/ eduction Created: 16/Apr/15  Updated: 10/May/15  Resolved: 10/May/15

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

Type: Defect Priority: Major
Reporter: Karsten Schmidt Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: transducers


 Description   
Unable to find source-code formatter for language: clojure. Available languages are: javascript, sql, xhtml, actionscript, none, html, xml, java
(defn my-conj
  [acc x]
  (prn acc x)
  (conj acc x))

(reduce my-conj [] (eduction (map identity) [1 2 3]))
;; [] 1
;; [1] 2
;; [1 2] 3
;; [1 2 3] nil
;; [1 2 3 nil]

This seems to be a CLJS specific issue - the above works fine in CLJ1.7.0-beta1. On the other hand, reductions too doesn't suffer this behavior (in CLJS):

Unable to find source-code formatter for language: clojure. Available languages are: javascript, sql, xhtml, actionscript, none, html, xml, java
(reductions my-conj [] (eduction (map identity) [1 2 3]))
;; [] 1
;; [1] 2
;; [1 2] 3
;; ([] [1] [1 2] [1 2 3])


 Comments   
Comment by David Nolen [ 10/May/15 2:30 PM ]

I cannot reproduce with 0.0-3269. Please feel free to reopen if more information can be supplied.

Comment by Karsten Schmidt [ 10/May/15 4:44 PM ]

I don't know, David - don't understand how this can be, since I just tried the same w/ 3269 and the extra `nil` still is happening (I first did use a clean setup as described in CLJS quickstart wiki). The below is from a figwheel REPL:

cljs.user=> *clojurescript-version*
"0.0-3269"

cljs.user=> (defn my-conj [acc x] (prn acc x) (conj acc x))
#<function cljs$user$my_conj(acc,x){
cljs.core.prn.call(null,acc,x);
return cljs.core.conj.call(null,acc,x);
}>

cljs.user=> (reduce my-conj [] (eduction (map identity) [1 2 3]))
[] 1
[1] 2
[1 2] 3
[1 2 3] nil
[1 2 3 nil]
Comment by Karsten Schmidt [ 10/May/15 4:47 PM ]

verified to still occur w/ 0.0-3269

Comment by Karsten Schmidt [ 10/May/15 4:49 PM ]

I you want, I can attach a zip of my test project...

Comment by David Nolen [ 10/May/15 5:10 PM ]

I wasn't quite careful enough when trying out your failing example. I see the problem, fix coming.

Comment by David Nolen [ 10/May/15 5:14 PM ]

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





[CLJS-1261] source fn fails for fns with conditional code Created: 09/May/15  Updated: 10/May/15  Resolved: 10/May/15

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

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

(Affects 0.0-3264)



 Description   

If you use the source ClojureScript REPL function on a function defined in a CLJC file, where the function itself contains some conditional code, then the operation will fail with "Conditional read not allowed".

To reproduce:
Set up the QuickStart Browser REPL example, but instead of core.cljs, set up a core.cljc file. In that file additionally include

(defn f 
  "Eff"
  [] 
  1)

(defn g 
  "Gee"
  []
  #?(:clj "clj" :cljs "cljs"))

Verify that you can call, get the doc for, and source for f.

But, on the other hand, while you can call and get the doc for g, you can't do (source hello-world.core/g).

This results in:

cljs.user=> (source hello-world.core/g)
clojure.lang.ExceptionInfo: Conditional read not allowed at line 1 <cljs repl> {:file "<cljs repl>", :line 1, :column 1, :tag :cljs/analysis-error}
	at clojure.core$ex_info.invoke(core.clj:4591)
	at cljs.analyzer$error.invoke(analyzer.cljc:384)
	at cljs.analyzer$macroexpand_1.invoke(analyzer.cljc:1853)
	at cljs.analyzer$analyze_seq.invoke(analyzer.cljc:1896)
	at cljs.analyzer$analyze$fn__1567.invoke(analyzer.cljc:1992)
	at cljs.analyzer$analyze.invoke(analyzer.cljc:1985)
	at cljs.repl$evaluate_form.invoke(repl.cljc:429)
	at cljs.repl$eval_cljs.invoke(repl.cljc:547)
	at cljs.repl$repl_STAR_$read_eval_print__4295.invoke(repl.cljc:814)
	at cljs.repl$repl_STAR_$fn__4301$fn__4308.invoke(repl.cljc:851)
	at cljs.repl$repl_STAR_$fn__4301.invoke(repl.cljc:850)
	at cljs.compiler$with_core_cljs.invoke(compiler.cljc:968)
	at cljs.repl$repl_STAR_.invoke(repl.cljc:816)
	at cljs.repl$repl.doInvoke(repl.cljc:932)
	at clojure.lang.RestFn.invoke(RestFn.java:439)
	at user$eval30.invoke(repl.clj:10)
	at clojure.lang.Compiler.eval(Compiler.java:6792)
	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$script_opt.invoke(main.clj:337)
	at clojure.main$main.doInvoke(main.clj:421)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.lang.Var.invoke(Var.java:379)
	at clojure.lang.AFn.applyToHelper(AFn.java:154)
	at clojure.lang.Var.applyTo(Var.java:700)
	at clojure.main.main(main.java:37)
Caused by: clojure.lang.ExceptionInfo: Conditional read not allowed {:type :reader-exception, :line 19, :column 5, :file nil}
	at clojure.core$ex_info.invoke(core.clj:4591)
	at clojure.tools.reader$read_STAR_.invoke(reader.clj:896)
	at clojure.tools.reader$read_delimited.invoke(reader.clj:189)
	at clojure.tools.reader$read_list.invoke(reader.clj:202)
	at clojure.tools.reader$read_STAR_$fn__767.invoke(reader.clj:878)
	at clojure.tools.reader.reader_types$log_source_STAR_$fn__501.invoke(reader_types.clj:240)
	at clojure.lang.AFn.applyToHelper(AFn.java:152)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.core$apply.invoke(core.clj:628)
	at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1866)
	at clojure.lang.RestFn.invoke(RestFn.java:425)
	at clojure.tools.reader.reader_types$log_source_STAR_.invoke(reader_types.clj:239)
	at clojure.tools.reader$read_STAR_.invoke(reader.clj:867)
	at clojure.tools.reader$read.invoke(reader.clj:928)
	at clojure.tools.reader$read.invoke(reader.clj:926)
	at cljs.repl$source_fn.invoke(repl.cljc:1133)
	at cljs.repl$source.invoke(repl.cljc:1153)
	at clojure.lang.AFn.applyToHelper(AFn.java:160)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.lang.AFunction$1.doInvoke(AFunction.java:29)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.core$apply.invoke(core.clj:632)
	at cljs.analyzer$macroexpand_1.invoke(analyzer.cljc:1859)
	... 24 more
Caused by: java.lang.RuntimeException: Conditional read not allowed
	at clojure.tools.reader$read_cond.invoke(reader.clj:490)
	at clojure.tools.reader$read_dispatch.invoke(reader.clj:66)
	at clojure.tools.reader$read_STAR_$fn__767.invoke(reader.clj:878)
	at clojure.tools.reader.reader_types$log_source_STAR_$fn__501.invoke(reader_types.clj:240)
	at clojure.lang.AFn.applyToHelper(AFn.java:152)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.core$apply.invoke(core.clj:628)
	at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1866)
	at clojure.lang.RestFn.invoke(RestFn.java:425)
	at clojure.tools.reader.reader_types$log_source_STAR_.invoke(reader_types.clj:239)
	at clojure.tools.reader$read_STAR_.invoke(reader.clj:867)
	... 45 more


 Comments   
Comment by David Nolen [ 10/May/15 2:21 PM ]

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

Comment by Mike Fikes [ 10/May/15 2:44 PM ]

Confirmed fixed.

Comment by Mike Fikes [ 10/May/15 2:53 PM ]

I created a similar ticket for Clojure: http://dev.clojure.org/jira/browse/CLJ-1728





[CLJS-1166] Browser REPL stacktraces unprocessed if explicit IP used Created: 24/Mar/15  Updated: 10/May/15  Resolved: 10/May/15

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

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

QuickStart Browser REPL OS X Safari (other browsers as well)



 Description   

Go through the Quick Start but change the repl/connect form to use an explicit IP instead of localhost. (In this case the IP I am trying is indeed the same host, if that matters.)

(defonce conn
  (repl/connect "http://10.96.82.207:9000/repl"))

Then connect to the REPL using the explicit IP http://10.96.82.207:9000.

The REPL will function properly but stacktraces are not properly processed. Here is an example (generated using Safari):

ClojureScript:cljs.user> (ffirst [1])
Error: 1 is not ISeqable
cljs$core$seq@http://10.96.82.207:9000/out/cljs/core.js:4667:17
cljs$core$first@http://10.96.82.207:9000/out/cljs/core.js:4697:22
cljs$core$ffirst@http://10.96.82.207:9000/out/cljs/core.js:5774:23


eval code
eval@[native code]
http://10.96.82.207:9000/out/clojure/browser/repl.js:42:271
clojure$browser$repl$evaluate_javascript@http://10.96.82.207:9000/out/clojure/browser/repl.js:45:4
http://10.96.82.207:9000/out/clojure/browser/repl.js:242:173
deliver@http://10.96.82.207:9000/out/goog/messaging/abstractchannel.js:142:21
xpcDeliver@http://10.96.82.207:9000/out/goog/net/xpc/crosspagechannel.js:733:19
messageReceived_@http://10.96.82.207:9000/out/goog/net/xpc/nativemessagingtransport.js:321:23
fireListener@http://10.96.82.207:9000/out/goog/events/events.js:741:25
handleBrowserEvent_@http://10.96.82.207:9000/out/goog/events/events.js:862:34
http://10.96.82.207:9000/out/goog/events/events.js:276:42


 Comments   
Comment by David Nolen [ 10/May/15 2:45 PM ]

as far as I can tell this was resolved with the fix for CLJS-1258 https://github.com/clojure/clojurescript/commit/d0bf12f24f3455fdc45962206580ab50ca907638





[CLJS-1191] Update clojure.walk to the current version on clojure Created: 06/Apr/15  Updated: 10/May/15

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

Type: Defect Priority: Minor
Reporter: Stuart Mitchell Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: enhancement, performance

Attachments: Text File 50.patch     Text File CLJS-1191.patch    
Patch: Code

 Description   

Currently clojure.walk can not handle records

It is using an old version of clojure.walk and clojure has improved the implementation because of

http://dev.clojure.org/jira/browse/CLJ-1105


src/cljs/clojure/walk.cljs | 4 ++++
1 file changed, 4 insertions

diff --git a/src/cljs/clojure/walk.cljs b/src/cljs/clojure/walk.cljs
index f2ebd8d..541ecea 100644
— a/src/cljs/clojure/walk.cljs
+++ b/src/cljs/clojure/walk.cljs
@@ -43,7 +43,11 @@ the sorting function."}
{:added "1.1"}
[inner outer form]
(cond
+ (list? form) (outer (apply list (map inner form)))
+ (satisfies? IMapEntry form) (outer (vec (map inner form)))
(seq? form) (outer (doall (map inner form)))
+ (satisfies? IRecord form)
+ (outer (reduce (fn [r x] (conj r (inner x))) form form))
(coll? form) (outer (into (empty form) (map inner form)))
:else (outer form)))



 Comments   
Comment by David Nolen [ 07/Apr/15 5:56 AM ]

Please attach the patch as a file. Thanks!

Comment by Stuart Mitchell [ 07/Apr/15 7:18 PM ]

I think this one works

it is a mail formatted patch

Comment by David Nolen [ 08/Apr/15 6:07 AM ]

Please follow the patch conventions described here https://github.com/clojure/clojurescript/wiki/Patches. Thank you.

Comment by David Nolen [ 12/Apr/15 4:53 PM ]

Stuart, I don't see you on the list of contributors. Please submit a CA so I can apply the patch. Thanks!

Comment by Stuart Mitchell [ 13/Apr/15 7:49 PM ]

Hopefully this is the right format

Comment by Stuart Mitchell [ 13/Apr/15 7:50 PM ]

Contributor agreement signed as well

Comment by Sebastian Bensusan [ 01/May/15 1:24 PM ]

Tested the patch on the REPL, works as expected except for walking fns that modify the keys:

> (defrecord Foo [name])
cljs.user/Foo
> (w/prewalk #(if (keyword? %) (str %) %) (Foo. "foo"))
#cljs.user.Foo{:name "foo", ":name" "foo"}

It is not consistent with walking the same fn over a map:

> (w/prewalk #(if (keyword? %) (str %) %) {:name "foo"})

{":name" "foo"}

This behavior was noted in the original Clojure patch as well: http://dev.clojure.org/jira/browse/CLJ-1239 and might be undesirable since it surprises the user.





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

Status: Reopened
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1127] validate compiled file written to disk Created: 16/Mar/15  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1139] Repeated applications of `ns` form at the REPL are not additive Created: 17/Mar/15  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1174] Simple warning if a namespace with dashes not found but a file path with dashes exists Created: 27/Mar/15  Updated: 10/May/15

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

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





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

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1133] REPL require results in warnings to be emitted twice Created: 17/Mar/15  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-712] resolve-var for symbol with dot still wrong Created: 03/Dec/13  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-773] Use unchecked-*-int functions for real 32-bit math Created: 26/Feb/14  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-868] no arity warnings on recursive calls Created: 03/Oct/14  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1134] Lift protocols from cljs.closure into cljs.protocols ns Created: 17/Mar/15  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1141] memoization of js-dependency-index and get-upstream-deps needs knobs Created: 18/Mar/15  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1147] reconnect logic for browser REPLs Created: 18/Mar/15  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1228] cljs.util/topo-sort is polynomial on larger dependency graphs Created: 28/Apr/15  Updated: 10/May/15

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

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


 Comments   
Comment by David Nolen [ 08/May/15 7:35 AM ]

This problem was reported due the performance of cljs.analyzer/ns-dependents when used by cljs.compiler/compile-file. However as cljs.compiler/compile-file does not need the topological sorting bit, we should supply a faster alternative to cljs.analyzer/ns-dependents which simply returns a distinct seq which can be poured into a set.





[CLJS-1236] `constructor` needs to munged if used as namespace segment Created: 01/May/15  Updated: 10/May/15

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

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


 Description   

Will make goog.require believe that the namespace has already been loaded and throw an exception since all JS objects have the constructor property.



 Comments   
Comment by David Nolen [ 04/May/15 8:19 AM ]

This issue is not quite as simple as it sounds as we actually need a special case for namespace munging. For example we don't want to munge Foo.constructor but we do want to munge ns.foo.constructor. To implement the fix correctly it would require changing all the cases where library names are munged.





[CLJS-1237] ns-unmap doesn't work on refers from cljs.core Created: 01/May/15  Updated: 10/May/15

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

Type: Defect Priority: Major
Reporter: Chouser Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: ns-unmap

Attachments: Text File 0001-CLJS-1237-ns-unmap-adds-to-namespace-s-excludes.patch     Text File 0002-CLJS-1237-ns-unmap-adds-to-namespace-s-excludes.patch    
Patch: Code

 Description   

In ClojureScript, using ns-unmap on a symbol from cljs.core doesn't exclude it from the current namespace. Note that both a function and a macro still exist, even after unmapping:

To quit, type: :cljs/quit  
cljs.user=> (ns-unmap 'cljs.user 'when) ;; macro
true  
cljs.user=> (ns-unmap 'cljs.user 'not)  ;; function
true  
cljs.user=> (when 1 2)  
2  
cljs.user=> (not false)  
true  

This differs from the behavior of Clojure's ns-unmap. Note the appropriate errors when attempting to use unmapped symbols:

Clojure 1.7.0-beta1
user=> (ns-unmap 'user 'when) ;; macro
nil
user=> (ns-unmap 'user 'not)  ;; function
nil
user=> (when 1 2)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: when in this context, compiling:(NO_SOURCE_PATH:11:1) 
user=> (not false)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: not in this context, compiling:(NO_SOURCE_PATH:12:1) 

Somehow ClojureScript's ns-unmap needs to add the symbol to the current namespace's :excludes set. Note that the def special form does this already (after it displays a warning).

We have two solutions. 0001 extends the ns form's :merge behavior to support :excludes, and then uses this in ns-unmap. If the enhancement to ns isn't wanted, patch 0002 changes ns-unmap to update :excludes directly.



 Comments   
Comment by David Nolen [ 05/May/15 7:23 AM ]

The second patch is preferred. However it seems the second patch is too permissive. The :excludes logic should only be applied if the symbol identifies a core macro or fn.

Comment by Chouser [ 05/May/15 3:46 PM ]

The ns form's own :refer-clojure :exclude accepts arbitrary symbols and adds them to the namespace's :excludes set, which seems like the same permissiveness problem. Do you want a patch that addresses the permissiveness of both ns and ns-unmap in this ticket, or should such a patch go in a new ticket?

Comment by David Nolen [ 05/May/15 4:08 PM ]

New ticket to fix the bug that :exclude doesn't check the symbol list for cljs.core declared vars, and an updated patch here please.





[CLJS-1247] Add *out* and *err* Created: 04/May/15  Updated: 10/May/15

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

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


 Comments   
Comment by David Nolen [ 06/May/15 9:02 AM ]

See CLJS-710





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

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

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





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

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-620] Warnings are generated when using a macro in argument position Created: 14/Oct/13  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-744] ISequential types should implement JS indexOf, lastIndexOf Created: 05/Jan/14  Updated: 10/May/15

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

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





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

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1070] top-level boolean inference does not work Created: 28/Feb/15  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1195] generic reusable command line argument parsing for REPLs Created: 10/Apr/15  Updated: 10/May/15

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

Type: Enhancement Priority: Minor
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-719] this-as behaves incorrectly in "scoping function" Created: 07/Dec/13  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-818] Externs don't get loaded when running under immutant as cljs.js-deps/find-js-classpath fails Created: 18/Jun/14  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-836] Replace seq-based iterators with direct iterators for all non-seq collections that use SeqIterator Created: 08/Aug/14  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-871] .-default property access returns nil Created: 11/Oct/14  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-968] Metadata on function literal inside of a let produces invalid Javascript Created: 07/Jan/15  Updated: 10/May/15

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

Type: Defect Priority: Major
Reporter: Bobby Eickhoff Assignee: David Nolen
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".

Comment by David Nolen [ 06/May/15 7:15 PM ]

Hrm, it appears analyze-wrap-meta may need to defer to a helper to change the :context of the given AST node.





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

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-349] cljs.compiler: No defmethod for emit-constant clojure.lang.LazySeq Created: 30/Jul/12  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-434] ClojureScript compiler prepends "self__" to defmulti forms when metadata in form of ^:field. Created: 01/Dec/12  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1128] Describe internationalization strategies via Google Closure on the wiki Created: 16/Mar/15  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1129] :modules tutorial for wiki Created: 16/Mar/15  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1136] Initial require fails to fully load added symbols Created: 17/Mar/15  Updated: 10/May/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
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-1238] Setting *main-cli-fn* when using :target :nodejs shouldn't be manditory Created: 01/May/15  Updated: 10/May/15

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

Type: Enhancement Priority: Minor
Reporter: Jeremy Shoemaker Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File nodejs-main-cli-fn.patch    
Patch: Code

 Description   

Currently, when you use :target :nodejs in the build options for ClojureScript, the resulting code requires you to set *main-cli-fn* to a function.

This prevents someone from writing a library that can be used by JavaScript developers because it forces code execution on require. It also makes writing a CLI tool that can be distributed using NPM less straightforward. I ran into this issue trying to create a Leiningen template for writing CLI tools that could be installed using npm install or npm link. I had a wrapper script to take care of the CLI use-case, and intended to write the ClojureScript module in a more library oriented way, but ran into issues. I could work around this by not using the wrapper script, but it got me thinking about the more general library issue.

I don't see any reason why you should be forced to set *main-cli-fn* and so I'm suggesting making it optional.

Attached is a patch that makes it optional but retains the check for whether the value it is set to is a function in the case where it is set.

This is my first time submitting a change to a project using a git patch and not a pull request, so let me know if I've made the patch wrong.



 Comments   
Comment by Jeremy Shoemaker [ 01/May/15 7:27 PM ]

I just noticed the priority defaulted to "Major". I don't know if I'd say it's major, so feel free to bump it down if that doesn't seem appropriate.





[CLJS-1234] local :foreign-libs support for REPLs Created: 01/May/15  Updated: 10/May/15  Resolved: 10/May/15

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

Type: Defect Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

It appears local (not upstream) :foreign-libs will not get picked up by REPLs.



 Comments   
Comment by David Nolen [ 09/May/15 11:17 AM ]

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

Comment by David Nolen [ 09/May/15 3:55 PM ]

The current behavior is is add with the support for Closure libraries that follow classpath conventions.

Comment by David Nolen [ 10/May/15 8:57 AM ]

There are no issues with master. :libs directories need to be on the classpath.





[CLJS-1260] >= 0.0-3265 cannot compile Closure style libraries that conform to the classpath Created: 09/May/15  Updated: 09/May/15  Resolved: 09/May/15

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

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


 Comments   
Comment by David Nolen [ 09/May/15 3:48 PM ]

fixed https://github.com/clojure/clojurescript/commit/4f8d24cf5f857bf114e09535cfbb0f5db17326a9





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

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

Type: Defect Priority: Major
Reporter: Daniel Skarda Assignee: David Nolen
Resolution: Completed 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!

Comment by David Nolen [ 09/May/15 1:47 PM ]

fixed https://github.com/clojure/clojurescript/commit/5858966764728393f86cdeca50a049e350c670eb





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

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

Type: Defect Priority: Major
Reporter: Michal Till Assignee: David Nolen
Resolution: Completed Votes: 4
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



 Comments   
Comment by David Nolen [ 09/May/15 12:46 PM ]

fixed https://github.com/clojure/clojurescript/commit/159fad2df02efd869842076fef22b51de3a6c085





[CLJS-1235] non-upstream :foreign-libs not copied to :output-dir Created: 01/May/15  Updated: 09/May/15  Resolved: 09/May/15

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

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


 Description   

When testing the following compiler option:

:foreign-libs [{:file "http://greggman.github.io/webgl-fundamentals/webgl/resources/webgl-utils.js"
                :provides ["gl-utils"]}

The file at the url does not get copied into :output-dir.



 Comments   
Comment by David Nolen [ 09/May/15 11:17 AM ]

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





[CLJS-1258] stack trace mapping does not appear to work with :asset-path Created: 08/May/15  Updated: 09/May/15  Resolved: 09/May/15

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

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


 Description   

The path to JS files just seems wrong.



 Comments   
Comment by David Nolen [ 09/May/15 8:36 AM ]

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





[CLJS-1259] Incorrect warnings on type hinted maths Created: 09/May/15  Updated: 09/May/15

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

Type: Defect Priority: Minor
Reporter: Erik Ouchterlony Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug, math, typehints


 Description   

Variables type hinted as int or double are not recognized as numbers, e.g.

(def ^int i 1)
(+ i i)
WARNING: cljs.core/+, all arguments must be numbers, got [int int] instead. at line 1 <cljs repl>
2





[CLJS-1257] find-doc regression Created: 08/May/15  Updated: 08/May/15  Resolved: 08/May/15

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

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


 Description   

find-doc no longer works



 Comments   
Comment by David Nolen [ 08/May/15 6:44 PM ]

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





[CLJS-1254] Update REPL browser agent detection Created: 07/May/15  Updated: 08/May/15  Resolved: 08/May/15

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

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


 Description   

See CLJS-1252 & CLJS-1253, the current agent detection used Closure labs features which have now been moved into the standard library.



 Comments   
Comment by David Nolen [ 08/May/15 6:54 AM ]

fixed https://github.com/clojure/clojurescript/commit/77d9434d2bfb78c233911c624d544265bb7666d5





[CLJS-1253] Create new Closure Library Release Created: 07/May/15  Updated: 08/May/15  Resolved: 08/May/15

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

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


 Comments   
Comment by David Nolen [ 08/May/15 6:54 AM ]

fixed https://github.com/clojure/clojurescript/commit/77d9434d2bfb78c233911c624d544265bb7666d5





[CLJS-1255] cljs.test file-and-line detection is not useful in browser testing Created: 07/May/15  Updated: 07/May/15

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

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

Chrome



 Description   

cljs.test reports using do-report, which adds file and line information computed from javascript stack traces. In chrome at least, these stack traces are not useful:

"Error
    at http://localhost:3449/js/cljs/test.js:261:69
    at cljs$test$do_report (http://localhost:3449/js/cljs/test.js:268:3)
    at http://localhost:3449/js/test/test_tests.js:491:21
    at test.test_tests.test_has_fails.cljs$lang$test (http://localhost:3449/js/test/test_tests.js:502:4)
    at http://localhost:3449/js/cljs/test.js:384:42
    at http://localhost:3449/js/cljs/test.js:387:4
    at cljs$test$run_block (http://localhost:3449/js/cljs/test.js:320:13)
    ..."

The `file-and-line` stack trace parser doesn't parse this correctly, resulting in a message like this:

FAIL in (test-function) (at http:384:42)

Note the lack of a useful file/namespace reference, and that the line number refers to the compiled javascript rather than the source clojurescript.



 Comments   
Comment by Stephen Nelson [ 07/May/15 9:15 PM ]

Prior to the release of cljs.test my company maintained an internal port of clojure.test that did better reporting than cljs.test's by adding source metadata from &form to the do-report calls generated by assert-expr. This approach was great for internal use but might not be suitable for cljs.test as it could reduce portability of assert-expr between clojure and clojurescript. Another approach could be dynamically bind source metadata in the body generated by try-expr. I'd be willing to implement and contribute code if you can provide some indication of your preferred approach.

Our version of assert-expr also injected a 'reporter function', {{(function(a,b,c){a.apply(b.c)})}}, which we would invoke from report, e.g. (reporter (.-debug js/console) js/console args). This causes the clickable link on the right hand side of chrome's console output to link to the source map location of the test expression, rather than the report function.





[CLJS-1252] Update Closure Compiler Dependency to v20150505 Created: 07/May/15  Updated: 07/May/15  Resolved: 07/May/15

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

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


 Comments   
Comment by David Nolen [ 07/May/15 4:12 PM ]

fixed https://github.com/clojure/clojurescript/commit/46ea0b9c2871532334c1007546191e1b4e60dc9f





[CLJS-1059] Simple interface wanted to convert cljs forms to js Created: 22/Feb/15  Updated: 07/May/15

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

Type: Enhancement Priority: Minor
Reporter: Stuart Mitchell Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: analyzer, compiler

Patch: Code

 Description   

In our project (a clojurescript debugger) we want to convert cljs forms or a sequence of forms into javascript so that they can be executed in the javascript console.

We would like something similar to closure/compile-form-seq (https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/closure.clj#L308)

However, we need to supply, the namespace requires and locals in an env like this

{:ns {:name "test.core" :requires {(quote gstring) (quote goog.string)}} :locals {}}

This code seems to do what we want.

(defn compile-form-seq
    \"Compile a sequence of forms to a JavaScript source string.\"
    [forms env]
    (env/ensure
    (compiler/with-core-cljs nil
      (fn []
        (with-out-str
            (doseq [form forms]
              (compiler/emit (analyzer/analyze env form))))))))

I am not sure why I need env/ensure.

Would you be able to patch compile-form-seq to provide the needed interface, or suggest what we should be doing.

Thanks
Stu



 Comments   
Comment by Mike Thompson [ 22/Feb/15 10:09 PM ]

Just to be clear:
1. when our debugger is at a breakpoint,
2. the user can type in an expression at the repl
3. in response, our debugger has to compile the user-typed-in expression to javascript (and then execute it, showing a result)
4. taking into account any local bindings. <---- this is the key bit.

To satisfy point 4, our tool extracts all the 'locals' from the current call-frame, and then supplies all these local bindings in env/locals, so the compiler doesn't stick a namespace on the front of them.

For example, if there was a local binding for 'x' in the callstack, and the user's repl-entered-expression involves 'x', then we want the compiler to leave the symbol 'x' alone and to not put some namespace on the front of it. In the final javascript, it must still be 'x', not 'some.namespace.x'

Our method to achieve this is to put 'x' into env/locals when compiling – and it all works. Except, with the recent changes this has become more of a challenge. Hence this ticket asking for a way to pass in env.

Comment by Thomas Heller [ 23/Feb/15 3:19 AM ]

You could wrap the user expression in an fn, that would allow you to skip messing with the locals. The REPL basically does the same trick for *1,*2,...

(fn [x]
  ~user-expression-here)
Comment by David Nolen [ 29/Apr/15 7:21 AM ]

Seems like something useful to add to a cljs.compiler.api namespace.





[CLJS-1250] uberjar script broken wrt cljc Created: 06/May/15  Updated: 07/May/15  Resolved: 07/May/15

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

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

Attachments: Text File CLJS-1250.patch     Text File CLJS-1250_v2.patch    

 Description   
$ script/uberjar
++ git --no-replace-objects describe --match v0.0
+ REVISION=v0.0-3242-gab68ddc
+ REVISION=3242-gab68ddc
+ REVISION=3242
++ mktemp /tmp/compiler.clj.XXXXXXXXXXX
+ COMP_FILE=/tmp/compiler.clj.S998xXGTrCX
+ sed -e 's/^.def ^:dynamic \*clojurescript-version\*.*$/(def ^:dynamic *clojurescript-version* {:major 0, :minor 0, :qualifier 3242})/' src/clj/cljs/util.clj
sed: src/clj/cljs/util.clj: No such file or directory


 Comments   
Comment by Mike Fikes [ 06/May/15 9:40 PM ]

Oops, didn't mean to mess with whitespace outside of the intended change. Attaching a revision that doesn't do that.

Comment by David Nolen [ 07/May/15 7:53 AM ]

fixed https://github.com/clojure/clojurescript/commit/74c7eb24c99955203eec61d8d065087292c3f201





[CLJS-1251] Missing semicolons when emitting deftype and defrecord Created: 07/May/15  Updated: 07/May/15

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

Type: Defect Priority: Trivial
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File cljs_1251.patch    

 Description   

Emitted code for deftype and defrecord has to separate the var assignment from body content by a semicolon (do not rely on automatic javascript semicolon insertion).

The bad case:
If body has the first statement wrapped in (...), javascript will treat it as a function call on the constructor definition.






[CLJS-710] port clojure.pprint Created: 02/Dec/13  Updated: 06/May/15  Resolved: 06/May/15

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

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

Attachments: Text File cljs-710.patch    

 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.

Comment by David Nolen [ 06/May/15 9:02 AM ]

See CLJS-1247

Comment by Shaun LeBron [ 06/May/15 12:50 PM ]

tests passing on v8. regex is producing a ton of google closure warnings at compile time.

going to ask for help on irc with getting cljc

Comment by David Nolen [ 06/May/15 1:56 PM ]

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





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

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

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


 Description   

Port relevant bits of CLJ-1671






[CLJS-1225] Variadic function with same name as parent function gives runtime error in advanced compile mode. Created: 27/Apr/15  Updated: 06/May/15  Resolved: 06/May/15

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

Type: Defect Priority: Major
Reporter: Dan Johansson Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

windows, chrome



 Description   

This code fails with: Uncaught TypeError: undefined is not a function, when using advanced compilation.
If I do not pass the variadic arguments it works.
If I rename one of the functions it works.

(defn- incme []
  (let [incme (fn [a queue & args] (inc a))]
    (println (incme 1 [1] :color "#fff"))))

(incme)

Tried this on both 2913 and 3211 with the same result.



 Comments   
Comment by David Nolen [ 27/Apr/15 7:52 AM ]

It appears that the variadic invoke is being considered as a local and inadvertently getting renamed. Will look into it. Thanks for the report.

Comment by David Nolen [ 06/May/15 7:50 AM ]

The issue only exists when *cljs-static-fns* is bound to true.

Comment by David Nolen [ 06/May/15 9:01 AM ]

fixed https://github.com/clojure/clojurescript/commit/717cab5ed3f9879cddab7e560919522e7698e873





[CLJS-1248] alter-meta! does not work on vars Created: 05/May/15  Updated: 05/May/15

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

Type: Defect Priority: Minor
Reporter: Leon Grapenthin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug


 Description   

(alter-meta! (var +) assoc :foo 42)
;-> {:foo 42} ;; wrong

(:foo (meta (var +)) :incorrect)
;-> :incorrect






[CLJS-1245] Implement bound-fn Created: 03/May/15  Updated: 05/May/15

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

Type: Enhancement Priority: Minor
Reporter: Brandon Bloom Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

See discussion on http://dev.clojure.org/jira/browse/CLJS-210






[CLJS-1233] excluding + * etc. does not work for libraries in JARs Created: 01/May/15  Updated: 05/May/15  Resolved: 05/May/15

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

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


 Comments   
Comment by David Nolen [ 05/May/15 7:24 AM ]

This behavior was observed when using Kovas Boguta's Gamma library.

Comment by David Nolen [ 05/May/15 7:44 AM ]

The bug is in Gamma itself.





[CLJS-1241] Add cljs.core/boolean? predicate Created: 03/May/15  Updated: 05/May/15

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

Type: Enhancement Priority: Minor
Reporter: Brandon Bloom Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: patch

Attachments: Text File CLJS-1241_v01.patch    
Patch: Code and Test

 Description   

I'm constantly re-implementing this predicate...

It's also important for clj/cljs compatibility.



 Comments   
Comment by Brandon Bloom [ 03/May/15 2:32 PM ]

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

Comment by Mike Fikes [ 03/May/15 2:52 PM ]

I tried this patch and it works correctly for me.

The docstring uses "typeof". Perhaps "type of" was intended?

cljs.user=> (doc boolean?)
-------------------------
cljs.core/boolean?
([x])
  Returns true if the typeof x is boolean, false otherwise.

nil
Comment by Brandon Bloom [ 03/May/15 7:41 PM ]

I did mean "typeof", which is a javascript-ism. A better doc string may be less javascript-specific...





[CLJS-1246] Add cljs.core/record? predicate Created: 03/May/15  Updated: 04/May/15  Resolved: 04/May/15

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

Type: Defect Priority: Major
Reporter: Brandon Bloom Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: patch

Attachments: Text File CLJS-1246_v01.patch    
Patch: Code and Test

 Description   

CLJ-394 added one for Clojure.

As is the case with all my recent predicate tickets, this is in the name of better cross-platform code.



 Comments   
Comment by David Nolen [ 04/May/15 6:51 AM ]

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





[CLJS-1244] tagged-literal precondition check missing wrapping vector Created: 03/May/15  Updated: 03/May/15  Resolved: 03/May/15

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

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

Attachments: Text File CLJS-1244_v01.patch    

 Description   
(tagged-literal "z" "y")

should trigger precondition check on first argument being a symbol.



 Comments   
Comment by David Nolen [ 03/May/15 7:28 PM ]

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

Comment by Brandon Bloom [ 03/May/15 7:36 PM ]

Ha! D'oh. I always make that mistake, which is why I made this patch:
http://dev.clojure.org/jira/browse/CLJ-1473

I guess I'll make a cljs version of that patch...

Thanks for the save, Mike.





[CLJS-1239] cljs.core/eduction is not variadic Created: 03/May/15  Updated: 03/May/15  Resolved: 03/May/15

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

Type: Defect Priority: Major
Reporter: Brandon Bloom Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: patch

Attachments: Text File CLJS-1239_v01.patch    
Patch: Code and Test

 Description   

But clojure.core/eduction is variadic.



 Comments   
Comment by David Nolen [ 03/May/15 7:30 PM ]

fixed https://github.com/clojure/clojurescript/commit/703561bff0f06636e1f604c74494c2b5b502f420





[CLJS-210] Implement Var form, var-get, and var? in CLJS Created: 27/Apr/12  Updated: 03/May/15  Resolved: 03/May/15

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

Type: Enhancement Priority: Minor
Reporter: Brandon Bloom Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: patch,

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

 Description   

See discussion of Vars in CLJS here: http://dev.clojure.org/display/design/Dynamic+Binding
My goal is to eventually implement dynamic scope capture, via bound-fn and friends. The attached patch is a step in that direction.

This patch adds support for parsing the (var foo) form. The #' reader macro is provided by JVM Clojure.

#'foo emits code to construct a Var object. In this patch, each invocation of 'var will create a unique Var object. This means they are '= by fully qualified symbol, but not 'identical?. Simple memoization would fix that, but I'm not going to bother until I get to Dynamic Var objects.

The main advantage of this level of Var support is for the interactive development convenience of being able to defer dereferencing top-levels. For example, (def fog (comp f #'g)) will pick up redefinitions of 'g, but not of 'f.



 Comments   
Comment by Brandon Bloom [ 28/Apr/12 10:07 PM ]

I found two issues with this patch:

1) I never used the IVar that I declared :-P

2) (apply #'+ (range 100)) throws "Invalid arity: 101" – this is related to http://dev.clojure.org/jira/browse/CLJS-211

I'll look into fixing both. However, we should discuss supporting variable arity protocol methods...

Comment by David Nolen [ 17/Jun/12 12:17 PM ]

any support for reified vars is a low priority for the foreseeable future.

Comment by Brandon Bloom [ 01/Sep/12 7:46 PM ]

Reified vars (and binding frames!) are a requirement for a CPS transform to be correct with respect to dynamic bindings.

Comment by Tom Jack [ 10/Sep/12 5:11 PM ]

+1 towards bound-fn and friends. I had an explanation written here but now I see "async Javascript (ie. nearly all Javascript) makes the binding macro effectively useless without bound-fn". Indeed.

Comment by Herwig Hochleitner [ 28/Oct/12 7:34 PM ]

bound-fn could also be implemented by setting / resetting bound vars before / after the wrapped fn, similar to binding. We would just need to add tracking of the currently rebound dynamic vars.
That should also be CPS - friendly, no?

Comment by Tom Jack [ 28/Oct/12 9:03 PM ]

I've considered that and would love to see it happen.

But what about:

(def ^:dynamic *foo* 3)
(set! *foo* 4)
(def f (bound-fn [] *foo*))
(set! *foo* 5)
(f)
Comment by Brandon Bloom [ 03/May/15 5:11 PM ]

Closing this ticket because a lot has changed in the last 3 years...

ClojureScript now has a Var type, with support for static-usage of the (var ...) form, and some of the related core functions.

Please see http://dev.clojure.org/jira/browse/CLJS-1245 for (totally as of now unplanned) work on bound-fn et al for dynamic vars.





[CLJS-1243] Add cljs.core.TaggedLiteral type & related fns Created: 03/May/15  Updated: 03/May/15  Resolved: 03/May/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3211, 0.0-3117
Fix Version/s: 0.0-3255

Type: Defect Priority: Major
Reporter: Brandon Bloom Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: patch

Attachments: Text File CLJS-1243_v01.patch    
Patch: Code and Test

 Description   

These are new in Clojure 1.7:

clojure.lang.TaggedLiteral
clojure.core/tagged-literal?
clojure.core/tagged-literal

This type (and it's record-like implementation) are super useful for generic handling of Edn, like I do in Fipp.



 Comments   
Comment by David Nolen [ 03/May/15 3:08 PM ]

fixed https://github.com/clojure/clojurescript/commit/99f4463354dbd9d73073865a999b0225823c41ec





[CLJS-1240] Add var? predicate Created: 03/May/15  Updated: 03/May/15  Resolved: 03/May/15

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

Type: Defect Priority: Major
Reporter: Brandon Bloom Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: patch

Attachments: Text File CLJS-1240_v01.patch    
Patch: Code and Test

 Description   

Now that ClojureScript has (static) vars, we need a var? predicate.



 Comments   
Comment by David Nolen [ 03/May/15 3:05 PM ]

fixed https://github.com/clojure/clojurescript/commit/795f08ea23eb740af04013162374e4d169654e27





[CLJS-625] apply constructor generates invalid JS Created: 18/Oct/13  Updated: 03/May/15  Resolved: 03/May/15

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

Type: Defect Priority: Trivial
Reporter: George Fraser Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None
Environment:

0.0-1913



 Description   

(apply js/String. "foo")

generates the javscript:

cljs.core.apply.call(null,String.,"foo")

which does not parse. This seems like a bad failure mode.



 Comments   
Comment by Antonin Hildebrand [ 03/May/15 4:42 AM ]

A note to myself: a possible javascript solution is outlined here:
http://stackoverflow.com/questions/1606797/use-of-apply-with-new-operator-is-this-possible

Comment by David Nolen [ 03/May/15 7:13 AM ]

This isn't valid Clojure(Script). Whether we should produce a warning of some kind is a separate issue.





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

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

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


 Comments   
Comment by David Nolen [ 01/May/15 11:00 AM ]

(-> #'first meta :arglists)

=>

(quote ([coll]))
Comment by David Nolen [ 01/May/15 2:45 PM ]

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





[CLJS-1232] bad arglists for doc, regression Created: 01/May/15  Updated: 01/May/15  Resolved: 01/May/15

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

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


 Description   

hash-map doesn't show anything. map only shows one arity, etc.



 Comments   
Comment by David Nolen [ 01/May/15 2:43 PM ]

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





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

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

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed 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.

Comment by David Nolen [ 01/May/15 9:07 AM ]

fixed https://github.com/clojure/clojurescript/commit/41207811f3e72748ddf51c21ab3b5359c287960c

Comment by Mike Fikes [ 01/May/15 10:11 AM ]

Confirmed fixed.





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

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

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


 Comments   
Comment by David Nolen [ 01/May/15 8:40 AM ]

this more or less in place in master, will require more specific feedback to flesh out.





[CLJS-1231] AMD Module Processing Created: 30/Apr/15  Updated: 30/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: GSoC

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





[CLJS-1092] CommonJS Module processing Created: 07/Mar/15  Updated: 30/Apr/15

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

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Maria Neise
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Given a CommonJS file we should able to produce an IJavaScript map with :requires, :provides, etc.






[CLJS-1230] ES 2015 Module Processing Created: 30/Apr/15  Updated: 30/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: None
Fix Version/s: GSoC

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





[CLJS-1047] externs checking for js/foo Created: 19/Feb/15  Updated: 30/Apr/15

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

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: Maria Neise
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Worth looking into validating `js/foo` forms again the known externs set. Can probably be done by leveraging the Closure JS Parser.



 Comments   
Comment by Michael Griffiths [ 22/Feb/15 12:03 PM ]

Would you consider making the results of parsing available to tooling (e.g. in cljs.env/*compiler*)? I would use this to add support for autocompletion of js/ forms to CIDER.

Comment by David Nolen [ 23/Feb/15 8:15 AM ]

Definitely open to the idea of exposing this information to other tooling when we get there.





[CLJS-1177] A compiler support for non-Closure transforms (JSX, etc) Created: 28/Mar/15  Updated: 30/Apr/15

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

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Maria Neise
Resolution: Unresolved Votes: 1
Labels: None


 Description   

There are now a variety of JS dialects, JSX, TypeScript etc. which need to be transformed first into regular JS before module processing. We should devise a standard way to deal with this. As we cannot predict what various dialects may arise in the future it's probably best to provide something like :preprocess-module option to cljs.closure/build.






[CLJS-1044] Investigate Closure CommonJS Support Created: 16/Feb/15  Updated: 30/Apr/15  Resolved: 30/Apr/15

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

Type: Task Priority: Major
Reporter: David Nolen Assignee: Maria Neise
Resolution: Completed Votes: 1
Labels: None


 Description   

It appears Google Closure has basic support for CommonJS modules. Apparently mixing CommonJS and Closure style libraries seems somewhat supported but this is not a necessary goal. For our purposes it may be satisfactory to simply allow CommonJS libs to be a part of the build, likely as a separate pass, in which require is compiled away.



 Comments   
Comment by David Nolen [ 30/Apr/15 6:46 PM ]

I went ahead and investigated this http://dev.clojure.org/jira/browse/CLJS-1229 is the resulting task.





[CLJS-1074] Externs inference Created: 02/Mar/15  Updated: 30/Apr/15

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

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


 Description   

Given all externs generally need to be supplied for js/foo we could probably automatically compute externs based on js/foo usage in user code. For this to work correctly we need to account for property access through js/foo i.e. (def Bar js/foo.Bar). This should infer that Bar is also a foreign object. Things gets more complicated for higher order cases, we probably want to support a ^js type hint.

Finally externs inference needs to account for externs likely already supplied by the user - i.e. don't emit dupes, Google Closure will complain.






[CLJS-1181] User Defined Tagged literal for integer causes all repls to hang Created: 01/Apr/15  Updated: 29/Apr/15  Resolved: 29/Apr/15

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

Type: Defect Priority: Minor
Reporter: Kuldeep Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

For a user define tagged literal brepl, rhino repl crash/hang on startup or form evaluation.

; CLJS
(register-tag-parser! 'my/int #(js/parseInt %))

; Clojure
(defn- print-int
  [^Integer i ^java.io.Writer w]
  (.write w (str "#my/int \"" i "\"")))

(defmethod print-method Integer
  [^Integer i ^java.io.Writer w]
  (print-int i w))

(defmethod print-dup Integer
  [^Integer i ^java.io.Writer w]
  (print-int i w))

(defn read-int
  [^String s]
  (Integer. s))

; resources data_readers.clj
; {my/int     myns/read-int}


 Comments   
Comment by David Nolen [ 01/Apr/15 5:57 AM ]

This ticket needs more information. Please include the stacktrace. Thanks.

Comment by Kuldeep [ 29/Apr/15 8:06 AM ]

Hello I would like to close this ticket as I think defining tagged literals for primitives was stupid idea in the first place. Please reopen if you think otherwise.





[CLJS-1190] definterface support Created: 03/Apr/15  Updated: 29/Apr/15

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

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


 Description   

A interop thing for JSDoc using JavaScript libraries, but also a potential Clojure interop thing. We can generate an empty object + methods that includes JSDoc @interface annotation.






[CLJS-1153] Typed Array backed PersistentVector based on clojure.core/Vec Created: 19/Mar/15  Updated: 29/Apr/15

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

Type: Enhancement Priority: Minor
Reporter: Adrian Medina Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: enhancement

Attachments: Text File 1153.patch    
Patch: Code

 Description   

Goal is to add support for vectors based on clojure.core/Vec, built on top of JavaScript Typed Arrays.

My hope is that this would allow for both efficient creation of vectors from existing Typed Arrays without intermediate conversion to normal JavaScript arrays, as well as efficient concatenation of the composite arrays of the vector back into a Typed Array when necessary via an enhanced cljs.core/into-array.

Implementation is based heavily on clojure/core/gvec.clj, cljs.core/PersistentVector, and cljs.core/TransientVector.

Performance should be comparable to cljs.core/PersistentVector, although there is additional constant overhead with TypedArray instantiation compared to js/Array.

Adds cljs.core/Vec, cljs.core/TransientVec, cljs.core/vector-of, and updates cljs.core/into-array.



 Comments   
Comment by Adrian Medina [ 19/Mar/15 8:39 PM ]

I still have to test, I will update the issue when that is complete. I just wanted to get my first patch up for review as quickly as possible.

Comment by Francis Avila [ 19/Mar/15 11:59 PM ]

No mention of Uint8ClampedArray.

Should Vec type- or range-check assignments? In Clojure these fail (even with unchecked-math):

  • (vector-of :byte 128) returns [-128]
  • (vector-of :byte "1") returns [1]
  • (vector-of :byte (js-obj)) returns [0]

If we're going to expose host primitive arrays via cljs apis, should we also bring the various other array functions in line with Clojure (and ClojureCLR, which also has extra uint, ubyte, etc types) like you are doing with into-array? Some or all of these issues may warrant another ticket instead, or maybe even a design page:

  • make-array ignores type argument and lacks higher dimensions.
  • object-array, int-array, etc. maybe should return TypedArrays.
  • Missing ubyte-array, ushort-array, uint-array (like ClojureCLR)
  • Missing aset-* setters. (Meaningless in js unless we range-check.)
  • aclone and amap preserve type of input array in Clojure, but not in cljs.
  • missing array casters: bytes, shorts, chars, ints, etc.
  • While we're at it, primitive coercion functions (e.g. int, long, unchecked-int, etc) are either no-ops or differ from clojure. (e.g., int in cljs is like unchecked-int in clojure, but unchecked-int in cljs does nothing). Maybe these should be dropped or should match the javascript ToInt32, ToInt16, etc abstract operations (i.e. those used when assigning to TypedArrays). Maybe these match java semantics also?




[CLJS-1091] Compose JavaScript dependency indexes Created: 07/Mar/15  Updated: 29/Apr/15

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

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


 Description   

Currently hard coded to Google Closure deps.js and the one produced for a build. Users should be able to supply JS dependency indexes that can get merged in.






[CLJS-1060] simplify nREPL integration Created: 23/Feb/15  Updated: 29/Apr/15  Resolved: 29/Apr/15

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   

-setup and -teardown need to be elidable. If cljs.env/*compiler* already bound use that. The eval of (ns cljs.user ...) form for auto-import of cljs.repl helpers needs to respect *cljs-ns* and restore it afterwards.



 Comments   
Comment by David Nolen [ 29/Apr/15 7:17 AM ]

this has been addressed in master





[CLJS-992] satisfies? does not work with locally bound symbols Created: 28/Jan/15  Updated: 29/Apr/15  Resolved: 29/Apr/15

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

Type: Defect Priority: Minor
Reporter: Richard Davies Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None
Environment:

[org.clojure/clojurescript "0.0-2727"]



 Description   
(ns sample)
(defprotocol ICustomer (doit [_]))
(defrecord Customer [fname])
(extend-type Customer
  ICustomer
    (doit [_] nil))
(let [t ICustomer]
  (js/alert (satisfies? t (Customer. nil))))

;satisfies? returns false but similar code in returns true.


 Comments   
Comment by David Nolen [ 29/Apr/15 7:13 AM ]

For now this is intentional. satisfies? only works directly on a protocol.





[CLJS-924] Better error message for mistaken use of 'def' Created: 24/Dec/14  Updated: 29/Apr/15

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

Type: Enhancement Priority: Trivial
Reporter: Alex Dowad Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-Better-error-message-if-def-is-mistakenly-substitute.patch    
Patch: Code

 Description   

ClojureScript shares what is IMHO one of the biggest weaknesses of the current JVM Clojure implementation: those (in)famous stack traces going down into the innards of the compiler if you get your syntax wrong. An easy mistake for noobs is to use 'def' in place of 'defn'; this patch makes that mistake a lot less painful to debug.

Feedback please!






[CLJS-886] Add a contains-key? function to the ITransientAssociative protocol Created: 14/Nov/14  Updated: 29/Apr/15  Resolved: 29/Apr/15

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

Type: Enhancement Priority: Minor
Reporter: Alejandro Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

I propose to add a contains-key? function to the ITransientAssociative protocol equivalent to the function with the same name in IAssociative.



 Comments   
Comment by David Nolen [ 17/Nov/14 7:49 AM ]

This is a departure from the interface design in Clojure. I recommend starting a discussion on clojure-dev.

Comment by David Nolen [ 29/Apr/15 7:11 AM ]

New functionality not supported by Clojure.





[CLJS-653] all core fns backed by a protocol should have inlining versions Created: 01/Nov/13  Updated: 29/Apr/15  Resolved: 29/Apr/15

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

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

first should be a compiler macro that checks &env to see if it's argument is ^not-native, if ^not-native it should inline into -first.



 Comments   
Comment by David Nolen [ 29/Apr/15 7:10 AM ]

Not going to pursue this for now.





[CLJS-1050] Warn on code that will obviously prevent dead code elimination or cross module code motion Created: 20/Feb/15  Updated: 29/Apr/15  Resolved: 29/Apr/15

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

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

Might make sense to support a module level flag like *warn-on-reflection*, perhaps *warn-on-deoptimization*? Simple cases of this are top-level data structures and and top-level side effects.



 Comments   
Comment by David Nolen [ 29/Apr/15 7:09 AM ]

Not going to do this for now.





[CLJS-1121] QuickStart a little unclear for browser REPL Created: 13/Mar/15  Updated: 29/Apr/15  Resolved: 29/Apr/15

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

Type: Defect Priority: Minor
Reporter: Brent Vukmer Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None
Environment:

Yosemite (10.10.2), Google Chrome


Attachments: File core.cljs     File repl.clj    

 Description   

I'm at the point in the QuickStart where it says "Point your web browser at http://localhost:9000. You should get a REPL."

I don't see the browser REPL when I go to http://localhost:9000, just a blank page. I'm attaching my repl.clj and core.cljs.



 Comments   
Comment by Brent Vukmer [ 14/Mar/15 9:08 AM ]

If "We also need to modify our script to load the browser REPL" refers to core.cljs, it would be clearer to say so.

Comment by David Nolen [ 29/Apr/15 7:06 AM ]

Cannot reproduce this.





[CLJS-1165] Support for multiple source directories in cljs.closure/build and watch Created: 24/Mar/15  Updated: 29/Apr/15  Resolved: 29/Apr/15

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

Type: Defect Priority: Minor
Reporter: Daniel Skarda Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None


 Description   

Quick-Start wiki page describes build and watch as functions with source (directory) as first argument

However more complex projects have multiple source paths (eg "src/cljs", "test/cljs" or cljx output "target/generated/cljs" and in future also "src/cljc").

Maybe I am missing some important point of a puzzle but I do not see a way how to (for example) build or watch multiple directories. Should we extend these function to support vectors of directories?



 Comments   
Comment by David Nolen [ 29/Apr/15 7:05 AM ]

CLJS-1203





[CLJS-1178] Compiler does not know Math ns is not not-native Created: 29/Mar/15  Updated: 29/Apr/15  Resolved: 29/Apr/15

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

Type: Defect Priority: Minor
Reporter: Francis Avila Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: compiler

Attachments: Text File cljs-1178.patch    
Patch: Code

 Description   

With static-fns true, compiler will emit invocations of functions in the Math "namespace" with a conditional arity check or .call() because it does not know that the Math namespace is not not-native. Example with the fix function (advanced compilation, pseudo-names true):

function $cljs$core$fix$$($q$$28$$) {
  return 0 <= $q$$28$$ ? Math.floor.$cljs$core$IFn$_invoke$arity$1$ ? Math.floor.$cljs$core$IFn$_invoke$arity$1$($q$$28$$) : Math.floor.call(null, $q$$28$$) : Math.ceil.$cljs$core$IFn$_invoke$arity$1$ ? Math.ceil.$cljs$core$IFn$_invoke$arity$1$($q$$28$$) : Math.ceil.call(null, $q$$28$$);
}

With attached patch, the following is emitted instead:

function $cljs$core$fix$$($q$$28$$) {
  return 0 <= $q$$28$$ ? Math.floor($q$$28$$) : Math.ceil($q$$28$$);
}


 Comments   
Comment by David Nolen [ 29/Apr/15 7:04 AM ]

fixed https://github.com/clojure/clojurescript/commit/4c50d43592074a72a84ca35eceaf5e43334da49e





[CLJS-1167]  Using (require 'namespace.core :reload) causes "too much recursion" - one process only. Created: 24/Mar/15  Updated: 29/Apr/15  Resolved: 29/Apr/15

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

Type: Defect Priority: Minor
Reporter: J David Eisenberg Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None
Environment:

Linux Fedora 21, openjdk version "1.8.0_31"


Attachments: File m060.tgz    

 Description   

At shell prompt, using "mies" from github: lein new mies m060
In core.cljs uncomment: (repl/connect "http://localhost:9000/repl")
In core.cljs add (defn doubled [x] (* 2 x))
At shell prompt: scripts/build # finishes successfully
At shell prompt: scripts/brepl

This will generate two warnings about goog.next.xpc.TransportNames and goog.net.xpc.CfgFields

In browser, connect to localhost:9000

In REPL: (require 'm060.core)
In REPL: (in-ns 'm060.core)
In REPL: (doubled 10) ;; this works correctly

In core.cljs, add: (defn tripled [x] (* 3 x))
in REPL: (require 'm060.core :reload)

browser shows "too much recursion" error twice (in Firefox)
in REPL: (tripled 10) ;; also works correctly

in core.cljs, add: (defn quad [x] (* 4 x))

in REPL: (require 'm060.core :reload)
Internal error: Too much recursion
Many repetitions of clojure$browser$repl$bootstrapgoog.require (out/clojure/browser/repl.cljs:158:33)


Note: this error can be avoided by replacing the (repl/connect "http://localhost:9000/repl") by
(defonce conn (repl/connect "http://localhost:9000/repl")) ;; as in quick start guide



 Comments   
Comment by David Nolen [ 29/Apr/15 6:59 AM ]

You must defonce the REPL connection if you want to reload that namespace. This is covered in the Quick Start.





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

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

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


 Comments   
Comment by David Nolen [ 29/Apr/15 6:55 AM ]

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





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

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

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


 Comments   
Comment by David Nolen [ 29/Apr/15 6:54 AM ]

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





[CLJS-1224] cljs.repl: Memoize stack frame mapping Created: 26/Apr/15  Updated: 29/Apr/15  Resolved: 29/Apr/15

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

Type: Enhancement Priority: Major
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: performance
Environment:

OS X QuickStart browser REPL against Safari


Attachments: Text File CLJS-1224.patch    

 Description   

When evaluating an expression that results in a stack overflow, and the resulting trace is source mapped by cljs.repl, this can result in thousands of frames being mapped which can take a few minutes. But, oftentimes stack overflow is the result of recursion, so many of the mapped frames are identical. This is trivial to optimize using memoize, resulting in the mapping occurring in a couple of seconds.

A test case, when using the Quick Start browser REPL against Safari, involves evaluating these 3 forms,

(defn next-results
  "Placeholder for function which computes some intermediate
  collection of results."
  [n]
  (range 1 n))

(defn build-result [n]
  (loop [counter 1
         results []]
    (if (< counter n)
      (recur (inc counter)
             (concat results (next-results counter)))
      results)))

(first (build-result 7000))

Note: The browser REPL sometimes fails to display a stack trace at times, showing an EOF error that is probably unrelated. When it does display the trace, though, you can see the performance effects. I found that you can get it to do this by starting with maybe 4000 in the call above, and increasing by 1000 until it overflows the stack.

Will attach a patch for consideration.



 Comments   
Comment by David Nolen [ 29/Apr/15 6:52 AM ]

fixed https://github.com/clojure/clojurescript/commit/4773730eda0a5c5d55cbb90adef54bc4bbe6b35e





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

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

Type: Defect Priority: Minor
Reporter: Ryan Berdeen Assignee: David Nolen
Resolution: Completed 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)

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

fixed as of e3ba4f4





[CLJS-1227] Raise error when if form has more than 4 statements Created: 28/Apr/15  Updated: 28/Apr/15

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

Type: Enhancement Priority: Minor
Reporter: Nikita Prokopov Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File cljs-1227-raise-error-when-if-has-more-than-4-statements.patch    
Patch: Code

 Description   

This is a trivial change, but might be very helpful. I've been struck by this a lot: form mistakenly put inside if form after then and else is silently ignored. Solution: raise an error when if contains more than 4 elements.






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

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3255
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.

Comment by Sebastian Bensusan [ 27/Apr/15 6:14 PM ]

This happens when ClojureScript is used with Java version < Java 7. The Regex ?U was added in Java 7.

Comment by David Nolen [ 28/Apr/15 6:52 AM ]

Right, but it's the case ClojureScript only works for Java >= 7 anyway due to the dependency on Closure Compiler.





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

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

Type: Enhancement Priority: Trivial
Reporter: Andrew Rosa Assignee: Andrew Rosa
Resolution: Declined 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.



 Comments   
Comment by David Nolen [ 26/Apr/15 6:22 AM ]

All current samples are now deprecated. If someone wants to modernize them they can submit a patch.





[CLJS-186] ClojureScript wiki/The-REPL-and-Evaluation-Environments - small issues Created: 19/Apr/12  Updated: 26/Apr/15  Resolved: 26/Apr/15

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

Type: Defect Priority: Minor
Reporter: Mike Lamb Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: documentation, wiki


 Description   

I just worked through the "The REPL and Evaluation Environments" wiki page and had to make the following change to get the example to work.

— The-REPL-and-Evaluation-Environments.md.0 2012-04-19 17:40:23.000000000 -0400
+++ The-REPL-and-Evaluation-Environments.md 2012-04-19 17:40:48.000000000 -0400
@@ -57,6 +57,7 @@
<body>
<div id="content">
<script type="text/javascript" src="out/goog/base.js"></script>
+ <script type="text/javascript" src="out/goog/deps.js"></script>
<script type="text/javascript" src="foo.js"></script>
<script type="text/javascript">
goog.require('foo');

Something else I noticed was that I didn't get the "Starting server on port 9000" message.



 Comments   
Comment by Brian Taylor [ 30/May/12 4:26 PM ]

In my environment, the deps.js script tag is appended to the page automatically as a side-effect of loading base.js.

base.js (line 613 in my release)

// Allow projects to manage the deps files themselves.
  if (!goog.global.CLOSURE_NO_DEPS) {
    goog.importScript_(goog.basePath + 'deps.js');
  }
Comment by David Nolen [ 26/Apr/15 6:18 AM ]

As far as I know this is now up-to-date.





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

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

Type: Task Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Completed 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.



 Comments   
Comment by David Nolen [ 26/Apr/15 6:11 AM ]

Added under Reference section under Common Problems.





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

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

Type: Defect Priority: Minor
Reporter: Stephen Nelson Assignee: Unassigned
Resolution: Completed 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.



 Comments   
Comment by David Nolen [ 26/Apr/15 6:07 AM ]

fixed https://github.com/clojure/clojurescript/commit/9a68234c0b1d45639bdfde040f582976eabe5523





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

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

Type: Defect Priority: Trivial
Reporter: Timothy Pratley Assignee: Timothy Pratley
Resolution: Completed 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

Comment by David Nolen [ 26/Apr/15 5:42 AM ]

Looking into this some more, is there some documentation somewhere that states that :output-file is a valid option to bin/cljsc.

Comment by David Nolen [ 26/Apr/15 5:56 AM ]

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





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

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

Type: Defect Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Declined 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.

Comment by David Nolen [ 26/Apr/15 5:22 AM ]

There's not a way to determine this in Clojure either.





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

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