Re: Release Candidate D 2.067.0-rc1
On Tuesday, 17 March 2015 at 14:01:18 UTC, Steven Schveighoffer wrote: On 3/17/15 7:18 AM, Daniel Kozak wrote: On Monday, 16 March 2015 at 21:38:22 UTC, Martin Nowak wrote: Release Candidate for 2.067.0 http://downloads.dlang.org/pre-releases/2.x/2.067.0/ http://ftp.digitalmars.com/ You can get the binaries here until they are mirrored. https://dlang.dawg.eu/downloads/dmd.2.067.0-rc1/ We fixed the few remaining issues. https://github.com/D-Programming-Language/dmd/compare/v2.067.0-b4...v2.067.0-rc1 https://github.com/D-Programming-Language/phobos/compare/v2.067.0-b4...v2.067.0-rc1 Unless any new issue pops up, we'll make the release on friday. -Martin Does not work with my code base :( dmd: interpret.c:6724: void setValue(VarDeclaration*, Expression*): Assertion `(vd->storage_class & (0x1000LL | 0x20LL)) ? isCtfeReferenceValid(newval) : isCtfeValueValid(newval)' failed. Exit code 134 This is an ICE (internal compiler error) and is something that needs to be filed. If you file it soon, it may be addressed before the release. http://issues.dlang.org -Steve https://issues.dlang.org/show_bug.cgi?id=14304
Re: DDT 0.11.0 released
Just go to project Properties, Builders, de-select DUB Build and add any another build option or script you need. On Tuesday, 17 March 2015 at 23:54:06 UTC, Manu wrote: I just checked out DDT, and I noticed it seems to use DUB... >_<
Re: Release Candidate D 2.067.0-rc1
On Wednesday, 18 March 2015 at 00:47:20 UTC, Martin Nowak wrote: On 03/18/2015 01:13 AM, Manu via Digitalmars-d-announce wrote: Yes. Has for a while. We're really hanging out for the 32bit COFF libs to ship with DMD. Well, someone should add a build target to https://github.com/D-Programming-Language/phobos/blob/master/win32.mak. How is the phobos.lib called to avoid conflicts? It's a bit late to come up with this, will see if I can find enough time for this. phobos32.lib I suppose? Would be great if it was there. That + struct d-tors would make this release great for those that wait to be able to create C++/D apps for Win32.
Re: Digger 1.1
On Sunday, 8 March 2015 at 18:20:07 UTC, Robert M. Münch wrote: Ok, great. I just tried it on Windows and get this here: I've pushed support for DMD bootstrapping, so if you need to build master now, build latest Digger from source. I'll make a binary release after 2.067 is out.
Re: Digger 1.1
On 03/04/2015 05:54 AM, Vladimir Panteleev wrote: > Finally, this is the first stable release with binary downloads for all > major platforms: Nice, out of curiosity. How did you build the releases for all the platforms?
Re: Digger 1.1
On Wednesday, 18 March 2015 at 18:18:19 UTC, Martin Nowak wrote: On 03/04/2015 05:54 AM, Vladimir Panteleev wrote: Finally, this is the first stable release with binary downloads for all major platforms: Nice, out of curiosity. How did you build the releases for all the platforms? Natively for Windows and Linux (used the server for that), and virtual machines for FreeBSD and OSX (I do own a Mac though). I managed to get one shell script working on all Posix platforms. Here's my build script: http://dump.thecybershadow.net/449edd68e2ad8fe835236de1f3244688/out.sh
Re: DDT 0.11.0 released
On 17/03/2015 23:45, Manu via Digitalmars-d-announce wrote: I also couldn't launch GDB and debug the example 'hello world' app under Windows. Are there more steps to make this work? If you're using DMD, that simply doesn't work at all. GDB doesn't understand any of the debug formats DMD outputs (COFF/MSVC or OMF), and it likely never will. GDC for Windows is not maintained. As LDC for Windows, I haven't tried it recently. Last time I tried it, debugging support wasn't working ( http://forum.dlang.org/post/qsttkqzbtnhyrogek...@forum.dlang.org ). However may be that has changed recently? I dunno about LDC itself, but I've tried the Rust compiler for Windows, and although a bit buggy, basic debugging support was working: https://raw.githubusercontent.com/RustDT/RustDT/master/documentation/screenshots/sample_debug.png So the same should be possible for LDC as well! Note: I try to collate this information in http://wiki.dlang.org/Debuggers , although perhaps "Debugging support" should listed by platform, instead of "by compiler". If you absolutely must use DMD/MSVC toolchains, well there might be some hope int the future, since work is being done on LLDB such as to be able to debug MSVC executables: http://blog.llvm.org/2015/01/lldb-is-coming-to-windows.html (LLDB has an interface emulating GDB, and as such should integrate with Eclipse and other GDB UI frontends) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 18/03/2015 00:12, Trent Forkert wrote: Unless something has changed recently, it shouldn't require dub. Last time I checked, my CMake work[1] could still generate projects for Eclipse from a D codebase, using Makefiles or Ninja. Not that that helps if you are creating a project from an Eclipse Wizard, which I haven't done in a long time. [1] https://github.com/trentforkert/cmake What kind of Eclipse projects does it generate? If it generates CDT projects, it's not really much help as CDT doesn't understand D (duh), and DDT doesn't work with CDT projects (also duh). -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 17/03/2015 23:45, Manu via Digitalmars-d-announce wrote: I just checked out DDT, and I noticed it seems to use DUB... >_< Why this marriage? I was really hoping it would be a lot more like CDT (ie, raw and flexible). In the project configuration I just see the one "DUB Options" box. The comprehensive suite of build options CDT presents would be much nicer. It makes no sense for DDT to use anything else than DUB. At a minimum, DDT needs a way to describe projects: the source files that are part of the project, and which other projects are dependencies of said project. Other aspects of a projects that are good to be able to describe are: which build configurations the project supports, which executables are produced (if any), etc.. Now the reason DUB is used is that it's a bad paradigm for this description mechanism to be Eclipse/DDT specific. It's unequivocally much better to be Eclipse-independent, such that other tools (not just other IDEs, but even other command-line analysis tools) can understand D projects/bundles/packages just as well as DDT. It also saved me a lot of work. If I had to develop my own format to describe all these aspects, it would not be as good as DUB's, guaranteed! I reckon this is true for any other D IDE out there. DUB is insufficient for any of my projects, and sadly, that makes DDT insufficient for my projects too:( The problem with DUB is it's self-contained. My projects involve cross-language interaction, and the build environments can be complex. DUB can't express this. Why is it insufficient? You don't have to use DUB to the exclusion of everything else. Isn't the use of the preGenerateCommands (http://code.dlang.org/package-format#build-settings) enough to call these other build systems you use? The only problem so far is that DDT doesn't support mutiple build configurations, but that's a DDT limitation, not a DUB one. You can also disable the DUB builder in DDT, as albatroz mentioned, however that isn't ideal since you won't get the compiler build errors reported back to Eclipse (DDT only has parsing errors built-in, other errors come externally, from the compiler.). There should be a way to integrate DUB with your build environment. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On Wednesday, 18 March 2015 at 21:12:11 UTC, Bruno Medeiros wrote: What kind of Eclipse projects does it generate? CDT. Anything else would prevent it from supporting multi-language projects, and thus turn it into yet another crappy monolingual NIHS tool, and thus useless for me (and Manu). If it generates CDT projects, it's not really much help as CDT doesn't understand D (duh), Nor does it need to. The project builds with either Make or Ninja, and Eclipse doesn't even care that it is building D code, and will build successfully even if you don't have DDT installed. and DDT doesn't work with CDT projects (also duh). Not sure what you mean by that. Installing DDT allows Eclipse to see *.d files (in any project, DDT, CDT or otherwise) as D files that will be opened in Eclipse's editor with syntax highlighting, completion, etc. Without DDT, Eclipse opens D files in an external editor. I just double checked, this all still works as I was expecting it to.
Re: DDT 0.11.0 released
On Wed, Mar 18, 2015 at 21:12:07 +, Bruno Medeiros via Digitalmars-d-announce wrote: > What kind of Eclipse projects does it generate? If it generates CDT > projects, it's not really much help as CDT doesn't understand D (duh), > and DDT doesn't work with CDT projects (also duh). It should add DDT support[1] for D projects. --Ben [1]https://github.com/trentforkert/cmake/blob/d_support3/Source/cmExtraEclipseCDT4Generator.cxx#L70-L73
Re: DDT 0.11.0 released
On Wednesday, 18 March 2015 at 21:49:17 UTC, Bruno Medeiros wrote: Why is it insufficient? You don't have to use DUB to the exclusion of everything else. Isn't the use of the preGenerateCommands (http://code.dlang.org/package-format#build-settings) enough to call these other build systems you use? You're joking, right? The only sensible way to use multiple languages in the same project is to use the same build system for them. Anything else is way too fragile and hackish. Arbitrary, contrived example (though not entirely unrealistic): * a C(++) executable needs a static D library * Said D library in turn uses a C(++) library * All three of these are built as components of the same project So now I need a weird tangled mess of build systems calling each other back and forth. Dub really doesn't pull its weight here.
Re: DDT 0.11.0 released
On Wed, Mar 18, 2015 at 22:32:05 +, Trent Forkert via Digitalmars-d-announce wrote: > The only sensible way to use multiple languages in the same > project is to use the same build system for them. Anything else > is way too fragile and hackish. > > Arbitrary, contrived example (though not entirely unrealistic): > * a C(++) executable needs a static D library > * Said D library in turn uses a C(++) library > * All three of these are built as components of the same project > > So now I need a weird tangled mess of build systems calling each > other back and forth. Dub really doesn't pull its weight here. FWIW, no language-specific build system I've ever come across does anything better than "meh" (and that's just one; the rest are basically "nope, can't do it") for support outside of their language or compiling C code against the core runtime/libraries. Then toss in cross-compiling of the C bits and all of them just fall apart. You really need something like Make, Ninja, or another generic build tool at the bottom to do things properly with how different dependencies can be constructed in a complex codebase; you can't really bake all of the knowledge required for the general cases in every language's tools. --Ben
