Re: Verbosity in D
On Sunday, 7 August 2022 at 16:01:08 UTC, pascal111 wrote: It's clear by working with D that it has the same bad point like Pascal language; the "verbosity". Is there any plans in future to make some shorthanded techniques that clean verbosity from D? In most cases this is a false statement. Just see examples on frontpage of dlang site. Or try write and compare concrete programs. Python have a good expressiveness, but up to 100 times slower.
Re: What are (were) the most difficult parts of D?
On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote: What are you stuck at? What was the most difficult features to understand? etc. To make it more meaningful, what is your experience with other languages? Ali When i take old library from a dub or github and cannot compile it with latest compiler because of small and subtle language changes. For example https://github.com/buggins/dlangide/pull/410/commits/43a82ed2f45143270482aa94c447e577174f0108#diff-375ecd44ef501b93adc6106fe404f55d353e667c21681c1c13a9e2008510ab42L937 I dont know even now, which D's features changes here.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: Yes, I know this is a question lacking a straightforward answer. Requirements: - desktop only: forget about support for mobile tablets whatever You forget semi-official DWT https://forum.dlang.org/group/dwt
Re: dlang vs crystal-language
On Friday, 30 April 2021 at 14:16:16 UTC, Vinod K Chandran wrote: BTW, I wonder to see someone says that they have succeeded in compiling a **tkD** example code. I tried it with no luck. So I gave up that idea. I did this @2014. No problems remembered.
Re: dlang vs crystal-language
On Wednesday, 28 April 2021 at 22:41:03 UTC, Alain De Vos wrote: What are the strengths and weaknesses comparing the two languages ? I can name a strength of dlang is the working binding to tk and gtk. Crystal is Web-only focused. And Crystal is not popular, even compared to D.
Re: WinUI 3
On Monday, 15 March 2021 at 16:41:08 UTC, Imperatorn wrote: Could D be used with WinUI 3? https://docs.microsoft.com/en-us/windows/apps/winui/winui3/ Would the win32metadata help? 樂 No need to going in another dead end
Re: Visual Studio 2019
On Sunday, 7 March 2021 at 20:43:22 UTC, Alexey wrote: Does Visual Studio 2019 support D development? If yes, please give me instructions on how to work in this environment. Visual D https://forum.dlang.org/thread/s1kuna$geb$1...@digitalmars.com
Re: tiny alternative to std library
On Friday, 5 March 2021 at 16:54:48 UTC, Kagamin wrote: On Wednesday, 3 March 2021 at 20:54:43 UTC, Anthony Quizon wrote: I'm having some success pulling out small bits of code from other libraries and keeping things minimal and c-style-ish. If you're really ok with minimalism, I'm writing such a library https://filebin.net/7gtyh5j01gk1ofly I didn't publish it anywhere yet, feel free to do so. Not everything is finished there yet. GPL "virus" license does not fit for any commercial or even shareware work (
Re: D's Continous Changing
On Friday, 5 March 2021 at 03:32:35 UTC, harakim wrote: I want this almost every week at work. When I run into some trivial statement that I need to know for sure how it works, it's rarely worth it to create a whole new file and make a main method and all that. I just edit and run the entire program again, which is a waste of time. So about ten seconds later: PS> rdmd --eval="writeln(format!`%b`(5));" ~\AppData\Local\Temp\.rdmd\eval.F4ADE5F0F88B126B82870415B197BF60.d(18): Error: template argument expected following `!` Failed: ["C:\\Program Files\\D\\dmd2\\windows\\bin\\dmd.exe", "-d", "-v", "-o-", "~\\AppData\\Local\\Temp\\.rdmd\\eval.F4ADE5F0F88B126B82870415B197BF60.d", "-I~\\AppData\\Local\\Temp\\.rdmd"] PS> rdmd --eval="writeln(__VERSION__);" 2095 That was pretty sweet. However, it kind of goes to the point of my post. A one-revision difference means the documentation is not accurate for my compiler. This is problem with Powershell. (May by need to create bugreport ?) This example runs fine from CMD (but i recommend FAR for conveniety) and fails from PS. Tested Win10.1909, dmd 2.095
Re: D's Continous Changing
On Thursday, 4 March 2021 at 06:43:57 UTC, user1234 wrote: otherwise another solution is to check every two monthes the sanity of your projects. E.g a montly cronjob on a CI service and that uses latest DMD Docker image. If it fails you got an email... It certainly cooler to take 5 mins every two monthes than 7 hours 4 years. Nice idea. Try do it with all hundreds of used in your projects libraries.
Re: tiny alternative to std library
On Wednesday, 3 March 2021 at 14:12:54 UTC, Siemargl wrote: I test full rebuild of dlang-IDE (20k loc) now for dmd under Update, 20k loc without counting libraries.
Re: tiny alternative to std library
On Wednesday, 3 March 2021 at 09:02:54 UTC, Anthony wrote: Strange, usual D programs builds fast. What build times do you get? Seems like some other people have similar issues: https://forum.dlang.org/post/pvseqkfkgaopsnhqe...@forum.dlang.org https://forum.dlang.org/thread/mailman.4286.1499286065.31550.digitalmar...@puremagic.com All you mentioned are template issues. Some was fixed. I test full rebuild of dlang-IDE (20k loc) now for dmd under Windows: (Result is 5.5Mb .exe file) -full rebuild with all libs take ~21s >dub build --build=debug --arch=x86_mscoff --force -change one file and rebuild <7s >dub build --build=debug --arch=x86_mscoff
Re: tiny alternative to std library
On Wednesday, 3 March 2021 at 03:52:13 UTC, Anthony Quizon wrote: On Monday, 1 March 2021 at 08:52:35 UTC, Imperatorn wrote: Having a library with bare minimum meta programming would help with this I think. I'm willing to pay the cost of safety. Strange, usual D programs builds fast. As a alternative to Phobos, you can see to D1 standard library - Tango, ported to D2. https://github.com/SiegeLord/Tango-D2 Without mass template magic, its easier. There is also print book "Learn to Tango with D".
Re: Name mangling problem with tiny Windows 10 load-time DLL example
On Sunday, 28 February 2021 at 23:00:56 UTC, WhatMeWorry wrote:
On Sunday, 28 February 2021 at 22:10:21 UTC, Siemargl wrote:
On Sunday, 28 February 2021 at 18:29:11 UTC, WhatMeWorry wrote:
It seems pretty obvious the problem is with name mangling.
But how to fix it?
fixing
int numb = 1;
and your example work correct
ldc 1.24 / win10
P.S.I'm not recommend using such keywords as 'file', may cross
with other modules.
I double checked my posting and of course works it now
works!?!? I've been having trouble where it works and then it
doesn't. I've been using examples with file.d, file1.d,
file2.d, etc. I also came across the note that Windows file
system is not case sensitive. Or is that case in-sensitive?
This worked fine for Linux (Ubuntu) so you might be on to
something.
Win10. Just try delete all obj, dll, lib and do full recompile
from scratch.
module patron;
import file;
void main()
{
import std.stdio;
int numb = 1;
writeln("mangled name of addOne is ", addOne.mangleof);
numb = addOne(numb);
writeln(numb);
}
-
E:\VSProjects\testjunk\D_load_dll>patron.exe
mangled name of addOne is _D4file6addOneFiZi
2
Re: Name mangling problem with tiny Windows 10 load-time DLL example
On Sunday, 28 February 2021 at 18:29:11 UTC, WhatMeWorry wrote: It seems pretty obvious the problem is with name mangling. But how to fix it? fixing int numb = 1; and your example work correct ldc 1.24 / win10 P.S.I'm not recommend using such keywords as 'file', may cross with other modules.
Re: DUB is not working correctly
On Thursday, 25 February 2021 at 17:38:11 UTC, Maxim wrote: On Thursday, 25 February 2021 at 17:34:29 UTC, Maxim wrote: On Wednesday, 24 February 2021 at 16:13:48 UTC, Maxim wrote: [...] I think, I need to rephrase the question for the present situtation: how can I force DUB to change targetName? It doesn't read my changes in dub.json, and I don't know why. In my opinion, that happens because of DUB can't accept my changes to the file. But how to make the manager admit it? I apologize to everyone who understood me wrong. And my problem has been substituted by another! Now DUB says to me to set targetName with this problem: 'No target name set.' Just study dub.pm site (it's not obvious to find it)
Re: DUB is not working correctly
On Thursday, 25 February 2021 at 12:49:05 UTC, Maxim wrote: Wait, I have just noticed that you said about dub which came with dmd. So, was dub on your computer right after compiler installation or you did you do this manually? Many years DMD come together with dub. Look at dmd2\windows\bin\ folder
Re: DUB is not working correctly
On Wednesday, 24 February 2021 at 20:10:29 UTC, Siemargl wrote: Works fine on void dub init project, but underscore problem whith dsfml still here I think, its a problem with dsfml project. You can see it in %userprofile%\AppData\Local\dub\packages\dsfml-2.1.1\dsfml There is a build.d build program, i compile it and build.exe -unittest fails, can see source code : Needed depencies dsfmlc-*.lib (note 'c' on tth end!) So its not a dub problem, just needed dsfmlc-*.libs, which is not a part of a dsfml-2.1.1, but maybe external to C-linking libraries.
Re: DUB is not working correctly
On Wednesday, 24 February 2021 at 19:48:10 UTC, Siemargl wrote: On Wednesday, 24 February 2021 at 19:42:05 UTC, Maxim wrote: On Wednesday, 24 February 2021 at 19:35:46 UTC, Siemargl wrote: On Wednesday, 24 February 2021 at 19:18:32 UTC, Siemargl wrote: [...] Yes, i see th error. If in your dub.json change > "targetType": "executable", [...] Tried and everything seems to be okay with underscores but the error message about the targetType appears even when I start my new pure project without any dependencies. Just downloaded latest dmd 2.095.1, it comes with dub 1.24.1 Works fine on void dub init project, but underscore problem whith dsfml still here I think, its a problem with dsfml project. You can see it in %userprofile%\AppData\Local\dub\packages\dsfml-2.1.1\dsfml There is a build.d build program, i compile it and build.exe -unittest fails, can see source code : Needed depencies dsfmlc-*.lib (note 'c' on tth end!)
Re: DUB is not working correctly
On Wednesday, 24 February 2021 at 19:42:05 UTC, Maxim wrote: On Wednesday, 24 February 2021 at 19:35:46 UTC, Siemargl wrote: On Wednesday, 24 February 2021 at 19:18:32 UTC, Siemargl wrote: [...] Yes, i see th error. If in your dub.json change > "targetType": "executable", [...] Tried and everything seems to be okay with underscores but the error message about the targetType appears even when I start my new pure project without any dependencies. Just downloaded latest dmd 2.095.1, it comes with dub 1.24.1 Works fine on void dub init project, but underscore problem whith dsfml still here
Re: DUB is not working correctly
On Wednesday, 24 February 2021 at 19:04:02 UTC, Maxim wrote:
On Wednesday, 24 February 2021 at 18:52:12 UTC, H. S. Teoh
I recently tried that. Even compiler was reinstalled. It didn't
help.
Just try remove dsfml and all depencies.
My void "dub init"? which works
{
"authors": [
"zws"
],
"copyright": "Copyright © 2021, zws",
"description": "A minimal D application.",
"license": "proprietary",
"name": "d_dub"
}
Re: Creating 1000 instances
On Friday, 19 February 2021 at 08:29:36 UTC, Ferhat Kurtulmuş wrote: Since classes are reference types all instances of files will be the same reference of "new File()", which you probably don't want. Is any differences between x and y definitions? MyClass [] x, y; x = new MyClass[7]; y= new MyClass[](8);
Re: Why filling AA in shared library freezes execution?
On Saturday, 6 February 2021 at 15:21:17 UTC, Siemargl wrote: extern(C) __gshared string[] rt_options = [ "gcopt=parallel:0" ]; LDC 1.24 is also affected and rt_options helps
Re: Minimize GC memory footprint
On Saturday, 13 February 2021 at 19:14:32 UTC, frame wrote: On Saturday, 13 February 2021 at 17:54:53 UTC, Siemargl wrote: And it works too, for 32-bit also =) Consuming about 100MB RAM. Yes, Appender is nice but I had no control about .data since the real property is private so I chose that edgy example to find the problem with the GC. As someone mentioned before, in a real application you would choose some pre-allocation like reserve() on Appender instead which performs better. LDC 1.24 is unaffected of this bug and x64 target consume less memory.
Re: Minimize GC memory footprint
On Tuesday, 9 February 2021 at 04:05:04 UTC, frame wrote:
On Saturday, 6 February 2021 at 20:24:00 UTC, frame wrote:
Hmmm.. with -m64 it's reporting 80 MB used, 203 MB are really
marked as private bytes. Constant. If I use GC.minimize() it
goes up and down and sometimes consumes more than 203 MB. Best
is 100MB. But it doesn't leak endlessly like the 32bit variant.
Hmm, I try to rewrite example in C# and it just hangs in GC, when
str += "1" added 5 million times.
Then i fix this using StringBuilder, as documented. It works fine.
Next i searched flang forums for D's StringBuilder - found this
https://forum.dlang.org/post/l667ab$cfa$1...@digitalmars.com
auto strBuilder = appender!string;
foreach (i; 0 .. 50_000_00) {
strBuilder.put("a");
And it works too, for 32-bit also =)
Consuming about 100MB RAM.
Re: Minimize GC memory footprint
On Saturday, 6 February 2021 at 19:10:14 UTC, Mike Parker wrote: On Saturday, 6 February 2021 at 17:50:18 UTC, frame wrote: Sorry, i forgot mem leak. Or maybe i incorrect understand Gc counters So log Usage: 698.46 MiB (free 187.42 MiB) / collected: 14 Round: 12 Usage: 759.72 MiB (free 184.16 MiB) / collected: 15 ... Usage: 802.00 MiB (free 202.88 MiB) / collected: 16 Usage: 871.38 MiB (free 197.50 MiB) / collected: 17 Usage: 935.64 MiB (free 200.24 MiB) / collected: 18 Usage: 995.86 MiB (free 210.02 MiB) / collected: 19 Usage: 1071.70 MiB (free 207.18 MiB) / collected: 20 Usage: 1139.22 MiB (free 215.66 MiB) / collected: 21 Usage: 1214.83 MiB (free 219.05 MiB) / collected: 22 Usage: 1297.88 MiB (free 218.00 MiB) / collected: 23 Usage: 1378.43 MiB (free 222.45 MiB) / collected: 24 Usage: 1416.72 MiB (free 184.16 MiB) / collected: 25
Re: Minimize GC memory footprint
On Saturday, 6 February 2021 at 19:10:14 UTC, Mike Parker wrote: On Saturday, 6 February 2021 at 17:50:18 UTC, frame wrote: On Saturday, 6 February 2021 at 15:45:47 UTC, rikki cattermole wrote: Default settings should work out of the box. If not - it's bad for reputation of the language. Given that 32-bit has been the default on Windows for D's entire lifetime, I don't expect this is so common of an issue. More harmful would be requiring Visual Studio to compile with the default settings. That said, dub already uses -m64 by default on Windows. And the goal is to enable 64-bit in dmd on Windows by default. That's the reason the MinGW-based link libraries and the LDC linker were added to the distribution, so that it will work out of the box. I don't know what the timetable is supposed to be, but at some point after that is rock solid, the switch to 64-bit by default will be made. This example seems been as a corner uglyness of AA realisation. 64bit heal a problem, but uses about 500Mb of RAM continuosly for this simple example, so its only patching sinkin' ship :-(
Re: Why filling AA in shared library freezes execution?
On Saturday, 6 February 2021 at 10:44:08 UTC, Siemargl wrote: On Saturday, 30 January 2021 at 20:32:36 UTC, Siemargl wrote: No, this is a deadlock in memory manager. To find roots of problem, needed a debug version of druntime, but i were unsuccesfull to compile it. I make debug vesion of druntime and catch nicer stacktrace. Maybe this can help somebody knowing GC internals So it seems, that disabling parallel GC, solves problem. I add in BOTH dll and main module and cant reproduce freeze anymore extern(C) __gshared string[] rt_options = [ "gcopt=parallel:0" ];
Re: Minimize GC memory footprint
On Saturday, 6 February 2021 at 11:20:18 UTC, Imperatorn wrote:
On Saturday, 6 February 2021 at 09:42:38 UTC, rikki cattermole
wrote:
On 06/02/2021 3:32 PM, frame wrote:
[...]
This won't do anything.
[...]
Don't forget to stdout.flush; Otherwise stuff can get caught
in the buffer before erroring out.
[...]
Turn on the precise GC, 32bit is a bit too small of a range
and you can get false positives like in this case (at least
looks like it).
For reference, how does one turn on precise GC?
https://dlang.org/spec/garbage.html#gc_config
Strange things happens:
- precise scanning dont change result - OOM @ same round 27
--DRT-gcopt=help wont show used gc implementation, also cleanup
type not printed
- maxPoolSize:N dont limit total size of GC
- in gc:manual mode GC.collect() not releasing memory
When i print free GC memory, it seems to memory leaking
writefln("Usage: %.2f MiB (free %.2f MiB) / collected: %d",
(cast(double) GC.stats.usedSize) / 1_048_576,
(cast(double) GC.stats.freeSize) / 1_048_576,
GC.profileStats.numCollections);
stdout.flush();
Re: Why filling AA in shared library freezes execution?
On Saturday, 30 January 2021 at 20:32:36 UTC, Siemargl wrote: No, this is a deadlock in memory manager. To find roots of problem, needed a debug version of druntime, but i were unsuccesfull to compile it. I make debug vesion of druntime and catch nicer stacktrace. Maybe this can help somebody knowing GC internals ntdll!ZwWaitForSingleObject+0xa ntdll!RtlDeNormalizeProcessParams+0x5a8 ntdll!RtlDeNormalizeProcessParams+0x4a4 ntdll!RtlInitializeCriticalSectionEx+0x3b9 KERNELBASE!HeapDestroy+0x3a KERNELBASE!GetModuleHandleExW+0x39 test_dll!D4core6thread8osthread23ll_startDLLUnloadThreadFNbNiZb+0x86 test_dll!D4core6thread8osthread20createLowLevelThreadFNbNiDFNbZvkDFNbZvZk+0x153 test_dll!D2gc4impl12conservativeQw3Gcx16startScanThreadsMFNbZv+0xc5 test_dll!D2gc4impl12conservativeQw3Gcx11fullcollectMFNbbZm+0x12f test_dll!D2gc4impl12conservativeQw3Gcx10smallAllocMFNbmKmkxC8TypeInfoZPv+0x135 test_dll!D2gc4impl12conservativeQw14ConservativeGC__T9runLockedS_DQCeQCeQCcQCnQBs12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS_DQEgQEgQEeQEp10mallocTimelS_DQFiQFiQFgQFr10numMallocslTmTkTmTxQCzZQFcMFNbKmKkKmKxQDsZQDl+0xa1 test_dll!D2gc4impl12conservativeQw14ConservativeGC6mallocMFNbmkxC8TypeInfoZPv+0x4b test_dll!gc_malloc+0x2d test_dll!aaGetX+0x2ca test_dll!aaGetY+0x39 test_dll!test_dll.TestFun+0x93 test_dll_exe!D main+0x111 test_dll_exe!D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZ9__lambda1MFZv+0x33 test_dll_exe!D2rt6dmain212_d_run_main2UAAamPUQgZiZ7tryExecMFMDFZvZv+0x3c
Re: Why filling AA in shared library freezes execution?
On Saturday, 30 January 2021 at 19:52:09 UTC, Vitalii wrote: On Friday, 29 January 2021 at 01:23:20 UTC, Siemargl wrote: On Friday, 29 January 2021 at 00:45:12 UTC, Siemargl wrote: Then i modify program, just removing DLL, copying TestFun() in main module and it runs. Same compiler -m64 target. Ups. Sorry, I just forget copy test_dll.dll inside VM :-) So, program runs in Win7, but hangs after printing i:64511 I downgrade DMD to 2.090.1 + MSVC2013 libs and problem disappears. But 2.092 + MSVC2013 libs also hangs. Not every time, but . Thank you, Siemargl! It's just the same behaviour that I got. The same number 64511. If you change double[int] to double[], the number would be around ~520.000, if int[] then ~1.000.000. I make conclusion that there is something concerning memory limit of 4 Mb. No, this is a deadlock in memory manager. To find roots of problem, needed a debug version of druntime, but i were unsuccesfull to compile it.
Re: Why filling AA in shared library freezes execution?
On Friday, 29 January 2021 at 10:10:56 UTC, frame wrote: On Friday, 29 January 2021 at 01:23:20 UTC, Siemargl wrote: On Friday, 29 January 2021 at 00:45:12 UTC, Siemargl wrote: Then i modify program, just removing DLL, copying TestFun() in main module and it runs. Same compiler -m64 target. Ups. Sorry, I just forget copy test_dll.dll inside VM :-) So, program runs in Win7, but hangs after printing i:64511 I downgrade DMD to 2.090.1 + MSVC2013 libs and problem disappears. But 2.092 + MSVC2013 libs also hangs. Not every time, but You should really try to use a debugger to see what error is thrown in first chance. It also helps to identify a possible hidden problem that is not reproducable on other machines. Sorry, there are many problems debugging D x64 on Windows. All i can get, is call stack from crash dump ntdll!ZwWaitForSingleObject+0xa ntdll!RtlDeNormalizeProcessParams+0x5a8 ntdll!RtlDeNormalizeProcessParams+0x4a4 ntdll!RtlInitializeCriticalSectionEx+0x3b9 KERNELBASE!HeapDestroy+0x3a KERNELBASE!GetModuleHandleExW+0x39 test_dll!TestFun+0x576b6 test_dll!TestFun+0x55bf3 test_dll!TestFun+0x4e315 test_dll!TestFun+0x4d86f test_dll!TestFun+0x4bdb5 test_dll!TestFun+0x507e1 test_dll!TestFun+0x4756b test_dll!TestFun+0x22d1d test_dll!TestFun+0x23d9a test_dll!TestFun+0x1a1b9 test_dll!TestFun+0x93 test_dll_exe!D main+0xe5 test_dll_exe!D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZ9__lambda1MFZv+0x33 test_dll_exe!D2rt6dmain212_d_run_main2UAAamPUQgZiZ7tryExecMFMDFZvZv+0x3c
Re: Why filling AA in shared library freezes execution?
On Friday, 29 January 2021 at 00:45:12 UTC, Siemargl wrote: Then i modify program, just removing DLL, copying TestFun() in main module and it runs. Same compiler -m64 target. Ups. Sorry, I just forget copy test_dll.dll inside VM :-) So, program runs in Win7, but hangs after printing i:64511 I downgrade DMD to 2.090.1 + MSVC2013 libs and problem disappears. But 2.092 + MSVC2013 libs also hangs. Not every time, but
Re: Why filling AA in shared library freezes execution?
On Thursday, 28 January 2021 at 12:42:09 UTC, Siemargl wrote: Update. Something is broken in DLL support in druntime for Win7. I take previous working in Win10 binary and try run it in virtual Windows 7 SP1 x64. Got this C:\Proj\dtest>test_dll_exe.exe object.Exception@test_dll_exe.d(7): Enforcement failed 0x0001400013A3 0x0001400012CC 0x000140001074 0x000140004123 0x000140003FAC 0x00014000408B 0x000140003FAC 0x000140003EF3 0x0001400019D0 0x000140001114 0x00014002F60E 0x771359CD in BaseThreadInitThunk 0x7736A561 in RtlUserThreadStart Then i modify program, just removing DLL, copying TestFun() in main module and it runs. Same compiler -m64 target. Ups. Sorry, I just forget copy test_dll.dll inside VM :-) So, program runs in Win7, but hangs after printing i:64511
Re: Why filling AA in shared library freezes execution?
On Thursday, 28 January 2021 at 16:46:40 UTC, frame wrote: On Thursday, 28 January 2021 at 12:42:09 UTC, Siemargl wrote: Update. Something is broken in DLL support in druntime for Win7. I take previous working in Win10 binary and try run it in virtual Windows 7 SP1 x64. Got this You can't expect that a Win10 build also runs on Win7. Why not? Only VS2013 runtime is prereq for DMD programs
Re: Why filling AA in shared library freezes execution?
Update. Something is broken in DLL support in druntime for Win7. I take previous working in Win10 binary and try run it in virtual Windows 7 SP1 x64. Got this C:\Proj\dtest>test_dll_exe.exe object.Exception@test_dll_exe.d(7): Enforcement failed 0x0001400013A3 0x0001400012CC 0x000140001074 0x000140004123 0x000140003FAC 0x00014000408B 0x000140003FAC 0x000140003EF3 0x0001400019D0 0x000140001114 0x00014002F60E 0x771359CD in BaseThreadInitThunk 0x7736A561 in RtlUserThreadStart Then i modify program, just removing DLL, copying TestFun() in main module and it runs. Same compiler -m64 target.
Re: Why filling AA in shared library freezes execution?
Vitalii, I test your program and it runs without any problem. Consuming about 1Gb RAM at end. But i have а slightly different environment. Win10 1909 x64, DMD32 D Compiler v2.092.1-dirty
Re: D function in a .d file calling printf refuses to link.
On Sunday, 18 October 2020 at 21:44:10 UTC, WhatMeWorry wrote:
module mydll;
extern (C):
import core.stdc.stdio : printf;
export
{
int addSeven(int a, int b)
{
//printf("Hello from within my DLL");
return a+b+7;
}
}
The above D code file compiles and links, no problems with
C:\D\dmd2\samples\d\mydll>dmd -v -m64 mydll.d -L/DLL -L/NOENTRY
But as soon as I uncomment the printf, all hell breaks loose
with
legacy_stdio_definitions.lib(legacy_stdio_definitions.obj) :
error LNK2019: unresolved external symbol __acrt_iob_func
referenced in function _vwprintf_l
legacy_stdio_definitions.lib(legacy_stdio_definitions.obj) :
error LNK2019: unresolved external symbol
__stdio_common_vfwprintf referenced in function _vfwprintf_l
legacy_stdio_definitions.lib(legacy_stdio_definitions.obj) :
error LNK2019: unresolved external symbol
__stdio_common_vfwprintf_s referenced in function _vfwprintf_s_l
o o o
Walter Bright even wrote a three line module at
https://github.com/dlang/dmd/blob/master/samples/mydll/mydll.d
which uses the printf.
It appears as you use recent Microsoft Linker and toolset. Which
requires adding legacy_stdio_definitions.lib in linking list.
Also i tested this example with DMD 2.092.1 - completed
succesfully. It uses mingw toolset and lld-link. (I have no VS
installed)
