<< Back to previous view

[CLJS-1794] incomplete alias created for namespace cljs.spec warning under advanced compilation Created: 26/Sep/16  Updated: 26/Sep/16

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

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

λ lein --version
Leiningen 2.6.1 on Java 1.8.0_45 Java HotSpot(TM) 64-Bit Server VM



 Description   

Under advanced compilation, use of cljs.spec can cause analyzer warnings.

out/cljs/analyzer.js:4740: WARNING - incomplete alias created for namespace cljs.spec
var mchk = (function (){var and__6935__auto__ = cljs.spec;
                                                ^

Sep 26, 2016 7:18:00 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 0 error(s), 1 warning(s)
Successfully compiled "out/main.js" in 43.391 seconds.


 Comments   
Comment by Michael Glaesemann [ 26/Sep/16 6:28 PM ]

I came across this when upgrading Om from alpha44 to alpha45. The commit that changed the behavior moved to from cljs to cljc for server-side rendering support. (https://github.com/omcljs/om/commit/439802239fdfb95b143cde33df26be7801069bf2)

Test case: https://gist.github.com/grzm/0d2db1d1364daeb6118b610c2fc60178

António Nuno Monteiro pointed out:
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L2666

            (let [mchk  #?(:clj  (some-> (find-ns 'clojure.spec)
                                   (ns-resolve 'macroexpand-check))
                           :cljs (and ^::no-resolve cljs.spec
                                      ^::no-resolve cljs.spec/macroexpand-check))




[CLJS-1793] Few misplaced docstrings Created: 24/Sep/16  Updated: 24/Sep/16

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

Type: Defect Priority: Trivial
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-1793.patch    

 Description   

A few docsctrings were placed after the binding form in the src/main/clojure/cljs/closure.clj namespace.






[CLJS-1792] Can't load clojure.spec.test when clojure.test.check is unavailable Created: 23/Sep/16  Updated: 23/Sep/16

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

Type: Defect Priority: Major
Reporter: Arne Brasseur Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: spec
Environment:
Unable to find source-code formatter for language: clojure. Available languages are: javascript, sql, xhtml, actionscript, none, html, xml, java
[org.clojure/clojure "1.9.0-alpha12"]
[org.clojure/clojurescript "1.9.229" :scope "provided"]


 Description   

Requiring clojure.spec.test results in an error, because it's looking for clojure.test.spec.

(ns foo.bar
  (:require [clojure.spec.test]))
Caused by: clojure.lang.ExceptionInfo: No such namespace: clojure.test.check, could not locate clojure/test/check.cljs, clojure/test/check.cljc, or Closure namespace "clojure.test.check" in file file:/home/arne/.m2/repository/org/clojure/clojurescript/1.9.229/clojurescript-1.9.229.jar!/cljs/spec/test.cljs {:tag :cljs/analysis-error}

This problem goes away when adding org.clojure/test.check as a dependency.

This is not an issue in Clojure. An exception is only raised when calling a function that relies on test.check.






[CLJS-1791] :hierarchy option of defmulti is not used to determine if one dispatch value dominates on another Created: 22/Sep/16  Updated: 22/Sep/16

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

Type: Defect Priority: Major
Reporter: Andrey Zaytsev Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug

Attachments: Text File 0001-follow-up-on-CLJS-460-defmulti-ignores-optional-hier.patch    
Patch: Code and Test

 Description   

It leads to exception on method invocation.
Patch for similar issue CLJS-460 does not address conflicting dispatch values.






[CLJS-1790] Port CLJ-1935: Use multimethod dispatch value method lookup to take hierarchies into account in multi-spec Created: 21/Sep/16  Updated: 26/Sep/16  Resolved: 26/Sep/16

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

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

Attachments: Text File CLJS-1790.patch    

 Description   

See Clojure commit: https://github.com/clojure/clojure/commit/522ba8b82ba6eb6c50284a211e7533db51363b8f



 Comments   
Comment by Lauri Oherd [ 25/Sep/16 4:53 AM ]

Code and Test

Comment by David Nolen [ 26/Sep/16 2:20 PM ]

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





[CLJS-1789] Port CLJ-1988: Extend coll-of to handle sequences Created: 21/Sep/16  Updated: 23/Sep/16  Resolved: 23/Sep/16

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

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

Attachments: Text File cljs-1789.patch    

 Description   

See Clojure commit: https://github.com/clojure/clojure/commit/edf869a0fa56df3aa2503980af65931d76e2e00b



 Comments   
Comment by Joshua Miller [ 21/Sep/16 2:56 PM ]

Adds fix and test.

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

fixed https://github.com/clojure/clojurescript/commit/7ef1ed8debc647ddef847ac85262b24bfe96c48a





[CLJS-1788] Port CLJ-2004: include retag in multi-spec form Created: 21/Sep/16  Updated: 23/Sep/16  Resolved: 23/Sep/16

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

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

Attachments: Text File CLJS-1788.patch    

 Description   

See Clojure commit:

https://github.com/clojure/clojure/commit/5e83c2ab898fefe655ee45495d56d69a6bd10304



 Comments   
Comment by Lauri Oherd [ 23/Sep/16 11:52 AM ]

Code and Test

Comment by Lauri Oherd [ 23/Sep/16 11:57 AM ]

Is it possible to edit the ticket's Patch field in order to add the "Code and Test" value to it (as described on https://github.com/clojure/clojurescript/wiki/Patches page)?
I couldn't find the Patch field.

Comment by David Nolen [ 23/Sep/16 12:56 PM ]

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





[CLJS-1787] Make cljs.spec explain pluggable Created: 21/Sep/16  Updated: 23/Sep/16  Resolved: 23/Sep/16

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

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


 Description   

See Clojure commit:

https://github.com/clojure/clojure/commit/99ab306f82620e6db6a978a5565d2ccd668c0798



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

fixed https://github.com/clojure/clojurescript/commit/8399062f0179770580f53ac331485c5e944a773c





[CLJS-1786] Add knob for controlling printing of namespaced maps Created: 21/Sep/16  Updated: 21/Sep/16

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

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


 Description   

See these Clojure commits:

https://github.com/clojure/clojure/commit/d57b5559829be8e8b3dcb28a20876b32615af0cb
https://github.com/clojure/clojure/commit/b49c1984a1527d17951fbb23ddf9406805a1343f
https://github.com/clojure/clojure/commit/05a8e8b323042fa043355b716facaed6003af324






[CLJS-1785] Warn on reference to js/foo shadowed by local binding Created: 21/Sep/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: 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





[CLJS-1784] Cleanup set creation functions Created: 20/Sep/16  Updated: 26/Sep/16

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

Type: Enhancement Priority: Minor
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

Use .fromArray for consistency/speed when handling zeroed IndexedSeqs.

Use reduce as the default construction path to take advantage of reducible collections.



 Comments   
Comment by Rohit Aggarwal [ 26/Sep/16 4:13 PM ]

Thomas Mulvaney, could you provide some benchmarks for the speed assertion? It would be nice to run it on Chrome/Firefox/Safari.





[CLJS-1783] Unify List creation code Created: 20/Sep/16  Updated: 20/Sep/16

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

Type: Enhancement Priority: Minor
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

There is some duplication and redundant functions around List creation.

In this patch a fromArray method was added to List, consistent with other persistent data structures in the code base.






[CLJS-1782] Self-host: allow namespaces to require their own macros Created: 19/Sep/16  Updated: 19/Sep/16

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

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-1782.patch    

 Description   

Currently a namespace can only require its own macros in JVM ClojureScript (called macro-loop in this post).

Because there's no reader conditional distinction between JVM and Bootstrapped ClojureScript, requiring a namespace that requires its own macros in self-host will result in the following error:

Could not require foo.core in file /Users/anmonteiro/Desktop/foo/src/foo/core.cljc
Maximum call stack size exceeded.

Below is an example that can be used to reproduce the issue:

;; foo/core.cljc
(ns foo.core
  #?(:cljs (:require-macros [foo.core])))

(defmacro a-macro [& args]
  `(println ~@args))

This ticket proposes the following solution: when loading a macros namespace in self-hosted ClojureScript, patch its `require-macros` and `use-macros` entries to remove itself, if present.



 Comments   
Comment by António Nuno Monteiro [ 19/Sep/16 9:09 PM ]

Attached patch with proposed fix.





[CLJS-1781] Add cljs.hash-map-test to self-parity tests Created: 19/Sep/16  Updated: 23/Sep/16  Resolved: 23/Sep/16

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

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

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

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

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





[CLJS-1780] Records without extmap fail to iterate Created: 15/Sep/16  Updated: 16/Sep/16  Resolved: 16/Sep/16

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

Type: Defect Priority: Major
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

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

 Description   

Calling hasNext on a Record with no extmap fails.



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

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





[CLJS-1779] keyword 2-arity constructor accepts anything for both parameters which leads to different hashing Created: 14/Sep/16  Updated: 14/Sep/16  Resolved: 14/Sep/16

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

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


 Description   
(keyword 'app "foo")
(keyword "app" "foo")

Will produce different hash codes.



 Comments   
Comment by David Nolen [ 14/Sep/16 3:05 PM ]

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





[CLJS-1778] cljs.spec.test/check only accepts literal syms, unlike clojure.spec.test/check Created: 14/Sep/16  Updated: 14/Sep/16  Resolved: 14/Sep/16

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

Type: Defect Priority: Major
Reporter: Jannis Pohlmann Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

As of commit https://github.com/clojure/clojurescript/commit/d0be39660f3a65422c3de6a774ceec0b6a863ee2, ClojureScript's implementation of `cljs.spec.test/check` only accepts a literal sym or a literal collection of syms as its inputs, e.g.

(cljs.spec.test/check 'some.ns/foo)
(cljs.spec.test/check '[some.ns/foo some.ns/bar])

It does not allow input syms to be passed in as a named value or to be generated (e.g. by filtering all checkable syms). So the following will fail:

(def test-syms '[some.ns/foo some.ns/bar])
(cljs.spec.test/check test-syms)
;; Results in an "`Unable to resolve symbol: test-syms`" error.

(cljs.spec.test/check (filter in-some-ns? (cljs.spec.test/checkable-syms)))
;; Results in an "`Unable to resolve symbol: filter`" error - I think.

This is different from the behavior of `clojure.spec.test/check` in Clojure, where all of the above are fine. Is this a bug or a deliberate difference?



 Comments   
Comment by David Nolen [ 14/Sep/16 3:35 PM ]

This is just how it works. Most of the clojure.spec.test/check must necessarily be implemented as macros.





[CLJS-1777] `module` undefined when using `:module-type :commonjs` Created: 14/Sep/16  Updated: 14/Sep/16

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

Type: Enhancement Priority: Major
Reporter: Arne Brasseur Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The Google Closure Compiler support for CommonJS modules rewrites `exports` and `module.exports`, but not `module`. Many libraries try to detect the module type (CommonJS) by checking the type of `module`, e.g. this is taken from D3.

```
typeof exports === 'object' && typeof module !== 'undefined'
```

This becomes

```
goog.provide('module$resource$d3')
typeof module$resource$d3 === 'object' && typeof module !== 'undefined'
```

Because `module` is undefined this fails, and nothing gets exported.

This seems like something Google Closure should address.

Alternatives would include injecting some code that defines `module` (`var module={}`) or munging `typeof module` to `"object"`.



 Comments   
Comment by Arne Brasseur [ 14/Sep/16 6:41 AM ]

To test

curl https://d3js.org/d3.v4.js > d3.js

Compiler options

:foreign-libs [{:file "d3.js"
:provides ["d3"]
:module-type :commonjs}]

Code

(:require '[d3])
(d3/select "#app")

Comment by Arne Brasseur [ 14/Sep/16 8:32 AM ]

Seems this exact case was already documented on Maria Geller's blog: http://mneise.github.io/posts/2015-07-08-week-6.html

Comment by Arne Brasseur [ 14/Sep/16 9:04 AM ]

Did some more digging, the issue is that thanks to http://dev.clojure.org/jira/browse/CLJS-1312 Closure Compiler tries to deal with UMD syntax, but there's no single definition of what UMD really looks like. Two popular tools (rollup and webpack) generate code that is not correctly recognized. This is what rollup generates

(function (global, factory) {
  typeof exports === 'object' && typeof module !== 'undefined' ? factory(exports) :
  typeof define === 'function' && define.amd ? define(['exports'], factory) :
  (factory((global.d3 = global.d3 || {})));
}(this, (function (exports) { 'use strict';

This is what webpack generates

(function webpackUniversalModuleDefinition(root, factory) {
	if(typeof exports === 'object' && typeof module === 'object')
		module.exports = factory(require("react"), require("react-dom"));
	else if(typeof define === 'function' && define.amd)
		define(["react", "react-dom"], factory);
	else if(typeof exports === 'object')
		exports["ReactDataGrid"] = factory(require("react"), require("react-dom"));
	else
		root["ReactDataGrid"] = factory(root["React"], root["ReactDOM"]);
})(this, function(__WEBPACK_EXTERNAL_MODULE_1__, __WEBPACK_EXTERNAL_MODULE

This will require changes to ProcessCommonJSModulesTest, similar to https://github.com/google/closure-compiler/commit/aa0a99cf380b05b2185156735d023b6fa78ec4ac





[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: 0
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-1775] `get` with `nil` returns as if `get` with `0` Created: 12/Sep/16  Updated: 16/Sep/16  Resolved: 16/Sep/16

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

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

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

 Description   

Calling `(get "test" nil)` returns `"t"` whereas previously it would return `nil`, as is the case in clojure.



 Comments   
Comment by António Nuno Monteiro [ 12/Sep/16 3:52 PM ]

Attached patch with fix and test.

Comment by David Nolen [ 14/Sep/16 3:36 PM ]

This patch needs a rebase it seems.

Comment by António Nuno Monteiro [ 14/Sep/16 3:42 PM ]

Replaced the patch with a rebased version.

Comment by Thomas Mulvaney [ 14/Sep/16 6:12 PM ]

Would it not be better to check if k is an integer rather than non-nil value when calling get on indexed collections?

Comment by António Nuno Monteiro [ 14/Sep/16 6:23 PM ]

It's not really how Clojure works, AFAICT:

boot.user=> (get "asd" 1.7)
\s
Comment by David Nolen [ 16/Sep/16 1:23 PM ]

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





[CLJS-1774] Self-host: Report filenames in warns in test-self-parity Created: 07/Sep/16  Updated: 14/Sep/16  Resolved: 14/Sep/16

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

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

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

 Description   

When running script/test-self-parity, make use of the new feature introduced with CLJS-1515 to add the capability of reporting filenames when diagnostics are emitted.

For example, you currently see

WARNING: baz is a single segment namespace at line 1

when running script/test-self-parity while script/test gives more info for the same diagnostic:

WARNING: baz is a single segment namespace at line 1 src/test/cljs/baz.cljs


 Comments   
Comment by David Nolen [ 14/Sep/16 3:37 PM ]

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





[CLJS-1773] Self-host: Don't resolve unqualified symbols / keywords with $macros Created: 05/Sep/16  Updated: 16/Sep/16  Resolved: 16/Sep/16

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

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

Attachments: Text File CLJS-1773.patch    

 Description   

Background: Since, in self-hosted ClojureScript, macro namespaces are compiled as ClojureScript, a $macros suffix is appended to macros namespace names in order to differentiate them from same-named runtime namespaces. As a concrete example: The foo.core runtime namespace will be processed normally, but the same, when compiled as a macro namespace is internally renamed to be foo.core$macros.

A consequence is that the internal $macros suffix surfaces in a few places where it is undesired. Specifically this ticket focuses on the cases of unqualified symbols subject to syntax-quote resolution and namespaced keywords that use the :: construct (as in ::bar). When these are used in macro namespaces, and then compiled with bootstrapped ClojureScript, a symbol like `baz would turn in to foo.core$macros/baz, and a keyword like ::bar would turn in to :foo.core$macros/bar.

In the case of symbols, it might be the case that the user wanted the symbol to refer to a var in the runtime namespace, in which case foo.core/baz is desired. And, even if the desire was that it end up referring to a macro named baz, then foo.core/baz works just fine. To achieve this, when porting regular ClojureScript code to be compatible with bootstrapped ClojureScript, one common pattern is the need to qualify symbols inside of syntax-quote scope so that they don't end up with the $macros suffix.

The same, parallel arguments essentially go for keywords: You want ::bar to turn into :foo.core/bar in both JVM and bootstrapped ClojureScript, and today, to achieve that, you must qualify those kinds of keywords when they appear in macros namespaces.

This ticket asks that when unqualified symbols in syntax quote are resolved and when the analogous thing occurs for keywords, that the $macros suffix be avoided as experience has shown now that it is practically always not the thing that you want (and perhaps also not correct from the desired language semantics.)



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

fixed https://github.com/clojure/clojurescript/commit/7e90ad51452ec5edd8ee7f2b7af9c7e7fb759c97





[CLJS-1772] Dependency index can incorrectly add `.cljc` files instead of `.cljs` if both are present Created: 02/Sep/16  Updated: 03/Sep/16  Resolved: 03/Sep/16

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

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1772.patch    

 Comments   
Comment by António Nuno Monteiro [ 02/Sep/16 10:09 PM ]

Attached patch with fix.

Comment by David Nolen [ 03/Sep/16 7:37 AM ]

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





[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-1770] goog-defines broken for integers Created: 01/Sep/16  Updated: 16/Sep/16  Resolved: 16/Sep/16

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

Type: Defect Priority: Minor
Reporter: Tom Connors Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: closure

Attachments: Text File CLJS-1770.patch    

 Description   

Using goog-define with integer values results in cljs.closure/make-options attempting to call .setDefineToIntegerLiteral on the compiler-options object. That method does not exist; the correct method is .setDefineToNumberLiteral. Note however that calls to .setDefineToNumberLiteral will fail when the value is a long; it might make sense to always use .setDefineToDoubleLiteral when the value is a number. Integers passed to .setDefineToDoubleLiteral remain integers in the output javascript, so it seems harmless enough to do it that way.



 Comments   
Comment by Tom Connors [ 02/Sep/16 8:55 AM ]

Patch for using setDefineToDoubleLiteral for all numbers.

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

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





[CLJS-1769] Use reduce pathway for arrays in js->clj Created: 01/Sep/16  Updated: 01/Sep/16

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

Type: Enhancement Priority: Trivial
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

Currently js->cljs uses `(vec (map some-fn some-js-array))` on arrays. By using `(mapv some-fn some-js-array)` we take advantage of array-reduce and avoid a lazy-sequence.






[CLJS-1768] cljs.spec perf tweaks Created: 31/Aug/16  Updated: 31/Aug/16

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

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


 Description   

Same as the following commits:

https://github.com/clojure/clojure/commit/de6a2b528a18bcb4768e82d0d707d2cab26268a6
https://github.com/clojure/clojure/commit/defa7b8ef268ea2b8772658ade2010ca5ad00dc4






[CLJS-1767] Make spec explain printer pluggable Created: 31/Aug/16  Updated: 23/Sep/16  Resolved: 23/Sep/16

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

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


 Description   

Same as https://github.com/clojure/clojure/commit/99ab306f82620e6db6a978a5565d2ccd668c0798



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

http://dev.clojure.org/jira/browse/CLJS-1787





[CLJS-1766] Set literals in REPL end up reified as ArrayMap backed PersistentHashSets. Created: 28/Aug/16  Updated: 28/Aug/16

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

Type: Defect Priority: Minor
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: repl


 Description   

Entering a set literal in the REPL with more than 8 elements should create a PHM backed set but instead it is array backed.

Example (in REPL):
cljs.user=> (type (.-hash-map #{1 2 3 4 5 6 7 8 9}))
cljs.core/PersistentArrayMap

This means operations such as `get` and `contains?` end up doing long scans and are slower than a user would expect.






[CLJS-1765] Empty iterator for some hash maps with a nil key Created: 27/Aug/16  Updated: 19/Sep/16  Resolved: 19/Sep/16

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

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

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

 Description   

Two specific examples:

cljs.user=> (.hasNext (-iterator {:a 1 :b 2 :c 3 :d 4 :e 5 :f 6 :g 7 :h 8 nil 9}))
false
cljs.user=> (.hasNext (-iterator (hash-map nil 1))))
false

This can affect "user-level" code as follows:

cljs.user=> (sequence (map identity) {:a 1 :b 2 :c 3 :d 4 :e 5 :f 6 :g 7 :h 8 nil 9})
()
cljs.user=> (sequence (map identity) (hash-map nil 1))
()


 Comments   
Comment by Thomas Mulvaney [ 27/Aug/16 5:27 PM ]

I've attached a simple patch with some tests.

Comment by Mike Fikes [ 27/Aug/16 6:22 PM ]

Confirmed CA at http://clojure.org/community/contributors

Comment by Mike Fikes [ 27/Aug/16 6:35 PM ]

The first ^boolean in the form (or ^boolean (not seen) ^boolean (.hasNext root-tier)) could be omitted.

The patch passes unit tests for me (both JVM and self-host) and causes the correct output to appear for the examples

Comment by Thomas Mulvaney [ 28/Aug/16 4:05 AM ]

Thanks Mike Fikes, I omitted that boolean flag per your suggestion. Updated patch now attached.

Comment by David Nolen [ 14/Sep/16 3:40 PM ]

This patch needs a rebase.

Comment by Thomas Mulvaney [ 14/Sep/16 6:06 PM ]

Most recent patch is rebased.

Comment by David Nolen [ 16/Sep/16 1:30 PM ]

This ticket needs a rebase again. We should probably consider breaking up our core tests into individual namespaces.

Comment by Thomas Mulvaney [ 16/Sep/16 8:47 PM ]

I would be happy to put the tests in a new namespace. Does `src/test/cljs/cljs/hash_map_test.cljs` sound sensible?

Comment by Thomas Mulvaney [ 18/Sep/16 8:27 PM ]

Newest patch has been rebased and tests were split out into the namespace I proposed in previous comment.

Comment by David Nolen [ 19/Sep/16 8:29 AM ]

fixed https://github.com/clojure/clojurescript/commit/7923f80fd50b3a7d1f808dd746758a1375a8e25d





[CLJS-1764] Double warning for undeclared Var Created: 26/Aug/16  Updated: 16/Sep/16

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

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


 Description   

A regression occurred where an undeclared Var in a {{require}}d file causes two diagnostics:

$ more src/foo/core.cljs
(ns foo.core)

(def x 2)

abc
$ rm -rf .cljs_node_repl
$ java -cp cljs-1.9.227.jar:src clojure.main -m cljs.repl.node
ClojureScript Node.js REPL server listening on 52749
To quit, type: :cljs/quit
cljs.user=> *clojurescript-version*
"1.9.227"
cljs.user=> (require 'foo.core)
WARNING: Use of undeclared Var foo.core/abc at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
WARNING: Use of undeclared Var foo.core/abc at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
nil
cljs.user=> :cljs/quit
$ rm -rf .cljs_node_repl
$ java -cp cljs-1.9.211.jar:src clojure.main -m cljs.repl.node
ClojureScript Node.js REPL server listening on 56704
To quit, type: :cljs/quit
cljs.user=>  *clojurescript-version*
"1.9.211"
cljs.user=> (require 'foo.core)
WARNING: Use of undeclared Var foo.core/abc at line 5 /Users/mfikes/Desktop/src/foo/core.cljs
nil
cljs.user=> :cljs/quit


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

If somebody wants to do a git bisect to sort this one out, that would be awesome





[CLJS-1763] Defining a var that clashes with `cljs.core` throws a compiler error instead of warning Created: 24/Aug/16  Updated: 24/Aug/16  Resolved: 24/Aug/16

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

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

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

 Comments   
Comment by António Nuno Monteiro [ 24/Aug/16 10:43 AM ]

Attached patch with fix and test.

Comment by David Nolen [ 24/Aug/16 11:40 AM ]

fixed https://github.com/clojure/clojurescript/commit/7a06d008fadf56b11dba0f9e2ab97e61059f44fc





[CLJS-1762] Bump Closure Compiler Created: 22/Aug/16  Updated: 15/Sep/16

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

Type: Task Priority: Minor
Reporter: António Nuno Monteiro Assignee: Juho Teperi
Resolution: Unresolved Votes: 0
Labels: closure

Attachments: Text File CLJS-1762.patch    

 Description   

A new version of the Closure Compiler features an optimization that results in faster compilation, as well as some some changes to ES6-related features.



 Comments   
Comment by Juho Teperi [ 27/Aug/16 4:39 AM ]

Here is my version of the change.

Updating cljs.closure was quite straightforward, just removed all the checks and changed a few constructor calls.

I think I found all places to update the Closure version: pom.template.xml, project.clj and script/bootstrap. Bootstrap script also needed a change to account for changes closure-compiler filename.

  • ES6ModuleLoader has been replaced with ModuleLoader, it no longer
    needs to be passed to ProcessCommonJSModules etc. constructors
  • This version requires the version 20160822 and any checks needed to
    work with older versions have been removed
  • Closure-compiler jar name has been changed so lib/ and closure/
    directories should be removed before running bootstrap
Comment by Juho Teperi [ 27/Aug/16 4:55 AM ]

While tests pass with the patch, looks like module processing is broken. Tested with https://github.com/mneise/circle-color

Comment by Juho Teperi [ 15/Sep/16 5:19 AM ]

Current WIP branch at https://github.com/clojure/clojurescript/compare/master...Deraen:cljs-1762

I started writing some tests for module processing based on Mneise's circle-color example. I heavily simplified React UMD module and JSX processing for the tests, but not yet very happy with this method. Probably best to write the JS for tests from scratch.

Currently stuck on getting Closure compiler to return the processed code: https://github.com/clojure/clojurescript/compare/master...Deraen:cljs-1762#diff-84ffd22349e5ca1fe6322cb0e379b3b1R1530





[CLJS-1761] Allow parallel Transit analysis cache writes Created: 19/Aug/16  Updated: 19/Sep/16

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

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

Attachments: Text File CLJS-1761.patch    

 Description   

With CLJS-1759, Transit analysis cache writes are being serialized. This ticket asks that analysis be done to find the root cause, so we can fix it and removed the workaround in CLJS-1759.



 Comments   
Comment by Francis Avila [ 19/Aug/16 1:53 PM ]

I suspect these lines in transit are a race condition:

https://github.com/cognitect/transit-java/blob/3f359c434264f675460bc2662dde2a1b2d8e9559/src/main/java/com/cognitect/transit/impl/WriterFactory.java#L74-L76

newHandlerCache is a cognitect.transit.impl.Cache instance, which is just a normal LinkedHashMap with size 10.

In between the containsKey() call and the get() call a cached item may have been evicted, causing the JsonEmitter to have a null map handler, causing the "Not supported: class java.lang.Integer" exception to bubble out of the emit() call inside write().

I think the fix is to call newHandlerCache.get(customHandlers) by itself and check for null instead of looking up twice. (I am not a seasoned Java dev, so I am not sure if concurrent reads are safe here without synchronization.) The synchronized block should probably also monitor the cache itself instead of the factory class.

Comment by Francis Avila [ 19/Aug/16 1:55 PM ]

Also, all of this is just from reading the code and your stacktrace, i.e., it is purely hypothesis.

Comment by Francis Avila [ 19/Aug/16 2:19 PM ]

On the other hand, the transit writer is created repeatedly with the same handler map instance, so I don't know why the write handler cache would ever have more than one entry (its limit is 10).

Comment by Mike Fikes [ 19/Aug/16 10:38 PM ]

Francis has logged a ticket against transit-java https://github.com/cognitect/transit-java/issues/20 and I've done some further experimentation and recorded what I found in that ticket.

Comment by Francis Avila [ 22/Aug/16 7:04 AM ]

This patch uses write-handler-map and read-handler-map to completely pre-assemble the transit handler maps and sidestep all handler cache construction caching. (I think this is a good thing to do even without these transit problems.)

If there are indeed races related handler construction and caching, this patch should sidestep them all and allow fully parallel use of transit.

Comment by David Nolen [ 16/Sep/16 1:48 PM ]

fixed https://github.com/clojure/clojurescript/commit/92459050162fce53312d9df7d7b5c703d2d992c2

Comment by Mike Fikes [ 16/Sep/16 7:47 PM ]

CLJS-1761.patch does not resolve this issue. With it applied the failures as described in CLJS-1759 occur.

Comment by Mike Fikes [ 16/Sep/16 8:02 PM ]

I have failed to create a repro for CLJS-1759 that does not involve any downstream tooling (and it also appears to require a multicore box). For reference and for the record, the specific steps used to reproduce the issue are at https://github.com/cognitect/transit-java/issues/20#issuecomment-241312648 (and, if you happen to have access to box that can repro, you can confirm that ClojureScript master with this patch doesn't resolve the issue by editing the project.clj in the referenced downstream project to use a locally-built ClojureScript master).

Comment by David Nolen [ 19/Sep/16 8:31 AM ]

Thanks for the confirmation that the issue is not resolved.





[CLJS-1760] Self-host: test-cljs-1757 failing in test-self-parity Created: 19/Aug/16  Updated: 19/Aug/16  Resolved: 19/Aug/16

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

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

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

 Description   
$ script/test-self-parity
Testing with Node
WARNING: baz is a single segment namespace at line 1
WARNING: Use of undeclared Var cljs.spec$macros/gen at line 77

Testing cljs.core-test

Testing cljs.reader-test

Testing clojure.string-test

Testing clojure.data-test

Testing cljs.letfn-test

Testing cljs.reducers-test

Testing cljs.binding-test

Testing cljs.macro-test

Testing cljs.top-level

Testing cljs.ns-test.foo

Testing foo.ns-shadow-test

Testing cljs.import-test

Testing cljs.spec-test

ERROR in (test-cljs-1757) (TypeError:NaN:NaN)
expected: (s/exercise-fn (quote cljs.spec-test/cljs-1757-x))
  actual: #object[TypeError TypeError: Cannot read property 'call' of undefined]

Testing cljs.clojure-alias-test

Ran 215 tests containing 17428 assertions.
0 failures, 1 errors.


 Comments   
Comment by António Nuno Monteiro [ 19/Aug/16 10:25 AM ]

Attached path with fix.

Comment by Mike Fikes [ 19/Aug/16 10:39 AM ]

LGTM. It is the “correct” fix; I missed when putting together CLJS-1720. All tests pass for me with António's patch.

Comment by David Nolen [ 19/Aug/16 10:42 AM ]

fixed https://github.com/clojure/clojurescript/commit/86a83d720beb44deb5d55d7d9c0bc2d5174816a3





[CLJS-1759] Errors writing transit analysis cache if parallel build Created: 19/Aug/16  Updated: 19/Aug/16  Resolved: 19/Aug/16

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

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

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

 Description   
  1. It fails only if parallel builds enabled
  2. When so, it fails, maybe 30 to 50% of the time
  3. If I put a coarse-grained mutex around the write calls, it succeeds
  4. It appears to occur under heave write load 3 concurrent writes

Here is an example of one of the failures:

Exception in thread "main" clojure.lang.ExceptionInfo: failed compiling file:out/cljs/source_map/base64.cljs {:file #object[java.io.File 0x125a8ab6 "out/cljs/source_map/base64.cljs"]}, compiling:(/Users/mfikes/Projects/planck/planck-cljs/script/build.clj:16: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:out/cljs/source_map/base64.cljs {:file #object[java.io.File 0x125a8ab6 "out/cljs/source_map/base64.cljs"]}
        at clojure.core$ex_info.invokeStatic(core.clj:4617)
        at clojure.core$ex_info.invoke(core.clj:4617)
        at cljs.compiler$compile_file$fn__3456.invoke(compiler.cljc:1386)
        at cljs.compiler$compile_file.invokeStatic(compiler.cljc:1352)
        at cljs.compiler$compile_file.invoke(compiler.cljc:1332)
        at cljs.closure$compile_file.invokeStatic(closure.clj:474)
        at cljs.closure$compile_file.invoke(closure.clj:465)
        at cljs.closure$eval5203$fn__5204.invoke(closure.clj:541)
        at cljs.closure$eval5139$fn__5140$G__5128__5147.invoke(closure.clj:431)
        at cljs.closure$compile_from_jar.invokeStatic(closure.clj:523)
        at cljs.closure$compile_from_jar.invoke(closure.clj:511)
        at cljs.closure$eval5209$fn__5210.invoke(closure.clj:551)
        at cljs.closure$eval5139$fn__5140$G__5128__5147.invoke(closure.clj:431)
        at cljs.closure$compile_task$fn__5294.invoke(closure.clj:821)
        at cljs.closure$compile_task.invokeStatic(closure.clj:819)
        at cljs.closure$compile_task.invoke(closure.clj:812)
        at cljs.closure$parallel_compile_sources$fn__5300.invoke(closure.clj:848)
        at clojure.lang.AFn.applyToHelper(AFn.java:152)
        at clojure.lang.AFn.applyTo(AFn.java:144)
        at clojure.core$apply.invokeStatic(core.clj:646)
        at clojure.core$with_bindings_STAR_.invokeStatic(core.clj:1881)
        at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1881)
        at clojure.lang.RestFn.invoke(RestFn.java:425)
        at clojure.lang.AFn.applyToHelper(AFn.java:156)
        at clojure.lang.RestFn.applyTo(RestFn.java:132)
        at clojure.core$apply.invokeStatic(core.clj:650)
        at clojure.core$bound_fn_STAR_$fn__4671.doInvoke(core.clj:1911)
        at clojure.lang.RestFn.invoke(RestFn.java:397)
        at clojure.lang.AFn.run(AFn.java:22)
        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)
Caused by: java.lang.RuntimeException: java.lang.Exception: Not supported: class java.lang.Integer
        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:3127)
        at cljs.analyzer$write_analysis_cache.invoke(analyzer.cljc:3114)
        at cljs.compiler$emit_source.invokeStatic(compiler.cljc:1283)
        at cljs.compiler$emit_source.invoke(compiler.cljc:1232)
        at cljs.compiler$compile_file_STAR_$fn__3433.invoke(compiler.cljc:1304)
        at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1154)
        at cljs.compiler$with_core_cljs.invoke(compiler.cljc:1145)
        at cljs.compiler$compile_file_STAR_.invokeStatic(compiler.cljc:1293)
        at cljs.compiler$compile_file_STAR_.invoke(compiler.cljc:1289)
        at cljs.compiler$compile_file$fn__3456.invoke(compiler.cljc:1374)
        ... 29 more


 Comments   
Comment by Mike Fikes [ 19/Aug/16 9:48 AM ]

The attached patch introduces a coarse-grained mutex as indicated in item (3) of the description, providing a work-around for the issue.

Comment by Mike Fikes [ 19/Aug/16 10:43 AM ]

A follow up enhancement ticket that would potentially lead to removing the (presumed) workaround in the patch: CLJS-1761

Comment by David Nolen [ 19/Aug/16 10:44 AM ]

fixed https://github.com/clojure/clojurescript/commit/002708e530b6b3449151d3d077883beeadb92f94





[CLJS-1758] QuickStart guide fails at browser REPL step with "TypeError: parentElm is null" Created: 18/Aug/16  Updated: 18/Aug/16  Resolved: 18/Aug/16

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

Type: Defect Priority: Minor
Reporter: Tim McCormack Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

When I follow http://clojurescript.org/guides/quick-start up to the browser REPL step, I get an error in the browser console and the REPL never connects. The browser error is TypeError: parentElm is null on line 482 of crosspagechannel.js: parentElm.appendChild(iframeElm);.

I have put up a self-contained example to demonstrate the bug: https://github.com/timmc/sscce-CLJS-1758

  • I am using this command to run the REPL: rlwrap java -cp cljs-1.9.216.jar:src clojure.main repl.clj
  • Refreshing the browser does not help.
  • Using Chromium 52.0.2743.116 instead of Firefox ESR 45.3.0 does not help.
$ java -version
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

$ uname -a
Linux bc-timmc 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux
(Debian GNU/Linux 8.5)


 Comments   
Comment by Tim McCormack [ 18/Aug/16 11:27 AM ]

CLJS 1.9.89 fails the same way.

Comment by António Nuno Monteiro [ 18/Aug/16 11:51 AM ]

Not a bug. Your index.html file needs to at least have a `<body>` tag.
All html examples in the quickstart provide valid HTML, you just chose not to use it.

Comment by Tim McCormack [ 18/Aug/16 12:41 PM ]

Ah, of course! I compared the other files with the demo, but not that one!

I could have sworn the body element was always created automatically in the DOM whether or not it was declared. TIL.

(And confirmed, it works now.)

ETA: Not sure which resolution to pick, so leaving open.





[CLJS-1757] cljs.spec/exercise-fn doesn't work when passed a quoted symbol Created: 17/Aug/16  Updated: 17/Aug/16  Resolved: 17/Aug/16

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

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: spec

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

 Description   
cljs.user=> (require '[clojure.spec :as s])
nil
cljs.user=> (defn a [b] 2)
#'cljs.user/a
cljs.user=> (s/fdef a :args (s/cat ::first number?) :ret #(= % 2))
cljs.user/a
cljs.user=> (s/exercise-fn `a)
clojure.lang.ExceptionInfo: Assert failed: (symbol? sym) at line 1 <cljs repl> {:file "<cljs repl>", :line 1, :column 1, :root-source-info {:source-type :fragment, :source-form (s/exercise-fn (quote cljs.user/a))}, :tag :cljs/analysis-error}


 Comments   
Comment by António Nuno Monteiro [ 17/Aug/16 12:31 PM ]

Attached patch with fix and test.

Comment by David Nolen [ 17/Aug/16 7:32 PM ]

fixed https://github.com/clojure/clojurescript/commit/74db88011dd6dd64f55521f074f0315231be0e12





[CLJS-1756] Add test.check JAR to the bootstrap script Created: 17/Aug/16  Updated: 18/Aug/16  Resolved: 18/Aug/16

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

Type: Enhancement Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

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

 Comments   
Comment by António Nuno Monteiro [ 17/Aug/16 10:03 AM ]

Added patch with fix.

Comment by David Nolen [ 18/Aug/16 3:59 PM ]

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





[CLJS-1755] Support sourcesContent in source maps Created: 16/Aug/16  Updated: 16/Aug/16

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

Type: Enhancement Priority: Minor
Reporter: Daniel Compton Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: sourcemap


 Description   

This issue adds sourcesContent support for source maps: https://github.com/google/closure-compiler/issues/1890. This means that your source maps can include your source as well in one bundled file. This makes handling sourcemaps much easier for things like error tracking services. It could also simplify config for source mapping as everything is included in the source map and you don't need to specify relative paths, e.t.c.

This will need to wait for the next release of the Closure Compiler.






[CLJS-1754] Add boolean? generator Created: 16/Aug/16  Updated: 17/Aug/16  Resolved: 17/Aug/16

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

Type: Defect Priority: Major
Reporter: Matt Burbidge Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: cljs, spec

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

 Description   

In clojure I can do
`(gen/generate (s/gen int?)) ;; => 1094`
or
`(gen/generate (s/gen boolean?)) ;; => false`.

In clojurescript I can do
`(gen/generate (s/gen int?)) ;; => -308`.
But in clojurescript I can't do
`(gen/generate (s/gen boolean?)) ;; => Error: Unable to construct gen at: [] for: function cljs$core$boolean_QMARK_{return (x === true) || (x === false);}].`

As far as I can tell it's because there is no boolean generator.



 Comments   
Comment by António Nuno Monteiro [ 17/Aug/16 10:04 AM ]

Added patch with fix and test.

Note that running self parity tests now depends on CLJS-1756 being in place.

Comment by David Nolen [ 17/Aug/16 10:40 AM ]

fixed https://github.com/clojure/clojurescript/commit/2a7454837244cf7de3dfed1e48f46f86c33a1809





[CLJS-1753] cljs.pprint does not print default tagged literals/elements Created: 16/Aug/16  Updated: 16/Aug/16

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

Type: Defect Priority: Major
Reporter: Miroslav Kubicek Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug
Environment:

Win 7 64bit



 Description   

Hi there!
I am having troubles making the cljs pretty print (cljs.pprint/pprint) behave the same way as the regular cljs or clj print function when it goes down to tagged elements that are by default used to denote custom records.

See example below - pr, pr-str, print and print-str functions all use the default approach toward creating (edn-like) tagged element for MyRecord and all produce the same result:
#cljs.user.MyRecord{:value "a"}

On the other hand pprint just ignores the record's tag and simply just traverses/prints it as a map:
{:value "a"}

Is there some setting and/or parameter in cljs.pprint namespace I am missing? I looked briefly at the code, but it seems it uses print-str by default - so maybe it just traverses the graph depth-first and does not check for every node's type? At this stage this seems like a bug to me as the expected behavior of the pprint function is that it would behave the same way print and other core functions do.

THIS WORKS:

cljs.user=> (defrecord MyRecord [value])
cljs.user/MyRecord
cljs.user=> (pr (MyRecord. "a"))
#cljs.user.MyRecord{:value "a"}
nil
cljs.user=> (pr-str (MyRecord. "a"))
"#cljs.user.MyRecord{:value \"a\"}"
cljs.user=> (print (MyRecord. "a"))
#cljs.user.MyRecord{:value a}
nil
cljs.user=> (print-str (MyRecord. "a"))
"#cljs.user.MyRecord{:value a}"

BUT THIS DOESN'T:

cljs.user=> (cljs.pprint/pprint (MyRecord. "a"))
{:value "a"}
("{:value \"a\"}\n")
cljs.user=> (with-out-str (cljs.pprint/pprint (MyRecord. "a")))
"{:value \"a\"}\n"

According to github the head revision of the cljs.pprint namespace has not changed since 1.7.28 so I'd assume all versions up to the current one are affected.

Thanks for help!






[CLJS-1752] stest/instrument never throws or :ret and :fn Created: 16/Aug/16  Updated: 16/Aug/16  Resolved: 16/Aug/16

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

Type: Defect Priority: Minor
Reporter: Jan Hein Hoogstad Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: cljs, spec


 Description   

When I replace the spec for the following function:

(defn create [query]
  (with-meta (map->Query query) {:spec ::specs/query}))

from:

(spec/fdef create
           :args (spec/cat :query ::specs/query)
           :ret ::specs/query
           :fn #(spec/valid? ::specs/meta (-> %1 :ret :meta)))

(stest/instrument `create)

to

(spec/fdef create
           :args (spec/cat :query ::specs/query)
           :ret string?
           :fn #(spec/valid? ::specs/meta (-> %1 :ret :meta)))

(stest/instrument `create)

it does not throw. As a matter of fact, I didn't get it to throw on any value that I give the :ret and :fn function. Removing the record with a plain map did not make a difference...



 Comments   
Comment by David Nolen [ 16/Aug/16 10:24 AM ]

This is by design.

Comment by Jan Hein Hoogstad [ 16/Aug/16 10:34 AM ]

Thanks for the quick reply, but it is not clear to me why? Can you maybe point me to an explanation?

Cheer!

Comment by Jan Hein Hoogstad [ 16/Aug/16 11:06 AM ]

Never mind, found it. Hadn't noticed it before...





[CLJS-1751] port fix lost type hints in map destructuring Created: 15/Aug/16  Updated: 18/Aug/16  Resolved: 18/Aug/16

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

Type: Enhancement Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

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

 Comments   
Comment by António Nuno Monteiro [ 15/Aug/16 3:24 PM ]

Attached patch with fix.

Comment by David Nolen [ 18/Aug/16 4:08 PM ]

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





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

Status: Resolved
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-1749] Missing `cljs.spec.impl.gen/double*` Created: 15/Aug/16  Updated: 15/Aug/16  Resolved: 15/Aug/16

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

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

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

 Comments   
Comment by António Nuno Monteiro [ 15/Aug/16 12:05 PM ]

Attached patch with fix.

Comment by David Nolen [ 15/Aug/16 12:53 PM ]

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





[CLJS-1748] Nth doesn't throw error for strings or arrays Created: 15/Aug/16  Updated: 19/Sep/16  Resolved: 19/Sep/16

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

Type: Defect Priority: Minor
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

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

 Description   

Calling nth on a string or array with an out of bounds index should throw an error but returns an empty string or nil.

(nth "012" 3) -> ""
(nth (array 0 1 2) 3) nil

Calling nth on a string or array with a negative index and a not-found value returns an empty string or nil.

(nth "012" -1 :not-found) -> ""
(nth (array 0 1 2) -1 :not-found) nil



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

This one needs a rebase.

Comment by Thomas Mulvaney [ 18/Sep/16 8:45 PM ]

Rebased patch attached. Also fixed inconsistent capitalisation on some of the errors being thrown.

Comment by David Nolen [ 19/Sep/16 8:25 AM ]

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





[CLJS-1747] Port `clojure.spec/assert` over to ClojureScript Created: 15/Aug/16  Updated: 15/Aug/16  Resolved: 15/Aug/16

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

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

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

 Comments   
Comment by António Nuno Monteiro [ 15/Aug/16 11:28 AM ]

Attached patch with fix and test.

Comment by David Nolen [ 15/Aug/16 12:52 PM ]

fixed https://github.com/clojure/clojurescript/commit/862950da92581b60abc3bc615305461a7e1c1bfb





[CLJS-1746] Log the result of loading a dependency Created: 14/Aug/16  Updated: 15/Aug/16  Resolved: 15/Aug/16

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

Type: Enhancement Priority: Trivial
Reporter: Andrea Richiardi Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1746.patch    

 Description   

It would be great to add a (debug-prn "Loading result: " res) in load-deps so that we see in the logs why a dependency failed to load.
It is a one line patch and I can take care of it.



 Comments   
Comment by Andrea Richiardi [ 14/Aug/16 9:16 PM ]

Patch attached

Comment by David Nolen [ 15/Aug/16 7:41 AM ]

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





[CLJS-1745] refer-clojure doesn't pull in previously excluded vars Created: 14/Aug/16  Updated: 14/Aug/16

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

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


 Description   

Observe this behavior in Clojure:

user=> (ns foo.core (:refer-clojure :exclude [juxt partial]))
nil
foo.core=> juxt
CompilerException java.lang.RuntimeException: Unable to resolve symbol: juxt in this context, compiling:(NO_SOURCE_PATH:0:0)
foo.core=> partial
CompilerException java.lang.RuntimeException: Unable to resolve symbol: partial in this context, compiling:(NO_SOURCE_PATH:0:0)
foo.core=> (refer-clojure :exclude [])
nil
foo.core=> juxt
#object[clojure.core$juxt 0x2f62ea70 "clojure.core$juxt@2f62ea70"]
foo.core=> partial
#object[clojure.core$partial 0x38aa816f "clojure.core$partial@38aa816f"]

Compare with ClojureScript:

$ script/noderepljs
ClojureScript Node.js REPL server listening on 49402
To quit, type: :cljs/quit
cljs.user=> (ns foo.core (:refer-clojure :exclude [juxt partial]))
nil
foo.core=> juxt
nil
foo.core=> partial
nil
foo.core=> (refer-clojure :exclude [])
nil
foo.core=> juxt
nil
foo.core=> partial
nil





[CLJS-1744] rest produces nil for larger maps Created: 13/Aug/16  Updated: 14/Aug/16  Resolved: 14/Aug/16

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

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


 Description   

CLJS-1739 illustrated an error where rest can produce nil for maps of size 9 or larger.

With code like this

(doseq [i (range 1 20)]
  (prn [i (last (take (inc i) (iterate rest (zipmap (range i) (range i)))))]))

you can demonstrate that while CLJS-1739 addressed it for 9, a similar issue occurs at 17.



 Comments   
Comment by David Nolen [ 13/Aug/16 10:54 PM ]

You mean rest not next, right?

Comment by Mike Fikes [ 13/Aug/16 11:07 PM ]

Yes, the first sentence in the description should have said rest can produce nil.

The doseq above produces output that looks like this (note how it produces nil values starting at 17:

[1 ()]
[2 ()]
[3 ()]
[4 ()]
[5 ()]
[6 ()]
[7 ()]
[8 ()]
[9 ()]
[10 ()]
[11 ()]
[12 ()]
[13 ()]
[14 ()]
[15 ()]
[16 ()]
[17 nil]
[18 nil]
[19 nil]
nil
Comment by David Nolen [ 14/Aug/16 8:25 AM ]

fixed https://github.com/clojure/clojurescript/commit/709cc57d003590945329ea8745b799e75ac4ba88





[CLJS-1743] Transient{Hash,Array}Map should support IFn like in Clojure Created: 13/Aug/16  Updated: 13/Aug/16

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

Type: Enhancement Priority: Trivial
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

Users should be able to invoke transient maps like in Clojure.






[CLJS-1742] Add docstring for new refer-clojure REPL special Created: 12/Aug/16  Updated: 14/Aug/16  Resolved: 14/Aug/16

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

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

Attachments: Text File CLJS-1742-2.patch     Text File CLJS-1742.patch    
Patch: Code

 Description   

Add a docstring for the new REPL special refer-clojure introduced with CLJS-1730.



 Comments   
Comment by António Nuno Monteiro [ 14/Aug/16 1:58 PM ]

Attached patch with fix.

Comment by António Nuno Monteiro [ 14/Aug/16 2:09 PM ]

Attached revised CLJS-1742-2.patch which drops reference to `inclusion` (used with Clojure's `:only` filter, not supported in ClojureScript)

Comment by David Nolen [ 14/Aug/16 2:36 PM ]

fixed https://github.com/clojure/clojurescript/commit/63e0d7380ee5c45d74a93613aafe982ee600e990





[CLJS-1741] Add :rename to :refer-clojure in ns docstring Created: 12/Aug/16  Updated: 13/Aug/16  Resolved: 13/Aug/16

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

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

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

 Description   

Currently it indicates the only option is :exclude.



 Comments   
Comment by David Nolen [ 13/Aug/16 10:10 AM ]

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





[CLJS-1740] Self-host: Need to port more of CLJS-1733 Created: 12/Aug/16  Updated: 13/Aug/16  Resolved: 13/Aug/16

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

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

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

 Description   

With CLJS-1733 some changes were made that needed to be carried over to self-host.

CLJS-1738 took care of a simple argument refactoring, thus leading to script/test-self-parity passing.

But, script/test-self-host is still failing with failures surrounding unit tests involving the ability to disable analyze deps.

Looking further at the changes made for CLJS-1733, you can see two additional things that need to be ported over:

  1. cljs.js makes a few calls to the cljs.analyzer namespace were cljs.analyzer/analyze-deps is used internally and thus needs to be bound (this fixes script/test-self-host).
  2. With https://github.com/clojure/clojurescript/commit/d197bcb2bef327e00bcb39346258ed314a69b8d9 there is a missing that was previously calculated early in a let and its calculation was moved down to occur later at its use point.


 Comments   
Comment by Mike Fikes [ 12/Aug/16 8:09 PM ]

With the attached patch script/test-self-host goes from failing to passing.

Comment by David Nolen [ 13/Aug/16 10:23 AM ]

fixed https://github.com/clojure/clojurescript/commit/712a8d8f1e69b4f440088ce21d32f63a2e363988





[CLJS-1739] seq on map literal with 9 elements leads to rest producing nil Created: 12/Aug/16  Updated: 12/Aug/16  Resolved: 12/Aug/16

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

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


 Description   

Observe that (take 11 (iterate rest {:a 1 :b 2 :c 3 :d 4 :e 5 :f 6 :g 7 :h 8 :i 9})) produces a nil instead of () right near the end.

({:e 5, :g 7, :c 3, :h 8, :b 2, :d 4, :f 6, :i 9, :a 1} ([:g 7] [:c 3] [:h 8] [:b 2] [:d 4] [:f 6] [:i 9] [:a 1]) ([:c 3] [:h 8] [:b 2] [:d 4] [:f 6] [:i 9] [:a 1]) ([:h 8] [:b 2] [:d 4] [:f 6] [:i 9] [:a 1]) ([:b 2] [:d 4] [:f 6] [:i 9] [:a 1]) ([:d 4] [:f 6] [:i 9] [:a 1]) ([:f 6] [:i 9] [:a 1]) ([:i 9] [:a 1]) ([:a 1]) nil ())


 Comments   
Comment by Rohit Aggarwal [ 12/Aug/16 5:21 PM ]

The following code works as expected:

(take 11 (iterate rest (array-map :a 1 :b 2 :c 3 :d 4 :e 5 :f 6 :g 7 :h 8 :i 9)))
Comment by David Nolen [ 12/Aug/16 6:26 PM ]

fixed https://github.com/clojure/clojurescript/commit/7fe544696ca7dd45785980097f6033f9274e433b





[CLJS-1738] Self-host: need to update call to check-use-macros-inferring-missing Created: 12/Aug/16  Updated: 12/Aug/16  Resolved: 12/Aug/16

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

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

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

 Description   

script/test-self-parity fails owing to a slight simplification in arguments to check-use-macros-inferring-missing. Also, should incorporate call to check-rename-macros-inferring-missing.



 Comments   
Comment by David Nolen [ 12/Aug/16 3:55 PM ]

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





[CLJS-1737] Self-host: clojure alias implicit macro use regression Created: 11/Aug/16  Updated: 13/Aug/16  Resolved: 13/Aug/16

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

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

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

 Description   

If you add a new test case to cljs.clojure-alias-test

(deftest use-macros
  (s/def ::even? (s/and number? even?))
  (is? (s/valid? ::even? 2)))

then script/test-self-parity will fail with

ERROR in (use-macros) (TypeError:NaN:NaN)
Uncaught exception, not in assertion.
expected: nil
  actual: #object[TypeError TypeError: Cannot read property 'call' of undefined]

and issue warnings while failing:

WARNING: Can't take value of macro cljs.spec/def at line 14
WARNING: Can't take value of macro cljs.spec/and at line 14

This appears to be a regression associated with the change made for CLJS-1716. If you check with the previous commit, it will pass. (Note that the proposed unit test needs to be revised slightly to use is instead of is? in order to be applicable to the older code.)



 Comments   
Comment by António Nuno Monteiro [ 13/Aug/16 8:42 AM ]

Attached patch with fix and test.

Comment by Mike Fikes [ 13/Aug/16 9:09 AM ]

I tested this locally and it passes script/test-self-parity. With CLJS-1740 it passes script/test-self-host.

I also tried it downstream with Planck and it works there:

cljs.user=> (require '[clojure.spec :as s])
nil
cljs.user=> (s/def ::even? (s/and number? even?))
:cljs.user/even?
cljs.user=> (s/valid? ::even? 3)
false
cljs.user=> (s/valid? ::even? 4)
true

I also tried the above successfully in script/noderepljs, and I successfully ran script/test (both with and without CLJS-1740).

Comment by David Nolen [ 13/Aug/16 10:07 AM ]

fixed https://github.com/clojure/clojurescript/commit/8a49ce62bb5f53167bc44d75ada31156bcec38b0





[CLJS-1736] cljs.spec.test: checkable-syms* called with 0-arity Created: 11/Aug/16  Updated: 11/Aug/16  Resolved: 11/Aug/16

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

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


 Description   

On this line https://github.com/clojure/clojurescript/blob/85bab0736aae442d55d7f25ffc502b5195afe5c1/src/main/cljs/cljs/spec/test.cljc#L235
checkable-sums* is called with no arguments, but the function is only defined for a single argument arity.



 Comments   
Comment by David Nolen [ 11/Aug/16 12:31 PM ]

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





[CLJS-1735] Self-host: cljs.spec speced-vars instance Created: 11/Aug/16  Updated: 11/Aug/16  Resolved: 11/Aug/16

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

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

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

 Description   

Similar to CLJS-1656 but a new instance here: https://github.com/clojure/clojurescript/blob/85bab0736aae442d55d7f25ffc502b5195afe5c1/src/main/cljs/cljs/spec/test.cljc#L105



 Comments   
Comment by David Nolen [ 11/Aug/16 12:32 PM ]

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





[CLJS-1734] :import in ns silently discards imported classes with the same name Created: 11/Aug/16  Updated: 11/Aug/16

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

Type: Defect Priority: Minor
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   
(ns some.ns
  (:import goog.fx.Transition.EventType
           goog.history.EventType))

Both classes are named EventType and the second will effectively remove the first one without warning or error.






[CLJS-1733] Macro inference issue for macros & runtime vars with the same name Created: 11/Aug/16  Updated: 12/Aug/16  Resolved: 12/Aug/16

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

Type: Defect Priority: Minor
Reporter: Thomas Heller Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

The new :rename feature has several cases that are currently not covered and should either throw or warn.

A) :refer-clojure does not account for inline macros.

(ns some.test
  (:refer-clojure :rename {+ plus}))

(plus 1 2) ;; produces cljs.core._PLUS_.cljs$core$IFn$_invoke$arity$2((1),(2));
(cljs.core/+ 1 2) ;; produces ((1) + (2));

The macro version should be used automatically as well.

B) Conflicting :refer and :rename

(:require [clojure.string :refer (blank? starts-with?) :rename {blank? starts-with?}])

The :refer starts-with? is chosen and the rename is ignored. The :rename should either throw or emit a warning.

C) Conflicting :rename

(:require [some.ns :refer (foo bar) :rename {foo baz bar baz}])

Both renames want to use the alias baz. This should warn or throw as well.



 Comments   
Comment by David Nolen [ 12/Aug/16 12:14 PM ]

The problem is not specific to :rename. Even with a normal :require :refer you will see that the only the runtime var will get considered if the name is shared.

Comment by David Nolen [ 12/Aug/16 2:07 PM ]

Solved the typical refer case https://github.com/clojure/clojurescript/commit/b49c19819f46a78e41a1e3c9147b1127a006664d

Comment by David Nolen [ 12/Aug/16 2:27 PM ]

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





[CLJS-1732] Add docstrings for new use and use-macros REPL specials Created: 10/Aug/16  Updated: 11/Aug/16  Resolved: 11/Aug/16

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

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

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

 Description   

To go along with CLJS-1729



 Comments   
Comment by David Nolen [ 11/Aug/16 8:10 AM ]

fixed https://github.com/clojure/clojurescript/commit/60d534977ace15667c38cf2c2609e27ad72f539a





[CLJS-1731] Self-host: do_template problem with script/test-self-parity Created: 10/Aug/16  Updated: 11/Aug/16  Resolved: 11/Aug/16

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

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

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

 Description   
Testing cljs.spec-test

ERROR in (conform-explain) (TypeError:NaN:NaN)
Uncaught exception, not in assertion.
expected: nil
  actual: #object[TypeError TypeError: Cannot read property 'do_template' of undefined]


 Comments   
Comment by Mike Fikes [ 10/Aug/16 4:04 PM ]

The attached patch makes some slight adjustments to the self-host parity unit test namespace loading logic so that it can successfully load the clojure.template namespace.

Note that the patch fixes this issue, but at the same time it reveals that there are now 6 new test failures related to cljs.spec.

Comment by Mike Fikes [ 10/Aug/16 10:05 PM ]

Good news: The changes in CLJS-1720 cover the newly failing unit tests mentioned above.

Comment by David Nolen [ 11/Aug/16 8:08 AM ]

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





[CLJS-1730] Support `refer-clojure` special function in REPLs Created: 10/Aug/16  Updated: 11/Aug/16  Resolved: 11/Aug/16

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

Type: Enhancement Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

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

 Description   

Now that we have support for `:rename` in require specifications, the `refer-clojure` function at the REPL can be a useful addition.



 Comments   
Comment by António Nuno Monteiro [ 10/Aug/16 3:26 PM ]

Attached patch with fix.

Comment by David Nolen [ 11/Aug/16 8:13 AM ]

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





[CLJS-1729] Support `use` special function in REPLs Created: 10/Aug/16  Updated: 10/Aug/16  Resolved: 10/Aug/16

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

Type: Enhancement Priority: Minor
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

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

 Description   

While `:use` is supported at the NS declaration level, REPLs only support `import` and `require`.

Supporting `use` and `use-macros` in REPLs would be a useful addition.



 Comments   
Comment by António Nuno Monteiro [ 10/Aug/16 11:00 AM ]

Attached patch with fix

Comment by David Nolen [ 10/Aug/16 1:42 PM ]

fixed https://github.com/clojure/clojurescript/commit/8c6bbf8bc9f5b3e04fd8b172e725894256076e75





[CLJS-1728] Update doc for ns for new :rename capability Created: 09/Aug/16  Updated: 10/Aug/16  Resolved: 10/Aug/16

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

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

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

 Description   

Update the docstring for the ns special to cover the :rename option landed with CLJS-1508.



 Comments   
Comment by David Nolen [ 10/Aug/16 1:43 PM ]

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





[CLJS-1727] Regression when evaluating non-sequential forms at the REPL Created: 05/Aug/16  Updated: 08/Aug/16  Resolved: 08/Aug/16

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

Type: Defect Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

Affects master as of commit 8524d7b1ac7c1c418ec394e89322e341070414ca


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

 Description   

this commit [1] assumes that the forms evaluated at the REPL are always sequential by comparing `(first form)` with 'ns.
This makes it impossible to evaluate e.g. numbers or symbols.

[1]: https://github.com/clojure/clojurescript/commit/8524d7b1ac7c1c418ec394e89322e341070414ca



 Comments   
Comment by António Nuno Monteiro [ 05/Aug/16 7:39 AM ]

Attached patch with fix.

Comment by David Nolen [ 08/Aug/16 7:36 AM ]

fixed https://github.com/clojure/clojurescript/commit/2cc8f921cb1e56dbeb901e61a7149d283ad78bc7





[CLJS-1726] demunge is too agreesive and incorrect in some cases Created: 04/Aug/16  Updated: 04/Aug/16

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

Type: Enhancement Priority: Minor
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have implemented some "demunging" logic in cljs-devtools (and dirac) to present original user-friendly names in UI.

During my testing I spotted some wrong edge-cases and incorrect behaviours of demunge:

1) it is too aggressive in replacing dollars - some dollars can be "real" dollars as part of original name
2) it does not revert js-reserved? transformation applied during munging
3) it is oblivious to underscores/dashes - some underscores were "real" underscores before munging
(this may be not complete)

I have worked around those issues on my side and implemented some heuristics[1] based on context, but it is far from perfect.

I'm not sure how to properly fix those, so I wanted to open a ticket with discussion. Maybe people will have some clever ideas.

Currently munging is lossy and we probably don't want to touch it for compatibility reasons.
Maybe we could mark original underscores and dollars in some way, so demunge could properly skip them.

1) One strategy could be to use some (rare) unicode characters, but that would be problematic for people to type.
2) Another strategy could be to escape original dollars and underscores somehow (using more dollars and underscores .
3) Better ideas?

[1] https://github.com/binaryage/cljs-devtools/blob/52899e61e33373df36be8dcb23c69377936821b2/src/lib/devtools/munging.cljs#L154-L185






[CLJS-1725] defrecord does not set cljs$lang$ctorStr Created: 04/Aug/16  Updated: 04/Aug/16

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

Type: Defect Priority: Trivial
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

While implementing some demunging code[1] for cljs-devtools, I stumbled upon inconsistency in type->str. It works for deftypes but not for defrecords.

The problem is that defrecord does not set! cljs$lang$ctorStr field for some reason. This has been likely overlooked, because type->str is not used often, just for some rare error exceptions as far I can see.

Anyways, this patch fixes it by copy&pasting it from deftype. A better solution to avoid future problems like this would be to extract shared code between deftypes and defrecords, but that seems to be a lot of work.

The patch also adds some tests. I had to add some utility macros to run those tests only in simple mode, because type->str is not supposed to work under advanced builds.
Also test for CLJS-1722 was added to be uncommented after potentially merging it.

[1] https://github.com/binaryage/cljs-devtools/blob/52899e61e33373df36be8dcb23c69377936821b2/src/lib/devtools/munging.cljs#L56-L60






[CLJS-1724] Include IIterable in fast-path-protocols Created: 04/Aug/16  Updated: 04/Aug/16

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

Type: Enhancement Priority: Trivial
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-1724.patch    

 Description   

While exploring CLJS record instances printed via cljs-devtools v0.8.0, I spotted that IIterable is not a fast-path protocol:

https://dl.dropboxusercontent.com/u/559047/iiterable-slow-path.png

Please notice that IIterable is the only white label in the protocol list there.






[CLJS-1723] pr-writer-ex-info does not print false values and tries to reimplement map printer Created: 04/Aug/16  Updated: 08/Aug/16

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

Type: Defect Priority: Trivial
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

While working on CLJS-1722 I spotted two issues with pr-writer-ex-info:

1) if data or cause happen to be "false", they are skipped in printing
2) the code tries to mimic map printer

This patch fixes both issues. It turns out printing real info map yields exactly same string output and plays better with cljs-devtools printer (which newly sees real map instead of soup of strings and values).

For reference: pr-writer-ex-info was implemented in CLJS-983



 Comments   
Comment by David Nolen [ 08/Aug/16 7:39 AM ]

Can you explain why you think 1 is a problem? data should be a map. cause should be an error but I suppose that could be a problem if you have a rethrow which wraps some throwable value (which of course could be anything).

Comment by Antonin Hildebrand [ 08/Aug/16 2:32 PM ]

Disclaimer: I don't have much experience with Clojure and almost none with Java.

Just by reading the code I didn't see any checks in ex-info (or in ExceptionInfo ctor) to restrict data or cause. So I assumed anything can be passed in and printer should print it as-is without additional logic. I assumed that checking for nil values was intentional abbreviation when CLJS-983 was implemented. And I assumed that false value was supposed to be printed. At least I personally would want it to be distinguished from nil. Or there should be no abbreviation at all.





[CLJS-1722] Upgrade ExceptionInfo to proper deftype Created: 03/Aug/16  Updated: 04/Aug/16

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

Type: Enhancement Priority: Minor
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

Currently ExceptionInfo is implemented as a raw constructor function which inherits from js/Error with some ad-hoc javascript-level patches to satisfy a tiny subset of deftype functionality (mainly for printing).

Unfortunately this does not play well with cljs-devtools[1]. This problem surfaced when I started playing with ExceptionInfo and cljs-devtools v0.8 which newly supports printing deftypes[2]. ExceptionInfo does not contain getBasis, cljs$lang$type, cljs$lang$ctorStr and similar machinery.

My proposed patch implements ExceptionInfo as a proper deftype and does some patch-work to provide backward compatibility. I'm pretty sure we must not break current contract of ExceptionInfo constructor accepting 3 args and synthesizing other fields on the fly in constructor.

Implementation details:
1) first we define ExceptionInfo as normal deftype (to get a template)
2) then we remember reference to ExceptionInfo in ExceptionInfoTypeTemplate
3) then we redefine ExceptionInfo with raw constructor function which should mimic original behaviour (by scraping newly created js/Error instance, but calling ExceptionInfoTypeTemplate to do proper deftype initialization)
4) then we copy keys from ExceptionInfoTypeTemplate over ExceptionInfo
5) then we set ExceptionInfo's prototype to be ExceptionInfoTypeTemplate's prototype
6) then we fix ExceptionInfo's prototype's constructor to point to our re-defined constructor function
7) then we patch ExceptionInfo's prototype to inherit from js/Error (note this clobbers ExceptionInfoTypeTemplate as well - but we don't care about it)

This effectively gives us properly working ExceptionInfo deftype with redefined constructor function wrapping deftype's constructor for backwards compatibility.
We also patch ExceptionInfo's prototype to inherit from js/Error the same was as original code did.

Note: With working deftype, we can move IPrintWithWriter and toString implementation to the deftype itself.

[1] https://github.com/binaryage/cljs-devtools/issues/23
[2] https://github.com/binaryage/cljs-devtools/releases/tag/v0.8.0



 Comments   
Comment by Thomas Heller [ 04/Aug/16 4:25 AM ]

Why not just add the missing getBasis, cljs$lang$type, cljs$lang$ctorStr bits per set!?

The patch looks like it would mess up advanced compilation although that is just an instinct not something I verified, did you?

Comment by Antonin Hildebrand [ 04/Aug/16 4:44 AM ]

I ran clojurescript tests and I assumed they run also against advanced-mode build. During development when my tests were failing I saw error messages about minified names.

This may seem as a hacky solution, but IMO the original code was also a hack. My hack will stay up-to-date with future changes to deftype implementation. I can imagine people would forget to update this part when touching deftype.

btw. there is another patch coming related to discrepancies between deftype and defrecord. That could have been avoided if defrecord shared common implementation with deftype.

Comment by Thomas Heller [ 04/Aug/16 6:27 AM ]

Closure is usually very strict about re-defining stuff but I guess my instincts were wrong, the tests should cover advanced.

My issue with this is that deftype is for defining Clojure-specific types. ExceptionInfo is not since it inherits from Error, just like you can't have a superclass in Clojure you can't in CLJS. So IF we were to change deftype in the future we might break things in unexpected ways that just re-use deftype but aren't actually deftype.

Yes, you have to do some house-keeping but you can't enforce the rules of deftype when dealing with inheritance.

Just my 2 cents, it has advantages to re-use deftype too (as you suggested).

Comment by Antonin Hildebrand [ 04/Aug/16 6:36 AM ]

Unfortunately I was unable to look up any comments or docs explaining the reasoning why we do that js/Error inheritance there.

My first attempt to "fix" ExceptionInfo was to simply implement it as an ordinary deftype. And that worked just fine (for my tests). Then I tried to re-implement original behaviours on top just to make it 100% compatible.

Comment by Antonin Hildebrand [ 04/Aug/16 12:47 PM ]

Just adding a motivational screenshot:

https://dl.dropboxusercontent.com/u/559047/CLJS-1722-example.png

Those yellow warnings are listing which properties are getting copied by gobject/extend call.
The expanded log item is new implementation logged via cljs-devtools v0.8.0.
The last log item is the old implementation logged via cljs-devtools v0.8.0 (cljs-devtools does not recognise ExceptionInfo as CLJS type, but detects IPrintWithWriter and uses it to present the value)





[CLJS-1721] 3-arity get-in fails on types which do not implement ILookup Created: 02/Aug/16  Updated: 10/Aug/16  Resolved: 10/Aug/16

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

Type: Defect Priority: Minor
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1721.patch    

 Description   

The following are examples which fail:

(get-in {:a "data"} [:a 0] :not-found)
(get-in {:a (array 0 1 2 3)} [:a 0] :not-found)

Whilst the 2-arity version succeeds.



 Comments   
Comment by Thomas Mulvaney [ 04/Aug/16 7:57 AM ]

Also worth noting that the 3-arity version is quicker than the 2-arity version on long paths because it bails when a lookup fails. For example (get-in {} [:a :b :c :d :e :f]) is slower than (get-in {} [:a :b :c :d :e :f] :not-found) which bails out as soon a lookup fails. The former continues to call `get` on nil for the rest of the keys.

Perhaps it would be better for the 2-arity version to make a call to the 3-arity version passing nil as the last argument to take advantage of the early return. Would be happy to update the patch to include this.

Comment by David Nolen [ 10/Aug/16 1:51 PM ]

fixed https://github.com/clojure/clojurescript/commit/817b44d34795696eda473776e355fb956d3aa5ae





[CLJS-1720] Self-host: Qualify symbols and namespaced keywords in spec macros Created: 31/Jul/16  Updated: 11/Aug/16  Resolved: 11/Aug/16

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

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

Attachments: Text File CLJS-1720-2.patch     Text File CLJS-1720-3.patch     Text File CLJS-1720.patch    
Patch: Code

 Description   

There are currently a few symbols and namespaced keywords in the cljs.spec macros namespace that either need to be qualified for proper operation, or should be.

The symbols fall into the category of calls to runtime functions in the cljs.spec namespace, and need qualification in order to avoid the $macros suffix. These comprise with-gen and gen.

In terms of keywords, an example that causes a failure is ::kvs->map in keys*: It resolves to :cljs.spec$macros/kvs->map which doesn't match the :cljs.spec/kvs->map spec registered near the bottom of the cljs.spec runtime namespace.

An example that doesn't cause an outright failure, but arguably inhibits its proper use by client code is ::nil and ::pred in the nilable macro. Ideally these would resolve to :cljs.spec/nil and :cljs.spec/pred so that client code can rely on these namespaced symbols identifying the branches.

Given the nilable example, you could argue that the intent is that all namespaced keywords in the cljs.spec macro namespace that employ :: resolve in :cljs.spec so that they can be used not simply as unique identifiers (the intent is not simply to avoid potential collisions), but so that they can be used as stable identifiers.

The set of keywords that should be qualified comprises: ::kind-form, ::kfn, ::conform-all, ::kvs->map, ::nil, and ::pred



 Comments   
Comment by Mike Fikes [ 10/Aug/16 9:43 PM ]

Patch no longer applies; attaching re-baselined CLJS-1720-2.patch

Comment by Mike Fikes [ 10/Aug/16 9:55 PM ]

Sorry David, I botched that last re-baseline. Attaching a corrected CLJS-1720-3.patch.

Comment by David Nolen [ 11/Aug/16 8:09 AM ]

fixed https://github.com/clojure/clojurescript/commit/20b08fe442a24c46526c812f6c52ad8c7d3f6c9b





[CLJS-1719] Port destructuring namespaced keys and symbols Created: 29/Jul/16  Updated: 29/Jul/16  Resolved: 29/Jul/16

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

Type: Enhancement Priority: Major
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

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

 Description   

Port CLJ-1919 to Clojurescript



 Comments   
Comment by António Nuno Monteiro [ 29/Jul/16 6:44 PM ]

Attached patch with code and test.

Comment by David Nolen [ 29/Jul/16 8:46 PM ]

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





[CLJS-1718] Foreign lib files should be placed in a location that matches their namespace Created: 29/Jul/16  Updated: 29/Jul/16

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

Type: Defect Priority: Minor
Reporter: António Nuno Monteiro Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Affects master



 Description   

Using several foreign libs with the same file name ends up just including one of them, as the files are placed at the root of the `:output-dir`.

A solution for this would be placing those files in a location that matches their `:provides` namespace.






[CLJS-1717] remove unnecessary map from equiv-map Created: 29/Jul/16  Updated: 29/Jul/16  Resolved: 29/Jul/16

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

Type: Enhancement Priority: Trivial
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

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

 Description   

Simplifies code and removes a sequence allocation speeding up equiv-map.



 Comments   
Comment by David Nolen [ 29/Jul/16 3:05 PM ]

fixed https://github.com/clojure/clojurescript/commit/82dce0b1ed322af25e1ebe2cf91e3afec9e249ec





[CLJS-1716] No longer possible to use same alias for :require-macros and :require Created: 27/Jul/16  Updated: 29/Jul/16  Resolved: 29/Jul/16

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

Type: Defect Priority: Minor
Reporter: Juho Teperi Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None
Environment:

1.9.146 / 8643c55


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

 Description   

It was possible possible to use same alias for :require-macros and :require:

(ns hello-world.core
  (:require-macros [cljs.core.async.macros :as a])
  (:require [cljs.core.async :as a]))

(a/go
  (a/<! (a/timeout 1000))
  (println "hello"))

This works with 1.9.89 but on 1.9.146 this causes a warning:

WARNING: Use of undeclared Var cljs.core.async/go at line 5 src/hello_world/core.cljs

According to anmonteiro at Slack, this is caused by commit https://github.com/clojure/clojurescript/commit/41a62bfd916208d30bf621aefba56c5dce031ce5

Based on discussion at Slack, this feature is non intentional and fixing this is low-priority.

Minimal test project is available at https://github.com/Deraen/problems/tree/cljs-1692-same-alias
This still uses lein to retrieve deps as using core.async with cljs.jar proved complicated.



 Comments   
Comment by António Nuno Monteiro [ 27/Jul/16 6:27 PM ]

Attached patch with fix

Comment by Juho Teperi [ 28/Jul/16 4:40 AM ]

I can confirm that the patch works.

Comment by David Nolen [ 29/Jul/16 3:02 PM ]

fixed https://github.com/clojure/clojurescript/commit/82a2a293e7b0b30f78399f997ec26d808473b8e2





[CLJS-1715] Self-host: Symbols in cljs.spec.test/instrument Created: 27/Jul/16  Updated: 16/Sep/16

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

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

Attachments: Text File CLJS-1715-2.patch     Text File CLJS-1715.patch    
Patch: Code

 Description   

For bootstrapped ClojureScript, within cljs.spec.test/instrument:

1. There is a use of speced-vars that conditionally needs the $macros suffix (analogous to CLJS-1656).
2. The references to the runtime fns instrumentable-syms and distinct-by need to be qualified (otherwise their expansions use $macros.



 Comments   
Comment by Mike Fikes [ 10/Aug/16 4:12 PM ]

Previous patch no longer applies. Attaching a rebased patch. This patch is still relevant to master.

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

Needs a rebase.

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

Does CLJS-1773 address this?





[CLJS-1714] Clojurescript github README.md should identify source Clojure version Created: 24/Jul/16  Updated: 26/Jul/16

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

Type: Enhancement Priority: Trivial
Reporter: Marshall Abrams Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It would be helpful if the Clojurescript README at https://github.com/clojure/clojurescript/blob/master/README.md explicitly identified the Clojure version on which the current stable release of Clojurescript is based, or the Clojure version(s) which the Clojurescript release most closely tracks. This is especially helpful during periods when the Clojurescript release recommended in README.md is based on a Clojure alpha or even beta version, since there may be significant changes between Clojure versions in this case, so users might expect more similarity between the latest public releases of the two dialects than is warranted. Of course one can also go through changes.md to figure out what Clojure version is the basis of each Clojurescript release, but I think it's worth making it easier for users to notice.



 Comments   
Comment by David Nolen [ 25/Jul/16 2:08 PM ]

ClojureScript depends only on final releases of Clojure. This dependency is expressed in the pom.xml file which Maven based tooling and its users already understand. I don't see a compelling reason to include yet another thing we have to remember to update in the README.

Comment by Marshall Abrams [ 25/Jul/16 9:46 PM ]

First, I'm not sure if what I wrote was clear. I'm not talking about a dependency on the Clojure version used to compile to Javascript. I'm talking about the relationship between a Clojurescript version and the Clojure version that was ... ported to the Clojurescript release.

I agree it would a pain to try to remember to update this each time the Clojurescript version changed. That was one of my reservations, but I thought the point was important enough-especially for new users-that it seemed worth suggesting. I suppose that if there was already a line in the README about it, that will help, but I know that it's still easy to forget to update that kind of thing. Can't be helped.

Here are some reasons to consider updating the README with the Clojure version(s) that are the "source" of a Clojurescript version:

It's very useful information what version of Clojure the current Clojurescript release is most similar to. That way, information about the Clojure version is useful for Clojurescript.

At present, the official releases of Clojurescript listed in the README is based on what are currently alpha Clojure releases. Since the Clojure releases are alpha releases, they're changing quickly, so whatever's documented on the Clojure website may be out of sync with the Clojurescript release. One needs to know if that's so. (If all I want from the current Clojurescript release is what's in the previous non-alpha/beta Clojure release, knowing the Clojure version that was the source probably doesn't matter if there have been no breaking changes in the alpha releases on which the current Clojurescript version is based, but if I want to experiment in Clojurescript with new Clojure features-spec in this case-I need to know if it might differ from the latest Clojure version. (explain-data changed from Clojure 1.9.0-alpha7 to alpha10, at least.)

(I think that the comment about Maven and pom.xml was based on assuming that I was talking about the Clojure version used to compile Clojurescript code. If so, you can stop reading this paragraph. If not, then I would say that though Maven may be routinely used by Clojurescript developers-I don't know-but Clojurescript has grown beyond a core community of hardcore users and developers. It's used for a lot of real work, and it's a good language for new users coming from Clojure or Javascript. There are books for sale, and good online tutorials. The wiki is quite good for new users now. All of the templates on the wiki use Leiningen or Boot. There's no mention of Maven. There is no need for most users to use Maven with Clojurescript, or to even know what a pom file is. In my case, I do know what a pom file is, and have read quite a few, but wouldn't have thought to look there. I've never used Maven, however. Leiningen has been enough.)

Those are my thoughts on the matter. Thanks much for considering it.





[CLJS-1713] cljs.spec/explain-data returns different data structure than clojure.spec/explain-data Created: 24/Jul/16  Updated: 10/Aug/16  Resolved: 10/Aug/16

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

Type: Defect Priority: Minor
Reporter: Marshall Abrams Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: spec
Environment:

Tested in Clojure 1.9.0-alpha10 and Clojurescript 1.9.89



 Description   

The structure of the data returned by cljs.spec/explain-data seems to be unnecessarily different from the structure of data returned by clojure.spec/explain-data. Since, as I understand it, explain.data is mean to be used programmatically, this means that code has to be changed, unnecessarily, it seems, to work with both dialects.

Ignoring trivial differences that are to be expected going from one dialect to the other, in Clojure, the value of the top-level key :problems is a sequence of maps, each of which includes a :path key and value. In Clojurescript, the value of :problems is a map in which those vectors that were the values of :path in Clojure are instead keys, whose values are the rest of the corresponding Clojure maps.

Example:

(s/def ::a #(> % 0))
(s/def ::b (s/or :lt0 #(< % 0.0) :gt1 #(> % 1.0)))
(s/def ::all (s/keys :req-un [::a ::b]))
(s/explain ::all {:a -1 :b 0.5})
(pprint (s/explain-data ::all {:a -1 :b 0.5}))

In Clojure 1.9.0-alpha10, the last line returns:

#:clojure.spec{:problems ({:path [:a], :pred (> % 0), :val -1, :via [:user/all :user/a], :in [:a]}
                          {:path [:b :lt0], :pred (< % 0.0), :val 0.5, :via [:user/all :user/b], :in [:b]}
                          {:path [:b :gt1], :pred (> % 1.0), :val 0.5, :via [:user/all :user/b], :in [:b]})}

In Clojurescript 1.9.89, the same line returns:

{:cljs.spec/problems {[:a] {:pred (> % 0), :val -1, :via [:cljs.user/all :cljs.user/a], :in [:a]}, 
                      [:b :lt0] {:pred (< % 0), :val 0.5, :via [:cljs.user/all :cljs.user/b], :in [:b]},
                      [:b :gt1] {:pred (> % 1), :val 0.5, :via [:cljs.user/all :cljs.user/b], :in [:b]}}}


 Comments   
Comment by Marshall Abrams [ 24/Jul/16 11:58 AM ]

I just realized that Clojurescript 1.9.89 is still based on Clojure 1.9.0-alpha7, in which the data structure is like in the Clojurescript last example above. That explains the difference in the examples, and I assume that the explain-data return values will eventually be harmonized between the dialects, with future releases of Clojurescript (possibly after further changes in Clojure's explain-data return values, since this seems to be in flux). Apologies if this is just a "noise" ticket that shouldn't have been opened.

Comment by David Nolen [ 10/Aug/16 2:18 PM ]

fixed in master





[CLJS-1712] Make PersistentHashSet implement IReduce Created: 21/Jul/16  Updated: 21/Jul/16

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

Type: Enhancement Priority: Minor
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: performance

Attachments: Text File difference-benchmark.txt     Text File into-benchmark.txt     Text File phs-reduce.patch     Text File union-benchmark.txt    
Patch: Code

 Description   

This improves speed of many reduce based operations on set which were falling back to seq-reduce, including code in `clojure.set` namespace such as `clojure.set/union` and `(into [] some-set)`.

I've included a few benchmarks I performed using `simple-benchmark` in a JavascriptCore environment (Planck REPL)



 Comments   
Comment by Rohit Aggarwal [ 21/Jul/16 3:35 PM ]

I think the code currently is faithful to Clojure's implementation of PersistentHashSet. So any change from that would probably require more thought and/or history.

Also someone else also raised a similar issue on ClojureScript mailing list.





[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-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-1709] clojure.data/diff throws an exception when comparing map keys of different types when used on sorted maps Created: 19/Jul/16  Updated: 22/Jul/16

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






[CLJS-1708] Self-host: [iu]nstrument-1 needs to qualify [iu]nstrument-1* Created: 15/Jul/16  Updated: 11/Aug/16  Resolved: 11/Aug/16

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

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

Attachments: Text File CLJS-1708-2.patch     Text File CLJS-1708.patch    
Patch: Code

 Description   

The instrument-1 and unstrument-1 macros refer to instrument-1* and unstrument-1* functions which need to be qualified for bootstrap (otherwise they resolve as being in cljs.spec.test$macros).



 Comments   
Comment by Mike Fikes [ 27/Jul/16 8:36 AM ]

Initial patch no longer applies; attaching revised CLJS-1708-2.patch.

Comment by Mike Fikes [ 10/Aug/16 4:18 PM ]

The updated attached patch is still relevant to master in a bootstrapped context.

Comment by David Nolen [ 11/Aug/16 8:14 AM ]

fixed https://github.com/clojure/clojurescript/commit/85bab0736aae442d55d7f25ffc502b5195afe5c1





[CLJS-1707] Self-host: with-instrument-disabled needs to qualify *instrument-enabled* Created: 15/Jul/16  Updated: 11/Aug/16  Resolved: 11/Aug/16

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

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

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

 Description   

The unqualified *instrument-enabled* symbol resolves to cljs.spec.test$macros/*instrument-enabled* in bootstrap. This can be fixed by qualifying the symbol.



 Comments   
Comment by Mike Fikes [ 10/Aug/16 4:26 PM ]

The attached patch is still relevant to master in a bootstrapped context.

Comment by David Nolen [ 11/Aug/16 8:12 AM ]

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





[CLJS-1706] cljs.reader support for namespaced map literal Created: 15/Jul/16  Updated: 11/Aug/16

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

Type: Defect Priority: Major
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Clojure 1.9 extends support for namespaced maps and cljs.reader needs to be able to read them.

#:example{:key "value"} currently results in a Could not find tag parser for :example in ... error.



 Comments   
Comment by Thomas Heller [ 17/Jul/16 3:20 AM ]

I wanted to start implementing this and started looking at the "spec" [1]. It mentions support for #:: and #::alias, but since cljs.reader does not have access to aliases (or the current ns) I do not know how to proceed. Should it just throw then encountering #:: since it isn't really all that useful in a EDN context?

http://dev.clojure.org/jira/browse/CLJ-1910

Comment by David Nolen [ 10/Aug/16 1:56 PM ]

What does the Clojure EDN reader do here?

Comment by Linus Ericsson [ 11/Aug/16 2:26 PM ]

The clojure.edn-reader seems to catch that it doesn't have a default namespace, nor any aliases.

user> (clojure.edn/read-string "#:a {:b 1}")
{:a/b 1}

user> (clojure.edn/read-string "#::a {:b 1}")
RuntimeException Namespaced map must specify a valid namespace: :a  clojure.lang.EdnReader$NamespaceMapReader.invoke (EdnReader.java:494)

user> (clojure.edn/read-string "#:: {:b 1}")
RuntimeException Invalid token: :  clojure.lang.Util.runtimeException (Util.java:221)

This seems to be sane defaults also for cljs.reader.

Also see the commit adding namespaces maps in clojure





[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, Next
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-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-1703] cljs sources not resolved by devtools for 1.9.93 Created: 08/Jul/16  Updated: 11/Jul/16  Resolved: 11/Jul/16

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

Type: Defect Priority: Major
Reporter: Denis Johnson Assignee: David Nolen
Resolution: Not Reproducible Votes: 0
Labels: None
Environment:

Ubuntu 14.04 LTS 64bit
Chrome unstable Version 53.0.2783.2 dev (64-bit)
Chrome release Version 51.0.2704.106 (64-bit)



 Description   

Chrome devtools fails to show cljs file sources when compiled with org.clojure/clojurescript "1.9.93" sources are fine with "1.9.89".

1. Create a browser REPL project as guided in the Quick Start
2. open browser on http://localhost:9000
3. open chrome devtools, go to sources tab and all cljs files should be visible and include contents

I see the cljs files listed but no contents.



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

Was already fixed in a later commit due to bad usage of clojure.string/index-of





[CLJS-1702] Warning or error when using private vars Created: 07/Jul/16  Updated: 07/Jul/16

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

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


 Description   

Currently no warning or error of any kind is given. Throwing an error and forcing users to go through vars is somewhat less attractive since vars dump information like file, line, etc. A warning would be a simple way to flag users that they are treading into dangerous territory. Downstream tooling error handling can make it a hard error if they like.






[CLJS-1701] cljs.spec impact on :advanced builds Created: 07/Jul/16  Updated: 07/Jul/16

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

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


 Description   

Investigate the impact of cljs.spec on :advanced builds.

Currently all specs are kept in the (private) cljs.spec/registry-ref atom. This atom is not understood by the Closure Compiler and cannot be eliminated as dead code. So even if specs are not used in "production" they still bloat the generated JS size. Some specs may be used at runtime and cannot not be removed, the gen parts however are probably never required in :advanced builds and should be omitted somehow.

In a test build (with 1.9.93) this adds 11kb (102kb vs 91kb) as soon as cljs.spec is :require'd somewhere and goes up with each defined spec.






[CLJS-1700] Support clojure.* aliasing when not in vector Created: 03/Jul/16  Updated: 29/Jul/16  Resolved: 29/Jul/16

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

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

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

 Description   

While this works:

(ns foo.core
  (:require [clojure.test]))

this does not:

(ns foo.core
  (:require clojure.test))


 Comments   
Comment by António Nuno Monteiro [ 27/Jul/16 10:59 AM ]

Attached patch with fix and test.

Comment by David Nolen [ 29/Jul/16 3:07 PM ]

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





[CLJS-1699] Update docstring for ns Created: 03/Jul/16  Updated: 06/Jul/16  Resolved: 06/Jul/16

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

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

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

 Description   

Since doc for ns was added with CLJS-1307, ClojureScript gained support for bootstrap, and also has new features in the pipeline in dev (CLJS-1507 and CLJS-1692) which could be reflected in the docstring.



 Comments   
Comment by David Nolen [ 06/Jul/16 7:39 AM ]

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





[CLJS-1698] cljs.spec: every res call needs &env Created: 01/Jul/16  Updated: 06/Jul/16  Resolved: 06/Jul/16

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

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

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

 Description   

Example of every working in Clojure, covering the salient case for this ticket:

Clojure 1.9.0-alpha8
user=> (require '[clojure.spec :as s])
nil
user=> (s/explain (s/every pos? :kind vector?) '(1))
val: (1) fails predicate: vector?
nil

In ClojureScript this causes an error to be thrown, starting with

clojure.lang.ExceptionInfo: Wrong number of args (-1) passed to: spec/res at line 1 <cljs repl> {:file "<cljs repl>", :line 1, :column 12, :root-source-info {:source-type :fragment, :source-form (s/explain (s/every pos? :kind vector?) (quote (1)))}, :tag :cljs/analysis-error}


 Comments   
Comment by Mike Fikes [ 01/Jul/16 6:24 PM ]

With the attached patch:

$ script/noderepljs
ClojureScript Node.js REPL server listening on 51132
To quit, type: :cljs/quit
cljs.user=> (require '[clojure.spec :as s])
nil
cljs.user=> (s/explain (s/every pos? :kind vector?) '(1))
val: (1) fails predicate: vector?

nil
cljs.user=>
Comment by David Nolen [ 06/Jul/16 7:43 AM ]

fixed https://github.com/clojure/clojurescript/commit/16bc7ace746e1c0d67f4628339c51aad0668c03d





[CLJS-1697] doc on inferred macros fails Created: 30/Jun/16  Updated: 06/Jul/16  Resolved: 06/Jul/16

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

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

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

 Description   

If you make use of the new CLJS-1507 feature to infer a macro var in :refer, then doc fails on it.

Here is an example. See how it fails in foo.core but succeeds in bar.core:

$ script/noderepljs
ClojureScript Node.js REPL server listening on 52639
To quit, type: :cljs/quit
cljs.user=> (doc doc)
-------------------------
cljs.repl/doc
([name])
Macro
  Prints documentation for a var or special form given its name

nil
cljs.user=> (ns foo.core)
nil
foo.core=> (require '[cljs.repl :refer [doc]])
nil
foo.core=> (doc doc)
-------------------------
cljs.repl/doc
  nil

nil
foo.core=> (ns bar.core)
nil
bar.core=> (require-macros '[cljs.repl :refer [doc]])
nil
bar.core=> (doc doc)
-------------------------
cljs.repl/doc
([name])
Macro
  Prints documentation for a var or special form given its name

nil


 Comments   
Comment by Mike Fikes [ 03/Jul/16 9:55 AM ]

The root cause is that, when inferring a macro in :refer, the macro symbol mapping is left in :uses. This leads to other manifestations, like being able to apply var to such a symbol, etc.

The fix in the attached patch adds a little extra logic to remove missing uses from :uses (both in the AST being returned and, more importantly, from the compiler state).

Comment by David Nolen [ 06/Jul/16 7:40 AM ]

fixed https://github.com/clojure/clojurescript/commit/7264ca4ed0502fd69acea04e5d01c9bd1a3cb687





[CLJS-1696] Alias clojure.spec.gen => cljs.spec.impl.gen Created: 29/Jun/16  Updated: 16/Sep/16

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

Type: Defect Priority: Trivial
Reporter: Shaun LeBron Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-1696.patch    

 Description   

A special case for http://dev.clojure.org/jira/browse/CLJS-1692 to correctly alias clojure.spec.gen.



 Comments   
Comment by Shaun LeBron [ 29/Jun/16 12:02 PM ]

code and test

Comment by David Nolen [ 29/Jun/16 2:04 PM ]

I'm not excited about special casing this one. I'd rather wait to see if people actually use this namespace frequently enough for this to be desirable.

Comment by Shaun LeBron [ 29/Jun/16 10:37 PM ]

yeah, i guess the question is who should be responsible for handling this special case-- the user with reader conditionals or the compiler with this patch.

for extra context, I asked about this last week in slack: https://clojurians.slack.com/archives/clojurescript/p1466866626001218

Comment by Oliver George [ 13/Aug/16 4:41 AM ]

Just to bump this, I see references to requiring clojure.spec.gen in a few places now. The Clojure spec guide mentions it in project setup for generators, and the Clojure spec screencast on customizing generators.

One possibly related point. It seems necessary to require `clojure.test.check` in order for requiring `cljs.spec.impl.gen` to work.





[CLJS-1695] Self-host: Port cljs / clojure namespace aliasing Created: 25/Jun/16  Updated: 06/Jul/16  Resolved: 06/Jul/16

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

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

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

 Description   

CLJS-1692 covers auto-aliasing clojure.* to cljs.* in JVM ClojureScript. This asks for the same for bootstrapped ClojureScript.



 Comments   
Comment by Mike Fikes [ 25/Jun/16 11:47 PM ]

This issue has the use of util/ns->source in common with CLJS-1657. (Perhaps a common solution could be found for both—like making use of something along the lines of the bootstrap source load function.)

Comment by Mike Fikes [ 02/Jul/16 3:30 PM ]

The attached patch employs a "try first and then fall-back and patch things up" strategy with respect to clojure.* -> cljs.*.

Comment by David Nolen [ 06/Jul/16 7:42 AM ]

fixed https://github.com/clojure/clojurescript/commit/16af9f651f09e5c3f91098270ffacb806b907302





[CLJS-1694] Self-host: Port macro var inference in :refer Created: 25/Jun/16  Updated: 29/Jun/16  Resolved: 29/Jun/16

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

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

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

 Description   

CLJS-1507 covers JVM ClojureScript. This ticket requests the same for bootstrapped ClojureScript.



 Comments   
Comment by Mike Fikes [ 26/Jun/16 3:04 PM ]

Attached patch is a straightforward (intended to be faithful) port of the JVM ClojureScript feature.

Comment by David Nolen [ 29/Jun/16 2:09 PM ]

fixed https://github.com/clojure/clojurescript/commit/053d7f1ead6698b38e7ff656e0910ebc8bb8f729





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

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






[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: Next

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-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-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: 0
Labels: None





[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: Next

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-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: Next

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-1686] cljs.spec: c alias needs expansion in int-in Created: 20/Jun/16  Updated: 20/Jun/16  Resolved: 20/Jun/16

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

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


 Description   

See https://github.com/clojure/clojurescript/blob/5da67c1d13db7b7a4b347548184869097c5efa74/src/main/cljs/cljs/spec.cljc#L433

There is an instance of c/int that needs the same treatment given in https://github.com/clojure/clojurescript/commit/8477f19dcf67a8f305b46f2fd2e793586e027263



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

fixed https://github.com/clojure/clojurescript/commit/0336696f4e805e96d1130f75a0e16241f96b55e1





[CLJS-1685] Incorrectly lazy subvec when start param is nil Created: 17/Jun/16  Updated: 26/Sep/16

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

Type: Defect Priority: Minor
Reporter: Alf Kristian Støyle Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

ClojureScript 1.9.36 on Mac and Windows


Attachments: Text File cljs-1685.patch    

 Description   

subvec in ClojureScript does not fail when start param is nil. This is different than in regular Clojure.

In Clojure:

(def foo (subvec nil 1))
CompilerException java.lang.IndexOutOfBoundsException, compiling:(form-init4645269128697935824.clj:1:10) 
(def foo (subvec nil nil))
CompilerException java.lang.NullPointerException, compiling:(form-init4645269128697935824.clj:1:10)

In ClojureScript:

(def foo (subvec nil 1))
#object[Error Error: Index out of bounds]
   cljs.core/build-subvec (jar:file:/Users/stoyle/.m2/repository/org/clojure/clojurescript/1.9.36/clojurescript-1.9.36.jar!/cljs/core.cljs:5316:16)
   Function.cljs.core.subvec.cljs$core$IFn$_invoke$arity$3 (jar:file:/Users/stoyle/.m2/repository/org/clojure/clojurescript/1.9.36/clojurescript-1.9.36.jar!/cljs/core.cljs:5328:7)
   Function.cljs.core.subvec.cljs$core$IFn$_invoke$arity$2 (jar:file:/Users/stoyle/.m2/repository/org/clojure/clojurescript/1.9.36/clojurescript-1.9.36.jar!/cljs/core.cljs:5326:7)
   cljs$core$subvec (jar:file:/Users/stoyle/.m2/repository/org/clojure/clojurescript/1.9.36/clojurescript-1.9.36.jar!/cljs/core.cljs:5319:1)
=> nil
(def foo (subvec nil nil))
=> #'user/foo

foo is of course not usable after this:

foo
#object[Error Error: No protocol method IIndexed.-nth defined for type null: ]
   cljs.core/missing-protocol (jar:file:/Users/stoyle/.m2/repository/org/clojure/clojurescript/1.9.36/clojurescript-1.9.36.jar!/cljs/core.cljs:264:4)


 Comments   
Comment by Joshua Miller [ 26/Sep/16 1:37 PM ]

Added fix and test.





[CLJS-1684] cljs.spec changes from Clojure master Created: 16/Jun/16  Updated: 17/Jun/16  Resolved: 17/Jun/16

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

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


 Description   

https://github.com/clojure/clojure/commit/aa9b5677789821de219006ece80836bd5c6c8b9b
https://github.com/clojure/clojure/commit/4978bf5cee35f74df87c49720fa82de7287d60a5
https://github.com/clojure/clojure/commit/20f67081b7654e44e960defb1e4e491c3a0c2c8b

the uri & bytes generator commits are interesting but less critical



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

fixed https://github.com/clojure/clojurescript/commit/7a4e70f8848274f5db82ded9d823db772b9e5cbc





[CLJS-1683] js->clj passes opts incorrectly Created: 15/Jun/16  Updated: 29/Jul/16  Resolved: 29/Jul/16

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

Type: Defect Priority: Trivial
Reporter: Oliver George Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

This seems be a bug but nil-punning makes it work.

A good reason for fixing is that inspecting the code leads you to think the calling convention is different.

([x] (js->clj x {:keywordize-keys false}))

should be this (remove map)

([x] (js->clj x :keywordize-keys false))

in

(defn js->clj
  "Recursively transforms JavaScript arrays into ClojureScript
  vectors, and JavaScript objects into ClojureScript maps.  With
  option ':keywordize-keys true' will convert object fields from
  strings to keywords."
  ([x] (js->clj x {:keywordize-keys false}))
  ([x & opts]
    (let [{:keys [keywordize-keys]} opts
          keyfn (if keywordize-keys keyword str)
          f (fn thisfn [x]

So calling (js->clj x) becomes (js->clj x {:keywordize-keys false}) which means opts is [{:keywordize-keys false}] but is destructured as a map.

Result is keywordize-keys is nil rather than false. No drama.

(It got me because I was unsure how to call with :keywordize-keys set. I looked at that code, swapped false with true and was confused when it didn't work. (keywordized-keys was still nil.)



 Comments   
Comment by António Nuno Monteiro [ 29/Jul/16 7:24 AM ]

This has been fixed in https://github.com/clojure/clojurescript/commit/0fcbef2bf6be543ce72de4797701fdd55b332922

Comment by David Nolen [ 29/Jul/16 7:40 AM ]

fixed





[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-1681] Make instrument-all / unstrument-all return nil Created: 11/Jun/16  Updated: 27/Jul/16  Resolved: 27/Jul/16

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

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Not Reproducible Votes: 0
Labels: None

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

 Description   

In Clojure, instrument-all and unstrument-all return nil, but in ClojureScript will return the last var instrumented / unstrumented by the resulting macroexpansion.



 Comments   
Comment by Mike Fikes [ 11/Jun/16 6:01 PM ]

The attached CLJS-1681 broadens the scope a little and also takes care of instrument-ns / unstrument-ns.

Comment by Mike Fikes [ 27/Jul/16 9:29 AM ]

The attached patch no longer applies (not just mechanically but also because the functions involved have evolved while tracking Clojure).





[CLJS-1680] Self-host: Don't require items no longer provided by Closure Created: 11/Jun/16  Updated: 11/Jun/16  Resolved: 11/Jun/16

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

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

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

 Description   

goog.array.ArrayLike no longer provided https://github.com/google/closure-library/commit/bf758d3c2ef81b91e7d73608f68ee3c327b709d4
goog.crypt.JpegEncoder no longer provided https://github.com/google/closure-library/commit/756182c7c566898ba0847d80b0c87389f7c037b6

With https://github.com/clojure/clojurescript/commit/aaa281d5cfef89385a484ad5f204ce6973f01222 we minimally need to remove these from the auxiliary namespace used in the self-host testing infrastructure.



 Comments   
Comment by David Nolen [ 11/Jun/16 12:13 PM ]

fixed https://github.com/clojure/clojurescript/commit/178c2c0daa5a52691d9e591425d55273e6176db3





[CLJS-1679] Self-host: Incorporate spec tests Created: 11/Jun/16  Updated: 11/Jun/16  Resolved: 11/Jun/16

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

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

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

 Description   

cljs.spect-test was added with this commit https://github.com/clojure/clojurescript/commit/391d5cf86fbbf3d110ef6bbfc263d8132518a172

This ticket asks for the same for self-host.



 Comments   
Comment by Mike Fikes [ 11/Jun/16 9:06 AM ]

Attached CLJS-1679.patch:

Adds cljs.spec-test to the self-host test suite

To do so involves some adjustments to self-host
loading in this suite (a workaround for CLJS-1657
for some of the spec namespaces) and the need
to skip loading code for cljs.core macros namespace.

This also catches and fixes one production code
issue in the cljs.spec macros namespace: the symbol
instrument-enabled needs to be qualified so that
it refers to the runtime namespace.

Comment by David Nolen [ 11/Jun/16 12:14 PM ]

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





[CLJS-1678] variadic defn can be called for missing fixed arities, overlapping arity Created: 11/Jun/16  Updated: 12/Jun/16

Status: Reopened
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: None


 Description   

For defns with a variadic arity: if invoked with a missing fixed arity, they use the variadic method instead of erroring; if invoked with a fixed arity that is the max fixed arity, variadic mathod instead of fixed form is invoked.

(defn f-hole
  ([a] 1)
  ([a b c d & args] "4 or more"))

(f-hole 1 2) ; =>"4 or more", should be error

(defn f-overlap-mfa
  ([a b] 2)
  ([a b & c] "2+"))

(f-overlap-mfa 1) ;=> "2+", should be error
(f-overlap-mfa 1 2) ;=> "2+", should be 2
(f-overlap-mfa 1 2 3) ;=> "2+", correct

A way to fix the f-hole bug is to emit a "case X:" into the switch statement for all X with no signature or less than max-fixed-arity.

The f-overlap-mfa I'm not sure why is happening and didn't investigate deeply.



 Comments   
Comment by Francis Avila [ 11/Jun/16 8:31 AM ]

Sorry, filed against CLJ instead of CLJS!

Comment by Rohit Aggarwal [ 12/Jun/16 9:41 AM ]

The behaviour I am seeing for f-overlap-mfa is:

(f-overlap-mfa 1) ;=> "2+"
(f-overlap-mfa 1 2) ;=> 2
(f-overlap-mfa 1 2 3) ;=> "2+"

So the two argument result is different for me than you, Francis Avila.

The call with just one argument does give a warning though:

WARNING: Wrong number of args (1) passed to cljs.user/f-overlap-mfa





[CLJS-1677] Requiring [goog] breaks an :advanced build, but the compiler exits successfully Created: 09/Jun/16  Updated: 10/Jun/16

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

Type: Defect Priority: Minor
Reporter: Daniel Compton Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

A single file with the following in it is enough to break a build:

(ns goog-error.core
  (:require [goog]))

with this error

Jun 10, 2016 11:18:03 AM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: ERROR - Duplicate input: file:/Users/danielcompton/.m2/repository/org/clojure/google-closure-library/0.0-20151016-61277aea/google-closure-library-0.0-20151016-61277aea.jar!/goog/base.js

Jun 10, 2016 11:18:03 AM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 1 error(s), 0 warning(s)
ERROR: JSC_DUPLICATE_INPUT. Duplicate input: file:/Users/danielcompton/.m2/repository/org/clojure/google-closure-library/0.0-20151016-61277aea/google-closure-library-0.0-20151016-61277aea.jar!/goog/base.js at (unknown source) line (unknown line) : (unknown column)

however the ClojureScript compiler exits successfully without throwing an error. The build looks successful, but the file produced doesn't work. Should the ClojureScript compiler throw on these kinds of errors, or otherwise indicate failure?



 Comments   
Comment by David Nolen [ 10/Jun/16 8:27 AM ]

We should look into why the namespace validation that checks where a ns exists or not isn't already catching this case.





[CLJS-1676] Unused local in ObjMap / IKVReduce Created: 09/Jun/16  Updated: 09/Jun/16

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

Type: Defect Priority: Trivial
Reporter: Stuart Hinson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-1676.patch    

 Description   

Local len isn't used in ObjMap / IKVReduce

https://github.com/clojure/clojurescript/blob/463de005b81d4a00951188e8b8d38a61d684c18e/src/main/cljs/cljs/core.cljs#L5792






[CLJS-1675] Update Closure Library Created: 09/Jun/16  Updated: 10/Jun/16  Resolved: 10/Jun/16

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

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


 Comments   
Comment by David Nolen [ 10/Jun/16 1:43 PM ]

Cut a new release today.





[CLJS-1674] cljs.test/run-all-tests fails when passed a regexp variable Created: 09/Jun/16  Updated: 13/Jun/16  Resolved: 10/Jun/16

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

Type: Defect Priority: Minor
Reporter: Erik Ouchterlony Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug, test


 Description   
(let [re #".*re.*"] 
  (cljs.test/run-all-tests re))

clojure.lang.ExceptionInfo: clojure.lang.Symbol cannot be cast to java.util.regex.Pattern at line 1 <cljs repl> {:file "<cljs repl>", :line 1, :column 21, :tag :cljs/analysis-error}



 Comments   
Comment by David Nolen [ 10/Jun/16 1:35 PM ]

This is not a bug. run-all-tests is a macro, this case cannot be made to work.

Comment by Erik Ouchterlony [ 13/Jun/16 3:52 AM ]

Wouldn't it be possible to defer the filtering until run-time?

The reason I think this is important is that in a live programming setting, using e.g. om or reagent, it is possible to run the tests while the program is running, displaying the result in a component. It would be really nice to be able to filter test at run-time as well, selecting the filter from the UI.





[CLJS-1673] Can't s/instrument a multimethod Created: 09/Jun/16  Updated: 10/Jun/16  Resolved: 10/Jun/16

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

Type: Defect Priority: Minor
Reporter: Oliver George Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

Looks like it's not possible to instrument a multimethod on 1.9.36.

The tests below pass on 1.9.14 but fail on 1.9.36. Equivalent code on 1.9.0-alpha5 passes.

(ns hello-world.core
  (:require [cljs.spec :as s :include-macros true]
            [cljs.test :refer-macros [deftest is run-tests]]))

(enable-console-print!)


(defmulti testmm :type)
(defmethod testmm :default [_])
(defmethod testmm :good [_] "good")

(s/fdef testmm :args (s/cat :m map?) :ret string?)

(s/instrument #'testmm)

(deftest test-good
  (is (= "good" (testmm {:type :good}))))

(deftest test-bad-arg-fails
  (is (thrown? ExceptionInfo (testmm :bad-arg))))

(deftest test-bad-ret-fails
  (is (thrown? ExceptionInfo (testmm {:bad :ret}))))

(run-tests)


 Comments   
Comment by David Nolen [ 09/Jun/16 8:27 AM ]

Fail in what way? Including the output of the failure helps a lot.

Comment by Oliver George [ 09/Jun/16 5:42 PM ]

My bad. All pass on 1.9.14, but this is the output on 1.9.36.

Results are consistent with s/instrument having no effect.

Testing hello-world.core

FAIL in (test-bad-arg-fails) (cljs/test.js:432:14)
expected: (thrown? ExceptionInfo (testmm :bad-arg))
  actual: nil

FAIL in (test-bad-ret-fails) (cljs/test.js:432:14)
expected: (thrown? ExceptionInfo (testmm {:bad :ret}))
  actual: nil

Ran 3 tests containing 3 assertions.
2 failures, 0 errors.
Comment by David Nolen [ 10/Jun/16 1:36 PM ]

In the future please try to make real minimal cases. We don't need deftest code making this example more complicated.

Comment by David Nolen [ 10/Jun/16 2:12 PM ]

fixed https://github.com/clojure/clojurescript/commit/2682a4a53b0002db35c9fa17879dab66b0a614ca





[CLJS-1672] port new preds, specs, and gens Created: 07/Jun/16  Updated: 09/Jun/16  Resolved: 09/Jun/16

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

Type: Enhancement Priority: Major
Reporter: Patrick Killean Assignee: Patrick Killean
Resolution: Completed Votes: 0
Labels: None

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

 Description   

port https://github.com/clojure/clojure/commit/58227c5de080110cb2ce5bc9f987d995a911b13e



 Comments   
Comment by Patrick Killean [ 07/Jun/16 10:01 PM ]

CLJS-1672.patch: Everything except the inapplicable numerics & spec test stuff

Comment by Mike Fikes [ 07/Jun/16 10:18 PM ]

For me, one of the unit tests is failing.

FAIL in (test-preds) (V_@builds/out-adv/core-advanced-test.js:1023:83)
(#object[If "function If(b){return null!=b?b.v&8388608||b.je?!0:b.v?!1:gb(Nc,b):gb(Nc,b)}"] #inst "2016-06-08T03:17:17.377-00:00")
expected: (= ((nth preds i) v) (nth row i))
  actual: (not (= true false))
Comment by Thomas Heller [ 08/Jun/16 3:15 AM ]

It would be nice to have some of the number stuff as well, maybe even with equivalents on the clojure side. Since we don't have Long maybe something like

  • pos-number?
  • neg-number?
  • nat-number?

Also some of the number related functions in cljs behave very differently from clojure:

CLJS:

(pos? nil) => false
(pos? "2") => true

CLJ:

(pos? nil) => NullPointerException   clojure.lang.Numbers.ops (Numbers.java:1013)
(pos? "2") => ClassCastException java.lang.String cannot be cast to java.lang.Number  clojure.lang.Numbers.isPos (Numbers.java:96)

Maybe we should address this (in a separate issue).

Comment by Rohit Aggarwal [ 08/Jun/16 5:31 AM ]

The failing test is:

(seqable? now)

It should be false but it is true.

Somehow the behaviour in a noderepl is different from the test.

Also, (seqable? now) is false when used in the browser in either :advanced or :none optimisations mode. This looks strange to me.

Comment by Patrick Killean [ 08/Jun/16 6:34 AM ]

I ran the tests independently and it was fine but with the other core tests it misbehaves (on node):

cljs.user=> (seqable? (js/Date.)) ;=> false
cljs.user=> (require 'cljs.core-test)
cljs.user=> (seqable? (js/Date.)) ;=> true
Comment by Rohit Aggarwal [ 08/Jun/16 6:42 AM ]

I figured out the problem.

In core-test.cljs on line 2262, javascript object is being extended to add ISeqable protocol to it. So now indeed (satisfies? ISeqable (js/Date.)) is true instead of false.

This is why the behaviour is different.

Comment by Patrick Killean [ 08/Jun/16 7:06 AM ]

^Nice catch Rohit. I think a predicate test ns is a good solution

Comment by Rohit Aggarwal [ 08/Jun/16 8:03 AM ]

Patrick Killean Thanks. I agree - either moving this test to a new ns or moving the extend-type and the associated test-extend-to-object to a different ns should fix the failing test.

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

A new predicate test ns is OK. Looking over the long predicates, I do see that there's little benefit given the lack of longs. Heller's concerns about the difference in the predicate behavior is also orthogonal to this ticket.

Comment by David Nolen [ 08/Jun/16 8:46 AM ]

On second thought, given that we have goog.math.Long I don't see a reason to not implement these new long predicates?

Comment by David Nolen [ 08/Jun/16 8:54 AM ]

Also the patch should be modified so that all the new predicates have a ^boolean flag.

Comment by Patrick Killean [ 08/Jun/16 5:37 PM ]

CLJS-1672-1.patch:
Boolean hints, long predicates, new predicate test namespace

Comment by Thomas Heller [ 09/Jun/16 3:06 AM ]

I'm pretty sure goog.math.Long is not included by default so we'd need to :require it in cljs.core. Shouldn't hurt since the file itself doesn't have any other dependencies.

Comment by David Nolen [ 09/Jun/16 1:23 PM ]

fixed https://github.com/clojure/clojurescript/commit/73ab8ff8f4610a6f11cf64cc09e7173dcada5dc0





[CLJS-1671] Bad cljs.spec interactive instrumentation session Created: 06/Jun/16  Updated: 06/Jun/16  Resolved: 06/Jun/16

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   
(ns solari.spectest
  (:require
    [cljs.spec :as s]))

(s/fdef instrument-test
        :args (s/cat :input string?)
        :ret (fn [x] true)
        :fn (fn [x] true))

(defn instrument-test [input]
  input)

(comment
  ;Trying the following in the browser repl

  (s/instrument #'instrument-test) ;works
  
  ;next try calling function
  (instrument-test "hi")
  
  ;with bad input, spec returns error as expected
  (instrument-test 3)

  (s/unstrument #'instrument-test) ;works
  
  (s/instrument-all) ;doesn't work
  
  )



solari.spectest=>   (s/instrument-all) ;doesn't work
clojure.lang.ExceptionInfo:  at line 1 <cljs repl> {:file "<cljs repl>", :line 1, :column 3, :tag :cljs/analysis-error}
        at clojure.core$ex_info.invokeStatic(core.clj:4617)
        at clojure.core$ex_info.invoke(core.clj:4617)
        at cljs.analyzer$error.invokeStatic(analyzer.cljc:594)
        at cljs.analyzer$error.invoke(analyzer.cljc:590)
        at cljs.analyzer$macroexpand_1.invokeStatic(analyzer.cljc:2430)
        at cljs.analyzer$macroexpand_1.invoke(analyzer.cljc:2426)
        at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:2460)
        at cljs.analyzer$analyze_seq.invoke(analyzer.cljc:2443)
        at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:2575)
        at cljs.analyzer$analyze_form.invoke(analyzer.cljc:2571)
        at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:2622)
        at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2613)
        at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2638)
        at cljs.analyzer$analyze.invoke(analyzer.cljc:2625)
        at cljs.repl$evaluate_form.invokeStatic(repl.cljc:450)
        at cljs.repl$evaluate_form.invoke(repl.cljc:440)
        at cljs.repl$eval_cljs.invokeStatic(repl.cljc:570)
        at cljs.repl$eval_cljs.invoke(repl.cljc:563)
        at cljs.repl$repl_STAR_$read_eval_print__6003.invoke(repl.cljc:876)
        at cljs.repl$repl_STAR_$fn__6009$fn__6018.invoke(repl.cljc:915)
        at cljs.repl$repl_STAR_$fn__6009.invoke(repl.cljc:914)
        at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1154)
        at cljs.compiler$with_core_cljs.invoke(compiler.cljc:1145)
        at cljs.repl$repl_STAR_.invokeStatic(repl.cljc:878)
        at cljs.repl$repl_STAR_.invoke(repl.cljc:761)
        at figwheel_sidecar.repl$eval8112$fn__8113.invoke(repl.clj:148)
        at clojure.lang.MultiFn.invoke(MultiFn.java:238)
        at figwheel_sidecar.repl$eval8106$fn__8107.invoke(repl.clj:144)
        at clojure.lang.MultiFn.invoke(MultiFn.java:238)
        at figwheel_sidecar.repl$repl.invokeStatic(repl.clj:165)
        at figwheel_sidecar.repl$repl.invoke(repl.clj:153)
        at figwheel_sidecar.system$start_figwheel_repl.invokeStatic(system.clj:471)
        at figwheel_sidecar.system$start_figwheel_repl.invoke(system.clj:462)
        at figwheel_sidecar.system$figwheel_cljs_repl_STAR_.invokeStatic(system.clj:515)
        at figwheel_sidecar.system$figwheel_cljs_repl_STAR_.invoke(system.clj:513)
        at figwheel_sidecar.system$cljs_repl_STAR_.invokeStatic(system.clj:540)
        at figwheel_sidecar.system$cljs_repl_STAR_.invoke(system.clj:532)
        at figwheel_sidecar.system$cljs_repl.invokeStatic(system.clj:565)
        at figwheel_sidecar.system$cljs_repl.invoke(system.clj:560)
        at figwheel_sidecar.system$cljs_repl.invokeStatic(system.clj:563)
        at figwheel_sidecar.system$cljs_repl.invoke(system.clj:560)
        at figwheel_sidecar.repl_api$cljs_repl.invokeStatic(repl_api.clj:110)
        at figwheel_sidecar.repl_api$cljs_repl.invoke(repl_api.clj:103)
        at figwheel_sidecar.repl_api$cljs_repl.invokeStatic(repl_api.clj:107)
        at figwheel_sidecar.repl_api$cljs_repl.invoke(repl_api.clj:103)
        at user$eval37818.invokeStatic(form-init802425000002695685.clj:1)
        at user$eval37818.invoke(form-init802425000002695685.clj:1)
        at clojure.lang.Compiler.eval(Compiler.java:6942)
        at clojure.lang.Compiler.eval(Compiler.java:6905)
        at clojure.core$eval.invokeStatic(core.clj:3105)
        at clojure.core$eval.invoke(core.clj:3101)
        at clojure.main$repl$read_eval_print__8495$fn__8498.invoke(main.clj:240)
        at clojure.main$repl$read_eval_print__8495.invoke(main.clj:240)
        at clojure.main$repl$fn__8504.invoke(main.clj:258)
        at clojure.main$repl.invokeStatic(main.clj:258)
        at clojure.main$repl.doInvoke(main.clj:174)
        at clojure.lang.RestFn.invoke(RestFn.java:1523)
        at clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__7186.invoke(interruptible_eval.clj:87)
        at clojure.lang.AFn.applyToHelper(AFn.java:152)
        at clojure.lang.AFn.applyTo(AFn.java:144)
        at clojure.core$apply.invokeStatic(core.clj:646)
        at clojure.core$with_bindings_STAR_.invokeStatic(core.clj:1881)
        at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1881)
        at clojure.lang.RestFn.invoke(RestFn.java:425)
        at clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invokeStatic(interruptible_eval.clj:85)
        at clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke(interruptible_eval.clj:55)
        at clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__7231$fn__7234.invoke(interruptible_eval.clj:222)
        at clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__7226.invoke(interruptible_eval.clj:190)
        at clojure.lang.AFn.run(AFn.java:22)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
        at clojure.core$namespace.invokeStatic(core.clj:1554)
        at clojure.core$namespace.invoke(core.clj:1548)
        at cljs.spec$speced_vars_STAR_$fn__23506.invoke(spec.cljc:284)
        at clojure.core.protocols$iter_reduce.invokeStatic(protocols.clj:49)
        at clojure.core.protocols$fn__7829.invokeStatic(protocols.clj:75)
        at clojure.core.protocols$fn__7829.invoke(protocols.clj:75)
        at clojure.core.protocols$fn__7771$G__7766__7784.invoke(protocols.clj:13)
        at clojure.core$reduce.invokeStatic(core.clj:6545)
        at clojure.core$reduce.invoke(core.clj:6527)
        at cljs.spec$speced_vars_STAR_.invokeStatic(spec.cljc:282)
        at cljs.spec$speced_vars_STAR_.invoke(spec.cljc:275)
        at cljs.spec$speced_vars_STAR_.invokeStatic(spec.cljc:277)
        at cljs.spec$speced_vars_STAR_.invoke(spec.cljc:275)
        at cljs.spec$instrument_all.invokeStatic(spec.cljc:417)
        at cljs.spec$instrument_all.invoke(spec.cljc:413)
        at clojure.lang.AFn.applyToHelper(AFn.java:156)
        at clojure.lang.AFn.applyTo(AFn.java:144)
        at clojure.core$apply.invokeStatic(core.clj:650)
        at clojure.core$apply.invoke(core.clj:641)
        at cljs.analyzer$macroexpand_1_STAR_$fn__1828.invoke(analyzer.cljc:2383)
        at cljs.analyzer$macroexpand_1_STAR_.invokeStatic(analyzer.cljc:2382)
        at cljs.analyzer$macroexpand_1_STAR_.invoke(analyzer.cljc:2369)
        ... 68 more
solari.spectest=>


 Comments   
Comment by Leon Talbert [ 06/Jun/16 9:58 AM ]

So it looks like the source of the problem is calling fdef on a function that doesn't exist yet.
This causes a nil value to be placed into _speced_vars. Once this happens all subsequent calls
to instrument-all fail.

Comment by David Nolen [ 06/Jun/16 1:00 PM ]

Does instrumenting a var before it exists work in Clojure, I would suspect not? I guess we should just throw here.

Comment by David Nolen [ 06/Jun/16 4:39 PM ]

fixed https://github.com/clojure/clojurescript/commit/103aa6e5770242d8bdf9d234a85fca9e6dc918cf





[CLJS-1670] "Differences-from-Clojure" should mention var/namespace conflict Created: 05/Jun/16  Updated: 05/Jun/16  Resolved: 05/Jun/16

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

Type: Enhancement Priority: Minor
Reporter: Phill Wolf Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: documentation


 Description   

A Google-Group thread[1] raised a difference between Clojure and ClojureScript: you may name a var and a sub-namespace (as it were) the same in Clojure, but you will have to rename one or the other when porting to ClojureScript.

I did not see this difference called out on the page of "Differences-from-Clojure" [2]. It would be helpful there, especially for readers not well versed in the implications of using Google Closure's conventions for libraries and dependencies.

[1] https://groups.google.com/forum/#!topic/clojurescript/4Fvwx2Jf1nU

[2] https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure



 Comments   
Comment by Alex Miller [ 05/Jun/16 2:54 PM ]

I moved this from the CLJ project to CLJS.

Comment by David Nolen [ 05/Jun/16 3:06 PM ]

The wiki has been updated.





[CLJS-1669] Self-host: s/fdef ns-qualify *ns* name field access Created: 04/Jun/16  Updated: 05/Jun/16  Resolved: 05/Jun/16

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

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

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

 Description   

If you evaluate

(s/fdef foo :args ::s/any :ret ::s/any)

in a self-host context, the code will ultimately call cljs.spec/ns-qualify which involves a form (.name *ns*). While this style of field access works in Clojure, in order to work in self-host, the form needs to be (.-name *ns*).

You can imitate the same in a regular JVM ClojureScript REPL by comparing

(.name (find-ns 'cljs.user))
(.-name (find-ns 'cljs.user))


 Comments   
Comment by David Nolen [ 05/Jun/16 9:07 AM ]

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





[CLJS-1668] Self-host: Macro checking support Created: 04/Jun/16  Updated: 05/Jun/16  Resolved: 05/Jun/16

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

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

Attachments: Text File CLJS-1668-2.patch     Text File CLJS-1668-3.patch     Text File CLJS-1668.patch    
Patch: Code

 Description   

Add support for macro checking in self-host.

In essence, like https://github.com/clojure/clojurescript/commit/d6440795c22e46d2a2f8ab585fb6cfabf62cc147 but perhaps with appropriate code in :cljs reader conditional branches.



 Comments   
Comment by Mike Fikes [ 04/Jun/16 11:14 PM ]

The attached CLJS-1668.patch works. One twist is that you need to refer to a macro symbol using the $macros suffix, but there's probably no easy way around that for now. As a concrete example from the Spec guide, you can set things if you use cljs.core$macros/declare as the symbol passed to s/fdef.

Of interest in the patch, worthy of feedback, is the use of the construct:

^::no-resolve cljs.spec/macroexpand-check

This appears to be efficient (as the JavaScript var is either nil or not), and this works in self-host where the analyzer has direct access to check whether the var is nil.

Comment by Mike Fikes [ 04/Jun/16 11:31 PM ]

Whoops. The first patch fails to pass script/test-self-parity (owing to cljs.spec being nil) Attaching a revised patch CLJS-1688-2.patch that first checks for non-nil using an and.

Comment by David Nolen [ 05/Jun/16 9:25 AM ]

We don't want to leak out $macros, it's an implementation detail. We should automatically do the right thing if we are in a macro namespace. I believe there should be enough information in &env to figure this out in cljs.spec/fdef no? If not we should address this in the same patch.

Comment by Mike Fikes [ 05/Jun/16 11:29 AM ]

I agree. Perhaps one additional aspect to consider is macro-functions (like cljs.core/inc). The CLJS-1668-3.patch would perhaps lead to the ability to catch misuse when these are used either as macros or functions. Instead of detecting and adding $macros inside of fdef, the patch experiments with going the opposite direction: removing $macros in order to find a spec. That way, a single spec would cover the logically equivalent macro and function.

With this, you can see what might be desirable behavior:

cljs.user=> (require '[cljs.spec :as s])
nil
cljs.user=> (s/fdef cljs.core/inc :args number? :ret number?)
cljs.core/inc
cljs.user=> (inc "abc")
            ⬆
Call to cljs.core$macros/inc did not conform to spec:
val: ("abc") fails at: [:args] predicate: number?
:cljs.spec/args  ("abc")
 at line 1
cljs.user=> (map inc [1])
(2)
cljs.user=> (s/instrument cljs.core/inc)
#'cljs.core/inc
cljs.user=> (map inc [1])
Call to [object Object] did not conform to spec:
val: (1) fails at: [:args] predicate: number?
:cljs.spec/args  (1)

Interestingly, you can see that something else is going on with the map inc example at the bottom. This also occurs in a JVM ClojureScript REPL with master and is unrelated to the attached patch; I'd like to understand what's going on with it.

Comment by Mike Fikes [ 05/Jun/16 11:49 AM ]

Actually, in the example in the previous comment, it is the spec I wrote which is bad.

Here is a revised transcript showing the desired behavior with a proper spec:

cljs.user=> (require '[cljs.spec :as s])
nil
cljs.user=> (s/fdef cljs.core/inc
       #_=>   :args (s/cat :x number?)
       #_=>   :ret number?)
cljs.core/inc
cljs.user=> (inc 1)
2
cljs.user=> (inc "abc")
            ⬆
Call to cljs.core$macros/inc did not conform to spec:
In: [0] val: "abc" fails at: [:args :x] predicate: number?
:cljs.spec/args  ("abc")
 at line 1
cljs.user=> (s/instrument cljs.core/inc)
#'cljs.core/inc
cljs.user=> (map inc [1])
(2)
cljs.user=> (map inc ["abc"])
Call to [object Object] did not conform to spec:
In: [0] val: "abc" fails at: [:args :x] predicate: number?
:cljs.spec/args  ("abc")
Comment by David Nolen [ 05/Jun/16 1:43 PM ]

What I'm suggesting would cover us for both macros that shadow fns and the runtime fns. If the fdef is in a macro namespace it covers the macro. If it's a runtime ns it covers the runtime fn. That is a single spec isn't going to cover syntax and runtime behavior - it's desirable to able to spec both.

Comment by Mike Fikes [ 05/Jun/16 2:13 PM ]

Trying with patch 2, relying on the idea that an unqualified name in a macros namespace will automatically have the $macros suffix added internally as an implementation detail, this is a promising experiment: (It is also consistent with the way you can call functions from within macro namespaces in bootstrap as illustrated in the bottom half of http://blog.fikesfarm.com/posts/2016-01-05-clojurescript-macros-calling-functions.html)

$ cat src/foo/core.cljc
(ns foo.core
  (:require [#?(:clj clojure.spec :cljs cljs.spec) :as s]))

(defmacro my-inc
  [x]
  `(inc ~x))

(s/fdef my-inc
 :args (s/cat :x number?)
 :ret number?)
$ cat src/foo/core.cljs
(ns foo.core
  (:require-macros foo.core)
  (:require [cljs.spec :as s]))

(defn my-inc
  [x]
  (inc x))

(s/fdef my-inc
 :args (s/cat :x number?)
 :ret number?)

Using this pair of source files in Planck:

$ planck -c src
Planck 1.15
ClojureScript 1.9.39
    Docs: (doc function-name-here)
          (find-doc "part-of-name-here")
  Source: (source function-name-here)
    Exit: Control+D or :cljs/quit or exit or quit
 Results: Stored in vars *1, *2, *3, an exception in *e

cljs.user=> (require '[foo.core :include-macros true]
       #_=>          '[cljs.spec :as s])
nil
cljs.user=> (foo.core/my-inc 1)
2
cljs.user=> (foo.core/my-inc "a")
            ⬆
Call to foo.core$macros/my-inc did not conform to spec:
In: [0] val: "a" fails at: [:args :x] predicate: number?
:cljs.spec/args  ("a")
 at line 1
cljs.user=> (apply foo.core/my-inc [1])
2
cljs.user=> (apply foo.core/my-inc ["a"])
"a1"
cljs.user=> (s/instrument foo.core/my-inc)
#'foo.core/my-inc
cljs.user=> (apply foo.core/my-inc ["a"])
Call to [object Object] did not conform to spec:
In: [0] val: "a" fails at: [:args :x] predicate: number?
:cljs.spec/args  ("a")

	cljs.core/ExceptionInfo (cljs/core.cljs:10149:11)
	conform! (cljs/spec.cljs:894:54)
	G__12411__delegate (cljs/spec.cljs:924:135)
	cljs/lang/applyTo (cljs/spec.cljs:965:26)
	cljs.core/apply (cljs/core.cljs:3563:1)

cljs.user=>

(Note, I'm doing :include-macros true to work around CLJS-1657)

In script/noderepljs, (slightly modified to include my source path):

$ script/noderepljs
ClojureScript Node.js REPL server listening on 49477
To quit, type: :cljs/quit
cljs.user=> (require '[foo.core :include-macros true]
                     '[cljs.spec :as s])
nil
cljs.user=> (foo.core/my-inc 1)
2
cljs.user=> (foo.core/my-inc "a")
clojure.lang.ExceptionInfo: Call to foo.core/my-inc did not conform to spec:
In: [0] val: "a" fails at: [:args :x] predicate: number?
:clojure.spec/args  ("a")
 at line 1 <cljs repl> {:file "<cljs repl>", :line 1, :column 1, :tag :cljs/analysis-error}
	at clojure.core$ex_info.invokeStatic(core.clj:4631)
	at clojure.core$ex_info.invoke(core.clj:4631)
	at cljs.analyzer$error.invokeStatic(analyzer.cljc:594)
	at cljs.analyzer$error.invoke(analyzer.cljc:590)
	at cljs.analyzer$macroexpand_1.invokeStatic(analyzer.cljc:2432)
	at cljs.analyzer$macroexpand_1.invoke(analyzer.cljc:2428)
	at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:2462)
	at cljs.analyzer$analyze_seq.invoke(analyzer.cljc:2445)
	at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:2577)
	at cljs.analyzer$analyze_form.invoke(analyzer.cljc:2573)
	at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:2624)
	at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2615)
	at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:2640)
	at cljs.analyzer$analyze.invoke(analyzer.cljc:2627)
	at cljs.repl$evaluate_form.invokeStatic(repl.cljc:450)
	at cljs.repl$evaluate_form.invoke(repl.cljc:440)
	at cljs.repl$eval_cljs.invokeStatic(repl.cljc:570)
	at cljs.repl$eval_cljs.invoke(repl.cljc:563)
	at cljs.repl$repl_STAR_$read_eval_print__6619.invoke(repl.cljc:876)
	at cljs.repl$repl_STAR_$fn__6625$fn__6634.invoke(repl.cljc:915)
	at cljs.repl$repl_STAR_$fn__6625.invoke(repl.cljc:914)
	at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1154)
	at cljs.compiler$with_core_cljs.invoke(compiler.cljc:1145)
	at cljs.repl$repl_STAR_.invokeStatic(repl.cljc:878)
	at cljs.repl$repl_STAR_.invoke(repl.cljc:761)
	at cljs.repl$repl.invokeStatic(repl.cljc:996)
	at cljs.repl$repl.doInvoke(repl.cljc:926)
	at clojure.lang.RestFn.invoke(RestFn.java:410)
	at user$eval6810.invokeStatic(NO_SOURCE_FILE:3)
	at user$eval6810.invoke(NO_SOURCE_FILE:3)
	at clojure.lang.Compiler.eval(Compiler.java:6942)
	at clojure.lang.Compiler.eval(Compiler.java:6905)
	at clojure.core$eval.invokeStatic(core.clj:3105)
	at clojure.main$eval_opt.invokeStatic(main.clj:288)
	at clojure.main$eval_opt.invoke(main.clj:282)
	at clojure.main$initialize.invokeStatic(main.clj:308)
	at clojure.main$null_opt.invokeStatic(main.clj:342)
	at clojure.main$null_opt.invoke(main.clj:339)
	at clojure.main$main.invokeStatic(main.clj:421)
	at clojure.main$main.doInvoke(main.clj:384)
	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: Call to foo.core/my-inc did not conform to spec:
In: [0] val: "a" fails at: [:args :x] predicate: number?
:clojure.spec/args  ("a")

	at clojure.spec$macroexpand_check.invokeStatic(spec.clj:560)
	at clojure.spec$macroexpand_check.invoke(spec.clj:549)
	at clojure.lang.Var.invoke(Var.java:383)
	at cljs.analyzer$macroexpand_1_STAR_.invokeStatic(analyzer.cljc:2383)
	at cljs.analyzer$macroexpand_1_STAR_.invoke(analyzer.cljc:2369)
	... 41 more
cljs.user=> (apply foo.core/my-inc [1])
2
cljs.user=> (apply foo.core/my-inc ["a"])
"a1"
cljs.user=> (s/instrument foo.core/my-inc)
#'foo.core/my-inc
cljs.user=> (apply foo.core/my-inc ["a"])

repl:13
throw e__6482__auto__;
^
Error: Call to [object Object] did not conform to spec:
In: [0] val: "a" fails at: [:args :x] predicate: number?
:cljs.spec/args  ("a")

    at new cljs$core$ExceptionInfo (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/cljs/core.js:34473:10)
    at Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/cljs/core.js:34549:9)
    at Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$2 (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/cljs/core.js:34545:26)
    at cljs$core$ex_info (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/cljs/core.js:34531:26)
    at cljs.spec.spec_checking_fn.conform_BANG_ (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/cljs/spec.js:892:25)
    at cljs.spec.spec_checking_fn.G__15208__delegate (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/cljs/spec.js:922:136)
    at Function.cljs.spec.spec_checking_fn.G__15208.cljs$lang$applyTo (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/cljs/spec.js:963:8)
    at Function.cljs.core.apply.cljs$core$IFn$_invoke$arity$2 (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/cljs/core.js:12759:10)
    at cljs$core$apply (/Users/mfikes/Projects/clojurescript/.cljs_node_repl/cljs/core.js:12730:24)
    at repl:1:105
cljs.user=>
Comment by David Nolen [ 05/Jun/16 2:35 PM ]

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





[CLJS-1667] bad describe* for and-spec-impl Created: 03/Jun/16  Updated: 05/Jun/16  Resolved: 05/Jun/16

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

Type: Defect Priority: Minor
Reporter: Oliver George Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

(cljs.spec/form (cljs.spec/and string?)) returns (s/and cljs.core/string?) where s/and should be cljs.spec/and.

Based on or-spec-impl I think the fix is to replace:

(describe* [_] `(s/and ~@forms))

with

(describe* [_] `(and ~@forms))


 Comments   
Comment by Oliver George [ 03/Jun/16 10:44 PM ]

(I can see one other case in cljs.spec which references s/with-instrument-disabled)

Comment by David Nolen [ 05/Jun/16 9:13 AM ]

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





[CLJS-1666] Flag to optionally disable transit analysis cache encoding Created: 03/Jun/16  Updated: 23/Sep/16

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

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


 Description   

We need a flag to explicitly disable the transit encoding - this is to work around code that creates unencodeable forms for one reason or another. EDN had become more lax about encoding random Objects which allowed this stuff to go under the radar in the past.



 Comments   
Comment by Wilker Lúcio da Silva [ 06/Jun/16 9:10 PM ]

I'm having a compilation issue with ClojureScript 1.9.36, I'm writing an app that uses untangled and this file https://github.com/untangled-web/untangled-client/blob/f42088c84b059562a48455a71daa6e4ea08d286c/src/untangled/client/data_fetch.cljs fails to compile with Caused by: java.lang.RuntimeException: java.lang.Exception: Not supported: class cljs.tagged_literals.JSValue this issue doesn't happen with 1.9.14

Comment by David Nolen [ 06/Jun/16 10:06 PM ]

We should investigate whether just handling JSValue + other cases like clojure.lang.Var is good enough.

Comment by David Nolen [ 08/Jun/16 8:53 AM ]

JSValue encoding/decoding landed in master fixing part of the issue. Still need more information about the Var case however.





[CLJS-1665] Use Javascript array to create a collection in cljs.reader Created: 03/Jun/16  Updated: 10/Aug/16  Resolved: 10/Aug/16

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

Type: Enhancement Priority: Minor
Reporter: Rohit Aggarwal Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: performance

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

 Description   

For performance, we should be using a Javascript array to create an ArrayMap/HashMap/Set/List/Vector instead of creating them out of a Vector. Most of the underlying data types do have methods to convert from an array to that type.

The big change is that cljs.reader/read-delimited-list now returns an array instead of a vector.

Benchmarking code:

(def nums (range 20))
(def nums-map (into {} (map (fn [i] [i i]) nums)))

(simple-benchmark [s "{:foo 1 :bar 2}"] (reader/read-string s) 1000000)
(simple-benchmark [s (pr-str nums-map)] (reader/read-string s) 100000)
(simple-benchmark [s (pr-str nums)] (reader/read-string s) 100000)
(simple-benchmark [s (pr-str (vec nums))] (reader/read-string s) 100000)
(simple-benchmark [s (pr-str (set nums))] (reader/read-string s) 100000)

Results (All times in msecs):

Engine Benchmark Old New Improvement
v8 Small Map 6620 5516 20.01%
SpiderMonkey Small Map 11929 10606 12.47%
JSC Small Map 5101 4158 22.68%
v8 Large Map 6075 5548 9.50%
SpiderMonkey Large Map 13070 11933 9.53%
JSC Large Map 4777 4273 11.79%
v8 List 2308 2280 1.23%
SpiderMonkey List 6167 4777 29.10%
JSC List 1891 1737 8.87%
v8 Vector 2276 2242 1.52%
SpiderMonkey Vector 5239 4700 11.47%
JSC Vector 1832 1684 8.79%
v8 Set 3362 3271 2.78%
SpiderMonkey Set 7283 6880 5.86%
JSC Set 2771 2619 5.80%


 Comments   
Comment by David Nolen [ 10/Aug/16 2:24 PM ]

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

Comment by Rohit Aggarwal [ 10/Aug/16 3:00 PM ]

Thank you David!





[CLJS-1664] Self-host: The filename aux.cljs is a problem on windows. Created: 02/Jun/16  Updated: 05/Jun/16  Resolved: 05/Jun/16

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

Type: Defect Priority: Minor
Reporter: Oliver George Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap

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

 Description   

As I understand AUX is a reserved word dating back to MS-DOS Device Driver days. It seems many windows features are hardwired to reject that pattern in filenames.

In my case running windows 10:

  • I can't git clone the full repo (aux.cljs is skipped).
  • Downloading and unzipping throws an error on that file.

I suspect the best solution is to rename that file.



 Comments   
Comment by Mike Fikes [ 02/Jun/16 9:30 PM ]

I created this particular file when adding the capability to run the compiler unit tests under self host. The choice of filename is arbitrary. In fact, it is just an auxiliary namespace is employed to cause certain files to be dumped to the compiler output directory. It could be named anything and there should be no other files making use of that particular namespace name.

Comment by Mike Fikes [ 03/Jun/16 6:36 PM ]

The attached patch simply moves the file to a new name (while updating the namespace in the ns form).

Comment by David Nolen [ 05/Jun/16 9:16 AM ]

fixed https://github.com/clojure/clojurescript/commit/63a4634c3b2aa72f33404901843540fe3302496d





[CLJS-1663] Calling instrumented multi-arity function causes exception Created: 02/Jun/16  Updated: 02/Jun/16  Resolved: 02/Jun/16

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

Type: Defect Priority: Minor
Reporter: Oliver George Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

Repeatable using lein mies with [clojurescript "1.9.14"] using script/build.bat (and script/release.bat)

(ns spec-multiarity.core
  (:require [cljs.spec :as s :include-macros true]))

(enable-console-print!)

(defn adder
  ([a] a)
  ([a b] (+ a b)))
  
(s/fdef adder
  :args (s/cat :a integer? :b (s/? integer?))
  :ret integer?)

(do 
  (s/instrument #'adder)
  (adder 1))
core.cljs:8 Uncaught TypeError: spec_multiarity.core.adder.cljs$core$IFn$_invoke$arity$1 is not a functionspec_multiarity$core$adder 
@ core.cljs:8cljs.core.apply.cljs$core$IFn$_invoke$arity$2 
@ core.cljs:3572cljs$core$apply 
@ core.cljs:3563(anonymous function) 
@ spec.cljs:290cljs.spec.spec_checking_fn.G__8367__delegate 
@ spec.cljs:289cljs.spec.spec_checking_fn.G__8367 
@ spec.cljs:284(anonymous function) @ core.cljs:30


 Comments   
Comment by Oliver George [ 02/Jun/16 9:10 AM ]

Same code works on [org.clojure/clojure "1.9.0-alpha4"]

Comment by David Nolen [ 02/Jun/16 3:52 PM ]

Do not open tickets that reference build tools other than ClojureScript, thanks. Multi-arity fns are handled with s/or + s/cat. That's the only thing that would need to be fixed if it doesn't work.

Comment by David Nolen [ 02/Jun/16 4:49 PM ]

I looked at this a bit more closely and I was mistaken. Looking into it.

Comment by David Nolen [ 02/Jun/16 6:14 PM ]

fixed https://github.com/clojure/clojurescript/commit/2f012cec88d05f42dd145338d9c942498d3ceb13





[CLJS-1662] Optimize seq (&) destructuring (as per latest 0aa3467 in Clojure) Created: 02/Jun/16  Updated: 03/Jun/16  Resolved: 02/Jun/16

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

Type: Enhancement Priority: Minor
Reporter: Rohit Aggarwal Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: performance

Attachments: Text File CLJS-1662-Optimize+seq+destructuring-2.patch     Text File CLJS-1662-Optimize seq destructuring.patch    
Patch: Code

 Description   

I've applied the changes which have been committed by Rich in this commit. All the tests are passing on v8, Spidermonkey and JSC engines on OS X. I've also tested using ./script/test-self-host and ./script/test-self-parity.

Benchmarking code:

(simple-benchmark [v (into [] (range 1000000))]
                  (loop [[x & xs] v]
                    (if xs
                      (recur xs)
                      x))
                  100)

Results (all times are in msecs):

- v8 Spidermoney JSC
Old 19070 18053 9116
New 10323 15238 6353


 Comments   
Comment by Rohit Aggarwal [ 02/Jun/16 7:34 AM ]

For reference, the performance improvements for Clojure are mentioned in this post.

Comment by Rohit Aggarwal [ 02/Jun/16 3:31 PM ]

I've updated the benchmarking code after conversation with David Nolen on Slack.

Comment by Rohit Aggarwal [ 02/Jun/16 3:34 PM ]

New benchmarks are below.

Code:

(println "\n")
(println ";; Destructuring a sequence")
(simple-benchmark [v (into [] (range 1000000))]
                  (loop [[x & xs] v]
                    (if-not (nil? xs)
                      (recur xs)
                      x))
                  1000)

Timing: (in msecs)

- v8 SpiderMonkey JSC
Old 160503 131297 123059
New 85183 118355 55245
Comment by David Nolen [ 02/Jun/16 6:18 PM ]

fixed https://github.com/clojure/clojurescript/commit/2f012cec88d05f42dd145338d9c942498d3ceb13

Comment by Rohit Aggarwal [ 03/Jun/16 3:41 AM ]

Thank you!





[CLJS-1661] cljs.spec: non-spec'ed fn var printing Created: 01/Jun/16  Updated: 10/Jun/16  Resolved: 10/Jun/16

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

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

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

 Description   

If you try to instrument an unspec'ed var, you will get a warning that prints [object Object]:

ClojureScript Node.js REPL server listening on 53013
To quit, type: :cljs/quit
cljs.user=> (require '[cljs.spec :as s])
nil
cljs.user=> (s/instrument inc)

repl:22
throw e__4797__auto__;
^
Error: Fn at [object Object] is not spec'ed.
...


 Comments   
Comment by Mike Fikes [ 01/Jun/16 11:22 PM ]

With the attached patch, prints:

Error: Fn at #'cljs.core/inc is not spec'ed.
Comment by David Nolen [ 10/Jun/16 9:15 AM ]

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





[CLJS-1660] cljs.spec: Always return var from instrument / unstrument Created: 01/Jun/16  Updated: 06/Jun/16  Resolved: 06/Jun/16

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

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1660-2.patch     Text File CLJS-1660.patch    
Patch: Code

 Description   

In Clojure, instrument and unstrument always return the associated var. In ClojureScript, calling instrument on an already-instrumented var returns nil. (And, likewise for unstrument with the fix for CLJS-1659.)

This ticket asks that ClojureScript behave like Clojure in this case.



 Comments   
Comment by Mike Fikes [ 06/Jun/16 4:56 PM ]

Attached CLJS-1660-2.patch, as previous no longer applies.

Comment by David Nolen [ 06/Jun/16 10:05 PM ]

fixed https://github.com/clojure/clojurescript/commit/8f1f977224a644bb6681d17876c73d4a12154792





[CLJS-1659] cljs.spec: stack-overflow calling unstrumented fn Created: 01/Jun/16  Updated: 06/Jun/16  Resolved: 06/Jun/16

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

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

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

 Description   

Affects 1.9.14. After unstrumenting, calling the fn results in stack overflow.

$ java -jar cljs.jar -m cljs.repl.node
ClojureScript Node.js REPL server listening on 54613
To quit, type: :cljs/quit
cljs.user=> (require '[cljs.spec :as s])
nil
cljs.user=> (defn ranged-rand
  "Returns random integer in range start <= rand < end"
  [start end]
  (+ start (rand-int (- end start))))
#'cljs.user/ranged-rand
cljs.user=> (s/fdef ranged-rand
  :args (s/and (s/cat :start integer? :end integer?)
               #(< (:start %) (:end %)))
  :ret integer?
  :fn (s/and #(>= (:ret %) (-> % :args :start))
             #(< (:ret %) (-> % :args :end))))
cljs.user/ranged-rand
cljs.user=> (s/instrument #'ranged-rand)
#'cljs.user/ranged-rand
cljs.user=> (s/unstrument #'ranged-rand)
#'cljs.user/ranged-rand
cljs.user=> (ranged-rand 3 7)
repl:13
throw e__4797__auto__;
^
RangeError: Maximum call stack size exceeded
    at cljs.core.Var.call.G__8117__3 (/Users/mfikes/Downloads/.cljs_node_repl/cljs/core.js:3682:120)
    at cljs.core.Var.call.G__8117 [as call] (/Users/mfikes/Downloads/.cljs_node_repl/cljs/core.js:3827:19)
    at cljs.core.Var.call.G__8117__3 (/Users/mfikes/Downloads/.cljs_node_repl/cljs/core.js:3682:120)
    at cljs.core.Var.call.G__8117 [as call] (/Users/mfikes/Downloads/.cljs_node_repl/cljs/core.js:3827:19)
    at cljs.core.Var.call.G__8117__3 (/Users/mfikes/Downloads/.cljs_node_repl/cljs/core.js:3682:120)
    at cljs.core.Var.call.G__8117 [as call] (/Users/mfikes/Downloads/.cljs_node_repl/cljs/core.js:3827:19)
    at cljs.core.Var.call.G__8117__3 (/Users/mfikes/Downloads/.cljs_node_repl/cljs/core.js:3682:120)
    at cljs.core.Var.call.G__8117 [as call] (/Users/mfikes/Downloads/.cljs_node_repl/cljs/core.js:3827:19)
    at cljs.core.Var.call.G__8117__3 (/Users/mfikes/Downloads/.cljs_node_repl/cljs/core.js:3682:120)
    at cljs.core.Var.call.G__8117 [as call] (/Users/mfikes/Downloads/.cljs_node_repl/cljs/core.js:3827:19)
cljs.user=>

Also happens in bootstrap (downstream in Planck). The same sequence does not occur in Clojure with 1.9.0-alpha3.



 Comments   
Comment by Mike Fikes [ 01/Jun/16 9:28 PM ]

Owing to a leftover bit of the original Clojure implementation,
while unstrument* causes the desired side effect on instrumented-vars,
it results in setting the value of the unstrumented var to the var
(as opposed to the desired original raw function value).

The fix is to eliminate the return of the var and do the swap in the
body of when block, following the same pattern employed in instrument*.

Comment by Mike Fikes [ 06/Jun/16 5:03 PM ]

Exact same patch applied with CLJS-1671.





[CLJS-1658] implements? may report false positives Created: 01/Jun/16  Updated: 02/Jun/16

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

Type: Defect Priority: Minor
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File implements-false-positives.patch     Text File implements-false-positives-with-sentinel.patch    
Patch: Code

 Description   

The cljs.core/implements? checks whether a protocol is implemented via a property on the tested object. When implementing the protocol this property will be set to true.

// the implementation
protocol.check.Dummy.prototype.protocol$check$TheProtocol$ = true;

// the check (implements? TheProtocol x)
((!((x == null)))?(((false) || (x.protocol$check$TheProtocol$))?true:false):false)

// only the relevant bit
x.protocol$check$TheProtocol$

This works fine under :none but :advanced may rename this to something like x.A. If you now try to check (implements? TheProtocol js/window) for example it may (or may not) report a false positive. For larger projects the likelyhood of creating a false positives goes way up since window contains all the variables created by the advanced compiled js.

The attached patch changes the patch the emitted code to check x.protocol$check$TheProtocol$ === true which reduces the chance of a false positive by a lot. We might chose another sentinel value instead to reduce the chance some more, this seems good enough though.



 Comments   
Comment by Thomas Heller [ 01/Jun/16 2:13 PM ]

Implemented the same change for cljs.core/satisfies?.

Comment by Thomas Heller [ 01/Jun/16 2:18 PM ]

Benchmark on my MBP indicate that the change comes with a slight performance cost.

// v8 with patch
;;; satisfies?
[coll (list 1 2 3)], (satisfies? ISeq coll), 1000000 runs, 10 msecs
[coll [1 2 3]], (satisfies? ISeq coll), 1000000 runs, 27 msecs

//v8 without patch
;;; satisfies?
[coll (list 1 2 3)], (satisfies? ISeq coll), 1000000 runs, 8 msecs
[coll [1 2 3]], (satisfies? ISeq coll), 1000000 runs, 19 msecs
Comment by Thomas Heller [ 01/Jun/16 2:28 PM ]
// spidermonkey with patch
;;; satisfies?
[coll (list 1 2 3)], (satisfies? ISeq coll), 1000000 runs, 68 msecs
[coll [1 2 3]], (satisfies? ISeq coll), 1000000 runs, 146 msecs

// spidermonkey without patch
;;; satisfies?
[coll (list 1 2 3)], (satisfies? ISeq coll), 1000000 runs, 63 msecs
[coll [1 2 3]], (satisfies? ISeq coll), 1000000 runs, 149 msecs
Comment by Thomas Heller [ 01/Jun/16 2:35 PM ]

JavascriptCore

// jsc with path
;;; satisfies?
[coll (list 1 2 3)], (satisfies? ISeq coll), 1000000 runs, 7 msecs
[coll [1 2 3]], (satisfies? ISeq coll), 1000000 runs, 14 msecs

// jsc without patch
;;; satisfies?
[coll (list 1 2 3)], (satisfies? ISeq coll), 1000000 runs, 6 msecs
[coll [1 2 3]], (satisfies? ISeq coll), 1000000 runs, 13 msecs
Comment by Thomas Heller [ 02/Jun/16 3:40 AM ]

Added a second patch that uses a sentinel value as the protocol marker. Currently just a plain empty javascript object.

Running the benchmarks shows no real difference to just checking "true".

I also tried using a number or string as the sentinel value but could not find any significant difference either.

// emitted code on protocol impls
protocol.check.Dummy.prototype.protocol$check$TheProtocol$ = cljs.core.PROTOCOL_SENTINEL;

// the check (identical?)
cljs.core.PROTOCOL_SENTINEL === x.protocol$check$TheProtocol$




[CLJS-1657] Self-host: Implicit macro loading with alias Created: 01/Jun/16  Updated: 14/Aug/16  Resolved: 14/Aug/16

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

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

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

 Description   

If a namespace relies on implicit macro loading (described here https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure#namespaces), and an alias is used, it is possible for aliased symbol resolution to fail.

This can be reproduced by adding a 10th case in self-host.test/test-load-and-invoke-macros covering this situation:

(let [st (cljs/empty-state)]
        ;; Rely on implicit macro loading (ns loads its own macros), with an alias
        (cljs/eval-str st
          "(ns cljs.user (:require [foo.core :as foo]))"
          nil
          {:eval node-eval
           :load (fn [{:keys [macros]} cb]
                   (if macros
                     (cb {:lang :clj :source "(ns foo.core) (defmacro add [a b] `(+ ~a ~b))"})
                     (cb {:lang :clj :source "(ns foo.core (:require-macros foo.core))"})))}
          (fn [{:keys [value error]}]
            (is (nil? error))
            (cljs/eval-str st
              "(foo/add 300 500)"
              nil
              {:eval    node-eval
               :context :expr}
              (fn [{:keys [error value]}]
                (is (nil? error))
                (is (= 800 value))
                (inc! l))))))

This will result in:

Testing self-host.test

FAIL in (test-load-and-invoke-macros) (at .../clojurescript/builds/out-self/core-self-test.js:11545:454)
expected: (nil? error)
  actual: (not (nil? #error {:message "ERROR", :data {:tag :cljs/analysis-error}, :cause #object[TypeError TypeError: Cannot read property 'call' of undefined]}))

FAIL in (test-load-and-invoke-macros) (at .../clojurescript/builds/out-self/core-self-test.js:11548:49)
expected: (= 800 value)
  actual: (not (= 800 nil))


 Comments   
Comment by Mike Fikes [ 01/Jun/16 7:48 AM ]

Analysis: This is because, this bit of code https://github.com/clojure/clojurescript/blob/19510523ad9de3f16832d287bae86f701e8b4263/src/main/clojure/cljs/analyzer.cljc#L1817-L1820
has a branch that only works in non-bootstrap ClojureScript.

You can also work around the issue (or gain a better understanding) in several ways (if you can control the affected loading namespace—this won't work if this affects code down in a library you are loading):

1. You can add :include-macros true
2. You can load the self-macro-loading namespace twice. (For example, if at the REPL, you can (require [foo.core :as foo]) twice.) This causes the analysis state to be set up so that on the second require, it is taken care of in the first clause of the or in the linked code above.
3. You can even assoc-in enough state prior to the load so that you are effectively doing (2).

In all of these cases, when it fails, vs. when it succeeds, you can see a difference in the :require-macros key in the analysis map of the loading namespace ('cljs.user, for example). When it fails, you will see that this key is empty and when it succeeds, you will see that the key is populated, and in particular, with the foo alias.

In the case where you don't use an alias, implicit macro loading will fail in a way that won't be visible: The :require-macros key will not be set up as described above, but qualified symbol resolution will still succeed (foo.core/add in the example will resolve to foo.core$macros/add), probably simply owing to the way resolution is performed.

Comment by Mike Fikes [ 14/Aug/16 1:48 PM ]

As António Monteiro points out, this is no longer reproducible. My recommendation would be to add the additional unit test in the description and to also remove the workaround on this line

https://github.com/clojure/clojurescript/blob/756fa9bb196a97e0ae40fd644da5e492e0336c1c/src/test/self/self_parity/test.cljs#L233-L237

(and the two calls to it below), and ultimately with a patch to lock down these unit tests, resolve this as fixed.

Comment by António Nuno Monteiro [ 14/Aug/16 5:22 PM ]

As per Mike Fikes's feedback, attached a patch that adds the proposed unit test and removes the workaround for the issue from self parity tests.

Comment by David Nolen [ 14/Aug/16 7:05 PM ]

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





[CLJS-1656] Self-host: cljs.spec: speced-vars* fn not resolving Created: 31/May/16  Updated: 10/Jun/16  Resolved: 10/Jun/16

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

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

Attachments: Text File CLJS-1656.patch