| Time |
Nick |
Message |
| 01:02 |
MTDiscord |
<exe_virus> Sfan, that's true for sizeof, but when that goes to the stack, everything is in their own address unless you're using structures, and specifically forcing the compiler to use #pragma pack 1/2/4, then it will do a lot of fancy slow code to stuff the floats together on most platforms, even when that's not efficient. Pragma pack is used most commonly for network buffer messages to make them byte aligned without changing the actual |
| 01:02 |
MTDiscord |
message structure. For example do sizeof() on a structure containing a single double and a single float, and tell me the size it returns by default on your machine |
| 01:13 |
pgimeno |
why a double and a float instead of two floats? |
| 01:15 |
pgimeno |
http://www.formauri.es/personal/pgimeno/pastes/floats.c |
| 01:15 |
pgimeno |
@exe_virus ^ |
| 02:28 |
|
queria^clone joined #minetest-dev |
| 02:33 |
|
queria^clone joined #minetest-dev |
| 02:35 |
|
Extex joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:05 |
|
v-rob joined #minetest-dev |
| 04:18 |
|
tekakutli joined #minetest-dev |
| 04:38 |
|
YuGiOhJCJ joined #minetest-dev |
| 05:04 |
|
pgimeno joined #minetest-dev |
| 05:33 |
|
tekakutli joined #minetest-dev |
| 07:28 |
|
specing_ joined #minetest-dev |
| 08:05 |
|
hendursa1 joined #minetest-dev |
| 08:37 |
Krock |
> INFO[Main]: Client::ProcessData(): Discarding data not coming from server: peer_id=24432 |
| 08:37 |
Krock |
hmmm |
| 08:52 |
|
Fixer joined #minetest-dev |
| 09:11 |
|
olliy joined #minetest-dev |
| 09:16 |
MTDiscord |
<exe_virus> Two floats will get packed as you expect, because it aligns with 64 bits. I specifically asked for something that doesn't align with 64 bits nicely. In code that happens relatively often, even with a compiler, and so the floats will typically get stored on a single address alone in their very own double. If you bit align yourself, then the compiler can do fancy things. 3 floats would also get the same result as a double + float. |
| 09:16 |
MTDiscord |
That being one float is stored by itself. In code if you have 3 floats doing different jobs all close to each other, they'll typically not be placed onto a single register/address during that code execution except in cases of SSE. |
| 09:26 |
MTDiscord |
<exe_virus> https://www.google.com/amp/s/www.geeksforgeeks.org/structure-member-alignment-padding-and-data-packing/amp/ |
| 10:32 |
sfan5 |
Krock: for testing your PR consider this https://clang.llvm.org/docs/ThreadSanitizer.html |
| 10:33 |
Krock |
sfan5: I found a culprit. std::move |
| 10:33 |
sfan5 |
ah |
| 10:33 |
Krock |
the buffer became invalid afterwards |
| 10:42 |
sfan5 |
btw for a "const-wrapper class" I was thinking of something like this http://sprunge.us/vNucxM?cpp |
| 10:42 |
sfan5 |
would remove the need to do that manually |
| 10:44 |
Krock |
oh that's a neat idea |
| 10:46 |
|
calcul0n_ joined #minetest-dev |
| 10:55 |
Krock |
hmm.. problem is that connection.cpp / connectionthreads.cpp need access to members, such as "address", "type", "time" |
| 10:56 |
Krock |
read&write access |
| 11:07 |
|
tech_exorcist joined #minetest-dev |
| 11:11 |
sfan5 |
you can add write access but then it's not automatically safe anymore |
| 11:13 |
sfan5 |
also I just noticed that removing the move constructors in my example is not actually needed |
| 11:22 |
nrz |
we should copy those tiny data if you are talking about thread safeness ? |
| 11:34 |
Krock |
tiny data? how about entire packets? |
| 11:38 |
sfan5 |
#11612 and #10729 could use another review |
| 11:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/11612 -- Fix client-side performance of chat UI by Desour |
| 11:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/10729 -- Allow Enabling The Touch UI In A Desktop Build by TheBrokenRail |
| 11:41 |
|
Guest503 joined #minetest-dev |
| 11:43 |
sfan5 |
merging #11616, #11638, #11644 in 10m |
| 11:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/11616 -- Add preprocessor check for weird (incorrect) build configurations by sfan5 |
| 11:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/11638 -- Add feature table entry for new dynamic media API by sfan5 |
| 11:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/11644 -- [PATCH] Trivial typos |
| 11:46 |
sfan5 |
(will put some more typo fixes in the last one) |
| 11:49 |
pgimeno |
github has started giving broken links for commits |
| 11:50 |
pgimeno |
https://github.com/minetest/minetest/pull/11616 - if you click on the commit line, you get a 404 |
| 11:51 |
pgimeno |
changing ...github.com/sfan5/minetest... to ...github.com/minetest/minetest... fixes it |
| 11:52 |
sfan5 |
huh |
| 11:59 |
Krock |
ah very cool. the first thread races already appear on init, in Logger::log() |
| 12:08 |
Krock |
however there's surprisingly no thread race for ConnectionReceiveThread |
| 12:09 |
Krock |
nvm. they appeared earlier in the logs |
| 13:43 |
|
tech_exorcist joined #minetest-dev |
| 13:47 |
|
hendursaga joined #minetest-dev |
| 15:03 |
Krock |
goddamn it. it was a copypaste error |
| 15:34 |
sfan5 |
rubenwardy: you do have server-side checks that people are actually uploading a .zip in CDB, right? |
| 15:35 |
sfan5 |
ah nvm |
| 15:35 |
sfan5 |
there was some unfinished code in the pkgmgr that identified 7z, tar.gz and tar.bz2 and I was wondering if it could possibly have worked in previous versions |
| 15:35 |
sfan5 |
but it can't |
| 15:38 |
rubenwardy |
Yeah |
| 15:38 |
rubenwardy |
Also unzip the zips and validate the contents |
| 15:38 |
rubenwardy |
Such as init.lua/mod.conf/etc |
| 15:55 |
|
Extex joined #minetest-dev |
| 16:25 |
|
Desour joined #minetest-dev |
| 17:38 |
|
v-rob joined #minetest-dev |
| 17:56 |
|
Extex joined #minetest-dev |
| 18:05 |
sfan5 |
pgimeno: https://github.community/t/bug-clicking-on-pr-commit-links-causes-404/201684 |
| 18:05 |
sfan5 |
(wonder if that page works without js) |
| 18:05 |
sfan5 |
looks like someone already opened a topic in the place where github excepts bug reports, so they'll hopefully fix it soon |
| 18:05 |
pgimeno |
thanks, let's hope so |
| 18:07 |
Pexin |
I've got most enduser github stuff working without js, but that's because greasemonkey |
| 18:08 |
Pexin |
well, greasemonkey and custom browser css that forces element visibility |
| 18:09 |
Pexin |
no contributor stuff tho |
| 18:13 |
sfan5 |
merging #10795, #11612, #11637 in 10m |
| 18:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/10795 -- Fix HUD multiline text alignment by appgurueu |
| 18:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/11612 -- Fix client-side performance of chat UI by Desour |
| 18:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/11637 -- Fix src/util/string.cpp on NetBSD by alarixnia |
| 18:17 |
|
longerstaff13 joined #minetest-dev |
| 18:46 |
sfan5 |
does anyone know why we have max_forceloaded_blocks? |
| 18:47 |
Krock |
to avoid that mods spam-load every mapblock? |
| 18:47 |
sfan5 |
but that's a mod bug |
| 18:47 |
sfan5 |
we don't arbitrarily limit the amount of hud elements either |
| 18:47 |
sfan5 |
or entities or particles or ... |
| 18:49 |
Krock |
entities are mapblock-bound, and the server cares basically zero about HUD elements and particles |
| 19:25 |
|
specing_ joined #minetest-dev |
| 19:48 |
sfan5 |
why do vector metatables not have comparison operators |
| 19:48 |
sfan5 |
it seems like an obvious omission |
| 19:49 |
pgimeno |
wasn't there a PR about that? |
| 19:51 |
pgimeno |
#11039 and before it #9612 |
| 19:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/11039 -- Add metatables to lua vectors by Desour |
| 19:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/9612 -- Add a metatable for vectors by Desour |
| 19:51 |
MTDiscord |
<luatic> sfan5: vector comparison is a bit... special, so it might be reasonable to omit that |
| 19:52 |
MTDiscord |
<luatic> (0, 0, 1) is not less than (0, 1, 0), yet (0, 1, 0) isn't less than or equals (0, 0, 1) either |
| 19:52 |
pgimeno |
oh wait, I misread |
| 19:54 |
pgimeno |
what would a < b do for vectors? is (1, 2, 3) < (3, 2, 1)? well, you can use lexicographical order but I don't think that's very useful |
| 19:55 |
MTDiscord |
<luatic> Usually a < b IMO should be interpreted as all components of a must be smaller than the corresponding component of b |
| 19:55 |
sfan5 |
yeah that's what I was thinking of |
| 19:55 |
MTDiscord |
<luatic> But that exhibits the "weird" behavior I just described, so there probably shouldn't be syntactic sugar for it |
| 19:56 |
MTDiscord |
<luatic> modlib actually has that syntactic sugar, but I'm now starting to question it :P |
| 19:56 |
Krock |
a < b is not useful for multi-dimensional values |
| 19:56 |
MTDiscord |
<luatic> Krock: wrong |
| 19:56 |
Krock |
no, correct. |
| 19:56 |
MTDiscord |
<luatic> is a point in an area from min to max? p >= min and p <= max |
| 19:56 |
Krock |
this depends on a coordinate sorting function |
| 19:57 |
Krock |
where each "min" must be smaller or equal "max" |
| 19:57 |
MTDiscord |
<luatic> coordinate sorting function? |
| 19:57 |
MTDiscord |
<luatic> well yes, I can't see these definitions being useful for things like "smart vector table", you'd use lexicographical order for that |
| 19:58 |
pgimeno |
<luatic> Usually a < b IMO should be interpreted as all components of a must be smaller than the corresponding component of b <-- but then you have cases where it's not true that a < b AND it's not true that a > b AND it's not true that a = b, that's abhorrent if you ask me |
| 19:58 |
MTDiscord |
<luatic> yeah, that's the "weird" behavior |
| 19:58 |
pgimeno |
I don't think it's useful |
| 19:58 |
|
Fixer joined #minetest-dev |
| 19:58 |
Krock |
comparisons with weird behaviour are not reliable enough |
| 19:59 |
Krock |
you'd rather have a isInArea(pos, corner1, corner2) function to cover all cases |
| 20:35 |
|
v-rob joined #minetest-dev |
| 23:13 |
|
Extex joined #minetest-dev |
