I've installed neovim with some lsp-servers and setup them. But when I try to get in-module objects, completion suggest almost nothing (module has a lot of functions, but completion doesn't show it).
I have tried a lot of LSP servers (pylance, pyright, jedi, etc) and completion plugins(coq.nvim, nvim-cmp, coc.nvim) with the same result. Now I've installed coc and coc-pyright, it shows this error:"xxx" is not a known member of module. It is false-error because python run this program correctly.
screenshots:opencv false-error, but lsp see opencv module, another false-error
Already, I have no idea what I can do to fix it.
Upd: I think type stubs might be the cause of the error. I don't really understand what is it, but I've found some common similar error with OpenCV lib here. In my case, completion does not work correctly with either opencv nor mediapipe. I've tried to generate the type stubs with pyright and stubgen, but it didn't help.
Related
Whatever the setup I use for coding in Lua is always the same thing: autocompletion works for the standard libraries but not for the 3rd parties or my own libraries.
I tried ZeroBrane studio, VSCode with Lua plugin and Vim with lua ftplugin, exact same behaviour in all 3. I start typing a standard library symbol such as
io.w
And I do get the autocompletion popup showing everything in the io module, and showing the closest method to io.w which would be io.write, with the signature and documentation.
Now I try a 3rd party or my own library such as
require("wx"); wx.
or
require("my_module"); my_module.
Either nothing happens at all, or I get a warning "undefined" on the module name.
If I run the code with the interpreter, it does work. It will call the function in the module just fine. But in the editor, warning and no autocompletion.
Am I missing something?
wxwidgets API comes prepackaged with ZeroBrane Studio, but it needs to be explicitly enabled (you can add api = {"wxwidgets"} to the config file to do that; see Custom APIs section in the documentation). Any other (non-packaged) API would need to be added to the IDE as documented here. There are several popular APIs already provided as plugins; for example, for Redis, Urho3d, openRA and others.
I am trying to create a barcode scanner from a usb camera for Raspberry Pi. I used the tutorial on this site to install OpenCV on the Pi:(https://gist.github.com/rodrigobaron/072a85460e46c48e3bee24fe140b9fdb).
After I used the make command (the third to last step of the tutorial), the following error occurred:
error: 'GL_PERSPECTIVE_CORRECTION_HINT' was not declared in this scope
glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is important to note that I used the simple "make" command rather than "make -j4" as the "j4" option allows it to work on all four cores of the raspberry pi, and it is suggested to eliminate "-j4" if an error occurs.
Upon searching for what caused this issue, I have discovered that it may be due to OPEN_GL support not needing to be enabled, or it might also be caused by an error in the header files. I have not determined how to re-write the make file to eliminate OPEN_GL support, nor do I feel comfortable altering the header files without good cause. I would appreciate any advice on fixing the issue as I feel I have exhausted my options. Thank you.
Disabling OPENGL cmake parameters (-DWITH_OPENGL=OFF) should fix the problem. i.e.
cmake -DWITH_QT=ON -DWITH_OPENGL=OFF -DFORCE_VTK=ON -DWITH_TBB=ON -DWITH_GDAL=ON -DWITH_XINE=ON -DBUILD_EXAMPLES=ON
Another option is to go to line 3229 and just comment that line out. It will build then.
This may not be the best method, but it worked for me..my file looks like this.
opencv/modules/highgui/src/window_Qt.cpp
void OpenGlViewPort::initializeGL()
{
//glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);
}
I am trying to get luasocket working in the lua scripting environment of Bizhawk, but so far without luck. I downloaded the vc8 version of luasocket here, made sure I have vc8 installed, and checked the lua version that came with bizhawk: 5.1
But, when I start the script I get the following error:
LuaInterface.LuaScriptException: error loading module 'socket.core' from file './libs/socket\core.dll':
Das angegebene Modul wurde nicht gefunden. (the given module was not found)
The lua code:
package.path = package.path..';./libs/lua/?.lua'
package.cpath = package.cpath..';./libs/?.dll'
local socket = require("socket")
The file system structure:
libs
> lua
> socket
ftp.lua http.lua smtp.lua tp.lua url.lua
ltn12.lua
mime.lua
socket.lua
> socket
core.dll
> mime
core.dll
It seems to find the files, because when I had the file structure wrong it gave me actual file-not-found errors.
My best guess is that there is some kind if incompatibility between the lua that is shipped with Bizhawk and the external luasocket library binaries, but I am out of ideas.
This guy's set it up: https://github.com/antogerva/emuHostUDP (dearchive to emuhawk.exe base directory). His example seems to work, but it might not contain everything you need. Like HTTP for example.
Since project is complex and the luasockets examples are awful, here's a one-liner for testing http:
print(require("socket.http").request{ url = "http://www.google.com" });
Following his model, I applied the following method: contents of lua dir to root; lua5.1.dll to root. Note that we will not be using the core.dlls from luasockets. This is because BizHawk now has them integrated; and this was necessary to work around a bug with luasockets in bizhawk.
More specifically, we have
/emuhawk.exe
/Lua (untouched)
/Socket/ftp.lua,http.lua,etc.
/ltn12.lua,socket.lua,mime.lua
/lua5.1.dll
/mytest.lua
(with files from http://files.luaforge.net/releases/luasocket/luasocket/luasocket-2.0.2/luasocket-2.0.2-lua-5.1.2-Win32-vc8.zip)
I can't say why precisely all of this is necessary, but I think it's miraculous that it works, given that we have a customized lua.
When using lua, if you find a directory structure that works, it's best not to wrestle with it any further.
Update:
(may be out of date) As soon as you do something nontrivial you may find bizhawk crashes. It seems this is due to a conflict with luasocket's "protection" system. Inspect http.lua and observe the code at the end which sends a function through socket.protect to wrap it. Remove the socket.protect wrapper and it should solve this problem.
I suspect that it's because of the dependence on lua51.dll. luasocket core.dll library is linked against lua51.dll (most likely; you can ran depends or similar tool to find out for sure), which is probably not present and this prevents socket.core from being loaded.
Even if you find lua51.dll, it's not likely to work if Bizhawk is statically compiled with lua51.dll as this will lead to two interpreters loaded into the same process, which is a recipe for seg faults.
There are three main options, but they all depend on how Bizhawk project is structured:
Bizhawk is compiled against lua51.dll (and this dll is present as a standalone file). In this case you need to make sure that the socket/core.dll you are using is compiled against the same library and it should work (as long as the run-times are the same and lua51.sll is available in PATH).
Bizhawk is statically compiled with lua51.dll. The simplest option is also statically compile luasocket libraries into the executable.
If option 2 is not available, then you need to use a proxy library and export Lua symbols from the Bizhawk executable as described in this SO answer: https://stackoverflow.com/a/28310666/1442917
If none of this helps you to solve the problem, you'll need to get depends for your Windows platform and run it in the "profiling" mode, which will tell you the exact error that happens when that DLL is loaded.
I've been trying to load a library into lua file. Sparing the details, as they are not really important, I have tried this many ways.
The final way, and the one I believe to be correct although I still can't get it to work, is to use "package.loadlib". See code:
ed = package.loadlib("Encode_Decode.lua", "luaopen_ed")
print(ed)
But when I run the program I get this error:
Encode_Decode.lua is either not designed to run on Windows or it
contains an error. Try installing the program again using the original
installation media or contact your system administrator or the
software vendor for support.
I know the program runs because I used it internally to test it's encoding and decoding abilities and it worked fine. I'd really prefer not moving the contents of the library over as my main lua file is crowded as it is. I will if I have to though.
Yes it is in the main folder. I've also tried changing the extension of the library file into a .dll, with the same error.
What am I doing wrong?
I apologize in advance if this is a duplicate, I did my best to research this problem as thoroughly as I could. But to be honest it's almost 3 AM and I've been searching for almost an hour.
Stupid beginner mistake, used the wrong syntax.
require("Encode_Decode")
print(dec("bnVs")) --returns "nul"
package.loadlib is used for loading shared libraries; i.e. .dll or .so files. You're passing a .lua file to it, so Windows attempts to load it as a .dll and fails when it can't.
To load Lua source code, you can use dofile. Alternatively, you can use require, which is a bit more complex, but handles loading modules only once and works with both Lua and C modules.
Why is there no compile time errors or warnings when I call a function in another module that doesn't exist or has the wrong arity?
The compiler has all of the exports information in a module to make this possible. Is it just not implemented yet or is there a technical reason why it is not possible that I am not seeing?
I don't know why it's missing (probably because modules are completely separate and compilation of one doesn't depend on the other really - but that's just speculation). But I believe you can find problems like this with dialyzer static analysis. Have a look at http://www.erlang.org/doc/man/dialyzer.html
It's part of the system itself, so try including it in your workflow.
It is as others have said. Modules are compiled separately and there is absolutely no guarantee that the environment which exists at compile-time is the same as the one that will exit at run-time. This implies that doing checks at compile-time about the existence of a module, or of a function in it, is basically meaningless. At run-time that module may or may not be loaded, the function you call may or may not be defined in the module, or it may do something completely different from what you expected.
All this is due to the very dynamic nature of Erlang systems. There is no real way as such to define what is in system at run-time. Hot code-loading is a part of this and works properly because of the dynamic nature of the system. It means you can redefine the system at run-time, you can load in new versions of existing modules with a different interface and you can load in completely new modules and remove existing modules.
For this to work all checks about the existence of a module or function must be done at run-time.
Tools like dialyzer can help with this but they do assume that you don't do anything "funny" at run-time and the system you check is the same as the system you run. Which is of course all good, but very static. And against Erlang's nature which is to be dynamic, in everything.
Unfortunately, in this case, you can't both have your cake and eat it.
You may use the xref application to check the usage of deprecated, undefined and unused functions (and more!).
Compile the module with debug_info:
Eshell V6.2 (abort with ^G)
1> c(test, debug_info).
{ok,test}
Check the module with xref:m/1:
2> xref:m(test).
[{deprecated,[]},
{undefined,[{{test,start,0},{erlang,foo,0}}]},
{unused,[]}]
You may want to check out more about xref here:
Erlang -- Xref - The Cross Reference Tool (Tools User's Guide)
Erlang -- xref (Tools Reference Manual)
It is due hot code loading. Each module can be loaded in any particular time. So when you have in your module A code which calls function B:F then you can't tell it is wrong in compile time when your source code of module B has no function B:F. Imagine this: You compile module A with call to B:F. You load module B into memory without function B:F. Then you load module A which contain call B:F but don't call it. Then compile new version of module B with B:F. Then load this new module and then you can call B:F and everything is perfectly right. Imagine your module A makes module B on fly and load it. You can't tell in any particular time that it is wrong that module A contain call to nonexistent function B:F.
In my opinion most, if not all, compiler does not verify that a function exists at compilation. What it is required in general is a prototype declaration of the function: the type of the return value, the list and type of all arguments. This is done in C/C++ by including some_file.h in each module definition (not the .c or .cpp).
In Erlang this type verification is done dynamically, while the program is running, so it is not necessary to include these definitions. It is even totally useless because Erlang allows to upgrade the application in run, so the function type may change, or the function may disappear, on purpose or by mistake, during application life time; it is why the Erlang designer have chosen to make this verification at run time and not at build time.
The error you speak about generally occurs during the link phase of the code generation, when the "compiler" tries to gather all together some individual pieces of object code to build an executable file or a library, during this phase the linker solves all the external addresses (for shared variable, static call...). This phase does not exist in Erlang, a module is totally self contained; it does no share anything with the rest of the application, no variable nor function address.
Of course, it is mandatory to use some tools and make some test before updating a running production program, but I consider that these verifications have exactly the same level of importance than the correctness of the algorithm itself.
When you compile e.g. module alpha which has a call to beta:some_function(...), the compiler cannot assume some specific version of beta to be in use at runtime. Maybe you will compile a newer version of beta after you compiled alpha and this will have the correct some_function exported. Maybe you will upload alpha to be used on a different host, which has all the other modules.
The compiler therefore just compiles the remote call and any errors (non-existent module or function) are resolved at run time, when some version of beta will be loaded.