On 2013-02-28 02:03, John Colvin wrote:
> Could you perhaps detail the process you went through to get opencv to D? It
> would be a big help to me as I'm currently staring down the barrel of having to
> re-implement a chunk of OpenCV in D for a data processing app.

I second that request! :)

On 2013-02-28 08:48, Walter Bright wrote:

> Curiously, there appears to be no copyright/license information.

Should be the same as DMD uses.

-- 
/Jacob Carlborg

On 2013-02-28 11:25, Walter Bright wrote:

> Why? The only point would be to change the license of the front end.

I don't know, I'm not doing it. Possibly reasons:

* Fun
* Learn
* Change the license
* DMD is not written in D
* DMD is not built/usable as a library
* DMD contains a lot of bugs

Although I don't know for sure if they're clean room implementations or not. They are at least not direct translations.

-- 
/Jacob Carlborg

On 2013-02-28 11:45, Andrea Fontana wrote:

> Something like Fabrice Bellard tcc/libtcc? (http://bellard.org/tcc/)
> If you can call dmd using an api, you can write a new range of
> application. Every program could be a custom compiler. And can compile
> and patch itself.

I have no idea about tcc, I was more thinking of like Clang and LLVM.

-- 
/Jacob Carlborg

On 2013-02-28 11:03, deadalnix wrote:

> I don't think that is a good idea.
>
> That will impair GDC and LDC quite a lot. Especially GDC as GCC team
> accept C++ only recently. This mean no inclusion in the official GCC
> collection.
>
> This mean that porting DMD to D and making it the default implementation
> imply to stick with DMD backend (and it isn't open source even if
> almost). Not being open source can really impair D's popularity.
>
> It also prevent to do actual progress on D during the translation
> process. FInally, Denis's ddmd hasn't succeeded.

They could stick with the C++ front end and fold in changes as needed. They can't to direct merges though.

-- 
/Jacob Carlborg

On 2013-02-28 11:27, Martin Nowak wrote:

> Splitting off druntime's GC to also use it for dmd could be a great
> project.

How do you mean. If DMD is written in D it would be using druntime including its GC?

-- 
/Jacob Carlborg

On 2013-02-28 11:35, Maxim Fomin wrote:

> With some kind of magical tool called 'dtoh'? Ok, it can
> translate declarations. But what (maybe who) would rewrite code?

One would translate a single file to D. Then run "dtoh" over that file to get a C/C++ interface to the D file. You can then link the D object file with the rest of the C++ code.

-- 
/Jacob Carlborg

On Thu, Feb 28, 2013 at 03:05:31PM +0100, Jacob Carlborg wrote:
> On 2013-02-28 11:03, deadalnix wrote:
> 
> >I don't think that is a good idea.
> >
> >That will impair GDC and LDC quite a lot. Especially GDC as GCC team accept C++ only recently. This mean no inclusion in the official GCC collection.
> >
> >This mean that porting DMD to D and making it the default implementation imply to stick with DMD backend (and it isn't open source even if almost). Not being open source can really impair D's popularity.
> >
> >It also prevent to do actual progress on D during the translation process. FInally, Denis's ddmd hasn't succeeded.
> 
> They could stick with the C++ front end and fold in changes as needed. They can't to direct merges though.
[...]

This will be a big problem once the front end is completely written in D. The GDC maintainers will have to translate bugfixes to the D code back to the C++ code. In some cases this may not be possible (D-specific features may be used in the fix, which requires non-trivial translation to C++, which is prone to bugs not in the D code). This will be a lot of maintenance work.

This is one of the reasons I suggested using a frozen version of D to write the front end with. That way, we can include the C++ source for that frozen version in GDC, and then bundle the newer D source code with it, so during the bootstrapping process, the GCC scripts first build a working (but older) D compiler from the C++ sources, then use that to compile the newer D source code to produce the final compiler.


T

-- 
The trouble with TCP jokes is that it's like hearing the same joke over and over.

On 2/28/13 4:49 AM, Jacob Carlborg wrote:
> On 2013-02-28 04:49, Walter Bright wrote:
>
>> There's a lot of lore in the original code involving arcana about how
>> things really work. If you refactor and translate at the same time, you
>> don't have an incremental conversion you can run through the test suite
>> at each step.
>
> I interpreted Ary's post as basically doing a clean room implementation.
> Not translate the existing code.

Yes, exactly.

On 2/28/13 1:45 AM, Iain Buclaw wrote:
> Once HEAD is compiled by the previous release (or system D compiler), it
> might be a good practice for HEAD to compile itself too. Then this
> compiler built by HEAD will then build the library.

Do you think there's a risk that bootstrapping causes trouble for gdc?

Andrei