digitalmars.D - Development environment (WAS: generative programming and debugging)
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Oct 19 2011
- Mirko Pilger <pilger cymotec.de> Oct 19 2011
- Piotr Szturmaj <bncrbme jadamspam.pl> Oct 19 2011
- Jacob Carlborg <doob me.com> Oct 19 2011
- Jacob Carlborg <doob me.com> Oct 20 2011
- Jacob Carlborg <doob me.com> Oct 19 2011
- "Marco Leise" <Marco.Leise gmx.de> Oct 19 2011
- Jacob Carlborg <doob me.com> Oct 19 2011
- Jacob Carlborg <doob me.com> Oct 20 2011
- Jacob Carlborg <doob me.com> Oct 20 2011
- Jacob Carlborg <doob me.com> Oct 21 2011
- Jacob Carlborg <doob me.com> Oct 21 2011
- Jacob Carlborg <doob me.com> Oct 22 2011
- Jude Young <10equals2 gmail.com> Oct 19 2011
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Oct 19 2011
- Jude Young <10equals2 gmail.com> Oct 20 2011
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Oct 20 2011
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Oct 20 2011
- "Marco Leise" <Marco.Leise gmx.de> Oct 20 2011
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Oct 21 2011
- "Marco Leise" <Marco.Leise gmx.de> Oct 21 2011
- "Marco Leise" <Marco.Leise gmx.de> Oct 21 2011
I've yet to see a single worthwhile IDE for D. I think it would be a great idea to have a standard reference IDE (just as DMD is the standard reference compiler). These things would be so useful: Inline compile-time ddoc and mixin views would make development process so much easier. Inline compile-time non-ctfe-able code highliting. Automatic import detector, based on visible import paths. On Wed, Oct 19, 2011 at 3:32 PM, Jacob Carlborg <doob me.com> wrote:On 2011-10-19 13:21, Gor Gyolchanyan wrote:This is cool. Unfortunately, descent is a big pain to use for everything else.
Well, it might be worth to just start up eclipse once in a while for case=
like these.On Wed, Oct 19, 2011 at 3:12 PM, Jacob Carlborg<doob me.com> =A0wrote:On 2011-10-19 11:07, Gor Gyolchanyan wrote:Do anybody know a good way to (statically) debug a generated code? Currently it takes lots of effort to determine the place, where the code is being incorrectly generated.
The Eclipse plugin Descent has support for compile time debugging. It also have a compile time view which shows the result of string mixins and template mixins. -- /Jacob Carlborg
-- /Jacob Carlborg
Oct 19 2011
I've yet to see a single worthwhile IDE for D.
http://dsource.org/projects/visuald
Oct 19 2011
Mirko Pilger wrote:I've yet to see a single worthwhile IDE for D.
http://dsource.org/projects/visuald
I'm using it too. I wish the author would move the source repository to github. I think it may then attract more contributors.
Oct 19 2011
On 2011-10-20 02:34, Jude Young wrote:Is Geany not a viable alternative? It seems to support everything that I need out of the box. what do you need that it doesn't do? half asking to see if geany would be useful, half to see what tools other people use. Mirko Pilger wrote: I've yet to see a single worthwhile IDE for D.
Not exactly sure what it does but: * show syntax errors * show semantic errors * show formatted/generated ddoc on hover * go to definition * show result of auto, string and template mixins * autocompletion, something intelligent * generate ddocs * code formatting * building * outline -- /Jacob Carlborg
Oct 19 2011
Jacob Carlborg <doob me.com> On 2011-10-20 09:18, Jude Young wrote:Well, I guess I'm just not used to all the fancy features. =P it does not show syntax errors. I did the lazy mans version, set a button set to compile the current file without outputting anything. It just shows errors. no semantic errors, same as above It doesn't handle ddoc, I wish it did. It does handle go to definition no mixin support that I know of I know it does autocompletion, probably not as smart as you want though. it'll autocomplete any declared or used var or function, if you type the first four letters, but it seems to be only for things in the current file. it other words it won't suggest things in files that you import. it handles building through makefiles (ie, write the file yourself and there's a nice button you can push) It does have an 'scribble' pane, but it's more like a scratchpad you can write notes on, so thats far less than optimal.
That's basically what I can do now with TextMate. -- /Jacob Carlborg
Oct 20 2011
On 2011-10-19 13:40, Gor Gyolchanyan wrote:I've yet to see a single worthwhile IDE for D. I think it would be a great idea to have a standard reference IDE (just as DMD is the standard reference compiler). These things would be so useful: Inline compile-time ddoc and mixin views would make development process so much easier. Inline compile-time non-ctfe-able code highliting. Automatic import detector, based on visible import paths.
Yeah, that would be really nice. -- /Jacob Carlborg
Oct 19 2011
Am 19.10.2011, 13:40 Uhr, schrieb Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>:I've yet to see a single worthwhile IDE for D. I think it would be a great idea to have a standard reference IDE (just as DMD is the standard reference compiler). These things would be so useful: Inline compile-time ddoc and mixin views would make development process so much easier. Inline compile-time non-ctfe-able code highliting. Automatic import detector, based on visible import paths.
Seems like I'm not the only one who thought of an IDE recently that is fast and can give hints on functions. Except I thought of highlighting pureness, safeness and the like by changing the background color slightly. The next thing is all the features of Eclipse that have to do with the code you write or running / debugging. Like regex search and replace, finding references to methods/fields, refactoring, code templates, class outlines, type search, jump to declaration etc. A difficulty for IDEs seems to be the complexity of D's CTFE and return type inference. DDT for example cannot give auto-completion hints on auto variables. That needs to be addressed. I'd also like very much a way to set up multiple targets for a project: - typical debug build - typical release build - unit test build - external launcher (i.e. dump MySQL table structure and generate D import) - run another program that uses my program (through IPC, as a debuggee) - run a DLL host using my library (also debuggable) - cross-compiling (currently x86-32/-64 for DMD) Especially a D frontend written in D would be a good start for a cross-platform IDE and other derived work. Ideally I think it should not be an external program or parse everything in one step. It could be a lot faster if it worked closely together with the editor itself and only updated the syntax tree where the user edited code. Changes in templates/functions/classes have to be propagated to the users of that code.
Oct 19 2011
On 2011-10-19 21:35, Marco Leise wrote:Am 19.10.2011, 13:40 Uhr, schrieb Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>:I've yet to see a single worthwhile IDE for D. I think it would be a great idea to have a standard reference IDE (just as DMD is the standard reference compiler). These things would be so useful: Inline compile-time ddoc and mixin views would make development process so much easier. Inline compile-time non-ctfe-able code highliting. Automatic import detector, based on visible import paths.
Seems like I'm not the only one who thought of an IDE recently that is fast and can give hints on functions. Except I thought of highlighting pureness, safeness and the like by changing the background color slightly. The next thing is all the features of Eclipse that have to do with the code you write or running / debugging. Like regex search and replace, finding references to methods/fields, refactoring, code templates, class outlines, type search, jump to declaration etc. A difficulty for IDEs seems to be the complexity of D's CTFE and return type inference. DDT for example cannot give auto-completion hints on auto variables. That needs to be addressed. I'd also like very much a way to set up multiple targets for a project: - typical debug build - typical release build - unit test build - external launcher (i.e. dump MySQL table structure and generate D import) - run another program that uses my program (through IPC, as a debuggee) - run a DLL host using my library (also debuggable) - cross-compiling (currently x86-32/-64 for DMD) Especially a D frontend written in D would be a good start for a cross-platform IDE and other derived work. Ideally I think it should not be an external program or parse everything in one step. It could be a lot faster if it worked closely together with the editor itself and only updated the syntax tree where the user edited code. Changes in templates/functions/classes have to be propagated to the users of that code.
Yet again, what's needed is a D compiler (or at least a front end) that can be used as a library. -- /Jacob Carlborg
Oct 19 2011
On 2011-10-20 11:38, Gor Gyolchanyan wrote:Not a compiler (we have 3), only a front-end. Preferably in D itself and preferably as modular as possible (e.g. not everyone needs the semantic parser). Provided a good D front-end in D it'll be very easy to make a great IDE, even if it's GUI is bad.
Preferably, at least one of, these compilers should use the front end as well. -- /Jacob Carlborg
Oct 20 2011
On 2011-10-20 22:29, Marco Leise wrote:Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:On 2011-10-20 11:38, Gor Gyolchanyan wrote:Not a compiler (we have 3), only a front-end. Preferably in D itself and preferably as modular as possible (e.g. not everyone needs the semantic parser). Provided a good D front-end in D it'll be very easy to make a great IDE, even if it's GUI is bad.
Preferably, at least one of, these compilers should use the front end as well.
I don't see that happening: A D front end and a C++ backend. Perhaps GCC becomes the stadard D compiler and DMD is translated to D using that ;)
It is possible, have a look at DDMD: http://www.dsource.org/projects/ddmd -- /Jacob Carlborg
Oct 20 2011
On 2011-10-21 09:22, Gor Gyolchanyan wrote:I wouldn't call it D. It looks like C, which smells like D. But the point is good. It's possible to make a C facade to use a C back-end.
As a fist step DDMD is only converted to D with minimal changes. The next step is to make it more D-like when you know everything is working. -- /Jacob Carlborg
Oct 21 2011
On 2011-10-21 10:07, Marco Leise wrote:Am 21.10.2011, 09:22 Uhr, schrieb Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>:I wouldn't call it D. It looks like C, which smells like D. But the point is good. It's possible to make a C facade to use a C back-end. On Fri, Oct 21, 2011 at 10:34 AM, Jacob Carlborg <doob me.com> wrote:On 2011-10-20 22:29, Marco Leise wrote:Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:On 2011-10-20 11:38, Gor Gyolchanyan wrote:Not a compiler (we have 3), only a front-end. Preferably in D itself and preferably as modular as possible (e.g. not everyone needs the semantic parser). Provided a good D front-end in D it'll be very easy to make a great IDE, even if it's GUI is bad.
Preferably, at least one of, these compilers should use the front end as well.
I don't see that happening: A D front end and a C++ backend. Perhaps GCC becomes the stadard D compiler and DMD is translated to D using that ;)
It is possible, have a look at DDMD: http://www.dsource.org/projects/ddmd -- /Jacob Carlborg
I said "D frontend" and "C++ backend", not "D backend". And "one of these [3] compilers" clearly referred to the C++ ones DMD, LDC and GDC. But the point is, that a frontend exists, that compiles as D code and can be the base for a library. Either for continued development on DDMD or an IDE or other tools that need to understand D code, like a online source code browser.
DDMD uses the C++ DMD backend. -- /Jacob Carlborg
Oct 21 2011
On 2011-10-21 20:56, Marco Leise wrote:Am 21.10.2011, 13:50 Uhr, schrieb Jacob Carlborg <doob me.com>:On 2011-10-21 10:07, Marco Leise wrote:Am 21.10.2011, 09:22 Uhr, schrieb Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>:I wouldn't call it D. It looks like C, which smells like D. But the point is good. It's possible to make a C facade to use a C back-end. On Fri, Oct 21, 2011 at 10:34 AM, Jacob Carlborg <doob me.com> wrote:On 2011-10-20 22:29, Marco Leise wrote:Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:On 2011-10-20 11:38, Gor Gyolchanyan wrote:Not a compiler (we have 3), only a front-end. Preferably in D itself and preferably as modular as possible (e.g. not everyone needs the semantic parser). Provided a good D front-end in D it'll be very easy to make a great IDE, even if it's GUI is bad.
Preferably, at least one of, these compilers should use the front end as well.
I don't see that happening: A D front end and a C++ backend. Perhaps GCC becomes the stadard D compiler and DMD is translated to D using that ;)
It is possible, have a look at DDMD: http://www.dsource.org/projects/ddmd -- /Jacob Carlborg
I said "D frontend" and "C++ backend", not "D backend". And "one of these [3] compilers" clearly referred to the C++ ones DMD, LDC and GDC. But the point is, that a frontend exists, that compiles as D code and can be the base for a library. Either for continued development on DDMD or an IDE or other tools that need to understand D code, like a online source code browser.
DDMD uses the C++ DMD backend.
Oh ok, when I clicked on "backend" I saw a long list of *.d files. I didn't know the compatibility between D and C++ was that good :)
I think it's bindings to the C++ backend and other stuff. Have a look at the C++ backend and you can see it's not the C++ backend ported to D: https://github.com/D-Programming-Language/dmd/tree/master/src/backend -- /Jacob Carlborg
Oct 22 2011
--20cf3002583a9b151f04afb01dc0 Content-Type: text/plain; charset=ISO-8859-1 Is Geany not a viable alternative? It seems to support everything that I need out of the box. what do you need that it doesn't do? half asking to see if geany would be useful, half to see what tools other people use. Mirko Pilger wrote:I've yet to see a single worthwhile IDE for D.
--20cf3002583a9b151f04afb01dc0 Content-Type: text/html; charset=ISO-8859-1 Is Geany not a viable alternative?<br><br>It seems to support everything that I need out of the box.<br><br>what do you need that it doesn't do?<br>half asking to see if geany would be useful, half to see what tools other people use. <br> <br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Mirko Pilger wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I've yet to see a single worthwhile IDE for D.<br> </blockquote> <br><br> </blockquote></div></blockquote></div><br> --20cf3002583a9b151f04afb01dc0--
Oct 19 2011
yeah. that sounds great. On Wed, Oct 19, 2011 at 11:35 PM, Marco Leise <Marco.Leise gmx.de> wrote:Am 19.10.2011, 13:40 Uhr, schrieb Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>:I've yet to see a single worthwhile IDE for D. I think it would be a great idea to have a standard reference IDE (just as DMD is the standard reference compiler). These things would be so useful: Inline compile-time ddoc and mixin views would make development process so much easier. Inline compile-time non-ctfe-able code highliting. Automatic import detector, based on visible import paths.
Seems like I'm not the only one who thought of an IDE recently that is fast and can give hints on functions. Except I thought of highlighting pureness, safeness and the like by changing the background color slightly. The next thing is all the features of Eclipse that have to do with the code you write or running / debugging. Like regex search and replace, finding references to methods/fields, refactoring, code templates, class outlines, type search, jump to declaration etc. A difficulty for IDEs seems to be the complexity of D's CTFE and return type inference. DDT for example cannot give auto-completion hints on auto variables. That needs to be addressed. I'd also like very much a way to set up multiple targets for a project: - typical debug build - typical release build - unit test build - external launcher (i.e. dump MySQL table structure and generate D import) - run another program that uses my program (through IPC, as a debuggee) - run a DLL host using my library (also debuggable) - cross-compiling (currently x86-32/-64 for DMD) Especially a D frontend written in D would be a good start for a cross-platform IDE and other derived work. Ideally I think it should not be an external program or parse everything in one step. It could be a lot faster if it worked closely together with the editor itself and only updated the syntax tree where the user edited code. Changes in templates/functions/classes have to be propagated to the users of that code.
Oct 19 2011
--485b392b172029619504afb5c3c2 Content-Type: text/plain; charset=ISO-8859-1 Well, I guess I'm just not used to all the fancy features. =P it does not show syntax errors. I did the lazy mans version, set a button set to compile the current file without outputting anything. It just shows errors. no semantic errors, same as above It doesn't handle ddoc, I wish it did. It does handle go to definition no mixin support that I know of I know it does autocompletion, probably not as smart as you want though. it'll autocomplete any declared or used var or function, if you type the first four letters, but it seems to be only for things in the current file. it other words it won't suggest things in files that you import. it handles building through makefiles (ie, write the file yourself and there's a nice button you can push) It does have an 'scribble' pane, but it's more like a scratchpad you can write notes on, so thats far less than optimal. It also integrates with gdb, but it doesn't let you specify which version. (personal irk I had to work around) I tried DDT, but that was... just not for me. ...And now I'm checking out Code::Blocks again 'cause I can't remember why I disliked it.. No terminal. That was the reason. Not exactly sure what it does but:* show syntax errors * show semantic errors * show formatted/generated ddoc on hover * go to definition * show result of auto, string and template mixins * autocompletion, something intelligent * generate ddocs * code formatting * building * outline -- /Jacob Carlborg
--485b392b172029619504afb5c3c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, I guess I'm just not used to all the fancy features.<br>=3DP<br>i= t does not show syntax errors. I did the lazy mans version, set a button se= t to compile the current file without outputting anything.<br>It just shows= errors.<br> no semantic errors, same as above<br>It doesn't handle ddoc, I wish it = did.<br>It does handle go to definition<br>no mixin support that I know of<= br>I know it does autocompletion, probably not as smart as you want though.= it'll autocomplete any declared or used var or function, if you type t= he first four letters, but it seems to be only for things in the current fi= le. it other words it won't suggest things in files that you import.<br=
e's a nice button you can push)<br>It does have an 'scribble' p= ane, but it's more like a scratchpad you can write notes on, so thats f= ar less than optimal.<br> <br>It also integrates with gdb, but it doesn't let you specify which v= ersion. (personal irk I had to work around)<br><br><br>I tried DDT, but tha= t was... just not for me.<br>...And now I'm checking out Code::Blocks a= gain 'cause I can't remember why I disliked it..<br> No terminal.=A0 That was the reason.<br><br><br><div class=3D"gmail_quote">= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;"> Not exactly sure what it does but:<br> <br> * show syntax errors<br> * show semantic errors<br> * show formatted/generated ddoc on hover<br> * go to definition<br> * show result of auto, string and template mixins<br> * autocompletion, something intelligent<br> * generate ddocs<br> * code formatting<br> * building<br> * outline<br><font color=3D"#888888"> <br> -- <br> /Jacob Carlborg<br> </font></blockquote></div><br> --485b392b172029619504afb5c3c2--
Oct 20 2011
Not a compiler (we have 3), only a front-end. Preferably in D itself and preferably as modular as possible (e.g. not everyone needs the semantic parser). Provided a good D front-end in D it'll be very easy to make a great IDE, even if it's GUI is bad. On Thu, Oct 20, 2011 at 10:20 AM, Jacob Carlborg <doob me.com> wrote:On 2011-10-19 21:35, Marco Leise wrote:Am 19.10.2011, 13:40 Uhr, schrieb Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>:I've yet to see a single worthwhile IDE for D. I think it would be a great idea to have a standard reference IDE (just as DMD is the standard reference compiler). These things would be so useful: Inline compile-time ddoc and mixin views would make development process so much easier. Inline compile-time non-ctfe-able code highliting. Automatic import detector, based on visible import paths.
Seems like I'm not the only one who thought of an IDE recently that is fast and can give hints on functions. Except I thought of highlighting pureness, safeness and the like by changing the background color slightly. The next thing is all the features of Eclipse that have to do with the code you write or running / debugging. Like regex search and replace, finding references to methods/fields, refactoring, code templates, class outlines, type search, jump to declaration etc. A difficulty for IDEs seems to be the complexity of D's CTFE and return type inference. DDT for example cannot give auto-completion hints on auto variables. That needs to be addressed. I'd also like very much a way to set up multiple targets for a project: - typical debug build - typical release build - unit test build - external launcher (i.e. dump MySQL table structure and generate D import) - run another program that uses my program (through IPC, as a debuggee) - run a DLL host using my library (also debuggable) - cross-compiling (currently x86-32/-64 for DMD) Especially a D frontend written in D would be a good start for a cross-platform IDE and other derived work. Ideally I think it should not be an external program or parse everything in one step. It could be a lot faster if it worked closely together with the editor itself and only updated the syntax tree where the user edited code. Changes in templates/functions/classes have to be propagated to the users of that code.
Yet again, what's needed is a D compiler (or at least a front end) that can be used as a library. -- /Jacob Carlborg
Oct 20 2011
Definitely. It would be a standardized good-practice advice for all compilers to use the standard D front-end. This will ensure absence of non-standard shenanigans with the front-end, preventing D from inheriting one of the biggest mistakes of C/C++: non-standard extensions. The pragma statements will provide a way to specify compiler-specific features. Note, that compiler-specific features are not the same as non-standard extensions, at least because they all follow the same syntactic rules. On Thu, Oct 20, 2011 at 3:11 PM, Jacob Carlborg <doob me.com> wrote:On 2011-10-20 11:38, Gor Gyolchanyan wrote:Not a compiler (we have 3), only a front-end. Preferably in D itself and preferably as modular as possible (e.g. not everyone needs the semantic parser). Provided a good D front-end in D it'll be very easy to make a great IDE, even if it's GUI is bad.
Preferably, at least one of, these compilers should use the front end as well. -- /Jacob Carlborg
Oct 20 2011
Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:On 2011-10-20 11:38, Gor Gyolchanyan wrote:Not a compiler (we have 3), only a front-end. Preferably in D itself and preferably as modular as possible (e.g. not everyone needs the semantic parser). Provided a good D front-end in D it'll be very easy to make a great IDE, even if it's GUI is bad.
Preferably, at least one of, these compilers should use the front end as well.
I don't see that happening: A D front end and a C++ backend. Perhaps GCC becomes the stadard D compiler and DMD is translated to D using that ;)
Oct 20 2011
I wouldn't call it D. It looks like C, which smells like D. But the point is good. It's possible to make a C facade to use a C back-end. On Fri, Oct 21, 2011 at 10:34 AM, Jacob Carlborg <doob me.com> wrote:On 2011-10-20 22:29, Marco Leise wrote:Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:On 2011-10-20 11:38, Gor Gyolchanyan wrote:Not a compiler (we have 3), only a front-end. Preferably in D itself and preferably as modular as possible (e.g. not everyone needs the semantic parser). Provided a good D front-end in D it'll be very easy to make a great IDE, even if it's GUI is bad.
Preferably, at least one of, these compilers should use the front end as well.
I don't see that happening: A D front end and a C++ backend. Perhaps GCC becomes the stadard D compiler and DMD is translated to D using that ;)
It is possible, have a look at DDMD: http://www.dsource.org/projects/ddmd -- /Jacob Carlborg
Oct 21 2011
Am 21.10.2011, 09:22 Uhr, schrieb Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>:I wouldn't call it D. It looks like C, which smells like D. But the point is good. It's possible to make a C facade to use a C back-end. On Fri, Oct 21, 2011 at 10:34 AM, Jacob Carlborg <doob me.com> wrote:On 2011-10-20 22:29, Marco Leise wrote:Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:On 2011-10-20 11:38, Gor Gyolchanyan wrote:Not a compiler (we have 3), only a front-end. Preferably in D itself and preferably as modular as possible (e.g. not everyone needs the semantic parser). Provided a good D front-end in D it'll be very easy to make a great IDE, even if it's GUI is bad.
Preferably, at least one of, these compilers should use the front end as well.
I don't see that happening: A D front end and a C++ backend. Perhaps GCC becomes the stadard D compiler and DMD is translated to D using that ;)
It is possible, have a look at DDMD: http://www.dsource.org/projects/ddmd -- /Jacob Carlborg
I said "D frontend" and "C++ backend", not "D backend". And "one of these [3] compilers" clearly referred to the C++ ones DMD, LDC and GDC. But the point is, that a frontend exists, that compiles as D code and can be the base for a library. Either for continued development on DDMD or an IDE or other tools that need to understand D code, like a online source code browser.
Oct 21 2011
Am 21.10.2011, 13:50 Uhr, schrieb Jacob Carlborg <doob me.com>:On 2011-10-21 10:07, Marco Leise wrote:Am 21.10.2011, 09:22 Uhr, schrieb Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>:I wouldn't call it D. It looks like C, which smells like D. But the point is good. It's possible to make a C facade to use a C back-end. On Fri, Oct 21, 2011 at 10:34 AM, Jacob Carlborg <doob me.com> wrote:On 2011-10-20 22:29, Marco Leise wrote:Am 20.10.2011, 13:11 Uhr, schrieb Jacob Carlborg <doob me.com>:On 2011-10-20 11:38, Gor Gyolchanyan wrote:Not a compiler (we have 3), only a front-end. Preferably in D itself and preferably as modular as possible (e.g. not everyone needs the semantic parser). Provided a good D front-end in D it'll be very easy to make a great IDE, even if it's GUI is bad.
Preferably, at least one of, these compilers should use the front end as well.
I don't see that happening: A D front end and a C++ backend. Perhaps GCC becomes the stadard D compiler and DMD is translated to D using that ;)
It is possible, have a look at DDMD: http://www.dsource.org/projects/ddmd -- /Jacob Carlborg
I said "D frontend" and "C++ backend", not "D backend". And "one of these [3] compilers" clearly referred to the C++ ones DMD, LDC and GDC. But the point is, that a frontend exists, that compiles as D code and can be the base for a library. Either for continued development on DDMD or an IDE or other tools that need to understand D code, like a online source code browser.
DDMD uses the C++ DMD backend.
Oh ok, when I clicked on "backend" I saw a long list of *.d files. I didn't know the compatibility between D and C++ was that good :)
Oct 21 2011