Re: DStep - Bindings Generator 0.0.1
On 2015-02-03 11:01, Chris wrote: And still nobody knows what DStep is all about? BTW, this is a three year old thread someone answered to. It was the initial announcement of DStep. -- /Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
On 2015-02-03 at 14:05, Mike Parker wrote: On 2/3/2015 7:01 PM, Chris wrote: And still nobody knows what DStep is all about? Define nobody. I've known about it for quite a while now. Well, there is someone called nobody on the D forums... :) He might know about DStep, and that would make the sentence true.
Re: DStep - Bindings Generator 0.0.1
On 2/3/2015 7:01 PM, Chris wrote: On Tuesday, 3 February 2015 at 01:35:16 UTC, Paul O'Neil wrote: On 02/02/2015 04:21 AM, Chris wrote: On Saturday, 31 January 2015 at 19:40:49 UTC, Jacob Carlborg wrote: On 2015-01-31 19:38, Chris wrote: At version 0.0.1? :) At version 0.1.0: https://github.com/jacob-carlborg/dstep/releases/tag/v0.1.0 Still loads of time to change the name. If you wanna do it, do it now. I like C.h D :) FYI, this thread started 3 years ago... And still nobody knows what DStep is all about? Define nobody. I've known about it for quite a while now.
Re: DStep - Bindings Generator 0.0.1
On Tuesday, 3 February 2015 at 01:35:16 UTC, Paul O'Neil wrote: On 02/02/2015 04:21 AM, Chris wrote: On Saturday, 31 January 2015 at 19:40:49 UTC, Jacob Carlborg wrote: On 2015-01-31 19:38, Chris wrote: At version 0.0.1? :) At version 0.1.0: https://github.com/jacob-carlborg/dstep/releases/tag/v0.1.0 Still loads of time to change the name. If you wanna do it, do it now. I like C.h D :) FYI, this thread started 3 years ago... And still nobody knows what DStep is all about?
Re: DStep - Bindings Generator 0.0.1
On 02/02/2015 04:21 AM, Chris wrote: On Saturday, 31 January 2015 at 19:40:49 UTC, Jacob Carlborg wrote: On 2015-01-31 19:38, Chris wrote: At version 0.0.1? :) At version 0.1.0: https://github.com/jacob-carlborg/dstep/releases/tag/v0.1.0 Still loads of time to change the name. If you wanna do it, do it now. I like C.h D :) FYI, this thread started 3 years ago... -- Paul O'Neil Github / IRC: todayman
Re: DStep - Bindings Generator 0.0.1
On Saturday, 31 January 2015 at 19:40:49 UTC, Jacob Carlborg wrote: On 2015-01-31 19:38, Chris wrote: At version 0.0.1? :) At version 0.1.0: https://github.com/jacob-carlborg/dstep/releases/tag/v0.1.0 Still loads of time to change the name. If you wanna do it, do it now. I like C.h D :)
Re: DStep - Bindings Generator 0.0.1
On Friday, 30 January 2015 at 20:27:22 UTC, Jacob Carlborg wrote: On 2015-01-30 15:19, Chris wrote: I see what you mean, I'm tired of clever backronyms [1] too. However, DStep is not a product or a company like Apple but a tool with a very specific use. If I look for a tool, I prefer it to have what it does in the name, simply because it's easier to find it with a search engine. E.g. if there is a color picker plugin written in JavaScript, it makes sense that it has the words color and picker or something in the name (JSColorPicker) or so, because that's what you type into the search engine. If someone is wondering if there is an automatic converter form C.h to D, what will s/he type? Probably something like C to D conversion programming or convert C headers/files to D. It's not about aesthetics, it's about being practical. C2D or CtoD (as has been suggested) are the most practical names. C.hD would be a nice pun. I think that changing the name now is too late. At version 0.0.1? :)
Re: DStep - Bindings Generator 0.0.1
On 2015-01-31 19:38, Chris wrote: At version 0.0.1? :) At version 0.1.0: https://github.com/jacob-carlborg/dstep/releases/tag/v0.1.0 -- /Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
On 2015-01-30 15:19, Chris wrote: I see what you mean, I'm tired of clever backronyms [1] too. However, DStep is not a product or a company like Apple but a tool with a very specific use. If I look for a tool, I prefer it to have what it does in the name, simply because it's easier to find it with a search engine. E.g. if there is a color picker plugin written in JavaScript, it makes sense that it has the words color and picker or something in the name (JSColorPicker) or so, because that's what you type into the search engine. If someone is wondering if there is an automatic converter form C.h to D, what will s/he type? Probably something like C to D conversion programming or convert C headers/files to D. It's not about aesthetics, it's about being practical. C2D or CtoD (as has been suggested) are the most practical names. C.hD would be a nice pun. I think that changing the name now is too late. -- /Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
On 2015-01-30 13:50, Chris wrote: I do understand where the name is coming from, but (as has been pointed out by others already) it offers no clue as to what it is doing. Looking at the name it's anybody's guess what it is. It's easier to remember a tool, if it has a reference to what it's all about, e.g. Cygwin, htod. Many projects/companies have completely unrelated names to what they do. I'm tired of trying to come up with cleaver names that have some kind of meaning. What has Phobos to do with D or programming? Nothing about Apple suggests they sell computers. -- /Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
On Friday, 30 January 2015 at 13:46:11 UTC, Jacob Carlborg wrote: On 2015-01-30 13:50, Chris wrote: I do understand where the name is coming from, but (as has been pointed out by others already) it offers no clue as to what it is doing. Looking at the name it's anybody's guess what it is. It's easier to remember a tool, if it has a reference to what it's all about, e.g. Cygwin, htod. Many projects/companies have completely unrelated names to what they do. I'm tired of trying to come up with cleaver names that have some kind of meaning. What has Phobos to do with D or programming? Nothing about Apple suggests they sell computers. I see what you mean, I'm tired of clever backronyms [1] too. However, DStep is not a product or a company like Apple but a tool with a very specific use. If I look for a tool, I prefer it to have what it does in the name, simply because it's easier to find it with a search engine. E.g. if there is a color picker plugin written in JavaScript, it makes sense that it has the words color and picker or something in the name (JSColorPicker) or so, because that's what you type into the search engine. If someone is wondering if there is an automatic converter form C.h to D, what will s/he type? Probably something like C to D conversion programming or convert C headers/files to D. It's not about aesthetics, it's about being practical. C2D or CtoD (as has been suggested) are the most practical names. C.hD would be a nice pun. [1] https://en.wikipedia.org/wiki/Backronym
Re: DStep - Bindings Generator 0.0.1
Thank you! I'm working on an adaptation of 7-zip for Phobos, and I very hope that DStep help me with this! P.S. Sorry for my runglish! On Friday, 30 January 2015 at 07:48:40 UTC, Jacob Carlborg wrote: On 2015-01-30 03:32, data man wrote: Please, compile for Win32. This issue has been libclang. Might be easier now that DMD supports Win32 COFF.
Re: DStep - Bindings Generator 0.0.1
On 2015-01-30 13:01, Chris wrote: Just brain storming (i.e. some output may be nonsense): - dimp [1] (D + import) [2] - dimpc (pronounced dimps) - dimplink - cimport - cimpleD - DiCe (D importing C external / extensions - you would want the 'e' at the end ;)) - CeeD (as in seed) - CeDe I think I'm going to stick with DStep. [1] https://en.wiktionary.org/wiki/dimp#English [2] in case it will go beyond C/Obj-C, we need no reference to C It will hopefully support C++ as well. -- /Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
On Friday, 30 January 2015 at 12:43:14 UTC, Jacob Carlborg wrote: On 2015-01-30 13:01, Chris wrote: Just brain storming (i.e. some output may be nonsense): - dimp [1] (D + import) [2] - dimpc (pronounced dimps) - dimplink - cimport - cimpleD - DiCe (D importing C external / extensions - you would want the 'e' at the end ;)) - CeeD (as in seed) - CeDe I think I'm going to stick with DStep. I do understand where the name is coming from, but (as has been pointed out by others already) it offers no clue as to what it is doing. Looking at the name it's anybody's guess what it is. It's easier to remember a tool, if it has a reference to what it's all about, e.g. Cygwin, htod. [1] https://en.wiktionary.org/wiki/dimp#English [2] in case it will go beyond C/Obj-C, we need no reference to C It will hopefully support C++ as well.
Re: DStep - Bindings Generator 0.0.1
On Sunday, 8 July 2012 at 20:01:07 UTC, Jacob Carlborg wrote: Do you have a suggestion? Just brain storming (i.e. some output may be nonsense): - dimp [1] (D + import) [2] - dimpc (pronounced dimps) - dimplink - cimport - cimpleD - DiCe (D importing C external / extensions - you would want the 'e' at the end ;)) - CeeD (as in seed) - CeDe Just think of some words starting with 's', 'c' or 'd' (or ending in 'd') PS cd won't work :) PPS Great project! [1] https://en.wiktionary.org/wiki/dimp#English [2] in case it will go beyond C/Obj-C, we need no reference to C
Re: DStep - Bindings Generator 0.0.1
Please, compile for Win32.
Re: DStep - Bindings Generator 0.0.1
On 2015-01-30 03:32, data man wrote: Please, compile for Win32. This issue has been libclang. Might be easier now that DMD supports Win32 COFF. -- /Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
On 2012-07-20 16:58, Andrej Mitrovic wrote: Cool, this will come in handy. Thanks. If your interested you can help out with DStep, add C++ support or similar :) -- /Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
On 7/22/12, Jacob Carlborg d...@me.com wrote: On 2012-07-20 16:58, Andrej Mitrovic wrote: Cool, this will come in handy. Thanks. If your interested you can help out with DStep, add C++ support or similar :) -- /Jacob Carlborg Well I'm already working on my own code generator. It's based on gccxml, which exports less information than clang but it's still enough info to get around. But my design is the polar opposite of dstep. I rely heavily on things like static foreach, templates, etc. Still, there's a lot I've learned and I'd like to document the details of wrapping C++ once I'm done. So if/when you start adding C++ support to dstep you'll have a nice reference manual of sorts which should help you get up and started. :)
Re: DStep - Bindings Generator 0.0.1
On 7/7/12, Jacob Carlborg d...@me.com wrote:
snip
Nice work!
Can I ask you something? Do you know if (lib)clang exports typeinfo
for default values? For example:
namespace Foo
{
enum En
{
Val1,
Val2
};
}
void test(int x = Foo::Val1) { }
'x' has typeinfo (it's an int), but I'm interested in the typeinfo for
the default value Foo::Val1. In other tools (like gccxml) the
default value is exported as a string which makes generating default
values in D hard (not impossible but just hard).
Re: DStep - Bindings Generator 0.0.1
On 2012-07-20 15:04, Andrej Mitrovic wrote:
Nice work!
Thanks.
Can I ask you something? Do you know if (lib)clang exports typeinfo
for default values? For example:
namespace Foo
{
enum En
{
Val1,
Val2
};
}
void test(int x = Foo::Val1) { }
'x' has typeinfo (it's an int), but I'm interested in the typeinfo for
the default value Foo::Val1. In other tools (like gccxml) the
default value is exported as a string which makes generating default
values in D hard (not impossible but just hard).
Don't know, sorry. I have only worked with C and Objective-C code. I can
see if I can find out.
--
/Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
On 2012-07-20 15:04, Andrej Mitrovic wrote:
On 7/7/12, Jacob Carlborg d...@me.com wrote:
snip
Nice work!
Can I ask you something? Do you know if (lib)clang exports typeinfo
for default values? For example:
namespace Foo
{
enum En
{
Val1,
Val2
};
}
void test(int x = Foo::Val1) { }
'x' has typeinfo (it's an int), but I'm interested in the typeinfo for
the default value Foo::Val1. In other tools (like gccxml) the
default value is exported as a string which makes generating default
values in D hard (not impossible but just hard).
In libclang, the kind of Foo::Val1 in the above example is:
CXCursor_FirstExpr - CXCursor_DeclRefExpr - CXCursor_NamespaceRef.
What I did here was I checked the kind of Foo::Val1 cursor, drilled
down into the cursor children as far as possible.
Cursor kinds:
http://clang.llvm.org/doxygen/group__CINDEX.html#gaaccc432245b4cd9f2d470913f9ef0013
--
/Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
On 7/20/12, Jacob Carlborg d...@me.com wrote: In libclang, the kind of Foo::Val1 in the above example is: CXCursor_FirstExpr - CXCursor_DeclRefExpr - CXCursor_NamespaceRef. What I did here was I checked the kind of Foo::Val1 cursor, drilled down into the cursor children as far as possible. Cursor kinds: http://clang.llvm.org/doxygen/group__CINDEX.html#gaaccc432245b4cd9f2d470913f9ef0013 Cool, this will come in handy. Thanks.
Re: DStep - Bindings Generator 0.0.1
On 7/7/12, Walter Bright newshou...@digitalmars.com wrote: so you could do things like: import stdio.h; and the D compile would fork/exec Dstep, generate the corresponding .d file, and import the .d file. Personally I think this is heading in the wrong direction. A D user shouldn't have to deal with C syntax or peculiarities of wrapper libraries, the experience of using a wrapper library should be as transparent as possible. Such a wrapper library should look just like any other D library to the user. Wrapper maintainers can use tools to generate bindings, and the users might have their own tools such as a package manager to make discovery installation of those libraries easy. There's compile-time performance issues to consider. Sure, you could cache the results of generating a library, but this is still a penalty because every user will have to wait for that import statement to finish the first time and cache the results before they can use the library, as opposed to the traditional way of downloading a maintained wrapper library which you don't have to re-wrap but just need to compile. I don't mean to sound discouraging, and this all might work for simple C libraries and Dstep, but there's a penalty for introducing special syntax and semantics into D for something that can be and is usually done externally by wrapper maintainers (think how we're always trying to move things away from the D language and replace it with more flexible and more easily debuggable library features). Maybe this feature would look great in a D vs Go comparison table, but I don't see the benefit of such a magical feature. I'd rather we have a package manager instead, which incidentally again Jacob is working on. Incidentally I'm also working on my own wrapper generator, although this one handles C and C++. But it won't be done soon (it's close though).
Re: DStep - Bindings Generator 0.0.1
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 ( 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.
Re: DStep - Bindings Generator 0.0.1
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 ( 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.
Re: DStep - Bindings Generator 0.0.1
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 KR 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
Re: DStep - Bindings Generator 0.0.1
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;
Re: DStep - Bindings Generator 0.0.1
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
Re: DStep - Bindings Generator 0.0.1
---
If the .h has:
typedef struct _Booger Booger;
struct Booger
{
int a;
};
Oops, typo! should be:
typedef struct _Booger Booger;
struct _Booger
{
int a;
};
Re: DStep - Bindings Generator 0.0.1
What do people do in OC makefiles? With Clang you can use the -ObjC or -x objective-c flags. But I guess most people use Xcode and not makefiles. CtoD ? I'll have to think about it. -- /Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
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.
--
/Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
Jacob Carlborg , dans le message (digitalmars.D.announce:23893), a écrit : What do people do in OC makefiles? With Clang you can use the -ObjC or -x objective-c flags. But I guess most people use Xcode and not makefiles. CtoD ? I'll have to think about it. -- /Jacob Carlborg CtoDi ? I suppose the tool translates interface only, not the code.
Re: DStep - Bindings Generator 0.0.1
On Monday, 9 July 2012 at 07:27:35 UTC, trav...@phare.normalesup.org (Christophe Travert) wrote: Jacob Carlborg , dans le message (digitalmars.D.announce:23893), a écrit : What do people do in OC makefiles? With Clang you can use the -ObjC or -x objective-c flags. But I guess most people use Xcode and not makefiles. CtoD ? I'll have to think about it. -- /Jacob Carlborg CtoDi ? I suppose the tool translates interface only, not the code. If I were him, I would choose cited
Re: DStep - Bindings Generator 0.0.1
On 2012-07-09 09:27, Christophe Travert wrote: CtoDi ? I suppose the tool translates interface only, not the code. Yes, only declarations. -- /Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
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 ( 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.
Re: DStep - Bindings Generator 0.0.1
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 ( 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
Re: DStep - Bindings Generator 0.0.1
On 7/7/2012 7:59 PM, Andrei Alexandrescu wrote: On 7/7/12 5:20 PM, Walter Bright wrote: In fact, we could make it a general facility, where if D sees: import filename.ext; that it fork/exec's the program: ext_to_D filename.ext tmpfile.d and them imports tmpfile.d. (Aside) This has an obvious security risk. Yup. It's similar to the import arbitrary file as string feature. We can leave it disabled unless -J is used.
Re: DStep - Bindings Generator 0.0.1
On 7/7/2012 8:40 PM, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/w7hbg/dstep_tool_for_translating_c_and_objc_headers/ Gotta change the name: http://www.reddit.com/r/programming/comments/w7hbg/dstep_tool_for_translating_c_and_objc_headers/c5az51y
Re: DStep - Bindings Generator 0.0.1
On Sunday, 8 July 2012 at 08:36:34 UTC, Walter Bright wrote: On 7/7/2012 8:40 PM, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/w7hbg/dstep_tool_for_translating_c_and_objc_headers/ Gotta change the name: http://www.reddit.com/r/programming/comments/w7hbg/dstep_tool_for_translating_c_and_objc_headers/c5az51y Just make it drop when you're done translating the file.
Re: DStep - Bindings Generator 0.0.1
On 2012-07-07 23:20, Walter Bright wrote: I think this is potentially a big deal. 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; and the D compile would fork/exec Dstep, generate the corresponding .d file, and import the .d file. How is this going to work, is it going to be an optional feature? I mean, this will add DStep (D and Clang) as dependencies to DMD. DStep is built to be used as a library, I can easily create a C API which can be used directly by DMD. No need for creating a new process. I can also make DStep give back the translate D code, no need for creating temporarily D files. BTW, how would you indicate that the header file is an Objective-C file? Since both C and Objective-C uses the same extension for header files, this is required by Clang, otherwise it will treat the file as a C file. Some issues: 1. Passing macro definitions to Dstep Yeah, this will be the hardest. The main problem now is that libclang (the stable C API) doesn't have an API for handling macros. 2. The name Dstep has no obvious relationship to what it does. No it does not, but I'm tired of trying to come up with cleaver names for tools and libraries. Here's the story behind the name for those who are interested: DStep started out as another project, as a D-Objective-C bridge: http://dsource.org/projects/dstep In that project I had a tool for converting C/Objective-c headers to D modules. This tool was a Ruby script based on BridgeSupport. This is a complete rewrite of that tool. The whole project was called DStep and the name fit among other Objective-C related names like NeXTSTEP, OpenStep and GNUStep. 3. The -o flag is not necessary. Just do the right thing when you see the filename extension. That can be easily fixed. In fact, we could make it a general facility, where if D sees: import filename.ext; that it fork/exec's the program: ext_to_D filename.ext tmpfile.d and them imports tmpfile.d. -- /Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
On 2012-07-08 04:59, Andrei Alexandrescu wrote: On 7/7/12 5:20 PM, Walter Bright wrote: In fact, we could make it a general facility, where if D sees: import filename.ext; that it fork/exec's the program: ext_to_D filename.ext tmpfile.d and them imports tmpfile.d. (Aside) This has an obvious security risk. Andrei Don't know if it helps but the tool can be easily used as a library and wrapped in a C API. Then DMD can used the tool directory like a library. No need for creating a new process and writing temporary files. -- /Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
On 7/8/2012 4:15 AM, Jacob Carlborg wrote: Don't know if it helps but the tool can be easily used as a library and wrapped in a C API. Then DMD can used the tool directory like a library. No need for creating a new process and writing temporary files. Creating a new process has its advantages: 1. Bugs from one process won't propagate to another. 2. The programmer of that process can develop completely independently of the D compiler.
Re: DStep - Bindings Generator 0.0.1
On 7/8/2012 4:13 AM, Jacob Carlborg wrote: How is this going to work, is it going to be an optional feature? I mean, this will add DStep (D and Clang) as dependencies to DMD. I think that implicitly using the feature will depend on those programs being available. It also means that any 3rd party can supply such a feature, to import a file in any format. DStep is built to be used as a library, I can easily create a C API which can be used directly by DMD. No need for creating a new process. I can also make DStep give back the translate D code, no need for creating temporarily D files. I think there are many advantages to DStep being a separate program, not the least of which is debugging the output of it. Also, it means DStep could be written in any language. For example, suppose a Go-to-D is proposed. Go provides a Go library to parse Go code - so such a tool might be more easily written in Go than in D. BTW, how would you indicate that the header file is an Objective-C file? Since both C and Objective-C uses the same extension for header files, this is required by Clang, otherwise it will treat the file as a C file. Since OC is a proper superset of C, this shouldn't be a problem. Just run the OC converter as your C compiler. In that project I had a tool for converting C/Objective-c headers to D modules. This tool was a Ruby script based on BridgeSupport. This is a complete rewrite of that tool. The whole project was called DStep and the name fit among other Objective-C related names like NeXTSTEP, OpenStep and GNUStep. The name makes more sense now, but for marketing reasons it should give more of a clue as to what it does.
Re: DStep - Bindings Generator 0.0.1
Jacob Carlborg, el 8 de July a las 13:13 me escribiste: On 2012-07-07 23:20, Walter Bright wrote: I think this is potentially a big deal. 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; and the D compile would fork/exec Dstep, generate the corresponding .d file, and import the .d file. How is this going to work, is it going to be an optional feature? I mean, this will add DStep (D and Clang) as dependencies to DMD. DStep is built to be used as a library, I can easily create a C API which can be used directly by DMD. No need for creating a new process. I can also make DStep give back the translate D code, no need for creating temporarily D files. This can also be done by just dumping the generated code to stdout. Then any application can use the output without using any temporary files. Pipes for the win! -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Me encanta el éxito; por eso prefiero el estado de progreso constante, con la meta al frente y no atrás. -- Ricardo Vaporeso. Punta del Este, Enero de 1918.
Re: DStep - Bindings Generator 0.0.1
On 7/8/12 3:05 PM, Leandro Lucarella wrote: Jacob Carlborg, el 8 de July a las 13:13 me escribiste: On 2012-07-07 23:20, Walter Bright wrote: I think this is potentially a big deal. 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; and the D compile would fork/exec Dstep, generate the corresponding .d file, and import the .d file. How is this going to work, is it going to be an optional feature? I mean, this will add DStep (D and Clang) as dependencies to DMD. DStep is built to be used as a library, I can easily create a C API which can be used directly by DMD. No need for creating a new process. I can also make DStep give back the translate D code, no need for creating temporarily D files. This can also be done by just dumping the generated code to stdout. Then any application can use the output without using any temporary files. Pipes for the win! Good old date checks (makefile style) can be used for the win. Andrei
Re: DStep - Bindings Generator 0.0.1
On 2012-07-08 20:42, Walter Bright wrote: I think that implicitly using the feature will depend on those programs being available. It also means that any 3rd party can supply such a feature, to import a file in any format. I see. I think there are many advantages to DStep being a separate program, not the least of which is debugging the output of it. Also, it means DStep could be written in any language. For example, suppose a Go-to-D is proposed. Go provides a Go library to parse Go code - so such a tool might be more easily written in Go than in D. DStep is both usable as a program and a library. Both I guess you have a point. On the other hand, C can be used to glue together libraries written in different languages. Since OC is a proper superset of C, this shouldn't be a problem. Just run the OC converter as your C compiler. That is not completely true if one is picky. The following code is legal C, but not legal Objective-C : int id; int nil; In Objective-C id is a type. The name makes more sense now, but for marketing reasons it should give more of a clue as to what it does. Do you have a suggestion? -- /Jacob Carlborg
Re: DStep - Bindings Generator 0.0.1
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.
Jacob,
I just used your tool to try and convert the GTK 3.0 include
files into D stubs, and wanted to say that it worked pretty darn
well. As a matter of practice, the single file limitation wasn't
too much of a problem - I hacked together a script to just go
through all the .h files and put the outputs in the right place.
D has become my new favorite scripting language, BTW!
For anybody who cares - here's how I went about it. This is
probably the most ignorant and least efficient method possible,
but it worked for me to at least display a little window (yay.).
#!/usr/bin/rdmd
import std.stdio;
import std.string;
import std.process;
int main(string[] args)
{
foreach(string word; args[1..$])
{
string cmd = format(dstep /home/jon/devel/gtk-include/%s -o
/home/jon/devel/gtk-include/d/%s.d -v -I./ -I./glib-2.0/ -I./gdk/
-I./gdk-pixbuf/ -I/usr/lib/gcc/i686-linux-gnu/4.6/include/
-I/usr/include/pango-1.0/ -I/usr/include/cairo/
-I/usr/include/atk-1.0/, word, chomp(word,.h));
writefln(%s,cmd);
system(cmd);
}
return 0;
}
Run with ./convert.d folder/*.h
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
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.
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.
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!
-Jon
Re: DStep - Bindings Generator 0.0.1
On Sunday, 8 July 2012 at 20:01:07 UTC, Jacob Carlborg wrote: On 2012-07-08 20:42, Walter Bright wrote: Since OC is a proper superset of C, this shouldn't be a problem. Just run the OC converter as your C compiler. That is not completely true if one is picky. The following code is legal C, but not legal Objective-C : int id; int nil; In Objective-C id is a type. I suppose this symptom will repeat in the future. I mean, for a particular file extension there may be several code importers. An (exotic?) example might be when some existing code uses one converter, but for some reason new code should use a different one. What about using the something like this: mixin convertImport!header.h; with ability to specify a particular converter as second template parameter?
Re: DStep - Bindings Generator 0.0.1
On Sunday, 8 July 2012 at 22:13:27 UTC, Roman D. Boiko wrote: What about using the something like this: mixin convertImport!header.h; with ability to specify a particular converter as second template parameter? Oh, completely forgot to mention that inside mixin there could be a pragma for compiler instructing it to execute conversion.
Re: DStep - Bindings Generator 0.0.1
On 09-Jul-12 02:13, Roman D. Boiko wrote: On Sunday, 8 July 2012 at 20:01:07 UTC, Jacob Carlborg wrote: On 2012-07-08 20:42, Walter Bright wrote: Since OC is a proper superset of C, this shouldn't be a problem. Just run the OC converter as your C compiler. That is not completely true if one is picky. The following code is legal C, but not legal Objective-C : int id; int nil; In Objective-C id is a type. I suppose this symptom will repeat in the future. I mean, for a particular file extension there may be several code importers. An (exotic?) example might be when some existing code uses one converter, but for some reason new code should use a different one. What about using the something like this: mixin convertImport!header.h; Ineffective even in distant future. Fixed functionality (=compiled, native, etc.) is faster and more practical. E.g. the above was possible already for something like a year (no less) the exact magic is: mixin(translate(import(file.ext)); But it never scaled to reasonably sized inputs/amounts of files like translating headers. with ability to specify a particular converter as second template parameter? However something like : import file.ext, FancyImporter; could work and call some 'FancyImporter' for compiler's tools directory to produce file.di I think extra syntax could be added easily WHEN the need arrives, so far 1:1 converters to extension feels fine. -- Dmitry Olshansky
Re: DStep - Bindings Generator 0.0.1
On Sunday, July 08, 2012 01:36:14 Walter Bright wrote: On 7/7/2012 8:40 PM, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/w7hbg/dstep_tool_for_translat ing_c_and_objc_headers/ Gotta change the name: c2d? - Jonathan M Davis
Re: DStep - Bindings Generator 0.0.1
On 7/8/2012 1:01 PM, Jacob Carlborg wrote: That is not completely true if one is picky. The following code is legal C, but not legal Objective-C : int id; int nil; In Objective-C id is a type. What do people do in OC makefiles? The name makes more sense now, but for marketing reasons it should give more of a clue as to what it does. Do you have a suggestion? CtoD ?
Re: DStep - Bindings Generator 0.0.1
On 7/8/2012 3:27 PM, Dmitry Olshansky wrote: I think extra syntax could be added easily WHEN the need arrives, so far 1:1 converters to extension feels fine. I don't think CTFE is good enough to parse C code in all its complex glory - and it would be 1000 times too slow if it did.
Re: DStep - Bindings Generator 0.0.1
On Sunday, July 08, 2012 18:39:54 Walter Bright wrote: On 7/8/2012 3:27 PM, Dmitry Olshansky wrote: I think extra syntax could be added easily WHEN the need arrives, so far 1:1 converters to extension feels fine. I don't think CTFE is good enough to parse C code in all its complex glory - and it would be 1000 times too slow if it did. Unless you need to get at an external program or file, I would fully expect to be able to write a fully functional C parser using only CTFE-usable constructs. However, I expect that it would be disgusting to do so, and as you say, it would be horribly inefficient. - Jonathan M Davis
Re: DStep - Bindings Generator 0.0.1
On 7/8/12 9:39 PM, Walter Bright wrote: On 7/8/2012 3:27 PM, Dmitry Olshansky wrote: I think extra syntax could be added easily WHEN the need arrives, so far 1:1 converters to extension feels fine. I don't think CTFE is good enough to parse C code in all its complex glory disagree - and it would be 1000 times too slow if it did. agree (for now) Andrei
Re: DStep - Bindings Generator 0.0.1
On 7/7/2012 7:47 AM, 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. I think this is potentially a big deal. 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; and the D compile would fork/exec Dstep, generate the corresponding .d file, and import the .d file. Some issues: 1. Passing macro definitions to Dstep 2. The name Dstep has no obvious relationship to what it does. 3. The -o flag is not necessary. Just do the right thing when you see the filename extension. In fact, we could make it a general facility, where if D sees: import filename.ext; that it fork/exec's the program: ext_to_D filename.ext tmpfile.d and them imports tmpfile.d.
Re: DStep - Bindings Generator 0.0.1
Wow at long last! On Saturday, 7 July 2012 at 21:20:53 UTC, Walter Bright wrote: On 7/7/2012 7:47 AM, 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. I think this is potentially a big deal. 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; and the D compile would fork/exec Dstep, generate the corresponding .d file, and import the .d file. Some issues: 1. Passing macro definitions to Dstep 2. The name Dstep has no obvious relationship to what it does. 3. The -o flag is not necessary. Just do the right thing when you see the filename extension. In fact, we could make it a general facility, where if D sees: import filename.ext; that it fork/exec's the program: ext_to_D filename.ext tmpfile.d and them imports tmpfile.d.
Re: DStep - Bindings Generator 0.0.1
On 07/07/12 23:20, Walter Bright wrote: In fact, we could make it a general facility, where if D sees: import filename.ext; that it fork/exec's the program: ext_to_D filename.ext tmpfile.d and them imports tmpfile.d. import extern (C) stdio.h; which execs dimport_C stdio.h which returns a filename of a D module, which is then imported. This way the importer can cache the result and doesn't need to regenerate the D module until stdio.h or any dependency changes. artur
Re: DStep - Bindings Generator 0.0.1
On 7/7/12 5:20 PM, Walter Bright wrote: In fact, we could make it a general facility, where if D sees: import filename.ext; that it fork/exec's the program: ext_to_D filename.ext tmpfile.d and them imports tmpfile.d. (Aside) This has an obvious security risk. Andrei
Re: DStep - Bindings Generator 0.0.1
On 7/7/12 10:47 AM, Jacob Carlborg wrote: DStep is a tool for translating C and Objective-C headers to D modules. Awesome! On reddit: http://www.reddit.com/r/programming/comments/w7hbg/dstep_tool_for_translating_c_and_objc_headers/ Andrei
