Georg Wrede wrote:
> Walter wrote:
> 
>> "Georg Wrede" <georg.wrede@nospam.org> wrote in message
>> news:41F61D6E.5090507@nospam.org...
>>
>>> The choice of name is arguably more important than any one of the
>>> thousands of single language and design decisions.
>>
>>
>>
>> I agree. I understand the issue with googling "D", but calling D "D" has
>> been effective in interesting the kinds of programmers who would be
>> interested in a reengineering of C++. It started out as a nickname, but it
>> soon became obvious that "D" was the right name for the language.
> 
> 
> Right. Every rule has its exceptions, and D definitely is one. Considering the target audience of D and the origins of D, one could hardly come up with a more suitable name! Also, the kind of guys we want here have to be literate enough to search successfully for single-letter stuff on the net.
> 
> Besides, we want to make D so good that an E never will appear. :-)

FYI: http://dmoz.org/Computers/Programming/Languages/E/
:-)

zwang wrote:

>> Besides, we want to make D so good that an E never will appear. :-)
> 
> FYI: http://dmoz.org/Computers/Programming/Languages/E/
> :-)

http://mumble.net/e/faq.html :

> 1.2. Why is it called 'E'?
> 
> Douglas Crockford writes: 'I chose E because of the progression B, C. I
> observed that there was no language D. I figured it was a bad luck
> letter, so we moved on to E. That 'E' was also the initial of Electric
> Communities was noticed at the time. It also tied in to our development
> of the Unum distributed object model.'

:-)

--anders

In article <ct7m6d$14ll$3@digitaldaemon.com>, Walter says...
>
>
>"Anders F Björklund" <afb@algonet.se> wrote in message news:ct7k6s$12f7$1@digitaldaemon.com...
>> It also varies a lot between project size and D compiler, for instance Mango takes quite a while to compile with GDC...
>
>There was a bug in the compiler I fixed in .110 or .111 that resulted in some very slow compiles for complex projects. Some compiles speeded up by a factor of a thousand or more <g>.
>
>
That's interesting. I've not seen any change in compile times on Win32 with Mango ... it's always been in the region of 2 or 3 seconds for the entire library (on an /old/ machine). There again, I compile everything with a single dmd command -- that is, I don't apply the traditional approach of starting the compiler for each out-of-date file.

Anders' report of slow compiles is the first one I've heard about (for Mango) so I'd be really interested to hear if anyone else has run into similar issues on *nix.

Anyone? How about JJR?

In article <ct7por$18m8$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Walter wrote:
>
>>>It also varies a lot between project size and D compiler, for instance Mango takes quite a while to compile with GDC...
>> 
>> There was a bug in the compiler I fixed in .110 or .111 that resulted in some very slow compiles for complex projects. Some compiles speeded up by a factor of a thousand or more <g>.
>
>Well,
>speed isn't the most important problem - as it fails...
>http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/981
>
>Currently it also has to give all the sources as
>input to the dmd tool, instead of just compiling
>the changed sources (some kind of dependency thing?)
>
>--anders

Yeah; what is it with those thunks?

Kris wrote:

> That's interesting. I've not seen any change in compile times on Win32 with
> Mango ... it's always been in the region of 2 or 3 seconds for the entire
> library (on an /old/ machine).

> Anders' report of slow compiles is the first one I've heard about (for Mango) so
> I'd be really interested to hear if anyone else has run into similar issues on
> *nix. 

Building libmango.a on Mac OS X 10.3 with GDC 0.10 / GCC 3.3.5
takes 60 seconds and then it just fails with the __thunk stuff.
(i.e. the library builds, but the unittest does not link alright)

make -f darwin.make  36.02s user 15.59s system 80% cpu 1:03.84 total

--anders

On Wed, 26 Jan 2005 18:20:13 +0000, Kris wrote:

> In article <ct7m6d$14ll$3@digitaldaemon.com>, Walter says...
>>
>>
>>"Anders F Björklund" <afb@algonet.se> wrote in message news:ct7k6s$12f7$1@digitaldaemon.com...
>>> It also varies a lot between project size and D compiler, for instance Mango takes quite a while to compile with GDC...
>>
>>There was a bug in the compiler I fixed in .110 or .111 that resulted in some very slow compiles for complex projects. Some compiles speeded up by a factor of a thousand or more <g>.
>>
>>
> That's interesting. I've not seen any change in compile times on Win32 with Mango ... it's always been in the region of 2 or 3 seconds for the entire library (on an /old/ machine). There again, I compile everything with a single dmd command -- that is, I don't apply the traditional approach of starting the compiler for each out-of-date file.
> 
> Anders' report of slow compiles is the first one I've heard about (for Mango) so I'd be really interested to hear if anyone else has run into similar issues on *nix.
> 
> Anyone? How about JJR?

Using the default make process, the time to compile and archive the mango library on linux is <= 3 seconds.

Mango 1.1 with DMD 0.111 on Gentoo Linux.

- John R.

On Wed, 26 Jan 2005 19:28:14 +0100, Anders F Björklund wrote:

> Kris wrote:
> 
>> That's interesting. I've not seen any change in compile times on Win32 with Mango ... it's always been in the region of 2 or 3 seconds for the entire library (on an /old/ machine).
> 
>> Anders' report of slow compiles is the first one I've heard about (for Mango) so I'd be really interested to hear if anyone else has run into similar issues on *nix.
> 
> Building libmango.a on Mac OS X 10.3 with GDC 0.10 / GCC 3.3.5 takes 60 seconds and then it just fails with the __thunk stuff. (i.e. the library builds, but the unittest does not link alright)
> 
> make -f darwin.make  36.02s user 15.59s system 80% cpu 1:03.84 total
> 
> --anders

Currently, libmango.a also builds on x86 Gentoo Linux with dmd 0.111.  But it also dies after trying to build and link the unittest.  It looks like the new xml stuff is the issue right now.

So I don't think the problem is in gdc.

- John R.

John Reimer wrote:
> On Wed, 26 Jan 2005 19:28:14 +0100, Anders F Björklund wrote:
> 
> 
>>Kris wrote:
>>
>>
>>>That's interesting. I've not seen any change in compile times on Win32 with
>>>Mango ... it's always been in the region of 2 or 3 seconds for the entire
>>>library (on an /old/ machine).
>>
>>>Anders' report of slow compiles is the first one I've heard about (for Mango) so
>>>I'd be really interested to hear if anyone else has run into similar issues on
>>>*nix. 
>>
>>Building libmango.a on Mac OS X 10.3 with GDC 0.10 / GCC 3.3.5
>>takes 60 seconds and then it just fails with the __thunk stuff.
>>(i.e. the library builds, but the unittest does not link alright)
>>
>>make -f darwin.make  36.02s user 15.59s system 80% cpu 1:03.84 total
>>
>>--anders
> 
> 
> Currently, libmango.a also builds on x86 Gentoo Linux with dmd 0.111.  But
> it also dies after trying to build and link the unittest.  It looks like
> the new xml stuff is the issue right now.
> 
> So I don't think the problem is in gdc.
> 
> - John R.

Yeah... The default Makefile probably doesn't compile any of the XML DOM stuff, but the unittest uses it.  When I release the processor in a few days, I'll update the Makefile.

John

"zwang" <nehzgnaw@gmail.com> wrote in message news:ct8f7q$2217$1@digitaldaemon.com...
> >
> > Besides, we want to make D so good that an E never will appear. :-)
>
> FYI: http://dmoz.org/Computers/Programming/Languages/E/
> :-)

PROC / ENDPROC gak!!! http://www.stud.uni-hamburg.de/users/goldi/aee/beginner/beginner_4.html

In article <pan.2005.01.26.18.37.36.235251@yahoo.com>, John Reimer says...
>
>On Wed, 26 Jan 2005 19:28:14 +0100, Anders F Björklund wrote:
>
>> Kris wrote:
>> 
>>> That's interesting. I've not seen any change in compile times on Win32 with Mango ... it's always been in the region of 2 or 3 seconds for the entire library (on an /old/ machine).
>> 
>>> Anders' report of slow compiles is the first one I've heard about (for Mango) so I'd be really interested to hear if anyone else has run into similar issues on *nix.
>> 
>> Building libmango.a on Mac OS X 10.3 with GDC 0.10 / GCC 3.3.5 takes 60 seconds and then it just fails with the __thunk stuff. (i.e. the library builds, but the unittest does not link alright)
>> 
>> make -f darwin.make  36.02s user 15.59s system 80% cpu 1:03.84 total
>> 
>> --anders
>
>Currently, libmango.a also builds on x86 Gentoo Linux with dmd 0.111.  But it also dies after trying to build and link the unittest.  It looks like the new xml stuff is the issue right now.
>
>So I don't think the problem is in gdc.
>
>- John R.

Thanks John; I'll get that fixed right away. If you use the unittest within the downloaded zipfile, this issue does not occur.

- Kris