Migrate to Lua 5.4 #781
Migrate to Lua 5.4 #781
Conversation
|
Based on the discussion #556 , and on discord, I think this is the way to go. If there's no strenuous objections here (@franko, your input would be appreciated, if you have some time to comment); but tl;dr from #556, 5.4 is just way more supported, more performant, and all-in-all a better way to go moving forward. And those who really desperately want jit, can just swap out the I also like the fact that we're no longer vendoring lua; that should make it generally easier to upgrade and switch versions without having to maintain the repository ourselves. |
data/core/tokenizer.lua
Outdated
| @@ -72,7 +73,7 @@ local function retrieve_syntax_state(incoming_syntax, state) | |||
| -- syntax we're using. Rather than walking the bytes, and calling into | |||
| -- `syntax` each time, we could probably cache this in a single table. | |||
| for i = 0, 2 do | |||
| local target = bit32.extract(state, i*8, 8) | |||
| local target = bit.extract(state, i*8, 8) | |||
There was a problem hiding this comment.
The calls to bit32.extract and bit32.replace should probably be replaced with more native logic.
I'm not fluent with Lua so its probably best I leave this to someone else.
data/core/tokenizer.lua
Outdated
| @@ -114,7 +115,7 @@ function tokenizer.tokenize(incoming_syntax, text, state) | |||
| -- Should be used to set the state variable. Don't modify it directly. | |||
| local function set_subsyntax_pattern_idx(pattern_idx) | |||
| current_pattern_idx = pattern_idx | |||
| state = bit32.replace(state, pattern_idx, current_level*8, 8) | |||
| state = bit.replace(state, pattern_idx, current_level*8, 8) | |||
| function bit.extract(n, field, width) | ||
| local r = trim(field) | ||
| local f = width | ||
| r = (r >> f) & mask(width) | ||
| return r | ||
| end | ||
|
|
||
| function bit.replace(n, v, field, width) | ||
| local r = trim(v); | ||
| local v = trim(field); | ||
| local f = width | ||
| local m = mask(width); | ||
| r = (r & ~(m << f)) | ((v & m) << f); | ||
| return r | ||
| end |
There was a problem hiding this comment.
These functions have been crafted by looking at the lua-bit32 implementation of them and rewriting them in Lua
| @@ -42,7 +42,7 @@ end | |||
|
|
|||
|
|
|||
| function common.distance(x1, y1, x2, y2) | |||
| return math.sqrt(math.pow(x2-x1, 2)+math.pow(y2-y1, 2)) | |||
| return math.sqrt(((x2-x1) ^ 2)+((y2-y1) ^ 2)) | |||
There was a problem hiding this comment.
math.pow has been deprecated with Lua 5.3
https://www.lua.org/manual/5.3/manual.html#8.2
| lua_dep = dependency('lua5.4', required : false) | ||
| if not lua_dep.found() | ||
| lua_dep = dependency('lua', fallback: ['lua', 'lua_dep'], | ||
| default_options: ['line_editing=false', 'default_library=static'] |
There was a problem hiding this comment.
line_editing is equivalent to use_readline
default_library=static is equivalent to shared=false
|
For future reference the .wrap was gathered from https://mesonbuild.com/Wrapdb-projects.html which includes the correct patch links that includes the meson files |
|
If there's no comment from Franko on this, I will merge as of Friday (the 7th). |
|
In this moment I don't have enough time to follow the developments that are going on in the master branch but I am glad to see the project moving forward. As for the transition to Lua 5.4 I have no objections, you can proceed to merge. I think the LuaJIT branch will just remain an experimental build I did for the 2.0 branch, that's all. |
|
OK; actually, after merging these changes, I'm experiencing a major performance regression (most noticeable while scrolling). Does anyone else see this? I may actually want to revert this if that's the case, until we can identify the underlying cause. |
|
OK. So I'm pretty sure this actually isn't CPU judder; I checked the CPU usage; and it's actually down in 5.4 from what it was before (this is expected); but it still "feels" stutter-y. I suspect this could have something to do with scrolling involving integers instead of floats; which could potentially lead to stutter if things are being rounded weirdly. I'll investigate. |
|
OK; turns out it's because time was being pushed as a whole integer, instead of with its milliseconds as decimals. Just committed directly to master to fix; should work now. |
luaMAJOR.MINORandluabeing the most common ones)