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--? ;) )



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/


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

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

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

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

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;


 *very* usable at this speed.

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

 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