This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-01
Channels
- # aleph (1)
- # announcements (2)
- # aws (3)
- # bangalore-clj (1)
- # beginners (136)
- # boot (3)
- # calva (89)
- # cider (44)
- # cljdoc (1)
- # cljs-dev (31)
- # clojure (101)
- # clojure-europe (3)
- # clojure-italy (52)
- # clojure-nl (7)
- # clojure-spec (12)
- # clojure-uk (34)
- # clojurescript (62)
- # community-development (46)
- # cursive (25)
- # datomic (6)
- # duct (26)
- # events (6)
- # figwheel-main (4)
- # fulcro (25)
- # graphql (2)
- # jackdaw (4)
- # jukebox (3)
- # kaocha (57)
- # leiningen (31)
- # off-topic (3)
- # onyx (4)
- # other-languages (22)
- # pathom (18)
- # re-frame (9)
- # reitit (3)
- # shadow-cljs (60)
- # spacemacs (9)
- # speculative (22)
- # sql (39)
- # tools-deps (45)
- # vim (37)
I'm running into a pretty nasty IntelliJ/Cursive bug. I am editing a deftype
when I get an IDE error (I submitted one to Cursive, I think). Then a couple seconds later I get a IDE and Plugin Updates message. A couple seconds after that, I can no longer edit my file or close IntelliJ. I have to log out and log back in to get IntelliJ to quit.
The deftype
looks like this:
(deftype PointTimestampExtractor []
TimestampExtractor
(^long extract [_ ^ConsumerRecord record ^long previousTimeStamp]
(let [{:keys [point]} (.value record)]
(long (first point)))))
Sounds nasty, have you tried File->Invalidate Caches & Restart...?
No. Not sure how that would help here. It isn't a problem with resolving stuff. I guess I could try it though.
I'm just thinking it sounds like something is majorly corrupted somewhere, cache clearing might help? 🤞
I think I've had problems with editing deftype
s in the past too. None that cause a full editor crash like this though.
that ^long return type looks wrong
the signature of extract is defined in TimestampExtractor - that’s what you’re going to get
the type hints in the signature won’t affect the method signature (again, you’ll get whatever extract is defined as) but do help the interop inside the method
although I guess previousTimeStamp isn’t being used, so not gaining anything there
fair enough
It just happened again - after Invalidate caches & fixing that type hint. The exception reported says it is #131. This time no IDE crash but editing in and around the deftype
s acts very strangely. For example, if I put my cursor at the end of the deftype
and hit enter, it will indent to the starting paren here (long
.
Opening and closing the file doesn't help. Editing anything above the deftype form but below the form above the deftype and anything below the deftype form but above the form below it causes the strange indent & no backspace issue.
is there any refactor for moving vars in cursive?
@kenny That does sound nasty, sorry - I’ve looked at the error, it’s a StackOverflowError. I can’t immediately see the cause, sorry. The class definition code did change in the latest EAP, downgrading to the latest stable might help until I can look at it?
SOEs are really nasty, they can cause the JVM to hold onto monitor objects forever and other seemingly impossible things.
@joelsanchez No sorry, although there should be.
any plans to add it? it could be like this:
- move the def to the end of target ns
- require the new ns in the namespaces that use the var (if needed), and allow the user to decide if Cursive should use a :refer
or an :alias
- (possibly) remove requires of the old ns if it's not used anymore