<< Back to previous view

[CLJS-1565] Self-host: whitespace optimization is broken Created: 08/Feb/16  Updated: 09/Feb/16

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

Type: Defect Priority: Minor
Reporter: Yehonathan Sharvit Assignee: Mike Fikes
Resolution: Unresolved Votes: 0
Labels: bootstrap, bug


 Description   

When requiring `cljs.js` and compiling in `:optimizations :whitespace`
I get the following error in the browser:
"goog.require could not find: cljs.core$macros"

And the page is broken.


Steps to reproduce:

1. Make a directory, say CLJS-1565
2. Copy shipping cljs.jar into the directory
3. Make an index.html, src/hello_world/core.cljs, and build.clj file with contents as below.
4. java -cp cljs.jar:src clojure.main build.clj
5. Open index.html with Chrome and view the JavaScriptConsole in Chrome.

index.html:

<html>
    <body>
        <script type="text/javascript" src="out/main.js"></script>
    </body>
</html>

src/hello_world/core.cljs:

(ns hello-world.core
  (:require cljs.js))

(enable-console-print!)

(println "Hello world!")

build.clj:

(require 'cljs.build.api)

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

(System/exit 0)


 Comments   
Comment by Mike Fikes [ 08/Feb/16 6:09 AM ]

I wonder if the description is sufficient to repro.

I'd recommend checking if CLJS-1541 fixes this.

Comment by Yehonathan Sharvit [ 08/Feb/16 6:45 AM ]

@mike CLJS-1541 doesn't fix this.





[CLJS-1564] Self-host: cached macro *loaded* update Created: 07/Feb/16  Updated: 07/Feb/16

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

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

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

 Description   

When using cljs.js/require, the cljs.js/*loaded* atom is updated reflecting loaded namespaces. When loading a cached macro namespace, the non-macros namespace name is added to the *loaded* set.

Minimal repo, with script/noderepljs:

$ script/noderepljs 
ClojureScript Node.js REPL server listening on 52507
To quit, type: :cljs/quit
cljs.user=> (require '[cljs.js :as cljs])
nil
cljs.user=> ;; Load a macros namespace
cljs.user=> (cljs/require
  {}
  'foo.core
  :reload-all
  {:macros-ns true
   :load      (fn [_ cb] (cb {:lang   :clj
                              :source "(ns foo.core)"}))
   :eval      (constantly nil)}
  (fn [_]
    (prn @cljs/*loaded*)))
#{foo.core$macros}
nil
cljs.user=> ;; Do the same again, but return cached js
cljs.user=> (cljs/require
  {}
  'foo.core
  :reload-all
  {:macros-ns true
   :load      (fn [_ cb] (cb {:lang   :js
                              :source ""}))
   :eval      (constantly nil)}
  (fn [_]
    (prn @cljs/*loaded*)))
#{foo.core}
nil
cljs.user=> ;; Note that *loaded* now has #{foo.core}


 Comments   
Comment by Mike Fikes [ 07/Feb/16 10:44 PM ]

This was a simple oversight with the changes made for CLJS-1504: One spot was missed in the places where name needed to be converted to aname.

With this change, the repo in the description goes away and the included additional unit tests covering *loaded* pass.

Additionally in a downstream cljs.js client, where a regular namespace refers several symbols from a cached macros namespace, it can be seen that loading of the cached namespace occurs once and only once, as opposed to an additional time for each referred symbol as :use-macros is being processed.





[CLJS-1563] :source-map option to cljs.build.api/build should take nil Created: 07/Feb/16  Updated: 08/Feb/16

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

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


 Description   

It should be possible to specify nil or false when providing the :source-map option to cljs.build.api/build, for example, like this:

(build {...
        :optimizations :whitespace
        :source-map (when debug? "somepath.js.map")})

Currently that causes:

Exception in thread "main" java.lang.AssertionError: Assert failed: :source-map nil must specify a file in the same directory as :output-to "target/js/zs-background.js" if optimization setting applied
(or (nil? (:output-to opts)) (:modules opts) (string? source-map)), compiling:(/Users/isaac/code/zensight/client/cljs/build.clj:66:1)

Using false has the same behavior. The alternative of conditionally assoc ing the key in works just fine, but is a tad awkward. It seems reasonably straightforward to fix - need to change that assert to check the value in the map and double-check that it's checked properly downstream. Happy to submit a patch if you'll take it.



 Comments   
Comment by Isaac Cambron [ 07/Feb/16 10:18 AM ]

Apologies for the formatting; forgot that backtick stuff doesn't work in Jira.

Comment by Mike Fikes [ 08/Feb/16 5:05 PM ]

Reformatted description.





[CLJS-1562] WARN on hinted fn call type mismatch Created: 06/Feb/16  Updated: 06/Feb/16

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

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


 Description   

If a call is made to a function that has hinted arguments (especially {^boolean} and {^number}), with an expression that is known to not be of that type, emit a diagnostic type mismatch warning.

An example that should emit a warning is:

(defn f [^boolean b])
(f 0)





[CLJS-1561] WARN if recur passes non-inferred type Created: 06/Feb/16  Updated: 06/Feb/16

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

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

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

 Description   

Take this code as an example:

(defn f [^boolean b]
  (loop [x b]
    (if x
      (recur 0)
      :done)))

The type of x is inferred to be Boolean, but there is a recur form that can be statically deduced to be passing a non-Boolean.

This ticket asks that a WARN be issued for this case, and perhaps others (where maybe x itself is directly type hinted).



 Comments   
Comment by Mike Fikes [ 06/Feb/16 2:59 PM ]

Attached a patch which warns on for the case of boolean and number, since those two types have special handling.

Some example usage:

cljs.user=> (defn f [^boolean b]
       #_=>   (loop [x b]
       #_=>     (if x
       #_=>       (recur 0)
       #_=>       :done)))
WARNING: recur target parameter x has inferred type boolean, but being passed type number at line 4 
#'cljs.user/f
cljs.user=> (loop [x 1 y true z :hi]
       #_=>   (when false (recur 'a "hi" nil)))
WARNING: recur target parameter x has inferred type number, but being passed type cljs.core/Symbol at line 2 
WARNING: recur target parameter y has inferred type boolean, but being passed type string at line 2 
nil
cljs.user=> (loop [x 1 y true]
       #_=>  (when false (recur nil nil)))
WARNING: recur target parameter x has inferred type number, but being passed type clj-nil at line 2 
WARNING: recur target parameter y has inferred type boolean, but being passed type clj-nil at line 2 
nil
cljs.user=> (loop [x 1]
       #_=>   (let [y (inc x)]
       #_=>     (when false (recur (inc y)))))
nil
cljs.user=> (loop [b true]
       #_=>   (when false (recur (inc 1))))
WARNING: recur target parameter b has inferred type boolean, but being passed type number at line 2 
cljs.user=> (loop [x 1] 
       #_=>   (inc x) 
       #_=>     (when false (recur :hi)))
WARNING: recur target parameter x has inferred type number, but being passed type cljs.core/Keyword at line 3 
nil
cljs.user=> (loop [x :hello] 
       #_=>   (inc x) 
       #_=>     (when false (recur :hi)))
WARNING: cljs.core$macros/+, all arguments must be numbers, got [cljs.core/Keyword number] instead. at line 2 
nil




[CLJS-1560] cljs.reader/read-string doesn't read records that are printed Created: 05/Feb/16  Updated: 05/Feb/16  Resolved: 05/Feb/16

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

Type: Enhancement Priority: Minor
Reporter: Daniel Compton Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

I'm not sure if this is a bug, or feature enhancement, but there is a difference between how Clojure reads records that have been printed, and how ClojureScript does with cljs.reader/read-string.

In Clojure

user=> (defrecord myrec [a b])
user.myrec
user=> (pr-str (->myrec 1 2))
"#user.myrec{:a 1, :b 2}"
user=> (read-string (pr-str (->myrec 1 2)))
#user.myrec{:a 1, :b 2}

In ClojureScript

cljs.user=> (defrecord myrec [a b])
cljs.user/myrec
cljs.user=> (pr-str (->myrec 1 2))
"#cljs.user.myrec{:a 1, :b 2}"
cljs.user=> (cljs.reader/read-string "#cljs.user.myrec{:a 1, :b 2}")
Could not find tag parser for cljs.user.myrec in ("inst" "uuid" "queue" "js")
...
;; Add a tag parser
cljs.user=> (cljs.reader/register-tag-parser! "cljs.user.myrec" map->myrec)
nil
cljs.user=> (cljs.reader/read-string "#cljs.user.myrec{:a 1, :b 2}")
#cljs.user.myrec{:a 1, :b 2}

The proposed solution to this would be to register a tag parser when a defrecord is created. However after reading http://stackoverflow.com/questions/24661655/clojure-clojurescript-clojure-core-read-string-clojure-edn-read-string-and-c, it seems like perhaps the error is in my understanding and cljs.reader/read-string should be expected to behave more like clojure.edn/read-string. If this is the case, it might be good to update the docstrings for cljs.reader to make this distinction clearer.



 Comments   
Comment by David Nolen [ 05/Feb/16 2:36 PM ]

There isn't a good way to make this work due to the nature of advanced compilation. Those names won't exist. If we created some kind of lookup table that would defeat dead code elimination of unused records.





[CLJS-1559] Closure :libs ignored Created: 05/Feb/16  Updated: 05/Feb/16

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

Type: Defect Priority: Minor
Reporter: Dominykas Mostauskis Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

:libs compilation option doesn't work. Whether specifying directories, or specific files. If trying to `import` one of the js classes (properly namespaced with `goog.provide`) into clojurescript, compilation fails with "no such namespace". If the libs code is not referenced in clojurescript, it compiles, and the output directory does not contain the libs js files.

Compilation options:

(cljs.closure/build
    "src/main/clojurescript"
    {:main 'example.core
     :libs ["/src/main/javascript/"]
     :optimizations :none
     :output-dir "js"
     :output-to "js/main.js"
     :source-map true
     :asset-path "/js"
     })

Javascript file:

goog.provide("test.Test");

test.Test = function(x) {
  this.x = x;
};


 Comments   
Comment by Mike Fikes [ 05/Feb/16 1:51 PM ]

Hi Dominykas, is the absolute path intentional? I suspect the intent was to not have the leading /.

Comment by Dominykas Mostauskis [ 05/Feb/16 2:01 PM ]

I made this typo when posting. On my setup paths are relative to project root.

Comment by David Nolen [ 05/Feb/16 2:38 PM ]

As far as I know quite a few people rely on this functionality. Please provide a complete minimal example or this issue will be closed. All source should be in the ticket or in this comment thread, no external links. Thanks.

Comment by Dominykas Mostauskis [ 05/Feb/16 3:50 PM ]

Can't reproduce. Tips would be appreciated. Banging my head against the wall here.





Generated at Tue Feb 09 20:50:43 CST 2016 using JIRA 4.4#649-r158309.