Thread overview
Will I try again? and also C header files.
May 31, 2013
SeanVn
May 31, 2013
Jacob Carlborg
May 31, 2013
Rémy Mouëza
Jun 01, 2013
Jacob Carlborg
Jun 03, 2013
SeanVN
Jun 03, 2013
John Colvin
May 31, 2013
John Colvin
Jun 01, 2013
Rikki Cattermole
May 31, 2013
I looked at the D programming language a few years ago and though it was good.  Then I ran into trouble.  The language was in a state of flux.  I would write code and with the next version of D it would no longer work.  The same thing was happening to people who were writing tools such as IDE's for D and I guess most of them just gave up.
That was then.
I hope now things have settled down. I will look at the language for a couple of days.  I presume I now only have to look at D2 and Phobos and not the previous 4 way split of D1/D2/Phobos/Tango.
I have a specific engineering application I want to develop. I want to pick a programming language that will give me the cleanest and most maintainable code possible.  I want to use the IUP GUI library.  That is a shared library that has C headers.  I presume I will be able to call the dll functions easily in D2?  Maybe I will only have to make some minimal changes to the C header files to get them to work with D2?

May 31, 2013
On 2013-05-31 09:18, SeanVn wrote:
> I looked at the D programming language a few years ago and though it was
> good.  Then I ran into trouble.  The language was in a state of flux.  I
> would write code and with the next version of D it would no longer
> work.  The same thing was happening to people who were writing tools
> such as IDE's for D and I guess most of them just gave up.
> That was then.
> I hope now things have settled down. I will look at the language for a
> couple of days.  I presume I now only have to look at D2 and Phobos and
> not the previous 4 way split of D1/D2/Phobos/Tango.
> I have a specific engineering application I want to develop. I want to
> pick a programming language that will give me the cleanest and most
> maintainable code possible.  I want to use the IUP GUI library.  That is
> a shared library that has C headers.  I presume I will be able to call
> the dll functions easily in D2? Maybe I will only have to make some
> minimal changes to the C header files to get them to work with D2?

You need to convert the C header files to D modules. Or the actual declarations you want to use. There's a tool available to do that:

https://github.com/jacob-carlborg/dstep

-- 
/Jacob Carlborg
May 31, 2013
On Friday, 31 May 2013 at 07:18:38 UTC, SeanVn wrote:
> I hope now things have settled down.

They have, considerably.


> I will look at the language for a couple of days.  I presume I now only have to look at D2 and Phobos and not the previous 4 way split of D1/D2/Phobos/Tango.

Correct


> I have a specific engineering application I want to develop. I want to pick a programming language that will give me the cleanest and most maintainable code possible.  I want to use the IUP GUI library.  That is a shared library that has C headers.  I presume I will be able to call the dll functions easily in D2?

Yes, shouldn't be any problems there.


> Maybe I will only have to make some minimal changes to the C header files to get them to work with D2?

As Jacob mentioned, there are tools to do this for you. Even without them though, simple header files are pretty trivial to convert.
May 31, 2013
Concerning dstep,

I compiled it recently (Ubuntu 12.04 32 bits system) and it wasn't as straightforward as it was described in the README file, nor was it that complicated to have it work. I'll outline my experience below for those interested.

first step that needed some care was the compilation of Tango-D2: I downloaded the last version that did not compiled on dmd 2.060 but did well on dmd 2.061 (and fast).

When I got dstep compiled, I forgot to run `sudo ldconfig` so that dstep could find libclang.so (this is not a bug nor an annoyance but it may be confusing at first).

Then, (dstep or rather) clang stopped with an error telling me it could not find "stddef.h". A quick google search seemed to indicate that I needed to upgrade from llvm-3.1 to llvm-3.2 to automagically solve that problem.
However, what I really had to do was to find out the include path which on my system is :
 /usr/local/include
 /usr/include
 /usr/include/i386-linux-gnu/
 /home/ray/apps/llvm-3.2/include/clang/   # wherever is installed llvm/clang
 /usr/lib/gcc/i686-linux-gnu/4.6/include/
 /usr/lib/gcc/i686-linux-gnu/4.6/include-fixed/

So I ran dstep like this:
$ ~/dev/dee/dstep/bin/dstep mongoose.h -o mongoose_d.d -v -I/usr/local/include -I/usr/include -I/usr/include/i386-linux-gnu/ -I/home/ray/apps/llmv-3.2/include/clang -I/usr/lib/gcc/i686-linux-gnu/4.6/include/ -I/usr/lib/gcc/i686-linux-gnu/4.6/include-fixed/


I noticed in the output file that an embedded "typedef'ed" struct was not handled very well but fixing this manually went really quick.

Using the output, my Mongoose test program no longer crashes with segfaults due to a mysterious void *user_data pointer being always set to 0x4 in my callback function even when set otherwise at initialization.

In brief: dstep is a huge improvement over manually writing a D header interface.

As for IUP, since I happen to have iup.h on my system, I tried it with dstep. The command line had just to be adjusted, adding the path to the include directory like '-I/path/to/iup/include/dir' or '-I`pwd`' when generating directly within the directory.



On 05/31/2013 10:52 AM, Jacob Carlborg wrote:
> On 2013-05-31 09:18, SeanVn wrote:
>> I looked at the D programming language a few years ago and though it was
>> good.  Then I ran into trouble.  The language was in a state of flux.  I
>> would write code and with the next version of D it would no longer
>> work.  The same thing was happening to people who were writing tools
>> such as IDE's for D and I guess most of them just gave up.
>> That was then.
>> I hope now things have settled down. I will look at the language for a
>> couple of days.  I presume I now only have to look at D2 and Phobos and
>> not the previous 4 way split of D1/D2/Phobos/Tango.
>> I have a specific engineering application I want to develop. I want to
>> pick a programming language that will give me the cleanest and most
>> maintainable code possible.  I want to use the IUP GUI library.  That is
>> a shared library that has C headers.  I presume I will be able to call
>> the dll functions easily in D2? Maybe I will only have to make some
>> minimal changes to the C header files to get them to work with D2?
>
> You need to convert the C header files to D modules. Or the actual
> declarations you want to use. There's a tool available to do that:
>
> https://github.com/jacob-carlborg/dstep
>

June 01, 2013
On Friday, 31 May 2013 at 07:18:38 UTC, SeanVn wrote:
> I looked at the D programming language a few years ago and though it was good.  Then I ran into trouble.  The language was in a state of flux.  I would write code and with the next version of D it would no longer work.  The same thing was happening to people who were writing tools such as IDE's for D and I guess most of them just gave up.
> That was then.
> I hope now things have settled down. I will look at the language for a couple of days.  I presume I now only have to look at D2 and Phobos and not the previous 4 way split of D1/D2/Phobos/Tango.
> I have a specific engineering application I want to develop. I want to pick a programming language that will give me the cleanest and most maintainable code possible.  I want to use the IUP GUI library.  That is a shared library that has C headers.  I presume I will be able to call the dll functions easily in D2?  Maybe I will only have to make some minimal changes to the C header files to get them to work with D2?

I have some where floating around static bindings to IUP.
Includes macros converted as functions as well.
https://bitbucket.org/alphaglosined/libglosined
Take a look under iup directory.
June 01, 2013
On 2013-05-31 23:08, Rémy Mouëza wrote:
> Concerning dstep,
>
> I compiled it recently (Ubuntu 12.04 32 bits system) and it wasn't as
> straightforward as it was described in the README file, nor was it that
> complicated to have it work. I'll outline my experience below for those
> interested.
>
> first step that needed some care was the compilation of Tango-D2: I
> downloaded the last version that did not compiled on dmd 2.060 but did
> well on dmd 2.061 (and fast).

Ok, I see. I haven't updated the readme. The build script will automatically try to use DMD 2.061 if you have DVM installed.

https://github.com/jacob-carlborg/dvm

> When I got dstep compiled, I forgot to run `sudo ldconfig` so that dstep
> could find libclang.so (this is not a bug nor an annoyance but it may be
> confusing at first).

The last command in the instructions for Clang it copies libclang.so to the folder of DStep. This will make the "sudo ldconfig" step unnecessary. I didn't even know about it.

> Then, (dstep or rather) clang stopped with an error telling me it could
> not find "stddef.h". A quick google search seemed to indicate that I
> needed to upgrade from llvm-3.1 to llvm-3.2 to automagically solve that
> problem.

Yeah, I think I had a similar issue. I guess it's time to update to 3.2 or rather 3.3 when it's released.

> However, what I really had to do was to find out the include path which
> on my system is :
>   /usr/local/include
>   /usr/include
>   /usr/include/i386-linux-gnu/
>   /home/ray/apps/llvm-3.2/include/clang/   # wherever is installed
> llvm/clang
>   /usr/lib/gcc/i686-linux-gnu/4.6/include/
>   /usr/lib/gcc/i686-linux-gnu/4.6/include-fixed/
>
> So I ran dstep like this:
> $ ~/dev/dee/dstep/bin/dstep mongoose.h -o mongoose_d.d -v
> -I/usr/local/include -I/usr/include -I/usr/include/i386-linux-gnu/
> -I/home/ray/apps/llmv-3.2/include/clang
> -I/usr/lib/gcc/i686-linux-gnu/4.6/include/
> -I/usr/lib/gcc/i686-linux-gnu/4.6/include-fixed/

I think I just copied the file to /usr/local/include

> I noticed in the output file that an embedded "typedef'ed" struct was
> not handled very well but fixing this manually went really quick.

Could you please file a bug for this. With the C input you used, the output from DStep and the expected output.

> Using the output, my Mongoose test program no longer crashes with
> segfaults due to a mysterious void *user_data pointer being always set
> to 0x4 in my callback function even when set otherwise at initialization.

Great.

> In brief: dstep is a huge improvement over manually writing a D header
> interface.

That's really great to here.

> As for IUP, since I happen to have iup.h on my system, I tried it with
> dstep. The command line had just to be adjusted, adding the path to the
> include directory like '-I/path/to/iup/include/dir' or '-I`pwd`' when
> generating directly within the directory.

Cool. Could you please file a bug for all this, so it's not forgotten.

BTW, there are pre-compiled binaries available:

https://github.com/jacob-carlborg/dstep/downloads

I forgot to add that to the readme.

-- 
/Jacob Carlborg
June 03, 2013
Thanks for all the information. It seems that D2 meets all my requirements.  I have been reading some of the documentation.  It is a extensive language and there is definitely a learning curve for me to overcome.  That is manageable though.
I looked at the Go programming language. The core ideas in that language are good but it is practically useless for designing desktop applications. The specifics of the standard libraries and the rejection of shared libraries mean it is consigned to being a web-server scripting language only.
I am happy that D2 allows me to use 79/80 bit reals, unlike almost every other programming language these days which only allow access to 64 bit floating point numbers.
June 03, 2013
On Monday, 3 June 2013 at 03:36:52 UTC, SeanVN wrote:
> Thanks for all the information. It seems that D2 meets all my requirements.  I have been reading some of the documentation.  It is a extensive language and there is definitely a learning curve for me to overcome.  That is manageable though.
> I looked at the Go programming language. The core ideas in that language are good but it is practically useless for designing desktop applications. The specifics of the standard libraries and the rejection of shared libraries mean it is consigned to being a web-server scripting language only.
> I am happy that D2 allows me to use 79/80 bit reals, unlike almost every other programming language these days which only allow access to 64 bit floating point numbers.

That's great to hear :)

Feel free to post for help with any problems in http://forum.dlang.org/group/digitalmars.D.learn