-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lua 5.1 to 5.3 Realignment Phase 3 and baseline 5.3 #3075
Conversation
- Lots of minor but nasty bugfixes to get all tests to run clean - core lua and test suite fixes to allow luac -F to run cleanly against test suite - next tranch to get LFS working - luac.cross -a options plus fixes from feedback - UART fixes and lua.c merge - commit of wip prior to rebaselining against current dev - more tweaks
I want to validate that this merge was correct. If not then I will close and reissue. |
I have hoisted my It does appear that this branch regressed 49ac968, tho'; |
Other misc details / discussion points
But all of this can be refined in the light of serious testing feedback. What we really need now is for this to occur so that we can merge this branch into |
Absolutely, agreed! It makes for slightly more complex code but (perhaps counterintuitively) the code tends to be less likely to have memory leaks, as temporary raw unowned pointers become userdatas on the stack instead and thus will get cleaned up if the function returns early for eg. I've been trying to avoid ever using the |
This feature actually makes the code simpler: as you say temporary resources are referenced on the Lua stack and get dereferenced if and when you leave the routine for any reason, and the LGC will collect this memory on the next sweep. |
@HHHartmann @nwf perhaps the alternative to moving the LROT macros into |
I agree re: the use of userdata for C-side allocations whenever possible, but... a class of bug I have found in our C modules is that they intermixed allocations, initialization, and registrations with the SDK and derived subsystems. The result could be that, in OOM scenarios, live objects pointed to allocated but not fully constructed objects. For example, I have taken the approach of squashing allocations up into the userdata -- rather than pointing to the |
In general using userdata helps / simplifies things when the function aborts due to out of memory. The process should be (i) create the resources and leave them on the stack (ii) once all resources have been created then hook them where they belong. Temporary resources will be GCed after return. The issues arise if they need to be bound to other UDs as you can only do this with the Lua 5.3 API and so this is approach isn't portable. Where practical it is better to concatenate all dynamic resources into a single UD brick. There will always be a couple of modules such as net and tls where this can all get hairy, but these will always be hairy; what I am really thinking about are the typical C modules that other contributors ad and maintain |
👍 Will do |
Replay a line from nodemcu#2861 after accidental revert in nodemcu#3075 (specifically 9ef5c7d)
- Lots of minor but nasty bugfixes to get all tests to run clean - core lua and test suite fixes to allow luac -F to run cleanly against test suite - next tranch to get LFS working - luac.cross -a options plus fixes from feedback - UART fixes and lua.c merge - commit of wip prior to rebaselining against current dev - more tweaks
Replaces #2912 and thus addresses: #2808, #2839 (partial), #2858, #2890
To be addressed before merge: #2783
dev
branch rather than formaster
.docs/*
.This is replacement for #2912. We've a lot of changes to
dev
since the original version that the previous PR was based on that I couldn't update the PR after the latest merge without loosing the commit history so it was just easier to reissue the PR.Tweaks to standard
lua.h
andlauxlib.h
C API to provide a unified API subset for ourapp/modules
.Updates to
app/lua
to realigned APIs. The Lua 5.3 version significantly improves ROTable performance and introduces of function and table subtypes. These have regressed into theapp/lua
codebase so that both the 5.1 and 5.3 variants support this unified API.Updates to app/modules and supporting directories to realign APIs. A general cleanup of the modules to use the stricter Lua API implemented in (2). Modules now only access the C API through the public
lua.h
andlauxlib.h
interfaces.Addition on the
app/lua53
code tree to implement the Lua 5.3 VM and runtime. This includes the core changes needed to be able to buildLUA=53
and download a runnable Lua 5.3 firmware image onto the ESP.Common
lua.c
for both versions.lua.c
is the initiation framework to start the Lua VM and runtime. This one module is highly specific to the interface with the non-OS SDK. This code is now shared between the Lua51 and Lua53 frameworks without use of symlinks. See app/lua/lua.c.The whitepaper describing the scope of this work in detail is my gist: Lua 5.3 port to NodeMCU Firmware.