gi , gy, gd, gr not working as expected for c++ on Ubuntu 22.04 - coc.nvim

the situations are the same as follows: https://github.com/neoclide/coc.nvim/issues/3497
On gd
It seems to go to the header file declaration instead of the definition.
On gy:
[coc.nvim]: Error on "jumpTypeDefinition": typeDefinition provider not found for current buffer, your language server doesn't support it.
On gi
[coc.nvim] implementation not found
On gr
It only gives usages in the same file and not the whole repo.

Related

Vulkan.hpp compiling on one system but not another

I have the following generic function:
template <typename U>
auto CastVkArray(std::vector<U> &unique_handles)
{
std::vector<typename U::element_type> handles;
for(auto &u_handle : unique_handles) handles.push_back(*u_handle);
return handles;
}
The problem is/was that although I thought I instructed premake5 to use the version under a local directory in my project, it was using the system's installed version instead. The version mismatch meant that I was using an old vulkan.hpp header rather than the one I need.
Which I am temporarily using to convert unique handle arrays to non unique arrays. This code compiles just fine on my desktop (arch linux), however on my laptop (ubuntu) I get the error:
error: no type named ‘element_type’ in ‘class vk::UniqueHandle<vk::CommandBuffer>’
std::vector<typename U::element_type> handles;
I use premake 5 to generate my build environment and the script hasn't changed between the 2 systems. I checked that all the libraries I am using are the same version, in particualr, I made sure that the vulkan sdk is the same between the 2 computers.
I deleted and rebuilt my code multiple times to test for potential race conditions in compilation (just to see if anything changed), the error is always the same.
The one difference that I have found is that the reported version of premake in arch is 5.0.0-dev but on ubuntu it is 5.0.0-alpha14
But I have not been able to find the dev version on the official github repository of premake.

"Module openfl.display.Shader does not define type Shader" when trying to do a release for neko or windows [Flash Develop/Haxe]

this is somenthing I was trying to solve for HOURS, but I don't get why this is not working.
First of all, I'm trying to do a release for neko or windows in Flash Develop. My project is a OpenFl one, and the language is Haxe 3.
What I have installed:
actuate: [1.8.6]
flixel-addons: [2.3.0]
flixel: [4.2.1]
hxcpp: [3.4.64]
lime: [2.9.1]
nape: [2.0.20]
openfl: [3.6.1]
And yes; I'm using haxeFlixel.
When I try to do a release in windows or neko, these errors appear:
-E:/HaxeToolkit/haxe/lib/openfl/3,6,1/openfl/_internal/renderer/opengl/utils/SpriteBatch.hx:12: characters 7-28 : Module openfl.display.Shader does not define type Shader
-E:/HaxeToolkit/haxe/lib/openfl/3,6,1/openfl/_internal/renderer/opengl/utils/SpriteBatch.hx:12: characters 7-28 : For function argument 'ax'
-src/skill/SkillLogicProjectil.hx:13: lines 13-54 : Defined in this class
-E:/HaxeToolkit/haxe/lib/openfl/3,6,1/openfl/_internal/renderer/opengl/shaders2/Shader.hx:11: characters 7-28 : Module openfl.display.Shader does not define type Shader
The most funny thing is: I'm not even using Shader in SkillLogicProjectil. That class only creates a sprite that follows a Player and has a var with the sprite that represents the skill.
If I comment this class, the error is in another class, and finally ends in my GameState.
This error doesn't appear when I do a release in html5. In html5 there are no problems with the release, but I can´t make the game load without Flash Develop running the process in http://localhost:2000/. I need to make a release that can be opened with a computer, without using Flash Develop to open it.
What can I do?.
The new version of Flixel supports Haxe 3.4.3 and OpenFL 8, have you given these versions a try?

How to get Racer working with Atom?

I've followed the instructions on this page to try to get the Racer package for Atom working in a 64-bit Windows OS. But I've so far been unsuccessful.
I installed Rust from this location. I installed Atom and its packages 'language-rust' (0.4.9) and 'racer' (0.20.0). I successfully compiled racer.exe using the source repository found here, producing a 3.4-MB binary. The Racer package asks for two directories to be specified by the user:
Path to the Racer executable
Path to the Rust source code directory
For the former, I pointed it at the location of the racer.exe binary I compiled. I'm not sure what to enter in the latter field.
If it's left blank, the plugin doesn't work (many errors are generated while typing). I gather that the Racer plugin wants to be pointed at a directory containing "the Rust source code", but I don't know what it's referring to. The package's documentation says, "The Rustc source has to point to the base directory of the source code.". The source points at the base directory of the source? I have no idea what that means, so I'm stuck.
The "rust source code directory" refers to the source of the compiler and standard library, such that racer can look up definitions for types and functions defined in the standard library.
Using rustup, you can run the command
rustup component add rust-src
- which will download the source code to a folder like
.multirust/toolchains/<your-toolchain>/lib/rustlib/src/rust/src
This is the path you want in step 2.
Alternatively, you can get it from here: https://github.com/rust-lang/rust/tree/stable

Modifying gethostbyname (res_search) source code - Linux Ubuntu 14.04 LTS

I am trying to modify the behaviour of the DNS lookup functions in Linux for my project by setting it to write a random string in a file as a test.
Linux use some DNS resolver functions, mainly gethostbyname. Looking forward, I found out that the resolver functions are within the glibc6 library. So, I downloaded it, compiled, generating the libresolv.so, libnss_dns.so dynamic libraries. Then, I replaced the existing ones on my system, at /usr/lib/x86_64-linux-gnu/.
Note: I found out these libraries are the ones that resolves queries by modifying gethostbyname code and compiling again. Then, I saw which dynamic libraries changed.
By creating a program that uses res_query directly (a resolver function) and compiling with -lresolv, it works (I used ldd command and it uses the resolver library I created). But, using gethostbyname directly from the code, using wget or browsing the web I can't get it right.
What am I doing wrong?
I discovered what should I do:
Firstly, the function called isn't gethostbyname. It is _nss_dns_gethostbyname3_r, defined in resolv/nss_dns/dns-host.c. Looking at the source I realized that this function called another one to resolve DNS names, __libc_res_nsearch, defined in resolv/res-query.c. So this is the function! I added some file writting commands there and it worked like a charm. I called it from C code using gethostbyname, used wget and Firefox, all worked. When you compile the code you should replace the libresolv.so of your system by the new one.
Note: my glibc version is 2.19.
I hope this helps someone.

OpenCV 2.0 C++ API using imshow: returns unhandled exception and "bad-flag"

I'm trying to use the new OpenCV 2.0 API in MS Visual C++ 2008 and wrote this simple program:
cv::Mat img1 = cv::imread("image.jpg",1);
cv::namedWindow("My Window", CV_WINDOW_AUTOSIZE);
cv::imshow("My Window", img1);
Visual Studio returnes an unhandled exception and the Console returns:
OpenCV Error: bad flag (parameter or structure field)
(Unrecognized or unsupported array type) in unknown function,
file ..\..\..\..\ocv\opencv\src\cxcore\cxarray.cpp, line 2376
The image is not displayed. Furthermore the window "My Window" has a strange caption: "ÌÌÌÌMy Window", which is not dependent on the name.
The "old" C API using commands like cvLoadImage, cvNamedWindow or cvShowImage works without any problem for the same image file. I tried a lot of different stuff without success.
I appreciate any help here.
Konrad
As I just commented, imread isn't working for me either. A little googling shows other people having the same problem; I guess it's a bug in the library code. For now, here's a hacky workaround:
IplImage* img = cvLoadImage("lena.jpg");
cv::Mat lena(img);
cvReleaseImage(&img);
This way, you can at least use the C++ API for the rest of your stuff.
There's help for this issue.
The solution is, that the usual proposed opencv library files in the linker are not working properly. Instead try to use the debug library files by this:
In Visual C++:
go to Project->Properties (or Alt-F7)
Configuration Properties->Linker->Input->Additional Dependencies
replace the usual
" cv210.lib cxcore210.lib highgui210.lib" by
" cv210d.lib cxcore210d.lib highgui210d.lib" - which are the debugging libraries.
The OpenCv 2.0 API commands should work now.
I had the same problem described above which turns out to be caused by the settings of the linker.
I found the answer in another thread,
OpenCV 2.3 and Visual Studio 2010.
To repeat it here:
Properties of your project (right click on it)
C/C++
General
include directory add the < your directory >\OpenCV2.3\include\opencv2, < your directory >\OpenCV2.3\include\opencv and < your directory >\OpenCV2.3\include
Linker
General
List item
Input
Add all the libs like opencv_core230d.lib opencv_highgui230d.lib and so on...
Once I've done the above, I can run imshow and imread + all other cpp functions seamlessly! OP's problem has probably already been resolved, but hopefully this will be useful to other people who are led here looking for the same solution.
Are you sure you added the whole path starting from /home/.... I had the same problem as you but when I added the whole path, things work out pretty well. The whole path had to be added despite the fact the path exists in the include files.
imread in openCV unlike Matlab does not return an error when file/folder is not found - instead it returns a null matrix, which in turn is reflected as an error during imshow.
Also, imread does not look for image files in the included folders or the workspace. So, specify the entire path whenever possible.
Please take a note of this for future references.
Firstly, you'd better compile your own version OpenCV.
I had the same error with the build (I got from Sourceforge), and solved by compiling my own version in debug and release versions.
And make sure you change the original system env variable PATH to the new build folder build/bin, then you could build and run the imshow() in Debug mode.
I believe this might be related to unicode.
Try the macro _TEXT()
For example:
cv::Mat img1 = cv::imread(_TEXT("image.jpg"),1);
Unicode in Visual C++ 2

Resources