Jump to page: 1 2 3
Thread overview
how do i fix this node_dlang error?
Jun 06
Jack
Jun 06
Jack
Jun 06
Jack
Jun 07
Jack
Jun 06
NotSpooky
Jun 07
Jack
Jun 07
Jack
Jun 07
Jack
Jun 07
frame
Jun 07
Jack
Jun 07
Jack
Jun 08
Jack
Jun 08
NotSpooky
Jun 08
Jack
Jun 08
Jack
June 06

I'm trying to use the node_dlang pakckage but the code example from this repo isn't working

the command dub build is fine but node example.js retuns an error saying the module.node is not a valid win32 application. How do I fix this?

June 06

On Sunday, 6 June 2021 at 04:25:39 UTC, Jack wrote:

>

I'm trying to use the node_dlang pakckage but the code example from this repo isn't working

the command dub build is fine but node example.js retuns an error saying the module.node is not a valid win32 application. How do I fix this?

Looking at node_dlang's dub.json, it's building a DLL then renaming it to module.node. The JS script then causes node to load the DLL.

So I expect this error may be related to a 32-bit vs. 64-bit issue. I assume you are on 64-bit Windows, in which case recent versions of dub compile as 64-bit by default. So if that's the case, and your installation of node is 32-bit, you would see this error. Ditto when you're loading a 32-bit DLL in a 64-bit process.

June 06

On Sunday, 6 June 2021 at 06:10:18 UTC, Mike Parker wrote:

>

On Sunday, 6 June 2021 at 04:25:39 UTC, Jack wrote:

>

I'm trying to use the node_dlang pakckage but the code example from this repo isn't working

the command dub build is fine but node example.js retuns an error saying the module.node is not a valid win32 application. How do I fix this?

Looking at node_dlang's dub.json, it's building a DLL then renaming it to module.node. The JS script then causes node to load the DLL.

So I expect this error may be related to a 32-bit vs. 64-bit issue. I assume you are on 64-bit Windows, in which case recent versions of dub compile as 64-bit by default. So if that's the case, and your installation of node is 32-bit, you would see this error. Ditto when you're loading a 32-bit DLL in a 64-bit process.

that's right, I was on 64bit system and node was 32bit installation (I didn't even realize I installed the 32bit instead of 64bit). I just installed node 64bit version, that fixed, thanks!

June 06

On Sunday, 6 June 2021 at 06:10:18 UTC, Mike Parker wrote:

>

On Sunday, 6 June 2021 at 04:25:39 UTC, Jack wrote:

>

I'm trying to use the node_dlang pakckage but the code example from this repo isn't working

the command dub build is fine but node example.js retuns an error saying the module.node is not a valid win32 application. How do I fix this?

Looking at node_dlang's dub.json, it's building a DLL then renaming it to module.node. The JS script then causes node to load the DLL.

So I expect this error may be related to a 32-bit vs. 64-bit issue. I assume you are on 64-bit Windows, in which case recent versions of dub compile as 64-bit by default. So if that's the case, and your installation of node is 32-bit, you would see this error. Ditto when you're loading a 32-bit DLL in a 64-bit process.

the npm was 32bit so the switch to 64bit worked then npm example.js ran file but electron requires a 32bit module, so I need to switch back to npm 32bit. Now, I can't build the example from node_dlang with --arch=x86, returns the error:

command:

$ dub --arch=x86

output:

Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for x86, x86_omf.
node_dlang 0.4.11: building configuration "node_dlang_windows"...
..\..\AppData\Local\dub\packages\node_dlang-0.4.11\node_dlang\source\node_dlang.d(137,11): Error: none of the overloads of `this` are callable using argument types `(string, string, ulong, Throwable)`, candidates are:
C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d(2440,30):        `object.Exception.this(string msg, string file = __FILE__, uint line = cast(uint)__LINE__, Throwable nextInChain = null)`
C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d(2445,30):        `object.Exception.this(string msg, Throwable nextInChain, string file = __FILE__, uint line = cast(uint)__LINE__)`
C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1.
June 06

On Sunday, 6 June 2021 at 15:42:55 UTC, Jack wrote:
0.4.11\node_dlang\source\node_dlang.d(137,11): Error: none of the overloads of this are callable using argument types (string, string, ulong, Throwable), candidates are:

>

C:\D\dmd2\windows\bin....\src\druntime\import\object.d(2440,30): object.Exception.this(string msg, string file = __FILE__, uint line = cast(uint)__LINE__, Throwable nextInChain = null)
C:\D\dmd2\windows\bin....\src\druntime\import\object.d(2445,30): object.Exception.this(string msg, Throwable nextInChain, string file = __FILE__, uint line = cast(uint)__LINE__)
C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1.

The error is from line 137 of node_dlang.d. Looking at it, we see this:

super (message, file, line, nextInChain);

This is in the constructor of the JSException class, a subclass of Exception, calling the superclass constructor. According to the error message, one or more of the arguments in this list does not match any Exception constructor's parameter list.

Looking closer, we can see that the arguments to the super constructor are all declared in the JSException constructor like this:

this (
    napi_value jsException
    , string message = `JS Exception`
    , string file = __FILE__
    , ulong line = cast (ulong) __LINE__
    , Throwable nextInChain = null)

Compare that with the constructors in the Exception class and you should see that the problem is ulong line. The equivalent argument in the superclass is size_t. In 32-bit, size_t is defined as uint, not ulong. So it's passing a ulong to a uint, which is a no-no.

The JSException constructor should be modified to this:

, size_t line = __LINE__

The README does say it hasn't been tested with 32-bit. So there may be more such errors.

Unrelated, but I recommend you use --arch=x86_mscoff so that you can use the same linker and object file format as -m64 uses (MS link, or lld, and PE/COFF), rather than the default (which is OPTLINK and OMF). It may save you further potential headaches.

June 06

On Sunday, 6 June 2021 at 04:25:39 UTC, Jack wrote:

>

I'm trying to use the node_dlang pakckage but the code example from this repo isn't working

the command dub build is fine but node example.js retuns an error saying the module.node is not a valid win32 application. How do I fix this?

Hello, I'm the author of the library.
Indeed I only tested it on 64-bit systems. I can try to make it 32-bit compatible if needed.

Aside from the auto-translated headers, in the case of Windows the repo also includes node.lib compiled for 64-bit, so unless the 32-bit version is added it will also give errors.

I'm pretty sure it does work with electron as I have used it myself.

June 07

On Sunday, 6 June 2021 at 17:32:57 UTC, Mike Parker wrote:

>

On Sunday, 6 June 2021 at 15:42:55 UTC, Jack wrote:
0.4.11\node_dlang\source\node_dlang.d(137,11): Error: none of the overloads of this are callable using argument types (string, string, ulong, Throwable), candidates are:

>

[...]

The error is from line 137 of node_dlang.d. Looking at it, we see this:

super (message, file, line, nextInChain);

This is in the constructor of the JSException class, a subclass of Exception, calling the superclass constructor. According to the error message, one or more of the arguments in this list does not match any Exception constructor's parameter list.

Looking closer, we can see that the arguments to the super constructor are all declared in the JSException constructor like this:

this (
    napi_value jsException
    , string message = `JS Exception`
    , string file = __FILE__
    , ulong line = cast (ulong) __LINE__
    , Throwable nextInChain = null)

Compare that with the constructors in the Exception class and you should see that the problem is ulong line. The equivalent argument in the superclass is size_t. In 32-bit, size_t is defined as uint, not ulong. So it's passing a ulong to a uint, which is a no-no.

The JSException constructor should be modified to this:

, size_t line = __LINE__

Thanks, I managed to get out this error by making everything 64bit so no type sizes mismatch anymore. The electron itself was still 32bit, which was causing the error to load but it was gone once I reinstalled the 64version.

>

The README does say it hasn't been tested with 32-bit. So there may be more such errors.

Unrelated, but I recommend you use --arch=x86_mscoff

thanks for the tip. in this case, i get the same error above not found the proper overload. But it's to avoid futher potential headaches, I'll edit the node_dlang.d file to make it work. Thanks!

>

so that you can use the same linker and object file format as -m64 uses (MS link, or lld, and PE/COFF), rather than the default (which is OPTLINK and OMF). It may save you further potential headaches.

June 07

On Sunday, 6 June 2021 at 21:44:44 UTC, NotSpooky wrote:

>

On Sunday, 6 June 2021 at 04:25:39 UTC, Jack wrote:

>

I'm trying to use the node_dlang pakckage but the code example from this repo isn't working

the command dub build is fine but node example.js retuns an error saying the module.node is not a valid win32 application. How do I fix this?

Hello, I'm the author of the library.

nice works, thanks for the library!

>

Indeed I only tested it on 64-bit systems. I can try to make it 32-bit compatible if needed.

for me i think it would be needed, i made everything 64bit so it at least compiled and ran.

>

Aside from the auto-translated headers, in the case of Windows the repo also includes node.lib compiled for 64-bit, so unless the 32-bit version is added it will also give errors.

I'm pretty sure it does work with electron as I have used it myself.

I managed to compile the module and it passed this test:

const nativeModule = require('./module.node');
const assert = require('assert');

assert(nativeModule.ultimate() == 42);

The D code looks like this:

import std.stdio : stderr;
import node_dlang;

extern(C):

    void atStart(napi_env env)
    {
        import std.stdio;
    	writeln ("Hello from D!");
    }

    int ultimate()
    {
    	return 42;
    }

mixin exportToJs! (ultimate, MainFunction!atStart);

its builds sucessfully with dub no arguments (no --arch=x86_mscoff yet because it requires to fix other compilation error). The dub script looks like this:

```json
{
	"authors": [
		"test"
	],
	"copyright": "Copyright © 2021, test",
	"dependencies": {
		"node_dlang": "~>0.4.11"
	},
	"description": "using electron from D",
	"license": "proprietary",
	"name": "eled",
	"targetType": "dynamicLibrary",
	"targetName" : "module.node",
	"targetPath": "bin"
}
```

then i test with node:

node test.js

it works fine. However, when I attempt to use it in the prescript within electron, I get this error:

A JavaScript error occured in the browser process
---------------------------
Uncaught Exception:
Error: A dynamic link library (DLL) initialization routine failed.

    \\?\C:\Users\001\Desktop\ele\module.node
        at process.func [as dlopen] (VM70 asar_bundle.js:5)
        at Object.Module._extensions..node (VM43 loader.js:1138)
        at Object.func [as .node] (VM70 asar_bundle.js:5)
        at Module.load (VM43 loader.js:935)
        at Module._load (VM43 loader.js:776)
        at Function.f._load (VM70 asar_bundle.js:5)
        at Function.o._load (VM75 renderer_init.js:33)
        at Module.require (VM43 loader.js:959)
        at require (VM50 helpers.js:88)
        at Object.<anonymous> (VM88 C:\Users\001\Desktop\ele\preload.js:6)
    ```

the lines of this in the prescript goes like this:

```javascript
const nativeModule = require('./module.node');
const assert = require('assert');

assert(nativeModule.ultimate() == 42);

What am I missing?

June 07

On Monday, 7 June 2021 at 02:33:38 UTC, Jack wrote:

>

What am I missing?

Does your code / node_dlang initialize Druntime before calling writeln?
Try replacing the writeln with puts (from core.stdc.stdio) which doesn't require an initialized runtime.

June 07

On Monday, 7 June 2021 at 17:22:48 UTC, MoonlightSentinel wrote:

>

On Monday, 7 June 2021 at 02:33:38 UTC, Jack wrote:

>

What am I missing?

Does your code / node_dlang initialize Druntime before calling writeln?

actually i didnt so I just added:

shared static this()
{
	Runtime.initialize();
}

shared static ~this()
{
	Runtime.terminate();
}

but it didn't change anything

>

Try replacing the writeln with puts (from core.stdc.stdio) which doesn't require an initialized runtime.

I've tried just removed the writeln() call it didn't change anything either

« First   ‹ Prev
1 2 3