| Time |
Nick |
Message |
| 00:15 |
|
MisterE123 joined #minetest-dev |
| 00:15 |
|
wsor4035 joined #minetest-dev |
| 00:15 |
|
thelounge656 joined #minetest-dev |
| 00:15 |
|
wsor4035 joined #minetest-dev |
| 00:24 |
|
ShadowBot joined #minetest-dev |
| 00:43 |
MTDiscord |
<luatic> it would be good if someone could review #14565; the new gltf PR i'm currently working on depends on it. |
| 01:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/14565 -- Upgrade client active object mgr tests to Catch2 (reviving #13609) by JosiahWI |
| 01:06 |
MTDiscord |
<luatic> damn that was slow. i wonder what caused the > 20 min delay. |
| 01:11 |
MTDiscord |
<exe_virus> took a look at it: no comments need left, besides perhaps why check two objects instead of one for the "two registered objects" section |
| 01:12 |
MTDiscord |
<exe_virus> Also, do REQUIREs failing cause all catch2 to stop and CHECKS() failing cause it to continue? |
| 01:13 |
MTDiscord |
<luatic> Yes, see https://github.com/catchorg/Catch2/blob/devel/docs/assertions.md |
| 01:13 |
MTDiscord |
<luatic> well, to be more precise, REQUIRE causes the test case to stop |
| 01:13 |
MTDiscord |
<exe_virus> ah, just the test case, not the whole set |
| 01:13 |
MTDiscord |
<luatic> yep |
| 01:15 |
MTDiscord |
<luatic> frankly, i don't think the distinction between aborting and non-aborting assertions is often made, or even needs to be made; it suffices if any test fails if something is wrong. though it is of course nicer if it then aborts early rather than "spamming" you with various failures. |
| 01:17 |
MTDiscord |
<luatic> anyways, there isn't much of a difference between testing one or two objects there, but testing two objects tests a bit more; it tests that the AO mgr can actually keep two objects apart. so i'm not opposed to it. |
| 01:25 |
MTDiscord |
<josiah_wi> My own habit for CHECK vs REQUIRE is that the assertion of interest will be a CHECK. I don't use REQUIRE for things I want to test - I use it more like an assertion on the test code itself. |
| 01:26 |
MTDiscord |
<josiah_wi> In one of these test cases for example, I access a pointer returned by the API. I don't want to generate a segfault because that's a nuisance for someone trying to understand what failed, so I immediately halt the test if that would happen. |
| 01:44 |
|
nrz joined #minetest-dev |
| 01:45 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 06:13 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:45 |
pgimeno |
<sfan5> "my primary worry of course is that modders use [IPC poll] to block the server thread" |
| 07:45 |
pgimeno |
is there a way to include a coroutine in the implementation, to avoid blocking the server? I haven't given it much thought tbh but it might be workable |
| 07:47 |
pgimeno |
the implementation could be along these lines: https://hump.readthedocs.io/en/latest/timer.html#Timer.script but with the blocking IPC poll instead of the wait function |
| 09:28 |
|
imi joined #minetest-dev |
| 10:51 |
|
Desour joined #minetest-dev |
| 11:34 |
|
Noisytoot joined #minetest-dev |
| 11:37 |
|
imi joined #minetest-dev |
| 11:48 |
sfan5 |
polling would only be useful in situations where there is no option but to block |
| 11:48 |
sfan5 |
becuase if you have the option to resume code later you can just do the polling yourself with core.after() |
| 11:48 |
|
Noisytoot joined #minetest-dev |
| 11:49 |
sfan5 |
to be precise: "the IPC poll API would only be useful in [...]" |
| 13:16 |
|
imi joined #minetest-dev |
| 14:47 |
|
TheCoffeMaker joined #minetest-dev |
| 14:54 |
|
TheCoffeMaker joined #minetest-dev |
| 16:14 |
|
Warr1024 joined #minetest-dev |
| 16:47 |
|
TheCoffeMaker joined #minetest-dev |
| 17:02 |
|
imi joined #minetest-dev |
| 17:23 |
sfan5 |
merging #14654, #14639, #14638 in 15m or more |
| 17:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/14654 -- Fix some clang compiler warnings by appgurueu |
| 17:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/14639 -- Don't bundle Development Test on macOS by rollerozxa |
| 17:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/14638 -- Fixes to Docker GitHub Actions workflow by AFCMS |
| 17:26 |
|
fluxionary joined #minetest-dev |
| 21:47 |
MTDiscord |
<exe_virus> I may not understand Minetest well: modifySafeMap has a mutex inside... When do we have multiple threads talking to SAOs? Or where do we have more than just the main thread? |
| 21:49 |
sfan5 |
where do you see a mutex? |
| 22:02 |
MTDiscord |
<exe_virus> was given bad info from lars lol, no is doesn't have a mutex. So I assume that all operations on that map are single threaded? |
| 22:02 |
MTDiscord |
<exe_virus> I'm trying to track down a bug related to entity activation and wanted to rule out other threads before deep diving |
| 22:04 |
MTDiscord |
<exe_virus> Also, just putting this out there: based on YourLands testing, once we help with getObjectsInRadius and that family, ModifySafeMap::get() is the next big culprit, mostly because std::map is slow. Perhaps we should consider a faster ordered map? https://github.com/greg7mdp/parallel-hashmap |
| 22:06 |
MTDiscord |
<luatic> yep stupid mistake on my part, was looking at the wrong class (MutexedMap..) |
| 22:09 |
MTDiscord |
<exe_virus> Once that* one is done, the next biggie is no surprise: axisAlignedCollision, not much we can probably do there, haha |
| 22:10 |
MTDiscord |
<luatic> i wouldn't be surprised if there was optimization potential with SIMD or similar |
| 22:10 |
MTDiscord |
<exe_virus> Oh, true. Hardware optimizations |
| 22:33 |
|
panwolfram joined #minetest-dev |
