aBothe
support code completion alternative using DCD
I think coupling with the c# parser is a little too tight to make this easy to implement but I could be wrong
i have no idea. but i like the idea to have every tooling support DCD in the long run so that one major completion system gets all the love and finally work on this side of dlang tooling unites.
I'd either have to reinvent the dcd-client-wheel, or just put up some CLI that interacts with dcd-client.
Despite that, it should be feasible, although I had to restructure whole parts of mono-d's existing completion & refactoring infrastructures.
i guess interacting with the dcd client is what every other editor does right now, too
The thing is though, Mono-D's parser and completion engine is better in my experience than DCD's is.
yeah but I see more potential for it since it can be used on any platform and be integrated relatively easily in any other IDE or tool. so in the long run I see it taking over and it would be great to have mono-d support both for now
so in the long run I see it taking over and it would be great to have mono-d support both for now
I agree, but at this point there isn't much else than maintenance work and I don't see any added value in using another parser. I'd much prefer to see that effort invested on more elaborate template resolution in Mono-D's parser, rather than integrating another parser
Ah right, those resolution caches for Botan's pseudo-preprocessors - gonna try to get something tomorrow :)
Heh thanks =) I ended the day on a good note, 95% of tests are working (though only on DMD master). That's 35 block crypto, 23 hash algos, 5 stream ciphers, 9 cipher modes, 8 pads, 6 mac, 3 kdf, 4 random number gens, 10 entropy sources, 11 public key algos and all the x509, pem, asn1, ber/der serialization, certificate handling, big int, elliptic curve powermods, modulators, reducers, math processing, simd operations, C++-style containers. The only thing left is testing the TLS in vibe.d and applying the original repo's commits. I had to find a lot of workarounds to get it all working together but so far I wonder if it isn't the biggest D project, with ~100k LOC
Hopefully most of these things are generated/converted automatically :P - but yeah, respect for making a crypto library for D! :)
Hopefully most of these things are generated/converted automatically :P - but yeah, respect for making a crypto library for D! :)
Yeah.. if 'automatically' means regex & search replace for the bulk of it, and very hard work for the rest :-p
Actually, @etcimon, Orvid/TribesAscendSDK contains just over 245k lines of D code, and that would be longer if I didn't use a few mixins to shorten the generated code. It's 11mb of source code, and, for most people to be able to compile it, I had to split it into 14 static libraries that get built and then linked against. It's possible to compile it all at once, but it takes just shy of 4gb of ram (at last check). That number would be even bigger if I were using any real amount of CTFE. That project also is why Mono-D will use the @ argument syntax for the compilers if the arguments become too long. (all but a couple of the static libs require that syntax to be used in order to compile them :P) For a while I couldn't even load the project to begin with, because Xamarin Studio was running out of room in the 32-bit address space for Mono-D to work with XD
So, this is a wrapper to the unreal engine, and more? That's mind blowing. It looks like you have a C++ to D header compiler as well I think? I was mostly focusing on putting the entirety of C++ code in D so I can maintain development later and add some algorithms. But this library is a completely different topic. Hell, you can't just translate the entire unreal engine to D by hand :-p It almost seems like all the open source code efforts are being put into video games, it would take years for me to wrap my head around all those concepts.
Nope, it doesn't touch the headers at all, instead it actually retrieves the information on the classes in memory after the game loads all the UnrealScript packages, and uses that information to generate D interfaces that can be used to directly interop with UnrealScript code. Very little of it is actually translated from C++ headers, and what is translated from them was done manually.