On 02/27/2013 08:05 PM, Andrei Alexandrescu wrote:
> On 2/27/13 7:55 PM, timotheecour wrote:
>>> Use dtoh to initiate and conduct an incremental port of the compiler.
>>
>> How about going the other way around?
>>
>> Using swig to make existing dmd C++ code available to D, so we can
>> advance with a mix of D and C++ code until all of C++ code is converted.
>> I was able to successfully convert large code bases from C++ to D using
>> swig (eg: opencv, sfml, etc). It's the most hands-off way, with very
>> minimal interface file that can recursively make things accessible with
>> fine grained control (for opencv the interface file was < 200 loc).
>
> I think that's a fine idea but I also believe dtoh would be a mightily
> powerful program in and by itself. Once available, it would make
> migration of C++ projects to D possible and easy.
>
> Andrei

Isn't this what swig /does/ though?  What is lacking?

On Thursday, 7 March 2013 at 18:56:05 UTC, Jeff Nowakowski wrote:
> And finally, while I think it's a shame that the reference compiler is proprietary, Debian has a non-free repository that DMD can be placed on as long as the binaries are redistributable.

Are they? I have a vague memory of dmd being non-redistributable.

On Monday, March 11, 2013 10:10:54 Kagamin wrote:
> On Thursday, 7 March 2013 at 18:56:05 UTC, Jeff Nowakowski wrote:
> > And finally, while I think it's a shame that the reference compiler is proprietary, Debian has a non-free repository that DMD can be placed on as long as the binaries are redistributable.
> 
> Are they? I have a vague memory of dmd being non-redistributable.

It requires Walter's permission to redstribute it, but he's likely to give permission if you ask.

- Jonathan M Davis

On Monday, 11 March 2013 at 11:54:29 UTC, Jonathan M Davis wrote:
> On Monday, March 11, 2013 10:10:54 Kagamin wrote:
>> On Thursday, 7 March 2013 at 18:56:05 UTC, Jeff Nowakowski wrote:
>> > And finally, while I think it's a shame that the reference
>> > compiler is proprietary, Debian has a non-free repository that
>> > DMD can be placed on as long as the binaries are
>> > redistributable.
>> 
>> Are they? I have a vague memory of dmd being non-redistributable.
>
> It requires Walter's permission to redstribute it, but he's likely to give
> permission if you ask.
>
> - Jonathan M Davis

That is so problematic for repositories.

"Daniel Murphy" <yebblies@nospamgmail.com> wrote in message news:khfoa6$fm7$1@digitalmars.com...
> "Daniel Murphy" <yebblies@nospamgmail.com> wrote in message news:kgumek$2tp4$1@digitalmars.com...
>> "Zach the Mystic" <reachBUTMINUSTHISzach@gOOGLYmail.com> wrote in message news:pabfuaorrjbljxzrglbv@forum.dlang.org...
>>>>
>>>> Something like this https://github.com/yebblies/magicport2 ?
>>>
>>> Yes! I need to look it over more thoroughly, but I couldn't ask for a better beginning. Can I trust that you'll be a willing part of future discussions on this matter, even if only to play Devil's Advocate?
>>
>> More like a full-blown attempt than a beginning.  I started this a long time ago.
>>
>> There are three parts to it:
>> - c++ parser/d printer, with lots of cheating and special cases
>> - patches to the c++ source
>> - patched version of dmd to build the result (no error on variable
>> shadowing etc)
>>
>> It produces a 70000 line d file which appears to get through 3/7ths of semantic1.  Root needs to be ported, and a cleaner interface to the backend is needed to compile the glue layer.
>>
>
> Update: With the bulk of root converting or ported, and the glue layer stubbed out, I can build dmd from the converted source then lex and parse the source (+druntime headers) again.
>
> The highlight was the dynamically resized struct in root/stringtable. Something went horribly wrong there.

Update: I can now generate the source, then build a frontend from that, then process the frontend's source again with the built compiler.  It also works on the conversion tool, and pulls in a sizeable chunk of druntime and phobos.

Am 11.03.2013 15:20, schrieb Daniel Murphy:
> "Daniel Murphy" <yebblies@nospamgmail.com> wrote in message
> news:khfoa6$fm7$1@digitalmars.com...
>> "Daniel Murphy" <yebblies@nospamgmail.com> wrote in message
>> news:kgumek$2tp4$1@digitalmars.com...
>>> "Zach the Mystic" <reachBUTMINUSTHISzach@gOOGLYmail.com> wrote in message
>>> news:pabfuaorrjbljxzrglbv@forum.dlang.org...
>>>>>
>>>>> Something like this https://github.com/yebblies/magicport2 ?
>>>>
>>>> Yes! I need to look it over more thoroughly, but I couldn't ask for a
>>>> better beginning. Can I trust that you'll be a willing part of future
>>>> discussions on this matter, even if only to play Devil's Advocate?
>>>
>>> More like a full-blown attempt than a beginning.  I started this a long
>>> time ago.
>>>
>>> There are three parts to it:
>>> - c++ parser/d printer, with lots of cheating and special cases
>>> - patches to the c++ source
>>> - patched version of dmd to build the result (no error on variable
>>> shadowing etc)
>>>
>>> It produces a 70000 line d file which appears to get through 3/7ths of
>>> semantic1.  Root needs to be ported, and a cleaner interface to the
>>> backend is needed to compile the glue layer.
>>>
>>
>> Update: With the bulk of root converting or ported, and the glue layer
>> stubbed out, I can build dmd from the converted source then lex and parse
>> the source (+druntime headers) again.
>>
>> The highlight was the dynamically resized struct in root/stringtable.
>> Something went horribly wrong there.
>
> Update: I can now generate the source, then build a frontend from that, then
> process the frontend's source again with the built compiler.  It also works
> on the conversion tool, and pulls in a sizeable chunk of druntime and
> phobos.

do i get it right - you've converted the dmd C++ code with it?

"dennis luehring" <dl.soluz@gmx.net> wrote in message news:khkqug$v57$1@digitalmars.com...
> Am 11.03.2013 15:20, schrieb Daniel Murphy:
>> "Daniel Murphy" <yebblies@nospamgmail.com> wrote in message news:khfoa6$fm7$1@digitalmars.com...
>>> "Daniel Murphy" <yebblies@nospamgmail.com> wrote in message news:kgumek$2tp4$1@digitalmars.com...
>>>> "Zach the Mystic" <reachBUTMINUSTHISzach@gOOGLYmail.com> wrote in
>>>> message
>>>> news:pabfuaorrjbljxzrglbv@forum.dlang.org...
>>>>>>
>>>>>> Something like this https://github.com/yebblies/magicport2 ?
>>>>>
>>>>> Yes! I need to look it over more thoroughly, but I couldn't ask for a better beginning. Can I trust that you'll be a willing part of future discussions on this matter, even if only to play Devil's Advocate?
>>>>
>>>> More like a full-blown attempt than a beginning.  I started this a long time ago.
>>>>
>>>> There are three parts to it:
>>>> - c++ parser/d printer, with lots of cheating and special cases
>>>> - patches to the c++ source
>>>> - patched version of dmd to build the result (no error on variable
>>>> shadowing etc)
>>>>
>>>> It produces a 70000 line d file which appears to get through 3/7ths of semantic1.  Root needs to be ported, and a cleaner interface to the backend is needed to compile the glue layer.
>>>>
>>>
>>> Update: With the bulk of root converting or ported, and the glue layer
>>> stubbed out, I can build dmd from the converted source then lex and
>>> parse
>>> the source (+druntime headers) again.
>>>
>>> The highlight was the dynamically resized struct in root/stringtable. Something went horribly wrong there.
>>
>> Update: I can now generate the source, then build a frontend from that,
>> then
>> process the frontend's source again with the built compiler.  It also
>> works
>> on the conversion tool, and pulls in a sizeable chunk of druntime and
>> phobos.
>
> do i get it right - you've converted the dmd C++ code with it?
>

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

Am 11.03.2013 16:23, schrieb Daniel Murphy:
> "dennis luehring" <dl.soluz@gmx.net> wrote in message
> news:khkqug$v57$1@digitalmars.com...
>> Am 11.03.2013 15:20, schrieb Daniel Murphy:
>>> "Daniel Murphy" <yebblies@nospamgmail.com> wrote in message
>>> news:khfoa6$fm7$1@digitalmars.com...
>>>> "Daniel Murphy" <yebblies@nospamgmail.com> wrote in message
>>>> news:kgumek$2tp4$1@digitalmars.com...
>>>>> "Zach the Mystic" <reachBUTMINUSTHISzach@gOOGLYmail.com> wrote in
>>>>> message
>>>>> news:pabfuaorrjbljxzrglbv@forum.dlang.org...
>>>>>>>
>>>>>>> Something like this https://github.com/yebblies/magicport2 ?
>>>>>>
>>>>>> Yes! I need to look it over more thoroughly, but I couldn't ask for a
>>>>>> better beginning. Can I trust that you'll be a willing part of future
>>>>>> discussions on this matter, even if only to play Devil's Advocate?
>>>>>
>>>>> More like a full-blown attempt than a beginning.  I started this a long
>>>>> time ago.
>>>>>
>>>>> There are three parts to it:
>>>>> - c++ parser/d printer, with lots of cheating and special cases
>>>>> - patches to the c++ source
>>>>> - patched version of dmd to build the result (no error on variable
>>>>> shadowing etc)
>>>>>
>>>>> It produces a 70000 line d file which appears to get through 3/7ths of
>>>>> semantic1.  Root needs to be ported, and a cleaner interface to the
>>>>> backend is needed to compile the glue layer.
>>>>>
>>>>
>>>> Update: With the bulk of root converting or ported, and the glue layer
>>>> stubbed out, I can build dmd from the converted source then lex and
>>>> parse
>>>> the source (+druntime headers) again.
>>>>
>>>> The highlight was the dynamically resized struct in root/stringtable.
>>>> Something went horribly wrong there.
>>>
>>> Update: I can now generate the source, then build a frontend from that,
>>> then
>>> process the frontend's source again with the built compiler.  It also
>>> works
>>> on the conversion tool, and pulls in a sizeable chunk of druntime and
>>> phobos.
>>
>> do i get it right - you've converted the dmd C++ code with it?
>>
>
> 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

but interesting enough to get its own root newsgroup post i think - or
it the "quality"(converted source etc. whatever) too bad

"dennis luehring" <dl.soluz@gmx.net> wrote in message news:khku3t$15ja$1@digitalmars.com...
> Am 11.03.2013 16:23, schrieb Daniel Murphy:
>> "dennis luehring" <dl.soluz@gmx.net> wrote in message news:khkqug$v57$1@digitalmars.com...
>>> Am 11.03.2013 15:20, schrieb Daniel Murphy:
>>>> "Daniel Murphy" <yebblies@nospamgmail.com> wrote in message news:khfoa6$fm7$1@digitalmars.com...
>>>>> "Daniel Murphy" <yebblies@nospamgmail.com> wrote in message news:kgumek$2tp4$1@digitalmars.com...
>>>>>> "Zach the Mystic" <reachBUTMINUSTHISzach@gOOGLYmail.com> wrote in
>>>>>> message
>>>>>> news:pabfuaorrjbljxzrglbv@forum.dlang.org...
>>>>>>>>
>>>>>>>> Something like this https://github.com/yebblies/magicport2 ?
>>>>>>>
>>>>>>> Yes! I need to look it over more thoroughly, but I couldn't ask for
>>>>>>> a
>>>>>>> better beginning. Can I trust that you'll be a willing part of
>>>>>>> future
>>>>>>> discussions on this matter, even if only to play Devil's Advocate?
>>>>>>
>>>>>> More like a full-blown attempt than a beginning.  I started this a
>>>>>> long
>>>>>> time ago.
>>>>>>
>>>>>> There are three parts to it:
>>>>>> - c++ parser/d printer, with lots of cheating and special cases
>>>>>> - patches to the c++ source
>>>>>> - patched version of dmd to build the result (no error on variable
>>>>>> shadowing etc)
>>>>>>
>>>>>> It produces a 70000 line d file which appears to get through 3/7ths
>>>>>> of
>>>>>> semantic1.  Root needs to be ported, and a cleaner interface to the
>>>>>> backend is needed to compile the glue layer.
>>>>>>
>>>>>
>>>>> Update: With the bulk of root converting or ported, and the glue layer
>>>>> stubbed out, I can build dmd from the converted source then lex and
>>>>> parse
>>>>> the source (+druntime headers) again.
>>>>>
>>>>> The highlight was the dynamically resized struct in root/stringtable. Something went horribly wrong there.
>>>>
>>>> Update: I can now generate the source, then build a frontend from that,
>>>> then
>>>> process the frontend's source again with the built compiler.  It also
>>>> works
>>>> on the conversion tool, and pulls in a sizeable chunk of druntime and
>>>> phobos.
>>>
>>> do i get it right - you've converted the dmd C++ code with it?
>>>
>>
>> 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
>
> but interesting enough to get its own root newsgroup post i think - or it the "quality"(converted source etc. whatever) too bad
>
>

I'm planning to when it can do the entire test suite, and all of phobos and druntime.

The code generated is very close to what you would get running it though a (bad) formatter, with comments removed.  I will eventually preserve the comments and improve the formatting.

Performance wise the code is pretty nasty because I'm allocating all OutBuffers on the heap and inserting tracing code.  This will need to be fixed eventually but is fine for checking correctness.

Here's an example conversion: (from PrettyFuncInitExp)

Almost all of the differences are from the primitive pretty-printer.

--------------------------------------------------------
C++ version
--------------------------------------------------------

Expression *PrettyFuncInitExp::resolveLoc(Loc loc, Scope *sc)
{
    FuncDeclaration *fd;
    if (sc->callsc && sc->callsc->func)
        fd = sc->callsc->func;
    else
        fd = sc->func;

    const char *s;
    if (fd)
    {
        const char *funcStr = fd->Dsymbol::toPrettyChars();
        HdrGenState hgs;
        OutBuffer buf;
        functionToCBuffer2((TypeFunction *)fd->type, &buf, &hgs, 0,
funcStr);
        buf.writebyte(0);
        s = (const char *)buf.extractData();
    }
    else
    {
        s = "";
    }

    Expression *e = new StringExp(loc, (char *)s);
    e = e->semantic(sc);
    e = e->castTo(sc, type);
    return e;
}


--------------------------------------------------------
D version
--------------------------------------------------------

    Expression resolveLoc(Loc loc, Scope sc)
    {
    tracein("resolveLoc");
    scope(success) traceout("resolveLoc");
    scope(failure) traceerr("resolveLoc");
    {
        FuncDeclaration fd;
        if ((sc.callsc && sc.callsc.func))
        (fd = sc.callsc.func);
         else (fd = sc.func);
        const(char)* s;
        if (fd)
        {
            const(char)* funcStr = fd.Dsymbol.toPrettyChars();
            HdrGenState hgs;
            OutBuffer buf = new OutBuffer();
            functionToCBuffer2((cast(TypeFunction)fd.type), buf, (&hgs), 0,
funcStr);
            buf.writebyte(0);
            (s = (cast(const(char)*)buf.extractData()));
        }
         else {
            (s = "");
        }
        Expression e = (new StringExp(loc, (cast(char*)s)));
        (e = e.semantic(sc));
        (e = e.castTo(sc, type));
        return e;
    }
    }

On 11 March 2013 16:01, Daniel Murphy <yebblies@nospamgmail.com> wrote:

> "dennis luehring" <dl.soluz@gmx.net> wrote in message news:khku3t$15ja$1@digitalmars.com...
> > Am 11.03.2013 16:23, schrieb Daniel Murphy:
> >> "dennis luehring" <dl.soluz@gmx.net> wrote in message news:khkqug$v57$1@digitalmars.com...
> >>> Am 11.03.2013 15:20, schrieb Daniel Murphy:
> >>>> "Daniel Murphy" <yebblies@nospamgmail.com> wrote in message news:khfoa6$fm7$1@digitalmars.com...
> >>>>> "Daniel Murphy" <yebblies@nospamgmail.com> wrote in message news:kgumek$2tp4$1@digitalmars.com...
> >>>>>> "Zach the Mystic" <reachBUTMINUSTHISzach@gOOGLYmail.com> wrote in
> >>>>>> message
> >>>>>> news:pabfuaorrjbljxzrglbv@forum.dlang.org...
> >>>>>>>>
> >>>>>>>> Something like this https://github.com/yebblies/magicport2 ?
> >>>>>>>
> >>>>>>> Yes! I need to look it over more thoroughly, but I couldn't ask for
> >>>>>>> a
> >>>>>>> better beginning. Can I trust that you'll be a willing part of
> >>>>>>> future
> >>>>>>> discussions on this matter, even if only to play Devil's Advocate?
> >>>>>>
> >>>>>> More like a full-blown attempt than a beginning.  I started this a
> >>>>>> long
> >>>>>> time ago.
> >>>>>>
> >>>>>> There are three parts to it:
> >>>>>> - c++ parser/d printer, with lots of cheating and special cases
> >>>>>> - patches to the c++ source
> >>>>>> - patched version of dmd to build the result (no error on variable
> >>>>>> shadowing etc)
> >>>>>>
> >>>>>> It produces a 70000 line d file which appears to get through 3/7ths
> >>>>>> of
> >>>>>> semantic1.  Root needs to be ported, and a cleaner interface to the
> >>>>>> backend is needed to compile the glue layer.
> >>>>>>
> >>>>>
> >>>>> Update: With the bulk of root converting or ported, and the glue
> layer
> >>>>> stubbed out, I can build dmd from the converted source then lex and
> >>>>> parse
> >>>>> the source (+druntime headers) again.
> >>>>>
> >>>>> The highlight was the dynamically resized struct in root/stringtable. Something went horribly wrong there.
> >>>>
> >>>> Update: I can now generate the source, then build a frontend from
> that,
> >>>> then
> >>>> process the frontend's source again with the built compiler.  It also
> >>>> works
> >>>> on the conversion tool, and pulls in a sizeable chunk of druntime and
> >>>> phobos.
> >>>
> >>> do i get it right - you've converted the dmd C++ code with it?
> >>>
> >>
> >> 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
> >
> > but interesting enough to get its own root newsgroup post i think - or it the "quality"(converted source etc. whatever) too bad
> >
> >
>
> I'm planning to when it can do the entire test suite, and all of phobos and druntime.
>
> The code generated is very close to what you would get running it though a (bad) formatter, with comments removed.  I will eventually preserve the comments and improve the formatting.
>
> Performance wise the code is pretty nasty because I'm allocating all OutBuffers on the heap and inserting tracing code.  This will need to be fixed eventually but is fine for checking correctness.
>
> Here's an example conversion: (from PrettyFuncInitExp)
>
> Almost all of the differences are from the primitive pretty-printer.
>
> --------------------------------------------------------
> C++ version
> --------------------------------------------------------
>
> Expression *PrettyFuncInitExp::resolveLoc(Loc loc, Scope *sc)
> {
>     FuncDeclaration *fd;
>     if (sc->callsc && sc->callsc->func)
>         fd = sc->callsc->func;
>     else
>         fd = sc->func;
>
>     const char *s;
>     if (fd)
>     {
>         const char *funcStr = fd->Dsymbol::toPrettyChars();
>         HdrGenState hgs;
>         OutBuffer buf;
>         functionToCBuffer2((TypeFunction *)fd->type, &buf, &hgs, 0,
> funcStr);
>         buf.writebyte(0);
>         s = (const char *)buf.extractData();
>     }
>     else
>     {
>         s = "";
>     }
>
>     Expression *e = new StringExp(loc, (char *)s);
>     e = e->semantic(sc);
>     e = e->castTo(sc, type);
>     return e;
> }
>
>
> --------------------------------------------------------
> D version
> --------------------------------------------------------
>
>     Expression resolveLoc(Loc loc, Scope sc)
>     {
>     tracein("resolveLoc");
>     scope(success) traceout("resolveLoc");
>     scope(failure) traceerr("resolveLoc");
>     {
>         FuncDeclaration fd;
>         if ((sc.callsc && sc.callsc.func))
>         (fd = sc.callsc.func);
>          else (fd = sc.func);
>         const(char)* s;
>         if (fd)
>         {
>             const(char)* funcStr = fd.Dsymbol.toPrettyChars();
>             HdrGenState hgs;
>             OutBuffer buf = new OutBuffer();
>             functionToCBuffer2((cast(TypeFunction)fd.type), buf, (&hgs), 0,
> funcStr);
>             buf.writebyte(0);
>             (s = (cast(const(char)*)buf.extractData()));
>         }
>          else {
>             (s = "");
>         }
>         Expression e = (new StringExp(loc, (cast(char*)s)));
>         (e = e.semantic(sc));
>         (e = e.castTo(sc, type));
>         return e;
>     }
>     }
>
>
>
(The D conversion seems to think it's lisp).

-- 
Iain Buclaw

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