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

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.)

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

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 ?

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

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.

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.

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

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 ;)

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.