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? |