[ANN] ClojureScript release 0.0-1535 with G.Closure 0.0-2029

638 views
Skip to first unread message

Stuart Sierra

unread,
Nov 9, 2012, 9:17:58 AM11/9/12
to clo...@googlegroups.com
ClojureScript release 0.0-1535 is out. Get it in Leiningen:

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

Change log for this release:
http://build.clojure.org/job/clojurescript-release/19/

This release depends on the latest version of the Google Closure Library, r2029. You can also depend on it explicitly:

    [org.clojure/google-closure-library "0.0-2029"]

ClojureScript does NOT depend directly on the Google Closure Library third-party extensions, but you can get it:

     [org.clojure/google-closure-library-third-party "0.0-2029"]


Sean Corfield

unread,
Nov 9, 2012, 11:50:42 AM11/9/12
to clo...@googlegroups.com
Nice!

I wonder how quickly lein-cljsbuild will get updated for this new
release? (Evan?)

Nice to see Leiningen and lein-cljsbuild introduced up front in your
book as the quickest way to get up and running, Stuart!

Sean

Evan Mezeske

unread,
Nov 11, 2012, 11:49:55 PM11/11/12
to clo...@googlegroups.com
Oops, I've been out of town and did not see this release!  I'll cut a new lein-cljsbuild tomorrow night.

-Evan

Sean Corfield

unread,
Nov 12, 2012, 12:36:49 AM11/12/12
to clo...@googlegroups.com
On Sun, Nov 11, 2012 at 8:49 PM, Evan Mezeske <emez...@gmail.com> wrote:
> Oops, I've been out of town and did not see this release! I'll cut a new
> lein-cljsbuild tomorrow night.

Wasn't trying to make you feel guilty! Just wondered if there was a
policy of tracking builds.

Welcome back - and thank you!
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

Evan Mezeske

unread,
Nov 13, 2012, 2:48:26 AM11/13/12
to clo...@googlegroups.com
The policy is: update the default version as quickly as possible when a new ClojureScript compiler revision is released.  So, feel free to poke me if it seems like I haven't noticed a new release (as I might not have!).  :)

Unfortunately, after setting the default ClojureScript version to 0.0-1535, the lein-cljsbuild simple project compiles fine, but attempting to compile the advanced project results in a NullPointerException:

https://github.com/emezeske/lein-cljsbuild/issues/155

This is going to take some debugging -- I'm not comfortable releasing lein-cljsbuild until both example projects compile and run cleanly.  If anyone has insight into the problem, that would be great.

-Evan

Herwig Hochleitner

unread,
Nov 13, 2012, 4:38:45 AM11/13/12
to clo...@googlegroups.com
I've seen this same NPE in my project. I managed to work around it by temporarily throwing out the browser repl. It seems to trigger the NPE. Not sure how and why.


2012/11/13 Evan Mezeske <emez...@gmail.com>

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

Herwig Hochleitner

unread,
Nov 13, 2012, 7:07:58 AM11/13/12
to clo...@googlegroups.com
I've debugged a bit, the underlying cause seems to be that goog.net.xpc.CrosspageChannel uses goog.async.Deferred, which lives in third_party.
In my project, I could indeed successfully compile again with the browser repl, by adding the third-party jar.

This leaves two open issues:

Why the NPE in cljsbuild? 
script/cljsc complains about goog.async.Deferred never provided, as it should. When compiling with cljsbuild, however, the js-sources list contains an entry which :provides goog.async.Deferred but has an :uri of nil, which triggers the breakage when mapping javascript-name over it. I didn't find out where that entry comes from. This is probably a cljsbuild issue, so I'll amend the ticket if I have time to look into this within a few days.

So clojure.browser.repl transitively depends on third_party now
Not only that, there are a lot of files in closure lib proper that depend on goog.async.Deferred, as you can verify by running

grep -r "goog.require('goog.async.Deferred')" closure/library/closure

from cljs root dir. That begs two questions: 
- Are there other third-party libs referred to from closure proper and has that been the case with older versions?
- Does it still make sense to split closure lib?


2012/11/13 Herwig Hochleitner <hhochl...@gmail.com>

Stuart Sierra

unread,
Nov 13, 2012, 9:08:52 AM11/13/12
to clo...@googlegroups.com
My original reason for splitting the third-party JAR was the licensing: the main G.Closure library is under the Apache license; the third-party libraries are under a variety of different licenses.

One simple solution would be to make ClojureScript itself have a dependency on the third-party libs in addition to the core G.Closure libraries. Then users would still have the option of excluding the third-party extensions from their projects.

-S

Herwig Hochleitner

unread,
Nov 13, 2012, 9:58:30 AM11/13/12
to clo...@googlegroups.com
I concur, but maybe we could make a second release of the closure lib main jar, with a dependency on third-party?
That would reflect the actual dependency.

I know, you asked for testing before the release. Sorry for not catching this one.


2012/11/13 Stuart Sierra <the.stua...@gmail.com>
My original reason for splitting the third-party JAR was the licensing: the main G.Closure library is under the Apache license; the third-party libraries are under a variety of different licenses.

One simple solution would be to make ClojureScript itself have a dependency on the third-party libs in addition to the core G.Closure libraries. Then users would still have the option of excluding the third-party extensions from their projects.

-S

Evan Mezeske

unread,
Nov 13, 2012, 10:58:05 PM11/13/12
to clo...@googlegroups.com
I agree with Herwig, in that if the ClojureScript JAR makes use of goog.async.Deferred, which is from the third party library, then the JAR really needs to depend on the third-party library.

I doubt that lein-cljsbuild is the only thing broken by this -- I expect this would break things like piggieback as well (really, anything that depends on ClojureScript but lacks an explicit dependency on the third-party stuff).

I could hack a third-party dependency into lein-cljsbuild, but I would prefer to just wait until a new ClojureScript is released that addresses this issue.

-Evan

Stuart Sierra

unread,
Nov 16, 2012, 7:50:23 PM11/16/12
to clo...@googlegroups.com

David Nolen

unread,
Nov 30, 2012, 7:38:20 PM11/30/12
to clojure
Can we move forward on this? Option 1 seems best to me. That said what's the compelling reason these days for lein-cljsbuild to depend on a specific version of ClojureScript? Are you relying on certain aspects of the analyzer or compiler's API and find that they change quite frequently?


On Fri, Nov 16, 2012 at 7:50 PM, Stuart Sierra <the.stua...@gmail.com> wrote:

Evan Mezeske

unread,
Dec 2, 2012, 2:11:51 AM12/2/12
to clo...@googlegroups.com

That said what's the compelling reason these days for lein-cljsbuild to depend on a specific version of ClojureScript? Are you relying on certain aspects of the analyzer or compiler's API and find that they change quite frequently?

I guess the (debatably compelling) reason for that these days is just that I like the idea of providing a sensible default.  AFAIK, you can always override the version by adding it you a project's :dependencies if you want to (I'd test this but am in the middle of moving atm, without access to my stuff).

Besides just having a sensible default, I also like to "endorse" a particular version of the compiler for a particular version of lein-cljsbuild.  Before any release, I do a few rounds of testing with the example projects and some of my personal stuff, and confirm that things seem to work.

Now, if I'm wrong, and you can't just stick a different version of clojurescript in :dependencies and have it work, then I'd consider that a bug.

David Nolen

unread,
Dec 2, 2012, 11:34:18 PM12/2/12
to clojure
That sounds reasonable to me. 
Reply all
Reply to author
Forward
0 new messages