Time  Nick       Message
02:02 rubenwardy merging #9184 in 5
02:02 ShadowBot  https://github.com/minetest/minetest/issues/9184 -- Add Lua builtin unit tests by rubenwardy
02:26 ANAND      5... hours? ;)
02:26 ANAND      Oh, nvm
02:26 ANAND      It was merged without a "Merging..." message :P
03:01 ANAND      Super-trivial 1-line PR: #9317
03:01 ShadowBot  https://github.com/minetest/minetest/issues/9317 -- [Trivial] guiFormSpecMenu.cpp: Replace stray tab with whitespace by ClobberXD
09:55 clavi      minetest_game only bumped the version number but is at the same commit level as 5.1.0, is this intentional?
10:14 ANAND      clavi: MTG's versioning is always in sync with MT, and new MTG versions would be released at the same time as their MT counterparts, in spite of there being no changes between versions.
10:16 clavi      alright, thanks
11:04 clavi      is Minetest compatible with the moonjit fork of LuaJIT?
11:21 Krock      #9153
11:21 ShadowBot  https://github.com/minetest/minetest/issues/9153 -- Use moonjit instead of LuaJIT
12:22 Krock      ANAND would like to have a second review here: #8271
12:22 ShadowBot  https://github.com/minetest/minetest/issues/8271 -- Fix breath statbar scaling; defer breath_bar hiding by one second by ClobberXD
12:24 Krock      #9317 also needs at least two reviews /s
12:24 ShadowBot  https://github.com/minetest/minetest/issues/9317 -- [Trivial] guiFormSpecMenu.cpp: Replace stray tab with whitespace by ClobberXD
12:56 celeron55_ clavi: code wise probably yes, as long as you're able to tell the build system to use it
12:57 ANAND      Krock: 9317 too? o_O
12:57 ANAND      Oh
12:57 ANAND      oops
16:24 rubenwardy merging #9317 in 10
16:24 ShadowBot  https://github.com/minetest/minetest/issues/9317 -- [Trivial] guiFormSpecMenu.cpp: Replace stray tab with whitespace by ClobberXD
16:30 clavi      celeron55_: thanks, do you know if any linux distro or bsd, macos, android builds use moonjit for minetest?
16:35 sfan5      I don't think anyone does that
16:35 Krock      clavi: do you think any distro does that by default if it's not even used in Minetest?
16:35 Krock      *used in the Minetest community
16:35 clavi      just wondering
16:36 Krock      you could compile it yourself to check whether it works
16:36 clavi      guess I'll try building and using it with moonjit to see if it breaks
16:36 clavi      yes :)
16:48 p_gimeno   besides "it's supported" what's the benefit of moonjit, again?
16:49 clavi      it's actually maintained
16:49 clavi      https://github.com/moonjit/moonjit
16:49 clavi      >This branch is 1014 commits ahead, 25 commits behind LuaJIT:master.
16:49 p_gimeno   ok besides "it's maintained" what's the benefit of moonjit, again?
16:52 p_gimeno   looking into here: https://github.com/moonjit/moonjit/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed doesn't reveal any outstanding benefit
16:55 p_gimeno   looking here: https://github.com/moonjit/moonjit/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed reveals some Lua 5.3 backports but I don't know if that's a good idea. LuaJIT is compatible with Lua 5.1; adding 5.3 features will just lay mines for users to step on
16:55 clavi      how so
16:55 clavi      if you only use lua 5.1 features
16:56 p_gimeno   you need to know that they are unique of 5.1, and not all modders know that
16:57 Krock      all I'd want in Lua is "continue"
16:58 clavi      modders not knowing what they're doing is not any runtime's fault
16:58 p_gimeno   classic LJ already has hex escapes like '\xNN' from 5.2 and that has introduced incompatibilities with PUC Lua when people didn't know it's not in 5.1
16:59 rubenwardy I want a nil operator and optional types
17:00 rubenwardy a nil operator means you can do    (a?.b)     instead of     (a and a.b)
17:00 p_gimeno   so, the only advantage is 5.3 extensions, and they aren't usable, which leads again to my first question: what's the benefit of moonjit besides "it's maintained"?
17:00 rubenwardy function(dog: table) -> int
17:00 rubenwardy imagine
17:00 rubenwardy I wish typedlua was maintained
17:00 clavi      can't you see how softare actually receiving bugfixes instead of being abandonware and rotting there is its own benefit?
17:01 Krock      p_gimeno: it's new, cool, trendy just like any Yet Another JS framework library
17:01 p_gimeno   clavi: what bugfixes?
17:02 clavi      surely among those 1000+ commits there must be one or two fixes
17:02 p_gimeno   *shrug*
17:02 clavi      idk what makes you so hostile towards a fork
17:04 p_gimeno   I don't see why adopting something for the reasons that Krock stated. LuaJIT is working fine, modulo the 1GB limit on 64 bits without GC64. If that isn't addressed, which is THE problem with LuaJIT, there's no reason to change to something that can become *less* stable.
17:04 rubenwardy the thing that worries me about these LuaJIT forks is the level of competence of the developers, and trends to accept loads of exciting new features which break stability and then the project
17:04 p_gimeno   ^
17:05 Krock      Mike Pall at least had a clear path of what LuaJIT should do
17:05 rubenwardy Mike Pall is a very good programmer, shame he left
17:05 rubenwardy he had lots of job offers for it
17:08 p_gimeno   I see more reasons to switch to RaptorJIT than to LuaJIT. The benefits are listed up front: https://github.com/raptorjit/raptorjit
17:08 p_gimeno   err than to MoonJIT*
17:08 rubenwardy The name for RaptorJIT comes from a quote from Mike Pall
17:09 rubenwardy he said something like to the pointer of - the raptors will descend upon LuaJIT add every feature and kill it
17:09 rubenwardy if that's RaptorJIT's philosophy, then we're back to "and trends to accept loads of exciting new features which break stability and then the project"
17:10 p_gimeno   to me it sounds more like ironic
17:12 p_gimeno   but since RaptorJIT has become x86-64 only, it has a reduced user base
17:14 rubenwardy 32bit is only really justified on RPis imo
17:14 rubenwardy I don't bother to make 32-bit Windows builds
17:14 rubenwardy not that I have any users for my games
17:14 rubenwardy oh, and Android
17:14 Krock      oh, and any other mobile or integrated device
17:14 p_gimeno   yeah but I don't expect many Android servers
17:14 Krock      singleplayer is also a server
17:15 p_gimeno   um, right
17:15 rubenwardy not one with many players
17:15 p_gimeno   yeah, and rarely if ever, bloated with mods
17:15 rubenwardy presumably, RaptorJIT has API compatibility with LuaJIT
17:15 p_gimeno   MT doesn't use the LJ API, does it?
17:16 Krock      I think there are some places where it does
17:16 p_gimeno   only Lua I think
17:16 rubenwardy in some places, but mostly lua
17:16 rubenwardy the some places are only init iirc
17:16 p_gimeno   uh I didn't know that
17:16 Krock      s_base.cpp and s_security.cpp only
17:17 Krock      based on the output of "grep -r LUAJIT"
17:19 p_gimeno   even if the API differs, it sounds like it's pretty much under control and could be #ifdef'd if necessary
17:20 sfan5      if we're "switching" to raptorjit the lack of windows support & x86-only are no-gos
17:20 sfan5      and if we're not switching it's irrelevant to us since the only binary builds we provide (windows + android) would not be able to use it
17:20 rubenwardy oh wow
17:22 sfan5      the README says this is "necessary [...] to make the code maintainable while we bootstrap the project" but I am sceptical of their ability/willingness/... to re-add support for Windows + other archs later on if those are indeed such big changes to the codebase
17:24 clavi      moonjit says it's supported on lots of stuff https://github.com/moonjit/moonjit/blob/master/INSTALL.md
17:25 p_gimeno   yeah, it's not all that clear that it's usable, all I said is that at least you know the benefits up front in comparison with moonjit which is just "hey look, it's maintained"... which is not necessarily a good thing for this kind of breakage-sensitive program
17:28 p_gimeno   also, who said LuaJIT is not maintained? https://github.com/LuaJIT/LuaJIT/commits/v2.1
17:29 p_gimeno   Mike Pall committed Jan 14, 2020
17:29 p_gimeno   that's 4 days ago
17:29 sfan5      huh
20:14 rubenwardy (if required/desired) Update the settingtypes.txt and the dummy *.cpp translation file and commit. There are automatic tools for this in the main menu code.
20:14 rubenwardy what does the cpp part of this mean?
20:15 Krock      settingtranslations.cpp will be generated
20:15 Krock      or so
20:15 rubenwardy oh right, so it makes settingtranslations.cpp from settingtypes.txt?
20:15 Krock      uncomment the two lines in the main menu settings *.lua file
20:15 Krock      it'll generate both files for you
20:16 Krock      1) pull translations from weblate (done)
20:16 Krock      2) generate translation files & settingtypes
20:16 Krock      3) updatepo.sh
20:16 Krock      4) rebase weblate
20:16 rubenwardy ok
20:19 rubenwardy this documentation is kinda terrible
20:19 rubenwardy where are the comments?
20:19 rubenwardy this is such a hack
20:19 rubenwardy oh of course, in the settings dialog file
20:19 Krock      /builtin/mainmenu/dlg_settings_advanced.lua
20:20 Krock      L1000-ish
20:20 sfan5      if the documentation is bad then improve it
20:20 rubenwardy I have been
20:21 Krock      if you use RUN_IN_PLACE=1, you'll need to create a src/ dir in the exec path
20:21 rubenwardy huh?
20:21 rubenwardy do you mean RUN_IN_PLACE=0?
20:21 rubenwardy there's already a src/ dir in the exec path
20:21 rubenwardy the src dir
20:22 Krock      what I said. settings_translation_file.cpp will be generated relatively to the execution dir
20:22 rubenwardy ah right
20:22 rubenwardy #9314
20:22 ShadowBot  https://github.com/minetest/minetest/issues/9314 -- Update translations by rubenwardy
20:23 rubenwardy https://github.com/minetest/minetest/pull/9314/commits/ca5c2173fa950a173704807a17c3252dc582e6e8
20:25 Krock      apparently settingtypes.txt doesn't contain some tail trimming operations: https://github.com/minetest/minetest/pull/9314/commits/ca5c2173fa950a173704807a17c3252dc582e6e8#diff-2fb5b44f6775f04cbd1e45bc2dfeb8b8L3063
20:25 rubenwardy the docs say to rebase and squash translations manually, so that each author only has one commit
20:26 rubenwardy I'm not going to do that manually
20:26 sfan5      that's stupid and we haven't done that in years
20:26 rubenwardy or at all
20:26 rubenwardy yeah
20:26 rubenwardy it's a waste of my time really
20:26 Krock      I just squashed the entire translations into one commmit
20:26 rubenwardy that's fair tbh
20:26 rubenwardy idk actuall
20:26 rubenwardy well, I can do a squashing merge for this PR if we decide to do that
20:27 Krock      Update from weblate should be a separate commit, really
20:27 Krock      updating minetest.conf.example is notdirectly the same thing
20:27 rubenwardy right
20:28 Krock      well, that's just my opinion like #8913 was done
20:28 ShadowBot  https://github.com/minetest/minetest/issues/8913 -- [NO SQUASH] Translations update by SmallJoker
20:28 rubenwardy it's not that hard to do
20:28 rubenwardy a find+replace on git rebase -i and a few corrections
20:29 rubenwardy wondering if it's fair to not attribute translators in the log, but I guess the log is more for development rather than attribution so it's fine
20:31 rubenwardy yeah, lets squash as that will make the log easier to deal with
20:33 erlehmann  rubenwardy, i think you can mention them in the commit message for the squashed commit?
20:36 Krock      squashing usually concats the commit titles, so yes.
20:37 Krock      but only titles.. hmm. in this case a custom "git log" output would help
20:45 p_gimeno   would it be of any benefit having a separate repo for the translations, as a submodule of the main repo?
20:50 erlehmann  i don't get the squashing thing
20:51 erlehmann  i have never seen a workflow where commits from different people were squashed
20:51 erlehmann  a person might squash their own branch to get a clean commit, though
20:52 Krock      p_gimeno: the idea is good, but weblate currently keeps a whole clone of the repository