| Time |
Nick |
Message |
| 00:22 |
|
Pexin joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 06:51 |
|
hlqkj joined #minetest-dev |
| 06:52 |
|
MisterE1230 joined #minetest-dev |
| 06:52 |
|
wsor4035 joined #minetest-dev |
| 06:52 |
|
thelounge656 joined #minetest-dev |
| 07:29 |
|
m42uko_ joined #minetest-dev |
| 10:35 |
|
dv^_^6 joined #minetest-dev |
| 10:59 |
|
wsor4035 joined #minetest-dev |
| 12:09 |
sfan5 |
planning to merge #14707 later today |
| 12:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/14707 -- Call malloc_trim() regularly to improve deallocation behavior by sfan5 |
| 13:13 |
MTDiscord |
<jordan4ibanez> I did the thing |
| 13:23 |
MTDiscord |
<jordan4ibanez> #14734 and let me know, etc |
| 13:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/14734 -- Add --terminal-silent flag to minetest by jordan4ibanez |
| 18:18 |
MTDiscord |
<siliconsniffer> sfan, I havn't replied again before you merged it, should I have reported back a second time or was it okay like this? |
| 18:19 |
MTDiscord |
<wsor4035> for context, the above is in response to: > https://github.com/minetest/minetest/issues/14707 -- Call malloc_trim() regularly to improve deallocation behavior by sfan5 |
| 18:20 |
sfan5 |
I assume that it still works, no need to test again |
| 18:29 |
MTDiscord |
<siliconsniffer> Thanks wsor, sorry for the messy message. Ah okay, yeah works - I havn't "benchmarked" it so I can't tell you if your later commits improved it or not but either way it's better than before. Thanks for your work! |
| 19:42 |
MTDiscord |
<exe_virus> Wait wat? I'm doing benchmark testing, and I'm trying to duplicate results on master and a branch. One of my more ridiculous things I try, is to delete a pseudorandom ID number. I'm getting different results for which actual object this deletes. Which makes me want to know: Is the active object ID assigned, not in order of 1,2,3... Immediately after startup? For example, is there somewhere that would cause it to start at 500 |
| 19:42 |
MTDiscord |
instead of 1... |
| 19:48 |
MTDiscord |
<josiah_wi> I believe there is no guarantee by the active object mgr about what order IDs will be assigned in. |
| 19:49 |
MTDiscord |
<josiah_wi> There may be a certain order in the current implementation, but that's not documented as being part of the contract, so if it is we need to add some unit tests for it and document it. |
| 19:50 |
MTDiscord |
<exe_virus> Okay, fair enough. So now how do I remove a randomized object, and remove the same one each time.... Across the two executions/branches... |
| 19:52 |
MTDiscord |
<josiah_wi> Could you explain more about what you mean by removing a randomized object, but having it be the same one each time? |
| 19:52 |
MTDiscord |
<josiah_wi> I don't usually thing of "randomized" and "same one" as going together. |
| 19:52 |
MTDiscord |
<josiah_wi> think* |
| 19:53 |
MTDiscord |
<josiah_wi> Maybe I should rename myself to Rubber Duck. |
| 19:55 |
MTDiscord |
<exe_virus> I am using pseudorandom number to determine when* to delete an object, add an object, move an object, and getobjects in radius and area. I do this many times to simulate fuzzy testing to ensure my branch and master have identical behavior. Right now, so make things a better test, 1/80 objects I find in radius or area, I delete the object ID two less than the found object. That ID, with identical test code, is resulting in a |
| 19:55 |
MTDiscord |
different number. Master might delete 132, and my branch might try 543. This with everything else getting identical results, except object IDs. Since I cannot seem to rely on object IDs being identical, I have to write a slightly worse test, and delete the current object (1/80 times) regardless of ID, and hope that's a strong enough fuzz test. |
| 19:57 |
MTDiscord |
<josiah_wi> Hmm, since the relative ordering of new IDs doesn't need to be the same between branches, I don't think it's something you need to test. I would think deleting the current object, or deleting a particular object you can identify some way, would be sufficient. |
| 19:58 |
MTDiscord |
<josiah_wi> Could the unexpectedly large ID assignments be due to existing entities loaded from the database? |
| 19:58 |
MTDiscord |
<exe_virus> It'll have to be current. Because since I'm messing with objects in area and radius, I can't rely on that functionality haha |
| 19:58 |
MTDiscord |
<exe_virus> No: this is not a full startup, this is unit/benchmark testing, where I just create a new SAO manager in a c++ file and test in that sandbox |
| 19:58 |
MTDiscord |
<josiah_wi> I haven't read that part of the code carefully, but I believe objects alive at runtime may be saved to the database and their IDs may even be saved with them, potentially. |
| 19:59 |
MTDiscord |
<josiah_wi> Ok. |
| 20:01 |
MTDiscord |
<josiah_wi> It could still load the entities. It may not be a full startup, but it pretty much runs in a fully initialized context. 😄 You are probably right that it won't. It's extremely unlikely in a unit test. I'm just noting for completeness that if the object manager does a database read and it happens to read an actual database somehow then boom. |
| 20:01 |
MTDiscord |
<josiah_wi> If I've learned one thing about programming it's to never assume anything. |
| 20:02 |
MTDiscord |
<exe_virus> well, number of entities is identical in both: 1000,1000 |
| 20:04 |
MTDiscord |
<josiah_wi> I would be concerned that if the way the IDs are assigned has changed and you didn't intend to change it, then, well, you made a change you didn't mean to and that's probably not desirable. |
| 20:05 |
MTDiscord |
<josiah_wi> For the purpose of the test, you shouldn't rely on it being the same, but if you didn't mean to change it and it was deterministic (which I believe it was) that's another matter. |
| 20:17 |
MTDiscord |
<exe_virus> Aha! it's a different order because my map is unordered when it returns a range.... |
| 20:17 |
MTDiscord |
<exe_virus> so.... hurm.... how to make this deterministic if the order is always jumbled... |
| 20:29 |
MTDiscord |
<exe_virus> there... is no good way is there.... well... I have 1000 entities. and I determined they do go from 1-1000 deterministically (normal for once). and I only add or remove 30 from each iteration... before redoing all 1000..... okay, I'll just remove a random one between 0-1000, if it exists |
| 21:06 |
MTDiscord |
<exe_virus> nope, since the ID's are jumbled, that doesn't work, because I move random sets of objects with randpos, which would be fine, but by deleting random ID's, I get different ordering for who is moved where, thereby affecting in_radius removals... sigh. I'll just get rid of deletes. Hopefully ordered results aren't required |
| 22:33 |
|
panwolfram joined #minetest-dev |
| 22:49 |
|
SFENCE joined #minetest-dev |
| 23:10 |
|
SFENCE joined #minetest-dev |
