sailormoontw wrote:
> For example, about the DirectX Wrapper what I can find the latest one is one in
> a Japanese site. http://hp.vector.co.jp/authors/VA031566/d_direct3d9/, I've
> searched the D Forum and there seems no newer version of DirectX wrapper. I
> downloaded the hdk library, and when I linked the library with its sample codes,
> the optlink fails with a runtime exception. I know it must be the version
> imcompatible, and then, I try to recompile the source. Not only did I find some
> codes need to rewrite but after all the codes seemed fixed to get a successful
> compilation, some the samples still cannot run at all. I find its for the
> mqoreader.d, but should I spend time to debug it??
> 
> Nope, it's hard to debug other's code, and I can feel the frustration of the
> author of hdk for the frequent changing of D. I think that's the reason he or
> she stopped upgrading. And if I want to upgrade the codes, I think I will face
> the same problem, and not to say there isn't a good debugger to help.
> 
> Well, maybe I should not choose DirectX, SDL with derelict library seems more
> stable and ready. I still hope there is a good DirectX wrapper to use...

The Windows API project
http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI
is well on the way towards converting all of the Windows API headers (including DirectX) into D. Stewart Gordon has done a great job of ensuring that this will be the definitive translation in D, and many of these types of problems will disappear once this project is complete, because we'll have a standard code base to improve.

In article <e4baj5$aut$1@digitaldaemon.com>, Walter Bright says...
>
>BCS wrote:
>> What do ya think new D users would think about a converter that does 100% correct convention of a sub set (+10%) of C (and maybe cpp) code? Say just global function prototypes, structs typdefs (c style) and anything else that would be easy to get right. Some of the stuff (in C, the most common stuff) translates directly, and shouldn't be that bad to translate.
>
>There is always something in each header that is not translatable :-(

But with any luck you wont need that part most of the time. What I'm suggesting is a tool that does a best effort translation generating a header for parts that can always be done (file scope function, simple structs, global variables of common types, etc.) in other words, the bulk of most C headers.

Ben Cooley wrote:
> Elsa seems to do a pretty good job for us.. and we've got some pretty
> complicated template usage.  But you really need little more than the sort of
> parser used to create documentation, or to view the class hierarchy.  You don't
> need to parse any actual code, just definitions.  Swig is a good example.

I've never heard of Elsa, but I bet I can break it <g>.

> As for the preprocessor, all C compilers come with their own already, so that's
> really not a major problem.  A D pass to extract macros first, then a
> preprocessing pass by the real Cpp compiler, then a declaration parsing pass.

That might work, but it's quite a lashup.

Don Clugston wrote:
> The Windows API project
> http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI
> is well on the way towards converting all of the Windows API headers (including DirectX) into D. Stewart Gordon has done a great job of ensuring that this will be the definitive translation in D, and many of these types of problems will disappear once this project is complete, because we'll have a standard code base to improve.

I agree. That project is a first rate example of what the D community can do in a collaborative effort. Kudos to all involved with it.

Walter Bright wrote:
> Don Clugston wrote:
>> The Windows API project
>> http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI
>> is well on the way towards converting all of the Windows API headers (including DirectX) into D. Stewart Gordon has done a great job of ensuring that this will be the definitive translation in D, and many of these types of problems will disappear once this project is complete, because we'll have a standard code base to improve.
> 
> I agree. That project is a first rate example of what the D community can do in a collaborative effort. Kudos to all involved with it.

We'll also need updated versions of the Windows import libs (since the ones provided with D don't have the recent functions). Do you have a license to redistribute the more recent ones?

Secondly, do you think it would be possible to use pragma(lib) to eliminate the concept of 'default libraries' at least for the Windows headers?
It seems to me that that's another C/C++ annoyance that D could abolish.

Don Clugston wrote:
> We'll also need updated versions of the Windows import libs (since the ones provided with D don't have the recent functions). Do you have a license to redistribute the more recent ones?

Yes.

> Secondly, do you think it would be possible to use pragma(lib) to eliminate the concept of 'default libraries' at least for the Windows headers?

Yes.

> It seems to me that that's another C/C++ annoyance that D could abolish.

In article <e4brql$1ihs$1@digitaldaemon.com>, BCS says...
>
>In article <e4baj5$aut$1@digitaldaemon.com>, Walter Bright says...
>>
>>BCS wrote:
>>> What do ya think new D users would think about a converter that does 100% correct convention of a sub set (+10%) of C (and maybe cpp) code? Say just global function prototypes, structs typdefs (c style) and anything else that would be easy to get right. Some of the stuff (in C, the most common stuff) translates directly, and shouldn't be that bad to translate.
>>
>>There is always something in each header that is not translatable :-(
>
>But with any luck you wont need that part most of the time. What I'm suggesting is a tool that does a best effort translation generating a header for parts that can always be done (file scope function, simple structs, global variables of common types, etc.) in other words, the bulk of most C headers.

Note that that's already how SWIG works pretty much.  It doesn't have a full C++ parser, but it can parse and generate wrappers for a lot of simple C++ code just by including the header.  It's not going to work for wrapping wxWidgets or something like that, but it is useful to have.

There has also been talk in the SWIG mailing lists about generating C wrappers from C++ code.  Don't think anyone is actively working on it, but there is interest in such a thing out there.  That could be useful for D purposes too. With a little work it could lead to the ability to use any SWIG-wrapped C or C++ code from D.  It's a thought for an alternative to trying to write a C++ to D translator type thing.

Finally about whether it's worth it to be able to call C++ code, I'd like to point to the example of Fortran.  It was superceded by better languages with better syntax many many years ago, but people still use it.  I hear a lot of people saying "we're better off without all that old junky C++ code anyway". But the fact of the matter is that nobody in the real world has the time or budget to go back and rewrite all their old code (that already works and has been debugged) just because it would be easier to read in a new language.  Most numerical work is still based on lots of legacy fortran code, even if the front end code is now written in C or C++ or Python or what have you.   It just makes no sense to rewrite gobs and gobs of stuff that works.

Gotta go so there's no time to finish my point, but there are some interesting parallels in this debate with the migration away from Fortran, I think.

Bill Baxter

Bill Baxter wrote:
> In article <e4brql$1ihs$1@digitaldaemon.com>, BCS says...
>> In article <e4baj5$aut$1@digitaldaemon.com>, Walter Bright says...
>>> BCS wrote:
>>>> What do ya think new D users would think about a converter that does 100% correct convention of a sub set (+10%) of C (and maybe cpp) code? Say just global function prototypes, structs typdefs (c style) and anything else that would be easy to get right. Some of the stuff (in C, the most common stuff) translates directly, and shouldn't be that bad to translate.
>>> There is always something in each header that is not translatable :-(
>> But with any luck you wont need that part most of the time. What I'm suggesting
>> is a tool that does a best effort translation generating a header for parts that
>> can always be done (file scope function, simple structs, global variables of
>> common types, etc.) in other words, the bulk of most C headers.
> 
> Note that that's already how SWIG works pretty much.  It doesn't have a full C++
> parser, but it can parse and generate wrappers for a lot of simple C++ code just
> by including the header.  It's not going to work for wrapping wxWidgets or
> something like that, but it is useful to have.
> 
> There has also been talk in the SWIG mailing lists about generating C wrappers
> from C++ code.  Don't think anyone is actively working on it, but there is
> interest in such a thing out there.  That could be useful for D purposes too.
> With a little work it could lead to the ability to use any SWIG-wrapped C or C++
> code from D.  It's a thought for an alternative to trying to write a C++ to D
> translator type thing.
> 
> Finally about whether it's worth it to be able to call C++ code, I'd like to
> point to the example of Fortran.  It was superceded by better languages with
> better syntax many many years ago, but people still use it.  I hear a lot of
> people saying "we're better off without all that old junky C++ code anyway".
> But the fact of the matter is that nobody in the real world has the time or
> budget to go back and rewrite all their old code (that already works and has
> been debugged) just because it would be easier to read in a new language.  Most
> numerical work is still based on lots of legacy fortran code, even if the front
> end code is now written in C or C++ or Python or what have you.   It just makes
> no sense to rewrite gobs and gobs of stuff that works.
> 
> Gotta go so there's no time to finish my point, but there are some interesting
> parallels in this debate with the migration away from Fortran, I think.  
> 
> Bill Baxter
Hi everybody,
This is my first post to this mailing list.

About the Fortran example
-------------------------
I think the Fortran example is a bad one. Which better languages were available long time ago? C or C++? Do you think C or C++ have a clean syntax? I don't think so, that's why I've been exploring D.
There are a lot of C (e.g. GSL, PETSc) and C++ (e.g. ITL, Blitz++) numerical libraries, so I don't think that is the main reason people still use Fortran.

I'm a scientist that have to write numerical codes. I've been searching for a better language (combination of languages) than Fortran for some time. I've used Fortran+F2PY+Python, C++, Python+SWIG+C++, and Java to write code. None of those alternatives to replace Fortran were completely satisfactory. One of the reasons is that Fortran is very good at doing number crunching. It's very fast, it includes array operations, and it is easy to learn.

However, Fortran95 (as standard) lacks other tools, such as: conditional compilation, unit testing, true OO programming, command line arguments (that was only fixed in the new 2003 standard), etc. To me those are the most interesting D's features. In fact, I think D features make it a terrific alternative to Fortran. however, there are a couple of things that would make it even better: array operations (it's in Walter's plans) and OpenMP support.

About using different languages
-------------------------------
I understand that some times is useful to be able to program using a combination of languages. However, those cases should be the exception if you want to take advantage of a better language features. Mixing languages always adds problems and, in my opinion, makes difficult to have a clear design. As example, you can check how difficult has been creating a good SWIG interface for C++ or the problems of the maintainer of F2PY (Fortran to python interface generator) to support new compilers.

I think D already has a very easy way (probably the easiest with the exception of C++) to communicate with C if needed. Why to spend more valuable time improving that?

About native libraries
----------------------
I think the way to go is to create QUALITY native D libraries. I think we usually overestimate the cost of porting/developing native libraries. As example, this weekend I played to create a native XML SAX parser. In a couple of hours I had a useful version. I'm not sure if it was easier/shorter to link to a C library (that was my first idea).

I think D main problem is the lack of good quality (documented) native libraries. More than 80% of project at www.dsource.org are unmaintained and/or don't have documentation. Therefore, collaborating in or using those projects is impossible. In my opinion libraries and good quality documentation are the main reasons of the success of Python and Java.

About writing a native XML library
----------------------------------
If someone is interested in creating native SAX and DOM XML libraries please drop me an email. By the way, XML is another effective way to communicate (actually, exchange data) between different languages.

I apologize if part of this email is off topic in this thread.
Paulo.

Paulo Herrera wrote:
> Bill Baxter wrote:
>> In article <e4brql$1ihs$1@digitaldaemon.com>, BCS says...
>>> In article <e4baj5$aut$1@digitaldaemon.com>, Walter Bright says...
>>>> BCS wrote:
>>>>> What do ya think new D users would think about a converter that does 100% correct convention of a sub set (+10%) of C (and maybe cpp) code? Say just global function prototypes, structs typdefs (c style) and anything else that would be easy to get right. Some of the stuff (in C, the most common stuff) translates directly, and shouldn't be that bad to translate.
>>>> There is always something in each header that is not translatable :-(
>>> But with any luck you wont need that part most of the time. What I'm suggesting
>>> is a tool that does a best effort translation generating a header for parts that
>>> can always be done (file scope function, simple structs, global variables of
>>> common types, etc.) in other words, the bulk of most C headers.
>>
>> Note that that's already how SWIG works pretty much.  It doesn't have a full C++
>> parser, but it can parse and generate wrappers for a lot of simple C++ code just
>> by including the header.  It's not going to work for wrapping wxWidgets or
>> something like that, but it is useful to have.
>>
>> There has also been talk in the SWIG mailing lists about generating C wrappers
>> from C++ code.  Don't think anyone is actively working on it, but there is
>> interest in such a thing out there.  That could be useful for D purposes too.
>> With a little work it could lead to the ability to use any SWIG-wrapped C or C++
>> code from D.  It's a thought for an alternative to trying to write a C++ to D
>> translator type thing.
>>
>> Finally about whether it's worth it to be able to call C++ code, I'd like to
>> point to the example of Fortran.  It was superceded by better languages with
>> better syntax many many years ago, but people still use it.  I hear a lot of
>> people saying "we're better off without all that old junky C++ code anyway".
>> But the fact of the matter is that nobody in the real world has the time or
>> budget to go back and rewrite all their old code (that already works and has
>> been debugged) just because it would be easier to read in a new language.  Most
>> numerical work is still based on lots of legacy fortran code, even if the front
>> end code is now written in C or C++ or Python or what have you.   It just makes
>> no sense to rewrite gobs and gobs of stuff that works.
>>
>> Gotta go so there's no time to finish my point, but there are some interesting
>> parallels in this debate with the migration away from Fortran, I think. Bill Baxter
> Hi everybody,
> This is my first post to this mailing list.
> 
> About the Fortran example
> -------------------------
> I think the Fortran example is a bad one. Which better languages were available long time ago? C or C++? Do you think C or C++ have a clean syntax? I don't think so, that's why I've been exploring D.
> There are a lot of C (e.g. GSL, PETSc) and C++ (e.g. ITL, Blitz++) numerical libraries, so I don't think that is the main reason people still use Fortran.
> 
> I'm a scientist that have to write numerical codes. 

Welcome! There are quite a few of us here already.

I've been searching
> for a better language (combination of languages) than Fortran for some time. I've used Fortran+F2PY+Python, C++, Python+SWIG+C++, and Java to write code. None of those alternatives to replace Fortran were completely satisfactory. One of the reasons is that Fortran is very good at doing number crunching. It's very fast, it includes array operations, and it is easy to learn.

And Fortran takes numerics seriously. Unlike almost all of the more recent languages. D is the only recent general-purpose language I know of that takes numerics seriously (that's what initially attracted me to it).

> However, Fortran95 (as standard) lacks other tools, such as: conditional compilation, unit testing, true OO programming, command line arguments (that was only fixed in the new 2003 standard), etc. To me those are the most interesting D's features. In fact, I think D features make it a terrific alternative to Fortran. however, there are a couple of things that would make it even better: array operations (it's in Walter's plans) and OpenMP support.
> 
> About using different languages
> -------------------------------
> I understand that some times is useful to be able to program using a combination of languages. However, those cases should be the exception if you want to take advantage of a better language features. Mixing languages always adds problems and, in my opinion, makes difficult to have a clear design. As example, you can check how difficult has been creating a good SWIG interface for C++ or the problems of the maintainer of F2PY (Fortran to python interface generator) to support new compilers.
> 
> I think D already has a very easy way (probably the easiest with the exception of C++) to communicate with C if needed. Why to spend more valuable time improving that?
> 
> About native libraries
> ----------------------
> I think the way to go is to create QUALITY native D libraries. I think we usually overestimate the cost of porting/developing native libraries.

I agree. When porting a library
(a) there isn't any algorithm development (not much 'thinking' time required);
(b) it's very easy to test (you can run test cases against the original version);
(c) the D version is frequently greatly superior to the original.

D is a fantastic language for writing libraries in. IMHO, if we had even a small number of libraries with solid unit test coverage, everything else would start to look obsolete very quickly.

> As example, this weekend I played to create a native XML SAX parser. In a couple of hours I had a useful version. I'm not sure if it was easier/shorter to link to a C library (that was my first idea).
> 
> I think D main problem is the lack of good quality (documented) native libraries. More than 80% of project at www.dsource.org are unmaintained and/or don't have documentation. Therefore, collaborating in or using those projects is impossible. In my opinion libraries and good quality documentation are the main reasons of the success of Python and Java.

And .NET too.

> 
> About writing a native XML library
> ----------------------------------
> If someone is interested in creating native SAX and DOM XML libraries please drop me an email. By the way, XML is another effective way to communicate (actually, exchange data) between different languages.
> 
> I apologize if part of this email is off topic in this thread.
> Paulo.

Right on topic, I would say.
-Don.

In article <e4ca0r$2hvj$1@digitaldaemon.com>, Paulo Herrera says...
>
>Bill Baxter wrote:
>> 
>> Finally about whether it's worth it to be able to call C++ code, I'd like to point to the example of Fortran.  It was superceded by better languages with better syntax many many years ago, but people still use it.  I hear a lot of people saying "we're better off without all that old junky C++ code anyway". But the fact of the matter is that nobody in the real world has the time or budget to go back and rewrite all their old code (that already works and has been debugged) just because it would be easier to read in a new language.  Most numerical work is still based on lots of legacy fortran code, even if the front end code is now written in C or C++ or Python or what have you.   It just makes no sense to rewrite gobs and gobs of stuff that works.
>> 
>> Gotta go so there's no time to finish my point, but there are some interesting parallels in this debate with the migration away from Fortran, I think.
>> 
>> Bill Baxter
>Hi everybody,
>This is my first post to this mailing list.

Howdy.

>
>About the Fortran example
>-------------------------
>I think the Fortran example is a bad one. Which better languages were
>available long time ago? C or C++? Do you think C or C++ have a clean
>syntax? I don't think so, that's why I've been exploring D.
>There are a lot of C (e.g. GSL, PETSc) and C++ (e.g. ITL, Blitz++)
>numerical libraries, so I don't think that is the main reason people
>still use Fortran.


My point was that while some people still use Fortran (and others have moved on), LOTS of people still use old Fortran *libraries*.  I.e. C/C++ are to Fortran as D is to C/C++.  And just as with Fortran, there's just no value proposition in rewriting gobs of well-known, well-tested, well-debugged code, like that available at netlib.org.  Dreaming that everything of value that has ever been written in other languages (including Fortran, C, and C++) will get rewritten in D is just that, dreaming.  Heck, from what I hear there are still plenty of mainframes out there, cranking away on Cobol code.  Because it just doesn't make sense to spend a lot of resources fixing what ain't broke.

Writing new libs from scratch is certainly the best in the long run.  But that takes time, and it takes a lot of raw man hours.  In the short term, it seems obvous to me that the best bet is to increase the number man-hours by increasing the number of 'mans' -- attracting as many folks as possible to D.  But starting off by saying "sorry you can't use your old code" is just going to put people like Ben off from the start, thereby shrinking the pool of potential contributors.   I don't think D needs compatibility with C++ -- I'm inclined to think it's pretty hopeless even with a working C++ compiler as a starting point -- but some tools to create wrappers for existing C++ code (a la SWIG), should be doable, and would be a huge help in luring people to D.

I would venture to guess that the vast majority of C++ code that people write in real life is not at all like the STL, but more like the subset of C++ that's contained in  Java.  Those are the things you want to target (most bang for the buck), and, no co-incidence, those are precisely the things that SWIG targets. Libraries like Blitz++ and ITL that go crazy with C++ templates are so steeped in C++-specific issues that I doubt they could be wrapped reasonably anyway, whether done by hand or by a wrapper-generator.

Apparently this idea to use SWIG has been discussed (and even worked on?) a bit
before:
http://www.digitalmars.com/d/archives/17315.html
http://www.digitalmars.com/d/archives/17289.html

Yikes that was 2003.  Wonder what happened...

Bill Baxter