It is already all done on top of Luvit (and running very nicely for the most part) so it definitely needs to happen on top of that. I was already thinking that I would split the whole luvit build process out and build each element separately rather than your combined makefile since I have had several issues with that any my toolchain which may have some bearing on the issues I'm seeing (no certainty though. switching on a lot of debugging has thrown up other issues as always with smaller embedded systems).
I saw that you had a separate makefile to build a shared library for luv in your 1.0 project but some elements are still missing (fs.c for example). I guess that will be what you finish off in the next week. I can try to integrate that next week with Luvit once you have finished. I'm working within a very specific build system so it won't be very relevant for wider consumption. On Tuesday, September 30, 2014 11:05:57 PM UTC+2, Tim Caswell wrote: > > I'm working full-time on the luv update. I expect it to be done within a > week. I'm not sure how much time will be needed to migrate luvit to it > though. Do you want to build on top of the luvit APIs or are you willing > to build on top of luv's APIs directly? Also the general idea for luv's > API is still under discussion. You can see part of it at > https://github.com/luvit/luv/issues/65 > > On Tue, Sep 30, 2014 at 2:03 PM, Martin Croome <[email protected] > <javascript:>> wrote: > >> Hi Tim >> >> Thanks for the confirmation. I'm still seeing some weird things happening >> with current Luvit when I run on an embedded ARM platform (may be build >> environment/kernel version/uclibc related but I'm still tracking it down. >> One of the issues is getting hung in epoll on exit.). Still trying to >> figure out some of them. I'm working on quite a large project which I'm >> basing on Luvit so I would *really* like to understand your timeline on >> a new luv version so that I do not waste time plugging leaks that will get >> fixed anyway. I'm about a month or two out from having to make a release. >> If you need any beta testing I'm open to it ... >> >> A large portion of the project is planned to be open sourced. Currently >> added bits include ... linux native serial bindings ... web sockets plugin >> for Utopia ... mini-express-like app plugin for Utopia ... plus large >> portions of the final project which is under wraps for the moment and a few >> other bits and pieces. >> >> All the best >> >> Martin >> >> >> On Tuesday, September 30, 2014 4:51:19 PM UTC+2, Tim Caswell wrote: >>> >>> Yep, I'm currently rewriting luv to use the latest libuv version. There >>> have been a *lot* of breaking changes in libuv. But the good news is the >>> new version should be around for a while and it being tagged 1.0.0 upstream >>> with semver API/ABI stability promises. >>> >>> The new luv code (in https://github.com/luvit/luv/tree/uv-update-1.0.0) >>> uses a simpler model for memory management. The libuv structs are passed >>> directly to lua as userdata values. There is no wrapper struct. >>> >>> Rather I'm using the void* data member of all libuv objects to create a >>> tiny luv managed struct containing lua_State and a couple refs (to the >>> userdata and it's current lua_State) to prevent GC eating things before >>> libuv is done. I create the userdata ref upon userdata creation and don't >>> free it till userdata close callback. This means you'll leak lua memory if >>> you never close your objects, but since you'll leak memory on the libuv >>> side anyway if you forget to close them, I don't see that as an issue. >>> Also using uv.walk, you can get a reference to all the active objects in a >>> loop. I might be able to add some sort of multithreading so that you can >>> have multiple concurrent event loops. >>> >>> Libuv uv_req_t structs are also exposed to lua this time around. They >>> work mostly the same as the handle structs. I ref them upon creation and >>> unref them when the callback fires. And yes, I'll need to unref >>> first-thing in the callback in case of early exit due to error states. >>> >>> The other big difference in this new version is how lua_States are >>> allocated. All events emitted (like connection, timeout) will call the lua >>> callback in a new coroutine that inherits shared scope from it's parent >>> lua_State. One-off functions like uv.close and uv.write will suspend the >>> current coroutine and resume when the operation is done. This makes things >>> much simpler in some respects and makes the lua code much more linear. The >>> node.js style APIs in luvit will probably stay callback based for API >>> consistency, but I hope people will migrate to the more minimal API in luv >>> and use the upcoming luvi project to build their own luvit style platforms. >>> >>> On Mon, Sep 29, 2014 at 11:57 PM, Martin Croome <[email protected]> >>> wrote: >>> >>>> This definitely helps: >>>> >>>> #define FS_CALL(func, cb_index, path, ...) >>>> \ >>>> do { >>>> \ >>>> uv_err_t err; >>>> \ >>>> int argc; >>>> \ >>>> if (lua_isfunction(L, cb_index)) { >>>> \ >>>> if (uv_fs_##func(luv_get_loop(L), req, __VA_ARGS__, >>>> luv_after_fs)) { \ >>>> err = uv_last_error(luv_get_loop(L)); >>>> \ >>>> luv_push_async_error(L, err, #func, path); >>>> \ >>>> uv_fs_req_cleanup(req); >>>> \ >>>> >>>> * free(req->data); >>>> \* >>>> >>>> * return lua_error(L); >>>> \* >>>> } >>>> \ >>>> return 0; >>>> \ >>>> } >>>> \ >>>> if (uv_fs_##func(luv_get_loop(L), req, __VA_ARGS__, NULL) < 0) { >>>> \ >>>> err = uv_last_error(luv_get_loop(L)); >>>> \ >>>> luv_push_async_error(L, err, #func, path); >>>> \ >>>> uv_fs_req_cleanup(req); >>>> \ >>>> >>>> * free(req->data); >>>> \* >>>> >>>> * return lua_error(L); >>>> \* >>>> } >>>> \ >>>> argc = luv_process_fs_result(L, req); >>>> \ >>>> lua_remove(L, -argc - 1); >>>> \ >>>> >>>> * uv_fs_req_cleanup(req); >>>> \* >>>> >>>> * free(req->data); >>>> \* >>>> return argc; >>>> \ >>>> } while (0) >>>> >>>> >>>> -- >>>> 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] <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.
