Re: How send parameters to DMD when using DUB
/+ dub.sdl: dependency "telega" version="~>0.2.0" lflags "C:\\Users\\Usuario\\Arquivos\\Sublime Text Build 3211\\Data\\Packages\\resources.res" platform="dmd" +/ Solved replaceing dflags to lflags
Re: How send parameters to DMD when using DUB
I'm trying this code but do not work. /+ dub.sdl: dependency "telega" version="~>0.2.0" dflags "C:\\Users\\Usuario\\Arquivos\\Sublime Text Build 3211\\Data\\Packages\\resources.res" platform="dmd" +/
How send parameters to DMD when using DUB
I need add resources. But how can I make it using DUB?
Re: win64 DLL stdout printing after main process completes
On Monday, 19 April 2021 at 18:05:46 UTC, cc wrote: This seems to work if I flush after every printf or write in both main and the dll. I was under the impression they were supposed to share the same IO buffers though, is this not the case? Very little in D dlls right now are shared, so there's duplicate buffers and functions in the dll do not necessarily affect the exe's copies. It basically works in most cases but this can cause some quirks and bugs in some situations.
Re: win64 DLL stdout printing after main process completes
On Monday, 19 April 2021 at 14:55:03 UTC, cc wrote: https://wiki.dlang.org/Win32_DLLs_in_D I'm starting to think half that page should just be deleted... the version up top with the druntime dll_process_attach etc versions should really be used in all cases. And that gets even simpler too, use import core.sys.windows.dll; mixin SimpleDllMain; and you get that boilerplate for free.
Re: win64 DLL stdout printing after main process completes
On Monday, 19 April 2021 at 16:04:28 UTC, Mike Parker wrote: On Monday, 19 April 2021 at 14:55:03 UTC, cc wrote: And upon running, the output I receive is: ``` [Main] Start [Main] x: 5 [Main] Finished [Main] END [dll] DLL_PROCESS_ATTACH [dll] static this for mydll [dll] MyDLL_Test [dll] DLL_PROCESS_DETACH [dll] static ~this for mydll ``` I would expect the first three lines of dll output to precede the "[Main] x:" line at least. Is there something I'm doing wrong? Do I need to somehow pass a reference to the main stdio to the DLL's D runtime similar to how the GC can be shared? It's probably just due to buffering. Insert a fflush(stdout) after the calls to printf in your DLL and see what happens. This seems to work if I flush after every printf or write in both main and the dll. I was under the impression they were supposed to share the same IO buffers though, is this not the case?
Re: win64 DLL stdout printing after main process completes
On Monday, 19 April 2021 at 16:00:25 UTC, frame wrote: You miss a core.stdc.stdio import in main(). I also omit the def-File, maybe you have an error in it? It shouldn't be necessary to include. It just did: ``` dmd -m64 -ofmydll.dll -L/DLL mydll.d ``` Sorry, here's the def file, taken from the wiki example. ``` LIBRARY "mydll.dll" EXETYPE NT SUBSYSTEM WINDOWS CODE SHARED EXECUTE DATA WRITE ``` Incidentally I get some warnings regarding it when I compile: ``` mydll.def(2) : warning LNK4017: EXETYPE statement not supported for the target platform; ignored mydll.def(3) : warning LNK4017: SUBSYSTEM statement not supported for the target platform; ignored mydll.def(4) : warning LNK4017: CODE statement not supported for the target platform; ignored mydll.def(5) : warning LNK4017: DATA statement not supported for the target platform; ignored ``` Are all those lines were intended for win32 dlls and whatever the x64 equivalents are are different? Also, the example at the D wiki URL had a -L/IMPLIB in the command line but I get `LINK : fatal error LNK1146: no argument specified with option '/IMPLIB'` with that so I removed it.
Re: How to skip class/function when using -HC flag to generate C++ headers?
On Monday, 19 April 2021 at 17:37:31 UTC, MoonlightSentinel wrote: On Monday, 19 April 2021 at 16:26:20 UTC, evilrat wrote: Or maybe there is a way to tell it whitelist/blacklist modules? The header generator only translates modules passed on the command line, other declarations are omitted unless they are required by another symbol. Omit the modules from your blacklist when generating the header file (allthough that requires rerunning dmd) Ok thanks, well, time for new dub subconfig. Or... maybe at least pre-build step for that specific module.
Re: How to skip class/function when using -HC flag to generate C++ headers?
On Monday, 19 April 2021 at 16:26:20 UTC, evilrat wrote: Or maybe there is a way to tell it whitelist/blacklist modules? The header generator only translates modules passed on the command line, other declarations are omitted unless they are required by another symbol. Omit the modules from your blacklist when generating the header file (allthough that requires rerunning dmd)
How to skip class/function when using -HC flag to generate C++ headers?
It is annoying, it tries to write all derived classes where it only needs interface. Or maybe there is a way to tell it whitelist/blacklist modules? Marking class private is not an option.
Re: win64 DLL stdout printing after main process completes
On Monday, 19 April 2021 at 14:55:03 UTC, cc wrote: And upon running, the output I receive is: ``` [Main] Start [Main] x: 5 [Main] Finished [Main] END [dll] DLL_PROCESS_ATTACH [dll] static this for mydll [dll] MyDLL_Test [dll] DLL_PROCESS_DETACH [dll] static ~this for mydll ``` I would expect the first three lines of dll output to precede the "[Main] x:" line at least. Is there something I'm doing wrong? Do I need to somehow pass a reference to the main stdio to the DLL's D runtime similar to how the GC can be shared? It's probably just due to buffering. Insert a fflush(stdout) after the calls to printf in your DLL and see what happens.
Re: win64 DLL stdout printing after main process completes
On Monday, 19 April 2021 at 14:55:03 UTC, cc wrote: I would expect the first three lines of dll output to precede the "[Main] x:" line at least. Is there something I'm doing wrong? Do I need to somehow pass a reference to the main stdio to the DLL's D runtime similar to how the GC can be shared? Which compiler version are you using? This is my output: ``` [dll] DLL_PROCESS_ATTACH [dll] static this for mydll [Main] Start [dll] MyDLL_Test [Main] x: 5 [Main] Finished [Main] END [dll] DLL_PROCESS_DETACH [dll] static ~this for mydll ``` You miss a core.stdc.stdio import in main(). I also omit the def-File, maybe you have an error in it? It shouldn't be necessary to include. It just did: ``` dmd -m64 -ofmydll.dll -L/DLL mydll.d ```
win64 DLL stdout printing after main process completes
I'm not sure if this is something unique to D or not, but I've
having a minor issue where stdout output from a DLL (either via
printf or phobos std.stdio write) is not displayed until after
the main process has completed. I'm making a project based
around the example at https://wiki.dlang.org/Win32_DLLs_in_D
which I've heard is a little out of date but I've gotten it
working nonetheless. I have the following project files:
```d
// mydll.d
module mydll;
import core.runtime;
import core.stdc.stdio;
import core.stdc.stdlib;
import core.sys.windows.windows;
extern(Windows) BOOL DllMain(HINSTANCE hInstance, ULONG ulReason,
LPVOID pvReserved) {
switch (ulReason) {
case DLL_PROCESS_ATTACH:
printf("[dll] DLL_PROCESS_ATTACH\n");
Runtime.initialize();
break;
case DLL_PROCESS_DETACH:
printf("[dll] DLL_PROCESS_DETACH\n");
Runtime.terminate();
break;
case DLL_THREAD_ATTACH:
printf("[dll] DLL_THREAD_ATTACH\n");
return false;
case DLL_THREAD_DETACH:
printf("[dll] DLL_THREAD_DETACH\n");
return false;
default:
}
return true;
}
export int MyDLL_Test() {
printf("[dll] MyDLL_Test\n");
return 5;
}
static this() {
printf("[dll] static this for mydll\n");
}
static ~this() {
printf("[dll] static ~this for mydll\n");
}
```
```d
// mydll.di
module mydll;
export int MyDLL_Test();
```
```d
// main.d
import mydll;
pragma(lib, "mydll.lib");
import core.sys.windows.windows;
void main() {
printf("[Main] Start\n");
scope(exit) printf("[Main] END\n");
int x = MyDLL_Test();
printf("[Main] x: %d\n", x);
printf("[Main] Finished\n");
}
```
DLL compilation command line: `dmd -m64 -ofmydll.dll -L/DLL
mydll.d mydll.def`
Main command line: `rdmd -m64 main.d`
And upon running, the output I receive is:
```
[Main] Start
[Main] x: 5
[Main] Finished
[Main] END
[dll] DLL_PROCESS_ATTACH
[dll] static this for mydll
[dll] MyDLL_Test
[dll] DLL_PROCESS_DETACH
[dll] static ~this for mydll
```
I would expect the first three lines of dll output to precede the
"[Main] x:" line at least. Is there something I'm doing wrong?
Do I need to somehow pass a reference to the main stdio to the
DLL's D runtime similar to how the GC can be shared?
Re: Shared with synchronized
On Monday, 4 March 2019 at 00:07:39 UTC, r-const-dev wrote:
I'm trying to implement a thread safe class, guarding data
access with synchronized and atomicOp.
To get more help with memory safety checking from the compiler,
please instead use `@safe` as
```d
import std.typecons : Nullable;
@safe class SharedObject {
private Nullable!int sharedValue;
private int changeCount = 0;
synchronized void modifyValue(int newValue) @trusted {
(cast(SharedObject)this).unsafeModifyValue(newValue);
}
private void unsafeModifyValue(int newValue) {
sharedValue = newValue;
++changeCount;
}
}
@safe void main()
{
shared SharedObject data = new shared SharedObject();
data.modifyValue(3);
}
```
