hmm 1.6 has some?

@aengelberg: you’re right about the evil nil case. I created an issue earlier: http://dev.clojure.org/jira/browse/CLJ-1775

Actually, I believe I am wrong about the evil nil case... (any? #(nil? %) [nil]) would return true for your trivial example. Because some returns the truthy value of the function call.

hi all, are there any way to reload java class in the repl?

something like (import [my.package HelloWorld] :reload)

ew. that's not what i thought pasting the link would do

@lucien.knechtli: ah, i meant a case like: I started a repl session, I changed HelloWorld after started repl, now I would like to reload it without restarting repl.

I'm afraid vinyasa cannot do that?

scroll down to "reimport" in the readme for the repo

Isn't that what you're describing?

aha, yes, it is! I always thought vinyasa is only for injecting vars

You could also change how you're loading the class on the Java side

it now looks to me a Swiss army knife!

but yea, I'd probably just use Vinyasa, because changing the way you load the class means messing with your deployed code, whereas vinyasa doesn't.

yes, vinyasa is a good tool in the repl

And I see your point about MyClassFactory too! Thanks!

uhmm, what keywords did you use to search about my problem?

"clojure repl reload java class"

vinyasa was pretty much the only useful thing I got out of the search though

haha, great catch though!

although, Chriz Zheng's blog looks like it's gonna be some good reading in case I get bored at work today: he wrote vinyasa

yes, I actually followed him for quite a while

Hey guys. Any chance anyone knows if there is something like reduce-indexed function (like standard map-indexed)? I don't know the whole standard library, but hope there is something that I can use without implementing it myself. Thanks.

Hi, has anyone run into namespace corruptions on :reload? I kept getting my defs corrupted when reloading namespaces with Cascalog, and my colleagues inform me this is not unique in Cascalog and happens in normal Clojure code as well.

I wonder what the reason for that might be.

I’m on Clojure 1.6, in case anyone’s wondering.

sgerguri: one common problem is that you have references from other namespaces to old instances of functions of the reloaded ns.

@ordnungswidrig: In my case I def-ed a Cascalog query.

Getting the results out of it multiple times prior to reload worked just fine, but reloading - even unrelated funs - corrupted it.

sgerguri: make sure that any ns the uses the ns with the query is reloaded, too

That was in a live repl session (so ‘user namespace). Can you even reload that?

Actually, I take that back - it was in the namespace I was reloading.

Ok, so I was in ‘foo.core and was reloading ‘foo.x.y.

ivanbokii: you can do sth like (->> [1 2 3] (map-indexed identity) (reduce (fn [s [i x] (+ s (* i x)) 0)))

I didn’t reload ‘foo.core, since the definitions I had there were all done manually.

sgerguri: maybe one of the references closed over a value from foo.x.y

They did actually.

Now it makes sense then - thanks!

Folks, why we have reduce-kv function when we could use reduce with destructing?

(reduce (fn [acc [key value]] ...

@ordnungswidrig: thanks!

@wiruzx: performance it seems

it avoids constructing, then tearing apart, the map entry

thanks

reduce-kv just walks over the internal nodes of the map and applies the function directly

one of the most confusing errors I've ever had in clojure

user.clj was in src/user.clj for component

classnotfounderror LoggerFactory when running the built jar

tools.logging is a pain with aot

devn: perhaps you were getting a logging impl from some lein plugin, and never actually depended on one properly in your project?

devn: the java loggers are very interface / impl decoupled, and everything avoids forcing a specific impl, you should usually end up having to pick one for every project

should unless someone else was poorly behaved and forced one on you

@noisesmith: there was commons logging, log4j, and slf4j-log4j12 transitively finding their way in via deps. i am using logback.

if your log library isn't working, you don't have enough of them

😄

that's the java way

To how many logs must an application write...

anyway, the real solution was to not have src/user.clj there, and specify dev in my :dev profile src-paths

but i cant say i totally understand what happened there

it was only with the built jar

user.clj being a file that referenced components

@trptcolin: eh?

😄 caught you typing

yeah i've ended up just changing the ns name to not-`user`, due to https://github.com/clojure/clojure/blob/35563c1d64406ce9c57e93a3d1d83cbd0a21bbab/src/jvm/clojure/lang/RT.java#L453-L473

for situations where :prep-tasks needs to prepare things that my main component ns needs, because the app itself depends on them, which loads clojure to run the :prep-tasks, which loads RT.java, which loads user

fun stuff

anyone here use different logback configurations in dev/test/prod? actually, in general: I could use some help with logging garbage. how the heck do you manage all of these logging deps?

it seems like if i pull one thread, another logging dep pops out of the woodwork

im sticking with logback because of its LogstashEncoder

controlling the insanity is trying my patience, though, i must admit

I like to have a separate “script” for packaging for deployment. If the app is invoked via a shell script, I just pass in -Dlogback.configurationFile=/path/to/prod/logback.xml for that.

For testing, I think you can do something similar inside leiningen. Some sort of fixtures thing. I’ve used that to hide all logging when running tests.

so you don't package the logback.xml?

also, it would seem that logback.configurationFile is only being respected when I run the jar

so for local development, it's still not doing the right thing

For testing:

:profiles {:uberjar {:aot :all}
             :test {:jvm-opts
                    ["-Dlogback.configurationFile=test/resources/logback.xml”]}

hmph, im genuinely confused. it would seem that my profile is not being respected

zentrope: do you have logback-core included as a dep?

For deps, I have the following:

i have zookeeper logging using slf4j-log4j12 under the covers

and log4j

[org.clojure/tools.logging "0.3.1"]
   [ch.qos.logback/logback-classic "1.1.3"]

Ah. Hm.

I have my “dev” logback in the resources directory.

named logback.xml?

For production, I have a separate logback.xml elsewhere. I use that for running the jar (as you said).

Yes.

so do you bundle the other logback.xml in your jar? sounds like no.

For testing, I have another logback in the test/resources dir, which doesn’t get on the classpath.

Yes, the default logback is still in the jar, but the -D param overrides it.

And, yeah, you have to add other slf4j nonsense to bridge dependencies that use something else and won’t shut up … sometimes.

So, the “prod” logback is NOT in the jar. (Otherwise, ops folks can’t fiddle with it.)

ah, that's a good point, i was doing exploded clojure uberwars in a previous job

so it was still available on the box

but that makes good sense

Yeah. I’m opinionated in that I like to make a separate project for building-for-production.

It just checks out the code (or whatever) and adds production style scripts, update.d, launchd, configs, logback, whatever.

That way my code is simple. No “if” statements. Just overridable defaults.

yeah, i was using janino to do conditional expressions inside the logback.xml

but that is absolute nonsense

(This is kinda against the grain for a lot of devs, I admit.)

im just going to drop logback.xml into chef and call it a day

Heh. ;)

Place I worked wrote software to deploy at customer sites, so had to have logback external to a jar so support could turn stuff on to see what happened.

meh, if it works, it works -- i dont want to pass a bunch of "necessary" nonsense logging-related burden onto other devs

so im trying to make development simple, clean configurable logging

Right! ;)

and then have the logstash encoder only exist in the prod environment

Ops should be able to pass in overrides as they need. It’s not a build-time concern.

paths matter to me as well -- would rather not have local devs forced into making /var/log/foo/bar.log with correct permissions

i just want those to go to log/bar.log

in the local project

Sensible defaults.

one last question for you, and it's a loaded one

so, configuration. I'm using environ, which lets you refer to ENV vars and java system properties in your clojure code like (get configuration :foo), but in prod you set the ENV var as FOO=123 java -jar ...

this turns out to be pretty handy, but locally we've got a config.edn.example file that specifies local defaults, which you copy to config.edn in order for them to take effect

this was all well and good, but of course, doing AOT in an environment that /doesn't/ have a config.edn obviously breaks, which means a bunch of complicated nonsense for the build pipeline, since it needs to go out and grab config

so i'm kind of faced with this question of: should I skip AOT and pass the values in as ENV vars when the jar is run?

or should i write a file, curl a file, etc. to read values from?

etc.

Hm.

My preference is to consider the build as a UI problem for devs. The mount of futzing with files is painful.

So, the app should “just work” with “lein run” and that’s that. ;)

But what about production?

so you run with defaults?

I use something like: java -jar app.jar —config /path/to/config.edn.

Then just merge the map there over the top of the sensible defaults.

right now im not specifying :main or :aot in project.clj, doing (:gen-class) and ^:skip-aot on the ns with the -main in it

so all env vars are set when it runs

Doesn’t uberjar aot everything anyway?

you can avoid it

As long as you have something like (System/getenv “ENV_VAR” “default”) it doesn’t matter, right?

by for instance, specifying :main, and then creating a bootstrap clojure file that references the -main indirectly, so it won't transitively AOT your project

so you reference your bootstrap -main instead of your true main

so many ways to run clojure 😄

Okay. Make sense. But how does that impact env vars for configuration?

when you go to run locally they still have to be set somewhere, even if you get to avoid them when building the jar

Yeah. I always go with defaults. localhost database, stock port, etc.

this whole scenario is a bit more complicated than im letting on, and i won't bore you with details, just rubber ducking a little bit thinking about the right way to keep development easy, but also close enough to a prod environment that there aren't annoying surprises when deploying

API keys still need to live somewhere

Yeah, that’s tough.

which, i could create a development version of those keys and commit them

Another thing is a “configurator” that just prints out what stuff isn’t set, so devs aren’t faced with bizarre stack traces.

but i tend to avoid committed keys at all cost

Sensible.

I've used outpace/config in the past

The problem with dev being too much like prod is that prod becomes frozen.

you can generate a config from all the areas you reference config values

Or, people start relying on stuff being there and don’t build in flexibility at the right places.

but it still isn't going to magically insert API keys

Tradeoffs, eh? ;)

Api keys, remote databases, etc.

yeah, the more i think about it i think that committed, sensible defaults for configuration vars needs to happen, and for the API keys in question, a separate set of test accounts can be created which will never see prod traffic

I’ve had people just “lein run —config=/path/to/custom.edn” for dev. It’s not too bad.

and maybe...just maybe commit those as well -- there's nothing of value in them, after all

Yeah, if you separate “build for production” vs “build for dev” into separate projects, you can store the production API keys in that project.

the main thing is seeing a built uberjar run in your dev environment, for me that matters

because sometimes AOT stuff sneaks in and bites you

Prod project is just shell scripts (say) and conf file that get merged into an RPM (or whatever). Not a clojure project.

Yep.

Like serving embedded files via an embedded web-server. That bit me. ;)

But I just “java -jar target/app.jar —config/resources/default-config.edn” and it works.

The important bit is “override”.

That way the prod config.edn doesn’t have to have every setting.

then again, i sort of like being forced to be explicit about everything in prod