Re: ActiveState seeking Lua community feedback

[Mason Bogue <scythe+lua@...>]

>If you would like to ask any questions or provide thoughts on where we can best help the Lua community

The biggest weakness of the Lua community is probably fragmentation,
so one of the best ways that you can help the community is by working
with the other people in your space. There are a number of "standard
library" attempts:

For PUC Lua:
http://luadist.org/

For LuaJIT:
http://luapower.org/
http://torch.ch/

LuaRocks (http://luarocks.org/) is probably the most important Lua
module system, so of course your product must work with LuaRocks. In
addition to that it could help to discuss with the maintainers of the
above projects how you can support using those distributions in your
IDE (Torch is huge; the other two should be easy).

There are a couple of frameworks for Lua that are popular; one of the
most important projects for hobbyists is LÖVE, which is used for
making little indie games (I think of it as a better Flash but without
the convenience of NPAPI):

http://love2d.org/

There are a lot of other game development frameworks that use Lua, of
course; There are also two (I think only two?) significant Lua web
frameworks:
http://leafo.net/lapis
http://sailorproject.org/
Particularly the latter seems to be tilted towards ease-of-use and so
they would probably be happy to have an IDE that had good support for
it, although whether the project is really ready for that kind of
investment on your part isn't my judgment call.

There are also two significant GUI frameworks, of which Qt Lua is
probably more significant:
http://github.com/torch/qtlua -- binding to Qt (LGPL)
http://github.com/peersuasive/luce -- binding to JUCE (a
GPL-or-commercial product which apparently makes money)
I think the people behind these would be happy to hear from you.

Lua has always had multithreading support, but parallelism in pure Lua
requires the use of an external library. Debugging parallel Lua
programs written with those libraries requires more work on the part
of the debugger than debugging vanilla Lua. The most important
concurrency solutions for Lua are:

http://github.com/askyrme/luaproc
http://cmr.github.io/lanes
http://github.com/torch/threads (integrated into the torch7 library)

Having the IDE actually work with these is a major advantage.
Debugging parallel code is pretty hard, so being able to do it is very
nice.

The other thing that comes to mind is that there is a pretty large
fraction of Lua users who primarily communicate in Portuguese (the
language is from Brazil) and there is also some significant adoption
of Lua by Chinese-speaking users, and supporting those languages would
probably be good for both your marketshare and the community as a
whole.

Anyway there's a lot you can do. You're not the first to try to bring
order to the Lua universe -- just try to be the best.

-Mason

On Wed, Nov 2, 2016 at 9:52 AM, Russell Haley <russ.haley@gmail.com> wrote:
> On Wed, Nov 2, 2016 at 2:56 AM, KHMan <keinhong@gmail.com> wrote:
>> On 11/2/2016 3:07 AM, Jeff Rouse wrote:
>>>
>>> [snip]
>>> At ActiveState we have been in the open source tools and languages
>>> business (Python, Perl, Tcl) for almost 20 years. We also build
>>> developer tools, which are our Komodo Edit (open source) and IDE,
>>> which has basic Lua support, and we are actively making further
>>> Lua development improvements in those products.
>>
>>
>> As a contributor to the Scintilla edit control, I applaud ActiveState's long
>> history of contributing to that project, and look forward to seeing more Lua
>> developer tools appearing in the market.
>>
>> Most hardware hobbyists have yet to move to IoT/embedded hardware with
>> plenty of RAM and CPU power, but we're already seeing folks impressed by
>> trailblazers like nodeMCU.
> OMG. WANT!
>
> With plenty of CPU and RAM, scripting and its
>> attendant benefits can be embraced with minimal downsides, just as the
>> gaming industry has done. When AAA games are built on game engines with
>> scripting and all, they must have hit on something right. Complex IoT can
>> benefit from productivity multipliers in the same way.
>
> Using lua-http and cqueues I've so far been able to produce a small
> IoT proof of concept in a few months at night. The memory usage isn't
> where I want it to be right now, but Lua has done exactly what it's
> supposed to do: wrap other languages so I don't have to learn them. I
> haven't written a lick of C yet and I have a fully polled and threaded
> application. Debian and FreeBSD support. Websocket or HTTP, TLS
> support, file polling, GPIO (work in progress on FreeBSD). Interrupt
> handling is (hopefully) next.
>
> I was hoping to support something small like an M4 or a little PIC,
> but I don't know if that's going to be possible. That's a different
> post that I'll get to later this week. :)
>
> https://github.com/daurnimator/lua-http
> http://www.25thandclement.com/~william/projects/cqueues.html
>
> https://github.com/RussellHaley/lua-http-endpoints (currently broken)
>
> Cheers,
>
> Russ
>
>> Although I have been updating Lua syntax highlighting for the Scintilla edit
>> control, I prefer to code old-school with a bare-bones editor, so I will
>> defer to others on the list on what they wish for in IDEs or platforms. I
>> also welcome contributions upstream to improve Lua syntax highlighting for
>> Scintilla, if there are any in the course of ActiveState's work.
>>
>> It's great to hear of such endeavours, looking forward to future
>> announcements!
>>
>> --
>> Cheers,
>> Kein-Hong Man (esq.)
>> Selangor, Malaysia
>>
>>
>