Time Nick Message 00:16 MTDiscord Why bisect first thing when I have an error message I can look at? 00:16 MTDiscord 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 git blame bud 00:18 MTDiscord tells last commit edit 00:18 erlehmann ah 00:19 MTDiscord My hunch rn is that it was a completely accidental type mismatch because there was no warning. 00:20 erlehmann ah 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: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) 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:57 MTDiscord I am fairly certain you do not have to delete bin/minetest to make it link again. 19:58 MTDiscord Unless nothing changed, in which case why would you relink. 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 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 That depends on how many entries you have in _G, which depends on environment 20:39 MTDiscord 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 That depends 20:41 MTDiscord 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 I am aware 20:42 MTDiscord To be clear, I consider the overhead of indexing a function table to be acceptable in most cases too. 20:42 MTDiscord I like using local for "private" functions 20:43 MTDiscord 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 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: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 22:09 MTDiscord can https://github.com/minetest/minetest/issues/11773 be closed? 22:24 MTDiscord first, where stickers can be ordered?