Re: Need help with Windows linkage ( DMD using ImportC)
On Thursday, 7 March 2024 at 18:14:32 UTC, Gregor Mückl wrote: 1. Missing import libraries for Win32 API functions. Anything starting with `__imp_` is a symbol that should be provided by a DLL import library. MapViewOfFileNuma2 for example is provided by onecore.lib in the Windows SDK, according to Microsoft documentation. Onecore: not sure what I did to add that dependency. Two symbols there. Thanks for the __imp_ clue. 2. C code referring to MSVC-specific compiler intrinsics. At least InterlockedExchangeAdd, InterlockedExchangeAdd64 and _stosb are such intrinsics. This is harder to resolve. There are two ways forward here: either implement a shim function that replicates the intrinsic's functionality if possible or add support for these intrinsics to DMD. Yes, not sure what the potential consequences are for my dirty replacement. Presumably DMD itself won't generate code using these, but ...
Re: DMD windows and Clang's llvm-link.exe
On 10/03/2024 11:02 AM, Carl Sturtivant wrote: I'd like to see if I can get dmd to work correctly with Clang rather than MS tools. Can anyone share any experience they've had with this or any understanding of the situation? lld is used and distributed with dmd and ldc. That is known to work. If you have MSVC, it'll prefer that however.
DMD windows and Clang's llvm-link.exe
I'd like to see if I can get dmd to work correctly with Clang rather than MS tools. Can anyone share any experience they've had with this or any understanding of the situation?
Re: Can a D library have some types determined by the client program?
Update on two things: One is that I now better understand what it means that D objects are "reference by default". This means that references *can* be null if they are declared with a class. In my commits last night, I have changed many pointers into references. I think my time will be smoother from now on, spending far less time trying to debug segfaults. Secondly, I found out that interfaces can't have variables. What!? That's crazy! Why wouldn't they? They totally should. Doesn't this mean that I will need to use getter and setter functions instead of direct access when using interfaces? I don't like this.
How to terminate thread under module destructor?
import core.thread.osthread : Thread;
import std.stdio : writeln;
__gshared static Thread th;
__gshared static size_t tht;
void run()
{
writeln("run");
while (tht == 0) {}
}
shared static this()
{
writeln("this");
th = new Thread().start();
}
shared static ~this()
{
writeln("~this");
tht = 1;
}
void main()
{
writeln("main");
}
Re: DMD windows and Clang's llvm-link.exe
On 10/03/2024 4:46 PM, Carl Sturtivant wrote: suggesting that there's a reason version 9 instead of 17 of lld is being used in the latest DMD installation, that may be relevant what I'd like to try. Any idea what that might be? Yes, nobody has updated it. https://github.com/dlang/installer/blob/50f5825e9d9bf44afb9108f0c1a01a8038d2f156/.github/workflows/build_windows.yml#L22 The ldc one should match whatever LLVM is which is newer.
Re: Can a D library have some types determined by the client program?
I have made a new branch of my project called "templates-interfaces" which reworks some things, and turns the Map class into an interface and template. It is now functioning like the master branch, but I think the code should now be (arguably) easier to follow. At least that's true for the Raylib front-end, though maybe a little less so for the library. Here it is: https://github.com/LiamM32/Open_Emblem/tree/templates-interfaces I will probably merge it into master soon.
Re: DMD windows and Clang's llvm-link.exe
On Sunday, 10 March 2024 at 04:22:20 UTC, Richard (Rikki) Andrew Cattermole wrote: On 10/03/2024 4:46 PM, Carl Sturtivant wrote: suggesting that there's a reason version 9 instead of 17 of lld is being used in the latest DMD installation, that may be relevant what I'd like to try. Any idea what that might be? Yes, nobody has updated it. https://github.com/dlang/installer/blob/50f5825e9d9bf44afb9108f0c1a01a8038d2f156/.github/workflows/build_windows.yml#L22 The ldc one should match whatever LLVM is which is newer. No technical reason then, I assume you mean.
Re: DMD windows and Clang's llvm-link.exe
On Saturday, 9 March 2024 at 22:07:05 UTC, Richard (Rikki) Andrew Cattermole wrote: lld is used and distributed with dmd and ldc. That is known to work. If you have MSVC, it'll prefer that however. Interesting, perhaps I should have known that, though I have not used DMD on Windows for many years until now. I have this from a 64-bit "Developer Command Prompt": ``` lld-link --version LLD 9.0.0 (https://github.com/dlang/installer d4266cf3dccfd7a7d361d28143f86e98b2da8db8) dmd --version DMD64 D Compiler v2.107.0 Copyright (C) 1999-2024 by The D Language Foundation, All Rights Reserved written by Walter Bright ``` Whereas from an MSYS2 Clang64 terminal I have this: ``` $ lld-link --version LLD 17.0.6$ clang --version clang version 17.0.6 ``` suggesting that there's a reason version 9 instead of 17 of lld is being used in the latest DMD installation, that may be relevant what I'd like to try. Any idea what that might be?
Re: Why am I getting segfaults when doing `foreach` with arrays of references?
On 09/03/2024 8:49 PM, Liam McGillivray wrote: But that begs the question; why? Don't dynamic arrays always start with a length of 0? If the array was only extended when valid objects were appended using the append operator |~=|, and none of those objects were deleted (as I the destructor was never called), why would some of the array elements be null? The default initialization state of a pointer (regardless of type) in D is null. I.e. ```d Object[] array; array.length = 2; array[0] = new Object; assert(array[0] !is null); assert(array[1] is null); array ~= new Object; assert(array[0] !is null); assert(array[1] is null); assert(array[2] !is null); ```
Re: Why am I getting segfaults when doing `foreach` with arrays of references?
On Saturday, 9 March 2024 at 07:49:52 UTC, Liam McGillivray wrote: But that begs the question; why? Don't dynamic arrays always start with a length of 0? If the array was only extended when valid objects were appended using the append operator `~=`, and none of those objects were deleted (as I the destructor was never called), why would some of the array elements be null? I'll answer my own question; because the thing assigned to the array was already null. Anyway, I managed to fix the segfaults. In the latest two commits, I have turned some pointers into references. Now that I understand this, I should have fewer segmentation faults.
