Re: ANN: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times
Amazing update! Yay.
But I just spotted one weird thing, after I pumped compiler version compilation
fails for me with following error:
clojure.lang.ExceptionInfo: failed compiling
file:public/javascripts/out-server-side/cljs/core.cljs {:file #File
public/javascripts/out-server-side/cljs/core.cljs}
at clojure.core$ex_info.invoke(core.clj:4403)
at cljs.compiler$compile_file$fn__2959.invoke(compiler.clj:1130)
at cljs.compiler$compile_file.invoke(compiler.clj:1101)
at cljs.closure$compile_file.invoke(closure.clj:347)
at cljs.closure$eval3294$fn__3295.invoke(closure.clj:398)
at cljs.closure$eval3230$fn__3231$G__3221__3238.invoke(closure.clj:305)
at cljs.closure$compile_from_jar.invoke(closure.clj:390)
at cljs.closure$eval3289$fn__3290.invoke(closure.clj:404)
at cljs.closure$eval3230$fn__3231$G__3221__3238.invoke(closure.clj:305)
at cljs.closure$get_compiled_cljs.invoke(closure.clj:467)
at cljs.closure$cljs_dependencies.invoke(closure.clj:511)
at cljs.closure$add_dependencies.doInvoke(closure.clj:533)
at clojure.lang.RestFn.applyTo(RestFn.java:139)
at clojure.core$apply.invoke(core.clj:626)
at cljs.closure$build.invoke(closure.clj:1408)
at cljs.closure$build.invoke(closure.clj:1351)
at cljsbuild.compiler$compile_cljs$fn__3665.invoke(compiler.clj:81)
at cljsbuild.compiler$compile_cljs.invoke(compiler.clj:80)
at cljsbuild.compiler$run_compiler.invoke(compiler.clj:180)
at
user$eval3797$iter__3833__3837$fn__3838$fn__3856.invoke(form-init1562646833731967415.clj:1)
at
user$eval3797$iter__3833__3837$fn__3838.invoke(form-init1562646833731967415.clj:1)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:484)
at clojure.core$seq.invoke(core.clj:133)
at clojure.core$dorun.invoke(core.clj:2855)
at clojure.core$doall.invoke(core.clj:2871)
at user$eval3797.invoke(form-init1562646833731967415.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6703)
at clojure.lang.Compiler.eval(Compiler.java:6693)
at clojure.lang.Compiler.load(Compiler.java:7130)
at clojure.lang.Compiler.loadFile(Compiler.java:7086)
at clojure.main$load_script.invoke(main.clj:274)
at clojure.main$init_opt.invoke(main.clj:279)
at clojure.main$initialize.invoke(main.clj:307)
at clojure.main$null_opt.invoke(main.clj:342)
at clojure.main$main.doInvoke(main.clj:420)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.ClassCastException: java.net.URL cannot be cast to
java.io.File
at cljs.util$mkdirs.invoke(util.clj:80)
at cljs.analyzer$write_analysis_cache.invoke(analyzer.clj:2021)
at cljs.compiler$compile_file_STAR_$fn__2927.invoke(compiler.clj:1055)
at cljs.compiler$with_core_cljs.invoke(compiler.clj:961)
at cljs.compiler$compile_file_STAR_.invoke(compiler.clj:981)
at cljs.compiler$compile_file$fn__2959.invoke(compiler.clj:1118)
... 40 more
Subprocess failed
Is this related to AOT compiler cljs.core ns?
On Tuesday, March 10, 2015 at 12:41:45 AM UTC+1, David Nolen wrote:
ClojureScript, the Clojure compiler that emits JavaScript source code.
README and source code: https://github.com/clojure/clojurescript
New release version: 0.0-3058
Leiningen dependency information:
[org.clojure/clojurescript 0.0-3058]
This is a significant enhancement release around REPLs and compile times.
All builtin REPLs (Nashorn, Node.js, Rhino and the browser REPL) now
support the helper functions normally available via clojure.repl,
these include: doc, find-doc, apropos, dir, source, and pst. All of the
builtins REPL now also support source mapped stacktraces.
This release also includes many enhancements around compile times.
ClojureScript now ships with a default :optimizations setting of
:none. Implicit now when using :none is source map generation and analysis
caching. Analysis caching significantly speeds up compile times.
The standard library (cljs.core) is now AOTed compiled to JavaScript
along with an AOTed analysis dump and an AOTed source map. This
dramatically cuts down on cold start compile times. The standard
library is never actually ever analyzed or compiled in your own
builds. The result is particularly dramatic for REPLs.
ClojureScript is also now available for the first time as a standalone
AOTed JAR. The Quick Start introduction has been rewritten in terms of
the standalone JAR:
https://github.com/clojure/clojurescript/wiki/Quick-Start
The new Quick Start
Re: [ClojureScript] Re: ANN: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times
Looks like you're trying to use :cache-analysis with a higher
:optimizations setting than :none. I would avoid this for now.
http://dev.clojure.org/jira/browse/CLJS-1103
David
On Tue, Mar 10, 2015 at 6:07 AM, Max Gonzih gon...@gmail.com wrote:
Amazing update! Yay.
But I just spotted one weird thing, after I pumped compiler version
compilation fails for me with following error:
clojure.lang.ExceptionInfo: failed compiling
file:public/javascripts/out-server-side/cljs/core.cljs {:file #File
public/javascripts/out-server-side/cljs/core.cljs}
at clojure.core$ex_info.invoke(core.clj:4403)
at cljs.compiler$compile_file$fn__2959.invoke(compiler.clj:1130)
at cljs.compiler$compile_file.invoke(compiler.clj:1101)
at cljs.closure$compile_file.invoke(closure.clj:347)
at cljs.closure$eval3294$fn__3295.invoke(closure.clj:398)
at
cljs.closure$eval3230$fn__3231$G__3221__3238.invoke(closure.clj:305)
at cljs.closure$compile_from_jar.invoke(closure.clj:390)
at cljs.closure$eval3289$fn__3290.invoke(closure.clj:404)
at
cljs.closure$eval3230$fn__3231$G__3221__3238.invoke(closure.clj:305)
at cljs.closure$get_compiled_cljs.invoke(closure.clj:467)
at cljs.closure$cljs_dependencies.invoke(closure.clj:511)
at cljs.closure$add_dependencies.doInvoke(closure.clj:533)
at clojure.lang.RestFn.applyTo(RestFn.java:139)
at clojure.core$apply.invoke(core.clj:626)
at cljs.closure$build.invoke(closure.clj:1408)
at cljs.closure$build.invoke(closure.clj:1351)
at cljsbuild.compiler$compile_cljs$fn__3665.invoke(compiler.clj:81)
at cljsbuild.compiler$compile_cljs.invoke(compiler.clj:80)
at cljsbuild.compiler$run_compiler.invoke(compiler.clj:180)
at
user$eval3797$iter__3833__3837$fn__3838$fn__3856.invoke(form-init1562646833731967415.clj:1)
at
user$eval3797$iter__3833__3837$fn__3838.invoke(form-init1562646833731967415.clj:1)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:484)
at clojure.core$seq.invoke(core.clj:133)
at clojure.core$dorun.invoke(core.clj:2855)
at clojure.core$doall.invoke(core.clj:2871)
at user$eval3797.invoke(form-init1562646833731967415.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6703)
at clojure.lang.Compiler.eval(Compiler.java:6693)
at clojure.lang.Compiler.load(Compiler.java:7130)
at clojure.lang.Compiler.loadFile(Compiler.java:7086)
at clojure.main$load_script.invoke(main.clj:274)
at clojure.main$init_opt.invoke(main.clj:279)
at clojure.main$initialize.invoke(main.clj:307)
at clojure.main$null_opt.invoke(main.clj:342)
at clojure.main$main.doInvoke(main.clj:420)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.ClassCastException: java.net.URL cannot be cast to
java.io.File
at cljs.util$mkdirs.invoke(util.clj:80)
at cljs.analyzer$write_analysis_cache.invoke(analyzer.clj:2021)
at
cljs.compiler$compile_file_STAR_$fn__2927.invoke(compiler.clj:1055)
at cljs.compiler$with_core_cljs.invoke(compiler.clj:961)
at cljs.compiler$compile_file_STAR_.invoke(compiler.clj:981)
at cljs.compiler$compile_file$fn__2959.invoke(compiler.clj:1118)
... 40 more
Subprocess failed
Is this related to AOT compiler cljs.core ns?
On Tuesday, March 10, 2015 at 12:41:45 AM UTC+1, David Nolen wrote:
ClojureScript, the Clojure compiler that emits JavaScript source code.
README and source code: https://github.com/clojure/clojurescript
New release version: 0.0-3058
Leiningen dependency information:
[org.clojure/clojurescript 0.0-3058]
This is a significant enhancement release around REPLs and compile times.
All builtin REPLs (Nashorn, Node.js, Rhino and the browser REPL) now
support the helper functions normally available via clojure.repl,
these include: doc, find-doc, apropos, dir, source, and pst. All of the
builtins REPL now also support source mapped stacktraces.
This release also includes many enhancements around compile times.
ClojureScript now ships with a default :optimizations setting of
:none. Implicit now when using :none is source map generation and
analysis
caching. Analysis caching significantly speeds up compile times.
The standard library (cljs.core) is now AOTed compiled to JavaScript
along with an AOTed analysis dump and an AOTed source map. This
dramatically cuts down on cold start compile times. The standard
library is never actually ever analyzed or
Re: [ANN] Reagent + Sente (+ Heroku) = Rente
Rente has been upgraded to sente 1.4.0 (breaking change). Best, Henrik On Sunday, January 18, 2015 at 1:28:50 PM UTC+1, Henrik Mohr wrote: Hi guys, If you want a sample on how to make the newest versions of Reagent, Sente (for web sockets) work together, want figwheel for ease of development, and deploy it to Heroku, take a look at my small demo project: https://github.com/enterlab/rente I use it myself as a template/basis for Proof-of-Concept projects, and plan to use it for production stuff later. Comments/feedback/suggestions/enhancements are welcome! Best, Henrik -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ClojureScript] Re: ANN: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times
On Tuesday, 10 March 2015 10:55:49 UTC, David Nolen wrote:
Looks like you're trying to use :cache-analysis with a higher :optimizations
setting than :none. I would avoid this for now.
That fixed the same problem for me. Thanks.
Also my cold compile time went down from 40s to 25s!
Thanks,
Chris
http://dev.clojure.org/jira/browse/CLJS-1103
David
On Tue, Mar 10, 2015 at 6:07 AM, Max Gonzih gon...@gmail.com wrote:
Amazing update! Yay.
But I just spotted one weird thing, after I pumped compiler version
compilation fails for me with following error:
clojure.lang.ExceptionInfo: failed compiling
file:public/javascripts/out-server-side/cljs/core.cljs {:file #File
public/javascripts/out-server-side/cljs/core.cljs}
at clojure.core$ex_info.invoke(core.clj:4403)
at cljs.compiler$compile_file$fn__2959.invoke(compiler.clj:1130)
at cljs.compiler$compile_file.invoke(compiler.clj:1101)
at cljs.closure$compile_file.invoke(closure.clj:347)
at cljs.closure$eval3294$fn__3295.invoke(closure.clj:398)
at
cljs.closure$eval3230$fn__3231$G__3221__3238.invoke(closure.clj:305)
at cljs.closure$compile_from_jar.invoke(closure.clj:390)
at cljs.closure$eval3289$fn__3290.invoke(closure.clj:404)
at
cljs.closure$eval3230$fn__3231$G__3221__3238.invoke(closure.clj:305)
at cljs.closure$get_compiled_cljs.invoke(closure.clj:467)
at cljs.closure$cljs_dependencies.invoke(closure.clj:511)
at cljs.closure$add_dependencies.doInvoke(closure.clj:533)
at clojure.lang.RestFn.applyTo(RestFn.java:139)
at clojure.core$apply.invoke(core.clj:626)
at cljs.closure$build.invoke(closure.clj:1408)
at cljs.closure$build.invoke(closure.clj:1351)
at cljsbuild.compiler$compile_cljs$fn__3665.invoke(compiler.clj:81)
at cljsbuild.compiler$compile_cljs.invoke(compiler.clj:80)
at cljsbuild.compiler$run_compiler.invoke(compiler.clj:180)
at
user$eval3797$iter__3833__3837$fn__3838$fn__3856.invoke(form-init1562646833731967415.clj:1)
at
user$eval3797$iter__3833__3837$fn__3838.invoke(form-init1562646833731967415.clj:1)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:484)
at clojure.core$seq.invoke(core.clj:133)
at clojure.core$dorun.invoke(core.clj:2855)
at clojure.core$doall.invoke(core.clj:2871)
at user$eval3797.invoke(form-init1562646833731967415.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6703)
at clojure.lang.Compiler.eval(Compiler.java:6693)
at clojure.lang.Compiler.load(Compiler.java:7130)
at clojure.lang.Compiler.loadFile(Compiler.java:7086)
at clojure.main$load_script.invoke(main.clj:274)
at clojure.main$init_opt.invoke(main.clj:279)
at clojure.main$initialize.invoke(main.clj:307)
at clojure.main$null_opt.invoke(main.clj:342)
at clojure.main$main.doInvoke(main.clj:420)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.ClassCastException: java.net.URL cannot be cast to
java.io.File
at cljs.util$mkdirs.invoke(util.clj:80)
at cljs.analyzer$write_analysis_cache.invoke(analyzer.clj:2021)
at cljs.compiler$compile_file_STAR_$fn__2927.invoke(compiler.clj:1055)
at cljs.compiler$with_core_cljs.invoke(compiler.clj:961)
at cljs.compiler$compile_file_STAR_.invoke(compiler.clj:981)
at cljs.compiler$compile_file$fn__2959.invoke(compiler.clj:1118)
... 40 more
Subprocess failed
Is this related to AOT compiler cljs.core ns?
On Tuesday, March 10, 2015 at 12:41:45 AM UTC+1, David Nolen wrote:
ClojureScript, the Clojure compiler that emits JavaScript source code.
README and source code: https://github.com/clojure/clojurescript
New release version: 0.0-3058
Leiningen dependency information:
[org.clojure/clojurescript 0.0-3058]
This is a significant enhancement release around REPLs and compile times.
All builtin REPLs (Nashorn, Node.js, Rhino and the browser REPL) now
support the helper functions normally available via clojure.repl,
these include: doc, find-doc, apropos, dir, source, and pst. All of the
builtins REPL now also support source mapped stacktraces.
This release also includes many enhancements around compile times.
ClojureScript now ships with a default :optimizations setting of
:none. Implicit
ANN: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times
Hopefully we can get that down 1s for anything except production builds.
Next on the list of todos is a shared AOT cache for all projects builds.
Once you've compiled a dependency from a JAR we should never compile it
ever again.
On Tue, Mar 10, 2015 at 9:11 AM, Chris McDevitt
christophermcdev...@gmail.com
javascript:_e(%7B%7D,'cvml','christophermcdev...@gmail.com'); wrote:
On Tuesday, 10 March 2015 10:55:49 UTC, David Nolen wrote:
Looks like you're trying to use :cache-analysis with a higher
:optimizations setting than :none. I would avoid this for now.
That fixed the same problem for me. Thanks.
Also my cold compile time went down from 40s to 25s!
Thanks,
Chris
http://dev.clojure.org/jira/browse/CLJS-1103
David
On Tue, Mar 10, 2015 at 6:07 AM, Max Gonzih gon...@gmail.com
javascript:_e(%7B%7D,'cvml','gon...@gmail.com'); wrote:
Amazing update! Yay.
But I just spotted one weird thing, after I pumped compiler version
compilation fails for me with following error:
clojure.lang.ExceptionInfo: failed compiling
file:public/javascripts/out-server-side/cljs/core.cljs {:file #File
public/javascripts/out-server-side/cljs/core.cljs}
at clojure.core$ex_info.invoke(core.clj:4403)
at cljs.compiler$compile_file$fn__2959.invoke(compiler.clj:1130)
at cljs.compiler$compile_file.invoke(compiler.clj:1101)
at cljs.closure$compile_file.invoke(closure.clj:347)
at cljs.closure$eval3294$fn__3295.invoke(closure.clj:398)
at
cljs.closure$eval3230$fn__3231$G__3221__3238.invoke(closure.clj:305)
at cljs.closure$compile_from_jar.invoke(closure.clj:390)
at cljs.closure$eval3289$fn__3290.invoke(closure.clj:404)
at
cljs.closure$eval3230$fn__3231$G__3221__3238.invoke(closure.clj:305)
at cljs.closure$get_compiled_cljs.invoke(closure.clj:467)
at cljs.closure$cljs_dependencies.invoke(closure.clj:511)
at cljs.closure$add_dependencies.doInvoke(closure.clj:533)
at clojure.lang.RestFn.applyTo(RestFn.java:139)
at clojure.core$apply.invoke(core.clj:626)
at cljs.closure$build.invoke(closure.clj:1408)
at cljs.closure$build.invoke(closure.clj:1351)
at
cljsbuild.compiler$compile_cljs$fn__3665.invoke(compiler.clj:81)
at cljsbuild.compiler$compile_cljs.invoke(compiler.clj:80)
at cljsbuild.compiler$run_compiler.invoke(compiler.clj:180)
at
user$eval3797$iter__3833__3837$fn__3838$fn__3856.invoke(form-init1562646833731967415.clj:1)
at
user$eval3797$iter__3833__3837$fn__3838.invoke(form-init1562646833731967415.clj:1)
at clojure.lang.LazySeq.sval(LazySeq.java:40)
at clojure.lang.LazySeq.seq(LazySeq.java:49)
at clojure.lang.RT.seq(RT.java:484)
at clojure.core$seq.invoke(core.clj:133)
at clojure.core$dorun.invoke(core.clj:2855)
at clojure.core$doall.invoke(core.clj:2871)
at user$eval3797.invoke(form-init1562646833731967415.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6703)
at clojure.lang.Compiler.eval(Compiler.java:6693)
at clojure.lang.Compiler.load(Compiler.java:7130)
at clojure.lang.Compiler.loadFile(Compiler.java:7086)
at clojure.main$load_script.invoke(main.clj:274)
at clojure.main$init_opt.invoke(main.clj:279)
at clojure.main$initialize.invoke(main.clj:307)
at clojure.main$null_opt.invoke(main.clj:342)
at clojure.main$main.doInvoke(main.clj:420)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.ClassCastException: java.net.URL cannot be cast to
java.io.File
at cljs.util$mkdirs.invoke(util.clj:80)
at cljs.analyzer$write_analysis_cache.invoke(analyzer.clj:2021)
at
cljs.compiler$compile_file_STAR_$fn__2927.invoke(compiler.clj:1055)
at cljs.compiler$with_core_cljs.invoke(compiler.clj:961)
at cljs.compiler$compile_file_STAR_.invoke(compiler.clj:981)
at cljs.compiler$compile_file$fn__2959.invoke(compiler.clj:1118)
... 40 more
Subprocess failed
Is this related to AOT compiler cljs.core ns?
On Tuesday, March 10, 2015 at 12:41:45 AM UTC+1, David Nolen wrote:
ClojureScript, the Clojure compiler that emits JavaScript source code.
README and source code: https://github.com/clojure/clojurescript
New release version: 0.0-3058
Leiningen dependency information:
[org.clojure/clojurescript 0.0-3058]
This is a significant enhancement
Re: GSoC 2015 - Better Clojure/Android integration project discussion
Hello, On Tue Mar 10 01:30 2015, Devang Shah wrote: Hello Daniel Thank you for the quick response. Just to clarify and see if my understanding is correct. Please correct if I am wrong. On Sunday, March 8, 2015 at 10:35:57 PM UTC-7, Daniel Solano Gómez wrote: Hello, Thanks for your interest. On Sun Mar 8 17:17 2015, Devang Shah wrote: This message is intended for suggester Daniel Solano Gómez, to initiate the discussion on the project mentioned in the subject line. Please feel free to jump in if you feel/wish to answer the questions or clarify points. I am interested in developing a plugin for the Clojure which will work in conjunction to the Android plugin. As I understand the project idea, TODO: 1. Develop functionality into the lein-droid (as an independent plugin) to support Gradle build system. 2. The new functionality has to be compatible with the current Android plugin in lein-droid. 3. Develop a superset and independent plugin to support build system and integration of Clojure and Android. 4. Since the new plugin will be integrated into the lein-driod, also modify lein-droid to support the new plugin. I think these are the right steps, as a whole, but I think I would tackle them in the following order: 1. Develop a Clojure plug-in for the Gradle-based Android build system The new clojure plug-in will be sister project of the lein-droid project implementing same features (more or less) as in lein-droid. But, for Gradle based Android project. That is, generate a Gradle project for Android with build.gradle and other files. Is that right? I am thinking of it from a slightly different point of view. First, start with a plug-in that works with Android's native Gradle-based build system. This essentially would just add Clojure compilation support for Android, but doing it in such a way so that all of Android's build features now support Clojure as well. At this point, lein-droid is a completely separate project, unaffected by these changes. 2. Examine lein-droid's features and see which can or should be handled by the Android build system other end: if required modify Android build system so that the pluin-in that is developed in step one is integrated successfully with the Android build system. Question: What is this Android build system that we refer to? The idea is this: Android moved from an Ant-based build system to a Gradle-based build system so that, amongst other features, it was more easily extendable. Thus the Clojure plug-in for Android/Gradle fits in with that philosophy. Some of the features that the new build system supports are differently configured debug/release builds. lein-droid also supports that functionality. Could we make lein-droid become a user-friendly shell around the Android build system? Clojure users are comfortable with Leiningen, so that's an important reason why lein-droid is essentail. However, lein-droid was created before the new build system, so it could potentially be even more powerful if it could leverage the Android build system by treating it as a library. I haven't fully investigated the extent to which this is feasible, but I think it's a good direction to go. This would decouple lein-droid from a lot of implementation details about how Android projects are built. Ultimately, if lein-droid could use what's in a project.clj file to generate a build.gradle file or configure the Gradle build at runtime, that should give use the best of both worlds: Clojure-friendly project definition and the full power of the native Android build infrastructure. For example, Leiningen profiles could map to Android build flavours. I hope this helps. Sincerely, DanieL 3. Rewrite bits of lein-droid to use the new build system Aside from the work on developing the Gradle plug-in, the key bits is figuring out exactly what lein-droid does and how that maps onto what the new Android build system does. Additionally, would it be possible to generate a build.gradle file from the project.clj? Questions (Project specific): 5. Can you elaborate Unfortunately, because the Android plugin replaces the Java plugin, the current Clojure plugin doesn't work for Android. What do you mean replaces the Java plugin? Gradle comes with a plug-in to compile Java. Clojuresque, the Clojure plug-in for Gradle depends on this Java plug-in. Unfortunately, the Android build system does away with the Java plug-in (the Android plug-in is in charge of compiling Java), so Clojuresque doesn't work there. This is why a new Clojure plug-in is needed. Also, can someone highlight in brief some features (of Gradle plugin) that we are planning to support? Any known features that are not supported by the current build system? Ideally, you could just include the Clojure
Re: [ClojureScript] Re: ANN: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times
Thanks David, it solved my problem! -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [OT?] Best DB/architecture for n-gram corpus?
By hard coding n-grams, do you mean using the simple string representation, e.g. aunt rhodie as the key in your database? If so, then maybe it helps to think of it from the perspective that it's not really just text, it's a string that encodes an n-gram just like [\aunt\, \rhodie\] is another way to encode an n-gram--the encoding/decoding uses clojure.string/join and clojure.string/split instead of json/write and json/read, and escaping tokens that contain spaces is on your TODO list at a low priority :) (And I think the Google n-gram corpus https://catalog.ldc.upenn.edu/LDC2006T13 uses the same format.) John On Mon, Mar 9, 2015 at 7:09 PM, Sam Raker sam.ra...@gmail.com wrote: That's interesting. I've been really reluctant to hard code n-grams, but it's probably the best way to go. On Monday, March 9, 2015 at 6:12:43 PM UTC-4, John Wiseman wrote: One thing you can do is index 1, 2, 3...n-grams and use a simple fast key-value store (like leveldb etc.) e.g., you could have entries like aunt rhodie - song-9, song-44 woman - song-12, song-65, song-96 That's basically how I made the Metafilter N-gram Viewer http://mefingram.appspot.com/, a clone of Google Books Ngram Viewer https://books.google.com/ngrams. Another possibility is using Lucene. Just be aware that Lucene calls n-grams of characters (au, un, nt) n-grams but it calls n-grams of words (that the, the old, old gray) shingles. So you would end up using (I think, I haven't done this) the ShingleFilter https://lucene.apache.org/core/4_2_0/analyzers-common/org/apache/lucene/analysis/shingle/ShingleFilter.html . You might also find this article by Russ Cox interesting, where he describes building and using an inverted trigram index: http://swtch.com/~rsc/regexp/regexp4.html John Three things that you might find interesting: Russ Cox' explanation of doing indexing and retrieval with an inverted trigram index: http://swtch.com/~rsc/regexp/regexp4.html On Sat, Mar 7, 2015 at 3:22 AM, Matching Socks phill...@gmail.com wrote: A lot of guys would use Lucene. Lucene calls n-grams of words shingles. [1] As for architecture, here is a suggestion to use Lucene to find keys to records in your real database. [2] [1] https://lucidworks.com/blog/whats-a-shingle-in-lucene-parlance/ [2] https://groups.google.com/d/msg/datomic/8yrCYxcQq34/GIomGaarX5QJ -- 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. -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Could use a better error message here (using a list in update-in)
Please file a ticket in JIRA and tag it with errormsg http://dev.clojure.org/display/community/Creating+Tickets –S On Tuesday, March 10, 2015 at 3:13:36 PM UTC, John Gabriele wrote: In Clojure v1.6.0. This one confused me when I'd accidentally passed a list in to `update-in` instead of a vector: -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [OT?] Best DB/architecture for n-gram corpus?
I more meant deciding on a maximum size and storing them qua ngrams--it seems limiting. On the other hand, after a certain size, they stop being ngrams and start being something else--texts, possibly. On Tuesday, March 10, 2015 at 1:29:44 PM UTC-4, John Wiseman wrote: By hard coding n-grams, do you mean using the simple string representation, e.g. aunt rhodie as the key in your database? If so, then maybe it helps to think of it from the perspective that it's not really just text, it's a string that encodes an n-gram just like [\aunt\, \rhodie\] is another way to encode an n-gram--the encoding/decoding uses clojure.string/join and clojure.string/split instead of json/write and json/read, and escaping tokens that contain spaces is on your TODO list at a low priority :) (And I think the Google n-gram corpus https://catalog.ldc.upenn.edu/LDC2006T13 uses the same format.) John On Mon, Mar 9, 2015 at 7:09 PM, Sam Raker sam@gmail.com javascript: wrote: That's interesting. I've been really reluctant to hard code n-grams, but it's probably the best way to go. On Monday, March 9, 2015 at 6:12:43 PM UTC-4, John Wiseman wrote: One thing you can do is index 1, 2, 3...n-grams and use a simple fast key-value store (like leveldb etc.) e.g., you could have entries like aunt rhodie - song-9, song-44 woman - song-12, song-65, song-96 That's basically how I made the Metafilter N-gram Viewer http://mefingram.appspot.com/, a clone of Google Books Ngram Viewer https://books.google.com/ngrams. Another possibility is using Lucene. Just be aware that Lucene calls n-grams of characters (au, un, nt) n-grams but it calls n-grams of words (that the, the old, old gray) shingles. So you would end up using (I think, I haven't done this) the ShingleFilter https://lucene.apache.org/core/4_2_0/analyzers-common/org/apache/lucene/analysis/shingle/ShingleFilter.html . You might also find this article by Russ Cox interesting, where he describes building and using an inverted trigram index: http://swtch.com/~rsc/regexp/regexp4.html John Three things that you might find interesting: Russ Cox' explanation of doing indexing and retrieval with an inverted trigram index: http://swtch.com/~rsc/regexp/regexp4.html On Sat, Mar 7, 2015 at 3:22 AM, Matching Socks phill...@gmail.com wrote: A lot of guys would use Lucene. Lucene calls n-grams of words shingles. [1] As for architecture, here is a suggestion to use Lucene to find keys to records in your real database. [2] [1] https://lucidworks.com/blog/whats-a-shingle-in-lucene-parlance/ [2] https://groups.google.com/d/msg/datomic/8yrCYxcQq34/GIomGaarX5QJ -- 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. -- 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 javascript: 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 javascript: 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Newify java class dynamically
Good to know thee, thank you T T!
—
Sent from Mailbox
On Mon, Mar 9, 2015 at 11:21 PM, Tassilo Horn t...@gnu.org wrote:
Juvenn Woo mach...@gmail.com writes:
I am writing a function that'll take a java class name as an arg,
wherein I'll make instance of the class. Several approaches did I try:
(let [klass Integer] (new klass 42)) ; this raises exception unable to
resolve
symbol: klass
(let [klass Integer] (.new klass 42)) ; raises no matching method found: new
for class java.lang. Class
I'm running out of ideas currently. How do you deal the use case like
this? And what's the idiomatic way to do this?
I think there's no generic predefined way to do this and you have to do
the same as what you would need to do in Java, too. I.e., use
reflection to enumerate the given class' constructors in order to find
the one you want to call (correct number and types of its arguments).
But maybe you can use something less generic in your scenario, e.g.:
--8---cut here---start-8---
(let [constructors {Integer #(Integer. %)
Long#(Long. %)
java.awt.Dimension #(java.awt.Dimension. % %)}
make (fn [type args]
(apply (constructors type) args))]
(for [cls [Integer Long java.awt.Dimension]]
(make cls 1)))
;;= (1 1 #Dimension java.awt.Dimension[width=1,height=1])
--8---cut here---end---8---
Bye,
Tassilo
--
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
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Chestnut 0.7.0
Oh, that's odd. I don't have any entries in my own user plugins for lein
new templates. (I'm assuming you meant ~/.lein/profiles.clj, right?)
Is there some reason you have them in there? lein new chestnut should
work just fine without them, but maybe I'm not understanding what you're
trying to do.
Tim
On Monday, March 9, 2015 at 6:30:48 PM UTC-4, webber wrote:
I've commented chestnut/lein-template from the ~/.lein/projects.clj as
follows, then it worked.
It worked using 0.6.0 if there was the chestnut/lein-template definition.
Was my usage wrong ?
{:user {:plugins [
[lein-try 0.4.3]
;[lein-pprint 1.1.1]
[lein-ancient 0.6.4 :exclusions
[org.clojure/core.cache]]
[lein-bikeshed 0.2.0]
[lein-ritz 0.7.0]
[lein-marginalia 0.8.0]
[http-kit/lein-template 1.0.0-SNAPSHOT]
[cider/cider-nrepl 0.9.0-SNAPSHOT]
[cljs-complete 0.1.1]
;;[chestnut/lein-template 0.7.0]
;;[chestnut/lein-template 0.6.0]
]
:dependencies [;;[nrepl-inspect 0.4.1]
[compliment 0.2.0]
[ritz/ritz-nrepl-middleware 0.7.0]
[cider/cider-nrepl 0.9.0-SNAPSHOT]
[alembic 0.2.1]
[org.clojure/tools.nrepl 0.2.7]
]
:repl-options {:nrepl-middleware
[cider.nrepl.middleware.classpath/wrap-classpath
cider.nrepl.middleware.complete/wrap-complete
cider.nrepl.middleware.info/wrap-info
cider.nrepl.middleware.inspect/wrap-inspect
cider.nrepl.middleware.stacktrace/wrap-stacktrace
cider.nrepl.middleware.trace/wrap-trace
]}
}}
Makoto
I ran into this same behavior, and then I realized it only happened if I
run the lein new command if I'm *already in* a previously-created
project created with lein new chestnut. I'm guessing that something in
the generated project.clj interferes some of the lein new behavior somehow.
At any rate, running lein new in a directory without a project.clj file in
it is working fine for me.
Tim
On Saturday, March 7, 2015 at 5:38:41 AM UTC-5, webber wrote:
I tested the v 0.7.0 of chestnut and I encountered the following error.
The v 0.6.0 works fine.
$ lein new chestnut test-app
Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.pom from
clojars
Retrieving chestnut/lein-template/0.7.0/lein-template-0.7.0.jar from
clojars
Exception in thread main java.lang.ExceptionInInitializerError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at clojure.lang.RT.loadClassForName(RT.java:2093)
at clojure.lang.RT.load(RT.java:430)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5066.invoke(core.clj:5641)
at clojure.core$load.doInvoke(core.clj:5640)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5446)
at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
at clojure.core$load_lib.doInvoke(core.clj:5485)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$load_libs.doInvoke(core.clj:5524)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$require.doInvoke(core.clj:5607)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at stencil.core$loading__4958__auto__.invoke(core.clj:1)
at stencil.core__init.load(Unknown Source)
at stencil.core__init.clinit(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at clojure.lang.RT.loadClassForName(RT.java:2093)
at clojure.lang.RT.load(RT.java:430)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__5066.invoke(core.clj:5641)
at clojure.core$load.doInvoke(core.clj:5640)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5446)
at clojure.core$load_lib$fn__5015.invoke(core.clj:5486)
at clojure.core$load_lib.doInvoke(core.clj:5485)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$load_libs.doInvoke(core.clj:5524)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:626)
at clojure.core$require.doInvoke(core.clj:5607)
at clojure.lang.RestFn.invoke(RestFn.java:512)
at leiningen.new.templates$loading__4958__auto__.invoke(templates.clj:11)
at leiningen.new.templates__init.load(Unknown Source)
at leiningen.new.templates__init.clinit(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at clojure.lang.RT.loadClassForName(RT.java:2093)
at
Re: ANN: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times
This is great, David! Is it difficult to include dependencies (e.g., core.async) for a project built this way? -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [GSoC] Mentors contact information
Hello, On Tue Mar 10 11:25 2015, Christopher Medrela wrote: Alex, Ambrose, thank you for quick answer. I'll contact you soon. I'm sorry for overlooking your mail, Ambrose. By the way, I can read at student application guidelines in project information section [1]: GSoC officially runs from 19 May–22 Aug, a period of 14 weeks. while the official GSoC website says [2]: 25 May: Students begin coding for their Google Summer of Code projects; 17 August: Suggested 'pencils down' date 21 August 19:00 UTC: Firm 'pencils down' date. [1] http://dev.clojure.org/display/community/Student+application+guidelines [2] https://www.google-melange.com/gsoc/events/google/gsoc2015 Thanks for catching that. We had last summer's dates on the application guidelines and I overlooked updating those dates. I have changed them. Sincerely, Daniel -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Could use a better error message here (using a list in update-in)
In Clojure v1.6.0. This one confused me when I'd accidentally passed a list in to `update-in` instead of a vector: ~~~ some-app.core= (update-in [:a :b :c] [1] name) [:a b :c] some-app.core= (update-in '(:a :b :c) [1] name) NullPointerException clojure.core/name (core.clj:1518) ~~~ -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [OT?] Best DB/architecture for n-gram corpus?
On 10 March 2015 at 20:03, Sam Raker sam.ra...@gmail.com wrote: That's honestly closer to what I was originally envisioning--I've never really looked into graph dbs before, but I'll check out Neo4j tonight. Do you know whether you can model multiple edges between the same nodes? Yes, certainly possible. If you go for Neo4j you have two options for Clojure: embedded (with the borneo library and reading Javadoc, or plain Java interop) or stand-alone server with REST API (with the well-documented Neocons library from Clojurewerkz). You'll also have to think about how to model which text (song) each phrase came from - likely another node type in the graph with a linking edge to the start of the phrase. Great book on Neo4j available for free download, also covers data modelling: http://neo4j.com/books/ I'd love to be able to have POS-based wildcarding as a feature, so you could search for e.g. the ADJ goose, but that's a whole other layer of stuff, so it might go in the eventually, maybe pile. Sounds like fun, but means doing some natural language processing on the input texts, which is a much more difficult problem than simply tokenizing. Ray. -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
ANN: Grafter 0.4.0 released
Grafter 0.4.0 has been released to clojars! Grafter is a data processing API for transforming, cleaning and manipulating tabular data from tabular sources such as CSV and Excel; whilst also providing simple methods of converting tabular data into linked data through a simple graph mapping DSL. There are extensive documentation and tutorials available here: http://grafter.org/ The key difference between Grafter and other projects is that it tries to perform its operations lazily, without loading datasets into memory. This streaming model means it can process datasets that are larger than available memory with some operations similar to those found in Incanter. Our initial focus has been on supporting linked data ETL, where we essentially convert a lazy-seq of rows into a lazy sequence of triples/quads. However we're slowly adding support for new use cases. In future releases we are hoping to add support for: - Other graph databases (including Datomic) - Better functional error handling - A library of composable transformations - SQL support - Better vocabulary support - More general API based on selection application. R. -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [OT?] Best DB/architecture for n-gram corpus?
On 10 March 2015 at 17:58, Sam Raker sam.ra...@gmail.com wrote: I more meant deciding on a maximum size and storing them qua ngrams--it seems limiting. On the other hand, after a certain size, they stop being ngrams and start being something else--texts, possibly. Exactly. When I first read your post, I almost suggested you model this in a graph database like Neo4j or Titan. Each word would be a node in the graph with an edge linking it to the next word in the sentence. You could define an index on the words (so retrieving all nodes for a given word would be fast), then follow edges to find and count particular n-grams. This is more complicated than the relational model I proposed, and will be a bit slower to query. But if you don't want to put an upper-bound on the length of the n-gram when you index the data, it might be the way to go. Ray. -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Project fails to compile on different machines
Hi, I have a project (unfortunately private) that uses a lot of java interop to provide Java with a seemless java-like API. On one of my development machines I can compile the project fine, but the other not. Both are set up (what I think) in the same relevant ways. Here is output compiling on the different machines: https://gist.github.com/AeroNotix/70a2d10bbb050aa0542a The lein version is 2.5.0 on both machines (I'm using the lein.sh script) Aaron -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Project fails to compile on different machines
prred correctly? I've cleaned the maven cache on both machines completely. On Wed, 11 Mar 2015 at 00:26 Ivan L ivan.laza...@gmail.com wrote: seems like a clear classnotfound error to me. make sure both environments are building from a clean state (no build caches) and that your classes are being prred correctly. -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/ topic/clojure/UtnchSngQAY/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Project fails to compile on different machines
seems like a clear classnotfound error to me. make sure both environments are building from a clean state (no build caches) and that your classes are being prred correctly. -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: GSoC 2015 - Better Clojure/Android integration project discussion
Hello Daniel Thank you for the quick response. Just to clarify and see if my understanding is correct. Please correct if I am wrong. On Sunday, March 8, 2015 at 10:35:57 PM UTC-7, Daniel Solano Gómez wrote: Hello, Thanks for your interest. On Sun Mar 8 17:17 2015, Devang Shah wrote: This message is intended for suggester Daniel Solano Gómez, to initiate the discussion on the project mentioned in the subject line. Please feel free to jump in if you feel/wish to answer the questions or clarify points. I am interested in developing a plugin for the Clojure which will work in conjunction to the Android plugin. As I understand the project idea, TODO: 1. Develop functionality into the lein-droid (as an independent plugin) to support Gradle build system. 2. The new functionality has to be compatible with the current Android plugin in lein-droid. 3. Develop a superset and independent plugin to support build system and integration of Clojure and Android. 4. Since the new plugin will be integrated into the lein-driod, also modify lein-droid to support the new plugin. I think these are the right steps, as a whole, but I think I would tackle them in the following order: 1. Develop a Clojure plug-in for the Gradle-based Android build system The new clojure plug-in will be sister project of the lein-droid project implementing same features (more or less) as in lein-droid. But, for Gradle based Android project. That is, generate a Gradle project for Android with build.gradle and other files. Is that right? 2. Examine lein-droid's features and see which can or should be handled by the Android build system other end: if required modify Android build system so that the pluin-in that is developed in step one is integrated successfully with the Android build system. Question: What is this Android build system that we refer to? 3. Rewrite bits of lein-droid to use the new build system Aside from the work on developing the Gradle plug-in, the key bits is figuring out exactly what lein-droid does and how that maps onto what the new Android build system does. Additionally, would it be possible to generate a build.gradle file from the project.clj? Questions (Project specific): 5. Can you elaborate Unfortunately, because the Android plugin replaces the Java plugin, the current Clojure plugin doesn't work for Android. What do you mean replaces the Java plugin? Gradle comes with a plug-in to compile Java. Clojuresque, the Clojure plug-in for Gradle depends on this Java plug-in. Unfortunately, the Android build system does away with the Java plug-in (the Android plug-in is in charge of compiling Java), so Clojuresque doesn't work there. This is why a new Clojure plug-in is needed. Also, can someone highlight in brief some features (of Gradle plugin) that we are planning to support? Any known features that are not supported by the current build system? Ideally, you could just include the Clojure plug-in into an Android build.gradle, and it will handle all Clojure sources similarly to Android Java sources are handled (build types, etc.). It should also present all the necessary options to configure the plug-in, such as source directory locations, Clojure compiler options, etc. It would be good to review what Clojuresque supports. Can you please elaborate the last line just include the Clojure plug-in into an Android build.gradle... ? I mean why do we want to handle all Clojure sources? If we are develop the plug-in similar to lein-droid, shouldn't it be able to generate gradle based Android project. (I am sorry, I am new to Gradle). Please correct if I understand it wrong. Questions: (GSoC application specific): 6. Where can I get the template for the application? 7. What are all the things expected to be addressed in the application. Please refer to: http://dev.clojure.org/display/community/Student+application+guidelines Again, thank you for your interest. Please feel free to post to this e-mail list and the clojure-android list for more feedback on your idea. Sincerely, Daniel Thank you. -- 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 javascript: 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 javascript: 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 javascript:. For more options, visit https://groups.google.com/d/optout.
Re: ANN: ClojureScript 0.0-3058, Enhanced REPLs, faster compile times
It says analysis caching is enabled when optimizations is :none. Do we have to enable to explicitly on other optimization levels? tirsdag 10. mars 2015 00.42.28 UTC+1 skrev David Nolen følgende: ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-3058 Leiningen dependency information: [org.clojure/clojurescript 0.0-3058] This is a significant enhancement release around REPLs and compile times. All builtin REPLs (Nashorn, Node.js, Rhino and the browser REPL) now support the helper functions normally available via clojure.repl, these include: doc, find-doc, apropos, dir, source, and pst. All of the builtins REPL now also support source mapped stacktraces. This release also includes many enhancements around compile times. ClojureScript now ships with a default :optimizations setting of :none. Implicit now when using :none is source map generation and analysis caching. Analysis caching significantly speeds up compile times. The standard library (cljs.core) is now AOTed compiled to JavaScript along with an AOTed analysis dump and an AOTed source map. This dramatically cuts down on cold start compile times. The standard library is never actually ever analyzed or compiled in your own builds. The result is particularly dramatic for REPLs. ClojureScript is also now available for the first time as a standalone AOTed JAR. The Quick Start introduction has been rewritten in terms of the standalone JAR: https://github.com/clojure/clojurescript/wiki/Quick-Start The new Quick Start is essential reading even if you are a relatively experienced ClojureScript developer. As usual feedback welcome! ## 0.0-3058 ### Enhancements * browser REPL source mapping for Firefox, Safari, Chrome * macro support in REPL special functions * CLJS-897: AOT core.cljs CLJS-899: AOT cache core.cljs analysis * CLJS-1078: Nashorn REPL should use persistent code cache * CLJS-1079: add way to execute arbitrary fn upon watch build completion * CLJS-1034: Support REPL-defined functions in stacktrace infrastructure * source mapping for Rhino * CLJS-1071: support symbol keys in :closure-defines * CLJS-1014: Support Closure Defines under :none * CLJS-1068: node target define * CLJS-1069: Generic :jsdoc support * CLJS-1030: add `cljs.repl/pst` * add `cljs.repl/apropos`, `cljs.repl/find-doc`, `cljs.repl/dir` * fix `cljs.analyzer.api/all-ns` docstring * add `cljs.analyzer.api/ns-publics` * CLJS-1055: cljs.repl/doc should support namespaces and special forms * Add ClojureScript special form doc map * CLJS-1054: add clojure.repl/source functionality to cljs.repl * CLJS-1053: REPLs need import special fn ### Changes * move :init up in cljs.repl/repl * CLJS-1087: with-out-str unexpectedly affected by *print-newline* * CLJS-1093: Better compiler defaults * Bump deps latest Closure Compiler, Rhino 1.7R5, data.json 0.2.6, tool.reader 0.8.16 * more sensible error if cljs.repl/repl arguments after the first incorrectly supplied * default REPLs to :cache-analysis true * default :output-dir for Nashorn and Node REPLs * change ES6 Map `get` support to take additional `not-found` parameter * deprecate clojure.reflect namespace now that REPLs are significantly enhanced, static vars, etc. ### Fixes * stop blowing away cljs.user in browser REPL so REPL fns/macros remain available * CLJS-1098: Browser REPL needs to support :reload and :reload-all * CLJS-1097: source map url for AOTed cljs.core is wrong * CLJS-1094: read option not used by cljs.repl/repl* * CLJS-1089: AOT analysis cache has bad :file paths * CLJS-1057: Nashorn REPL should not use EDN rep for errors * CLJS-1086: Keyword constants should have stable names * CLJS-964: Redefining exists? does not emit a warning like redefining array? does. * CLJS-937: local fn name should be lexically munged * CLJS-1082: analysis memoization bug * CLJS-978: Analysis caching doesn't account for constants table * CLJS-865: remove `cljs.js-deps/goog-resource` hack * CLJS-1077: analyze-deps infinite recursive loop * manually set *e in Rhino on JS exception * REPL options merging needs to be more disciplined * CLJS-1072: Calling .hasOwnProperty(source) in Clojurescript's string/replace will break with ES6 * CLJS-1064: ex-info is not printable * Fix REPLs emitting code into .repl directory * CLJS-1066: Rhino REPL regression * be more disciplined about ints in murmur3 code * Node.js REPL should work even if :output-dir not supplied * Nashorn environment doesn't supply console, setup printing correctly -- 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 first post. To unsubscribe from this group, send email to
Re: [ANN] Dunaj project, an alternative core API for Clojure
Third Dunaj experiment: Protocols First One of Dunaj’s objectives is to facilitate host independent style of programming. The third Dunaj experiment aims to transform core API into one that uses protocols for all of its abstractions. Additionally, Dunaj introduces a concept of a factory protocol that represents an abstraction of a constructor for an abstract data type. Protocols and protocol methods are part of the Dunaj’s interface that is oriented towards implementers of custom types and language extensions and they are documented separatedly in the SPI part of Dunaj’s documentation. Goals of the third Dunaj experiment are as follows: - Provide protocols for all existing built-in abstractions that were in Clojure specified by host interfaces. - Modify existing core functionalities to build upon protocols instead of specific types, host classes or interfaces. - Introduce a separate representation of deftypes, treating the underlying host class as an implementation detail not automatically imported into the current namespace. - Introduce a new idiom of factory protocols, which are used to represent an abstraction of a constructor for an abstract data type. As usual, you can read more about this experiment at http://www.dunaj.org Regards, Jozef On Thursday, March 5, 2015 at 10:33:53 PM UTC+1, Jozef Wagner wrote: I'm happy to announce a project called Dunaj [1], which provides an alternative core API for Clojure. Its main aim is to experimentally test major additions to the language. Dunaj /ˈdunaɪ/ is a set of core language experiments aimed to improve Clojure language and its core API. It deals with language features that require changes across different parts of Clojure and which cannot be evaluated in isolation. Dunaj aims to bring Clojure even more towards simplicity, consistency and performance. It is intended to be used by regular Clojure developers, either for application or library development. Dunaj was created to test 10 experiments that bring significant changes to the Clojure language. As there is a substantial number of additions and changes, I want to try a bit unconventional approach here. Before I'll release the actual library, I will introduce Dunaj's experiments in a series of individual posts. Every part states the motivation behind the experiment, introduces changes and additions to the language and demonstrates its intended use. If you do not want to miss any of this, you may want to register for a mailing list at [1] or follow @dunajproject at Twitter. -- Jozef Wagner [1] http://www.dunaj.org/ -- 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 first post. To unsubscribe from this group, send email to clojure+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
