lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> The wxLua editor is cool, but have a look at Paul K's Zerobrane
Studio, which is the souped-up and generally refined descendent of
that editor, reborn as an IDE.

FWIW, the next version of ZeroBrane Studio will package both LuaJIT
and Lua5.2 and will work with both out of the box on all supported
platforms (Windows XP+, OSX 10.6+, and various Linux flavors
32/64bit). It also includes its own (although it's hidden

What I would like as a user is to have two commands: one would install
the modules I need and the other one would put all the modules I need
for a script in one folder (so that the script and all its
dependencies can be copied to a different computer).

The first command would require a cross between LuaRocks and LuaDist
to have a repository of modules to query with references to binaries
for various platforms. I think "dist" from LuaDist comes close, but I
don't see it working with binaries (this is running from LuaJIT):

> ld = require 'dist'
> ld.install('lpeg')
Downloading repository information...
Finding out available versions of lpeg...
Getting lpeg-0.11 (source)...
Finding out available versions of lua...
Getting lua-5.2.2 (source)...
Error: command 'cmake' not found on system. See installation instructions at

Note that it tried to get lua-5.2.2 even though I'm running from Lua
5.1 compatible system (_VERSION == "Lua 5.1"). Ideally, this would
just get the binaries for lpeg and installs them where I need them to

Peter, could you make binaries available through ld.install?

I could then integrate this into ZBS to allow the user to type
"require 'foo'" in the console and it would check that 'foo' is not
locally available, would get its module description from
LuaRock/LuaDist, grab the .lua file or the binary appropriate for the
platform (and check the hash) and install it into the appropriate
folder (probably under ZBS by default).

The second command would run your script with a patched version of
"require" that would keep track of all the modules and their
dependencies to see what needs to be packaged. It could then copy
those dependencies into the project folder for distribution.

I know that binaries are not the best distribution format, but it does
have some advantages over source code distribution; for example, I
couldn't bootstrap luadist on my machine even though I have both
recent mingw and mingw-tdm (it just kept crashing! on compiling
luasocket 3.0). I don't have any numbers to support my claim, but will
venture to say that the majority Lua users on Windows probably don't
have cmake and mingw installed and will probably resort to searching
for a binary on the Internet.

Another issue for Windows uses is that some libraries are compiled
against different lua dlls. For example, ZBS libraries are compiled
against lua51.dll and lua52.dll, but LuaDist libraries are compiled
against liblua.dll, which makes them not to work with ZBS executables.
I "fixed" this by adding a proxy DLL that forwards calls from
liblua.dll to lib51.dll, but ideally we'd settle on one way to
name/reference the libraries. I've considered something similar to
liblua, but it has disadvantages for situations when one packages
needs to support both Lua 5.1 and Lua 5.2 (as it is in my case), so I
kept lua51 and lua52 names for dlls.


On Thu, Sep 26, 2013 at 5:14 AM, steve donovan
<> wrote:
> On Thu, Sep 26, 2013 at 1:47 PM, John Hind <> wrote:
>> ecosystem. The Community WiKi ought to be the starting point, but you'd be
>> hard pressed to find important parts of the ecosystem starting there or to
>> navigate what is salient today rather than being of historical interest
>> only.
> Yes, wikis are not self-organizing.  That's why there was a LuaForge 2
> project, to build a catalog with a rating system. It's still a good
> idea and I hope Pierre finds some time for it!
>> 3. LuaRocks: A non-GUI command-line system. Binary distribution for Windows
> This situation should improve now that we have settled on mingw builds
> for windows 32/64; we can then populate the repo with all the popular
> binary versions and LR can do its dependency magic without needing a
> compiler.
>> 4. LuaDist: Again strictly command-line. Binary distributions for the three
>> major platforms, but these do not include a distribution of Lua itself, only
>> the system for handling modules/packages.
> Have a look at the 'batteries' distribution on  This is
> intended to be the new 'Lua for Windows' but there are also Linux and
> OS X builds.
> The idea is to put a graphical front-end (using wxLua naturally) so
> that a person could install any module that was pure Lua or has been
> already compiled - this includes all the major packages.  It's just
> been a bit awkward finding out what they are, and this involves
> building a manifest of everything, which LD currently lacks.
> The wxLua editor is cool, but have a look at Paul K's Zerobrane
> Studio, which is the souped-up and generally refined descendent of
> that editor, reborn as an IDE.
> steve d.