Fork me on GitHub
#clojure
<
2015-09-15
>
cfleming00:09:05

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

cfleming00:09:15

:exclusions :all or something?

danielcompton00:09:38

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

noisesmith00:09:28

would :provided do something similar enough?

estsauver05:09:04

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

benedek06:09:01

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

borkdude13:09:20

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

tylerdiaz13:09:49

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

nberger13:09:42

@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.

benedek13:09:08

good idea as well, thx @nberger

nblumoe16:09:24

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?

lvh16:09:28

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

crankyadmin17:09:32

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?

akiva17:09:43

There’s a compile error in that namespace.

crankyadmin17:09:09

Fun times....

akiva17:09:00

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

crankyadmin17:09:14

I'll give that a go.

crankyadmin18:09:54

lein run annoyingly doesn't produce a stack trace

crankyadmin18:09:39

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

akiva18:09:35

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.

lvh18:09:16

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

mitchelkuijpers18:09:34

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

lein eastwood
this showed the complete stacktrace

mitchelkuijpers18:09:49

You have to install eastwood then ofc

crankyadmin18:09:27

thanks its something with my Emacs setup.

crankyadmin18:09:38

Works fine on another machine.

mitchelkuijpers18:09:41

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

nblumoe18:09:36

@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)?

lvh18:09:39

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

nblumoe18:09:26

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

nblumoe18:09:55

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

lvh18:09:07

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

nblumoe18:09:52

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

crankyadmin18:09:10

@mitchelkuijpers: eastwood shows up nothing 😞

akiva18:09:37

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.

akiva18:09:29

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

crankyadmin18:09:39

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

crankyadmin18:09:27

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

crankyadmin18:09:00

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

nblumoe19:09:41

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)

gtrak19:09:56

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

nblumoe20:09:38

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

Alex Miller (Clojure team)21:09:46

I think that message was pre 1.2

Alex Miller (Clojure team)21:09:23

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

venantius22:09:00

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) 😛

danielcompton22:09:14

@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

venantius22:09:02

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

lfn322:09:23

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

lfn322:09:02

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

venantius22:09:24

@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

lfn322:09:59

Yeah that's what I was digging at as well

danielcompton22:09:15

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

danielcompton22:09:27

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

danielcompton22:09:42

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

venantius22:09:01

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

danielcompton22:09:14

That’s my best guess

danielcompton23:09:04

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

venantius23:09:06

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

lfn323:09:08

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

lfn323:09:22

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

lfn323:09:59

So it's probably pretty challenging...?

lfn323:09:09

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

cfleming23:09:03

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

cfleming23:09:43

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

cfleming23:09:57

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

venantius23:09:11

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

cfleming23:09:19

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.

lvh23:09:37

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
(t/HMap :mandatory {:kwargs (IPersistentMap t/Symbol t/Any), :retries t/Any, :id t/Any, :task String} :optional {:args (t/Seq t/Any)}) definitely matches t/Any, and (t/HMap :mandatory {:key-fn [(t/U t/Kw String) -> String]} :complete? true) seems like it should match (t/HMap :optional {:key-fn (t/Fn [t/Any -> String]); that is, an argument HMap with a mandatory key should be passable to something that doesn’t care about that key.