Thread overview | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
May 01, 2012 luajit-ffi | ||||
---|---|---|---|---|
| ||||
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 Re: luajit-ffi | ||||
---|---|---|---|---|
| ||||
Posted in reply to so | 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 Re: luajit-ffi | ||||
---|---|---|---|---|
| ||||
Posted in reply to so | 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 Re: luajit-ffi | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert Clipsham | 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 Re: luajit-ffi | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert Clipsham | 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 Re: luajit-ffi | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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 Re: luajit-ffi | ||||
---|---|---|---|---|
| ||||
Posted in reply to so | 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 Re: luajit-ffi | ||||
---|---|---|---|---|
| ||||
Posted in reply to so | 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 Re: luajit-ffi | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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 Re: luajit-ffi | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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. |
Copyright © 1999-2021 by the D Language Foundation