| Time |
Nick |
Message |
| 02:51 |
|
aliasstilltaken joined #luanti-dev |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 10:36 |
|
Desour joined #luanti-dev |
| 10:45 |
|
Sompi joined #luanti-dev |
| 11:05 |
|
pgimeno_ joined #luanti-dev |
| 13:04 |
MTDiscord |
<sumianvoice> I've been looking at core.check_for_falling because it's very very slow for my use case, does anyone know if there's a reason it's so complex, and specifically why it always checks 11 nearby nodes no matter what? I made a quick replacement for it using an existing node update API and it was about 10x faster despite being un-optimised, mostly due to not needing to check all 11 nodes, only the one position being checked. I can tell |
| 13:04 |
MTDiscord |
some games might rely on this, specifically because you can dig_node(pos), check_for_falling(pos) and it always checks the nodes it needs to, but even then falling nodes only happen when unsupported on y - 1, so just checking the one node above (until there is a falling node found) would be a substantial improvement to performance already without actually hurting functionality. Is this something that might change or is it being kept for legacy |
| 13:04 |
MTDiscord |
support? For now I can just make my own parallel system for it, but it seems odd to have this really slow function lying around checking >5x as many nodes as it needs to. |
| 13:32 |
luatic |
"I made a quick replacement for it using an existing node update API and it was about 10x faster despite being un-optimised, mostly due to not needing to check all 11 nodes, only the one position being checked" - might you want core.check_single_for_falling? |
| 13:40 |
MTDiscord |
<sumianvoice> My replacement uses that yes, but the normal use of it doesn't propagate it to other nodes, so only the one node can ever fall at a time. |
| 13:48 |
luatic |
so you want a sort of core.check_column_for_falling? |
| 13:48 |
luatic |
which only propagates upwards? |
| 16:58 |
|
SFENCE joined #luanti-dev |
| 17:18 |
|
SFENCE joined #luanti-dev |
| 17:27 |
|
SFENCE joined #luanti-dev |
| 17:31 |
|
pgimeno_ joined #luanti-dev |
| 17:39 |
|
SFENCE joined #luanti-dev |
| 18:13 |
|
SFENCE joined #luanti-dev |
| 18:18 |
sfan5 |
merging #16472, #16380 soon |
| 18:18 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/16472 -- [no squash] Make node break particles visible to all players by sfan5 |
| 18:18 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/16380 -- CGUITTFont: Clean up, unify and comment draw code by SmallJoker |
| 18:42 |
|
SFENCE joined #luanti-dev |
| 18:47 |
Krock |
> (server) [FAIL] test_node_callbacks - 0ms |
| 18:48 |
Krock |
though this seems entirely unrelated to the recent changes. |
| 18:48 |
Krock |
y5nw: I'll try to find the source locally. Perhaps it's a mod that triggers it ..? |
| 18:48 |
Krock |
access |
| 18:49 |
Krock |
(hehe, missing Ctrl+F) |
| 18:49 |
sfan5 |
yeah I have no idea what's with the CI |
| 18:50 |
sfan5 |
precisely because we have a second job that runs the same tests and it doesn't fail |
| 18:51 |
[MatrxMT] |
<y5nw> Krock: I would guess so given that the in-house translation system is only used on mods. Although I can't reproduce it with devtest (which has French .po test files) or with Repixture (which seems to use .po files) |
| 18:54 |
sfan5 |
re-ran the job, it worked |
| 18:55 |
sfan5 |
must be cosmic rays hitting the github server |
| 19:01 |
|
SFENCE joined #luanti-dev |
| 19:07 |
Krock |
gettext_plural_form.cpp is a pain to read |
| 19:08 |
Krock |
what an unfortunate time to have eyes |
| 19:14 |
Krock |
> static ParserResult reduce_ltr(const size_t nplurals, const ParserResult &res, const wchar_t** patterns) |
| 19:14 |
Krock |
how does this function know the length of the array "patterns"? |
| 19:14 |
Krock |
it happily increments the pointer and passes it to the next function, which seems error-prone. |
| 19:19 |
Krock |
and translation.cpp:474 (last_entry[L"msgstr"]) reads out of bounds |
| 19:21 |
sfan5 |
null-terminated maybe? |
| 19:22 |
Krock |
^ sorry, that's a misinterpretation. It's where the memory originates, and not where the invalid access occurred. This also points to reduce_ltr |
| 19:27 |
Krock |
https://pastebin.com/raw/xFsqAxrR |
| 19:28 |
Krock |
as of master fcd9c73f2f63f9 |
| 20:29 |
[MatrxMT] |
<y5nw> Krock: The length of `patterns` is assumed to be the same as the number of operators. I'm working on changing this to throw a compile-time error if the lengths don't match, but the result is a bit ... ugly |
| 20:30 |
Krock |
Compile time? That might be a bit difficult if the data origin is an external file, right? |
| 20:34 |
[MatrxMT] |
<y5nw> Krock: https://pastebin.com/sJdT6m0p |
| 20:35 |
[MatrxMT] |
<y5nw> Also the data origin is not an external file. The operators (patterns) are listed as static const wchar_t *[] |
| 20:37 |
[MatrxMT] |
<y5nw> Ideally it would be nice to be able to specify the operator (class) and the pattern together in a template (or something similar), but I don't think that can be (easily) done. |
| 20:49 |
[MatrxMT] |
<y5nw> Realistically though I suspect the problem is elsewhere given that the line suggests something off with the string_view it received |
| 21:00 |
|
SFENCE joined #luanti-dev |
| 22:33 |
|
panwolfram joined #luanti-dev |
| 22:56 |
|
SFENCE joined #luanti-dev |
| 23:05 |
|
Eragon joined #luanti-dev |
| 23:13 |
|
wrrrzr joined #luanti-dev |
| 23:31 |
|
SFENCE joined #luanti-dev |
