Fork me on GitHub
#cursive
<
2016-11-17
>
yonatanel07:11:43

Someone here wanted cursive to remove unused imports, but I'm having this problem when not using type hints which is always:

yonatanel07:11:12

Only when I import .getTime can be resolved, but then the import is unused.

ikitommi07:11:00

@yonatanel the code uses now reflection. You can add (set! *warn-on-reflection* true) to get warnings of these. Add ^Date hint to the latter and it鈥檚 all good (into the let after a-date.

yonatanel08:11:31

Sorry for the clojure question, but can I do (.getTime ^Date a-date)?

stijn08:11:32

what about

(let [^Date a-date (:date m)]
  (.getTime a-date))

yonatanel08:11:02

No problem. I'm curious, technically, is (.getTime ^Date (:date m)) possible?

stijn08:11:05

(.getTime ^java.util.Date (java.util.Date.))
=> 1479372774370

stijn08:11:07

yes 馃檪

yonatanel08:11:10

In (some-> m :date (.getTime)) getTime is not resolved but in (some-> m (:date) (.getTime)) it is. :thinking_face:

yonatanel08:11:49

From http://clojure.org/guides/threading_macros: A bare symbol or keyword without parentheses is interpreted as a simple function invocation with a single argument.

bfabry09:11:14

that looks like a cursive bug, I don't think either of those is resolvable

yonatanel09:11:00

Why not? It works

rauh09:11:18

@yonatanel It might get guesses by Cursive, but the clojure compiler will still do reflection

bfabry09:11:33

so would your original snippet, but it would be slow

rauh09:11:38

There is no chance for clojure to know that the map field :date is a Date

rauh09:11:56

Enable *warn-on-reflection* and you'll see

yonatanel09:11:22

@rauh You are right about reflection, but it should be resolved.

bfabry09:11:32

"not resolvable" warnings in cursive don't indicate "this won't work", they indicate "I don't know if this will work or not but it will be slow"

yonatanel09:11:18

I see. So both should not be resolved...

bfabry09:11:46

well, I don't know if cursive aims to guarantee that it will always tell you something will be slow, but it would be useful if it does

imre14:11:44

anyone else having performance problems with cursive + intellij community these days?

imre14:11:22

something in my setup seems to be leaking memory and the longer I have a repl running the slower the whole ide becomes and eventually it runs out of java memory

imre14:11:28

the only recent change to my workflow was that I started using datomic

imre14:11:52

which could also be the culprit

cfleming15:11:12

@imre I actually saw that the other day. What it seemed to be was something holding the head of a seq in the nREPL client code.

cfleming15:11:29

I have some heap dumps but haven鈥檛 had time to investigate properly.

cfleming15:11:42

@bfabry Cursive does aim to do that, but has some bugs currently. In particular, it doesn鈥檛 do the right thing in a total absence of type hints (should warn always, but that perhaps should be a configurable strict mode).

cfleming15:11:08

It鈥檚 very close to being totally accurate, though.

imre15:11:05

@cfleming let me know if I can send you anything that could help tracking the issue down

yonatanel16:11:05

Is there any way to replace a common keyword namespace on all occurrences, for example when rearranging clojure specs?

cfleming19:11:59

@yonatanel You can rename a namespace alias, is that what you mean? So you can rename str/trim to string/trim or ::str/keyword` to ::string/keyword

cfleming19:11:37

Currently you can only rename the last segment of a namespace name, because renaming other segments involves moving things around which is more complicated, and not implemented yet.

cfleming19:11:43

@misha I don鈥檛 think so, no. You can use proportional fonts, but I believe the vertical space of every line has to be equal.

cfleming19:11:00

That would drive me nuts, personally - nothing would ever align.

bfabry20:11:45

also getting periodic repl slowdowns