> I know this isn't actually a Calva question At the present time

(= Calva Clojure-in-VSCode) ; => true

I don’t know what’s causing it or how to stop it, but maybe we can narrow it down a bit. Do you have a connected repl when this happens? And if so, does the same thing happen when you aren’t connected to a repl? If it does happen without a connected repl, this might be related to clojure-lsp, and pasting <https://calva.io/clojure-lsp/#viewing-the-logs-between-the-client-and-server%7Cthe client<->server logs> here for when you experience the issue might be helpful.

Yes it only happens with a connected repl. I can see the symbolic link 'version' of the file (file whose path starts with /opt/) in the log file you mentioned at "textDocument" and "arguments" to a "command".

Iirc, Calva has a setting for preferring clojure-lsp definitions over nREPL, see if that hides the problem for you.

This looks like the setting. I'll shutdown VS Code then bring it up again and test...

Why shutdown VS Code?

So that configuration changes take effect. Nice to know I don't need to.

Great, that fixed the problem 🙂

Very few Calva settings demand restart. We try to tell in the descriptions if they do.

> Great, that fixed the problem 🙂 It hid the problem. Could be something with your classpath that makes the REPL find the wrong file.

I'll settle with hiding just for now. Makes sense it is a CP issue.

The classpath as evaluated at the REPL doesn't have any entries starting with "/opt/foo/"

(str/split (java.lang.System/getProperty "java.class.path") #":")

("test"
 "user"
 "src"
 "resources"
 "/root/.clojure/repos/aero/aero/1.1.6/aero-1.1.6.jar"
 "/root/.clojure/repos/babashka/process/0.0.2/process-0.0.2.jar"
 "/root/.clojure/repos/binaryage/oops/0.7.1/oops-0.7.1.jar"
 "/root/.clojure/repos/buddy/buddy-auth/3.0.1/buddy-auth-3.0.1.jar"
 "/root/.clojure/repos/buddy/buddy-hashers/1.8.1/buddy-hashers-1.8.1.jar"
 "/root/.clojure/repos/cider/cider-nrepl/0.28.5/cider-nrepl-0.28.5.jar")

I agree. I do wonder what could be going on. Can you create a minimal repro project?

Not immediately but sure will do...

I think this issue would be solved if VS Code could be told to only care about project files, not what it calls 'Other files'. This picture should tell the story:

I looked for a VS Code option for 'only project files' but couldn't find one.

@UKFSJSM38 Is there any way to configure clojure-lsp (assuming Calva is set to use/prefer that and it's running) to solve this problem?

I couldn't understand the issue yet 😅 can anyone summarize or provide a minimal sample?

@U0D5RN0S1 ^?

The issue is that VSCode thinks there are two files (normal file and symbolic link file) when in reality there is only one. Thus sometimes two tabs for the same file can be open - one for the actual file and another for the symbolic link version of it. These days when I notice I'm editing the symbolic link file I shut that tab down and re-navigate to the line I was on. Sorry I can't remember exactly what things go wrong, but the IDE does become buggy when there are two of the same. This is hardly a big deal problem, but didn't happen with IntelliJ.

In the picture above you can see for the file .../ui/drawings/domain.cljc that the real version is modified and symbolic link version not modified. If I opened the symbolic link version I would start editing a stale cached version of the file.

I can't see how this is related to clojure-lsp, maybe a Vscode thing, I think a minimal repro would help calva maintainers confirm that

Just for the purposes of documenting the problem, it seems the symbolic link is from the outside (of the project) pointing in:

chris@pop-os:/opt$ pwd
/opt
chris@pop-os:/opt$ ls -al | grep foo-app
lrwxrwxrwx  1 root root   45 Feb 16 00:57 foo-app -> /home/chrismurphy/code/foo-app/foo-app/

I think I forgot / reversed the above info on what "fixed" the problem - thinking that switching to using the repl for definitions over clojure-lsp fixed the problem, when really using clojure-lsp for definitions fixed it, if I understand correctly. CC @UKFSJSM38. Thanks for checking in here, though.

Yes, setting "Calva: Definition Provider Priority" to lsp, repl did seem to fix the problem, but I now work the opposite way round, the default, which is repl, lsp.

It is really strange that the REPL finds those symlinks.

Glad to hear LSP is working more than the repl for that feature :)

I think the issue has to do with the fact that the nREPL Server is running inside a Docker container. If I look at the Dockerfile it has these lines:

COPY ./foo-app /opt/foo-app
WORKDIR /opt/foo-app 

Getting rid of the symlink meant that navigation (from F12) couldn't proceed at all:

Note that the way I printed the classpath before was misleading. This code shows the long form for each CP file:

(do
    (require '[clojure.java.classpath :as cp])
    (->> (cp/classpath)
         (map #(.getAbsolutePath %))
         (take 5)))

("/opt/foo-app/test"
 "/opt/foo-app/user"
 "/opt/foo-app/src"
 "/opt/foo-app/resources"
 "/root/.clojure/repos/aero/aero/1.1.6/aero-1.1.6.jar")

We fixed this issue by having the Dockerfile take an arg:

WORKDIR ${HERE}/foo-app
COPY ./foo-app ${HERE}/foo-app

Neither of those (jackInEnv or :jvm-opts) are reflected on the command line. In the case of jackInEnv it is set in the environment in which the jack-in command line is run. Usually you should see an echo (from which tool I don't know) about which JAVA_TOOL_OPTIONS are used, when you override defaults.

You can provide some dummy environment variable with jackInEnv and look at it in the REPL to convince yourself that it is indeed passed on.

Well, thing is, something is logging when adding those. And I get the picking up JAVA_TOOL_OPTIONS message twice. But it logs so much that I cant scroll back to see what happens and why logging changes.

Increase the Terminal buffer so that you can read those logs. Might be enlightening.

Using windows and powershell ...

Some people enjoy pain 😃

There is a VS Code setting for this. I think it should carry over to the Jack-in pseudo-terminal.

yea was just searching for scrollback

terminal lines something-something

found it, gonna check if it works

It works and can atleast look back now. After the first mention of JAVA_TOOL_OPTIONS I can clearly see log entries by javax.net.ssl wire - http-outgoing-0 and headers - http-outgoing-0 and others. Then a second mention of JAVA_TOOL_OPTIONS occurs just before the nREPL starts and only javax.net.ssl gets logged to console, really strange. Example logs:

2023/02/28 11:30:14:585 CET [DEBUG] wire - http-outgoing-0 << "Date: Tue, 28 Feb 2023 10:30:29 GMT[\r][\n]"
javax.net.ssl|DEBUG|12|clojure-agent-send-off-pool-3|2023-02-28 11:30:34.321 CET|SSLContextImpl.java:428|System property jdk.tls.client.cipherSuites is set to 'null'

cmd.exe /d /c lein update-in :dependencies conj [nrepl,"1.0.0"] -- update-in :plugins conj [cider/cider-nrepl,"0.28.5"] -- update-in [:repl-options,:nrepl-middleware] conj '["cider.nrepl/cider-middleware"]' -- with-profile +dev repl :headless
Picked up JAVA_TOOL_OPTIONS:  -Djavax.net.debug=all -Dorg.apache.hc.client5.http=TRACE -Dorg.apache.hc.client5.http.wire=TRACE -Dorg.apache.hc.client5.http.header=TRACE -Dorg.apache.commons.logging.simplelog.defaultlog=TRACE -Dlog4j.category.org.apache.http.wire=TRACE --illegal-access=warn -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog -Dorg.apache.commons.logging.simplelog.showdatetime=true -Dorg.apache.commons.logging.simplelog.log.org.apache.http=TRACE -Dorg.apache.commons.logging.simplelog.log.org.apache.http.impl.conn=TRACE -Dorg.apache.commons.logging.simplelog.log.org.apache.http.impl.client=TRACE -Dorg.apache.commons.logging.simplelog.log.org.apache.http.client=TRACE -Dorg.slf4j.simpleLogger.defaultLogLevel=TRACE -Xdebug

Picked up JAVA_TOOL_OPTIONS:  -Djavax.net.debug=all -Dorg.apache.hc.client5.http=TRACE -Dorg.apache.hc.client5.http.wire=TRACE -Dorg.apache.hc.client5.http.header=TRACE -Dorg.apache.commons.logging.simplelog.defaultlog=TRACE -Dlog4j.category.org.apache.http.wire=TRACE --illegal-access=warn -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog -Dorg.apache.commons.logging.simplelog.showdatetime=true -Dorg.apache.commons.logging.simplelog.log.org.apache.http=TRACE -Dorg.apache.commons.logging.simplelog.log.org.apache.http.impl.conn=TRACE -Dorg.apache.commons.logging.simplelog.log.org.apache.http.impl.client=TRACE -Dorg.apache.commons.logging.simplelog.log.org.apache.http.client=TRACE -Dorg.slf4j.simpleLogger.defaultLogLevel=TRACE -Xdebug
nREPL server started on port 1078 on host 127.0.0.1 - 

I'm trying to debug an issue with the clj-http library and tls but cant get the log to work after the jack-in

Starting the jackin manually in a terminal now

lets see what happens 🙂

same thing, weird, After the nREPL is connected the http-outgoing-0 debug lines no longer get logged to console

Don't know if related, but getting a reflective access warning.

WARNING: Illegal reflective access by clojure.core$bean$fn__7278$fn__7279 (file:/C:/Users/thier/.m2/repository/org/clojure/clojure/1.11.1/clojure-1.11.1.jar) to method sun.security.provider.certpath.SunCertPathBuilderException.getAdjacencyList()

Maybe try with just one option first?

without any option:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by clojure.core$bean$fn__7278$fn__7279 (file:/C:/Users/thier/.m2/repository/org/clojure/clojure/1.11.1/clojure-1.11.1.jar) to method sun.security.provider.certpath.SunCertPathBuilderException.getAdjacencyList()
WARNING: Please consider reporting this to the maintainers of clojure.core$bean$fn__7278$fn__7279
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Seems unrelated to your issue. But might be something to ask about here: https://ask.clojure.org/index.php/search?q=reflection

ill have a look

Done :facepunch::skin-tone-2:💪:skin-tone-2:

Yeah done:raised_hands: