Re: TLF = thread local functions
On Friday, 24 January 2014 at 06:03:27 UTC, dennis luehring wrote: no - the parameters and local vars of the function are in the stack of the thread - so there is no problem with them, only shared variables can have a need to synchronization your idea tries to solve non existing problems? ...Unless the thread is started with a delegate (literal or member function), which implicitly gains an unsynchronized view of its enclosing scope (or class). Granted, the "default" D's spawning function, std.concurrency.spawn, being restrictive like a firm parent, simply would not allow this. However, it may sometimes be feasible to do so (using Thread interface directly), although this is a case for "I know what I'm doing" category. If we had a way of explicitly capturing variables for delegate literals, the problem with delegates could go away altogether.
Re: can't I use __traits(allMembers) recursivly ?
Orange is neat I had a look at but, the docs are abit lacking ... I don't really know how to get it to do what i want Well I have an Enum in a Struct and I need to serialze the struct members and "unfold" the enum. can orange do that ?
Re: can't I use __traits(allMembers) recursivly ?
On Friday, 24 January 2014 at 06:11:30 UTC, Uplink_Coder wrote: I'm trying to serialize my struct through CT-Refelction Maybe your _pod_ functions needs a parameter. // take a look at std.conv.to string toString(P)(P pod) { }
Re: can't I use __traits(allMembers) recursivly ?
On Friday, 24 January 2014 at 09:14:31 UTC, Tobias Pankrath wrote: On Friday, 24 January 2014 at 06:11:30 UTC, Uplink_Coder wrote: I'm trying to serialize my struct through CT-Refelction Maybe your _pod_ functions needs a parameter. // take a look at std.conv.to string toString(P)(P pod) { } Oops, that was not finished. __traits(getMember, pod, member) could now be used. But you'll need to check if member really is a field. So it's easier to iterate over std.traits.FieldTypeTuple directly.
Re: TLF = thread local functions
On Friday, 24 January 2014 at 08:11:53 UTC, Stanislav Blinov wrote: ...Unless the thread is started with a delegate (literal or member function), which implicitly gains an unsynchronized view of its enclosing scope (or class). Which means accessing shared data pretty much by definition. It actually should not even compile without explicit casts. I guess yet another delegate qualifier bug. Um, duh, but in d data is already TLS. 1) not necessarily, is is only default 2) "using TLS data" usually implies "using _own_ TLS data" as you shouldn't be able to get reference to TLS of other thread without dirty hacks (it breaks basic type system assumptions)
Re: shared methods
Am Thu, 23 Jan 2014 19:20:34 + schrieb "Kagamin" : > A minor caveat is GDC treats shared as volatile, which can be not > optimal. Even worse, on some platforms like itanium volatile > generates fences. Do you have more information on that issue? There are claims that Itanium "automatically generates fences", however that statement is not precise and I can't find a detailed description. Itanium has special instructions which refresh the caches before reading/writing. But the interesting question is this: Does GCC use these instructions if you access a variable marked as volatile? If it does, that's really a performance problem. AFAICS we need a 'volatile' in D for embedded programming which just does the following: * Avoid removing any stores / or loads to that variable (includes moving accesses out of loops) * Avoid instruction reordering between accesses to volatile variables: volatile int a, c; int b; a = 0; b = 0; c = 0; b can be moved anywhere, but c must always come after a Here volatile should only affect the ASM generated by the compiler, it shouldn't care at all what the final CPU does, that's the programmers task. In some cases the compiler can't even know: For example some memory areas in ARM are special and the processor won't reorder accesses to those areas anyway, so a 'smart compiler' adding memory barriers would actually only harm performance. http://infocenter.arm.com/help/topic/com.arm.doc.dui0552a/CIHGEIID.html Such a 'volatile' could be integrated with shared as it should not cause any huger performance problems. However, if you think of this code: shared int X; synchronized(x) { for(int i=0; i< 100; i++) X = i; } it's actually valid to optimize the loop, so 'volatile' behavior is not wanted. But what if we used atomic ops? shared int X; for(int i=0; i< 100; i++) atomicSet(X, i); Now the loop can't be optimized away. Is the compiler smart enough to figure out that an atomic op is used and it can't optimize this? Or would we have to mark this volatile?
Re: TLF = thread local functions
On Friday, 24 January 2014 at 09:50:44 UTC, Dicebot wrote: On Friday, 24 January 2014 at 08:11:53 UTC, Stanislav Blinov wrote: ...Unless the thread is started with a delegate (literal or member function), which implicitly gains an unsynchronized view of its enclosing scope (or class). Which means accessing shared data pretty much by definition. I would rephrase that as "implicitly sharing not explicitly shared data". It actually should not even compile without explicit casts. I guess yet another delegate qualifier bug. Why shouldn't it compile? Safe spawner (std.concurrency.spawn) does not accept delegates. Unsafe one (core.thread.Thread) does. I wouldn't consider it a bug since in the context of one thread it's pretty much a feature :) But I agree that some special syntax for threading and otherwise restricting sharing would be great. Maybe another set of parentheses? Consider: // Call could be anything. Just a call, do-some-work-and call, // spawn a thread, etc. void call(F,Args...)(F dg,Args args) if (is(F == delegate)) { dg(args); } void main() { int myPreciousInt = 42; string myPreciousString = "precious"; // current syntax, horrifying if call spawns a thread with that delegate call({ myPreciousInt = 151; // modifies main's myPreciousInt myPreciousString = "stolen"; // ditto }); // current syntax with parameters, ditto call((int i){ myPreciousInt = i; myPreciousString = "stolen"; }); // explicit capture syntax: call((myPreciousInt){// capture by value myPreciousInt = 132; // changes local variable myPreciousString = "stolen"; // would not compile, variable is not captured }); // explicit capture with parameters: call((ref myPreciousInt)(int i){ // capture by reference myPreciousInt = 144; // will modify main's myPreciousInt too }); } This could be extended to support various capture qualifies: ref - by reference in - by move ref shared - by reference if variable is shared etc. Looks like C++'s [](){}, perhaps, but with D's powerful compile-time facilities we could do so much more. For example, the above, coupled with some introspection with e.g. __traits(captures, dg) could give way to implementing safe thread spawners even for delegates: e.g. disallow capturing non-shared data by reference. As I mentioned, currently pretty much all that can be done is a shallow copy of the stack (which means allocation), and I don't even know how portable or safe that is :) Um, duh, but in d data is already TLS. 1) not necessarily, is is only default 2) "using TLS data" usually implies "using _own_ TLS data" as you shouldn't be able to get reference to TLS of other thread without dirty hacks (it breaks basic type system assumptions) In my understanding delegates are pretty much unique at that. Probably because they were redesigned like that since D1, but never were taken one step further towards multithreading.
Re: Python calling D
On Fri, 2014-01-24 at 02:29 +, Ellery Newcomer wrote: […] I have just tried a trivial D source shared object on Debian Unstable using DMD 2.064.2 from d-apt. Compile up the shared object with entries C linkage, try to use ctypes or CFFI from Python just gives a segmentation violation :-( > python wants shared libs, not static libs. but this is very > fiddly. so use pyd. > > 1. clone the ariovistus/pyd repo > 2. from top dir, type > > python setup install > python runtests.py hello Probably want to use a virtualenv for this rather than install into the base installation > (or > cd examples/hello > python setup.py build > python test.py) > > this will run the code found in examples/hello (it's a simple > python calls D) > > use python 2.7 and have dmd 2.064 on your path somewhere. It > should just work. It needs to work for Python 3.3 as well! -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: TLF = thread local functions
On Friday, 24 January 2014 at 10:43:05 UTC, Stanislav Blinov wrote: It actually should not even compile without explicit casts. I guess yet another delegate qualifier bug. Why shouldn't it compile? Safe spawner (std.concurrency.spawn) does not accept delegates. Unsafe one (core.thread.Thread) does. I wouldn't consider it a bug since in the context of one thread it's pretty much a feature :) But I agree that some special syntax for threading and otherwise restricting sharing would be great. Maybe another set of parentheses? D type system is supposed to guarantee that you never ever can get pointer/reference to data that is not stored in your own TLS (including stack) unless it is marked as shared (immutable / __gshared are in shared category). By allowing to spawn thread with a delegate which has context pointer not qualified as shared you break that type system sanity rule. Multithreading / concurrency in D is quite different from C++. Um, duh, but in d data is already TLS. 1) not necessarily, is is only default 2) "using TLS data" usually implies "using _own_ TLS data" as you shouldn't be able to get reference to TLS of other thread without dirty hacks (it breaks basic type system assumptions) In my understanding delegates are pretty much unique at that. Probably because they were redesigned like that since D1, but never were taken one step further towards multithreading. Delegates unique in a sense that they often erase type qualifiers for the context because of rather hacky current implementation. All such cases are bugs that contradict language spec, there is nothing intentional about it. There are no legal exceptions to the rule "all shared data must be shared".
Re: can't I use __traits(allMembers) recursivly ?
I have solved by problem. I just forgot to prepend static to the ifs I used :D
Re: TLF = thread local functions
On Friday, 24 January 2014 at 11:00:42 UTC, Dicebot wrote: D type system is supposed to guarantee that you never ever can get pointer/reference to data that is not stored in your own TLS (including stack) unless it is marked as shared (immutable / __gshared are in shared category). Agreed. By allowing to spawn thread with a delegate which has context pointer not qualified as shared you break that type system sanity rule. Agreed again. AFAIK, that was the exact reasoning behind restricting std.concurrency to not allow delegates as thread functions or message types. Multithreading / concurrency in D is quite different from C++. With this I cannot completely agree. Granted, we have "shared" qualifier and by-default-TLS static data. Oh, and built-in monitors + synchronized methods (which are of dubious value at best). In that, D differs. But the bare bones of concurrency still are the same. Access to shared data still has to be manually synchronized somehow (locks, atomics, cas, you name it). Threads still have to be spawned and joined as necessary. Ok, we have some of the boilerplate removed thanks to std.concurrency and std.parallelism, but that's just library solutions, not unlike those that exist for C++. I.e. there's nothing in the language that says "use that!". And sadly, when threading is concerned, purity doesn't help much because of the "weak purity" concept. Delegates unique in a sense that they often erase type qualifiers for the context because of rather hacky current implementation. All such cases are bugs that contradict language spec, there is nothing intentional about it. There are no legal exceptions to the rule "all shared data must be shared". Agreed. Oh, speaking of holes in the type system. Synchronization primitives like Mutex, Condition, etc. (which should be de-facto shared) aren't qualified as shared. Do you know if it's intentional or?..
Re: User defined types: Problems with ref
Now the output is as it should be (after changing the elements). // The div.toString(); Hello, world! I am a span // Tree Elements [ Hello, world! I am a span , I am a span ]
Re: User defined types: Problems with ref
On Friday, 24 January 2014 at 01:26:06 UTC, Ali Çehreli wrote: On 01/23/2014 07:26 AM, Chris wrote: > On Thursday, 23 January 2014 at 15:24:19 UTC, Chris wrote: >> Here's what I'm trying to do. >> >> struct Element(T) { >> T x; >> T y; >> >> public void setX(T value) { >> x = value; >> } >> // More fancy functions ... >> } >> >> I store Element(s) in an array and want to pass each one by reference, >> which does not work. >> >> >> class Tree { >> >> Element!string[] elements; >> >> public ref auto createElement(string name) { >> elements ~= Element!string(name); >> return elements[$-1]; >> } >> } >> >> in main: >> >> auto tag = Element!string("first"); >> >> The elements in Tree.elements and the ones in main are not the same, >> instead I obtain a copy of each. >> How can I make them refer to the same Elements? If I have to add a >> .ptr property to Element, how do I do that? Is that possible at all or >> did I shoot myself in the foot with the template? > > Sorry in main it is: > > auto tree = new Tree(); > auto tag = tree.createElement("first"); createElement does return a reference. However, because D does not have local references the type of tag is Element!string (not 'ref Element!string'). The following program demonstrates that the address of the returned reference is indeed the same as the one that has been created: import std.stdio; struct Element(T) { T x; T y; public void setX(T value) { x = value; } // More fancy functions ... } class Tree { Element!string[] elements; public ref auto createElement(string name) { elements ~= Element!string(name); writefln(" created element at %s", &elements[$-1]); return elements[$-1]; } } void main() { auto tree = new Tree(); writefln("received element at %s", &tree.createElement("first")); } Sample output: created element at 7F14C72C0F80 received element at 7F14C72C0F80 You can use the returned element directly as well: tree.createElement("second").setX("hello"); Ali Thank you guys. Yes, it's the array bit that kills the reference as FreeSlave pointed out. After tinkering around with it, I've (reluctantly) turned Element into a class to get the reference semantics. I need a reference so I can do things like tree.getElementById("div"); It's a basic (very simple) HTML / markup thing. Tree stores all elements, but the elements are changed outside Tree, like so auto div = tree.createElement("div"); div.setAttribute("id", "1"); // ... div.appendChild(...); etc. I'm sure there are cleverer ways of implementing a HTML tree.
N-body bench
If someone if willing to test LDC2 with a known benchmark, there's this one: http://benchmarksgame.alioth.debian.org/u32/performance.php?test=nbody A reformatted C++11 version good as start point for a D translation: http://codepad.org/4mOHW0fz Bye, bearophile
fibers/coroutines tutorial?
Is there a quick tutorial/intro for what D offers as an equivalent or alternative to "goroutines"? I've seen the concurrency link on the homepage .. and umm .. call me lazy but I don't feel like reading through all that just to see what D's alternative to goroutines looks like ..
Re: fibers/coroutines tutorial?
On Friday, 24 January 2014 at 16:02:27 UTC, Hasan wrote: Is there a quick tutorial/intro for what D offers as an equivalent or alternative to "goroutines"? I've seen the concurrency link on the homepage .. and umm .. call me lazy but I don't feel like reading through all that just to see what D's alternative to goroutines looks like .. Yes, and it is listed on http://wiki.dlang.org . Please go to articles/tutorials part of that web-site and enjoy really good reads.
Profiling
I'm trying to use the `-profile` flag for DMD and, without any documentation, I can't really understand the resulting log files: * They contain only mangled names. Is there a way to get demangled, human-readable symbols? * Can someone tell me what the numbers means? Is there a page somewhere on dlang.org that explains how to use the profiler? Thanks, Philippe
Re: fibers/coroutines tutorial?
On Friday, 24 January 2014 at 16:02:27 UTC, Hasan wrote: Is there a quick tutorial/intro for what D offers as an equivalent or alternative to "goroutines"? I've seen the concurrency link on the homepage .. and umm .. call me lazy but I don't feel like reading through all that just to see what D's alternative to goroutines looks like .. Well if you really want to skip everything and go straight to code, it is all about fibers : http://dlang.org/phobos/core_thread.html#.Fiber
Re: Profiling
24-Jan-2014 20:31, Philippe Sigaud пишет: I'm trying to use the `-profile` flag for DMD and, without any documentation, I can't really understand the resulting log files: * They contain only mangled names. Is there a way to get demangled, human-readable symbols? pipe it though ddemangle tool. I though it was shipped with compiler. * Can someone tell me what the numbers means? Ticks spent in this function. One column specifies inclusive time (the whole call-tree of that function) another one exclusive - time spent exactly in this function not its children. Is there a page somewhere on dlang.org that explains how to use the profiler? http://digitalmars.com/ctg/trace.html see Dynamic Profiling With DMD Thanks, Philippe -- Dmitry Olshansky
Re: Profiling
On Fri, Jan 24, 2014 at 8:15 PM, Dmitry Olshansky wrote: > 24-Jan-2014 20:31, Philippe Sigaud пишет: > >> I'm trying to use the `-profile` flag for DMD and, without any >> documentation, I can't really understand the resulting log files: >> >> * They contain only mangled names. Is there a way to get demangled, >> human-readable symbols? >> > pipe it though ddemangle tool. I though it was shipped with compiler. Maybe it is :-) I never used it, though. Will it automatically demangle all mangled symbols it finds? Can I use it on other outputs with mangled symbols? >> * Can someone tell me what the numbers means? > > > Ticks spent in this function. One column specifies inclusive time (the whole > call-tree of that function) another one exclusive - time spent exactly in > this function not its children. OK. I get it. >> Is there a page somewhere on dlang.org that explains how to use the >> profiler? > > > http://digitalmars.com/ctg/trace.html > see Dynamic Profiling With DMD There it is! I knew I saw some page on profiling long ago. Must have been before the switch to dlang.org. Thanks a lot.
Re: Profiling
Please file a bug on this. The docs should be on dlang.org. On 1/24/14 11:15 AM, Dmitry Olshansky wrote: 24-Jan-2014 20:31, Philippe Sigaud пишет: I'm trying to use the `-profile` flag for DMD and, without any documentation, I can't really understand the resulting log files: * They contain only mangled names. Is there a way to get demangled, human-readable symbols? pipe it though ddemangle tool. I though it was shipped with compiler. * Can someone tell me what the numbers means? Ticks spent in this function. One column specifies inclusive time (the whole call-tree of that function) another one exclusive - time spent exactly in this function not its children. Is there a page somewhere on dlang.org that explains how to use the profiler? http://digitalmars.com/ctg/trace.html see Dynamic Profiling With DMD Thanks, Philippe
Re: fibers/coroutines tutorial?
On Fri, 2014-01-24 at 16:02 +, Hasan wrote: > Is there a quick tutorial/intro for what D offers as an > equivalent or alternative to "goroutines"? > > I've seen the concurrency link on the homepage .. and umm .. call > me lazy but I don't feel like reading through all that just to > see what D's alternative to goroutines looks like .. Now that is just bad research ;-) As far as I am aware D has no equivalent of Go's goroutines per se. A goroutine is (well should be) a process with no access to any global shared memory, with channels with which to communicate to other goroutines. Effectively Go realizes Communicating Sequential Processes (CSP), not 1978 style, but about 2009 style. D's built-in concurrency/parallelism supports is much more akin to actors. D would be improved by having a realization of CSP to augment what it already has. For now though you would have to build a CSP-style system over the actor-style system, though this would have inefficiencies. The problem will be how to realize the select operation. For now the only realizations of CSP that I am aware of that are usable are Go, PyCSP, PythonCSP, JCSP, GroovyCSP, C++CSP2. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Profiling
On Fri, Jan 24, 2014 at 8:35 PM, Brad Roberts wrote: > Please file a bug on this. The docs should be on dlang.org. Here it is: https://d.puremagic.com/issues/show_bug.cgi?id=11985
Re: Profiling
Am 24.01.2014 17:31, schrieb Philippe Sigaud: I'm trying to use the `-profile` flag for DMD and, without any documentation, I can't really understand the resulting log files: * They contain only mangled names. Is there a way to get demangled, human-readable symbols? * Can someone tell me what the numbers means? Is there a page somewhere on dlang.org that explains how to use the profiler? Thanks, Philippe What Plattform are you profiling on?
Re: shared methods
for example http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming
Re: shared methods
http://igoro.com/archive/volatile-keyword-in-c-memory-model-explained/ As I understand, because Itanium doesn't have cache coherency, a memory fence is needed to implement volatile load and store. On x86 load and store are already volatile because of cache coherency, so fences are not needed.
How to skip permission denied exceptions if iterate through directories?
Hi, Im a newbie in D and I have a small problem. Thats my method //* private void searchAndRunAction() { foreach (entry;dirEntries(paramPath, paramSearchType, (paramSwitchRecursiveOn ? SpanMode.breadth : SpanMode.shallow))) { filesCount++; if (isDuplicate(entry.name)) { filesDupCount++; if (paramSwitchDeleteOn) remove(entry.name); } printProgress(entry.name); } } I want work through a directory on my linux server but there are some directories I have no permissions to access so I get following: ~/Projects/cltools/smdups $ source/smdups -r -p=/media/clas/Elements2 -e=*.* std.file.FileException@../../../../src/libphobos/src/std/file.d(2353): /media/clas/Elements2/lost+found: Permission denied /home/clas/Projects/cltools/smdups/source/smdups() [0x43cb1d] /home/clas/Projects/cltools/smdups/source/smdups() [0x43eab4] /home/clas/Projects/cltools/smdups/source/smdups() [0x404768] /home/clas/Projects/cltools/smdups/source/smdups() [0x404116] /home/clas/Projects/cltools/smdups/source/smdups() [0x404d2d] /home/clas/Projects/cltools/smdups/source/smdups() [0x41a71f] /home/clas/Projects/cltools/smdups/source/smdups() [0x41ae7f] /home/clas/Projects/cltools/smdups/source/smdups() [0x41b0b0] /home/clas/Projects/cltools/smdups/source/smdups() [0x41ae7f] /home/clas/Projects/cltools/smdups/source/smdups() [0x41b018] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f66a29c8de5] /home/clas/Projects/cltools/smdups/source/smdups() [0x403e63] ~/Projects/cltools/smdups $ std.file.FileException@../../../../src/libphobos/src/std/file.d(2353): /media/clas/Elements2/lost+found: Permission denied std.file.FileException@../../../../src/libphobos/src/std/file.d(2353):: command not found My question: How to skip any exceptions in dirEntries. I tried it with filter. But no chance. Is there a way to do it like in C# with LINQ-Expressions? greets clas
Re: How to skip permission denied exceptions if iterate through directories?
On Friday, 24 January 2014 at 23:46:04 UTC, Clas Onnebrink wrote: Hi, Im a newbie in D and I have a small problem. Thats my method //* private void searchAndRunAction() { foreach (entry;dirEntries(paramPath, paramSearchType, (paramSwitchRecursiveOn ? SpanMode.breadth : SpanMode.shallow))) { filesCount++; if (isDuplicate(entry.name)) { filesDupCount++; if (paramSwitchDeleteOn) remove(entry.name); } printProgress(entry.name); } } I want work through a directory on my linux server but there are some directories I have no permissions to access so I get following: ~/Projects/cltools/smdups $ source/smdups -r -p=/media/clas/Elements2 -e=*.* std.file.FileException@../../../../src/libphobos/src/std/file.d(2353): /media/clas/Elements2/lost+found: Permission denied /home/clas/Projects/cltools/smdups/source/smdups() [0x43cb1d] /home/clas/Projects/cltools/smdups/source/smdups() [0x43eab4] /home/clas/Projects/cltools/smdups/source/smdups() [0x404768] /home/clas/Projects/cltools/smdups/source/smdups() [0x404116] /home/clas/Projects/cltools/smdups/source/smdups() [0x404d2d] /home/clas/Projects/cltools/smdups/source/smdups() [0x41a71f] /home/clas/Projects/cltools/smdups/source/smdups() [0x41ae7f] /home/clas/Projects/cltools/smdups/source/smdups() [0x41b0b0] /home/clas/Projects/cltools/smdups/source/smdups() [0x41ae7f] /home/clas/Projects/cltools/smdups/source/smdups() [0x41b018] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f66a29c8de5] /home/clas/Projects/cltools/smdups/source/smdups() [0x403e63] ~/Projects/cltools/smdups $ std.file.FileException@../../../../src/libphobos/src/std/file.d(2353): /media/clas/Elements2/lost+found: Permission denied std.file.FileException@../../../../src/libphobos/src/std/file.d(2353):: command not found My question: How to skip any exceptions in dirEntries. I tried it with filter. But no chance. Is there a way to do it like in C# with LINQ-Expressions? greets clas One way would just be to catch the exceptions. Note you may want to activate debug mode to know what functions are actually failing. A FileException is being fired when it cannot do a file operation as detailed in phobos documentation.
Linux dll -> Windows dll
Alright.. I've been having issues with getting windows DLL's to work with DMD, as in I can't make them and can't even compile without a bunch of errors. So, I need help on that, as the dll part of the site ain't helping. Also, any idea on how to convert some of the dll stuff on https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/core.d to be windows compatible, I was having weird issues with that also.
Re: Linux dll -> Windows dll
On Saturday, 25 January 2014 at 03:13:33 UTC, Mineko wrote: Alright.. I've been having issues with getting windows DLL's to work with DMD, as in I can't make them and can't even compile without a bunch of errors. So, I need help on that, as the dll part of the site ain't helping. Also, any idea on how to convert some of the dll stuff on https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/core.d to be windows compatible, I was having weird issues with that also. https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/core.d#L158 you are about this? it is just "dmd -shared -ofmydll.dll files.d", the problem is that you may have to add DllMain. if this doesn't works for you then put a error or describe what exactly doesn't work.