<< Back to previous view

[CLJS-1436] self-host: Doesn't load dep ns when loading own cache Created: 29/Aug/15  Updated: 03/Sep/15  Resolved: 03/Sep/15

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

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

Attachments: Text File CLJS-1436-1.patch     Text File CLJS-1436-2.patch    
Patch: Code

 Description   

Background: Both *load-fn* and *eval-fn* support the concept of passing JavaScript and analysis cache info. Such data passed to *eval-fn* should be able to be stored and subsequently passed to *load-fn* upon subsequent runs in order to effect analysis/compilation caching.

If one namespace depends on another then transitive loading occurs if no caching is involved. But if cached information it returned to *load-fn* when the top-level namespace is loaded, then transitive loading does not occur.

My speculation is that this is the case because, while the analysis cache is incorporated here

https://github.com/clojure/clojurescript/blob/r1.7.122/src/main/cljs/cljs/js.cljs#L206-L208

nothing further is done to load dependent namespaces as is done when ClojureScript source is passed in the callback.

Here is a concrete example. Let foo.core depend on bar.core:

(ns foo.core
  (:require bar.core))

(prn bar.core/x)
(ns bar.core)

(def x 2)

If you require foo.core (via an ns form passed to eval-str), then *load-fn* is called with

{:name foo.core, :macros nil, :path "foo/core"}

and it is called back upon with the loaded ClojureScript source:

{:lang :clj, :source "(ns foo.core\n  (:require bar.core))\n\n(prn bar.core/x)\n"}

and the embedded :require then causes *load-fn* to be invoked for bar.core:

{:name bar.core, :macros nil, :path "bar/core"}

with its source being passed to the callback:

{:lang :clj, :source "(ns bar.core)\n\n(def x 2)\n"}

Then the evaluation phase begins with two evaluations (done properly in reverse dependency order):

{:lang :clj, :name bar.core, :path "bar/core", :source "goog.provide(\"bar.core\");\nbar.core.x = 2;\n", :cache {:use-macros nil, :excludes #{}, :name bar.core, :imports nil, :requires nil, :uses nil, :defs {x {:name bar.core/x, :file nil, :line 3, :column 1, :end-line 3, :end-column 7, :meta {:file bar.core, :line 3, :column 6, :end-line 3, :end-column 7}}}, :require-macros nil, :doc nil}}

and

{:lang :clj, :name foo.core, :path "foo/core", :source "goog.provide(\"foo.core\");\ncljs.core.prn.call(null,bar.core.x);\n", :cache {:name foo.core, :doc nil, :excludes #{}, :use-macros nil, :require-macros nil, :uses nil, :requires {bar.core bar.core}, :imports nil}}

which causes 2 to be printed.

Then if you start fresh, but go through the same sequence, consuming cached information, you start off the same with *load-fn* being called the same way:

{:name foo.core, :macros nil, :path "foo/core"}

and with the callback now being passed cached information back in return:

{:lang :js, :source "goog.provide(\"foo.core\");\ncljs.core.prn.call(null,bar.core.x);\n", :cache {:name foo.core, :doc nil, :excludes #{}, :use-macros nil, :require-macros nil, :uses nil, :requires {bar.core bar.core}, :imports nil}}

This JavaScript is evaluated by cljs.js here

https://github.com/clojure/clojurescript/blob/r1.7.122/src/main/cljs/cljs/js.cljs#L205

and this causes this to be printed

Can't find variable: bar

Perhaps this isn't a defect if instead it is expected that clients of cljs.js handle the loading of dependent namespaces when caching is involved.



 Comments   
Comment by David Nolen [ 30/Aug/15 10:34 AM ]

A patch for this is welcome. Analysis caches for a ns include all the information needed to load lib and macro dependencies.

Comment by Mike Fikes [ 02/Sep/15 3:55 PM ]

This appears to be a fairly straightforward patch, but attached it with a -1 revision indicator in case it ultimately needs a few rounds of review. (IMHO, there is definitely no urgency to review this, as it is a self-host ticket.)

Comment by David Nolen [ 02/Sep/15 4:51 PM ]

Lets break out helper functions for this one please. Thanks!

Comment by Mike Fikes [ 02/Sep/15 9:11 PM ]

Broke out with a few explicitly named helper functions. Let me know if I took it too far. Also, feel free to simply modify this to suit.

Comment by David Nolen [ 03/Sep/15 6:36 AM ]

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





[CLJS-1435] self-host: lexical scope is broken Created: 29/Aug/15  Updated: 29/Aug/15  Resolved: 29/Aug/15

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

Type: Defect Priority: Major
Reporter: Chris Truter Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bootstrap

Attachments: Text File 1435.patch    
Patch: Code and Test

 Description   

This has the cause as http://dev.clojure.org/jira/browse/CLJS-1400, but demonstrates a more provocative compilation error.

Sample code using cljs.js to demonstrate the failure:

(cljs/eval
  (cljs/empty-state)
  '(let [x 1]
     (let [x (inc x)]
       (prn x))
     (prn x))
  {:eval (juxt (comp prn :source) cljs/js-eval)}
  (fn [& _]))

Which displays both the code (line breaks unescaped here for convenience) and resulting error:

"var x_22 = 1;
 var x_23__$1 = (x_23 + 1);
 cljs.core.prn.call(null,x_23__$1);
 cljs.core.prn.call(null,x_22);"
VM1654:2 Uncaught ReferenceError: x_23 is not defined

This issue is more noticeable than in the case encountered via "doseq", as the naming error occurs in a read position rather than write, so we get an error instead of unexpected behaviour.

The patch attached fixies this and 1400



 Comments   
Comment by Chris Truter [ 29/Aug/15 10:32 AM ]

Attached patch with a (hopefully) faster alternate

Comment by David Nolen [ 29/Aug/15 11:00 AM ]

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





[CLJS-1433] self-host: cljs.js/*eval-fn* passed nil :cache Created: 24/Aug/15  Updated: 26/Aug/15  Resolved: 26/Aug/15

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

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

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

 Description   

If you load some ClojureScript source that implements a namespace, the cljs.js/*eval-fn* will always be passed a :cache value of nil



 Comments   
Comment by Mike Fikes [ 24/Aug/15 12:24 PM ]

Simple defect—simply need to deref the atom.

Comment by David Nolen [ 26/Aug/15 10:28 PM ]

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





[CLJS-1430] self-host: .toString is emitted as .toString$ (munged) Created: 18/Aug/15  Updated: 27/Aug/15  Resolved: 27/Aug/15

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

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

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

 Description   

If you evaluate a form like (.toString "a") in bootstrapped mode, the emitted JavaScript will end up with a dollar-sign: "a".toString$().

This can be reproduced via a compile-str unit test involving the form.



 Comments   
Comment by Mike Fikes [ 18/Aug/15 11:29 PM ]

This is because, even though the compiler indicates that there are no reserved words (the empty set for second argument here):

https://github.com/clojure/clojurescript/blob/v1.7/src/main/clojure/cljs/compiler.cljc#L1006

cljs.core/munge is called here

https://github.com/clojure/clojurescript/blob/v1.7/src/main/clojure/cljs/compiler.cljc#L108

to imitate Clojure's munge. But cljs.core/munge introduces the dollar-sign for reserved JavaScript keywords:

https://github.com/clojure/clojurescript/blob/v1.7/src/main/cljs/cljs/core.cljs#L9898

The direct ClojureScript imitation of Clojure's munge is munge-str here

https://github.com/clojure/clojurescript/blob/v1.7/src/main/cljs/cljs/core.cljs#L9882

Calling that (private) method instead fixes the problem.

Comment by Mike Fikes [ 18/Aug/15 11:37 PM ]

The attached file fixes the issue.

On problem with it, though it it has the compiler calling a private function in cljs.core namespace.

Comment by Mike Fikes [ 18/Aug/15 11:44 PM ]

Attaching a 2nd patch which properly updates the latch count in the unit test.

Comment by David Nolen [ 26/Aug/15 10:37 PM ]

This ticket does not explain why toString would get munged - it's not on the reserved list.

Comment by Mike Fikes [ 26/Aug/15 11:04 PM ]

You are right, David. The root cause actually has to do with (js-reserved? "toString") returning true when it should not do so. I suspect this has to do with the use of gobject/containsKey giving a false positive for things in the Object prototype, viz:

cljs.user=> (require '[goog.object :as gobject])
nil
cljs.user=> (gobject/containsKey #js {} "toString")
true

So, I retract my patch which completely glosses over the aspect that js-reserved? is probably the culprit.

Comment by Mike Fikes [ 26/Aug/15 11:53 PM ]

David, based on your feedback, attached a CLJS-1430-3.patch which might be closer to a correct approach in that it fundamentally revises js-reserved? to not return true for things like "toString".

My JavaScript is not strong enough for a feel as to whether the actual implementation in the patch is up to muster, nor whether munging is in the critical path for perf.

Comment by David Nolen [ 27/Aug/15 6:27 AM ]

Ah ok, revise the patch to remove the two tests, instead just use (.hasOwnProperty js-reserved foo)

Comment by Mike Fikes [ 27/Aug/15 7:56 AM ]

CLJS-1430-4.patch updated to use .hasOwnProperty, and ran all tests except Nashorn. Also ran self-host tests.

Comment by David Nolen [ 27/Aug/15 8:23 AM ]

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





[CLJS-1429] self-host: Load dependent namespaces when client calls back with :cache Created: 17/Aug/15  Updated: 17/Aug/15  Resolved: 17/Aug/15

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

Type: Enhancement Priority: Minor
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Not Reproducible Votes: 0
Labels: bootstrap


 Description   

If cljs.js/*load-fn*'s callback is called with :cache, load dependent namespaces. Otherwise, the cached JavaScript will be loaded but not its dependencies.



 Comments   
Comment by Mike Fikes [ 17/Aug/15 9:45 AM ]

FWIW, I've worked around this downstream by making use of Google Closure's dependency management to actually do the load along with dependent namespaces, combined with simply returning an empty string for the source: https://github.com/mfikes/planck/blob/5dcc56c28732e79436fd9cc37dfd6cd42e0d076c/planck-cljs/src/planck/repl.cljs#L314

Comment by Mike Fikes [ 17/Aug/15 9:55 AM ]

I apologize for the ticket noise. This issue is invalid; it actually works.





[CLJS-1425] self-host: cljs.js/eval cb argument inconsistent with docstring Created: 14/Aug/15  Updated: 14/Aug/15

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

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


 Description   

The docstring for cljs.js/eval indicates a map (containing either an :error or :value key).

This is the case for :error: Here is an example:

https://github.com/clojure/clojurescript/blob/r1.7.48/src/main/cljs/cljs/js.cljs#L489

But for :value the value is returned without being wrapped in a map; instead the result of applying *eval-fn* is directly returned (and *eval-fn* is supposed to return the value). Here is an example:

https://github.com/clojure/clojurescript/blob/r1.7.48/src/main/cljs/cljs/js.cljs#L499






[CLJS-1423] self-host: Requiring analyzer/compiler breaks unchecked Boolean Created: 14/Aug/15  Updated: 14/Aug/15

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

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

Quick Start



 Description   

Grab the Quick Start cljs.jar, and make a src/foo/core.cljs file with

(ns foo.core)

(if 0 
  (prn 1) 
  (prn 2))

Build it using java -cp cljs.jar:src clojure.main build.clj where build.clj contains:

(require 'cljs.build.api)

(cljs.build.api/build "src" 
  {})

Inspect out/foo/core.js:

// Compiled by ClojureScript 1.7.48 {}
goog.provide('foo.core');
goog.require('cljs.core');
if(cljs.core.truth_((0))){
cljs.core.prn.call(null,(1));
} else {
cljs.core.prn.call(null,(2));
}

//# sourceMappingURL=core.js.map

Now revise src/foo/core.cljs to require the analyzer namespace:

(ns foo.core
  (:require cljs.analyzer))

(if 0 
  (prn 1) 
  (prn 2))

Build again and inspect out/foo/core.js:

// Compiled by ClojureScript 1.7.48 {}
goog.provide('foo.core');
goog.require('cljs.core');
goog.require('cljs.analyzer');
if((0)){
cljs.core.prn.call(null,(1));
} else {
cljs.core.prn.call(null,(2));
}

//# sourceMappingURL=core.js.map

Note the lack of cljs.core.truth_



 Comments   
Comment by Mike Fikes [ 14/Aug/15 3:41 PM ]

Speculation: The intent of this line

https://github.com/clojure/clojurescript/blob/r1.7.48/src/main/clojure/cljs/analyzer.cljc#L1565

is to provide *unchecked-if* capability in bootstrapped environments. But, perhaps it additionally acts as a meta-circular gateway allowing cljs.analyzer/*unchecked-if* to be set in new scenarios while compiling ClojureScript using the JVM-based compiler. (That line was not there previously.)

Fact: If you remove this line, it works. Additionally, if you revise it to set a literal false, things work. Neither are satisfying as they would defeat the original intent of that bit of code.

I have a much more complicated downstream usage of bootstrap that exhibits similar behavior with respect to the minimal repro above (https://github.com/mfikes/planck/issues/84).





[CLJS-1421] Enable Asynchronous cljs.js/*eval-fn* Created: 14/Aug/15  Updated: 16/Aug/15

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

Type: Enhancement Priority: Minor
Reporter: Matthew Molloy Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: asynchronous, bootstrap


 Description   

In bootstrapped ClojureScript cljs.js/eval-fn receives javascript source and evaluates it, returning a result. In some contexts it is necessary to evaluate the js asynchronously, can we add this functionality?



 Comments   
Comment by David Nolen [ 14/Aug/15 7:49 PM ]

This ticket needs more rationale. Can you elaborate on the usecase?

Comment by Matthew Molloy [ 14/Aug/15 10:08 PM ]

My usecase is an asynchronous eval function

(fn *eval-fn*
  [{:keys [source]}]
  (js/chrome.devtools.inspectedWindow.eval source
    (fn [result err]
      (if result
        (callback result)
        (callback err))))

There must be other people who have situations like this.

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

Interesting. I don't think this is a common use case, most JS engines provide synchronous eval. Not interested in any breaking changes but would be happy to take a patch that gives you the behavior you want via an option flag, :async-eval.





[CLJS-1418] self-host: defprotocol regressed with arity error Created: 10/Aug/15  Updated: 10/Aug/15  Resolved: 10/Aug/15

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

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

Attachments: Text File 0001-Exhibit-defprotocol-failure.patch     Text File CLJS-1481.patch    

 Description   

There is a regression in the ability to evaluate (defprotocol Foo) in master.

The attached patch exhibits the problem with a unit test that triggers the issue, causing the following to be emitted:

FAIL in (test-eval-str) (at /Users/mfikes/Projects/clojurescript/builds/out-self/core-self-test.js:10969:98)
expected: (nil? error)
  actual: (not (nil? #error {:message "Could not eval ", :data {:tag :cljs/analysis-error}, :cause #error {:message "Invalid arity: 4 at line 1 ", :data {:file nil, :line 1, :column 1, :tag :cljs/analysis-error}, :cause #object[Error Error: Invalid arity: 4]}}))


 Comments   
Comment by Mike Fikes [ 10/Aug/15 4:00 PM ]

Regression occurred with this commit: https://github.com/clojure/clojurescript/commit/d435b4395c719644a4a16f0277ae912f61db42a6

Comment by David Nolen [ 10/Aug/15 7:28 PM ]

fixed https://github.com/clojure/clojurescript/commit/04d0b92da513c8e7129e06bc34b19b1801207c32





[CLJS-1406] macroexpand munging goog.string.StringBuffer Created: 09/Aug/15  Updated: 14/Aug/15

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

Type: Defect Priority: Minor
Reporter: Matthew Molloy Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bootstrap
Environment:

Bootstrapped Planck REPL


Attachments: Text File cljs_1406.patch     Text File cljs_1406_test.patch    

 Description   

(macroexpand '(with-out-str)) on bootstrapped ClojureScript gives (let* [sb__13582__auto__ (string.StringBuffer.)]...
on JVM compiled ClojureScript it is (let* [sb__1155__auto__ (goog.string.StringBuffer.)]...

goog.string.StringBuffer has been incorrectly munged to string.StringBuffer when the cljs.js compiler is used.



 Comments   
Comment by Joel Martin [ 13/Aug/15 7:28 PM ]

I ran into this today. Here is a test case for the self host tests that reproduces the problem.

Comment by Joel Martin [ 13/Aug/15 7:50 PM ]

Fix the test. Propose a fix that just puts "js/" in front to prevent the broken name resolution. Probably not the correct solution, but it does work.

Comment by David Nolen [ 14/Aug/15 7:50 PM ]

Not going to take the current patches. The underlying resolution issue needs to be fixed.





[CLJS-1382] Macros time and case use unqualified core/str in syntax quote (breaks bootstrap) Created: 30/Jul/15  Updated: 30/Jul/15  Resolved: 30/Jul/15

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

Type: Defect Priority: Minor
Reporter: Joel Martin Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bootstrap
Environment:

cljs-bootstrap


Attachments: Text File time-case-fix.patch    
Patch: Code

 Description   

The following are broken in bootstrapped clojurescript because they call unqualified versions of core/str within syntax quote:

(time (reduce #(+ %1 %2) 0 (range 1000000)))

(case :constant false "nope")


 Comments   
Comment by David Nolen [ 30/Jul/15 11:36 AM ]

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





[CLJS-1379] self-host: Macroexpansion defeated when calling helper Created: 29/Jul/15  Updated: 11/Aug/15  Resolved: 11/Aug/15

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

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: bootstrap
Environment:

1.7.10



 Description   

If you have a namespace:

(ns foo.macros
  (:require foo.helper))

(defmacro my-inc [n]
  `(foo.helper/my-inc ~n))

That makes use of a helper namespace:

(ns foo.helper)

(defn my-inc [x]
  (inc x))

Then things will work properly for non-bootstrapped ClojureScript. Here is an example use in Ambly:

cljs.user=> (require 'foo.helper)
nil
cljs.user=> (require-macros 'foo.macros)
nil
cljs.user=> (defn f [] (foo.macros/my-inc 3))
#'cljs.user/f
cljs.user=> f
#<function cljs$user$f() {
return foo.helper.my_inc.call(null,(3));
}>
cljs.user=> (f)
4

But, the same sequence in bootstrapped ClojureScript fails:

cljs.user=> (require 'foo.helper)
nil
cljs.user=> (require-macros 'foo.macros)
nil
cljs.user=> (defn f [] (foo.macros/my-inc 3))
#'cljs.user/f
cljs.user=> f
#<function cljs$user$f() {
return foo.macros.my_inc.call(null,3);
}>
cljs.user=> (f)
Error occurred
cljs$user$f

Note that the emitted JavaScript in this second case treats the macro as a function.

Also, I've seen that if you eliminate the call to a helper, but instead, say make direct use of say, inc, then macro expansion works properly in bootstrapped ClojureScript (and for the example above you end up with JavaScript code that adds 1 and 3.)

Of course, these are with downstream REPLs. Let me know if a minimal repro without any downstream stuff is desired and I'm sure I can scratch one together involving the same calls Planck is making to cljs.js.



 Comments   
Comment by David Nolen [ 30/Jul/15 3:18 PM ]

The second case is only possible if for some reason the macros could not get loaded.

Comment by Mike Fikes [ 30/Jul/15 5:12 PM ]

As discussed in IRC, Mike to add minimal repro to this ticket.

Comment by David Nolen [ 10/Aug/15 10:09 PM ]

If we can't get a reproducer for this will close soon

Comment by Mike Fikes [ 11/Aug/15 10:30 AM ]

The root cause is that cljs.tools.reader/resolve-symbol is not bound.

Adding the binding pair r/resolve-symbol ana/resolve-symbol to cljs.js/eval-str* resolves the issue, but the correct fix may involve binding this in other entry points as well.

Still working on trying to put together a good repro. An ideal place would be self-host.test test-eval-str-with-require, but something is preventing those tests from running under Node.js (it looks like the ns form that creates foo.bar derails because the outer foo object is not created. Interestingly, if I use JavaScriptCore (via Planck, pointed at clojurescript/src/test/self as its source directory), and I also rename helper.clj -> helper.cljc, I am able to make a lot of progress (repro the issue and have augmented test cases pass, with the right changes).

So, I think the key to progress on this one is to get these tests to run under Node.js. I'll see if I can get them to work.

Comment by David Nolen [ 11/Aug/15 4:03 PM ]

possible fix on master that needs testing.

Comment by Mike Fikes [ 11/Aug/15 4:53 PM ]

Confirmed fixed using downstream Planck REPL.

As an aside, even though regular ClojureScript REPLs (like Ambly) need the additional (require 'foo.helper) prior to (require-macros 'foo.macros) in order for this code to work, Planck (and probably all bootstrapped REPLs), can simply issue (require-macros 'foo.macros) and have the code work. (In other words, bootstrapped ClojureScript appears to be capable of loading the transitive dependency for this case.)

Comment by David Nolen [ 11/Aug/15 5:20 PM ]

fixed https://github.com/clojure/clojurescript/commit/2677ff7a595e872d9393237818894d84a0214083





[CLJS-1370] cljs.js: Path for goog off Created: 27/Jul/15  Updated: 30/Jul/15  Resolved: 30/Jul/15

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

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bootstrap


 Description   

I have a namespace that indirectly uses goog.

(ns foo.bar
  (:require clojure.string))

(def a 4)

When I use cljs.js to require this source, ultimately the path "goog/string" is passed to *load-fn*. The transcript here shows the argument sequence passed to *load-fn*.

cljs.user=> (require 'foo.bar)
{:name foo.bar, :macros nil, :path "foo/bar"}
{:name clojure.string, :macros nil, :path "clojure/string"}
{:name goog.string, :macros nil, :path "goog/string"}

My *load-fn* implementation successfully loads clojure/string.cljs which contains

(:require [goog.string :as gstring])

as one of its namespace specs, which triggers the last path "goog/string".

On disk, there is actually "goog/string/string.js" that could be loaded, but before trying any hacking surrounding that, figured I'd submit a ticket regarding this case.



 Comments   
Comment by David Nolen [ 30/Jul/15 3:24 PM ]

We're not going to address this one at all. REPLs will have to provide their own Google Closure Library index to make this work.





[CLJS-1369] eval-str should support compilation output caching Created: 27/Jul/15  Updated: 27/Jul/15  Resolved: 27/Jul/15

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

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


 Description   

This is the only place for people to run side effects (like writing compilation output to disk).



 Comments   
Comment by David Nolen [ 27/Jul/15 9:12 AM ]

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





[CLJS-1366] Warnings from bootstrap use of defrecord Created: 24/Jul/15  Updated: 24/Jul/15  Resolved: 24/Jul/15

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

Type: Defect Priority: Minor
Reporter: Joel Martin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap
Environment:

cljs-bootstrap


Attachments: Text File 1366.patch    

 Description   

Currently, use of defrecord with a value field generates non-fatal warnings because core/list is not fully qualified:

cljs.user> (defprotocol IFoo (foo [this]))
nil
cljs.user> (defrecord Baz [b] IFoo (foo [this] (prn "some baz:" b)))
WARNING: No such namespace: core, could not locate core.cljs, core.cljc, or Closure namespace ""
WARNING: Use of undeclared Var core/list
cljs.user/Baz


 Comments   
Comment by David Nolen [ 24/Jul/15 7:15 PM ]

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





[CLJS-1365] cljs.js: :context :expr propagates down into ns loading Created: 23/Jul/15  Updated: 27/Jul/15  Resolved: 27/Jul/15

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

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

Master, with downstream Planck



 Description   

Planck sets :context :expr to evaluate a form in the REPL (via this feature http://dev.clojure.org/jira/browse/CLJS-1357)

If it turns out that the expression being evaluated in the REPL is actually an ns form that causes another namespace to be :require d (and loaded via *load-fn*) then only the first form after the ns form in that namespace is loaded. This doesn't occur if I omit the :context :expr opt.



 Comments   
Comment by Mike Fikes [ 23/Jul/15 8:40 PM ]

I'll work on a repro for cljs-bootstrap.

Comment by David Nolen [ 27/Jul/15 7:54 AM ]

fixed https://github.com/clojure/clojurescript/commit/478eb80c3f1bd9aa896bf925b535f9a52bf7b8d4





[CLJS-1362] cljs.js: eval-str: Some core fns not aliased Created: 23/Jul/15  Updated: 25/Jul/15  Resolved: 25/Jul/15

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

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

Master clojurescript-version "0.0-3620", downstream Planck



 Description   

If I eval-str inc I'll get back the core fn, but not so with "map" unless I fully qualify it.

So (inc 1) works but not (map inc [1 2 3]) but, (cljs.core/map inc [1 2 3]) works just fine.

Will see if I can repo with cljs-bootstrap.



 Comments   
Comment by David Nolen [ 24/Jul/15 7:07 PM ]

I see this as well thanks for the report.

Comment by David Nolen [ 25/Jul/15 1:39 PM ]

So I believe this is happening only because the analysis cache for core has not yet been loaded.

Comment by David Nolen [ 25/Jul/15 1:56 PM ]

Closing this one. This only happens when cljs.core has not been analyzed. I do not currently see an easy to solve this problem for users as it either means analyzing cljs.core before doing anything (very slow) or I/O to load a cached analysis. I think this should be just covered by good documentation when we get there.

Comment by David Nolen [ 25/Jul/15 3:26 PM ]

needs fixing

Comment by David Nolen [ 25/Jul/15 3:26 PM ]

fixed https://github.com/clojure/clojurescript/commit/72e01962bfeae9c24b37d6c27a86fd12412e7f07

Comment by Mike Fikes [ 25/Jul/15 8:51 PM ]

Confirmed fixed in master (0.0-3632) with downstream Planck.

I did time ./planck -e '(map inc [1 2 3])' with the cljs.js and previous non-cljs.js versions of Planck and it is slower than I think we expected. Here is what I get:

$ time ./planck -e '(map inc [1 2 3])'
(2 3 4)

real	0m6.883s
user	0m5.168s
sys	0m2.038s

vs.

$ time ./planck -e '(map inc [1 2 3])'
(2 3 4)

real	0m0.956s
user	0m0.964s
sys	0m0.196s

To eliminate any potential noise introduced by the subsequent commits related to source map stuff, I checked out the commit with this fix and got similar numbers:

$ time ./planck -e '(map inc [1 2 3])'
(2 3 4)

real	0m6.884s
user	0m5.135s
sys	0m2.058s

And, to see what this commit alone does to the timings I went to the commit immediately prior and got

$ time ./planck -e '(map inc [1 2 3])'
undefined is not an object (evaluating 'cljs.user.map') 
 
real	0m6.125s
user	0m4.517s
sys	0m1.855s

Summary conclusion: This commit fixes the issue by only adding about 0.75 seconds to startup!

There is obviously something else I'll want to dig into in order to isolate where the 6-second numbers are coming from relative to the 1-second numbers (perhaps it's a Planck thing; I promise to get back with that info, but wanted to at least record what I measured here.)

Comment by Mike Fikes [ 25/Jul/15 9:36 PM ]

Isolated it: With cljs.js, something related to defn is very slow the first time called. Planck has a couple of those in it during startup. If I eliminate those, then very comparable numbers result:

$ time ./planck -e '(map inc [1 2 3])'
(2 3 4)

real	0m1.220s
user	0m1.118s
sys	0m0.252s

Whatever it is with defn perf is clearly not related to this ticket. Just wanted to comment so this ticket is not "left hanging", and whatever it is with defn perf can be pursued separately.





[CLJS-1356] cljs.js/*load-fn* should take the original library name Created: 20/Jul/15  Updated: 21/Jul/15  Resolved: 21/Jul/15

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

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


 Description   

More information the better.



 Comments   
Comment by David Nolen [ 21/Jul/15 5:26 AM ]

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





[CLJS-1355] cljs.js/*eval-fn* should take cljs.js/*load-fn*'s return value, a map Created: 20/Jul/15  Updated: 21/Jul/15  Resolved: 21/Jul/15

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

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


 Description   

Rhino, Nashorn, JavaScriptCore, and Node.js all have good support for evaluating an arbitrary string as source and associating it with a file name. For this reason we should just pass the map with :source, :name, and :lang received from cljs.js/load-fn.



 Comments   
Comment by David Nolen [ 21/Jul/15 5:26 AM ]

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





[CLJS-1354] bootstrapped ClojureScript should support inline source maps Created: 20/Jul/15  Updated: 21/Jul/15  Resolved: 21/Jul/15

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

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


 Comments   
Comment by David Nolen [ 21/Jul/15 5:29 PM ]

fixed https://github.com/clojure/clojurescript/commit/6235833cb398510bd62bfc33da1345dc6316259e





[CLJS-1338] NPE in confirm-var-exists if suffix is ".." Created: 12/Jul/15  Updated: 12/Jul/15  Resolved: 12/Jul/15

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

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

Master, :clj mode



 Description   

When compiling out/cljs/core.cljc for bootstrap purposes (with ClojureScript JVM), `cljs.analyzer/confirm-var-exists` ends up being called with prefix of "cljs.core$macros" and suffix of "..". This causes suffix-str to take on the value nil which is passed to `symbol`, causing an NPE.

This regression occurred with this commit: https://github.com/clojure/clojurescript/commit/8bb3b1ddc28bb773dcd3acd74f6e35c50015246b



 Comments   
Comment by David Nolen [ 12/Jul/15 3:07 PM ]

fixed https://github.com/clojure/clojurescript/commit/8600c7cb88414ec91faf5cb22e3c4ee3be649b0d





[CLJS-1337] Move parse ns side-effects into a separate compiler pass Created: 12/Jul/15  Updated: 15/Jul/15  Resolved: 15/Jul/15

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

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap


 Description   

Originally suggested by Thomas Heller there's now an immediate need to pursue this - bootstrapping. Currently the ns side-effects assume I/O can happen synchronously. This assumption falls apart in many JS environments.



 Comments   
Comment by David Nolen [ 15/Jul/15 5:47 PM ]

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





[CLJS-1335] resolve-macro-var: information missing for macros Created: 12/Jul/15  Updated: 12/Jul/15

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

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

https://github.com/swannodette/cljs-bootstrap



 Description   

In bootstrapped ClojureScript, if you resolve-var on a function, you get lots of information, but resolve-macro-var doesn't work for macros. (The only reason I have any expectation for this to work is that it appears to do so in ClojureScript JVM).

cljs-bootstrap.core=> (with-compiler-env cenv (ana/resolve-macro-var (ana/empty-env) 'or)))
nil

But:

cljs-bootstrap.core=> (with-compiler-env cenv (ana/resolve-var (ana/empty-env) 'map)))
{:protocol-inline nil, :meta {:file "cljs/core.cljs", :end-column 10, :top-fn {:variadic true, :method-params ([f] [f coll] [f c1 c2] [f c1 c2 c3]), :arglists-meta (nil nil nil nil nil), :max-fixed-arity 4, :arglists ([f] [f coll] [f c1 c2] [f c1 c2 c3] [f c1 c2 c3 & colls])}, :column 7, :line 4128, :end-line 4128, :arglists (quote ([f] [f coll] [f c1 c2] [f c1 c2 c3] [f c1 c2 c3 & colls])), :doc "Returns a lazy sequence consisting of the result of applying f to\n  the set of first items of each coll, followed by applying f to the\n  set of second items in each coll, until any one of the colls is\n  exhausted.  Any remaining items in other colls are ignored. Function\n  f should accept number-of-colls arguments. Returns a transducer when\n  no collection is provided."}, :ns cljs.core, :name cljs.core/map, :variadic true, :file "cljs/core.cljs", :end-column 10, :top-fn {:variadic true, :method-params ([f] [f coll] [f c1 c2] [f c1 c2 c3]), :arglists-meta (nil nil nil nil nil), :max-fixed-arity 4, :arglists ([f] [f coll] [f c1 c2] [f c1 c2 c3] [f c1 c2 c3 & colls])}, :method-params ([f] [f coll] [f c1 c2] [f c1 c2 c3]), :protocol-impl nil, :arglists-meta (nil nil nil nil nil), :column 1, :line 4128, :end-line 4128, :max-fixed-arity 4, :fn-var true, :arglists ([f] [f coll] [f c1 c2] [f c1 c2 c3] [f c1 c2 c3 & colls]), :doc "Returns a lazy sequence consisting of the result of applying f to\n  the set of first items of each coll, followed by applying f to the\n  set of second items in each coll, until any one of the colls is\n  exhausted.  Any remaining items in other colls are ignored. Function\n  f should accept number-of-colls arguments. Returns a transducer when\n  no collection is provided."}

As an aside:

cljs-bootstrap.core=> (with-compiler-env cenv (ana/resolve-var (ana/empty-env) 'or)))
{:name cljs.core/or, :ns cljs.core}





[CLJS-1334] Bootstrap 2-binding for can't recur here Created: 11/Jul/15  Updated: 15/Jul/15  Resolved: 15/Jul/15

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

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

Attachments: Text File cljs-1334-for-macro-v2.patch    

 Description   

A form like {{(for [x [1] y [2]] y)}} causes a Can't recur here error diagnostic.

With https://github.com/swannodette/cljs-bootstrap

cljs-bootstrap.core=> *clojurescript-version*
"0.0-3464"
cljs-bootstrap.core=> (for [x [1] y [2]] y)
(2)
cljs-bootstrap.core=> (with-out-str
      (c/emit
        (ensure
          (ana/analyze
            (assoc (ana/empty-env) :context :expr)
             '(for [x [1] y [2]] y))))))
Error: Can't recur here
    at new cljs$core$ExceptionInfo (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/core.cljs:9688:9)
    at Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/core.cljs:9720:14)
    at Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$3 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:514:5)
    at Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$2 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:512:13)
    at /Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:1364:15
    at [object Object].cljs.core.MultiFn.cljs$core$IFn$_invoke$arity$5 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/core.cljs:9445:8)
    at Object.cljs$analyzer$analyze_seq_STAR_ [as analyze_seq_STAR_] (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:2174:6)
    at Object.cljs$analyzer$analyze_seq_STAR__wrap [as analyze_seq_STAR__wrap] (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:2179:6)
    at Function.cljs.analyzer.analyze_seq.cljs$core$IFn$_invoke$arity$4 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:2196:15)
    at Object.cljs$analyzer$analyze_form [as analyze_form] (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:2294:43)


 Comments   
Comment by Andy Sheldon [ 12/Jul/15 8:43 PM ]

The cljs-1334-for-macro.patch did not fix the issue, so I deleted it. Maybe a problem with recur-frames is more likely.

Comment by Mike Fikes [ 12/Jul/15 9:25 PM ]

I tested with Andy's cljs-1334-for-macro.patch and the issue went away.

I got a different slew of errors that perhaps warrant separate tickets:

cljs-bootstrap.core=> (with-out-str
      (c/emit
        (ensure
          (ana/analyze
            (assoc (ana/empty-env) :context :expr)
             '(for [x [1] y [2]] y))))))

repl:42
throw e__4257__auto__;
      ^
Error: Cannot read property 'cljs$core$IFn$_invoke$arity$2' of undefined
    at new cljs$core$ExceptionInfo (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/core.cljs:9688:9)
    at Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/core.cljs:9720:14)
    at Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$3 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:514:5)
    at Object.cljs$analyzer$macroexpand_1 [as macroexpand_1] (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:2355:52)
    at Function.cljs.analyzer.analyze_seq.cljs$core$IFn$_invoke$arity$4 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:2381:23)
    at Object.cljs$analyzer$analyze_form [as analyze_form] (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:2481:43)
    at Object.cljs$analyzer$analyze_STAR_ [as analyze_STAR_] (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:2504:17)
    at Function.cljs.analyzer.analyze.cljs$core$IFn$_invoke$arity$4 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:2520:11)
    at Function.cljs.analyzer.analyze.cljs$core$IFn$_invoke$arity$3 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:2515:21)
    at Function.cljs.analyzer.analyze.cljs$core$IFn$_invoke$arity$2 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.cljc:2514:16)
Comment by David Nolen [ 13/Jul/15 5:50 AM ]

The ticket and patch needs more information. Currently there's no rationale at all for the change.

Comment by Andy Sheldon [ 15/Jul/15 7:00 AM ]

If you look at a macro expansion in the bootstrap node repl, for the multi-binding for in the bootstrap, you see a

clojure.core/when-first
reference, instead of
cljs.core/when-first
.

Copying the core.cljc as-is and running a modified '(for) test generates the error:

cljs-bootstrap.core=>   (js/eval
    (with-out-str
      (ensure
        (c/emit
          (no-warn
            (ana/analyze
              (assoc (ana/empty-env) :context :expr)
              `(for [x# [1 2 3] y# [2 3 4]] 1)))))))

repl:48
throw e__4275__auto__;
      ^
Error: Can't recur here

Modifying the copied resources/cljs/core.cljc file, changing

defmacro for
to generate
(when-first [~bind ~gxs])
instead of
(core/when-first [~bind ~gxs])
, I can get a result:

cljs-bootstrap.core=>   (js/eval
    (with-out-str
      (ensure
        (c/emit
          (no-warn
            (ana/analyze
              (assoc (ana/empty-env) :context :expr)
              `(for [x# [1 2 3] y# [2 3 4]] x#)))))))
(1 1 1 2 2 2 3 3 3)
Comment by Andy Sheldon [ 15/Jul/15 7:02 AM ]

Attaching patch for core.cljc defmacro for

Comment by Mike Fikes [ 15/Jul/15 7:17 AM ]

I can confirm that cljs-1334-for-macro-v2.patch works for me downstream for ClojureScript JS (via Replete) and ClojureScript JVM (via Ambly) for the form (for [x [1] y [2]] y).

I can also confirm that the ClojureScript unit tests pass for me for V8, SpiderMonkey and JavaScriptCore (I don't have Nashorn configured).

Comment by David Nolen [ 15/Jul/15 11:29 AM ]

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





[CLJS-1331] Regex literal emits invalid JS Created: 08/Jul/15  Updated: 13/Jul/15  Resolved: 13/Jul/15

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

Type: Defect Priority: Major
Reporter: Mike Fikes Assignee: Mike Fikes
Resolution: Completed Votes: 0
Labels: bootstrap
Environment:

https://github.com/swannodette/cljs-bootstrap


Attachments: Text File CLJS-1331.patch    

 Description   
(with-out-str
  (c/emit
    (ensure
      (ana/analyze
        (assoc (ana/empty-env) :context :expr)
        '#"foo"))))) 
"/\\\\/foo\\\\//"

Non-bootstrap, for this case, using :repo-verbose emits \foo.

If you take this JS and eval it in Node you'll get

> /\\\\/foo\\\\//
SyntaxError: Unexpected token ILLEGAL
    at Object.exports.createScript (vm.js:44:10)
    at REPLServer.defaultEval (repl.js:117:23)
    at bound (domain.js:254:14)
    at REPLServer.runBound [as eval] (domain.js:267:12)
    at REPLServer.<anonymous> (repl.js:279:12)
    at REPLServer.emit (events.js:107:17)
    at REPLServer.Interface._onLine (readline.js:214:10)
    at REPLServer.Interface._line (readline.js:553:8)
    at REPLServer.Interface._ttyWrite (readline.js:830:14)
    at ReadStream.onkeypress (readline.js:109:10)

and in JSC

>>> /\\\\/foo\\\\//
Invalid escape in identifier: '\':1


 Comments   
Comment by Mike Fikes [ 12/Jul/15 7:03 PM ]

The attached patch passes manually-run regex tests taken from the test suite plus some additional tests I found online for JavaScript regexs (in particular, those involving the backslash character).

Comment by David Nolen [ 13/Jul/15 5:58 AM ]

fixed https://github.com/clojure/clojurescript/commit/6920b62be188809fcab97a593415cf0a72a39baa





[CLJS-1330] self-host: .toString on int needs parens Created: 08/Jul/15  Updated: 18/Aug/15

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

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

https://github.com/swannodette/cljs-bootstrap



 Description   
cljs-bootstrap.core=> (with-out-str
      (c/emit
        (ensure
          (ana/analyze
            (assoc (ana/empty-env) :context :expr)
            '(.toString 1)))))) 
"1.toString$()"
  • Note the lack of parens CLJS-715
  • Note the dollar sign after fn name is covered by separate ticket CLJS-1430





[CLJS-1329] Support for reading #js tagged literals in bootstrap Created: 07/Jul/15  Updated: 08/Jul/15  Resolved: 08/Jul/15

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

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

Attachments: Text File CLJS-1329-v1.patch    

 Description   

If you attempt to analyze a form like {{# [1 2]}} then cljs.analyzer/analyze-form, when in :cljs mode, lacks a cond case for JSValue, and it will drop through to the default, treating the form as a constant.

I haven't yet sorted out how to reproduce this with https://github.com/swannodette/cljs-bootstrap. My attempt so far is when I get to

cljs-bootstrap.core=> (r/read-string "#js [1 2]")    
Error: No reader function for tag js
...

Joel Martin's bootstrap Node and Replete, you will see the compiler attempting to handle the :constant AST:

cljs-bootstrap.repl> #js [1 2]
Error: No method in multimethod 'cljs.compiler/emit-constant' for dispatch value: function (val) {
  this.val = val;
}


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

The attached CLJS-1329-v1.patch appears to address the issue, but with two notes:

It uses :require instead of :import to get the JSValue tagged literal symbol for :cljs (not sure if this is the right approach).

It appears to emit the correct JS, and works in Replete, but for the map form, say if you issue

#js {:a 1}

then this JavaScript is emitted:

{"a": 1}

and then something will then indicate

Unexpected token ':'. Parse error.

Also, for both the map and vector forms, the individual values don't end up being surrounded with parenthesis like they do on ClojureScript JVM.

So, at best, this patch is a first stab, perhaps suitable for inspiration or refinement.

Comment by David Nolen [ 08/Jul/15 11:55 AM ]

fixed https://github.com/clojure/clojurescript/commit/2924c4880c05208beb0f321e8e4e63b4cb1c45f3





[CLJS-1326] In bootstrapped cljs, read-number of "0" gives "invalid number format" Created: 03/Jul/15  Updated: 12/Jul/15  Resolved: 03/Jul/15

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

Type: Defect Priority: Minor
Reporter: Joel Martin Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bootstrap
Environment:

cljs-bootstrap REPL (https://github.com/kanaka/cljs-bootstrap)



 Description   

tools.reader/read-number (https://github.com/swannodette/tools.reader) of "0" throws an error. The same for "1" works fine.

cljs-bootstrap.repl> 0
Error: Invalid number format [0]
    at new cljs$core$ExceptionInfo (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/core.js:33157:10)
    at Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/core.js:33219:9)
    at Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$2 (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/core.js:33215:26)
    at cljs$core$ex_info (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/core.js:33201:26)
    at Function.cljs.tools.reader.reader_types.reader_error.cljs$core$IFn$_invoke$arity$variadic (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/tools/reader/reader_types.js:802:25)
    at cljs$tools$reader$reader_types$reader_error (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/tools/reader/reader_types.js:798:52)
    at cljs$tools$reader$read_number (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/tools/reader.js:446:52)
    at /home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/tools/reader.js:1550:38
    at cljs$tools$reader$reader_types$log_source (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/tools/reader/reader_types.js:873:16)
    at cljs$tools$reader$target (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/tools/reader.js:1528:50)

This is because reader/read-number has:

(or (match-number s) (reader-error rdr "Invalid number format [" s "]")))

which compiled to this JS:

var or__4073__auto__ = cljs.tools.reader.impl.commons.match_number.call(null,s);
if(or__4073__auto__){
return or__4073__auto__;
} else {
return cljs.tools.reader.reader_types.reader_error.call(null,rdr,"Invalid number format [",s,"]");
}

Since match_number returns a JS number, or_4073auto_ is 0, therefore falsey.



 Comments   
Comment by Joel Martin [ 03/Jul/15 9:31 AM ]

FYI, to reproduce, run this in https://github.com/kanaka/cljs-bootstrap

lein run -m clojure.main script/build.clj
node repl.js
cljs-bootstrap.repl> 0
Error: Invalid number format [0]
...
Comment by David Nolen [ 03/Jul/15 2:55 PM ]

This ticket doesn't have nearly enough information. I checked the output of tools.reader and I don't see this generated code at all. The test is wrapped in the required call to truth_.

Comment by Mike Fikes [ 12/Jul/15 7:10 AM ]

FWIW, if this helps anyone else who might encounter this:

In Replete, this was occurring and was address by revising its build to compile macros after the main Replete namespace. The root cause was not determined, but this was tried based on a theory that *unchecked-if* was being set! but somehow left true.

Reference Replete commit: https://github.com/mfikes/replete/commit/e21c59b5f595fb8a10c25cae98a67dee7d0db013





[CLJS-1325] defrecord broken in bootstrapped cljs (error during set!) Created: 03/Jul/15  Updated: 14/Jul/15  Resolved: 14/Jul/15

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

Type: Defect Priority: Minor
Reporter: Joel Martin Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bootstrap
Environment:

cljs-bootstrap node.js RELP (https://github.com/kanaka/cljs-bootstrap)


Attachments: Text File CLJS-1325.patch    

 Description   

This is a follow-on to http://dev.clojure.org/jira/browse/CLJS-1321 for getting defrecord to work in the bootstrap node REPL.

cljs-bootstrap.repl> (defprotocol IFoo (foo [this]))
nil
cljs-bootstrap.repl> (defrecord Baz [b] IFoo (foo [this] (prn "some baz:" b)))
Error: Can't set! local var or non-mutable field
    at new cljs$core$ExceptionInfo (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/core.js:33157:10)
    at Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/core.js:33219:9)
    at cljs$core$ex_info (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/core.js:33205:26)
    at Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$3 (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/analyzer.js:699:26)
    at cljs$analyzer$error (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/analyzer.js:685:28)
    at Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$2 (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/analyzer.js:695:28)
    at cljs$analyzer$error (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/analyzer.js:681:28)
    at /home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/analyzer.js:2311:27
    at /home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/analyzer.js:2315:3
    at cljs.core.MultiFn.call.G__11387__6 (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/core.js:31419:149)

The same as above but with debug added to the analyzer set! method to print the form:

cljs-bootstrap.repl> (defprotocol IFoo (foo [this]))
DEBUG set! p__9852: (set! *unchecked-if* true)
DEBUG set! p__9852: (set! *unchecked-if* false)
nil
cljs-bootstrap.repl> (defrecord Baz [b] IFoo (foo [this] (prn "some baz:" b)))
DEBUG set! p__9852: (set! (.. Baz -prototype -cljs$core$ILookup$-lookup$arity$2) (cljs.core$macros/fn ([this__7850__auto__ k__7851__auto__] (cljs.core$macros/this-as this__7850__auto__ (cljs.core/-lookup this__7850__auto__ k__7851__auto__ nil)))))
DEBUG set! p__9852: (set! (.. Baz -prototype -cljs$core$ICollection$-conj$arity$2) (cljs.core$macros/fn ([this__7855__auto__ entry__7856__auto__] (cljs.core$macros/this-as this__7855__auto__ (if (cljs.core/vector? entry__7856__auto__) (cljs.core/-assoc this__7855__auto__ (cljs.core/-nth entry__7856__auto__ 0) (cljs.core/-nth entry__7856__auto__ 1)) (cljs.core/reduce cljs.core/-conj this__7855__auto__ entry__7856__auto__))))))
DEBUG set! p__9852: (set! (.. Baz -prototype -cljs$core$ILookup$-lookup$arity$3) (cljs.core$macros/fn ([this__7852__auto__ k25 else__7853__auto__] (cljs.core$macros/this-as this__7852__auto__ (cljs.core$macros/case k25 :b b (cljs.core/get __extmap k25 else__7853__auto__))))))
DEBUG set! p__9852: (set! (.. Baz -prototype -cljs$core$IPrintWithWriter$-pr-writer$arity$3) (cljs.core$macros/fn ([this__7864__auto__ writer__7865__auto__ opts__7866__auto__] (cljs.core$macros/this-as this__7864__auto__ (cljs.core$macros/let [pr-pair__7867__auto__ (cljs.core$macros/fn [keyval__7868__auto__] (cljs.core/pr-sequential-writer writer__7865__auto__ cljs.core/pr-writer "" " " "" opts__7866__auto__ keyval__7868__auto__))] (cljs.core/pr-sequential-writer writer__7865__auto__ pr-pair__7867__auto__ "#cljs-bootstrap.repl.Baz{" ", " "}" opts__7866__auto__ (cljs.core/concat [(cljs.core/vector :b b)] __extmap)))))))
DEBUG set! p__9852: (set! (.. Baz -prototype -cljs$core$IMeta$-meta$arity$1) (cljs.core$macros/fn ([this__7848__auto__] (cljs.core$macros/this-as this__7848__auto__ __meta))))
DEBUG set! p__9852: (set! (.. Baz -prototype -cljs$core$ICloneable$-clone$arity$1) (cljs.core$macros/fn ([this__7844__auto__] (cljs.core$macros/this-as this__7844__auto__ (new Baz b __meta __extmap __hash)))))
DEBUG set! p__9852: (set! (.. Baz -prototype -cljs$core$ICounted$-count$arity$1) (cljs.core$macros/fn ([this__7854__auto__] (cljs.core$macros/this-as this__7854__auto__ (cljs.core$macros/+ 1 (cljs.core/count __extmap))))))
DEBUG set! p__9852: (set! (.. Baz -prototype -cljs$core$IHash$-hash$arity$1) (cljs.core$macros/fn ([this__7845__auto__] (cljs.core$macros/this-as this__7845__auto__ (cljs.core$macros/caching-hash this__7845__auto__ hash-imap __hash)))))
DEBUG set! p__9852: (set! __hash h__7674__auto__)
Error: Can't set! local var or non-mutable field
    at new cljs$core$ExceptionInfo (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/core.js:33157:10)
    at Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/core.js:33219:9)
    at cljs$core$ex_info (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/core.js:33205:26)
    at Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$3 (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/analyzer.js:699:26)
    at cljs$analyzer$error (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/analyzer.js:685:28)
    at Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$2 (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/analyzer.js:695:28)
    at cljs$analyzer$error (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/analyzer.js:681:28)
    at /home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/analyzer.js:2312:27
    at /home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/analyzer.js:2316:3
    at cljs.core.MultiFn.call.G__11387__6 (/home/joelm/scratch/cljs-bootstrap/.cljs_bootstrap/cljs/core.js:31419:149)


 Comments   
Comment by Joel Martin [ 03/Jul/15 9:31 AM ]

FYI, to reproduce, run this in https://github.com/kanaka/cljs-bootstrap

lein run -m clojure.main script/build.clj
node repl.js
cljs-bootstrap.repl> (defprotocol IFoo (foo [this]))
cljs-bootstrap.repl> (defrecord Baz [b] IFoo (foo [this] (prn "some baz:" b)))
Error: Can't set! local var or non-mutable field
...
Comment by Mike Fikes [ 08/Jul/15 1:23 PM ]

To reproduce with https://github.com/swannodette/cljs-bootstrap

cljs-bootstrap.core=> (with-out-str
      (c/emit
        (ensure
          (ana/analyze
            (assoc (ana/empty-env) :context :expr)
             '(defrecord R []))))))

repl:42
throw e__4277__auto__;
      ^
Error: Can't set! local var or non-mutable field
    at new cljs$core$ExceptionInfo (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/core.js:32007:10)
    at Function.cljs.core.ex_info.cljs$core$IFn$_invoke$arity$3 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/core.js:32084:9)
    at Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$3 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.js:715:26)
    at Function.cljs.analyzer.error.cljs$core$IFn$_invoke$arity$2 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.js:711:28)
    at /Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.js:2411:27
    at /Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.js:2415:3
    at cljs.core.MultiFn.cljs$core$IFn$_invoke$arity$5 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/core.js:31494:114)
    at Object.cljs$analyzer$analyze_seq_STAR_ [as analyze_seq_STAR_] (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.js:3882:81)
    at Function.cljs.analyzer.analyze_seq.cljs$core$IFn$_invoke$arity$4 (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.js:3925:26)
    at Object.cljs$analyzer$analyze_form [as analyze_form] (/Users/mfikes/Projects/cljs-bootstrap/.cljs_node_repl/cljs/analyzer.js:4069:34)
Comment by David Nolen [ 09/Jul/15 12:16 PM ]

The thing to investigate here is why the compiler thinks it's setting a local. If you're using cljs-bootstrap make sure to run lein npm install to get source map support. It makes it pretty easy to figure out what's going wrong in the analyzer. It's what I've been using to pinpoint bugs.

Comment by Mike Fikes [ 09/Jul/15 5:34 PM ]

Results of partial investigation: If you macroexpand-1 the (defrecord R []) form, and then take those results and attempt to evaluate them, you will get the error regarding set!. Then eliminating sub-forms from that expansion, you can reduce it down to

(defrecord* R [] nil (extend-type R IHash (-hash [this] (caching-hash this hash-imap __hash))))

So, there is a set! in the expansion of caching-hash, which would mutate the __hash field

https://github.com/clojure/clojurescript/blob/6b590f2fdf898e94a65153f8059ebdf0e3ec0952/src/main/clojure/cljs/core.cljc#L1592

which is set to be ^:mutable

https://github.com/clojure/clojurescript/blob/6b590f2fdf898e94a65153f8059ebdf0e3ec0952/src/main/clojure/cljs/core.cljc#L1583

A theory would be that either the meta is not conveyed properly, or, perhaps this is simply going down the wrong path, with perhaps a limitation of macroexpand-1 not being capable of processing meta, in which case the above analysis is wrong.

Comment by David Nolen [ 10/Jul/15 9:01 AM ]

The places to look now are much narrower. Something is wrong with parse-type or parse 'set! cases in cljs.analyzer. I would add some printlns using :cljs reader conditionals to make it more readily apparent what is going on. Another option would be to use the browser based setup in cljs-bootstrap and set some breakpoints.

Comment by Mike Fikes [ 11/Jul/15 6:19 PM ]

If you examine the local in parse 'set!, you will see

{:name __hash, :field true, :column nil, :unsynchronized-mutable nil, :line nil, :tag nil, :mutable nil, :volatile-mutable nil, :shadow nil}

Experimenting with the (released) Node.js REPL, shows that ^:mutable doesn't work as intended in ClojureScript within a quoted vector:

cljs.user=> (map meta '[x y ^:mutable z])
(nil nil nil)

But, this can be worked around:

cljs.user=> (map meta ['x 'y (with-meta 'z {:mutable true})])
(nil nil {:mutable true})

Both of the above work in Clojure, while only the second evidently works in ClojureScript.

So this patch fixes the problem by employing this technique. (Perhaps there is a deeper ClojureScript bug; if so, it is not a regression since 0.0-3308.)

With this, defrecord doesn't quite work fully. (Separate tickets can be opened for it.) But, the mutability of the __hash field is properly established.

Comment by Mike Fikes [ 11/Jul/15 6:43 PM ]

The attached patch is arguably working around something that should work (even in 0.0-3308), and perhaps it was only just now discovered via the bootstrap effort.

Is it a defect in cljs.tools.reader? This was done with the version being used within https://github.com/swannodette/cljs-bootstrap

cljs-bootstrap.core=> (meta (last (last (cljs.tools.reader/read-string "'[x y ^:mutable z]"))))
{:mutable true}
Comment by Mike Fikes [ 11/Jul/15 7:43 PM ]

See CLJS-1333. Perhaps this is a defect in ClojureScript.

Comment by David Nolen [ 14/Jul/15 10:43 AM ]

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





[CLJS-1321] defrecord broken in bootstrapped cljs Created: 01/Jul/15  Updated: 02/Jul/15  Resolved: 02/Jul/15

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

Type: Defect Priority: Minor
Reporter: Joel Martin Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: bootstrap
Environment:

cljs-bootstrap REPL (https://github.com/swannodette/cljs-bootstrap)



 Description   

First problem that I run into is that emit-defrecord makes use of .getNamespace and .getName on rname. That should probably be (namespace rname) and (name rname). After that change is made the next error is "Can't set! local var or non-mutable field" somewhere in defrecord. Not sure what the cause of that one is.



 Comments   
Comment by David Nolen [ 02/Jul/15 6:03 PM ]

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

Comment by David Nolen [ 02/Jul/15 6:04 PM ]

I did not look into the set! issue. Separate ticket should be opened for that if it persists.

Comment by Mike Fikes [ 02/Jul/15 6:46 PM ]

Confirmed fixed downstream (https://github.com/mfikes/replete/issues/25), apart from other Can't set! local var or non-mutable field error, which needs a separate ticket.





[CLJS-1247] Split out error printing from regular printing Created: 04/May/15  Updated: 15/Jul/15  Resolved: 15/Jul/15

Status: Resolved
Project: ClojureScript
Component/s: None
Affects Version/s: 0.0-3269
Fix Version/s: 1.7.28

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


 Comments   
Comment by David Nolen [ 06/May/15 9:02 AM ]

See CLJS-710

Comment by David Nolen [ 15/Jul/15 4:19 PM ]

fixed https://github.com/clojure/clojurescript/commit/074445f5c8eccd5a4ff6d075b9d4b3d96bc367ee





[CLJS-859] Downloads for bootstrap script should happen over HTTPS. Created: 17/Sep/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

Type: Enhancement Priority: Major
Reporter: David Kinzer Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bootstrap, https

Attachments: Text File bootstrap-over-https.patch    
Patch: Code

 Description   

Currently all downloads for the clojurescript bootstrap process are happening over HTTP. If this is switched to HTTPS it adds a layer of security at no real cost.



 Comments   
Comment by David Nolen [ 17/Sep/14 12:20 PM ]

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





[CLJS-161] Update bootstrap to current version of Google's Closure Library Created: 14/Mar/12  Updated: 27/Jul/13  Resolved: 08/May/12

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

Type: Task Priority: Major
Reporter: Gianni Chiappetta Assignee: Hubert Iwaniuk
Resolution: Completed Votes: 0
Labels: bootstrap, closure
Environment:

N/A


Attachments: Text File CLJS-161-CLJS-35-with-static-serving.patch    

 Description   

The current bundled version of Google's Closure Library is out of date and missing a lot of useful additions. The bootstrap currently requests version r790, however r1376 has been available for several months now.

The latest version can be found here: http://closure-library.googlecode.com/files/closure-library-20111110-r1376.zip



 Comments   
Comment by David Nolen [ 14/Mar/12 7:09 PM ]

CLJS-35 has a non-working patch. If it's fixed for OS X, I'll apply it.

Comment by Gianni Chiappetta [ 15/Mar/12 10:44 AM ]

@David Once the patch is fixed, can we do both?

Comment by David Nolen [ 15/Mar/12 11:12 AM ]

The ideal patch would allow you to get head, a specific revision. Unless I'm missing something it would also be nice to get a bootstrap.bat

Comment by Hubert Iwaniuk [ 21/Apr/12 3:17 AM ]

Attached patch uses newer version of GClosure.

Comment by David Nolen [ 21/Apr/12 9:27 AM ]

fixed, https://github.com/clojure/clojurescript/commit/8b74d8dcb4edeb80fda72ae7f7c1e5872dc59687

Comment by David Nolen [ 22/Apr/12 3:34 PM ]

Reverted. This patch related to CLJS-35 broke browser REPL. I'll happily apply a new patch that addresses the browser REPL issues

Comment by Hubert Iwaniuk [ 30/Apr/12 3:37 AM ]

New GClosure and static serving.

Comment by Hubert Iwaniuk [ 08/May/12 6:05 AM ]

New patch should solve both, this and CLJS-35.

Comment by David Nolen [ 08/May/12 11:38 PM ]

fixed, https://github.com/clojure/clojurescript/commit/63eea77d4d6a2ec31bb017da9f343be5f29a61a4





Generated at Fri Sep 04 20:14:39 CDT 2015 using JIRA 4.4#649-r158309.