Re: DLL hell :S
On Saturday, 7 October 2017 at 15:30:30 UTC, rikki cattermole wrote: A little from column a, a little from column b, but most because he might be able to do something for you. Thanks, I'll send him an email.
Re: DLL hell :S
On 07/10/2017 4:29 PM, Ian Hatch wrote: On Saturday, 7 October 2017 at 15:14:01 UTC, rikki cattermole wrote: Email Walter directly. I intend to campaign for next years (basically a soft TODO list) plan for what we want done. But until then, he and Andrei need to hear that this is the biggest limitation that D faces currently, not memory management. Hm, are you saying "if you email Walter he can tell you how to sort it" or "please make sure Walter knows this problem is important" (or both)? Definitely happy to give my feedback. A little from column a, a little from column b, but most because he might be able to do something for you. "not memory management" gives me an idea actually - if I ditch the GC, which I may want to do eventually anyway, I guess I won't have this issue.
Re: DLL hell :S
On Saturday, 7 October 2017 at 15:14:01 UTC, rikki cattermole wrote: Email Walter directly. I intend to campaign for next years (basically a soft TODO list) plan for what we want done. But until then, he and Andrei need to hear that this is the biggest limitation that D faces currently, not memory management. Hm, are you saying "if you email Walter he can tell you how to sort it" or "please make sure Walter knows this problem is important" (or both)? Definitely happy to give my feedback. "not memory management" gives me an idea actually - if I ditch the GC, which I may want to do eventually anyway, I guess I won't have this issue.
Re: DLL hell :S
Email Walter directly. I intend to campaign for next years (basically a soft TODO list) plan for what we want done. But until then, he and Andrei need to hear that this is the biggest limitation that D faces currently, not memory management.
DLL hell :S
Hello! I'm Ian, and I've been a programmer in games for 10 years. I've been poking at D for a year or so and I'm absolutely in love with the compile-time execution and inline unit testing in particular. I've been trying for a while to set up a project that I intend to build a lot of my future code on top of, but I'm stumbling at one of the first hurdles at the moment so I'm hoping I can straighten this out and be able to keep using D. My framework is supposed to load plugin dlls (and later sharedobjects) which operate on memory allocated by the executable, and sadly I've hit roadblock after roadblock trying to get this set up. Following https://wiki.dlang.org/Win32_DLLs_in_D I've gotten to a stage where I successfully load the DLL, find my functions, and call them passing the objects to be modified. Initially this was crashing immediately. After a lot of digging I found https://issues.dlang.org/show_bug.cgi?id=17326, so now I've added the gcopt to my dll to set the gc to manual, and I'm passing over my gc pointer and trying to set it as the proxy. Unfortunately this results in the DLL getting stuck in a spinlock in addRange within gc_setProxy() :( DLL side: https://pastebin.com/yBPs0A30 EXE side: https://pastebin.com/h2qLBqXA Thread lock call stack: https://pastebin.com/zUvH3Cnb I'm not really sure where to go from here. I'm doing this in my spare time and I've been stuck for months on something I know how to do in C++ (I really should have asked for help earlier). Is there an up to date example someone can point me to of how to set this up correctly so that the DLL uses the exe's runtime and/or garbage collector?
