<< Back to previous view

[CLJS-2159] simple-benchmark prints #js values in an odd way Created: 03/Jul/17  Updated: 03/Jul/17

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

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


 Description   
cljs.user=> (simple-benchmark [a #js [1]] 1 1)
[a #object[cljs.tagged_literals.JSValue 0x1b7e0717 "cljs.tagged_literals.JSValue@1b7e0717"]], 1, 1 runs, 3 msecs
nil





[CLJS-2114] Add release notes for breaking change in CLJS-1875 Created: 21/Jun/17  Updated: 21/Jun/17

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

Type: Enhancement Priority: Trivial
Reporter: Daniel Compton Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File CLJS-2114.patch    




[CLJS-2043] Remove checks made redundant by CLJS-2040 Created: 20/May/17  Updated: 20/May/17

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

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


 Description   

CLJS-2040 added a check to see if we have analyzer metadata for a given ns. The old checks are still in there but would also be covered by the new check. We should probably remove them.

https://github.com/clojure/clojurescript/commit/77e01a01af9f45c76cfa34aa67bfae154b075544#diff-55b85385d2d0bfb6dc20d59ed982d5c8R953






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

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

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

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


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

 Description   

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

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

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

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

This is because 🖌 is not a valid JavaScript name.

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

Actual result: Invalid JavaScript code is generated:

var 🖌_38518 = (1);

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

var _1F58C__38518 = (1);


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

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


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

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

This allows the code to be used like this:

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

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

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

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

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

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

Comment by Mike Fikes [ 25/Jun/17 4:10 PM ]

Attached patch no longer applies cleanly.





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

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

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


 Description   

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






[CLJS-1958] Macro :arglists include &form and &env Created: 27/Feb/17  Updated: 27/Feb/17

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

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


 Description   

Minor issue, but nice to fix especially because of tooling. In lumo:

cljs.user=> (:arglists (get-in @lumo.repl/st [:cljs.analyzer/namespaces 'cljs.core$macros :defs 'when]))
([&form &env test & body])

I would like to filter out the first two arguments that are of course not needed.
A simple patch is here.

I can provide a patch once I figure out where is the right place to apply it. Of course if I am not doing it wrong.

Thanks!



 Comments   
Comment by Andrea Richiardi [ 27/Feb/17 12:26 PM ]

On second thought, if we put this filter in `load-analysis-cache!`, probably we will pay to much of a price for just a display/ide problem. The best thing I can think of is to filter the transit/json file before loading. So probably this is better to be inside `lumo`.

Comment by Andrea Richiardi [ 27/Feb/17 12:44 PM ]

After conversation with António Nuno Monteiro: this inconsistency might be solved with CLJS-1461 so this one here can be closed I guess.





[CLJS-1898] JSValue should support metadata to fix source maps contents edge case Created: 23/Jan/17  Updated: 24/Jan/17

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

Type: Defect Priority: Trivial
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

Dirac DevTools REPL relies on proper source-maps[1]. When I type "#js {}" into the REPL prompt, evaluation works, but generated javascript code snippet has wrong source map. Associated source-map's sourcesContent is something like #object[cljs.tagged_literals.JSValue 0x34d692f3 "cljs.tagged_literals.JSValue@34d692f3"]. And it is not what user entered. And this is not a valid cljs source I could parse again for code-completions.

The problem is somewhat subtle. When generating source-map info, the REPL code given a form tries to look at :source metadata[2] and if not present, it simply prints the form using pr. We get Clojure-style printing because JSValue does not implement ClojureScript printing as reported in CLJS-733.

Instead of implementing the rejected idea from CLJS-733. I focused on the first-case code path with :source metadata. It turned out that :source gets added if given form supports metadata protocols. Easiest idea was to change JSValue from deftype to defrecord.

I confirm that this fixed the REPL issue in Dirac. Now I'm getting back the original source code as entered by user.

Note that similar issue is present with #uuid and #inst tags as well. Those mostly work because their printer is compatible with both Clojure and ClojureScript. But fundamentally user might get back different source-map source than entered into the REPL. For example whitespace will be missing. This might cause confusion because line/column information reported by reader which might not match this artificial source-map content generated by printing.

I believe a fix would be to wrap UUID and Date forms created by tagged literals into something similar to JSValue and work with this wrapped value instead. Same with #queue. This would make cljs.tagged-literal code consistent, because every form originated from data readers would be inside a wrapper. It would enable arbitrary metadata on wrappers.

As a side note:
I noticed that reader's metadata get lost. They are not transplanted from form produced by the reader to generated tagged literal forms.
My second goal was to copy reader's metadata. Unfortunately this wasn't possible with current implementation of tools.reader. I can get reader metadata from passed form, but that is not the full picture, it only describes content after the tag was already consumed. I would need metadata from tag itself, passed into data-reader call somehow[3].

I don't know about any real-world problem caused by missing reader metadata on tagged literals, but I think ideally it should be fixed. For example when implementing error-reporting in cljs-oops, I had to handle this edge case[4], because line/column metadata was missing in some edge cases.

[1] https://github.com/binaryage/dirac/releases/tag/v0.8.0
[2] https://github.com/clojure/clojurescript/blob/960bb9b778190aa7359acb2f74cc61d452cef2ae/src/main/clojure/cljs/repl.cljc#L476
[3] https://github.com/clojure/tools.reader/blob/3f36a18a6c5d53a4fc718822131ee75625fd44dc/src/main/cljs/cljs/tools/reader.cljs#L834
[4] https://github.com/binaryage/cljs-oops/blob/d530a3cdf8cbab39bd2699c36caded4414224c50/src/lib/oops/reporting.clj#L29



 Comments   
Comment by Antonin Hildebrand [ 23/Jan/17 5:58 PM ]

I just noticed that some tests broke because of the defrecord change. My original implementation was using deftype with clojure.lang.IObj implementation. But it had a shortcoming of reusing val as the target for holding metadata. Which might not be IObj in general case. And also a separate implementation would have to be done for bootstrapped. Also I didn't want to add another field into deftype. I will leave it open for your suggestion how to properly implement this.

Comment by Antonin Hildebrand [ 24/Jan/17 2:28 PM ]

Another stab at it - this time I rely on the fact that val field must be a vector or a map. So it can carry metadata for JSValue without changing adding new fields to deftype.

Tests passing.





[CLJS-1889] A lone ampersand `&` can be used to name a var, but throws when invoked. `(&)` Created: 15/Jan/17  Updated: 20/Nov/17

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

Type: Defect Priority: Trivial
Reporter: Aleksander Madland Stapnes Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None


 Description   

I can use the symbol & to name something, but if I try to invoke it, the following exception is thrown:

Exception in thread "main" clojure.lang.ExceptionInfo: failed compiling file:src/amp/core.cljs {:file #object[java.io.File 0x5e63cad "src/amp/core.cljs"]}, compiling:(/home/madstap/code/ampersand/build.clj:3:1)
	at clojure.lang.Compiler.load(Compiler.java:7391)
	at clojure.lang.Compiler.loadFile(Compiler.java:7317)
	at clojure.main$load_script.invokeStatic(main.clj:275)
	at clojure.main$script_opt.invokeStatic(main.clj:335)
	at clojure.main$script_opt.invoke(main.clj:330)
	at clojure.main$main.invokeStatic(main.clj:421)
	at clojure.main$main.doInvoke(main.clj:384)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.lang.Var.invoke(Var.java:379)
	at clojure.lang.AFn.applyToHelper(AFn.java:154)
	at clojure.lang.Var.applyTo(Var.java:700)
	at clojure.main.main(main.java:37)
Caused by: clojure.lang.ExceptionInfo: failed compiling file:src/amp/core.cljs {:file #object[java.io.File 0x5e63cad "src/amp/core.cljs"]}
	at clojure.core$ex_info.invokeStatic(core.clj:4617)
	at cljs.compiler$compile_file$fn__3147.invoke(compiler.cljc:1406)
	at cljs.compiler$compile_file.invokeStatic(compiler.cljc:1376)
	at cljs.closure$compile_file.invokeStatic(closure.clj:430)
	at cljs.closure$fn__4204.invokeStatic(closure.clj:497)
	at cljs.closure$fn__4204.invoke(closure.clj:493)
	at cljs.closure$fn__4146$G__4139__4153.invoke(closure.clj:389)
	at cljs.closure$compile_sources$iter__4315__4319$fn__4320.invoke(closure.clj:829)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.Cons.next(Cons.java:39)
	at clojure.lang.RT.next(RT.java:688)
	at clojure.core$next__4341.invokeStatic(core.clj:64)
	at clojure.core$dorun.invokeStatic(core.clj:3033)
	at clojure.core$doall.invokeStatic(core.clj:3039)
	at cljs.closure$compile_sources.invokeStatic(closure.clj:826)
	at cljs.closure$build.invokeStatic(closure.clj:1942)
	at cljs.build.api$build.invokeStatic(api.clj:198)
	at cljs.build.api$build.invoke(api.clj:187)
	at cljs.build.api$build.invokeStatic(api.clj:190)
	at cljs.build.api$build.invoke(api.clj:187)
	at user$eval24.invokeStatic(build.clj:3)
	at user$eval24.invoke(build.clj:3)
	at clojure.lang.Compiler.eval(Compiler.java:6927)
	at clojure.lang.Compiler.load(Compiler.java:7379)
	... 11 more
Caused by: clojure.lang.ExceptionInfo: No method in multimethod 'parse' for dispatch value: & at line 5 src/amp/core.cljs {:file "src/amp/core.cljs", :line 5, :column 1, :tag :cljs/analysis-error}
	at clojure.core$ex_info.invokeStatic(core.clj:4617)
	at cljs.analyzer$error.invokeStatic(analyzer.cljc:628)
	at cljs.analyzer$analyze_seq_STAR__wrap.invokeStatic(analyzer.cljc:2871)
	at cljs.analyzer$analyze_seq.invokeStatic(analyzer.cljc:2892)
	at cljs.analyzer$analyze_form.invokeStatic(analyzer.cljc:3011)
	at cljs.analyzer$analyze_STAR_.invokeStatic(analyzer.cljc:3056)
	at cljs.analyzer$analyze.invokeStatic(analyzer.cljc:3073)
	at cljs.compiler$emit_source.invokeStatic(compiler.cljc:1255)
	at cljs.compiler$compile_file_STAR_$fn__3124.invoke(compiler.cljc:1325)
	at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1159)
	at cljs.compiler$compile_file_STAR_.invokeStatic(compiler.cljc:1316)
	at cljs.compiler$compile_file$fn__3147.invoke(compiler.cljc:1396)
	... 34 more
Caused by: java.lang.IllegalArgumentException: No method in multimethod 'parse' for dispatch value: &
	at clojure.lang.MultiFn.getFn(MultiFn.java:156)
	at clojure.lang.MultiFn.invoke(MultiFn.java:251)
	at cljs.analyzer$analyze_seq_STAR_.invokeStatic(analyzer.cljc:2867)
	at cljs.analyzer$analyze_seq_STAR__wrap.invokeStatic(analyzer.cljc:2870)
	... 43 more


 Comments   
Comment by Aleksander Madland Stapnes [ 16/Jan/17 1:59 AM ]

Better explanation as I can't seem to edit the description: https://gist.github.com/madstap/c77581185afa7fea8bbf2556f2d9fafe

Comment by Mike Fikes [ 20/Nov/17 7:45 PM ]

If ClojureScript's symbols follow Clojure's constraints (https://clojure.org/reference/reader#_symbols), then & is not a valid symbol.

Of course,

(type (second (second '(fn [f & r]))))
is cljs.core/Symbol, but perhaps that is an exception to the rule, reserved for use by Clojure.





[CLJS-1771] Add helper for converting ex-info to js/Error Created: 02/Sep/16  Updated: 02/Sep/16

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

Type: Enhancement Priority: Trivial
Reporter: Artem Yarulin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: ex-info


 Description   

ex-info/ex-data/ex-message didn't get a lot of attention in CLJS community, still I find quiet often (js/Error. "Err"). I guess the main reason is that we cannot pass ex-info object back to JS world, clj->js doesn't work in this case. We can solve it by adding helper like ex->js which will convert ex-info backward to js/Error.

What do you think about such enhancement? I can add patch later if you would find it useful






[CLJS-1769] Use reduce pathway for arrays in js->clj Created: 01/Sep/16  Updated: 19/Nov/17

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

Type: Enhancement Priority: Trivial
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None

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

 Description   

Currently js->cljs uses `(vec (map some-fn some-js-array))` on arrays. By using `(mapv some-fn some-js-array)` we take advantage of array-reduce and avoid a lazy-sequence.



 Comments   
Comment by Mike Fikes [ 19/Nov/17 7:48 PM ]

Patch no longer applies; needs re-baseline.





[CLJS-1725] defrecord does not set cljs$lang$ctorStr Created: 04/Aug/16  Updated: 19/Nov/17

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

Type: Defect Priority: Trivial
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

While implementing some demunging code[1] for cljs-devtools, I stumbled upon inconsistency in type->str. It works for deftypes but not for defrecords.

The problem is that defrecord does not set! cljs$lang$ctorStr field for some reason. This has been likely overlooked, because type->str is not used often, just for some rare error exceptions as far I can see.

Anyways, this patch fixes it by copy&pasting it from deftype. A better solution to avoid future problems like this would be to extract shared code between deftypes and defrecords, but that seems to be a lot of work.

The patch also adds some tests. I had to add some utility macros to run those tests only in simple mode, because type->str is not supposed to work under advanced builds.
Also test for CLJS-1722 was added to be uncommented after potentially merging it.

[1] https://github.com/binaryage/cljs-devtools/blob/52899e61e33373df36be8dcb23c69377936821b2/src/lib/devtools/munging.cljs#L56-L60



 Comments   
Comment by Mike Fikes [ 19/Nov/17 7:49 PM ]

Patch no longer applies; needs re-baseline.





[CLJS-1723] pr-writer-ex-info does not print false values and tries to reimplement map printer Created: 04/Aug/16  Updated: 08/Aug/16

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

Type: Defect Priority: Trivial
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

While working on CLJS-1722 I spotted two issues with pr-writer-ex-info:

1) if data or cause happen to be "false", they are skipped in printing
2) the code tries to mimic map printer

This patch fixes both issues. It turns out printing real info map yields exactly same string output and plays better with cljs-devtools printer (which newly sees real map instead of soup of strings and values).

For reference: pr-writer-ex-info was implemented in CLJS-983



 Comments   
Comment by David Nolen [ 08/Aug/16 7:39 AM ]

Can you explain why you think 1 is a problem? data should be a map. cause should be an error but I suppose that could be a problem if you have a rethrow which wraps some throwable value (which of course could be anything).

Comment by Antonin Hildebrand [ 08/Aug/16 2:32 PM ]

Disclaimer: I don't have much experience with Clojure and almost none with Java.

Just by reading the code I didn't see any checks in ex-info (or in ExceptionInfo ctor) to restrict data or cause. So I assumed anything can be passed in and printer should print it as-is without additional logic. I assumed that checking for nil values was intentional abbreviation when CLJS-983 was implemented. And I assumed that false value was supposed to be printed. At least I personally would want it to be distinguished from nil. Or there should be no abbreviation at all.





[CLJS-1676] Unused local in ObjMap / IKVReduce Created: 09/Jun/16  Updated: 24/Nov/17

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

Type: Defect Priority: Trivial
Reporter: Stuart Hinson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

Local len isn't used in ObjMap / IKVReduce

https://github.com/clojure/clojurescript/blob/463de005b81d4a00951188e8b8d38a61d684c18e/src/main/cljs/cljs/core.cljs#L5792



 Comments   
Comment by Stuart Hinson [ 10/Aug/17 2:56 PM ]

BTW, recognize this is a trivial issue, but it's still around

https://github.com/clojure/clojurescript/blob/fe77a1349aba903856cbaa0a0f10e03b6fb30d92/src/main/cljs/cljs/core.cljs#L6150

Comment by Mike Fikes [ 19/Nov/17 7:52 PM ]

Patch no longer applies; needs re-baseline.

Comment by Stuart Hinson [ 24/Nov/17 8:48 AM ]

Thanks for the heads up! Remade the patch





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

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

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

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

 Description   

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

(_ 7 3)
works.

Repro:

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


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

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

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

With a special `ns-interns**` as

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

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

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

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

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

Yep

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

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

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





[CLJS-1549] Printing #object tags should be consistent Created: 22/Jan/16  Updated: 19/Nov/17

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

Type: Enhancement Priority: Trivial
Reporter: Antonin Hildebrand Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File cljs_1549.patch    
Patch: Code

 Description   

[CLJS-1376|http://dev.clojure.org/jira/browse/CLJS-1376) wanted to bring printing parity with Clojure 1.7.0.

There are two problems:
1) Atom and Volatile contain extra space between #object and "[" (that differs from Clojure 1.7.0)
2) Atom and Volatile printing was inconsistent with #object printing in pr-writer-impl (in goog/isFunction and :else branches) - there we have no space

I have introduced a function which handles printing object tags consistently without space. Also I have broken writing content into writer into logical tokens for easier cljs-devtools implementation.

Background info:
Exact printing behaviour is quite important for me when implementing alternative pr-writer-impl for cljs-devtools. For most cases I call original pr-writer-impl and then post-process its output to enhance its presentation in DevTools console:
https://github.com/binaryage/cljs-devtools/blob/2f1c0f4095a364bb11a833e73e5753a4e48add8f/src/devtools/format.cljs#L200-L226

In case of constructors or functions (goog/isFunction and :else branches of pr-writer-impl), I don't want to emit stringified content, but I want to provide real js-object reference and delegate further printing/expansion to native javascript formatter in DevTools.
In other cases like Atom or Volatile, I would like to easily detect "#object" as first token written into writer and provide better visual clues. I find printing "#object [...]" confusing for more complex data situations. Square brackets resemble vectors and may confuse clarity. Instead I will use color-coding or another form of visual styling to mark object instances and their boundaries. But for this I want to have nice token stream "#object" "[" ... "]" without having to use regexps.



 Comments   
Comment by Mike Fikes [ 19/Nov/17 7:58 PM ]

Patch no longer applies.





[CLJS-1450] Arithmetic warning thrown for impossible condition Created: 15/Sep/15  Updated: 30/Mar/16

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

Type: Defect Priority: Trivial
Reporter: Quest Yarbrough Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: bug, compiler


 Description   

The following code triggers an arithmetic warning even though the condition it's warning about is impossible to reach. I tested this code in Clojure and it did not generate a warning. I would guess that the CLJS compiler doesn't take note of the (js/Error) in the same way that the Clojure compiler treats (Error.)

The exact warning triggered is below, followed by the code.

WARNING: cljs.core/+, all arguments must be numbers, got [number clj-nil] instead. at line 22 src\spurious_arithmetic\core.cljs
(def x [0 1 2 3 4 nil])
(def index (atom -1))
(defn take-value []
  (->> (swap! index inc)
       (nth x)))

(-> (loop [result (take-value)
           prev nil]
      (if (= nil result prev) (throw (js/Error. "This condition prevents nil arithmetic.")))
      (if (some? result)
        (recur (take-value) result)
        (+ 1 prev)))                                        ; this triggers the [number cljs-nil] warning
    (print)) ; 5


 Comments   
Comment by Mike Fikes [ 30/Mar/16 11:33 PM ]

The type inference logic in the compiler expects that the type of a loop local is static. In fact, somewhat the opposite of this ticket is being done in CLJS-1561.





[CLJS-1439] Add type annotations to goog-define defined vars Created: 01/Sep/15  Updated: 29/Oct/17

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

Type: Enhancement Priority: Trivial
Reporter: Martin Klepsch Assignee: David Nolen
Resolution: Unresolved Votes: 4
Labels: None

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

 Description   

Currently it's still required to annotate goog-define constants with ^boolean to allow the Closure compiler to safely remove dead branches. The macro could emit the var with ^boolean metadata to make this unnecessary.

In general it would be nice to have similar annotations for the already defined constants like goog.DEBUG although I'm not sure how/if that's possible.



 Comments   
Comment by Thomas Heller [ 28/Oct/17 5:25 PM ]

Added patch sets the proper :tag for the defined symbol for goog-define.

Inferring a type from a JS expression is not that simple and should probably be done in a separate ticket.

Comment by Thomas Heller [ 28/Oct/17 5:30 PM ]

Patch included a change from another ticket, fixed to only include the intended change.





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

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

Type: Enhancement Priority: Trivial
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-1378] JARs that end in .exe are problematic Created: 29/Jul/15  Updated: 30/Jul/15

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

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


 Description   

compile-from-jar cannot handle the later form

{{jar:file:/Users/candera/cognitect/walmart/walsim/deploy/walsim-v0.3.5.jar!/cljs/com/walmart/test/app.cljs}}
{{jar:file:/Users/candera/cognitect/walmart/walsim/deploy/walsim-v0.3.5.exe!/cljs/com/walmart/test/app.cljs}}






[CLJS-1139] Repeated applications of `ns` form at the REPL are not additive Created: 17/Mar/15  Updated: 27/Jun/17

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

Type: Defect Priority: Trivial
Reporter: Michael Griffiths Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Quick start guide with Node REPL



 Description   

In a Clojure REPL, it is possible to declare the same namespace again, without existing namespaces aliases being altered or removed:

user=> (ns my-test-ns.core (:require [clojure.string :as string]))
nil
my-test-ns.core=> (def a string/blank?)
#'my-test-ns.core/a
my-test-ns.core=> (ns my-test-ns.core)
nil
my-test-ns.core=> (def a string/blank?)
#'my-test-ns.core/a
my-test-ns.core=>

ClojureScript REPLs do not behave in the same way:

ClojureScript:cljs.user> (ns my-test-ns.core (:require [clojure.string :as string]))
true
ClojureScript:my-test-ns.core> (def a string/blank?)
#<function clojure$string$blank_QMARK_(s){
return goog.string.isEmptySafe(s);
}>
ClojureScript:my-test-ns.core> (ns my-test-ns.core)
nil
ClojureScript:my-test-ns.core> (def a string/blank?)
WARNING: No such namespace: string, could not locate string.cljs at line 1 <cljs repl>
WARNING: Use of undeclared Var string/blank? at line 1 <cljs repl>
repl:13
throw e__3919__auto__;
      ^
ReferenceError: string is not defined
    at repl:1:109
    at repl:9:3
    at repl:14:4
    at Object.exports.runInThisContext (vm.js:74:17)
    at Domain.<anonymous> ([stdin]:41:34)
    at Domain.run (domain.js:197:16)
    at Socket.<anonymous> ([stdin]:40:25)
    at Socket.emit (events.js:107:17)
    at readableAddChunk (_stream_readable.js:163:16)
    at Socket.Readable.push (_stream_readable.js:126:10)
ClojureScript:my-test-ns.core>





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

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

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

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

 Description   

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

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

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



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

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

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

Comment by Mike Fikes [ 19/Nov/17 8:05 PM ]

Patch no longer applies.





[CLJS-872] Ordered collections printed as if they were unordered at the REPL Created: 13/Oct/14  Updated: 20/Nov/17

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

Type: Defect Priority: Trivial
Reporter: Michał Marczyk Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This is due to cljs.repl's read-then-print processing of string representations of return values that come back from the JS env. As of release 2371, the relevant code fragment lives here:

https://github.com/clojure/clojurescript/blob/r2371/src/clj/cljs/repl.clj#L156

A larger snippet to demonstrate this:

ClojureScript:cljs.user> (array-map 1 2 3 4 5 6 7 8 9 10 11 12 13 14)
{1 2, 3 4, 5 6, 7 8, 9 10, 11 12, 13 14}
ClojureScript:cljs.user> (array-map 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18)
{7 8, 1 2, 15 16, 13 14, 17 18, 3 4, 11 12, 9 10, 5 6}
ClojureScript:cljs.user> (seq (array-map 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18))
([1 2] [3 4] [5 6] [7 8] [9 10] [11 12] [13 14] [15 16] [17 18])
ClojureScript:cljs.user> (hash-map 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18)
{7 8, 1 2, 15 16, 13 14, 17 18, 3 4, 11 12, 9 10, 5 6}

This issue seems to be the most likely cause of the problem described in this StackOverflow question. It would be nice to print ordered collections in the "expected" way to prevent user confusion.



 Comments   
Comment by David Nolen [ 14/Oct/14 5:23 AM ]

How is this handled in Clojure?

Comment by Michał Marczyk [ 14/Oct/14 7:40 AM ]

The built-in REPL simply prints string representations of values to *out* without attempting to read them back in first.

Comment by David Nolen [ 14/Oct/14 7:54 AM ]

Well the result of REPL evaluation is a string unlike Clojure, in order to get a proper print at the ClojureScript REPL it seems necessary to read back the result. I will say it's not clear to me array-map promises anything about order anyway.

Comment by Michał Marczyk [ 14/Oct/14 8:02 AM ]

It does – see http://clojure.org/data_structures, where it says

ArrayMaps
When doing code form manipulation it is often desirable to have a map which maintains key order. An array map is such a map - it is simply implemented as an array of key val key val... As such, it has linear lookup performance, and is only suitable for very small maps. It implements the full map interface. New ArrayMaps can be created with the array-map function. Note that an array map will only maintain sort order when un-'modified'. Subsequent assoc-ing will eventually cause it to 'become' a hash-map.

This snippet has been there for as long as I can remember; and this particular feature comes up in various online discussions from time to time. The docstrings for array-map (the core function) are unambiguous in their promise to construct array maps in both Clojure and ClojureScript.

As for the issue at hand, I do think it's a very minor one (hence the "Trivial" priority), but it is real – the representation printed at the REPL is out of line with the string returned from pr-str on the same value. In fact, one way to fix this would be to use pr-str representations computed on the CLJS side. (There may be some complications here, though, which we'd have to work out.)

Comment by David Nolen [ 14/Oct/14 8:07 AM ]

Thanks for pointing out the API promise. OK, yeah I don't really have a good idea for how do this but a patch that isn't too ugly is welcome

Comment by Mike Fikes [ 20/Nov/17 5:14 PM ]

I think this is no longer reproducible. For example (apply array-map (range 100)) prints in an ordered way. There is also no longer a read-string call in repl.cljc.





[CLJS-844] Optimize js->clj by switching to transients Created: 22/Aug/14  Updated: 19/Nov/17

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

Type: Enhancement Priority: Trivial
Reporter: Darrick Wiebe Assignee: Darrick Wiebe
Resolution: Unresolved Votes: 2
Labels: None

Attachments: Text File js-to-clj-using-transients.patch     Text File use-transducers-in-js-to-clj.patch     Text File use-transducers-in-js-to-clj.patch    
Patch: Code

 Comments   
Comment by David Nolen [ 23/Aug/14 1:19 PM ]

Did you any benchmarks on other JS engines?

Comment by Darrick Wiebe [ 23/Aug/14 2:14 PM ]

No. My main concern was to check if there was any startup overhead that might offset the basic efficiency improvements for processing small collections. Using into with a transducer turned out to be faster in every scenario, significantly in most.

Comment by David Nolen [ 23/Aug/14 2:19 PM ]

It would be nice to see a jsperf of before and after on this ticket. Thanks.

Comment by Darrick Wiebe [ 23/Aug/14 2:23 PM ]

Is there a existing one that I can work from?

Comment by David Nolen [ 23/Aug/14 2:35 PM ]

There is not. I generally just make a simple project, create an advanced compiled artifact and copy and paste it into jsperf.

Comment by Darrick Wiebe [ 24/Aug/14 7:24 PM ]

Turns out reducing into a transient is considerably better than using a transducer (which was itself a little faster) for this.

http://jsperf.com/js-clj-transducer-test

The code is at:

https://gist.github.com/pangloss/591d77231fda460c2fbe

Let me know if you want me to prepare an updated patch.

Comment by David Nolen [ 25/Aug/14 7:34 AM ]

Thanks for putting this together. Yes please provide an updated patch.

Comment by Darrick Wiebe [ 26/Aug/14 11:19 AM ]

Not sure whether the convention is to comment that I've uploaded a new patch. Regardless, I uploaded it yesterday.

Comment by Marcin Kulik [ 07/Oct/15 1:46 PM ]

I have tested and benchmarked the patch on a big js objects (5MB+ json files) and I confirm that new-js->clj3 function is more than 2x faster. It runs now in the player on https://asciinema.org and all seems good so far.

Comment by David Nolen [ 08/Oct/15 2:33 PM ]

Marcin thanks for the feedback. Experience reports always help push tickets forward.

Darrick, the patch need to be rebased to master. Please remove all patches except the one that will be applied.

Comment by Rohit Aggarwal [ 08/Oct/15 3:06 PM ]

[ClojureScript beginner here. so do ignore this if I am mistaken]

The patch of 25/Aug uses `(aget x k)` instead of `(goog.object/get x k)` for getting the value of a key if x is an object. I believe it isn't the right way even though it works.

This contains why the latter is preferred over the former.

Comment by David Nolen [ 09/Oct/15 12:33 PM ]

Rohit good catch. Yes that should be changed.

Comment by Thomas Spellman [ 21/Oct/16 3:01 AM ]

Added a patch, "js-to-clj-using-transients.patch", on Oct 16, 2016 that supersedes "use-transducers-in-js-to-clj.patch" from Aug, 2014. This patch changes cljs.core/js->clj to use transients. Also included is a change to both js->clj and clj->js to use gobject/get and gobject/set instead of aget and aset on JS object.

The JSperf shows a 17% speed improvement in Chrome on the first run, but about equal on the second run: https://jsperf.com/js-clj-transient-perf-test

The code for the JSperf is here: https://gist.github.com/thos37/41c0b38bea3270988a3275332686ab49

What would be the ideal test data for this?

Comment by Mike Fikes [ 19/Nov/17 8:10 PM ]

js-to-clj-using-transients.patch no longer applies.





[CLJS-633] Missing Java type hints in closure.clj Created: 22/Oct/13  Updated: 19/Nov/17

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

Type: Enhancement Priority: Trivial
Reporter: Julien Eluard Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File cljs_ticket_633.patch    
Patch: Code

 Description   

A number of reflection warnings are generated from closure.clj. Fixing those probably would not improved performance but it would be cleaner anyway.



 Comments   
Comment by Julien Eluard [ 22/Oct/13 8:03 AM ]

Attached patch.

There are a couple warnings left, similar to:
Reflection warning, cljs/closure.clj:232:1 - reference to field url can't be resolved.
They appear to be due to some unexpected protocol method name? It looks harmless.

Comment by Mike Fikes [ 19/Nov/17 8:11 PM ]

Patch no longer applies.





[CLJS-555] CLONE - Implement ratios Created: 27/Jul/13  Updated: 02/Dec/14

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

Type: Enhancement Priority: Trivial
Reporter: Stuart Halloway Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None


 Description   

Clojure.java contains support for Ratio types. It would be nice to have them in Clojurescript as well, but as far as I can tell this would be new development (please comment if I'm wrong). That is, there is no implementation of Ratio types in GClosure so this feature would need to be implemented from the ground up. In additional to the Ratio type, the following corresponding functions would also need implementations:

  • `ratio?`
  • `numerator`
  • `denominator`
  • `rationalize`

Plus the ratio type would need to be rolled into the existing mathematical frameworkings.

Imported from github issue #66



 Comments   
Comment by David Nolen [ 02/Dec/14 6:14 AM ]

Lower priority, unsolvable without numerics overhaul.





Generated at Mon Jan 22 12:27:13 CST 2018 using JIRA 4.4#649-r158309.