Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Long command line causes problems with Clojure? #565

Open
mars0i opened this issue Jan 29, 2025 · 5 comments
Open

Long command line causes problems with Clojure? #565

mars0i opened this issue Jan 29, 2025 · 5 comments

Comments

@mars0i
Copy link

mars0i commented Jan 29, 2025

I am not sure whether you'll be able to do anything about this problem, because it seems to involve an interaction between Goneovim and the nrepl Clojure client, or maybe something with the Conjure IDE plugin that I use with Clojure, and the behavior is not entirely consistent. It's very confusing. But I thought I would report it, even though the problem may be impossible to diagnose.

I'm using this version of goneovim:
https://github.com/akiyosi/goneovim/actions/runs/12727719274 as you suggested here: #562 (comment) (That did fix the WinPos problem--thank you.)

Normally, first I start a Clojure nrepl server. Then I start goneovim and run the Conjure plugin, which connects to the nrepl server so that I can send lines of code to be evaluated, etc.

This is what I know:

If I start goneovim with a long command line--many filenames, e.g.:

goneovim src/clj/sauroprob/hanami.clj src/clj/sauroprob/core.clj src/clj/sauroprob/mayoster1976.clj src/clj/sauroprob/basicillustrations.clj src/clj/utils/math.clj src/clj/utils/string.clj src/clj/utils/misc.clj src/clj/utils/json.clj

then when I use Conjure to cause nepl to evaluate one of the files, I get errors such as this one:

; eval (file): ...lj/sauroprob/mayoster1976.clj
; (err) Syntax error compiling at (clojure/core/async/impl/ioc_macros.clj:12:1).
; (err) namespace 'clojure.tools.analyzer' not found

The missing namespace seems is compiled source that gets pulled in by one of the libraries that my source file requires. What's weird is that the name of the missing namespace is not always the same. It's not even always part of the clojure package. So it seems as if there's a race condition somewhere. So far this doesn't seem to have anything to do with goneovim, though.


However, if I do the same thing using plain nvim in a terminal, without goneovim, the problem doesn't occur.

Further, if I start goneovim using a shorter command line--one, or two, or three filenames, for example, the problem doesn't occur.


Finally, the problem or lack of problem persists in the nrepl server across different invocations of goneovim:

What I mean is that I start nrepl. Then if I start goneovim with a long command line, I get the error. If I then quit goneovim but leave nrepl running, and start goneovim with only one filename, or if I start nvim instead, the error keeps happening. To prevent the error from occuring again, I have to kill nrepl and restart it.

On the other hand, if start nrepl, and then start goneovim with a single filename, or I use plain nvim, then the error doesn't occur. If I then quit goneovim or nvim but leave nrepl running, and start goneovim with a long command line using the same nrepl process, the problem never occurs.

I would describe this by saying that once nrepl gets confused, it remains confused, but if it once it gets started in a non-confused state, it remains unconfused.


So it seems as if when goneovim is given a long command line, or many file names, or ?, nrepl gets confused, but it's not confused by a short command line with goneovim, and it's not confused by plain nvim.

This doesn't make any sense to me!


There's one more weird thing. This is only happening on my new MacOS 15.2 ARM machine. It doesn't happen on my old Intel machine that's running MacOS 13.

@mars0i
Copy link
Author

mars0i commented Jan 30, 2025

A correction: My last comment, that the problem doesn't occur on my MacOS 13 Intel machine was incorrect. I had been running goneovim 0.6.8 on the Intel machine. The problem does not occur with 0.6.8. However, if I switch to the 50a163b build on the Intel machine--the same build that I'm using on the ARM machine--the problem described above does occur. (Yay! One less mystery!)

@mars0i
Copy link
Author

mars0i commented Jan 30, 2025

Would it be very easy to make an ARM build of 0.6.8? It's the last version without a MacOS ARM build, but it seems to work well for me on Intel, so it would probably work well on ARM too. That might be a good temporary solution for my needs. If it would be a pain to make an ARM build of 0.6.8, I have some ideas about workarounds I can implement to use the 50a163b build.

(Thanks again for goneovim, and for being so helpful with issues! I don't like terminal nvim.)

@akiyosi
Copy link
Owner

akiyosi commented Feb 2, 2025

@mars0i
Hi :)
Thanks for reporting this issue.

I am investigating, but there are numerous fixes in the current 0.6.8 and the latest version, so I have no idea of the suspect area at this time. However, I am certain that the problem is on the goenovim side.
I have re-created a ver with only arm support in 0.6.8 with the following fixes. Please check the reproducibility of the problem here and give us feedback.

https://github.com/akiyosi/goneovim/actions/runs/13095116264

@mars0i
Copy link
Author

mars0i commented Feb 2, 2025

Thank you @akiyosi! I'll try it out.

On Intel MacOS, the fixup version seems to work fine. I'll keep playing with it and see if a problem arises. I'll install the ARM version later today or tomorrow and try that.

@mars0i
Copy link
Author

mars0i commented Feb 3, 2025

The fixup version d039c73 has no problems in the ARM version either. At least with my preliminary experiments, it works perfectly, with no issues.

Thanks for this version, and thank you for investigating.

Let me know if there are other versions you want me to try out, or if there are particular experiments I should try. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants