Time  Nick        Message
01:56 hmmmm       celeron55, sapier said it was trivial to add his async api to the mod environment
01:56 hmmmm       so really not much work
01:56 hmmmm       or are you asking about a completely asynchronous API
01:57 hmmmm       we would get 95% of the benefit of having a separate mod thread if sapier adds async api to mods and modders start using that (correctly)
01:58 hmmmm       anyway I think if we make (light userspace) locks per-mapblock and have the container itself lock-free/wait-free, we can almost eliminate the contention problem
01:58 hmmmm       i mean how often are two separate pieces of code really working on the same MapBlock
01:59 hmmmm       and even then, how long would they be working on that MapBlock for?
02:15 ShadowNinja ~tell sapier https://github.com/minetest/minetest/blob/master/builtin/builtin.lua#L13-L17 This needs to go.  It causes duplicate tracebacks and tracebacks when unwanted.  Use xpcall() or lua_pcall's errorhandler argument instead.
02:15 ShadowBot   ShadowNinja: O.K.
02:33 spillz      My 2c on threading and mods... trying to put mods into individual threads sounds like a tremendously bad idea. Better idea: all of the server side LUA stuff stays on one thread, but add engine API calls that do threaded/parallel processing for mods and use callbacks for tasks that may take some time to complete. e.g. mapgen mods should be able to ask the engine to do various processor intensive manipulations of map blocks ra
02:34 spillz      Also, ping on #1217
02:34 ShadowBot   https://github.com/minetest/minetest/issues/1217 -- Keyboard shortcuts for chat commands (REDUX) by spillz
02:49 ShadowNinja Objections to reverting https://github.com/minetest/minetest/commit/5b518ed2feff28c9bf21ad940c1b211b72d71bd1 ?
02:49 ShadowNinja Oh, that also ignored the level parameter to error().
02:51 ShadowNinja And didn't pass the message to debug.traceback().
02:58 hmmmm       spillz, yeah that's the idea.
02:58 hmmmm       each mod can be quite interdependent upon each other, so it doesn't make sense to have a separate thread for each.  the idea is to have a mod thread that is separate from the server thread so one isn't hung up on the other
04:11 ShadowNinja ~tell spillz Check the logs for -dev.
04:11 ShadowBot   ShadowNinja: O.K.
04:11 ShadowNinja Let's resolve this 'engine' vs. 'minetest' discussion.  I'm in favor of 'core' (or 'engine') because it's less awkward for forks (and shorter :-) ).
04:11 ShadowNinja celeron55 raises the point that 'core'/'engine' is too generic, using 'minetest' makes it unlikely that you will confuse a Minetest mod with a generic Lua file.
04:11 ShadowNinja However, I think that you will be able to tell because of
04:11 ShadowNinja 1. The location of the file and files near it (particularly a README)
04:11 ShadowNinja 2. Comments in the file describing it (particularly a header comment) and
04:11 ShadowNinja 3. What the mod does (you don't register a node and a craft for it in many applications...)
04:11 ShadowNinja
04:11 ShadowNinja Also: What do you think about adding a 'strict' module to builtin like Penlight's strict.lua?  It would make reading global varibles that haven't been defined an error rather than just returning nil.
04:11 ShadowNinja Lua's behavior with undifined globals is a common source of errors, and this shouldn't have a significant performance impact since anything that needs to be done fast is done with locals.
04:11 ShadowNinja Annother function of the strict module could be to print a warning when a global is added, to prevent global scope polution.  You could use, eg, core.add_global("areas", {}) (Basically just an alias for rewset()) for variables that should be global.
04:11 ShadowNinja
04:12 ShadowNinja Finally, I'd like to organize builtin into 'game', 'common', and 'mainmenu' folders.  I'd like to do this after my async pull is merged, to minimize rebasing.
04:12 ShadowNinja
04:12 ShadowNinja Sorry about the wall of text.  ;-)
04:20 ShadowNinja I just got flooded with "A sapling grew into a tree" messages, and no tree grew.  It seems the growing code's broken.
04:21 ShadowNinja (The growing code is very ugly, so now would be a good time to fix it's style too.)
04:23 VanessaE    rip out all of the growing code and merge plants_lib into core ;-)
04:23 VanessaE    (ok, maybe not, it's even uglier :P )
04:50 Megaf       Am I the only one who find this really pretty and fun? http://en.zimagez.com/zimage/compilingminetestonraspberrypi-megaf.php
05:07 ShadowNinja Comments? http://ix.io/bTD/diff (sorry about the big diff blocks, it was indented with spaces)
05:08 ShadowNinja BBL, sleep.
05:09 VanessaE    comment:
05:09 VanessaE    borrow some code from moretrees and make an L-system model instead of building the tree "manually".
05:10 VanessaE    surely that would be less code than the current way.  there's a model there (beech) that, with some minor changes, should look about the same as an existing tree.
05:27 * VanessaE  wanders off to bed.
05:29 Megaf       Good night VanessaE, sleep well
05:31 Megaf       I'm making a new game, man, that's gonna be great
05:32 Megaf       and lightweight
06:23 celeron55   hmm, running the lua environment in a separate but single thread sounds quite reasonabl
06:23 celeron55   +e
06:24 celeron55   it would get rid of the main problem which is the engine not being able to do trivial things like transferring positions of players when something in lua happens to be calculating something
06:25 celeron55   at least i think that is the main issue
06:29 celeron55   random inspirational video for minetest developers: https://www.youtube.com/watch?v=KeqQVHSvxG0
06:31 celeron55   ShadowNinja: i didn't know about such strict.lua thing; that does sound useful
06:32 celeron55   ShadowNinja: it also sounds like many mods will break but they'll be easy to fix and it will be much better in the long term
06:34 celeron55   also organizing builtin sounds reasonable
06:36 celeron55   ShadowNinja: also the issue i mentioned is not about confusing a minetest file with a generic lua file; the issue is not being able to use a generic term locally in each mod's code
06:39 celeron55   i'd like to hear everyone's opinion on this though
06:42 celeron55   i'm in favor of "core" because it's shorter
06:42 celeron55   (compared to "engine")
06:58 diemartin   +1 for strict.lua; I made an experiment a while ago, and it seems some of the mods in "default" tended to "leak" globals
06:58 diemartin   (in addition to a lot of leaks from other mods)
06:59 diemartin   my remarks at that time seem to get ignored due to more pressing issues (I think it was the modstore)
07:00 diemartin   except for a few modders which took my recommendation and fixed their stuff :P
07:02 celeron55   well, it happens (it helps to file an issue on github or write it on the forum if people are too busy doing something else on IRC)
07:48 diemartin   am I the only one using 4:3 display mode??
07:48 diemartin   oops
07:49 diemartin   wrong chan, sorry
12:03 twoelk      If it makes any sense I would place the all the mapgenerating kids together in a sandbox of their own (be it engine/core or mod) apart from all the other kids screaming for attention. So that life can go on at a normal pace near spawn while big geography is being calculated on the outer rims of the known world.
12:05 twoelk      This may not be an issue anymore, my setup may be outdated but if any process should be considered to run in
12:05 twoelk      an own thread/container, I would strongly suggest all mapgenerating stuff to be parted from the rest and not
12:05 twoelk      along any core/lua/mod border but rather as a functional group regardless of source. This may need some mod
12:05 twoelk      or even function classification though.
12:06 twoelk      ? sorry my ircclient split that
12:15 celeron55   twoelk: i've considered that too... there are quite many options here
12:16 celeron55   it could work like minetest.start_mapgen_thread("mapgen.lua") and that would run in it's own environment with only access to some voxelmanips or so
13:42 Taoki       Why was finite liquid removed? o.o
13:47 Taoki       Seemed to work good enough to me... prolly just needed some extra fixes here and there
13:48 Taoki       I won't miss finite liquid that much, but I'd really like to see weather added back without it. More precisely, water freezing and turning to ice... this should be totally possible even without finite liquid. By allowing only water sources to turn into ice blocks and vice versa
17:41 sapier      ShadowNinja:  I don't remember using error a lot, I just added the backtrace to it as it wasn't available by that time. Do your changes make sure we really get the backtrace?
17:42 sapier      it'd be quite annoying we'd have backtraces only half of time because of new handling doesn't handle everything
17:51 Megaf       sapier: There's a not too serious bug that is quite old already, but it's been annoying me for a while
17:51 sapier      tell about it
17:52 Megaf       sapier: That shadow thing, some areas get shadowed (I'm not sure about this word, may be wrong) with no apparent reason
17:52 Megaf       crop wont grow in that shadow
17:52 Megaf       crops*
17:52 sapier      lighting issues ... I know about yes but those issues are nontrivial
17:53 Megaf       if you go to my server ( minetest.megaf.info 30003 ) you will notice near the spawn point a large rectangular shadow
17:53 Megaf       any idea about what causes that?
17:53 proller     игппн дшпрештп
17:53 Megaf       some I can fix selecting the area with world edit and doing a //replace air air
17:53 proller     buggy lighting
17:54 VanessaE    I've seen that happen on my servers when using worldedit
17:54 VanessaE    solution:  select the area, //replace air with something like mese (anything you know for sure is NOT in the area), then //replace the mese or whatever you chose, with air again.
17:54 Megaf       sometime when many trees grown in a cluster, and you take them down, the shadow will remain
17:54 sapier      no need to proove I believe you. An idea yes, because I tried to optimize light calculation once and did make that issue even worse, so I didn't continue that work. I don't exactly understand how light is calculated but that's be required to fix it.
17:55 celeron55   there could be some bug in eg. the assumptions lighting has to make when something isn't generated yet, or there could be some rare situation where it's impossible to assume correctly
17:55 Megaf       VanessaE: you can replace air air, it works
17:55 VanessaE    Megaf:  hm, I never thought of doing that, didn't think it would work.  good tip.
17:55 VanessaE    (I assumed it had to be something opaque)
17:56 VanessaE    maybe a vmanip bug?
17:56 Megaf       yep, that was my first thought too, then I tried air air and it worked
17:57 sapier      my optimizations broke block edges, maybe there's a bug in how minetest usually calculates light on block edges
18:00 * twoelk    didn't notice those random shadows relating to block edges
18:00 sapier      well that's just an idea I don't have verified this yet
18:15 Megaf       sapier: so there's no quick fix for that
18:17 sapier      I don't think so megaf no
18:20 twoelk      I wonder if minetest should have a mod that shows block edges in game. Might be usefull for many debugging issues.
18:21 twoelk      no wait, doesn't landrush allready have a command for something similar?
18:29 Megaf       how now a days Minetest Minimal compares to Minetest 0.3?
18:30 Megaf       is it comatible with Minetest 0.3 clients?
18:30 VanessaE    not really comparable, and no.
18:31 VanessaE    and besides, 0.3.x is dead, use Minetest Classic if you want a 0.3.x-esque client.
18:31 * VanessaE  pokes darkrose
18:31 VanessaE    that one is quite the opposite of dead.
18:32 Megaf       Yep, I'm asking that because I'm reading the post about darkrose's servers
19:01 Megaf       darkrose: I want that snowcap biome for update minetest versions
19:01 Megaf       I mean, now a days
20:22 ShadowNinja The //fixlight / //replace air air trick doesn't always work.  I've had to use //replace air torch //replace torch air once or twice.
20:32 Megaf       ShadowNinja: That might do the trick, air air isnt working
21:47 ShadowNinja ~tell sapier No, you won't get a backtrace if you use pcall() in a mod.  But if you do that you probably don't want a backtrace.  Your override forces a backtrace if you use error(), whether or not you want it.
21:47 ShadowBot   ShadowNinja: O.K.
21:48 ShadowNinja celeron55: Great!  I'll change it to 'core' later (after some of my stuff is merged and I've asked a few people).
21:54 ShadowNinja Strict.lua, comments?: http://sprunge.us/HfIQ?diff  I fixed a few leaking globals too.
21:56 ShadowNinja Also, comments on #1226 please.  I don't want to do much before merging it to prevent conflicts.
21:56 ShadowBot   https://github.com/minetest/minetest/issues/1226 -- [WIP] Remove dependency on marshal and push the Lua error handler only once by ShadowNinja
21:56 ShadowNinja The [WIP] can probably go now.
22:07 sapier      ShadowNinja: well in case of a real error it's reasonable to assume a backtrace could be helpfull
22:08 ShadowNinja sapier: Yep.  There's xpcall() for that.
22:08 sapier      ipv4/ipv6 address family fixes somehow caused a major bug in packet retransmission
22:08 ShadowNinja sapier: Can you check https://github.com/minetest/minetest/issues/1226 ?
22:09 sapier      right now it seems impossible to resend timed out reliables because of address family in packet backup doesn't match address family of socket
22:10 sapier      I'm gonna check tomorrow ShadowNinja but I haven't changed opinion about moving those files is wrong
22:11 Megaf       ShadowNinja: replace air torch and then orch air did not work to wipe that shadow
22:20 sapier      forget about my last comment about a bug ... it's been in my local changes