Minetest logo

IRC log for #minetest-dev, 2020-10-15

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
02:22 absurb joined #minetest-dev
04:34 fluxflux joined #minetest-dev
08:00 ShadowNinja joined #minetest-dev
09:54 proller joined #minetest-dev
10:04 proller joined #minetest-dev
10:10 Flitzpiepe joined #minetest-dev
10:21 calcul0n joined #minetest-dev
10:23 Flitzpiepe joined #minetest-dev
10:24 Flitzpiepe joined #minetest-dev
10:46 Beton joined #minetest-dev
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 <a​ppguru> 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 <a​ppguru> yeah, just figured
11:11 MTDiscord <a​ppguru> #10502
11:11 ShadowBot MTDiscord: Error: That URL appears to have no HTML title within the first 4KB.
11:15 Fixer joined #minetest-dev
11:28 MTDiscord <a​ppguru> 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
11:58 Flitzpiepe joined #minetest-dev
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:19 NetherEran joined #minetest-dev
12:57 MTDiscord <a​ppguru> Hmmm
12:58 MTDiscord <a​ppguru> CSM should be able to (dynamically) add media
12:58 MTDiscord <a​ppguru> The shadermedia thing should still be implemented
12:58 MTDiscord <a​ppguru> CSM could control uniforms as well, but until we have proper SSCSM I would not surrender this to CSM exclusively
12:59 MTDiscord <a​ppguru> Either way, there needs to be discussion regarding a uniform API spec
12:59 sfan5 true
13:58 NetherEran joined #minetest-dev
14:19 NetherEran joined #minetest-dev
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&amp;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 <L​one_Wolf> Didn't you want to try a different GUI lib?
15:29 rubenwardy compatibility with formspecs still needs to be kept
15:30 MTDiscord <L​one_Wolf> Ah
15:31 MTDiscord <J​ordach> Or just leave formspecs where they are
15:31 MTDiscord <J​ordach> And build something new
15:32 rubenwardy same thing
16:24 v-rob joined #minetest-dev
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 <L​one_Wolf> 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
16:42 Beton joined #minetest-dev
16:50 fluxflux joined #minetest-dev
17:02 absurb joined #minetest-dev
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:09 DS-minetest joined #minetest-dev
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 <L​one_Wolf> 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 <L​one_Wolf> 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 <L​one_Wolf> 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:29 GreenXenith joined #minetest-dev
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 <a​ppguru> 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:14 DS-minetest joined #minetest-dev
19:20 v-rob What would it take to get TouchInput on non-Android Minetest?
19:25 lisac joined #minetest-dev
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:39 homthack joined #minetest-dev
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:45 homthack64 joined #minetest-dev
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.
20:59 v-rob joined #minetest-dev
21:05 pgimeno frigging crap, GitHub now is adding almost 6K of crap before the <title>
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:47 proller joined #minetest-dev
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:23 proller joined #minetest-dev
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 Fixer joined #minetest-dev
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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext