<< Back to previous view

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

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

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


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

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



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

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





[CLJS-1210] Javascript built-in arguments replaces nil arguments locally defined by let Created: 16/Apr/15  Updated: 17/Apr/15

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

Type: Defect Priority: Minor
Reporter: Darrick Wiebe Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

NodeJs 0.12.2 on OSX. Using lein cljsbuild project generated with mies template



 Description   

I encountered this using cljs.tools.cli/parse-opts which returns a map that may contain an arguments key. It is easy to work around by avoiding destructuring, but could lead to some very confusing bugs.

(deftest arguments-error
  (let [{:keys [arguments]} {}
        arguments (or arguments [])]
    (is (= [] arguments))))





[CLJS-1211] Automatically requiring :main namespace under :none fails in IE9 Created: 17/Apr/15  Updated: 17/Apr/15

Status: Open
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3058, 0.0-3115, 0.0-3196, 0.0-3117, 0.0-3119, 0.0-3123, 0.0-3126
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Immo Heikkinen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Internet Explorer 9



 Description   

Automatic goog/base.js inclusion using :none & :main doesn't work in Internet Explorer 9. The following error message is printed to the console:

ClojureScript could not load :main, did you forget to specify :asset-path?

There seems to be a timing issue after writing script tags to the HTML document. Inline JavaScript for requiring the main namespace gets executed while goog is still undefined.

I played a bit with this but couldn't get it working in IE9. I tried moving the require statement to a separate JS file and adding a script tag to load that file, then goog was no longer undefined but I still got an error message:

SCRIPT5022: Undefined nameToPath for goog.string
base.js, line 753 character 9

The feature seems to work fine in other browsers (also IE10). Probably not worth fixing but at least the limitation is documented now in case someone else wonders the why it doesn't work in IE9.






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

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

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


 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?





[CLJS-1208] local deps.cljs should take precedence over upstream libs when containing the same :provides Created: 15/Apr/15  Updated: 16/Apr/15  Resolved: 16/Apr/15

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

Type: Defect Priority: Minor
Reporter: Kevin Webster Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None

Attachments: Text File rabidpraxis-reversed-deps.patch    
Patch: Code

 Description   

Creating a deps.cljs in attempt to override :foreign-libs from an upstream dependency (ex. cljsjs) does not work when the :provides are the same.

https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/closure.clj#L1251

It looks as though getResources returns a sequence of deps.cljs where the upstream versions are ordered at the end of the seq. Because of this, when this gets built into the index, the upstream version always takes precedence.

Reversing the sequence seems to fix the problem.



 Comments   
Comment by David Nolen [ 16/Apr/15 1:53 PM ]

This is not how overriding works, overriding is done by supplying overrides via compiler options.





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

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

Type: Defect Priority: Major
Reporter: Karsten Schmidt Assignee: Unassigned
Resolution: Unresolved 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])





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

Status: Open
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: Unresolved 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     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.





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

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

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


 Description   

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






[CLJS-1205] Support conditional reading in REPLs Created: 14/Apr/15  Updated: 14/Apr/15  Resolved: 14/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   

Same as CLJ-1700



 Comments   
Comment by David Nolen [ 14/Apr/15 6:33 PM ]

fixed https://github.com/clojure/clojurescript/commit/78c882f1f61023c0b0a75b87bd8e8bcb7058ed04





[CLJS-1204] cljs.closure/watch cannot take cljs.closure/Compilable Created: 14/Apr/15  Updated: 14/Apr/15  Resolved: 14/Apr/15

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

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


 Description   

Blocker for exporting an official cljs.build.api/watch.



 Comments   
Comment by David Nolen [ 14/Apr/15 6:10 PM ]

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





[CLJS-1203] official way to supply multiple files/directories to cljs.closure/build and cljs.closure/watch Created: 14/Apr/15  Updated: 14/Apr/15  Resolved: 14/Apr/15

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

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


 Comments   
Comment by David Nolen [ 14/Apr/15 9:02 AM ]

https://github.com/clojure/clojurescript/commit/5353489fe3beda9a6e9d044e89da3bd0d2accce7





[CLJS-1201] compare-indexed: improper handling of empty indexed collections Created: 14/Apr/15  Updated: 14/Apr/15  Resolved: 14/Apr/15

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

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

Attachments: Text File cljs-1201-empty-vectors-throw-on-compare.patch    

 Description   
(compare (into [] '()) [])
(compare (vec #js[]) [])
(compare (with-meta [] {}) [])
(compare (pop [1]) [])
(compare (subvec [1] 0 0) (subvec [1] 0 0))

all throw #<Error: No item 0 in vector of length 0>

(compare [] []) only passes because they're considered identical?
(-compare [] []) throws too



 Comments   
Comment by David Nolen [ 14/Apr/15 7:18 AM ]

This is a dupe of CLJS-1200. Prefer a patch that simply covers all cases not individual problems.

Comment by Nikita Prokopov [ 14/Apr/15 7:33 AM ]

No, it is not a dupe. CLJS-1200 is a conceptual thing: should compare compare objects of different types? It’s a language-level decision. E.g. Clojure’s compare does not. We can discuss it for months.

This one is an actual bug in compare-indexed. A zero-index access inside empty collection. Missed codepath, real exception.

Please fix this one as it affects our production code.

Comment by David Nolen [ 14/Apr/15 7:55 AM ]

Nikita, accurate ticket titles help when assessing the intent of patches. I understand the issue now.

Comment by David Nolen [ 14/Apr/15 7:59 AM ]

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

Comment by Nikita Prokopov [ 14/Apr/15 8:00 AM ]

Oh, you probably thought that I’m comparing PersistentVector to Subvec. Sorry, didn’t want to confuse you





[CLJS-1202] load-file is not additive, unmaps the namespace Created: 14/Apr/15  Updated: 14/Apr/15  Resolved: 14/Apr/15

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

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


 Comments   
Comment by David Nolen [ 14/Apr/15 7:23 AM ]

fixed https://github.com/clojure/clojurescript/commit/53780c6e0aaf68e8c687ebb666cf2d4092ba136f





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

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

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





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

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

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


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

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






[CLJS-1199] array-map can reuse skipped elements of IndexedSeq Created: 13/Apr/15  Updated: 13/Apr/15  Resolved: 13/Apr/15

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

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

Attachments: Text File cljs-1199.patch    

 Description   
(let [x (drop 1 [0 :a 1 :b 2])]
  (apply array-map x))

Expected:

{:a 1, :b 2}

Got:

{0 :a, 1 :b, 2 nil}

Broken by this commit: https://github.com/clojure/clojurescript/commit/815dde62ef06e591444d5deec8f2425890f57a1f

(defn array-map
  "keyval => key val
  Returns a new array map with supplied mappings."
  [& keyvals]
  (let [arr (if (instance? IndexedSeq keyvals)
              (.-arr keyvals)
              (into-array keyvals))]
    (.fromArray cljs.core/PersistentArrayMap arr true false)))

This code should also check for (zero? (.-i keyvals))



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

fixed https://github.com/clojure/clojurescript/commit/0c0602ac25a4092e0d3fbc53b5a7ff0479307307





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

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

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

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



 Description   

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

My setup is:

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

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

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






[CLJS-1197] load-file does not reload associated macro namespace Created: 12/Apr/15  Updated: 12/Apr/15  Resolved: 12/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: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

In the case of a ns with a accompanying macros ns of the same name we should reload the macro namespace when using load-file.



 Comments   
Comment by David Nolen [ 12/Apr/15 5:51 PM ]

fixed https://github.com/clojure/clojurescript/commit/3cf142cdfe83b7ce59fcbbe5e0e721f3176123df





[CLJS-1113] Compile in dependency order Created: 12/Mar/15  Updated: 12/Apr/15  Resolved: 12/Apr/15

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

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


 Description   

Because we do not compile in dependency order we do a lot of needless analysis.



 Comments   
Comment by David Nolen [ 14/Mar/15 6:13 AM ]

With the latest changes to master this will only improve the performance of the first compile.

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

as of https://github.com/clojure/clojurescript/commit/e89950e1962d4aece70262dacc7fab6428fb5625, we always compile everything in dependency order. There is a separate further step which is to compile everything at once in order.





[CLJS-1193] recompile dependents fails to work when not auto-building Created: 10/Apr/15  Updated: 10/Apr/15  Resolved: 10/Apr/15

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

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


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

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





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

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

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

Linux 64bit

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


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

 Description   

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

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

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

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

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



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

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

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

I did bind out to err. Check the patch.

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

Crispin, oops sorry you are correct. Thanks.

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

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

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

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

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

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

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

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





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

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

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


 Description   

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

Example:

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

Whereas foo.getBarRight expands to something like

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

foo.getBarWrong on the other hand expands to

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





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

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

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

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

 Description   

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



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

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

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

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

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

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





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

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

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


 Description   

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






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

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

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

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



 Description   

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

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

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

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



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

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

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

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

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

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

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

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

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

to be true and emit a "return".





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

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

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





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

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

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


 Description   

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



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

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





[CLJS-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/Apr/15

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

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


 Description   

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






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

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

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





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

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

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


 Description   

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






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

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

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

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

 Description   

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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





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

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

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





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

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

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


 Description   

Problem for using boolean Closure defines



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

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





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

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

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

cljs 0.0-3115


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

 Description   

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

(Slightly friendlier version of the test case.)





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

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

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

Quick Start Browser REPL with :watch off



 Description   

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

Then further down, where the new symbol is introduced

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

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

(def a 1)
(def a 1)

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

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

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





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

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

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

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

 Description   

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

Expected:
a file called foo.js

Actual:
Compiler throws an internal error

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



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

Fixes handling of compiling one IJavaScript or many

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

Patch is attached, updating ticket to reflect that

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

Can we get a patch rebased to master? Thanks.

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

updated for latest master





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

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

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


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

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

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

I'm ceasing development on the port.

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

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

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

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

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

k, resuming.





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

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

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


 Description   

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






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

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

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

r2173



 Description   

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

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



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

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

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

Bump, this enhancements sound simple & fine.

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

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

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

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

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

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

Be my guest





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

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

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

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

 Description   

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

(deftype Foo [default])

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


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

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

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

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

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

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

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

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

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

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

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

Updated to use new refactorings

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

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





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

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

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


 Description   

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






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

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

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

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

 Description   

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



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

A patch that caches upstream dependencies in the compiler env.

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

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

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

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

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

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

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

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

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

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

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

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

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

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





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

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

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

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



 Description   

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

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

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

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

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

What I found:

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

But:

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

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

Hope you have all information to fix the problem.

Thank you.



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

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





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

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

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





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

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

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





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

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

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

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



 Description   

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

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

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

(ns test-def)

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

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

https://gist.github.com/4185793



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

code tags

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

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





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

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

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

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

 Description   

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

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

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



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

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

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

http://clojure.org/contributing





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

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

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

Attachments: File CLJS-620.diff    

 Description   

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

Find a reproduction project here.



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

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

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

For reference, Clojure generates the following error message:

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

The "obvious" approach would be to add

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

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

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

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

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

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

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

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

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





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

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

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


 Description   

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

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


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

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

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

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





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

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

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


 Description   

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

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

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

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

Thanks



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

A patch is welcome for this. Thanks.





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

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

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

Quick Start Browser REPL (OS X / Safari)



 Description   

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

To reproduce:

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

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

But:

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

Now, if you :reload

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


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

Prior to step 8:

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

Between steps 9 and 10:

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

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

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

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





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

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

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


 Description   

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






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

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

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

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

 Description   

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

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

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






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

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

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

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


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

 Description   

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



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

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

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

Patch welcome for this.

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

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

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

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

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

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

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

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

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

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

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

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

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





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

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

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


 Description   

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

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



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

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

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

Maybe this option should make it into core.

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

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

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

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

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

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





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

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

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


 Description   

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






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

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

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


 Description   

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






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

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

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

Quick start guide with Node REPL



 Description   

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

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

ClojureScript REPLs do not behave in the same way:

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





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

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

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


 Description   

Port relevant bits of CLJ-1671






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

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

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





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

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

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


 Description   

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



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

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





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

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

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

Linux, lein-cljsbuild



 Description   

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

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



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

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

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

Do you have a suggested fix for this?





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

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

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


 Description   

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






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

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

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


 Description   

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






[CLJS-1189] array-map will return PersistentHashMap if applied to more than (.-HASHMAP-THRESHOLD PersistentArrayMap) pairs Created: 03/Apr/15  Updated: 10/Apr/15  Resolved: 03/Apr/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: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

cljs.user=> (type (apply array-map [1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0]))
cljs.core/PersistentArrayMap
cljs.user=> (type (apply array-map [1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 10 0]))
cljs.core/PersistentHashMap



 Comments   
Comment by David Nolen [ 03/Apr/15 5:22 PM ]

fixed https://github.com/clojure/clojurescript/commit/815dde62ef06e591444d5deec8f2425890f57a1f

Comment by Mike Fikes [ 03/Apr/15 5:30 PM ]

Confirmed fixed.

Comment by Michał Marczyk [ 10/Apr/15 7:31 PM ]

array-map actually should always return array maps – it does so in Clojure and this is documented as desired behaviour in the docstring (which promises to return an array map) and on the Data Structures page on clojure.org:

http://clojure.org/data_structures

ArrayMaps
When doing code form manipulation it is often desirable to have a map which maintains key order. An array map is such a map - it is simply implemented as an array of key val key val... As such, it has linear lookup performance, and is only suitable for very small maps. It implements the full map interface. New ArrayMaps can be created with the array-map function. Note that an array map will only maintain sort order when un-'modified'. Subsequent assoc-ing will eventually cause it to 'become' a hash-map.

Clojure keeps the above promise:

Clojure 1.7.0-beta1
user=> (class (apply array-map (range 1000)))
clojure.lang.PersistentArrayMap

See also CLJS-873 (with my patch to make non-higher-order calls to array-map return array maps) and CLJS-872 (tangentially related).





[CLJS-1158] Regression: compiler fails to see symbols defined in another namespace Created: 23/Mar/15  Updated: 09/Apr/15  Resolved: 07/Apr/15

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

Type: Defect Priority: Major
Reporter: Nikita Prokopov Assignee: David Nolen
Resolution: Completed Votes: 1
Labels: None

Attachments: Zip Archive cljs-1158.zip    

 Description   

Regression happened between 0.0-2985 and 0.0-3030.

E.g. I have this setup:

(ns datascript
  (:require [datascript.core :as dc]))

(def filter dc/filter)
(ns datascript.js
  (:require
    [datascript :as d]))

d/filter

This is the output of compiler for 0.0-2985:

Compiling ClojureScript.
Compiling "target/datascript.js" from ["src" "test"]...
Analyzing jar:file:/Users/prokopov/.m2/repository/org/clojure/clojurescript/0.0-2985/clojurescript-0.0-2985.jar!/cljs/core.cljs
Compiling src/datascript/btset.cljs
Compiling src/datascript/core.cljs
Compiling src/datascript/debug.cljs
Compiling src/datascript/impl/entity.cljs
Compiling src/datascript/js.cljs
Analyzing file:/Users/prokopov/Dropbox/ws/datascript/src/datascript.cljs
WARNING: datascript is a single segment namespace at line 1 /Users/prokopov/Dropbox/ws/datascript/src/datascript.cljs
Analyzing file:/Users/prokopov/Dropbox/ws/datascript/src/datascript/query.cljs
Analyzing file:/Users/prokopov/Dropbox/ws/datascript/src/datascript/parser.cljs
Analyzing jar:file:/Users/prokopov/.m2/repository/org/clojure/clojurescript/0.0-2985/clojurescript-0.0-2985.jar!/clojure/set.cljs
Analyzing file:/Users/prokopov/Dropbox/ws/datascript/src/datascript/pull_parser.cljs
Analyzing file:/Users/prokopov/Dropbox/ws/datascript/src/datascript/pull_api.cljs
Analyzing jar:file:/Users/prokopov/.m2/repository/org/clojure/clojurescript/0.0-2985/clojurescript-0.0-2985.jar!/cljs/reader.cljs
Analyzing jar:file:/Users/prokopov/.m2/repository/org/clojure/clojurescript/0.0-2985/clojurescript-0.0-2985.jar!/clojure/walk.cljs
Compiling src/datascript/parser.cljs
...

Note that

Compiling src/datascript/js.cljs
triggers
Analyzing file:/Users/prokopov/Dropbox/ws/datascript/src/datascript.cljs

And on 0.0-3030 and later versions I get this:

Compiling ClojureScript.
Retrieving org/clojure/clojurescript/0.0-3030/clojurescript-0.0-3030.pom from central
Retrieving org/clojure/clojurescript/0.0-3030/clojurescript-0.0-3030.jar from central
Compiling "target/datascript.js" from ["src" "test"]...
Reading analysis cache for jar:file:/Users/prokopov/.m2/repository/org/clojure/clojurescript/0.0-3030/clojurescript-0.0-3030.jar!/cljs/core.cljs
Compiling src/datascript/btset.cljs
Compiling src/datascript/core.cljs
Compiling src/datascript/debug.cljs
Compiling src/datascript/impl/entity.cljs
Compiling src/datascript/js.cljs
WARNING: Use of undeclared Var datascript/filter at line 11 src/datascript/js.cljs
Compiling src/datascript/parser.cljs
Analyzing jar:file:/Users/prokopov/.m2/repository/org/clojure/clojurescript/0.0-3030/clojurescript-0.0-3030.jar!/clojure/set.cljs
Compiling src/datascript/pull_api.cljs
Analyzing file:/Users/prokopov/Dropbox/ws/datascript/src/datascript/pull_parser.cljs
Compiling src/datascript/pull_parser.cljs
Compiling src/datascript/query.cljs
Analyzing jar:file:/Users/prokopov/.m2/repository/org/clojure/clojurescript/0.0-3030/clojurescript-0.0-3030.jar!/cljs/reader.cljs
Analyzing jar:file:/Users/prokopov/.m2/repository/org/clojure/clojurescript/0.0-3030/clojurescript-0.0-3030.jar!/clojure/walk.cljs
Compiling src/datascript/query_v3.cljs
Analyzing jar:file:/Users/prokopov/.m2/repository/com/cemerick/clojurescript.test/0.3.3/clojurescript.test-0.3.3.jar!/cemerick/cljs/test.cljs
Analyzing jar:file:/Users/prokopov/.m2/repository/org/clojure/clojurescript/0.0-3030/clojurescript-0.0-3030.jar!/clojure/string.cljs
Compiling src/datascript.cljs
WARNING: datascript is a single segment namespace at line 1 src/datascript.cljs
...

The problem is in this line:

WARNING: Use of undeclared Var datascript/filter at line 11 src/datascript/js.cljs

I have fully legit use of datascript/filter in datascript.js, and yet get this warning.

To reproduce, just lein cljsbuild once advanced on master of https://github.com/tonsky/datascript with 0.0-3030 or later



 Comments   
Comment by David Nolen [ 23/Mar/15 5:45 AM ]

In general we only consider minimal cases not complete projects as there are too many variables at play. We no longer consider anything involving cljsbuild. Please attempt to produce a minimal case first. Given the above you should be able produce something quite small and simple using the Quick Start and the standalone JAR. Thanks!

Comment by David Nolen [ 23/Mar/15 6:09 AM ]

I just tried the standalone 0.0-3126 JAR with the following:

src/alias_bug/core.cljs

(ns alias-bug.core)

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

src/alias_bug/js.cljs

(ns alias-bug.js
  (:require [alias-bug :as alias]))

alias/foo

src/alias_bug.cljs

(ns alias-bug
  (:require [alias-bug.core :as core]))

(def foo core/foo)

build.clj

(require '[cljs.closure :as cljsc])

(cljsc/build "src"
  {:output-to "out/main.js"
   :verbose true})

I compiled this with:

java -cp cljs.jar:src clojure.main build.clj

I did not see this issue. I tried touching one file then running build again one at a time, still did not see this issue. The implicit options here are :optimizations :none, :cache-analysis true.

Comment by Nikita Prokopov [ 23/Mar/15 6:37 AM ]

Sorry, for some reason I decided that’s something trivial that was just overlooked and is easy to spot without a minimal test case. Now I see it’s more deep/complex than that. Attaching a minimal use case. Looks like it has something to do with :require-macros

Comment by Nikita Prokopov [ 23/Mar/15 6:58 AM ]

Just for information: I also noted that compilation order is alphabetical, and naming files plays a role here: when it compiles a, then b, then c, bug reproduces, if we rename files to change that order, it vanishes.

Comment by Immo Heikkinen [ 04/Apr/15 10:02 AM ]

I ran into this as well. The source seems to be changes to `intern-macros` in commit https://github.com/clojure/clojurescript/commit/db2c4d04cb924da6f939c26ba36dcdad08ef7080
which causes analysis of the macro namespace to be skipped here:
https://github.com/clojure/clojurescript/blob/r3126/src/clj/cljs/analyzer.clj#L1240

Comment by David Nolen [ 04/Apr/15 10:36 AM ]

Thanks for the additional information. I think this should be enough for me to create a minimal case.

Comment by David Nolen [ 07/Apr/15 7:34 AM ]

fixed https://github.com/clojure/clojurescript/commit/0d0f50958c952db5281aaec5e7bf0c0f9954ccee

Comment by Nikita Prokopov [ 07/Apr/15 7:44 AM ]

Amazing — thanks David!

Comment by David Nolen [ 07/Apr/15 9:14 AM ]

Nikita & Immo I'm pretty sure this fixes the issue but you all should confirm with master. Thanks.

Comment by Immo Heikkinen [ 07/Apr/15 11:40 PM ]

Yes it fixes the issue. Thanks David!

Comment by Nikita Prokopov [ 09/Apr/15 1:32 PM ]

Confirming too — works both on minimal test case and on DataScript codebase, warning is gone





[CLJS-27] Conditional compilation (or reading) Created: 22/Jul/11  Updated: 09/Apr/15  Resolved: 09/Apr/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: Rich Hickey Assignee: David Nolen
Resolution: Completed Votes: 12
Labels: None

Attachments: File cljs-27.diff     File cljs-27-v2.diff     File cljs-27-v3.diff     File cljs-27-v4.diff     File cljs-27-v5.diff     File cljs-27-v6.diff     File conditional-compilation-clojure.diff     File conditional-compilation-clojurescript.diff    
Patch: Code and Test
Approval: Vetted

 Description   

As people start trying to write libs that are portable between Clojure and ClojureScript they might need to have a bit of branching on target. N.B. supporting this means a change to Clojure, although it has general utility there as well.

Consider CL #+ #- reader macros - http://www.lispworks.com/documentation/lw50/CLHS/Body/02_dhq.htm

Patch: cljs-27-v6.diff

Related: CLJ-1424, TRDR-14



 Comments   
Comment by Roman Scherer [ 19/Jul/12 8:52 AM ]

The following patches include an implementation of Common Lisp's #+
and #- reader macros to allow conditional compilation/reading for
Clojure and ClojureScript.

The patches add a dynamic variable called features to the
clojure.core and cljs.core namespaces, that should contain the
supported features of the platform in question as keywords.

Unlike in Common Lisp, the variable is a Clojure set and not a list.
In Clojure the set contains at the moment the :clojure keyword, and in
ClojureScript the :clojurescript keyword.

I would like to get feedback on the names that are added to this
variable. Are those ok? Is :jvm for Clojure and :js for ClojureScript
better? Should ClojureScript add something like :rhino, :v8 or
:browser as well?

To run the ClojureScript tests, drop a JAR named "clojure.jar" that
has the Clojure patch applied into ClojureScript's lib directory.

Comment by David Nolen [ 19/Jul/12 12:18 PM ]

This is an enhancement so it probably requires a design page and extended discussion before it will go anywhere. Until that happens I'm marking this is as low priority.

Comment by Roman Scherer [ 19/Jul/12 1:45 PM ]

Ok. If someone could give me write access to the Clojure Dev Wiki I would be happy to start such a design page.

Comment by David Nolen [ 19/Jul/12 5:50 PM ]

If you've sent in your CA request permissions on the clojure-dev mailing list.

Comment by Roman Scherer [ 21/Jul/12 5:45 AM ]

I started a design page for this ticket in the Clojure Dev wiki:
http://dev.clojure.org/display/design/Feature+Expressions

Comment by Stuart Halloway [ 27/Jul/12 1:48 PM ]

Posting my comments over on the design page...

Comment by Alex Miller [ 06/Aug/14 7:42 AM ]

Latest patch updates into current ClojureScript and use of tools.reader/tools.analyzer etc. The reader changes are all in the accompanying tools.reader patch in TRDR-14. This patch adds support to allow a new option "features" which is expected to be a set of keywords. build will inject :cljs into this set. The feature set is maintained in clojure.tools.reader/*features*. set! is enhanced to special-case an update to *features* in the code (presumably a rarely-used feature).

Because tools.reader needs the supporting patch, I left in several changes that pull in a new version of tools.reader - I don't actually expect those to be the correct versions but they are there as a reminder to update all of the proper places.

Comment by Alex Miller [ 11/Sep/14 9:04 AM ]

cljs-27-v2.diff adds ability to load .clj files as well as .cljs files when compiling.

Comment by Alex Miller [ 07/Nov/14 10:55 AM ]

Fresh patch, switch to take .cljc files.

Comment by Alex Miller [ 06/Jan/15 3:04 PM ]

Freshened patch for current CLJS.

Comment by David Nolen [ 06/Jan/15 9:55 PM ]

Alex the freshened patch includes modifications to the compiler version dynamic var and compiler version fn. Can we remove these? Thanks!

Comment by Alex Miller [ 07/Jan/15 12:28 PM ]

Yep, updated to -v5 patch.

Comment by Alex Miller [ 21/Jan/15 4:36 PM ]

Updated to use new tools.reader patch and to remove the ability to dynamically set the features set. The active set of features can be set on startup and are held in the features var in the analyzer.

Comment by David Nolen [ 09/Apr/15 10:32 AM ]

the big issues resolved as of https://github.com/clojure/clojurescript/commit/7ccdffaf8f36a28dec6651248707ac83e6362d79





[CLJS-1192] cljs.repl.node mistakenly depends upon JDK8 API Created: 08/Apr/15  Updated: 08/Apr/15  Resolved: 08/Apr/15

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

Type: Defect Priority: Major
Reporter: Chas Emerick Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: File CLJS-1192.diff    
Patch: Code

 Description   

The errant patch was associated with CLJS-1176.



 Comments   
Comment by David Nolen [ 08/Apr/15 11:44 AM ]

fixed https://github.com/clojure/clojurescript/commit/689ed7db5507fd3a10285f88086f8a379f55bbe6





[CLJS-1176] Push node.js REPL output through *out* and *err* Created: 27/Mar/15  Updated: 08/Apr/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! :-/





[CLJS-1188] multi-arity fns hinder cross-module code motion Created: 03/Apr/15  Updated: 07/Apr/15  Resolved: 06/Apr/15

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

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

Attachments: Text File CLJS-1188.patch    

 Description   

Google Closure compiler will not move multi-arity ClojureScript functions as they are constructed via a function invoke.



 Comments   
Comment by David Nolen [ 03/Apr/15 7:14 PM ]

Experimented with lazy loading top-level multi-arity fns (which also required eliminating all existing invoke optimization) and confirmed that multi-arity fns in their current form defeat code motion. With working code motion the results can be quite dramatic, in the case of the Mori it shrinks the base module to about 25K.

Comment by David Nolen [ 03/Apr/15 7:35 PM ]

Lazy loading is not the way to do it as it cannot be reconciled without our other optimizations. We should treat top-level multi-arity fns as a special case. There is now a code-motion branch where this exploration is underway.

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

In the code-motion branch currently explores doing this at the macro level. Doing this at the macro level avoids further complications to def and fn analyzer cases which are already the two of most complicated bits of the analyzer outside of ns. Doing this at the macro level does introduce its own issues - we have to replicate the implementation specific code generation bits handled by the compiler emission around multi-arity fns (the dispatcher), and the variadic fns (the argument wrangling, and runtime metadata). Another complication is that the compiler sees an fn var which takes no arguments. We will need to hack around this by collecting this information passing it along on the fn form.

Comment by David Nolen [ 06/Apr/15 6:30 PM ]

fixed https://github.com/clojure/clojurescript/commit/576fb6e054dd50ec458a3c9e4172a5a0002c7aea

Comment by Thomas Heller [ 07/Apr/15 4:48 AM ]

Nice work! Not seeing much in terms of movement between modules but my main module goes from 98KB to 91KB (gzip'd) due to extra removable code.

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

Thomas that's great to hear. As another datapoint, for Mori the difference is about a 30-35% reduction of the base module.





[CLJS-1190] definterface support Created: 03/Apr/15  Updated: 03/Apr/15

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

Type: Enhancement Priority: Major
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-1184] log module building activity under verbose Created: 02/Apr/15  Updated: 03/Apr/15  Resolved: 03/Apr/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: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

Log how modules are constructed to support user reports as well as development.



 Comments   
Comment by David Nolen [ 03/Apr/15 7:25 AM ]

fixed https://github.com/clojure/clojurescript/commit/343573f5bf748aec6943d71e85e9c9a36dcfb529





[CLJS-1187] var ast contains internal nodes with bad analysis :context Created: 02/Apr/15  Updated: 03/Apr/15  Resolved: 03/Apr/15

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

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


 Description   
(defn foo [] (print "foo!"))
 
(defn bar [] (print "bar!"))
 
(defn print-foo [fb]
  (apply 
    (case fb
      :foo #'foo
      :bar #'bar) []))


 Comments   
Comment by David Nolen [ 03/Apr/15 5:50 AM ]

fixed https://github.com/clojure/clojurescript/commit/49ed83337baf762ef21a907be234ebdbcc105d66





[CLJS-1185] Support preambles when our target is node.js and we are compiler a main file Created: 02/Apr/15  Updated: 02/Apr/15

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

Type: Enhancement Priority: Trivial
Reporter: Ivan Willig Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-1185.patch    




[CLJS-1186] add :postamble option to compiler Created: 02/Apr/15  Updated: 02/Apr/15

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

Type: Enhancement Priority: Minor
Reporter: Michael Bradley Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: cljs

Attachments: Text File cljs_1186.patch    

 Description   

Similar to CLJS-723:

1) :postamble's value will be a vector of paths
2) the compiled output is appended with the contents of the files at those paths
3) the generated source map points to the correct/adjusted line numbers






[CLJS-1183] load-file doesn't copy source to output directory Created: 01/Apr/15  Updated: 01/Apr/15  Resolved: 01/Apr/15

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

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

0.0-3169 QuickStart Browser REPL with watch commented out, OS X, Chrome



 Description   

If you invoke load-file for a path like "src/foo/bar.cljs", compiler output for the file is placed in "out/foo", but the source "bar.cljs" file is not copied. This results in java.io.FileNotFoundException: /Users/mfikes/Desktop/hello_world/out/foo/bar.cljs if source mapping of exception stacktraces needs to access the file.

To repro:
1. Use 0.0-3169 in QuickStart.
2. Set up Browser REPL following QuickStart, but comment out :watch.
3. Connect and ensure REPL is working.
4. Add "src/foo/bar.cljs" with contents below (a fn that will throw).
5. Do (load-file "src/foo/bar.cljs")
6. Call the fn: (foo.bar/call-me)
7. Observe attempt to read source in out when processing stacktrace.

cljs.user=> (foo.bar/call-me)
Error: 1 is not ISeqable
Exception in thread "main" java.io.FileNotFoundException: /Users/mfikes/Desktop/hello_world/out/foo/bar.cljs (No such file or directory), compiling:(/Users/mfikes/Desktop/hello_world/repl.clj:8:19)
	at clojure.lang.Compiler.load(Compiler.java:7142)
	at clojure.lang.Compiler.loadFile(Compiler.java:7086)
	at clojure.main$load_script.invoke(main.clj:274)
	at clojure.main$script_opt.invoke(main.clj:336)
	at clojure.main$main.doInvoke(main.clj:420)
	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: java.io.FileNotFoundException: /Users/mfikes/Desktop/hello_world/out/foo/bar.cljs (No such file or directory)
	at java.io.FileInputStream.open0(Native Method)
	at java.io.FileInputStream.open(FileInputStream.java:195)
	at java.io.FileInputStream.<init>(FileInputStream.java:138)
	at clojure.java.io$fn__8702.invoke(io.clj:229)
	at clojure.java.io$fn__8615$G__8606__8622.invoke(io.clj:69)
	at clojure.java.io$fn__8676.invoke(io.clj:165)
	at clojure.java.io$fn__8628$G__8610__8635.invoke(io.clj:69)
	at clojure.java.io$reader.doInvoke(io.clj:102)
	at clojure.lang.RestFn.invoke(RestFn.java:410)
	at cljs.analyzer$parse_ns$fn__1510.invoke(analyzer.clj:2049)
	at cljs.analyzer$parse_ns.invoke(analyzer.clj:2035)
	at cljs.analyzer$parse_ns.invoke(analyzer.clj:2026)
	at cljs.repl$read_source_map.invoke(repl.clj:218)
	at clojure.core$juxt$fn__4211.invoke(core.clj:2440)
	at cljs.repl$mapped_stacktrace$iter__3903__3907$fn__3908$fn__3909.invoke(repl.clj:287)
	at cljs.repl$mapped_stacktrace$iter__3903__3907$fn__3908.invoke(repl.clj:278)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.RT.seq(RT.java:484)
	at clojure.core$seq.invoke(core.clj:133)
	at clojure.core$map$fn__4245.invoke(core.clj:2551)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.LazySeq.more(LazySeq.java:85)
	at clojure.lang.RT.more(RT.java:607)
	at clojure.core$rest.invoke(core.clj:73)
	at cljs.repl$mapped_stacktrace.invoke(repl.clj:322)
	at cljs.repl$print_mapped_stacktrace.invoke(repl.clj:333)
	at cljs.repl$display_error.invoke(repl.clj:403)
	at cljs.repl$repl_caught.invoke(repl.clj:696)
	at cljs.repl$repl_STAR_$fn__4076$fn__4083.invoke(repl.clj:835)
	at cljs.repl$repl_STAR_$fn__4076.invoke(repl.clj:832)
	at cljs.compiler$with_core_cljs.invoke(compiler.clj:951)
	at cljs.repl$repl_STAR_.invoke(repl.clj:798)
	at cljs.repl$repl.doInvoke(repl.clj:914)
	at clojure.lang.RestFn.invoke(RestFn.java:439)
	at user$eval198.invoke(repl.clj:10)
	at clojure.lang.Compiler.eval(Compiler.java:6703)
	at clojure.lang.Compiler.load(Compiler.java:7130)
	... 9 more

Contents of "src/foo/bar.cljs"

(ns foo.bar)

(defn this-throws [] (ffirst 1))

(defn call-me [] (this-throws))


 Comments   
Comment by Mike Fikes [ 01/Apr/15 1:41 PM ]

Occurs for me with master (https://github.com/clojure/clojurescript/commit/d12d678d9babb7d9a164e11997f084eeeb378c16)

Comment by David Nolen [ 01/Apr/15 3:22 PM ]

Ah right, this is probably due to the fact that load-file doesn't copy over the original source file into :output-dir which is needed for source mapping to work.

Comment by David Nolen [ 01/Apr/15 5:43 PM ]

fixed https://github.com/clojure/clojurescript/commit/6c446bce4ffe367ad4b32e60f5139f201651bf29

Comment by Mike Fikes [ 01/Apr/15 5:50 PM ]

Confirmed fixed.





[CLJS-1180] Cache is read using read-edn, which does not accept all keywords that clojurescript accepts Created: 31/Mar/15  Updated: 01/Apr/15  Resolved: 01/Apr/15

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

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


 Description   

Source that contains keywords such as `:*:` cannot be loaded from the cache because it's not valid edn. The same keyword is accepted by cljsc. Consequently, non-clean builds can fail when they attempt to load from the cache.

This particular keyword is used in hiccup vectors to indicate splicing (e.g. keminglabs/singult).



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

This ticket needs more information - i.e. is this actually considered a valid keyword? Just because something can be read does not mean it's actually valid. According to http://clojure.org/reader, it appears keywords ending with : would be reserved by Clojure.

Comment by Francis Avila [ 01/Apr/15 9:52 AM ]

There are definitely problems with the keyword and symbol lack-of-specs and differences between edn and clojure, but :*: is an unreadable form everywhere.

Probably :*: was created from a string with (keyword ":*:"). So the problem here is really that Clojure will print forms that it and edn can't read back.

I think there was a proposal to have tagged-literal forms for symbols and keywords which are not readable directly, but I can't find a ticket for it. (e.g. print #kw [nil "*:"] instead.)

Related: CLJ-1527 CLJS-677 CLJ-1286

Comment by Stephen Nelson [ 01/Apr/15 4:34 PM ]

minimal reproduction using cljs.jar and the 'Quick Start' instructions.

:*: is a valid keyword in clojurescript, in so far that it's accepted by the cljs reader (without requiring using the keyword constructor). This is demonstrated by the reproduction I've created, the relevant source line is (println :*:). It is not accepted by the edn or clj readers.

The http://clojure.org/reader spec is an inaccurate representation of the syntax actually accepted by various readers. I think the compiler should at least be internally consistent in its behaviour, even if it doesn't follow the spec. I don't think it's reasonable for cljsc to fail when it loads from its cache as this behaviour is hard to diagnose for a user.

Tightening the constraints on keywords in the cljs reader to match edn and/or the clj reader would be an acceptable resolution of this issue.

Comment by David Nolen [ 01/Apr/15 4:43 PM ]

Just verified that this is an unreadable form in Clojure. Please feel free to file an issue with Singult or tools.reader which is what we use to read.





[CLJS-1182] semantics of load-file should be require + implicit :reload Created: 01/Apr/15  Updated: 01/Apr/15  Resolved: 01/Apr/15

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

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


 Comments   
Comment by David Nolen [ 01/Apr/15 6:02 AM ]

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





[CLJS-1181] User Defined Tagged literal for integer causes all repls to hang Created: 01/Apr/15  Updated: 01/Apr/15

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

Type: Defect Priority: Major
Reporter: Kuldeep Assignee: Unassigned
Resolution: Unresolved 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.





[CLJS-1179] strange load-file behavior Created: 31/Mar/15  Updated: 31/Mar/15  Resolved: 31/Mar/15

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

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


 Description   

As reported by Colin Fleming:

~/d/cljs> cat node_repl.clj 
(require 'cljs.repl)
(require 'cljs.closure)
(require 'cljs.repl.node)

(cljs.closure/build "src"
  {:main 'hello-world.core
   :output-to "out/main.js"
   :verbose true})

(cljs.repl/repl (cljs.repl.node/repl-env)
  :watch "src"
  :output-dir "out")

~/d/cljs> cat src/hello_world/core.cljs 
(ns hello-world.core
  (:require [cljs.nodejs :as nodejs]))

(nodejs/enable-util-print!)

(defn -main [& args]
  (println "Hello world!"))

(set! *main-cli-fn* -main)

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

~/d/cljs> rlwrap java -cp cljs.jar:src clojure.main node_repl.clj
Reading analysis cache for jar:file:/Users/colin/dev/cljs/cljs.jar!/cljs/core.cljs
Compiling src/hello_world/core.cljs
Analyzing jar:file:/Users/colin/dev/cljs/cljs.jar!/cljs/nodejs.cljs
Compiling out/cljs/nodejs.cljs
Compiling out/cljs/core.cljs
Using cached cljs.core out/cljs/core.cljs
ClojureScript Node.js REPL server listening on 55907
Watch compilation log available at: out/watch.log
To quit, type: :cljs/quit
cljs.user=> (load-file "/Users/colin/dev/cljs/src/hello_world/core.cljs")
nil
cljs.user=> (hello-world.core/foo 1 2)
repl:13
throw e__3976__auto__;
      ^
TypeError: Cannot read property 'call' of undefined
    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)
cljs.user=> (require '[hello-world.core :as hello] :reload)
/Users/colin/dev/cljs/out/hello_world/core.js:5
cljs.nodejs.enable_util_print_BANG_.call(null);
           ^
TypeError: Cannot read property 'enable_util_print_BANG_' of undefined
    at Object.<anonymous> (/Users/colin/dev/cljs/out/hello_world/core.cljs:4:2)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at global.CLOSURE_IMPORT_SCRIPT (repl:75:16)
    at Object.goog.require (repl:19:60)
    at repl:3:6
cljs.user=> :cljs/quit

~/d/cljs> rlwrap java -cp cljs.jar:src clojure.main node_repl.clj
Reading analysis cache for jar:file:/Users/colin/dev/cljs/cljs.jar!/cljs/core.cljs
Compiling src/hello_world/core.cljs
Reading analysis cache for jar:file:/Users/colin/dev/cljs/cljs.jar!/cljs/nodejs.cljs
Compiling out/cljs/nodejs.cljs
ClojureScript Node.js REPL server listening on 50817
Watch compilation log available at: out/watch.log
To quit, type: :cljs/quit
cljs.user=> (require '[hello-world.core :as hello] :reload)
nil
cljs.user=> (hello-world.core/foo 1 2)
3
cljs.user=> :cljs/quit
~/d/cljs>


 Comments   
Comment by David Nolen [ 31/Mar/15 7:32 AM ]

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





[CLJS-1178] Compiler does not know Math ns is not not-native Created: 29/Mar/15  Updated: 29/Mar/15

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

Type: Defect Priority: Minor
Reporter: Francis Avila Assignee: Unassigned
Resolution: Unresolved 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$$);
}





[CLJS-1164] quot and rem are inefficient Created: 24/Mar/15  Updated: 29/Mar/15

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

Type: Enhancement Priority: Minor
Reporter: Francis Avila Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: math

Attachments: Text File cljs-1164.patch    
Patch: Code and Test

 Description   

The implementation of the quot and rem functions are needlessly complicated. Currently they are:

(defn quot [n d] (fix (/ (- n (js-mod n d)) d)))
(defn rem [n d] (- n (* d (quot n d))))

However all numbers in js are doubles already, so all this is unnecessary:

(defn quot [n d] (fix (/ n d)))
(defn rem [n d] (js-mod n d)))

Notice that "rem" is simply js-mod, and I'm not sure why no one noticed this before. I keep js-mod for now since a lot of code uses it, and if cljs ever grows a number tower the distinction may be important.

Patch attached, which also:

  • Creates a macro version of quot and rem.
  • Updates documentation for quot, rem, js-mod and mod for clarity.
  • Implement fix (private function to round to zero) with ES6 Math.trunc() if available.

Existing quot and rem tests pass, although there could be some better tests of edge cases (negative decimal num or div, NaN and +-Infinity args).



 Comments   
Comment by Francis Avila [ 24/Mar/15 12:27 PM ]

Better tests found rounding errors in my updated rem, which should stay as-is. (Not simply js-mod after all! Seems to round args first? Not obvious from the spec.) Changed quot however is correct and introduces less error than the current one. Will update patch and tests when I get a chance.

Comment by Francis Avila [ 29/Mar/15 12:39 AM ]

Working patch with tests attached. Tests expanded to cover floating-point cases. rem is now fundamentally the same as master (was more accurate than js-mod!!), but returns results consistent with js-mod for non-finite args or zero divisor.





[CLJS-1177] A compiler pass for JS dialects Created: 28/Mar/15  Updated: 28/Mar/15

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

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
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-1175] CLJS defmulti doesn't exhibit same defonce behavior as Clojure's defmulti, suggesting an even better reloading behavior Created: 27/Mar/15  Updated: 28/Mar/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: Defect Priority: Major
Reporter: Bruce Hauman Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

I just noticed that the redefinition of a defmulti completely destroys the dispatch table associated with it.

This is not the case in Clojure.
http://dev.clojure.org/jira/browse/CLJ-900
https://github.com/clojure/clojure/commit/1b8d5001ba094053b24c55829994785be422cfbf

I actually think the better behavior is to create a new MultiFn with the new options and steal the dispatch table state from the current MultiFn.

I think this is the least surprising behavior.



 Comments   
Comment by David Nolen [ 27/Mar/15 1:32 PM ]

defmulti in Clojure has defonce semantics. I don't think we need to do anything at all beyond that. Patch welcome for this.

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

fixed https://github.com/clojure/clojurescript/commit/380c8b19c5fada55c40759063a4a23332bc7fdf8





[CLJS-808] Warning from `find-classpath-lib` mistakenly included in generated source Created: 02/Jun/14  Updated: 27/Mar/15  Resolved: 27/Mar/15

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

Type: Defect Priority: Major
Reporter: Joshua Ballanco Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None
Environment:

clojurescript 0.0-r2227
target: node


Attachments: Text File warn-with-out-str-fix.patch    
Patch: Code

 Description   

When compiling for node.js, `find-classpath-lib` generates a warning because `cljs/nodejs.js` doesn't contain a `goog.provide` declaration. However, this warning ends up being emitted into the JS files being generated (caused by a call to `with-out-str`), later causing a critical failure in the Closure compiler.

To reproduce:

  • `lein new cljs-node buggy`
  • Update clojurescript to r2227, lein-cljsbuild to 1.0.3
  • `lein cljsbuild once`

Result:

  • Multiple warnings
  • Generated "buggy.js" file contains only node.js shebang

Fix:

  • The simplest patch (attached) is to rebind `out` to `err` when emitting a warning
  • A better fix would be to write a function for error printing that wraps this idiom
  • Ideally, cljs/nodejs.js should have a `goog.provides` line added to prevent the warning in the first place


 Comments   
Comment by David Nolen [ 02/Jun/14 7:45 AM ]

A patch that adds a goog.provide to the file is preferred, thanks!

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

fixed https://github.com/clojure/clojurescript/commit/9cddd7581c5cdacfe4f4f20274aed61cd3cfc7cb





[CLJS-1144] Expose MultiFn assessors Created: 18/Mar/15  Updated: 27/Mar/15  Resolved: 27/Mar/15

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

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

Attachments: Text File 1144.patch    

 Description   

The MultiFn fields default-dispatch-val and dispatch-fn are useful in some cases. It would be nice to have accessors for these fields instead of having to use property access directly.



 Comments   
Comment by Joel Holdbrooks [ 18/Mar/15 12:31 PM ]

Added patch

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

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





[CLJS-1172] Determine if practical to supply main entry points for all standard REPLs Created: 26/Mar/15  Updated: 27/Mar/15  Resolved: 27/Mar/15

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

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


 Comments   
Comment by David Nolen [ 27/Mar/15 5:21 AM ]

fixed https://github.com/clojure/clojurescript/commit/9d7ee61070ba50dce283dea2b4c5caceaf8002cc





[CLJS-1171] map clojure.repl/doc, clojure.repl/source, clojure.repl/dir Created: 26/Mar/15  Updated: 27/Mar/15  Resolved: 27/Mar/15

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

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


 Comments   
Comment by David Nolen [ 27/Mar/15 5:02 AM ]

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





[CLJS-1170] expose macroexpand & macroexpand-1 at the REPL Created: 26/Mar/15  Updated: 27/Mar/15  Resolved: 27/Mar/15

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

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


 Comments   
Comment by David Nolen [ 27/Mar/15 4:58 AM ]

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





[CLJS-1169] cannot use REPL load-file on files that declare single segment namespaces Created: 26/Mar/15  Updated: 26/Mar/15  Resolved: 26/Mar/15

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

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


 Description   

While not encouraged for projects, being able to do this when trying thing out is convenient.



 Comments   
Comment by David Nolen [ 26/Mar/15 9:19 PM ]

fixed by b17edea679fab22bafb949f0cffb01c1c55d33c9





[CLJS-288] Compilation of unordered collections Created: 31/May/12  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

Type: Defect Priority: Trivial
Reporter: Brandon Bloom Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

Given:

(defn f [x] (println x) x)

{(f 5) (f 10), (f :x) (f :y)}

Clojure produces:

5
10
:x
:y

{5 10, :x :y}

ClojureScript produces:

5
:x
10
:y

{5 10, :x :y}

 Comments   
Comment by Brandon Bloom [ 16/Aug/12 9:28 PM ]

See also: CLJ-1043

I realized that this problem is actually only partially solvable as is. We could assign the interleaved keys and values to locals before constructing the map. Unfortunately, that doesn't solve a bigger underlying problem: The reader returns unordered sets and maps.

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

Is this actually a problem?

Comment by Brandon Bloom [ 23/Sep/12 7:40 PM ]

See discussion at http://dev.clojure.org/jira/browse/CLJ-1043?focusedCommentId=29526#comment-29526

Comment by Brandon Bloom [ 25/Mar/15 8:08 PM ]

See discussion at CLJ-1043





[CLJS-1167]  Using (require 'namespace.core :reload) causes "too much recursion" - one process only. Created: 24/Mar/15  Updated: 24/Mar/15

Status: Open
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: Unresolved 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






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

Status: Open
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: Unresolved 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





[CLJS-1165] Support for multiple source directories in cljs.closure/build and watch Created: 24/Mar/15  Updated: 24/Mar/15

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

Type: Defect Priority: Minor
Reporter: Daniel Skarda Assignee: Unassigned
Resolution: Unresolved 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?






[CLJS-1163] Using (require 'namespace.core :reload) causes "too much recursion" Created: 23/Mar/15  Updated: 23/Mar/15  Resolved: 23/Mar/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)


Attachments: File m060.tgz    

 Description   

lein new mies m060 (using latest version of mies from github)
Uncomment repl/connect in core.cljs, add function (defn doubled[x] (* 2 x))
In one terminal window: scripts/watch (wait for it to build)
In another terminal window: scripts/brepl
In browser: go to http://localhost:9000 and open web console.
In REPL: (require 'm060.core), then (in-ns 'm060.core)
In editor, add this to core.cljs: (defn tripled[x] (* 3 x)) ;; the "watch" window will recompile it
In REPL: (require 'm060.core :reload)
After a long pause, web console displays "too much recursion" message twice.
Despite the error message, in REPL: (tripled 10) works properly.



 Comments   
Comment by David Nolen [ 23/Mar/15 11:07 PM ]

We don't support multiple processes compiling to the same output directory.

Comment by J David Eisenberg [ 23/Mar/15 11:08 PM ]

Spurious issue; can't run both brepl and watch at the same time.





[CLJS-1019] REPL source map caching support Created: 07/Feb/15  Updated: 23/Mar/15  Resolved: 23/Mar/15

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

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


 Description   

Need smarter caching for better performance. Probably something based on last modified times.



 Comments   
Comment by David Nolen [ 23/Mar/15 9:57 PM ]

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





[CLJS-1162] Failure to printStackTrace when REPL initialized Created: 23/Mar/15  Updated: 23/Mar/15  Resolved: 23/Mar/15

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

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

Attachments: Text File CLJS-1162.patch    

 Description   

I got the (spurious) exception included below once when starting the Ambly REPL with 0.0-3148.

For quick reference, relevant code is
https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/repl.clj#L687

FWIW, I found that I can reproduce it in a Clojure REPL with:

(binding [*err* 1]
      (.printStackTrace (clojure.lang.ExceptionInfo. "hi" {} (Throwable.)) *err*))

where *err* is bound to anything of a type that is not an instance of PrintStream, which is perhaps at the root of the problem.

Exception in thread "main" java.lang.IllegalArgumentException: No matching method found: printStackTrace for class clojure.lang.ExceptionInfo, compiling:(/private/var/folders/nm/97bx7f_n31z2t2g_gf2bn90w0h013l/T/form-init733659167150723581.clj:1:141)
	at clojure.lang.Compiler.load(Compiler.java:7142)
	at clojure.lang.Compiler.loadFile(Compiler.java:7086)
	at clojure.main$load_script.invoke(main.clj:274)
	at clojure.main$init_opt.invoke(main.clj:279)
	at clojure.main$initialize.invoke(main.clj:307)
	at clojure.main$null_opt.invoke(main.clj:342)
	at clojure.main$main.doInvoke(main.clj:420)
	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.IllegalArgumentException: No matching method found: printStackTrace for class clojure.lang.ExceptionInfo
	at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:80)
	at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28)
	at cljs.repl$repl_caught.invoke(repl.clj:687)
	at cljs.repl$repl_STAR_$fn__4102$fn__4103.invoke(repl.clj:790)
	at cljs.repl$repl_STAR_$fn__4102.invoke(repl.clj:785)
	at cljs.compiler$with_core_cljs.invoke(compiler.clj:951)
	at cljs.repl$repl_STAR_.invoke(repl.clj:782)
	at user$eval4325.invoke(form-init733659167150723581.clj:3)
	at clojure.lang.Compiler.eval(Compiler.java:6703)
	at clojure.lang.Compiler.eval(Compiler.java:6666)
	at clojure.core$eval.invoke(core.clj:2927)
	at clojure.main$eval_opt.invoke(main.clj:288)
	at clojure.main$initialize.invoke(main.clj:307)
	at clojure.main$null_opt.invoke(main.clj:342)
	at clojure.main$main.doInvoke(main.clj:420)
	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:483)
	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:483)
	at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
	at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:207)
	at user$eval5.invoke(form-init733659167150723581.clj:1)
	at clojure.lang.Compiler.eval(Compiler.java:6703)
	at clojure.lang.Compiler.eval(Compiler.java:6693)
	at clojure.lang.Compiler.load(Compiler.java:7130)
	... 11 more


 Comments   
Comment by Mike Fikes [ 23/Mar/15 1:07 PM ]

Minor correction to description: PrintStream or PrintWriter.

Comment by Mike Fikes [ 23/Mar/15 1:30 PM ]

I am able to reproduce this by adding

(throw (clojure.lang.ExceptionInfo. "hi" {} (Throwable.)))

to Ambly's startup impl.

With this, I added a (prn *err*) right before the line in repl.clj and get this:

#<OutputStreamWriter java.io.OutputStreamWriter@1fe05fff>

This class is neither PrintStream or PrintWriter, so this is the penultimate cause.

Comment by Mike Fikes [ 23/Mar/15 1:37 PM ]

A minimal repro with Node.js REPL:

Add the throw mentioned above to the Node REPL impl, as the first thing inside setup:

--- a/src/clj/cljs/repl/node.clj
+++ b/src/clj/cljs/repl/node.clj
@@ -102,6 +102,7 @@
           root (.substring path 0 (+ (.indexOf path fc) (count fc)))
           root-path (vec (cons root cs))
           rewrite-path (conj root-path "goog")]
+      (throw (clojure.lang.ExceptionInfo. "hi" {} (Throwable.)))
       (reset! (:proc repl-env) proc)
       (loop [r nil]
         (when-not (= r "ready")

Then (with (prn *err*) still in place):

Mike-Fikess-MacBook-Pro:clojurescript mfikes$ script/noderepljs 
#<OutputStreamWriter java.io.OutputStreamWriter@41f686af>
Exception in thread "main" java.lang.IllegalArgumentException: No matching method found: printStackTrace for class clojure.lang.ExceptionInfo
	at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:80)
	at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28)
	at cljs.repl$repl_caught.invoke(repl.clj:688)
	at cljs.repl$repl_STAR_$fn__4074.invoke(repl.clj:756)
	at cljs.compiler$with_core_cljs.invoke(compiler.clj:951)
	at cljs.repl$repl_STAR_.invoke(repl.clj:749)
	at cljs.repl$repl.doInvoke(repl.clj:900)
	at clojure.lang.RestFn.invoke(RestFn.java:410)
	at user$eval4248.invoke(NO_SOURCE_FILE:3)
	at clojure.lang.Compiler.eval(Compiler.java:6703)
	at clojure.lang.Compiler.eval(Compiler.java:6666)
	at clojure.core$eval.invoke(core.clj:2927)
	at clojure.main$eval_opt.invoke(main.clj:288)
	at clojure.main$initialize.invoke(main.clj:307)
	at clojure.main$null_opt.invoke(main.clj:342)
	at clojure.main$main.doInvoke(main.clj:420)
	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)
ClojureScript Node.js REPL server listening on 57399
Mike-Fikess-MacBook-Pro:clojurescript mfikes$
Comment by Mike Fikes [ 23/Mar/15 2:07 PM ]

Attached patch resolves issue. See CLJ-286 for interesting discussion surrounding root cause.

Comment by Mike Fikes [ 23/Mar/15 3:43 PM ]

I suppose an alternate patch could first check if *out* is a PrintWriter and conditionally do the wrapping. I'd be happy to put that together if warranted.

Comment by David Nolen [ 23/Mar/15 4:04 PM ]

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

Comment by Mike Fikes [ 23/Mar/15 4:27 PM ]

Confirmed fixed in master.





[CLJS-1161] Use higher-level binding of *cljs-ns*, REPL stack traces not printing to *err* Created: 23/Mar/15  Updated: 23/Mar/15  Resolved: 23/Mar/15

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

Type: Enhancement Priority: Blocker
Reporter: Chas Emerick Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1161.patch    
Patch: Code

 Comments   
Comment by Chas Emerick [ 23/Mar/15 12:18 PM ]

Patch attached. Not printing to *err* was probably just an oversight; being able to rebind *cljs-ns* at a higher level enables user-facing REPL utilities other than cljs.repl/repl.

Comment by David Nolen [ 23/Mar/15 12:21 PM ]

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





[CLJS-1160] Source map js / cljs line number mixup Created: 23/Mar/15  Updated: 23/Mar/15

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

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

QuickStart Browser REPL Chrome OS X



 Description   

Note the source location for cljs.core.LazySeq.sval in the following 0.0-3126 stacktrace:

ClojureScript:cljs.user> (map ffirst (range))
Error: 0 is not ISeqable
	 cljs$core$seq (out/cljs/core.cljs:951:13)
	 cljs$core$first (out/cljs/core.cljs:960:7)
	 cljs$core$ffirst (out/cljs/core.cljs:1393:3)
	 cljs.core.map.cljs$core$map__2 (out/cljs/core.cljs:4046:30)
	 cljs.core.LazySeq.sval (out/cljs/core.cljs:11400:3)
	 cljs.core.LazySeq.cljs$core$ISeqable$_seq$arity$1 (out/cljs/core.cljs:2884:12)
	 cljs$core$seq (out/cljs/core.cljs:938:7)
	 cljs$core$pr_sequential_writer (out/cljs/core.cljs:8426:13)

It turns out that line 11400 is actually in core.js, but the source map logic is evidently getting tripped up by this one, and core.cljs gets reported with the JS line numbers (core.cljs doesn't even have that many lines).

Note that this also occurs on master (where CLJS-1154 and CLJS-1157 have landed):

ClojureScript:cljs.user> (map ffirst (range))
Error: 0 is not ISeqable
	 cljs.core/seq (out/cljs/core.cljs:951:20)
	 cljs.core/first (out/cljs/core.cljs:960:16)
	 cljs$core$ffirst (out/cljs/core.cljs:1393:11)
	 cljs.core.map.cljs$core$map__2 (out/cljs/core.cljs:4046:30)
	 cljs.core.LazySeq.sval (out/cljs/core.cljs:11400:3)
	 cljs.core.LazySeq.cljs$core$ISeqable$_seq$arity$1 (out/cljs/core.cljs:2884:12)
	 cljs.core/seq (out/cljs/core.cljs:938:25)
	 cljs$core$pr_sequential_writer (out/cljs/core.cljs:8426:20)





[CLJS-841] cljs.closure/build file locks Created: 13/Aug/14  Updated: 22/Mar/15  Resolved: 22/Mar/15

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

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

Windows 7, 8, sublime text 3, lein-cljsbuild 1.0.3



 Description   

I suspect that the following issue of the lein-cljsbuild (https://github.com/emezeske/lein-cljsbuild/issues/322) is caused by clojurescript itself and not the plugin. In short: Is it possible that the cljs.closure/build function keeps file locks on the source files? This would explain why running `lein cljsbuild auto` prevents editors like sublime to save (overwrite) the files.



 Comments   
Comment by Thomas Heller [ 14/Aug/14 4:01 AM ]

cljs.closure/build does no file locking. The file is opened, read completely and then closed.

https://github.com/clojure/clojurescript/blob/95122e1206d4a64f392cff03bfd73712ab7f3a33/src/clj/cljs/closure.clj#L256

Comment by joerupen [ 18/Aug/14 6:11 AM ]

Okay, but how is possible that when I comment out the call to the build function, then lein-cljsbuild maintains no locks on the source files? Without the call, lein-cljsbuild picks up any modifications that I do to my source files and invokes the build (which in that case just does nothing, see https://github.com/emezeske/lein-cljsbuild/issues/322).

I opened this issue because it's really disturbing the development workflow when you cannot use `lein cljsbuild auto`. If it's not due to ClojureScript you can close this issue.

Comment by David Nolen [ 18/Aug/14 9:41 AM ]

Never heard this before, sounds possibly like a host issue that we might not be aware of?

Comment by joerupen [ 18/Aug/14 4:18 PM ]

It happens on win7/8 with jdk 7. This problem seems related to sublime 3, as with e.g. lighttable I have no problem. You can see that java.exe holds open file handles on the source files (sysinternals process explorer). Closing the handles manually works but is just a workaround. The reason is that sublime is actually doing a file 'move' operation. When you run `lein cljsbuild auto` and try to overwrite a source file from windows explorer you get the same problem, however you can still open & modify the file in various editors. So it's not a real file lock, but a file lock that prevents a file-move operation. I really don't know if it's ClojureScript or the plugin itself.

Comment by Thomas Heller [ 19/Aug/14 6:21 AM ]

Not sure how lein-cljsbuild handles the file watching, maybe that keeps files open?

Try replacing your (spit ...) test with (Thread/sleep 5000) or something that takes time, since spit is probably "too fast". Is it happening then?

Comment by joerupen [ 19/Aug/14 9:47 AM ]

I just tried to intercept the arguments in the call to cljs.closure/build and then invoked the build function in a repl using the same args. There was no lock this time, but also the generated js files were wrong. There might be some thread bindings in lein-cljsbuild that I am missing, but it looks like the build function by itself does not lock. I also replaced the code with Thread/sleep but the effect is the same. Only when I comment out the build function I can save my file. I also tried to run the build function in an agent, but without success, locks keep existing. I'll keep exploring some other potential causes in lein-cljsbuild and let you know if I find something useful.

Comment by joerupen [ 20/Aug/14 4:45 AM ]

By introducing a (Thread/sleep 5000) right after the build function I give the JVM some time to relax right after compiling. The locks seem to disappear (or become very rare). Doesn't that should like a finalizer waiting to be called by the garbage collector? If the polling starts immediatly, the locks occur almost instantly. I know that functions like slurp are pretty safe, so maybe this whole issue is caused by some internals of the JVM itself. Since I don't know all the internals of cljs.closure/build I can't possibly exclude it.

@Thomas: I had a look at the lein-cljsbuild source and from what I understood was that every 100ms,

My conclusion is that lein-cljsbuild does not open any file for reading (at least not in my simple project, no macros, no crossovers, just a simple hello world if you will). It only does directory listings and queries for modified timestamps. Under the hood, querying a file's attributes might very well translate into a call for opening & reading the file and this is done very often. If you have some ideas how I could attempt to locate the root cause, a hint would be appreciated As a workaround I can only recommend to switch to lighttable.

Comment by Thomas Heller [ 20/Aug/14 4:02 PM ]

100ms seems a little overkill to me since no human will make meaningful changes in that time, but that should not matter. A pending finalizer should not be the cause since cljs.closure/build uses with-open which closes the reader when done.

But I use neither Windows, Sublime Text or lein-cljsbuild so I'm just guessing anyways.

If you are feeling adventurous you could try https://github.com/thheller/shadow-build (shameless-plug) but I never tried it on Windows so it might actually blow up or something.

Comment by joerupen [ 22/Aug/14 7:28 AM ]

On https://github.com/emezeske/lein-cljsbuild/issues/322 I have posted a workaround. I basically copy the source cljs files to a temp folder and run `cljs.closure/build` from that folder. Interestingly I can always delete that folder after invoking build. This indicates that this issue only occurs in combination with the lein-cljsbuild plugin (due to the watch behavior). As far as the build function is concerned I'd recommend to close this issue in jira.

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

Not a ClojureScript thing specifically.

Comment by David Nolen [ 19/Mar/15 6:38 AM ]

This is a legitimate platform issue: http://stackoverflow.com/questions/2537306/java-opening-and-reading-from-a-file-without-locking-it

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

Unfortunately I don't see a good way to solve this. Someone who is more familiar with Java on Windows will have to contribute an answer for closing the reader under error conditions.

Comment by David Nolen [ 22/Mar/15 2:44 PM ]

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





[CLJS-1151] Noisy errors when referring to symbol in undefined ns Created: 19/Mar/15  Updated: 22/Mar/15

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

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

Quick Start / OS X / Chrome



 Description   

Run through the Quick Start to the point where you have the browser REPL running.

If you refer to a symbol in an undefined ns you will get really noisy errors:

ClojureScript:cljs.user> foo.bar/a
WARNING: Use of undeclared Var foo.bar/a at line 1 <cljs repl>
ReferenceError: foo is not defined
ReferenceError: foo is not defined
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:1:89)
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:9:3)
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:14:4)
    at http://localhost:9000/out/clojure/browser/repl.js:42:267
    at clojure$browser$repl$evaluate_javascript (http://localhost:9000/out/clojure/browser/repl.js:45:4)
    at Object.callback (http://localhost:9000/out/clojure/browser/repl.js:242:169)
    at goog.messaging.AbstractChannel.deliver (http://localhost:9000/out/goog/messaging/abstractchannel.js:142:13)
    at goog.net.xpc.CrossPageChannel.xpcDeliver (http://localhost:9000/out/goog/net/xpc/crosspagechannel.js:733:12)
    at Function.goog.net.xpc.NativeMessagingTransport.messageReceived_ (http://localhost:9000/out/goog/net/xpc/nativemessagingtransport.js:321:13)
    at Object.goog.events.fireListener (http://localhost:9000/out/goog/events/events.js:741:21)

Now, define the namespace, but don't actually define the symbol. For example:

(ns foo.bar)

(def z 3)

Now, require the namespace and do the same. The noise will go away.

ClojureScript:cljs.user> (require 'foo.bar)
nil
ClojureScript:cljs.user> foo.bar/a
WARNING: Use of undeclared Var foo.bar/a at line 1 <cljs repl>
nil

Additional info: Now if you attempt to refer to other unknown symbols, you will get different kinds of "noise" depending on whether the ns simply starts with foo:

ClojureScript:cljs.user> foo.baz/a
WARNING: No such namespace: foo.baz, could not locate foo/baz.cljs at line 1 <cljs repl>
WARNING: Use of undeclared Var foo.baz/a at line 1 <cljs repl>
TypeError: Cannot read property 'a' of undefined
TypeError: Cannot read property 'a' of undefined
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:1:96)
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:9:3)
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:14:4)
    at http://localhost:9000/out/clojure/browser/repl.js:42:267
    at clojure$browser$repl$evaluate_javascript (http://localhost:9000/out/clojure/browser/repl.js:45:4)
    at Object.callback (http://localhost:9000/out/clojure/browser/repl.js:242:169)
    at goog.messaging.AbstractChannel.deliver (http://localhost:9000/out/goog/messaging/abstractchannel.js:142:13)
    at goog.net.xpc.CrossPageChannel.xpcDeliver (http://localhost:9000/out/goog/net/xpc/crosspagechannel.js:733:12)
    at Function.goog.net.xpc.NativeMessagingTransport.messageReceived_ (http://localhost:9000/out/goog/net/xpc/nativemessagingtransport.js:321:13)
    at Object.goog.events.fireListener (http://localhost:9000/out/goog/events/events.js:741:21)
ClojureScript:cljs.user> goo.baz/a
WARNING: No such namespace: goo.baz, could not locate goo/baz.cljs at line 1 <cljs repl>
WARNING: Use of undeclared Var goo.baz/a at line 1 <cljs repl>
ReferenceError: goo is not defined
ReferenceError: goo is not defined
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:1:89)
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:9:3)
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:14:4)
    at http://localhost:9000/out/clojure/browser/repl.js:42:267
    at clojure$browser$repl$evaluate_javascript (http://localhost:9000/out/clojure/browser/repl.js:45:4)
    at Object.callback (http://localhost:9000/out/clojure/browser/repl.js:242:169)
    at goog.messaging.AbstractChannel.deliver (http://localhost:9000/out/goog/messaging/abstractchannel.js:142:13)
    at goog.net.xpc.CrossPageChannel.xpcDeliver (http://localhost:9000/out/goog/net/xpc/crosspagechannel.js:733:12)
    at Function.goog.net.xpc.NativeMessagingTransport.messageReceived_ (http://localhost:9000/out/goog/net/xpc/nativemessagingtransport.js:321:13)
    at Object.goog.events.fireListener (http://localhost:9000/out/goog/events/events.js:741:21)


 Comments   
Comment by Mike Fikes [ 19/Mar/15 3:47 PM ]

Clarification on the description: When defining the foo.bar ns, I actually created a source file src/foo/bar.cljs containing the ns declaration and the def z.

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

I'm not sure what we can do about this or that suppressing the errors from the JavaScript evaluation environment is a good idea. Property access on something that doesn't exist is what causes the JS environment to emit the error. In the later cases the property access is on something that does exist but doesn't have the property so no error.





[CLJS-1156] load-file fails with :make-reader issue Created: 20/Mar/15  Updated: 22/Mar/15  Resolved: 21/Mar/15

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

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

Quick Start, browser REPL (with :watch eliminated from repl.clj), OS X, Chrome,



 Description   

If I try (load-file ...) in the Browser REPL (Quick Start) for a file I've added it fails.

Here is a sample transcript illustrating the issue, followed by successfully using (require ...).

orion:hello_world mfikes$ rlwrap java -cp cljs.jar:src clojure.main repl.clj
Compiling client js ...
Waiting for browser to connect ...
To quit, type: :cljs/quit
ClojureScript:cljs.user> (doc load-file)
-------------------------
load-file
REPL Special Function
  Sequentially read and evaluate the set of forms contained in the file.
nil
ClojureScript:cljs.user> (load-file "src/foo/bar.cljs")
java.lang.IllegalArgumentException: No implementation of method: :make-reader of protocol: #'clojure.java.io/IOFactory found for class: nil
	at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:544)
	at clojure.java.io$fn__8628$G__8610__8635.invoke(io.clj:69)
	at clojure.java.io$reader.doInvoke(io.clj:102)
	at clojure.lang.RestFn.invoke(RestFn.java:410)
	at cljs.analyzer$forms_seq.invoke(analyzer.clj:1957)
	at cljs.analyzer$parse_ns$fn__1485.invoke(analyzer.clj:2011)
	at cljs.analyzer$parse_ns.invoke(analyzer.clj:1998)
	at cljs.analyzer$parse_ns.invoke(analyzer.clj:1989)
	at cljs.closure$src_file__GT_target_file.invoke(closure.clj:1580)
	at cljs.closure$src_file__GT_target_file.invoke(closure.clj:1575)
	at cljs.repl$load_file.invoke(repl.clj:467)
	at cljs.repl$fn__3938$self__3940.invoke(repl.clj:540)
	at cljs.repl$repl_STAR_$read_eval_print__4004.invoke(repl.clj:745)
	at cljs.repl$repl_STAR_$fn__4010$fn__4017.invoke(repl.clj:785)
	at cljs.repl$repl_STAR_$fn__4010.invoke(repl.clj:784)
	at cljs.compiler$with_core_cljs.invoke(compiler.clj:950)
	at cljs.repl$repl_STAR_.invoke(repl.clj:749)
	at cljs.repl$repl.doInvoke(repl.clj:866)
	at clojure.lang.RestFn.invoke(RestFn.java:439)
	at user$eval30.invoke(repl.clj:10)
	at clojure.lang.Compiler.eval(Compiler.java:6703)
	at clojure.lang.Compiler.load(Compiler.java:7130)
	at clojure.lang.Compiler.loadFile(Compiler.java:7086)
	at clojure.main$load_script.invoke(main.clj:274)
	at clojure.main$script_opt.invoke(main.clj:336)
	at clojure.main$main.doInvoke(main.clj:420)
	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)
ClojureScript:cljs.user> (load-file "/Users/mfikes/Desktop/hello_world/src/foo/bar.cljs")
java.lang.IllegalArgumentException: No implementation of method: :make-reader of protocol: #'clojure.java.io/IOFactory found for class: nil
	at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:544)
	at clojure.java.io$fn__8628$G__8610__8635.invoke(io.clj:69)
	at clojure.java.io$reader.doInvoke(io.clj:102)
	at clojure.lang.RestFn.invoke(RestFn.java:410)
	at cljs.analyzer$forms_seq.invoke(analyzer.clj:1957)
	at cljs.analyzer$parse_ns$fn__1485.invoke(analyzer.clj:2011)
	at cljs.analyzer$parse_ns.invoke(analyzer.clj:1998)
	at cljs.analyzer$parse_ns.invoke(analyzer.clj:1989)
	at cljs.closure$src_file__GT_target_file.invoke(closure.clj:1580)
	at cljs.closure$src_file__GT_target_file.invoke(closure.clj:1575)
	at cljs.repl$load_file.invoke(repl.clj:467)
	at cljs.repl$fn__3938$self__3940.invoke(repl.clj:540)
	at cljs.repl$repl_STAR_$read_eval_print__4004.invoke(repl.clj:745)
	at cljs.repl$repl_STAR_$fn__4010$fn__4017.invoke(repl.clj:785)
	at cljs.repl$repl_STAR_$fn__4010.invoke(repl.clj:784)
	at cljs.compiler$with_core_cljs.invoke(compiler.clj:950)
	at cljs.repl$repl_STAR_.invoke(repl.clj:749)
	at cljs.repl$repl.doInvoke(repl.clj:866)
	at clojure.lang.RestFn.invoke(RestFn.java:439)
	at user$eval30.invoke(repl.clj:10)
	at clojure.lang.Compiler.eval(Compiler.java:6703)
	at clojure.lang.Compiler.load(Compiler.java:7130)
	at clojure.lang.Compiler.loadFile(Compiler.java:7086)
	at clojure.main$load_script.invoke(main.clj:274)
	at clojure.main$script_opt.invoke(main.clj:336)
	at clojure.main$main.doInvoke(main.clj:420)
	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)
ClojureScript:cljs.user> (require 'foo.bar)
nil
ClojureScript:cljs.user> (ns-interns 'foo.bar)
{six #'foo.bar/six, two! #'foo.bar/two!, one #'foo.bar/one, eight #'foo.bar/eight, five' #'foo.bar/five', four #'foo.bar/four, nine #'foo.bar/nine, seven #'foo.bar/seven, three* #'foo.bar/three*}


 Comments   
Comment by Mike Fikes [ 20/Mar/15 9:37 PM ]

I'm not familiar with the way load-file is supposed work. I used the fully-qualified path, because that's what I saw Cursive do. I tried a path relative to the source directory, and this does't balk, but doesn't work either:

ClojureScript:cljs.user> (load-file "foo/bar.cljs")
nil
ClojureScript:cljs.user> (ns-interns 'foo.bar)
{}
Comment by Mike Fikes [ 20/Mar/15 9:40 PM ]

(I apologize for the ticket noise.)

The relative path does work in that the symbols are loaded into the browser JavaScript engine, while ns-interns is not updated:

orion:hello_world mfikes$ rlwrap java -cp cljs.jar:src clojure.main repl.clj
Compiling client js ...
Waiting for browser to connect ...
To quit, type: :cljs/quit
ClojureScript:cljs.user> (foo.bar/nine)
WARNING: Use of undeclared Var foo.bar/nine at line 1 <cljs repl>
ReferenceError: foo is not defined
ReferenceError: foo is not defined
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:1:89)
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:9:3)
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:14:4)
    at http://localhost:9000/out/clojure/browser/repl.js:42:267
    at clojure$browser$repl$evaluate_javascript (http://localhost:9000/out/clojure/browser/repl.js:45:4)
    at Object.callback (http://localhost:9000/out/clojure/browser/repl.js:242:169)
    at goog.messaging.AbstractChannel.deliver (http://localhost:9000/out/goog/messaging/abstractchannel.js:142:13)
    at goog.net.xpc.CrossPageChannel.xpcDeliver (http://localhost:9000/out/goog/net/xpc/crosspagechannel.js:733:12)
    at Function.goog.net.xpc.NativeMessagingTransport.messageReceived_ (http://localhost:9000/out/goog/net/xpc/nativemessagingtransport.js:321:13)
    at Object.goog.events.fireListener (http://localhost:9000/out/goog/events/events.js:741:21)
ClojureScript:cljs.user> (load-file "foo/bar.cljs")
nil
ClojureScript:cljs.user> (foo.bar/nine)
WARNING: Use of undeclared Var foo.bar/nine at line 1 <cljs repl>
Error: 1 is not ISeqable
	 cljs$core$seq (out/cljs/core.cljs:951:13)
	 cljs$core$first (out/cljs/core.cljs:960:7)
	 cljs$core$ffirst (out/cljs/core.cljs:1393:3)
	 foo$bar$one (out/foo/bar.cljs:7:14)
	 foo$bar$two_BANG_ (out/foo/bar.cljs:9:15)
	 foo$bar$three_STAR_ (out/foo/bar.cljs:11:17)
	 foo$bar$four (out/foo/bar.cljs:13:15)
	 foo$bar$five_SINGLEQUOTE_ (out/foo/bar.cljs:16:16)
	 foo$bar$six (out/foo/bar.cljs:20:2)
ClojureScript:cljs.user> (ns-interns 'foo.bar)
{}

(The exception thrown from foo.bar/nine is expected... I was testing stacktraces with this namespace earlier.)

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

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

Comment by Mike Fikes [ 22/Mar/15 9:05 AM ]

Confirmed fixed in master.





[CLJS-1152] (require 'some.ns :reload) causes printing to stop working in browser REPL Created: 19/Mar/15  Updated: 21/Mar/15  Resolved: 21/Mar/15

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

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


 Comments   
Comment by David Nolen [ 20/Mar/15 9:06 AM ]

This root cause is that the compiled browser repl JavaScript also gets reloaded. This occurs because we do not have real require and instead use the ns form to simulate it. What happens is that we emit a new ns form with whatever requires were previously present, the new ones, and add :reload or :reload-all. However this will affect all the namespaces instead of only the ones specified by require. Because of auto-building changing the semantics is likely to be surprising for compilation, however aligning the semantics when at the REPL should be fine.

In order to avoid churn on master while we wait for an enhanced Piggieback release we should try to implement the solution in the least invasive as possible way.

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

Reloading is a transient thing so doing this via metadata is probably not a good idea. Probably the simplest thing to do is to always have REPL require reshape the specs into vectors and add metadata to the vector so that analyzer parse 'ns can extract and leverage this information without polluting the persistent compiler environment.

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

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





[CLJS-1157] Stacktrace unmunging will blindly use local symbols Created: 21/Mar/15  Updated: 21/Mar/15  Resolved: 21/Mar/15

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

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

Attachments: Text File CLJS-1157-2.patch     Text File CLJS-1157.patch    

 Description   

With CLJS-1154, the symbol used to call a function is extracted from source maps to use in lieu of a munged name. This leads to undesirable results if the symbol is simply a local.

For example, notice the use of f in call-me:

(ns foo.bar)

(defn this-throws []
  (ffirst 1))

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

(defn tricky []
  (call-me this-throws))

Where previously we would get:

ClojureScript:cljs.user> (foo.bar/tricky)
Error: 1 is not ISeqable
	 cljs$core$seq (.../cljs/core.cljs:951:13)
	 cljs$core$first (.../cljs/core.cljs:960:7)
	 cljs$core$ffirst (.../cljs/core.cljs:1393:3)
	 foo$bar$this_throws (.../foo/bar.cljs:4:3)
	 foo$bar$call_me (.../foo/bar.cljs:7:3)
	 foo$bar$tricky (.../foo/bar.cljs:10:3)
	 (NO_SOURCE_FILE)

we now get:

ClojureScript:cljs.user> (foo.bar/tricky)
Error: 1 is not ISeqable
	 cljs.core/seq (.../cljs/core.cljs:951:20)
	 cljs.core/first (.../cljs/core.cljs:960:16)
	 cljs.core/ffirst (.../cljs/core.cljs:1393:11)
	 f (.../foo/bar.cljs:4:4)
	 foo.bar/call-me (.../foo/bar.cljs:7:4)
	 foo$bar$tricky (.../foo/bar.cljs:10:4)
	 (NO_SOURCE_FILE)


 Comments   
Comment by Mike Fikes [ 21/Mar/15 10:36 AM ]

The attached patch takes a strategy of only replacing munged names if we can munge back to them.

It is a little more complicated in trying to deal with the possibility that, instead of a clean name like call-me, we had call-me$', in which case the unmanaged name would be used.

Below is what the patch would produce with the additional change call-me -> call-me$'. It successfully prevents replacing foo$bar$this_throws with the local symbol f.

ClojureScript:cljs.user> (foo.bar/tricky)
Error: 1 is not ISeqable
	 cljs.core/seq (.../cljs/core.cljs:951:20)
	 cljs.core/first (.../cljs/core.cljs:960:16)
	 cljs.core/ffirst (.../cljs/core.cljs:1393:11)
	 foo$bar$this_throws (.../foo/bar.cljs:4:4)
	 foo.bar/call-me$' (.../foo/bar.cljs:7:4)
	 foo$bar$tricky (.../foo/bar.cljs:10:4)
	 (NO_SOURCE_FILE)
Comment by Mike Fikes [ 21/Mar/15 1:23 PM ]

Attaching a simpler patch that doesn't try to look for $ in unmunaged name. It does't appear to be necessary and, makes things more complex, and would cause a local symbol with a name like f$ to appear in the trace.

Comment by David Nolen [ 21/Mar/15 2:03 PM ]

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





[CLJS-1154] When source-mapping stacktraces, obtain unmunged function names from source map Created: 20/Mar/15  Updated: 21/Mar/15  Resolved: 21/Mar/15

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

Type: Enhancement Priority: Blocker
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None
Environment:

All except for, say Node.js, where source mapping is done by the engine


Attachments: Text File CLJS-1154.patch    

 Description   

With CLJS-937 function symbols in stacktraces ended up being munged (for example cljs.core/first appears as cljs$core$first).

The symbol used when making calls is available in source maps (it is the :name element when read in), and it is possible to use this info to improve the stacktraces by using that symbol where possible (which appears to always be possible except for the top-most element in the trace, where the call site info is not there).



 Comments   
Comment by David Nolen [ 21/Mar/15 7:54 AM ]

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





[CLJS-1155] REPL :watch support does not play nicely with :cljs/quit Created: 20/Mar/15  Updated: 20/Mar/15  Resolved: 20/Mar/15

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

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


 Comments   
Comment by David Nolen [ 20/Mar/15 5:51 PM ]

fixed https://github.com/clojure/clojurescript/commit/501a922a2fd1412503638bedc78a1f5e18b0219c

Comment by Mike Fikes [ 20/Mar/15 6:00 PM ]

Confirmed fixed for me when using browser REPL from Quick Start with :watch "src".





[CLJS-1148] ClojureScript REPL must maintain eval/print pairing Created: 19/Mar/15  Updated: 20/Mar/15  Resolved: 19/Mar/15

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

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


 Description   

Currently the behavior is fine for the standard command line REPLs but pretty broken for anything else. Instead we should adopt the approach of the coming socket REPLs, we should supply a bind-err option which can be set to false to force error printing and other forms of logging to be directed to *err* instead of *out*.

There also a couple of places around the default prompt that should also be fixed.



 Comments   
Comment by Mike Fikes [ 19/Mar/15 7:10 AM ]

One consideration for printed output (even if directed to *err*): it needs to be modeled after print (in contrast to the default of println for :print).

Rationale: this supports evaluating forms that essentially call either print or println, without presuming a newline should be sent to *err*.

The pattern I've used in Ambly is :print-no-newline followed by :flush; perhaps with *err* semantics the :flush isn't necessary.

Comment by David Nolen [ 19/Mar/15 8:09 AM ]

fixed https://github.com/clojure/clojurescript/commit/9e680c425d300f20bd8726993d9835ced560bd87

Comment by David Nolen [ 19/Mar/15 8:09 AM ]

Mike Fikes good point but I think we should surface that issue elsewhere now.





[CLJS-1137] :cljs/quit fails to actually quit Created: 17/Mar/15  Updated: 20/Mar/15  Resolved: 20/Mar/15

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

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

Quick Start Browser REPL (OS X / Safari)



 Description   

If you run through Quick Start through the Browser REPL section (https://github.com/clojure/clojurescript/wiki/Quick-Start#browser-repl), :cljs/quit will hang if a user tries it:

$ rlwrap java -cp cljs.jar:src clojure.main repl.clj
Compiling client js ...
Waiting for browser to connect ...
To quit, type: :cljs/quit
ClojureScript:cljs.user> :cljs/quit

The root problem appears to be agent threads running; here is what a kill -3 shows:

2015-03-17 12:50:25
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.31-b07 mixed mode):

"DestroyJavaVM" #19 prio=5 os_prio=31 tid=0x00007fc9201cf800 nid=0xf07 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"clojure-agent-send-pool-0" #18 prio=5 os_prio=31 tid=0x00007fc9209d8000 nid=0x5e03 waiting on condition [0x0000000129214000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e09bfdf8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007fc91c038800 nid=0x5103 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007fc91b810800 nid=0x4f03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007fc91c822800 nid=0x4d03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007fc91c822000 nid=0x4b03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007fc91c037800 nid=0x4903 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007fc91c03a800 nid=0x3c17 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007fc91c064000 nid=0x3503 in Object.wait() [0x0000000125685000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
	- locked <0x00000006e04631b8> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007fc91c063000 nid=0x3303 in Object.wait() [0x0000000125582000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
	- locked <0x00000006e0184378> (a java.lang.ref.Reference$Lock)

"VM Thread" os_prio=31 tid=0x00007fc91c060800 nid=0x3103 runnable 

"GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007fc91c00e800 nid=0x10f runnable 

"GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007fc91c00f000 nid=0x230f runnable 

"GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007fc91c00f800 nid=0x2503 runnable 

"GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007fc91c010800 nid=0x2703 runnable 

"GC task thread#4 (ParallelGC)" os_prio=31 tid=0x00007fc91c011000 nid=0x2903 runnable 

"GC task thread#5 (ParallelGC)" os_prio=31 tid=0x00007fc91c011800 nid=0x2b03 runnable 

"GC task thread#6 (ParallelGC)" os_prio=31 tid=0x00007fc91c012000 nid=0x2d03 runnable 

"GC task thread#7 (ParallelGC)" os_prio=31 tid=0x00007fc91c013000 nid=0x2f03 runnable 

"VM Periodic Task Thread" os_prio=31 tid=0x00007fc91c07b800 nid=0x5303 waiting on condition 

JNI global references: 76

Heap
 PSYoungGen      total 124928K, used 115712K [0x0000000775580000, 0x000000077d880000, 0x00000007c0000000)
  eden space 115712K, 100% used [0x0000000775580000,0x000000077c680000,0x000000077c680000)
  from space 9216K, 0% used [0x000000077cf80000,0x000000077cf80000,0x000000077d880000)
  to   space 9216K, 0% used [0x000000077c680000,0x000000077c680000,0x000000077cf80000)
 ParOldGen       total 102400K, used 10119K [0x00000006e0000000, 0x00000006e6400000, 0x0000000775580000)
  object space 102400K, 9% used [0x00000006e0000000,0x00000006e09e1dc0,0x00000006e6400000)
 Metaspace       used 21921K, capacity 22079K, committed 22400K, reserved 1067008K
  class space    used 4104K, capacity 4140K, committed 4224K, reserved 1048576K


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

A minor correction:

The thread dump in the description was produced with :watch "src" commented out of my repl.clj. Restoring that to adhere to Quick Start produces the same end result, but with additional non-daemon threads:

2015-03-17 12:53:46
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.31-b07 mixed mode):

"DestroyJavaVM" #20 prio=5 os_prio=31 tid=0x00007fc02f155800 nid=0xf07 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Thread-9" #19 daemon prio=5 os_prio=31 tid=0x00007fc02f155000 nid=0x6503 waiting on condition [0x000000012e3be000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007757e8110> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-pool-0" #18 prio=5 os_prio=31 tid=0x00007fc02a6b5000 nid=0x6303 waiting on condition [0x000000012ed01000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e08f4438> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-6" #17 prio=5 os_prio=31 tid=0x00007fc02e17e000 nid=0x6103 waiting on condition [0x000000012e993000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e0500628> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-5" #16 prio=5 os_prio=31 tid=0x00007fc02bc39800 nid=0x5f03 waiting on condition [0x000000012e890000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007757e75f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:492)
	at java.util.concurrent.LinkedBlockingDeque.take(LinkedBlockingDeque.java:680)
	at sun.nio.fs.AbstractWatchService.take(AbstractWatchService.java:118)
	at cljs.closure$watch.invoke(closure.clj:1533)
	at cljs.closure$watch.invoke(closure.clj:1487)
	at cljs.repl$repl_STAR_$fn__4003$fn__4006.invoke(repl.clj:753)
	at clojure.core$binding_conveyor_fn$fn__4145.invoke(core.clj:1910)
	at clojure.lang.AFn.call(AFn.java:18)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-4" #15 prio=5 os_prio=31 tid=0x00007fc02e125800 nid=0x5d03 waiting on condition [0x000000012e2bb000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e0500628> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-3" #14 prio=5 os_prio=31 tid=0x00007fc02c95e000 nid=0x5b03 waiting on condition [0x000000012de5d000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e0500628> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-2" #13 prio=5 os_prio=31 tid=0x00007fc02e124800 nid=0x5903 waiting on condition [0x000000012dd5a000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e0500628> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-1" #12 prio=5 os_prio=31 tid=0x00007fc02e1e2800 nid=0x5703 waiting on condition [0x000000012dc57000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e0500628> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-0" #11 prio=5 os_prio=31 tid=0x00007fc02c027000 nid=0x5503 waiting on condition [0x000000012ee41000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e0500628> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007fc02b816800 nid=0x5103 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007fc02b800800 nid=0x4f03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007fc029894000 nid=0x4d03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007fc029875000 nid=0x4b03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007fc029887000 nid=0x4903 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007fc029886000 nid=0x3c13 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007fc029873800 nid=0x3503 in Object.wait() [0x000000012add9000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
	- locked <0x00000006e00f7988> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007fc029872800 nid=0x3303 in Object.wait() [0x000000012acd6000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
	- locked <0x00000006e0124b90> (a java.lang.ref.Reference$Lock)

"VM Thread" os_prio=31 tid=0x00007fc029870000 nid=0x3103 runnable 

"GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007fc02981e000 nid=0x10f runnable 

"GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007fc02981e800 nid=0x230f runnable 

"GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007fc02981f000 nid=0x2503 runnable 

"GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007fc02981f800 nid=0x2703 runnable 

"GC task thread#4 (ParallelGC)" os_prio=31 tid=0x00007fc029820800 nid=0x2903 runnable 

"GC task thread#5 (ParallelGC)" os_prio=31 tid=0x00007fc029821000 nid=0x2b03 runnable 

"GC task thread#6 (ParallelGC)" os_prio=31 tid=0x00007fc029821800 nid=0x2d03 runnable 

"GC task thread#7 (ParallelGC)" os_prio=31 tid=0x00007fc029822000 nid=0x2f03 runnable 

"VM Periodic Task Thread" os_prio=31 tid=0x00007fc02b817000 nid=0x5303 waiting on condition 

JNI global references: 92

Heap
 PSYoungGen      total 124928K, used 23388K [0x0000000775580000, 0x0000000781880000, 0x00000007c0000000)
  eden space 115712K, 19% used [0x0000000775580000,0x0000000776b973b8,0x000000077c680000)
  from space 9216K, 8% used [0x000000077c680000,0x000000077c740000,0x000000077cf80000)
  to   space 15872K, 0% used [0x0000000780900000,0x0000000780900000,0x0000000781880000)
 ParOldGen       total 100352K, used 10109K [0x00000006e0000000, 0x00000006e6200000, 0x0000000775580000)
  object space 100352K, 10% used [0x00000006e0000000,0x00000006e09df468,0x00000006e6200000)
 Metaspace       used 22439K, capacity 22609K, committed 22656K, reserved 1067008K
  class space    used 4175K, capacity 4207K, committed 4224K, reserved 1048576K
Comment by Mike Fikes [ 17/Mar/15 12:27 PM ]

It would be interesting if there is a clever solution to this. Ambly is currently using an explicit directive in its start script: https://github.com/omcljs/ambly/blob/master/Clojure/script/jscrepljs#L14 which works (https://github.com/omcljs/ambly/blob/master/Clojure/src/ambly/repl/jsc.clj#L217), but is not suitable for use in environments where a user may already have a REPL running that they'd like :cljs/quit to return to.

Comment by David Nolen [ 20/Mar/15 5:23 PM ]

fixed https://github.com/clojure/clojurescript/commit/6e2c8175b102eb3213dffc84cc44a9b7e1443be4

Comment by Mike Fikes [ 20/Mar/15 5:35 PM ]

Confirmed fixed for me (with no :watch directive).





[CLJS-1153] Typed Array backed PersistentVector based on clojure.core/Vec Created: 19/Mar/15  Updated: 19/Mar/15

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

Type: Enhancement Priority: Major
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-1150] lift cljs.repl/repl cljs.user ns form evalution into default init Created: 19/Mar/15  Updated: 19/Mar/15  Resolved: 19/Mar/15

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

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


 Comments   
Comment by David Nolen [ 19/Mar/15 7:40 AM ]

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





[CLJS-1149] cljs.repl/repl needs to support :compiler-env option Created: 19/Mar/15  Updated: 19/Mar/15  Resolved: 19/Mar/15

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

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


 Comments   
Comment by David Nolen [ 19/Mar/15 7:25 AM ]

fixed https://github.com/clojure/clojurescript/commit/1208fe565b27ec30ac315f3c237b0df3d30a629d





[CLJS-1116] Long cold compile times even under :none Created: 12/Mar/15  Updated: 18/Mar/15  Resolved: 18/Mar/15

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

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


 Description   

Some users have reported long cold compile times even under none. Compiling in dependency order CLJS-1113 will likely help a lot here. Also redundant analysis of files in JARs CLJS-1117.



 Comments   
Comment by David Nolen [ 14/Mar/15 6:18 AM ]

After the fixes to master it's unclear what more can be done in a reasonable amount of time for the next release. For cold builds it is imperative to analyze all dependencies when recompiling a particular file. For example if a file uses core.async it's not enough to analyze just cljs.core.async because the go macro will use cljs.core.asyn.impl nses (which are required by cljs.core.async. These must be analyzed in order to emit correct errors/warnings.

Comment by David Nolen [ 18/Mar/15 5:41 PM ]

the complaints disappeared with https://github.com/clojure/clojurescript/commit/9a276fb84c135e4199929c08f55e8a986efc72b7





[CLJS-1140] typo in cljs.repl/repl, `:need-prompt prompt` instead of `:need-prompt need-prompt` Created: 18/Mar/15  Updated: 18/Mar/15  Resolved: 18/Mar/15

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

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


 Comments   
Comment by David Nolen [ 18/Mar/15 5:40 PM ]

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





[CLJS-1146] REPL regression due to missing wrapping cljs.compiler/with-core-cljs in cljs.repl/repl Created: 18/Mar/15  Updated: 18/Mar/15  Resolved: 18/Mar/15

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

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


 Comments   
Comment by David Nolen [ 18/Mar/15 2:06 PM ]

fixed https://github.com/clojure/clojurescript/commit/9c1230ec912c930239eed1a4ab0b2b22e2ff5964





[CLJS-1143] Build module example from cljs.closure fails with file not found error. Created: 18/Mar/15  Updated: 18/Mar/15  Resolved: 18/Mar/15

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

Type: Defect Priority: Major
Reporter: John Chijioke Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

Running the build-modules example from the comments results in a file not found error when the file does not exist on disk. My expectation is that the whole process should be able to check if the file exists and write it if it doesn't but it fails to do that.

The code:

(build-modules
  [(map->javascript-file
     (ana/parse-ns 'cljs.core (io/file "out/cljs/core.js") nil))
   (map->javascript-file
     (ana/parse-ns 'cljs.reader (io/file "out/cljs/reader.js") nil))]
   {:optimizations  :advanced
    :output-dir     "out"
    :cache-analysis true
    :modules        {:core
                     {:output-to "out/modules/core.js"
                      :entries   '#{cljs.core}}
                     :landing
                     {:output-to  "out/modules/reader.js"
                      :entries    '#{cljs.reader}
                      :depends-on #{:core}}}})

In my case the file "out/cljs/reader.js" does not exist.



 Comments   
Comment by David Nolen [ 18/Mar/15 9:10 AM ]

This is comment code, not official documentation of an API. The failure is in parse-ns which has nothing to do with modules support. That said there's not enough introductory information around :modules. There is a simple task to provide a step by step walk through of :modules support CLJS-1129. Happy to see this taken up by someone.





[CLJS-1132] compile-file analysis pass optimization broken under Closure optimization and :cache-analysis true Created: 16/Mar/15  Updated: 16/Mar/15  Resolved: 16/Mar/15

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

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


 Comments   
Comment by David Nolen [ 16/Mar/15 5:29 PM ]

fixed https://github.com/clojure/clojurescript/commit/7a6ce7f5f680b304a44d20692353abdef68a5592





[CLJS-1131] cljs.closure/add-dependencies needs to be more aggressively set oriented Created: 16/Mar/15  Updated: 16/Mar/15  Resolved: 16/Mar/15

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

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


 Comments   
Comment by David Nolen [ 16/Mar/15 5:34 PM ]

fixed https://github.com/clojure/clojurescript/commit/9a276fb84c135e4199929c08f55e8a986efc72b7





[CLJS-1130] :foreign-libs regression under Closure optimized builds Created: 16/Mar/15  Updated: 16/Mar/15  Resolved: 16/Mar/15

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

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


 Description   

:foreign-libs support has regressed in master



 Comments   
Comment by David Nolen [ 16/Mar/15 12:48 PM ]

fix https://github.com/clojure/clojurescript/commit/d94e6c6e88541b8cd3d559be4281c76bb8c408d9





[CLJS-1126] File are not recompiled when build affecting options changes Created: 16/Mar/15  Updated: 16/Mar/15  Resolved: 16/Mar/15

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

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


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

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





[CLJS-463] Google Closure Class interop form (genclass) Created: 26/Jan/13  Updated: 16/Mar/15  Resolved: 16/Mar/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: 3
Labels: None


 Description   

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



 Comments   
Comment by Tyler Tallman [ 11/May/13 3:06 PM ]

What do you think of this approach based on
based on http://www.50ply.com/blog/2012/07/08/extending-closure-from-clojurescript/

While it may not preserve enough of gen-class's semantics. This would be enough for us to start gradually porting our large GClosure code base to Clojurescript. The code size reduction would be enormous.

sample_use
(ns com.example
  (:require [goog.ui.tree.TreeControl :as TreeControl]))
(gen-class
  :name DemoTree
  :extends goog/ui.tree.TreeControl
  :constructor ([name config]
                 (goog/base (js* "this") name config))
  :methods [[handleKeyEvent [e]
              (goog/base (js* "this") "handleKeyEvent" e)
              ;; my special code to handle the key event
    ]])

here is a untested mock implementation modified from http://www.50ply.com/blog/2012/07/08/extending-closure-from-clojurescript/

I changed constructors to constructor because there can be only one in js

This unfortunately has different semantics from gen-class because the original did not include the definition of the methods and constructor inline. It tried to read the Clojure gen-class source,but I still do not yet understand how the :prefix grabbing of functions from the current namespace works from within a macro.

For Google Closure interop each class should have its own provide

dryrun_for_gen-class
(defmacro gen-class [{new-type :name base-type :extends ctor :constructor methods :methods}]
  `(do
     ;(goog/provide ~@(str *ns* "." new-type)) 
     (defn ~new-type ~@ctor)

     (goog/inherits ~type ~base-type)

     ~@(map
        (fn [method]
          `(set! (.. ~type -prototype ~(to-property (first method)))
                 (fn ~@(rest method))))
        methods)))
Comment by David Nolen [ 16/Mar/15 6:30 AM ]

Out of scope.





[CLJS-433] Throw error when user tries to use wrong syntax for multiple arity functions in extend-type Created: 29/Nov/12  Updated: 16/Mar/15  Resolved: 16/Mar/15

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

Type: Enhancement Priority: Minor
Reporter: Max Penet Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

Right now it allows to mix declarations, sometimes allowing an illegal syntax (-nth shouldn't be allowed in the following example)

example from jayq:

(extend-type js/jQuery

  IIndexed
  (-nth [this n] ...)
  (-nth [this n not-found] ...)

  ILookup
  (-lookup
    ([this k] ...)
    ([this k not-found] ...))

It already throws an error with some protocols such as IFn, but not for all of them.



 Comments   
Comment by David Nolen [ 16/Mar/15 6:29 AM ]

fixed by CLJS-667





[CLJS-327] Backend agnostic repl infrastructure Created: 25/Jun/12  Updated: 16/Mar/15  Resolved: 16/Mar/15

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

Type: Enhancement Priority: Minor
Reporter: Raphaël AMIARD Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None

Attachments: Text File backend-agnostic-repl.patch    
Patch: Code

 Description   

This enhancement is about changing some names and docs in the repl infrastructure, so that it is backend agnostic.

The code is already backend agnostic, so the only changes that were needed are about references to Javascript.



 Comments   
Comment by David Nolen [ 26/Jun/12 11:34 AM ]

Thanks! Did you verify that browser REPL continues to function properly?

Comment by David Nolen [ 16/Mar/15 6:25 AM ]

Out of scope.





[CLJS-299] PersistentVector push-tail, do-assoc, pop-tail should not contain recursive calls Created: 04/Jun/12  Updated: 16/Mar/15  Resolved: 16/Mar/15

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

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: Michał Marczyk
Resolution: Declined Votes: 0
Labels: None

Attachments: Text File 0001-CLJS-299-eliminate-recursive-calls-in-PV-s-push-tail.patch     Text File 0001-CLJS-299-eliminate-recursive-calls-in-PV-s-push-tail.patch    

 Description   

This prevents V8 inlining. Lazlo's earlier experiments seemed to suggest ~30% gain.



 Comments   
Comment by Michał Marczyk [ 15/Aug/12 6:17 AM ]

Here's a patch which eliminates recursion in all the fns mentioned in the ticket name.

I haven't done much in the way of measuring the impact on perf; a naive benchmark of (assoc huge-vector 123 :foo) seems to indicate a modest perf gain (a few percent shaved off the runtime).

Note that whether pop-tail as implemented in this patch is an improvement over the previous version is not that clear, since it needs to precalculate the level at which the main loop should terminate. Careful measurements will be necessary. (I wouldn't be surprised if the difference turned out to be unmeasurable, in which case I guess we needn't bother with the change.)

push-tail and do-assoc have no such problems – all the work being done needs to be done (and is now done in a non-recursive fashion).

Hm... Actually that probably means this patch should be split in two (pop-tail & rest). I'll get around to that soon.

More importantly, some benchmarks for large data structures should be added (assoc / conj of 32 items (at any rate, a large enough number of items for the tail to be pushed in) / repeated pops (again, enough to pop the tail)). ("Large" here means "large enough for the shift of the vector to grow at least to 10", meaning size > 1024 + 32; shift 15 would be better, requiring size > 32768 + 32.)

Comment by David Nolen [ 17/Aug/12 12:36 AM ]

Awesome! Lets split the patch in two.

Comment by Michał Marczyk [ 17/Aug/12 4:23 AM ]

Ok. Here's a new patch which eliminates recursion in push-tail and do-assoc. I guess the large data structure benchmarks should probably get in first – see CLJS-357 (some benchmarks already attached – could use some scrutiny in case they're not exercising what they should be; initial runs indicate a very modest speedup).

I'll give pop-tail a little more thought and write a new patch for it sometime soon too. (Perhaps worth pointing out is that the zlvl precalculation in the current version of the pop-tail patch doesn't need to traverse any nodes – it's all bit twiddling – so it should be pretty cheap... I guess we'll see what the benchmarks say – I haven't actually ran them on this code yet.)

Comment by David Nolen [ 29/Aug/12 8:44 PM ]

So how did the benchmarks turn out for these?

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

I applied and ran these benchmarks using the lasted V8. These don't seem to make any difference. Perhaps V8 no longer has issues with the recursive cases? I didn't test beyond running the benchmark script. Might be worth getting something up on JSPerf.

Comment by David Nolen [ 16/Mar/15 6:25 AM ]

I think this ticket is pretty moot these days.





[CLJS-287] Allow extending 'set-options' for Closure Compiler Created: 31/May/12  Updated: 16/Mar/15  Resolved: 16/Mar/15

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

Type: Enhancement Priority: Minor
Reporter: Sergei Lebedev Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

Currently, ClojureScript only exposes a limited set of options to the API users. Would be nice to have a way of extending cljs.clojure/set-options to handle arbitrary options, like --define (which is already covered in CLJS-77).



 Comments   
Comment by David Nolen [ 16/Mar/15 6:24 AM ]

Not going to do this one.





[CLJS-270] Warn if ISeq is implemented and ISeqable and ICollection are not Created: 24/May/12  Updated: 16/Mar/15  Resolved: 16/Mar/15

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

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


 Comments   
Comment by David Nolen [ 16/Mar/15 6:23 AM ]

This issue is too specific.





[CLJS-1123] this-as unexpectedly binds js/window when used within function with post-condition Created: 15/Mar/15  Updated: 16/Mar/15

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

Type: Defect Priority: Minor
Reporter: Joshua Choi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Adding a post-condition to any function that uses cljs.core/this-as will unexpectedly cause this-as's "this" symbol to be bound to the root object (e.g., js/window) instead.

(defn f-no-post-condition [argument]
  (this-as this
    (js/console.log argument this)))

(defn f-with-post-condition [argument]
  {:post [true]}
  (this-as this
    (js/console.log argument this)))

(def test-object
  #js {:methodNoPostcondition f-no-post-condition
       :methodWithPostcondition f-with-post-condition})

(f-with-post-condition "A") ; Correctly prints js/window
(.methodNoPostcondition test-object "B") ; Correctly prints test-object
(.methodWithPostcondition test-object "C") ; Incorrectly prints js/window


 Comments   
Comment by David Nolen [ 16/Mar/15 6:17 AM ]

This is almost certainly a different manifestation of CLJS-719.

Comment by Thomas Heller [ 16/Mar/15 6:21 AM ]

Just looked at the generated javascript. As David mentioned the problem is the extra function generated to get the result for the :post condition.

dummy.f_no_post_condition = (function f_no_post_condition(argument){
var this$ = this;
var G__82157 = argument;
var G__82158 = this$;
return console.log(G__82157,G__82158);
});
dummy.f_with_post_condition = (function f_with_post_condition(argument){
var _PERCENT_ = (function (){var this$ = this;
var G__82161 = argument;
var G__82162 = this$;
return console.log(G__82161,G__82162);
})();


return _PERCENT_;
});
dummy.test_object = {"methodWithPostcondition": dummy.f_with_post_condition, "methodNoPostcondition": dummy.f_no_post_condition};
dummy.f_with_post_condition("A");
dummy.test_object.methodNoPostcondition("B");
dummy.test_object.methodWithPostcondition("C");




[CLJS-1122] The "print" REPL option is called with multiple arguments instead of only one. Created: 14/Mar/15  Updated: 15/Mar/15  Resolved: 15/Mar/15

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

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


 Description   

The cljs.repl/repl* function calls the "print" function with multiple arguments. It should always call it with only one argument.



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

The behavior is the same as clojure.main/repl which uses prn which accepts multiple arguments.

Comment by grosjean [ 15/Mar/15 3:17 PM ]

Sorry to insist, but the docstring says : "- :print, function of one argument, prints its argument to the output
default: println". Whether the docstring must be changed or prn must be called with 1 argument.





[CLJS-891] Defs in "parent" namespaces clash with "child" namespaces with the same name? Created: 28/Nov/14  Updated: 15/Mar/15  Resolved: 14/Mar/15

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

Type: Defect Priority: Major
Reporter: Russell Dunphy Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bug, namespace
Environment:

Clojurescript 0.0-2371, OSX



 Description   

This has had me totally flummoxed for a few hours, but I have finally been able to create a minimal project replicating the problem based on the mies template: https://github.com/rsslldnphy/cljs-ns-issue.

The problem seems to happen when a "parent" namespace, for example `my-project.foo`, contains a def with the same name as a "child" namespace, eg if there is a namespace `my-project.foo.bar`, and a def named `bar` in `my-project.foo`, and both those namespaces are required by `my-project.core`, then calling functions in `my-project.foo.bar` ends up with an Uncaught TypeError: Cannot read property 'call' of undefined. Sometimes, depending on which ns requires which, I've also seen an Uncaught Error: Namespace "cljs_ns_issue.foo.bar" already declared.

I don't think I'm doing a particularly good job of explaining this so it might be easier to look at the code. The crux is: comment out this line and the code works, leave it in and you get an error.



 Comments   
Comment by Francis Avila [ 28/Nov/14 2:01 PM ]

Clojurescript implements namespaces with Google Closure compiler's require/provide system. Unfortunately that system does not have a hard distinction between names and namespaces like Clojure does but instead is more like a sloppy java classname. The crux of it is that vars and namespaces occupy the same tree of js objects and thus their names may not overlap.

Compare the cljs on the left with the emitted javascript (This isn't exactly what is happening, but only in essence):

(ns my-project.foo ; goog.provide('my_project.foo') // something like window.my_project = {foo: {}}
  (:require my-project.foo.bar)) //goog.require('my_project.foo.bar')

;; the "require" evaluates the other namespace, which sets
;; // window.my_project.foo = {bar:{}};
;; // my_project.foo.bar.baz = "some var in the bar ns";
;; Now window.my_project.foo.bar = {baz: "some var in the bar ns"};

(defn bar [] 1)         ; my_project.foo.bar = (function bar(){return 1;});
;; Now the js object that was the bar namespace is gone, replaced with this function.

(my-project.foo.bar/baz)
; my_project.foo.bar.baz.call() // Uncaught TypeError: Cannot read property 'call' of undefined.

;; Alternatively, if (ns my-project.foo.bar) got evaluated *after* my-project.foo namespace was
;; evaluated, then my-project.foo/bar is defined, and the emitted goog.provide('my-project.foo.bar')
;; throws "Uncaught Error: Namespace "my_project.foo.bar" already declared".

So basically this is a leaky abstraction. In Clojurescript, you cannot define a var whose ns-qualified name matches that of another namespace: the slash between name and namespace is not real.

I think the only possible things that can be done are either:

  • Warn at compile-time if a var and a namespace object-path clash. Obviously there may still be runtime-created vars.
  • Put namespace vars behind some magic name. E.g. (ns foo.bar)(def baz 1) becomes goog.provide('foo.bar.__NS__'); foo.bar.__NS__.baz = 1; This would significantly uglify cljs names exported to js (and break existing code), and the magic name could never be used as a var name.
Comment by David Nolen [ 02/Dec/14 6:07 AM ]

We actually already have some logic for this in place, we track namespace segments for this reason. This is a different manifestation of it than previously encountered. I think any further workarounds are likely more trouble than they are worth (debugging complications) - probably the best thing to do is report a warning if we detect a clash.

Comment by David Nolen [ 14/Mar/15 9:03 AM ]

fixed https://github.com/clojure/clojurescript/commit/68894f00c8bd281e4b8366fe335c98fa3e4a067c





[CLJS-1043] top-level locals issues Created: 16/Feb/15  Updated: 15/Mar/15  Resolved: 15/Mar/15

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

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


 Description   
(let [x #js {"Foo" #js {"Bar" (fn [])}}
      y (new x.Foo.Bar.)])

x will get renamed and not considered a local. This seems like a fundamental problem with whatever top level let special casing we may have in place.



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

http://dev.clojure.org/jira/browse/CLJS-693





[CLJS-1085] Allow to pass test environment to cljs.test/run-all-tests Created: 06/Mar/15  Updated: 15/Mar/15  Resolved: 15/Mar/15

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

Type: Enhancement Priority: Major
Reporter: Kimmo Koskinen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

Now run-all-tests internally uses run-all-tests. Allowing to pass a custom env (like with run-tests, would allow to use a custom reporter and still be able to select which tests to run with a regex.



 Comments   
Comment by Kimmo Koskinen [ 12/Mar/15 12:37 AM ]

Oops: s/internally uses run-all-tests/internally uses (cljs.test/empty-env)/.

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

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





[CLJS-867] extend-type with Object methods requires multi-arity style definition Created: 02/Oct/14  Updated: 15/Mar/15  Resolved: 15/Mar/15

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

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


 Description   
Object
(foo [] ...)

Throws an `nth not supported on this type: Symbol` exception.

Object
(foo ([] ...))

Is required even though this is not true for protocol implementations.



 Comments   
Comment by David Nolen [ 15/Mar/15 9:07 AM ]

Not specific to specify true for anything that uses extend-type.

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

fixed https://github.com/clojure/clojurescript/commit/29655a20f31a692e7feb45988a0c28b77ae74cf8





[CLJS-667] validate extend-type and extend-protocol shape Created: 07/Nov/13  Updated: 15/Mar/15  Resolved: 15/Mar/15

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

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


 Description   

deftype and defrecord are sugar over the extend-type grouping, this is a source of confusion we should signal an error/warning if extend-type / extend-protocol malformed.



 Comments   
Comment by David Nolen [ 15/Mar/15 9:01 AM ]

fixed https://github.com/clojure/clojurescript/commit/42c6930e65444ee066d5d77a96f1207bafe70147





[CLJS-806] support ^:const Created: 09/May/14  Updated: 14/Mar/15  Resolved: 14/Mar/15

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

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

Attachments: Text File cljs_806.patch     Text File cljs_806v2.patch    
Patch: Code and Test

 Description   

Currently def's do not support ^:const annotations, this is useful in conjunction with case.



 Comments   
Comment by Peter Schuck [ 17/Dec/14 4:53 PM ]

def's marked with ^:const are now treated as constants, they can't be redefined or set to a different value. Currently only case takes advantage of this. Additionally the emitted var is annotated as a constant for the closure compiler.

Comment by David Nolen [ 14/Mar/15 9:30 AM ]

This patch looks good can we get one rebased to master? Thanks!

Comment by Peter Schuck [ 14/Mar/15 2:05 PM ]

Patch rebased to master.

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

fixed https://github.com/clojure/clojurescript/commit/9a1fae97246a4f3acc9f70cbe51037d8331239cf





[CLJS-1118] cljs.repl/doc support for protocols Created: 13/Mar/15  Updated: 14/Mar/15  Resolved: 14/Mar/15

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

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


 Description   

Protocols do not include doc information at all. We should have special doc printing for protocols.



 Comments   
Comment by David Nolen [ 14/Mar/15 1:24 PM ]

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





[CLJS-889] 2 characters not supported in re-pattern: \u2028 \u2029 Created: 18/Nov/14  Updated: 14/Mar/15  Resolved: 14/Mar/15

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

Type: Defect Priority: Major
Reporter: Dave Sann Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None
Environment:

[org.clojure/clojurescript "0.0-2371"]
ubuntu


Attachments: Text File 0001-re-pattern-works-on-strings-containing-u2028-or-u202.patch     Text File 889.patch    

 Description   

The following 2 patterns

(re-pattern "[\u2028]")
(re-pattern "[\u2029]")

Cause:

SyntaxError: Invalid regular expression: missing terminating ] for character class

They are probably somewhat rare characters in practice.

http://www.fileformat.info/info/unicode/char/2028/index.htm
http://www.fileformat.info/info/unicode/char/2029/index.htm



 Comments   
Comment by Alex Dowad [ 18/Dec/14 1:51 PM ]

The problem is that re-pattern uses a (.*) regexp to pick out the "pattern" portion of a regexp string (separate from the "flags" portion), and "." doesn't match \u2028 and \u2029.

Comment by Alex Dowad [ 18/Dec/14 2:15 PM ]

Sorry, JIRA's helpful formatting mangled that patch. Here it is again.

Comment by Alex Dowad [ 26/Dec/14 1:31 AM ]

Here is a fixed version of the patch, tested on V8, Nashorn, and Spidermonkey. It includes a regression test.

Comment by David Nolen [ 14/Mar/15 12:08 PM ]

fixed https://github.com/clojure/clojurescript/commit/804946988ed0f9787b40f6464ade88c71ad8b13e





[CLJS-799] Having a namespace end with ".cljs" produces wrong source map Created: 16/Apr/14  Updated: 14/Mar/15  Resolved: 14/Mar/15

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

Type: Defect Priority: Major
Reporter: Sven Richter Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: maps, namespace, source
Environment:

Windows 7
JDK 1.7
CLJS version: 0.0-2138 and 0.0-2156 (probably hits other versions too, but I only tested these two)



 Description   

When an clojurescript namespaces ends with ".cljs" I cannot see the source file in google chrome.
Repro steps:

1. Create a new luminus project with: lein new luminus cljsbug +cljs +http-kit
2. Change the project.clj cljsbuild -> compiler setting to:

:compiler
{:output-to "resources/public/js/site.js"
:output-dir "resources/public/js/out"
:optimizations :none
:source-map true
}

3. Change cljsexample.html file to:

<script type="text/javascript" src="js/out/goog/base.js"></script>
<script type="text/javascript" src="{{servlet-context}}/js/site.js"></script>
<script type="text/javascript">goog.require("cljsbug.main");</script>

4. Now start the server with "lein run -dev" and "lein cljsbuild auto"
5. Open localhost:3000/cljsexample
6. Check for the source file in google chrome

It should be there now and correct.
Now to reproduce the problem do this:

7. Change the namespace of the main.cljs file to: ns cljsbug.main.cljs
8. Change the cljsexample.html goog.require line to:

<script type="text/javascript">goog.require("cljsbug.main.cljs");</script>

9. Restart the cljsbuild with: lein do cljsbuild clean, cljsbuild auto
10. Reload the /cljsexample page in google chrome and the source mapping wont be there anymore.



 Comments   
Comment by Sven Richter [ 16/Apr/14 2:38 PM ]

Just to clear things up. Steps 1 to 6 are not needed to reproduce the problem. It is sufficient to go through steps 7 to 10 on any project that uses a similar cljsbuild setting.
It is important that optimizations are set to :none.

Short repro version.

1. Have cljs project with the following settings:
:compiler
{:output-to "resources/public/js/site.js"
:output-dir "resources/public/js/out"
:optimizations :none
:source-map true
}

2. Change any cljs file namespace and add ".cljs" to the namespace.
3. Have the new namespace required in the html file by google like this: goog.require("cljsbug.main.cljs")

4. Open a page in the browser and see that the source maps are missing.

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

A patch for this is welcome!

Comment by David Nolen [ 14/Mar/15 11:54 AM ]

Cannot reproduce this on master using the compiler directly. If you can reproduce using only the instructions given in the Quick Start please feel free to reopen this one.





[CLJS-109] Compiler errors/warnings should be displayed when cljs namespace 'package' names start with an unacceptable javascript symbol. Created: 29/Nov/11  Updated: 14/Mar/15  Resolved: 14/Mar/15

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

Type: Defect Priority: Major
Reporter: Benjamin Conlan Assignee: Unassigned
Resolution: Completed Votes: 1
Labels: None
Environment:

OSX 10.7



 Description   

Clojurescript namespaces are extremely flexible. The generated javascript symbol names are not. ie:

cljs:
[code]
(ns canvas.context.2d)

(defn ^:export create-image-data
([canvas image-data] (.createImageData image-data))
([canvas sw sh] (.createImageData canvas sw sh)))
[/code]

generated js:
[code]
goog.provide('canvas.context.2d');
goog.require('cljs.core');
canvas.context.2d.create_image_data = (function() {
var create_image_data = null;
var create_image_data__2432 = (function (canvas,image_data){ return image_data.createImageData(); });
var create_image_data__2433 = (function (canvas,sw,sh){ return canvas.createImageData(sw,sh); });
create_image_data = function(canvas,sw,sh){
switch(arguments.length){ case 2 : return create_image_data__2432.call(this,canvas,sw); case 3 : return create_image_data__2433.call(this,canvas,sw,sh); }
throw('Invalid arity: ' + arguments.length);
};
return create_image_data;
})()
;
goog.exportSymbol('canvas.context.2d.create_image_data', canvas.context.2d.create_image_data);[/code]

Note the symbol name "canvas.context.2d.create_image_data". Because of the "2d" namespace name, the javascript generated is invalid.

This can simply be resolved by renaming the namespace but some notification to the developer during the compilation stage should help avoid unnecessary problems.



 Comments   
Comment by Jozef Wagner [ 09/Jan/12 2:59 PM ]

I had a similar problem when my namespace contained a word class, e.g. in namespace:

(ns foo.bar.class)

Advanced closure compiler produced an error treating class as a JS keyword.

Comment by David Nolen [ 14/Mar/15 11:30 AM ]

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





[CLJS-904] timeout in start-evaluator is too short Created: 10/Dec/14  Updated: 14/Mar/15  Resolved: 14/Mar/15

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

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


 Description   

The timeout specified in cljs.browser.repl/start-evaluator is too short.
https://github.com/clojure/clojurescript/b