Re: Beta 10 Last call
- From: Mike Pall <mike-1205@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sun, 6 May 2012 18:48:46 +0200
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:
