| Time |
Nick |
Message |
| 00:00 |
pgimeno |
also, not that I like that option in the least, but ever considered luau? |
| 00:06 |
MTDiscord |
<luatic> 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:16 |
|
SFENCE joined #minetest-dev |
| 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 |
<wsor4035> iirc luau has issues like no dofile, and other things stripped out that would have to be added back |
| 00:27 |
MTDiscord |
<luatic> 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 |
<wsor4035> 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:36 |
|
SFENCE joined #minetest-dev |
| 00:37 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<wsor4035> 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 |
<wsor4035> also its generally outdated due to it being rolling release |
| 00:41 |
MTDiscord |
<wsor4035> also debian/ubuntu dont enable gc64 which is a notable issue servers at least |
| 00:41 |
MTDiscord |
<luatic> 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 |
| 00:55 |
|
SFENCE joined #minetest-dev |
| 01:36 |
|
SFENCE joined #minetest-dev |
| 02:00 |
|
SFENCE_arch joined #minetest-dev |
| 02:41 |
MTDiscord |
<herowl> And git submodule it? |
| 02:43 |
MTDiscord |
<wsor4035> 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 |
<herowl> 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 |
<wsor4035> (yes this is an irrlichtmt reference, lets please not do that again) |
| 02:45 |
MTDiscord |
<herowl> That should have been git subtree |
| 02:46 |
MTDiscord |
<herowl> Submodules are better for things that are supposed to be developed externally |
| 02:46 |
MTDiscord |
<herowl> Like LuaJIT, which is not related to this project |
| 02:47 |
MTDiscord |
<herowl> 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 |
<wsor4035> 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 |
<herowl> Subtree allows pulling in further external changes though |
| 02:48 |
MTDiscord |
<herowl> With relative ease |
| 02:48 |
MTDiscord |
<herowl> 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 |
<wsor4035> 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 |
<wsor4035> agreed |
| 02:50 |
MTDiscord |
<herowl> 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 |
<wsor4035> 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 |
<wsor4035> did lua5.2 fix the stack trace thing we originally "forked" lua5.1 for? dont recall |
| 03:04 |
MTDiscord |
<wsor4035> 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 |
<wsor4035> also i dont know where, but someone here in irc got luau working with minetest at one point |
| 03:09 |
MTDiscord |
<wsor4035> https://irc.minetest.net/minetest/2021-11-04, see comments by icedragon |
| 03:09 |
MTDiscord |
<wsor4035> 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 |
<wsor4035> 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 |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 07:59 |
|
hwpplayer1 joined #minetest-dev |
| 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 |
<andrey2470t> 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 <red-001> 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> <wsor4035> 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 |
<andrey2470t> 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 |
<herowl> sfan5: +1 |
| 11:10 |
|
hwpplayer1 joined #minetest-dev |
| 11:22 |
MTDiscord |
<wsor4035> 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 |
<wsor4035> 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 |
"<red-001> 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 |
<wsor4035> 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 |
<wsor4035> 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 |
| 13:45 |
|
untilted joined #minetest-dev |
| 14:15 |
|
SFENCE_arch joined #minetest-dev |
| 14:15 |
|
SFENCE joined #minetest-dev |
| 14:16 |
|
SFENCE joined #minetest-dev |
| 14:24 |
|
Lupercus joined #minetest-dev |
| 15:03 |
|
SFENCE joined #minetest-dev |
| 16:01 |
|
SFENCE joined #minetest-dev |
| 16:19 |
|
SFENCE joined #minetest-dev |
| 16:27 |
|
SFENCE joined #minetest-dev |
| 16:32 |
|
ivanbu joined #minetest-dev |
| 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 |
<herowl> 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 |
<herowl> Krock: I just hope it'll make it before 5.10 feature freeze |
| 17:24 |
MTDiscord |
<herowl> Thanks anyway |
| 17:25 |
Krock |
@wsor4035 Does the driver opengl vs opengl3 make a difference? The buildbot build should support both. |
| 17:25 |
MTDiscord |
<wsor4035> 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 |
<wsor4035> anyways, my comment this morning was aimed at sfan5 as a follow up to the one from last night |
| 17:26 |
MTDiscord |
<wsor4035> since it didnt get a response |
| 17:26 |
Krock |
"iirc" means we won't know until it's certain |
| 17:28 |
MTDiscord |
<wsor4035> 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 |
<wsor4035> https://github.com/minetest/minetest/issues/14999#issuecomment-2309050261 |
| 17:30 |
MTDiscord |
<wsor4035> 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 |
<wsor4035> 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:41 |
|
Sokomine joined #minetest-dev |
| 17:52 |
|
hwpplayer1 joined #minetest-dev |
| 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:51 |
|
v-rob joined #minetest-dev |
| 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:05 |
|
Sharpman joined #minetest-dev |
| 19:06 |
|
hwpplayer1 joined #minetest-dev |
| 19:19 |
sfan5 |
rubenwardy: is it intentional that <game>/icon.png can be any extension but <game>/screenshot.png is only searched with .png? |
| 19:20 |
sfan5 |
sorry, <game>/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 |
| 20:02 |
|
hwpplayer1 joined #minetest-dev |
| 20:28 |
|
SFENCE joined #minetest-dev |
| 20:28 |
|
Desour joined #minetest-dev |
| 21:03 |
|
SFENCE joined #minetest-dev |
| 21:10 |
|
red-001 joined #minetest-dev |
| 21:40 |
|
SFENCE joined #minetest-dev |
| 22:29 |
|
SFENCE joined #minetest-dev |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 22:50 |
|
SFENCE joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
| 23:11 |
|
SFENCE joined #minetest-dev |
| 23:43 |
|
SFENCE joined #minetest-dev |
