<< Back to previous view

[CLJS-25] goog.global.Date/String etc don't work in non-browser advanced mode Created: 22/Jul/11  Updated: 23/Jul/11  Resolved: 23/Jul/11

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

Type: Defect Priority: Blocker
Reporter: Rich Hickey Assignee: Rich Hickey
Resolution: Completed Votes: 0
Labels: None


 Description   

goog.global resolves to something undefined in advanced mode when not in the browser. This prevents us from using e.g. goog.global.String

We should experiment with --use_only_custom_externs=true flag for these builds. The book also mentions:
http://code.google.com/p/closure-compiler/source/browse/trunk/externs/es3.js?r=996

Not having this is causing all kinds of ick as people use js* for everything



 Comments   
Comment by Stuart Halloway [ 22/Jul/11 1:38 PM ]

It appears that the disabled warnings in script/compile

--jscomp_off=undefinedVars \
  --jscomp_off=missingProperties \

are disabled because of js* stuff that would go away if this issue was solved. Can these warnings be re-enabled or are they necessary for some other reason?

Comment by Stuart Halloway [ 22/Jul/11 2:36 PM ]

While experimenting with Advanced mode codegen, I found a workaround:

(defn ^:export _ggfn [] [goog.global])
(set! goog.global.String.prototype.call ...

compiles to

ba("cljs.core._ggfn", function() {
  return T([n])
});
n.H.prototype.call = function() {

The important thing above is the n. which refers to goog.global. Without the exported fn mentioning goog.global, the same set! code compiles to an invalid reference to this:

this.H.prototype.call = function() {

Interestingly, an exported def that refers to goog.global does not fix the problem, it has to be a defn.

Comment by Rich Hickey [ 22/Jul/11 3:37 PM ]

I'm taking this. I understand the problem (we were looking at goog.global completely backwards), and a fix will require some language (or at least ns) magic.





[CLJS-558] CLONE - closures act like js not clojure Created: 27/Jul/13  Updated: 27/Jul/13  Resolved: 27/Jul/13

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

Type: Defect Priority: Blocker
Reporter: Anonymous Assignee: Rich Hickey
Resolution: Completed Votes: 0
Labels: None


 Description   

(loop [i 0 j ()]
(if (< i 5)
(recur (inc i) (conj j (fn [] i)))
(map #(%) j)))

In Clojure, this returns: `(4 3 2 1 0)`

In ClojureScript it returns: `(5 5 5 5 5)`

Imported from github issue #85



 Comments   
Comment by David Nolen [ 27/Jul/13 1:45 PM ]

cloned, was resolved





[CLJS-70] Protocols not working in IE8 Created: 10/Sep/11  Updated: 27/Jul/13  Resolved: 23/Sep/11

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

Type: Defect Priority: Blocker
Reporter: Wilkes Joiner Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None
Environment:

IE8


Attachments: Text File fix_for_ie8.patch    
Patch: Code

 Description   

The function generated by defprotocol does not work in IE8. I haven't tried any other versions of IE. The fix is pretty simple, however I don't know the edge cases so consider the patch of a proof of concept.

I'll use IEquiv as an example. The currently generated code is:

cljs.core._equiv = function(a, b) {
return cljs.core.truth_(cljs.core.truth_(a) ? a.cljs$core$IEquiv$_equiv : a) ? a.cljs$core$IEquiv$_equiv(a, b) : function() {
var b = _equiv[goog.typeOf.call(null, a)];
if(cljs.core.truth_(b)) { return b }else {
if(b = equiv., cljs.core.truth_(b)) { return b }else { throw cljs.core.missing_protocol.call(null, "IEquiv.-equiv", a); }
}
}().call(null, a, b)
};

Inside the function the reference to _equiv is unqualified. In IE8, this evaluates to undefined. Using the fully qualified name fixes the issue. So, _equiv[goog.typeOf.call(null, a)] becomes cljs.core._equiv[goog.typeOf.call(null, a)], and equiv. becomes cljs.core.equiv.



 Comments   
Comment by David Nolen [ 23/Sep/11 1:35 AM ]

Fixed, https://github.com/clojure/clojurescript/commit/2c2f49ea9843f4ccc0b440506f8d3fcd93c898bf





[CLJS-42] Function names clash with namespace names Created: 28/Jul/11  Updated: 27/Jul/13  Resolved: 20/Dec/11

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

Type: Defect Priority: Blocker
Reporter: Anthony Simpson Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

Related to this thread: https://groups.google.com/forum/?hl=en#!topic/clojure/AINvE8fUjAM

The issue is that, if you have a namespace called 'foo.core' and a function called 'foo', foo clashes with the namespace inside the generated JavaScript code and results in odd and generally indecipherable errors. Here is some example code that fails:

(def net (node/require "net"))

(defn portal
  [port host] (.createConnection net port host))

(defn -main [& args] ; Note that only one of these -main functions is in the file at any given time, of course.
  (.createConnection net 1337 "localhost"))

(defn -main [& args]
  (portal 1337 "localhost"))

(set! *main-cli-fn* -main)

The first main is the one that works. The second main is a failwhale. Running the second main results in this error:

TypeError: Cannot read property 'net' of undefined
and this generated JavaScript:

portal.core.net = cljs.nodejs.require.call(null, "net");
portal.core.portal = function portal(b, c) {
  return portal.core.net.createConnection(b, c)
};
portal.core._main = function(a) {
  cljs.core.array_seq(Array.prototype.slice.call(arguments, 0), 0);
  return portal.core.portal.call(null, 1337, "localhost")
};

And here is the generated JS for the working -main:

portal.core._main = function(a) {
  cljs.core.array_seq(Array.prototype.slice.call(arguments, 0), 0);
  return portal.core.net.createConnection(1337, "localhost")
};


 Comments   
Comment by David Nolen [ 23/Sep/11 1:21 AM ]

Is this still a problem? I don't see anything in the generated source that looks problematic. Do you have an testable example of the issue that doesn't involve Node?

Comment by David Nolen [ 20/Dec/11 4:26 PM ]

Already resolved





[CLJS-40] Variadic fns fail to convey this Created: 28/Jul/11  Updated: 27/Jul/13  Resolved: 29/Jul/11

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

Type: Defect Priority: Blocker
Reporter: Rich Hickey Assignee: Fogus
Resolution: Completed Votes: 0
Labels: None


 Description   

When used for call, prevents 'this' getting to the bodies in the generated sub-fns. Currently blocking multimethods



 Comments   
Comment by Fogus [ 29/Jul/11 11:31 AM ]

Pushed to master. Frank mentioned that the fix works for his multimethods work.





[CLJS-753] Too many open files exception Created: 28/Jan/14  Updated: 28/Jan/14  Resolved: 28/Jan/14

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

Type: Defect Priority: Blocker
Reporter: Roman Scherer Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: File too-many-open-files.diff    
Patch: Code

 Description   

This patch uses `io/reader` in conjunction with `with-open` to prevent
"too many open files" errors. This happens in a browser REPL when
evaluating a file that references a couple of other files multiple
times.

From the Google Group discussion at: https://groups.google.com/forum/#!topic/clojurescript/r2iGPh2Lv0U

----------------------------

Hello Clojure Scripters,

with my current REPL setup I get some really annoying "Too many
files open" errors. I'm not sure if it's a problem with
ClojureScript itself, Austin the browser REPL, nREPL or my own
miss-configuration of something.

When I connect to the browser REPL via AUSTIN and eval a whole
ClojureScript file the first time a lot of Ajax requests are sent
over the wire and my main namespace is getting compiled and
shipped to the browser. So far so good, my Java process is at
around 18676 open files. I don't care yet.

Compiling the same file again and again increases the open files

not sure if this is a problem with my setup, but I

18676, 19266, 22750, 21352, 33097, 62913, 64398, 64398, 64398,
64398, 64398 up to 171977, where some ulimit is reached and I get
an exception like this:

java.io.FileNotFoundException: .repl/5614/request/routes.js (Too many open files)

and my ClojureScript hangs up and I have to do a
cider-restart. Ok maybe I shouldn't eval whole files too often
over the XHR connection, but this seems not right.

I used the command "lsof -n | grep java | wc -l" to watch the
above numbers while evaluating the file again and again.

Does someone had a similar problem, knows how to solve that, or
has any ideas how to track this one down?

Thanks for your help, Roman.



 Comments   
Comment by Roman Scherer [ 28/Jan/14 5:56 PM ]

Hi David, can you review this. Thanks.

Comment by David Nolen [ 28/Jan/14 6:19 PM ]

Looks good to me will apply soon and test.

Comment by David Nolen [ 28/Jan/14 10:51 PM ]

fixed, https://github.com/clojure/clojurescript/commit/905c64445faa1c60e21b66fb226982759b0d4001





[CLJS-1137] :cljs/quit fails to actually quit Created: 17/Mar/15  Updated: 20/Mar/15  Resolved: 20/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3123
Fix Version/s: 0.0-3196

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

Quick Start Browser REPL (OS X / Safari)



 Description   

If you run through Quick Start through the Browser REPL section (https://github.com/clojure/clojurescript/wiki/Quick-Start#browser-repl), :cljs/quit will hang if a user tries it:

$ rlwrap java -cp cljs.jar:src clojure.main repl.clj
Compiling client js ...
Waiting for browser to connect ...
To quit, type: :cljs/quit
ClojureScript:cljs.user> :cljs/quit

The root problem appears to be agent threads running; here is what a kill -3 shows:

2015-03-17 12:50:25
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.31-b07 mixed mode):

"DestroyJavaVM" #19 prio=5 os_prio=31 tid=0x00007fc9201cf800 nid=0xf07 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"clojure-agent-send-pool-0" #18 prio=5 os_prio=31 tid=0x00007fc9209d8000 nid=0x5e03 waiting on condition [0x0000000129214000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e09bfdf8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007fc91c038800 nid=0x5103 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007fc91b810800 nid=0x4f03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007fc91c822800 nid=0x4d03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007fc91c822000 nid=0x4b03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007fc91c037800 nid=0x4903 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007fc91c03a800 nid=0x3c17 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007fc91c064000 nid=0x3503 in Object.wait() [0x0000000125685000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
	- locked <0x00000006e04631b8> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007fc91c063000 nid=0x3303 in Object.wait() [0x0000000125582000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
	- locked <0x00000006e0184378> (a java.lang.ref.Reference$Lock)

"VM Thread" os_prio=31 tid=0x00007fc91c060800 nid=0x3103 runnable 

"GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007fc91c00e800 nid=0x10f runnable 

"GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007fc91c00f000 nid=0x230f runnable 

"GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007fc91c00f800 nid=0x2503 runnable 

"GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007fc91c010800 nid=0x2703 runnable 

"GC task thread#4 (ParallelGC)" os_prio=31 tid=0x00007fc91c011000 nid=0x2903 runnable 

"GC task thread#5 (ParallelGC)" os_prio=31 tid=0x00007fc91c011800 nid=0x2b03 runnable 

"GC task thread#6 (ParallelGC)" os_prio=31 tid=0x00007fc91c012000 nid=0x2d03 runnable 

"GC task thread#7 (ParallelGC)" os_prio=31 tid=0x00007fc91c013000 nid=0x2f03 runnable 

"VM Periodic Task Thread" os_prio=31 tid=0x00007fc91c07b800 nid=0x5303 waiting on condition 

JNI global references: 76

Heap
 PSYoungGen      total 124928K, used 115712K [0x0000000775580000, 0x000000077d880000, 0x00000007c0000000)
  eden space 115712K, 100% used [0x0000000775580000,0x000000077c680000,0x000000077c680000)
  from space 9216K, 0% used [0x000000077cf80000,0x000000077cf80000,0x000000077d880000)
  to   space 9216K, 0% used [0x000000077c680000,0x000000077c680000,0x000000077cf80000)
 ParOldGen       total 102400K, used 10119K [0x00000006e0000000, 0x00000006e6400000, 0x0000000775580000)
  object space 102400K, 9% used [0x00000006e0000000,0x00000006e09e1dc0,0x00000006e6400000)
 Metaspace       used 21921K, capacity 22079K, committed 22400K, reserved 1067008K
  class space    used 4104K, capacity 4140K, committed 4224K, reserved 1048576K


 Comments   
Comment by Mike Fikes [ 17/Mar/15 11:56 AM ]

A minor correction:

The thread dump in the description was produced with :watch "src" commented out of my repl.clj. Restoring that to adhere to Quick Start produces the same end result, but with additional non-daemon threads:

2015-03-17 12:53:46
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.31-b07 mixed mode):

"DestroyJavaVM" #20 prio=5 os_prio=31 tid=0x00007fc02f155800 nid=0xf07 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Thread-9" #19 daemon prio=5 os_prio=31 tid=0x00007fc02f155000 nid=0x6503 waiting on condition [0x000000012e3be000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007757e8110> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-pool-0" #18 prio=5 os_prio=31 tid=0x00007fc02a6b5000 nid=0x6303 waiting on condition [0x000000012ed01000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e08f4438> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-6" #17 prio=5 os_prio=31 tid=0x00007fc02e17e000 nid=0x6103 waiting on condition [0x000000012e993000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e0500628> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-5" #16 prio=5 os_prio=31 tid=0x00007fc02bc39800 nid=0x5f03 waiting on condition [0x000000012e890000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007757e75f0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
	at java.util.concurrent.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:492)
	at java.util.concurrent.LinkedBlockingDeque.take(LinkedBlockingDeque.java:680)
	at sun.nio.fs.AbstractWatchService.take(AbstractWatchService.java:118)
	at cljs.closure$watch.invoke(closure.clj:1533)
	at cljs.closure$watch.invoke(closure.clj:1487)
	at cljs.repl$repl_STAR_$fn__4003$fn__4006.invoke(repl.clj:753)
	at clojure.core$binding_conveyor_fn$fn__4145.invoke(core.clj:1910)
	at clojure.lang.AFn.call(AFn.java:18)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-4" #15 prio=5 os_prio=31 tid=0x00007fc02e125800 nid=0x5d03 waiting on condition [0x000000012e2bb000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e0500628> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-3" #14 prio=5 os_prio=31 tid=0x00007fc02c95e000 nid=0x5b03 waiting on condition [0x000000012de5d000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e0500628> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-2" #13 prio=5 os_prio=31 tid=0x00007fc02e124800 nid=0x5903 waiting on condition [0x000000012dd5a000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e0500628> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-1" #12 prio=5 os_prio=31 tid=0x00007fc02e1e2800 nid=0x5703 waiting on condition [0x000000012dc57000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e0500628> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"clojure-agent-send-off-pool-0" #11 prio=5 os_prio=31 tid=0x00007fc02c027000 nid=0x5503 waiting on condition [0x000000012ee41000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006e0500628> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

"Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007fc02b816800 nid=0x5103 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007fc02b800800 nid=0x4f03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007fc029894000 nid=0x4d03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007fc029875000 nid=0x4b03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007fc029887000 nid=0x4903 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007fc029886000 nid=0x3c13 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007fc029873800 nid=0x3503 in Object.wait() [0x000000012add9000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
	- locked <0x00000006e00f7988> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007fc029872800 nid=0x3303 in Object.wait() [0x000000012acd6000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
	- locked <0x00000006e0124b90> (a java.lang.ref.Reference$Lock)

"VM Thread" os_prio=31 tid=0x00007fc029870000 nid=0x3103 runnable 

"GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007fc02981e000 nid=0x10f runnable 

"GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007fc02981e800 nid=0x230f runnable 

"GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007fc02981f000 nid=0x2503 runnable 

"GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007fc02981f800 nid=0x2703 runnable 

"GC task thread#4 (ParallelGC)" os_prio=31 tid=0x00007fc029820800 nid=0x2903 runnable 

"GC task thread#5 (ParallelGC)" os_prio=31 tid=0x00007fc029821000 nid=0x2b03 runnable 

"GC task thread#6 (ParallelGC)" os_prio=31 tid=0x00007fc029821800 nid=0x2d03 runnable 

"GC task thread#7 (ParallelGC)" os_prio=31 tid=0x00007fc029822000 nid=0x2f03 runnable 

"VM Periodic Task Thread" os_prio=31 tid=0x00007fc02b817000 nid=0x5303 waiting on condition 

JNI global references: 92

Heap
 PSYoungGen      total 124928K, used 23388K [0x0000000775580000, 0x0000000781880000, 0x00000007c0000000)
  eden space 115712K, 19% used [0x0000000775580000,0x0000000776b973b8,0x000000077c680000)
  from space 9216K, 8% used [0x000000077c680000,0x000000077c740000,0x000000077cf80000)
  to   space 15872K, 0% used [0x0000000780900000,0x0000000780900000,0x0000000781880000)
 ParOldGen       total 100352K, used 10109K [0x00000006e0000000, 0x00000006e6200000, 0x0000000775580000)
  object space 100352K, 10% used [0x00000006e0000000,0x00000006e09df468,0x00000006e6200000)
 Metaspace       used 22439K, capacity 22609K, committed 22656K, reserved 1067008K
  class space    used 4175K, capacity 4207K, committed 4224K, reserved 1048576K
Comment by Mike Fikes [ 17/Mar/15 12:27 PM ]

It would be interesting if there is a clever solution to this. Ambly is currently using an explicit directive in its start script: https://github.com/omcljs/ambly/blob/master/Clojure/script/jscrepljs#L14 which works (https://github.com/omcljs/ambly/blob/master/Clojure/src/ambly/repl/jsc.clj#L217), but is not suitable for use in environments where a user may already have a REPL running that they'd like :cljs/quit to return to.

Comment by David Nolen [ 20/Mar/15 5:23 PM ]

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

Comment by Mike Fikes [ 20/Mar/15 5:35 PM ]

Confirmed fixed for me (with no :watch directive).





[CLJS-1155] REPL :watch support does not play nicely with :cljs/quit Created: 20/Mar/15  Updated: 20/Mar/15  Resolved: 20/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: 0.0-3196

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


 Comments   
Comment by David Nolen [ 20/Mar/15 5:51 PM ]

fixed https://github.com/clojure/clojurescript/commit/501a922a2fd1412503638bedc78a1f5e18b0219c

Comment by Mike Fikes [ 20/Mar/15 6:00 PM ]

Confirmed fixed for me when using browser REPL from Quick Start with :watch "src".





[CLJS-1154] When source-mapping stacktraces, obtain unmunged function names from source map Created: 20/Mar/15  Updated: 21/Mar/15  Resolved: 21/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: 0.0-3196

Type: Enhancement Priority: Blocker
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None
Environment:

All except for, say Node.js, where source mapping is done by the engine


Attachments: Text File CLJS-1154.patch    

 Description   

With CLJS-937 function symbols in stacktraces ended up being munged (for example cljs.core/first appears as cljs$core$first).

The symbol used when making calls is available in source maps (it is the :name element when read in), and it is possible to use this info to improve the stacktraces by using that symbol where possible (which appears to always be possible except for the top-most element in the trace, where the call site info is not there).



 Comments   
Comment by David Nolen [ 21/Mar/15 7:54 AM ]

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





[CLJS-1152] (require 'some.ns :reload) causes printing to stop working in browser REPL Created: 19/Mar/15  Updated: 21/Mar/15  Resolved: 21/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: 0.0-3196

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


 Comments   
Comment by David Nolen [ 20/Mar/15 9:06 AM ]

This root cause is that the compiled browser repl JavaScript also gets reloaded. This occurs because we do not have real require and instead use the ns form to simulate it. What happens is that we emit a new ns form with whatever requires were previously present, the new ones, and add :reload or :reload-all. However this will affect all the namespaces instead of only the ones specified by require. Because of auto-building changing the semantics is likely to be surprising for compilation, however aligning the semantics when at the REPL should be fine.

In order to avoid churn on master while we wait for an enhanced Piggieback release we should try to implement the solution in the least invasive as possible way.

Comment by David Nolen [ 21/Mar/15 10:14 AM ]

Reloading is a transient thing so doing this via metadata is probably not a good idea. Probably the simplest thing to do is to always have REPL require reshape the specs into vectors and add metadata to the vector so that analyzer parse 'ns can extract and leverage this information without polluting the persistent compiler environment.

Comment by David Nolen [ 21/Mar/15 8:09 PM ]

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





[CLJS-1156] load-file fails with :make-reader issue Created: 20/Mar/15  Updated: 22/Mar/15  Resolved: 21/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: 0.0-3196

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

Quick Start, browser REPL (with :watch eliminated from repl.clj), OS X, Chrome,



 Description   

If I try (load-file ...) in the Browser REPL (Quick Start) for a file I've added it fails.

Here is a sample transcript illustrating the issue, followed by successfully using (require ...).

orion:hello_world mfikes$ rlwrap java -cp cljs.jar:src clojure.main repl.clj
Compiling client js ...
Waiting for browser to connect ...
To quit, type: :cljs/quit
ClojureScript:cljs.user> (doc load-file)
-------------------------
load-file
REPL Special Function
  Sequentially read and evaluate the set of forms contained in the file.
nil
ClojureScript:cljs.user> (load-file "src/foo/bar.cljs")
java.lang.IllegalArgumentException: No implementation of method: :make-reader of protocol: #'clojure.java.io/IOFactory found for class: nil
	at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:544)
	at clojure.java.io$fn__8628$G__8610__8635.invoke(io.clj:69)
	at clojure.java.io$reader.doInvoke(io.clj:102)
	at clojure.lang.RestFn.invoke(RestFn.java:410)
	at cljs.analyzer$forms_seq.invoke(analyzer.clj:1957)
	at cljs.analyzer$parse_ns$fn__1485.invoke(analyzer.clj:2011)
	at cljs.analyzer$parse_ns.invoke(analyzer.clj:1998)
	at cljs.analyzer$parse_ns.invoke(analyzer.clj:1989)
	at cljs.closure$src_file__GT_target_file.invoke(closure.clj:1580)
	at cljs.closure$src_file__GT_target_file.invoke(closure.clj:1575)
	at cljs.repl$load_file.invoke(repl.clj:467)
	at cljs.repl$fn__3938$self__3940.invoke(repl.clj:540)
	at cljs.repl$repl_STAR_$read_eval_print__4004.invoke(repl.clj:745)
	at cljs.repl$repl_STAR_$fn__4010$fn__4017.invoke(repl.clj:785)
	at cljs.repl$repl_STAR_$fn__4010.invoke(repl.clj:784)
	at cljs.compiler$with_core_cljs.invoke(compiler.clj:950)
	at cljs.repl$repl_STAR_.invoke(repl.clj:749)
	at cljs.repl$repl.doInvoke(repl.clj:866)
	at clojure.lang.RestFn.invoke(RestFn.java:439)
	at user$eval30.invoke(repl.clj:10)
	at clojure.lang.Compiler.eval(Compiler.java:6703)
	at clojure.lang.Compiler.load(Compiler.java:7130)
	at clojure.lang.Compiler.loadFile(Compiler.java:7086)
	at clojure.main$load_script.invoke(main.clj:274)
	at clojure.main$script_opt.invoke(main.clj:336)
	at clojure.main$main.doInvoke(main.clj:420)
	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)
ClojureScript:cljs.user> (load-file "/Users/mfikes/Desktop/hello_world/src/foo/bar.cljs")
java.lang.IllegalArgumentException: No implementation of method: :make-reader of protocol: #'clojure.java.io/IOFactory found for class: nil
	at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:544)
	at clojure.java.io$fn__8628$G__8610__8635.invoke(io.clj:69)
	at clojure.java.io$reader.doInvoke(io.clj:102)
	at clojure.lang.RestFn.invoke(RestFn.java:410)
	at cljs.analyzer$forms_seq.invoke(analyzer.clj:1957)
	at cljs.analyzer$parse_ns$fn__1485.invoke(analyzer.clj:2011)
	at cljs.analyzer$parse_ns.invoke(analyzer.clj:1998)
	at cljs.analyzer$parse_ns.invoke(analyzer.clj:1989)
	at cljs.closure$src_file__GT_target_file.invoke(closure.clj:1580)
	at cljs.closure$src_file__GT_target_file.invoke(closure.clj:1575)
	at cljs.repl$load_file.invoke(repl.clj:467)
	at cljs.repl$fn__3938$self__3940.invoke(repl.clj:540)
	at cljs.repl$repl_STAR_$read_eval_print__4004.invoke(repl.clj:745)
	at cljs.repl$repl_STAR_$fn__4010$fn__4017.invoke(repl.clj:785)
	at cljs.repl$repl_STAR_$fn__4010.invoke(repl.clj:784)
	at cljs.compiler$with_core_cljs.invoke(compiler.clj:950)
	at cljs.repl$repl_STAR_.invoke(repl.clj:749)
	at cljs.repl$repl.doInvoke(repl.clj:866)
	at clojure.lang.RestFn.invoke(RestFn.java:439)
	at user$eval30.invoke(repl.clj:10)
	at clojure.lang.Compiler.eval(Compiler.java:6703)
	at clojure.lang.Compiler.load(Compiler.java:7130)
	at clojure.lang.Compiler.loadFile(Compiler.java:7086)
	at clojure.main$load_script.invoke(main.clj:274)
	at clojure.main$script_opt.invoke(main.clj:336)
	at clojure.main$main.doInvoke(main.clj:420)
	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)
ClojureScript:cljs.user> (require 'foo.bar)
nil
ClojureScript:cljs.user> (ns-interns 'foo.bar)
{six #'foo.bar/six, two! #'foo.bar/two!, one #'foo.bar/one, eight #'foo.bar/eight, five' #'foo.bar/five', four #'foo.bar/four, nine #'foo.bar/nine, seven #'foo.bar/seven, three* #'foo.bar/three*}


 Comments   
Comment by Mike Fikes [ 20/Mar/15 9:37 PM ]

I'm not familiar with the way load-file is supposed work. I used the fully-qualified path, because that's what I saw Cursive do. I tried a path relative to the source directory, and this does't balk, but doesn't work either:

ClojureScript:cljs.user> (load-file "foo/bar.cljs")
nil
ClojureScript:cljs.user> (ns-interns 'foo.bar)
{}
Comment by Mike Fikes [ 20/Mar/15 9:40 PM ]

(I apologize for the ticket noise.)

The relative path does work in that the symbols are loaded into the browser JavaScript engine, while ns-interns is not updated:

orion:hello_world mfikes$ rlwrap java -cp cljs.jar:src clojure.main repl.clj
Compiling client js ...
Waiting for browser to connect ...
To quit, type: :cljs/quit
ClojureScript:cljs.user> (foo.bar/nine)
WARNING: Use of undeclared Var foo.bar/nine at line 1 <cljs repl>
ReferenceError: foo is not defined
ReferenceError: foo is not defined
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:1:89)
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:9:3)
    at eval (eval at <anonymous> (http://localhost:9000/out/clojure/browser/repl.js:42:272), <anonymous>:14:4)
    at http://localhost:9000/out/clojure/browser/repl.js:42:267
    at clojure$browser$repl$evaluate_javascript (http://localhost:9000/out/clojure/browser/repl.js:45:4)
    at Object.callback (http://localhost:9000/out/clojure/browser/repl.js:242:169)
    at goog.messaging.AbstractChannel.deliver (http://localhost:9000/out/goog/messaging/abstractchannel.js:142:13)
    at goog.net.xpc.CrossPageChannel.xpcDeliver (http://localhost:9000/out/goog/net/xpc/crosspagechannel.js:733:12)
    at Function.goog.net.xpc.NativeMessagingTransport.messageReceived_ (http://localhost:9000/out/goog/net/xpc/nativemessagingtransport.js:321:13)
    at Object.goog.events.fireListener (http://localhost:9000/out/goog/events/events.js:741:21)
ClojureScript:cljs.user> (load-file "foo/bar.cljs")
nil
ClojureScript:cljs.user> (foo.bar/nine)
WARNING: Use of undeclared Var foo.bar/nine at line 1 <cljs repl>
Error: 1 is not ISeqable
	 cljs$core$seq (out/cljs/core.cljs:951:13)
	 cljs$core$first (out/cljs/core.cljs:960:7)
	 cljs$core$ffirst (out/cljs/core.cljs:1393:3)
	 foo$bar$one (out/foo/bar.cljs:7:14)
	 foo$bar$two_BANG_ (out/foo/bar.cljs:9:15)
	 foo$bar$three_STAR_ (out/foo/bar.cljs:11:17)
	 foo$bar$four (out/foo/bar.cljs:13:15)
	 foo$bar$five_SINGLEQUOTE_ (out/foo/bar.cljs:16:16)
	 foo$bar$six (out/foo/bar.cljs:20:2)
ClojureScript:cljs.user> (ns-interns 'foo.bar)
{}

(The exception thrown from foo.bar/nine is expected... I was testing stacktraces with this namespace earlier.)

Comment by David Nolen [ 21/Mar/15 8:46 PM ]

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

Comment by Mike Fikes [ 22/Mar/15 9:05 AM ]

Confirmed fixed in master.





[CLJS-1161] Use higher-level binding of *cljs-ns*, REPL stack traces not printing to *err* Created: 23/Mar/15  Updated: 23/Mar/15  Resolved: 23/Mar/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: 0.0-3196

Type: Enhancement Priority: Blocker
Reporter: Chas Emerick Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

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

 Comments   
Comment by Chas Emerick [ 23/Mar/15 12:18 PM ]

Patch attached. Not printing to *err* was probably just an oversight; being able to rebind *cljs-ns* at a higher level enables user-facing REPL utilities other than cljs.repl/repl.

Comment by David Nolen [ 23/Mar/15 12:21 PM ]

fixed https://github.com/clojure/clojurescript/commit/4a3737bbe8de30081c9aef1ec15f8aae9065a1b6





[CLJS-1187] var ast contains internal nodes with bad analysis :context Created: 02/Apr/15  Updated: 03/Apr/15  Resolved: 03/Apr/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3126
Fix Version/s: 0.0-3196

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


 Description   
(defn foo [] (print "foo!"))
 
(defn bar [] (print "bar!"))
 
(defn print-foo [fb]
  (apply 
    (case fb
      :foo #'foo
      :bar #'bar) []))


 Comments   
Comment by David Nolen [ 03/Apr/15 5:50 AM ]

fixed https://github.com/clojure/clojurescript/commit/49ed83337baf762ef21a907be234ebdbcc105d66





[CLJS-1260] >= 0.0-3265 cannot compile Closure style libraries that conform to the classpath Created: 09/May/15  Updated: 09/May/15  Resolved: 09/May/15

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

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


 Comments   
Comment by David Nolen [ 09/May/15 3:48 PM ]

fixed https://github.com/clojure/clojurescript/commit/4f8d24cf5f857bf114e09535cfbb0f5db17326a9





[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-2193] :npm-deps dependencies are implicit Created: 08/Jul/17  Updated: 08/Jul/17  Resolved: 08/Jul/17

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

Type: Defect Priority: Blocker
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: npm-deps

Attachments: Text File CLJS-2193.patch    
Patch: Code
Approval: Accepted

 Description   

Currently the Node dependencies for `:npm-deps` to work are implicit. Looking `cljs/module_deps.js` it's clear that at least `module-deps`, `resolve`, and `browserResolve` must exist. This should probably be handled transparently for the user.



 Comments   
Comment by David Nolen [ 08/Jul/17 9:52 AM ]

On my local machine at least I had to install these manually. I think this should probably be handled for the user?

Comment by David Nolen [ 08/Jul/17 12:09 PM ]

Even after manually installing all the necessary deps if I try to run just the `test-npm-deps` test by itself on master I get the following stacktrace from Node.js:

module.js:471
    throw err;
    ^

Error: Cannot find module 'resolve'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at [eval]:3:19
    at ContextifyScript.Script.runInThisContext (vm.js:25:33)
    at Object.runInThisContext (vm.js:97:38)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (module.js:570:32)
    at evalScript (bootstrap_node.js:353:27)
Comment by David Nolen [ 08/Jul/17 2:08 PM ]

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





[CLJS-1800] Defer to tools.reader for cljs.reader functionality Created: 30/Sep/16  Updated: 08/Jul/17  Resolved: 08/Jul/17

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

Type: Enhancement Priority: Blocker
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Approval: Vetted

 Description   

We already have a dependency on tools.reader and maintaining our own EDN reader is just an unnecessary burden.



 Comments   
Comment by Aleš Roubíček [ 02/Oct/16 1:02 AM ]

I'm fiddling with this and found two differences in reading (according to cljs.reader-tests):

  1. cljs.tools.reader reads the @ macro as 'clojure.core/deref instead of 'deref
  2. cljs.tools.reader does not read small maps as PersistentArrayMap

Shoud this be solved by patching cljs.tools.reader or by changing cljs.reader-tests?

Comment by David Nolen [ 04/Oct/16 1:35 PM ]

Questions should be asked about 2). 1) seems fine.

Comment by Rohit Aggarwal [ 05/Oct/16 4:11 AM ]

I think fixing cljs.tools.reader/read-map to return a PersistentArrayMap or a PersistentHashMap is a relatively easy fix and should be raised in TRDR bug tracker.

Comment by Aleš Roubíček [ 26/Oct/16 7:04 AM ]

I did the patch for cljs.tools.reader http://dev.clojure.org/jira/browse/TRDR-40

Comment by David Nolen [ 08/Jul/17 4:39 PM ]

fixed https://github.com/clojure/clojurescript/commit/07ee2250af02b25f232111890c0f40f23150768d





[CLJS-2059] Printing a namespaced qualified map and reading it back to ClojureScript fails Created: 29/May/17  Updated: 08/Jul/17  Resolved: 08/Jul/17

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

Type: Defect Priority: Blocker
Reporter: Michiel Borkent Assignee: Unassigned
Resolution: Completed Votes: 2
Labels: None


 Description   

Example:

`(cljs.reader/read-string (pr-str {:foo/id "foo" :foo/bar "bar"}))`

fails with

#object[Error Error: Could not find tag parser for :foo in ("inst" "uuid" "queue" "js")]
Error: Could not find tag parser for :foo in ("inst" "uuid" "queue" "js")

This fails in 1.9.542 but I could not choose that version from the dropdown.



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

Related to CLJS-1800

Comment by António Nuno Monteiro [ 08/Jul/17 2:24 PM ]

https://github.com/clojure/clojurescript/pull/69 (CLJS-1800) fixes this one





[CLJS-2152] "is not a relative path" exception thrown when `:libs` directory is provided. Created: 02/Jul/17  Updated: 08/Jul/17  Resolved: 08/Jul/17

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

Type: Defect Priority: Blocker
Reporter: Bruce Hauman Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: build
Environment:

OSX


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

 Description   

This problem shows up in this simple case:

In the compiler config set :libs to ["js_libs"]

Create a GCL file in "js_libs"

goog.provide("tabby");

tabby.hello = function() {return "hello there from tabby";};

In the main cljs file require the GCL lib:

(ns example.core
  (:require [tabby]))

This should produce the following stacktrace:

java.lang.IllegalArgumentException: /tabby.js is not a relative path
 at clojure.java.io$as_relative_path.invokeStatic (io.clj:414)
    clojure.java.io$file.invokeStatic (io.clj:426)
    clojure.java.io$file.invoke (io.clj:418)
    cljs.closure$write_javascript.invokeStatic (closure.clj:1658)
    cljs.closure$write_javascript.invoke (closure.clj:1651)
    cljs.closure$source_on_disk.invokeStatic (closure.clj:1697)
    cljs.closure$source_on_disk.invoke (closure.clj:1692)
    cljs.closure$output_unoptimized$fn__13956.invoke (closure.clj:1735)
    clojure.core$map$fn__4785.invoke (core.clj:2646)
    clojure.lang.LazySeq.sval (LazySeq.java:40)
    clojure.lang.LazySeq.seq (LazySeq.java:49)
    clojure.lang.RT.seq (RT.java:521)
    clojure.core$seq__4357.invokeStatic (core.clj:137)
    clojure.core$filter$fn__4812.invoke (core.clj:2700)
    clojure.lang.LazySeq.sval (LazySeq.java:40)
    clojure.lang.LazySeq.seq (LazySeq.java:49)
    clojure.lang.RT.seq (RT.java:521)
    clojure.core$seq__4357.invokeStatic (core.clj:137)
    clojure.core$map$fn__4785.invoke (core.clj:2637)
    clojure.lang.LazySeq.sval (LazySeq.java:40)
    clojure.lang.LazySeq.seq (LazySeq.java:49)
    clojure.lang.Cons.next (Cons.java:39)
    clojure.lang.RT.next (RT.java:688)
    clojure.core$next__4341.invokeStatic (core.clj:64)
    clojure.core$str$fn__4419.invoke (core.clj:546)
    clojure.core$str.invokeStatic (core.clj:544)
    clojure.core$str.doInvoke (core.clj:533)
    clojure.lang.RestFn.applyTo (RestFn.java:139)
    clojure.core$apply.invokeStatic (core.clj:646)
    clojure.core$apply.invoke (core.clj:641)
    cljs.closure$deps_file.invokeStatic (closure.clj:1433)
    cljs.closure$deps_file.invoke (closure.clj:1430)
    cljs.closure$output_deps_file.invokeStatic (closure.clj:1453)
    cljs.closure$output_deps_file.invoke (closure.clj:1452)
    cljs.closure$output_unoptimized.invokeStatic (closure.clj:1743)
    cljs.closure$output_unoptimized.doInvoke (closure.clj:1726)
    clojure.lang.RestFn.applyTo (RestFn.java:139)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$apply.invoke (core.clj:641)
    cljs.closure$build.invokeStatic (closure.clj:2352)
    cljs.closure$build.invoke (closure.clj:2236)
    cljs.build.api$build.invokeStatic (api.clj:202)
    cljs.build.api$build.invoke (api.clj:189)


 Comments   
Comment by Francis Avila [ 02/Jul/17 8:35 PM ]

I ran in to this issue on a large, complex project which I was upgrading from 1.8.51 to a few commits short of 1.9.655. However, I never created a minimal case. Some more information I can add:

  1. This is a regression since 1.8.51.
  2. I experienced this on a project where :libs and :src were the same. (Cljs and goog-compatible js were intermingled in same source root.) I thought that might have been relevant but it looks like it is not.
  3. The length of the goog-provided namespace does not matter. (One segment and many-segment both fail.)
  4. A workaround is to include the full path to the goog file in :libs. For example, {{:libs ["js_libs/tabby.js"] }} will not fail. This is the workaround I used in my project.
Comment by David Nolen [ 08/Jul/17 9:21 AM ]

The patch must supply a test.

Comment by António Nuno Monteiro [ 08/Jul/17 2:14 PM ]

Patch attached.

Comment by Martin Klepsch [ 08/Jul/17 3:44 PM ]

Tested the patch with cljsjs/incremental-dom. Working as advertised 👍

FWIW, in contrast to Francis' observations I thought this only affected :libs with single segment goog.provide names. After stumbling into this with incremental-dom I tried to reproduce it with openlayers but I couldn't reproduce the issue there.

Comment by David Nolen [ 08/Jul/17 4:48 PM ]

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





[CLJS-2179] Add test for preprocess JS module as symbol Created: 05/Jul/17  Updated: 08/Jul/17  Resolved: 08/Jul/17

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

Type: Task Priority: Blocker
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: js-modules, newbie

Attachments: Text File CLJS-2179.patch    
Approval: Accepted

 Comments   
Comment by António Nuno Monteiro [ 08/Jul/17 2:21 PM ]

Patch with tests attached.

Comment by David Nolen [ 08/Jul/17 4:55 PM ]

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





[CLJS-1959] under :nodejs target we should provide __dirname and __filename constants Created: 27/Feb/17  Updated: 09/Jul/17  Resolved: 09/Jul/17

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

Type: Defect Priority: Blocker
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 1
Labels: nodejs

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

 Comments   
Comment by David Nolen [ 08/Jul/17 9:22 AM ]

The current patch does not work. Also the patch must supply a test to be accepted.

Comment by David Nolen [ 09/Jul/17 8:52 AM ]

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





[CLJS-2199] String requires broken after recompile Created: 09/Jul/17  Updated: 09/Jul/17  Resolved: 09/Jul/17

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

Type: Defect Priority: Blocker
Reporter: Juho Teperi Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: js-modules, npm-deps

Approval: Vetted

 Description   

String requires uses js-module-exists? to check if module needs to loaded: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L722

It checks the compiler state for :js-module-index.

The first time e.g. react-dom/server is not found.

If using the same compiler state for recompile, the second time the module is already present in compiler-state.

This means that the module is not indexed into foreign-libs: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L2043

Result is that cljs_deps.js won't have the line for react-dom/sever or No such namespace exception about react-dom$server.



 Comments   
Comment by David Nolen [ 09/Jul/17 12:21 PM ]

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





[CLJS-2202] String requires not working from files in classpath Created: 09/Jul/17  Updated: 09/Jul/17  Resolved: 09/Jul/17

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

Type: Defect Priority: Blocker
Reporter: Juho Teperi Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: js-modules, npm-deps

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

 Comments   
Comment by David Nolen [ 09/Jul/17 3:13 PM ]

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





[CLJS-2203] REPL is turning on all warnings by default (including :invalid-array-access) Created: 09/Jul/17  Updated: 10/Jul/17  Resolved: 10/Jul/17

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

Type: Defect Priority: Blocker
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: repl

Attachments: Text File CLJS-2203.patch    
Patch: Code
Approval: Accepted

 Description   

If you fire up a REPL and evaluate (aget #js {:foo 1} "foo") you will see the aget warning. This is because the REPL initialization code assumes that if the compiler options doesn't include warnings, that it should assume the same as :warnings true.



 Comments   
Comment by David Nolen [ 10/Jul/17 4:57 AM ]

fixed https://github.com/clojure/clojurescript/commit/149724bcb28c44bf331ff96c813c0c3aba287b0f





[CLJS-2200] bump to tools.reader 1.0.2 Created: 09/Jul/17  Updated: 11/Jul/17  Resolved: 11/Jul/17

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

Type: Task Priority: Blocker
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: reader

Approval: Accepted

 Description   

We should bring back any relevant tests when this is done.



 Comments   
Comment by David Nolen [ 11/Jul/17 6:42 AM ]

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





[CLJS-2211] Add function to index a top-level node_modules installation Created: 11/Jul/17  Updated: 11/Jul/17  Resolved: 11/Jul/17

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

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

Attachments: Text File CLJS-2211.patch    
Patch: Code and Test
Approval: Vetted

 Description   

This is a pre-requisite for CLJS-2206



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

fixed https://github.com/clojure/clojurescript/commit/921b2630804b387f342e54a711e220a1cf8ff0c6





[CLJS-2212] Replace missing-js-modules with new index-node-module-dir Created: 11/Jul/17  Updated: 11/Jul/17  Resolved: 11/Jul/17

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

Type: Enhancement Priority: Blocker
Reporter: Juho Teperi Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: js-modules, npm-deps

Attachments: Text File CLJS-2212.patch    
Patch: Code
Approval: Accepted

 Comments   
Comment by David Nolen [ 11/Jul/17 5:32 PM ]

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





[CLJS-2214] :global-exports for foreign libraries Created: 11/Jul/17  Updated: 12/Jul/17  Resolved: 12/Jul/17

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

Type: Task Priority: Blocker
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: foreign-libs, migration

Attachments: Text File CLJS-2214-2.patch     Text File CLJS-2214.patch    
Approval: Accepted

 Description   

To make foreign libraries more idiomatic to use and in order to ease future migration to direct node_modules usage users need a way to define what global exports a foreign lib provides. Regular foreign libraries export global names and the requires are synthetic. We can fix this issue by allowing foreign libraries to describe what they globally export.

{:file ...
 :file-min ...
 :requires [...]
 :provides [...]
 :global-exports '{cljsjs.react React 
                   cljsjs.react/dom-server ReactDOMServer}} ;; map :provides to a :require'able name


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

`global$module$` for the module name please. And lets lift out some helpers to make this cleaner.

Comment by David Nolen [ 12/Jul/17 4:48 PM ]

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





[CLJS-2220] Add runtime :npm-deps tests Created: 12/Jul/17  Updated: 13/Jul/17  Resolved: 13/Jul/17

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

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

Attachments: Text File CLJS-2220.patch    
Approval: Accepted

 Comments   
Comment by David Nolen [ 13/Jul/17 12:08 PM ]

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





[CLJS-2218] Make ClojureScript aware of native node modules Created: 12/Jul/17  Updated: 13/Jul/17  Resolved: 13/Jul/17

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

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

Attachments: Text File CLJS-2218.patch    
Patch: Code and Test
Approval: Vetted

 Comments   
Comment by David Nolen [ 13/Jul/17 12:12 PM ]

fixed https://github.com/clojure/clojurescript/commit/6530e0d0da91d6a5f324ae4b86ca1d2d208c40d9





[CLJS-2217] Support `:rename` for JS modules Created: 12/Jul/17  Updated: 13/Jul/17  Resolved: 13/Jul/17

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

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

Attachments: Text File CLJS-2217.patch    
Patch: Code and Test
Approval: Vetted

 Description   

This may just work when target is not `:nodejs`, need to add a test for that case.



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

Attached patch with fix. This patch should be applied after CLJS-2220 which adds a namespace for runtime testing of npm-deps, and relies on it.

Comment by António Nuno Monteiro [ 12/Jul/17 11:10 PM ]

Patch also contains a small refactoring that addresses the fact that we were accessing `(-> env :ns :name)` several times when we could just bind it in a `let` block.

Comment by David Nolen [ 13/Jul/17 8:03 AM ]

Noting that there is no test for `:rename` `:global-exports` case. Can either take an augmented patch, or I will look into adding it after this one is applied.

Comment by António Nuno Monteiro [ 13/Jul/17 11:36 AM ]

Replaced the patch with one that also tests global exports.

Comment by David Nolen [ 13/Jul/17 12:22 PM ]

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





[CLJS-2224] resolve-var is wrong wrt. module resolution Created: 13/Jul/17  Updated: 13/Jul/17  Resolved: 13/Jul/17

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

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

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

 Description   

core names & user-defined vars should take precedence over modules called as functions



 Comments   
Comment by David Nolen [ 13/Jul/17 4:44 PM ]

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





[CLJS-2226] :npm-deps can't index scoped packages Created: 13/Jul/17  Updated: 13/Jul/17  Resolved: 13/Jul/17

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

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

Attachments: Text File CLJS-2226.patch    
Patch: Code and Test
Approval: Vetted

 Comments   
Comment by David Nolen [ 13/Jul/17 4:47 PM ]

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





[CLJS-2225] Need to add :checked-arrays to known compiler opts Created: 13/Jul/17  Updated: 13/Jul/17  Resolved: 13/Jul/17

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

Type: Defect Priority: Blocker
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: closure

Attachments: Text File CLJS-2225.patch    
Patch: Code
Approval: Accepted

 Description   

So, for example the compiler will warn if you misspell:

WARNING: Unknown compiler option ':checked-array'. Did you mean ':checked-arrays'?


 Comments   
Comment by David Nolen [ 13/Jul/17 4:48 PM ]

fixed https://github.com/clojure/clojurescript/commit/2247b0c2be4f2900bebfb544fea18ea3ed58f540





[CLJS-2213] Node.js target should use node_modules index to emit platform specific require Created: 11/Jul/17  Updated: 13/Jul/17  Resolved: 12/Jul/17

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

Type: Task Priority: Blocker
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: nodejs

Attachments: Text File CLJS-2213.patch    
Approval: Vetted

 Description   

Previously users had to require files differently when targeting Node.js. With CLJS-2211 we can now have an index of top level node_modules finally allowing us to require Node.js files in an idiomatic fashion.



 Comments   
Comment by António Nuno Monteiro [ 12/Jul/17 1:43 AM ]

Attached patch + tests.

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

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

Comment by David Nolen [ 12/Jul/17 7:00 AM ]

One potential issue with this patch is that it reverts CLJS-2151, https://github.com/clojure/clojurescript/commit/addaf39e861191dab6aeb0189c66f5f6ef132918.

Comment by David Nolen [ 12/Jul/17 7:05 AM ]

Oh the other thing I noticed is that `:rename` feature doesn't appear to be supported for Node libs?





[CLJS-2228] Port CLJS-2226 to module_deps.js Created: 13/Jul/17  Updated: 13/Jul/17  Resolved: 13/Jul/17

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

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

Attachments: Text File CLJS-2228.patch    
Approval: Accepted

 Comments   
Comment by David Nolen [ 13/Jul/17 5:25 PM ]

fixed https://github.com/clojure/clojurescript/commit/26fb6b1f19d0b698c7720c3140f107fa360fd7fe





[CLJS-2232] Self-host: Add support for string-based requires Created: 14/Jul/17  Updated: 14/Jul/17  Resolved: 14/Jul/17

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

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

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

 Comments   
Comment by António Nuno Monteiro [ 14/Jul/17 12:43 AM ]

Patch attached.

Comment by David Nolen [ 14/Jul/17 5:57 AM ]

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





[CLJS-2240] don't shell out to module_deps.js if `:npm-deps` not specified Created: 14/Jul/17  Updated: 14/Jul/17  Resolved: 14/Jul/17

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

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

Attachments: Text File CLJS-2240.patch    
Patch: Code
Approval: Accepted

 Comments   
Comment by David Nolen [ 14/Jul/17 1:56 PM ]

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





[CLJS-2238] Perf regression with node module indexing Created: 14/Jul/17  Updated: 14/Jul/17  Resolved: 14/Jul/17

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

Type: Defect Priority: Blocker
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: js-modules, npm-deps, performance

Attachments: Text File CLJS-2238.patch    
Patch: Code
Approval: Accepted

 Description   

On master, I'm observing that, using Figwheel, changes to source take about 12 seconds to appear in a React Native app running in an iOS simulator, whereas with the 1.9.671 such changes take about 2 seconds.

I apologize for not having a minimal repro available. I suspect it is easily reproducible locally using a setup generated using re-natal init FutureApp (see https://github.com/drapanjanas/re-natal)

Of note: I don't have :npm-deps set. My compiler options are:

{:output-to     "target/ios/not-used.js"
 :main          "env.ios.main"
 :output-dir    "target/ios"
 :optimizations :none
 :checked-arrays false 
 :warnings      true}

A git bisect shows that this was introduced with the change in CLJS-2212.



 Comments   
Comment by Mike Fikes [ 14/Jul/17 1:26 PM ]

For reference, in handle-js-modules the top-level set ends up having 14748 elements, and it does appear to take about 12 seconds to produce that number.

My requires set has 77 elements and the node-required (the intersection) has 0 elements.

Comment by David Nolen [ 14/Jul/17 2:03 PM ]

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

Comment by Mike Fikes [ 14/Jul/17 2:04 PM ]

With the patch, changes appear in about 2 seconds.





[CLJS-2229] Ensure that new modules work works correctly with REPLs Created: 13/Jul/17  Updated: 14/Jul/17  Resolved: 14/Jul/17

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

Type: Task Priority: Blocker
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: js-modules, repl

Approval: Accepted

 Description   

We need to audit the new features and ensure they work out of the box for various REPLs. Even a cursory glance shows that we don't index node modules.



 Comments   
Comment by David Nolen [ 14/Jul/17 5:04 PM ]

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





[CLJS-2241] Multiple requires of Node.js modules in non :nodejs target are not idempotent at the REPL Created: 14/Jul/17  Updated: 14/Jul/17  Resolved: 14/Jul/17

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

Type: Defect Priority: Blocker
Reporter: David Nolen Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: js-modules, repl

Approval: Vetted

 Description   

Given the following setup:

(require '[cljs.repl :as r])
(require '[cljs.repl.browser :as rb])

(def opts
  {:browser-repl true
   :verbose true
   :npm-deps {"lodash" "4.17.4"}})

(r/repl* (rb/repl-env) opts)

Under a REPL when the target is not the Node.js the following behavior is observed:

(require '["lodash/array" :as lodash-array])

Will succeed the first time. The same require a second time produce the following stack trace:

clojure.lang.ExceptionInfo: No such namespace: module$Users$davidnolen$development$clojure$hello-world$node-modules$lodash$array, could not locate module$Users$davidnolen$development$clojure$hello_world$node_modules$lodash$array.cljs, module$Users$davidnolen$development$clojure$hello_world$node_modules$lodash$array.cljc, or JavaScript providing "module$Users$davidnolen$development$clojure$hello-world$node-modules$lodash$array" at line 1 <cljs repl> {:file "<cljs repl>", :line 1, :column 1, :root-source-info {:source-type :fragment, :source-form (require (quote ["lodash/array" :as lodash-array]))}, :tag :cljs/analysis-error}
	at clojure.core$ex_info.invokeStatic(core.clj:4617)
	at cljs.analyzer$error.invokeStatic(analyzer.cljc:690)
	at cljs.analyzer$error.invoke(analyzer.cljc:690)
	at cljs.analyzer$error.invokeStatic(analyzer.cljc:692)
	at cljs.analyzer$analyze_deps.invokeStatic(analyzer.cljc:2111)
	at cljs.analyzer$ns_side_effects.invokeStatic(analyzer.cljc:3430)
	at cljs.analyzer$ns_side_effects.invoke(analyzer.cljc:3424)
	at cljs.analyzer$analyze_STAR_$fn__2393.invoke(analyzer.cljc:3546)
	at clojure.lang.PersistentVector.reduce(PersistentVector.java:341)
	at clojure.core$reduce.invokeStatic(core.clj:6544)
	at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:3543)
	at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:3569)
	at cljs.analyzer$analyze.invoke(analyzer.cljc:3553)
	at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:3350)
	at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:3498)
	at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:3543)
	at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:3569)
	at cljs.repl$evaluate_form$fn__6113.invoke(repl.cljc:496)
	at cljs.repl$evaluate_form.invokeStatic(repl.cljc:496)
	at cljs.repl$eval_cljs.invokeStatic(repl.cljc:616)
	at cljs.repl$eval_cljs.invoke(repl.cljc:603)
	at cljs.repl$repl_STAR_$read_eval_print__6234.invoke(repl.cljc:865)
	at cljs.repl$repl_STAR_$fn__6240$fn__6249.invoke(repl.cljc:905)
	at cljs.repl$repl_STAR_$fn__6240.invoke(repl.cljc:904)
	at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1224)
	at cljs.repl$repl_STAR_.invokeStatic(repl.cljc:841)
	at cljs.repl$repl_STAR_.invoke(repl.cljc:745)
	at user$eval1109.invokeStatic(repl.clj:19)
	at user$eval1109.invoke(repl.clj:19)
	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)


 Comments   
Comment by David Nolen [ 14/Jul/17 5:32 PM ]

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

Comment by Mike Fikes [ 14/Jul/17 8:04 PM ]

Regression for this commit tracked in CLJS-2242





[CLJS-2242] Lots of undeclared Var warns in cljs.spec.gen.alpha Created: 14/Jul/17  Updated: 15/Jul/17  Resolved: 15/Jul/17

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

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


 Description   

I saw this with the browser REPL in Quick Start, but it is also easy to repro with script/noderepljs:

orion:(master)clojurescript$ script/noderepljs
ClojureScript Node.js REPL server listening on 49628
WARNING: Use of undeclared Var cljs.spec.alpha/get-spec at line 52 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/repl.cljs
WARNING: Use of undeclared Var cljs.spec.alpha/describe at line 56 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/repl.cljs
WARNING: Use of undeclared Var cljs.spec.alpha/describe at line 56 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/repl.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/such-that at line 277 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/delay-impl at line 442 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/bind at line 448 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/choose at line 448 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/hash-map at line 453 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/gen-for-pred at line 491 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/delay-impl at line 532 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/fmap at line 533 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/one-of at line 541 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/tuple at line 603 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/delay-impl at line 672 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/one-of at line 676 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/fmap at line 788 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/tuple at line 790 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/bind at line 894 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/return at line 896 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/fmap at line 897 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/return at line 899 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/fmap at line 901 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/vector-distinct at line 906 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/vector-distinct at line 907 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/vector at line 912 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/vector at line 915 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/vector at line 918 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/delay-impl at line 1176 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/fmap at line 1181 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/fmap at line 1181 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/return at line 1188 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/return at line 1189 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/fmap at line 1191 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/cat at line 1195 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/one-of at line 1198 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/return at line 1200 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/fmap at line 1202 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/vector at line 1203 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/for-all* at line 1286 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/quick-check at line 1287 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/return at line 1329 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/generate at line 1332 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/frequency at line 1380 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/delay-impl at line 1381 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/return at line 1381 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/delay-impl at line 1382 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
WARNING: Use of undeclared Var cljs.spec.gen.alpha/sample at line 1393 /Users/mfikes/Projects/clojurescript/src/main/cljs/cljs/spec/alpha.cljs
To quit, type: :cljs/quit


 Comments   
Comment by Mike Fikes [ 14/Jul/17 8:02 PM ]
3cf960bb161d8c5fd75b046a4a119d9d0f645409 is the first bad commit
commit 3cf960bb161d8c5fd75b046a4a119d9d0f645409
Author: dnolen <dnolen@cognitect.com>
Date:   Fri Jul 14 18:31:45 2017 -0400

    CLJS-2241: Multiple requires of Node.js modules in non :nodejs target are not idempotent at the REPL

    leave a comment about module subtlely, drop unneeded analyze

:040000 040000 c3fa69586da025b5ee7599d9a8ad3d50361b8699 a569843f2f91d8d7da5d180c15126b3c2ed4f5eb M	src
Comment by David Nolen [ 15/Jul/17 8:12 AM ]

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





[CLJS-2243] Self-host: Add support for :global-exports Created: 15/Jul/17  Updated: 15/Jul/17  Resolved: 15/Jul/17

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

Type: Enhancement Priority: Blocker
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap, foreign-libs

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

 Comments   
Comment by David Nolen [ 15/Jul/17 8:14 AM ]

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





[CLJS-2249] Regression with foreign-libs under Node.js Created: 15/Jul/17  Updated: 15/Jul/17  Resolved: 15/Jul/17

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

Type: Defect Priority: Blocker
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: foreign-libs

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

 Comments   
Comment by António Nuno Monteiro [ 15/Jul/17 7:39 PM ]

closing as this is the wrong fix for the issue in question.

Comment by David Nolen [ 15/Jul/17 7:41 PM ]

This is actual a bug, but the patch is just fixing the wrong place. I believe I fixed the issue in master. Would take a patch which is just the test.

Comment by António Nuno Monteiro [ 15/Jul/17 7:50 PM ]

The revised patch now contains just the test which passes after the fix in master.

Comment by David Nolen [ 15/Jul/17 7:52 PM ]

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





[CLJS-2251] Follow-up fix to CLJS-2249 and related commit Created: 16/Jul/17  Updated: 16/Jul/17  Resolved: 16/Jul/17

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

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

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

 Description   

the fix in [1] is not enough since any other arity that calls `cljs.env/default-compiler-env` without computing the implicit options will suffer from the same problem. Instead we should update the js-dependency-index in the compiler env once we have computed all the implicit options, and every caller of `build` will get consistency for free without needing to call `add-implicit-options` themselves.

https://github.com/clojure/clojurescript/commit/d4b871cce73e43e489496b6c2bf460492bb7742a



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

fixed https://github.com/clojure/clojurescript/commit/309e209f4739f411e7fad959095ecbdc17def948





[CLJS-551] CLONE - Create Sample Application Created: 27/Jul/13  Updated: 27/Jul/13  Resolved: 27/Jul/13

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

Type: Enhancement Priority: Critical
Reporter: Rich Hickey Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

Remaining items:

  • host the application somewhere
  • links to compiled code
  • someone other than Brenton should review the code (is this a good example of how to write ClojureScript?)
  • could use a little more design work

Since I (Brenton) won't be able to do any of these things, I am relinquishing this task to someone who can.



 Comments   
Comment by David Nolen [ 27/Jul/13 1:45 PM ]

cloned, was resolved





[CLJS-26] Create a standard way to reference this Created: 22/Jul/11  Updated: 27/Jul/13  Resolved: 01/Oct/11

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

Type: Enhancement Priority: Critical
Reporter: Rich Hickey Assignee: Fogus
Resolution: Completed Votes: 0
Labels: None


 Description   

Some js frameworks require you to implement 'methods' and those methods need to access js this. Currelty this forces you to js*.

_the following is handled by CLJS-83_

Currently deftype only supports implementing protocol functions. It could be enhanced to support 'method' fns, possibly by using the Object section:

(deftype Foo [a]
Object
(anyArbitraryMethod [a-name-for-this] ...))

Note that the arity of the actual fn would be one less than for protocol 'methods'.

Explore other options before going this way.

Supporting access to 'this' in stand-alone functions may cause gclosure to complain (it only wants to see traditional methods on prototypes), and is a non-objective for now.



 Comments   
Comment by Fogus [ 30/Sep/11 2:17 PM ]

The plan is to start with a pair, this-as and extend-object!. used as such:

;;;;;; GLOBAL THIS

(defn f [] 
  (this-as self 
    (println self)) 
  [self])

(f)
;; #<Object Global>
;;=> [#<undefined>] 

;;;;;; METHOD THIS

(def o (array))

(extend-object! o {:foo f})

(. o (foo))
;; #<Array []>
;;=> [#<undefined>]
Comment by Fogus [ 01/Oct/11 8:56 PM ]

I am going to split out the (deftype T ... Object ...) capability into its own ticket as it's scope is greater than the accessing of this. It's likely that the new ticket will eliminate the need for extend-object!.

Comment by Fogus [ 01/Oct/11 9:19 PM ]

Added note about related ticket. (CLJS-83)

Comment by Fogus [ 01/Oct/11 9:20 PM ]

The this-as macro provides a scoped way to access the implicit this.





[CLJS-442] Lazy seqs fails to close over local vars Created: 14/Dec/12  Updated: 27/Jul/13  Resolved: 18/Dec/12

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

Type: Defect Priority: Critical
Reporter: Jozef Wagner Assignee: Michał Marczyk
Resolution: Completed Votes: 1
Labels: None
Environment:

master clojurescript, commit 9abeb143f6


Attachments: Text File 0001-CLJS-442-fix-a-bug-whereby-fns-might-not-close-over-.patch    

 Description   

When executing following code

(loop [i 10
       v [0]
       v2 [0]]
  (if (pos? i)
    (let [j i
          x (map #(+ j %) v)]
      (recur (dec i) x (map #(+ j %) v2)))
    (concat v v2)))

Clojure produces

(55 55)
while Clojurescript produces
(10 55)

Forcing realization of lazy seqs produces correct output (55 55) on both environments.

(loop [i 10
       v [0]
       v2 [0]]
  (if (pos? i)
    (let [j i
          x (doall (map #(+ j %) v))]
      (recur (dec i) x (doall (map #(+ j %) v2))))
    (concat v v2)))


 Comments   
Comment by Michał Marczyk [ 14/Dec/12 11:28 PM ]

This is actually due to a bug in analyze-let whereby functions involved in init-exprs would not close over earlier bindings. The attached patch fixes this.

Comment by Michał Marczyk [ 14/Dec/12 11:30 PM ]

Incidentally, I wonder whether *loop-lets* is still an appropriate name for this Var...

Comment by David Nolen [ 18/Dec/12 3:04 PM ]

Do you have a better name in mind?

Comment by David Nolen [ 18/Dec/12 3:08 PM ]

fixed http://github.com/clojure/clojurescript/commit/84e9488f49bcfea4b4037a562f8f797c7ddd79f0

Comment by Jozef Wagner [ 19/Dec/12 7:46 AM ]

Thank you, you guys are great!





[CLJS-544] named fn lexical scoping bug Created: 18/Jul/13  Updated: 27/Jul/13  Resolved: 19/Jul/13

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

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


 Description   
(fn [foo] (fn foo [] foo))

generates the following code

function (foo) {
    return (function foo() {
        return foo__$1;
    });
}


 Comments   
Comment by David Nolen [ 19/Jul/13 1:06 AM ]

It looks like the issue is that emit-fn-method in compiler.clj just emits :name from the fn AST, but this :name lack the shadow information present that we pass along via locals in parse fn* star case in analyzer.clj

Comment by David Nolen [ 19/Jul/13 8:06 AM ]

fixed http://github.com/clojure/clojurescript/commit/9ddf847b44ec82070e91038f4afbd8a2baec94ff





[CLJS-333] Keyword self-lookups to return default value when appropriate Created: 03/Jul/12  Updated: 27/Jul/13  Resolved: 03/Jul/12

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

Type: Defect Priority: Critical
Reporter: Michał Marczyk Assignee: Michał Marczyk
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-CLJS-333-add-missing-arity-to-cljs.core.Keyword-s-IF.patch    

 Description   

Originally reported by Evan Mezeske in a comment on CLJS-330.

Due to a missing -invoke arity in cljs.core.Keyword's implementation of IFn, calls like (:foo {} 1) fail to produce the given default value.



 Comments   
Comment by Michał Marczyk [ 03/Jul/12 7:30 PM ]

Note the case with not-found doesn't bother to check if it's dealing with an ObjMap. This is because an ObjMap is capable of holding nil or false as a value, so we would still need to call contains? which on an ObjMap does exactly the same work as -lookup, except it returns true / false thus forcing us to pick the correct return value.

Comment by David Nolen [ 03/Jul/12 7:52 PM ]

fixed, http://github.com/clojure/clojurescript/commit/04e44e444f9bf63d2833d8ff9f87fdb32ac9de48





[CLJS-189] Order-independent hashing of maps Created: 21/Apr/12  Updated: 27/Jul/13  Resolved: 21/Apr/12

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

Type: Defect Priority: Critical
Reporter: Michał Marczyk Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-clojure.lang.APersistentMap-like-hashing-for-maps.patch    

 Description   

This patch introduces a new function – {cljs.core/hash-imap} – which calculates a hash for a map using the algorithm of {clojure.lang.APersistentMap} and wires it into the {-hash} implementations of the various map types. The benefit is that it is order-independent and thus guarantees a stable hash value congruent with {=} without the need for keyset sorting.

This should also be used in sets once {PersistentTreeSet} lands (along with the tree map).



 Comments   
Comment by Michał Marczyk [ 21/Apr/12 11:28 AM ]

Note this calculates the hash modulo 4503599627370496 so it can be represented exactly. Perhaps it would be better to stay within int bounds though?

Comment by David Nolen [ 21/Apr/12 11:37 AM ]

Fixed, https://github.com/clojure/clojurescript/commit/6fd16df50bca7a6118693712e6918c70a64de255





[CLJS-201] Fix bug in PersistentTreeMap, supply some missing proto impls in PTM, PHM auxiliaries Created: 24/Apr/12  Updated: 27/Jul/13  Resolved: 24/Apr/12

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

Type: Defect Priority: Critical
Reporter: Michał Marczyk Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Fix-bugs-around-PersistentTreeMap-PersistentHashMap.patch    

 Description   

From the commit message:



 Comments   
Comment by Michał Marczyk [ 24/Apr/12 1:08 AM ]

A missing ctor argument is supplied in tree-map-append, missing
protocol method and .toString implementations are supplied in PTM- and
PHM-related auxiliary types.

Comment by Michał Marczyk [ 24/Apr/12 7:17 AM ]

The actual .patch file this time.

Comment by David Nolen [ 24/Apr/12 11:10 AM ]

fixed, https://github.com/clojure/clojurescript/commit/63102bceaea60485ae936047a96c6d66bb7387c3





[CLJS-89] Simplify the dot access special form. Created: 14/Oct/11  Updated: 27/Jul/13  Resolved: 01/Feb/12

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

Type: Enhancement Priority: Critical
Reporter: Fogus Assignee: Fogus
Resolution: Completed Votes: 2
Labels: None


 Description   

Currently ClojureScript provides the following dot access syntaxes:

(.p o)           ;=> a property access

(.m o <args>)    ;=> a method call

(. o p)          ;=> a property access

(. o p <args>)   ;=> a method call

(. o (m))        ;=> a method call

(. o (m <args>)) ;=> a method call

This is potentially confusing. Especially considering that Clojure looks as follows:

(.p o)           ;=> a property access if p is a property

(.p o)           ;=> a method call if p is a method

(.m o <args>)    ;=> a method call

(. o p)          ;=> a property access if p is a property

(. o p)          ;=> a method call if p is a method

(. o p <args>)   ;=> a method call

(. o (m))        ;=> a method call

(. o (m <args>)) ;=> a method call

The divergence between the Clojure and ClojureScript way is due to first-class functions. That is, in JavaScript a property can be a field or a function or a method. There is currently no way to distinguish between the desire to call a method and retrieve a function as a property except through syntax. This ticket would shorten the gap between Clojure and ClojureScript in the following way (ClojureScript proposal below):

(.m o)           ;=> a method call

(.m o <args>)    ;=> a method call

(. o m)          ;=> a method call

(. o m <args>)   ;=> a method call

(. o (m))        ;=> a method call

(. o (m <args>)) ;=> a method call

(.-p o)          ;=> a property access

(. o -p)         ;=> a property access

This would be a breaking change, but would shorten the divergence between Clojure and ClojureScript.



 Comments   
Comment by Fogus [ 16/Nov/11 9:09 AM ]

The implementation on the prop-lookup branch is functional and has associated tests. Ready for inclusion.

Comment by Benjamin Conlan [ 02/Dec/11 12:02 AM ]

I've just given this a quick spin and it works beautifully (at least regarding the property value vs property function syntax).

But after looking at my code I can't help but think that for the non-function case (ie json data) just using the maps symbol operator might be more desirable instead of (.-p o))

so json such as:

var jsonData = {
  "person": {
    "title" : "mr",
    "name" : {
      "firstname" : "Harry",
      "surname" : "Jones"
    }
  }
}

could be accessed like:

(:firstname (:name (:person jsonData)))

But in saying this I haven't put any thought into this statement (and of course the suggested code doesn't work anyway in the master/prop-access branches).

In coming full circle, I'm just appreciative of your work on the prop-access branch.

Comment by Stuart Sierra [ 03/Jan/12 5:05 PM ]

Back in the dark ages before Clojure 1.0, you always had to write this;

(. o (m))  ; method call
(. o f)    ; field access

Later, but before the introduction of (.m o) syntax, this was shortened to (. o x) for both methods and fields. What if we went back to the original dot operator syntax, but assume that (.m o) always means a method call:

(. o f)     ; always field access
(. o (m))   ; always method call
(.m o)      ; always method call

Raw field access is rare in Java, perhaps less so in JavaScript. But this doesn't require adding any new syntax and is consistent with what Clojure programmers are used to.

The common case for field access in ClojureScript is, I believe, interop which uses JavaScript objects as map-like data structures. My preferred solution for that case would be better conversion between JS objects and real ClojureScript maps.

Comment by Thomas Scheiblauer [ 01/Feb/12 12:37 PM ]

I would also prefer Stuart's solution due to the reasons he mentioned and because the currently implemented concatenation of sugar characters (.-somefield obj) didn't really make the matter taste more sweet it feels rather clumsy to me.
By the way, I would also propose to implement 'memfn' for staying consistent with Clojure (if it hasn't already been done so).

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

At this point it's probably water under the bridge. If you're interested in memfn, please submit a patch

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

Done





[CLJS-226] Fix bug in TransientVector impl Created: 01/May/12  Updated: 27/Jul/13  Resolved: 01/May/12

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

Type: Defect Priority: Critical
Reporter: Michał Marczyk Assignee: Michał Marczyk
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0002-Fix-bug-in-TransientVector-impl.patch    
Patch: Code

 Description   

This is the bug reported by Brian Taylor in CLJS-208. Patch created on top of CLJS-224, but applies cleanly against current master.



 Comments   
Comment by David Nolen [ 01/May/12 5:26 PM ]

fixed, https://github.com/clojure/clojurescript/commit/b97dd8707f7d78d672cdc255a18ff52106f8f481





[CLJS-229] Fix count for non-counted collections, remove ICounted from Cons Created: 01/May/12  Updated: 27/Jul/13  Resolved: 02/May/12

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

Type: Defect Priority: Critical
Reporter: Michał Marczyk Assignee: Michał Marczyk
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Fix-count-for-non-counted-collections-remove-ICounte.patch    
Patch: Code

 Description   

This caused TwitterBuzz breakage reported by leimy in #clojure: http://clojure-log.n01se.net/date/2012-05-01.html#21:36

Patch created on top of CLJS-228, but should apply cleanly to master.

From the commit message:

Since default no longer gets extended to ICounted, the original
implementation of cljs.core/count no longer works on LazySeq
instances.

This patch takes the approach of checking whether the given collection
is counted and either calling -count or a linear traversal
helper (which rolls over to -count as soon as possible).

The implementation of ICounted on Cons is now unnecessary and has been
removed, so that things for which counted? returns true really do
provide constant-time count.



 Comments   
Comment by Michał Marczyk [ 01/May/12 9:49 PM ]

The actual patch file this time.

Comment by David Nolen [ 02/May/12 10:30 AM ]

fixed, https://github.com/clojure/clojurescript/commit/0ad5556531325d03746f05845dcd26acdc716ef7





[CLJS-204] Bug in sort Created: 25/Apr/12  Updated: 27/Jul/13  Resolved: 18/May/12

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

Type: Defect Priority: Critical
Reporter: Sean Nilan Assignee: Hubert Iwaniuk
Resolution: Completed Votes: 0
Labels: clojure
Environment:

Mac OS X, recently cloned ClojureScript repository


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

 Description   

The sort function (and thus sort-by) do not seem to be behaving as they would in normal Clojure. For example, in my ClojureScript REPL I have:

ClojureScript:cljs.user> (def values (list [-11 10] [-8 12] [-15 -4] [4 5]))
([-11 10] [-8 12] [-15 -4] [4 5])
ClojureScript:cljs.user> (sort values)
([-11 10] [-15 -4] [-8 12] [4 5])

But in the Clojure REPL, you get what one would expect:
user=> (def values (list [-11 10] [-8 12] [-15 -4] [4 5]))
#'setback.core/values
user=> (sort values)
([-15 -4] [-11 10] [-8 12] [4 5])

I have only noticed this bug for sorting vectors, since in Clojure vectors are sorted position by position.



 Comments   
Comment by Sean Nilan [ 25/Apr/12 8:52 AM ]

The bug is actually in the compare function, which uses the google.array.defaultCompare as the compare function for vectors. A simple patch such as below could fix the problem:

(defn vector-compare
[v1 v2]
(cond
(and (empty? v1) (empty? v2))
0
(empty? v1)
-1
(empty? v2)
1
:default
(let [cmp (apply compare (map first [v1 v2]))]
(if (zero? cmp)
(vector-compare (rest v1) (rest v2))
cmp))))

(defn compare
"Comparator. Returns a negative number, zero, or a positive number
when x is logically 'less than', 'equal to', or 'greater than'
y. Uses google.array.defaultCompare for objects of the same type
and special-cases nil to be less than any other object."
[x y]
(cond
(and (vector? x) (vector? y)) (vector-compare x y)
(identical? (type x) (type y)) (garray/defaultCompare x y)
(nil? x) -1
(nil? y) 1
:else (throw (js/Error. "compare on non-nil objects of different types"))))

Comment by David Nolen [ 25/Apr/12 8:54 AM ]

Thanks. We need a IComparable protocol.

Comment by Hubert Iwaniuk [ 16/May/12 3:11 AM ]

IComparable protocol, implementations and tests.

Comment by David Nolen [ 16/May/12 8:15 AM ]

Can we squash the commits here? Thanks!

Comment by Hubert Iwaniuk [ 16/May/12 8:30 AM ]

Commits squashed.

Comment by David Nolen [ 16/May/12 11:31 AM ]

Why do we need to extend IComparable to strings, arrays, boolean, and number?

Comment by Hubert Iwaniuk [ 17/May/12 2:17 PM ]

booleans - are supported in clj
number - special case in clj, not sure if it brings any speed increase, will test with jsperf
arrays - are supported in clj
strings - to support symbols and keywords

Comment by Hubert Iwaniuk [ 18/May/12 7:46 AM ]

Simplified version, just to solve comparing vectors.

Comment by David Nolen [ 18/May/12 7:28 PM ]

fixed, http://github.com/clojure/clojurescript/commit/43ff1c4adea322e6edc1d368ff128f2ad47406a5





[CLJS-589] '({:a 1}) doesn't implement INext Created: 12/Sep/13  Updated: 13/Sep/13  Resolved: 13/Sep/13

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

Type: Defect Priority: Critical
Reporter: George Fraser Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None
Environment:

Clojure 1.5.1
lein-clsbuild 0.3.2



 Description   

Clojurescript:

(map set '({:a 1}))
==> No protocol method INext.-next defined for type cljs.core/NodeSeq: ([:a 1])

(map set (list {:a 1}))
==> (#{[:a 1]})

Clojure:
(map set '({:a 1}))
==> (#{[:a 1]})



 Comments   
Comment by David Nolen [ 13/Sep/13 7:46 AM ]

this bug is not present in the latest release of ClojureScript, 0.0-1878.





[CLJS-751] requiring clojure.core.reducers throws error Created: 15/Jan/14  Updated: 16/Jan/14  Resolved: 16/Jan/14

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

Type: Defect Priority: Critical
Reporter: Francis Avila Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: reducers
Environment:

r2138


Attachments: Text File cljs-751.patch    

 Description   

Requiring the reducers library in any file throws a TypeError at runtime. The generated javascript in reducers.js is this:

cljs.core.IPersistentVector.prototype.clojure$core$reducers$CollFold$ = true;

Error messages is "Uncaught TypeError: Cannot read property 'prototype' of undefined reducers.js:733
(anonymous function)". This stops all execution of JS and basically makes it impossible to use any

IPersistentVector in reducers.cljs should probably be PersistentVector. The specify machinery in extend-type probably exposed this bug.



 Comments   
Comment by Francis Avila [ 15/Jan/14 4:54 PM ]

Note that because of advanced-compilation dead-code elimination, you won't catch this if you advance-compile. Run script/test with whitespace optimizations to see the reducer tests fail.

Comment by Francis Avila [ 15/Jan/14 4:57 PM ]

Patch fixes typo and causes existing reducer tests to pass (tests run with whitespace optimization). Doesn't make sense to write any more tests, although the test runner should probably not use advanced compilation as the default....

Comment by David Nolen [ 16/Jan/14 5:19 PM ]

fixed, https://github.com/clojure/clojurescript/commit/6e10f3d2ca99c58c441de1a1031be2649dae4072





[CLJS-789] Advanced compilation broken with latest closure libra Created: 04/Apr/14  Updated: 22/Apr/14  Resolved: 22/Apr/14

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

Type: Defect Priority: Critical
Reporter: Francis Avila Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Environment:

cljs >= 2197



 Description   

CLJS releases >= 2197 are depending on the most recent packaged closure lib [org.clojure/google-closure-library "0.0-20140226-71326067"].

This is bad,



 Comments   
Comment by Francis Avila [ 04/Apr/14 3:50 PM ]

I have no idea how this was submitted both too soon and twice! I'm very sorry for the mess. Please mark duplicate of CLJS-790 and close.





[CLJS-812] Recurring from a case statement emits invalid JavaScript Created: 09/Jun/14  Updated: 13/Jun/14  Resolved: 13/Jun/14

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

Type: Defect Priority: Critical
Reporter: Luke VanderHart Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug, compiler


 Description   

In 0.2227, compiling the following form produces syntactically invalid JavaScript:

(defn reproduce
  [value]
  (case value
    :a (recur :b)
    :b 0))

Yields:

bug_repro_test.reproduce = (function reproduce(value) {
    while (true) {
        var G__5832 = (((value instanceof cljs.core.Keyword)) ? value.fqn : null);
        var caseval__5833;
        switch (G__5832) {
            case "b":
                caseval__5833 = 0
                break;
            case "a":
                caseval__5833 = {
                    var G__5834 = cljs.core.constant$keyword$67;
                    value = G__5834;
                    continue;
                }

                break;
            default:
                caseval__5833 = (function () {
                    throw (new Error(("No matching clause: " + cljs.core.str.cljs$core$IFn$_invoke$arity$1(value))))
                })()
        }
        return caseval__5833;
        break;
    }
});

When evaluated in any JavaScript environment (including the Google Closure compiler) environment, this yields a syntax error in this code:

caseval__5833 = {
                    var G__5834 = cljs.core.constant$keyword$67;
                    value = G__5834;
                    continue;
                }


 Comments   
Comment by David Nolen [ 10/Jun/14 7:56 AM ]

Good catch. I suspect that throw may be similarly problematic.

Comment by David Nolen [ 13/Jun/14 3:59 PM ]

fixed in master https://github.com/clojure/clojurescript/commit/cc11c7996ba8522d6767fb45df2f76e20e4c1773





[CLJS-819] cljs.reader cannot handle character classes beginning with slashes in regex literals Created: 20/Jun/14  Updated: 01/Jul/14  Resolved: 01/Jul/14

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

Type: Defect Priority: Critical
Reporter: Ziyang Hu Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug, cljs, reader

Attachments: Text File cljs-819.patch    

 Description   

cljs.user> (cljs.reader/read-string "#\"\\s\"")
Compilation error: Error: Unexpected unicode escape \s



 Comments   
Comment by Ziyang Hu [ 20/Jun/14 10:03 AM ]

This in particular means that (cljs.reader/read-string (str [#"\s"])) won't work

Comment by Francis Avila [ 25/Jun/14 11:46 AM ]

Patch and test.

Comment by David Nolen [ 01/Jul/14 9:25 PM ]

fixed https://github.com/clojure/clojurescript/commit/32259c5ff3f86ea086ae3949403df80c2f518c7e





[CLJS-790] Advanced compilation broken with latest closure libra Created: 04/Apr/14  Updated: 03/Jul/14  Resolved: 03/Jul/14

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

Type: Defect Priority: Critical
Reporter: Francis Avila Assignee: Unassigned
Resolution: Completed Votes: 2
Labels: None
Environment:

cljs >= 2197


Attachments: Text File cljs-790.patch     Text File cljs-790-updated.patch    

 Description   

CLJS releases >= 2197 are depending on the most recent packaged closure lib [org.clojure/google-closure-library "0.0-20140226-71326067"].

This is bad,



 Comments   
Comment by Francis Avila [ 04/Apr/14 3:46 PM ]

ARG, submitted too soon by accident.

Rundown is this:

  1. CLJS >= 2197 depends on the latest packaged closure lib (March 17th release, "0.0-20140226-71326067").
  2. This closure lib version is incompatible with the closure compiler closurescript depends on at least because of changes to how goog.base works. See commit 5bdb54d221dbf7c6177ba5ba6901c012981501ec on the closure compiler library (and many more after this one with a similar commit message).
  3. When you advanced-compile a cljs project, goog classes which internally use the goog.base(this, 'superMethod') form will all be munged incorrectly and throw exceptions. Minimal test case: (ns myproj (:require goog.net.XhrIo)) (goog.net.XhrIo/send "http://example.org" #(js/console.log %)). This will fail at a "disposeInternal" call. (Notice that the output js still has the "disposeInternal" string!)
  4. Oddly, the compiler does not emit any warnings about this!
  5. Additionally, the clojurescript project's POM and project.clj specify different versions of the closure library starting at https://github.com/clojure/clojurescript/commit/523a0c5b18138c9a4d23c5104a77b65488bc28c3 The POM specifies the new lib, but the project.clj the older one.

A workaround is to declare an explicit dependency in your project to [org.clojure/google-closure-library "0.0-20130212-95c19e7f0f5f"]. If you do this everything will start working again.

Basically, cljs can't use the new closure lib until its closure compiler has an updated release. (There is some hope that this may be easier to do in the future: https://groups.google.com/d/msg/closure-compiler-discuss/tKZQ1eLUixA/3urgnli84SYJ)

Comment by David Nolen [ 08/May/14 6:21 PM ]

Has this been resolved by a new closure compiler release yet? Thanks!

Comment by Francis Avila [ 11/May/14 11:48 AM ]

Donno, will give v20140407 release a try tonight.

Comment by Francis Avila [ 13/May/14 8:13 AM ]

Seems to work. Ran the test suite, benchmark, and some other projects I had which were failing before. Patch attached with updated dependencies.

Comment by Stephen Nelson [ 17/Jun/14 10:21 PM ]

This bug (or a similar one) is still affecting clojurescript 0.0-2234. Another example:

(ns myproj
(:require goog.net.XhrManager))
(.send (goog.net.XhrManager.) "xhr-request" "myproj.js" "GET" nil nil nil #(.log js/console %))

The workaround suggested above (using the old closure library) works, but versions of clojurescript newer than 2197 cannot be used in production without the workaround. If this bug is going to remain open in new releases, please consider documenting the workaround in the release notes.

Comment by David Nolen [ 18/Jun/14 10:42 AM ]

Can we get a new patch with a more recent release? http://search.maven.org/#artifactdetails%7Ccom.google.javascript%7Cclosure-compiler-parent%7Cv20140508%7Cpom

Comment by Francis Avila [ 24/Jun/14 10:30 AM ]

Bumped version. Note that this patch is unnecessary in the 1.6.0 branch, as its versions are up to date and its pom and project.clj agree. This commit is likely conflict when 1.6.0 is merged into master (the master side should be ignored if that happens).

Comment by David Nolen [ 01/Jul/14 9:25 PM ]

this should be resolved in master

Comment by Francis Avila [ 03/Jul/14 1:55 PM ]

It is. You can close.

Comment by David Nolen [ 03/Jul/14 2:10 PM ]

fixed in master with 1.6.0 work merge





[CLJS-1216] varargs not passed properly Created: 21/Apr/15  Updated: 23/Apr/15  Resolved: 23/Apr/15

Status: Closed
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3196
Fix Version/s: 0.0-3211

Type: Defect Priority: Critical
Reporter: Karsten Schmidt Assignee: David Nolen
Resolution: Completed Votes: 2
Labels: compiler


 Description   

The following is broken as of 3196 (3165 is still working correctly)

(defn foo
  ([a] (foo a 10))
  ([a b & [c]] [a b c]))

(foo 1)
;; => [1 (10) nil] => should be [1 10 nil]

(foo 1 2)
;; => [1 (2) nil] => should be [1 2 nil]

(foo 1 2 3)
;; => [1 (2 3) nil] => should be [1 2 3]


 Comments   
Comment by Stephen Nelson [ 21/Apr/15 7:18 PM ]

This only occurs with defns that have multiple bodies, it does not occur with fns or with defns with a single body, or when the defn is called via apply rather than directly. Seems like it might be an off-by-one error in the calculation of required arguments in the defn dispatcher function. Test case:

test/dispatch_test.cljs
(ns test.destructuring-test
  (:require [cljs.test :refer-macros [deftest is]]))

(defn destructure
  ([kvs]
   kvs)
  ([k v & args]
   [k v args]))

(deftest test-destructuring
  (is (= [1 2 [3 4]]                                        ;; fails
         (destructure 1 2 3 4)))
  (is (= [1 2 [3 4]]                                        ;; passes
         (apply destructure [1 2 3 4])))
  )

In the compiled javascript the default case of the dispatcher only pulls one argument off before calling the variadic body, whereas the applyTo body pulls two off. Seems like the dispatcher is at fault.

test/dispatch_test.js
...
test.destructuring_test.destructure = (function test$destructuring_test$destructure() {
    var G__48557 = arguments.length;
    switch (G__48557) {
        case 1:
            return test.destructuring_test.destructure.cljs$core$IFn$_invoke$arity$1((arguments[(0)]));

            break;
        default:
            var argseq__17948__auto__ = (new cljs.core.IndexedSeq(Array.prototype.slice.call(arguments, 1), (0)));
            return test.destructuring_test.destructure.cljs$core$IFn$_invoke$arity$variadic((arguments[(0)]), argseq__17948__auto__);

    }
});

test.destructuring_test.destructure.cljs$core$IFn$_invoke$arity$1 = (function (kvs) {
    return kvs;
});

test.destructuring_test.destructure.cljs$core$IFn$_invoke$arity$variadic = (function (k, v, args) {
    return new cljs.core.PersistentVector(null, 3, 5, cljs.core.PersistentVector.EMPTY_NODE, [k, v, args], null);
});

test.destructuring_test.destructure.cljs$lang$applyTo = (function (seq48553) {
    var G__48554 = cljs.core.first.call(null, seq48553);
    var seq48553__$1 = cljs.core.next.call(null, seq48553);
    var G__48555 = cljs.core.first.call(null, seq48553__$1);
    var seq48553__$2 = cljs.core.next.call(null, seq48553__$1);
    return test.destructuring_test.destructure.cljs$core$IFn$_invoke$arity$variadic(G__48554, G__48555, seq48553__$2);
});
...
Comment by Karsten Schmidt [ 22/Apr/15 5:20 AM ]

You're right, Stephen! I've narrowed down the first occurrence, it's starting at r3178 - most likely with the changes done to cljs.core in this commit: https://github.com/clojure/clojurescript/commit/576fb6e054dd50ec458a3c9e4172a5a0002c7aea

will dig more & attempt a patch later today...

Comment by David Nolen [ 23/Apr/15 12:34 AM ]

I have a fix for this, just a simple error around computing the max fixed arity.

Comment by David Nolen [ 23/Apr/15 12:39 AM ]

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

Comment by David Nolen [ 23/Apr/15 12:51 AM ]

Cut 0.0-3211 with this fix.





[CLJS-1289] Revert clj->cljc file conversion Created: 26/May/15  Updated: 26/May/15  Resolved: 26/May/15

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

Type: Defect Priority: Critical
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

Commit [1] changed some .clj files over to .cljc files but no other changes were made to actually make these "common" files. Most of the files are not actually compatible (and probably never will be, eg. assuming sync streaming IO) and some even cause conflicts src/clj/cljs/repl.cljc vs. src/main/cljs/cljs/repl.cljs both trying to provide cljs.repl namespaces.

Any objections to changing these back as they provide no gain as of now?

I know other build tools are not a concern but these "faulty" files cause "issues" in shadow-build.

[1] https://github.com/clojure/clojurescript/commit/11113cea2f599d685b60f8fbdcb56d944240ea25



 Comments   
Comment by David Nolen [ 26/May/15 1:13 PM ]

The change was intentionally made now that Clojure has reader conditionals. The intent is for portions of these ClojureScript files to be made so that we can compile to Node.js gradually over time.





[CLJS-1469] :modules regression Created: 14/Oct/15  Updated: 20/Oct/15  Resolved: 20/Oct/15

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

Type: Defect Priority: Critical
Reporter: David Nolen Assignee: Sebastian Bensusan
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File cljs_1469.patch    

 Description   

:modules support appears broken now. Any attempt to use :modules results in the following stack trace:

Exception in thread "main" java.lang.NullPointerException, compiling:(/Users/davidnolen/development/clojure/om-tutorial/script/build.clj:3:1)
        at clojure.lang.Compiler.load(Compiler.java:7239)
        at clojure.lang.Compiler.loadFile(Compiler.java:7165)
        at clojure.main$load_script.invoke(main.clj:275)
        at clojure.main$script_opt.invoke(main.clj:337)
        at clojure.main$main.doInvoke(main.clj:421)
        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)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
        at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:207)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
        at clojure.lang.Reflector.invokeStaticMethod(Reflector.java:207)
        at user$eval5.invoke(form-init397895486450728621.clj:1)
        at clojure.lang.Compiler.eval(Compiler.java:6782)
        at clojure.lang.Compiler.eval(Compiler.java:6772)
        at clojure.lang.Compiler.load(Compiler.java:7227)
        at clojure.lang.Compiler.loadFile(Compiler.java:7165)
        at clojure.main$load_script.invoke(main.clj:275)
        at clojure.main$init_opt.invoke(main.clj:280)
        at clojure.main$initialize.invoke(main.clj:308)
        at clojure.main$null_opt.invoke(main.clj:343)
        at clojure.main$main.doInvoke(main.clj:421)
        at clojure.lang.RestFn.invoke(RestFn.java:421)
        at clojure.lang.Var.invoke(Var.java:383)
        at clojure.lang.AFn.applyToHelper(AFn.java:156)
        at clojure.lang.Var.applyTo(Var.java:700)
        at clojure.main.main(main.java:37)
Caused by: java.lang.NullPointerException
        at com.google.javascript.jscomp.JSModule.sortInputsByDeps(JSModule.java:263)
        at cljs.closure$optimize_modules$fn__3702.invoke(closure.clj:974)
        at cljs.closure$optimize_modules.doInvoke(closure.clj:973)
        at clojure.lang.RestFn.applyTo(RestFn.java:139)
        at clojure.core$apply.invoke(core.clj:632)
        at cljs.closure$build.invoke(closure.clj:1709)
        at cljs.build.api$build.invoke(api.clj:219)
        at cljs.build.api$build.invoke(api.clj:213)
        at user$eval4050.invoke(build.clj:3)
        at clojure.lang.Compiler.eval(Compiler.java:6782)
        at clojure.lang.Compiler.load(Compiler.java:7227)
        ... 36 more


 Comments   
Comment by David Nolen [ 14/Oct/15 2:47 PM ]

We should figure out a simple test case for this one that we can add to the Clojure test suite.

Comment by Sebastian Bensusan [ 20/Oct/15 3:57 PM ]

As discussed elsewhere, the solution was to set the CompilerOptions to the Compiler instance before calling sortInputs. The regression is due to a change in the compiler's internals, which now require those "who don't do a normal compile job" to set their own options (comment changed in commit 5509c2f6038d9bf36c944fe2d58e6ae956283dd3 of the Google Closure Compiler)

Also, a test to detect similar regressions was added. The patch was also tested following the example found here.

Comment by David Nolen [ 20/Oct/15 4:01 PM ]

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





[CLJS-1472] Patch for CLJS-1467 causes regression for nodejscli Created: 16/Oct/15  Updated: 23/Oct/15  Resolved: 23/Oct/15

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

Type: Defect Priority: Critical
Reporter: Michael Ballantyne Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File cljs_1472.patch    

 Description   

https://github.com/clojure/clojurescript/commit/a4d6a241cd9d45bf0356809c18df14585befd68f, the patch for CLJS-1467, breaks the functionality of nodejscli when compilation uses :output-to.

As an example, compiling samples/nodehello.cljs like this:

bin/cljsc samples/nodehello.cljs "{:target :nodejs :output-to \"out/nodehello.js\"}"

Yields out/nodehello.js with these contents:

goog.addDependency("base.js", ['goog'], []);
goog.addDependency("../cljs/core.js", ['cljs.core'], ['goog.string', 'goog.object', 'goog.string.StringBuffer', 'goog.array']);
goog.addDependency("../out/nodehello.js", ['cljs.nodejs'], ['cljs.core']);
goog.addDependency("../out/nodehello.js", ['nodehello'], ['cljs.core', 'cljs.nodejs']);
goog.addDependency("../out/nodehello.js", ['cljs.nodejscli'], ['cljs.core', 'cljs.nodejs']);

Note that out/nodehello.js is offered as the source of all three of 'cljs.nodejs', 'nodehello', and 'cljs.nodejscli' while it only actually contains 'nodehello'.

In the previous revision cljs.nodejs and cljs.nodejscli would be compiled to a file with a name like "BCE03FE.js". Now it appears they are being compiled into the output-to file and then being overwritten.



 Comments   
Comment by Sebastian Bensusan [ 21/Oct/15 10:29 AM ]

The CLJS-1467 regression happened because cljs.closure/compile-file doesn't doesn't match it's docstring:

"If no output-file is specified, returns a string of compiled JavaScript. With an output-file option, the compiled JavaScript will written to this location and the function returns a JavaScriptFile. "

while it can may also write to :output-to instead. Before CLJS-1467 this case was unreachable, so therefore unused and not problematic.

The attached patch removes :output-to from compile-file and makes it the caller's responsibility to use {:output-file}}, restoring pre-CLJS-1467 behavior to the function.

CLJS-1467 solved the original issue by compiling the unique file of :main with :simple or :advanced through the true clause of compile-file, which writes to disk. The same effect is achieved by specifying output-file before calling compile-file, thus solving the issue.

Comment by Sebastian Bensusan [ 21/Oct/15 10:31 AM ]

Though the given sample case correctly shows the issue, the command lacks a :main. To get a running program from the sample run:

bin/cljsc samples/nodehello.cljs "{:target :nodejs :main \"nodehello\" :output-to \"out/nodehello.js\"}"
Comment by David Nolen [ 23/Oct/15 11:36 AM ]

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





[CLJS-1824] transit cache feature leaks files Created: 18/Oct/16  Updated: 18/Oct/16  Resolved: 18/Oct/16

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

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


 Description   

We read transit files outside of `with-open` blocks.



 Comments   
Comment by David Nolen [ 18/Oct/16 12:17 PM ]

fixed https://github.com/clojure/clojurescript/commit/176c681b25b75e907bf376698263dacf6ce998f4





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

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

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

Affects master



 Description   

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

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



 Comments   
Comment by David Nolen [ 02/Dec/16 5:11 PM ]

fixed https://github.com/clojure/clojurescript/commit/97d2d61e78ce747d02d0e5b2ced706f6fb68ec4e





[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-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-2163] Clean up uses of aget / aset on objects Created: 04/Jul/17  Updated: 08/Jul/17  Resolved: 08/Jul/17

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

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

Attachments: Text File CLJS-2163-2.patch     Text File CLJS-2163.patch    
Patch: Code and Test
Approval: Vetted

 Description   

With CLJS-2148 new warnings were added which emit diagnostics when inference indicates invalid aget or aset usage, and the usages were also addressed.

This ticket asks that other uses of aget and aset be fixed (where the use site does not have sufficient inference to trigger the warnings).



 Comments   
Comment by Mike Fikes [ 05/Jul/17 3:51 PM ]

For the two changes in ObjMap, I used unsafe-get, in case efficiency matters. (It looks like this deftype is deprecated, so I didn't bother to add tests for it)

For the change in js-invoke, I used unsafe-get in case efficiency matters. I added a unit test for js-invoke.

For the two changes in source-map, I used unsafe-get thinking that efficiency might really matter here. I didn't add any unit tests for these changes.

I ran a browser REPL (QuickStart), script/noderepljs, the Nashorn, and Rhino REPLs to ensure they didn't break. Interestingly, the Node REPL needed unsafe-get, otherwise you get "Cannot read property 'get' of undefined" for goog.object.get. Presumably this is too early in startup to use goog.object.

The changes in js-obj appear to already have coverage in the test suite. I also manually tested at the REPL.

Comment by Mike Fikes [ 07/Jul/17 10:43 PM ]

Attaching a revised {{CLJS-2163-2.patch}} that patches a few more missed uses in the ObjMap implementation and two important ones:

  1. The printing of JavaScript objects in pr-writer-impl
  2. The js->clj implementation

The two above use unsafe-get in the patch, presuming they need to be extra performant.

Comment by David Nolen [ 08/Jul/17 10:20 AM ]

This looks good but the changes to source map are unnecessary `sources` and `name` are in fact JavaScript arrays. Otherwise looks good.

Comment by David Nolen [ 08/Jul/17 10:43 AM ]

Actually just going to fix the source map changes myself.

Comment by David Nolen [ 08/Jul/17 10:44 AM ]

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





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

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

Type: Defect Priority: Critical
Reporter: Thomas Heller Assignee: Unassigned
Resolution: Completed Votes: 4
Labels: None


 Description   

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

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



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

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

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

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

What does the Clojure EDN reader do here?

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

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

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

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

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

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

Also see the commit adding namespaces maps in clojure

Comment by David Nolen [ 08/Jul/17 10:06 AM ]

related CLJS-1800, CLJS-2059

Comment by António Nuno Monteiro [ 08/Jul/17 3:10 PM ]

this will be fixed by https://github.com/clojure/clojurescript/pull/69 (CLJS-1800)

Comment by David Nolen [ 09/Jul/17 7:56 AM ]

fixed https://dev.clojure.org/jira/browse/CLJS-1800





[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: 09/Jul/17  Resolved: 09/Jul/17

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

Type: Defect Priority: Critical
Reporter: Creighton Kirkendall Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: cljs.test

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

 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



 Comments   
Comment by António Nuno Monteiro [ 08/Jul/17 4:04 PM ]

Patch attached.

Comment by David Nolen [ 09/Jul/17 8:25 AM ]

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





[CLJS-2172] memfn docstring refers to Java and reflection Created: 05/Jul/17  Updated: 09/Jul/17  Resolved: 09/Jul/17

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

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

Attachments: Text File CLJS-2172.patch     Text File CLJS-2172-v2.patch    
Patch: Code and Test
Approval: Screened

 Description   

Currently:

Expands into code that creates a fn that expects to be passed an
object and any args and calls the named instance method on the
object passing the args. Use when you want to treat a Java method as
a first-class fn. name may be type-hinted with the method receiver's
type in order to avoid reflective calls.

Proposed:

Expands into code that creates a fn that expects to be passed an
object and any args and calls the named instance method on the
object passing the args. Use when you want to treat a JavaScript 
method as a first-class fn.


 Comments   
Comment by Mike Fikes [ 05/Jul/17 8:45 AM ]

Note: Even though this ticket was marked as "trivial" owing to it being simply a docstring change, the solution in CLJS-2172.patch is not trivial in that it involves exclusively using the ClojureScript-specific copy of memfn that was originally created for self-hosted. Since this is a bit more extensive of a change, added unit tests. Also, a small consequence is that doc on memfn now shows the macro symbol name as cljs.core/memfn (as it already does in self-hosted REPLs that implement doc).

I suppose, if this change is accepted, it opens the door to potentially remove the with-meta that is in the implementation, which came from the Clojure copy (if there is really no need for it in ClojureScript).

Comment by David Nolen [ 09/Jul/17 8:19 AM ]

Patch needs to be rebased to master.

Comment by Mike Fikes [ 09/Jul/17 9:12 AM ]

Attached re-baselined CLJS-2172-v2.patch.

Comment by David Nolen [ 09/Jul/17 9:57 AM ]

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





[CLJS-2192] Add ChakraCore testing facilities Created: 08/Jul/17  Updated: 09/Jul/17  Resolved: 09/Jul/17

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

Type: Enhancement Priority: Critical
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-2192.patch     Text File CLJS-2192-v2.patch    
Patch: Code
Approval: Accepted

 Description   

It is trivial to get pre-built ChakraCore binaries. This ticket asks that support for ChakraCore be added to script/test and others so that it is easy for users to also test with this engine if desired. The amount of time needed to run the tests is not significantly more than the other fast engines.



 Comments   
Comment by Mike Fikes [ 08/Jul/17 4:24 PM ]

Attached patch adds ChakraCore to the test scripts, including (and tested on) Windows.
The tests pass on macOS and Linux, but fail on Windows in a 3 spots (will deal with those few failures via separate ticket or tickets).
Also adds ChakraCore to CI (it passes there).

Comment by David Nolen [ 09/Jul/17 8:12 AM ]

The patch needs to be rebased to master.

Comment by Mike Fikes [ 09/Jul/17 9:21 AM ]

Attached re-baselined CLJS-2192-v2.patch.

Comment by David Nolen [ 09/Jul/17 11:59 AM ]

fixed https://github.com/clojure/clojurescript/commit/6583de880ee6bf92e0baa50dee8da621e45494e1





[CLJS-1428] Add a cljs.core/*command-line-args* var Created: 16/Aug/15  Updated: 09/Jul/17  Resolved: 09/Jul/17

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

Type: Enhancement Priority: Critical
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Completed Votes: 1
Labels: core

Attachments: Text File CLJS-1428.patch    
Patch: Code
Approval: Accepted

 Description   

Add a cljs.core/*command-line-args* var that mimics Clojure's:

https://github.com/clojure/clojure/blob/4bb1dbd596f032621c00a670b1609a94acfcfcab/src/clj/clojure/core.clj#L6148

Rationale:
1) Simplifies writing command-line scripts in ClojureScript if this var is universally available.
2) Consistency with Clojure.

Existing tooling can ignore the var (it would be initialized with nil).

Command-line REPLs or other command-line environments can bind a sequence to this var when launched.



 Comments   
Comment by Justin Thomas [ 31/Aug/15 10:14 PM ]

In this file: https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/nodejs.cljs Looks like you could set this: (def *command-line-args* (.-argv process)) and it'd be accessible under nodejs/*command-line-args*. Not sure where the star vars are set in the elsewhere in the code or if that's a good solution putting it in each repo.

Maybe get the target var somehow and set it based on that--similar to how the nodejs file is loaded?

Found this: src/main/clojure/cljs/core.cljc and saw references to a ns called env.

Comment by David Nolen [ 01/Sep/15 6:44 AM ]

This ticket needs more rationale and stronger outline of the design issues before proceeding. As it stands no one should be working on this yet.

Comment by Justin Thomas [ 01/Sep/15 4:27 PM ]

Just trying to learn the code at the moment. As for rationale, using the command line vars in node is a common use case for shell scripts. Accessing the command line vars in a more clojure-y way seems like a good idea.

Comment by David Nolen [ 08/Jul/17 10:47 AM ]

I agree that in a post bootstrap world this sounds pretty useful.

Comment by António Nuno Monteiro [ 08/Jul/17 3:24 PM ]

Attached a simple patch just adding the variable to the `cljs.core` namespace, that bootstrap REPLs can set.

I think that providing a default behavior warrants more discussion that falls out of the scope of this ticket.

Comment by David Nolen [ 09/Jul/17 12:23 PM ]

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





[CLJS-2135] require macro prints last result of loaded-libs Created: 28/Jun/17  Updated: 09/Jul/17  Resolved: 09/Jul/17

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

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

Attachments: Text File CLJS-2135.patch    
Patch: Code
Approval: Accepted

 Description   

When using the require macro in the REPL, you see the last result of the loaded-libs emitted JavaScript. Oftentimes this can be an innocuous true, but if you use :reload-all you'll see the loaded libs:

$ java -jar cljs.jar -m cljs.repl.node
ClojureScript Node.js REPL server listening on 53584
To quit, type: :cljs/quit
cljs.user=> (require 'clojure.set)
true
cljs.user=> (require 'clojure.set :reload-all)
#{"goog.dom.NodeType" "clojure.set" "goog.array" "cljs.spec" "clojure.walk" "goog.reflect" "goog.asserts" "goog.object" "clojure.string" "goog.math.Long" "cljs.repl" "goog.string" "goog.debug.Error" "cljs.spec.impl.gen" "goog.math.Integer" "cljs.core" "cljs.pprint" "goog.string.StringBuffer"}

If you use `:repl-verbose`, you can see what is happening. The last bit of the above looks like:

goog.require('clojure.set', 'reload-all');
if(!COMPILED) cljs.core._STAR_loaded_libs_STAR_ = cljs.core.into(cljs.core._STAR_loaded_libs_STAR_17863, cljs.core._STAR_loaded_libs_STAR_);

This ticket requests that a null; be emitted so that require returns nil as was done with the require REPL special.



 Comments   
Comment by Mike Fikes [ 28/Jun/17 8:49 AM ]

The attached patch produces the desired result at the REPL (having `require` always return `nil`). It does it in a way that doesn't affect namespaces compiled (that may use top-level `require`) outside of the REPL.

Comment by David Nolen [ 09/Jul/17 2:21 PM ]

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





[CLJS-2139] Undeclared var regression in fn bodies Created: 29/Jun/17  Updated: 12/Jul/17  Resolved: 30/Jun/17

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

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

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

 Description   
(defn foo [] x)

No longer produces a warning. Probably related to the changes to suppress double warnings as a result of fn invoke optimization. The fix needs to also supply an analyzer test case.



 Comments   
Comment by David Nolen [ 29/Jun/17 5:31 PM ]

Actually I looked into this - not related to changes around double warnings an fn optimization. Dropping `warning-for` from analyze does not change the behavior.

Comment by Mike Fikes [ 29/Jun/17 6:58 PM ]

git bisect shows that this regression was introduced with the commit for CLJS-2066.

Comment by Mike Fikes [ 29/Jun/17 9:28 PM ]

The root cause is fairly cut-n-dry. The solution is fairly straightforward, but perhaps a little more complex than desired. Explanation is in commit comment in the attached patch. Adds a regression test specifically for this case.

Comment by Mike Fikes [ 29/Jun/17 9:53 PM ]

Since method param analysis never results in warnings being emitted, a much simpler (1-line) patch is sufficient for the problem. Attaching a v2 patch as an alternative to consider.

Comment by David Nolen [ 30/Jun/17 8:19 AM ]

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





[CLJS-2191] Clean up doc references to clojure.spec.* in favor of cljs.spec.* Created: 08/Jul/17  Updated: 12/Jul/17  Resolved: 09/Jul/17

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

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

Attachments: Text File CLJS-2191.patch    
Patch: Code
Approval: Accepted

 Description   

There are a handful of docstrings that refer to the namespaces as clojure.spec.* instead of cljs.spec.* that could be cleaned up:

  1. In the regex? predicate
  2. The keyword in the conform docstring
  3. The fdef docstring

These can also be cleaned up to append alpha (as is done in other docstrings).



 Comments   
Comment by David Nolen [ 09/Jul/17 8:13 AM ]

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





[CLJS-2198] Safe array operations Created: 09/Jul/17  Updated: 13/Jul/17  Resolved: 13/Jul/17

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

Type: Enhancement Priority: Critical
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: core

Attachments: Text File CLJS-2198-v10.patch     Text File CLJS-2198-v11.patch     Text File CLJS-2198-v1.patch     Text File CLJS-2198-v2.patch     Text File CLJS-2198-v3.patch     Text File CLJS-2198-v4.patch     Text File CLJS-2198-v5.patch     Text File CLJS-2198-v6.patch     Text File CLJS-2198-v7.patch     Text File CLJS-2198-v8.patch     Text File CLJS-2198-v9.patch    
Patch: Code and Test
Approval: Vetted

 Description   

We need an new compiler flag `*unchecked-array-access*`.

We should add a `safe-aget`, `safe-aget` runtime functions. These functions should make three assertions before bottoming out to `unsafe-get`:

  • first argument `array?`
  • second argument must be `number?`
  • second argument must be in array bounds

If `:invalid-array-access` is true, compilation mode is not `:advanced` and `*unchecked-array-access*` is not true, then `aget/aset` macro should not generate inlined JS array access but should instead call `safe-aget` and `safe-aset`.

We also need to update `aset/aget` runtime fns to also do these assertions under the same compiler option configuration specified above.

Finally `*unchecked-array-access*` needs to be be set to true for the standard library. It's important that this flag is file local and we should provide a simple test that setting it in one file will not affect a dependent namespace.



 Comments   
Comment by Mike Fikes [ 09/Jul/17 9:16 PM ]

A first draft patch is attached, which works, but highlights some of the deeper questions that arise (at least with the approach in the patch). I think it is worth playing with the implementation at this point, and seeing if ideas come up on how to better do some things. Here are some fairly extensive notes attempting to describe the patch:

*unchecked-array-access* is very similar to *unchecked-if*

ana/unchecked-array-access? returns the analyzer Var if in clj and the core Var if in self-host (this could probably be dispensed with, but for now it has the same "shape" as *unchecked-if*, which might make it simpler to reason about)

*unchecked-array-access* is slightly different from *unchecked-if* in that it doesn't need to be baked into the AST for conveyance to the compiler like we need for the if special form. This is because macroexpansion is done in the analyzer and we can get away with an analyzer dynamic Var for what we are doing.

(:parallel-build -> really works because only one namespace uses it? I wonder the same about *unchecked-if).

File-scope aspect? We don't need to un-set it at the bottom of file if we have some other mechanism to turn it off after file processed. It seems that this occurs in JVM ClojureScript, but not in self-hosted (perhaps owing to reliance on the Var in cljs.core, or perhaps owing to a lack of setting a dynamic Clojure Var that unsets itself.) I haven't tracked this down. There is a test for this if we come up with a good way. Otherwise it is single gigantic scopes being manually done (like the smaller *unchecked-if* scopes, but covering whole files).

The runtime aget/aset functions delegate to macros for their behavior, but we wrap the scope of where they are defined to turn off *unchecked-array-access*, so they can vary based on :invalid-array-access and :advanced

:invalid-array-access is build-affecting

Can't figure out how to make runtime aget/aset be AOT able (because it changes based :invalid-array-access setting)

unsafe-set added and used as bottom-out for safe-set. If instead we have it call aset, aset will then call safe-set, which will then call aset... infinite recursion

Tried not to introduce any new public Vars anywhere in cljs.core (apart from unsafe-set). In particular the safe-aget and safe-aset are private

Ended up using unsafe-get in the few places that aget is used in the cljs.core macros namespace. Without doing this, what appears to be happening is if you, for example, define a variadic fn, the defn gets expanded, and you end up using safe-gets where you wanted unsafe-gets.

We lose our static analysis warnings because they are based on looking at the resulting js* and seeing if the :op is cljs.core/aget. When we turn on :invalid-array-access, aget gets expanded to safe-aget, which has inside of it some checks, and a bottom out at unsafe-get, thus causing the wrong :op. It would be nice to think through this so we can re-gain some static analysis checks to find incorrect code before runtime.

Comment by David Nolen [ 10/Jul/17 5:22 AM ]

Thanks this is helpful. With respect to the patch, first I'd like to go with Christophe Grand's feedback about naming:

  • unsafe-set -> unchecked-set
  • unsafe-get -> unchecked-get
  • safe-set -> checked-aset
  • safe-get -> checked-aget

The file scoping falls out of the fact that we bind thread local dynamic vars when compiling or analyzing files. So no need to unset. In bootstrapped I suspect this has to be done differently because of the asynchronous design.

We can reclaim static analysis with an analyzer pass (cljs.analyzer/*passes*) that looks at checked-aset and checked-aget invoke ASTs and checks that tags of the argument ASTs.

Comment by David Nolen [ 10/Jul/17 5:40 AM ]

I think I understand the point about aset/aget and AOT. Why not just alias higher order aget/aset to checked-aset/checked-aget using the same checks for the other cases?

Comment by Mike Fikes [ 10/Jul/17 9:16 AM ]

The attached CLJS-2198-v2.patch addresses all of David's feedback apart from the runtime / AOT issue.

  • Names refactored to Grand's suggestion
  • File scoping addressed in self-host and tests revised
  • Static analysis reclaimed by simply looking for :js-op of cljs.core/checked-aget and cljs.core/checked-aset

The difficulty with the runtime / AOT issue: It would appear that the conditions that drive things are only available at compile time. With the way the patch is structured, the runtime functions bottom out in macros that switch based on the compile time setting, and we get what we want apart from the negative aspect that cljs.core effectively gets recompiled (we don't really want it to be affected by build-affecting options).

Perhaps one way out of this (perhaps this is what David alludes to with aliasing?) is to, when starting up a REPL, monkey patch aget / aset to instead be their checked variants. I haven't put too much thought into this approach.

Comment by David Nolen [ 10/Jul/17 9:40 AM ]

re: AOT. We handle cljs.core as a special case already. Basically we can just always compile `cljs.core` with `:invalid-array-access` set to true. This will avoid triggering rebuilds of core when users change the compiler options.

re: aset/aget - all I'm suggesting is that `aset/aget` become aliases for the checked variants in higher order cases as long as the compiler options call for it.

(map aget ...)

Should become:

(map checked-aget ...)

We can handle this during var resolution I think.

Comment by Mike Fikes [ 10/Jul/17 9:49 AM ]

Ahh. Makes sense.

I was wrong, by the way with respect to reclaiming static analysis. Will also revisit the idea of an analyzer pass.

Comment by Mike Fikes [ 10/Jul/17 10:17 PM ]

Added CLJS-2198-v3.patch

Notes on revisions in this patch:

The AOT stuff appears to be working: There is now code in the resolve path that conditionally substitutes in the checked variants for runtime aget / aset while using precisely the same function used by the macros when they are expanding. One way to see that this aliasing is working is to

Given this, it is possible to remove the temporary unset and reset of *unchecked-array-access* that was wrapping aget / aset. This means those functions (and all of runtime cljs.core, really) is unconditionally unchecked), except of course, checked-aget / checked-aset, which employ checks as assertions via :pre.

This means that the runtime cljs.core is not affected by :invalid-array-access, and can be safely AOTd, and the user can change To ensure that this happens, there is a bit where I have the code dissoc any :warnings that may have been set (near the same place where we set :static-fns true when compiling core.

The static analysis checks have also been reclaimed by adding an additional pass. (As an aside, this opens the door to easily adding other static analysis checks for other runtime functions outside of checked-aset and checked-aget. For example, I found it was trivial to add a check for bit-count once this machinery was in place.

The only problem with the static warnings is that they appear twice now. Here is an example:

cljs.user=> (aget #js {:foo 1} "foo")
WARNING: cljs.core/aget, arguments must be an array followed by numeric indices, got [object string] instead (consider goog.object/get for object access) at line 1 <cljs repl>
WARNING: cljs.core/aget, arguments must be an array followed by numeric indices, got [object string] instead (consider goog.object/get for object access) in file <cljs repl>

I'm speculating that this is because of the analysis that occurs right at the end of macroexpansion, with perhaps another analysis ocurring on the code returned from macroexpansion. (You only get one such warning if you try it directly with checked-aget). I tried putting a analyzed wrapper call around what I thought was the right place for this but haven't solved that yet.

So that's where things stand right now (just this one double warning bug is known). But, to be honest, this is a fairly large patch with a lot of subtle moving parts that will probably only become robust with more testing and time, I'm thinking.

Comment by Mike Fikes [ 10/Jul/17 10:40 PM ]

Attaching CLJS-2198-v4.patch which has minor revisions to remove leftover unnecessary code which was in CLJS-2198-v3.patch.

Comment by David Nolen [ 11/Jul/17 6:10 AM ]

Thanks will take a look today and see if I can't find the double warning issue. We should make a test case for that once we discover the cause.

Comment by Mike Fikes [ 11/Jul/17 6:34 AM ]

If you add a bit of code to (prn (ex-info "" {})) fight at the point the warning is thrown, you can see that the stacks involved are the same apart from a little extra part of the stack that exists when the first warning is emitted:

$ diff -C 20 a.txt b.txt
*** a.txt	2017-07-11 07:28:09.000000000 -0400
--- b.txt	2017-07-11 07:28:20.000000000 -0400
***************
*** 1,40 ****
  [[clojure.core$ex_info invokeStatic "core.clj" 4725]
    [clojure.core$ex_info invoke "core.clj" 4725]
    [cljs.analyzer$check_invoke_arg_types invokeStatic "analyzer.cljc" 3380]
    [cljs.analyzer$check_invoke_arg_types invoke "analyzer.cljc" 3373]
    [cljs.analyzer$analyze_STAR_$fn__3102 invoke "analyzer.cljc" 3439]
    [clojure.lang.PersistentVector reduce "PersistentVector.java" 341]
    [clojure.core$reduce invokeStatic "core.clj" 6703]
    [clojure.core$reduce invoke "core.clj" 6686]
    [cljs.analyzer$analyze_STAR_ invokeStatic "analyzer.cljc" 3439]
    [cljs.analyzer$analyze_STAR_ invoke "analyzer.cljc" 3429]
    [cljs.analyzer$analyze invokeStatic "analyzer.cljc" 3463]
    [cljs.analyzer$analyze invoke "analyzer.cljc" 3446]
-   [cljs.analyzer$analyze_seq invokeStatic "analyzer.cljc" 3245]
-   [cljs.analyzer$analyze_seq invoke "analyzer.cljc" 3222]
-   [cljs.analyzer$analyze_form invokeStatic "analyzer.cljc" 3391]
-   [cljs.analyzer$analyze_form invoke "analyzer.cljc" 3387]
-   [cljs.analyzer$analyze_STAR_ invokeStatic "analyzer.cljc" 3438]
-   [cljs.analyzer$analyze_STAR_ invoke "analyzer.cljc" 3429]
-   [cljs.analyzer$analyze invokeStatic "analyzer.cljc" 3463]
-   [cljs.analyzer$analyze invoke "analyzer.cljc" 3446]
    [cljs.analyzer$analyze invokeStatic "analyzer.cljc" 3455]
    [cljs.analyzer$analyze invoke "analyzer.cljc" 3446]
    [cljs.analyzer$analyze invokeStatic "analyzer.cljc" 3453]
    [cljs.analyzer$analyze invoke "analyzer.cljc" 3446]
    [cljs.analyzer$analyze_let_binding_init invokeStatic "analyzer.cljc" 1761]
    [cljs.analyzer$analyze_let_binding_init invoke "analyzer.cljc" 1759]
    [cljs.analyzer$analyze_let_bindings_STAR_ invokeStatic "analyzer.cljc" 1781]
    [cljs.analyzer$analyze_let_bindings_STAR_ invoke "analyzer.cljc" 1770]
    [cljs.analyzer$analyze_let_bindings invokeStatic "analyzer.cljc" 1812]
    [cljs.analyzer$analyze_let_bindings invoke "analyzer.cljc" 1811]
    [cljs.analyzer$analyze_let invokeStatic "analyzer.cljc" 1827]
    [cljs.analyzer$analyze_let invoke "analyzer.cljc" 1822]
    [cljs.analyzer$eval2303$fn__2304 invoke "analyzer.cljc" 1848]
    [clojure.lang.MultiFn invoke "MultiFn.java" 251]
    [cljs.analyzer$analyze_seq_STAR_ invokeStatic "analyzer.cljc" 3215]
    [cljs.analyzer$analyze_seq_STAR_ invoke "analyzer.cljc" 3213]
    [cljs.analyzer$analyze_seq_STAR__wrap invokeStatic "analyzer.cljc" 3220]
    [cljs.analyzer$analyze_seq_STAR__wrap invoke "analyzer.cljc" 3218]
    [cljs.analyzer$analyze_seq invokeStatic "analyzer.cljc" 3244]
    [cljs.analyzer$analyze_seq invoke "analyzer.cljc" 3222]
--- 1,32 ----
Comment by David Nolen [ 11/Jul/17 7:07 AM ]

Thanks! Feedback on the latest patch:

  • Lift out the internal aliasing in resolve-var into a helper.
  • the change to compile-file is too aggressive and problematic for compiler devs. Just update-in to set :invalid-array-access to false or the value of *invalid-array-access* so it can be manually overridden.

Otherwise looks good. Still looking into the double warning issue.

Comment by Mike Fikes [ 11/Jul/17 8:39 AM ]

Added CLJS-2198-v5.patch which addresses the two issues in the last comment, but not the double-warning issue.

The lifting of the aliasing is pretty straightforward. (You might have nits about names, etc.)

Take a look at the updated code surrounding build-affecting options. It was revised a little more heavily than you had suggested in the comment, largely around the idea of properly handing {:warnings true} as being another way that :invalid-array-access can get set. The stuff put in the build-affecting comment when enabled is simply :invalid-array-access-warning-enabled true.

Comment by David Nolen [ 11/Jul/17 10:36 AM ]

Based on the feedback so far it looks like we need to emphasize runtime warnings and not hard errors if users are going to be productive with this enabled.

  • add `:checked-arrays` compiler flag which is either false-y, :warn, :error
  • use this option to set the relevant analyzer warnings
  • add `checked-aget'`, `checked-aset'` which allocate an Error to get the raw stacktrace
  • use the warning variants based on the `:checked-arrays` setting
Comment by David Nolen [ 11/Jul/17 4:54 PM ]

The double warning issue is because the check AST pass doesn't mark AST nodes as being analyzed. Just call `analyzed` on the returned `ast` and don't check the `ast` argument if `analyzed?` returns true on it.

Comment by Mike Fikes [ 11/Jul/17 5:14 PM ]

CLJS-2198-v6.patch addresses the double warning.

Remaining known issues include the "knob" revisions that allow users to choose to have either only static analysis warnings or that plus runtime checks.

There is also a problem with initial compile behaving strangely in a real-world project:

What I see occur: I set :warnings true. Then lein clean, lein figwheel. My code gets compiled by Figwheel when it starts up, but no warnings appear. If I look at the JavaScript in my out directory, I see the {:invalid-array-access-warning-enabled true} build-affecting option recorded, but I don't see checked-aget in the JavaScript. If I then go in the REPL and use :reload on a namespace, I then see warnings appear in the REPL console, and if I go back and look at the JavaScript in out, the unchecked

return (({"foo": (1)})["foo"])
code snippets are replaced with code using checked_aget:
return cljs.core.checked_aget.call(null,({"foo": (1)}),"foo");

Comment by Mike Fikes [ 11/Jul/17 7:55 PM ]

The CLJS-2198-v7.patch patch addresses the "knob" idea.

Before providing notes on the changes to implement it, here is a high-level description of the feature that would be targeted to users (this helps ensure we are on the same page with respect to the behavior of the feature):

A new compiler option exists, :checked-arrays. If not set (or set to a false-y value), the compiler behaves as before. If set to :warn, then, where possible via static type inference, warnings will be emitted for passing invalid arguments to aget/aset. The warnings will be emitted via the :invalid-array-access warning key, which is enabled by default, but can be suppressed by setting it to false. If set to :error, in addition to the warning behavior just described, runtime checks will be made for proper values being passed (array objects, and indices within bounds), with these being in the form of assertions (thus, subject to :elide-asserts). When compiling in :advanced mode, all this is disabled (as if :checked-arrays were set to false).

Implementation notes:

Renamed *unchecked-array-access* to *unchecked-arrays* (for consistency with :checked-arrays, and it seems closer in naming to *unchecked-if*). A minor note is that this is not included in the user-targeted description above (it seems just as "internal" as *unchecked-if*). Let me know if this rename is undesired and I'll revert it.

Whereas previous patches had an ana/emit-safe-array-access?, it has been revised with a new ana/checked-arrays, which returns false-y, :warn, or :error, and this is used to drive macroexpansion and aliasing (to pick between unchecked, type-inference-checked (checked-aget), or runtime-value-checked (checked-aget')). This is not simply the compiler option :checked-arrays value, but is guarded by looking to see that we are not in :advanced, and that *unchecked-arrays* hasn't been set (if either are true, it will return false-y).

The new checked-aget'/checked-aset' are just like the older checked-aget/checked-aset, while checked-aget/checked-aset are just there (without :pre) in order for the type inference analsysis pass to hook on.

The build-affecting story becomes simpler now: it is just the :checked-arrays compiler option that is build-affecting. We dissoc that option if compiling cljs.core.

The :invalid-array-access warning is on by default in the latest patch, and really exists if a user wants to write custom code to react to it in a certain way (using cljs.analyzer/with-warning-handlers), or if a user wants to suppress it by setting :warnings {:invalid-array-access false}.

The patch doesn't try to use :checked-arrays to set :invalid-array-access, nor :invalid-array-access to set :checked-arrays.

I think other aspects of the patch are straightforward; the above probably covers the aspects worth explaining.

The patch doesn't attempt to address the "initial compile" issue.

Comment by Mike Fikes [ 12/Jul/17 7:12 AM ]

CLJS-2198-v8.patch exposes feature to cljs.js and employs a dynamic Var (mimicking the way :static-fns is handled), as opposed to directly looking in the compiler environment for the option.

Tested :checked-arrays successfully downstream with Planck:

cljs.user=> (aget #js {:foo 1} "foo")
1
cljs.user=> (swap! planck.repl/app-env assoc :checked-arrays :warn)
{:repl true, :verbose false, :cache-path "/Users/mfikes/.planck_cache", :opts {}, :checked-arrays :warn}
cljs.user=> (aget #js {:foo 1} "foo")
            ^
WARNING: cljs.core/aget, arguments must be an array followed by numeric indices, got [object string] instead (consider goog.object/get for object access) at line 1
1
cljs.user=> (swap! planck.repl/app-env assoc :checked-arrays :error)
{:repl true, :verbose false, :cache-path "/Users/mfikes/.planck_cache", :opts {}, :checked-arrays :error}
cljs.user=> (aget #js {:foo 1} "foo")
            ^
WARNING: cljs.core/aget, arguments must be an array followed by numeric indices, got [object string] instead (consider goog.object/get for object access) at line 1
Assert failed: (or (array? array) (js/goog.isArrayLike array))
	cljs.core/checked-aget' (cljs/core.cljs:445:1)

Assigning ticket to me to look into initial compile issue.

Comment by Mike Fikes [ 12/Jul/17 8:41 AM ]

It turns out that CLJS-2198-v8.patch fixed the "initial compile" problem.

Attaching CLJS-2198-v9.patch which revises the behavior so that if :checked-arrays is set to :warn and a runtime invoke is made with invalid arguments, it does the same checks as :pre and logs the resulting exception.

Comment by Mike Fikes [ 12/Jul/17 6:08 PM ]

CLJS-2198-v10.patch rebaselines, adds unit test coverage for unchecked-get, aget, checked-get, checked-get', and their -set variants, and fixes an issue with maybe-warn where exists? needs to be used instead of some? when checking for the existence of js/console.warn.

Comment by Mike Fikes [ 13/Jul/17 12:42 PM ]

CLJS-2198-v11.patch rebaselined (note: unit tests haven't passed for it as master is currently failing)

Comment by David Nolen [ 13/Jul/17 3:08 PM ]

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





[CLJS-2206] Refactor :npm-deps functionality to use indexed node_modules instead of handling missing modules in special pass Created: 10/Jul/17  Updated: 13/Jul/17  Resolved: 13/Jul/17

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

Type: Task Priority: Critical
Reporter: David Nolen Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: js-modules, nodejs, npm-deps

Approval: Vetted

 Description   

Doing this will have the added benefit in supporting enhancements to the Node.js target. By indexing `node_modules` up front we can later determine how a particular library should be required - either `goog.require` or CommonJS `require`.



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

Depends on CLJS-2211

Comment by David Nolen [ 11/Jul/17 5:35 PM ]

Partially addressed by CLJS-2212. We should audit / remove any vestigial missing-js-modules logic if there is any.





[CLJS-1955] data_readers.cljc can't reference handlers in user code Created: 27/Feb/17  Updated: 13/Jul/17  Resolved: 13/Jul/17

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

Type: Defect Priority: Critical
Reporter: Dustin Getz Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: reading
Environment:

clojurescript 1.9.456-493


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

 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`



 Comments   
Comment by David Nolen [ 08/Jul/17 10:08 AM ]

The patch must come with a test case.

Comment by António Nuno Monteiro [ 08/Jul/17 5:12 PM ]

Patch attached.

Comment by David Nolen [ 13/Jul/17 5:04 PM ]

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





[CLJS-2230] Double checked arrays Created: 13/Jul/17  Updated: 14/Jul/17  Resolved: 14/Jul/17

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

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

Approval: Vetted

 Description   

If you have an aget passed as a form to a macro like or it will get analyzed twice and trigger the diagnostic.

Example:

cljs.user=> (and true (or (aget #js {:foo 1} "foo") 2))
WARNING: cljs.core/aget, arguments must be an array followed by numeric indices, got [object string] instead (consider goog.object/get for object access) at line 1 <cljs repl>
WARNING: cljs.core/aget, arguments must be an array followed by numeric indices, got [object string] instead (consider goog.object/get for object access) at line 1 <cljs repl>
WARNING: cljs.core/aget, arguments must be an array followed by numeric indices, got [object string] instead (consider goog.object/get for object access) at line 1 <cljs repl>
WARNING: cljs.core/aget, arguments must be an array followed by numeric indices, got [object string] instead (consider goog.object/get for object access) at line 1 <cljs repl>
Error: Assert failed: (or (array? array) (js/goog.isArrayLike array))
...


 Comments   
Comment by David Nolen [ 14/Jul/17 5:54 AM ]

fixed https://github.com/clojure/clojurescript/commit/424e26415476ed302098d37fd2d3cc0e6d5a3051





[CLJS-2239] Self-host: Add `:target :nodejs` to the docstrings in cljs.js Created: 14/Jul/17  Updated: 16/Jul/17  Resolved: 16/Jul/17

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

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

Attachments: Text File CLJS-2239.patch    
Patch: Code
Approval: Accepted

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

fixed https://github.com/clojure/clojurescript/commit/8429372b13a06fd90c69eb296c6fd63980557326





[CLJS-1801] Foreign libs that are processed as modules should not have their exports invoked with fn optimizations Created: 30/Sep/16  Updated: 16/Jul/17  Resolved: 16/Jul/17

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

Type: Defect Priority: Critical
Reporter: David Nolen Assignee: David Nolen
Resolution: Not Reproducible Votes: 0
Labels: None


 Comments   
Comment by David Nolen [ 13/Jul/17 7:14 PM ]

This may no longer effect master? Previously I believe there was case encountered where a module export was treated as ClojureScript fn and there was a direct invoke?

Comment by David Nolen [ 16/Jul/17 1:43 AM ]

Closing this one since there's just not enough information to act on.





[CLJS-1904] Reload support for JS Modules Created: 25/Jan/17  Updated: 16/Jul/17  Resolved: 16/Jul/17

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

Type: Enhancement Priority: Critical
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed 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.



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

As far as I can tell this issue is resolved now in master in the general case. There maybe edge cases but we should open issues as we encounter them.





[CLJS-2248] Build API tests rely on Yarn Created: 15/Jul/17  Updated: 16/Jul/17  Resolved: 16/Jul/17

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

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

Attachments: Text File CLJS-2248.patch    
Patch: Code
Approval: Accepted

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

The patch needs to be rebased to master.

Comment by António Nuno Monteiro [ 16/Jul/17 11:47 AM ]

Replaced the patch with a new one that applies on current master.

Comment by David Nolen [ 16/Jul/17 5:53 PM ]

fixed https://github.com/clojure/clojurescript/commit/576f2865289d68743597022033c6752c8d0ebc18





[CLJS-2254] Module Indexing: Provide relative paths for a package's main module Created: 16/Jul/17  Updated: 17/Jul/17  Resolved: 17/Jul/17

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

Type: Enhancement Priority: Critical
Reporter: António Nuno Monteiro Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: js-modules, npm-deps

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

 Comments   
Comment by António Nuno Monteiro [ 16/Jul/17 8:14 PM ]

The attached patch also provides tests for previously untested `module_deps.js` indexing to make sure it's at parity with the indexing on the Clojure side.

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

fixed https://github.com/clojure/clojurescript/commit/7139c4c17932b1e11e7a2b665914b32936f02644





[CLJS-1] Pattern used in path-seq is not portable Created: 21/Jul/11  Updated: 28/Jul/11  Resolved: 28/Jul/11

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

Type: Defect Priority: Major
Reporter: Paul Bauer Assignee: Brenton Ashworth
Resolution: Completed Votes: 1
Labels: None
Environment:

Any environment that uses '\' as its default path separator.


Attachments: File portable-path-regex.diff     File portable-path-regex-properly-annotated.diff    
Patch: Code

 Description   

The pattern used in cljs/compiler.clj to generate a path sequence is not portable.
Every execution of cljsc throws a Pattern error in some environments.



 Comments   
Comment by Brenton Ashworth [ 25/Jul/11 7:54 AM ]

Here is the related conversation on the mailing list.

http://groups.google.com/group/clojure/browse_thread/thread/90e6c22b8224ded6

Comment by Paul Bauer [ 25/Jul/11 10:49 PM ]

Re-uploading patch (portable-path-regex-propertly-annotated.diff).
Previous patch did not have the proper name and email address associated with the CA.

Comment by Marko Kocić [ 26/Jul/11 6:54 AM ]

The attached patch solves only a part of the issue. After applying the patch I was still not able to compile twitterbuzz. Here's the exception I got:

c:\development\cvstree\clojurescript\samples\twitterbuzz>..\..\bin\cljsc src > twitterbuzz.js
Exception in thread "main" java.lang.RuntimeException: java.io.FileNotFoundException: The file C:\development\cvstree\clojurescript\src\cljs\cljs%5ccore.cljs does not exist.
at clojure.lang.Util.runtimeException(Util.java:153)
at clojure.lang.Compiler.eval(Compiler.java:6417)
at clojure.lang.Compiler.load(Compiler.java:6843)
at clojure.lang.Compiler.loadFile(Compiler.java:6804)
at clojure.main$load_script.invoke(main.clj:282)
at clojure.main$script_opt.invoke(main.clj:342)
at clojure.main$main.doInvoke(main.clj:426)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:405)
at clojure.lang.AFn.applyToHelper(AFn.java:163)
at clojure.lang.Var.applyTo(Var.java:518)
at clojure.main.main(main.java:37)
Caused by: java.io.FileNotFoundException: The file C:\development\cvstree\clojurescript\src\cljs\cljs%5ccore.cljs does not exist.
at cljs.compiler$compile_file.invoke(compiler.clj:1135)
at cljs.closure$compile_file.invoke(closure.clj:224)
at cljs.closure$eval1132$fn__1133.invoke(closure.clj:266)
at cljs.closure$eval1068$fn_1069$G1059_1076.invoke(closure.clj:187)
at cljs.closure$eval1119$fn__1120.invoke(closure.clj:280)
at cljs.closure$eval1068$fn_1069$G1059_1076.invoke(closure.clj:187)
at cljs.closure$eval1127$fn__1128.invoke(closure.clj:271)
at cljs.closure$eval1068$fn_1069$G1059_1076.invoke(closure.clj:187)
at cljs.closure$get_compiled_cljs.invoke(closure.clj:421)
at cljs.closure$cljs_dependencies.invoke(closure.clj:451)
at cljs.closure$add_dependencies.doInvoke(closure.clj:473)
at clojure.lang.RestFn.applyTo(RestFn.java:139)
at clojure.core$apply.invoke(core.clj:602)
at cljs.closure$build.invoke(closure.clj:712)
at user$eval1266.invoke(cljsc.clj:21)
at clojure.lang.Compiler.eval(Compiler.java:6406)
... 10 more

Comment by Brenton Ashworth [ 26/Jul/11 9:04 AM ]

Marko,

I did some work on Windows issues yesterday and found and fixed this problem as well as a few others. I will apply this patch and my fixes today.

Comment by Brenton Ashworth [ 26/Jul/11 12:53 PM ]

The following two commits fix this problem as well as all other problems that I found while trying the compile the sample apps on Windows within the Cygwin environment.

https://github.com/clojure/clojurescript/commit/add1dfcdbb68c2d98ff62f999c094f536c842f78
https://github.com/clojure/clojurescript/commit/d38729e66631bd649dc7c87f70e9b501d58da266

Comment by Marko Kocić [ 27/Jul/11 2:14 AM ]

I can confirm that compile now works correctly on windows.
I tested it in plain windows (no cygwin) using my patch for adding cmdline scripts which is attached to #CLJS-24





[CLJS-34] fns should hash by identity Created: 23/Jul/11  Updated: 29/Jul/11  Resolved: 29/Jul/11

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

Type: Enhancement Priority: Major
Reporter: Stuart Halloway Assignee: Stuart Halloway
Resolution: Completed Votes: 0
Labels: None

Approval: Ok

 Description   

currently hit -hash missing when you try to make them e.g. map keys.

I have committed a fix (https://github.com/clojure/clojurescript/commit/22a64ff17b343b6c61039fcb66fd9acf34d98522) which uses goog.getUid for function objects. While I don't like goog.getUid for arbitrary objects, I think it is a good fit for functions, which need to hash by identity, but only occasionally.



 Comments   
Comment by Rich Hickey [ 29/Jul/11 8:35 AM ]

ok by me





[CLJS-32] Implement range Created: 22/Jul/11  Updated: 23/Jul/11  Resolved: 23/Jul/11

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

Type: Defect Priority: Major
Reporter: Benjamin Teuber Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None


 Description   

I guess range is not yet implemented due to chunking etc. implementation, but a simple version would do for now.



 Comments   
Comment by Benjamin Teuber [ 22/Jul/11 7:29 PM ]

Sorry, duplicate - please delete..

Comment by Devin Walters [ 23/Jul/11 7:41 PM ]

See: http://dev.clojure.org/jira/browse/CLJS-6





[CLJS-49] ClojureScript breaks goog.fx.dom.BgColorTransform Created: 01/Aug/11  Updated: 03/Aug/11  Resolved: 03/Aug/11

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

Type: Defect Priority: Major
Reporter: Sergey Didenko Assignee: Brenton Ashworth
Resolution: Completed Votes: 0
Labels: None

Attachments: File bg-color.cljs     HTML File bg-color.html     GZip Archive test.tar.gz    

 Description   

The following JS snippet in Google Closure works. (It animates the background color of the elem):

var transform = new goog.fx.dom.BgColorTransform(elem, start, end, 2000);
return transform.play();

The following CLJS code:

(ns bgcolor
(:require [goog.fx.dom :as fx-dom]))

(defn ^:export animate [elem start end]
(let [anim (fx-dom/BgColorTransform. elem start end 2000)]
(.play anim)))

gets compiled to (the final part in whitespace mode)

goog.provide("bgcolor");goog.require("cljs.core");goog.require("goog.fx.dom");bgcolor.animate=function animate(elem,start,end){var anim__1960=new goog.fx.dom.BgColorTransform(elem,start,end,2E3);return anim__1960.play};goog.exportSymbol("bgcolor.animate",bgcolor.animate);

and looks ok but does not work neither in whitespace mode nor in advanced mode

See the attached files for full examples.



 Comments   
Comment by Sergey Didenko [ 01/Aug/11 5:33 PM ]

I used the wrong syntax for calling function without args.

Must be (.play anim ()) or (. anim (play))

Comment by Sergey Didenko [ 01/Aug/11 5:34 PM ]

Please close this, I can't find the way to do it.





[CLJS-38] add range function Created: 27/Jul/11  Updated: 28/Jul/11  Resolved: 28/Jul/11

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

Type: Enhancement Priority: Major
Reporter: Arthur Ulfeldt Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None

Attachments: File add-range-function.diff    
Patch: Code and Test

 Description   

implament the range function in core.cljs



 Comments   
Comment by Arthur Ulfeldt [ 27/Jul/11 3:54 AM ]

duplicate of CLJS-6.
moved the patch there.





[CLJS-59] destructured locals in loops are closed over incorrectly Created: 20/Aug/11  Updated: 23/Sep/11  Resolved: 23/Sep/11

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

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


 Description   

This is just like CLJS-22 except requires destructuring in the loop binding to trigger the error:

(loop [[_ i] [:dmy 0] j ()]
  (if (< i 5)
    (recur [:dmy (inc i)]
           (conj j (fn [] i)))
    (map #(%) j)))

ClojureScript incorrectly returns: (5 5 5 5 5)

Clojure correctly returns: (4 3 2 1 0)



 Comments   
Comment by David Nolen [ 23/Sep/11 1:08 AM ]

duplicate of CLJS-39





[CLJS-71] Add reify Created: 11/Sep/11  Updated: 13/Sep/11  Resolved: 13/Sep/11

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

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

Attachments: Text File 71-reify-2.patch     Text File 71-reify.patch    

 Comments   
Comment by David Nolen [ 12/Sep/11 1:54 AM ]

A patch to add reify.

Comment by David Nolen [ 13/Sep/11 12:51 AM ]

A much, much simpler patch that I think has all the desired properties. Leverages deftype since deftype has all the machinery required for dealing with fields, uses the namespace itself as the cache.

Comment by Rich Hickey [ 13/Sep/11 6:48 AM ]

I've made you a member - go ahead and apply this.

Comment by David Nolen [ 13/Sep/11 7:54 AM ]

Done, 791834558b61459ece6c124af6186580a65128a1





[CLJS-73] add :externs and :use-only-custom-externs options Created: 12/Sep/11  Updated: 14/Sep/11  Resolved: 14/Sep/11

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

Type: Task Priority: Major
Reporter: John Li Assignee: Brenton Ashworth
Resolution: Completed Votes: 0
Labels: None

Attachments: File external.js     File externs.diff     File externs.js     File test.cljs     HTML File test.html    

 Description   

One bit I'm not sure of is whether :use-only-custom-externs on nodejs should include "cljs/nodejs_externs.js". In the current patch, it doesn't. You would have to specify it manually.

:use-only-custom-externs is also untested.

I've attached a small test.
external.js defines external.fn(str) (which is just toUpperCase).
test.cljs defines test.main which calls external.fn.
test.html sources external.js and test.js (the advanced-compiled test.cljs) and calls external.fn directly and then via test.main.
externs.js gives an empty definition of external.fn.

Without the patch, (my) advanced-compiled test.js renames external.fn to external.K. When compiled with :externs (./bin/cljsc test.cljs '{:optimizations :advanced :output-to "test.js" :externs ["externs.js"]}'), external.fn is left alone.

Closure reference: https://code.google.com/closure/compiler/docs/api-tutorial3.html#mixed



 Comments   
Comment by John Li [ 12/Sep/11 11:20 PM ]

Adding rest of the test files.

Comment by Brenton Ashworth [ 14/Sep/11 3:39 PM ]

A patch for this was submitted under a different issue: CLJS-10.

I have applied that patch to the externs branch.

Please test your code with those changes to ensure that this works for you or to discover if more work needs to be done. If you run into problems, comment on that issue or on the Clojure dev mailing list.

Thanks for the patch and sorry for the confusion.

Comment by Brenton Ashworth [ 14/Sep/11 3:40 PM ]

Duplicate issue.





[CLJS-90] Browser repl does not work if the JVM working directory is not the CLJS directory Created: 14/Oct/11  Updated: 28/Oct/11  Resolved: 28/Oct/11

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

Type: Defect Priority: Major
Reporter: Luke VanderHart Assignee: Brenton Ashworth
Resolution: Declined Votes: 0
Labels: None
Environment:

MacOS 10.6.8, Java SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)



 Description   

The browser repl hangs if the JVM working directory is not in the CLJS repository ($CLOJURESCRIPT_HOME). This is an odd and nonintuitive restriction.

For example, if my machine has $CLOJURESCRIPT_HOME set to ~/src/clojurescript, and I'm using emacs inferior lisp:

Dired to ~/src/clojurescript, set inferior-lisp-program to "script/repl", everything works fine.

Dired to ~/src/foo, set inferior-lisp-program to "../clojurescript/script/repl", the Clojure repl starts up fine, but the ClojureScript repl hangs.

This is not a classpath error: I have verified that the classpath is identical in both cases. Everything except the ClojureScript repl works in both cases.

Nor is it an error with the 'script/repl' startup script - I was initially using my own startup script in a completely separate directory, which is where I discovered the problem.



 Comments   
Comment by David Nolen [ 16/Oct/11 12:39 PM ]

Does this problem occur at the command line sans Emacs?

Comment by Brenton Ashworth [ 17/Oct/11 9:37 AM ]

I can't reproduce the problem.

Here is what I did:

  • Create directory foo next to clojurescript
  • cd foo & cp -a ../clojurescript/samples/repl/* .
  • In emacs
    • dired to foo
    • M-x set-variable
      • inferior-lisp-program
      • "../clojurescript/script/repl"
    • M-x run-lisp
  • In the REPL
    • (use 'cljs.closure)
    • (def opts {:output-to "main.js" :output-dir "out"})
    • (build "src" opts)
    • (require '[cljs.repl :as repl])
    • (require '[cljs.repl.browser :as browser])
    • (def env (browser/repl-env))
    • (repl/repl env)
  • Open foo/index.html in browser

At this point everything works.

I also tried doing the same from the command line, just running ../clojurescript/script/repl which also worked.

Comment by Luke VanderHart [ 28/Oct/11 1:59 PM ]

I've replicated your steps and it works.

There must be something more subtle and complex going on with my shell environment. I will try to isolate it - I'll let you know if there's anything in ClojureScript that needs to be fixed.

In the meantime, we can close this ticket as "cannot reproduce" since apparently it's only happening on some of my projects, reason TBD.

Thanks!

Comment by Luke VanderHart [ 28/Oct/11 2:00 PM ]

Cannot reproduce, suspect user error. Will re-open if ClojureScript does turn out to be at fault.





[CLJS-309] Bug - Typo in commit "Tagged literals in the CLJS compiler and first blush tests " Created: 08/Jun/12  Updated: 08/Jun/12  Resolved: 08/Jun/12

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

Type: Defect Priority: Major
Reporter: Raphaël AMIARD Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug

Attachments: Text File fix-data-readers-typo.patch    
Patch: Code

 Description   

I'm pretty sure there is a typo in this commit,

cljs-data-readers is declared, but then data-readers is bound in compile-file, which makes compilation fail

Patch attached



 Comments   
Comment by Fogus [ 08/Jun/12 8:43 AM ]

I'm unable to reproduce this. Do you mind posting the steps that you ran to see the error?
Thank you.

Comment by Raphaël AMIARD [ 08/Jun/12 10:48 AM ]

Sorry, i failed to follow the implications of CLJ-890, the bug was related to my configuration, and the binding valid.





[CLJS-58] ClojureScript places fully qualified keywords in the user namespace Created: 19/Aug/11  Updated: 05/Dec/11  Resolved: 16/Sep/11

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

Type: Defect Priority: Major
Reporter: Paul Bauer Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

(ns testns)

(pr-str "kw: " ::kwtest " ns: " (namespace ::kwtest))
==> ("kw: " :user/kwtest "ns: " "user")

while in clojure:
(ns testns)

(pr-str "kw: " ::kwtest " ns: " (namespace ::kwtest))
==> ("kw: " :testns/kwtest "ns: " "testns")



 Comments   
Comment by Paul Bauer [ 19/Aug/11 12:55 AM ]

https://groups.google.com/d/topic/clojure/LQYU55mPbHY/discussion

Comment by David Nolen [ 16/Sep/11 8:32 PM ]

duplicate of CLJS-74

Comment by Jeremy Hughes [ 16/Oct/11 6:21 AM ]

This affects more than just the repl.

Comment by Radford Smith [ 05/Dec/11 12:06 AM ]

Yeah, this seems to happen in normally compiled code. Am I missing something or does this need to be reopened?

Comment by David Nolen [ 05/Dec/11 8:21 AM ]

So you see the correct behavior at the REPL but not compiled code?





[CLJS-108] Colon characters in symbols don't look to be interpreted correctly in compiled code Created: 29/Nov/11  Updated: 05/Dec/11  Resolved: 04/Dec/11

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

Type: Defect Priority: Major
Reporter: Benjamin Conlan Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None
Environment:

OSX 10.7



 Description   

Compiled javascript source files are not outputting the colon character correctly. I have a feeling that this might have something to do with closure-latest (bootstrapped as of 28th Nov)

the cljs source

`(def colon-test [:symbol-name])`

outputs

`cljs.user.colon_test = cljs.core.Vector.fromArray(["﷐'symbol-name"]);`



 Comments   
Comment by Benjamin Conlan [ 29/Nov/11 6:03 AM ]

using: `(def colon-test [":symbol-name"])`
outputs: `cljs.user.colon_test = cljs.core.Vector.fromArray([":symbol-name"]);`

which as outlined in the differences from clojure (https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure) stating that they are javascript string is a simple work around.

As such, this issue should be lowered to minor.

Comment by Benjamin Conlan [ 04/Dec/11 8:30 PM ]

I've just noticed on the mailing list this is identified using the

'
character also:

http://groups.google.com/group/clojure/browse_thread/thread/b4f0c335067ca74d/36d34b5d151d2ad0?lnk=gst&q=clojurescript+core#36d34b5d151d2ad0

The solution seems to be to use a page encoding of utf-8 (which is great when using javascript in a browser).

Comment by David Nolen [ 04/Dec/11 9:28 PM ]

Keywords and symbols are just JavaScript strings with a special unicode code character. ClojureScript requires the utf-8 meta tag to function properly in most browsers.

Comment by Benjamin Conlan [ 05/Dec/11 9:53 PM ]

Yes, again I've just found this link http://groups.google.com/group/clojure/browse_thread/thread/6613fcf1a9129c3a which clarifies the logic.

I noticed that closure has a `--charset=[charset-name]` flag which might help me out as i'm not playing with this stuff in a browser (at least for the moment).





[CLJS-99] Allow names from cljs.core to be properly resolved Created: 11/Nov/11  Updated: 15/Dec/11  Resolved: 15/Dec/11

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

Type: Enhancement Priority: Major
Reporter: Chris Gray Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: File cljs-name-resolving.diff     File cljs-name-resolving.diff    
Patch: Code

 Description   

It is not currently possible to redefine functions from cljs.core. For example, the following cljs:

(defn first [x]
1)

(first 2)

compiles to:

cljs.core.first = (function first{ return 1; });
cljs.core.first.call(null,2);

With the attached patch, it compiles to:

voronoi_diagram.rationals.first = (function first{ return 1; }
});
voronoi_diagram.rationals.first.call(null,2);

which is correct.



 Comments   
Comment by Chris Gray [ 11/Nov/11 6:26 PM ]

I have signed and sent the CA, though it was recently and might not be received yet.

Comment by Chris Gray [ 11/Nov/11 7:13 PM ]

It was also necessary to remove some macros that are also defined as functions in cljs.core, since I need to redefine some of these functions in my project.

I have not checked that all the macros that I removed are implemented as functions, but at first glance they appear to be.

Comment by David Nolen [ 20/Nov/11 1:26 PM ]

Thanks, but a patch to add compiler support for :refer-clojure :exclude is preferred. This would allow for the desired behavior w/o penalizing people who want fast arithmetic.

Comment by David Nolen [ 15/Dec/11 8:43 PM ]

This actually already works, you just need to exclude the symbol you want to redefine

code
(ns foo.bar
(:refer-clojure :exclude [first]))
code

Comment by David Nolen [ 15/Dec/11 8:43 PM ]

This actually already works, you just need to exclude the symbol you want to redefine

code
(ns foo.bar
(:refer-clojure :exclude [first]))
code





[CLJS-329] Cannot reference protocols using dot syntax (cljs.core.ILookup). Created: 29/Jun/12  Updated: 30/Jun/12  Resolved: 30/Jun/12

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

Type: Defect Priority: Major
Reporter: Kevin Lynagh Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: None


 Description   

One used to be able to reference protocols using dot-separators; e.g.,

(satisifies? cljs.core.ILookup {:a 1}) ;;=> true

however, after CLJS commit 2aeb3d8f this is no longer possible.
These forms work correctly:

(satisfies? cljs.core/ILookup {:a 1})
(satisfies? ILookup {:a 1})

This issue came to my attention because core.match uses the cljs.core.ILookup form, so if that gets depreciated, downstream libraries will have to be updated.



 Comments   
Comment by Michał Marczyk [ 29/Jun/12 7:12 PM ]

Note that extend-protocol in Clojure expects the foo.bar/IQuux form (or IQuux in same namespace / after :use) and refuses to work with foo.bar.Quux. That's because in contrast to types and records, protocols actually expose a Var. The dotted name refers to the interface backing the protocol and seems to be an implementation detail.

So, I think the current behaviour is in line with how things are in Clojure.

Comment by Kevin Lynagh [ 29/Jun/12 8:47 PM ]

Matching the syntax of JVM Clojure sounds reasonable to me.
I take it I should close this issue and open up a ticket/patch core.match to use the correct syntax?

Comment by Kevin Lynagh [ 30/Jun/12 12:11 PM ]

Patch opened on downstream lib:

http://dev.clojure.org/jira/browse/MATCH-62





[CLJS-143] (hash obj-map) inappropriately depends on key order. Created: 03/Feb/12  Updated: 06/Feb/12  Resolved: 03/Feb/12

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

Type: Defect Priority: Major
Reporter: Kevin Lynagh Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 1a70326a25009cdddca56db0584bc157595ce1a9.patch    
Patch: Code and Test

 Description   

Seqing on obj-maps moves in key insertion order, which can lead to different hash values for maps with equal key/value pairs.
This issue is related to CLJS-118, and attached patch fixes it in the same way (i.e., seq in sorted key order).

Commit here

https://github.com/lynaghk/clojurescript/tree/143-hash-obj-map



 Comments   
Comment by David Nolen [ 03/Feb/12 7:05 PM ]

Fixed, https://github.com/clojure/clojurescript/commit/d9190cb4d4145a0cc1f0ebf0632e530a1a8b6023

Comment by Dave Sann [ 06/Feb/12 9:26 PM ]

There appears to still be an issue with this in the following scenario:

(ns test
  (:require [cljs.reader :as reader]))

(defn log [x]
  (.log js/console (pr-str x))
  x)

(def data
 {{:start 143  :end 144}  "data" })

(log {:data data})

(doseq [k (keys data)]  
  (let [ks (pr-str k)
        kr (reader/read-string ks)]
    (log  {:k      k 
           :v      (get data k)
           :k-hash (hash k)
           :read-k kr
           :read-k-hash (hash kr)
           :read-v (get data kr)})))

my output:

{:data {{:end 144, :start 143} "data"}}
{:k {:end 144, :start 143},
 :k-hash 40749209, 
 :read-k {:start 143, :end 144}, 
 :read-k-hash -1503612376, 
 :read-v nil, 
 :v "data"}

I have checked my cljs version and the patch has been applied.
can this be confirmed?

Comment by David Nolen [ 06/Feb/12 10:15 PM ]

Fixed, https://github.com/clojure/clojurescript/commit/e3854ccef19d1ceb427bb2ba7cd0ac3633dc7d0e





[CLJS-535] Update ClojureScript to use the new Google Closure releases from maven central Created: 08/Jul/13  Updated: 27/Jul/13  Resolved: 27/Jul/13

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

Type: Enhancement Priority: Major
Reporter: Stephen Nelson Assignee: Stuart Sierra
Resolution: Completed Votes: 0
Labels: None


 Description   

ClojureScript is currently using 20120710-r2029, which is several versions out of date. The most recent zip version available was released in December 2012 and it seems there won't be any more of that form as Google Closure has migrated to git and is pushing versions to maven central using a new version scheme (https://code.google.com/p/closure-compiler/wiki/Maven). The latest release is v20130603.

I think ClojureScript needs to switch to using the maven central releases, and it would be good to have a process/plan in place for getting more regular library updates.



 Comments   
Comment by Stephen Nelson [ 08/Jul/13 6:37 PM ]

I think I've misunderstood the difference between the Closure compiler and the Closure libraries. The compiler is being regularly release to central (as you are obviously aware - it's used in the build process) but the libraries don't seem to be being released at all since the switch to git. I can't find any references to a release plan for the closure libraries: this seems like something ClosureScript is going to need to deal with. There are several features that have been added to the libraries in the last year that would be 'nice to have'.

Comment by Jonas Enlund [ 09/Jul/13 12:33 AM ]

Here's a list of all closure-library releases: https://code.google.com/p/closure-library/downloads/list. The version ClojureScript is using today is r2029 from July 2012. The latest version is from February 2013.

I suspect they don't ship the closure-library to maven central since it doesn't contain any Java code.

Comment by David Nolen [ 16/Jul/13 6:20 AM ]

There's no process for staying up to date with closure-library beyond having the periodically bundle it and release them ourselves. More than happy to bump provided that someone tests that the latest versions of closure-libary don't break anything.

Comment by David Nolen [ 16/Jul/13 6:21 AM ]

Stuart, mind cutting new releases of the closure library so that people can test?





[CLJS-268] warn on calling type constructor with incorrect number of arguments Created: 23/May/12  Updated: 27/Jul/13  Resolved: 24/May/12

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

Attachments: Text File 0001-CLJS-268-warn-on-calling-type-constructor-with-wrong.patch     Text File 0002-fixed-type-constructor-argument-count-warnings.patch    

 Comments   
Comment by Brian Taylor [ 24/May/12 6:36 PM ]

0001

Added warning when type-constructor is invoked with the wrong number of warnings.

0002

The change in 0001 caused existing code to generate the newly created warning. This second patch addresses those new warnings.

Comment by David Nolen [ 24/May/12 7:00 PM ]

Man I love warnings Thank you!

Comment by David Nolen [ 24/May/12 7:02 PM ]

fixed, http://github.com/clojure/clojurescript/commit/fb240abd9a2bf99761d067709be772a8bc4dc0a9





[CLJS-269] (rest ()) returns nil Created: 23/May/12  Updated: 27/Jul/13  Resolved: 24/May/12

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

Attachments: Text File 0001-CLJS-269-rest-returns-nil.patch    

 Comments   
Comment by Brian Taylor [ 24/May/12 5:25 PM ]

(rest ()) now returns ().

Test (assert (= () (rest ()))) failed before change and passes now.

Comment by David Nolen [ 24/May/12 7:11 PM ]

Fixed, http://github.com/clojure/clojurescript/commit/0a26ec00a14104593a3731365dd83e6c9af75aa9





[CLJS-263] investigate special case for not in emit :invoke, could eliminate most uses of coercive-not=, coercive-not Created: 23/May/12  Updated: 27/Jul/13  Resolved: 24/May/12

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

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


 Description   

The use of coercive-not=, and coercive-not is getting a bit ugly. We could avoid this by checking for not invokes. If the argument is a bool-expr we can emit "!" directly on the argument. This would make core.cljs considerably more idiomatic.

Need to check that this doesn't affect perf.



 Comments   
Comment by David Nolen [ 24/May/12 8:31 PM ]

fixed, http://github.com/clojure/clojurescript/commit/af5dc7eff95c1e3af269a3fb999d8c4a74f8f147





[CLJS-265] Implement IChunk, ChunkedCons, ArrrayChunk, IChunkedSeq, ChunkBuffer Created: 23/May/12  Updated: 27/Jul/13  Resolved: 24/May/12

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

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


 Comments   
Comment by David Nolen [ 24/May/12 7:12 PM ]

work in progress here, http://github.com/clojure/clojurescript/compare/master...chunks

Comment by David Nolen [ 24/May/12 7:38 PM ]

fixed, http://github.com/clojure/clojurescript/commit/b4459bd8fd122602156aad44ded2e60f113b3853





[CLJS-278] ClojureScript macro eval bug since 0.0-1211? Created: 28/May/12  Updated: 27/Jul/13  Resolved: 31/May/12

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

Type: Defect Priority: Major
Reporter: Roman Scherer Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-CLJS-278-bind-ns-to-a-real-namespace-not-symbol-duri.patch    

 Description   

As discussed on the Mailing List:

--------------------------------------------------------------

Hello ClojureScripters,

I'm trying to update a port of hiccup [1] to the latest
ClojureScript version. During HTML compilation I call at some
point eval (in a Clojure macro) on a datastructure and get a
java.lang.ClassCastException. This used to work in ClojureScript
versions before 0.0-1211.

I traced it down to the following example. This works in
ClojureScript 0.0-1011:

; Define a Clojure macro.
(defmacro eval-test [arg]
(eval arg))

; Use the Clojure macro from ClojureScript.
(eval-test "1")
;=> "1"
(eval-test 1)
;=> 1
(eval-test "div")
;=> "div"
(eval-test :div)
;=> :div
(eval-test [])
;=> []
(eval-test {})
;=> {}
(eval-test #{})
;=> #{}

In ClojureScript 0.0-1211 it works on strings, numbers and
symbols, but fails on vectors, maps and sets. I get the follwoing
results:

(eval-test "1")
;=> "1"
(eval-test 1)
;=> 1
(eval-test "div")
;=> "div"
(eval-test :div)
;=> :div
(eval-test [])

java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to clojure.lang.Namespace, compiling:(NO_SOURCE_PATH:1)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6462)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.eval(Compiler.java:6508)
at clojure.lang.Compiler.eval(Compiler.java:6477)
at clojure.core$eval.invoke(core.clj:2797)
at hiccup.core$eval_test.invoke(core.clj:20)
at clojure.lang.AFn.applyToHelper(AFn.java:167)
at clojure.lang.AFn.applyTo(AFn.java:151)
at clojure.core$apply.invoke(core.clj:605)
at cljs.compiler$macroexpand_1.invoke(compiler.clj:1351)
at cljs.compiler$analyze_seq.invoke(compiler.clj:1368)
at cljs.compiler$analyze.invoke(compiler.clj:1425)
at cljs.compiler$analyze.invoke(compiler.clj:1418)
at cljs.repl$evaluate_form.invoke(repl.clj:64)
at cljs.repl$eval_and_print.invoke(repl.clj:124)
at cljs.repl$repl.doInvoke(repl.clj:173)
at clojure.lang.RestFn.invoke(RestFn.java:410)
at cljsbuild.repl.listen$run_repl_listen.invoke(listen.clj:10)
at cljsbuild.repl.listen$run_repl_launch.invoke(listen.clj:31)
at user$eval2490.invoke(NO_SOURCE_FILE:1)
at clojure.lang.Compiler.eval(Compiler.java:6511)
at clojure.lang.Compiler.eval(Compiler.java:6500)
at clojure.lang.Compiler.eval(Compiler.java:6501)
at clojure.lang.Compiler.eval(Compiler.java:6477)
at clojure.core$eval.invoke(core.clj:2797)
at clojure.main$eval_opt.invoke(main.clj:297)
at clojure.main$initialize.invoke(main.clj:316)
at clojure.main$null_opt.invoke(main.clj:349)
at clojure.main$main.doInvoke(main.clj:427)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:419)
at clojure.lang.AFn.applyToHelper(AFn.java:163)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.main.main(main.java:37)
Caused by: java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to clojure.lang.Namespace
at clojure.lang.Compiler.currentNS(Compiler.java:6864)
at clojure.lang.Compiler.lookupVar(Compiler.java:6826)
at clojure.lang.Compiler.lookupVar(Compiler.java:6847)
at clojure.lang.Compiler.isInline(Compiler.java:6323)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6448)
... 33 more
java.lang.ClassCastException: clojure.lang.Symbol cannot be cast to clojure.lang.Namespace, compiling:(NO_SOURCE_PATH:1)

Does anyone have an idea what has changed between those versions?
Could this be a bug?

Thanks for your help, Roman.



 Comments   
Comment by David Nolen [ 30/May/12 8:09 AM ]

Patch welcome. I suspect this may be due to us binding cljs-ns to ns in compiler.clj line 1450. This was done to give file & line numbers for macro errors.

Comment by Brian Taylor [ 30/May/12 3:52 PM ]

macroexpand-1 is binding ns to a symbol but the Clojure compiler assumes ns will be a namespace. We find or create an appropriately named CLJ namespace for the parallel CLJS namespace being compiled.

Comment by Brian Taylor [ 30/May/12 4:15 PM ]

This may also address CLJS-152 (though I suspect we'll need a test case or feedback from the ticket creator to be sure.)

Comment by David Nolen [ 31/May/12 8:18 AM ]

fixed, 6eada144088a373fe5c2b1eed65d6d3a8d75cb37

Comment by Roman Scherer [ 31/May/12 10:14 AM ]

I can confirm that this patch solved my problem. Thanks for fixing this so fast ...





[CLJS-267] warn on undeclared protocols Created: 23/May/12  Updated: 27/Jul/13  Resolved: 25/May/12

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

Attachments: Text File 0001-CLJS-267-warn-on-undeclared-protocols.patch     Text File 0002-fixing-un-resolved-protocol-warnings.patch    

 Description   

While working in the chunks branch I could have saved a lot of time if I had a warning that I had written ICount instead of ICounted.



 Comments   
Comment by Brian Taylor [ 24/May/12 8:40 PM ]

Added a warning to extend-type when a referenced protocol's symbol does not exist (or is not actually a protocol.)

The second patch corrects the new warnings in pre-existing code that the first patch revealed.

Comment by Brian Taylor [ 24/May/12 8:54 PM ]

I ran the benchmark and found another new warning that I had missed.

Comment by Brian Taylor [ 24/May/12 9:06 PM ]

If accepted, these changes resolve CLJS-236 as well.

Comment by David Nolen [ 25/May/12 7:09 AM ]

fixed, http://github.com/clojure/clojurescript/commit/56da2c3ca3bde1e15faf6ff372da151cae9343db





[CLJS-236] extend-protocol should throw error for undefined arguments Created: 03/May/12  Updated: 27/Jul/13  Resolved: 25/May/12

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

Type: Defect Priority: Major
Reporter: Robert Nikander Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

This should throw an error:

(extend-protocol undefined js/Text (foo [x] x))

It currently does not, which means if you forget a require or mis-type a name, you get no error until later when you protocol is not there as expected.

(extend-protocol Missspellled js/Text (foo [x] x))



 Comments   
Comment by Brian Taylor [ 24/May/12 9:05 PM ]

This issue should be resolved once CLJS-267 is resolved as they both come down to the same additional checks in extend-type.

Comment by David Nolen [ 25/May/12 7:10 AM ]

fixed, http://github.com/clojure/clojurescript/commit/56da2c3ca3bde1e15faf6ff372da151cae9343db





[CLJS-271] cljs.compiler/resolve-var doesn't look in :use'd namespaces Created: 24/May/12  Updated: 27/Jul/13  Resolved: 25/May/12

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

Type: Defect Priority: Major
Reporter: Brian Taylor Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-resolve-var-learned-about-use-d-namespaces.patch    
Patch: Code

 Description   

This is the cause of issue CLJS-216.



 Comments   
Comment by David Nolen [ 25/May/12 7:14 AM ]

fixed, http://github.com/clojure/clojurescript/commit/468cf4e1f4bb708b8c7ee114af25c7d66dd41d33





[CLJS-216] Can't (:use) protocol from another namespace Created: 29/Apr/12  Updated: 27/Jul/13  Resolved: 25/May/12

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

Type: Defect Priority: Major
Reporter: Stuart Campbell Assignee: Unassigned
Resolution: Completed Votes: 1
Labels: None


 Description   

The ClojureScript compiler doesn't correctly resolve the namespace of implemented protocol methods when the protocol is referenced via `(:use)`.

E.g.

(ns foo)

(defprotocol SomeProtocol
  (some-function [this]))
(ns bar
  (:use [foo :only (SomeProtocol)]))

(defrecord SomeRecord
  SomeProtocol
  (some-function [_] :quux))

The protocol function is compiled as though SomeProtocol was defined in the "bar" namespace, e.g.:

bar.SomeType.prototype.bar$SomeProtocol$ = true;
bar.SomeType.prototype.bar$SomeProtocol$some_function = function(this$) {
  var this__14211 = this;
  return"\ufdd0'quux"
};

This example works as expected in Clojure.



 Comments   
Comment by Brian Taylor [ 24/May/12 10:03 PM ]

If accepted, the patch associated with CLJS-271 resolves this issue.

Comment by David Nolen [ 25/May/12 7:14 AM ]

fixed, http://github.com/clojure/clojurescript/commit/468cf4e1f4bb708b8c7ee114af25c7d66dd41d33





[CLJS-394] PersistentTreeSet lookup bug Created: 15/Oct/12  Updated: 27/Jul/13  Resolved: 15/Oct/12

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

Type: Defect Priority: Major
Reporter: Erik Ouchterlony Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug, patch

Attachments: File bugfix-PersistentTreeSet-lookup.diff    
Patch: Code and Test

 Description   

The lookup function in PersistentTreeSet behaves differently in clojurescript than in clojure when a custom comparison function is used. If two elements are evaluated as equal, one of then is in the set and we do a lookup on the other, clojure returns the element in the set, whereas clojurescript returns the lookup element.

(let [compare-quot-2 #(compare (quot %1 2) (quot %2 2))
s (sorted-set-by compare-quot-2 1)]
(get s 0))

Should return: 1
Returns: 0



 Comments   
Comment by David Nolen [ 15/Oct/12 10:02 PM ]

fixed, http://github.com/clojure/clojurescript/commit/409fcc9a824668207953b2bc47d40aaab85191d3





[CLJS-389] Compiler emits throw string Created: 07/Oct/12  Updated: 27/Jul/13  Resolved: 15/Oct/12

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


 Description   

http://github.com/clojure/clojurescript/blob/master/src/clj/cljs/compiler.clj#L468



 Comments   
Comment by David Nolen [ 15/Oct/12 9:59 PM ]

fixed http://github.com/clojure/clojurescript/commit/ddcb192be4c34a548cf669625fd6d1a5bf81aa9f





[CLJS-388] expose :output-wrapper compile option Created: 07/Oct/12  Updated: 27/Jul/13  Resolved: 15/Oct/12

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

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 2
Labels: None


 Comments   
Comment by Daniel Pittman [ 07/Oct/12 7:15 PM ]

I went looking for exactly this feature two days ago, as part of investigating ClojureScript as part of the "component model" for our single page application. It uses the "Asynchronous Module Definition" pattern to isolate code, as defined here: https://github.com/amdjs/amdjs-api/wiki/AMD

While it probably isn't the only headache, being able to easily produce an appropriate function definition around the ClojureScript code would make it much easier to get started here.

Comment by David Nolen [ 15/Oct/12 10:26 PM ]

fixed, http://github.com/clojure/clojurescript/commit/e83cf518ef4d3d6aa9a1cca18dc889efb0eae57f





[CLJS-275] self calls do not optimize Created: 25/May/12  Updated: 27/Jul/13  Resolved: 28/May/12

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

Attachments: Text File 0001-CLJS-275-optimize-self-calls.patch    

 Description   

.call is emitted for self calls. This should be addressed before tackling CLJS-273



 Comments   
Comment by Brian Taylor [ 27/May/12 8:39 PM ]

Added a second analysis pass over the method bodies for named fn's that includes the fn-var flag and the arity info. Self calls get optimized in this pass.

Comment by David Nolen [ 28/May/12 12:27 PM ]

fixed, http://github.com/clojure/clojurescript/commit/d07f2e1e777591338e6f2a3d1fb9a73e1e81edfd





[CLJS-444] def issues in REPL Created: 18/Dec/12  Updated: 27/Jul/13  Resolved: 18/Dec/12

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


 Description   

(def x) now fails in the REPL, this is very likely a result of CLJS-397 and CLJS-403



 Comments   
Comment by David Nolen [ 18/Dec/12 1:06 PM ]

This may be related to dead code elimination optimizations introduced in CLJS-397

Comment by David Nolen [ 18/Dec/12 2:49 PM ]

http://github.com/clojure/clojurescript/commit/ab868f2121b64e31c7206e3d17f209f63e8e6a51

Issue was not related to other mentioned tickets. No code was emitted if init not provided was the issue.





[CLJS-244] optimize list fn Created: 08/May/12  Updated: 27/Jul/13  Resolved: 28/May/12

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

Attachments: Text File 0001-CLJS-244-optimize-list-fn.patch    

 Comments   
Comment by Brian Taylor [ 27/May/12 10:39 PM ]

Before:

[], (list), 1000000 runs, 1247 msecs
[], (list 1 2 3), 1000000 runs, 4984 msecs

After:

[], (list), 1000000 runs, 19 msecs
[], (list 1 2 3), 1000000 runs, 797 msecs

After (with CLJS-275 fix):

[], (list), 1000000 runs, 18 msecs
[], (list 1 2 3), 1000000 runs, 645 msecs

Comment by David Nolen [ 28/May/12 1:06 PM ]

fixed, http://github.com/clojure/clojurescript/commit/b46995281acacd6eecd9c232ab2318ad34d1ac9b





[CLJS-274] type-hint the return value of seq, rest, next Created: 25/May/12  Updated: 27/Jul/13  Resolved: 28/May/12

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

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


 Description   

If we tag the return value of seq then we can avoid a lot of truth tests. It's simply too common in Clojure code to use if, when etc after a call to seq.



 Comments   
Comment by David Nolen [ 28/May/12 3:40 PM ]

fixed, http://github.com/clojure/clojurescript/commit/af3ec4b3acbd020979f70ed473014c0bcdd8cd99





[CLJS-30] Remove use of js* from demo app code Created: 22/Jul/11  Updated: 27/Jul/13  Resolved: 22/Jul/11

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

Type: Enhancement Priority: Major
Reporter: Alan Dipert Assignee: Alan Dipert
Resolution: Completed Votes: 0
Labels: None


 Description   

Twitterbuzz uses js* in several places to access objects in the browser, like Math and Regexp. js* shouldn't be used like this. Use goog.global.Math form instead.

goog.global works because gclosure compiler is loaded with dom/browser externs, and knows about these objects. They just need to be referred to the right way.



 Comments   
Comment by Alan Dipert [ 22/Jul/11 4:26 PM ]

goog.global.Math and goog.global.RegExp are provided by gclosure's default externs. They can be accessed with goog.global.x, where x is a global object in an extern'd environment.

RegExp, for reasons unknown, cannot be reliably accessed this way from cljs source. As a result, re-pattern in core is implemented on top of js*. For the possibly wrong but working solution, see https://github.com/clojure/clojurescript/blob/329fb01483452288c158195c94c95f94d9bd5cfd/src/cljs/cljs/core.cljs#L2375





[CLJS-39] doseq bindings not properly scoped Created: 28/Jul/11  Updated: 27/Jul/13  Resolved: 23/Sep/11

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

Type: Defect Priority: Major
Reporter: Remco van 't Veer Assignee: David Nolen
Resolution: Completed Votes: 1
Labels: None
Environment:

Ubuntu, Sun JDK 1.6, master at ba94ed7


Attachments: Text File cljs-39.patch    

 Description   

Example:

(def q (atom []))
(doseq [v [1 2 3]] (swap! q conj (fn [] v)))
(map #(%) @q))

Clojurescript: (3 3 3)
Clojure: (1 2 3)

Probably related to CLJS-22.



 Comments   
Comment by Rich Hickey [ 28/Jul/11 8:03 AM ]

Please recheck this now that CLJS-22 is fixed.

Comment by Remco van 't Veer [ 29/Jul/11 4:59 AM ]

Problem still exists:

$ git pull
Already up-to-date.
$ git log -1
commit 5b32f81c3ffc1fabb3cbd4376690118ffa9a8d75
Author: fogus <mefogus@gmail.com>
Date: Thu Jul 28 16:21:00 2011 -0400

Fixed FF's error related to #40. More testing needed.
$ ./script/repljs
#'user/jse
"Type: " :cljs/quit " to quit"
ClojureScript:cljs.user> (let [q (atom [])] (doseq [v [1 2 3]] (swap! q conj (fn [] v))) (map #(%) @q))
(3 3 3)

Comment by Remco van 't Veer [ 29/Jul/11 5:45 AM ]

Also offered as pull request on github: https://github.com/clojure/clojurescript/pull/7

Comment by John Li [ 14/Sep/11 12:57 AM ]

I was pretty confused when I ran into this.

Unfortunately I can't get the patch won't apply, even when I update to the revision you mention (ba94ed7). I'm rusty with git, so maybe I'm just doing something wrong. However, when I manually made the changes, my problem went away.

Comment by David Nolen [ 22/Sep/11 8:09 AM ]

I think the patch needs further work. doseq maps to loop/recur which is an efficient looping construct. By just wrapping the body of the loop in a function to preserve bindings is inefficient for many use cases. Better would be to analyze the body of loop to see if the bindings are involved in closures and only then wrap the body of the loop in a function.

Comment by David Nolen [ 22/Sep/11 8:49 AM ]

Another interesting approach would be to wrap the fns in a closure at their creation site. Probably much simpler to implement as well.

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

Fixed, https://github.com/clojure/clojurescript/commit/17df9703f8933fa2f0037a2d8ad5185f620414a1

The issue was not loop/recur which communicates loop bindings to fns. The issue was that doseq wasn't keeping those bindings inside the loop binding list.





[CLJS-45] Browser-connected REPL Created: 29/Jul/11  Updated: 27/Jul/13  Resolved: 09/Sep/11

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

Type: Enhancement Priority: Major
Reporter: Brenton Ashworth Assignee: Brenton Ashworth
Resolution: Completed Votes: 0
Labels: None


 Description   

Create a REPL that uses the browser as the JavaScript runtime instead of Rhino.

  • send compiled JavaScript strings to the browser for evaluation
  • side effects happen in the browser, return values are sent back to the REPL
  • abstract over communication leveraging goog library
  • stub code
  • launch browser


 Comments   
Comment by Brenton Ashworth [ 09/Sep/11 4:38 PM ]

REPL code has been removed from the compiler. There is now a protocol for evaluation and implementations exist for Rhino and the browser.





[CLJS-57] namespace function in core.cljs returns :else instead of nil for a symbol without namespace Created: 10/Aug/11  Updated: 27/Jul/13  Resolved: 16/Sep/11

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

Type: Defect Priority: Major
Reporter: Arthur Edelstein Assignee: Brenton Ashworth
Resolution: Com