Fork me on GitHub

I’m trying to use an inner enum from a Java class, but got this exception:

1. Unhandled java.lang.NoClassDefFoundError
   Could not initialize class$Api


Anyone have a clue?


it works with inner classes..


What happened to cond-let from contrib's cond.clj namespace? Did it move somewhere in core?


@teng in order to turn on :args checking for fdef's you need to call instrument


Is that something you want to do in production?


in general I think having the :args checked is only really meant for development and testing yes. though obviously you could turn it on in production if you wanted to. If you want to also check the :ret then you need to run check on the print-name function, which will call print-name with a bunch of randomly generated :x/person's and check that the result is nil


obviously when you call check on a side-effecting function like print-name you'll get side-effects, so look out 😉


I like when the code is explicit, so I will probably go for the :pre/:post support built in to defn or the explicit calls to s/valid? and s/conform. Thanks for the warning about testing side-effecting functions 🙂


cool cool, I think using :pre and :post is the more intended way of making those checks in production


I come from the Java world with a lot of magic byte-code instrumentation and configuration….after a while you totally lose control! I like the Clojure way where things are very explicit, leading to code that you can follow and understand.


anyone know when the Clojutre videos will be put up?


They said in the email that during this week


Trying out spec I wonder how comprehensive is :fn supposed to be? I watched Stu's demo of my-index-of and despite the original claim the verification the :fn invariant is quite weak (much weaker than the happy path scenario it replaces). I can imagine a series of (s/and inv1 inv2 inv3 ... invN) based on a default generator but that seems rather limited. There is a hint how to write an useful generator for testing something like that in the Spec Guide (hello generator) but such a generator can't be used as a default one. Most stronger properties needed custom generators and bind forms ... maybe that is out of Spec scope? I ended up with a standard happy path tests + standard TC tests (+thinking of test.chuck because of clojure.test integration) + very basic spec :fns for most functions. TC tests include a 2nd implementation or round tripping via another fn in the suite (encrypt/decrypt) - that also seems out of spec scope. Note that the code tested is crypto, that is a perfect match for gen. tests. It will only be harder for "normal" code. Thoughts?


@katox: It’s been suggested that s/fdef is best suited for specifying properties of the output type in terms of the input type, that it’s not a good place to specify properties of the fn proper.


@donaldball makes sense - using spec just to describe format of input and output variants and not for actual testing. In that regard I find Stu's descriptions largely confusing 😉


A question about timbre logging, has somebody been able to redirect it to log4j/slf4j? I keep seeing it on the cider console but not in the logs


@seancorfield Hi, at World Singles, are you running an abstraction on top of And are you using postgres as database?


How do I spec a function that passes its arg to slurp? Something like ::reader-input aboce? I'd like to automatically check its output in test but the gen keeps complaining.


@katox I'm not sure what the long term story for testing functions with side-effects is, but at the moment I think you'll need to stub out the side-effecting function (slurp) with with-redefs or similar


s/with-gen might be useful


@donaldball: I tried it but I failed to come up with a generator for the snippet above. such-that wasn't satisfied with my proposed solution :)


@sveri We use MySQL and we used to have an abstraction over java.jdbc but now we tend to use it raw — with HoneySQL when we need to work with composable SQL fragments.


@katox: you may be looking for s/or instead of s/alt?


@donaldball good catch, I need to exercise with-gen and with-redefs a bit more


Is there any way to do postgres type casting in a hugsql tuple? Been over the docs a few times and there isn't a simple answer looks like.


@seancorfield Ok, thank you, is it that any abstraction over jdbc does not bring that much value? How would you compare it to JPA? I mean, I know what JPA is and have it used myself, I just wonder why you dont find the need to use a similar abstraction in clojure.


We used to have get-by-id and find-by-keys in our abstraction layer (as well as hiding the actual DB connection pooling from the rest of our code) but those two functions are in java.jdbc now — and we’ve moved to Component for managing state/configuration/etc so we say (jdbc/query (-> application :database :pooled-db) […]) directly


insert! traffics in hash maps directly, so there’s no "objects" to map to DB columns.


query and find-by-keys produce sequences of hash maps, get-by-id produces a hash map. There’s just no mapping to be done there.


When we have complex queries that need to be built, HoneySQL provides the composability we need there.


We do wrap our (Clojure) persistence layer in a thin OOP veneer for our legacy code, but we have a generic class that uses "method missing" hooks to pretend to have accessors for direct properties and for related "objects" using a convention-based approach (`getThing()` looks for thingid and does a get-by-id on the thing table with that as the PK).


Working in Clojure with sequences of maps, we just don’t find a need for anything ORM-like.


(if we know we eagerly need related data from multiple tables, it’s easy to do a join in the select instead, especially with HoneySQL)


(and if we want to lazy-load it, then explicitly calling get-by-id or find-by-keys works fine — if we need caching, we do it explicitly with core.cache and core.memoize).