<< Back to previous view

[CLJS-1714] Clojurescript github README.md should identify source Clojure version Created: 24/Jul/16  Updated: 26/Jul/16

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

Type: Enhancement Priority: Trivial
Reporter: Marshall Abrams Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It would be helpful if the Clojurescript README at https://github.com/clojure/clojurescript/blob/master/README.md explicitly identified the Clojure version on which the current stable release of Clojurescript is based, or the Clojure version(s) which the Clojurescript release most closely tracks. This is especially helpful during periods when the Clojurescript release recommended in README.md is based on a Clojure alpha or even beta version, since there may be significant changes between Clojure versions in this case, so users might expect more similarity between the latest public releases of the two dialects than is warranted. Of course one can also go through changes.md to figure out what Clojure version is the basis of each Clojurescript release, but I think it's worth making it easier for users to notice.



 Comments   
Comment by David Nolen [ 25/Jul/16 2:08 PM ]

ClojureScript depends only on final releases of Clojure. This dependency is expressed in the pom.xml file which Maven based tooling and its users already understand. I don't see a compelling reason to include yet another thing we have to remember to update in the README.

Comment by Marshall Abrams [ 25/Jul/16 9:46 PM ]

First, I'm not sure if what I wrote was clear. I'm not talking about a dependency on the Clojure version used to compile to Javascript. I'm talking about the relationship between a Clojurescript version and the Clojure version that was ... ported to the Clojurescript release.

I agree it would a pain to try to remember to update this each time the Clojurescript version changed. That was one of my reservations, but I thought the point was important enough-especially for new users-that it seemed worth suggesting. I suppose that if there was already a line in the README about it, that will help, but I know that it's still easy to forget to update that kind of thing. Can't be helped.

Here are some reasons to consider updating the README with the Clojure version(s) that are the "source" of a Clojurescript version:

It's very useful information what version of Clojure the current Clojurescript release is most similar to. That way, information about the Clojure version is useful for Clojurescript.

At present, the official releases of Clojurescript listed in the README is based on what are currently alpha Clojure releases. Since the Clojure releases are alpha releases, they're changing quickly, so whatever's documented on the Clojure website may be out of sync with the Clojurescript release. One needs to know if that's so. (If all I want from the current Clojurescript release is what's in the previous non-alpha/beta Clojure release, knowing the Clojure version that was the source probably doesn't matter if there have been no breaking changes in the alpha releases on which the current Clojurescript version is based, but if I want to experiment in Clojurescript with new Clojure features-spec in this case-I need to know if it might differ from the latest Clojure version. (explain-data changed from Clojure 1.9.0-alpha7 to alpha10, at least.)

(I think that the comment about Maven and pom.xml was based on assuming that I was talking about the Clojure version used to compile Clojurescript code. If so, you can stop reading this paragraph. If not, then I would say that though Maven may be routinely used by Clojurescript developers-I don't know-but Clojurescript has grown beyond a core community of hardcore users and developers. It's used for a lot of real work, and it's a good language for new users coming from Clojure or Javascript. There are books for sale, and good online tutorials. The wiki is quite good for new users now. All of the templates on the wiki use Leiningen or Boot. There's no mention of Maven. There is no need for most users to use Maven with Clojurescript, or to even know what a pom file is. In my case, I do know what a pom file is, and have read quite a few, but wouldn't have thought to look there. I've never used Maven, however. Leiningen has been enough.)

Those are my thoughts on the matter. Thanks much for considering it.





[CLJS-1713] cljs.spec/explain-data returns different data structure than clojure.spec/explain-data Created: 24/Jul/16  Updated: 24/Jul/16

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

Type: Defect Priority: Minor
Reporter: Marshall Abrams Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: spec
Environment:

Tested in Clojure 1.9.0-alpha10 and Clojurescript 1.9.89



 Description   

The structure of the data returned by cljs.spec/explain-data seems to be unnecessarily different from the structure of data returned by clojure.spec/explain-data. Since, as I understand it, explain.data is mean to be used programmatically, this means that code has to be changed, unnecessarily, it seems, to work with both dialects.

Ignoring trivial differences that are to be expected going from one dialect to the other, in Clojure, the value of the top-level key :problems is a sequence of maps, each of which includes a :path key and value. In Clojurescript, the value of :problems is a map in which those vectors that were the values of :path in Clojure are instead keys, whose values are the rest of the corresponding Clojure maps.

Example:

(s/def ::a #(> % 0))
(s/def ::b (s/or :lt0 #(< % 0.0) :gt1 #(> % 1.0)))
(s/def ::all (s/keys :req-un [::a ::b]))
(s/explain ::all {:a -1 :b 0.5})
(pprint (s/explain-data ::all {:a -1 :b 0.5}))

In Clojure 1.9.0-alpha10, the last line returns:

#:clojure.spec{:problems ({:path [:a], :pred (> % 0), :val -1, :via [:user/all :user/a], :in [:a]}
                          {:path [:b :lt0], :pred (< % 0.0), :val 0.5, :via [:user/all :user/b], :in [:b]}
                          {:path [:b :gt1], :pred (> % 1.0), :val 0.5, :via [:user/all :user/b], :in [:b]})}

In Clojurescript 1.9.89, the same line returns:

{:cljs.spec/problems {[:a] {:pred (> % 0), :val -1, :via [:cljs.user/all :cljs.user/a], :in [:a]}, 
                      [:b :lt0] {:pred (< % 0), :val 0.5, :via [:cljs.user/all :cljs.user/b], :in [:b]},
                      [:b :gt1] {:pred (> % 1), :val 0.5, :via [:cljs.user/all :cljs.user/b], :in [:b]}}}


 Comments   
Comment by Marshall Abrams [ 24/Jul/16 11:58 AM ]

I just realized that Clojurescript 1.9.89 is still based on Clojure 1.9.0-alpha7, in which the data structure is like in the Clojurescript last example above. That explains the difference in the examples, and I assume that the explain-data return values will eventually be harmonized between the dialects, with future releases of Clojurescript (possibly after further changes in Clojure's explain-data return values, since this seems to be in flux). Apologies if this is just a "noise" ticket that shouldn't have been opened.





[CLJS-1712] Make PersistentHashSet implement IReduce Created: 21/Jul/16  Updated: 21/Jul/16

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

Type: Enhancement Priority: Minor
Reporter: Thomas Mulvaney Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: performance

Attachments: Text File difference-benchmark.txt     Text File into-benchmark.txt     Text File phs-reduce.patch     Text File union-benchmark.txt    
Patch: Code

 Description   

This improves speed of many reduce based operations on set which were falling back to seq-reduce, including code in `clojure.set` namespace such as `clojure.set/union` and `(into [] some-set)`.

I've included a few benchmarks I performed using `simple-benchmark` in a JavascriptCore environment (Planck REPL)



 Comments   
Comment by Rohit Aggarwal [ 21/Jul/16 3:35 PM ]

I think the code currently is faithful to Clojure's implementation of PersistentHashSet. So any change from that would probably require more thought and/or history.

Also someone else also raised a similar issue on ClojureScript mailing list.





[CLJS-1711] Compiler analysis cache issue with regex and Transit Created: 21/Jul/16  Updated: 22/Jul/16  Resolved: 22/Jul/16

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

Type: Defect Priority: Minor
Reporter: Rohit Aggarwal Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None
Environment:

Mac OS X. Bug reproduced on master branch and latest release


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

 Description   

This issue was reported by Martin Klepsch on Slack.

The following code causes the compiler to throw an error if transit-clj is included as a dependency.

core.cljs
(ns hello-world.core)

(enable-console-print!)

(defn x [{:keys [extract]
          :or {extract #"\w"}}])
build.clj
(require 'cljs.build.api)

(cljs.build.api/build "src" {:output-to "out/main.js"})

I used the following command to compile the code:

java -cp cljs.jar:transit-java-0.8.311.jar:transit-clj-0.8.285.jar:src clojure.main build.clj

The error stack trace is:

Exception in thread "main" clojure.lang.ExceptionInfo: failed compiling file:src/hello_world/core.cljs {:file #object[java.io.File 0xaed0151 "src/hello_world/core.cljs"]}, compiling:(....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/hello_world/core.cljs {:file #object[java.io.File 0xaed0151 "src/hello_world/core.cljs"]}
	at clojure.core$ex_info.invokeStatic(core.clj:4617)
	at cljs.compiler$compile_file$fn__2840.invoke(compiler.cljc:1368)
	at cljs.compiler$compile_file.invokeStatic(compiler.cljc:1338)
	at cljs.closure$compile_file.invokeStatic(closure.clj:471)
	at cljs.closure$fn__3897.invokeStatic(closure.clj:538)
	at cljs.closure$fn__3897.invoke(closure.clj:534)
	at cljs.closure$fn__3839$G__3832__3846.invoke(closure.clj:430)
	at cljs.closure$compile_sources$iter__4008__4012$fn__4013.invoke(closure.clj:870)
	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:867)
	at cljs.closure$build.invokeStatic(closure.clj:1995)
	at cljs.build.api$build.invokeStatic(api.clj:209)
	at cljs.build.api$build.invoke(api.clj:198)
	at cljs.build.api$build.invokeStatic(api.clj:201)
	at cljs.build.api$build.invoke(api.clj:198)
	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: java.lang.RuntimeException: java.lang.Exception: Not supported: class java.util.regex.Pattern
	at com.cognitect.transit.impl.WriterFactory$1.write(WriterFactory.java:129)
	at cognitect.transit$write.invokeStatic(transit.clj:149)
	at cognitect.transit$write.invoke(transit.clj:146)
	at cljs.analyzer$write_analysis_cache.invokeStatic(analyzer.cljc:2871)
	at cljs.compiler$emit_source.invokeStatic(compiler.cljc:1268)
	at cljs.compiler$compile_file_STAR_$fn__2817.invoke(compiler.cljc:1287)
	at cljs.compiler$with_core_cljs.invokeStatic(compiler.cljc:1154)
	at cljs.compiler$compile_file_STAR_.invokeStatic(compiler.cljc:1278)
	at cljs.compiler$compile_file$fn__2840.invoke(compiler.cljc:1358)
	... 34 more
Caused by: java.lang.Exception: Not supported: class java.util.regex.Pattern
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:176)
	at com.cognitect.transit.impl.JsonEmitter.emitMap(JsonEmitter.java:158)
	at com.cognitect.transit.impl.AbstractEmitter.emitMap(AbstractEmitter.java:70)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:166)
	at com.cognitect.transit.impl.JsonEmitter.emitMap(JsonEmitter.java:158)
	at com.cognitect.transit.impl.AbstractEmitter.emitMap(AbstractEmitter.java:70)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:166)
	at com.cognitect.transit.impl.AbstractEmitter.emitArray(AbstractEmitter.java:82)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:164)
	at com.cognitect.transit.impl.AbstractEmitter.emitArray(AbstractEmitter.java:87)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:164)
	at com.cognitect.transit.impl.AbstractEmitter.emitTagged(AbstractEmitter.java:34)
	at com.cognitect.transit.impl.AbstractEmitter.emitEncoded(AbstractEmitter.java:59)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:169)
	at com.cognitect.transit.impl.AbstractEmitter.emitArray(AbstractEmitter.java:87)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:164)
	at com.cognitect.transit.impl.AbstractEmitter.emitTagged(AbstractEmitter.java:34)
	at com.cognitect.transit.impl.AbstractEmitter.emitEncoded(AbstractEmitter.java:59)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:169)
	at com.cognitect.transit.impl.JsonEmitter.emitMap(JsonEmitter.java:158)
	at com.cognitect.transit.impl.AbstractEmitter.emitMap(AbstractEmitter.java:70)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:166)
	at com.cognitect.transit.impl.JsonEmitter.emitMap(JsonEmitter.java:158)
	at com.cognitect.transit.impl.AbstractEmitter.emitMap(AbstractEmitter.java:70)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:166)
	at com.cognitect.transit.impl.JsonEmitter.emitMap(JsonEmitter.java:158)
	at com.cognitect.transit.impl.AbstractEmitter.emitMap(AbstractEmitter.java:70)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:166)
	at com.cognitect.transit.impl.JsonEmitter.emitMap(JsonEmitter.java:158)
	at com.cognitect.transit.impl.AbstractEmitter.emitMap(AbstractEmitter.java:70)
	at com.cognitect.transit.impl.AbstractEmitter.marshal(AbstractEmitter.java:166)
	at com.cognitect.transit.impl.AbstractEmitter.marshalTop(AbstractEmitter.java:193)
	at com.cognitect.transit.impl.JsonEmitter.emit(JsonEmitter.java:28)
	at com.cognitect.transit.impl.WriterFactory$1.write(WriterFactory.java:126)
	... 42 more

It works perfectly fine if the transit dependency is removed.



 Comments   
Comment by Rohit Aggarwal [ 21/Jul/16 2:56 AM ]

A related issue is that for the compiler analysis cache, for edn, the code is using pr-str to output, which handles regular expressions just fine. But AFAIK, a regex isn't a type supported by edn and edn/read-string doesn't work with the string outputted by pr-str.

Not sure what to do with that.

Comment by David Nolen [ 22/Jul/16 7:34 AM ]

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





[CLJS-1710] spec/double-in not implemented Created: 20/Jul/16  Updated: 20/Jul/16

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

Type: Defect Priority: Major
Reporter: Marshall Abrams Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: cljs, newbie, spec
Environment:

Clojurescript 1.9.89



 Description   

spec/double-in is available in Clojure 1.9.0-alpha10, but doesn't seem to be implemented yet in Clojurescript as of 1.9.89. I also tried 1.9.76: not there either.

cljs.user=> (require '[cljs.spec :as s])
nil
cljs.user=> (s/valid? #(and (>= % 0.0) (<= % 1.0)) 1.0)
----  Compiler Warning on   <cljs form>   line:1  column:12  ----

  Use of undeclared Var cljs.spec/double-in

  1  (s/valid? (s/double-in :min 0.0 :max 1.0) 1.0)
                ^---

----  Compiler Warning  ----
#object[TypeError TypeError: Cannot read property 'call' of undefined]
nil

(Newbie ticket. Apologies if this is a dupe ticket or doesn't belong here. I couldn't find any tickets that seemed to mention this issue.)






Generated at Tue Jul 26 13:05:16 CDT 2016 using JIRA 4.4#649-r158309.