www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD source overview?

reply "Nick Sabalausky" <a a.a> writes:
I don't suppose there's any sort of overview-writeup of DMD's source 
anywhere? Particularly from the perspective of replacing the backend? 
Sep 13 2010
next sibling parent Don <nospam nospam.com> writes:
Nick Sabalausky wrote:
 I don't suppose there's any sort of overview-writeup of DMD's source 
 anywhere? Particularly from the perspective of replacing the backend? 
 

Limited, but it's a start: http://www.prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
Sep 13 2010
prev sibling parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Hi Nick!

If you are going to replace dmd's backend, you might want to have a look at
ddmd,
as we have plans to make other backends for it. And of course it is much more
pleasant to work with D rather than C++!
Sep 14 2010
next sibling parent reply BLS <windevguy hotmail.de> writes:
On 14/09/2010 12:15, Eldar Insafutdinov wrote:
 Hi Nick!

 If you are going to replace dmd's backend, you might want to have a look at
ddmd,
 as we have plans to make other backends for it. And of course it is much more
 pleasant to work with D rather than C++!

Hear hear, IMHO ddmd looks atm very c-ish. But heck, D bindings for LLVM 2.7 are also avail, so ..) -- Nick there was/is a dsource project done by Ben Hinkle (he is not on the radar anymore) which is enhancing the dmd frontent with output stubs. hth bjoern
Sep 14 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"BLS" <windevguy hotmail.de> wrote in message 
news:i6ohm1$1n1n$1 digitalmars.com...
 On 14/09/2010 12:15, Eldar Insafutdinov wrote:
 Hi Nick!

 If you are going to replace dmd's backend, you might want to have a look 
 at ddmd,
 as we have plans to make other backends for it. And of course it is much 
 more
 pleasant to work with D rather than C++!

Hear hear, IMHO ddmd looks atm very c-ish. But heck, D bindings for LLVM 2.7 are also avail, so ..) -- Nick there was/is a dsource project done by Ben Hinkle (he is not on the radar anymore) which is enhancing the dmd frontent with output stubs. hth bjoern

I saw that on wiki4d, but the site it linked to seemed to be gone. But I've been looking through 2.048's source from main(), and read that page about DMD's internals on the D wiki, and I think I understand enough now to proceed.
Sep 14 2010
parent reply jcc7 <jccalvarese gmail.com> writes:
== Quote from Nick Sabalausky (a a.a)'s article
 "BLS" <windevguy hotmail.de> wrote in message
 news:i6ohm1$1n1n$1 digitalmars.com...

 Nick there was/is a dsource project done by Ben Hinkle (he is


 on the radar anymore) which is enhancing the dmd frontent with
 output stubs.

 hth bjoern

I saw that on wiki4d, but the site it linked to seemed to be gone. But I've been looking through 2.048's source from main(), and read that page about DMD's internals on the D wiki, and I think I understand enough now to proceed.

(I assume that you're talking about Ben Hinkle's dmdfe project.) I don't know what you mean by "gone". As far as I can tell the project is still there: * Trac: http://www.dsource.org/projects/dmdfe, * forum: http://www.dsource.org/forums/viewforum.php?f=61 It might not be "gone", but it does appear abandoned (the SVN hasn't been updated in over 3 years). Apparently, Gregor created a branch for DMD 2.0 at http://www.dsource.org/projects/dsss/browser/branches/dmdfe-2.0, but it looks like that effort's SVN repository hasn't been updated in a couple years, either. Anyway, this is probably all a moot point as much as DMD (v1 and v2) has evolved since either of these projects have been synced up with Walter's official DMD. Good luck with your project. It sounds interesting. jcc7
Sep 14 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"jcc7" <jccalvarese gmail.com> wrote in message 
news:i6onkv$22ag$1 digitalmars.com...
 == Quote from Nick Sabalausky (a a.a)'s article
 "BLS" <windevguy hotmail.de> wrote in message
 news:i6ohm1$1n1n$1 digitalmars.com...

 Nick there was/is a dsource project done by Ben Hinkle (he is


 on the radar anymore) which is enhancing the dmd frontent with
 output stubs.

 hth bjoern

I saw that on wiki4d, but the site it linked to seemed to be gone. But I've been looking through 2.048's source from main(), and read that page about DMD's internals on the D wiki, and I think I understand enough now to proceed.

(I assume that you're talking about Ben Hinkle's dmdfe project.) I don't know what you mean by "gone". As far as I can tell the project is still there: * Trac: http://www.dsource.org/projects/dmdfe, * forum: http://www.dsource.org/forums/viewforum.php?f=61 It might not be "gone", but it does appear abandoned (the SVN hasn't been updated in over 3 years). Apparently, Gregor created a branch for DMD 2.0 at http://www.dsource.org/projects/dsss/browser/branches/dmdfe-2.0, but it looks like that effort's SVN repository hasn't been updated in a couple years, either.

Ahh, ok. I was looking at the DMDFE listing here: http://prowiki.org/wiki4d/wiki.cgi?GrammarParsers#DMDFrontEndStarterKitDMDFE And it just had a link to a NG announcement posting and a "Project Page" link to: http://home.comcast.net/~benhinkle/dmdfe/ Which automatically redirected to a 404 page. I'll update the Wiki.
 Anyway, this is probably all a moot point as much as DMD (v1 and v2)
 has evolved since either of these projects have been synced up with
 Walter's official DMD.

 Good luck with your project. It sounds interesting.

Thanks. I hope I can pull it off quickly and effectively.
Sep 14 2010
next sibling parent jcc7 <jccalvarese gmail.com> writes:
== Quote from Nick Sabalausky (a a.a)'s article
...
 Ahh, ok. I was looking at the DMDFE listing here:
 http://prowiki.org/wiki4d/wiki.cgi?

 And it just had a link to a NG announcement posting and a "Project

 link to:
 http://home.comcast.net/~benhinkle/dmdfe/
 Which automatically redirected to a 404 page.

Oh, I forgot about that was his website. I'll bet that link went dead years ago.
 I'll update the Wiki.

Thanks!
Sep 14 2010
prev sibling parent reply Justin Johansson <no spam.com> writes:
On 15/09/2010 12:31 PM, Nick Sabalausky wrote:
 Anyway, this is probably all a moot point as much as DMD (v1 and v2)
 has evolved since either of these projects have been synced up with
 Walter's official DMD.

 Good luck with your project. It sounds interesting.

Thanks. I hope I can pull it off quickly and effectively.

So does everyone else; you will be a * Good luck, Justin
Sep 15 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Justin Johansson" <no spam.com> wrote in message 
news:i6qaud$1n62$1 digitalmars.com...
 On 15/09/2010 12:31 PM, Nick Sabalausky wrote:
 Anyway, this is probably all a moot point as much as DMD (v1 and v2)
 has evolved since either of these projects have been synced up with
 Walter's official DMD.

 Good luck with your project. It sounds interesting.

Thanks. I hope I can pull it off quickly and effectively.

So does everyone else; you will be a *

I've always wanted to be a pointer!
Sep 15 2010
parent Juanjo Alvarez <fake fakeemail.com> writes:
On Wed, 15 Sep 2010 15:34:47 -0400, "Nick Sabalausky" <a a.a> wrote:
 So does everyone else; you will be a *


 I've always wanted to be a pointer!

Ok, but Try{ ! to be a void* } :)
Sep 24 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Eldar Insafutdinov" <e.insafutdinov gmail.com> wrote in message 
news:i6ni0q$31jt$1 digitalmars.com...
 Hi Nick!

 If you are going to replace dmd's backend, you might want to have a look 
 at ddmd,
 as we have plans to make other backends for it. And of course it is much 
 more
 pleasant to work with D rather than C++!

Actually I was thinking of doing as much of my backend as possible in D anyway since D and C are supposed to be link-compatible (and since I got really fed up with C/C++ a long time ago). Of course, dmd is C++, not C, so I figure I might need to add a C-based bridge-to-my-backend in the front-end...unless dmd sticks to the subset of C++ that D2 supports linking with? (Anyone know if that's the case?) But you do raise a good point. What's the current state of ddmd's front-end? What I have in mind is to just rip out dmd's current backend stuff entirely, maybe even including the toObjFile and toIR methods, or at least big chunks of them, and replace it all with a PHP-generator. (Yea...I'm fairly determined to be able to do as much of my web dev as possible in D.) So depending on the current level of ddmd's progress, I'm wondering if it might be more practical to just stick with my orignal plan of using dmd and then switch over to ddmd once ddmd is ready. Although, one benefit of using dmd is it would likely make it quicker and easier to merge in changes from new dmd releases.
Sep 14 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Denis Koroskin" <2korden gmail.com> wrote in message 
news:op.vi1hasy7o7cclz korden-pc...
 On Tue, 14 Sep 2010 23:33:37 +0400, Nick Sabalausky <a a.a> wrote:

 But you do raise a good point. What's the current state of ddmd's 
 front-end?

It's at 2.039 atm, and it improves rapidly, e.g. it was at 2.032 about 3 weeks ago.

And the front-end is completely fully-functional?
 What I have in mind is to just rip out dmd's current backend stuff 
 entirely,
 maybe even including the toObjFile and toIR methods, or at least big 
 chunks
 of them, and replace it all with a PHP-generator. (Yea...I'm fairly
 determined to be able to do as much of my web dev as possible in D.) So
 depending on the current level of ddmd's progress, I'm wondering if it 
 might
 be more practical to just stick with my orignal plan of using dmd and 
 then
 switch over to ddmd once ddmd is ready. Although, one benefit of using 
 dmd
 is it would likely make it quicker and easier to merge in changes from 
 new
 dmd releases.

I would recommend against heavy modification of the original code (e.g. getting rid of toIR/toObjFile, be it dmd or ddmd). Use external visitors if possible.

I was deciding between modifying parts of toIR/toObjFile versus just side-stepping them entirely and traversing the tree externally. I guess I'll go with the latter, then :) But one of the reasons I was thinking about outright removing toIR/toObjFile is because: don't they call into the back-end? So if I rip out the back-end, I would think those functions would just break at compile-time anyway. And if proper traversal chnges at all, then I'd need to change my external traversal. At least that's what I was thinking, anyway. Am I misguided on any of this?
 Why would you want to generate PHP anyway? There are FastCGI libraries 
 available for D, and there isn't much that D is missing and PHP has 
 anyway. Everything else is implementable as a library (and contributable 
 to Phobos! ;)

I definitely intend to do D/CGI/FastCGI whenever possible. But sometimes a client may insist on PHP and I may be unable to sway either them or their IT people, or they may be on a host that disallows or frowns on custom CGI, or whatever. Plus, with the project I'm working on right now (currently in Haxe, which gets compiled to PHP), the business guy's intent is to sell it to other groups who are likely to have their own server/web-host, and if I switch from Haxe to D without a way to convert D to PHP then I risk turning away potential buyers (and this is already a limited-domain sort of thing anyway).
Sep 14 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Danny Wilson" <danny decube.net> wrote in message 
news:op.vi4emf1skxpqx4 zenix...
 Op Tue, 14 Sep 2010 21:33:37 +0200 schreef Nick Sabalausky <a a.a>:

 But you do raise a good point. What's the current state of ddmd's 
 front-end?
 What I have in mind is to just rip out dmd's current backend stuff 
 entirely,
 maybe even including the toObjFile and toIR methods, or at least big 
 chunks
 of them, and replace it all with a PHP-generator. (Yea...I'm fairly
 determined to be able to do as much of my web dev as possible in D.)

What?! No haxe output? I would love D -> Haxe...

I actually thought about that, but it seemed like an excess step, and I figured I could leverage my experience creating D->PHP to then do a D->Flash and maybe then D->JS...but...maybe it would be good to start with D->Haxe just to take care of all of them at once, and only then go about eliminating the extra step. What do other people think? If you're interested in D->PHP, or D->Flash, would you have any problem using Haxe as an intermediate step? Do you anticipate other potential users would have a problem with that?
Sep 16 2010
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 14 Sep 2010 23:33:37 +0400, Nick Sabalausky <a a.a> wrote:

 "Eldar Insafutdinov" <e.insafutdinov gmail.com> wrote in message
 news:i6ni0q$31jt$1 digitalmars.com...
 Hi Nick!

 If you are going to replace dmd's backend, you might want to have a look
 at ddmd,
 as we have plans to make other backends for it. And of course it is much
 more
 pleasant to work with D rather than C++!

Actually I was thinking of doing as much of my backend as possible in D anyway since D and C are supposed to be link-compatible (and since I got really fed up with C/C++ a long time ago). Of course, dmd is C++, not C, so I figure I might need to add a C-based bridge-to-my-backend in the front-end...unless dmd sticks to the subset of C++ that D2 supports linking with? (Anyone know if that's the case?)

dmd2 supports some of the C++, but it is mostly limited to free functions and virtual member functions. D also has no direct mapping for C/C++ "long" type so some proxy functions might be required. Better than nothing, anyway.
 But you do raise a good point. What's the current state of ddmd's  
 front-end?

It's at 2.039 atm, and it improves rapidly, e.g. it was at 2.032 about 3 weeks ago. I don't really think you need the most up to date version to begin with.
 What I have in mind is to just rip out dmd's current backend stuff  
 entirely,
 maybe even including the toObjFile and toIR methods, or at least big  
 chunks
 of them, and replace it all with a PHP-generator. (Yea...I'm fairly
 determined to be able to do as much of my web dev as possible in D.) So
 depending on the current level of ddmd's progress, I'm wondering if it  
 might
 be more practical to just stick with my orignal plan of using dmd and  
 then
 switch over to ddmd once ddmd is ready. Although, one benefit of using  
 dmd
 is it would likely make it quicker and easier to merge in changes from  
 new
 dmd releases.

I would recommend against heavy modification of the original code (e.g. getting rid of toIR/toObjFile, be it dmd or ddmd). Use external visitors if possible. Why would you want to generate PHP anyway? There are FastCGI libraries available for D, and there isn't much that D is missing and PHP has anyway. Everything else is implementable as a library (and contributable to Phobos! ;)
Sep 14 2010
prev sibling next sibling parent "Danny Wilson" <danny decube.net> writes:
Op Tue, 14 Sep 2010 21:33:37 +0200 schreef Nick Sabalausky <a a.a>:

 But you do raise a good point. What's the current state of ddmd's  
 front-end?
 What I have in mind is to just rip out dmd's current backend stuff  
 entirely,
 maybe even including the toObjFile and toIR methods, or at least big  
 chunks
 of them, and replace it all with a PHP-generator. (Yea...I'm fairly
 determined to be able to do as much of my web dev as possible in D.)

What?! No haxe output? I would love D -> Haxe...
Sep 16 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Eldar Insafutdinov" <e.insafutdinov gmail.com> wrote in message 
news:i6ni0q$31jt$1 digitalmars.com...
 Hi Nick!

 If you are going to replace dmd's backend, you might want to have a look 
 at ddmd,
 as we have plans to make other backends for it. And of course it is much 
 more
 pleasant to work with D rather than C++!

I'm having trouble building DDMD: http://www.dsource.org/forums/viewtopic.php?t=5620
Sep 16 2010