Time Nick Message 01:17 jonadab ROllerozxa: One of my favorites is "We're sorry, but your password couldn't be changed. Code: 0x8007052d". Which means your password is longer than the maximum allowable length, because *of course* there's a maximum allowable length, it's not like hashing it is going to make that irrelevant or anything. 01:18 jonadab And yes, I found that out the hard way. 19:32 sfan5 if there are no complaints I'd like to merge #13092 this evening 19:32 ShadowBot https://github.com/minetest/minetest/issues/13092 -- Lua on each mapgen thread by sfan5 19:53 pgimeno just wow, looking forward to it 19:56 pgimeno does it break backwards compat? also, is there a provision for inter-thread communication? 19:56 pgimeno @sfan5 ^ 19:57 sfan5 no and no 19:58 pgimeno hm, the second "no" limits its use a bit; still, it's a great advance 19:59 pgimeno love2d has "channels" for inter-thread communication, which serialize/deserialize Lua data for communication and are also able to pass love2d objects 20:00 sfan5 the issue I always see with ipc is the following: what are you planning to do? any blocking work will stop the engine from functioning normally. 20:00 pgimeno in a thread? 20:00 pgimeno maybe threads want to talk between themselves 20:01 sfan5 but you don't get to choose and spawn threads 20:01 sfan5 you're only running work in callbacks inside engine threads 20:02 pgimeno still, they may need info on e.g. parameters or stuff 20:02 pgimeno it can also be non-blocking communication 20:02 sfan5 btw there is a way to communicate Lua data from the mapgen thread back to the main thread 20:03 sfan5 i can see why mods may need bidirectional communication but they way everything is set up right now you would basically be adding a huge footgun because it's so hard to use IPC correctly without impairing the engine 20:05 pgimeno I think I see your point 20:05 sfan5 of course this our "fault" because we only give mods single-purpose specialized ways to offload work and not just threading primitives 20:09 celeron55_ there's a huge advantage to single threaded operation though. it simplifies everything, up until to the point where you want to run large computational workloads 20:09 celeron55_ if e.g. every mod was ran in its own thread, any APIs provided by mods would have to be IPC based 20:10 celeron55_ then you'd end up wanting to be able to make "header-style" mods that are ran in the same thread that they are called in 20:11 celeron55_ even if the "standard" was a mod ran in its own thread 20:12 celeron55_ then, if a mod running in its own thread would want to do bulk-ish node operations, it would have no chance whatsoever of doing it with the basic api calls, as each would involve an environment mutex of some kind 20:12 celeron55_ you'd basically always have to use a voxelmanip-style thing or a serialized list of operations of some kind 20:13 celeron55_ then you'd probably have async and sync versions of every api 20:14 celeron55_ every thread would be fighting for the ownership of things, or alternatively nobody would own them and performance for accessing anything in the actual game would be unbearably bad 20:23 Krock at least the mapgen can easily be parallelized because.. it already is on C++ 20:24 Krock side 20:24 celeron55_ and it makes a lot of sense anyway 20:24 celeron55_ it's crazy that it takes only about a thousand lines to stretch that to lua 20:24 celeron55_ usefully 20:24 Krock for anything else I could see async + callback-based approaches to be more helpful for compute-intensive tasks that are working with their own data 20:26 celeron55_ yeah any time you can copy a chunk of data, throw it to a self-sufficient task and then get something back sometime later, a thread makes a lot of sense 21:16 pgimeno celeron55_> if e.g. every mod was ran in its own thread, any APIs provided by mods would have to be IPC based 21:16 pgimeno that doesn't sound too wise; I'm thinking about allowing mods to create their own threads instead 21:17 pgimeno not sure it'd be useful tbh 21:26 sfan5 merging #13092, #14298 in 10m 21:26 ShadowBot https://github.com/minetest/minetest/issues/13092 -- Lua on each mapgen thread by sfan5 21:26 ShadowBot https://github.com/minetest/minetest/issues/14298 -- [no squash] Dynamic media improvements by sfan5 22:21 MTDiscord Question on multi-threaded mapgen: in that PR did it affect current mapgen v7 or rivers or anything? Or is this mod-only for now and not built-in mapgens? 22:21 sfan5 engine mapgen has always been multi-threaded 22:24 MTDiscord oh - interesting - it never blocked main? gotcha 22:24 MTDiscord curse you caverealms haha 22:26 Desour awesome new mapgen feature 🎉🎉. and dynamic media improvement is also nice 🎉 22:28 nrz_ Good job guys ! 22:29 nrz_ I like lua callbacks per threads. It's the good way, and for maintenability ensure they never communicate together (there is no interest here) 23:06 MTDiscord Maybe you could have some kind of atomic, mutex, or rwlock/wrlock so they could? That would be crazy 23:22 MTDiscord Just not valuable I think. Even with dynamic mapgen stuff, you would just use message passing to let them know about the changes, you wouldn't need to know when they finished. It's like a traditional graphics GPU pipeline, one way