Contributors needed for Rouge (Clojure on Ruby)

[gvim]

I have recently moved most of my work to Clojure and Clojurescript but
neither of these implementations seem suitable for non-http scripting,
for which I currently use Ruby. So, you can imagine my elation when I
discovered Rouge which is Clojure implemented on Ruby:

https://github.com/rouge-lang/rouge

The project looks fantastic but they seem to be short of contributors.
My programming skills are nowhere near advanced enough to work on this
myself so, please, if any of you Clojurians have proficiency in Ruby and
Clojure please consider contributing.

I looked at Python's Hy (hylang.org) which is an excellent project in
its own right and is heavily influenced by Clojure but its taregt is
generic Lisp 1 rather than Clojure. Rouge will enable Clojure to occupy
the non-http scripting space without competing directly with Clojure and
Clojurescript.

gvim

[Hajime Branko Yamasaki Vukelic]

On Sat, Jan 4, 2014 at 3:43 PM, gvim <gvi...@gmail.com> wrote:
> I looked at Python's Hy (hylang.org) which is an excellent project in its
> own right and is heavily influenced by Clojure but its taregt is generic
> Lisp 1 rather than Clojure. Rouge will enable Clojure to occupy the non-http
> scripting space without competing directly with Clojure and Clojurescript.

FYI, there's also Clojure-Py https://github.com/halgari/clojure-py


--
Branko
bra...@brankovukelic.com

/dev/blog: brankovukelic.com

[gaz jones]

Why not just use Ruby or (my preference) Python? Both are great for quick CLI apps / scripts. Best tool for the job, and all that?

--
--
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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gvim]

On 04/01/2014 17:28, gaz jones wrote:
> Why not just use Ruby or (my preference) Python? Both are great for
> quick CLI apps / scripts. Best tool for the job, and all that?
>

A Clojure layer on top of Ruby means less context switching which works
better for me as the Lisp mindset is very different from Ruby or Python.
However, I just looked at the Rouge docs and very little seems to have
been implemented so maybe it's dying. If so, I'll go with Hy which looks
much more mature.

gvim

[gvim]

On 04/01/2014 15:01, Hajime Branko Yamasaki Vukelic wrote:
>
> FYI, there's also Clojure-Py https://github.com/halgari/clojure-py
>

This looks like the best of the scripting language implementations of
Clojure in that it attempts to match the JVM implementation on PyPy.
Sadly, however, there doesn't seem to have been any activity since last
April so it may be a dead project.

gvim

[Hajime Branko Yamasaki Vukelic]

Could be. I just got into Clojure, so I haven't actually tried it yet.
Just stumbled upon it the other day.

[Michael Gardner]

On Jan 4, 2014, at 11:52 , gvim <gvi...@gmail.com> wrote:

> This looks like the best of the scripting language implementations of Clojure in that it attempts to match the JVM implementation on PyPy. Sadly, however, there doesn't seem to have been any activity since last April so it may be a dead project.

It’s dead, Jim [1]. Hopefully the landscape for alternative Clojure hosts will improve with the completion of CinC [2].

[1] https://groups.google.com/d/msg/clojure-py-dev/HbeNEkIG23U/61rN0wR2qDwJ
[2] https://github.com/Bronsa/CinC

[Glen Mailer]

Have you looked into running clojurescript on Node.js?

This should be a reasonable environment for command line scripting

[John Gabriele]

On Saturday, January 4, 2014 1:12:12 PM UTC-5, Michael Gardner wrote:

> Hopefully the landscape for alternative Clojure hosts will improve with the completion of CinC [2].

[2] https://github.com/Bronsa/CinC

Looks like CinC is now:

  * https://github.com/clojure/tools.analyzer
  * https://github.com/clojure/tools.analyzer.jvm
  * https://github.com/clojure/tools.emitter.jvm

This may be the topic for another thread, but could anyone please summarize: Do these libs provide a path forward for a native compiled Clojure? If so, what would that path be? (Ex. a tools.emitter.c? tools.emitter.llvm?)

[Timothy Baldridge]

Sure, anyone can go and write an emitter using these tools, but this doesn't solve the issues of a good type system, GC, JIT, etc. These tools make it easier to make any Clojure implementation self hosting, but those impls still need a good foundation to build on, and that's the hard part. 

Timothy

--
--
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/groups/opt_out.

--
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[Mikera]

I'm somewhat sceptical of the value of trying to build a native-compiled Clojure. It is certainly theoretically possible, but making a *good* native Clojure implementation would require:

1. A really good garbage collector (for persistent data structures, lazy sequences etc.)

2. Excellent concurrency / multi-threading support with a robust concurrent memory model

3. Some sort of underlying object model / type system

4. A fast dynamic JIT compiler to recompile code in the running environment

5. A rich set of standard libraries (for collections, numerical tower etc.)

This means reinventing something effectively equivalent to the JVM..... except it wouldn't have the benefit of years of fine tuning and a huge cross-platform library ecosystem. Sounds like a backwards step to me.

[Joel Holdbrooks]

As one of the original contributors to Rouge I will definitely agree that it does need a lot of work. That being said, if there's interest and pull requests are submitted the original author or myself typically chime in. Both of us have been busy with other projects/life and haven't done much work on it in quite some time.

While Rouge itself is not 100% compatible with Clojure or complete, I certainly would recommend it over Hy for simple tasks and for the maintainers understanding of both Clojure and Lisp idioms. As far as I can tell, the Hy team seems more or less interested in a Pythonic Lisp. There was a huge debate, for instance, over whether or not 0, [], {}, (), and "" should be considered truthy in Hy which. If you ask me, that alone is a reason not to consider it unless, of course, you are looking for that.

Beside the topic, there is a Ruby library that includes implementations of various persistent data structures. Since I head about it I thought it would be nice to use those instead of the `freeze`ing of Ruby's data structures you see in Rouge currently. It would definitely be worth the effort/discussion and I'm sure Rouge would be open to that.

[Joel Holdbrooks]

As a suffix to my last reply; if Hy were capable of delivering acceptable truthy semantics and persistent data structures, I might recommend it.

On Saturday, January 4, 2014 9:44:08 AM UTC-8, g vim wrote:

[Russell Christopher]

I wonder if Go could be a good substrate for native-compiled Clojure.

--

[john walker]

If boot time is your primary concern, this can help. The jvm is still there, though :/

https://github.com/technomancy/grenchman

[Rich Morin]

On Jan 4, 2014, at 06:43, gvim wrote:
> I have recently moved most of my work to Clojure and ClojureScript but

> neither of these implementations seem suitable for non-http scripting,
> for which I currently use Ruby. So, you can imagine my elation when I
> discovered Rouge which is Clojure implemented on Ruby:

This might be of interest:

Clojure to Objective-C compiler
https://github.com/joshaber/clojurem

It's not Ruby, but the start-up time should be better than on the JVM.
It might also be possible to link in MacRuby liobraries, etc.

-r

--
http://www.cfcl.com/rdm Rich Morin r...@cfcl.com
http://www.cfcl.com/rdm/resume San Bruno, CA, USA +1 650-873-7841

Software system design, development, and documentation

[Max Gonzih]

Al this conversation still gives me hope that there is room for clojure on bare metal implementation. There is https://github.com/halgari/clojure-metal but I'm not sure about its state.

[Laurent PETIT]

Is it possible that a lot of these projects are waiting for a stronger blessing of the clojure contrib efforts for analyzers, etc. that is, waiting for the JVM Clojure in Clojure.

2014/1/8 Max Gonzih <gon...@gmail.com>

--

[Max Gonzih]

Probably you are right.

> 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/26X7Bj5_KUQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.

--
Best regards,
Max

[Mikera]

Cool link, thanks! Yet another clever tool.....

The JVM isn't really the problem though, at least as far as I can work out. In fact I think the whole "JVM startup is slow" thing is a bit of a myth: JVM startup including running a simple "hello world" is less than 0.1 secs on my machine. Obviously not as quick as native compiled code, but "good enough" for typical command line usage.

I'm pretty sure that loading a big dependency graph of clojure.core + require'd Clojure libraries is the real startup time culprit for most Clojure apps (which gives me hope, since it means there is still potential for significant improvements, either via pre-compilation, lazy loading of namespaces, concurrent loading or general compiler/reader optimisations)

[Laurent PETIT]

2014/1/8 Mikera <mike.r.an...@gmail.com>

Cool link, thanks! Yet another clever tool.....

The JVM isn't really the problem though, at least as far as I can work out. In fact I think the whole "JVM startup is slow" thing is a bit of a myth: JVM startup including running a simple "hello world" is less than 0.1 secs on my machine. Obviously not as quick as native compiled code, but "good enough" for typical command line usage.

I'm pretty sure that loading a big dependency graph of clojure.core + require'd Clojure libraries is the real startup time culprit for most Clojure apps (which gives me hope, since it means there is still potential for significant improvements, either via pre-compilation, lazy loading of namespaces, concurrent loading or general compiler/reader optimisations)

As far as I can remember, Rich had made some experiments, at some point in time, wrt lazy compilation of fns. Meaning that you still had the linear time eagerly skimming all your app's dependency namespaces at startup, but at least, the work done eagerly was just defining vars, and executing top level code (including macros).

AFAICT at some point he decided to revert back, but I don't remember the exact reason (something like : nobody reported feedback, and we were close to a clojure release, so it was not interesting to pursue this goal at that time).

One can probably still find relevant commits in Git revisions, as well as traces of the discussion in the mailing list archives.

Cheers,

--
Laurent

 

On Monday, 6 January 2014 04:14:20 UTC, john walker wrote:

If boot time is your primary concern, this can help. The jvm is still there, though :/

https://github.com/technomancy/grenchman


On Saturday, January 4, 2014 9:43:22 AM UTC-5, g vim wrote:

I have recently moved most of my work to Clojure and Clojurescript but
neither of these implementations seem suitable for non-http scripting,
for which I currently use Ruby. So, you can imagine my elation when I
discovered Rouge which is Clojure implemented on Ruby:

https://github.com/rouge-lang/rouge

The project looks fantastic but they seem to be short of contributors.
My programming skills are nowhere near advanced enough to work on this
myself so, please, if any of you Clojurians have proficiency in Ruby and
Clojure please consider contributing.

I looked at Python's Hy (hylang.org) which is an excellent project in
its own right and is heavily influenced by Clojure but its taregt is
generic Lisp 1 rather than Clojure. Rouge will enable Clojure to occupy
the non-http scripting space without competing directly with Clojure and
Clojurescript.

gvim

--

[Alex Miller]

I have a task on my infinite todo list to analyze these load times. I know that Tim B has done a bit of work on it in the past too. Rich has mentioned it to me a couple times so I know it's something he's concerned about.

Alex

[John Gabriele]

On Wednesday, January 8, 2014 7:17:35 AM UTC-5, Mikera wrote:

The JVM isn't really the problem though, at least as far as I can work out. In fact I think the whole "JVM startup is slow" thing is a bit of a myth: JVM startup including running a simple "hello world" is less than 0.1 secs on my machine.

For a tiny Java-only command-line program, startup time is very quick.

For a tiny Clojure uberjar, startup time on my desktop is about a second. Tolerable.

A `lein run` in a tiny project takes a little over 2 seconds. To start up a `lein repl`, it takes around 3 seconds, or 5 seconds if I'm within a project (longer for a cold start). Those places, I think, is where most complaints lie regarding startup time. (This is all without using grenchman.)

Regardless though, I still think there would be value in a small-footprint natively-compiled Clojure with easy access to C libraries. Even without a JIT and without Java's expansive standard library. But, point taken about how much work the rest of the foundation would require.

[Jim - FooBar();]

On 08/01/14 14:38, John Gabriele wrote:
> For a tiny Clojure uberjar, startup time on my desktop is about a
> second. Tolerable.

well, a tiny Clojure/Swing uberjar on the raspberry-pi (oracle-java7)
takes 9-12 seconds to start!!! not so tolerable...
in fact, in the absence of a splash screen, the user has the quite
convincing illusion that nothing is happening!!!

this of course doesn't mean anything, I just thought it is worth
mentioning...

Jim

[Timothy Baldridge]

That's actually a major issue for those wanting to use Clojure to work on a RPi or similar low end system. These systems are also so memory constrained, that last I checked, the CLJS compiler wouldn't run too well on them either. Now that doesn't stop people from using Node.js to run CLJS code once it's compiled and copied to the device, but still, not exactly the ideal solution. 

Timothy

--
--
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+unsubscribe@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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Laurent PETIT]

What Mikera probably wants to demonstrate, and I agree with him, is that the slow startup time not being due to JVM proper, it's in the current implementation of Clojure that you must find what to do.

If you port Clojure piece by piece to another technology, you will probably get the same startup time problems ... minus the 0.1s taken by the JVM to start.

The good news is that if it's not the JVM startup the problem, then you can work on a better way of compiling Clojure code on the JVM ... no need to change your target !

2014/1/8 John Gabriele <jmg...@gmail.com>

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to

clojure+u...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
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.

[Jim - FooBar();]

Anyone who owns a RPi can go into the Pi-store and download MultiSnake to get a feeling of the problem...MultiSnake is basically a polished version of Stuart Halloway's snake game first featured in the book "Programming Clojure", with the major features you would expect from a snake game included and no reflection (well there is one place where I cannot get rid of reflection)...

If I remember correctly `lein repl` takes close to 55 seconds to show...clojure-py beats everything, hands down with respect to startup times...

Jim



On 08/01/14 15:46, Timothy Baldridge wrote:

That's actually a major issue for those wanting to use Clojure to work on a RPi or similar low end system. These systems are also so memory constrained, that last I checked, the CLJS compiler wouldn't run too well on them either. Now that doesn't stop people from using Node.js to run CLJS code once it's compiled and copied to the device, but still, not exactly the ideal solution.�

Timothy

On Wed, Jan 8, 2014 at 8:43 AM, Jim - FooBar(); <jimpi...@gmail.com> wrote:

On 08/01/14 14:38, John Gabriele wrote:

For a tiny Clojure uberjar, startup time on my desktop is about a second. Tolerable.

well, a tiny Clojure/Swing uberjar on the raspberry-pi (oracle-java7) takes 9-12 seconds to start!!! not so tolerable...
in fact, in the absence of a splash screen, the user has the quite convincing illusion that nothing is happening!!!

this of course doesn't mean anything, I just thought it is worth mentioning...

Jim

--
--
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/groups/opt_out.

--
�One of the main causes of the fall of the Roman Empire was that�lacking zero�they had no way to indicate successful termination of their C programs.�
(Robert Firth)

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

[Timothy Baldridge]

And even clojure-py is miles behind stock python. 

One of the problems with Clojure as it stands now is that there is just way too much init work that has to be done on every startup. Just as a comparison, let's compare how python code and clojure code is loaded:

Python:

1) look for a pyc file (often exists for library code)
2) load pyc code, and "parse". This parsing is basically creating C structs that line up with the file. That is to say, pyc code is basically a memory dump of a module. The actual format of this code is interpreter specific. At this point, all literals are instantiated and ready to go. 

4) run the loaded bytecode. Since all literals are loaded and ready, very little extra work needs to be done. 

Clojure:
1) Load the clojure compiler
2) Parse a .clj text file
3) analyze and compile the resulting code
4) generate classes for the code. 
5) call the init method for each namespace. 
6) sometime in here all the functions you're are going to need are init-ed. This means all static members need to be fulfilled. This means that every var in every function has to be resolved and interned. Every constant needs to be created. 
7) Now the code can run. 

8) ... somewhere in here JITing happens. 

What makes this worse is that parts of Clojure may not be properly profiled by the JIT. In one benchmark I ran I saw a 2x speed-up loading files after the compiler was properly warmed up. 

What we see here is the difference between a VM designed for a language, and one designed for a different language. In Python constants are just dumped to/from disk during compilation and loading. In Clojure these constants have to be recreated each time. In order to avoid cross platform issues, many people avoid AOT compilation at all costs (and rightfully so, it's a ugly beast), but this then adds parse/analyzer/compiler costs to the entire process.

All this results in the following:

time python -c "1"

real 0m0.019s

user 0m0.011s

sys 0m0.007s

time java -jar clojure-1.6.0-alpha3.jar -e "1"

1

real 0m1.135s

user 0m1.525s

sys 0m0.086s

Now most of the time I really don't care, I have a beefy dev machine, and so I simply load up a repl and keep it up all day. But I understand that these limitations also keep Clojure from reaching into other more constrained environments. 

Anyway, that's my personal take on the subject. It's a trade-off. The JVM is nice, but it's dang hard to get fast startup times with it. 

Timothy 

On Wed, Jan 8, 2014 at 8:56 AM, Jim - FooBar(); <jimpi...@gmail.com> wrote:

Anyone who owns a RPi can go into the Pi-store and download MultiSnake to get a feeling of the problem...MultiSnake is basically a polished version of Stuart Halloway's snake game first featured in the book "Programming Clojure", with the major features you would expect from a snake game included and no reflection (well there is one place where I cannot get rid of reflection)...

If I remember correctly `lein repl` takes close to 55 seconds to show...clojure-py beats everything, hands down with respect to startup times...

Jim

On 08/01/14 15:46, Timothy Baldridge wrote:

That's actually a major issue for those wanting to use Clojure to work on a RPi or similar low end system. These systems are also so memory constrained, that last I checked, the CLJS compiler wouldn't run too well on them either. Now that doesn't stop people from using Node.js to run CLJS code once it's compiled and copied to the device, but still, not exactly the ideal solution. 

Timothy

On Wed, Jan 8, 2014 at 8:43 AM, Jim - FooBar(); <jimpi...@gmail.com> wrote:

On 08/01/14 14:38, John Gabriele wrote:

For a tiny Clojure uberjar, startup time on my desktop is about a second. Tolerable.

well, a tiny Clojure/Swing uberjar on the raspberry-pi (oracle-java7) takes 9-12 seconds to start!!! not so tolerable...
in fact, in the absence of a splash screen, the user has the quite convincing illusion that nothing is happening!!!

this of course doesn't mean anything, I just thought it is worth mentioning...

Jim

--
--
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/groups/opt_out.

--

“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

--
--
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/groups/opt_out.

--
--
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/groups/opt_out.

--
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[Max Gonzih]

I do lot of hacking on embed devices like Pi and BeagleBone for fun, I
run clojure mostly on ejre and it is much faster and memory efficient than openjdk
compiled for ARM, but still suffers from startup time (in Pi case it actually much worse).
Also ejre in development right now, so sometimes it crashes.
Things like drip are helpful, but still clojure.jar takes some time to load.
Also cached jvm can give you unexpected errors in rare cases.
I tried node.js but wasn't very satisfied with results.
Basically node.js can be much slower in some
cases, memory usage isn't ideal but startup time is good. I'm not big
fan of node.js as a platform, so I still looking forward to something
closer to metal (like yours clojure-metal project).

> > 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/groups/opt_out.
> >
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>

> --
> --
> 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 a topic in the Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/26X7Bj5_KUQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.

--

Best regards,
Max

[Jim - FooBar();]

I would recommend the newly available through official Pi channels,
oracle-java7-jdk...It is a full distribution of JIT'ed Java (including
Swing) with hardware-floating point arithmetic. I think the jdk8-ea
(early access) is a tiny bit faster but not complete (no Swing). I think
openJDK has not JIT.

Jim

>> �One of the main causes of the fall of the Roman Empire was that�lacking
>> zero�they had no way to indicate successful termination of their C
>> programs.�

[Max Gonzih]

How is it different from http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html ?

> >>“One of the main causes of the fall of the Roman Empire was that–lacking
> >>zero–they had no way to indicate successful termination of their C
> >>programs.”

[Softaddicts]

We run on small nodes with g540 cpus 4gig Ram and raid 1 SSDs.
Not very powerful machines. Startup times are around 3/4 seconds

AOT cuts the startup issue of our code significantly, we are thinking about
doing the same for all clojure source dependencies (shipping both
the code and the source).

Hard for us to qualify AOT as being an ugly beast,
unsuitable for development certainly but for deployment ?

Please clarify :)

Luc P.

Softaddicts<lprefo...@softaddicts.ca> sent by ibisMail from my ipad!

[Jim - FooBar();]

I think that is the one in the repos, but update 40 instead of 45...I
had no idea it was called `ejre` as I used to use jdk-ea and switched to
7 a couple of months ago through the official rasbian channels .

Jim

>>>> �One of the main causes of the fall of the Roman Empire was that�lacking
>>>> zero�they had no way to indicate successful termination of their C
>>>> programs.�

[Max Gonzih]

Well it's actually cool that this is inside Raspbian channels.

> >>>>“One of the main causes of the fall of the Roman Empire was that–lacking
> >>>>zero–they had no way to indicate successful termination of their C
> >>>>programs.”

[Jim - FooBar();]

indeed :)

[gvim]

On 08/01/2014 15:56, Jim - FooBar(); wrote:
> If I remember correctly `lein repl` takes close to 55 seconds to
> show...clojure-py beats everything, hands down with respect to startup
> times...

However, Clojure-Py is now a dead parrot :)

gvim

[John Gabriele]

On Wednesday, January 8, 2014 11:17:07 AM UTC-5, tbc++ wrote:

And even clojure-py is miles behind stock python. 

One of the problems with Clojure as it stands now is that there is just way too much init work that has to be done on every startup. Just as a comparison, let's compare how python code and clojure code is loaded:

 

{snip}

What makes this worse is that parts of Clojure may not be properly profiled by the JIT. In one benchmark I ran I saw a 2x speed-up loading files after the compiler was properly warmed up. 

What we see here is the difference between a VM designed for a language, and one designed for a different language. In Python constants are just dumped to/from disk during compilation and loading. In Clojure these constants have to be recreated each time.

 

{snip}

Anyway, that's my personal take on the subject. It's a trade-off. The JVM is nice, but it's dang hard to get fast startup times with it. 

Timothy 

It sounds to me that you're saying there's much less legwork for the VM to do when it's written expressly for a single given language.

I don't have a comp sci background, so please excuse my ignorance here, but Clojure seems like a pretty simple language, as languages go. How much work would be involved in hacking together a completely un-optimized custom VM for Clojure --- just for a useful subset of the Clojure language? Say, for argument's sake, you were willing to temporarily forego having a JIT and multithreading.

-- John