On Sun, Dec 2, 2012 at 2:11 AM, Evan Mezeske emeze...@gmail.com wrote:
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
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
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,
Tracking this at http://dev.clojure.org/jira/browse/CLJS-418
-S
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
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 emeze...@gmail.com
The policy is: update the default version as quickly as possible when a
new
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
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
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.stuart.sie...@gmail.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
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
Oops, I've been out of town and did not see this release! I'll cut a new
lein-cljsbuild tomorrow night.
-Evan
On Friday, November 9, 2012 9:51:01 AM UTC-7, Sean Corfield wrote:
Nice!
I wonder how quickly lein-cljsbuild will get updated for this new
release? (Evan?)
Nice to see
On Sun, Nov 11, 2012 at 8:49 PM, Evan Mezeske emeze...@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
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
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
On Fri, Nov 9, 2012 at 6:17 AM, Stuart Sierra
the.stuart.sie...@gmail.com
14 matches
Mail list logo
