<< Back to previous view

[CLJS-1085] Allow to pass test environment to cljs.test/run-all-tests Created: 06/Mar/15  Updated: 06/Mar/15

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

Type: Enhancement Priority: Minor
Reporter: Kimmo Koskinen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Now run-all-tests internally uses run-all-tests. Allowing to pass a custom env (like with run-tests, would allow to use a custom reporter and still be able to select which tests to run with a regex.






[CLJS-1084] once a REPL require is borked cannot recover Created: 05/Mar/15  Updated: 05/Mar/15  Resolved: 05/Mar/15

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

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


 Description   

Once a (require ...) has failed cannot recover, we should restore the old namespace if this occurs if possible.



 Comments   
Comment by David Nolen [ 05/Mar/15 7:01 PM ]

Can't duplicate this outside of the JS reserved keyword namespace segment issue





[CLJS-1082] analysis memoization bug Created: 05/Mar/15  Updated: 05/Mar/15  Resolved: 05/Mar/15

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

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


 Description   

cljs.compiler/compile-file removes ns entries from :cljs.analyzer/namespaces in the compilation environment but cljs.analyzer/analyze-file uses :cljs.analyzer/analyzed-cljs as memoization hook. This means namespace analysis will get dropped and never restored.



 Comments   
Comment by David Nolen [ 05/Mar/15 6:43 PM ]

fixed https://github.com/clojure/clojurescript/commit/746bbb1fdbee4d96cf7c88a083f34532c4edfa45





[CLJS-1083] cljs.closure/source-for-namespace does not do proper namespace munging Created: 05/Mar/15  Updated: 05/Mar/15  Resolved: 05/Mar/15

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

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


 Description   

(require 'foo.bar.function) will not munge function to {{function$}



 Comments   
Comment by David Nolen [ 05/Mar/15 6:40 PM ]

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





[CLJS-937] local fn name should be lexically munged Created: 30/Dec/14  Updated: 05/Mar/15

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

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


 Description   
(ns foo.bar)

(fn console []
  ...)

The local name should be foo$bar$$console.



 Comments   
Comment by David Nolen [ 30/Dec/14 3:12 PM ]

See CLJS-833

Comment by David Nolen [ 03/Mar/15 9:13 AM ]
(ns foo.bar)

(defn console []
  (fn log []
    ...))

The name of the inner fn should be foo$bar$$console$log.

This has an added benefit for older JavaScript runtimes like Rhino. Rhino will not associate vars with anonymous functions. Today we supply a name but wrongly by leaking a bare name to the global scope. By always scoping the function to its lexical environment we avoid arbitrary top level pollution in addition to namespace recoverability in Rhino by splitting on $$ when parsing stacktraces into canonical form.

Comment by David Nolen [ 03/Mar/15 6:53 PM ]

This also benefits WebKit debugging.





[CLJS-897] AOT core.cljs Created: 02/Dec/14  Updated: 05/Mar/15  Resolved: 04/Mar/15

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

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


 Comments   
Comment by David Nolen [ 08/Dec/14 4:22 PM ]

As pointed out by Colin Fleming it will be important to cache both optimized and unoptimized ClojureScript source - specifically the static-fns build option toggled.

Comment by David Nolen [ 04/Mar/15 11:44 PM ]

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

Comment by David Nolen [ 04/Mar/15 11:45 PM ]

:static-fns is always the default for core now. This optimization is about speeding up dev builds. Production builds will need further consideration.

Comment by Thomas Heller [ 05/Mar/15 3:58 AM ]

I guess I'm too late to comment on this but I think special case AOT compilation/caching of cljs/core.cljs is bad. We should rather provide a solid caching implementation that can generate this itself rather than shipping it with each release. Yes, the first "boot" will be slower since it has to generate the cache but each start after will have an up-to-date cache for not only core.cljs but also every other file. That will mean the startup performance will be much better for everything instead of just this one single special case.

We can easily tweak things like :static-fns by setting it to true for every file from a .jar for example.

I think it would be better to bring :cache-analysis to a point where it can default to true instead of special case code for cljs/core.cljs.

Don't quite see the win in this, just looks like technical debt to me.

PS: Sorry I keep commenting on closed issues, you are moving to fast for me these days David.

Comment by David Nolen [ 05/Mar/15 7:43 AM ]

The strategy of this ticket is precisely the same as the one taken by Clojure, the end result is not small for day to day coding, particularly for REPLs and the fact that many sophisticated ClojureScript programs do not reach the >9000 lines of cljs.core.

As far as smarter caching for 3rd party libraries in JARs - see CLJS-1067.

Yes :cache-analysis true will one day become default, not there yet.





[CLJS-899] AOT cache core.cljs analysis Created: 02/Dec/14  Updated: 04/Mar/15  Resolved: 04/Mar/15

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

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


 Comments   
Comment by David Nolen [ 04/Mar/15 11:45 PM ]

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





[CLJS-1081] Add script to create uberjar Created: 04/Mar/15  Updated: 04/Mar/15  Resolved: 04/Mar/15

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

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


 Comments   
Comment by David Nolen [ 04/Mar/15 6:20 PM ]

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





[CLJS-1078] Nashorn REPL should use persistent code cache Created: 04/Mar/15  Updated: 04/Mar/15  Resolved: 04/Mar/15

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

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


 Description   

See https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using



 Comments   
Comment by David Nolen [ 04/Mar/15 6:14 PM ]

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





[CLJS-978] Analysis caching doesn't account for constants table Created: 15/Jan/15  Updated: 04/Mar/15  Resolved: 04/Mar/15

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

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


 Description   

This means advanced optimizations cannot leverage analysis caching.



 Comments   
Comment by Thomas Heller [ 16/Jan/15 4:48 AM ]

Currently the constants use a generated id, we could instead use the constant itself as the key.

:test/keyword creates cljs.core.constant$keyword$123 where 123 is the sequential id which makes it unusable between compiles. We could instead turn it into cljs.core.constant$keyword$_COLON_test_SLASH_keyword (to reuse current munge). We would then just need to keep track of which namespace uses which constant and emit this as well in the analysis cache.

Might be missing something, will investigate a bit later.

Comment by David Nolen [ 16/Jan/15 5:59 AM ]

The constants table needs to work for all compile time constants - vectors, sets, maps, etc.

Comment by David Nolen [ 04/Mar/15 7:53 AM ]

CLJS-897 CLJS-899 depend on this one

Comment by David Nolen [ 04/Mar/15 8:58 AM ]

fixed https://github.com/clojure/clojurescript/commit/592d28a7e6daf4e9fa9ce8b46661aea9d455c410

Comment by Thomas Heller [ 04/Mar/15 1:55 PM ]

@David: I'm not sure what your plan is with AOT cljs core but I think your fix has some issues. The constants id is sequential and when restoring from cache the constants just go through the normal path of register-constant!. When the dependency order is changed (eg. namespace added/removed or even just removing one constant from a dependency) the sequence might be in a different state when restoring which will cause different ids than used in the cached file. I might be wrong though, should probably verify first.

Comment by David Nolen [ 04/Mar/15 2:18 PM ]

The ids don't matter for anything but advanced builds, they don't need to be persisted at all.

Comment by David Nolen [ 04/Mar/15 2:34 PM ]

Thomas actually upon further consideration I do see your point. But it's hard for me to see an obvious case that wouldn't work now that :recompile-dependents is the default and core is always analyzed first. A minimal failing case would be helpful if you can come up with one. If you can a separate ticket would be great.

Comment by David Nolen [ 04/Mar/15 2:46 PM ]

Hrm ok I see the issue for cached files for advanced builds. But it seems switching from sets to vectors for :cljs.analyzer/constants and the fact that core is analyzed first + :recompile-dependents covers any potential problems?

Comment by Thomas Heller [ 04/Mar/15 6:10 PM ]

I wonder if we could

  • keep a {the-constant some-uuid-key} map for each namespace
  • emit the-constant in the namespace output IF used the first time (checks dependencies when compiling)
  • if the-constant is found in a namespace higher up refer to its id
(ns my-base-ns)

(def x :const)

(ns other-ns (:require my-base-ns))

(def y :const)

turns into

// my_base_ns.js
goog.provide("my_base_ns");
cljs.constants$keyword$aaaa-bbbb-cccc-dddd = cljs.core.keyword("const");
my_base_ns.x = cljs.constants$keyword$aaaa-bbbb-cccc-dddd;

// other_ns.js
goog.provide("other_ns")
other_ns.y = cljs.constants$keyword$aaaa-bbbb-cccc-dddd;

should work for other constants as well.

Not sure if that made sense, way too tired. Will think about it tommorrow.





[CLJS-1057] Nashorn REPL should not use EDN rep for errors Created: 22/Feb/15  Updated: 04/Mar/15

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

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


 Description   

Nashorn REPL should just convert the JVM stacktrace into a string form that mirrors JavaScript stack property and implement IParseStacktrace. This seems like pointless work but it simplifies cljs.repl/pst which needs to grab the error value out of Nashorn runtime anyway. The current strategy will not work work cljs.repl/pst.






[CLJS-1080] Analysis cache should keep constants in visit order Created: 04/Mar/15  Updated: 04/Mar/15  Resolved: 04/Mar/15

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

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


 Description   

Track seen in a set but keep the constants visit order via vector.



 Comments   
Comment by David Nolen [ 04/Mar/15 5:30 PM ]

fixed https://github.com/clojure/clojurescript/commit/547d03217046ad4341276bded320fe64c480bed0





[CLJS-1079] add way to execute arbitrary fn upon watch build completion Created: 04/Mar/15  Updated: 04/Mar/15  Resolved: 04/Mar/15

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

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


 Description   

Something which only runs on successful builds



 Comments   
Comment by David Nolen [ 04/Mar/15 5:12 PM ]

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





[CLJS-1056] declaring an already-defined var clobbers its metadata Created: 22/Feb/15  Updated: 04/Mar/15  Resolved: 03/Mar/15

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

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


 Description   

For example, in om.core, path is defined at https://github.com/omcljs/om/blob/master/src/om/core.cljs#L106 and then declared later in the file at https://github.com/omcljs/om/blob/master/src/om/core.cljs#L152. Examining its meta at the REPL using

(meta #'om.core/path)

yields:

{:arglists (),
 :test nil,
 :name path,
 :column 1,
 :line 152,
 :file "resources/public/js/out/om/core.cljs",
 :doc nil,
 :ns om.core}

Note that {:arglists} is empty and {:line} points to the line of the declare.

Examining the compiler env using e.g.

(get-in @cljs.env/*compiler* [:cljs.analyzer/namespaces 'om.core :defs 'path])

yields:

{:file "file:/Users/griffithsm/.m2/repository/om/om/0.6.2/om-0.6.2.jar!/om/core.cljs",
 :line 113,
 :column 1,
 :end-line 113,
 :end-column 23,
 :declared true,
 :test true,
 :name om.core/path}


 Comments   
Comment by David Nolen [ 03/Mar/15 5:21 PM ]

The behavior is the same as Clojure. This bug should be filed with the library.

Comment by Michael Griffiths [ 04/Mar/15 5:01 AM ]

Will do, thanks for looking into it!

Comment by Nicola Mometto [ 04/Mar/15 5:47 AM ]

David, I'm not sure that it is true that this is the same behaviour as Clojure.
In clojure not only

(declare foo)
(defn foo [a])
(:arglists (meta #'foo))

returns ([a]) but every `def` replaces the current var metadata with the new meta.

user=> (def ^:foo foo)
#'user/foo
user=> (meta #'foo)
{:ns #<Namespace user>, :name foo, :file "NO_SOURCE_PATH", :column 1, :line 6, :foo true}
user=> (def ^:bar foo)
#'user/foo
user=> (meta #'foo)
{:bar true, :ns #<Namespace user>, :name foo, :file "NO_SOURCE_PATH", :column 1, :line 9}
Comment by David Nolen [ 04/Mar/15 6:16 AM ]

Nicola none of those cases are what this ticket is about. The ticket is about (declare foo) after defn foo [] ...). There may be other issues but it's not this one.

Comment by Nicola Mometto [ 04/Mar/15 6:33 AM ]

Ah, sorry, I got the declare/defn order wrong reading the ticket description.





[CLJS-1034] Support REPL-defined functions in stacktrace infrastructure Created: 12/Feb/15  Updated: 03/Mar/15  Resolved: 03/Mar/15

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

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


 Description   

Some new machinery has recently been added to ClojureScript facilitating dealing with exception stack traces and their source-mapping with the REPL-author-facing documentation here.

As an enhancement, support REPL-defined functions which have namespaces / functions, but no source to refer to. Clojure REPLs accomplish this via NO_SOURCE_FILE; this enhancement ticket asks for the same in ClojureScript.

To accomplish this probably involves expanding the definition of the canonical stactrace format (allowing :file key to me missing or with a nil value, or some such, along with similar ideas for :line and :column), along with some special conditional handling in the underlying source-mapping machinery to conditionally handle REPL-defined functions as a special case.



 Comments   
Comment by Mike Fikes [ 12/Feb/15 8:19 PM ]

A motivating example for this enhancement is detailed in a ticket for the Ambly REPL.

Comment by David Nolen [ 03/Mar/15 6:29 PM ]

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

Comment by Mike Fikes [ 03/Mar/15 6:58 PM ]

Confirmed fixed.

The only issue I could see in testing is that REPL-defined functions appear as munged, but David points out that can be covered with CLJS-937.





[CLJS-1065] Fix inconsistencies in Quick Start Guide Created: 24/Feb/15  Updated: 03/Mar/15

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

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


 Description   

Good feedback from Micah Martin:

  • Compiler in REPL seems broken: https://gist.github.com/slagyr/7d52ba4ba98e96172456
  • Not interested in Node.js so I skipped all that
  • Development Mode: Okay... this is where I'm confused.
  • The wiki says include 'hello.js'.
  • hello-dev.html explicitely includes goog.base.js.
  • hello-dev.html also requires hello.core.
  • The generated hello.js loads goog.base if it isn't already.
  • out/cljs_deps.js looks like cljsbuild's :output-to file
  • cljbuild doesn't generate anything like sample/hello.js
  • maybe I'll learn about all these difference later in the guide
  • It seems that "Development Mode" requires a modest but significant change in the way the js is included in the page. This is not obvious in the guide. It would be nice if no change was needed.
  • At the end of the Quick Start page... where do I go from here? Would be nice if there was a recomendation.
  • The 'lein cljsbuild' page doesn't address the confusion mentioned above
  • "Source maps" mentions :source-map-path... Am I supposed to add this to [:cljsbuild :builds :name :compiler]? Doesn't seem to do anything.

In the end, I have better picture of the ClojureScript landscape. I see where my assumptions failed me, and huzzah, got source maps working.



 Comments   
Comment by David Nolen [ 26/Feb/15 8:55 AM ]

The Rhino REPL issue has been addressed in master.

Comment by David Nolen [ 03/Mar/15 6:35 PM ]

Master is now setup to build an AOTed uberjar. We should attach this to releases moving forward. Then Quick Start can written in the style of Clojure, just run Java against a single JAR. This in fact considerably cooler than what Google Closure Compiler can offer, we ship with a scripting language which means a command line centric interface can be avoided for the time being and AOT means we can start fast.





[CLJS-964] Redefining exists? does not emit a warning like redefining array? does. Created: 06/Jan/15  Updated: 03/Mar/15

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

Type: Defect Priority: Major
Reporter: Uday Verma Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

[org.clojure/clojurescript "0.0-2665"]



 Description   

ClojureScript:cljs.user> (def array? 2)
WARNING: array? already refers to: /array? being replaced by: cljs.user/array? at line 1 <cljs repl>
2
ClojureScript:cljs.user> (def exists? 2)
2
ClojureScript:cljs.user>



 Comments   
Comment by Mike Fikes [ 06/Jan/15 11:41 PM ]

Additionally, if you define exists? as as a function in your namespace, as in

(defn exists? [] 1)

You need to call it indirectly via its var:

ClojureScript:cljs.user> (@#'exists?)
1

If you instead call it directly, you will get this (this is in the Node.js REPL; similar occurs in JavaScriptCore environment):

ClojureScript:cljs.user> (exists?)
clojure.lang.ExceptionInfo: Wrong number of args (2) passed to: core/exists? at line 1 <cljs repl> {:tag :cljs/analysis-error, :file "<cljs repl>", :line 1, :column 1}
	at clojure.core$ex_info.invoke(core.clj:4403)
	at cljs.analyzer$error.invoke(analyzer.clj:297)
	at cljs.analyzer$macroexpand_1.invoke(analyzer.clj:1562)
	at cljs.analyzer$analyze_seq.invoke(analyzer.clj:1605)
	at cljs.analyzer$analyze$fn__1673.invoke(analyzer.clj:1696)
	at cljs.analyzer$analyze.invoke(analyzer.clj:1689)
	at cljs.analyzer$analyze.invoke(analyzer.clj:1684)
	at cljs.repl$evaluate_form.invoke(repl.clj:100)
	at cljs.repl$evaluate_form.invoke(repl.clj:96)
	at cljs.repl$eval_and_print.invoke(repl.clj:188)
	at cljs.repl$repl_STAR_.invoke(repl.clj:322)
	at user$eval3528.invoke(NO_SOURCE_FILE:3)
	at clojure.lang.Compiler.eval(Compiler.java:6703)
	at clojure.lang.Compiler.eval(Compiler.java:6666)
	at clojure.core$eval.invoke(core.clj:2927)
	at clojure.main$eval_opt.invoke(main.clj:288)
	at clojure.main$initialize.invoke(main.clj:307)
	at clojure.main$null_opt.invoke(main.clj:342)
	at clojure.main$main.doInvoke(main.clj:420)
	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.ArityException: Wrong number of args (2) passed to: core/exists?
	at clojure.lang.AFn.throwArity(AFn.java:429)
	at clojure.lang.AFn.invoke(AFn.java:36)
	at clojure.lang.AFn.applyToHelper(AFn.java:156)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.lang.AFunction$1.doInvoke(AFunction.java:29)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.core$apply.invoke(core.clj:628)
	at cljs.analyzer$macroexpand_1.invoke(analyzer.clj:1568)
	... 21 more

None of this occurs for the other predicates defined near exists? in cljs.core, like array?, true?, etc.

Comment by Thomas Heller [ 07/Jan/15 4:58 AM ]

I suspect that is due to exists? only being a macro with no function in cljs.core. array? and other predicates exist as an inlining macro and a function.

(defn ^boolean array? [x]
  (cljs.core/array? x))

Should just be a matter of creating a similar function for exists?.

Comment by Thomas Heller [ 07/Jan/15 5:00 AM ]

Oops no. Won't be that simple.

;; TODO: x must be a symbol, not an arbitrary expression
(defmacro exists? [x]
  (bool-expr
    (core/list 'js* "typeof ~{} !== 'undefined'"
      (vary-meta x assoc :cljs.analyzer/no-resolve true))))




[CLJS-1049] Include macro information in var resolution functions Created: 20/Feb/15  Updated: 03/Mar/15

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

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


 Description   

The fundamental issue around CLJS-964. Macro information doesn't appear in any of the analysis helpers.



 Comments   
Comment by David Nolen [ 22/Feb/15 12:48 PM ]

This is an important problem. Because this information is missing macros are not of part of the various reflection helpers that are now a big part of ClojureScript REPLs.





[CLJS-112] clojure.data.json -- Read and write JSON strings to/from clojure data structures Created: 16/Dec/11  Updated: 03/Mar/15  Due: 31/Dec/11  Resolved: 03/Mar/15

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

Type: Enhancement Priority: Minor
Reporter: Bobby Calderwood Assignee: Bobby Calderwood
Resolution: Declined Votes: 2
Labels: None

Attachments: Text File 0001-Added-clojure.data.json.patch    
Patch: Code

 Description   

Reading and writing JSON is a common requirement in both server- and client-side applications. ClojureScript needs a way to transform ClojureScript data into JSON, and vice-versa.



 Comments   
Comment by David Nolen [ 03/Mar/15 12:19 PM ]

transit is the answer to this one





[CLJS-37] A way to create js objects and arrays from cljs maps and vectors, without copying if possible. Created: 26/Jul/11  Updated: 03/Mar/15  Resolved: 03/Mar/15

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

Type: Enhancement Priority: Minor
Reporter: Chouser Assignee: Unassigned
Resolution: Declined Votes: 4
Labels: None

Attachments: Text File 0001-Add-as-js.-CLJS-37.patch    
Patch: Code and Test

 Description   

There's currently no convenient way to create a js object from a map. Arrays can be created using the `array` function, but this always creates a copy. In cases where you know the object or array will not be modified, it would be a shame to still pay for a copy of the object. This is especially true when the cljs map or vector is a literal such that nothing else can have a reference to it anyway.



 Comments   
Comment by Chouser [ 26/Jul/11 11:07 PM ]

My plan is a macro `as-js` that takes a single expression. If it's a literal vector or map, it will expand to a js* form that will emit the appropriate array or object literal. In the case of a map, all the keys must be constants (string, keyword, or symbol) in order to for this to work since literal object keys in javascript aren't evaluated. Keyword and symbol keys would be converted to strings.

If the argument to the `as-js` macro isn't a literal (or is a map with non-constant keys), the macro will expand to a call to an `-as-js` protocol fn. When called on a vector, the vector will return its internal array. When called on an ObjMap whose keys are all s convtrings, its internal strobj will be returned. If any of the ObjMap's keys are not strings, then no appropriate js obj exists and a new one will be created, converting keys to strings just like the macro above. HashMaps never contain an appropriate js object, so a new one would be created, again converting keys to strings.

So in the common case of maps whose keys are known at compile time, such as (as-js {:foo "bar" :baz (str "qu" "ux")}), this would at compile time become the js obj literal {"foo": "bar", "baz" cljs.core.str("qu", "ux")}. When the map or vector is not a literal, the least possible copying is done to produce the correct obj or array at runtime.

...why do I have this annoying feeling that I may have done something too compound here?

Comment by David Nolen [ 28/Oct/11 6:58 PM ]

Some work towards a solution: https://github.com/clojure/clojurescript/compare/37-support-for-js-literals

Comment by Chouser [ 28/Oct/11 8:53 PM ]

The macro-based solution I outlined above is unacceptable.

The key issue is that Rich wants the reader to actually create the target type (js array or object) at read time, so special reader syntax is required. I think the syntax was to be #js[1 2 3] for arrays and #js{k v k v} for objects. Then of course there needs to be support in the compiler to generate code that evaluates the array elements and the object values (but not their keys, since the js literal produced can't have expressions for keys).

Comment by Aaron Brooks [ 29/Oct/11 12:28 PM ]

Does a special reader syntax ask for something readable across other platforms? i.e. #native[]/#native{}

It seems that this would enhance the ability of ClojureScript libraries to be reusable across other platforms. It's easier to get around macro/function differences between platforms, however reader syntax differences would cut off the options for sharing source files between Clojure platforms.

Comment by Nicolas Buduroi [ 11/Apr/12 12:30 AM ]

Any update on this issue?

Comment by David Nolen [ 11/Apr/12 2:41 PM ]

Waiting on whether Clojure becomes a JSON superset.

Comment by David Nolen [ 03/Mar/15 12:18 PM ]

Not going to do this.





[CLJS-865] js-dependency-index won't work when running from an uberjar Created: 26/Sep/14  Updated: 03/Mar/15  Resolved: 03/Mar/15

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

Type: Defect Priority: Major
Reporter: Dan Johansson Assignee: Unassigned
Resolution: Completed Votes: 2
Labels: None
Environment:

Window7
[org.clojure/clojure "1.6.0"]
[org.clojure/clojurescript "0.0-2322"]
java 1.7



 Description   

I'm having problems running an uberjar with [lein-light-nrepl "0.0.18"].
I've tracked the problem down to the filter in cljs.js-deps/goog-resource.
It expects to find goog/deps.js in the google jar file but it is in the uberjar file.



 Comments   
Comment by Dan Johansson [ 29/Sep/14 2:27 AM ]

I use this workaround for now:

(defn load-nrepl []
  (require 'cljs.js-deps)
  
  (alter-var-root (find-var 'cljs.js-deps/goog-resource)
                  (fn [of]
                    (fn [path]
                      (first
                       (enumeration-seq (.getResources (.getContextClassLoader (Thread/currentThread)) path))))))
  
  (require 'lighttable.nrepl.handler))

It just removes the filter.
I guess the filter is there to make sure you get the correct goog/deps.js file? I don't know what assumptions to make about build environments to suggest a generic solution.

Comment by Dan Johansson [ 29/Sep/14 2:28 AM ]

This is the error I get:

Caused by: java.lang.IllegalArgumentException: No implementation of method: :make-reader of protocol: #'clojure.java.io/IOFactory found for class: nil
	at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:544)
	at clojure.java.io$fn__8628$G__8610__8635.invoke(io.clj:69)
	at clojure.java.io$reader.doInvoke(io.clj:102)
	at clojure.lang.RestFn.invoke(RestFn.java:410)
	at cljs.js_deps$goog_dependencies_STAR_.invoke(js_deps.clj:241)
	at clojure.lang.AFn.applyToHelper(AFn.java:152)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at clojure.core$apply.invoke(core.clj:624)
	at clojure.core$memoize$fn__5097.doInvoke(core.clj:5846)
	at clojure.lang.RestFn.invoke(RestFn.java:397)
	at cljs.js_deps$js_dependency_index.invoke(js_deps.clj:265)
	at cljs.env$default_compiler_env.invoke(env.clj:45)
	at cljs.env$default_compiler_env.invoke(env.clj:42)
	at lighttable.nrepl.cljs__init.load(Unknown Source)
	at lighttable.nrepl.cljs__init.<clinit>(Unknown Source)
	... 52 more
Comment by James Cash [ 29/Sep/14 3:58 PM ]

I was able to work around this same issue by explicitly including the google-closure-library jar in the classpath (i.e. instead of `java -jar my-uber.jar`, `java -cp google-closure-library-$VERSION.jar:my-uber.jar my-uber.core`)

Comment by Taha Siddiqi [ 08/Oct/14 10:19 PM ]

This is what worked for me.

(defn goog-resource [original-fn path]
  (if-let [resource (io/resource path)]
    resource
    (original-fn path)))

(alter-var-root #'cljs.js-deps/goog-resource (fn [f] (partial goog-resource f)))
Comment by David Nolen [ 09/Oct/14 3:35 PM ]

I'd be happy to remove the hack for Google Closure if someone can demonstrate it's no longer needed. If I recall we now remove the empty files from the thirdy party JAR so this shouldn't be a problem anymore.

Comment by Joseph Moore [ 03/Dec/14 11:43 PM ]

Adding the google-closure library jar to my war file in immutant (from lein immutant war) fixed lighttable's nrepl under wildfly as well, thank you James

Comment by David Nolen [ 03/Mar/15 12:05 PM ]

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





[CLJS-1077] analyze-deps infinite recursive loop Created: 02/Mar/15  Updated: 03/Mar/15  Resolved: 03/Mar/15

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

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

Attachments: Text File CLJS-1077.patch    

 Description   

The first arity of analyze-deps unconditionally invokes itself:

https://github.com/clojure/clojurescript/blob/r2913/src/clj/cljs/analyzer.clj#L1102



 Comments   
Comment by David Nolen [ 03/Mar/15 9:23 AM ]

fixed https://github.com/clojure/clojurescript/commit/42a263f7b9ee780417119d8b63f8fed5f892ffda





[CLJS-1076] :nashorn target Created: 02/Mar/15  Updated: 02/Mar/15

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

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

To run well on Nashorn the target should supply CLOSURE_IMPORT_SCRIPT as well as setTimeout or setImmediate for core.async.






[CLJS-1073] :dynamic is misspelled as :dyanmic for *target* in core.cljs Created: 02/Mar/15  Updated: 02/Mar/15  Resolved: 02/Mar/15

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

Type: Defect Priority: Trivial
Reporter: Matthew Davidson Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: cljs, dynamic, target
Environment:

N/A



 Description   

At the top of core.cljs, line 20:

(def ^{:dyanmic true
:jsdoc ["@define {string}"]}
target "default")

I'm not sure there are any consequences so far, since a search doesn't show target being rebound anywhere.



 Comments   
Comment by David Nolen [ 02/Mar/15 2:37 PM ]

thanks https://github.com/clojure/clojurescript/commit/8785fa9c9ff38c0fcebc32757c077070397018b7





[CLJS-1075] Generic inline source map support Created: 02/Mar/15  Updated: 02/Mar/15

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

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


 Description   

Currently hard coded to REPLs. Would simplify jsbin and similar integration.






[CLJS-1074] Externs inference Created: 02/Mar/15  Updated: 02/Mar/15

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

Type: Enhancement Priority: Minor
Reporter: David Nolen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Given all externs generally need to be supplied for js/foo we could probably automatically compute externs based on js/foo usage in user code. For this to work correctly we need to account for property access through js/foo i.e. (def Bar js/foo.Bar). This should infer that Bar is also a foreign object. Things gets more complicated for higher order cases, we probably want to support a ^js type hint.

Finally externs inference needs to account for externs likely already supplied by the user - i.e. don't emit dupes, Google Closure will complain.






[CLJS-1072] Calling .hasOwnProperty("source") in Clojurescript's string/replace will break with ES6 Created: 01/Mar/15  Updated: 02/Mar/15  Resolved: 02/Mar/15

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

Type: Defect Priority: Major
Reporter: Matthew Davidson Assignee: Unassigned
Resolution: Completed Votes: 1
Labels: bug, cljs, es6, replace, string
Environment:

Firefox Developer Edition
Mac OS X 10.10.1
Clojurescript 0.0-2913 (but I checked, and it's still present in current master branch)



 Description   

The "replace" function in string.cljs identifies RegExp objects by calling .hasOwnProperty to check for the "source" property. If true, then it's a regex. However, in ES6, the "source" property will become part of the RegExp prototype and not the actual object, so .hasOwnProperty("source") will return false instead.

Documentation on the RegExp change is at http://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/source under the "Specifications" section. The change hit Firefox two weeks ago, according to this bug report, https://bugzilla.mozilla.org/show_bug.cgi?id=1120169, so it will still be 2-3 months before it appears in the main release channel. But given that ES6 is aiming for a June release date, we should expect other browsers to show this error soon enough.

To fix the issue, the Javascript "in" operator would work, if there's a way to compile cljs to use it. Otherwise, the next best thing might be to check to see if the "source" property is non-nil. Basically, the test:

(.hasOwnProperty match "source")

could become:

(.-source match)

It's not a major code change at all, but I'm happy to provide a patch and verify tests if you prefer.



 Comments   
Comment by Elliot Block [ 02/Mar/15 12:54 AM ]

Just to slightly summarize/reiterate, this bug means that `string/replace` is always broken if you pass it a RegExp as the `match` (under the new ES6 rules, already live in FF Dev Ed.)

This further breaks plenty of applications, like it immediately breaks the `secretary` router found in many Om apps.

Comment by David Nolen [ 02/Mar/15 7:46 AM ]

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





[CLJS-1064] ex-info is not printable Created: 24/Feb/15  Updated: 01/Mar/15  Resolved: 01/Mar/15

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

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


 Description   
(str (ex-info "foo" {}))

Fails under master.



 Comments   
Comment by David Nolen [ 01/Mar/15 12:26 PM ]

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





[CLJS-1071] Convert symbol keys in :closure-defines to munged strings Created: 01/Mar/15  Updated: 01/Mar/15  Resolved: 01/Mar/15

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

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


 Comments   
Comment by David Nolen [ 01/Mar/15 9:54 AM ]

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





[CLJS-1014] Support Closure Defines under :none Created: 06/Feb/15  Updated: 01/Mar/15  Resolved: 01/Mar/15

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

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


 Description   

Because Google Closure never runs under :none Closure Defines do not work.



 Comments   
Comment by David Nolen [ 06/Feb/15 9:51 AM ]

This is easy to make work with :main. Can probably be made to work without as well?

Comment by David Nolen [ 01/Mar/15 9:24 AM ]

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





[CLJS-1070] top-level boolean inference does not work Created: 28/Feb/15  Updated: 28/Feb/15

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

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


 Description   

Problem for using boolean Closure defines






[CLJS-1068] CLJS_NODE_TARGET define Created: 27/Feb/15  Updated: 28/Feb/15  Resolved: 28/Feb/15

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

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


 Description   

While we have our own means of tracking in the analyzer/compiler this it would be nice to expose a user-land closure define so that users can customize their own code bases now that this is out of scope for conditional reading.



 Comments   
Comment by David Nolen [ 28/Feb/15 12:15 PM ]

fixed https://github.com/clojure/clojurescript/commit/801861cc03d5dc3c783b18a375eec37725e6671b





[CLJS-1069] Generic :jsdoc support Created: 28/Feb/15  Updated: 28/Feb/15  Resolved: 28/Feb/15

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

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


 Description   

Currently :jsdoc support is not generalized for use. This means users cannot easily leverage Google Closure defines.



 Comments   
Comment by David Nolen [ 28/Feb/15 12:14 PM ]

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





[CLJS-1063] Regression for Rhino REPL part of Quick Start tutorial Created: 24/Feb/15  Updated: 28/Feb/15  Resolved: 28/Feb/15

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

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


 Description   

Curiously bin/repljs appears to work. When trying the tutorial we get a bunch of "already declared" errors which seems like a REPL bootstrapping issue.



 Comments   
Comment by David Nolen [ 28/Feb/15 10:24 AM ]

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





[CLJS-1067] Shared AOT cache for dependencies in JARs Created: 26/Feb/15  Updated: 27/Feb/15

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

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


 Description   

3rd party library code in JARs shouldn't be recompiled across dev and prod configurations. There should be a shared AOT cache for all builds within a project for all non-project local source.






Generated at Fri Mar 06 05:04:58 CST 2015 using JIRA 4.4#649-r158309.