Nice work.  #617 in particular is very welcome.  As a general comment for future releases, is there any chance that a short description could be added to tickets when they are closed describing the resolution?  It would save a lot of questions when releases occur.


Sean

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
>
> GDC has fallen behind and could use some TLC.

I hope I'm not stepping on any toes by saying this, but GDC seems like a sinking ship to me.  Almost all of the issues we have with Tango concern GDC codegen or install problems. At this point I'm very much hoping that LLVMDC or the other D compiler project (dyld?) can supplant GDC.  In fact, I think the LLVMDC folks have been asking for help to get some issues sorted out?


Sean

"Sean Kelly" <sean@invisibleduck.org> wrote in message news:g3dtv7$1g0q$1@digitalmars.com...
> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>>
>> GDC has fallen behind and could use some TLC.
>
> I hope I'm not stepping on any toes by saying this, but GDC seems like a sinking ship to me.  Almost all of the issues we have with Tango concern GDC codegen or install problems. At this point I'm very much hoping that LLVMDC or the other D compiler project (dyld?) can supplant GDC.  In fact, I think the LLVMDC folks have been asking for help to get some issues sorted out?

I like what LLVMDC is doing but I don't think using the DMDFE in *yet another* compiler is the best idea.  It's time that D had a bootstrapped compiler and that the DMDFE had some competition.

As for "dyld" I think you're thinking of Dil.  I was trying to help with Dil but with all the other projects and real-life responsibilities, I just don't have the time.

Jarrett Billingsley wrote:
> "Sean Kelly" <sean@invisibleduck.org> wrote in message news:g3dtv7$1g0q$1@digitalmars.com...
>> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>>> GDC has fallen behind and could use some TLC.
>> I hope I'm not stepping on any toes by saying this, but GDC
>> seems like a sinking ship to me.  Almost all of the issues
>> we have with Tango concern GDC codegen or install problems.
>> At this point I'm very much hoping that LLVMDC or the other
>> D compiler project (dyld?) can supplant GDC.  In fact, I
>> think the LLVMDC folks have been asking for help to get
>> some issues sorted out?
> 
> I like what LLVMDC is doing but I don't think using the DMDFE in *yet another* compiler is the best idea.  It's time that D had a bootstrapped compiler and that the DMDFE had some competition.
> 
> As for "dyld" I think you're thinking of Dil.  I was trying to help with Dil but with all the other projects and real-life responsibilities, I just don't have the time. 
> 
> 

We could certainly use some help over at LLVMDC :) The project has come pretty far in the last months, with beginning inline asm support, dstress regressions testing and generally a lot of bugfixes. However there's still a few things to do before we're there.

Mainly exception handling and some codegen issues.

Exception handling is a tricky issue. The LLVM support is there, but it needs someone to look at it, willing to submit patches to the LLVM developers so we can get the exception tables we need (and want)!

Regarding code generation, for the most part, it's complete. However there are some subtle problems that I have yet to track down. The most critical one being a crash on GC collection.
I've been spend the last weeks on improving symbolic debugging information to make these issues easier to track down. Any help in this regard would be extremely appreciated. So far my debugging sessions have been mostly fruitless in locating the true trouble spots :/

As to having a D compiler in D, I would love that. If there had been a usable D frontend in D when I started considering LLVMDC I would have used that for sure. However my knowledge on compilers etc was basically non-existing back then, and I was mostly interested in the code generation part.

I can say that I've wished I wasn't coding in C++ and DMDFE sources _many_ times during this project...

Oh well, just thought I'd chime in here since LLVMDC could definitely use some more testers/developers :)

Tomas

http://www.dsource.org/projects/llvmdc

Tomas Lindquist Olsen Wrote:

> Jarrett Billingsley wrote:
> > "Sean Kelly" <sean@invisibleduck.org> wrote in message news:g3dtv7$1g0q$1@digitalmars.com...
> >> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
> >>> GDC has fallen behind and could use some TLC.
> >> I hope I'm not stepping on any toes by saying this, but GDC seems like a sinking ship to me.  Almost all of the issues we have with Tango concern GDC codegen or install problems. At this point I'm very much hoping that LLVMDC or the other D compiler project (dyld?) can supplant GDC.  In fact, I think the LLVMDC folks have been asking for help to get some issues sorted out?
> > 
> > I like what LLVMDC is doing but I don't think using the DMDFE in *yet another* compiler is the best idea.  It's time that D had a bootstrapped compiler and that the DMDFE had some competition.
> > 
> > As for "dyld" I think you're thinking of Dil.  I was trying to help with Dil but with all the other projects and real-life responsibilities, I just don't have the time.
> > 
> > 
> 
> We could certainly use some help over at LLVMDC :) The project has come pretty far in the last months, with beginning inline asm support, dstress regressions testing and generally a lot of bugfixes. However there's still a few things to do before we're there.
> 
> Mainly exception handling and some codegen issues.
> 
> Exception handling is a tricky issue. The LLVM support is there, but it needs someone to look at it, willing to submit patches to the LLVM developers so we can get the exception tables we need (and want)!
> 
> Regarding code generation, for the most part, it's complete. However there are some subtle problems that I have yet to track down. The most critical one being a crash on GC collection. I've been spend the last weeks on improving symbolic debugging information to make these issues easier to track down. Any help in this regard would be extremely appreciated. So far my debugging sessions have been mostly fruitless in locating the true trouble spots :/
> 
> As to having a D compiler in D, I would love that. If there had been a usable D frontend in D when I started considering LLVMDC I would have used that for sure. However my knowledge on compilers etc was basically non-existing back then, and I was mostly interested in the code generation part.
> 
> I can say that I've wished I wasn't coding in C++ and DMDFE sources _many_ times during this project...
> 
> Oh well, just thought I'd chime in here since LLVMDC could definitely use some more testers/developers :)
> 
> Tomas
> 
> http://www.dsource.org/projects/llvmdc

How pluggable is LLVMDC? For example, if it uses the visitor pattern &
just public interfaces,it might be possible to replace the DMD classes
with wrappers around classes generated from another front-end
(maybe even a D one with a C go-between... sounds complex, but I
might be willing to do that part).

Tomas Lindquist Olsen:
> As to having a D compiler in D, I would love that.

I think eventually creating such compiler can be an interesting thing to do.
But what D are you talking about? D 1.x? D 2.x? Or a possible cross between the two?

Bye,
bearophile

Reply to Jarrett,

> "Sean Kelly" <sean@invisibleduck.org> wrote in message
> news:g3dtv7$1g0q$1@digitalmars.com...
> 
>> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> 
>>> GDC has fallen behind and could use some TLC.
>>> 
>> I hope I'm not stepping on any toes by saying this, but GDC seems
>> like a sinking ship to me.  Almost all of the issues we have with
>> Tango concern GDC codegen or install problems. At this point I'm very
>> much hoping that LLVMDC or the other D compiler project (dyld?) can
>> supplant GDC.  In fact, I think the LLVMDC folks have been asking for
>> help to get some issues sorted out?
>> 
> I like what LLVMDC is doing but I don't think using the DMDFE in *yet
> another* compiler is the best idea.  It's time that D had a
> bootstrapped compiler and that the DMDFE had some competition.
> 

That is actually the motivating factor behind dparse. I'm writing it as the parser generator for a D front end in D. At this point I have a lexer (that is almost correct) and a framework for extracting the d grammar from the doc files as well as dparse (which is currently getting a major overhaul and soaking up most of my free time)

Robert Fraser wrote:
> Jason House wrote:
>> Walter Bright wrote:
>>
>>> Some new stuff to make writing templates easier.
>>>
>>> http://www.digitalmars.com/d/1.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.1.031.zip
>>>
>>> http://www.digitalmars.com/d/2.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.2.015.zip
>>
>> Why is "alias" required when specifying a template parameter?  It seems like
>> the most accepting and general case.  Why wouldn't it be the default?
> 
> Really? I have never had a use for an alias parameter (although I guess most types could work as alias parameters) except using an un-speced trick with regards to their name mangling. They seem way to permissive.

One great example of alias parameters is when you want to pass another template name as a parameter.  You can build a foreach() template, operating over a Tuple, which passes each element in the Tuple into some other template.

Jarrett Billingsley wrote:
> It's time that D had a bootstrapped compiler and that the DMDFE had
> some competition.

I would love this too. A bootstrapped compiler is like the ultimate statement from a developer that he thinks his product is mature enough that even he himself uses it. I think when D has achieved this goal, it is finally adult. :)

LLAP,
Sascha

Walter Bright schrieb:
> Some new stuff to make writing templates easier.
> 
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.031.zip
> 
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.015.zip

what are difference between Template Constraints
and static asserts?