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.

Sign up for GitHub

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

Jump to bottom

Ambiguity between class #464

Open
ghost opened this issue Dec 7, 2018 · 41 comments
Open

Ambiguity between class #464

ghost opened this issue Dec 7, 2018 · 41 comments
Labels
bug

Comments

@ghost
Copy link

ghost commented Dec 7, 2018

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
@razzmatazz
Copy link
Contributor

razzmatazz commented Dec 7, 2018 •
edited
Loading

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.

@razzmatazz razzmatazz added the bug label Dec 7, 2018
@ForLoveOfCats ForLoveOfCats mentioned this issue Dec 17, 2018
Closed
@razzmatazz
Copy link
Contributor

razzmatazz commented Dec 17, 2018 •
edited
Loading

@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)

@razzmatazz
Copy link
Contributor

@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:

@bklebe
Copy link

bklebe commented Dec 17, 2018

@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.

@bklebe
Copy link

bklebe commented Dec 18, 2018 •
edited
Loading

@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?

@bklebe
Copy link

bklebe commented Dec 18, 2018

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.

@bklebe
Copy link

bklebe commented Dec 18, 2018

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?

@bklebe bklebe mentioned this issue Dec 18, 2018
Merged
@bklebe
Copy link

bklebe commented Dec 18, 2018

@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: OmniSharp/omnisharp-roslyn#1252 (comment) Would anyone else like to confirm that they tried this and it works?

@bklebe
Copy link

bklebe commented Dec 18, 2018 •
edited
Loading

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: OmniSharp/omnisharp-roslyn#1357 (comment)

@ifoolb
Copy link

ifoolb commented Dec 31, 2018

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 already contains a definition for xxxx'. If I start emacsserver and then omnisharp server in unity project directory manually then this bug never occurs.

@razzmatazz
Copy link
Contributor

@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

@Chaoclypse
Copy link

Is there any update on this? I am also experiencing the same issue.

@Chaoclypse
Copy link

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.

@razzmatazz
Copy link
Contributor

razzmatazz commented Jan 31, 2019 •
edited
Loading

@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

@razzmatazz
Copy link
Contributor

razzmatazz commented Jan 31, 2019 •
edited
Loading

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.

@Chaoclypse
Copy link

@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?

@razzmatazz
Copy link
Contributor

razzmatazz commented Jan 31, 2019 •
edited
Loading

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.

@razzmatazz
Copy link
Contributor

razzmatazz commented Jan 31, 2019 •
edited
Loading

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.

@bklebe
Copy link

bklebe commented Jan 31, 2019 via email

@bklebe
Copy link

bklebe commented Jan 31, 2019 via email

@Chaoclypse
Copy link

@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.

@bklebe
Copy link

bklebe commented Jan 31, 2019 via email

@Chaoclypse
Copy link

@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?

@bklebe
Copy link

bklebe commented Jan 31, 2019 via email

@bklebe
Copy link

bklebe commented Jan 31, 2019

@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?

@Chaoclypse
Copy link

@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!

@Chaoclypse
Copy link

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?

@bklebe
Copy link

bklebe commented Mar 1, 2019

@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?

@bklebe
Copy link

bklebe commented Mar 1, 2019

@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.

@razzmatazz
Copy link
Contributor

@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:

@ifoolb
Copy link

ifoolb commented Mar 24, 2019

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???

@ifoolb
Copy link

ifoolb commented Mar 24, 2019 •
edited
Loading

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.

@razzmatazz razzmatazz mentioned this issue Mar 27, 2019
Open
@Dustoe
Copy link

Dustoe commented Apr 19, 2019

Will you guys update the omnisharp-server binary so that the ambiguity is gone?

@razzmatazz
Copy link
Contributor

razzmatazz commented Apr 19, 2019 via email

@razzmatazz
Copy link
Contributor

I have release an updated version of omnisharp-emacs which:

  • upgrades server version to 1.32.18
  • no longer requires .sln file to be present/discovered/selected but uses SCM/git project root/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?

@Dustoe
Copy link

Dustoe commented Apr 24, 2019

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?

@razzmatazz
Copy link
Contributor

Is it your emacs that freezes or the whole PC?!
BTW, which version of emacs do you use?

@Dustoe
Copy link

Dustoe commented Apr 24, 2019 •
edited
Loading

emacs 25.2.2 haha. I'm on Linux Mint
emacs freezes and it slows down/freezes the whole system.

@razzmatazz
Copy link
Contributor

razzmatazz commented Apr 24, 2019 •
edited
Loading

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..

@Dustoe
Copy link

Dustoe commented Apr 24, 2019 •
edited
Loading

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

@Dustoe
Copy link

Dustoe commented May 2, 2019

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@razzmatazz @bklebe @Chaoclypse @ifoolb @Dustoe