www.digitalmars.com         C & C++   DMDScript  

D - Reality check.

reply larry cowan <larry_member pathlink.com> writes:
A few "reality-check" questions and suggestions:

`1.  Is this language and this website ready to entertain a 10X to 100X jump in
traffic - bugs, questions/bugs, questions/info, argumentation about features,
etc by next summer?

2.  I think the language is generally well-defined, but I would hate to have it
lock-in upward compatibility as a requirement yet.

3.  Is there any direct support for Walter for bugfixes and feature enhancements
to handle a lot of yelping would-be users?

4.  Should the phobos limitations be dealt with immediately?  How about startng
multiple libraries beyond just phobos to classify, accept, distribute user
submissions?  They should have varying degrees of stability required for
inclusion, and therefore "officialness".  Incidentally, phobos MUST be split
into basic and OS-dependent libraries, or linux and Solaris and MacOS and ...
are going to become a quick hell.  I have tried to research this back a bit, but
I don't see any benefit to mixing basic and OS-dependent stuff in a single
library except that it has been easier to just maintain a single lib.  This is
not likely to be the case any more. 

4.  There should be a drop point other than this list (or email to Walter) for
contributions of fixes, doc-changes, compiler addins, library addins,
specialized libraries or programs.  If it's not standardized as a method now, a
whole crop of supporting sites with conflicting versions of the same things may
well arise.  This would not show D well to potential new users, and ALL
companies will want "the official versions" - pissing off all concerned.  CVS
has been mentioned, as SourceForge or other - doesn't matter where, Mars or
elsewhere, but the process needs a home.  More than it needs bosses, Lars, but
that will be needed too - hopefully as welcoming and non-authoritarian as
possible.  We need knowledgeable people in control, but ones with the time (not
me, I'm afraid) to keep things moving well.  Hopefully not too much "process" or
red-tape - at least for a while yet.

5.  There probably should be a feature requests vs. status list somewhere
centralized and accessible.   Bugzilla possibly, or a Wiki with some locked
pages as well as open ones, or ???  Would be nice if something similar for bugs
vs. fixes status.  The traffic on these will likely not be handled well by the
message list, and anyway it's hard to see what has already been proposed or
submitted, and what the response was.  Having a central status viewing point
does not prevent us from requesting a post to the message list about new entries
and/or discussions there.

6.  The news-group stuff should be pursued, but I agree completely that it's a
not-until-full-status-can-be-attained thing.

7.  I hate formality, but love appropriate support for appropriate processes.
It's a fine line between doing what is needed and establishing unnecessary
rules.  Let's keep this as open, fair, and productive as possible.

-larry
Feb 06 2004
next sibling parent "Achilleas Margaritis" <axilmar b-online.gr> writes:
D should have 100% source code compatibility between different operating
systems, like Java. Implementation and O/S details must be hidden under the
libraries. This is what is the major C++ problem. Having to write once, run
everywhere (or rather, compile everywhere in D's case) is what made Java a
huge success (and the sheer amount of existing libraries).

"larry cowan" <larry_member pathlink.com> wrote in message
news:c00vhs$24aq$1 digitaldaemon.com...
 A few "reality-check" questions and suggestions:

 `1.  Is this language and this website ready to entertain a 10X to 100X

 traffic - bugs, questions/bugs, questions/info, argumentation about

 etc by next summer?

 2.  I think the language is generally well-defined, but I would hate to

 lock-in upward compatibility as a requirement yet.

 3.  Is there any direct support for Walter for bugfixes and feature

 to handle a lot of yelping would-be users?

 4.  Should the phobos limitations be dealt with immediately?  How about

 multiple libraries beyond just phobos to classify, accept, distribute user
 submissions?  They should have varying degrees of stability required for
 inclusion, and therefore "officialness".  Incidentally, phobos MUST be

 into basic and OS-dependent libraries, or linux and Solaris and MacOS and

 are going to become a quick hell.  I have tried to research this back a

 I don't see any benefit to mixing basic and OS-dependent stuff in a single
 library except that it has been easier to just maintain a single lib.

 not likely to be the case any more.

 4.  There should be a drop point other than this list (or email to Walter)

 contributions of fixes, doc-changes, compiler addins, library addins,
 specialized libraries or programs.  If it's not standardized as a method

 whole crop of supporting sites with conflicting versions of the same

 well arise.  This would not show D well to potential new users, and ALL
 companies will want "the official versions" - pissing off all concerned.

 has been mentioned, as SourceForge or other - doesn't matter where, Mars

 elsewhere, but the process needs a home.  More than it needs bosses, Lars,

 that will be needed too - hopefully as welcoming and non-authoritarian as
 possible.  We need knowledgeable people in control, but ones with the time

 me, I'm afraid) to keep things moving well.  Hopefully not too much

 red-tape - at least for a while yet.

 5.  There probably should be a feature requests vs. status list somewhere
 centralized and accessible.   Bugzilla possibly, or a Wiki with some

 pages as well as open ones, or ???  Would be nice if something similar for

 vs. fixes status.  The traffic on these will likely not be handled well by

 message list, and anyway it's hard to see what has already been proposed

 submitted, and what the response was.  Having a central status viewing

 does not prevent us from requesting a post to the message list about new

 and/or discussions there.

 6.  The news-group stuff should be pursued, but I agree completely that

 not-until-full-status-can-be-attained thing.

 7.  I hate formality, but love appropriate support for appropriate

 It's a fine line between doing what is needed and establishing unnecessary
 rules.  Let's keep this as open, fair, and productive as possible.

 -larry

Feb 06 2004
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"larry cowan" <larry_member pathlink.com> wrote in message
news:c00vhs$24aq$1 digitaldaemon.com...
 A few "reality-check" questions and suggestions:

 `1.  Is this language and this website ready to entertain a 10X to 100X

 traffic - bugs, questions/bugs, questions/info, argumentation about

 etc by next summer?

Yes. It's done fine even during two slashdottings. Jan Knepper's company hosts the server, which has survived viral attacks, slashdottings, power failures, and at least one assault from the 7th dimension. Rumor has it that during the last slashdotting, the glow from the data pipe feeding it turned night into day.
 2.  I think the language is generally well-defined, but I would hate to

 lock-in upward compatibility as a requirement yet.

1.0 is going to happen shortly.
 3.  Is there any direct support for Walter for bugfixes and feature

 to handle a lot of yelping would-be users?

Not sure what you mean here.
 4.  Should the phobos limitations be dealt with immediately?  How about

 multiple libraries beyond just phobos to classify, accept, distribute user
 submissions?  They should have varying degrees of stability required for
 inclusion, and therefore "officialness".  Incidentally, phobos MUST be

 into basic and OS-dependent libraries, or linux and Solaris and MacOS and

 are going to become a quick hell.  I have tried to research this back a

 I don't see any benefit to mixing basic and OS-dependent stuff in a single
 library except that it has been easier to just maintain a single lib.

 not likely to be the case any more.

 4.  There should be a drop point other than this list (or email to Walter)

 contributions of fixes, doc-changes, compiler addins, library addins,
 specialized libraries or programs.  If it's not standardized as a method

 whole crop of supporting sites with conflicting versions of the same

 well arise.  This would not show D well to potential new users, and ALL
 companies will want "the official versions" - pissing off all concerned.

 has been mentioned, as SourceForge or other - doesn't matter where, Mars

 elsewhere, but the process needs a home.  More than it needs bosses, Lars,

 that will be needed too - hopefully as welcoming and non-authoritarian as
 possible.  We need knowledgeable people in control, but ones with the time

 me, I'm afraid) to keep things moving well.  Hopefully not too much

 red-tape - at least for a while yet.

 5.  There probably should be a feature requests vs. status list somewhere
 centralized and accessible.   Bugzilla possibly, or a Wiki with some

 pages as well as open ones, or ???  Would be nice if something similar for

 vs. fixes status.  The traffic on these will likely not be handled well by

 message list, and anyway it's hard to see what has already been proposed

 submitted, and what the response was.  Having a central status viewing

 does not prevent us from requesting a post to the message list about new

 and/or discussions there.

 6.  The news-group stuff should be pursued, but I agree completely that

 not-until-full-status-can-be-attained thing.

 7.  I hate formality, but love appropriate support for appropriate

 It's a fine line between doing what is needed and establishing unnecessary
 rules.  Let's keep this as open, fair, and productive as possible.

Something like that will have to be done in the fugure. The current process, while a bit chaotic and random, seems to be serving reasonably well at the moment.
Feb 06 2004
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
You bring up some important points. Reply embedded...

larry cowan wrote:
 A few "reality-check" questions and suggestions:
 
 `1.  Is this language and this website ready to entertain a 10X to 100X jump in
 traffic - bugs, questions/bugs, questions/info, argumentation about features,
 etc by next summer?

I hope so. It seems like there's been a lot of see-how-I-made-the-compiler-fail messages recently. I think these posts are made in good faith. When I first started following this newsgroup many, many months ago, I got the impression that many of the posters didn't actually try out the compiler. There was a lot of discussion about which features would be included in the ultimate programming languge. Now, people are actually trying to do things in D. So we post more messages trying to help Walter squash bugs by showing weaknesses in the compiler. Fortunately, this newsgroup is basically troll-free. Sometimes there's a disagreement about how much the compiler should hold the programmer's hand, but there are a lot of knowledgeable folks around here who want D to succeed. And I think newbies are treated pretty well.
 2.  I think the language is generally well-defined, but I would hate to have it
 lock-in upward compatibility as a requirement yet.

You probably need bring up your specific crticisms ASAP if you want Walter to slow down (or back up). I've already brought up my specific issues with D.
 3.  Is there any direct support for Walter for bugfixes and feature
enhancements
 to handle a lot of yelping would-be users?

He sometimes replies that he'll fix stuff. When he does fix it, he replies to the bug author (and sometimes the newsgroup) that it's fixed. Walter would rather spend time improving D that talking about how he's going to improve D.
 4.  Should the phobos limitations be dealt with immediately?  How about startng
 multiple libraries beyond just phobos to classify, accept, distribute user
 submissions?  They should have varying degrees of stability required for
 inclusion, and therefore "officialness".  Incidentally, phobos MUST be split
 into basic and OS-dependent libraries, or linux and Solaris and MacOS and ...
 are going to become a quick hell.  I have tried to research this back a bit,
but
 I don't see any benefit to mixing basic and OS-dependent stuff in a single
 library except that it has been easier to just maintain a single lib.  This is
 not likely to be the case any more. 

I disaggree. It's one lib of source code, but it's compiled twice. One of the goals of D is to be cross-platform. It's hard to have a strong cross-platform library if all of the OS-dependent stuff is removed. Really, what would be left of phobos? Just std.string?
 4.  There should be a drop point other than this list (or email to Walter) for
 contributions of fixes, doc-changes, compiler addins, library addins,
 specialized libraries or programs.  If it's not standardized as a method now, a
 whole crop of supporting sites with conflicting versions of the same things may
 well arise.  This would not show D well to potential new users, and ALL
 companies will want "the official versions" - pissing off all concerned.  CVS
 has been mentioned, as SourceForge or other - doesn't matter where, Mars or
 elsewhere, but the process needs a home.  More than it needs bosses, Lars, but
 that will be needed too - hopefully as welcoming and non-authoritarian as
 possible.  We need knowledgeable people in control, but ones with the time (not
 me, I'm afraid) to keep things moving well.  Hopefully not too much "process"
or
 red-tape - at least for a while yet.

This is a weakness in the state of D right now. I think an even more pressing problem is all of the "stale" code out there (e.g. it worked great with DMD 0.69, but won't even compile since phobos got re-arranged in DMD 0.75). We probably should include a version number and date when we upload code to a website (so if we fall behind with D updates at least a person can tell before he downloads the whole thing).
 5.  There probably should be a feature requests vs. status list somewhere
 centralized and accessible.   Bugzilla possibly, or a Wiki with some locked
 pages as well as open ones, or ???  Would be nice if something similar for bugs
 vs. fixes status.  The traffic on these will likely not be handled well by the
 message list, and anyway it's hard to see what has already been proposed or
 submitted, and what the response was.  Having a central status viewing point
 does not prevent us from requesting a post to the message list about new
entries
 and/or discussions there.

I think Bugzilla would be great. I think Walter has some concerns that the Anti-D Militia would make announcements like "look how many unresolved bugs has! Oh, the horror!" (When in reality, their favorite language has many bugs, but their vendor sweeps all the bugs underneath the rug.) There's already a Wiki page set up (it's all open) relating to requested features: http://www.wikiservice.at/d/wiki.cgi?FeatureRequestList It's basically a list of some common (and not-so-common) requests with a link to the newsgroup post where it was requested. I've put some similiar pages on the Wiki for topics that come up repeatedly so that we don't necessarily have the same discussions over and over again. It's a Wiki, so anyone and everyone is encouraged to expand and revise these pages to improve them.
 6.  The news-group stuff should be pursued, but I agree completely that it's a
 not-until-full-status-can-be-attained thing.

The world needs news:comp.lang.d.
 7.  I hate formality, but love appropriate support for appropriate processes.
 It's a fine line between doing what is needed and establishing unnecessary
 rules.  Let's keep this as open, fair, and productive as possible.

Yes.
 
 -larry
 
 

-- Justin http://jcc_7.tripod.com/d/
Feb 06 2004
next sibling parent reply "C" <dont respond.com> writes:
 I think Bugzilla would be great. I think Walter has some concerns that
 the Anti-D Militia would make announcements like "look how many
 unresolved bugs has! Oh, the horror!" (When in reality, their favorite
 language has many bugs, but their vendor sweeps all the bugs underneath
 the rug.)

So true ... and most times they dont even think its a bug just a language restriction ( or a "Thats a poor design" , when most likely , their language is incapable of implementing it , and they cant see past their own noses ) In my D advocacy , ive run into so many people who just refuse to try anything new or keep an open mind , its sad and depressing. There arguing against me , never even having tried the language ... , I tell them to just try it they'll love it , but they just flat refuse. So sad. C "J C Calvarese" <jcc7 cox.net> wrote in message news:c01fje$31d7$1 digitaldaemon.com...
 You bring up some important points. Reply embedded...

 larry cowan wrote:
 A few "reality-check" questions and suggestions:

 `1.  Is this language and this website ready to entertain a 10X to 100X


 traffic - bugs, questions/bugs, questions/info, argumentation about


 etc by next summer?

I hope so. It seems like there's been a lot of see-how-I-made-the-compiler-fail messages recently. I think these posts are made in good faith. When I first started following this newsgroup many, many months ago, I got the impression that many of the posters didn't actually try out the compiler. There was a lot of discussion about which features would be included in the ultimate programming languge. Now, people are actually trying to do things in D. So we post more messages trying to help Walter squash bugs by showing weaknesses in the compiler. Fortunately, this newsgroup is basically troll-free. Sometimes there's a disagreement about how much the compiler should hold the programmer's hand, but there are a lot of knowledgeable folks around here who want D to succeed. And I think newbies are treated pretty well.
 2.  I think the language is generally well-defined, but I would hate to


 lock-in upward compatibility as a requirement yet.

You probably need bring up your specific crticisms ASAP if you want Walter to slow down (or back up). I've already brought up my specific issues with D.
 3.  Is there any direct support for Walter for bugfixes and feature


 to handle a lot of yelping would-be users?

He sometimes replies that he'll fix stuff. When he does fix it, he replies to the bug author (and sometimes the newsgroup) that it's fixed. Walter would rather spend time improving D that talking about how he's going to improve D.
 4.  Should the phobos limitations be dealt with immediately?  How about


 multiple libraries beyond just phobos to classify, accept, distribute


 submissions?  They should have varying degrees of stability required for
 inclusion, and therefore "officialness".  Incidentally, phobos MUST be


 into basic and OS-dependent libraries, or linux and Solaris and MacOS


 are going to become a quick hell.  I have tried to research this back a


 I don't see any benefit to mixing basic and OS-dependent stuff in a


 library except that it has been easier to just maintain a single lib.


 not likely to be the case any more.

I disaggree. It's one lib of source code, but it's compiled twice. One of the goals of D is to be cross-platform. It's hard to have a strong cross-platform library if all of the OS-dependent stuff is removed. Really, what would be left of phobos? Just std.string?
 4.  There should be a drop point other than this list (or email to


 contributions of fixes, doc-changes, compiler addins, library addins,
 specialized libraries or programs.  If it's not standardized as a method


 whole crop of supporting sites with conflicting versions of the same


 well arise.  This would not show D well to potential new users, and ALL
 companies will want "the official versions" - pissing off all concerned.


 has been mentioned, as SourceForge or other - doesn't matter where, Mars


 elsewhere, but the process needs a home.  More than it needs bosses,


 that will be needed too - hopefully as welcoming and non-authoritarian


 possible.  We need knowledgeable people in control, but ones with the


 me, I'm afraid) to keep things moving well.  Hopefully not too much


 red-tape - at least for a while yet.

This is a weakness in the state of D right now. I think an even more pressing problem is all of the "stale" code out there (e.g. it worked great with DMD 0.69, but won't even compile since phobos got re-arranged in DMD 0.75). We probably should include a version number and date when we upload code to a website (so if we fall behind with D updates at least a person can tell before he downloads the whole thing).
 5.  There probably should be a feature requests vs. status list


 centralized and accessible.   Bugzilla possibly, or a Wiki with some


 pages as well as open ones, or ???  Would be nice if something similar


 vs. fixes status.  The traffic on these will likely not be handled well


 message list, and anyway it's hard to see what has already been proposed


 submitted, and what the response was.  Having a central status viewing


 does not prevent us from requesting a post to the message list about new


 and/or discussions there.

I think Bugzilla would be great. I think Walter has some concerns that the Anti-D Militia would make announcements like "look how many unresolved bugs has! Oh, the horror!" (When in reality, their favorite language has many bugs, but their vendor sweeps all the bugs underneath the rug.) There's already a Wiki page set up (it's all open) relating to requested features: http://www.wikiservice.at/d/wiki.cgi?FeatureRequestList It's basically a list of some common (and not-so-common) requests with a link to the newsgroup post where it was requested. I've put some similiar pages on the Wiki for topics that come up repeatedly so that we don't necessarily have the same discussions over and over again. It's a Wiki, so anyone and everyone is encouraged to expand and revise these pages to improve them.
 6.  The news-group stuff should be pursued, but I agree completely that


 not-until-full-status-can-be-attained thing.

The world needs news:comp.lang.d.
 7.  I hate formality, but love appropriate support for appropriate


 It's a fine line between doing what is needed and establishing


 rules.  Let's keep this as open, fair, and productive as possible.

Yes.
 -larry

-- Justin http://jcc_7.tripod.com/d/

Feb 06 2004
next sibling parent "Andres Rodriguez" <rodriguez ai.sri.com> writes:
Nevertheless I think nothing beats open-ness.  Let vendors have a rug,
they can afford it.  An open project like D cannot.


"C" <dont respond.com> wrote in message
news:c01g0d$tr$1 digitaldaemon.com...
 I think Bugzilla would be great. I think Walter has some concerns that
 the Anti-D Militia would make announcements like "look how many
 unresolved bugs has! Oh, the horror!" (When in reality, their favorite
 language has many bugs, but their vendor sweeps all the bugs underneath
 the rug.)

So true ... and most times they dont even think its a bug just a language restriction ( or a "Thats a poor design" , when most likely , their

 is incapable of implementing it , and they cant see past their own noses )
 In my D advocacy , ive run into so many people who just refuse to try
 anything new or keep an open mind , its sad and depressing.  There arguing
 against me , never even having tried the language ... , I tell them to

 try it they'll love it , but they just flat refuse.  So sad.

Feb 06 2004
prev sibling next sibling parent reply Sean Kelly <sean ffwd.cx> writes:
C wrote:
 
 So true ... and most times they dont even think its a bug just a language
 restriction ( or a "Thats a poor design" , when most likely , their language
 is incapable of implementing it , and they cant see past their own noses )
 In my D advocacy , ive run into so many people who just refuse to try
 anything new or keep an open mind , its sad and depressing.  There arguing
 against me , never even having tried the language ... , I tell them to just
 try it they'll love it , but they just flat refuse.  So sad.

I just heard about D a few days ago (thanks to a thread Walter is in on the MS STL newsgroup) so I'm still getting up to speed on the language, but on paper it seems like the language I *wish* C++ were. If people discount D out of hand it's probably because they're inexperienced, in which case perhaps they'll come around eventually. For D to become a true alternative to C++ for me though, it's going to need to scale to handle enterprise-level issues. Multiplexed i/o, better thread support, etc. I was going to work on this a bit for Boost but I may do it here instead :p Sean
Feb 06 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean ffwd.cx> wrote in message
news:c01mhe$d5u$1 digitaldaemon.com...
 C wrote:
 So true ... and most times they dont even think its a bug just a


 restriction ( or a "Thats a poor design" , when most likely , their


 is incapable of implementing it , and they cant see past their own


 In my D advocacy , ive run into so many people who just refuse to try
 anything new or keep an open mind , its sad and depressing.  There


 against me , never even having tried the language ... , I tell them to


 try it they'll love it , but they just flat refuse.  So sad.

I just heard about D a few days ago (thanks to a thread Walter is in on the MS STL newsgroup) so I'm still getting up to speed on the language, but on paper it seems like the language I *wish* C++ were. If people discount D out of hand it's probably because they're inexperienced, in which case perhaps they'll come around eventually.

I'm a simple fellow, and that used to incline me to think that C++ was the undisputed best language. I've just written a book called "Imperfect C++", whose title was more an ironic aside than heartfelt when I started it. Out the other side, I still think it's the current best language, but I now see it as much less perfect looking than I had expected to going into it. Anyway, still being a simple fellow, my new simple rule is that anyone who thinks that any one technology/language/operating-system/whatever is always best is a bit of a dill. :) In any case, playing around with lots of different languages is far more fun than being stuck in a rut with one. It also opens your eyes to new things that you can do with your existing ones. (I invented a mechanism for providing space&speed efficienct properties in C++; Chapter 35 of the "Imperfect C++" <G>) Anyhoo, that's enough blatant self-aggrandisement for one posting. Now to address your other issues ...
 For D to become a
 true alternative to C++ for me though, it's going to need to scale to
 handle enterprise-level issues.  Multiplexed i/o, better thread support,
 etc.  I was going to work on this a bit for Boost but I may do it here
 instead :p

Please do. I'd love to help out here and there if you get into IO Completion ports. Love those guys! (There's one technology in which MS can genuinely say that Win32 is superior to UNIX. It may be the only one ...) And yes, the threading needs a real strong broom, but it's all doable. Please do make some contributions. At the moment Phobos is missing in several areas, so there's plenty of scope for immortality. Cheers -- Matthew Wilson Director, Synesis Software (www.synesis.com.au) STLSoft moderator (http://www.stlsoft.org) Contributing editor, C/C++ Users Journal (www.synesis.com.au/articles.html#columns) -----------------------------------------------------
Feb 06 2004
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"Sean Kelly" <sean ffwd.cx> wrote in message
news:c01mhe$d5u$1 digitaldaemon.com...
 I just heard about D a few days ago (thanks to a thread Walter is in on
 the MS STL newsgroup)

It's microsoft.public.vc.stl for anyone interested in it.
 so I'm still getting up to speed on the language,
 but on paper it seems like the language I *wish* C++ were.

You hit the nail on the head with that. That's exactly the motivation behind D. I love what I can do with C++, but its flaws are so many it inspires me, as an engineer, to fix them.
 If people
 discount D out of hand it's probably because they're inexperienced, in
 which case perhaps they'll come around eventually.  For D to become a
 true alternative to C++ for me though, it's going to need to scale to
 handle enterprise-level issues.  Multiplexed i/o, better thread support,
 etc.  I was going to work on this a bit for Boost but I may do it here
 instead :p

We'd love to have your help here.
Feb 06 2004
prev sibling parent reply "C" <dont respond.com> writes:
 For D to become a
 true alternative to C++ for me though, it's going to need to scale to
 handle enterprise-level issues.

I completely agree, for me it also needs more library support. For me to use it at work i need a libcurl like library ( http://curl.haxx.se ).
 I was going to work on this a bit for Boost but I may do it here
 instead :p

I hope so! C "Sean Kelly" <sean ffwd.cx> wrote in message news:c01mhe$d5u$1 digitaldaemon.com...
 C wrote:
 So true ... and most times they dont even think its a bug just a


 restriction ( or a "Thats a poor design" , when most likely , their


 is incapable of implementing it , and they cant see past their own


 In my D advocacy , ive run into so many people who just refuse to try
 anything new or keep an open mind , its sad and depressing.  There


 against me , never even having tried the language ... , I tell them to


 try it they'll love it , but they just flat refuse.  So sad.

I just heard about D a few days ago (thanks to a thread Walter is in on the MS STL newsgroup) so I'm still getting up to speed on the language, but on paper it seems like the language I *wish* C++ were. If people discount D out of hand it's probably because they're inexperienced, in which case perhaps they'll come around eventually. For D to become a true alternative to C++ for me though, it's going to need to scale to handle enterprise-level issues. Multiplexed i/o, better thread support, etc. I was going to work on this a bit for Boost but I may do it here instead :p Sean

Feb 07 2004
parent reply "Walter" <walter digitalmars.com> writes:
"C" <dont respond.com> wrote in message
news:c03i1s$tor$1 digitaldaemon.com...
 I completely agree, for me it also needs more library support.  For me to
 use it at work i need a libcurl like library ( http://curl.haxx.se ).

Since libcurl is a C library, a D wrapper for it should be pretty easy. Want to give it a try?
Feb 07 2004
parent reply "C" <dont respond.com> writes:
I have tried in the past , i took the approach of building the .dll in VC ,
and using implib to create a .lib.  I got it to compile , but it failed on
startup , with .. I forget the error.  Its been a couple months though , Ill
give it another go around.

I also need to re-read the C to D section, I've forgotten how D handles
memory allocated from within C functions :/.

C


"Walter" <walter digitalmars.com> wrote in message
news:c03nfs$178v$1 digitaldaemon.com...
 "C" <dont respond.com> wrote in message
 news:c03i1s$tor$1 digitaldaemon.com...
 I completely agree, for me it also needs more library support.  For me


 use it at work i need a libcurl like library ( http://curl.haxx.se ).

Since libcurl is a C library, a D wrapper for it should be pretty easy.

 to give it a try?

Feb 07 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
You may want to compile it with DigitalMars C compiler into a lib. This 
is the easiest.

After you get it to work within a simple DigitalMars C or C++ program, 
the step to D would be trivial and any failure would be easy to diagnose.

-eye

C wrote:
 I have tried in the past , i took the approach of building the .dll in VC ,
 and using implib to create a .lib.  I got it to compile , but it failed on
 startup , with .. I forget the error.  Its been a couple months though , Ill
 give it another go around.
 
 I also need to re-read the C to D section, I've forgotten how D handles
 memory allocated from within C functions :/.
 
 C

Feb 07 2004
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:c03r5f$1bf7$1 digitaldaemon.com...
 You may want to compile it with DigitalMars C compiler into a lib. This
 is the easiest.

 After you get it to work within a simple DigitalMars C or C++ program,
 the step to D would be trivial and any failure would be easy to diagnose.

Yes, a static lib. I'd forget about making a curl dll for this project.
Feb 07 2004
parent reply "C" <dont respond.com> writes:
Ok , the api wrappers are at www.atari-soldiers.com/curl.d . Compiled and
tested with linux , ill work on compiling with dmc for windows.

Im working on some OO wrappers ill post shortly.

Here is the simple.d example :


import curl;

import std.c.stdio;
import std.string;

alias std.string.toStringz c_str;

int main()
{
 CURL *curl;
 CURLcode res;

 curl = curl_easy_init();
 if(curl) {
  curl_easy_setopt(curl, CURLOPT_URL, c_str("www.digitalmars.com"));
  res = curl_easy_perform(curl);

  /* always cleanup */
  curl_easy_cleanup(curl);
 }
 return 0;
}

If you havent used libcurl you should check it out , its very cool .(
http://curl.haxx.se )

C

"Walter" <walter digitalmars.com> wrote in message
news:c04708$1vv1$1 digitaldaemon.com...
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:c03r5f$1bf7$1 digitaldaemon.com...
 You may want to compile it with DigitalMars C compiler into a lib. This
 is the easiest.

 After you get it to work within a simple DigitalMars C or C++ program,
 the step to D would be trivial and any failure would be easy to


 Yes, a static lib. I'd forget about making a curl dll for this project.

Feb 08 2004
parent reply "Walter" <walter digitalmars.com> writes:
That was fast! Could you let the curl guys know so they can put a link up at
http://curl.haxx.se/libcurl/ for the D bindings?

"C" <dont respond.com> wrote in message
news:c0706q$e9v$1 digitaldaemon.com...
 Ok , the api wrappers are at www.atari-soldiers.com/curl.d . Compiled and
 tested with linux , ill work on compiling with dmc for windows.

 Im working on some OO wrappers ill post shortly.

 Here is the simple.d example :


 import curl;

 import std.c.stdio;
 import std.string;

 alias std.string.toStringz c_str;

 int main()
 {
  CURL *curl;
  CURLcode res;

  curl = curl_easy_init();
  if(curl) {
   curl_easy_setopt(curl, CURLOPT_URL, c_str("www.digitalmars.com"));
   res = curl_easy_perform(curl);

   /* always cleanup */
   curl_easy_cleanup(curl);
  }
  return 0;
 }

 If you havent used libcurl you should check it out , its very cool .(
 http://curl.haxx.se )

 C

 "Walter" <walter digitalmars.com> wrote in message
 news:c04708$1vv1$1 digitaldaemon.com...
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:c03r5f$1bf7$1 digitaldaemon.com...
 You may want to compile it with DigitalMars C compiler into a lib.



 is the easiest.

 After you get it to work within a simple DigitalMars C or C++ program,
 the step to D would be trivial and any failure would be easy to


 Yes, a static lib. I'd forget about making a curl dll for this project.


Feb 08 2004
parent reply "C" <dont respond.com> writes:
Yep already sent ( on the mailing list ) ;).

C
"Walter" <walter digitalmars.com> wrote in message
news:c0776m$qc5$1 digitaldaemon.com...
 That was fast! Could you let the curl guys know so they can put a link up

 http://curl.haxx.se/libcurl/ for the D bindings?

 "C" <dont respond.com> wrote in message
 news:c0706q$e9v$1 digitaldaemon.com...
 Ok , the api wrappers are at www.atari-soldiers.com/curl.d . Compiled


 tested with linux , ill work on compiling with dmc for windows.

 Im working on some OO wrappers ill post shortly.

 Here is the simple.d example :


 import curl;

 import std.c.stdio;
 import std.string;

 alias std.string.toStringz c_str;

 int main()
 {
  CURL *curl;
  CURLcode res;

  curl = curl_easy_init();
  if(curl) {
   curl_easy_setopt(curl, CURLOPT_URL, c_str("www.digitalmars.com"));
   res = curl_easy_perform(curl);

   /* always cleanup */
   curl_easy_cleanup(curl);
  }
  return 0;
 }

 If you havent used libcurl you should check it out , its very cool .(
 http://curl.haxx.se )

 C

 "Walter" <walter digitalmars.com> wrote in message
 news:c04708$1vv1$1 digitaldaemon.com...
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:c03r5f$1bf7$1 digitaldaemon.com...
 You may want to compile it with DigitalMars C compiler into a lib.



 is the easiest.

 After you get it to work within a simple DigitalMars C or C++




 the step to D would be trivial and any failure would be easy to


 Yes, a static lib. I'd forget about making a curl dll for this






Feb 09 2004
parent reply "Walter" <walter digitalmars.com> writes:
Were you also able to build curl with dmc++?

"C" <dont respond.com> wrote in message
news:c077jd$que$1 digitaldaemon.com...
 Yep already sent ( on the mailing list ) ;).

 C
 "Walter" <walter digitalmars.com> wrote in message
 news:c0776m$qc5$1 digitaldaemon.com...
 That was fast! Could you let the curl guys know so they can put a link


 at
 http://curl.haxx.se/libcurl/ for the D bindings?

 "C" <dont respond.com> wrote in message
 news:c0706q$e9v$1 digitaldaemon.com...
 Ok , the api wrappers are at www.atari-soldiers.com/curl.d . Compiled


 tested with linux , ill work on compiling with dmc for windows.

 Im working on some OO wrappers ill post shortly.

 Here is the simple.d example :


 import curl;

 import std.c.stdio;
 import std.string;

 alias std.string.toStringz c_str;

 int main()
 {
  CURL *curl;
  CURLcode res;

  curl = curl_easy_init();
  if(curl) {
   curl_easy_setopt(curl, CURLOPT_URL, c_str("www.digitalmars.com"));
   res = curl_easy_perform(curl);

   /* always cleanup */
   curl_easy_cleanup(curl);
  }
  return 0;
 }

 If you havent used libcurl you should check it out , its very cool .(
 http://curl.haxx.se )

 C

 "Walter" <walter digitalmars.com> wrote in message
 news:c04708$1vv1$1 digitaldaemon.com...
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:c03r5f$1bf7$1 digitaldaemon.com...
 You may want to compile it with DigitalMars C compiler into a lib.



 is the easiest.

 After you get it to work within a simple DigitalMars C or C++




 the step to D would be trivial and any failure would be easy to


 Yes, a static lib. I'd forget about making a curl dll for this







Feb 08 2004
parent reply "C" <dont respond.com> writes:
Not yet, I tried a couple months back , and the pre-proccessor seems to
proccess the files correctly only if it was in C++ mode , but the libcurl
code contains C++ keywords it would need to be ansi-c.  I will try  soon ,
unfortunately I only use linux at work  ( I billed the time working on it
)  ) , and Im moving so it might be a while.

C

"Walter" <walter digitalmars.com> wrote in message
news:c07efa$158j$1 digitaldaemon.com...
 Were you also able to build curl with dmc++?

 "C" <dont respond.com> wrote in message
 news:c077jd$que$1 digitaldaemon.com...
 Yep already sent ( on the mailing list ) ;).

 C
 "Walter" <walter digitalmars.com> wrote in message
 news:c0776m$qc5$1 digitaldaemon.com...
 That was fast! Could you let the curl guys know so they can put a link


 at
 http://curl.haxx.se/libcurl/ for the D bindings?

 "C" <dont respond.com> wrote in message
 news:c0706q$e9v$1 digitaldaemon.com...
 Ok , the api wrappers are at www.atari-soldiers.com/curl.d .




 and
 tested with linux , ill work on compiling with dmc for windows.

 Im working on some OO wrappers ill post shortly.

 Here is the simple.d example :


 import curl;

 import std.c.stdio;
 import std.string;

 alias std.string.toStringz c_str;

 int main()
 {
  CURL *curl;
  CURLcode res;

  curl = curl_easy_init();
  if(curl) {
   curl_easy_setopt(curl, CURLOPT_URL, c_str("www.digitalmars.com"));
   res = curl_easy_perform(curl);

   /* always cleanup */
   curl_easy_cleanup(curl);
  }
  return 0;
 }

 If you havent used libcurl you should check it out , its very cool




 http://curl.haxx.se )

 C

 "Walter" <walter digitalmars.com> wrote in message
 news:c04708$1vv1$1 digitaldaemon.com...
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:c03r5f$1bf7$1 digitaldaemon.com...
 You may want to compile it with DigitalMars C compiler into a






 This
 is the easiest.

 After you get it to work within a simple DigitalMars C or C++




 the step to D would be trivial and any failure would be easy to


 Yes, a static lib. I'd forget about making a curl dll for this








Feb 09 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"C" <dont respond.com> wrote in message
news:c07ers$16aj$1 digitaldaemon.com...
 Not yet, I tried a couple months back , and the pre-proccessor seems to
 proccess the files correctly only if it was in C++ mode , but the libcurl
 code contains C++ keywords it would need to be ansi-c.  I will try  soon ,
 unfortunately I only use linux at work  ( I billed the time working on it
 )  ) , and Im moving so it might be a while.

Dude! Amusing as it is to read, do you really want this publicly and permanently accessible?!
 C

 "Walter" <walter digitalmars.com> wrote in message
 news:c07efa$158j$1 digitaldaemon.com...
 Were you also able to build curl with dmc++?

 "C" <dont respond.com> wrote in message
 news:c077jd$que$1 digitaldaemon.com...
 Yep already sent ( on the mailing list ) ;).

 C
 "Walter" <walter digitalmars.com> wrote in message
 news:c0776m$qc5$1 digitaldaemon.com...
 That was fast! Could you let the curl guys know so they can put a




 up
 at
 http://curl.haxx.se/libcurl/ for the D bindings?

 "C" <dont respond.com> wrote in message
 news:c0706q$e9v$1 digitaldaemon.com...
 Ok , the api wrappers are at www.atari-soldiers.com/curl.d .




 and
 tested with linux , ill work on compiling with dmc for windows.

 Im working on some OO wrappers ill post shortly.

 Here is the simple.d example :


 import curl;

 import std.c.stdio;
 import std.string;

 alias std.string.toStringz c_str;

 int main()
 {
  CURL *curl;
  CURLcode res;

  curl = curl_easy_init();
  if(curl) {
   curl_easy_setopt(curl, CURLOPT_URL,





   res = curl_easy_perform(curl);

   /* always cleanup */
   curl_easy_cleanup(curl);
  }
  return 0;
 }

 If you havent used libcurl you should check it out , its very cool




 http://curl.haxx.se )

 C

 "Walter" <walter digitalmars.com> wrote in message
 news:c04708$1vv1$1 digitaldaemon.com...
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:c03r5f$1bf7$1 digitaldaemon.com...
 You may want to compile it with DigitalMars C compiler into a






 This
 is the easiest.

 After you get it to work within a simple DigitalMars C or C++




 the step to D would be trivial and any failure would be easy







 diagnose.
 Yes, a static lib. I'd forget about making a curl dll for this









Feb 09 2004
parent reply "C" <dont respond.com> writes:
What my inability to get libcurl compiled ( actually I found the old
makefile and am working on it )?  Or if its the billing thing I got apporval
before hand of course :P.

C


"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c07m23$1k0i$1 digitaldaemon.com...
 "C" <dont respond.com> wrote in message
 news:c07ers$16aj$1 digitaldaemon.com...
 Not yet, I tried a couple months back , and the pre-proccessor seems to
 proccess the files correctly only if it was in C++ mode , but the


 code contains C++ keywords it would need to be ansi-c.  I will try  soon


 unfortunately I only use linux at work  ( I billed the time working on


 )  ) , and Im moving so it might be a while.

Dude! Amusing as it is to read, do you really want this publicly and permanently accessible?!
 C

 "Walter" <walter digitalmars.com> wrote in message
 news:c07efa$158j$1 digitaldaemon.com...
 Were you also able to build curl with dmc++?

 "C" <dont respond.com> wrote in message
 news:c077jd$que$1 digitaldaemon.com...
 Yep already sent ( on the mailing list ) ;).

 C
 "Walter" <walter digitalmars.com> wrote in message
 news:c0776m$qc5$1 digitaldaemon.com...
 That was fast! Could you let the curl guys know so they can put a




 up
 at
 http://curl.haxx.se/libcurl/ for the D bindings?

 "C" <dont respond.com> wrote in message
 news:c0706q$e9v$1 digitaldaemon.com...
 Ok , the api wrappers are at www.atari-soldiers.com/curl.d .




 and
 tested with linux , ill work on compiling with dmc for windows.

 Im working on some OO wrappers ill post shortly.

 Here is the simple.d example :


 import curl;

 import std.c.stdio;
 import std.string;

 alias std.string.toStringz c_str;

 int main()
 {
  CURL *curl;
  CURLcode res;

  curl = curl_easy_init();
  if(curl) {
   curl_easy_setopt(curl, CURLOPT_URL,





   res = curl_easy_perform(curl);

   /* always cleanup */
   curl_easy_cleanup(curl);
  }
  return 0;
 }

 If you havent used libcurl you should check it out , its very






 .(
 http://curl.haxx.se )

 C

 "Walter" <walter digitalmars.com> wrote in message
 news:c04708$1vv1$1 digitaldaemon.com...
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:c03r5f$1bf7$1 digitaldaemon.com...
 You may want to compile it with DigitalMars C compiler into








 lib.
 This
 is the easiest.

 After you get it to work within a simple DigitalMars C or








 program,
 the step to D would be trivial and any failure would be easy







 diagnose.
 Yes, a static lib. I'd forget about making a curl dll for this










Feb 09 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
  Or if its the billing thing I got apporval
 before hand of course :P.

My mistake. Any imputations to your character utterly retracted. :)
 C


 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c07m23$1k0i$1 digitaldaemon.com...
 "C" <dont respond.com> wrote in message
 news:c07ers$16aj$1 digitaldaemon.com...
 Not yet, I tried a couple months back , and the pre-proccessor seems



 proccess the files correctly only if it was in C++ mode , but the


 code contains C++ keywords it would need to be ansi-c.  I will try



 ,
 unfortunately I only use linux at work  ( I billed the time working on


 )  ) , and Im moving so it might be a while.

Dude! Amusing as it is to read, do you really want this publicly and permanently accessible?!
 C

 "Walter" <walter digitalmars.com> wrote in message
 news:c07efa$158j$1 digitaldaemon.com...
 Were you also able to build curl with dmc++?

 "C" <dont respond.com> wrote in message
 news:c077jd$que$1 digitaldaemon.com...
 Yep already sent ( on the mailing list ) ;).

 C
 "Walter" <walter digitalmars.com> wrote in message
 news:c0776m$qc5$1 digitaldaemon.com...
 That was fast! Could you let the curl guys know so they can put






 link
 up
 at
 http://curl.haxx.se/libcurl/ for the D bindings?

 "C" <dont respond.com> wrote in message
 news:c0706q$e9v$1 digitaldaemon.com...
 Ok , the api wrappers are at www.atari-soldiers.com/curl.d .




 and
 tested with linux , ill work on compiling with dmc for







 Im working on some OO wrappers ill post shortly.

 Here is the simple.d example :


 import curl;

 import std.c.stdio;
 import std.string;

 alias std.string.toStringz c_str;

 int main()
 {
  CURL *curl;
  CURLcode res;

  curl = curl_easy_init();
  if(curl) {
   curl_easy_setopt(curl, CURLOPT_URL,





   res = curl_easy_perform(curl);

   /* always cleanup */
   curl_easy_cleanup(curl);
  }
  return 0;
 }

 If you havent used libcurl you should check it out , its very






 .(
 http://curl.haxx.se )

 C

 "Walter" <walter digitalmars.com> wrote in message
 news:c04708$1vv1$1 digitaldaemon.com...
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:c03r5f$1bf7$1 digitaldaemon.com...
 You may want to compile it with DigitalMars C compiler









 a
 lib.
 This
 is the easiest.

 After you get it to work within a simple DigitalMars C or








 program,
 the step to D would be trivial and any failure would be









 to
 diagnose.
 Yes, a static lib. I'd forget about making a curl dll for








 project.








Feb 09 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"C" <dont respond.com> wrote in message
news:c07ers$16aj$1 digitaldaemon.com...
 Not yet, I tried a couple months back , and the pre-proccessor seems to
 proccess the files correctly only if it was in C++ mode , but the libcurl
 code contains C++ keywords it would need to be ansi-c.  I will try  soon ,
 unfortunately I only use linux at work  ( I billed the time working on it
 )  ) , and Im moving so it might be a while.

There was an issue with the preprocessor that was preventing boost from compiling that is fixed in 8.39 (insertion of extra spaces in concatenated strings). Was that it?
Feb 09 2004
parent reply "C" <dont respond.com> writes:
Yea thats probably it , they use these macros to define their options

#define CINIT(name,type,number) CURLOPT_ ## name = CURLOPTTYPE_ ## type +
number

#define CFINIT(name) CURLFORM_ ## name

Cool that will make it easier.

C

"Walter" <walter digitalmars.com> wrote in message
news:c08nmm$s2a$1 digitaldaemon.com...
 "C" <dont respond.com> wrote in message
 news:c07ers$16aj$1 digitaldaemon.com...
 Not yet, I tried a couple months back , and the pre-proccessor seems to
 proccess the files correctly only if it was in C++ mode , but the


 code contains C++ keywords it would need to be ansi-c.  I will try  soon


 unfortunately I only use linux at work  ( I billed the time working on


 )  ) , and Im moving so it might be a while.

There was an issue with the preprocessor that was preventing boost from compiling that is fixed in 8.39 (insertion of extra spaces in concatenated strings). Was that it?

Feb 09 2004
parent "Walter" <walter digitalmars.com> writes:
"C" <dont respond.com> wrote in message
news:c0906k$1add$1 digitaldaemon.com...
 Yea thats probably it , they use these macros to define their options

 #define CINIT(name,type,number) CURLOPT_ ## name = CURLOPTTYPE_ ## type +
 number

 #define CFINIT(name) CURLFORM_ ## name

 Cool that will make it easier.

Rock on!
Feb 09 2004
prev sibling parent reply "C" <dont respond.com> writes:
Hmm ok.  I got it to compile , needed to change ftp.c , there was a variable
named 'try' , and to compile the example , easycurl.h includes winnt.h ,
there was an error with

typdef long LONG;

changed to

#define LONG long;

and it works ok.  However when the sample is run it crashes inexplicably.  I
ran it through the debugger ( by the way if anyone doesnt have the CD they
should get it for the debugger alone its very useful ) , seems its crashing
on curl_easy_perform .

Here's the Call window,

main
curl_easy_perform
Curl_perform
Curl_connect <-- crashing , calling CreateConnection .

CreateConnection is in url.c , and is huge.

Ive posted the libcurl build at www.atari-soldiers.com/libcurlDMC.zip .  It
should build without a problem , youll probably need to change those lines
in WINNT.h though.  The makefile is Makefile.dmc , make -f Makefile.dmc
should do the trick.


Everyone that can help please do!

Thanks,
Charlie



"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:c03r5f$1bf7$1 digitaldaemon.com...
 You may want to compile it with DigitalMars C compiler into a lib. This
 is the easiest.

 After you get it to work within a simple DigitalMars C or C++ program,
 the step to D would be trivial and any failure would be easy to diagnose.

 -eye

 C wrote:
 I have tried in the past , i took the approach of building the .dll in


 and using implib to create a .lib.  I got it to compile , but it failed


 startup , with .. I forget the error.  Its been a couple months though ,


 give it another go around.

 I also need to re-read the C to D section, I've forgotten how D handles
 memory allocated from within C functions :/.

 C


Feb 10 2004
parent "C" <dont respond.com> writes:
Just to be clear here, im trying to compile simple.c , trying to get the
libcurl to play with DMC.

C
"C" <dont respond.com> wrote in message
news:c0bet1$298o$1 digitaldaemon.com...
 Hmm ok.  I got it to compile , needed to change ftp.c , there was a

 named 'try' , and to compile the example , easycurl.h includes winnt.h ,
 there was an error with

 typdef long LONG;

 changed to

 #define LONG long;

 and it works ok.  However when the sample is run it crashes inexplicably.

 ran it through the debugger ( by the way if anyone doesnt have the CD they
 should get it for the debugger alone its very useful ) , seems its

 on curl_easy_perform .

 Here's the Call window,

 main
 curl_easy_perform
 Curl_perform
 Curl_connect <-- crashing , calling CreateConnection .

 CreateConnection is in url.c , and is huge.

 Ive posted the libcurl build at www.atari-soldiers.com/libcurlDMC.zip .

 should build without a problem , youll probably need to change those lines
 in WINNT.h though.  The makefile is Makefile.dmc , make -f Makefile.dmc
 should do the trick.


 Everyone that can help please do!

 Thanks,
 Charlie



 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:c03r5f$1bf7$1 digitaldaemon.com...
 You may want to compile it with DigitalMars C compiler into a lib. This
 is the easiest.

 After you get it to work within a simple DigitalMars C or C++ program,
 the step to D would be trivial and any failure would be easy to


 -eye

 C wrote:
 I have tried in the past , i took the approach of building the .dll in


 and using implib to create a .lib.  I got it to compile , but it



 on
 startup , with .. I forget the error.  Its been a couple months though



 Ill
 give it another go around.

 I also need to re-read the C to D section, I've forgotten how D



 memory allocated from within C functions :/.

 C



Feb 10 2004
prev sibling parent "Walter" <walter digitalmars.com> writes:
"C" <dont respond.com> wrote in message
news:c01g0d$tr$1 digitaldaemon.com...
 So true ... and most times they dont even think its a bug just a language
 restriction ( or a "Thats a poor design" , when most likely , their

 is incapable of implementing it , and they cant see past their own noses )
 In my D advocacy , ive run into so many people who just refuse to try
 anything new or keep an open mind , its sad and depressing.  There arguing
 against me , never even having tried the language ... , I tell them to

 try it they'll love it , but they just flat refuse.  So sad.

That fits right in line with the demographics of D users being younger programmers. I ain't so young anymore (my father fought in the Civil War, ya know <g>), but I'm having more fun with this project than anything I've done in the past. The huge response D is getting, as evidenced here, is more than justifying my confidence that D's future is unlimited.
Feb 06 2004
prev sibling parent "Walter" <walter digitalmars.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:c01fje$31d7$1 digitaldaemon.com...
 It seems like there's been a lot of see-how-I-made-the-compiler-fail
 messages recently. I think these posts are made in good faith.

Yes, they are. I can't think of a single example otherwise.
 When I first started following this newsgroup many, many months ago, I
 got the impression that many of the posters didn't actually try out the
 compiler. There was a lot of discussion about which features would be
 included in the ultimate programming languge.

 Now, people are actually trying to do things in D. So we post more
 messages trying to help Walter squash bugs by showing weaknesses in the
 compiler.

Absolutely right. If nobody was posting bugs, that's a sure sign nobody is using it. I fix them one by one, and add the resulting test cases to the test suite so it will never happen again. The result is an ever stronger compiler backed by an ever more thorough QA program.
 This is a weakness in the state of D right now.  I think an even more
 pressing problem is all of the "stale" code out there (e.g. it worked
 great with DMD 0.69, but won't even compile since phobos got re-arranged
 in DMD 0.75). We probably should include a version number and date when
 we upload code to a website (so if we fall behind with D updates at
 least a person can tell before he downloads the whole thing).

I knew that would happen and dreaded doing it, but the the rearrangement had to happen, and the sooner the better. I hope that is all behind us now.
 I think Bugzilla would be great. I think Walter has some concerns that
 the Anti-D Militia would make announcements like "look how many
 unresolved bugs has! Oh, the horror!" (When in reality, their favorite
 language has many bugs, but their vendor sweeps all the bugs underneath
 the rug.)

I published a carefully documented bug list once in the past. It was a disaster.
Feb 06 2004
prev sibling parent Mark T <Mark_member pathlink.com> writes:
In article <c00vhs$24aq$1 digitaldaemon.com>, larry cowan says...
2.  I think the language is generally well-defined, but I would hate to have it
lock-in upward compatibility as a requirement yet.

Any language can add or deprecate features over it's "lifetime" but I think it is time for D to establish a first standard "D 2004" much like other languages have done Fortran 1977, C 1989, C++ 1998 etc. This would allow other vendors and targets to be established. I really like D, but I'm in the embedded world and at work we mostly use PowerPC and ARM. It would be nice to see Greenhills release a D compiler. The embedded tool vendors tend to be much more risk adverse and they probably won't bite until D is reasonably established in the non-embedded world. I think a lot of people confuse the DMD implementation which may or may not have a particular bug with the D language itself.
Feb 08 2004