I have no clue but suddenly my vscode became unable to resolve to own package.
building main.go succeeds so I think the code itself does not have a problem.
I'm sorry for lucking information but if anyone encountered the same problem and solved it, please tell me how. I really appreciate it
this was due to I updated to experimental version for golang language server
I completely reinstalled vscode and it worked again
Same situation Happend for me long time main reasons vscode crash/old versions compatibility or may be other issue.
go side pkg section not able 'get' the proper info
Related
Cypress for me is often stuck in the "Your tests are loading" screen. I am really confused as to why it happens, and restarting Firefox/crome doesn't help either. It doesn't depend on any code, happens completely randomly and today my luck was down so I was looking more at that then at my code. any help is welcome, and thank you in advance.
Late reply, but are you using webpack-preprocessor? I am and the same issue happened to me when I upgraded to Webpack 5 lately.
The solution was to downgrade to Webpack 4.
In this case it is a known issue, there is an open Pull Request on Cypress github that should hopefully fix it: https://github.com/cypress-io/cypress/pull/15611
If you're coding a project that's using another version and you install the project without using nvm use it will install the latest dependencies which may break the code that doesn't support the new dependencies version.
Check the original code Webpack version and be sure it is the same installed locally
I'm trying to go get go.etcd.io/etcd/tools/benchmark.
Previously this has worked, flawlessly. However when I try to do it currently I have alternatively got no errors and I've had it fail on me with:
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/balancer_conn_wrappers.go:28:2: use of internal package google.golang.org/grpc/internal/buffer not allowed
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/clientconn.go:49:2: use of internal package google.golang.org/grpc/internal/resolver/dns not allowed
go/src/go.etcd.io/etcd/vendor/google.golang.org/grpc/clientconn.go:50:2: use of internal package google.golang.org/grpc/internal/resolver/passthrough not allowed
The first time I ran it on a new go-1.13 installation it worked, but the following times it has failed as above.
The repo has not changed as far as I can tell in the past 8 months and I've tried on various golang versions but all so far have failed (bar the go-1.13 on that first try...).
Any assistance debugging this would be greatly appreciated!
I have both a workaround and an official fix.
The workaround:
Here I defined a go.mod which then used a previous version of the library.
The official fix:
This was fixed upstream and thus no one else should experience this.
I guess you can try by removing vendor folder from the go.etcd.io/etcd repo. Also disable the vendoring mode. It should work.
Recently, I have been getting this error a lot and from some research, I got to know that the cause for it is the Xamarin.Build package.
The error text is as follows:
The "User7ZipPath" parameter is not supported by the "XamarinDownloadArchives" task. Verify the parameter exists on the task, and it is a settable public instance property.
I have tried the solution here and here but nothing helped.
My configuration is as follows:
Xamarin version: 4.7.10.38
Visual Studio 2015
The Error occurs when I update the xamarin build NuGet package, If anyone has a solution to this problem please help me.
Thanks.
At last after all this time I was able to solve this problem.
The problem was with Xamarin.Build.Download package.
Now this package had a problem in version 4.7 where it is unable to find the XamarinDownloadArchives task.
I checked a lot of places and for the answer but nothing seemed to help with this issue after that I removed the bin, obj folders for all my projects.
And Updated my Xamarin.Build.Download package to version 0.4.11 and everything started working.
I hope this helps someone else, In case of any queries related to this issue feel free to comment.
Finally! I've come with a solution. The problem was in the Xamarin.Build.Download package, v0.4.0. It was a annidated dependency (in iOS) of Xamarin.Forms.GoogleMaps v2.2.1.
Updating Xamarin.Forms.GoogleMaps to v2.3.0 (the most recent version as of today) solves the issue. Make sure to clean the solution after update NuGet dependencies, though.
When I try to install devtools in Rstudio 3.2.3 (Windows 10) using the command install.packages("devtools"), I get the following message:
warning in install.packages :
'lib = "c:/Program Files/R/R-3.2.3//library"' is not writable
I'm a newby and I've been hunting for solutions but so far am coming up empty. I would appreciate any advice that might get me through this step. Thanks.
I stumbled upon the same issue earlier. This "problem" arises when you try to install a library for the first time and R does not have a a dedicated library for it yet.
Two pop-up should appear one after the other when you try to install a package like:
install.packages("ggplot2")
The questions are the following:
Would you like to use a personal library instead?
Would you like to create a personal library 'C:\Users\bartlein\Documents/R/win-library/3.2' to install packages into?
Answer yes to both questions and you should be fine.
The ressources I used came from here.
I should mention that I originally posted this as an issue on Neovim's tracker, but it hasn't been getting a ton of traction there lately and I'm beginning to suspect that it's more an issue with my setup rather than Neovim itself.
Essentially, I had stopped building neovim nightlies for a few months. Having heard that it's getting integrated terminal support I decided to rebuild using the latest source, only to get a persistent, odd error. No matter what my build settings are, it always boils down to make hitting an error when it has to compile a file called loop.so. I hadn't noticed this issue with any other software I try to build, but I suspect it could be an issue with my environment.
Does anyone here know what this file's role is, and why the compilation could be failing at that point?
You might need to install the full Xcode app and not just the command line. This fixed the issue for me.
The issue turned out to be a bad typedef in a libuv header, object.h.