<< Back to previous view

[CLJS-866] Faulty ns macro desugaring Created: 01/Oct/14  Updated: 01/Oct/14

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

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

ClojureScript 0.0-2356, Clojure 1.7.2-alpha2 (but I believe this has been around for some time)



 Description   

ns desugaring for `:include-macros`, `:refer-macros` seems to be faulty.

Have posted a Gist showing the behaviour: https://gist.github.com/ptaoussanis/e599719d5fb6828a31b1

;; desugar-ns-specs from clojurescript/src/clj/cljs/analyzer.clj
;; (`cljs.analyzer` ns)
 
(desugar-ns-specs '[(:require [foo.bar :as bar :include-macros true])])
;; =>
((:require-macros (foo.bar :as bar))
 (:require        (foo.bar :as bar))) ; Correct
 
(desugar-ns-specs '[(:require [foo.bar :as bar :include-macros true :refer [baz]])])
;; =>
((:require-macros (foo.bar :as bar :refer [baz]))
 (:require        (foo.bar :as bar))) ; Seems off, but what's the intended behaviour?
 
(desugar-ns-specs '[(:require [foo.bar :as bar :refer [baz] :include-macros true])])
;; =>
((:require-macros (foo.bar :as bar :refer [baz]))
 (:require        (foo.bar :as bar :refer [baz])))
 
;; Is the position of `:include-macros true` supposed to influence expansion
;; like this?
 
;; And is the interaction between `:include-macros true` and `:refer` as
;; intended? I would have expected something like this:
(desugar-ns-specs '[(:require [foo.bar :as bar :include-macros true :refer [baz]])])
;; =
(desugar-ns-specs '[(:require [foo.bar :as bar :refer [baz] :include-macros true])])
;; =>
((:require-macros (foo.bar :as bar)) ; No :refer
 (:require        (foo.bar :as bar :refer [baz])))
 
;;; --------------------------------------------------------------------------
 
;; There's an additional problem with `:refer` + `:refer-macros`:
 
(desugar-ns-specs '[(:require [foo.bar :as bar :refer [baz] :refer-macros [qux]])])
;; =>
((:require-macros (foo.bar :as bar :refer [baz] :refer [qux])) ; Faulty
 (:require        (foo.bar :as bar :refer [baz])))
 
;; I believe the correct expansion should be:
((:require-macros (foo.bar :as bar :refer [qux]))
 (:require        (foo.bar :as bar :refer [baz])))

So to recap, there seems to be two issues:
1. `:refer-macros` is producing an invalid expansion.
2. `:include-macros true` is position-sensitive, and is dragging `:refer`s along into `:require-macros`. I suspect that this may not be the intended behaviour?

Would be happy to provide a patch if you can confirm that the alternative behaviour I'm suggesting in the Gist is correct.

Thanks, cheers!






[CLJS-865] js-dependency-index won't work when running from an uberjar Created: 26/Sep/14  Updated: 29/Sep/14

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

Type: Defect Priority: Major
Reporter: Dan Johansson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Window7
[org.clojure/clojure "1.6.0"]
[org.clojure/clojurescript "0.0-2322"]
java 1.7



 Description   

I'm having problems running an uberjar with [lein-light-nrepl "0.0.18"].
I've tracked the problem down to the filter in cljs.js-deps/goog-resource.
It expects to find goog/deps.js in the google jar file but it is in the uberjar file.



 Comments   
Comment by Dan Johansson [ 29/Sep/14 2:27 AM ]

I use this workaround for now:

(defn load-nrepl []
  (require 'cljs.js-deps)
  
  (alter-var-root (find-var 'cljs.js-deps/goog-resource)
                  (fn [of]
                    (fn [path]
                      (first
                       (enumeration-seq (.getResources (.getContextClassLoader (Thread/currentThread)) path))))))
  
  (require 'lighttable.nrepl.handler))

It just removes the filter.
I guess the filter is there to make sure you get the correct goog/deps.js file? I don't know what assumptions to make about build environments to suggest a generic solution.

Comment by Dan Johansson [ 29/Sep/14 2:28 AM ]

This is the error I get:

Caused by: 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.js_deps$goog_dependencies_STAR_.invoke(js_deps.clj:241)
	at clojure.lang.AFn.applyToHelper(AFn.java:152)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.core$apply.invoke(core.clj:624)
	at clojure.core$memoize$fn__5097.doInvoke(core.clj:5846)
	at clojure.lang.RestFn.invoke(RestFn.java:397)
	at cljs.js_deps$js_dependency_index.invoke(js_deps.clj:265)
	at cljs.env$default_compiler_env.invoke(env.clj:45)
	at cljs.env$default_compiler_env.invoke(env.clj:42)
	at lighttable.nrepl.cljs__init.load(Unknown Source)
	at lighttable.nrepl.cljs__init.<clinit>(Unknown Source)
	... 52 more
Comment by James Cash [ 29/Sep/14 3:58 PM ]

I was able to work around this same issue by explicitly including the google-closure-library jar in the classpath (i.e. instead of `java -jar my-uber.jar`, `java -cp google-closure-library-$VERSION.jar:my-uber.jar my-uber.core`)





[CLJS-864] ClojureScript's 'and' does not always short-circuit Created: 24/Sep/14  Updated: 25/Sep/14

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

Type: Defect Priority: Major
Reporter: Zachary Kanfer Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

my dependencies from my project.clj:

:dependencies [[org.clojure/clojure "1.6.0"]
[org.clojure/clojurescript "0.0-2342"]
[org.clojure/core.async "0.1.319.0-6b1aca-alpha"]]

I'm building on Linux 3.13.0-35



 Description   

I have a section of code: and false (function-that-should-not-be-called). Now, we should never call the function inside the and, but I'm seeing behavior where sometimes we are. It seems to depend on what's going on inside the definition of {function-that-should-not-be-called}. If we define a function this way, everything is fine:

(defn implicit-return-value
  []
  (.log js/console "implicit-return-value called")
  (dom/setTextContent (dom/getElement "executed")
                      "We called (implicit-return-value)"))

When I say "everything is fine", I mean the function is not called when this code is executed: (and false (implicit-return-value).

On the other hand, if we define a function this way, everything is not fine:

(defn explicit-return-value
  []
  (.log js/console "explicit-true-return called.")
  (dom/setTextContent (dom/getElement "executed")
                      "We called (explicit-return-value)")
  true)

When we execute this code: (and false (explicit-return-value), we do call the function explicit-return-value.

I have made a minimal project using the latest ClojureScript. The output of that project is located on my webpage. The project itself is on bitbucket. I'm not able to reproduce in a ClojureScript repl, and I haven't played around with optimizations to see when it does and does not happen.



 Comments   
Comment by Francis Avila [ 25/Sep/14 2:48 AM ]

Most likely the problem is in core.async's go macro, not clojurescript. You should bring this issue up with them.

Other avenues of investigation:

  • Are go blocks required to trigger the problem? (Seems so from what is said about repl.)
  • Does similar code (and inside go block with compile-time-known return value) exhibit the same behavior in Clojure?
Comment by Francis Avila [ 25/Sep/14 2:51 AM ]

Indeed, it seems the same issue has a ticket in core.async JIRA: ASYNC-91





Generated at Wed Oct 01 13:17:01 CDT 2014 using JIRA 4.4#649-r158309.