Minetest logo

IRC log for #minetest-dev, 2018-10-06

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:13 VanessaE I saw "use full words for NSFW directions" there....
00:24 paramat joined #minetest-dev
00:25 paramat lol
00:27 VanessaE I thought to myself, what do you do, sprinkle all kinds of offensive and pornographic language into it? :)
00:48 ANAND joined #minetest-dev
02:36 paramat joined #minetest-dev
02:43 paramat merging #7769
02:43 ShadowBot https://github.com/minetest/minetest/issues/7769 -- Various spelling and grammar improvements by paramat
02:46 paramat merged
02:57 Lone-Star left #minetest-dev
02:58 Lone-Star joined #minetest-dev
03:12 ssieb joined #minetest-dev
03:23 ANAND joined #minetest-dev
03:50 jas__ joined #minetest-dev
06:15 ANAND joined #minetest-dev
06:18 opal joined #minetest-dev
10:01 ANAND joined #minetest-dev
10:10 sys4 joined #minetest-dev
10:14 sys4_ joined #minetest-dev
10:36 Fixer joined #minetest-dev
11:00 Fixer joined #minetest-dev
11:07 Krock joined #minetest-dev
11:08 Krock well yeah, it's nice that it's supported in GCC but that's not the only compiler out there
11:16 p_gimeno I know, I've been looking for alternatives. The most standard way I've found is using memcmp, but it isn't optimized by GCC.
11:17 calcul0n joined #minetest-dev
11:23 p_gimeno so, here's one question: would it be acceptable to support directly only the same endianness for integer and float, and fall back to generic code in any other case? (that is, drop the cases of endianness differences between int and float). it seems like a reasonable compromise to me
11:36 Gael-de-Sailly joined #minetest-dev
12:24 p_gimeno if so, this should work and it's standard: https://paste.scratchbook.ch/view/43eb2bcb
12:37 Krock yes, I think that should be ok
12:49 T4im joined #minetest-dev
13:30 Ruslan1 joined #minetest-dev
14:18 Krock joined #minetest-dev
14:31 ANAND joined #minetest-dev
14:52 Krock p_gimeno: if memcpy is used, and the endianness of u32 and f32 are the same, then is bitshifting still needed when using readU32/writeU32 since it seems to output the correct byte order already?
14:52 Krock well yeah, "be32toh" so it should be corrected already
15:14 p_gimeno Krock: if the endianness is the same, then it's safe to pass it to writeU32 so it deals with the platform's endianness
15:14 p_gimeno same if it comes from readU32
15:18 Krock okay, thanks for confirming. *simplifies the code*
17:05 paramat joined #minetest-dev
17:09 Krock p_gimeno: it might not be the most detailed test, but a step of 41 should suffice to prove that the custom float functions provide the wanted encoding
17:10 Krock this brings the test time down from 3 minutes to 5.2s
17:26 p_gimeno Krock: still, best if that's only done in the unit testing only, not during normal runs
17:26 p_gimeno oops, there's one 'only' too much in that sentence
17:39 p_gimeno Krock: oh, I hadn't checked your new commit yet, sorry. Infinity (i=0x7F800000 and i=0xFF800000) is important to be tested as a special case, and a step of 41 skips it (because 0x7F800000 % 41 = 31). Maybe add it as a special case at the beginning like NaN?
17:40 Krock yes sure
18:28 p_gimeno Krock: in the last comment I've sent, my point is that as written, the test will fail in every non-IEEE platform even if the functions work correctly
18:31 Krock I see, thanks for the input. Travis also suggests me to do more work on compatibility
19:13 Cornelia joined #minetest-dev
22:02 paramat joined #minetest-dev
22:03 sys4 joined #minetest-dev
22:15 sys4_ joined #minetest-dev
23:11 Gael-de-Sailly joined #minetest-dev
23:23 paramat game#2180 seems ready
23:23 ShadowBot https://github.com/minetest/minetest_game/issues/2180 -- Add blueberry bushes by random-geek
23:27 Ruslan1 joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext