cider 2021-08-28 | Slack Archive

vemv18:08:03

I've released https://github.com/clojure-emacs/enrich-classpath 1.4.1 with a bugfix for one of the very few issues we've detected in it through the whole year. It allows CIDER (Orchard in particular) to jump to Java sources, and also to display better autocompletion info for Java methods (since said sources are parsed if present) All feedback welcome, it will be useful prior to bundling this along CIDER in future releases

🎉 10

🚀 6

bartuka14:08:47

this works perfectly! Thanks.

vemv14:08:03

Cheers, feel free keep an eye on the Cider integration, any missing little feature related to autocompletion would be a good issue to report in Orchard

bartuka16:08:04

@U45T93RA6 would be great to have a unified api to handle deps and lein projects. Reading the code seems like the add function depends on (:dependencies project) value. what do you think about a little refactor to split the add function and have a "deps preparation" phase that returns a list of [{:deps-name "", :deps-version "", ..}] then will be easier to create an alias in deps.edn projects to run a function that will generate this datastructure and call add. wdyt?

bartuka16:08:16

this is a first thought on the problem, but you got the idea hehe

vemv16:08:54

I'm really looking forward to make the project deps-compatible more easily. I did take a first step by not hardcoding any leiningen.core dependency I'm tracking the task at https://github.com/clojure-emacs/enrich-classpath/issues/2 . I have a pretty clear idea of the intended API, the only bottleneck is time 😬 if you can contribute that would be absolutely welcome

vemv16:08:22

(I do use deps.edn at my day job, but work around it by wrapping deps.edn with some Lein hack... that's far from a universal solution!)

bartuka21:08:39

I can try to contribute to that this week.. time is always the limited factor hehe. I will keep you posted when I start

vemv22:08:34

! Let's see, would be awesome. I've updated the GH issue with some impl notes of what I have in mind.

sun-one20:08:52

I'm getting unhandled nrepl failures during autocompletion from CLJS. Below is the nrepl logs. The error seems to be coming from this pre-clause check failing https://github.com/clojure-emacs/clj-suitable/blob/223f890ce6af23e764276c5d26303564a8cafd86/src/main/suitable/compliment/sources/cljs/analysis.cljc#L257 . Any insight here would be greatly appreciated. Quick note I am using the same nrepl session for both CLJS and CLJ via cider-jack-in-clj&cljs command.

(-->
  id         "30"
  op         "complete"
  session    "1888129b-91b7-4f34-a2ef-35e312c0b024"
  time-stamp "2021-08-28 13:17:36.662267000"
  context    ":same"
  ns         #("gen-fhi.frontend.core" 0 21 (fontified nil help-echo cider--help-echo cider-locals nil cider-block-dynamic-font-lock t face font-lock-type-face))
  prefix     "mat"
)
(<--
  id         "10"
  session    "1888129b-91b7-4f34-a2ef-35e312c0b024"
  time-stamp "2021-08-28 13:17:36.677222000"
  err        "ERROR: Unhandled REPL handler exception processing message {:op complete, :ns gen-fhi.frontend.core, :prefix mat, :context :same, :session 1888129b-91b7-4f34-a2ef-35e312c0b024, :id 30}
"
)
(<--
  id         "10"
  session    "1888129b-91b7-4f34-a2ef-35e312c0b024"
  time-stamp "2021-08-28 13:17:36.678457000"
  err        "java.lang.AssertionError: Assert failed: (symbol? ns)
	at cider.nrepl.inlined_deps.suitable.v0v4v0.suitable.compliment.sources.cljs.analysis$ns_meta.invokeStatic(analysis.cljc:257)
	at cider.nrepl.inlined_deps.suitable.v0v4v0.suitable.compliment.sources.cljs.analysis$ns_meta.invoke(analysis.cljc:257)
	at cider.nrepl.inlined_deps.suitable.v0v4v0.suitable.compliment.sources.cljs$ns_candidates$iter__69346__69350$fn__69351.invoke(cljs.cljc:82)
	at clojure.lang.LazySeq.sval(LazySeq.java:42)
	at clojure.lang.LazySeq.seq(LazySeq.java:51)
	at clojure.lang.RT.seq(RT.java:535)
	at clojure.core$seq__5419.invokeStatic(core.clj:139)
	at clojure.core$concat$cat__5512$fn__5513.invoke(core.clj:736)
	at clojure.lang.LazySeq.sval(LazySeq.java:42)
	at clojure.lang.LazySeq.seq(LazySeq.java:58)
	at clojure.lang.Cons.next(Cons.java:39)
	at clojure.lang.RT.next(RT.java:713)
	at clojure.core$next__5403.invokeStatic(core.clj:64)
	at clojure.core.protocols$fn__8181.invokeStatic(protocols.clj:169)
	at clojure.core.protocols$"
)

vemv08:08:06

I've reported the issue at https://github.com/clojure-emacs/clj-suitable/issues/22 , feel free to chime in

sun-one16:08:30

Looks good the only thing I would add would be it still is erroring when allowing strings to go through the ns-meta pre check (happens later in the code). But these errors are getting caught somewhere in the code (this avoids one of the biggest issues I was having which is my nrepl buffer getting huge error stack traces from unhandled Exceptions). Alteration I made:

(defn ns-meta
  [ns]
  {:pre [(or (symbol? ns) (string? ns))]}
  (if (string? ns)
    {}
    (meta (clojure.core/find-ns ns))))

Sample of my current output:

(-->
  id                        "34"
  op                        "complete"
  session                   "8553fbad-e282-4cd6-b499-8e4a27d817a4"
  time-stamp                "2021-08-29 08:32:54.854319000"
  context                   ":same"
  enhanced-cljs-completion? "t"
  ns                        #("gen-fhi.frontend.core" 0 21 (fontified t help-echo cider--help-echo cider-locals nil cider-block-dynamic-font-lock t face font-lock-type-face))
  prefix                    "zxcvzxxcv"
)
(<--
  id            "34"
  session       "8553fbad-e282-4cd6-b499-8e4a27d817a4"
  time-stamp    "2021-08-29 08:32:55.158890000"
  err           "java.lang.IllegalArgumentException: No such namespace: @auth0
 at clojure.lang.Var.find (Var.java:146)
    clojure.core$find_var.invokeStatic (core.clj:2024)
    clojure.core$find_var.invoke (core.clj:2019)
    cider.nrepl.inlined_deps.suitable.v0v4v0.suitable.compliment.sources.cljs.analysis$macro_meta.invokeStatic (analysis.cljc:266)

Maybe a filter around string namespaces earlier would be better solution as a temporary fix? Just avoid running any of this analysis code when encountered.

vemv16:08:57

Thanks! Feel free to complete the GH issue with as many 'vulnerable' defns that have to be patched for them to return no errors.

👌 2

2021-08-28

Channels