Re: Mike Pall's standalone FFI: a dream?

[CrazyButcher <crazybutcher@...>]

There is a nice preprocessor (although not fully c compliant) inside
http://icculus.org/mojoshader/ so one could run strings trhough that
prior handing to ffi.cdef

as was stated before, I think if someone really wants to, you could
write a wrapper around cinvoke that mimics the ffi api or is there
something fundamentally missing (except the performance issue, which
you said wasn't as critical)?
"create what you will" ;)

I've done ffi like header parsing myself lately for syntax api file
generation and shader parsing, gmatch and gsub for the win :) can get
you quite far if the code is relatively clean. it's not super robust,
but a start
http://estrelaeditor.git.sourceforge.net/git/gitweb.cgi?p=estrelaeditor/estrelaeditor;a=blob;f=tools/ffitoapi.lua;h=4b335a2ea180fd4d64101d9b79400867212ba8bf;hb=HEAD

because it sounds like what you are most interested in is the c-header
parser, which mojoshader for example could generate for you with
comments removed, and then it becomes a pure lua job of parsing that
string, resolving typedefs... and feed that to whatever native-call
backend you prefer

2011/5/12 Lorenzo Donati <lorenzodonatibz@interfree.it>:
> On 12/05/2011 6.10, Miles Bader wrote:
>>
>> dcharno<dcharno@comcast.net>  writes:
>>>
>>> Yes, I have this dream often.  I doubt my applications would benefit
>>> from LuaJIT's performance, but the simplicity of the FFI makes it very
>>> attractive.
>>
>> ... and it would mean that one could rely on FFI as a "general solution"
>> for portable code.  LuaJIT is very nice, but it only works on a subset
>> of architectures, and knowing one can always fall back to standard Lua
>> is very comforting.
>
> Yes!
> Simplicity, readability (as far as C is readable - but it is a stable
> standard nevertheless) and portability!
> Not to mention that if Mike implements the C preprocessor in the FFI parser,
> you could have "conditional compilation".
>
> So you could make Lua scripts that can be designed to adapt themselves to
> different platforms and still being able to access system API facilities. So
> you could have the best of two worlds. Maybe not the most readable code, but
> as the old say goes:
>
> "make simple things simple and difficult ones possible"
>
>
> Really a dream! :-)
>
>
>>
>> -Miles
>>
>
> P.S.: really nice signature! :-D
>
>