Re: DDT 0.11.0 released
On 20/03/2015 04:12, Manu via Digitalmars-d-announce wrote: 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. Fair enough on that last 'duh', it could have been that DDT integrated with CDT. VisualD and Mono-D interact extensively with the existing C/C++ toolsets present on those platforms. Do they now? I'm inclined to try them out again because I'm a bit skeptical of that comment, as least in how it applies to this discussion. For example, does Mono-D allow to seamlessly create a crossplatform solution with a D project interacting with a C project (and/or the opposite). And what exactly seamlessly means here, what is offered in Mono-D that couldn't be done in DDT? -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 19/03/2015 15:55, Trent Forkert wrote:
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
Err.., but it is. XML is just syntax, you still have the semantics of
what that data means to be defined. Just as learning XML doesn't mean
you know how to properly read/write HTML5! (Maybe there is a better term
than file format, but regardless I think my comment was clear.
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.
At the time of this message of yours, you didn't offer any concrete,
*technical* reasons of why dub shouldn't be used. Saying one doesn't
*want* to use dub is not a valid reason at all. Saying you can't,
without saying why, is no valid reason either.
It would be silly to use anything else.
VisualD has done pretty well for itself.
And is that a full-featured integration, or does it have significant
limitations? You see, before DUB was, DDT did have it's own `.dproject`
of sorts ('.buildpath' for those who remember), and it's own basic
builder. But that integration was very basic and had severe limitations.
What I'm wondering is how good the VisualD on is then. Unfortunately I
can't easily check it out myself because if the point here is to check
C/C++ I'd probably have to install the commercial version of Visual
Studio to try it out.
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 20/03/2015 05:30, Manu via Digitalmars-d-announce wrote: 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? There's no plans ATM to integrate with CDT itself. (I don't even know what integration with java tools would mean here) Even for CDT, I don't see what much would there be to integrate, other than the build system. It would also be really nice to have a UI with tick boxes and select boxes for all the relevant build settings like CDT. Yeah, true. Even if using DUB, it would be nice to have UI to control the settings in dub.json, but that's a fair amount of work for little gain, so down in the priority list. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On Mon, Mar 23, 2015 at 12:51:36 +, Bruno Medeiros via
Digitalmars-d-announce wrote:
At the time of this message of yours, you didn't offer any concrete,
*technical* reasons of why dub shouldn't be used. Saying one doesn't
*want* to use dub is not a valid reason at all. Saying you can't,
without saying why, is no valid reason either.
Can dub build multiple libraries in the same project? Different flags to
different source files? Running a Python script to generate D code?
And is that a full-featured integration, or does it have significant
limitations? You see, before DUB was, DDT did have it's own `.dproject`
of sorts ('.buildpath' for those who remember), and it's own basic
builder. But that integration was very basic and had severe limitations.
With CMake, you don't need to do the build steps in DDT; Eclipse already
knows how to run an external build tool just fine.
What I'm wondering is how good the VisualD on is then. Unfortunately I
can't easily check it out myself because if the point here is to check
C/C++ I'd probably have to install the commercial version of Visual
Studio to try it out.
VS2013 Community Edition should work.
--Ben
Re: DDT 0.11.0 released
On 20/03/2015 18:07, Trent Forkert wrote: And I don't understand why it is not acceptable. * Because it is not guaranteed to be there. For instance, I don't have dub on my system That's the lamest reason ever. Why is that an issue? Just install it if it is not installed. To me, that's akin to saying DDT shouldn't have a requirement of the Java VM! * Because anybody not using dub should not be required to use dub. This is dlang, not dublang * Because I just want to tell Eclipse about the project, there is no need to involve dub * Because the user said so These are basically all the same reason: me no want to use dub!. Well, you're free not to use DDT either! Seriously, I don't understand the *gripe* here: DUB offers a service, a functionality, that is not offered elsewhere (for D at least): a package management system, for source packages. And this is an important functionality for language ecosystems, because it is so damn useful!! That's why nearly all modern language have a source-package manager (Rust - Cargo, Ruby - rpm, Go - `go get/install`, Java - Maven/OSGi), all of them integrated with a build tool. I hope your experience/mindset has not been too tainted with archaic C/C++ paradigms that you fail to see this. D actually lags behind these languages in that DUB is not an official part of the language/toolchain. Although from what I recall there are plans to make DUB included as part of the DMD installation, so that would change. * Because it is at odds with C/C++ integration, which is an H1 priority This is the only reason with some credence. However, *not using dub* doesn't makes DDT automatically integrate with C/C++, nor doesn't it even necessarily bring it any closer to that. A fair amount of work would still need to be done to properly support this scenario, I suspect. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: DlangUI
On Tuesday, 20 May 2014 at 18:13:36 UTC, Vadim Lopatin wrote: Hello! I would like to announce my project, DlangUI library - cross-platform GUI for D. https://github.com/buggins/dlangui License: Boost License 1.0 Native library written in D (not a wrapper to other GUI library) - easy to extend. As a backend, uses SDL2 on any platform, Win32 API on Windows, XCB on Linux. Other backends can be added easy. .. Best regards, Vadim coolreader@gmail.com Project Update: == * Mac OSX OpenGL support fixed * High DPI (Retina) displays interface scaling is implemented * Separate resources for high DPI resolutions * Font sizes in themes can be specified in points and % of parent size, in addition to pixels * Dark theme is implemented * Settings dialogs support widgets * Multiline TextWidget * A lot of bugfixes
Re: DDT 0.11.0 released
On Mon, Mar 23, 2015 at 14:04:30 +, Dicebot via Digitalmars-d-announce wrote: If you mean separate compilation with different flags per module and linking into same binary - it is pretty much illegal in D and can only be done at own risk. I don't know if it is mentioned anyway on dlang.org but that is inevitable side-effect of how symbol emitting works. Makes sense for -fversion and the like (it would be nice if libraries exported the list of version symbols they had since it is basically ABI...), but not necessarily for things like SSE support where you want to do runtime detection and run the fastest version based on the running processor. You might need to compile foo.bar.sse3 and foo.bar.sse4 with different compiler flags. --Ben
Re: DDT 0.11.0 released
On 23/03/2015 13:39, Ben Boeckel via Digitalmars-d-announce wrote:
On Mon, Mar 23, 2015 at 12:51:36 +, Bruno Medeiros via
Digitalmars-d-announce wrote:
At the time of this message of yours, you didn't offer any concrete,
*technical* reasons of why dub shouldn't be used. Saying one doesn't
*want* to use dub is not a valid reason at all. Saying you can't,
without saying why, is no valid reason either.
Can dub build multiple libraries in the same project?
Yes - use DUB sub-packages.
Different flags to different source files?
What dicebot said.
That looks like an invalid, abstraction-breaking thing to do
Running a Python script to generate D code?
Yes, in DUB you can run arbitrary external commands before and after the
D sources compilation.
And is that a full-featured integration, or does it have significant
limitations? You see, before DUB was, DDT did have it's own `.dproject`
of sorts ('.buildpath' for those who remember), and it's own basic
builder. But that integration was very basic and had severe limitations.
With CMake, you don't need to do the build steps in DDT; Eclipse already
knows how to run an external build tool just fine.
What I'm wondering is how good the VisualD on is then. Unfortunately I
can't easily check it out myself because if the point here is to check
C/C++ I'd probably have to install the commercial version of Visual
Studio to try it out.
VS2013 Community Edition should work.
--Ben
I thought about that - VS2013 Community Edition -, but it looks huge and
I don't want to install a bunch of library and stuff on my computer just
to try VisualD out. I'd do it in a virtual machine though, as its
worthwhile to check it out. But it will just have to wait until I get
around to it, I don't have a spare Windows VM or installation at the moment.
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
Re: DDT 0.11.0 released
On 20/03/2015 05:04, Manu via Digitalmars-d-announce wrote: 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. We might have different notions of what as good as DUB's means then. Let's look at these two use cases: * Do those IDEs allow a project specifying a dependency on an D library, without having to download the library, or to configure the build settings for the library? And does doing so still make it possible to integrate with C/C++ projects? * Can you have a cross-plaftorm workspace/solution, and when building the D part of it, the IDE parses the error messages of the D compiler and reports then to the UI in the editor? 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. Yes, it would be nice if DDT would automatically integrate with CDT, and handle this use case seamlessly (regardless of using DUB internally or not). But this would be complex work, for little gain. Let me go into detail. First of all, CDT works, and I don't know how: yeah, but CDT only had to concern himself with C/C++, no cross-language stuff. Like you said, DDT and DUB also works well if you stick to the D ecosystem only. If you put a cross-language requirement on DDT, you're actually asking more of DDT than CDT had to worry (which means more work, more complexity). CDT and VisualStudio are IDEs with big companies backing them, they both had multiple developers working on them, full-time, for many, many years now. DDT only has had me working on it, on a volunteer basis (although some of the work I do there, and in Goclipse and RustDT, is related to some commercial work I do). Still, it's just me ATM, so there is an order of magnitude of difference of manpower available. You can't expect the same level of completeness. Only the most critical/important features can be worked on (or simple to implement ones). Also, there is limited gain. Sure, C/C++ and D are related, but A) Not everyone in D world is that concerned with that scenario, C/C++ integration. B) More importantly, adding DDT integration with CDT, would only benefit users of DDTCDT combined, which is a fraction of 'C++ D' users. What about users (and you might be one) that at the end of day don't use DDT/CDT because you can't debug
Re: Release Candidate D 2.067.0-rc1
On Friday, 20 March 2015 at 15:19:03 UTC, Martin Nowak wrote: On 03/19/2015 08:02 AM, Rainer Schuetze wrote: 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 .. It's seriously too late, unless someone else steps up and does it. I'd need to change the build script to clean and build another Windows target, and my time is bound to regression fixing. Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call.
Re: DDT 0.11.0 released
On Monday, 23 March 2015 at 13:40:04 UTC, Ben Boeckel wrote: Different flags to different source files? If you mean separate compilation with different flags per module and linking into same binary - it is pretty much illegal in D and can only be done at own risk. I don't know if it is mentioned anyway on dlang.org but that is inevitable side-effect of how symbol emitting works.
Re: DDT 0.11.0 released
On 19/03/2015 16:02, Ben Boeckel via Digitalmars-d-announce wrote: 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). I think the issue of speed and parallellization is an orthogonal one: The build components should be structured in properly defined, self-contained, versioned libraries/bundles(*) - that can be built, and auto-tested on their own (obviously using the dependencies they require too). That should be the primary (top level) build unit of a build system. But, the way you build each bundle/component, is still up to the build system. You can build it on file-by-file sequentially, or parallelized, etc. I'm not familiar with CMake, so I don't know if it has any concept similar to this, but I suspect not. *: AKA packages in DUB and Ruby, crates in Rust. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Release Candidate D 2.067.0-rc1
On Mon, Mar 23, 2015 at 13:49:53 +, Szymon Gatner via Digitalmars-d-announce wrote: Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. At least you get that far; Android doesn't even get there (though those patches to even let people get toolchains up and running are only around a year old). --Ben
Re: DDT 0.11.0 released
On Mon, Mar 23, 2015 at 14:25:22 +, Bruno Medeiros via Digitalmars-d-announce wrote: Yes - use DUB sub-packages. Ah, had missed this. Different flags to different source files? What dicebot said. That looks like an invalid, abstraction-breaking thing to do Not all flags are -fversion or -I flags. Running a Python script to generate D code? Yes, in DUB you can run arbitrary external commands before and after the D sources compilation. But not in between? Basically, can you have a tool written in D built with the project and then used to generate code in the same project? --Ben
Re: serve - A simple HTTP server for static files
On 03/22/2015 08:56 PM, Walter Bright wrote: If you could write a brief article about it, that would be great! I think there's a lot of potential for D in that space, and having such articles will help promulgate the idea. An article would exceed the amount of code I wrote, but I did read up how to serve static files really fast, that might make for an interesting article.
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 14:19:34 UTC, Ben Boeckel wrote: On Mon, Mar 23, 2015 at 13:49:53 +, Szymon Gatner via Digitalmars-d-announce wrote: Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. At least you get that far; Android doesn't even get there (though those patches to even let people get toolchains up and running are only around a year old). --Ben i really try not to be whiny about it but it is sooo frustrating. d advertises itself as easy to integrate with c/c++ and maybe in theory it is but in practice it is not true at all. simplest example from Adam's book I followed crashed miserable so I can only assume that -nobody- is mixing c++ with d on Win. I need it working on win so we can even start to think about using D for our projects but indeed iOS and Android is very next
Re: Release Candidate D 2.067.0-rc1
On 03/23/2015 02:49 PM, Szymon Gatner wrote: Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. As a matter of fact we only have few Windows developers, so unless someone with interest in this platform steps up it will hardly improve. Daniel Murphy did a lot of D/C++ integration to get ddmd to work, and apparently, that also works on Windows, so you might ask him for details. https://auto-tester.puremagic.com/?projectid=10
Re: DDT 0.11.0 released
On Monday, 23 March 2015 at 15:30:43 UTC, Ben Boeckel wrote: On Mon, Mar 23, 2015 at 14:04:30 +, Dicebot via Digitalmars-d-announce wrote: If you mean separate compilation with different flags per module and linking into same binary - it is pretty much illegal in D and can only be done at own risk. I don't know if it is mentioned anyway on dlang.org but that is inevitable side-effect of how symbol emitting works. Makes sense for -fversion and the like (it would be nice if libraries exported the list of version symbols they had since it is basically ABI...), but not necessarily for things like SSE support where you want to do runtime detection and run the fastest version based on the running processor. You might need to compile foo.bar.sse3 and foo.bar.sse4 with different compiler flags. I'd suggest to build such modules as separate static libraries (which is possible within dub). Risk remains but it at least becomes obvious for other developers that this needs care. Also parallel build of several static libraries should be generally faster than parallel builds of all modules 1-by-1 (overhead of single file compilation is huge because of redundant import analysis) Also don't forget that there are plenty of implicit versions that get added from compiler flags (like D_NoBoundsChecks or D_PIC).
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 13:49:55 UTC, Szymon Gatner wrote: On Friday, 20 March 2015 at 15:19:03 UTC, Martin Nowak wrote: On 03/19/2015 08:02 AM, Rainer Schuetze wrote: 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 .. It's seriously too late, unless someone else steps up and does it. I'd need to change the build script to clean and build another Windows target, and my time is bound to regression fixing. Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. bug report?
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 15:36:42 UTC, Martin Nowak wrote: On 03/23/2015 02:49 PM, Szymon Gatner wrote: Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. As a matter of fact we only have few Windows developers, so unless someone with interest in this platform steps up it will hardly improve. Daniel Murphy did a lot of D/C++ integration to get ddmd to work, and apparently, that also works on Windows, so you might ask him for details. https://auto-tester.puremagic.com/?projectid=10 sure I could bug individuals to make things work for me, then discover another problem rinse and repeat. thing is i dont want things to somehow work (possibly only until next release that will breake it) I want to know that this is something that is cared about and can be considered mature (and i am looking for the weakest definition of mature possible)
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 16:01:51 UTC, John Colvin wrote: On Monday, 23 March 2015 at 13:49:55 UTC, Szymon Gatner wrote: On Friday, 20 March 2015 at 15:19:03 UTC, Martin Nowak wrote: On 03/19/2015 08:02 AM, Rainer Schuetze wrote: 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 .. It's seriously too late, unless someone else steps up and does it. I'd need to change the build script to clean and build another Windows target, and my time is bound to regression fixing. Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. bug report? i am typing from my phone so hard to find but i did post it on forums some time ago
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 16:05:55 UTC, Szymon Gatner wrote: i am typing from my phone so hard to find but i did post it on forums some time ago Posting about something on the forums won't get it fixed, make a bug report if you're encountering a bug.
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 16:05:55 UTC, Szymon Gatner wrote: On Monday, 23 March 2015 at 16:01:51 UTC, John Colvin wrote: On Monday, 23 March 2015 at 13:49:55 UTC, Szymon Gatner wrote: On Friday, 20 March 2015 at 15:19:03 UTC, Martin Nowak wrote: On 03/19/2015 08:02 AM, Rainer Schuetze wrote: 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 .. It's seriously too late, unless someone else steps up and does it. I'd need to change the build script to clean and build another Windows target, and my time is bound to regression fixing. Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. bug report? i am typing from my phone so hard to find but i did post it on forums some time ago here: http://forum.dlang.org/thread/hsglkscatlniiuacp...@forum.dlang.org#post-mailman.397.1409844359.5783.digitalmars-d-learn:40puremagic.com
DConf 2015 Schedule published
Dconf 2015's programme is on! http://dconf.org/2015/index.html I would like to thank everyone who submitted a proposal. We've had very strong proposals this year and a 50% acceptance rate, which made it very difficult to only choose half. Submitters are encouraged to join the conference; we'll have two panels and ample unstructured time during the evenings to keep discussions going. Last but not least, I encourage everyone in the community to register. The strength of any conference is ultimately decided by its attendees. We're operating at a loss to keep registration costs low, and chose a location that is accessible and affordable. Take the schedule to your employer or academic advisor and ask them if you can attend! Andrei
Re: DDT 0.11.0 released
On 2015-03-23 13:54, Bruno Medeiros wrote: There's no plans ATM to integrate with CDT itself. (I don't even know what integration with java tools would mean here) Even for CDT, I don't see what much would there be to integrate, other than the build system. I would guess he means using C(++) files and D files in the same project and the build system would just work. -- /Jacob Carlborg
Re: Release Candidate D 2.067.0-rc1
On Monday, 23 March 2015 at 16:11:12 UTC, Kapps wrote: On Monday, 23 March 2015 at 16:05:55 UTC, Szymon Gatner wrote: i am typing from my phone so hard to find but i did post it on forums some time ago Posting about something on the forums won't get it fixed, make a bug report if you're encountering a bug. i posted it on forums because i wasnt sure if it was indeed a bug or just me. also it is hard to provide minimal app when mixing code and under msvc as potentially full project is needed. i do get your point tho
Re: Release Candidate D 2.067.0-rc1
Szymon Gatner wrote in message news:oofoormyfxkefokvk...@forum.dlang.org... i really try not to be whiny about it but it is sooo frustrating. d advertises itself as easy to integrate with c/c++ and maybe in theory it is but in practice it is not true at all. simplest example from Adam's book I followed crashed miserable so I can only assume that -nobody- is mixing c++ with d on Win. DDMD is mixing D and C++ on all the autotester platforms. It's not that simple, but it should be possible.
Re: DDT 0.11.0 released
On Mon, Mar 23, 2015 at 21:14:31 +0100, Jacob Carlborg via Digitalmars-d-announce wrote: On 2015-03-23 13:54, Bruno Medeiros wrote: There's no plans ATM to integrate with CDT itself. (I don't even know what integration with java tools would mean here) Even for CDT, I don't see what much would there be to integrate, other than the build system. I would guess he means using C(++) files and D files in the same project and the build system would just work. From what I understand[1] of Eclipse (which I admit isn't much from a user's PoV), it supports natures to be loaded which provide functionality. Now I have no idea how much work this is, but it would be nice to have a nature for D support (syntax highlighting, completion, etc.). If it includes dub, great, but it might be worth it to have a separate nature for that. CMake (and other theoretical tools) would then just add the D support nature to handle the D files and use the existing build support. Projects created through DDT itself could add the dub nature by default (FWIW, I don't think CDT generates CMake-based projects out of the box either). Basically, make DDT suitable for using it with other projects which don't use dub because it doesn't suit the upstream project whether it be because the project is more than some D code, YAML is preferred to JSON or whatever. Take my gunroar[2] repo for example. It's mainly D code, but there is some C and Java in the src/android directory. If one were working in Eclipse with it, it would be nice to support using CDT features for the C code, the native Java support for the Java code, DDT for the D code, and the build button to put it all together. --Ben [1]This is based on my experience where enabling the Android bits in an Eclipse project generated by CMake is to allow users to add natures to the generated .project file using the ECLIPSE_EXTRA_NATURES global property. [2]https://github.com/mathstuf/abagames-gunroar
Re: Release Candidate D 2.067.0-rc1
Szymon Gatner wrote in message news:tthkrzwwobmdzbufe...@forum.dlang.org... sure I could bug individuals to make things work for me, then discover another problem rinse and repeat. thing is i dont want things to somehow work (possibly only until next release that will breake it) I want to know that this is something that is cared about and can be considered mature (and i am looking for the weakest definition of mature possible) The only way bugs will get fixed is if you file them. D/C++ interop is definitely _not_ mature, but it is cared about. eg This release will fix most of the issues with using variadic functions across the D/C++ boundary.
Re: DDT 0.11.0 released
On 23 March 2015 at 22:39, Bruno Medeiros via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 20/03/2015 04:12, Manu via Digitalmars-d-announce wrote: 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. Fair enough on that last 'duh', it could have been that DDT integrated with CDT. VisualD and Mono-D interact extensively with the existing C/C++ toolsets present on those platforms. Do they now? I'm inclined to try them out again because I'm a bit skeptical of that comment, as least in how it applies to this discussion. I use those IDE's every day, and all my projects are C/C++ engine/ibs and D frontend code. In Visual-D you can even press F12 (go to definition) on an extern(C) symbol in your D code, and it will jump to the .cpp file where it's defined. For example, does Mono-D allow to seamlessly create a crossplatform solution with a D project interacting with a C project (and/or the opposite). Absolutely, if it didn't, it wouldn't be useful (to me). And what exactly seamlessly means here, what is offered in Mono-D that couldn't be done in DDT? Automatic linking between sibling libs within a solution, referencing of symbols between the languages/projects, automatic rebuild dependencies between sibling projects. I'm sure it could all be done in DDT. I'm just saying that as an end-user I would expect that level of interoperation with CDT and no less. I haven't tested those things, they may already work.
Re: DConf 2015 Schedule published
On Monday, 23 March 2015 at 16:47:30 UTC, Andrei Alexandrescu wrote: Dconf 2015's programme is on! http://dconf.org/2015/index.html We're operating at a loss to keep registration costs low, and chose a location that is accessible and affordable. Take the schedule to your employer or academic advisor and ask them if you can attend! Andrei Perhaps you might want to ask for a nominal amount to cover putting up the content on the web after the conference ? Nick
Re: DConf 2015 Schedule published
On Tuesday, March 24, 2015 02:17:22 Nick B via Digitalmars-d-announce wrote: On Monday, 23 March 2015 at 16:47:30 UTC, Andrei Alexandrescu wrote: Dconf 2015's programme is on! http://dconf.org/2015/index.html We're operating at a loss to keep registration costs low, and chose a location that is accessible and affordable. Take the schedule to your employer or academic advisor and ask them if you can attend! Andrei Perhaps you might want to ask for a nominal amount to cover putting up the content on the web after the conference ? Given how much complaining there was in the past when the videos were not made immediately available and were instead released with reddit posts at regular intervals, I hate to think how much complaining there would be if we tried to charge for someone to watch them. It's also not something I've ever heard of a conference doing. The folks who go pay, and if the talks are made available, they're posted for free. So, it would be abnormal and would look bad if we charged for them. Also, if the point of charging less for the conference was to make it more accessible, charging for the talks online would be contrary to that goal. No. It sounds like what's probably needed is to find ways to encourage sponsorship, and for that to work, we probably need to spread knowledge of D further so that its adoption grows, and charging for the online content would definitely get in the way of that. - Jonathan M Davis
