| 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 |
<appguru> 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 |
<appguru> yeah, just figured |
| 11:11 |
MTDiscord |
<appguru> #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 |
<appguru> 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 |
<appguru> Hmmm |
| 12:58 |
MTDiscord |
<appguru> CSM should be able to (dynamically) add media |
| 12:58 |
MTDiscord |
<appguru> The shadermedia thing should still be implemented |
| 12:58 |
MTDiscord |
<appguru> CSM could control uniforms as well, but until we have proper SSCSM I would not surrender this to CSM exclusively |
| 12:59 |
MTDiscord |
<appguru> 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&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 |
<Lone_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 |
<Lone_Wolf> Ah |
| 15:31 |
MTDiscord |
<Jordach> Or just leave formspecs where they are |
| 15:31 |
MTDiscord |
<Jordach> 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 |
<Lone_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 |
<Lone_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 |
<Lone_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 |
<Lone_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 |
<appguru> 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 |
