I'm not planning to maintain LuaJIT or contribute to it, except for
I'm a pretty heavy user of LuaJIT and have built it into Csound, a
moderately widely used user-programmable software synthesizer used by
computer music people, especially the academic kind. My motivation for
using it was the pure ease of building it into Csound itself, such
that Csound could be programmed in a very good high-level language
(the Csound language itself is not so great), especially for
algorithmic composition, PLUS the speed, enabling LuaJIT in Csound to
do not only compositional procedures, but actual audio digital signal
processing at a speed quite competitive with C/C++ (measured and
proved). For 4-5 years I composed a number of pieces using LuaJIT in
Csound that have been performed in festivals, ended up online, etc.
Speed ALWAYS matters, don't listen to what anyone says.
audio DSP, but certainly for algorithmic composition. Why? Mainly
and is so tightly integrated with the user interface and all the
capabilities of HTML5. It's like getting a ton of the most useful
libraries for nothing.
and to the DOM, I would not be doing this. So that's item number one
on my wish list for LuaJIT: Embed in browsers somehow (easier probably
with NW.js or Chrome's PNaCl or something like that) so that it can
I'm sure that's possible because I can imagine doing LuaJIT as a node
for node.js or NW.js, but I don't know how hard it would be or if it
would be worth the trouble.
My other wishes/suggestions, in decreasing order of importance to me:
(1) Stability of the language/API.
(2) A package manager in the cloud like npm.
(3) Base array indexes at 0 (startup option, default is 0, legacy is 1).
(4) Some kind of C++ FFI (hard I know).
(5) More compatibility with ongoing developments in PUC Lua.
Thanks for everything,
Michael dot Gogins at gmail dot com
On Wed, Sep 2, 2015 at 11:38 AM, William Adams
Date: Wed, 2 Sep 2015 18:30:32 +0300
Subject: Re: Turning Lua into C++ (was: alleviate the load of the GC)
It looks like there's already a contest going on about the best way
to hijack and destroy LuaJIT with the most atrocious and hazardous
I guess it depends on how this community reacts to the suggestion of these
changes. I don't see anything wrong with people expressing their desire to
make wacky changes. In fact, I think it's actually required because it
helps shape the "consensus opinion".
I know there's been an allergic reaction to many of the changes suggested by
the tarantool camp in the past for example. It's when the rest of the
community doesn't know the technical implications of a seemingly "decent
proposal" that things will go really sideways.
That must be disheartening to see.
I'm outta here in a couple of days.
It doesn't appear there will be a 'new maintainer' in a couple of days, so
our real problem will be stagnation, rather than rampant disembowelment.
I see rays of hope. "luajit should always be about performance". I agree
to that, and it should be a cornerstone in the 'luajit manifesto'. I also
believe another key differentiator is the ffi, and that should always grow
and improve. And another tenet is "the runtime size should remain small and