Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2024-05-08

Channels

#calva
<
2024-05-08
>
Carsten Behring08:05:19

I know that Calva uses mainly static information via lsp for completion and help, but I was still wondering if the following 2 things should work from a "purely dynamic generated namespace", which has no on-disk representation): • simple completion of vars in the name space • show the :doc of a var (so the :doc of meta)

Carsten Behring08:05:36

I try to get "clojure doc" for a symbol in a ns which is completely dynamically created. So there is no "require" line but, it uses a specially macro which creates a ns and interns symbols, attaching doc strings do the ":doc" of th e`meta` In the repl it does work to get the clojure doc as usual, via 

(doc dynamic-ns/symbol)
Emacs / Cider shows it as well, but Calva not. In fact Calva does not even complete the name of the ns, and shows error overlays about "not existing ns".

pez11:05:45

It should work. Does it make a difference if you disable clojure-lsp?

ericdallo16:05:22

Keep in mind that LSP protocol support buffers not saved in disk too

Carsten Behring16:05:22

yes, it does work know. Not sure, what I did wrong.

lspector19:05:43

Small thing, but wanting to avoid ellipses (`...`) in long lists returned as values for display in output.calva-repl I found my way to settings.json where I can change the value for maxLength in calva.prettyPrintOptions. This works if I change it to a different number but I also saw somewhere that if maxLength isn't provided then everything would be printed. However, removing the maxLength specification doesn't do that -- you get a limit of 50. For practical purposes one can just set it to an enormous number, but is this a bug or is there another way to actually tell it to print whole values?

pez20:05:03

Removing it will use the default, which is 50. I think setting it to null disables it. Just beware that this also hangs the repl if you evaluate something infinite.

lspector20:05:47

Ah, beautiful. Thanks! I had tried nil because I was thinking in Clojure, and of course it didn't like that! null does the trick. I understand about infinite or otherwise problematic outputs -- I always want it to print what I told it to, and if I tell it to print something crazy then that's on me 😶

🙏 1
lspector20:05:44

Interrupt running evaluations sometimes fails for me and recently I saw that the failure also produced this message: 

ERROR:
java.lang.UnsupportedOperationException
        at java.base/java.lang.Thread.stop(Thread.java:1667)
        at nrepl.middleware.session$interrupt_stop$fn__1459.invoke(session.clj:198)
        at clojure.core$binding_conveyor_fn$fn__5823.invoke(core.clj:2047)
        at clojure.lang.AFn.call(AFn.java:18)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Thre
I realize now that this looks like it was cut off, and the session in which I did this is now gone (because I had to quit and restart VSCode to actually stop the evaluation), but I think I did a select all before copying it so there may not have been more. Might this point to the source of interrupt failures, and maybe how to fix them?

pez20:05:49

Which version of Java are you using? They removed something in some recent version that’s needed for some interruptions to work. (It’s a bit unclear to me which interrupts work and which doesn’t.).

pez20:05:42

The change was introduced with Java 20: https://github.com/nrepl/nrepl/issues/296

lspector20:05:12

Ah... so that's pretty rough, I guess. Maybe quitting VSCode sometimes won't even work because of this? In the case that produced the error I just shared, quitting VSCode did stop it. But not too long ago there was a thread about zombie processes heating up computers even after quitting VSCode, so maybe that is also due to this?

seancorfield20:05:26

There's never been a safe, sanctioned way to kill running threads so this behavior has always been living on borrowed time...

seancorfield20:05:55

(the threads should all die when the JVM exits tho')

pez20:05:05

I don’t think quitting VS Code is necessary. Kill the repl and start it again should be enough. And safer than relying on VS Code to quit cleanly.

lspector20:05:55

Interesting, maybe the previously mentioned zombie processes were from VSCode quitting in a messy way. When I see the interrupt failing in the future I'll try killing the repl first.

seancorfield20:05:51

If you just jack-in again, it kills the previous REPL, right @U0ETXRFEW?

lspector20:05:16

Seems so weird to me that there wouldn't be a good way to do something so basic and useful as killing threads, but I believe you and understand that my surprise must be rooted in my ignorance of the underlying mechanisms. Still, seems weird!

pez20:05:31

Yes, Sean, if the repl was started with jack-in, a new jack-in will start with killing the old repl.

seancorfield20:05:04

The JVM has always encouraged cooperative thread interruptions and discouraged stopping it. The former means that the running process needs to periodically check whether it has been interrupted and then exit -- which arbitrary code running in a REPL won't (can't) do. And stopping a thread can cause a failure to cleanup resources etc so it can make your application unstable.

pez20:05:06

The thread I linked to contains a lot of information about the underlying mechanism. As well as two potential solutions. None of them super convenient, but maybe we can make the nrepl clients hide some of the complexity for the users.

lspector20:05:04

Thanks both for the explanations and the practical advice on restarting the repl!

Carsten Behring21:05:39

Calva is not showing the doc string of some "synthetic" vars I use. It shows the "args" in a popup, but not the doc String. In the following 2 example, the first works well (a usual funcion), while in the second I only see args string, but not the clojure doc. Does Calva depend on any metadata my synthetic function is missing ? 

(meta #'str/capitalize)
;; => {:added "1.2",
;;     :ns #namespace[clojure.string],
;;     :name capitalize,
;;     :file "clojure/string.clj",
;;     :column 1,
;;     :line 196,
;;     :tag java.lang.String,
;;     :arglists ([s]),
;;     :doc "Converts first character of the string to upper-case, all other\n  characters to lower-case."}

(meta #'stats/lm)
;; => {:arglists ([formula data subset weights na.action & {:keys [method model x y qr singular.ok contrasts offset ...]}]),
;;     :doc
;;     "Fitting Linear Models\n\nDescription:\n\n     'lm' is used to fit linear models, including multivariate ones.\n     It can be used to carry out regression, single stratum analysis of\n     variance and analysis of covariance (although 'aov' may provide a\n     
...
...
...
;;     :name lm,
;;     :ns #namespace[r.stats]}

Carsten Behring21:05:06

When hovering over the function name it works

seancorfield23:05:55

You says it shows up in the hover docs, but I don't understand from your post where it doesn't show up -- can you elaborate?

pez09:05:05

Like @U04V70XH6, I don’t quite understand what’s not working. 😃

Carsten Behring13:05:06

When I do function completion from a namespace, like "clojure.core/m.." VSCode shows completions and "optional" the clojure doc of the completion candidate. (I thing Ctrl - Shit - Tab toggles this) This does not show the ClojureDoc for the synthetic function above, "stats/lm" while it does work for any other namespace.

Carsten Behring13:05:28

2) is not shown for the "ml/stats" function above.

Carsten Behring13:05:24

You see in 2) there is no clojure doc, only the "args", but he var has "clojuredoc" attached, see meta above

Carsten Behring13:05:04

In first screen shot the "help box" contains "args and clojure doc" in second only "args". I expect to see "args and clojuredocs" in both, as both have the key ":doc" present in the var meta. And "hovering" works for both:

Carsten Behring10:05:31

You can reproduce it by creating your own symbol with a doc string: 

(intern 'clojure.core
          (vary-meta
           'test123
           assoc
           :doc "doc of test")
          (fn [a b c]
            (+ a b c))
          )
and then try to complete (clojure.core/test1...) The "doc string" will not popup, while it does popup for other vars from clojure.core (at least when toggeling it via "ctrl-space") But mouse hovering hovering of "(clojure.core/test123)" will hsow it, so does "(clojure.repl/doc clojure.core/test123)"

Carsten Behring10:05:14

I think the feature is called "suggestionDetails": https://stackoverflow.com/questions/62815774/auto-expand-suggestion-details-in-vscode So for the "synthetic" function the "sueggest details" do not show the doc string, while they do for "normal functions".

Carsten Behring10:05:01

I found some hints, if or if-not Calva can do anything about this: Of course, this requires that the extension which contributed the suggestion / CompletionItem populated the detail and documentation properties, or implements for them to be populated by resolveCompletionItem, or there would be nothing to show in the details widget.

Carsten Behring10:05:31

It works on Emacs/Cider, for your information.

pez10:05:58

There’s a setting for prioritizing the completion provider service. Default is to use repl first and fall back on clojure-lsp. See if it matters any what this setting is configured to.

Carsten Behring12:05:29

I tried both , but it makes no difference

Carsten Behring12:05:08

I think there is a bug here: https://github.com/BetterThanTomorrow/calva/blob/4dcc69a00393566ec72b7d7ebb935b52960e9d20/src/providers/infoparser.ts#L135 This does not return the "doc" coming from cider. So it looks to me that for the "definition details during completion" only lsp info is used, never cider info, even if available. And as far as I know, lsp does not have info on his type of "dynamic" created vars.

pez13:05:46

I think we populate _docString from either doc or data.completion-doc (or something like that). You are welcome to debug it and of course with a PR if you figure it out. Regardless, an issue is welcome.

pez13:05:02

If you haven’t already, run with nrepl logging enabled and you’ll see what nrepl/cider-nrepl returns. I think you’re correct in assuming that clojure-lsp is not following those loops and hoops.

Carsten Behring13:05:22

I did, Cider returns the doc string. I think there is something wrong with the parsing of it, and / or the handling of lsp vs repl results.

pez13:05:33

Awesome. Thanks!

pez13:05:33

Let’s see what you find if you debug it. I can’t really understand from my memory of this code, why it would differ between this dynamic function and the static ones. Maybe it never works dynamically and we always only see docs from lsp. You can check that by disabling clojure-lsp and see if you get docs in completions for anything.

Carsten Behring13:05:45

Not sure I will be able to do this, I know nothing on Calva. My "impression" is, that in this special case, lsp has no clojure doc information on this vars. (as they are fully dynamic, not present on disk) I remember that LSP shows as well warnings on "unknown vars" due to this. And somehow the code handles this case "lsp has no info" and "cider has info" wrong for "completion details". while it does work for "hover". (it does work as well for this plugin: https://marketplace.visualstudio.com/items?itemName=bierner.docs-view)

pez15:05:20

I can take it from here, @U7CAHM72M. Thanks for having a look and digging up all that info for me!