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.
Related
Google dart compiles to javascript code but dart is also a standalone language. I know Dart can also run without javascript (on the vm), but to what does it compile to? Does it compile to C or object code? I couldnt find any information about it.
Im also asking because dart works on mobile devices and ive also read it will be used in some experimental OS called fuchsia.
As far as I know
it's compiled to binary code on-the-fly in the VM,
it's compiled to binary code ahead of time with AoT.
I am currently building a program using GLEW, compiled with MinGW ( in Eclipse ). I built the GLEW libs from the source provided by the GLEW website.
I have been able to use the GLEW declared functions without a problem if I link with the .DLL. However, if I try to link with the static library ( libglew32.a ) with the "GLEW_STATIC" flag defined, I get an error for the function "glewInit()":
undefined reference to `imp_glewInit#0'
If I open up libglew32.a in a hex editor, I can see that there is an entry, but it is named _glewInit#0. So it seems like the disconnect is that my program's compile is trying to append this "imp" string to the front of the function name in the library.
It seems like there must be mis-match of the calling convention here, but I don't know what would cause it yet. There are certainly lots of different ways that GLEW declares the api functions in the header depending on what compiler definitions are set, but I haven't narrowed it down yet.
Any ideas out there?
It looks like that imp prefix gets added for function stubs that are intended to be loaded at runtime from a .DLL. In other words, I wasn't actually staticly linking against GLEW. It turned out that I didn't quite have my eclipse C++ symbols set up correctly, so GLEW_STATIC was not being defined. After making sure that it was set up in the g++ call, it links just fine.
I've tried to formulate the problem in an abstract way, but anyway I give details about the actual libraries in the end.
Dynamic library Addon is statically linked against other library WebRTC which has some code in assembly and this code is linked into WebRTC as object files together with WebRTC's own object files. Lets call this assembly code VP8. Functions of VP8 are marked extern inside WebRTC. Some function Encode() from Addon calls functions of WebRTC which eventually calls functions from VP8.
Now, the application Firefox which is going to load library Addon is quite complex and has its own version (means statically linked) of library WebRTC(let's call it WebRTC2), but an older one.
So, here is a problem: if a call of Encode() is made from the application Firefox, WebRTC functions get called (not WebRTC2, which is correct) BUT when WebRTC tries to call VP8 functions, they get called from the WebRTC2 version (means application's version of WebRTC), but not from WebRTC.
Is there are way to force WebRTC make calls only from local copy of VP8?
Application Firefox is a Firefox browser, WebRTC is a WebRTC library, VP8 is a VP8 codec library (inside WebRTC) and Addon is my Firefox C++ add-on.
UPDATE - DETAILED DESCRIPTION
Here is "unabstract" description of the problem:
So there is a C++ XPCOM add-on which is statically linked against latest version of WebRTC library.
At some point inside add-on a call for encoding a frame is made (method Encode of VP8Encoder class) and it crashes in Firefox all the time, while continue to work well on test programs using gtest framework.
The problem is that at some point inside WebRTC there is VP8 assembly code which is get called for encoding and functions of this assembly code are declared as extern in implementation files. Actually, it crashes on vp8_intra_pred_y_ve_sse2 function.
I've compared three assembly codes of this function: one is from my version of WebRTC (used in add-on), second - where debugger crashed and the third one - from source code of Mozilla's WebRTC.
It turned out that for some weird reason, Mozilla's code get called instead of add-on's WebRTC (they both have same names of course) and as Mozilla's WebRTC code is outdated, it crashes with EXC_BAD_ACCESS.
This probably won't be much help to you, but since no one else has responded, here I go ...
You didn't mention if you're running on Linux, Windows, or something else. My answer is for Linux. I believe Windows loads dynamic libraries differently.
I think what's happening is that you've statically linked against the WebRTC library stub interfaces and those stub interfaces are dynamically linking to the actual implementation, and then getting the first instance of the WebRTC library loaded into firefox instead of the second. Be sure that you're really linking against a statically compiled version of the WebRTC library.
The linux dlopen(3) man page has an interesting flag listed that seems like it would help if your library was the one loading the WebRTC library:
void *dlopen(const char *filename, int flag);
dlopen()
The function dlopen() loads the dynamic library file named by the null-
terminated string filename and returns an opaque "handle" for the
dynamic library. [...]
RTLD_DEEPBIND (since glibc 2.3.4)
Place the lookup scope of the symbols in this library ahead of
the global scope. This means that a self-contained library will
use its own symbols in preference to global symbols with the
same name contained in libraries that have already been loaded.
This flag is not specified in POSIX.1-2001.
Unfortunately, firefox is the one loading your library.
If your library was dynamically linked against WebRTC (which it seems to be) and you explicitly loaded the WebRTC library you want using dl_open() with the RTLD_DEEPBIND flag, than that would solve your problem.
This won't help you much since its not your code that's binding to vp8_intra_pred_y_ve_sse2, but its worth pointing out that gcc also has the dlsym() function which can take a couple of special flags:
void *dlsym(void *handle, const char *symbol);
dlsym()
The function dlsym() takes a "handle" of a dynamic library returned by
dlopen() and the null-terminated symbol name, returning the address
where that symbol is loaded into memory. [...]
There are two special pseudo-handles, RTLD_DEFAULT and RTLD_NEXT. The
former will find the first occurrence of the desired symbol using the
default library search order. The latter will find the next occurrence
of a function in the search order after the current library. This
allows one to provide a wrapper around a function in another shared
library.
You could use that in your code to at least debug what's going on by having it print out the values it gets for a lookup of vp8_intra_pred_y_ve_sse2.
Finally, the same man page notes that linux has a dlvsm() that takes a version string argument as well, allowing the XPCOM code to specify which version of the function it wants:
#define _GNU_SOURCE /* See feature_test_macros(7) */
#include <dlfcn.h>
void *dlvsym(void *handle, char *symbol, char *version);
If it were me, and I was forced to dynamically link the stuff, I'd go with the brute force approach. Go into the libraries and change the function names (in both libraries). Its not elegant, and it will be a headache whenever a new version of either library comes out, but its simple and direct.
I'm having this annoying problem.
I'm doing an ios app in objective-c++. I'm coding the backbone of the app in c++ and the UI in objective-c, because the app is most likely going to be ported to Android (maybe also wp) at a later point. The setup works just fine... That is, until I want to include some c/c++ libraries.
The app is going to do a lot of requests to web services and therefore I've decided to include the libcurl library.
I have downloaded the library, configured it and "made" it and it is installing just fine in /usr/local/lib and /usr/local/include. I have added the libcurl.a/libcurl.dylib to the project, but here comes the problem:
When I want to include it in the .h or .cpp (or .mm) file it says that the file is missing fx.
#include "curl/curl.hpp" // -or similar according to library, always returns "file not found"
The intellisense is also not suggesting the files/libraries when typing. I have also tried with the libcurlpp and Poco libraries which all installs just fine and are added to the project just fine (via Build phases -> Link Binaries with Libraries), but is not recognized in the code.
I have also build libcurl specific for ios via this link:
http://home.comcast.net/~seiryu/libcurl-ios.html
and again everything is working regarding building and installing the library, but again I can't include it in the code...
I really hope it's just because I'm retarded at this and that it is some sort of setting I have missed or don't know about. Searched all over the web now and tried different solutions, all with the same result. I must be including the libraries wrong in some way...?
P.S. I've also tried adding the OS provided libcurl.4.dylib, with same result. Can't include it in the code.
I have two projects in an F# solution.
1. main project with [EntryPoint] and set as the StarUp project.
2. support, the second project, holds a group of support modules. I.e. they are only called and never initiate anything nor serve as the entry point nor are the StartUp project.
For the last module in the support project, compiling in Visual Studio gives
warning FS0988: Main module of program is empty; nothing will happen
when it is run
While using compiler option nowarn inline as #nowarn "988" in the module causing the warning does suppress the message I would rather add something like a dummy function with comments that resolves the issue.
How does one make such a dummy function to resolve the warning?
EDIT
Jack is correct in that my support project was setup as a Console Application instead of a Class Library. Changing to Class Library resolved the warning. It is also nice to know about do () for the other case.
EDIT
While it seemed odd that I would have set a support project as a Console Application, I recently found that for some reason when I made a change to the code in the project, something changed the Output type from Class Library to Console Application. I suspect it has to do with the F# PowerPack and it's build rules, but it's only a guess.
Are you building the support project as a Library or as a Console Application? (This is set via the project properties page.)
If you're building it as a library, then you may need to add a do() at the end of the last file in the project. This is necessary to make the F# compiler happy in a few specific scenarios, like when you create a module which contains only assembly-level attributes (because they're applied to the assembly, the module appears "empty" to the compiler).
You can see an example in my code here:
https://github.com/jack-pappas/FSharp.Compatibility/blob/master/FSharp.Compatibility.OCaml/AssemblyInfo.fs