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 "\"str\""))
   (mixin (pr "arr"))
   (mixin (pr "(mapcar (lambda (x) (1+ x)) arr)"))
   (mixin (pr "a"))
   (values))
-----
CL-USER> (main)

5

"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