had better luck with extending assert-expr

@gtrak I wrote cljunit to get JUnit integration with clojure.test - works nicely in Eclipse and with Maven : https://github.com/mikera/cljunit

@nberger: I think I'm getting to the bottom of this POST thing. The Swagger UI didn't work for completely baffling reasons that might be bugs in its own code... once I'm out of the woods, I'll try to reproduce and make a test case, but if you want to have some fun, do a +swagger Luminus project and try out the /minus and /divide post endpoints in swagger-ui. For me, if I edited the arguments, I'd get JS errors. I haven't used ring-logger yet -- I wanted to remove Clojure-side request generation from the equation. curl -v and judicious logging have proven really useful, and it looks like the error is in my code to begin with (surprise surprise), but I will hook up ring-logger soon to test the mock request format against what I know to be working in curl. In the meantime, before I can produce error-free schema-based output, it's time to read up on coercion... I'm sure I'm going to look back at this and laugh. Hopefully I won't be in a padded cell at the time.

Haha. I've seen it working in an app but using :body instead of :body-params... it works with swagger-ui, but I'm using peridot instead of ring-mock for the tests. I'll see if I can give it a try with ring-mock tomorrow

Don't worry about it! I did just get a reduced version working with curl. I'll see about the full version, and a tested version with ring-mock, tomorrow. Thanks for your suggestions so far. I look back at what I'm doing, and I realize that I've really been wrestling with very elementary stuff... I would be discouraged, since I pretend to be a "senior programmer" from 10 to 6 every day. In other languages, thank goodness. But really, the only way to learn anything is to begin with the acceptance that you know nothing.

Isn't it that senior programmers are those who recognize that in the first place? 😛

I don't know... sometimes I'm jealous of our summer interns, who know virtually everything. Clearly I forgot it all somewhere along the way.

@profil - I believe that's possible.

@beppu: How do I do it?

@beppu: nvm, I already solved it yesterday, just took a while for it to iterate 😄

Does anyone remember the name of the clojure library that allows to add data to a thrown exception-map?

not= slingshot

you mean ex-info?

@oily with ex-info I’d have to catch, assoc to ex-data and and rethrow. I thought I remembered a library that would make that more concise + additional benefits

@denik: This is a tangent, but when talking to Common Lisp people, they frequently complain that Clojure doesn't have a condition/restart system as described here: http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html

However, I've been meaning to check out http://docs.caudate.me/ribol/ which is such a system implemented for Clojure.

@profil: I see you figured it out, but in the repl, you can just redefine things at will and they take effect immediately.

@beppu I see. It seems try/catch with added ex-data can work similarly to Common Lisps signal/handler. Only restart is not that easy.

I think hara/signal is the new ribol. Edit: Wrong: It's hara/event

I'm still trying to wrap my head around how to use conditions and restarts. I've come to appreciate good error handling, and if there's something better than the traditional try/catch (which isn't bad), I'd like to know.

@rauh: Is ribol deprecated in favor of what's in hara?

@beppu: I think so. I was wrong with calling it "signal". It's hara/event

This one? http://docs.caudate.me/hara/hara-event.html

@beppu: Yes, ribol is deprecated

@rauh: Thanks, good to know.

thanks @rauh, reading: http://docs.caudate.me/hara/hara-event.html

Does clojure have read-time evaluation, similar to #. in Common Lisp?

ljosa: Yes, via #=, but it's not "officially" documented and generally not recommended.

thanks, I’ll try not to use it unless I really have to then.

@stuartsierra: Out of curiosity, how do you use #=?

n/m figured it out.

> '(+ 1 #=(+ 2 3))
(+ 1 5)

http://www.clojureremote.com

In the highlighted function parameter list, what is idiom being used for the second parameter? (Specifically, line 148: & [callback]) https://github.com/http-kit/http-kit/blob/master/src/org/httpkit/client.clj#L137-L148

Is that to allow an arbitrary number of parameters, only the first of which (which should be named callback in the function body) is actually used?

@erik_price: It's for pulling values out of a hash-map. See the bottom of section 3.3.3 here: http://www.braveclojure.com/do-things/#3_3__Defining_Functions

beppu: I’m specifically curious about line 148, which seems to be a vector destructuring applied to the varargs parameter. It appears to be destructuring the first element of the varargs, and what I’m really wondering is… why would one do this? Is it a useful idiom in Clojure to write functions that take varargs but only use the first one?

@erik_price: I've never done it that way myself, but I guess it's a convenient way to tack on one more optional param at the end.

beppu: thanks. i sort of thought so… just wondered if that was common.

anyone know offhand if (into {} transducer m) is faster than (persistent! (reduce-kv .. (assoc! ..)?

i feel like destructuring the kv map entry would slow things down

in the transducer

@erik_price: I’ve found it is better to replace that style of optional argument with explicit multiple arities

@jakemcc: agree. It shows up in docstrings properly etc. Plus for callbacks, you can have your lower arity thing pass a callback that does nothing, which cleans the code up a bunch (esp if the callback is called in more than one place)

turns out reduce-kv is about twice as fast on a large map

(defn remove-nil-vals1
  [m]
  (if-let [s (seq m)]
    (persistent! (reduce-kv (fn [acc k v]
                              (if (nil? v)
                                acc
                                (assoc! acc k v)))
                            (transient (empty m))
                            m))))

(defn remove-nil-vals2
  [m]
  (if-let [s (seq m)]
    (into (empty m) (filter (fn [entry]
                              (some? (val entry))))
          s)))

using criterium with non default jvm settings?

not rigorous

with (def nilmap (into {} (map vector (range 1000000) (interleave (range 1000000) (repeat nil)))))

in different jvms for each criterium run as well?

(measuring things on the jvm is really hard)

well, just trying to get a feel for it

is reduce-kv iteration faster than the transducer stuff

yeah

it's hard to do "just a feel" on the jvm sadly 😞 Thing is so complex to measure

(I've seen per differences of ~ 10 thousand times in the wrong direction due to benchmarking mistakes. 10000 is probably bigger than 2)

sorry, don't wanna piss on your measurements

no, I agree, if I were posting this to clojure-dev I'd be yelled at

but I'm still just learning transducers and trying to establish the new rules of thumb.

seems like a single boot script would be the easiest way to do criterium tests

gtrak: those aren't 100% equivalent -- one is a nil? check the other is some?

at least unify them and see if the 2x holds

maybe try (filter (comp some? val))

as well

or (remove (comp nil? val)) and hope for surprising data points

well, remove calls complement, and some also calls not, the not has to go somewhere

seems consistent either way

comp some? val was my first try

lazy-filter is indeed a bit slower than the transducer version though

which matches intuition

is there a coll-reduce implementation for persistenthashmap? I think it might still be creating a seq in that case.

I am translating a mathematical function into clojure code and get a function that is a lot slower than the "equivalent" python function. The python function takes about 2 seconds to run, but my clojure version takes at least 25-30 seconds. What am I doing wrong?

The function contains two nested sums, which I solve by using two nested reduce. The maths looks like this http://mathb.in/42688

And my clojure function looks like this, https://www.refheap.com/109401

The zetas/patterns are nested lists

Any hint is welcome

@gtrak: I've been having a lot of fun with transducers lately here: https://github.com/decomplect/ion/blob/master/src/ion/ergo/l_system.cljc

Haven't spent much time on performance optimizations, however.

@profil: does that code have to be all in one function, or could it be split up?

@meow: No reason for it to be in a big function like that, I would split it up, but wanted to know if I do something very wrong first

its very ugly right now

well, speaking from experience, when I start getting frustrated with code that isn't working its often because I've got a function that is doing too much. Lately I've worked very aggressively at keeping my functions to a bare minimum, and I'm much happier with the results.

It seems like the simplest thing, and it is. But I've had to work to break myself of bad habits from the past.

Another benefit I've recently experienced. I used to be happy when some code I was working on worked and passed some unit tests. And that's still great. But with really, really small functions, I find that many of them don't really need tests (shhh, don't tell the test-driven folks). And then the functions that use those functions, which are also small and focused, well not only do they not really need tests but even better, I can fully grasp what they do so much faster and easier. I can compose all these functions I've written in my head. And for the most part, know that they will work. Just building things up, one layer at a time, each layer as thin and focused as the previous layer.

Old hat for all the functional folks here, but for an old OO guy I'm finally feeling the payoff of the functional approach, where the clojure functions I need are coming into my mind fairly readily, my own functions are just small compositions of clojure functions, and everything just builds up nicely.

Yeah, I agree about the small function part. But in this case I am forced to create closures because the inner reduce functions still needs data outside of their "call scope", which makes it a bit ugly..

@profil http://insideclojure.org/2014/12/15/warn-on-boxed/

@profil: Also make sure the types of mu and nu support quick nth lookups.

@luxbock: Thanks, will check that

@jakemcc: Yeah, working on getting repeatedly to spit out vectors instead

@luxbock: one of these days I'm going to start using type hints in my code

@meow they can be a bit tricky

Most of the code I've been working on is early development and in such a state of flux I really don't want to invest the time in optimization until the code matures a bit and settles down.

I think unless you are working with numerics or Java interop then they don't matter as much

Haha, converting my lists into vectors made the clojure function faster than the python version :D nth on lists is linear so

Thanks for the help guys!

@meow: I believe prismatic schema spits out type hints.

> Does anyone remember the name of the clojure library that allows to add data to a thrown exception-map? @denik: did you find it? If not, what about https://github.com/gfredericks/catch-data?

Thanks @nberger

I think I saw something else

ok