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

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

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

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.

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.

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

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.

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.

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.