<< Back to previous view

[CLJS-2234] Make build scripts optionally less verbose Created: 14/Jul/17  Updated: 14/Jul/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-2234.patch    
Patch: Code

 Description   

Canary project[1] needs to build ClojureScript compiler via script/build[2]. Canary's runner runs in Travis CI and this was causing too verbose output.

Let's allow altering build scripts verbosity via CLJS_SCRIPT_QUIET env var.

[1] https://github.com/cljs-oss/canary
[2] https://github.com/cljs-oss/canary/blob/9772649eae7097156251f4abb7ee70ea349ea99b/runner/scripts/build_compiler.sh#L84






[CLJS-2170] for macro does not support multiple body expr Created: 05/Jul/17  Updated: 08/Jul/17

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

Type: Enhancement Priority: Trivial
Reporter: Isaac Zeng Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

ClojureScript


Attachments: Text File 0001-let-macro-for-support-multiple-body-expr.patch    
Patch: Code

 Description   

see
https://dev.clojure.org/jira/browse/CLJ-2200



 Comments   
Comment by Mike Fikes [ 08/Jul/17 7:14 AM ]

The Clojure analog of this ticket has been declined; this one should be as well.





[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-2146] docstring for associative? should refer to IAssociative Created: 01/Jul/17  Updated: 01/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: David Nolen
Resolution: Unresolved Votes: 0
Labels: docstring

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

 Description   

The docstring currently mentions Associative:

cljs.user=> (doc associative?)
-------------------------
cljs.core/associative?
([x])
  Returns true if coll implements Associative
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-2096] Avoid re-declaring deref Created: 16/Jun/17  Updated: 25/Jun/17

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

Type: Enhancement Priority: Trivial
Reporter: A. R Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

Currently every single @ or deref creates code like this:

$cljs$core$deref$$.$cljs$core$IFn$_invoke$arity$1$ ? $cljs$core$deref$$.$cljs$core$IFn$_invoke$arity$1$($G__11312_arr$jscomp$92_init__$2$$) : $cljs$core$deref$$.call(null, $G__11312_arr$jscomp$92_init__$2$$);

because it is declared after already defined. See CLJS-1992 .






[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-1974] Remove cljs.core/fixture1 and fixture2 Created: 11/Mar/17  Updated: 11/Mar/17

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

Type: Enhancement Priority: Trivial
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: None

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

 Description   

There are a couple of vars in cljs.core named fixture1 and fixture2 that appear to perhaps be leftovers from when tests were assertions included in the cljs.core namespace.

https://github.com/clojure/clojurescript/commit/43861f7bc0b7b4fb534167b0773e49ccb68e6b1e#diff-a98a037c6c098dd3707e861df3c2f5acR1893

These can probably be safely removed.






[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-1969] Docstring for condp indicates IllegalArgumentException Created: 07/Mar/17  Updated: 07/Mar/17

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

Type: Defect Priority: Trivial
Reporter: Mike Fikes Assignee: David Nolen
Resolution: Unresolved Votes: 0
Labels: docstring

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

 Description   

The docstring for condp indicates IllegalArgumentException is thrown. Instead it should indicate Error (as does case's docstring, for example.)






[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: 25/Jun/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





[CLJS-1793] Few misplaced docstrings Created: 24/Sep/16  Updated: 24/Sep/16

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

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

Attachments: Text File CLJS-1793.patch    

 Description   

A few docsctrings were placed after the binding form in the src/main/clojure/cljs/closure.clj namespace.






[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: 01/Sep/16

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: 0
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.






[CLJS-1725] defrecord does not set cljs$lang$ctorStr Created: 04/Aug/16  Updated: 04/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-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






[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: 09/Jun/16

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    

 Description   

Local len isn't used in ObjMap / IKVReduce

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






[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: 29/Jan/16

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.






[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-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: 08/Apr/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: 2
Labels: None

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

 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*.





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

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





[CLJS-844] Optimize js->clj by switching to transients Created: 22/Aug/14  Updated: 21/Oct/16

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: 0
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    

 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?





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

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    

 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.





[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 Jul 24 07:39:11 CDT 2017 using JIRA 4.4#649-r158309.