<< Back to previous view

[CLJS-1444] Node.js shim requires `node` invocation to be in the same directory as shim script Created: 10/Sep/15  Updated: 24/Apr/17

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

Type: Defect Priority: Minor
Reporter: Martin Klepsch Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-In-bootstrapping-code-use-__dirname-to-calculate-pat.patch    

 Description   

Don't have time to provide a proper repro now but the basic issue can be illustrated by this:

~/c/boot-cljs-example (master=) node target/main.js
module.js:338
    throw err;
          ^
Error: Cannot find module '/Users/martin/code/boot-cljs-example/out/goog/bootstrap/nodejs.js'
    at Function.Module._resolveFilename (module.js:336:15)
    at Function.Module._load (module.js:278:25)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.<anonymous> (/Users/martin/code/boot-cljs-example/target/main.js:6:1)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:501:10)
~/c/boot-cljs-example (master=) cd target/
~/c/b/target (master=) node main.js
Starting...

This is compiled with boot because that was what I had at hand right now. The compiled shim looks like this:

var path = require("path");
try {
    require("source-map-support").install();
} catch(err) {
}
require(path.join(path.resolve("."),"out","goog","bootstrap","nodejs.js"));
require(path.join(path.resolve("."),"out","cljs_deps.js"));
goog.global.CLOSURE_UNCOMPILED_DEFINES = {"cljs.core._STAR_target_STAR_":"nodejs"};
goog.require("boot.cljs.main");
goog.require("cljs.nodejscli");

The problem here is that path.resolve(".") will return the directory the node command was invoked in and not the directory of the shim. (See the "Cannot find module..." error above)

A solution could be to use __dirname which always resolves to the directory of the current file. This might result in some breakage for existing setups.



 Comments   
Comment by Sebastian Bensusan [ 14/Oct/15 11:31 AM ]

I have a proposed solution but I fear that supporting "run from anywhere" adds essential complexity to the resulting code. My thought process:

1. Relative paths are desirable to produce "context free code." If the user chooses absolute paths, then that behavior is respected and there's nothing to handle (no "path algebra") .

2. When dealing with relative paths, the whole system needs to establish a "frame of reference", a root path. The ClojureScript compiler assumes the path from which it is compiling to be that frame of reference, which usually coincides with the top root of the project. Though arbitrary, it is the only choice that makes sense.

3. The frame of reference is not explicit anywhere in the code, since it is defined as ".". If it were explicit, it would reveal context, as in "/home/some-user/their-folder/this-project/".

4. When we approach the code from another reference point (executing the script from another directory), we first need to find the original compiler path (reference point,) and then resolve all paths from there. The compiler uses `cljs.closure/path-relative-to` for this purpose.

Path algebra:
compiler-path = __dirname - output-to

Node.js

var compiler-path = __dirname.replace(output-to, "")
path.resolve (compiler-path, output-dir, "goog", "base.js")
path.resolve (compiler-path, output-dir, "cljs_deps.js")

which assumes that if output-to was given relatively, then output-dir is also relative. If they are not in sync, more work needs to be done to keep them that way.

It's not up to me to decide if the extra complexity is worth the use-case. I actually hope there is a simpler solution to solve this that I'm not seeing.

Comment by Karol Majta [ 14/Mar/16 10:43 AM ]

I find this behavior really weird and would opt for switching to __dirname. I am also not sure i fully understand consequences of such switch (I have little cljs experience, speaking more from the perspective of nodejs user). My point is: current behavior renders clojurescript hard to use for commandline and desktop applications (namely electron).

For command line and desktop applications assumptions about CWD cannot be made. For now i run my applications through a bootstrap script JS script:

process.chdir(__dirname);
require('./target/out');

I am lucky that my code does not have to use the real CWD, but it's a hack more than a real solution.

Speaking from nodejs perspective:

1. Using absolute paths is considered a bad practice anyway.
2. Nodejs programs that don't use external packages (don't depend on node_modules) can be run from any CWD
3. Nodejs programs that do depend on node_modules will break if run from a different directory than the one containing node_modules, but this is expected behavior.

Comment by J. Pablo Fernández [ 26/Jan/17 5:42 AM ]

I just run into this problem when trying to develop an Electron application. The way it's working right now is essentially unpackageable. I think it would be nice to have this behavior even as an option and I'm happy to work on a patch.

Comment by J. Pablo Fernández [ 26/Jan/17 5:57 AM ]

As far as I can see, this is the relevant code:

https://github.com/clojure/clojurescript/blob/cdaeff298e0f1d410aa5a7b6860232270d287084/src/main/clojure/cljs/closure.clj#L1410-L1411

Comment by J. Pablo Fernández [ 26/Jan/17 6:15 AM ]

A potential workaround seems to use :simple optimization.

Comment by Matt Lee [ 21/Apr/17 12:02 PM ]

I have also just hit this issue in an electron app that I'm building. @pupeno did you get anywhere with your offer to work on a patch? I too would be happy to look in to a patch for this. Although I think I'll need some pointers to get started.

Comment by Matt Lee [ 22/Apr/17 5:36 AM ]

From a quick experiment this morning it looks like replacing path.resolve(".") with __dirname at https://github.com/clojure/clojurescript/blob/aa5f001300e9aebd976cb180f5b7ccb37fcb6898/src/main/clojure/cljs/closure.clj#L1460-L1461 works for a couple of simple electron and node apps. By work I specifically mean that the error doesn't occur even when the app is started from a current working directory that is different to the compilation directory, i.e. the code is path independent.

I'll attach a patch for this once I've done some more complete testing. Before then any feedback on this approach would be appreciated.

Comment by Matt Lee [ 23/Apr/17 1:51 AM ]

Attaching patch for the suggested fix of using __dirname instead of "." in the generated script. I have tested this with nodejs 6.10.0 and electron 1.6.5.

Comment by Matt Lee [ 24/Apr/17 2:34 AM ]

Also see: CLJS-1990





[CLJS-1990] Clojurescript programs targeting nodejs should support global installation Created: 28/Mar/17  Updated: 24/Apr/17

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

Type: Enhancement Priority: Minor
Reporter: Greg Haskins Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-CLJS-1990-Use-module-relative-__dirname-for-bootstra.patch    

 Description   

The top-level entry point in a :target :nodejs application uses $CWD relative paths to load the bootstrapping. See "path.resolve('.')" here: https://github.com/clojure/clojurescript/blob/296d0a69340e832b92ed742b3cd0304a06bea27f/src/main/clojure/cljs/closure.clj#L1460 for example.

This works fine for a local build, but is problematic when we try to globally install clojurescript (such as via 'npm install -g') because it requires the caller $CWD to be something that is likely to be unnatural (e.g. /usr/lib/node_modules/$pkg). Suggested fix is to replace "path.resolve('.')" with "__dirname".



 Comments   
Comment by Matt Lee [ 24/Apr/17 2:34 AM ]

Also see: CLJS-1444





[CLJS-2014] find on sorted-map entries broken Created: 19/Apr/17  Updated: 19/Apr/17

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

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


 Description   

The entries of a sorted-map no longer behave as expected when find is called on them.

cljs.user=> (find (first (sorted-map :key :val)) 0)
[:key :val]
; expected [0 :key]
cljs.user=> (find (first (sorted-map :key :val)) 1)
[:key :val]
; expected [1 :val]





[CLJS-2012] find on PHM with nil entry always returns nil entry Created: 19/Apr/17  Updated: 19/Apr/17

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

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

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

 Description   

The following always returns the nil entry:

(find (hash-map :a 1 :b 2 nil 3) :a) 
; [nil 3]


 Comments   
Comment by Francis Avila [ 19/Apr/17 10:11 AM ]

The way -find is called, it is guaranteed that (contains? coll k) was called and returned true first; -find is never responsible for membership testing. So the has-nil? is unnecessary. This would be a sufficient impl/patch:

(-find [coll k]
  (if (nil? k)
    [nil nil-val]
    (.inode-find root 0 (hash k) k nil)))

Now, whether this should be the contract for -find is a different story. We could potentially avoid double-lookup if -find were also responsible for membership testing: collections where testing membership also happens to retrieve the value could avoid doing it twice.

Comment by Thomas Mulvaney [ 19/Apr/17 10:19 AM ]

Yes, that is a much nicer patch. The current double lookup implementation of find is probably at its worst with PersistentTreeMaps which I think are O(log2n) rather than log32 like PHMs.





[CLJS-2001] Add map-entry? predicate Created: 06/Apr/17  Updated: 19/Apr/17

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-2001.patch    
Patch: Code and Test

 Description   

map-entry? has existed in Clojure since 1.8 would be nice to have it in ClojureScript.



 Comments   
Comment by Thomas Mulvaney [ 06/Apr/17 6:00 AM ]

The attached patch looks more like the first implementation of `map-entry?` as per CLJ-1831.

This is because ClojureScript returns PersistentVectors when iterating over PAM and PHM maps.

Comment by David Nolen [ 07/Apr/17 11:06 AM ]

This patch is no good. 2 element vectors are not MapEntry.

Comment by Francis Avila [ 07/Apr/17 7:22 PM ]

Given that Clojure still returns MapEntry (CLJ-1831 was backed out later) and CLJS returns vectors, it is probably impossible for this predicate to be portable. If we can't consider count-2 vectors map-entry?=true, then the only possible cljs impl is (defn map-entry? [x] false). Given this, perhaps the best solution is not to have map-entry? in cljs, to discourage people from using it in portable code.

Comment by David Nolen [ 12/Apr/17 1:03 PM ]

I'm fine with adding a MapEntry type which implements all the vector protocols and returning that instead. That work should be a separate issue though and then we can come back to this one.

Comment by Thomas Mulvaney [ 19/Apr/17 8:00 AM ]

This came about as I was porting some Clojure code. I was probably misusing/abusing map-entry? anyway. The code could be rewritten to check if something is a map first and then do the appropriate thing on the sequence of entries rather than doing the check from "with in" the collection.

As mentioned, a 2 element vector != MapEntry. So, I've opened an issue to track adding a MapEntry type: CLJS-2013





[CLJS-2013] Add MapEntry type Created: 19/Apr/17  Updated: 19/Apr/17

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


 Description   

It would be nice to have a MapEntry type in ClojureScript.

Since the introduction of the map-entry? predicate in Clojure 1.8 it has been trivial to determine if an object represents an entry in a map. Being able to distinguish a map entry from other data types is really handy when walking data amongst other things. Currently, ClojureScript uses PersistentVectors to represent entries from PersistentArrayMaps and PersistentHashMaps. PersistentTreeMaps use their own nodes to represent entries and as such would be unaffected.

Besides making it possible to use the the map-entry? predicate across both CLJ and CLJS code, there may space/performance benefits to having a specialised type.






[CLJS-2011] :modules cannot rely on code motion or dead code removal Created: 19/Apr/17  Updated: 19/Apr/17

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: 0
Labels: None


 Description   

Currently the :modules compiler option relies on code motion and dead code removal by the Closure Compiler. Many constructs used by CLJS are not moved/removed by Closure so the result will very likely be sub-optimal.

A demo repo is available here:
https://github.com/thheller/cljs-issues/tree/master/modules






[CLJS-2010] refer-clojure :rename throws on valid invocations Created: 18/Apr/17  Updated: 18/Apr/17

Status: Open
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: Unresolved Votes: 0
Labels: analyzer

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




[CLJS-910] JavaScriptCore 0xbbadbeef EXC_BAD_ACCESS when evaluating (list 0 1 ... 18) Created: 16/Dec/14  Updated: 18/Apr/17  Resolved: 10/Nov/15

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: Declined Votes: 0
Labels: None
Environment:

Embedded JavaScriptCore on iOS simulator
Connected via Weasel / simple-brepl
:whitespace optimization


Attachments: PNG File memory.png     Text File stacktrace.txt    

 Description   

If I evaluate

(list 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18)

JavaScriptCore exhibits a 0xbbadbeef EXC_BAD_ACCESS, with a fairly deep stacktrace:

(lldb) bt

  • thread #1: tid = 0x3f7e, 0x0111e583 JavaScriptCore`WTFCrash + 67, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xbbadbeef)
    frame #0: 0x0111e583 JavaScriptCore`WTFCrash + 67
    frame #1: 0x011395a9 JavaScriptCore`WTF::fastMalloc(unsigned long) + 1929
    frame #2: 0x00c9cb56 JavaScriptCore`WTF::Vector<JSC::UnlinkedInstruction, 0ul, WTF::UnsafeVectorOverflow>::expandCapacity(unsigned long) + 86
    frame #3: 0x00c90f27 JavaScriptCore`JSC::BytecodeGenerator::emitGetById(JSC::RegisterID*, JSC::RegisterID*, JSC::Identifier const&) + 311
    frame #4: 0x00fd4617 JavaScriptCore`JSC::DotAccessorNode::emitBytecode(JSC::BytecodeGenerator&, JSC::RegisterID*) + 551
    ...

(Full stack trace attached as stacktrace.txt)

This only occurs with :whitespace optimization and does not under :advanced.

If you evaluate (list 0), it works, and so does (list 0 1), all the way up to 17. Interestingly, it gets progressively slower as you evaluate longer lists.



 Comments   
Comment by Mike Fikes [ 16/Dec/14 12:35 PM ]

While the EXC_BAD_ACCESS is arguably a bug in JavaScriptCore, it is likely provoked by excessive memory usage of the (list 0 1 ...) form. The attached memory.png shows what appears to be 2^n memory usage for evaluating a list of size n. This graph was produced while REPLd into an iOS device, monitoring memory use from Xcode.

Comment by Mike Fikes [ 18/Dec/14 11:28 AM ]

The construct

(list 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18)

works in r2014 (released Nov 6, 2013), but fails in r2024 (released Nov 8, 2013).

In r2014, the emitted JavaScript is:

cljs.core.list.call(null, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18)

while in r2024 the emitted JavaScript is:

cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null,
cljs.core.List.EMPTY, 18), 17), 16), 15), 14), 13), 12), 11), 10), 9), 8), 7), 6), 5), 4), 3), 2), 1), 0)

This particular commit, between r2014 and r2014 on Nov 7 2013, is likely when the emitted JavaScript changed (I haven't pulled down that specific revision):

https://github.com/clojure/clojurescript/commit/5bcbc4745f599e352c51e01b210755a88aa4bc5f#diff-b64165608bed8fb21a132890b4e2fca2R1279

Comment by Mike Fikes [ 18/Dec/14 12:07 PM ]

Knowing this, it is trivial to reproduce this in desktop Safari (and also see that it works fine in Chrome and Firefox).

If you go to clojurescript.net, or himera.herokuapp.com, and define a function that returns a list constructed with (list 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18), you can see that those websites are built using ClojureScript r2014 or earlier, as cljs.core.list.call(null, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18) appears in the reader literal for the returned function.

But, with either of those sites, if you evaluate the following, you will cause a severe performance problem in Safari:

(conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj '() 21) 20) 19) 18) 17) 16) 15) 14) 13) 12) 11) 10) 9) 8) 7) 6) 5) 4) 3) 2) 1) 0)

My hope is that knowing this will make it easier to profile (using desktop tools) what is giving Safari grief executing the resulting JavaScript.

Comment by Mike Fikes [ 18/Dec/14 2:38 PM ]

I don't understand JavaScriptCore's evaluation strategy. I found that if you manually revise the deeply nested composition of cljs.core._conj.call(...) invocations to extract a temporary var or two, as below, then the "doubling" effect is cut short, and the code executes quickly.

This revised code essentially builds a list of length 13 first, and then conses on 3 more elements, and 3 more.

var list0 = cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null,cljs.core.List.EMPTY, 18), 17), 16), 15), 14), 13), 12), 11), 10), 9), 8), 7), 6);

var list1 = cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, list0, 5), 4), 3);

cljs.core._conj.call(null, cljs.core._conj.call(null, cljs.core._conj.call(null, list1, 2), 1), 0)

I found that I can cause something similar to occur from the ClojureScript side by adding a do form, as in:

(conj (conj (conj (conj (conj (do nil
(conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj (conj '() 21) 20) 19) 18) 17) 16) 15) 14) 13) 12) 11) 10) 9) 8) 7) 6) 5)) 4) 3) 2) 1) 0)

Comment by Mike Fikes [ 18/Dec/14 7:00 PM ]

This JavaScriptCore perf problem is easily reproduced purely with JavaScript:

inc=function( x ) { return x + 1; }

alert(
inc.call(null, inc.call(null, inc.call(null, inc.call(null,
inc.call(null, inc.call(null, inc.call(null, inc.call(null,
inc.call(null, inc.call(null, inc.call(null, inc.call(null,
inc.call(null, inc.call(null, inc.call(null, inc.call(null,
inc.call(null, inc.call(null, inc.call(null, inc.call(null,
inc.call(null, 1))))))))))))))))))))))

Try this, at, say jsfiddle.net and you will see it max a core and use several GB in Safari, but not FireFox or Chrome.

Comment by Mike Fikes [ 19/Dec/14 9:00 AM ]

As indicated in this ticket's description, this problem doesn't occur with :advanced mode optimizations. Just to confirm, I produced the JavaScript with :pseudo-names set to true for (list 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18), and you can see that it doesn't use the problematic "call" construct:

$cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$_conj$$($cljs$core$List$EMPTY$$, 18), 17), 16), 15), 14), 13), 12), 11), 10), 9), 8), 7), 6), 5), 4), 3), 2), 1), 0);

Correction 20-DEC-2014: Even with :advanced mode optimization, this occurs. The setting that is needed to avoid the "call" construct is {:static-fns true}, as was set for the above output. With {:static-fnc false}, the emitted coded under :advanced mode is:

$cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$_conj$$.call(null, $cljs$core$List$EMPTY$$, 18), 17), 17), 15), 14), 13), 12), 11), 10), 9), 8), 7), 6), 5), 4), 3), 2), 1);
Comment by Mike Fikes [ 19/Dec/14 9:09 AM ]

Since the fundamental problem is easily reproducible with pure JavaScript, I've opened a StackOverflow regarding it: http://stackoverflow.com/questions/27568249/javascriptcore-deeply-composed-call-performance

Comment by David Nolen [ 19/Dec/14 12:08 PM ]

That was the first thing I was going to suggest trying, repo in plain JavaScript. Thanks for doing this - I believe this may explain some oddities we've encountered elsewhere.

Comment by Mike Fikes [ 19/Dec/14 1:41 PM ]

I’ve filed rdar://19310764 with Apple, and copied it here for reference: http://openradar.appspot.com/radar?id=5864025753649152

Comment by Francis Avila [ 19/Dec/14 5:38 PM ]

Excellent debugging work. Shouldn't this be filed against webkit instead? http://www.webkit.org/quality/reporting.html. (I already searched for this issue in their bug tracker and found nothing.)

This still leaves open the question of whether CLJS should do anything to mitigate. Many of the cljs macros that shadow functions expand recursively--maybe they should expand to loops or reduces instead?

For example:

(defmacro list
  ([] '(.-EMPTY cljs.core/List))
  ([& xs]
    `(let [a# (array ~@(reverse xs))]
       (areduce a# i# l# (list)
         (. l# cljs$core$ICollection$_conj$arity$2 (aget a# i#))))))

Or maybe cheat and emit a ChunkedCons instead?

(defmacro cclist
  ([] '(.-EMPTY cljs.core/LIST))
  ([& xs]
    `(cljs.core/ChunkedCons.
       (cljs.core/ArrayChunk.
         (array ~@(reverse xs)) 0 ~(count xs))
       nil nil nil)))
Comment by Mike Fikes [ 19/Dec/14 6:54 PM ]

Thanks Francis. I've confirmed that it occurs in the WebKit Nightly r177573, and I've moved the ticket to https://bugs.webkit.org/show_bug.cgi?id=139847

Comment by Thomas Heller [ 20/Dec/14 4:19 AM ]

FWIW to toggle between fn.call(null, ...) and fn(...) you can use the compiler option {:static-fns true}. This works with all optimization levels (also :none) but I'm told it causes issues with the REPL. But if you don't use a REPL it is safe to use that option always, I have been for years. Maybe the best short term option.

Comment by Mike Fikes [ 20/Dec/14 8:43 AM ]

Given Thomas's comment, I now realize that my comments above regarding :whitespace and :advanced are incorrect. (My project.clj has a dev and release build, and in addition to a change in the optimization directive, I had a change in the :static-fns directive.)

The correction: This problem occurs for both :whitespace and :advanced, iff :static-fns is set to false.

Comment by David Nolen [ 20/Dec/14 3:22 PM ]

One thing I'm curious about is whether the issue manifests if you're not nesting calls to the same function? This should be easy to confirm with plain JavaScript.

Comment by Mike Fikes [ 20/Dec/14 4:26 PM ]

Hey David, it appears to still cause a problem even with distinct functions. (This fiddle exhibits the problem with distinct functions, so don't follow the link on mobile Safari: http://jsfiddle.net/mfikes/Lwr78cmk/1/ )

Comment by Mike Fikes [ 21/Dec/14 4:16 PM ]

Activity is occurring with the WebKit ticket:

1) It has been confirmed as reproducible
2) It appears to be imported into Apple's system (InRadar keyword added).

Additionally, I succeeded in reproducing the issue on an older PowerPC Mac OS X 10.4.11 Safari 4.1.3 (from 2010), so it is not a recent regression, FWIW.

Comment by Mike Fikes [ 03/Jan/15 7:43 PM ]

Note: CLJS-945 sets :static-fns true as the default.

Comment by David Nolen [ 03/Jan/15 7:49 PM ]

Mike this is true only for cljs.core.

Comment by Mike Fikes [ 06/Jan/15 1:42 PM ]

FWIW, the original ticket I filed with Apple (rdar://19310764) has subsequently been closed by Apple as a duplicate of rdar://19321122, which is the Apple ticket the WebKit team opened in association with https://bugs.webkit.org/show_bug.cgi?id=139847

Comment by Timothy Pratley [ 24/Jul/15 8:38 AM ]

Just for reference: https://github.com/google/closure-compiler/issues/1049

Comment by David Nolen [ 10/Nov/15 9:57 AM ]

this is an upstream bug that we are not going to fix that has known solutions, closing for now.

Comment by Mike Fikes [ 13/Nov/15 6:41 AM ]

Collected summary:

For certain forms like (list 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18), the generated JavaScript under :none involves nested call constructs provoking a known upstream O(2^n) perf issue in JavaScriptCore:
https://bugs.webkit.org/show_bug.cgi?id=139847

This can be worked around by passing the compiler option :static-fns true

Comment by Yehonathan Sharvit [ 14/Apr/16 1:23 AM ]

Why not making :static-fns true by default?

Comment by Mike Fikes [ 18/Apr/17 7:10 AM ]

Patch has landed upstream https://trac.webkit.org/changeset/215453/webkit and associated ticket closed as fixed.





[CLJS-2007] :main namespace silently ignored under :whitespace optimizations Created: 12/Apr/17  Updated: 16/Apr/17

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

Type: Defect Priority: Minor
Reporter: Kevin Lynagh Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: compiler
Environment:

cljs.jar 1.9.473. Full reproducible example at https://github.com/lynaghk/reproducible-reports/tree/master/1-main-option


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

 Description   

The ClojureScript compiler's :main option specifies an "entry point namespace". In the output JavaScript, I expect the compiler to include only the entry point namespace, and the transitive closure of namespaces required by that namespace.

However, in ClojureScript r1.9.473, the :main is silently ignored when :optimizations :whitespace is set.

As a user, my expectation is that the whitespace optimizations case would act the same as the simple optimizations case.

If this is not possible, I think the compiler should throw an error when the :main option is provided together with :optimizations :whitespace to prevent confusion / frustration.
(Ditto for behavior under :optimizations :none)

I'm happy to contribute a patch for whatever behavior the core team deems preferable.

Thanks

Kevin






[CLJS-2009] Remove unnecessary code introduced by CLJS-1973 Created: 14/Apr/17  Updated: 14/Apr/17  Resolved: 14/Apr/17

Status: Resolved
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-2009.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 14/Apr/17 11:22 AM ]

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





[CLJS-1954] "async" needs special munging since Feb2017 closure compiler Created: 25/Feb/17  Updated: 13/Apr/17  Resolved: 13/Apr/17

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

Type: Defect Priority: Blocker
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Completed Votes: 8
Labels: None

Patch: Code and Test

 Description   

I tried to release a new chromex library version and hit strange errors generated by new Closure compiler:

Feb 25, 2017 9:16:59 PM com.google.javascript.jscomp.LoggerErrorManager println
    SEVERE: /Users/darwin/code/chromex/test/.compiled/optimizations_advanced/cljs/core/async.js:1418: ERROR - Parse error. No newline allowed before '=>'
    var inst_18944 = async(inst_18943);
                                      ^
    
    Feb 25, 2017 9:16:59 PM com.google.javascript.jscomp.LoggerErrorManager printSummary

The problem is that "async" is kind of a reserved word in new Closure compiler. And code like this[1] will newly break advanced compilation.

I tried to fix it by adding "async" into list of js-reserved keywords in ClojureScript compiler, but this introduced another issue. Namespaces are subject of munging, so usage of goog.async.* stuff will break[2]. Also the compiler emitted a bunch of warnings about using reserved keywords in namespace names. I saw no easy way how to distinguish those cases. At least I created a dirty solution by hard-coding some extra logic into `munge` implementation just to fix my use-case. But in general this will probably require more precise solution.

[1] https://github.com/clojure/core.async/blob/d17eb8a50cfb022b83c0ba53715451a8fe2fd5fa/src/main/clojure/cljs/core/async.cljs#L270
[2] https://github.com/clojure/core.async/blob/d17eb8a50cfb022b83c0ba53715451a8fe2fd5fa/src/main/clojure/cljs/core/async/impl/dispatch.cljs#L29



 Comments   
Comment by Antonin Hildebrand [ 25/Feb/17 4:28 PM ]

I marked this as a blocker because core.async is heavily used and it newly breaks due to this issue in advanced mode.

You might want to grab the test and patches from here:
https://github.com/clojure/clojurescript/compare/master...darwin:cljs-1954

Although that fixed the immediate problems in my scenario, I assume you want to handle namespace munging in a more robust way. In rare cases there might be user-specified closure modules with "async" in their names as well, not only goog.async.

Comment by Antonin Hildebrand [ 25/Feb/17 4:41 PM ]

This is a dupe of CLJS-1953. Sorry, didn't see that.

Comment by Brandon Bloom [ 01/Mar/17 9:23 PM ]

This seems like a Google Closure Compiler bug: It shouldn't choke on "async" unless it precedes "function" or an arrow lambda (=>), since async isn't a reserved word (as far as I can tell), only a contextual keyword. Might get a quick response/fix if you file an issue over at https://github.com/google/closure-compiler

CLJS can probably workaround this, and arguably should, since if not invalid, using "async" as an identifier" is at least confusing with traditional syntax highlighting tools, etc.

Comment by António Nuno Monteiro [ 01/Mar/17 9:26 PM ]

This has been reported and a fix is in progress. Here's the ticket: https://github.com/google/closure-compiler/issues/2336

Comment by Len Weincier [ 27/Mar/17 2:35 AM ]

I see the closure-compiler issue is closed. Whats the process for this to hit Clojurescript ?

Comment by Dieter Komendera [ 27/Mar/17 3:46 AM ]

@Len as far as I know we first have to wait for a new release of the Closure compiler until we can bump it as done in http://dev.clojure.org/jira/browse/CLJS-1952

Comment by David Nolen [ 13/Apr/17 2:26 PM ]

fixed by http://dev.clojure.org/jira/browse/CLJS-2006





[CLJS-2008] backport fixes to threading macros Created: 13/Apr/17  Updated: 13/Apr/17

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

Type: Defect Priority: Major
Reporter: Christophe Grand Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Backport the fix for CLJ-1562 and CLJ-1418 (commit https://github.com/clojure/clojure/commit/5e655b5b12bde5d2b1434b82b1ed445815ea9a95)






[CLJS-1998] Printing an Object with a null prototype throws an error Created: 04/Apr/17  Updated: 13/Apr/17

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

Type: Defect Priority: Minor
Reporter: Jonathan Boston Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

ClojureScript doesn't handle printing objects with a null prototype:

(prn (.create js/Object nil)) ;;throws Uncaught TypeError: Cannot read property 'cljs$lang$ctorStr' of undefined
(str (.create js/Object nil)) ;;throws Uncaught TypeError: Cannot convert object to primitive value

For the first case, it looks like pr-writer-impl's last case needs a separate check for a nil object constructor. I've not yet investigated the second case.



 Comments   
Comment by David Nolen [ 07/Apr/17 11:09 AM ]

Is this a common JS pattern?

Comment by Jonathan Boston [ 07/Apr/17 11:40 AM ]

I assume it isn't since I only recently ran into it. But PDFjs uses it regularly, which is where the problem came to light.

It appears to be used for objects that are strictly for wrapping other data. Perhaps it's a performance optimization?

I'm away from a computer for the next few days, but can provide links/more info then as necessary.

Comment by David Nolen [ 07/Apr/17 12:03 PM ]

I'm happy to see a fix for the first case and I'd like hear more information about the second one.

Comment by Jonathan Boston [ 13/Apr/17 2:05 AM ]

So the second case is interesting and I'm not sure of the fix implications. The following plain javascript highlights the problem:

Object.create(null) + "";
"" + Object.create(null);
[Object.create(null)].join(""); //str implementation uses this

//all three calls give the following error
Uncaught TypeError: Cannot convert object to primitive value

The str implementation passes the value through to array.join, so we'd need to check for null prototypes for every str call.

Adding an extra conditional to printing out to the console seems harmless enough, but adding an extra conditional for every str call seems like it might not be worth it.

I'm happy to do a fix for whatever you suggest.





[CLJS-2006] Upgrade Closure Compiler to April 2017 release Created: 11/Apr/17  Updated: 12/Apr/17  Resolved: 12/Apr/17

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: 1
Labels: None

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

 Comments   
Comment by António Nuno Monteiro [ 11/Apr/17 6:12 PM ]

Patch attached to upgrade the version of Google Closure Compiler. This version also contains the fix for CLJS-1954.

Comment by David Nolen [ 12/Apr/17 1:04 PM ]

fixed https://github.com/clojure/clojurescript/commit/3a9e4b43a2c01be5ed8945b2a90d04dcd14af1c2





[CLJS-1593] Self-host: Munged minus macro Created: 25/Feb/16  Updated: 11/Apr/17

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

Type: Defect Priority: Trivial
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: bootstrap

Attachments: Text File 0001-CLJS-1593-only-return-a-var-when-we-re-looking-for-a.patch    
Patch: Code

 Description   

In bootstrap, the macro form of cljs.core/- is evidently available as _ so, for example

(_ 7 3)
works.

Repro:

cljs.user=> (require 'cljs.js)
nil
cljs.user=> (cljs.js/eval-str (cljs.js/empty-state)
  "(_ 7 3)" nil {:eval cljs.js/js-eval :context :expr} identity)
{:ns cljs.user, :value 4}


 Comments   
Comment by Erik Assum [ 07/Apr/17 4:29 PM ]

So, in self-hosted (at least) the munged names are available, you can see this for `+` as well

cljs.user=> (_PLUS_ 4 4)
8
(in-ns 'cljs.js)
nil
cljs.js=> (compile-str (empty-state) "(+ 4 4)" nil identity)
{:value "((4) + (4));\n"}
cljs.js=> (compile-str (empty-state) "(_PLUS_ 4 4)" nil identity)
{:value "((4) + (4));\n"}
cljs.js=>

With a special `ns-interns**` as

(defn ns-interns**
  "Bootstrap only."
  [sym]
  (let [ns-obj (find-ns-obj sym)
        ns     (Namespace. ns-obj sym)]
    (letfn [(step [ret k]
              (let [var-sym (symbol k #_(demunge k))] ;; not demunging the key
                (assoc ret
                  var-sym (Var. #(gobject/get ns-obj k)
                            (symbol (str sym) (str var-sym)) {:ns ns}))))]
      (reduce step {} (js-keys ns-obj)))))

you see that `-` is stored under `_`, e.g. the munged name in the ns-object

cljs.core=> (get (ns-interns** 'cljs.core$macros) '_)
#'cljs.core$macros/_
cljs.core=>
Comment by Mike Fikes [ 11/Apr/17 8:00 AM ]

Interestingly, the patch works for cljs.core/- but it doesn't seem to completely work for new symbols defined in cljs.user, if I'm interpreting this correctly:

cljs.user=> (require 'cljs.js)
true
cljs.user=> (def st (cljs.js/empty-state))
#'cljs.user/st
cljs.user=> (cljs.js/eval st '(def foo-bar 17) {:eval cljs.js/js-eval :context :expr} identity)
{:value 17}
cljs.user=> (cljs.js/eval st 'foo_bar {:eval cljs.js/js-eval :context :expr} identity)
WARNING: Use of undeclared Var cljs.user/foo_bar
{:value 17}
Comment by Erik Assum [ 11/Apr/17 3:05 PM ]

Yep

cljs.user=> (def foo-bar 17)
#'cljs.user/foo-bar
cljs.user=> foo_bar
            ^
WARNING: Use of undeclared Var cljs.user/foo_bar at line 1
17
cljs.user=>

Don't remember the details now, but the way I got to fixing the minus was by the code-path which
tries to figure out macros, IIRC.

I guess I'll have to look at the code-path which resolves normal symbols as well.





[CLJS-2005] Bad error message with duplicate arity function definitions. Created: 10/Apr/17  Updated: 10/Apr/17

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

Type: Defect Priority: Minor
Reporter: Russ Olsen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MacOS X
Clojure 1.9.0-master-SNAPSHOT
Java HotSpot(TM) 64-Bit Server VM 1.8.0_65-b17

Also Lumo



 Description   

If you write a multi-arity function with duplicate arities, like this:

(defn myfun ([x] x) ([x] x))

You get a very uninformative error message from the cljs compiler:

Duplicate case test constant '1' on line 1 at line 1

The JVM compiler produces a much clearer error message:

CompilerException java.lang.RuntimeException: Can't have 2 overloads with same arity,...






[CLJS-2004] Minor fix for test-simple script Created: 10/Apr/17  Updated: 10/Apr/17

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

Type: Enhancement Priority: Minor
Reporter: Dejan Josifovic Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: clojurescript, script, test
Environment:

Lubuntu 16.10


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

 Description   

On Ubuntu based Linux distributions $[] doesn't work.
Output is: Tested with $[ran+1] out of 4 possible js targets
and should be: Tested with 4 out of 4 possible js targets

As in CLJS-929 (for test script), $(()) will work for ash, dash, bash, and zsh.



 Comments   
Comment by Dejan Josifovic [ 10/Apr/17 2:42 PM ]

Add patch.





[CLJS-1320] clojure.string/split adds separator matches & failed matches (nil) when the separator is a regex with alternation Created: 26/Jun/15  Updated: 10/Apr/17

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

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


 Description   

I want to split a string on "; ", and optionally discard a final ";". So, I tried:

(clojure.string/split "ab; ab;" #"(; )|(;$)")

In Clojure, this does what I want:

["ab" "ab"]

In ClojureScript, I get:

["ab" "; " nil "ab" nil ";"]

I'm not sure to what extent this is a platform distinction and to what extent it's a bug. Returning nils and seperators from clojure.string/split's output seems like it's against string.split's contract?



 Comments   
Comment by Erik Assum [ 10/Apr/17 11:12 AM ]

Might not be the answer you want, but Clojurescript uses js' split implementation.
Testing this in the browser you get

> "ab; ab;".split(/(; )|(;$)/)
< ["ab", "; ", undefined, "ab", undefined, ";", ""] (7)
>

from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/split

If separator is a regular expression that contains capturing parentheses, then each time separator is matched, the results (including any undefined results) of the capturing parentheses are spliced into the output array. However, not all browsers support this capability.

Which means that to avoid this, you should use non-capturing groups:

(clojure.string/split "ab; ab;" #"(?:; )|(?:;$)")

Which incidentally can be simplified to

(clojure.string/split "ab; ab;" #";(?: |$)")

Which produces the result you're after in both clojure and clojurescript.





[CLJS-2003] munge/demunge in cljs.core has too many calls to str Created: 10/Apr/17  Updated: 10/Apr/17

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

Type: Enhancement Priority: Trivial
Reporter: Erik Assum Assignee: Erik Assum
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File 0001-CLJS-2003-remove-redundant-calls-to-str-in-munge-dem.patch    
Patch: Code




[CLJS-1009] Allow deps.cljs to declare a foreign lib as remote Created: 05/Feb/15  Updated: 08/Apr/17

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

Type: Enhancement Priority: Trivial
Reporter: Martin Klepsch Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None

Attachments: Text File 0001-CLJS-1009-allow-remote-url-in-deps.cljs-foreign-libs.patch    

 Description   

When using things like the Google Maps JS API [1] the Javascript that is required can't be bundled inside a jar as it depends on the used API key.

To be able to provide externs for those kind of libraries there should be a way to declare them as "remote" in deps.cljs.

[1] https://developers.google.com/maps/documentation/javascript/tutorial



 Comments   
Comment by Nathan Dao [ 08/Apr/17 6:43 PM ]

js_deps.cljs deliberately only allows upstream foreign-libs (defined in deps.cljs file) to be local file. Yet, this issue is still open, so I (hastily ) assume the local file enforcement was not intentional.

The patch should add back support for using url as foreign-libs in deps.cljs and remove unused codes in load-foreign-library*.





[CLJS-1497] `find` on an associative collection does not return collection key Created: 30/Nov/15  Updated: 07/Apr/17  Resolved: 07/Apr/17

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

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

Attachments: Text File CLJS-1497-2.patch     Text File CLJS-1497-3.patch     Text File CLJS-1497-4.patch     Text File CLJS-1497.patch    
Patch: Code and Test

 Description   

Instead find returns the passed in key. This means metadata on the key will appear to be lost. Related to CLJS-1496.



 Comments   
Comment by Rohit Aggarwal [ 15/Jun/16 3:39 PM ]

Proposed Plan

IAssociative protocol has a function called -entry-at which has been commented out. This function needs to be implemented which will return the necessary data structure, similar to the way it has been done in Clojure.

An example of its implementation for PersistentArrayMap is:

(-entry-at
 [coll k]
 (let [idx (array-map-index-of coll k)]
   (when-not (neg? idx)
     [(aget arr idx) (aget arr (inc idx))])))

We will need to implement this for all the collections which implement that protocol.

A failing test case:

(deftest test-find-meta-cljs-1497
  (let [k        [1 2 3]
        m        {:my "meta"}
        v        1
        xs       {(with-meta k m) v}
        [k' v']  (find xs k)]
    (is (= k k'))
    (is (= v v'))
    (is (= m (meta k')))))
Comment by António Nuno Monteiro [ 13/Nov/16 10:23 AM ]

Attached patch with proposed fix and tests.

Comment by Alex Miller [ 18/Nov/16 7:50 PM ]

dnolen's comment was lost here in a system migration, but he said: "The proposed patch is a breaking change for people who implement custom collections. We need a new protocol `IEntryAt` or something like this."

Comment by António Nuno Monteiro [ 21/Dec/16 9:03 AM ]

Attached an updated patch as per review comments.

Comment by David Nolen [ 07/Apr/17 11:30 AM ]

Finally getting around to commenting on this patch. We don't want to change an existing protocol. `IFind` should be a new protocol with one method `-find` and we should leave the other protocol alone. That is this patch should be additive only please.

Comment by António Nuno Monteiro [ 07/Apr/17 11:45 AM ]

Attached new patch addressing feedback comments.

Comment by David Nolen [ 07/Apr/17 12:02 PM ]

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





[CLJS-1996] Support correct checking of :preloads when :optimizations not specified Created: 03/Apr/17  Updated: 07/Apr/17  Resolved: 07/Apr/17

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

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

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

 Comments   
Comment by David Nolen [ 07/Apr/17 11:16 AM ]

fixed https://github.com/clojure/clojurescript/commit/79509651e16bf2b2fdc60a39de8671ef96206055





[CLJS-1997] Outward function type hint propagation Created: 03/Apr/17  Updated: 07/Apr/17

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

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

Attachments: Text File CLJS-1997.patch    

 Description   

New feature: Detect the type of a function and arrange so that it is available for outward type hinting.

For reference, a small amount of discussion from Jan 2016 in the #cljs-dev Slack:

mfikes: Curious if "outward" ^boolean propagation has been debated / rejected. Example: If simple analysis detects that ^boolean can be applied as in for functions like (defn f [x] (not x)). Perhaps automatically propagating type hints in this direction would be unwelcome by users?

dnolen: @mfikes: we have already have outward propagation for numerics which broke because of changes for code motion

dnolen: absolutely nothing against that



 Comments   
Comment by Mike Fikes [ 03/Apr/17 7:38 PM ]

The attached patch will handle cases like

(defn foo? [x] (or (string? x) (number? x)))

and

(def baz (fn ([x] 1) ([x y] 2)))

but it doesn't attempt to address the case of multi-arity defn s, as these are implemented by dispatching to multiple single-arity functions that could have different return types.

It adds a :inferred-ret-tag to the AST only because the arguments to or on line 18 in the patch are not reversed (only to allow explicit hints to override inferred hints, but perhaps that is overcomplicating things and the inferred tag could be dropped directly into :ret-tag.)

Bronsa helpfully pointed out in Slack that outward type hint propagation is avoided in Clojure because it breaks things like:

(defn foo [] 1)
(defn bar [] (String/valueOf (foo)))
(defn foo [] "foo")
(bar)

for which an analogy in ClojureScript would be:

(defn foo? [] true)
(defn bar [] (if (foo?) :t :f))
(defn foo? [] "")
(bar)

where the patch causes it to yield :f.

This could be viewed as a REPL-only concern (perhaps addressed by another compiler flag along the lines of :static-fns).

But, arguably the problem already exists today, with type hinting in code like the following affecting the compilation of bar:

(def foo? true)
(defn bar [] (if foo? :t :f))
(def foo? "")
(bar)
Comment by David Nolen [ 07/Apr/17 11:15 AM ]

Thanks will think about it





[CLJS-1994] assoc on nil returns PHM (expected PAM) Created: 01/Apr/17  Updated: 07/Apr/17  Resolved: 07/Apr/17

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

Type: Defect Priority: Trivial
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1994.patch    

 Description   

(assoc nil :foo 1) results in a PersistentHashMap in CLJS but a PersistentArrayMap in CLJ.



 Comments   
Comment by Thomas Heller [ 04/Apr/17 2:11 AM ]

Updated patch to address warning about undeclared cljs.lang.PersistentArrayMap.

Comment by David Nolen [ 07/Apr/17 11:13 AM ]

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





[CLJS-1981] ./script/bootstrap fails on FreeBSD 11.0 Created: 15/Mar/17  Updated: 07/Apr/17

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

Type: Defect Priority: Minor
Reporter: Duncan Bayne Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bootstrap, bug
Environment:

$ git rev-list HEAD | head -n 1
f7d08ba3f837f3e2d20ebdaf487221b18bb640c7

$ uname -a
FreeBSD x220 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64

$ java -version
openjdk version "1.8.0_112"
OpenJDK Runtime Environment (build 1.8.0_112-b16)
OpenJDK 64-Bit Server VM (build 25.112-b16, mixed mode)



 Description   

When I run ./script/bootstrap, it fails when trying to invoke unzip. I think it's expecting GNU/Linux unzip, or something similar:

$ ./script/bootstrap
Usage: unzip [-aCcfjLlnopqtuvyZ1] [-d dir] [-x pattern] zipfile
The 'unzip' utility is missing, or not on your system path.



 Comments   
Comment by David Nolen [ 17/Mar/17 1:51 PM ]

I'm assuming you can install unzip no? If not then please provide a patch that generalize the bootstrap script. Thanks.

Comment by Duncan Bayne [ 06/Apr/17 2:08 AM ]

Yes, unzip is already installed. I'll attempt to generalize it.

If that fails - that is, if there is no suitable set of common arguments to GNU unzip and BSD unzip - I'll detect the unzip type and send the correct commands.

Comment by David Nolen [ 07/Apr/17 11:08 AM ]

This just doesn't seem like a problem. Just install unzip, just like you need to install Java etc.





[CLJS-2002] Don't throw when no *print-fn* is set Created: 07/Apr/17  Updated: 07/Apr/17

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

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


 Description   

Currently calling (enable-console-print!) causes a bunch of code to be retained in :advanced mode even if you never print.

While that is not ideal it doesn't cause runtime errors. Not calling it and trying to print however will throw an exception which will potentially break your app.

No *print-fn* fn set for evaluation environment

So we end up in a no-win situation for :advanced builds where a "forgotten" prn may break your app in production or "maybe" bloating your file size by retaining all the print-related things.

I think the no-print-fn condition should never throw, maybe just try to write a warning using console.log. Or just dropping the prn altogether.






[CLJS-2000] Don't log deprecation warnings on recursive calls to the same function with a different arity Created: 05/Apr/17  Updated: 06/Apr/17

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

Type: Defect Priority: Minor
Reporter: Daniel Compton Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: warning


 Description   

If a function has two arity's where one calls the other, then if that function is marked with `^:deprecated`, then compile warnings about deprecations will always be emitted while that function exists. E.g.

(defn ^:deprecated test-deprecated
  ([]
    (test-deprecated nil))
  ([a]
    nil))

produces these logs:

WARNING: my.test/test-deprecated is deprecated. at line 3 src/my/test/error.cljs

I think that only outside references to a deprecated function should warn here. Otherwise, it's impossible to deprecate a multi-arity function and still get clean compiles.






[CLJS-1999] Nullpointer Exception while compiling node module Created: 05/Apr/17  Updated: 05/Apr/17  Resolved: 05/Apr/17

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

Type: Defect Priority: Major
Reporter: Daniel Große Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug, compiler
Environment:

MacOSX 10.11.6
Node 7.8.0
npm 4.5.0



 Description   

While trying the compilation of an node module, I got an exception thrown.

monospaced
lein cljsbuild once  1 ↵  2506  16:17:41
Compiling ClojureScript.
Compiling "resources/autobahn_cljs.js" from ["src"]...
Compiling "resources/autobahn_cljs.js" failed.
java.lang.NullPointerException
at com.google.javascript.jscomp.ProcessCommonJSModules.getScopeInsertionPoint(ProcessCommonJSModules.java:242)
at com.google.javascript.jscomp.ProcessCommonJSModules.access$400(ProcessCommonJSModules.java:42)
at com.google.javascript.jscomp.ProcessCommonJSModules$FindImportsAndExports.addGoogProvide(ProcessCommonJSModules.java:556)
at com.google.javascript.jscomp.ProcessCommonJSModules.process(ProcessCommonJSModules.java:125)
at com.google.javascript.jscomp.Compiler.processAMDAndCommonJSModules(Compiler.java:1841)
at com.google.javascript.jscomp.Compiler.parseInputs(Compiler.java:1549)
at com.google.javascript.jscomp.Compiler.parse(Compiler.java:809)
at cljs.closure$eval5980$fn__5981.invoke(closure.clj:1601)
at clojure.lang.MultiFn.invoke(MultiFn.java:238)
at cljs.closure$process_js_modules$fn__6251.invoke(closure.clj:2156)
at clojure.core$map$fn__4785.invoke(core.clj:2646)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:521)
at clojure.core$seq__4357.invokeStatic(core.clj:137)
at clojure.core$apply.invokeStatic(core.clj:641)
at clojure.core$mapcat.invokeStatic(core.clj:2674)
at clojure.core$mapcat.doInvoke(core.clj:2674)
at clojure.lang.RestFn.invoke(RestFn.java:423)
at cljs.closure$process_js_modules.invokeStatic(closure.clj:2155)
at cljs.closure$process_js_modules.invoke(closure.clj:2127)
at cljs.closure$build.invokeStatic(closure.clj:2229)
at cljs.closure$build.invoke(closure.clj:2216)
at cljs.closure$build.invokeStatic(closure.clj:2219)
at cljs.closure$build.invoke(closure.clj:2216)
at cljsbuild.compiler$compile_cljs$fn__6424.invoke(compiler.clj:81)
at cljsbuild.compiler$compile_cljs.invokeStatic(compiler.clj:80)
at cljsbuild.compiler$compile_cljs.invoke(compiler.clj:69)
at cljsbuild.compiler$run_compiler.invokeStatic(compiler.clj:187)
at cljsbuild.compiler$run_compiler.invoke(compiler.clj:143)
at user$eval6558$iter_65946598$fn6599$fn_6617.invoke(form-init8848799542314272754.clj:1)
at user$eval6558$iter_65946598$fn_6599.invoke(form-init8848799542314272754.clj:1)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:521)
at clojure.core$seq__4357.invokeStatic(core.clj:137)
at clojure.core$dorun.invokeStatic(core.clj:3024)
at clojure.core$doall.invokeStatic(core.clj:3039)
at clojure.core$doall.invoke(core.clj:3039)
at user$eval6558.invokeStatic(form-init8848799542314272754.clj:1)
at user$eval6558.invoke(form-init8848799542314272754.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.eval(Compiler.java:6917)
at clojure.lang.Compiler.load(Compiler.java:7379)
at clojure.lang.Compiler.loadFile(Compiler.java:7317)
at clojure.main$load_script.invokeStatic(main.clj:275)
at clojure.main$init_opt.invokeStatic(main.clj:277)
at clojure.main$init_opt.invoke(main.clj:277)
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)
Subprocess failed
monospaced

A demo repository can be found under: https://github.com/Ninerian/npm-compile-test



 Comments   
Comment by António Nuno Monteiro [ 05/Apr/17 10:06 AM ]

This is not a clojureScript issue. It's fixed in Closure Compiler master and we're waiting on a new release. Relevant issue: https://github.com/google/closure-compiler/issues/2345





[CLJS-1995] Possible conflict with automatic aliases for JS modules Created: 02/Apr/17  Updated: 02/Apr/17

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   

https://clojurescript.org/guides/javascript-modules

The hello-es6 example uses a directory to apply :module-type to every file in that directory.

{:file "src" :module-type :es6}

This leads to src/js/hello.js being aliased to the js.hello ns which .cljs files can then :require.

Given a directory structure like this:

{:file "lib-a" :module-type :es6}
{:file "lib-b" :module-type :es6}

.
├── lib-a
│   └── js
│       └── hello.js
├── lib-b
│   └── js
│       └── hello.js

Leads to lib-b silently replacing lib-a as they both claim the js.hello name.

The same issue is present in closure-compliant libs but they typically follow some kind of manual namespacing (ie. goog.string, cljs.core, ...) which ES6/JS libs do not do (and do not even support given their use of relative imports vs absolute imports)

Not sure how to handle this but at the very least there should be some kind of warning that there is a conflicting alias.

Demo here: https://github.com/thheller/hello-es6-conflict






[CLJS-1471] :source-map-path doesn't work anymore Created: 15/Oct/15  Updated: 31/Mar/17  Resolved: 16/Oct/15

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

Type: Defect Priority: Major
Reporter: Jean-Louis Giordano Assignee: Sebastian Bensusan
Resolution: Declined Votes: 0
Labels: None


 Description   

:source-map-path should be prepended to //# sourceMappingURL=main.js.map but it isn't.

This is a relatively important feature for us because the error logging tool we use needs an absolute path to the map files in order to work with them.



 Comments   
Comment by Sebastian Bensusan [ 15/Oct/15 6:17 PM ]

Hi Jean-Louis Giordano

Are you reporting a regression? Can you provide the compiler options that produce the error and the last ClojureScript version that worked as expected as well as the obtained values for sourceMappingURL?

Thanks!

Comment by Jean-Louis Giordano [ 16/Oct/15 12:28 AM ]

I'm assuming it's a regression because the behaviour is documented here:

https://github.com/clojure/clojurescript/wiki/Compiler-Options#source-map-path

But I haven't gotten it to work in recent versions of ClojureScript.

Using the "mies" template https://github.com/swannodette/mies with "lein new sourcemap_prefix" and changing the `script/release.clj` to look like this:

Unable to find source-code formatter for language: clj. Available languages are: javascript, sql, xhtml, actionscript, none, html, xml, java
(require '[cljs.build.api :as b])

(println "Building ...")

(let [start (System/nanoTime)]
  (b/build "src"
    {:output-to "release/sourcemap_prefix.js"
     :output-dir "release"
     :optimizations :advanced
     :source-map "release/sourcemap_prefix.js.map"
     :source-map-path "/prefix"
     :verbose true})
  (println "... done. Elapsed" (/ (- (System/nanoTime) start) 1e9) "seconds"))

I expect to see:

//# sourceMappingURL=/prefix/sourcemap_prefix.js.map

But I get:

//# sourceMappingURL=sourcemap_prefix.js.map
Comment by Sebastian Bensusan [ 16/Oct/15 8:39 AM ]

Thanks for taking the time to provide the config. I think the problem is in the documentation.

When it comes to source maps and url linking, there are two distinct steps:

  1. Linking the generated JavaScript to the source map file
    ("release/sourcemap_prefix.js" to
    "release/sourcemap_prefix.js.map"). This is achieved by adding {{//#
    sourceMappingURL= <url>}} at the bottom of the generated JavaScript.
    According the source mapping spec[1], if url is not absolute,
    it will be resolved from the generated's JavaScript path. The
    generated JavaScript path is controlled by :output-to and the
    source map url is controlled by :source-map. Right now,
    ClojureScript makes sure `//# sourceMapping=<url>` is relative to
    :output-to so that is correctly resolved in the browser. I
    believe you are interested in this part of the problem which
    doesn't involve :source-map-path. To get the desired behavior,
    please try with an absolute :source-map and report back.
    There might be a bug there. If there is, either change this issue
    to reflect that, or open another one.
  2. Linking the lines inside the source map file to the actual
    ClojureScript sources. Inside the source map file there is a
    mapping between line numbers and ClojureScript files.
    :source-map-path is meant for those mappings. Without :source-map-path
    you get:
{
    ...
    "sources": ["goog/base.js", "sourcemap_prefix/core.cljs"],
    ...
}

and if you add :source-map-path "js/compiled":

{
    ...
    "sources": [
        "js/compiled/goog/base.js",
        "js/compiled/sourcemap_prefix/core.cljs"
        ],
    ...
}

This is useful when the root directory of your web server's assets
is not the same as :output-dir. In this regard,
:source-map-path solves the same need than :asset-path.

I will expand the docs, to include these clarifications.

Hope this helps

[1] https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit?hl=en_US&pli=1&pli=1

Comment by Jean-Louis Giordano [ 16/Oct/15 9:19 AM ]

OK I see now what source-map-path is for. But I'm a bit confused... What compiler options should I use if I want to use an absolute path for the sourceMappingUrl then? Or is that not supported?

Comment by Sebastian Bensusan [ 16/Oct/15 9:39 AM ]

Did you try with an absolute :source-map?

Comment by Jean-Louis Giordano [ 16/Oct/15 9:46 AM ]

Yes but I got an error ":source-map "/prefix/sourcemap_prefix.js.map" must specify a file in the same directory as :output-to "release/sourcemap_prefix.js" if optimization setting applied"

So I'm not sure what I should use as :source-map?

This is what I used:

Unable to find source-code formatter for language: clj. Available languages are: javascript, sql, xhtml, actionscript, none, html, xml, java
(b/build "src"
    {:output-to "release/sourcemap_prefix.js"
     :output-dir "release"
     :optimizations :advanced
     :source-map "/prefix/sourcemap_prefix.js.map"
     :verbose true})
Comment by Sebastian Bensusan [ 16/Oct/15 11:34 AM ]

OK, we are almost there. The issue is that `:source-map` doesn't support absolute paths. It is clear that you want //# sourceMappingURL="/prefix/sourcemap_prefix.js.map" on the final JavaScript but it is not clear where should the compiler place the file now, under "/your/projects/path/release/prefix/sourcemap_prefix.js.map" or under "/your/projects/path/prefix/sourcemap_prefix.js.map".

Presumably the answer to this depends on where you place the webserver's root path, which may be "release" or something else.

Also, can you point us to the error logging tool to see the docs and what's expected?

Comment by Jean-Louis Giordano [ 16/Oct/15 12:17 PM ]

I would like the compiler to place the file at:

"/your/projects/path/release/sourcemap_prefix.js.map", next to its JS counterpart at
"/your/projects/path/release/sourcemap_prefix.js"

But I would also like:
//# sourceMappingURL="/prefix/sourcemap_prefix.js.map"

I compile the app to a `release` folder, but then serve it under a `/prefix` through a webserver.
So http://myapp.com/prefix/sourcemap_prefix.js

I hope I am not wasting too much of your time due to my misunderstandings! Thank you for your patience.

The tool we're using is Honeybadger (https://app.honeybadger.io/), but according to their docs they seem to support relative sourcemaps just fine: https://github.com/honeybadger-io/honeybadger-js
Sorry I should have done better research on that front.

Summary so far:

  • I misunderstood the point of source-map-path (sorry about that)
  • I misunderstood the requirements of the reporting tools I'm using (sorry about that)
  • the compiler does not support absolute paths for the outputted sourceMappingURL
Comment by Sebastian Bensusan [ 16/Oct/15 1:18 PM ]

No problem, glad to help.

If you ask for "#// sourceMappingURL="/prefix/sourcemap_prefix.js.map" and then place it somewhere else, it will then be your responsibility to get "release" under "prefix". If you don't do that, source maps won't work for the browser, nor the logging tool.

Even though your request sounds legitimate (there could be other reasons to put it under an absolute path), I believe that the compiler is doing the right thing by ignoring the absolute path use case, in order to save 99% of the users from themselves. Since you can solve it, with the existing tools, I will close this. If somebody else needs something similar, we'll consider it in another issue.

Comment by Sebastian Bensusan [ 16/Oct/15 1:20 PM ]

The real problem could be solved without modifying the compiler.

Comment by Shaun LeBron [ 31/Mar/17 1:29 PM ]

the issue of customizing the `sourceMappingURL` was addressed with the `source-map-asset-path` option: https://github.com/clojure/clojurescript/commit/17bcf2a091accb6f7caf1e8fa3954b490e9d34fa





[CLJS-1991] ClojureScript compiler generates invalid JavaScript code when name contains emoji Created: 30/Mar/17  Updated: 31/Mar/17

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

Type: Defect Priority: Trivial
Reporter: Thai Pangsakulyanont Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: compiler
Environment:

ClojureScript Compiler 1.9.495 (note: I selected 1.9.293 because 1.9.495, the currently released version, is not available)


Attachments: Text File CLJS-1991-Munge-non-identifier-unicode-characters.patch    

 Description   

Clojure (for JVM) handles code that contains emoji just fine, as shown in this example REPL session:

user=> (let [🖌 1] 🖌)
1

However, in ClojureScript, it generates an invalid JavaScript code:

app:cljs.user=> (let [🖌 1] 🖌)
#object[SyntaxError SyntaxError: Invalid or unexpected token]

This is because 🖌 is not a valid JavaScript name.

If this name should not be acceptable in ClojureScript as well, I think the compiler should raise an error during compilation instead of producing an invalid JavaScript code. However, it would be better such names are supported, because 1) Clojure works with such name and 2) it would allow writing code more expressively.

Actual result: Invalid JavaScript code is generated:

var 🖌_38518 = (1);

Expected result: Invalid JavaScript identifiers that's allowed in Clojure should be escaped:

var _1F58C__38518 = (1);


 Comments   
Comment by Thai Pangsakulyanont [ 31/Mar/17 8:24 AM ]

I added a simple patch that fixes this problem. Also a test is added to verify the fix. I have already signed the Clojure CA.


To give an example of how emojis might be useful in ClojureScript, I am creating a web page using ClojureScript and I want to define a color scheme. I could use the “artist palette” emoji to refer to the color palette.

(def 🎨 {:red    "#A4303F"
         :yellow "#FFECCC"
         :green  "#C8D6AF"
         :blue   "#254E70"})

This allows the code to be used like this:

[:div {:style {:color (🎨 :red)}} "Error!"]

One could also take advantage of the colors to make the code easier to understand:

(def ❤️ "#A4303F")
(def 💛 "#FFECCC")
(def 💚 "#C8D6AF")
(def 💙 "#254E70")

Current workaround: It is possible to use an emoji when referring to other namespaces, like this:

(ns mysite.core
  (:require [mysite.theme.colors :as 🎨]))

In this case, 🎨 can be used without generating a syntax error, because after compilation they will be replaced by mysite.theme.colors





[CLJS-1993] cljs.spec: form of cljs.spec/every is broken Created: 31/Mar/17  Updated: 31/Mar/17  Resolved: 31/Mar/17

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

Type: Defect Priority: Major
Reporter: Tommi Reiman Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Environment:

tested with 1.9.494 (the dropdown doesn't allow that)



 Description   

Trying to generate JSON Schemas out of Specs using forms and bumped into this:

cljs.spec/every produces broken form. This is how it looks on the Clojure (1.9.0-alpha15) side:

(s/form (s/every integer?))
; => (clojure.spec/every clojure.core/integer?)

This the ClojureScript version:

(s/form (s/every integer?))
; (cljs.spec/every integer? :cljs.spec/kind-form nil :cljs.spec/cpred #object[Function "function (G__19233){
; return cljs.core.coll_QMARK_.call(null,G__19233);
; }"])


 Comments   
Comment by António Nuno Monteiro [ 31/Mar/17 9:22 AM ]

This is solved in master





[CLJS-1992] Warn when using declare after def Created: 30/Mar/17  Updated: 30/Mar/17

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

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

Attachments: Text File CLJS-1992.patch    

 Description   

Currently no warning is emitted when using declare after defn or def.

The effect of a declare after a defn is that all the fn-arity information is lost and only "unoptimized" invokes are emitted instead.

I added a warning which identified them some offenders in cljs.core.

WARNING: deref at line 1354 is being replaced (cljs/core.cljs at 5031:1) 
WARNING: reset! at line 4288 is being replaced (cljs/core.cljs at 6488:1) 
WARNING: atom at line 4269 is being replaced (cljs/core.cljs at 6488:1)


 Comments   
Comment by Thomas Heller [ 30/Mar/17 4:56 PM ]

The patch re-uses the already defined :redef-in-file warning type which I think is close enough, however in the spirit of better errors a new warning type might be better?





[CLJS-1989] s/fdef expansion side effect fails when load cached source Created: 28/Mar/17  Updated: 28/Mar/17

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

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


 Description   

s/fdef has an expansion-time side effect that causes it to not operate properly if cached code is loaded.

To repro, have src/foo/core.cljs:

(ns foo.core
 (:require [clojure.spec :as s]))

(defn bar [x])

(s/fdef bar :args (s/cat :x number?))

Then:

$ java -cp cljs.jar:src clojure.main -m cljs.repl.nashorn
To quit, type: :cljs/quit
cljs.user=> (require '[clojure.spec.test :as st] 'foo.core)
true
cljs.user=> (st/instrument)
[foo.core/bar]
cljs.user=> :cljs/quit

Now this has been cached. If you exit and try again, (st/instrument) fails:

$ java -cp cljs.jar:src clojure.main -m cljs.repl.nashorn
To quit, type: :cljs/quit
cljs.user=> (require '[clojure.spec.test :as st] 'foo.core)
true
cljs.user=> (st/instrument)
[]


 Comments   
Comment by Thomas Heller [ 28/Mar/17 11:34 AM ]

s/def is also affected. It uses the cljs.spec/registry-ref atom which has a CLJ side (in cljs/spec.cljc) as well as a CLJS side (in cljs/spec.cljs). The CLJ is not populated when using the cache.





[CLJS-1988] add :npm-deps to recognized compiler options Created: 27/Mar/17  Updated: 27/Mar/17  Resolved: 27/Mar/17

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-1988.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 27/Mar/17 2:02 PM ]

fixed https://github.com/clojure/clojurescript/commit/296d0a69340e832b92ed742b3cd0304a06bea27f





[CLJS-1984] Fix one-argument arity implementation of cljs.closure/index-node-modules Created: 18/Mar/17  Updated: 24/Mar/17  Resolved: 24/Mar/17

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

Type: Defect Priority: Trivial
Reporter: Thomas Spellman Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bug, patch
Environment:

N/A


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

 Description   

cljs.closure/index-node-modules is a multimethod, and the 1-arity args are getting dropped in the pass to the 2-arity method causing it to loop until stack overflow. The attached patch fixes it in latest master (1.9.508).



 Comments   
Comment by David Nolen [ 24/Mar/17 12:20 PM ]

fixed https://github.com/clojure/clojurescript/commit/52ff7a2bdcaacf840f7aae72f4be4575297f7db1





[CLJS-1985] `index-node-modules` should pass opts to `node-inputs` Created: 18/Mar/17  Updated: 24/Mar/17  Resolved: 24/Mar/17

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

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

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

 Comments   
Comment by David Nolen [ 24/Mar/17 12:15 PM ]

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





[CLJS-1987] don't index node modules blindly Created: 21/Mar/17  Updated: 24/Mar/17  Resolved: 24/Mar/17

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-1987.patch    
Patch: Code

 Description   

We shouldn't call `cljs.closure/index-node-modules` if `npm-deps` hasn't been specified



 Comments   
Comment by David Nolen [ 24/Mar/17 12:14 PM ]

fixed https://github.com/clojure/clojurescript/commit/81c37b941fd7336ec620cfff1cfa0d2a5270d23b





[CLJS-1519] Collection invoke errors report arity off by 1 Created: 22/Dec/15  Updated: 24/Mar/17  Resolved: 24/Mar/17

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

Type: Defect Priority: Minor
Reporter: David Nolen Assignee: André Luís Anastácio
Resolution: Completed Votes: 0
Labels: newbie

Attachments: Text File 0001-CLS-1519-Collection-invoke-errors-report-arity-off-b.patch    
Patch: Code

 Description   

Runtime collection invokes will report arity that is off by one. This is because we use the generic function arity dispatching logic which doesn't account for the 1st self argument.



 Comments   
Comment by Mike Jackson [ 15/Apr/16 1:02 AM ]

Hey David,

Can I pick this one up? I'm a first time contributor and I wouldn't mind using this to get a lay of the land. I've already signed the Contributor Agreement.

Cheers

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

Mike, I've updated your permissions. Please assign the ticket to yourself. Thanks!

Comment by Mike Jackson [ 19/Apr/16 2:42 PM ]

Awesome, thanks. Looking forward to it.

Comment by André Luís Anastácio [ 05/Oct/16 10:32 PM ]

This issue are assigned to Mike a long time ago, maybe I can solve this.

David, sorry for the newbie question but I don't understand the issue. Do you have some example?

Comment by António Nuno Monteiro [ 06/Oct/16 7:34 AM ]

Here go a couple of examples:

cljs.user=> ({:a 1})
Error: Invalid arity: 1

cljs.user=> ({:a 1} :a :not-found :other)
Error: Invalid arity: 4

Notice how the arity is off by one? In the first example, we passed 0 args and in the 2nd example we passed 3 args.

Comment by David Nolen [ 24/Mar/17 12:14 PM ]

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





[CLJS-1830] sorted-map-by returns values for non-existing keys Created: 22/Oct/16  Updated: 24/Mar/17

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

Type: Defect Priority: Minor
Reporter: Eugene Pakhomov Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Oracle Java 1.8.0_91
Apache Maven 3.3.9



 Description   

Run the following in a REPL:

(def a (sorted-map-by > 1 :a 2 :b))
(get a "a")

Expected: nil or exception

Actual: :a



 Comments   
Comment by Erik Assum [ 23/Mar/17 11:42 AM ]

So, the type of a here is `PersistentTreeMap`
It defines `get` through `-lookup`, which in turn has the following code (around line 7679)

(-lookup [coll k not-found]
    (let [n (.entry-at coll k)]
      (if-not (nil? n)
        (.-val n)
        not-found)))

Calling `(.entry-at a "a")` gives
`[1 :a]`, and `(.-val [1 :a])` gives `:a`

So the bug is somewhere in

(entry-at [coll k]
    (loop [t tree]
      (if-not (nil? t)
        (let [c (comp k (.-key t))]
          (cond (zero? c) t
                (neg? c)  (recur (.-left t))
                :else     (recur (.-right t)))))))
Comment by António Nuno Monteiro [ 23/Mar/17 11:46 AM ]

The problem is the comparator. This actually produces an error in Clojure, but JS will accept comparing "a" to a number

Comment by Erik Assum [ 24/Mar/17 7:36 AM ]
(def c (cljs.core/fn->comparator <))
#'foo/c
foo=> (c 1 "a")
0
foo=> (< 1 "a")
      ⬆
WARNING: cljs.core/<, all arguments must be numbers, got [number string] instead. at line 1
false
foo=>

Jupp so the problem is using `<` as a comparator since it's happy comparing strings and ints.

So this issue could be closed as "working as intended"?





[CLJS-1539] Parallel compilation fails on circular dependencies Created: 06/Jan/16  Updated: 21/Mar/17  Resolved: 06/Jan/16

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

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


 Description   

Master test will not run due to the circular dependency between circular-deps.a and circular-deps.b test namespaces.



 Comments   
Comment by David Nolen [ 06/Jan/16 2:34 PM ]

We should probably just validate that the inputs do not include a circular dependency before starting parallel compilation.

Comment by David Nolen [ 06/Jan/16 4:15 PM ]

fixed https://github.com/clojure/clojurescript/commit/5724f72ad92d62b93cdf1afe19e4bbfc7b6ddecc

Comment by Maarten Truyens [ 20/Mar/17 5:30 AM ]

In version 1.9.494 (but also earlier versions, I tried up to 1.9.293), in my fairly large codebase of about 200 CLJC/CLJS namespaces, I have noticed that circular dependencies sometimes cause the compiler to simply idle after initial compilation efforts, without any error indication whatsoever. I then have to kill the compiler, disable parallel building, and restart it, in order to be notified about the actual circular dependency error. This happens both with (1) a clean and then cold recompile of a version of the codebase that happens to contain the error, and (2) during a Figwheel editing session where everything was fine until I happen to introduce the circular dependency. For clarity: in the former case, the compiler does start working during about 10 seconds, but then simply stops and idles (a full recompile takes about 40 seconds on my codebase).

I have tried recreating this error with another codebase, but was unable to do so, so it could be related to the size of the codebase. Do you have any idea where this could be coming from?

Comment by David Nolen [ 20/Mar/17 2:40 PM ]

So are you saying if you disable parallel compilation and you try to build it fails with a circular dependency error?

Comment by Maarten Truyens [ 21/Mar/17 3:07 AM ]

Correct: when I disable parallel compilation, the build will (rightfully) fail.





[CLJS-1986] Support for ES6 generators Created: 19/Mar/17  Updated: 20/Mar/17

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

Type: Enhancement Priority: Minor
Reporter: James Laver Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File generators.patch    
Patch: Code

 Description   

The attached patch adds support for ES6 generators (supported in node for a while now).

Generator functions can be declared through the :generator metadata that this patch adds support for. There is a new special token, `yield`.



 Comments   
Comment by António Nuno Monteiro [ 19/Mar/17 12:06 PM ]

I don't see how this patch is desirable. The ClojureScript compiler emits ES3 compatible code, which doesn't include generators.

In general, I think it's best to raise issues like this in the mailing list or the Clojurians slack before wasting time doing work that's not going to be accpeted.

Comment by James Laver [ 19/Mar/17 12:25 PM ]

Why is it that we emit ES3 compatible code in particular (I wasn't aware)? Google closure compiler has had support for compiling generators to ES3 for some time now https://github.com/google/closure-compiler/wiki/ECMAScript6

Comment by David Nolen [ 20/Mar/17 2:38 PM ]

I agree that this issues like this need some discussion first. Feel free to start one on the mailing list / Slack or IRC.





[CLJS-1964] Validate that `:target :nodejs` and no optimizations requires a `:main` option to be present Created: 01/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

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: newbie, nodejs

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

 Comments   
Comment by David Nolen [ 17/Mar/17 2:44 PM ]

fixed https://github.com/clojure/clojurescript/commit/197ff2e7c3f96b365e31cf4c1a4af39bdd60fc88





[CLJS-1956] Add missing JS reserved keywords Created: 27/Feb/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

Status: Resolved
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-1956.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 17/Mar/17 2:33 PM ]

fixed https://github.com/clojure/clojurescript/commit/2171ae9859a2e982497764a04de10916aae68307





[CLJS-1983] res -> mres in spec.cljs Created: 17/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

Status: Resolved
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-1983.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 17/Mar/17 2:26 PM ]

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





[CLJS-1976] hash-map assoc stackoverflow Created: 13/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

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

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

Using clojurescript master and a browser environment


Attachments: Text File CLJS-1976.patch    

 Description   

A particular combination of keys in a hash-map will cause a stackoverflow when added into the same hash-map, whether using transient or non-transient assoc.

Minimal case:

(defrecord T [index a b])

(def bad-key-1 (map->T {:index :eavt, :a 17592186192276, :b nil}))
(def bad-key-2 (map->T {:index :avet, :a 10, :b :fhir.ElementDefinition/minValueDateTime$cr}))

;; Implicit Transient assoc
(hash-map bad-key-1 nil bad-key-2 nil)

;RangeError: Maximum call stack size exceeded

;;; From a browser console:
;core.cljs:5034 Uncaught RangeError: Maximum call stack size exceeded
;cljs.core.PersistentVector.cljs$core$ISeqable$_seq$arity$1 @ core.cljs:5034
;cljs$core$seq @ core.cljs:1121
;cljs.core.concat.cljs$core$IFn$_invoke$arity$2 @ core.cljs:3619
;cljs.core.LazySeq.sval @ core.cljs:3269
;cljs.core.LazySeq.cljs$core$ISeqable$_seq$arity$1 @ core.cljs:3323
;cljs$core$seq @ core.cljs:1121
;cljs.core.pr_str.call.cljs.user.T.cljs$core$ISeqable$_seq$arity$1 @ VM2295:158
;cljs$core$seq @ core.cljs:1121
;cljs$core$first @ core.cljs:1143
;(anonymous) @ core.cljs:4049
;cljs$core$every_QMARK_ @ core.cljs:4049
;cljs$core$equiv_map @ core.cljs:5836
;(anonymous) @ VM2295:114
;cljs.core.pr_str.call.cljs.user.T.cljs$core$IEquiv$_equiv$arity$2 @ VM2295:118
;cljs$core$_equiv @ core.cljs:617
;cljs.core._EQ_.cljs$core$IFn$_invoke$arity$2 @ core.cljs:1179
;cljs$core$key_test @ core.cljs:6494
;cljs.core.BitmapIndexedNode.inode_assoc_BANG_ @ core.cljs:6752
;cljs.core.create_node.cljs$core$IFn$_invoke$arity$7 @ core.cljs:7050
;(anonymous) @ core.cljs:6760
;;; Last 3 lines repeat forever


;; Explicit non-transient assoc
(assoc (hash-map bad-key-1 nil) bad-key-2 nil)

;RangeError: Maximum call stack size exceeded
;;; Stack is similar to above, except `inode-assoc` instead of `inode-assoc!`
;;; is repeating, because this version is not transient

As near as I can tell, the fundamental problem is that the (zero? (bit-and bitmap bit)) test in inode-assoc is always false. I have a hunch this is due to some bit-twiddling difference between js and Java that isn't accounted for in bit-count or bitmap-indexed-node-index or the recursive call to inode-assoc. I am investigating further.



 Comments   
Comment by Francis Avila [ 13/Mar/17 6:13 PM ]

(Just to note: we encountered this issue in production.)

The fundamental problem is that JS hash values may use more than 32 bits, but only 32 bits should be considered.

These two records have different hash values, but if only 32 bits are compared they have the same hash value. At least create-node naively assumes that hash values are normalized and does normal comparison between them using ==, meaning it does not detect the hash collision correctly.

This is a problem for records because they use an older (pre-murmur) hash-imap, which is not careful to truncate to 32 bits.

However, it is also a problem for dates for the same reason:

(hash-map #inst "2017-03-13T22:21:08.666-00:00" nil  #inst "2015-11-02T19:53:15.706-00:00" nil)
;RangeError: Maximum call stack size exceeded

My proposed fix is to force all hash values to be normalized to 32 bits to preserve the invariant that two equal hash values means they collide.

Comment by David Nolen [ 17/Mar/17 2:24 PM ]

fixed https://github.com/clojure/clojurescript/commit/3449c5328356fb4951d1a950158b88e339818d0b





[CLJS-1977] defrecord should use murmur hashing like Clojure Created: 13/Mar/17  Updated: 17/Mar/17

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

Type: Enhancement Priority: Minor
Reporter: Francis Avila Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Due probably to an oversight, defrecord uses the older hash-imap method of hashing instead of the newer murmur hashing used by Clojure. Clojure does the equivalent of this:

(bit-xor (hash "full.class.name.of.Record") (hash-unordered-coll the-record))

This would also allow us to remove the internal functions hash-iset (which is already unused) and hash-imap (which is only used by records).






[CLJS-1973] Add support for `:npm-deps` in upstream `deps.cljs` Created: 11/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

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-1973.patch    
Patch: Code

 Comments   
Comment by Thomas Heller [ 12/Mar/17 4:19 AM ]

Wrote about this in Slack but I wanted to properly voice my concerns so they don't get lost in Slack archives.

I think managing npm via CLJS is a bad idea. While this is very interesting it could/should probably happen in a library. We will inherit all the woes npm brings and force this onto the user. What if the user prefers yarn? What if the user is using a tool with support for package.json but not deps.cljs?

I voiced similar concerns a while ago [1] and with everything happening recently with regards to JS modules the situation is getting worse. It may appear that this work must happen in CLJS but really could happen somewhere else without making cljs.core more complicated. clojure.core doesn't bundle with leiningen for good reason.

IMHO, YMMV

[1] https://groups.google.com/d/msg/clojurescript/xMQuEmQt7oQ/AWT5RZe_nQQJ

Comment by David Nolen [ 17/Mar/17 2:23 PM ]

fixed https://github.com/clojure/clojurescript/commit/21da03e03e229a0b38fb872485d26a30fbf034b8





[CLJS-1978] Port CLJ-2035 Created: 14/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

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: spec

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

 Description   

CLJ-2035 has made it into Clojure 1.9.0-alpha15



 Comments   
Comment by António Nuno Monteiro [ 14/Mar/17 12:40 PM ]

Attached patch with fix and tests.

Comment by David Nolen [ 17/Mar/17 1:54 PM ]

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





[CLJS-1979] Port CLJ-2043 (fix s/form of s/conformer) Created: 14/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

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-1979.patch    
Patch: Code

 Description   

this is in clojure 1.9.0-alpha15



 Comments   
Comment by David Nolen [ 17/Mar/17 1:50 PM ]

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





[CLJS-1980] port CLJ-2100 (s/nilable form should retain original spec form) Created: 14/Mar/17  Updated: 17/Mar/17  Resolved: 17/Mar/17

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

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

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

 Comments   
Comment by David Nolen [ 17/Mar/17 1:47 PM ]

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





[CLJS-1982] Backtick of a quoted namespace should not change it Created: 16/Mar/17  Updated: 16/Mar/17

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

Type: Defect Priority: Minor
Reporter: Andrea Richiardi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Little inconsistence with Clojure here:

boot.user=> `'my-namespace.test-runner
(quote my-namespace.test-runner)

while in lumo, planck and replumb:

cljs.user=> `(require 'my-namespace.test-runner)
(cljs.core/require (quote my-namespace/test-runner))

this happens in a normal repl as well. Some other examples:

cljs.user=> `'my-namespace.test-runner
(quote my-namespace/test-runner)
cljs.user=> `'my-namespace.test-runner.ars
(quote my-namespace/test-runner.ars) ;; second not changed





[CLJS-1975] Perf: Compare f with nil in Delay impl Created: 11/Mar/17  Updated: 11/Mar/17

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

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: performance

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

 Description   

When a Delay has been realized, f is set to nil. We can avoid truth_ and not calls and directly compare with nil for a minor perf boost.

In script/noderepljs, this leads to these

(simple-benchmark [x (delay 1)] @x 1e9)
(simple-benchmark [x (delay 1)] (realized? x) 1e9)
(simple-benchmark [x (doto (delay 1) deref)] (realized? x) 1e9)

speeding up by 6%, 11% and 9%, respectively.






[CLJS-1974] Remove cljs.core/fixture1 and fixture2 Created: 11/Mar/17  Updated: 11/Mar/17

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

Type: Enhancement Priority: Trivial
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

There are a couple of vars in cljs.core named fixture1 and fixture2 that appear to perhaps be leftovers from when tests were assertions included in the cljs.core namespace.

https://github.com/clojure/clojurescript/commit/43861f7bc0b7b4fb534167b0773e49ccb68e6b1e#diff-a98a037c6c098dd3707e861df3c2f5acR1893

These can probably be safely removed.






[CLJS-1970] Cannot infer target type for list/vector expressions Created: 08/Mar/17  Updated: 10/Mar/17

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

Type: Defect Priority: Minor
Reporter: Daniel Janus Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 16.04.2, Oracle JRE 8



 Description   

With

(set! *warn-on-infer* true)
enabled, attempting to compile functions like:

(defn foo [] (list))
(defn bar [] (vector))

results in a warning:

WARNING: Cannot infer target type in expression (. cljs.core/List -EMPTY) at line 2427 src/cljs/discann/core.cljs

WARNING: Cannot infer target type in expression (. cljs.core/PersistentVector -EMPTY) at line 2435 src/cljs/discann/core.cljs

The line number reported is totally unrelated to the line of code where the problematic fn appears.

Affects 1.9.456 and 1.9.494.






[CLJS-1953] JSC_PARSE_ERROR during prod compilation after update clojurescript to version 1.9.494 from 1.9.229. Created: 25/Feb/17  Updated: 10/Mar/17  Resolved: 10/Mar/17

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

Type: Defect Priority: Critical
Reporter: Pavel Kopychenko Assignee: Unassigned
Resolution: Duplicate Votes: 2
Labels: bug, compiler
Environment:

GNU/Linux Debian 8 x64, java version "1.8.0_121", , clojure 1.8, clojurescript 1.9.494, Leiningen 2.7.1, lein-cljsbuild "1.1.5", core.async "0.3.441"



 Description   

I have a next error when I try to compile my project as prod after update clojurescript to last release version 1.9.494 from 1.9.229 :

Compiling "resources/public/js/c/camerton/testor/main.js" from ["src-cljc" "src-cljs-common" "src-cljs-testor"]...
Feb 25, 2017 3:40:05 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /home/maker/git/camerton/target/cljsbuild-compiler-3/cljs/core/async.js:1426: ERROR - Parse error. No newline allowed before '=>'
var inst_56769 = async(inst_56768);
                                  ^

Feb 25, 2017 3:40:05 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 1 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. No newline allowed before '=>' at /home/maker/git/camerton/target/cljsbuild-compiler-3/cljs/core/async.js line 1426 : 34


 Comments   
Comment by Antonin Hildebrand [ 25/Feb/17 4:39 PM ]

Ah, sorry. I searched for "async" in existing JIRA tickets and didn't get this one. So I created a new one here CLJS-1954.





[CLJS-1957] Process JS modules errors and warnings don't get printed Created: 27/Feb/17  Updated: 10/Mar/17  Resolved: 10/Mar/17

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-1957.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 10/Mar/17 1:36 PM ]

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





[CLJS-1448] lib-rel-path fails on Windows because of File/separator being \\ Created: 14/Sep/15  Updated: 10/Mar/17  Resolved: 10/Mar/17

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

Type: Defect Priority: Minor
Reporter: Orlando William Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: bug, newbie
Environment:

Windows



 Description   

https://github.com/clojure/clojurescript/blob/cc953d4be7b4a256fd5eae783f9106a2929a4126/src/main/clojure/cljs/closure.clj#L1210

That code calls replace with \ on windows, who ends up calling (.replaceAll "foo.js" "." "\") and fails with
IllegalArgumentException character to be escaped is missing java.util.regex.Matcher.appendReplacement (:-1)



 Comments   
Comment by Orlando William [ 14/Sep/15 1:20 PM ]

I can't find a way to edit the description, I meant \ followed by \ but somehow it got a line break

Comment by David Nolen [ 12/Feb/16 4:12 PM ]

A patch for this is welcome.

Comment by Shaun Mahood [ 10/Mar/17 1:27 PM ]

Looks like a duplicate of CLJS-1868

Comment by David Nolen [ 10/Mar/17 1:29 PM ]

Marked as duplicate unless we get a reproducer





[CLJS-1868] CLJS compilation error with Closure lib dependency on Windows Created: 11/Dec/16  Updated: 10/Mar/17  Resolved: 10/Mar/17

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

Type: Defect Priority: Minor
Reporter: Dejan Josifovic Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug, cljs, compiler
Environment:

Tested on Windows 10 with java 8 and on windows 7 with java 7 and java 8.
Clojure version is 1.8.0 on both systems.


Attachments: Text File CLJS-1868.patch     Text File CLJS-1868.patch     Text File stacktrace.txt    

 Description   

I encountered this error while developing a cljs project that included openlayers lib in its deps.
Open layers is a Closure library and I used the latest version 3.15.1.

The error that compiler reports is:
java.io.IOException: The filename, directory name, or volume label syntax is incorrect

I have recreated the minimal scenario, the one like on ClojureScript Quick start guide.
Steps to reproduce the problem (basically like the quick start):

  • Download standalone cljs jar from the link in the guide
  • Create the same build.cljs file as defined on the guide
  • Download openlayers-3.15.1.jar and place it in the root
  • Add require statement in core.cljs - (ns hello-world.core (:require ol.Map)) for example
  • Than in cmd run java -cp "cljs.jar;openlayers-3.15.1.jar;src" clojure.main build.clj

I have also tested with cljs master branch (created an uberjar and tested again) and i get the same error.

Attached is the example stacktrace (in that run I added :verbose true to get the 'Copying...' output).



 Comments   
Comment by Dejan Josifovic [ 11/Dec/16 8:06 AM ]

I have also created a git hub repo for this problem: https://github.com/28/openlayers-cljs-compile-error-repo

Comment by Gijs Stuurman [ 12/Dec/16 4:22 AM ]

This issue is present on all OS's, but breaks on Windows. I see it on Ubuntu.

The logic that already exists to shorten filenames for files from jars is not applied for the library in the openlayer.jar.

In verbose mode there is this output:

Copying jar:file:/path/openlayers/openlayers-cljs-compile-error-repo/openlayers-3.15.1.jar!/cljsjs/openlayers/development/ol/events/event.js to out/file:/path/openlayers/openlayers-cljs-compile-error-repo/openlayers-3.15.1.jar!/cljsjs/openlayers/development/ol/events/event.js

The file that gets written into the "out" directory contains a colon (:) and an exclamation point (!) in the path (at the "file:" and "jar!"). On Windows this is a Java IO Exception, because colons are not allowed in file names or paths.

The generated "main.js" file contains:

goog.addDependency("../file:/path/openlayers/openlayers-cljs-compile-error-repo/openlayers-3.15.1.jar!/cljsjs/openlayers/development/ol/events/event.js", ['ol.events.Event'], []);

The "openlayers" jar is a Google Closure compatible JavaScript library in a jar. All its files have a "goog.provides" and "goog.require"'s and the jar contains a "deps.cljs" with the keys :libs and :externs.

The following monkey patch in "build.clj" makes paths without "file:" or "jar!" in them:

(alter-var-root #'cljs.closure/rel-output-path
                (fn [orig-fn]
                  (fn [js & args]
                    (apply orig-fn (dissoc js :closure-lib) args))))

For comparison, the verbose output for the files generated for files from cljs.jar:

Copying jar:file:/path/openlayers/openlayers-cljs-compile-error-repo/cljs.jar!/goog/base.js to out/goog/base.js
Comment by David Nolen [ 12/Dec/16 9:25 AM ]

Gijs thanks for the additional information. Very helpful, will take a look.

Comment by David Nolen [ 16/Dec/16 2:02 PM ]

The suggested fix isn't desirable as far as I can tell since we have a branch specifically for dealing with Closure libs that will be avoided. We need a better explanation.

Comment by Dejan Josifovic [ 03/Feb/17 6:54 AM ]

Hi all,

the problem occurred only for Closure libraries compilation (such as openlayers).
As already commented, it manifested on both Win and Linux, but on Linux it did not
cause problems.

The problem was in the function that produced relative output paths for deps (lib-rel-path).
It tried to remove the first part of the absolute path with clojure.string/replace, but
it tried it with a wrong match (it did not reproduce the actual first part of the path)
so it effectively did nothing.

Example:
(str (io/file (System/getProperty "user.dir") lib-path) File/separator)
produced
file:\C:\Users&#42;***\Documents\Projects\openlayers-cljs-compile-error-repo\cljsjs\openlayers\development\
instead of
file:\C:\Users&#42;***\Documents\Projects\openlayers-cljs-compile-error-repo\openlayers-3.15.1.jar!\cljsjs\openlayers\development\

Attached patch produces better paths that work on both OS.
Can someone check if it is an okay solution?
I have tested it of course on both OS, run CLJS tests etc.

Thanks,
Dejan.

Comment by Dejan Josifovic [ 03/Feb/17 8:23 AM ]

This is the correct patch - first one contained an error.

Comment by Shaun Mahood [ 01/Mar/17 4:17 PM ]

I've tested the newest patch on Windows 10/Java 8 and Mac OSX 10.11.6/Java 8, using the quickstart compile method with both :none and :advanced.
It fixes the compilation issue on Windows and will compile both openlayers and libphonenumber (both are Google Closure libraries, I used the JAR files from CLJSJS to compile them). The folder structure also looks much better and doesn't have the user path embedded anymore.

Comment by David Nolen [ 10/Mar/17 1:28 PM ]

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





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

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

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

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



 Description   

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

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

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

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

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



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

Looks like a duplicate of CLJS-1868





[CLJS-1967] Missing ^boolean annotation for removed-leaf? in TransientHashMap Created: 07/Mar/17  Updated: 10/Mar/17  Resolved: 10/Mar/17

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

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

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

 Description   

The `removed-leaf?` is a boxed boolean and can be annotated.



 Comments   
Comment by Thomas Mulvaney [ 07/Mar/17 9:18 AM ]

Attached patch uses the provided `val` field of the `Box` type rather than setting a new field.

Comment by David Nolen [ 10/Mar/17 1:20 PM ]

fixed https://github.com/clojure/clojurescript/commit/62337d018bf9902fe8943289b9d7f3bf5c698bff





[CLJS-1960] Require CommonJS modules directly from a ClojureScript namespace Created: 27/Feb/17  Updated: 10/Mar/17  Resolved: 10/Mar/17

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: 3
Labels: None

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

 Comments   
Comment by Andrea Richiardi [ 27/Feb/17 11:34 PM ]

I will comment again after I'll try the patch, but this is very good stuff. One thing I was pondering about is the name of the option. It could be more generic, for instance :js-deps, so that we kind of abstract from the package manager. I know I know everybody knows what npm is...Anyways, my two cents.

Comment by Andrea Richiardi [ 01/Mar/17 5:09 PM ]

Ok I tried the new patch and I detected that it basically throws (sorry it is a bit verbose):

Error: Cannot find module '/home/arichiardi/git/rest-resources-viz/home/arichiardi/.boot/cache/tmp/glu/-d8mh6z/main.out/cljs$node_modules.js' from '/home/arichiardi/git/rest-resources-viz'

But it looks like the file is there, and if I escape the $ with a \$, the file can be read

Comment by David Nolen [ 10/Mar/17 1:09 PM ]

fixed https://github.com/clojure/clojurescript/commit/777d41b9b6fe83c3d29fc51ee3ddbdfeff4f803b





[CLJS-1968] Enable calling JS modules that export a single function Created: 07/Mar/17  Updated: 10/Mar/17  Resolved: 10/Mar/17

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-1968.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 10/Mar/17 12:53 PM ]

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





[CLJS-1972] cljs.nodejs/enable-util-print! identical to enable-console-print Created: 10/Mar/17  Updated: 10/Mar/17

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

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


 Description   

cljs.nodejs/enable-util-print! is identical to the cljs.core/enable-console-print! and should probably rather re-use than having duplicate code.






[CLJS-1971] Typos in docstring of require macro Created: 08/Mar/17  Updated: 08/Mar/17

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

Type: Defect Priority: Trivial
Reporter: OHTA Shogo Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: docstring

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

 Description   

The example code in the docstring looks not right:

cljs.user=> (doc require)
-------------------------
cljs.core/require
([& args])

...

Example:

  The following would load the library clojure.string :as string.

  (require '[clojure/string :as string])
nil
cljs.user=>





[CLJS-1969] Docstring for condp indicates IllegalArgumentException Created: 07/Mar/17  Updated: 07/Mar/17

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

Type: Defect Priority: Trivial
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: docstring

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

 Description   

The docstring for condp indicates IllegalArgumentException is thrown. Instead it should indicate Error (as does case's docstring, for example.)






[CLJS-1966] cljs.test assumes the output directory is '/out/' when determining the filename for a failed or errored test result. Created: 06/Mar/17  Updated: 06/Mar/17

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

Type: Defect Priority: Minor
Reporter: Creighton Kirkendall Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If your output directory is does not contain '/out/' in the path the code for getting the filename on failure for test results will return nonsense.

You can see here where we we make the assumption that '/out/' is used.
https://github.com/clojure/clojurescript/blob/2f8a1529955acc943ac8082ab5848b2cba54bc4d/src/main/cljs/cljs/test.cljs#L379






[CLJS-705] locals clearing Created: 27/Nov/13  Updated: 06/Mar/17  Resolved: 05/Jan/16

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

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


 Description   

Without locals clearing ClojureScript is likely to suffer from the same cases as Clojure did for common uses of lazy sequences.



 Comments   
Comment by David Nolen [ 29/Nov/13 3:03 PM ]

For this we'll need to introduce some special private way to set a local to nil, i.e. (_clear_local sym)

Comment by David Nolen [ 05/Jan/16 4:37 PM ]

More effort than it's worth, few people have reported issues with head-holding.

Comment by Marcin Kulik [ 06/Mar/17 5:35 AM ]

Would you reconsider it given people now use Planck and Lumo for scripting? Lack of locals clearing prevents any non-trivial stream processing with ClojureScript in CLI.





[CLJS-1965] letfn collisions across namespaces Created: 02/Mar/17  Updated: 02/Mar/17

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

Type: Defect Priority: Minor
Reporter: Jeremy R Sellars Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Affects 1.9.495 and earlier. Probably only affects browsers (not nodejs).


Attachments: Text File cljs-1965_wrap_letfn_statements.patch    

 Description   

If you `letfn` a fn with the same name in two namespaces, the wrong fn is used.

one.cljs
(ns hello-world.one)

(letfn [(answer [] "1")]
  (defn get-answer []
    (answer)))
two.cljs
(ns hello-world.two)

(letfn [(answer [] "2")]
  (defn get-answer []
    (answer)))
core.cljs
(ns hello-world.core
  (:require [hello-world.one]
            [hello-world.two]))

(println "one =>" (hello-world.one/get-answer))  ; one => 1
(println "two =>" (hello-world.two/get-answer))  ; two => 1      WHAT?!?

This issue seems to exist both on top-level `letfn`s and non-top-level `(let [] (letfn [...]))`.



 Comments   
Comment by Jeremy R Sellars [ 02/Mar/17 4:21 PM ]

This patch wraps `letfn` :expr and :statement forms in a function declaration (formerly, only :expr forms were wrapped).

I only did minimal testing. It fixes the code from the description.

Note: This is my first crack at the compiler and it is entirely possible I have not understood the entire problem.





[CLJS-1963] cljs.analyzer/load-core is called for every analyzed form Created: 01/Mar/17  Updated: 01/Mar/17

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   

In cljs.analyzer/analyze-form the load-core fn is called. load-core guards against doing its work multiple times. It then always calls (intern-macros 'cljs.core), which also checks whether it was called before. This ends up doing the checks very often. load-core should probably be called in a less frequent manner.

Performance impact is very minimal but I did a quick test in my work project and load-core is called 416671 times there (without cache) when 1 would be enough.






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

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

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

Quick start guild



 Description   

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






[CLJS-1961] Regression in :advanced output Created: 28/Feb/17  Updated: 28/Feb/17  Resolved: 28/Feb/17

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

Type: Defect Priority: Major
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: None


 Description   

I wanted to upgrade my work project to any release after 1.9.293, but it started showing weird errors when running the compiled JS in the browser.

I ran git bisect and identified the bad commit [1].

git bisect bad
de05b15568c848a1d4f80a44bdffd486abd05150 is the first bad commit
commit de05b15568c848a1d4f80a44bdffd486abd05150
Author: António Nuno Monteiro <anmonteiro@gmail.com>
Date:   Mon Nov 7 12:07:32 2016 +0100

    CLJS-1768: cljs.spec perf tweaks

    This patch implements the changes in the following commits:

    https://github.com/clojure/clojure/commit/de6a2b528a18bcb4768e82d0d707d2cab26268a6
    https://github.com/clojure/clojure/commit/defa7b8ef268ea2b8772658ade2010ca5ad00dc4
    https://github.com/clojure/clojure/commit/021a3adf131d3f4158acd9e5d08ca91eb36ab56d
    https://github.com/clojure/clojure/commit/9fa85c6a908c9a3e89b4c0c449c49887a4c35248

:040000 040000 f8eee4c6e8289c5ec539c478e67c48d0de485f84 f261f856c8492bd4880be536186ccc8ad3fe3557 M    src

The error is very confusing as it happens at a point in the code where spec isn't even involved. When running the :advanced build with :pseudo-names the bug disappears as well making this very hard to track down. I think I have ruled out all other factors and the only thing that changes is this commit. Must be something that confuses the Closure Compiler.

This works: git reset --hard de05b15568c848a1d4f80a44bdffd486abd05150~1
This does not: git reset --hard de05b15568c848a1d4f80a44bdffd486abd05150

https://github.com/clojure/clojurescript/commit/de05b15568c848a1d4f80a44bdffd486abd05150



 Comments   
Comment by Thomas Heller [ 28/Feb/17 5:08 AM ]

Well, externs should have been my first guess.

In this case I accidentally removed externs for Google Analytics which is just one global var "ga". Which replaced whatever the Closure compiler generated for that leading me down a completely wrong path trying to track this down.

Sorry for the noise (again).





[CLJS-1959] under :nodejs target we should provide __dirname and __filename constants Created: 27/Feb/17  Updated: 27/Feb/17

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

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





[CLJS-1958] Macro :arglists include &form and &env Created: 27/Feb/17  Updated: 27/Feb/17

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

Type: Defect Priority: Trivial
Reporter: Andrea Richiardi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Minor issue, but nice to fix especially because of tooling. In lumo:

cljs.user=> (:arglists (get-in @lumo.repl/st [:cljs.analyzer/namespaces 'cljs.core$macros :defs 'when]))
([&form &env test & body])

I would like to filter out the first two arguments that are of course not needed.
A simple patch is here.

I can provide a patch once I figure out where is the right place to apply it. Of course if I am not doing it wrong.

Thanks!



 Comments   
Comment by Andrea Richiardi [ 27/Feb/17 12:26 PM ]

On second thought, if we put this filter in `load-analysis-cache!`, probably we will pay to much of a price for just a display/ide problem. The best thing I can think of is to filter the transit/json file before loading. So probably this is better to be inside `lumo`.

Comment by Andrea Richiardi [ 27/Feb/17 12:44 PM ]

After conversation with António Nuno Monteiro: this inconsistency might be solved with CLJS-1461 so this one here can be closed I guess.





[CLJS-1955] data_readers.cljc can't reference handlers in user code Created: 27/Feb/17  Updated: 27/Feb/17

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

Type: Defect Priority: Major
Reporter: Dustin Getz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: compiler
Environment:

clojurescript 1.9.456-493



 Description   

data_readers.cljc:

{a/UserIdentity foo.core/user-identity}
(ns foo.core)
(defn user-identity [i] i)
(assert (= 1 #a/UserIdentity 1))

`CompilerException java.lang.IllegalStateException: Attempting to call unbound fn: #'foo.core/user-identity

Using a #' in data_readers.cljc results in a different error:
`java.lang.ClassCastException: clojure.lang.Cons cannot be cast to clojure.lang.Named`






[CLJS-1948] Possible race condition in compiler w/ parallel-build true Created: 21/Feb/17  Updated: 25/Feb/17  Resolved: 24/Feb/17

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

Type: Defect Priority: Minor
Reporter: Nikita Prokopov Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Zip Archive datascript_compiler_race.zip    

 Description   

I'm seeing errors trying to compile DataScript on 1.9.473. Judging from output, it looks like a race error in ClojureScript compiler: output JS files are damaged, removing parallel-build true fixes the problem.

Due to the nature of error, it might not be 100% reproducible. I get it 100% times on my machine though, but reported syntax errors in JS are always different.

The problem was probably introduced in 1.9.229. I'm not getting any errors compiling DataScript in earlier versions (1.9.227 and before)

HOW TO REPRODUCE:

unzip datascript_compiler_race.zip
cd datascript_compiler_race
wget https://github.com/clojure/clojurescript/releases/download/r1.9.473/cljs.jar
rm -rf target && java -cp cljs.jar:src clojure.main build.clj

As this is a race condition, it might not reproduce perfectly every time.

Examples of what I get on my MacBook Pro Retina Mid 2012 (Core i7-3615QM, 4 cores):

[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj
WARNING: parse-binding at line 215 is being replaced at line 215 src/datascript/parser.cljc
WARNING: collect-vars-acc at line 470 is being replaced at line 470 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
Feb 21, 2017 1:07:13 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/target/datascript/parser.js:140: ERROR - Parse error. Semi-colon expected
datascript.parser.collect.cljsdatascript.parser.collect.cljs$lang$mavar G__16546 = cljs.datascript.parser.collvar seq16545__$1 = cljs.core.next(seq16545);
                                                                        ^

Feb 21, 2017 1:07:13 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/target/datascript/parser.js:1676: ERROR - Parse error. IE8 (and below) will parse trailing commas in array and object literals incorrectly. If you are targeting newer versions of JS, set the appropriate language_in option.
return faif(cljs.coredatascript.parser.RuleVars.prototype.cljs$core$IMap$_dissoc$arity$2 = (function (this__7667__auto__,k__7668return ((this__7654__auto____$1.constructor === other__7655__autoif(cljs.core.contains_QMARK_(new cljs.core.PersistentHashSet(null, new cljs.core.PersistentArrayMap(null, 2, [cljs.core.cst$kw$free,return true;
                                                                                                                                                                                                                                                                                                                                    ^

Feb 21, 2017 1:07:13 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 2 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. Semi-colon expected at /Users/prokopov/datascript_compiler_race/target/datascript/parser.js line 140 : 72
ERROR: JSC_TRAILING_COMMA. Parse error. IE8 (and below) will parse trailing commas in array and object literals incorrectly. If you are targeting newer versions of JS, set the appropriate language_in option. at /Users/prokopov/datascript_compiler_race/target/datascript/parser.js line 1676 : 324
[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj
WARNING: parse-binding at line 215 is being replaced at line 215 src/datascript/parser.cljc
WARNING: parse-clause at line 598 is being replaced at line 598 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
WARNING: parse-clauses at line 611 is being replaced at line 611 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
Feb 21, 2017 1:05:50 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/target/datascript/parser.js:458: ERROR - Parse error. Semi-colon expected
datasreturn cljs.core.pr_sequential_writer(writer__7673__auto__,pr_pair__7675__auto__,"#datascript.parser.Variable{",", ","}",opts__7674__auto__,cljs.core.concat.cljs$core$IFn$_invoke$arity$2(new cljs.core.PersistentVector(null, 1, 5return (new cljs.core.RecordIter((0),G__16721__$1,1,new cljs.core.PersistentVector(null, 1, 5, cljs.core.PersistentVector.EMPTY_NODE, [cljs.core.cst$kw$symbol], null),(cljs.core.truth_(self__.__extmap)?cljs.core._iterator(self__.__extmap):cljs.core.nil_iter())));
            ^

Feb 21, 2017 1:05:50 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/target/datascript/parser.js:4080: ERROR - Parse error. IE8 (and below) will parse trailing commas in array and object literals incorrectly. If you are targeting newer versions of JS, set the appropriate language_in option.
throw cljs.core.ex_info.cljs$core$IFn$_invoke$arity$2([cljs.core.str.cljs$cothrow cljs.core.ex_info.cljs$core$IFn$_invoke$arity$2([cljs.core.str.cljs$core$IFn$_invoke$arity$1("Cannot parse pull expression, expect ['pull' src-var? variable (constant | variable | plain-symbol)]")].join(''),new cljs.core.PersistentArrayMap(null, 2, [cljs.core.cst$kw$error,}
                                                                                                                                                                                                                                                                                                                                                                  ^

Feb 21, 2017 1:05:50 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 2 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. Semi-colon expected at /Users/prokopov/datascript_compiler_race/target/datascript/parser.js line 458 : 12
ERROR: JSC_TRAILING_COMMA. Parse error. IE8 (and below) will parse trailing commas in array and object literals incorrectly. If you are targeting newer versions of JS, set the appropriate language_in option. at /Users/prokopov/datascript_compiler_race/target/datascript/parser.js line 4080 : 354
[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj
WARNING: parse-binding at line 215 is being replaced at line 215 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
Feb 21, 2017 1:02:55 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/target/datascript/parser.js:4507: ERROR - Parse error. ',' expected
throw cljs.core.ex_info.cljs$core$IFn$_invoke$arity$2([cljs.core.str.cljs$core$IFn$_invoke$arity$1("Cannot parse :find, expected: (find-rel | find-coll | find-tuple | find-scalar)")].join(''),new cljs.core.PersistentArrayMap(null, 2, [cljs.core.cst$kw$error,cljs.core.cst$kw$parser_SLASH_find,cljs.core.cst$kw$fragment,forvar or__6983__}
                                                                                                                                                                                                                                                                                                                                      ^

Feb 21, 2017 1:02:55 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 1 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. ',' expected at /Users/prokopov/datascript_compiler_race/target/datascript/parser.js line 4507 : 326
[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj
WARNING: collect-vars-acc at line 470 is being replaced at line 470 src/datascript/parser.cljc
WARNING: parse-clause at line 598 is being replaced at line 598 src/datascript/parser.cljc
WARNING: parse-clauses at line 611 is being replaced at line 611 src/datascript/parser.cljc
Feb 21, 2017 1:02:00 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/target/datascript/parser.js:227: ERROR - Parse error. ',' expected
this.datascript.parser.Placeholder.prototype.cljs$core$ILookup$_lookup$arity$2 = (function (this__7658_this.cljs$lang$protocol_mask$partition1$ = 81var thidatascript.parser.Placeholdereturn this__7658__auto____$1.cljs$core$ILookup$_lookup$arity$3(null,k__7659__auto__,null);
                                                                                                           ^

Feb 21, 2017 1:02:00 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 1 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. ',' expected at /Users/prokopov/datascript_compiler_race/target/datascript/parser.js line 227 : 107
[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj
WARNING: parse-binding at line 215 is being replaced at line 215 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
Feb 21, 2017 1:00:46 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/out/datascript/parser.js:215: ERROR - Parse error. Character '@' (U+0040) is not a valid identifier start char
datascript.parser.Placeholder = (functio * @implements {cljs.core.IAthis.__meta  * @implemthis.__extmap = __extm * @this.__hash = __hash;
                                           ^

Feb 21, 2017 1:00:46 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 1 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. Character '@' (U+0040) is not a valid identifier start char at /Users/prokopov/datascript_compiler_race/out/datascript/parser.js line 215 : 43
[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj
WARNING: collect-vars-acc at line 470 is being replaced at line 470 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
WARNING: parse-clause at line 598 is being replaced at line 598 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
WARNING: parse-clauses at line 611 is being replaced at line 611 /Users/prokopov/datascript_compiler_race/src/datascript/parser.cljc
Feb 21, 2017 12:59:33 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /Users/prokopov/datascript_compiler_race/out/datascript/parser.js:7639: ERROR - Parse error. '}' expected

Feb 21, 2017 12:59:33 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 1 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. '}' expected at /Users/prokopov/datascript_compiler_race/out/datascript/parser.js line 7639 : 0

Note how output JS is not even syntactically correct:

functio * @implements
__meta  * @implemthis.__extmap
,forvar or__6983__}

This is a clear sign that two or more threads are writing to the same file without coordination.

Also note that with parallel build enabled, compiler confuses declare with function defenition and warns about collect-vars-acc at line 470 is being replaced at line 470. In fact, the function is first decalre-d, then defn-ed just once in the same file, which, under normal circumstances, should not trigger any warnings.

Also note that setting :parallel-build false leads to 100% stable, error-less builds:

[~/datascript_compiler_race] rm -rf target && java -cp cljs.jar:src clojure.main build.clj --no-parallel
[~/datascript_compiler_race]


 Comments   
Comment by David Nolen [ 22/Feb/17 6:50 AM ]

This issue needs work before it will be considered. Do not link outside to minimal cases, you need to provide all the information in the ticket.

Comment by Nikita Prokopov [ 22/Feb/17 7:12 AM ]

David, thanks for the heads up! I’ve updated the issue with standalone zip containing test case and instructions on how to build it. Unfortunately I cannot include cljs.jar in it because it’s too big (24 Mb, while JIRA only allows for 10 Mb attachments max). But I’m sure you have one somewhere on your machine

Comment by David Nolen [ 24/Feb/17 1:38 PM ]

The issue appears to be that somehow duplicate inputs are present, that is

datascript/pull_parser.cljc
will get compiled twice.

Comment by David Nolen [ 24/Feb/17 2:06 PM ]

fixed https://github.com/clojure/clojurescript/commit/04541fbf8ec573d26bac4e4e61e69cb4c64a3dd7

Comment by Nikita Prokopov [ 25/Feb/17 2:35 AM ]

Is it because of how cljc is handled? I don’t see duplicate file names in that repo

Comment by Nikita Prokopov [ 25/Feb/17 2:44 AM ]

BTW confirm that 1.9.494 fixes my issue. Thanks a lot!

Comment by Pavel Kopychenko [ 25/Feb/17 3:59 AM ]

Hi all!! I'm sorry! I have simular error when I try to compile production after update clojurescript to version 1.9.494 from 1.9.229.

Compiling "resources/public/js/c/camerton/testor/main.js" from ["src-cljc" "src-cljs-common" "src-cljs-testor"]...
Feb 25, 2017 3:40:05 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: /home/maker/git/camerton/target/cljsbuild-compiler-3/cljs/core/async.js:1426: ERROR - Parse error. No newline allowed before '=>'
var inst_56769 = async(inst_56768);
                                  ^

Feb 25, 2017 3:40:05 PM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 1 error(s), 0 warning(s)
ERROR: JSC_PARSE_ERROR. Parse error. No newline allowed before '=>' at /home/maker/git/camerton/target/cljsbuild-compiler-3/cljs/core/async.js line 1426 : 34
Comment by António Nuno Monteiro [ 25/Feb/17 10:48 AM ]

@nikita not related to cljc files in particular, just the way we sort dependencies could make us end up with duplicate entries. We now calculate `distinct` by keying on the namespace that the entry provides.

@pavel that's not related to this issue, but I'm also seeing it. Please open a new ticket. It's most likely related to the Closure Compiler upgrade.





[CLJS-1921] Certain files are compiled twice, leading to "Can't redefine a constant ..." errors Created: 30/Jan/17  Updated: 24/Feb/17

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

Type: Defect Priority: Minor
Reporter: Viktor Magyari Assignee: Viktor Magyari
Resolution: Unresolved Votes: 0
Labels: compiler
Environment:

windows, linux



 Description   

Repro:

Create a folder with the following files:

cljs.jar (the quick start uberjar)
src
  foo.cljc
  core.cljc

The contents shall be:

;; foo.cljc
(ns foo)

(def ^:const a 10)

;; core.cljc
(ns core
  (:require [foo]))

(def ^:const a 10)

In this folder, call java -cp src;cljs.jar clojure.main. In the repl, enter:

(require '[cljs.build.api :refer [build]])
(build "src" {:output-to "out/main.js" :output-dir "out" :verbose true})

If some conditions are met (see [1] and the explanations below), you'll see the compilation fail with "Can't redefine a constant at <...>".

NOTE: the easiest way to reproduce is to sort the value returned by cljs.closure/add-dependency-sources by a function of our choosing, (comp first :provides) for example. This can ensure that the last element will be a dependency which appears twice (see explanations below). However, in this case we have to use a hand-crafted classpath, which includes our patched clojurescript jar (+ its dependencies, + the src folder).

Cause:

NOTE: My understanding of the compiler internals (cljs.js-deps and cljs.closure in particular) is very superficial, but those familiar with it can probably follow along.

The journey starts at cljs.closure/add-dependency-sources, invoked in cljs.closure/build. The function takes some dependencies, converts them to a set, and adds some dependencies to it. Things to note here:

  • the :file entry in each dependency is nil [0]
  • the order of (seq (set inputs)) is "random" (or unspecified rather) [1]
  • the :source-file entry in each dependency is a java.io.File instance
  • the :source-file entry in each additional dependency from cljs.closure/find-cljs-dependencies is a java.net.URL instance
  • there are some dependencies (in the repro case at least) which were in inputs and were added as well with cljs.closure/find-cljs-dependencies (so they appear twice in the list)

The fact that some dependencies are java.io.File, some are java.net.URL instances may be the reason why some items appear multiple times in the set, but I haven't confirmed this.

Next, the computed dependencies are fed into cljs.js-deps/dependency-order, where they are passed to cljs.js-deps/build-index. This function reduces over each dependency (OUTER reduce), and reduces over each provided namespace (:provides entry, INNER reduce).

Here's the crucial part: the INNER reduce associates each namespace in :provides with the dependency, and the OUTER reduce then associates the :file entry with the dependency. But, since the :file entries are nil (see [0]), the value mapped to nil is overridden with each step in the OUTER reduce. Now, let X be a dependency which appeared twice (or at least twice, does not matter) in inputs. If X happens to be the last element of the dependencies (depends on [1]), then in the final map (when the OUTER reduce finishes) X will be mapped to nil. Therefore, in the final index, X will be present twice (once mapped to nil, once mapped to the namespace it provides).

Afterwards, these dependencies are compiled, and when the stars align (= sometimes it happens, sometimes it doesn't, both with parallel and non-parallel build) the compilation will fail with "Can't redefine a constant at <...>". This is most likely due to the fact that certain dependency (X), which has a ^:const var, was compiled twice (and some namespaces are compiled twice, this can be observed when :verbose is set to true).

I could reproduce the error on both windows (locally), and on linux (on a travis-ci server).



 Comments   
Comment by David Nolen [ 24/Feb/17 2:44 PM ]

Please verify that CLJS-1948 does or does not resolve this problem.





[CLJS-1928] Self-host: Macro namespace alias in keyword Created: 02/Feb/17  Updated: 24/Feb/17  Resolved: 24/Feb/17

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-1928.patch    
Patch: Code and Test

 Description   

If, in self-hosted ClojureScript you require a macro namespace and establish an alias, as in

(require-macros '[cljs.spec :as s])

You won't be able to use to use the alias in a keyword, as in

::s/foo

The root cause is that when r/*alias-map* is bound to (current-alias-map) this fails to set up mappings for macro namespaces.



 Comments   
Comment by Mike Fikes [ 02/Feb/17 9:27 PM ]

The attached patch revises (current-alias-map) to additionally consult macros namespaces when setting up the alias map. This is tested by adding the (previously-disabled) keyword unit tests, adding a specific test for a macros namespace alias.

(FWIW, a similar technique is also used in Lumo and Planck and, as a consequence, they can properly read forms involving macros namespace aliases, but the resulting forms cannot be compiled in those environments owing to the change needed in cljs.js).

Comment by David Nolen [ 24/Feb/17 1:23 PM ]

fixed https://github.com/clojure/clojurescript/commit/46dcd22713a924bfd90f0a19449bb09f128d11df





[CLJS-1941] `cljs.compiler/cljs-files-in` shouldn't return `.cljc` files if a `.cljs` file exists for the namespace Created: 14/Feb/17  Updated: 24/Feb/17  Resolved: 24/Feb/17

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: Unassigned
Resolution: Completed Votes: 0
Labels: None

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

 Description   

We're seeing non-determinism in builds due to this problem. This is the same bug as CLJS-1772, but happens at a different code path.



 Comments   
Comment by António Nuno Monteiro [ 14/Feb/17 12:26 PM ]

Attached patch with fix.

Comment by David Nolen [ 24/Feb/17 1:16 PM ]

fixed https://github.com/clojure/clojurescript/commit/3aa1951533ce2ff7a94f90dbcf74904fe413db48





[CLJS-1940] Undeclared var warning when invoking a protocol method on a `js` interop form Created: 14/Feb/17  Updated: 24/Feb/17  Resolved: 24/Feb/17

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

Type: Defect Priority: Major
Reporter: Nicola Mometto Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: interop, protocols, regression


 Description   

Compiling the following code under 1.9.743

(ns test.foo)

(defprotocol Proto
  (f [this]))

(defn foo []
  (f js/Math.E))

Produces the following warning:

WARNING: Use of undeclared Var test.foo/js at line 7 src/test/foo.cljs

This is a regression from 1.9.293

https://github.com/Bronsa/CLJS-1.9.473-regression contains a project set up to reproduce this



 Comments   
Comment by David Nolen [ 24/Feb/17 12:52 PM ]

:advanced
is not the issue here,
:static-fns
is what is required to exhibit the problem.

Comment by David Nolen [ 24/Feb/17 1:05 PM ]

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





[CLJS-1951] Missing 0 and 1 arity versions of interleave Created: 23/Feb/17  Updated: 24/Feb/17  Resolved: 24/Feb/17

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-1951.patch    
Patch: Code and Test

 Description   

For compatibility with Clojure, `interleave` should have 0 and 1 arity versions.



 Comments   
Comment by David Nolen [ 24/Feb/17 12:45 PM ]

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





[CLJS-1952] Bump Closure Compiler to Feb 2017 release Created: 23/Feb/17  Updated: 24/Feb/17  Resolved: 24/Feb/17

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-1952.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 24/Feb/17 12:42 PM ]

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





[CLJS-1937] Self-host: undeclared cljs.core$macros/mod when compiling cljs/core.cljs Created: 12/Feb/17  Updated: 22/Feb/17  Resolved: 22/Feb/17

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-1937.patch    
Patch: Code

 Comments   
Comment by António Nuno Monteiro [ 12/Feb/17 11:32 PM ]

Attached patch with fix.

Comment by David Nolen [ 22/Feb/17 6:59 AM ]

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





[CLJS-1936] cljs.analyzer declares vars which are only used in Clojure Created: 11/Feb/17  Updated: 22/Feb/17  Resolved: 22/Feb/17

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-1936.patch    
Patch: Code

 Description   

We shouldn't be declaring these vars on the ClojureScript side, as they can lead to runtime errors when trying to call those functions from the self-hosted compiler. Putting them under reader conditionals enables emitting warnings when they are used.



 Comments   
Comment by David Nolen [ 22/Feb/17 6:58 AM ]

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





[CLJS-1949] Self-host: cljs.compiler/munge doesn't preserve JVM compiler semantics Created: 21/Feb/17  Updated: 22/Feb/17  Resolved: 22/Feb/17

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-1949.patch    
Patch: Code and Test

 Comments   
Comment by António Nuno Monteiro [ 21/Feb/17 5:17 PM ]

Attached patch with fix and test.

Comment by Mike Fikes [ 21/Feb/17 5:30 PM ]

FWIW, I tried the attached patch downstream with Planck and it worked. Prior to the patch, I observed this behavior:

cljs.user=> (.catch (js/Promise. #(%2 "x")) #(println %))
(new Promise((function (p1__20_SHARP_,p2__19_SHARP_){
return p2__19_SHARP_.call(null,"x");
}))).catch$ is not a function. (In '(new Promise((function (p1__20_SHARP_,p2__19_SHARP_){
return p2__19_SHARP_.call(null,"x");
}))).catch$((function (p1__21_SHARP_){
return cljs.core.println.call(null,p1__21_SHARP_);
}))', '(new Promise((function (p1__20_SHARP_,p2__19_SHARP_){
return p2__19_SHARP_.call(null,"x");
}))).catch$' is undefined)

And with the patch:

cljs.user=> (.catch (js/Promise. #(%2 "x")) #(println %))
x
#object[Promise [object Promise]]
Comment by David Nolen [ 22/Feb/17 6:56 AM ]

fixed https://github.com/clojure/clojurescript/commit/025dd9d3e57f1955fd442b9f69823c892a38cb58





[CLJS-1950] Eliminate instances of #^ Created: 21/Feb/17  Updated: 22/Feb/17  Resolved: 22/Feb/17

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

Type: Enhancement Priority: Trivial
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

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

 Description   

With CLJS-1636 I had, without thinking, blindly followed the existing pattern used to mark def s as private, employing

#^:private

This ticket is to remove those new and the existing instance of this older syntax.



 Comments   
Comment by David Nolen [ 22/Feb/17 6:52 AM ]

fixed https://github.com/clojure/clojurescript/commit/6325a29612b6266ee786ce49a83f12566708e696





[CLJS-1943] Self-host: `cljs.pprint`'s macros can't be compiled Created: 15/Feb/17  Updated: 20/Feb/17  Resolved: 20/Feb/17

Status: Resolved
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: bootstrap

Attachments: Text File CLJS-1943-2.patch     Text File CLJS-1943-3.patch     Text File CLJS-1943.patch    
Patch: Code and Test

 Comments   
Comment by António Nuno Monteiro [ 15/Feb/17 6:46 PM ]

Attached patch with fix and enabled running the cljs.pprint tests when running the self-parity tests.

Comment by David Nolen [ 20/Feb/17 1:50 PM ]

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





[CLJS-1945] cljs.spec/every-impl kind-fn kind-form dead code Created: 18/Feb/17  Updated: 20/Feb/17  Resolved: 20/Feb/17

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-1945.patch    
Patch: Code

 Description   

With Clojure 386e7e6 a [kindfn kindform] let was removed here

https://github.com/clojure/clojure/commit/386e7e63485bcb7bed050df2c2b54a6ceca05e5f#diff-b0f91f319d0c76aadf667da929b08d37L1031

this upstream revision was not copied in ClojureScript 1a297c5 around here:

https://github.com/clojure/clojurescript/commit/1a297c52d958520065335815ffb3dee07c314aa7#diff-5c48ec6d047e1ea6fdcdd00b4f09f45eR729

and is currently dead code that could be removed.



 Comments   
Comment by David Nolen [ 20/Feb/17 11:01 AM ]

fixed https://github.com/clojure/clojurescript/commit/7326d79001f2fbbb2ee4086b1f645cab374c0e58





[CLJS-1944] Can't spec generate non-vector collections Created: 18/Feb/17  Updated: 20/Feb/17  Resolved: 20/Feb/17

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-1944.patch    
Patch: Code and Test

 Description   

If you use cljs.spec/coll-of with non-vector :kind, you can't exercise the spec.

Repro:

$ java -jar cljs.jar -m cljs.repl.node
ClojureScript Node.js REPL server listening on 58736
To quit, type: :cljs/quit
cljs.user=> (require '[clojure.spec :as s] 'clojure.test.check.generators)
true
cljs.user=> (s/exercise (s/coll-of string? :kind set?))
Error: Couldn't satisfy such-that predicate after 100 tries.
...


 Comments   
Comment by Mike Fikes [ 18/Feb/17 11:48 AM ]

This is a cut-n-dry defect simply involving missing this Clojure deletion:

https://github.com/clojure/clojure/commit/23e3ec3f8bceeedee70beed7a17846c25eba05a6#diff-b0f91f319d0c76aadf667da929b08d37L1208

in this ClojureScript tracking change here:

https://github.com/clojure/clojurescript/commit/cd43ec9bf40605e230dc8858c2855f9ad85b39d8#diff-5c48ec6d047e1ea6fdcdd00b4f09f45eL702

The consequence is that gen-into is always non-nil (set to []) and then kind is not made use of here: https://github.com/clojure/clojurescript/blob/627f7fd513d928531db48392d8f52142fea5eb38/src/main/cljs/cljs/spec.cljs#L890-L891

Comment by David Nolen [ 20/Feb/17 10:57 AM ]

fixed https://github.com/clojure/clojurescript/commit/77d9077c04f61a19d86e67d18bd7c93217e88aa3





[CLJS-1946] Self-hosted: don't emit `goog.require` calls for foreign libs if optimizations different than `:none` Created: 18/Feb/17  Updated: 20/Feb/17  Resolved: 20/Feb/17

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-1946.patch    
Patch: Code

 Description   

This is done in JVM CLJS but not in self-hosted.



 Comments   
Comment by David Nolen [ 20/Feb/17 10:53 AM ]

fixed https://github.com/clojure/clojurescript/commit/23beecb7e0b752c98cacebfe0aff3879eab0f0e1





[CLJS-1947] cljs.spec "and" passes :cljs.spec/invalid in next spec after failed if there are 4+ sub-specs Created: 19/Feb/17  Updated: 20/Feb/17  Resolved: 20/Feb/17

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

Type: Defect Priority: Minor
Reporter: Vlad Protsenko Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: bug, clojurescript, spec


 Description   

This bug affects version 1.9.473, but I could not select it in select box, and I did not test it on other versions.

;; This code will print :cljs.spec/invalid once:
(s/conform (s/and pos? println println println) 0)
:cljs.spec/invalid
=> :cljs.spec/invalid

;; This code does not print anything
(s/conform (s/and pos? println println) 0)
=> :cljs.spec/invalid


 Comments   
Comment by Mike Fikes [ 19/Feb/17 9:26 PM ]

Duplicate of CLJS-1935.

Confirmed via git bisect that https://github.com/clojure/clojurescript/commit/ff0b11c123bf46d9e0efff164a7327fb269d2262 fixed the issue reported in this ticket.





[CLJS-536] clj->js trims the namespace prefix from keywords while writing them to string Created: 12/Jul/13  Updated: 19/Feb/17  Resolved: 02/Dec/13

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

Type: Defect Priority: Major
Reporter: Vasile Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: clj->js

Attachments: Text File 0001-CLJS-536-Add-support-for-namespaced-keywords.patch     Text File 0001-CLJS-536-Add-support-for-namespaced-keywords.patch    

 Description   

The following behavior was observed and confirmed from the code:

(clj->js :ns/n) => "n"

I believe this is a limitation and the namespace of the keyword should be kept while writing it to string.
The code in core.js does this while handling keywords:

(keyword? x) (name x)

while it should do this (or something similar):

(keyword? x) (str (namespace x) "/" (name x))



 Comments   
Comment by Vasile [ 12/Jul/13 12:03 PM ]

a better (working) fix: (keyword? x) (str (if (namespace x) (str (namespace x) "/")) (name x))

Comment by David Nolen [ 16/Jul/13 6:22 AM ]

I'd be willing to take a patch that allows this behavior to be configured.

Comment by Niklas Närhinen [ 01/Nov/13 7:33 AM ]

Proposed fix

Comment by Niklas Närhinen [ 01/Nov/13 7:37 AM ]

Fixed version of patch

Comment by David Nolen [ 01/Nov/13 9:23 AM ]

Excellent, Niklas I don't see you on the list of contributors, please send in your Contributor Agreement, http://clojure.org/contributing, so we can apply the patch.

Comment by David Nolen [ 02/Dec/13 8:52 PM ]

I looked more closely at the clj->js source, the system is already customizable. We can't determine ahead of time how you might want to emit keywords and symbols - thus you can extend Keyword and Symbol to IEncodeJS yourself and get the desired behavior.

Comment by Andrea Richiardi [ 17/Jan/17 2:52 PM ]

I have just stumbled across this one, shall we at least say it in the docstring of clj->js that we are losing the namespace part?

Comment by Jozef Wagner [ 19/Feb/17 4:11 AM ]

With the introduction of specs, the namespaced keywords are being used more and more. This issue prevents streamlined edn->json->edn transformation. I think it should be reopened. IMO the 'lossy' method should never be a default one.

Comment by Paulus Esterhazy [ 19/Feb/17 5:53 AM ]

Unless we are willing to break existing code, I don't think it will be possible to change the default behavior.

I'm also not sure that extending IEncodeJS is the best solution, as it affects every call to clj->js, including calls to libraries which may rely on the ns-stripping behavior.

However, the attached patch allows you to make the decision on a per-call basis.

One quibble with the patch: perhaps it would be better to use kwargs style `(clj->js v :preserve-namespaces true)` in line with `js->clj`?





[CLJS-1935] When calling cljs.spec/valid?, subsequent predicates of cljs.spec/and are evaluated even when early predicate is unsatisfied Created: 11/Feb/17  Updated: 16/Feb/17  Resolved: 15/Feb/17

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

Type: Defect Priority: Major
Reporter: Henrik Lundahl Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: clojure.spec

Attachments: Text File CLJS-1935.patch    

 Description   

Affects 1.9.456 and 1.9.473.

The problem is that subsequent predicates of cljs.spec/and are evaluated even when an early predicate is unsatisfied when calling cljs.spec/valid?.

See https://github.com/henriklundahl/minimal-cljs-spec-problem for a minimal example demonstrating the problem.



 Comments   
Comment by David Nolen [ 11/Feb/17 10:49 AM ]

Please do not link outside. Minimal examples need to be in the ticket. This means no project. Just code demonstrating the problem. Thanks.

Comment by Henrik Lundahl [ 12/Feb/17 7:59 AM ]

Since I'm not allowed to edit the description I'll just add the details here.

The following code renders an exception:

(ns asdf
(:require [clojure.spec :as s]))

(defn pred-1? [s]
(> (count s) 100))

(defn pred-2? [s]
(> (count s) 100))

(defn pred-3? [s]
(> (count s) 100))

(s/valid? (s/and string? pred-1? pred-2? pred-3?) "a")

The exception is something like:

Uncaught Error: No protocol method ICounted.-count defined for type cljs.core/Keyword: :cljs.spec/invalid

This works in both Clojure 1.9.0-alpha14 and ClojureScript 1.9.293. It does not work in neither ClojureScript 1.9.456 nor ClojureScript 1.9.473.

Comment by David Nolen [ 15/Feb/17 5:38 PM ]

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

Comment by Henrik Lundahl [ 16/Feb/17 12:47 AM ]

Thanks!





[CLJS-1636] Mark some symbols in core macros ns as private Created: 27/Apr/16  Updated: 15/Feb/17  Resolved: 15/Feb/17

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-1636-2.patch     Text File CLJS-1636-3.patch     Text File CLJS-1636.patch    
Patch: Code

 Description   

There are some symbols in the core macros namespace that are not meant for external consumption. Some of these are marked private and some aren't. This ticket asks that the others be marked private as well.

An example of one symbol marked private is defcurried.
An example of one symbol not marked private is caching-hash.



 Comments   
Comment by Mike Fikes [ 27/Apr/16 8:21 AM ]

In CLJS-1636.patch, I checked and it appears nothing in the compiler codebase is explicitly using these symbols outside of the cljs.core namespace. But, it is still worth scanning through these to check if they make sense. For example js-debugger and js-comment are a couple that might actually be meant for public use, but it is difficult to tell.

Comment by Mike Fikes [ 27/Apr/16 2:43 PM ]

Note, that in #cljs-dev slack, there appears to be interest in caching-hash being public.

(I don't mind revising the patch to suit whatever is needed. At the same time, I'm certainly not in a position to take decisions on what is public API or not.)

Comment by Mike Fikes [ 27/Apr/16 2:43 PM ]

Note, that in #cljs-dev slack, there appears to be interest in caching-hash being public.

(I don't mind revising the patch to suit whatever is needed. At the same time, I'm certainly not in a position to take decisions on what is public API or not.)

Comment by Mike Fikes [ 31/Jul/16 1:33 PM ]

Patch no longer applies. Attaching updated patch.

Comment by Mike Fikes [ 12/Feb/17 1:33 PM ]

Previous patch no longer applies; attaching re-baselined patch.

Comment by David Nolen [ 15/Feb/17 5:46 PM ]

fixed https://github.com/clojure/clojurescript/commit/627f7fd513d928531db48392d8f52142fea5eb38





[CLJS-1939] Bad load_file generated for foreign-dep requires on Node Created: 13/Feb/17  Updated: 15/Feb/17  Resolved: 15/Feb/17

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

Type: Defect Priority: Minor
Reporter: Juho Teperi Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1939-1.patch    

 Description   

After CLJS-1922 ijs :file is preferred as output-path when writing the JS files to output-dir. compiler/load-libs still uses util/relative-name for all cases, which won't work when the JS file is loaded from classpath and written to output-dir using classpath path.

Fix is to use the same logic in load-files to build the path as is used in closure/rel-output-path.



 Comments   
Comment by David Nolen [ 15/Feb/17 5:44 PM ]

fixed https://github.com/clojure/clojurescript/commit/90fc275d939f6c701096378134a930adbd9493f3





[CLJS-1942] Self-host: `cljs.env.macros` and `cljs.analyzer.macros` can't be loaded Created: 14/Feb/17  Updated: 15/Feb/17  Resolved: 15/Feb/17

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: bootstrap

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

 Comments   
Comment by António Nuno Monteiro [ 14/Feb/17 3:50 PM ]

Attached patch with fix.

Comment by David Nolen [ 15/Feb/17 5:41 PM ]

fixed https://github.com/clojure/clojurescript/commit/47cd1cef8f7ed5b16cffc7e2ae4d223328091ab7





[CLJS-1938] :elide-asserts compiler option without effect Created: 13/Feb/17  Updated: 13/Feb/17  Resolved: 13/Feb/17

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

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


 Description   

Some self-host related things broke the :elide-asserts compiler option.

cljs.closure/build is the only place that binds *assert* when the :elide-asserts option is set. This however binds the clojure.core dynamic var, the cljs.core/assert macro however uses the cljs.core dynamic var. Therefore this is always true and asserts are never removed.

Possible fixes:
[1] change to cljs.core/*assert*.
[2] change to (core/when core/*assert* ...

I would like to revisit http://dev.clojure.org/jira/browse/CLJS-1494 and always emit the asserts but wrapped in a goog-define so Closure is able to remove them without us actually affecting the generated JS.

[1] https://github.com/clojure/clojurescript/blob/af2ca808fcc5efc088b48957b898fed0b59eddbe/src/main/clojure/cljs/closure.clj#L2091
[2] https://github.com/clojure/clojurescript/blob/af2ca808fcc5efc088b48957b898fed0b59eddbe/src/main/clojure/cljs/core.cljc#L2247



 Comments   
Comment by Thomas Heller [ 13/Feb/17 7:05 AM ]

Sorry for the noise, my conclusion was wrong. Looked at the wrong file.





[CLJS-1931] Closure Compiler {{--generate_exports}} flag not supported Created: 08/Feb/17  Updated: 10/Feb/17  Resolved: 10/Feb/17

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

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


 Description   

We are including a third-party, Closure-compiler compatible JS library in our ClojureScript project, which is using the @export JSDoc-style tags in the source to export names, and another third party JS library (not Closure Compiler compatible) is expecting those names to be exported.

However, the names are not being exported because, we believe, the --generate_exports flag needs to be passed to the Closure Compiler to get it to parse the JSDoc comments and generate goog.export() calls, and there is no interface to enable that flag from the ClojureScript compiler.



 Comments   
Comment by David Nolen [ 10/Feb/17 12:06 PM ]

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





[CLJS-1919] cljs.spec conformer regression Created: 30/Jan/17  Updated: 10/Feb/17  Resolved: 10/Feb/17

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

Type: Defect Priority: Minor
Reporter: Allan Jiang Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None


 Description   

Upon compiling the following code,

(ns repro.core
  (:require [cljs.spec :as s]))

(defn coll->set [x] 
  (cond
    (set? x) x
    (coll? x) (set x)
    :else ::s/invalid))

(s/def ::set-ints (s/coll-of int? :kind (s/conformer coll->set) :into #{}))
(s/def ::vec-ints (s/coll-of int? :kind vector? :into []))
(try
  (s/valid? ::set-ints [1 2 3]) 
  (catch js/Object e
    (js/console.error e)))
(s/valid? ::vec-ints [1 2 3])

the validation for ::set-ints fails due to using the conformer.

The error message is:

TypeError: cljs.spec.spec_impl.call(...).call is not a function
    at core.cljs:10
    at cljs.spec.every_impl.cljs$core$IFn$_invoke$arity$4.cljs.spec.t_cljs$spec860.cljs$spec$Spec$conform_STAR_$arity$2 (spec.cljs:844)
    at cljs$spec$conform_STAR_ (spec.cljs:40)
    at Function.cljs.spec.valid_QMARK_.cljs$core$IFn$_invoke$arity$2 (spec.cljs:357)
    at cljs$spec$valid_QMARK_ (spec.cljs:353)
    at core.cljs:13


 Comments   
Comment by David Nolen [ 10/Feb/17 11:59 AM ]

As far as I can tell this not a bug, it doesn't work in Clojure 1.9.0-alpha14





[CLJS-1443] ES6 Module Processing at individual :foreign-lib spec Created: 09/Sep/15  Updated: 10/Feb/17  Resolved: 10/Feb/17

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

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


 Description   

ES6 module processing could probably benefit from processing at the individual :foreign-lib spec. Brings up questions wrt. source maps and merged source maps when applying other optimization settings.






[CLJS-1912] cljs.build.api/node-modules Created: 27/Jan/17  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: Next
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 [ 10/Feb/17 10:58 AM ]

fixed in 1.9.456





[CLJS-1074] Externs inference Created: 02/Mar/15  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3211
Fix Version/s: GSoC

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Maria Geller
Resolution: Completed Votes: 4
Labels: None


 Description   

Given all externs generally need to be supplied for js/foo we could probably automatically compute externs based on js/foo usage in user code. For this to work correctly we need to account for property access through js/foo i.e. (def Bar js/foo.Bar). This should infer that Bar is also a foreign object. Things gets more complicated for higher order cases, we probably want to support a ^js type hint.

Finally externs inference needs to account for externs likely already supplied by the user - i.e. don't emit dupes, Google Closure will complain.



 Comments   
Comment by Leon Grapenthin [ 27/Feb/16 3:17 PM ]

Is this still being worked on?

Here is an approach: https://gist.github.com/Chouser/5796967

A very lean first approach would be to generate a `var foo = {}` for every interop expression.

I. e. by experimentation I could observe that no nested statements or var foo = function() statements are required to prevent minification.

js/foo 
js/foo.Bar 
(js/foo.Bar) 
(.-Bar js/foo) 
(.-Bar x) 
;; etc... would all not be minified with 
var foo = {}; 
var Bar = {};

To prevent dupes a cheap way to go would be a CLJS compiler mode in which no extern files are loaded. We can disable Closures externs via the exclude_default_externs compiler flag.

IDK if the minification quality is in any way different if the externs are type annotated or declared nested of with =function() --?

At least it looks like doing this would automate the most common use case of externs in CLJS: Preventing minification.

Comment by David Nolen [ 29/Feb/16 9:05 PM ]

Not actively being worked on at the moment but Maria Geller has a pretty solid proof of concept in a branch that somebody else can pick up. It takes the basic idea from that gist much further.

Comment by Leon Grapenthin [ 01/Mar/16 12:41 AM ]

Branch for reference: https://github.com/mneise/clojurescript/commits/CLJS-1074

Thanks David. Will have a closer look asap.

Comment by David Nolen [ 10/Feb/17 10:58 AM ]

This was shipped in 1.9.456





[CLJS-1934] Self-host: require-macros :reload / :reload-all fails Created: 09/Feb/17  Updated: 10/Feb/17  Resolved: 10/Feb/17

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-1934.patch    
Patch: Code

 Description   

In a self-hosted environment set up to work with cljs.js/*load-fn*, evaluating an expression like

(require-macros 'foo.core :reload)

fails to request a reload of the code.



 Comments   
Comment by Mike Fikes [ 09/Feb/17 5:55 PM ]

This was caused by a simple typo. With the typo and the example in the description, reloads would be passed in as an empty map instead of reload which would contain the key :reload-macros and the value :reload. Deleting the extra s makes it consistent with the other nearby calls and does the trick.

Comment by David Nolen [ 10/Feb/17 9:45 AM ]

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





[CLJS-1933] Support CLJS browserless remote REPL from nodejs Created: 09/Feb/17  Updated: 09/Feb/17

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

Type: Enhancement Priority: Minor
Reporter: Mike Longworth Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: enhancement, remote, repl
Environment:

Dev machine OSX - build and Cursive editing and REPL
Remote: RaspberryPI - nodejs
compiler out-files shared between devices with OSXFUSE.



 Description   

I would like to develop clojurescript for a remote nodejs target compiling cljs and running a REPL on my development machine.
https://github.com/clojure/clojurescript/wiki/Remote-REPL suggests a way of doing this however:

!) I haven't managed to get this working.
2) I don't like that the solution relies identical absolute file paths for the compiler output, better to have matching relative paths.

I made a post to request help with this but haven't managed to resolve all the issues:
https://groups.google.com/forum/#!topic/clojurescript/Y4ajOcej8Qo

I have made some progress since the post:
1) I dug into the cljs.repl.node source and found I can stop the node hang I reported by specifying repl-env :debug-port, and get:

Clojure 1.8.0
Debugger listening on port 5002
ClojureScript Node.js REPL server listening on 5001
TypeError: Cannot read property 'nameToPath' of undefined
at Object.goog.require (repl:2:49)
at repl:1:-56
at Object.exports.runInThisContext (vm.js:54:17)
at Domain.<anonymous> ([stdin]:50:34)
at Domain.run (domain.js:221:14)
at Socket.<anonymous> ([stdin]:49:25)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at readableAddChunk (_stream_readable.js:146:16)
at Socket.Readable.push (_stream_readable.js:110:10)
TypeError: goog.provide is not a function
at repl:1:-56
at Object.exports.runInThisContext (vm.js:54:17)
at Domain.<anonymous> ([stdin]:50:34)
at Domain.run (domain.js:221:14)
at Socket.<anonymous> ([stdin]:49:25)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at readableAddChunk (_stream_readable.js:146:16)
at Socket.Readable.push (_stream_readable.js:110:10)
at TCP.onread (net.js:523:20)
To quit, type: :cljs/quit

This looks like some kind of path problem but I haven't managed to resolve it.

I did some investigations with my original relative-path setup to try and identify the issues:
1) I eliminated absolute paths from the compile output by disabling analysis caching.
2) I ran wireshark on the REPL port and found that absolute paths were being sent by the REPL, this currently makes the relative path option unworkable.

I have many gaps in my knowledge of the REPL operation at the moment and I don't know what the best approach is to getting a good solution for a browserless remote repl setup.



 Comments   
Comment by David Nolen [ 09/Feb/17 12:33 PM ]

It's probably going to be easier to discuss this issue in IRC or Slack first. There's just too many different issues piled into this one. Thanks.





[CLJS-1932] Self-host: Perf regression macroexpand-check Created: 08/Feb/17  Updated: 09/Feb/17  Resolved: 09/Feb/17

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-1932.patch    
Patch: Code

 Description   

With https://github.com/clojure/clojurescript/commit/cebfb586355b526253fdd25965de976b49a6973e you can observe a compilation perf regression. This is particularly noticeable if you load cljs.core.async (from Andare) into a self-hosted environment (both Lumo and Planck exhibit 2-3x slowdowns).



 Comments   
Comment by Mike Fikes [ 08/Feb/17 11:30 PM ]

With the attached patch, downstream perf in loading cljs.core.async in Planck is confirmed to return to the previous good perf.

Also, confirmed downstream that the change doesn't break the ability to have specs on macros:

With this macros namespace:

(ns foo.core
  (:require [clojure.spec :as s]))

(defmacro add [a b]
  `(+ ~a ~b))

(s/fdef add
  :args (s/cat :a int? :b int?))

The spec works properly downstream in Planck:

cljs.user=> (require-macros 'foo.core)
nil
cljs.user=> (foo.core/add "a" 3)
            ^
Call to foo.core$macros/add did not conform to spec:
In: [0] val: "a" fails at: [:args :a] predicate: int?
:cljs.spec/args  ("a" 3)
 at line 1
cljs.user=> (foo.core/add 2 3)
5
Comment by David Nolen [ 09/Feb/17 5:35 AM ]

fixed https://github.com/clojure/clojurescript/commits/master





[CLJS-1930] Master broken wrt static field: ES5_STRICT_UNCOMMON Created: 06/Feb/17  Updated: 06/Feb/17  Resolved: 06/Feb/17

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

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

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

 Description   

{{git clone https://github.com/clojure/clojurescript}}

cd clojurescript/

script/build

...

+ java -server -cp /Users/mfikes/.m2/repository/org/clojure/clojure/1.8.0/clojure-1.8.0.jar:/Users/mfikes/.m2/repository/com/google/javascript/closure-compiler-unshaded/v20161201/closure-compiler-unshaded-v20161201.jar:/Users/mfikes/.m2/repository/com/google/javascript/closure-compiler-externs/v20161201/closure-compiler-externs-v20161201.jar:/Users/mfikes/.m2/repository/args4j/args4j/2.33/args4j-2.33.jar:/Users/mfikes/.m2/repository/com/google/guava/guava/20.0/guava-20.0.jar:/Users/mfikes/.m2/repository/com/google/protobuf/protobuf-java/3.0.2/protobuf-java-3.0.2.jar:/Users/mfikes/.m2/repository/com/google/code/gson/gson/2.7/gson-2.7.jar:/Users/mfikes/.m2/repository/com/google/code/findbugs/jsr305/3.0.1/jsr305-3.0.1.jar:/Users/mfikes/.m2/repository/com/google/jsinterop/jsinterop-annotations/1.0.0/jsinterop-annotations-1.0.0.jar:/Users/mfikes/.m2/repository/org/clojure/google-closure-library/0.0-20160609-f42b4a24/google-closure-library-0.0-20160609-f42b4a24.jar:/Users/mfikes/.m2/repository/org/clojure/google-closure-library-third-party/0.0-20160609-f42b4a24/google-closure-library-third-party-0.0-20160609-f42b4a24.jar:/Users/mfikes/.m2/repository/org/clojure/data.json/0.2.6/data.json-0.2.6.jar:/Users/mfikes/.m2/repository/org/mozilla/rhino/1.7R5/rhino-1.7R5.jar:/Users/mfikes/.m2/repository/org/clojure/tools.reader/1.0.0-beta3/tools.reader-1.0.0-beta3.jar:/Users/mfikes/.m2/repository/org/clojure/test.check/0.9.0/test.check-0.9.0.jar:/Users/mfikes/.m2/repository/com/cognitect/transit-clj/0.8.285/transit-clj-0.8.285.jar:/Users/mfikes/.m2/repository/com/cognitect/transit-java/0.8.311/transit-java-0.8.311.jar:/Users/mfikes/.m2/repository/com/fasterxml/jackson/core/jackson-core/2.3.2/jackson-core-2.3.2.jar:/Users/mfikes/.m2/repository/org/msgpack/msgpack/0.6.10/msgpack-0.6.10.jar:/Users/mfikes/.m2/repository/com/googlecode/json-simple/json-simple/1.1.1/json-simple-1.1.1.jar:/Users/mfikes/.m2/repository/org/javassist/javassist/3.18.1-GA/javassist-3.18.1-GA.jar:/Users/mfikes/.m2/repository/commons-codec/commons-codec/1.10/commons-codec-1.10.jar:src/main/clojure:src/main/cljs clojure.main script/aot.clj
Exception in thread "main" java.lang.RuntimeException: Unable to find static field: ES5_STRICT_UNCOMMON in class com.google.javascript.jscomp.DiagnosticGroups, compiling:(cljs/closure.clj:98:1)
	at clojure.lang.Compiler.analyze(Compiler.java:6688)
	at clojure.lang.Compiler.analyze(Compiler.java:6625)
	at clojure.lang.Compiler$MapExpr.parse(Compiler.java:3072)
	at clojure.lang.Compiler.analyze(Compiler.java:6677)
	at clojure.lang.Compiler.access$300(Compiler.java:38)
	at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:589)
	at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868)
	at clojure.lang.Compiler.analyze(Compiler.java:6669)
	at clojure.lang.Compiler.analyze(Compiler.java:6625)
	at clojure.lang.Compiler.eval(Compiler.java:6931)
	at clojure.lang.Compiler.load(Compiler.java:7379)
	at clojure.lang.RT.loadResourceScript(RT.java:372)
	at clojure.lang.RT.loadResourceScript(RT.java:363)
	at clojure.lang.RT.load(RT.java:453)
	at clojure.lang.RT.load(RT.java:419)
	at clojure.core$load$fn__5677.invoke(core.clj:5893)
	at clojure.core$load.invokeStatic(core.clj:5892)
	at clojure.core$load.doInvoke(core.clj:5876)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.core$load_one.invokeStatic(core.clj:5697)
	at clojure.core$load_one.invoke(core.clj:5692)
	at clojure.core$load_lib$fn__5626.invoke(core.clj:5737)
	at clojure.core$load_lib.invokeStatic(core.clj:5736)
	at clojure.core$load_lib.doInvoke(core.clj:5717)
	at clojure.lang.RestFn.applyTo(RestFn.java:142)
	at clojure.core$apply.invokeStatic(core.clj:648)
	at clojure.core$load_libs.invokeStatic(core.clj:5774)
	at clojure.core$load_libs.doInvoke(core.clj:5758)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.core$apply.invokeStatic(core.clj:648)
	at clojure.core$require.invokeStatic(core.clj:5796)
	at clojure.core$require.doInvoke(core.clj:5796)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at user$eval1.invokeStatic(aot.clj:1)
	at user$eval1.invoke(aot.clj:1)
	at clojure.lang.Compiler.eval(Compiler.java:6927)
	at clojure.lang.Compiler.load(Compiler.java:7379)
	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: Unable to find static field: ES5_STRICT_UNCOMMON in class com.google.javascript.jscomp.DiagnosticGroups
	at clojure.lang.Util.runtimeException(Util.java:221)
	at clojure.lang.Compiler.analyzeSymbol(Compiler.java:7061)
	at clojure.lang.Compiler.analyze(Compiler.java:6648)
	... 47 more


 Comments   
Comment by António Nuno Monteiro [ 06/Feb/17 6:00 PM ]

Attached patch with fix.

Comment by David Nolen [ 06/Feb/17 6:05 PM ]

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

Comment by Mike Fikes [ 06/Feb/17 6:09 PM ]

Confirmed that with the patch I can build locally and tests pass.





[CLJS-1929] When expanding libs don't include Hidden files Created: 04/Feb/17  Updated: 06/Feb/17  Resolved: 06/Feb/17

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

Type: Defect Priority: Major
Reporter: Bruce Hauman Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1929.patch    

 Description   

When the compiler expands libs that are directories it is including hidden files. The will cause builds to break when editors like Emacs make temp files in the src directories.



 Comments   
Comment by Bruce Hauman [ 04/Feb/17 2:03 PM ]

Providing a simple solution that avoids Hidden files.

Comment by David Nolen [ 06/Feb/17 3:23 PM ]

fixed https://github.com/clojure/clojurescript/commit/182ad1621e2bc4293098dde2f214f5aac4091e75





[CLJS-1905] Self-host: Stacktraces for script/test-self-parity Created: 25/Jan/17  Updated: 06/Feb/17  Resolved: 06/Feb/17

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-1905-2.patch     Text File CLJS-1905.patch    
Patch: Code

 Description   

If script/test-self-parity fails, you currently only get a prn of the error, which makes it difficult to locate the cause of the error. Add some infrastructure to print stacktraces.



 Comments   
Comment by Mike Fikes [ 05/Feb/17 12:29 PM ]

Previous patch no longer applies; attaching re-baselined patch.

Comment by David Nolen [ 06/Feb/17 3:22 PM ]

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





[CLJS-1795] Support more options in the `:closure-warnings` compiler option Created: 28/Sep/16  Updated: 06/Feb/17  Resolved: 06/Feb/17

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-1795.patch    
Patch: Code

 Description   

Support more options in the `:closure-warnings` compiler option as per https://github.com/google/closure-compiler/wiki/Warnings#warnings-categories



 Comments   
Comment by António Nuno Monteiro [ 05/Feb/17 10:28 PM ]

Attached patch with fix.

Comment by David Nolen [ 06/Feb/17 3:21 PM ]

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





[CLJS-1902] Add support for compiler option :inline-source-maps Created: 24/Jan/17  Updated: 06/Feb/17

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: 1
Labels: None

Patch: Code and Test

 Description   

1. refactor `emit-source-map` and break it into multiple functions
2. fix logic for relative path computation (see `strip-prefix-path`)
3. add support for `:inline-source-maps` option
4. add tests

Related: CLJS-1402, CLJS-1901



 Comments   
Comment by Antonin Hildebrand [ 24/Jan/17 8:09 PM ]

Patches:
https://github.com/darwin/clojurescript/commit/de1da63072c8049b9812d41cce750e5a972c0b0b.patch
https://github.com/darwin/clojurescript/commit/2389fb7839a18299d842d381b135a669a7091869.patch
https://github.com/darwin/clojurescript/commit/3ba594d8c7215ef8c8276737b7e5d8008c6b3a98.patch

Comment by Antonin Hildebrand [ 24/Jan/17 8:27 PM ]

Full review: https://github.com/clojure/clojurescript/compare/darwin:inline-source-maps~3...darwin:inline-source-maps

Also please note that the first patch testing original functionality fails in one test because there was a bug in timestamp formatting in :source-map-url case:
https://github.com/clojure/clojurescript/compare/master...darwin:inline-source-maps#diff-55b85385d2d0bfb6dc20d59ed982d5c8L1239

Comment by Antonin Hildebrand [ 25/Jan/17 10:25 AM ]

Today when testing Dirac I realised we need to embed sources contents as well.

Additional patch:
https://github.com/darwin/clojurescript/commit/c1df38f14a33d02fe2d421f80db0b421b17286bb.patch

New review URL: https://github.com/darwin/clojurescript/compare/inline-source-maps~4...darwin:inline-source-maps

Tested in DevTools and works like a charm.

Comment by Dusan Maliarik [ 06/Feb/17 10:00 AM ]

This would be helpful for us as well.





[CLJS-1923] Optimization causes TypeError not a function with a simple three.js dependency Created: 01/Feb/17  Updated: 06/Feb/17  Resolved: 06/Feb/17

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

Type: Defect Priority: Major
Reporter: David Plumpton Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: cljs, compiler
Environment:

Ubuntu 16.10, Clojurescript 1.9.456


Attachments: GZip Archive problem.tar.gz    

 Description   

I've created a simple test case that creates a three.js renderer and calls one function on loading (.setSize renderer 200 200)

When building with "lein cljsbuild once dev" everything works when the browser loads index.html.

But with "lein cljsbuild once min" an error occurs on loading:
"Uncaught TypeError: (intermediate value).bc is not a function"



 Comments   
Comment by David Plumpton [ 04/Feb/17 6:17 PM ]

Sorry, misunderstanding of externs behaviour, please close.





[CLJS-1927] Restore ability to refer to foreign libs placed within project-local classpath roots Created: 02/Feb/17  Updated: 04/Feb/17  Resolved: 04/Feb/17

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

Type: Defect Priority: Major
Reporter: Chas Emerick Assignee: Chas Emerick
Resolution: Duplicate Votes: 0
Labels: None

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

 Description   

https://github.com/clojure/clojurescript/commit/97d2d61e78ce747d02d0e5b2ced706f6fb68ec4e changed how relative paths for foreign lib destinations are determined, but made it so that the compiler (at least in some cases) cannot accommodate foreign libs that are defined and sourced from project-local classpath roots (directories, not jars).

This was originally reported and hashed around starting here: https://github.com/bhauman/lein-figwheel/issues/516#issuecomment-275818898

The most minimal case of this I could construct is here: https://github.com/cemerick/figwheel-516 Oddly, bhauman wasn't able to replicate that failing project; even worse, this failure only affects figwheel, not cljsbuild. We've not been able to figure out why that is, but there is one other person on that figwheel issue thread that hit the same problem.

The attached patch does fix my original project's figwheel usage, the minimal case repo I linked above in my testing, and the other contributor's usage in the figwheel issue thread. The change treats file URLs the same as {{java.io.File}}s with regard to calculating relative paths, which AFAICT is most appropriate for the stated objective of the function in question.



 Comments   
Comment by António Nuno Monteiro [ 02/Feb/17 12:03 PM ]

This is probably related to CLJS-1922. We should come up with a solution that solves both problems.

Comment by Chas Emerick [ 02/Feb/17 12:19 PM ]

Yes, CLJS-1922 looks like a related if not equivalent problem. I wish I had found that before filing this.

Comment by David Nolen [ 03/Feb/17 1:39 PM ]

Please check that CLJS-1922 doesn't solve this problem. It's been applied to master.

Comment by Chas Emerick [ 04/Feb/17 7:40 PM ]

Looks good here with CLJS master, closing as dupe of CLJS-1922. Thanks!





[CLJS-1922] uti/relative-name presumes that local foreign-lib files are under working directory which is not true on Boot Created: 30/Jan/17  Updated: 03/Feb/17  Resolved: 03/Feb/17

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:

Cljs 1.9.456, Boot-cljs


Attachments: Text File CLJS-1922-1.patch    

 Description   

cljs.util/relative-name presumes that foreign-libs are located under working directory.

This is not true on Boot with local deps.cljs and foreign-libs. In Boot files from source/resource-paths are copied into temp directories (outside of working directory), and classpath contains these temp directories.

I'm investigation two solutions:

Improve relative-name to return paths relative to a classpath directory under which the file is found. Path relative to a classpath directory should be unique enough for output path, as foreign library contents are anyway read from classpath (unless I'm mistaken).

Another solution I'll check, is why the paths need to be relativized, in most cases foreign-lib `:file` value is relative.



 Comments   
Comment by Juho Teperi [ 30/Jan/17 7:07 PM ]

Solution using :file as output path if it is set and is relative. Else falls back to the current behavior.

Comment by David Nolen [ 03/Feb/17 1:39 PM ]

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





[CLJS-1831] Self-host: Improperly munge ns names Created: 22/Oct/16  Updated: 03/Feb/17  Resolved: 03/Feb/17

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-1831-2.patch     Text File CLJS-1831-3.patch     Text File CLJS-1831.patch    

 Description   

If you have a namespace containing a reserved JavaScript keyword, in self-hosted ClojureScript the namespace isn't properly munged for the goog.provide call. A result is that symbols defined in the namespace will be attached to a nonexistent JavaScript object.

To reproduce, add a test namespace, say static.core that does nothing but have an assert that (= 1 1).



 Comments   
Comment by Mike Fikes [ 22/Oct/16 1:04 PM ]

Without the prod code fixes in cljs.js, a new unit test fails, producing the desired warning but then tripping up on attempting to attach to an undefined JavaScript static$ object, with the root cause being a goog.provide('static.core-test') call instead of the needed goog.provide('static$.core-test') as is done in regular ClojureScript:

WARNING: Namespace static.core-test contains a reserved JavaScript keyword, the corresponding Google Closure namespace will be munged to static$.core_test at line 1 src/test/cljs/static/core_test.cljs
#error {:message "ERROR in file src/test/cljs/static/core_test.cljs", :data {:tag :cljs/analysis-error}, :cause #object[ReferenceError ReferenceError: static$ is not defined]}

The production fix is to simply call cljs.compiler/munge instead of cljs.core/munge.

Comment by Mike Fikes [ 16/Dec/16 2:50 PM ]

Previous patch no longer applies. Attaching CLJS-1831-2.patch

Comment by Mike Fikes [ 02/Feb/17 10:04 PM ]

The previous patch no longer applies; attaching re-baselined patch.

Comment by David Nolen [ 03/Feb/17 1:34 PM ]

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





[CLJS-1926] Changes to namespace metadata are not properly transferred to *ns* dynamic var Created: 02/Feb/17  Updated: 02/Feb/17

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   

A CLJS macro may want to access the metadata of the current ns via (meta *ns*).

Changes to the ns metadata are not reflected back the *ns* var when re-compiling a namespace, the metadata of the first compile will remain. This is due to the analyzer always calling create-ns but never updating the meta. It should probably be updated inside parse 'ns [1]. Clojure always resets the metadata via the ns macro.

One potential conflict is when a .clj and a .cljs file exist for the same namespace and both provide different metadata. Both platforms reseting the meta is probably not ideal, maybe we should vary-meta merge instead?

[1] https://github.com/clojure/clojurescript/blob/94b4e9cdc845c1345d28f8e1a339189bd3de6971/src/main/clojure/cljs/analyzer.cljc#L2312






[CLJS-1925] Use of undeclared Var cljs.user/RegExp when extending protocol for RegExp Created: 01/Feb/17  Updated: 01/Feb/17  Resolved: 01/Feb/17

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

Type: Defect Priority: Major
Reporter: Juho Teperi Assignee: David Nolen
Resolution: Completed Votes: 1
Labels: None

Attachments: Text File CLJS-1925.patch     Text File CLJS-1925-test-2.patch    
Patch: Code and Test

 Description   

WARNING: Use of undeclared Var schema.core/RegExp at line 356 /home/juho/.boot/cache/tmp/home/juho/Source/**/**/4i8/-uc8bn7/js/main.out/schema/core.cljs
WARNING: Use of undeclared Var bidi.bidi/RegExp at line 232 /home/juho/.boot/cache/tmp/home/juho/Source/**/**/4i8/-uc8bn7/js/main.out/bidi/bidi.cljc

https://github.com/juxt/bidi/blob/master/src/bidi/bidi.cljc#L230
https://github.com/plumatic/schema/blob/master/src/cljx/schema/core.cljx#L355

First commit with problem: https://github.com/clojure/clojurescript/commit/d961e66edfd3d62f80bed18418c597ee1f569e85

Test case by thheller:

(defprotocol X
  (x [x]))

(defprotocol Y
  (y [y]))

(extend-protocol X
  js/RegExp
  (x [x]
    (y x)))

(extend-protocol Y
  js/RegExp
  (y [y]
    :y))


 Comments   
Comment by António Nuno Monteiro [ 01/Feb/17 3:56 PM ]

Attached patch with fix and test.

As specified in the commit message, this is a regression caused by the improper fix to CLJS-1607, which this patch now properly fixes.

Comment by António Nuno Monteiro [ 01/Feb/17 3:59 PM ]

^ The patch I attached is CLJS-1925.patch. The other should be disregarded as it only includes a test.

Comment by David Nolen [ 01/Feb/17 4:02 PM ]

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





[CLJS-1920] cljs.build.api/node-inputs: package.json files are only added if module entries are top-level Created: 30/Jan/17  Updated: 01/Feb/17  Resolved: 01/Feb/17

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-1920.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 01/Feb/17 10:29 AM ]

fixed https://github.com/clojure/clojurescript/commits/master





[CLJS-1924] The compiler cannot infer the target type of "(. RecordName -prototype)" expressions Created: 01/Feb/17  Updated: 01/Feb/17

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

Type: Defect Priority: Minor
Reporter: Viktor Magyari Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: compiler, extern


 Description   

Repro:

Place

(set! *warn-on-infer* true)

(defrecord Foo [])

anywhere in your source files, compile with :infern-externs true.

Expected:

Multiple warnings like:

  • WARNING: Cannot infer target type in expression (. Foo -prototype)
  • WARNING: Cannot infer target type in expression (. other__8838__auto__ -constructor)
  • WARNING: Cannot infer target type in expression (. user/Foo -getBasis)

There are also warnings for (. cljs.core/List -EMPTY), but this might be unrelated.






[CLJS-1918] case needs a type hint for keywords case when using *warn-on-infer* Created: 30/Jan/17  Updated: 30/Jan/17

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

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





[CLJS-1917] `case` doesn't handle matching against lists Created: 28/Jan/17  Updated: 28/Jan/17

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


 Description   

The following works in Clojure but not ClojureScript

(let [foo '(:a :b)]
  (case foo
    '(:a :b) :works))





[CLJS-1916] __dirname and __filename are not defined when compiling for Node.js with optimizations :none Created: 28/Jan/17  Updated: 28/Jan/17  Resolved: 28/Jan/17

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-1916.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 28/Jan/17 2:08 PM ]

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





[CLJS-1864] timestamped source maps broken with Node Created: 29/Nov/16  Updated: 28/Jan/17

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

Type: Defect Priority: Minor
Reporter: Dmitr Sotnikov Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None


 Description   

I'm using Figwheel with Node, and noticed a bug with timestamped source maps. When the :source-map-timestamp compiler flag is set, the sourceMappingURL is set to source.js.map?timestamp.

This works fine in the browser, but breaks in Node where files are loaded from the filesystem. It looks like a simple workaround would be to check if :target is :node and output something like source.js.timestamp.map instead, and use it directly as the value of sourceMappingURL.

Here's a change I made locally in cljs.compiler/emit-source-map that allows source maps to be resolved on Node when using timestamps:

emit-source-map
(defn emit-source-map [src dest sm-data opts]
     (let [timestamp (System/currentTimeMillis)
           filename (str (.getPath ^File dest)
                         (when (and
                                 (true? (:source-map-timestamp opts))
                                 (= (:target opts) :nodejs))
                           (str "." timestamp))
                         ".map")
           sm-file  (io/file filename)]
       (if-let [smap (:source-map-asset-path opts)]
         (emits "\n//# sourceMappingURL=" smap
                (string/replace (util/path sm-file)
                                (str (util/path (io/file (:output-dir opts))))
                                "")
                (if (and (true? (:source-map-timestamp opts))
                         (not= (:target opts) :nodejs))
                  (str
                    (if-not (string/index-of smap "?") "?" "&")
                    "rel=" timestamp)
                  ""))
         (emits "\n//# sourceMappingURL="
                (or (:source-map-url opts) (.getName sm-file))
                (if (and (true? (:source-map-timestamp opts))
                         (not= (:target opts) :nodejs))
                  (str "?rel=" timestamp)
                  "")))
       (spit sm-file
             (sm/encode {(url-path src) (:source-map sm-data)}
                        {:lines                   (+ (:gen-line sm-data) 2)
                         :file                    (url-path dest)
                         :source-map-path         (:source-map-path opts)
                         :source-map-timestamp    (:source-map-timestamp opts)
                         :source-map-pretty-print (:source-map-pretty-print opts)
                         :relpaths                {(util/path src)
                                                   (util/ns->relpath (first (:provides opts)) (:ext opts))}}))))


 Comments   
Comment by David Nolen [ 30/Nov/16 8:32 AM ]

Does Node.js have source map caching issues? The timestamp feature was created for caching issues present in web browsers.

Comment by Dmitr Sotnikov [ 30/Nov/16 8:39 AM ]

I tried it with :source-map-timestamp set to false, and source maps got out of sync when Cljs sources were reloaded.

Comment by David Nolen [ 30/Nov/16 10:01 AM ]

Okay. This issue will require more investigation into Node.js source mapping support before pursuing anything. As the behavior is understood, information should be added here.

Comment by Dmitr Sotnikov [ 30/Nov/16 2:56 PM ]

Sounds like a plan.

Comment by David Nolen [ 30/Nov/16 7:25 PM ]

OK I took a look at the implementation of source-map-support, it does indeed cache the source map. However the proposed idea here isn't comprehensive enough. We need to change all the places where :source-map-timestamp is used in the source code. Patch is welcome.

Comment by Dmitr Sotnikov [ 30/Nov/16 7:28 PM ]

Yeah, I noticed the key is used in a few places. I can definitely take a look at making a patch in the near future if the approach looks good to you.

Comment by Dmitr Sotnikov [ 28/Jan/17 12:39 PM ]

It looks like the approach of adding a timestamp introduces some problems. Generating unique file names would mean that old files have to be cleaned up somehow, since the new files will no longer overwrite them. Having to keep track of that isn't ideal. Perhaps it would be better to see if there's a way to prevent Node from caching the source maps.





[CLJS-1915] cljs.test: Index out of bounds for stack element w/o line/column Created: 28/Jan/17  Updated: 28/Jan/17  Resolved: 28/Jan/17

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-1915.patch    
Patch: Code and Test

 Description   

The cljs.test/js-line-and-column function does not properly handle stack elements that have no line and column information encoded in them. In particular, if you pass in something like "eval@[native code]" (which can be part of a stack from JavaScriptCore), you will get an index out of bounds exception.



 Comments   
Comment by David Nolen [ 28/Jan/17 11:11 AM ]

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





[CLJS-1914] Investigate directly requiring CommonJS Node module into a ClojureScript namespace Created: 28/Jan/17  Updated: 28/Jan/17

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

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


 Comments   
Comment by David Nolen [ 28/Jan/17 10:20 AM ]

We would need to check that it exists. We would also need to parse out CommonJS requires to sort out the foreign libs inputs.





[CLJS-1913] Investigate slow reading / compilation of CLJC files Created: 27/Jan/17  Updated: 27/Jan/17

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





[CLJS-1910] Self-host: Need to eliminate use of cljs.nodejs/require Created: 26/Jan/17  Updated: 27/Jan/17  Resolved: 27/Jan/17

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-1910.patch    
Patch: Code

 Description   

Need to change this:

https://github.com/clojure/clojurescript/blob/master/src/test/self/self_parity/test.cljs#L56



 Comments   
Comment by António Nuno Monteiro [ 27/Jan/17 12:50 AM ]

The change from `require` to `nodeGlobalRequire` in this commit
https://github.com/clojure/clojurescript/commit/59a7f265fac02c931cc3d5615727da861db62e3b#diff-db201d3634488851510ee2fbce327924R75
means that loading every file will go through `vm.runInThisContext`.

The above causes `require` to not be bound, since `require` is a "free variable" and not a property of the global object (more context here https://github.com/nodejs/node-v0.x-archive/issues/9211#issuecomment-134412415).

A suggested fix is to add `global.require = require;` to `cljs/bootstrap_node.js`. I tested that fix and it worked.

Note that this is not only breaking the self-host tests. It will break every ClojureScript build which targets Node.js under `:none` optimizations, which should therefore be considered critical.

Comment by Mike Fikes [ 27/Jan/17 1:18 AM ]

The attached patch addresses (and only addresses) the primary issue in this ticket: The need to use js/require.

Given the critical and subtle nature of the side issue discovered and detailed in António's comment above, that issue is split off to CLJS-1911 in case some other more appropriate solution is found for it.

Comment by David Nolen [ 27/Jan/17 9:20 AM ]

fixed by removing the breaking change https://github.com/clojure/clojurescript/commit/18d1e5792f6c712b6c8e426ac9123ee4b898a374, CLJS-1911 was the root cause





[CLJS-1911] Need to bind Node.js require Created: 27/Jan/17  Updated: 27/Jan/17  Resolved: 27/Jan/17

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

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

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

 Description   

While making an ostensibly simple change for CLJS-1910, updating from cljs.nodejs/require to js/require, it was discovered that Node was, initially inexplicably, indicating that require wasn't available at runtime.

Credit to António: He discovered the root cause, potential serious ramifications, and a potential patch (attached to this ticket). See more detailed commentary from António here: http://dev.clojure.org/jira/browse/CLJS-1910?focusedCommentId=44906&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-44906

The attached patch is sufficient to allow the patch attached to CLJS-1910 pass script/test-self-parity.

Given the subtleties surrounding this issue, this patch probably warrants review.



 Comments   
Comment by David Nolen [ 27/Jan/17 9:02 AM ]

fixed https://github.com/clojure/clojurescript/commit/35bcfce2565148cd96b31499a2bbc3bfc2257822





[CLJS-1909] Self-host: circular dependency when requiring cljs.reader Created: 26/Jan/17  Updated: 26/Jan/17  Resolved: 26/Jan/17

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-1909.patch    
Patch: Code

 Description   

`cljs.analyzer` -> `cljs.reader` -> `cljs.reader$macros` -> `cljs.analyzer`



 Comments   
Comment by David Nolen [ 26/Jan/17 11:32 PM ]

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





[CLJS-1906] Self-host: script/test-self-parity fails Created: 25/Jan/17  Updated: 26/Jan/17  Resolved: 26/Jan/17

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-1906.patch    

 Description   

With master as of the writing of this ticket

script/test-self-parity fails with:

#error {:message "Could not parse ns form cljs.clojure-alias-test", :data {:tag :cljs/analysis-error}, :cause #object[Error Error: No protocol method IDeref.-deref defined for type null: ]}


 Comments   
Comment by David Nolen [ 26/Jan/17 10:10 PM ]

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





[CLJS-1908] Improve error messages by using pr-str instead of str when printing objects Created: 26/Jan/17  Updated: 26/Jan/17

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: 1
Labels: errormsgs


 Description   

Many error messages from ClojureScript include the invalid argument like this:

(throw (js/Error. (str "Doesn't support name: " x)))

If x is nil, then the error message produces is "Doesn't support name: " which is a bit mystifying to debug. If x was wrapped with pr-str then the error message would be the much more understandable: "Doesn't support name: nil".

If there's interest in this, then I can prepare a patch which wraps these kinds of errors with pr-str.






[CLJS-1907] Improve error message from cljs.reader/read-string when reading keyword with number first (e.g. :0seconds) Created: 26/Jan/17  Updated: 26/Jan/17

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

Type: Enhancement Priority: Trivial
Reporter: Daniel Compton Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: errormsgs

Attachments: Text File CLJS-1907.patch    

 Description   

In read-keyword, if the keyword doesn't match symbol-pattern then re-matches* returns nil, and then the aget for token throws an error about null not being an object. The provided patch checks if the keyword matches, and if not throws an error with a descriptive error message that the keyword is not valid.

This hit our team when we were trying to deserialise some EDN, and we had keywords with leading numbers in them.

(defn read-keyword
  [reader initch]
  (let [token (read-token reader (read-char reader))
        a (re-matches* symbol-pattern token) ;; returns nil when token is `0s`
        token (aget a 0) ;; throws from aget on nil
        ns (aget a 1)
        name (aget a 2)]
    (if (or (and (not (undefined? ns))
                 (identical? (. ns (substring (- (.-length ns) 2) (.-length ns))) ":/"))
            (identical? (aget name (dec (.-length name))) ":")
            (not (== (.indexOf token "::" 1) -1)))
      (reader-error reader "Invalid token: " token)
      (if (and (not (nil? ns)) (> (.-length ns) 0))
        (keyword (.substring ns 0 (.indexOf ns "/")) name)
        (keyword token)))))


 Comments   
Comment by Daniel Compton [ 26/Jan/17 6:05 PM ]

I don't love using the _ side effect in the let binding, but the alternative makes the code a bit uglier and less readable.





[CLJS-1841] Check lib folder before compiling with cljsc, check for compilation success before running tests Created: 06/Nov/16  Updated: 25/Jan/17

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: None

Attachments: Text File CLJS-1841.patch     Text File CLJS-1841v2.patch    
Patch: Code

 Description   

If script/bootstrap hasn't been run, then running script/test returns the slightly cryptic error message:

Error: Could not find or load main class clojure.main

This patch checks if the lib folder exists and has files in it. If not it prompts the user to run script/bootstrap and exits.

This patch also adds a check for compilation success before running tests against the various VM engines.



 Comments   
Comment by Daniel Compton [ 25/Jan/17 5:57 PM ]

Add v2 patch.





[CLJS-1903] Remove anonymous vars from dir and apropos output Created: 24/Jan/17  Updated: 25/Jan/17  Resolved: 25/Jan/17

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-1903.patch    
Patch: Code

 Description   

Anonymous vars (associated with reify gensyms) appear in dir output. For example, the trailing end of (dir cljs.spec) looks like:

...
spec-impl
spec?
t_cljs$spec3750
t_cljs$spec3780
t_cljs$spec3821
t_cljs$spec3836
t_cljs$spec3854
t_cljs$spec3867
t_cljs$spec3874
t_cljs$spec3970
t_cljs$spec3973
t_cljs$spec3984
t_cljs$spec3987
t_cljs$spec4003
t_cljs$spec4253
t_cljs$spec4256
t_cljs$spec4266
t_cljs$spec4272
tuple-impl
unform
unform*
valid?
with-gen
with-gen*

(For comparison, items like these don't appear in the Clojure REPL for dir output.)

This ticket requests that these be removed from dir as well as apropos as being noise / distraction.



 Comments   
Comment by Mike Fikes [ 24/Jan/17 11:03 PM ]

In addition to the example in the description, with the attached patch:

cljs.user=> (apropos spec)
(cljs.core/special-symbol? cljs.core/specify cljs.core/specify! 
cljs.spec/*fspec-iterations* cljs.spec/->t_cljs$spec3750 
cljs.spec/->t_cljs$spec3780 cljs.spec/->t_cljs$spec3821 
cljs.spec/->t_cljs$spec3836 cljs.spec/->t_cljs$spec3854 
cljs.spec/->t_cljs$spec3867 cljs.spec/->t_cljs$spec3874 
cljs.spec/->t_cljs$spec3970 cljs.spec/->t_cljs$spec3973 
cljs.spec/->t_cljs$spec3984 cljs.spec/->t_cljs$spec3987 
cljs.spec/->t_cljs$spec4003 cljs.spec/->t_cljs$spec4253 
cljs.spec/->t_cljs$spec4256 cljs.spec/->t_cljs$spec4266 
cljs.spec/->t_cljs$spec4272 cljs.spec/and-spec-impl 
cljs.spec/fspec-impl cljs.spec/get-spec cljs.spec/map-spec 
cljs.spec/map-spec-impl cljs.spec/merge-spec-impl 
cljs.spec/multi-spec-impl cljs.spec/or-spec-impl 
cljs.spec/regex-spec-impl cljs.spec/spec-impl cljs.spec/spec? 
cljs.spec/t_cljs$spec3750 cljs.spec/t_cljs$spec3780 
cljs.spec/t_cljs$spec3821 cljs.spec/t_cljs$spec3836 
cljs.spec/t_cljs$spec3854 cljs.spec/t_cljs$spec3867 
cljs.spec/t_cljs$spec3874 cljs.spec/t_cljs$spec3970 
cljs.spec/t_cljs$spec3973 cljs.spec/t_cljs$spec3984 
cljs.spec/t_cljs$spec3987 cljs.spec/t_cljs$spec4003 
cljs.spec/t_cljs$spec4253 cljs.spec/t_cljs$spec4256 
cljs.spec/t_cljs$spec4266 cljs.spec/t_cljs$spec4272)

becomes much more useful:

cljs.user=> (apropos spec)
(cljs.core/special-symbol? cljs.core/specify cljs.core/specify! 
cljs.spec/*fspec-iterations* cljs.spec/and-spec-impl 
cljs.spec/fspec-impl cljs.spec/get-spec cljs.spec/map-spec 
cljs.spec/map-spec-impl cljs.spec/merge-spec-impl 
cljs.spec/multi-spec-impl cljs.spec/or-spec-impl 
cljs.spec/regex-spec-impl cljs.spec/spec-impl cljs.spec/spec? 
cljs.spec/specize*)
Comment by David Nolen [ 25/Jan/17 5:01 PM ]

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





[CLJS-1904] Reload support for JS Modules Created: 25/Jan/17  Updated: 25/Jan/17

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

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


 Description   

Process modules currently works by changing transforming compiler opts. This means the resulting compiler opts cannot be used to run JS module processing again. This issue is now clear in cljs/repl.cljc. The other issue is that JS module processing is the only time that ClojureScript is involved in the compilation of JS sources - prior to this we never to need to trigger JS compilation ourselves. Thus require + :reload doesn't work on JS namespaces.






[CLJS-1453] cljs.compiler/load-libs does not preserve user expressed require order Created: 17/Sep/15  Updated: 25/Jan/17  Resolved: 25/Jan/17

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

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

Attachments: Text File cljs-1453-1.patch    

 Description   

Due to putting the requires into a map the original order is lost. This is a problem primarily when order specific side effects are present in the required namespaces.



 Comments   
Comment by Angus Fletcher [ 09/Jan/17 5:08 PM ]

This patch changes deps in parse 'ns and parse 'ns* to be a vector, which gives us deterministic ordering in load-libs.

Comment by Angus Fletcher [ 09/Jan/17 5:36 PM ]

Patch, updated to remove whitespace changes.

Comment by David Nolen [ 25/Jan/17 3:19 PM ]

fixed https://github.com/clojure/clojurescript/commit/94b4e9cdc845c1345d28f8e1a339189bd3de6971





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

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

Type: Defect Priority: Minor
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.check.

(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.



 Comments   
Comment by David Nolen [ 30/Sep/16 11:41 AM ]

This is not a bug per se, we can't do what Clojure does here. How to best handle is something to consider. Present a good idea and submit a patch.

Comment by Andrea Richiardi [ 24/Jan/17 4:46 PM ]

I went through cljs.spec.test and I have noticed that basically the [clojure.test.check :as stc] dependencies is there only for using the namespace for stc/ret and others. We could get rid of it and use the ns explicitely.

There is another require, which is [clojure.test.check.properties]. My guess is that it is there because of some side-effect (maybe it registers some spec?). I need some enlightenment here but I could work on a cut-off





[CLJS-1402] Source Mapping Closure Error Logger Created: 08/Aug/15  Updated: 24/Jan/17

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

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: type-check


 Description   

Current error reports generated by Google Closure point back to the generated JavaScript sources. For JavaScript source that originated from ClojureScript we should generated source mapped reports.



 Comments   
Comment by Antonin Hildebrand [ 24/Jan/17 8:06 PM ]

I believe this will be fixed by CLJS-1901 either using `--source_map_input` or inlining source-maps into generated js files (CLJS-1902).





[CLJS-1901] Investigate new Google Closure source mapping support Created: 24/Jan/17  Updated: 24/Jan/17

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: None


 Description   

Google Closure now contains comprehensive support for (at least from the command line) for source map merging and inline source map generation. We should investigate how reusable this functionality actually is.



 Comments   
Comment by Antonin Hildebrand [ 24/Jan/17 3:30 PM ]