<< Back to previous view

[CLJS-2272] Tests that depended on default install deps behavior failing Created: 25/Jul/17  Updated: 25/Jul/17  Resolved: 25/Jul/17

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

Type: Defect Priority: Blocker
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: js-modules, test

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

 Comments   
Comment by David Nolen [ 25/Jul/17 3:18 PM ]

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





[CLJS-2058] Update known compiler options Created: 29/May/17  Updated: 25/Jul/17  Resolved: 25/Jul/17

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

Type: Defect Priority: Major
Reporter: Shaun LeBron Assignee: Shaun LeBron
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2058.patch    

 Description   

Add the following known options:

  • closure-module-roots
  • rewrite-polyfills
  • use-only-custom-externs
  • watch-error-fn
  • watch-fn (moved from known-repl-opts, since this is not repl-specific)


 Comments   
Comment by David Nolen [ 16/Jun/17 9:11 AM ]

Please don't reformat code when making small changes like this. Thanks.

Will apply an updated patch that doesn't change formatting.

Comment by David Nolen [ 25/Jul/17 1:34 AM ]

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





[CLJS-2255] Clean up :npm-deps Created: 17/Jul/17  Updated: 25/Jul/17  Resolved: 25/Jul/17

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

Type: Task Priority: Critical
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: npm-deps

Attachments: Text File CLJS-2255.patch    

 Description   

We should separate module installation from building and REPLs. I propose the following new public build fns:

cljs.build.api/install-deps!
cljs.build.api/get-deps
cljs.build.api/print-deps


 Comments   
Comment by David Nolen [ 17/Jul/17 2:00 AM ]

`get-deps` should return a vector of {:name ... :version ... :type ...} entries

Comment by António Nuno Monteiro [ 17/Jul/17 8:37 PM ]

Attached a tentative patch adding `cljs.build.api/install-node-deps!` and `cljs.build.api/get-node-deps` functions.

Looking for feedback if this is the satisfies the requirements for what you had in mind. IMO printing dependencies is just a call away from `get-node-deps`.

Comment by David Nolen [ 18/Jul/17 12:36 AM ]

I agree about printing deps. These functions should probably take compiler options since they are user facing and that's the easiest interface from that standpoint.

We should also remove automatic calls to dep installation in build as well as REPLs. Installing dependencies on each build, REPL start just doesn't seem like a good idea.

Comment by David Nolen [ 25/Jul/17 1:19 AM ]

After thinking about it some more I think the supplied patch is OK.

Comment by David Nolen [ 25/Jul/17 1:26 AM ]

fixed https://github.com/clojure/clojurescript/commit/8972224b4b4617a98a9fdd497af1aeb91a29ed2a





[CLJS-2235] Allow passing extra maven opts to build scripts Created: 14/Jul/17  Updated: 25/Jul/17  Resolved: 25/Jul/17

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

Type: Enhancement Priority: Critical
Reporter: Antonin Hildebrand Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: test-matrix

Attachments: Text File CLJS-2235.patch    
Patch: Code
Approval: Vetted

 Description   

I canary project[1] I need to run all maven commands in --batch-mode to prevent download progress messages output and also optionally I want to run it with --quiet flag to optionally suppress its verbose output.

This patch introduces CLJS_SCRIPT_MVN_OPTS env var which can be optionally specified to provide extra command line opts to all mvn commands executed within build scripts.

[1] https://github.com/cljs-oss/canary
[2] https://github.com/cljs-oss/canary/blob/9772649eae7097156251f4abb7ee70ea349ea99b/runner/scripts/build_compiler.sh#L74



 Comments   
Comment by David Nolen [ 25/Jul/17 1:25 AM ]

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





[CLJS-2271] native-satisfies? using aget Created: 24/Jul/17  Updated: 24/Jul/17  Resolved: 24/Jul/17

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

Type: Defect Priority: Minor
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

native-satisfies? is using aget and should instead be using either gobj/get or unchecked-get.



 Comments   
Comment by Mike Fikes [ 24/Jul/17 9:33 AM ]

Already fixed with https://github.com/clojure/clojurescript/commit/84a2128dab9f52e67ee227a66be4f849d83de0a3





[CLJS-2267] Allow ^:const inlined vars to affect if emission Created: 21/Jul/17  Updated: 24/Jul/17  Resolved: 24/Jul/17

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

Type: Enhancement Priority: Major
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: core

Attachments: Text File CLJS-2267.patch    
Patch: Code and Test
Approval: Accepted

 Description   

If an if test is a truthy or falsey constant, this fact is used to emit either the then or else branch, while also avoiding Closure warnings about unreachable code.

With the new ^:const Var inlining feature, we can allow a modest broadening of scope to also allow for truthy or falsey const expressions, perhaps slightly improving performance of affected code that is not run through Closure, and also avoiding new unreachable code warnings that can otherwise now crop up with the new JavaScript that results from ^:const Var inlining.



 Comments   
Comment by David Nolen [ 24/Jul/17 12:59 AM ]

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





[CLJS-2265] Library namespaces loading before their dependencies with :none optiizations Created: 20/Jul/17  Updated: 24/Jul/17  Resolved: 24/Jul/17

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

Type: Defect Priority: Minor
Reporter: Peter Schuck Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: bug, repl


 Description   

Loading ClojureScript module that has library dependencies will fail due to the library namespaces loading before their dependencies.

For example say the have a project with a cljs-time ([com.andrewmcveigh/cljs-time "0.5.0"]) dependency, there modules

:modules {:core {:entries '#{org.modules.transitive}
                 :output-to "out/modules.js"}
          :time {:entries '#{org.modules.time}
                 :output-to "out/time.js"}}

and this code

(ns org.modules.time
  (:require [cljs-time.core :as ct]
            [cljs.loader :as loader]))

(defn display-time [time]
  time)
(ns org.modules.transitive
  (:require [cljs.loader :as loader]))

(loader/load
  :time
  (fn []
    (js/console.log ((resolve 'org.modules.time/display-time) 100))))

When the :time module is loaded the cljs-time.core is loaded, but any dependencies it may have (e.g. cljs-time.core.internal) are loaded afterwards causing the loading of the :time module to fail. After a backoff delay (around 5 seconds) the Google Closure Module Manager retries loading the :time module, this time successfully. Until the :time module is loaded successfully all module loading is subject to this backoff delay.

Demonstration Repo



 Comments   
Comment by David Nolen [ 24/Jul/17 12:33 AM ]

CLJS-2264





[CLJS-2264] Double loading of :cljs-base with :none optimizations Created: 20/Jul/17  Updated: 24/Jul/17  Resolved: 24/Jul/17

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

Type: Defect Priority: Minor
Reporter: Peter Schuck Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug, repl


 Description   

If a project has these modules

:modules {:core {:entries '#{org.modules.core}
                 :output-to "out/modules.js"}
          :menu {:entries '#{org.modules.menu}
                 :output-to "out/menu.js"}}

and this root (org.modules.core) namespace

(ns org.modules.core
  (:require [cljs.loader :as loader]))

(loader/load
  :menu
  (fn [] (js/console.log "Module loaded)))

Then the :cljs-base module will be loaded twice.

The issue is that the loading of :menu causes `:cljs-base` to be loaded as well. Loading the root namespace marks :cljs-base as loaded but only at the end of the file. Under the hood ClojureScript adds

(cljs.loader/set-loaded! :core)

at the end of the :core module. By then it's too late, the :menu module has already started loading.

This is only a problem in the REPL due to the :cljs-base module being loaded through document.write.

Demonstration Repo



 Comments   
Comment by David Nolen [ 24/Jul/17 12:30 AM ]

This is not a bug. Loading modules like this at the top-level means you need to call set-loaded! yourself. In general what is being shown here is an antipattern. If you're just going to immediately load some other module why are you using code splitting?

One simple workaround is to simply put a setTimeout around this top level load.





[CLJS-2263] Docstring for neg-int? backwards Created: 19/Jul/17  Updated: 24/Jul/17  Resolved: 24/Jul/17

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

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

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

 Description   

Typo introduced here for neg-int?'s docstring:

https://github.com/clojure/clojurescript/commit/224e140117d330933fb9b7e993ff26f997f36cbd



 Comments   
Comment by David Nolen [ 24/Jul/17 12:27 AM ]

fixed https://github.com/clojure/clojurescript/commit/39b6c260837d2eec33b60a30f805b62146364383





[CLJS-2262] Correct comment that *warn-on-infer* is file-scope Created: 19/Jul/17  Updated: 24/Jul/17  Resolved: 24/Jul/17

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

Type: Defect Priority: Trivial
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: documentation

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

 Description   

I had accidentally written a comment in the code next to *warn-on-infer* indicating that it has global scope.



 Comments   
Comment by David Nolen [ 24/Jul/17 12:26 AM ]

fixed https://github.com/clojure/clojurescript/commit/3037f04cdc7d8cc977842e9f129ef9f3aee70796





[CLJS-2258] Stack overflow regression for sequence xform applied to eduction Created: 18/Jul/17  Updated: 24/Jul/17  Resolved: 24/Jul/17

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

Type: Defect Priority: Critical
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: regression, transducers

Attachments: Text File CLJS-2258.patch    
Patch: Code and Test
Approval: Accepted

 Description   

There is a regression in the ability to use sequence to apply transducers to eductions that was introduced with 1.9.562.

In 1.9.542 and earlier,

(sequence (map str) (eduction [1]))
produced ("1").

Minimal repro:

$ java -jar cljs.jar -m cljs.repl.node
ClojureScript Node.js REPL server listening on 50609
To quit, type: :cljs/quit
cljs.user=> (sequence (map str) (eduction [1]))
repl:13
throw e__5525__auto__;
^

RangeError: Maximum call stack size exceeded
    at Function.cljs.core.TransformerIterator.create (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:13959:50)
    at cljs.core.Eduction.cljs$core$IIterable$_iterator$arity$1 (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:33244:38)
    at Object.cljs$core$_iterator [as _iterator] (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:3158:13)
    at Object.cljs$core$iter [as iter] (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:13554:18)
    at Function.cljs.core.TransformerIterator.create (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:13960:55)
    at cljs.core.Eduction.cljs$core$IIterable$_iterator$arity$1 (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:33244:38)
    at Object.cljs$core$_iterator [as _iterator] (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:3158:13)
    at Object.cljs$core$iter [as iter] (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:13554:18)
    at Function.cljs.core.TransformerIterator.create (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:13960:55)
    at cljs.core.Eduction.cljs$core$IIterable$_iterator$arity$1 (/Users/mfikes/Downloads/.cljs_node_repl/.cljs_node_repl/cljs/core.js:33244:38)


 Comments   
Comment by Mike Fikes [ 18/Jul/17 7:36 AM ]

CLJS-2034:

d93c4356e7ab78743ae66d8cffe8df54869f0be3 is the first bad commit
commit d93c4356e7ab78743ae66d8cffe8df54869f0be3
Author: António Nuno Monteiro <anmonteiro@gmail.com>
Date:   Fri May 12 13:39:37 2017 -0700

    CLJS-2034: Sequence and Eduction produce infinite loop in transducer that appends to the reduction

    The implementation of transducers in ClojureScript tracked an old counterpart in
    the Clojure codebase. This patch addresses the change introduced in the
    following commit to Clojure, which replaced `LazyTransformer` with
    `TransformerIterator`, effectively making the transducer behavior akin to the
    one in Clojure.

    https://github.com/clojure/clojure/commit/c47e1bbcfa227723df28d1c9e0a6df2bcb0fecc1

:040000 040000 001a34e8f941a2e1697299be2632143e3e191587 5a508a3162eb9eb1023c0c0cd9ff7ee9cf2ad733 M	src
Comment by António Nuno Monteiro [ 18/Jul/17 12:08 PM ]

Attached patch with fix and test.

Comment by Mike Fikes [ 18/Jul/17 12:37 PM ]

I don't know if this is a bug or not, but with 1.9.542

cljs.user=> (iter (eduction [1 2 3]))
#object[cljs.core.SeqIter]

and after the patch:

cljs.user=> (iter (eduction [1 2 3]))
repl:13
throw e__8096__auto__;
^

Error: [object Object] is not ISeqable
    at Object.cljs$core$seq [as seq] (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/.cljs_node_repl/cljs/core.js:4413:8)
    at Object.cljs$core$pr_sequential_writer [as pr_sequential_writer] (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/.cljs_node_repl/cljs/core.js:31431:14)
    at cljs.core.TransformerIterator.cljs$core$IPrintWithWriter$_pr_writer$arity$3 (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/.cljs_node_repl/cljs/core.js:32456:18)
    at Object.cljs$core$pr_writer_impl [as pr_writer_impl] (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/.cljs_node_repl/cljs/core.js:31612:12)
    at Object.cljs$core$pr_writer [as pr_writer] (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/.cljs_node_repl/cljs/core.js:31722:18)
    at Object.cljs$core$pr_seq_writer [as pr_seq_writer] (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/.cljs_node_repl/cljs/core.js:31726:11)
    at Object.cljs$core$pr_sb_with_opts [as pr_sb_with_opts] (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/.cljs_node_repl/cljs/core.js:31789:11)
    at Object.cljs$core$pr_str_with_opts [as pr_str_with_opts] (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/.cljs_node_repl/cljs/core.js:31803:63)
    at Function.cljs.core.pr_str.cljs$core$IFn$_invoke$arity$variadic (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/.cljs_node_repl/cljs/core.js:31886:18)
    at Object.cljs$core$pr_str [as pr_str] (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/.cljs_node_repl/cljs/core.js:31882:25){

I wonder if there is some public code path where this would show up (as opposed to directly calling iter).

Comment by António Nuno Monteiro [ 18/Jul/17 12:57 PM ]

`(iter (eduction [1 2 3]))` is now a TransformerIterator, which doesn't have a print method.

For comparison with Clojure:

user=> (clojure.lang.RT/iter (eduction [1 2 3]))
#object[clojure.lang.TransformerIterator 0x28adf451 "clojure.lang.TransformerIterator@28adf451"]
Comment by David Nolen [ 24/Jul/17 12:12 AM ]

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





Generated at Wed Jul 26 01:39:37 CDT 2017 using JIRA 4.4#649-r158309.