I am trying to load a DLL power.dll following this tutorial. However, I am getting the warnings
WARNING: ...it\faforever\fa\lua\ai\aiarchetype-managerloader.lua(48): could not load package `power' from path `E:\lua\'
WARNING: stack traceback:
WARNING: [C]: in function `require'
Unfortunately there is not more output than that. All I know is that the game I try to modify "uses uses a slightly modified version of Lua 5.0." [1] - whatever "slightly" is supposed to mean ..
The thing is that I tested this import with a Lua 5.3 standalone and it works. I can call that square() function (see tutorial) but it's not working with the game.
Of course there is a chance the they simply do not allow loading a .dll simple as that but of course I hope than it's simply just me not seeing something or missing something out.
Is there a chance that somebody could help me with this (quite specific) question?
Am I doing it right, speaking in LUA 5.0 standards:
The file which is supposed to load my DLL simply calls:
_G.LUA_PATH = "E:\\lua\\"
require("power")
At first I got an error becacuse LUA_PATH was not defined as I called require. After defining LUA_PATH the require seems to work but something else still seems to fail here ..
[1] http://supcom.wikia.com/wiki/Lua
Related
I know it can be done, but I'm having trouble getting it working. I'm still finding my feet with Haskell.
I tried using postgresql-typed, but it wouldn't compile. They don't enable the QuasiQuotes extension, so I don't understand how their code would ever compile. It also fails with an error on the useTPGDatabase statement. I cloned the library's source code from Github, but their tests failed to compile using stack with exactly the same errors.
I considered using hasql-th, but it's not on stackage.org, which immediately puts it in the "too hard basket.". I considered switching to nix but that seems like even more effort.
Does somebody have a reliable recipe for getting an environment working that type-checks SQL at compile time in Haskell?
I considered using hasql-th, but it's not on stackage.org, which immediately puts it in the "too hard basket."
All you need to do is add the latest version of hasql-th to the extra-deps section of your stack.yaml file and all other deps that Stack will suggest to you when you build.
In the end your stack.yaml file should look something like this:
resolver: lts-17.9
extra-deps:
- hasql-th-0.4.0.8
- headed-megaparsec-0.1.0.4
- postgresql-syntax-0.3.0.3
Anticipating a question in the spirit of "Why is it not listed on Stackage?" It's just that nobody has gotten to list these packages yet.
When serving lit-element components with nollup then I keep getting the following error in the browser console that I am not able to track down:
toast-messages.js:56 Uncaught TypeError: modules[number] is not a function
at create_bindings (toast-messages.js:56)
at toast-messages.js:57
at Object.48 (toast-messages.js:365)
at create_bindings (toast-messages.js:56)
at _require (toast-messages.js:141)
at toast-messages.js:249
at toast-messages.js:251
Can anyone point me in the right direction? (I can share my rollup.config.js if required)
This error means that a module has been requested, but there's no module with the specified id (number) included in the bundle. This can happen for a variety of reasons:
There's a call using require passing an invalid id.
Passing a string or something other than a number into require.
Using a library that was compiled to CommonJS but was not transformed to ESM.
It's likely that you're missing the CommonJS plugin, or if you are, then the CommonJS isn't able to catch the require call and convert it. The latter can happen because of obfuscation in the library code. CommonJS plugins work by using static analysis. It would be very difficult for the plugin to transform the following:
var r = require;
r('my-library-code');
Without executing the code, it would be difficult for static analysis to track this. A best effort attempt can be made, but there will be always a situation where it could fail.
So here's the following steps you should take:
* Confirm that the CommonJS plugin is being used.
* If it is, check the file in node_modules for unusual patterns.
* If there is, file an issue with the CommonJS plugin maintainer and see if it's possible to solve, and if not, you might need to contact the maintainer for the toast-message library.
I do realise I'm posting this very late, but better to answer later than never! To avoid this vague error in the future, in 0.10.2 of Nollup I've added a user friendly error that list some things to check for.
Hope this helps!
Ok folks this is a long one, so please bear with me. I'll preface this by stating that I am -for all intents and purposes- a noob.
I'm trying to link to a running instance of a program (ETABS) using IronPython. The program has an API and decent documentation on how one can go about hooking into the running instance (EXAMPLE). However, their examples are for Python, C#, VB.net but not IronPython.
No biggie I thought, the Marshal module can be used to hook into it. So I tried this:
from System.Runtime.InteropServices import Marshal
csiApp = Marshal.GetActiveObject("CSI.ETABS.API.ETABSObject")
SapModel=csiApp.SapModel
Unfortunately I get errors on that last line - "ETABSObject has no attribute SapModel".
And yes, I've tried running it with csiApp.SapModel() as well with the same results.
So I delved deeper into it and apparently the object needs to be cast into another type - at least that's the way its been done for the C# example (LINK). Since - to my knowledge - we can't really cast objects around in Python (and yes, I've already tried clr.Convert) I came to the conclusion that the object being returned to Ironpython is a few abstractions removed from the object that I really need. Apparently comtypes can handle this automatically in the background (seeing as the python example works flawlessly). The code block below shows the object types returned to Ironpython and to pure python respectively:
Ipy : <System.MarshalByRefObject object at 0x000000000000002B [CSI.ETABS.API.ETABSObject]>
Python with comtypes : <POINTER(cOAPI) ptr=0x2e68d17f7c8 at 2e690b36a48>
I'm working on Ironpython 2.7.3 and can't really update it (for several reasons not relevant to this post). Would love to have advice on how to fix this or on how to install comtypes on Ipy.
So I think I've found the reason why this is happening - Ironpython cannot directly use MarshalByRefObjects (source) since Reflection doesn't work on these. It seems I'll need to create a C# class which can cast this object into the one I want, compile it into a dll and load that into my Ipy code.
I'll leave this here in case someone with more knowledge has a better answer.
I have a DirectShow filter (MonogramAAC encoder) successfully compiling. It also registers successfully, however, when I try to instantiate the filter in GrapheditPlus, it shows a CO_E_ERRORINDLL. After inspecting the filter properties under GraphEditPlus, the filter was actually linked to RegSvr32.exe instead of the actual host DLL!
Here's the evidence:
I'm sure the .def file in the linker is correct, I also tested that it IS being considered by the compiler and it is correctly pointing to the filter DLL.
A little bakground info:
I couldn't get the original project to compile under Visual Studio 2017 after automated conversion. (I couldn't resolve strange MFC and runtime library linker errors between the Monogram filter and the libaac.lib library, that I'm also able to compile successfully).
Finally I decided to recreate a brand-new VS2017 Project mimicking the original one and got it to compile and register (with the only warning being the mismatch between the Project name and the output library), but obviously I missed something important while recreating the project.
Any pointers?
Ok, I managed to find the reason for this unexpected behavior in this old post.
RegSvr32 just calls the DllRegisterServer entry point in your code.
What gets written to the registry is entirely up to your filter. If
you are using the standard baseclass call to AMovieDllRegisterServer2
as your DllRegisterServer, I would suspect that something went wrong
in setting up g_hInst, which should have been done by the call
DllEntryPoint in your DllMain.
…
The DllMain is not being called, so g_hInst stays 0 and
GetModuleFileNameA(...) returns the name of the currently executing
program instead of my filter.
The filter is using MFC (dynamically linked), and its DllMain() version is not calling the DllEntryPoint() function. I had to override the MFC DllMain() by adding extern "C" { int _afxForceUSRDLL; } as described in an answer to this question and call DllEntryPoint() myself to fix the registration problem. (I also found a missing #define was the reason for the property page not showing up).
Could somebody please explain what cob32api does?
I have the task of migrating a batch cobol system from 32 bit Windows to 64 bit Linux. A large number of programs call 'cob32api' which belongs to Net Express. The Linux equivalent to Net Express is Server Express, but I'm not at all clear on what this particular call actually does. There don't appear to be any parameters required. Sadly, there are also no comments explaining what it's for.
Naturally I get an error when I try to build:
Load error : file 'cob32api'
error code: 173, pc=0, call=1, seg=0 173
Called program file not found in drive/directory
Can anybody help me out here?
Thanks in advance.
OK, I tracked down a colleague who has worked on this stuff and knew what it meant. The call to cob32api is required so that the cobol program in question, as well as any sub-modules, can call Windows APIs. This explains why the corresponding library (cob32api.dll) has no Linux equivalent.
The simple solution to my problem: Remove the call altogether.
I hope this helps anybody who runs into a similar problem.
Thanks for the comments.
Additional information:
The removal of the "cob32api" call had consequences for the sub-modules I mentioned. Ther were a number of calls of the form
CALL WINAPI "windows-function-name" ...
These resulted in later compile errors and therefore needed to be replaced.