Ok I know it's v 0.0.1, but I think this bugs are not so difficult to fix:

- d keywords should be escaped  => (for example  int f(int out) should become int f(int _out) or something similar...)
- self alias should be removed  => typedef test { int a; } test; generate alias test test; struct test { int a; };
- struct gives error if used on function ( "xxxx is used as a type")
- variadic function gives errors: "Error: variadic functions with non-D linkage must have at least one parameter"

:)

On Saturday, 7 July 2012 at 14:47:49 UTC, Jacob Carlborg wrote:
> DStep is a tool for translating C and Objective-C headers to D modules. It uses libclang for lexing/parsing and AST traversal. This means it handles everything that Clang itself can handle, although this doesn't mean it will correctly translate everything.
>
> I would consider this release alpha or beta. I'm releasing this now in hope I get some feedback on what language features the tool can't handle.
>
> The tool is available at github:
> https://github.com/jacob-carlborg/dstep
>
> Binaries are available for Mac OS X and Ubuntu 11.10 32bit:
> https://github.com/jacob-carlborg/dstep/downloads
>
> Unfortunately I haven't been able to successfully compile it on Windows due to Optlink not cooperating. I'll most likely provide Linux binaries with better compatibility later.
>
> Build instructions are available at github.
>
> Usage:
>
> dstep <input-file.h> -o output_file.d
>
> For Objective-C
>
> dstep <input-file.h> -o output_file.d -ObjC
>
> Tests:
>
> DStep uses Cucumber and Aruba (Ruby tools) to run its tests. It will basically run the tool on all *.h files in the "test_files" directory and compare the results to the corresponding *.d files.
>
> Known issues/missing functionality:
>
> * Multiple input files
> * Framework as input file
> * Add module declaration
> * Option for specifying before and after code
> * Option for specifying package
> * Windows support
>
> C:
>     * Self includes
>     * Out of order typedefs of structs
>     * Bitfields
>     * Non-standard extensions
>     * Preprocessor
>     * Arrays with no size marked as "extern".
>
> Objective-C:
>     * Protocols
>     * Properties
>     * Blocks
>     * Categories
>     * Actions
>     * Outlets
>     * Selectors
>
> This is basically what's on the todo list:
>
> https://raw.github.com/jacob-carlborg/dstep/master/todo.taskpaper
>
> There's no point in reporting issues which are listed above.

On 2012-07-09 17:49, Andrea Fontana wrote:
> Ok I know it's v 0.0.1, but I think this bugs are not so difficult to fix:
>
> - d keywords should be escaped  => (for example  int f(int out) should
> become int f(int _out) or something similar...)
> - self alias should be removed  => typedef test { int a; } test;
> generate alias test test; struct test { int a; };

I've added this to issues to github: https://github.com/jacob-carlborg/dstep/issues

> - struct gives error if used on function ( "xxxx is used as a type")

I'm not sure I understand what you mean. Do you have an example of the C code and the generated D code.

> - variadic function gives errors: "Error: variadic functions with non-D
> linkage must have at least one parameter"

Do you have an example of the C code that causes this error? DStep should give an error for C code like this:

void foo (...);

File(117B84)foo.h:1:11: error: ISO C requires a named argument before '...'

-- 
/Jacob Carlborg

On 2012-07-08 23:22, Jonathan Andrew wrote:

> The only disadvantage to the single-file limitation is that in the case
> of GTK at least, it has preprocessor directives to keep you from just
> #include-ing the single file you want to convert, so I just used sed to
> strip out all the #error directives that come up and force it to do my
> bidding. I understand DStep doesn't deal with preprocessor yet, but as
> far as the CLang front-end it uses goes, it might be helpful to find a
> way to turn off #error-s.
>
> sed -i 's/#error/\/\//g' *.h

I added an enhancement request for this:

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

> The next step was to rename all the D reserved words that GTK used as
> function arguments - in, out, function, and align are the only ones I
> can think of off the top of my head. Easy fix for the user (by no means
> am I complaining), but if you want to streamline the conversion,
> automatically renaming these kinds of arguments might be a helpful option.

I added this to the issue list as well:

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

> Then, renaming all the duplicate empty struct{} entries in some of the
> files. You already know about this, but it was probably the most
> time-consuming part of the process for converting GTK, at least. I
> couldn't think of an easy way to automate this on my end, because some
> of the empty structs were necessary to get it to compile.

BTW, do you have an example of the C code that causes these empty structs?

> Finally, putting import statements in all the .d files after I was done.
> Still a long way to go on this (500 files).

Imports are already added for most of the files in the C standard library. I plan to add support for other files as well. Hopefully this can be done.

> Sorry for the long post, this is probably obvious stuff to everybody
> else, but I was really impressed with DStep - thank you for creating it!
>
> -Jon


-- 
/Jacob Carlborg

On Monday, 9 July 2012 at 19:24:52 UTC, Jacob Carlborg wrote:
> On 2012-07-09 17:49, Andrea Fontana wrote:
>> - struct gives error if used on function ( "xxxx is used as a type")
>
> I'm not sure I understand what you mean. Do you have an example of the C code and the generated D code.

Ok that was a problem with my struct name conflicting with module name. Sorry!

>> - variadic function gives errors: "Error: variadic functions with non-D
>> linkage must have at least one parameter"
>
> Do you have an example of the C code that causes this error? DStep should give an error for C code like this:
>
> void foo (...);

struct test
{
        int var;
};

struct test* first();

Dstep translate first() =>  first(...) in this case.

On Monday, 9 July 2012 at 19:24:52 UTC, Jacob Carlborg wrote:
> On 2012-07-09 17:49, Andrea Fontana wrote:
>> - struct gives error if used on function ( "xxxx is used as a type")
>
> I'm not sure I understand what you mean. Do you have an example of the C code and the generated D code.

Ok that was a problem with my struct name conflicting with module name. Sorry!

>> - variadic function gives errors: "Error: variadic functions with non-D
>> linkage must have at least one parameter"
>
> Do you have an example of the C code that causes this error? DStep should give an error for C code like this:
>
> void foo (...);

struct test
{
        int var;
};

struct test* first();

Dstep translate first() =>  first(...) in this case.

On 2012-07-10 09:57, Andrea Fontana wrote:

> struct test
> {
> int var;
> };
>
> struct test* first();
>
> Dstep translate first() => first(...) in this case.

As far as I know that is legal C code is a variadic function. It's the old K&R style which is discouraged now but still legal:

http://en.wikipedia.org/wiki/ANSI_C#Compliance_detectability

If you want a function taking no arguments the correct syntax is:

struct test* first (void);

I don't know the best way to deal with that. It's legal C code but not legal D. I could check if there is no parameters and assume that's what the users wants but it's not correct. Perhaps I could provide a flag for this.

-- 
/Jacob Carlborg

On Saturday, 7 July 2012 at 21:20:53 UTC, Walter Bright wrote:
> If it can be made complete enough, I'd like to add support into D for it, so you could do things like:
>
>     import "stdio.h";

I don't think this syntax makes it clear enough. The following has been making rounds in the community for a long time:

    import(C) "stdio.h";

On Monday, 9 July 2012 at 06:30:39 UTC, Jacob Carlborg wrote:
> On 2012-07-08 23:22, Jonathan Andrew wrote:
>
>> Jacob,
>
>> The only disadvantage to the single-file limitation is that in the case
>> of GTK at least, it has preprocessor directives to keep you from just
>> #include-ing the single file you want to convert, so I just used sed to
>> strip out all the #error directives that come up and force it to do my
>> bidding. I understand DStep doesn't deal with preprocessor yet, but as
>> far as the CLang front-end it uses goes, it might be helpful to find a
>> way to turn off #error-s.
>
> I had no idea about that.
>
>> sed -i 's/#error/\/\//g' *.h
>>
>> The next step was to rename all the D reserved words that GTK used as
>> function arguments - in, out, function, and align are the only ones I
>> can think of off the top of my head. Easy fix for the user (by no means
>> am I complaining), but if you want to streamline the conversion,
>> automatically renaming these kinds of arguments might be a helpful option.
>
> I thought the tool did that already.
>
>> Then, renaming all the duplicate empty struct{} entries in some of the
>> files. You already know about this, but it was probably the most
>> time-consuming part of the process for converting GTK, at least. I
>> couldn't think of an easy way to automate this on my end, because some
>> of the empty structs were necessary to get it to compile.
>
> I thought I had fixed this too. I'll have to take a look.
>
>> Finally, putting import statements in all the .d files after I was done.
>> Still a long way to go on this (500 files).
>>
>> Sorry for the long post, this is probably obvious stuff to everybody
>> else, but I was really impressed with DStep - thank you for creating it!
>
> No it's good, this is just what I wanted people to do. It would be great if you could report these issues:
>
> https://github.com/jacob-carlborg/dstep/issues
>
> If you have a simple test case or a header I can try that would be great.

OK, as far as the empty struct-s, it looks like it has to do with typedef struct.
-------------------------------------------------------
//Test.h:

typedef struct _Booger Booger;

//Results in:

-------------------------------------------------------
//Test.d:

extern (C):

alias _Booger Booger;

struct _Booger
{
}

-------------------------------------------------------

If the .h has:

typedef struct _Booger Booger;

struct Booger
{
   int a;
};

The .d will have both the incorrect empty struct and the correct one with the "int a;" declaration.
extern (C):

alias _Booger Booger;

struct _Booger
{
}

struct _Booger
{
   int a;
}

Thanks,
   Jon

> -------------------------------------------------------
>
> If the .h has:
>
> typedef struct _Booger Booger;
>
> struct Booger
> {
>    int a;
> };
>

Oops, typo! should be:

 typedef struct _Booger Booger;

 struct _Booger
 {
    int a;
 };

On 2012-07-11 02:38, Jonathan Andrew wrote:

> OK, as far as the empty struct-s, it looks like it has to do with
> typedef struct.
> -------------------------------------------------------
> //Test.h:
>
> typedef struct _Booger Booger;
>
> //Results in:
>
> -------------------------------------------------------
> //Test.d:
>
> extern (C):
>
> alias _Booger Booger;
>
> struct _Booger
> {
> }
>

Reported as: https://github.com/jacob-carlborg/dstep/issues/4

>
> If the .h has:
>
> typedef struct _Booger Booger;
>
> struct Booger
> {
> int a;
> };
>
> The .d will have both the incorrect empty struct and the correct one
> with the "int a;" declaration.
> extern (C):
>
> alias _Booger Booger;
>
> struct _Booger
> {
> }
>
> struct _Booger
> {
> int a;
> }

This is a known issue, it's on the todo list. I've reported it to github as well: https://github.com/jacob-carlborg/dstep/issues/5

-- 
/Jacob Carlborg