<< Back to previous view

[CLJS-1389] Support Override of Custom Closure Defines w/ :none/:whitespace Created: 02/Aug/15  Updated: 04/Aug/15  Resolved: 03/Aug/15

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

Type: Enhancement Priority: Minor
Reporter: Martin Klepsch Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1389-provide-define-macro-to-support-proper-use.patch     Text File CLJS-1389-provide-define-macro-to-support-proper-use.patch    

 Description   

When creating "uncompiled" builds (:none, :whitespace) it is not possible to override a custom Closure @define by passing a different value to the compiler option :closure-defines.

Closure provides CLOSURE_UNCOMPILED_DEFINES and CLOSURE_DEFINES [1] which can be set before loading any other code.
Overriding defines this way only works for Defines with done with goog.define.
Using goog.define however introduces other problems:
1) The name passed to goog/define must match the name in compiled JS. E.g. (goog/define "hello_world.core.DBG" true).
2) This produces no var in CLJS which causes an undeclared var warning if the defined var is used.
3) There is nothing to be annotated causing ERROR: JSC_INVALID_MISSING_DEFINE_ANNOTATION.

Getting the CLOSURE_UNCOMPILED_DEFINES into the build is straightforward, just not sure how to deal with those other complexities.

[1] http://google.github.io/closure-library/api/source/closure/goog/base.js.src.html#l147



 Comments   
Comment by David Nolen [ 03/Aug/15 5:14 AM ]

Why can't we just emit CLOSURE_DEFINES under :none? If user supplies :main this is simple to do here https://github.com/clojure/clojurescript/blob/d946a58153ec5132063f1ac29acd8d4bcd1bdeb2/src/main/clojure/cljs/closure.clj#L1124-L1143

If this cannot work there should be documentation on this ticket as to why. Thanks!

Comment by Martin Klepsch [ 03/Aug/15 6:06 AM ]

I created a sample in the Clojurescript repo to illustrate this: https://github.com/martinklepsch/clojurescript/tree/defines-in-none/samples/defines

TLDR; goog.define is not just sugar and is required to look things up at runtime from CLOSURE_DEFINES and CLOSURE_UNCOMPILED_DEFINES.

Copy of the README:

Custom Defines in :none

See CLJS-1389.

Most straightforward solution would be to prepend CLOSURE_UNCOMPILED_DEFINES or CLOSURE_DEFINES to the main file as
done in 9962889. Unfortunately
this won't work. Values in these globals are only looked up at runtime when something has been defined with

/** @define {boolean} */
goog.define('my.thing.DEBUG', false)

See source of goog.define.
In comparison defining something through CLJS will result in the following

(def ^{:jsdoc ["@define {boolean}"]}
  DEBUG true)

compiles to:

/**
 * @define {boolean}
 */
my.thing.DEBUG = true;

The @define JSDoc tag is appropriately set but since there is no runtime lookup no values from CLOSURE_DEFINES or CLOSURE_UNCOMPILED_DEFINES will be used.
In comparison goog.define does the runtime lookup.

There is an example in this directory where you can see that modifying the :closure-defines passed to the compiler will not have any effect on the compiled core.js.

Docstrings for CLOSURE_DEFINES and CLOSURE_UNCOMPILED_DEFINES are also interesting.

Possible solution

Using goog.define instead of just the :jsdoc metadata would allow
overriding in all optimization modes. Emitting goog.define properly without
causing warnings or errors requires the following:

1. The goog.define call needs to be annotated with the JSDoc @define tag.
2. We need to declare the var defined, otherwise there will be undeclared Var warnings

There's a macro in samples/defines/src/hello_world/core.clj that I
wrote while experimenting what's required to make this work.

Comment by Martin Klepsch [ 03/Aug/15 11:19 AM ]

Patch introducing cljs.core/define macro and prepending :closure-defines to main file.

EDIT: I settled on using CLOSURE_UNCOMPILED_DEFINES because it seemed most appropriate given
that it's only ever used in "uncompiled" mode.

Comment by Martin Klepsch [ 03/Aug/15 12:16 PM ]

Please review/give feedback.

Comment by David Nolen [ 03/Aug/15 1:49 PM ]

This patch needs to be rebased to master.

Comment by Martin Klepsch [ 03/Aug/15 1:53 PM ]

rebased patch on master

Comment by David Nolen [ 03/Aug/15 2:01 PM ]

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

Comment by Martin Klepsch [ 04/Aug/15 8:20 AM ]

cljs.core/define has been renamed to cljs.core/goog-define.
https://github.com/clojure/clojurescript/commit/37ce674742f2969597cbb3b5e25dfa0cc77bd619





[CLJS-1177] A compiler support for non-Closure transforms (JSX, etc) Created: 28/Mar/15  Updated: 03/Aug/15  Resolved: 03/Aug/15

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

Type: Enhancement Priority: Major
Reporter: David Nolen Assignee: Maria Geller
Resolution: Completed Votes: 1
Labels: None

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

 Description   

There are now a variety of JS dialects, JSX, TypeScript etc. which need to be transformed first into regular JS before module processing. We should devise a standard way to deal with this. As we cannot predict what various dialects may arise in the future it's probably best to provide something like :preprocess-module option to cljs.closure/build.



 Comments   
Comment by David Nolen [ 17/Jun/15 5:20 PM ]

We should verify with Babel now that React is moving away from JSX.

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

I went ahead and looked into this a bit. Looks like getting Babel to work will take some time. Babel has difficulties loading into Nashorn due to code size limits that originate from Lodash usage. JSX while deprecated is still the most widely used option so we have some time yet and the interface supplied by both tools is exactly the same. So we should test this feature with JSX and switch to Babel when the issues are resolved.

Comment by Maria Geller [ 03/Aug/15 12:38 PM ]

Attached a patch for adding support for foreign libs preprocessing. Users can add support for a JS dialect by implementing the js-transforms function and using the :preprocess foreign lib compiler option. Both, js-transforms and convert-js-modules, now take an IJavaScript and return an IJavaScript.

Comment by David Nolen [ 03/Aug/15 1:54 PM ]

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





[CLJS-1296] browser REPL should queue prints before connection then flush after connection Created: 01/Jun/15  Updated: 03/Aug/15  Resolved: 03/Aug/15

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

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


 Description   

If the page loads and attempts to print before the connection is made the application will unintuitively error out.



 Comments   
Comment by David Nolen [ 03/Aug/15 6:55 AM ]

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





[CLJS-1388] Stacktrace element handling for :output-dir w/o file/line/column Created: 02/Aug/15  Updated: 03/Aug/15  Resolved: 03/Aug/15

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

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


 Description   

If parsing stacktraces when :host and :port are supplied, elements that have no file/line/column are properly accommodated.

For example:

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

But, an attempt to process a similar stacktrace when :output-dir is being used, an error will be thrown. (This can occur when using :output-dir for embedded JavaScriptCore.)

Here is a simple repro:

(parse-stacktrace {}
"cljs$core$seq@out/cljs/core.js:3999:17
cljs$core$first@out/core.js:4018:22
cljs$core$ffirst@out/cljs/core.js:5161:39
global code"
{:ua-product :safari} 
{:output-dir "out"})


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

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





[CLJS-1311] Improve error reporting when converting JavaScript modules Created: 15/Jun/15  Updated: 02/Aug/15  Due: 21/Aug/15  Resolved: 02/Aug/15

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

Type: Enhancement Priority: Major
Reporter: Maria Geller Assignee: Maria Geller
Resolution: Completed Votes: 2
Labels: None

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

 Description   

When using the Google Closure compiler via the command line and trying to convert a JavaScript module which has trailing commas, the compiler throws a parse error, e.g.:

chance.js:1109: ERROR - Parse error. IE8 (and below) will parse trailing commas in array and object literals incorrectly. If you are targeting newer versions of JS, set the appropriate language_in option.
                        '09' + self.string({ pool: '0123456789', length: 8}),

At the moment, we don't throw any errors when converting a module and an error occurs. Instead, just the following gets emitted by the Google Closure compiler:

goog.provide("module$libs$chance");var module$libs$chance={}

We need to change this behaviour to show the warnings and errors the Google Closure compiler is emitting.



 Comments   
Comment by Kristian Mandrup [ 16/Jun/15 10:53 PM ]

Yes, by default don't convert the CommonJS module, unless perhaps if you set a specific --force compile option.

Comment by Maria Geller [ 01/Aug/15 3:34 PM ]

Show Google Closure compiler warnings when converting JS modules and set :closure-warnings, :closure-extra-annotations and :pretty-print options. We cannot use the make-options functions for this, since it requires an optimizations level. Instead pull options that we want to use into set-options function.

Comment by David Nolen [ 02/Aug/15 8:37 AM ]

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





[CLJS-1387] support for Closure libraries that conform to classpath conventions does not work for local libraries Created: 01/Aug/15  Updated: 01/Aug/15  Resolved: 01/Aug/15

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

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


 Description   

Only works for libs in JARs.



 Comments   
Comment by David Nolen [ 01/Aug/15 10:50 AM ]

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





[CLJS-1386] Symbols should be added to the constants table Created: 01/Aug/15  Updated: 01/Aug/15  Resolved: 01/Aug/15

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

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


 Description   

Now that optional bootstrap is a thing, this is a significant optimization.



 Comments   
Comment by David Nolen [ 01/Aug/15 6:11 AM ]

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





[CLJS-1336] Create bootstrapping namespace Created: 12/Jul/15  Updated: 31/Jul/15  Resolved: 31/Jul/15

Status: Resolved
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: None


 Description   

This namespace should provide basic analyze, emit, eval functionality along with necessary helpers for establishing the compilation environment. *load-file* or something similar must be bound by the user. One open question is how to handle async versus sync file loading. In the browser context only the former is really realistic, while in Node.js/iOS/Android we have considerably more flexibility.



 Comments   
Comment by David Nolen [ 12/Jul/15 2:05 PM ]

CLJS-1337 must be addressed first.

Comment by David Nolen [ 31/Jul/15 8:12 PM ]

fixed in master





[CLJS-1385] cljs.js/compile-str does not correctly track the current ns Created: 31/Jul/15  Updated: 31/Jul/15  Resolved: 31/Jul/15

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

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


 Description   

Macros are not correctly expanded. Instead macro calls resolve to cljs.user.



 Comments   
Comment by David Nolen [ 31/Jul/15 10:22 AM ]

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





[CLJS-1380] Hashing is broken when using iphone 4 Created: 30/Jul/15  Updated: 31/Jul/15  Resolved: 31/Jul/15

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

Type: Defect Priority: Minor
Reporter: Jean-Louis Giordano Assignee: Unassigned
Resolution: Declined Votes: 0
Labels: bug
Environment:

iphone 4 running iOS 7.1.2



 Description   

On a physical iPhone 4 running iOS 7.1.2, when running the `hash` function too many times at the top level, the result becomes inconsistent.

This only happens when not using the safari webinspector.

I have setup a minimal failing spec here: https://github.com/Jell/iphone-bug

Instructions to reproduce in the README.

I must confess, this took me a very long time to debug! I hope someone can take it from here.



 Comments   
Comment by Jean-Louis Giordano [ 30/Jul/15 7:23 AM ]

With the help of my colleague, we narrowed it down further to this:

(ns iphone-bug.core)

(def yyyy (hash "yyyy"))

(dotimes [i 1000] (hash "yyyy"))

(js/alert (str "Before: " yyyy " After: " (hash "yyyy")))
Comment by Jean-Louis Giordano [ 30/Jul/15 7:36 AM ]

Note: the bug only appears on iPhone 4, not iPhone 4S!

Comment by David Nolen [ 30/Jul/15 10:58 AM ]

I believe this is something to do with 32bit vs. 64bit JavaScriptCore. Super low priority but happy to take a patch if someone can devise one.

Comment by Thomas Heller [ 30/Jul/15 11:34 AM ]

Sounds like something which was fixed a long time ago and I haven't personally seen since. Maybe a recent change reverted the Math.imul fix?

http://dev.clojure.org/jira/browse/CLJS-839
http://dev.clojure.org/jira/browse/CLJS-830

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

Thomas I'm not sure we solved this for older phones only relatively newer ones with specific versions of Safari. iPhone 4 was ARM Cortex A8, and the 4S was an ARM Cortex A9. Turns out both are 32bit, but I still suspect this is a JITing issue if it disappears with a debugger attached.

Comment by Thomas Heller [ 31/Jul/15 3:33 AM ]

Just saying that the description exactly matched what I saw when investigating the keyword hashing issue. The problem never appeared with the devtools running and sometimes produced the correct hash without. After adding the imul.js the issue disappeared and clients stopped sending invalid maps. See CLJS-830 for a list of user agents [1] that were problematic before, the issue was with a specific webkit version and seemingly not hardware related (iOS 7.1.2 was the version at the time, user agents don't identify the device though).

Not claiming that this is the same issue, just saying that it sounds very very similar.

[1] https://gist.github.com/thheller/8cae79cabd9ac74958ca

Comment by Jean-Louis Giordano [ 31/Jul/15 9:32 AM ]

We found a fix that works for us!

We redefine the imul polyfill (cljs/imul.js) with the following:

if(typeof Math.imul == "undefined" || (Math.imul(0xffffffff,5) == 0)) {
    Math.imul = function (a, b) {
      try {
        var ah  = (a >>> 16) & 0xffff;
        var al = a & 0xffff;
        var bh  = (b >>> 16) & 0xffff;
        var bl = b & 0xffff;
        // the shift by 0 fixes the sign on the high part
        // the final |0 converts the unsigned value into a signed value
        return ((al * bl) + (((ah * bl + al * bh) << 16) >>> 0)|0);
      } catch(err) { throw err; }
    }
}

The error is not really coming from inside this function, but adding the try/catch disables JIT optimisation for callers of imul as far as we understand, which solves the hashing issues we saw on Iphone 4.

The errors seems to come from bit operations, in particular the `x|0` operations (corresponding to (int x) calls or bit-or in CLJS).

Infuriating to pin the bug down, because observing intermediate variables will prevent the bug from happening!

Comment by Francis Avila [ 31/Jul/15 9:59 AM ]

This is going to cause an enormous performance regression.

Comment by Jean-Louis Giordano [ 31/Jul/15 10:05 AM ]

Well a perf regression for the browsers that do not have a built-in or broken Math/imul, which might not be that big of a deal?

This is good enough for us at least, so we will probably not be investigating this further.

Comment by David Nolen [ 31/Jul/15 10:20 AM ]

Thanks for the bug report good to have monkey-path solution for those that need it. Closing this one.





[CLJS-1384] cljs.js/eval-str doc that :ns returned upon success Created: 31/Jul/15  Updated: 31/Jul/15  Resolved: 31/Jul/15

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

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


 Description   

If eval-str is called and it succeeds with a `:value`, the resulting `:ns` is also passed back, but the doctoring hasn't been updated to reflect this fact.



 Comments   
Comment by David Nolen [ 31/Jul/15 8:38 AM ]

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





[CLJS-1381] cljs.js: Memory perf on JSC for first defn evaluation 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: Major
Reporter: Mike Fikes Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None

Attachments: PNG File memory.png    

 Description   

If you evaluate something like (defn f []) via cljs.js/eval-str with JavaScriptCore, a spike in memory will occur and it will take several seconds to complete the evaluation. After this, subsequent evaluations don't exhibit this behavior. Also, this doesn't occur for Firefox or Chrome.

Additionally, it did not occur previously with bootstrapped ClojureScript when we were building things outside of `cljs.js` (it doesn't occur in Replete, for example, nor the earlier versions of Planck: https://youtu.be/AMT63rxK4E8).

You can see it for yourself at http://ClojureScript.net (you can see the slowness in desktop Safari, and on an iPhone it exhausts memory).



 Comments   
Comment by Mike Fikes [ 30/Jul/15 10:58 AM ]

Attached memory.png, which shows what happens in Planck when you do (defn f [])

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

This is the same as CLJS-910. An easy workaround is :static-fns true.





[CLJS-1376] Printing in a tagged literal data form Created: 28/Jul/15  Updated: 30/Jul/15  Resolved: 30/Jul/15

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

Type: Task Priority: Major
Reporter: Ewen Grosjean Assignee: David Nolen
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File CLJS-1376.patch    

 Description   

Since Clojure 1.7, objects, functions, atoms and volatiles print in a tagged literal data form.

(atom {})
#object[clojure.lang.Atom 0x349c1daf {:status :ready, :val {}}]

Clojurescript format is different

(atom {})
#<Atom: {}>


 Comments   
Comment by Ewen Grosjean [ 30/Jul/15 3:52 PM ]

patch attached.

(fn [] nil)
#object ["function" "function (){\nreturn null;\n}"]
(js/AnimationEvent. 1)
#object ["object" "[object AnimationEvent]"]
(atom {})
#object [cljs.core.Atom {:status :ready, :val {}}]
(volatile! 1)
#object [cljs.core.Volatile 1]

I have also made undefined printing to nil.

I hope that helps.

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

fixed https://github.com/clojure/clojurescript/commit/34c3b8985ed8197d90f441c46d168c4024a20eb8

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

Ewen you need to submit a CA if you want to submit patches. Once you've done that you should assign tickets to yourself if you decide to work on them so people are aware of progress.

Comment by Ewen Grosjean [ 30/Jul/15 4:26 PM ]

Thanks for the fix.

I think there are still a few things missing.
Atom and volatile are still printed the old way: https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L9053
As is "undefined", even though undefined is printed as nil because it is catched by the nil? clause:
https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L8776





[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-1316] let does not detect invalid binding vector when it contains destructuring Created: 19/Jun/15  Updated: 30/Jul/15  Resolved: 30/Jul/15

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

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

Attachments: Text File CLJS-1319-29-July-15.patch    

 Description   

The presence of destructuring in a `let` binding vector prevents detection of basic errors.

cljs.user=> *clojurescript-version*
"0.0-3308"
cljs.user=> (let [{a :a} {:a 0} b] a)
0
cljs.user=> (let [a 0 b] a)
clojure.lang.ExceptionInfo: bindings must be vector of even number of elements at line 1 <cljs repl> {:file "<cljs repl>", :line 1, :column 1, :tag :cljs/analysis-error}

David Nolen mentions that this looks like something busted with the cljs.core/assert-args macro



 Comments   
Comment by Samuel Miller [ 29/Jul/15 8:27 PM ]

I have a solution for this but I don't completely understand why the solution I have works.

In core.cljc you have assert-args(used by let, loop, for, doseq) and core/assert-args(used by if-let, when-first, when-let, if-some...). This problem also exist in loop but not in for and doseq. This is because the marco's arguments are [fnname & pairs] and when you use non-core assert-args you need to supply the fnname. I am not sure why this exploded only with destructing... Also not sure where to add tests for this.

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

fixed https://github.com/clojure/clojurescript/commit/32e7559afab7b8b6620481ef44932697d3dd81d4





[CLJS-1383] cljs.js/eval in a specific ns does not work Created: 30/Jul/15  Updated: 30/Jul/15  Resolved: 30/Jul/15

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

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


 Description   
(cljs/eval (cljs/empty-state)
           '(def x 1)
           {:eval cljs/js-eval
            :context :expr
            :def-emits-var true
            :ns cells.core
            }
           #(pprint %))


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

Cannot repro on master





[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-836] Replace seq-based iterators with direct iterators for all non-seq collections that use SeqIterator Created: 08/Aug/14  Updated: 30/Jul/15  Resolved: 30/Jul/15

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

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

Attachments: Text File cljs_836_v1.patch     Text File cljs_836_v2.patch     Text File cljs_836_v3.patch    
Patch: Code and Test

 Description   

See http://dev.clojure.org/jira/browse/CLJ-1499



 Comments   
Comment by Peter Schuck [ 12/Dec/14 4:56 PM ]

This is a port of the patches / diffs at http://dev.clojure.org/jira/browse/CLJ-1499. I'm getting around a 2X perf improvement when running the benchmark quite.

Comment by David Nolen [ 13/Dec/14 8:43 AM ]

Thanks, looks great! Will check with Alex Miller about the status of CLJ-1499 and see if we can apply this one.

Comment by Peter Schuck [ 03/Apr/15 10:10 AM ]

CLJ-1499 has been applied to Clojure. I updated the patch to update the tests.

Comment by Peter Schuck [ 30/Jul/15 10:36 AM ]

Another update for the new file structure and cljc files.

Comment by David Nolen [ 30/Jul/15 10:55 AM ]

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





[CLJS-1377] om-tools.core fails to compile Created: 29/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: Sean Grove Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None


 Description   

Any file with a ns declaration that requires om-tools.core will throw an exception:

(ns example.core (:require [om-tools.core]))

=>

clojure.lang.ExceptionInfo: failed compiling file:src/cljs/example/core.cljs {:file #object[java.io.File 0x37f37699 "src/cljs/example/core.cljs"]}
at clojure.core$ex_info.invoke(core.clj:4593)
at cljs.compiler$compile_file$fn__2999.invoke(compiler.cljc:1249)
at cljs.compiler$compile_file.invoke(compiler.cljc:1211)
at cljs.compiler$compile_root.invoke(compiler.cljc:1286)
at cljs.closure$compile_dir.invoke(closure.clj:430)
at cljs.closure$eval3382$fn__3383.invoke(closure.clj:470)
at cljs.closure$eval3334$fn_3335$G3325_3342.invoke(closure.clj:375)
at cljs.closure$eval3395$fn__3396.invoke(closure.clj:484)
at cljs.closure$eval3334$fn_3335$G3325_3342.invoke(closure.clj:375)
at cljsbuild.compiler.SourcePaths$fn__3862.invoke(compiler.clj:67)
at clojure.core$map$fn__4553.invoke(core.clj:2622)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:507)
at clojure.core$seq__4128.invoke(core.clj:137)
at clojure.core$apply.invoke(core.clj:630)
at clojure.core$mapcat.doInvoke(core.clj:2660)
at clojure.lang.RestFn.invoke(RestFn.java:423)
at cljsbuild.compiler.SourcePaths._compile(compiler.clj:67)
at cljs.closure$build.invoke(closure.clj:1634)
at cljs.closure$build.invoke(closure.clj:1590)
at cljsbuild.compiler$compile_cljs$fn__3873.invoke(compiler.clj:81)
at cljsbuild.compiler$compile_cljs.invoke(compiler.clj:80)
at cljsbuild.compiler$run_compiler.invoke(compiler.clj:187)
at user$eval4007$iter_40434047$fn4048$fn_4066.invoke(form-init7604443915532456796.clj:1)
at user$eval4007$iter_40434047$fn_4048.invoke(form-init7604443915532456796.clj:1)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:507)
at clojure.core$seq__4128.invoke(core.clj:137)
at clojure.core$dorun.invoke(core.clj:3009)
at clojure.core$doall.invoke(core.clj:3025)
at user$eval4007.invoke(form-init7604443915532456796.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: clojure.lang.ExceptionInfo: Don't know how to create ISeq from: clojure.lang.Symbol {:tag :cljs/analysis-error}
at clojure.core$ex_info.invoke(core.clj:4593)
at cljs.analyzer$error.invoke(analyzer.cljc:525)
at cljs.analyzer$analyze_seq_STAR__wrap.invoke(analyzer.cljc:2363)
at cljs.analyzer$analyze_seq.invoke(analyzer.cljc:2381)
at cljs.analyzer$analyze_form.invoke(analyzer.cljc:2490)
at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2536)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2552)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2547)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2546)
at cljs.analyzer$analyze_do_statements_STAR_$fn__1522.invoke(analyzer.cljc:1370)
at clojure.core$map$fn__4553.invoke(core.clj:2622)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:507)
at clojure.core$seq__4128.invoke(core.clj:137)
at cljs.analyzer$analyze_do_statements_STAR_.invoke(analyzer.cljc:1370)
at cljs.analyzer$analyze_do_statements.invoke(analyzer.cljc:1373)
at cljs.analyzer$eval1526$fn__1528.invoke(analyzer.cljc:1377)
at clojure.lang.MultiFn.invoke(MultiFn.java:251)
at cljs.analyzer$analyze_seq_STAR_.invoke(analyzer.cljc:2359)
at cljs.analyzer$analyze_seq_STAR__wrap.invoke(analyzer.cljc:2364)
at cljs.analyzer$analyze_seq.invoke(analyzer.cljc:2381)
at cljs.analyzer$analyze_form.invoke(analyzer.cljc:2490)
at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2536)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2552)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2547)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2546)
at cljs.analyzer$analyze_let_body_STAR_.invoke(analyzer.cljc:1456)
at cljs.analyzer$analyze_let_body.invoke(analyzer.cljc:1461)
at cljs.analyzer$analyze_let.invoke(analyzer.cljc:1477)
at cljs.analyzer$eval1545$fn__1546.invoke(analyzer.cljc:1489)
at clojure.lang.MultiFn.invoke(MultiFn.java:251)
at cljs.analyzer$analyze_seq_STAR_.invoke(analyzer.cljc:2359)
at cljs.analyzer$analyze_seq_STAR__wrap.invoke(analyzer.cljc:2364)
at cljs.analyzer$analyze_seq.invoke(analyzer.cljc:2381)
at cljs.analyzer$analyze_form.invoke(analyzer.cljc:2490)
at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2536)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2552)
at cljs.analyzer$analyze_seq.invoke(analyzer.cljc:2382)
at cljs.analyzer$analyze_form.invoke(analyzer.cljc:2490)
at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2536)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2552)
at cljs.analyzer$analyze_seq.invoke(analyzer.cljc:2382)
at cljs.analyzer$analyze_form.invoke(analyzer.cljc:2490)
at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2536)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2552)
at cljs.analyzer$analyze_file$fn__2031.invoke(analyzer.cljc:2796)
at cljs.analyzer$analyze_file.invoke(analyzer.cljc:2791)
at cljs.analyzer$analyze_deps.invoke(analyzer.cljc:1625)
at cljs.analyzer$ns_side_effects.invoke(analyzer.cljc:2457)
at cljs.analyzer$analyze_STAR_$fn__1980.invoke(analyzer.cljc:2537)
at clojure.lang.PersistentVector.reduce(PersistentVector.java:333)
at clojure.core$reduce.invoke(core.clj:6518)
at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2537)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2552)
at cljs.analyzer$analyze_file$fn__2031.invoke(analyzer.cljc:2796)
at cljs.analyzer$analyze_file.invoke(analyzer.cljc:2791)
at cljs.analyzer$analyze_deps.invoke(analyzer.cljc:1625)
at cljs.analyzer$ns_side_effects.invoke(analyzer.cljc:2457)
at cljs.analyzer$analyze_STAR_$fn__1980.invoke(analyzer.cljc:2537)
at clojure.lang.PersistentVector.reduce(PersistentVector.java:333)
at clojure.core$reduce.invoke(core.clj:6518)
at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2537)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2552)
at cljs.analyzer$analyze_file$fn__2031.invoke(analyzer.cljc:2796)
at cljs.analyzer$analyze_file.invoke(analyzer.cljc:2791)
at cljs.analyzer$analyze_deps.invoke(analyzer.cljc:1625)
at cljs.analyzer$ns_side_effects.invoke(analyzer.cljc:2457)
at cljs.analyzer$analyze_STAR_$fn__1980.invoke(analyzer.cljc:2537)
at clojure.lang.PersistentVector.reduce(PersistentVector.java:333)
at clojure.core$reduce.invoke(core.clj:6518)
at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2537)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2552)
at cljs.analyzer$analyze_file$fn__2031.invoke(analyzer.cljc:2796)
at cljs.analyzer$analyze_file.invoke(analyzer.cljc:2791)
at cljs.analyzer$analyze_deps.invoke(analyzer.cljc:1625)
at cljs.analyzer$ns_side_effects.invoke(analyzer.cljc:2457)
at cljs.analyzer$analyze_STAR_$fn__1980.invoke(analyzer.cljc:2537)
at clojure.lang.PersistentVector.reduce(PersistentVector.java:333)
at clojure.core$reduce.invoke(core.clj:6518)
at cljs.analyzer$analyze_STAR_.invoke(analyzer.cljc:2537)
at cljs.analyzer$analyze.invoke(analyzer.cljc:2552)
at cljs.compiler$compile_file_STAR_$fn__2958.invoke(compiler.cljc:1120)
at cljs.compiler$with_core_cljs.invoke(compiler.cljc:1048)
at cljs.compiler$compile_file_STAR_.invoke(compiler.cljc:1071)
at cljs.compiler$compile_file$fn__2999.invoke(compiler.cljc:1232)
... 45 more
Caused by: java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Symbol
at clojure.lang.RT.seqFrom(RT.java:528)
at clojure.lang.RT.seq(RT.java:509)
at clojure.core$seq__4128.invoke(core.clj:137)
at clojure.core.protocols$seq_reduce.invoke(protocols.clj:30)
at clojure.core.protocols$fn__6500.invoke(protocols.clj:84)
at clojure.core.protocols$fn_6452$G6447_6465.invoke(protocols.clj:13)
at clojure.core$reduce.invoke(core.clj:6519)
at cljs.analyzer$parse_type.invoke(analyzer.cljc:1943)
at cljs.analyzer$eval1766$fn__1767.invoke(analyzer.cljc:1972)
at clojure.lang.MultiFn.invoke(MultiFn.java:251)
at cljs.analyzer$analyze_seq_STAR_.invoke(analyzer.cljc:2359)
at cljs.analyzer$analyze_seq_STAR__wrap.invoke(analyzer.cljc:2364)
... 128 more
Subprocess failed



 Comments   
Comment by David Nolen [ 30/Jul/15 7:33 AM ]

already fixed in master.





Generated at Tue Aug 04 21:32:59 CDT 2015 using JIRA 4.4#649-r158309.