<< Back to previous view

[CLJS-1595] Update Closure Compiler to v20160208 Created: 29/Feb/16  Updated: 23/Apr/16  Resolved: 23/Apr/16

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

Type: Task Priority: Trivial
Reporter: Michael Zhou Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: clojurescript

Attachments: Text File update-closure-compiler-v20160208.patch    

 Description   

Now that Closure Cmopiler v20160208 has been pushed to Maven Central, update to that version.



 Comments   
Comment by Linus Ericsson [ 29/Feb/16 12:06 PM ]

Success report:

I applied update-closure-compiler-v20160208.patch to f58dcdf4 (22 feb) and successfully built clojurescript.

I added the resulting [org.clojure/clojurescript "1.8.28"] to a non-trivial reagent/figwheel based project.clj and updated its closure dependency as well.

I managed to start the repl and everything seem to work fine, these warnings are shown after upgrading clojurescript:

WARNING: Unknown option ':compiler-env'.
WARNING: Unknown option ':special-fns'.
WARNING: Unknown option ':warn-on-undeclared'.

I have not read all the changes to ClojureScript and therefore assume this is just some regression for changed compiler options.

$lein figwheel
Figwheel: Starting server at http://localhost:3449
Figwheel: Watching build - dev
Compiling "resources/public/js/compiled/frontlyft.js" from ["src" "../delat_src"]...
Successfully compiled "resources/public/js/compiled/frontlyft.js" in 1.693 seconds.
Figwheel: Starting CSS Watcher for paths ["resources/public/css"]
Launching ClojureScript REPL for build: dev
Figwheel Controls:
(stop-autobuild) ;; stops Figwheel autobuilder
(start-autobuild [id ...]) ;; starts autobuilder focused on optional ids
(switch-to-build id ...) ;; switches autobuilder to different build
(reset-autobuild) ;; stops, cleans, and starts autobuilder
(reload-config) ;; reloads build config and resets autobuild
(build-once [id ...]) ;; builds source one time
(clean-builds [id ..]) ;; deletes compiled cljs target files
(print-config [id ...]) ;; prints out build configurations
(fig-status) ;; displays current state of system
Switch REPL build focus:
:cljs/quit ;; allows you to switch REPL to another build
Docs: (doc function-name-here)
Exit: Control+C or :cljs/quit
Results: Stored in vars *1, *2, *3, *e holds last exception object
Prompt will show when Figwheel connects to your application
WARNING: Unknown option ':compiler-env'.
WARNING: Unknown option ':special-fns'.
WARNING: Unknown option ':warn-on-undeclared'.
To quit, type: :cljs/quit

These are the dependencies

:dependencies [[org.clojure/clojure "1.8.0"]
[org.clojure/clojurescript "1.8.28"]
[org.clojure/core.async "0.2.374"]
[reagent "0.5.1"]
[timothypratley/reanimated "0.1.4"]
[cljsjs/react "0.14.3-0"]
[com.andrewmcveigh/cljs-time "0.4.0"]
[com.google.javascript/closure-compiler "v20160208"]
[datascript "0.15.0"]
[cljs-http "0.1.39"]
[secretary "1.2.3" :exclusion [org.clojure/clojurescript]]]

:plugins [[lein-cljsbuild "1.1.2" :exclusion [org.clojure/clojure]]
[lein-figwheel "0.5.0-6"]]

Comment by Michael Zhou [ 23/Mar/16 4:12 PM ]

Is there an update on this?

Comment by David Nolen [ 23/Apr/16 3:51 PM ]

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

Comment by Michael Zhou [ 23/Apr/16 4:19 PM ]

Thanks!





[CLJS-1771] Add helper for converting ex-info to js/Error Created: 02/Sep/16  Updated: 02/Sep/16

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

Type: Enhancement Priority: Trivial
Reporter: Artem Yarulin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: ex-info


 Description   

ex-info/ex-data/ex-message didn't get a lot of attention in CLJS community, still I find quiet often (js/Error. "Err"). I guess the main reason is that we cannot pass ex-info object back to JS world, clj->js doesn't work in this case. We can solve it by adding helper like ex->js which will convert ex-info backward to js/Error.

What do you think about such enhancement? I can add patch later if you would find it useful






[CLJS-1962] Quick start guide unnecessarily uses rlwrap to run commands Created: 28/Feb/17  Updated: 16/Jun/17  Resolved: 16/Jun/17

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

Type: Defect Priority: Trivial
Reporter: Jeff Younker Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: documentation
Environment:

Quick start guild



 Description   

At least one example command in the quick start guide uses rlwrap. The command rlwrap is unnecessary to run the command, and it is not installed on all systems (e.g. windows or OSX). This creates an unnecessary stumbling block on these systems, so rlwrap should be removed from the examples in the guide.



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

This issue should be moved over the clojurescript-site and I believe it has already been resolved there.





[CLJS-1785] Warn on reference to js/foo shadowed by local binding Created: 21/Sep/16  Updated: 29/Jan/19  Resolved: 23/Sep/16

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

Type: Enhancement Priority: Trivial
Reporter: Trevor Schmidt Assignee: David Nolen
Resolution: Completed Votes: 1
Labels: None
Environment:

OS X



 Description   

When a local binding shadows a JS global, and an attempt is made to access said global with js/foo, it would be nice to get a warning indicating that the global is inaccessible.

Example:

(defn simple-repro []
  (let [location (str js/location.pathname)]
    location))

Per discussion in Clojurians Slack, this is the same issue as http://dev.clojure.org/jira/browse/CLJS-833.

The previous issue was closed because the suggested solution was inadequate, but per discussion it seems appropriate to provide a warning so it is less surprising.



 Comments   
Comment by David Nolen [ 23/Sep/16 1:31 PM ]

fixed https://github.com/clojure/clojurescript/commit/00e46feb03e7c4e7784f6b0759762d537ea1daaa

Comment by Dan Johansson [ 29/Jan/19 8:03 AM ]

Testing this on ClojureScript 1.10.439 only gives me warnings in the letfn case

cljs.user=> (letfn [(parseInt [s] (js/parseInt s))] (parseInt "123"))
WARNING: js/parseInt is shadowed by a local at line 1 <cljs repl>
RangeError: Maximum call stack size exceeded

cljs.user=> (let [parseInt (fn [s] (js/parseInt s))] (parseInt "123"))
RangeError: Maximum call stack size exceeded





[CLJS-1687] Self-host: cljs.spec: inst-in-range? and int-in-range? need qualification Created: 20/Jun/16  Updated: 20/Jun/16  Resolved: 20/Jun/16

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

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

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

 Description   

The runtime fns ints-in-range? and int-in-range? need to be qualified for self-host. (Otherwise they resolve to the $macros pseudo-namespace.



 Comments   
Comment by David Nolen [ 20/Jun/16 4:29 PM ]

fixed https://github.com/clojure/clojurescript/commit/416f322c25624b042e63e64a0754d5aaf48e552e





[CLJS-1704] destructuring maps in protocol method signatures cause runtime values to be replaced with the destructuring map literal Created: 10/Jul/16  Updated: 11/Jul/16  Resolved: 11/Jul/16

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

Type: Defect Priority: Minor
Reporter: Bert Muthalaly Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug
Environment:

Can be reproduced with the clojurescript Quick Start jar and the code below.



 Description   

(defprotocol P
(f [this {:keys [x]}]))

(defrecord R []
P
(f [this m] m))

(f (R.) {:hello "world"}) ;; => {:keys [:hello]}

We should get the same map as output as we used as input - instead, we get the destructuring map literal.

The above code works as expected in a bare Clojure 1.8 REPL.



 Comments   
Comment by Bert Muthalaly [ 10/Jul/16 1:39 PM ]

Oh, I think I understand what's happening here.

We unconditionally splice the method signature of the protocol into the generated call to (. this <slot> ~@sig), so defn correctly destructures the map, but the invocation of the method macroexpands to (. this cljs$user$P$mtd$arity$2 this {:keys [x]}).

Can be reproduced with

(cljs.pprint/pprint (macroexpand-1 '(defprotocol P (mtd [this {:keys [x]}]))))

at a bare ClojureScript REPL.

My original rationale for supporting this was for protocol readability.

It is sometimes useful to approximate named arguments in protocol method signatures, especially because keyword arguments are not supported in protocol method signatures due to the fact that keyword destructuring is variadic[0].

If you could write destructuring forms in protocol method signatures (that had no effect), a reader of a protocol method can quickly understand the desired invocation.

Other solutions:

  • Spec the protocol arguments. More robust, but the information is no longer inline with the signature of the protocol method.
  • Document this in the method docstring.
  • Warn that destructuring forms are not supported - solves the problem of the user's map being replaced by the destructuring map at runtime.

[0]: https://groups.google.com/forum/#!topic/clojure/AHfyzXCgvTk

Comment by David Nolen [ 11/Jul/16 4:15 PM ]

It's invalid to use destructuring syntax in defprotocol





[CLJS-1711] Compiler analysis cache issue with regex and Transit Created: 21/Jul/16  Updated: 22/Jul/16  Resolved: 22/Jul/16

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

Type: Defect Priority: Minor
Reporter: Rohit Aggarwal Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None
Environment:

Mac OS X. Bug reproduced on master branch and latest release


Attachments: Text File CLJS-1711.patch    
Patch: Code

 Description   

This issue was reported by Martin Klepsch on Slack.

The following code causes the compiler to throw an error if transit-clj is included as a dependency.

core.cljs
(ns hello-world.core)

(enable-console-print!)

(defn x [{:keys [extract]
          :or {extract #"\w"}}])
build.clj
(require 'cljs.build.api)

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

I used the following command to compile the code:

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

The error stack trace is:

Exception in thread "main" clojure.lang.ExceptionInfo: failed compiling file:src/hello_world/core.cljs {:file #object[java.io.File 0xaed0151 "src/hello_world/core.cljs"]}, compiling:(....build.clj:3:1)
	at clojure.lang.Compiler.load(Compiler.java:7391)
	at clojure.lang.Compiler.loadFile(Compiler.java:7317)
	at clojure.main$load_script.invokeStatic(main.clj:275)
	at clojure.main$script_opt.invokeStatic(main.clj:335)
	at clojure.main$script_opt.invoke(main.clj:330)
	at clojure.main$main.invokeStatic(main.clj:421)
	at clojure.main$main.doInvoke(main.clj:384)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.lang.Var.invoke(Var.java:379)
	at clojure.lang.AFn.applyToHelper(AFn.java:154)
	at clojure.lang.Var.applyTo(Var.java:700)
	at clojure.main.main(main.java:37)
Caused by: clojure.lang.ExceptionInfo: failed compiling file:src/hello_world/core.cljs {:file #object[java.io.File 0xaed0151 "src/hello_world/core.cljs"]}
	at clojure.core$ex_info.invokeStatic(core.clj:4617)
	at cljs.compiler$compile_file$fn__2840.invoke(compiler.cljc:1368)
	at cljs.compiler$compile_file.invokeStatic(compiler.cljc:1338)
	at cljs.closure$compile_file.invokeStatic(closure.clj:471)
	at cljs.closure$fn__3897.invokeStatic(closure.clj:538)
	at cljs.closure$fn__3897.invoke(closure.clj:534)
	at cljs.closure$fn__3839$G__3832__3846.invoke(closure.clj:430)
	at cljs.closure$compile_sources$iter__4008__4012$fn__4013.invoke(closure.clj:870)
	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:688)
	at clojure.core$next__4341.invokeStatic(core.clj:64)
	at clojure.core$dorun.invokeStatic(core.clj:3033)
	at clojure.core$doall.invokeStatic(core.clj:3039)
	at cljs.closure$compile_sources.invokeStatic(closure.clj:867)
	at cljs.closure$build.invokeStatic(closure.clj:1995)
	at cljs.build.api$build.invokeStatic(api.clj:209)
	at cljs.build.api$build.invoke(api.clj:198)
	at cljs.build.api$build.invokeStatic(api.clj:201)
	at cljs.build.api$build.invoke(api.clj:198)
	at user$eval24.invokeStatic(build.clj:3)
	at user$eval24.invoke(build.clj:3)
	at clojure.lang.Compiler.eval(Compiler.java:6927)
	at clojure.lang.Compiler.load(Compiler.java:7379)
	... 11 more
Caused by: java.lang.RuntimeException: java.lang.Exception: Not supported: class java.util.regex.Pattern
	at com.cognitect.transit.impl.WriterFactory$1.write(WriterFactory.java:129)
	at cognitect.transit$write.invokeStatic(transit.clj:149)
	at cognitect.transit$write.invoke(transit.clj:146)
	at cljs.analyzer$write_analysis_cache.invokeStatic(analyzer.cljc:2871)
	at cljs.compiler$emit_source.invokeStatic(compiler.cljc:1268)
	at cljs.compiler$compile_file_STAR_$fn__2817.invoke(compiler.cljc:1287)
	at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1154)
	at cljs.compiler$compile_file_STAR_.invokeStatic(compiler.cljc:1278)
	at cljs.compiler$compile_file$fn__2840.invoke(compiler.cljc:1358)
	... 34 more
Caused by: java.lang.Exception: Not supported: class java.util.regex.Pattern
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:176)
	at com.cognitect.transit.impl.JsonEmitter.emitMap(JsonEmitter.java:158)
	at com.cognitect.transit.impl.AbstractEmitter.emitMap(AbstractEmitter.java:70)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:166)
	at com.cognitect.transit.impl.JsonEmitter.emitMap(JsonEmitter.java:158)
	at com.cognitect.transit.impl.AbstractEmitter.emitMap(AbstractEmitter.java:70)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:166)
	at com.cognitect.transit.impl.AbstractEmitter.emitArray(AbstractEmitter.java:82)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:164)
	at com.cognitect.transit.impl.AbstractEmitter.emitArray(AbstractEmitter.java:87)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:164)
	at com.cognitect.transit.impl.AbstractEmitter.emitTagged(AbstractEmitter.java:34)
	at com.cognitect.transit.impl.AbstractEmitter.emitEncoded(AbstractEmitter.java:59)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:169)
	at com.cognitect.transit.impl.AbstractEmitter.emitArray(AbstractEmitter.java:87)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:164)
	at com.cognitect.transit.impl.AbstractEmitter.emitTagged(AbstractEmitter.java:34)
	at com.cognitect.transit.impl.AbstractEmitter.emitEncoded(AbstractEmitter.java:59)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:169)
	at com.cognitect.transit.impl.JsonEmitter.emitMap(JsonEmitter.java:158)
	at com.cognitect.transit.impl.AbstractEmitter.emitMap(AbstractEmitter.java:70)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:166)
	at com.cognitect.transit.impl.JsonEmitter.emitMap(JsonEmitter.java:158)
	at com.cognitect.transit.impl.AbstractEmitter.emitMap(AbstractEmitter.java:70)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:166)
	at com.cognitect.transit.impl.JsonEmitter.emitMap(JsonEmitter.java:158)
	at com.cognitect.transit.impl.AbstractEmitter.emitMap(AbstractEmitter.java:70)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:166)
	at com.cognitect.transit.impl.JsonEmitter.emitMap(JsonEmitter.java:158)
	at com.cognitect.transit.impl.AbstractEmitter.emitMap(AbstractEmitter.java:70)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:166)
	at com.cognitect.transit.impl.AbstractEmitter.marshalTop(AbstractEmitter.java:193)
	at com.cognitect.transit.impl.JsonEmitter.emit(JsonEmitter.java:28)
	at com.cognitect.transit.impl.WriterFactory$1.write(WriterFactory.java:126)
	... 42 more

It works perfectly fine if the transit dependency is removed.



 Comments   
Comment by Rohit Aggarwal [ 21/Jul/16 2:56 AM ]

A related issue is that for the compiler analysis cache, for edn, the code is using pr-str to output, which handles regular expressions just fine. But AFAIK, a regex isn't a type supported by edn and edn/read-string doesn't work with the string outputted by pr-str.

Not sure what to do with that.

Comment by David Nolen [ 22/Jul/16 7:34 AM ]

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





[CLJS-1682] :foreign-libs with module conversion does not works properly if it is used form deps.cljs Created: 13/Jun/16  Updated: 23/Sep/16  Resolved: 23/Sep/16

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

Type: Defect Priority: Minor
Reporter: Andrey Antukh Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: closure, compiler, foreign-libs
Environment:

Linux, openjdk8


Attachments: Text File CLJS-1682.patch    
Patch: Code

 Description   

When :foreign-libs is used for consume commonjs (or amd) modules from clojurescript using the `deps.cljs` mechanism, an unexpected "internal compiler error" is raised. When the same configuration is attached on the build script, everything works as expected.

Simple way to reproduce that, create sample directory tree:

mkdir tmp;
cd tmp;
mkdir -p src/testapp
mkdir -p src/vendor
touch src/testapp/core.cljs
touch src/vendor/greeter.js

Download the latest compiler or copy the recently build one from master:

wget https://github.com/clojure/clojurescript/releases/download/r1.9.36/cljs.jar

Create the sample cljs file:

;; tmp/src/testapp/core.cljs
(ns testapp.core
  (:require [cljs.nodejs :as nodejs]
            [greeter.core :as g]))

(nodejs/enable-util-print!)

(defn -main
  [& args]
  (println (g/sayHello "Ciri")))

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

Create the sample commonjs module:

"use strict";

exports.sayHello = function(name) {
  return `Hello ${name}!`;
};

Create the build script (that works):

;; tmp/build.clj
(require '[cljs.build.api :as b])

(b/build "src"
 {:main 'testapp.core
  :output-to "out/main.js"
  :output-dir "out"
  :target :nodejs
  :language-in  :ecmascript6
  :language-out :ecmascript5
  :foreign-libs [{:file "vendor/greeter.js"
                  :module-type :commonjs
                  :provides ["greeter.core"]}]
  :verbose true})

And compile this using the following command:

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

This will generate successfully the final artifact that can be successufully executed with node:

node out/main.js
# => "Hello Ciri!"

But, if you remove the `:foreign-libs` from the build script and create a new `src/deps.cljs` file
with the following content:

{:foreign-libs [{:file "vendor/greeter.js"
                 :module-type :commonjs
                 :provides ["greeter.core"]}]}

And try compile it:

$ java -cp cljs.jar:src clojure.main build.clj
Copying jar:file:/home/niwi/tmp/cljs.jar!/cljs/core.cljs to out/cljs/core.cljs
Reading analysis cache for jar:file:/home/niwi/tmp/cljs.jar!/cljs/core.cljs
Compiling out/cljs/core.cljs
Using cached cljs.core out/cljs/core.cljs
Copying jar:file:/home/niwi/tmp/cljs.jar!/cljs/nodejs.cljs to out/cljs/nodejs.cljs
Compiling out/cljs/nodejs.cljs
Compiling src/testapp/core.cljs
Copying jar:file:/home/niwi/tmp/cljs.jar!/cljs/nodejs.cljs to out/cljs/nodejs.cljs
Copying jar:file:/home/niwi/tmp/cljs.jar!/cljs/nodejscli.cljs to out/cljs/nodejscli.cljs
Copying jar:file:/home/niwi/tmp/cljs.jar!/goog/base.js to out/goog/base.js
Copying jar:file:/home/niwi/tmp/cljs.jar!/goog/string/string.js to out/goog/string/string.js
Copying jar:file:/home/niwi/tmp/cljs.jar!/goog/object/object.js to out/goog/object/object.js
Copying jar:file:/home/niwi/tmp/cljs.jar!/goog/string/stringbuffer.js to out/goog/string/stringbuffer.js
Copying jar:file:/home/niwi/tmp/cljs.jar!/goog/debug/error.js to out/goog/debug/error.js
Copying jar:file:/home/niwi/tmp/cljs.jar!/goog/dom/nodetype.js to out/goog/dom/nodetype.js
Copying jar:file:/home/niwi/tmp/cljs.jar!/goog/asserts/asserts.js to out/goog/asserts/asserts.js
Copying jar:file:/home/niwi/tmp/cljs.jar!/goog/array/array.js to out/goog/array/array.js
Copying file:/home/niwi/tmp/src/vendor/greeter.js to out/greeter.js
Exception in thread "main" java.lang.RuntimeException: INTERNAL COMPILER ERROR.
Please report this problem.

null
  Node(SCRIPT): vendor/greeter.js:1:0
[source unknown]
  Parent: NULL, compiling:(/home/niwi/tmp/build.clj:3:1)
        at clojure.lang.Compiler.load(Compiler.java:7391)
        at clojure.lang.Compiler.loadFile(Compiler.java:7317)
        at clojure.main$load_script.invokeStatic(main.clj:275)
        at clojure.main$script_opt.invokeStatic(main.clj:335)
        at clojure.main$script_opt.invoke(main.clj:330)
        at clojure.main$main.invokeStatic(main.clj:421)
        at clojure.main$main.doInvoke(main.clj:384)
        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.lang.RuntimeException: INTERNAL COMPILER ERROR.
Please report this problem.

[...]


 Comments   
Comment by Andrey Antukh [ 13/Jun/16 5:42 AM ]

Also happens with `cljs.jar` build from master.

Comment by Rohit Aggarwal [ 14/Jun/16 5:40 AM ]

[Compiler noob here]

Here is what is causing the issue:

In src/main/clojure/cljs/closure.clj in process-js-modules function, in the first case :foreign-libs is being set in opts and in the second failing case :ups-foreign-libs is being set in opts.

I am investigating the root of this.

Comment by Rohit Aggarwal [ 14/Jun/16 6:11 AM ]

A fix is to that set foreign-libs keyword in opts to a union of both foreign-libs and ups-foreign-libs.

I've verified that it works for both the above given examples. But I don't know enough about the compiler to propose this change.

Comment by Rohit Aggarwal [ 14/Jun/16 10:57 AM ]

Attaching patch with fixes this problem. The patch keeps the two sets of data (ups-foreign-libs, foreign-libs) separate.

I've run all the tests and they pass.

Comment by David Nolen [ 23/Sep/16 2:31 PM ]

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





[CLJS-1820] "No such namespace" warning when referring to JS module namespace without using alias Created: 13/Oct/16  Updated: 30/Oct/16  Resolved: 30/Oct/16

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

Type: Defect Priority: Minor
Reporter: Maria Geller Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1820.patch    

 Description   

Currently, when requiring a JS module it is not possible to refer to it using the original namespace. For example, the following code will result in a warning:

(ns my-calculator.core
  (:require [my.calc]))

(println (my.calc/add 5 5))
WARNING: No such namespace: my.calc, could not locate my/calc.cljs, my/calc.cljc, or Closure namespace "" at line 4 src/my_calculator/core.cljs
WARNING: Use of undeclared Var my.calc/add at line 4 src/my_calculator/core.cljs

And the resulting JavaScript will throw the following error:

Uncaught ReferenceError: my is not defined

However, defining an alias for the JS module and using it works fine, for example:

(ns my-calculator.core
  (:require [my.calc :as calc]))

(println (calc/add 5 5))

Here is a minimal repo to reproduce this problem: https://github.com/mneise/my-calculator.



 Comments   
Comment by Maria Geller [ 27/Oct/16 8:23 PM ]

Added a patch for this.

Since JS modules are loaded using the new name created by the Google Closure compiler during module conversion, we always need to add an alias from the name given in the :provides compiler option to the new name.

Comment by David Nolen [ 30/Oct/16 5:12 AM ]

fixed https://github.com/clojure/clojurescript/commit/1f2c0a922130769a3da398aa501b3621fd1f8cd5





[CLJS-1806] build api fails to generate inline code for :target :nodejs Created: 01/Oct/16  Updated: 09/Dec/16

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

Type: Defect Priority: Minor
Reporter: Bruce Hauman Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None


 Description   

when inline code is provided as vector to the composition of `cljs.build.api/build` and `cljs.build.api/inputs` methods under `:target :nodejs` the provided inline code is not output.

;; this outputs code
(cljs.build.api/build (cljs.build.api/inputs '[(ns hello.core) (+ 1 2)]) {}) 

;; this does not output inline code
(cljs.build.api/build (cljs.build.api/inputs '[(ns hello.core) (+ 1 2)]) {:target :nodejs}) 


;; When you don't use cljs.build.api/inputs everything works correctly
(cljs.build.api/build '[(ns hello.core) (+ 1 2)] {}) ;; this outputs code

(cljs.build.api/build '[(ns hello.core) (+ 1 2)] {:target :nodejs}) ;; this outputs code


 Comments   
Comment by Bruce Hauman [ 30/Oct/16 11:31 AM ]

From @ykomatsu on Github:

add-preloads seems to remove cljs/nodejs.cljs.

https://github.com/clojure/clojurescript/blob/ab7a4911f1fd3a81210b1a9f2d84857748f8268b/src/main/clojure/cljs/closure.clj#L897

This patch will fix this problem but I am not sure if this is correct solution.

https://github.com/ykomatsu/clojurescript/commit/fc986467e66e6a628dc8f0e8a2ef2b30f715fd23

Comment by Dusan Maliarik [ 09/Dec/16 2:15 PM ]

Would anyone from the team please look at the patch? Thank you

Comment by David Nolen [ 09/Dec/16 6:22 PM ]

Please attach a patch to the ticket for review. Linking out of JIRA is not desirable. Thanks.





[CLJS-1709] clojure.data/diff throws an exception when comparing map keys of different types when used on sorted maps Created: 19/Jul/16  Updated: 16/Jun/17  Resolved: 16/Jun/17

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

Type: Defect Priority: Minor
Reporter: Thomas Scheiblauer Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug


 Description   

e.g.
(clojure.data/diff (sorted-map :foo 42) (sorted-map 1 42))
(clojure.data/diff (sorted-map :foo 42) (sorted-map "x" 42))
(clojure.data/diff (hash-map :foo 42) (sorted-map 1 42))
(clojure.data/diff (hash-map :foo 42) (sorted-map "x" 42))
will throw e.g.
Error: Cannot compare :foo to 1
while e.g.
(clojure.data/diff (hash-map :foo 42) (hash-map 1 42))
(clojure.data/diff (hash-map :foo 42) (hash-map "x" 2))
(clojure.data/diff (sorted-map :foo 42) (sorted-map :bar 42))
will not.

The same applies to Clojure with a different exception (e.g. "java.lang.Long cannot be cast to clojure.lang.Keyword")



 Comments   
Comment by David Nolen [ 16/Jun/17 1:02 PM ]

The behavior is based on Clojure, so this issue should be brought up there first.





[CLJS-1750] With `:language-out :ecmascript5-strict` goog.global is undefined Created: 15/Aug/16  Updated: 16/Jun/17  Resolved: 16/Sep/16

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

Type: Defect Priority: Minor
Reporter: Dusan Maliarik Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: closure


 Description   

When using `:language-out :ecmascript5-strict` the compiled code ends up in a wrapper where `this` resolves to `undefined`. This break goog/base.js where `this` is assigned to `goog.global`.



 Comments   
Comment by David Nolen [ 15/Aug/16 2:34 PM ]

This doesn't seem like a bug but rather a faithful interpretation of strict mode - see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode.





[CLJS-1797] Update aot_core to support build with MINGW on Windows Created: 30/Sep/16  Updated: 08/Jul/17  Resolved: 08/Jul/17

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

Type: Enhancement Priority: Minor
Reporter: Thomas Kidd Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: windows
Environment:

Windows 10


Attachments: Text File CLJS-1797.patch    
Patch: Code
Approval: Accepted

 Description   

When using Git Bash (which uses MINGW), ./script/build can get nearly all the way through it's work. However, it dies in aot_core because of the way that the classpath is generated by the Maven dependency:build-classpath plugin.



 Comments   
Comment by Thomas Kidd [ 30/Sep/16 7:40 AM ]

I was able to get this working locally, and will submit a patch when I am sure things are working

Comment by Thomas Kidd [ 30/Sep/16 8:45 AM ]

Updates aot_core to set the classpath correctly. More comments in patch.

Comment by Thomas Kidd [ 30/Sep/16 8:49 AM ]

Tested that patched version of master works on Windows 10 and OSX

Comment by Thomas Kidd [ 30/Sep/16 8:54 AM ]

Needs review

Comment by David Nolen [ 30/Sep/16 10:49 AM ]

Issues don't get closed until the issue is actually resolved

Comment by David Nolen [ 08/Jul/17 10:44 AM ]

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





[CLJS-1827] Improve reader performance on Firefox/Windows Created: 20/Oct/16  Updated: 19/Nov/17

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

Type: Enhancement Priority: Minor
Reporter: Michael Sperber Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: performance, reader
Environment:

Firefox on Windows


Attachments: Text File cljs-reader.patch    
Patch: Code

 Description   

cljs.reader/read-string speeds up by a factor of 2 on Firefox/Windows through this change without complicating the code.

(Other JS engines, including Firefox on Linux/Mac do not seem to be affected as significantly.)



 Comments   
Comment by David Nolen [ 20/Oct/16 10:33 AM ]

It would be nice to have a bit more information on this ticket as to what Google Closure does that's unnecessary or whether this path is actually a faithful port of Clojure behavior (copies the implementation of the EDN reader in these hot spots??). Finally the patch names David Frese, have they submitted a CA?

Thanks!

Comment by Michael Sperber [ 21/Oct/16 5:49 AM ]

I believe the Google functions are too general, work on strings in addition to characters etc.

It's not clear to us though why only Firefox on Windows benefits.

(David Frese is a co-worker - yes, has submitted a CA.)

Comment by Mike Fikes [ 19/Nov/17 7:41 PM ]

Patch no longer applies; needs re-baseline.
Also, doesn't work with git am; recommend creating patch using https://clojurescript.org/community/patches





[CLJS-1776] Add fixed arities for mapcat Created: 13/Sep/16  Updated: 13/Sep/16

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

Type: Enhancement Priority: Minor
Reporter: Robert C Faber Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: performance

Attachments: Text File CLJS_1776__Add_fixed_arities_for_mapcat.patch     Text File CLJS-1776.patch    
Patch: Code

 Description   

Following the pattern of map, this patch adds three fixed arities for mapcat.



 Comments   
Comment by Alex Miller [ 13/Sep/16 10:25 AM ]

Presumably this is to improve performance. Please include a benchmark showing the difference.





[CLJS-1689] regression issue with cljs.spec.test/check-var Created: 21/Jun/16  Updated: 21/Jun/16  Resolved: 21/Jun/16

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

Type: Defect Priority: Major
Reporter: Wilker Lúcio da Silva Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1689.patch    
Patch: Code

 Description   

The cljs.spec.test/check-var is trying to use the `cljs.spec/fn-specs` function that is not available. Reproduction steps:

Wilkers-MacBook-Pro:Downloads wilkerlucio$ java -cp cljs.jar clojure.main -m cljs.repl.node
ClojureScript Node.js REPL server listening on 54604
To quit, type: :cljs/quit
cljs.user=> (require 'cljs.spec.test)
WARNING: Use of undeclared Var cljs.spec/fn-specs at line 80 file:/Users/wilkerlucio/Downloads/cljs.jar!/cljs/spec/test.cljs
WARNING: Use of undeclared Var cljs.spec/fn-specs at line 80 .cljs_node_repl/cljs/spec/test.cljs
nil
cljs.user=>


 Comments   
Comment by Mike Fikes [ 21/Jun/16 8:32 AM ]

Just need to follow a bit more of https://github.com/clojure/clojure/commit/4978bf5cee35f74df87c49720fa82de7287d60a5#diff-b0f91f319d0c76aadf667da929b08d37L526 and rename fn-spec to get-spec. Caught another place and fixed it in this patch as well.

Comment by David Nolen [ 21/Jun/16 8:34 AM ]

fixed https://github.com/clojure/clojurescript/commit/4628e011c193fe25a60a527bfa6771f2ff5403a1





[CLJS-1688] :preloads compiler option for loading tooling code before the main ns Created: 20/Jun/16  Updated: 21/Jun/16  Resolved: 21/Jun/16

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

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


 Description   

The compiler should take a new `:preload` seq of symbols identifying namespaces (including Closure namespaces) that should be loaded before the main ns. The order of `:preload` will be respected but the recommendation will be that the namespaces are order independent. This will simplify loading tooling related side-effects which currently requires classpath busywork and requires boilerplate that will never see production.



 Comments   
Comment by David Nolen [ 21/Jun/16 11:31 AM ]

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





[CLJS-1691] spec internal compiler APIs Created: 21/Jun/16  Updated: 21/Jun/16

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

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





[CLJS-1692] Autoalias clojure.* to exisiting cljs.* namespaces if possible Created: 24/Jun/16  Updated: 24/Jun/16  Resolved: 24/Jun/16

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

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


 Comments   
Comment by David Nolen [ 24/Jun/16 3:04 PM ]

fixed https://github.com/clojure/clojurescript/commit/23632baa35f86de8866dede624545bc0cdf4a2bb





[CLJS-1705] Calling (done) within binding in an async test corrupts bound vars Created: 10/Jul/16  Updated: 11/Jul/16  Resolved: 11/Jul/16

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 1.9.36, 1.9.76, 1.9.293
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Trevor Schmidt Assignee: Unassigned
Resolution: Declined Votes: 1
Labels: asynchronous, cljs, test
Environment:

OS X 10.11.5

⟩ java -version
java version "1.8.0_72"
Java(TM) SE Runtime Environment (build 1.8.0_72-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode)



 Description   

In an async test, calling (done) within a (binding) corrupts bound vars.

repro/core.cljs
(ns repro.core
  (:require [clojure.string :as string]
            [cljs.test :refer-macros [async deftest is run-tests]]))

(def ^:dynamic *foo* nil)

(deftest async-binding-safe
  (async done
    (binding [*foo* {}]
      (is (some? *foo*)))
    (is (nil? *foo*))
    (done)))

(deftest async-binding-corruption
  (async done
    (is (nil? *foo*))
    (binding [*foo* {}]
      (is (some? *foo*))
      (done))))

(deftest async-binding-corrupt?
  (async done
    (is (nil? *foo*))
    (done)))

(enable-console-print!)

(run-tests 'repro.core)

The first test passes as expected, and because (done) is outside the binding, *foo* is reverted to nil. The second test passes, but leaves *foo* bound. The third test fails.



 Comments   
Comment by Trevor Schmidt [ 10/Jul/16 4:44 PM ]

clojure.string is not necessary for the repro, but I am unable to edit to remove it.

Comment by Antonin Hildebrand [ 10/Jul/16 5:28 PM ]

might be related to CLJS-1634

Comment by David Nolen [ 11/Jul/16 4:14 PM ]

This is expected behavior





[CLJS-1710] spec/double-in not implemented Created: 20/Jul/16  Updated: 23/Sep/16  Resolved: 23/Sep/16

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

Type: Defect Priority: Major
Reporter: Marshall Abrams Assignee: David Nolen
Resolution: Completed Votes: 1
Labels: cljs, newbie, spec
Environment:

Clojurescript 1.9.89



 Description   

spec/double-in is available in Clojure 1.9.0-alpha10, but doesn't seem to be implemented yet in Clojurescript as of 1.9.89. I also tried 1.9.76: not there either.

cljs.user=> (require '[cljs.spec :as s])
nil
cljs.user=> (s/valid? #(and (>= % 0.0) (<= % 1.0)) 1.0)
----  Compiler Warning on   <cljs form>   line:1  column:12  ----

  Use of undeclared Var cljs.spec/double-in

  1  (s/valid? (s/double-in :min 0.0 :max 1.0) 1.0)
                ^---

----  Compiler Warning  ----
#object[TypeError TypeError: Cannot read property 'call' of undefined]
nil

(Newbie ticket. Apologies if this is a dupe ticket or doesn't belong here. I couldn't find any tickets that seemed to mention this issue.)



 Comments   
Comment by David Nolen [ 23/Sep/16 2:22 PM ]

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





[CLJS-1693] rel-output-path produces wrong path for :lib files Created: 25/Jun/16  Updated: 10/Mar/17  Resolved: 10/Mar/17

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

Type: Defect Priority: Major
Reporter: Ruslan Prokopchuk Assignee: Unassigned
Resolution: Duplicate Votes: 1
Labels: None
Environment:

Bug presents in any environment, but break things only on Windows.



 Description   

Building with a cljsjs package where cljsjs package includes :libs in deps.cljs you find the "out" directory includes a subdirectory "file:".

An example from my specific case:
"out/file:/home/vagrant/.m2/repository/cljsjs/openlayers/3.3.0-0/openlayers-3.3.0-0.jar!/cljsjs/development/openlayers/ol/array.js"

':' is not permitted on Windows filesystem, which leads to compilation error.

It happens because rel-output-path here https://github.com/clojure/clojurescript/blob/17bcf2a091accb6f7caf1e8fa3954b490e9d34fa/src/main/clojure/cljs/closure.clj#L1515 detects closure-lib first (before taking in account that it is in jar) and passes it to lib-rel-path which acts as if file is located in project directory.

Another issue, but deeply related, is that on Windows, lib-rel-path breaks build even for :lib files located in project directory. It happens because of naive path prefix removal https://github.com/clojure/clojurescript/blob/17bcf2a091accb6f7caf1e8fa3954b490e9d34fa/src/main/clojure/cljs/closure.clj#L1500 because it tries to remove a subpath with native path separators, but path comes here in url-like form with forward slashes. Compiler then reports that path is not relative and aborts compilation.



 Comments   
Comment by Shaun Mahood [ 02/Mar/17 11:54 AM ]

Looks like a duplicate of CLJS-1868





[CLJS-1813] bring clojure.core.specs from clojure Created: 06/Oct/16  Updated: 22/Dec/17  Resolved: 22/Dec/17

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

Type: Enhancement Priority: Major
Reporter: Yehonathan Sharvit Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: spec


 Description   

In clojure there is clojure.core.specs namespace.
It has not yet be ported in clojurescript.






[CLJS-1690] spec the ClojureScript AST Created: 21/Jun/16  Updated: 21/Jun/16

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

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





Generated at Wed Apr 24 00:58:35 CDT 2019 using JIRA 4.4#649-r158309.