Andrei's Google Talk

Ellis Peters epeters at donthavemail.com
Sun Aug 15 12:03:57 PDT 2010


Don Wrote:

> retard wrote:
> > Sat, 14 Aug 2010 20:24:33 -0500, Yao G. wrote:
> > 
> >> On Sat, 14 Aug 2010 20:20:49 -0500, Mike Parker <aldacron at gmail.com>
> >> wrote:
> >>
> >>
> >>> What prevents you from contributing to the frontend under its current
> >>> license?
> >> Apparently he doesn't like butt-ugly frontends. That's the game breaker
> >> for him  :|
> > 
> > I'm using the same argumentation as Walter here. If I ever contributed 
> > code to the proprietary dmd, I would get sued by a group of lawyers when 
> > contributing code later to some other proprietary / open source compiler. 
> > Even seeing the code might taint my mind. Just like Walter refuses to 
> > read Tango's code to prevent license issues with Phobos.
> > 
> 
> 
> > Dmd's code also has several problems. I don't think it supports multi-
> > core CPUs very well when parsing files. The other issues are: forward 
> > reference bugs, lack of a good internal garbage collector (CTFE & 
> > templates), not well documented (I know nearly nothing about compiler 
> > implementation).
> 
> Those things are all true, but not relevant to ddoc. The ddoc code is 
> just doc.c, which is 58kB in size. You're quite right in saying that 
> something much better could be produced in a week or so of work. The 
> existing ddoc was made in about a week, and I've spent a couple of days 
> fixing some of the most obvious bugs.
> 
> Now that most of the wrong-code and compiler error bugs are fixed, other 
> stuff is becoming higher priority. Still, the fact that there are a 
> thousand open compiler bugs, and only a couple of people working on the 
> compiler is a pretty obvious limitation. Would be great if someone put a 
>   concerted effort into ddoc for a

The advantage of ddoc is that it's simple. That makes it practical for us to use. No need to read long manuals, we can straight away write production quality documents with few macros. Even the idioms are very intuitive unlike @foo and @bar in Javadoc. I don't think the type signatures need better structure in the output. Walter usually foresees what is the most pragmatic solution. Seriously we should kick the retard out of here, he's only trolling with no useful arguments. Moderation.votes++


More information about the Digitalmars-d mailing list