Anywhere you see Netty (and it's fairly ubiquitous in drivers/libraries these days, see the java driver for Cassandra or https://github.com/mpenet/alia) you'll be able to use non-blocking nio networking. Prior to http-kit I think Feng Shen played with creating a Netty based Clojure framework but ended up re-writing the core independently.

Hmm, wondering is there is a library for parsing project.clj for elisp

I have :source-paths ["src/clj" "src/cljc”] and "src/cljs” for CLJS, and when creating for example a new file -clj file, clojure-mode tries to figure out a proper ns -form but inserts a “clj” -prefix e.g. (ns clj.foo.bar)

would probably need to read project.clj in clojure-mode and compare the path of the new file to :source-paths and :cljsbuild :source-paths

maybe I should learn some elisp

how to avoid perm-gen-space errors, or oom errors ?

Maybe giving more space fro perm-gen space to the jvm or using jdk8, that as far as I know has some improvements in this area.

@niwinz: Catacumba looks impressive especially the component integration with separate modules with routes is very nice!

@mitchelkuijpers: nice to hear that! Thanks!

Can anyone explain why alter-var-root doesn't have a bang suffix: alter-var-root!?

@zcaudate: Welcome to the slack channels Chris!

lazy-lambda: Did you resolve your OOM issues?

@markmandel: setting the xx:maxPermSize=512M solved the problem

@lazy-lambda: Ah, just had it too small. Cool. I haven't done it in a while, but I've previously used Eclipse MAT and friends to do heap analysis to see what was going on under the hood when leaks occur.

@meow: the bang convention is not adhered to universally

Can clojure.tools.reader be used from Clojure 1.5.1?

Looks like it can, because its project.clj tests it on 1.5.1

I'm writing a plugin that uses clojure.tools.reader. I need to modify some of the functions in clojure.tools.reader to do certain things differently, but a lot of the meat of that namespace lives in private functions. In the REPL, I can do @#'rdr/READ_FINISHED successfully but when actually running the plugin, it cannot be resolved.

Even more odd, certain (public!) dynamic variables like *read-suppress* cannot be resolved either.

My current general strategy is to write custom versions of certain functions (`read-cond` and read-eval) and use with-redefs at the time I want to read some code. Is there a better way to do this?