Time Nick Message 11:00 anon5[m] https://github.com/minetest/minetest/issues/10387 actually could be added, the client version is sent in the TOSERVER_INIT packet 11:01 MTDiscord Thank you for your input anon5! 11:06 anon5[m] no, it's the TOSERVER_CLIENT_READY packet 11:10 anon5[m] it looks like it's exposed to lua only in debug builds 11:11 MTDiscord yeah, just figured 11:11 MTDiscord #10502 11:11 ShadowBot MTDiscord: Error: That URL appears to have no HTML title within the first 4KB. 11:28 MTDiscord Thoughts on #10503 ? 11:28 ShadowBot MTDiscord: Error: That URL appears to have no HTML title within the first 4KB. 11:57 pgimeno looks like ShadowBot needs fixes 12:04 pgimeno :https://github.com/minetest/minetest/issues/10503 -- Shader uniform API 12:04 pgimeno #10503 12:04 ShadowBot pgimeno: Error: That URL appears to have no HTML title within the first 4KB. 12:14 sfan5 @appguru I know this puts the feature in the backlog, but I think dealing with shaders and rendering would be better left to CSM. 12:14 sfan5 With that you'd avoid network latency and have more flexibility 12:57 MTDiscord Hmmm 12:58 MTDiscord CSM should be able to (dynamically) add media 12:58 MTDiscord The shadermedia thing should still be implemented 12:58 MTDiscord CSM could control uniforms as well, but until we have proper SSCSM I would not surrender this to CSM exclusively 12:59 MTDiscord Either way, there needs to be discussion regarding a uniform API spec 12:59 sfan5 true 14:21 anon5[m] I think a shader api should be added if it can be done securely like in webgl 14:46 zughy[m] hey core devs, what's your opinion about IrrlichtBAW? It has pretty solid sponsors and it's been actually maintained https://forum.minetest.net/viewtopic.php?f=7&p=382014#p382014 14:47 sfan5 they removed all gui stuff which we need 14:49 rubenwardy We can include the irrlicht GUI stuff in our own codebase 14:49 zughy[m] "In my corner of the engine, GUIs, I want to abandon it". If v-rob succeeds, is it viable? 14:49 rubenwardy Bigger issue is that irrlichtbaw does not aim to keep compatibility, and so will probably take some effort to port to 14:50 rubenwardy Worth a go though 14:52 zughy[m] you mean between their own versions or with the original? 15:28 MTDiscord Didn't you want to try a different GUI lib? 15:29 rubenwardy compatibility with formspecs still needs to be kept 15:30 MTDiscord Ah 15:31 MTDiscord Or just leave formspecs where they are 15:31 MTDiscord And build something new 15:32 rubenwardy same thing 16:28 v-rob How can I disable LuaJIT from GitHub Actions Windows builds? 16:28 v-rob I tried `CMAKE_FLAGS: "-DENABLE_LUAJIT=0"`, but that didn't seem to work 16:29 MTDiscord I think there's also REQUIRE_LUAJIT 16:30 sfan5 remove the cmake args that point to luajit 16:35 Krock USE_LUAJIT=0 ? 16:36 Krock actually no. that's an internal variable 17:06 v-rob I settled for temporarily editing FindLua.cmake 17:07 sfan5 if you remove the cmake args and make sure there are no leftover build artifacts I guarantee you MT won't be picking luajit 17:08 v-rob It's not really important; I just needed a Windows artifact without LuaJIT because I can't compile MT on Windows 17:08 v-rob I can't get vcpkg to work 17:14 DS-minetest how can I use insecure environment in builtin? 17:15 v-rob All right! Non-JIT Lua drawing has no noticeable performance impact 17:16 MTDiscord How exactly is it not working v-rob? I haven't had any trouble with it 17:16 v-rob What not working? 17:17 MTDiscord vcpkg 17:17 v-rob I've installed it three separate times. Each time, it failed sometime during the build process, no matter what package I try. 17:18 MTDiscord Weird 17:19 v-rob Usually with some error message about something being missing or not being a system library 17:19 v-rob Searching online has yielded nothing 17:19 v-rob Anyway, I believe I have done enough testing to be confident that an all Lua-side GUI is feasible 17:19 v-rob Quite possibly even for hypertext 17:27 zughy[m] I know you can't see it from there, but I've added a heart reaction to the Lua-side GUI message 17:42 DS-minetest the warnings in mtg are super annoying 18:02 pgimeno DS-minetest: I don't think you can. I think that builtin should boot in an insecure environment and should switch on security itself before mods are loaded. 18:04 DS-minetest pgimeno: security seems to be switched on already for builtin. I was able to get insecure environment by adding "*builtin*" to secure.trusted mods 18:05 DS-minetest (and I used loadfile(filename)(insecure_env) for passing it to other files) 18:05 pgimeno yes, that's why I say it should be the other way around, it should be allowed insecure access from the start 18:05 pgimeno I didn't know you could add *builtin*, that's good to know 18:38 zughy[m] maan, I'm refactoring l_object.cpp and it's so... intense sometimes: https://github.com/minetest/minetest/blob/master/src/script/lua_api/l_object.cpp#L136 18:39 zughy[m] especially because it's been there for 8 years and I'm like "wait wtf" ahah 18:39 v-rob Gee, those comments go waaay too in depth. Perhaps they should be toned down a bit. How about just `//`? 18:41 MTDiscord honestly most "do it" comments should be removed 18:47 zughy[m] I've been told to remove them completely 18:48 zughy[m] it feels like Shia LaBeouf is yelling at the code 18:51 zughy[m] also, can I put some ternary operators here and there? Like https://github.com/minetest/minetest/blob/master/src/script/lua_api/l_object.cpp#L169 18:56 Krock the line would need breaking anyway, so ternary doesn't bring a benefit 18:57 rubenwardy 3 lines rather than 4 19:04 zughy[m] also, and then I'm done bothering: some functions go on a new line when they can't find a sao (L168), some others don't (L149). Do you have a preference about that? 19:05 v-rob Always, always on a new line 19:05 v-rob If statements should never have it on the same line 19:05 v-rob The code guidelines are very clear about that :) 19:06 zughy[m] nvm, I've just seen the guidelines 19:20 v-rob What would it take to get TouchInput on non-Android Minetest? 19:28 rubenwardy replacing #ifs with ifs 19:28 rubenwardy you'll probably also want to only enable the touchscreen on non-android if it is used 19:28 v-rob I mean specifically SEvent::STouchInput 19:29 rubenwardy oh right 19:29 rubenwardy do you have a touchscreen? 19:29 v-rob Yes 19:39 zughy[m] so uhm... this backward compatibility is 7 year old and I can't seem to find anything on the lua_api.txt. Is it rot code? https://github.com/minetest/minetest/blame/f43d1cfa81aa496174af6cdfa648dab9dd17288c/src/script/lua_api/l_object.cpp#L411 19:55 v-rob Probably is. Anything from 2013 is probably completely defunct. But I'm no expert 19:57 Krock minetest.env: still exists, thus be better careful 19:58 v-rob True 20:52 nore #10451 should be ready for review, anyone? 20:52 pgimeno :https://github.com/minetest/minetest/pull/10451 -- Client-side translations: gettext support by Ekdohibs 20:52 ShadowBot nore: Error: That URL appears to have no HTML title within the first 4KB. 21:05 pgimeno frigging crap, GitHub now is adding almost 6K of crap before the 21:06 DS-minetest I've tried using luajit's ffi for core.get_content_id, but somehow it's slower. see https://github.com/Desour/minetest/commit/aa275efff43a2bbe6bcf78fa8aa4f9e97cfa4934 21:07 DS-minetest maybe there's something that I did completely wrong 21:07 sfan5 you could replace get_content_id with a lua table lookup if you cache it 21:07 sfan5 surely that'd be fastest 21:09 DS-minetest yes, the main goal wasn't to speed up core.get_content_id. it is just the function I've chosen to try it out 21:14 pgimeno DS-minetest: do you have the benchmarks? 21:14 pgimeno oh hmm 21:14 pgimeno a tail call 21:15 pgimeno try: local result = ... 21:15 pgimeno return result 21:15 DS-minetest ffi: time taken: 2249.431 ms no ffi: time taken: 1053.407 ms (benchmark code is in code) 21:15 DS-minetest I've already tried removing tail calls, but it didn't help 21:17 pgimeno I didn't even know you could write functions in cdef's 21:17 pgimeno by the way, I suggest using rawget from insecure_env, not that it should affect much 21:18 DS-minetest yeah, it's nice how luajit allows you to write c code in lua 21:18 DS-minetest huh, is _G's rawget different? 21:19 pgimeno I wouldn't take the risk 21:19 pgimeno it sounds more secure, in case an untrusted mod modifies rawget 21:20 pgimeno not sure that can be done 21:20 DS-minetest :O oh, right 21:20 pgimeno it would be interesting to get a trace, to see where it's failing 21:21 DS-minetest how can I do this? 21:21 pgimeno I only know how to get one with the command line, sorry :( 21:22 pgimeno let's google 21:26 DS-minetest how would you do it in command line? 21:30 pgimeno luajit -j dump 21:32 pgimeno google is failing me 21:33 DS-minetest https://luajit.org/ext_jit.html says, jit.util.* is used by -jdump 21:33 DS-minetest documentation is in luajit/src/jit/dump.lua 21:34 pgimeno yes, that's the source itself 21:34 pgimeno it's a module written in lua and loaded by the interpreter when given that flag 21:35 pgimeno ohh 21:35 pgimeno require('jit.dump').on() 21:36 pgimeno I guess require('jit.dump').off() at the end too 21:38 DS-minetest hm, where did you find this? 21:38 pgimeno from the stuff the module returns, and then testing 21:39 pgimeno why? 21:39 pgimeno is it not working for you? 21:39 DS-minetest didn't try yet. just wanted to know where it came from 21:53 DS-minetest nice, fixed it to 584.624 ms 21:54 pgimeno ooooh 21:54 pgimeno how? 21:55 pgimeno did you find any NYI? 21:56 DS-minetest yes, it always said bad argument type 21:56 DS-minetest made a commit 21:58 pgimeno I see, great! 21:59 DS-minetest thanks for your help! :D 21:59 pgimeno if the API base is essentially constant during the whole run, that's good 22:00 pgimeno my pleasure! 22:00 DS-minetest actually, I don't know if the API base is constant 22:00 pgimeno but if not, it might be better to typecast the return value of the registry 22:00 pgimeno ffi.cast is your friend :) 22:01 DS-minetest mhm, that might work 22:01 pgimeno but it's worth checking if it's constant, because avoiding a parameter would even be better 22:03 pgimeno (i.e. just like you're doing now) 22:04 pgimeno marginally off topic, I'm reading a fascinating article about LJ internals: https://blog.cloudflare.com/luajit-hacking-getting-next-out-of-the-nyi-list/ 22:05 DS-minetest heh, I've seen this as a websearch result, but didn't click 22:06 pgimeno lots of insights into how it works and how to optimize even better 22:06 pgimeno things like, having random types in an array when you iterate it, aborts traces 22:19 pgimeno and as you've discovered, having FFI calls in interpreted code is actually counter-productive 22:20 DS-minetest maybe it's the type checking that takes so long 22:21 DS-minetest ffi.cast also seems to stop traces btw., so it should be called seldomely 22:21 pgimeno yes 22:22 DS-minetest is there something easy I can use to stop traces on purpose? 22:22 pgimeno what's the exact type, by the way? 22:22 pgimeno um, any NYI function call e.g. io.write() 22:22 pgimeno http://wiki.luajit.org/NYI 22:22 DS-minetest ScriptApiBase * 22:23 pgimeno I mean the Lua type. Is it lightuserdata? userdata? 22:23 pgimeno wait, io.write is implemented :D 22:25 pgimeno collectgarbage('count') should be harmless and avoids traces 22:25 pgimeno er, stops* traces 22:26 DS-minetest type() said, it's "userdata", idk how to check whether it's lightuserdata (I don't even know what it is) 22:27 DS-minetest I've used unpack({}) in the benchmark loop to avoid traces, no-ffi: 1699.849 ms, ffi: 1360.691 ms 22:28 pgimeno type says it, if it were lightuserdata it would have said so, and thanks 22:28 pgimeno cool, it still beats it 22:29 pgimeno but {} is initializing an object on every iteration, maybe try with a separate variable 22:29 DS-minetest will do 22:30 pgimeno lightuserdata is a 48-bit pointer IIRC 22:30 pgimeno I think it's deprecated 22:31 DS-minetest ffi: 940.393 ms, no ffi: 1246.234 ms 22:33 pgimeno ok, that shows the gap a bit better. It's cool that FFI still beats it. I guess the problem was the cast. 22:33 pgimeno Can you try with a void * and passing the object, to see if that breaks the trace too? 22:33 DS-minetest oh, I've checked again, now it says it's "cdata" 22:33 pgimeno cdata is a luajit type 22:34 pgimeno that must be the already cast one 22:34 DS-minetest I've tried void *, but it also breaks traces 22:34 DS-minetest yep, cdata is the cast one 22:34 pgimeno oh I see 22:35 pgimeno sorry, cdata is a FFI type (specifically) 22:38 pgimeno such a shame... userdata should be compatible with a C pointer, at least with void* pointer 22:39 DS-minetest according to a comment in c_internal.h, lightuserdata is just 48 bit iff it's aarch64 and luajit 22:39 DS-minetest I guess the type checks are to avoid segfaults by lua code 22:39 DS-minetest or maybe not... 22:40 pgimeno in https://lua-l.lua.narkive.com/gystrKVo/luajit-2-ffi-casting-force-hotpath#post28 Mike Pall says: "The FFI treats userdata like a 'void *' pointing to the payload." 22:40 pgimeno I'll test 22:42 DS-minetest (and only if the lightuserdata is just 48 bits, minetest uses userdata, otherwise lightuserdata) https://github.com/minetest/minetest/blob/09f9e465e760cb8fd791222405a9e5e68a676ba0/src/script/cpp_api/s_base.cpp#L92 22:46 pgimeno oh okay 23:00 pgimeno hm, I'm trying a loop that feeds userdata to a function that requires a void *, and it doesn't break the trace 23:01 pgimeno oh, lightuserdata does break the trace though 23:04 pgimeno and I was wrong, it isn't distinguishable with a type() 23:13 pgimeno it's preposterous, it takes 0.17 seconds when compiled and 10.6 seconds when interpreted 23:13 pgimeno that must be the cast alone 23:15 DS-minetest http://wiki.luajit.org/NYI#libraries_ffi-library doesn't state anything about lightuserdata 23:32 DS-minetest aha! https://luajit.org/ext_ffi_semantics.html says it at "Current Status": "not compiled[...]:[...]Conversions from lightuserdata to void *." 23:33 pgimeno ohh I see 23:34 DS-minetest also: "Table initializers.", so eg. get_node(pos, node) should rather be wrapped with a get_node_raw(x, y, z, node), or construct for C lua vectors with x,y,z 23:37 pgimeno yeah, I often use a reusable table and do: t.x = x_value; t.y = y_value; t.z = z_value; get_node(t, node) 23:37 pgimeno it is longer to write and cripples the code a bit, but I do it for speed 23:38 DS-minetest huh, so is it faster than get_node(vector.new(...)) ? 23:39 pgimeno it should, if it gets a chance to be compiled 23:40 pgimeno this function could work: function setv(x, y, z, temp_table) temp_table.x = x; temp_table.y = y; temp_table.z = z; return temp_table; end 23:40 pgimeno you have a temporary object ready, temp, and do: get_node(setv(x, y, z, temp), node) 23:41 pgimeno anyway, get_node itself breaks the trace, so there isn't much gain anyway 23:42 DS-minetest hm, throw-away vectors are actually generated in big numbers if one does things like vector.add(vector.multiply(a, 2), b) 23:44 pgimeno yeah, the API is not great for FFI