Re: D street cred: Just a thought

On 4/03/2017 7:10 PM, Patrick Schluter wrote: The compiler front-end did just that. I can not comment on the quality of the code but on the speed of compilation, wow, just wow. Building v2.067 takes 1'38" on the server at work (westmere at 2.2 GHz, gcc 6.2, dmd v2.073, single core build).

Re: Building bits of D [was Andrei's list of barriers to D adoption]

On 6/06/2016 8:40 PM, Russel Winder via Digitalmars-d wrote: Building dmd with Microsoft C++ isn't an official build. Building it with DMC++ is, works fine, and does not depend on Microsoft tools. But standard C++ should be compilable with any standards compliant C++ compiler. So if it C++

Re: C++ to D converter based on clang

On 1/06/2016 9:40 PM, Jacob Carlborg wrote: Yes I could. Like I could participate to VisualD/cpp2d or magicport2 projects. Anything that is not using a real front end is a lost cause. Haha that really depends on your goals.

Re: DMD producing huge binaries

On 20/05/2016 12:44 AM, Andrei Alexandrescu wrote: On 05/19/2016 10:43 AM, Steven Schveighoffer wrote: This may be crazy, but I solved this problem by simply moving the struct outside the function. What about a lowering that does this for you? That's also a possibility, but likely a more

Re: Battle-plan for CTFE

On 19/05/2016 3:50 AM, Stefan Koch wrote: I am currently designing an IR to feed into the CTFE Evaluator. I am aware that this could potentially make it harder to get things merged since DMD already has the glue-layer. It's always more difficult to justify merging more complexity. But if

Re: Why doesn't dlang-bot use the GitHub conventions?

On 19/05/2016 3:06 AM, Jacob Carlborg wrote: On 2016-05-18 17:05, Daniel Murphy wrote: No, because #99 is a github pull request reference. GitHub uses the same syntax to refer to issues and pull requests. If the syntax works for GitHub I don't see why it can't work for us. No point

Re: Why doesn't dlang-bot use the GitHub conventions?

On 19/05/2016 12:27 AM, Jacob Carlborg wrote: Apparently dlang-bot doesn't recognize the GitHub syntax/conventions [1] to link and close issues from pull requests. Instead one have to use "Fix issue ...". I don't see a point in inventing new conventions for this. Can we please have dlang-bot

Re: Battle-plan for CTFE

On 18/05/2016 9:01 AM, Martin Nowak wrote: Yes, this https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/dinterpret.d#L3418 is really ugly and complex, but you won't get rid of this inherent complexity. The e2ir code for AssingExp looks almost the same

Re: Always false float comparisons

On 16/05/2016 10:37 PM, Walter Bright wrote: Some counter points: 1. Go uses 256 bit soft float for constant folding. Then we should use 257 bit soft float!

Re: Battle-plan for CTFE

On 16/05/2016 9:20 PM, Martin Nowak wrote: On Monday, 16 May 2016 at 10:01:47 UTC, Kagamin wrote: Wasn't it possible to enable GC for entire compiler? There can be hybrid approach: 1) first allocate from bump heap 2) when it reaches, say, 200MB, switch to GC. Well, I wouldn't use D's GC for

Re: Battle-plan for CTFE

On 15/05/2016 11:25 PM, Martin Nowak wrote: On 05/15/2016 02:17 PM, Daniel Murphy wrote: For simple types that's true. For more complicated reference types... Variable indexes are not enough, you also need heap memory, but slices and pointers (and references) can refer to values either

Re: Battle-plan for CTFE

On 15/05/2016 9:57 PM, Martin Nowak wrote: On 05/15/2016 01:58 PM, Daniel Murphy wrote: The biggest advantage of bytecode is not the interpreter speed, it's that by lowering you can substitute VarExps etc with actual references to memory without modifying the AST. By working with something

Re: Battle-plan for CTFE

On 15/05/2016 9:57 PM, Martin Nowak wrote: On 05/15/2016 01:58 PM, Daniel Murphy wrote: The biggest advantage of bytecode is not the interpreter speed, it's that by lowering you can substitute VarExps etc with actual references to memory without modifying the AST. By working with something

Re: Battle-plan for CTFE

On 15/05/2016 8:29 PM, Martin Nowak wrote: No need for a byte-code interpreter, it mostly just adds overhead and complexity over an AST interpreter. If you want to go really fast you need some sort of JIT anyhow, but a proper interpreter will be orders of mangnitude faster than the current

Re: Why are tests restarting in Github?

On 25/04/2016 5:44 AM, ag0aep6g wrote: On 24.04.2016 21:26, tcak wrote: There are 10 test. Some of them gets completed. And then, I look at it again, tests have restarted, and less number of tests are passed at that point. 1. What is the reason of restarts? Something else has been pulled.

Re: [PRs] How to update on Github

On 19/04/2016 11:05 PM, tcak wrote: On Thursday, 21 May 2015 at 10:39:46 UTC, ZombineDev wrote: Basically you need clone your fork to your computer, add a "upstream" remote to github.com/D-Programming-Language/[repo name, eg. phobos], pull from upstream the new changes and optionally update

Re: I want this so badly, please implement

On 8/04/2016 1:59 AM, Adam D. Ruppe wrote: (I thought this would be easy but I keep hitting dmd assert failures. However, that's probably because I'm a n00b, it probably is easy if you know the e2ir style.) If you have a patch I can probably point out the error. You're right that it should

Re: How my little brother try D

On 3/04/2016 9:35 PM, cym13 wrote: To be fair I've always thought that mv is a bad name because moving really is just renaming, there are no two separate operations. That said I too would have searched for "move" first exactly because as misleading as the name can be it corresponds to what the

Re: Can we check the arguments to format() at compile time?

On 2/04/2016 8:25 AM, Yuxuan Shui wrote: Clang has this nice feature that it will warn you when you passed wrong arguments to printf: #include int main(){ long long u = 10; printf("%c", u); } clang something.c: something.c:4:15: warning: format specifies type 'int' but the argument

Re: "Squash and merge" on GitHub

On 2/04/2016 7:28 AM, Vladimir Panteleev wrote: 4. We should use the autotester's auto-merge feature anyway. Can we disable both and force everyone to use the autotester?

Re: Could we reserve void[T] for builtin set of T ?

On 1/04/2016 6:24 AM, deadalnix wrote: Pretty much as per title. I has that in the back of my mind for a while. Would that work ? Don't forget that builtin AAs have been an epic disaster, and this would require an appalling amount of effort to implement in the compiler types, ctfe, druntime,

Re: DDMD: functions defined in both C++ and D

On 8/03/2016 8:42 PM, Johan Engelen wrote: On Monday, 7 March 2016 at 22:19:46 UTC, Daniel Murphy wrote: On 8/03/2016 7:12 AM, Johan Engelen wrote: or perhaps a remnant of semi-automated C++->D conversion? That. :) Out with it, then? If it still links. Vtbl emission can be tricky.

Re: DDMD: functions defined in both C++ and D

On 8/03/2016 7:12 AM, Johan Engelen wrote: or perhaps a remnant of semi-automated C++->D conversion? That.

Re: State of the Compiler

On 1/03/2016 7:18 AM, Jack Stouffer wrote: On Monday, 29 February 2016 at 00:10:33 UTC, Walter Bright wrote: 5. convert back end to D. What's the status of this? When the ddmd switch happened, Daniel Murphy was saying that a similar transition in the back end would take about six to eight

Re: Running DMD tests on Windows / build requirements

On 22/02/2016 5:42 AM, Vladimir Panteleev wrote: On Saturday, 20 February 2016 at 13:41:36 UTC, Martin Krejcirik wrote: Dne 20. 2. 2016 v 13:40 kinke napsal(a): You may want to have a look at http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC#Running_the_dmd-testsuite_tests

Re: Head Const

On 16/02/2016 8:29 PM, Ola Fosheim Grøstad wrote: I agree with the principle, but not as a library function, because: 1. you want virtual functions to work out ok virtual functions don't even need mangling. But even if they did it would work just fine anyway. 2. making D more reliant

Re: Head Const

On 16/02/2016 12:04 PM, Walter Bright wrote: It's currently difficult to interface with C++, and always will be, but smoothing out what we can can be a big opportunity for D. I'm starting to think we should give up on implementing C++ support in the language and move it to the library. eg

Re: Head Const

On 16/02/2016 9:48 AM, Walter Bright wrote: rears its head again :-) Head Const is what C++ has for const, i.e. it is not transitive, applies to one level only. D has transitive const. What head const will do for us: 1. make it easy to interface to C++ code that uses const, as currently it is

Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library

On 9/02/2016 12:23 AM, Atila Neves wrote: What's new: Built-in unittest blocks can now have a name with just a string UDA: @("test that does stuff") unittest {... } I feel obliged to point out that this is going to be a

Re: Wannabe contributor frustrations

On 12/02/2016 4:10 AM, Jonathan M Davis wrote: IIRC, it uses 2.067 and will continue to do so until GDC and LDC have switched to using the D version of the frontend instead of the older, C++ version. Most likely we will stick with 2.067 until GDC and LDC both have 2.068 releases. There are

Re: Wannabe contributor frustrations

On 11/02/2016 3:37 PM, Jonathan M Davis wrote: It's also a pain to edit. It's been suggested several times that we change the build system (e.g. to use https://github.com/atilaneves/reggae), but IIRC, Walter and Andrei have generally been opposed to the idea of changing it. It's one of those

Re: Type safety could prevent nuclear war

On 5/02/2016 11:03 AM, tsbockman wrote: The compiler cannot (in the general case) verify that `extern(C)` declarations are *correct*. What it could do, though, is verify that they are *consistent*. If the same `extern(C)` symbol is declared multiple places in the D source code for a program,

Re: Deprecation policy

On 4/02/2016 6:25 AM, Jonathan M Davis wrote: With regards to language features, we really don't have a policy. Some stuff has been in the state of "we're definitely going to deprecate it" for ages (e.g. delete and using scope on local variables) but never actually gets deprecated, and other

Re: Type safety could prevent nuclear war

On 5/02/2016 10:07 PM, tsbockman wrote: I think it makes sense (when actually linking to C) to allow stuff like druntime's creative use of overloads. The signatures of the two bsd_signal() overloads are compatible (from C's perspective), so why not? However, multiple `extern(C)` overloads that

Re: Vision for the first semester of 2016

On 1/02/2016 8:46 AM, Iain Buclaw via Digitalmars-d-announce wrote: I know, I've been hitting bug after bug in 2.067, and the answer has always been to backport from 2.068. I already have backported druntime's object.d from 2.068 because 2.067's object module has drifted so far out of sync

Re: extern(C++) multiple inheritence

On 26/01/2016 5:29 PM, Manu via Digitalmars-d wrote: I tried to build DMD myself, doesn't build with vs2015: https://issues.dlang.org/show_bug.cgi?id=15611 *sigh* .. everything's always so hard! It's exhausting. Get with the times, vs2015 is so last year.

Re: Last revision of phobos and druntime that actually compile with cdmd

On 25/01/2016 2:55 AM, Benjamin Thaut wrote: I tried using a commit which was the same date as the cdmd -> ddmd switch but that didn't work. That's the only way I know to do it, it should work.

Re: extern(C++, ns)

On 21/01/2016 9:15 AM, Walter Bright wrote: On 1/20/2016 8:38 AM, Marc Schütz wrote: IMO his description was already quite clear, but here you are: What's missing is why this is a *serious* problem. All you've got to do is add a qualifier. The *serious* problem is that the added scope does

Re: extern(C++) multiple inheritence

On 19/01/2016 4:10 PM, Manu via Digitalmars-d wrote: I'm repeating this here from the depths of my prior whinge thread, since this is kind of a new topic. D's multiple inheritance solution is single-inheritance + interfaces. Rightly so, it's a great solution, and this matches what all the C++

Re: extern(C++, ns)

On 18/01/2016 6:47 AM, Walter Bright wrote: > On 1/17/2016 3:55 AM, Daniel Murphy wrote: >> So now we have two public symbols called 'mylib', and because they >> conflict they >> can't be used to disambiguate eg 'someotherlib.funca' with >> 'library.a.funca'. >

Re: extern(C++, ns)

On 18/01/2016 12:19 PM, Chris Wright wrote: On Sun, 17 Jan 2016 22:55:23 +1100, Daniel Murphy wrote: So now we have two public symbols called 'mylib', and because they conflict they can't be used to disambiguate eg 'someotherlib.funca' with 'library.a.funca'. Users want to disambiguate

Re: extern(C++, ns)

On 19/01/2016 7:54 PM, Walter Bright wrote: On 1/19/2016 12:42 AM, Daniel Murphy wrote: So Why make extern(C++, namespace) introduce a new symbol? Why not just let it change ONLY mangling and use modules to organize symbols and resolve conflicts? 1. Because a namespace is a scope

Re: extern(C++) multiple inheritence

On 19/01/2016 8:04 PM, Walter Bright wrote: On 1/19/2016 12:34 AM, Daniel Murphy wrote: Yeah, it never has. No attempt has ever been made to make it work. Actually, as I recall it was made to match what DMC++ generates for Win32. Wasn't that from before we had extern(C++) classes? I did

Re: extern(C++, ns)

On 17/01/2016 6:09 AM, Walter Bright wrote: On 1/16/2016 6:26 AM, Daniel Murphy wrote: Nobody wants conflicting symbols in a module, and nobody wants to cram all of their C++ namespace bindings inside a single D source file to avoid getting namespace symbol conflicts. D's namespace system

Re: extern(C++, ns)

On 13/01/2016 5:51 PM, Walter Bright wrote: If you like: extern (C++) { int a; extern (C++,ns) { int a; } } The whole point of scoped names is to be able to do this. The whole point is meant to be linking to C++ symbols inside namespaces.

Re: So... let's document dmd

On 17/01/2016 2:29 AM, Joakim wrote: While this would all be nice in principle, the reality is that dmd is mostly worked on by two people these days (https://github.com/D-Programming-Language/dmd/graphs/contributors) and they're unlikely to refactor ddmd to put forth a libdmd. It will depend

Re: Reset all Members of a Aggregate Instance

On 4/12/2015 8:38 AM, Chris Wright wrote: An object reference is just a pointer, but we can't directly cast it. So we make a pointer to it and cast that; the type system allows it. Now we can access the data that the object reference refers to directly. Casting is fine too: cast(void*)classRef

Re: Can someone check this on win32 ?

On 21/11/2015 10:46 PM, BBaz wrote: Seems to be fixed: __ import std.math; void main() {real function(real) c = } __ https://issues.dlang.org/show_bug.cgi?id=4541 At least it works on linux x86_64. It works because of

Re: Something about Chinese Disorder Code

On 25/11/2015 2:16 PM, Rikki Cattermole wrote: On 25/11/15 1:47 AM, Meta wrote: I'm pretty sure you can just do: wstring text = "my string"; Or auto text = "my string"w; The second one is correct yes. I'm just assuming that it isn't compiled into the executable. Either is fine.

Re: extern(C++, NS)

On 30/11/2015 10:42 PM, Manu via Digitalmars-d wrote: > Exactly, the D module system would still be in place. Assuming they were in defferent modules, then the D module system would keep them out of conflict naturally, with rules identical to the normal D rules. I imagined this; C++ namespace is

Re: I hate new DUB config format

On 26/11/2015 6:45 PM, Jacob Carlborg wrote: On 2015-11-25 20:02, Walter Bright wrote: Note 2: I intend to migrate the dmd.conf file format to json. What's the gain here compared to the breakage it will cause? We get to delete the non-boost INI parser from the frontend!

Re: I hate new DUB config format

On 27/11/2015 1:37 AM, Jacob Carlborg wrote: On 2015-11-26 12:47, Daniel Murphy wrote: We get to delete the non-boost INI parser from the frontend! How much trouble is that causing? None, it just annoys me.

Re: C++ to add import, module and export

On 25/11/2015 11:53 AM, deadalnix wrote: On Tuesday, 24 November 2015 at 23:14:28 UTC, deadalnix wrote: According to this: https://www.youtube.com/watch?v=RwdQA0pGWa4 There are plan to add these keyword in C++'s module system. Also, this module representation may be an opportunity for us to

Re: New __traits

On 25/11/2015 12:06 PM, BLM768 wrote: For a project I've been working on, I found that it would be helpful to have a way to determine whether a symbol represents a module or package. Since I couldn't find an easy way to do it, I forked DMD and made some tweaks. ;) Anyway, I uncovered an

Re: New __traits

On 26/11/2015 9:33 AM, BLM768 wrote: On Wednesday, 25 November 2015 at 15:39:17 UTC, Daniel Murphy wrote: What you're seeing is just an artifact of how dmd's internals work. 'std' is an 'import' (call Dsymbol.kind() for the category of symbol) and you'll have to resolve it to work out which

Re: I have this game engine...

On 4/11/2015 7:09 PM, Iain Buclaw via Digitalmars-d wrote: I'm aware of this, not because I take an interest, but because I was cc'd into discussion when they discovered a C++ regression that was seen by comparing the md5sum of (D frontend) interpret.c sources between 2nd and 3rd generation

Re: why to (not) support "older" compiler versions

On 4/11/2015 3:12 AM, Johannes Pfau wrote: A crazy idea: Once gdc supports the latest frontend version we could theoretically adjust the dmd pull request testing to also merge dmd pull requests into the gdc frontend and test gdc with these frontend-only requests. We would then only merge dmd

Re: Our template emission strategy is broken

On 13/11/2015 8:26 PM, Robert burner Schadek wrote: On Friday, 13 November 2015 at 02:50:07 UTC, Daniel Murphy wrote: You also need to modify root/rmem.d to actually use the GC as the allocator. I should have known that it couldn't be that simple. Anyway, after doing so. Building druntime

Re: Our template emission strategy is broken

On 12/11/2015 10:44 AM, Robert burner Schadek wrote: I just run make -f posix.mak unittest -j10 on phobos after removing GC.disable() from ddmd. It worked just fine. Everything build everything passed the tests. (the time program told 1:41.25 for nogc and 1:49.80 with gc. This is with running

Re: Release D 2.069.0

On 9/11/2015 10:25 AM, Jack Stouffer wrote: Is there any reason why this isn't currently used in the front end? Lack of testing, focus on matching c-dmd performance, it used to be blocked and nobody realized it wasn't any more etc.

Re: Release D 2.069.0

On 8/11/2015 1:41 AM, Dmitry Olshansky wrote: IMHO enabling D's GC in the frontend is better way to fix leaking in the CTFE, but there are some issues with that (it segfaults if we enable GC). Actually I think it's fixed now, just disabled. It used to have problems with lib*/scan*, but

Re: Is D so powerfull ??

On 9/11/2015 4:26 PM, Jeremy DeHaan wrote: What is the correct way to use C++ class instances in D? Can you by chance give an example? extern (C++) class X { ... } extern (C++) void func(X x); void main(string[] args) { func(new X()); } etc

Re: Is D so powerfull ??

On 9/11/2015 5:54 PM, Jeremy DeHaan wrote: Didn't you say constructors and destructors are missing? What should one do in those cases? Constructors and destructors do not match the C++ ABI, but they are still generated, so they can only be called from the language they were written in. So

Re: Is D so powerfull ??

On 9/11/2015 4:05 PM, Jeremy DeHaan wrote: Because that's what this page says: http://dlang.org/cpp_interface.html That page is out of date. Virtual and non-virtual member functions, static member functions, and free functions all work since ~2.066. The biggest missing thing is special

Re: why to (not) support "older" compiler versions

On 3/11/2015 7:52 PM, drug wrote: On 03.11.2015 11:22, Johannes Pfau wrote: I guess it's to be compatible with the latest DMD, LDC and GDC. GDC currently only provides the 2.066.1 frontend. A bit offtopic - will the situation change with ddmd accepted? I mean the situation with different

Re: #ifdef hell

On 31/10/2015 12:01 AM, Jacob Carlborg wrote: On 2015-10-30 03:01, Walter Bright wrote: I might add that over time, I'd been removing #if's and #ifdef's from the dmd front end source code. The results were very satisfactory - the code was easier to read, understand and maintain. It also made

Re: Fixing spurious "statement is not reachable" in template code

On 28/10/2015 4:29 PM, tsbockman wrote: I would say none, since *the template* contains no unreachable code, and the compiler can easily trim unreachable code from any *instantiation* which needs it, without bothering me about it. If it's unreachable or not depends on what the template is

Re: Fixing spurious "statement is not reachable" in template code

On 28/10/2015 4:02 PM, tsbockman wrote: (But not all control flow statements have static equivalents, so this solution can only be applied to some code. Even if we had `static switch`, `static foreach`, `static goto`, etc., I doubt that forcing the user to segregate all compile-time logic from

Re: Fixing spurious "statement is not reachable" in template code

On 25/10/2015 4:25 AM, tsbockman wrote: /// module main; import std.stdio; void reachIf(bool x)() { if(!x) return; writeln("reached"); // Warning: statement is not reachable } void main(string[] args) { reachIf!true(); // prints "reached"

Re: Fixing spurious "statement is not reachable" in template code

On 28/10/2015 8:29 AM, tsbockman wrote: On Tuesday, 27 October 2015 at 21:14:26 UTC, Timon Gehr wrote: On 10/27/2015 09:18 PM, tsbockman wrote: I don't think any dead code is being generated, This seems to be a misunderstanding. I mean generated using mixins or template instantiation. Sure,

Re: Purity of std.conv.to!string

On 27/09/2015 3:14 AM, cym13 wrote: On Saturday, 26 September 2015 at 17:08:00 UTC, Nordlöw wrote: Why is the following code not pure: float x = 3.14; import std.conv : to; auto y = x.to!string; ??? Is there a reason for it not being pure? If not, this is a serious problem as

Re: Magicport - where it is ?

On 14/09/2015 7:24 PM, Temtaime wrote: Hi ! I wonder if there's a repo with magicport that was used to convert dmd. I have a big library written in C++ and wanna try convert it to D. Or is magicport closed and there's no chance to get it ? Thanks for a reply. The latest version of magicport

Re: D-Day for DMD is today!

On 8/09/2015 1:54 AM, "Luís Marques <l...@luismarques.eu> wrote: On Friday, 4 September 2015 at 12:38:41 UTC, Daniel Murphy wrote: It's not that phobos is bad, it's that we're following the same development pattern we had with C++. We're using a conservative subset of D features an

Re: D-Day for DMD is today!

On 6/09/2015 2:47 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= wrote: But you are going to do high level refactoring too, right? Not just local conversions into foreachs and the like? Of course. Some of this was been started before the conversion.

Re: D-Day for DMD is today!

On 2/09/2015 11:23 PM, Rory McGuire via Digitalmars-d-announce wrote: Surely if the dog food is so bad no one should be eating? It's not that phobos is bad, it's that we're following the same development pattern we had with C++. We're using a conservative subset of D features and libraries,

Re: D-Day for DMD is today!

On 1/09/2015 11:57 PM, Rory McGuire via Digitalmars-d-announce wrote: Surely this is a code coverage issue then? Are there any unit tests in ddmd? There is an enormous test suite, but there are also plenty of parts with zero coverage.

Re: D-Day for DMD is today!

Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote in message news:mailman.640.1440835567.13986.digitalmars-d-annou...@puremagic.com... I'm planning to generate the C++ headers from the D source rather than maintain them by hand. You could use UDAs for that!

Re: D-Day for DMD is today!

Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote in message news:mailman.647.1440844869.13986.digitalmars-d-annou...@puremagic.com... Just an idea to selectively @tag any classes or functions you want to export to C++, then let the conversion tool do the rest.

Re: D-Day for DMD is today!

Jacob Carlborg wrote in message news:mrsigg$1574$1...@digitalmars.com... I'm pretty sure we already have a tool that generates C/C++ headers for D modules. Adam started one, I don't think it got to the point where it would work for this, and I don't agree that the json output is a good way

Re: D-Day for DMD is today!

Johannes Pfau wrote in message news:mrp3m1$184s$1...@digitalmars.com... Current GDC master can compile DDMD, although it uses the 2.066.1 frontend. Iain backported the relevant C++ mangle changes: https://github.com/D-Programming-Language/dmd/pull/4957 Yeah, I guess the more accurate

Re: D-Day for DMD is today!

Iain Buclaw via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote in message news:mailman.598.1440753894.13986.digitalmars-d-annou...@puremagic.com... Best to start using GDC in the CI development of DMD now though so we catch them when it happens! I've played the 'upgrade

Re: D-Day for DMD is today!

Luís Marques wrote in message news:fnhnundiapulkyqmi...@forum.dlang.org... Probably not all of them, though, no? For instance, utf.h is not needed by the GDC / LDC glue code, is it? We don't have a policy on this yet. It won't matter so much if we can auto-generate the headers.

Re: D-Day for DMD is today!

Luís Marques wrote in message news:ckyiqzpchfahzfjmm...@forum.dlang.org... What is the relation between the .h files that were left intact, and the backend, GDC, and LDC? When the backend is converted to D, will the DMD source drop the C++ header files, or will (some?) of those be left

Re: D-Day for DMD is today!

Bruno Medeiros wrote in message news:mrn30f$26ff$2...@digitalmars.com... Cool stuff! Yeah! What's the plan going forward, for those not so much up to date with what's going on? Is the next major release of DMD gonna be D-DMD based then? Which compiler is going to be used to compile D-DMD?

Re: DMD git HEAD now self-hosting

H. S. Teoh via Digitalmars-d wrote in message news:mailman.579.1440708229.13986.digitalmar...@puremagic.com... I'm surprised nobody has mentioned this on the forum yet, but as of 23 Aug, dmd git HEAD has switched over to ddmd with the landmark commit 88ec9d8. Since that time, the remaining

Re: dmd codegen improvements

John Colvin wrote in message news:qlbnpjnizwpslrdpk...@forum.dlang.org... I think he's saying that the argument: Don't work on DMD because it's already far behind could have been applied to working on LLVM when it was far behind GCC. I don't agree, but I think that's what he means. It

Re: DMD git HEAD now self-hosting

bitwise wrote in message news:ydbofgjkddszxedpw...@forum.dlang.org... So.. looking through the source, I see lots of this: extern (C++) class { ... } Wasn't extern(C++) only supposed to work on interfaces? Are the docs outdated? Yup. extern(C++) works with almost everything except special

Re: D-Day for DMD is today!

BBasile wrote in message news:rljvemqjfvnnqqnnc...@forum.dlang.org... Excellent. I guess it's also time to clean the wiki page that explained how to build under win32 with DMC. It's obsolete now. Nope! The glue layer and backend are still in C++, and still need to be built with DMC.

Re: D-Day for DMD is today!

Mike wrote in message news:hkyvytmqbstkelkum...@forum.dlang.org... There are still a number of .h files in the front end. What will happen with those? Do they need to be maintained? For now they must be maintained by hand, if there is any possibility of the glue layers or backends needing

Re: D-Day for DMD is today!

Joakim wrote in message news:sfhycfhmabpfxxuxn...@forum.dlang.org... Great work, thanks to Daniel and others who helped out, can't wait to use ddmd and see all the changes that come with it in the next couple releases. I can't wait to use foreach internally! No more manual for loops! Can

Re: D-Day for DMD is today!

BBasile wrote in message news:fmoabuqgvlztgmqyj...@forum.dlang.org... By the way, currently under win32 it's not possible to build DDMD unless the line --- #HOST_DC=dmd --- is uncommented. Because there is a bunch of commands using dmd compile and run (-run) in win32.mak. Is it a bug ?

Re: D-Day for DMD is today!

Dicebot wrote in message news:jdgpeyxvdltshldnf...@forum.dlang.org... Great! Daniel, does that mean that I can remove DDMD testing job from my CI? :) Yes, thanks!

Re: extern opaque struct

John Colvin wrote in message news:uhpgjffttsuqeswyj...@forum.dlang.org... Let's say I have some C headers that have code like this in: extern struct UndeclaredStruct blah; Undeclared *p = blah; which would naïvely translate to D as: struct UndeclaredStruct; extern UndeclaredStruct blah;

Re: force inline/not-inline

Steven Schveighoffer wrote in message news:mp86be$8f2$1...@digitalmars.com... the only thing I can thing of is that true/false are (or have the potential to be in this context) expressions, which means one could use compile-time logic to specify inlining. The same wouldn't be true of

Re: force inline/not-inline

tcak wrote in message news:psflpqqpsukpfgpzh...@forum.dlang.org... Why not like pragma(inline, [try | force | no]) ? Walter liked the boolean version, which is certainly better than nothing.

Re: version: multiple conditions

Walter Bright wrote in message news:mloslo$1o7v$1...@digitalmars.com... I have yet to see a single case of needing boolean versions that could not be refactored into something much more readable and maintainable that did not use such. Over time, I've gotten rid of most of that stuff from

Re: version: multiple conditions

Walter Bright wrote in message news:mloslo$1o7v$1...@digitalmars.com... I have yet to see a single case of needing boolean versions that could not be refactored into something much more readable and maintainable that did not use such. Over time, I've gotten rid of most of that stuff from

Re: version: multiple conditions

Walter Bright wrote in message news:mlorvv$1nb6$1...@digitalmars.com... On 6/14/2015 9:53 AM, bitwise wrote: What if I need AndroidOrWP8, and I also need Win32OrWin64? This can quickly become a much larger pita. If you need those, the design is wrong. It is better to think about what the

Re: Allow deprecated to accept more than string literals while parsing

Dicebot wrote in message news:odfsgqcftykjkztsg...@forum.dlang.org... Is there any reason to not allow argument to be any expression and reject non-string ones at semantic phase? The original reason is that trying to reference manifest constants etc from that context resulted in forward

Re: Evaluation order of index expressions

Andrei Alexandrescu wrote in message news:mjvlv5$vch$1...@digitalmars.com... which one is correct? GDC. -- Andrei I don't think it matters too much if we pick strict LTR, or keep dmd's existing exception for assign expressions. IIRC Walter is in favour of keeping the exception[1].

  1   2   3   4   5   6   7   8   9   10   >