www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - luajit-ffi

reply "so" <so so.so> writes:
http://luajit.org/ext_ffi.html
https://github.com/malkia/ufo

How awesome is Mike Pall?
I didn't dive into details of the code, but if he can do this 
with a dynamic language, why on earth D still need manual C 
bindings while having ABI compatibility? So luajit comes with a C 
compiler?
May 01 2012
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 01/05/2012 16:24, so wrote:
 http://luajit.org/ext_ffi.html
 https://github.com/malkia/ufo

 How awesome is Mike Pall?
 I didn't dive into details of the code, but if he can do this with a
 dynamic language, why on earth D still need manual C bindings while
 having ABI compatibility? So luajit comes with a C compiler?

Note that you can't just drop any C header file in there for that to work (as far as I can tell), you still have to bring out individual post-processed function declarations. Also, someone has written a libffi binding for D, which could probably be adapted to work in a similar manor: https://github.com/lycus/libffi-d -- Robert http://octarineparrot.com/
May 01 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 17:31, Robert Clipsham wrote:
 On 01/05/2012 16:24, so wrote:
 http://luajit.org/ext_ffi.html
 https://github.com/malkia/ufo

 How awesome is Mike Pall?
 I didn't dive into details of the code, but if he can do this with a
 dynamic language, why on earth D still need manual C bindings while
 having ABI compatibility? So luajit comes with a C compiler?

Note that you can't just drop any C header file in there for that to work (as far as I can tell), you still have to bring out individual post-processed function declarations.

Note in particular that the message box example used a preprocessed version of the MessageBoxA declaration.
 Also, someone has written a libffi binding for D, which could probably
 be adapted to work in a similar manor:

 https://github.com/lycus/libffi-d

If you have a C parser (libclang?), it's probably entirely doable. -- - Alex
May 01 2012
prev sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 17:43, so wrote:
 On Tuesday, 1 May 2012 at 15:31:05 UTC, Robert Clipsham wrote:
 On 01/05/2012 16:24, so wrote:
 http://luajit.org/ext_ffi.html
 https://github.com/malkia/ufo

 How awesome is Mike Pall?
 I didn't dive into details of the code, but if he can do this with a
 dynamic language, why on earth D still need manual C bindings while
 having ABI compatibility? So luajit comes with a C compiler?

Note that you can't just drop any C header file in there for that to work (as far as I can tell), you still have to bring out individual post-processed function declarations.

https://github.com/malkia/ufo/blob/master/ffi/OpenCL.lua https://github.com/malkia/ufo/blob/master/ffi/OpenGL.lua If it can handle these 2 beasts.

I see no preprocessor directives.
 Also, someone has written a libffi binding for D, which could probably
 be adapted to work in a similar manor:

 https://github.com/lycus/libffi-d

Neat. Still, having native C libraries means that you can just drop your C/C++ environment and start D. And i am sure you agree this is by far the biggest blocker for C/C++ developers.

I'm not sure what you're trying to say here. Elaborate/rephrase? -- - Alex
May 01 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 18:08, so wrote:
 On Tuesday, 1 May 2012 at 15:53:37 UTC, Alex Rønne Petersen wrote:
 On 01-05-2012 17:43, so wrote:
 On Tuesday, 1 May 2012 at 15:31:05 UTC, Robert Clipsham wrote:
 On 01/05/2012 16:24, so wrote:
 http://luajit.org/ext_ffi.html
 https://github.com/malkia/ufo

 How awesome is Mike Pall?
 I didn't dive into details of the code, but if he can do this with a
 dynamic language, why on earth D still need manual C bindings while
 having ABI compatibility? So luajit comes with a C compiler?

Note that you can't just drop any C header file in there for that to work (as far as I can tell), you still have to bring out individual post-processed function declarations.

https://github.com/malkia/ufo/blob/master/ffi/OpenCL.lua https://github.com/malkia/ufo/blob/master/ffi/OpenGL.lua If it can handle these 2 beasts.

I see no preprocessor directives.

They are all there as "enum".

That has nothing to do with the C preprocessor... The point here is that you can't just copy/paste a C header into LuaJIT's FFI out of the box. You have to run the preprocessor on it first, or preprocess it by hand.
 Also, someone has written a libffi binding for D, which could probably
 be adapted to work in a similar manor:

 https://github.com/lycus/libffi-d

Neat. Still, having native C libraries means that you can just drop your C/C++ environment and start D. And i am sure you agree this is by far the biggest blocker for C/C++ developers.

I'm not sure what you're trying to say here. Elaborate/rephrase?

For example in my projects i implement different tasks in different libraries. All of them have C interfaces. With something like this i could just access these libraries as i am accessing in C/C++. Then why do i need to go on using C/C++? Transition would be seamless. You can say just write the damn bindings and be done with it. But it is neither scalable nor maintainable.

Let's be realistic. In practice, you can almost never just copy/paste a C header into LuaJIT's FFI. Even a header guard (#ifndef FOO \ #define FOO \ ... \ #endif) will ruin it. The fundamental problem is the C preprocessor. The best you can do is take your C header, preprocess it with cpp, and then pass it to LuaJIT and hope nothing breaks. Usually, not even an approach like that will work because of weird compiler extensions used in headers which aren't stripped by cpp. In an ideal world where no compiler extensions existed, this might have had a chance of working, but we all know what the situation with C and C++ is. Yes, creating manual bindings is tedious and annoying to maintain, but it is the most foolproof approach. -- - Alex
May 01 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 18:47, so wrote:
 On Tuesday, 1 May 2012 at 16:31:09 UTC, Alex Rønne Petersen wrote:

 That has nothing to do with the C preprocessor... The point here is
 that you can't just copy/paste a C header into LuaJIT's FFI out of the
 box.

Well i didn't say you can. But D have great advantages over Lua to be able to do that and much more.

D still can't solve the preprocessor problem, so I don't see how it would be any easier for D than it is for LuaJIT.
 Let's be realistic.

 In practice, you can almost never just copy/paste a C header into
 LuaJIT's FFI. Even a header guard (#ifndef FOO \ #define FOO \ ... \
 #endif) will ruin it. The fundamental problem is the C preprocessor.
 The best you can do is take your C header, preprocess it with cpp, and
 then pass it to LuaJIT and hope nothing breaks. Usually, not even an
 approach like that will work because of weird compiler extensions used
 in headers which aren't stripped by cpp.

Again, you can't do that in lua but you should be able to do it in D.

No, D really can't solve the preprocessor problem. It's not as simple as you think. D does not have any more knowledge about the C compiler intended to compile the C library (or the parameters passed to it) than LuaJIT does.
 If you check some lua bindings, libraries tries to simplify the process,
 all the duplicate stuff they do on tons of different projects. All for
 nothing, and i am sure this is true for many other languages. And then
 you see luajit-ffi, gives both performance boost and soooo much clean code.

 This discussion came up before and preprocessor was the only serious
 blocker. But if you support it to the level what mature C libraries use,
 which means simple alias and enum you have them all.

See my reply to your other post for why this is not sufficient for the majority of C libraries.
 In an ideal world where no compiler extensions existed, this might
 have had a chance of working, but we all know what the situation with
 C and C++ is.

I am not sure if C++ had quarter of its user base if it didn't work with C seamlessly.

If C++ didn't have C "support", it would probably never have been adopted at all. But I never claimed otherwise.
 Yes, creating manual bindings is tedious and annoying to maintain, but
 it is the most foolproof approach.

In another language there may not be other exit but D, i am not sure.

-- - Alex
May 01 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 17:24, so wrote:
 http://luajit.org/ext_ffi.html
 https://github.com/malkia/ufo

 How awesome is Mike Pall?
 I didn't dive into details of the code, but if he can do this with a
 dynamic language, why on earth D still need manual C bindings while
 having ABI compatibility? So luajit comes with a C compiler?

Parsing a C header is relatively easy; don't need a full compiler for that. It's what htod does. I don't know what you mean by "manual bindings", but keep in mind that: 1) We *don't* want to embed some kind of crazy C syntax in D. 2) In D, we want statically bound C function calls. Lua is a dynamic language. 3) LuaJIT will have the same problems as htod: Preprocessor definitions. -- - Alex
May 01 2012
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 17:50, so wrote:
 On Tuesday, 1 May 2012 at 15:32:40 UTC, Alex Rønne Petersen wrote:
 On 01-05-2012 17:24, so wrote:
 http://luajit.org/ext_ffi.html
 https://github.com/malkia/ufo

 How awesome is Mike Pall?
 I didn't dive into details of the code, but if he can do this with a
 dynamic language, why on earth D still need manual C bindings while
 having ABI compatibility? So luajit comes with a C compiler?

Parsing a C header is relatively easy; don't need a full compiler for that. It's what htod does. I don't know what you mean by "manual bindings", but keep in mind that: 1) We *don't* want to embed some kind of crazy C syntax in D. 2) In D, we want statically bound C function calls. Lua is a dynamic language.

It has nothing to do with syntax, D already can call C functions directly, and have all the structures.

What are you talking about? The link you posted clearly shows that LuaJIT has a C parser built in. It has everything to do with syntax (note that FFI is not anything spectacular or innovative; see libffi, Mono, Lisp, ...). And no, D does not "have all the structures". If it did, we wouldn't be redefining them in D bindings.
 3) LuaJIT will have the same problems as htod: Preprocessor definitions.

We can just support enum and simple alias capabilities of C PP and most if not all the popular C libraries would be in D arsenal. I haven't seen many serious C APIs that exploit PP more than these simple tasks.

What does enum have to do with the C preprocessor? Anyway, it's not that simple. Any arbitrary symbol can have multiple definitions depending on what path you take in the preprocessor forest. -- - Alex
May 01 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 18:22, so wrote:
 On Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen wrote:

 note that FFI is not anything spectacular or innovative;

Have you ever written bindings for any of these scripting languages?

No, but you're missing my point entirely. The concept of FFI is not something LuaJIT came up with, at all. http://en.wikipedia.org/wiki/Foreign_function_interface -- - Alex
May 01 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 18:32, Alex Rønne Petersen wrote:
 On 01-05-2012 18:22, so wrote:
 On Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen wrote:

 note that FFI is not anything spectacular or innovative;

Have you ever written bindings for any of these scripting languages?

No, but you're missing my point entirely. The concept of FFI is not something LuaJIT came up with, at all. http://en.wikipedia.org/wiki/Foreign_function_interface

IIRC, SDC has a feature to import C headers by using libclang, BTW. -- - Alex
May 01 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 18:15, so wrote:
 On Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen wrote:

 What are you talking about? The link you posted clearly shows that
 LuaJIT has a C parser built in. It has everything to do with syntax
 (note that FFI is not anything spectacular or innovative; see libffi,
 Mono, Lisp, ...). And no, D does not "have all the structures". If it
 did, we wouldn't be redefining them in D bindings.

What am "i" talking about? How hard to understand these two things?

Very hard! You're not making it clear what it is you want! Do you want something like LuaJIT's FFI so you can just drop a C header in and get a binding or what? You really need to make this clear. I'm not even sure what we're discussing at this point.
 ABI compatibility and "already" being able to call C natively? If you
 need any syntax you "already" have it.

 What does enum have to do with the C preprocessor? Anyway, it's not
 that simple. Any arbitrary symbol can have multiple definitions
 depending on what path you take in the preprocessor forest.

Have you ever used a C api, say OpenGL?

Yes... I wrote the libffi-d binding. You might want to have a look at your local ffi.h and ffitarget.h to see why the preprocessor is a serious problem in automated binding generation. As another example, look at gc.h from libgc.
 What are they using preprocessor for? other than enum and alias?

C libraries use the preprocessor everywhere to deal with funny differences between operating systems, libc implementations, architectures, ...
 It is that damn simple.

No, not really. See above. It may be that simple for the OpenGL headers, but frankly, OpenGL is an example of a reasonably designed library, something that can't be said for 98% of all C libraries.
 I am not talking about supporting Boost level
 preprocessor exploit. I am talking about mature "C" libraries.

"Mature" C libraries are exactly the ones that exploit the preprocessor the most to deal with the aforementioned funny differences! Again, I direct you to ffi.h, ffitarget.h, and gc.h for "simple" examples. -- - Alex
May 01 2012
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 01-05-2012 18:56, so wrote:
 On Tuesday, 1 May 2012 at 16:46:32 UTC, Alex Rønne Petersen wrote:
 On 01-05-2012 18:15, so wrote:
 On Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen wrote:

 What are you talking about? The link you posted clearly shows that
 LuaJIT has a C parser built in. It has everything to do with syntax
 (note that FFI is not anything spectacular or innovative; see libffi,
 Mono, Lisp, ...). And no, D does not "have all the structures". If it
 did, we wouldn't be redefining them in D bindings.

What am "i" talking about? How hard to understand these two things?

Very hard! You're not making it clear what it is you want! Do you want something like LuaJIT's FFI so you can just drop a C header in and get a binding or what? You really need to make this clear. I'm not even sure what we're discussing at this point.

Oh! Be prepared... import capi; // and you are done.

OK, I understand.
 Yes... I wrote the libffi-d binding. You might want to have a look at
 your local ffi.h and ffitarget.h to see why the preprocessor is a
 serious problem in automated binding generation. As another example,
 look at gc.h from libgc.

 No, not really. See above. It may be that simple for the OpenGL
 headers, but frankly, OpenGL is an example of a reasonably designed
 library, something that can't be said for 98% of all C libraries.

As you said lets be realistic if we can support things like OpenGL/CL with tons of typedefs, enums, defines, function declerations (which you said seem to agree that easy). We could have 98% of mature C libraries. I don't agree with you on that 98% of mature libraries designed worse than those. Because since they target different languages they tend to have clean interfaces.

zlib.h, iconv.h, curses.h, arpa/inet.h, ev.h, expat.h, setjmp.h, ucontext.h, unwind.h ... Just to name a few headers with subtle but problematic preprocessor usage. How do you propose that we magically figure out what preprocessor definitions were given to the C compiler when the libraries were compiled? Not to mention what preprocessor definitions the compiler itself defines? And what about compiler extensions? -- - Alex
May 01 2012
prev sibling parent David Gileadi <gileadis NSPMgmail.com> writes:
On 5/2/12 1:04 PM, so wrote:
 Sorry everyone!
 I can't restrain the urge to answer such posts.
 I feel the presence of some higher powers, yes! they are trying to tell
 me... something, perhaps warning me in a way? I keep hearing voices
 along the lines "NNTP error: 400 loadav [innwatch:load] 2084 gt 1500".
 yet i... must... click "Send"!

LOL that one made my day! Glad you're still around :)
May 02 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Tuesday, 1 May 2012 at 15:31:05 UTC, Robert Clipsham wrote:
 On 01/05/2012 16:24, so wrote:
 http://luajit.org/ext_ffi.html
 https://github.com/malkia/ufo

 How awesome is Mike Pall?
 I didn't dive into details of the code, but if he can do this 
 with a
 dynamic language, why on earth D still need manual C bindings 
 while
 having ABI compatibility? So luajit comes with a C compiler?

Note that you can't just drop any C header file in there for that to work (as far as I can tell), you still have to bring out individual post-processed function declarations.

https://github.com/malkia/ufo/blob/master/ffi/OpenCL.lua https://github.com/malkia/ufo/blob/master/ffi/OpenGL.lua If it can handle these 2 beasts.
 Also, someone has written a libffi binding for D, which could 
 probably be adapted to work in a similar manor:

 https://github.com/lycus/libffi-d

Neat. Still, having native C libraries means that you can just drop your C/C++ environment and start D. And i am sure you agree this is by far the biggest blocker for C/C++ developers.
May 01 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Tuesday, 1 May 2012 at 15:32:40 UTC, Alex Rønne Petersen 
wrote:
 On 01-05-2012 17:24, so wrote:
 http://luajit.org/ext_ffi.html
 https://github.com/malkia/ufo

 How awesome is Mike Pall?
 I didn't dive into details of the code, but if he can do this 
 with a
 dynamic language, why on earth D still need manual C bindings 
 while
 having ABI compatibility? So luajit comes with a C compiler?

Parsing a C header is relatively easy; don't need a full compiler for that. It's what htod does. I don't know what you mean by "manual bindings", but keep in mind that: 1) We *don't* want to embed some kind of crazy C syntax in D. 2) In D, we want statically bound C function calls. Lua is a dynamic language.

It has nothing to do with syntax, D already can call C functions directly, and have all the structures.
 3) LuaJIT will have the same problems as htod: Preprocessor 
 definitions.

We can just support enum and simple alias capabilities of C PP and most if not all the popular C libraries would be in D arsenal. I haven't seen many serious C APIs that exploit PP more than these simple tasks.
May 01 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Tuesday, 1 May 2012 at 15:53:37 UTC, Alex Rønne Petersen 
wrote:
 On 01-05-2012 17:43, so wrote:
 On Tuesday, 1 May 2012 at 15:31:05 UTC, Robert Clipsham wrote:
 On 01/05/2012 16:24, so wrote:
 http://luajit.org/ext_ffi.html
 https://github.com/malkia/ufo

 How awesome is Mike Pall?
 I didn't dive into details of the code, but if he can do 
 this with a
 dynamic language, why on earth D still need manual C 
 bindings while
 having ABI compatibility? So luajit comes with a C compiler?

Note that you can't just drop any C header file in there for that to work (as far as I can tell), you still have to bring out individual post-processed function declarations.

https://github.com/malkia/ufo/blob/master/ffi/OpenCL.lua https://github.com/malkia/ufo/blob/master/ffi/OpenGL.lua If it can handle these 2 beasts.

I see no preprocessor directives.

They are all there as "enum".
 Also, someone has written a libffi binding for D, which could 
 probably
 be adapted to work in a similar manor:

 https://github.com/lycus/libffi-d

Neat. Still, having native C libraries means that you can just drop your C/C++ environment and start D. And i am sure you agree this is by far the biggest blocker for C/C++ developers.

I'm not sure what you're trying to say here. Elaborate/rephrase?

For example in my projects i implement different tasks in different libraries. All of them have C interfaces. With something like this i could just access these libraries as i am accessing in C/C++. Then why do i need to go on using C/C++? Transition would be seamless. You can say just write the damn bindings and be done with it. But it is neither scalable nor maintainable.
May 01 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen 
wrote:

 What are you talking about? The link you posted clearly shows 
 that LuaJIT has a C parser built in. It has everything to do 
 with syntax (note that FFI is not anything spectacular or 
 innovative; see libffi, Mono, Lisp, ...). And no, D does not 
 "have all the structures". If it did, we wouldn't be redefining 
 them in D bindings.

What am "i" talking about? How hard to understand these two things? ABI compatibility and "already" being able to call C natively? If you need any syntax you "already" have it.
 What does enum have to do with the C preprocessor? Anyway, it's 
 not that simple. Any arbitrary symbol can have multiple 
 definitions depending on what path you take in the preprocessor 
 forest.

Have you ever used a C api, say OpenGL? What are they using preprocessor for? other than enum and alias? It is that damn simple. I am not talking about supporting Boost level preprocessor exploit. I am talking about mature "C" libraries.
May 01 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen 
wrote:

 note that FFI is not anything spectacular or innovative;

Have you ever written bindings for any of these scripting languages?
May 01 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Tuesday, 1 May 2012 at 16:31:09 UTC, Alex Rønne Petersen 
wrote:

 That has nothing to do with the C preprocessor... The point 
 here is that you can't just copy/paste a C header into LuaJIT's 
 FFI out of the box.

Well i didn't say you can. But D have great advantages over Lua to be able to do that and much more.
 Let's be realistic.

 In practice, you can almost never just copy/paste a C header 
 into LuaJIT's FFI. Even a header guard (#ifndef FOO \ #define 
 FOO \ ... \ #endif) will ruin it. The fundamental problem is 
 the C preprocessor. The best you can do is take your C header, 
 preprocess it with cpp, and then pass it to LuaJIT and hope 
 nothing breaks. Usually, not even an approach like that will 
 work because of weird compiler extensions used in headers which 
 aren't stripped by cpp.

Again, you can't do that in lua but you should be able to do it in D. If you check some lua bindings, libraries tries to simplify the process, all the duplicate stuff they do on tons of different projects. All for nothing, and i am sure this is true for many other languages. And then you see luajit-ffi, gives both performance boost and soooo much clean code. This discussion came up before and preprocessor was the only serious blocker. But if you support it to the level what mature C libraries use, which means simple alias and enum you have them all.
 In an ideal world where no compiler extensions existed, this 
 might have had a chance of working, but we all know what the 
 situation with C and C++ is.

I am not sure if C++ had quarter of its user base if it didn't work with C seamlessly.
 Yes, creating manual bindings is tedious and annoying to 
 maintain, but it is the most foolproof approach.

In another language there may not be other exit but D, i am not sure.
May 01 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Tuesday, 1 May 2012 at 16:46:32 UTC, Alex Rønne Petersen 
wrote:
 On 01-05-2012 18:15, so wrote:
 On Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen 
 wrote:

 What are you talking about? The link you posted clearly shows 
 that
 LuaJIT has a C parser built in. It has everything to do with 
 syntax
 (note that FFI is not anything spectacular or innovative; see 
 libffi,
 Mono, Lisp, ...). And no, D does not "have all the 
 structures". If it
 did, we wouldn't be redefining them in D bindings.

What am "i" talking about? How hard to understand these two things?

Very hard! You're not making it clear what it is you want! Do you want something like LuaJIT's FFI so you can just drop a C header in and get a binding or what? You really need to make this clear. I'm not even sure what we're discussing at this point.

Oh! Be prepared... import capi; // and you are done.
 Yes... I wrote the libffi-d binding. You might want to have a 
 look at your local ffi.h and ffitarget.h to see why the 
 preprocessor is a serious problem in automated binding 
 generation. As another example, look at gc.h from libgc.

 No, not really. See above. It may be that simple for the OpenGL 
 headers, but frankly, OpenGL is an example of a reasonably 
 designed library, something that can't be said for 98% of all C 
 libraries.

As you said lets be realistic if we can support things like OpenGL/CL with tons of typedefs, enums, defines, function declerations (which you said seem to agree that easy). We could have 98% of mature C libraries. I don't agree with you on that 98% of mature libraries designed worse than those. Because since they target different languages they tend to have clean interfaces.
May 01 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Tuesday, 1 May 2012 at 16:56:48 UTC, Alex Rønne Petersen
wrote:

 Yes, creating manual bindings is tedious and annoying to 
 maintain, but
 it is the most foolproof approach.

In another language there may not be other exit but D, i am not sure.


As it happens, you are safe with D even if you pick that path. With my limited knowledge, these a few lines of code destroys all lua binders out there. Make sure they are inlined and it would be identical to handcrafted bindings. WARNING: DO NOT TRY THIS WITH C++! (See the "alias F"? ParamTuple? Yep) import std.stdio; import std.traits; struct handle { int i=0; int get_arg() { return i++; } } alias handle* hnd; void assign(uint N, P...)(ref P p, hnd h) { static if(N) { p[N-1] = h.get_arg(); assign!(N-1)(p, h); } } int fn(alias F)(hnd h) { alias ParameterTypeTuple!(typeof(&F)) P; P p; assign!(P.length)(p, h); F(p); return 0; } // test >>>> void fun0(int a) { writeln("fun0 a: ", a); } void fun1(int a, int b) { writeln("fun1 a: ", a); writeln("fun1 b: ", b); } void main() { // reg(&fn!fun0, "fun0"); // reg(&fn!fun1, "fun1"); auto f0 = &fn!fun0; auto f1 = &fn!fun1; handle h; f0(&h); f1(&h); } // test <<<<
May 01 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 1 May 2012 at 16:15:58 UTC, so wrote:
 Have you ever used a C api, say OpenGL?
 What are they using preprocessor for? other than enum and alias?
 It is that damn simple. I am not talking about supporting Boost 
 level preprocessor exploit. I am talking about mature "C" 
 libraries.

Oh _come on_, that's just plain wrong. For example, have you ever heard of that library called OpenSSL? David
May 02 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Wednesday, 2 May 2012 at 11:56:51 UTC, David Nadlinger wrote:
 On Tuesday, 1 May 2012 at 16:15:58 UTC, so wrote:
 Have you ever used a C api, say OpenGL?
 What are they using preprocessor for? other than enum and 
 alias?
 It is that damn simple. I am not talking about supporting 
 Boost level preprocessor exploit. I am talking about mature 
 "C" libraries.

Oh _come on_, that's just plain wrong. For example, have you ever heard of that library called OpenSSL? David

Why don't you give a link to the source where they use preprocessor heavily? And "even" if they do, did i say "all" libraries? Yes you managed to come up with a library which includes tons of header files in the sea of mature C libraries.
May 02 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 2 May 2012 at 12:36:03 UTC, so wrote:
 Why don't you give a link to the source where they use 
 preprocessor heavily?

Like many other C libraries, OpenSSL implements quite a few functions in terms of macros for performance reasons, so that they can be inlined (like [1]). Additionally, the OpenSSL guys also rely on macros to generate things like their ASN1 interface ([2], [3]), collections (»safe stacks«), …
 And "even" if they do, did i say "all" libraries? Yes you 
 managed to come up with a library which includes tons of header 
 files in the sea of mature C libraries.

Well, after more or less telling Alex that he has no clue what he's talking about, you implied that most of the »mature« libraries would make only moderate use of the preprocessor for constants. In this generality (»Have you ever used a C api, say OpenGL? What are they using preprocessor for? other than enum and alias?«), this is simply not true. As Alex pointed out, it's often even the other way round: The older and more mature a library is, the more preprocessor macros it uses to deal with various subtle incompatibilities between all the different systems out there… David (These links are to [1] https://github.com/D-Programming-Deimos/openssl/blob/master/C/bn.h#L369 [2] https://github.com/D-Programming-Deimos/openssl/blob/master/C/asn1.h#L301 [3] https://github.com/D-Programming-Deimos/openssl/blob/master/C/asn1t.h#L85
May 02 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Wednesday, 2 May 2012 at 16:23:28 UTC, David Nadlinger wrote:

 Well, after more or less telling Alex that he has no clue what 
 he's talking about,

With no reason, right? Could you go back and read why i did what you said i did? I might sometimes sound rude. You can blame my temper, nature or lack of (quite obvious) English language skills, but these never happen without a reason. So enum, alias has nothing to do with #define? Or D requires syntax to support the things i mentioned? Don't i have a right to expect, someone who answers me already understand what i am saying or ask nicely to clear it up? This is not directing Alex but you since i think we settled the issue, yet you jump as a self appointed lawyer. Nothing i hate as much as this, pack behavior in humans. It is time for me to leave this community too, i can stand many things but this. My start on this forum wasn't very bright either. Called troll for a very legitimate question, because a few regulars couldn't comprehend the topic i am talking about and/or my cryptic English. Whatever.
 you implied that most of the »mature« libraries would make 
 only moderate use of the preprocessor for constants. In this 
 generality (»Have you ever used a C api, say OpenGL? What are 
 they using preprocessor for? other than enum and alias?«), 
 this is simply not true. As Alex pointed out, it's often even 
 the other way round: The older and more mature a library is, 
 the more preprocessor macros it uses to deal with various 
 subtle incompatibilities between all the different systems out 
 there…

May 02 2012
prev sibling next sibling parent "agitator" <nope example.com> writes:
good bye
you won't be missed
May 02 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Wednesday, 2 May 2012 at 18:27:18 UTC, agitator wrote:
 good bye
 you won't be missed

I am just trying to find a better tool to ease the work i do, not trying to be one as yourself. So as long as D rocks, i ll be following. Just not post on forums as it won't do much good when you have hard time expressing yourself anyway. I pity you, as i believe nothing would be that low on spirit if it wasn't disturbed somehow. Sorry everyone! I can't restrain the urge to answer such posts. I feel the presence of some higher powers, yes! they are trying to tell me... something, perhaps warning me in a way? I keep hearing voices along the lines "NNTP error: 400 loadav [innwatch:load] 2084 gt 1500". yet i... must... click "Send"!
May 02 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 2 May 2012 at 17:52:07 UTC, so wrote:
 So enum, alias has nothing to do with #define?
 Or D requires syntax to support the things i mentioned?

#define can be used for manifest constants and aliases, yes, but also for many other things, as in the examples from popular libraries that I and others posted. And for an automatic C importing mechanism to be worth its complexity, it must be able to handle at least the more common variations.
 Don't i have a right to expect, someone who answers me already 
 understand what i am saying or ask nicely to clear it up?

Frankly, no – just as you answered other posts in this thread probably without being absolutely sure what the author was trying to say. Maybe my reply sounded harsher than I intended, I tend to get annoyed too easily when somebody seems to just ignore multiple technically sound replies (which people have spent time writing, after all). I apologize for that. David
May 02 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 2 May 2012 at 20:04:30 UTC, so wrote:
 I keep hearing voices along the lines "NNTP error: 400 loadav 
 [innwatch:load] 2084 gt 1500". yet i... must... click "Send"!

I might suffer from the same type of schizophrenia ;) David
May 02 2012
prev sibling parent "James Miller" <james aatch.net> writes:
Just pitching in as somebody that has worked on a few C bindings, 
some small some big (current one is XCB, which has the lovely 
xproto.h file coming to over 15000 lines). Doing automatic 
conversion of C headers, properly, is difficult, if not 
impossible. There are all sorts of gotchas and strange things 
that make trying to write bindings difficult to automate.

A lot of APIs rely on the CPP, as part of the API itself. This is 
an issue because you generally need to replicate those parts of 
the API in some D way, without completely mangling the original 
API, generally you want to be able to copy-and-paste C code and 
have it work as D code.

Not all defines can, or should, be converted to enums, even if 
you distinguish macros and constants. Not all typedefs can be 
converted to aliases. Different libraries use different ways of 
typedef'ing their structs and the like. Each library needs a 
specific touch to make the D bindings as true to the original as 
possible, and a tool cannot do that well.

Manually writing bindings is boring, but also quite medatitive. 
It is simple enough that you can just shut off, or you can make 
it a challenge to find the best macro for converting a certain 
construct in this library. But it is generally not that difficult.

The difference between using bindings and FFI is that bindings 
are compile time and you get all the advantages from that, such 
as type checking and the like. FFI is all runtime, so you don't 
get that, unless you do some crazy CTFE magic.

--
James Miller
May 02 2012