Time |
Nick |
Message |
00:00 |
erlehmann |
i should have probably read the commit messages before voicing that suspicion |
00:02 |
|
beanzilla joined #minetest-dev |
00:07 |
erlehmann |
just for future reference, you do not always control who else makes a texture and conveniently leaves some raw bitmaps lying around. in fact, almost all of the mcl_maps code i have written will deal with textures where this assumption is false. |
00:07 |
|
YuGiOhJCJ joined #minetest-dev |
00:09 |
erlehmann |
and even if you had the raw bitmaps lying around, it's more code and uses more storage and … i really don't see an upside unless editing operations are *rare*. in which case you can use texture modifiers. |
00:12 |
|
Alias2 joined #minetest-dev |
00:20 |
|
v-rob joined #minetest-dev |
00:43 |
|
v-rob joined #minetest-dev |
00:46 |
wsor |
hey v-rob, when you have a chance could you rebase https://github.com/minetest/minetest/pull/10265 ? |
01:46 |
|
behalebabo joined #minetest-dev |
01:58 |
|
tekakutli joined #minetest-dev |
05:00 |
|
MTDiscord joined #minetest-dev |
06:10 |
|
tekakutli joined #minetest-dev |
06:46 |
|
calcul0n joined #minetest-dev |
07:31 |
|
tekakutli joined #minetest-dev |
08:00 |
|
erlehmann joined #minetest-dev |
08:01 |
|
proller joined #minetest-dev |
08:02 |
proller |
https://github.com/minetest/minetest/pull/11843 |
08:03 |
proller |
https://github.com/minetest/minetest/pull/11910 |
08:05 |
proller |
2.3 months is enough to merge? |
08:25 |
erlehmann |
proller what is your upgrade plan anyway? |
08:26 |
erlehmann |
like, assume a server on 5.5, how to enlarge map? |
08:28 |
erlehmann |
proller, you should know that people are often wrong about reserved identifiers, see “what we think we reserve” page 3 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2409.pdf |
08:28 |
erlehmann |
> In effect, these identifiers are reserved for all uses in C regardless of what header files (if any) are included |
08:28 |
erlehmann |
> Identifiers starting with uint or int and ending with _t, or UINT or INT and ending with _MAX, _MIN, or _C |
08:42 |
proller |
erlehmann, just compile with USE_POS32=1 and run, but clients without this enabled options cant connect to your server |
08:42 |
erlehmann |
proller you can fix that |
08:42 |
erlehmann |
and arguably, shoud |
08:42 |
erlehmann |
should |
08:43 |
proller |
erlehmann, new type names can be changed to any other in 5 minutes |
08:43 |
proller |
erlehmann, not in this pr |
08:43 |
erlehmann |
i was just pointing out that the type name thing is not POSIX thing, but rather C or C++ thing in general |
08:43 |
erlehmann |
and many people do not know about it |
08:44 |
erlehmann |
for example, i believe you can not make a type starting with letter E |
08:44 |
erlehmann |
EAGAIN hehe |
08:45 |
proller |
you can name types as you want if they not match already existed standard types |
08:45 |
erlehmann |
proller i do not understand why you could not keep network protocol compatibility for old clients. you could have old position in the packet for old client and not load nodes past old mapgen limit. |
08:46 |
erlehmann |
then tell people haha world is bigger |
08:46 |
erlehmann |
proller other question what happens with stuff that people have built out of bounds? it just becomes visible, right? |
08:46 |
proller |
because network protocol is streamed and uses fixed number of bits for coords, it vas 16*3 and now it 32*3 |
08:47 |
erlehmann |
i think you misunderstand me. keep the old bits. add some new bits somewhere else. |
08:48 |
erlehmann |
your idea of changing field size also breaks *every* software dealing with coordinates in network packets? |
08:48 |
erlehmann |
think of multiserver, mt-go library, the wireshark dissector … |
08:48 |
proller |
new client-server should use different serialization for old clients |
08:48 |
proller |
erlehmann, yes, breaks |
08:48 |
erlehmann |
it should not! |
08:49 |
erlehmann |
i mean, you can do this in a way that it breaks in a way that is more reasonable |
08:50 |
proller |
easiest way to send new big numbers at end of packets as new fields, but it requre rework all packets and add lot of if (version)... code |
08:50 |
proller |
it subject fot future prs |
08:50 |
erlehmann |
just changing the size of a struct in a network field is – to my knowledge – a big no no in terms reliable engineering |
08:50 |
erlehmann |
yes you have to change version code anyway |
08:51 |
erlehmann |
because this is new network protocol |
08:51 |
erlehmann |
proller have you talked to himbeerserver and anon55555 about it and what they would like to see? |
08:52 |
proller |
no |
08:52 |
erlehmann |
i mean they have written the most popular server proxies (i.e. they have parsing code for minetest network protocol the PR could break) |
08:52 |
erlehmann |
it is probably a good idea to talk to them just because they might give you ideas too |
08:54 |
erlehmann |
proller what is your opinion on the work of himbeerserver anyway? i find it always interesting how people who work on similar things have different approaches. |
08:54 |
proller |
this pr is just for rename types |
08:55 |
erlehmann |
i know you are doing it in stages |
08:55 |
erlehmann |
i think that is good btw |
08:55 |
erlehmann |
taking as small steps as is feasible, not biting off too much |
08:55 |
proller |
and it already have no move 2+ months |
08:55 |
erlehmann |
hahaha have you seen some simpler changes? |
08:55 |
erlehmann |
it takes ages to get something complex approved in any project sorry :/ |
08:55 |
erlehmann |
look at the stuff that wuzzy made |
08:55 |
erlehmann |
it is a shame :( |
08:56 |
proller |
so for talking backward compatibility code we should wait... years? |
08:56 |
erlehmann |
no, not. talk now. |
08:58 |
erlehmann |
proller i believe the fundamental problem is that ultimately people like appgurueu who engage with your code can not give meaningful approval. i have largely stopped reviewing stuff and looking for bugs for that reason after i realized my opinion does not really count if i am not a coredev. |
08:59 |
erlehmann |
you have to get approval from coredevs |
09:00 |
erlehmann |
how to do? i know only repeatedly asking people. |
09:01 |
proller |
or fork 8) |
09:01 |
erlehmann |
you are not the first person to say this ^^ |
09:02 |
erlehmann |
the problem is keeping critical mass. you either need to have a few very dedicated people or it becomes the same. |
09:02 |
erlehmann |
by the way i believe cleaning up types is a good idea, regardless of if you change map size later. |
09:44 |
|
Fixer joined #minetest-dev |
10:19 |
MTDiscord |
<luatic> proller: I'm afraid you won't get a PR merged that breaks multiple things and then just say "fixing this is up to future PRs". |
10:21 |
erlehmann |
haha that too |
10:21 |
erlehmann |
but |
10:21 |
erlehmann |
does the typedef thing break anything? |
10:23 |
ROllerozxa |
Hmm, what would it take for Minetest sound functionality to be more modular? Like, right now it is pretty much hardcoded to only use Ogg Vorbis. The Lua API SimpleSoundSpec also assumes all sounds are Ogg Vorbis sounds with the .ogg file extension, requiring you to omit the file extension of any sounds you want to use. |
10:26 |
erlehmann |
ROllerozxa you could probably easily extend it to support opus, as that also uses the ogg container. but i assume this is about the tracker music support, right? |
10:36 |
ROllerozxa |
Heh, yeah. Either way if either Opus, MIDI or tracker music support were to be added, the code would still need to be refactored to support more sound formats. Would be nice if it was made to be similar to how Irrlicht's texture loaders are implemented. |
10:43 |
erlehmann |
i think opus does not make sense really. it's more efficient, but then you have mods that are not backwards compatible or have to encode everything twice. |
10:43 |
erlehmann |
vorbis is really good enough |
10:43 |
erlehmann |
source: i have written podcast publishing software, encoding stuff multiple times is a chore |
10:44 |
erlehmann |
midi or tracker music on the other hand would be cool |
10:44 |
erlehmann |
and give a completely different feel |
10:44 |
erlehmann |
additionally, stuff like bytebeat does not compress very well |
10:52 |
sfan5 |
rubenwardy: do you have any idea how the 64-bit APKs ever worked correctly https://github.com/minetest/minetest/issues/12081#issuecomment-1045990017 |
10:53 |
sfan5 |
the context is https://github.com/minetest/minetest/pull/9614 which is a workaround that only applies correctly via CMake |
10:57 |
ROllerozxa |
The arm64 android APKs are quite honestly broken and shouldn't be made available, it only confuses people since most will assume 64-bit to be better than 32-bit and go for it if their device is 64-bit. |
10:58 |
sfan5 |
they are not advertised on the website or forums |
10:58 |
sfan5 |
the play store forces us to provide 64-bit builds |
10:59 |
ROllerozxa |
...oh |
11:03 |
erlehmann |
i can test aarch64 as soon as my reform is back, if there is a general luajit issue (there seems to be?) |
11:04 |
erlehmann |
would using builtin lua change anything? |
11:04 |
MTDiscord |
<luatic> It would probably ruin performance |
11:04 |
erlehmann |
please elaborate |
11:04 |
ROllerozxa |
Minetest Android always uses the LuaJIT library it downloads |
11:05 |
MTDiscord |
<luatic> But yes, it should fix LuaJIT related bugs. PUC Lua is presumably a lot more platform-independent than LuaJIT. |
11:05 |
MTDiscord |
<luatic> erlehmann: LuaJIT usually provides a ~5x speedup from my experience. Android users in modded singleplayer absolutely need this. |
11:05 |
MTDiscord |
<luatic> (IDK if the speedup is as large on ARM though) |
11:06 |
ROllerozxa |
Although it certainly wouldn't hurt to write a PUC Lua dependency script for Android, if only for testing |
11:06 |
erlehmann |
oh, i never had such experiences |
11:06 |
erlehmann |
like, luajit is a bit better, but not that much |
11:06 |
erlehmann |
may be different on x86 |
11:06 |
MTDiscord |
<luatic> LuaJIT is much better. |
11:06 |
erlehmann |
or i have the “wrong” workload to test it |
11:06 |
erlehmann |
i believe you, i just wonder why i did not notice |
11:07 |
erlehmann |
do you have some test mod that makes it obvious? |
11:07 |
erlehmann |
or some indication which operations are affected? |
11:08 |
MTDiscord |
<luatic> https://www.lua.org/gems/sample.pdf |
11:09 |
MTDiscord |
<luatic> I have observed this on a MT-unrelated algo repo and on a couple MT benchmarks I ran |
11:10 |
erlehmann |
yeah pls give the benchmarks |
11:10 |
erlehmann |
i'll read the pdf |
11:11 |
erlehmann |
wait i know this |
11:11 |
MTDiscord |
<luatic> The last page is where it mentions LuaJIT and the 5x speedup |
11:11 |
erlehmann |
> The drawbacks are that it runs only on x86 architectures and that you need a non-standard Lua interpreter (LuaJIT) to run your programs. |
11:11 |
erlehmann |
ah yes, this seems trustworthy |
11:11 |
erlehmann |
so then we should not use luajit on aarch64 at all |
11:11 |
erlehmann |
since it runs only on x86 architecture |
11:11 |
erlehmann |
… right? ;) |
11:17 |
erlehmann |
what change in the build process between minetest 5.4.1 and minetest 5.5.0 could be responsible for the latter pushing the system load to 4 on a 2 core system, making my computer smell weird and overheat when i build? |
11:18 |
erlehmann |
could be something else hmm |
11:20 |
erlehmann |
oh, firefox :( |
11:20 |
ROllerozxa |
browsers suck :( |
11:21 |
erlehmann |
well, firefox was good for a long time, but recently it often crashes and uses CPU while doing nothing (like chrome) |
11:22 |
ROllerozxa |
Anyways I'm writing an Android dependency build script for Lua but I can't get it to create the static library (liblua.a) |
11:22 |
ROllerozxa |
(by Lua I mean PUC Lua) |
11:25 |
ROllerozxa |
never mind, it was hiding in src/ along with object files, didn't get copied over for some reason |
11:26 |
erlehmann |
i really wonder if luajit on aarch64 is giving that speedup |
11:36 |
|
HuguesRoss joined #minetest-dev |
13:28 |
ROllerozxa |
ok so I managed to compile Minetest Android with PUC Lua... it crashes instantly. |
13:28 |
ROllerozxa |
how lovely |
13:30 |
|
jingkaimori joined #minetest-dev |
13:34 |
ROllerozxa |
oh never mind, arm64-v8a crashes with PUC Lua but not armeabi-v7a... that's ironic |
13:36 |
sfan5 |
I guarantee you you just compiled it wrong |
13:36 |
erlehmann |
yeah can you please show how you did it |
13:37 |
|
appguru joined #minetest-dev |
13:38 |
sfan5 |
I didn't do anything but I know that it is possible |
13:38 |
jingkaimori |
for the replacement of formspec, is it necessary for modders to layout elements manually by specifying position? or there must be a default layout |
13:38 |
erlehmann |
ROllerozxa so how did *you* do it? |
13:38 |
|
Baytuch joined #minetest-dev |
13:39 |
erlehmann |
where's the build script lewobski |
13:41 |
ROllerozxa |
Okay so at first I tried to do it by writing an Android dependency build script but I gave up on that idea and just edited the Android makefiles to point to the built-in lua source directory and commented out LuaJIT. |
13:41 |
ROllerozxa |
https://github.com/rollerozxa/minetest/commit/b4fa87dcdf157f58b17260acf55cf182810bdcf1 |
13:43 |
sfan5 |
that sounds close to correct |
13:43 |
sfan5 |
so whats the error when starting MT? |
13:47 |
ROllerozxa |
here's the stacktrace: https://mister-muffin.de/p/p1i7.txt |
13:49 |
erlehmann |
> Build fingerprint: 'Nokia/DoctorDoom_00EEA/DRD_sprout:11/RKQ1.210303.002/00WW_2_19B:user/release-keys' |
13:49 |
erlehmann |
hehe |
13:50 |
ROllerozxa |
...eh? |
13:51 |
MTDiscord |
<CartridgeZine> ….eh? |
13:52 |
erlehmann |
02-19 14:29:29.392 3683 3683 F DEBUG : Abort message: 'FORTIFY: strchr: prevented read past end of buffer' |
13:52 |
erlehmann |
i guess this is legit and you could try to figure out what illegal thing strchr() wanted to do to that poor buffer |
13:53 |
sfan5 |
the most interesting part of the stacktrace (frames 3 to 6) are unfortunately missing symbolsd |
13:53 |
sfan5 |
-d |
13:53 |
erlehmann |
yeah, how come? |
13:53 |
erlehmann |
would a recompile with -g or so fix it? |
13:54 |
sfan5 |
possibly |
13:54 |
ROllerozxa |
android debug builds are already done with -g right? |
13:54 |
erlehmann |
well no idea why we have *some* symbols but not others |
13:57 |
erlehmann |
ROllerozxa can you step through this using a debugger btw? |
13:59 |
jingkaimori |
for the replacement of formspec, is it necessary for modders to layout |
13:59 |
jingkaimori |
elements manually by specifying position? or there must be a default |
13:59 |
jingkaimori |
layout |
14:04 |
ROllerozxa |
erlehmann: I don't know, am I able to? Only thing I know of is running adb logcat to get debug logs and whatnot |
14:07 |
erlehmann |
well i do not know about debugger on android sadly |
14:08 |
ROllerozxa |
also I am indeed compiling with -g, super weird how some symbols are still missing |
14:12 |
sfan5 |
you can also try addr2line to manually resolve an address to the symbol |
14:23 |
ROllerozxa |
oh alright. addr2line says that #03-#06 are lua_yield... would that give any clues? |
14:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/03 -- Furnace segfault |
14:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/06 -- Apples on the trees can not be eaten |
15:03 |
|
Taoki joined #minetest-dev |
15:58 |
|
appguru joined #minetest-dev |
16:08 |
|
erlehmann joined #minetest-dev |
16:37 |
|
erlehmann joined #minetest-dev |
16:44 |
MTDiscord |
<MisterE> If colored shadows are possible, is colored sunlight possible? For example, the sunlight could take on an orange tint at sunset |
16:54 |
sfan5 |
sure |
17:40 |
|
erlehmann joined #minetest-dev |
17:59 |
MTDiscord |
<Benrob0329> I mean, sunlight is already colored, but only for day vs night |
18:01 |
MTDiscord |
<Benrob0329> (as well as artificial light vs sunlight) |
18:11 |
rubenwardy |
!tell sfan5 didn't the Lua error handling change in 5.5? I remember a PR on that |
18:11 |
ShadowBot |
rubenwardy: OK. |
18:11 |
sfan5 |
. |
18:11 |
sfan5 |
what do you mean |
18:12 |
rubenwardy |
huh |
18:13 |
rubenwardy |
why can't I see you in the user list |
18:13 |
rubenwardy |
client's borked |
18:13 |
|
rubenwardy joined #minetest-dev |
18:14 |
rubenwardy |
wonder how long the user list was outdated for |
18:18 |
rubenwardy |
the one I was thinking of wasn't merged |
18:19 |
rubenwardy |
another possibility is that we've updated the dependencies since |
18:20 |
rubenwardy |
so the code/compile settings for LuaJIT may have changed |
18:48 |
|
lhofhansl joined #minetest-dev |
19:33 |
|
proller joined #minetest-dev |
19:49 |
sfan5 |
possible |
19:50 |
|
erlehmann joined #minetest-dev |
20:11 |
|
beanzilla joined #minetest-dev |
20:39 |
|
lhofhansl joined #minetest-dev |
21:08 |
rubenwardy |
Looks like GitHub actions is no longer making artifacts for Windows builds |
21:09 |
rubenwardy |
oh ffs, it would be nice if people could fix stuff rather than just disabling it |
21:10 |
erlehmann |
is it githubs fault or did some minetest dev disable it? |
21:11 |
rubenwardy |
mt de |
21:12 |
rubenwardy |
I imagine they intended to renable them after a while, but there's no issue to track it |
21:13 |
rubenwardy |
https://github.com/minetest/minetest/issues/12087 |
21:13 |
MTDiscord |
<Jonathon> its been disabled for a while now |
21:13 |
rubenwardy |
!title |
21:13 |
ShadowBot |
Fix Visual Studio/MSVC CI builds, and renable them · Issue #12087 · minetest/minetest · GitHub |
21:18 |
MTDiscord |
<LandarVargan> Also note #11176, which I need to fix at some point |
21:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/11176 -- Fix Windows Visual Studio actions by LoneWolfHT |
21:20 |
rubenwardy |
oh right |
21:20 |
rubenwardy |
I'll close #12088 then |
21:20 |
ShadowBot |
https://github.com/minetest/minetest/issues/12088 -- Fix MSVC build on GitHub Actions by rubenwardy |
21:24 |
rubenwardy |
LandarVargan: please may you rebase your branch |
21:24 |
rubenwardy |
or I can do it |
21:29 |
MTDiscord |
<LandarVargan> Feel free to do whatever you want with it, I need to pop out to eat |
21:36 |
|
v-rob joined #minetest-dev |
21:48 |
sfan5 |
rubenwardy: gitlab has windows artifacts btw |
21:48 |
sfan5 |
on that note the win32 is broken but I haven't had time to investigate yet |
21:49 |
rubenwardy |
Isn't that only on the master branch? |
21:49 |
sfan5 |
it is |
21:49 |
rubenwardy |
Well, only on official branches. Not PRs |
22:27 |
|
lhofhansl joined #minetest-dev |