"Vladimir Panteleev" <vladimir@thecybershadow.net> wrote in message news:zhdnnukpqrpbydlyvnci@forum.dlang.org...
> On Tuesday, 12 March 2013 at 14:32:05 UTC, Daniel Murphy wrote:
>> Unfortunately it only works because it can make a lot of assumptions
>> about
>> the dmd source, and the subset of C++ it uses.  The same approach can be
>> used with other C++ projects, but not the same tool.
>
> Visual D comes with a "C++ to D" conversion wizard (also usable as a stand-alone command-line tool): http://www.dsource.org/projects/visuald/wiki/Tour/CppConversion

Why didn't I know this existed...

(copied from an e-mail)
Probably I have misunderstood linker error then. This simple snippet fails:

---
import core.stdc.stdio;

template Value(int val)
{
    enum Value = val;
}
// Plain enum Value = 42 works

extern(C)
int main()
{
    printf("%d", Value!42);
    return 0;
}
---
$ dmd -betterC -defaultlib= tmp.d
tmp.o: In function `_D3tmp7__arrayZ':
tmp.d:(.text._D3tmp7__arrayZ+0xd): undefined reference to `_D3tmp12__ModuleInfoZ'
tmp.d:(.text._D3tmp7__arrayZ+0x16): undefined reference to `_d_array_bounds'
tmp.o: In function `_D3tmp8__assertFiZv':
tmp.d:(.text._D3tmp8__assertFiZv+0xd): undefined reference to `_D3tmp12__ModuleInfoZ'
tmp.d:(.text._D3tmp8__assertFiZv+0x16): undefined reference to `_d_assertm'
tmp.o: In function `_D3tmp15__unittest_failFiZv':
tmp.d:(.text._D3tmp15__unittest_failFiZv+0xd): undefined reference to `_D3tmp12__ModuleInfoZ'
tmp.d:(.text._D3tmp15__unittest_failFiZv+0x16): undefined reference to `_d_unittestm'
collect2: error: ld returned 1 exit status
---

What is the issue then?

On Wednesday, 6 March 2013 at 02:26:43 UTC, Chris Cain wrote:
> On Wednesday, 6 March 2013 at 00:25:30 UTC, Adam Wilson wrote:
>> My preference would be to completely replace the back-end with LLVM. Why LLVM?
>
> I would _really_ like to see this, personally. I kind of doubt it
> would happen, but I can dream...
>
> Not just for the reasons you listed, but because it would
> potentially enable the compiler to use LLVM's JIT/interpreter to
> perform CTFE at much higher speeds. There's been several things
> I've wanted to do at compile time that I simply could not because
> CTFE is rather expensive, especially memory-wise, with DMD.
>
> Furthermore, it would also allow some other pretty unique
> features... For instance, Emscripten
> (https://github.com/kripken/emscripten) could be used to enable
> people to write JS code in D (which might be a pretty cool bonus
> for the vibe.d project).
>

It hasn't been updated in awhile but Adam D. Ruppe made a D to JavaScript compiler.

https://github.com/adamdruppe/dtojs

On Monday, 11 March 2013 at 15:23:17 UTC, Daniel Murphy wrote:
> Umm...
>
> C++ compiler source -> my tool -> D source
> D source -> normal dmd -> self-host dmd
> D source -> self-host dmd -> no problems, but only the frontend so no code
> generation
> tool source -> self-host dmd -> same thing

This is great. I'm still trying to invent the wheel, and you're driving a sports car. I've been trying to develop a general purpose text-to-text translation program, but it may be just something I need to do for myself - I need to learn this stuff, but your progress is really encouraging.

Are there any blind spots to your approach right now? It looks like you're destined to get this whole thing covered. I was wondering your thoughts on some of the more sophisticated operations, like converted all of dmd/root to built-in D, OutBuffer -> Appender!string, standard C/C++ libraries (malloc, strcmp, const char* -> string, etc.)? Are these things within grasp, given the incentive and enough time, or farther away than what you've got right now?

"Zach the Mystic" <reachzach@gggggmail.com> wrote in message news:ybbtwnbvxhjcpgbnaoaq@forum.dlang.org...
> On Monday, 11 March 2013 at 15:23:17 UTC, Daniel Murphy wrote:
>> Umm...
>>
>> C++ compiler source -> my tool -> D source
>> D source -> normal dmd -> self-host dmd
>> D source -> self-host dmd -> no problems, but only the frontend so no
>> code
>> generation
>> tool source -> self-host dmd -> same thing
>
> This is great. I'm still trying to invent the wheel, and you're driving a sports car. I've been trying to develop a general purpose text-to-text translation program, but it may be just something I need to do for myself - I need to learn this stuff, but your progress is really encouraging.
>

I did have a couple years head start.

> Are there any blind spots to your approach right now? It looks like you're destined to get this whole thing covered. I was wondering your thoughts on some of the more sophisticated operations, like converted all of dmd/root to built-in D, OutBuffer -> Appender!string, standard C/C++ libraries (malloc, strcmp, const char* -> string, etc.)? Are these things within grasp, given the incentive and enough time, or farther away than what you've got right now?

Most of these are possible, some harder than others.  I'd rather do as little as possible refactoring now, and leave that until after it's all in D.

What I'm up to now is the glue layer needs to be linked into the D code, and for this extern(C++) needs to be upgraded a bit.

So, what the final decision about porting D to D?

On 31 March 2013 19:31, Suliman <evermind@live.ru> wrote:

> So, what the final decision about porting D to D?
>

https://www.youtube.com/watch?v=fpaQpyU_QiM

-- 
Iain Buclaw

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

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!

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

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.

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!