Open ghost opened 5 years ago
Hi. I think I saw this problem myself too. The issue appears to be triggered when omnisharp server is still loading project data but omnisharp-emacs starts to interact with it (by asking for autocomplete, syntax checks, etc.). The server probably doesn't know the file is part of the project when the project is not loaded yet and thus once the project is actually loaded there appears to be two duplicate files/class definitions in it's mind.
I think we will have to suppress interaction with the server until it has projects loaded. And we probably need to check what other omnisharp clients are doing.
@beeuhtricks You can consider emacs itself to be a non-multithreaded process–I think there is some kind of threading support build into emacs but we don't use it in this project.
Omnisharp-emacs uses a subprocess model to manage communication with the server via STDOUT/STDIN using a kind of event-loop mechanism model–I may not know the details very intimately, since I inherited this project.
Events received from the server are processed at this point:
You can add a (print ..)
call in the case matches of (cond ...)
special form to see the actual event packets/data to get to know what is being sent from the server as a starting point. This is the point (or somewhere in the functions called from this code) where in the context of this PR you will probably need to watch for server event which says: "all the project are loaded, you can interact with me".
Another point is where all the messages are dispatched to the server:
Here you will probably need to add an (if
or (unless
form to not actually "disturb" the server when you know that it: a) has been started; and b) has not loaded all the projects yet.. you might also want to invoke (omnisharp--message
to notify the user why omnisharp-emacs is not responding to commands by outputing some message that "the server is loading"
You can maintain the status of the server on the omnisharp--server-info
variable which is created with this function:
omnisharp--server-info
is an alist
(associative list–kind of like a dictionary but in list form, i.e. not a especially efficient but a simple data structure.). There are functions that work on alist's and you can find an example how to read/write to alists in places where omnisharp--server-info
is referenced.
This was a tiny brain dump which is hopefully useful for you as a starting point :) Please ask if there are any other questions. (And sorry for any grammar mistakes, English is not my first language)
@beeuhtricks I would also suggest you take a look at how vscode plugin for omnisharp-roslyn handles this. They may have the events described in typescript classes and you can infer more about the expected communication model with the server from their code:
@razzmatazz I'm going to be working until about 6PM EST today and I will take a crack at this afterwards. Thanks for giving me a leg up.
@razzmatazz So, I think omnisharp-vscode uses async/await to deal with launching the server: https://github.com/OmniSharp/omnisharp-vscode/blob/80bf9ae20ec595ab212da358a7188045789303fe/src/omnisharp/server.ts#L333 https://github.com/OmniSharp/omnisharp-vscode/blob/80bf9ae20ec595ab212da358a7188045789303fe/src/omnisharp/launcher.ts#L232
I have found some libraries that provide promise-like APIs with async/await for Emacs Lisp. Would you be opposed to bringing those in or would it be better to adopt an approach with something like an event loop and polling?
I will note that calling omnisharp-reload-solution
fixes the bug, and that calls to omnisharp-check-ready-status appear to return "Server is ready" even when the bug is occurring.
Looking at the code, I think this issue might be upstream. I have a hunch this happened during 1.32.2 -> 1.32.3 @ omnisharp/omnisharp-roslyn#1252 because that release merged a PR that introduced support for files outside of projects. Is it possible that what's happening is OmniSharp is trying to load it as a file outside of a project and then loading it inside the project as well?
@razzmatazz Confirmed that this is upstream. I tried the new beta of the OmniSharp Server (1.32.9-beta.20 to be precise) and it appears to be fixed: https://github.com/OmniSharp/omnisharp-roslyn/pull/1252#issuecomment-448285488 Would anyone else like to confirm that they tried this and it works?
I will note that this does require manually downloading and extracting the server from Azure Storage, because it is not yet released as a tag on GitHub. I'm wondering if we could extract the code to download a server version so the user could set where they want it to pull the server from. Currently the URL is hardcoded in omnisharp-server-installation.el
This is the PR with the fix: https://github.com/OmniSharp/omnisharp-roslyn/pull/1357#issue-237428909
I think I still have this issue using omnisharp-roslyn v1.32.9, sometimes I launch emacsclient(which in turn starts emacsserver if there isn't already one) via Unity, I still get errors like 'the namespace
@ifoolb I think we should wait for the bugfix to be released first as @beeuhtricks has noticed. and then we will know if there is anything to be done here in omnisharp-emacs
Is there any update on this? I am also experiencing the same issue.
Update: I have tested it with the latest version of omnisharp-roslyn (v1.32.10) and am still experiencing the same problem (occasionally, it will report ambiguity where there is none). Calling 'omnisharp-reload-solution' sometimes works, but sometimes does nothing.
@Chaoclypse sorry for not looking at this.. work and life problems, as usual.. and yes, it does the same thing for me with the new version I tried today.
I think the problem goes away if you don't touch the buffer of any of .cs files in your projects. That way ominsharp server is not forced to observe the file twice (during the time you browse the file and during it's own project loading sequence).
The proper solution still would probably be to wait until all the projects are loaded before issuing any requests to omnisharp-roslyn server from omnisharp-emacs
This problem (I think) has appeared once they have added support for files outside projects (a.k.a csx scripts) – thus the server does not know if the file belongs to any project before the project has actually completed loading–thus the confusion in it's behaviour.
@razzmatazz Don't worry about it, and thanks for the prompt reply to my latest message!
Is there any way to tell when my projects are fully loaded so that I know when I can make a request? Also, to clarify, a request in this case means inserting some text and getting an auto-complete, for example, right?
Just launch the server while browsing root project directory with dired or within a shell with M-x omnisharp-start-omnisharp-server
and then switch to *omnisharp-log*
buffer – when a project has completed loading it will say something like:
[14:41:26] INFORMATION: OmniSharp.MSBuild.ProjectManager, Update project: XXXYYYZZZ
Which means loading for the project is complete. I infer all of this is from observation as I am not involved in development of the related omnisharp-roslyn
project.
As to give the answer to your last question–yes. When you do autocomplete or point to a thing with a cursor - omnisharp-emacs
sends the whole buffer to the server to parse and do it's thing. Thus making the server register the class/namespace BEFORE it has actually loaded from the project or before it actually has any references between code objects in your .cs files and files on the disk resolved.
Apologies for not responding sooner. The problem with waiting for all the projects to load is that the server doesn’t announce these things, as far as I can tell, and beyond that, there is already a decent amount of async logic in the code for this particular problem. I think a long-term solution will necessitate working with the omnisharp-roslyn team as this is a regression they introduced. For the record I have also started experiencing this occasionally again and it seemed to be fixed at first.
From: Saulius Menkevičius notifications@github.com Sent: Thursday, January 31, 2019 8:06 AM To: OmniSharp/omnisharp-emacs Cc: Beatrix Klebe; Mention Subject: Re: [OmniSharp/omnisharp-emacs] Ambiguity between class (#464)
As to give the answer to your last question–yes. When you do autocomplete or point to a thing with a cursor - omnisharp-emacs sends the whole buffer to the server to parse and do it's thing. Thus making the server register the class/namespace BEFORE it has actually loaded from the project or before it actually has any references between code objects in your .cs files and files on the disk.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OmniSharp/omnisharp-emacs/issues/464#issuecomment-459337004, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIpKPZvwUCpFw-KLqQy6W5BTgS18oR3dks5vIuo6gaJpZM4ZHoUF.
@razzmatazz In the short term, it seems like we could do something like block with a while loop until we see that message. Pretty ugly, but ironically enough I’ve had to do the same thing in a project for work recently. I can start a PR for this when I’m back at my workstation if wanted.
From: Beatrix Klebe beeuhtricks@gmail.com Sent: Thursday, January 31, 2019 10:29 AM To: OmniSharp/omnisharp-emacs; OmniSharp/omnisharp-emacs Cc: Beatrix Klebe; Mention Subject: Re: [OmniSharp/omnisharp-emacs] Ambiguity between class (#464)
Apologies for not responding sooner. The problem with waiting for all the projects to load is that the server doesn’t announce these things, as far as I can tell, and beyond that, there is already a decent amount of async logic in the code for this particular problem. I think a long-term solution will necessitate working with the omnisharp-roslyn team as this is a regression they introduced. For the record I have also started experiencing this occasionally again and it seemed to be fixed at first.
From: Saulius Menkevičius notifications@github.com Sent: Thursday, January 31, 2019 8:06 AM To: OmniSharp/omnisharp-emacs Cc: Beatrix Klebe; Mention Subject: Re: [OmniSharp/omnisharp-emacs] Ambiguity between class (#464)
As to give the answer to your last question–yes. When you do autocomplete or point to a thing with a cursor - omnisharp-emacs sends the whole buffer to the server to parse and do it's thing. Thus making the server register the class/namespace BEFORE it has actually loaded from the project or before it actually has any references between code objects in your .cs files and files on the disk.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OmniSharp/omnisharp-emacs/issues/464#issuecomment-459337004, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIpKPZvwUCpFw-KLqQy6W5BTgS18oR3dks5vIuo6gaJpZM4ZHoUF.
@razzmatazz Would just like to report that I did indeed try to wait for the message to appear in the appropriate buffer. However, the problem still occurs occasionally, even after the update message appeared.
@Chaoclypse this is, indeed, distressing. I think more details should be passed upstream.
From: Chaoclypse notifications@github.com Sent: Thursday, January 31, 2019 10:36 AM To: OmniSharp/omnisharp-emacs Cc: Beatrix Klebe; Mention Subject: Re: [OmniSharp/omnisharp-emacs] Ambiguity between class (#464)
@razzmatazzhttps://github.com/razzmatazz Would just like to report that I did indeed try to wait for the message to appear in the appropriate buffer. However, the problem still occurs occasionally, even after the update message appeared.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OmniSharp/omnisharp-emacs/issues/464#issuecomment-459389224, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIpKPfDyFRTs--t4l4u6Z7LKu_Q2WKkSks5vIw14gaJpZM4ZHoUF.
@beeuhtricks I would be happy to assist in any way I can - however, do note that I am an emacs novice. I might need some instructions as to how to help.
In the meantime, is there any hack or any way around this barring constantly restarting the solution/server?
There’s a whole range of rather ugly hacks I can imagine, the first of which is to set a literal timeout before commencing communications with the server, maybe just a couple seconds after seeing that message or so. I’m no emacs lisp expert either, I would just be googling to figure this out. Clearly omnisharp-roslyn need to either fix their messaging so we can work around their regression or fix it entirely in the first place.
From: Chaoclypse notifications@github.com Sent: Thursday, January 31, 2019 10:42 AM To: OmniSharp/omnisharp-emacs Cc: Beatrix Klebe; Mention Subject: Re: [OmniSharp/omnisharp-emacs] Ambiguity between class (#464)
@beeuhtrickshttps://github.com/beeuhtricks I would be happy to assist in any way I can - however, do note that I am an emacs novice. I might need some instructions as to how to help.
In the meantime, is there any hack or any way around this barring constantly restarting the solution/server?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/OmniSharp/omnisharp-emacs/issues/464#issuecomment-459391558, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIpKPZzB5lTGJ8Geev59WCJPKh9n29Cuks5vIw7ZgaJpZM4ZHoUF.
@Chaoclypse I am trying this out with 1.32.10 after it started happening again on my old 1.32.9 beta. It seems to be fixed, I can't repro it. Are there more details about your setup you could provide?
@beeuhtricks My set-up is pretty bare-bones. The only plug-in installed on emacs is omnisharp-emacs and its dependencies. Here are my relevant settings:
(setq omnisharp-server-executable-path "/home/chaoclypse/.local/bin/omnisharp-proxy.sh")
(eval-after-load
'company
'(add-to-list 'company-backends #'company-omnisharp))
(setq company-dabbrev-downcase 0)
(setq company-idle-delay 0)
(defun my-csharp-mode-setup ()
(omnisharp-mode)
(company-mode)
(flycheck-mode)
(setq indent-tabs-mode nil)
(setq c-syntactic-indentation t)
(c-set-style "ellemtel")
(setq c-basic-offset 4)
(setq truncate-lines t)
(setq tab-width 4)
(setq evil-shift-width 4)
;; Speed up auto-complete on mono drastically. This comes with the
;; downside that documentation is impossible to fetch.
(setq omnisharp-auto-complete-want-documentation nil)
;;csharp-mode README.md recommends this too
;;(electric-pair-mode 1) ;; Emacs 24
;;(electric-pair-local-mode 1) ;; Emacs 25
(local-set-key (kbd "C-c r r") 'omnisharp-run-code-action-refactoring)
;; (local-set-key (kbd "C-c C-c") 'recompile))
(local-set-key (kbd "C-c C-c") (lambda () (interactive) (omnisharp-reload-solution)))
)
(add-hook 'csharp-mode-hook 'my-csharp-mode-setup t)
In addition, the shell script it's pointed to is just this:
#!/usr/bin/env bash
/usr/bin/mono /home/chaoclypse/.local/bin/omnisharp/OmniSharp.exe $@
Mono is version 5.16.0, OmniSharp is version 1.32.10.
I hope that's enough details! Thanks!
Update: I went back and read what @razzmatazz posted and I would like to note that I must have missed the "pointing with a cursor" part. If I keep my cursor still until the server start-up message has popped up, there is indeed no problem, at least after testing it about 10 times. If I move before the server start-up message, there is usually ambiguity. Sorry for the error on that part.
@beeuhtricks When you say you can't repro it, you mean that there is no ambiguity, regardless of when you move the cursor/type in input, right?
@beeuhtricks When you say you can't repro it, you mean that there is no ambiguity, regardless of when you move the cursor/type in input, right?
Sorry for replying so late. This is correct, the bug is completely gone for me. I am now using the 1.32.11 prerelease. Does that fix it for you?
@razzmatazz As a thought, I've noticed that some contingent of omnisharp-roslyn are working on Language Server Protocol support. Maybe it would be best to start a new issue to discuss this, but in the long term that seems somewhat appealing as a solution to this problem of the clients and server diverging over time. Certainly not all features would be supported, but it might be more robust in the features it does have.
@beeuhtricks I was actually attempting to make it work some time ago, but ran into a couple of bugs in omnisharp-roslyn.
See https://github.com/razzmatazz/lsp-csharp
The bugs were JSONRPC compliance issues in omnisharp-roslyn, maybe they are fixed now:
I have not prepared README.md in my lsp-csharp repo yet (as it didn't even actually work for me), but you can take a look at:
by the way has any of you guys tried windows version of omnishap emacs? I just did, and my classes, functions etc were marked red by flycheck all the time. it often takes many tries restarting omnisharp server and flycheck manually to finally make a session work, while currently this almost doesn't happen to me on Linux. how can omnishap roslyn be more buggy on Windows???
I now start to doubt myself if we're talking about the same thing. I've only been using emacs to code C# for Unity. In my case the ambiguity issue and redefinition issue will rise when I directly create a source file in emacs and remove a source file in unity respectively. Also if I import new packages in Unity after omnishap server has been started, the server won't just detect these new classes by itself. these issues are usually gone after I manually restart the server, as such I didn't pay much attention to it before, but it's much less likely to make it work on Windows, which is a real pain.
Will you guys update the omnisharp-server binary so that the ambiguity is gone?
I have it on my mind and somewhat working on my machine. But there is a couple of PRs that are stuck on failing tests that I didn’t get to fix yet that need to be merged in first.
—Saulius Menkevičius
Am 19.04.2019 um 15:31 schrieb Enderguy58 notifications@github.com:
Will you guys update the omnisharp-server binary so that the ambiguity is gone?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I have release an updated version of omnisharp-emacs which:
projectile-root
to determine the root folder of the project (like vscode does)As far as I have tested this fixes this particular problem with amiguity. I tried modifying the files while the server is loading, also adding a new file no longer seems to issue "duplicate definition" error for me.
Could someone confirm this fixes their problem too?
I'm sorry to bring bad news but my pc seems to freeze at uncompressing publicsuffix.txt.gz...done
when I try to install the server.
Any idea what I could do to fix this?
Is it your emacs that freezes or the whole PC?! BTW, which version of emacs do you use?
emacs 25.2.2 haha. I'm on Linux Mint emacs freezes and it slows down/freezes the whole system.
Not sure why it could be happening.. in the worst case just mkdir ~/.emacs.d/.cache/omnisharp/server/v1.32.18 and extract https://github.com/OmniSharp/omnisharp-roslyn/releases/download/v1.32.18/omnisharp-linux-x64.tar.gz there..
Thank you! It did work but, as you said earlier, it no longer requires a .sln file. Thing is, I was working using .sln files with Unity Engine
I think it's using csproj files, I'm not sure. Is there a way I could solve this by myself if it's not a bug?
I have a question is: Ambiguity between 'Receiver._runningConsumers' and 'Receiver._runningConsumers'
First, i ensure this class no repeat. this error always print when i'm load project complete. I'm try to delete this class and files, after restart emacs and loading project, create file and class, error has gone. so i not sure this problem from here? omnisharp-emacs plugin or omnisharp-rolysn .
omnisharp-emacs version: v4.2 omnisharp-rolysn version: v1.32.8 os: ubuntu 18.04