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?

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/

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

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

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.

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.

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

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

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.

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.