 |
lua-l archive |
|
|
||
|
Hi Mason,Thanks for your outstanding response. We are collecting all of this great feedback to see where we can best help Lua.
Cheers, -JR On 2016-11-02 12:20 PM, Mason Bogue wrote:
If you would like to ask any questions or provide thoughts on where we can best help the Lua communityThe 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 itsattendant 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, RussAlthough 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