Minetest logo

IRC log for #minetest-dev, 2022-02-19

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

All times shown according to UTC.

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

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