Time Nick Message 00:00 pgimeno also, not that I like that option in the least, but ever considered luau? 00:06 MTDiscord pgimeno: true, though then you still have to trust the LuaJIT interpreter. you lose an independent interpreter to cross-check against. 00:13 red-001 pgimeno: isn't that already an issue if a mod uses a feature implemented in LuaJIT but not 5.1? 00:26 red-001 I would still probably be for just supporting only LuaJIT, mods and the engine having to support two slightly different Lua environments is messy and LuaJIT is the only one that has any maintainers at all. Maybe could go with Luau as the secondary supported implementation for checking LuaJIT against? 00:27 MTDiscord iirc luau has issues like no dofile, and other things stripped out that would have to be added back 00:27 MTDiscord no tail recursion 😡 00:27 red-001 ah well that's a shame 00:28 red-001 I mean dofile or whatever is not a big deal but changes to recursion might be a problem 00:28 MTDiscord see https://luau.org/compatibility, its a lot 00:31 red-001 it would be nice to get a supported and maintained core even if some standard libraries would still need to be vendored in 00:32 red-001 LuaJIT seems to break encapsulation for the standard library (or at least uses their FFI) but stock Lua does everything through the standard C API 00:34 red-001 no __pairs/__ipairs support is a bit annoying 00:36 red-001 but pairs/ipairs is implemented using the C API, not in the guts of the VM/interpreter 00:37 MTDiscord i'm fairly sure that luajit has special optimizations for pairs/ipairs 00:38 red-001 I meant in PUC Lua, LuaJIT already implements the metamethods for those when compiled in 5.2 compat mode 00:39 MTDiscord problem with the compat mode is (as sfan pointed out on the issue) that whether that's enabled depends on distros, at least when we link luajit dynamically 00:40 red-001 do most distros just ship one LuaJIT package that may or may not have it enabled? 00:40 MTDiscord pretty much 00:40 red-001 seems kinda like poor package management on their part if so, they wouldn't ship PUC Lua as just one package no matter which version it is 00:41 MTDiscord also its generally outdated due to it being rolling release 00:41 MTDiscord also debian/ubuntu dont enable gc64 which is a notable issue servers at least 00:41 MTDiscord tbh we could consider linking it statically, especially as we strongly recommend latest master... 00:45 red-001 probably a good idea tbh, distros can complain about it but also can't rely on any sort of sane way to ask for certain compile options on their version of the package 02:41 MTDiscord And git submodule it? 02:43 MTDiscord nah, they would rather make submodules at home in some cursed fashion instead of ever using anything standard (i wish this was sarcasm) 02:44 MTDiscord Anyway, I implemented the reviews on #14543, refactoring and heavily simplifying the code (partially relying on changes made to that file in the meantime, thanks @sfence). 02:44 ShadowBot https://github.com/minetest/minetest/issues/14543 -- Add gameid aliases by nauta-turbidus 02:44 MTDiscord (yes this is an irrlichtmt reference, lets please not do that again) 02:45 MTDiscord That should have been git subtree 02:46 MTDiscord Submodules are better for things that are supposed to be developed externally 02:46 MTDiscord Like LuaJIT, which is not related to this project 02:47 MTDiscord Subtree incorporates one project into another, preserving commit history... and making it easier to include changes from the other repo if needed (not needed in this case, still better for commit history). 02:47 MTDiscord except subtree puts something in your project, while the point was to keep it external till it was ready to put it in 02:47 MTDiscord Subtree allows pulling in further external changes though 02:48 MTDiscord With relative ease 02:48 MTDiscord And I'm referring to the thing done in the end, where the whole irr folder is one big "bundle" commit IIRC 02:49 MTDiscord you missed my point, but i digress. i suppose the c++ fetch content or whatever it is could also be used, typically package managers dont like that, but there already going to not like statically linking it anyways 02:49 red-001 submodules aren't that bad tbh 02:49 MTDiscord agreed 02:50 MTDiscord I think I understand now. 02:51 red-001 so I gave luau some more thought, some of those syntax extensions could be annoying (what if someone writes their mod expecting them to be supported?), but that's already an issue with LuaJIT and Lua 5.1 02:52 red-001 it is probably the best maintained Lua 5.1 implementation right now 02:53 MTDiscord take my two bent pennies for what there worth, but so far the easiest is probably either to port on 5.2 stuff to our 5.1 to match luajit(statically linked), or 5.2 with polyfills for a few 5.1 things with luajit(statically linked) to have the best cross combability 02:56 red-001 well if you want to try the first one #15134 could use a review or testing, got through a decent chunk of the changes needed for LuaJIT-ish features 02:56 ShadowBot https://github.com/minetest/minetest/issues/15134 -- [no-sq] Some Lua 5.2 backports by red-001 02:59 red-001 if we really really wanted to stick to PUC Lua but still vendor it in, could switch to Lua 5.2 and port Lua 5.1 environments over. If there really is a need to support even someone abusing the debug API like that example I suppose can just change the bytecode generator to make sure each function gets _ENV as an upvalue (if needed), as messy as that would be. 03:00 red-001 but to be honest, Lua 5.2 is also not supported anymore. #maintainers is zero 03:00 red-001 luau is backwards compatible even if it adds some features that Minetest doesn't want because LuaJIT doesn't implement them 03:01 red-001 and it's maintained by MoneyPrinter Corporation for use in their MoneyPrinter line of products 03:02 red-001 so is probably going to be maintained for the foreseeable future 03:04 MTDiscord did lua5.2 fix the stack trace thing we originally "forked" lua5.1 for? dont recall 03:04 MTDiscord i guess i could test the pr, but i do try to avoid engine dev as to not get involved in yet another minetest area 03:05 MTDiscord also i dont know where, but someone here in irc got luau working with minetest at one point 03:09 MTDiscord https://irc.minetest.net/minetest/2021-11-04, see comments by icedragon 03:09 MTDiscord https://github.com/IceDragon200/minetest/tree/luau-support 03:20 red-001 I think I see an easier way to do that, might try it 03:20 red-001 Minetest *does* include a copy of luaxlib and like the rest of the *lib files it only depends on the main Lua header 03:26 red-001 ah I see the issue, thanks for linking that! 03:28 MTDiscord np 03:33 red-001 Looking at their standard library implementation it seems lua_getstack was not implemented because there's no need for it anymore, they merged it with lua_getinfo, presumably because those two tend to be used together anyways 09:44 sfan5 tbh I don't understand why invest so much time in this area 09:45 sfan5 supporting PUC lua is good to avoid "all eggs in one basket" situations and as a fallback 09:47 sfan5 but upwards of 95% of players use luajit so who benefits from this? and not like it makes maintenance any easier, we've had to do almost zero changes to lua 5.1 over the years 09:50 MTDiscord Could #15061 be added in the 5.10 milestone? I've already fixed the most of the UV issues and also mipmapping artifacts. 09:50 ShadowBot https://github.com/minetest/minetest/issues/15061 -- Texture atlas for mapblocks meshes by Andrey2470T 09:51 sfan5 02:38 I meant in PUC Lua, LuaJIT already implements the metamethods for those when compiled in 5.2 compat mode 09:52 sfan5 this is a largely theoretical concern. you have to go out of your way to disable it, so why would anyone do it? and if someone raised a bug in this regard I bet distros would consider it a defect that the 5.2 compat isn't enabled 09:52 sfan5 02:41 <+MTDiscord> also debian/ubuntu dont enable gc64 which is a notable issue servers at least 09:52 sfan5 this is incorrect. debian has moved on from the old 2.1.0-beta3 and now packages openresty's fork 09:53 MTDiscord Also taken into account creating additional atlases if the current one is on the verge of the overflowing 09:57 sfan5 not to mention that breaking changes in something as central as lua are absolutely not an option right now or soon. 10:24 MTDiscord sfan5: +1 11:22 MTDiscord Sfan5, maybe something changes since the last time i tested, but they both have the 2gb memory limit in place 11:28 sfan5 shouldn't be the case in debian testing 11:46 sfan5 (I checked the sources they build from. didn't test) 12:00 MTDiscord tested on ubuntu 20.04 with grow.lua, https://pastebin.com/gPU8cVye, taken from some stackoverflow a while ago, crashes at 2075747.6386719 KB 12:05 pgimeno " pgimeno: isn't that already an issue if a mod uses a feature implemented in LuaJIT but not 5.1?" sure, but LuaJIT is much more used and it's unlikely that a server will use PUC Lua. Also, people are typically aware of the fact that they're using LuaJIT-specific features and make them conditional (notable exception: hex escapes in string literals) 12:06 MTDiscord same with 22.04 12:07 pgimeno and the *only* reason I brought up Luau is sandboxing. It has a few good enhancements - better garbage management, more speed - but otherwise it's not a big gain and it has the drawback of being MS stuff 12:07 MTDiscord anyways, more so care about an opinion on #14999 12:07 ShadowBot https://github.com/minetest/minetest/issues/14999 -- minetest 5.9 mapblock flickering depending on camera view 17:14 Krock so I'd assume that at least all Maxwell 2.0 cards would have the same issue - at least on Linux. 17:15 Krock it is very interesting that this somehow solves your issue because there's nothing about the map rendering going on 17:20 Krock this means that glBufferDataARB is present. perhaps we could try with glBufferData because the ARB extension is for OpenGL < 1.5 compatibility 17:21 MTDiscord I'd like #14543 to be taken a look at during the upcoming meeting, if it is possible. 17:21 ShadowBot https://github.com/minetest/minetest/issues/14543 -- Add gameid aliases by nauta-turbidus 17:22 Krock the next meeting will be filed with 5.9.1 topics I'm afraid. Let's see. I'll add it. 17:24 MTDiscord Krock: I just hope it'll make it before 5.10 feature freeze 17:24 MTDiscord Thanks anyway 17:25 Krock @wsor4035 Does the driver opengl vs opengl3 make a difference? The buildbot build should support both. 17:25 MTDiscord thats covered in the issue (iirc no, but opengl3 with gl debug on works) 17:25 sfan5 is opengl3 even enabled by default? 17:26 sfan5 if not we should enable it 17:26 MTDiscord anyways, my comment this morning was aimed at sfan5 as a follow up to the one from last night 17:26 MTDiscord since it didnt get a response 17:26 Krock "iirc" means we won't know until it's certain 17:28 MTDiscord as stated in the first half of the comment, its covered in the issue. iirc is from my memory without looking at the issue 17:28 Krock opengl3 uses glBindBuffer + glBufferData + glBindBuffer(reset) no ARB extension 17:29 MTDiscord https://github.com/minetest/minetest/issues/14999#issuecomment-2309050261 17:30 MTDiscord what i was following up to from the last night: https://irc.minetest.net/minetest-dev/2024-09-08#i_6199928 17:30 Krock I see. Thanks. It's strange that it happens on both implementations. It must be driver related 17:31 MTDiscord sfan5: opengl3 wasnt default when i did testing with it 17:32 Krock createOpenGL3Driver depends on SDL, and SDL is disabled for 5.9.0 17:57 sfan5 I meant enabled = compiled in 18:32 sfan5 there's some great entanglement between client stuff and our definition managers 18:33 sfan5 (irony) 18:52 v-rob Why in the world does drawVertexPrimitiveList() have both primitiveCount and vertexCount parameters? vertexCount can be (and is) calculated by using primitiveCount 18:58 sfan5 huh yeah the gl3 driver does not use it, it must be != 0 but other than that it assumes you have provided enough 19:19 sfan5 rubenwardy: is it intentional that /icon.png can be any extension but /screenshot.png is only searched with .png? 19:20 sfan5 sorry, /menu/icon.png actually 19:20 sfan5 because it's put through getImagePath 19:29 v-rob I'm doing a tiny bit of cleanup in the OpenGL code so I can add a few features, so I'll probably make a PR to remove that unnecessary parameter 19:31 rubenwardy sfan5: I that predates me, it's not a specific choice I made 19:31 rubenwardy +think 19:45 v-rob I suppose vertexCount could be used with glDrawRangeElements, but we use glDrawElements anyway 19:47 v-rob Guess I'd better not change it then 20:00 sfan5 before I sink more time into this #15126 is now ready for review 20:00 ShadowBot https://github.com/minetest/minetest/issues/15126 -- [no squash] Share objects between client / server builds by sfan5