Something has caused my Rust language tools to stop working as expected recently. I hadn't been in a Rust file for about 2 weeks, came back and I no longer have all the diagnostic info from the language server in the buffer. No gutter hints, no underlines, no LSP-Saga goodness. Oddly I still have some inlay hints. ?? I could use some help troubleshooting where to dig on this.
Nvim version:
NVIM v0.8.0-1210-gd367ed9b2
LuaJIT 2.1.0-beta3
Packer installs related to rust:
nvim-lspconfig (though not using it to configure rust, see tools below)
Mason and mason-lspconfig
simrat39/rust-tools
Rust-Analyzer and codelldb installed through Mason and updated
So far I have tried removing rust-tools and and configuring through lspconfigs. No luck. I also confirmed with :LspInfo that the language server is running and attached with both config options. I removed LSPSaga, combed through everything touching vim.diagnostic and turned things off / back on, no love there either.
The strange thing is I still have my Typescript, Lua, Svelte and Go support, full featured and totally unchanged, so it's more than likely something specific to Rust. I did run PackerSync a few times because I was playing with themes and saw some updates on other plugins that I didn't pay a lot of attention to. No new issues on any of the github repos related to Rust either, at least not with this issue. Something changed somewhere, but I could definitely use some direction tracking it down.
Any thoughts?
Edit
I was able to get partial support back. I did this by uninstalling the language server with Mason, then installing an older version directly within linux and adding it to $PATH. At this point things some of the things turned back on, but not all. I then removed the binary from $PATH and reinstalled the latest version with Mason, and the things that started working again kept working.
This one has me stumped, but I got enough functionality back to work comfortably again.
Warning! I am beginner.
Apple testflight is refusing to accept any builds of a previously healthy project, sending out this message;
*
TMS-90809: Deprecated API Usage - New apps that use UIWebView are no
longer accepted. Instead, use WKWebView for improved security and
reliability. Learn more
OK, I understand that the UIWebView is now fully deprecated and no longer allowed.
I have scoured all the files in may app manually using the Xcode editor and find there is no reference to the deprecated string ( UIWebView ) in any file that I can edit.
Using the Xcode "find in project" tool also says it's not there.
If I build & archive, then run grep in CLI to examine the resulting package contents, the report is that the string "UIWebView" IS found in the app and the dSYM file.
Also, again using grep, I have examined the various framework files referenced in the editor, the report is that framework 'UIKIT' contains many references to UIWebView. The check does not reveal any other references to the string.
UIKIT is still shown as required in the build list.
I have cleaned the project, deleted all derived data, closed and opened the project and xcode.
Could any kind soul point me in the right direction here - I am stumped.
Thanks, Max
After learning a lot more, I found it was the PayPal external framework which had deprecated references in it. They no longer maintain it. I had to remove that and I added Braintree instead which is kept updated.
I had failed to check the external frameworks when trying to sanitise the cause. There is no magic bullet here...I just had to plod through all the components.
This was mostly caused by my inexperience and failure to understand the function of the various components of an app.
I have built and added some new plugins to MPS and when I am trying to use them I am getting the following error "The language is not deployed 'com.abc.plugin.implementation'"
Anybody faced the similar problem and have a solution can help me?
MPS Version used: 2017.1.2
JDK: 1.8
Do you mean language plugins or other? If Yes can you find sources of your plugin (ctrl+alt+shift+S opens find module popup)? If there is no sources then plugin wasn't loaded. If you can find sources then probably some of language dependencies is not found (if any module in MPS has broken dependency then it won't be deployed). May be you build plugin with language, but didn't include it's runtime module.
This issue is a bug in MPS which is logged in youtrack as below:
https://youtrack.jetbrains.com/issue/MPS-26437
Layout node for plugin places all modules of a group under a single folder. If there's a devkit among the modules, only devkits are loaded (https://youtrack.jetbrains.com/issue/MPS-25852), and other modules are ignored.
Unless we've got devkits deployed as regular modules, not simple files, MPS could place these devkit files separately when deploying a module as a workaround.
This problem is resolved and available with commit # 2edca430f054c908eb7606bad8ac6af46e0a7352
As you can see here, while a Sentry project has a setting for platform, it has instructions (sections to the left) for connecting any platform to its logging:
Furthermore it works when logging from multiple programming languages, and it's not obvious in the stream, which errors are from which programming languages until you go to the individual error.
Is the platform setting just marking a project as one language, so you may have one project for Python, one project for JS, etc. or are there more important ramifications of changing the "platform" of a project? I saw in the changelog that "Sentry will now ask for your project’s platform." since 5.2 although it isn't clear what this option is for, as it will apparently log from any language's Raven logger.
This is the best answer I've found (and it's still pretty vague):
This is mostly so we can apply some sane defaults on how to render the stack frames visually.
We definitely don't prevent you from sending a JavaScript error to a project that is set to Python, for example.
This is just odd.
I'm getting a build error in ServiceStack.Text after just bringing down the latest build from GitHub.
if (endpointUrl.IsNullOrEmpty() || !endpointUrl.StartsWith("http"))
return null;
Error 1 No overload for method 'IsNullOrEmpty' takes 0 arguments
ServiceStack\src\ServiceStack.Common\Messaging\ClientFactory.cs 10 18
ServiceStack.Common
I'm also getting bunch of other build errors:
Error 35 'int' does not contain a definition for 'Times' and no extension method 'Times' accepting a first argument of type 'int' could be found (are you missing a using directive or an assembly reference?) ServiceStack.Redis\src\ServiceStack.Redis\Messaging\RedisMqServer.cs 192 37 ServiceStack.Redis
and after downloading the ServiceStack branch, I even tried opening ServiceStack-master\src\ServiceStack.sln and tried to build and it's totally broken:
I don't know what's going on here, there can't possibly be this many build errors if any right? I pray not but it seems as such.
Purpose of this post, what I'm asking about and need help clarifying and resolving (mythz???)
I need input from ServiceStack here on the following:
1) are the builds really this broken? Am I imagining this?
2) The branch stucture on GitHub is all over the place meaning I'm finding dup project folders all over and I do not know what this ServiceStack branch is as in it's src folder has a ton of projects there, different versions, as well as doesn't have projects like ServiceStack.Text, etc. so I don't know what's going on here. I want to use the basic core of service stack but there's like repeated stuff everywhere overall on GitHub. I need ServiceStack to clear all this up for me.
Here is my code, so you can see for yourself, it doesn't build.
This one won't build in terms of the ServiceStack projects - it's my solution in which I'm simply trying to include the ServiceStack projects I need along with my own projects that are using ServiceSTack. All I did was downoad those individual projects from https://github.com/ServiceStack then added them to my solution and made sure that any references to each other were now Project references, no longer binary..I removed the binary refs and readded them as project refs. So for example ServiceStack.Common depends on ServiceStack.Text but it was referencing it via binary so I removed it and readded the reference to ServiceStack.Text as a project ref now because in the end we plan on being able to look at and work with the base Stack code. The errors I posted above are happening in this Solution for ServiceStack related projects.
This one won't build - it's a download of the ServiceStack branch master (originally folder name is ServiceStack-master, I removed the -master)
UPDATE: yes I confirmed it's a bad build checked in on the GitHub site (refering to the ServiceStack branch master right above here). I had to remove unused using statements that were causing the build to fail and one of these was a dup using statement causing part of the build failure. I am surprised at this...this stuff should build and people should be checking in code that BUILDS successfully! common! Yes mythz, any dev trying to consume your API would be pissed that there are so many build erros all the time, I can't even get our protype going because this is not the only solution that won't build. First we had the Examples solution all breaking and now the core. I'm willing to fix these if I can but I honestly can't believe it's been a mountain to try to even use this API because of these checked in builds that are failing.
This one Will build because it was Nuget down, so ServiceStack is referencing other layers via binary references in the lib folder so this builds...probably builds here because someone has a working set of builds across all core projects but the stuff on the site for download is not the same revision and broken when you try to use them as project references (source code)?? Just my conclusion as it's only building IF you are using binary references to the lib folder. We want the source, not the binaries to work inside our solution so this is a brick wall for me
There are a lot of big changes happening on master right now - it will be unstable for a while.
I suggest you branch from the v3-fixes tag or pull the references from nuget.
#CoffeeAddict
Yesterday, the mythz answered about these problems in your previous question
"#CoffeeAddict like I said before, ServiceStack's is undergoing significant re-factoring and master in alpha and not for public use. While everything still builds for me and tests still pass in CI, it will be frequently unstable until its in beta. You're likely mixing v3 with v4 dlls which are technically incompatible. The release on NuGet is off the v3 branches of each project, that's what you should checkout if you want to build from src. Any contribs should be done to v3-fixes only - see Contributing docs for more info. – mythz 9 hours ago"
well looks like when I had downloaded all the stack branches, at the time earlier today contributors had checked in broken builds. Fabulous.
I just got latest early this morning, and appears people must have fixed the build and checked some stuff back in for various core projects. Now it builds.
Suggestion to mythz, get CI in place NOW. Don't wait for v4. This cost me a freakin day of trying various things to get this stuff to build and the problems were across several projects. This shouldn't happen, setup CI please. It's 2am and nobody using this project should have to deal with it.
I will contribute but first I had to get a full build to work! Not too happy as no dev would be wasting an entire day getting ServiceStack to build.
To compile v3:
Would someone with true knowledge post PROPER instructions on compiling v4 or v3? I had no luck with the build.bat files for v3 or v4, and opening solutions will not compile for most.
git clone servicestack, servicestack.text, redis, ormlite
make a new directory and copy from under src so you have these:
ServiceStack
ServiceStack.Client
ServiceStack.Common
ServiceStack.Interfaces
ServiceStack.OrmLite
ServiceStack.Redis
ServiceStack.Server
ServiceStack.Text
open csproj for ServiceStack.Interfaces ... right click properties, go to the signing tab, click the combo, new, type in your own signing pfx, I used servicestackInterfaces.pfx (doesn't matter) and make up a password.
Compiles fine, since it has not much referenced.
saved solution as ServiceStackV3 in folder C:\2015\SSv3compile
add csproj ServiceStack.Text, set signature, compiles ok
add csproj ServiceStack.Common, set signature, remove references, add references using solution for interface, text, compiles ok
add csproj ServiceStack.Client, set signature, remove references, add references using solution for interface, text, compiles ok
add csproj ServiceStack, set signature, remove references, add references using solution for client, common, interface, text, compiles ok
add csproj ServiceStack.OrmLite, set signature, remove references, add references using solution for common, interface, text, compiles ok
add csproj ServiceStack.Redis, set signature, remove references, add references using solution for common, interface, text, compiles ok
add csproj ServiceStack.ServiceStack.Server, set signature, remove references, add references using solution for Servicestack, ServiceStack.Client, ServiceStack.Common, ServiceStack.Interface, ServiceStack.Text, ServiceStack.Ormlite, ServiceStack.Redis
compiles ok
have some more trouble compiling the tests...
and finding so many tweaks and changes which are for me maddening to find
(endless agentransack searching for "namespace ISomethinMissing" in *.cs
... there seems to be namespace ServiceStack with cs code contained in projects other than Servicestack...
isn't that VERY improper? (now you require both DLLs? why not one?)
whatever...its free and works for what I wanted.
looks like there is some code leakage from v4...
after getting my head around v3, not sure I want to buy v4 - I will probably buy it in the future, I expect, and hope someday I can just clone and compile from the solution
ANyway, I love servicestack and have been
replacing old webservices
and the config nightmares of WCF with great happiness...
I say it is well worth the initial hassle.
I put this all in code block because I found the editor wouldn't accept this simple text when it was in a numbered list. whatever.