Re: DMD 2.066 Alpha

Andrei Alexandrescu wrote in message news:lncrb0$31ec$1...@digitalmars.com... It was decided and 100% certain - virtual is not going in. Need to remove it from DMD before this release is out. Yes please. -- Andrei You did say that something with the same effect as 'virtual' was going in.

Re: DMD 2.066 Alpha

Andrei Alexandrescu wrote in message news:lndq8q$obh$1...@digitalmars.com... You did say that something with the same effect as 'virtual' was going in. No. I am certain either you or Walter did in the last 'final by default' discussion. Please no new keyword for what can be done

Re: bugzilla and auto-tester temporarily down

Brad Roberts via Digitalmars-d-announce wrote in message news:mailman.3141.1404253839.2907.digitalmars-d-annou...@puremagic.com... The host that runs these two services is down. I'm working on getting them back up. There's a reasonable chance I'll end up having to restore both db's from

Re: DMD v2.066.0-b4

safety0ff wrote in message news:xfceasqsqxxygwzsc...@forum.dlang.org... I have a kludge / patch for #11435, but I get the impression of apathy towards back end issues so I don't feel motivated to contribute. Are you joking? Do a pull request.

Re: D 2.066 is out. Enjoy!

Jacob Carlborg wrote in message news:lt43pj$ral$1...@digitalmars.com... Support for C++ namespaces where just released and support for C++ templates will most likely end up in master soon. Support for C++ templates was in the last release, and the new pull request is only for special

Re: D 2.066 is out. Enjoy!

Jonathan M Davis wrote in message news:fxdqpmfcbskvtcafz...@forum.dlang.org... LOL. Yeah, well, it would be ni going to support C+ce if we could get an actual list of the C++ features that D currently supports somewhere (and how to use them if it's not obvious). You've been doing so much

Re: D 2.066 is out. Enjoy!

Walter Bright wrote in message news:lt5l3k$2s5t$1...@digitalmars.com... The thing is, while the code was there, there wasn't a single test case for it in the test suite. Furthermore, at least for Elf, there was no support for the special mangling done for ::std:: stuff. Yeah, I don't know

Re: D 2.066 is out. Enjoy!

Walter Bright wrote in message news:lt7tan$24ei$1...@digitalmars.com... 1. I hate writing documentation. I really really hate it. Join the club :-) =) Sorry you got to be the pioneer with the arrows in your back, but you've paved the way for the rest of us. I don't really mind, for

Re: D 2.066 is out. Enjoy!

Kagamin wrote in message news:ujtkjzyvjhtvmcvjh...@forum.dlang.org... On Friday, 22 August 2014 at 08:18:18 UTC, Daniel Murphy wrote: 2. These features are rather difficult to use, and I don't want people to think they can just plug-and-play. I've spent a lot of time fighting compiler

Re: core.stdcpp

Ola Fosheim Grøstad wrote in message news:pbfaphgiugafrhach...@forum.dlang.org... I know, but the vendor provided C++ libraries could trigger compiler-magic in the optimizer, so it might not be enough to look at the source code in the general case… I would be very surprised to find a C++

Re: core.stdcpp

Mike wrote in message news:zjscnxerhbxnopvay...@forum.dlang.org... The C standard library and C++ standard library are not part of D-the-language. D would even be better served by putting these features in phobos as std.stdc and std.stdcpp. This would make them just as conveniently

Re: core.stdcpp

Ola Fosheim Grøstad wrote in message news:mclztlymyjydwhcxs...@forum.dlang.org... Probably, at least without whole-program optimization turned on. Linking with D is not a concern for whole-program-optimized C++ programs. But you still have to track compiler version changelogs and then deal

Re: core.stdcpp

Mike wrote in message news:bkkdiikafdsraqssj...@forum.dlang.org... I really don't see a practical problem with having them in druntime, only a philosophical one. It give the impression that D requires the C standard library, the C++ standard library, and an full-featured desktop OS in

Re: core.stdcpp

eles wrote in message news:qrfucjdbmydvoqgey...@forum.dlang.org... While this might be acceptable, there is one more question: what use to have the druntime separated from phobos, in this case? Apart from the fact that it's too late to change of course. For me the druntime shall include

Re: core.stdcpp

eles wrote in message news:ybcxmuwwpsiyupwer...@forum.dlang.org... The question of dupplication may be addressed now better, since the newly fixed bug about hierarchical packaging. I don't see how. _only that_ should be the runtime. And the sole part that one needs to port in order to

Re: core.stdcpp

eles wrote in message news:rixtiaiokrukvqjsf...@forum.dlang.org... But the request is simply to split the current druntime in a language-runtime and a phobos-runtime. The namespace and so on might even remain the same and the existing code would run unmodified. What is really important is

Re: D is for Data Science

weaselcat wrote in message news:rnlbybkfqokypxlgf...@forum.dlang.org... I see array.sort is planned for future deprecation, what does future fall under? Generally 'future deprecation' means at least 6 months after it gets turned into a warning. Often it's significantly longer, because

Re: Request for Recursive Warnings as Message DUB Flag

Nordlöw wrote in message news:iswbimvzcxegthnxg...@forum.dlang.org... Crap, I should of course have posted this on digitalmars.D. You should probably post it on dub's issue tracker or forums.

Re: Gource visualisations of various D repositories

Andrej Mitrovic via Digitalmars-d-announce wrote in message news:mailman.3585.1419448250.9932.digitalmars-d-annou...@puremagic.com... The animations are super-fast, it makes it hard to see what's going on but it's still fun. I wonder what that sudden branch explosion was in DMD, maybe some

Re: DConf 2015 Call for Submissions is now open

Jonathan M Davis via Digitalmars-d-announce wrote in message news:mailman.4595.1421160931.9932.digitalmars-d-annou...@puremagic.com... On Tuesday, January 13, 2015 14:39:42 Iain Buclaw via Digitalmars-d-announce wrote: Daniel prefers to talk through other peoples talks. :o) Or to work on

Re: 2015 H1 Vision

Joakim wrote in message news:nphrawlkmiwksghfy...@forum.dlang.org... Nice work, D needed some direction like this. I thought one oversight was no mention of ddmd, which seems to have gone into limbo over the last year. According to Daniel, it's pretty much done but is just waiting on Brad

Re: 2015 H1 Vision

Vladimir Panteleev wrote in message news:viqwfixznbdbdwvha...@forum.dlang.org... I don't use Dub You really should! I put it off for months and months but I'm quite happy with it now.

Re: DConf 2015 Call for Submissions is now open

Brad Anderson wrote in message news:jcidebafygjtdsabn...@forum.dlang.org... Sounds like a good subject for Daniel Murphy to talk about. He spent a good hour explaining to me how a linker works in the Aloft bar after most people had retired (thanks for that, Daniel) and he certainly knows dmd

DMD's lexer available on code.dlang.org

I've created a dub package for the D version of DMD's lexer, generated automatically from the C++ source. github: https://github.com/yebblies/ddmd dub: http://code.dlang.org/packages/ddmd There are a few annoying limitations, such that it uses dmd's error printing and allocation functions,

Re: DMD's lexer available on code.dlang.org

Rikki Cattermole wrote in message news:m8be2m$1dlp$1...@digitalmars.com... I saw that. I'm really looking forward to getting my teeth into it and doing some good old refactoring. Although that will be a while because of the auto generated thing. There's plenty of refactoring to be done on

Re: DMD's lexer available on code.dlang.org

Kiith-Sa wrote in message news:nffxogzwpmayydyom...@forum.dlang.org... (sorry if you get this question too often) How is DDMD as a whole going? Is it getting closer or are ongoing DMD changes slowing it down too much? It's been sitting still for 8 nearly months because of

Re: DMD's lexer available on code.dlang.org

Daniel Murphy wrote in message news:m8bdul$1dke$1...@digitalmars.com... I've created a dub package for the D version of DMD's lexer, generated automatically from the C++ source. github: https://github.com/yebblies/ddmd dub: http://code.dlang.org/packages/ddmd I've pushed a new version

Re: DMD's lexer available on code.dlang.org

Laeeth Isharc wrote in message news:vtgirvyjsalkzjvlz...@forum.dlang.org... Thanks v much - this will be very helpful indeed. Let me know if you have any questions about it.

Re: DMD's lexer available on code.dlang.org

Laeeth Isharc wrote in message news:yzmwemaevaltcmkyw...@forum.dlang.org... on a related note, have you considered sharing your translation tool (c++ - D)? I completely understand if you would rather not of course. The translation tool is available on github and is boost licensed. This

Re: Release Candidate D 2.067.0-rc1

Rainer Schuetze wrote in message news:mehkf1$21k2$1...@digitalmars.com... I think we should not do it for the dmd 2.067 release. It would be good to have it integrated into the test infrastructure before adding it to the release. I think that needs to be a hard requirement.

Re: dfmt 0.1.3 (codename: yebblied)

Brian Schott wrote in message news:wctzwywddsrjzbygr...@forum.dlang.org... https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.3 dfmt is a source code formatter for D. v0.1.3 fixes 34 issues from v0.1.2. The codename is inspired by somebody who may or may not* have filed 45 Github

Re: Digger 1.1

Robert M. Münch wrote in message news:mdi3sn$jh8$1...@digitalmars.com... make -fwin32.mak C=backend TK=tk ROOT=root HOST_DC= OPT=-o DEBUG= LFLAGS=-L/delexe/la dmd.exe run idgen Error: 'run' not found dmd has very recently been changed to required dmd already installed on the system. Until

Re: dfmt 0.1.0

Jacob Carlborg wrote in message news:md8vu6$hc1$1...@digitalmars.com... The DMD front end is not really designed to be used as a library for tooling. It isn't, but it's slowly getting better. eg You can now build the lexer as a library without pulling everything else in. It's quite

Re: dfmt 0.1.0

Brian Schott wrote in message news:updwbngwrilngxhun...@forum.dlang.org... dfmt is a D source code formatting tool. https://github.com/Hackerpilot/dfmt/ https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0 Is this on code.dlang.org? I can't find it.

Re: Interfacing D to existing C++ code

Walter Bright wrote in message news:maed4o$2da6$1...@digitalmars.com... So constructors and destructors are mangled 'a la D' instead of the C++ way. Please post this to bugzilla. The problems with constructors go beyond mangling, so the current forced D mangling is intentional to

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

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

Re: Implementing cent/ucent...

Kai Nacke wrote in message news:kxcbizohnxdtimjwl...@forum.dlang.org... But: I am not going to extend the DMD backend! This has 2 consequences. First, we need to decide how to integrate the code. (Do we want to clutter the code with #if WANT_CENT as I currently do? Should we wait for DDMD?)

Re: Monday is last day for DConf 2015 registrations

Steven Schveighoffer wrote in message news:mjkncd$21e7$1...@digitalmars.com... BTW, I will stress again that I'm going to be at the hotel all day Tuesday (and without a car) if anyone is interested in hanging out :) I'll be there from Saturday night.

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: 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: 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: 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!

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!

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!

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 8/09/2015 1:54 AM, "Luís Marques 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 and

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: 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: 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: 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: 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 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: 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: 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 on