Re: Mid-term vision review
On 05/04/2015 00:33, Walter Bright wrote: On 4/4/2015 1:59 PM, weaselcat wrote: proprietary license hindering contributions and distribution, performs worse across the board against GDC/LDC in terms of optimized binaries, lack of manpower in comparison to LLVM/GCC that have massive corporation and educational backing. Massive manpower doesn't do much good when doing tricky things like getting the optimizer to work well. An optimizer/code generator can be kept all in one head at the same time. MM pays off when you've got a galaxy of tools to be developed that are a bit independent of each other. "MM pays off when you've got a galaxy of tools to be developed that are a bit independent of each other." Exactly, and that's why LLVM/GCC are poised to have a lot more quality than DMD/DMC (if they don't already). Because in the D world there is also a variety of tools and development aspects to be worked upon: optimizer/code generator; frontend; debugging support; profiler; website and community admin; etc, LLVM/GCC can have (at least) one person working full-time for *each* of these aspects, whereas in the D world - at least for backend stuff like the optimizer/code generator - it's mainly just you Walter. But you working part-time on one such aspect, you can't possibly hope to match the quality of a dedicated multi-person team such as what LLVM/GCC have. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Mid-term vision review
On Tuesday, 7 April 2015 at 19:02:54 UTC, Pierre Krafft wrote: My opinion is that it should be addressed as a culture problem and not trying to limit the language. If a macro-system could be added it shouldn't be limited to just phobos code. Instead the community should look down upon over usage of the feature in non-library code. If you rely on people using good practice you are doomed. The only way to get people to do the "right thing©" is to make that right thing way easier than the wrong thing.
Re: Mid-term vision review
On Tuesday, 7 April 2015 at 08:01:19 UTC, Dicebot wrote: On Monday, 6 April 2015 at 18:17:31 UTC, deadalnix wrote: On the other hand, many features in the language could be implementation as macro in object.d, reducing language complexity. Mixin has some severe limitation when you want to pass symbols that are not accessible down the road (the type mechanism in SDC is a very good example of how absurdly complex things can get just because you need to make some symbols accessible down the road). I'm not eager to see them in, as I'd favor finishing what is already started. Over time, while researching how macro approach feels like in other languages, I have become more sceptical of providing it as a generally available feature. But it could be interesting to allow them only in std / core package to be able to move more language implementation into library. My opinion is that it should be addressed as a culture problem and not trying to limit the language. If a macro-system could be added it shouldn't be limited to just phobos code. Instead the community should look down upon over usage of the feature in non-library code.
Re: Mid-term vision review
On Tuesday, 7 April 2015 at 08:01:19 UTC, Dicebot wrote: On Monday, 6 April 2015 at 18:17:31 UTC, deadalnix wrote: On the other hand, many features in the language could be implementation as macro in object.d, reducing language complexity. Mixin has some severe limitation when you want to pass symbols that are not accessible down the road (the type mechanism in SDC is a very good example of how absurdly complex things can get just because you need to make some symbols accessible down the road). I'm not eager to see them in, as I'd favor finishing what is already started. Over time, while researching how macro approach feels like in other languages, I have become more sceptical of providing it as a generally available feature. But it could be interesting to allow them only in std / core package to be able to move more language implementation into library. Yes, this is my conclusion too. That is not desirable that this creep all over the codebase, by highly useful deep down in core libraries.
Re: Mid-term vision review
On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei vibe.d is a comprehensive approach to web development that is approaching maturity. We aim to raise its importance and relevance to D development: offer bundled installation with dmd, release in lockstep, make working with vibe.d an acceptance criterion for dmd releases. This idea does not sit well with me. I don't want D to become a framework like this (coming from Rails nonsense with Ruby). If the the compiler and the library will be released at the same time, then why not put vibe.d into phobos? Maybe not the entire thing but at least parts of it.
Re: Mid-term vision review
On Friday, 3 April 2015 at 15:35:15 UTC, Iain Buclaw wrote: On 3 April 2015 at 12:10, Andrea Fontana via Digitalmars-d wrote: It would be great to have dmd on embedded platforms. We have GDC supporting ARM, MIPS, PPC, S390, etc... LDC supporting ARM... what more do you want? Hmmm, probably I'm missing something. I tried some time ago to develop something for raspberry pi & co but it wasn't fully supported, if I'm right. Is phobos ported too? It would really useful: have you ever seen code for 3d printers? It would be benefit a lot from D :) I build a 3d printer, and its firmware is written in C for arduino from many hands. I thinks it would a good idea to switch to something like rpi, and rewrite firmware in D, it's not that complex. I had to check many times that C code, and I think it's really messy. Andrea
Re: Mid-term vision review
On Monday, 6 April 2015 at 18:17:31 UTC, deadalnix wrote: On the other hand, many features in the language could be implementation as macro in object.d, reducing language complexity. Mixin has some severe limitation when you want to pass symbols that are not accessible down the road (the type mechanism in SDC is a very good example of how absurdly complex things can get just because you need to make some symbols accessible down the road). I'm not eager to see them in, as I'd favor finishing what is already started. Over time, while researching how macro approach feels like in other languages, I have become more sceptical of providing it as a generally available feature. But it could be interesting to allow them only in std / core package to be able to move more language implementation into library.
Re: Mid-term vision review
On Monday, 6 April 2015 at 12:45:48 UTC, Martin Nowak wrote: On 04/06/2015 03:39 AM, Dennis Ritchie wrote: Thanks. I hope that in the near future will be a powerful D macrosystem. Don't expect too much enthusiasm about adding macros. Perhaps you're right. - D already has very good metaprogramming capabilities and most stuff macros can do, can already be achieved using string mixins - Macros in Scala turned out very complex (not sure about std.meta). - DSLs can fracture the community (http://winestockwebdesign.com/Essays/Lisp_Curse.html) In my opinion, should not be afraid to include language in anything complicated. I think that the complex and powerful things can help D to become even better. Might be a approach to write a good, fast, and CTFEable parsing library for. It would be nice.
Re: Mid-term vision review
On Monday, 6 April 2015 at 12:45:48 UTC, Martin Nowak wrote: On 04/06/2015 03:39 AM, Dennis Ritchie wrote: Thanks. I hope that in the near future will be a powerful D macrosystem. Don't expect too much enthusiasm about adding macros. - D already has very good metaprogramming capabilities and most stuff macros can do, can already be achieved using string mixins - Macros in Scala turned out very complex (not sure about std.meta). - DSLs can fracture the community (http://winestockwebdesign.com/Essays/Lisp_Curse.html) Might be a approach to write a good, fast, and CTFEable parsing library for. On the other hand, many features in the language could be implementation as macro in object.d, reducing language complexity. Mixin has some severe limitation when you want to pass symbols that are not accessible down the road (the type mechanism in SDC is a very good example of how absurdly complex things can get just because you need to make some symbols accessible down the road). I'm not eager to see them in, as I'd favor finishing what is already started.
Re: Mid-term vision review
On 04/06/2015 03:39 AM, Dennis Ritchie wrote: > > Thanks. I hope that in the near future will be a powerful D macrosystem. Don't expect too much enthusiasm about adding macros. - D already has very good metaprogramming capabilities and most stuff macros can do, can already be achieved using string mixins - Macros in Scala turned out very complex (not sure about std.meta). - DSLs can fracture the community (http://winestockwebdesign.com/Essays/Lisp_Curse.html) Might be a approach to write a good, fast, and CTFEable parsing library for.
Re: Mid-term vision review
On Monday, 6 April 2015 at 02:11:08 UTC, Daniel Murphy wrote: Yes, exactly. If I get my way, the conversion tool will be put into the dmd repository for a while, and it should be possible to automatically upgrade a pull request with rebase+convert+rebase. This method will be properly documented and advertised before the switch is made. Conflicts will still need to be resolved manually, of course, and some converter config data may need to be updated manually. Thank you very much for the clarification. This is a nice migration path and should be more then sufficient. Kind Regards Benjamin Thaut
Re: Mid-term vision review
"Benjamin Thaut" wrote in message news:nkhhmscwnjcrdbihk...@forum.dlang.org... > Daniel, any thoughts? Can we help with tooling? -- Andrei Shouldn't it be possible to tag the last C++ version of dmd? Then rebase the pull-reuqest on top of that and run it through the C++ to D conversion tool. Afterwards the output of the tool could be used to do a diff against the first D version of dmd (tagged again). This diff could then be used as a starting point for a new pull request. This will obviously not be perfect and might require some additional manual merging but at least people with larger pull requests (like me) don't have to redo the entire thing. A page with instructions how to do this conversion should be enough. Main points in question beeing, where to get the conversion tool and how to use it. Yes, exactly. If I get my way, the conversion tool will be put into the dmd repository for a while, and it should be possible to automatically upgrade a pull request with rebase+convert+rebase. This method will be properly documented and advertised before the switch is made. Conflicts will still need to be resolved manually, of course, and some converter config data may need to be updated manually.
Re: Mid-term vision review
On Friday, 3 April 2015 at 17:51:00 UTC, Andrei Alexandrescu
wrote:
On 4/3/15 4:04 AM, Dennis Ritchie wrote:
On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu
wrote:
It's the end of Q1. Walter and I reviewed our vision
document. We're
staying the course with one important addition: switching to
ddmd,
hopefully with 2.068.
http://wiki.dlang.org/Vision/2015H1
Andrei
Are there any plans for the creation of a powerful AST-macro
system in D?
http://wiki.dlang.org/DIP50
Not for the time being. -- Andrei
Thanks. I hope that in the near future will be a powerful D
macrosystem. If you ever start to create a macro system in D,
then I suggest you explore approaches Lisp family of languages,
because they have a very powerful macro-framework that allows
modifying the language to suit your needs. In the family of Lisp
contains a lot of powerful features that can once and for all to
eclipse C++. It would be very nice if in the future you add these
features in D. Sorry if I did something wrong said.
For Example,
D mixin's:
-
import std.stdio;
import std.algorithm;
string print(string s)
{
return `writeln(` ~ s ~ `);`;
}
void main()
{
auto a = 3;
auto arr = [1, 2, 3, 4, 5];
mixin(print(`5`)); // prints 5
mixin(print(`'c'`)); // prints c
mixin(print(`"str"`)); // prints str
mixin(print(`arr`)); // prints [1, 2, 3, 4, 5]
mixin(print(`arr.map!(t => ++t)`)); // prints [2, 3, 4, 5, 6]
mixin(print(`a`)); // prints 3
}
-
Mixin, created by a powerful macro system Common Lisp:
-
(defmacro mixin (f) (read-from-string (eval f)))
(defun pr (s)
(format nil "(print ~A)" s))
(defun main (&aux (a 3) (arr '(1 2 3 4 5)))
(mixin (pr "5"))
(mixin (pr "#\\c"))
(mixin (pr "\"str\""))
(mixin (pr "arr"))
(mixin (pr "(mapcar (lambda (x) (1+ x)) arr)"))
(mixin (pr "a"))
(values))
-
CL-USER> (main)
5
#\c
"str"
(1 2 3 4 5)
(2 3 4 5 6)
3 ; No value
Re: Mid-term vision review
On 5 April 2015 at 21:37, Benjamin Thaut via Digitalmars-d wrote: > On Sunday, 5 April 2015 at 18:30:16 UTC, Andrei Alexandrescu wrote: >> >> On 4/5/15 10:32 AM, Benjamin Thaut wrote: >>> >>> Am 03.04.2015 00:44, schrieb Andrei Alexandrescu: switching to ddmd, hopefully with 2.068. Andrei >>> >>> >>> That sounds nice, I just hope that there is going to be some nice >>> migration path for people currently working on Pull-Requests for the C++ >>> Version of dmd. I would prefer to not redo all the changes in D code. >> >> >> Daniel, any thoughts? Can we help with tooling? -- Andrei > > > Shouldn't it be possible to tag the last C++ version of dmd? Then rebase the > pull-reuqest on top of that and run it through the C++ to D conversion tool. > Afterwards the output of the tool could be used to do a diff against the > first D version of dmd (tagged again). This diff could then be used as a > starting point for a new pull request. This will obviously not be perfect > and might require some additional manual merging but at least people with > larger pull requests (like me) don't have to redo the entire thing. A page > with instructions how to do this conversion should be enough. Main points in > question beeing, where to get the conversion tool and how to use it. > Have a look here: https://github.com/D-Programming-Language/dmd/pull/3410 I believe the first goal is to get the automated conversion in as part of the autotester. So any new PRs in will go through compilation (in C++), automated conversion to D, then re-compilation (in D). If the PR cannot be automatically converted to D, then you'll need to fix it up in order to make conversion possible. Regards Iain
Re: Mid-term vision review
On Sunday, 5 April 2015 at 18:30:16 UTC, Andrei Alexandrescu wrote: On 4/5/15 10:32 AM, Benjamin Thaut wrote: Am 03.04.2015 00:44, schrieb Andrei Alexandrescu: switching to ddmd, hopefully with 2.068. Andrei That sounds nice, I just hope that there is going to be some nice migration path for people currently working on Pull-Requests for the C++ Version of dmd. I would prefer to not redo all the changes in D code. Daniel, any thoughts? Can we help with tooling? -- Andrei Shouldn't it be possible to tag the last C++ version of dmd? Then rebase the pull-reuqest on top of that and run it through the C++ to D conversion tool. Afterwards the output of the tool could be used to do a diff against the first D version of dmd (tagged again). This diff could then be used as a starting point for a new pull request. This will obviously not be perfect and might require some additional manual merging but at least people with larger pull requests (like me) don't have to redo the entire thing. A page with instructions how to do this conversion should be enough. Main points in question beeing, where to get the conversion tool and how to use it. Kind Regards Benjamin Thaut
Re: Mid-term vision review
On 4/5/15 10:32 AM, Benjamin Thaut wrote: Am 03.04.2015 00:44, schrieb Andrei Alexandrescu: switching to ddmd, hopefully with 2.068. Andrei That sounds nice, I just hope that there is going to be some nice migration path for people currently working on Pull-Requests for the C++ Version of dmd. I would prefer to not redo all the changes in D code. Daniel, any thoughts? Can we help with tooling? -- Andrei
Re: Mid-term vision review
Am 03.04.2015 00:44, schrieb Andrei Alexandrescu: switching to ddmd, hopefully with 2.068. Andrei That sounds nice, I just hope that there is going to be some nice migration path for people currently working on Pull-Requests for the C++ Version of dmd. I would prefer to not redo all the changes in D code. -- Kind Regards Benjamin Thaut
Re: Mid-term vision review
On 5 April 2015 at 13:49, David Nadlinger via Digitalmars-d wrote: > On Sunday, 5 April 2015 at 01:59:21 UTC, Daniel Murphy wrote: >> >> "weaselcat" wrote in message news:rspoyryeklgjychqf...@forum.dlang.org... >> >>> Out of curiosity, what was the communication level between the decision >>> to switch to ddmd frontend and the ldc/gdc team? >> >> >> The ldc and gdc teams have been involved since the first discussions at >> dconf13. > > > Yeah, I distinctly remember Iain, you and me plotting how we'd achieve world > domination even if Walter couldn't be convinced in the Aloft lobby. ;) > Step one being steering the development and direction of D awaying from Walter and into the hands of the community. ;-) Incidentally, it's step two (convincing the community to switch priorities) is the more difficult part. Iain.
Re: Mid-term vision review
On 4 April 2015 at 22:48, H. S. Teoh via Digitalmars-d wrote: > On Sat, Apr 04, 2015 at 01:10:43PM -0700, Walter Bright via Digitalmars-d > wrote: >> On 4/3/2015 9:41 AM, David Nadlinger wrote: >> >On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote: >> >>On 4/3/15 3:10 AM, Andrea Fontana wrote: >> >>>It would be great to have dmd on embedded platforms. >> >> >> >>I agree. We just don't have the champion for that yet. -- Andrei >> > >> >I might obviously be biased, but to be honest I don't see much value >> >in starting to port a largely obsolete backend to a whole new >> >processor architecture. >> >> It's not obsolete at all. There's nothing fundamentally wrong with it, >> or preventing new optimizations being added to it. After all, I didn't >> have trouble upgrading it from 16 to 32 bits, from 32 to 64, to Linux, >> to OSX, to SIMD, etc. > > The trouble with the dmd backend is that it currently doesn't produce > very well-optimized code. I have consistently observed a 20-30% > performance degradation with code compiled with dmd vs. code compiled > with gdc (both with all optimization switches turned to the max). From > cursory investigation of the asm output, dmd appears to be unable to > inline beyond the most trivial function calls, doesn't do loop > refactoring / unrolling as well as gdc does, and a host of other little > things that all add up to poorer performance when CPU-intensive inner > loops are concerned. A lot of this deficiency shows up especially in > range-based code, which consists of lots of calls to small functions > from inner loops, where performance really matters. > Not just inlining, each CPU has it's own quirks that need tending to as well, for instance, a Bonnel (Atom) CPU should have loop branches aligned to a 16-byte boundary, where-as other chips (Core i7, Sandybridge, etc) are fine on an 8-byte boundary. (Observation made in issue 5100) Iain.
Re: Mid-term vision review
On Sunday, 5 April 2015 at 01:59:21 UTC, Daniel Murphy wrote: "weaselcat" wrote in message news:rspoyryeklgjychqf...@forum.dlang.org... Out of curiosity, what was the communication level between the decision to switch to ddmd frontend and the ldc/gdc team? The ldc and gdc teams have been involved since the first discussions at dconf13. Yeah, I distinctly remember Iain, you and me plotting how we'd achieve world domination even if Walter couldn't be convinced in the Aloft lobby. ;) — David
Re: Mid-term vision review
On Sunday, 5 April 2015 at 05:04:52 UTC, H. S. Teoh wrote: On Sat, Apr 04, 2015 at 04:31:06PM -0700, Walter Bright via Digitalmars-d wrote: On 4/4/2015 1:48 PM, H. S. Teoh via Digitalmars-d wrote: >Besides, even if you could, you're just one person, whereas >gdc/ldc >have a much larger number of contributors, some of whose >specialty is >optimization. Do you realistically think you can >singlehandedly >outdo all of them? I did for decades, until the early 2000's or so when I began spending all my time on the front end. [...] Well, yes, that's because we need you more on DMDFE than on the backend, and that's why there will probably never be enough time for you to do everything you need to do with the backend. And that's why the backend will probably never be as good as gdc/ldc. T You can't reason people out of what the haven't been reasoned into.
Re: Mid-term vision review
On Sat, Apr 04, 2015 at 04:31:06PM -0700, Walter Bright via Digitalmars-d wrote: > On 4/4/2015 1:48 PM, H. S. Teoh via Digitalmars-d wrote: > >Besides, even if you could, you're just one person, whereas gdc/ldc > >have a much larger number of contributors, some of whose specialty is > >optimization. Do you realistically think you can singlehandedly > >outdo all of them? > > I did for decades, until the early 2000's or so when I began spending > all my time on the front end. [...] Well, yes, that's because we need you more on DMDFE than on the backend, and that's why there will probably never be enough time for you to do everything you need to do with the backend. And that's why the backend will probably never be as good as gdc/ldc. T -- Freedom: (n.) Man's self-given right to be enslaved by his own depravity.
Re: Mid-term vision review
On Saturday, 4 April 2015 at 22:05:33 UTC, H. S. Teoh wrote: On Sat, Apr 04, 2015 at 09:15:01PM +, weaselcat via Digitalmars-d wrote: On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote: >On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote: >>The reliance on GDC/LDC to produce production-level >>binaries(i.e, >>optimized) and the actual people working on them really is >>worrisome. If Iain or Kai decided one day to leave D, it >>would be a >>very big blow I think. > >Yes. And considering there is no hope that we bring dmd's >backend up >to speed with GCC or LLVM (let's be realistic one second) >what is >even more worrisome is how little they are integrated in the >workflow. Out of curiosity, what was the communication level between the decision to switch to ddmd frontend and the ldc/gdc team? I thought it was public knowledge for a while now that eventually we're gonna do this switch? It was just a matter of time. I mean, Daniel Murphy hasn't exactly been keeping hush-hush about progress on ddmd all this time. T I was just curious, didn't mean it to come off any other way : )
Re: Mid-term vision review
"weaselcat" wrote in message news:rspoyryeklgjychqf...@forum.dlang.org... Out of curiosity, what was the communication level between the decision to switch to ddmd frontend and the ldc/gdc team? The ldc and gdc teams have been involved since the first discussions at dconf13.
Re: Mid-term vision review
On 4/4/2015 1:59 PM, weaselcat wrote: proprietary license hindering contributions and distribution, performs worse across the board against GDC/LDC in terms of optimized binaries, lack of manpower in comparison to LLVM/GCC that have massive corporation and educational backing. Massive manpower doesn't do much good when doing tricky things like getting the optimizer to work well. An optimizer/code generator can be kept all in one head at the same time. MM pays off when you've got a galaxy of tools to be developed that are a bit independent of each other.
Re: Mid-term vision review
On 4/4/2015 1:48 PM, H. S. Teoh via Digitalmars-d wrote: Besides, even if you could, you're just one person, whereas gdc/ldc have a much larger number of contributors, some of whose specialty is optimization. Do you realistically think you can singlehandedly outdo all of them? I did for decades, until the early 2000's or so when I began spending all my time on the front end. There's no great mystery how to do it. I know how to improve all the issues you've mentioned, and then some. It's just a matter of being able to spend the time on it - it is not a matter of the design being obsolete and it must be tossed, which was what I was responding to.
Re: Mid-term vision review
On Sat, Apr 04, 2015 at 09:15:01PM +, weaselcat via Digitalmars-d wrote: > On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote: > >On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote: > >>The reliance on GDC/LDC to produce production-level binaries(i.e, > >>optimized) and the actual people working on them really is > >>worrisome. If Iain or Kai decided one day to leave D, it would be a > >>very big blow I think. > > > >Yes. And considering there is no hope that we bring dmd's backend up > >to speed with GCC or LLVM (let's be realistic one second) what is > >even more worrisome is how little they are integrated in the > >workflow. > > Out of curiosity, what was the communication level between the > decision to switch to ddmd frontend and the ldc/gdc team? I thought it was public knowledge for a while now that eventually we're gonna do this switch? It was just a matter of time. I mean, Daniel Murphy hasn't exactly been keeping hush-hush about progress on ddmd all this time. T -- Give me some fresh salted fish, please.
Re: Mid-term vision review
On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote: On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote: The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think. Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow. Out of curiosity, what was the communication level between the decision to switch to ddmd frontend and the ldc/gdc team?
Re: Mid-term vision review
On Saturday, 4 April 2015 at 20:10:45 UTC, Walter Bright wrote: On 4/3/2015 9:41 AM, David Nadlinger wrote: On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote: On 4/3/15 3:10 AM, Andrea Fontana wrote: It would be great to have dmd on embedded platforms. I agree. We just don't have the champion for that yet. -- Andrei I might obviously be biased, but to be honest I don't see much value in starting to port a largely obsolete backend to a whole new processor architecture. It's not obsolete at all. There's nothing fundamentally wrong with it, or preventing new optimizations being added to it. After all, I didn't have trouble upgrading it from 16 to 32 bits, from 32 to 64, to Linux, to OSX, to SIMD, etc. There's nothing fundamentally wrong with it, proprietary license hindering contributions and distribution, performs worse across the board against GDC/LDC in terms of optimized binaries, lack of manpower in comparison to LLVM/GCC that have massive corporation and educational backing.
Re: Mid-term vision review
On Sat, Apr 04, 2015 at 01:10:43PM -0700, Walter Bright via Digitalmars-d wrote: > On 4/3/2015 9:41 AM, David Nadlinger wrote: > >On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote: > >>On 4/3/15 3:10 AM, Andrea Fontana wrote: > >>>It would be great to have dmd on embedded platforms. > >> > >>I agree. We just don't have the champion for that yet. -- Andrei > > > >I might obviously be biased, but to be honest I don't see much value > >in starting to port a largely obsolete backend to a whole new > >processor architecture. > > It's not obsolete at all. There's nothing fundamentally wrong with it, > or preventing new optimizations being added to it. After all, I didn't > have trouble upgrading it from 16 to 32 bits, from 32 to 64, to Linux, > to OSX, to SIMD, etc. The trouble with the dmd backend is that it currently doesn't produce very well-optimized code. I have consistently observed a 20-30% performance degradation with code compiled with dmd vs. code compiled with gdc (both with all optimization switches turned to the max). From cursory investigation of the asm output, dmd appears to be unable to inline beyond the most trivial function calls, doesn't do loop refactoring / unrolling as well as gdc does, and a host of other little things that all add up to poorer performance when CPU-intensive inner loops are concerned. A lot of this deficiency shows up especially in range-based code, which consists of lots of calls to small functions from inner loops, where performance really matters. Now, obviously, there's nothing (in theory) stopping you or anybody else from improving the backend so that it *can* perform better optimizations, but the fact of the matter is that there is a whole group of dedicated contributors to gdc/ldc backends who are constantly honing their respective optimizers, some of whom specialize in improving optimizers, whereas AFAICT you are the only one here who's truly comfortable with dmd's backend code and who can implement these improvements within a reasonable amount of effort. However, we need you for other, high-level things related to D -- we can't afford you to spend all of your time working only on the optimizer in the backend. Besides, even if you could, you're just one person, whereas gdc/ldc have a much larger number of contributors, some of whose specialty is optimization. Do you realistically think you can singlehandedly outdo all of them? And now we're talking about adding whole new platforms to the backend, with all that it entails (need to write more optimization code for each new target and maintain it all, etc.). With all due respect, I recognize that you produced superior C/C++ compilers back in the day in spite of the naysayers, but as they say, extraordinary claims require extraordinary proof. You had extraordinary proof back then, in the form of actual compilers that generated superior code. Unfortunately, today, staring me in the face is the irrefutable data that dmd-produced code consistently performs 20-30% poorer than gdc-produced code (sometimes I've seen it as bad as 40-50%). In light of that, I find it hard to justify investing more effort into the dmd backend when you could instead put your efforts into improving DMDFE and let the gdc/ldc backend guys do what they do best. T -- Give me some fresh salted fish, please.
Re: Mid-term vision review
On 4/3/2015 9:41 AM, David Nadlinger wrote: On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote: On 4/3/15 3:10 AM, Andrea Fontana wrote: It would be great to have dmd on embedded platforms. I agree. We just don't have the champion for that yet. -- Andrei I might obviously be biased, but to be honest I don't see much value in starting to port a largely obsolete backend to a whole new processor architecture. It's not obsolete at all. There's nothing fundamentally wrong with it, or preventing new optimizations being added to it. After all, I didn't have trouble upgrading it from 16 to 32 bits, from 32 to 64, to Linux, to OSX, to SIMD, etc.
Re: Mid-term vision review
On 4/3/2015 2:59 PM, Kai Nacke wrote: My plan with LDC is to use the CPP backend to produce a boot strap compiler and then compile the D source. Much work... I don't understand. Why can't you use the existing LDC compiler to bootstrap?
Re: Mid-term vision review
On Friday, 3 April 2015 at 21:59:38 UTC, Kai Nacke wrote: My plan with LDC is to use the CPP backend to produce a boot strap compiler and then compile the D source. Much work... CPP backend? — David
Re: Mid-term vision review
On 2015-04-04 01:00, Iain Buclaw via Digitalmars-d wrote: Summary of sources in first link, those familiar with DMD internals will understand what the glue methods more or less do. It's not like there's a lot of documentation for the DMD internals ;) -- /Jacob Carlborg
Re: Mid-term vision review
"Mike" wrote in message news:ipfucgyjwwjdvmmik...@forum.dlang.org... Also, there may not be any need for changes to the backend. The Intel Galileo [1] is a Pentium-based Quark MCU [2], and the Intel Edison [3] is a dual-core Atom CPU. Walter already said he thinks DMD might be able to program the Quark. These aren't really "micro"controllers as they have an abundance of resources compared to the ARM Cortex-M and Atmel AVRs, but it has it's place in the ecosystem. Also, there is no reason one can't use their desktop PC to experiment. I see modularization of the language benefiting all domains, and I think if it existed, we'd see those features exploited in many interesting ways. Yes, as long as we're targeting x86 the dmd backend has a chance. Targeting another architecture would not be worth the effort.
Re: Mid-term vision review
On Friday, 3 April 2015 at 16:41:14 UTC, David Nadlinger wrote: On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote: On 4/3/15 3:10 AM, Andrea Fontana wrote: It would be great to have dmd on embedded platforms. I agree. We just don't have the champion for that yet. -- Andrei I might obviously be biased, but to be honest I don't see much value in starting to port a largely obsolete backend to a whole new processor architecture. I see a benefit in bringing DMD to an embedded platform: To suggest, experiment with, and introduce changes to the frontend/runtime that benefit all compilers and embedded development in D. Such a task isn't one for an embedded champion, however, it needs a compiler champion. We can't really get serious about building embedded systems in D until there is better compiler/runtime support. There are two impediments to this: (1) A strategy identifying a way forward. How do we modularize the language, and how do we implement that modularization? My suggestions have not been very popular, but I enthusiastically welcome suggestions. (2) Compiler hacking skills necessary to implement those changes without stirring the aversion to change. I have worked on this, but I failed while trying to modify the compiler, and I've been discouraged by suggestions that we don't want to "shuffle the deck". Perhaps in the next few months I'll try to get some conversations started around this, but I'm still exploring other alternatives at the moment. Also, there may not be any need for changes to the backend. The Intel Galileo [1] is a Pentium-based Quark MCU [2], and the Intel Edison [3] is a dual-core Atom CPU. Walter already said he thinks DMD might be able to program the Quark. These aren't really "micro"controllers as they have an abundance of resources compared to the ARM Cortex-M and Atmel AVRs, but it has it's place in the ecosystem. Also, there is no reason one can't use their desktop PC to experiment. I see modularization of the language benefiting all domains, and I think if it existed, we'd see those features exploited in many interesting ways. Mike [1] - Intel Galileo - http://www.intel.com/content/www/us/en/do-it-yourself/galileo-maker-quark-board.html [2] - Intel Quark - http://www.intel.com/content/www/us/en/processors/quark/intel-quark-technologies.html [3] - Intel Edison - http://www.intel.com/content/www/us/en/do-it-yourself/edison.html
Re: Mid-term vision review
On Saturday, 4 April 2015 at 01:03:14 UTC, deadalnix wrote: On Friday, 3 April 2015 at 23:59:52 UTC, weaselcat wrote: On Friday, 3 April 2015 at 23:47:48 UTC, deadalnix wrote: On Friday, 3 April 2015 at 22:46:31 UTC, weaselcat wrote: On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote: On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote: The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think. Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow. The best way to help would probably be to work on contributor guides/documentation. They don't seem to have much of either of these - or I'm blind(good possibility.) Even if so what is the point ? That is completely wasted work. It is already done elsewhere. That is aggravated pathological NIH syndrome right there. Maybe I'm misreading, but I don't see how documentation is NIH syndrome. Like always in economy, the question is compared to what ? Writing documentation on that thing, compared to what valuable use of people's time. Considering there is no hope for this to compete with other backends in term of supported targets, the only reason you'd have to invest in there is NIH syndrome. I was referring to LDC and/or GDC.
Re: Mid-term vision review
On Friday, 3 April 2015 at 23:59:52 UTC, weaselcat wrote: On Friday, 3 April 2015 at 23:47:48 UTC, deadalnix wrote: On Friday, 3 April 2015 at 22:46:31 UTC, weaselcat wrote: On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote: On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote: The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think. Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow. The best way to help would probably be to work on contributor guides/documentation. They don't seem to have much of either of these - or I'm blind(good possibility.) Even if so what is the point ? That is completely wasted work. It is already done elsewhere. That is aggravated pathological NIH syndrome right there. Maybe I'm misreading, but I don't see how documentation is NIH syndrome. Like always in economy, the question is compared to what ? Writing documentation on that thing, compared to what valuable use of people's time. Considering there is no hope for this to compete with other backends in term of supported targets, the only reason you'd have to invest in there is NIH syndrome.
Re: Mid-term vision review
On Friday, 3 April 2015 at 23:47:48 UTC, deadalnix wrote: On Friday, 3 April 2015 at 22:46:31 UTC, weaselcat wrote: On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote: On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote: The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think. Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow. The best way to help would probably be to work on contributor guides/documentation. They don't seem to have much of either of these - or I'm blind(good possibility.) Even if so what is the point ? That is completely wasted work. It is already done elsewhere. That is aggravated pathological NIH syndrome right there. Maybe I'm misreading, but I don't see how documentation is NIH syndrome.
Re: Mid-term vision review
On Friday, 3 April 2015 at 22:46:31 UTC, weaselcat wrote: On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote: On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote: The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think. Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow. The best way to help would probably be to work on contributor guides/documentation. They don't seem to have much of either of these - or I'm blind(good possibility.) Even if so what is the point ? That is completely wasted work. It is already done elsewhere. That is aggravated pathological NIH syndrome right there.
Re: Mid-term vision review
On Friday, 3 April 2015 at 21:59:38 UTC, Kai Nacke wrote: On Friday, 3 April 2015 at 18:04:14 UTC, deadalnix wrote: Also, what are the plan for GDC and LDC if we move toward DDMD ? My plan with LDC is to use the CPP backend to produce a boot strap compiler and then compile the D source. Much work... Regards, Kai Bindings for LLVM and GCC would still have to be written/generated (and work). Calypso could help with building D versions of GDC and LDC, H1 seems a bit early but it's shaping up.
Re: Mid-term vision review
On 4 April 2015 at 00:46, weaselcat via Digitalmars-d wrote: > On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote: >> >> On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote: >>> >>> The reliance on GDC/LDC to produce production-level binaries(i.e, >>> optimized) and the actual people working on them really is worrisome. If >>> Iain or Kai decided one day to leave D, it would be a very big blow I think. >> >> >> Yes. And considering there is no hope that we bring dmd's backend up to >> speed with GCC or LLVM (let's be realistic one second) what is even more >> worrisome is how little they are integrated in the workflow. > > > The best way to help would probably be to work on contributor > guides/documentation. They don't seem to have much of either of these - or > I'm blind(good possibility.) > Summary of sources in first link, those familiar with DMD internals will understand what the glue methods more or less do. http://gdcproject.org/documentation/ Only coding guidelines are the rough notes in the link below, and that all changes should be reported in the relevant ChangeLog entry. https://gcc.gnu.org/codingconventions.html#CandCxx I'd expect things to change dramatically in the future though what with all these glue methods now gone (thanks yebblies), and the new glue Visitor's giving free reign on compiler backend's to simplify and lower the entry barrier for potential new contributors. Regards Iain.
Re: Mid-term vision review
On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote: On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote: The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think. Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow. The best way to help would probably be to work on contributor guides/documentation. They don't seem to have much of either of these - or I'm blind(good possibility.) let's be realistic one second sometimes I feel the D community puts too much emphasis on what might be rather than what is ;)
Re: Mid-term vision review
On 3 April 2015 at 23:59, Kai Nacke via Digitalmars-d wrote: > On Friday, 3 April 2015 at 18:04:14 UTC, deadalnix wrote: >> >> Also, what are the plan for GDC and LDC if we move toward DDMD ? > > > My plan with LDC is to use the CPP backend to produce a boot strap compiler > and then compile the D source. Much work... > > Regards, > Kai Then we'd have to make sure that we never use any new compiler features added after the switch to D in the frontend. Otherwise the CPP sources in stage1 will need to be continually maintained alongside. I think a couple of things need doing that would really help here: 1. Push for getting binary packages to be built and hosted in distributor software repositories before the switch. ie: Packages for all supported targets on Archlinux, Debian, Fedora, OpenSUSE. This makes life easier for the package maintainers of each of those repos too, rather than have them go through a process of bootstrapping unsupported targets via a cross-compiler. 2. Test the following configurations on native host/target compilations (eg: x86 -> x86). host=dmd build=ldc host=dmd build=gdc host=ldc build=dmd host=ldc build=gdc host=gdc build=dmd host=gdc build=ldc In the absence of a D host compiler, downloading binaries of one D compiler should allow you to bootstrap any alternative D compiler. Regards Iain.
Re: Mid-term vision review
On Friday, 3 April 2015 at 18:04:14 UTC, deadalnix wrote: Also, what are the plan for GDC and LDC if we move toward DDMD ? My plan with LDC is to use the CPP backend to produce a boot strap compiler and then compile the D source. Much work... Regards, Kai
Re: Mid-term vision review
On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote: The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think. Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow.
Re: Mid-term vision review
On Friday, 3 April 2015 at 16:41:14 UTC, David Nadlinger wrote: On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote: On 4/3/15 3:10 AM, Andrea Fontana wrote: It would be great to have dmd on embedded platforms. I agree. We just don't have the champion for that yet. -- Andrei I might obviously be biased, but to be honest I don't see much value in starting to port a largely obsolete backend to a whole new processor architecture. Sure, it might be a fun exercise for somebody interested in learning about code generation. But in terms of pushing D forward, I think the much better option is to encourage people to contribute to GDC or LDC instead, where backends for virtually all important embedded platforms already exist. — David The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think.
Re: Mid-term vision review
On 4/3/15 9:41 AM, David Nadlinger wrote: On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote: On 4/3/15 3:10 AM, Andrea Fontana wrote: It would be great to have dmd on embedded platforms. I agree. We just don't have the champion for that yet. -- Andrei I might obviously be biased, but to be honest I don't see much value in starting to port a largely obsolete backend to a whole new processor architecture. Sure, it might be a fun exercise for somebody interested in learning about code generation. But in terms of pushing D forward, I think the much better option is to encourage people to contribute to GDC or LDC instead, where backends for virtually all important embedded platforms already exist. The matter of finding a champion applies all the same :o). -- Andrei
Re: Mid-term vision review
On Friday, 3 April 2015 at 17:51:00 UTC, Andrei Alexandrescu wrote: On 4/3/15 4:04 AM, Dennis Ritchie wrote: On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei Are there any plans for the creation of a powerful AST-macro system in D? http://wiki.dlang.org/DIP50 Not for the time being. -- Andrei Conclusion with wish I agree. However, I'd like us to keep in mind that the proposal is around, as I think it is highly relevant for discussion like the ones related to unittests - behavior could be easily customized if the damn thing was a macro. Also, what are the plan for GDC and LDC if we move toward DDMD ?
Re: Mid-term vision review
On 4/3/15 4:04 AM, Dennis Ritchie wrote: On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei Are there any plans for the creation of a powerful AST-macro system in D? http://wiki.dlang.org/DIP50 Not for the time being. -- Andrei
Re: Mid-term vision review
On Friday, 3 April 2015 at 16:41:14 UTC, David Nadlinger wrote: On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote: On 4/3/15 3:10 AM, Andrea Fontana wrote: It would be great to have dmd on embedded platforms. I agree. We just don't have the champion for that yet. -- Andrei I might obviously be biased, but to be honest I don't see much value in starting to port a largely obsolete backend to a whole new processor architecture. Sure, it might be a fun exercise for somebody interested in learning about code generation. But in terms of pushing D forward, I think the much better option is to encourage people to contribute to GDC or LDC instead, where backends for virtually all important embedded platforms already exist. — David I think I might agree to that. What matters more is having light weight runtimes for embedded systems. There's no single good answer, so it will have to be down to switching features on and off. (GC for sure, exceptions, type info, etc.)
Re: Mid-term vision review
On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote: On 4/3/15 3:10 AM, Andrea Fontana wrote: It would be great to have dmd on embedded platforms. I agree. We just don't have the champion for that yet. -- Andrei I might obviously be biased, but to be honest I don't see much value in starting to port a largely obsolete backend to a whole new processor architecture. Sure, it might be a fun exercise for somebody interested in learning about code generation. But in terms of pushing D forward, I think the much better option is to encourage people to contribute to GDC or LDC instead, where backends for virtually all important embedded platforms already exist. — David
Re: Mid-term vision review
On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei I'm glad to see embedded systems mentioned there. I'm planning on seeing if I can get a D program to run on a Pebble watch, so I've been asking around for limited runtimes recently. I think it would be a big bonus to have some support for limited runtimes, as I think D can do very well as a "better C" with some support there. I won't promise much from my experiments, but I'll certainly post about it if it gets somewhere. When std.allocator becomes part of Phobos, I'll probaly experiment with writing containers with different allocators.
Re: Mid-term vision review
On Friday, 3 April 2015 at 16:03:11 UTC, Joakim wrote: On Friday, 3 April 2015 at 11:04:36 UTC, Dennis Ritchie wrote: Are there any plans for the creation of a powerful AST-macro system in D? http://wiki.dlang.org/DIP50 No, Walter and Andrei are against it: http://forum.dlang.org/thread/l5otb1$1dhi$1...@digitalmars.com?page=20#post-l62466:242n8p:241:40digitalmars.com Thanks.
Re: Mid-term vision review
On Friday, 3 April 2015 at 11:04:36 UTC, Dennis Ritchie wrote: Are there any plans for the creation of a powerful AST-macro system in D? http://wiki.dlang.org/DIP50 No, Walter and Andrei are against it: http://forum.dlang.org/thread/l5otb1$1dhi$1...@digitalmars.com?page=20#post-l62466:242n8p:241:40digitalmars.com On Friday, 3 April 2015 at 13:41:02 UTC, Wyatt wrote: On Friday, 3 April 2015 at 10:56:24 UTC, Joakim wrote: You have already been doing this recently by listing various needed jobs on the forum with the [WORK] label, which is helpful for those looking for ways to pitch in, but it would be better if they were listed on a single page in the wiki. Or use the built-in keywords functionality of Bugzilla. Or tracking bugs. Those would both work, but you still need to surface them somewhere on the wiki or main site, because the bugzilla interface doesn't appear that great at surfacing such topics. Things just get lost in bugzilla, as it's hard to search, though you could put together a list on the wiki with links to the relevant bugzilla issues, if you wanted to keep bugzilla as the main archive. Is it? I don't understand, what problem are you having? (IME, It's a damn sight better than any of the alternatives when you have this many issues.) I've had problems searching for dmd error strings in bugzilla and had a much better experience doing a google custom search on forum.dlang.org instead, using google search to find it through the web mirror. Perhaps I'm just not adequately aware of how bugzilla search works, but the moment you need casual users to guess the right keywords to search for, you lose 99% of them. Even if it's all done in bugzilla underneath, you need to have some sort of external links from the wiki or somewhere easier to find, because bugzilla is a very effective haystack.
Re: Mid-term vision review
On 3 April 2015 at 12:10, Andrea Fontana via Digitalmars-d wrote: > It would be great to have dmd on embedded platforms. > We have GDC supporting ARM, MIPS, PPC, S390, etc... LDC supporting ARM... what more do you want?
Re: Mid-term vision review
On 4/3/15 1:30 AM, Guillaume Chatelet wrote: On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei Regarding "C++ integration". I'm working on https://issues.dlang.org/show_bug.cgi?id=14178 which is the first step to get STL working. Sounds great, thanks! Keep us posted. -- Andrei
Re: Mid-term vision review
On 4/3/15 3:10 AM, Andrea Fontana wrote: It would be great to have dmd on embedded platforms. I agree. We just don't have the champion for that yet. -- Andrei
Re: Mid-term vision review
On Friday, 3 April 2015 at 00:41:06 UTC, weaselcat wrote: maybe wishful thinking, but it would be nice if this was on dub until it does get some sort of review, but I'm not sure how much work it would take to get it on there. I turned this into a separate repo at some point, https://github.com/andralex/std_allocator. Should be fairly easy to update that and integrate doc building so that it be used/developed as dub package until it gets included into std_expermintal. Have it as separate repo also makes it easier to contribute.
Re: Mid-term vision review
On Friday, 3 April 2015 at 10:56:24 UTC, Joakim wrote: You have already been doing this recently by listing various needed jobs on the forum with the [WORK] label, which is helpful for those looking for ways to pitch in, but it would be better if they were listed on a single page in the wiki. Or use the built-in keywords functionality of Bugzilla. Or tracking bugs. Things just get lost in bugzilla, as it's hard to search, though you could put together a list on the wiki with links to the relevant bugzilla issues, if you wanted to keep bugzilla as the main archive. Is it? I don't understand, what problem are you having? (IME, It's a damn sight better than any of the alternatives when you have this many issues.) -Wyatt
Re: Mid-term vision review
On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei Are there any plans for the creation of a powerful AST-macro system in D? http://wiki.dlang.org/DIP50 On Friday, 3 April 2015 at 08:30:18 UTC, Guillaume Chatelet wrote: Regarding "C++ integration". I'm working on https://issues.dlang.org/show_bug.cgi?id=14178 which is the first step to get STL working. Fine.
Re: Mid-term vision review
On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 That's great news, looking forward to ddmd getting out soon. Looks like this will take about 50-60% of dmd's source to D, which should also help a bit with creating a D cross-compiler. One move that might help is to list specific steps you'd like taken for each of those broader goals, ie a list of "action items" to further each of those goals. Otherwise, many of those are too vague for people to actually pick up and act on: how do they improve the quality of implementation or "brand?" You have already been doing this recently by listing various needed jobs on the forum with the [WORK] label, which is helpful for those looking for ways to pitch in, but it would be better if they were listed on a single page in the wiki. Things just get lost in bugzilla, as it's hard to search, though you could put together a list on the wiki with links to the relevant bugzilla issues, if you wanted to keep bugzilla as the main archive. Also, now that the download page splits up the zip files by OS, a long-needed move, it would be interesting to see stats of downloads by OS. :)
Re: Mid-term vision review
It would be great to have dmd on embedded platforms. On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei
Re: Mid-term vision review
On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei Regarding "C++ integration". I'm working on https://issues.dlang.org/show_bug.cgi?id=14178 which is the first step to get STL working.
Re: Mid-term vision review
On Thursday, 2 April 2015 at 23:44:01 UTC, Andrei Alexandrescu wrote: On 4/2/15 4:39 PM, Brian Schott wrote: On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei I see that the memory management item is still there. What's going on with std.allocator? I'm hard at work on it. https://github.com/andralex/phobos/tree/allocator maybe wishful thinking, but it would be nice if this was on dub until it does get some sort of review, but I'm not sure how much work it would take to get it on there.
Re: Mid-term vision review
On 4/2/15 4:47 PM, weaselcat wrote: Is the workflow for getting into std.experimental defined - i.e, does it have to be reviewed before going into std.experimental or after? We didn't discuss that much yet, but in all likelihood we need two stages of review: general fitness assessment for std.experimental, then a much stronger scrutiny for admission into std. -- Andrei
Re: Mid-term vision review
On Thursday, 2 April 2015 at 23:44:01 UTC, Andrei Alexandrescu wrote: On 4/2/15 4:39 PM, Brian Schott wrote: On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei I see that the memory management item is still there. What's going on with std.allocator? I'm hard at work on it. https://github.com/andralex/phobos/tree/allocator I have a few projects (some on Github, some at EMSI) that use it because it seemed like it was on its way to being in Phobos. What can I do to help with this? Thanks for offering! I think the best thing to do will be test harnesses and performance evaluation. Let's discuss that more when I get closer to something reviewable for Phobos. Andrei Is the workflow for getting into std.experimental defined - i.e, does it have to be reviewed before going into std.experimental or after?
Re: Mid-term vision review
On 4/2/15 4:39 PM, Brian Schott wrote: On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei I see that the memory management item is still there. What's going on with std.allocator? I'm hard at work on it. https://github.com/andralex/phobos/tree/allocator I have a few projects (some on Github, some at EMSI) that use it because it seemed like it was on its way to being in Phobos. What can I do to help with this? Thanks for offering! I think the best thing to do will be test harnesses and performance evaluation. Let's discuss that more when I get closer to something reviewable for Phobos. Andrei
Re: Mid-term vision review
On Thursday, 2 April 2015 at 23:39:53 UTC, Brian Schott wrote: On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei I see that the memory management item is still there. What's going on with std.allocator? I have a few projects (some on Github, some at EMSI) that use it because it seemed like it was on its way to being in Phobos. What can I do to help with this? +1
Re: Mid-term vision review
On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei I see that the memory management item is still there. What's going on with std.allocator? I have a few projects (some on Github, some at EMSI) that use it because it seemed like it was on its way to being in Phobos. What can I do to help with this?
Re: Mid-term vision review
On Thursday, 2 April 2015 at 22:44:56 UTC, Andrei Alexandrescu wrote: It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei What is the plan for GDC and LDC ?
Mid-term vision review
It's the end of Q1. Walter and I reviewed our vision document. We're staying the course with one important addition: switching to ddmd, hopefully with 2.068. http://wiki.dlang.org/Vision/2015H1 Andrei
