Re: Release Candidate D 2.067.0-rc1
On 18.03.2015 01:46, 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. The COFF32 lib is built through win64.mak. This is an excerpt from my build script to create lib32\phobos32mscoff.lib: set dm_make=c:\l\dmc\bin\make set vs=vs12 set vcdir=c:\l\%vs%\vc set cl32=%vcdir%/bin/cl.exe set ar32=%vcdir%/bin/lib.exe set MSLINK=%vcdir%\bin\link.exe set lib32coff=m:\s\d\rainers\lib32;%vcdir%\vc\lib;%sdkdir%\lib set sdkdir=c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A set LINKCMD=%MSLINK% set LIB=%LIB32COFF% set ARGS=DMD=%DMD% MAKE=%dm_make% CC=\%cl32%\ AR=\%ar32%\ VCDIR=%vcdir% SDKDIR=%sdkdir% cd druntime %dm_make% -f win64.mak MODEL=32mscoff %ARGS% target if errorlevel 1 goto xit cd .. cd phobos %dm_make% -f win64.mak MODEL=32mscoff %ARGS% LIB=..\lib32\phobos32mscoff.lib if errorlevel 1 goto xit cd ..
Re: 2nd London D Programmers Meetup - Robot Tank Battle Tournament
Just a reminder - this is happening next Tuesday - please come along if you are in London and fancy a bit of D programming fun. On Thursday, 26 February 2015 at 15:56:13 UTC, Kingsley wrote: Hi, The second London D Programmers Meetup is now officially scheduled for Tuesday 24th March. As usual it's sponsored by Skills Matter and will be at their awesome training facility. This meetup will be all about an awesome robot battle tournament. Come along and bring your laptop and be prepared to build a tank robot that can destroy the opposition in our custom made 2D battle arena. I've used the very excellent DSFML library for the graphics so it's looks nice :) If we come up with a super tank we may start challenging other D meetup groups to a robot tank battle royale extravaganza!! So watch out!!! Here are the details - spread the word: http://www.meetup.com/London-D-Programmers/events/220610394/ thanks --Kingsley
New Russian doc in wiki.dlang.org
My friend Ruslan wrote pretty big doc for D-noobs about using D. It's pretty much inspired by Ali book (thanks Ali!) but not so big. I hope that doc will help to newcomers to start programming. Any feed back are welcome! http://wiki.dlang.org/Reading_the_documentation_%28in_Russian%29 P.S. the work on dlang.ru is not stop. We done huge refactoring of engine, but now our programmer again have not free time. But I keep hand on pulse.
Re: DDT 0.11.0 released
On Wednesday, 18 March 2015 at 22:32:06 UTC, Trent Forkert wrote: 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. I call dub from makefile rules and feel pretty comfortable about such pattern (apart from being not-so-portable compared to raw dub). And building anything via IDE is just asking for trouble :) Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much.
Re: DDT 0.11.0 released
On 20 March 2015 at 01:31, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 19/03/2015 11:18, Dicebot wrote: On Wednesday, 18 March 2015 at 22:32:06 UTC, Trent Forkert wrote: 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. I call dub from makefile rules and feel pretty comfortable about such pattern (apart from being not-so-portable compared to raw dub). And building anything via IDE is just asking for trouble :) Indeed, I reckon in these more complex examples, you'd call DUB from make/cmake/whatever. DUB would be in charge of building the D library aspect/component of that whole project. I don't see why this would not be possible, or otherwise why it would be a tangled messed. Pushing variables, lib paths, include paths, etc around immediately comes to mind. It might force to think of your build components in a more structured/componentized way, instead of the paradigm of building on a file by file basis, the `make` way. (I've only used make though, not cmake, so dunno how much this comment applies to the later) In premake, D projects are emit as a single invocation of the compiler given all source files at once, and this works seamlessly with C/C++ projects which are done in the traditional file-by-file way. VisualD and Mono-D also perform D compilation in single step, while interoperating with C compilation in the traditional way.
Re: DDT 0.11.0 released
On 20 March 2015 at 00:45, Trent Forkert via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote: I call dub from makefile rules and feel pretty comfortable about such pattern (apart from being not-so-portable compared to raw dub). And building anything via IDE is just asking for trouble :) I use Vim myself, but I think people who use IDEs would like to, well, use IDEs. Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much. It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work. Precisely, I was expecting a .dproject file to appear, but it didn't. I also maintain the D (and Eclipse) support for premake (like cmake), but I can't support D in Eclipse like C/C++ as it is.
Re: DDT 0.11.0 released
On 19 March 2015 at 07:49, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: 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. I use Mono-D and VisualD extensively, and in lieu of those, I fallback to makefiles. Those certainly did make their own equivalent build systems matching the IDE's existing styles. Those IDE's integrate D nicely with the C/C++ experiences. 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? I have no idea how Eclipse operates internally... and I shouldn't have to. Isn't that the point of an IDE? All I can say is that CDT works, and I don't know how. If DDT doesn't automatically work with it out of the box, then the IDE experience is kinda pointless (to me at least). If I have to fiddle with a build system by hand, then that undermines the whole point of the IDE as far as I'm concerned. C/C++ and D are related, and they must interoperate. It's the top of the D roadmap. If I'm an IDE user, I think that's more-or-less an admission that I don't understand build environments, and I don't want to. So from that perspective, I think it would be valuable work to make sure DDT and CDT understand eachother. 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. There may very well be, but it would seem to be more work than not, and added complexity and for the cost of additional work doesn't make for a good sales pitch :) As far as I can tell, dub is good for self-contained D apps, and that's about it. Beyond that, there are much simpler solutions, and that includes IDE support.
Re: DDT 0.11.0 released
On 19 March 2015 at 07:12, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: 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). Why is that 'duh'? I would expect nothing less than for DDT and CDT to interact comprehensively. VisualD and Mono-D interact extensively with the existing C/C++ toolsets present on those platforms.
Re: New Russian doc in wiki.dlang.org
On 3/19/2015 4:41 AM, Suliman wrote: My friend Ruslan wrote pretty big doc for D-noobs about using D. It's pretty much inspired by Ali book (thanks Ali!) but not so big. I hope that doc will help to newcomers to start programming. Any feed back are welcome! http://wiki.dlang.org/Reading_the_documentation_%28in_Russian%29 P.S. the work on dlang.ru is not stop. We done huge refactoring of engine, but now our programmer again have not free time. But I keep hand on pulse. Thank you!
Re: DDT 0.11.0 released
On 20 March 2015 at 01:14, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 19/03/2015 14:45, Trent Forkert wrote: On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote: Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much. Exactly. It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work. DDT does support a .dproject ... it's called dub.json ! ;) I'm dead serious here though. Why would I invent my own file format to describe source folders and include/imports paths when dub.json does that already?? It would be silly to use anything else. If you absolutely don't want to use DUB to build things, there are ways to disable the DUB builder, as mentioned before in this thread, and this way you'll use dub.json merely to describe the import path structure of the D project. I would imagine that if you had complete control over the project description and build process, it would be much easier to integrate with other components in Eclipse? Of course, I have no idea whether that's true or not. But I will hazard a guess that using dub in this way must make it harder for you to interact with CDT/java tools than otherwise? It would also be really nice to have a UI with tick boxes and select boxes for all the relevant build settings like CDT.
Re: Terminal ANSI Colouring Library
On Monday, 16 March 2015 at 15:39:52 UTC, Kingsley wrote: Hi, As a learning project I've knocked up a tiny library to output ansi coloured text on linux/osx. Have a look here for an earlier attempt: http://forum.dlang.org/thread/mailman.41.1317934445.28623.digitalmar...@puremagic.com This would be great to have in Phobos!
updated SDC-32bit again
My sdc32-experimental has now limited support for : * foreach on forward-ranges * inference of purity * checking the returnType of main currently it CANNOT generate 32bit code anymore ...
Re: Digger 1.1
On Thursday, 19 March 2015 at 15:40:19 UTC, Robert M. Münch wrote: On 2015-03-18 12:14:01 +, Vladimir Panteleev said: 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. I just tried it and get this here: Entering 'phobos' Entering 'tools' error: Your local changes to the following files would be overwritten by checkout: test/d_do_test.d Please, commit your changes or stash them before you can switch branches. Aborting Unable to checkout '229edba461ef6f6e2254e060eb498f302e982563' in submodule path 'dmd' Fatal error: Command [git, --work-tree=D:\\develop\\d-language\\Digger\\repo, --git-dir=D:\\develop\\d-language\\Di gger\\repo\\.git, submodule, update] failed with status 1 I don't have done any changes to test/d_do_test.d so no idea what this means or where it comes from... any idea? Hmm... Does it happen with a fresh Digger install? What is your core.autocrlf set to?
Re: DDT 0.11.0 released
On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote: I call dub from makefile rules and feel pretty comfortable about such pattern (apart from being not-so-portable compared to raw dub). And building anything via IDE is just asking for trouble :) I use Vim myself, but I think people who use IDEs would like to, well, use IDEs. Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much. It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work.
Re: DDT 0.11.0 released
On 18/03/2015 22:09, Trent Forkert wrote: 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. When I said it's not really much help, I didn't mean for building: I meant for code completion and other semantic functionality. A CDT project description means nothing for DDT, and as such, code completion and other semantic functionality won't work properly (you will get code completion for the standard library, and for symbols of the .d file you opened, but any other imports/modules will not be found). -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On Thursday, 19 March 2015 at 15:14:09 UTC, Bruno Medeiros wrote: On 19/03/2015 14:45, Trent Forkert wrote: It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work. DDT does support a .dproject ... it's called dub.json ! ;) I'm dead serious here though. Why would I invent my own file format to describe source folders and include/imports paths when dub.json does that already?? 1. I don't consider an XML configuration to be your own file format 2. For the very reason that started this entire conversation. Not everybody *wants* to use dub. Not everybody *can* use dub. So it doesn't make sense for DDT to force dub. It would be silly to use anything else. VisualD has done pretty well for itself. If you absolutely don't want to use DUB to build things, there are ways to disable the DUB builder, as mentioned before in this thread, and this way you'll use dub.json merely to describe the import path structure of the D project. This still requires dub for things to work, which isn't an acceptable solution. Using XML the way CDT does also allows something else: GUI configuration. Users could then adjust build parameters via a GUI the way IDE users would expect to be able to, instead of editing a configuration file for a tool they aren't even using.
Re: DDT 0.11.0 released
On Thu, Mar 19, 2015 at 15:31:49 +, Bruno Medeiros via Digitalmars-d-announce wrote: Indeed, I reckon in these more complex examples, you'd call DUB from make/cmake/whatever. DUB would be in charge of building the D library aspect/component of that whole project. I don't see why this would not be possible, or otherwise why it would be a tangled messed. If dub needs things built earlier and then the D code is used by CMake, dependency tracking becomes very manual; it's better to have one tool know the entire build structure here. It might force to think of your build components in a more structured/componentized way, instead of the paradigm of building on a file by file basis, the `make` way. (I've only used make though, not cmake, so dunno how much this comment applies to the later) Building file-at-a-time is, for developers, on the whole faster than unity builds because you can parallelize it and only have to build what changed. CMake only really works with .d - .o rules (Java support bends this AFAIK due to restrictions in javac, but I vastly prefer -j8 over a single invokation). --Ben
Re: DDT 0.11.0 released
On 19/03/2015 14:45, Trent Forkert wrote: On Thursday, 19 March 2015 at 11:18:29 UTC, Dicebot wrote: Semantics analysis you can get by simply opening .d file in CDT project is very limited compared to opening dub project because it can't know the import paths for dependencies or pretty much anything about project structure apart from opened file. This isn't much. Exactly. It seems you are right that it *is* limited, but it shouldn't be. CMake emits include/import paths into the project structure. I had thought it emitted into .project, but evidently emits into .cproject. If DDT supported a .dproject I could also emit, I could get it to work. DDT does support a .dproject ... it's called dub.json ! ;) I'm dead serious here though. Why would I invent my own file format to describe source folders and include/imports paths when dub.json does that already?? It would be silly to use anything else. If you absolutely don't want to use DUB to build things, there are ways to disable the DUB builder, as mentioned before in this thread, and this way you'll use dub.json merely to describe the import path structure of the D project. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Digger 1.1
On 2015-03-18 12:14:01 +, Vladimir Panteleev said: 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. I just tried it and get this here: Entering 'phobos' Entering 'tools' error: Your local changes to the following files would be overwritten by checkout: test/d_do_test.d Please, commit your changes or stash them before you can switch branches. Aborting Unable to checkout '229edba461ef6f6e2254e060eb498f302e982563' in submodule path 'dmd' Fatal error: Command [git, --work-tree=D:\\develop\\d-language\\Digger\\repo, --git-dir=D:\\develop\\d-language\\Di gger\\repo\\.git, submodule, update] failed with status 1 I don't have done any changes to test/d_do_test.d so no idea what this means or where it comes from... any idea? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: DDT 0.11.0 released
On 19/03/2015 11:18, Dicebot wrote: On Wednesday, 18 March 2015 at 22:32:06 UTC, Trent Forkert wrote: 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. I call dub from makefile rules and feel pretty comfortable about such pattern (apart from being not-so-portable compared to raw dub). And building anything via IDE is just asking for trouble :) Indeed, I reckon in these more complex examples, you'd call DUB from make/cmake/whatever. DUB would be in charge of building the D library aspect/component of that whole project. I don't see why this would not be possible, or otherwise why it would be a tangled messed. It might force to think of your build components in a more structured/componentized way, instead of the paradigm of building on a file by file basis, the `make` way. (I've only used make though, not cmake, so dunno how much this comment applies to the later) -- Bruno Medeiros https://twitter.com/brunodomedeiros
