I'm interested in luvit working with normal Lua binaries. As I mentioned in a question some months ago, I'm working on a project where LuaJIT isn't an option because of CPU architecture. I succeeded in porting luv/luvi/luvit to Lua 5.3.1 as collection of shared objects and lua files instead of a statically linked, self contained binary. That caused the code to diverge a bit (especially in luvi) from the official project, but so far I've kept mostly up to date with upstream. It would be really helpful to my project to have more official support for Lua mainstream in addition to LuaJIT.
We haven't yet had a need for other third party Lua libraries that aren't compatible with luvit. The functionality of luvit and libuv have been sufficient. I have added a great deal of linkage into our own proprietary code via another library, but I wrote it specifically to be used with luvit. We're using luvit more like nodejs, but I must admit it was a challenge for me to fully understand the complexities of luvit's require system in combination with Lua's. Replacing it with a more lua-esque package loader would be a welcome change. On Friday, December 18, 2015 at 8:13:38 AM UTC-6, Tim Caswell wrote: > > Thanks for the feedback, keep it coming. I'm starting on the > transformation. > > The first step is to implement a set of lua loaders (for package.loaders) > that works mostly like the current luvit require system. This will mean we > stop overriding lua's require and simply add to it. > > Also I'll be changing the lit metadata format so that luvit modules can be > loaded by normal lua without needing the syntax changed. > > The next step after that is tricky, but I'd love to send a patch to > luarocks allowing it to install directly from a lit package server. I > really don't want to publish to two different places. > > Even if luarocks doesn't take the change or it's too hard technically, > users can simply install lit in addition to luarocks and use both to > install their libraries. > > -Tim Caswell > On Dec 18, 2015 2:54 AM, "Ben Powers" <[email protected] <javascript:>> > wrote: > >> >> When I first looked into luvit I thought it would be perfect for a >> project I had always wanted to tackle right up until I realized it was a >> tight knit system not a library. >> >> the reason I wanted to use luvit was because I wouldn't have to fail at >> tieing into libuv myself nor would I have to implement my own networking >> stack on top as luvit already had what I wanted. >> but trying to decouple those interfaces from the run-time proved too >> difficult at the time so I've mostly just been following it's development >> ever since hoping a topic like this would come up. >> >> personalty I was hoping dropping in luvit and a libuv blinding would >> "just work" in an existing luajit run-time. >> >> the existing luvit runtime couples system could certainly continue to >> exist but surely there is way to pull luvit away from it's Luv runtime and >> still keep a majority of it's functionality. >> >> -- >> 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] <javascript:>. >> 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.
