digitalmars.D - luajit-ffi
- so (7/7) May 01 2012 http://luajit.org/ext_ffi.html
- Robert Clipsham (10/16) May 01 2012 Note that you can't just drop any C header file in there for that to
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (6/20) May 01 2012 Note in particular that the message box example used a preprocessed
- so (7/23) May 01 2012 https://github.com/malkia/ufo/blob/master/ffi/OpenCL.lua
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (5/28) May 01 2012 I'm not sure what you're trying to say here. Elaborate/rephrase?
- so (10/45) May 01 2012 They are all there as "enum".
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (19/58) May 01 2012 That has nothing to do with the C preprocessor... The point here is that...
- so (18/35) May 01 2012 Well i didn't say you can. But D have great advantages over Lua
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (13/44) May 01 2012 D still can't solve the preprocessor problem, so I don't see how it
- so (54/60) May 01 2012 As it happens, you are safe with D even if you pick that path.
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (10/16) May 01 2012 Parsing a C header is relatively easy; don't need a full compiler for
- so (9/27) May 01 2012 It has nothing to do with syntax, D already can call C functions
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (11/34) May 01 2012 What are you talking about? The link you posted clearly shows that
- so (11/21) May 01 2012 What am "i" talking about? How hard to understand these two
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (20/37) May 01 2012 Very hard! You're not making it clear what it is you want!
- so (11/40) May 01 2012 Oh! Be prepared...
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (11/44) May 01 2012 zlib.h, iconv.h, curses.h, arpa/inet.h, ev.h, expat.h, setjmp.h,
- David Nadlinger (4/9) May 02 2012 Oh _come on_, that's just plain wrong. For example, have you ever
- so (5/15) May 02 2012 Why don't you give a link to the source where they use
- David Nadlinger (24/29) May 02 2012 Like many other C libraries, OpenSSL implements quite a few
- so (17/28) May 02 2012 With no reason, right? Could you go back and read why i did what
- agitator (2/2) May 02 2012 good bye
- so (13/15) May 02 2012 I am just trying to find a better tool to ease the work i do, not
- David Gileadi (2/8) May 02 2012 LOL that one made my day! Glad you're still around :)
- David Nadlinger (3/5) May 02 2012 I might suffer from the same type of schizophrenia ;)
- David Nadlinger (13/17) May 02 2012 #define can be used for manifest constants and aliases, yes, but
- James Miller (27/27) May 02 2012 Just pitching in as somebody that has worked on a few C bindings,
- so (4/5) May 01 2012 Have you ever written bindings for any of these scripting
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (6/9) May 01 2012 No, but you're missing my point entirely. The concept of FFI is not
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (4/16) May 01 2012 IIRC, SDC has a feature to import C headers by using libclang, BTW.
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
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
On 01-05-2012 17:31, Robert Clipsham wrote:On 01/05/2012 16:24, so wrote:Note in particular that the message box example used a preprocessed version of the MessageBoxA declaration.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-dIf you have a C parser (libclang?), it's probably entirely doable. -- - Alex
May 01 2012
On Tuesday, 1 May 2012 at 15:31:05 UTC, Robert Clipsham wrote:On 01/05/2012 16:24, so wrote: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.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-dNeat. 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
On 01-05-2012 17:43, so wrote:On Tuesday, 1 May 2012 at 15:31:05 UTC, Robert Clipsham wrote:I see no preprocessor directives.On 01/05/2012 16:24, so wrote: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.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.I'm not sure what you're trying to say here. Elaborate/rephrase? -- - AlexAlso, someone has written a libffi binding for D, which could probably be adapted to work in a similar manor: https://github.com/lycus/libffi-dNeat. 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
On Tuesday, 1 May 2012 at 15:53:37 UTC, Alex Rønne Petersen wrote:On 01-05-2012 17:43, so wrote:They are all there as "enum".On Tuesday, 1 May 2012 at 15:31:05 UTC, Robert Clipsham wrote:I see no preprocessor directives.On 01/05/2012 16:24, so wrote: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.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.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.I'm not sure what you're trying to say here. Elaborate/rephrase?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-dNeat. 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
On 01-05-2012 18:08, so wrote:On Tuesday, 1 May 2012 at 15:53:37 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. You have to run the preprocessor on it first, or preprocess it by hand.On 01-05-2012 17:43, so wrote:They are all there as "enum".On Tuesday, 1 May 2012 at 15:31:05 UTC, Robert Clipsham wrote:I see no preprocessor directives.On 01/05/2012 16:24, so wrote: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.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.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. -- - AlexFor 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.I'm not sure what you're trying to say here. Elaborate/rephrase?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-dNeat. 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
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
On 01-05-2012 18:47, so wrote:On Tuesday, 1 May 2012 at 16:31:09 UTC, Alex Rønne Petersen wrote: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.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.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.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.See my reply to your other post for why this is not sufficient for the majority of C libraries.If C++ didn't have C "support", it would probably never have been adopted at all. But I never claimed otherwise.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.-- - AlexYes, 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
On Tuesday, 1 May 2012 at 16:56:48 UTC, Alex Rønne Petersen wrote: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 <<<<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
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
On Tuesday, 1 May 2012 at 15:32:40 UTC, Alex Rønne Petersen wrote:On 01-05-2012 17:24, so wrote:It has nothing to do with syntax, D already can call C functions directly, and have all the structures.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.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
On 01-05-2012 17:50, so wrote:On Tuesday, 1 May 2012 at 15:32:40 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.On 01-05-2012 17:24, so wrote:It has nothing to do with syntax, D already can call C functions directly, and have all the structures.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.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. -- - Alex3) 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
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
On 01-05-2012 18:15, so wrote:On Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen wrote: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.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.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 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?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
On Tuesday, 1 May 2012 at 16:46:32 UTC, Alex Rønne Petersen wrote:On 01-05-2012 18:15, so wrote:Oh! Be prepared... import capi; // and you are done.On Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen wrote: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.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?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
On 01-05-2012 18:56, so wrote:On Tuesday, 1 May 2012 at 16:46:32 UTC, Alex Rønne Petersen wrote:OK, I understand.On 01-05-2012 18:15, so wrote:Oh! Be prepared... import capi; // and you are done.On Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen wrote: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.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?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? -- - AlexYes... 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
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
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: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.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
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
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
On Wednesday, 2 May 2012 at 18:27:18 UTC, agitator wrote:good bye you won't be missedI 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
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
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
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
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
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
On 01-05-2012 18:22, so wrote:On Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen wrote: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 -- - Alexnote that FFI is not anything spectacular or innovative;Have you ever written bindings for any of these scripting languages?
May 01 2012
On 01-05-2012 18:32, Alex Rønne Petersen wrote:On 01-05-2012 18:22, so wrote:IIRC, SDC has a feature to import C headers by using libclang, BTW. -- - AlexOn Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen wrote: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_interfacenote that FFI is not anything spectacular or innovative;Have you ever written bindings for any of these scripting languages?
May 01 2012