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.
Related
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 am starting out getting more hands-on with FPGAs and have chosen Xilinx.
In a small trial project I have the problem that XST complains about the library proc_common_v_3 is not found. The ise prj file contains paths looking like "../../.." and so on and it gets recreated when trying to change the paths.
When looking in the project list and not the file, the library is referenced using "........", which is different.
Is there another way to make sure ISE handles libraries correct?
ISE Version 14.7
Error message when doing XST->Check Syntax
Xst:2927 - .... line 1: Source file ../../../../../../../../../../../../../Xilinx/14.7/ISE_DS/EDK/hw/XilinxProcessorIPLib/pcores/proc_common_v3_00_a/hdl/vhdl/proc_common_pkg.vhd does not exist
NB: Yes I know there is a thread on this issue, but my comment gets deleted. The answer there is using what seems to be known working paths, but as starting out that is not possible. Better to go for Altera perhaps.
Thanks in advance.
-Michael
I have the following issue, I cannot find a solution on the web, please let me know if you can help me or point me to a proper info about this issue.
To understand the background, Im porting a game from flashDevelop to Flash Builder (please dont give me tips about this comment if doesn't help to my particular problem). Everything works fine right now, the game use a file null.swf as a container of local files (I don't undertand that part completely, but the game has a lot of embed swc files, and the game use the null.swf to access those files, through LoaderMax).
The problem is that everything works fine with a fast build, but it's not working with a standard build, I have the error on Loader class that says "Multiple application domains are not supported on this operating system".
Useful information:
Im using AIR 3.9, compilation flash swf-version=20 (I had 18 when I started with this issue)
null.swf is properly included on the IPA, the code recognize the file, and as I said before it works with a fast build.
For embed swc files, I had to include the files with a compiler argument: "-include-libraries ../../filename.swc ../../filename2.swc etc.."
Thanks for any help.
Regards
It's fixed, using a context:
context = new LoaderContext(false, ApplicationDomain.currentDomain, null);
If I use the third parameter, like ..., SecurityDomain.currentDomain); it doesn't work.
Okey, this is not a core programming question; it is more of a question regarding cgns (CFD general notational system) API.
I've exported a grid/mesh file from ANSYS Fluent (which was first created in Gambit 2.46), and I wrote a very simple Fortran program to open and close it (doing nothing else). To check the file is not corrupt I plotted it in Tecplot.
So, when I compiled using gfortran with the mentioned cgns and ran the program I got this error (as part of cg_error_exit_f())
ADF_Database_Open:File does not exist or is not a HDF5 file
Here is the program
program cavity
include "/usr/include/cgnslib_f.h"
call cg_open_f("Cavity.cgns",CG_MODE_READ,index_file,ier)
!check for error if so exit
if (ier .ne. CG_OK) then
call cg_error_exit_f()
end if
write(*,*)"I kind of opened the file?"
call cg_close_f(index_file,ier)
stop
end program cavity
I'm able to write both structured and unstructured grids in cgns format, without any problem.
I suspect the cgns library I'm using(version 2.5.5 packaged in Fedora 15 and Scientific linux 6.1) is built to support only HDF5, while the exported grid file is written in ADF format.
Any ideas to circumvent this or perhaps adding ADF? Which by the way is not packaged in both the distributions. Any other grid generator which is compatible with cgns version 2.5.5?
I hope I was clear. Any further info required, I would provide.
There is so much that could've gone wrong in here, and I'm afraid you didn't exactly narrow the problem down.
You said you exported a file from Fluent (what kind of a file is it? Be sure!). cg_error_exit_f() gave you an error listed. I'm assuming you have the source of the mentioned routines? In the program you include a cgnslib_f.h file - what's in it? I'm assumming the program compiled without errors of any kind, making this a file format question, not a fortran question.
Again, verify what kind of file Fluent produced.
When I ran into this situation, I discovered the following tools:
hdf2adf
adf2hdf
They are in the cgns-convert package on Ubuntu and are probably available for your distribution as well.
I'm developing a BlackBerry application in which I need to unpack a zip file compressed with PKZIP. The package could have one file in it, or it could have 10; it will vary in each case. I know that the BlackBerry API has native support for GZip and Zlib, although I'm pretty sure that these methods aren't going to be helpful in my case. It doesn't look as if I can extract the individual files using these calls.
I've tried JZlib (http://www.jcraft.com/jzlib/), which compiled fine, but again it doesn't look as if the methods contained therein are going to allow me to pull the individual files.
It appears as if this is possible, as there's an application called Ziplorer (http://www.s4bb.com/software/ziplorer/) that claims to do perform this exact procedure. How they're doing it, however, escapes me.
So here I am after hours of Googling. I'm welcoming any insight into my problem with open arms.
"zip" algorithms are typically offshoots of the Lempel-Ziv-Welch algorithm. They are a fairly efficient stream compression algorithms, but because of how they function, you can't start to decompress at random points in the file, you have to start from the start.
Any product that claims to be able to decompress one file from a zip still has to decompress everything before it in the zip file in order to know how to decrypt the given file, or even, for that matter, where the file is in the archive.
If you can tolerate GPL code in your application, then this library http://jazzme.sourceforge.net/ that might work. However the project (and its parent project http://sourceforge.net/projects/jazzlib/) don't look like they're being developed.