Re: ?? How to subscribe to Multicast Broadcasts ??
On Monday, 13 August 2018 at 01:12:16 UTC, Joe wrote: Please Please Please Help, I am desperate! Many Thanks in Advance for your time & attention, -joe I implemented multicast support in vibe.d, I hope looking at the source can help you: https://github.com/vibe-d/vibe.d/blob/master/core/vibe/core/drivers/libevent2.d#L1129 Also, shouldn't both sending and receiving ports be the same? Where I use it I call addMembership and then canBroadcast on a vibed socket, and it has worked for me. It wouldn't be difficult to port that back to std.socket.
Re: Load D shared library on windows x64
On Saturday, 18 August 2018 at 21:10:55 UTC, Tofu Ninja wrote:
On Saturday, 18 August 2018 at 11:27:29 UTC, Mike Wey wrote:
On 18-08-18 02:31, Tofu Ninja wrote:
On Friday, 17 August 2018 at 20:27:05 UTC, Tofu Ninja wrote:
Its this part that fails... always returns null
HMODULE h = cast(HMODULE) Runtime.loadLibrary(dllName);
if (h is null) {
writeln("error loading");
return;
}
I there any way to see why Runtime.loadLibrary is failing? It
just returns null on error which is not very helpful.
You can probably use: core.sys.windows.winbase.GetLastError
That was helpful, error is:
ERROR_DLL_INIT_FAILED
1114 (0x45A)
A dynamic link library (DLL) initialization routine failed.
Thank you this helped lead me to the real error.
The problem was here
writeln("DLL_PROCESS_ATTACH");
Runtime.initialize();
Cant use writeln before Runtime.initialize
Re: Load D shared library on windows x64
On Saturday, 18 August 2018 at 11:27:29 UTC, Mike Wey wrote:
On 18-08-18 02:31, Tofu Ninja wrote:
On Friday, 17 August 2018 at 20:27:05 UTC, Tofu Ninja wrote:
Its this part that fails... always returns null
HMODULE h = cast(HMODULE) Runtime.loadLibrary(dllName);
if (h is null) {
writeln("error loading");
return;
}
I there any way to see why Runtime.loadLibrary is failing? It
just returns null on error which is not very helpful.
You can probably use: core.sys.windows.winbase.GetLastError
That was helpful, error is:
ERROR_DLL_INIT_FAILED
1114 (0x45A)
A dynamic link library (DLL) initialization routine failed.
Re: Set optional function parameter
On Friday, 17 August 2018 at 08:52:53 UTC, Andrey wrote:
I mean - can I skip some arguments and set only one that I want?
Hm, Python, it seems to me, support this feature.
There's no such built-in functionality in the language or
standard library, no. As Jonathan pointed out, this has been
implemented as a template multiple times, though. Here's my
version:
https://gist.github.com/Biotronic/fffa7d4c96d760da5129d27ba3307f73
Usage:
named!executeShell("my_command", args.workDir = "my/path")
Missing functionality:
No support for overloads. Sorry.
No handy suggestions for which argument you may have meant when a
typo sneaks in.
--
Simen
Re: Calling convention for ASM on Linux AMD64
Okay, cool, thanks for the information. The main reason for using D versus Java for me at the moment is that array slices allow me avoid lots of intermediate buffers that Java is forcing me to use. Also the line count is about 2/3 of Java. Further I can directly embed any assembly language I need, rather than using JNI. Maybe some day a version of D for graal can be written, though you would lose native assembly language. https://github.com/oracle/graal All I really want though is a sane low level programming language or a sane version of C.
Re: Load D shared library on windows x64
On 18-08-18 02:31, Tofu Ninja wrote:
On Friday, 17 August 2018 at 20:27:05 UTC, Tofu Ninja wrote:
Its this part that fails... always returns null
HMODULE h = cast(HMODULE) Runtime.loadLibrary(dllName);
if (h is null) {
writeln("error loading");
return;
}
I there any way to see why Runtime.loadLibrary is failing? It just
returns null on error which is not very helpful.
You can probably use: core.sys.windows.winbase.GetLastError
--
Mike Wey
Re: Load D shared library on windows x64
On Saturday, 18 August 2018 at 00:31:49 UTC, Tofu Ninja wrote:
On Friday, 17 August 2018 at 20:27:05 UTC, Tofu Ninja wrote:
Its this part that fails... always returns null
HMODULE h = cast(HMODULE) Runtime.loadLibrary(dllName);
if (h is null) {
writeln("error loading");
return;
}
I there any way to see why Runtime.loadLibrary is failing? It
just returns null on error which is not very helpful.
Maybe you can find something useful in how Derelict does it here:
https://github.com/DerelictOrg/DerelictUtil/blob/master/source/derelict/util/sharedlib.d
Re: Calling convention for ASM on Linux AMD64
On Saturday, 18 August 2018 at 06:47:36 UTC, Eugene Wissner wrote:
On Saturday, 18 August 2018 at 04:16:11 UTC, Sean O'Connor
wrote:
What calling convention is used for assembly language in Linux
AMD64?
Normally the parameters go in fixed order into designated
registers.
import std.stdio;
// Linux AMD64
float* test(float *x,ulong y){
asm{
naked;
align 16;
mov RAX,RDI;
ret;
}
}
void main(){
float[] f=new float[16];
writeln([0]);
float* a=test([0],7);
writeln(a);
}
If the ulong y parameter is removed from the function
definition the pointer x goes into RDI as expected. When y is
added it all goes wrong. According to AMD64 the pointer should
stay in RDI and the ulong go into RSI.
If you compile with DMD, DMD passes the arguments in reverse
order. LDC and GDC use normal C calling conventions.
You can define test() as exter(C) to force dmd to use the
expected arguments order.
Re: Calling convention for ASM on Linux AMD64
On Saturday, 18 August 2018 at 04:16:11 UTC, Sean O'Connor wrote:
What calling convention is used for assembly language in Linux
AMD64?
Normally the parameters go in fixed order into designated
registers.
import std.stdio;
// Linux AMD64
float* test(float *x,ulong y){
asm{
naked;
align 16;
mov RAX,RDI;
ret;
}
}
void main(){
float[] f=new float[16];
writeln([0]);
float* a=test([0],7);
writeln(a);
}
If the ulong y parameter is removed from the function
definition the pointer x goes into RDI as expected. When y is
added it all goes wrong. According to AMD64 the pointer should
stay in RDI and the ulong go into RSI.
If you compile with DMD, DMD passes the arguments in reverse
order. LDC and GDC use normal C calling conventions.
