Is there a way in leiningen to use :exclusions to exclude all dependencies of a dep?

:exclusions :all or something?

@cfleming: not sure, but there is the corollary for excluding a specific dep from all dependencies

would :provided do something similar enough?

@benedek: download the specific lein you want following the install instructions, specify the explicit path as part of the build step.

@estsauver did just that. looks ugly kinda but works. thx

I was wondering if you can get binding.pry like behavior in CIDER while developing a ring application, as in: fire a new request and the debugger is triggered in emacs (edited) I still use mostly println because of this reason

@borkdude: I haven’t tried it outside of trivial apps, but CIDER’s debugger tool might do the trick

http://endlessparentheses.com/cider-debug-a-visual-interactive-debugger-for-clojure.html

@benedek: I had the same need for CircleCI and fixed it by adding echo Y | lein upgrade 2.5.2 as a post dependencies task. You said there's lein 2.5.1 already installed, so something similar must work in travis too.

good idea as well, thx @nberger

When I dissoc from a map and get rid of the reference to the original map, will the garbage collector free up memory for the disassociated data?

nblumoe: Yes. Persistent data structures don’t break garbage collection

Hi, I'm getting this error when I launch cider in emacs. error in process filter: Some namespaces are in a bad state: error "clojure.lang.PersistentArrayMap cannot be cast to clojure.lang.Compiler$LocalBinding" I'm using Cider 0.9.1 with Clojure 1.7.0. Google isn't turning up much. Anyone have any ideas what may be causing it?

There’s a compile error in that namespace.

Fun times....

Hah yeah. I honestly don’t know if pst would help out. However lein run should give you the stacktrace.

I'll give that a go.

lein run annoyingly doesn't produce a stack trace

in fact I'm sure its refactor-nrepl in emacs causing it... just don't have a clue where to start debugging.

Interesting. Usually when I see that message, it’s because of an issue of … well, now that I think of it, I usually launch a REPL from the command line and then use cider-connect rather than cider-jack-in so, yeah, I may be totally useless for you here.

Is there a way to get lein-typed to just check every namespace?

@crankyadmin: I also had that problem and found it by running

lein eastwood

You have to install eastwood then ofc

https://github.com/jonase/eastwood

thanks its something with my Emacs setup.

Works fine on another machine.

@crankyadmin: It was really annoying because it broke al refactor-nrepl stuff

@lvh thanks. to take the question about dissoc further then: could I leverage this to prevent head retention issues when having to iterate over lazy sequences nested in a tree? example: let's say we have a map m with lazy seqs that don't fit into memory, but we need to process these seqs lazily. Would (f (dissoc m :large-seq) (:large-seq m)) allow to go lazily through the seqs in function f and still having the head of the tree available via the first function parameter, without having head retention (assuming m isn't in the scope of f of course)?

if m isn’t reachable you don’t even need to do that

well the alternative would be to pass m as an argument of f, because I need the data in f

but this then would mean head retention and not allow walking the lazy seq without running out of memory

nblumoe: Okay, then yes, just get rid of the reference to the head

great, thanks will give it a try then. have been banging my hand against lazy sequences a lot recently.... 😉

@mitchelkuijpers: eastwood shows up nothing 😞

Funny, I just cranked on a REPL in a project and got similar errors but it’s telling me which namespaces. That might be a feature of CIDER-10.0-SNAPSHOT or it might point to the fact that, yes, it’s an issue with your Emacs setup.

My best advice at this point would be to make sure your CIDER and nREPL dependencies are up to date.

I'm pretty sure I'm as up to date as possible and I know the code is good. lein run ... ... works fine.

It does tell me which namespace the error is in but there is no error (why I mention lein runs fine)

I'm starting to suspect that refactor-nrepl is broken on the master branch

@nblumoe: might be useful to read up on locals clearing: https://groups.google.com/forum/#!msg/clojure/FLrtjyYJdRU/1gzChYsmTpsJ

thanks @gtrak do you know since which Clojure version this is in release? I also found the comment on http://clojure.org/lazy#Making%20Clojure%20Lazier--Don%27t%20hang%20%28onto%29%20your%20head referring to the quite old lazy branch, which has unmerged commits, but I would assume the corresponding improvements found their way into release on other ways (e.g. lazy-seq)

Yea it's been around for any modern release, not sure which exactly

thanks again. now I struggle to make something fail due to head retention XD

I think that message was pre 1.2

there were some additional changes to the path tracking made in 1.6 to further reduce head retention

Is anybody using Cloverage these days for code coverage? I gave it a dry run on a small application and was pretty dissatisfied - it seemed convinced I had coverage for like 20% of my codebase with a single deftest form that just did (= 1 1) 😛

@venantius: I’ve never been particularly happy with it’s results, but it is nice for an indication of problem areas. I don’t really look at the percentages, but the HTML it produces can be quite helpful

I’m not even sure I can agree on that 😛

@venantius: yeah we tried it out as well, and were throughly confused.

The thing that bugs me is that if the stats are wrong then presumably the pretty html stuff is as well...

@lfn3: I’m not totally sure about that, necessarily - the wrong results could still be displayed correctly (read: still wrong, but at least correspondingly wrong) — but the greater point is that I have absolutely zero faith in the underlying analyzer

Yeah that's what I was digging at as well

I’m pretty sure it just checks which lines/characters are touched when running

So all of the def forms are going to be touched because they get required

but (server/run-server… isn’t called so it goes red

how to explain what’s going on in the routing then? is that partially explored because it’s a macro?

That’s my best guess

¯\(ツ)/¯

bleaugh

It’s not something I’d break the build over, but I do find it handy on occasion to use

can’t tell what’s an inherent problem with just trying to do this sort of analysis in clojure (re: macros, specifically) or whether it’s actually Cloverage itself

Presumably this sort of stuff works with bytecode injection and that kind of thing

(or at least I know that's how similar things in other langs work)

So it's probably pretty challenging...?

Source code says I'm a liar. Looks like it rewrites source to wrap everything. https://github.com/lshift/cloverage/blob/master/cloverage/src/cloverage/instrument.clj#L146

hmmmmmm

Yes, Cloverage rewrites source. I’m planning to experiment with a bytecode coverage tool at some point.

Bytecode tools have the advantage of being very battle tested, and working across Java/Clojure

But they’re line oriented, so no individual expression coverage

@cfleming: I would love that. I don’t care that much about individual expression coverage

Based on my experiences with debugging, there’s likely to be weirdness with things like threading forms too. But I think it’ll still be pretty useful.

Could anyone help me understand this core.typed error?

Domains:
	t/Any (t/HMap :optional {:key-fn (t/Fn [t/Any -> String])})

Arguments:
	(t/HMap :mandatory {:kwargs (IPersistentMap t/Symbol t/Any), :retries t/Any, :id t/Any, :task String} :optional {:args (t/Seq t/Any)}) (t/HMap :mandatory {:key-fn [(t/U t/Kw String) -> String]} :complete? true)

Ranges:
	String