www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Looking forward to the resurrection ddmd

reply dolive <dolive89 sina.com> writes:
Looking forward to the resurrection ddmd.

thank's all

dolive
Sep 10 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"dolive" <dolive89 sina.com> wrote in message 
news:j4f55s$1r9p$1 digitalmars.com...
 Looking forward to the resurrection ddmd.

Yea, that would be really nice. I'm wondering if maybe the problem is that it needs a different approach. I suspect a big part of the reason it's stagnated is because it's difficult to update to new versions of DMD. I think what's needed is an approach where changes from DMD to DDMD are minimal. Plus a "staged" approach to maximize DDMD's usefulness while it's under development. This is what I have in mind: Stage 1: Create D bindings to access DMD's functionality (ie, tell it to do lexing/parsing/sematic-analysis on some source, and then access the AST). The actual implementation would just be DMD's original C++-based source. Any changes that may be needed in DMD's C++ source can be folded into the official DMD sources on github. Updating to new DMDs would be trivial in most cases. Stage 2: One-by-one, convert sections of the C++ code to D, but *without* D-ifying anything. The goal here is to keep the converted D source as close as possible to the original C++ source. Anything that hasn't been converted yet will just fallback to the original C++ implementation. Updating to new DMDs would hopefully be much easier than it currently is. Stage 3: If/when the core DMD team is ready to switch to D, then DDMD would become the new DMD and the code would finally get D-ified. Or, if DMD stays C++, this D-ification could be done in a separate experimental fork of DDMD (so that the D-ification doesn't get in the way of updating the mainstream DDMD to new DMDs).
Sep 10 2011
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:j4gflo$1c59$1 digitalmars.com...
 I'm wondering if maybe the problem is that it needs a different approach. 
 I suspect a big part of the reason it's stagnated is because it's 
 difficult to update to new versions of DMD.

 I think what's needed is an approach where changes from DMD to DDMD are 
 minimal. Plus a "staged" approach to maximize DDMD's usefulness while it's 
 under development. This is what I have in mind:

I actually had some success with a similar approach in the past, converting parts of the lexer to D (before I got sidetracked fixing dmd bugs). For this to be viable, D needs to be able to call normal C++ functions, C++ non-virtual member functions (including constructors), and access data members of C++ classes.
Sep 10 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-09-11 06:08, Daniel Murphy wrote:
 "Nick Sabalausky"<a a.a>  wrote in message
 news:j4gflo$1c59$1 digitalmars.com...
 I'm wondering if maybe the problem is that it needs a different approach.
 I suspect a big part of the reason it's stagnated is because it's
 difficult to update to new versions of DMD.

 I think what's needed is an approach where changes from DMD to DDMD are
 minimal. Plus a "staged" approach to maximize DDMD's usefulness while it's
 under development. This is what I have in mind:

I actually had some success with a similar approach in the past, converting parts of the lexer to D (before I got sidetracked fixing dmd bugs). For this to be viable, D needs to be able to call normal C++ functions, C++ non-virtual member functions (including constructors), and access data members of C++ classes.

I find this strange: D can call C++ free functions and virtual member functions but it cannot call non-virtual or static member functions. Especially not be able to call static member functions are strange. I thought that free functions and static member functions where implemented in the same way. As far as I know they are implemented in the same way in D. -- /Jacob Carlborg
Sep 11 2011
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:j4i33b$1bc2$1 digitalmars.com...
 I find this strange:

 D can call C++ free functions and virtual member functions but it cannot 
 call non-virtual or static member functions.

 Especially not be able to call static member functions are strange. I 
 thought that free functions and static member functions where implemented 
 in the same way. As far as I know they are implemented in the same way in 
 D.

 -- 
 /Jacob Carlborg

Adding the C++ interfacing capability was well before my time, so I'm not sure how it ended up with the current limitations. Maybe someone else does? I think the issue with static member functions is getting the name mangling/linking to work, this is obviously never a problem for virtual functions, and is simpler for free functions. I'll have a go at this eventually if nobody beats me to it.
Sep 11 2011
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-09-11 17:07, Daniel Murphy wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:j4i33b$1bc2$1 digitalmars.com...
 I find this strange:

 D can call C++ free functions and virtual member functions but it cannot
 call non-virtual or static member functions.

 Especially not be able to call static member functions are strange. I
 thought that free functions and static member functions where implemented
 in the same way. As far as I know they are implemented in the same way in
 D.

 --
 /Jacob Carlborg

Adding the C++ interfacing capability was well before my time, so I'm not sure how it ended up with the current limitations. Maybe someone else does? I think the issue with static member functions is getting the name mangling/linking to work, this is obviously never a problem for virtual functions, and is simpler for free functions. I'll have a go at this eventually if nobody beats me to it.

Virtual functions needs to be mangled as well. The only thing that, at least I know about, differs from a free function and a static member function is the mangling. -- /Jacob Carlborg
Sep 11 2011
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:j4j4al$il3$1 digitalmars.com...
 Virtual functions needs to be mangled as well. The only thing that, at 
 least I know about, differs from a free function and a static member 
 function is the mangling.

 -- 
 /Jacob Carlborg

Virtual functions never need to get linked. The compiler just needs to match up the argument types, calling convention and vtable slot, and because only C++ interfaces are supported in D, the rest just works. There's no need to have virtual functions mangled the same way as in C++ because they're always abstract in D.
Sep 11 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-09-12 03:35, Daniel Murphy wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:j4j4al$il3$1 digitalmars.com...
 Virtual functions needs to be mangled as well. The only thing that, at
 least I know about, differs from a free function and a static member
 function is the mangling.

 --
 /Jacob Carlborg

Virtual functions never need to get linked. The compiler just needs to match up the argument types, calling convention and vtable slot, and because only C++ interfaces are supported in D, the rest just works. There's no need to have virtual functions mangled the same way as in C++ because they're always abstract in D.

Ok, I see. -- /Jacob Carlborg
Sep 12 2011
prev sibling parent Don <nospam nospam.com> writes:
On 11.09.2011 17:07, Daniel Murphy wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:j4i33b$1bc2$1 digitalmars.com...
 I find this strange:

 D can call C++ free functions and virtual member functions but it cannot
 call non-virtual or static member functions.

 Especially not be able to call static member functions are strange. I
 thought that free functions and static member functions where implemented
 in the same way. As far as I know they are implemented in the same way in
 D.

 --
 /Jacob Carlborg

Adding the C++ interfacing capability was well before my time, so I'm not sure how it ended up with the current limitations. Maybe someone else does? I think the issue with static member functions is getting the name mangling/linking to work, this is obviously never a problem for virtual functions, and is simpler for free functions. I'll have a go at this eventually if nobody beats me to it.

things from the patch, but left out the rest. Don't know what the reasoning was.
Sep 12 2011
prev sibling parent dolive <dolive89 sina.com> writes:
Daniel Murphy Wrote:

 "Nick Sabalausky" <a a.a> wrote in message 
 news:j4gflo$1c59$1 digitalmars.com...
 I'm wondering if maybe the problem is that it needs a different approach. 
 I suspect a big part of the reason it's stagnated is because it's 
 difficult to update to new versions of DMD.

 I think what's needed is an approach where changes from DMD to DDMD are 
 minimal. Plus a "staged" approach to maximize DDMD's usefulness while it's 
 under development. This is what I have in mind:

I actually had some success with a similar approach in the past, converting parts of the lexer to D (before I got sidetracked fixing dmd bugs). For this to be viable, D needs to be able to call normal C++ functions, C++ non-virtual member functions (including constructors), and access data members of C++ classes.

How about Progress at ? Look forward to ddmd early resurrection ! thanks all ! dolive
Dec 07 2011
prev sibling parent Trass3r <un known.com> writes:
Am 12.09.2011, 09:07 Uhr, schrieb Don <nospam nospam.com>:
 On 11.09.2011 17:07, Daniel Murphy wrote:
 Adding the C++ interfacing capability was well before my time, so I'm  
 not
 sure how it ended up with the current limitations.  Maybe someone else  
 does?
 I think the issue with static member functions is getting the name
 mangling/linking to work, this is obviously never a problem for virtual
 functions, and is simpler for free functions.  I'll have a go at this
 eventually if nobody beats me to it.

things from the patch, but left out the rest. Don't know what the reasoning was.

Do you mean this one? http://d.puremagic.com/issues/show_bug.cgi?id=4620 I really don't understand why we have to deal with crappy C++ -> C -> D layers if it's that easy to add more C++ interoperability.
Sep 12 2011