[Issue 16146] postblit is not called on struct creation with "{field:value}" syntax

https://issues.dlang.org/show_bug.cgi?id=16146 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 16146] postblit is not called on struct creation with "{field:value}" syntax

https://issues.dlang.org/show_bug.cgi?id=16146 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/5b2fb91bae4df298a82bc94565198827671664ef Fix issue 16146 - Postblit the values in struct literals.

Re: D future ...

On 12/21/2016 7:57 PM, Chris Wright wrote: You can implement write barriers as runtime calls, but omit them in @nogc code. @nogc code is code that doesn't allocate from the gc. It can still write to gc allocated objects, however, so that idea won't work. However, this would be costly --

Re: D future ...

On 12/21/2016 6:50 AM, thedeemon wrote: Have you seen this one? http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html Although I had called them write gates, write barriers are the same thing. Yes, that's the problem with implementing a generational collector in D. I once

[Issue 16423] ModuleInfo missing when linking to static lib with classes

https://issues.dlang.org/show_bug.cgi?id=16423 --- Comment #12 from Ketmar Dark --- funny, it doesn't cause any problems on GNU/Linux, only windows builds are affected. --

Re: D future ...

On 12/21/2016 3:36 AM, thedeemon wrote: Bad news: without complete redesign of the language and turning into one more C++/CLI (where you have different kinds of pointers in the language for GC and non-GC), having C performance and Go-style low-pause GC is not really possible. You have to choose

Re: Constructing a variadic template parameter with source in two files

On 12/21/2016 07:59 PM, Jon Degenhardt wrote: > construct the 'opts' parameter from > definitions stored in two or more files. The reason for doing this is to > create a customization mechanism where-by there are a number of default > capabilities built-in to the main code base, but someone can

[Issue 16423] ModuleInfo missing when linking to static lib with classes

https://issues.dlang.org/show_bug.cgi?id=16423 --- Comment #11 from Jacob Carlborg --- (In reply to Ketmar Dark from comment #10) > by the way. applying 6076 broke windows builds: phobos refused to build with > "duplicate ModuleInfo for object.d" error. Yeah, I noticed that four

Re: ModuleInfo, factories, and unittesting

On 12/21/2016 9:43 AM, Johannes Pfau wrote: You need some kind of linker support to do this to provide the start/end symbols. That's partially correct. I've done this for decades by having the compiler itself emit those symbols. There are other tricks one can do, such as putting the

[Issue 16999] takeOne popFront/Back does not pop the source range

https://issues.dlang.org/show_bug.cgi?id=16999 ajiesk...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED

[Issue 16999] New: takeOne popFront/Back does not pop the source range

https://issues.dlang.org/show_bug.cgi?id=16999 Issue ID: 16999 Summary: takeOne popFront/Back does not pop the source range Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: minor

Re: returning struct, destructor

On Wednesday, 21 December 2016 at 17:49:22 UTC, kinke wrote: Basic stuff such as this is appropriately tested. The named return value optimization is enforced by D (incl. unoptimized builds), so behavior doesn't change by this optimization. It's you who changed the behavior by removing the if.

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 23:33:50 UTC, Jonathan M Davis wrote: Definitely. It is almost always the case that building a program with dmd is much faster than building with gdc or ldc. The tradeoff is that gdc and ldc do a much better job optimizing the resultant binary. So, with dmd,

Re: D future ...

> Library Standardization: > > > Some of the proposals sounds very correct. The library needs to be > split. Every module needs its own GIT. People need to be able to add > standard modules ( after approval ). I can't agree with you there. There are a lot of dependencies

Re: DIP 1007 - keywords as identifiers with an escape symbol - feedback

On Mon, 19 Dec 2016 09:58:28 +, default0 wrote: > On Monday, 19 December 2016 at 08:30:07 UTC, Stefan Koch wrote: >> If you are prepending # you might as well prepend _ > > That doesn't solve the complications this introduces if you want to > serialize to/from members with these names, as

Re: D future ...

On Thursday, 22 December 2016 at 03:57:10 UTC, Chris Wright wrote: You can implement write barriers as runtime calls, but omit them in @nogc code. That means redefining what @nogc means. Currently it basically means "does not GC-allocate" and you want to change it to "does not mutate

Re: D future ...

On Wed, 21 Dec 2016 11:36:14 +, thedeemon wrote: > Bad news: without complete redesign of the language and turning into one > more C++/CLI (where you have different kinds of pointers in the language > for GC and non-GC), having C performance and Go-style low-pause GC is > not really possible.

Constructing a variadic template parameter with source in two files

I'd like to find a way to define programming constructs in one file and reference them in a getopt call defined in another file. getopt uses variadic template argument, so the argument list must be known at compile time. The std.getopt.getopt signature: GetoptResult getopt(T...)(ref

Re: D future ...

On Tue, 20 Dec 2016 08:20:32 +, LiNbO3 wrote: > And have the patch wait in the PR queue until the end of time, > not even acknowledged at all ? When I've put in PRs for doc improvements, they've been reviewed relatively quickly.

Re: Red Hat's issues in considering the D language

On Thursday, 22 December 2016 at 03:18:42 UTC, Jerry wrote: Not using AliasSeq if that's what you mean. I don't know if the "tupleof" for a struct would be considered the same as "T..." but basically what I was doing: foreach(ref field; myLargeStruct.tupleof) { } Yes that is a

[Issue 16423] ModuleInfo missing when linking to static lib with classes

https://issues.dlang.org/show_bug.cgi?id=16423 --- Comment #10 from Ketmar Dark --- by the way. applying 6076 broke windows builds: phobos refused to build with "duplicate ModuleInfo for object.d" error. --

Re: Red Hat's issues in considering the D language

On Thursday, 22 December 2016 at 02:34:48 UTC, Stefan Koch wrote: On Thursday, 22 December 2016 at 02:32:30 UTC, Jerry wrote: On Thursday, 22 December 2016 at 01:57:55 UTC, safety0ff wrote: On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei Alexandrescu wrote: Must be a pathological case

Re: Red Hat's issues in considering the D language

On Thursday, 22 December 2016 at 02:32:30 UTC, Jerry wrote: Yup looks like that was the cause. Removed some of the functions that did a "foreach()" over some large tuples. Down to 26 seconds with that removed. Also: https://issues.dlang.org/show_bug.cgi?id=2396

Re: Red Hat's issues in considering the D language

On Thursday, 22 December 2016 at 02:32:30 UTC, Jerry wrote: On Thursday, 22 December 2016 at 01:57:55 UTC, safety0ff wrote: On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei Alexandrescu wrote: Must be a pathological case we should fix anyway. -- Andrei Likely related bug has been open

Re: Red Hat's issues in considering the D language

On Thursday, 22 December 2016 at 01:57:55 UTC, safety0ff wrote: On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei Alexandrescu wrote: Must be a pathological case we should fix anyway. -- Andrei Likely related bug has been open 5 years minus 1 day:

[Issue 16998] New: Provide a uniq & group range methods that doesn't rely on sortedness

https://issues.dlang.org/show_bug.cgi?id=16998 Issue ID: 16998 Summary: Provide a uniq & group range methods that doesn't rely on sortedness Product: D Version: D2 Hardware: x86_64 OS: Linux

[Issue 16634] std.math exposes yl2x and yl2xp1 publicly

https://issues.dlang.org/show_bug.cgi?id=16634 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/f10dd947cdbaeb67ef02063e734f8b842ec1bb23 fix issue 16634

Re: Red Hat's issues in considering the D language

On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei Alexandrescu wrote: Must be a pathological case we should fix anyway. -- Andrei Likely related bug has been open 5 years minus 1 day: https://issues.dlang.org/show_bug.cgi?id=7157

Re: Red Hat's issues in considering the D language

On Thursday, December 22, 2016 00:59:27 hardreset via Digitalmars-d wrote: > On Wednesday, 21 December 2016 at 18:33:52 UTC, Brad Anderson > >> Moving the reference compiler to LLVM as was suggested in the > >> list. > > > > I've never been able to understand why it matters. > > Cause people think

Re: Red Hat's issues in considering the D language

On 12/21/16 7:09 PM, Jerry wrote: On Wednesday, 21 December 2016 at 21:27:57 UTC, Jack Stouffer wrote: On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote: Any other backend would be better. DMD with -O takes over an hour for my project to compile. In comparison LDC with -O3 takes less

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/21/16 6:40 PM, Timothee Cour via Digitalmars-d wrote: Andrei: ping on this? (especially regarding allowing `:`) I think "lazy" is a bit too cute. "with" is so close to what's actually needed, it would be a waste to not use it. Generally I'm weary of the use of ":" (never liked it - it

[Issue 16824] std.experimental.allocator.dispose leaks memory for arrays of more than 1 dimension

https://issues.dlang.org/show_bug.cgi?id=16824 --- Comment #1 from Andrei Alexandrescu --- OK, so what we have here at the core is this: auto ints2d = allocator.makeArray!(int[])(2); foreach(ref ints1d; ints2d) ints1d = allocator.makeArray!(int)(3); What I

[Issue 16824] std.experimental.allocator.dispose leaks memory for arrays of more than 1 dimension

https://issues.dlang.org/show_bug.cgi?id=16824 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |ASSIGNED --

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 18:33:52 UTC, Brad Anderson wrote: On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: On Tuesday, 20 December 2016

Re: Red Hat's issues in considering the D language

On Wednesday, December 21, 2016 18:49:43 Johannes Pfau via Digitalmars-d wrote: > Am Wed, 21 Dec 2016 08:18:48 -0500 > > schrieb Andrei Alexandrescu : > > On 12/20/16 6:08 PM, Andrei Alexandrescu wrote: > > > Hello, a few engineers at Red Hat are taking a look at

Re: Red Hat's issues in considering the D language

On Wednesday, December 21, 2016 15:46:19 Gerald via Digitalmars-d wrote: > Given that DMD is a non-starter for Linux packages, how feasible > is it to simply deprecate GDC and declare LDC as the > reference/production compiler for D? DMD could become the > experimental/future facing compiler used

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 21:27:57 UTC, Jack Stouffer wrote: On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote: Any other backend would be better. DMD with -O takes over an hour for my project to compile. In comparison LDC with -O3 takes less than a minute and produces a

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Mon, Dec 19, 2016 at 9:33 PM, Timothee Cour wrote: > what about using `lazy` instead of `with`: > > `with(import foo)` > => > `lazy(import foo)` > > advantages: > * avoids confusion regarding usual scoping rules of `with` ; > * conveys that the import is indeed lazy

Re: Red Hat's issues in considering the D language

On Wednesday, December 21, 2016 22:05:32 Yuxuan Shui via Digitalmars-d wrote: > On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote: > > On Wednesday, 21 December 2016 at 16:41:58 UTC, Jesse Phillips > > > > wrote: > >> On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier > >> > >>

Re: Variadic function parameters passed by move

On 12/21/2016 02:59 PM, Nordlöw wrote: On Wednesday, 21 December 2016 at 21:02:17 UTC, Ali Çehreli wrote: void f(Rs...)(Rs ranges) { import std.functional: forward; g(forward!ranges); Interesting. How does this differ from std.algorithm.mutation.move() when R.length is 1? Why do we

Re: DIP 1007 - keywords as identifiers with an escape symbol - feedback

On Monday, 19 December 2016 at 10:28:31 UTC, Basile B. wrote: On Monday, 19 December 2016 at 09:58:28 UTC, default0 wrote: That doesn't solve the complications this introduces if you want to serialize to/from members with these names, as seen in the Examples section of the DIP. Yes it does.

Re: Variadic function parameters passed by move

On Wednesday, 21 December 2016 at 23:11:02 UTC, Nordlöw wrote: Given that ref isn't involved, assuming that nothing else after the call to g references ranges, the compiler should move the values in ranges when it calls g Yes, DMD should automatically convert the last reference of a value

Re: Variadic function parameters passed by move

On Wednesday, 21 December 2016 at 21:09:41 UTC, Jonathan M Davis wrote: Given that ref isn't involved, assuming that nothing else after the call to g references ranges, the compiler should move the values in ranges when it calls g, so I would have hoped that the compiler would then allow you

Re: Variadic function parameters passed by move

On Wednesday, 21 December 2016 at 21:02:17 UTC, Ali Çehreli wrote: void f(Rs...)(Rs ranges) { import std.functional: forward; g(forward!ranges); Interesting. How does this differ from std.algorithm.mutation.move() when R.length is 1? Why do we have both `move` and `forward`, then?

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/20/2016 09:31 AM, Dmitry Olshansky wrote: On 12/13/16 11:33 PM, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei Just a thought but with all of proliferation of imports down to each declaration comes the pain that e.g. renaming a module cascades

[Issue 16967] No switch case fallthrough warnings in in/out contracts

https://issues.dlang.org/show_bug.cgi?id=16967 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/b15db024d8667919581df7b7a0ab3eca806054f1 Fix issue #16967 - Show fallthrough warnings for in/out

Re: Improvement in pure functions specification

On 12/21/2016 04:42 PM, Johan Engelen wrote: On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei Alexandrescu wrote: On 12/21/2016 03:04 PM, Johan Engelen wrote: Super contrived, but I hope you get my drift: ``` int *awesome() pure { static if (ohSoAwesome) { return new int; }

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote: On Wednesday, 21 December 2016 at 16:41:58 UTC, Jesse Phillips wrote: On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: [...] People that want to use D, want to use the latest and greatest. The reference compiler

Re: Improvement in pure functions specification

On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei Alexandrescu wrote: On 12/21/2016 03:04 PM, Johan Engelen wrote: Super contrived, but I hope you get my drift: ``` int *awesome() pure { static if (ohSoAwesome) { return new int; } else { return null; } } ``` Where does

Re: Improvement in pure functions specification

On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei Alexandrescu wrote: On 12/21/2016 03:04 PM, Johan Engelen wrote: ``` I don't know what "required to honor all calls" means, but I guess it means ``` auto a = foo(); // int* foo() pure; auto b = foo(); ``` cannot be transformed to ```

Re: Improvement in pure functions specification

On 12/21/2016 03:59 PM, John Colvin wrote: On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei Alexandrescu wrote: On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote: https://github.com/dlang/dlang.org/pull/1528 -- Andrei Dropped the void functions. On to the next scandal: A function

Re: Improvement in pure functions specification

On 12/21/2016 03:10 PM, Johan Engelen wrote: On Wednesday, 21 December 2016 at 20:04:04 UTC, Johan Engelen wrote: "Any `pure` function that is not strongly pure _may not be assumed to be_ memoizable." That version of mine is also not correct :( How about: "A strongly pure function can be

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 21:12:07 UTC, Jerry wrote: Any other backend would be better. DMD with -O takes over an hour for my project to compile. In comparison LDC with -O3 takes less than a minute and produces a faster binary. It doesn't really make sense to increase the workload

Re: Improvement in pure functions specification

On 12/21/2016 03:04 PM, Johan Engelen wrote: On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei Alexandrescu wrote: On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote: https://github.com/dlang/dlang.org/pull/1528 -- Andrei Dropped the void functions. On to the next scandal: I think you

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 16:41:58 UTC, Jesse Phillips wrote: On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: Is moving to LLVM backend or LDC something that is on the roadmap? What does it mean to

Re: Variadic function parameters passed by move

On Wednesday, December 21, 2016 20:27:47 Nordlöw via Digitalmars-d-learn wrote: > If I have a variadic function > > f(Rs...)(Rs ranges) > { > g(ranges); > } > > that calls > > g(Rs...)(Rs ranges) > { > // use ranges > } > > and all or some of the elements in `ranges` are non-copyable

Re: Variadic function parameters passed by move

On 12/21/2016 12:27 PM, Nordlöw wrote: If I have a variadic function f(Rs...)(Rs ranges) { g(ranges); } that calls g(Rs...)(Rs ranges) { // use ranges } and all or some of the elements in `ranges` are non-copyable can I somehow move them at the call of `g` inside of `f`. I've tried

Re: Improvement in pure functions specification

On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei Alexandrescu wrote: On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote: https://github.com/dlang/dlang.org/pull/1528 -- Andrei Dropped the void functions. On to the next scandal: A function that accepts only parameters without mutable

Variadic function parameters passed by move

If I have a variadic function f(Rs...)(Rs ranges) { g(ranges); } that calls g(Rs...)(Rs ranges) { // use ranges } and all or some of the elements in `ranges` are non-copyable can I somehow move them at the call of `g` inside of `f`. I've tried f(Rs...)(Rs ranges) { import

Re: Improvement in pure functions specification

On Wednesday, December 21, 2016 15:49:35 Stefan Koch via Digitalmars-d wrote: > On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei > > Alexandrescu wrote: > > On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote: > >> https://github.com/dlang/dlang.org/pull/1528 -- Andrei > > > > Dropped the

Re: Improvement in pure functions specification

On Wednesday, 21 December 2016 at 20:04:04 UTC, Johan Engelen wrote: "Any `pure` function that is not strongly pure _may not be assumed to be_ memoizable." That version of mine is also not correct :( How about: "A strongly pure function can be assumed to be memoizable. For a not strongly

[Issue 16590] Wrong di generation for ref methods

https://issues.dlang.org/show_bug.cgi?id=16590 --- Comment #8 from Satoshi --- Can someone fix this bug, please? I am not able to release any alpha version of my library until this bug will not be fixed. --

Re: Improvement in pure functions specification

On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei Alexandrescu wrote: On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote: https://github.com/dlang/dlang.org/pull/1528 -- Andrei Dropped the void functions. On to the next scandal: I think you should be very careful in making sure that

Re: ModuleInfo, factories, and unittesting

On 2016-12-21 18:43, Johannes Pfau wrote: Back to topic: I'd really love to see a generalization of RTInfo/mixin templates in D: I implemented RTInfo for modules a couple of years ago [1]. Unfortunately it was rejected because it had the same problem as RTInfo, it only works inside

Re: D future ...

On 12/21/2016 6:24 AM, Mark wrote: I do not think that this would be a bad use of the foundation's funds. That is one of the purposes of the Foundation.

Re: Selective unittesting in DUB

On 2016-12-21 19:07, Nordlöw wrote: Is there a way to specify in dub.json (or any other file) that only a subset of the sources compiled and linked to a library or app should have they're unittests enabled? You can use the "unittest" configuration in Dub to add or remove files, but I don't

Re: Red Hat's issues in considering the D language

On 12/21/2016 12:49 PM, Johannes Pfau wrote: We're at 2.068.2 now. Johannes, are you personally involved with gdc? If so please email me. Thanks! -- Andrei

Re: returning struct, destructor

On 12/21/2016 07:01 AM, Eugene Wissner wrote: > Isn't an optimization that changes the behavior bad? I had a crash in > the code where the destructor did something meaningfull, freed the > memory (the same pointer) twice. Sounds like you ended up with two objects that owned the same resource.

Re: returning struct, destructor

On Wednesday, 21 December 2016 at 18:02:54 UTC, bauss wrote: It removes an unnecessary allocation for the returning copy of the struct, as the return value is never used. Hence why it's pointless that it would be compiled anyway. That's incorrect, it doesn't have anything to do with the

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 18:33:52 UTC, Brad Anderson wrote: On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: On Tuesday, 20 December 2016

Re: Red Hat's issues in considering the D language

On Wed, Dec 21, 2016 at 06:33:52PM +, Brad Anderson via Digitalmars-d wrote: [...] > In theory the backend should be completely divorced from the frontend > and people would be editing a libd repo or something and there > wouldn't be a need for a reference compiler. Isn't our plan to

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at

Re: ModuleInfo, factories, and unittesting

On 12/20/2016 10:36 PM, Walter Bright wrote: > On 12/20/2016 11:05 AM, Dicebot wrote: >> Yes, pretty much. What ways do you have in mind? I am only aware of two: >> >> 1) ModuleInfo >> 2) https://dlang.org/spec/traits.html#getUnitTests > > > Put pointers to them in a special segment. Oh, so you

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 17:49:43 UTC, Johannes Pfau wrote: We're at 2.068.2 now. Still old, but good enough to run the latest vibe.D release. Just a quick heads up (and maybe motivation): the upcoming 0.8.0 release will drop the support for 2.068 ;-)

[Issue 16746] Please output Makefile-style depfiles for ninja and make

https://issues.dlang.org/show_bug.cgi?id=16746 Vladimir Panteleev changed: What|Removed |Added CC|

Selective unittesting in DUB

Is there a way to specify in dub.json (or any other file) that only a subset of the sources compiled and linked to a library or app should have they're unittests enabled?

[Issue 16746] Please output Makefile-style depfiles for ninja and make

https://issues.dlang.org/show_bug.cgi?id=16746 Johannes Pfau changed: What|Removed |Added CC|

Re: Red Hat's issues in considering the D language

Am Wed, 21 Dec 2016 15:46:19 + schrieb Gerald : > Given that DMD is a non-starter for Linux packages, how feasible > is it to simply deprecate GDC and declare LDC as the > reference/production compiler for D? Hey, GDC is still in active development ;-) We need some

Re: returning struct, destructor

On Wednesday, 21 December 2016 at 15:01:20 UTC, Eugene Wissner wrote: On Wednesday, 21 December 2016 at 14:15:06 UTC, John C wrote: On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner wrote: This prints 3 times "Destruct" with dmd 0.072.1. If I remove the if block, it prints

Re: D future ...

On Wednesday, 21 December 2016 at 14:50:31 UTC, thedeemon wrote: On Wednesday, 21 December 2016 at 11:54:35 UTC, Ilya Yaroshenko wrote: On Wednesday, 21 December 2016 at 11:36:14 UTC, thedeemon wrote: On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote: [...] Bad news: without

Re: Red Hat's issues in considering the D language

Am Wed, 21 Dec 2016 08:18:48 -0500 schrieb Andrei Alexandrescu : > On 12/20/16 6:08 PM, Andrei Alexandrescu wrote: > > Hello, a few engineers at Red Hat are taking a look at using the D > > language on the desktop and have reached out to us. They have > > created a

Re: returning struct, destructor

On Wednesday, 21 December 2016 at 15:01:20 UTC, Eugene Wissner wrote: On Wednesday, 21 December 2016 at 14:15:06 UTC, John C wrote: On Wednesday, 21 December 2016 at 11:45:18 UTC, Eugene Wissner wrote: This prints 3 times "Destruct" with dmd 0.072.1. If I remove the if block, it prints

Re: ModuleInfo, factories, and unittesting

Am Tue, 20 Dec 2016 12:36:53 -0800 schrieb Walter Bright : > On 12/20/2016 11:05 AM, Dicebot wrote: > > Yes, pretty much. What ways do you have in mind? I am only aware of > > two: > > > > 1) ModuleInfo > > 2) https://dlang.org/spec/traits.html#getUnitTests > > >

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 16:41:56 UTC, hardreset wrote: Moving the reference compiler to LLVM as was suggested in the list. LDC is the only compiler on Fedora/CentOS anyway!

Re: Socket missing option: SO_REUSEPORT

On Wednesday, 21 December 2016 at 13:01:53 UTC, Benjiro wrote: Just check the socket code and there is a small feature missing: enum SocketOption: int { DEBUG =SO_DEBUG,/// Record debugging information BROADCAST =SO_BROADCAST,/// Allow

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: Is moving to LLVM backend or LDC something that is on the roadmap? What does it mean to "move" to LDC? Why can't you use LDC now? People that want to use D, want

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 16:30:15 UTC, bachmeier wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop

Re: Red Hat's issues in considering the D language

On 12/21/2016 11:32 AM, hardreset wrote: On Wednesday, 21 December 2016 at 16:20:31 UTC, Jack Stouffer wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: Is moving to LLVM backend or LDC something that is on the roadmap? Nope. So whats the solution to the "DMD compiler

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 16:20:31 UTC, Jack Stouffer wrote: On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: Is moving to LLVM backend or LDC something that is on the roadmap? Nope. So whats the solution to the "DMD compiler issues" listed?

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues.

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 10:15:26 UTC, hardreset wrote: Is moving to LLVM backend or LDC something that is on the roadmap? Nope.

Re: Red Hat's issues in considering the D language

On Wednesday, 21 December 2016 at 15:46:19 UTC, Gerald wrote: Given that DMD is a non-starter for Linux packages, how feasible is it to simply deprecate GDC and declare LDC as the reference/production compiler for D? DMD could become the experimental/future facing compiler used to evolve D as

[Issue 7016] local import does not create -deps dependency

https://issues.dlang.org/show_bug.cgi?id=7016 --- Comment #21 from RazvanN --- (In reply to Vladimir Panteleev from comment #20) > (In reply to RazvanN from comment #19) > > I ran the exact example as the one in 2011 with the exact command and the > > output is: > > >

[Issue 7016] local import does not create -deps dependency

https://issues.dlang.org/show_bug.cgi?id=7016 --- Comment #20 from Vladimir Panteleev --- (In reply to RazvanN from comment #19) > I ran the exact example as the one in 2011 with the exact command and the > output is: > > (a.d) : private : object (..)

Re: Improvement in pure functions specification

On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei Alexandrescu wrote: On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote: https://github.com/dlang/dlang.org/pull/1528 -- Andrei Dropped the void functions. On to the next scandal: A function that accepts only parameters without mutable

Re: Red Hat's issues in considering the D language

On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any

Re: Improvement in pure functions specification

On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote: https://github.com/dlang/dlang.org/pull/1528 -- Andrei Dropped the void functions. On to the next scandal: A function that accepts only parameters without mutable indirections and returns a result that has mutable indirections is called a

[Issue 7016] local import does not create -deps dependency

https://issues.dlang.org/show_bug.cgi?id=7016 --- Comment #19 from RazvanN --- I ran the exact example as the one in 2011 with the exact command and the output is: (a.d) : private : object (..) (b.d) : private :

Re: Red Hat's issues in considering the D language

On 2016-12-21 15:58, Madaz Hill wrote: I'd like to add that the windows version would require another change so that DMD becomes true FOSS. Unless the 32 bit version get dropped away, the standard C library, snn.lib, is even not open-sourced (which is a worst than the backend situation) ! A.

Re: Improvement in pure functions specification

On 12/21/2016 05:08 AM, Timon Gehr wrote: On 21.12.2016 01:58, Andrei Alexandrescu wrote: On 12/20/16 7:40 PM, Timon Gehr wrote: On 20.12.2016 23:49, Andrei Alexandrescu wrote: https://github.com/dlang/dlang.org/pull/1528 -- Andrei Good, except: "$(P `pure` functions returning `void` will

  1   2   >