
CloudFlare starts discussion about LuaJIT project governance - bratao
https://www.freelists.org/post/luajit/LuaJIT-project-governance
======
bratao
My impression is that LuaJIT is too perfect/complex to the GitHub
collaborative model work, where developers uses the software, identify a
bug/missing feature for his use case, dig in code for a day/week, and do a
push. In LuaJIT the stakes are much higher, and a small change can have big
repercussions. Relying on occasional open-source contributors seems like a
direct path to abandonware.

~~~
hobo_mark
Is it possible (as in, easy), to use something like gerrit/rietveld on top of
(or next to) github?

I am imagining a bot what will take GH pull requests, submit the patch to
gerrit for review, and answer to the user something like "thank you for your
contribution, this project uses an external platform for code review, a
discussion was automatically created to review your changes, please follow
this link to participate".

~~~
piotrkaminski
Another option is to use a code review tool similar to Gerrit / Rietveld but
built from the ground up for integration with GitHub. Recent entrants include
[https://review.ninja](https://review.ninja),
[https://gitcolony.com](https://gitcolony.com), and
[https://reviewable.io](https://reviewable.io) (disclosure: this last one's
mine).

------
kzrdude
Maybe the project can take inspiration from projects that use run tests for
each pull request, before merging.

------
sdf45
I don't know much about Lua and LuaJIT, so let me ask a naive question:

If you would start out with a JavaScript JIT (like V8) what things would you
have to add (i.e. things that are not required to JIT JavaScript) besides the
obvious modifications in the parser?

One point I can think of is support for efficient compilation of co-routines.

~~~
yoklov
Lua has goto (and JS does not), which means not all cfg's are well structured.
That could impact the compiler in certain ways.

Lua also has finalizers, which effect the GC's design. The Lua/C api also
makes it impossible for the GC to move objects, which means pretty much every
current JS VM's GC is out.

Lua 5.3 has 64 bit integers, which would effect most JS VM's in a significant
way (but to my knowledge LuaJIT doesn't support 5.3 so...)

There are other issues too, but these are just off the top of my head.

~~~
mraleph
> Lua also has finalizers, which effect the GC's design.

V8 has a weak callback mechanism, which (while not exposed to JS) allows
reentering JS from inside a weak callback - which means you can emulate Lua's
__gc on top of this mechanism.

> The Lua/C api also makes it impossible for the GC to move objects, which
> means pretty much every current JS VM's GC is out.

If we disregard lua_topointer then Lua/C API only leaks internal pointers for
strings (lua_tostring), userdata (lua_newuserdata, lua_touserdata) and threads
(lua_newthread,lua_tothread) - everything else is manipulated using
lua_State's stack.

This means VM only has to take care with regards to these objects. Userdata
and threads can be just allocated outside of movable part of the heap and
strings can be "externalized" (i.e. they payload relocated into the immovable
space) on first access via lua_tostring. Coincidentally last thing is
something that V8 supports[1] (though of course externalization is not a cheap
operation as it requires copying).

> Lua 5.3 has 64 bit integers, which would effect most JS VM's in a
> significant way

Yeah, that's certainly a whole ton of work, but most of this work would be
pretty technical.

JS engines might actually get int64/uint64 value types in the future (at some
point there was an ES7 proposal - but currently it does not seem to be on
track for inclusion).

[1] [https://github.com/v8/v8-git-
mirror/blob/master/include/v8.h...](https://github.com/v8/v8-git-
mirror/blob/master/include/v8.h#L2344-L2353)

~~~
piotrjurkiewicz
LuaJIT does not support 64 bit integers. It uses double NaN tagging for
storing object references. That's the basic principle of LuaJIT design and one
of the most important source of its superior performance. In this matter, it
is very similar to JS VMs.

Support for 64 bit integers would require to abandon this model and completely
redesign the LuaJIT VM. Mike opinion about that was very negative.

I believe that this was one of the reasons he decided to abandon the project:
he was disappointed by Lua creators decision to introduce 64 bit ints and the
fact that LuaJIT can't be made Lua 5.3 compatible without rebuilding it from
scratch (but that's only my personal impression).

------
coldtea
I was exchited by what I was hearing about Lua and LuaJIT, speed and quality
of code wise. And then I tried the language.

While it's poweful in its "meta-programming" facilities and has some nicities,
it has many uneeded bizarro decisions.

This alone was enough to make me leave it:

[http://stackoverflow.com/questions/2705793/how-to-get-
number...](http://stackoverflow.com/questions/2705793/how-to-get-number-of-
entries-in-a-lua-table)

~~~
tylerneylon
If you have an array in Lua, which is a table used as a contiguous list of
items, this is how you get the number of items:

    
    
        num_items = #my_array
    

Your qualm, apparently, is that this # is not built for all use cases of
tables.

In C++, what operator tells you how many instance variables a class has? There
is none, because that wouldn't make sense in many use cases. Lua tables,
offering prototype-based inheritance, experience a similar conceptual
ambiguity in the case where you want to take the length of an object.

Lua has made a design decision that the built-in length operator only works on
arrays = tables-used-as-a-list and on strings -- cases without ambiguity. If
you want the length operator to make sense for a hash map usage, it's a few
extra lines of work for you. It's consistent with the langauge being small and
flexible, a theme which Lua embraces with elegance.

~~~
coldtea
> _Your qualm, apparently, is that this # is not built for all use cases of
> tables._

My qualms are multiple:

(a) this is an operator when it doesn't need to -- a function would do --,

(b) this only works for contiguous list of items.

(c) Lua, like PHP and JS, has the same type for "contiguous list of items" and
hash tables, not even providing a builtin just for the first and/or the latter
(e.g. ES6 now does with "Map").

I can understand the powerful metaprogramming capabilities of tables. I also
understand that they are not needed, and are even a hidrance, in the tons of
cases where all you want is a simple hashmap or a simple vector that wont
change under your feet.

>* In C++, what operator tells you how many instance variables a class has?*

Nobody said C++ was well designed ever, too.

------
jgrahamc
I would have titled that as "CloudFlare starts discussion about LuaJIT project
governance". We don't have a solution or prescription. We're happy to help
Mike in the transition in any way possible and are taking baby steps as we do
so.

~~~
dang
Ok, we changed the title to that.

------
logicrime
The qualms I have with this dialogue are the same as before, because
CloudFlare has little to no idea how they are going to handle this. JGC
tweeted me about how 'Oh, we get so much benefit from LuaJIT being FOSS" but
here we have CloudFlare walling LuaJIT into it's own entity on GitHub where I
predict commit bits will be few and far between.

More than that, I don't think there has been enough narrative between Mike and
the 'new LuaJIT crew' (CF) to determine how the project should be structured.
In this thread, agentzh had a fantastic idea to vet somebody through Mike,
someone the community knows can be trusted and also is somewhat familiar with
the LuaJIT internals, and that person could serve as a canary between the
project and CF.

I write a fair bit of Lua for game scripting, and I've even made a few bucks
here and there helping folks with their custom plugin ideas etc, but I've
never touched C before. Well, when the previous announcement was made, I
immediately Amazon'd some C books, which I plan to devour in my free time. At
which point I'll be learning Rust, and reimplementing LuaJIT in Rust, and
hopefully convince Mozilla to host the git, such that it will be protected
from FOSS corruption.

My worst fear is CF taking this project into the shadows, developing it
closed-source (which they absolutely have a right to do) and not sharing their
insights with the community.

I think everybody with any kind of invested interest in LuaJIT needs to be
gearing up right now, such that we can do our parts to keep this project
alive.

~~~
jgrahamc
_JGC tweeted me about how 'Oh, we get so much benefit from LuaJIT being FOSS"_

And we do. We paid Mike Pall to work on open source LuaJIT, we've contributed
to NGINX, hired people to exclusively work on open source projects. Here's the
harsh economic reality: it is simply better business for us to spend a
relatively small amount of money on open source support to get what we need
from fantastic projects like LuaJIT than to try to develop this stuff
ourselves.

 _My worst fear is CF taking this project into the shadows, developing it
closed-source (which they absolutely have a right to do) and not sharing their
insights with the community._

How do we "have the right to do" that? Whatever makes you think us trying to
closed source this would have any benefit to us? How is the Github account (of
which Mike Pall is an owner) us walling it off?

 _More than that, I don 't think there has been enough narrative between Mike
and the 'new LuaJIT crew' (CF) to determine how the project should be
structured._

I predict that if I hadn't sent an email to the list soliciting ideas and
input and had announced a new structure you would have complained that
everything had been done in the shadows.

