I'm not planning to maintain LuaJIT or contribute to it, except for
these observations.
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.
Over time I've been moving a lot of my work to JavaScript, not for
audio DSP, but certainly for algorithmic composition. Why? Mainly
because JavaScript runs in both standalone and embedded Web browsers,
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.
If LuaJIT were able to run in Web browsers, with access to JavaScript
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
essentially be used as a substitute for/along with JavaScript.
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,
Mike
-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com
On Wed, Sep 2, 2015 at 11:38 AM, William Adams
<william_a_adams@xxxxxxxxxxx> wrote:
From: cosmin.apreutesei@xxxxxxxxx
Date: Wed, 2 Sep 2015 18:30:32 +0300
Subject: Re: Turning Lua into C++ (was: alleviate the load of the GC)
To: luajit@xxxxxxxxxxxxx
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
changes.
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.
For good?
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
embeddable".
