RE: Beta 10 Last call
- From: William Adams <william_a_adams@xxxxxxx>
- To: <luajit@xxxxxxxxxxxxx>
- Date: Mon, 7 May 2012 01:59:01 +0000
That "C" behavior, yah, kind of silly esoteric stuff. I just change my
declarations and all is fine. As for my various ffi bindings and work, thanks
for the suggestion. I'll make a summary of the work, and post the link here. I
came to Lua for the various reasons you state. Small embeddable, compact
language etc. But, given the old style of interop with Lua 5.1, I would not
have been able to stay with it as you spend more time writing interop code than
actually writing the core code you're supposed to be writing. Similarly, you
end up eliminating all the advantages of the small size, because the interop
code becomes so big and unwieldy. LuaJITs FFI eliminates all that complexity.
For example, hooking up with Kinect took me a weekend's worth of work, and that
was mainly in fiddling about with how to properly get a COM style interface
working. Now that basic work is done, I can simply write Kinect code, and
never worry about maintaining my interop code. Great benefit of the FFI. I'll
look forward to user accessible assembly code. I think that will have a similar
beneficial affect that the FFI itself has. And thanks for creating this
particular list. I know the Lua mailing list exists, but at this point, I
think LuaJIT can just stand on its own and let the community evolve as it will.
-- William
===============================
- Shaping clay is easier than digging it out of the ground.
http://blog.nanotechstyles.com
http://www.thingiverse.com/WilliamAAdams
https://github.com/Wiladams
> Date: Sun, 6 May 2012 18:48:46 +0200
> From: mike-1205@xxxxxxxxxx
> To: luajit@xxxxxxxxxxxxx
> Subject: Re: Beta 10 Last call
>
> William Adams wrote:
> > Only one thing in FFI that I'm looking for. "const char **",
> > won't necessarily accept something that is "char **", but that's
> > a minor nit easily fixed in my declarations.
>
> I'm just following C behavior. Try that in C:
>
> $ cat >test.c
> void foo(const char **p);
> void bar(char **p) { foo(p); }
> ^D
> $ gcc -Wall -O2 -c test.c
> test.c: In function 'bar':
> test.c:2: warning: passing argument 1 of 'foo' from incompatible pointer type
> test.c:1: note: expected 'const char **' but argument is of type 'char **'
>
> It's all explained in the C89/C99 docs somewhere. C has, umm,
> interesting semantics. :-)
>
> [
> I've been writing C code for 25 years. But only after I wrote half
> of a C compiler, did I begin to understand some of its darker corners.
>
> Ok, so ... how many people do you think fully understand C++? ;-)
> ]
>
> > The only request I'd have for future versions is an across the
> > board implementation of interlockexchange.
>
> Once the support for user-definable machine code templates is in
> (after 2.1), this should be doable. In the meantime, you can use
> the OS-provided locking APIs. Without some kind of OS support or
> coordination across threads, you'd be busy-waiting on every
> long-term lock, anyway -- not so nice.
>
> > LuaJIT has literally changed my opinion and usage of Lua.
> > Without LuaJIT in particular, Lua would be no better than
> > JavaScript for me.
>
> Thank you, certainly an interesting perspective!
>
> Previously most people came to Lua not just because it's a nice
> and clean language. I guess the main reason was the great
> embeddability compared to other scripting languages: small memory
> footprint, few library dependencies, clean API and so on. And some
> of them went on to LuaJIT, because they needed more performance.
>
> But Lua still doesn't have the appeal of a mainstream programming
> language. I guess the major hurdle was the lack of batteries,
> which is of course a consequence of the minimalistic design. And
> that's the main reason for the great embeddability. Kind of a
> chicken-and-egg syndrome. The neglect for a coordinated, polished
> and blessed ecosystem of libraries around it, pays its toll, too.
>
> In a certain sense that hurdle can be overcome with the LuaJIT FFI.
> You can still have a small memory footprint and few integration
> hassles. But now you get to easily tap into the whole ecosystem of
> C libraries with very little effort and high performance, too. And
> all of that without writing bindings in C, which eliminates a lot
> of build-time complexity. Just a bunch of Lua files with C header
> declarations -- that's it. The YAGNI and KISS principles at work.
>
> [I have some ideas for coordinating that sub-ecosystem, to avoid
> everyone writing standard FFI bindings from scratch. I mean, how
> many semi-complete, semi-portable OpenGL FFI bindings do we have
> by now? I'll have to think about what I can offer and what I cannot.
> But that's for another thread. Alas, time is my main limit.]
>
>
> BTW: William, I've been following your blog entries about your
> adventures with the LuaJIT FFI, getting it to talk to GL, the
> Kinect, the nice writeups with videos, and so on.
>
> Maybe you want to announce this here on the list? I bet others
> would be interested to read this in chronological order. I
> couldn't find a way to lists only the relevant entries in the
> right order, or I'd have posted a URL. Maybe create an extra
> collection blog entry, which has all the internal links?
>
> --Mike
>
Other related posts:
