Neovim Rust LSP diagnostics no longer working in buffers - rust

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.

Related

All node usb libraries do not work and all give some kind of error

I'm developing a VSCode Extension where you can develop CircuitPython code. I want it to be able to upload your code to your pico, or whatever microcontroller you're using.
For this I need to detect all usb drives that are connected, I've tried libraries like node-usb, usb-detection, etc. But they always give some kind of error, for usb-detection for example you need to rebuild the library with this command:
./node_modules/.bin/electron-rebuild
But then I get greeted with this:
text here: https://pastebin.com/E7bjtWgP
I have absolutely no idea what anything of this means, I've installed vs build tools 2022, 2017 and even added it to my community installation.
After that I tried the usb library. Which again, greets me very kindly with:
I've also tried some other libraries but they all give a similar result. Some do this:
And I've also seen some very questionable things like this:
I've been googling, and debugging now for roughly 4 hours and atm I'm tired so I'll probably try again in a couple of hours.
EDIT:
I've made an entirely new project, moved over all the code and it now works. I have absolutely no idea what the problem was but at least its working now.

Does go have OS-specific packages that cannot be used on another OS?

I cannot call myself an absolute beginner in go, and I'm definitively not an expert.
Today, I noticed something VERY confusing. I was experimenting with Unix sockets and Windows named pipes, and from my research, there are 2 packages that support Windows named pipes:
https://github.com/natefinch/npipe
https://github.com/Microsoft/go-winio (I could not find ANY documentation, help, how-to-use, whatsoever about this package)
My OS is Linux, and I decided to give it a go: go get the package(s), and write the code to later test on a Windows machine, but, to my surprise, at least in VSCode, those packages are not recognized by the tooling.
When I look at npipe for example, I see it only has npipe_windows.go, which, if I'm not mistaken, is supposed to automatically be used on Windows.
So, I think there is the concept of OS-specific packages in Go, right? And if so, does it mean that I cannot use, for example, VSCode's go tools to code against Windows packages on Linux?
That, in my opinion, would be extremely inconvenient to have to switch systems in order to write something that works both on Linux and Windows... Although I guess that's only true if we're developing on Linux, and Windows should cover both.
But for me, it doesn't make sense NOT to be able to develop something on Linux; the best environment to develop on IMHO (except Apple-related code of course)
Am I missing something here?
Thank you
So, I think my question actually involves more the tooling rather than the go language itself. gopls is the tool used by VSCode if you choose to use the go language server.
As thre README says, it's in alpha and not stable, and there are known issues listed on the repo, which seem to be the source of my confusions.
I think the main issue that's related to what I'm seeing is:
x/tools/gopls: does not handle build tags

C++ entry points not showing up in node.js profiling output

When running node --prof <command>, then later node --prof-process on macOS, my profiling output no-longer shows any of the C++ entry points, leading to a lot of unaccounted-for gaps in my profiling data. Changed around the same time, I now just see the node binary in these profiling trees where it wasn't showing up before, so it's like the profiler is no-longer able to "dive in" to the internals of node.
I think this started when trying to improve dtrace permissions with csrutil, but I've restored things back to their factory settings and this still happens.
What causes C++ entry points to not show up in traces? Is there a way to fix the issue?
Update:
Just tried turning off SIP entirely with csrutil disable (which is a bad thing to do), and the problem persists, so maybe SIP is a red herring here.
The amazing wizards in the node.js github issues figured this out.
In short, I learned that two commands are used by the profiler on macOS: c++filt and nm. When I tried reporting which versions of those commands I had installed, I got this message back for nm:
» nm --version
Agreeing to the Xcode/iOS license requires admin privileges, please run “sudo xcodebuild -license” and then retry this command.
Apparently the requirement of accepting the license was added, perhaps after an upgrade, and this was blocking the ability for the profiler to look up and demangle C++ symbols. After I accepted the license, the profiler started working normally again.
Hopefully this helps others running across the same scenario.

AHBot in an AzerothCore 3.3.5 Server

Does anyone have a guide on setting up AHBot in an AzerothCore 3.3.5 server? I can find no mention of ahbot in the world.conf and no DB tables like auctionhousebot in the database or any references. It is included in TrinityCore so all the google references that I find point me back there.
Our server is just two of us and it would be nice to have some items on the auction house. At the moment, if you need a silver bar you have to go out in the world and find it. That was exciting the first couple of times... but gets old.
I followed the guide to install off github: https://www.azerothcore.org/wiki/Installation and am using the latest release under Ubuntu linux.
Thank you for any help. You are my last hope...
AHBot is not currently an 'official' supported module of AzerothCore (which would be why you aren't finding any settings in the worldserver or anywhere else regarding it).
There is a module in development that isn't currently part of the AC list, but I've gotten it working on my personal server: https://github.com/AyaseCore/mod-ahbot Note that this is a bit different than a normal module as there is also a git patch that needs to be applied manually.
Theres a module in azerothCore repository you have to apply patch manually but it wont compile on Win x64 and unix x64 comes up with an error about 9 arguments, but seems to compile for some

Porting a markdown-live-preview-in-vim plugin from *nix to Windows

I need your help. Because I've no idea what I'm doing.
There is this nice plugin vim-instant-markdown I recently stumbled onto. Basically, it's a live preview in a browser, running in the background, while you're writing your text in markdown plugin, and I like the concept.
So, I've tried to get it to work on Windows,
installed Ruby (rubyinstaller-1.9.3-p125)
installed Ruby-DevKit (DevKit-tdm-32-4.5.2-20111229-1559-sfx)
followed instructions on https://github.com/oneclick/rubyinstaller/wiki/Development-Kit
gem install redcarpet pygments.rb
installed node (node-v0.6.10)
npm -g install instant-markdown-d
So far so good,
I open a markdown file in Vim, and it opens (pause button works here) a command line window with my text inside. Browser not seen anywhere.
In the plugin there is an /dev/null "thing" (I'm not an unix guy, more than I needed to be, which wasn't very much - just an ordinary user for most part). /dev doesn't exist on Windows.
To put long story short, my question is - can this be made to work on Windows, the way it should work, or is it a waste of effort even to try it to get it to work?
I'm welcoming all constructive ideas and suggestions.
glad you found this useful enough to want a Windows port! I think it definitely can be done, you just might need more dependencies and hackage.
First of all, understand that there's a server component that is used apart from the actual .vim file to make this work, which is started and stopped on demand. You will definitely need to look at its code, which can be found here.
The server uses open on OSX and xdg-open on Linux to open a browser window, neither of which exist on Windows. On Windows, you can use start (more here). Try to find a way to make the browser window open in the background, and not steal focus, otherwise it will be very annoying.
Also, curl is used to send commands to the server, and curl doesn't exist for Windows. Indeed, I don't think anything similar exists. There is a curl Windows port, though IMO it kinda sucks to add such a thing as a requirement for the plugin...
It seems that you've taken this on at least partially as a learning experience, so I hope you can make it work and send back a pull request! (Of course feel free to keep asking questions if you're stuck) But in the (hopefully unlikely) event that you lose interest or give up, create an issue in github requesting Windows compatibility, and I'll see if I have time to implement it. Also, keep in mind that some questions/comments will be better suited to the project's issues area than here.
Good luck!

Resources