| Time |
Nick |
Message |
| 00:05 |
|
Eragon joined #minetest-dev |
| 01:12 |
|
YuGiOhJCJ joined #minetest-dev |
| 03:40 |
MTDiscord |
<mistere_123> Attn: the bridge will be down for maintenance for (hopefully only) a few minutes. I will be moving the server. |
| 04:31 |
MTDiscord |
<mistere_123> Bridge going down now |
| 04:33 |
|
[MatrxMT] joined #minetest-dev |
| 04:38 |
[MatrxMT] |
<MisterE> test |
| 04:56 |
|
[MatrxMT] joined #minetest-dev |
| 04:57 |
|
[MatrxMT] joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:02 |
|
[MatrxMT] joined #minetest-dev |
| 05:05 |
|
[MatrxMT] joined #minetest-dev |
| 05:06 |
|
[MatrxMT] joined #minetest-dev |
| 05:12 |
MTDiscord |
<mistere_123> test |
| 05:20 |
|
MisterE123 joined #minetest-dev |
| 05:20 |
MisterE123 |
test from irc |
| 05:21 |
MTDiscord |
<mistere_123> Seems to work as well as it has been... so I'll put it back on a systemctl service and hope for the best. |
| 05:22 |
|
[MatrxMT] joined #minetest-dev |
| 05:22 |
[MatrxMT] |
<MisterE> and finally,: test |
| 11:29 |
|
hwpplayer1 joined #minetest-dev |
| 13:59 |
|
SFENCE joined #minetest-dev |
| 14:02 |
MTDiscord |
<herowl> Does anyone (sfan5 maybe?) know how mesh nodes are batched? I.e. if I make a few different nodes using same mesh, but different textures, will those be batched? |
| 14:05 |
sfan5 |
we can't batch things with different textures |
| 14:12 |
|
hwpplayer1 joined #minetest-dev |
| 15:40 |
|
hwpplayer1 joined #minetest-dev |
| 15:48 |
|
hwpplayer1 joined #minetest-dev |
| 16:15 |
|
SFENCE joined #minetest-dev |
| 16:55 |
|
hwpplayer1 joined #minetest-dev |
| 18:11 |
|
hwpplayer1 joined #minetest-dev |
| 18:31 |
celeron55 |
if you make different nodes using a different mesh but the same texture, they might(*) get batched |
| 18:33 |
celeron55 |
the fine print: i'm not looking at the code |
| 18:57 |
|
wrrrzr joined #minetest-dev |
| 18:58 |
wrrrzr |
Hello, is it necessary to do "enum : u8" or is it useless and damagefull for code? |
| 18:59 |
wrrrzr |
*damageful |
| 18:59 |
MTDiscord |
<josiah_wi> Is that done anywhere else in the codebase yet? |
| 19:00 |
wrrrzr |
Yes |
| 19:00 |
MTDiscord |
<josiah_wi> Yay, I think it's fine to do then. |
| 19:00 |
MTDiscord |
<josiah_wi> It could potentially save a lot of memory. |
| 19:01 |
wrrrzr |
It damageful for serialization or something like this? |
| 19:02 |
MTDiscord |
<josiah_wi> Good question, but I don't think so. In fact it's probably beneficial for serialization, because u8 is a fixed-width type. |
| 19:02 |
MTDiscord |
<josiah_wi> I think enums use int as the underlying type if none is specified, right? And int is not a fixed-width type, so it could in fact be damaging for serialization to not specify the underlying type width. |
| 19:04 |
wrrrzr |
And what about backward compatibility? |
| 19:05 |
wrrrzr |
Luanti uses binary data for saving worlds? |
| 19:08 |
sfan5 |
serializating enum types should generally use explicit types so there aren't accidental differences |
| 19:08 |
MTDiscord |
<luatic> wrrrzr: Why are you using enum : u8? |
| 19:09 |
MTDiscord |
<luatic> I'd just use enum unless you explicitly see a need to restrict this |
| 19:09 |
MTDiscord |
<luatic> Is it serialized? If so then it makes sense to supply a width, but you should think about how many values this might need to hold in the future |
| 19:11 |
wrrrzr |
I think enum : u8 saves memory in serialization, and i know that i need to take more bigger types if enum is big |
| 19:12 |
MTDiscord |
<luatic> without context it's hard to say whether u8 will be enough for the future (though probably yes) and whether saving memory is important at all |
| 19:13 |
wrrrzr |
Why not? It saves 3 bytes per one element |
| 19:14 |
MTDiscord |
<luatic> If you only have a couple elements, that is irrelevant |
| 19:14 |
MTDiscord |
<luatic> Also, are we talking memory or persistent storage here? In memory the byte will often have to be aligned so the compiler might have to throw those 3 bytes away either way. |
| 19:21 |
MTDiscord |
<luatic> btw fun fact, while practically it may end up as an int, the compiler should in principle be free to choose a smaller integral type for an enum (which is why there are compiler flags like -fshort-enum) |
| 19:24 |
wrrrzr |
Ok, i think I'll leave everything as it was |
| 19:31 |
|
hwpplayer1 joined #minetest-dev |
| 20:16 |
|
wrrrzr left #minetest-dev |
| 20:22 |
|
wrrrzr joined #minetest-dev |
| 20:22 |
wrrrzr |
Test message |
| 20:22 |
|
wrrrzr left #minetest-dev |
| 20:23 |
MTDiscord |
<wsor4035> test failed successfully |
| 20:37 |
|
hwpplayer1 joined #minetest-dev |
| 22:33 |
[MatrxMT] |
<Zughy> luatic: please check Matrix DMs, possible exploit |
| 22:58 |
|
Desour joined #minetest-dev |
| 23:04 |
Desour |
enum class has int as underlying type. c style enum uses smalles bitfield that is large enough, iirc |
| 23:05 |
Desour |
see also #14090, btw |
| 23:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/14090 -- Fix out of range enum casts in deSerialize functions by cx384 |
| 23:33 |
|
panwolfram joined #minetest-dev |
| 23:38 |
|
TheCoffeMaker joined #minetest-dev |
