Re: Clojurescript to target JVM?
Hi Adam, This is really interesting, thanks - at some point soon I'm going to be doing some performance work on Cursive, a large part of which is going to be trying to stop namespaces being loaded before they're required. This will be very useful - I'll steal your patch to log namespace loading, for a start. Very interesting proposal to separate macros out in Clojure too. Thanks, Colin On 29 January 2015 at 05:41, Adam Clements adam.cleme...@gmail.com wrote: I'm currently using the fastload branch against alpha5, and it's pretty good. You have to be careful though with namespace declarations as you may end up loading more than you need to. I'm currently in the process of breaking my app down into runlevels, where it loads the minimum needed to get started and then once that's all done and the app is responsive it starts loading the namespaces that might not be needed for a little while. I got a large chunk of my start up time back by avoiding loading all of tools.analyser for core.async (see my blog post on the subject here http://adamclements.github.io/articles/core-async-runtime-dependencies/ ). I think by doing this and being careful what you load (my build of clojure has logging turned on for when it loads/compiles individual namespaces and how long it takes repo here https://github.com/AdamClements/clojure), it should be possible to get something up and running pretty quickly. On Wed Jan 28 2015 at 16:34:52 Ashton Kemerling ashtonkemerl...@gmail.com wrote: A lot of the slowness in Clojure comes down to how slow it is to load the main namespaces that are needed, especially clojure.core (see this post http://nicholaskariniemi.github.io/2014/02/25/clojure-bootstrapping.html ). You should also look into the Clojure fastload branch, which apparently helped out a few Android programmers according to the clojure-android google list. On Friday, November 21, 2014 at 2:48:20 PM UTC-7, Alan Moore wrote: On Friday, November 21, 2014 9:50:58 AM UTC-8, Uday Verma wrote: Hello Everyone, Basically the approach is this: cljs - js - rhino [3] - bytecode. Provides java interop through rhino. By the time things get to rhino, google closure has already thrown away most of the runtime away since we didn't use it, and we end up with manageable amount of JS which is compiled to manageable amount of byte code. All of jvm is still available. Sounds like the clojure compiler could benefit from dead code elimination. I'm not sure if that is possible or not but it does sound like it might work. Compiles would probably take longer so the gains might be offset by longer compile times. If this is the case then it wouldn't help development workflows but could provide deployment/runtime gains. I'm wondering if the availability of eval in clojure and the lack of it in clojurescript makes a difference - it might lead to some code that can't be properly analyzed. Alan -- 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. -- 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
Re: Clojurescript to target JVM?
A lot of the slowness in Clojure comes down to how slow it is to load the main namespaces that are needed, especially clojure.core (see this post http://nicholaskariniemi.github.io/2014/02/25/clojure-bootstrapping.html ). You should also look into the Clojure fastload branch, which apparently helped out a few Android programmers according to the clojure-android google list. On Friday, November 21, 2014 at 2:48:20 PM UTC-7, Alan Moore wrote: On Friday, November 21, 2014 9:50:58 AM UTC-8, Uday Verma wrote: Hello Everyone, Basically the approach is this: cljs - js - rhino [3] - bytecode. Provides java interop through rhino. By the time things get to rhino, google closure has already thrown away most of the runtime away since we didn't use it, and we end up with manageable amount of JS which is compiled to manageable amount of byte code. All of jvm is still available. Sounds like the clojure compiler could benefit from dead code elimination. I'm not sure if that is possible or not but it does sound like it might work. Compiles would probably take longer so the gains might be offset by longer compile times. If this is the case then it wouldn't help development workflows but could provide deployment/runtime gains. I'm wondering if the availability of eval in clojure and the lack of it in clojurescript makes a difference - it might lead to some code that can't be properly analyzed. Alan -- 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 to target JVM?
I'm currently using the fastload branch against alpha5, and it's pretty good. You have to be careful though with namespace declarations as you may end up loading more than you need to. I'm currently in the process of breaking my app down into runlevels, where it loads the minimum needed to get started and then once that's all done and the app is responsive it starts loading the namespaces that might not be needed for a little while. I got a large chunk of my start up time back by avoiding loading all of tools.analyser for core.async (see my blog post on the subject here http://adamclements.github.io/articles/core-async-runtime-dependencies/). I think by doing this and being careful what you load (my build of clojure has logging turned on for when it loads/compiles individual namespaces and how long it takes repo here https://github.com/AdamClements/clojure), it should be possible to get something up and running pretty quickly. On Wed Jan 28 2015 at 16:34:52 Ashton Kemerling ashtonkemerl...@gmail.com wrote: A lot of the slowness in Clojure comes down to how slow it is to load the main namespaces that are needed, especially clojure.core (see this post http://nicholaskariniemi.github.io/2014/02/25/clojure-bootstrapping.html ). You should also look into the Clojure fastload branch, which apparently helped out a few Android programmers according to the clojure-android google list. On Friday, November 21, 2014 at 2:48:20 PM UTC-7, Alan Moore wrote: On Friday, November 21, 2014 9:50:58 AM UTC-8, Uday Verma wrote: Hello Everyone, Basically the approach is this: cljs - js - rhino [3] - bytecode. Provides java interop through rhino. By the time things get to rhino, google closure has already thrown away most of the runtime away since we didn't use it, and we end up with manageable amount of JS which is compiled to manageable amount of byte code. All of jvm is still available. Sounds like the clojure compiler could benefit from dead code elimination. I'm not sure if that is possible or not but it does sound like it might work. Compiles would probably take longer so the gains might be offset by longer compile times. If this is the case then it wouldn't help development workflows but could provide deployment/runtime gains. I'm wondering if the availability of eval in clojure and the lack of it in clojurescript makes a difference - it might lead to some code that can't be properly analyzed. Alan -- 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: Clojurescript to target JVM?
inline... On Thursday, January 15, 2015 at 8:47:34 AM UTC-8, Adam Clements wrote: I've been looking at getting my startup time down on my Clojure on android app (it needs to be at least an order of magnitude smaller before I can ship), and revisited this as a potential candidate. The biggest friction point was that I would have to change which libraries I use and revisit all the java interop to make it work nicely as clojurescript. - * V8 (JNI) - *I briefly considered compiling a V8 runtime to host ClojureScript. Startup speed would probably outperform the WebView. This would be a lot of work to develop a nice bridging mechanism. Object lifecycle management is better than WebView, but still not ideal. With no C++ or JNI background, I could tell very quickly that this would not be a weekend project. You might want to check out duktape: http://duktape.org/ It claims ES5 and some preliminary features from ES6. It is an interpreter so it will be slower than V8 but it would only take a day or two to get it going. Duktape is part of the IOT effort by the AllSeen Aliance (Linux Foundation) and has lots of support so I'm guessing it will be a viable tool for some time to come: https://allseenalliance.org/ https://wiki.allseenalliance.org/_media/training/programming_alljoyn.js.pdf The startup performance might be sufficient for your needs - TBD. If it doesn't work you are only out a weekend :-) I could help you with the C++ part (my day job is embedded systems C++) and I have been wanting to give duktape a try with ClojureScript anyway. Take care. Alan -- 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 to target JVM?
Hi Sam;
I'm currently trying to get some functions written in clojure(-script)
running on Android, wrapping them in a java class generated by rhino.
Currently, I'm stuck at overcoming the 64k limit. Could you explain the
splitting process in some greater detail?
All the best,
Gerrit
PS ~ Any eta on Lambdroid?
Am Samstag, 22. November 2014 04:18:21 UTC+1 schrieb Sam Beran:
The code is still half-baked, but in leu of a blog post or code, I can
summarize my reasoning and approach:
*ClojureScript is Designed With UI Responsiveness In Mind*
At present, JVM Clojure is not currently suitable for Android development.
Since Android applications are structured around ephemeral Activities,
any startup penalty over 250 ms is simply unacceptable. Current benchmarks
[1] are showing 2-5 seconds of startup time, and I have seen no
straightforward advice on how to achieve an order-of-magnitude increase in
startup performance. ClojureScript (and JavaScript) is designed from the
ground up with startup speed in mind. ClojureScript can be used to create
responsive user interfaces on Android.
*Selecting a Host Runtime*
In order to run ClojureScript on Android, I considered the following
options for host runtimes:
- *Android WebView * - we can achieve reasonable startup times with a
WebView, however any data must be serialized and deserialized in order to
communicate between a WebView and Java. Even worse, any long-running
object
lifecycles must be manually managed, since we cannot rely on garbage
collection to maintain object references between the host VM and those of
the WebView.
- *V8 (JNI) - *I briefly considered compiling a V8 runtime to host
ClojureScript. Startup speed would probably outperform the WebView. This
would be a lot of work to develop a nice bridging mechanism. Object
lifecycle management is better than WebView, but still not ideal. With no
C++ or JNI background, I could tell very quickly that this would not be a
weekend project.
- *Rhino* - Rhino is a lightweight JavaScript runtime for the JVM.
Execution speed is not fast, and since Rhino is not actively maintained,
it
will probably never support ES6 - not huge concerns for ClojureScript.
Since Rhino is a pure-Java runtime, there is very little overhead when
communicating between JS- Java, and Java GC can be used to maintain
object lifecycles.
- *Nashorn *- the successor to rhino. Not an option until Android
supports InvokeDynamic.[2]
*Achieving Fast Startup on Rhino*
When I initially ran ClojureScript on Rhino, Startup speed was around 8-10
seconds - even worse than JVM Clojure! Some quick measurements indicated
that the bulk of the time was spent with Rhino parsing the JS sources for
cljs/core.js. I was pleased to discover that Rhino supports bytecode
precompilation via the jsc utility [3]. I was able to precompile the
ClojureScript output to bytecode, and achieve *much faster startup -
around 150ms on device*. This is well within the target performance
range, and is fast enough to eliminate any noticeable UI lag.
One hurdle I ran into is the 64k method size limit for Java classes. Since
jsc compiles all .js files to a single method in a Java class, compiling
cljs/core.js caused errors when compiling to bytecode. I was able to get
around this by splitting the JS files in half during the build process
until they were small enough to compile. *I have since implemented some
optimizations which bring the startup overhead of ClojureScript down to
100 ms.*
*Pure ClojureScript Android Applications*
Since I am precompiling the ClojureScript sources, I can also generate
Java classes using ClojureScript macros. Here is an example of an Android
Activity written in ClojureScript. This activity is compiled to Java in a
similar manner to Clojure's gen-class mechanism:
(ns cljs-hello.core
(:require-macros [lambdroid.compile :refer [java-class]]))
(java-class
{:name io.lambdroid.MyActivity
:extends android.app.Activity})
(defn ^:override onCreate [this ^android.os.Bundle state]
(.onCreate this state)
(.setContentView this io.lambdroid.R.layout/activity_hello_world)
(.setText (.findViewById this io.lambdroid.R.id/message
http://io.lambdroid.r.id/message)
Hello From ClojureScript))
Note that this generated activity class is created by Android directly and
has full access to Android asset bundles, so users of this library *will
not need to write any Java whatsoever* .
*Next Steps*
There are a few things I still need to do before releasing code:
- Extract build logic into Gradle plugin - it is currently just some
build scripts in an example app.
- Build an Android REPL that can run in the context of the current
activity
- Incremental builds (cljs compile time is currently slow)
Once these are finished, I plan to
Re: Clojurescript to target JVM?
I've been looking at getting my startup time down on my Clojure on android
app (it needs to be at least an order of magnitude smaller before I can
ship), and revisited this as a potential candidate. The biggest friction
point was that I would have to change which libraries I use and revisit all
the java interop to make it work nicely as clojurescript.
This got me wondering, would a hybrid approach work? If Rhino can use java
classes, could we rework the clojurescript emitter to emit javascript
corresponding to jvm clojure with rhino's java interop? Presumably if only
the javascript primitives were used and the java objects and interop
retained, the resulting rhino compiled bytecode would be fairly reasonable?
What's more, all the var indirection could be removed and macro
transformations baked in, making it less dynamic and workable for proguard
optimisation even if google's closure compiler didn't work very well with
it.
It's a fairly roundabout approach, and it might be that it would be quicker
to just implement a static production-mode compiler for clojure and skip
the clojurescript hack, but let me know if you think there would be some
mileage in using this to get something working in the short term.
Adam
On Sat Nov 22 2014 at 04:29:47 Sam Beran sbe...@gmail.com wrote:
The code is still half-baked, but in leu of a blog post or code, I can
summarize my reasoning and approach:
*ClojureScript is Designed With UI Responsiveness In Mind*
At present, JVM Clojure is not currently suitable for Android development.
Since Android applications are structured around ephemeral Activities,
any startup penalty over 250 ms is simply unacceptable. Current benchmarks
[1] are showing 2-5 seconds of startup time, and I have seen no
straightforward advice on how to achieve an order-of-magnitude increase in
startup performance. ClojureScript (and JavaScript) is designed from the
ground up with startup speed in mind. ClojureScript can be used to create
responsive user interfaces on Android.
*Selecting a Host Runtime*
In order to run ClojureScript on Android, I considered the following
options for host runtimes:
- *Android WebView * - we can achieve reasonable startup times with a
WebView, however any data must be serialized and deserialized in order to
communicate between a WebView and Java. Even worse, any long-running object
lifecycles must be manually managed, since we cannot rely on garbage
collection to maintain object references between the host VM and those of
the WebView.
- *V8 (JNI) - *I briefly considered compiling a V8 runtime to host
ClojureScript. Startup speed would probably outperform the WebView. This
would be a lot of work to develop a nice bridging mechanism. Object
lifecycle management is better than WebView, but still not ideal. With no
C++ or JNI background, I could tell very quickly that this would not be a
weekend project.
- *Rhino* - Rhino is a lightweight JavaScript runtime for the JVM.
Execution speed is not fast, and since Rhino is not actively maintained, it
will probably never support ES6 - not huge concerns for ClojureScript.
Since Rhino is a pure-Java runtime, there is very little overhead when
communicating between JS- Java, and Java GC can be used to maintain
object lifecycles.
- *Nashorn *- the successor to rhino. Not an option until Android
supports InvokeDynamic.[2]
*Achieving Fast Startup on Rhino*
When I initially ran ClojureScript on Rhino, Startup speed was around 8-10
seconds - even worse than JVM Clojure! Some quick measurements indicated
that the bulk of the time was spent with Rhino parsing the JS sources for
cljs/core.js. I was pleased to discover that Rhino supports bytecode
precompilation via the jsc utility [3]. I was able to precompile the
ClojureScript output to bytecode, and achieve *much faster startup -
around 150ms on device*. This is well within the target performance
range, and is fast enough to eliminate any noticeable UI lag.
One hurdle I ran into is the 64k method size limit for Java classes. Since
jsc compiles all .js files to a single method in a Java class, compiling
cljs/core.js caused errors when compiling to bytecode. I was able to get
around this by splitting the JS files in half during the build process
until they were small enough to compile. *I have since implemented some
optimizations which bring the startup overhead of ClojureScript down to
100 ms.*
*Pure ClojureScript Android Applications*
Since I am precompiling the ClojureScript sources, I can also generate
Java classes using ClojureScript macros. Here is an example of an Android
Activity written in ClojureScript. This activity is compiled to Java in a
similar manner to Clojure's gen-class mechanism:
(ns cljs-hello.core
(:require-macros [lambdroid.compile :refer [java-class]]))
(java-class
{:name io.lambdroid.MyActivity
:extends
Clojurescript to target JVM?
Hello Everyone, I was at this pretty interesting meet-up yesterday where Sam Beran [1] showed how he achieved 30ms startup times on Android using Clojurescript. He was not hosting his app inside a web view, it was a native java app. We all know and understand why clojure runtime bootstrap is heavy [2]. It is definitely not feasible at all on Android, and I feel Sam is onto something here. Sam took a round about way to solve this problem which I think is incredible. I have requested Sam to write a blog post about this so that interesting rhetoric can begin. Basically the approach is this: cljs - js - rhino [3] - bytecode. Provides java interop through rhino. By the time things get to rhino, google closure has already thrown away most of the runtime away since we didn't use it, and we end up with manageable amount of JS which is compiled to manageable amount of byte code. All of jvm is still available. I do feel that having JS as an intermediate layer has certain disadvantages when we want to target jvm (e.g. threading), but overall I wanted to get a feel of what everyone thinks about this, may be insights into this as to why this is or isn't a great idea. I understand that I am not doing justice to Sam's efforts here by mentioning it in just one line above, but I am hoping a more detailed blog post will help! I have a feeling that this approach can do certain things for me and the Clojure community in general: - Makes it easy to sell adoptability to people, write code once, run on Web or JVM (what JS sort of does with node.js). - Fast startup times mean that we can write single shot command line apps and short lifespan programs, right now Clojure bootup is a major thing holding at least me back from doing this. Oh man its takes forever to run. - May be we can figure how to convert existing investment and effort spent into writing Clojure libraries into this approach? Looking forward to hearing back. Relevant twitter thread: https://twitter.com/samberan/status/523929208595025920 Thanks, Uday [1] https://twitter.com/samberan [2] http://nicholaskariniemi.github.io/2014/02/25/clojure-bootstrapping.html [3] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/JavaScript_Compiler -- 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 to target JVM?
I too was intrigued by this and cobbled together a quick test to see if this made it possible to create command-line apps that start up more quickly [1]. It appears that this is indeed the case, but, of course you still need to pay JVM startup time. I was also interested in what Sam Beran accomplished, wishing the same approach was available in iOS. I haven't thought of a clean way to do it and simply load the JS into JavaScriptCore [2], paying several hundred milliseconds at startup, which would be nice to eliminate. The main aspect of all of this appears to be the whole-program optimization aspect eliminating lots of unnecessary code. I'm currently wondering if this is on the plate for Clojure 7. [1] https://github.com/mfikes/cljs-cl [2] https://github.com/mfikes/goby -- 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 to target JVM?
Really interested by this. The startup time has always been a big no-no every time I was tempted to use Clojure on Android. On Friday, November 21, 2014 12:50:58 PM UTC-5, Uday Verma wrote: Hello Everyone, I was at this pretty interesting meet-up yesterday where Sam Beran [1] showed how he achieved 30ms startup times on Android using Clojurescript. He was not hosting his app inside a web view, it was a native java app. We all know and understand why clojure runtime bootstrap is heavy [2]. It is definitely not feasible at all on Android, and I feel Sam is onto something here. Sam took a round about way to solve this problem which I think is incredible. I have requested Sam to write a blog post about this so that interesting rhetoric can begin. Basically the approach is this: cljs - js - rhino [3] - bytecode. Provides java interop through rhino. By the time things get to rhino, google closure has already thrown away most of the runtime away since we didn't use it, and we end up with manageable amount of JS which is compiled to manageable amount of byte code. All of jvm is still available. I do feel that having JS as an intermediate layer has certain disadvantages when we want to target jvm (e.g. threading), but overall I wanted to get a feel of what everyone thinks about this, may be insights into this as to why this is or isn't a great idea. I understand that I am not doing justice to Sam's efforts here by mentioning it in just one line above, but I am hoping a more detailed blog post will help! I have a feeling that this approach can do certain things for me and the Clojure community in general: - Makes it easy to sell adoptability to people, write code once, run on Web or JVM (what JS sort of does with node.js). - Fast startup times mean that we can write single shot command line apps and short lifespan programs, right now Clojure bootup is a major thing holding at least me back from doing this. Oh man its takes forever to run. - May be we can figure how to convert existing investment and effort spent into writing Clojure libraries into this approach? Looking forward to hearing back. Relevant twitter thread: https://twitter.com/samberan/status/523929208595025920 Thanks, Uday [1] https://twitter.com/samberan [2] http://nicholaskariniemi.github.io/2014/02/25/clojure-bootstrapping.html [3] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/JavaScript_Compiler -- 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 to target JVM?
Awesome! Thanks for setting up that little playground with your cljs-cl project, Mike, I am going to use that to explore some stuff as well! On Friday, November 21, 2014 12:13:01 PM UTC-6, Frozenlock wrote: Really interested by this. The startup time has always been a big no-no every time I was tempted to use Clojure on Android. On Friday, November 21, 2014 12:50:58 PM UTC-5, Uday Verma wrote: Hello Everyone, I was at this pretty interesting meet-up yesterday where Sam Beran [1] showed how he achieved 30ms startup times on Android using Clojurescript. He was not hosting his app inside a web view, it was a native java app. We all know and understand why clojure runtime bootstrap is heavy [2]. It is definitely not feasible at all on Android, and I feel Sam is onto something here. Sam took a round about way to solve this problem which I think is incredible. I have requested Sam to write a blog post about this so that interesting rhetoric can begin. Basically the approach is this: cljs - js - rhino [3] - bytecode. Provides java interop through rhino. By the time things get to rhino, google closure has already thrown away most of the runtime away since we didn't use it, and we end up with manageable amount of JS which is compiled to manageable amount of byte code. All of jvm is still available. I do feel that having JS as an intermediate layer has certain disadvantages when we want to target jvm (e.g. threading), but overall I wanted to get a feel of what everyone thinks about this, may be insights into this as to why this is or isn't a great idea. I understand that I am not doing justice to Sam's efforts here by mentioning it in just one line above, but I am hoping a more detailed blog post will help! I have a feeling that this approach can do certain things for me and the Clojure community in general: - Makes it easy to sell adoptability to people, write code once, run on Web or JVM (what JS sort of does with node.js). - Fast startup times mean that we can write single shot command line apps and short lifespan programs, right now Clojure bootup is a major thing holding at least me back from doing this. Oh man its takes forever to run. - May be we can figure how to convert existing investment and effort spent into writing Clojure libraries into this approach? Looking forward to hearing back. Relevant twitter thread: https://twitter.com/samberan/status/523929208595025920 Thanks, Uday [1] https://twitter.com/samberan [2] http://nicholaskariniemi.github.io/2014/02/25/clojure-bootstrapping.html [3] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/JavaScript_Compiler -- 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 to target JVM?
On Friday, November 21, 2014 9:50:58 AM UTC-8, Uday Verma wrote: Hello Everyone, Basically the approach is this: cljs - js - rhino [3] - bytecode. Provides java interop through rhino. By the time things get to rhino, google closure has already thrown away most of the runtime away since we didn't use it, and we end up with manageable amount of JS which is compiled to manageable amount of byte code. All of jvm is still available. Sounds like the clojure compiler could benefit from dead code elimination. I'm not sure if that is possible or not but it does sound like it might work. Compiles would probably take longer so the gains might be offset by longer compile times. If this is the case then it wouldn't help development workflows but could provide deployment/runtime gains. I'm wondering if the availability of eval in clojure and the lack of it in clojurescript makes a difference - it might lead to some code that can't be properly analyzed. Alan -- 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 to target JVM?
The code is still half-baked, but in leu of a blog post or code, I can
summarize my reasoning and approach:
*ClojureScript is Designed With UI Responsiveness In Mind*
At present, JVM Clojure is not currently suitable for Android development.
Since
Android applications are structured around ephemeral Activities, any
startup penalty over 250 ms is simply unacceptable. Current benchmarks [1]
are showing 2-5 seconds of startup time, and I have seen no straightforward
advice on how to achieve an order-of-magnitude increase in startup
performance. ClojureScript (and JavaScript) is designed from the ground up
with startup speed in mind. ClojureScript can be used to create responsive
user interfaces on Android.
*Selecting a Host Runtime*
In order to run ClojureScript on Android, I considered the following
options for host runtimes:
- *Android WebView * - we can achieve reasonable startup times with a
WebView, however any data must be serialized and deserialized in order to
communicate between a WebView and Java. Even worse, any long-running object
lifecycles must be manually managed, since we cannot rely on garbage
collection to maintain object references between the host VM and those of
the WebView.
- *V8 (JNI) - *I briefly considered compiling a V8 runtime to host
ClojureScript. Startup speed would probably outperform the WebView. This
would be a lot of work to develop a nice bridging mechanism. Object
lifecycle management is better than WebView, but still not ideal. With no
C++ or JNI background, I could tell very quickly that this would not be a
weekend project.
- *Rhino* - Rhino is a lightweight JavaScript runtime for the JVM.
Execution speed is not fast, and since Rhino is not actively maintained, it
will probably never support ES6 - not huge concerns for ClojureScript.
Since Rhino is a pure-Java runtime, there is very little overhead when
communicating between JS- Java, and Java GC can be used to maintain
object lifecycles.
- *Nashorn *- the successor to rhino. Not an option until Android
supports InvokeDynamic.[2]
*Achieving Fast Startup on Rhino*
When I initially ran ClojureScript on Rhino, Startup speed was around 8-10
seconds - even worse than JVM Clojure! Some quick measurements indicated
that the bulk of the time was spent with Rhino parsing the JS sources for
cljs/core.js. I was pleased to discover that Rhino supports bytecode
precompilation via the jsc utility [3]. I was able to precompile the
ClojureScript output to bytecode, and achieve *much faster startup - around
150ms on device*. This is well within the target performance range, and is
fast enough to eliminate any noticeable UI lag.
One hurdle I ran into is the 64k method size limit for Java classes. Since
jsc compiles all .js files to a single method in a Java class, compiling
cljs/core.js caused errors when compiling to bytecode. I was able to get
around this by splitting the JS files in half during the build process
until they were small enough to compile. *I have since implemented some
optimizations which bring the startup overhead of ClojureScript down to
100 ms.*
*Pure ClojureScript Android Applications*
Since I am precompiling the ClojureScript sources, I can also generate Java
classes using ClojureScript macros. Here is an example of an Android
Activity written in ClojureScript. This activity is compiled to Java in a
similar manner to Clojure's gen-class mechanism:
(ns cljs-hello.core
(:require-macros [lambdroid.compile :refer [java-class]]))
(java-class
{:name io.lambdroid.MyActivity
:extends android.app.Activity})
(defn ^:override onCreate [this ^android.os.Bundle state]
(.onCreate this state)
(.setContentView this io.lambdroid.R.layout/activity_hello_world)
(.setText (.findViewById this io.lambdroid.R.id/message
http://io.lambdroid.r.id/message)
Hello From ClojureScript))
Note that this generated activity class is created by Android directly and
has full access to Android asset bundles, so users of this library *will
not need to write any Java whatsoever* .
*Next Steps*
There are a few things I still need to do before releasing code:
- Extract build logic into Gradle plugin - it is currently just some
build scripts in an example app.
- Build an Android REPL that can run in the context of the current
activity
- Incremental builds (cljs compile time is currently slow)
Once these are finished, I plan to release Lambdroid under a permissive
license.
*ClojureScript JVM Applications?*
As Uday and Mike have alluded, this appriach could potentially be used to
run applications on the JVM as well. This would be ideal for CLI
applications and development. However, due to the many differences between
CLJS and Clojure[4], I think this might be difficult to write the necessary
shims to get something like Leiningen running on Clojurescript. Also, I
think Nashorn
