www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mid-term vision review

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 02 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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 ?
Apr 02 2015
prev sibling next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
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?
Apr 02 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
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
Apr 02 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 02 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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?
Apr 02 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 02 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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.
Apr 02 2015
parent "Martin Nowak" <code dawg.eu> writes:
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.
Apr 03 2015
prev sibling next sibling parent reply "Guillaume Chatelet" <chatelet.guillaume gmail.com> writes:
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.
Apr 03 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 03 2015
prev sibling next sibling parent reply "Andrea Fontana" <mail example.com> writes:
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
Apr 03 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 03 2015
parent reply "David Nadlinger" <code klickverbot.at> writes:
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
Apr 03 2015
next sibling parent "w0rp" <devw0rp gmail.com> writes:
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.)
Apr 03 2015
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 03 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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.
Apr 03 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Apr 03 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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 ;)
Apr 03 2015
next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4 April 2015 at 00:46, weaselcat via Digitalmars-d
<digitalmars-d puremagic.com> 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.
Apr 03 2015
parent Jacob Carlborg <doob me.com> writes:
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
Apr 04 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Apr 03 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
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.
Apr 03 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Apr 03 2015
parent "weaselcat" <weaselcat gmail.com> writes:
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.
Apr 03 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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?
Apr 04 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Apr 04, 2015 at 09:15:01PM +0000, 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.
Apr 04 2015
parent "weaselcat" <weaselcat gmail.com> writes:
On Saturday, 4 April 2015 at 22:05:33 UTC, H. S. Teoh wrote:
 On Sat, Apr 04, 2015 at 09:15:01PM +0000, 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 : )
Apr 04 2015
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"weaselcat"  wrote in message news:rspoyryeklgjychqfyuk 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.
Apr 04 2015
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Sunday, 5 April 2015 at 01:59:21 UTC, Daniel Murphy wrote:
 "weaselcat"  wrote in message 
 news:rspoyryeklgjychqfyuk 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
Apr 05 2015
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5 April 2015 at 13:49, David Nadlinger via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Sunday, 5 April 2015 at 01:59:21 UTC, Daniel Murphy wrote:
 "weaselcat"  wrote in message news:rspoyryeklgjychqfyuk 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.
Apr 05 2015
prev sibling next sibling parent reply "Mike" <none none.com> writes:
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
Apr 03 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Mike"  wrote in message news:ipfucgyjwwjdvmmikqcm 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.
Apr 03 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 04 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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.
Apr 04 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 04 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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.
Apr 04 2015
parent "deadalnix" <deadalnix gmail.com> writes:
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.
Apr 05 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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.
Apr 04 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 04 2015
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
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
Apr 17 2015
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4 April 2015 at 22:48, H. S. Teoh via Digitalmars-d
<digitalmars-d puremagic.com> 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.
Apr 05 2015
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 April 2015 at 12:10, Andrea Fontana via Digitalmars-d
<digitalmars-d puremagic.com> 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?
Apr 03 2015
parent "Andrea Fontana" <mail example.com> writes:
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
 <digitalmars-d puremagic.com> 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
Apr 07 2015
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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. :)
Apr 03 2015
parent "Wyatt" <wyatt.epp gmail.com> writes:
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
Apr 03 2015
prev sibling next sibling parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
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.
Apr 03 2015
next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
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.
Apr 03 2015
parent "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
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.
Apr 03 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 03 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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 ?
Apr 03 2015
parent reply "Kai Nacke" <kai redstar.de> writes:
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
Apr 03 2015
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 April 2015 at 23:59, Kai Nacke via Digitalmars-d
<digitalmars-d puremagic.com> 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.
Apr 03 2015
prev sibling next sibling parent "Elie Morisse" <syniurge gmail.com> writes:
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.
Apr 03 2015
prev sibling next sibling parent "David Nadlinger" <code klickverbot.at> writes:
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
Apr 04 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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?
Apr 04 2015
prev sibling parent reply "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
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
Apr 05 2015
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
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.
Apr 06 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Apr 06 2015
parent reply "Dicebot" <public dicebot.lv> writes:
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.
Apr 07 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Apr 07 2015
prev sibling parent reply "Pierre Krafft" <kpierre+dlang outlook.com> writes:
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.
Apr 07 2015
parent "deadalnix" <deadalnix gmail.com> writes:
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.
Apr 07 2015
prev sibling parent "Dennis Ritchie" <dennis.ritchie mail.ru> writes:
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.
Apr 06 2015
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
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.
Apr 03 2015
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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
Apr 05 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 05 2015
parent reply "Benjamin Thaut" <code benjamin-thaut.de> writes:
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
Apr 05 2015
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5 April 2015 at 21:37, Benjamin Thaut via Digitalmars-d
<digitalmars-d puremagic.com> 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
Apr 05 2015
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Benjamin Thaut"  wrote in message 
news:nkhhmscwnjcrdbihkcsd 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.
Apr 05 2015
parent "Benjamin Thaut" <code benjamin-thaut.de> writes:
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
Apr 06 2015
prev sibling parent "Adam Hawkins" <adam hawkins.io> writes:
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.
Apr 07 2015