Re: Faster application startup for rapid development

2012-05-15 Thread Sergey Didenko
Also discovered I can prefix `java -cp ...` with `rlwrap` to get back a nice REPL experience. If you want to use rlwrap, check out its options like --remember, -c, -b and -f. Here is the script I use to run repl from the root of the lein project: breakchars=(){}[],^%$#@\\;:''|\\

Re: Faster application startup for rapid development

2012-05-15 Thread Michael Gardner
There's also nailgun: it keeps a JVM running in the background that Java programs can connect to, eliminating JVM startup time completely. It's totally insecure on multi-user machines and hasn't been updated in a while, but it may be sufficient to ease the pain on developer machines. -- You

Re: Faster application startup for rapid development

2012-05-15 Thread MarkSwanson
reloading code at the REPL, because old background threads may still be running with old code. So I end up restarting the process many times per day. I usually create a 'restart fn that closes down the background threads and services and restarts them. This might require you to add a

Re: Faster application startup for rapid development

2012-05-14 Thread Stuart Sierra
Also discovered I can prefix `java -cp ...` with `rlwrap` to get back a nice REPL experience. -S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are

Re: Faster application startup for rapid development

2012-05-14 Thread blais
On Friday, May 11, 2012 5:33:22 PM UTC-4, Stuart Sierra wrote: What other tricks do you have for speeding up your development cycle with Clojure? I have a similar situation, where I've had to restart a repl a *lot* for a particular program (several times a day, like 10-20 times and

Faster application startup for rapid development

2012-05-11 Thread Stuart Sierra
I have a large-ish Clojure project that involves a lot of network servers and background threads. It's difficult to work on a program like this by reloading code at the REPL, because old background threads may still be running with old code. So I end up restarting the process many times per

Re: Faster application startup for rapid development

2012-05-11 Thread Phil Hagelberg
On Fri, May 11, 2012 at 2:33 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: I have a large-ish Clojure project that involves a lot of network servers and background threads. It's difficult to work on a program like this by reloading code at the REPL, because old background threads may

Re: Faster application startup for rapid development

2012-05-11 Thread Softaddicts
You are using an SSD drive I assume ? When you say large, how many servers/threads ? Luc I have a large-ish Clojure project that involves a lot of network servers and background threads. It's difficult to work on a program like this by reloading code at the REPL, because old background

Re: Faster application startup for rapid development

2012-05-11 Thread Moritz Ulrich
Are you on 32 or 64 bit Java? Startup is much faster on my machine (2008 Macbook, Core2Duo) when I use a 32bit vm. On Fri, May 11, 2012 at 11:33 PM, Stuart Sierra the.stuart.sie...@gmail.com wrote: I have a large-ish Clojure project that involves a lot of network servers and background threads.

Re: Faster application startup for rapid development

2012-05-11 Thread Softaddicts
I use ubuntu with an SSD and I hardly notice the lein repl startup time. Even in Eclipse the repl starts within a couple of seconds. I am in the same situation, multiple processes, oracle, About 80 dependencies total. I7 HT, 8 gig of ram Before using an SSD, I used to copy the most used

Re: Faster application startup for rapid development

2012-05-11 Thread Phil Hagelberg
On Fri, May 11, 2012 at 3:58 PM, Moritz Ulrich ulrich.mor...@googlemail.com wrote: Are you on 32 or 64 bit Java? Startup is much faster on my machine (2008 Macbook, Core2Duo) when I use a 32bit vm. If you have a newish JVM (hotspot 20+ IIRC) then TieredCompilation will allow the 64-bit JVM to