www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What kind of app could D be especially suitable for?

reply "Lynn Allan" <l_d_allan adelphia.net> writes:
<alert comment="newbie zealot">


 What I am excited about is D is becoming the premier language to do
 unicode in, by a wide margin. And that's thanks to you guys!


This post from The WB back in 04-Aug has stayed with me. I'm not the
most imaginative person or "brightest bulb in the box", but sometimes
I'm less than clear on what D will eventually be really good for as it
matures and hopefully achieves mind-share and market-share critical
mass.

I think it might be interesting/valuable to solicit ideas on the kinds
of software that D might be especially suitable for.

Another way to think of this question: what kind of projects could we
suggest 'D' as the language of choice for the next major release of
existing software that has outgrown its original 'sandbox'?

For instance, perhaps reverse-engineering of originally niche apps
that were written in interpretative languages (python, php, perl,
ruby), but the app has become very popular and would benefit from a
"real" compiled language for performance and reliability. phpBB? wiki?
SCons?

Another instance; I think D has good-to-great potential to replace
certain Java apps that are slower than molasses.

Specifically, the commerical products JTest and C++Test from Parasoft
come to mind. They are nice for advanced Lint capabilities, but are
practically unusable because they are so sloooooow. It can take
overnight to process a medium size set of source files.

I think the XML tools from Altova (Spy, Authenticate, etc.) are
written in Java, since they ship with .jar files. My limited
experience with them was that they were also slooooooooow.

The Qarbon viewlet application for animated slideshows is written in
Java and is sloooooooow. It can 'grind' for almost an hour on
elaborate scripts.

Seems like quite a few of the Apache XML tools are written in Java?

For now, a problem with reverse engineering apps like the above is the
immaturity of the native D gui's. This might be less of an issue with
the apache xml apps that work in a console mode.

Another type of "candidate for being in D's crosshairs" might be small
to moderate size C libraries. (reverse-engineering of libsndfile and
portaudio come to mind.) D wouldn't necessarily have performance
advantages, but could very well have significant reliability
advantages. These "inner libraries" used by other tools should be
ultra reliable.

Embedded o/s for micro-processors? pda's?

</alert>
Jan 24 2005
next sibling parent "Walter" <newshound digitalmars.com> writes:
"Lynn Allan" <l_d_allan adelphia.net> wrote in message
news:ct3c4s$1nsk$1 digitaldaemon.com...

 I think it might be interesting/valuable to solicit ideas on the kinds
 of software that D might be especially suitable for.


One useful datapoint is that DMDScript in D is smaller and faster than the
same code in C++. I view D as serving the same space as C and C++ do.
Jan 24 2005
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 Embedded o/s for micro-processors? pda's?


Now that someone released a GC-free version of phobos, that may be possible.
Of course, D assumes a flat, 32-bit memory space, which is probably
incompatible with many PDAs (i.e. 68K based Palm-powered handhelds.  the 68K
is a 16-bit processor).  Maybe Pocket PCs, and to a limited extend, newer
Palms would be more viable candidates.

Or, maybe a smaller version of D (D--? ;) ) could be made for smaller
devices, with support for things like 16- and 8-bit code.  The far and near
pointer mess would probably play havoc with some of the features, however
(arrays, classes (thouch classes on an 8-bit microprocessor are..
overkill?), out/inout params).
Jan 24 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 24 Jan 2005 13:33:34 -0500, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 Embedded o/s for micro-processors? pda's?


 Now that someone released a GC-free version of phobos, that may be  
 possible.
 Of course, D assumes a flat, 32-bit memory space, which is probably
 incompatible with many PDAs (i.e. 68K based Palm-powered handhelds.  the  
 68K
 is a 16-bit processor).  Maybe Pocket PCs, and to a limited extend, newer
 Palms would be more viable candidates.

 Or, maybe a smaller version of D (D--? ;) )


Lets call it "Dmin".


 could be made for smaller
 devices, with support for things like 16- and 8-bit code.  The far and  
 near
 pointer mess would probably play havoc with some of the features, however
 (arrays, classes (thouch classes on an 8-bit microprocessor are..
 overkill?), out/inout params).


Regan
Jan 24 2005
parent reply Andy Friesen <andy ikagames.com> writes:
Regan Heath wrote:

 On Mon, 24 Jan 2005 13:33:34 -0500, Jarrett Billingsley  
 <kb3ctd2 yahoo.com> wrote:
 

 Embedded o/s for micro-processors? pda's?



 Now that someone released a GC-free version of phobos, that may be  
 possible.
 Of course, D assumes a flat, 32-bit memory space, which is probably
 incompatible with many PDAs (i.e. 68K based Palm-powered handhelds.  
 the  68K
 is a 16-bit processor).  Maybe Pocket PCs, and to a limited extend, newer
 Palms would be more viable candidates.

 Or, maybe a smaller version of D (D--? ;) )


 
 Lets call it "Dmin".


If we really want to be clever, we could call it "d".

  -- andy
Jan 24 2005
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
 Or, maybe a smaller version of D (D--? ;) )


 Lets call it "Dmin".


 If we really want to be clever, we could call it "d".


This got me thinking about language names in general. And how the 
requisites around a new language have changed in the past two decades.

((Please everybody, I'm not critisicing D here. This is just thoughts 
about languages to be.))   :-)

In the old days, a language name like C was cool. It was easy to 
remember, short, and at the time to-the-point, considering its origins. 
It was easy to spot on book covers and backs, mainly because you could 
print it with a huge font.

Today such a name would be awkward and a hindrance to a rapid spread of 
know-how about it. Why? Well, today information about a language is 
sought on the net, and a name that is inconvenient to search for should 
be avoided. Ideally, a name should give you "all" the pertinent hits, 
and "no" false hits.

Bad examples would be all one-character names (a A B 1 0 Z = :, etc.). 
Good examples (I hope) are zoobyboo, GungkFoo, JavaScript, KoffeeWrite, 
and so on. (We all know the name JavaScript is a bit dishonest, but it 
still is an excellent example here.)

To help search engines differentiate between posted code and discussion 
about the language, there should be a source code convention. Pascal 
used to have (a redundant) compulsory line at the very beginning

program <program name here>

Carrying this idea forward, we could have the compiler enforce that the 
language name appear at the very start. Add to this the major and minor 
version of the language, and we're pretty well off.

KoffeeWrite 2.5: myprog.kw
blabla blabla
blabla
blabla blabla blabla

What exactly is done with the version number depends. If the language is 
a compiled language, then the compiler might enforce and check that the 
number is acceptable. Say, the difference between v2.5 and v2.4 is only 
bug fixes, then 2.4 code would be accepted as-is. Otherwise, any time 
there is a compile time error, the compiler would remind you about a 
possible version problem. If we are ambitious, any newer compiler would 
accept old code and compile it in "compatibility mode".

"Everybody" uses an IDE in the future, and it would write the first line 
for you.

Well, version numbers or not, starting a new language today needs a more 
professional attitude, way beyond just having a good syntax and a bug 
free reference implementation. It's like with cars: in 1910 it was 
enough that you took a barn door and slapped 4 wheels on it, and an 
engine. Today, a new car goes through research and development and 
marketing study -- even before anyone even considers making a clay 
model, let alone a prototype.

If you want success for the language, you have to be diligent, right 
from the start. Philip Morris spent millions to find out the exact shade 
of red to use on packs of Marlboro cigarrettes.

With the number of programming languages growing exponentially (at least 
in the immediately foreseeable future), the scene is like a car market 
where everyone has a self-made "best car in the world", but nobody ever 
hired a salesman or a marketing company.

The choice of name is arguably more important than any one of the 
thousands of single language and design decisions.
Jan 25 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jan 25 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
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. :-)
Jan 26 2005
parent reply zwang <nehzgnaw gmail.com> writes:
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/
:-)
Jan 26 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 26 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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
Jan 26 2005
next sibling parent Daan Oosterveld <daan.oosterveld home.nl> writes:
Walter schreef:

 "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
 
 


I did program E for some years. It already had non-null terminated 
strings like D has, buildin gui toolkit and precompiled headers/modules. 
But yes, it has a hidious syntax. It was free and compiled fast on my 
Amiga. ;)

Daan
Jan 26 2005
prev sibling next sibling parent John Reimer <brk_6502 yahoo.com> writes:
On Wed, 26 Jan 2005 11:00:57 -0800, Walter wrote:


 
 "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



Oooo... that is ugly!
Jan 26 2005
prev sibling parent "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Walter" <newshound digitalmars.com> skrev i en meddelelse 
news:ct8pj2$2f6r$2 digitaldaemon.com...

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


 PROC / ENDPROC gak!!!


It isn't the only language called E. About 10 years ago, I wrote the 
specification for an E language and implemented it. It was a scripting 
language within an application (or application framework). The same piece of 
code would look like:

entry main()
    Print("My first program\n");
end main;

The rationale for "E" was trademark issues and that the application was 
handling EDI (Electronic Data Interchange).

Regards,
Martin
Feb 03 2005
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Andy Friesen wrote:
<snip>

 If we really want to be clever, we could call it "d".


Hmm ... how would that name be pronounced?

And what would its filename extension be?  .D?

Of course, it could spark confusion on file systems that aren't even 
case-retentive.  But at least MS-DOS and Windows 3.x and below are 
16-bit systems, and so the ambiguity is gone (at least as long as you're 
coding/compiling for the local platform).

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jan 26 2005
prev sibling parent Paul Bonser <misterpib gmail.com> writes:
How about D-minor?

Andy Friesen wrote:

 Regan Heath wrote:
 

 On Mon, 24 Jan 2005 13:33:34 -0500, Jarrett Billingsley  
 <kb3ctd2 yahoo.com> wrote:


 Embedded o/s for micro-processors? pda's?




 Now that someone released a GC-free version of phobos, that may be  
 possible.
 Of course, D assumes a flat, 32-bit memory space, which is probably
 incompatible with many PDAs (i.e. 68K based Palm-powered handhelds.  
 the  68K
 is a 16-bit processor).  Maybe Pocket PCs, and to a limited extend, 
 newer
 Palms would be more viable candidates.

 Or, maybe a smaller version of D (D--? ;) )



 Lets call it "Dmin".


 
 
 If we really want to be clever, we could call it "d".
 
  -- andy



-- 
-PIB

--
"C++ also supports the notion of *friends*: cooperative classes that
are permitted to see each other's private parts." - Grady Booch
Jan 30 2005
prev sibling parent "Lynn Allan" <l_d_allan adelphia.net> writes:
 Now that someone released a GC-free version of phobos, that may be


possible.

 Of course, D assumes a flat, 32-bit memory space, which is probably
 incompatible with many PDAs (i.e. 68K based Palm-powered handhelds.


the 68K

 is a 16-bit processor).


FWIW: if memory serves (from the mid-80's), the 68000 was 32-bit
internally, and had 24 address lines, resulting in 16meg usable
memory.
Jan 24 2005
prev sibling next sibling parent Chris Sauls <Chris_member pathlink.com> writes:
In article <ct3c4s$1nsk$1 digitaldaemon.com>, Lynn Allan says...

I think it might be interesting/valuable to solicit ideas on the kinds
of software that D might be especially suitable for.


Well, for example, a good friend of mine (with my help) is writing a BitTorrent
client in D.  Pretty near all clients we've seen have been written either in
Java or Python.  (In fact the "bencode" format used by BT's communications is
from Python.)  Using D I managed to write the modules 'bittorrent.bencode' and
'bittorrent.metainfo' in literally an hour, and they /worked/ on first compile!
(There were a couple of minor issues but they were gone in about ten minutes.)

So yeah... I guess just about anything could be made.  Although, like Walter, I
don't think I could recommend it for small, trivial programs, because of GC and
Phobos overhead.  Maybe in the future we'll have that solved, though (via the
Ares library perhaps?)

-- Chris Sauls
Jan 24 2005
prev sibling next sibling parent Sjoerd van Leent <svanleent wanadoo.nl> writes:
Hi Lynn and others,

I think D has an even bigger potential market as C and C++ have. C and
C++ where designed to be used with a local application. And although 
there are many network uses (CORBA, SOAP or plain Socket), D is capable 
to run over networks by its own and use webinterfaces (Mango and DSP). 
Though these techniques are completely alpha and can't be used right 
now, the potential of the techniques is high.

Due to the garbage collector, which with modern programming languages is 
a good thing (much more stable programs, and not particulary slower, in 
some ocassions even faster), is given the ease of passing objects quite 
simply. Which for the techniques mentioned before, among others, is 
pretty handy (one could use a referential counter or something, but that 
makes code highly unreadable).

Kind Regards,
Sjoerd van Leent

Lynn Allan wrote:

 <alert comment="newbie zealot">
 

What I am excited about is D is becoming the premier language to do
unicode in, by a wide margin. And that's thanks to you guys!


 
 
 This post from The WB back in 04-Aug has stayed with me. I'm not the
 most imaginative person or "brightest bulb in the box", but sometimes
 I'm less than clear on what D will eventually be really good for as it
 matures and hopefully achieves mind-share and market-share critical
 mass.
 
 I think it might be interesting/valuable to solicit ideas on the kinds
 of software that D might be especially suitable for.
 
 Another way to think of this question: what kind of projects could we
 suggest 'D' as the language of choice for the next major release of
 existing software that has outgrown its original 'sandbox'?
 
 For instance, perhaps reverse-engineering of originally niche apps
 that were written in interpretative languages (python, php, perl,
 ruby), but the app has become very popular and would benefit from a
 "real" compiled language for performance and reliability. phpBB? wiki?
 SCons?
 
 Another instance; I think D has good-to-great potential to replace
 certain Java apps that are slower than molasses.
 
 Specifically, the commerical products JTest and C++Test from Parasoft
 come to mind. They are nice for advanced Lint capabilities, but are
 practically unusable because they are so sloooooow. It can take
 overnight to process a medium size set of source files.
 
 I think the XML tools from Altova (Spy, Authenticate, etc.) are
 written in Java, since they ship with .jar files. My limited
 experience with them was that they were also slooooooooow.
 
 The Qarbon viewlet application for animated slideshows is written in
 Java and is sloooooooow. It can 'grind' for almost an hour on
 elaborate scripts.
 
 Seems like quite a few of the Apache XML tools are written in Java?
 
 For now, a problem with reverse engineering apps like the above is the
 immaturity of the native D gui's. This might be less of an issue with
 the apache xml apps that work in a console mode.
 
 Another type of "candidate for being in D's crosshairs" might be small
 to moderate size C libraries. (reverse-engineering of libsndfile and
 portaudio come to mind.) D wouldn't necessarily have performance
 advantages, but could very well have significant reliability
 advantages. These "inner libraries" used by other tools should be
 ultra reliable.
 
 Embedded o/s for micro-processors? pda's?
 
 </alert>
Jan 24 2005
prev sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <ct3c4s$1nsk$1 digitaldaemon.com>, Lynn Allan says...

I think it might be interesting/valuable to solicit ideas on the kinds
of software that D might be especially suitable for.


Okay, I'll bite. :)

- One thing that hasn't been mentioned yet is using D for real-time media
applications.  I think that the low-level control of the GC in D gives it
considerable leverage over other GC'd languages in this arena.  One could
actually boast that D is a language with all of Java's advantages and can still
be used to write a solid video-conferencing app or mp3 player.


- Non-interactive, competition-grade, demonstrations.  I've long since fallen
out of doing this stuff, but are there any demo coders here?  I think D could
give a coder the edge in making non-interactive, realtime demo programs like
those shown at Assembly:

http://www.assembly.org/compos/realtime

Even if it's never shown at a given party, coding to the constraints listed for
these competitions is a great way to show off D's speed and capabilities; not to
mention those of the programmer!


- Games, games, games.  We've seen some inital offerings from the far east in
the form of Warning Forever and Torus Trooper; both of which are great games.
Its amazing what SDL bindings and a nose for fast code can accomplish (both of
the above play nicely on my 400Mhz P2).


- (Future) Sandboxed code.  One of the things that could easily come of the Ares
project is a reduced library that would be perfect for restricted (secure)
programming environments (like DSP for example).  Even a reduced capability
phobos module would go a long way to this end.


- Misc.  I've developed a healthy respect for D's ability to fight platform
bloat (*coughjavacoughdotnetcough*) and bind to practically any library in
existance that's worth using.  To that end, I've put off replacing my existing
machine (the "400Mhz Franken-vunder-box") as the code-compile-test loop is
lightning fast compared to the competition; Its *very* usable at this speed.

- EricAnderton at yahoo
Jan 24 2005
next sibling parent zwang <nehzgnaw gmail.com> writes:
pragma wrote:

 In article <ct3c4s$1nsk$1 digitaldaemon.com>, Lynn Allan says...
 

I think it might be interesting/valuable to solicit ideas on the kinds
of software that D might be especially suitable for.


 
 
 Okay, I'll bite. :)
 
 - One thing that hasn't been mentioned yet is using D for real-time media
 applications.  I think that the low-level control of the GC in D gives it
 considerable leverage over other GC'd languages in this arena.  One could
 actually boast that D is a language with all of Java's advantages and can still
 be used to write a solid video-conferencing app or mp3 player.
 
 
 - Non-interactive, competition-grade, demonstrations.  I've long since fallen
 out of doing this stuff, but are there any demo coders here?  I think D could
 give a coder the edge in making non-interactive, realtime demo programs like
 those shown at Assembly:
 
 http://www.assembly.org/compos/realtime
 
 Even if it's never shown at a given party, coding to the constraints listed for
 these competitions is a great way to show off D's speed and capabilities; not
to
 mention those of the programmer!
 


I used to write a few 64k intros in C++, but I found it hard to meet the 
code size constraint with D because of its statically linked library.
D might help "mega demo" productivity, though.



 
 - Games, games, games.  We've seen some inital offerings from the far east in
 the form of Warning Forever and Torus Trooper; both of which are great games.
 Its amazing what SDL bindings and a nose for fast code can accomplish (both of
 the above play nicely on my 400Mhz P2).
 
 
 - (Future) Sandboxed code.  One of the things that could easily come of the
Ares
 project is a reduced library that would be perfect for restricted (secure)
 programming environments (like DSP for example).  Even a reduced capability
 phobos module would go a long way to this end.
 
 
 - Misc.  I've developed a healthy respect for D's ability to fight platform
 bloat (*coughjavacoughdotnetcough*) and bind to practically any library in
 existance that's worth using.  To that end, I've put off replacing my existing
 machine (the "400Mhz Franken-vunder-box") as the code-compile-test loop is
 lightning fast compared to the competition; Its *very* usable at this speed.
 
 - EricAnderton at yahoo
Jan 24 2005
prev sibling parent reply Carotinho <carotinobg yahoo.it> writes:
Hi!


 - Games, games, games.  We've seen some inital offerings from the far east
 in the form of Warning Forever and Torus Trooper; both of which are great
 games. Its amazing what SDL bindings and a nose for fast code can
 accomplish (both of the above play nicely on my 400Mhz P2).


I'm currently learning to code games with D, but with Allegro. This is one
of my dreams:) I've never found before a language so nice to the
programmer, and still fast and...


 To that end, I've put off replacing my
 existing machine (the "400Mhz Franken-vunder-box") as the
 code-compile-test loop is lightning fast compared to the competition; Its
 *very* usable at this speed.


Yes, this is absolutely wonderful :) I have a P3 500 and compilation is near
real time:)) It looks like an interpreted language:))

Byez!!!

Carotinho
Jan 25 2005
next sibling parent reply h3r3tic <foo bar.baz> writes:
Carotinho wrote:

 Yes, this is absolutely wonderful :) I have a P3 500 and compilation is near
 real time:)) It looks like an interpreted language:))


Yeah... but that's why D is evil. Most programmers love long compile 
times. Why ? Check this out: 
http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=63877
We definitely need something like this in D...
Jan 25 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
h3r3tic wrote:


 Yes, this is absolutely wonderful :) I have a P3 500 and compilation 
 is near real time:)) It looks like an interpreted language:))


 
 Yeah... but that's why D is evil. Most programmers love long compile 
 times.


It also varies a lot between project size and D compiler,
for instance Mango takes quite a while to compile with GDC...

ccache and Make makes most C compilations quite speedy as well.
(http://ccache.samba.org/)

--anders
Jan 26 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"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>.
Jan 26 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 26 2005
parent Kris <Kris_member pathlink.com> writes:
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?
Jan 26 2005
prev sibling parent reply Kris <Kris_member pathlink.com> writes:
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?
Jan 26 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 26 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
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.
Jan 26 2005
next sibling parent John Demme <me teqdruid.com> writes:
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
Jan 26 2005
prev sibling parent reply Kris <Kris_member pathlink.com> writes:
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
Jan 26 2005
parent John Reimer <brk_6502 yahoo.com> writes:
On Wed, 26 Jan 2005 19:10:37 +0000, Kris wrote:


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


No problem.  You must have just modified unittest in the last few minutes;
it now compiles without errors.

Thanks,

John R.
Jan 26 2005
prev sibling parent John Reimer <brk_6502 yahoo.com> writes:
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.
Jan 26 2005
prev sibling parent Paul Bonser <misterpib gmail.com> writes:
h3r3tic wrote:

 Carotinho wrote:
 

 Yes, this is absolutely wonderful :) I have a P3 500 and compilation 
 is near
 real time:)) It looks like an interpreted language:))


 
 
 Yeah... but that's why D is evil. Most programmers love long compile 
 times. Why ? Check this out: 
 http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=63877
 We definitely need something like this in D...



Well dang, I guess I shouldn't have just ordered that Athlon64 and 
pc3200 ram, eh? ... all my compile times are going to drop like crazy. 
And I use ccache and distcc with my other computer ("just" a 1GHz duron).

-- 
-PIB

--
"C++ also supports the notion of *friends*: cooperative classes that
are permitted to see each other's private parts." - Grady Booch
Feb 03 2005
prev sibling next sibling parent "Walter" <newshound digitalmars.com> writes:
"Carotinho" <carotinobg yahoo.it> wrote in message
news:ct6ov6$l0$1 digitaldaemon.com...

 To that end, I've put off replacing my
 existing machine (the "400Mhz Franken-vunder-box") as the
 code-compile-test loop is lightning fast compared to the competition;




Its

 *very* usable at this speed.


 Yes, this is absolutely wonderful :) I have a P3 500 and compilation is


near

 real time:)) It looks like an interpreted language:))


That's one of the reasons I use an old machine to do development on. It
motivates me to keep it running fast.
Jan 25 2005
prev sibling parent reply Nils Hensel <nils.hensel web.de> writes:
Carotinho wrote:

 Hi!
 
 

- Games, games, games.  We've seen some inital offerings from the far east
in the form of Warning Forever and Torus Trooper; both of which are great
games. Its amazing what SDL bindings and a nose for fast code can
accomplish (both of the above play nicely on my 400Mhz P2).


 
 
 I'm currently learning to code games with D, but with Allegro. This is one
 of my dreams:) I've never found before a language so nice to the
 programmer, and still fast and...


Hi,
I want to try the same thing actually. Good to hear that it works well. 
Could you point me to some D binding for the allegro library please?

Regards,
Nils
Jan 27 2005
parent Carotinho <carotinobg yahoo.it> writes:
Hi!

Nils Hensel wrote:


 Hi,
 I want to try the same thing actually. Good to hear that it works well.
 Could you point me to some D binding for the allegro library please?


The binding I use has been written by myself. Up to now it works, but I
admit I've not thorougly tested. Maybe you can help:)
I'm running linux, and I've not managed yet to compile D with Allegro under
Windows, mainly because I don't know how to do the "ALLEGRO_MAIN()" thing.

If you want, I can email you a zip with all the files I use!

Byez:)

Carotinho
Jan 27 2005