"Zach the Mystic" <reachzach@gggggmail.com> wrote in message news:rgotiizywwfzkzrdqwkf@forum.dlang.org...
> On Tuesday, 2 April 2013 at 01:09:59 UTC, Nick B wrote:
>> On Sunday, 31 March 2013 at 23:48:31 UTC, Zach the Mystic wrote:
>>> On Sunday, 31 March 2013 at 18:31:33 UTC, Suliman wrote:
>>>> So, what the final decision about porting D to D?
>>>
>>> It's not a "final decision", but Daniel Murphy/yebblies has already made
>>> so much progress with his automatic conversion program,
>>> https://github.com/yebblies/magicport2 that I feel like he carries the
>>> torch right now. Please refer to this discussion:
>>> http://forum.dlang.org/thread/kgn24n$5u8$1@digitalmars.com#post-kgumek:242tp4:241:40digitalmars.com
>>>
>>> Basically:
>>> 1) Daniel seems to have this project under control, and he's way ahead
>>> of anyone else on it.
>>> 2) The current hurdle is the glue layer.
>>> 3) The project is mostly being kept private, presumably because he wants
>>> to come out with a finished product.
>>> 4) All I know is, my gut says YES!
>>
>> Question. Does this imply that once Daniel has finished this task, the code will be frozen and a new major release i.e. D 3.0 announced ?
>>
>> Nick
>
> I'm no expert on that, but I seriously doubt it. D2 is the flagship and will be for a long time, so far as I understand it. Also, Daniel's is an automatic dmd C++ to D conversion program, designed precisely so that the C++ will not need to be frozen, allowing a period where there are both C++ and D frontends. And a new frontend doesn't mean a new language. A "D 3.0" would imply additions and modifications to the language, whereas the topic of this post is changing the compiler.
>

This is what I'm hoping for.  An automatic converter means we never have to freeze development, and the pull requests are never invalidated.  We can even automatically convert the pull requests to D by applying, converting, and diffing.

Because it is automatically kept up to date, the D version and the C++ version can coexist with minimal disruption while the D version is perfected.  At some point we abandon the C++ version and switch all development to the D version.  I would guess it will be several months of having both until we reach this kind of trust in the D version.

Right now I'm up to 'get glue layer working' which needs 'allow C++ static variables, member variables, static functions etc' which (for me) needs 'move win32 C++ mangling into the frontend' which needs 'more free time'. If anyone wants to have a go the plan is to just copy what the linux version does. (cppmangle.c)

> At the same time, perhaps the fact that the leaders have decided now would be a good time to convert the frontend means the language is reaching an important point in its maturity. Still, there's so much known work to do, plus actually extremely fertile ground for new possibilities within D2, that D3 is probably considered both unnecessary and a bit of a distraction at this time. And yet major versions do exist, and there must be some reason they advance, and to have a frontend written in its own language is in some way a milestone, so maybe you're right!

Yeah, D3 is not on the table and may never be.  There is no reason we need to change the numbering when switching to D.

On 4/2/13 9:34 AM, Daniel Murphy wrote:
> Right now I'm up to 'get glue layer working' which needs 'allow C++ static
> variables, member variables, static functions etc' which (for me) needs
> 'move win32 C++ mangling into the frontend' which needs 'more free time'.
> If anyone wants to have a go the plan is to just copy what the linux version
> does. (cppmangle.c)

How did you solve the problem that virtual functions for a given class are spread out in several implementation files?

Andrei

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:kjenl8$1h4h$1@digitalmars.com...
> On 4/2/13 9:34 AM, Daniel Murphy wrote:
>> Right now I'm up to 'get glue layer working' which needs 'allow C++
>> static
>> variables, member variables, static functions etc' which (for me) needs
>> 'move win32 C++ mangling into the frontend' which needs 'more free time'.
>> If anyone wants to have a go the plan is to just copy what the linux
>> version
>> does. (cppmangle.c)
>
> How did you solve the problem that virtual functions for a given class are spread out in several implementation files?
>
> Andrei

I'm not currently preserving file layout, so they are all merged into the class definitions.  It could also be done by generating forwarder functions or changing the language to allow out-of-class function bodies, if keeping the current organization is required.  I'm not a fan of out-of-class bodies but whatever is easiest.

Note that C++ code can still define the function bodies for extern(C++) classes, so there is no problem for the various glue layers.

In the future I would prefer to introduce real visitor objects.  The current approach of virtual functions + state structs leads to a lot of duplication for each pass that needs to walk the ast.  (semantic, toObj, cppMangle, toJson, apply, toChars, toCBuffer, interpret, toMangleBuffer, nothrow, @safe, toDelegate etc)

Does anybody work on port D to D?

https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fgithub.com%2FD-Programming-Language%2Fdmd+%5BDDMD%5D&oq=site%3Ahttps%3A%2F%2Fgithub.com%2FD-Programming-Language%2Fdmd+%5BDDMD%5D

On 15 August 2013 14:02, Suliman <bubnenkoff@gmail.com> wrote:
> Does anybody work on port D to D?

Daniel is the driving force, with myself falling second behind.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"Suliman" <bubnenkoff@gmail.com> wrote in message news:htihsekthjkyhqazuvpc@forum.dlang.org...
> Does anybody work on port D to D?

I've done quite a lot of work on it since dconf.

The progress of making the C++ source 'conversion compatible' is shown here: https://github.com/D-Programming-Language/dmd/pull/1980

The porting program is here: https://github.com/yebblies/magicport2

I am currently able to convert the C++ source to D, then build that into a compiler capable of building itself, druntime, phobos (with unittests), and passing the test suite on win32.

The next step now is to clear the list of patches by integrating them into the compiler or improving the converter.  The large parts of this list are:

- Cleaning up macro uses
- Integrating new extern(C++) support
- Splitting up root.c
- Fixing all narrowing integer conversions
- Removing all variable shadowing
- Correctly mangling templated types
- Finding a clean way to shallow copy classes

Once that is done:

- Enhancing the GC so it can destruct extern(C++) classes (no typeinfo
available)
- Porting to other platforms
- Making the generated source more presentable (eg preserving comments)
- Integration with gdc/ldc

On Thursday, 15 August 2013 at 13:20:15 UTC, Iain Buclaw wrote:
> On 15 August 2013 14:02, Suliman <bubnenkoff@gmail.com> wrote:
>> Does anybody work on port D to D?
>
> Daniel is the driving force, with myself falling second behind.

And FWIW, we at the LDC front are also working on minimizing the diff of our frontend to the upstream DMD source so as to make a possible future transition easier.

David

On 8/15/13 7:10 AM, Daniel Murphy wrote:
> "Suliman" <bubnenkoff@gmail.com> wrote in message
> news:htihsekthjkyhqazuvpc@forum.dlang.org...
>> Does anybody work on port D to D?
>
> I've done quite a lot of work on it since dconf.
>
> The progress of making the C++ source 'conversion compatible' is shown here:
> https://github.com/D-Programming-Language/dmd/pull/1980
>
> The porting program is here: https://github.com/yebblies/magicport2
>
> I am currently able to convert the C++ source to D, then build that into a
> compiler capable of building itself, druntime, phobos (with unittests), and
> passing the test suite on win32.

Did you have a chance to measure the speed of the Double-D compiler?

Andrei

On Thursday, 15 August 2013 at 14:11:02 UTC, Daniel Murphy wrote:
> "Suliman" <bubnenkoff@gmail.com> wrote in message
> news:htihsekthjkyhqazuvpc@forum.dlang.org...
>> Does anybody work on port D to D?
>
> I've done quite a lot of work on it since dconf.
>
> The progress of making the C++ source 'conversion compatible' is shown here:
> https://github.com/D-Programming-Language/dmd/pull/1980
>

So all of those changes were just done by hand, right?  Have the other DDMD labeled pull requests just been you cherry-picking from that branch?

> The porting program is here: https://github.com/yebblies/magicport2
>
> I am currently able to convert the C++ source to D, then build that into a
> compiler capable of building itself, druntime, phobos (with unittests), and
> passing the test suite on win32.
>

So what's left is basically cleaning it all up and fine tuning it so it's good enough for the actual transition?