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


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


jump in

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


features,

 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


have it

 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


enhancements

 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


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.


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




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


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




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.


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




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




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




diagnose.

 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.






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


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.






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




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.






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




 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.

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








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.

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




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








 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.

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






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

 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.

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

#define

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




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  "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
 number

 #define

 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




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


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




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


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.


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