• dolive (3/3) Sep 10 2011 Looking forward to the resurrection ddmd.
• Nick Sabalausky (25/26) Sep 10 2011 Yea, that would be really nice.
• Daniel Murphy (7/13) Sep 10 2011 I actually had some success with a similar approach in the past, convert...
• Jacob Carlborg (10/24) Sep 11 2011 I find this strange:
• Daniel Murphy (8/17) Sep 11 2011 Adding the C++ interfacing capability was well before my time, so I'm no...
• Jacob Carlborg (6/26) Sep 11 2011 Virtual functions needs to be mangled as well. The only thing that, at
• Daniel Murphy (7/12) Sep 11 2011 Virtual functions never need to get linked. The compiler just needs to
• Jacob Carlborg (4/17) Sep 12 2011 Ok, I see.
• Don (4/24) Sep 12 2011 There's a patch in bugzilla which implements it. Walter used a couple of...
• Trass3r (5/19) Sep 12 2011 Do you mean this one?
• dolive (4/21) Dec 07 2011 How about Progress at ? Look forward to ddmd early resurrection !

dolive <dolive89 sina.com> writes:

Looking forward to the resurrection ddmd.

thank's all

dolive

"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).

"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. 

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

"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. 

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

"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. 

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

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.

There's a patch in bugzilla which implements it. Walter used a couple of 
things from the patch, but left out the rest. Don't know what the 
reasoning was.

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.

 There's a patch in bugzilla which implements it. Walter used a couple of  
 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.

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