Re: DFL can be used by D2.065
Is there somebody maintaining the GTK branch of DFL? -- Jordi Sayol
Re: DFL can be used by D2.065
On Thursday, 27 March 2014 at 07:32:38 UTC, Mike Parker wrote: On 3/27/2014 10:57 AM, FrankLike wrote: On Wednesday, 26 March 2014 at 10:42:09 UTC, Andrej Mitrovic wrote: On 3/26/14, FrankLike 1150015...@qq.com wrote: If you are programming on win32,now,DFL can be used by D2.065. Please git clone http://github.com/FrankLike/dfl Open the folder w32 -dflexe double click the 'makedflexe.bat' FYI: you've changed one hardcoded path to another. I also don't understand the removal of the package module. Anywho I don't use DFL much. : package module Let the all.d is null,most of codes have used the dfl.all,so keep all.d and remove package.d ,that's ok. thank you. It's fine to keep both. Old code (if any of it out there still compiles) can continue to use dfl.all, while new projects can make user of the newer package.d. The *.all technique should be deprecated in old projects like this, IMO, not encouraged. Thank you,Mike Sorry,I test the newer package.d ,but it's not work. Error 42:Symbol Undefined _D3dfll2__ModuleInfoZ Can you contact the Christopher E. Miller? He should keep continue his work,it's very good. Thank you again.
Cerealed V0.4.1
http://code.dlang.org/packages/cerealed Binary serialisation library with minimal boilerplate. New in this version: . Support for (non-null) pointers . Child class serialisation via a base class reference . Support for InputRange and OutputRange . Ability to reuse the classes in order to avoid allocating garbage . Bug fixes On the horizon: I want to make a breaking change in the next version, and that is to replace the classes with structs. It dawned on me that picking what direction the serialisation happens is never done at run-time so I can avoid all the virtual calls. I can see some breaking changes but only for custom serialisation. Atila
Re: CMake with D support early snapshot
On 26 March 2014 23:17, Ben Boeckel maths...@gmail.com wrote: On Wed, Mar 26, 2014 at 22:52:43 +, Trent Forkert wrote: However, if we have gdc produce make-style dependencies (which will still require processing to get CMake to be happy), that requires me to put a special case in the C++ that I'd rather not have. I'm fine with either, but make-style is preferred since it can exclude system files (which I've asked LDC about supporting as well; should ask dmd too). The way I see it, there are three possibilities here: 1. Keep gdc producing make-style deps, and deal with that as needed. 2. Have gdc produce dmd-style deps, and let the patched Ninja you mentioned use that. 3. Have a separate flag registered for the two different styles of dependencies. I'm quite partial to number 3, as I could then use that to check which flags are defined for which style is supported, and act accordingly. I prefer that to hardcoding gdc does this. Anything else does this other thing. What about: 4. Add depfile support to Makefile generators. It seems that it shouldn't be *too* hard[1] to do. Obviously, dmd-style deps will still have problems with make, but we could try and ask the dmd and ldc upstream to at least support Make-style dependency files (this would mean old dmd/ldc + make isn't supported, but at least Ninja would be an option there). If that fails, some CMake code to generate Make-style .d files from dmd-style shouldn't be too bad (some regex matching and character escaping should do the trick). Ain't the dmd-style deps legacy from a failed D build system? It's just kept around cause more recent/current build systems /may/ find it's output useful.
Re: CMake with D support early snapshot
On Thu, Mar 27, 2014 at 17:21:45 +, Iain Buclaw wrote: Ain't the dmd-style deps legacy from a failed D build system? It's just kept around cause more recent/current build systems /may/ find it's output useful. Well, it's what we have currently. We could add support for gcc-compatible depfiles, but then you're stuck with only new versions of DMD or LDC if you use CMake. Adding support to CMake and Ninja is much easier than upgrading the compiler since they're much smaller and more easily upgradable (fewer moving parts, lower chance of getting subtle new behavior[1], more reasonable to expect or ask users to have an up-to-date version, etc.). Getting the -M flags recognized and implemented in DMD and LDC are good goals to shoot for, but we're constrained by the tools we have available… --Ben [1]CMake is (ideally) loud when this occurs through its policy system.m
Re: Experimental win32 OMF linker written in D now on github
On Sunday, 23 March 2014 at 20:33:15 UTC, Daniel Murphy wrote: It still needs a lot of work, but it's functional. Is there a test suite that you have to pass to declare it fully functional?
Re: CMake with D support early snapshot
FWIW, I just pushed my implementation of cmDependsD[1], and found dmd-style deps much nicer to work with. I used the =2.064 ability to do dmd -c -o- -deps foo.d since that also contains file imports, which are technically dependencies. I missed when/if this was discussed on the list, but it seems that form of dependency output at least is intended to stay, even if it forces us to drop support for older compiler versions. - Trent [1]https://github.com/trentforkert/cmake/commit/bbaa6b1f82d6c55154a95d1995007e408c31103e
Dconf 2014 Early Bird registration ticket prices about to expire!
http://dconf.org/2014/registration.html Early Bird ticket prices are good through March 31.
