On Fri, Oct 31, 2014 at 8:10 AM, James Doyle <[email protected]> wrote:
> I'm cool with a new package manager. It seems strange to install node on a > server, right beside luvit, *only because you need npm*. Also having a > nice npmjs.org style repo would be cool. > > I like the node.js style of doing things. I think it fits nicely. I > actually use my same node-completions library for Sublime in the same code. > > Although, I would be interested in seeing what *"synchronous looking code > that actually ran asynchronously*" was like. > It's actually pretty simple in lua to detect if the caller is in a coroutine and block while waiting for some result. I do that in this example. If you pass in the callback, it works in normal non-blocking matter. If you omit the callback, it suspends the coroutine and resumes with the result when done. In these two examples, the `tcpConnect` and `channel.take` are slow operations that should never block the main thread. https://github.com/luvit/luvit/blob/cfc39ef6811c8c0da1c4bc4e0d27fd627deaadec/test-tls.lua#L277-L300 -- Sample usage using callback syntax tcpConnect("luvit.io", "https", function (err, stream) assert(not err, err) local channel = secureChannel( streamToChannel(stream)) channel.put("GET / HTTP/1.1\r\n" .. "User-Agent: luvit\r\n" .. "Host: luvit.io\r\n" .. "Accept: *.*\r\n\r\n") channel.take( function (err, data) assert(not err, err) p(data) end)end) -- Sample usage using coroutine syntaxcoroutine.wrap(function () local channel = secureChannel( streamToChannel(tcpConnect("luvit.io", "https"))) channel.put ("GET / HTTP/1.1\r\n" .. "User-Agent: luvit\r\n" .. "Host: luvit.io\r\n" .. "Accept: *.*\r\n\r\n") p(channel.take())end)() > > On Tuesday, October 21, 2014 3:30:54 PM UTC-4, Tim Caswell wrote: >> >> Since working on luvit became my full-time job, I've been super busy >> paying off technical debt and cleaning up the lower layers and now it's >> time for the interesting high-level discussions. >> >> So first to recap the current status. I've finished rewriting my >> libuv-lua bindings. The code can be found at https://github.com/luvit/ >> luv. This has much better test coverage than the previous version and >> more closely follows libuv. Also it uses the new libuv 1.x APis and is >> currently built against libuv 1.0.0-rc3. >> >> Next there is a small project known as "luvi >> <https://github.com/luvit/luvi>". This builds a luajit binary with the >> luv bindings baked in. Also it has a tiny bootstrapper that allows LÖVE >> style packaging. Simple write your app as a folder of lua files with main >> being at "main.lua". Then zip this folder and append it to the luvi binary >> and you now have a self-contained binary for your app without ever needing >> to build luajit or luv yourself. (I'll publish binaries for all popular >> platforms. Windows version can currently be found on appveyor >> <https://ci.appveyor.com/project/creationix/luvi/build/artifacts>. >> >> The next step is to decide how to integrate this new base into luvit >> itself. I have a few questions for the community. >> >> 1. Are you set on the node.js clone APIs currently in luvit? >> >> 2. Which sugar APIs from luvit do you depend on? (event emitters, >> objects, streams, net, etc) >> >> 3. Would you like freedom to try other async styles (coroutines, >> channels, etc)? >> >> 4. How important is the ability to ship a single binary for your project? >> >> 5. Would you rather use luv as a module to vanilla lua or luajit (perhaps >> through luarocks)? >> >> I'm not in love with many of the node.js APIs even though I was there >> when they were originally designed back in 2009. In particular I think the >> stream interface in node is pretty bad and complex. Luvit currently >> doesn't take advantage of coroutines in lua which could dramatically >> simplify async work. >> >> I propose we break out the node.js style API sugar into a standalone >> library that could be imported to a project for folks who prefer this >> style. This would leave room for other styles and expose the raw >> underpinnings in luvi for people like me who like working closer to the >> metal. >> >> I'm also considering a package management system for sharing and reusing >> such modules. I want to make it trivial for a community to start growing >> around this tiny core and see what's important to various people. >> >> I've talked some to the virgo agent <http://virgoagent.com/> team at >> Rackspace (of which I'm a member). I'd love to hear from someone on the >> Torch7 <http://torch.ch/> team and anyone else who uses or wants to use >> luv or luvit. >> >> Let me know what you think. >> >> -Tim Caswell >> @creationix >> >> -- > You received this message because you are subscribed to the Google Groups > "luvit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "luvit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
