ANN: ClojureScript 0.0-3115

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

New release version: 0.0-3115

Leiningen dependency information:

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

This release is a bugfix release addressing several long outstanding

issues as well as a number of problems that cropped up around improved

REPLs and compile times.

As usual feedback welcome!

## 0.0-3115

### Enhancements

* CLJS-806: support ^:const

* CLJS-1115: Reusable repl-bootstrap! fn

### Changes

* CLJS-667: validate extend-type and extend-protocol shape

* CLJS-1112: :repl-requires option for REPL evaluation environment

* CLJS-1111: browser REPL should have no side effects until -setup

### Fixes

* CLJS-1085: Allow to pass test environment to cljs.test/run-all-tests

* CLJS-867: extend-type with Object methods requires multi-arity style definition

* CLJS-1118: cljs.repl/doc support for protocols

* CLJS-889: re-pattern works on strings containing \u2028 or \u2029

* CLJS-109: Compiler errors/warnings should be displayed when cljs namespace 'package' names start with an unacceptable javascript symbol

* CLJS-891: Defs in "parent" namespaces clash with "child" namespaces with the same name?

* CLJS-813: Warn about reserved JS keyword usage in namespace names

* CLJS-876: merged sourcemap doesn't account for output-wrapper

* CLJS-1062: Incorrect deftype/defrecord definition leads to complex error messages

* CLJS-1120: analyze-deps does not appear to work when analyzing analysis caches

* CLJS-1119: constant table emission logic is incorrect

* CLJS-977: implement IKVReduce in Subvec

* CLJS-1117: Dependencies in JARs don't use cached analysis

* CLJS-689: js/-Infinity munges to _Infinity

* CLJS-1114: browser REPL script loading race condition

* CLJS-1110: cljs.closure/watch needs to print errors to *err*

* CLJS-1101 cljs.test might throw when trying to detect file-and-line

* CLJS-1090: macros imported from clojure.core missing docs

* CLJS-1108: :modules :output-to needs to create directories

* CLJS-1095: UUID to implement IComparable

* CLJS-1096: Update js/Date -equiv and -compare semantics based on Date.valueOf() value

* CLJS-1102 clojure.test should print column number of exception when available

[David Nolen]

Just cut 0.0-3117 the only change is an important fix that will recompile files when changing :optimizations settings. In general trying to move to a world where a corrupted :output-dir is highly unlikely. The next big release will be even further improved along these lines.

David

[Jonathon McKitrick]

I just tried a build with this version, and I'm getting this error in my CLJS test suite, which does not happen with 0.0-2985.

Compiling ClojureScript.
Compiling "resources/public/js/unit-test.js" from ["src/cljs" "test/cljs"]...
Successfully compiled "resources/public/js/unit-test.js" in 17.483 seconds.
Compiling "resources/public/js/main.js" from ["src/cljs"]...
Successfully compiled "resources/public/js/main.js" in 14.543 seconds.
Running ClojureScript test: unit-test
Error: goog.require could not find: cljsjs.react

resources/public/js/unit-test.js:19683
resources/public/js/unit-test.js:55237

ERROR: cemerick.cljs.test was not required.

You can resolve this issue by ensuring [cemerick.cljs.test] appears
in the :require clause of your test suite namespaces.
Also make sure that your build has actually included any test files.

[David Nolen]

Need more information. But that warning is most certainly not something emitted by the ClojureScript compiler.

Make sure you can reproduce without whatever downstream tooling you may be using: https://github.com/clojure/clojurescript/wiki/Reporting-Issues

There's a good chance it's purely downstream and needs to be reported elsewhere.

David

--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[David Nolen]

On Mon, Mar 16, 2015 at 1:01 PM, Fluid Dynamics <a209...@trbvm.com> wrote:

On Monday, March 16, 2015 at 11:23:14 AM UTC-4, David Nolen wrote:

Need more information. But that warning is most certainly not something emitted by the ClojureScript compiler.

Make sure you can reproduce without whatever downstream tooling you may be using: https://github.com/clojure/clojurescript/wiki/Reporting-Issues

There's a good chance it's purely downstream and needs to be reported elsewhere.

 
The only thing the OP changed was the version of cljs he was using, and his project went from working to broken. This means that one of the changes in the new cljs broke something. Whether it directly broke the OP's code, or broke a library that the OP's project depends on, is immaterial; the location of the breaking change was in cljs itself

No. A surprising amount of downstream tooling relies on unpublished and undocumented details of the ClojureScript compiler. This kind of third party breakage is rarely if ever under consideration.

David 

[David Nolen]

It appears there was a regression in ClojureScript :foreign-libs support and Closure optimization passes. Just cut 0.0-3119 to address this.

Jonathan, this may fix your issue but it's unclear as the regression was around release builds and your error about cljsjs.react seems like it originated from a dev build to me.

David

On Mon, Mar 16, 2015 at 1:09 PM, Luc Préfontaine <lprefo...@softaddicts.ca> wrote:

It's up the maintainers down the food chain to keep up with changes and yes there are
timing issues, not all changes/fixes can be applied synchronously.

That's the idea of having libraries instead of a monolithic soup of code.

Applying your statement to technology in general we would still be using
horse driven carts...  I appreciate the life style of Amish communities and would
certainly switch to it if I could. But that's not how my world is wired presently.

Luc P.

> On Monday, March 16, 2015 at 11:23:14 AM UTC-4, David Nolen wrote:
> >

> > Need more information. But that warning is most certainly not something
> > emitted by the ClojureScript compiler.
> >
> > Make sure you can reproduce without whatever downstream tooling you may be
> > using: https://github.com/clojure/clojurescript/wiki/Reporting-Issues
> >
> > There's a good chance it's purely downstream and needs to be reported
> > elsewhere.
> >
>

> The only thing the OP changed was the version of cljs he was using, and his
> project went from working to broken. This means that one of the changes in
> the new cljs broke something. Whether it directly broke the OP's code, or
> broke a library that the OP's project depends on, is immaterial; the

> location of the breaking change was in cljs itself.

>
> --
> You received this message because you are subscribed to the Google

> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com

> Note that posts from new members are moderated - please be patient with your first post.

> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

--
Luc Préfontaine<lprefo...@softaddicts.ca> sent by ibisMail!

--
You received this message because you are subscribed to the Google

Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com

Note that posts from new members are moderated - please be patient with your first post.

To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Nolen]

On Mon, Mar 16, 2015 at 2:47 PM, Fluid Dynamics <a209...@trbvm.com> wrote:

If that is true, then it is a problem, indicative either of a widespread lack of discipline among the tool makers or (more likely) a strong need for some additional well-specified (and maintained!) APIs in the compiler for tools to hook into.

It's been suggested that the community work on this numerous times and on numerous channels. So far few people have stepped forward to help design, maintain, and document shared tooling entry points.

It's also the case that for many users popular and critical ClojureScript tools like cljsbuild are unfortunately considered a blackbox. This means that tooling authors don't get nearly the amount of distributed community effort they deserve for their efforts.

As the community comes to grips with the Quick Start and how the ClojureScript compiler actually works people can begin to identify what is fundamental to ClojureScript and what isn't. Until this knowledge becomes more broadly disseminated the tooling state of affairs is not going to improve very quickly.

David 

[Leon Grapenthin]

If it helps: I am getting a similar error ( goog.require could not find: cljsjs.react  when trying to compile a namespace via weasel-5.0.0 and piggieback... 

On Monday, March 16, 2015 at 7:47:12 PM UTC+1, Fluid Dynamics wrote:

On Monday, March 16, 2015 at 1:06:31 PM UTC-4, David Nolen wrote:

On Mon, Mar 16, 2015 at 1:01 PM, Fluid Dynamics <a209...@trbvm.com> wrote:

On Monday, March 16, 2015 at 11:23:14 AM UTC-4, David Nolen wrote:

Need more information. But that warning is most certainly not something emitted by the ClojureScript compiler.

Make sure you can reproduce without whatever downstream tooling you may be using: https://github.com/clojure/clojurescript/wiki/Reporting-Issues

There's a good chance it's purely downstream and needs to be reported elsewhere.

 
The only thing the OP changed was the version of cljs he was using, and his project went from working to broken. This means that one of the changes in the new cljs broke something. Whether it directly broke the OP's code, or broke a library that the OP's project depends on, is immaterial; the location of the breaking change was in cljs itself

No.

"No"? Are you *denying* that the breaking change was in cljs itself, even though the OP says that's *the only thing changed* between a working and a non-working configuration?
 

A surprising amount of downstream tooling relies on unpublished and undocumented details of the ClojureScript compiler.

[David Nolen]

Both piggieback and weasel unfortunately tapped into undiscussed details. piggieback's design is fundamentally flawed (being constructed on flawed implementation details of the standard REPL infrastructure which have since changed) and I would personally be happy to see piggieback eventually disappear. weasel has been refactored to work correctly after the maintainer reviewed this document which I wrote: https://github.com/clojure/clojurescript/wiki/Custom-REPLs

Anyways I've personally submitted fixes to both piggieback and weasel some time ago, SNAPSHOT releases of both work with the latest ClojureScript as far as I'm aware.

David

[Mike Fikes]

If that is true, then it is a problem, indicative either of a widespread lack of discipline among the tool makers or (more likely) a strong need for some additional well-specified (and maintained!) APIs in the compiler for tools to hook into. 

Sometimes it is just a simple bug or lack of robustness in a downstream tool that needs to be sorted before rushing to blame and/or burden upstream ClojureScript.

Take https://github.com/omcljs/ambly/issues/61 as an example. Previously ClojureScript 0.0-3030 would not print anything when evaluating (doc unknown-symbol), and with 0.0-3053 onwards it prints an empty string. This broke Ambly.

This doesn't really reflect a lack of discipline with APIs, but does illustrates the need to do downstream triage first.

[David Nolen]

And cut 0.0-3123 based on feedback from releases earlier today. One fix addresses redundant information in the dependency graph when compiling, the other fixes an issue when using advanced optimizations and :cache-analysis true.

David

On Mon, Mar 16, 2015 at 7:11 AM, David Nolen <dnolen...@gmail.com> wrote:

[Jonathon McKitrick]

The cljsjs issue is fixed!

[David Nolen]

Glad to hear it!

[Leon Grapenthin]

Here is the error I am still getting when compiling a ns via piggieback 0.1.5 /weasel 0.6.0 on cljs 3123:

1. Unhandled clojure.lang.ExceptionInfo
No such namespace: cljsjs.react, could not locate cljsjs/react.cljs
at line 1
file:/home/leon/.m2/repository/org/omcljs/om/0.8.8/om-0.8.8.jar!/om/dom.cljs
{:tag :cljs/analysis-error,
:file
"file:/home/leon/.m2/repository/org/omcljs/om/0.8.8/om-0.8.8.jar!/om/dom.cljs",
:line 1,
:column 1}

[Leon Grapenthin]

And stacktrace - looks like a piggieback issue:
core.clj: 4577 clojure.core/ex-info
analyzer.clj: 379 cljs.analyzer/error
analyzer.clj: 376 cljs.analyzer/error
analyzer.clj: 1249 cljs.analyzer/analyze-deps
analyzer.clj: 1494 cljs.analyzer/eval18559/fn
MultiFn.java: 251 clojure.lang.MultiFn/invoke
analyzer.clj: 1833 cljs.analyzer/analyze-seq
analyzer.clj: 1925 cljs.analyzer/analyze/fn
analyzer.clj: 1918 cljs.analyzer/analyze
analyzer.clj: 2133 cljs.analyzer/analyze-file/fn
analyzer.clj: 2129 cljs.analyzer/analyze-file
analyzer.clj: 1246 cljs.analyzer/analyze-deps
analyzer.clj: 1494 cljs.analyzer/eval18559/fn
MultiFn.java: 251 clojure.lang.MultiFn/invoke
analyzer.clj: 1833 cljs.analyzer/analyze-seq
analyzer.clj: 1925 cljs.analyzer/analyze/fn
analyzer.clj: 1918 cljs.analyzer/analyze
analyzer.clj: 2133 cljs.analyzer/analyze-file/fn
analyzer.clj: 2129 cljs.analyzer/analyze-file
analyzer.clj: 1246 cljs.analyzer/analyze-deps
analyzer.clj: 1494 cljs.analyzer/eval18559/fn
MultiFn.java: 251 clojure.lang.MultiFn/invoke
analyzer.clj: 1833 cljs.analyzer/analyze-seq
analyzer.clj: 1925 cljs.analyzer/analyze/fn
analyzer.clj: 1918 cljs.analyzer/analyze
repl.clj: 389 cljs.repl/evaluate-form
repl.clj: 386 cljs.repl/evaluate-form
piggieback.clj: 116 cemerick.piggieback/cljs-eval/fn
AFn.java: 152 clojure.lang.AFn/applyToHelper
AFn.java: 144 clojure.lang.AFn/applyTo
core.clj: 626 clojure.core/apply
core.clj: 1864 clojure.core/with-bindings*
RestFn.java: 425 clojure.lang.RestFn/invoke
piggieback.clj: 97 cemerick.piggieback/cljs-eval
AFn.java: 165 clojure.lang.AFn/applyToHelper
AFn.java: 144 clojure.lang.AFn/applyTo
core.clj: 628 clojure.core/apply
piggieback.clj: 180 cemerick.piggieback/cljs-repl/fn
RestFn.java: 436 clojure.lang.RestFn/invoke
Var.java: 388 clojure.lang.Var/invoke
REPL: 1 colligent.components.staff.vouchers/eval30315
Compiler.java: 6767 clojure.lang.Compiler/eval
Compiler.java: 6730 clojure.lang.Compiler/eval
core.clj: 3076 clojure.core/eval
main.clj: 239 clojure.main/repl/read-eval-print/fn
main.clj: 239 clojure.main/repl/read-eval-print
main.clj: 257 clojure.main/repl/fn
main.clj: 257 clojure.main/repl
RestFn.java: 1523 clojure.lang.RestFn/invoke
interruptible_eval.clj: 67 clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
AFn.java: 152 clojure.lang.AFn/applyToHelper
AFn.java: 144 clojure.lang.AFn/applyTo
core.clj: 626 clojure.core/apply
core.clj: 1864 clojure.core/with-bindings*
RestFn.java: 425 clojure.lang.RestFn/invoke
interruptible_eval.clj: 51 clojure.tools.nrepl.middleware.interruptible-eval/evaluate
interruptible_eval.clj: 183 clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
interruptible_eval.clj: 152 clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn
AFn.java: 22 clojure.lang.AFn/run
ThreadPoolExecutor.java: 1145 java.util.concurrent.ThreadPoolExecutor/runWorker
ThreadPoolExecutor.java: 615 java.util.concurrent.ThreadPoolExecutor$Worker/run
Thread.java: 745 java.lang.Thread/run

[Max Gonzih]

After update compilation with advanced optimizations displays following warning:

WARNING: file:/home/gnzh/.m2/repository/org/clojure/google-closure-library/0.0-20140718-946a7d39/google-closure-library-0.0-20140718-946a7d39.jar!/goog/net/jsonp.js:269: WARNING - Misplaced f
unction annotation.
  return function(var_args) {
  ^

Mar 17, 2015 10:44:04 AM com.google.javascript.jscomp.LoggerErrorManager printSummary
WARNING: 0 error(s), 1 warning(s)


Just curios what is it related to?

[David Nolen]

Yes I said earlier that you'll want SNAPSHOT releases of both weasel and piggieback. The current release of piggieback doesn't include this commit https://github.com/cemerick/piggieback/commit/966c811ab817df0e818404943c473081337b286e

In the case of weasel you might want to try a local install of my patched fork https://github.com/swannodette/weasel

David

[David Nolen]

We bumped the Closure Compiler dependency which now spews a few innocuous warnings. Feel free to report this one to the Google Closure mailing list. I've already reported the Object type one we get now when using browser REPL.

David

[Leon Grapenthin]

Thanks :)