Minetest logo

IRC log for #minetest-dev, 2021-11-15

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

All times shown according to UTC.

Time Nick Message
00:16 MTDiscord <josiah_wi> Why bisect first thing when I have an error message I can look at?
00:16 MTDiscord <josiah_wi> Do we need to know who introduced it?
00:17 erlehmann josiah_wi it is a good idea to know if it was introduced deliberately for some reason or accidentally
00:18 erlehmann there may be a good reason to break compatibility
00:18 erlehmann or it may just be an accidenta
00:18 erlehmann l breakage
00:18 MTDiscord <josiah_wi> git blame bud
00:18 MTDiscord <josiah_wi> tells last commit edit
00:18 erlehmann ah
00:19 MTDiscord <josiah_wi> My hunch rn is that it was a completely accidental type mismatch because there was no warning.
00:20 erlehmann ah
00:45 AliasAlreadyTake joined #minetest-dev
02:16 Extex joined #minetest-dev
02:19 Extex joined #minetest-dev
02:24 Extex joined #minetest-dev
02:36 Extex joined #minetest-dev
03:28 queria joined #minetest-dev
03:34 queria joined #minetest-dev
04:11 Alias joined #minetest-dev
05:00 MTDiscord joined #minetest-dev
06:59 rubenwardy joined #minetest-dev
06:59 Chompy joined #minetest-dev
06:59 beanzilla joined #minetest-dev
06:59 nrz joined #minetest-dev
07:04 Shara joined #minetest-dev
07:04 ShadowNinja joined #minetest-dev
07:04 Shara joined #minetest-dev
08:29 tekakutli joined #minetest-dev
08:44 olliy joined #minetest-dev
09:40 Flitzpiepe joined #minetest-dev
11:25 calcul0n__ joined #minetest-dev
11:33 tech_exorcist joined #minetest-dev
12:21 proller joined #minetest-dev
13:44 proller joined #minetest-dev
14:15 Alias joined #minetest-dev
14:22 proller joined #minetest-dev
15:13 tech_exorcist joined #minetest-dev
15:42 Fleckenstein joined #minetest-dev
15:54 Extex joined #minetest-dev
15:59 EliasFleckenstei joined #minetest-dev
16:00 Fleckenstein joined #minetest-dev
16:16 Extex joined #minetest-dev
16:22 Fixer joined #minetest-dev
16:39 appguru joined #minetest-dev
16:44 proller joined #minetest-dev
16:50 kilbith joined #minetest-dev
16:59 erlehmann joined #minetest-dev
17:20 appguru Why is it not possible to readd ephemeral dynamic media with the same name?
17:21 erlehmann appguru, what exactly are you trying to do?
17:22 appguru I'm trying to not fill up the client media cache
17:23 erlehmann with what exactly?
17:23 erlehmann i have yet to see a piece of code that legitimately spammed the client media cache, but i am curious
17:23 appguru It's for a 3d skin painting mod. I'm trying to resend the painted skin; the old file should be dropped. As "dropping" of media files isn't possible (I have opened a feature request), I'm trying to override them instead. But this would force me to not use ephemeral, which would result in the client file cache being filled up.
17:23 erlehmann also this belongs into #minetest ig if you talk about it
17:24 appguru No, this is a limitation of the Minetest engine. I'm planning a PR.
17:24 sfan5 dropping a media file is a subset of overriding it
17:24 sfan5 if the former is not possible then the latter isn't
17:24 appguru Huh?
17:24 erlehmann for one i agree with sfan5
17:24 erlehmann for once
17:24 appguru But isn't overriding possible for non-ephemeral files with a different path?
17:25 appguru That's what I'm asking: Why this distinction between ephemeral and non-ephemeral?
17:25 sfan5 you can do that on the server under certain circumstances, the docs don't spell it out exactly because this is not intended
17:26 sfan5 but a client can/will only receive a media with a given name once
17:26 appguru I was hoping it would override it?
17:26 sfan5 it won't
17:27 appguru argh too bad
17:27 appguru back to media dropping I suppose...
17:27 erlehmann what's so bad about that?
17:28 erlehmann appguru what is the problem with dropping in your mental model
17:28 appguru it isn't implemented yet
17:29 erlehmann how big are your textures anyway?
17:29 erlehmann (asking bc i am a big user of cache)
17:29 appguru Arguably it would work well for quite some time
17:30 erlehmann depends. creating a few 100k per day or so is basically noise. creating a few 100k per minute would be conncernig.
17:30 sfan5 replacing a texture with an identically sized new one would be easy
17:30 appguru But I don't like the fact that (1) it won't work well for high res textures, even though my code could handle those just fine and (2) users of low spec devices might get a problem with this (I'm not quite sure how inefficient the cache is: are ephemeral media files stored in memory or in temporary files?)
17:30 sfan5 but this would be an unpredictable constrain for modders
17:32 erlehmann appguru, i am a user of a low-spec device (my home partition is 79G), never had issues with cache (as it never exceeded 1G even after months of play), do you want to show your mod?
17:32 sfan5 appguru: images are decoded and stored in memory
17:32 sfan5 so are sounds
17:32 appguru sfan5: ouch
17:32 sfan5 models are stored as-is in memory and parsed when needed
17:32 appguru I was hoping that wasn't the case, as it's quite memory inefficient
17:32 rubenwardy honestly, I wouldn't be against such a constraint as long as there were suitable errors if modders mess up
17:33 appguru Which constraint are you talking about? Why would such a feature be "constraining"?
17:34 erlehmann same size ig
17:34 appguru but why would you need the same size? to save a single pointer? to be able to memcpy without a hassle?
17:34 Extex joined #minetest-dev
17:37 sfan5 the idea is this: at one point some code will grab an ITexture and use it, now you want to replace it without having to somehow re-run the code that grabs the texture. in this situation replacing the pixel data is 100% safe, everything else requires more care
17:38 sfan5 +without needing to swap out the ITexture object itself
17:39 rubenwardy doesn't this break with texture modifiers?
17:40 appguru good question: how are texture modifiers expected to behave if one of the textures they use is swapped?
17:40 sfan5 that is another hairy part regardless of how the new texture data gets there
17:40 rubenwardy what is your idea for implementing general updating?
17:40 erlehmann what if texture modifier is this ugly hack that hecks made with the base64 png
17:40 sfan5 you might need a dependency graph so all relevant textures can be rebuilt
17:40 rubenwardy what about some sort of, TextureHandle class which essentially acts as a handle to a TextureManager, allowing for it to be swapped out / reference counted?
17:40 erlehmann (which btw is something that is NOT GOOD for generated textures)
17:40 rubenwardy hmm
17:40 appguru dependency graph? a simple map string -> texmod should do the job.
17:41 sfan5 a simple map that contains what
17:41 appguru mediafile -> list of texmods*
17:41 rubenwardy list of texmods being texture strings that use said media file, right
17:42 sfan5 rubenwardy: instead of trying to solve that "backwards" it'll be easier to properly implement triggering a texture reload
17:42 erlehmann since you are talking about memory management, i just want to mention that “-fsanitize=address” exists and can help you find and debug memory leaks. it makes the game dog slow though, so unlike “-fsanitize=undefined”, i suggest to not use it in production. maybe some of you did not know it.
17:42 sfan5 appguru: I guess that works, the order is irrelevant after all
17:42 appguru Now that we have IrrlichtMT, we can directly implement our desired behavior in ITexture?
17:43 sfan5 probably but see my answer to ruben
17:45 sfan5 there's another thing: Minetest currently does not delete any textures until you exit the game session
17:45 rubenwardy my idea there would be to make it easier to implement updating in most cases by storing direct references to textures sless
17:45 rubenwardy and also allow reference counting
17:45 sfan5 I guess because there is no sure way to tell when a texture is unused
17:45 sfan5 or well, there is refcounting
17:46 rubenwardy all root level textures should be kept indefinitely (= pure media files like default_dirt.png)
17:46 rubenwardy derived textures should be refcounted and also last use tracked
17:46 erlehmann minetest def leaks memory, but tbh it never seemed a problem for me on <2GB RAM. then again, i am rarely leaving mt open for more than 8 hours.
17:46 rubenwardy last use tracked is needed for GUI textures which don't maintain references between open/closings
17:46 erlehmann yeah so are the derived textures not the solution for appguru painting problems?
17:47 erlehmann assuming you mean derived, as in “someone slapped a modifier on it”
17:47 appguru I already use texture modifiers for small changes to the skins
17:48 erlehmann bc if that is the case, i could see a better version of hecktests PNG base64 thingy (basically) handle that case (something that is easier to work with from lua than a base64 encoded PNG)
17:48 erlehmann only for smaller textures ofc
17:50 erlehmann appguru again, pls show your mod
17:50 appguru literally 3d skin painting
17:53 erlehmann can't find it
17:53 erlehmann btw, is there a way to let devtest spawn all devtest nodes?
17:54 sfan5 yes
17:54 erlehmann how?
17:55 erlehmann my idea is to grab all the crashy media stuff and make nodes for dev test for it
17:55 erlehmann then if “spawn all the nodes” does not crash the game, minetest can handle it
17:57 erlehmann ah, it is test_place_nodes. thank you!
17:58 erlehmann uh, i didn't expect that to actually crash the game
17:58 erlehmann i might have found a use-after-free
18:02 erlehmann anyone of you aware of use-after-free triggerable by careful playing around with voxelmanips? i'll try to compile a newer version so i don't report a dupe.
18:35 erlehmann i have a question. in line 1386 of game.cpp, where it says “delete text” … should it say “delete[] text” instead?
18:37 sfan5 you wouldn't be asking if you didn't have a reason to
18:39 erlehmann true, but i do not know C++ well enough to be sure
18:39 erlehmann to be clear, i *suspect* it should be “delete[] text”
18:39 sfan5 ...because ASan told you so
18:40 erlehmann no, that was only the prompt to learn about it
18:40 erlehmann apparently, you can't o things like: char *p = new char[n]; delete p
18:40 erlehmann it is new to me
18:41 erlehmann that is why i am asking
18:42 sfan5 you indeed can't (by the standard)
18:54 proller joined #minetest-dev
18:58 fluxionary joined #minetest-dev
19:37 Menchers why is source code getting rebuilt when I just deleted bin/minetest? I wanted to just relink it  :/
19:37 Menchers did it throw the objects away
19:47 kilbith joined #minetest-dev
19:57 MTDiscord <josiah_wi> I am fairly certain you do not have to delete bin/minetest to make it link again.
19:58 MTDiscord <josiah_wi> Unless nothing changed, in which case why would you relink.
19:58 Extex joined #minetest-dev
20:13 kilbith leaving here a benchmark comparing local vs global function performance (with LuaJIT and Lua 5.1)
20:13 kilbith benchmark: https://gist.github.com/kilbith/ce1f9b09e090b5bf14dcae3f4e48c831
20:13 kilbith results: https://gist.github.com/kilbith/84e0cb019f20e32436f3a90861dbf891
20:13 kilbith conclusion: almost no difference
20:25 MTDiscord <luatic> kilbith: No. Your "x" table is not the global table "_G". It might be a bit slower if it was as _G contains more elements, slowing down the indexing if hashes collide.
20:26 kilbith do note that the hash table lookup is pretty big in `x`
20:27 kilbith look at line 5
20:30 kilbith well I've got better performance with _G.test() than x.test(), there's actually less entries in _G. so your comment is moot.
20:34 kilbith that's with _G: https://gist.github.com/kilbith/9758f7f956ac5802e59cd9f884ecfecc
20:34 kilbith and, again, the "local functions are faster" is just a myth
20:39 MTDiscord <luatic> That depends on how many entries you have in _G, which depends on environment
20:39 MTDiscord <luatic> I assume you are testing this under plain Lua?
20:39 kilbith sure
20:39 kilbith I agree
20:40 kilbith but the difference tends to be infinitesimal if not inexistent
20:41 MTDiscord <luatic> That depends
20:41 MTDiscord <luatic> Local functions provide more guarantees to the compiler
20:41 kilbith biggest benefit of localizing functions is syntactic
20:41 kilbith local functions are array indexed
20:42 MTDiscord <luatic> I am aware
20:42 MTDiscord <luatic> To be clear, I consider the overhead of indexing a function table to be acceptable in most cases too.
20:42 MTDiscord <luatic> I like using local for "private" functions
20:43 MTDiscord <luatic> As long as you don't pollute the global namespace with your functions, cleanly storing them in API tables, everything is fine
20:48 MTDiscord <luatic> Might want to have a look at https://gitspartv.github.io/LuaJIT-Benchmarks
20:53 kilbith there's always a compromise to find between ease of maintenance vs optimization
20:56 erlehmann sfan5 i was of the impression that data is a pointer to an array of wchar_t – is that wrong?
20:57 kilbith interesting to see that LuaJIT optimizes condition branching the same way that `foo and 1 or 2`
20:57 erlehmann sfan5, data → text
21:00 sfan5 erlehmann: can you link the line?
21:00 erlehmann yes
21:01 erlehmann looking for it
21:01 rubenwardy I usually don't bother making local copies of API functions
21:03 erlehmann sfan5 https://github.com/minetest/minetest/blob/master/src/client/game.cpp#LC1386
21:04 sfan5 it indeed is pointer to wchar_t, why the question?
21:05 erlehmann well i think array things need to be deconstructed with delete[]?
21:06 erlehmann i obviously do not understand this, so i ask
21:06 erlehmann (if i were sure about anything, i'd open an issue)
21:08 sfan5 the type system does not carry the needed information
21:08 proller joined #minetest-dev
21:09 sfan5 you'd look inside wgettext, find that it uses new[] and conclude that the counterpart must be delete[]
21:09 erlehmann yes
21:09 erlehmann but there is no delete, but delete[], so why?
21:09 erlehmann i mean
21:10 erlehmann there is no delete[], but delete
21:10 erlehmann sorry, very sleepy
21:10 sfan5 why what
21:10 sfan5 you found a bug, that's it
21:10 erlehmann ah!
21:10 erlehmann ok i was thinking it is not one
21:10 erlehmann and i have misunderstood something
21:11 erlehmann what is the consequence of this, it leaks part of the window title?
21:11 sfan5 it is not compliant to the C++ standard but it works anyway on all platforms we know of
21:12 sfan5 so no consequences
21:12 erlehmann uh, ok … why would it work though?
21:13 sfan5 operator delete() and operator delete[]() will be implemented identically
21:14 erlehmann uh, i need to read about this
21:14 erlehmann it sounds very strange
21:15 sfan5 https://en.cppreference.com/w/cpp/memory/new/operator_new
21:15 erlehmann thx
21:22 erlehmann uh, i have very little understanding of it, but it seems making stuff with new[] and getting rid of it with delete is basically calling the destructor on the first object and then freeing the pointer?
21:23 sfan5 it has nothing to do with objects or what's inside memory
21:23 sfan5 operator new() and operator delete() perform the same function as malloc and free
21:24 erlehmann i am more irritated about the “delete[] cleans up the entire thing” vs “delete only cleans up one thing” difference.
21:24 erlehmann ohhhhhhhhh
21:24 erlehmann i think i get it
21:25 sfan5 such difference does not exist
21:25 erlehmann oh?
21:25 sfan5 if you read the operator_delete page both just get a void pointer to memory to free
21:26 sfan5 just like operator new gets a number of bytes to allocate
21:27 sfan5 from this information they could not possibly try to do anything with objects possibly meant to be in the memory area
21:29 erlehmann one thing though: new[] has to put the number of array elements somewhere, while new points exactly to the memory given to you by malloc or whatever
21:29 sfan5 no
21:30 erlehmann i thought if the number of array elements would be stored at the beginning of the memory, how would it not be a few bytes difference (the width of the number of elements) then to call delete or delete[]?
21:30 sfan5 how would new[] know how many objects are in the array?
21:31 sfan5 btw if you have more questions we should probably move this to #minetest
21:31 erlehmann ok right
21:31 erlehmann lets do that
21:44 kilbith joined #minetest-dev
22:09 MTDiscord <Jonathon> can https://github.com/minetest/minetest/issues/11773 be closed?
22:19 YuGiOhJCJ joined #minetest-dev
22:24 MTDiscord <SX> first, where stickers can be ordered?

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