Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>A couple of quick hints, then some links:</p> <p>Don't use <code>lein uberjar</code> during development; prefer <code>lein jar</code>. The difference is that <code>lein uberjar</code> puts all your dependencies in the generated <code>jar</code> (including Clojure itself), so that your single jar is an entirely self contained package with your app inside; <code>lein jar</code> only jars your own code. The <code>uberjar</code> approach has obvious benefits for deployment, but for development, you should be able to just use the appropriate classpath when running your app, saving yourself the time necessary to prepare an uberjar. If you don't want to hand-manage the classpath for test runs, check out the <a href="http://github.com/ericlavigne/leiningen-run" rel="noreferrer"><code>lein run</code> plugin</a>.</p> <p>Also, most likely the majority of your code should not actually be AOT compiled. AOT is necessary in some Java interop scenarios, but most of the time it brings one a slight boost in startup speed and annoying problems with binary compatibility with different releases of Clojure. I suppose the latter issue is not relevant to an <code>uberjar</code>-ed standalone app kind of project, but any library code at least should be left to be JIT-ed if at all possible. With Leiningen, you can put a <code>:namespaces</code> clause in the <code>defproject</code> form in <code>project.clj</code> to determine which namespaces are to be compiled; whatever you leave out will currently be JIT-ed by default. Older versions of Leiningen used to compile everything by default, which is actually a good reason to upgrade!</p> <p>As for the windows popping out during compilation, I would guess that you're either running window-out-popping code during macro expansion time or outside of any function definition or similar construct. (Something like a <code>(println "Foo!")</code> at the top level.) That's just something you shouldn't do, I suppose -- unless you are planning to run your code as a script, anyway. To avoid the problem, wrap side-effecting code up in function definitions and provide an entry point to your application using the <code>:main</code> clause in <code>project.clj</code>. (If you say <code>:main foo</code>, then the <code>-main</code> function from the <code>foo</code> namespace will be used as the entry point to your app. That's the default, anyway, and at least the above mentioned <code>lein run</code> seems to have the name hardcoded -- not sure about lein itself.)</p> <p>As for resetting the state of the REPL -- you can just restart it. With SLIME, M-x slime-restart-inferior-lisp will do just that while maintaining all other state of your Emacs session.</p> <p>See also these discussions on the Clojure Google group:</p> <ol> <li><a href="http://groups.google.com/group/clojure/browse_thread/thread/5723edbd8a3a0d4c/3c414d0cc24e342c" rel="noreferrer">Clojure for system administration</a></li> <li><a href="http://groups.google.com/group/clojure/browse_thread/thread/138e9cdc10508dfc/c7eccd203ca4fb43" rel="noreferrer">Prepping clojure for packaging (was: Re: Clojure for system administration)</a></li> <li><a href="http://groups.google.com/group/clojure/browse_thread/thread/3a20228de255afa9/8dce80c962cb4433" rel="noreferrer">Leiningen, Clojure and libraries: what am I missing?</a></li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload