Re: Making things go faster

2013-06-06 Thread David Pollak
Folks, I'm skipping Midge for the time being. I've written up a little more on my environment for other newbies: http://blog.goodstuff.im/clojure_setup I plan to read more of Chas' book on my NYC flight on Saturday. Thanks, David On Wed, Jun 5, 2013 at 2:44 AM, Chas Emerick wrote: > Hi D

Re: Making things go faster

2013-06-06 Thread Gary Trakhman
> Note that the problem is actually the Clojure startup time, *not* the JVM > startup. JVM starts up in about 0.1sec on my machine. The rest of the time > is spend loading Clojure code, compiling all the core namespaces etc. > > That's one way to look at it, another is that clojure's design tightly

Re: Making things go faster

2013-06-05 Thread Mikera
My setup is usually: - Eclipse with Counterclockwise plugin - Keep an open, running REPL at all times - Reload namespaces when necessary (Ctrl+Alt+L) - Run tests with clojure.test from the REPL This avoids the startup overhead most of the time - I usually only use the Maven / leiningen comma

Re: Making things go faster

2013-06-05 Thread Brian Marick
On Jun 4, 2013, at 11:16 PM, Kevin Downey wrote: > midje makes each test a top level form, so test runs happen as a side effect > of code loading, which means you cannot really run tests in a good way from > the repl without doing some kind of ridiculous forced code reloading. I would > defin

Re: Making things go faster

2013-06-05 Thread Brian Marick
On Jun 4, 2013, at 11:16 PM, Kevin Downey wrote: > midje makes each test a top level form, so test runs happen as a side effect > of code loading, which means you cannot really run tests in a good way from > the repl without doing some kind of ridiculous forced code reloading. I would > defin

Re: Making things go faster

2013-06-05 Thread Brian Marick
On Jun 4, 2013, at 3:51 PM, David Pollak wrote: > * Is there a faster cycle than to change code, change tests and type "lein > test" to see the results? I use Midje in a repl. That looks like this: % lein repl (use 'midje.repl) (autotest) When I save a source or test file, the relevant

Re: Making things go faster

2013-06-05 Thread Alan Thompson
Nice summary on the blog. Might I suggest one small improvement? How about: (do (use 'plugh.file-test :reload-all) (run-tests) ) Then, just a single sequence. :) Alan Thompson P.S. I'm still working on getting GVIM+fireplace set up, which should allow me to do everything from within the ed

Re: Making things go faster

2013-06-05 Thread Ben Mabey
On 6/4/13 10:16 PM, Kevin Downey wrote: midje makes each test a top level form, so test runs happen as a side effect of code loading, which means you cannot really run tests in a good way from the repl without doing some kind of ridiculous forced code reloading. I would definitely recommend sta

Re: Making things go faster

2013-06-05 Thread Adam Rulli-Gibbs
What's wrong with midje's (autotest) in the REPL? I save code or test and the tests relevant to the namespace are automatically run. On Wednesday, 5 June 2013 05:16:39 UTC+1, red...@gmail.com wrote: > > midje makes each test a top level form, so test runs happen as a side > effect of code loadin

Re: Making things go faster

2013-06-05 Thread Chas Emerick
Hi David, It's odd/interesting that you're finding yourself restarting the JVM regularly. For many years, I've developed Clojure with very rare restarts; especially if my baseline project configuration is stable, I often have REPL sessions that last days. (Random thought: it'd be cute if vari

Re: Making things go faster

2013-06-05 Thread Tassilo Horn
David Pollak writes: Hi David, > * Is there a faster cycle than to change code, change tests and type > "lein test" to see the results? Obviously, you can run the tests from the already running REPL. FWIW, when I change something in using Emacs/nrepl.el/clojure-mode in a namespace, I do C-c

Re: Making things go faster

2013-06-04 Thread Kevin Downey
midje makes each test a top level form, so test runs happen as a side effect of code loading, which means you cannot really run tests in a good way from the repl without doing some kind of ridiculous forced code reloading. I would definitely recommend staying far away from midje, if you want a tigh

Re: Making things go faster

2013-06-04 Thread Hoàng Minh Thắng
> > * Is there a faster cycle than to change code, change tests and type "lein > test" to see the results? > my favourite workflow is with lein-midje (you can run both midje tests and clojure tests!) https://github.com/marick/lein-midje > * Is there a way to keep everything in a hot JVM (I've d

Re: Making things go faster

2013-06-04 Thread David Pollak
Thanks for pointing me in the right direction. I did a quick blog post to help other newbies: http://blog.goodstuff.im/clojure_workflow On Tue, Jun 4, 2013 at 1:54 PM, Tim Visher wrote: > On Tue, Jun 4, 2013 at 4:51 PM, David Pollak > wrote: > > So... the questions: > > > > * Is there a fast

Re: Making things go faster

2013-06-04 Thread Michael Klishin
2013/6/5 David Pollak > * Is there a faster cycle than to change code, change tests and type "lein > test" to see the results? > * Is there a way to keep everything in a hot JVM (I've done a little > research on Nailgun... but it seems to be out of vogue) so there's no JVM > start-up penalty? >

Re: Making things go faster

2013-06-04 Thread Tim Visher
On Tue, Jun 4, 2013 at 4:51 PM, David Pollak wrote: > So... the questions: > > * Is there a faster cycle than to change code, change tests and type "lein > test" to see the results? > * Is there a way to keep everything in a hot JVM (I've done a little > research on Nailgun... but it seems to be o

Making things go faster

2013-06-04 Thread David Pollak
Folks, I've been doing Clojure coding for the last couple of weeks and really love the language... and the community is fantastic. But the development cycle is slow. I'm coming from mostly Scala and a little Java. In Java, there's no REPL or anything... but the compile/test cycle is very fast.