Clojurescript to target JVM?

[Uday Verma]

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?

[Mike Fikes]

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?

[Frozenlock]

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?

[Uday Verma]

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?

[Alan Moore]

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?

[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 
)
"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 
thi

Re: Clojurescript to target JVM?

[Adam Clements]

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

Re: Clojurescript to target JVM?

[Gerrit Begher]

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

Re: Clojurescript to target JVM?

[Alan Moore]

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?

[Ashton Kemerling]

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 

). 

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?

[Adam Clements]

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

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 ), it
should be possible to get something up and running pretty quickly.

On Wed Jan 28 2015 at 16:34:52 Ashton Kemerling 
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
> 
> ).
>
> 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?

[Colin Fleming]

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  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
> 
> ).
>
> 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 ),
> it should be possible to get something up and running pretty quickly.
>
>
> On Wed Jan 28 2015 at 16:34:52 Ashton Kemerling 
> 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
>> 
>> ).
>>
>> 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 
"Cloj