Time  Nick           Message
02:00 est31          I have raised this topic before, but perhaps somebody hasn't heard.
02:00 est31          anybody against accepting Calinou's entry for the website?
02:01 est31          the only Issue I could see this far is its big download size
02:04 est31          But there are ways to make it smaller, perhaps I'll send PRs
02:07 BrandonReese   I think it was mentioned on the forums but the size of the home page is because it's loading the full size images in the gallery
02:08 BrandonReese   All the other pages seem to be less than 600k
02:12 est31          thats already too large
02:13 BrandonReese   Oh really?
02:13 BrandonReese   What size is optimal?
02:13 est31          It should be < 100 KB
02:22 y              considering 600k takes 40 seconds to load over 2g here
10:26 kahrl          is the glitching through blocks with using the sneak glitch really fixed? (#3045 / #3089)
10:26 ShadowBot      https://github.com/minetest/minetest/issues/3089 -- Fix glitching through block while sneak glitching by BlockMen
10:27 kahrl          I built this simple structure: https://imgrush.com/akOkveH1Hj-E.png
10:27 kahrl          and stood inside it: https://imgrush.com/2XxfmrSWDG9o.png
10:28 kahrl          if I then press sneak + jump, I glitch through the ceiling
10:28 kahrl          see also https://forum.minetest.net/viewtopic.php?f=6&t=13123
10:34 kahrl          reopened 3045.
11:07 nanepiwo       is play store updated?
11:25 nrzkt          nanepiwo: not, not atm because i need to check a thing with est31
11:26 nrzkt          apk is built and signed but not uploaded yet
14:30 sfan5          https://github.com/minetest/minetest/pull/3116
14:30 sfan5          the fucl
14:30 sfan5          why is this needed?
14:33 sfan5          it just breaks a lot of pull requests
14:33 sfan5          i thought we generally dont accept dumb stylistic changed like this
14:49 est31          sfan5, its not just style
14:50 est31          i++ copies the iterator, and discards the copy
14:50 est31          ++i doesnt copy it
14:50 est31          therefore ++i should be used instead
14:50 est31          the copy is only a problem for iterators, etc. "simple" types like integers arent affected by this
14:59 kahrl          how would a single-line conflict that can be easily rebased "break" a pull request?
15:00 est31          I guess sfan5 argues that it needs manual intervention
15:00 kahrl          oh well
15:01 Gael-de-Sailly minor change about ore generation : https://github.com/minetest/minetest/pull/3119
15:01 est31          nrzkt, your apk works
15:06 sfan5          est why do you always leave
15:06 sfan5          anyway
15:07 sfan5          are you sure that compilers are that dumb?
15:07 sfan5          i doubt the compiler will copy the iterator and throw the copy away
15:30 nrzkt          ~tell est31: then i upload to playstore ?
15:30 ShadowBot      nrzkt: O.K.
18:36 neoascetic     tell ShadowNinja #3117 is OK now
18:36 ShadowBot      https://github.com/minetest/minetest/issues/3117 -- Fixes building on OSX caused by e4bff8b (refs #2613) by neoascetic
18:45 est31          <sfan5> est why do you always leave <---- because I go afk, and turn my computer off.
18:45 est31          nrzkt, btw I don't seem to get your messages
18:46 est31          but yeah, I guess you can upload it
18:46 sfan5          nrzkt: i think you need to omit the :
18:46 sfan5          ~tell est31 like this
18:46 ShadowBot      sfan5: O.K.
18:46 sfan5          did that work?
18:47 est31          -ShadowBot- Sent just now: <sfan5> like this
18:47 est31          yes
18:47 sfan5          ok
18:47 est31          but I have to leave and join again
18:47 est31          anyway
18:48 est31          I dont think compilers optimize that away
18:48 est31          the copy is an opaque method call
18:48 sfan5          why would they differ between (void) i++ and (void) ++i
18:48 est31          the copy can have side effects
18:48 sfan5          such as?
18:49 est31          its just a completely normal method I guess
18:50 nrzkt          est31: okay uploading it then
18:53 nrzkt          notice: 493 devices will not be supported anymore with this version because we switch from armeabi to armeeabi-v7a
18:53 nrzkt          armeabi-v7a*
18:53 est31          yeah ...
18:54 est31          but its claimed to be faster
18:54 nrzkt          whereis the changelog ?
18:54 sfan5          not claimed
18:54 sfan5          armv7 is clearly faster than armv6
18:54 nrzkt          i will add a link
18:54 nrzkt          got it :)
18:55 est31          my i9100 is a 2011 model, and has armv7 as well
18:56 nrzkt          i hope nobody will have same crash as me on my Huawei Ascend from 2013...
18:56 est31          whats the logcat?
18:57 nrzkt          i haven't it atm, will look at this a little bit more later :) i come here for publishing apk :) good evening
18:59 sfan5          est31: i just tested, my gcc (v5.2.0 x86_64 -O2) generates the exact same assembly code for this example with i++ and ++i http://sprunge.us/VBGg?cpp
19:01 sfan5          est31: v4.8.1 x86_64 -O2 MinGW too
19:01 sfan5          32-bit mingw too
19:03 sfan5          est31: is i++ vs ++i supposed to have any other advantages?
19:04 est31          sfan5, not that I know
19:04 sfan5          so the PR is complete bullshit
19:05 sfan5          i suggest adding a rule to the git guidelines not to merge any PR thats supposed to improve some performance without anyone actually proving that it does
19:06 est31          sfan5, I get a largely differing assembler output
19:06 est31          I did g++ -g -Wa,-alh  a.cpp  > pre.ass
19:07 sfan5          -Wa,-alh wat
19:07 est31          and then diff pre.ass post.ass
19:07 sfan5          g++ -O2 -S test.cpp -o - > thing.S
19:07 nrzkt          est31: you forgot -O2
19:07 est31          -S didnt work for me
19:07 nrzkt          in release process it's done, and gcc solve the problem itself
19:07 sfan5          then you should fix your gcc
19:09 est31          without -O2 there is a difference
19:09 sfan5          indeed
19:09 sfan5          and who cares about that
19:09 sfan5          we build minetest with -O2
19:09 est31          everybody who runs minetest in debug mode because they get std::bad_allow
19:09 est31          alloc*
19:09 est31          or other crashes
19:09 est31          to give us stacktraces
19:10 est31          isnt -g and -O conflicting?
19:10 sfan5          yes
19:10 est31          as in "either or"
19:10 sfan5          -g is debug
19:10 sfan5          i mean no
19:10 sfan5          CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
19:10 sfan5          we even use -O3
19:11 sfan5          debug is either -O0 or -O1 indeed
19:11 sfan5          woops no i customized that
19:11 est31          O1 seems to be enough
19:12 sfan5          set(CMAKE_CXX_FLAGS_DEBUG "-g -O0 -Wall -Wabi ${WARNING_FLAGS} ${OTHER_FLAGS}")
19:12 sfan5          -O0 is slow anyway
19:12 sfan5          i suggest not trying to "optimize" for -O0
19:12 sfan5          tl;dr the whole change is still not necessary
19:13 est31          well, its completely non functional
19:13 sfan5          any sane person would use set(CMAKE_CXX_FLAGS_SEMIDEBUG "-O1 -g -Wall -Wabi" CACHE STRING
19:13 sfan5          that one
19:14 sfan5          actually we could simply have changed the debug optimization
19:14 est31          I mean its something else to say "++i instead of i++" than to say "I add some face position cache because it removes some copies"
19:14 est31          sfan5, thats more intrusive than editing code
19:14 est31          at least in this case
19:14 sfan5          nope
19:15 sfan5          you rather edit 125 lines than 1?
19:15 est31          if its less intrusive yes
19:15 sfan5          how is making the debug build not damn slow intrusive?
19:16 est31          it can optimize e.g. assert checks away
19:16 est31          or it can change undefined behaviour
19:16 sfan5          wat
19:16 est31          and make valgrind crash
19:16 sfan5          assert checks are done unless you set NDEBUG
19:16 est31          who knows how valgrind behaves
19:17 sfan5          NDEBUG is not the same as the optimisation level
19:17 nrzkt          est31: asserts are useful to fix bugs
19:17 nrzkt          don't remove it.
19:17 est31          nrzkt, therefore they shouldnt be removed
19:18 est31          its far more risky to SET A WHOLE COMPILER FLAG than to make obvious optimisations yourself
19:19 sfan5          est31: "If you are planning to use Memcheck: [...] All other tools (as far as we know) are unaffected by optimisation level, and for profiling tools like Cachegrind it is better to compile your program at its normal optimisation level."
19:19 sfan5          tl;dr the -O level does not matter unless your using memcheck
19:19 sfan5          http://valgrind.org/docs/manual/manual-core.html#manual-core.started
19:20 est31          "So the best solution is to turn off optimisation altogether. "
19:21 sfan5          est31: "If you are planning to use memcheck: ..."
19:22 est31          sfan5, so why do you want to slow down memcheck, which is already slow?
19:22 sfan5          wat
19:22 sfan5          i would change the default debug flags to -O1
19:23 sfan5          if someone wants to use memcheck they change it to -O as suggested in the text
19:23 est31          then people will complain that memcheck has weird bugs
19:23 sfan5          read the text please
19:23 sfan5          "Since this often makes things unmanageably slow, a reasonable compromise is to use -O. This gets you the majority of the benefits of higher optimisation levels whilst keeping relatively small the chances of false positives or false negatives from Memcheck"
19:24 est31          Im still against making -O1 in debug mode
19:24 sfan5          for what reasons?
19:24 est31          you already have to turn off luajit for valgrind, you shouldnt need to fiddle with even more settings
19:24 est31          just to be abled to revert some commit for a pointless reason
19:25 sfan5          i dont want to revert that commit
19:25 est31          your goal is to revert the PR?
19:25 sfan5          it would be pointless
19:25 sfan5          what were arguing about right now is whether changing the debug flags to -O1 would have been a better way to fix this
19:26 est31          My honest opinion would have been to live with this, and change it where you touch the code
19:26 est31          to not break prs
19:26 sfan5          change it back to i++ you mean?
19:26 est31          no, change it to ++i where you already change something else close to that
19:27 sfan5          but that makes no sense
19:27 sfan5          we already discussed that
19:27 est31          ++i is better
19:27 sfan5          the compiler will optimize it away with any sane optimisation level
19:27 sfan5          there is no point
19:27 est31          where is i++ actually faster?
19:27 sfan5          idk
19:27 sfan5          but i am not saying that
19:27 est31          so why do that, instead of ++i
19:28 est31          with ++i you are only better
19:28 sfan5          because the person who coded it did it that way
19:28 est31          and its not requiring some serious efforts
19:28 sfan5          just because it doesn't require a lot of effore doesn't mean it's a good idea to do it
19:29 est31          sfan5, I agree that we shouldnt accept prs that just change code style to person's personal preference
19:29 est31          back and forth back and forth
19:29 sfan5          the only thing that s/i++/++i/ (on code that you change anyway) does is add another thing programmers need to look out for
19:29 est31          but in this case there is a speedup argument
19:29 sfan5          est31: yes i agree on that too
19:29 est31          its weak agreed,, but it is there
19:29 sfan5          not really
19:30 sfan5          it's not a speedup imo if any sane optimizations level will make the compiler optimize it away
19:30 est31          the game should be playable in debug mode as well
19:30 est31          with debug mode still being abled to be used for debugging
19:30 sfan5          it is if you change debug mode to -O1
19:31 sfan5          then it will still be usable for debugging
19:31 est31          no
19:31 sfan5          yes
19:33 est31          I gtg